Virtualização e serviço de arquivos em cluster de alta disponibilidade com Debian Etch, com redundância, espelhamento, replicação, em ambientes de desenvolvimento (parte 3)

Virtualização e serviço de arquivos POSIX em cluster de alta disponibilidade redundante com espelhamento síncrono e replicação assíncrona em ambientes de desenvolvimento, com montagem local, suporte a ACL, quotas, direct I/O (dio), asynchronous I/O (aio), homologado para banco de dados Oracle RAC e compatível com PostgreSQL. Nesta terceira parte do trabalho, abordaremos o sistema de arquivos em cluster de alta disponibilidade. Também apresentaremos resultados de desempenho, soluções alternativas e outras implementações e conceitos que NÃO funcionaram e os motivos. Apresenta as conclusões e lições aprendidas com o que funcionou e o que não funcionou. Igualmente valiosas.

2. Serviço de arquivos distribuído POSIX, com dio, aio e montagem local, em cluster de alta disponibilidade, redundância, espelhamento, replicação em ambiente de desenvolvimento.

2.1. Cenário e problemas atuais.

O compartilhamento de arquivos e serviço de arquivos remotos consolidado atualmente é problemático em ambientes de desenvolvimento. As alternativas estabelecidas, NFS v3 (NFS3) e Samba (SMB, CIFS), são limitadas, em desempenho, inconformidade POSIX, opacidade para as aplicações, inadequação para bancos de dados, segurança, estabilidade, gerenciamento e configuração. Mesmo o recente NFS v4 (NFS4) não resolve todas as limitações e ainda é considerado instável para volumes de produção. Em conseqüência, muito desenvolvimento é feito e armazenado localmente em estações de trabalho, com implicações em segurança, estabilidade, agilidade, desempenho, gerenciamento, disponibilidade e integridade de dados.
Em ambiente de desenvolvimento em micro-informática usual, com estações de trabalho completas e praticamente ilhadas em termos de desenvolvimento, estes problemas são reconhecidos. Até hoje, as soluções propostas estavam inviáveis técnica e ou economicamente para esses ambientes.

2.2. Propostas escolhidas e testadas

2.2.1. Requisitos e restrições

• Viabilidade técnica e econômica em ambientes de desenvolvimento departamentais pequenos (10 ou mais desenvolvedores).
• Não exigência de recursos de hardware, software e rede exóticos, proprietários, dispendiosos.
• Implantação completa em software livre sobre hardware e rede comuns.
• Transparência para todo tipo de aplicações. Conformidade POSIX.
• Resolver eficazmente as deficiências de serviços de arquivos compartilhados alternativos estabelecidos.
• Desempenho aceitável em volumes de carga de desenvolvimento.
• Compatibilidade, desejável homologação, para gerenciadores de bancos de dados para uso corporativo, desejável compatibilidade para uso em data warehousing, direct I/O (dio) e asynchronous I/O (aio). Especialmente para Oracle RAC e PostgreSQL.
• Disponibilidade de serviços e integridade de informações máximas viáveis a departamentos. Classe 3, desejável Classe 4.
• Não ter ponto único de falhas (SPOF).
• Estabilidade demonstrável sob cargas contínuas extremas para o hardware, software, rede implantados.
• Compatibilidade com técnicas de virtualização.
• Disponibilidade para mais de uma distribuição de sistema operacional livre com mínimas alterações no sistema operacional e efeitos colaterais nas aplicações.
• Ativo desenvolvimento e manutenção do código fonte.

2.2.2. Alternativas avaliadas e fundamentação da escolha.

A análise das restrições indicou a busca por um sistema de arquivos distribuído para iniciar a definição de arquitetura.
Avaliamos as alternativas CFS [35], GlusterFS [36], ClusterNFS [37], NFS4 [5], HaNFS [38], OpenAFS [39], MogileFS [40], StarFish [41], Lustre [42], Veritas [43], PolyServe [44], Ibrix Fusion [45], CXFS [46], PVFS [47], GPFS [48], Intermezzo [49], RapidScale (Terragrid) [50], CODA [51], pNFS [52], MFS com DFSA [53], ZFS [54] [55] [56] [57], OCFS2 [58], GFS [59] [60].
Atendendo os requisitos e restrições, restaram GFS, OCFS2, GlusterFS.
Como Oracle e Oracle RAC ainda são utilizados em projetos na empresa, os fatores desejáveis tiveram coeficientes muito elevados na consideração.
Assim, por ainda não ser homologado para uso com Oracle RAC, deixamos o GlusterFS para futuras oportunidades. Mesmo sendo superior em capacidade, flexibilidade, escalabilidade, modularidade, desempenho.
Examine a tabela competitiva [61] entre GFS e OCFS2.

