Comparando as ofertas do Galera Cluster Cloud:parte dois Google Cloud Platform (GCP)

Em nosso último blog, discutimos as ofertas disponíveis no Amazon Web Services (AWS) ao executar um MySQL Galera Cluster. Neste blog, continuaremos a discussão analisando mais detalhadamente quais são as ofertas para executar a mesma tecnologia de cluster, mas desta vez no Google Cloud Platform (GCP).

O GCP, como alternativa à AWS, atrai continuamente aplicativos adequados para DevOps, oferecendo suporte para uma ampla variedade de tecnologias full-stack, aplicativos em contêiner e grandes sistemas de banco de dados de produção. O Google Cloud é um ambiente completo e testado em batalha que alimenta sua própria infraestrutura de hardware no Google para produtos como YouTube e Gmail.

O GCP ganhou força em grande parte por causa de sua lista cada vez maior de recursos. Oferece suporte para plataformas como Visual Studio, Android Studio, Eclipse, Powershell e muitas outras. O GCP tem uma das maiores e mais avançadas redes de computadores e fornece acesso a várias ferramentas que ajudam você a se concentrar na criação de seu aplicativo.

Outra coisa que atrai clientes para migrar, importar ou usar o Google Cloud é o forte suporte e soluções para conteinerização. O Kubernetes (GKE:Google Kubernetes Engine) é construído em sua plataforma.

O GCP também lançou recentemente uma nova solução chamada Anthos. Este produto foi projetado para permitir que as organizações gerenciem cargas de trabalho usando a mesma interface no Google Cloud Platform (GCP) ou no local usando o GKE On-Prem e até mesmo em nuvens rivais, como Amazon Web Services (AWS) ou Azure.

Além dessas tecnologias, o GCP oferece tipos de máquina sofisticados e poderosos, otimizados para computação, como a família C2 no GCE, que é baseada na última geração de processadores escaláveis ​​Intel (Cascade Lake).

O GCP também continua a oferecer suporte ao código aberto, o que beneficia os usuários ao fornecer uma estrutura simples e bem suportada que facilita a entrega de um produto final em tempo hábil. Apesar desse suporte de tecnologia de código aberto, o GCP não oferece suporte nativo para a implantação ou configuração de um MySQL Galera Cluster. Neste blog, mostraremos a única opção disponível para você se desejar usar essa tecnologia, a implantação por meio de uma instância de computação que você mesmo deve gerenciar.

O Google Compute Engine (GCE)

O GCE tem um conjunto sofisticado e poderoso de nós de computação disponíveis para seu consumo. Ao contrário da AWS, o GCE possui o nó de computação mais poderoso disponível no mercado (n1-ultramem-160 com 160 vCPU e 3,75 TB de memória). A GCE também introduziu recentemente um novo tipo de família de instâncias de computação chamada tipo de máquina C2. Construídos com base na última geração de processadores escaláveis ​​Intel (Cascade Lake), os tipos de máquina C2 oferecem turbo all-core sustentado de até 3,8 GHz e fornecem total transparência na arquitetura das plataformas de servidor subjacentes; permitindo que você ajuste o desempenho. Os tipos de máquina C2 oferecem muito mais poder de computação, são executados em uma plataforma mais recente e geralmente são mais robustos para cargas de trabalho de computação intensiva do que os tipos de máquina N1 de alta CPU. As ofertas da família C2 são limitadas (no momento da redação deste artigo) e não estão disponíveis em todas as regiões e zonas. O C2 também não oferece suporte a discos permanentes regionais, embora seja um ótimo complemento para serviços de banco de dados com estado que exigem redundância e alta disponibilidade. Os recursos de uma instância C2 são demais para um nó Galera, então vamos nos concentrar nos nós de computação, que são ideais.

GCE também usa KVM como seu software de tecnologia de virtualização, enquanto a Amazon está usando Xen. Vamos dar uma olhada nos nós de computação disponíveis no GCE que são adequados para executar o Galera juntamente com sua equivalência no AWS EC2. Os preços diferem de acordo com a região, mas para este gráfico, usamos a região us-east usando o tipo de preço sob demanda para AWS.

