Considerações de BCDR (Continuidade dos Negócios e Recuperação de Desastres) com o Serviço OpenAI do Azure

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

É raro, mas não impossível, que um problema de rede atinja toda uma região. Se o seu serviço precisar estar sempre disponível, você deverá projetá-lo para fazer 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 OpenAI do Azure em regiões diferentes. Este artigo fornece recomendações gerais sobre como implementar a BCDR (Continuidade dos Negócios e Recuperação de Desastres) para aplicativos do OpenAI do Azure.

Por padrão, o serviço OpenAI do Azure 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 dos negócios devem tomar medidas adicionais para fortalecer ainda mais sua infraestrutura de modelo.

Standard

Observação

Se você puder usar implantações Padrão Globais, use-as no lugar. As implantações de Zona de Dados são a segunda melhor opção para organizações que exigem que o processamento de dados ocorra inteiramente dentro de um limite geográfico.

1. Para Implantações Padrão, use a implantação de Zona de Dados (opções EUA/Europa).

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 preferencial e o outro deve ser implantado em uma região secundária/de failover. O Serviço OpenAI do Azure aloca a cota no nível de assinatura + região, para que possam residir na mesma assinatura sem afetar a 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 do Azure preferencial 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 à cota de divisão entre várias implantações.

4. Selecione a região de implantação com base na topologia de 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 entre a 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 entre 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árias e secundárias são implantações de zona, elas extraem do 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 OpenAI do Azure estar inacessível.
   • Use um Gateway de IA Generativa que dê 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, de modo que a interrupção durante uma interrupção regional seja minimizada para o 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 por trás do Gateway de IA Generativa.

Implantações provisionadas

Criar um Pool corporativo de PTU

1. Para implantações provisionadas, recomendamos ter uma única implantação de PTU de Zona de Dados (disponível 04/12/2024) que serve como um pool empresarial 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 em log, prioridade e lógica de failover.
   • Pense nesse Pool corporativo de PTU como um recurso de "pagamento conforme o uso privado” 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 dedicado e garantido a um pool de capacidade que só está disponível para você e, portanto, independente dos picos de demanda de outros clientes.
   • Isso fornece controle sobre qual experiência de aplicativos aumenta em latência primeiro, permitindo que você priorize o tráfego para seus aplicativos críticos.
   • As implantações provisionadas são apoiadas por SLAs de latência que as tornam preferíveis às implantações Padrão (pagas conforme o uso) para cargas de trabalho sensíveis a latência.
   • A Implantação corporativa de PTU também permite taxas de uso mais altas à medida que o tráfego diminui entre cargas de trabalho do aplicativo, enquanto cargas de trabalho individuais tendem a ser mais propensas a picos.
2. Sua implantação corporativa de PTU principal deve estar em uma região diferente da implantação da Zona Padrão primária. Isso é indicado para que, se houver uma interrupção regional, você não perca o acesso à implantação de PTU e à implantação da Zona Padrão ao mesmo tempo.

Implantação de PTU dedicada à carga de trabalho

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

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

Dar suporte à infraestrutura

A infraestrutura que dá suporte à arquitetura do OpenAI do Azure precisa ser considerada nos designs. Os componentes de infraestrutura envolvidos na arquitetura variam dependendo se os aplicativos consomem o Serviço OpenAI do Azure pela Internet ou por uma rede privada. A arquitetura discutida neste artigo pressupõe que a organização implementou um Gateway de IA Generativa. As organizações com um volume de memória aperfeiçoado 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.

Projetar 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 Gateway de IA Generativa deve ser implantado de maneira que garanta que ele esteja disponível no caso de uma interrupção regional do Azure. Se estiver usando o APIM (Gerenciamento de API do Azure), isso poderá ser feito implantando instâncias 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 Gateway de IA Generativa de maneira ativa/ativa ou ativa/passiva. O Azure FrontDoor pode ser usado para atender a essa função, dependendo dos requisitos da organização.

Projetar para consumo por meio 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 subjacentes que dão suporte à conectividade híbrida consistem na infraestrutura de rede local da organização e o Microsoft ExpressRoute ou a VPN.
2. O Gateway de IA Generativa deve ser implantado de maneira que garanta que ele esteja disponível no caso de uma interrupção regional do Azure. Se estiver usando o APIM (Gerenciamento de API do Azure), isso poderá ser feito implantando instâncias 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 Link Privado do Azure 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 DNS com partição de rede pode ser usada se todo o acesso do aplicativo ao Serviço OpenAI do Azure for feito por meio do Gateway de IA Generativa para fornecer proteção adicional contra uma falha regional. Caso contrário, os registros de DNS privado precisarão ser modificados manualmente em 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 Gateway de IA Generativa 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 de DNS privado. 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 por meio da alternância do registro DNS para o Gateway de IA Generativa.