GFS	OCFS2
Infra-estrutura integrada de cluster. É até possível escrever aplicação de cluster personalizada.	Sem infra-estrutura de clustering. Limitada coordenação de travamento de direitos através de um disco de quorum.
Disco de quorum opcional. Facilmente escalável a 32 nós. Possível cluster de 300 nós se não usar disco de quorum.	Disco de quórum limita o cluster a até 16 nós.
Gerenciador de volumes lógicos com capacidade de cluster integrado.	Sem gerenciador de volumes lógicos com capacidade de cluster.
Bom suporte a atributos extendidos. ACL já é suportado e SELinux está em desenvolvimento.	Sem suporte a atributos extendidos.
I/O mapeado em memória para comunicação interprocessos.	Sem I/O mapeado em memória.
Suporte a quotas.	Sem suporte a quotas.
Disponibilidade em todo cluster de flocks e locks POSIX.	Locks POSIX e flocks apenas locais aos nós.
Suporte a POSIX Access Control Lists (ACLs)	Sem suporte a POSIX ACLs
Mecanismo de fencing para assegurar integridade do sistema de arquivos.	Sem fencing.
Suporte integrado para chaveamento automático em situação de falha (failover) de aplicações (alta disponibilidade).	Sem suporte integrado a failover de aplicações.

Tabela 1: Diferenças competitivas entre GFS e OCFS2.
Assim, foi definida que a solução implementaria GFS.
Por ser integrado com a solução livre Red Hat Cluster Suite [62] [63] [86], fizemos a segunda definição por infra-estrutura de cluster.
Para viabilizar a utilização abrangente a partir de ultrapassadas e modestas máquinas disponíveis até as topo de linha, com amplo suporte e controle de qualidade na comunidade e completamente livre com facilidades de configuração e gerenciamento, definimos a distribuição Debian GNU / Linux versão estável (4.0 Etch atualmente) [64].
Sobre estes pilares, passamos a definir a arquitetura para atender os requisitos e restrições.

2.3. Definições de arquitetura implementadas, testadas e aprovadas

Ilustração 1: High availability cluster com redundância, espelhamento e replicação.
A ilustração 1 representa em abstração elevada os conceitos e módulos chave da arquitetura concebida, implementada, exaustivamente testada sob máxima carga e aprovada.
Os conceitos basilares da arquitetura, que viabilizaram alcançar disponibilidade Classe 3, e até Classe 4, são:

• Sem pontos únicos de falha
• Redundância
• Espelhamento
• Replicação
• Chaveamento automático em caso de falha (Failover)
• Montagem local

2.3.1. Sem pontos únicos de falha

Este conceito norteia a concepção, justificando escolhas heterodoxas.
Ao se definir por um sistema de arquivos distribuído, buscou-se uma infra-estrutura em cluster de nós equivalentes.
Não há um ponto central de coordenação do cluster. Todos os participantes participam da coordenação que é distribuída e baseada em quorum majoritário (metade + 1), que pode ter coeficientes diferentes por nó.
A princípio, se qualquer nó falhar, os restantes podem manter a coordenação operando e tomar ações compensatórias.
Os componentes lógicos foram escolhidos para poderem operar em múltiplas conexões alternativas em casos de falhas.
Por exemplo, para utilizarmos LVM, é necessário o uso do CLVM2 [63], com capacidade de integração à coordenação travamento de direitos de cluster. Sem ele, seríamos obrigados a utilizar discos e partições reais brutas, para não corromper o sistema de arquivos em acessos de escrita simultâneos de diferentes nós.
Como outro exemplo, o protocolo e a implementação iSCSI [67] permite mais de uma conexão ao mesmo dispositivo, até por redes físicas diferentes. E para um aproveitamento dessa característica, a escolha do device mapper multipath [68].
Aliás, a recomendação é de que realmente sejam feitas conexões por redes físicas múltiplas, não só por disponibilidade, como por desempenho, já que a própria coordenação do cluster envolve um razoável tráfego entre todos os nós participantes, o que pode limitar o número prático de nós em redes de baixa velocidade.

2.3.2. Redundância

Para ser viável já em pequenos departamentos, o cluster todo tem de operar já a partir de hardware e rede comuns.
Para ter maior disponibilidade com tais recursos, a opção de redundância de máquinas completas e, se possível, de conexões físicas e redes.
Falhas catastróficas envolvendo todo o circuito do node1 ou node2 até o node4, hardware, software e rede, podem ocorrer que não há queda de disponibilidade de serviços ou integridade de dados.
É indicado o uso de múltiplas conexões físicas e redes completas diferentes e redundantes entre os nós. Tanto por disponibilidade quanto por desempenho.
Mas não é exigência e pode ser implementado com conexões simples entre os nós.
A experiência demonstra que a rede é um elo bastante forte da corrente.
A implementação completa, com múltiplas conexões físicas completas de rede, alcança disponibilidade Classe 3.
Se for implantada uma infra-estrutura redundante geograficamente remota, pode ser alcançada disponibilidade Classe 4.
Nesse caso, o desempenho da conexão de rede poderá afetar sensivelmente o desempenho aparente do cluster, mas não a confiabilidade, pois tudo pode ser configurado para somente entregar resultado de transações se todas estiverem realmente concluídas.

2.3.3. Espelhamento

