Condividi tramite

Considerazioni su continuità aziendale e ripristino di emergenza (BCDR) con il Servizio OpenAI di Azure

  • Articolo

OpenAI di Azure è disponibile in più aree. Quando si crea una risorsa del servizio OpenAI di Azure, occorre specificare un'area. Da quel momento in poi, la risorsa e tutte le relative operazioni rimangono associate a tale area del server di Azure.

È raro, ma non impossibile, riscontrare un problema di rete che interessa un'intera area. Se il servizio deve essere sempre disponibile, è necessario progettarlo per eseguire il failover in un'altra area o suddividere il carico di lavoro tra due o più aree. Entrambi gli approcci richiedono almeno due risorse di OpenAI di Azure in aree diverse. Questo articolo fornisce consigli generali su come implementare continuità aziendale e ripristino di emergenza (BCDR) per le applicazioni OpenAI di Azure.

Per impostazione predefinita, il servizio Azure OpenAI fornisce un contratto di servizio predefinito. Anche se la resilienza predefinita può essere sufficiente per molte applicazioni, le applicazioni che richiedono elevati livelli di resilienza e continuità aziendale devono eseguire ulteriori passaggi per rafforzare ulteriormente l'infrastruttura del modello.

e distribuzioni standard

Nota

Se è possibile usare le distribuzioni Standard globali, è consigliabile usarle. Le distribuzioni dell'area dati rappresentano l'opzione migliore per le organizzazioni che richiedono l'elaborazione dei dati interamente entro un limite geografico.

  1. Per le distribuzioni standard viene predefinito la distribuzione dell'area dati (opzioni US/EU).

  2. È necessario distribuire due risorse del servizio Azure OpenAI nella sottoscrizione di Azure. Una risorsa deve essere distribuita nell'area preferita e l'altra deve essere distribuita nell'area secondaria/failover. Il servizio Azure OpenAI alloca la quota a livello di sottoscrizione e area, in modo che possano trovarsi nella stessa sottoscrizione senza alcun impatto sulla quota.

  3. È necessario avere una distribuzione per ogni modello che si intende usare distribuita nella risorsa del servizio Azure OpenAI nell'area di Azure preferita ed è necessario duplicare queste distribuzioni di modelli nell'area secondaria/di failover. Allocare la quota completa disponibile nella distribuzione Standard a ognuno di questi endpoint. In questo modo viene fornita la velocità effettiva più elevata rispetto alla suddivisione della quota tra più distribuzioni.

  4. Selezionare l'area di distribuzione in base alla topologia di rete. È possibile distribuire una risorsa del servizio OpenAI di Azure in qualsiasi area supportata e quindi creare un endpoint privato per tale risorsa nell'area preferita.

    • Una volta entro il limite del servizio OpenAI di Azure, il servizio OpenAI di Azure ottimizza il routing e l'elaborazione tra le risorse di calcolo disponibili nella zona dati.
    • L'uso delle zone dati è più efficiente e più semplice rispetto al bilanciamento del carico autogestito tra più distribuzioni a livello di area.

  5. Se si verifica un'interruzione a livello di area in cui la distribuzione è in uno stato inutilizzabile, è possibile usare l'altra distribuzione nell'area secondaria/passiva all'interno della stessa sottoscrizione.

    • Poiché entrambe le distribuzioni primarie e secondarie sono distribuzioni di zone, derivano dallo stesso pool di capacità zona che estrae da tutte le aree disponibili nella zona. La distribuzione secondaria protegge dall'endpoint OpenAI di Azure primario non raggiungibile.
    • Usare un gateway di intelligenza artificiale generativo che supporta il bilanciamento del carico e il modello di interruttore, ad esempio Gestione API davanti agli endpoint del servizio OpenAI di Azure, in modo da ridurre al minimo l'interruzione durante un'interruzione a livello di area per l'utilizzo delle applicazioni.
    • Se la quota all'interno di una determinata sottoscrizione è esaurita, è possibile distribuire una nuova sottoscrizione nello stesso modo di quanto sopra e il relativo endpoint distribuito dietro il gateway di intelligenza artificiale generativo.

Distribuzioni con provisioning

Creare un pool PTU aziendale

  1. Per le distribuzioni con provisioning, è consigliabile avere una singola distribuzione PTU della zona dati (disponibile 12/04/2024) che funge da pool aziendale di PTU. È possibile usare Gestione API per gestire il traffico da più applicazioni per impostare limiti di velocità effettiva, registrazione, priorità e logica di failover.
    • Si consideri questo pool PTU aziendale come una risorsa "Con pagamento in base al consumo" privata che protegge dal problema dei vicini rumorosi che possono verificarsi nelle distribuzioni Standard quando la domanda di servizio è elevata. L'organizzazione avrà garantito l'accesso dedicato a un pool di capacità disponibile solo per l'utente e quindi indipendentemente dai picchi di domanda di altri clienti.
    • In questo modo è possibile controllare l'esperienza delle applicazioni che aumentano prima di tutto la latenza, consentendo di classificare in ordine di priorità il traffico alle applicazioni cruciali.
    • Le distribuzioni con provisioning sono supportate da contratti di servizio di latenza che li rendono preferibili alle distribuzioni Standard (con pagamento in base al consumo) per carichi di lavoro sensibili alla latenza.
    • La distribuzione PTU aziendale consente anche tassi di utilizzo più elevati man mano che il traffico viene smussato tra i carichi di lavoro dell'applicazione, mentre i singoli carichi di lavoro tendono a essere più soggetti a picchi.
  2. La distribuzione PTU aziendale primaria deve trovarsi in un'area diversa rispetto alla distribuzione primaria della zona Standard. In questo modo, se si verifica un'interruzione a livello di area, non si perde l'accesso alla distribuzione PTU e alla distribuzione della zona Standard contemporaneamente.

