Niezawodność w usłudze Azure Bot Service

W tym artykule opisano obsługę niezawodności w usłudze Azure Bot Service. Obejmuje ona zarówno niezawodność regionalną ze strefami dostępności, jak i odpornością między regionami z odzyskiwaniem po awarii dla botów z lokalnym miejscem przechowywania danych. Aby uzyskać bardziej szczegółowe omówienie niezawodności na platformie Azure, zobacz Niezawodność platformy Azure.

Podczas tworzenia aplikacji (bota) w usłudze Bot Service możesz wybrać lokalizację danych globalnych lub lokalnych. Lokalne miejsce przechowywania danych zapewnia, że dane osobowe bota są zachowywane, przechowywane i przetwarzane w określonych granicach geograficznych, takich jak Unia Europejska. Takie podejście pomaga spełnić wymagania dotyczące zgodności i niezawodności regionalnej.

Aby uzyskać więcej informacji na temat wdrażania botów z lokalnym miejscem przechowywania danych i zgodnością regionalną, zobacz Regionalizacja w usłudze Azure Bot Service.

Obsługa strefy dostępności

Strefy dostępności są fizycznie oddzielnymi grupami centrów danych w regionie świadczenia usługi Azure. Gdy jedna strefa ulegnie awarii, usługi mogą przejść w tryb failover do jednej z pozostałych stref.

W przypadku botów regionalnych usługa Azure Bot Service domyślnie obsługuje redundancję strefową. Nie musisz go konfigurować ani ponownie konfigurować pod kątem obsługi stref dostępności.

Wymagania wstępne

• Bot musi być regionalny (nie globalny).
• Obecnie tylko region "westeurope" obsługuje strefy dostępności.

Doświadczenie uspokajające

Podczas awarii w całej strefie klient powinien spodziewać się krótkiego obniżenia wydajności, dopóki usługa nie zrównoważy bazowej wydajności w celu dostosowania się do zdrowych stref. Nie jest to zależne od odtworzenia strefy; zakłada się, że samonaprawiający się stan usługi zarządzanej przez firmę Microsoft rekompensuje utratę strefy przez wykorzystanie pojemności z innych stref.

Odzyskiwanie po awarii między regionami w geograficznym układzie wieloregionowym.

Odzyskiwanie po awarii (DR) odnosi się do praktyk używanych przez organizacje do odzyskiwania po wystąpieniu zdarzeń o dużym wpływie, takich jak klęski żywiołowe lub nieudane wdrożenia, które powodują przestoje i utratę danych. Niezależnie od przyczyny najlepszym rozwiązaniem dla awarii jest dobrze zdefiniowany i przetestowany plan odzyskiwania po awarii oraz projekt aplikacji, który aktywnie obsługuje odzyskiwanie po awarii. Przed rozpoczęciem tworzenia planu odzyskiwania po awarii zobacz Zalecenia dotyczące projektowania strategii odzyskiwania po awarii.

W przypadku DR firma Microsoft używa modelu wspólnej odpowiedzialności . W tym modelu firma Microsoft zapewnia dostępność podstawowej infrastruktury i usług platformy. Jednak wiele usług platformy Azure nie replikuje automatycznie danych ani nie wraca z regionu, w którym wystąpił błąd, aby przeprowadzić replikację krzyżową do innego włączonego regionu. W przypadku tych usług odpowiadasz za skonfigurowanie planu odzyskiwania po awarii, który działa dla waszych obciążeń użytkowania. Większość usług oferty platformy Azure jako usługa (PaaS) udostępnia funkcje i wskazówki wspierające DR. Możesz użyć funkcji specyficznych dla usługi, aby wspierać szybkie odzyskiwanie i ułatwić opracowanie planu odzyskiwania po awarii.

Usługa Azure Bot Service działa w trybie aktywny-aktywny dla usług globalnych i regionalnych. W przypadku wystąpienia awarii nie trzeba wykrywać błędów ani zarządzać usługą. Usługa Azure Bot Service automatycznie wykonuje automatyczne przełączenie awaryjne i automatyczne odzyskiwanie w architekturze geograficznej obejmującej wiele regionów. W przypadku usługi regionalnej bota UE usługa Azure Bot Service udostępnia dwa pełne regiony w Europie z aktywną/aktywną replikacją w celu zapewnienia nadmiarowości. W globalnym serwisie botów wszystkie dostępne regiony mogą być obsługiwane jako zasięg globalny.

Następne kroki