Dziedziny magazynowania dla SQL Managed Instance z obsługą usługi Azure Arc

  • Artykuł

Magazyn jest kluczowym składnikiem we wdrożeniu SQL Managed Instance z obsługą usługi Azure Arc (SQL Managed Instance z obsługą usługi Arc). Zrozumienie, w jaki sposób pojęcia związane z magazynem opisane w tym dokumencie wpływają na funkcjonowanie klastrów Kubernetes jest ważnym aspektem wyborów projektowych i zarządzania magazynem.

Zamiast bezpośrednio korzystać z magazynu bazowego, platforma Kubernetes zapewnia warstwę abstrakcji do różnych technologii magazynowania za pośrednictwem klas magazynu. Dostawcy usług w chmurze, dostawcy sprzętu i inne platformy zarządzane przez platformę Kubernetes oferują różne opcje StorageClass dopasowane do konkretnych środowisk i scenariuszy implementacji.

SQL Managed Instance z obsługą usługi Arc nie ogranicza ani nie wymusza używania żadnych klas magazynu, dlatego ważne jest, aby wybrać prawidłowy projekt i konfigurację magazynu. Projekt magazynu dla SQL Managed Instance z obsługą usługi Arc jest tak ważny, jak w przypadku wybierania urządzeń magazynujących dla SQL Server podczas uruchamiania na maszynach bez systemu operacyjnego lub maszyn wirtualnych. Te opcje ostatecznie reprezentują wymagania dotyczące celu punktu odzyskiwania, celu odzyskiwania, pojemności i wydajności.

W przypadku wdrożeń SQL Managed Instance z obsługą usługi Arc efektywne planowanie możliwości i konfiguracji magazynu ma kluczowe znaczenie dla pomyślnego działania. Przeczytaj, aby dowiedzieć się więcej o czynnikach związanych z magazynem, które należy wziąć pod uwagę, a następnie zalecenia dotyczące konfigurowania SQL Managed Instance z obsługą usługi Arc.

Architektura

Na poniższym diagramie architektury przedstawiono logiczny projekt składników usług danych z obsługą usługi Azure Arc. Te składniki obejmują wymagany kontroler danych usługi Azure Arc i co najmniej jedną SQL Managed Instance z obsługą usługi Arc, które zawierają bazy danych aprowizowane do celów referencyjnych. Zarówno kontroler danych usługi Azure Arc, jak i SQL Managed Instance z obsługą usługi Arc zapewniają opcje obsługi urządzeń magazynujących, które są zależne od dostawców dystrybucji i infrastruktury magazynu Kubernetes.

Zrzut ekranu przedstawiający diagram architektury logicznej usług danych z obsługą usługi Azure Arc.

Zagadnienia dotyczące projektowania

Poniżej przedstawiono zagadnienia dotyczące projektowania i konfiguracji magazynu.

Klasy magazynu

Wybranie odpowiedniej klasy Kubernetes StorageClass i konfiguracji składników usług danych z obsługą usługi Azure Arc jest ważne dla wydajności magazynu danych, odporności i pojemności.

Klasy StorageClass, PersistentVolume (PV) i PersistentVolumeClaim (PVC) to obiekty zasobów Platformy Kubernetes tworzone w klastrze Kubernetes podczas aprowizacji składników usług danych z obsługą usługi Azure Arc.

Opcje storageClass różnią się w zależności od tego, co dostawca usług w chmurze, dostawca sprzętu oferuje i co skonfigurowano administrator platformy Kubernetes. Element PersistentVolumeClaim żąda utworzenia elementu PersistentVolume dla klasy StorageClass i żądanego rozmiaru. Poniższy diagram stanowi odwołanie do relacji między tymi zasobami Kubernetes i potencjalnymi opcjami dla klas magazynu.

Zrzut ekranu przedstawiający pojęcia dotyczące magazynu Kubernetes z opcjami klas magazynowania.

Zasoby platformy Kubernetes PV i PVC są konfigurowane odpowiednio podczas aprowizacji kontrolera danych usługi Azure Arc i SQL Managed Instance z obsługą usługi Arc.

