Udostępnij przez

Omówienie wdrażania bazy danych PostgreSQL o wysokiej dostępności w usłudze Azure Kubernetes Service (AKS)

W tym przewodniku wdrożysz klaster PostgreSQL o wysokiej dostępności obejmujący wiele stref dostępności platformy Azure w usłudze AKS za pomocą interfejsu wiersza polecenia platformy Azure.

W tym artykule przedstawiono wymagania wstępne dotyczące konfigurowania klastra PostgreSQL w usłudze Azure Kubernetes Service (AKS) oraz omówienie pełnego procesu wdrażania i architektury.

Ważne

Oprogramowanie typu open source jest wymienione w dokumentacji i przykładach usługi AKS. Wdrażane oprogramowanie jest wykluczone z umów dotyczących poziomu usług AKS, ograniczonej gwarancji oraz wsparcia platformy Azure. W miarę korzystania z technologii open source wraz z usługą AKS zapoznaj się z opcjami pomocy technicznej dostępnymi w odpowiednich społecznościach i opiekunami projektów, aby opracować plan.

Firma Microsoft ponosi odpowiedzialność za tworzenie pakietów typu open source wdrażanych w usłudze AKS. Ta odpowiedzialność obejmuje posiadanie pełnej kontroli nad procesem kompilacji, skanowania, podpisywania, weryfikacji i szybkich poprawek, a także nad plikami binarnymi w obrazach kontenerów. Aby uzyskać więcej informacji, zobacz zarządzanie podatnościami dla AKS i zakres wsparcia dla AKS.

Wymagania wstępne

  • W tym przewodniku założono, że czytelnik posiada podstawową wiedzę na temat podstawowych koncepcji Kubernetes i bazy danych PostgreSQL.
  • Potrzebujesz ról wbudowanych platformy Azure: właściciela lub Administratora dostępu użytkownika oraz współautora, na subskrypcji w swoim koncie platformy Azure.

Proces wdrażania

Niniejszy przewodnik zawiera informacje na temat wykonywania następujących czynności:

  • Użyj interfejsu wiersza polecenia platformy Azure, aby utworzyć klaster usługi AKS z wieloma strefami.
  • Wdróż klaster i bazę danych PostgreSQL o wysokiej dostępności przy użyciu operatora CNPG.
  • Konfigurowanie monitorowania bazy danych PostgreSQL przy użyciu rozwiązań Prometheus i Grafana.
  • Wdrażanie przykładowego zestawu danych w bazie danych PostgreSQL.
  • Wykonaj uaktualnienia klastrów PostgreSQL i AKS.
  • Symulacja przerwania klastra i przełączenia awaryjnego repliki PostgreSQL.
  • Wykonaj kopię zapasową i przywracanie bazy danych PostgreSQL.

Architektura wdrażania

Ten diagram przedstawia konfigurację klastra PostgreSQL z jedną repliką podstawową i dwie repliki do odczytu zarządzane przez operator CloudNativePG (CNPG). Architektura zapewnia wysoce dostępny PostgreSQL działający w klastrze AKS, który może wytrzymać awarię strefy, wykonując failover między replikami.

Kopie zapasowe są przechowywane w usłudze Azure Blob Storage, zapewniając inny sposób przywracania bazy danych w przypadku problemu z replikacją strumieniową z repliki podstawowej.

Możesz zdecydować się na hostowanie bazy danych PostgreSQL w usłudze AKS, gdy potrzebujesz pełnej kontroli nad konfiguracją, rozszerzeniami i architekturą wdrażania bazy danych. Idealnie nadaje się do integracji z narzędziami natywnymi platformy Kubernetes, optymalizowania kosztów na dużą skalę i dostrajania wydajności za pomocą niestandardowych strategii alokacji zasobów, buforowania i konfiguracji magazynu dostosowanych do obciążenia.

Diagram architektury operatora Kubernetes CNPG na potrzeby samodzielnego hostowania bazy danych PostgreSQL o wysokiej dostępności w usłudze AKS.

Uwaga

