2.6 ANÁLISE DOS DADOS
2.6.4 Análise do funcionamento
2.6.4.1 Simulação de falhas no Heartbeat
Conforme Figura 2.24: é possível verificar o funcionamento do Heartbeat no node1 através do comando ifconfig que possibilita a visualização das configurações de rede, bem como do IP virtual pertencente ao cluster.
Figura 2.24: Node1 com IP virtual
DESCRIÇÃO SERVIDOR PRIMÁRIO SERVIDOR SECUDÁRIO CLIENTE WINDOWS Sistema
Operacional Debian 7 Whezzy Debian 7 Whezzy Windows 8
Hostname Node 1 Node 2 Cliente
HD 20GB do Sistema 40GB Para Cluster 20GB do Sistema 40GB Para Cluster 960GB Sistema IP eth0 192.168.1.10 eth1 10.0.0.1 eth0:0 192.168.1.30 IP virtual utilizado pelo serviço Heartbeat e o DRBD para envio de requisições e resposta aos clientes eth0 192.168.1.20 eth1 10.0.0.2 eth0:0 192.168.1.30 IP virtual utilizado pelo serviço Heartbeat e o DRBD para envio de requisições e resposta aos clientes 192.168.1.106 Serviços Heartbeat, DRBD, Mon e Samba Heartbeat, DRBD, Mon e Samba **************** *
Fonte: Próprios autores.
Como descrito na seção 2.5.1, o Heartbeat possui seu funcionamento baseado no envio periódico de mensagens entre os nodes. Essas mensagens são enviadas através de broadcast com portas de origem 45138 e destino 694, conforme Figura 2.25.
Figura 4.25: Comunicação Heartbeat
Durante os testes de paralização do processo do Heartbeat no node1 através do comando /etc/init.d/heartbeat stop ou interrupção na comunicação entre os nodes desconectando o cabo de rede, o node2 assumiu o IP virtual como esperado conforme Figura 2.26, levando para isso aproximadamente 2 segundos.
Fonte: Próprios autores.
2.6.4.2 SIMULAÇÃO DE FALHAS NO DRBD
O Heartbeat não possui qualquer mecanismo que possibilite o sincronismo das informações em ambos os nodes. Para essa finalidade foi utilizado o software DRBD (Distributed Replicated Block) configurado com o Protocolo C, descrito na seção 2.5.2. Na Figura 2.27 é possível observar o processo de transferência de um arquivo de mídia, com tamanho de 594 MB realizado por um cliente com IP 192.168.1.106 no node primário, que faz uso IP virtual 192.168.1.30, nesse mesmo instante o node primário inicia o envio das informações para o node secundário, mantendo assim o sincronismo das informações, conforme pode ser verificado na Figura 2.28.
Fonte: Próprios autores.
Figura 2.28: Sincronismo dos DRBDs
O DRBD se mostrou eficaz no sincronismo das informações, replicando as alterações realizadas no node primário para o secundário em tempo real.
Nos testes em que foram simuladas as falhas no node primário, o node secundário mudou seu estado para primário, assumindo o IP virtual e montando a partição administrada pelo DRBD, sincronizada anteriormente, conforme Figura 2.29 e Figura 2.30.
Figura 2.29: Partição montada node1
Fon te: Próprios autores.
Figura 2.30: Partição montada node 2
Fonte: Próprios autores.
Para os casos em que foram simuladas falhas no node primário, que tenham afetado a comunicação do DRBD entre os nodes (desconexão do cabo de rede da
interface eth0 ou paralização total do servidor) foi observado no processo de failback um fenômeno denominado Split Brain, conforme descrito na seção 2.3.2 Para solucionar esse problema o DRBD possui em seu arquivo de configuração instruções que fazem o servidor dado como morto anteriormente desligar, evitando inconsistência entre as informações em ambos os nodes.
Caso o administrador opte por remover esse recurso no arquivo de configuração do DRBD, o cluster irá comportar-se normalmente, exceto no processo de failback, necessitando de intervenção para remover o Split Brain.
Outro teste realizado foi na interrupção do servidor primário durante a transferência de um arquivo realizada por um cliente, embora o servidor secundário tenha assumido o controle dos serviços, outrora administrados pelo servidor primário, foi observada a ocorrência de um erro, conforme Figura 2.31. Esse erro está relacionado a inconsistência da tabela ARP (Address Resolution Protocol) presente no host do cliente, que ainda indica o MAC address do servidor dado como morto como endereço físico do IP virtual, ocasionando duplicidade de endereço IP, como ilustrado na Figura 2.32.
Figura 2.31: Erro de transferência de arquivo
A modificação da tabela ARP no host ocorre automaticamente após nova tentativa de comunicação com o IP virtual, agora em posse do host secundário denominado node2, conforme a Figura 2.33 onde é possível observar a saída do comando arp -a, onde o endereço IP virtual (192.168.1.30) antes associado ao mesmo endereço físico (00-0C-29-6F-2C-09) do node1 (192.168.1.10), agora é associado ao endereço IP do node2 (192.168.1.20).
Figura 2.33: Tabela ARP
2.6.4.3 SIMULAÇÃO DE FALHA NO SERVIÇO SMB DO SAMBA
A utilização conjunta do Heartbeat e DRBD não proporciona total automação do cluster e consequentemente continuidade dos serviços, pois uma falha no processo da aplicação que fornece o serviço, neste caso o Samba, pode ocasionar a paralização total dos serviços, uma vez que o Hertbeat não possui mecanismos que possam identificar a paralização da aplicação. Para essa finalidade foi utilizado o software Mon descrito na seção 2.5.3.
Na Figura 2.34 pode ser observado o Mon monitorando o serviço do Samba, o smb que se encontra ativo mostrado na coluna sete (Sumary), com a mensagem Ok. Após a simulação da ocorrência de falha no serviço do Samba no node1, o software Mon que se encontra instalado no node primário irá parar o funcionamento do Heartbet forçando o node secundáro a assumir o controle dos serviços bem como do IP virtual 192.168.1.30, até o momento administrado pelo node primário. Na Figura 2.35 pode ser observada a detecção da interrupção do smb mostrada na coluna três (Status), onde a mensagem presente é Fail.
Figura: 2.34: Mon monitorando o smb do Samba
Figura: 2.35: Mon notificando a paralização do smb do Samba do node1
Nos dias atuais, mesmo em organizações que não têm a tecnologia como atividade fim, há a necessidade de dispor de recursos que possibilitem o bom funcionamento da instituição, bem como a entrega satisfatória de serviços ou produtos a seus clientes. Paralizações constantes nos serviços podem ocasionar insatisfação dos clientes, levando a prejuízos, muitas vezes irreversíveis, a reputação da organização, dado o grau de exigência dos clientes.
As aplicações analisadas mostraram-se bastante customizáveis, podendo ser utilizadas em diversos cenários. Por se tratar de um sistema constituído por aplicações Open-Source, a implementação do cluster aqui proposto torna-se bastante atrativa por não exigir altos investimentos, podendo ser implementado em computadores de pequeno porte de uso pessoal.
Durante a análise dos dados foram constatadas algumas limitações, embora funcionem totalmente sincronizados, caso ocorra falha no node principal durante o processo de Download ou Upload de arquivos realizado por um usuário, o node secundário irá assumir o controle dos serviços, no entanto as informações trafegadas pelo usuário referente ao momento da falha serão perdidas, no caso de Download, ou corrompidas, no caso de Upload.
Em virtude dos aspectos analisados, os objetivos do presente trabalho são dados por alcançados, uma vez que a implementação do cluster aqui proposto possibilitou uma rápida recuperação do sistema em caso de falhas, aumentando significativamente a disponibilidade dos serviços. Embora tenha sido utilizado nesse trabalho o serviço de compartilhamento de aquivos e diretórios para demonstrar o funcionamento da implementação, a solução proposta pode ser empregada para aumentar a disponibilidade de outros serviços como, serviços de Proxy, Firewall, servidores Web, dentre outros.
REFERÊNCIAS
AGUIAR, G. M. O que é alta disponibilidade. Technet, 2012. Disponivel em: <https://technet.microsoft.com/pt-br/sqlserver/hh226646.aspx>. Acesso em: 11 fevereiro 2015.
ALDEVAN. Calcular disponibilidade e indisponibilidade dos ativos de rede. Under Linux, 2013. Disponivel em: <https://under-linux.org/entry.php?b=3069>. Acesso em: 29 mar. 2015.
ALECRIM, E. Missão Crítica: conceitos básicos. Infowester, 20 mar. 2005. Disponivel em: <http://www.infowester.com/missaocritica.php>. Acesso em: 20 mar. 2015.
AMARAL, M. C. D. Reason-Avaliação de confiabilidade e disponbilidade em redes de computadores sustentáveis, São Paulo-SP, 2014.
BACELLAR, H. V. Cluster: Computação de Alto Desempenho, Campinas-SP, 2010. 1-6.
BARROS, M. B. S. Tolerância a Falhas em uma Aplicação de Processamento Sísmico para Cluster Multicore., Niteroi-RJ, 2011.
BATISTA, J. W. D. S. Cluster de Alta Disponibilidade em Sistema Linux. Slideshare, 2011. Disponivel em: <http://pt.slideshare.net/jbwillinas/artigo-alta-disponibilidade- em-sistema-linux>. Acesso em: 14 Fevereiro 2015.
BRAGA, M. A. Implementação dos protocolos freestore de Reconfiguração de Sistemas de Quóruns., Brasília-DF, 2014.
BRANDÃO, R. Conceitos sobre Disponibilidade. Technet, 2011. Disponivel em: <https://technet.microsoft.com/pt-br/library/cc668492.aspx>. Acesso em: 29 mar. 2015.
BRUSCHI, F. S. D. S. C. V. D. O. T. G. C. Gerenciamento e alta disponibilidade em armazenamento de banco de dados, Bauru-SP, 2013.
CAMBIUCCI, W. Exemplos de projetos de Missão Crítica. Profissionais TI, 2009. Disponivel em: <http://www.profissionaisti.com.br/2009/11/exemplos-de-projetos-de- missao-critica/>. Acesso em: 17 abr. 2015.
CONCEIÇÃO, M. D. DEPENDABILIDADE COM PROCESSOS ITIL, Canoas-RS, 04 dez. 2012.
COSTA, H. L. A. lta Disponibilidade Balaceamento de Carga para melhoria de sistemas de computadores críticos usando software livre um estudo de caso, Viçosa- MG, 2009.
COSTA, P. H. A. D. O que é o SAMBA? In: COSTA, P. H. A. D. Samba: Windows e Linux em rede. SP: Linux Magazine, 2011. p. 14.
DRBD. Linbit. DRBD, 2015. Disponivel em: <http://drbd.linbit.com/>. Acesso em: 20 mar. 2015.
FERRÃO, L. M. D. S. Comutação distribuída: o melhor aproveitamento de recursos computacionais. Linguagem Acadêmica, p. 93-119, 2012.
FERRAZ, J. Serviço Samba. Jairo Pro, 2013. Disponivel em: <www.jairo.pro.br>. Acesso em: 05 abr. 2015.
FONSECA, M. S. Projeto de um balanceador de carga de Servidores para sistema
confiável Linux. FGA, 2014. Disponivel em:
<http://fga.unb.br/articles/0000/5580/TCC1_MatheusFonseca.pdf>. Acesso em: 20 mar. 2015.
FRANCK, H. D. S. Avalizção de Atraso Consumo e Proteção de Somadores olernates a Falhas, Porto Alegre-RS, 2011.
GOUVEIA, J. Tecnologia RAID. In: GOUVEIA, J. Gestão Prática de Redes de Computadores. 1ª. ed. Lisboa: FCA - Editora de Informática, Ltda, 2011. Cap. Tecnologia RAID, p. 171-174.
HEARTBEAT. Alta disponibilidade - CLuster - Meios de transmissão - heartbeats -
Funcionamento. HeartBeat, 2008. Disponivel em:
<http://replicacao.no.sapo.pt/heartbeat.htm>. Acesso em: 14 Fevereiro 2015.
IBM. High-availability middleware on Linux, Part 1: Heartbeat and Apache Web server. IBM, 2004. Disponivel em: <http://www.ibm.com/developerworks/library/l- halinux/>. Acesso em: 14 Fevereiro 2015.
JERPS, B. Stretched clustering basics. Bartsjerps, 2011. Disponivel em: <https://bartsjerps.wordpress.com/2011/08/11/stretched-clustering-basics/>. Acesso em: 24 mar. 2015.
JORDÃO, F. DDoS: como funciona um ataque distribuído por negação de serviço.
Tecmundo, 24 Junho 2011. Disponivel em:
<http://www.tecmundo.com.br/seguranca/10970-ddos-como-funciona-um-ataque- distribuido-por-negacao-de-servico.htm>. Acesso em: 10 abr. 2015.
JR, B. A. D. S. Balanceamento e Alta Disponibilidade com LVS. brivaldojunior, 27
Junho 2011. Disponivel em:
<http://brivaldojunior.docente.ufms.br/2011/06/balanceamento-de-servicos- utilizando-lvs/>. Acesso em: 03 14 2015.
KRUGER, K. Programação de Micro controladores utilizando técnicas de tolerãncia a, Mato Grosso do Sul, 30 jul. 2014.
KUROSE. Redes de Computadores e a Internet. In: KUROSE, J. F. Redes de Computadores e a Internet. 5. ed. São Paulo-SP: [s.n.], 2011. p. 325.
LIMA, G. D. O. Arquitetura de Computação em Nuvens com Dependibilidade, Uberlândia-MG, 2014.
LINUX PLACE. Servidor em Alta Disponibilidade HA. Linux Place. Disponivel em: <http://linuxplace.com.br/solucoes/alta-disponibilidade-cluster/servidor-de-alta-
disponibilidade-cluster>. Acesso em: 19 Fevereiro 2015.
MARTINS, E. O que é VPN. Tecmundo, 2009. Disponivel em: <http://www.tecmundo.com.br/1427-o-que-e-vpn-.htm>. Acesso em: 18 fev. 2015. MATTE, J. R. Projeto de Alta Disponibilidade para Processamento de Transações Eletrônicas, Novo Hamburgo-RS, 2009.
MATTOS, É. D. Sistema de Firewalls em Alta Disponibilidade, Curitiba-PR, mar. 2010.
MORIMOTO. Samba. In: MORIMOTO, C. E. Servidores Linux Guia Pratico. 1º. ed. Porto Alegre-RS: [s.n.], 2011. Cap. 5, p. 243 - 247.
NATÁRIO, R. Redes e Servidores, 2011. Disponivel em: <http://redes-e- servidores.blogspot.com.br/2011/04/failover-clustering-i.html>. Acesso em: 26 mar. 2015.
NEGUS, C. Configurando um Servidor de compartilhamento de arquivos do Windows (Samba). In: NEGUS, C. Linux a Bíblia. 1º. ed. Rio de Janeiro: [s.n.], 2014. Cap. 19, p. 489 - 490.
NEVES, D. D. S. E. V. H. CLUSTER DE ALTA DISPONIBILIDADE EM LINUX, Santa Barbara d' Oeste-SP, 2012.
PITANGA, A. M. J. Cluster de Alta Disponibilidade em Linux. Curso Escola Linux, 29 dez. 2014. Disponivel em: <http://cursos.escolalinux.com.br/curso/cluster-de-alta- disponibilidade-linux-14-horas>. Acesso em: 04 abr. 2015.
PITANGA, A. M. J. Balanceamento de Servidores com Linux. Curso Escola Linux, 2015. Disponivel em: <http://cursos.escolalinux.com.br/curso/balanceamento-de- servidores-com-linux-10-horas?coupon=Curso+Balanceamento+de+Servidores>. Acesso em: 20 mar. 2015.
PLOTZE, R. D. O. Comutação distribuída: o melhor aproveitamento de recursos computacionais. Linguagem Acadêmica, Batatais-SP, p. 93-119, 2012.
REBOUÇAS, D. L. Utilização de redes neurais artificiais para, Natal-RN, 2011.
RIBEIRO, C. F. Sistemas Críticos. Devmedias, 2012. Disponivel em: <http://www.devmedia.com.br/sistemas-criticos/18952>. Acesso em: 17 fev. 2015. ROUSE, M. split brain syndrome. Techtarget, 2014. Disponivel em: <http://whatis.techtarget.com/definition/split-brain-syndrome>. Acesso em: 25 mar. 2015.
SANTOS, F. U. D. Disponibilidade em ambientes de TI empresarial. Blue Solutions,
31 nov. 2013. Disponivel em:
<http://www.bluesolutions.com.br/AltaDisponibilidade/>. Acesso em: 05 abr. 2015. SERVER, L. V. Linux via NAT. Linux Virtual Server, p. http://www.linuxvirtualserver.org/&prev=search, 2011. Disponivel em: <http://transhttp://www.linuxvirtualserver.org/&prev=search>. Acesso em: 11 abr. 2015.
SILVA, D.S. Técnicas de detecção de falhas de escalonamento de tarefas em sistemas embarcados baseados em sistemas operacionais de tempo real, Porto Alegre-RS, 2011.
SILVA, J W. Alta Disponibilidade em Sistema Linux. SlideShare, 2011. Disponivel em: <http://pt.slideshare.net/jbwillinas/artigo-alta-disponibilidade-em-sistema-linux>. Acesso em: 15 Fevereiro 2015.
SMITH, R. W. Aprenda Linux, 302 (Ambientes Mistos): Funções do Samba. IBM, 2011. Disponivel em: <http://www.ibm.com/developerworks/br/library/l-lpic3-310-2/>. Acesso em: 05 abr. 2015.
TANENBAUM. Intrdução. In: TANENBAUM Redes de Computadores. São Paulo- SP: Pearson, 2011. p. 12-15.
TCPDUMP. Documentation. TcpDump, 2010-2015. Disponivel em: <www.tcpdump.org>. Acesso em: 10 maio 2015.
TELECO. SLA O que é. Teleco. Disponivel em:
<http://www.teleco.com.br/tutoriais/tutorialsla/pagina_1.asp>. Acesso em: 13 Fevereiro 2015.
TRAUE, T. G. Um estudo sobre a relação entre processos de engenharia, Santo André-SP, 2012.
TROCKI, J. Mon. Linux Die, 2008. Disponivel em: <http://linux.die.net/man/8/mon>. Acesso em: 29 mar. 2015.
WIRESHARK. User Documetation. Wireshark, 2015. Disponivel em: <www.wireshark.org>. Acesso em: 10 maio 2015.
APÊNDICES
Apêndice A – Exemplo de configuração das ferramentas utilizadas Configurando o Heartbeat
Nessa seção será apresentada a configuração necessária para o funcionamento da ferramenta Heartbeat, que tem a função de monitorar a disponibilidade dos nodes como descrito na seção 2.5.1 Todos os arquivos de configuração do Heartbeat devem ser idênticos em ambos os servidores.
Para a instalação do Heartbeat é usado o comando a seguir.
#apt-get install heartbeat
Após a finalização da instalação é necessário cópiar os arquivos de configuração da área de documentação do Heartbeat, pois no Debian esses arquivos não vêm no diretório de configuração por padrão.
#cd /usr/share/doc/heartbeat
#cp authkeys ha.cf.gz haresources.gz /etc/ha.d #cd /etc/ha.d #gunzip ha.cf.gz
#gunzip haresources.gz
Ao término das cópias dos arquivos será feito a configuração do arquivo authkeys, que é responsável pela autenticação entre os servidores. A Figura 3.1 ilustra o conteúdo no arquivo authkeys, para visualizar o conteúdo utiliza o comando:
#nano /etc/ha.d/authkeys
Figura 3.1: Arquivo de configuração authkeys do Heartbeat
Fonte: Próprios autores. Fonte: Próprios autores.
Feito isso é necessário atribuir permissão de leitura e escrita para o arquivo authkeys utilizando o comando abaixo.
O arquivo principal de configuração do Heartbeat é o ha.cf como descrito na seção 2.5.1, onde é atribuída qual interface será responsável pela comunicação entre os servidores, os diretórios de logs, tempo mínimo para declarar a outra máquina como inativa etc.
Arquivo ha.cf:
Logfile /var/log/ha-log #Caminho do arquivo de Log Logfacility local0 #Caminho do arquivo de Log do node keepalive 1 #Intervalo em segundos entre os pings
deadtime 3 #Intervalo em segundos para declarar uma máquina inativa initdead 20 #Permite inicialização em todos os nodes
udpport 694 #Porta utilizada para checagem de disponibilidade do node bcast eth1
auto_failback on #Volta do servidor primário caso haja falha e depois volte a responder
node node1 #Servidor primário node node2 #Servidor secundário
O haresources como descrito na seção 2.5.1 é o arquivo de configuração, que gerencia os daemons de responsabilidade do Heartbeat, como por exemplo: atribuir um IP virtual para o cluster e ativar os serviços no servidor secundário em caso de falha do servidor primário. Arquivo demonstrado na Figura 3.2.
Os significados dos parâmetros são os seguintes: node1 - Nome da máquina principal;
192.168.1.30 - IP virtual que é gerenciador pelo Heartbet; /24 Máscara de rede de IP de classe C;
eth0 - Interface de rede utilizada para a comunicação do Heartbeat; drbddisk - Utilitário do Heartbeat para gerenciar o DRBD;
r0 - nome do dispositivo do DRBD (configurado no drbd.conf); Filesystem - Utilitário para montagem de partição;
/dev/drbd0 - Nome da unidade do DRBD;
/ha - Nome do local de montagem do disco do DRBD; ext4 - Sistema de arquivos;
samba - Script do init.d para o samba.
Ao término da configuração é preciso reiniciar o serviço do Heartbeat.
#/etc/init.d/heartbeat restart
Assim que o serviço estiver ativo novamente, o IP virtual do cluster de alta disponibilidade atribuído no arquivo /etc/ha.d/haresources, já estará em uso no servidor primário, como ilustra a Figura 3.3
Para realizar um teste, irá ser desligado o servidor primário e conferir se o servidor secundário assumirá o IP virtual. Utilizando o comando:
#shutdown -h now
Como ilustrado na Figura 3.4, o servidor secundário assumiu o IP virtual 192.168.1.30 em poucos segundos.
Figura 3.4: IP virtual em funcionamento no servidor secundário
Nessa seção serão desenvolvidas as configurações do DRBD. O comando a seguir é usado para a instalação do DRBD e deverá ser executado tanto no servidor primário quanto no secundário. Entretanto antes de fazer a instalação será preciso fazer algumas configurações necessárias para que o processo de instalação do DRBD funcione corretamente. Sendo:
Verifique os nomes das máquinas: Dentro do terminal digite o comando #hostname caso queira padronizar digite no terminal. #hostname <nome da máquina> Modifique o conteúdo de /etc/hosts e o deixe igual nos dois nodes.
#echo "127.0.0.1 localhost" > /etc/hosts #echo "192.168.1.10 node1" >> /etc/hosts
#echo "192.168.1.20 node2" >> /etc/hosts
Sincronizando os relógios.#apt-get install ntpdate tzdata #ntpdate a.ntp.br
#hwclock –systohc
Instalando o DRBD e ativando os módulos necessários.#aptitude -y install drbd8-utils #modprobe cn
#modprobe drbd
Editando o arquivo/etc/drbd.d/global_common.conf feito isso é preciso mudar de
#usage-count yes para #usage-count no
Criando o arquivo r0.res na pasta /etc/drbd.d/ e adicionando é possívelFigura 3.5: Arquivo de configuração r0.res #!/bin/bash
resource r0 { protocol C; handlers {
pri-on-incon-degr "echo o > /proc/sysrq-trigger ;halt -f"; pri-lost-after-sb "echo o > /proc/sysrq-trigger ; halt -f"; local-io-error "echo o > /proc/sysrq-trigger ; halt -f"; } startup { degr-wfc-timeout 60; } disk{ on-io-error detach; } net { sndbuf-size 512k; startup { degr-wfc-timeout 60; } disk{ on-io-error detach; } net { sndbuf-size 512k; timeout 60; connect-int 12; ping-int 12; ping-timeout 9; max-buffers 20480; cram-hmac-alg "sha1"; shared-secret "123456"; after-sb-0pri discard-older-primary; after-sb-1pri violently-as0p; after-sb-2pri disconnect; } syncer { rate 100M; al-extents 257;
} on node1 { device /dev/drbd0; disk /dev/sdb1; address 192.168.1.10:7793; } on node2 { device /dev/drbd0; disk /dev/sdb1; address 192.168.1.20:7793; meta-disk internal; } }
Fonte: Próprios autores. Iniciando a configuração.
#drbdadm create-md r0 #modprobe drbd
#drbdadm up r0
Sincronizando os servidores esse processo é feito apenas no servidor primário. O tempo de sincronia vai depender do tamanho dos HDs. Para acompanhar, digite:
#drbdadm -- --overwrite-data-of-peer primary r0
Para visualizar o processo em tempo real utiliza o comando:
#watch cat /proc/drbd
Esperando até completar 100%;
Iniciando o serviço.#/etc/init.d/drbd start
Formatando a partição Esse processo é feito somente no servidor primário;#mkfs.ext4 /dev/drbd0
criando uma pasta para fazer os testes necessários em ambos os servidores.
Será montada a partição (formatada anteriormente) na pasta /ha e será criado um arquivo para efeitos de testes. Tudo isso apenas no servidor primário.
#mount -t ext4 /dev/drbd0 /ha #touch /ha/teste.txt
Será feita a verificação no servidor primário para analisar se a