Executar um MySQL Galera Cluster (seja a compilação Percona, MariaDB ou Codership) infelizmente não é compatível (nem faz parte) dos bancos de dados compatíveis com o Amazon RDS. A maioria dos bancos de dados suportados pelo RDS usa replicação assíncrona, enquanto o Galera Cluster é uma solução de replicação multimestre síncrona. O Galera também requer o InnoDB como seu mecanismo de armazenamento para funcionar corretamente e, embora você possa usar outros mecanismos de armazenamento, como MyISAM, não é aconselhável usar esse mecanismo de armazenamento devido à falta de manipulação de transações.
Devido à falta de suporte nativo no RDS, este blog se concentrará nas ofertas disponíveis ao escolher e hospedar seu cluster baseado em Galera usando um ambiente AWS.
Existem certamente muitas razões pelas quais você escolheria ou não a plataforma de nuvem AWS, mas para este tópico específico, vamos abordar as vantagens e os benefícios do que você pode aproveitar em vez de por que você escolheria a Plataforma AWS.
Os servidores virtuais (instâncias de computação elástica)
Como mencionado anteriormente, o MySQL Galera não faz parte do RDS e o InnoDB é um mecanismo de armazenamento transacional para o qual você precisa dos recursos certos para o requisito de sua aplicação. Deve ter capacidade para atender a demanda de tráfego de requisições do seu cliente. No momento deste artigo, sua única opção para executar o Galera Cluster é usar o EC2, a oferta de nuvem de instância de computação da Amazon.
Como você tem a vantagem de executar seu sistema em vários nós em instâncias do EC2, a execução de um Galera Cluster no EC2 versus no local não difere muito. Você pode acessar o servidor remotamente via SSH, instalar os pacotes de software desejados e escolher o tipo de compilação do Galera Cluster que deseja utilizar.
Além disso, com o EC2, essa oferta é mais elástica e flexível, permitindo que você forneça e ofereça uma configuração granular mais simples. Você pode aproveitar os serviços da Web para automatizar ou construir vários nós se precisar dimensionar seu ambiente ou, por exemplo, automatizar a construção de seu ambiente de teste ou desenvolvimento. Ele também oferece uma vantagem para criar rapidamente o ambiente desejado, escolher e configurar o sistema operacional desejado e obter os recursos de computação corretos que atendem às suas necessidades (como CPU, memória e armazenamento em disco). O EC2 elimina o tempo de espera pelo hardware , já que você pode fazer isso em tempo real. Você também pode aproveitar a ferramenta AWS CLI para automatizar a configuração do cluster Galera.
Preços para instâncias do Amazon EC2
O EC2 oferece várias opções muito flexíveis para consumidores que desejam hospedar seu ambiente Galera Cluster em nós de computação da AWS. O nível gratuito da AWS inclui 750 horas de instâncias t2.micro do Linux e do Windows, todos os meses, durante um ano. Você pode permanecer no nível gratuito usando apenas instâncias Micro do EC2, mas isso pode não ser a melhor opção para uso em produção.
Existem vários tipos de instâncias do EC2 para as quais você pode implantar ao provisionar seus nós Galera. Idealmente, essas famílias r4/r5/x1 (otimizadas para memória) e c4/c5 (otimizadas para computação) são a escolha ideal, e esses preços diferem dependendo do tamanho das necessidades de recursos do servidor e do tipo de sistema operacional.
Estes são os tipos de instâncias pagas que você pode escolher...
Sob demanda
Pague por capacidade de computação (por hora ou por segundo), depende do tipo de instância que você executa. Por exemplo, os preços podem diferir ao provisionar uma instância do Ubuntu versus uma instância do RHEL, além do tipo de instância. Não há compromissos de longo prazo ou pagamentos antecipados necessários. Ele também tem a flexibilidade de aumentar ou diminuir sua capacidade de computação. Essas instâncias são recomendadas para necessidades de ambiente flexível e de baixo custo, como aplicativos com cargas de trabalho de curto prazo, pontiagudas ou imprevisíveis que não podem ser interrompidas ou aplicativos que estão sendo desenvolvidos ou testados no Amazon EC2 pela primeira vez. Confira aqui para mais informações.
Anfitriões dedicados
Se você procura requisitos de conformidade e regulatórios, como a necessidade de adquirir um servidor dedicado que funcione em um hardware dedicado para uso, esse tipo de oferta atende às suas necessidades. Hosts dedicados podem ajudá-lo a atender aos requisitos de conformidade e reduzir custos, permitindo que você use sua licença de software vinculada ao servidor existente, incluindo Windows Server, SQL Server, SUSE Linux Enterprise Server, Red Hat Enterprise Linux ou outras licenças de software vinculadas a VMs , soquetes ou núcleos físicos, sujeitos aos seus termos de licença. Pode ser adquirido sob demanda (por hora) ou como reserva com até 70% de desconto no preço sob demanda. Confira aqui para mais informações.
Instâncias spot
Essas instâncias permitem que você solicite capacidade de computação sobressalente do Amazon EC2 por até 90% do preço sob demanda. Isso é recomendado para aplicativos com horários de início e término flexíveis, aplicativos que só são viáveis a preços de computação muito baixos ou usuários com necessidades de computação urgentes para grandes quantidades de capacidade adicional. Confira aqui para mais informações.
Instâncias reservadas
Este tipo de oferta de pagamento oferece a você a opção de obter um desconto de até 75% e, dependendo de qual instância você deseja reservar, você pode adquirir uma reserva de capacidade, dando-lhe confiança adicional em sua capacidade para iniciar instâncias quando você precisar delas. Isso é recomendado se seus aplicativos tiverem uso estável ou previsível, aplicativos que possam exigir capacidade reservada ou clientes que possam se comprometer a usar o EC2 por um período de 1 ou 3 anos para reduzir seus custos totais de computação. Confira aqui para mais informações.
Nota de preço
Uma última coisa com o EC2, eles também oferecem uma cobrança por segundo que também reduz o custo de minutos e segundos não utilizados em uma hora da conta. Isso é vantajoso se você estiver expandindo por um período mínimo de tempo, apenas para lidar com a solicitação de tráfego de um nó Galera ou no caso de você querer experimentar e testar em um nó específico por apenas um tempo de uso limitado.
Criptografia de banco de dados na AWS
Se você estiver preocupado com a confidencialidade de seus dados ou cumprir as leis exigidas para sua conformidade e regulamentos de segurança, a AWS oferece criptografia de dados em repouso. Se você estiver usando o MariaDB Cluster versão 10.2+, eles têm suporte de plug-in integrado para fazer interface com a API do Amazon Web Services (AWS) Key Management Service (KMS). Isso permite que você aproveite o serviço de gerenciamento de chaves do AWS-KMS para facilitar a separação de responsabilidades e o registro e auditoria remotos de solicitações de acesso de chave. Em vez de armazenar a chave de criptografia em um arquivo local, esse plug-in mantém a chave mestra no AWS KMS.
Ao iniciar o MariaDB pela primeira vez, o plug-in do AWS KMS se conectará ao AWS Key Management Service e solicitará que ele gere uma nova chave. O MariaDB armazenará essa chave no disco de forma criptografada. A chave armazenada no disco não pode ser usada para descriptografar os dados; em vez disso, em cada inicialização, o MariaDB se conecta ao AWS KMS e faz com que o serviço descriptografe as chaves armazenadas localmente. A chave descriptografada é armazenada na memória enquanto o processo do servidor MariaDB estiver em execução e essa chave descriptografada na memória é usada para criptografar os dados locais.
Como alternativa, ao implantar suas instâncias do EC2, você pode criptografar seu volume de armazenamento de dados com EBS (Elastic Block Storage) ou criptografar a própria instância. A criptografia para volumes do tipo EBS é suportada, embora possa ter um impacto, mas a latência é muito mínima ou mesmo não visível para os usuários finais. Para criptografia do tipo de instância do EC2, a maioria das instâncias grandes tem suporte. Portanto, se você estiver usando nós otimizados para computação ou memória, poderá aproveitar sua criptografia.
Abaixo está a lista de tipos de instâncias compatíveis...
- Uso geral:A1, M3, M4, M5, M5a, M5ad, M5d, T2, T3 e T3a
- Otimizado para computação:C3, C4, C5, C5d e C5n
- Memória otimizada:cr1.8xlarge, R3, R4, R5, R5a, R5ad, R5d, u-6tb1.metal, u-9tb1.metal, u-12tb1.metal, X1, X1e e z1d
- Armazenamento otimizado:D2, h1.2xlarge, h1.4xlarge, I2 e I3
- Computação acelerada:F1, G2, G3, P2 e P3
Você pode configurar sua conta da AWS para sempre habilitar a criptografia na implantação de suas instâncias do tipo EC2. Isso significa que a AWS criptografará novos volumes do EBS na inicialização e criptografará novas cópias de snapshots não criptografados.
Implantações Multi-AZ/Multi-Region/Multi-Cloud
Infelizmente, até o momento em que este artigo foi escrito, não há suporte direto no Console AWS (nem em nenhuma API da AWS) que ofereça suporte a implantações Multi-AZ/-Region/-Cloud para clusters de nós Galera.
Alta disponibilidade, escalabilidade e redundância
Para obter uma implantação multi-AZ, é recomendável provisionar seus nós galera em diferentes zonas de disponibilidade. Isso evita que o cluster fique inativo ou um mau funcionamento do cluster devido à falta de quorum.
Você também pode configurar um AWS Auto Scaling e criar um grupo de auto scaling para monitorar e fazer verificações de status para que seu cluster sempre tenha redundância, escalabilidade e alta disponibilidade. O Auto Scaling deve resolver seu problema caso seu nó fique inativo por algum motivo desconhecido.
Para implantação multi-região ou multi-nuvem, Galera tem seu próprio parâmetro chamado gmcast.segment para o qual você pode definir isso na inicialização do servidor. Este parâmetro é projetado para otimizar a comunicação entre os nós Galera e minimizar a quantidade de tráfego enviado entre segmentos de rede, incluindo retransmissão de conjunto de gravação e seleção de doador IST e SST.
Este tipo de configuração permite que você implante vários nós em diferentes regiões para seu Galera Cluster. Além disso, você também pode implantar seus nós Galera em um fornecedor diferente, por exemplo, se estiver hospedado no Google Cloud e desejar redundância no Microsoft Azure.
Eu recomendo que você confira nosso blog Multiple Data Center Setups Using Galera Cluster for MySQL ou MariaDB and Zero Downtime Network Migration With MySQL Galera Cluster Using Relay Node para obter mais informações sobre como implementar esses tipos de implantações.
Desempenho do banco de dados na AWS
Dependendo da demanda de sua aplicação, se suas consultas de memória consumindo as instâncias otimizadas de memória são sua escolha ideal. Se seu aplicativo tiver transações mais altas que exigem alto desempenho para servidores Web ou processamento em lote, escolha instâncias otimizadas para computação. Se você quiser saber mais sobre como otimizar seu Galera Cluster, confira este blog How to Improve Performance of Galera Cluster for MySQL or MariaDB.
Backups de banco de dados na AWS
A criação de backups pode ser difícil, pois não há suporte direto na AWS específico para a tecnologia MySQL Galera. No entanto, a AWS fornece uma solução de desastre e recuperação usando EBS Snapshots. Você pode tirar snapshots dos volumes do EBS anexados à sua instância e fazer um backup por agendamento usando o CloudWatch ou usando o Amazon Data Lifecycle Manager (Amazon DLM) para automatizar os snapshots.
Observe que os instantâneos obtidos são backups incrementais, o que significa que apenas os blocos no dispositivo que foram alterados após o instantâneo mais recente são salvos. Você pode armazenar esses snapshots no AWS S3 para economizar custos de armazenamento. Como alternativa, você pode usar ferramentas externas como Percona Xtrabackup e Mydumper (para backups lógicos) e armazená-los no AWS EFS -> AWS S3 -> AWS Glacier.
Você também pode configurar o Lifecycle Management na AWS se precisar que seus dados de backup sejam armazenados de maneira mais econômica. Se você tiver arquivos grandes e for utilizar o AWS EFS, poderá aproveitar a solução AWS Backup, pois essa também é uma solução simples, mas econômica.
Por outro lado, você também pode usar serviços externos (assim como ClusterControl) que fornece soluções de monitoramento e backup. Confira isso se quiser saber mais.
Monitoramento de banco de dados na AWS
A AWS oferece verificações de integridade e algumas verificações de status para fornecer visibilidade dos nós do Galera. Isso é feito por meio do CloudWatch e do CloudTrail.
O CloudTrail permite habilitar e inspecionar os logs e realizar auditorias com base em quais ações e rastreamentos foram feitos.
O CloudWatch permite coletar e rastrear métricas, coletar e monitorar arquivos de log e definir alarmes personalizados. Você pode configurá-lo de acordo com suas necessidades personalizadas e obter visibilidade de todo o sistema sobre a utilização de recursos, desempenho do aplicativo e integridade operacional. O CloudWatch vem com um nível gratuito, desde que você ainda esteja dentro de seus limites (veja a captura de tela abaixo.)
O CloudWatch também vem com um preço dependendo do volume de métricas distribuídas. Confira seus preços atuais, verificando aqui.
Atenção:há uma desvantagem em usar o CloudWatch. Ele não foi projetado para atender à integridade do banco de dados, especialmente para monitorar os nós do cluster MySQL Galera. Como alternativa, você pode usar ferramentas externas que oferecem gráficos de alta resolução ou gráficos que são úteis em relatórios e são mais fáceis de analisar ao diagnosticar um nó problemático.
Para isso, você pode usar o PMM da Percona, DataDog, Idera, VividCortex ou nosso próprio ClusterControl (já que o monitoramento é GRATUITO com a Comunidade ClusterControl). necessidades com base em seus requisitos de aplicação individuais. É muito importante que sua ferramenta de monitoramento seja capaz de notificá-lo de forma agressiva ou fornecer integração para sistemas de mensagens instantâneas como Slack, PagerDuty ou até mesmo enviar SMS ao escalar um estado de saúde grave.
Segurança de banco de dados na AWS
Proteger suas instâncias do EC2 é uma das partes mais vitais da implantação de seu banco de dados na nuvem pública. Você pode configurar uma sub-rede privada e configurar os grupos de segurança necessários apenas para permitir a porta ou o IP de origem, dependendo da sua configuração. Você pode definir seus nós de banco de dados com um acesso não remoto e apenas configurar um host de salto ou um Gateway de Internet, se os nós precisarem acessar a Internet para acessar ou atualizar pacotes de software. Você pode ler nosso blog anterior Deploying Secure Multicloud MySQL Replication on AWS and GCP with VPN sobre como configuramos isso.
Além disso, você pode proteger seus dados em trânsito usando uma conexão TLS/SSL ou criptografar seus dados quando estiverem em repouso. Se você estiver usando o ClusterControl, implantar um seguro de dados em trânsito é simples e fácil. Você pode conferir nosso blog SSL Key Management and Encryption of MySQL Data in Transit se quiser experimentar. Para dados em repouso, armazenar seus dados via S3 pode ser criptografado usando AWS Server-Side Encryption ou usar AWS-KMS que discuti anteriormente. Confira este blog externo sobre como configurar e aproveitar um cluster MariaDB usando AWS-KMS para que você possa armazenar seus dados com segurança em repouso.
Solução de problemas de cluster do Galera na AWS
O AWS CloudWatch pode ajudar especialmente ao investigar e verificar as métricas do sistema. Você pode verificar a rede, CPU, memória, disco e sua instância ou uso e equilíbrio de computação. No entanto, isso pode não atender aos seus requisitos ao investigar um caso específico.
O CloudTrail pode realizar rastreamentos sólidos de ações que foram governadas com base em sua conta específica da AWS. Isso ajudará você a determinar se as ocorrências não são provenientes do MySQL Galera, mas podem ser algum bug ou problemas no ambiente da AWS (como o Hyper-V está tendo problemas na máquina host em que sua instância, como convidada, está sendo hospedado.)
Se você estiver usando o ClusterControl, vá para Logs -> System Logs, você poderá navegar pelos logs de erros capturados do próprio nó do MySQL Galera. Além disso, o ClusterControl fornece monitoramento em tempo real que amplifica seu sistema de alarme e notificação em caso de emergência ou se o(s) nó(s) do MySQL Galera estiverem danificados.
Conclusão
A AWS não tem suporte puro para uma configuração do MySQL Galera Cluster, ao contrário do AWS RDS que tem compatibilidade com MySQL. Por isso, a maioria das recomendações ou opiniões sobre a execução de um Galera Cluster para uso em produção no ambiente AWS são baseadas em ambientes experientes e bem testados que estão em execução há muito tempo.
O MariaDB Cluster vem com uma grande produtividade, pois fornece constantemente suporte conciso para a solução de pilha de tecnologia da AWS. No próximo lançamento da versão 10.5 do MariaDB, eles oferecerão suporte para o S3 Storage Engine, que pode valer a pena esperar.
As ferramentas externas podem ajudá-lo a gerenciar e controlar seu MySQL Galera Cluster em execução na Nuvem AWS, portanto, não é uma grande preocupação se você tiver alguns dilemas e FUD sobre por que deve executar ou mudar para a Nuvem AWS Plataforma.
A AWS pode não ser a solução de tamanho único em alguns casos, mas fornece uma ampla variedade de soluções que você pode personalizar e adequá-la às suas necessidades.
Na próxima parte do nosso blog, veremos outra plataforma de nuvem pública, principalmente o Google Cloud, e veremos como podemos aproveitar se optarmos por executar nosso Galera Cluster em sua plataforma.
