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, business continuity and disaster recovery), która zapewnia bezpieczeństwo danych, dostępne aplikacje i obciążenia online podczas planowanych i nieplanowanych przestojów.
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 udostępnia usługi, które mogą obsługiwać bezpieczeństwo danych organizacji, dostępności aplikacji i obciążeń podczas przestojów. Na przykład w przypadku wystąpienia awarii w lokalizacji podstawowej przełączasz się do lokalizacji zapasowej, aby uzyskać dostęp do swoich aplikacji. Gdy tylko witryna główna znowu działa, możesz przełączyć z powrotem na nią. Aby uzyskać więcej informacji, zobacz About 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 działa 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 element może mieć wpływ na punkty przywracania.
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 Azure Stack Hub uruchamia aplians maszyny wirtualnej 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:
Kontyngent:
- Należy mieć wystarczający limit przydziału do tworzenia urządzenia maszyny wirtualnej usługi Azure Site Recovery. Potrzebujesz jednego lub więcej, w zależności od ogólnego planu.
Magazyn dla urządzenia maszyny wirtualnej usługi Azure Site Recovery:
Samo urządzenie maszyny wirtualnej usługi Azure Site Recovery ma wymagania dotyczące danych zdefiniowane przez jego 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.
Notatka
Jeśli istnieją ograniczenia magazynowe, powrót po awarii i ponowne włączenie ochrony może zakończyć się niepowodzeniem z powodu błędu Wystąpił błąd wewnętrzny. 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.
Szerokość pasma:
- 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.
Rozważania dotyczące celu
W środowisku docelowym istnieją dwa elementy, które należy wziąć pod uwagę podczas planowania pojemności:
Wymagania dotyczące usługi Azure Site Recovery: jakie są koszty utrzymania działania usługi Azure Site Recovery, bez konieczności ochrony jakichkolwiek obciążeń roboczych.
Wymagania dotyczące chronionych obciążeń.
Środowisko docelowe wymaga utworzenia jednego magazynu usługi Azure Site Recovery dla każdego urządzenia usługi Site Recovery w celu ochrony maszyn wirtualnych ze źródła (jednego urządzenia na magazyn). Chociaż nie jest to ograniczenie z perspektywy pojemności, należy to wziąć pod uwagę przy planowaniu projektu całego środowiska.
Zasoby rp usługi Azure Site Recovery
Instalacja usługi Azure Site Recovery w usłudze Azure Stack Hub wymaga zainstalowania dostawcy zasobów usługi Site Recovery (RP).
Notatka
W przypadku usługi Microsoft.SiteRecovery-1.2301.2216.2287 usługa 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 pewne procesory wirtualne:
| Usługa | vCore | Pamięć | Rozmiar dysku |
|---|---|---|---|
| Azure Site Recovery (odzyskiwanie witryny Azure) | 18 | 64 GB | 384 GB |
Notatka
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
Podczas tworzenia planu BCDR należy wziąć pod uwagę wszystkie aspekty chronionych obciążeń. Poniższa lista nie jest kompletna 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 nowo utworzone dane.
Zagadnienia dotyczące przepustowości sieci:
- Przepustowość sieci wymagana do replikacji różnicowej.
- Ilość przepływności w środowisku docelowym, którą usługa Azure Site Recovery może uzyskać ze środowiska źródłowego.
- Liczba maszyn wirtualnych do przetwarzania wsadowo jednocześnie. Ta liczba jest oparta na szacowanej przepustowości do ukończenia replikacji początkowej w danym czasie.
- RPO, które można osiągnąć dla danej przepustowości.
- Wpływ na oczekiwany RPO (Recovery Point Objective), jeśli zapewniona 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ń:
- W przypadku przełączenia awaryjnego maszyny wirtualne są uruchamiane w docelowych subskrypcjach użytkowników 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, nie są używane żadne zasoby związane z maszyną wirtualną, takie jak procesor wirtualny, pamięć itp. w środowisku docelowym. Te zasoby stają się istotne tylko podczas procesu failover, takiego jak test failover.
W zakresie usługi Azure Site Recovery w usłudze Azure Stack Hub poniżej przedstawiono punkt początkowy obliczeń, szczególnie w przypadku używanego konta magazynu pamięci podręcznej:
W przypadku przejścia w tryb failover podczas normalnych operacji pomnóż liczbę dysków replikowanych przez średnie RPO. Na przykład: (2 MB * 250 s). Konto magazynu pamięci podręcznej wynosi zwykle od kilku KB do 500 MB na dysk.
W przypadku awarii systemu, w najgorszym wypadku, pomnożysz liczbę replikowanych dysków przez średnie RPO przez cały dzień.
Ważny
Jeśli niektóre części usługi Azure Site Recovery nie działają, ale inne działają, może być co najwyżej jeden dzień dziennika różnic na koncie magazynu, zanim usługa Azure Site Recovery zdecyduje się wykonać operację przekroczenia limitu czasu.
Powrót po awarii do nowej maszyny wirtualnej. Oblicz sumę rozmiaru dysków każdej partii.
- Cały dysk musi zostać skopiowany na konto magazynu cache, aby można było zastosować docelową maszynę wirtualną, ponieważ docelowy dysk jest pusty.
- Skojarzone dane są usuwane po skopiowaniu, ale prawdopodobnie osiągnie szczytowe użycie równocześnie z sumą wszystkich rozmiarów dysków.
Utwórz plan BDCR na podstawie specyfiki rozwiązania, które próbujesz chronić.
Poniższa tabela zawiera 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ę:
Konfiguracja
| 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ść | Łączne OPS | Wąskie gardło |
|---|---|---|---|
| 68 | 136 MB/s | 68 | składowanie |
| 60 | 120 MB/s | 2048 | składowanie |
| 28 | 28 MB/s | 3584 | Procesor i pamięć usługi Azure Site Recovery |
| 16 | 32 MB/s | 4096 |
Notatka
8 Kb to najmniejszy rozmiar bloku danych, które obsługuje usługa Azure Site Recovery. Wszelkie zmiany mniejsze niż 8 Kb są traktowane jako 8 Kb.
Aby przeprowadzić dalsze testy, wygenerowaliśmy spójny typ obciążenia, na przykład spójne zmiany pamięci w blokach o rozmiarze 8 KB, które łącznie osiągają do 1 MB/s na dysk. Ten scenariusz nie jest prawdopodobny w rzeczywistym obciążeniu pracą, ponieważ zmiany mogą wystąpić o różnych porach dnia lub w postaci nagłych, różnorodnych wzrostów.
Aby zreplikować te losowe wzorce, przetestowaliśmy również scenariusze z:
- 120 maszyn wirtualnych (80 Windows, 40 Linux) chronionych za pomocą tego samego urządzenia do odzyskiwania maszyn wirtualnych Azure Site Recovery.
Każda maszyna wirtualna generuje w losowych odstępach czasu, co najmniej dwa razy na godzinę, losowe bloki danych łącznie o rozmiarze 5 GB w pięciu plikach.
Replikacja powiodła się na wszystkich 120 maszynach wirtualnych z niskim do średnim obciążeniem usług Azure Site Recovery.
Notatka
Te liczby powinny być używane tylko jako punkt odniesienia. Niekoniecznie są one skalowane liniowo. Dodanie kolejnej partii tej samej liczby maszyn wirtualnych może mieć mniejszy wpływ niż początkowa. Wyniki są bardzo 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). Efektywne projektowanie ciągłości działania i odzyskiwania po awarii (BCDR) wykorzystuje 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, zidentyfikuj wymagania dotyczące odzyskiwania po awarii platformy i uwzględnij wszystkie te czynniki w projektowaniu.
Wymagania dotyczące dostępności aplikacji i danych:
- Wymagania RTO i RPO 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 przełączania awaryjnego z bliskością składników w celu zapewnienia wydajności. Podczas awarii mogą wystąpić operacje aplikacji z ograniczoną funkcjonalnością lub obniżoną wydajnością.
Notatka
Aplikacja może natywnie obsługiwać wiele środowisk usługi Azure Stack Hub lub posiadać komponenty zdolne do działania w takich środowiskach. W takim przypadku możesz 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 front-end lub back-end, w którym możesz wdrożyć front-endy w środowiskach usługi Azure Stack Hub.
Unikaj używania nakładających się zakresów adresów IP w sieciach produkcyjnych i działających na wypadek awarii.
- Sieci produkcyjne i odzyskiwania po awarii, których adresy IP się nakładają, wymagają procesu przełączenia awaryjnego, co może komplikować i opóźniać przełączanie aplikacji. Jeśli to możliwe, zaplanuj architekturę sieci BCDR, która zapewnia współbieżną łączność ze wszystkimi lokacjami.
Ustalanie rozmiaru środowisk docelowych:
- Jeśli używasz źródła i miejsca 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 2-krotnym wzrostem, ponieważ obejmuje tylko zmiany w danych. W zależności od typu danych i oczekiwanych zmian, oraz z uwagi na zasady replikacji, które wymagają od 1,5 do 2 razy więcej miejsca do magazynowania na docelowym urządzeniu, upewnij się, że procesy awaryjnego przełączania nie stwarzają żadnych problemów.
- Możesz rozważyć posiadanie docelowego środowiska usługi Azure Stack Hub jako miejsca 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 obejmować zachowanie tych obciążeń. Możesz na przykład 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 upewnić się, że wystarczające zasoby są dostępne do uruchamiania chronionych maszyn wirtualnych.
Należy regularnie testować i weryfikować system BCDR. Można to zrobić, wykorzystując procesy testowania awaryjnego przełączania lub przenosząc całe obciążenia, aby zweryfikować przepływy od początku do końca.