W przypadku aplikacji wymagających separacji danych na poziomie bazy danych można dodać więcej baz danych za pomocą poleceń postInitSQL i podobnych. Obecnie nie można dodać większej liczby baz danych w sposób deklaratywny z operatorem CNPG. Dowiedz się więcej o operatorze CNPG.

Zagadnienia dotyczące magazynu

Typ używanego magazynu może mieć duży wpływ na wydajność bazy danych PostgreSQL. W dalszej części tego przewodnika wybierz opcję najlepiej dopasowaną do celów i potrzeb w zakresie wydajności.

Typ magazynu Zgodny sterownik Opis
SSD Premium Sterownik CSI Azure Disks Maksymalna odporność danych. Usługa Azure Premium SSD zapewnia magazyn o wysokiej wydajności i bezproblemowo współpracuje z magazynem strefowo nadmiarowym platformy Azure (ZRS). Dysk SSD w warstwie Premium jest aprowizowany na podstawie określonych rozmiarów, dla których dostępne są konkretne poziomy liczby operacji we/wy na sekundę oraz przepływności.
Premium SSD wersja 2 Sterownik CSI Azure Disks Najlepsza wydajność cenowa. Dyski SSD w warstwie Premium platformy Azure w wersji 2 oferują wyższą wydajność niż dyski SSD w warstwie Premium platformy Azure, a jednocześnie ogólnie są tańsze. W przeciwieństwie do dysków SSD w warstwie Premium, Premium SSD w wersji 2 nie ma dedykowanych rozmiarów. Możesz ustawić dysk SSD v2 Premium na dowolny obsługiwany rozmiar i dokonywać szczegółowych regulacji wydajności bez przestojów. Dyski SSD w warstwie Premium w wersji 2 platformy Azure mają pewne ograniczenia, o których należy pamiętać. Aby uzyskać pełną listę, zobacz Ograniczenia dotyczące dysków SSD w warstwie Premium w wersji 2.
Lokalne dyski NVMe lub ssd tymczasowe (dyski efemeryczne) Tylko usługa Azure Container Storage Maksymalna wydajność. Dyski efemeryczne są lokalnymi urządzeniami NVMe i tymczasowym magazynem SSD dostępnym w wybranych rodzinach maszyn wirtualnych. Oferują one największą możliwą liczbę operacji IO na sekundę, przepływność i opóźnienie na poziomie poniżej milisekundy dla twojego klastra AKS. Możesz także wykorzystać wysoką wydajność dysków tymczasowych, korzystając z usługi Azure Container Storage, zarządzanego rozwiązania dla Kubernetes, które dynamicznie przydziela trwałe woluminy dla stanowych obciążeń, takich jak PostgreSQL. Jednak ponieważ te dyski znajdują się na lokalnych maszynach wirtualnych hostujących klaster, dane nie są utrwalane w usłudze Azure Storage. W związku z tym wszystkie dane przechowywane na tych dyskach zostaną utracone, jeśli klaster zostanie zatrzymany lub odzwolniony. Aby rozwiązać ten problem, w kolejnych sekcjach tego przewodnika pokazano, jak skonfigurować okresowe kopie zapasowe danych PostgreSQL w usłudze Azure Blob Storage.

Następne kroki

Tworzenie infrastruktury bazy danych PostgreSQL

Współautorzy

Firma Microsoft utrzymuje ten artykuł. Następujący współautorzy pierwotnie to napisali:

  • Ken Kilty | Główny TPM
  • Russell de Pina | Główny Menedżer TPM
  • Adrian Joian | Starszy inżynier klienta
  • Jenny Hayes | Starszy deweloper zawartości
  • Carol Smith | Starszy deweloper zawartości
  • Erin Schaffer | Content Developer 2
  • Adam Sharif | Inżynier klienta 2

Potwierdzenie

Ta dokumentacja została opracowana wspólnie z bazą danych EnterpriseDB, opiekunami operatora CloudNativePG. Dziękujemy Gabriele Bartolini za przejrzenie wcześniejszych wersji tego dokumentu i oferowanie ulepszeń technicznych.

  • Last updated on