Em contraste com a robustez da rede, o ponto fraco são os dispositivos de armazenamento.
Portanto, especial atenção foi dedicada.
O espelhamento síncrono foi definido em função do uso em banco de dados.
A atividade de disco é intensa e é difícil prever se uma simples cópia em determinado instante proveria um conjunto coerente de arquivos e um banco de dados consistente. A cópia apenas garantiria um sistema de arquivos consistente.
O uso de RAID por software foi descartado porque atualmente, maio 2007, a implementação disponível estável não é compatível com coordenação de cluster.
Se houver HW RAID, é transparentemente aproveitado, mas não é exigência.
O uso de espelhamento por CLVM2 foi testado mas rejeitado, conforme análise em outro tópico deste documento.
Optamos pelo uso de DRBD [69] para manter os discos em máquinas diferentes em escrita síncrona. Configurado para apenas devolver resposta de transação de escrita concluída quando finalizada e confirmada escrita em ambos os discos.
O DRBD disponibiliza um novo dispositivo virtual presente em ambas as máquinas node1 e node2 para uso das aplicações um nível acima. Reitero: é o mesmo dispositivo para todos os efeitos práticos nas aplicações. Os dispositivos originais não devem mais ser acessados diretamente sob pena de corrupção do sistema de arquivos.
O DRBD mantém uma conexão lógica de rede entre as máquinas node1 e node2 para sincronização a nível de blocos entre os discos. Por ser em nível lógico de blocos, qualquer sistema de arquivos pode ser usado, até mesmo um sistema de arquivos em cluster.
E o DRBD pode receber como dispositivo original qualquer um que possa operar a nível de blocos, até mesmo um CLVM2, que é um LVM para cluster.
O DRBD escolhido atualmente limita o tamanho de dispositivo de blocos a até 4 TB. O DRBD+ , proprietário, eleva esse limite a 16 TB e permite um terceiro nó. O limite de 4TB é suficiente para aplicações departamentais, mesmo as que reproduzem ambientes de produção em escala na empresa, atualmente e no médio prazo.

2.3.4. Replicação

A replicação assíncrona é bem mais fácil de configurar, pois pode ser completamente implementada em user space, sem necessidade de módulos de kernel que atuem sobre I/O.
Se o sistema de arquivos tiver baixa atividade de escrita, é mais simples optar por apenas essa solução, como mostrada em definição de arquitetura em outro tópico deste documento.
Como já explicado em outro tópico, uma cópia de arquivos num dado momento proveria um sistema de arquivos consistente, mas não garantiria um conjunto coerente de arquivos em um banco de dados ativo.
Se for possível fazer um encerramento de todas atividades de escrita no sistema de arquivos pela duração do processo de replicação, muito melhor.
O GFS possui um interessante comando que é congelar a atividade de I/O de disco após um flush do cache. As aplicações ficam suspensas até que seja feito um comando de descongelar o sistema de arquivos.
Esse período pode ser usado para fazer a replicação assíncrona com maior segurança, pois arquivos voláteis poderiam aparecer e ou desaparecer entre o início e o fim de uma replicação sobre um sistema ativo.
Avaliamos as alternativas rsync [70], Unison [71], FAM+IMON [72], Xfiles [73], mirrordir [74], rsnapshot [75], Tsync [76], csync2 [77].
Escolhemos csync2 porque pode operar entre múltiplas máquinas simultâneamente e não só aos pares. Também por implementar sobre o comprovado protocolo e algoritmo básico do rsync aliado a uma granularidade de configuração fina muito boa. Mas csync2 inclui importantes acréscimos como um configurável e poderoso critério de escolha sobre conflitos.

2.3.5. Chaveamento automático em caso de falha (Failover)

