MariaDB
 sql >> Base de Dados >  >> RDS >> MariaDB

Comparando a solução Oracle RAC HA com o Galera Cluster for MySQL ou MariaDB


As empresas desejam continuamente obter insights das informações para tomar decisões confiáveis, mais inteligentes, em tempo real e baseadas em fatos. Como as empresas dependem mais de dados e bancos de dados, informações e processamento de dados são o núcleo de muitas operações e decisões de negócios. A fé no banco de dados é total. Nenhum dos serviços diários da empresa pode ser executado sem as plataformas de banco de dados subjacentes. Como consequência, a necessidade de escalabilidade e desempenho do software do sistema de banco de dados é mais crítica do que nunca. Os principais benefícios do sistema de banco de dados em cluster são escalabilidade e alta disponibilidade. Neste blog, tentaremos comparar o Oracle RAC e o Galera Cluster à luz desses dois aspectos. O Real Application Clusters (RAC) é a solução premium da Oracle para clustering de bancos de dados Oracle e oferece alta disponibilidade e escalabilidade. Galera Cluster é a tecnologia de cluster mais popular para MySQL e MariaDB.

Visão geral da arquitetura


O Oracle RAC usa o software Oracle Clusterware para vincular vários servidores. O Oracle Clusterware é uma solução de gerenciamento de cluster integrado ao Oracle Database, mas também pode ser usado com outros serviços, não apenas o banco de dados. O Oracle Clusterware é um software adicional instalado em servidores que executam o mesmo sistema operacional, que permite que os servidores sejam encadeados para operar como se fossem um único servidor.

O Oracle Clusterware observa a instância e a reinicia automaticamente se ocorrer uma falha. Se o seu aplicativo for bem projetado, você pode não enfrentar nenhuma interrupção do serviço. Apenas um grupo de sessões (aquelas conectadas à instância com falha) é afetada pela falha. O blecaute pode ser mascarado com eficiência para o usuário final usando recursos avançados de RAC, como Notificação Rápida de Aplicativo e Failover de Conexão Rápida do cliente Oracle. O Oracle Clusterware controla a associação do nó e evita sintomas de cérebro dividido em que duas ou mais instâncias tentam controlar a instância.

Galera Cluster é uma tecnologia de cluster de banco de dados ativo-ativo síncrono para MySQL e MariaDB. O Galera Cluster difere do que é conhecido como Oracle’s MySQL Cluster - NDB. O cluster MariaDB é baseado no plug-in de replicação multimestre fornecido pela Codership. Desde a versão 5.5, o plugin Galera (API wsrep) é parte integrante do MariaDB. O Percona XtraDB Cluster (PXC) também é baseado no plugin Galera. A arquitetura do plugin Galera se baseia em três camadas principais:certificação, replicação e estrutura de comunicação em grupo. A camada de certificação prepara os conjuntos de gravação e faz as verificações de certificação sobre eles, garantindo que eles possam ser aplicados. A camada de replicação gerencia o protocolo de replicação e fornece a capacidade total de pedidos. O Group Communication Framework implementa uma arquitetura de plug-in que permite que outros sistemas se conectem via esquema de back-end gcomm.

Para manter o estado idêntico no cluster, a API wsrep usa um ID de transação global. O identificador exclusivo do GTID é criado e associado a cada transação confirmada no nó do banco de dados. No Oracle RAC, várias instâncias de banco de dados compartilham o acesso a recursos como blocos de dados no cache de buffer para enfileirar blocos de dados. O acesso aos recursos compartilhados entre instâncias RAC precisa ser coordenado para evitar conflitos. Para organizar o acesso compartilhado a esses recursos, o cache distribuído mantém informações como ID do bloco de dados, qual instância RAC contém a versão atual desse bloco de dados e o modo de bloqueio em que cada instância contém o bloco de dados.

Conceitos-chave de armazenamento de dados


