Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Modelli di evacuazione della zona di disponibilità
Dopo aver rilevato l'impatto in una singola zona di disponibilità, il passaggio successivo consiste nell'evacuare quella zona di disponibilità. Ci sono due risultati che l'evacuazione deve raggiungere.
Innanzitutto, vuoi interrompere l'invio di lavoro alla zona di disponibilità interessata. Ciò potrebbe significare cose diverse in architetture diverse. In un carico di lavoro di richiesta/risposta, ciò significherebbe impedire che cose come le richieste HTTP o gRPC provenienti dai clienti vengano inviate al sistema di bilanciamento del carico o ad altre risorse nella zona di disponibilità. In un sistema di elaborazione in batch o in coda, ciò potrebbe comportare l'interruzione del lavoro di elaborazione delle risorse di elaborazione nella zona di disponibilità interessata. Dovrai inoltre impedire che le risorse nelle zone di disponibilità non interessate interagiscano con le risorse nella zona di disponibilità interessata, ad esempio un'istanza EC2 che invia traffico a uninterfaccia VPC endpointnella zona di disponibilità interessata o connessione all'istanza principale di un database.
Il secondo risultato è impedire che venga fornita nuova capacità nella zona di disponibilità interessata. Questo è importante perché è probabile che le nuove risorse, come le istanze o i container EC2, che vengono fornite nella zona di disponibilità interessata abbiano lo stesso impatto delle risorse esistenti. Inoltre, poiché il primo risultato impedisce loro l'invio di lavoro, non possono assorbire il carico per cui sono stati predisposti a gestire. Ciò comporta un aumento del carico sulle risorse esistenti, che alla fine può portare abrunireo totale indisponibilità del carico di lavoro. Sono disponibili diversi servizi di scalabilità automatica inAWSladdove applicabile:Scalabilità automatica di Amazon EC2