Ta strona używa cookies. Dowiedz się więcej o celu ich używania i zmianie ustawień cookies w przeglądarce.
Korzystając ze strony wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.

Zamknij X
Strona główna  Baza Wiedzy   Sieci wirtualne w środowisku Azure
Logo SOFTRONIC

Ośrodek Szkoleniowy i Egzaminacyjny

Sieci wirtualne w środowisku Azure

16.03.17r.

Podziel się:

        

VNet bez tajemnic.

Azure jest platformą Microsoft świadczącą usługi chmurowe różnorakich typów zlokalizowanych w centrach Microsoftu.

 
Głównym czynnikiem decydującym o wdrożeniu usług typu cloud, takich jak Azure, jest umożliwienie działom informatycznym przeniesienia zasobów serwerów do chmury. Może to zaoszczędzić pieniądze firmom, eliminując potrzebę utrzymywania drogich centrów danych za pomocą zasilaczy bezprzerwowych, generatorów prądu, sklastrowanych serwerów itd.

Możemy konfigurować trzy typy usług: Platform as a Service (PaaS), Infrastructure as a Service (Iaas) oraz Software as a Service (Saas). Ale wg mnie jest kilka istotnych komponentów, które nie ważny jaki model wybierzemy, wcześniej czy później, na pewno się z nim zetkniemy. Jednym z nich są sieci wirtualne (VNet).

VNet w środowisku Microsoft Azure to swego rodzaju układy sieciowe, które możemy wykorzystać do konfiguracji i sterowania połączeniami między maszynami wirtualnymi (VM), czy funkcjami usługi Paas. Oczywiście możemy używać zarówno maszyn wirtualnych, jak i usług PaaS bez wcześniej zdefiniowanych VNet, ale kiedy „osadzimy” je we wspólnych sieciach, włączymy bezpośrednią komunikację między nimi w odizolowanych sieciach i będziemy w stanie zdefiniować zakresy adresacji i związane z nimi ustawienia rozwiązywania nazw. Co ważne, VNets pozwalają na rozszerzenie sieci on-premise o połączenie z zasobami Microsoft Azure, tworząc środowisko hybrydowe (On-premise vs. Cloud). Aby zbudować taką konfigurację, należy podłączyć wirtualną sieć prywatną (VPN) on-premise do Azure VNet.

Poniżej kilka funkcjonalności, którym warto przyjrzeć się dokładniej:

Adresy IP
Wirtualne maszyny i usługi PaaS w pojedynczej VNet wymagają unikatowych adresów IP. Mamy dwa typy tych adresów: 
Dynamic internal IP address (DIP). Ten adres wykorzystywany jest przez maszyny wirtualne w sieci do komunikacji z innymi maszynami tej samej sieci. W sytuacji zestawienia tunelu VPN do Azure VNet, klienci środowiska on-premise komunikują się z maszynami wirtualnymi wykorzystując adresację DIP
Virtual IP address (VIP). Adres IP używany przez zewnętrznych klientów do komunikacji z usługami chmurowymi i ich maszynami wirtualnymi. Wszystkie maszyny wirtualne w zakresie pojedynczej usługi chmurowej mają ten sam adres VIP.
 
Azure przypisuje DIP wykorzystując protokół DHCP. DHCP przydziela adres IP na nieograniczony czas, zatem jest on stały… z małym wyjątkiem: jeśli maszyna wirtualna zostanie wyłączona i zdelokowana, adres DIP może ulec zmianie.
 
Jeśli używamy VPN do połączenia środowiska on-premise z VNet, musimy być pewni, że adresy IP on-premise i adres DIP VNet nie będą wchodziły w konflikt.

DNS
Domain Name System pozwala klientom na rozwiązywanie (tłumaczenie) w pełni kwalifikowanych nazw (FQDNs), takich jak: www.softronic.pl na adresy IP. Mamy oczywiście możliwość definiowania DNS na potrzeby rozwiązywania tylko nazw wewnętrznych VNet.
 
Azure Load Balancer oraz Internal Load Balancer
Jak wspomniałem wyżej klienci zewnętrzni używają adresów VIP do komunikacji z maszynami wirtualnymi Azure. VIP jest przypisany do usługi chmurowej IaaS znajdującej się w zdefiniowanej sieci VNet. W usłudze chmurowej możemy także zdefiniować tzw. Endpoints w celu zezwolenia użytkownikom na połączenie do konkretnej maszyny wirtualnej. Domyślnie endpoints są przypisane do pojedynczej maszyny wirtualnej.
W celu zwiększenia dostępności i skalowalności, możemy stworzyć dwie, bądź więcej maszyn wirtualnych w ramach tej samej usługi IaaS, która publikuje tą samą aplikację. Dla przykładu, jeśli kilka maszyn wirtualnych hostuje ten sam website, możemy dystrybuować ruch przychodzący pomiędzy te właśnie maszyny. W tej konfiguracji pojedynczy endpoint jest współdzielony przez maszyny wirtualne.
 
Traffic Manager
Jest kolejny przykładem rozwiązania Load Balancing, tym razem pomiędzy endpoint’ami zlokalizowanymi w różnych regionach Azure. Dzięki niemu mamy pewność, że użytkownik połączy się do endpoint’a zlokalizowanego najbliżej jego fizycznej lokalizacji.


W kolejnych odsłonach postaram się nakreślić kolejne komponenty platformy Microsoft Azure. Jeśli jesteście Państwo zainteresowani szczegółami konfiguracyjnymi powyższych funkcjonalności, zapraszam na szkolenie: MS-20533 Implementing Microsoft Azure Infrastructure Solutions


----------------------------------
Autor:
Patryk Łączny - MCT, MCSE: Cloud Platform and Infrastructure, Private Cloud
 

« powrót