Podstawy Azure DNS i Load Balancer

DNS (Domain Name System) tłumaczy czytelne dla człowieka nazwy domen (takie jak api.mycompany.com) na adresy IP używane przez komputery do komunikacji. Azure udostępnia dwie usługi DNS: Azure DNS do hostowania publicznych stref DNS (domen dostępnych z internetu) oraz Azure Private DNS do wewnętrznego rozpoznawania nazw w VNet-ach. Bez prawidłowej konfiguracji DNS do zasobów Azure trzeba odwoływać się za pomocą adresów IP, przez co architektury stają się podatne na awarie — każda zmiana adresu IP powoduje nieprawidłowe działanie wszystkich zależnych konfiguracji. Azure DNS to wysoce dostępna, globalnie rozproszona usługa oparta na sieci anycast firmy Microsoft.

Publiczne strefy Azure DNS hostują rekordy DNS dla domen dostępnych z internetu. Delegują Państwo swoją domenę (zarejestrowaną u rejestratora, takiego jak GoDaddy) do Azure DNS, aktualizując rekordy NS domeny tak, aby wskazywały serwery nazw Azure. Po delegowaniu można zarządzać wszystkimi rekordami DNS (A, CNAME, MX, TXT itd.) z poziomu portalu Azure lub interfejsu CLI zamiast korzystać z oddzielnego dostawcy DNS. Publiczne strefy Azure DNS zapewniają 100% dostępności w ramach SLA, globalną propagację w czasie krótszym niż sekunda oraz dostęp kontrolowany przez RBAC, dzięki czemu tylko upoważnieni członkowie zespołu mogą modyfikować rekordy DNS.

Prywatne strefy Azure DNS zapewniają rozpoznawanie nazw zasobów w VNet-ach bez publicznego udostępniania rekordów DNS. Można na przykład utworzyć prywatną strefę myapp.internal i zarejestrować w niej maszyny wirtualne, aby można było rozpoznawać je po nazwie (db.myapp.internal), a nie po adresie IP. Prywatne strefy DNS są połączone z VNet-ami — tylko zasoby w połączonych VNet-ach mogą rozpoznawać prywatne rekordy. Można także włączyć automatyczną rejestrację, która automatycznie tworzy rekordy DNS dla maszyn wirtualnych dołączanych do VNet-u, dzięki czemu DNS pozostaje zsynchronizowany bez ręcznego zarządzania.

Prywatne punkty końcowe (dla usług takich jak Azure SQL, Blob Storage i Key Vault) wymagają skonfigurowania DNS tak, aby publiczna nazwa hosta usługi była rozpoznawana jako prywatny adres IP zamiast publicznego adresu IP. Azure udostępnia prywatne strefy DNS dla każdej usługi (np. privatelink.blob.core.windows.net dla usługi Blob Storage). Podczas tworzenia prywatnego punktu końcowego Azure tworzy w tej prywatnej strefie rekord DNS A wskazujący prywatny adres IP. Należy połączyć tę strefę z VNet-em, a wszystkie zapytania DNS dotyczące adresu URL konta magazynu będą automatycznie zwracać prywatny adres IP — ruch będzie kierowany przez prywatną sieć szkieletową bez konieczności wprowadzania zmian w kodzie aplikacji.

Azure Load Balancer rozdziela przychodzący ruch sieciowy między wiele zasobów zaplecza (maszyn wirtualnych lub instancji w zestawie skalowania), aby zapobiec przeciążeniu pojedynczego zasobu. Działa w warstwie 4 (warstwie transportowej) modelu OSI — kieruje pakiety TCP i UDP na podstawie źródłowego i docelowego adresu IP oraz portu, bez analizowania zawartości HTTP. Azure Load Balancer to wysoce dostępna usługa nadmiarowa strefowo z SLA na poziomie 99,99% (Standard SKU), która obsługuje zarówno równoważenie ruchu przychodzącego (z internetu lub VNet-u), jak i wychodzący SNAT dla ruchu maszyn wirtualnych do internetu.

Azure Load Balancer ma cztery główne elementy: Konfiguracja adresu IP frontendu — publiczny lub prywatny adres IP, z którym łączą się klienci. Pula zaplecza — zestaw maszyn wirtualnych lub instancji zestawu skalowania odbierających ruch. Reguły równoważenia obciążenia — mapują adres IP i port frontendu na port zaplecza oraz określają algorytm rozdzielania ruchu (domyślnie hash 5-elementowej krotki). Testy kondycji — okresowo sprawdzają każdą instancję zaplecza; instancje, które nie przejdą testów, przestają otrzymywać nowe połączenia do czasu odzyskania sprawności. Wspólnie elementy te określają sposób odbierania, sprawdzania i rozdzielania ruchu.

