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à.
Opzioni di distribuzione per i broker Amazon MQ for RabbitMQ
i broker RabbitMQ possono essere creati come broker a istanza singola o in un'implementazione di cluster. Per entrambe le modalità di implementazione, Amazon MQ garantisce un'elevata durata archiviando i dati in modo ridondante.
Puoi accedere ai tuoi broker RabbitMQ utilizzando qualsiasi linguaggio di programmazione supportato da RabbitMQ e abilitando
Argomenti
Opzione 1: Amazon MQ per broker a istanza singola RabbitMQ
Un broker a istanza singola è composto da un broker in una zona di disponibilità dietro un Network Load NLB Balancer (). Il broker comunica con la tua applicazione e con un volume EBS di storage Amazon. Amazon EBS offre storage a livello di blocco ottimizzato per bassa latenza e throughput elevato.
L'utilizzo di un Network Load Balancer assicura che l'endpoint del broker Amazon MQ for RabbitMQ rimanga invariato se l'istanza del broker viene sostituita durante una finestra di manutenzione o a causa di guasti hardware Amazon sottostanti. EC2 Un load balancer di rete consente alle applicazioni e agli utenti di continuare a utilizzare lo stesso endpoint per connettersi al broker.
Il seguente diagramma illustra un broker a istanza singola Amazon MQ per RabbitMQ.
Opzione 2: distribuzione di cluster Amazon MQ per RabbitMQ
Un'implementazione cluster è un raggruppamento logico di tre nodi di broker RabbitMQ dietro un load balancer di rete, ognuno dei quali condivide utenti, code e uno stato distribuito su più zone di disponibilità.
In un'implementazione cluster, Amazon MQ gestisce automaticamente le policy del broker per abilitare il mirroring classico su tutti i nodi, garantendo un'elevata disponibilità. Ogni coda sottoposta a mirroring è composta da un nodo principale e uno o più mirror. Ogni coda ha il proprio nodo principale. Tutte le operazioni per una determinata coda vengono prima applicate sul nodo principale della coda e poi propagate ai mirror. Amazon MQ crea una policy di sistema predefinita che imposta ha-mode su all e ha-sync-mode su automatic. Ciò garantisce che i dati vengano replicati in tutti i nodi del cluster in diverse zone di disponibilità per una maggiore durata.
Nota
Durante una finestra di manutenzione, la manutenzione di un cluster viene eseguita su un nodo alla volta, mantenendo almeno due nodi in esecuzione in ogni momento. Ogni volta che un nodo viene fermato, le connessioni client verso tale nodo vengono interrotte e devono essere ristabilite. È necessario assicurarsi che il codice client sia progettato per riconnettersi automaticamente al cluster. Per ulteriori informazioni sulla connettività remota, consultare Ripristino automatico da guasti di rete.
Dal momento che Amazon MQ imposta ha-sync-mode: automatic durante una finestra di manutenzione, le code verranno sincronizzate quando ogni nodo rientra nuovamente nel cluster. La sincronizzazione delle code blocca tutte le altre operazioni di coda. È possibile ridurre l'impatto della sincronizzazione delle code durante le finestre di manutenzione mantenendo brevi le code.
La policy predefinita non deve essere eliminata. Se elimini questa policy, Amazon MQ la ricreerà automaticamente. Amazon MQ garantisce inoltre che le proprietà di alta disponibilità vengano applicate a tutte le altre policy create su un broker del cluster. Se si aggiunge una policy senza le proprietà di alta disponibilità, Amazon MQ le aggiungerà automaticamente. Se si aggiunge una policy con proprietà di alta disponibilità diverse, Amazon MQ le sostituirà. Per ulteriori informazioni sul mirroring classico, consultare Code classiche sottoposte a mirroring
Il diagramma seguente illustra una distribuzione di broker di cluster RabbitMQ con tre nodi in tre zone di disponibilità (AZ), ciascuna con il proprio EBS volume Amazon e uno stato condiviso. Amazon EBS offre storage a livello di blocco ottimizzato per bassa latenza e throughput elevato.