Ao optarmos por iSCSI para exportar dispositivo de blocos, em rejeição ao GNBD [78], explicado em outro tópico deste documento, perdemos o recurso de fencing embutido ao programa exportador de dispositivo de blocos, que seria usado pelo programa gerenciador de cluster para fazer o chaveamento automático em caso de falha.
Como não teríamos acesso a um recurso de hardware para implementação de fencing, muito dispendioso, e a concepção de cluster deveria ser viável em hardware comum, procuramos alternativas.
Um aspecto pouco lembrado é que o protocolo original do NFS v.3 não precisa manter informação de estado entre clientes e servidor (stateless) [65]. Já um protocolo de sistema de arquivos em montagem local pode ter de manter informação de estado entre conexões (stateful), como o NFS v. 4 e sistemas de arquivo em cluster [66].
Por ser stateful, o GFS pode ser usado com aplicações que mantém seu estado no sistema de arquivos, transparentemente.
Mas isso impõe sérios problemas para o failover resolver.
A conexão falha não pode ser simplesmente interrompida e estabelecida para outro nó.
Ela precisa ser paralizada, sem perda de informações, que precisam ser armazenadas em algum buffer, e redirecionada para outro nó, que por sua vez precisa ter ou receber a mesma informação de estado que estava no nó falho.
O device mapper multipath foi concebido para prover conexão por caminhos alternativos de rede a um dispositivo de bloco, iSCSI ou GNBD, por exemplo.
Mas se usado com GNBD, tem de ser usado um dispositivo físico para fencing de nó falho. Não se poderá usar o código embutido de fencing do GNBD [85].
A importante característica a ser aproveitada aqui é que o DRBD disponibiliza UM MESMO dispositivo de blocos virtual que está presente em DUAS máquinas fisicamente distintas.
Repare que o iSCSI Target [79] possui identificadores iqn DIFERENTES, mas o ScsiId configurado para declaração e o dispositivo são os MESMOS em ambas as máquinas.
Assim, o Open-iSCSI initiator [80] importa os targets DIFERENTES, por diferentes rotas, mas porque o ScsiId e dispositivo são informados como os mesmos, ele considera serem diferentes rotas para um mesmo dispositivo de blocos.
Pode-se notar os conceitos de ausência de ponto único de falhas e redundância.
Por não termos o controle sobre fencing, o failover não é implementado pela infra-estrutura de cluster, mas por configuração do device mapper multipath, como indicado no diagrama.
Este configuramos para rotacionar a conexão ao dispositivo através das diferentes conexões a cada 5 segundos. Se identificar falha, suspende a rotação e ficar conectado a apenas uma rota até o restabelecimento da rota alternativa.
Como foi escolhida uma versão de DRBD que permite que ambos os dispositivos estejam ativos como primários, é possível fazer múltiplas conexões concorrentes ao sistema de arquivos, que não é corrompido por ser um sistema de arquivos em cluster como o GFS.
Isto é crucialmente importante, pois em alguns instantes de chaveamento o GFS estará recebendo atualizações via DRBD e, simultaneamente, via iSCSI.
O DRBD não interfere com sistema de arquivos, mas configuramos para só devolver resultado de escrita ao fim de transação em ambos os nós. No momento do chaveamento, o outro disco começa a receber requisições para transações enquanto ainda não foram completadas as anteriores e a sincronização de nós e respectivos discos.
Para manter consistência do sistema de arquivos, uma coordenação de travamento (locking) precisa estar ativa, no caso é o sistema de arquivos em cluster na infraestrutura do Red Hat Cluster Suite.
É essa coordenação que vai se encarregar de conceder, revogar, enfileirar as requisições de escrita e leitura nesses instantes de alta atividade.
Durante os 5 segundos em que está conectado ao node1 e escrevendo, o DRBD se encarrega do espelhamento síncrono com o node2, já que a transação de escrita só é concluída ao terminar escrita em ambos os nós.
No período seguinte, as funções se invertem.
Em caso de falha, a configuração é de chaveamento imediato e desabilitação da rota falha até restabelecimento e manutenção da atividade de I/O para aplicações superiores.
Se fossem dispositivos diferentes ou dispositivo stand-by inativo, teria de haver enfileiramento e congelamento da atividade de I/O ao completar o buffer, para as aplicações superiores até o restabelecimento de rota. Se isso fosse causado por falha de máquina demorada, as aplicações estariam presas ao processo por esse tempo. Para usuários, teriam aparência de aplicações travadas ou em descontrole mas não o sistema operacional. Só que não seria por bug; estariam aguardando finalização de transação de I/O.
Na configuração implementada, com ambos dispositivos ativos primários, em caso de falha de uma rota (engloba rede e máquina em nosso contexto), uma atividade de I/O é enfileirada e imediatamente redirecionada para a outra rota de forma transparente para as aplicações, então esvaziando a fila.
Apenas se AMBAS as rotas falharem haverá resposta de falha para as aplicações.
Dependendo das aplicações e conseqüências de uma falha total de I/O para elas, pode ser conveniente configurar para enfileirar e congelar atividade de I/O em caso de falha de ambas as rotas até o restabelecimento.
As conexões de rede também podem ser redundantes.
Com isso, se pode perceber que o failover não está sendo feito pela infraestrutura de cluster do Red Hat Cluster Suite, mas por conjunto de funções encadeadas do device mapper multipath, iSCSI Enterprise Target e Open-iSCSI initiator, viabilizados pelo DRBD.
Adicionalmente, como característica chave, não há perda de informação de estado no chaveamento e este é muito rápido, sem perda de informações em trânsito que estejam sendo processadas.
Praticamente imperceptível para as aplicações. Apenas alguns milisegundos de atraso na transação de escrita ou leitura pelo chaveamento.
Transparente para as aplicações, sem modificações.
Se for possível, é recomendável implantar um dispositivo de fencing por hardware, que desabilite o nó falho.
Nossa implementação utiliza fencing manual para manter o custo baixo.

2.3.6. Montagem local

