Home

montagem de um ambiente de cluster usando

1. 75 Figura 32 Disponibilidade do firewall ano de 2007 76 LISTA DE TABELAS Tabela 1 Os quatro principais componentes de um 22 Tabela 2 Medidas de Confiabilidade 33 Tabela 3 Medidas de Disponibilidade 34 Tabela 4 Exemplos de sistemas e suas disponibilidades necess rias 34 Tabela 5 T cnicas de recupera o 44 Tabela 6 Fases da toler ncia a falhas 45 Tabela 7 Resultados dos testes 67 SUMARIO 1 INTRODU O ss pa does Bela Ste oe ale AD he en 16 2 INTRODU O AOS CLUSTERS 18 2 1 O PAPEL DO SOFTWARE LIVRE COMO BASE PARA OS CLUSTERS 18 2 2 PRINC PIOS DE UM CLUSTER 19 2 3 ABSTRA ES DE UM CLUSTER 21 2 3 T N oU Nodo eek ee 21 23 2 ROCUISO E E E aod E Be Rl Re a 22 2 3 3 Depend ncia de Recursos 22 2 3 4 Grupo de Recursos 1 2 23 24 A HIST RIA DOS CLUSTERS 23 2 5 OS DIFERENTES TIPOS DE CLUSTER E SUAS APLICA ES 25 2 5 1 Cl
2. Seite ue Sa oU OS os Soo ON m SSSOSOSSOSSOSAS E a E a 445 E a 4545545 5 455 MoO CCC OCA AWD SONHOS TFA AMO ACO 4 COMO Od AA A O NO aA NN AM ANN ANN aa AN N DEGE GGG Giok 2RR D LGE tc ttt G i i i i tee tee NDA DR VLU Vee 2 440 0 TG a a a a 1 Cnr vr Or Veer UTP Bosco saosaeosasao Tr TLTLITCILITCLUTO T LILOLOLOLITMTU TLITIVILOLOLO pe 0 30 0 1 1 0 5 0 0 50 o State Breakdowns Up 99 8222 146d 10h 46m 31s Down 0 1012 Od 3h 32m 59s Unreachable 0 078 Od 2h 44m 6s Indeterminate 0 0002 Od Oh Om Os Figura 32 Disponibilidade do firewall no ano de 2007 Fonte O Autor V escalabilidade a nova infraestrutura ja foi preparada pensando em agregar novos recur sos entre eles o uso de VoIP voz sobre IP atrav s da Internet para liga es telef nicas entre as unidades da empresa com custo zero 77 7 CONCLUSAO Este trabalhou iniciou apresentando a hist ria do sistema operacional Linux e definindo os clusters e as suas caracter sticas Logo ap s foi abo
3. 31 3 ALTA DISPONIBILIDADE Os avan os alcan ados nos ltimos anos nas reas de hardware e equipamentos para redes as a es por parte do governo como a redu o de taxas tribut rias sobre computadores MANFREDINI 2005 s o exemplos de a es que t m estimulado a queda de pre os e a venda de equipamentos fazendo com que cada vez mais os computadores sejam empregados na realiza o de tarefas cr ticas e que as empresas fiquem cada vez mais dependentes deles Exemplo disso foi a grande preocupa o com o bug do ano 2000 Al m dos gastos financeiros as empresas estavam preocupadas com a perda dos dados e que isso pudesse causar um grande problema a n vel mundial VARGAS 2000 Um sistema de miss o cr tica se falhar pode trazer grandes preju zos empresa Hoje muitos processos dependem dos recursos computacionais para funcionar Se os recursos n o estiverem dispon veis os processos param Na rea de com rcio eletr nico por exemplo dis ponibilidade fundamental pois se um cliente n o conseguir efetuar uma compra ele se dirige ao portal do concorrente pois a facilidade e o conforto proporcionados a ele s o muito grandes VARGAS 2000 Como as falhas n o podem ser evitadas um m todo de garantir a disponibilidade dos servi os mesmo no caso de falha de um componente a redund ncia Neste caso os recursos falhos podem migrar para um equipamento operante Este cap tulo visa explorar os conceitos r
4. 63 5 5 Teste finalizar o daemon do samba nodo prim rio 63 5 6 Teste 4 nodo02 assumindo 65 5 7 Teste 5 finalizar processo do DRBD no nodo ativo 66 5 8 Teste 6 outras verifica es 66 59 CONCLUS O sa pin beware te wis SPE GRE SAS 67 6 ESTUDO DE CASO sis a CE AT eee SEE SRI ww te aces ta 68 6 1 O AMBIENTE DA EMPRESA NA POCA E SUAS NECESSIDADES 68 6 2 PROPOSTA DE MELHORIA 70 6 3 EXECU O DO PROJETO 71 6 4 OS RESULTADOS ALCAN ADOS 74 T CONCEUS O qe Auta he he tee bee 77 GLOSS RIO GI Oe ee 79 REFERENCIAS res o pera Boe eae SRS Mike See Ce eee 81 16 1 INTRODU O As corpora es dependem cada vez mais das aplica es e servi os fornecidos pela rea de tecnologia da informa o para realizar tarefas cr ticas e para que suas opera es processos e neg cios n o parem Em um ambiente ideal os recursos computacionais deveriam estar dispon veis 100 do tempo sem apresentar falhas WEBER 2002 Por m as falhas s o inevit veis PEREIRA 2004 e v rios fatores podem fazer com que um recurso computacional apresente indisponibili dade tais como cat strofes naturais falhas em aplicativos ou p
5. 2 3 3 Depend ncia de Recursos Geralmente um recurso depende de outro para funcionar Por exemplo o servidor web Apache depende de uma placa de rede e de um sistema de arquivos para poder funcionar O sistema de arquivos para poder funcionar precisa de um disco r gido e assim por diante Essa rela o de depend ncia entre os recursos conhecida como rvore de depend ncias e descreve a ordem em que os recursos devem ser inicializados Quando um nodo apresenta uma falha por meio da rvore de depend ncias que ele sabe quais recursos devem ser migrados em conjunto de um nodo para outro VOGELS 1998 A Figura 2 ilustra este exemplo 23 Servidor Apache 192 168 0 1 Armazenamento Figura 2 Depend ncia de recursos em um servidor Apache Fonte O Autor adaptado de Pereira 2004 p 9 2 3 4 Grupo de Recursos Al m da depend ncia de recursos em que mais de um recurso pode ser migrado em conjunto existe a possibilidade de se agrupar recursos de modo que em caso de falha nao apenas um mas 0 grupo todo seja migrado Cabe ao administrador definir que um recurso s pode depender de outro que esteja no mesmo grupo PEREIRA 2004 A Figura 3 mostra o caso 1 em que cada um dos recursos est separado No caso 2 os recursos sistema de arquivos e endere o IP foram agrupados ao Apache ou seja o Apache precisa deles para funcionar foi criado um grupo Apache ao qual os demais recursos est o
6. f inet addr add 192 168 200 203 24 brd 192 168 200 255 dev ethO label etho 0 IPaddr2 INFO sbin ip link set eth up IPaddr2 INFO usr lib heartbeat send arp i 200 r 5 p var run heartbeat rsctmp send arp send arp 192 168 200 203 ethO 192 168 200 203 auto 192 168 200 203 ffffffffffff IPaddr2 INFO IPaddr2 Success ResourceManager info Acquiring resource group nodo0l itflex local drbddisk r0 Filesystem dev drbdO rede ext3 ResourceManager info Running etc ha d resource d drbddisk rO start Filesystem INFO Running status for dev drbd on rede Filesystem INFO rede is unmounted stopped Filesystem INFO Filesystem Resource is stopped ResourceManager info Running etc ha d resource d Filesystem dev drbd rede ext3 start Filesystem INFO Running start for dev drbd on rede kernel EXT3 fs warning maximal mount count reached running e2fsck is recommended Filesystem INFO Filesystem Success ResourceManager info Acquiring resource group nodoBl itflex local smb ResourceManager info Running etc init d smb start smb inicio de smbd succeeded smb inicio de nmbd succeeded heartbeat info all HA resource acquisition completed standby heartbeat info Standby resource acquisition done all heartbeat info remote resource transition completed Figura 25 Forgando os recursos a migrarem para outro nodo Fonte O Autor 5 4 Teste 2 nodos prim rio e secund rio no ar simult neamente N
7. 14 O arquivo de configura o etc ha d haresources Fonte O Autor 51 A sintaxe do arquivo simples No lado esquerdo deve ser configurado um nome v lido para o nodo ou seja necess rio que um endere o IP responda por este nome Para isso pode ser configurado um servi o de DNS ou usado o arquivo etc hosts Este nome n o precisa necessariamente ser o mesmo no qual s o disponibilizados os servi os e precisa ser v lido somente para o cluster os usu rios n o precisam ter acesso a ele Por isso e por ser mais simples a op o do arquivo etc hosts a mais usada Do lado direito configurado o recurso que ele est disponibilizando e que pode ser mi grado para outro nodo no caso de falha que neste exemplo s o o endere o IP virtual a parti o do DRBD e o servidor Samba O Heartbeat segue a ordem do arquivo etc hd d haresources para inicializar os servi os ou seja quem estiver na primeira linha iniciado primeiro quem es tiver na segunda linha iniciado em seguida e assim por diante A Interface para Programa o de Aplica es Application Programing Interface API do Heartbeat foi criada seguindo o padr o Base Padr o do Linux Linux Standard Base LSB Isso permite que ele seja usado em distribui es Linux que sigam este padr o sem problemas al m de permitir que sejam facilmente criados plugins para trabalhar em conjunto com ele Segundo o padr o LSB os servi os disponibilizados pel
8. 5Mbps do enlace para uso com o sistema TCtran b classe Il utilizando os 25 512Kbps restantes para tr fego de emails FTP e demais aplica es O sistema operacional Linux permite que este controle seja din mico ou seja se uma classe n o estiver fazendo uso de toda largura de banda reservada a ela a banda que sobra pode ser emprestada para uma classe vizinha 74 A terceira parte do projeto tratou da instala o do firewall de alta disponibilidade fw levatudo net Neste caso foi utilizado somente o aplicativo Heartbeat pois as informa es nos discos mudam com pouca frequ ncia n o sendo necess ria a utiliza o do DRBD O sincronismo do sistema de arquivos feito semanalmente atrav s do aplicativo rsync A instala o do nodo backup fw2 levatudo net foi feita atrav s de um clone do HD do firewall fw1 levatudo net que j estava no ar e foi usado como nodo prim rio A clonagem foi feita atrav s do aplicativo rsync Conclu da esta tarefa foram ajustados os par metros de configura o tais como endere amento IP e nome do servidor Com os dois nodos no ar foi feita a instala o e configura o do Heartbeat Os recursos sob controle do Heartbeat s o um script que avisa os administradores por email caso ocorra alguma falha e os endere os de IP virtual firewall e terminal server que s o IPs v lidos Existe um NAT para o IP inv lido dos servidores que est o na DMZ Cada nodo possui quat
9. 8425 with signal 15 Mar 31 16 11 51 info Core process 8425 exited 3 remaining Mar 31 16 11 51 info Core process 8424 exited 2 remaining Mar 31 16 11 51 info Core process 8426 exited 1 remaining 31 16 11 51 info nodo01 itflex local Heartbeat shutdown complete Mar 31 16 11 51 info Heartbeat restart triggered Mar 31 16 11 51 info Restarting heartbeat Mar 31 16 11 51 info Performing heartbeat restart exec Mar 31 16 13 52 WARN Logging daemon is disabled enabling logging daemon is recommended Mar 31 16 13 52 info HAHAHAHAHAHA O Mar 31 16 13 52 Configuration validated Starting heartbeat 2 0 7 16 13 52 heartbeat version 2 0 7 Figura 26 Dois nodos ativos ao mesmo tempo Fonte O Autor Mar 31 16 13 53 info Heartbeat generation 5 Mar 31 16 13 53 info G main add TriggerHandler Added signal manual handler Mar 31 16 13 53 info Removing var run heartbeat rsctmp failed recreating Mar 31 16 13 53 info glib UDP Broadcast heartbeat started on port 694 694 interface eth0 Mar 31 16 13 53 info glib UDP Broadcast heartbeat closed on port 694 interface eth0 Status 1 Mar 31 16 13 53 info G_main_add_SignalHandler Added signal handler for signal 17 Mar 31 16 13 53 info Local status now set to up Mar 31 16 13 54 info Link nodo01 itflex local eth0 up Mar 31 16 13 56 info Link nodo02 itflex local ethO up Mar 31 16 13 56 info Status update for node nodo02 itflex local status up
10. Alta Disponibilidade Disponibilidade Basica Continua Figura 8 Dominios de disponibilidade Fonte O Autor adaptado de Resnick 1996 p 11 3 3 5 Replica o passiva e ativa Os clusters permitem dois tipos de replica o de estados de processos replica o ativa e replica o passiva a replica o ativa RA o estado de todos os processos s o compartilhados em tempo real entre nodos que comp e o cluster BRASILEIRO 2000 Eles s o tamb m coordenados afim de que as transa es ocorram de maneira sincronizada entre as r plicas PEREIRA 2004 b replica o passiva RP neste caso os processos n o s o sincronizados em tempo real Geralmente a RP empregada em ambientes onde n o se deseja que os clusters sejam sincronizados por completo ou em ambientes onde o custo de implementa o da RA se torna muito alto 40 3 4 DEFEITOS ERROS E FALHAS Ao usar um sistema espera se que ele funcione de acordo com sua especifica o O defeito failure ocorre quando o funcionamento foge dessa especifica o PEREIRA 2004 Um erro o que pode levar o sistema ao estado de defeito ALMEIDA 2001 O termo falha usado para definir a causa f sica ou l gica que conduz ao erro WEBER 2002 ou seja as defici ncias no sistema que podem levar o sistema ao estado de erro Por ser uma propriedade do estado do sistema o erro pode ser observado e avaliado Por outro lado o defeito n o uma propriedade d
11. Detec o de erros 3 5 2 Confinamento de estragos e avalia o 3 5 3 Recupera o de erros 3 5 4 Tratamento da falha e servi os continuados 3 6 CONCLUS O lt lt gos 20 SORA PARTES SAE Cega Pe GRU ie 4 FERRAMENTAS PARA CRIA O DE UM AMBIENTE DE ALTA DISPONIBILIDADE 4 1 COMO SURGIU O PROJETO LINUX HA 4 2 AS CARACTER STICAS DO HEARTBEAT 4 2 1 A estrutura do aplicativo 4 2 2 Outras caracter sticas do Heartbeat 4 3 VIS O GERAL SOBRE O DRBD 4 3 1 A estrutura do aplicativo 4 3 2 As topologias de armazenamento 4 3 3 Os protocolos utilizados pelo DRBD 4 3 4 O sincronismo quando um nodo entra no cluster 4 A CONCLUS O etc eee Bie Ke ade 5 AVALIA O DAS FERRAMENTAS DE ALTA DISPONIBILIDADE 5 1 5 1 1 A configura o dos aplicativos 59 5 2 realiza o dos testes 60 5 3 Teste 1 for ando nodo01 a entrar no modo de espera 62 5 4 Teste 2 nodos prim rio e secund rio no ar simult neamente
12. Mar 31 16 13 56 info Running etc ha d rc d status status Mar 31 16 13 57 info Comm_now_up updating status to active Mar 31 16 13 57 info Local status now set to active Mar 31 16 13 57 WARN G_CH_dispatch_int Dispatch function for read child took too long to execute 220 ms gt 50 ms GSource 0x80f9c58 Mar 31 16 13 58 info Status update for node nodo02 itflex local status active Mar 31 16 13 58 info Running etc ha d rc d status status Mar 31 16 14 09 info remote resource transition completed Mar 31 16 14 09 info Initial resource acquisition complete T RESOURCES us Mar 31 16 14 09 INFO IPaddr2 Resource is stopped Mar 31 16 14 09 info Local Resource acquisition completed Mar 31 16 14 09 info Running etc ha d rc d ip request resp ip request resp Mar 31 16 14 09 info Received ip request resp IPaddr2 192 168 200 203 24 eth0 0 OK yes Mar 31 16 14 09 info Acquiring resource group nodo01 itflex local IPaddr2 192 168 200 203 24 eth0 0 Mar 31 16 14 10 INFO IPaddr2 Resource is stopped Mar 31 16 14 10 info Running etc ha d resource d IPaddr2 192 168 200 203 24 eth0 0 start Mar 31 16 14 10 INFO sbin ip f inet addr add 192 168 200 203 24 brd 192 168 200 255 dev eth0 label eth0 0 Mar 31 16 14 10 INFO sbin ip link set eth0 up Mar 31 16 14 10 INFO usr lib heartbeat send i 200 r 5 p var run heartbeat rsctmp send arp send arp 192 168 200 203 etho 192 168 200 203 auto 192 168 200 203 ffffffffffff Ma
13. Rio de Janeiro RJ Surgiram em 1994 com o objetivo de apoiar o avan o de pesquisas nas reas de ci ncia e tecnologia no pa s Para isso disponibilizam aos usu rios laborat rios com equi pamentos de alto desempenho recursos de hardware e aplicativos al m do suporte t cnico CENAPAD 2007 Tamb m a Petrobr s utiliza clusters de alto desempenho nas plataformas 26 para executar c lculos relacionados extra o de petr leo FRANCO 2004 e simula o nu m rica em reservat rios de petr leo SCHIOZER 1997 2 5 2 Clusters de alta disponibilidade HAC Os Clusters de alta disponibilidade High Availability Clusters HAC tem como objetivo manter um ou mais servi os no ar a maior parte do tempo poss vel e de forma segura PI TANGA 2002 Os recursos t m que estar sempre ou quase sempre dispon veis para atender as requisi es dos clientes ou seja t m de estar acess veis por um per odo de tempo muito pr ximo a 100 PEREIRA 2004 A bilbiografia mostra c lculos de disponibilidade tomando como base um ano ou seja tempo de disponibilidade de um servi o durante o per odo de um ano de um valor pr ximo a 100 que pode variar de 99 a 99 999999999 de acordo com a aplica o Faustino 2006 p 19 diz que Manter apenas um computador realizando uma tarefa im portante n o garantia segura de que o servi o vai estar sempre dispon vel pois problemas de hardware ou aplica tivos podem causar
14. a interrup o do servi o Assim um dos requisitos para alcan ar alta disponibilidade a elimina o dos pontos nicos de falha A autora Weber 2002 p 29 afirma que Usu rios que inicialmente se mostram satisfeitos em contar apenas com a simples automa o de servi os logo pas sam a desejar que esses servi os sejam prestados corre tamente e sem interrup es Sistemas tolerantes a falhas s o caros e portanto empregados apenas naquelas situa es em que sua n o utiliza o acarretaria preju zos irre cuper veis A autora tamb m cita algumas reas em que os clusters de alta disponibilidade s o empregados aplica es cr ticas de tempo real como medicina controle de processos e transportes a reos Il aplica es seguras de tempo real como transportes urbanos HI aplica es em sistemas de tempo real de longo per odo de dura o sem manuten o como viagens espaciais ou sat lites IV aplica es t cnicas como telefonia e telecomunica es 27 V aplica es comerciais de alta disponibilidade como sistemas de transa o e servido res de rede WEBER 2002 No Brasil empresas como Telecomunica es Brasileiras S A TELEBRAS e Instituto Nacional de Pesquisas Espaciais INPE t m trabalhado na pesquisa de solu es tolerantes a falhas para o sistema de telefonia e espacial respectivamente Uma medida muito usada atualmente a do n mero de noves de disponibilid
15. acompanhamento sobre o que os usu rios estavam acessando Os emails da empresa estavam hospedados em um provedor ou seja internamente n o se tinha controle sobre o que entrava e saia de emails ent o se algum funcion rio estivesse enviando informa es da empresa para fora n o era pos s vel saber quem estava mandando nem que tipo de informa o estava saindo Al m disso alguns clientes reclamavam que n o recebiam os emails de acompanhamento de embarque de mercadoria O parque da matriz conta com cerca de 40 esta es de trabalho e n o existia nenhum controle de banda Qualidade de Servi o Quality of service QoS no roteador nem no firewall Com todo esse tr fego o enlace de Internet tamb m n o era mais suficiente A Figura 30 ilustra melhor o cen rio da empresa na poca Ss Campinas aa Filiais Matriz Roteador Firewall lt Curitiba Servidor de Banco Dados Florianopolis Arquivos de troca Figura 30 O ambiente da empresa antes Fonte O Autor Al m dos problemas apresentados a Levatudo Log stica Ltda precisava disponibilizar alguns servi os aos seus clientes por m com essa infraestrutura n o era poss vel I espa o do cliente a transportadora precisava disponibilizar no seu portal de Internet um espa o dedicado aos clientes onde pudessem verificar faturas solicitar coletas consultar 70 prazos de entrega emitir segunda vi
16. agrupados 2 4 A HIST RIA DOS CLUSTERS Os clusters surgiram no momento em que uma tarefa n o podia ser executada por um nico computador e quando passaram a executar tarefas que exigiam um n vel maior de con fiabilidade o que um nico computador n o poderia garantir A data exata do surgimento dos 24 CASO 1 CASO 2 APACHE Sistema de Arquivos Sistema de Arquivos Endere o IP Endere o IP Figura 3 Exemplo agrupamento de recursos em grupo Fonte O Autor primeiros clusters desconhecida mas foi no final da d cada de 50 e inicio da d cada de 60 MARCO 2006 Em 1967 em um artigo publicado por Gene Amdahl da IBM apresentada a Lei de Amdahl por meio da qual descrito matematicamente o ganho de velocidade ao se paralelizar tarefas seriais AMDAHL 1967 Os clusters atuais tem uma rela o forte com a evolu o das redes de computadores o desenvolvimento do protocolo Protocolo de Controle de Transmiss o Protocolo de Internet Transmission Control Protocol Internet Protocol TCP IP e do sistema operacional Unix na d cada de 70 O conceito de redes baseadas na comuta o de pacotes surgiu em 1962 e foi criado pela RAND Corporation Usando o conceito criado pela RAND a rede ARPANET surgiu em 1969 e foi um dos primeiros clusters criados usando hardware comum Ela foi usada para criar a infraestrutura de interliga o de quatro centros de computa o nos Estados Unidos Por volta d
17. ambos os nodos O fato de o samba parar foi uma falha de servi o a qual o Heartbeat n o est apto a tratar Neste caso se estivesse sendo utilizado um watchdog ele poderia carregar novamente o servi o do samba e tudo voltaria a funcionar normalmente 5 6 Teste 4 nodo02 assumindo O nodo01 estava ar e o nodo02 estava desligado O nodo02 foi ligado e logo em seguida o nodo01 falhou fazendo com que o nodo02 assumisse os servi os Como nodo01 falhou logo ap s o nodo02 entrar ar o tempo n o foi suficiente para que o sincronismo dos dados pudesse ser completado As parti es ficaram inconsistentes Na situa o o nodo02 mostra os arquivos corretramente Por m quando o nodo01 assumiu novamente mostrou os dados que estavam consistentes antes dele falhar Este comportamento conhecido como recupera o por retorno citado na se o 3 5 3 do cap tulo 3 A B E smb 192 168 200 203 publico smb 192 168 200 203 publico Nome w teste 1 Jarquivo01 rmvb arquivo02 mpg amp larquivoO3 mpg Figura 28 Inconsist ncia nos dados Fonte O Autor Neste caso o Heartbeat n o sincroniza automaticamente as parti es sendo necess ria uma interven o para sincroniza o manual das parti es root nodo02 cat proc drbd version 8 0 1 api 86 proto 86 SVN Revision 2784 build by root nodo02 itflex local 2007
18. das parti es no momento em que ambos os nodos entraram no ar no vamente depois que a situa o ficou estabilizada o DRBD poderia ter sincronizado as parti es automaticamente pois o nodo01 n o mostrou os arquivos que eram esperados De acordo com o que foi apresentado na tabela 6 do cap tulo 3 a recupera o se deu por meio de um retorno ao ltimo estado de consist ncia backward error recovery ou seja este foi o comportamento do aplicativo Com isso foi necess rio for ar o sincronismo manualmente para que as mesmas informa es ficassem sincronizadas novamente Levando em considera o que o DRBD pode ser utilizado nos mais diversos ambientes em que talvez o sicronismo autom tico n o seja requerido o aplicativo poderia conter uma op o no seu arquivo de configura o em que o administrador pudesse escolher qual o comportamento esperado numa situa o dessas queda de servi os como se trata de alta disponibilidade seria interessante que o Heart beat tivesse habilidade de monitorar os recuros locais pois a falha em um servi o n o significa que todo o servidor esteja comprometido Atualmente necess rio o uso de um aplicativo em paralelo que monitore os recursos e execute a es pr determinadas caso ocorram problemas 68 6 ESTUDO DE CASO Este capitulo apresenta o estudo de caso de uma transportadora onde foi instalado um cluster de alta disponibilidade utilizando as ferramentas abordadas no c
19. email para a matriz O processo de importa o dos arquivos era feito manual mente estava sujeito a erros e frequentemente eram encontradas inconsist ncias no sistema Quando as filiais precisavam de algum relat rio mais espec fico era feita uma solicita o matriz que gerava o relat rio e disponibilizava via email Os servidores de banco de dados eram esta es de trabalho que foram montadas usando hardware simples n o indicadas para esta tarefa Era comum estes servidores apresen tarem problemas como travamento ou falha em algum componente de hardware Isso gerava um transtorno muito grande que atrasava a sa da de caminh es Algumas vezes at que o sistema entrasse no ar novamente o processo de libera o da carga era feito manualmente e 69 depois lan ado no sistema o que acabava por atrasar todo o processo A Levatudo Log stica Ltda estava sujeita a preju zos financeiros pois tem contratos com grandes empresas da regi o e a carga tem de ser entregue dentro do prazo Quanto a infraestrutura de comunica o a Levatudo Log stica Ltda utilizava um enlace de Internet ADSL com IP fixo de 256Kbps O firewall fazia algumas prote es sobre o tr fego que vinha no sentido da Internet em dire o a empresa N o existia nenhum controle sobre o que saia da rede pois as portas eram todas liberadas No proxy os controles n o eram atualiza dos pois n o existia nenhum relat rio atrav s do qual se pudesse fazer um
20. informa es no nodo02 192 168 200 201 45372 gt 192 168 200 202 drbd 297 305 8 ack 1568 win 2252 lt nop nop timestamp 363910 363546 gt 192 168 200 202 drbd gt 192 168 200 201 45372 ack 305 win 1460 lt nop nop timestamp 363557 363910 gt 192 168 200 201 45372 gt 192 168 200 202 drbd 305 313 8 ack 1568 win 2252 lt nop nop timestamp 366410 363557 gt 192 168 200 202 drbd gt 192 168 200 201 45372 ack 313 win 1460 lt nop nop timestamp 366045 366410 gt IP 192 168 200 202 drbd gt 192 168 200 201 45372 P 1568 1576 8 ack 313 win 1460 lt nop nop timestamp 366045 366410 gt 192 168 200 201 45372 gt 192 168 200 202 drbd ack 1576 win 2252 lt timestamp 366420 366045 gt Figura 23 Pacotes de replica o das informa es Fonte O Autor Neste ambiente de testes foi utilizado o protocolo C que envia pacotes de confirma o depois que os dados foram escritos no nodo secund rio conforme pode ser observado na Figura 24 192 168 200 202 46769 192 168 200 202 46769 192 168 200 201 drbd ack 809768 win 16652 lt nop nop timestamp 34944957 1048976457 gt 192 168 200 201 drbd ack 812440 win 16652 lt nop nop timestamp 34944957 1048976457 gt 192 168 200 202 46769 192 168 200 202 46769 192 168 200 201 drbd 818008 win 16652 lt nop nop timestamp 34944957 1048976457 gt gt gt 192 168 200 202 46769 gt 192 168 200 201 d
21. o De in cio a Levatudo Log stica Ltda disponibilizou dois novos servidores que j haviam sido adquiridos 2 servidores HP Proliant 310L Processador Intel Xeon 3 2GHz HT 2MB cache 4GB mem ria RAM 2 HDs SCSi 73 4GB 15k RPM RAID5 Por serem equipamentos de alto desempenho esses servidores foram alocados para tarefas que exigiam mais recursos de hardware Foi solicitado solicitado que a transportadora disponibilizasse mais dois servidores com configura o mais simples para serem usados como servidor firewall e servidor de email 71 1 servidor Intel Processador Intel Celeron 2 4GHz 512MB mem ria RAM 2 HDs IDE 80GB RAID1 1 servidor Intel Processador Pentium IV 3 0 HT 512MB mem ria RAM 2 HDs IDE 80GB RAID1 Foi elaborada uma proposta baseada em quatro etapas principais reestrutura o do CPD da matriz contrata o de novos enlaces de Internet instala o do cluster de firewall e melhorias na infraestrutura de comunica o das filiais 6 3 EXECU O DO PROJETO Com a proposta aprovada pelo cliente iniciou se a primeira etapa do projeto que tratou da reestrutura o dos servidores no CPD da matriz a firewall Linux esse foi um dos pontos mais importantes do projeto A empresa preci sava centralizar seus sistemas de gest o de modo que as filiais tamb m tivessem acesso Uma das op es mais comum e financeiramente vi vel foi atrav s da disponibiliza o em u
22. o iniciar novamente um servi o caso ele fique indispon vel Um dos fatores mais importantes que os clusters de alta disponibilidade oferecem em rela o aos demais o tempo de recupera o de falhas MTTR Para um clusters de alta disponibilidade o MTTR significativamente influenciado pelo tempo de detec o de falha de um nodo membro do clusters A maioria dos clusters de alta disponibilidade detectam falhas entre 10 e 60 segundos O Heartbeat pode ser configurado para detectar falhas em menos de um segundo Este tempo cr tico para certas aplica es como na rea de telefonia por exemplo Por fim o Heartbeat oferece suporte b sico ao OCF a partir da vers o 2 0 do Heartbeat que foi constru da baseando se na API do OCF 53 Para as futuras vers es est o previstas melhorias na documenta o Apesar dela ser bastante completa seu entendimento e a decis o de como utilizar o aplicativo em alguns casos um pouco complicado A id ia disponibilizar uma documenta o mais clara e com um aspecto mais profissional Al m disso o aplicativo pretende suportar novas m dias de comunica o Atualmente as mensagens de controle do Heartbeat usam a comunica o Ethernet ou serial As novas vers es pretendem usar novos meios de comunica o como USB por exemplo 4 3 VIS O GERAL SOBRE O DRBD O Dispositivo de bloco de armazenamento distribu do Distributed Replicated Block De vice DRBD foi criado especialm
23. o logicamente agrupados e assim s o vistos como um recurso nico pelo usu rios O estado dos processos conhecido por todos os nodos do clusters Ap s uma falha os usu rios s o desconectados do nodo defeituoso mas n o observam erro algum 38 pois os recursos continuam sendo oferecidos pelos nodos restantes e dessa maneira o trabalho continua podendo ser feito ou seja a recupera o instant nea e n o h nenhuma parada no funcionamento do sistema 3 3 3 Disponibilidade cont nua continous availability CA Os sistemas de alta disponibilidade somente mascaram as paradas n o planejadas A disponibilidade cont nua trata tamb m as paradas planejadas dos servi os Este tipo de modelo deve ser exclusivamente HS RA para qualquer tipo de parada Para compreender melhor este problema a Figura 7 apresenta um cen rio com dois nodos em que ambos precisam passar por uma atualiza o de aplicativo Inicialmente um processo igualmente replicado entre os dois nodos Para que seja feita a atualiza o o nodo 2 retirado de servi o e recolocado com a vers o do aplicativo atualizada vers o B Quando ele entra no ar novamente absorve o estado de processamento do nodo 1 com a vers o A O nodo 1 ent o retirado de servi o e atualizado tamb m Finalmente o sistema entra no ar com a vers o B instalada nos dois nodos Para que essa atualiza o seja poss vel tanto a vers o A quanto a vers o B t m que ser suf
24. odos de opera o incorreta n o s o toler veis 3 2 2 Disponibilidade A disponibilidade tamb m uma medida de probabilidade dada pela fun o A t que representa a probabilidade de um sistema operar corretamente num instante t PEREIRA 36 2004 Disponibilidade o atributo mais usado e desejado em sistemas de miss o cr tica e n o pode ser confundida com confiabilidade Um sistema pode apresentar v rios noves de dis ponibilidade mesmo estando fora do ar em alguns momentos enquanto est sendo reparado desde que os per odos sejam curtos e n o venham a comprometer a qualidade do servi o tempo m dio entre a ocorr ncia de falhas to 4 t funcionamento 4 funcionamento funcionamento reparo reparo Figura 6 Alternancia entre os periodos de funcionamento e reparo Fonte Weber 2002 p 12 3 2 3 Seguran a Por seguran a entende se a capacidade de um sistema se comportar sem falhas ou seja operar dentro da sua especifica o e quando deixar de funcionar n o provocar danos aos sistemas que dele dependem PEREIRA 2004 Tomando como exemplo o caso da ponte a garantia de que um ve culo possa fazer a travessia do rio sem que ocorra algum problema e que quando a ponte for elevada os ve culos que dela dependem para fazer a travessia n o sejam comprometidos 3 3 CLASSIFICA ES DOS CLUSTERS DE ALTA DISPONIBILIDADE O autor RESNICK 1996 apresenta uma divis o quanto aos n ve
25. que s o fundamentais estado operacional no in cio do per odo especifica o condi es definidas e per odo de funcionamento estado operacional no in cio do per odo uma premissa b sica pois n o poss vel falar de confiabilidade em sistemas que j partem operando com defeito especifica o para saber se um sistema confi vel ou n o necess rio que se tenha uma especifica o de como ele deve funcionar Caso contr rio n o poss vel saber se o sistema confi vel ou n o Tomando novamente o caso da ponte como exemplo ela deve apresentar uma especifica o de quantas toneladas de peso suporta afim de evitar que um caminh o com uma carga muito pesada tente fazer a travessia a e ponte venha abaixo condi es definidas as condi es como temperatura do ambiente ou n vel de umidade do ar devem ser conhecidas afim de que o sistema funcione de maneira adequada per odo de funcionamento o tempo em que o sistema vai estar no ar e funcional deve ser conhecido No caso da ponte supondo que ela seja elevadi a e possa ser usada somente das 6hs da manh at as 18hs Dever ser especificado ent o que no per odo das 18hs at as 6hs da manh ela estar indispon vel n o por ter ocorrido algum problema mas por quest es relacionadas a especifica o A confiabilidade a medida mais usada em sistema cr ticos nos quais o reparo im poss vel ou sistemas em que curtos per
26. rio do Desenvolvimento Dispon vel em lt http www desenvolvimento gov br sitio ascom noticia php cd noticia 6454 gt Acesso em 18 mar 2007 MARCO L M d Computa o de Alto Desempenho Clusters Artigo publicado pela Unicamp Campinas 2006 82 MISAGHI M Introdu o a Ger ncia de Redes Joinville Notas de aula utilizadas no IST 2006 MUSSI E e a Guia de Estrutura o e Administra o do Ambiente de Cluster e Grid Bras lia Artigo publicado pelo Minist rio do Planejamento 2007 NEMETH E e a Manual Completo do Linux Guia do Administrador S o Paulo Makron Books 2004 OYAMADA M S e a Alta disponibilidade utilizando sistemas Linux Cascavel Artigo publicado pela UNIOESTE 2003 PARKER P M Definition Cluster 2007 Webster s Online Dictionary Dispon vel em lt http www websters online dictionary org definition cluster gt Acesso em 08 maio 2007 PEREIRA N A Servi os de pertin ncia para clusters de alta disponibilidade S o Paulo Disserta o de mestrado apresentada na USP 2004 PITANGA M Construindo Supercomputadores com Linux Rio de Jaineiro Brasport 2002 REISNER P DRBD Wien Artigo publicado pela Linbit 2002 REISNER P Rapid resynchronization for replicated storage Activity logging for DRBD Wien Artigo publicado pela Linbit 2004 RESNICK R I A Modern Taxonomy of High Availability 1996 General Concepts Dispon vel em lt http www generalconce
27. se um determinado valor est dentro de um intervalo e verifica es de diagn sticos neste caso o sistema usa algumas verifica es em seus componentes para determinar se ele est funcionando corretamente A partir do conhecimento pr vio de certos valores de entrada e respectivos valores de sa da corretos os valores s o aplicados ao componente e e a sa da comparada com os resultados corretos 3 5 2 Confinamento de estragos e avalia o Se um sistema n o estiver sendo monitorado constantemente haver um intervalo de tempo entre a ocorr ncia da falha e a detec o do erro Durante este tempo o erro pode se propagar aos demais componentes do sistema Por isso antes de tomar medidas corretivas importante que seja verificado com detalhes qual o estado do sistema que est compromentido ou seja quais partes foram danificadas o que ocorreu com elas e qual a causa 3 5 3 Recupera o de erros Assim que o erro for detectado e os detalhes citados no item anterior forem conhecidos necess rio remover o erro do sistema Isso pode ser feito de duas maneiras a recupera o por retorno backward recovery neste modelo o sistema retornado a um estado anterior o qual se espera que esteja livre de erros Para que isso possa ocorrer existe um reposit rio est vel onde peri dicamente s o criados pontos de controle checkpoints Quando um erro detectado no sistema ele sofre um retorno rollback para o checkpoint
28. todos que n o foram mencionados mas de alguma forma colaboraram com o de senvolvimento deste trabalho O imposs vel quest o de tempo Alberto Satiel RESUMO O agrupamento de dois ou mais servidores de modo que possa ser visto como um Unico recurso definido como cluster Essa tecnologia permite que se consiga por exemplo alto desempenho balanceamento de carga ou alta disponibilidade em uma aplica o Este trabalho apresenta os principais tipos de clusters existentes hoje no mercado e em que situa es podem ser utilizados aboradada tamb m a alta disponibilidade apresentando as classifica es e como se obt la Ao final montado um ambiente de testes onde s o utilizadas as ferramentas de alta disponi bilidade presentes no sistema operacional Linux e tamb m apresentado o estudo da caso de uma transportadora onde foi criado um ambiente de comunica o seguindo os princ pios de alta disponibilidade Palavras chave Agrupamento Disponibilidade Falhas Cluster ABSTRACT The grouping of the two or most servers in way that can be seen as an only resource is defi ned as cluster This technology allows to get for example high performance load balancing or high availability in an application This paper presents the main types of existing clusters in the market today and where situations each type of cluster can be used High availability is also ci ted presenting the classifications and how to get high availab
29. 03 31 14 18 18 0 cs Connected st Primary Secondary ld Consistent ns 92968 nr 0 dw 72488 dr 169192401 al 0 bm 4 10 0 pe 0 ua 0 ap 0 66 5 7 Teste 5 finalizar processo do DRBD no nodo ativo Este teste consiste em finalizar o processo do DRBD no nodo ativo atrav s do comando killall 9 drbd0_worker ou atrav s do comando service drbd stop e tentar descarre gar o m dulo do kernel com o aplicativo sendo usado Croot nodo02 logl killall 9 drbdO_worker root nodo02 logl killall 9 drbdO_worker root nodo02 logl killall 9 drbd0_worker root nodoOZ logl killall 9 drbdO_worker root nodo02 logl killall 9 drbdO_worker root nodo02 logl killall 9 drbd0_worker root nodoOZ logl killall 9 drbd0_worker root nodoOZ logl killall 9 drbd0_worker root nodo02 logl killall 9 drbd0_worker root nodo02 logl killall 9 drbdO_worker root nodo02 logl killall 9 drbdO_worker root nodoOZ 109 1 killall 9 drbdO worker root nodo02 logl ps aux grep drbd 0 root 4111 0 0 0 0 07 S 13 01 0 01 drbd0_worker root 4125 0 0 0 0 0 07 13 01 0 07 drbdO_receiver root 4713 0 0 0 0 0 07 S 13 01 0 01 drbd0_asender root 16049 0 0 0 0 3948 604 pts 0 R 15 46 0 00 grep drbd root nodo02 logl service drbd stop Stopping all DRBD resourcesState change failed 12 Device is held open by someone Command sbin drbdsetup dev drbdO down terminated with exit code 11 drbdsetup exited with code 11 ERROR Module drbd is in use
30. 177 s1 Roteador GVT 192 168 253 1 24 etho WAN CLUSTER BRT eth0 2 200 100 20 182 29 fw levatudo net vpn levatudo net l eth1 WAN CLUSTER GVT 192 168 253 254 24 I eth0 0 200 100 20 180 29 gvi Jevatudo net eth0 1 200 100 20 181 29 WAN WAN eth0 200 100 20 179 29 eth0 200 100 20 178 29 fw1 levatudo net fw2 levatudo net pee DMZ eth2 172 16 0 254 24 FIREWALL CLUSTER FW1 FW2 eth3 192 168 1 253 24 eth3 192 168 1 252 24 LAN Figura 31 Ambiente do cluster Fonte O Autor seguran a a nova estrutura proporciona uma maior confiabilidade nos dados disponibili zados pelo sistema uma vez que as inforam es s o gravadas e consultadas no mesmo local A VPN utilizando recursos de criptografia permite a comunica o segura das filiais com a matriz atrav s de uma rede insegura que a Internet Al m disso o novo firewall proporciona um forte controle sobre o tr fego que entra e sai da rede da empresa produtividade a nova estrutura proporcionou de modo geral uma maior produtividade na transportadora Uma vez que as informa es est o centralizadas os processos que envolvem a matriz e as filiais correm de maneira mais r pida O portal do cliente disponi biliza muitos recursos atrav s dos quais o pr prio cliente pode interagir com a empresa poupando tempo e aloca o de colaboradores internos disponibilidade o firewall cluster visa garanti
31. GVT mais simples oferencendo uma garantia menor de banda e um prazo de reparo maior Foi contratado com o objetivo principal de prover redund ncia de comunica o em situa es em que o enlace principal estiver indispon vel Ambos os enlace foram ligados no firewall e utilizam um recurso do sistema operacio nal Linux conhecido como policy routing roteamento por pol tica disponibilizado pelo pacote TProute2 que permite escolher quais servi os far o uso de qual enlace Foram definidas tr s situa es I opera o normal dois enlaces funcionando Brasil Telecom dedicado ao TCtran e servi dor de correio eletr nico GVT dedicado a navega o Il enlace da Brasil Telecom fora do ar todo o tr fego direcionado para o enlace da GVT ou seja todos os servi os passam a ser disponibilizados neste enlace Al m das regras de policy routing os apontamentos de DNS tamb m s o alterados e em 3 minutos passam a apontar para o IP da GVT lll enlace GVT fora do ar o tr fego de navega o passa tamb m para o enlace da Brasil Telecom Ap s a ativa o de ambos os enlaces foi feita a configura o do QoS no firewall Foi necess rio a apli o de patches adi o de uma pequena parte de c digo fonte ao kernel do sistema operacional Linux e ao pacote iptables que agregaram suporte ao Qos tanto sobre o tr fego de entrada quanto o de sa da O enlace foi dividido em duas classes a classe 1 com reserva de 75 1
32. PC Clusters de alto desempenho High Performance Clusters INPE Instituto Nacional de Pesquisas Espaciais LBC Clusters de balanceamento de carga Load Balance Clusters LINUX HA Linux High Availability LSB Base Padr o do Linux Linux Standard Base MIT Instituto de Tecnologia de Massachusetts Massachusetts Institute of Technology NIST Instituto Nacional de Padr es e Tecnologia dos Estados Unidos National Institute of Standards and Technology OCF Padr o de Cluster Aberto Open Cluster Framework OCFS2 Sistema de Arquivos Oracle vers o 2 Oracle Cluster File System version 2 PETROBRAS Petr leo Brasileiro S A QoS Qualidade de Servi o Quality of service 80 SPOF Ponto Unico de Falha Single Point of Failures SSH Secure Shell STONITH Atire na Cabega do Outro nodo Shot The Other Node In The Head TCP IP Protocolo de Controle de Transmissao Protocolo de Internet Transmission Control Pro tocol Internet Protocol TELEBRAS Telecomunica es Brasileiras S A TI Tecnologia da Informa o VPN Rede Virtual Privada Virtual Private Network WAP Protocolo de Aplica es sem Fio Wireless Application Protocol 81 REFERENCIAS ABREU H O e a Construindo cluser beowulf com software livre Manaus Monografia apresentada na UNAMA 2004 ALMEIDA L Entraves a Dependabilidade Aveiro Monografia apresentada na Universidade de Aveiro 2001 AMDAHL G M Validity of the single processor approach to achieving large sc
33. SOCIEDADE EDUCACIONAL DE SANTA CATARINA SOCIESC INSTITUTO SUPERIOR TUPY IST MARCELO RENAN BECHER MONTAGEM DE UM AMBIENTE DE CLUSTER USANDO SOFTWARE LIVRE UMA ABORDAGEM AOS CLUSTERS DE ALTA DISPONIBILIDADE Joinville 2007 1 MARCELO RENAN BECHER MONTAGEM DE UM AMBIENTE DE CLUSTER USANDO SOFTWARE LIVRE UMA ABORDAGEM AOS CLUSTERS DE ALTA DISPONIBILIDADE Esse trabalho sera apresentado ao Instituto Supe rior Tupy como requisito parcial para a obten o de grau de bacharel em Sistemas de Informa o sob orienta o do Professor Eduardo da Silva PROF EDUARDO DA SILVA Joinville 2007 1 MARCELO RENAN BECHER MONTAGEM DE UM AMBIENTE DE CLUSTER USANDO SOFTWARE LIVRE UMA ABORDAGEM AOS CLUSTERS DE ALTA DISPONIBILIDADE Esse trabalho foi julgado e aprovado em sua forma final pela banca examinadora abaixo assinada Joinville 26 de junho de 2007 Prof Eduardo da Silva Prof MSc Mehran Misaghi Prof MSc Alexandre Lima BECHER MARCELO RENAN MONTAGEM DE UM AMBIENTE DE CLUSTER USANDO SOFTWARE LIVRE UMA ABORDAGEM AOS CLUSTERS DE ALTA DIS PONIBILIDADE Joinville SOCIESC 2007 1 A toda minha familia por todo o apoio ao longo da caminhada AGRADECIMENTOS A DEUS que sempre me deu for a para continuar nos momentos de fraqueza A minha familia pelo apoio e incentivo aos estudos Aos amigos Carlos Diego Russo Medeiros e Felipe Nogaroto Gonzalez por todo o co nhecimento que me foi repassado A
34. a de boleto etc O portal proporcionaria conforto tanto para o cliente quanto para a transportadora O cliente nao precisaria mais entrar em contato com a empresa solicitando os servi os Os colaboradores por outro lado poderiam ser alocados em outras tarefas Il acompanhamento de entregas este um m dulo dentro do espa o do cliente Os ca minh es saiam na parte da manh fazer entregas No TCtran a mercadoria somente era dada como entregue a noite quando eles retornavam para a empresa ou no dia seguinte Era muito comum clientes ligarem para a transportadora questionando sobre a localiza o da mercadoria N o existia nenhum meio de saber a localiza o da carga que muitas vezes j havia sido entregue Pode se observar que neste ambiente v rias melhorias eram poss veis e necess rias como por exemplo implanta o de controles sobre todo o tr fego de Internet contrata o de enlaces de Internet com largura de banda maior e disponibilidade das informa es para que as filiais tivessem acesso 6 2 PROPOSTA DE MELHORIA O projeto de melhoria foi elaborado em conjunto por duas empresas a BC2C Tecnologia especialista em ambientes Microsoft a empresa que j prestava suporte na parte de redes e hardware para a Levatudo Log stica Ltda b iTFLEX Tecnologia especialista em solu es de software livre redes e seguran a da informa o Foi a empresa contratada para a reestrutura o da parte de comunica
35. ace virtual no cluster Fonte O Autor Nas ltimas vers es o Heartbeat ganhou tamb m um mecanismo para tirar do ar ou tros nodos conhecido como Atire na Cabe a do Outro nodo Shot The Other Node In The Head STONITH o qual prov um mecanismo de acesso nico ao storage recurso de arma zenamento Isso permite ao Heartbeat trabalhar com dispositivos de armazenamento compar tilhados o DRBD por exemplo garantindo assim a confiabilidade dos dados KOPPER 2005 A partir desse momento o Heartbeat atingiu um alto grau de maturidade e passou a atrair muitas empresas da rea de telecomunica es Como resultado o projeto passou a receber contribui o e apoio de algumas dessas empresas em especial a Intel devido ao seu interesse na rea de telecomunica es 4 2 1 A estrutura do aplicativo As configura es do Heartbeat est o divididas em tr s arquivos etc hd d ha cf etc ha d authkeys e etc hd d haresources etc hd d ha cf o a arquivo de configura o geral do Heartbeat Nele s o confi guradas por exemplo quais interfaces ser o usadas para os nodos se comunicarem serial Ethernet e quanto tempo o nodo secund rio deve esperar antes de assumir no caso do nodo principal falhar 50 etc ha d authkeys permite assinar digitalmente os pacotes do Heartbeat Podem ser usados tr s algoritmos MD5 O Message Digest algorithm 5 definido pela RFC 1321 Sua chave de 128 bits com
36. ade 2 5 3 Clusters de balanceamento de carga LBC Os Clusters de balanceamento de carga Load Balance Clusters LBC s o um misto de cluster de alto desempenho com cluster de alta disponibilidade Neste tipo de cluster v rios nodos chamados de nodos diretores ou load balancers atendem requisi es de um servi o qualquer e repassam aos demais nodos do cluster Estes por sua vez fazem o processamento das informa es e s o conhecidos como servidores reais GARCIA 2007 Esta t cnica faz com que n o haja um ponto de gargalo muito usada em grandes portais de Internet que recebem um grande n mero de acessos simult neos ABREU 2004 Um exemplo de empresa que utiliza em grande escala os clusters do tipo LBC o Go ogle Neste ambiente diversos nodos recebem s requisi es de busca feitas pelos usu rios e repassam aos nodos reais que ent o fazem a busca e devolvem os resultados ao usu rio DEAN 2003 2 6 ARQUITETURA DOS CLUSTERS A arquitetura dos clusters compreende toda a estrutura de funcionamento dos nodos e equipamentos de rede ou seja a maneira com que eles se comunicam quais servi os execu tam o que fazer no caso de falhas entre outros Os elementos citados na se o 2 3 trabalhando em conjunto que formam esta arquitetura Hoje n o existe um padr o para arquitetura de clusters Muitos fornecedores de solu es comerciais adotam uma nomenclatura voltada para suas solu es e que diferem umas
37. ale computing capabilities California Artigo publicado na IBM 1967 BRASILEIRO F V Seljuk Um ambiente para suporte ao desenvolvimento e execu o de aplica es distribu das robustas Campina Grande Monografia apresentada na UFPB 2000 CENAPAD Guia do Usu rio CENAPAD 2007 Unicamp Dispon vel em lt http www cenapad unicamp br gt Acesso em 20 fev 2007 DARWIN I F e a Linux Standard Base Core Specification 3 1 2006 The Free Standards Group Dispon vel em lt http www linux foundation org en Specifications gt Acesso em 19 abr 2007 DEAN J e a Web search for a planet The google cluster architecture Mountain View Artigo publicado pelo IEEE 2008 FAUSTINO E P e a Construindo supercomputadores com Linux Goi nia Monografia apresentada no Cefet 2006 FERREIRA L e a Linux HPC Cluster Installation Austin IBM 2001 FRANCO L D Implementa o computacional em ambiente paralelo de mem ria distribu da para an lise acoplada de sistemas off shore Rio de Janeiro Monografia apresentada na UFRJ 2004 GARCIA S Clusters de Balanceamento de Carga em Linux S o Paulo Artigo publicado na Slackwarezine 2007 KOPPER K The Linux Enterprise Cluster San Francisco No Starch Press 2005 LAUREANDO S C Un cluster in alta disponibilit in ambiente Linux Bari Monografia apresentada a Universita Degli Studi di Bari 2004 MANFREDINI C Medida previs ria do bem 2005 Minist
38. ap tulo 5 Por quest es de seguran a o nome real da empresa n o ser divulgado Ser utilizado o nome fict cio Levatudo Log stica Ltda Ser apresentada a situa o da infraestrutura na poca a proposta de melhoria e como ficou o parque ap s as mudan as 6 1 O AMBIENTE DA EMPRESA NA POCA E SUAS NECESSIDADES A Levatudo Log stica Ltda uma empresa que atua no mercado h 35 anos oferecendo transportes de carga fracionada lota es transportes municipais intermunicipais estaduais e interestaduais Atualmente a Levatudo Log stica Ltda possui uma frota de 109 ve culos entre cavalos carretas e caminh es distribu dos entre as dez filiais da empresa que est o localizadas nos estados do Paran Santa Catarina e S o Paulo Nos demais estados a empresa somente entrega mercadorias atrav s de redespachos feitos por transportadoras parceiras A rea de TI da empresa apresentava diversos problemas Os principais estavam rela cionados com a disponibilidade e centraliza o das informa es e tamb m conectividade entre matriz e filiais A empresa utiliza o aplicativo TCtran para faturamento emiss o de conhecimentos de frete coletas entregas entre outros Havia uma base de dados principal na matriz e uma base de dados local para cada filial O sincronismo das informa es era feito somente no sentido filiais matriz atrav s de arquivos de troca gerados pelo TCtran que ao final do expediente eram enviados por
39. bi lizou na Internet um guia contendo algumas recomenda es que deveriam ser seguidas por quem quisesse desenvolver alguma aplica o voltada alta disponibilidade Depois de um ano nada havia sido criado ent o Milz decidiu implementar um pequeno aplicativo que era menci onado no guia Assim nasceu o Heartbeat que a pe a fundamental do projeto LINUX HA ROBERTSON 2004 A vers o est vel do Heartbeat para ambientes de produ o foi disponibilizada em 1999 e desde ent o vem sendo utilizado em in meros projetos pelo mundo todo al m de ter sido portado para outros sistemas operacionais baseados em Unix 4 2 AS CARACTER STICAS DO HEARTBEAT O aplicativo Heartbeat foi criado inicialmente de modo a permitir que fosse montado um cluster de alta disponibilidade com dois nodos um principal e outro secund rio backup e que seguisse dois prop sitos a verificar se ambos os nodos est o no ar ou seja aptos a disponibilizar servi os aos clientes 47 b no caso do nodo principal falhar o nodo secund rio assumir e disponibilizar os servi os que eram oferecidos pelo nodo principal O Heartbeat utiliza tr s tipos de mensagens para troca de informa es heartbeats mensagens de transi o e requisi es de transmiss o heartbeats s o o tipo mais comum de mensagem S o conhecidas como batidas de cora o ou mensagens de status e t m de cerca de 150 bytes por meio delas que os nodos se comun
40. da passando pelas abstra es e hist ria de surgimento dos clusters A se o 2 5 apresenta os principais tipos de clusters existentes no mercado e as reas em que s o utilizados Ao final apresentada uma proposta de arquitetura de comunica o entre as camadas que formam a arquitetura dos clusters e uma conclus o sobre o cap tulo 2 Antes de iniciar a abordagem aos clusters importante entender o que o software livre e como surgiu o sistema operacional Linux 2 1 PAPEL DO SOFTWARE LIVRE COMO BASE PARA OS CLUSTERS Em 1984 o at ent o pesquisador do Instituto de Tecnologia de Massachusetts Mas sachusetts Institute of Technology MIT Richard Stallman criou a Funda o do Software Livre Free Software Foundation FSF pela qual passou a defender a id ia de que o c digo fonte de todo e qualquer aplicativo deve estar dispon vel para que qualquer pessoa tenha acesso Ele n o achava correto que os fabricantes fornecessem todo o aplicativo necess rio para o funci onamento do seu equipamento Stallman sentiu que isso impedia que o aplicativo fosse aper fei oado pois somente algumas poucas pessoas tinham acesso ao c digo fonte FERREIRA 2001 Foi ent o que ele come ou a defender a id ia de software livre No mesmo ano criou a Licen a P blica Geral General Public License GPL a qual se caracteriza por permitir quatro liberdades a quem estiver usando o aplicativo STALLMAN 2007 utilizar o apl
41. das outras devido aos diferentes tipos de cluster Uma das propostas de padroniza o arquitetural dos clusters o projeto OCF que prop e o uso de uma camada de programa o em comum entre todas as solu es de cluster PEREIRA 2004 Em geral a literatura apresenta v rias propostas semelhantes Pereira 2004 p 9 divide esta arquitetura em grupo de camadas e grupo de servi os O grupo de camadas 28 composto pelas camadas de comunica o liga o integra o e recupera o que sao definidas a seguir camada de comunica o a camada de comunica o em baixo n vel entre os nodos do cluster As interfaces de comunica o mais comuns s o do tipo Ethernet ou serial e cada interface trabalha de maneira aut noma Atrav s desta camada s o trocadas mensagens que verificam se um nodo est ativo ou n o e mensagens que verificam o estado do enlace Tamb m por meio dessa camada que realizado o sincronismo dos dados entre os nodos do cluster camada de liga o esta uma camada de alto n vel constru da sobre a camada de comunica o Ela proporciona a cria o de um enlace virtual por meio da associa o de todos os canais de liga o do nodo para este enlace vitual O objetivo desta camada tornar mais simples a troca de mensagens entre as camadas superiores por meio da abstra o camada de integra o durante o funcionamento do cluster pode ser necess rio que ele passe por uma tra
42. das falhas que visa impedir que novos erros aconte am A ocorr ncia de uma falha gera um erro que podem ser gerados de duas maneiras 45 erros gerados por falhas transenientes n o precisam ser tratadas pois ja desaparece ram Il erros gerados por falhas permanentes ainda est o presentes no sistema mesmo ap s a recupera o Mesmo que o sistema for reiniciado o erro ocorrer novamente Para evitar isso componente defeituoso deve ser identificado e n o ser mais utilizado Se ele n o for identificado n o ser poss vel reparar o sistema de modo que o erro n o aconte a novamente Geralmente o componente defeituoso o que est mais pr ximo da origem do erro Em seguida o sistema deve ser reparado atrav s da substitui o do componente defeituoso para voltar a operar normalmente A tabela 6 apresenta alguns mecanismos que podem ser utilizados em cada fase da toler ncia falhas e que auxiliam no processo de recupera o do sistema Tabela 6 Fases da toler ncia a falhas Fases Mecanismos 1 detec o de erros duplica o e compara o testes de consist ncia diagn sticos 2 confinamento e avalia o hierarquia de processos controle de recursos 3 recupera o de erros t cnicas de recupera o por retorno ou avan o 4 tratamento da falha diagn stico e reparo Fonte Pereira 2004 p 35 3 6 CONCLUS O Por tr z de toda a parte que envolve o hardware e aplicativ
43. de problemas A bibliografia apresenta diversos tipos de cluster em que a nomenclatura geralmente baseada no tipo de aplica o que oferecem tais como banco de dados ou armazenamento Mas de modo geral os tr s principais tipos s o clusters de alto desepenho clusters de alta disponibilidade e clusters de balanceamento de carga 2 5 1 Clusters de alto desempenho HPC Neste tipo de cluster tarefas que exigem um n vel elevado de processamento s o di vididas entre os nodos ou seja s o executadas de forma paralela afim de que o tempo de processamento seja menor Quanto mais nodos estiverem ligados ao cluster menos tempo ser necess rio para executar todo o processamento PEREIRA 2004 Clusters de alto desempenho podem ser empregados em ambientes que possuam uma grande demanda de dados a serem processados Bancos de dados robustos aplica es de engenharia portais com grande volume de acessos s o alguns exemplos A utiliza o de aplica es que fazem uso do processamento paralelo uma tarefa com plexa por isso precisa ser bem planejada Al m do desenvolvimento das aplica es ser muito trabalhoso exige grande quantidade de mem ria e bastante tempo de processamento No Brasil existem cinco Centros Nacionais de Processamento de Alto Desempenho CENAPAD espalhados pelo pa s Est o instalados junto Unicamp em Campinas SP UFPE em Recife PE UFRGS em Porto Alegre RS UFMG em Belo Horizonte MG e UFRJ no
44. dessa interli ga o feita a troca de mensagens entre os nodos do cluster e uma falha pode ser detectada na aus ncia dessas mensagens VOGELS 1998 22 A tabela 1 apresenta os quatro principais componentes de um nodo Tabela 1 Os quatro principais componentes de um nodo Componente Descri o CPU Componente de processamento principal que l e escreve na mem ria do computador Mem ria Armazenamento tempor rio de informa es durante opera es de entrada sa da Reposit rio de armazenamento Dispositivo que armazena informa es Geralmente um disco r gido Interconex o Canal de comunica o entre os nodos Fonte O Autor adaptado de Pereira 2004 p 8 2 3 2 Recurso As funcionalidades oferecidas pelos nodos s o conhecidas como recurso Eles podem ser l gicos como o nome de um servidor por exemplo ou f sicos como um dispositivo de armazenamento fundamental o uso de uma ferramenta que possibilite o monitoramento dos recursos que fazem parte do ambiente pois em caso de falha esta ferramenta pode por exemplo fazer com que o recurso seja disponibilizado em outro nodo e avise o operador que a falha ocorreu de modo que possa ser executada uma a o corretiva no nodo que apresentou indisponibilidade MISAGHI 2006 O processo de migra o de um recurso de um nodo para outro seja de forma autom tica por meio de interven o de um operador conhecido como failover PEREIRA 2004
45. e 1983 surgiram protocolos e ferramentas que permitiam fazer de maneira f cil a distribui o de trabalhos entre diferentes CPUs e tamb m o compartilhamento de arquivos A primeira solu o de cluster comercial surgiu em 1977 O ARCNET desenvolvido pela empresa Datapoint era uma solu o composta por hardware aplicativo e outros equipamentos que permitiram a interliga o das m quinas em rede WIKIPEDIA 2006 Em 1976 entrou no mercado a Tandem Computers que por muitos anos dominou o mer cado de solu es de toler ncia a falhas baseadas em aplicativoNo ano de 1980 foi fundada a Stratus Computers que entrou no mercado fornecendo solu es de alta disponibilidade basea das em hardware Anos mais tarde tanto a Tandem como Stratus acabaram se incorporando a outras empresas e atuando em ramos mais espec ficos WEBER 2002 25 2 5 OS DIFERENTES TIPOS DE CLUSTER E SUAS APLICAGOES Os clusters t m se mostrado uma alternativa vi vel se comparada a solu es proprieta rias de alto desempenho e alta disponibilidade pois os recursos financeiros exigidos na mon tagem do ambiente s o menores Alguns fatores impulsionaram a populariza o dos clusters como uso do hardware comum queda de pre os e evolu o de processadores e equipamentos de rede FAUSTINO 2006 Empresas do setor privado rg os governamentais institui es de pesquisa ou institui es financeiras utilizam clusters para resolver in meros tipos
46. e alguns objetivos sejam alcan ados tais como alto desempenho por meio da interliga o de computadores tarefas s o processadas paralelamente e consequentemente em menos tempo Il escalabilidade capacidade de aumentar a capacidade de processamento do cluster por meio da adi o de novos nodos HI toler ncia a falhas aumento da confiabilidade do sistema pois caso algum compo nente falhe outro assume sua fun o IV baixo custo e independ ncia de fornecedor o custo de montagem do ambiente baixo pois usado hardware comum que pode ser de qualquer fabricante e utilizando software livre n o existe a necessidade de pagamento de licen a de uso de aplicativo 2 3 ABSTRA ES DE UM CLUSTER Para melhor compreens o do trabalho importante conhecer alguns jarg es utilizados no mundo dos clusters e da alta disponibilidade Esta se o apresenta os termos mais comuns tais como n recurso depend ncia de recursos e grupo de recursos Quando um programa executado em um computador este programa em execu o conhecido como processo No sistema operacional Linux um processo que disponibiliza um servi o conhecido como daemon Um daemon e os recursos oferecidos por ele s o chamados de servi o KOPPER 2005 2 3 1 N ou Nodo Cada computador interligado ao cluster conhecido como n ou nodo Esta interliga o pode ser por meio de uma interface de rede ou de uma interface serial Por meio
47. elacionados a alta disponibilidade atrav s de exemplos pois sua compreens o fundamental para o entedimento do assunto 3 1 OS PRINC PIOS DA ALTA DISPONIBILIDADE Por meio de pesquisa feita na literatura observa se que muitas vezes s o usados termos diferentes ou at mesmo mais de um termo para definir um mesmo conceito Esta se o aborda de maneira detalhada os conceitos relacionados alta disponibilidade Disponibilidade pode ser caracterizada pela por o de tempo em que um recurso est no ar e pode ser usado para a finalidade desejada WATSON 1995 Para conceituar os termos relacionados alta disponibilidade e facilitar a compreen s o ao longo do cap tulo ser utilizado um exemplo retirado e adaptado do portal do Instituto Nacional de Padr es e Tecnologia dos Estados Unidos National Institute of Standards and Technology NIST 32 O exemplo do NIST considera uma ponte que fica sobre um rio A ponte pode ser en tendida como um recurso que neste momento apresenta disponibilidade pois permite o trafego de ve culos em ambos os sentidos Desse modo um caminh o que saiu de um lado do rio consegue fazer a travessia e chegar do outro lado sem problemas Redund ncia a palavra chave para se alcan ar alta disponibilidade e usada desde os primeiros computadores visando assim o aumento da confiabilidade do sistema WEBER 2002 Por isso a elimina o dos Ponto nico de Falha Single Point of Failu
48. ente para uso em clusters de alta disponibilidade Ele permite o espelhamento de dados entre duas ou mais parti es semelhante ao espelhamento conhecido como RAID 1 A diferen a que no RAID 1 os dados s o espelhados em dois discos locali zados fisicamente na mesma m quina TESTONI 2005 No DRBD esse espelhamento feito entre dois ou mais nodos interligados em rede KOPPER 2005 A Figura 16 ilustra os dois casos DRBD RAID 1 e o dev md1 1 dev sdb1 Figura 16 Semelhanga entre DRBD e RAID 1 Fonte O Autor A nivel de sistema operacional o DRBD um m dulo do kernel do Linux que junta mente com alguns scripts e aplicativos permite que parti es possam ser espelhadas 54 Cada parti o envolvida no espelhamento tem um estado que pode ser prim rio ou se cund rio O DRBD cria em todos os n s um v nculo entre um dispositivo virtual dev nbX e uma parti o local dev hdaX a qual n o acessada diretamente ou seja toda a escrita rea lizada no dispositivo virtual do servidor prim rio que ent o transfere os dados para o dispositivo de bloco do n vel mais baixo a parti o e propaga aos demais nodos em estado secund rio Ao receber os dados o nodo secund rio simplesmente escreve os dados no dispositivo de bloco do n vel mais baixo Atualmente a vers o 0 8 do DRBD permite que dois nodos acessem um dispositivo no modo leitura escri
49. espelhamento dos dados pelo gestor do clusters Al m disso esta solu o permite um melhor aproveitamento do espa o dispon vel A grande desvantagem que os sistemas de storage t m um custo muito elevado LAUREANDO 2004 b armazenamento interno e distribu do Esta a topologia na qual o DRBD se encaixa Nela os nodos usam discos comuns HDs os quais possuem pelo menos uma parti o de dados que compartilhada no clusters A grande vantagem desta topologia a elimina o de SPOFs pois se um disco em um nodo falhar outro pode assumir imediatamente No caso do storage se ele falhar somente tendo outro no lugar para substituir e por ser um equipamento caro geralmente as empresas n o tem Levando em conta custos e manuten o espelhamento a op o mais vi vel REISNER 2002 4 3 3 Os protocolos utilizados pelo DRBD No momento em que o DRBD foi projetado foram considerados v rios tipos de ambien tes onde aplicativo poderia ser utilizado Por isso foram criados tr s protocolos para controle do 56 espelhamento dos dados nos nodos secund rios S o eles protocolo A protocolo B e protocolo C protocolo A o nodo principal executa uma opera o de entrada sa da no disco local notifica aos demais nodos sobre o que foi alterado e d como encerrada a opera o O protocolo A n o aguarda o recebimento de uma confirma o nem se preocupa em saber se a opera o foi ou n o bem sucedida Gera
50. esso em 10 jan 2007
51. este teste foi desconectado o cabo de rede do nodo01 Ap s os 2 minutos sem co munica o o Heartbeat do nodo01 considerou que o nodo02 estava fora do ar e assumiu os servi os e vice versa O resultado foi a ocorr ncia de um problema conhecido como s ndrome do c rebro divido conforme mostra a Figura Neste caso os dois nodos passaram a disponibilizar os mesmos servi os Ao detectar que os dois nodos estavam no ar o Heartbeat parou o servi o em ambos fazendo com que ambos entrassem em um modo de espera Em seguida como os dois nodos estavam indispon veis o prim rio assumiu os servi os A Figura mostra os registros do sistema no momento em que isso ocorre 5 5 Teste 3 finalizar o daemon do samba no nodo prim rio Neste teste foi encerrado o processo do servidor samba no nodo prim rio atrav s do comando killall 9 smbde killall 9 nmbd que dessa foram deixou o servi o inacessi vel O objetivo era verificar se com o servi o indispon vel no nodo01 o Heartbeat iria executar o failover e fazer o nodo02 assumir 64 Mar 31 16 11 49 info All HA resources relinquished Mar 31 16 11 51 info Received shutdown notice from nodo02 itflex local Mar 31 16 11 51 info Resource takeover cancelled shutdown in progress Mar 31 16 11 51 info killing HBREAD process 8426 with signal 15 Mar 31 16 11 51 info killing HBFIFO process 8424 with signal 15 Mar 31 16 11 51 info killing HBWRITE process
52. funci onal b recupera o por avan o forward recovery ao contr rio do m todo anterior n o existe nenhum checkpoint anterior que possa ser utilizado feita uma tentativa de avan o 44 atrav s da cria o de um novo checkpoint livre de erros O sucesso do novo checkpoint vai depender muito do estrago causado no sistema Na pr tica o primeiro m todo mais utilizado pois a restaura o se da partindo de um ponto que j estava operante anteriormente ou seja a garantia de funcionamento maior O segundo m todo uma tentativa a probabilidade de sucesso na utiliza o menor e vai depender muito de como a aplica o trata os erros A tabela 5 mostra em resumo as t cnicas apresentadas e a Figura 10 exibe a id ia por traz dessas t cnicas Tabela 5 T cnicas de recupera o T cnica recupera o por retorno recupera o por avan o Defini o condu o a um estado anterior condu o a um novo estado Caracter sticas alto custo mas de aplica o gen rica eficiente mas danos precisam ser previstos Implementa o pontos de controle espec fica a cada sistema Fonte O Autor adaptado de Pereira 2004 p 33 ponto de recupera o rollback novo estado avan o Figura 10 Recupera o por retorno e por avan o Fonte O Autor adaptado de Pereira 2004 p 33 3 5 4 Tratamento da falha e servi os continuados Esta etapa descreve o tratamento
53. gura o etc ha d haresources Figura 15 Servi o samba sendo iniciado no RedHat Linux Figura 16 Semelhan a entre DRBD e RAID 1 Figura 17 Cluster do ambiente de testes Figura 18 Arquivo de configura o etc hd d ha cf Figura 19 Parti o do disco nos nodos Figura 20 Configura o do DRBD em etc drbd conf Figura 21 Mensagem de erro ao iniciar o Heartbeat Figura 22 Pacotes dos heartbeats Figura 23 Pacotes de replica o das informa es Figura 24 Pacotes de confirma o Figura 25 Forgando os recursos a migrarem para outro nodo 63 Figura 26 Dois nodos ativos ao mesmo tempo 64 Figura 27 Momento em que o nodo01 assume os servi os 64 Figura 28 Inconsist ncia nos 65 Figura 29 Tentando matar o processo do DRBD 66 Figura 30 O ambiente da empresa antes 69 Figura 31 Ambiente do cluster _
54. iar a aplica o ali Se o nodo que falhou retornar ele se torna o secund rio e precisa sincronizar seus dados com o prim rio Isto feito em segundo plano sem que seja necess ria a interrup o do servi o 4 3 1 A estrutura do aplicativo Os principais componentes do pacote DRBD s o 55 a m dulo DRBD um m dulo do kernel do sistema operacional Linux respons vel pela intera o com o hardware do nodo principal e nodos secund rios b sbin drbdsetup o comando utilizado para a configura o do DRBD Atrav s dele s o criados os dispositivos virtuais dev drbdX e definidos quais nodos far o parte do cluster por exemplo c sbin drbdadm comando utilizado para administra o dos dispositivos DRBD Ele permite que o espelhamento seja iniciado parado al m de fornecer estat sticas sobre o espe lhamento d etc drbd conf arquivo onde s o armazenadas todas as configura es do apli cativo 4 3 2 As topologias de armazenamento O DRBD permite ser utilizado em conjunto com algumas topologias de armazenamento existentes armazenamento externo e armazenamento interno e distribuido a armazenamento externo Este tipo de sistema de storage armazenamento permite acesso simult neo aos dados por todos os nodos que comp e o cluster Esta solu o centraliza todo o sistema de armazenamento dos dados e centraliza a gest o do sistema de arquivos em um nico ponto eliminando o trabalho de
55. icam Na aus ncia destas mensagens poss vel detectar a ocorr ncia de falha em um nodo Elas usam o protocolo UDP e s o enviadas por broadcast Il mensagens de transi o estas mensagens s o do tipo mais raro Elas cont m toda a conversa entre o Heartbeat do nodo principal e o Heartbeat do nodo secund rio no momento de transi o ou seja quando os recursos est o sendo migrados de um nodo para outro Ill requisi es de transmiss o o Heartbeat usa uma numera o sequencial nos pacotes afim de que eles cheguem corretamente Isso faz com que o Heartbeat saiba quando os pacotes chegam corrompidos ou fora de ordem Quando alguma coisa estiver errada o Heartbeat solicita a retransmiss o do pacote Ele n o faz isso mais do que uma vez por segundo evitando assim o aumento de tr fego na rede KOPPER 2005 O aplicativo Heartbeat em execu o no nodo backup pode checar os heartbeats vindos do nodo prim rio atrav s da interface Ethernet presente no servidor Normalmente o Heartbeat configurado para utilizar uma conex o f sica separada da rede comum Pode ser utilizada uma interface de rede dedicada ao Heartbeat atrav s de um cabo de cross over por exemplo ou pode ainda ser utilizado um cabo serial Se as tr s op es forem utilizadas em conjunto eliminm o SPOF na comunica o entre os nodos O Heartbeat trabalhar sob uma ou mais dessas conex es simult neamente e ir con siderar que o nodo prim rio es
56. icativo sem nenhuma restri o e sem ter que pagar por uma licen a de uso Il estudar o aplicativo e entender como ele funciona Ill redistribuir o aplicativo para outras pessoas IV aperfei oar o aplicativo corrigindo erros ou acrescentando novas funcionalidades A partir de ent o a FSF passou a criar aplicativos e disponibiliz los sobre a licen a GPL al m de divulgar a filosofia mundo afora 19 Anos mais tarde em 1990 o programador finland s Linus Torvalds inicia como um pro jeto pessoal o desenvolvimento do sistema operacional Linux NEMETH 2004 o qual foi ba seado no sistema operacional Minix que por sua vez foi criado com base no Unix desenvolvido na d cada de 70 e ja conhecido por sua estabilidade PITANGA 2002 Torvalds utilizou o compilador Compilador GNU C GNU C Compiler GCC criado pela FSF no desenvolvimento do Linux Ele tamb m disponibilizou seu projeto na Internet sob a licen a GPL e passou a receber colabora o de c digo de muitos programadores Dessa maneira sistema tornou se muito conhecido e come ou a ser utilizado no meio acad mico e nas empresas Por m para o sistema ser utilizado em ambientes de miss o cr tica ainda faltavam ferramentas que garantissem alta disponibilidade dos servi os PEREIRA 2004 No in cio foi dif cil para os fornecedores de solu es baseadas no sistema operacional Linux pois o Unix originalmente n o oferecia recursos que permitissem de maneira aut
57. icientemente compat veis a n vel de compartilhamento de processos entre elas Tamb m a vers o cliente tem que ser transparente para poder interagir com as vers es A e B no servidor RESNICK 1996 Cliente Nodo 1 Nodo 2 1 Antes de Vers o X Vers o Vers o atualiza o Cliente Nodo 1 2 Removendo lt Vers o o nodo 2 3 Instalada vers o Cliente Nodo 1 Nodo 2 nodo 2 Sincroniza Vers o X Vers o A Vers o informa es com a vers o A do nodo 1 Cliente 1 n Nodo 2 4 Remo o eas 5 Instalada vers o no Cliente Nodo 1 Nodo 2 nodo 1 Sincroniza Vers o X gt Vers o B Vers o B informa es com a vers o B do nodo 2 Figura 7 Atualiza o de aplicativo em um sistema de disponibilidade cont nua Fonte O Autor adaptado de Resnick 1996 p 10 39 3 3 4 Dominios de disponibilidade Em um sistema de alta disponibilidade estao envolvidos varios componentes tais como hardware aplicativo procedimentos entre outros Geralmente nao se deseja que todos os componentes ofere am o mesmo nivel de disponibilidade ou seja alguns componentes vitais para o funcionamento do sistema requerem um n vel maior de disponibilidade enquanto outros exigem um n vel menor O autor RESNICK 1996 sugere uma divis o de seis sub dom nios aos quais os com ponentes podem ser associados Disponibilidade B sica Dominios de Dominios de
58. ility To the end an environment of tests is mounted where the tools presents in Linux operational system are used and presented a case study of a logistics company where a high availability communication environment was created following the principles of high availability Keywords Grouping Availability Faults Cluster LISTA DE ILUSTRA ES Figura 1 Cluster de quatro computadores Figura 2 Depend ncia de recursos em um servidor Apache Figura Exemplo de agrupamento de recursos em grupo Figura 4 Exemplo de cluster e sub cluster Figura 5 Exemplo de redund ncia Figura 6 Altern ncia entre os per odos de funcionamento e reparo Figura 7 Atualiza o de aplicativo em um sistema de disponibilidade cont nua Figura 8 Dom nios de disponibilidade Figura 9 Modelo de tr s universos defeito erro e falha Figura 10 Recupera o por retorno e por avan o Figura 11 Arquitetura do Heartbeat Figura 12 Uso da interface virtual no cluster Figura 13 O arquivo de configura o etc hd d authkeys Figura 14 O arquivo de confi
59. is de disponibilidade que podem ser alcan ados S o eles disponibilidade b sica alta disponibilidade e disponibili dade cont nua 3 3 1 Disponibilidade b sica basic availability BA Um sistema que foi projetado desenvolvido e implantado com um n mero suficiente de componentes hardware aplicativos e procedimentos para satisfazer os requisitos funcionais e nada mais um sistema que pode se dizer que apresenta Disponibilidade B sica RESNICK 1996 37 Cabe aqui novamente o exemplo da ponte Supondo que ela tenha sido construida tendo como objetivo somente permitir a travessia do rio sem contar com nenhum recurso de redund ncia para o caso de a ponte precisar de reformas ent o pode se dizer que ela apresenta uma disponibilidade b sica RESNICK 1996 3 3 2 Alta disponibilidade high availability HA Um sistema que foi projetado desenvolvido e implantado com componentes suficientes para satisfazer os requisitos funcionais e que tamb m oferece redund ncia de componentes hardware aplicativos e procedimentos para mascarar algumas falhas pr estabelecidas um sistema que apresenta alta disponibilidade RESNICK 1996 O mascaramento consiste em impedir que os usu rios do cluster visualizem a falha n o impedir que ela aconte a Isto pode ser alcan ado atrav s da redund ncia atrav s da substitui o do equipamento falho pelo funcional Dependendo do grau de transpar ncia de sejado o grau de dispo
60. lidade ainda pouco explorado se comparado a outras reas como por exemplo os clusters de alto desempenho Grande parte do material encontrado como artigos por exemplo s o escritos por alguns poucos autores Algumas sugest es para trabalhos futuros s o implementa o do Heartbeat em um ambiente com mais de dois nodos afim de se ob servar como o Heartbeat trata o processo de failover nesse ambiente ll utilizar o DRBD no modo leitura escrita em mais de dois nodos simultaneamente e verificar a consist ncia dos dados Ill estudo comparativo de desempenho entre sistemas de arquivos distribu dos tais como DRBD GFS OCFS2 IV estudo comparativo entre diferentes ferramentas de monitoramento afim de se identificar qual delas a melhor para trabalhar em conjunto com o Heartbeat e o DRBD 79 GLOSSARIO API Interface para Programa o de Aplica es Application Programing Interface CENAPAD Centros Nacionais de Processamento de Alto Desempenho DMZ Zona desmilitarizada DeMilitarized Zone DRBD Dispositivo de bloco de armazenamento distribuido Distributed Replicated Block Device EXT3 Terceiro Sistema de Arquivos Third Extended File System FSF Fundagao do Software Livre Free Software Foundation GCC Compilador GNU C GNU C Compiler GPL Licen a P blica Geral General Public License GFS Sistema de Arquivos Global Global File System HAC Clusters de alta disponibilidade High Availability Clusters H
61. lmente usado em redes onde a lat ncia grande como por exemplo uma conex o via Rede Virtual Privada Virtual Private Network VPN Do ponto de vista da confiabilidade o que apresenta a menor n vel entre os tr s Il protocolo B apresenta um nivel de confiabilidade um pouco maior Ap s nodo principal ter executado uma opera o de entrada sa da no disco local notifica os demais e aguarda a confirma o de que os pacotes foram recebidos por m n o aguarda que os nodos secund rios fa am a grava o nos discos locais GARCIA 2007 Ill protocolo C as opera es s o realizadas de modo sincronizado O nodo principal n o sinaliza como finalizada uma opera o de entrada sa da no disco local por exemplo at at que todos os nodos secund rios tenham executado a tarefa tamb m e tenham enviado uma confirma o para o nodo principal Os desenvolvedores recomendam o uso do protocolo C em redes de baixa lat ncia e que tenham um alto n mero de opera es de entrada sa da como um servidor de arquivos por exemplo O emprego do protocolo C em redes de grade lat ncia totalmente invi vel pois causar uma grande lentid o no servidor O protocolo C o que proporciona maior seguran a e confiabilidade entre os tr s sendo portanto o mais utilizado REISNER 2004 4 3 4 sincronismo quando um nodo entra no cluster Quando um nodo falho retorna ao clusters ou quando um novo nodo adicionado ao cluster
62. m http www linux ha org heartbeat 2 0 7 1 1586 rpm pacote base para o funcionamento do aplicativo heartbeat stonith 2 0 7 1 1586 rpm mecanismo que prov acesso nico dis positivo de armazenamento heartbeat pils 2 0 7 1 1586 rpm plugins o Heartbeat Depois de instalados foi feita a configura o atrav s do arquivo etc hd d ha cf marcelo canoeh ha dJ cat ha cf File to write debug messages to debugfile var log ha debug File to write other messages to logfile var log ha log Facility to use for syslog logger logfacility localO keepalive 2 deadtime 120 warntime 150 beast ethd Linux auto_failback off watchdog dev watchdog node nodename must match uname n node nodo01 itflex local node nodo02 itflex local Figura 18 Arquivo de configura o etc hd d ha cf Fonte O Autor O keepalive o intervalo que os nodos aguardam entre o envio dos heartbeats O dead time indica quanto tempo os nodos backup devem aguardar quando perderem a comunica o com o nodo principal antes iniciar o processo de takeover A vari vel initdead especifica quanto o nodo deve aguardar para iniciar os servi os quando for reinicializado por exemplo Os valores s o expressos em segundos e podem variar de acordo com o ambiente A vari vel bcast in 60 forma que o Heartbeat deve usar a interface ethO para as mensagens de controle Nas ultimas duas linhas as varia
63. m ser compreendidos como pontos de vista da dependabilidade como disponi bilidade confiabilidade confidencialidade integridade seguran a e sustentabilidade l a prontid o de uso leva disponibilidade 1 continuidade do servi o leva confiabilidade Ill o impedimento de revela es desautorizadas de informa es leva confidencialidade IV a prote o contra altera es impr prias nas informa es leva integridade V a prote o contra cat strofes ao ambiente e ao usu rio leva seguran a VI a possibilidade de submeter o sistema a reparos e evolu es leva sustentabilidade Tabela 4 Exemplos de sistemas e suas disponibilidades necess rias C digo Onde s o exigidos 1 computadores pessoais sistemas experimentais sistemas de acesso provedores de internet CPD sistemas de neg cios sistemas de telefonia de sa de banc rios a sistemas de defesa militar Fonte Pereira 2004 p 19 35 Diante disso o termo dependabilidade mostra se mais abrangente se comparado sim plesmente disponibilidade 3 2 1 Confiabilidade A confiabilidade uma fun o R t que representa a probabilidade de um sistema estar operante at o instante t e tamb m uma medida de probabilidade pois a ocorr ncia de falhas um fen meno aleat rio PEREIRA 2004 Segundo Weber 2002 p 11 a confiabilidade implica algumas condi es
64. m servi dor atrav s da Internet No caso de uma transportadora isso bastante cr tico pois al m de estar disponibilizando dados da empresa e de clientes ela trabalha com transporte de diversos tipos de mercadoria e cargas de alto valor Um firewall com controles efetivos sobre o tr fego de extrema import ncia para que um poss vel invasor n o tenha acesso a essas informa es e consiga por exemplo descobrir informa es sobre rotas dos caminh es tipos de mercadoria transportados etc O novo firewall possui controles de acesso internos e externos seguindo o princ pio de que somente as portas de comunica o necess rias s o abertas as demais s o fechada O servi o de proxy controla a navega o e permite a gera o de relat rios de acesso por usu rio ou esta o VPN para comunica o segura entre matriz e filiais atrav s da Internet e controle de banda QoS para otimizar o uso dos enlaces de Internet b servidor Web nesse novo cen rio foi criada uma rede separada conhecida como Zona desmilitarizada DeMilitarized Zone DMZ para os servidores que disponibilizam servi os na Web A DMZ criada com o intuito de que se um invasor conseguir acesso privilegiado ao servidor esse acesso seja somente ao servidor e n o a rede interna onde est o as informa es da empresa Um dos pap is do firewall filtrar essa comunica o Este servidor al m de 72 correio eletr nico disponibiliza webmail recurs
65. necimento de energia tais como a rede el trica convencional e um gerador de energia da 33 pr pria empresa Assim no caso de uma fonte falhar a outra assume a fun o Outro exemplo relacionado com a localiza o f sica dos recursos que se mantenha uma c pia de todos os dados da empresa em outro local f sico pois no caso de um inc ndio por exemplo de nada adianta se ter redund ncia ou backup das informa es se elas estiverem no mesmo local Desse modo a recupera o do desastre pode de dar de uma maneira bem r pida 3 1 1 Como medir a disponibilidade Para medir a disponibilidade de um recurso atualmente existem duas maneiras que s o mais comuns A primeira considera a prov vel por o de tempo em que um sistema estar no ar e a por o de tempo em que estar fora do ar conhecidas comumente como uptime e downtime respectivamente PEREIRA 2004 A segunda e mais usada atualmente considera o n mero de noves de disponibilidade que o recurso apresenta durante um ano Pode ser calculada atrav s da seguinte equa o _ Desse modo um recurso 4 noves de disponibilidade significa que seu uptime de 99 99 ou seja durante um ano apresenta indisponibilidade durante cerca de 52 minutos cerca de 1 minuto por semana A tabela 7 define as siglas usadas na equa o Tabela 2 Medidas de Confiabilidade Medida Significado MTBF mean time between failu
66. nibilidade tamb m pode variar Os quatro tipos de mascaramento s o mascaramento manual cold stand by warm stand by e hot stand by a Mascaramento Manual MM Neste tipo de mascaramento necess ria a interven o de um operador para colocar o componente redundante no ar Durante essa interven o o sistema fica indispon vel para uso b Cold Stand By CS Ap s um componente falhar os usu rios s o desconectados e perdem o trabalho feito at ent o Neste momento ocorre o takeover que quando o nodo que estava somente aguardando a ocorr ncia de uma falha entra no ar e assume o papel de nodo operante A partir desse momento os usu rios j podem conectar se novamente ao servi o e ter o dispon veis no servidor as informa es do ltimo sincronismo com o nodo principal c Warm Stand By WS Neste caso os usu rios tamb m s o desconectados e perdem o trabalho feito at o momento Um mecanismo autom tico de detec o de falhas detecta a falha e notifica o o nodo secund rio o qual j est iniciado e parcialmente ativo Pelo fato de o nodo secund rio j estar no ar o tempo de detec o da falha o mesmo do caso anterior mas o tempo de migra o de recursos de um nodo para outro bastante reduzido d Hot Stand By Replica o Ativa HS RA Este tipo de mascaramento o mais transparente para os usu rios do clusters se comparado aos demais Neste caso os compo nentes redundantes e ativos s
67. nsi o ou seja adicionar remover ou subsubstituir nodo do grupo Esta camada garante as altera es na forma o do cluster e faz com que todos os nodos tomem conhecimento da altera o da composi o do cluster camada de recupera o a fun o desta camada recuperar se das transi es realizadas pela camada de integra o Ela transporta as vari veis do sistema e seus valores do nodo falho para o nodo ativo deixando o no mesmo estado do nodo falho antes deste apresentar problemas Esta camada permite ainda desativar o acesso a certos servi os at que a migra o dos recursos para o outro nodo esteja completa O grupo de servi os formado pelo servi o de qu rum servi o de barreiras servi o de informa es e servi o de nomes servi o de qu rum os clusters possuem a caracter stica de poderem ser divididos em grupos menores ou seja um subcluster formado por um n mero menor de nodos Essa divis o pode ser necess ria por exemplo em uma situa o em que ocorre uma falha de comunica o em uma parte do cluster Os nodos problem ticos s o ent o separados de modo a n o interferir no funcionamento dos demais Dois subclusters n o podem disponibilizar servi os simult neamente sempre deve existir um subcluster principal Esta situa o conhecida como s ndrome do c rebro dividido ou em ingl s split brain syndrome KOPPER 2005 Para evitar a s ndrome do c rebro 29 dividido cada nod
68. o da informa o Defeito Universo do usuario Figura 9 Modelo de tr s universos defeito erro e falha Fonte O Autor adaptado de Weber 2002 p 9 3 4 2 A classifica o das falhas Segundo o autor Pereira 2004 p 29 as falhas podem ser classificadas de acordo com a natureza ou a dura o I Natureza a falhas f sicas s o as falhas relacionadas aos componentes f sicos do sistema Po dem ocorrer devido a mudan as de temperatura interfer ncia eletro magn ticas curto circuitos entre outros b falhas humanas podem ter ocorrido na fase de projeto do sistema ou durante a intera o do operador com o equipamento Il Dura o a falhas transientes falhas com curto per odo de dura o Elas tamb m podem ser intermitentes ocorrendo sequencialmente por curtos intervalos de tempo b falhas permanentes uma vez que o componente falhou ele n o voltar mais a funci onar corretamente 3 5 FASES DA TOLER NCIA A FALHAS N o existe uma t cnica que deve ser seguida em todos os casos em que se deseja alcan ar alta disponibilidade Por m existem alguns pontos que devem ser considerados e que levam a este objetivo os quais ser o detalhados no decorrer desta se o 42 3 5 1 Detec o de erros Antes dos erros serem tratados eles precisam ser identificados Portanto esta a pri meira fase da toler ncia falhas Elas s o descobertas atrav s de erros apresentados pelo si
69. o possui uma lista em que consta quais s o os membros associados ao subcluster Esta camada decide qual dos subclusters possui qu rum ou seja qual ser o subcluster principal Ela respons vel por fazer essa escolha de duas maneiras vota o ou recurso de qu rum Na vota o o subcluster composto pelo maior n mero de nodos eleito o principal No recurso de qu rum o subcluster que possuir um certo recurso ser escolhido como subcluster principal n o levando em considera o o n mero de nodos que o comp e Ap s conclu da a etapa para eleger o subcluster principal a lista dos subclusters atua lizada e informada aos demais nodos Demais nodos que n o pertencerem ao subcluster principal neste momento param de processar as informa es A Figura 4 apresenta um cluster com seis nodos ativos Em seguida dois deles falham e o cluster dividido em dois subclusters Os nodos falhos ficam isolados e os quatro nodos restantes assumem dois nodos falhos Figura 4 Exemplo de cluster e sub cluster Fonte O Autor Il servi o de informa es os nodos que comp e o cluster possuem capacidade de votar e tomar algumas decis es Dessa forma necess rio em cada nodo do cluster um banco de dados transacional para que as configura es e informa es sobre seu estado possam ser salvas de maneira persistente lll servi o de barreiras esta camada controla todas as transi es do clus
70. o que seja copiado somente as informa es que foram alteradas no per odo de tempo em que o nodo esteve ausente Este processo conhecido como sincronismo r pido 4 4 CONCLUS O Com base na pesquisa feita pode se identificar alguns aplicativos que podem ser utili zados em conjunto com o sistema operacional Linux e que proporcionam alta disponibilidade Alguns projetos tiveram um per odo de vida muito curto por possu rem caracter sticas que n o v o de encontro com as necessidades do mercado O Heartbeat e o DRBD foram os aplicativos de maior destaque e por isso foram frutos de estudo Ambos os projetos amadureceram no decorrer do tempo sendo hoje est veis e podendo ser utilizados para solucionar os mais diversos tipos de problema Algumas funcionalidades ainda s o requeridas Muitas j est o previstas para as pr xi mas vers es que garantia de que os aplicativos continuar o sendo desenvolvidos e com estas novas caracter sticas poder o ser ainda empregados em diversas outras solu es 58 5 AVALIA O DAS FERRAMENTAS DE ALTA DISPONIBILIDADE Para que se pudesse compreender melhor o funcionamento das ferramentas apresenta das no cap tulo 4 foi montando um clusterde alta disponibilidade com dois nodos Atrav s dele foi poss vel passar por situa es semelhantes a um ambiente real que tratam desde a insta la o do sistema operacional configura o b sica do sistema configura o dos aplicativo
71. o sistema por isso pode ser detectado apenas quando o sistema apresentar algum erro Retomando o exemplo da ponte citado no in cio do cap tulo Uma falha pode ser um buraco no acostamento da ponte O fato do buraco estar presente conduz a ponte ao estado de erro pois o buraco n o faz parte do projeto da ponte Enquanto o acostamento n o for utilizado o buraco n o ser respons vel por nenhum acidente Entretanto no momento em que o acostamento for utilizado um ve culo pode cair no buraco e sofrer um acidente conduzindo o sistema ao estado de defeito pois o acidente tamb m n o faz parte da especifica o da ponte 3 4 1 modelo de tr s universos Este modelo mostra a rela o entre defeitos erros e falhas formado por tr s univer sos universo f sico da informa o e do usu rio SANTOS 2000 a universo f sico onde ocorrem as falhas Ele composto pelas partes f sicas do sistema Nele que ocorrem as altera es de comportamento que levam a ocorr ncia de falhas b universo da informa o nele que os erros acontecem Este universo o respons vel por afetar as informa es armazenadas no computador c universo do usu rio aqui o usu rio percebe a ocorr ncia de erros que quando surgem os defeitos A representa o gr fica do universo que envolve os tr s tens comentados anteriormente mostrada pela Figura 9 41 Falha Universo f sico Erro _ Univers
72. o sistema operacional devem ser controlados iniciados ou parados atrav s dos scripts conhecidos como init scripts DARWIN 2006 Nas distribui es baseadas no RedHat Linux estes arquivos est o localizados em etc rc d init d e est o ligados ao nome do servi o por exemplo smb sshd ou cups Normalmente o pr prio sistema operacional trata de iniciar estes servi os no momento em que o servidor ligado Quando um servi o for disponibilizado no cluster a tarefa de iniciar e parar o servi o deve ficar por conta do Heartbeat e n o do sistema operacional Isso far com que o Heartbeat execute corretamente o processo de failover O Heartbeat usa a sa da do comando que ecoada na tela para saber se o servi o foi inicializado com sucesso ou n o Os init scripts das distribui es Linux RedHat e SuSE por exemplo imprimem na tela o status como OK done ou sucess root canoeh 1 service smb start Iniciando servicos SMB OK 1 Iniciando servi os NMB OK 1 root canoeh It E Figura 15 Servi o samba sendo iniciado no RedHat Linux Fonte O Autor 52 4 2 2 Outras caracter sticas do Heartbeat Al m das capacidades j apresentadas o autor Robertson 2004 p 07 apresenta outras caracter sticas do Heartbeat O Heartbeat permite trabalhar com configura es no modo ativo passivo ou ativo ativo Em um ambiente com dois nodos se um disponibiliza todos os servi os e o outro atua como servidor backu
73. o tamb m mostra a hist ria de surgimento dos pri meiros clusters quais os principais tipos e cita alguns exemplos de reas em que podem ser utilizados Ao final apresentada a arquitetura de clusters segundo a proposta do Padr o de Cluster Aberto Open Cluster Framework OCF O cap tulo 3 mostra os conceitos relacionados alta disponibilidade e apresenta uma das f rmulas mais utilizadas para se calcular a disponibilidade de um sistema S o mostrados 17 Os principais tipos de disponibilidade que podem ser requeridos em um sistema e os principais tipos de falhas que podem ocorrer Ao final do cap tulo s o apresentadas as fases da toler ncia falhas O cap tulo 4 apresenta as principais ferramentas que podem ser utilizadas em conjunto com o sistema operacional Linux na cria o de um ambiente de alta disponibilidade e o cap tulo 5 descreve os testes de valida o que foram realizados em um laborat rio Ao fim o cap tulo 6 apresenta o estudo de caso da transportadora Levatudo Log stica Ltda onde foi implementado um ambiente de alta disponibilidade utilizando as ferramentas es tudadas neste trabalho 18 2 INTRODU O AOS CLUSTERS Este cap tulo visa a compreens o de uma das reas da Tecnologia da Informa o TI que trata do agrupamento de computadores ou clusters A se o 2 1 apresenta as caracter sti cas do software livre Em seguida o conceito de cluster apresentado de forma mais detalha
74. o02 itflex local uuid changed to nodoO1 itflex local nodename nodoO1 itflex local uuid changed to nodoO2 itflex local Figura 21 Mensagem de erro ao iniciar o Heartbeat Fonte O Autor Foi constatado que durante a instala o o Heartbeat gera um arquivo que o identifica dentro do cluster ou seja em cada nodo esse arquivo tem de ser diferente Pelo fato serem c pias em ambos os nodos o arquivo era o mesmo o Heartbeat apontava a inconsist ncia e avisava que isso poderia at ser uma tentativa de ataque Para resolver o problema foi neces s rio apagar o arquivo var lib heartbeat hb_uuid Ao iniciar o servi o o Heartbeat criou um novo arquivo e o passou a operar normalmente Foi utilizado o aplicativo tcpdump para monitorar os pacotes que passam pela interface de rede Atrav s do tcpdump foi poss vel visualizar o comportamento do Heartbeat em algumas situa es A Figura 22 mostra os pacotes dos heartbeats ou seja a comunica o feita entre os nodos que verifica se est o ativos ou n o O nodo01 e o nodo02 atrav s de broadcast 62 enviam pacotes de cerca de 180 bytes que saem da porta 32770 com destino a porta 694 UDP ha cluster ha cluster ha cluster ha cluster ha cluster ha cluster ha cluster Figura 22 Pacotes dos heartbeats Fonte O Autor Em seguida foram gravados alguns arquivos no compartilhamento PUBLICO do servidor samba Pode ser observado os pacotes replicando as
75. om tica a troca de informa es entre computadores nem o compartilhamento do sistema de arquivos em rede WEBER 2002 Aos poucos surgiram projetos com o objetivo de desenvolver ferramentas que pudessem preencher este espa o deixando o Linux no mesmo n vel das solu es comerciais PEREIRA 2004 O Linux cresceu e hoje reconhecido pela sua estabilidade flexibilidade e robustez aliadas ao baixo custo um dos sistemas operacionais mais usados principalmente em ser vidores A filosofia do software livre tornou se conhecida mundialmente e hoje impulsiona milhares de programadores e empresas de desenvolvimento de aplicativos nas mais diversas reas 2 2 PRINC PIOS DE UM CLUSTER Do ingl s cluster significa grupo de coisas do mesmo tipo ou semelhantes juntar se agrupar se PARKER 2007 O autor Pitanga 2002 p 12 diz que quando voc utiliza dois ou mais computadores em conjunto para resolver um problema voc tem um cluster O autor Pereira 2004 p 5 descreve da seguinte maneira Um cluster ou aglomerado uma cole o de computado res que trabalham juntos para criar um sistema mais po deroso ou um conjunto de m quinas independentes que cooperam umas com as outras para atingir um determinado objetivo comum 20 Caracteriza se por cluster o ambiente que oferece um recurso computacional por meio de v rios computadores interligados por uma rede que s o vistos pelos usu rios aplicativos e out
76. os de auditoria sobre as mensagens antivirus antispam e FTP No decorrer do projeto foram disponibilizados tamb m o portal de espa o do cliente al m de um novo m dulo do TCtran o STwap j comentados anteriormente O STwap um aplicativo desenvolvido usando as tecnologias de programa o Java a tecnologia de co munica o Protocolo de Aplica es sem Fio Wireless Application Protocol WAP que permite aos motoristas intera o com o TCtran atrav s de um aparelho de telefone celular O aplica tivo permite que os motoristas d em baixa nas mercadorias entregues em poucos minutos a informa o atualizada no TCtran e permite que os clientes saibam que sua mercadoria foi entregue atrav s do portal do cliente c servidor Windows Terminal instalado na DMZ e dedicado ao TCtran onde todas as filiais acessam o aplicativo instalado nele atrav s da VPN Este servidor usa o sistema operacio nal Microsoft Windows 2003 Server Terminal Server Edition Em hor rios de pico como quando feito o faturamento por exemplo chega a ter 60 usu rios simult neos conectados d servidor de banco de dados instalado na LAN este servidor disponibiliza o SGBD sistema gerenciador de banco de dados Micrsoft SQL Server 2005 que utilizado pelo TCtran Al m do banco de dados esta m quina utilizada tamb m como servidor de arquivos da rede A segunda etapa do projeto tratou da contrata o dos enlaces de Internet Como a rees trut
77. os presentes em um ambiente de alta disponibilidade existem as t cnicas que tratam do comportamento destes componentes nas mais diversas situa es As t cnicas apresentadas neste cap tulo se aplicadas correta mente e utilizadas em conjunto com boas ferramentas permitem que se consiga toler ncia a falhas Isso proporciona o aumento na qualidade e confiabilidade de um sistema 46 4 FERRAMENTAS PARA CRIA O DE UM AMBIENTE DE ALTA DISPONIBILIDADE Este cap tulo apresenta alguns aplicativos e ferramentas auxiliares que permitem a cri a o de um ambiente de alta disponibilidade Ser o enfatizados o Heartbeat que permite que Os recursos sejam migrados de um nodo falho para um nodo operante e o DRBD que permite que uma parti o de dados seja espelhada via rede 4 1 COMO SURGIU O PROJETO LINUX HA O Heartbeat um aplicativo que faz parte do projeto Linux High Availability LINUX HA O projeto LINUX HA foi iniciado em 1997 pelo ent o funcion rio da Bell Labs Harald Milz O projeto previa a cria o de aplicativos que permitissem montar um ambiente de alta disponibilidade usando o sistema operacional Linux pois nativamente o Linux n o possui estas caracter sticas Na poca Milz pesquisava o sistema operacional Linux como plataforma para desenvolvimento de aplica es e uma das suas tarefas era estudar a capacidade que o Linux tinha em trabalhar com aplica es de alta disponibilidade Foi ent o que ele criou e disponi
78. p isso chamado de configura o ativo passivo Se os dois est o configurados para prover servi os de alta disponibilidade e cada um atua fazendo failback recupera o da falha para o servi o falho do outro isso conhecido como configura o ativo ativo Em um ambiente ativo passivo o Heartbeat utiliza a fun o de iptakeover para migrar de um nodo para outro o IP virtual Antes este processo era executado por um script separado Nas vers es mais recentes o pr prio Heartbeat executa este processo O Heartbeat permite que o administrador escolha como a recupera o de falha ser tratada Se a op o de autofailback estiver ativada os recursos migrar o automaticamente para o nodo principal quando ele estiver dispon vel Esta op o deve ser usada caso o clusters seja do tipo ativo ativo O Heartbeat permite que o administrador seja notificado por email quando ocorrer o failover ou failback no clusters O Heartbeat implementa atrav s de plugins comunica o sobre diferentes tipos de mi dia que atualmente inclui unicat multicast e broadcast al m da comunica o atrav s de porta serial N o h limite quanto ao n mero de diferentes tipos de meios de comunica o que podem ser usados O Heartbeat nativamente n o tem disp e de um m dulo que permita o monitoramento de recursos nos nodos do clusters Isto pode ser feito atrav s de um watchdog que um m dulo baseado em hardware ou aplicativo que tem como fun
79. para conectar o nodo prim rio aos nodos secund rios prov redund ncia para as mensagens de controle do Heartbeat al m de ser um dos requisitos para a elimina o dos pontos nicos de falha Os dois caminhos f sicos n o precisam ser do mesmo tipo Um clusters pode ser montado usando uma conex o Ethernet por exemplo e uma serial Os servi os s o disponibilizados em um IP que configurado em uma interface virtual conforme a Figura 12 Sempre que os recursos s o migrados de um nodo para outro a confi gura o da interface virtual tamb m o acompanha Isso torna o processo de migra o failover transparente para o usu rio Os clientes que acessam os recursos do cluster geralmente usam o protocolo ARP Addess Resolution Protocol para descobrir qual o endere o MAC endere o f sico da placa de rede e o armazenam em uma tabela no sistema operacional conhecida como tabela ARP Por m no momento em que ocorre o failover o IP virtual do cluster passa a ter outro endere o MAC neste caso o endere o MAC da placa de rede do nodo secund rio Para garantir que os clientes acessem o servidor correto o Heartbeat usa uma t cnica conhecida como GARP Gratuitous ARP broadcasts Essa t cnica consiste em for ar a atualiza o da tabela ARP nos clientes atrav s de broadcast KOPPER 2005 49 Usuarios eth0 0 192 168 0 3 NODO primario NODO secundario ethO 192 168 0 1 ethO 192 168 0 2 Figura 12 Uso da interf
80. posta por 32 caracteres no formato hexadecimal Il SHA1 conhecido tamb m como Secure Hash Algorithm 1 definido pela RFC 2104 e usa uma chave de 160 bits para assinar os pacotes Aos poucos o SHA 1 est substi tuindo o MDS por proporcionar uma criptografia mais forte Ill crc o metodo mais inseguro pois n o usa criptografia Geralmente nos clusters de alta disponibilidade usado para fazer checar e detectar altera es que possam ter ocorrido nos pacotes ao longo do caminho A Figura 13 mostra a sintaxe para os tr s algoritmos O arquivo composto por duas linhas A primeira deve conter a palavra auth seguida de um n mero A segunda linha deve conter este mesmo n mero seguida do algoritmo e de uma senha A exce o fica por conta do algoritmo CRC que por n o usar criptografia n o necessida de senha marcelo canoeh ha dJ cat authkeys Algoritmo CRC auth 1 1 cre Algoritmo SHA 1 auth 1 1 shai senha Algoritmo 5 auth 1 1 md5 senha Figura 13 O arquivo de configura o etc hd d authkeys Fonte O Autor etc hd d haresources especifica qual ser o nodo prim rio e quais recursos ele estar disponibilizando A Figura 14 segue um exemplo do arquivo de configura o marcelo canoeh ha dJ cat haresources nodo01 itflex local IPaddrZ2 192 168 200 203 24 eth0 0 nodo01 itflex local drbddisk rO0 Filesystem dev drbdO rede ext3 nodo01 itflex local smb Figura
81. pts com resources reliability resnick HA htm gt Acesso em 28 mar 2007 ROBERTSON A The evolution of the Linux HA project Austin Artigo publicado pela IBM 2004 SANTOS A C Toler ncia a falhas para sistemas embarcados Recife Monografia apresentada na UFPE 2000 SCHIOZER D J Computa o paralela aplicada simula o num rica de reservat rios Campinas Monografia apresentada na Unicamp 1997 STALLMAN R The Free Software Definition 2007 Free Software Fundation Dispon vel em lt http www fsf org licensing essays free sw html gt Acesso em 08 abr 2007 TESTONI A G S Solu es RAID para preven o de falhas ocorridas em discos r gidos de computador Joinville Monografia apresentada no IST 2005 TOSATTI M High Availability 2006 Artigo publicado pelo Kernel Newbies Dispon vel em lt http kernelnewbies org Documents HighAvailability gt Acesso em 08 jan 2007 VARGAS E High Availability Fundamentals Palo Alto SUN 2000 VOGELS W e a The design and architecture of the Microsoft Cluster Service Piscataway Artigo publicado pelo IEEE 1998 83 WATSON M e a High Availability on the RISC System 6000 Family Austin IBM 1995 WEBER T S Um roteiro para explora o dos conceitos b sicos de toler ncia a falhas Porto Alegre Artigo publicado na UFRGS 2002 WIKIPEDIA Computer cluster 2006 Wikipedia Dispon vel em lt http en wikipedia org wiki ARCnet gt Ac
82. r 31 16 14 10 INFO IPaddr2 Success Mar 31 16 14 10 info Running etc ha d rc d ip request resp ip request resp Mar 31 16 14 10 received ip request resp drbddisk r0 OK yes Mar 31 16 14 10 info Acquiring resource group nodo01 itflex local drbddisk r0 Filesystem dev drbd0 rede ext3 Mar 31 16 14 11 info Running etc ha d resource d drbddisk r0 start Mar 31 16 14 11 INFO Running status for dev drbdO on rede Mar 31 16 14 11 INFO rede is unmounted stopped Mar 31 16 14 11 INFO Filesystem Resource is stopped Mar 31 16 14 11 info Running etc ha d resource d Filesystem dev drbdO rede ext3 start Mar 31 16 14 11 INFO Running start for dev drbdO on rede Mar 31 16 14 12 INFO Filesystem Success Mar 31 16 14 12 info Running etc ha d rc d ip request resp ip request resp Mar 31 16 14 12 received ip request resp smb OK ves Mar 31 16 14 12 info Acquiring resource group nodo01 itflex local smb Mar 31 16 14 12 info Running etc init d smb start Mar 31 16 14 12 smb in cio de smbd succeeded Mar 31 16 14 12 smb in cio de nmbd succeeded Figura 27 Momento em que o nodo01 assume os servi os Fonte O Autor 65 O que ocorreu foi que o nodo02 n o assumiu Este comportamento ocorreu porque mesmo com o servi o estando parado a comunica o entre os dois nodos continuava funcio nando ou seja os nodo01 continuava recebendo os heartbeats do nodo02 e vice versa fazendo o Heartbeat entender que estava tudo nomal com
83. r a disponibilidade das informa es a maior parte do tempo poss vel de modo que a qualquer momento possam ser acess veis pelas 76 filiais ou pelos clientes Indisponibilidade pode ser sin nimo de caminh es parados e preju zos A Figura 32 mostra a disponibilidade do firewall cluster do dia 01 01 2007 at 27 05 2007 Houve um momento em que ambos os nodos falharam ficando fora do ar por cerca de tr s horas Isso mostra que a disponibilidade at o dia 27 era de 99 8 State History For Host fu Aria Mon Jan 1 01 00 00 2007 to Sun May 27 17 03 36 2007 Up Down Unreachable Indeterminate fh PhP PP DJ JJ Jd SO09090090090900000000000009000000000000000006 gt lt lt lt lt lt lt lt OSC CO COCO o N SONO SDODDOSDDSDSOCND a a DEED DO O S Ss coo ine be Ga ae Ga SOOL Se ae as CD
84. r sempre ser visto como srvcluster 5 2 A realiza o dos testes Ap s a configura o do ambiente ter sido conclu da foram feitas as primeiras verifica es para comprovar que os aplicativos Heartbeat e DRBD estavam funcionando de acordo com o esperado 61 resource rO protocol C startup wfc timeout 180 3 minutos degr wfc timeout 180 3 minutos disk on io error detach syncer rate 10M Taxa de transfer ncia maxima on nodoO 1 itflex local device fdev drbdo disk dev hda4 address 192 168 200 201 7788 meta disk internal on nodo02 itflex local device dev drbd0 disk dev hda4 address 192 168 200 202 7788 meta disk internal Figura 20 Configura o do DRBD em etc drbd conf Fonte O Autor O primeiro problema encontrado ocorreu devido ao disco do nodo02 ter sido clonado apartir do nodo01 A Fgiura 21 mostra erro tentar iniciar o Heartbeat O servi o n o era carregado e o arquivo de registro do sistema o var log messages apresentava um erro nodo6l nodo 1 nodo6l nodo62 nodo62 nodo62 heartbeat heartbeat heartbeat heartbeat heartbeat heartbeat should drop message attempted replay attack nodo02 itflex local nodename nodo02 itflex local uuid changed to nodoO1 itflex local nodename nodoO1 itflex local uuid changed to nodoO2 itflex local should drop message attempted replay attack nodo 2 itflex local nodename nod
85. rbd 815336 win 16652 lt timestamp 34944957 1048976457 gt gt gt 192 168 200 201 drbd ack 822128 win 16652 lt nop nop timestamp 34944958 1048976457 gt Figura 24 Pacotes de confirma o Fonte O Autor 5 3 Teste 1 for ando o nodo01 a entrar no modo de espera O pacote do Heartbeat traz alguns scripts que permitem algumas funcionalidades extras ao aplicativo Um deles o hb standby localizado em usr lib heatbeat hb standby Este script for a os recursos a migrarem para o servidor secund rio Foi o primeiro teste para verificar se o recurso de failover estava funcionando corretamente Conforme pode ser observado na Figura 25 o nodo02 reconhece que o nodo01 quer deixar de ser principal e assumir o a fun o de secund rio Ent o todos os servi os disponi 63 biliados no nodo01 s o parados executado o processo de iptakeover e garp atualiza o da tabela ARP dos clientes Em seguida os servi os s o disponibilizados no nodo02 heartbeat info nodo 1 itflex local wants to go standby all heartbeat info standby acquire all resources from nodo 1 itflex local eartbeat info acquire all HA resources standby ResourceManager info Acquiring resource group nodo 1 itflex local IPaddr2 192 168 200 203 24 etho 0 IPaddr2 INFO IPaddr2 Resource is stopped ResourceManager info Running etc ha d resource d IPaddr2 192 168 200 203 24 eth0 0 start IPaddr2 INFO sbin ip
86. rdada a alta disponibilidade e toler ncia falhas em que foram apresentados os principais termos e classifica es usadas muito importante que a parte te rica de alta disponibilidade seja bem definida pois nessa rea mui tos termos iguais s o utilizados para conceitos diferentes Com os conceitos definidos foram analisadas e testadas as ferramentas que permitem a cria o de um ambiente de alta disponi bilidade A parte te rica dos cap tulos 2 e 3 foi fundamental para que se pudesse compreender o funcionamento e durante os testes entender o comportamento dos aplicativos apresentados no cap tulo 4 As solu es comerciais de alta disponibilidade geralmente implicam em altos investi mentos pois no momento em que feita a compra o cliente paga por um pacote o que acaba por deix lo sem op o de escolha ou seja o cliente obrigado a comprar o hardware os apli cativos e o servi o do mesmo fornecedor para garantir que seu problema possa ser resolvido O sistema operacional Linux por outro lado permite a cria o solu es de alta disponi bilidade utilizando hardware simples aplicativos livres de f cil implementa o e que podem ser utilizados em conjunto com outras aplica es Tanto o Heartbeat quanto o DRBD atenderam as expectativas durante a implementa o Atualmente estas solu es v m sendo utilizadas em diversas reas e t m tomado o espa o das solu es comerciais n o somente por ter um bai
87. res tempo m dio entre a ocorr ncia das falhas MTTR mean time to repair tempo m dio para reparo do sistema Fonte Pereira 2004 p 18 Com base na equa o anteriormente apresentada na tabela 3 PEREIRA 2004 mos tra algumas medidas de disponibilidade e na tabela 4 alguns sistemas e a disponibilidade por eles exigida Por exemplo para computadores pessoais o tempo que podem ficar fora do ar durante um ano de cerca de 36 5 dias J para sistemas de defesa militar o tempo m ximo aceit vel de 31 5 segundos 34 Tabela 3 Medidas de Disponibilidade C digo Uptime Downtime Downtime por ano Downtime por semana 1 90 10 36 5 dias 16 horas 51 minutos 2 98 2 7 3 dias 3 horas 22 minutos 3 99 1 3 65 dias 1 hora 41 minutos 4 99 8 0 2 17 horas 30 minutos 20 minutos 10 segundos 5 99 9 0 1 8 horas 45 minutos 10 minutos 5 segundos 6 99 99 0 01 52 5 minutos 1 minuto 7 99 999 0 001 5 25 minutos 6 segundos 8 99 9999 0 0001 31 5 segundos 0 6 segundos Fonte Pereira 2004 p 19 3 2 Dependabilidade O objetivo da toler ncia a falhas alcan ar a dependabilidade WEBER 2002 O termo caracteriza se por entregar um servi o de maneira confi vel ou seja quem interage com o sistema espera que ele funcione de maneira adequada A dependabilidade mede a qualidade de servi o e a confian a depositada nele Alguns atributos pode
88. res SPOF s fundamental para o alcance da alta disponibilidade Sistemas que apresentam falhas fazem parte do dia a dia WATSON 1995 Segundo Pereira 2004 p 38 toler ncia falhas quando um sistema pode mascarar a presen a de falhas Tomando novamente o exemplo com a ponte considerando que houve um acidente a reo e que a ponte foi comprometida Um avi o chocou se contra os pilares de sustenta o e a estrutura toda veio a baixo Se a ponte for o nico meio de se atravessar o rio pode se entender que ela um SPOF pois neste caso n o ser mais poss vel fazer a travessia Por outro lado se existir outra ponte ou uma balsa que permita fazer a travessia pode se dizer que o sistema apresenta redund ncia e tolerante a falhas A Figura 5 mostra que a ponte do lado direito veio abaixo e como redund ncia a ponte do lado esquerdo est sendo usada permitindo assim que o autom vel fa a a travessia Figura 5 Exemplo de redund ncia Fonte O Autor Quanto maior o n vel de redund ncia entre os equipamentos envolvidos maior ser o n vel de disponibilidade Os SPOFs n o se restringem somente aos recursos de m quina mas tamb m fonte de fornecimento de energia el trica ativos de rede e localiza o f sica dos equipamentos Por exemplo para evitar que um servidor fique indispon vel em uma situa o em que houver falta de luz importante que al m de nobreak possua duas fontes distintas de for
89. ro interfaces de rede Al m disso existem 2 switches um para a liga o dos enlaces nas interfaces WAN e outro para liga o dos servidores que est o na DMZ A Figura 31 ilustra o ambiente do cluster depois de pronto Das nove filiais na poca que foi iniciado o projeto somente duas tinham firewall e n o tinham nenhuma rela o com a matriz Atualmente sete delas j possuem firewall semelhante ao da matriz que al m da prote o disponibilizam os servi os de DHCP proxy VPN e Qos permitindo assim que as filiais fechem um t nel de comunica o segura com a matriz atrav s da Internet e proporcionando um acesso r pido ao sistema 6 4 OS RESULTADOS ALCAN ADOS Para que fosse realizada toda essa mudan a que atingiu a matriz e filiais a Levatudo Lo g stica Ltda fez um investimento alto Por m as melhorias e os benef cios puderam ser sentidos logo no in cio centraliza o os novos servidores de banco de dados e do aplicativo TCtran permitiram a centraliza o das informa es em um nico banco de dados elimitando completamente as inconsist ncias que ocorriam anteriormente com os arquivos de troca e o processo de importa o manual Atrav s da VPN todas as filiais acessam a mesma base de dados o que permite um acompanhamento em tempo real das atividades que acontecem na empresa como por exemplo faturamento sa da de caminh es e entregas 75 Roteador BrTelecom 200 217 200 217 s0 200 100 20
90. roblemas com hardware As consequ ncias podem ser as mais diversas desde a perda de dados comprometi mento do neg cio da empresa e at mesmo a perda de vidas humanas PEREIRA 2004 O mercado atualmente oferece v rias solu es que permitem a cria o de uma infraes trutura redundante Fabricantes de hardware e desenvolvedores de software agregam a seus produtos caracter sticas que permitem que os recursos computacionais continuem funcionais mesmo que algum componente envolvido apresente uma falha A alta disponibilidade pode ser alcan ada de duas formas por meio do uso de hardware propriet rio fabricado exclusivamente para esse fim ou por meio do uso de hardware comum em conjunto com aplicativos espec ficos TOSATTI 2006 Este trabalho apresenta um estudo baseado no uso de hardware comum em conjunto com aplicativos conhecidos como software livre os quais podem ser utilizados sem que seja necess rio o pagamento por uma licen a de uso como ocorre com aplicativos comerciais O hardware comum e os softwares livres implementados em conjunto permitem a cria o de um ambiente de alta disponibilidade O cap tulo 2 apresenta as caracter sticas que tornam o sistema operacional Linux fle x vel e possibilitam us lo para solucionar problemas nas mais diversas reas A seguir s o apresentadas algumas defini es para o termo cluster e apresentados os conceitos abstratos que est o relacionados eles Este cap tul
91. root nodoOZ logl modprobe r drbd FATAL Module drbd is in use root nodo02 logit J Figura 29 Tentando matar o processo do DRBD Fonte O Autor O processo n o deixa ser finalizado atrav s de nenhuma das formas Essa uma prote o da aplica o para evitar a inconsist ncia dos dados 5 8 Teste 6 outras verifica es Outros testes executados que tiveram o mesmo resultado foram a for ar a finaliza o do processo do Heartbeat atrav s do comando killall 9 heartbeat b desconectar o cabo de rede do servidor c retirar o cabo de energia do servidor Em todas estas situa es n o houve mais nenhum tr fego gerado pelo Heartbeat em execu o no outro nodo Assim o nodo que permaneceu ligado entendeu que alguma coisa havia acontecido com a outra m quina e passou a disponibilizar os servi os 67 5 9 CONCLUSAO Os testes proporcionaram uma melhor compreens o sobre o funcionamento dos aplica tivos e no geral os resultados foram satisfat rios Tabela 7 Resultados dos testes Teste Resultado satisfat rio For ando o nodo01 a entrar no modo de espera SIM Nodo prim rio e secund rio no ar simult neamente SIM Finalizar o daemon do samba no nodo prim rio N O Nodo02 assumindo SIM Finalizar processo do DRBD no nodo ativo SIM Outras verifica es SIM Fonte O Autor Por m em duas situa es os aplicativos poderiam ter tratado de maneira diferente sincronismo
92. ros servidores como um recurso nico Al m disso os usu rios n o devem saber que est o usando um cluster e os demais servidores n o devem saber que est o se comunicando com um cluster KOPPER 2005 Segundo Kopper 2005 p 3 as quatro caracter sticas b sicas de um cluster s o os usu rios n o saberem que est o usando um cluster Il os computadores n o saberem que eles fazem parte do cluster Ill as aplica es em execu o n o saberem que fazem parte de um cluster IV demais computadores que comp e o cluster tem que ser vistos como clientes co muns A Figura 1 mostra um cluster formado por quatro computadores comuns Eles estao interligados atrav s de um switch e compartilham um dispositivo de armazenamento Internet Dispositivo de armazenamento Figura 1 Cluster de quatro computadores Fonte O Autor adaptado de Pereira 2004 p 6 21 Estas sao as caracteristicas de um sistema de imagem Unica ou seja idependente do cluster ser composto por v rios computadores interligados toda a comunica o distribui o de tarefas e sincroniza o de informa es devem ser transparentes para o usu rio O cluster deve comportar se como um sistema centralizado FAUSTINO 2006 Redes de esta es de trabalho n o podem ser consideradas como cluster pois cada esta o trabalha de forma aut noma o que n o caracteriza um sistema de imagem nica A utiliza o dos clusters permite qu
93. s necess rio que seja feita a sincroniza o dos discos Todos os nodos devem es tar com os discos sincronizados em rela o ao principal pois isso possibilitar que um deles assuma caso o principal falhe No DRBD o processo de sincroniza o foi implementado de modo a n o afetar o desem penho do clusters A opera o executada em segundo plano e permite que o administrador estabele a qual a largura de banda m xima que pode ser usada na rede para o processo de sincronismo REISNER 2002 Nas primeiras vers es do DRBD sempre que um nodo voltava a fazer parte do clusters era feito um sincronismo completo entre os dispositivos DRBD Isso era problem tico pois du 57 rante o per odo em que o clusters fazia sincronismo se o principal falhasse os dados no nodo secund rio estariam inconsistentes Nas novas vers es o sincronismo implementado atrav s de um algoritmo conhecido como active logging O sincronismo geralmente feito atrav s de uma conex o de rede dedicada ao DRBD Uma conex o gigabit entre os nodos do clusters uma boa op o neste caso Isso evita congestionamento na interface de rede dedicada aos usu rios Se um nodo entra no clusters pela primeira vez todos os blocos precisam ser copiados para os nodos secund rios que est o no modo de espera Esse processo conhecido como sincronismo completo Se um nodo apenas deixa o clusters por um certo per odo de tempo necess ri
94. s de alta disponibilidade at o uso do cluster depois de tudo pronto 5 1 montagem do ambiente Para a montagem do cluster foram usados dois computadores com as mesmas configu ra es Cada um tem seu endere o IP real usado para a comunica o dentro do cluster Al m disso o Heartbeat controla outro endere o IP neste caso 192 168 200 203 que atribu do ao nodo que est ativo no momento atrav s de uma interface de rede virtual chamada de eth0 0 por meio deste endere o tamb m que os usu rios acessam os recursos disponibilizados no cluster AMD Duron 1200 AMD Duron 1200 512 MB RAM 512 MB RAM HD 40GB HD 40GB CentOS Linux 4 4 CentOS Linux 4 4 Kernel 2 6 16 Kernel 2 6 16 Heartbeat 2 0 7 Heartbeat 2 0 7 DRBD 0 8 DRBD 0 8 s srvcluster itflex local Samba 2 0 23 Samba 2 0 23 g eth0 0 192 168 200 203 nodo01 itflex local eth0 192 168 200 201 Us Usuarios HighAvailability nodo02 itflex local eth0 192 168 200 202 q Figura 17 Cluster do ambiente de testes Fonte O Autor 59 5 1 1 A configura o dos aplicativos Depois de conclu da a etapa de montagem dos nodos foram feitas as configura es no sistema operacional Linux e nos aplicativos Heartbeat e DRBD a Heartbeat o primeiro passo foi obter a ltima vers o dos pacotes no portal do apli cativo e
95. stema por isso de extrema import ncia que os recursos sejam monitorados e verificados de modo que as falhas possam ser corrigidas e o sistema opere conforme sua especifica o OYAMADA 2003 O ideal seria que todos os erros fossem detectados e tratados mas isso acarretaria numa carga de trabalho muito grande e tornaria se inviavel Portanto somente os componentes que podem causar erros de grande impacto devem ser considerados Segundo Pereira 2004 p 30 algumas propriedades devem ser levadas em conta antes de se definir o que sera verificado a a verifica o deve ser baseada somente na especifica o do sistema tens que fujam da especifica o devem ser ignorados b a verifica o deve ser completa e correta ou seja todos os poss veis erros que pos sam ocorrer devem ser detectados e verificados c a verifica o deve ser independente do sistema que est sujeito a falhas pois as ve rifica es tamb m podem falhar e n o se deseja que uma falha na verifica o seja relacionada ao sistema que est sendo verificado O conhecimento pr vio da implementa o do sistema pode ser bastante til na esco lha das verifica es a serem executadas As verifica es podem ocorrer de v rias formas dependendo do sistema e dos erros de interesse Os principais tipos s o por replica o tem porizadas estruturais de coer ncia e de diagn sticos a verifica es por replica o este tipo de
96. t ativo at que ele responda os heartbeats em pelo menos uma das interfaces OYAMADA 2003 A Figura 11 ilustra melhor esta situa o atrav s das tr s conex es entre os servidores A primeira vers o do Heartbeat era muito simples pois permitia somente a troca de heatbeats atrav s de interface serial As vers es posteriores permitiram que o Heartbeat exe cutasse scripts no nodo backup quando o prim rio falhasse e que as mensagens de controle do Heartbeat entre os dois nodos tamb m fosse feita atrav s das interfaces de rede A limita o de dois nodos n o foi mais problema apartir da vers o 2 0 que passou a suportar clusters com at 16 nodos ROBERTSON 2004 48 Heartbeats Servidor Servidor Secundario Primario Cabo Ethernet Crossover Cabo Serial Figura 11 Arquitetura do Heartbeat Fonte O Autor adaptado de Kopper 2005 p 112 comunica o via cabo serial mais segura do que uma conex o Ethernet pois atrav s dela o invasor nao conseguir abrir uma sess o Telnet ou Secure Shell SSH por exemplo A limita o fica por conta do comprimento do cabo que segundo a norma EIA 232 nao pode passar de 15 24 metros fazendo com que os servidores tenham que ficar no mesmo espa o f sico KOPPER 2005 A conex o Ethernet por sua vez elimina os problemas com a dist ncia Ela permite tamb m que o sistema de arquivos seja sincronizado entre os nodos do clusters Usando dois caminhos f sicos
97. ta simult neamente Para isso necess rio utilizar um sistema de arquivos compartilhado tal como Sistema de Arquivos Global Global File System GFS ou Sistema de Arquivos Oracle vers o 2 Oracle Cluster File System version 2 OCFS2 por exemplo Eles s o capazes de gerenciar a trava ou seja permitir acesso exclusivo ao arquivo de maneira global ao sistema de arquivos garantindo assim a integridade dos dados Sistemas de arquivos comuns tais como ext3 reiserfs ou xfs n o devem ser usados com o DRBD neste tipo de opera o Por m apenas um nodo por vez fazendo o acesso leitura escrita j suficiente para o failover usual de um clusters de alta disponibilidade Apesar do m dulo do DRBD j fazer parte de algumas distribui es do sistema operacional Linux nativamente geralmente o pacote DRBD precisa ser obtido na internet e deve ser compilado e instalado a parte pois originalmente seu m dulo DRBD n o faz parte do kernel padr o do sistema operacional Linux O DRBD usa a mesma sem ntica de um dispositivo compartilhado mas ele n o neces sita de nenhum hardware incomum por trabalhar sobre redes que usam o protocolo TCP IP as quais t m um custo de implementa o menor se comparado com sistemas de armazena mento especial Isso permite por exemplo que o DRBD seja usado em redes geograficamente afastadas MUSSI 2007 Se o nodo prim rio falhar o Heartbeat permutar o dispositivo secund rio em prim rio e inic
98. ter ou seja esta belece sincronismo de processos entres os nodos Para que exista sincronismo s o estabelecidas barreiras as quais todos os nodos devem alcan ar para depois iniciar o processo de chegada na pr xima Se um nodo alcan ar uma barreira antes dos demais 30 ele aguarda at que todos os nodos cheguem no mesmo ponto antes de dar sequ ncia no processamento IV servi o de nomes uma estrutura hier rquica atrav s da qual um nodo pode registrar nomes e os processos podem consultar ou definir depend ncias baseadas nestes nomes 2 7 CONCLUS O Este cap tulo apresentou os conceitos b sicos relacionados aos clusters Pode se con cluir que sistema operacional Linux oferece diversas vantagens em rela o s solu es proprie t rias de cluster entre elas o fato de poder se utilizar hardware comum e utilizar aplicativos sem custo de licenciamento que proporciona uma grande economia para as empresas e de ter seu c digo fonte dispon vel o que permite que empresas que tenham alguma necessidade muito espec fica possam utilizar o c digo j dispon vel e adapt lo criando desta forma uma solu o para o seu problema Al m disso a proposta do OCF torna mais simples os processos de melhoria e desen volvimento de novas ferramentas para uso nos ambientes de clusters pois s o desenvolvidas seguindo os mesmos conceitos o que poupa trabalho e garanta uma maior compatibilidade entre estas solu es
99. ura o foi feita pensando em redund ncia optou se por contratar dois enlaces de Internet de operadoras distintas Foi calculado que cada conex o ao terminal server consumiria cerca de 16Kbps de banda podendo chegar a 70 conex es simult neas ou seja seria necess rio cerca de 1Mbps somente para o sistema Foram levados em conta tamb m o prazo de atendimento por parte da operadora no caso de falhas com o enlace largura e garantia de banda e tamb m o custo mensal do servi o Dentre as propostas apresentadas foram escolhidas duas a Operadora Brasil Telecom enlace dedicado e redundante de 2Mbps com banda ga rantida de 50 e 8 endere os IPs 6 v lidos O enlace da operadora Brasil Telecom endere o da rede 200 100 20 176 29 roteador Cisco 2600 200 100 20 177 fwl levatudo net 200 100 20 178 fw2 levatudo net 200 100 20 179 mail levatudo net 200 100 20 180 wts levatudo net 200 100 20 181 fw levatudo net 200 100 20 183 b Operadora GVT enlace ADSL empresarial de 1Mbps com 1 endere o IP v lido 73 O enlace da Brasil Telecom chega em duas fibras ticas que percorrem caminhos dife rentes da operadora at a transportadora Caso uma fibra falhe a outra pode ser usada Na verdade como se fossem dois enlaces diferentes mas usando a mesma faixa de IPs O con trato firmado com a operadora prev que o prazo de reparo para problemas que possam ocorrer com o enlace de 4 horas teis O enlace da
100. usters de alto desempenho HPC 25 2 5 2 Clusters de alta disponibilidade HAC 26 2 5 3 Clusters de balanceamento de carga LBC 27 2 6 ARQUITETURA DOS CLUSTERS sus esa E Epa E aerea Bongo Bet E rd E 27 27 CONCLUS O nei ak Bah ek NE q a A Ge gl 30 3 ALTA DISPONIBILIDADE 31 3 1 OS PRINC PIOS DA ALTA DISPONIBILIDADE 31 3 1 1 Como medir a disponibilidade 33 3 2 Dependabilidade 34 3 2 1 Confiabilidade 35 3 2 2 Disponibilidade ernis ole Gets SR ee eee RG a i 35 SS aten oie tale mpa ale Te oie eee a 36 3 3 CLASSIFICA ES DOS CLUSTERS DE ALTA DISPONIBILIDADE 36 3 3 1 Disponibilidade b sica basic availability BA 3 3 2 Alta disponibilidade high availability HA 3 3 3 Disponibilidade continua continous availability CA 3 3 4 Dominios de disponibilidade 3 3 5 Replica o passiva e ativa 34 DEFEITOS ERROS E FALHAS usa EE QE E 3 4 1 O modelo de tr s universos 2 2 ee 3 4 2 A classifica o das falhas 2 a 3 5 FASES DA TOLER NCIA A FALHAS 3 5 1
101. veis node recebem o nome dos nodos que comp e o cluster b DRBD foi utilizada a vers o 0 8 que teve de ser compilada para gerar o m dulo de acordo com a vers o do kernel em uso Este m dulo respos vel pela comunica o entre o dispositivo DRBD e os aplicativos O particionamento dos discos em ambos os nodos foi feito da conforme a Figura 19 dev hda dev hda1 boot dev hda2 swap dev hda3 dev hda4 drbdO HD 40GB IDE Figura 19 Parti o do disco nos nodos Fonte O Autor A Figura 20 mostra a configura o do DRBD Optou se pelo protocolo C por ser mais seguro Foi definido tamb m que a parti o dev hda4 faria parte do dispositivo DRBD neste caso dev drbd0 os IPs dos nodo e a taxa de transfer ncia m xima que poderia ser usada durante o sincronismo das parti es A parti o dev drbd0 foi formatada usando o sistema de arquivos Terceiro Sistema de Arquivos Third Extended File System EXT3 e o ponto de montagem foi definido em rede O controle tamb m fica por conta do Heartbeat que monta a parti o no nodo que est ativo no momento Samba na configura o do samba foi criado um compartilhamento chamado publico apontando para a parti o do DRBD montada em rede Na se o global da configura o do aplicativo foi alterada a vari vel netbios name srvcluster em ambos os nodos Assim independente de qual nodo estiver no ar nodo01 ou nodo02 o cluste
102. verifica o muito comum e pode ser im plementada sem que se tenha conhecimento de como o sistema funciona internamente Ela consiste em replicar um componente do sistema geralmente hardware e comparar os resulta dos afim de que se possa detectar os erros b verifica es temporizadas se a especifica o de um componente inclui restri es quanto ao tempo de resposta este tipo de verifica o pode ser aplicada Neste caso feita uma requisi o e o tempo de resposta comparado com o tempo descrito na especifica o do sistema Em clusters de alta disponibilidade a aus ncia da resposta pode indicar a falha de algum componente ou mesmo de um nodo Em um cluster de balanceamento de carga por exemplo o tempo de resposta muito alto pode indicar uma sobrecarga de trabalho 43 c verifica es estruturais para qualquer tipo de informa o dois tipos de verifica o s o poss veis verifica o sem ntica e verifica o estrutural A verifica o sem ntica tenta conferir se o valor consistente com o resto do sistema A verifica o estrutural somente garante que a estrutura dos dados como deveria ser A forma mais comum de verifica o estrutural a codifica o usada em hardware Nela s o aplicados bits extras aos dados de forma que possa ser detectado se existe algum bit corrompido d verifica es de coer ncia determinam se o estado de algum objeto no sistema est coerente como por exemplo
103. xo custo de implementa o mas por se mostrarem bastante flex veis na configura o e robustas durante o uso caracter ticas que s o importantes em um ambiente de alta disponibilidade O nico ponto em que o Heartbeat deixou a desejar foi na quest o de monitoramento de recursos locais mas segundo os desenvolvedores em breve esta caracter stica estar presente O projeto proporcionou uma grande comodidade e satisfa o tanto para a transporta dora que conseguiu melhorar a infraestrutira de TI como um todo quanto para o cliente que atingido tamb m O mercado est cada vez mais competitivo e os clientes cada vez mais exigentes por isso fundamental que a empresa possa oferecer um bom servi o com entregas r pidas e um baixo custo afim de garantir sua posi o no mercado Os recursos implantados nesse projeto para a Levatudo Log stica Ltda representam um passo nessa dire o 78 Para o futuro existe a proposta de montar um cluster para o servidor web pois o mesmo disponibiliza aplica es importantes para a empresa que requerem disponibilidade e existe tamb m a hip tese se se montar um cluster de servidores Windows Atualmente os servi os de banco de dados e o TCtran podem ser disponibilizados no mesmo servidor caso algum falhe por m isso requer interven o de um t cnico Uma das dificuldades encontradas no desenvolvimento do trabalho foi a busca por re fer ncias O tema clusters de alta disponibi

montagem de um ambiente de cluster usando

Contents

Download Pdf Manuals

Related Search

Related Contents