Wskazówki dotyczące linii bazowej operacji dla usługi Azure Red Hat OpenShift

Usługa Azure Red Hat OpenShift zapewnia wysoce skalowalne, w pełni zarządzane klastry OpenShift na żądanie. Dzięki prawidłowemu zaprojektowaniu rozwiązania z myślą o zarządzaniu i monitorowaniu możesz pracować nad doskonałością operacyjną i sukcesem klientów.

Zagadnienia dotyczące projektowania

Rozważ następujące czynniki:

• Zapoznaj się z macierzą odpowiedzialności usługi Azure Red Hat OpenShift , aby dowiedzieć się, jak obowiązki klastrów są współdzielone między firmą Microsoft, firmą Red Hat i klientami.
• Należy pamiętać o limitach maszyn wirtualnych platformy Azure i obsługiwanych regionach. Upewnij się, że dostępna jest pojemność do wdrażania zasobów.
• Należy pamiętać o sposobach logicznego izolowania obciążeń w klastrze i fizycznie w oddzielnych klastrach.
• Należy pamiętać o sposobach, aby ułatwić platformie Kubernetes zrozumienie kondycji obciążeń.
• Należy pamiętać o różnych rozmiarach maszyn wirtualnych i wpływie używania jednego lub drugiego.
• Należy pamiętać o sposobach monitorowania i rejestrowania usługi Azure Red Hat OpenShift, aby uzyskać wgląd w kondycję zasobów i przewidzieć potencjalne problemy. Zarówno klaster, jak i aplikacje uruchomione na górze mogą generować wiele zdarzeń. Użyj alertów, aby ułatwić rozróżnienie wpisów dziennika w celach historycznych i wpisów wymagających natychmiastowej akcji.
• Należy pamiętać o ważnych aktualizacjach i uaktualnieniach systemu. Aktualizacje poprawek krytycznych są stosowane do klastrów automatycznie przez inżynierów niezawodności lokacji usługi Azure Red Hat OpenShift (SRE). Klienci, którzy chcą z wyprzedzeniem instalować aktualizacje poprawek, mogą to zrobić.
• Należy pamiętać o ograniczeniach zasobów klastra i poszczególnych obciążeń.
• Należy pamiętać o różnicach między skalowaniem automatycznym zasobnika poziomego a skalowaniem automatycznym klastra.
• Przejrzyj cykl życia pomocy technicznej i zapoznaj się z zasadami pomocy technicznej dotyczącymi wersji. Usługa Azure Red Hat OpenShift obsługuje tylko bieżące i poprzednie ogólnie dostępne wersje pomocnicze platformy Red Hat OpenShift Container Platform. Żądania pomocy technicznej wymagają, aby klaster był w obsługiwanej wersji.
• Przejrzyj wymagania dotyczące konfiguracji klastra , aby zachować możliwość obsługi klastra.
• Przejrzyj sieć między nazwami, aby zabezpieczyć ruch w klastrze przy użyciu zasad sieciowych.

Zalecenia dotyczące projektowania

