Banco de Dados Operacional CDP (COD) é um banco de dados transacional autônomo desenvolvido pelo Apache HBase e Apache Phoenix. É um dos principais serviços de dados executados na nuvem pública da Cloudera Data Platform (CDP). Você pode acessar o COD diretamente do seu console CDP. Com o COD, os desenvolvedores de aplicativos agora podem aproveitar o poder do HBase e do Phoenix sem as despesas gerais que geralmente estão relacionadas à implantação e gerenciamento. O COD é fácil de provisionar e autogerenciável, o que significa que os desenvolvedores podem provisionar uma nova instância de banco de dados em minutos e começar a criar protótipos rapidamente. Recursos autônomos como dimensionamento automático, recuperação automática e ajuste automático garantem que não haja gerenciamento e administração do banco de dados para se preocupar.
Neste blog, compartilharemos como o CDP Operational Database pode fornecer alta disponibilidade para seus aplicativos quando executados em várias zonas de disponibilidade na AWS.
Para entender completamente o que é uma implantação Multi-AZ significa para sua infraestrutura, é fundamental reconhecer como o Amazon Web Services está configurado em todo o mundo e, portanto, como ele fornece os serviços de redundância, independentemente da sua localização. Conforme discutido na documentação oficial da Amazon, a Nuvem AWS é composta por várias regiões, que são locais físicos em todo o mundo. Embora as interrupções de AZ não sejam rastreadas oficialmente, os clientes da Cloudera relataram ter sofrido interrupções de AZ 1 a 2 vezes por ano. Portanto, as implantações estendidas do Multi-AZ são necessárias para atingir mais de 99,95% de disponibilidade.
Cada região compreende vários data centers físicos separados, conhecidos como zonas de disponibilidade (AZ) . Cada AZ é uma instalação independente com seus próprios recursos de energia, conectividade e rede. A maioria das regiões abriga de 2 a 3 zonas de disponibilidade diferentes cada, fornecendo redundância adequada em uma determinada região (uma AZ é representada por um código de região seguido por um identificador de letra; por exemplo, us-west-1a) .
No entanto, essa redundância é aplicada apenas à camada de armazenamento (S3) e não existe para máquinas virtuais usadas para sua instância de banco de dados. Se algo fizesse com que a Zona de Disponibilidade em que suas instâncias de servidor residem sofresse uma interrupção, seu banco de dados deixaria de funcionar, pois toda a infraestrutura de computação ficaria offline.
É aqui que entra a implantação Multi-AZ. Uma implantação Multi-AZ significa que a infraestrutura de computação para os servidores mestre e regional do HBase é distribuída em várias zonas de disponibilidade, garantindo que, quando uma única zona de disponibilidade tiver uma interrupção, apenas uma parte dos servidores regionais será afetados e os clientes mudarão automaticamente para os servidores restantes nas AZs disponíveis. Da mesma forma, o mestre de backup (supondo que o mestre primário estava na AZ com uma interrupção) assumirá automaticamente a função do mestre com falha, pois é implantado em uma AZ separada do servidor mestre primário. Tudo isso é automático, sem necessidade de configuração, gerenciamento e ações do ponto de vista do usuário/administrativo. Ele simplesmente funciona para garantir que um aplicativo não sofra uma interrupção devido à perda de uma única AZ.
Demonstração
Os bancos de dados COD recém-criados aproveitarão automaticamente todas as zonas de disponibilidade configuradas no ambiente. Portanto, é crucial configurar o ambiente com as zonas que gostaríamos de usar.
Por exemplo, temos um ambiente com as seguintes AZs:us-west-1a, us-west-1b e us-west-1c. Quando implantamos um banco de dados COD, ele é implantado automaticamente de maneira multi-AZ — não há nada a fazer! Vamos verificar os bastidores e ver o que está no console da AWS.
O COD garante que os nós do trabalhador sejam distribuídos igualmente entre as AZs configuradas. (O Masters e o Leader também são implantados em diferentes AZs para fornecer alta disponibilidade para o quorum do ZooKeeper.)
O Apache HBase já possui recursos de failover integrados, portanto, no caso de uma AZ ficar offline, o sistema já está pronto para continuar instantânea e automaticamente os serviços do seu banco de dados.
Para adicionar um pouco mais de diversão, vamos executar um simples teste de carga do HBase durante nossos testes. O HBase possui uma ferramenta de teste de carga integrada que podemos usar para um teste de gravação de longa duração:
hbase ltt -write 10:1024:10 -num_keys 10000000
Vamos simular a falha AZ agora e ver o que acontece. A maneira mais fácil de fazer isso é adicionar uma nova Network ACL que desativa o tráfego de entrada e saída de uma determinada sub-rede executando condições semelhantes a uma interrupção real da AWS.
No primeiro minuto, não vemos nada particularmente interessante na página de status, porque da perspectiva do COD o banco de dados ainda está saudável.
Mas notei que o cliente parou de progredir.
Em 10-20 segundos, o Mestre percebe que alguns dos Servidores Regionais estão inativos.
Se a interrupção afetar o mestre ativo, o HBase mudará automaticamente para o backup que assume a função após 10 a 20 segundos.
A falha não demora muito, após 2-3 minutos e alguns erros de região transitórios, o cliente consegue progredir novamente. O mestre teve que fazer a transição das regiões mortas para os servidores de região ativos.
Para simular o fim da interrupção, vamos desfazer a criação da network ACL excluindo-a. Os Servidores Regionais estão se conectando de volta ao Mestre.
Agora estamos de volta onde começamos originalmente. O COD se recuperou totalmente da interrupção. Nas solicitações de gravação, podemos ver duas quedas:a primeira é quando o cliente fez a transição para os servidores de região ativos restantes, a segunda um pouco mais tarde é quando o balanceador de carga do HBase voltou as regiões para os servidores reconectados.
COD em HDFS
O Object Storage in the Cloud é a camada de armazenamento padrão para COD e distribui os dados em 3 zonas de disponibilidade atrás e reequilibrará nos bastidores. O HBase só precisa fazer algumas tarefas domésticas (transição de região) para atender regiões pelos servidores restantes, tornando essa operação relativamente rápida.
Para casos de uso de alto desempenho, o COD oferece suporte ao uso de HDFS como armazenamento subjacente. Nesse paradigma de implantação, configuramos automaticamente o reconhecimento de rack HDFS para tolerância a falhas, colocando uma réplica de bloco em um rack diferente e mapeando os racks para zonas de disponibilidade. Isso fornece disponibilidade de dados no caso de falha de um switch de rede ou partição no cluster. Portanto, o comportamento na demonstração acima é muito semelhante ao que você veria ao implantar COD com HDFS.
Resumo
A implantação Multi-AZ é crucial para bancos de dados altamente disponíveis e agora o COD oferece suporte na AWS como visualização técnica nos bastidores, sem custo extra. Ele torna sua carga de trabalho operacional mais robusta e confiável sem nenhuma configuração adicional. Ambos estarão disponíveis para o público geral e oferecerão suporte a provedores de nuvem adicionais (Microsoft, Google) em breve.
Entre em contato com sua equipe de contas do Cloudera se estiver interessado em saber mais sobre como migrar de sua implantação do HBase para o CDP Operational Database na nuvem pública ou experimente o Cloudera Test Drive.
