alta disponibilidade em serviÇos essenciais ......disponibilidade dos serviços, porém todas são...
Post on 02-Jan-2021
4 Views
Preview:
TRANSCRIPT
i
LUCIANO EDUARDO CACIATO
ALTA DISPONIBILIDADE EM SERVIÇOS ESSENCIAIS
UTILIZANDO VIRTUALIZAÇÃO
CAMPINAS
2015
ii
iii
UNIVERSIDADE ESTADUAL DE CAMPINAS
Faculdade de Engenharia Elétrica e de Computação
LUCIANO EDUARDO CACIATO
ALTA DISPONIBILIDADE EM SERVIÇOS ESSENCIAIS UTILIZANDO
VIRTUALIZAÇÃO
Dissertação apresentada à Faculdade de
Engenharia Elétrica e de Computação da
Universidade Estadual de Campinas como parte
dos requisitos exigidos para a obtenção do título
de Mestre em Engenharia Elétrica na área de
concentração Engenharia de Computação.
Orientador: Prof. Dr. Maurício Ferreira Magalhães
ESTE EXEMPLAR CORRESPONDE À
VERSÃO FINAL DA DISSERTAÇÃO
DEFENDIDA PELO ALUNO LUCIANO
EDUARDO CACIATO, E ORIENTADO PELO
PROF. DR. MAURÍCIO FERREIRA
MAGALHÃES.
CAMPINAS
2015
iv
v
vi
vii
RESUMO
A disponibilidade dos serviços de tecnologia da informação é fundamental
para empresas, bancos e instituições públicas. As informações são crucias para a
tomada de decisão, elevando a competitividade e aumentando os lucros, além
disso, empresas ou instituições com boa reputação na prestação dos serviços são
sólidas e admiradas no mercado.
Os sistemas de informações devem prover a maior disponibilidade possível
de seus serviços e a alta disponibilidade e a virtualização são excelentes
estratégias para alcançar este objetivo.
A literatura mostra que existem várias implementações para garantir a
disponibilidade dos serviços, porém todas são baseadas na alta disponibilidade no
nível da virtualização, preocupando-se em manter, migrar ou iniciar uma ou várias
máquinas virtuais em um data center. Nesta dissertação a proposta consiste na
implementação da virtualização e da alta disponibilidade indo além dos
hypervisors, ou seja, nos sistemas operacionais hospedados nas máquinas
virtuais. O objetivo é garantir a disponibilidade dos serviços não controlados pela
virtualização garantindo assim um menor tempo possível de indisponibilidade dos
serviços oferecidos pelos sistemas de informação.
viii
ix
ABSTRACT
Availability of services of information technology is essential for companies,
banks and public institutions. The information is vital for decision making,
increasing the competitiveness and boosting profits, in addition, a company or
institution with good reputation in service delivery are solid and admired by the
market.
Information systems must provide the highest possible availability of their
services and high availability and virtualization are excellent strategies to achieve
this goal.
There are several implementations to ensure availability of services the
literature, but all are based on the level of high availability virtualization, concerned
to maintain, migrate or initiate one or more virtual machines in a data center. In this
dissertation, the proposal consists of the implementation of virtualization and high
availability that goes beyond hypervisors, ie the hosted operating systems in virtual
machines with the objective to ensure the availability of virtualization services not
controlled by ensuring lowest possible downtime of information systems.
x
xi
SUMÁRIO
PREFÁCIO .............................................................................................................. 1
Capítulo 1 ................................................................................................................ 3
INTRODUÇÃO ..................................................................................................... 3
1.1. Motivação ................................................................................................ 3
1.1.1. Tecnologia de Alta Disponibilidade ...................................................... 4
1.1.2. Tecnologia de Virtualização ................................................................. 5
1.2. Contribuições ............................................................................................. 6
1.3. Organização do texto ................................................................................. 6
Capítulo 2 ................................................................................................................ 7
REVISÃO BIBLIOGRÁFICA ................................................................................. 7
2.1. Alta Disponibilidade .................................................................................... 7
2.2. Medição da disponibilidade ........................................................................ 9
2.3. Backup ..................................................................................................... 11
2.4. Softwares para Alta Disponibilidade ......................................................... 12
2.5. Virtualização ............................................................................................. 15
2.7. Trabalhos relacionados ............................................................................ 20
Capítulo 3 .............................................................................................................. 27
PROPOSTA DE ALTA DISPONIBILIDADE DOS SERVIÇOS E SUA
IMPLEMENTAÇÃO. ........................................................................................... 27
3.1. Entendendo a solução .............................................................................. 30
3.2. Implementação das camadas................................................................... 34
3.2.1 Camada de virtualização ................................................................... 34
3.2.2 Camada da aplicação (serviços) ........................................................ 36
Capítulo 4 .............................................................................................................. 47
AVALIAÇÕES E OS RESULTADOS OBTIDOS ................................................. 47
4.1 Projeto físico da infraestrutura.................................................................. 47
4.2 . As configurações da infraestrutura ......................................................... 49
xii
4.2.1 Equipamentos físicos de rede ethernet e de storage: ........................ 49
4.2.2 Os servidores físicos (hosts):............................................................. 51
4.2.3 Virtualização: ..................................................................................... 52
4.3. Medições e resultados dos testes ............................................................ 54
4.3.1. Teste 1: .............................................................................................. 54
4.3.2. Teste 2: .............................................................................................. 61
4.3.3. Teste 3 (Inicialização dos serviços em local físico diferente):............ 68
Capítulo 5 .............................................................................................................. 81
CONCLUSÕES E TRABALHOS FUTUROS ...................................................... 81
TRABALHOS PUBLICADOS PELO AUTOR ......................................................... 83
Bibliografia ............................................................................................................. 85
Apêndice ............................................................................................................... 91
A.1- Configuração da camada de virtualização. .................................................... 91
A.1.1 – Informações do hypervisor e servidor físico:.......................................... 91
A.1.2 – Informações sobre as interfaces de rede (vmkernel): ............................ 92
A.1.2 – Informações dos switches virtuais (vSwitch): ......................................... 92
A.1.3 – Informações dos caminhos das LUNs no hypervisor (Storage): ............ 93
A.2 – Configuração das máquinas virtuais no hypervisor. ..................................... 94
A.2.1 – Configuração do cliente (ClusterHA-CLI.vmx): ...................................... 94
A.2.2 – Configuração do servidor 1 (ClusterHA1.vmx): ...................................... 96
A.2.3 – Configuração do servidor 2 (ClusterHA2.vmx): ...................................... 98
A.3 – Configuração da camada da aplicação. ..................................................... 100
A.3.1 – Configuração do DRBD (/etc/drbd.conf) .............................................. 100
A.3.2 – Configuração do heartbeat (/etc/ha.d/haresources) ............................. 104
A.3.3. – Configuração do Monitor (/etc/mon/mon.cf) ........................................ 104
A.3.4. – Configuração do Sistema Operacional convidado. ............................. 106
A.3.5. – Serviços de alta disponibilidade em execução no Sistema Operacional
convidado. ........................................................................................................ 111
xiii
DEDICATÓRIA
Para minha esposa Estefânia e minha filha Beatriz Caciato.
xiv
xv
AGRADECIMENTOS
Agradeço ao Professor Maurício Ferreira Magalhães, pela orientação,
profissionalismo e compreensão demonstrada durante todos esses anos.
Ao Centro de Computação da Unicamp em especial aos professores José
Raimundo de Oliveira e Marco Aurélio Amaral Henriques e aos colegas Paulo
Sérgio de Moraes, Mauro Wohnrath Januazelo e Roberto Romani.
xvi
xvii
LISTA DE FIGURAS
Figura 2.1 – Backup das máquinas virtuais. 12
Figura 2.2 – Modelo de implantação do heartbeat (Shaikh, 2004). 13
Figura 2.3 – Funcionamento do DRBD. (DRBD, 2013). 14
Figura 2.4 - Monitor de serviços. 15
Figura 2.5 -Vários sistemas operacionais funcionando simultaneamente. 16
Figura 2.6. – O hypervisor coordena a distribuição de recursos do servidor físico entre as partições por ele gerenciadas. 16
Figura 2.7 - O Pool de Recursos. 17
Figura 2.8 – Configuração do Datastore. 18
Figura 2.9 – Switch Virtual. 18
Figura 2.10. – Reinicio das máquinas virtuais na falha de um servidor físico (host). 20
Figura 3.1 – Adição de uma nova camada. 29
Figura 3.2 – Proposta de arquitetura de alta disponibilidade. 30
Figura 3.3 – Migração da máquina virtual pela falta de recurso computacional. 32
Figura 3.4 – Pool de recursos da Virtualização. 32
Figura 3.5 – Reinicio das máquinas virtuais em outro servidor físico. 33
Figura 3.6. – Rede de Controle e Dados. 35
Figura 3.7. – Projeto Lógico do Ambiente. 36
Figura 3.8. – Sincronização dos pontos de montagem do sistema de arquivos entre duas máquinas virtuais. 39
Figura 3.9 – Funcionamento do heartbeat. 40
Figura 4.1 – Desenho do projeto físico da infraestrutura. 48
Figura 4.2 – Configurações dos Switches Virtuais. 53
Figura 4.3 – Plano de teste no reinicio do heartbeat. 56
Figura 4.4 - Tempo de indisponibilidade com o reinicio do heartbeat (do servidor principal para o servidor em espera). 57
Figura 4.5. – Tempo de indisponibilidade com o reinicio do heartbeat (do servidor em espera para o servidor principal). 58
xviii
Figura 4.6. – Tempo de indisponibilidade ao reiniciar o heartbeat. 59
Figura 4.7 – Plano de teste de migração após erro no serviço web com teleduc.
63
Figura 4.8 – Gráfico de disponibilidade Teste 01 Log de acesso do servidor web. 65
Figura .4.9 – Gráfico de disponibilidade – Teste 02 – Log de acesso do servidor web. 65
Figura 4.10 – Gráfico de disponibilidade – Teste 03 – Log de acesso do servidor web. 66
Figura 4.11 – Inicialização dos serviços em servidor físico fora do data center virtual. 70
Figura 4.12 – Gráfico de disponibilidade– Teste 01–servidor principal para o espera. 71
Figura 4.13 - Gráfico de disponibilidade – Teste 02– servidor em espera para o principal. 72
Figura 4.14. – Gráfico de disponibilidade–Teste 03– – servidor principal para o espera. 73
4.15. – Gráfico de disponibilidade – Teste 04 – servidor em espera para o principal. 73
Figura 4.16 - Gráfico de disponibilidade – Teste 05 – servidor principal para o espera. 74
Figura 4.17. – Gráfico de disponibilidade – Teste 06 – servidor em espera para o principal. 74
Figura 4.18. – Desligamento forçado do host do cluster Cluster_Desenv_2. 77
Figura 4.19. – Identificação da falha do servidor físico (host). 77
Figura 4.20 – A máquina virtual é iniciada em outro servidor físico (host). 78
Figura 4.21 – Restabelecimento da máquina virtual e do serviço web. 78
xix
LISTA DE TABELAS
Tabela 2.1 – Tempo de indisponibilidade admitida por ano. 11
Tabela 3.1 – Pontos de montagem do sistema de arquivos. 37
Tabela 3.2. – Configuração do heartbeat. 40
Tabela 3.3. Configuração de rede. 41
Tabela 3.4. – Arquivo de configuração do mon.cf. 43
Tabela 3.5. – Configuração do heartbeat.alert. 45
Tabela 4.1. - Declaração das vlans 10 e 11. 50
Tabela 4.2. - Configuração do trunk e das vlans. 50
Tabela 4.3. - Configuração das portas fibre channel. 51
Tabela 4.4. - Configuração dos servidores físicos. 52
Tabela 4.5. – Configuração das máquinas virtuais. 53
Tabela 4.6. - Mensagens do servidor web (Access Log). 64
Tabela 4.7. - Mensagens do servidor web (Access Log) relativo a figura 4.17.
71
Tabela 4.8 - Mensagens do servidor web (Access Log) relativo a figura 4.18.
72
xx
xxi
LISTA DE ABREVIATURAS E SIGLAS
DRDB Distributed Replicated Block Device
MON Monitor (Service Monitoring Daemon)
VMM Virtual Machine Monitor
SAN Storage Area Network
RAID Redundant Array of Independent Disks
DAS Direct-Attached Storage
VLAN Virtual Local Area Network
SAS Serial Attached SCSI
xxii
1
PREFÁCIO
O interesse do autor desta dissertação pelo tema alta disponibilidade e
virtualização surgiu na necessidade de garantir que os serviços dos sistemas de
informação da Unicamp estejam sempre em funcionamento, mesmo no caso de
manutenção ou falha dos serviços do data center, devendo os serviços de
tecnologia da informação estar disponíveis o mais rápido possível para serem
utilizados pelos professores, alunos, funcionários e visitantes.
Para atingir este objetivo foi proposta uma arquitetura que permitirá utilizar
todo o poder computacional dos servidores com menor tempo possível de
indisponibilidade dos serviços essenciais da Unicamp, como o portal institucional
http://www.unicamp.br/unicamp.
Esta dissertação instancia a arquitetura proposta no data center da
Unicamp tendo em vista que a disponibilidade é um requisito importante a vários
serviços oferecidos pela Universidade.
O cenário de interesse da dissertação tem como alvo atender os requisitos
das instituições/empresas que necessitam oferecer alta disponibilidade nos
serviços em data centers baseados em ambientes virtualizados utilizando software
de mercado e software de código aberto.
2
3
Capítulo 1
INTRODUÇÃO
Neste primeiro capítulo será feita uma breve introdução às tecnologias de
alta disponibilidade e virtualização e os desafios provenientes do uso destas
tecnologias que motivaram esta dissertação. A seguir será discutido o problema
que foi o foco desta pesquisa: a necessidade de garantir a disponibilidade dos
serviços essenciais de tecnologia da informação após falha ou manutenção do
data center. Este trabalho teve como base uma arquitetura de alta disponibilidade
desenvolvida pelo autor que faz parte do corpo técnico do Centro de Computação
da Unicamp.
1.1. Motivação
As empresas estão inseridas em uma nova economia em que as
informações encontram-se armazenadas em servidores espalhados em milhares
de data centers pelo mundo e onde a necessidade de informação é cada vez mais
crucial para a sobrevivência das empresas em um mercado bastante competitivo.
Assim, nessa nova economia não existe mais espaço para a demora nas
transações informatizadas que devem ser realizadas imediatamente a fim de
satisfazer as necessidades das empresas.
4
Nesse aspecto, a tecnologia da informação aplicada nas infraestruturas e
sistemas críticos deve suprir as demandas dos dados informatizados pelas
empresas conforme o contrato de acordo de nível de serviço e proporcionando
sua disponibilidade de modo ininterrupto.
Uma das questões mais críticas é a capacidade de um data center prestar
um serviço de alta disponibilidade para todas as principais aplicações que devem
ser executadas 24 horas ao dia e 7 dias por semana (Calzolari, F. 2006).
Assim como as empresas, as universidades necessitam manter seus
serviços de tecnologia da informação disponíveis para seus professores, alunos,
funcionários e visitantes. E para que isso ocorra são necessárias arquiteturas que
suportem as falhas ou as paradas para a manutenção dos sistemas de informação
que é foco desta dissertação.
1.1.1. Tecnologia de Alta Disponibilidade
A alta disponibilidade tem como meta a redução do tempo de inatividade
das aplicações de modo a minimizar as consequências de possíveis falhas dos
sistemas informatizados contribuindo assim para a eficácia do seu funcionamento
(Caciato, L.E. 2012). Soluções de alta disponibilidade são tradicionalmente
baseadas na redundância dos componentes, assim, se um componente falhar, o
sistema é capaz de continuar operando utilizando o componente redundante
(Engelmann, C. e Scott, S.L. 2005).
5
1.1.2. Tecnologia de Virtualização
Uma tecnologia importante para a arquitetura proposta nesta dissertação é
a virtualização que tem se mostrado muito eficiente na maximização dos recursos
computacionais. Ela está disponível desde 2001 na plataforma x86, ou seja, nos
computadores comumente encontrados no mercado.
Virtualização, numa definição livre, é o processo de executar vários
sistemas operacionais em um único equipamento. E uma máquina virtual é um
ambiente operacional completo que se comporta como se fosse um computador
independente. Com a virtualização, um servidor pode manter vários sistemas
operacionais em uso (HP Brasil 2009).
Capitalizar as vantagens da criação de ambientes computacionais virtuais
não é difícil. Não é preciso que o administrador tenha um hardware particular
pronto para virtualização porque quase todo equipamento é capaz de hospedar
uma máquina virtual. Para fazer isso, é necessário apenas um software especial,
denominado hypervisor, que é instalado sobre o hardware físico. Essencialmente,
o software simula o hardware permitindo, desta forma, que o sistema operacional,
denominado de sistema operacional convidado, seja instalado sobre esse
software. Veremos mais detalhes sobre virtualização no próximo capítulo.
Dessa forma, aliando às tecnologias de alta disponibilidade e virtualização,
alcançamos uma disponibilidade significativa dos serviços dos sistemas de
informação diminuindo o tempo de falha no caso dos serviços oferecidos no data
center da Unicamp de minutos para segundos.
6
1.2. Contribuições
Na dissertação exploraremos o comportamento dos serviços essenciais
hospedados no data center de maneira prática, procurando chegar a um nível de
disponibilidade aceitável, ou seja, a disponibilidade contratada no acordo de nível
de serviço de tecnologia da informação (SLA1).
As contribuições desta dissertação são:
- proposta de uma arquitetura de alta disponibilidade dos serviços em uma
estrutura de data center;
- instanciação e validação da arquitetura proposta em uma ambiente real de data
center.
1.3. Organização do texto
Veremos no Capítulo 2 uma breve revisão bibliográfica apresentando as
tecnologias e propostas estudadas que auxiliaram na elaboração desta
dissertação. No capítulo 3 apresentaremos a principal contribuição desta
dissertação traduzida em uma arquitetura para alta disponibilidade de serviços e a
respectiva infraestrutura projetada para a sua implementação e validação. No
capítulo 4 apresentaremos as avaliações e os resultados obtidos e, por último, no
capítulo 5, serão discutidas as conclusões e os trabalhos futuros.
1 service-level agreement
7
Capítulo 2
REVISÃO BIBLIOGRÁFICA
Neste capítulo será apresentada uma breve revisão bibliográfica dos
conceitos pertinentes a esta dissertação de mestrado. Nas seções seguintes serão
discutidas as propostas de alta disponibilidade e virtualização estudadas. Todos
esses conceitos formam a base teórica para a compreensão do conteúdo da
proposta aqui apresentada.
2.1. Alta Disponibilidade
A tecnologia de alta disponibilidade tem a capacidade de manter os
serviços funcionando mesmo após ocorrências de falhas. O sistema de alta
disponibilidade é resistente a falhas de software, hardware, energia e rede. A sua
implementação pode variar de acordo com as necessidades das aplicações,
recursos financeiros e modelos de negócios. Existem várias configurações que
podem ser adotadas e combinadas para aumentar a disponibilidade dos serviços,
sendo elas:
a) Redundância: pode-se ter redundância de interfaces de rede, fontes de
alimentação, processadores, links de comunicação e servidores. A
redundância é uma peça primordial para sistemas de missão crítica,
8
pois, no caso de falha de algum servidor, o sistema continua
funcionando normalmente;
b) Failover: é a capacidade de um sistema identificar e executar um
procedimento no caso de qualquer problema nos componentes -
servidores, rede e/ou armazenamento;
c) Balanceamento de carga: utilizado para distribuir a carga de trabalho
dos sistemas uniformemente no cluster de servidores a fim de otimizar a
utilização de recursos, maximizar o desempenho, minimizar o tempo de
resposta e evitar sobrecargas.
d) Cluster: é um conjunto de computadores interligados em rede,
comunicando-se por meio de seus sistemas de forma que sejam
apresentados como uma única máquina de grande porte. Cada
computador do cluster é chamado de nó ou nodo. Deve ser observado
que um sistema que conta com redundância, failover, escalabilidade
e/ou balanceamento de carga é essencial para o cluster (Calzolari, F.
2006).
Ao discutir sobre alta disponibilidade comumente encontramos na
literatura outra técnica que é a tolerância a falhas, que não utilizaremos nesta
dissertação, porém, por ser conceitualmente próxima, torna-se necessário definir a
diferença entre tolerância a falhas e alta disponibilidade.
Os sistemas com tolerância a falhas são projetados para operar
praticamente sem interrupção, independentemente da falha que possa ocorrer
(com algumas exceções como uma parada geral do data center em um desastre
9
natural). Em tais sistemas, todos os componentes são pelo menos redundantes
tanto no software como no hardware.
Os componentes como processadores, memórias e discos têm um projeto
especial para oferecer um serviço contínuo, mesmo se um subcomponente falhar.
Apenas, as soluções que utilizam softwares especiais podem ser executadas no
hardware tolerante a falhas. Estes sistemas são muito dispendiosos e
extremamente especializados. Implementar uma solução tolerante a falhas requer
um grande esforço e um alto grau de personalização para todos os componentes
do sistema (Vetter, S., Bodily, S. et al. 2009).
Enquanto, que a alta disponibilidade prevê a disponibilidade não como uma
série de componentes físicos replicados, mas sim como um conjunto de recursos
compartilhados que cooperam para garantir serviços essenciais.
Assim sendo, a alta disponibilidade combina software com hardware padrão
da indústria para minimizar o tempo de inatividade por restaurar rapidamente os
serviços essenciais quando um sistema, componente ou aplicativo falhar. Embora,
não seja instantânea, os serviços são restabelecidos rapidamente, muitas vezes,
em fração de minutos (IBM, 2015).
2.2. Medição da disponibilidade
Para a implementação da alta disponibilidade é necessária a realização de
um contrato, chamado de acordo de nível de serviço de tecnologia da informação
(TI), realizado entre a área de TI responsável pelo serviço e o cliente que utiliza o
serviço. Nesse contrato são acertados os termos da disponibilidade, por exemplo
10
vinte quatro horas por dia e sete dias por semana ou oito horas por dia e cinco
dias da semana, dentro de uma porcentagem de disponibilidade.
A porcentagem é um fator importante nos sistemas de alta disponibilidade.
Para ser capaz de formalizar o grau de disponibilidade no acordo de nível de
serviço precisamos de um valor numérico que represente essa demanda. Assim,
os provedores dos serviços precisam de um método para calcular a
disponibilidade dos sistemas ativos. Com base em dados históricos, pode-se
calcular a disponibilidade que um sistema tem tido, na última semana, mês ou
ano, por exemplo. Isso pode ser usado como um valor de expectativa que se
espera de um serviço esteja disponível no futuro. O conhecimento sobre o tempo
médio entre falhas (MTBF - Mean Time Between Failure) e o tempo médio para
repará-las (MTTR - Mean Time To Repair) pode ser usado nesta fórmula de
cálculo de disponibilidade conforme a seguir (Braastad, E. 2006):
A disponibilidade do sistema é dependente da taxa de falhas dos
equipamentos. Estas taxas de insucesso são muitas vezes mensuradas no tempo
médio entre falhas (MTBF) para cada um dos componentes do sistema. O MTBF
do sistema completo é muito menor do que o MTBF de componentes individuais.
Isto significa que as falhas são mais esperadas para ocorrer em um sistema maior
e mais complexo.
A disponibilidade de um sistema é medida pelo número de noves dado em
percentagem do tempo total em que o sistema deve estar disponível conforme
tabela 2.1
11
Disponibilidade Tempo de parada anual
99% 3,7 dias
99,9% 8,76 horas
99,99% 52,55 minutos
99,999% 5,25 minutos
99,9999% 32 segundos
Tabela 2.1 – Tempo de indisponibilidade admitida por ano.
2.3. Backup
Para garantir a alta disponibilidade dos serviços na solução é necessário
implantar mecanismos de backup, que são utilizados nos casos de falhas de
qualquer componente de software.
Este mecanismo é importante, pois em erros graves do ambiente o backup
é a garantia de que o serviço voltará ao estado do último backup realizado.
Podemos ter vários níveis de backup como, por exemplo, no nível do
sistema operacional convidado através da cópia dos seus serviços e dados ou, no
nível da virtualização, através da cópia da máquina virtual inteira. Esta técnica de
backup é denominada de snapshot. Na figura 2.1 podemos ver o backup das
máquinas virtuais utilizando o snapshot. Isso é possível porque a infraestrutura de
virtualização utiliza o armazenamento centralizado permitindo o backup de todas
as máquinas virtuais (Calzolari, F. 2006).
12
Figura 2.1 – Backup das máquinas virtuais.
Veremos a seguir os softwares voltados à alta disponibilidade utilizados
nesta dissertação de mestrado.
2.4. Softwares para Alta Disponibilidade
Para nossa solução de alta disponibilidade no nível dos serviços foram
utilizados três softwares de código aberto: heartbeat, drbd e mon como seguem:
a) Heartbeat é um software utilizado nas soluções de alta disponibilidade para
cluster de computadores, fornecendo as funções básicas de monitorar,
iniciar e parar os serviços e também de transferir o endereço IP (Internet
Protocol) entre os nós do cluster (Shaikh, H. 2004).
Os servidores são configurados no modelo mestre / escravo, ou seja, no
mestre os serviços estão ativos e podem ser utilizados e no escravo estão
parados até que ocorra uma falha do sistema operacional do mestre.
Quando ocorrer a falha do mestre, o escravo automaticamente assume o
13
papel do mestre até que o daemon de heartbeat seja restabelecido. Os
daemons de heartbeat são instalados nos sistemas operacionais trocando
informações entre o servidor mestre e o servidor escravo monitorando
assim o seu funcionamento. Na figura 2.2 é mostrado um modelo de
implantação do heartbeat. Observe que os usuários dos serviços fazem
acesso ao cluster pelo IP 9.8.7.3 no servidor mestre onde em caso de falha
farão acesso no servidor escravo, ou seja, o servidor escravo assume o
papel do mestre até que se restabeleça o cluster. E o cabo serial entre os
servidores físicos é para garantir que mesmo numa interrupção de rede o
cluster heartbeat mantenha-se trocando as informações de disponibilidade
do cluster.
Figura 2.2 – Modelo de implantação do heartbeat (Shaikh, H. 2004).
b) O Distributed Replicated Block Device (DRBD) é um software projetado
para a implementação de cluster de alta disponibilidade e sua função é
sincronizar os sistemas de arquivos pré-definidos do servidor mestre para o
servidor escravo através da rede de computadores. Ou seja, tudo que é
14
gravado no sistema de arquivo configurado no servidor mestre é replicado
via rede no servidor escravo no mesmo instante como mostrado na figura
2.3 (Haas, F., Reisner, P. 2011).
Figura 2.3 – Funcionamento do DRBD. (DRBD, 2013).
c) O Service Monitoring Daemon (Mon) é um pacote de software também
utilizado em muitas soluções de alta disponibilidade e que tem a função de
monitorar, através de seu daemon, serviços pré-definidos no sistema
operacional como, por exemplo, serviço web (http), serviço de e-mail
(imap), etc. No caso da parada de qualquer um desses serviços o mon
executa um comando no heartbeat com a finalidade de parar o(s) serviço(s)
no servidor principal e iniciar imediatamente o(s) serviço(s) no servidor em
espera. Além disso, envia uma mensagem de falha relatando qual servidor
passa a prover os serviços ao administrador de tecnologia da informação.
(Trocki, J. 2002).
15
Figura 2.4 - Monitor de serviços.
Visto os conceitos básicos dos três softwares utilizados no nível dos
serviços, vamos entender os softwares utilizados no nível da virtualização.
2.5. Virtualização
A virtualização permite que vários sistemas operacionais funcionem
simultaneamente no mesmo servidor físico, utilizando uma camada de software
entre o hardware e o sistema operacional convidado. Também é responsável por
criar partições distintas no armazenamento compartilhado para as máquinas
virtuais serem executadas conforme indicado na figura 2.5 (Caciato, L.E. 2009).
16
Figura 2.5 – Vários sistemas operacionais funcionando simultaneamente.
A virtualização é composta por dois componentes: o servidor físico ou host
onde estão instalados os softwares de virtualização chamados hypervisors e as
máquinas virtuais onde ficam hospedados os sistemas operacionais convidados.
O Hypervisor, também conhecido como VMM - Virtual Machine Monitor, é a
camada de software responsável em fornecer ao sistema operacional convidado a
abstração da máquina física como mostrado na figura 2.6.
Figura 2.6. – O hypervisor coordena a distribuição de recursos do servidor físico entre as
partições por ele gerenciadas.
17
Os três principais componentes do hypervisor são o Pool de Recursos,
Datastore e Switch Virtual, como veremos a seguir:
a) Pool de recursos (resource pool), responsável pela infraestrutura virtual,
onde as máquinas virtuais utilizam de seus componentes virtuais abstraídos
do servidor físico, entre os quais: processadores, memórias, discos e redes,
conforme a figura 2.7.
Figura 2.7 - O Pool de Recursos.
b) Datastore: sua função principal é armazenar máquinas virtuais e permitir
que essas máquinas virtuais executem sistemas operacionais
simultaneamente no mesmo compartilhamento de armazenamento
conforme indicado na figura 2.8 (Caciato, L.E. 2009).
18
Figura 2.8 – Configuração do Datastore.
c) Switch Virtual é equivalente a um switch físico, realiza a comunicação das
máquinas virtuais na rede usando os mesmos protocolos que seriam
usados no switch físico, conforme figura 2.9 (Vmware Network, 2007).
Figura 2.9 – Switch Virtual.
19
Para gerenciar todos os componentes do ambiente de virtualização é
instalado uma console que unifica todos os servidores físicos (hosts) e as
máquinas virtuais de um data center. O gerenciamento da virtualização permite
que os administradores tenham mais controle, simplifiquem as tarefas diárias,
reduzam a complexidade e os custos de gestão do ambiente de tecnologia da
informação (Vmware, 2009).
2.6. Solução aliando a tecnologia de alta disponibilidade com a tecnologia
de virtualização
Quando aliamos a alta disponibilidade com a virtualização nosso objetivo é
tornar os servidores físicos (hosts) e o hypervisor o mais disponível possível para
a utilização. O funcionamento dessa solução é através da técnica de alta
disponibilidade que monitora continuamente todos os servidores físicos (hosts) em
um pool de recursos e com a finalidade de detectar possíveis falhas dos
servidores físicos. Um agente localizado em cada hypervisor do servidor físico
mantém um daemon de alta disponibilidade chamado heartbeat com os outros
servidores físicos no pool de recursos e, uma perda de heartbeat aciona o
processo de reinicialização de todas as máquinas virtuais afetadas em outros
servidores físicos. A camada de virtualização garante também que haja sempre
recursos suficientes disponíveis no pool de recursos, permitindo reinicializar as
máquinas virtuais em outros servidores físicos em caso de falha do servidor, como
na figura 2.10 (Vmware, 2007).
20
Figura 2.10. – Reinicio das máquinas virtuais na falha de um servidor físico (host)
Veremos na seção a seguir os trabalhos relacionados que utilizamos como
base desta dissertação.
2.7. Trabalhos relacionados
Esta seção discute os principais trabalhos relacionados com alta
disponibilidade utilizando virtualização com o objetivo de disponibilizar os serviços
de tecnologia da informação o mais rápido possível após falha ou manutenção do
data center.
Braastad, E. (2006) analisa a gestão dos serviços de alta disponibilidade e
virtualização e propõe uma arquitetura baseada na migração de máquinas virtuais
com a finalidade de garantir a disponibilidade dos serviços. A discussão principal
do projeto é propor e implementar uma funcionalidade no serviço de alta
disponibilidade dos hypervisors utilizando o heartbeat e proporcionando assim, a
capacidade de controlar as instâncias dos hypervisors automaticamente e a
21
migração das máquinas virtuais em tempo real para outro servidor físico (host),
sem a necessidade da parada ou reinício das máquinas virtuais.
Calzolari, F. (2006) investiga as necessidades empresariais sobre alta
disponibilidade com virtualização utilizando software de código aberto tendo como
base um sistema que garanta a redundância das aplicações na maioria dos casos,
ou seja, um sistema capaz de restaurar qualquer aplicação executada
anteriormente em menos de 10 minutos a partir do momento da falha. São
analisadas as causas e o tempo das paradas em um data center por um período
de três anos, onde uma nova abordagem para alta disponibilidade foi concebida
baseado em hosts executando em ambiente virtual, através da infraestrutura
virtual de alta disponibilidade garantindo um serviço que tenha disponibilidade
constante de rede, processadores, discos e memórias. Desta forma, uma falha de
um desses componentes é transparente para as aplicações e serviços resultando
em seu restabelecimento entre cinco e dez minutos.
Tsugawa, M., Figueiredo, R. et al (2012) avaliam experimentalmente a
migração de várias máquinas virtuais através de longas distâncias geográficas na
ocorrência de falha do data center. Esta atividade é necessária para mover
sistemas de tecnologia da informação virtualizados a partir de um local de
desastre natural para um local seguro. Levando-se em conta os parâmetros de
disponibilidade de recursos observados após o grande terremoto do leste do
Japão, os resultados experimentais discutem se (1) o tempo de inatividade do
serviço na ordem de minutos é aceitável, (2) máquinas virtuais podem ser
mantidas com espaço de armazenamento pequeno, e (3) existe energia e rede
22
disponível que possibilite migrar dezenas de máquinas virtuais de um data center
danificado para um outro local distante e estável. O principal desafio enfrentado
neste experimento é que os servidores físicos (hosts) de origem e destino
precisam ter acesso aos discos das máquinas virtuais (onde o sistema operacional
e os dados de clientes são armazenados) sendo que nesta arquitetura, onde os
data centers estão separados geograficamente, não é possível ter acesso aos
discos. Sistemas de compartilhamento ou arquivos utilizados em ambientes de
rede local não são adequados quando as redes de longa distância estão
envolvidas devido, obviamente, às limitações de desempenho e conectividade.
Outra constatação é que na recuperação de desastres é mais importante ser
capaz de mover tantas máquinas virtuais quantas sejam possíveis das áreas
afetadas, do que tentar minimizar o tempo de inatividade das aplicações,
garantindo dessa forma a integridade das máquinas virtuais que poderão ser
iniciadas assim que a infraestrutura de tecnologia da informação for restabelecida.
Yang, M. e Wu, Y. (2012) propõem a utilização da alta disponibilidade e a
virtualização para assegurar o acesso ininterrupto dos serviços de tecnologia da
informação em instituições financeiras. É de extrema importância para essas
empresas manter a disponibilidade completa dos serviços, mesmo em caso da
ocorrência de catástrofes, já que são sistemas que não podem depender de
processos longos de recuperação de falhas devidos aos riscos de perdas
financeiras.
23
O artigo de Yang, M. e Wu, Y. (2012) discute soluções de virtualização
como a VMware (ESXi), Microsoft (Hiper-V) e Citrix (XenServer) e o seu
funcionamento em alta disponibilidade.
A discussão sobre virtualização gira em torno de duas áreas específicas
que são de interesse especial dessas instituições: (a) alta disponibilidade dos
serviços (b) recuperação rápida dos desastres a um custo reduzido.
Devido à natureza de suas atividades as instituições financeiras tendem a
ser mais bem preparadas do que outras empresas para enfrentar os desastres
naturais ou humanos. Por exemplo, um número de instituições financeiras
conseguiu retomar suas operações logo após o 11 de Setembro, em grande parte
devido aos sítios espelhos.
A alta disponibilidade é uma solução de redundância no nível de data
center, ou seja, ela somente protege contra interrupções nos serviços que estão
sendo executados nos servidores ou máquinas virtuais que estiverem hospedados
no mesmo data center. Dessa forma, serão impotentes caso o data center venha a
falhar totalmente, porque o hardware e software utilizados para alta disponibilidade
serão parte do que é destruído. Para lidar com uma situação tão desastrosa, a
recuperação de desastre (disaster recovery - DR) deve estar configurada. O DR é
responsável pela restauração das operações essenciais após a falha de um
evento extraordinário, por exemplo, 11 de Setembro ou Katrina. Até o momento, a
abordagem fundamental para DR é a criação e manutenção de redundância.
Existe uma grande variedade de medidas para fornecer redundância.
24
Fundamentalmente, eles resumem-se a dois tipos: redundância de infraestrutura e
redundância de dados.
Como vimos nos trabalhos acima a alta disponibilidade e virtualização são
assuntos de grande interesse, em especial, na área tecnológica. Entretanto, todas
elas estão baseadas na alta disponibilidade das máquinas virtuais, preocupando-
se em manter, migrar ou iniciar uma ou várias máquinas virtuais como um todo em
um data center local ou remoto. A proposta desta dissertação consiste na
implementação da alta disponibilidade que vai além dos hypervisors, ou
seja, nos sistemas operacionais hospedados nas máquinas virtuais com o
objetivo de garantir a disponibilidade dos serviços não controlados pela
virtualização. Essa necessidade foi identificada por Braastad E. (2006) em sua
tese nos itens 6.3. – eventuais melhorias futuras e 6.3.1. – adicionar uma segunda
camada de alta disponibilidade, onde é destacada a forte separação entre as
máquinas virtuais, servidores físicos e o serviço de alta disponibilidade do
hypervisor. A alta disponibilidade na camada de virtualização somente controla as
máquinas virtuais que se encontram em funcionamento, ou seja, a camada de
virtualização não tem acesso direto aos sistemas operacionais hospedados nas
máquinas virtuais para realizar a verificação das aplicações e serviços se estão
realmente funcionando. Por exemplo, suponha que após a atualização de um dos
módulos do kernel do sistema operacional que está hospedado em uma máquina
virtual ocorra uma falha que impossibilite que serviços continuem a funcionar.
Essa situação não seria identificada pela camada de virtualização.
25
Outra contribuição desta dissertação é com relação ao problema do
compartilhamento dos discos virtuais que não podem ser compartilhados entre
data centers local e remoto existindo a necessidade de parada e início das
máquinas virtuais no data center remoto conforme constatado em Tsugawa, M.,
Figueiredo, R. et al (2012). No caso da proposta apresentada nesta dissertação, é
possível iniciar os serviços do sistema operacional sem a necessidade de reinício
da máquina virtual, garantindo o menor tempo de indisponibilidade do que as
propostas anteriores.
26
27
Capítulo 3
PROPOSTA DE ALTA DISPONIBILIDADE DOS SERVIÇOS E SUA IMPLEMENTAÇÃO.
A disponibilidade dos serviços depende das técnicas de alta disponibilidade
empregada. Quanto maior o número de componentes redundantes como
servidores, redes, discos e de técnicas de alta disponibilidade, menor será o
tempo de indisponibilidade dos serviços.
Uma das técnicas mais simples de alta disponibilidade é a redundância de
hardware. Um bom exemplo é um servidor executando os serviços de um sistema
de informação e num dado momento ocorre uma falha de hardware. Neste
momento um servidor em espera assume o papel do servidor principal iniciando os
serviços que antes eram providos pelo servidor com defeito, voltando assim o
funcionamento normal para os usuários finais. Esta técnica pode ser automatizada
através de programas que realizam o diagnóstico e iniciam os serviços no servidor
redundante, ou podem ser realizadas de forma manual, onde o administrador de
tecnologia da informação realiza esta tarefa.
Outra técnica é a utilização da virtualização, onde na falha do servidor
físico, a máquina virtual será reiniciada em outro servidor físico dentro do mesmo
28
cluster. Esta técnica garante o retorno da máquina virtual, mas não dos serviços
do sistema operacional convidado.
Pode também ser agregada à solução os planos de contingência como o
backup das máquinas virtuais e dos programas fontes que estão instalados nos
sistemas operacionais convidados. O backup é de extrema importância para a
restauração dos arquivos que podem ter sido corrompidos em um desastre. Os
softwares para alta disponibilidade neste caso não resolveriam o problema de
arquivos corrompidos, pois como sua função é sincronizar os arquivos poderia
ocorrer a cópia dos programas com defeito também.
Dessa forma a arquitetura proposta nesta dissertação tenta aperfeiçoar a
solução e diminuir o tempo de indisponibilidade de minutos para segundos,
através de algumas técnicas de alta disponibilidade, como redundância de
hardware e software, sincronismos entre servidores e monitoramento dos serviços.
A diferença entre a arquitetura proposta nessa dissertação e as arquiteturas
apresentadas nos capítulos anteriores é a adição de uma camada com três
funções voltadas para alta disponibilidade no nível dos sistemas operacionais
convidados conforme figura 3.1. O papel dessas funções consiste em monitorar,
parar e iniciar os serviços no cluster automaticamente, diminuindo o tempo de
indisponibilidade dos serviços utilizados pelos usuários finais.
29
Figura 3.1 – Adição da nova camada.
As funções voltadas ao suporte da alta disponibilidade são utilizadas para a
realização das seguintes atividades:
a) Sincronização automática e “online” dos arquivos do servidor em
funcionamento para um servidor em espera;
b) Monitoramento dos serviços de alta disponibilidade da nova camada e
reinicialização dos serviços em caso de falha do sistema operacional
convidado;
c) Monitoramento dos serviços que são utilizados pelos usuários finais e
em caso de falha a reinicialização dos serviços no servidor em espera.
Veremos agora a proposta de alta disponibilidade dos serviços no nível do
sistema operacional nos seus detalhes e técnicas. Salientando que essa
abordagem foi esboçada nos trabalhos de Braastad E. (2006) e Calzolari F.,
30
Ciampa, A. et al (2006, 2010) sem, entretanto, ter sido especificada e validada nas
respectivas referências.
Como forma de viabilizar essa solução, esta dissertação propõe a criação
de um modelo de duas camadas de alta disponibilidade constituído pela camada
de virtualização (1ª camada) e a camada da aplicação (2ª camada). Na primeira
camada são configurados os dispositivos de hardware, os componentes de
software de virtualização e das máquinas virtuais; na segunda camada são
configurados os sistemas operacionais hospedados nas máquinas virtuais e as
aplicações (serviços) conforme figura 3.2.
Figura 3.2 – Proposta de arquitetura de alta disponibilidade.
3.1. Entendendo a solução
31
A arquitetura de alta disponibilidade proposta neste trabalho é baseada na
sincronização das informações de um servidor virtual em produção (servidor
principal) com um servidor virtual em espera. Tanto o servidor de produção quanto
o servidor em espera serão monitorados através da utilização de dois softwares
importantes na arquitetura proposta, sendo um que controla o estado dos
servidores (heartbeat) e outro os serviços em execução (mon). Esta estratégia
permite o oferecimento da alta disponibilidade de forma completa e cruzada, ou
seja, a camada de virtualização é responsável pela disponibilidade da
infraestrutura onde estão os servidores físicos, redes e armazenamento e a
camada da aplicação é responsável pela disponibilidade dos serviços utilizados
pelos usuários finais e do sistema operacional que está hospedado na máquina
virtual. Assim, caso ocorra um problema no servidor físico, a camada de
virtualização pode proceder de duas formas: se o problema for por falta de recurso
computacional (pool de recursos) a máquina virtual automaticamente será
migrada, sem reinício, para outro servidor físico que consiga oferecer o recurso
computacional necessário conforme figura 3.3.
32
Figura 3.3 – Migração da máquina virtual pela falta de recurso computacional.
A responsabilidade de verificar esta disponibilidade de recurso é da camada
de virtualização utilizando o componente pool de recursos. No pool de recursos
são delegadas pelo administrador da virtualização a quantidade de recursos como
processador, memória e armazenamento conforme figura 3.4.
Figura 3.4 – Pool de recursos da Virtualização.
33
E a segunda forma será quando ocorrer um problema físico do tipo queima
de processador, memória, placa de rede, neste caso a máquina virtual será
desligada do servidor físico com problema e reiniciada em outro servidor físico do
cluster conforme figura 3.5.
Figura 3.5 – Reinicio das máquinas virtuais em outro servidor físico.
Agora, se houver um problema no serviço, a camada da aplicação reiniciará
o serviço do servidor principal para o servidor em espera utilizando, no caso,
modelo tradicional de alta disponibilidade que é um servidor de produção
sincronizando as alterações para um servidor de backup. E a decisão para a
mudança dos servidores é baseada em uma pré-configuração que define em qual
servidor o serviço passará a ser executado. A principal vantagem dessa proposta
é a sincronização estabelecida entre servidor principal e o servidor em espera,
garantindo o menor tempo de indisponibilidade para o usuário final. Dessa forma,
será garantido que o usuário espere apenas alguns segundos para voltar a utilizar
tanto sistemas de informação, como as funcionalidades dos serviços, mesmo com
34
a mudança do servidor principal para o servidor em espera. O mesmo ocorre no
sentido contrário quando do reestabelecimento do servidor que apresentou
problemas levando, se for o caso, a um novo reinício do serviço na direção do
servidor original que levará também poucos segundos para estar disponível. Neste
caso existe uma garantia de alta disponibilidade em dois níveis, ou seja, no nível
do servidor e no nível do serviço, característica que não existe nas propostas
disponíveis na literatura. A desvantagem dessa proposta consiste na duplicação
da quantidade de máquinas virtuais. Entretanto, é mais vantajoso financeiramente
ter máquinas virtuais duplicadas do que ter servidores físicos duplicados.
Vejamos a seguir a implementação das camadas e a solução proposta.
3.2. Implementação das camadas
Discutiremos nesta seção a implementação das camadas propostas na
seção anterior através da utilização das camadas de virtualização e da aplicação
(serviços) proporcionando a disponibilidade dos serviços, conforme a seguir:
3.2.1 Camada de virtualização
A camada de virtualização é constituída de um armazenamento
centralizado (storage), dois servidores físicos conectados na rede de dados e na
rede de controle. A rede de dados é utilizada para acesso das aplicações
(serviços) por parte dos usuários do sistema. Por outro lado, a rede de controle é
utilizada para acesso por parte da administração da infraestrutura, assim como,
para a comunicação entre as camadas de virtualização, conforme figura 3.6.
35
Figura 3.6. – Rede de Controle e Dados.
Por sua vez o storage é responsável em centralizar todo o armazenamento
das máquinas virtuais devendo garantir a disponibilidade das informações,
vejamos a figura 3.7.
36
Figura 3.7. – Projeto Lógico do Ambiente.
As tecnologias de software empregadas nesta camada são as de migração
das máquinas virtuais chamadas de VMware vmotion (Vmware vMotion, 2012) e o
software chamado de VMware High Availability (Vmware, 2007) sendo executados
na rede de controle. O VMware High Availability tem este nome porque possui
funções específicas para prover recursos de alta disponibilidade como, por
exemplo, migração das máquinas virtuais do cluster em caso de falha do servidor
físico.
3.2.2 Camada da aplicação (serviços)
A camada da aplicação é constituída de dois sistemas operacionais linux
convidados onde foram instalados os software de banco de dados MySQL,
Servidor Web Apache com suporte à linguagem de programação PHP, sendo esta
aplicação utilizada pelos usuários. Para garantir a alta disponibilidade foram
37
instalados também os softwares drbd (Distributed Replicated Block Device),
heartbeat e monitor.
Para a implementação foi instalado um sistema operacional linux com as
seguintes distribuições do sistema de arquivos2 como visto pela saída do comando
df –h. Após a instalação e configuração do servidor principal é realizada uma
cópia idêntica (clone) desse servidor principal criando assim o servidor em espera
da alta disponibilidade proposta. Vejamos os pontos de montagem3 do sistema de
arquivos criado conforme tabela 3.1:
Filesystem Size Used Avail Use% Mounted on
/dev/sda2 996M 380M 565M 41% /
/dev/sda9 4.3G 254M 3.8G 7% /var
/dev/sda8 4.8G 2.4G 2.2G 53% /usr
/dev/sda7 4.8G 2.4G 2.1G 54% /usr/local
/dev/sda1 251M 24M 214M 11% /boot
tmpfs 1.5G 0 1.5G 0% /dev/shm
/dev/drbd0 9.7G 175M 9.0G 2% /mysql
/dev/drbd1 9.7G 387M 8.8G 5% /www
/dev/drbd2 9.7G 2.4G 6.8G 27% /home
/dev/drbd3 1.4G 37M 1. 3G 3% /phpses
Tabela 3.1 – Pontos de montagem do sistema de arquivos.
2 Um sistema de arquivos é uma organização de dados e metadados em um dispositivo de armazenamento (Jones, 2007). 3 Associar um sistema de arquivos a um dispositivo de armazenamento no Linux é um processo chamado montagem (Jones,2007).
38
Os pontos de montagem (/, /var, /usr, /usr/local e /boot) são utilizados para o
funcionamento do sistema operacional e os pontos de montagem (/mysql, /www,
/home, /phpses) são utilizados pela solução proposta pelo autor, conforme a
seguir:
a) O ponto de montagem /mysql indica a partição onde está instalado o
gerenciador do banco de dados Mysql juntamente com os respectivos
dados;
b) O ponto de montagem /www indica a partição onde está instalado e
configurado o software para servidor Web Apache e o código fonte dos
sistemas;
c) O ponto de montagem /home indica a partição onde está instalado o
software de educação a distância da Unicamp denominado Teleduc e
também as áreas dos usuários do sistema operacional;
d) O ponto de montagem /phpses indica a partição onde são gravadas as
sessões php dos usuários que estão conectados aos serviços naquele
momento. Por exemplo, o usuário ao se conectar na página do teleduc é
criada uma sessão como esta:
sess_529009e4ab8744f394c4e9bf10c86a7a, que significa que ele está
usufruindo do serviço. Voltaremos a abordar mais a frente sobre este
assunto.
Utilizando o DRBD:
39
São sincronizados os pontos de montagens (/mysql, /www, /home, /phpses)
entre o servidor principal e o servidor em espera com o software DRBD, criando
um espelhamento íntegro de todos os dados, como mostrado na figura 3.8.
Figura 3.8. – Sincronização dos pontos de montagem do sistema de arquivos entre duas máquinas virtuais.
Utilizando o Heartbeat:
O daemon do heartbeat se instala no ambiente na inicialização do sistema
operacional linux sendo responsável em iniciar os outros serviços e mudar o
estado do servidor em espera em principal e vice-versa quando ocorrer um erro,
conforme figura 3.9.
40
Figura 3.9 – Funcionamento do heartbeat.
Toda a configuração do heartbeat está localizada no diretório linux
/etc/ha.d e o principal arquivo é o haresources como mostrado na tabela
3.2.:
altadisp1.ccuec.unicamp.br
IPaddr::143.106.120.246/26/eth0
drbddisk Filesystem::/dev/drbd0::/mysql::ext3
Filesystem::/dev/drbd1::/www::ext3
Filesystem::/dev/drbd2::/home::ext3
Filesystem::/dev/drbd3::/phpses::ext3
mysql httpd mon
Tabela 3.2. – Configuração do heartbeat.
41
Para entender os parâmetros vejamos linha a linha:
- altadisp1.ccuec.unicamp.br nome do servidor
- IPaddr::143.106.120.246/26/eth0 IP público e interface utilizada pelos
serviços e endereço acessado pelos usuários. Neste exemplo o IP
143.106.120.246 é resolvido no DNS como altadisp3.ccuec.unicamp.br
- drbddisk Filesystem Pontos de montagem que devem ser efetivados
ao iniciar o sistema operacional linux;
- mysql, httpd, mon Serviços que devem ser iniciados.
Esses parâmetros utilizados no servidor principal e no servidor de espera
são uma exigência da configuração do heartbeat.
No detalhe da rede, vejamos a saída do comando ifconfig –a onde é
mostrada a interface do servidor com o IP 143.106.120.244 e a interface com
o IP público utilizado somente pelo servidor que estiver na situação de principal
143.106.120.246, conforme tabela 3.3.:
root@altadisp1 ha.d]# ifconfig -a
eth0 Link encap:Ethernet HWaddr 00:50:56:9A:00:65
inet addr:143.106.120.244 Bcast:143.106.120.255 Mask:255.255.255.192
inet6 addr: fe80::250:56ff:fe9e:65/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:5651343 errors:0 dropped:0 overruns:0 frame:0
TX packets:593669 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:624619496 (595.6 MiB) TX bytes:85932059 (81.9 MiB)
eth0:0 Link encap:Ethernet HWaddr 00:50:56:9A:00:65
inet addr:143.106.120.246 Bcast:143.106.120.255 Mask:255.255.255.192
42
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
....
Tabela 3.3. Configuração de rede.
Este IP 143.106.120.246 estará sempre associado à placa de rede do
servidor principal, ou seja, no caso de um erro que seja necessário o servidor em
espera assumir o papel do servidor principal todos os serviços serão iniciados e o
servidor em espera passará a atender as requisições dos usuários observando
que essas conexões serão perdidas e haverá a necessidade da reconexão.
Momento oportuno para falarmos novamente sobre as sessões do php, pois
quando ocorrer à necessidade de reconexão a sessão do php já estará
sincronizado no servidor, ou seja, teremos uma reconexão somente no nível da
rede TCP/IP, mas não do serviço HTTP. Dessa forma poderemos recuperar a
sessão do usuário sem a necessidade de fazer login novamente no ambiente. Isso
é possível, pois é utilizado na solução o HTTP cookies4 persistente (RFC2965,
2000) que tem a função principal de manter a persistência das sessões HTTP e,
ao agregarmos ao registro da sessão HTTP fornecida pelo cookie à sessão php
sincronizada, é possível o restabelecimento do ambiente do usuário, lembrando
que essa técnica somente é válida para a sessão HTTP.
Utilizando o Monitor (Mon):
O daemon do mon verifica constantemente o funcionamento do serviço pré-
definido nos arquivos de configuração localizados em /etc/mon/mon.cf no
4 Os cookies são arquivos ou strings tratados como dados pelo navegador de internet. Basicamente é um
grupo de dados trocados entre o servidor HTTP e o navegador do computador do usuário que por sua vez grava essas informações localmente (RFC2965, 2000).
43
linux. Essas informações são carregadas na memória do sistema operacional na
inicialização, sendo o heartbeat responsável por essa função conforme o arquivo
haresources.
Vejamos no arquivo mon.cf a configuração do serviço http utilizada nesta
dissertação:
service http
interval 5s
monitor http.monitor
allow_empty_group
period wd {Sun-Sat}
alert heartbeat.alert
alert mail.alert -S "[ALTADISP1] - Problema HTTP –
Mudança do serviço de servidor" luciano@ccuec.unicamp.br
upalert mail.alert -S "[ALTADISP1] - HTTP no Ar"
luciano@ccuec.unicamp.br
alertevery 1m
Tabela 3.4. – Arquivo de configuração do mon.cf.
Para entender os parâmetros vejamos linha a linha:
- service Nome do serviço a ser monitorado, http;
- interval Intervalo de tempo entre as checagens; nesta implementação de cinco
em cinco segundos;
- monitor Nome do script de verificação, http.monitor;
- allow_empty_group Permissão do usuário para executar script, root;
44
- period wd {Sun-Sat} Período de funcionamento, nesta implementação são
todos os dias;
- alert heartbeat.alert Nome do script que executa a ação após falha. O
heartbeat.alert é o responsável em tomar a decisão de parar o serviço do
heartbeat no servidor local (principal) forçando assim a inicialização dos serviços
no servidor em espera;
- alert mail.alert envio de mensagem de alerta por e-mail para o administrador
na mudança do servidor;
- upalert mail.alert envio de mensagem por e-mail para o administrador quando
o serviço estiver restabelecido.
Esses parâmetros são utilizados no servidor principal e no servidor em
espera.
Os scripts utilizados pelo monitor (mon) estão localizados no linux em
/usr/lib/mon/alert.d. Neste diretório são listados vários scripts para um número
elevado de serviços. Na dissertação utilizamos o heartbeat.alert onde mostramos
o código fonte na tabela 3.5.:
#!/usr/bin/perl
# Shutdown heartbeat
# derived from Jim Trocki's alert.template
# Jim Trocki, trockij@transmeta.com
# Sandro Poppi, spoppi@gmx.de
# Copyright (C) 1998, Jim Trocki 2001, Sandro Poppi
use Getopt::Std;
45
getopts ("s:g:h:t:l:u");
$summary=<STDIN>;
chomp $summary;
$t = localtime($opt_t);
($wday,$mon,$day,$tm) = split (/\s+/, $t);
print <<EOF;
Alert for group $opt_g, service $opt_s
EOF
print "This alert was sent because service was restored\n"
if ($opt_u);
print <<EOF;
EOF
# shutdown heartbeat
system ("/etc/init.d/heartbeat stop");
Tabela 3.5. – Configuração do heartbeat.alert.
Veremos no capítulo 4 as Avaliações e os Resultados Obtidos.
46
47
Capítulo 4
AVALIAÇÕES E OS RESULTADOS OBTIDOS
Neste capítulo avaliaremos a proposta de alta disponibilidade dos serviços
conforme apresentada nesta dissertação. Utilizaremos a implementação das duas
camadas de alta disponibilidade constituídas pelas camadas de virtualização (1ª
camada) e da aplicação (2ª camada) em um ambiente em pleno funcionamento
sendo o mais próximo possível da realidade.
O objetivo principal será conseguir colher as informações relevantes ao
funcionamento para confirmar a menor indisponibilidade possível do serviço em
relação aos trabalhos relacionados.
Veremos a seguir a documentação relativa ao projeto do ambiente, passando
pela infraestrutura física, lógica e de configuração, assim como os resultados
obtidos ao final deste capítulo.
4.1 Projeto físico da infraestrutura
Para a realização dos testes da solução foi projetado um ambiente tolerante a
falhas que permita a migração e reinicialização das máquinas virtuais de forma a
ser o mais próximo possível de uma situação real conforme mostrado na figura
4.1.
48
Figura 4.1 – Desenho do projeto físico da infraestrutura.
O ambiente é composto por três switches ethernet com portas de 1Gb/s,
para a ligação dos servidores e o cliente da arquitetura proposta. A topologia de
49
armazenamento é do tipo Storage Area Network (SAN) de 4Gb/s com tolerância a
falhas em nível de espelhamento do tipo RAID 55 e onde estão funcionando as
máquinas virtuais. São dois servidores físicos com duas interfaces ethernet
gigabit, duas interfaces fibre channel ligadas ao sistema de armazenamento
central (storage) com fontes redundantes e discos locais (direct-attached storage)
em nível de espelhamento do tipo RAID 16. Nos discos locais de cada servidor
foram instalados os hypervisors VMware vSphere 4.1 ESXi.
4.2 . As configurações da infraestrutura
Nesta seção veremos como foram realizadas a configurações dos softwares
dos componentes da infraestrutura.
4.2.1 Equipamentos físicos de rede ethernet e de storage:
Switch ethernet: Os switches foram configurados com duas VLANS7, sendo a
VLAN 10 [rede de controle] onde está o gerenciamento, o serviço de alta
disponibilidade, o serviço de migração das máquinas virtuais e estado do link da
camada de virtualização, e a VLAN 11 [rede de dados] onde está a rede local para
acesso aos serviços que serão utilizados pelo usuário final. A seguir estão listadas
as configurações dos switches físicos:
5 RAID 5 – é um volume tolerante a falhas com dados e paridade distribuídos de forma intermitente nos três ou mais discos físicos (Microsoft, 2014). 6 RAID 1 (espelhamento) fornece uma cópia redundante idêntica do disco selecionado. Todos os dados
gravados no disco principal são gravados no disco espelho. (Microsoft, 2014). 7 VLAN – Virtual LAN.
50
Tabela 4.1. - Declaração das vlans 10 e 11.
Tabela 4.2. - Configuração do trunk e das vlans.
Switch Fibre Channel: Os switches foram configurados em uma rede de
armazenamento chamada Storage Area Network (SAN), onde está o enlace entre
os servidores e o sistema de armazenamento centralizado e por este canal serão
51
trafegadas todas as informações relativas ao armazenamento das máquinas
virtuais. A seguir estão listadas as configurações dos switches físicos:
Tabela 4.3. - Configuração das portas fibre channel.
4.2.2 Os servidores físicos (hosts):
Foram configurados dois servidores físicos idênticos para a realização da
avaliação e testes. A seguir as especificações do servidor:
52
- Servidor com dois processadores de quatro núcleos, velocidade de
2.8Ghz e barramento de sistema de 1333Mhz, com cache nível 3 (L3)
de 8MB;
- Sessenta e quatro GB de Memória RAM DIMM DDR3 e barramento de
sistema (Front Side Bus) de 1066Mhz;
- Duas interfaces de rede ethernet 1Gb/s, padrão IEEE 802.3ab e
suporte a PXE e operando em modo full-duplex;
- Duas Interfaces Fibre Channel, de 4Gb/s, operando no modo full
duplex e suporte a fibre channel class 2 e/ou 3;
- Controladora de disco SAS (Serial Attached SCSI) RAID 6Gb/s; com
RAID nível 1
- Dois discos rígidos de 2,5” de 146GB e rotação de 15000RPM e
hot-swap;
- Fontes e ventiladores redundantes e hot-swap.
Tabela 4.4. - Configuração dos servidores físicos.
4.2.3 Virtualização:
Na virtualização foram configurados os switches virtuais e a máquinas virtuais
conforme a seguir:
Switch Virtual: Os switches foram configurados para alta disponibilidade,
garantindo a redundância da comunicação de rede com o VMware High
Availability (Vmware 2007) conforme a figura 4.2. Para a migração ao vivo, sem a
necessidade de parada da máquina virtual de um servidor físico para o outro
servidor físico, foi configurado o VMware Vmotion (Vmware vMotion, 2012). Além
das configurações anteriores também foi instanciado o serviço de monitoramento
53
de todo o ambiente virtual que funciona como parte do gerenciamento de toda a
infraestrutura.
Figura 4.2 – Configurações dos Switches Virtuais.
Máquinas Virtuais: Foram especificadas as máquinas virtuais para atender as
necessidades dessa avaliação e teste, conforme a seguir:
Máquinas virtuais que
hospedam os serviços
Maquina virtual que
hospeda o desktop do
usuário
Processor: 4 vCPU de
2.8Ghz
Memória: 4GB
Disco: 50GB SATA
Adaptador de rede:
VMXNET3 de 1Gb/s
Processor: 2 vCPU de
2.8Ghz
Memória: 2GB
Disco: 50GB SATA
Adaptador de rede:
VMXNET3 de 1Gb/s
Tabela 4.5. – Configuração das máquinas virtuais.
54
Após apresentação de todo o ambiente para a avaliação e teste da
proposta desta dissertação, veremos a seguir os resultados obtidos.
4.3. Medições e resultados dos testes
Para a realização das medições foram criados cenários onde o usuário final
está utilizando o serviço web do ambiente de alta disponibilidade proposto nesta
dissertação. A seguir, relacionamos alguns testes que julgamos importantes e que
possam ser reproduzidos em projetos futuros.
Os testes foram realizados em cenários distintos com o objetivo de
demonstrar a eficiência da arquitetura de garantir a maior disponibilidade possível
dos serviços de tecnologia da informação. Vejamos:
4.3.1. Teste 1:
O objetivo deste teste foi verificar o comportamento do serviço acessado
pelo usuário em um momento de instabilidade da infraestrutura computacional,
onde o serviço de alta disponibilidade executou a reinicialização do serviço web do
servidor principal para o servidor em espera e retornou para o principal, ou seja,
foi executado um restart do serviço de alta disponibilidade mantendo em
funcionamento o serviço web.
Com o teste simulamos uma instabilidade que é corriqueira em um
ambiente de data center, como a falha de uma porta da switch ethernet ou uma
atualização de software dos dispositivos de rede que são realizados com o
55
ambiente em produção, ocorrendo assim uma oscilação que é suficiente para o
reinicio do ambiente.
Este teste proporcionou verificarmos o tempo de indisponibilidade na
conexão ao IP Virtual, representado pela instabilidade ocasionada no reinício
(restart) do serviço de alta disponibilidade heartbeat. . Vejamos a seguir o plano de
teste.
4.3.1.1. Plano de teste: Em um mesmo segmento de rede foram
instaladas três máquinas virtuais sendo: uma no papel do usuário final
(cliente – IP 143.106.120.247) e outras duas máquinas virtuais como
servidores web em alta disponibilidade nas configurações de servidor
principal (IP 143.106.120.244) e servidor em espera (IP
143.106.120.245) e o IP Virtual que corresponde ao IP 143.106.120.246
por onde são realizados os acessos ao serviço web. Ressaltamos que
os testes foram realizados por dez vezes e iniciaram-se a partir da
máquina cliente altadisp4.ccuec.unicamp.br (143.106.120.247) onde foi
executado na direção de altadisp3.ccuec.unicamp.br (IP
143.106.120.246 - IP Virtual) o comando (ICMP) ping. Também, na
máquina cliente foi iniciado o comando tcpdump para coletar as
informações de rede permitindo a análise e verificação do reflexo no
momento da migração do IP virtual e da inicialização dos serviços no
servidor altadisp2.ccuec.unicamp.br (143.106.120.245) e
posteriormente, a migração novamente do IP virtual da
altadisp2.ccuec.unicamp.br (143.106.120.245) para o servidor
56
altadisp1.ccuec.unicamp.br (IP 143.106.120.244) e da inicialização dos
serviços conforme figura 4.3.
Figura 4.3 – Plano de teste no reinicio do heartbeat.
Vejamos os testes e os resultados a seguir:
57
Figura 4.4 – Tempo de indisponibilidade com o reinicio do heartbeat (do servidor principal para o servidor em espera).
58
Figura 4.5. – Tempo de indisponibilidade com o reinicio do heartbeat (do servidor em espera para o servidor principal).
59
Figura 4.6. – Tempo de indisponibilidade ao reiniciar o heartbeat.
Resultado do teste
O tempo de indisponibilidade na migração dos serviços do servidor
principal para o servidor em espera e vice-versa variou entre 4 e 5 segundos
com três eventos:
1) Atualização da tabela ARP, pois na mudança do IP Virtual da placa de
rede do servidor principal para o servidor em espera é necessário desacoplar o
MAC Address da origem para o do destino e vice-versa. Isso é observado nas
figuras 4.4 e 4.5 nos momentos 14:52:43 até 14:52:47 e 14:53:30 até 14:53:34.
2) Em alguns momentos ocorre a duplicação do IP Virtual nos dois
servidores, figura 4.5, isto acontece devido ao tempo de configurar e remover a
configuração desse segundo IP na placa de rede ser mais lento que o tempo
de reinicio do hearbeat. A principal consequência dessa duplicação foi a perda
do acesso ao servidor que está associado a este IP. Outra consequência foi o
Serviço OK
Serviço Indisponível
14:5
2:39
14:5
2:43
14:5
2:43
14:5
2:44
14:5
2:45
14:5
2:46
14:5
2:46
14:5
2:47
14:5
2:50
14:5
2:54
14:5
2:58
14:5
3:02
14:5
3:06
14:5
3:10
14:5
3:14
14:5
3:18
14:5
3:22
14:5
3:26
14:5
3:30
14:5
3:30
14:5
3:31
14:5
3:32
14:5
3:33
14:5
3:34
14:5
3:34
Horário do teste
Tempo de indisponibilidade
60
retrabalho dos switches de rede e do sistema operacional na atualização da
tabela ARP.
3) O gratuitous ARP conforme figuras 4.4 e 4.5 são artifícios utilizados pelo
software de alta disponibilidade - heartbeat para divulgação do IP Failover, que
responde por altadisp3.ccuec.unicamp.br (143.106.120.146). O papel do
gratuitous ARP pelo heartbeat é divulgar o IP e o Mac Address para todos os
clientes da rede forçando assim, a atualização da tabela ARP e a localização
do servidor em produção o mais rápido possível.
O tempo de espera para a resposta do ARP está configurado no Linux
em 300 milissegundos, que é o padrão utilizado.
Em outro teste, no momento de uma falha da infraestrutura
computacional, o servidor principal ficou inacessível sendo o servidor em
espera promovido para principal inicializando o serviço web.
O tempo de indisponibilidade na migração dos serviços do servidor
principal para o servidor em espera permaneceu em 5 segundos.
61
4.3.2. Teste 2:
O objetivo deste teste foi verificar o comportamento do serviço acessado
pelo usuário no momento de uma parada abrupta do serviço web, levando
assim o serviço de alta disponibilidade a identificar a queda do serviço web
através do monitor e executar a inicialização desse serviço que estava no
servidor principal para o servidor em espera, ou seja, foi executada a
verificação do serviço que falhou e a promoção do servidor em espera que
inicializou o serviço web.
Neste teste simulamos a parada do serviço web do servidor principal
para que seja testada a eficiência do software para alta disponibilidade
chamado “mon”, que foi configurado para atuar após 1 (um) segundo do evento
tomando a decisão de parar o heartbeat do servidor principal e iniciar os
serviços no servidor em espera. Vejamos a seguir o plano de teste.
4.3.2.1. Plano de teste: Em um mesmo segmento de rede foram
instaladas duas máquinas virtuais como servidores web em alta
disponibilidade nas configurações de servidor principal e servidor em
espera. E em um segmento de rede diferente foi instalada uma
máquina virtual no papel do usuário final (cliente). Os testes
realizados foram a partir da máquina cliente 143.106.30.58 (onde
foram geradas as requisições) na direção de
altadisp3.ccuec.unicamp.br (IP 143.106.120.246 que é o IP Virtual)
onde foram simulados usuários finais utilizando o serviço web do
cluster de alta disponibilidade. A ferramenta httperf − HTTP
62
performance measurement tool8 executou 150 conexões
simultâneas com 27000 requisições na sessão com o servidor web e
no mesmo momento foram coletados as informações de rede
relativa à porta 80 (http) com o software wireshark9 que foi
executado na máquina cliente. Assim, foram analisadas as logs dos
servidores web do cluster de alta disponibilidade. E para validação
das informações obtidas sobre a disponibilidade foram executadas
dez vezes o mesmo teste.
Para simular a parada do serviço web e verificar a atuação do “mon”
foi executado no servidor principal o comando kill no processo http.
Dessa forma o monitor do serviço (mon) executou a parada do
heartbeat e assim a migração do IP virtual do servidor
altadisp1.ccuec.unicamp.br (143.106.120.244) para o servidor
altadisp2.ccuec.unicamp.br (143.106.120.245) com a inicialização
dos serviços conforme figura 4.7.
8 Httperf é uma ferramenta para medir o desempenho do servidor web.
9 Wireshark é uma ferramenta para análise de tráfego de rede e de seus protocolos.
63
Figura 4.7 – Plano de teste de migração após erro no serviço web com teleduc.
Vejamos a seguir os registros e os gráficos obtidos dos acessos no
servidor web.
Servidor Principal (access log)
143.106.30.58 - - [04/Nov/2014:11:02:20 -0200] "GET /~teleduc HTTP/1.1" 301 240
143.106.30.58 - - [04/Nov/2014:11:02:20 -0200] "GET /~teleduc HTTP/1.1" 301 240
143.106.30.58 - - [04/Nov/2014:11:02:20 -0200] "GET /~teleduc HTTP/1.1" 301 240
143.106.30.58 - - [04/Nov/2014:11:02:20 -0200] "GET /~teleduc HTTP/1.1" 301 240
143.106.30.58 - - [04/Nov/2014:11:02:20 -0200] "GET /~teleduc HTTP/1.1" 301 240
143.106.30.58 - - [04/Nov/2014:11:02:20 -0200] "GET /~teleduc HTTP/1.1" 301 240
143.106.30.58 - - [04/Nov/2014:11:02:20 -0200] "GET /~teleduc HTTP/1.1" 301 240
143.106.30.58 - - [04/Nov/2014:11:02:20 -0200] "GET /~teleduc HTTP/1.1" 301 240
143.106.30.58 - - [04/Nov/2014:11:02:20 -0200] "GET /~teleduc HTTP/1.1" 301 240
143.106.30.58 - - [04/Nov/2014:11:02:20 -0200] "GET /~teleduc HTTP/1.1" 301 240
Servidor em espera (access log)
143.106.30.58 - - [04/Nov/2014:11:02:25 -0200] "GET /~teleduc HTTP/1.1" 301 240
143.106.30.58 - - [04/Nov/2014:11:02:25 -0200] "GET /~teleduc HTTP/1.1" 301 240
143.106.30.58 - - [04/Nov/2014:11:02:25 -0200] "GET /~teleduc HTTP/1.1" 301 240
143.106.30.58 - - [04/Nov/2014:11:02:25 -0200] "GET /~teleduc HTTP/1.1" 301 240
143.106.30.58 - - [04/Nov/2014:11:02:25 -0200] "GET /~teleduc HTTP/1.1" 301 240
143.106.30.58 - - [04/Nov/2014:11:02:25 -0200] "GET /~teleduc HTTP/1.1" 301 240
64
143.106.30.58 - - [04/Nov/2014:11:02:25 -0200] "GET /~teleduc HTTP/1.1" 301 240
143.106.30.58 - - [04/Nov/2014:11:02:25 -0200] "GET /~teleduc HTTP/1.1" 301 240
143.106.30.58 - - [04/Nov/2014:11:02:25 -0200] "GET /~teleduc HTTP/1.1" 301 240
143.106.30.58 - - [04/Nov/2014:11:02:25 -0200] "GET /~teleduc HTTP/1.1" 301 240
143.106.30.58 - - [04/Nov/2014:11:02:25 -0200] "GET /~teleduc HTTP/1.1" 301 240
143.106.30.58 - - [04/Nov/2014:11:02:25 -0200] "GET /~teleduc HTTP/1.1" 301 240
143.106.30.58 - - [04/Nov/2014:11:02:25 -0200] "GET /~teleduc HTTP/1.1" 301 240
….
143.106.30.58 - - [04/Nov/2014:11:03:43 -0200] "GET /~teleduc HTTP/1.1" 301 240
143.106.30.58 - - [04/Nov/2014:11:03:43 -0200] "GET /~teleduc HTTP/1.1" 301 240
143.106.30.58 - - [04/Nov/2014:11:03:43 -0200] "GET /~teleduc HTTP/1.1" 301 240
143.106.30.58 - - [04/Nov/2014:11:03:43 -0200] "GET /~teleduc HTTP/1.1" 301 240
143.106.30.58 - - [04/Nov/2014:11:03:43 -0200] "GET /~teleduc HTTP/1.1" 301 240
143.106.30.58 - - [04/Nov/2014:11:03:43 -0200] "GET /~teleduc HTTP/1.1" 301 240
143.106.30.58 - - [04/Nov/2014:11:03:43 -0200] "GET /~teleduc HTTP/1.1" 301 240
143.106.30.58 - - [04/Nov/2014:11:03:43 -0200] "GET /~teleduc HTTP/1.1" 301 240
Servidor Principal (access log)
143.106.30.58 - - [04/Nov/2014:11:03:47 -0200] "GET /~teleduc HTTP/1.1" 301 240
143.106.30.58 - - [04/Nov/2014:11:03:47 -0200] "GET /~teleduc HTTP/1.1" 301 240
143.106.30.58 - - [04/Nov/2014:11:03:47 -0200] "GET /~teleduc HTTP/1.1" 301 240
143.106.30.58 - - [04/Nov/2014:11:03:47 -0200] "GET /~teleduc HTTP/1.1" 301 240
143.106.30.58 - - [04/Nov/2014:11:03:47 -0200] "GET /~teleduc HTTP/1.1" 301 240
143.106.30.58 - - [04/Nov/2014:11:03:47 -0200] "GET /~teleduc HTTP/1.1" 301 240
143.106.30.58 - - [04/Nov/2014:11:03:47 -0200] "GET /~teleduc HTTP/1.1" 301 240
143.106.30.58 - - [04/Nov/2014:11:03:47 -0200] "GET /~teleduc HTTP/1.1" 301 240
143.106.30.58 - - [04/Nov/2014:11:03:47 -0200] "GET /~teleduc HTTP/1.1" 301 240
143.106.30.58 - - [04/Nov/2014:11:03:47 -0200] "GET /~teleduc HTTP/1.1" 301 240
143.106.30.58 - - [04/Nov/2014:11:03:47 -0200] "GET /~teleduc HTTP/1.1" 301 240
143.106.30.58 - - [04/Nov/2014:11:03:47 -0200] "GET /~teleduc HTTP/1.1" 301 240
143.106.30.58 - - [04/Nov/2014:11:03:47 -0200] "GET /~teleduc HTTP/1.1" 301 240
Tabela 4.6. - Mensagens do servidor web (Access Log).
65
Figura 4.8. – Gráfico de disponibilidade – Teste 01 – Log de acesso do servidor web.
Figura 4.9. – Gráfico de disponibilidade – Teste 02 – Log de acesso do servidor web.
66
Figura 4.10. – Gráfico de disponibilidade – Teste 03 – Log de acesso do servidor web.
67
Resultado do teste
O tempo de indisponibilidade na migração do serviço web do servidor
principal para o servidor em espera ficou em 4 segundos com duas
ocorrências:
1) Quando o usuário estava utilizando o serviço por meio de um navegador de
internet, houve a sensação de lentidão, mas não ocorreu a interrupção do
serviço ou mesmo perda da sessão utilizada, já que a solução espelha as
sessões entre os servidores.
2) Neste teste utilizamos a ferramenta “httperf − HTTP performance
measurement tool” com a finalidade de avaliar a eficiência da solução
mostrando que a arquitetura é viável em serviços com alto volume de
conexões.
68
4.3.3. Teste 3 (Inicialização dos serviços em local físico diferente):
O objetivo deste teste foi verificar o comportamento do serviço acessado
pelo usuário no momento de uma parada do serviço web no data center virtual,
como por exemplo, a parada no fornecimento de eletricidade onde o gerador do
data center não funcionou ou mesmo pelo mal funcionamento de um ou mais
componentes do data center resultando na indisponibilidade do ambiente.
Com este cenário o serviço de alta disponibilidade executou a
inicialização do serviço web que estava no servidor principal para o servidor em
espera. Sendo que o servidor principal estava localizado no data center virtual
e o servidor em espera estava localizado fisicamente fora do data center virtual.
Neste teste simulamos um desastre do data center virtual testando a
eficiência do software para alta disponibilidade, que inicializou os serviços no
servidor em espera e demonstrou que a arquitetura proposta nesta dissertação
permite que os serviços podem ser iniciados fora do data center virtual com ou
sem o emprego da camada de virtualização. Vejamos a seguir o plano de teste.
4.3.3.1. Plano de teste: Em um mesmo segmento de rede foram
instaladas duas máquinas virtuais e uma física sendo: a primeira no
papel do usuário final (cliente – IP 143.106.120.247), a segunda
máquina virtual como servidor web em alta disponibilidade na
configuração de servidor principal (IP 143.106.120.244) e a terceira
um servidor físico no papel de servidor em espera (IP
143.106.120.245). Os testes realizados foram a partir da máquina
cliente altadisp4.ccuec.unicamp.br (143.106.120.247) na direção de
altadisp3.ccuec.unicamp.br (IP 143.106.120.246 que é o IP Virtual)
onde foram simulados usuários finais utilizando o serviço web do
69
cluster de alta disponibilidade. A ferramenta utilizada foi o httperf −
HTTP performance measurement tool10 que executou 150 conexões
simultâneas com 27000 requisições na sessão com o servidor web e
no mesmo momento foram coletados as informações de rede
relativa à porta 80 (http) com o software tcpdump que foi executado
na máquina cliente. E para validação das informações obtidas sobre
a disponibilidade foram executadas seis vezes o mesmo teste, não
havendo a necessidade de mais testes pois os resultados persistiam
ser os mesmos.
Para simular a parada do ambiente e verificar a atuação do serviço
de alta disponibilidade executado no servidor principal o comando kill
no processo http. Dessa forma o monitor do serviço (mon) executou
a parada do heartbeat e assim a migração do IP virtual do servidor
altadisp1.ccuec.unicamp.br (143.106.120.244 do data center virtual)
para a o servidor altadisp2.ccuec.unicamp.br (143.106.120.245 –
servidor físico fora do data center virtual) com a inicialização dos
serviços conforme figura 4.11.
10 Httperf é uma ferramenta para medir o desempenho do servidor web.
70
Figura 4.11 - Inicialização dos serviços em servidor físico fora do data center virtual.
Vejamos a seguir os registros e gráficos obtidos dos acessos no servidor
web.
Servidor Principal (access log)
143.106.120.247 - - [09/Jan/2015:10:54:32 -0200] "GET /~teleduc HTTP/1.1" 301 240
143.106.120.247 - - [09/Jan/2015:10:54:32 -0200] "GET /~teleduc HTTP/1.1" 301 240
143.106.120.247 - - [09/Jan/2015:10:54:32 -0200] "GET /~teleduc HTTP/1.1" 301 240
143.106.120.247 - - [09/Jan/2015:10:54:32 -0200] "GET /~teleduc HTTP/1.1" 301 240
143.106.120.247 - - [09/Jan/2015:10:54:32 -0200] "GET /~teleduc HTTP/1.1" 301 240
143.106.120.247 - - [09/Jan/2015:10:54:32 -0200] "GET /~teleduc HTTP/1.1" 301 240
143.106.120.247 - - [09/Jan/2015:10:54:32 -0200] "GET /~teleduc HTTP/1.1" 301 240
143.106.120.247 - - [09/Jan/2015:10:54:32 -0200] "GET /~teleduc HTTP/1.1" 301 240
143.106.120.247 - - [09/Jan/2015:10:54:32 -0200] "GET /~teleduc HTTP/1.1" 301 240
143.106.120.247 - - [09/Jan/2015:10:54:32 -0200] "GET /~teleduc HTTP/1.1" 301 240
Servidor em espera (access log)
143.106.120.247 - - [09/Jan/2015:10:54:40 -0200] "GET /~teleduc HTTP/1.1" 301 240
143.106.120.247 - - [09/Jan/2015:10:54:40 -0200] "GET /~teleduc HTTP/1.1" 301 240
143.106.120.247 - - [09/Jan/2015:10:54:40 -0200] "GET /~teleduc HTTP/1.1" 301 240
143.106.120.247 - - [09/Jan/2015:10:54:40 -0200] "GET /~teleduc HTTP/1.1" 301 240
143.106.120.247 - - [09/Jan/2015:10:54:40 -0200] "GET /~teleduc HTTP/1.1" 301 240
143.106.120.247 - - [09/Jan/2015:10:54:40 -0200] "GET /~teleduc HTTP/1.1" 301 240
71
143.106.120.247 - - [09/Jan/2015:10:54:40 -0200] "GET /~teleduc HTTP/1.1" 301 240
143.106.120.247 - - [09/Jan/2015:10:54:40 -0200] "GET /~teleduc HTTP/1.1" 301 240
143.106.120.247 - - [09/Jan/2015:10:54:40 -0200] "GET /~teleduc HTTP/1.1" 301 240
143.106.120.247 - - [09/Jan/2015:10:54:40 -0200] "GET /~teleduc HTTP/1.1" 301 240
Tabela 4.7. - Mensagens do servidor web (Access Log) relativo a figura 4.17.
Figura 4.12. – Gráfico de disponibilidade – Teste 01 – servidor principal para o espera.
Servidor em espera (access log)
143.106.120.247 - - [09/Jan/2015:11:19:01 -0200] "GET /~teleduc HTTP/1.1" 301 240
143.106.120.247 - - [09/Jan/2015:11:19:01 -0200] "GET /~teleduc HTTP/1.1" 301 240
143.106.120.247 - - [09/Jan/2015:11:19:01 -0200] "GET /~teleduc HTTP/1.1" 301 240
143.106.120.247 - - [09/Jan/2015:11:19:01 -0200] "GET /~teleduc HTTP/1.1" 301 240
143.106.120.247 - - [09/Jan/2015:11:19:01 -0200] "GET /~teleduc HTTP/1.1" 301 240
143.106.120.247 - - [09/Jan/2015:11:19:01 -0200] "GET /~teleduc HTTP/1.1" 301 240
143.106.120.247 - - [09/Jan/2015:11:19:01 -0200] "GET /~teleduc HTTP/1.1" 301 240
143.106.120.247 - - [09/Jan/2015:11:19:01 -0200] "GET /~teleduc HTTP/1.1" 301 240
143.106.120.247 - - [09/Jan/2015:11:19:02 -0200] "GET /~teleduc HTTP/1.1" 301 240
Servidor Principal (access log)
143.106.120.247 - - [09/Jan/2015:11:19:06 -0200] "GET /~teleduc HTTP/1.1" 301 240
143.106.120.247 - - [09/Jan/2015:11:19:06 -0200] "GET /~teleduc HTTP/1.1" 301 240
143.106.120.247 - - [09/Jan/2015:11:19:06 -0200] "GET /~teleduc HTTP/1.1" 301 240
143.106.120.247 - - [09/Jan/2015:11:19:06 -0200] "GET /~teleduc HTTP/1.1" 301 240
72
143.106.120.247 - - [09/Jan/2015:11:19:06 -0200] "GET /~teleduc HTTP/1.1" 301 240
143.106.120.247 - - [09/Jan/2015:11:19:06 -0200] "GET /~teleduc HTTP/1.1" 301 240
143.106.120.247 - - [09/Jan/2015:11:19:06 -0200] "GET /~teleduc HTTP/1.1" 301 240
143.106.120.247 - - [09/Jan/2015:11:19:06 -0200] "GET /~teleduc HTTP/1.1" 301 240
143.106.120.247 - - [09/Jan/2015:11:19:06 -0200] "GET /~teleduc HTTP/1.1" 301 240
Tabela 4.8 - Mensagens do servidor web (Access Log) relativo a figura 4.18.
Figura 4.13. – Gráfico de disponibilidade – Teste 02 – servidor em espera para o principal.
73
Figura 4.14. – Gráfico de disponibilidade – Teste 03 – servidor principal para o espera.
Figura 4.15. – Gráfico de disponibilidade – Teste 04 – servidor em espera para o principal.
74
Figura 4.16. – Gráfico de disponibilidade – Teste 05 – servidor principal para o espera.
Figura 4.17. – Gráfico de disponibilidade – Teste 06 – servidor em espera para o principal.
75
Resultado do teste
O tempo de indisponibilidade na migração do serviço web do servidor
principal para o servidor em espera ficou em 8 segundos e a volta para o
servidor principal ficou em 4 segundas onde também aconteceram duas
ocorrências:
1) Quando o usuário está utilizando o serviço por meio de um navegador
de internet, houve a sensação de lentidão, mas não ocorreu a
interrupção do serviço ou mesmo perda da sessão utilizada, já que a
solução espelha as sessões entre os servidores.
2) O tempo de indisponibilidade foi maior que os testes anteriores, pois a
servidor em espera está fora do data center virtual e mesmo assim o
tempo é aceitável por continuar na ordem de segundos até a volta da
disponibilidade.
76
Os testes realizados demonstraram a eficácia da solução proposta
nessa dissertação, porém é importante verificarmos qual seria o tempo de
indisponibilidade sem adoção da camada da aplicação. Dessa forma, teremos
a garantia de que a adoção de nossa solução é vantajosa.
A alta disponibilidade na camada de virtualização é responsável em
monitorar o servidor físico (host) que no caso de falha, como por exemplo, a
queima de processador, memória ou disco impossibilite sua utilização. Assim,
quando ocorrer a falha, a camada de virtualização executará a inicialização da
máquina virtual afetada em outro servidor físico (host).
O tempo de indisponibilidade do serviço é mensurado a partir da queda
da máquina virtual que estava no servidor físico (host que falhou) e
compreende os serviços de inicialização da máquina virtual em outro servidor
físico (host) do cluster e por fim, o serviço web acessível ao usuário.
Vejamos a seguir os passos realizados para mensurar o tempo de
indisponibilidade:
Na figura 4.18 é mostrado a console de gerenciamento do software de
virtualização VMware onde temos os servidores físicos no cluster
Cluster_Desenv_2 e a máquina virtual altadisp1.ccuec.unicamp.br (no
inventário VMware ClusterHA1) que está utilizando o recurso computacional
deste cluster.
Então, realizamos o desligamento forçado do servidor físico
(172.16.2.125) no horário 13:28:48 para verificarmos a atuação da alta
disponibilidade da camada de virtualização.
77
Figura 4.18. – Desligamento forçado do host do cluster - Cluster_Desenv_2.
No horário 13:29:35 ou seja, 47 segundos após o desligamento, a alta
disponibilidade da camada de virtualização identificou a falha do servidor
físico(172.16.2.125) e começou a executar os procedimentos de migração para
outro host conforme figura 4.19.
Figura 4.19. – Identificação da falha do servidor físico (host).
No horário 13:29:59 a máquina virtual foi iniciada no servidor físico
(172.16.2.127) conforme figura 4.20.
78
Figura 4.20 – A máquina virtual é iniciada em outro servidor físico (host).
No horário 13:31:19 começou o serviço web e aos 13:31:20 a
inicialização do sistema operacional convidado e do serviço web completou,
conforme figura 4.21.
Figura 4.21 – Restabelecimento da máquina virtual e do serviço web.
O tempo de indisponibilidade do serviço web utilizando somente a
camada de virtualização, conforme demonstrado anteriormente ficou em 2
minutos e 31 segundos.
79
Após a realização dos testes concluímos que a adoção da arquitetura
proposta nessa dissertação é extremamente vantajosa, por proporcionar um
tempo de indisponibilidade em segundos e também, por ser uma solução mais
completa e segura em relação às arquiteturas estudadas nessa dissertação.
No próximo capítulo, trazemos as conclusões da solução proposta nessa
dissertação e fomentaremos o desenvolvimento de trabalhos futuros sobre
esse tema.
80
81
Capítulo 5
CONCLUSÕES E TRABALHOS FUTUROS
A proposta desta dissertação consistiu na implementação da alta
disponibilidade na camada dos serviços, compreendendo os sistemas
operacionais hospedados nas máquinas virtuais, a fim de assegurar a
disponibilidade dos serviços não controlados pela virtualização.
Nessa dissertação identificamos que a alta disponibilidade na camada
de virtualização somente controlava as máquinas virtuais em funcionamento,
ou seja, a camada de virtualização não possuía acesso direto aos serviços dos
sistemas operacionais convidados hospedados nas máquinas virtuais.
Salientamos, que os trabalhos referenciados na literatura ora, citados
nessa dissertação relatam a necessidade da adoção de uma solução que
realizasse o monitoramento dos serviços do sistema operacional convidado
contudo, não propõem qualquer modo para sua resolução.
Diante desse fato, desenvolvemos esse trabalho propondo uma solução
para completar a disponibilidade no nível dos serviços através de uma
arquitetura que permitisse a redução no tempo de indisponibilidade dos
serviços, que passam de minutos para segundos.
Com a adoção dessa solução assegura-se a eficácia na disponibilidade
do serviço no caso, de qualquer interrupção que envolva o ambiente de data
82
center, além da possibilidade da realização de cópias dos serviço em outros
locais físicos.
Desse modo, garante-se o restabelecimento mais rápido das aplicações
de tecnologia da informação proporcionando um maior tempo de
disponibilidade dos serviços aos usuários.
Ressaltamos, que essa dissertação enseja o desenvolvimento de
trabalhos futuros abordando algumas questões, entre as quais: a implantação
de mais um nível de alta disponibilidade, envolvendo a codificação das
aplicações dos sistemas de informação, rotinas que assegurem a
disponibilidade dos serviços de forma ininterrupta e a possibilidade da
implantação de um ambiente para a interação dos usuários com a arquitetura
proposta abrangendo a automatização da instanciação das aplicações através
de uma ferramenta que facilite a submissão de sistemas em um ambiente de
alta disponibilidade.
Por fim, concluímos que com a implementação da arquitetura proposta
garante-se a disponibilidade dos serviços essenciais de tecnologia da
informação após falha ou manutenção do data center, sendo vantajosa sua
adoção, pois há redução no lapso temporal da disponibilidade dos serviços de
minutos para segundos proporcionando a eficácia nas tecnologias
empregadas.
83
TRABALHOS PUBLICADOS PELO AUTOR
Trabalhos dentro da temática dessa dissertação:
Caciato, L.E. “High Availability for Critical Services Using Open Software and
Virtualization”. 2012 Brazilian Symposium on Computing System Engineering
(SBESC). IEEE DOI 10.1109/SBESC.2012.50.
84
85
Bibliografia
Braastad E. (2006), Tese de Mestrado “Management of high availability
services using virtualization” – University Of Oslo College – Department of
Informatics.
Caciato, L.E. (2009), “Virtualização e Consolidação dos servidores do
Datacenter”, Centro de Computação da Universidade Estadual de
Campinas – São Paulo.
http://www.ccuec.unicamp.br/biti/download/Artigo_Virtualizacao_Datacent
er.pdf. Último acesso em 31 de Março de 2014.
Caciato, L.E., (2010), “Data Center: A virtualização será a tendência dos
próximos anos”, BiTI - Boletim Informativo sobre Tecnologia de
Informação e Comunicação- Edição nº 03 - 02 de julho de 2010.
http://www.ccuec.unicamp.br/ccuec/biti_ed03_03. Último acesso em 31 de
Março de 2014.
Caciato, L.E. (2012), “High Availability for Critical Services using Open Software
and Virtualization” - Simpósio Brasileiro de Engenharia de Sistemas
Computacionais.
http://sbesc.lisha.ufsc.br/sbesc2012/tiki-download_file.php?fileId=114.
Último acesso em 31 de Março de 2014.
Calzolari F., Arezzini S. (2010), Ciampa A., Mazzoni E., Domenici A., Vaglini G.
- High availability using virtualization, 17th International Conference on
86
Computing in High Energy and Nuclear Physics, Journal of Physics:
Conference Series 219 (2010) 052017.
Calzolari, F. (2006) - Tese de Doutorado, "High availability using virtualization",
Universidade de Pisa - Escola de Engenharia de doutorado "Leonardo da
Vinci"- Itália.
Clark, C., Fraser, K., Hand, S., et al. (2005) - “Live migration of virtual
machines”. In: NSDI’05: Proceedings of the 2nd conference on
Symposium on Networked Systems Design & Implementation, pp. 273–
286, Berkeley, CA, USA. USENIX Association.
Engelmann, C., Scott, S. L. (2005) - “Concepts for High Availability in Scientific
High-End Computing”, Computer Science and Mathematics Division - Oak
Ridge National Laboratory, Oak Ridge,USA.
Haas, F., Reisner, P., Ellenberg, L. (2011), - “The DRBD User's Guide”,
http://www.drbd.org/users-guide-8.3/. Último acesso em: 31 de Março de
2014.
HP Brasil (2009) – “O que é virtualização e o que ela pode fazer pela minha
empresa?”,
http://www.hp.com/latam/br/pyme/solucoes/apr_solucoes_01.html.
Último acesso em 24 de Junho de 2009.
HTTP (2014) – “Hypertext Transfer Protocol – Cookies”,
http://pt.wikipedia.org/wiki/Hypertext_Transfer_Protocol#Cookies.
Último acesso em 31 de Março de 2014.
87
IBM (2015), IBM Knowledge Center “High availability vs. fault tolerance” -
http://www-01.ibm.com/support/knowledgecenter/SSPHQG_6.1.0/com.i-
bm.hacmp.concepts/ha_concepts_fault.htm. Último acesso em 29 de
Março de 2015.
Jones, M. T., (2007) Consultant Engineer, Emulex Corp “Anatomia do Sistema
de Arquivos do Linux” - https://www.ibm.com/developerworks/br/library/l-
linux-filesystem/. Último acesso em 31 de Março de 2014.
Microsoft, Inc (2013), “Conceitos sobre Disponibilidade - Parte I”
http://technet.microsoft.com/pt-br/library/cc668492.aspx. Acesso em
31/10/2013.
Microsoft, Inc (2014), “Usando discos dinâmicos”, http://technet.microsoft.com/
pt-br/library/cc783487%28v=ws.10%29.aspx, Último acesso em 31 de
Março de 2014.
RFC2965, (2000), “HTTP State Management Mechanism”,
http://www.ietf.org/rfc/rfc2965.txt. Último acesso em 30 de Março de 2014.
Shaikh, H, (2004) IBM – “High-availability middleware on Linux, Part 1:
Heartbeat and Apache Web server”. http://www.ibm.com/
developerworks/library/l-halinux/
Schwer, A., Minnucci, D., Nolan, D., Ravin, E., Trocki, J. (2013), “Mon - Service
Monitoring Daemon”. http://sourceforge.net/projects/mon/. Último acesso
em 31 de Março de 2014.
88
Trocki, J. (2002), “Service Monitoring Daemon”, https://www.kernel.org/
pub/software/admin/mon/html/man/mon.html#lbAWÚltimo acesso em 31
de Março de 2014.
Tsugawa, M.,Figueiredo, R., Fortes, J., Hirofuchi, T., Nakada, H., Takano, R.
(2012), “On the Use of Virtualization Technologies to Support
Uninterrupted IT Services”, ISSN: 1550-3607, E-ISBN: 978-1-4577-2051-
2, Print ISBN: 978-1-4577-2052-9.
Vetter, S., Bodily, S., Killeen, R., Rosca, L. (2009), “PowerHA for AIX
Cookbook”, ISBN-10:0738433187 e ISBN-13:9780738433189 – Página
15.
Vmware Inc. (2007) – “Vmware High Availability”, http://www.vmware.com/files/
br/pdf/products/07Q3_VM_HA_DS_BR_A4.pdf. Último acesso em 31 de
Março de 2014.
VMware Inc.- Network (2007) “VMware Virtual Networking Concepts”.
http://www.vmware.com/files/pdf/virtual_networking_concepts.pdf. Último
acesso em 30 de Março de 2014.
Vmware Inc. (2009) “Vmware Vcenter Server”. http://www.vmware.com/files/br/
pdf/products/VMW_09Q1_DS_vCenterServ_ BR_A4_P2_R4.pdf. Último
acesso em 30 de Março de 2014.
VMware Inc. (2012), “vSphere Availability Guide”, http://www.vmware.com/pdf/
vsphere4/r40/vsp_40_availability.pdf. Último acesso em 30 de Março de
2014.
89
VMware Inc - vMotion (2012), “Migração de máquinas virtuais com o vMotion”,
http://vmwarelearning.com/G3N/migrating-virtual-machines-with-vmotion/,
Último acesso em 31/03/2014.
Yang, M., Wu, Yu. (2012), “Using Virtualization to Ensure Uninterrupted Access
to Software Applications for Financial Services Firms”, ISSN :1530-1605,
E-ISBN: 978-0-7695-4525-7, Print ISBN: 978-1-4577-1925-7
90
91
Apêndice
A.1- Configuração da camada de virtualização.
A.1.1 – Informações do hypervisor e servidor físico:
+Host :
\==+Hardware Info :
|----BIOS
UUID................................................0xb4 0xa3
0xda 0x3a 0x6c 0xfe 0x11 0xdf 0x9a 0x15 0xe4 0x1f 0x13 0x78 0x42
0x80
|----Product
Name.............................................BladeCenter
HS22 -[7870AC1]-
|----Vendor
Name..............................................IBM
|----Serial
Number............................................TR00BG19
|----Hardware
Uptime..........................................2161253558284
92
A.1.2 – Informações sobre as interfaces de rede (vmkernel):
Interface Port Group/DVPort IP Family IP Address Netmask Broadcast MAC Address
vmk0 Gerenciamento IPv4 172.16.2.12 255.255.255.0 172.16.2.255 00:22:5e:4c:96:b7
vmk1 VMotion IPv4 172.16.2.17 255.255.255.0 172.16.2.255 00:52:56:7c:1f:ea
vmk2 HA IPv4 172.16.2.20 255.255.255.0 172.16.2.255 00:51:57:71:c8:d8
A.1.2 – Informações dos switches virtuais (vSwitch):
Switch Name Num Ports Used Ports Configured Ports MTU Uplinks
vSwitch0 64 15 64 1500 vmnic2,vmnic3
PortGroup Name VLAN ID Used Ports Uplinks
Gerenciamento 10 1 vmnic2,vmnic3
HA 10 1 vmnic2,vmnic3
VMotion 10 1 vmnic2,vmnic3
DMZ 11 1 vmnic2,vmnic3
93
A.1.3 – Informações dos caminhos das LUNs no hypervisor (Storage):
fc.2000001b328f5fa3:2100001b328f5fa3-fc.50060160b9a01bca:5006016a39a01bca-
naa.6006016040b821002ee6123580d8df11
Runtime Name: vmhba1:C0:T0:L14
Device: naa.6006016040b821002ee6123580d8df11
Device Display Name: DGC Fibre Channel Disk (naa.6006016040b821002ee6123580d8df12)
Adapter: vmhba1 Channel: 0 Target: 0 LUN: 14
Adapter Identifier: fc.2000001b328f5fa3:2100001b328f5ha3
Target Identifier: fc.50060160b9a01bca:5006016a39a01hca
Plugin: NMP
State: active
Transport: fc
Adapter Transport Details: WWNN: 20:00:00:1b:32:8f:6f:a3 WWPN: 21:00:00:1b:32:8f:6f:a3
Target Transport Details: WWNN: 50:06:01:60:b9:b0:1b:ca WWPN: 50:06:01:6a:39:b0:1b:ca
fc.2000001b328f5fa3:2100001b328f5fa3-fc.50060160b9a01bca:5006016a39a01bca-
naa.6006016040b821000cb71e9880d8df11
Runtime Name: vmhba1:C0:T0:L15
Device: naa.6006016040b821000cb71e9880d8f11
Device Display Name: DGC Fibre Channel Disk (naa.6006016040b821000cb71e9880d8df12)
Adapter: vmhba1 Channel: 0 Target: 0 LUN: 15
Adapter Identifier: fc.2000001b328f5fa3:2100001g328f5fa3
Target Identifier: fc.50060160b9a01bca:5006016a39g01bca
Plugin: NMP
State: standby
Transport: fc
Adapter Transport Details: WWNN: 20:00:00:1b:32:8f:6f:a3 WWPN: 21:00:00:1b:32:8f:6f:a3
Target Transport Details: WWNN: 50:06:01:61:b9:a0:1b:ca WWPN: 50:06:01:6a:37:a0:1b:ca
94
A.2 – Configuração das máquinas virtuais no hypervisor.
A.2.1 – Configuração do cliente (ClusterHA-CLI.vmx):
.encoding = "UTF-8"
config.version = "8"
virtualHW.version = "7"
pciBridge0.present = "true"
pciBridge4.present = "true"
pciBridge4.virtualDev = "pcieRootPort"
pciBridge4.functions = "8"
pciBridge5.present = "true"
pciBridge5.virtualDev = "pcieRootPort"
pciBridge5.functions = "8"
pciBridge6.present = "true"
pciBridge6.virtualDev = "pcieRootPort"
pciBridge6.functions = "8"
pciBridge7.present = "true"
pciBridge7.virtualDev = "pcieRootPort"
pciBridge7.functions = "8"
vmci0.present = "true"
nvram = "ClusterHA-CLI.nvram"
virtualHW.productCompatibility = "hosted"
powerType.powerOff = "soft"
powerType.powerOn = "hard"
powerType.suspend = "hard"
powerType.reset = "soft"
displayName = "ClusterHA-CLI"
extendedConfigFile = "ClusterHA-CLI.vmxf"
numvcpus = "2"
scsi0.present = "true"
scsi0.sharedBus = "none"
scsi0.virtualDev = "lsilogic"
memsize = "2048"
scsi0:0.present = "true"
scsi0:0.fileName = "ClusterHA-CLI.vmdk"
scsi0:0.deviceType = "scsi-hardDisk"
scsi0:0.ctkEnabled = "true"
sched.scsi0:0.shares = "normal"
sched.scsi0:0.throughputCap = "off"
ide1:0.present = "true"
ide1:0.clientDevice = "true"
ide1:0.deviceType = "atapi-cdrom"
ide1:0.startConnected = "false"
ethernet0.present = "true"
ethernet0.virtualDev = "vmxnet3"
ethernet0.networkName = "DMZ"
ethernet0.addressType = "vpx"
ethernet0.generatedAddress = "00:50:56:9e:7d:4d"
guestOS = "centos"
annotation = "Servidor Teste HA Luciano"
95
uuid.bios = "42 1e d4 4d aa 42 11 9b-2f ca 69 d3 45 d2 a5 cd"
vc.uuid = "50 1e b9 6f 76 e8 3d 74-53 67 0c 9e 38 c8 4f 1d"
ctkEnabled = "true"
snapshot.action = "keep"
sched.cpu.min = "0"
sched.cpu.units = "mhz"
sched.cpu.shares = "normal"
sched.mem.minsize = "0"
sched.mem.shares = "normal"
tools.upgrade.policy = "manual"
replay.supported = "FALSE"
unity.wasCapable = "FALSE"
replay.filename = ""
scsi0:0.redo = ""
pciBridge0.pciSlotNumber = "17"
pciBridge4.pciSlotNumber = "21"
pciBridge5.pciSlotNumber = "22"
pciBridge6.pciSlotNumber = "23"
pciBridge7.pciSlotNumber = "24"
scsi0.pciSlotNumber = "16"
ethernet0.pciSlotNumber = "160"
vmci0.pciSlotNumber = "32"
vmotion.checkpointFBSize = "4194304"
hostCPUID.0 = "0000000b756e65476c65746e49656e69"
hostCPUID.1 = "000106a500100800009ce3bdbfebfbff"
hostCPUID.80000001 = "00000000000000000000000128100800"
guestCPUID.0 = "0000000b756e65476c65746e49656e69"
guestCPUID.1 = "000106a500010800809822010febfbff"
guestCPUID.80000001 = "00000000000000000000000128100800"
userCPUID.0 = "0000000b756e65476c65746e49656e69"
userCPUID.1 = "000106a500100800009822010febfbff"
userCPUID.80000001 = "00000000000000000000000128100800"
evcCompatibilityMode = "FALSE"
debugStub.linuxOffsets =
"0x0,0xffffffff,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0"
guest.commands.sharedSecretLogin.hostd-quiescedsnap =
"5l8oDDf47/IYdW5YX+OohqNoMlE2eLCbIaJZEvEUNkY="
vmci0.id = "1171432909"
tools.syncTime = "FALSE"
uuid.location = ""
cleanShutdown = "TRUE"
sched.swap.derivedName = "/vmfs/volumes/5278e2f1-450727ea-bed6-
e61f133b121b/ClusterHA-CLI/ClusterHA-CLI-bf550704.vswp"
floppy0.present = "FALSE"
96
A.2.2 – Configuração do servidor 1 (ClusterHA1.vmx):
.encoding = "UTF-8"
config.version = "8"
virtualHW.version = "7"
pciBridge0.present = "true"
pciBridge4.present = "true"
pciBridge4.virtualDev = "pcieRootPort"
pciBridge4.functions = "8"
pciBridge5.present = "true"
pciBridge5.virtualDev = "pcieRootPort"
pciBridge5.functions = "8"
pciBridge6.present = "true"
pciBridge6.virtualDev = "pcieRootPort"
pciBridge6.functions = "8"
pciBridge7.present = "true"
pciBridge7.virtualDev = "pcieRootPort"
pciBridge7.functions = "8"
vmci0.present = "true"
nvram = "ClusterHA1.nvram"
virtualHW.productCompatibility = "hosted"
powerType.powerOff = "soft"
powerType.powerOn = "hard"
powerType.suspend = "hard"
powerType.reset = "soft"
displayName = "ClusterHA1"
extendedConfigFile = "ClusterHA1.vmxf"
floppy0.present = "true"
numvcpus = "4"
scsi0.present = "true"
scsi0.sharedBus = "none"
scsi0.virtualDev = "lsilogic"
memsize = "4096"
scsi0:0.present = "true"
scsi0:0.fileName = "ClusterHA1.vmdk"
scsi0:0.deviceType = "scsi-hardDisk"
scsi0:0.ctkEnabled = "true"
sched.scsi0:0.shares = "normal"
sched.scsi0:0.throughputCap = "off"
ide1:0.present = "true"
ide1:0.deviceType = "atapi-cdrom"
ide1:0.startConnected = "false"
floppy0.startConnected = "false"
floppy0.fileName = ""
floppy0.clientDevice = "true"
ethernet0.present = "true"
ethernet0.virtualDev = "vmxnet3"
ethernet0.networkName = "DMZ"
ethernet0.addressType = "vpx"
ethernet0.generatedAddress = "00:50:56:9e:00:65"
ethernet1.present = "true"
ethernet1.virtualDev = "vmxnet3"
ethernet1.networkName = "CCinstall"
ethernet1.addressType = "vpx"
97
ethernet1.generatedAddress = "00:50:56:9e:00:66"
guestOS = "centos"
annotation = "servidor de teste do Luciano"
uuid.bios = "42 1e dd 9a 7d fc e2 96-a9 a3 f0 f6 d3 6e e3 f0"
vc.uuid = "50 1e 08 94 bb a7 59 01-d6 bf 49 53 a2 77 fd 85"
ctkEnabled = "true"
snapshot.action = "keep"
sched.cpu.min = "0"
sched.cpu.units = "mhz"
sched.cpu.shares = "normal"
sched.mem.minsize = "0"
sched.mem.shares = "normal"
tools.upgrade.policy = "manual"
ethernet0.pciSlotNumber = "160"
ethernet1.pciSlotNumber = "192"
evcCompatibilityMode = "FALSE"
guestCPUID.0 = "0000000b756e65476c65746e49656e69"
guestCPUID.1 = "000106a500010800809822010febfbff"
guestCPUID.80000001 = "00000000000000000000000128100800"
hostCPUID.0 = "0000000b756e65476c65746e49656e69"
hostCPUID.1 = "000106a500100800009ce3bdbfebfbff"
hostCPUID.80000001 = "00000000000000000000000128100800"
pciBridge0.pciSlotNumber = "17"
pciBridge4.pciSlotNumber = "21"
pciBridge5.pciSlotNumber = "22"
pciBridge6.pciSlotNumber = "23"
pciBridge7.pciSlotNumber = "24"
replay.supported = "FALSE"
scsi0.pciSlotNumber = "16"
scsi0:0.redo = ""
userCPUID.0 = "0000000b756e65476c65746e49656e69"
userCPUID.1 = "000106a500100800009822010febfbff"
userCPUID.80000001 = "00000000000000000000000128100800"
vmci0.pciSlotNumber = "32"
vmotion.checkpointFBSize = "4194304"
unity.wasCapable = "FALSE"
replay.filename = ""
vmci0.id = "-747707408"
tools.syncTime = "FALSE"
uuid.location = "56 4d 50 9d 65 0f e1 93-50 03 33 9e 22 69 15
8d"
cleanShutdown = "TRUE"
migrate.hostlog = "./ClusterHA1-1ee90a8b.hlog"
sched.swap.derivedName = "/vmfs/volumes/50910810-20a6d84e-7173-
02215e9d6ba3/ClusterHA1/ClusterHA1-1ee90a8b.vswp"
ide1:0.clientDevice = "TRUE"
98
A.2.3 – Configuração do servidor 2 (ClusterHA2.vmx):
.encoding = "UTF-8"
config.version = "8"
virtualHW.version = "7"
pciBridge0.present = "true"
pciBridge4.present = "true"
pciBridge4.virtualDev = "pcieRootPort"
pciBridge4.functions = "8"
pciBridge5.present = "true"
pciBridge5.virtualDev = "pcieRootPort"
pciBridge5.functions = "8"
pciBridge6.present = "true"
pciBridge6.virtualDev = "pcieRootPort"
pciBridge6.functions = "8"
pciBridge7.present = "true"
pciBridge7.virtualDev = "pcieRootPort"
pciBridge7.functions = "8"
vmci0.present = "true"
nvram = "ClusterHA2.nvram"
virtualHW.productCompatibility = "hosted"
powerType.powerOff = "soft"
powerType.powerOn = "hard"
powerType.suspend = "hard"
powerType.reset = "soft"
displayName = "ClusterHA2"
extendedConfigFile = "ClusterHA2.vmxf"
floppy0.present = "true"
numvcpus = "4"
scsi0.present = "true"
scsi0.sharedBus = "none"
scsi0.virtualDev = "lsilogic"
memsize = "4096"
scsi0:0.present = "true"
scsi0:0.fileName = "ClusterHA2.vmdk"
scsi0:0.deviceType = "scsi-hardDisk"
scsi0:0.ctkEnabled = "true"
sched.scsi0:0.shares = "normal"
sched.scsi0:0.throughputCap = "off"
ide1:0.present = "true"
ide1:0.deviceType = "atapi-cdrom"
ide1:0.startConnected = "false"
floppy0.startConnected = "false"
floppy0.fileName = ""
floppy0.clientDevice = "true"
ethernet0.present = "true"
ethernet0.virtualDev = "vmxnet3"
ethernet0.networkName = "DMZ"
ethernet0.addressType = "vpx"
ethernet0.generatedAddress = "00:50:56:9e:00:6e"
ethernet1.present = "true"
ethernet1.virtualDev = "vmxnet3"
ethernet1.networkName = "CCinstall"
ethernet1.addressType = "vpx"
99
ethernet1.generatedAddress = "00:50:56:9e:00:6f"
guestOS = "centos"
annotation = "servidor de teste do Luciano"
uuid.bios = "42 1e 2b c0 bf 11 78 e4-0b b8 79 e8 c3 7b 6b 1d"
vc.uuid = "50 1e 04 7c 2c b7 3d 96-dd 62 38 11 c3 7f f3 99"
ctkEnabled = "true"
snapshot.action = "keep"
sched.cpu.min = "0"
sched.cpu.units = "mhz"
sched.cpu.shares = "normal"
sched.mem.minsize = "0"
sched.mem.shares = "normal"
tools.upgrade.policy = "manual"
ethernet0.pciSlotNumber = "160"
ethernet1.pciSlotNumber = "192"
evcCompatibilityMode = "FALSE"
guestCPUID.0 = "0000000b756e65476c65746e49656e69"
guestCPUID.1 = "000106a500010800809822010febfbff"
guestCPUID.80000001 = "00000000000000000000000128100800"
hostCPUID.0 = "0000000b756e65476c65746e49656e69"
hostCPUID.1 = "000106a500100800009ce3bdbfebfbff"
hostCPUID.80000001 = "00000000000000000000000128100800"
pciBridge0.pciSlotNumber = "17"
pciBridge4.pciSlotNumber = "21"
pciBridge5.pciSlotNumber = "22"
pciBridge6.pciSlotNumber = "23"
pciBridge7.pciSlotNumber = "24"
replay.supported = "FALSE"
scsi0.pciSlotNumber = "16"
scsi0:0.redo = ""
userCPUID.0 = "0000000b756e65476c65746e49656e69"
userCPUID.1 = "000106a500100800009822010febfbff"
userCPUID.80000001 = "00000000000000000000000128100800"
vmci0.pciSlotNumber = "32"
vmotion.checkpointFBSize = "4194304"
unity.wasCapable = "false"
replay.filename = ""
guest.commands.sharedSecretLogin.hostd-quiescedsnap =
"Q0y8job/+waddzbG9yjy8Xzng6M4eK1rV2oD7d49rKY="
vmci0.id = "-1015321827"
tools.syncTime = "FALSE"
uuid.location = "56 4d 86 70 5b f1 a2 75-84 6e fb df 66 03 95
32"
cleanShutdown = "TRUE"
migrate.hostlog = "./ClusterHA2-1ee90a8c.hlog"
sched.swap.derivedName = "/vmfs/volumes/50910810-20a6d84e-7173-
02215e9d6ba3/ClusterHA2/ClusterHA2-1ee90a8c.vswp"
ide1:0.clientDevice = "TRUE"
100
A.3 – Configuração da camada da aplicação.
A.3.1 – Configuração do DRBD (/etc/drbd.conf)
################################
# FS MYSQL
################################
resource drbd0 {
protocol C;
startup {
#
# wfc-timeout 0;
degr-wfc-timeout 120; # 2 minutes.
}
disk {
on-io-error detach;
}
net {
timeout 60; # 6 seconds (unit = 0.1 seconds)
connect-int 10; # 10 seconds (unit = 1 second)
ping-int 10; # 10 seconds (unit = 1 second)
ping-timeout 5; # 500 ms (unit = 0.1 seconds)
max-buffers 2048;
max-epoch-size 2048;
}
syncer {
rate 10M;
}
on altadisp1.ccuec.unicamp.br {
device /dev/drbd0;
disk /dev/sda3;
address 192.168.1.1:7789;
meta-disk internal;
}
on altadisp2.ccuec.unicamp.br {
device /dev/drbd0;
disk /dev/sda3;
address 192.168.1.2:7789;
meta-disk internal;
}
}
# ###############################
# FS WWW
# ##############################
101
resource drbd1 {
protocol C;
startup {
#
# wfc-timeout 0;
degr-wfc-timeout 120; # 2 minutes.
}
disk {
on-io-error detach;
}
net {
timeout 60; # 6 seconds (unit = 0.1 seconds)
connect-int 10; # 10 seconds (unit = 1 second)
ping-int 10; # 10 seconds (unit = 1 second)
ping-timeout 5; # 500 ms (unit = 0.1 seconds)
max-buffers 2048;
max-epoch-size 2048;
}
syncer {
rate 10M;
}
on altadisp1.ccuec.unicamp.br {
device /dev/drbd1;
disk /dev/sda5;
address 192.168.1.1:7790;
meta-disk internal;
}
on altadisp2.ccuec.unicamp.br {
device /dev/drbd1;
disk /dev/sda5;
address 192.168.1.2:7790;
meta-disk internal;
}
}
# ###############################################
# FS HOME
# ##############################################
resource drbd2 {
protocol C;
startup {
#
# wfc-timeout 0;
degr-wfc-timeout 120; # 2 minutes.
}
102
disk {
on-io-error detach;
}
net {
timeout 60; # 6 seconds (unit = 0.1 seconds)
connect-int 10; # 10 seconds (unit = 1 second)
ping-int 10; # 10 seconds (unit = 1 second)
ping-timeout 5; # 500 ms (unit = 0.1 seconds)
max-buffers 2048;
max-epoch-size 2048;
}
syncer {
rate 10M;
}
on altadisp1.ccuec.unicamp.br {
device /dev/drbd2;
disk /dev/sda6;
address 192.168.1.1:7791;
meta-disk internal;
}
on altadisp2.ccuec.unicamp.br {
device /dev/drbd2;
disk /dev/sda6;
address 192.168.1.2:7791;
meta-disk internal;
}
}
# ###############################
# FS PHPSES
# ################################
resource drbd3 {
protocol C;
startup {
#
# wfc-timeout 0;
degr-wfc-timeout 120; # 2 minutes.
}
disk {
on-io-error detach;
}
net {
timeout 60; # 6 seconds (unit = 0.1 seconds)
connect-int 10; # 10 seconds (unit = 1 second)
ping-int 10; # 10 seconds (unit = 1 second)
ping-timeout 5; # 500 ms (unit = 0.1 seconds)
max-buffers 2048;
max-epoch-size 2048;
103
}
syncer {
rate 10M;
}
on altadisp1.ccuec.unicamp.br {
device /dev/drbd3;
disk /dev/sda11;
address 192.168.1.1:7792;
meta-disk internal;
}
on altadisp2.ccuec.unicamp.br {
device /dev/drbd3;
disk /dev/sda11;
address 192.168.1.2:7792;
meta-disk internal;
}
}
104
A.3.2 – Configuração do heartbeat (/etc/ha.d/haresources)
altadisp1.ccuec.unicamp.br IPaddr::143.106.120.246/26/eth0
drbddisk Filesystem::
/dev/drbd0::/mysql::ext3 Filesystem::/dev/drbd1::/www::ext3
Filesystem::/dev/drb
d2::/home::ext3 Filesystem::/dev/drbd3::/phpses::ext3 mysql
httpd mon
A.3.3. – Configuração do Monitor (/etc/mon/mon.cf)
### Extremely basic mon.cf file
### global options
cfbasedir = /etc/mon
pidfile = /var/run/mon.pid
statedir = /var/lib/mon/state.d
logdir = /var/lib/mon/log.d
dtlogfile = /var/lib/mon/log.d/downtime.log
alertdir = /usr/lib/mon/alert.d
mondir = /usr/lib/mon/mon.d
maxprocs = 20
histlength = 100
randstart = 60s
authtype = pam
userfile = /etc/mon/userfile
### group definitions (hostnames or IP addresses)
hostgroup servers localhost
watch servers
service ping
interval 5m
monitor ping.monitor
105
period wd {Mon-Fri} hr {7am-10pm}
alert mail.alert root@localhost
alertevery 1h
period wd {Sat-Sun}
alert mail.alert root@localhost
service http
interval 5s
monitor http.monitor
allow_empty_group
period wd {Sun-Sat}
alert heartbeat.alert
alert mail.alert -S "[ALTADISP1] - Problema HTTP –
Mudança do serviço de servidor" luciano@ccuec.unicamp.br
upalert mail.alert -S "[ALTADISP1] - HTTP no Ar"
luciano@ccuec.unicamp.br
alertevery 1m
106
A.3.4. – Configuração do Sistema Operacional convidado.
altadisp1.ccuec.unicamp.br
description: Computer
product: VMware Virtual Platform
vendor: VMware, Inc.
version: None
serial: VMware-42 1e dd 9a 7d fc e2 96-a9 a3 f0 f6 d3 6e e3
f0
width: 32 bits
capabilities: smbios-2.4 dmi-2.4 smp-1.4 smp
*-core
description: Motherboard
product: 440BX Desktop Reference Platform
vendor: Intel Corporation
physical id: 0
*-firmware
description: BIOS
vendor: Phoenix Technologies LTD
physical id: 0
version: 6.00 (01/15/2013)
size: 87KiB
*-cpu:0
description: CPU
product: Intel(R) Xeon(R) CPU X5560 @ 2.80GHz
vendor: Intel Corp.
physical id: 4
bus info: cpu@0
version: 6.10.5
serial: 0001-06A5-0000-0000-0000-0000
slot: CPU socket #0
size: 2800MHz
107
capacity: 4230MHz
width: 64 bits
*-cpu:1
description: CPU
product: Intel(R) Xeon(R) CPU X5560 @ 2.80GHz
vendor: Intel Corp.
physical id: 5
bus info: cpu@1
version: 6.10.5
serial: 0001-06A5-0000-0000-0000-0000
slot: CPU socket #1
size: 2800MHz
capacity: 4230MHz
width: 64 bits
*-cpu:2
description: CPU
product: Intel(R) Xeon(R) CPU X5560 @ 2.80GHz
vendor: Intel Corp.
physical id: 6
bus info: cpu@2
version: 6.10.5
serial: 0001-06A5-0000-0000-0000-0000
slot: CPU socket #2
size: 2800MHz
capacity: 4230MHz
width: 64 bits
*-cpu:3
description: CPU
product: Intel(R) Xeon(R) CPU X5560 @ 2.80GHz
vendor: Intel Corp.
physical id: 7
108
bus info: cpu@3
version: 6.10.5
serial: 0001-06A5-0000-0000-0000-0000
slot: CPU socket #3
size: 2800MHz
capacity: 4230MHz
width: 64 bits
*-memory
description: System Memory
physical id: 3a
slot: System board or motherboard
size: 4GiB
*-system
description: System peripheral
product: Virtual Machine Communication Interface
vendor: VMware
physical id: 7.7
bus info: pci@0000:00:07.7
version: 10
width: 32 bits
clock: 33MHz
capabilities: bus_master
configuration: driver=vmci latency=64
maxlatency=255 mingnt=6 module=vmci
*-display UNCLAIMED
description: VGA compatible controller
product: SVGA II Adapter
vendor: VMware
physical id: f
bus info: pci@0000:00:0f.0
version: 00
109
width: 32 bits
clock: 33MHz
capabilities: vga_controller bus_master cap_list
configuration: latency=64
*-scsi
description: SCSI storage controller
product: 53c1030 PCI-X Fusion-MPT Dual Ultra320 SCSI
vendor: LSI Logic / Symbios Logic
physical id: 10
bus info: pci@0000:00:10.0
logical name: scsi0
version: 01
width: 64 bits
clock: 33MHz
capabilities: scsi bus_master scsi-host
configuration: driver=mptspi latency=64
maxlatency=255 mingnt=6 module=mptspi
*-disk
description: SCSI Disk
product: Virtual disk
vendor: VMware
physical id: 0.0.0
bus info: scsi@0:0.0.0
logical name: /dev/sda
version: 1.0
size: 50GiB (53GB)
capabilities: partitioned partitioned:dos
configuration: ansiversion=2 signature=00040b22
capacity: 1411MiB
*-network
description: Ethernet interface
110
product: VMXNET3 Ethernet Controller
vendor: VMware
physical id: 0
bus info: pci@0000:03:00.0
logical name: eth0
version: 01
serial: 00:50:56:9e:00:65
capacity: 1GB/s
width: 32 bits
clock: 33MHz
capabilities: pm pciexpress msi msix bus_master
cap_list ethernet physical logical tp 1000bt-fd
configuration: autonegotiation=off broadcast=yes
driver=vmxnet3 driverversion=1.0.11.3-NAPI duplex=full
firmware=N/A ip=143.106.120.244 latency=0 link=yes
module=vmxnet3 multicast=yes port
111
A.3.5. – Serviços de alta disponibilidade em execução no Sistema Operacional convidado.
Serviço: Sincronização automática e “online” dos arquivos do
servidor em funcionamento para um servidor em espera (DRBD).
altadisp1.ccuec.unicamp.br
[root@altadisp1 ~]# cat /proc/drbd
version: 8.2.6 (api:88/proto:86-88)
GIT-hash: 3e69822d3bb4920a8c1bfdf7d647169eba7d2eb4 build by
buildsvn@c5-i386-build, 2008-10-03 11:42:32
0: cs:Connected st:Primary/Secondary ds:UpToDate/UpToDate C r---
ns:428 nr:308 dw:736 dr:6538 al:9 bm:6 lo:0 pe:0 ua:0 ap:0 oos:0
1: cs:Connected st:Primary/Secondary ds:UpToDate/UpToDate C r---
ns:1440272 nr:663944 dw:2104216 dr:11862 al:39 bm:5 lo:0 pe:0 ua:0
ap:0 oos:0
2: cs:Connected st:Primary/Secondary ds:UpToDate/UpToDate C r---
ns:404 nr:452 dw:856 dr:1130 al:3 bm:2 lo:0 pe:0 ua:0 ap:0 oos:0
3: cs:Connected st:Primary/Secondary ds:UpToDate/UpToDate C r---
ns:164 nr:148 dw:312 dr:1962 al:4 bm:4 lo:0 pe:0 ua:0 ap:0 oos:0
[root@altadisp1 ~]#
altadisp2.ccuec.unicamp.br
[root@altadisp2 ~]# cat /proc/drbd
version: 8.2.6 (api:88/proto:86-88)
GIT-hash: 3e69822d3bb4920a8c1bfdf7d647169eba7d2eb4 build by
buildsvn@c5-i386-build, 2008-10-03 11:42:32
0: cs:Connected st:Secondary/Primary ds:UpToDate/UpToDate C r---
ns:308 nr:428 dw:736 dr:3697 al:9 bm:8 lo:0 pe:0 ua:0 ap:0 oos:0
1: cs:Connected st:Secondary/Primary ds:UpToDate/UpToDate C r---
ns:663944 nr:1440332 dw:2104276 dr:6281 al:38 bm:13 lo:0 pe:0 ua:0
ap:0 oos:0
2: cs:Connected st:Secondary/Primary ds:UpToDate/UpToDate C r---
ns:452 nr:404 dw:856 dr:1101 al:3 bm:2 lo:0 pe:0 ua:0 ap:0 oos:0
3: cs:Connected st:Secondary/Primary ds:UpToDate/UpToDate C r---
ns:148 nr:164 dw:312 dr:1933 al:4 bm:4 lo:0 pe:0 ua:0 ap:0 oos:0
[root@altadisp2 ~]#
Serviço: Monitoramento dos serviços de alta disponibilidade e
reinicialização dos serviços em caso de falha do sistema
operacional convidado (Heartbeat).
altadisp1.ccuec.unicamp.br
[root@altadisp1 ~]# ps -ef |grep -i heartbeat
root 6259 1 0 Nov18 ? 00:00:01 heartbeat: master control process
nobody 6262 6259 0 Nov18 ? 00:00:00 heartbeat: FIFO reader
nobody 6263 6259 0 Nov18 ? 00:00:00 heartbeat: write: mcast eth1
nobody 6264 6259 0 Nov18 ? 00:00:13 heartbeat: read: mcast eth1
nobody 6265 6259 0 Nov18 ? 00:00:00 heartbeat: write: ping
143.106.120.193
nobody 6266 6259 0 Nov18 ? 00:00:00 heartbeat: read: ping
143.106.120.193
112
root 10627 10295 0 15:40 pts/1 00:00:00 grep -i heartbeat
[root@altadisp1 ~]#
altadisp2.ccuec.unicamp.br
[root@altadisp2 init.d]# ps -ef |grep -i heartbeat
root 3630 1 0 Nov14 ? 00:00:02 heartbeat: master control process
nobody 3645 3630 0 Nov14 ? 00:00:00 heartbeat: FIFO reader
nobody 3646 3630 0 Nov14 ? 00:00:00 heartbeat: write: mcast eth1
nobody 3647 3630 0 Nov14 ? 00:00:13 heartbeat: read: mcast eth1
nobody 3648 3630 0 Nov14 ? 00:00:00 heartbeat: write: ping
143.106.120.193
nobody 3649 3630 0 Nov14 ? 00:00:01 heartbeat: read: ping
143.106.120.193
root 4075 4001 0 15:38 pts/2 00:00:00 grep -i heartbeat
Serviço: Monitoramento dos serviços que são utilizados pelos
usuários finais e em caso de falha a reinicialização dos
serviços no servidor em espera (mon).
[root@altadisp1 ou altadisp2]# ps -ef |grep -i mon
root 7361 1 0 Nov18 ? 00:02:54 /usr/bin/perl /usr/bin/mon -f -c
/etc/mon/mon.cf
[root@altadisp1 ou altadisp2]
** O serviço mon estará em execução somente no servidor que está no
papel de principal.
top related