Istnieją dwa różne typy magazynów do wyboru:

  • Lokalnych: Wolumin zainstalowany na lokalnym urządzeniu magazynu dołączonym do węzła Kubernetes, w którym jest uruchomiony zasobnik. Ten typ magazynu zwykle zapewnia mniejsze opóźnienie wraz z wyższymi operacjami wejścia/wyjścia na sekundę (we/wy na sekundę) i przepływnością w porównaniu z magazynem zdalnym/udostępnionym.
  • Magazyn zdalny/udostępniony: Urządzenia magazynujące dołączone do sieci, które mają tendencję do nadmiarowości wbudowanej. Typowe opcje magazynowania to urządzenia NAS i SAN.

Podczas wybierania klasy StorageClass należy wziąć pod uwagę następujące standardy. Te kryteria będą również miały wartość true dla dowolnego serwera bazy danych, który chcesz skompilować:

  • Wydajności: Przepływność wejścia/wyjścia urządzenia magazynu (we/wy) i liczba operacji we/wy na sekundę powinna spełniać potrzeby bazy danych.
  • Współczynnik odczytu/zapisu: Zrozumienie obciążenia może pomóc w wyborze sprzętu pomocniczego, aby najlepiej zaspokoić potrzeby związane z odpowiednimi kosztami. Duże obciążenia zapisu mogą korzystać z konfiguracji RAID 0, natomiast rzadko używane dane mogą być najlepiej obsługiwane przy użyciu magazynu urządzeń SAN.
  • Izolacja bazy danych i wspólna lokalizacja: Wszystkie bazy danych w wystąpieniu z obsługą usługi Arc SQL Managed Instance współużytkować pv, dzięki czemu można przenieść bazy danych do oddzielnych wystąpień SQL Managed Instance z obsługą usługi Arc i uniknąć rywalizacji o zasoby magazynu.
  • Pojemność: Zdefiniowany rozmiar magazynu powinien spełniać przyszłe możliwości kontrolera danych i wystąpień bazy danych, aby uniknąć konieczności zmiany rozmiaru pvc. Rozważ wszelkie ograniczenia magazynu, które mogły mieć wybrana klasa StorageClass.
  • Tryb dostępu: Dostawcy klas magazynu mają różne tryby dostępu, obsługując różne możliwości sposobu instalacji i odczytywania i zapisywania magazynu przez zasobniki. Dla woluminu kopii zapasowej SQL wymagany jest RWX (odczyt zapisu wiele).
  • Nadmiarowości: Replikacja danych w warstwie magazynu fizycznego (RAID) w celu zapewnienia bezproblemowego przejścia w tryb failover, jeśli wystąpi awaria dysku sprzętowego, która jest oddzielona od nadmiarowości na poziomie bazy danych wykonywanej przez grupy dostępności.

Zarówno kontroler danych usługi Azure Arc, jak i usługi danych z obsługą usługi Arc SQL Managed Instance z obsługą usługi Arc zapewniają szczegółowe opcje konfigurowania różnych klas magazynowania dla danych bazy danych. Te usługi danych udostępniają również dzienniki, które umożliwiają elastyczność wybierania klas magazynu w celu spełnienia potrzeb.

Kontroler danych

Dla klastra Kubernetes wymagany jest pojedynczy kontroler danych usługi Azure Arc jako wstępnie wymagany do tworzenia wystąpień SQL Managed Instance z obsługą usługi Arc. Więcej niż jeden kontroler danych uruchomiony w klastrze nie jest obsługiwany.

Kontroler danych usługi Azure Arc będzie mieć cztery różne zasobniki stanowe uruchomione w klastrze Kubernetes: Kontroler SQL, Interfejs API kontrolera, Baza danych dzienników i Metryki DB. Każdy zasobnik wymaga dwóch woluminów trwałych dla woluminów danych i dzienników. Wszystkie składniki kontrolera danych wymagają zdalnej klasy StorageClass w celu zapewnienia trwałości danych, ponieważ same składniki kontrolera danych nie zapewniają trwałości danych natywnie.

Pamiętaj, aby wziąć pod uwagę zasoby obliczeniowe i pamięci wymagane przez kontroler danych usługi Azure Arc. Na poniższym diagramie przedstawiono zasoby magazynu kontrolera danych, PV i PVC Kubernetes.

Zrzut ekranu przedstawiający magazyn kontrolera danych usługi Azure Arc.

