ApsaraMQ for RabbitMQ permite converter instâncias entre clusters compartilhados e dedicados durante operações de upgrade ou downgrade. Conheça as condições e os possíveis impactos dessa conversão.
Instâncias compartilhadas e dedicadas
ApsaraMQ for RabbitMQ oferece as seguintes arquiteturas de implantação de instâncias para cada série:
|
Série |
Instâncias compartilhadas |
Instâncias dedicadas |
|
Série de assinatura |
Professional Edition, Enterprise Edition |
Enterprise Platinum Edition |
|
Série Serverless |
Shared |
Dedicated |
Condições
Instâncias de séries diferentes não podem ser convertidas. Contudo, instâncias da mesma série suportam upgrade ou downgrade entre especificações de forma transparente.
Instâncias de assinatura mais antigas podem apresentar erros durante o upgrade ou downgrade. Caso não seja possível realizar a operação, envie um ticket para obter assistência.
Somente instâncias em execução podem passar por upgrade ou downgrade.
Instâncias compartilhadas não suportam alteração direta do método de autenticação nem upgrade para edições Dedicated ou Serverless que utilizam autenticação de identidade open-source. Para usar autenticação de identidade open-source, adquira uma nova instância Dedicated ou Serverless. Crie a nova instância e valide seu ambiente de negócios antes de liberar a instância antiga.
Conversões entre arquiteturas suportam apenas upgrades ou downgrades de especificação dentro da mesma série. Conversões diretas entre séries distintas ou entre sistemas de autenticação diferentes não são suportadas.
Procedimento de migração
A conversão de instâncias envolve os seguintes tipos de migração:
Migração de cluster
-
Upgrade
Quando uma instância migra de um cluster compartilhado para um cluster dedicado, um novo cluster é criado e passa a ser o cluster de destino da migração.
-
Downgrade
Quando uma instância migra de um cluster dedicado para um cluster compartilhado, o cluster compartilhado serve diretamente como destino da migração.
Migração de armazenamento
Fase de gravação dupla e leitura dupla: o roteamento de leitura e gravação é estabelecido no cluster de destino. Ambos os clusters aceitam leitura e gravação.
Fase de gravação única e leitura dupla: o cluster de origem deixa de aceitar gravações, mas permanece disponível para leitura. O cluster de destino aceita leitura e gravação.
Fase de aguardo pelo consumo completo do cluster de origem: o sistema aguarda o consumo de todas as mensagens no cluster de origem. Se houver mensagens não consumidas acumuladas ou mensagens agendadas não expiradas, esta fase leva mais tempo.
Fase de gravação única e leitura única no cluster de destino: após o consumo de todas as mensagens do cluster de origem, esse cluster deixa de aceitar leituras e gravações. Todo o tráfego é roteado para o cluster de destino e a migração é concluída.
Migração de conexão
-
Ponto de acesso VPC / Ponto de acesso de rede pública
-
Migração do cluster compartilhado para o cluster dedicado
O servidor não migra as conexões ativamente. Após o início da migração, novas conexões são direcionadas diretamente ao cluster de destino, mas as conexões existentes no cluster de source permanecem ativas. Para garantir que todas as conexões utilizem o novo cluster, reinicie sua aplicação para reconectar.
-
Migração do cluster dedicado de volta para o cluster compartilhado
Como o cluster dedicado precisa ser descomissionado, o servidor encerra ativamente as conexões existentes no cluster de source. Se o cliente suportar reconexão automática, ele se reconecta ao cluster de destino automaticamente.
-
-
Endpoint PrivateLink
Todas as conexões que utilizam endpoints PrivateLink sofrem desconexões de alguns minutos durante a migração da instância.
Impactos da migração
Quando um cluster dedicado migra de volta para um cluster compartilhado, as conexões são encerradas ativamente. Execute as migrações em horários de baixo tráfego e certifique-se de que o cliente tenha um mecanismo de reconexão robusto. Para mais detalhes, consulte Configure automatic client reconnection.
Para conexões via ponto de acesso VPC ou de rede pública, as conexões existentes só migram para o cluster de destino após o reinício da aplicação ou do servidor (por exemplo, durante um upgrade do cluster de source). Upgrades do cluster de source ou ações semelhantes podem causar desconexões inesperadas. Para concluir a transição para o cluster de destino, reinicie sua aplicação em horários de baixo tráfego.
Para conexões via endpoint PrivateLink, ocorrem desconexões de alguns minutos durante a migração. Execute as migrações em horários de baixo tráfego e certifique-se de que o cliente tenha um mecanismo de reconexão robusto.
Se o cluster de source tiver mensagens não consumidas acumuladas ou mensagens agendadas não expiradas, a fase de migração de armazenamento levará mais tempo.
FAQ
O que considerar ao fazer upgrade de uma instância RabbitMQ da Professional Edition para a Enterprise Edition?
Ponto de entrada: verifique se o botão Upgrade está disponível no canto superior direito do console da instância. Se o botão estiver presente, a instância suporta operações de upgrade.
Momento adequado: execute o upgrade em horários de baixo tráfego.
Estabilidade da conexão: em geral, upgrades não causam desconexões. Mesmo assim, implemente lógica de reconexão automática no código da aplicação como medida adicional de segurança. Para mais informações sobre a configuração de reconexão, consulte Automatic Reconnection.
Retenção de configuração: o upgrade apenas aumenta os limites de recursos. As configurações existentes — como Queues, Vhosts e outros metadados — permanecem inalteradas, e o endpoint de acesso não é modificado.