• Usługa Azure Red Hat OpenShift ma bogaty ekosystem operatorów i powinna być używana do wykonywania i automatyzowania działań operacyjnych z wydajnością i dokładnością.
• Dodaj sondy kondycji do zasobników, aby monitorować kondycję aplikacji. Upewnij się, że zasobniki zawierają wartość livenessProbe i gotowośćProbe. Użyj sond startowych, aby określić punkt, w którym aplikacja została uruchomiona.
• Użyj rozmiarów maszyn wirtualnych, które są wystarczająco duże, aby zawierać wiele wystąpień kontenera, dzięki czemu można uzyskać korzyści ze zwiększonej gęstości, ale nie tak duże, że klaster nie może obsłużyć obciążenia węzła zakończonego niepowodzeniem.
• Regulowanie funkcji klastra przy użyciu wtyczek wstępu, które są często używane do wymuszania zasad zabezpieczeń, ograniczeń zasobów lub wymagań dotyczących konfiguracji.
• Użyj żądań zasobników i limitów, aby zarządzać zasobami obliczeniowymi w klastrze. Żądania zasobników i limity informują harmonogram Kubernetes, który przypisuje zasoby obliczeniowe do zasobnika. Ogranicz użycie zasobów w projekcie przy użyciu zakresów limitów.
• Zoptymalizuj wartości żądań procesora i pamięci oraz zmaksymalizuj wydajność zasobów klastra przy użyciu automatycznego skalowania pionowego zasobnika zasobnika.
• Konsola internetowa platformy OpenShift zawiera wszystkie metryki na poziomie węzła. Ustanów proces monitorowania przy użyciu wbudowanej integracji rozwiązania Prometheus lub Container Insights.
  • Rozwiązanie Prometheus jest wstępnie zainstalowane i skonfigurowane dla klastrów Usługi Azure Red Hat OpenShift 4.x.
  • Usługę Container Insights można włączyć, dołączając klaster do platformy Kubernetes z włączoną usługą Azure Arc.
  • Rejestrowanie openShift wdraża agregatory dzienników, magazyn i składniki wizualizacji.
• Automatyzowanie procesu dostarczania aplikacji za pomocą rozwiązań DevOps i rozwiązań ciągłej integracji/ciągłego wdrażania, takich jak Pipelines/GitOps dostarczone przez platformę kontenera OpenShift.
• Zdefiniuj klasterAutoScaler i MachineAutoScaler, aby skalować maszyny, gdy klaster zabraknie zasobów w celu obsługi większej liczby wdrożeń.
• Wdrażanie kontroli kondycji maszyny w celu automatycznego naprawiania uszkodzonych maszyn w puli maszyn.
• Skaluj zasobniki, aby sprostać zapotrzebowaniu przy użyciu narzędzia do automatycznego skalowania zasobników w poziomie.
• Użyj systemu alertów, aby zapewnić powiadomienia, gdy elementy wymagają bezpośredniej akcji: alerty metryk usługi Container Insights lub wbudowany interfejs użytkownika alertów.

Ciągłość biznesowa i odzyskiwanie po awarii (BCDR)

Twoja organizacja musi zaprojektować odpowiednie możliwości platformy Azure Red Hat OpenShift, aby spełnić określone wymagania. Te usługi aplikacji mają wymagania dotyczące celu czasu odzyskiwania (RTO) i celu punktu odzyskiwania (RPO). Istnieje wiele zagadnień, które należy wziąć pod uwagę podczas odzyskiwania po awarii. Pierwszym krokiem jest zdefiniowanie umowy dotyczącej poziomu usług (SLA) dla infrastruktury i aplikacji. Dowiedz się więcej o umowie SLA dla usługi Azure Red Hat OpenShift. Aby uzyskać informacje o miesięcznych obliczeniach czasu pracy, zobacz sekcję Szczegóły umowy SLA .

Zagadnienia dotyczące projektowania dla bcDR

Rozważ następujące czynniki:

• Klaster Usługi Azure Red Hat OpenShift powinien używać wielu zestawów maszyn, aby zapewnić minimalny poziom dostępności aplikacji.
• Ustawianie żądań zasobników i limitów. Ustawienie tych limitów umożliwia platformie Kubernetes:
  • Wydajne przypisywanie zasobów procesora CPU i pamięci do zasobników.
  • Mają większą gęstość kontenera w węźle.
  • Zwiększ niezawodność dzięki obniżonym kosztom ze względu na lepsze wykorzystanie sprzętu.