Corretamente instalado e configurado, o sistema de arquivos GFS em cluster mantém localmente, em cada um dos nós, um journal particular a cada nó integrante do cluster.
Na implementação do diagrama, vê-se que está configurado para quatro jounals em cada nó.
Assim, cada nó tem individualizada informação de estado de transação de todos os nós do cluster.
Nos journals estão presentes informações de metadados e, se configurado para tal, também de dados.
O gerenciador distribuído do cluster mantém a consistência e coerência dos journals por todos os nós, corrigindo eventuais atrasos até que todos estejam coerentes e encerradas as transações em todos nós e discos.
Com isso obtemos um desempenho aparente limitado pela largura de banda útil da rede.
Isso é demonstrável através da montagem local síncrona do dispositivo importado através do Open-iSCSI initiator, como no caso mais simples do node3, sem device mapper multipath.
Então cada transação de I/O só é informada como encerrada após os dados estarem efetivamente escritos no disco e todos os caches e journals terem sido esvaziados (flushed) e concluídos (commited).
O desempenho é ordem de magnitude menor que montagem local assíncrona e próxima do limite da rede, conforme documentado nos resultados de testes em outro tópico deste documento.
Notar que todos os escolhidos integrantes do circuito possuem capacidade de prover acesso a nível de blocos, independentemente de sistema de arquivo escolhido.
Assim, a informação de blocos pode chegar até o ponto final de montagem e ser implantado o sistema de arquivos POSIX distribuído em cluster montado localmente com capacidade de direct I/O e asynchronous I/O, apto ao uso em banco de dados como Oracle RAC e PostgreSQL.

2.4. Resultados de testes

Todos os testes executados com o mesmo hardware e rede.
Node1, 2, 3 , PIII 866 MHz, 256 MB RAM, disco 20 GB 5400 rpm, 1 x 100 Mb/s.
Node4, P4 3.2 GHz, 1GB RAM, disco SATA 80 GB 7200 rpm, 1 x 100 Mb/s.
O segmento de rede departamental continha tráfego normal de horário de expediente, sem alocação exclusiva ao cluster, representando um caso prático em departamento.
Todos os nós executando Debian GNU / Linux 4.0 Etch atualizado até o momento do teste. O node4 executava interface gráfica. Os node1, node2, node3 foram instalados na modalidade instalação básica mínima e acrescentados apenas os pacotes que se fizeram necessários para satisfazer dependências e instalar o cluster.
Houve necessidade de aplicar vários patches e recompilar os pacotes para Debian GNU / Linux com correções definidas pelo autor e outros, conforme documentado em artigo do blog pessoal do autor [81].
Os pacotes foram recompilados no node4 e então instalados nos outros nós.
Todos os programas instalados usando o sistema de pacotes Debian.

2.4.1. Velocidade de escrita sustentada

2.4.1.1. Sem device mapper multipath nem drbd (node 3)

Com os modestos hardware, discos e rede disponíveis no departamento, foi obtida uma taxa sustentada de 700 KB/s de escrita em disco GFS remoto com montagem local síncrona.
Fazendo montagem local assíncrona, foi possível obter uma taxa sustentada de 10 MB/s.
A velocidade máxima teórica numa rede local de 100 Mb/s é de aprox. 12,5 MB/s.
Usados arquivos de imagens ISO de cd para teste.
Um sistema de arquivos montado em uma máquina remota.
Cópia local usando scp, que exibe a velocidade de transmissão mesmo quando usado localmente.

2.4.1.2. Com device mapper multipath e drbd (node1 e node2)

Usando ainda o mesmo hardware, rede, arquivos e comandos.
Fazendo montagem local assíncrona, foi possível obter uma velocidade sustentada de 8 MB/s.

2.4.2. Resultados de Bonnie++

Bonnie++ executa uma série de testes de desempenho de memória de armazenamento que simulam operações de banco de dados e de serviço de arquivos. Estabelecido na comunidade de software livre como referência para benchmarking de discos rígidos.
Os resultados que estão listados com +++ indicam execução total em menos de 500 ms e descartados por imprecisão estatística na média.
Os resultados estão listados em quadro pré-formatados para melhor visualização.

2.4.2.1. Ext3 local com montagem local (node4)

Foi uma referência para comparações no hardware utilizado.

user@node4:~$ /usr/sbin/bonnie++ -d /mnt/ext3 -s 2G -n 1 -x 1 | \
 /usr/bin/bon_csv2txt > bonnie_ext3_output_2gigas.txt
 

Version 1.03 ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
node4 2G 43164 95 52428 20 22157 5 41735 81 56235 4 129.8 0
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files:max:min /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
node4 1 +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++

2.4.2.2. GFS remoto com montagem local via device mapper multipath e drbd (node1 e node2)

user@node4:~$ /usr/sbin/bonnie++ -d /mnt/gfs1 -s 2G -n 1 -x 1 | \
/usr/bin/bon_csv2txt > bonnie_gfs1_multipath_output_2gigas.txt
 

Version 1.03 ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
node4 2G 9655 27 9654 5 4022 2 10185 23 8131 1 89.8 0
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files:max:min /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
node4 1 487 7 +++++ +++ 1198 10 419 5 +++++ +++ 1334 11

2.4.2.3. GFS remoto com montagem local sem device mapper multipath nem drbd (node3)

user@node4:~$ /usr/sbin/bonnie++ -d /mnt/gfs3 -s 2G -n 1 -x 1 | \ 
/usr/bin/bon_csv2txt > bonnie_gfs3_output_2gigas.txt
 

Version 1.03 ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
node4 2G 10799 31 12682 7 4526 2 10272 29 8332 1 82.4 0
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files:max:min /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
node4 1 992 10 +++++ +++ 2038 17 1831 19 +++++ +++ +++++ +++

2.4.2.4. GFS local com montagem local (node4)

