Dostępność za pomocą nadmiarowości lokalnej i strefowej — Azure SQL Managed Instance

Dotyczy:Azure SQL Managed Instance

W tym artykule opisano architekturę usługi Azure SQL Managed Instance, która zapewnia dostępność dzięki nadmiarowości lokalnej i wysokiej dostępności dzięki nadmiarowości strefy.

Omówienie

Wystąpienie zarządzane SQL działa w oparciu o najnowszą stabilną wersję aparatu bazy danych SQL Server w systemie operacyjnym Windows z wszystkimi odpowiednimi aktualizacjami. Usługa SQL Managed Instance automatycznie obsługuje krytyczne zadania obsługi, takie jak stosowanie poprawek, kopie zapasowe, uaktualnienia aparatu bazy danych Windows i SQL oraz nieplanowane zdarzenia, takie jak awarie sprzętu, oprogramowania lub sieci. Jeśli wystąpienie jest poprawiane lub przechodzi w tryb failover, przestoje nie mają wpływu na zastosowanie logiki ponawiania prób w aplikacji. Usługa SQL Managed Instance może szybko odzyskiwać dane nawet w najbardziej krytycznych okolicznościach, zapewniając, że dane są zawsze dostępne. Większość użytkowników nie zauważa, że uaktualnienia są wykonywane w sposób ciągły.

Domyślnie Azure SQL Managed Instance zapewnia dostępność dzięki lokalnej nadmiarowości, gwarantując, że instancja radzi sobie z zakłóceniami, takimi jak:

  • Operacje zarządzania zainicjowane przez klienta, które skutkują krótkim przestojem
  • Operacje konserwacji usługi
  • Problemy i awarie centrum danych w następujących kwestiach:
    • Stojak, na którym działają maszyny zasilające usługę.
    • Maszyna fizyczna, która obsługuje maszynę wirtualną, na której działa silnik bazy danych SQL.
    • Maszyna wirtualna uruchamiająca silnik bazy danych SQL
  • Inne problemy z silnikiem bazy danych SQL
  • Inne potencjalne nieplanowane awarie lokalne

Domyślne rozwiązanie dostępności zostało zaprojektowane w celu zapewnienia, że zatwierdzone dane nigdy nie zostaną utracone z powodu awarii, że operacje konserwacji mają minimalny wpływ na obciążenie i że wystąpienie nie jest pojedynczym punktem awarii w architekturze oprogramowania.

Jednak aby zminimalizować wpływ na Twoje dane w przypadku awarii obejmującej całą strefę, można osiągnąć wysoką dostępność, włączając nadmiarowość strefową. Bez nadmiarowości strefowej przełączenie awaryjne następuje lokalnie w tym samym centrum danych, co może spowodować, że instancja będzie niedostępna do czasu usunięcia awarii — jedynym sposobem przywrócenia działania jest skorzystanie z rozwiązania do odzyskiwania po awarii, takiego jak grupa przełączania awaryjnego lub przywracanie geograficzne geograficznie nadmiarowej kopii zapasowej. Aby dowiedzieć się więcej, zapoznaj się z omówieniem ciągłości działania.

Wysoka dostępność zwiększa niezawodność usługi, chroniąc cię przed wpływem na:

  • Strefa dostępności, która tworzy centrum danych

Istnieją dwa różne modele architektury dostępności oparte na warstwie usługi:

  • Model magazynu zdalnego opiera się na rozdzieleniu zasobów obliczeniowych i magazynu w warstwach usług Ogólnego przeznaczenia i Ogólnego przeznaczenia nowej generacji oraz na dostępności i niezawodności magazynu zdalnego, a także na dostępności klastrów obliczeniowych zarządzanych przez Azure Service Fabric. Ten model dostępności jest przeznaczony dla aplikacji biznesowych zorientowanych na budżet, które mogą tolerować obniżenie wydajności podczas działań konserwacyjnych.
  • Model magazynu lokalnego jest oparty na klastrze procesów aparatu bazy danych, które opierają się na kworum dostępnych węzłów aparatu bazy danych z magazynem lokalnym w warstwie usługi Krytyczne dla działania firmy. Ten model magazynu lokalnego jest przeznaczony dla aplikacji o znaczeniu krytycznym, które obsługują dużą liczbę transakcji i wymagają wysokiej wydajności wejścia/wyjścia (I/O). Architektura wysokiej dostępności gwarantuje minimalny wpływ na wydajność obciążenia roboczego podczas prac konserwacyjnych.