• Rozłóż węzły we wszystkich dostępnych strefach, aby uzyskać wyższą dostępność.
  • Wybierz region obsługujący Strefy dostępności.
  • Aby uzyskać pełną korzyść strefową, wszystkie zależności usług muszą również obsługiwać strefy. Jeśli usługa zależna nie obsługuje stref, możliwe, że awaria strefy może spowodować niepowodzenie tej usługi. Zapoznaj się z typami dysków używanymi podczas rozmieszczania obciążenia między strefami.
  • Aby zapewnić wyższą dostępność poza Strefy dostępności, uruchom wiele klastrów w różnych sparowanych regionach. Jeśli zasób platformy Azure obsługuje nadmiarowość geograficzną, podaj lokalizację, w której usługa nadmiarowa będzie miała swój region pomocniczy.
• Spójne tworzenie kopii zapasowych dla aplikacji i danych.
  • Usługa niestanowa może być wydajnie replikowana.
  • Jeśli musisz przechowywać stan w klastrze, wykonaj kopię zapasową danych często w sparowanym regionie.
• Uaktualnij i zachowaj klastry.
  • Zawsze aktualizuj klaster. Sprawdź uaktualnienia klastra.
  • Należy pamiętać o procesie wydawania i wycofywania.
  • Kontrolowanie uaktualnień za pomocą harmonogramów.
  • Zapoznaj się z potrzebą aktualizacji wdrożenia kanarzy dla obciążeń krytycznych.
• W przypadku łączności sieciowej w przypadku przejścia w tryb failover:
  • Jeśli musisz dystrybuować ruch między regionami, rozważ użycie usługi Azure Front Door.
• W przypadku planowanych i nieplanowanych trybów failover:
  • Podczas konfigurowania każdej usługi platformy Azure wybierz funkcje, które obsługują odzyskiwanie po awarii. Jeśli na przykład wybrano Azure Container Registry, włącz ją na potrzeby replikacji geograficznej. Jeśli region ulegnie awarii, nadal możesz ściągać obrazy z zreplikowanego regionu.
• Zachowaj możliwości inżynieryjne metodyki DevOps, aby osiągnąć cele na poziomie usługi.

Zalecenia dotyczące projektowania dla bcDR

Poniżej przedstawiono najlepsze rozwiązania dotyczące projektu:

• Klastry usługi Azure Red Hat OpenShift są aprowizowane za pomocą trzech węzłów płaszczyzny sterowania i trzech lub większej liczby węzłów roboczych. Upewnij się, że klaster jest tworzony w regionie obsługującym Strefy dostępności, aby węzły były rozmieszczone w różnych strefach.
• Aby zapewnić wysoką dostępność, wdróż te węzły w różnych Strefy dostępności. Ponieważ potrzebujesz różnych zestawów maszyn dla każdej strefy dostępności, utwórz co najmniej trzy zestawy maszyn.
• Nie uruchamiaj dodatkowych obciążeń w węzłach płaszczyzny sterowania. Chociaż można je zaplanować na węzłach płaszczyzny sterowania, spowoduje to dodatkowe użycie zasobów i problemy ze stabilnością, które mogą mieć wpływ na cały klaster.
• Tworzenie zestawów maszyn infrastruktury do przechowywania składników infrastruktury. Zastosuj określone etykiety kubernetes do tych maszyn, a następnie zaktualizuj składniki infrastruktury, aby były uruchamiane tylko na tych maszynach.
• Jeśli to możliwe, usuń stan usługi z wewnątrz kontenerów. Zamiast tego należy użyć platformy Azure jako usługi (PaaS), która obsługuje replikację wieloregionową.
• Wdrożenia powinny określać wymagania dotyczące zasobów zasobnika. Harmonogram może następnie odpowiednio zaplanować zasobnik. Niezawodność znacznie obniża się, gdy zasobniki nie są zaplanowane.
• Skonfiguruj wiele replik we wdrożeniu, aby obsługiwać zakłócenia, takie jak awarie sprzętowe. W przypadku planowanych zdarzeń, takich jak aktualizacje i uaktualnienia, budżet zakłóceń może zapewnić, że istnieje wymagana liczba replik zasobników do obsługi oczekiwanego obciążenia aplikacji.
• Ograniczeń topologii zasobników można używać do automatycznego planowania zasobników w węzłach w całym klastrze.
• Aplikacje mogą używać magazynu dla swoich danych i w razie potrzeby zapewnić dostępność między regionami:
  • Używanie magazynu RWX z wbudowaną klasą magazynu Azure Files.
  • Używanie sterowników CSI do aprowizacji magazynu.
