

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

# Opções de implantação de agentes do Amazon MQ para RabbitMQ
<a name="rabbitmq-broker-architecture"></a>

Agentes RabbitMQ podem ser criados como *agentes de instância única* ou em uma *implantação de cluster*. Para ambos os modos de implantação, o Amazon MQ oferece alta durabilidade armazenando seus dados de forma redundante.

Você pode acessar seus agentes do RabbitMQ usando [qualquer linguagem de programação compatível com o RabbitMQ](https://www.rabbitmq.com/devtools.html) e habilitando o TLS para os seguintes protocolos:
+ [AMQP (0-9-1)](https://www.rabbitmq.com/specification.html)

**Topics**
+ [Opção 1: agente de instância única do Amazon MQ para RabbitMQ](#rabbitmq-broker-architecture-single-instance)
+ [Opção 2: implantação do cluster do Amazon MQ para RabbitMQ](#rabbitmq-broker-architecture-cluster)

## Opção 1: agente de instância única do Amazon MQ para RabbitMQ
<a name="rabbitmq-broker-architecture-single-instance"></a>

Um *agente de instância única* é composto por um agente em uma zona de disponibilidade atrás de um Balanceador de carga da rede (NLB). O agente se comunica com sua aplicação e com um volume de armazenamento do Amazon EBS. O Amazon EBS fornece armazenamento em nível de bloco otimizado para baixa latência e alta taxa de transferência.

 O uso de um Balanceador de carga da rede garante que seu endpoint do agente do Amazon MQ para RabbitMQ permaneça inalterado se a instância do agente for substituída durante uma janela de manutenção ou devido a falhas de hardware subjacentes do Amazon EC2. Um Balanceador de carga da rede permite que suas aplicações e usuários continuem a usar o mesmo endpoint para se conectar ao agente.

O diagrama a seguir ilustra um agente de instância única do Amazon MQ para RabbitMQ.

![\[Diagram showing client, load balancer, Amazon MQ broker, and EBS volume in Nuvem AWS.\]](http://docs.aws.amazon.com/pt_br/amazon-mq/latest/developer-guide/images/amazon-mq-rabbitmq-broker-architecture-single-broker.png)


## Opção 2: implantação do cluster do Amazon MQ para RabbitMQ
<a name="rabbitmq-broker-architecture-cluster"></a>

A *implantação de cluster* é um agrupamento lógico de três nós do agente RabbitMQ por trás de um Balanceador de Carga da Rede, cada um compartilhando usuários, filas e um estado distribuído em várias Zonas de Disponibilidade (AZ).

Em uma implantação de cluster, o Amazon MQ gerencia automaticamente as políticas de agente para habilitar o espelhamento clássico em todos os nós, garantindo alta disponibilidade (HA). Cada fila espelhada consiste em um nó *principal* e um ou mais *espelhos*. Cada fila tem seu próprio nó principal. Todas as operações para uma determinada fila são aplicadas primeiro no nó principal da fila e depois propagadas para espelhos. O Amazon MQ cria uma política de sistema padrão que define o `ha-mode ` para `all` e `ha-sync-mode` para `automatic`. Isso garante que os dados sejam replicados para todos os nós do cluster em diferentes zonas de disponibilidade para maior durabilidade.

**nota**  
 Em uma implantação de cluster, se ocorrer uma interrupção na zona de disponibilidade, o Amazon MQ tentará automaticamente realocar os nós afetados do RabbitMQ para uma zona de disponibilidade diferente para manter o tamanho do cluster. Quando a interrupção for resolvida, o cluster será automaticamente rebalanceado entre as zonas de disponibilidade. 

**nota**  
Durante uma *janela de manutenção*, toda a manutenção de um cluster é realizada em um nó de cada vez, mantendo pelo menos dois nós em execução o tempo todo. Cada vez que um nó é derrubado, as conexões de cliente para esse nó são cortadas e precisam ser restabelecidas. Você deve garantir que seu código de cliente foi projetado para se reconectar automaticamente ao cluster. Para obter mais informações sobre a recuperação de conexões, consulte [Etapa 1: Recuperação automática de falhas de rede](best-practices-network-resilience.md#automatically-recover-from-network-failures).  
Como o Amazon MQ define `ha-sync-mode: automatic`, durante uma janela de manutenção, as filas serão sincronizadas quando cada nó voltar a ingressar no cluster. A sincronização de filas bloqueia todas as outras operações de fila. Você pode atenuar o impacto da sincronização de filas durante as janelas de manutenção mantendo as filas curtas.

A política padrão não deve ser excluída. Se você excluí-la, o Amazon MQ vai recriá-la automaticamente. O Amazon MQ também garantirá que as propriedades de HA sejam aplicadas a todas as outras políticas criadas em um agente em cluster. Se você adicionar uma política sem as propriedades de HA, o Amazon MQ as adicionará para você. Se você adicionar uma política com diferentes propriedades de alta disponibilidade, o Amazon MQ as substituirá. Para obter mais informações sobre o espelhamento clássico, consulte [filas espelhadas](https://www.rabbitmq.com/ha.html).

 O diagrama a seguir ilustra uma implantação do agente de cluster RabbitMQ com três nós em três zonas de disponibilidade (AZ), cada um com seu próprio volume do Amazon EBS e um estado compartilhado. O Amazon EBS fornece armazenamento em nível de bloco otimizado para baixa latência e alta taxa de transferência. 

![\[Ilustra a arquitetura do agente de implantação de cluster para agentes RabbitMQ.\]](http://docs.aws.amazon.com/pt_br/amazon-mq/latest/developer-guide/images/amazon-mq-rabbitmq-broker-architecture-cluster-broker.png)