Testy kondycji to okresowe sprawdzenia wysyłane przez load balancer do każdej instancji zaplecza w celu ustalenia, czy jest sprawna i powinna otrzymywać ruch. Konfigurują Państwo protokół testu (HTTP, HTTPS lub TCP), port i interwał. W przypadku testów HTTP/HTTPS load balancer wysyła żądanie GET do określonej ścieżki URL — instancja jest uznawana za sprawną, jeśli zwróci HTTP 200. W przypadku testów TCP pomyślne nawiązanie połączenia TCP oznacza sprawność. Jeśli zaplecze nie przejdzie konfigurowalnej liczby kolejnych testów, load balancer przestaje wysyłać do niego nowe połączenia, dopóki ponownie nie przejdzie testów. Zapewnia to automatyczną tolerancję błędów bez ręcznej interwencji.

Azure Load Balancer jest dostępny w dwóch jednostkach SKU: Basic — bezpłatny, obsługuje do 300 instancji zaplecza, nie zapewnia SLA ani obsługi stref dostępności i nie wymaga bezpiecznej konfiguracji NSG jako ustawienia domyślnego. Standard — płatny (około 20 USD miesięcznie opłaty podstawowej), obsługuje do 1000 instancji zaplecza, zapewnia SLA na poziomie 99,99%, strefowo nadmiarowy frontend, domyślne zabezpieczenia (wymaga jawnych reguł NSG zezwalających na ruch) oraz obsługę wielu adresów IP frontendu. W przypadku każdego obciążenia produkcyjnego zdecydowanie zalecana jest jednostka SKU Standard. Firma Microsoft wycofuje jednostkę SKU Basic — w nowych wdrożeniach należy zawsze używać wersji Standard.

Azure Load Balancer można wdrożyć w dwóch konfiguracjach: Publiczny (zewnętrzny) Load Balancer — ma publiczny adres IP na frontendzie i rozdziela ruch internetowy między maszyny wirtualne zaplecza. Jest używany w aplikacjach dostępnych z internetu, takich jak serwery internetowe i bramy API. Wewnętrzny (prywatny) Load Balancer — ma prywatny adres IP na frontendzie w obrębie VNet-u i rozdziela ruch wewnątrz VNet-u. Jest używany w aplikacjach wielowarstwowych, w których load balancer warstwy aplikacji nie powinien być dostępny z internetu, lecz tylko z warstwy internetowej w tym samym VNet-cie. Oba rozwiązania można wdrożyć jednocześnie: publiczny LB dla warstwy internetowej i wewnętrzny LB dla warstwy aplikacji.

Azure oferuje dwie podstawowe usługi równoważenia obciążenia przeznaczone do różnych scenariuszy: Azure Load Balancer — warstwa 4, TCP/UDP, ultraniskie opóźnienia, obsługa milionów połączeń na sekundę. Najlepszy w przypadku obciążeń innych niż HTTP lub gdy priorytetem są maksymalna przepustowość i minimalne opóźnienia. Azure Application Gateway — warstwa 7, HTTP/HTTPS, rozpoznaje ścieżki adresów URL i nagłówki, obejmuje Web Application Firewall (WAF), terminowanie SSL, powinowactwo sesji oparte na plikach cookie oraz routing oparty na adresach URL. Najlepszy w przypadku aplikacji internetowych wymagających równoważenia obciążenia uwzględniającego zawartość, odciążania TLS i ochrony WAF. W przypadku prostego równoważenia obciążenia TCP należy użyć usługi Load Balancer. W przypadku aplikacji internetowych Application Gateway oferuje znaczne dodatkowe możliwości.

DNS i Load Balancer współpracują ze sobą, tworząc odporne i przyjazne dla użytkownika punkty końcowe. Typowy schemat wygląda następująco: 1) Utwórz usługę Azure Load Balancer ze standardowym publicznym adresem IP i pulą backendu zawierającą maszyny wirtualne serwerów internetowych. 2) Utwórz rekord CNAME DNS w usłudze Azure DNS, wskazujący z domeny www.mycompany.com na publiczny adres IP Load Balancer (lub jego nazwę DNS). 3) Gdy użytkownicy odwiedzą stronę www.mycompany.com, DNS rozwiąże nazwę na adres IP Load Balancer, a Load Balancer rozdzieli żądania między sprawne instancje maszyn wirtualnych. Zapewnia to zarówno przyjazny adres URL, jak i automatyczne rozdzielanie ruchu z tolerancją błędów.

Sprawdź swoją wiedzę na temat zagadnień Microsoft Azure Fundamentals (AZ-900) omówionych w tej lekcji.

W tej lekcji poznali Państwo: Azure DNS hostuje publiczne i prywatne strefy DNS z dostępnością bliską 100%, umożliwiając korzystanie z czytelnych dla człowieka nazw zasobów Azure, prywatne strefy DNS z automatyczną rejestracją utrzymują aktualność rekordów DNS sieci VNet bez ręcznego zarządzania oraz Azure Load Balancer rozdziela ruch TCP/UDP warstwy 4 między sprawne instancje maszyn wirtualnych backendu, korzystając z sond kondycji do automatycznego wykrywania i pomijania niesprawnych instancji. Następnie przejdziemy do kursu Azure Databases, zaczynając od Azure SQL Database.