O Oracle RAC conta com uma arquitetura de disco distribuído. Os arquivos de banco de dados, arquivos de controle e logs de redo online para o banco de dados precisam estar acessíveis a cada nó no cluster. Há uma variedade de maneiras de configurar o armazenamento compartilhado, incluindo discos conectados diretamente, redes de área de armazenamento (SAN) e armazenamento anexado à rede (NAS) e Oracle ASM. Dois mais populares são OCFS e ASM. O Oracle Cluster File System (OCFS) é um sistema de arquivos compartilhado projetado especificamente para Oracle RAC. O OCFS elimina a exigência de que os arquivos de banco de dados Oracle sejam conectados a unidades lógicas e permite que todos os nós compartilhem um único dispositivo Oracle Home ASM, RAW. O Oracle ASM é a solução de gerenciamento de armazenamento recomendada da Oracle que oferece uma alternativa aos gerenciadores de volume convencionais, sistemas de arquivos e dispositivos brutos. O Oracle ASM fornece uma camada de virtualização entre o banco de dados e o armazenamento. Ele trata vários discos como um único grupo de discos e permite adicionar ou remover unidades dinamicamente enquanto mantém os bancos de dados online.

Não há necessidade de criar armazenamento em disco compartilhado sofisticado para o Galera, pois cada nó tem sua cópia completa dos dados. No entanto, é uma boa prática tornar o armazenamento confiável com caches de gravação com bateria.
Oracle RAC, armazenamento em cluster Replicação do Galera, discos anexados aos nós do banco de dados

Comunicação e cache de nós do cluster


O Oracle Real Application Clusters possui uma arquitetura de cache compartilhada, utiliza o Oracle Grid Infrastructure para permitir o compartilhamento de recursos de servidor e armazenamento. A comunicação entre os nós é o aspecto crítico da integridade do cluster. Cada nó deve ter pelo menos dois adaptadores de rede ou placas de interface de rede:uma para a interface de rede pública e outra para a interconexão. Cada nó do cluster é conectado a todos os outros nós por meio de uma rede privada de alta velocidade, também reconhecida como a interconexão do cluster.
Oracle RAC, arquitetura de rede
A rede privada é normalmente formada com Gigabit Ethernet, mas para ambientes de alto volume, muitos fornecedores oferecem soluções de baixa latência e alta largura de banda projetadas para Oracle RAC. O Linux também estende um meio de vincular vários NICs físicos em um único NIC virtual para fornecer maior largura de banda e disponibilidade.

Embora a abordagem padrão para conectar os nós do Galera seja usar uma única NIC por host, você pode ter mais de uma placa. O ClusterControl pode ajudá-lo com essa configuração. A principal diferença é o requisito de largura de banda na interconexão. O Oracle RAC envia blocos de dados entre instâncias, portanto, ele coloca uma carga mais pesada na interconexão em comparação com os conjuntos de gravação Galera (que consistem em uma lista de operações).

Com o uso de interconexão redundante no RAC, você pode identificar várias interfaces para usar na rede de cluster privada, sem a necessidade de usar ligação ou outras tecnologias. Essa funcionalidade está disponível a partir do Oracle Database 11gR2. Se você usar o recurso de interconexão excessiva do Oracle Clusterware, deverá usar endereços IPv4 para as interfaces (UDP é um padrão).

Para gerenciar a alta disponibilidade, cada nó do cluster recebe um endereço IP virtual (VIP). No caso de falha do nó, o endereço IP do nó com falha pode ser reatribuído a um nó sobrevivente para permitir que os aplicativos continuem a acessar o banco de dados por meio do mesmo endereço IP.

A configuração de rede sofisticada é necessária para a tecnologia Cache Fusion da Oracle para acoplar a memória física em cada host em um único cache. O Oracle Cache Fusion fornece dados armazenados no cache de uma instância Oracle para serem acessados ​​por qualquer outra instância, transportando-os pela rede privada. Ele também protege a integridade dos dados e a coerência do cache transmitindo informações de bloqueio e sincronização suplementar além dos nós do cluster.

Além da configuração de rede descrita, você pode definir um único endereço de banco de dados para seu aplicativo - Single Client Access Name (SCAN). O objetivo principal do SCAN é fornecer facilidade de gerenciamento de conexão. Por exemplo, você pode adicionar novos nós ao cluster sem alterar sua string de conexão do cliente. Essa funcionalidade ocorre porque a Oracle distribuirá automaticamente as solicitações de acordo com os IPs SCAN que apontam para os VIPs subjacentes. Os ouvintes de varredura fazem a ponte entre os clientes e os ouvintes locais subjacentes que são dependentes de VIP.