Aby uzyskać więcej informacji na temat określonych umów SLA dla różnych warstw usług, zapoznaj się z umową SLA dotyczącą usługi Azure SQL Managed Instance.

Dostępność dzięki lokalnej nadmiarowości

Dostępność lokalnie nadmiarowa jest oparta na przechowywaniu węzłów obliczeniowych i danych w jednym centrum danych w regionie podstawowym i chroni dane w przypadku awarii lokalnej, takiej jak awaria sieci na małą skalę lub awaria zasilania. Jeśli w regionie wystąpi awaria na dużą skalę, taka jak pożar lub powodzia, wszystkie repliki konta magazynu lub danych w węzłach obliczeniowych mogą zostać utracone lub nieodwracalne. W związku z tym, aby dodatkowo chronić dane podczas korzystania z opcji dostępności lokalnie nadmiarowej, rozważ użycie bardziej odpornej opcji magazynu dla kopii zapasowych bazy danych.

Warstwa usługi Ogólnego przeznaczenia

Warstwa usługi Ogólnego przeznaczenia używa architektury dostępności magazynu zdalnego. Na poniższym rysunku przedstawiono cztery różne węzły z oddzielnymi warstwami obliczeniowymi i warstwami magazynu.

Diagram przedstawiający rozdzielenie zasobów obliczeniowych i magazynu.

Model dostępności magazynu zdalnego obejmuje dwie warstwy:

  • Bezstanowa warstwa obliczeniowa, która uruchamia proces aparatu bazy danych i zawiera tylko nietrwałe dane oraz dane w pamięci podręcznej, takie jak bazy danych tempdb i model na dołączonym dysku SSD oraz pamięć podręczna planów, pula buforów i pula magazynu kolumnowego w pamięci. Ten bezstanowy węzeł jest zarządzany przez Azure Service Fabric, który inicjuje silnik bazy danych, monitoruje stan węzła i w razie potrzeby przeprowadza przełączenie awaryjne na inny węzeł.
  • Stanowa warstwa danych z plikami bazy danych (.mdf i .ldf) przechowywana w usłudze Azure Blob Storage. Usługa Azure Blob Storage ma wbudowane funkcje dostępności i nadmiarowości danych. Dostępność lokalnie nadmiarowa jest oparta na przechowywaniu danych w magazynie lokalnie nadmiarowym (LRS), który kopiuje dane trzy razy w jednym centrum danych w regionie podstawowym. Gwarantuje to, że każdy rekord w pliku dziennika lub stronie w pliku danych zostanie zachowany, nawet jeśli proces aparatu bazy danych ulegnie awarii.

Za każdym razem, gdy aparat bazy danych lub system operacyjny zostanie uaktualniony lub zostanie wykryty błąd, usługa Azure Service Fabric przeniesie bezstanowy proces aparatu bazy danych do innego bezstanowego węzła obliczeniowego z wystarczającą ilością wolnej pojemności. Na dane w usłudze Azure Blob Storage przeniesienie nie ma wpływu, a pliki danych i dziennika zostają dołączone do nowo zainicjowanego procesu silnika bazy danych. Ten proces gwarantuje wysoką dostępność, ale przy dużym obciążeniu może wystąpić pewne obniżenie wydajności podczas przełączania, ponieważ nowy proces silnika bazy danych uruchamia się z pustą pamięcią podręczną.

Warstwa usługi ogólnego przeznaczenia nowej generacji

