Considerações sobre continuidade de negócios e recuperação de desastres (BCDR) com o Serviço OpenAI do Azure

O Azure OpenAI está disponível em várias regiões. Ao criar um recurso do Azure OpenAI, você especifica uma região. A partir de então, seu recurso e todas as suas operações permanecem associados a essa região de servidor do Azure.

É raro, mas não impossível, encontrar um problema de rede que atinge uma região inteira. Se o seu serviço precisa estar sempre disponível, você deve projetá-lo para failover em outra região ou dividir a carga de trabalho entre duas ou mais regiões. Ambas as abordagens exigem pelo menos dois recursos do Azure OpenAI em regiões diferentes. Este artigo fornece recomendações gerais sobre como implementar a continuidade de negócios e recuperação de desastres (BCDR) para seus aplicativos Azure OpenAI.

Por padrão, o serviço Azure OpenAI fornece um SLA padrão. Embora a resiliência padrão possa ser suficiente para muitos aplicativos, os aplicativos que exigem altos graus de resiliência e continuidade de negócios devem tomar medidas adicionais para fortalecer ainda mais sua infraestrutura modelo.

Implantações padrão

Nota

Se você puder usar implantações de Padrão Global, deverá usá-las. As implantações de Data Zone são a próxima melhor opção para organizações que exigem que o processamento de dados aconteça inteiramente dentro de um limite geográfico.

1. Para implantações padrão, o padrão é implantação de zona de dados (opções EUA/UE).

2. Você deve implantar dois recursos do Serviço OpenAI do Azure na Assinatura do Azure. Um recurso deve ser implantado em sua região preferida e o outro deve ser implantado em sua região secundária/failover. O serviço Azure OpenAI aloca cota no nível de assinatura + região, para que eles possam viver na mesma assinatura sem impacto na cota.

3. Você deve ter uma implantação para cada modelo que planeja usar implantado no recurso do Serviço OpenAI do Azure em sua região preferida do Azure e deve duplicar essas implantações de modelo na região secundária/de failover. Aloque a cota completa disponível em sua implantação padrão para cada um desses pontos de extremidade. Isso fornece a taxa de transferência mais alta quando comparada à divisão de cotas em várias implantações.

4. Selecione a região de implantação com base na topologia da rede. Você pode implantar um recurso do Serviço OpenAI do Azure em qualquer região com suporte e, em seguida, criar um Ponto de Extremidade Privado para esse recurso em sua região preferida.

   • Uma vez dentro do limite do Serviço OpenAI do Azure, o Serviço OpenAI do Azure otimiza o roteamento e o processamento na computação disponível na zona de dados.
   • O uso de zonas de dados é mais eficiente e simples do que o balanceamento de carga autogerenciado em várias implantações regionais.

5. Se houver uma interrupção regional em que a implantação esteja em um estado inutilizável, você poderá usar a outra implantação na região secundária/passiva dentro da mesma assinatura.

   • Como as implantações primária e secundária são implantações de Zona, elas se baseiam no mesmo pool de capacidade de Zona que se baseia em todas as regiões disponíveis na Zona. A implantação secundária está protegendo contra o ponto de extremidade primário do Azure OpenAI estar inacessível.
   • Use um Gateway de IA Generativo que ofereça suporte ao balanceamento de carga e ao padrão de disjuntor, como o Gerenciamento de API, na frente dos pontos de extremidade do Serviço OpenAI do Azure, para que a interrupção durante uma interrupção regional seja minimizada ao consumo de aplicativos.
   • Se a cota dentro de uma determinada assinatura estiver esgotada, uma nova assinatura poderá ser implantada da mesma maneira que acima e seu ponto de extremidade implantado atrás do Generative AI Gateway.

Implantações provisionadas

Criar um pool de PTU empresarial

1. Para implantações provisionadas, recomendamos ter uma única implantação de PTU de zona de dados (disponível em 12/04/2024) que sirva como um pool corporativo de PTU. Você pode usar o Gerenciamento de API para gerenciar o tráfego de vários aplicativos para definir limites de taxa de transferência, registro, prioridade e lógica de failover.
   • Pense neste Pool de PTU Empresarial como um recurso de "pagamento privado conforme o uso" que protege contra o problema de vizinhos barulhentos que pode ocorrer em implantações padrão quando a demanda de serviço é alta. Sua organização terá acesso garantido e dedicado a um pool de capacidade que só está disponível para você e, portanto, independente de picos de demanda de outros clientes.
   • Isso lhe dá controle sobre quais aplicativos experimentam aumentos de latência primeiro, permitindo que você priorize o tráfego para seus aplicativos de missão crítica.
   • As implantações provisionadas são apoiadas por SLAs de latência que as tornam preferíveis às implantações padrão (pré-pagas) para cargas de trabalho sensíveis à latência.
   • A implantação de PTU corporativa também permite taxas de utilização mais altas à medida que o tráfego é suavizado entre cargas de trabalho de aplicativos, enquanto cargas de trabalho individuais tendem a ser mais propensas a picos.
