Metodologia projektowania obciążeń o krytycznym znaczeniu na platformie Azure
Tworzenie aplikacji o znaczeniu krytycznym na dowolnej platformie w chmurze wymaga znacznej wiedzy technicznej i inwestycji w inżynierię, zwłaszcza że istnieje znaczna złożoność związana z:
- Omówienie platformy w chmurze
- Wybieranie odpowiednich usług i kompozycji
- Stosowanie prawidłowej konfiguracji usługi,
- Operacjonalizacja wykorzystywanych usług i
- Stale zgodne z najnowszymi najlepszymi rozwiązaniami i planami obsługi.
Ta metodologia projektowania dąży do zapewnienia łatwej ścieżki projektowej, aby ułatwić poruszanie się po tej złożoności i informowanie o decyzjach projektowych wymaganych do utworzenia optymalnej architektury docelowej.
1 — Projektowanie pod kątem wymagań biznesowych
Nie wszystkie obciążenia o znaczeniu krytycznym mają te same wymagania. Spodziewaj się, że zagadnienia dotyczące przeglądu i zalecenia projektowe dostarczone przez tę metodologię projektowania przyniosą różne decyzje projektowe i kompromisy w różnych scenariuszach aplikacji.
Wybieranie warstwy niezawodności
Niezawodność jest względną koncepcją i dla każdego obciążenia, które ma być odpowiednio niezawodne, powinno odzwierciedlać wymagania biznesowe związane z nim. Na przykład obciążenie o znaczeniu krytycznym z 99,999% celem poziomu usług dostępności (SLO) wymaga znacznie wyższego poziomu niezawodności niż inne mniej krytyczne obciążenie z slo 99,9%.
Ta metodologia projektowania stosuje koncepcję warstw niezawodności wyrażonych jako cele SLA dostępności w celu informowania o wymaganych cechach niezawodności. W poniższej tabeli przedstawiono dozwolone budżety błędów skojarzone z typowymi warstwami niezawodności.
| Warstwa niezawodności (slo dostępności) | Dozwolony przestój (tydzień) | Dozwolony przestój (miesiąc) | Dozwolony przestój (rok) |
|---|---|---|---|
| 99,9% | 10 minut, 4 sekundy | 43 minuty, 49 sekund | 8 godzin, 45 minut, 56 sekund |
| 99,95% | 5 minut, 2 sekundy | 21 minut, 54 sekundy | 4 godziny, 22 minuty, 58 sekund |
| 99,99% | 1 min | 4 minuty 22 sekundy | 52 minuty, 35 sekund |
| 99.999% | 6 s | 26 s | 5 minut, 15 sekund |
| 99.9999% | <1 sekunda | 2 sekundy | 31 sekund |
Ważne
Cel slo dostępności jest uznawany przez tę metodologię projektowania za więcej niż prosty czas pracy, ale raczej spójny poziom usługi aplikacji względem znanego stanu aplikacji w dobrej kondycji.
Podczas pierwszego ćwiczenia czytelnicy powinni wybrać docelową warstwę niezawodności, określając, ile przestojów jest akceptowalne? Dążenie do określonej warstwy niezawodności ostatecznie będzie miało znaczący wpływ na ścieżkę projektową i obejmuje decyzje projektowe, co spowoduje inną architekturę docelową.
Na tym obrazie pokazano, jak różne warstwy niezawodności i podstawowe wymagania biznesowe wpływają na architekturę docelową implementacji referencyjnej koncepcyjnej, szczególnie w odniesieniu do liczby wdrożeń regionalnych i wykorzystania globalnych technologii.
Cel czasu odzyskiwania (RTO) i cel punktu odzyskiwania (RPO) są kolejnymi krytycznymi aspektami podczas określania wymaganej niezawodności. Jeśli na przykład próbujesz osiągnąć cel czasu odzyskiwania aplikacji wynoszący mniej niż minutę, strategie odzyskiwania oparte na kopii zapasowej lub strategia wdrażania aktywnego pasywnego może być niewystarczająca.
2 — Ocena obszarów projektowych przy użyciu zasad projektowania
W ramach tej metodologii znajduje się krytyczna ścieżka projektowania składająca się z następujących elementów:
- Podstawowe zasady projektowania
- Podstawowy obszar projektowania z silnie powiązanymi i zależnymi decyzjami projektowymi.
Wpływ decyzji podjętych w poszczególnych obszarach projektowych będzie powtarzał się w innych obszarach projektowych i decyzjach projektowych. Zapoznaj się z podanymi zagadnieniami i zaleceniami, aby lepiej zrozumieć konsekwencje obejmujących decyzje, które mogą powodować kompromisy w powiązanych obszarach projektowych.
Aby na przykład zdefiniować architekturę docelową, kluczowe jest określenie, jak najlepiej monitorować kondycję aplikacji w kluczowych składnikach. Zdecydowanie zalecamy przejrzenie obszaru projektowania modelowania kondycji przy użyciu opisanych zaleceń, aby pomóc w podejmowaniu decyzji.
3 — Wdrażanie pierwszej aplikacji o znaczeniu krytycznym
Zapoznaj się z tymi architekturami referencyjnymi, które opisują decyzje projektowe na podstawie tej metodologii.
Porada
Architektura jest wspierana przez implementację usługi Mission-Critical Online , która ilustruje zalecenia dotyczące projektowania.
Artefakty klasy produkcyjnej Każdy artefakt techniczny jest gotowy do użycia w środowiskach produkcyjnych ze wszystkimi końcowymi aspektami operacyjnymi.
Zakorzenione w rzeczywistych doświadczeniach Wszystkie decyzje techniczne są prowadzone przez doświadczenia klientów platformy Azure i wnioski wyciągnięte z wdrażania tych rozwiązań.
Wyrównanie planu działania platformy Azure Architektury referencyjne o znaczeniu krytycznym mają własny plan działania dostosowany do planów rozwoju produktów platformy Azure.
4 — Integrowanie obciążenia ze strefami docelowymi platformy Azure
Subskrypcje strefy docelowej platformy Azure zapewniają udostępnioną infrastrukturę dla wdrożeń przedsiębiorstwa, które wymagają scentralizowanego ładu.
Ważne jest, aby ocenić, który przypadek użycia łączności jest wymagany przez aplikację o krytycznym znaczeniu. Strefy docelowe platformy Azure obsługują dwa główne archetypy oddzielone różnymi zakresami grupy zarządzania: Online lub Corp, jak pokazano na tej ilustracji.
Subskrypcja online
Obciążenie o znaczeniu krytycznym działa jako niezależne rozwiązanie bez bezpośredniej łączności sieciowej firmowej z resztą architektury strefy docelowej platformy Azure. Aplikacja zostanie dodatkowo zabezpieczona za pośrednictwem ładu opartego na zasadach i automatycznie zostanie zintegrowana ze scentralizowanym rejestrowaniem platformy za pośrednictwem zasad.
Architektura punktu odniesienia i implementacja usługi Mission-Critical Online jest zgodna z podejściem online.
Subskrypcja corp.
W przypadku wdrożenia w subskrypcji Corp obciążenie o znaczeniu krytycznym zależy od strefy docelowej platformy Azure w celu zapewnienia zasobów łączności. Takie podejście umożliwia integrację z innymi aplikacjami i usługami udostępnionymi. Musisz zaprojektować niektóre podstawowe zasoby, które będą istnieć z góry w ramach platformy udostępnionej usługi. Na przykład sygnatura wdrożenia regionalnego nie powinna już obejmować efemerycznych Virtual Network ani strefy usługi Azure Prywatna strefa DNS, ponieważ będą one istnieć w subskrypcji Corp.
Aby rozpocząć pracę z tym przypadkiem użycia, zalecamy architekturę punktu odniesienia w architekturze referencyjnej strefy docelowej platformy Azure .
Porada
Poprzednia architektura jest wspierana przez implementację połączenia o krytycznym znaczeniu .
5 — Wdrażanie środowiska aplikacji piaskownicy
Równolegle do działań projektowych zdecydowanie zaleca się ustanowienie środowiska aplikacji piaskownicy przy użyciu implementacji odwołań Mission-Critical.
Zapewnia to praktyczne możliwości weryfikacji decyzji projektowych przez replikowanie architektury docelowej, co pozwala szybko ocenić niepewność projektową. W przypadku poprawnego zastosowania z reprezentatywnym zakresem wymagań większość problematycznych problemów, które mogą utrudnić postęp, można odkryć, a następnie rozwiązać problem.
6 — Stale ewoluuje wraz z planami działania platformy Azure
Architektury aplikacji ustanowione przy użyciu tej metodologii projektowania muszą nadal ewoluować zgodnie z planami platformy Azure w celu zapewnienia zoptymalizowanego zrównoważonego rozwoju.
Następny krok
Zapoznaj się z zasadami projektowania scenariuszy aplikacji o znaczeniu krytycznym.