Następna generacja Ogólnego Przeznaczenia to uaktualnienie architektury istniejącego poziomu usług Ogólnego Przeznaczenia, które używa udoskonalonej zdalnej warstwy magazynowej. Przechowuje ona dane instancji i pliki dziennika w elastycznej sieci SAN zamiast w obiektach blob stron i obsługuje je lokalnie.

Redundancja strefowa nie jest dostępna dla aktualizacji warstwy usługi Ogólnego Przeznaczenia nowej generacji.

Poziom usługi Krytyczny dla działania firmy

Warstwa usługi Business Critical korzysta z modelu dostępności opartego na magazynie lokalnym, który integruje zasoby obliczeniowe (proces aparatu baz danych) i magazyn danych (lokalnie podłączony dysk SSD) w jednym węźle. Dostępność jest osiągana przez replikowanie zasobów obliczeniowych i magazynu do dodatkowych węzłów.

Diagram przedstawiający klaster węzłów aparatu bazy danych.

Bazowe pliki bazy danych (.mdf/.ldf) są przechowywane w dołączonej pamięci masowej SSD, aby zapewnić bardzo niskie opóźnienia operacji wejścia/wyjścia dla Twojego obciążenia roboczego. Dostępność jest implementowana przy użyciu technologii podobnej do zawsze włączonych grup dostępności programu SQL Server. Klaster obejmuje jedną podstawową replikę dostępną dla obciążeń klientów wymagających odczytu i zapisu oraz do trzech replik pomocniczych (obliczeniowych i pamięci masowej), które zawierają kopie danych. Replika podstawowa stale przesyła zmiany sekwencyjnie do replik pomocniczych, aby upewnić się, że zostaną one utrwalone na wystarczającej liczbie replik pomocniczych przed zatwierdzeniem każdej transakcji. Ten proces gwarantuje, że jeśli replika podstawowa lub replika pomocnicza z możliwością odczytu staną się niedostępne z jakiegokolwiek powodu, zawsze będzie dostępna w pełni zsynchronizowana replika, do której można przełączyć się awaryjnie. Przełączenie awaryjne jest inicjowane przez Azure Service Fabric. Gdy replika pomocnicza stanie się nową repliką podstawową, zostanie utworzona inna replika pomocnicza, aby upewnić się, że klaster ma wystarczającą liczbę replik do obsługi kworum. Po zakończeniu przełączenia awaryjnego połączenia z usługą Azure SQL są automatycznie przekierowywane do nowej repliki podstawowej (lub czytelnej repliki pomocniczej, w zależności od parametrów połączenia).

Dodatkową zaletą jest to, że model dostępności magazynu lokalnego obejmuje możliwość przekierowywania połączeń Azure SQL tylko do odczytu do jednej z replik pomocniczych. Ta funkcja nosi nazwę skalowanie odczytu w poziomie. Zapewnia ona 100% dodatkowej mocy obliczeniowej bez dodatkowych opłat, umożliwiając odciążenie repliki podstawowej z operacji tylko do odczytu, takich jak obciążenia analityczne.

Wysoka dostępność dzięki nadmiarowości strefowej

Dostępność strefowo nadmiarowa jest oparta na umieszczaniu replik w trzech strefach dostępności platformy Azure w regionie podstawowym. Każda strefa dostępności jest oddzielną lokalizacją fizyczną z niezależnym zasilaniem, chłodzeniem i siecią.

Domyślnie klaster węzłów dla lokalnego modelu dostępności magazynu jest tworzony w tym samym centrum danych. Wraz z wprowadzeniem stref dostępności platformy Azure usługa SQL Managed Instance umieszcza repliki w różnych strefach dostępności w obrębie tego samego regionu. Aby wyeliminować pojedynczy punkt awarii, pierścień sterowania jest również duplikowany w wielu strefach. Ruch płaszczyzny sterowania jest następnie kierowany do modułu równoważenia obciążenia, który jest również wdrażany w różnych strefach dostępności. Kierowanie ruchem z płaszczyzny sterowania do modułu równoważenia obciążenia jest sterowane przez Azure Traffic Manager (ATM).

