Udostępnij za pośrednictwem

Zagadnienia dotyczące ciągłości działania i odzyskiwania po awarii (BCDR) w usłudze Azure OpenAI Service

  • Artykuł

Usługa Azure OpenAI jest dostępna w wielu regionach. Podczas tworzenia zasobu usługi Azure OpenAI należy określić region. Od tego momentu zasób i wszystkie jego operacje pozostają skojarzone z tym regionem serwera platformy Azure.

Problem z siecią, który dotyczy całego regionu, zdarza się rzadko, ale nie jest niemożliwy. Jeśli usługa musi być zawsze dostępna, należy zaprojektować ją w celu przejścia w tryb failover do innego regionu lub podzielenia obciążenia między co najmniej dwa regiony. Oba podejścia wymagają co najmniej dwóch zasobów usługi Azure OpenAI w różnych regionach. Ten artykuł zawiera ogólne zalecenia dotyczące implementowania ciągłości działania i odzyskiwania po awarii (BCDR) dla aplikacji Azure OpenAI.

Domyślnie usługa Azure OpenAI zapewnia domyślną umowę SLA. Mimo że domyślna odporność może być wystarczająca dla wielu aplikacji, aplikacje wymagające wysokiego stopnia odporności i ciągłości działania powinny podjąć dodatkowe kroki w celu dalszego wzmocnienia infrastruktury modelu.

Wdrożenia standardowe

Uwaga

Jeśli możesz użyć wdrożeń w warstwie Global Standard, należy użyć tych opcji. Wdrożenia strefy danych to kolejna najlepsza opcja dla organizacji wymagających całkowitego przetworzenia danych w granicach geograficznych.

  1. W przypadku wdrożeń standardowych domyślnie wdrożenia strefy danych (opcje USA/UE).

  2. W subskrypcji platformy Azure należy wdrożyć dwa zasoby usługi Azure OpenAI. Jeden zasób powinien zostać wdrożony w preferowanym regionie, a drugi powinien zostać wdrożony w regionie pomocniczym/w trybie failover. Usługa Azure OpenAI przydziela limit przydziału na poziomie subskrypcji i regionu, dzięki czemu mogą żyć w tej samej subskrypcji bez wpływu na limit przydziału.

  3. Musisz mieć jedno wdrożenie dla każdego modelu, którego planujesz użyć do wdrożenia w zasobie usługi Azure OpenAI Service w preferowanym regionie świadczenia usługi Azure, i należy zduplikować te wdrożenia modelu w regionie pomocniczym/failover. Przydziel pełny przydział dostępny we wdrożeniu w warstwie Standardowa do każdego z tych punktów końcowych. Zapewnia to najwyższą szybkość przepływności w porównaniu z podziałem przydziału w wielu wdrożeniach.

  4. Wybierz region wdrażania na podstawie topologii sieci. Zasób usługi Azure OpenAI można wdrożyć w dowolnym obsługiwanym regionie, a następnie utworzyć prywatny punkt końcowy dla tego zasobu w preferowanym regionie.

    • Po przejściu do granicy usługi Azure OpenAI usługa Azure OpenAI optymalizuje routing i przetwarzanie dostępnych zasobów obliczeniowych w strefie danych.
    • Korzystanie ze stref danych jest bardziej wydajne i prostsze niż samodzielne równoważenie obciążenia w wielu wdrożeniach regionalnych.

  5. Jeśli wystąpi awaria regionalna, w której wdrożenie jest w stanie bezużytecznym, możesz użyć innego wdrożenia w regionie pomocniczym/pasywnym w ramach tej samej subskrypcji.

    • Ponieważ zarówno wdrożenia podstawowe, jak i pomocnicze są wdrożeniami strefowymi, pobierają one z tej samej puli pojemności strefy, która jest pobierana ze wszystkich dostępnych regionów w strefie. Wdrożenie pomocnicze chroni przed podstawowym punktem końcowym usługi Azure OpenAI jest niemożliwy do osiągnięcia.
    • Użyj bramy sztucznej inteligencji generowania, która obsługuje równoważenie obciążenia i wzorzec wyłącznika, taki jak usługa API Management przed punktami końcowymi usługi Azure OpenAI, dzięki czemu zakłócenia podczas awarii regionalnej są zminimalizowane do korzystania z aplikacji.
    • Jeśli limit przydziału w ramach danej subskrypcji zostanie wyczerpany, można wdrożyć nową subskrypcję w taki sam sposób, jak powyżej, a jego punkt końcowy wdrożony za bramą generacyjnych sztucznej inteligencji.