• Utwórz kopię zapasową aplikacji i zaplanuj przywracanie:
  • Uwzględnij woluminy trwałe w kopii zapasowej.
• Szacowanie limitów zasobów zasobnika. Przetestuj i ustanów punkt odniesienia. Zacznij od równych wartości dla żądań i limitów. Następnie stopniowo dostrajaj te wartości do momentu ustanowienia progu, który może spowodować niestabilność w klastrze. Limity zasobników można określić w manifestach wdrożenia. Narzędzie do automatycznego skalowania zasobników w pionie optymalizuje wartości żądań procesora i pamięci i może zmaksymalizować wydajność zasobów klastra.
  • Wbudowane funkcje mogą obsługiwać błędy i zakłócenia w architekturze usługi. Te konfiguracje ułatwiają zarówno projektowanie, jak i automatyzację wdrażania. Gdy organizacja definiuje standard dla umowy SLA, celu czasu odzyskiwania i celu punktu odzyskiwania, może używać usług wbudowanych w platformę Kubernetes i platformę Azure, aby osiągnąć cele biznesowe.
• Rozważ strategie niebieskie/zielone lub kanary, aby wdrożyć nowe wersje aplikacji.
• Ustaw budżety zakłóceń pod priorytetem/zasobnika, aby ograniczyć liczbę replik zasobników, które klaster może zdjąć na potrzeby operacji konserwacji, zapewniając dostępność.
• Wymuszanie przydziałów zasobów w przestrzeniach nazw usługi. Limit przydziału zasobów w przestrzeni nazw zapewni prawidłowe ustawienie żądań zasobników i limitów we wdrożeniu.
  • Ustawianie limitów przydziału zasobów na poziomie klastra może powodować problemy podczas wdrażania usług partnerskich, które nie mają odpowiednich żądań i limitów.
• Zapisz obrazy kontenerów w Azure Container Registry i zreplikuj rejestr geograficznie do każdego regionu.
• Użyj wielu regionów i lokalizacji komunikacji równorzędnej na potrzeby łączności usługi Azure ExpressRoute . Jeśli wystąpi awaria wpływająca na region platformy Azure lub lokalizację dostawcy komunikacji równorzędnej, nadmiarowa architektura sieci hybrydowej może pomóc zapewnić nieprzerwaną łączność między lokalizacjami.
• Połącz regiony z globalną komunikacją równorzędną sieci wirtualnych. Jeśli klastry muszą komunikować się ze sobą, połączenie obu sieci wirtualnych ze sobą można osiągnąć za pośrednictwem komunikacji równorzędnej sieci wirtualnych. Ta technologia łączy ze sobą sieci wirtualne w celu zapewnienia wysokiej przepustowości w sieci szkieletowej firmy Microsoft, nawet w różnych regionach geograficznych.
• Użyj podzielonego protokołu emisji opartego na protokole TCP usługi Azure Front Door, aby szybko połączyć użytkowników końcowych z najbliższym punktem POP usługi Front Door (punktem obecności). Więcej funkcji usługi Azure Front Door obejmuje:
  • Zakończenie szyfrowania TLS
  • Domena niestandardowa
  • Web Application Firewall
  • Regenerowanie adresów URL
  • Koligacja sesji

Następne kroki

Dowiedz się więcej na temat zagadnień projektowych i zaleceń dotyczących automatyzacji platformy i metodyki DevOps w strefach docelowych platformy Azure.