Projektowanie pod kątem tworzenia kopii zapasowych i odzyskiwania

  • 5 min

Organizacje, takie jak Tailwind Traders, wymagają wysokiego stopnia niezawodności od swoich aplikacji o krytycznym znaczeniu. Aby uzyskać żądaną niezawodność aplikacji lokalnych, typowe jest zakup większej ilości zasobów obliczeniowych, takich jak serwery i magazyn. Zakup większej liczby zasobów obliczeniowych zwiększa nadmiarowość w infrastrukturze lokalnej.

Ważne jest również, aby każda aplikacja o znaczeniu krytycznym i skojarzone z nią dane były możliwe do odzyskania po awarii. Ta możliwość odzyskiwania jest często zapewniana przez tworzenie kopii zapasowych, przywracanie składników i procedur. W przypadku organizacji z aplikacjami hostowanymi na platformie Azure lub w organizacjach z wdrożeniami aplikacji hybrydowych istnieją inne zagadnienia i opcje.

Niezawodne aplikacje to:

  • Odporność na awarie składników.

  • Wysoka dostępność i może działać w dobrej kondycji bez znaczących przestojów.

Aby osiągnąć żądaną odporność i wysoką dostępność, należy najpierw zdefiniować wymagania.

Uwaga

W tym module będzie używany termin odporność jako zdolność systemu do bezproblemowego obsługi i odzyskiwania po awariach, zarówno niezamierzonych, jak i złośliwych.

Definiowanie wymagań

Definiowanie wymagań obejmuje:

  • Identyfikowanie potrzeb biznesowych.

  • Tworzenie planu odporności w celu zaspokojenia tych potrzeb.

Poniższa tabela zagadnień zawiera wskazówki dotyczące tego procesu.

Zagadnienie Opis
Jakie są obciążenia i ich użycie? Obciążenie to odrębna możliwość lub zadanie, które jest logicznie oddzielone od innych zadań pod względem wymagań logiki biznesowej i magazynowania danych. Każde obciążenie prawdopodobnie ma inne wymagania dotyczące dostępności, skalowalności, spójności danych i odzyskiwania po awarii.
Jakie są wzorce użycia obciążeń? Wzorce użycia mogą określać wymagania. Zidentyfikuj różnice w wymaganiach zarówno w okresach krytycznych, jak i niekrytycznych. Aby zapewnić czas pracy, zaplanuj nadmiarowość w kilku regionach w przypadku awarii jednego regionu. Z drugiej strony, aby zminimalizować koszty w okresach niekrytycznych, możesz uruchomić aplikację w jednym regionie.
Jakie są metryki dostępności? Średni czas odzyskiwania (MTTR) i średni czas między awariami (MTBF) to zwykle używane metryki. Średni czas między awariami określa oczekiwany czas działania składnika między awariami. Średni czas do odzyskania to średni czas potrzebny do przywrócenia składnika po awarii. Użyj tych metryk, aby określić, gdzie należy dodać nadmiarowość, oraz określić umowy dotyczące poziomu usług (SLA) dla klientów.
Jakie są metryki odzyskiwania? Cel czasu odzyskiwania (RTO) jest maksymalnym dopuszczalnym czasem, gdy jedna z Twoich aplikacji może być niedostępna po zdarzeniu. Cel punktu odzyskiwania (RPO) to maksymalny czas trwania utraty danych, który jest akceptowalny podczas awarii. Należy również rozważyć cel poziomu odzyskiwania (RLO). Ta metryka określa stopień szczegółowości odzyskiwania. Innymi słowy, niezależnie od tego, czy musisz mieć możliwość odzyskania farmy serwerów, aplikacji internetowej, witryny, czy tylko określonego elementu. Aby określić te wartości, przeprowadź ocenę ryzyka. Upewnij się, że rozumiesz koszty i ryzyko przestoju lub utraty danych w organizacji.
Jakie są cele dostępności obciążeń? Aby zapewnić, że architektura aplikacji spełnia wymagania biznesowe, zdefiniuj docelowe umowy SLA dla każdego obciążenia. Oprócz zależności aplikacji weź pod uwagę koszt i złożoność spełnienia wymagań dotyczących dostępności.
Jakie są twoje umowy SLA? Na platformie Azure umowa dotycząca poziomu usług (SLA) opisuje zobowiązania firmy Microsoft dotyczące czasu pracy i łączności. Jeśli umowa SLA dla określonej usługi zawiera wartość 99,9%, należy oczekiwać, że usługa będzie dostępna przez 99,9% czasu.

Napiwek

Jeśli mtTR dowolnego krytycznego składnika w scenariuszu o wysokiej dostępności przekracza cel czasu odzyskiwania systemu, awaria w systemie może spowodować niedopuszczalne zakłócenia działania firmy. Innymi słowy, nie można przywrócić systemu w ramach zdefiniowanego celu czasu odzyskiwania.

Zdefiniuj własne docelowe umowy SLA dla każdego obciążenia w rozwiązaniu, odpowiadając na powyższe pytania. Pomaga to zapewnić, że architektura spełnia Twoje wymagania biznesowe. Jeśli na przykład obciążenie wymaga czasu pracy na 99,99%, ale zależy od usługi z umową SLA na 99,9%, usługa nie może być pojedynczym punktem awarii w systemie.

Po zdefiniowaniu wymagań dotyczących odzyskiwania można wybrać odpowiednią technologię odzyskiwania.