Para Galera Cluster, o equivalente a SCAN seria adicionar um proxy de banco de dados na frente dos nós Galera. O proxy seria um único ponto de contato para aplicativos, ele pode colocar na lista negra nós com falha e encaminhar consultas para nós íntegros. O próprio proxy pode se tornar redundante com Keepalived e Virtual IP.

Failover e recuperação de dados


A principal diferença entre o Oracle RAC e o MySQL Galera Cluster é que o Galera não tem arquitetura compartilhada. Em vez de discos compartilhados, Galera usa replicação baseada em certificação com comunicação de grupo e ordenação de transações para obter replicação síncrona. Um cluster de banco de dados deve ser capaz de sobreviver à perda de um nó, embora isso seja feito de maneiras diferentes. No caso do Galera, o aspecto crítico é o número de nós, o Galera requer um quorum para se manter operacional. Um cluster de três nós pode sobreviver à falha de um nó. Com mais nós em seu cluster, sua disponibilidade aumentará. O Oracle RAC não exige um quorum para permanecer operacional após uma falha de nó. É por causa do acesso ao armazenamento distribuído que mantém informações consistentes sobre o estado do cluster. No entanto, seu armazenamento de dados pode ser um ponto potencial de falha em seu plano de alta disponibilidade. Embora seja uma tarefa razoavelmente simples ter nós de cluster Galera espalhados pelos data centers de geolocalização, não seria tão fácil com o RAC. O Oracle RAC requer espelhamento de disco avançado adicional, no entanto, RAID básico, como redundância, pode ser obtido dentro de um grupo de discos ASM.
Tipo de grupo de disco Níveis de espelhamento compatíveis Nível de espelhamento padrão
Redundância externa Desprotegido (nenhum) Desprotegido
Redundância normal Duas vias, três vias, desprotegido (nenhum) Duas vias
Alta redundância Três vias Três vias
Redundância flexível Duas vias, três vias, desprotegido (nenhum) Duas vias (recém-criado)
Redundância estendida Duas vias, três vias, desprotegido (nenhum) Duas vias
Redundância do grupo de discos ASM

Esquemas de bloqueio


Em um banco de dados de usuário único, um usuário pode alterar dados sem se preocupar com outras sessões modificando os mesmos dados ao mesmo tempo. No entanto, em um ambiente de vários nós de banco de dados multiusuário, isso se torna mais complicado. Um banco de dados multiusuário deve fornecer o seguinte:
  • simultaneidade de dados - a garantia de que os usuários podem acessar os dados ao mesmo tempo,
  • consistência de dados - a garantia de que cada usuário tenha uma visão consistente dos dados.

As instâncias de cluster exigem três tipos principais de bloqueio de simultaneidade:
  • Leituras de simultaneidade de dados em diferentes instâncias,
  • A simultaneidade de dados lê e grava em diferentes instâncias,
  • Gravações de simultaneidade de dados em diferentes instâncias.

O Oracle permite que você escolha a política de bloqueio, seja pessimista ou otimista, dependendo de seus requisitos. Para obter o bloqueio de simultaneidade, o RAC possui dois buffers adicionais. Eles são o Global Cache Service (GCS) e o Global Enqueue Service (GES). Esses dois serviços abrangem o processo do Cache Fusion, transferências de recursos e escalações de recursos entre as instâncias. GES incluem bloqueios de cache, bloqueios de dicionário, bloqueios de transação e bloqueios de tabela. O GCS mantém os modos de bloco e as transferências de bloco entre as instâncias.

No cluster Galera, cada nó tem seu armazenamento e buffers. Quando uma transação é iniciada, os recursos de banco de dados locais para esse nó estão envolvidos. Na confirmação, as operações que fazem parte dessa transação são transmitidas como parte de um conjunto de gravação para o restante do grupo. Como todos os nós têm o mesmo estado, o conjunto de gravação será bem-sucedido em todos os nós ou falhará em todos os nós.