user@node4:~$ /usr/sbin/bonnie++ -d /mnt/gfs -s 2G -n 1 -x 1 | \
 /usr/bin/bon_csv2txt > bonnie_gfs_local_output_2gigas.txt
 

Version 1.03 ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
node4 2G 36623 97 52419 40 22485 11 39464 87 47982 9 117.4 0
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files:max:min /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
node4 1 +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++

2.5. Definições de arquitetura implementadas, testadas e preteridas

2.5.1. Cluster com failover externo ou manual

 

Ilustração 2: High availability cluster com espelhamento e replicação, failover externo.
Esta implementação funcionou como esperado por seus componentes.
A versão de DRBD utilizada permitia apenas uma máquina primária em dado momento.
Assim, o node2 era mantido sincronizado mas em espera.
Em caso de falha do node1, um programa externo deveria fazer a reconfiguração do dispositivo drbd desabilitando o do node1, tornando primário o dispositivo do node2 e reconfigurando a rota até o node4.
Mantém comprovadamente a integridade dos dados.
Mas a disponibilidade fica um pouco reduzida, por alguns minutos se for executada manualmente por comandos apropriados, ou por alguns instantes se implementada pelo programa externo (heartbeat).
Não explorou eficientemente a infra-estrutura de cluster disponível.
Não implementou o grau de redundância desejado, e ainda era possível um ponto único de falhas, na rota do iSCSI.
Apesar dos méritos e testes funcionais positivos, foi preterida por não satisfazer todos os requisitos e atender plenamente disponibilidade Classe 3.
Ainda assim, pode ser uma opção em algumas circunstâncias.

2.5.2. Cluster com replicação assíncrona

 

Ilustração 3: High availability cluster com replicação assincrona.
Esta implementação mais simples funcionou conforme esperado por seus componentes.
Bastante confiável, foi testada durante 3 dias ininterruptos sob carga concorrente máxima possível no hardware, software, rede e não apresentou falhas.
Porém, utiliza apenas replicação assíncrona.
Se não for utilizada em uma aplicação de grande atividade transacional, é uma interessante opção pela menor complexidade e flexibilidade.
Mas não é transparente para as aplicações, já que são diferentes pontos de montagem, que aparentam ter praticamente os mesmos dados ao final dos ciclos de sincronização.
A menos que seja utilizado o comando de congelamento de sistema de arquivos GFS até o fim de cada etapa de sincronização, que pode ser configurado em scripts auxiliares no csync2.
Isso garantiria igualdade de conteúdo ao fim dos ciclos de sincronização e integridade dos dados, mas ainda não seria transparente às aplicações.
Em caso de falha do node1, por exemplo, as aplicações deveriam redirecionar para o node2 após uma verificação de coerência de dados. A consistência já é garantida pela sincronização.
Ou o node1 poderia ser desmontado e remontado o node2 no mesmo ponto de montagem do node1. Ainda não transparente às aplicações e com algum impacto na disponibilidade.
A facilidade da implantação é atraente e deve ser considerada se for suficientemente baixa a atividade de escrita no sistema de arquivos para a coerência dos dados não ser fortemente impactada pelos intervalos de sincronização.
Não recomendamos chaveamento automatizado, pois é importante fazer uma verificação manual da coerência dos dados antes de disponibilizar a cópia do sistema de arquivos para as aplicações.
Deve ser considerada como um backup automatizado de maior freqüência e comodidade, pois a restauração de operações pode demorar apenas alguns minutos.
Ainda assim, supera as deficiências de serviços de arquivos que não disponibilizam acesso em nível de blocos, mas a nível de arquivos, como o NFS e CIFS.

2.6. Definições de arquitetura implementadas e rejeitadas

2.6.1. Cluster com replicação assíncrona e GNBD

 

Ilustração 4: High availability cluster usando GNBD com replicação assíncrona
Esta implementação foi rejeitada principalmente porque o GNBD não demonstrou confiabilidade para uso sob carga significativa.
Com detalhes registrados no blog pessoal do autor [81], o GNBD provocava congelamentos de I/O quando submetido a cargas de acesso simultâneas.
Acompanhando os debates na comunidade de desenvolvimento do Red Hat Cluster Suite, verificamos que outros usuários enfrentam esporádicos e infreqüentes, porém preocupantes, problemas semelhantes.
Até então, não havia sido possível rastrear a causa pois o autor foi o primeiro a utilizar os programas em hardware e rede tão limitados, onde os extremos são facilmente alcançados e cargas máximas são mais facilmente examinadas.
Usando múltiplas redes privadas de fibra ótica, dispositivos SAN de alto desempenho, capazes de 450 MB/s sustentados, as race conditions são muito esporádicas. Raras mesmo.
Os desenvolvedores agora estão a par do problema e as futuras versões poderão incorporar aprimoramentos necessários.
Atualmente, a ausência do GNBD inviabiliza o uso de fencing por software que ele incorporava.
O mecanismo de failover do cluster teria de usar um dispositivo externo de hardware, elevando o custo.
Sem contar que sua pronta integração ao resto da infra-estrutura do cluster torna tudo mais simples.
As futuras versões devem ser acompanhadas.
E também se será possível implementar device mapper multipath por elas ou o fencing e failover embutidos serão funcionais [85] e rápidos o suficiente para transparência às aplicações.

