Cluster de Alta Disponibilidade em um Sistema Administrativo Hospitalar

Transcrição

1 Cluster de Alta Disponibilidade em um Sistema Administrativo Hospitalar Julio Cezar Gross Junior 1, Msc. Eduardo Maronãs Monks 1 1 Faculdade de Tecnologia Senac (FATEC) Curso Superior de Tecnologia em Redes de Computadores Rua Gonçalves Chaves, Centro julio.gross@gmail.com, emmonks@gmail.com Resumo. Este artigo tem o objetivo de apresentar uma solução de cluster para um sistema administrativo hospitalar SIS-HOS (Sistema Hospitalar) para garantir alta disponibilidade no funcionamento e apresentar as vantagens que existem neste tipo de cenário. Abstract. This article aims to provide a solution for cluster of a hospital administrative system HOS SIS (Hospital System) in order to ensure high operation availability, and to present the advantages that exist in this type of scenario. 1. Introdução O Hospital Escola da Universidade Federal de Pelotas (UFPEL) deu início a utilização de prontuário eletrônico com a implantação do Software Administrativo Hospitalar SIS-HOS [JME 2012]. Ao longo dos anos de utilização deste software foi detectada a necessidade de criar módulos específicos para cada especialidade que o HE (Hospital Escola) oferecia a comunidade. Portanto, no ano de 2007 foi criado um setor de desenvolvimento de software próprio do HE que começou a criar módulos para substituição do SIS-HOS, restando somente o módulo Internação. Neste módulo encontram-se as principais informações para alimentar os softwares específicos produzidos pelo HE, como nome dos médicos da instituição, nome dos pacientes, motivo da internação e etc. Este módulo encontra-se hoje em um único servidor onde são executados backups periodicamente para garantir a segurança dos dados que são essenciais para o funcionamento do HE. Sendo assim, analisando este cenário, vê-se a necessidade de implantar um cluster de alta disponibilidade proporcionando a redundância dos dados em mais de uma máquina e possibilitando aos técnicos da área de TI um espaço de tempo maior para solucionar problemas que venham a ocorrer. Em caso de ocorrer alguma falha, a configuração em cluster de alta disponibilidade possibilitará a continuidade dos atendimentos e o tempo necessário aos técnicos para recuperar o componente com falhas. 2. Cluster É o nome dado a um sistema montado com mais de um computador, cujo objetivo é fazer com que todo o processamento da aplicação seja distribuído aos computadores, mas de forma que pareça com que eles sejam um computador só [Alecrim 2004]. Com isso, é possível realizar processamentos que até então somente computadores de alta performance seriam capazes de fazer.

2 2.1. Tipos de Cluster Os clusters podem ser usados para uma infinidade de aplicações. Basicamente, para qualquer aplicação que exija alto desempenho, qualquer tipo de aplicação crítica, ou seja, aplicações que não podem parar de funcionar ou não podem perder dados Cluster Beowulf Esse tipo de cluster, voltado à computação paralela, foi proposto em 1994, pela NASA, com a finalidade de processar as informações espaciais que a entidade recolhia [Alecrim 2004]. Desde então, grandes empresas (como HP e IBM) e universidades (como a brasileira Unesp) vêm construindo clusters deste tipo e com cada vez mais nós. De maneira generalizada, o cluster Beowulf permite a construção de sistemas de processamento que podem alcançar altos valores de gigaflop (um gigaflop equivale a 1 bilhão de instruções de ponto flutuante executadas por segundo) Cluster para Alta Disponibilidade Quando se fala de disponibilidade, fala-se do tempo em que determinado sistema permanece ativo e em condições de uso. A alta disponibilidade se refere a sistemas que praticamente não param de funcionar. Este tipo de cluster é usado em aplicações de missão crítica, eles costumam ter meios eficientes de proteção e de detecção de falhas [Alecrim 2004] Cluster para Balanceamento de Carga O balanceamento de carga se refere à distribuição equilibrada de processamento aos nós do cluster. É muito usado na Internet, em servidores de e comércio eletrônico. Neste tipo de cluster, é necessário que haja monitoramento constante da comunicação e mecanismos de redundância. Caso contrário, qualquer falha pode interromper o funcionamento do cluster[alecrim 2004]. 3. Alta disponibilidade Para se entender o conceito de alta disponibilidade faz-se necessário, antes de mais nada, perceber que a alta disponibilidade não é apenas um produto ou uma aplicação que se instale, e sim uma característica de um sistema computacional. Existem mecanismos e técnicas, blocos básicos, que podem ser utilizados para aumentar a disponibilidade de um sistema. A simples utilização destes blocos, entretanto, não garante este aumento se não for acompanhado de um completo estudo e projeto de configuração. A disponibilidade de um sistema computacional é medida por meio da fórmula A(t) [DIMAP 2012], que define a probabilidade (A) de que um sistema esteja oferencendo serviços em um dado instante de tempo (t). Esta disponibilidade pode ser enquadrada em três classes, de acordo com a faixa de valores desta probabilidade. As três classes são: Disponibilidade Básica, Alta Disponibilidade e Disponibilidade Contínua.