O Galera Cluster usa o controle de simultaneidade otimista em nível de cluster, que pode aparecer em transações que resultam em uma interrupção do COMMIT. O primeiro commit vence. Quando as anulações ocorrem no nível do cluster, o Galera Cluster apresenta um erro de deadlock. Isso pode ou não afetar a arquitetura do seu aplicativo. O alto número de linhas para replicar em uma única transação afetaria as respostas dos nós, embora existam técnicas para evitar esse comportamento.

Requisitos de hardware e software


A configuração do hardware de ambos os clusters não requer recursos potentes. A configuração mínima do cluster Oracle RAC seria satisfeita por dois servidores com duas CPUs, memória física de pelo menos 1,5 GB de RAM, uma quantidade de espaço de troca igual à quantidade de RAM e duas NICs Gigabit Ethernet. A configuração mínima do nó do Galera é de três nós (um dos nós pode ser um árbitro, gardb), cada um com CPU de núcleo único de 1 GHz, 512 MB de RAM, placa de rede de 100 Mbps. Embora estes sejam os mínimos, podemos dizer com segurança que em ambos os casos você provavelmente gostaria de ter mais recursos para seu sistema de produção.

Cada nó armazena software para que você precise preparar vários gigabytes de seu armazenamento. Oracle e Galera têm a capacidade de corrigir individualmente os nós, eliminando-os um de cada vez. Esse patch contínuo evita uma interrupção completa do aplicativo, pois sempre há nós de banco de dados disponíveis para lidar com o tráfego.

O que é importante mencionar é que um cluster Galera de produção pode ser executado facilmente em VMs ou bare metal básico, enquanto o RAC precisaria de investimento em armazenamento compartilhado sofisticado e comunicação de fibra.

Monitoramento e Gerenciamento


O Oracle Enterprise Manager é a abordagem preferida para monitorar o Oracle RAC e o Oracle Clusterware. O Oracle Enterprise Manager é um sistema de gerenciamento unificado baseado na Web da Oracle para monitorar e administrar seu ambiente de banco de dados. Faz parte do Oracle Enterprise License e deve ser instalado em um servidor separado. O monitoramento e o gerenciamento do controle de cluster são feitos por meio da combinação dos comandos crsctl e srvctl que fazem parte dos binários do cluster. Abaixo você pode encontrar alguns comandos de exemplo.

Verificação do status do recurso de clusterware:
    crsctl status resource -t (or shorter: crsctl stat res -t)

Exemplo:
$ crsctl stat res ora.test1.vip
NAME=ora.test1.vip
TYPE=ora.cluster_vip_net1.type
TARGET=ONLINE
STATE=ONLINE on test1

Verifique o status da pilha do Oracle Clusterware:
    crsctl check cluster

Exemplo:
$ crsctl check cluster -all
*****************************************************************
node1:
CRS-4537: Cluster Ready Services is online
CRS-4529: Cluster Synchronization Services is online
CRS-4533: Event Manager is online
*****************************************************************
node2:
CRS-4537: Cluster Ready Services is online
CRS-4529: Cluster Synchronization Services is online
CRS-4533: Event Manager is online

Verifique o status do Oracle High Availability Services e a pilha do Oracle Clusterware no servidor local:
    crsctl check crs

Exemplo:
$ crsctl check crs
CRS-4638: Oracle High Availablity Services is online
CRS-4537: Cluster Ready Services is online
CRS-4529: Cluster Synchronization Services is online
CRS-4533: Event Manager is online

Pare o Oracle High Availability Services no servidor local. 
    crsctl stop has

Pare o Oracle High Availability Services no servidor local. 
    crsctl start has

Exibe o status dos aplicativos do nó:
    srvctl status nodeapps

Exibe as informações de configuração para todos os VIPs SCAN 
    srvctl config scan

Exemplo:
srvctl config scan -scannumber 1
SCAN name: testscan, Network: 1
Subnet IPv4: 192.51.100.1/203.0.113.46/eth0, static
Subnet IPv6: 
SCAN 1 IPv4 VIP: 192.51.100.195
SCAN VIP is enabled.
SCAN VIP is individually enabled on nodes:
SCAN VIP is individually disabled on nodes:

O Cluster Verification Utility (CVU) executa verificações do sistema em preparação para instalação, atualizações de patches ou outras alterações do sistema:
    cluvfy comp ocr