2.6.2. Cluster redundante com espelhamento síncrono por CLVM2

Ilustração 5: Cluster de alta disponibilidade redundante com espelhamento síncrono por CLVM2.
Esta seria a melhor implementação e foi a tentativa inicial.
Infelizmente, os componentes necessários não demonstraram funcionalidade ou confiabilidade esperados [81].
CLVM2 não implementa corretamente o espelhamento em cluster ainda. Os volumes sequer podem ser ativados remotamente, apenas localmente, para só depois participarem de cluster. A criação dos espelhos falha com mensagens sobre tamanho incorreto. Continua em desenvolvimento.
CLVM snapshots também ainda não são suportados.
Espelhamento e snapshots, em maio 2007, apenas em modo local comum, sem clustering.
GNBD não está confiável [81], conforme explicado em outro tópico deste documento.
O projeto Red Hat Cluster Suite deve ser acompanhado, pois quando estiverem disponíveis as funcionalidades, o cluster será de muito mais simples implantação e com maiores possibilidades de redundância e espelhamento.

3. CONCLUSÃO

3.1. Problemas atuais com soluções propostas neste trabalho

Este trabalho focou-se em propostas de soluções para problemas existentes em ambientes de desenvolvimento.
A configuração, manutenção, controle e gestão de configuração de hardware e software para toda uma equipe, assim como o ágil desenvolvimento e experimentação de alternativas, a depuração e testes, homologação e transição para implantação em produção são tarefas complexas, demoradas, dispendiosas e sujeitas a dificuldades, inconsistências, riscos à estabilidade e segurança.
Com impacto direto sobre os compromissos de desenvolvimento assumidos com clientes e os custos da empresa, a disponibilidade de serviços e integridade das informações em ambientes de desenvolvimento foram assuntos diretamente enfrentados.
As alternativas estabelecidas para serviço de arquivos remotos consolidado e compartilhado, NFS v3 (NFS3), Samba (SMB, CIFS) e mesmo o recente NFS v4 (NFS4), são limitadas, em desempenho, inconformidade POSIX, opacidade para as aplicações, inadequação para bancos de dados, segurança, gerenciamento e configuração.
Em decorrência, muito desenvolvimento é feito localmente em estações de trabalho, com implicações em segurança, estabilidade, agilidade, desempenho, gerenciamento, disponibilidade e integridade de dados.

3.2. O que a virtualização pode resolver e seus benefícios

A virtualização de máquinas em ambientes de desenvolvimento pode garantir a consistência de configurações por toda a equipe.
Exemplificando, uma configuração de referência pode ser preparada e homologada para um determinado projeto.
Instalada em um arquivo de disco de máquina virtual, por exemplo, pode ser copiada para que diversos desenvolvedores possam executar instâncias da mesma.
Por ter sido instalada sobre uma máquina virtual, tal configuração é consistente com um hardware virtual que pode ser recriado em outra localidade e igual para toda equipe, independentemente do hardware e software hospedeiro.
A estabilidade das estações de trabalho é maior, pois as mesmas apenas executariam máquinas virtualizadas, até remotamente. As configurações locais teriam pouca influência sobre as virtualizadas.
A flexibilidade para experimentações é maior porque o desenvolvedor pode até desconfigurar e desestabilizar irremediavelmente uma máquina virtual, apagá-la e recriar a partir da cópia de uma máquina em configuração de referência muito mais rapidamente do que em uma máquina física real.
Os discos das máquinas virtuais podem estar armazenados em servidores consolidados confiáveis, com facilidades de backup, disponibilidade e integridade de dados.
A configuração de referência para integração e homologação pode ser igual ou similar ao ambiente de produção (quando virtualizado), minimizando surpresas na implantação.
A integração e homologação são consistentes e facilitadas, pois a configuração de referência também seria igual ou similar ao ambiente de produção. Uma cópia apropriada de arquivo ou partição de disco da máquina virtual e transmissão à equipe de implantação garantiria uma transição sem surpresas.
Ambientes remotos para integração e homologação nas máquinas e ambiente de produção não mais seriam exigidos, para depuração e configurações. Desta forma, menor risco de segurança e instabilidades nesses ambientes críticos.

3.3. Vantagens obtidas com serviço de arquivos em cluster

3.3.1. Economias

A economia de cada hora departamental parada em média é de R$ 5 mil. Um incidente grave de disponibilidade pode tomar 3 dias efetivos, R$ 120 mil. Um incidente real registrado tomou 22 dias e perda irrecuperável de informações estimadas em R$ 2,5 milhões.
Implementação completa em software livre. Economia de licenças de sistemas operacionais e programas específicos para clusters. Economia e controle sobre modo de uso dos programas. Uma implantação completa de Veritas [43] ou Bakbone NetVault Replicator [84] e Oracle Data Guard [82] e Oracle Recovery Manager [83] para apenas 4 nós pode custar dezenas de milhares de dólares para os mesmos recursos implementados.
Implementação completa a partir de hardware comum, reciclado, e redes comuns já é viável. Dispensa exigência de SAN, HW RAID, FC, Ultra320 SCSI, Firewire, GbE, InfiniBand, embora claramente se beneficie desses recursos para aumento de confiabilidade.