Aprowizowania wdrożeń

Tworzenie puli jednostek PTU przedsiębiorstwa

  1. W przypadku wdrożeń aprowizowanych zalecamy wdrożenie pojedynczej jednostki PTU strefy danych (dostępne 12.04.2024), które służy jako pula jednostek PTU przedsiębiorstwa. Usługa API Management umożliwia zarządzanie ruchem z wielu aplikacji w celu ustawienia limitów przepływności, rejestrowania, priorytetu i logiki trybu failover.
    • Ta pula PTU przedsiębiorstwa jest "prywatnym zasobem z płatnością zgodnie z rzeczywistym użyciem", który chroni przed hałaśliwym problemem sąsiadów, który może wystąpić we wdrożeniach w warstwie Standardowa, gdy zapotrzebowanie na usługę jest wysokie. Twoja organizacja będzie mieć gwarantowany, dedykowany dostęp do puli pojemności, która jest dostępna tylko dla Ciebie, a tym samym niezależnie od skoków zapotrzebowania od innych klientów.
    • Zapewnia to kontrolę nad tym, które aplikacje najpierw zwiększają opóźnienie, co pozwala na ustalanie priorytetów ruchu do aplikacji o krytycznym znaczeniu.
    • Aprowizowania wdrożeń są wspierane przez umowy SLA dotyczące opóźnień, które sprawiają, że są preferowane w przypadku wdrożeń w warstwie Standardowa (płatność zgodnie z rzeczywistym użyciem) w przypadku obciążeń wrażliwych na opóźnienia.
    • Wdrożenie jednostki PTU w przedsiębiorstwie umożliwia również wyższe wskaźniki wykorzystania, ponieważ ruch jest wygładzony w obciążeniach aplikacji, podczas gdy poszczególne obciążenia wydają się być bardziej podatne na wzrosty.
  2. Podstawowe wdrożenie jednostki PTU przedsiębiorstwa powinno znajdować się w innym regionie niż podstawowe wdrożenie strefy standardowej. Dzieje się tak, aby w przypadku awarii regionalnej nie utracić dostępu zarówno do wdrożenia jednostki PTU, jak i wdrożenia strefy standardowej w tym samym czasie.

Wdrożenie dedykowanej jednostki PTU obciążenia

  1. Niektóre obciążenia mogą wymagać własnego wdrożenia z dedykowaną aprowizowaną obsługą administracyjną. Jeśli tak, możesz utworzyć dedykowane wdrożenie PTU dla tej aplikacji.
  2. Wdrożenia puli jednostek PTU obciążeń i przedsiębiorstw powinny chronić przed awariami regionalnymi. Można to zrobić, umieszczając pulę PTU obciążenia w regionie A i puli jednostek PTU przedsiębiorstwa w regionie B.
  3. To wdrożenie powinno najpierw przejść w tryb failover do puli JEDNOSTEK PTU przedsiębiorstwa, a następnie do wdrożenia w warstwie Standardowa. Oznacza to, że jeśli użycie wdrożenia jednostki PTU obciążenia przekracza 100%, żądania będą nadal obsługiwane przez punkty końcowe PTU, włączając umowę SLA o wyższym opóźnieniu dla tej aplikacji.

Diagram architektury odzyskiwania po awarii.

Dodatkową zaletą tej architektury jest możliwość stosu wdrożeń w warstwie Standardowa przy użyciu wdrożeń aprowizowanych, dzięki czemu można wybrać preferowany poziom wydajności i odporności. Dzięki temu możesz używać jednostek PTU na potrzeby bazowego zapotrzebowania na obciążenia i korzystać z płatności zgodnie z rzeczywistym użyciem w przypadku skoków ruchu.

Aprowizowany diagram skalowania.

Infrastruktura pomocnicza