Exemplo:
Verifying OCR integrity
Checking OCR integrity...
Checking the absence of a non-clustered configurationl...
All nodes free of non-clustered, local-only configurations
ASM Running check passed. ASM is running on all specified nodes
Checking OCR config file “/etc/oracle/ocr.loc"...
OCR config file “/etc/oracle/ocr.loc" check successful
Disk group for ocr location “+DATA" available on all the nodes
NOTE:
This check does not verify the integrity of the OCR contents. Execute ‘ocrcheck' as a privileged user to verify the contents of OCR.
OCR integrity check passed
Verification of OCR integrity was successful.

Os nós Galera e o cluster requerem que a API wsrep relate vários status, que são expostos. Existem atualmente 34 variáveis ​​de status dedicadas que podem ser visualizadas com a instrução SHOW STATUS. 
mysql> SHOW STATUS LIKE 'wsrep_%';
wsrep_apply_oooe
wsrep_apply_oool
wsrep_cert_deps_distance
wsrep_cluster_conf_id
wsrep_cluster_size
wsrep_cluster_state_uuid
wsrep_cluster_status
wsrep_connected
wsrep_flow_control_paused
wsrep_flow_control_paused_ns
wsrep_flow_control_recv		 wsrep_local_send_queue_avg
wsrep_local_state_uuid
wsrep_protocol_version
wsrep_provider_name
wsrep_provider_vendor
wsrep_provider_version
wsrep_flow_control_sent
wsrep_gcomm_uuid_sent
br /> wsrep_last_committed
wsrep_local_bf_aborts
wsrep_local_cert_failures		 wsrep_local_commits
wsrep_local_index
wsrep_local_recv_queue
wsrep_local_recv_queue_avg
wsrep_local_replays
wsrep_local_send_queue
wsrep_ready
wsrep_received
wsrep_received_bytes
wsrep_replicated
wsrep_replicated_bytes
wsrep_thread_count

A administração do MySQL Galera Cluster em muitos aspectos é muito semelhante. Existem apenas algumas exceções, como inicializar o cluster do nó inicial ou recuperar nós por meio de operações SST ou IST.

Cluster de inicialização:
$ service mysql bootstrap # sysvinit
$ service mysql start --wsrep-new-cluster # sysvinit
$ galera_new_cluster # systemd
$ mysqld_safe --wsrep-new-cluster # command line

A solução equivalente baseada na Web e pronta para uso para gerenciar e monitorar o Galera Cluster é o ClusterControl. Ele fornece uma interface baseada na Web para implantar clusters, monitora as principais métricas, fornece consultores de banco de dados e cuida de tarefas de gerenciamento como backup e restauração, correção automática, criptografia de tráfego e gerenciamento de disponibilidade.

Restrições na carga de trabalho


A Oracle fornece tecnologia SCAN que não encontramos no Galera Cluster. O benefício do SCAN é que as informações de conexão do cliente não precisam ser alteradas se você adicionar ou remover nós ou bancos de dados no cluster. Ao usar o SCAN, o banco de dados Oracle se conecta aleatoriamente a um dos ouvintes SCAN disponíveis (normalmente três) de forma round robin e equilibra as conexões entre eles. Dois tipos de balanceamento de carga podem ser configurados:lado do cliente, balanceamento de carga de tempo de conexão e no lado do servidor, balanceamento de carga de tempo de execução. Embora não haja nada semelhante no próprio cluster Galera, a mesma funcionalidade pode ser abordada com software adicional como ProxySQL, HAProxy, Maxscale combinado com Keepalived.

Quando se trata de design de carga de trabalho de aplicativo para o Galera Cluster, você deve evitar atualizações conflitantes na mesma linha, pois isso leva a deadlocks em todo o cluster. Evite inserções ou atualizações em massa, pois elas podem ser maiores que o conjunto de gravação máximo permitido. Isso também pode causar paralisações do cluster.

Ao projetar o Oracle HA com RAC, você precisa ter em mente que o RAC protege apenas contra falhas do servidor, e você precisa espelhar o armazenamento e ter redundância de rede. Os aplicativos da Web modernos exigem acesso a serviços de dados independentes de localização e, devido às limitações da arquitetura de armazenamento do RAC, pode ser difícil de conseguir. Você também precisa gastar uma quantidade considerável de tempo para obter conhecimento relevante para gerenciar o ambiente; é um processo longo. No lado da carga de trabalho do aplicativo, existem algumas desvantagens. A distribuição de operações de leitura ou gravação separadas no mesmo conjunto de dados não é ideal porque a latência é adicionada pela troca de dados entre nós suplementares. Coisas como particionamento, cache de sequência e operações de classificação devem ser revisadas antes da migração para o RAC.