Korzystając z konfiguracji nadmiarowej między strefami, można zwiększyć odporność instancji Business Critical lub General Purpose na znacznie szerszy zakres awarii, w tym katastrofalne awarie centrum danych, bez wprowadzania jakichkolwiek zmian w logice aplikacji. Istniejące wystąpienia Krytyczne dla działania firmy lub Ogólnego przeznaczenia można przekonwertować na konfigurację strefowo nadmiarową. Nadmiarowość w strefie nie jest dostępna dla warstwy usługi Ogólnego przeznaczenia nowej generacji.

Ponieważ wystąpienia strefowo nadmiarowe mają repliki w różnych centrach danych z pewną odległością między nimi, zwiększone opóźnienie sieci może zwiększyć czas zatwierdzania transakcji, a tym samym wpłynąć na wydajność niektórych obciążeń OLTP. Zawsze można wrócić do konfiguracji z jedną strefą, wyłączając ustawienie nadmiarowości strefy. Ten proces jest operacją online podobną do standardowego uaktualnienia docelowego poziomu usługi. Na końcu procesu wystąpienie jest migrowane z pierścienia strefowo nadmiarowego do pierścienia jednostrefowego lub odwrotnie.

Aby rozpocząć korzystanie z nadmiarowości stref w wystąpieniu zarządzanym SQL, zapoznaj się z artykułem Konfigurowanie nadmiarowości stref. Przejrzyj dostępność redundancji strefy dla poszczególnych regionów dla usługi Azure SQL Managed Instance.

Warstwa usługi Ogólnego przeznaczenia

W warstwie usługi General Purpose nadmiarowość strefowa jest osiągana przez umieszczenie bezstanowych węzłów obliczeniowych w różnych strefach dostępności i oparcie jej na stanowym magazynie z nadmiarowością strefową (ZRS), który jest dołączany do tego węzła, który aktualnie zawiera aktywny proces silnika SQL Database. W przypadku awarii proces silnika bazy danych SQL zostaje uruchomiony na jednym z bezstanowych węzłów, który następnie uzyskuje dostęp do danych przechowywanych w magazynie stanowym.

Poniższy diagram przedstawia architekturę nadmiarowości strefowej dla warstwy usługi Ogólnego przeznaczenia:

Schemat architektury nadmiarowości strefowej w warstwie usługi Ogólnego przeznaczenia.

Poziom usługi Krytyczny dla działania firmy

W warstwie usługi Business Critical nadmiarowość strefowa jest osiągana przez rozmieszczenie replik warstwy obliczeniowej i magazynu w różnych strefach dostępności, a następnie wykorzystanie technologii grup dostępności Always On do replikowania zmian danych z instancji podstawowej do replik w trybie gotowości w innych strefach dostępności. W przypadku awarii występuje automatyczna praca w trybie failover, która bezproblemowo przenosi jedną z replik rezerwowych na podstawową.

Poniższy diagram przedstawia architekturę nadmiarowości strefowej dla warstwy usługi Business Critical:

Schemat architektury nadmiarowości strefowej w warstwie usługi Business Critical.

Testowanie odporności błędów aplikacji

Dostępność jest podstawowym elementem platformy SQL Managed Instance i działa w sposób transparentny dla aplikacji bazodanowej. Wiemy jednak, że warto przetestować, jak automatyczne operacje trybu failover inicjowane podczas planowanych lub nieplanowanych zdarzeń będą miały wpływ na aplikację przed wdrożeniem jej w środowisku produkcyjnym. Możesz ręcznie wywołać przełączenie awaryjne, wywołując specjalny interfejs API, aby ponownie uruchomić wystąpienie zarządzane. Ponieważ operacja ponownego uruchamiania jest natrętna i duża ich liczba może przeciążyć platformę, tylko jedno wywołanie trybu failover jest dozwolone co 15 minut dla każdego wystąpienia zarządzanego.