Domyślny rozmiar woluminu kontrolera danych jest zalecanym minimum. Używany magazyn zależy od liczby baz danych, sposobu używania baz danych i liczby generowanych dzienników. Klasa StorageClass kontrolera danych usługi Azure Arc nie jest wrażliwa na małe opóźnienia. Mimo to użytkownicy mogą zobaczyć korzyści w interfejsach Grafana i Kibana z szybszym magazynem, jeśli masz wiele wdrożeń SQL Managed Instance z obsługą usługi Arc w klastrze. Narzędzia Grafana i Kibana są open source narzędzia do monitorowania wizualizacji wdrożone za pomocą kontrolera danych i aprowizowane za pomocą pulpitów nawigacyjnych do wyświetlania metryk i dzienników dla SQL Managed Instance z obsługą usługi Arc.

Aprowizowanie kontrolera danych

Podczas aprowizacji kontrolera danych usługi Azure Arc skonfiguruj klasę StorageClass i pojemność magazynu zarówno dla dzienników, jak i danych. Konfigurowanie magazynu zarówno dla dzienników, jak i danych ma zastosowanie do wszystkich ośmiu telewizorów utworzonych dla zasobników kontrolera danych. Podczas aprowizacji można określić niestandardowy szablon wdrożenia , który zastępuje domyślne parametry, takie jak pojemność, przechowywanie dzienników i elementy związane z zabezpieczeniami, takimi jak typy usługi Kubernetes. Po zakończeniu aprowizacji obiekty PV i PVC Kubernetes zostaną utworzone.

Ważne jest, aby zrozumieć, że klasa StorageClass dla kontrolera danych nie może zostać zmieniona po aprowizacji. Jeśli nie określisz klasy StorageClass, kontroler danych używa domyślnej klasy StorageClass platformy Kubernetes, która może się różnić w zależności od wystąpienia lub dostawcy platformy Kubernetes.

Po odinstalowaniu kontrolera danych usługi Azure Arc wszystkie skojarzone z nim woluminy trwałe zostaną usunięte. Zarchiwizuj wszystkie dzienniki na poziomie płaszczyzny sterowania usług danych z obsługą usługi Azure Arc, które organizacja musi zapisać przed odinstalowaniem kontrolera danych.

SQL Managed Instance z obsługą usługi Azure Arc

SQL Managed Instance z obsługą usługi Arc oferuje dwie różne warstwy w zależności od wymagań biznesowych: Ogólnego przeznaczenia i Krytyczne dla działania firmy. W przypadku obu warstw ważne jest przejrzenie minimalnych i maksymalnych limitów SQL Managed Instance z obsługą usługi Arc, które można skonfigurować, oraz upewnienie się, że wdrożony klaster Kubernetes ma odpowiednią pojemność obliczeniową i pamięci.

W scenariuszach z wieloma bazami danych w danym wystąpieniu bazy danych wszystkie bazy danych używają tej samej klasy StorageClass, PVC i PV określonej dla SQL Managed Instance z obsługą usługi Arc. Istnieje możliwość posiadania wielu wystąpień SQL Managed Instance z obsługą usługi Arc w jednym klastrze Kubernetes. Ta konfiguracja umożliwia niezależne woluminy trwałe i może pomóc oddzielić rywalizację we/wy z różnych baz danych, wdrażając bazy danych w różnych wystąpieniach SQL Managed Instance z obsługą usługi Arc.

W poniższej tabeli opisano różne woluminy trwałe używane przez każdy zasobnik z obsługą usługi Arc SQL Managed Instance i jego przeznaczenie.

Wolumin trwały Opis Wymagania dotyczące klasy magazynu
Dane pliki danych SQL Database (pliki mdf) Zależy od warstwy
Dzienniki danych pliki dziennika SQL Database (pliki ldf) Zależy od warstwy
Dzienniki Agent SQL, dzienniki błędów, pliki śledzenia, dzienniki kondycji Zależy od warstwy
Tworzenie kopii zapasowych SQL Server pliki kopii zapasowej, w tym pełne, różnicowe, transakcyjne dzienniki Zdalny, ReadWriteMany Tryb dostępu

Ogólnego przeznaczenia warstwie usługi

