O teorema CAP é a pedra angular da teoria dos sistemas distribuídos. É claro que a polêmica em torno dele não diminui: as definições nele contidas não são canônicas e não há prova estrita... No entanto, permanecendo firmes nas posições do senso comum cotidiano™, entendemos intuitivamente que o teorema é verdadeiro.
A única coisa que não é óbvia é o significado da letra “P”. Quando o cluster é dividido, ele decide se não responde até que o quorum seja atingido ou devolve os dados que estão disponíveis. Dependendo dos resultados desta escolha, o sistema é classificado como CP ou AP. Cassandra, por exemplo, pode se comportar de qualquer maneira, 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 se dividir, o que acontecerá?
A resposta a esta pergunta é um tanto inesperada: um cluster de CA não pode ser dividido.
Que tipo de cluster é esse 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 através de uma SAN, o que limita o uso de soluções CA a grandes empresas capazes de manter uma infra-estrutura SAN. Para que vários servidores funcionem 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 em 2001 com o lançamento do Oracle 9i. Nesse cluster, várias instâncias de servidor trabalham com o mesmo banco de dados.
A Oracle pode trabalhar tanto com um sistema de arquivos em cluster quanto com 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 por uma instância. Se uma instância falhar, um dos nós do cluster sobreviventes (instâncias) lê seu log e restaura 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 nos caches de várias instâncias ao mesmo tempo. Além disso, se uma instância precisar de uma página e ela estiver no cache de outra instância, ela poderá obtê-la de seu vizinho usando o mecanismo de fusão de cache em vez de lê-la no 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 quiser bloquear uma linha, o registro de bloqueio é colocado diretamente na página de memória onde a linha bloqueada está localizada. Graças a esta abordagem, a Oracle é a campeã de desempenho entre os bancos de dados monolíticos: o serviço de bloqueio nunca se torna um gargalo. Mas em uma configuração de cluster, tal arquitetura pode levar a intenso tráfego de rede e bloqueios.
Depois que um registro é bloqueado, uma instância notifica todas as outras instâncias de que a página que armazena esse registro tem uma retenção exclusiva. Se outra instância precisar alterar um registro na mesma página, ela deverá aguardar até que as alterações na página sejam confirmadas, ou seja, as informações da alteração sejam gravadas em um diário no disco (e a transação possa continuar). Também pode acontecer que uma página seja alterada sequencialmente em várias cópias e, ao gravar a página no disco, você terá que descobrir quem armazena a versão atual desta página.
Atualizar aleatoriamente as mesmas páginas em diferentes nós RAC faz com que o desempenho do banco de dados caia drasticamente, a ponto de o desempenho do cluster poder ser inferior ao de uma única instância.
O uso correto do Oracle RAC é particionar fisicamente os dados (por exemplo, usando um mecanismo de tabela particionada) e acessar cada conjunto de partições por meio de um nó dedicado. O principal objetivo do RAC não era o escalonamento horizontal, mas sim garantir a tolerância a falhas.
Se um nó parar de responder a uma pulsação, então o nó que o detectou primeiro inicia um procedimento de votação no disco. Se o nó ausente não for anotado aqui, um dos nós assume a responsabilidade pela recuperação dos dados:
- “congela” todas as páginas que estavam no cache do nó ausente;
- lê os logs (redo) do nó faltante e reaplica as alterações registradas nesses logs, verificando simultaneamente se outros nós possuem versões mais recentes das páginas que estão sendo alteradas;
- reverte transações pendentes.
Para simplificar a alternância entre nós, a Oracle possui o conceito de serviço - uma instância virtual. Uma instância pode servir vários serviços e um serviço pode mover-se entre nós. Uma instância de aplicativo que atende uma determinada parte do banco de dados (por exemplo, um grupo de clientes) funciona com um serviço, e o serviço responsável por essa parte do banco de dados é transferido para outro nó quando um nó falha.
IBM Pure Data Systems para transações
Uma solução de cluster para SGBD apareceu no portfólio da Blue Giant em 2009. Ideologicamente, é o sucessor do cluster Parallel Sysplex, construído em equipamentos “regulares”. Em 2009, o DB2 pureScale foi lançado como um conjunto de software e, em 2012, a IBM ofereceu um dispositivo chamado Pure Data Systems for Transactions. Não deve ser confundido com Pure Data Systems for Analytics, que nada mais é do que um Netezza renomeado.
À primeira vista, a arquitetura pureScale é semelhante ao Oracle RAC: da mesma forma, vários nós estão conectados a um sistema comum de armazenamento de dados, e cada nó executa sua própria instância de DBMS com suas próprias áreas de memória e logs de transações. Mas, diferentemente do Oracle, o DB2 possui um serviço de bloqueio dedicado representado por um conjunto de processos db2LLM*. Em uma configuração de cluster, esse 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;
- área de comunicações entre processos.
Para transferir dados do PowerHA para os nós da base de dados e vice-versa, é utilizado o acesso remoto à memória, pelo que a interligação do cluster deve suportar o protocolo RDMA. PureScale pode usar Infiniband e RDMA sobre Ethernet.
Se um nó precisar de uma página e esta página não estiver no cache, então o nó solicita a página no cache global e, somente se ela não estiver lá, a lê do disco. Ao contrário do Oracle, a solicitação vai apenas para o PowerHA e não para nós vizinhos.
Se uma instância vai alterar uma linha, ela a bloqueia em modo exclusivo e a página onde a linha está localizada em modo compartilhado. Todos os bloqueios são registrados no gerenciador de bloqueios global. Quando a transação é concluída, o nó envia uma mensagem ao gerenciador de bloqueios, 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 na qual a linha modificada está localizada já estiver bloqueada, o gerenciador de bloqueio lerá a página modificada da memória do nó que fez a alteração, liberará o bloqueio, invalidará a página modificada nos caches de outros nós e forneça o bloqueio da página ao nó que o solicitou.
Páginas “sujas”, ou seja, alteradas, podem ser gravadas no disco tanto de um nó normal quanto de PowerHA (castout).
Se um dos nós do pureScale falhar, a recuperação será 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ó reinicia em uma configuração reduzida em um dos servidores do cluster, reverte transações pendentes e libera bloqueios.
O PowerHA é executado em dois servidores e o nó principal replica o seu estado de forma síncrona. Se o nó PowerHA primário falhar, o cluster continuará a operar com o nó de backup.
Obviamente, se você acessar o conjunto de dados por meio de um único nó, o desempenho geral do cluster será maior. O PureScale pode até perceber que uma determinada área de dados está sendo processada por um nó e, então, todos os bloqueios relacionados a essa área serão processados localmente pelo nó sem comunicação com o PowerHA. Mas assim que o aplicativo tentar acessar esses dados por meio de outro nó, o processamento centralizado do bloqueio será retomado.
Os testes internos da IBM em uma carga de trabalho de 90% de leitura e 10% de gravação, que é muito semelhante às cargas de trabalho de produção do mundo real, mostram um escalonamento quase linear até 128 nós. As condições do teste, infelizmente, não são divulgadas.
SQL ininterrupto HPE
O portfólio da Hewlett-Packard Enterprise também possui sua própria plataforma altamente disponível. Trata-se da plataforma NonStop, lançada ao mercado 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 (appliance), que inclui nós de computação, sistema de armazenamento de dados e equipamentos de comunicação. A rede ServerNet (em sistemas modernos - Infiniband) serve tanto para troca entre nós quanto para acesso ao sistema de armazenamento de dados.
As primeiras versões do sistema usavam processadores proprietários sincronizados entre si: todas as operações eram realizadas de forma síncrona por vários processadores e, assim que um dos processadores cometia um erro, ele era desligado e o segundo continuava funcionando. Posteriormente, o sistema mudou para processadores convencionais (primeiro MIPS, depois Itanium e finalmente x86), e outros mecanismos passaram a ser utilizados para sincronização:
- mensagens: cada processo do sistema possui um gêmeo “sombra”, para o qual o processo ativo envia periodicamente mensagens sobre seu status; se o processo principal falhar, o processo sombra começa a funcionar a partir do momento determinado pela última mensagem;
- votação: o sistema de armazenamento possui um componente de hardware especial que aceita múltiplos acessos idênticos e os executa somente se os acessos corresponderem; Em vez de sincronização física, os processadores operam de forma assíncrona e os resultados de seu trabalho são comparados apenas nos momentos de E/S.
Desde 1987, um SGBD relacional tem sido 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 mecanismos de gravação de dados, armazenamento em cache e bloqueio. O processamento dos dados é realizado pelos Processos do Executor Server rodando nos mesmos nós dos gerenciadores de dados correspondentes. O agendador SQL/MX divide tarefas entre executores e agrega os resultados. Quando é necessário fazer alterações acordadas, é utilizado o protocolo de commit de duas fases fornecido pela biblioteca TMF (Transaction Management Facility).
O NonStop SQL pode priorizar processos para que consultas analíticas longas não interfiram na execução da transação. Porém, sua finalidade é justamente o processamento de transações curtas, e não analíticas. O desenvolvedor garante a disponibilidade do cluster NonStop no nível de cinco “nove”, 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 HANA em maio de 2013. A plataforma é baseada em tecnologias adquiridas: TREX Search Engine (pesquisa em armazenamento colunar), P*TIME DBMS 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 rodar em qualquer servidor x86, porém instalações industriais são permitidas apenas em equipamentos certificados. Soluções disponíveis na HP, Lenovo, Cisco, Dell, Fujitsu, Hitachi, NEC. Algumas configurações da Lenovo permitem até mesmo operação sem SAN - o papel de um sistema de armazenamento comum é desempenhado por um cluster GPFS em discos locais.
Ao contrário das plataformas listadas acima, o HANA é um SGBD na memória, ou seja, a imagem de dados primária é armazenada na RAM e apenas logs e instantâneos periódicos são gravados no 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 – Name Server, localizado no nó coordenador. Os dados não são duplicados entre nós. As informações de bloqueio também são armazenadas em cada nó, mas o sistema possui um detector de deadlock global.
Quando um cliente HANA se conecta a um cluster, ele baixa sua topologia e pode acessar qualquer nó diretamente, dependendo dos dados necessários. Se uma transação afeta os dados de um único nó, então ela pode ser executada localmente por esse nó, mas se os dados de vários nós mudarem, o nó inicial entra em contato com o nó coordenador, que abre e coordena a transação distribuída, confirmando-a usando um protocolo de commit de duas fases otimizado.
O nó coordenador é duplicado, portanto, se o coordenador falhar, o nó de backup assume imediatamente o controle. Mas se um nó com dados falhar, a única maneira de acessar seus dados é reiniciar o nó. Como regra, os clusters HANA mantêm um servidor sobressalente para reiniciar um nó perdido nele o mais rápido possível.
Fonte: habr.com