Preços (Instância de computação, disco, vCPU, memória e rede)

O preço também depende da região onde está localizado, do tipo de SO ou licenciamento (RHEL vs Suse Linux Enterprise) e também do tipo de armazenamento em disco que você está usando.

O GCP também oferece descontos que permitem economizar o consumo de recursos. Para o Compute Engine, ele oferece diferentes descontos disponíveis.

Os descontos por uso prolongado se aplicam aos seguintes recursos:

• As vCPUs e a memória para tipos de máquina predefinidos e personalizados de uso geral
  

• As vCPUs e a memória para tipos de máquina com otimização de memória
  

• As vCPUs e a memória para tipos de máquina otimizados para computação
  

• As vCPUs e a memória para nós de locatário individual
  

• O custo premium de 10% para nós de locatário individual, mesmo se as vCPUs e a memória nesses nós estiverem cobertas por descontos por uso contínuo
  

• dispositivos GPU1
  

Observe que os descontos por uso prolongado não se aplicam a VMs criadas usando o ambiente flexível do App Engine e o Cloud Dataflow.

Você também pode usar descontos por uso contínuo ao comprar um VMS vinculado a um contrato. Esse tipo de escolha é ideal para cargas de trabalho previsíveis e necessidades de recursos. Ao adquirir um contrato de uso contínuo, você compra uma certa quantidade de vCPUs, memória, GPUs e SSDs locais com desconto em troca de se comprometer a pagar por esses recursos por 1 ou 3 anos. O desconto é de até 57% para a maioria dos recursos, como tipos de máquina ou GPUs. O desconto é de até 70% para tipos de máquina com otimização de memória. Uma vez adquirido, você será cobrado mensalmente pelos recursos adquiridos durante o período selecionado (independentemente de usar os serviços ou não).

Uma VM preemptiva é uma instância que você pode criar e executar a um preço muito mais baixo do que as instâncias normais. No entanto, o Compute Engine pode encerrar (prevenir) essas instâncias se exigir acesso a esses recursos para outras tarefas. As instâncias preemptivas usam capacidade excessiva do Compute Engine, portanto, a disponibilidade varia de acordo com o uso.

Se seus aplicativos forem tolerantes a falhas e puderem suportar possíveis preempções de instância, as instâncias preemptivas poderão reduzir significativamente os custos do Compute Engine. Por exemplo, trabalhos de processamento em lote podem ser executados em instâncias preemptivas. Se algumas dessas instâncias forem encerradas durante o processamento, o trabalho ficará lento, mas não será interrompido completamente. As instâncias preemptivas concluem suas tarefas de processamento em lote sem colocar carga de trabalho adicional em suas instâncias existentes e sem exigir que você pague o preço total por instâncias normais adicionais.

Para o Compute Engine, o tamanho do disco, a memória do tipo de máquina e o uso da rede são calculados em gigabytes (GB), em que 1 GB equivale a 230 bytes. Essa unidade de medida também é conhecida como gibibyte (GiB). Isso significa que o GCP oferece pagamento apenas com base no consumo de recursos que você alocou.

Agora, se você tiver um aplicativo de banco de dados de produção de alto nível, é recomendável (e ideal) anexar ou adicionar um disco permanente separado. Você usaria esse disco como seu volume de banco de dados, pois ele oferece desempenho de disco confiável e consistente no GCE. Quanto maior o tamanho configurado, maior o IOPS que ele oferece. Confira a lista de preços de discos permanentes para determinar o preço que você obteria. Além disso, o GCE possui um disco permanente regional adequado caso você precise de alta disponibilidade mais sólida e sustentável em seu cluster de banco de dados. O disco permanente regional adiciona mais redundância caso sua instância seja encerrada, falhe ou seja corrompida. Ele fornece replicação síncrona de dados entre duas zonas em uma região que acontece de forma transparente na instância de VM. No caso improvável de falha de zona, sua carga de trabalho pode fazer failover para outra instância de VM na mesma zona ou em uma zona secundária. Em seguida, você pode forçar a anexação do disco permanente regional a essa instância. O tempo de fixação forçada é estimado em menos de um minuto.

