Udostępnij za pośrednictwem

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

  • Artykuł

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.

Ważne

Konfiguracja strefowo nadmiarowa jest dostępna w publicznej wersji zapoznawczej dla warstwy usługi Ogólnego przeznaczenia i ogólnie dostępna dla warstwy usługi Krytyczne dla działania firmy.

Omówienie

Wystąpienie zarządzane SQL działa w najnowszej stabilnej wersji aparatu bazy danych programu SQL Server w systemie operacyjnym Windows ze wszystkimi odpowiednimi poprawkami. 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 usługa Azure SQL Managed Instance osiąga dostępność za pośrednictwem nadmiarowości lokalnej, dzięki czemu wystąpienie jest dostępne podczas:

  • Zainicjowane przez klienta operacje zarządzania, które powodują krótki przestój
  • 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 hostuje maszynę wirtualną z uruchomionym aparatem bazy danych SQL
    • maszyna wirtualna z uruchomionym aparatem bazy danych SQL
  • Inne problemy z aparatem bazy danych SQL
  • Inne potencjalne nieplanowane awarie lokalne

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

Jednak aby zminimalizować wpływ na dane w przypadku awarii w całej strefie, można osiągnąć wysoką dostępność , włączając nadmiarowość strefy. Bez nadmiarowości strefy tryb failover odbywa się lokalnie w tym samym centrum danych, co może spowodować niedostępność wystąpienia do momentu rozwiązania awarii — jedynym sposobem odzyskania jest rozwiązanie odzyskiwania po awarii, takie jak za pośrednictwem grupy trybu failover lub geograficzne przywracanie 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 Następnej generacji, która opiera się na dostępności i niezawodności magazynu zdalnego oraz dostępności klastrów obliczeniowych zarządzanych przez usługę 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.
  • Lokalny model magazynu jest oparty na klastrze procesów aparatu bazy danych, które opierają się na kworum dostępnych węzłów aparatu bazy danych w warstwie usługi Krytyczne dla działania firmy, która ma magazyn lokalny. Ten lokalny model magazynu jest przeznaczony dla aplikacji o krytycznym znaczeniu, które mają wysoką szybkość transakcji i wymagają wysokiej wydajności operacji we/wy. Architektura wysokiej dostępności gwarantuje minimalny wpływ na wydajność obciążenia podczas działań 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ść za pośrednictwem nadmiarowości lokalnej

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 przejściowe i buforowane dane, takie jak tempdb bazy danych i model na dołączonym dysku SSD, pamięć podręczna planu, pula i pula magazynu kolumn w pamięci. Ten bezstanowy węzeł jest obsługiwany przez usługę Azure Service Fabric , która inicjuje aparat bazy danych, kontroluje kondycję węzła i w razie potrzeby wykonuje przejście w tryb failover do innego węzła.
  • 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. Przeniesienie danych w usłudze Azure Blob Storage nie ma wpływu na dane, a pliki danych/dziennika są dołączane do nowo zainicjowanego procesu aparatu bazy danych. Ten proces gwarantuje wysoką dostępność, ale duże obciążenie może spowodować obniżenie wydajności podczas przejścia, ponieważ nowy proces aparatu bazy danych rozpoczyna się od zimnej pamięci podręcznej.

Warstwa usługi Ogólnego przeznaczenia następnej generacji

Uwaga

Uaktualnienie warstwy usługi Ogólnego przeznaczenia następnej generacji jest obecnie dostępne w wersji zapoznawczej.

Next-gen Ogólnego przeznaczenia to uaktualnienie architektury do istniejącej warstwy usługi Ogólnego przeznaczenia, która używa uaktualnionej warstwy magazynu zdalnego, która przechowuje dane wystąpień i pliki dziennika na dyskach zarządzanych zamiast stronicowych obiektów blob i obsługuje ją lokalnie.

warstwa usługi Krytyczne dla działania firmy

Warstwa usługi Krytyczne dla działania firmy korzysta z lokalnego modelu dostępności magazynu, który integruje zasoby obliczeniowe (proces aparatu bazy danych) i magazyn (lokalnie dołączony dysk SSD) w jednym węźle. Wysoka 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.

Podstawowe pliki bazy danych (.mdf/.ldf) są umieszczane w dołączonym magazynie SSD w celu zapewnienia bardzo małych opóźnień we/wy dla obciążenia. Wysoka dostępność jest implementowana przy użyciu technologii podobnej do zawsze włączonych grup dostępności programu SQL Server. Klaster zawiera jedną replikę podstawową dostępną dla obciążeń klientów odczytu i zapisu oraz maksymalnie trzy repliki pomocnicze (obliczeniowe i magazynowe), które zawierają kopie danych. Replika podstawowa stale wypycha zmiany do replik pomocniczych sekwencyjnie, aby upewnić się, że dane są utrwalane 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, w pełni zsynchronizowana replika jest zawsze dostępna w trybie failover. Tryb failover jest inicjowany przez usługę 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 pracy w trybie failover połączenia usługi Azure SQL są automatycznie przekierowywane do nowej repliki podstawowej (lub repliki pomocniczej z możliwością odczytu na podstawie parametry połączenia).

