Projektowanie pod kątem odzyskiwania
 Obciążenie musi być w stanie przewidywać i odzyskiwać dane po większości awarii o wszystkich rozmiarach, przy minimalnych zakłóceniach środowiska użytkownika i celów biznesowych. |
|---|
Nawet wysoce odporne systemy wymagają podejścia do gotowości po awarii zarówno w przypadku operacji projektowania architektury, jak i obciążeń. W warstwie danych powinny istnieć strategie, które mogą naprawiać stan obciążenia w przypadku uszkodzenia.
Przykładowy scenariusz
Firma Contoso obecnie hostuje dużą ilość danych w lokalnej bazie danych programu SQL Server i niedawno zmodernizuje swoje rozwiązanie analityczne dla danych za pomocą usług platformy Azure.
Nowe rozwiązanie analityczne korzysta z usług Azure Analysis Services, Azure Data Factory, Azure Synapse Analytics, Power BI i Azure Virtual Machines. Wszyscy użytkownicy rozwiązania są wewnętrzni. Po uwzględnieniu wymagań dotyczących dostępności rozwiązania zespół decyduje się wdrożyć rozwiązanie w jednym regionie.
Dane są pozyskiwane przy użyciu usługi Azure Data Factory i przetwarzane przed zapisaniem w magazynie usług Analysis Services. Część procesu wymaga starszego procesu systemu Windows wdrożonego na maszynie wirtualnej w chmurze.
Przygotuj się na awarie
Mają ustrukturyzowane, przetestowane i udokumentowane plany odzyskiwania zgodne z wynegocjowanymi celami odzyskiwania. Plany muszą obejmować wszystkie składniki oprócz całego systemu.
Dobrze zdefiniowany proces prowadzi do szybkiego odzyskiwania, które może zapobiec negatywnemu wpływowi na finanse i reputację firmy. Przeprowadzanie regularnych testów odzyskiwania testuje proces odzyskiwania składników systemu, danych i trybu failover oraz kroków powrotu po awarii, aby uniknąć nieporozumień, gdy czas i integralność danych są kluczowymi miarami sukcesu.
Wyzwanie firmy Contoso
- Rozwiązanie jest używane tylko wewnętrznie i nie jest uznawane za krytyczne. Dlatego zespół ds. obciążeń i osoby biorące udział w projekcie biznesowym zgadzają się, że odbudowanie rozwiązania w regionie pomocniczym jest wystarczającym modelem odzyskiwania w mało prawdopodobnym przypadku, że region świadczenia usługi Azure, w którym jest wdrożony, zostanie utracony lub całe rozwiązanie stanie się niedostępne z jakiegoś innego powodu.
- Zespół ds. obciążeń opisuje sposób kompilowania rozwiązania w innym regionie w ramach planu odzyskiwania po awarii, ale nie miał jeszcze możliwości wykonania pełnego testowania odzyskiwania po awarii.
Stosowanie podejścia i wyników
- Po wystąpieniu regionalnej awarii zespół reagowania na odzyskiwanie po awarii może postępować zgodnie z instrukcjami planu odzyskiwania po awarii, aby ponownie wdrożyć rozwiązanie analityczne w innym regionie.
- Zespół odnajduje luki w planach odzyskiwania po awarii dla niektórych operacji wymaganych do wdrożenia rozwiązania, a plan zostanie zaktualizowany w celu zwiększenia wydajności odzyskiwania w przyszłości.
- Zespół obciążeń i uczestnicy projektu zgadzają się przyspieszyć planowane testowanie odzyskiwania po awarii, aby zapewnić, że zaktualizowany plan umożliwi bardziej wydajne odzyskiwanie.
Rozwiązywanie problemów z danymi stanowymi
Upewnij się, że możesz naprawić dane wszystkich składników stanowych w ramach celów odzyskiwania.
Kopie zapasowe są niezbędne do powrotu systemu do stanu roboczego przy użyciu zaufanego punktu odzyskiwania, takiego jak ostatni znany dobry stan.
Niezmienne i transakcyjnie spójne kopie zapasowe zapewniają, że nie można zmienić danych i że przywrócone dane nie są uszkodzone.
Wyzwanie firmy Contoso
- Zespół ds. obciążeń decyduje się przenieść bazy danych SQL na platformę Azure, aby skrócić czas przetwarzania analiz. Jedna z baz danych jest intensywnie używana podczas procesu analizy przez maszyny wirtualne, więc zespół musi upewnić się, że stan bazy danych można odzyskać przy użyciu najniższego możliwego celu punktu odzyskiwania.
Stosowanie podejścia i wyników
- Ponieważ bazy danych mają rozmiar ponad 4 TB, migracja do usługi Azure SQL Database nie jest osiągalna w krótkim okresie. Dlatego zespół przeprowadza migrację do maszyn wirtualnych platformy Azure z uruchomionym programem SQL Server 2022.
- Zespół decyduje się na użycie funkcji Automated Backup dla wszystkich baz danych, w tym krytycznych, takich jak ta używana przez maszyny wirtualne.
- W przypadku krytycznych baz danych zespół planuje użyć funkcji Automated Backup wraz z funkcją linku wystąpienia zarządzanego, aby aktywnie replikować bazy danych do usługi Azure SQL Managed Instance.
Implementowanie automatycznych funkcji samonaprawiania w projekcie
Możliwości samonaprawiania to mechanizmy, które umożliwiają składnikom obciążenia automatyczne rozwiązywanie problemów przez odzyskiwanie składników, których dotyczy problem, a w razie potrzeby przechodzenie w tryb failover do nadmiarowej infrastruktury. Użyj wzorców projektowych, aby zwiększyć odporność obciążenia za pomocą mechanizmów samonaprawiania.
Automatyzacja samonaprawiania pomaga zmniejszyć ryzyko związane z czynnikami zewnętrznymi, takimi jak interwencja człowieka, i skróci cykl naprawy przerwania.
Wyzwanie firmy Contoso
- Proces systemu Windows wywoływany z usługi Azure Data Factory podczas pozyskiwania danych został początkowo wdrożony na wielu maszynach wirtualnych w celu zwiększenia dostępności.
- Wystąpiło kilka przypadków awarii starszego procesu systemu Windows, co wymaga ponownego uruchomienia maszyny wirtualnej. Chociaż ogólny czas przetwarzania został minimalny (ze względu na poziom nadmiarowości), zespół chce zaimplementować rozwiązanie, które automatyzuje wykrywanie awarii i odzyskiwania.
Stosowanie podejścia i wyników
- Zespół decyduje się wdrożyć rozwiązanie zestawu skalowania maszyn wirtualnych platformy Azure, które jest skonfigurowane do wdrażania rozszerzenia kondycji aplikacji w celu ciągłego monitorowania kondycji procesu maszyny wirtualnej.
- Po włączeniu automatycznej naprawy wystąpienia zestaw skalowania jest teraz w stanie naprawić składnik, uruchamiając ponownie maszynę wirtualną lub tworząc nowe wystąpienie na podstawie tego samego obrazu.