Se você armazena backups como parte de sua solução de recuperação de desastres e exige um volume que abrange todo o cluster, o GCP oferece Cloud Filestore, NetApp Cloud Volumes e algumas outras soluções alternativas de compartilhamento de arquivos. São serviços totalmente gerenciados que oferecem serviços padrão e premium. Você pode conferir a página de preços da NetApp aqui e os preços do Filestore aqui.

Criptografia Galera no GCP

O GCP não inclui suporte específico para o tipo de criptografia disponível para Galera. O GCP, no entanto, criptografa os dados do cliente armazenados em repouso por padrão, sem que você precise fazer nenhuma ação adicional. O GCP também oferece outra opção para criptografar seus dados usando chaves de criptografia gerenciadas pelo cliente (CMEK) com o Cloud KMS, bem como com chaves de criptografia fornecidas pelo cliente (CSEK). O GCP também usa criptografia SSL/TLS para todas as comunicações interceptadas à medida que os dados são movidos entre seu site e o provedor de nuvem ou entre dois serviços. Essa proteção é obtida criptografando os dados antes da transmissão; autenticando os terminais; e descriptografar e verificar os dados na chegada.

Como o Galera usa o MySQL nos bastidores (compilação Percona, MariaDB ou Codership), você pode aproveitar o plug-in de criptografia de gerenciamento de chave de arquivo do MariaDB ou usando os plug-ins do MySQL Keyring. Aqui está um blog externo da Percona que é um bom recurso sobre como você pode implementar isso.

Implantações Multi-AZ/Multi-Região/Multi-Cloud do Galera Cluster com GCP

Da mesma forma que a AWS, o GCP não oferece suporte direto para implantar um cluster Galera em um Multi-AZ/-Region/-Cloud.

Alta disponibilidade, escalabilidade e redundância do cluster Galera no GCP

Um dos principais motivos para usar um cluster de nó Galera é a alta disponibilidade, redundância e sua capacidade de dimensionamento. Se você estiver atendendo tráfego globalmente, é melhor atender seu tráfego com base em regiões com seu design de arquitetura, incluindo uma distribuição geográfica de seus nós de banco de dados. Para conseguir isso, a implantação multi-AZ e multirregional ou multinuvem/multidatacenter é recomendável e viável. Isso evita que o cluster fique inativo ou um mau funcionamento do cluster devido à falta de quorum.

Para ajudar você com seu design de escalabilidade, o GCP também tem um escalonador automático que pode ser configurado com um grupo de escalonamento automático. Isso funcionará desde que você tenha criado seu cluster como grupos de instâncias gerenciadas. Por exemplo, você pode monitorar a utilização da CPU ou confiar nas métricas do Stackdriver definidas em sua política de escalonamento automático. Isso permite provisionar e automatizar instâncias quando um determinado limite for atingido ou encerrar as instâncias quando elas voltarem ao estado normal.

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. Isso inclui retransmissão de conjunto de gravações e seleção de doadores IST e SST. Esse tipo de configuração permite implantar vários nós em diferentes regiões. Além disso, você também pode implantar seus nós Galera em um roteamento de fornecedor de nuvem diferente do GCP, AWS, Microsoft Azure ou no local.

Recomendamos 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 de cluster do Galera no GCP

Como não há suporte disponível para Galera no GCP, suas escolhas dependem dos requisitos e do design do tráfego do seu aplicativo e das demandas de recursos. Para consultas com alto consumo de memória, você pode começar com a instância n1-highmem-2. Instâncias de CPU alta (família n1-highcpu*) podem ser uma boa opção se for um banco de dados de alta transação ou uma boa opção para aplicativos de jogos.

