campus sombrio luã alfredo gonçalves ronaldo borges de

Transcrição

INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA
CATARINENSE – CAMPUS SOMBRIO
LUÃ ALFREDO GONÇALVES
RONALDO BORGES DE QUADROS
IMPLEMENTAÇÃO DE UM AMBIENTE DE ALTA DISPONIBILIDADE COM
HEARTBEAT
Sombrio (SC)
2013
HEARTBEAT
Trabalho de Conclusão de Curso apresentado como
requisito parcial para a obtenção do título de
Tecnólogo, no Curso Superior de Tecnologia em
Redes de Computadores, do Instituto Federal de
Educação, Ciência e Tecnologia Catarinense Campus Sombrio.
Orientador: Prof. Me. Marco Antonio Silveira de
Souza.
Coorientador: Prof. Jéferson Mendonça de Limas.
Sombrio (SC)
2013
HEARTBEAT
Esta
Produção
Técnica-Científica
foi
julgada
adequada para obtenção do título de Tecnólogo e
aprovada pelo Curso Superior de Tecnologia em
Redes de Computadores, do Instituto Federal de
Educação, Ciência e Tecnologia Catarinense Campus Sombrio.
Área de concentração: Redes de computadores.
Sombrio, 23 de fevereiro de 2013.
Prof. Marco Antônio Silveira de Souza.
Instituto Federal Catarinense – Campus Sombrio
Orientador(a)
Prof. Vanderlei Freitas Junior
Membro
Prof. Alexssandro Cardoso Antunes
Membro
RESUMO
Este trabalho tem como objetivo implementar um cluster de alta disponibilidade com
ferramentas open source. Para a realização do trabalho foi feito uma simulação em
ambiente virtual utilizando-se o software de virtualização, Virtualbox. Criou-se três
máquinas virtuais onde duas são os servidores e uma o cliente. Nos dois servidores
instalou-se o servidor web Apache, e o Heartbeat para monitorar os servidores. Com
os dois servidores funcionando, um ativo (master) e o outro em modo de espera
(slave), e o cliente acessando a página de testes criada para esse fim, fez-se alguns
testes com as máquinas, por exemplo, um dos testes foi a desconexão do cabo de
rede virtual, simulando uma desconexão real, o que pode acontecer por acidente.
Outro teste foi o fechamento da janela do Virtualbox onde estava funcionando o
servidor ativo, simulando uma queima de fonte ou de placa de rede. Em todos os
testes foi possível constatar que o servidor em modo de espera passava a operar
quase que instantaneamente, o que se comprova com o comando ping, ao desligar
o servidor ativo, o cliente perde dez segundos de conexão e volta a funcionar
novamente. Como comprovou-se com os testes feitos, o Heartbeat atende as
necessidades de quem precisa de alta disponibilidade de serviços de rede.
Palavras-chave: Cluster. Alta disponibilidade. Heartbeat. Apache.
ABSTRACT
This paper aims to implement a high availability cluster with open source tools. To
conduct the study was done in a simulated virtual environment using virtualization
software, VirtualBox. It created three virtual machines are those where two servers
and a client. In both servers was installed the Apache web server, and Heartbeat to
monitor the servers. With the two servers running, one active (master) and the other
in standby (slave), and the client accessing the test page created for this purpose,
made up some tests with the machines, for example, one of the tests was disconnect
the network cable virtual simulating a real disconnect, which can happen by accident.
Another test was closing the window where Virtualbox was running the live server,
simulating a burning source or network card. In all tests, we determined that the
standby server operating spent almost instantly, as evidenced with the ping
command to shut down the active server, the client loses connection ten seconds
and back to work again. As demonstrated with the tests, Heartbeat meets the needs
of those who need high availability of network services.
Key words: Cluster. High availability. Heartbeat. Apache.
LISTA DE FIGURAS
Figura 1: Cartão perfurado..........................................................................................11
Figura 2: Rede ponto a ponto......................................................................................13
Figura 3: Rede Cliente/Servidor..................................................................................14
Figura 4: Barramento...................................................................................................15
Figura 5: Anel..............................................................................................................15
Figura 6: Estrela..........................................................................................................16
Figura 7: Market share................................................................................................21
Figura 8: Cenário.........................................................................................................24
Figura 9: Virtual Host...................................................................................................27
Figura 10: Hosts..........................................................................................................28
Figura 11: Ha.cf...........................................................................................................29
Figura 12: Authkeys.....................................................................................................30
Figura 13: Haresources...............................................................................................31
Figura 14: Ifconfig........................................................................................................32
Figura 15: Sysv-rc-conf...............................................................................................33
Figura 16: Espelha.sh..................................................................................................34
Figura 17: Crontab.......................................................................................................35
Figura 18: Rc.local.......................................................................................................36
Figura 19: Comando ping............................................................................................37
Figura 20: Heartbeat no servidor sv2..........................................................................38
Figura 21: Estatísticas do comando ping para queima de placa de rede..................38
Figura 22: Estatísticas do comando ping 192.168.1.1 para queima de Fonte...........39
LISTA DE ABREVIATURAS E SIGLAS
AMD - Advanced Micro Devices
ARPANet - The Advanced Research Projects Agency Network
CD - Compact Disc
CRC - Cyclic Redundancy Check
DFSG - Debian Free Software Guidelines
DNS - Domain Name Service
DRDB - Duplicated Redundant Block Device
DVD - Digital Versatile Disc
GB - Gigabytes
HA - High Availability
HASP - Houston Automatic Spooling Priority
HD - Hard Disk
HP - Hewlett-Packard
HPC - High Performance Computing
HTML - HyperText Markup Language
HTTPD - Hypertext Transfer Protocol Daemon
IBM - International Business Machines
ITU - International Telecommunications Union
JES - Job Entry System
LAN - Local Area Network
MAC - Media Access Control
MAN - Metropolitan Area Network
MB - Megabytes
MD5 - Message Digest 5
NAT - Network Address Translation
NCSA - National Center for Supercomputing Applications
OSI - Open Source Initiative
RAM - Random Access Memory
SHA1 - Secure Hash Algorithm 1
SSH - Secure Shell
TCP/IP - Transmission Control Protocol/Internet Protocol
WAN - Wide Area Network
SUMÁRIO
1 INTRODUÇÃO...........................................................................................................8
2 OBJETIVOS.............................................................................................................10
2.1 Objetivos gerais...................................................................................................10
2.2 Objetivos específicos.........................................................................................10
3 REFERENCIAL TEÓRICO.......................................................................................11
3.1 O uso das redes de computadores...................................................................12
3.2 Topologias das redes..........................................................................................14
3.3 Tipos de redes.....................................................................................................17
3.4 Sistemas operacionais.......................................................................................17
3.5 Virtualização........................................................................................................19
3.5 Open source.........................................................................................................19
3.6 Serviços de rede..................................................................................................20
3.7 Cluster..................................................................................................................22
4 MATERIAIS E MÉTODOS.......................................................................................24
5 RESULTADOS E DISCUSSÃO...............................................................................37
6 CONSIDERAÇÕES FINAIS.....................................................................................40
REFERÊNCIAS...........................................................................................................42
8
1 INTRODUÇÃO
Partindo do surgimento das redes de computadores nos anos 60, segundo
Morimoto (2010) até se tornar a realidade diária de milhões de pessoas em 1996
Tanenbaum (2003) e chegar em 2011 passando dos 2 bilhões de pessoas
conectadas a internet, estatística informada no artigo Internet (2013), atualmente fica
difícil imaginar um ambiente onde o computador não esteja inserido, seja no
trabalho, na escola, em casa. Os usuários esperam que seus sistemas estejam
sempre funcionando.
Um portal na internet, sites de jogos on line, sites de notícias, sites de
comércio eletrônico entre outros precisam estar sempre funcionando ou correm o
risco de perder seus usuários para outros sites. Como garantir que os serviços
oferecidos em rede estejam sempre disponíveis? De acordo com Pitanga (2008), um
cluster de alta disponibilidade visa exatamente garantir que os serviços oferecidos
em rede não parem, ou que se ficar indisponível, seja pelo menor tempo possível.
Desde que os computadores começaram a ser ligados em rede se pensou na
criação de clusters para melhorar o aproveitamento dos recursos que as vezes eram
mal utilizados. A ARPAnet (The Advanced Research Projects Agency Network )
utilizou os programas Creeper e Reaper-ran para testes com computação distribuída.
Pode-se dizer que eles vislumbravam que as aplicações se moveriam de um
computador para outro (DANTAS, 2005).
Existe no mercado algumas soluções que tentam garantir a disponibilidade
dos serviços oferecidos em rede, como o HACMP (High Availabylity Cluster MultiProcessing), que é proprietária da IBM, ou então a Serviceguard da HP (HewlettPackard), ou ainda a da SUN, SPARCcluster (Scalable Processor Architetcure
Cluster) (FERREIRA; SANTOS, 2005). Estes são apenas alguns exemplos. No caso
que será exposto neste artigo, toda a solução será baseada em software livre.
Este
trabalho
tem
como
objetivo
implementar
um
cluster
de
alta
disponibilidade utilizando-se ferramentas open source, onde servidores oferecerão
serviços de rede aos usuários. O sistema será composto por dois computadores
interligados por rede ethernet, sendo que um equipamento estará ativo oferecendo
serviço de web e o outro equipamento será um espelho do primeiro, de forma que se
9
o servidor principal ficar inativo o outro assumirá as suas funções oferecendo o
serviço até que o outro servidor seja reestabelecido.
O presente trabalho esta organizado da seguinte forma: no capítulo 2 são
apresentados os objetivos, sendo o objetivo específico a implementação do cluster e
os objetivos gerais que são o estudo da ferramenta Heartbeat, a instalação e
configuração dos servidores, a instalação e configuração do serviço de rede que
será oferecido e a instalação e configuração das ferramentas de monitoramento do
cluster. No capítulo 3 é apresentado o referencial teórico sobre as redes de
computadores, clusters e os softwares utilizados, e ainda informações que
corroboram com a importância do que é discutido neste trabalho. Nó capítulo 4 é
apresentado de que forma foi realizado o trabalho, neste capítulo é descrito as
configurações que foram feitas em cada uma das máquinas, seus arquivos de
configuração e de que forma foram feitos os testes. O capítulo 5 trás os resultados e
discussões, e finalmente o capítulo 6 com as considerações finais além de ideias
para trabalhos futuros.
10
2 OBJETIVOS
Abaixo a exposição dos objetivos geral e específicos.
2.1 Objetivos gerais
Implementar um ambiente de alta disponibilidade com Heartbeat.
2.2 Objetivos específicos
•
Realizar uma revisão bibliográfica sobre alta disponibilidade;
•
Estudar a ferramenta Heartbeat;
•
Instalar o sistema operacional Ubuntu Server 12.04;
•
Instalar e configurar Apache;
•
Instalar e configurar o Heartbeat e o Rsync;
•
Validar a disponibilidade do sistema.
11
3 REFERENCIAL TEÓRICO
Para que se tenha uma visão mais ampla do desenvolvimento das redes de
computadores é preciso voltar ao passado. Morimoto (2010) diz que a criação das
primeiras redes de computadores foi durante os anos 60. Antes disso, para
transportar dados de uma máquina para outra, utilizava-se cartões perfurados, o que
era um sistema nada prático. Na figura 1, um exemplo destes cartões:
Figura 1: Cartão perfurado.
Fonte: Wcrivelini, 2012.
A partir de 1969 começou a ser desenvolvida a Arpanet que acabou dando
origem a Internet dos dias atuais. Com apenas quatro máquinas a Arpanet entrou
em funcionamento em dezembro de 69. A rede que tinha sido criada para testes, se
desenvolveu muito rápido e em 1973 já estavam conectadas trinta instituições,
incluindo universidades e instituições militares (MORIMOTO, 2012).
As primeiras máquinas eram identificadas na rede por nomes, sendo que os
nomes das quatro primeiras máquinas eram: SRI, UCLA, UCSB e UTAH. Nesta
época eram criadas listas dos hosts, conforme se conectavam a rede. Com o
crescimento da rede, conforme mais máquinas foram sendo conectadas, foi ficando
mais difícil manter e distribuir estas listas, até que em 1974 surge o TCP/IP
(Transmission Control Protocol/Internet Protocol), conjunto de protocolos usados até
hoje na internet. Mais tarde em 1980, passou a ser usado nomes de domínio, dando
12
origem ao DNS (Domain Name Service), também usado atualmente (MORIMOTO,
2012).
Estes primeiros computadores eram grandes máquinas que ficavam em
algumas universidades dos Estados Unidos e foram colocadas em rede, sendo
usadas linhas telefônicas para fazer as conexões.
Paralelamente ao que acontecia nas universidades, em 1973 a Xerox fez o
primeiro teste de transmissão de dados, utilizando o padrão ethernet, fazendo as
conexões através de cabos coaxiais e que permitia a conexão de até 256
computadores. É importante lembrar que nesta época não existiam ainda
computadores pessoais, interfaces gráficas, etc, o lançamento do primeiro PC só
aconteceu em 1981 (MORIMOTO, 2012).
A Arpanet deu origem a internet como conhecemos hoje, e o ethernet acabou
se tornando um padrão utilizado no mundo todo para a criação de redes locais de
computadores. Atualmente temos até geladeiras e micro-ondas que se conectam a
internet (MORIMOTO, 2012).
3.1 O uso das redes de computadores
Conforme Tanenbaum (2003) as redes de computadores eram uma
curiosidade acadêmica em 1980 e era a realidade diária de milhões de pessoas em
1996. O site da ITU (International Telecommunications Union) trás informações de
que em 2011 passamos dos 2 bilhões de pessoas conectadas a internet (INTERNET,
2013). As redes de computadores estão se tornando imprescindíveis nos mais
diversos setores da sociedade e inclusive nas residências. Como salienta Torres
(2001), quando se tem mais de um computador seja em casa ou no escritório, faz
todo o sentido ter uma rede. Uma rede local permite o compartilhamento de
periféricos, como impressora, scanner, driver de CD ou DVD, permite o
compartilhamento de arquivos e também a conexão com a internet. É muito mais
prático e rápido transferir documentos através da rede do que gravar em um CD,
DVD ou mesmo pendrive, para depois copiar em outra máquina.
Ainda segundo Torres (2001), as redes de computadores podem ser dividas
em duas, sendo elas ponto a ponto e cliente/servidor. Nas redes ponto a ponto não
13
existe um servidor dedicado oferecendo serviços aos nós, más cada usuário pode
compartilhar ou não, arquivos, impressoras, drivers, etc. Dessa forma cada máquina
as vezes age como servidor e as vezes como cliente. As questões de segurança são
mais precárias neste tipo de rede e por isso ela é indicada apenas para pequenas
redes com 10 ou menos computadores e onde a segurança não é o fator mais
importante. A rede ponto a ponto tem um custo menor, é mais fácil de configurar,
porém o desempenho da rede é menor que nas redes cliente/servidor, e conforme a
rede aumenta, pior é o desempenho. Na figura 2 abaixo a representação de uma
rede ponto a ponto:
Figura 2: Rede ponto a
ponto.
Fonte: Os autores, 2013.
As redes do tipo cliente/servidor diferentemente das redes ponto a ponto tem
uma administração e configuração centralizada, por isso é muito mais segura
(TORRES, 2001). Empresas com 10 ou mais computadores ou onde a segurança é
importante é recomendável a utilização deste tipo de rede. Existem vários serviços
que podem ser oferecidos pelos servidores. Servidores de arquivos, servidor de
impressão, servidor web, etc. Todos os serviços podem estar instalados em uma
máquina ou em máquinas diferentes. Os servidores podem ainda ser dedicados ou
não. Ou seja uma máquina que não é utilizada para uso comum, ou uma máquina
que além de oferecer os serviços, ainda é utilizada para outros trabalhos, o que é
comum em pequenas empresas. Porém um servidor dedicado é mais seguro e traz
14
menos problemas para a rede como um todo. Redes do tipo cliente/servidor
precisam de administradores de rede que configuram o que cada usuário pode ou
não acessar no servidor. Além disso um servidor não precisa necessariamente ser
um computador. Um servidor pode ser uma máquina construída especificamente
para este fim. Na figura 3 um exemplo de rede cliente/servidor (TORRES, 2001).
Figura 3: Rede Cliente/Servidor.
3.2 Topologias das redes
As redes de computadores também podem ser classificadas de acordo com a
topologia. A topologia diz respeito a distribuição física dos computadores e como
eles estão interligados. Existem várias topologias de rede, entre elas as principais
são: barramento, anel, estrela (MORAES, 2010).
A topologia em barramento foi uma das primeiras topologias de rede e foi uma
das que mais prosperou devido a facilidade de implementação e expansão
(MORAES, 2010). Todas as máquinas são conectadas a um cabo, que é o meio de
transmissão. Nesta topologia as estações precisam escutar o meio antes de
transmitir, já que apenas uma máquina pode transmitir. Se duas transmitirem ao
mesmo tempo pode haver colisão de pacotes. Quanto maior o número de máquinas,
pior o desempenho da rede. A figura 4 ilustra uma topologia em barramento:
15
Figura 4: Barramento.
Na Topologia em anel, os computadores ficam conectados em um caminho
fechado, como se formassem um circulo. Cada máquina só pode usar o meio se
tiver autorização que é chamada de token. Quando uma máquina recebe o token, se
ela tiver algo para transmitir, ela transmite, senão passa o token para a próxima
máquina. As mensagens normalmente circulam em um só sentido, por isso não
existe o problema de colisão de pacotes. Porém se ninguém estiver transmitindo e
uma máquina quiser transmitir, ela terá que espera o token (MORAES, 2010). Na
figura 5 um exemplo de topologia em anel:
Figura 5: Anel.
Ainda, segundo Moraes (2010) as redes em topologia estrela são aquelas em
16
que todos os dispositivos da rede convergem para um ponto central, ou seja, um
concentrador. Esse concentrador é um hardware, que pode ser um hub, switch ou
um roteador. Todas as máquinas são conectadas diretamente no concentrador,
portanto se houver um problema com o concentrador, toda a rede fica inoperante.
Por outro lado se uma das máquinas deixar de funcionar, não compromete a rede
que pode continuar sendo usada normalmente. Um ponto limitante na topologia em
estrela é que o número de máquinas fica restrito ao número de portas do
concentrador. Se houver necessidade de mais portas, o concentrador terá que ser
trocado por um modelo com mais portas ou então outro concentrador poderá ser
conectado a esse de forma a aumentar o número de portas. Atualmente, esta é a
topologia mais usada, pois a sua implementação é fácil assim como sua
configuração, além de ter um custo baixo e alta disponibilidade de produtos no
mercado. Na figura 6 tem-se a representação de uma rede com topologia em
estrela:
Figura 6: Estrela.
Além das topologias citadas acima, que são as mais utilizadas, outras
topologias também são conhecidas, como: topologia híbrida, que mistura
características de duas topologias, por exemplo, anel estrela ou barramento estrela.
E ainda há outros tipos. Topologia em árvore, topologia em malha.
17
3.3 Tipos de redes
As redes também podem ser classificadas de acordo com seu tamanho, ou
seja, área de abrangência. Dos quais as mais comum são: LAN (Local Area
Network), MAN (Metropolitan Area Network) e WAN (Wide Area Network).
A definição dessas redes segundo Tanenbaum (2003), serão descritas a
seguir: Redes LAN são pequenas redes, a maioria de uso privado, que interligam
estações dentro de pequenas distâncias. São muito utilizadas para a conexão de
computadores pessoais e estações de trabalho, permitindo o compartilhamento de
recursos e informações. Seu tamanho é restrito, o que permite o conhecimento do
seu tempo de transmissão e a detecção de falhas com antecedência, permitindo
assim um gerenciamento simplificado da rede.
Redes MAN ou redes metropolitanas são praticamente uma versão ampliada
das redes locais, pois utilizam tecnologias semelhantes. As MAN’s podem ser
formadas por escritórios vizinhos ou abranger uma cidade inteira sendo ou redes
públicas ou redes privadas. Tanenbaum (2003) cita como exemplo de MAN as redes
de TV e internet a cabo, que existem na maioria das grandes cidades.
WAN ou redes geograficamente distribuídas são formadas por grandes áreas
geográficas que abrangem países e continentes. São formadas por um conjunto de
hosts, conectados através de uma sub-rede. Esses hosts são computadores
pessoais e a sub-rede é formada por operadoras telefônicas e provedoras de
internet.
3.4 Sistemas operacionais
Um sistema operacional funciona mais ou menos como os demais softwares
instalados em um computador, ou seja, são processos sendo executados pelo
processador. Sendo que é o sistema operacional que controla o hardware da
máquina, compartilhando os recursos entre os diversos processos que estiverem
sendo executados, além dos dispositivos de entrada e saída. (MACHADO, MAIA,
2007).
Tanto o UNIX e suas variantes como o Linux e o Windows são sistemas
18
operacionais de rede, pois ambos trazem nativamente recursos que permitem
interligação em redes e acesso a recursos remotos (COLOURIS et al, 2007).
A Ubuntu Foundation é uma organização que mantém o sistema operacional
Ubuntu. Sendo este um dos sistemas operacionais mais popular atualmente. O
Ubuntu é uma distribuição Linux baseada no Debian que é uma das distribuições
mais antigas ainda ativa (PETERSEN, 2012). Conforme consta no site do
desenvolvedor (UBUNTU, 2013), Ubuntu é uma palavra africana antiga e significa
humanidade para os outros ou eu sou o que sou pelo que nós somos. A ideia do
idealizador do Ubuntu, Mark Shuttleworth é que o Ubuntu fosse um sistema
operacional para desktop fácil de usar . A instalação da versão server do Ubuntu,
que é uma versão voltada para servidores trás uma coleção de servidores como,
servidor web e FTP (File Transfer Protocol)( PETERSEN, 2012).
19
3.5 Virtualização
A virtualização iniciou-se com mainframes com a intenção de reduzir custos e
hoje oferece tantas possibilidades que se tornou um novo campo na área de
tecnologia (SIQUEIRA, 2008).
Com o poder de processamento dos computadores atuais a virtualização foi
introduzida também nos desktops permitindo rodar um sistema operacional completo
dentro de outro. Com a virtualização eliminou-se a subutilização em servidores e
data centers, virtualizando-se sistemas, ferramentas e aplicações consegue-se
utilizar melhor os recursos de hardware (SIQUEIRA, 2008).
Existem diversos softwares disponíveis para virtualização em desktops, como
Xen, VMWare e VirtualBox (SIQUEIRA, 2008).
Virtualbox é um software de virtualização de propriedade da Oracle que é
disponibilizado para as plataformas Intel e AMD e é compatível com os sistemas
operacionais Windows, MAC, Linux e Solaris. Com o Virtualbox é possível criar
máquinas virtuais completas e instalar sistemas operacionais diferente ou não do
sistema operacional hospedeiro. Pode-se executar vários sistemas operacionais
simultaneamente, tendo-se como limite o espaço disponível no HD (Hard Disk) e
memória (DOCUMENTATION, 2012).
3.5 Open source
A OSI (Open Source Initiative) é uma fundação sem fins lucrativos que surgiu
em 1998, com o intuito de defender o desenvolvimento colaborativo de software. O
termo open source foi criado pela organização neste mesmo ano, quando da
liberação do código fonte do navegador Netscape (ABOUT, 2012).
As definições do open source são derivadas do DFSG (Debian Free Software
Guidelines) que falam do desenvolvimento e distribuição de software livre. Para ser
considerado open source ou software livre o software precisa preencher alguns
requisitos como: não pode haver restrições de partes do código, não deve haver
restrições contra pessoas ou áreas de trabalho, o software deve ser disponibilizado
com o código fonte completo, o código pode ser modificado por qualquer pessoa,
20
entre outros (ABOUT, 2012).
3.6 Serviços de rede
Uma rede permite que diversos usuários utilizem recursos compartilhados.
“Em essência, um programa de cliente faz solicitações a partir de outro processo,
que em geral está executando em outro sistema.” (SCRIMGER, et. al. 2002, p.464).
Os servidores normalmente são computadores com mais recursos do que
computadores utilizados por clientes e mantidos em locais protegidos onde apenas
os administradores tem acesso (TANENBAUM, 2011).
Pode-se fazer uma divisão dos servidores em, servidores de rede local e
servidores de internet. Servidor de arquivos e servidor de impressão são exemplos
de servidores de rede local. Servidor web é um exemplo de servidor de internet
(MORIMOTO, 2011).
Os servidores web são peças fundamentais na infraestrutura da internet.
Nestes servidores ficam armazenadas todas as páginas da internet, inclusive as
páginas dos motores de busca e aplicativos web como o webmail (MORIMOTO,
2011).
O Apache, segundo Marcelo (2006), é o servidor web mais conhecido e
utilizado no mundo. O projeto do Apache é mantido pela Apache Software
Foundation. É um projeto de código aberto e é desenvolvido de forma colaborativa
por voluntários dos mais diversos países. Eles se comunicam através da internet,
fazendo correções e implementando melhorias no código. O servidor web Apache
surgiu em 1995. Usando como base o servidor web NCSA (National Center of
Supercomputing Applications) httpd (Hypertext Transfer Protocol Daemon)1.3, que
na época era o mais famoso, mas que havia sido descontinuado em 1994. Apenas
um ano após seu lançamento o Apache ultrapassou o NCSA se tornando o servidor
web mais utilizado na internet, feito que se mantém até hoje (Apache, 2012). No site
Netcraft (2013) que mantém um ranking de servidores web no mundo, o Apache
aparece em primeiro lugar em janeiro de 2013 com 55,26% dos servidores, em
segundo a Microsoft com 16,93%, em terceiro a Nginx com 12,64% e em quarto o
Google com 3,58%, como pode ser visto na figura 7:
21
Figura 7: Market share.
Fonte: Netcraft, 2013.
O SSH (Secure Shell) pode ser visto de várias formas. Dwived (2004) diz que
o SSH “pode ser descrito com protocolo, uma ferramenta de encriptação, uma
aplicação cliente/servidor”.
O SSH é um sistema de segurança baseado em software com uma
arquitetura cliente/servidor. Dados enviados pela rede são criptografados na origem
e descriptografados pelo SSH no destino de forma transparente para o usuário
(BARRETT, SILVERMAN, BYRNES, 2005). Com ele é possível fazer acesso remoto
seguro e também transferir arquivos. O SSH pode ainda ser usado em conjunto com
outros softwares como o Rsync, criando uma espécie de túnel para garantir a
segurança na transferência de dados (MORIMOTO, 2011).
O projeto OpenBSD desenvolve o OpenSSH que é uma versão de código
aberto do SSH (OPENSSH, 2012).
O Rsync é um ótimo programa para quando há necessidade de se programar
backups. Com ele é possível sincronizar dados de dois diretórios na mesma
máquina ou remotamente transferindo apenas as modificações. O Rsync faz
comparações entre arquivos e inclusive de seu conteúdo, transferindo apenas as
modificações dentro deles. Com o Rsync pode-se facilmente realizar backup
22
incremental de um diretório ou até de partições inteiras (MORIMOTO, 2011).
No site do projeto Rsync (2013), estão listadas algumas das funcionalidades
do Rsync, entre os quais o Rsync pode atualizar toda uma árvore de diretórios,
pode-se configurá-lo para manter links simbólicos e hard links, preservar as
propriedades e permissões dos arquivos, trabalha com pipeline interno, e ainda tem
a funcionalidade do Rsync anônimo, que é de grande utilidade quando se quer fazer
espelhamento (RSYNC, 2013).
Heartbeat é uma ferramenta open source normalmente utilizadas em clusters
de alta disponibilidade.
O Heartbeat é uma solução aberta para cluster de alta disponibilidade
desenvolvido pelo projeto Linux-HA, sendo uma da mais utilizadas. O Heartbeat
monitora os servidores do cluster para permitir que um servidor assuma caso o outro
deixe de operar. A comunicação do Heartbeat pode ser feita através de cabos UTP
sobre IPv4 ou ainda através de cabos seriais. O Heartbeat deve ser instalado e
configurado nos dois lados, quando por qualquer motivo, se um servidor ficar
inoperante o Heartbeat inicializa os serviços no outro servidor (LINUX-HA, 2011).
3.7 Cluster
Quando dois ou mais computadores são ligados em rede para a execução de
operações em conjunto, tem-se um cluster (PITANGA, 2008). Foi a IBM
(International Business Machines) quem começou a explorar este sistema nos anos
60 com duas de suas máquinas. HASP (Houston Automatic Spooling Priority) e JES
(Job Entry System), que permitiram a interligação entre mainframes a um custo
moderado.
A computação em cluster ganhou força nos anos 80 principalmente pela
construção de processadores de alto desempenho, redes de comunicação de baixa
latência e padronização de ferramentas para computação paralela (PITANGA, 2008).
Ainda segundo Pitanga (2008), os clusters podem ser divididos em duas categorias
básicas, a saber, os de alta disponibilidade e de alto desempenho de computação.
Cluster de alta disponibilidade (HA - High Availability). Este tipo de cluster visa
garantir que um serviço que é oferecido na rede esteja sempre disponível, ou quase,
23
já que segundo Pitanga (2008), não é possível dar uma garantia total de que o
sistema nunca vai falhar. Atualmente com os computadores invadindo todos os
ambientes, e com usuários cada vez mais conectados, um cluster de alta
disponibilidade torna-se uma ferramenta importante e imprescindível em alguns
ambientes. Neste tipo de cluster os equipamentos são interconectados e ficam
monitorando um ao outro de forma que qualquer um que parar, o outro
automaticamente assumirá a sua função, de forma a manter o serviço disponível
pelo maior tempo possível.
Cluster de alto desempenho de computação (HPC – High Performance
Computing). No
cluster de
alto
desempenho, o
objetivo
é interconectar
equipamentos para conseguir um maior poder de processamento. Com isso o
cluster se torna uma boa opção para universidades e pequenas empresas que não
podem investir em um supercomputador. As aplicações modernas também exigem
cada vez mais poder de processamento, e com o alto custo dos supercomputadores,
a opção de paralelizar as aplicações em hardware comum se torna bastante atrativo
(PITANGA, 2008).
Cluster de balanceamento de carga (LB – Load Balance). Um cluster
balanceamento de carga é utilizado quando muitos usuários precisam acessar o
mesmo recurso. Dois ou mais computadores são interconectados e todos dispõem
dos recursos que serão acessados. Um software faz o monitoramento e distribuiu as
requisições dos usuários entre os computadores que fazem parte do cluster
(GORINO, 2006).
24
4 MATERIAIS E MÉTODOS
O cenário montado é ilustrado na figura 8, sendo que para a realização dos
testes foi usado um ambiente totalmente virtual, de forma que a figura do switch
desaparece, pois ao se configurar uma interface de rede no Virtualbox escolhendose o modo de rede interna os computadores se reconhecem como que estando na
mesma rede:
Figura 8: Cenário.
O cenário montado são dois servidores, e um cliente. Os dois servidores e o
cliente são conectados estando todos na mesma rede. Por ser um ambiente
virtualizado, as máquinas são configuradas através da interface de rede interna do
Virtualbox para estar na mesma rede e podem se comunicar sem a presença do
switch.
As configurações refente as máquinas foram deixadas os padrões oferecidos
25
pelo Virtualbox na hora da criação das máquinas. Tanto os servidores, como a
máquina cliente ficaram com 512MB de memória RAM (Random Access Memory) e
HD de 8GB.
Nos dois servidores foram instalado o SSH, o Rsync, o Heartbeat e o servidor
web Apache. Quando os servidores são ligados um dos servidores escolhidos será o
principal (master) e o outro será o secundário (slave) e ficará em modo de espera,
sendo que quando o servidor principal ficar inoperante através das simulações que
serão feitas, o segundo servidor assumirá o serviço. Os softwares instalados tem
cada um a sua função, que serão explicitados a seguir: o SSH é requisito para o
funcionamento do Rsync, que por sua vez fará a replicação de dados entre os
servidores para manter os dois atualizados independente de qual esteja atuando
como servidor principal no momento. O servidor web Apache será o serviço
oferecido na rede e o Heartbeat irá monitorar a disponibilidade do Apache de forma
que se o servidor que estiver ativo, por algum motivo deixar de oferecer o serviço, o
Heartbeat que estará instalado no servidor secundário inicializará o Apache,
mantendo assim o serviço disponível.
Para a execução do trabalho foram instaladas três máquinas virtuais com o
Virtualbox. O sistema operacional utilizado em duas das máquinas foi o Ubuntu
server 12.04. Estas duas máquinas formam o cluster, e na terceira máquina foi
instalado o Ubuntu 12.04, versão para desktop, que será o cliente para fazer os
testes. O nome de um dos servidores é sv1 e o outro sv2.
Depois da instalação do sistema operacional o primeiro passo é configurar as
placas de rede. De inicio foi utilizado duas placas de rede, uma em modo NAT
(Network Address Translation) para baixar os pacotes que seriam instalado e a outra
como rede interna para ser usado na rede local.
A placa de rede em modo NAT não necessita de nenhuma configuração. Já
para as placas da rede local foi utilizados os IPs 192.168.1.254 para o servidor sv1 e
192.168.1.253 para o servidor sv2, ambos com máscara de rede 255.255.255.0,
além disso foi utilizado o IP 192.168.1.100 para o cliente também com a mesma
máscara. Todas
compreenção.
essas
informações
constam
no
quadro
1,
para
melhor
26
Quadro 1 – Configurações dos computadores.
Computador
Nome
Endereço IP
Máscara de subrede
Servidor 1
sv1
192.168.1.254
255.255.255.0
Servidor 2
sv2
192.168.1.253
255.255.255.0
Cliente
cliente
192.168.1.100
255.255.255.0
O SSH se faz necessário para a utilização do Rsync, depois de configurar a
rede foi instalado o OpenSSH, foi gerado um par de chaves e foi configurado para
permitir o acesso sem senha, senão seria necessário digitar uma senha toda vez
que o Heartbeat fosse acessar o outro servidor e isso inviabilizaria o trabalho do
Heartbeat.
Depois foi a vez de instalar o Apache que foi o serviço escolhido para ser
oferecido na rede. A seguir os passos que foram seguidos para colocar o servidor
web em operação. O serviço web foi configurado nos dois servidores, foi criado um
diretório chamado website1 com o seguinte comando:
•
mkdir /var/www/website1
Dentro do diretório website1 foram criados outros dois diretórios, public_html
e logs, com os seguintes comandos:
•
mkdir /var/www/website1/public_html
•
mkdir /var/www/website/logs
Sendo o public_html, o diretório para a publicação do site e o diretório logs
para armazenar os logs.
Depois, dentro do diretório /etc/apache2/sites-available/ foi criado o arquivo
website1 e foi editado conforme a figura 9:
27
Figura 9: Virtual Host.
O diretório sites-available guarda as configurações dos domínios hospedados
em um mesmo servidor.
Foi depois criada uma página em HTML (HyperText Markup Language) para
servir de teste.
Antes de instalação do Heartbeat foi configurado o arquivo /etc/hosts nos dois
servidores sendo adicionadas as linhas abaixo:
•
192.168.1.254
sv1
•
192.168.1.253
sv2
Ficando como mostrado na figura 10:
28
Figura 10: Hosts.
O próximo passo é a instalação do Heartbeat em si. A instalação é simples,
bastando usar o comando apt-get, como mostrado na linha abaixo:
•
$ sudo apt-get install heartbeat
Após a instalação do Heartbeat, três arquivos devem ser configurados, todos
ficam no diretório /etc/ha.d/. São eles: o ha.cf, authkeys e o haresources.
O primeiro deles, o ha.cf foi configurado como na figura 11:
29
Figura 11: Ha.cf.
A descrição dos parâmetros é a seguinte:
•
logfile /var/log/ha-log – Neste arquivo fica armazenado as mensagens de log
do Heartbeat.
•
debugfile /var/log/ha-log – Neste arquivo são armazenados os logs de
depuração do heartbeat;
•
keeppalive 2 – Quando é inicializado o Heartbeat, ele fica testando
continuamente o servidor secundário enviando uma mensagem e aguardando
uma resposta, essas mensagens recebem o nome de heartbeat. Aqui se
define o tempo em segundos entre um heartbeat e outro;
•
deadtime 10 – Aqui é configurado o tempo que o Heartbeat deve esperar por
uma resposta do outro servidor;
•
udp eth0 – Através desta interface o Heartbeat fará a comunicação com os
outros nós da rede;
•
node sv1 – Nome do servidor 1;
•
node sv2 – Nome do servidor 2. A ordem deve ser seguida.
•
auto_failback off – Este parâmetro define se em caso de falha no servidor
principal, quando ele for reestabelecido, deve parar o servidor secundário e
reassumir o serviço. Se estiver configurado como off o servidor primário não
30
reassume o serviço quando for reestabelecido (LINUX-HA, 2013). A
configuração deste arquivo é igual nos dois servidores.
O segundo arquivo a ser configurado é o authkeys, e também é igual nos dois
servidores, a configuração do authkeys é como o da figura 12:
Figura 12: Authkeys.
Este é o arquivo de autenticação do Heartbeat. O dono deste arquivo tem que
ser o root e as permissões devem ser 600, por questões de segurança, já que com
estas permissões apenas o administrador terá acesso ao aquivo.
O linux trabalha com um sistema de permissões onde pode-se configurar
permissões para o dono do arquivo, para o grupo e para outros usuários. As
permissões vão de 0, que não dá nenhuma permissão, até 7 que dá permissão
totalsobre o arquivo ou diretório. No caso acima o dono tem permissão 6, o que
significa que o dono pode ler e escrever, o grupo tem permissão 0 e os outros tem
permissão 0. O sistema de permissão funciona como ilustrado no quadro 2:
Quadro 2 - Permissões no Linux
Permissão
Número
---
0
--x
1
-w-
2
-wx
3
r--
4
r-x
5
rw-
6
rwx
7
Fonte: Adaptado de Morimoto, 2009.
31
auth 1 – Esta linha define o número de autenticação que será usado,
normalmente é usado apenas um. Exitem três tipos possíveis para o Heartbeat, são
eles: CRC (Cyclic Redundancy Check), MD5 (Message Digest 5), e SHA1 (Secure
Hash Algorithm 1). Com o CRC não se utiliza chave de autenticação, portanto não é
seguro e deve ser utilizado em casos específicos. O SHA1 é o método mais seguro
(LINUX-HA, 2013).
Aqui está sendo usado autenticação md5 e a senha pode ser qualquer texto,
que neste caso foi escrito teste.
O último arquivo do Heartbeat a ser configurado é o haresources, os
parâmetros configurados são mostrados na figura 13:
Figura 13: Haresources.
Os parâmetros aplicados aqui são: sv1 é o nome do servidor primário é o que
o Heartbeat vai inicializar o apache quando for iniciado. O IP 192.168.1.1 é chamado
de IP flutuante, IP compartilhado ou ainda IP virtual. Ele deve estar na mesma rede
que os IPs das placas reais e é este IP que será anunciado na rede. E por fim
apache2 é o serviço que o Heartbeat irá monitorar. Este IP fica associado ao
Apache. Este arquivo é igual nos dois servidores. Este arquivo informa ao Heartbeat
que este é o IP que deve ser anunciado na rede, quando o servidor principal parar
de funcionar o Heartbeat que está trabalhando no servidor secundário assume este
mesmo IP para continuar disponibilizando o Apache. Se houvessem outros serviços
sendo oferecidos na rede, seriam adicionados neste mesmo arquivo de
configuração.
Utilizando-se o comando ifconfig é possível verificar as configurações de rede
e perceber como é criada uma interface virtual (eth0:0) que é a interface que será
usada pelo Heartbeat.
32
Figura 14: Ifconfig.
O Apache foi retirado da inicialização do servidor porque a partir destas
configurações é o Heartbeat quem fica responsável pela inicialização do Apache.
O Sysv-rc-conf é um utilitário onde se pode configurar o que será inicializado
com o sistema.
33
Figura 15: Sysv-rc-conf
Foi criado um script com o nome espelha.sh que será usado pelo Rsync para
fazer a sincronização dos dados do servidor web. A figura 16 mostra os parâmetros
do script:
34
Figura 16: Espelha.sh
Fonte: Os autores. 2013.
A primeira linha informa ao Rsync para copiar o diretório /var/www/website1
no servidor local e adicionar no /var/www do servidor remoto 192.168.1.253,
excluindo o conteúdo que estiver lá. Os parâmetros -aup e --delete que aparecem
nas linhas são o seguinte:
•
-a: arquivo. Informa o Rsync para copiar arquivos;
•
-u: updade. O Rsync só substituirá o arquivo, se o que ele estiver copiando for
mais recente;
•
-p: permissão. Com este parâmetro as permissões serão mantidas nos
arquivos copiados;
•
--delete: esta opção estando no final da linha faz com que o Rsync apague os
arquivos que existem no destino.
A segunda linha informa ao Rsync para copiar o diretório /etc/apache2/sites-
availabe também do servidor local para /etc/apache2 no servidor remoto
192.168.1.253 e também excluir o conteúdo que estiver lá.
Esse script foi adicionado no Crontab para fazer sincronização de cinco em
cinco minutos, assim a cada cinco minutos ele fará uma comparação entre os
arquivos dos servidores e sempre que houver modificação ele copiará os arquivos
mais novos para o servidor secundário. O utilitário Crontab encontra-se no
diretório /etc e sua configuração pode ser vista na imagem 17:
35
Figura 17: Crontab.
Quando os dois servidores são ligados, o Heartbeat é inicializado e procura
no arquivo haresources quem é o servidor principal, o Heartbeat do servidor principal
assume o IP ali especificado e inicializa o Apache que também está configurado
nesse arquivo. O Heartbeat do servidor secundário faz o mesmo processo porém ao
verificar que está no servidor secundário ele fica testando continuamente o servidor
principal de forma que quando não receber repostas, ele assume o papel de servidor
principal e inicializa o Apache. Assim o cliente continua acessando o serviço de
forma transparente.
Quando o servidor que parou de funcionar for reestabelecido, ele volta a ser
o servidor principal ou não, dependendo do que foi configurado no parâmetro
auto_failback no arquivo ha.cf.
O Rsync também fará a sincronização de dados quando o sv1 ficar operante
novamente, um script fará com que ele faça a sincronização dos dados assim que o
que o sv1 for iniciado. Para isso é necessário editar o arquivo /etc/rc.local, como
mostrado na figura 18:
36
Figura 18: Rc.local.
As configurações são as mesmas do script espelha.sh, porém com o caminho
inverso, ou seja, no primeiro caso o Rsync instalado no sv1 copia os dados do sv1
para o sv2 de 5 em 5 minutos, no segundo o Rsync instalado no sv1 copia os dados
do sv2 para o sv1 assim que o sv1 é iniciado.
37
5 RESULTADOS E DISCUSSÃO
Alguns testes foram feitos no ambiente montado e descrito anteriormente para
comprovar-se de que o ambiente de alta disponibilidade realmente estava
funcionando, para tal os arquivos da páginas em HTML de teste, foram deixados
dessincronizados justamente para saber quando se está no servidor v1 ou no sv2.
Para testar a conexão para saber se o cliente está conectado com o apache
utiliza-se o comando ping 192.168.1.1, onde 192.168.1.1 é o IP virtual, conforme
mostra a figura 19.
Figura 19: Comando ping.
Primeiramente foi parado o serviço Heartbeat no sv1 com o comando
#/etc/init.d/heartbeat stop, para verificar se o sv2 assumiria o serviço do Apache, o
que realmente aconteceu, pois a página web continua disponível na máquina cliente,
a partir do mesmo IP, conforme mostra a figura 20 na linha SERVER 2 que o sv2
assumiu o serviço e o IP virtual.
38
Figura 20: Heartbeat no servidor sv2.
Depois de iniciar o serviço no sv1 novamente, fez-se novo teste, com o
comando #ping 192.168.1.1 ativo, em determinado momento foi feito a simulação de
uma queima de placa de rede, desconectado o cabo de rede virtual e verificou-se
uma pequena demora na resposta do ping voltando em seguida. O Heartbeat já
tinha inicializado o Apache assumindo o IP virtual no sv2 e por isso o comando ping
continuou alcançando o destino e perdeu apenas 9 pacotes conforme a figura 21, e
demorando em torno de 10 segundos para que o sv2 assumisse o serviço Apache.
Figura 21: Estatísticas do comando ping para queima de placa de rede.
Uma simulação de queima de fonte também foi feita. Com os dois servidores
na posição inicial novamente, foi fechada a máquina virtual sv1 e ao atualizar o
navegador com o atalho Alt+F5, a página web continuava disponível através do sv2,
que ao perceber que o sv1 não respondia mais, assumiu suas funções conforme
mostra a figura 22, que se perdeu 10 pacotes levando 10 segundos para que o sv2
39
assumisse o serviço do sv1.
Figura 22: Estatísticas do comando ping 192.168.1.1 para queima de Fonte.
Também foi feito testes com o parâmetro autofail_back, ora foi deixado no
modo on, ora no modo off. Em todas as vezes funcionou com deveria, ou seja, em
modo on o sv1 assumia o serviço de volta quando era reestabelecido e em modo off,
o serviço se mantinha com o sv2 e o sv1 ficava em modo de espera. Pareceu ser
mais interessante manter o parâmetro em modo off para garantir a confiabilidade do
sistema pois se algum arquivo for corrompido por qualquer razão, pode acontecer de
o Rsync sincronizar e substituir os arquivos bons pelos corrompidos, o mais seguro
é que administrador verifique a integridade do sistema antes de sincronizar os
dados.
40
6 CONSIDERAÇÕES FINAIS
Foi exposto neste trabalho o porquê da implementação de um cluster de alta
disponibilidade. Os serviços que são oferecidos na rede precisam estar sempre
disponíveis. O usuário não quer ligar o seu computador e descobrir que os serviços
não estão funcionado. Em um servidor web, que foi o serviço testado neste trabalho,
a alta disponibilidade é um fator muito importante.
Com poucas ferramentas e um mínimo de arquivos de configurações
demonstrou-se como é possível manter um servidor web no ar, mesmo falhando
uma máquina. Com os testes feitos pode-se comprovar a eficácia do sistema, com o
Heartbeat inicializando o serviço no outro servidor, assim que o primeiro fica
inoperante, e o Rsync mantendo os dados sincronizados para que o usuário não
tenha que reiniciar o que estava fazendo, ou seja, o usuário nem percebe a troca de
servidor.
No caso de falha em um dos servidores, o administrador da rede deve o mais
rápido possível reestabelecer o servidor que parou de funcionar, o que diminui os
riscos de o serviço ficar indisponível, pois pode acontecer de ocorrer falha no outro
servidor.
Foi pesquisado outros softwares que também tinham os requisitos necessário
para fazer parte deste trabalho, como a ferramenta de monitoramento MON,
também foi pesquisado sobre o DRDB, que faz sincronização em tempo real.
Escolheu-se o Rsync por já se ter alguma familiaridade com a ferramenta e o
Heartbeat apesar de não ter-se nenhuma familiaridade, assim como também com o
MON ou outras ferramentas para monitoramento. Foram escolhidos os softwares
que serviriam aos objetivos propostos. Pesquisar ferramentas para este tipo de
trabalho gera até alguma dificuldade tamanha variedade, pois o mundo do software
livre é cheio de opções para as mais diversas áreas.
Neste trabalho foi configurado para o Rsync fazer a sincronização de tempos
em tempos, no caso de 5 em 5 minutos. É claro que em um ambiente crítico essa
sincronização deve ser feita em tempo real, como um raid em rede. Isso pode ser
feito em trabalhos futuros.
Esta implementação de cluster de alta disponibilidade na verdade é
41
incompleta, pois a ideia neste trabalho foi demonstrar algumas ferramentas. Para
trabalhos futuros existem muitos planos, como fazer redundância de placas de rede,
de switch, de nobreak, para ai sim ter um cluster de alta disponibilidade completo.
42
REFERÊNCIAS
ABOUT the OSI. Open Source Initiative. 2012.
<http://opensource.org/about>. Acesso em: 06 fev. 2013.
Disponível
em:
APACHE:
http
server
project.
Apache.org.
2012.
Disponível
<http://httpd.apache.org/ABOUT_APACHE.html>. Acesso em: 06 fev. 2013.
em:
BARRET, D. J. Silverman, R. E. Byrnes, R. G. SSH, the secure shell: the definitive
guide. 2. ed. Sebastopol: O'reilly Media Inc, 2005.
COULOURIS, G. DOLLIMORE, J. KINDBERG, T. Sistemas distribuídos:
conceitos e projetos. 4. ed. Porto Alegre: Bookman, 2007
DANTAS, M. Computação distribuída de alto desempenho: redes, clusters e grids
computacionais. Rio de Janeiro: Axcel, 2005
DOCUMENTATION:
user
manual.
Virtualbox,
2011.
Disponível
<https://www.virtualbox.org/wiki/Documentation>. Acesso em: 02, jan. 2012.
em:
DWIVED, H. Implementing SSH: Strategies for optmizing the secure shell.
Indianapolis: Wiley Publishing Inc, 2004.
FERREIRA, F. S. SANTOS, N. C. G. G. Cluster de alta disponibilidade:
abordagem OpenSource. Monografia. Escola superior de tecnologia e gestão de
Leiria, 2005.
GORINO, F. V. R. Balanceamento de carga em cluster de alto desempenho: uma
extensão para LAMP/MPI. Dissertação (Mestrado). Universidade estadual do
Marigá, 2006
INTERNET users. ITU, 2013. Disponível em: <http://www.itu.int/ITU-D/ict/statistics/>.
Acesso em: 31 jan. 2013.
LINUX-HA. HA High Availability. 2011. Disponível
ha.org/wiki/Main_Page>. Acesso em: 06 fev.2013.
em:
<http://www.linux-
MACHADO, F. B. MAIA, L. P. Arquitetura de sistemas operacionais. 4. ed. Rio de
Janeiro: LTC, 2007.
MARCELO, A. Squid. 5. ed. Rio de Janeiro: Brasport, 2006.
43
MORAES, A. F. Redes de computadores: fundamentos. 7. ed. São Paulo: Érica,
2010.
MORIMOTO, C. E. Linux: guia prático. Porto Alegre: Sul editores, 2009.
MORIMOTO, C. E. Redes: guia prático. Porto Alegre: Sul editores, 2010. 2ª
reimpressão.
MORIMOTO. C. E. Servidores Linux: guia prático. Porto Alegre: Sul editores, 2012.
NETCRAFT. January 2013 web server survey. 2013. Disponível em:
<http://news.netcraft.com/archives/2013/01/07/january-2013-web-server-survey2.html#more-7696>. Acesso em: 30 jan. 2013.
OPENSSH: keeping your communiqués secret. OpenSSH. 2012. Disponível em:
<http://www.openssh.com/>. Acesso em: 06 fev. 2013.
PETERSEN, R. Ubuntu 12.04 Server: Administration and reference. Alameda:
Surfing Turtle Press, 2012.
PITANGA, M. Construindo supercomputadores com Linux. 3. ed. Rio de Janeiro.
Brasport, 2008.
RSYNC features. Rsync. Disponível em: <http://rsync.samba.org/features.html>.
Acesso em: 10 jan. 2013.
SCRIMGER, R. SALLE, P. L. PARIHAR, M. GUPTA, M. TCP/IP: A bíblia. Tradução
Edson Furmankievcs, Docware traduções técnicas. Rio de Janeiro: Elsevier, 2002. 5ª
reimpressão.
SIQUEIRA, E. Para compreender o mundo digital. São Paulo. Globo, 2008.
SQUID: Optimising web delivery. Squid-cache.org.
<http://www.squid-cache.org/>. Acesso em: 05, jan. 2012.
2012.
Disponível
em:
TANENBAUM, A. S. Redes de computadores. Tradução Vanderberg D. de Souza.
Rio de Janeiro: Elsevier, 2003. 16ª reimpressão. Tradução de Computer networks.
4th. ed.
TANENBAUM, A. S. WETHERALL, D. Redes de computadores. Tradução Daniel
Vieira. São Paulo: Pearson Prentice Hall, 2011. Tradução de Computer networks.
5th. ed.
44
THE
Ubuntu
story.
Ubuntu.
2013.
Disponível
<http://www.ubuntu.com/project/about-ubuntu>. Acesso em: 28 jan. 2013.
em:
TORRES, G. Redes de computadores. Rio de Janeiro: Axcel, 2001.
WCRIVELINI. Bancos de dados & BI. IBM. 2012. Disponível em:
<https://www.ibm.com/developerworks/mydeveloperworks/blogs/ibmacademiccell/ent
ry/no_tempo_dos_cart_c3_b5es_perfurados1?lang=en>. Acesso em: 02 fev. 2013.

campus sombrio luã alfredo gonçalves ronaldo borges de

Transcrição

Documentos relacionados

Clusters de alta disponibilidade – uma abordagem Open

Apresentação - WordPress.com

Como perder seu becape

Gerenciamento simultâneo

desenvolvimento de um cluster de balanceamento de carga

Uma Arquitetura para Submissão e Gerenciamento de jobs em

The life and times of Coretta Scott King

Carolina CN Nascimento , Mara RBM Nascimento , Natascha AM

Release FINAL O Cluster Gastronomia

químico, farmacêutico, biotecnologia