Podczas rzeczywistego przejścia w tryb failover połączenia z wystąpieniem kończą się niepowodzeniem, gdy usługa SQL staje się podstawowa w innym węźle. Aby zasymulować tryb failover, wywołaj polecenie, które ponownie uruchamia proces SQL, aby symulować uruchamianie usługi tak, jakby nastąpiło przełączenie w tryb failover. Jednak podczas rzeczywistego failoveru połączenia mogą nie działać przez dłuższy czas niż podczas symulowanego failoveru, ponieważ w trakcie rzeczywistego failoveru proces SQL przejmuje rolę podstawowego na innej maszynie wirtualnej w klastrze (lokalnie lub w innej strefie, jeśli włączono nadmiarowość między strefami), a podczas symulowanego failoveru proces SQL jest ponownie uruchamiany na istniejącej maszynie wirtualnej.

Ręczne polecenie przełączenia awaryjnego opisane w tej sekcji zwykle działa tak samo zarówno w konfiguracjach z lokalną nadmiarowością, jak i z nadmiarowością strefową. Polecenie zwykle uruchamia ponownie proces SQL lokalnie i nie inicjuje przejścia w tryb failover do innego węzła, chociaż stosuje się kilka wyjątków. To lokalne przełączenie awaryjne różni się od przełączenia awaryjnego, które występuje w przypadku grupy przełączania awaryjnego. Nie ma jednak żadnego ograniczenia, które gwarantuje uruchomienie nowego procesu w tym samym węźle i może zostać uruchomione w innym węźle w tym samym lub w innej strefie dostępności. Lokalne przełączenie awaryjne można zainicjować za pomocą programu PowerShell, interfejsu API REST lub Azure CLI:

PowerShell interfejs API REST Interfejs wiersza poleceń platformy Azure
Invoke-AzSqlInstanceFailover SQL Managed Instance - przełączenie awaryjne az sql mi failover może służyć do wywoływania wywołania interfejsu API REST z interfejsu wiersza polecenia platformy Azure

Automatyczne testy łączności wewnętrznej

Aby zapewnić dostępność usługi, Azure SQL Managed Instance uruchamia automatyczne wewnętrzne testy łączności w celu monitorowania niezawodności usługi i przyspieszania wykrywania problemów. Testy te są wykonywane co 10 sekund z wewnętrznych adresów IP w obrębie podsieci wystąpienia zarządzanego SQL i mają pomijalny wpływ na przepustowość sieci i wydajność usługi. Jeden test weryfikuje łączność typu end-to-end, próbując zalogować się przy użyciu poświadczeń, o których wiadomo, że spowodują niepowodzenie logowania (AzureSQLConnectivityChecker), co generuje oczekiwane wpisy o nieudanych próbach logowania w dziennikach audytu, zdarzeniach rozszerzonych i dziennikach błędów SQL. Te wpisy są normalne i nie wskazują problemu z zabezpieczeniami. Aby uzyskać więcej informacji, w tym sposób identyfikowania podpisów testowych w dziennikach, zobacz Automatyczne testy łączności wewnętrznej.

Podsumowanie

Usługa Azure SQL Managed Instance oferuje wbudowane rozwiązanie wysokiej dostępności, które jest głęboko zintegrowane z platformą Azure. Usługa zależy od usługi Service Fabric do wykrywania awarii i odzyskiwania, usługi Azure Blob Storage w celu ochrony danych oraz Strefy dostępności w celu zapewnienia większej odporności na uszkodzenia. W przypadku warstwy usługi Business Critical usługa SQL Managed Instance używa technologii grup dostępności Always On programu SQL Server do replikacji baz danych i obsługi przełączania awaryjnego. Połączenie tych technologii pozwala aplikacjom w pełni wykorzystać zalety modelu magazynu mieszanego i obsługiwać najbardziej wymagające umowy SLA.

Treści powiązane

  • Last updated on