Warstwa Ogólnego przeznaczenia SQL Managed Instance z obsługą usługi Arc musi używać magazynu zdalnego dla wystąpienia bazy danych, aby po awarii zasobnika dane pozostają dostępne dla nowo utworzonych zasobników. Tryb failover jest zarządzany przez zasobnik Kubernetes i orkiestrację węzłów. Ta konfiguracja jest mniej złożona w porównaniu do Krytyczne dla działania firmy, która korzysta z grup dostępności SQL i wielu replik SQL Managed Instance z obsługą usługi Arc. Konfiguracja pojedynczego zasobnika w warstwie Ogólnego przeznaczenia oznacza, że można zminimalizować ilość miejsca do magazynowania, ponieważ nie trzeba duplikować pojemności magazynu dla innych replik.

Zrzut ekranu przedstawiający magazyn SQL Managed Instance Ogólnego przeznaczenia z obsługą usługi Arc.

Krytyczne dla działania firmy warstwie usługi

Krytyczne dla działania firmy warstwie używa wielu modeli zasobników, w których można przechowywać dane i woluminy dziennika w lokalnych lub zdalnych klasach magazynu. Lokalne klasy magazynu zwykle działają lepiej pod względem opóźnienia i przepływności, ponieważ urządzenie magazynujące jest bezpośrednio dołączone do węzła. Magazyn zdalny zwykle oferuje wbudowaną nadmiarowość, ale często ma mniejsze opóźnienia i przepływność w porównaniu z magazynem lokalnym. Należy pamiętać, że użycie większej liczby replik bazy danych Krytyczne dla działania firmy wymaga dodatkowych woluminów trwałych dla danych, dzienników i dzienników danych. Wymagana całkowita pojemność magazynu jest znacznie większa.

Na poniższym diagramie przedstawiono konfigurację magazynu Krytyczne dla działania firmy dla Arc-Enabled SQL Managed Instance z dwiema replikami.

Zrzut ekranu przedstawiający magazyn SQL Managed Instance Krytyczne dla działania firmy z obsługą usługi Arc.

Krytyczne dla działania firmy umożliwia skonfigurowanie dwóch lub trzech replik pomocniczych. Tryb failover jest zarządzany przez zawsze włączoną grupę dostępności SQL, która zapewnia mniej przestojów w przypadku uaktualnień i awarii niż warstwa Ogólnego przeznaczenia.

Skonfigurowanie wielu replik z replikacją danych trybu zatwierdzania synchronicznego zapewnia lepszą ochronę przed awariami, takimi jak zasobnik, węzeł lub sprzęt magazynu. Chroni przed awariami, ponieważ istnieje wiele kopii danych na replikach. Rozważ skonfigurowanie replik pomocniczych jako wystąpień skalowania w poziomie odczytu, z którymi klienci mogą się łączyć podczas korzystania z pomocniczego punktu końcowego odbiornika.

Aprowizowanie i odinstalowywanie usługi Azure Arc SQL Managed Instance

Podczas aprowizacji SQL Managed Instance z obsługą usługi Arc można elastycznie przypisywać różne klasy magazynu do każdego z wymaganych SQL Managed Instance trwałych woluminów z obsługą usługi Arc. Możesz chcieć użyć opcji magazynu o wyższej wydajności dla dzienników danych i dzienników danych, ale woluminy dzienników i kopii zapasowych mogą użyć bardziej ekonomicznej opcji StorageClass, aby zaoszczędzić na kosztach. W scenariuszach, w których używasz magazynu lokalnego, upewnij się, że woluminy są w stanie wylądować na różnych węzłach i urządzeniach magazynu fizycznego, aby uniknąć rywalizacji o we/wy dysku. Umieszczenie danych i dzienników danych na tym samym dysku fizycznym może spowodować rywalizację o ten dysk magazynu, co skutkuje niską wydajnością. Zamiast tego rozważ umieszczenie danych i dzienników danych na oddzielnych dyskach magazynu w celu równoległości we/wy zarówno dla danych bazy danych, jak i dzienników.

Po usunięciu SQL Managed Instance z obsługą usługi Arc skojarzone z nią komputery wirtualne i pvcs nie zostaną usunięte. Takie zachowanie gwarantuje, że można uzyskać dostęp do plików bazy danych w przypadku przypadkowego usunięcia.

Zalecenia dotyczące projektowania

Poniżej przedstawiono zalecenia dotyczące projektowania i konfiguracji magazynu.

