Desde a sua criação, houve um número crescente de migrações para um ambiente baseado em nuvem. Afinal, a computação em nuvem pode trazer muitos benefícios para as empresas, principalmente aquelas que trabalham com big data.
No entanto, à medida que a demanda cresce, os custos também aumentam, e você pode se encontrar em uma situação em que as despesas mensais com a nuvem se tornam muito altas e os negativos logo superam os benefícios de operar na nuvem. Ou talvez você tenha requisitos de segurança ou conformidade exigindo que você tenha um controle mais direto de seus sistemas. Em última análise, isso pode justificar a migração de volta para um ambiente local.
A AWS fornece ferramentas de monitoramento e gerenciamento para executar nosso sistema na nuvem, com visibilidade e controle para otimização. No entanto, quando nos encontramos prontos para uma solução local, pode ser um desafio migrar nossos dados e recriar todas as ferramentas para gerenciar nossos sistemas adequadamente.
Neste blog, discutiremos como você pode migrar seus sistemas da AWS para um datacenter local e como o ClusterControl pode ajudar a simplificar o processo.
Conceitos
Antes de começarmos, vamos abordar alguns conceitos básicos sobre Amazon Cloud e ClusterControl.
AWS
Amazon Web Services (AWS) é uma plataforma de infraestrutura como serviço composta por um grande número de serviços independentes e semi-independentes. O objetivo da plataforma de Infraestrutura como Serviço é oferecer, em uma base de commodities, serviços que anteriormente exigiam a compra de componentes de infraestrutura de capital intensivo, como servidores de ponta, roteadores de rede e switches, e para grandes empresas, até mesmo seus datacenters próprios.
RDS
O Amazon Relational Database Service (RDS) facilita a configuração, operação e dimensionamento de um banco de dados relacional na nuvem. Ele fornece capacidade econômica e redimensionável enquanto automatiza tarefas de administração demoradas, como provisionamento de hardware, configuração de banco de dados, aplicação de patches e backups.
O Amazon RDS está disponível em vários tipos de instância de banco de dados e oferece seis sistemas de gerenciamento de banco de dados familiares para você escolher, incluindo Amazon Aurora, PostgreSQL, MySQL, MariaDB, Oracle Database e SQL Server.
EC2
Amazon Elastic Compute Cloud (EC2) é um serviço que fornece capacidade de computação segura e redimensionável na nuvem. Ele foi projetado para tornar a computação em nuvem em escala da Web mais fácil para os desenvolvedores.
A interface web simples do Amazon EC2 permite obter e configurar a capacidade com o mínimo de atrito. Ele fornece controle total de seus recursos de computação e permite que você execute no ambiente de computação comprovado da Amazon.
Controle de Cluster
ClusterControl é um sistema de gerenciamento abrangente para bancos de dados de código aberto que automatiza a implantação, as funções de gerenciamento e o monitoramento de integridade e desempenho a partir de um único painel.
O ClusterControl oferece suporte à implantação, gerenciamento, monitoramento e dimensionamento para diferentes tecnologias de banco de dados em qualquer ambiente.
Por que migrar para o local?
Como mencionamos anteriormente, os motivos mais comuns para migrar da AWS para um ambiente local são custos, segurança, conformidade ou execução de aplicativos locais. Na AWS, você não sabe o que está acontecendo nos bastidores da infraestrutura. Você só sabe se tudo está funcionando. Se você tiver um desempenho ruim ou anomalias, a única solução é entrar em contato com o suporte da Amazon.
Exemplo de cenário de migração
Na AWS, você tem dois produtos diferentes relacionados a este blog:EC2 e RDS.
A principal diferença entre eles é que no EC2, você tem acesso SSH ao servidor e deve gerenciar o banco de dados você mesmo. O RDS é um serviço de banco de dados hospedado e você só tem acesso à instância do banco de dados.
No RDS, como você não tem acesso SSH, você precisa criar um dump e importá-lo para o novo servidor, ou configurar a replicação e promover a réplica para o novo primário. Para ambas as opções, o processo é manual. Você também pode adicionar um balanceador de carga para melhorar esse processo. Cobrimos essa tarefa nestes blogs:Parte 1 e Parte 2.
Então, vamos nos concentrar na migração do EC2.
Em nosso exemplo, vamos ver como migrar o MySQL do AWS EC2 para um data center local. Usaremos um ambiente de replicação MySQL, mas essas etapas devem funcionar para outras tecnologias como o PostgreSQL.
Vamos supor que você tenha seu banco de dados MySQL principal em execução em uma instância do EC2. No data center local, também presumiremos que você tenha o ClusterControl instalado e um servidor de banco de dados atualizado para o qual migrar.
No console de gerenciamento da AWS, você deve ter algo assim no EC2 seção de instâncias:
Primeiro, você precisará importar seu nó primário atual em execução no EC2 para ClusterControl. Para esse processo de importação, você precisa abrir a porta 3306 editando o grupo de segurança associado à instância do EC2.
Depois disso, dentro do ClusterControl, vá para a seção Importar:
Ali, você pode escolher a tecnologia de banco de dados, neste exemplo MySQL Replication, e você deve especificar o usuário, a chave ou a senha e a porta para se conectar ao seu servidor via SSH. Você também precisa fornecer o nome do seu novo cluster.
Após configurar as informações de acesso SSH, você deve definir algumas informações do banco de dados como as credenciais de administrador do banco de dados, porta e basedir. Além disso, você pode habilitar os recursos ClusterControl Node AutoRecovery e Cluster AutoRecovery para o novo cluster.
Depois, você precisa adicionar seu servidor usando o endereço IP ou nome do host e pressionar Importar.
Uma vez feito isso, você pode monitorar o status do trabalho de importação do Monitor de atividade do ClusterControl.
Quando a tarefa for concluída, você verá o nó do banco de dados na página principal Tela ClusterControl:
Certifique-se de habilitar a geração de log binário em seu banco de dados mestre atual.
Agora, você pode adicionar seu novo nó primário futuro como uma nova réplica de seu banco de dados primário atual. Para isso, vá para ClusterControl -> Select Cluster -> Cluster Actions -> Add Replication Slave.
Aqui, você precisa adicionar o nome do host ou endereço IP da nova réplica servidor e se desejar que o ClusterControl instale o software para você.
Certifique-se de ter conectividade da AWS para as portas 3306 e 9999 no servidor local.
ClusterControl prepara a réplica com dados fazendo um backup dinâmico do primário, transmitindo-o para a réplica e restaurando-o lá. Uma vez restaurado, o nó de réplica é conectado ao nó primário para que possa acompanhar os eventos e entrar em sincronia. Observe que, para bancos de dados grandes executados com alguma carga, convém evitar a carga extra dessa operação no nó primário. Nesse caso, é possível criar o nó de réplica primeiro a partir de um backup existente e, em seguida, conectar a réplica, para que ela alcance o nó primário.
Após esta tarefa, você deve ter algo assim:
Você também pode verificar sua topologia na seção ClusterControl Topology.
Então, você precisa promover a réplica para primária (ClusterControl -> Select Cluster -> Node Actions -> Promote Slave) e altere o endpoint em seu aplicativo.
Para melhorar essa topologia, você pode adicionar um balanceador de carga para gerenciar o tráfego do servidor de aplicativos para o banco de dados. Ao usar um balanceador de carga, você não precisará alterar o endpoint do seu aplicativo durante a migração; o balanceador de carga mudará o nó primário de forma transparente.
Há muitas maneiras de realizar esta tarefa, e você deve ser capaz de adote uma estratégia como essa para seu ambiente, dependendo de sua infraestrutura, segurança, etc.
Por motivos de segurança, você deve considerar o uso de uma VPN entre a AWS e o ambiente local.
No caso de uma topologia multimestre como Galera Cluster, você só precisa adicionar os nós que deseja no local, mas tenha cuidado com a latência. Você pode usar, por exemplo, diferentes segmentos do Galera para diminuir o uso da rede.
Considerações sobre migração
Finalmente, aqui estão algumas considerações a serem levadas em consideração se você quiser sair da AWS e começar a usar seu próprio ambiente:
- Monitoramento:não se esqueça de usar um sistema de monitoramento. Você precisa saber o que está acontecendo em seu sistema o tempo todo!
- Estratégia de recuperação de desastres:você deve considerar um bom DRP. Em geral, você deve ter as informações em três locais físicos diferentes:principal, réplica e backup.
- Alta disponibilidade:hoje em dia, a alta disponibilidade é obrigatória na maioria dos ambientes de produção, portanto, você precisa pensar na melhor solução de alta disponibilidade, dependendo da sua infraestrutura.
- Escalonamento:você deve poder dimensionar se necessário no futuro ou para um evento específico.
- Reversão:se você deseja migrar da AWS para um ambiente local, lembre-se de que algo pode dar errado (como em qualquer tipo de migração), portanto, você deve ter um plano de reversão.
- Suponha que você esteja atrás de algum tipo de ambiente híbrido, com instâncias em execução na AWS e no local. Nesse caso, o ClusterControl é uma excelente opção para monitoramento, gerenciamento de disponibilidade, backups, dimensionamento e muito mais. Experimente!
Encerrando
Às vezes, operar na nuvem não é a melhor opção, e você pode precisar migrar de volta para uma solução local. Esperamos que este blog tenha fornecido algumas informações úteis sobre como migrar seus dados baseados em MySQL para seu data center local da AWS e como o ClusterControl fornece as ferramentas necessárias para gerenciar seus sistemas adequadamente.
Depois de concluir sua migração com êxito, aprimore seu sistema de monitoramento com estratégias proativas, como alertas preditivos. Confira nossa postagem recentemente atualizada sobre Monitoramento de banco de dados com ClusterControl para saber mais.
Para obter mais atualizações sobre dicas de gerenciamento de banco de dados e práticas recomendadas, assine nosso blog, feed RSS e siga-nos no LinkedIn e no Twitter.