3 3.1. Disponibilidade básica A disponibilidade básica é aquela encontrada em máquinas comuns, sem nenhum mecanismo especial, em software ou hardware, que vise de alguma forma mascarar as eventuais falhas destas máquinas. As máquinas nesta classe apresentam uma disponibilidade de 99% a 99,9%. Isto equivale a dizer que em um ano de operação a máquina poderá ficar indisponível por um período de 9 horas a quatro dias. Estes dados são empíricos e os tempos não levam em consideração a possibilidade de paradas planejadas, porém são aceitas como o senso comum na literatura da área Alta disponibilidade Adicionando-se mecanismos especializados de detecção, recuperação e mascaramento de falhas, pode-se aumentar a disponibilidade do sistema, de forma que este venha a se enquadrar na classe de alta disponibilidade. Nesta classe as máquinas tipicamente apresentam disponibilidade na faixa de 99,99% a 99,999%, podendo ficar indisponíveis por um período de pouco mais de 5 minutos até uma hora em um ano de operação. Nesta classe se encaixam grande parte das aplicações comerciais de alta disponibilidade, como centrais telefônicas Disponibilidade contínua Com a adição de noves (9) se obtém uma disponibilidade cada vez mais próxima de 100%, diminuindo o tempo de inoperância do sistema de forma que este tempo se torne desprezível ou mesmo inexistente. Chega-se então na disponibilidade contínua, o que significa que todas as paradas planejadas e não planejadas são mascaradas, e o sistema está sempre disponível. 4. Ferramentas Esta seção tem o objetivo de apresentar as ferramentas que foram utilizadas para criar o ambiente de cluster de alta disponibilidade do sistema SIS-HOS no ambiente do HE Heartbeat O Heartbeat é uma ferramenta que funciona como um batimento cárdiaco, ele envia pulsos entre dois computadores através de uma porta serial ou placa de rede, caso um desses pulsos falhe o nó secundário irá assumir o papel de primário. O Heartbeat cria um ip virtual, ip este que irá passar de um nó para o outro, dependendo do nó que estiver trabalhando como primário [Ferreira; Rubem 2008] DRBD (Distributed Replicated Block Device) O DRBD é um módulo para o kernel linux, que juntamente com alguns scripts disponibiliza dispositivos de armazenamento distribuído. Isto é feito replicando blocos da partição via rede [DRBD 2011] Funcionamento Cada dispositivo tem um estado que pode ser primário ou secundário. O DRBD associa um dispositivo virtual, tal como /dev/drbdx, a uma partição local. Toda escrita é realizada

4 no servidor primário que está com a partição /dev/drbdx montada, e transmite os dados escritos para o secundário que está com a partição desmontada. Se o servidor primário falhar, o secundário monta a partição e assume como primário possibilitando a escrita. O DRBD trabalha a nível de blocos do disco rígido e não a nível de sistema de arquivos [DRBD 2011] Modos de replicação O DRBD possui três modos de replicação. O modo A, onde as operações de escrita são consideradas concluídas logo após a gravação local e o pacote de replicação colocado no buffer. No modo B, onde a escrita é concluída após a gravação local e o pacote de replicação atingir o nó secundário. No modo C, a escrita só é dada como concluída após confirmada o término da gravação no nó secundário. Este modo é o mais utilizado para evitar a perda de dados [DRBD 2011] NFS (Network File System) O protocolo NFS fornece acesso remoto transparente para sistemas de arquivo compartilhados através de redes. O protocolo NFS é projetado para ser independente de máquina, sistema operacional, arquitetura de rede e protocolo de transporte. Esta independência é conseguida através de Chamadas RPC (Remote Procedure Call) [Watts 2012] Firebird É um banco de dados relacional que oferece recursos ANSI SQL que roda em diversas plataformas. Ele oferece alta performance e uma linguagem poderosa para procedures e triggers. O Firebird já vem sendo usado desde 1981 com diversos nomes diferentes [Firebird 2012]. 5. Desenvolvimento Esta seção tem como objetivo apresentar o cenário atual utilizado no HE e o cenário proposto com recursos de alta disponibilidade SIS-HOS Destinado a hospitais e clínicas de saúde, o SIS-HOS estabelece uma rede de comunicação em tempo real que abrange todas as unidades da instituição, possibilitando integrar informações e processos de rotina administrativa, assistencial e gerencial [JME 2012]. Na figura 1, está representada uma tela da funcionalidade de cadastro de pacientes.

