Zagadnienia dotyczące ciągłości działania i odzyskiwania po awarii w systemie Red Hat Enterprise Linux na platformie Azure
W tym artykule opisano, jak poprawić gotowość ciągłości działania i odzyskiwania po awarii (BCDR) dla środowiska opartego na systemie Red Hat Enterprise Linux (RHEL) na platformie Azure. Zawiera on zalecenia, których można użyć do obsługi obciążeń RHEL i wdrażania składników zarządzania platformą RHEL. Subskrypcja usługi Red Hat Management zawiera składniki platformy, które ułatwiają zarządzanie obciążeniami w co najmniej jednej strefie docelowej RHEL. Te składniki oferują własne konfiguracje BCDR.
Uwagi dotyczące projektowania
Zaimplementuj następujące zagadnienia, aby zwiększyć odporność obciążeń RHEL.
Cele czasu odzyskiwania
Cel czasu odzyskiwania (RTO) to czas, przez jaki system powinien zostać odzyskany do stanu pierwotnego po awarii. Cel czasu odzyskiwania obejmuje czas potrzebny na:
- Przywróć minimalną funkcjonalność maszyn wirtualnych i aplikacji.
- Przywracanie danych, których wymagają aplikacje.
W kategoriach biznesowych cel czasu odzyskiwania reprezentuje czas, przez jaki procesy biznesowe są poza usługą. Niski cel czasu odzyskiwania jest idealny dla obciążeń o znaczeniu krytycznym, dzięki czemu procesy biznesowe mogą szybko wznowić działanie. W przypadku obciążeń o niższym priorytcie wyższy cel czasu odzyskiwania może nie mieć zauważalnego wpływu na wydajność firmy.
Cele punktu odzyskiwania
Aby pomyślnie obsługiwać środowisko chmury, należy zaimplementować kopie zapasowe, replikację lub obie te elementy, aby chronić dane przed awariami. Cel punktu odzyskiwania (RPO) odnosi się do ostatniego przechwycenia danych. W przypadku awarii systemu można przywrócić go tylko do ostatniego punktu odzyskiwania.
Mierzysz cel punktu odzyskiwania z ostatniego punktu odzyskiwania do czasu wystąpienia awarii. Jeśli zmierzysz cel punktu odzyskiwania w godzinach, awaria systemu spowoduje utratę danych przez godziny między ostatnim punktem odzyskiwania a awarią. Jeśli zmierzysz cel punktu odzyskiwania w dniach, awaria systemu spowoduje utratę danych przez dni między ostatnim punktem odzyskiwania a awarią. Jednorazowy cel punktu odzyskiwania teoretycznie powoduje utratę wszystkich transakcji w ciągu dnia, który prowadzi do awarii.
W przypadku systemów o znaczeniu krytycznym należy zmierzyć cel punktu odzyskiwania w minutach lub sekundach, aby uniknąć utraty przychodów lub zysków. Krótki cel punktu odzyskiwania zwykle powoduje zwiększenie kosztów zarządzania. Aby zmniejszyć te koszty, należy utworzyć punkt odniesienia zarządzania, który koncentruje się na najdłuższym akceptowalnym celu punktu odzyskiwania. Następnie można zmniejszyć cel punktu odzyskiwania dla określonych platform lub obciążeń, które uzasadniają większą inwestycję.
Zagadnienia związane z procesem BCDR obciążenia
Zagadnienia dotyczące projektowania wysokiej dostępności i odzyskiwania po awarii dla obciążeń opartych na systemie RHEL zależą od technologii obsługujących te obciążenia. Wiele nowoczesnych obciążeń może korzystać z natywnych usług platformy Azure w celu zapewnienia nadmiarowości w różnych strefach dostępności i w różnych regionach. Usługi platformy Azure umożliwiają zarządzanie replikacją danych, automatyczne skalowanie zestawów dostępności oraz kontrolowanie domen aktualizacji i błędów. Te rozwiązania ułatwiają zapewnienie dostępności wdrożeń systemu RHEL.
Rozwiązania bazy danych i inne aplikacje stanowe mogą wymagać rozwiązań zorientowanych na system operacyjny w celu zapewnienia wysokiej dostępności i odzyskiwania po awarii. Skontaktuj się z deweloperem aplikacji lub dostawcą, aby sprawdzić rozwiązania obsługiwane przez aplikacje. Aby uzyskać więcej informacji, zobacz Wysoka dostępność i odzyskiwanie po awarii dla aplikacji IaaS.
| Funkcja lub usługa platformy Azure | Definicja | Kwestie wymagające rozważenia |
|---|---|---|
| Regiony | Grupa centrów danych, które znajdują się blisko siebie, aby zapewnić małe opóźnienia sieci. Aby zapewnić szybki transfer danych, określona sieć regionalna łączy centra danych. | Po wybraniu regionu świadczenia usługi Azure należy wziąć pod uwagę lokalizację centrów danych, użytkowników i danych zaplecza. Sprawdź dostępność potrzebnych usług w wybranych regionach. W przypadku wdrożeń systemu RHEL może być potrzebny jeden region do uruchomienia, a następnie dodać więcej regionów w przyszłości do celów BCDR. |
| Azure ExpressRoute | Usługa platformy Azure, której można użyć do nawiązywania prywatnych połączeń z centrów danych firmy Microsoft do własnej infrastruktury lub do kolokacji. | Usługa ExpressRoute pomija publiczny Internet i zapewnia dedykowane połączenie prywatne. Ta konfiguracja jest typowym wymaganiem dla wdrożeń RHEL na dużą skalę. Usługa ExpressRoute jest usługą udostępnioną, więc musisz dokładnie zaplanować pojemność przepustowości, aby zaspokoić ogólne potrzeby dotyczące przepustowości przedsiębiorstwa. Jeśli masz niewystarczającą przepustowość, możesz naruszyć środowisko użytkownika lub dostęp do krytycznych usług w centrum danych. Upewnij się, że usługa ExpressRoute jest wdrażana w sposób odporny na awarie w różnych regionach i lokalizacjach komunikacji równorzędnej. |
| Strefy dostępności | Oddzielne grupy centrów danych, które mają własne systemy zasilania, chłodzenia i sieci w regionie świadczenia usługi Azure. Strefy dostępności zapewniają wysoką dostępność i odporność na awarie centrum danych. | Aby zapewnić wysoką umowę dotyczącą poziomu usług (SLA), użyj stref dostępności z infrastrukturą RHEL, jeśli jest to możliwe. Strefy dostępności oferują nadmiarowość centrum danych w regionie. Ale nie każdy region ma strefy dostępności, więc należy dokładnie zaplanować. Usługi RHEL, takie jak Azure Red Hat OpenShift i usługi zarządzania strefami docelowymi, obsługują strefy dostępności. |
| Zestawy dostępności | Logiczne grupowanie maszyn wirtualnych. Co najmniej jedna maszyna wirtualna jest zawsze uruchomiona podczas planowanych lub nieplanowanych zdarzeń konserwacji. Domena błędów jest podzbiorem zestawu dostępności, który współudzieli wspólną infrastrukturę fizyczną, taką jak zasilanie lub sieć. Podczas dystrybucji maszyn wirtualnych w różnych domenach błędów zestaw dostępności zmniejsza wpływ awarii sprzętu na dostępność maszyny wirtualnej. | Zestawy dostępności zapewniają wysoką umowę SLA. Zestawy dostępności są odpowiednie dla infrastruktury RHEL, gdy region nie ma stref dostępności. Zestawy dostępności mają tylko nadmiarowość sprzętową, która jest podobna do reguł ochrony przed koligacją funkcji hypervisor. Jeśli więc regiony nie mają stref dostępności, potrzebujesz strategii wieloregionowej dla centrum danych i nadmiarowości geograficznej. |
| Azure Load Balancer | Usługa równoważenia obciążenia sieciowego. Usługę Load Balancer można skonfigurować tak, aby zapewnić wydajny ruch sieciowy o dużej ilości na wielu serwerach Red Hat Enterprise. Usługa działa z małym opóźnieniem i wysoką przepływnością, co zwiększa wydajność i dostępność aplikacji. Moduł równoważenia obciążenia może automatycznie skalować zgodnie z zapotrzebowaniem. Aby promować wdrożenie hybrydowe aplikacji, usługa Load Balancer może dystrybuować ruch sieciowy między wieloma regionami na platformie Azure, a także między środowiskami lokalnymi i platformą Azure. |
Usługa Load Balancer dystrybuuje ruch sieciowy między wieloma serwerami, aby zapewnić nieprzerwaną dostępność aplikacji i zapobiec awariom pojedynczego punktu. W przypadku awarii usługa Load Balancer przekierowuje ruch do serwerów operacyjnych w celu zapewnienia szybkiego przejścia w tryb failover i odzyskiwania. Ta operacja minimalizuje przestoje i utrzymuje operacje biznesowe. Usługa Load Balancer może równoważyć ruch między serwerami lokalnymi w chmurze platformy Azure lub serwerami w wielu regionach świadczenia usługi Azure. Aby uzyskać więcej informacji, zobacz Opcje równoważenia obciążenia. |
| Dyski zarządzane | Zwirtualizowane dyski zarządzane przez platformę Azure. Należy wybrać rozmiar dysku i typ. Platforma Azure dystrybuuje dyski między różne jednostki magazynu, aby chronić dane przed awariami sprzętowymi. | Dyski zarządzane są najlepszym wyborem dla całej infrastruktury RHEL. Nie używaj dysków niezarządzanych. Aby uzyskać więcej informacji, zobacz Umowy SLA dotyczące maszyn wirtualnych. Różne typy dysków mają różną wydajność i koszty. W przypadku maszyn infrastruktury RHEL zalecamy użycie dysków SSD w warstwie Premium platformy Azure. Podczas wybierania typu dysku należy wziąć pod uwagę koszty, wydajność i dostępność. Po cofnięciu przydziału systemu lokalne dyski SSD i efemeryczne zostaną usunięte. W razie potrzeby wykonaj kopię zapasową danych na tych dyskach. |
| Azure Backup | Usługa, która zapewnia ekonomiczne rozwiązania do tworzenia kopii zapasowych danych i odzyskiwania ich z chmury platformy Azure. | Tworzenie kopii zapasowych to niezawodne i ekonomiczne rozwiązanie, które chroni infrastrukturę RHEL przed awarią lub uszkodzeniem maszyny wirtualnej. Użyj funkcji Kopia zapasowa, aby łatwo przywrócić całą maszynę wirtualną lub określone pliki i foldery z chmury bez konieczności ponownego tworzenia maszyny wirtualnej ani utraty danych. Możesz również użyć innych obsługiwanych rozwiązań partnerskich. |
| Azure Arc | Platforma, która rozszerza usługi platformy Azure tak, aby były uruchamiane w różnych środowiskach, w tym w centrach danych, urządzeniach brzegowych i architekturach wielochmurowych. Usługa Azure Arc umożliwia spójne programowanie, operacje i zarządzanie zabezpieczeniami dla aplikacji i usług. | Usługa Azure Arc umożliwia zaimplementowanie scentralizowanych automatycznych kopii zapasowych i monitorowania, co zwiększa odporność z perspektywy BCDR. |
| Azure Site Recovery | Usługa, która zapewnia możliwości odzyskiwania po awarii w celu zapewnienia ciągłości działania. Obciążenia, w tym maszyny wirtualne platformy Azure i lokalne maszyny wirtualne, można replikować i zarządzać nimi w różnych regionach. Za pomocą usługi Site Recovery można skonfigurować procesy replikacji, trybu failover i odzyskiwania w celu ochrony aplikacji podczas planowanych awarii i nieplanowanych awarii. | Użyj usługi Site Recovery, aby zminimalizować problemy z odzyskiwaniem, zmniejszyć koszty infrastruktury i zapewnić bezpieczne i zależne odzyskiwanie między regionami platformy Azure lub lokalizacjami lokalnymi na platformę Azure. |
| Blokady zasobów | Funkcja platformy Azure, której można użyć do ograniczania użytkowników i ról w organizacji. Ochrona krytycznych zasobów przed przypadkowymi lub złośliwymi zmianami. Zasób można zablokować na różnych poziomach zakresu, takich jak subskrypcja, grupa zasobów lub poszczególne poziomy zasobów. W zależności od typu blokady można uniemożliwić użytkownikom usuwanie lub modyfikowanie zasobu, ale nadal mogą odczytywać jego konfigurację. | Aby chronić całą infrastrukturę RHEL i złote maszyny wirtualne obrazu, użyj blokad zasobów. Aby zapobiec przypadkowemu utracie ważnych maszyn, zastosuj blokadę Usuń co najmniej. Zastosuj blokadę ReadOnly do maszyn infrastruktury RHEL, ponieważ nie zmieniają się one często. Wprowadzaj zmiany tylko w odpowiednich oknach sterowania zmianami. |
Zagadnienia dotyczące bcDR platformy RHEL
Aby uzyskać więcej informacji na temat możliwości BCDR dla infrastruktury platformy RHEL, zobacz:
- Architektura wysokiej dostępności satelitarnej.
- Architektura wysokiej dostępności platformy Ansible Automation.
- Architektura wysokiej dostępności zarządzania tożsamościami.
Zalecenia dotyczące projektowania
W przypadku aplikacji natywnych dla chmury w kontenerach systemu Linux użyj platformy opartej na platformie Kubernetes, aby zapewnić skalowalność, wysoką dostępność i nadmiarowość. Rozważ użycie platformy Azure Red Hat OpenShift lub własnego wdrożenia openShift z replikowanym lub zreplikowanym geograficznie magazynem.
W przypadku natywnych frontonów aplikacji internetowych i aplikacji bezstanowych można użyć wielu usług natywnych dla platformy Azure, które zapewniają dostępność aplikacji. W przypadku architektur korzystających z takich usług zobacz:
- Podstawowa wysoce dostępna strefowo nadmiarowa aplikacja internetowa.
- Aplikacja internetowa o wysokiej dostępności w wielu regionach.
Powyższe architektury używają różnych usług platformy Azure dla stref dostępności. Architektura wieloregionowa używa funkcji replikacji geograficznej dla zawartości i usługi Azure Front Door jako usługi równoważenia obciążenia.
W przypadku wielu tradycyjnych aplikacji stanowych wymagających wysokiej dostępności system RHEL oferuje dodatek Pacemaker o wysokiej dostępności. Możesz uzyskać systemy, które mają tę funkcję z witryny Azure Marketplace, lub wdrożyć obraz niestandardowy z osadzonymi wymaganymi składnikami oprogramowania. Aby uzyskać więcej informacji, zobacz Konfigurowanie klastra wysokiej dostępności oprogramowania Red Hat na platformie Microsoft Azure.
Problemy z dostępnością wpływają na przerwy w działaniu usługi i czasy odpowiedzi usługi. Może wystąpić obniżenie poziomu usług, co może obniżyć wydajność obsługi klienta. Aby zapewnić utrzymanie poziomów wydajności i wystarczającej pojemności w wymaganych regionach, użyj funkcji rezerwacji pojemności na żądanie platformy Azure.
Niezawodność
Wiele pojęć, które mają zastosowanie do infrastruktury jako infrastruktury maszyn wirtualnych usługi, ma również zastosowanie do architektur RHEL. Aby uzyskać więcej informacji, zobacz Zasady projektowania niezawodności.
Klastry
Platforma Azure nie obsługuje łączenia usług centralnych serwera aplikacji i wysokiej dostępności bazy danych w ramach jednego klastra programu Pacemaker RHEL. Aby rozwiązać ten problem, należy podzielić je na poszczególne klastry. W parze maszyn wirtualnych można połączyć maksymalnie pięć klastrów usług centralnych.
W przypadku bcDR on SAP należy wziąć pod uwagę następujące usługi do uruchamiania klastrów usług centralnych SAP:
- Klaster RHEL Pacemaker: urządzenia blokowe STONITH nie są obsługiwane, ale można polegać na agencie ogrodzenia platformy Azure.
- Oprogramowanie klastra spoza firmy Microsoft z certyfikatem SAP: zapoznaj się z tą opcją, jeśli jest zgodna z wymaganiami.
Wybierz odpowiednią usługę na podstawie konkretnych potrzeb i systemu operacyjnego.
Aby uzyskać więcej informacji, zobacz:
- Skonfiguruj klaster wysokiej dostępności oprogramowania Red Hat na platformie Microsoft Azure dla systemu RHEL 9.
- Konfigurowanie klastrów wysokiej dostępności dla systemu RHEL 9 i zarządzanie nimi.
- Dokumentacja systemu RHEL 8.
Repliki z galerii obliczeń platformy Azure
Za pomocą galerii obliczeniowej można przechowywać złote obrazy na potrzeby wdrożeń. Użyj tych obrazów do odzyskiwania po awarii aplikacji i narzędzi. Galeria obliczeniowa może używać zasobów o wysokiej dostępności z kontami magazynu strefowo nadmiarowego (ZRS) w regionach obsługujących strefy dostępności. Magazyn ZRS zapewnia odporność na błędy strefowe. Obrazy galerii można również replikować do innych regionów lub lokalizacji geograficznych.
Uwaga
Zalecamy posiadanie co najmniej dwóch galerii w różnych regionach.
Site Recovery
Usługa Site Recovery może zwiększyć odporność niektórych składników RHEL. Aby uzyskać listę obsługiwanych serwerów odzyskiwania lokacji RHEL, zobacz Macierz obsługi odzyskiwania po awarii maszyny wirtualnej platformy Azure za pomocą usługi Site Recovery. Usługę Site Recovery można również skonfigurować jako tryb failover ze środowisk lokalnych do chmury. Aby uzyskać oszacowanie kosztów usługi Site Recovery, użyj planisty wdrożenia usługi Site Recovery.
Węzły klastra odzyskiwania
Aby zmniejszyć liczbę obiektów RTO i zwiększyć odporność, możesz użyć aktywnych lub rezerwowych węzłów klastra odzyskiwania zdalnego. Elementy klastra odzyskiwania po awarii należy skonfigurować ręcznie. Na przykład należy zastosować konfiguracje, aby skonfigurować zasoby i skopiować dane.