Strona korzysta z plików cookies w celu realizacji usług i zgodnie z Polityką Plików Cookies.



07.04.2021

Lubelskie Dni Informatyki

Koło Naukowe Informatyków już po raz XIII zorganizuje Lubelskie Dni Informatyki.
07.04.2021

Bariery językowe przełamane

Cisco Webex
06.04.2021

Nowość w portfolio Bakotech

Progress Software
06.04.2021

Kontrola służbowych urządzeń

Hexnode MDM
02.04.2021

Red Hat Inc.

Firma Red Hat Inc. udostępniła Red Hat OpenShift 4.7 – najnowszą wersji czołowej...
02.04.2021

Rozpoznawanie twarzy

QNAP QVR
02.04.2021

Układy EPYC Serii 7003

Firma AMD zaprezentowała nowe wydajne procesory serwerowe, czyli układy EPYC Serii 7003,...
02.04.2021

Mobilna wydajność

Satellite Pro C50-G
01.04.2021

Nowa linia monitorów

AOC V4

Wirtualny WAN w chmurze Azure

Data publikacji: 01-04-2021 Autor: Piotr Wojciechowski

Firmowa sieć WAN rozrasta się wraz z rozwojem przedsiębiorstwa. Gdy przedsiębiorstwo przenosi swoje zasoby do chmury, naturalne jest także rozciągnięcie WAN-u do chmury publicznej. W Azure jest nawet przeznaczona do tego celu usługa.

 

Firmowe sieci rozległe, czyli tak zwane sieci WAN, służą do łączenia ze sobą różnych fizycznych lokalizacji naszego przedsiębiorstwa. Istnieje kilka topologii, w której tego typu sieci mogą działać. Najpopularniejsze z nich są hub-and-spoke oraz dual-homed. Często spotykamy także połączenia partial-mesh czy full-mesh. W tej ostatniej każda z sieciowych lokalizacji jest połączona logicznie z pozostałymi węzłami. We wszystkich tych rozwiązaniach istnieje jeden lub więcej centralnych węzłów zwanych hubami lub koncentratorami. Służą one za punkt połączenia pomiędzy odległymi węzłami i to w nich koncentruje się ruch.


> WAN w chmurze publicznej


Chmura publiczna w rozwiązaniach typu WAN może pełnić rolę zarówno węzła końcowego, jak i jednego z koncentratorów. Jeżeli budowaliśmy już swoje rozwiązania WAN, to prawdopodobnie koncentratory ruchu zlokalizowane są wewnątrz naszej sieci. Zazwyczaj w jednym z głównych biur lub centrów przetwarzania danych. Są to naturalne lokalizacje dla hubów, gdyż w tych miejscach naszej sieci koncentruje się ruch. Zazwyczaj tam też umiejscowione są serwery aplikacyjne, z którymi komunikują się stacje robocze. Te centralne węzły sieci WAN co do zasady powinny być połączone między sobą siecią połączeń o wysokiej przepustowości. Ma to zapewnić odpowiednie przesyłanie dużej ilości danych pomiędzy nimi, a także pomiędzy samymi węzłami końcowymi, które zazwyczaj nie komunikują się bezpośrednio ze sobą, tylko za pośrednictwem węzłów centralnych.


Wraz z rozwojem usług chmurowych coraz więcej aplikacji uruchomionych jest w chmurze publicznej. Mogą to być wirtualne maszyny, na których działają korporacyjne aplikacje, lub chmurowe usługi pakietów biurowych takich jak Office 365. Firmy powszechnie wykorzystują też natywne usługi chmurowe udostępniane w modelu Platform as a Service (PaaS), za pomocą których wykonują zaawansowane czynności, płacąc jedynie za zużyte zasoby. Wszystko to powoduje, że regiony poszczególnych dostawców usług chmury publicznej stają się niezwykle ważne z punktu widzenia sieci firmowej, a co za tym idzie połączenie do nich i pomiędzy nimi muszą być odpowiednio szybkie i redundantne. Dlatego naturalnym elementem rozwoju usług chmurowych, za pomocą których realizujemy połączenia sieciowe, jest dostarczenie rozwiązań ułatwiających budowanie sieci WAN, z chmurą publiczną jako punkt centralny. Zapewniają one także odpowiednią redundancję połączeń pomiędzy regionami, a co za tym idzie dostępność do innych usług realizowanych w chmurze, które także ze względów bezpieczeństwa umieszczamy w więcej niż jednym regionie. vWAN, czyli Virtual WAN, jest właśnie tego typu usługą, którą znajdziemy w chmurze Azure. Korzystając z niej, stworzymy skalowalne rozwiązanie typu WAN, realizowane w modelu PaaS.


> Tworzymy vWAN