5 Figura 1. Cadastro de pacientes 5.2. Cenário atual No cenário atual, existe um único servidor utilizando sistema operacional Linux Debian com Firebird, onde se faz necessário além dos arquivos executáveis do SIS-HOS um cliente Firebird instalado nas máquinas clientes. Portanto, este ambiente não possui redundância e caso ocorra alguma falha, o sistema ficará indisponível. O tempo de indisponibilidade vai depender do tipo de problema, por exemplo, uma placa-mãe poderia levar horas ou até mesmo dias para ser substituída. Na figura 2, um diagrama simplificado do cenário atual do sistema SIS-HOS sem redundância. Figura 2. Cenário atual 5.3. Cenário proposto No cenário proposto pode-se ver conforme a figura 3 que existem 4 servidores envolvidos com o intuito de tornar o cenário um cluster de alta disponibilidade. Em ambos os

6 servidores, o sistema operacional utilizado é o linux Debian. Na figura 3a encontra-se a ferramenta Heartbeat, que tem a função de disponibilizar um ip Virtual que será o ip utilizado pelos clientes para acesso ao sistema, e tem também como sua função gerenciar o funcionamento do Firebird. Para instalação do Heartbeat no Debian é necessário apenas instalar o pacote heartbeat com o comando apt-get install heartbeat, após a instalação é necessário ajustar os arquivos de configuração /etc/ha.d/ha.cf que é o arquivo onde contém as principais configurações do heartbeat, o arquivo /etc/ha.d/haresources onde será configurado o ip virtual que será disponibilizado e também os serviços que o Heartbeat ira controlar na sua inicialização e o arquivo /etc/ha.d/authkeys onde é configurado a chave de autenticação entre os servidores. Na figura 3b encontra-se novamente o Heartbeat disponibilizando um ip virtual para acesso do par de servidores 3a via NFS e também controlando o funcionamento do DRBD. O NFS disponibilizando o compartilhamento da partição DRBD, e o DRBD que tem a função de sincronizar os dados inseridos no banco de dados entre os dois servidores. Para instalação do DRBD no Debian é necessário instalar o pacote drbd8-utils com o comando apt-get install drbd8-utils, após é necessario ajustar os seguintes arquivos de configurção /etc/drbd.conf, nele serão ajustadas as principais configurações do DRBD e dos nós envolvidos no cluster. Figura 3. Cenário proposto, uso de Heartbeat com Firebird (a) e com DRBD (b). 6. Testes Esta seção tem o intuito de demonstrar os testes realizados. Todos os testes foram realizados em máquinas virtualizadas com a ferramenta VirtualBox[Oracle 2012] utilizando uma máquina hospedeira com processador Pentium Dual Core 2.10 GHz e 256MB de memória.

7 6.1. Teste de funcionamento do cluster Para testar o funcionameto do cluster foi simulado a ausência do nó primário no Heartbeat e DRBD para verificar o tempo necessário para o nó secundário assumir o serviço. Depois foi simulado o retorno do nó primário para se obter o tempo necessário para ele assumir o serviço novamente Teste de funcionamento do Heartbeat No teste de ausência do nó primário, o nó secundário levou o tempo de 708ms para assumir o serviço, e no teste de retorno do nó primário o tempo foi de 1717ms Teste de funcionamento do DRBD No teste de ausência do nó primário, o nó secundário levou o tempo de 2207ms para assumir o serviço e montar a partição DRBD, e no teste de retorno do nó primário sem alteração de conteúdo da partição DRBD o tempo foi de 15451ms. No teste de retorno do nó primário, com alteração de 100 MB no conteúdo da partição DRBD o tempo foi de 29336ms para assumir o serviço efetuando o sincronismo, sendo que durante o sincronismo o sistema não fica indisponível, pois o nó secundário esta ativo e trabalhando como nó primário Teste de desempenho do banco de dados Para executar os testes de desempenho do banco de dados foi utilizada a ferramenta DBbench, ferramenta baseada no PGbench do PostgreSQL [DBbench 2009]. Esta ferramenta executa uma seqüência de comandos SQL em várias sessões de banco de dados simultâneos, e então calcula a taxa média de transação (transações por segundo)[pgbench 2009]. Os testes foram realizados comparando Select e Update rodando no banco local e no cluster. Foi executada uma bateria de 5 testes com as transações por usuário fixas e variando o número de usuários conforme tabela 1. Tabela 1. Testes realizados Testes Transações por Número de Total usuário usuários transações Teste Teste Teste Teste Teste de Na figura 4 pode-se ver a tela de configuração do DBbench, onde no campo client é configurado o número de usuários e no campo trasaction/client o número de transações por cliente.

