A única coisa que não é óbvia é o significado da letra "P". Quando o cluster é dividido, ele decide se não responderá até que um quorum seja atingido ou se fornecerá os dados. Dependendo dos resultados desta seleção, o sistema é classificado como CP ou AP. O Cassandra, por exemplo, pode se comportar de uma forma ou de outra, dependendo nem mesmo das configurações do cluster, mas dos parâmetros de cada solicitação específica. Mas se o sistema não for "P" e estiver dividido, o que acontecerá?
A resposta a essa pergunta é um tanto surpreendente: o cluster CA não pode ser dividido.
O que é esse cluster que não pode ser dividido?
Um atributo indispensável de tal cluster é um sistema de armazenamento de dados compartilhado. Na grande maioria dos casos, isso significa conectar-se por meio de uma SAN, o que limita o uso de soluções CA a grandes empresas que podem hospedar uma infraestrutura de SAN. Para que vários servidores possam trabalhar com os mesmos dados, é necessário um sistema de arquivos em cluster. Esses sistemas de arquivos estão disponíveis nos portfólios HPE (CFS), Veritas (VxCFS) e IBM (GPFS).
Oracle RAC
A opção Real Application Cluster apareceu pela primeira vez na versão de 2001 do Oracle 9i. Nesse cluster, várias instâncias de servidor funcionam com o mesmo banco de dados.
A Oracle pode trabalhar com um sistema de arquivos em cluster e sua própria solução - ASM, Automatic Storage Management.
Cada cópia mantém seu próprio diário. A transação é executada e confirmada em uma instância. No caso de falha de uma instância, um dos nós de cluster sobreviventes (instâncias) lê seu log e recupera os dados perdidos, garantindo assim a disponibilidade.
Todas as instâncias mantêm seu próprio cache, e as mesmas páginas (blocos) podem estar simultaneamente nos caches de várias instâncias. Além disso, se uma página é necessária para uma instância e está no cache de outra instância, ela pode obtê-la do “vizinho” usando o mecanismo de fusão de cache em vez de ler do disco.
Mas o que acontece se uma das instâncias precisar alterar os dados?
A peculiaridade do Oracle é que ele não possui um serviço de bloqueio dedicado: se o servidor deseja bloquear uma linha, o registro de bloqueio é colocado diretamente na página da memória onde a linha bloqueada está localizada. Essa abordagem torna a Oracle o campeão de desempenho do banco de dados monolítico: o serviço de bloqueio nunca se torna um gargalo. Mas, em uma configuração em cluster, essa arquitetura pode levar a um tráfego intenso de rede e bloqueios.
Assim que um registro é bloqueado, a instância notifica todas as outras instâncias de que a página que armazena o registro foi adquirida em modo exclusivo. Se outra instância precisar alterar um registro na mesma página, ela deve esperar até que as alterações na página sejam confirmadas, ou seja, as informações de alteração são gravadas no log do disco (e a transação pode continuar). Também pode acontecer que a página seja alterada sequencialmente por várias cópias, e então, ao gravar a página no disco, você terá que descobrir quem tem a versão atual desta página.
A atualização acidental das mesmas páginas em nós RAC diferentes degrada drasticamente o desempenho do banco de dados - a ponto de o desempenho do cluster ser mais lento do que uma única instância.
O uso correto do Oracle RAC é particionar fisicamente os dados (por exemplo, usando o mecanismo de tabela particionada) e acessar cada conjunto de partições por meio de um nó dedicado. O objetivo principal do RAC não era o dimensionamento horizontal, mas fornecer tolerância a falhas.
Se um nó parar de responder à pulsação, o nó que o detecta inicia o procedimento de votação de disco. Se o nó ausente não foi marcado aqui, um dos nós assume a responsabilidade pela recuperação de dados:
- “Congela” todas as páginas que estavam no cache do nó ausente;
- Lê os logs (refaz) do nó faltante e reaplica as alterações registradas nesses logs, ao longo do caminho verificando se outros nós possuem versões mais recentes das páginas alteradas;
- reverte transações não confirmadas.
Para simplificar a alternância entre nós, o Oracle tem o conceito de serviço - uma instância virtual. Uma instância pode servir a vários serviços e um serviço pode se mover entre os nós. Uma instância de aplicação que atende uma determinada parte da base (por exemplo, um grupo de clientes) trabalha com um serviço, e o serviço responsável por essa parte da base, quando um nó falha, passa para outro nó.
IBM Pure Data Systems para transações
A solução de cluster para o DBMS apareceu no portfólio da Blue Giant em 2009. Ideologicamente, é o sucessor do cluster Parallel Sysplex construído em hardware "convencional". Em 2009, o DB2 pureScale foi lançado como um pacote de software e, em 2012, a IBM está oferecendo um dispositivo chamado Pure Data Systems for Transactions. Não deve ser confundido com Pure Data Systems for Analytics, que nada mais é do que o renomeado Netezza.
A arquitetura pureScale se parece com o Oracle RAC à primeira vista: da mesma forma, vários nós são conectados a um sistema de armazenamento compartilhado e cada nó executa sua própria instância de um DBMS com suas próprias áreas de memória e logs de transações. Mas, ao contrário do Oracle, o DB2 tem um serviço de bloqueio dedicado representado pelo conjunto de processos db2LLM *. Em uma configuração de cluster, este serviço é colocado em um nó separado, que é chamado de recurso de acoplamento (CF) no Parallel Sysplex e PowerHA no Pure Data.
PowerHA fornece os seguintes serviços:
- gerenciador de bloqueio;
- cache de buffer global;
- a área de comunicações entre processos.
O acesso à memória remota é usado para transferir dados do PowerHA para os nós do banco de dados e vice-versa, portanto, a interconexão do cluster deve oferecer suporte ao protocolo RDMA. PureScale pode usar Infiniband e RDMA sobre Ethernet.
Se um nó precisa de uma página e essa página não está no cache, o nó solicita uma página no cache global e, apenas se não estiver lá, ele a lê do disco. Ao contrário do Oracle, a consulta só vai para PowerHA e não para nós vizinhos.
Se a instância for alterar a string, ela a bloqueará em modo exclusivo e a página onde a string reside em modo compartilhado. Todos os bloqueios são registrados no gerenciador de bloqueio global. Quando a transação é concluída, o nó envia uma mensagem ao gerenciador de bloqueio, que copia a página modificada para o cache global, libera os bloqueios e invalida a página modificada nos caches de outros nós.
Se a página que contém a sequência modificada já estiver bloqueada, o gerenciador de bloqueio lerá a página modificada da memória do nó que fez as alterações, liberará o bloqueio, invalidará a página modificada nos caches de outros nós e dará o bloqueio de página ao nó que o solicitou.
As páginas sujas, ou seja, alteradas, podem ser gravadas no disco a partir de um nó regular e do PowerHA (castout).
Se um dos nós pureScale falhar, a recuperação é limitada apenas às transações que ainda não foram concluídas no momento da falha: as páginas modificadas por esse nó nas transações concluídas estão no cache global no PowerHA. O nó é reiniciado em uma configuração reduzida em um dos servidores de cluster, reverte as transações não confirmadas e libera bloqueios.
O PowerHA é executado em dois servidores e o nó mestre replica seu estado de maneira síncrona. Se o nó PowerHA primário falhar, o cluster continuará com o nó de backup.
Claro, se você acessar o conjunto de dados por meio de um único nó, o desempenho geral do cluster será melhor. O PureScale pode até notar que alguma área de dados está sendo processada por um nó e, em seguida, todos os bloqueios relacionados a esta área serão processados pelo nó localmente sem comunicação com o PowerHA. Mas assim que o aplicativo tentar acessar esses dados por meio de outro nó, o processamento de bloqueio centralizado será retomado.
Os benchmarks internos da IBM em 90% da carga de trabalho de leitura e 10% de gravação, muito semelhantes a uma carga de produção real, mostram um dimensionamento quase linear de até 128 nós. As condições de teste, infelizmente, não foram divulgadas.
HPE NonStop SQL
O portfólio da Hewlett-Packard Enterprise também tem sua própria plataforma altamente disponível. Esta é a plataforma NonStop lançada em 1976 pela Tandem Computers. Em 1997, a empresa foi adquirida pela Compaq, que por sua vez se fundiu com a Hewlett-Packard em 2002.
NonStop é usado para construir aplicativos críticos - por exemplo, HLR ou processamento de cartão bancário. A plataforma é entregue na forma de um complexo de software e hardware (dispositivo), que inclui nós de computação, sistema de armazenamento de dados e equipamentos de comunicação. ServerNet (em sistemas modernos - Infiniband) serve tanto para troca entre nós quanto para acesso ao sistema de armazenamento de dados.
As versões anteriores do sistema usavam processadores proprietários que eram sincronizados entre si: todas as operações eram realizadas de forma síncrona por vários processadores e, assim que um dos processadores se enganava, ele era desligado e o segundo continuava a funcionar. Mais tarde, o sistema mudou para processadores convencionais (primeiro MIPS, depois Itanium e, finalmente, x86), e outros mecanismos começaram a ser usados para sincronização:
- mensagens: cada processo do sistema possui um gêmeo “sombra”, para o qual o processo ativo envia periodicamente mensagens sobre seu estado; se o processo principal falhar, o processo sombra começa a funcionar a partir do momento determinado pela última mensagem;
- : , , ; , /.
Desde 1987, um DBMS relacional está sendo executado na plataforma NonStop - primeiro SQL / MP e, posteriormente, SQL / MX.
Todo o banco de dados é dividido em partes, e cada parte é responsável por seu próprio processo Data Access Manager (DAM). Ele fornece gravação de dados, armazenamento em cache e mecanismo de bloqueio. O processamento de dados é feito pelo Executor Server Process, rodando nos mesmos nós que os respectivos gerenciadores de dados. O agendador SQL / MX divide as tarefas entre os executores e mescla os resultados. Se você precisar fazer mudanças consistentes, use o protocolo two-phase commit fornecido pela biblioteca TMF (Transaction Management Facility).
NonStop SQL é capaz de priorizar processos para que longas consultas analíticas não interfiram na execução das transações. No entanto, seu objetivo é precisamente o processamento de transações curtas, não análises. O desenvolvedor garante a disponibilidade do cluster NonStop no nível de cinco noves, ou seja, o tempo de inatividade é de apenas 5 minutos por ano.
SAP HANA
A primeira versão estável do HANA DBMS (1.0) ocorreu em novembro de 2010 e o pacote SAP ERP mudou para o HANA em maio de 2013. A plataforma é baseada nas tecnologias adquiridas: TREX Search Engine (pesquisa em armazenamento colunar), P * TIME e MAX DB.
A própria palavra "HANA" é um acrônimo, High performance ANalytical Appliance. Este SGBD é fornecido na forma de código que pode ser executado em qualquer servidor x86, entretanto, instalações industriais são permitidas apenas em equipamentos certificados. Existem soluções da HP, Lenovo, Cisco, Dell, Fujitsu, Hitachi, NEC. Algumas configurações da Lenovo até permitem a operação sem uma SAN - um cluster GPFS em discos locais desempenha a função de armazenamento compartilhado.
Ao contrário das plataformas listadas acima, o HANA é um DBMS in-memory, ou seja, a imagem primária dos dados é armazenada na RAM e apenas logs e instantâneos periódicos são gravados em disco para recuperação em caso de desastre.
Cada nó do cluster HANA é responsável por sua própria parte dos dados, e o mapa de dados é armazenado em um componente especial - Servidor de Nomes, localizado no nó coordenador. Os dados entre os nós não são duplicados. As informações de bloqueio também são armazenadas em cada nó, mas o sistema possui um detector de deadlock global.
Um cliente HANA, ao se conectar a um cluster, carrega sua topologia e no futuro pode acessar diretamente qualquer nó, dependendo dos dados de que necessita. Se uma transação afetar os dados de um único nó, então ela pode ser realizada por este nó localmente, mas se os dados de vários nós mudarem, então o nó iniciador contata o nó coordenador, que abre e coordena a transação distribuída, comprometendo-a usando um protocolo de confirmação de duas fases otimizado.
O nó coordenador é duplicado, portanto, se o coordenador falhar, o nó de backup assume imediatamente. Mas se um nó com dados falhar, a única maneira de obter acesso a seus dados é reiniciando o nó. Como regra, em clusters HANA, um servidor sobressalente é mantido para reiniciar o nó perdido nele o mais rápido possível.