Dodatkową korzyścią jest możliwość przekierowywania połączeń usługi Azure SQL tylko do odczytu z jedną z replik pomocniczych. Ta funkcja jest nazywana skalowaniem odczytu w poziomie. Zapewnia ona 100% dodatkowej pojemności obliczeniowej bez dodatkowych opłat za operacje tylko do odczytu, takie jak obciążenia analityczne, z repliki podstawowej.

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 usługi Azure Strefy dostępności usługa SQL Managed Instance umieszcza różne repliki w różnych strefach dostępności w tym samym regionie. 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. Routing ruchu z płaszczyzny sterowania do modułu równoważenia obciążenia jest kontrolowany przez usługę Azure Traffic Manager (ATM).

Korzystając z konfiguracji strefowo nadmiarowej, można zapewnić odporność wystąpień Krytyczne dla działania firmy lub ogólnego przeznaczenia na znacznie większy zestaw awarii, w tym katastrofalne awarie centrum danych bez żadnych zmian logiki aplikacji. Istniejące wystąpienia Krytyczne dla działania firmy lub Ogólnego przeznaczenia można przekonwertować na konfigurację strefowo nadmiarową.

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 zwykłego uaktualnienia celu warstwy usług. Na końcu procesu wystąpienie jest migrowane z pierścienia strefowo nadmiarowego do pierścienia jednostrefowego lub odwrotnie.

Aby rozpocząć pracę z nadmiarowością stref dla wystąpienia zarządzanego SQL, zapoznaj się z artykułem Konfigurowanie nadmiarowości strefy.

Warstwa usługi Ogólnego przeznaczenia

W warstwie usługi Ogólnego przeznaczenia nadmiarowość strefy jest osiągana przez umieszczenie bezstanowych węzłów obliczeniowych w różnych strefach dostępności, a następnie opiera się na magazynie strefowo nadmiarowym stanowym (ZRS), który jest dołączony do niezależnie od tego, który węzeł zawiera obecnie aktywny proces aparatu bazy danych SQL. W przypadku awarii proces aparatu bazy danych SQL staje się aktywny w jednym z węzłów bezstanowych, który następnie uzyskuje dostęp do danych w magazynie stanowym.

Na poniższym diagramie przedstawiono architekturę nadmiarowości strefy dla warstwy usługi Ogólnego przeznaczenia:

Diagram architektury nadmiarowości strefy w warstwie usługi Ogólnego przeznaczenia.

Uwaga

Nadmiarowość strefy jest obecnie dostępna w wersji zapoznawczej dla warstwy usługi Ogólnego przeznaczenia.

warstwa usługi Krytyczne dla działania firmy

W warstwie usługi Krytyczne dla działania firmy nadmiarowość strefy jest osiągana przez umieszczenie replik obliczeniowych i magazynowych w różnych strefach dostępności, a następnie użycie podstawowej technologii zawsze włączonej grupy dostępności w celu replikowania zmian danych z wystąpienia podstawowego do replik rezerwowych 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ą.

Na poniższym diagramie przedstawiono architekturę nadmiarowości strefy dla warstwy usługi Krytyczne dla działania firmy:

Diagram architektury nadmiarowości strefy w warstwie usługi Krytyczne dla działania firmy.

Testowanie odporności błędów aplikacji

Dostępność jest podstawową częścią platformy SQL Managed Instance, która działa w sposób niewidoczny dla aplikacji bazy danych. 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 wyzwolić tryb failover przez wywołanie specjalnego interfejsu API w celu ponownego uruchomienia wystąpienia zarządzanego. 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 połączenia mogą zakończyć się niepowodzeniem przez dłuższy okres w czasie rzeczywistego przejścia w tryb failover w porównaniu z symulowanym trybem failover, ponieważ podczas rzeczywistego przejścia w tryb failover proces SQL staje się podstawowym na innej maszynie wirtualnej w klastrze (lokalnie lub w innej strefie, jeśli włączono nadmiarowość strefy) i podczas symulowanego przejścia w tryb failover, proces SQL jest uruchamiany ponownie na istniejącej maszynie wirtualnej.

Ręczne polecenie trybu failover w tej sekcji zachowuje się tak samo zarówno w konfiguracjach lokalnie nadmiarowych, jak i strefowo nadmiarowych — tylko uruchamia proces SQL lokalnie i nie inicjuje przejścia w tryb failover do innego węzła. Ten lokalny tryb failover różni się od trybu failover, który występuje w przypadku grupy trybu failover.

Lokalne przejście w tryb failover można zainicjować przy użyciu programu PowerShell, interfejsu API REST lub interfejsu wiersza polecenia platformy Azure:

Program PowerShell Interfejs API REST Interfejs wiersza polecenia platformy Azure
Invoke-AzSqlInstanceFailover SQL Managed Instance — tryb failover az sql mi failover może służyć do wywoływania wywołania interfejsu API REST z interfejsu wiersza polecenia platformy Azure

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 Krytyczne dla działania firmy usługa SQL Managed Instance używa technologii zawsze włączonej grupy dostępności programu SQL Server na potrzeby replikacji bazy danych i trybu failover. Połączenie tych technologii pozwala aplikacjom w pełni wykorzystać zalety modelu magazynu mieszanego i obsługiwać najbardziej wymagające umowy SLA.

Następne kroki