3.3.2. Características e benefícios

Disponibilidade Classe 3 (99% a 99,9%) e viabilidade de implantar Disponibilidade Classe 4 (99,9% a 99,99%) nos serviços departamentais críticos se replicar a estrutura remotamente.
Disponibilidade Classe 3 e até Classe 4 nos serviços departamentais de desenvolvimento permite melhor atendimento dos compromissos com clientes.
Integridade de dados em caso de falhas catastróficas completas de servidores. Maior garantia de patrimônio. Um incidente prévio registrado causou prejuízo de milhões de reais em informações.
Reprodução em escala de ambientes de produção em condições limite para melhor desenvolvimento e depuração.
Melhor controle de configurações e reprodutibilidade no desenvolvimento por toda equipe. Maior qualidade, controle e agilidade nas responsabilidades e tarefas de GCS e GCI.
Maior agilidade na experimentação e avaliação rápida de alternativas de implementação. Menor prazo e esforço em homens hora no desenvolvimento.
Implantação em produção potencialmente mais controlada e ágil. Menores problemas inesperados. Menores custos e prazos.
Viabilização de virtualização, clusters, alta disponibilidade, redundância, espelhamento e replicação a custos baixos e já a partir de recursos de hardware e rede amplamente disponíveis. Até hoje exigia hardware, software e rede exóticos, proprietários, dispendiosos, justificáveis apenas em altos volumes de processamento e produção, sendo inviáveis em ambientes departamentais de desenvolvimento.
Maior preservação, menor risco à estabilidade e segurança de ambientes de homologação e produção.
Máxima continuidade e integridade de serviços e informações de desenvolvimento impacta positivamente toda a cadeia de compromissos com clientes e imagem da empresa no mercado.
Configuração sem Ponto Único de Falhas (SPOF). Redundância completa. Mesmo clusters comerciais possuem um ou mais SPOF. Disponibilidade maior que soluções comerciais.
Conformidade total com POSIX, tendo ACL e montagem local. Transparência total para todo tipo de aplicações.
Homologado para Oracle RAC e compatível com PostgreSQL. Disponibiliza direct I/O (dio) e asynchronous I/O (aio) do sistema de arquivos para aplicações como Oracle RAC.
Controle sobre uso dos programas. Por exemplo, as licenças de uso de soluções de redundância do Oracle RAC cobram por dias de uso (até 10 dias). As de replicação do Oracle RAC permitem um número de utilizações definido. É um programa pré-pago.
Sistema de arquivos nativo de 64 bits e alta capacidade (16 TB) e desempenho para uso em Data Warehousing.

3.4. Sinergia de soluções

Quando a virtualização é usada em conjunto com as técnicas de compartilhamento de arquivos em cluster, com redundância, espelhamento, sincronização, montagem local, a interação torna-se sinergética e possibilidades de uso, consistência, disponibilidade, integridade, confiabilidade têm um resultado maior do que a soma de seus benefícios.
Os discos das máquinas virtuais estariam instalados no sistema de arquivos em cluster com redundância.
Máquinas virtuais de serviços mais críticos durante a fase de desenvolvimento poderiam ser executadas em nós do cluster em configuração de chaveamento automático em caso de falhas, para não afetar a continuidade do serviço.
A mobilidade de execução das máquinas virtuais, usando a infraestrutura de virtualização e cluster seria melhor explorada.
Atualmente, Xen pode mover a execução de uma máquina virtual em 100 ms, em uma rede e hardware de alto desempenho. Aliado às capacidades do cluster, isso poderia representar uma disponibilidade ótima num departamento de desenvolvimento.

3.5. Benefícios totais

Este trabalho apresentou as dificuldades, as peculiaridades, problemas obscuros e não documentados, e as soluções criadas ou encontradas, na implementação de cluster em condições máximas de carga de servidores, discos, e saturação de rede em processos concorrentes.
Apresentou resultados de testes de desempenho comparativos de diferentes configurações para avaliações de custos X benefícios em diferentes situações e em aplicações em ambientes de desenvolvimento.
Apresentou alternativas e configurações, em desenvolvimento, para futuras implementações ainda melhores e mais eficientes.
Este trabalho apresentou, principalmente, implementações testadas e quantificadas que racionalizam, integram e consolidam ambientes de desenvolvimento, aumentando agilidade das equipes, minimizando prazos, esforços de configuração, gerenciamento, riscos, custos, e maximizando disponibilidade de serviços e integridade de informações nesses ambientes.
Reiteramos que os conceitos apresentados não são substitutos para backups. São medidas complementares integrantes de um plano de contingências departamental.
Não substituem hardware e rede de alta confiabilidade e desempenho. Se estes estiverem disponíveis, serão aproveitados com ainda maior eficiência e eficácia.
São soluções viáveis técnica e economicamente já em pequenas equipes departamentais, com potencial de extrapolação para outros ambientes, em todo ou em parte, com benefícios antes inviáveis em departamentos.