Klasy magazynu dla obciążeń produkcyjnych

W przypadku określonych chmur publicznych zalecane klasy magazynu dla obciążeń produkcyjnych są wyświetlane w poniższej tabeli.

Dostawca Zweryfikowany i zalecany magazyn
Azure Kubernetes Service (AKS) Azure Dyski zarządzane (warstwa Premium)
Amazon Elastic Kubernetes Service (EKS) Sterownik magazynu EBS CSI
Google (GKE) Dyski trwałe GCE

Podczas wybierania produkcyjnej klasy StorageClass w scenariuszach lokalnych lub wielochmurowych upewnij się, że jest ona w stanie sprostać zamierzonej pojemności magazynu, operacji we/wy na sekundę, nadmiarowości i przepływności. W poniższych sekcjach przedstawiono więcej zaleceń dotyczących tych scenariuszy.

Projekt kontrolera danych

Wybierz zdalną, udostępnioną klasę StorageClass, aby zapewnić trwałość danych. W przypadku usunięcia zasobnika lub węzła można przywrócić kopię zapasową zasobnika i ponownie nawiązać połączenie z woluminem trwałym. Podkreśl element StorageClass musi zapewnić nadmiarowość i wysoką dostępność.

Zalecamy użycie niestandardowego szablonu wdrożenia podczas tworzenia kontrolera danych usług danych z obsługą usługi Arc. Szablon niestandardowy umożliwia dostosowanie klas magazynu, rozmiaru magazynu dla danych i dzienników, zabezpieczeń i typów usługi Kubernetes Service. Można je dostosować do potrzeb twojego środowiska i przedsiębiorstwa. Kontroler danych usługi Azure Arc wymaga łącznie ośmiu woluminów trwałych. Domyślna minimalna konfiguracja umożliwia korzystanie z 15Gi dla danych i 10Gi w przypadku dzienników na telewizorach. Skonfiguruj pojemność, która nie tylko spełnia minimalne zalecenia, ale obsługuje wyższy wzrost z wielu implementacji SQL Managed Instance z obsługą usługi Arc działających w klastrze. Ta konfiguracja uniemożliwi zmianę rozmiaru pvC w przyszłości.

Zalecamy wybranie klasy StorageClass o niższym opóźnieniu w przypadku, gdy klaster ma wiele baz danych i wdrożeń SQL Managed Instance z obsługą usługi Arc. Mniejsze opóźnienie poprawia środowisko użytkownika w interfejsach Grafana i Kibana.

Migracja SQL Managed Instance z obsługą usługi Azure Arc

Zalecamy planowanie i uwzględnianie wszystkich nowych i istniejących baz danych związanych z migracją i wdrażaniem SQL Managed Instance z obsługą usługi Arc. Planowanie uniemożliwia przenoszenie baz danych między wystąpieniami w późniejszym czasie.

W zależności od organizacji klastra Kubernetes aprowizuj wdrożenia SQL Managed Instance z obsługą usługi Arc w różnych klastrach Kubernetes w zależności od potrzeby oddzielenia środowisk (nieprodowych, prod), regionów i innych czynników biznesowych. Zapoznaj się z obszarem projektowania organizacji zasobów , aby uzyskać więcej zaleceń. Podczas konfigurowania wielu wystąpień bazy danych w klastrze należy oddzielić zajęte bazy danych na własne wystąpienie, aby uniknąć rywalizacji o operacje we/wy.

Użyj etykiet węzłów, aby upewnić się, że wystąpienia bazy danych są umieszczane w oddzielnych węzłach, aby dystrybuować ogólny ruch we/wy między wieloma węzłami, zobacz Etykiety węzłów Kubernetes wraz z koligacją węzła Kubernetes i etykietami koligacji na potrzeby konfigurowania etykiet. Jeśli działa w środowisku zwirtualizowanym, upewnij się, że we/wy są odpowiednio rozproszone na poziomie hosta fizycznego.