A escolha do armazenamento correto e do IOPS necessário para o volume do banco de dados é essencial. Geralmente, o disco permanente baseado em SSD é sua escolha aqui. Depende do volume de tráfego necessário, talvez seja necessário verificar as opções de armazenamento do GCP para determinar o tamanho certo para seu aplicativo.

Também recomendamos que você verifique e leia nosso blog Como melhorar o desempenho do Galera Cluster para MySQL ou MariaDB para saber mais sobre como otimizar seu Galera Cluster.

Backups de dados do Galera no GCP

Não apenas os dados do MySQL Galera precisam ser copiados, você também deve fazer backup de toda a camada que compreende seu aplicativo de banco de dados. Isso inclui arquivos de registro (lógicos ou binários), arquivos externos, arquivos temporários, arquivos de despejo etc. O Google recomenda que você sempre crie um instantâneo de seus volumes de discos permanentes que estão sendo usados ​​por suas instâncias do GCE. Você pode facilmente criar e agendar instantâneos. Os instantâneos do GCP são armazenados no Cloud Storage e você pode selecionar o local ou a região desejada para o backup. Você também pode configurar um agendamento para seus instantâneos, bem como definir uma política de retenção de instantâneos.

Você também pode usar serviços externos como ClusterControl, que fornece soluções de monitoramento e backup. Confira isso se quiser saber mais.

Monitoramento de banco de dados de cluster do Galera no GCP

O GCP não oferece monitoramento de banco de dados ao usar o GCE. O monitoramento da integridade da sua instância pode ser feito por meio do Stackdriver. Para o banco de dados, porém, você precisará obter uma ferramenta de monitoramento externa que tenha métricas de banco de dados avançadas e altamente granulares. Há muitas opções que você pode escolher, como PMM by Percona, DataDog, Idera, VividCortex ou nosso próprio ClusterControl (o monitoramento é GRATUITO com a Comunidade ClusterControl).

Segurança de banco de dados de cluster do Galera no GCP

Conforme discutido em nosso blog anterior, você pode adotar a mesma abordagem para proteger seu banco de dados na nuvem pública. No GCP, você pode configurar uma sub-rede privada, regras de firewall para permitir apenas as portas necessárias para executar o Galera (principalmente as portas 3306, 4444, 4567, 4568). Você pode usar o NAT Gateway ou configurar um bastion host para acessar seus nós de banco de dados privados. Quando esses nós são encapsulados, eles não podem ser acessados ​​de fora das instalações do GCP. 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 criptografando 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, você pode seguir a discussão que afirmei anteriormente na seção Criptografia deste blog.

Solução de problemas do cluster Galera 

O GCP oferece o Stackdriver Logging, que você pode aproveitar para ajudá-lo com os requisitos de observabilidade, monitoramento e notificação. O melhor do Stackdriver Logging é que ele oferece integração com a AWS. Com ele você pode capturar os eventos de forma seletiva e então gerar um alerta baseado naquele evento. Isso pode mantê-lo informado sobre certos problemas que podem surgir e ajudá-lo durante a solução de problemas. O GCP também tem registros de auditoria do Cloud, que fornecem informações mais rastreáveis ​​de dentro do ambiente do GCP, da atividade do administrador, acesso a dados e eventos do sistema.

Se você estiver usando o ClusterControl, vá para Logs -> System Logs e 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

O Google Cloud Platform oferece uma ampla variedade de serviços eficientes e avançados que você pode aproveitar. De fato, existem prós e contras para cada uma das plataformas de nuvem pública, mas o GCP prova que a AWS não tem um bloqueio na nuvem.

É interessante que grandes empresas como o Vimeo estejam migrando para o GCP no local e obtiveram alguns resultados interessantes em sua pilha de tecnologia. A Bloomberg também está satisfeita com o GCP e está usando o Percona XtraDB Cluster (uma variante do Galera). Deixe-nos saber o que você pensa sobre o uso do GCP para configurações do MySQL Galera nos comentários abaixo.