Redundância de vários data centers


De acordo com a documentação da Oracle, a distância máxima entre duas caixas conectadas ponto a ponto e rodando de forma síncrona pode ser de apenas 10 km. Usando dispositivos especializados, essa distância pode ser aumentada para 100 km.

O Galera Cluster é bem conhecido por seus recursos de replicação de vários datacenters. Ele tem suporte avançado para configurações de rede Wider Area Networks. Ele pode ser configurado para alta latência de rede fazendo medições de Round-Trip Time (RTT) entre nós de cluster e ajustando os parâmetros necessários. Os parâmetros wsrep_provider_options permitem que você defina configurações como suspeito_timeout, interativo_timeout, join_retrans_timouts e muito mais.

Usando Galera e RAC na nuvem


De acordo com a nota da Oracle www.oracle.com/technetwork/database/options/.../rac-cloud-support-2843861.pdf nenhuma nuvem de terceiros atualmente atende aos requisitos da Oracle em relação ao armazenamento compartilhado fornecido nativamente. “Nativo” neste contexto significa que o provedor de nuvem deve oferecer suporte ao armazenamento compartilhado como parte de sua infraestrutura de acordo com a política de suporte da Oracle.

Graças à sua arquitetura nada compartilhada, que não está vinculada a uma solução de armazenamento sofisticada, o cluster Galera pode ser facilmente implantado em um ambiente de nuvem. Coisas como:
  • protocolo de rede otimizado,
  • replicação com reconhecimento de topologia,
  • criptografia de tráfego,
  • detecção e remoção automática de nós não confiáveis,

torna o processo de migração para a nuvem mais confiável.

Licenças e custos ocultos


O licenciamento da Oracle é um tópico complexo e exigiria um artigo de blog separado. O fator cluster torna ainda mais difícil. O custo aumenta, pois temos que adicionar algumas opções para licenciar uma solução RAC completa. Aqui queremos apenas destacar o que esperar e onde encontrar mais informações.

O RAC é um recurso da licença do Oracle Enterprise Edition. A licença do Oracle Enterprise é dividida em dois tipos, por usuário nomeado e por processador. Se você considerar a Enterprise Edition com licença por núcleo, o custo de núcleo único será RAC 23.000 USD + Oracle DB EE 47.500 USD, e você ainda precisará adicionar uma taxa de suporte de ~ 22%. Gostaríamos de consultar um ótimo blog sobre preços encontrado em https://flashdba.com/2013/09/18/the-real-cost-of-oracle-rac/.

Flashdba calculou o preço de um Oracle RAC de quatro nós. O valor total foi de 902.400 USD mais 595.584 USD adicionais para três anos de manutenção de banco de dados, e isso não inclui recursos como particionamento ou banco de dados na memória, tudo isso com 60% de desconto Oracle.

Galera Cluster é uma solução de código aberto que qualquer pessoa pode executar gratuitamente. Assinaturas estão disponíveis para implementações de produção que exigem suporte do fornecedor. Um bom cálculo de TCO pode ser encontrado em https://severalnines.com/blog/database-tco-calculating-total-cost-ownership-mysql-management.

Conclusão


Embora existam diferenças significativas na arquitetura, ambos os clusters compartilham os princípios principais e podem atingir objetivos semelhantes. O produto empresarial da Oracle vem com tudo pronto para uso (e seu preço). Com um custo na faixa de> 1 milhão de dólares, como visto acima, é uma solução de ponta que muitas empresas não conseguiriam pagar. O Galera Cluster pode ser descrito como uma solução decente de alta disponibilidade para as massas. Em certos casos, o Galera pode ser uma boa alternativa ao Oracle RAC. Uma desvantagem é que você precisa construir sua própria pilha, embora isso possa ser completamente automatizado com o ClusterControl. Adoraríamos ouvir seus pensamentos sobre isso.