Wirtualny WAN w usłudze Azure możemy otworzyć na kilka sposobów. Użycie do tego portalu Azure jest najbardziej tradycyjną metodą polegającą na „wyklikiwaniu” wszystkich parametrów usługi krok po kroku w przeglądarce internetowej. Ten sposób zapewni najlepsze zrozumienie działania poszczególnych elementów usługi i zachodzących między nimi relacji i powiązań. Zarządzanie usługą wirtualnego WAN może odbywać się także w sposób zautomatyzowany – za pomocą takich narzędzi jak Azure CLI czy Azure PowerShell – lub programowalny poprzez dostępną na platformie REST API oraz dostarczoną przez Microsoft bibliotekę Azure SDK for Python. Zarządzać konfiguracją możemy także w modelu Infrastructure as a Code za pomocą narzędzia Terraform. Portal Azure nie pozwala nam jednak na wykonanie wszystkich czynności diagnostycznych, które oferuje nam platforma. Do pewnych bardzo specyficznych zadań będziemy musieli wykorzystać Azure CLI.


Przed przystąpieniem do konfiguracji należy sprawdzić, czy subskrypcja Azure jest aktywna. Płatność za usługę realizowana jest w modelu Pay As You Go. Jeżeli administrujemy bardziej złożoną topologią, w której skonfigurowany jest więcej niż jeden węzeł vWAN w różnych regionach, zapłacimy także za ruch, który wygenerujemy pomiędzy regionami Azure. Microsoft oddzielnie także nalicza opłaty za dane przesyłane w szyfrowanych tunelach VPN. Dlatego zanim skonfigurujemy usługę w naszej firmie, pamiętajmy, by dokładnie przeprowadzić symulację potencjalnych kosztów.


Aby utworzyć nową usługę, łączymy się z portalem Azure (portal.azure.com), wybieramy przycisk Create a Resource i odnajdujemy usługę Virtual WAN. W oknie kreatora musimy podać podstawowe dane takie jak subskrypcja, do której usługa zostanie przypisana, resource grupa oraz region, w którym grupa się znajduje. Każdej usłudze vWAN musimy ponadto nadać nazwę oraz wybrać jej typ. Jeżeli wybierzemy Basic, to utworzymy prostą usługę, w ramach której będziemy mogli skonfigurować jedynie tunele VPN typu site-to-site. Usługa typu Standard pozwoli nam na skorzystanie ze wszystkich funkcjonalności produktu. Z typu Basic możemy zawsze dokonać zmiany na Standard, w odwrotnym kierunku zmiana jednak jest już niedozwolona.


> Huby i usługi


Ponieważ architektura usługi vWAN opiera się na architekturze hub-and-spoke, budując własny wirtualny WAN w Azure, będziemy posługiwali się kilkoma terminami: Huby (koncentratory) to tak naprawdę regiony Azure, w ramach których realizowana jest usługa vWAN. W każdym regionie możemy zdefiniować tylko jeden hub, do którego można podłączyć ponad tysiąc węzłów. Jeżeli tworząc usługę vWAN, wybraliśmy jej typ jako Basic, to każdy z utworzonych hubów jest izolowany. Oznacza to, że ruch pomiędzy hubami nie jest dozwolony. W usłudze typu Standard wszystkie huby, które utworzymy w ramach usługi vWAN, są ze sobą połączone siecią typu full-mesh zarządzaną przez Microsoft. Do koncentratorów podłączamy końcówki różnego typu. W tym artykule przedstawię konfigurację tuneli site-to-site. W ramce umieszczone zostały opisy pozostałych typów połączeń, jakie oferuje vWAN.


Aby utworzyć nowy hub, należy przejść do sekcji Connectivity w menu po lewej stronie oraz wybieramy opcję Hubs. Kreator tworzenia nowego koncentratora składa się z kilku kroków, podczas których konfigurujemy jego podstawowe parametry oraz wybieramy usługi, które mają być świadczone w danym regionie. Ponieważ za każdą z tych usług płacimy stałą opłatę za utrzymanie, pamiętajmy, aby wybierać tylko te, które są nam w danym regionie potrzebne. W pierwszym kroku kreatora wybieramy region, w którym umieszczamy nasz hub, oraz nadajemy mu nazwę. Każda z usług realizowanych w ramach vivaan potrzebuje poświęconej jej przestrzeni adresowej do swojego działania. Ponieważ Azure vWAN jest usługą zarządzaną, nie musimy przejmować się alokacją podsieci dla każdego z połączeń. Musimy jednak zdefiniować minimalną przestrzeń adresową, w ramach której poszczególne usługi będą miały alokowane adresy IP. Podsieć dedykowana dla koncentratora nie może pokrywać się z adresami stosowanymi przez nas w chmurze Azure ani z żadną lokalizacją, którą chcemy podłączyć do koncentratora. Minimalny rozmiar podsieci to /24.

 

[...]

 

Autor specjalizuje się w rozwiązaniach routing & switching, data center oraz service providers. Promuje automatyzację w środowiskach sieciowych i udziela się jako deweloper w projektach open source. Jest twórcą modułów do Docker Swarm w Ansible'u i jednym z opiekunów modułów w community.docker. Pracuje jako niezależny konsultant IT. Posiada certyfikat CCIE.

Pełna treść artykułu jest dostępna w papierowym wydaniu pisma.

prenumerata Numer niedostępny Spis treści

.

Transmisje online zapewnia: StreamOnline

All rights reserved © 2019 Presscom / Miesięcznik "IT Professional"