8 Figura 4. Configuração DBbench 6.5. Análise dos resultados do teste de Select Na figura 5, pode-se notar que o gráfico de transações por segundo se manteve com um desempenho melhor no ambiente de cluster, que conforme foi aumentado o número de usuários para 120 mostrou uma perda de desempenho muito pequena em relação a leitura no ambiente local. Porém, no teste5 seu desempenho caiu 2,8 transações por segundos em relação ao ambiente local, como consequência esta diferença é vista no tempo total para executar as transações. Na figura 6, pode-se verificar que no teste5 existe uma diferença de 1,4 segundos em relação a leitura local. Portanto, conclui-se que conforme se aumenta a carga no banco de dados, o cluster vai perdendo um pouco seu desempenho, mas não é nada significativo que possa colocar em risco a agilidade do sistema. Figura 5. Gráfico de transações por segundo

9 Figura 6. Gráfico do tempo total para executar as transações 6.6. Análise dos resultados do teste de Update Pode-se notar na figura 7 que o cluster teve um melhor desempenho em quatro dos cinco testes,e conforme foi aumentado o número de usuários e consecutivamente o número total de transações a serem executadas, ele manteve desempenho superior em relação ao ambiente de escrita local. Na figura 8, verifica-se que o tempo total de execução das transações manteve uma diferença mínima de milisegundos, inperceptível para o usuário. Entretanto no teste 5 houve uma diferença de 1,8 segundos mostrando que seu desempenho de escrita é inverso ao de leitura trazendo benefícios para os usuários. Figura 7. Gráfico de transações por segundo

10 Figura 8. Gráfico do tempo total para executar as transações 7. Conclusão Conclui-se que o cluster de alta disponibilidade é um cenário extremamente vantajoso para sistemas de missão crítica, que não podem falhar. Devido a possibilidade de se montar um ambiente de cluster utilizando ferramentas de software livre como o Heartbeat e o DRBD, seu custo se torna extremamente baixo sendo necessário investir apenas em hardware. Seu impacto sobre o desempenho pode ser considerado pequeno, pois analisando os resultados obtidos nos testes apresentados ao longo do artigo chega-se a conclusão que dependendo da carga que o servidor recebe o cluster se mostra com a mesma eficiência de leitura e escrita que um ambiente local. Quando a carga é aumentada no cluster o desempenho pode até diminuir, mas não causa lentidão significativa no acesso dos usuários ao sistema. Os benefícios são notórios tanto para o usuário final, que terá a sua disposição um sistema tolerante à falhas e com alta disponibilidade, quanto para o técnico de TI, que poderá usufruir de uma janela de tempo maior para a manutenção do sistema. Referências Alecrim, E. (2004). Cluster: principais conceitos. Disponível em: < Acesso em: setembro DBbench (2009). Dbbench. Disponível em: < Acesso em: novembro DIMAP (2012). Guia do servidor conectiva linux. Disponível em: < aguiar/entendendo Conectiva8 Pro/servidor/ha.html#AEN11902>. Acesso em: outubro DRBD, L. &. (2011). Drbd. Disponível em: < Acesso em: setembro 2012.

11 Ferreira; Rubem, E. (2008). Heartbeat. In Linux Guia do Administrador do Sistema 2 a edição. Novatec. Firebird (2012). About firebird. Disponível em: < Acesso em: novembro JME (2012). Conheça o sis-hos. Disponível em: < Acesso em: novembro Oracle (2012). Welcome to virtualbox.org! Disponível em: < Acesso em: novembro PGbench (2009). Postgresql 9.3 devel documentation. Disponível em: < Acesso em: novembro Watts, L. (2012). Nfs. Disponível em: < Acesso em: novembro 2012.

12 A. Anexos A.1. Arquivos de configuração Figura 1. DRBD /etc/drbd.conf Figura 2. Heartbeat /etc/ha.d/authkeys

13 Figura 3. Heartbeat /etc/ha.d/haresources Figura 4. Heartbeat /etc/ha.d/ha.cf