Planowanie pojemności przy użyciu usługi Azure Site Recovery
Jako organizacja konieczne jest wdrożenie strategii ciągłości działania i odzyskiwania po awarii (BCDR) zapewniającej bezpieczeństwo danych, dostępne aplikacje i obciążenia w trybie online podczas planowanych i nieplanowanych awarii.
Dzięki replikacji obciążeń maszyn wirtualnych z lokacji głównej do lokalizacji dodatkowej usługa Azure Site Recovery w usłudze Azure Stack Hub zapewnia usługi, które mogą obsługiwać bezpieczeństwo danych organizacji, dostępności aplikacji i obciążeń podczas awarii. Na przykład w przypadku wystąpienia awarii w lokacji głównej przełączenie w tryb failover do lokalizacji dodatkowej w celu uzyskania dostępu do aplikacji. Po ponownym uruchomieniu lokacji głównej można wrócić do niej po awarii. Aby uzyskać więcej informacji, zobacz About Site Recovery (Informacje o Site Recovery).
Aby włączyć replikację maszyn wirtualnych w dwóch sygnaturach usługi Azure Stack Hub, należy skonfigurować dwa środowiska:
- Środowisko źródłowe:
- Sygnatura usługi Azure Stack Hub, w której są uruchomione maszyny wirtualne dzierżawy.
- Środowisko docelowe:
- Gdzie jest uruchamiany dostawca zasobów usługi Azure Site Recovery.
Podstawowym składnikiem sukcesu planu ciągłości działania i odzyskiwania po awarii jest planowanie pojemności. Podczas planowania pojemności należy wziąć pod uwagę kilka czynników:
Cele czasu odzyskiwania (RTO) i cele punktu odzyskiwania (RPO) dla określonych obciążeń, które chcesz chronić.
Obciążenia i cechy aplikacji:
- Jak często dane zmieniają się na odpowiedniej maszynie wirtualnej.
- Ile danych jest generowanych lub usuwanych?
- Jak wygląda projekt aplikacji i nie tylko?
Rozmiary maszyn wirtualnych, liczba dysków i sposób, w jaki każda maszyna wirtualna jest powiązana z innymi maszynami wirtualnymi.
- W przypadku rozwiązań wymagających kilku maszyn wirtualnych należy poznać kolejność uruchamiania tych maszyn wirtualnych.
Przepustowość sieci między środowiskami źródłowymi i docelowymi. Ten składnik może mieć wpływ na obiekty żądań grupy.
Każdy z tych punktów jest ważny i ma szerokie konsekwencje podczas tworzenia planu BCDR.
W poniższych sekcjach wymieniono główne kwestie, które należy wziąć pod uwagę z perspektywy usługi Azure Site Recovery. Każdy plan BCDR jest inny i zależy od specyfiki obciążeń, które planujesz chronić. W związku z tym ta lista nie jest kompleksowa.
Zagadnienia dotyczące źródła
W środowisku źródłowym usługa Azure Stack Hub uruchamia urządzenie maszyny wirtualnej platformy Azure Site Recovery. Maszyna wirtualna to maszyna wirtualna Standard_DS4_v2 (8 procesorów wirtualnych, 28 Gb pamięci, 32 dysków danych) działająca w subskrypcji użytkownika usługi Azure Stack Hub.
W środowisku źródłowym należy wziąć pod uwagę następujące obszary:
Przydziału:
- Aby utworzyć urządzenie maszyny wirtualnej platformy Azure Site Recovery, musisz mieć wystarczający limit przydziału. Potrzebujesz co najmniej jednego planu, w zależności od ogólnego planu.
Magazyn dla urządzenia maszyny wirtualnej platformy Azure Site Recovery:
Samo urządzenie maszyny wirtualnej platformy Azure Site Recovery ma wymagania dotyczące danych zdefiniowane przez rozmiar maszyny wirtualnej.
Podczas planowania pojemności upewnij się, że maszyna wirtualna urządzenia ma wystarczającą ilość miejsca do wykonania operacji powrotu po awarii i ponownego włączenia ochrony.
Uwaga
Jeśli istnieją ograniczenia magazynu, powrót po awarii i ponowne włączenie ochrony może zakończyć się niepowodzeniem z powodu błędu Wystąpił wewnętrzny komunikat o błędzie . Użytkownicy powinni sprawdzić dzienniki zdarzeń na urządzeniu, aby potwierdzić rzeczywisty błąd usługi Azure Resource Manager. Aby uzyskać więcej informacji, zobacz Znane problemy dotyczące usługi Azure Site Recovery.
Przepustowość:
- Replikacja początkowa generuje wysokie użycie przepustowości.
- Zmiany na każdej maszynie wirtualnej są replikowane w zależności od zasad replikacji i każdego typu aplikacji.
Zagadnienia dotyczące celu
W środowisku docelowym należy wziąć pod uwagę dwa elementy dotyczące planowania pojemności:
Wymagania dotyczące usługi Azure Site Recovery: ile jest używane do uruchamiania usługi Azure Site Recovery bez konieczności ochrony obciążeń.
Wymagania dotyczące chronionych obciążeń.
Środowisko docelowe wymaga utworzenia jednego magazynu usługi Azure Site Recovery dla każdego urządzenia Site Recovery w celu ochrony maszyn wirtualnych ze źródła (jedno urządzenie na magazyn). Chociaż nie jest to ograniczenie z perspektywy pojemności, należy wziąć pod uwagę podczas planowania projektu ogólnego środowiska.
Zasoby usługi Azure Site Recovery RP
Instalacja usługi Azure Site Recovery w usłudze Azure Stack Hub wymaga zainstalowania dostawcy zasobów Site Recovery (RP).
Uwaga
W przypadku usługi Microsoft.SiteRecovery-1.2301.2216.2287 platforma Azure Site Recovery w usłudze Azure Stack Hub nie wymaga usługi Event Hubs jako zależności.
Ta usługa jest tworzona w ramach subskrypcji administracyjnej usługi Azure Stack Hub i zarządzana przez samą usługę Azure Stack Hub, dlatego nie jest wymagana żadna konfiguracja. Jednak podobnie jak w przypadku dowolnej usługi te zasoby zużywają pamięć, magazyn i mają przydzielone określone procesory wirtualne:
| Usługa | Rdzenie wirtualne | Memory (Pamięć) | Rozmiar dysku |
|---|---|---|---|
| Azure Site Recovery | 12 | 42 GB | 1,4 TB |
Uwaga
Te zasoby to usługi Azure Stack Hub po stronie administracyjnej usługi Azure Stack Hub. Po zainstalowaniu platforma zarządza tymi zasobami.
Chronione obciążenia robocze
Podczas tworzenia planu BCDR należy wziąć pod uwagę wszystkie aspekty chronionych obciążeń. Poniższa lista nie została ukończona i powinna być traktowana jako punkt początkowy:
Rozmiar maszyny wirtualnej, liczba dysków, rozmiar dysku, liczba operacji we/wy na sekundę, współczynnik zmian danych i utworzone nowe dane.
Zagadnienia dotyczące przepustowości sieci:
- Przepustowość sieci wymagana do replikacji różnicowej.
- Ilość przepływności w środowisku docelowym, którą platforma Azure Site Recovery może uzyskać ze środowiska źródłowego.
- Liczba maszyn wirtualnych, które mają być wsadowe naraz. Ta liczba jest oparta na szacowanej przepustowości do ukończenia replikacji początkowej w danym czasie.
- Cel punktu odzyskiwania, który można osiągnąć dla danej przepustowości.
- Wpływ na żądany cel punktu odzyskiwania, jeśli aprowizowana jest niższa przepustowość.
Zagadnienia dotyczące magazynu:
- Ile danych jest wymaganych do replikacji początkowej.
- Ile punktów odzyskiwania jest przechowywanych i jak zwiększa się ilość danych dla każdej chronionej maszyny wirtualnej w tych odstępach czasu.
- Ile przydziałów należy przypisać do docelowych subskrypcji użytkowników usługi Azure Stack Hub, aby użytkownicy mieli wystarczającą alokację.
- Konto magazynu pamięci podręcznej na potrzeby replikacji.
Zagadnienia dotyczące obliczeń:
- Po przejściu w tryb failover maszyny wirtualne są uruchamiane w docelowych subskrypcjach użytkowników usługi Azure Stack Hub. Aby można było uruchomić te zasoby maszyny wirtualnej, należy zastosować wystarczającą alokację przydziału.
- Podczas ochrony maszyny wirtualnej, gdy chroniona maszyna wirtualna jest aktywna w środowisku źródłowym, w środowisku docelowym nie są używane żadne zasoby związane z maszyną wirtualną, takie jak procesory wirtualne, pamięć itp. Te zasoby stają się istotne tylko podczas procesu pracy w trybie failover, takiego jak testowanie pracy w trybie failover.
Zakres usługi Azure Site Recovery w usłudze Azure Stack Hub zawiera punkt wyjścia do obliczeń, szczególnie w przypadku używanego konta magazynu pamięci podręcznej:
W przypadku przejścia w tryb failover podczas normalnych operacji należy pomnożyć liczbę dysków replikowanych przez średni cel punktu odzyskiwania. Na przykład może istnieć (2 MB * 250s). Konto magazynu pamięci podręcznej zwykle wynosi od 500 MB na dysk.
W przypadku przejścia w tryb failover, biorąc pod uwagę najgorszy scenariusz, pomnożyj liczbę dysków replikowanych przez średni cel punktu odzyskiwania w ciągu całego dnia.
Ważne
Jeśli niektóre części usługi Azure Site Recovery nie działają, ale inne działają, może istnieć co najwyżej jeden dzień różnic na koncie magazynu, zanim usługa Azure Site Recovery zdecyduje się na przekroczenie limitu czasu.
Powrót po awarii do nowej maszyny wirtualnej. Oblicz sumę rozmiaru dysków każdej partii.
- Cały dysk należy skopiować na konto magazynu pamięci podręcznej, aby docelowa maszyna wirtualna miała zastosowanie, ponieważ element docelowy jest pustym dyskiem.
- Skojarzone dane są usuwane po skopiowaniu, ale prawdopodobnie zobaczysz szczytowe użycie z sumą wszystkich rozmiarów dysków.
Utwórz plan BDCR na podstawie specyfiki rozwiązania, które próbujesz chronić.
W poniższej tabeli przedstawiono przykład testów uruchamianych w naszych środowiskach. Te szczegółowe informacje umożliwiają uzyskanie planu bazowego dla własnej aplikacji, ale każde obciążenie różni się:
Konfigurowanie
| Rozmiar bloku | Przepływność/dysk |
|---|---|
| 2 MB | 2 MB/s |
| 64 KB | 2 MB/s |
| 8 KB | 1 MB/s |
| 8 KB | 2 MB/s |
Wynik
| Liczba obsługiwanych dysków | Łączna przepływność | Łączna liczba operacji OPS | Wąskie gardło |
|---|---|---|---|
| 68 | 136 MB/s | 68 | magazyn |
| 60 | 120 MB/s | 2048 | magazyn |
| 28 | 28 MB/s | 3584 | Procesor i pamięć usługi Azure Site Recovery |
| 16 | 32 MB/s | 4096 |
Uwaga
8 Kb jest najmniejszym rozmiarem bloku danych obsługiwanego przez usługę Azure Site Recovery. Wszelkie zmiany mniejsze niż 8 Kb są traktowane jako 8 Kb.
Aby przeprowadzić dalsze testowanie, wygenerowaliśmy spójny typ obciążenia; na przykład spójne zmiany magazynu w blokach o rozmiarze 8 KB łącznie do 1 MB/s na dysk. Ten scenariusz nie jest prawdopodobnie w rzeczywistym obciążeniu, biorąc pod uwagę, że zmiany mogą wystąpić w różnych porach dnia lub w skokach o różnych rozmiarach.
Aby replikować te losowe wzorce, przetestowaliśmy również następujące scenariusze:
- 120 maszyn wirtualnych (80 Windows, 40 Linux) chronionych za pomocą tego samego urządzenia maszyny wirtualnej usługi Azure Site Recovery.
Każda maszyna wirtualna generująca losowe interwały, co najmniej dwa razy na godzinę, losowe bloki w sumie 5 Gb danych w pięciu plikach.
Replikacja powiodła się na wszystkich 120 maszynach wirtualnych z niskim do średnim obciążeniem w usługach Azure Site Recovery.
Uwaga
Te liczby powinny być używane tylko jako punkt odniesienia. Niekoniecznie skalują liniowo. Dodanie kolejnej partii tej samej liczby maszyn wirtualnych może mieć mniejszy wpływ niż początkowa. Wyniki są wysoce zależne od typu używanych obciążeń.
Jak planować i testować
Aplikacje i obciążenia rozwiązań mają określone wymagania celu czasu odzyskiwania (RTO) i celu punktu odzyskiwania (RPO). Efektywna ciągłość biznesowa i odzyskiwanie po awarii (BCDR, business continuity and disaster recovery) wykorzystują zarówno możliwości na poziomie platformy, które spełniają te wymagania, jak korzystamy z mechanizmów specyficznych dla rozwiązania. Aby zaprojektować możliwości bcDR, przechwyć wymagania odzyskiwania po awarii platformy i uwzględnić wszystkie te czynniki w projekcie:
Wymagania dotyczące dostępności aplikacji i danych:
- Wymagania dotyczące celu czasu odzyskiwania i celu punktu odzyskiwania dla każdego obciążenia.
- Obsługa wzorców dostępności aktywne-aktywne i aktywne-pasywne.
Obsługa wdrożeń w wielu regionach na potrzeby trybu failover z sąsiedztwem składników w celu zapewnienia wydajności. Podczas awarii mogą wystąpić operacje aplikacji z ograniczoną funkcjonalnością lub obniżoną wydajnością.
Uwaga
Aplikacja może wiedzieć, że jest uruchamiana natywnie lub ma pewne składniki, które mogą być uruchamiane w wielu środowiskach usługi Azure Stack Hub. W takim przypadku można użyć usługi Azure Site Recovery do replikowania tylko maszyn wirtualnych ze składnikami, które nie mają tej funkcji, na przykład rozwiązania typu frontonu lub zaplecza, w którym można wdrożyć frontony w środowiskach usługi Azure Stack Hub.
Unikaj używania nakładających się zakresów adresów IP w sieciach produkcyjnych i dr.
- Sieci produkcyjne i dr, które mają nakładające się adresy IP, wymagają procesu trybu failover, który może komplikować i opóźniać przejście aplikacji w tryb failover. Jeśli to możliwe, zaplanuj architekturę sieci BCDR, która zapewnia współbieżną łączność ze wszystkimi lokacjami.
Określanie rozmiaru środowisk docelowych:
- Jeśli używasz źródła i elementu docelowego w sposób 1:1, przydziel nieco więcej miejsca do magazynowania w środowisku docelowym. Wynika to ze sposobu, w jaki dzieje się historia zakładek dysków. Ta alokacja nie jest wzrostem 2 razy, ponieważ obejmuje tylko zmiany danych. W zależności od typu danych i oczekiwanych zmian, a zasady replikacji mają magazyn od 1,5x do 2x więcej miejsca w obiekcie docelowym, upewnij się, że procesy trybu failover nie mają żadnych problemów.
- Możesz rozważyć posiadanie docelowego środowiska usługi Azure Stack Hub jako elementu docelowego dla wielu źródeł usługi Azure Stack Hub. W takim przypadku obniżasz ogólny koszt, ale musisz zaplanować, co się stanie, gdy niektóre obciążenia spadną; na przykład, które źródło musi być priorytetowe.
- Jeśli środowisko docelowe jest używane do uruchamiania innych obciążeń, plan BCDR musi uwzględniać zachowanie tych obciążeń. Na przykład możesz uruchomić maszyny wirtualne tworzenia i testowania w środowisku docelowym, a jeśli wystąpi problem ze środowiskiem źródłowym, możesz wyłączyć wszystkie maszyny wirtualne w obiekcie docelowym, aby zapewnić dostępność wystarczających zasobów do uruchamiania chronionych maszyn wirtualnych.
Należy regularnie testować trasę BCDR i weryfikować ją. Można to zrobić przy użyciu procesów testowania pracy w trybie failover lub przenosząc całe obciążenia, aby zweryfikować kompleksowe przepływy.