2. Sua implantação principal de PTU corporativa deve estar em uma região diferente da implantação principal da Zona Padrão. Isso é para que, se houver uma interrupção regional, você não perca o acesso à implantação da PTU e à implantação da Zona Padrão ao mesmo tempo.

Implantação de PTU dedicada à carga de trabalho

1. Certas cargas de trabalho podem precisar ter sua própria implantação provisionada dedicada. Em caso afirmativo, você pode criar uma implantação de PTU dedicada para esse aplicativo.
2. A carga de trabalho e as implantações do pool de PTU corporativo devem proteger contra falhas regionais. Você pode fazer isso colocando o pool de PTU de carga de trabalho na Região A e o pool de PTU empresarial na Região B.
3. Essa implantação deve fazer failover primeiro para o Pool de PTU Empresarial e, em seguida, para a implantação Padrão. Isso implica que, quando a utilização da implantação da PTU da carga de trabalho exceder 100%, as solicitações ainda serão atendidas por pontos de extremidade PTU, permitindo um SLA de latência mais alto para esse aplicativo.

O benefício adicional dessa arquitetura é que ela permite empilhar implantações padrão com implantações provisionadas para que você possa discar seu nível preferido de desempenho e resiliência. Isso permite que você use a PTU para sua demanda de linha de base em cargas de trabalho e aproveite o pagamento conforme o uso para picos de tráfego.

Infraestruturas de apoio

A infraestrutura que dá suporte à arquitetura OpenAI do Azure precisa ser considerada nos projetos. Os componentes de infraestrutura envolvidos na arquitetura variam dependendo se os aplicativos consomem o serviço Azure OpenAI pela Internet ou por uma rede privada. A arquitetura discutida neste artigo pressupõe que a organização implementou um Generative AI Gateway. As organizações com uma pegada madura do Azure e conectividade híbrida devem consumir o serviço por meio de uma rede privada, enquanto as organizações sem conectividade híbrida, ou com aplicativos em outra nuvem, como GCP ou AWS, consumirão o serviço por meio do backbone público da Microsoft.

Projetando para consumo por meio do backbone público da Microsoft

As organizações que consomem o serviço por meio do backbone público da Microsoft devem considerar os seguintes elementos de design:

1. O Generative AI Gateway deve ser implantado de forma a garantir que esteja disponível no caso de uma interrupção regional do Azure. Se estiver usando o APIM (Gerenciamento de API do Azure), isso pode ser feito implantando instâncias de APIM separadas em várias regiões ou usando o recurso de gateway de várias regiões do APIM.

2. Um balanceador de carga de servidor global público deve ser usado para balancear a carga entre as várias instâncias do Generative AI Gateway de maneira ativa/ativa ou ativa/passiva. O Azure FrontDoor pode ser usado para cumprir essa função, dependendo dos requisitos da organização.

Projetando para o consumo através da rede privada

As organizações que consomem o serviço por meio de uma rede privada devem considerar os seguintes elementos de design:

1. A conectividade híbrida deve ser implantada de forma a proteger contra a falha de uma região do Azure. Os componentes sublinhados que suportam a conectividade híbrida consistem na infraestrutura de rede local da organização e no Microsoft ExpressRoute ou VPN.
2. O Generative AI Gateway deve ser implantado de forma a garantir que esteja disponível no caso de uma interrupção regional do Azure. Se estiver usando o APIM (Gerenciamento de API do Azure), isso pode ser feito implantando instâncias de APIM separadas em várias regiões ou usando o recurso de gateway de várias regiões do APIM.
3. Os Pontos de Extremidade Privados do Azure Private Link devem ser implantados para cada instância do Serviço OpenAI do Azure em cada região do Azure. Para o DNS Privado do Azure, uma abordagem de DNS split-brain pode ser usada se todo o acesso do aplicativo ao Serviço OpenAI do Azure for feito por meio do Generative AI Gateway para fornecer proteção adicional contra uma falha regional. Caso contrário, os registros DNS privados precisarão ser modificados manualmente no caso de perda de uma região do Azure.
4. Um balanceador de carga de servidor global privado deve ser usado para balancear a carga entre as várias instâncias do Generative AI Gateway de maneira ativa/ativa ou ativa/passiva. O Azure não tem um serviço nativo para balanceador de carga de servidor global para cargas de trabalho que exigem resolução DNS privada. Para obter informações adicionais sobre este tópico, você pode consultar este guia não oficial: https://github.com/adstuart/azure-crossregion-private-lb. Em vez de um balanceador de carga de servidor global, as organizações podem alcançar um padrão ativo/passivo alternando o registro DNS para o Generative AI Gateway.