Infrastruktura, która obsługuje architekturę azure OpenAI, musi być brana pod uwagę w projektach. Składniki infrastruktury biorące udział w architekturze różnią się w zależności od tego, czy aplikacje korzystają z usługi Azure OpenAI przez Internet, czy przez sieć prywatną. Architektura omówiona w tym artykule zakłada, że organizacja zaimplementowała bramę sztucznej inteligencji generowania. Organizacje z dojrzałym śladem platformy Azure i łącznością hybrydową powinny korzystać z usługi za pośrednictwem sieci prywatnej, podczas gdy organizacje bez łączności hybrydowej lub aplikacje w innej chmurze, takie jak GCP lub AWS, będą korzystać z usługi za pośrednictwem sieci szkieletowej firmy Microsoft.

Projektowanie pod kątem zużycia za pośrednictwem sieci szkieletowej firmy Microsoft

Organizacje korzystające z usługi za pośrednictwem publicznej sieci szkieletowej firmy Microsoft powinny wziąć pod uwagę następujące elementy projektowe:

  1. Brama generowania sztucznej inteligencji powinna zostać wdrożona w sposób zapewniający dostępność w przypadku awarii regionalnej platformy Azure. W przypadku korzystania z usługi APIM (Azure API Management) można to zrobić, wdrażając oddzielne wystąpienia usługi APIM w wielu regionach lub korzystając z funkcji bramy z wieloma regionami usługi APIM.

  2. Publiczny globalny moduł równoważenia obciążenia serwera powinien służyć do równoważenia obciążenia w wielu wystąpieniach bramy sztucznej inteligencji generowania w sposób aktywny/aktywny/pasywny. Usługa Azure FrontDoor może służyć do spełnienia tej roli w zależności od wymagań organizacji.

Diagram architektury trybu failover.

Projektowanie pod kątem zużycia za pośrednictwem sieci prywatnej

Organizacje korzystające z usługi za pośrednictwem sieci prywatnej powinny rozważyć następujące elementy projektowe:

  1. Łączność hybrydowa powinna zostać wdrożona w sposób, który chroni przed awarią regionu świadczenia usługi Azure. Podkreślenie składników obsługujących łączność hybrydową składa się z lokalnej infrastruktury sieciowej organizacji i usługi Microsoft ExpressRoute lub sieci VPN.
  2. Brama generowania sztucznej inteligencji powinna zostać wdrożona w sposób zapewniający dostępność w przypadku awarii regionalnej platformy Azure. W przypadku korzystania z usługi APIM (Azure API Management) można to zrobić, wdrażając oddzielne wystąpienia usługi APIM w wielu regionach lub korzystając z funkcji bramy z wieloma regionami usługi APIM.
  3. Prywatne punkty końcowe usługi Azure Private Link powinny być wdrażane dla każdego wystąpienia usługi Azure OpenAI w każdym regionie świadczenia usługi Azure. W przypadku usługi Azure Prywatna strefa DNS można użyć podejścia DNS podzielonego mózgu, jeśli cały dostęp aplikacji do usługi Azure OpenAI jest wykonywany za pośrednictwem bramy AI generowania w celu zapewnienia dodatkowej ochrony przed awarią regionalną. Jeśli tak nie jest, Prywatna strefa DNS rekordy będą musiały zostać ręcznie zmodyfikowane w przypadku utraty regionu świadczenia usługi Azure.
  4. Prywatny globalny moduł równoważenia obciążenia serwera powinien być używany do równoważenia obciążenia w wielu wystąpieniach bramy sztucznej inteligencji generowania w sposób aktywny/aktywny/pasywny. Platforma Azure nie ma natywnej usługi dla globalnego modułu równoważenia obciążenia serwera dla obciążeń wymagających prywatnego rozpoznawania nazw DNS. Dodatkowe informacje na temat tego tematu można znaleźć w tym nieoficjalnym przewodniku: https://github.com/adstuart/azure-crossregion-private-lb. Zamiast globalnego modułu równoważenia obciążenia serwera organizacje mogą osiągnąć wzorzec aktywny/pasywny przez przełączenie rekordu DNS dla bramy generacyjnych sztucznej inteligencji.