Distribuzione PTU dedicata del carico di lavoro

  1. Alcuni carichi di lavoro potrebbero dover disporre della propria distribuzione con provisioning dedicata. In tal caso, è possibile creare una distribuzione PTU dedicata per tale applicazione.
  2. Le distribuzioni del carico di lavoro e del pool PTU aziendale devono proteggersi da errori a livello di area. A tale scopo, posizionare il pool PTU del carico di lavoro nell'area A e nel pool PTU aziendale nell'area B.
  3. Questa distribuzione deve eseguire prima il failover nel pool PTU aziendale e quindi nella distribuzione Standard. Ciò implica che quando l'utilizzo della distribuzione PTU del carico di lavoro supera il 100%, le richieste vengono comunque gestite dagli endpoint PTU, abilitando un contratto di servizio di latenza superiore per tale applicazione.

Diagramma dell'architettura del ripristino di emergenza.

Il vantaggio aggiuntivo di questa architettura è che consente di eseguire lo stack di distribuzioni Standard con distribuzioni con provisioning in modo da poter comporre il livello preferito di prestazioni e resilienza. In questo modo è possibile usare la PTU per la domanda di base tra carichi di lavoro e sfruttare i picchi di traffico con pagamento in base al consumo.

Diagramma di ridimensionamento con provisioning.

Supporto dell'infrastruttura

L'infrastruttura che supporta l'architettura OpenAI di Azure deve essere considerata nelle progettazioni. I componenti dell'infrastruttura coinvolti nell'architettura variano a seconda che le applicazioni utilizzano il servizio OpenAI di Azure tramite Internet o tramite una rete privata. L'architettura descritta in questo articolo presuppone che l'organizzazione abbia implementato un gateway di intelligenza artificiale generativo. Le organizzazioni con un footprint di Azure maturo e la connettività ibrida devono usare il servizio tramite una rete privata mentre le organizzazioni senza connettività ibrida o con applicazioni in un altro cloud, ad esempio GCP o AWS, utilizzeranno il servizio tramite il backbone pubblico Microsoft.

Progettazione per l'utilizzo tramite il backbone pubblico Microsoft

Le organizzazioni che utilizzano il servizio tramite il backbone pubblico Microsoft devono considerare gli elementi di progettazione seguenti:

  1. Il gateway di intelligenza artificiale generativo deve essere distribuito in modo da garantire che sia disponibile in caso di interruzione a livello di area di Azure. Se si usa Gestione API (Azure Gestione API), questa operazione può essere eseguita distribuendo istanze di Gestione API separate in più aree o usando la funzionalità gateway in più aree di Gestione API.

  2. Un servizio di bilanciamento del carico del server globale pubblico deve essere usato per bilanciare il carico tra più istanze di Gateway di intelligenza artificiale generative in modo attivo/attivo/passivo. Frontdoor di Azure può essere usato per soddisfare questo ruolo a seconda dei requisiti dell'organizzazione.

Diagramma dell'architettura di failover.

Progettazione per l'utilizzo tramite la rete privata

Le organizzazioni che usano il servizio tramite una rete privata devono considerare gli elementi di progettazione seguenti:

  1. La connettività ibrida deve essere distribuita in modo da proteggersi dall'errore di un'area di Azure. I componenti di sottolineatura che supportano la connettività ibrida sono costituiti dall'infrastruttura di rete locale dell'organizzazione e da Microsoft ExpressRoute o VPN.
  2. Il gateway di intelligenza artificiale generativo deve essere distribuito in modo da garantire che sia disponibile in caso di interruzione a livello di area di Azure. Se si usa Gestione API (Azure Gestione API), questa operazione può essere eseguita distribuendo istanze di Gestione API separate in più aree o usando la funzionalità gateway in più aree di Gestione API.
  3. collegamento privato di Azure gli endpoint privati devono essere distribuiti per ogni istanza del servizio OpenAI di Azure in ogni area di Azure. Per Azure DNS privato, è possibile usare un approccio DNS split-brain se tutti gli accessi delle applicazioni al servizio OpenAI di Azure vengono eseguiti tramite il gateway di intelligenza artificiale generativo per garantire una protezione aggiuntiva da un errore a livello di area. In caso contrario, è necessario modificare manualmente i record DNS privato in caso di perdita di un'area di Azure.
  4. È consigliabile usare un servizio di bilanciamento del carico globale privato per il bilanciamento del carico tra più istanze di Gateway di intelligenza artificiale generative in modo attivo/attivo/passivo. Azure non dispone di un servizio nativo per il servizio di bilanciamento del carico globale del server per i carichi di lavoro che richiedono la risoluzione DNS privata. Per altre informazioni su questo argomento, è possibile fare riferimento a questa guida non ufficiale: https://github.com/adstuart/azure-crossregion-private-lb. Al posto di un servizio di bilanciamento del carico del server globale, le organizzazioni possono ottenere un modello attivo/passivo tramite l'attivazione/disattivazione del record DNS per il gateway di intelligenza artificiale generativa.