Zaplanuj pojemność SQL Managed Instance z obsługą usługi Arc, aby uwzględnić odpowiednie rozmiary magazynu dla danych, dzienników, dziennikówdanych i kopii zapasowych. Jeśli planujesz pojemność, aby uwzględnić zarówno bieżące potrzeby, jak i przewidywany wzrost dla wszystkich baz danych, które będą żyć w wystąpieniach SQL Managed Instance z obsługą usługi Arc, uniemożliwia to zmianę rozmiaru kontrolerów PVC w przyszłości. Wybierz oddzielne dyski fizyczne dla danych i dzienników danych , aby zezwolić na równoległe działanie we/wy. Równoległe działanie we/wy zwiększa wydajność, unikając możliwej rywalizacji spowodowanej użyciem dysku udostępnionego.

Chociaż istnieje kilka czynników, które mogą dyktować wdrożenie Krytyczne dla działania firmy lub Ogólnego przeznaczenia warstwie SQL Managed Instance z obsługą usługi Arc, Krytyczne dla działania firmy użycie magazynu lokalnego zapewnia najniższe opóźnienie i najwyższą dostępność. Zapoznaj się z obszarem projektowania ciągłości działania usługi Arc z obsługą SQL Managed Instance usługi Arc, aby zapoznać się z zaleceniami dotyczącymi przywracania do punktu w czasie, wysokiej dostępności i odzyskiwania po awarii. Ponadto zapoznaj się z obszarem projektowania zarządzania kosztami z obsługą usługi Arc SQL Managed Instance, aby dowiedzieć się więcej na temat wpływu kosztów między warstwami.

Poniższe podsekcje zawierają bardziej szczegółowe zalecenia dotyczące każdej warstwy:

zalecenia dotyczące warstwy usług Ogólnego przeznaczenia

Zaleca się wybranie zdalnej klasy StorageClass z małym opóźnieniem dla woluminów trwałych danych i dzienników danych w celu uzyskania optymalnej wydajności. Unikaj używania klasy StorageClass, która wprowadza partycje sieciowe, takie jak posiadanie klastra lokalnego skonfigurowanego do używania udostępnionej przez Internet klasy StorageClass dla woluminówtrwałych kopii zapasowych i dzienników.

zalecenia dotyczące warstwy usług Krytyczne dla działania firmy

Zaleca się zapoznanie się z różnicami w trybie dostępności, które będą wymagać innej konfiguracji dla każdego wybranego trybu.

W przypadku scenariuszy dotyczących najniższych możliwych opóźnień wybierz magazyn lokalny, jeśli jest to opcja dla infrastruktury Kubernetes. Lokalne woluminy magazynu powinny znajdować się na różnych podstawowych urządzeniach magazynujących, aby uniknąć rywalizacji o we/wy dysku i zmaksymalizować wydajność. Urządzenie magazynujące nie powinno mieć wielu funkcji, takich jak hostowanie partycji systemu operacyjnego.

W przypadku obciążeń intensywnie korzystających z odczytu i wysokiej dostępności należy skonfigurować wiele replik i skonfigurować aplikacje lub klientów do używania replik pomocniczych jako wystąpień odczytu Scale-Out. Repliki pomocnicze nie są domyślnie czytelne; można skonfigurować ustawienie.

Monitorowanie

Zaleca się monitorowanie wszystkich kontrolerów PVC utworzonych przez usługi danych z obsługą usługi Arc, w tym kontrolera danych usługi Azure Arc i wszystkich wystąpień SQL Managed Instance z obsługą usługi Arc w klastrze. Ustaw alerty, aby otrzymywać powiadomienia, gdy pvc zbliża się do niemal pojemności. Powiadomienie umożliwia zmianę rozmiaru PVC przed osiągnięciem pojemności. W przypadku klastrów połączonych bezpośrednio monitorowanie serwerów PVC i alertów odbywa się przez usługę Azure Monitor i usługę Container Insights. W przypadku korzystania z klastrów połączonych pośrednich wykonaj monitorowanie i alerty w narzędziach Grafana i Kibana. Instalacja narzędzia Grafana obejmuje pulpity nawigacyjne dla metryk SQL Managed Instance z obsługą usługi Arc i zasobów platformy Kubernetes.

Zapoznaj się z dziedzinami zapewniania ładu SQL Managed Instance z obsługą usługi Arc, aby uzyskać więcej zaleceń dotyczących monitorowania SQL Managed Instance z obsługą usługi Arc.

Następne kroki

Aby uzyskać więcej informacji na temat podróży do chmury hybrydowej i wielochmurowej, zobacz następujące artykuły: