CENTRO ESTADUAL DE EDUCAÇÃO TECNOLÓGICA PAULA SOUZA

Transcrição

1 CENTRO ESTADUAL DE EDUCAÇÃO TECNOLÓGICA PAULA SOUZA FACULDADE DE TECNOLOGIA DE LINS PROF. ANTONIO SEABRA CURSO SUPERIOR DE TECNOLOGIA EM REDES DE COMPUTADORES ANTONIO MARCOS HONORIO MAIKON HENRIQUE DA SILVA SOUZA ESTUDO E ANÁLISE DO BALANCEAMENTO DE CARGA DE SERVIDORES COM LINUX VIRTUAL SERVER (LVS) LINS/SP 1 SEMESTRE /2014

2 CENTRO ESTADUAL DE EDUCAÇÃO TECNOLÓGICA PAULA SOUZA FACULDADE DE TECNOLOGIA DE LINS PROF. ANTONIO SEABRA CURSO SUPERIOR DE TECNOLOGIA EM REDES DE COMPUTADORES ANTONIO MARCOS HONORIO MAIKON HENRIQUE DA SILVA SOUZA ESTUDO E ANÁLISE DO BALANCEAMENTO DE CARGA DE SERVIDORES COM LINUX VIRTUAL SERVER (LVS) Trabalho de Conclusão de Curso apresentado à Faculdade de Tecnologia de Lins para obtenção do Titulo de Tecnólogo em Redes de Computadores. Orientador: Prof. Me Julio Fernando Lieira. LINS/SP 1 SEMESTRE /2014

3 ANTONIO MARCOS HONORIO MAIKON HENRIQUE DA SILVA SOUZA ESTUDO E ANÁLISE DO BALANCEAMENTO DE CARGA DE SERVIDORES COM LINUX VIRTUAL SERVER (LVS) Trabalho de Conclusão de Curso apresentado à Faculdade de Tecnologia de Lins, como parte dos requisitos necessários para a obtenção do título de Tecnólogo em Redes de Computadores sob a orientação do Prof. Me Julio Fernando Lieira. Data de aprovação / / Orientador Julio Fernando Lieira Examinador Examinador

4 Dedicamos este trabalho aos nossos Professores e familiares que estiveram presente conosco durante toda esta jornada. Antonio Marcos Honório Maikon Henrique da Silva Souza

5 AGRADECIMENTOS Primeiramente agradeço a Deus por ter me dado saúde e força nesta caminhada para poder cumprir todas as etapas as quais me propus realizar. Agradeço a toda a minha família que sempre me apoiou e me ajudou a não desanimar nestes anos de estudos, principalmente aos meus pais Antonio e Gilda, minha sogra Antonia e meus irmãos Carlos, Gisele e Keli; agradeço a todos os meus primos e também a meu sobrinho, Diego, pela parceria nas aulas. Agradeço a Fatec por ter me dado esta chance de estudo que espero retribuir um dia. A todos os professores que com paciência e competência nos ajudam a nos tornar profissionais mais preparados para a vida. Ao professor Júlio Fernando Lieira, nosso orientador, que com muita dedicação nos ajudou em todos os momentos dessa caminhada e a professora Luciane Noronha que sempre me deu força nesta jornada. Um agradecimento especial a todos meus amigos de sala durante este curso, principalmente ao Maikon parceiro neste momento final e de muitas dificuldades. E como não poderia deixar de ser, agradeço a minha esposa Adriana, companheira e parceira de todas as horas, que não mediu esforços para me ajudar e me animar nos momentos de desânimo. E, claro, aos meus queridos filhos Karol e Marco Antonio, pois é por eles que concluo este curso. Antonio Marcos Honório

6 AGRADECIMENTOS Nessa etapa muito importante da minha vida e que irei carregar comigo todo conhecimento adquirido nesse precioso período de tempo, venho agradecer a todos que contribuíram nessa jornada. Primeiramente a Deus que traçou o meu caminho até aqui, com alegrias e saúde. A minha mãe Vilma e ao meu pai Otacilio que desde sempre me apoiaram e ofereceram o alicerce necessário, não só para concluir essa etapa em minha vida, mas como todas que passei até o presente momento. A minha tia Lourdes que tenho como uma segunda mãe. A minha irmã Pâmela e a minha namorada Ana pelo apoio e dedicação nos momentos em que precisei. A toda a minha família que se manteve presente comigo durante essa caminhada. Ao meu parceiro e amigo nesse trabalho Antonio Marcos Honório, por partilhar todo o seu conhecimento e dedicação em prol desse trabalho. A cada um dos professores, com os qual tive o privilégio de conviver durante esse período. Um agradecimento especial ao professor Julio Fernando Lieira, que graças ao seu conhecimento, dedicação e disponibilidade nos ajudou a concluir esse trabalho nos orientando e enriquecendo nossos conhecimentos. Agradeço a Fatec por proporcionar todos os recursos necessários para os estudos, e por ser palco da fase mais importante da minha vida, por isso, serei eternamente grato a essa instituição. Também agradeço aos amigos que posso chamar de irmãos que tive a sorte de fazer durante essa jornada: João Luiz, Cezar Henrique, Luciano Kiyosaque, Bruno Carvalho, Antonio Marcos, Bruno Vinicius, Mauricio Gimenez, Fernando e Gustavo Cremonesi, Mari Nogueira e Alexandre Kenji. Maikon Henrique da Silva Souza

7 RESUMO Este trabalho tem como objetivo apresentar uma solução que assegure um serviço web confiável e resguardado contra falhas, sejam elas de software ou de hardware. A solução adotada foi a criação de um cluster com balanceamento de carga utilizando a tecnologia do LVS, que é um projeto de código aberto cujas características de redundância, desempenho e escalabilidade se enquadram perfeitamente às necessidades deste trabalho. Para melhor compreensão do mesmo foram abordados conceitos de rede de computadores com suas topologias e arquitetura; assim como um levantamento bibliográfico sobre alta disponibilidade, clusters, além das tecnologias disponíveis para implementação do LVS. Todo processo de configuração e implantação da estrutura do LVS via Direct Routing foram descritos, bem como a coleta e análise dos dados do comportamento dos servidores WEB perante os testes de vários algoritmos de escalonamento definidos na estrutura do LVS. A tecnologia do LVS, além do fato de não incorrer em custo, se mostrou valiosa por oferecer um ambiente confiável não somente para um serviço web, mas como assegurar alta disponibilidade em um serviço de , banco de dados, proxy entre outros; assim torna-se uma tecnologia imprescindível para qualquer outro ambiente, seja ele acadêmico ou empresarial, e que tenha necessidade de garantir a total disponibilização de seus serviços. Palavras-chave: Cluster, balanceamento de carga, alta disponibilidade, Direct Routing.

8 ABSTRACT This work had the purpose of presenting a solution that ensure a reliable web service and sheltered against failures, whether of software or hardware. The adopted solution was to create a cluster with load balancing using technology of LVS, which is an open source project whose features redundancy, performance and stability fit perfectly to the needs of this work. For better understanding of the work were discussed concepts of computer network with their topologies and architecture; as well as a bibliographical survey about high availability, clusters, beyond the technologies available for deployment of LVS. The whole process of configuration and deployment of the LVS structure by way of Direct Routing were described, as well as the collection and analysis of data on the behavior of WEB servers, before the testing of various scheduling algorithms defined in the LVS structure. The LVS technology, beyond the fact of not incurring cost, proved valuable for providing a trusted environment not only for a web service, how to ensure high availability in an service, database, proxy among other; thus becoming an essential technology for any environment, be it academic or business that has the need of ensure the full provision of their services. Keywords: Cluster, Load Balancing, High Availability, Direct Routing.

9 LISTA DE ILUSTRAÇÕES Figura Modelo de computação centralizada Figura Modelo de computação distribuída Figura Exemplo de uma rede ponto-a-ponto Figura Exemplo de uma rede cliente/servidor Figura Topologia totalmente conectada Figura Topologia em malha Figura Topologia em anel Figura Topologia em barramento Figura Topologia em estrela Figura Topologia em árvore Figura Topologia sem fio Figura Camadas da arquitetura TCP/IP e respectivos protocolos Figura Datagrama do protocolo IP Figura Esquema de Alta Disponibilidade Figura Exemplo de cluster de balanceamento de carga Figura Esquema geral de um Linux Virtual Server Figura LVS via NAT Figura LVS via IP Tunneling Figura LVS via Direct Routing Figura Arquitetura LVS Figura Interface de Login do software piranha Figura Definição do IP primário e tipo de LVS no servidor LVS1 e LVS Figura Definição do IP Secundário e configurações de monitoramento Figura Adicionando um servidor virtual ao cluster LVS Figura Adicionando um servidor real ao cluster LVS Figura 3. 7 Servidores reais adicionados ao cluster LVS Figura Teste de funcionamento da estrutura Figura Configurações do algoritmo Round-Robin no LVS Figura Totalização das requisições recebidas - Algoritmo RR Figura Média de requisições recebidas pelo Apache no servidor WEB Figura Média de tráfego de entrada/saída de rede no servidor WEB

10 Figura Média de consumo de CPU no servidor WEB Figura Média de consumo de memória no servidor WEB Figura Configurações do algoritmo Weighted Round Robin no LVS Figura Totalização das requisições recebidas - Algoritmo WRR Figura Requisições - Apache no WEB1 - algoritmo WRR Figura Tráfego de entrada/saída de rede no WEB1 - algoritmo WRR Figura Média de consumo de CPU no - WEB1 - algoritmo WRR Figura Média de consumo de memória no WEB1 - algoritmo WRR... 77

11 LISTA DE QUADROS Quadro Diferenças entre redes cliente/servidor e ponto-a-ponto Quadro Modelo de Referência OSI Quadro Métodos de implementação do LVS Quadro Resultados de testes com algoritmos de escalonamento... 78

12 LISTA DE SCRIPTS Script Comandos para desabilitar o iptables Script Desabilitando o SELinux Script Configuração IP nas interfaces do servidor web Script Configuração IP nas interfaces do servidor web Script 3. 5 Configuração IP nas interfaces do servidor web Script Ativação das configurações IP nas interfaces Script Procedimentos de instalação e configuração inicial do Apache Script Configuração do Apache para gerar informações mais detalhadas Script Instalação das dependências do Monitorix Script Comandos para download e instalação do Monitorix Script Comandos instalação e configuração do arptables Script Configuração IP nas interfaces do servidor LVS Script Configuração IP nas interfaces do servidor LVS Script Ativação das configurações IP nas interfaces dos servidores LVS Script Instalação dos pacotes ipvsadm e piranha nos servidores LVS Script Configurações sysctl nos servidores LVS Script Configuração e inicialização do software piranha Script Arquivo com as configurações do cluster LVS criado pelo Piranha Script Script de requisição de página Script Configurações na máquina de requisição de páginas... 71

13 LISTA DE ABREVIATURAS E SIGLAS ARP - Address Resolution Protocol ARPA Advanced Research Projects Agency ARPANET - Advanced Research Projects Agency Network CAN - Campus Area Network CPU - Central Processing Unit CVS - Concurrent Version System DARPA - Defense Advanced Research Projects Agency DH - Destination hash DNS - Domain Name System FSP - Free Software Foundation FTP - File Transfer Protocol GNU - General Public License GUI - Graphical User Interface HTTP - Hyper Text Transfer Protocol HTTPS Hyper Text Transfer Protocol Secure IAB - Internet Activity Board IEEE - Institute of Electrical and Electronics Engineers IP - Internet Protocol IPVS - IP Virtual Server ISO - International Organization for Standardization Kbps - kilobit por Segundo LAN - Local Area Network LBLC - Locality-Based Least-Connection LBLCR - Locality-Based Least-Connection with Replication Scheduling LC - Least-Connection LVS Linux Virtual Server MAN - Metropolitan Area Network Mbps - Megabit por segundo NAT - Network Address Translation NAT - Network Address Translation NNTP - Network News Transfer Protocol

14 NQ - Never Queue OSI - Open Systems Interconnection PC - Personal Computer PHP - Hypertext Preprocessor RR Round Robin SED - Shortest Expected Delay SMTP - Simple Mail Transfer Protocol SRI - Stanford Research Institute SSH Secure Shell TCP - Transmission Control Protocol UCLA - University of California, Los Angeles UCSB - University of California, Santa Barbara UDP - User Datagram Protocol VLAN - Virtual Local Area Network WAN - Wide Area Network WLAN - Wireless Local Area Network WLC - Weighted Least-Connection WRR - Weighted Round Robin

15 SUMÁRIO INTRODUÇÃO REDES DE COMPUTADORES MODELO COMPUTACIONAL TOPOLOGIAS DE REDES Redes Ponto-a-Ponto Redes Cliente/Servidor TOPOLOGIAS DE CONEXÃO Topologia Totalmente Conectada Topologia em Malha Topologia em Anel Topologia em Barramento Topologia em Estrela Topologia em Árvore Topologia Sem Fio Topologia Híbrida ou Mista MODELO DE REFERÊNCIA OSI MODELO DE REFERÊNCIA TCP/IP Camada Física Camada Inter-Redes Camada de Transporte Camada de Aplicação BALACEAMENTO DE CARGA E ALTA DISPONIBILIDADE EM SERVIDORES CLUSTER Aplicações para Clusters Tipos de Clusters ALTA DISPONIBILIDADE BALACEAMENTO DE CARGA LINUX VIRTUAL SERVER (LVS) LVS VIA NAT... 44

16 2.6 LVS VIA IP TUNNELING LVS VIA DIRECT ROUTING ALGORITMOS DE ESCALONAMENTO Round-Robin (RR) Weighted Round-Robin (WRR) Destination hash (DH) Least-Connection (LC) Weighted Least-Connection (WLC) Shortest Expected Delay (SED) Never Queue (NQ) Locality-Based Least-Connection (LBLC) Locality-Based Least-Connection With Replication Scheduling (LBLCR) FERRAMENTAS EXISTENTES HeartBeat Piranha KeepAlived Ultra Monkey Balanceamento de Carga de servidores com LVS CONFIGURAÇÕES DOS SERVIDORES WEB Configurações de Rede Instalação e Configuração do Apache Instalação e Configuração do Monitorix Instalação e Configuração do Arptables CONFIGURAÇÕES DOS SERVIDORES LVS Configurando o Cluster de Balanceamento Via Software Piranha Definindo IP para os Servidores LVS Primário e Secundário Adicionar um Servidor Virtual ao Cluster LVS Adicionar e Ativar os Servidores Reais Configuração dos Servidores LVS Via Arquivo TESTE DE FUNCIONAMENTO DA ESTRUTURA ANÁLISE DO FUNCIONAMENTO E DESEMPENHO DO LVS METODOLOGIA DE TESTES TESTES COM O ALGORITMO ROUND-ROBIN (RR)... 71

17 4.3 TESTES COM O ALGORITMO WEIGHTED ROUND ROBIN (WRR) RESULTADOS DOS TESTES COM DEMAIS ALGORITMOS CONCLUSÃO REFERÊNCIAS BIBLIOGRÁFICAS... 83

18 17 INTRODUÇÃO Cada vez mais empresas dependem da tecnologia da informação para conseguir manter, promover e expandir seus negócios. Com o crescimento da internet vem se tornando imprescindível para todos os tipos de empresas o uso de um servidor confiável e sem falhas e com uma boa relação custo-benefício para dar sustentabilidade e segurança aos dados. Problemas frequentemente encontrados na web, tais como Página não encontrada, Tente novamente mais tarde, Serviço indisponível ; não só irritam o usuário como o impossibilita de realizar suas tarefas, causando prejuízo tanto para a empresa que disponibiliza o site quanto para o usuário. Alguns sites possuem tecnologias para suportar grandes números de acessos, como por exemplo, o site da Receita Federal que é conhecido por lidar de forma eficiente com situações de excesso de tráfego. Em 2005, foram entregues mais de 20 milhões de declarações do Imposto de Renda, sendo que 98% das declarações de IR Pessoa Física foram realizadas pela Internet. (AZEREDO, 2006) Entretanto, alguns sites ainda sofrem com o excesso de tráfego, como o site de compra coletiva Groupon, uma das principais empresas do mundo neste segmento do e-commerce e que apresentou desempenho abaixo do normal em sua infraestrutura de servidores. De acordo com um estudo da WatchMouse, uma empresa que realiza pesquisas sobre a internet, revelou que o gigante coletivo ficou 26 horas inoperante entre os dias 22 novembro a 22 dezembro de 2010, impedindo inúmeros usuários de comprarem em seu site. (E-COMMERCE, 2010) Outro exemplo de indisponibilidade que gerou transtornos e prejuízos aconteceu com o site do jornal on-line Africanidade.com em 25/04/2008, o servidor no qual o site estava hospedado, sofreu um grave problema técnico que provocou uma indisponibilidade no acesso ao site. Este problema técnico foi suficientemente grave ao causar perda de dados, o que obrigou a administração do jornal on-line a tomar a decisão de transferir os dados que se conseguiu recuperar para outro servidor e para outra empresa de hospedagem. (AFRICANIDADE, 2008) Como o objetivo de visar soluções eficazes para os problemas descritos acima, este trabalho tem como objetivo o estudo de técnicas para criar um serviço web confiável e protegido contra erros e falhas que possam acontecer, sejam elas

19 18 de software ou de hardware. Isso é possível por meio de um balanceamento de carga, que faz com que um servidor web não sobrecarregue e torne o serviço indisponível ou, em caso de falha de um servidor, automaticamente outra máquina assume o seu lugar e faz com que o sistema não pare de funcionar. A tecnologia base usada para o desenvolvimento do trabalho foi o Linux Virtual Server (LVS), que é um projeto open source e que tem como principal objetivo a criação de clusters com balanceamento de carga para aplicações críticas. Dentre suas características, pode-se mencionar sua redundância de serviços, desempenho e escalabilidade flexível. Para implantação de um serviço seguro e sem falhas é indispensável o uso da redundância como método para lidar com falhas em componentes confiáveis. Para que este método possa funcionar corretamente, um sistema tem que ter sempre um segundo servidor com as mesmas características do servidor principal, o qual assume as funções em caso de falha do servidor principal. A redundância fornece total segurança para o sistema como, por exemplo, caso um servidor precise ser removido para atualização ou manutenção, ele pode ser retirado e recolocado de volta, sem interrupção do serviço ao cliente. O LVS possui uma arquitetura totalmente transparente para o usuário final, na qual o cliente parece estar conectado a um servidor real. Porém é o LVS que realiza as requisições no lugar do cliente, assim, escolhe um entre dois ou mais servidores web, caso um desses servidores pare de responder, o LVS redireciona as requisições para os outros servidores Web que estão ativos, e fica transparente para o usuário. O fato da arquitetura ser transparente torna-se um fator de extrema importância, pois, a partir dele, um conjunto de servidores parece ser um servidor único, faz com que os usuários não saibam quantos servidores têm por trás do LVS, e tem-se apenas acesso as suas aplicações. Basicamente a transparência tem como objetivo esconder o fato de seus recursos e processos estarem distribuídos através de diversas máquinas. No que se refere à organização, este trabalho está dividido da seguinte forma: o primeiro capítulo descreve alguns conceitos importantes sobre redes de computadores, tais como topologia, protocolos e sua arquitetura; no segundo é feito um estudo sobre o conceito de alta disponibilidade, balanceamento de carga, a tecnologia de cluster e sobre LVS; o terceiro capítulo é demostrado um tutorial sobre

20 19 a instalação e configuração do software de balanceamento de carga, bem como outros utilitários necessários para a topologia de servidores utilizada neste trabalho; o quarto capítulo descreve os testes e resultados feitos com os diferentes algoritmos de balanceamento de carga, e por fim, têm-se as conclusões finais sobre o trabalho.

21 20 1 REDES DE COMPUTADORES Segundo Torres (2009), as redes de computadores surgiram da necessidade da troca de informações de dados que estão fisicamente localizados longe do usuário, ele afirma que é impossível não pensar em redes de computadores, quando o assunto é informática. Na Internet, essa troca de informações armazenadas remotamente vai ao extremo quando acessa dados em locais remotos, e o local onde geralmente estão armazenadas, não tem a menor importância para o usuário. Para Tanenbaum (1997), rede de computadores é um conjunto de computadores autônomos interconectados, trocando informações entre si, através de um fio de cobre, fibras ópticas, rádio, micro-ondas, satélites de comunicação, entre outros. Um exemplo de rede mundialmente difundida é a Internet, que possui milhares de computadores interconectados trocando as mais diversas informações, tais como , arquivos, páginas pessoais e corporativas. A Internet iniciou-se no final da década de 1960, quanto a Agência de Projetos de Pesquisas Avançadas do Departamento de Defesa dos Estados Unidos da América Advanced Reserch Projects Agency (ARPA), mais tarde chamada de DARPA começou a consolidar uma rede experimental de computadores de longa distância, chamada de ARPANET, que se espalhou pelos Estados Unidos. O objetivo original da ARPANET era permitir aos fornecedores do governo compartilhar caros e também escassos recursos computacionais. Inicialmente a ARPANET permitia que os laboratórios de pesquisa dos Estados Unidos da América (EUA) (Universidade da Califórnia UCLA em Los Angeles, Universidade de Utah, em Salt Lake City, Universidade da Califórnia em Santa Barbara UCSB, e Stanford Research Institute SRI em Stanford) trocassem informações entre si. Desde o início, entretanto, usuários da ARPANET também usavam a rede para colaboração. Essa colaboração abrangia desde compartilhamento de arquivos e programas, e troca de mensagens via correio eletrônico ( ) até desenvolvimento conjunto de pesquisa usando computadores remotos. (TORRES, 2001) Segundo Torres (2009), atualmente, as redes de computadores podem ser classificadas de acordo com o tamanho da área geográfica que elas abrangem.

22 21 Local Area Network (LAN) é o nome dado às redes locais mais comuns, sua abrangência pode chegar até ao espaço de uma sala ou mesmo de um prédio inteiro, pois se ultrapassar essa demanda pertencerá á outra classificação. O padrão de mais comum deste tipo de rede chama-se Ethernet ou IEEE Wireless Local Area Network (WLAN) o que diferencia esta da LAN é a ausência de cabos, utilizam transmissores de radiofrequência. A arquitetura mais popular deste tipo de rede chama-se Wi-Fi ou IEEE Campus Area Network (CAN) também chamada de rede de campo é uma rede maior que a local, com a abrangência maior que um prédio, possui interligação de pelo menos duas redes locais. Exemplo disso são os hospitais, universidades e grandes empresas. Metropolitan Area Network (MAN) é uma rede metropolitana, podendo abranger até mesmo uma cidade inteira, interligando redes locais e de campo, que geralmente são realizadas por concessionárias de telecomunicações (Embratel, Oi, Vivo etc.). Wide Area Network (WAN) também chamada de rede de longa distância abrange uma área maior que uma cidade, atuando na esfera mundial, sua melhor definição é a internet. Virtual Local Area Network (VLAN) neste caso pode-se configurar uma rede de computadores distante fisicamente, que mesmo assim fazem parte de uma rede local, para que possam acessar e compartilhar recursos. Internet que é rede mundial de computadores e que interliga milhões de computadores em todo o mundo, de vários tipos e tamanhos, marcas e modelos e com diferentes sistemas operacionais. A Intranet, rede privada que usa o mesmo modelo da internet, navega por meio de um navegador web em um site interno da empresa, disponível para funcionários. Extranet é uma intranet que permite acesso remoto, através de um modem ou mesmo por meio da Internet. 1.1 MODELO COMPUTACIONAL Para Torres (2009) a classificação das redes de computadores varia conforme

23 22 o processamento dos dados e pode ser de processamento centralizado, processamento distribuído ou processamento cooperativo. A computação centralizada foi o primeiro modelo de redes de computadores, possuíam uma grande capacidade de processamento sendo acessado através de terminais sem qualquer poder de processamento (terminais burros), que apenas nos dão dispositivos de entrada (teclado e monitor) para conectarmos ao computador central conforme a figura 1.1. Figura Modelo de computação centralizada Fonte: Farias, 2006, Adaptado pelos autores A computação cooperativa, segundo Torres (2009), é um tipo de computação distribuída. Nela vários computadores executam a mesma tarefa. Quando são utilizados computadores comuns conectados à internet, esse tipo de computação passa a chamar de computação em nuvem, mas se os computadores forem dedicados ela passa a chamar computação em grade. Na computação distribuída cada máquina tem seu próprio processador, logo, tem poder de processamento. Elas podem ser classificadas como cliente/servidor, ponto-a-ponto, baseada em servidor e front-end/back-end. A figura 1.2 demostra um exemplo de computação distribuída. Torres (2009) afirma que as redes baseadas em servidores são semelhantes

24 23 às de computação centralizada. A diferença é que na computação centralizada os terminais não possuem qualquer tipo de processamento, diferente das baseadas em servidor, nas quais os computadores não são terminais burros e sim usados como clientes, portanto capazes de realizar processamento de dados. Redes Front-End/Back-End são utilizadas na comunicação entre servidores (frontal e traseiro). O modelo mais comum é o servidor web (front-end) e o servidor de banco de dados (back-end). Assim quando é feita a solicitação de uma página para o servidor web ele busca os dados no servidor de banco e então envia ao usuário. O servidor web é responsável pela formatação e apresentação dos dados. (TORRES, 2009) Figura Modelo de computação distribuída Fonte: Farias, 2006, Adaptado pelos autores 1.2 TOPOLOGIAS DE REDES Topologia de redes é o canal no qual o meio de rede está conectado e que pode ser descrito fisicamente ou logicamente Redes Ponto-a-Ponto As redes ponto-a-ponto possuem algumas características importantes que devem ser lembradas. Elas são utilizadas em locais geograficamente menores, são fáceis de serem implementadas, possuem baixo custo, o sistema de cabeamento é

25 24 simples, não necessitam de um administrador e não existem computadores servidores. Porém possuem pouca segurança, exigem que os computadores sejam independentes e instalados em um mesmo ambiente de trabalho e são de difícil expansão. A Figura 1.3 mostra um exemplo de rede ponto-a-ponto. (TORRES, 2001) Figura Exemplo de uma rede ponto-a-ponto Fonte: Torres, 2001, p.8 Na rede ponto-a-ponto, os computadores compartilham dados e periféricos sem muita burocracia. Qualquer computador pode facilmente ler e escrever arquivos armazenados em outros computadores da rede bem como utilizar periféricos que estejam instalados em outros PC's. Obviamente tudo isso depende da configuração, que é feita em cada computador individualmente. Ou seja, não há papel de um computador servidor como nas redes cliente/servidor. (TORRES, 2001) Os computadores presentes em uma rede ponto-a-ponto são computadores completos, isto é, funcionam normalmente quando não estão ligados em rede, tanto no que diz respeito ao hardware quanto ao software. De acordo com Torres (2001), a grande vantagem das redes ponto-a-ponto é a facilidade de instalação e de configuração, onde os próprios usuários podem configurar manualmente quais serviços estarão disponíveis em seu computador. Essa vantagem, entretanto, traz alguns inconvenientes como, por exemplo, a vulnerabilidade em relação à segurança da rede. As redes ponto-a-ponto são ideais para escritórios nos quais existem poucas

26 25 estações, podendo haver o controle dos arquivos, pois nesse tipo de rede todas as estações conseguem ler e gravar informações em qualquer outra estação, sem perder a integridade das informações. O correto é existir regras entre os usuários da rede, definindo apenas uma estação para armazenamento das informações. O custo de implementação deste tipo de rede é baixo, pois não são necessários servidores e outros recursos de infraestrutura, que são caros para pequenas organizações. Não há grandes gastos com a administração da rede, pois somente as próprias estações dos usuários são configuradas. Também não se gasta muito com cabeamento, pois este tipo de rede é destinado a estruturas de pequeno porte, não sendo necessários recursos como fibras ópticas ou pontos para acesso sem fio Redes Cliente/Servidor Nesse tipo de rede existe a figura do servidor, geralmente um computador dedicado a fornecer recursos aos usuários da rede. O servidor é um computador especializado que executa apenas tarefas específicas como armazenar e compartilhar dados, por exemplo. A utilização de Servidores traz vários benefícios como segurança, disponibilidade e integridade das informações, além da otimização de recursos. (TANENBAUM, 2003) A configuração de uma rede cliente servidor e toda administração é feita de forma centralizada, ou seja, as configurações estão no servidor. Desta forma é possível executar processos diretamente no servidor, processos estes resultantes de aplicativos executados nas estações, aumentando a organização e segurança da rede. O custo para a implementação desse tipo de rede depende muito das necessidades da organização, pois essa rede poderá possuir vários servidores, cada um com uma função específica. É necessário um administrador de redes para configuração e manutenção dessa rede. Geralmente também são essenciais investimentos maiores em infraestrutura como um centro de dados para alocar estes servidores e cabeamento mais específico como fibras ópticas para interligação dos servidores e outros dispositivos da rede. (TANENBAUM, 2003) O desempenho dessa estrutura em relação a ponto-a-ponto, considerando um servidor que atenda às necessidades, é maior, pois, as estações não ficam responsáveis pelo processamento referente à rede, ou seja, o armazenamento de

27 26 arquivos ou o compartilhamento da Internet são de responsabilidade dos servidores. Os servidores desse tipo de rede podem ser computadores simples ou equipamentos sofisticados. A definição de qual utilizar depende das necessidades da organização, dos recursos disponíveis e da necessidade de futura expansão dos serviços disponibilizados. Nesse tipo de arquitetura é possível implementar bancos de dados oferecendo serviços de armazenamento e disponibilidade de informações para as demais estações, como mostra a Figura 1.4. Figura Exemplo de uma rede cliente/servidor Fonte: Tanenbaum, 2003, p.4 No Quadro 1.1 podem ser observadas as principais diferenças existentes entre os dois modelos descritos. Quadro Diferenças entre redes cliente/servidor e ponto-a-ponto Cliente/Servidor Ponto-a-Ponto Serviço de diretório Administração centralizada Alta manutenção Implementação complexa Várias opções de segurança Alto custo Não tem serviço de diretório Não tem administração centralizada Baixa manutenção Simples implementação Segurança fraca Baixo custo Fonte: Torres, 2009, p.13

28 TOPOLOGIAS DE CONEXÃO Segundo o autor Torres (2009) as redes de computadores podem ser conectadas das seguintes maneiras: Topologia Totalmente Conectada Neste modelo cada computador possui uma conexão individual para cada outro computador, sendo assim ele oferece o maior nível de redundância, porque caso a conexão seja interrompida é possível continuar a conexão entre eles simplesmente mudando o caminho da conexão. É claro que neste caso o caminho será mais longo. A figura 1.5 a seguir mostra um exemplo deste tipo de topologia. Figura Topologia totalmente conectada Fonte: Torres, 2009, p Topologia em Malha Ela é parecida com a anterior, mais usa menos conexões e alguns computadores precisam passar por outros para acessar determinado destinatário. Para alguns autores não á distinção entre estes dois tipos, eles consideram os dois como rede em malha. A figura 1.6 mostra um modelo desta topologia.

29 28 Figura Topologia em malha Fonte: Torres, 2009, p Topologia em Anel De acordo com Torres (2009), cada computador possui dois cabos, um conectado ao anterior e outro conectado ao mais próximo computador da rede. Redes em anel são capazes de transmitir e receber dados em qualquer direção, mas as configurações mais usuais são unidirecionais, de forma a tornar menos sofisticado os protocolos de comunicação que asseguram a entrega da mensagem corretamente e em sequencia ao destino, conforme é demostrado na figura 1.7. Figura Topologia em anel Fonte: Torres, 2009, p.22

30 Topologia em Barramento Neste tipo de topologia há um elemento central ao quais todos os computadores são conectados. Quando o elemento central é partido, a rede deixa de funcionar. Este modelo é muito usado em redes Ethernet usando cabo coaxial ou cabo de par trançado usando um periférico concentrador chamado hub. Este tipo de rede também é conhecido como topologia linear e fica bastante claro que nenhum micro pode usar o cabo enquanto uma comunicação está sendo efetuada. A figura 1.8 mostra como micros são ligados fisicamente. (TORRES, 2009) Figura Topologia em barramento Fonte: Torres, 2009, p Topologia em Estrela Redes do tipo estrela são aquelas em que os dispositivos de rede convergem para um ponto central, ou seja, um concentrador. Esse concentrador central é um hardware, que pode ser hub, switch ou roteador. Todos os equipamentos como computadores, impressoras de rede, pontos de acesso sem fio, etc. Convergem para o ponto concentrador da rede e, havendo problema nesse ponto da rede, toda a rede fica inoperante porque o concentrador é o equipamento responsável para servir as informações aos demais computadores da rede. Esse tipo de rede é mais eficiente e eficaz, porque, se existir uma interrupção em uma das estações de trabalho, a rede não será comprometida.

31 30 Outra vantagem da topologia em estrela é a sua flexibilidade, e também o uso de cabeamento estruturado, que permite melhor organização, controle e expansão do cabeamento da rede. A figura 1.9 mostra um exemplo de ligação desta topologia. Figura Topologia em estrela Fonte: Torres, 2009, p Topologia em Árvore É uma topologia também chamada estrela hierárquica e é feita ligando-se redes estrelas junta. Esta é a topologia mais comum atualmente, ela utiliza mais periféricos concentradores. A figura 1.10 demostra um exemplo de ligação. Figura Topologia em árvore Fonte: Torres, 2009, p.23

32 Topologia Sem Fio Como o próprio nome diz, ela permite que computadores se conectem a rede sem a necessidade de uso de cabos. É necessário um equipamento chamado ponto de acesso Wireless Access Point (WAP) para fazer a conexão entre os computadores dotados de placa de rede sem fio e a rede física. A figura 1.11 demostra um exemplo deste tipo de rede. Figura Topologia sem fio Fonte: Torres, 2009, p Topologia Híbrida ou Mista São redes que usam mais de uma topologia descrita acima ao mesmo tempo. 1.4 MODELO DE REFERÊNCIA OSI O modelo Open Systems Interconnection (OSI), proposto pela Organização Internacional de Padronização, não é uma arquitetura de rede, pois não especifica os serviços e os protocolos que devem ser usados em cada camada e sim informa o que cada uma deve ser responsável. (TANENBAUM, 1997)

33 32 O modelo OSI descreve sete camadas, onde cada nova camada é criada quando há necessidade de outra camada de abstração. As camadas referenciadas devem executar funções bem definidas. Este modelo é tido como base das arquiteturas já existentes e para o desenvolvimento de novas arquiteturas de redes, sendo que nem sempre todas as camadas que o modelo propõe são implementadas. Em seguida, uma breve descrição das camadas embasada na literatura de Tanenbaum (1997) e Stallings (2005) será realizada, onde começa-se pela camada mais inferior: Camada Física: lida com as características de acesso ao meio físico, ou seja, é a camada responsável pela transmissão dos bits em um meio de comunicação. Esta camada é interconectada a outra camada física através de um meio físico para que haja a comunicação, seja ele, metálico, de fibra ou eletromagnético. Camada de Enlace: faz a interface entre o bloco de dados e o meio físico. Sua principal finalidade é dividir a informação recebida da camada superior (Rede) em quadros (do inglês: frames) com tamanho permitido pelo meio físico, o que reduz a perda dessas informações através de controle de fluxo, controle de erros e sincronização. Camada de Rede: provê às camadas superiores independência quanto à tecnologia de transmissão utilizada. Responsável também por endereçamento lógico e roteamento de pacotes, e por este motivo, é de fundamental importância para os projetos de rede. Camada de Transporte: realiza controle dos dados transmitidos e proporciona confiabilidade, controle de fluxo, recuperação de dados perdidos, transmissão e recepção simultânea (do inglês: full duplex). Camada de Sessão: camada responsável pelo controle de conexões entre aplicações como estabelecimento, gerenciamento e término de sessões entre as partes envolvidas. Também é responsável pela gerência do tráfego, tokens (conjunto de caracteres) e pela sincronização. Camada de Apresentação: esta camada é responsável pela adoção de um sistema padronizado de representação dos dados em alto nível, compressão e codificação de dados. Camada de Aplicação: serve de interface entre os usuários e as demais camadas OSI, é onde ocorrem todas as trocas de informações úteis ao usuário.

34 33 O Quadro 1.2 exemplifica as camadas, serviços e exemplos de utilização aplicados do modelo OSI, descrito anteriormente. Quadro Modelo de Referência OSI Camadas Serviços Exemplos 7 Aplicação Aplicação do Usuário FTP, Web, Browser 6 Apresentação Encriptação, compressão ASCII, UniCode, jpg 5 Sessão Controle, sincronismo RPC, NetBios 4 Transporte Recuperação de erro TCP, UDP 3 Rede Roteamento, conexão IP, IPX 2 Enlace Controle de erro de fluxo FDDI, Frame Relay, PPP 1 Física Interface de acesso ao meio Conector, cabo Fonte: Stallings, 2005, Adaptado pelos autores 1.5 MODELO DE REFERÊNCIA TCP/IP Esse modelo baseia-se principalmente em um serviço de transporte orientado à conexão fornecido pelo Transmission Control Protocol (TCP), e em um serviço de rede não orientado à conexões (datagrama não confiável), fornecido pelo protocolo Internet Protocol (IP). (TANENBAUM, 2003) Diferente dos sistemas proprietários, o TCP/IP foi desenvolvido como padrão aberto no qual qualquer um pudesse usar em uma grande escala de interoperabilidade de sistemas. A ideia deste modelo surgiu no Departamento de defesa Americano, que tinha como objetivo manter a comunicação entre as bases militares em uma ocorrência de ataques ou catástrofes que afetassem os meios de comunicação. (MENDES, 2007) Os padrões da arquitetura TCP/IP não são elaborados por órgãos internacionais de padronização, como a ISO ou a IEEE. O coro técnico que coordena o desenvolvimento dos protocolos dessa arquitetura é um comitê denominado Internet Activity Board (IAB). O IAB é formado por pesquisadores seniores, tendo a maioria deles projetado e implementado os protocolos da arquitetura internet. O IAB, na realidade, produz poucos documentos. Qualquer

35 34 pessoa pode projetar, documentar, implementar e testar um protocolo para ser usado na Internet. (SOARES, 1995) Segundo Odom (2003), o TCP/IP possui uma série de protocolos menores: na verdade, o próprio nome TCP/IP é uma combinação de dois desses protocolos: o TCP e o IP. A arquitetura TCP/IP é composta por quatro camadas conforme é demostrado na figura Figura Camadas da arquitetura TCP/IP e respectivos protocolos Fonte: Odom, 2003, Adaptado pelos autores Camada Física A camada de rede, ou física, é responsável por converter as tensões elétricas recebidas pela placa de rede em bits 1 ou 0. Em seguida, esses bits são agrupados em pacotes e entregues à camada superior que, por sua vez, continuará repassando até chegar à camada de aplicação, na qual o conteúdo recebido será processado e apresentado ao usuário. (MENDES, 2007) Na arquitetura Internet (TCP/IP) não há restrições às redes que são interligadas para formar a inter-rede. Para uma rede ser conectada ela deve apenas possuir uma interface que a torne compatível com o protocolo IP. Essa função se encontra mais especificamente no nível de interface da rede, que encaminha os datagramas IP para os destinos específicos. Para realizar este encaminhamento os endereços IP são traduzidos para os endereços de hardware dos dispositivos conectados à rede. (SOARES, 1995)

36 Camada Inter-Redes O nível inter-redes é responsável pela interligação de redes de comunicação. Sua tarefa è permitir que os hosts enviem e recebam pacotes em qualquer rede e garantir que estes pacotes trafegarão corretamente até seu destino. O roteamento de pacotes é uma questão de grande importância neste nível, assim como o controle de congestionamentos na rede. (TANENBAUM, 2003) Estas mensagens podem chegar a uma ordem diferente daquela em que foram enviadas, obrigando as camadas superiores a reorganizá-las, caso a entrega em ordem seja desejável. (TANENBAUM, 2003) A camada inter-rede define um formato de pacote oficial e o protocolo IP. O pacote ou datagrama (Figura 1.13) utilizado pelo protocolo IP consiste em um cabeçalho e um payload (pacotes de dados), sendo que o cabeçalho possui um comprimento fixo de 20 bytes mais um comprimento variável. A tarefa da camada inter-redes é entregar os pacotes IP onde são necessários. O roteamento é uma questão de grande importância nessa camada, assim como a necessidade de evitar congestionamentos. (TANENBAUM, 2003) Figura Datagrama do protocolo IP Fonte: Tanenbaum, 2003, p Camada de Transporte O nível de transporte provê uma conexão entre a acamada de aplicação e os

37 36 serviços oferecidos pelas camadas mais baixas (física e inter-redes). Isso torna as redes físicas transparentes para a camada de aplicação. A camada de transporte trata também do controle de conexão, oferecendo serviços orientados à conexão e serviços sem conexão. (FOROUZAN, 2008) Dois protocolos fim-a-fim atuam nesta camada. O primeiro deles, o TCP, é um protocolo orientado a conexão confiável que permite a entrega sem erros de um fluxo de bytes, originado de um determinado computador, em qualquer outro computador da inter-rede. Esse protocolo fragmenta o fluxo de bytes de entrada em mensagens e encaminha cada uma delas para a camada inter-redes. No destino, O TCP cuida também do controle de fluxo, impedindo que um transmissor rápido sobrecarregue um receptor lento com um volume de mensagens maior do que ele pode manipular. (TANEMBAUM, 2003) O segundo protocolo, o User Datagram Protocol (UDP), é um protocolo de conexão não confiável destinado a aplicações que não requerem controle de fluxo nem a manutenção da sequência das mensagens enviadas. Ele é amplamente usado em consultas e aplicações diretas do tipo cliente/servidor com solicitação e resposta, nas quais a entrega é mais importante do que a entrega precisa, como transmissão de dados de voz ou de vídeo. (TANEBAUM, 2003) Camada de Aplicação A camada de aplicação trata de protocolos de alto nível. No modelo TCP/IP questões de representação, codificação e controle de diálogo foram tratados em uma única camada. O TCP/IP combina todas as questões relacionadas a aplicações e presume que esses dados estejam empacotados corretamente para a próxima camada. (MENDES, 2007) A camada de aplicação contém os protocolos de alto nível. Dentre eles estão o protocolo de terminal virtual (Telnet), o File Transfer Protocol (FTP) e o protocolo de correio eletrônico Simple Mail Transfer Protocol (SMTP). O protocolo de terminal virtual permite que o usuário de um computador estabeleça login em uma máquina remota e a utilize. O protocolo de transferência de arquivos permite mover dados com eficiência de uma máquina para outra. Originalmente, o correio eletrônico era um tipo de transferência de arquivos. Posteriormente um protocolo especializado foi desenvolvido para essa função. Muitos outros protocolos foram incluídos com o

38 37 decorrer dos anos como o Domain Name System (DNS), que realiza o mapeamento dos nomes de hosts para seus respectivos endereços de rede, o Network News Transfer Protocol (NNTP), protocolo usado para mover novos artigos e o Hyper Text Transfer Protocol (HTTP), utilizado para acessar páginas web, entre outros. (TANEMBAUM, 2003) Neste capítulo foram abordados aspectos gerais de rede de computadores, suas topologias e protocolos. No próximo capítulo serão abordados assuntos referentes à Alta Disponibilidade, Cluster, com ênfase em LVS.

39 38 2 BALACEAMENTO DE CARGA E ALTA DISPONIBILIDADE EM SERVIDORES Neste capítulo são abordados os conceitos relacionados a clusters, suas aplicações e seus tipos, balanceamento de carga, alta disponibilidade, escalabilidade computacional, estudo sobre a tecnologia do LVS, algoritmos de escalonamento e algumas das ferramentas existentes que possibilitam a implantação e funcionalidade do ambiente. 2.1 CLUSTER De acordo com o autor Dantas (2002) Cluster é um sistema que compreende um conjunto de computadores ou sistemas na qual trabalham de forma agregada para executar aplicações ou desempenhar outras tarefas, produzindo a ilusão de um recurso único. Esse conceito é denominado de transparência do sistema. Ele foi desenvolvido para balancear servidores entre computadores, tem como objetivo dividir certo processamento de dados com outras máquinas conectadas na mesma rede para acelerar o processamento. (DANTAS, 2002) Aplicações para Clusters Os clusters podem ser utilizados para uma infinidade de aplicações. Basicamente, para qualquer uma que demande processamento pesado. Como exemplos de aplicações, destaca-se a previsão meteorológica (previsão do tempo e condições climáticas), simulações geotérmicas (simulação de eventos no solo), renderização de efeitos especiais (muito usado em filmes), simulações financeiras, distribuição de carga, entre outras. (DANTAS, 2002) Basicamente, qualquer tipo de aplicação crítica, ou seja, aplicações que não podem ser interrompidas ou não podem perder dados (como os sistemas de bancos, por exemplo), podem empregar as tecnologias de cluster, desde que devidamente configurados para não serem sujeitas a falhas graves. Assim, o cluster deve contar com nobreaks ou geradores que assegurem o funcionamento do sistema mesmo nos casos de queda de energia, além de meios de manutenção e detecção e falhas eficientes. (DANTAS, 2002)

40 Tipos de Clusters Segundo Pitanga (2003) Existem vários tipos de clusters, aqui estão descritos os tipos de clusters mais utilizados: Cluster de alta disponibilidade: os sistemas deste modelo conseguem permanecer ativos por um extenso período de tempo e em plena condição de uso de forma contínua através do uso da redundância implícita ao sistema, além disso, conseguem detectar erros se resguardando de possíveis falhas, esse tipo de cluster é muito empregado para base de dados de missões críticas, para os correios, servidores de arquivos e aplicações. Cluster de alto desempenho: esse tipo de cluster tem como papel permitir que a união de vários computadores comuns consiga-se um alto poder de processamento. Cluster para balanceamento de carga: este modelo tem como papel distribuir controladamente o processamento. Seu mecanismo de redundância exige constante monitoramento, se um nó falhar as requisições são redistribuídas entre os nós disponíveis no momento. São utilizados, por exemplo, em cluster de servidores de web. 2.2 ALTA DISPONIBILIDADE A Alta Disponibilidade está vinculada diretamente a crescente dependência dos serviços oferecidos pelos computadores. Atualmente, várias empresas contam com os recursos computacionais para fornecerem os seus serviços, como sistemas bancários, sites web, e-business, banco de dados, entre outros. Um cluster de Alta Disponibilidade tem como finalidade manter os serviços prestados, por um sistema computacional, disponíveis a todo o momento, mesmo em caso de falhas. Isso é obtido através da criação de réplicas dos serviços e servidores, onde os computadores atuam como um único sistema. Cada computador monitora os outros por meio de software, e no caso de ocorrer uma falha um deles assume os serviços daquele que ficou indisponível. (PITANGA, 2003) Segundo Pitanga (2003) A Alta disponibilidade pode ser classificada como: Disponibilidade básica: Empregada em máquinas comuns, sem mecanismos especiais, garantindo disponibilidade de 99% a 99,9%. Isto equivale a

41 40 dizer que em um ano a máquina pode ficar indisponível por um período de 9 horas a quatro dias. Alta disponibilidade: São mecanismos especializados que contém mecanismos de detecção, recuperação e mascaramento de falhas elevando a disponibilidade do sistema. Nesse modelo, as máquinas têm uma disponibilidade de 99,99% a 99,999%, podendo ficar indisponível por um período de 5 horas até uma hora em um ano de operação. Disponibilidade contínua: teoricamente ideal chegando muito próximo de 100%, neste modelo o tempo de inoperância do sistema é insignificante, todas as paradas planejadas ou não são mascaradas, e o sistema está sempre disponível, mas sempre existe a possibilidade do sistema parar. A figura 2.1 demostrada a seguir apresenta um modelo de alta disponibilidade, na qual os Servidores são precisamente réplicas, tanto de hardware como de software. O Servidor da direita, através do esquema de monitoramento, detecta a indisponibilidade do Servidor da esquerda, e logo assume o posto para manter o serviço disponível. Figura Esquema de Alta Disponibilidade Fonte: Pitanga, 2003, Adaptado pelos Autores 2.3 BALACEAMENTO DE CARGA Esta solução tem como finalidade manter o equilíbrio de carga entre vários servidores, assegurando assim a disponibilidade do serviço em momentos de

42 41 elevados acessos. A necessidade desta implementação é devido a elevada quantidade de tráfego nos servidores que prestam serviço em uma rede, pois, um dos maiores problemas enfrentados na Internet são os excessivos acessos quando se tem apenas um servidor. De acordo com Pitanga (2003) O sistema de cluster baseado em balanceamento de carga consiste em integrar seus computadores para que todas as requisições provenientes dos clientes sejam distribuídas de forma equilibrada entre os servidores. A tarefa principal é redirecionar essas requisições de entrada por meio de um elemento que fará o balanceamento entre os servidores e os usuários. Consequentemente, nessa estrutura teriam-se múltiplos servidores, mas que parecem ser apenas um para o cliente. A figura 2.2 mostra um tipo de cluster que é especialmente empregado em serviços de comércio eletrônico e provedores de Internet, que precisam resolver diferenças de carga provenientes de múltiplas requisições de entrada em tempo real. Figura Exemplo de cluster de balanceamento de carga Fonte: Pitanga, 2003, Adaptado pelos Autores 2.4 LINUX VIRTUAL SERVER (LVS) O LVS é um projeto Open Source que tem como principal objetivo a construção de sistemas com alta disponibilidade e profundamente escaláveis, a

43 42 partir do uso conjunto de vários servidores. A arquitetura é totalmente imperceptível para o usuário final e os serviços são providos por um conjunto de máquinas e acessados por meio de um único servidor. O LVS pode oferecer serviços de maior capacidade, desempenho e serviços redundantes em relação aos serviços disponíveis em servidores únicos. (GOVERNO ELETRÔNICO, 2006) Dentre suas características, é importante citar seu desempenho e escalabilidade flexível. O LVS é um sistema de cluster totalmente transparente para seu usuário final, pois mesmo que tenha 20 nós em seu cluster, seu usuário interagirá com apenas um endereço de entrada. Para o funcionamento do LVS são necessários dois tipos de máquinas: Load Balancer: este é o host responsável por receber as requisições vindas dos clientes e transmiti-las aos servidores reais do cluster, lógico que este é o ponto vulnerável do cluster. Mas se o ponto de entrada é apenas uma máquina, isto é uma falha, pois se esta máquina falhar, consecutivamente o cluster também falhará, porém pode-se usar ferramentas como o HeartBeat para monitorar e criar um "espelho" deste Servidor de Load Balancer para se caso ele falhar, a máquina espelhada assumir seu lugar automaticamente. Servidores reais: são os servidores do cluster que detêm os serviços oferecidos pelo cluster aos clientes. Para um cluster é necessário que exista no mínimo dois servidores reais. (GOVERNO ELETRÔNICO, 2006) O LVS é como um roteador da camada quatro do modelo OSI. A estrutura do cliente-servidor continua preservada, onde cada cliente pensa que está diretamente conectado a um servidor real e este pensa que está conectado diretamente a um cliente. Tanto o cliente como o servidor não percebem que as conexões sofrem a intervenção do direcionador. Um servidor real do LVS não coopera e não sabe da existência de outros servidores reais no LVS, um LVS não é um beowulf (Projeto de cluster que utiliza computadores pessoais) e também não é um cluster, mas se comporta como um agregador de serviços que possibilita o atendimento de uma demanda grande em um serviço. O código IPVS é responsável por possibilitar a criação do sistema LVS, é uma coleção de modificações para kernel Linux, que combinadas com as capacidades de roteamento e filtragem de pacotes de uma máquina Linux, transformam-na em um roteador com características especiais, capaz de balancear sessões TCP e UDP entre várias máquinas. Este roteador especial chamado Linux Director distribui a

44 43 carga de requisições de serviços entre os computadores que os proveem. Com isso, o sistema constituído pela máquina Linux com o código IPVS e as outras máquinas que hospedam os serviços é chamado Linux Virtual Server. (GOVERNO ELETRÔNICO, 2006) O sistema LVS não precisa de nenhuma modificação nos servidores reais ou nos clientes. Estes por sua vez, enviam suas requisições apenas para uma máquina não importando quantos servidores reais estejam provendo os serviços, que podem ser os comuns HTTP e HTTPS, servidores de , bancos de dados, Concurrent Version System (CVS), Secure Shell (SSH), ou seja, em geral todas as aplicações TCP/IP. (GOVERNO ELETRÔNICO, 2006) O LVS fornece, de maneira imperceptível e simples, um ambiente altamente escalável de alta disponibilidade. Seu ponto único de falha é o Director, mas mesmo assim, em conjunção com outras ferramentas como HeartBeat e Ldirectord, pode-se construir um sistema de alta disponibilidade para o Director, aumentando ainda mais sua confiabilidade e eliminando seu ponto único de falha. A figura 2.3 demostra como funciona um servidor Linux Virtual Server. Figura Esquema geral de um Linux Virtual Server O LVS pode ser implantado de três formas diferentes, como Virtual Server via Network Address Translation (NAT), via IP Tunneling e via Direct Routing.

45 44 No LVS via NAT tem como vantagem a utilização de qualquer sistema operacional nos servidores reais, mas tem como desvantagem a baixa capacidade implantação de servidores reais, além de sua alta latência e seu menor desempenho comparado aos métodos IP Tunneling e Direct Routing. (MACK, 2004) O método IP Tunneling tem como vantagem seu alto desempenho, sua capacidade de suportar um número maior de servidores reais (mais de 100), e a possibilidade de implantar os servidores reais em uma rede diferente dos servidores LVS. A desvantagem desse método é em relação aos sistemas operacionais dos servidores reais, que devem suportar túneis. (MACK, 2004) O método Direct Routing oferece alto desempenho, os servidores reais podem utilizar a maioria dos sistemas operacionais, desde que a interface de loopback não responda arp. Todos os servidores da estrutura devem estar no mesmo segmento de rede. (MACK, 2004) O quadro 2.1 demonstra as principais características dos métodos NAT, IP Tunneling e Direct Routing. Quadro Métodos de implementação do LVS 2.5 LVS VIA NAT Segundo Cota (2005), a superioridade do Linux Virtual Server via NAT está em que os servidores reais podem executar qualquer sistema operacional que

46 45 suporta TCP/IP com endereços IP privados e apenas um endereço IP é necessário para o Load Balancer. A desvantagem deste tipo de cluster do LVS é a limitação da escalabilidade, caso o número de servidores reais em seu cluster passe de 20 servidores. Caso este número seja ultrapassado, o load balancer pode ser um gargalo em seu sistema LVS, pois todos os pacotes que passam pelo load balancer têm que ser reescritos para fazer o NAT. Isto é lógico, pois supondo que a média do tamanho dos pacotes TCP que irão trafegar por seu load balancer seja de 563 bytes, o tempo médio para reescrever este pacote é de 60us, em um processador Intel Pentium. O throughput (capacidade total de um canal em processar e transmitir dados durante um determinado período de tempo) do load balancer será de 8.93 Megabit por Segundo (Mbps). Ao assumir que o throughput dos servidores reais seja de 400 Kilobit por Segundo (kbps), o load balancer pode gerenciar até no máximo 22 servidores reais. Lógico que isso é baseado em suposições e projetado para ambientes realmente enormes, com mais de 20 nós de cluster. A figura 2.4 demostra LVS via NAT. Figura LVS via NAT 2.6 LVS VIA IP TUNNELING De acordo com Cota (2005), neste tipo de cluster o load balancer ao invés de fazer a comunicação de entrada e saída, ele faz apenas um agendamento das

47 46 requisições, pois a resposta do servidor real é enviada diretamente ao usuário, sem passar pelo load balancer. Desta maneira, o load balancer pode administrar até 100 servidores reais, sem gerar gargalos no sistema. Este tipo de LVS é recomendado para implementação de sistemas de Proxy (define os intermediários entre o usuário e seu servidor, tendo como função a conexão do computador local com a rede externa) para a Internet altamente disponível. Pois o load balancer encaminha as requisições dos clientes para os servidores Proxy e estes respondem diretamente para os usuários. Para que esta estrutura funcione, todos os servidores do cluster precisam ter o IP Tunneling habilitado. E é aqui que teremos um problema, pois habilitar este IP Tunneling pode ser simples para o Linux, mas talvez não seja se tiver servidores reais com Solaris, por exemplo. Isto dificulta a utilização de servidores reais com sistemas operacionais diferentes. A figura 2.5 demostra um exemplo de LVS via IP Tunneling Figura LVS via IP Tunneling 2.7 LVS VIA DIRECT ROUTING Como descrito por Cota (2005), no tipo de cluster via Direct Routing, o servidor LVS só processa requisições de entrada, deixando os servidores reais

48 47 responder diretamente para os usuários, utilizando roteamento direto. A única limitação para este tipo de LVS é que tanto o load balancer quanto os servidores reais precisam ter uma interface de rede que esteja no mesmo segmento ou Sub-Rede. A figura 2.6 exemplifica o LVS via Direct Routing. Figura LVS via Direct Routing Estas três formas dependem de um algoritmo de escalonamento para realizar o balanceamento de carga do LVS. 2.8 ALGORITMOS DE ESCALONAMENTO Como descrito no Governo Eletrônico (2006), existem diversos algoritmos utilizados para a implementação do LVS e seus métodos de escalonamento para o balanceamento de carga. Os métodos de escalonamento controlam a maneira como a carga é distribuída entre os nós que compõem o sistema. Quando o Director recebe uma requisição de um cliente, é através dos algoritmos de escalonamento que ele decide qual nó deverá tratá-la. Existem métodos de escalonamento dinâmico que dão maior controle sobre a carga de chegada, com pouco ou nenhum custo adicional em processamento. O

49 48 Director mantém uma lista do número de conexões ativas e inativas para cada nó do cluster e usa esta informação para determinar qual nó irá receber a nova conexão Round-Robin (RR) Através da leitura do Governo Eletrônico (2006), é possível afirmar que o Director armazena uma lista com os endereços de cada servidor real, assim que recebe uma conexão, ele a redireciona para um servidor dessa lista, onde uma próxima conexão será enviada para o servidor seguinte e assim continua percorrendo essa lista de forma circular atendendo todas as requisições. Todos os servidores da lista são tratados de maneira igual, não importando quantas conexões estão sendo manipuladas por um servidor específico, nem seu tempo de resposta e/ou capacidades de processamento Weighted Round-Robin (WRR) De acordo com a leitura do Governo Eletrônico (2006), cada nó do sistema LVS possui um peso, baseado na quantidade de carga que ele pode processar. O peso é então usado, em conjunto com o método Round-Robin, para selecionar o próximo nó que será usado quando uma nova conexão chegar, sem levar em consideração o número de conexões que ainda estão ativas, servidores reais com pesos maiores terão prioridade no recebimento e quantidade de requisições, se comparados com servidores reais com pesos menores Destination Hash (DH) De acordo com o Governo Eletrônico (2006), neste método, o Director, envia requisições de um mesmo endereço IP de origem para o mesmo servidor real no sistema LVS, usando uma lista estática de endereços de destino. O método é útil quando o servidor real é um servidor Proxy ou cache Least-Connection (LC) Neste método conforme citado no Governo Eletrônico (2006), quando uma

50 49 nova conexão chega, o Director verifica o número de conexões ativas e inativas para decidir para qual nó irá enviar a requisição. Para realizar esta escolha, o Director multiplica o número de conexões ativas do nó por 256 e adiciona ao resultado o número de conexões inativas resultando em um overhead (processamento em excesso) para cada nó. O nó com menor overhead receberá a conexão. Caso haja nós com mesmo overhead, o primeiro nó encontrado na tabela do IPVS será selecionado Weighted Least-Connection (WLC) De acordo com as conclusões do Governo Eletrônico (2006), este método mescla o Least-Connection com um peso para cada nó, útil para ser usado com nós de diferentes capacidades de processamento. O Director define para qual nó uma requisição será enviada, calculando o overhead, como no método anterior, dividindo este número pelo peso associado ao nó. O nó com menor valor associado após esta operação receberá a conexão. Caso haja nós com mesmo valor associado, o primeiro da tabela do IPVS será selecionado Shortest Expected Delay (SED) De acordo com o Governo Eletrônico (2006), pode-se considerar que este método pode prover uma pequena melhoria em relação ao método WLC em serviços que usam TCP e mantêm a conexão ativa enquanto o nó processa a requisição. O cálculo do valor do overhead para o SED é feito adicionando-se 1 ao número de conexões ativas, dividido pelo peso associado a cada nó. O nó com menor overhead recebe a requisição. Deve-se notar neste algoritmo: Ele não usa o número de conexões inativas enquanto determina o overhead para cada nó; Ele adiciona 1 ao número de conexões ativas para antecipar como o overhead irá parecer quando uma nova conexão for realizada; O algoritmo SED tenta minimizar o tempo de espera para cada trabalho até sua finalização. O tempo de espera é (Ci+1) /Ui, sendo Ci o número de conexões do

51 50 servidor e Ui o peso fixado para este servidor; A diferença entre SED e WLC é que SED inclui a conexão que chega à função de custo, incrementando 1. Ele apresenta melhor qualidade em grandes sistemas heterogêneos, cujos pesos variam muito Never Queue (NQ) De acordo com que é descrito no Governo Eletrônico (2006), este método proporciona uma melhoria em relação ao SED, pois caso um nó não possua conexões ativas ele ganhará uma nova requisição de serviço. Apesar do resultado exposto no cálculo do SED podem ocorrer situações em que uma máquina que não possua nenhuma conexão ativa apresente um overhead maior que outra que possua Locality-Based Least-Connection (LBLC) Segundo o Governo Eletrônico (2006), os Directors também podem direcionar o tráfego de saída para um agregado de servidores Proxy transparentes (utilizado em redes amplas sem interação com o usuário). Nesta configuração, os nós do cluster são Proxy transparentes ou servidores de web cache (responsável por procurar pela página web requisitada em seu cache e caso a possua, avalia sua idade e a confronta com a sua data de validade estipulada pelo criador da página ou segundo um conjunto de regras estipuladas pelo próprio servidor de web cache) que estão entre os clientes e a Internet. Quando o LBCL é usado, o Director tenta enviar todas as conexões de um endereço IP particular para o mesmo servidor Proxy invisível. Ou seja, a primeira vez que uma requisição chegar, o Director definirá um servidor real para atendê-la usando uma versão um pouco modificada do método WLC e todas as requisições subsequentes deste cliente continuarão a ser enviadas para o servidor escolhido Locality-Based Least-Connection With Replication Scheduling (LBLCR) É semelhante ao LBLC, mas com uma melhoria, o Director contém um mapeamento de um cliente para um agregado de servidores que podem atendê-lo,

52 51 se todos os nós do conjunto estiverem sobrecarregados, o Director seleciona um servidor com menos conexões e o adiciona ao conjunto. Caso este conjunto não se modifique em um intervalo de tempo específico, o servidor com maior carga será excluído. Além de algoritmos de escalonamento, existem ferramentas que podem ser utilizadas em conjunto com o LVS para realizar o balanceamento de carga e alta disponibilidade de um serviço. 2.9 FERRAMENTAS EXISTENTES Para implementar uma estrutura de alta disponibilidade e balanceamento de carga é necessário o uso de ferramentas que possibilitam a implantação, segurança e funcionalidade do ambiente HeartBeat De acordo com Governo Eletrônico (2006), o HeartBeat tem como função criar um backup de um servidor, que pode utilizar como base o Load Balancer que é o ponto frágil do cluster. Com um backup do load balancer, o heartbeat pode monitorar via cabo Ethernet ou serial o servidor original e quando for verificado que o serviço LVS falhou no load balancer, ele automaticamente ativa o backup, que assume o lugar do load balancer até que um administrador possa corrigir o problema no servidor original Piranha Segundo Ludolf (2011), o Piranha é uma das ferramentas de clustering da Red Hat Inc., que inclui o módulo IPVS do kernel (Gerencia os recursos do sistema operacional e permite que os programas façam uso deles), uma tecnologia de monitoração do cluster e uma interface web para configuração do cluster. A tecnologia de monitoração do Piranha tem como propósito averiguar o status dos servidores de balanceamento ativo e backup, e também verificar a disponibilidade dos serviços nos servidores reais. O Piranha é constituído dos seguintes componentes:

53 52 Código de kernel do IPVS; Daemon do LVS que gerencia a tabela de roteamento utilizando a ferramenta ipvsadm ; Daemon nanny, responsável por monitorar os servidores e serviços nos servidores reais do cluster; Daemon pulse responsável por controlar os outros daemons e chavear o LVS entre os Directors ativos e backup em caso de falha; Ferramenta Piranha GUI para gerenciar e administrar o ambiente do cluster KeepAlived De acordo com KeepAlived (2012), KeepAlived é uma ferramenta que garante uma segurança para a estrutura, e ele possui algumas funcionalidades nativas interessantes como: Redundância de Directors, ou seja, se o mestre falhar, o slave vai assumir; Segurança dos servidores reais, ou seja, se um servidor real deixar de responder por um serviço, ele será automaticamente removido do ambiente; Aviso constante, caso aconteça alguma falha no ambiente, o usuário poderá ser notificado por Ultra Monkey É um projeto criado para fornecer serviços de alta disponibilidade e de balanceamento de carga, utilizando o sistema operacional Linux para prover uma solução flexível que pode ser usada para diversas tarefas. Embora funcione sobre Linux, o software Ultra Monkey fornece clustering para qualquer serviço, de uma forma virtual, desde que executado num sistema operacional que possa comunicar usando TCP ou UDP. (ULTRA MONKEY, 2005)

54 53 3 BALANCEAMENTO DE CARGA DE SERVIDORES COM LVS Este capítulo mostra uma implementação de balanceamento de carga de servidores com LVS (Linux Virtual Server) de alta disponibilidade. O método LVS escolhido foi o Direct Routing, conforme descrito no capítulo anterior. Para tanto, foi criada uma infraestrutura de testes com máquinas virtuais conforme mostrado na figura 3.1, e é utilizado o software de virtualização Virtual Box. Foram criadas ao todo seis máquinas virtuais, sendo três Servidores Web (servidores que detêm os serviços oferecidos pelo cluster aos clientes), e dois Servidores LVS (responsáveis por receber as requisições vindas dos usuários finais e transmiti-las aos servidores do cluster, realizando o balanceamento), e uma para efetuar requisições. Em todas as máquinas virtuais da estrutura, foi utilizado o sistema operacional PUIAS/Springdale Linux 6.4. Tal distribuição foi escolhida por sua compatibilidade com os softwares necessários para implementação do LVS, o que não ocorreu com outras distribuições como Debian, Ubuntu Server e OpenSuse, também testadas. Figura Arquitetura LVS

55 54 O funcionamento da arquitetura implementada da estrutura será da seguinte maneira: a) A máquina cliente, através de um script php, fará requisições de páginas web; b) Tais requisições serão recebidas pelo servidor LVS primário, o qual direciona o pedido para um dos três servidores web; c) O servidor web escolhido recebe o pedido de página e responde ao cliente. A escolha do servidor web para o qual o pedido será direcionado é orientada pelo algoritmo de escalonamento utilizado. Neste sentido, foram testados oito algoritmos disponibilizados na ferramenta Piranha, utilizada neste trabalho para gerenciar o LVS, e cujos resultados estão descritos no próximo capítulo. Cabe salientar que a arquitetura montada, implementa alta disponibilidade do servidor LVS por meio de um segundo servidor, o qual assume o balanceamento em casos de falha do servidor LVS primário, sem que haja uma grande interrupção no sistema. 3.1 CONFIGURAÇÕES DOS SERVIDORES WEB Os servidores web disponibilizam os serviços que serão oferecidos para os clientes. Nestes servidores, além da instalação do Apache (software que implementa o serviço web), também foi instalado a ferramenta Monitorix, utilizada para obter relatórios referentes ao estado de vários componentes do servidor, tais como utilização de CPU, memória, disco, rede; comportamento do servidor Apache quanto ao número de requisições recebidas, consumo de memória e CPU. Além da instalação destes softwares, também foi feita a instalação e configuração do arptables, necessário para o perfeito funcionamento da estrutura do LVS quando implementado via Direct Routing (conforme descrito na seção 2.7) Configurações de Rede Antes de iniciar as configurações, deve-se desabilitar o iptables e o SELinux nos três servidores web, uma vez que na distribuição PUIAS/Springdale, utilizada nos servidores web, o iptables e o SELinux vêm habilitados por padrão. O script 3.1 mostra os comandos necessários para desabilitar o iptables.

56 55 # service iptables save # service iptables stop # chkconfig iptables off Script Comandos para desabilitar o iptables O SELinux é desabilitado editando-se o arquivo /etc/sysconfig/selinux mudando a diretiva SELinux de permissive para disabled (script 3.2). # vi /etc/sysconfig/selinux # This file controls the state of SELinux on the system. # SELINUX= can take one of these three values: # enforcing - SELinux security policy is enforced. # permissive - SELinux prints warnings instead of enforcing. # disabled - No SELinux policy is loaded. SELINUX=disabled # SELINUXTYPE= can take one of these two values: # targeted - Targeted processes are protected, # mls - Multi Level Security protection. SELINUXTYPE=targeted Script Desabilitando o SELinux Fonte: Elaborado pelos Autores, 2014 Depois é necessário configurar as interfaces de rede dos três servidores web editando os arquivos /etc/sysconfig/network-scripts/ifcfg-eth0 e /etc/sysconfig/network-scripts/ifcfg-lo:0 (Scripts 3.3, 3.4, 3.5). Servidor Web 1 # vi /etc/sysconfig/network-scripts/ifcfg-eth0 DEVICE=eth0 TYPE=Ethernet ONBOOT=yes BOOTPROTO=static IPADDR= NETMASK= # vi /etc/sysconfig/network-scripts/ifcfg-lo:0 DEVICE=lo:0 IPADDR= NETMASK= NETWORK= Script Configuração IP nas interfaces do servidor web 1

57 56 Servidor Web 2 # vi /etc/sysconfig/network-scripts/ifcfg-eth0 DEVICE=eth0 TYPE=Ethernet ONBOOT=yes BOOTPROTO=static IPADDR= NETMASK= # vi /etc/sysconfig/network-scripts/ifcfg-lo:0 DEVICE=lo:0 IPADDR= NETMASK= NETWORK= Script Configuração IP nas interfaces do servidor web 2 Servidor Web 3 # vi /etc/sysconfig/network-scripts/ifcfg-eth0 DEVICE=eth0 TYPE=Ethernet ONBOOT=yes BOOTPROTO=static IPADDR= NETMASK= # vi /etc/sysconfig/network-scripts/ifcfg-lo:0 DEVICE=lo:0 IPADDR= NETMASK= NETWORK= Script 3.5 Configuração IP nas interfaces do servidor web 3 É importante notar que a configuração da interface virtual lo:0, como mostrado, é a mesma para os três servidores web. O IP aqui utilizado deve ser o mesmo IP da interface virtual dos servidores LVS. Depois de editado os arquivos, para efetivar as configurações são necessários executar os comandos mostrados no script 3.6 nos três servidores. # ifdown eth0 # ifup eth0 # ifup lo:0 && echo "ifup lo:0" >> /etc/rc.local Script Ativação das configurações IP nas interfaces

58 Instalação e Configuração do Apache O serviço web foi implementado através do software Apache. Aqui são mostrados os procedimentos para sua instalação e configuração, os quais devem ser feitos da mesma forma nos três servidores web (web1, web2 e web3). O script 3.7 mostra os comandos para os procedimentos para: a) Atualizar a base de informações do sistema de gerenciamento de pacotes do Linux; b) Instalar o pacote do Apache; c) Configurar o serviço para inicializar automaticamente junto com a inicialização do sistema; d) Inicialização manual do Apache. # yum upgrade y # yum install httpd # chkconfig httpd on # service httpd start Script Procedimentos de instalação e configuração inicial do Apache Já é possível testar o funcionamento do serviço web apontando um navegador para os endereços IPs dos servidores web. O resultado é a página de bem vindo padrão do Apache. Porém, como o Apache foi instalado nos três servidores, deve ser criada uma página específica para identificar cada servidor. Para tanto, é necessário criar um arquivo com o nome index.html dentro do diretório /var/www/html/, cujo conteúdo será WEB 1 para identificar o servidor web1, WEB 2 para identificar o servidor web2 e WEB 3 para o servidor web3. O próximo procedimento é configurar o Apache para gerar informações mais detalhadas que são coletadas e analisadas pela ferramenta Monitorix. Para tanto, edite o arquivo httpd.conf, habilite a diretiva ExtendedStatus On e adicione as configurações mostradas no script 3.8.

59 58 # vi /etc/httpd/conf/httpd.conf ExtendedStatus On <Location /server-status> SetHandler server-status Order allow,deny Allow from all </Location> Script Configuração do Apache para gerar informações mais detalhadas reiniciá-lo. Após efetuar as modificações na configuração do Apache é necessário Instalação e Configuração do Monitorix Monitorix é uma ferramenta livre projetada para monitorar tanto a utilização dos recursos de hardware (CPU, Memória, Rede e Disco.) da máquina, quanto a utilização dos serviços (web e smtp.) ao executar em um sistema operacional Linux. Tais informações são exibidas em gráficos com a sua própria interface web. Foi escrito em linguagem Perl e licenciado sob os termos da General Public License (GNU) conforme publicado pela Free Software Foundation (FSP). Antes da instalação do Monitorix é preciso instalar alguns softwares necessários para sua execução, denominados dependências, conforme mostrado no script 3.9. # yum install rrdtool rrdtool-perl perl-libwww-perl perl- MailTools perl-mime-lite perl-cgi perl-dbi perl-xml-simple perl-config-general wget #wget perl-http-server-simple puias6.noarch.rpm # rpm -ivh perl-http-server-simple puias6.noarch.rpm Script Instalação das dependências do Monitorix

60 59 Depois de instaladas as dependências, o Monitorix pode ser baixado e instalado por meio dos comandos mostrados no script # wget # rpm -ivh monitorix noarch.rpm Script Comandos para download e instalação do Monitorix O próximo passo é configurar o Monitorix para iniciar automaticamente durante a inicialização do sistema. Isso é feito através do comando chkconfig -- level 35 monitorix on, o qual deve ser executado com privilégio de root. Para que o Monitorix processe as informações do funcionamento do Apache, é preciso editar seu arquivo de configuração com o comando vi /etc/monitorix.conf e modificar a linha apache = n, para apache = y. Inicialize o Monitorix por meio do comando service monitorix start Instalação e Configuração do Arptables O arptables se faz necessário devido ao método de implementação LVS Direct Routing utilizado neste trabalho, uma vez que neste método o servidor LVS precisa estar na mesma rede IP dos servidores web e os servidores web devem responder diretamente aos clientes. O problema que surge é que tanto o servidor LVS quanto os servidores web possuem o IP Virtual que é usado pelo cliente para requisitar os serviços. Entretanto, somente o servidor LVS deve responder aos pedidos ARP vindos do cliente (ou roteador da rede no caso do cliente estar fora da rede), pois caso os servidores web também respondam, os pedidos não passam pelo servidor LVS e, portanto, não acontece o balanceamento de carga. Os comandos para instalação e configuração do arptables nos três servidores web são mostrados no script Como pode ser notado, após a instalação do pacote pelo comando yum, aplicou-se uma regra para evitar que os servidores web respondam a pedidos ARP para o IP Virtual, bem como uma regra para trocar o IP de qualquer reposta ou pedido ARP que esteja saindo com o IP Virtual.

61 60 Servidor Web 1 # yum install arptables_jf -y # arptables -A IN -d j DROP # arptables -A OUT -d j mangle --mangle-ip-s # /etc/init.d/arptables_jf save Servidor Web 2 # yum install arptables_jf -y # arptables -A IN -d j DROP #arptables -A OUT -d j mangle --mangle-ip-s # /etc/init.d/arptables_jf save Servidor Web 3 # yum install arptables_jf -y # arptables -A IN -d j DROP # arptables -A OUT -d j mangle --mangle-ip-s # /etc/init.d/arptables_jf save Script Comandos instalação e configuração do arptables 3.2 CONFIGURAÇÕES DOS SERVIDORES LVS Antes de iniciar as configurações, deve-se desabilitar o iptables e o SELinux nos dois servidores LVS, uma vez que na distribuição PUIAS/Springdale, utilizada nestes servidores, o iptables e o SELinux vêm habilitados por padrão. Estes comandos são os mesmos executados para os servidores web (seção 3.1.1), conforme mostrado na figura 3.2. O SELinux é desabilitado editando-se o arquivo /etc/sysconfig/selinux mudando SELinux de permissive para disabled (script 3.2, seção 3.1.1).

62 61 Depois é necessário configurar a interface de rede real (eth0) e a interface de rede virtual (eth0:1) dos dois servidores LVS editando os arquivos /etc/sysconfig/network-scripts/ifcfg-eth0 e /etc/sysconfig/network-scripts/ifcfg-eth0:1 (scripts 3.12 e 3.13). Servidor LVS 1 # vi /etc/sysconfig/network-scripts/ifcfg-eth0 DEVICE=eth0 TYPE=Ethernet ONBOOT=yes BOOTPROTO=static IPADDR= NETMASK= # vi /etc/sysconfig/network-scripts/ifcfg-eth0:1 DEVICE=eth0:1 TYPE=Ethernet ONBOOT=yes BOOTPROTO=static IPADDR= NETMASK= Script Configuração IP nas interfaces do servidor LVS 1 Servidor LVS 2 # vi /etc/sysconfig/network-scripts/ifcfg-eth0 DEVICE=eth0 TYPE=Ethernet ONBOOT=yes BOOTPROTO=static IPADDR= NETMASK= # vi /etc/sysconfig/network-scripts/ifcfg-eth0:1 DEVICE=eth0:1 TYPE=Ethernet ONBOOT=yes BOOTPROTO=static IPADDR= NETMASK= Script Configuração IP nas interfaces do servidor LVS 2 Depois de editado os arquivos, para efetivar as configurações são necessários executar os comandos mostrados no script 3.14 nos dois servidores.

63 62 # ifdown eth0 # ifup eth0 # ifdown eth0:1 # ifup eth0:1 Script Ativação das configurações IP nas interfaces dos servidores LVS Agora em ambos servidores (lvs1 e lvs2) deve-se atualizar a base de dados do gerenciador de pacotes do sistema através do comando yum upgrade -y. Finalizada a atualização é preciso instalar o pacote ipvsadm que gerencia a distribuição das conexões aos servidores; e também instalar o pacote piranha que é a interface de administração, através da qual se configura os servidores que fazem parte do cluster de balanceamento. O script 3.15 resume estes procedimentos. # yum upgrade -y # yum install y ipvsadm piranha Script Instalação dos pacotes ipvsadm e piranha nos servidores LVS Após instalar os pacotes, é necessário editar o arquivo sysctl.conf em ambos os servidores LVS alterando ou acrescentando (caso não existam) as diretivas do script 3.16, as quais são responsáveis por ativar o roteamento (forwarding) de pacotes e ajustar as configurações do protocolo ARP, devido ao problema descrito no início da seção # vi /etc/sysctl.conf... net.ipv4.ip_forward = 1 net.ipv4.conf.eth0.arp_ignore = 1 net.ipv4.conf.all.arp_announce = 2 net.ipv4.conf.eth0.arp_announce = 2... Script Configurações sysctl nos servidores LVS O próximo passo é definir uma senha de acesso para a interface de administração do software de gerenciamento LVS Piranha, bem como iniciar este serviço (script 3.17).

64 63 # piranha-passwd # service piranha-gui start # chkconfig piranha on Script Configuração e inicialização do software piranha Iniciado o serviço, o acesso à interface do Piranha é feito por meio de um navegador, digitando-se o endereço para o servidor LVS1, ou para o servidor LVS2. A figura 3.2 mostra a interface de login do Piranha. Figura Interface de Login do software Piranha Configuração do Cluster de Balanceamento Via Software Piranha Nesta etapa faz-se a construção do cluster de balanceamento, cujos procedimentos são: a) Definir o endereço IP do servidor LVS Primário e do servidor LVS Secundário; b) Adicionar um Servidor Virtual ao cluster LVS; c) Definir a política de balanceamento;

65 64 d) Adicionar e ativar os servidores reais. As próximas seções detalham tais procedimentos Definindo IP para os Servidores LVS Primário e Secundário Este procedimento é realizado através da opção GLOBAL SETTINGS da interface do software piranha (figura 3.3). Como pode ser visto, foi definido o IP para o servidor LVS Primário e também foi definido o tipo de LVS como sendo Direct Routing, clicando-se no botão rotulado como Direct Routing. É importante notar que a mesma configuração deve ser feita no servidor LVS2. Figura Definição do IP primário e tipo de LVS no servidor LVS1 e LVS2 A definição do servidor LVS Secundário (backup) é feita através da opção REDUNDANCY da interface do software Piranha (figura 3.4), bem como as configurações de como o servidor secundário vai monitorar o status de funcionamento do servidor LVS Primário, o que é feito via a ferramenta Heartbeat. Esta ferramenta dispara pings para o servidor LVS primário em intervalos

66 65 determinados para monitorar seu status. A seguir uma breve descrição dos itens que devem ser configurados: Redundant server public IP: endereço IP LVS de backup (lvs2); Heartbeat Interval (seconds): determina os segundos entre heartbeats, o intervalo em que o servidor LVS secundário irá checar o status funcional do servidor LVS primário (lvs1); Assume dead after (seconds): Caso o LVS primário não responda após este número de segundos, o LVS de backup irá assumir o serviço; Heartbeat runs on port: porta na qual o heartbeat se comunica com o LVS primário. Aporta padrão é a 539. Figura Definição do IP Secundário e configurações de monitoramento Adicionar um Servidor Virtual ao Cluster LVS Por meio do botão rotulado ADD da opção VIRTUAL SERVERS adiciona-se um servidor Virtual ao cluster LVS, definindo-se o IP Virtual dos servidores LVS, através do qual os clientes do cluster solicitarão acesso aos serviços dos servidores

67 66 reais, a interface virtual e o algoritmo (política) de escalonamento. A figura 3.5 mostra as configurações disponíveis, as quais são descritas a seguir: Name: Nome do servidor virtual; Application port: Porta da aplicação; Virtual IP Address: Ip virtual; Device: interface virtual; Re-entry Time: Segundos no qual o servidor LVS ativo irá reintegrar um servidor real ao cluster após alguma falha; Service Timeout: intervalo de tempo em que o servidor não responde e será retirado do cluster; Quiesce Server: Habilita a limpeza espontânea das tabelas de roteamento caso um host anteriormente retirado retorna ao status de ativo; Load monitoring tool: Utilizado para monitorar os status dos hosts; Scheduling: É o algoritmo que será empregado para determinar como será executado o balanceamento das conexões entre os servidores reais. Figura Adicionando um servidor virtual ao cluster LVS Para salvar estas configurações deve-se clicar no botão rotulado ACCEPT.

68 Adicionar e Ativar os Servidores Reais Na mesma interface de adição do servidor virtual, clicando-se em REAL SERVER, adicionam-se os servidores reais que responderão ao serviço. Neste trabalho serão três servidores web com IPs: , e Após clicar no botão rotulado ADD da interface REAL SERVER, configura-se o IP do Servidor web, a porta e o peso que será utilizado pelo algoritmo de balanceamento de carga (figura 3.6). Para salvar a configuração deve clicar no botão ACCEPT. Este mesmo procedimento deve ser feito para cada um dos servidores reais do cluster. Figura Adicionando um servidor real ao cluster LVS trabalho. A figura 3.7 ilustra os três servidores reais adicionados e ativados neste Figura 3. 7 Servidores reais adicionados ao cluster LVS

69 Configuração dos Servidores LVS Via Arquivo Nas seções anteriores foi mostrado como se configurar o cluster de servidores LVS via a interface web da ferramenta de gerenciamento Piranha, a qual facilita este procedimento. Todas estas configurações são armazenadas em um arquivo texto localizado em /etc/sysconfig/ha/lvs.cf. É possível sua edição direta sem utilizar a interface web. O script 3.18 mostra estas configurações. serial_no = 164 primary = service = lvs rsh_command = ssh backup_active = 1 backup = heartbeat = 1 heartbeat_port = 539 keepalive = 2 deadtime = 10 network = direct debug_level = NONE monitor_links = 1 virtual server1 { active = 1 address = eth0:1 port = 80 send = "GET / HTTP/1.1\r\n\r\n" expect = "HTTP" load_monitor = uptime scheduler = rr protocol = tcp timeout = 10 reentry = 180 quiesce_server = 0 server websrv1 { address = active = 1 weight = 1 } server websrv2 { address = active = 1 weight = 1 } server websrv3 { address = active = 1 weight = 1 } } Script Arquivo com as configurações do cluster LVS criado pelo Piranha

70 69 É possível, após a configuração do servidor LVS Primário, copiar este arquivo para o servidor LVS Secundário, pois se evita erros de configuração, onde estas devem ser idênticas em ambos os servidores. 3.3 TESTE DE FUNCIONAMENTO DA ESTRUTURA Realizadas as configurações nos servidores LVS e servidores web reais, para testar o funcionamento do balanceamento basta abrir um navegador e inserir o IP virtual A figura 3.8 mostra a resposta a um pedido, o qual foi atendido pelo servidor web 3. Figura Teste de funcionamento da estrutura Com a estrutura do LVS configurada e em funcionamento; o próximo capitulo apresenta alguns testes que abordam e comparam os algoritmos de escalonamento oferecidos por essa estrutura.

71 70 4 ANÁLISE DO FUNCIONAMENTO E DESEMPENHO DO LVS Com o objetivo de demonstrar o funcionamento e desempenho da estrutura LVS proposta, foram realizados testes com os diversos algoritmos de escalonamento disponíveis no LVS. O uso destes algoritmos foi configurado via o software Piranha e informações de comportamento dos servidores web foram coletadas por meio do software Monitorix. Este capítulo mostra a metodologia de testes dos servidores web na estrutura LVS, bem como uma análise das informações coletadas. 4.1 METODOLOGIA DE TESTES O teste consiste em obter resultados em relação ao comportamento da estrutura LVS aplicando-se cada um dos oito algoritmos de escalonamento disponíveis pela ferramenta Piranha, que são: Round-Robin, Weighted Round- Robin, Least-Connection, Weighted Least-Connections, Locality-Based Least- Connection, Locality-Based Least-Connection Scheduling with Replication, Destination Hash e Source Hash. Cada teste com cada algoritmo teve uma duração de 24 horas, onde se pode ter uma ideia do real funcionamento da estrutura com cada algoritmo de escalonamento selecionado. Para automatizar as requisições de páginas para os servidores web, foi utilizado um script escrito em linguagem PHP (script 4.1) onde se executa em uma máquina com a distribuição Linux Puias Linux. <?php $WEB1=0; $WEB2=0; $WEB3=0; for($i=0;$i< ;$i++){ $f=fopen(' $data=''; while(!feof($f)) $data.=fread($f,5); fclose($f); $data = str_replace("\r\n",'',trim($data)); print " $data \n"; if (strpos($data,'web 1')!==false) $WEB1++; else if (strpos($data,'web 2')!==false) $WEB2++; else if (strpos($data,'web 3')!==false) $WEB3++; else print("\n Conteudo nao encontrado"); } print "\nweb 1: $WEB1 \nweb 2: $WEB2 \nweb 3: $WEB3\n";?> Script Script de requisição de página

72 71 Além da confecção do script, alguns preparativos são necessários para executar o script nesta distribuição, tais como: desabilitar o iptables e o selinux; configurar a interface de rede; instalar o pacote da linguagem PHP. O script 4.2 mostra os comandos relacionados com estes procedimentos. # service iptables save # service iptables stop # chkconfig iptables off # vi /etc/sysconfig/selinux... SELINUX=disabled... # vi /etc/sysconfig/network-scripts/ifcfg-eth0 DEVICE=eth0 TYPE=Ethernet ONBOOT=yes BOOTPROTO=static IPADDR= NETMASK= # ifdown eth0 # ifup eth0 # yum upgrade -y # yum install php Script Configurações na máquina de requisição de páginas Devido à forma de coleta de dados da ferramenta Monitorix, a qual fornece gráficos dos dados coletados durante o tempo de 24 horas, mensal e anual, foi disparado um total de requisições de página para atingir um tempo 24 horas de teste. 4.2 TESTES COM O ALGORITMO ROUND-ROBIN (RR) Este algoritmo distribui as requisições igualmente entre os servidores reais. Sua configuração no LVS é através da interface gráfica do Piranha, que é mostrada na figura 4.1.

73 72 Figura Configurações do algoritmo Round-Robin no LVS Após o termino das requisições o servidor WEB1 respondeu por vezes, o servidor WEB2 respondeu por vezes e o servidor WEB3 respondeu por vezes (figura 4.2), mostra-se assim que o algoritmo cumpriu o proposto no balanceamento igualitário de carga entre os servidores web e sendo recomendado seu uso quando os servidores web possuem os mesmos recursos de hardware. Figura Totalização das requisições recebidas - Algoritmo RR

74 73 Para comprovar a real distribuição de carga entre os servidores web, foram coletadas informações de uso de recursos de CPU, memória e rede destes servidores, via ferramenta Monitorix. O gráfico da figura 4.3 mostra a média de requisições por segundo recebidas pelo Apache no servidor WEB1 durante o teste com o algoritmo round-robin, o qual foi de 115 acessos por segundo. Valor idêntico foi obtido nos demais servidores WEB2 e WEB3. Figura Média de requisições recebidas pelo Apache no servidor WEB1 Fonte: Elaborado pelos Autores, 2014 Ainda ao considerar as requisições, a figura 4.4 ilustra o gráfico de tráfego de entrada e saída na interface eth0 do servidor WEB1, com média de entrada de 52 kbytes por segundo e de saída de 80 kbytes por segundo. O mesmo tráfego foi medido na interface de rede dos outros dois servidores WEB2 e WEB3. Figura Média de tráfego de entrada/saída de rede no servidor WEB1

75 74 Para atender todas as requisições recebidas durante o teste, o Apache utilizou em média cerca de 2.5% de CPU da máquina, conforme mostrado na figura 4.5. O mesmo consumo ocorreu também nos outros dois servidores WEB2 e WEB3. Figura Média de consumo de CPU no servidor WEB1 Ainda ao considerar o uso de recursos da máquina durante os testes, o servidor WEB1 registrou uma média de uso de 478 Megabytes de memória física, 400 Megabytes de cache (memória de acesso rápido), e oscilou entre 50 e 30 Megabytes em buffers (memória temporária), conforme figura 4.6. Consumo similar de memória foi registrado nos demais servidores. Figura Média de consumo de memória no servidor WEB1 4.3 TESTES COM O ALGORITMO WEIGHTED ROUND ROBIN (WRR) Este algoritmo atribui requisições aos servidores reais equivalentes ao peso. Servidores com um valor maior de peso recebem novas requisições primeiramente e respondem a mais requisições do que os servidores com um valor menor de peso. A figura 4.7 mostra a configuração do LVS para utilizar o algoritmo Weighted Round

76 75 Robin, onde foi adicionado peso 5 ao servidor WEB1 e peso 1 aos outros dois servidores. Figura Configurações do algoritmo Weighted Round Robin no LVS Após o termino das requisições o servidor WEB1 respondeu por vezes, o servidor WEB2 respondeu por vezes e o servidor WEB3 respondeu por vezes (figura 4.8), mostrando que o algoritmo distribuiu uma carga de requisições maior para o servidor WEB1 de maior peso, em detrimento dos demais servidores que ficaram ambos com uma carga menor, é recomendado seu uso quando os servidores web possuem recursos de hardware diferentes. Figura Totalização das requisições recebidas - Algoritmo WRR

77 76 Para comprovar a real distribuição de carga entre os servidores web, foram coletadas informações de uso de recursos de CPU, memória e rede destes servidores, via ferramenta Monitorix. O gráfico da figura 4.9 mostra a média de requisições por segundo recebidas pelo Apache no servidor WEB1 durante o teste com o algoritmo Weighted Round Robin, o qual foi de 250 acessos por segundo, o qual foi 5 vezes maior que o valor obtido nos demais servidores WEB2 e WEB3. Figura Requisições - Apache no WEB1 - algoritmo WRR Ainda ao considerar as requisições, a figura 4.10 ilustra o gráfico de tráfego de entrada (110 kbytes por segundo) e saída (170 Kbytes por segundo) na interface eth0 do servidor WEB1, tráfego este que foi cerca de 5 vezes maior que o medido na interface de rede dos outros dois servidores WEB2 e WEB3. Figura Tráfego de entrada/saída de rede no WEB1 - algoritmo WRR.

78 77 Para atender todas as requisições recebidas durante o teste, o Apache apresentou picos de 20% de utilização de CPU da máquina, conforme mostrado na figura Nos outros servidores, o consumo foi de 4% no servidor WEB2 e 6% no servidor WEB3. Figura Média de consumo de CPU no - WEB1 - algoritmo WRR Ainda ao considerar o uso de recursos da máquina durante os testes, o servidor WEB1 registrou uma média de uso de 480 Megabytes de memória física, 410 Megabytes de cache (memória de acesso rápido), e oscilou entre 30 e 10 Megabytes em buffers (memória temporária), conforme figura Consumo similar de memória foi registrado nos demais servidores. Figura Média de consumo de memória no WEB1 - algoritmo WRR

79 RESULTADOS DOS TESTES COM DEMAIS ALGORITMOS Os mesmos procedimentos dos testes anteriores foram realizados com os demais algoritmos disponíveis no LVS via interface do software Piranha. Os resultados obtidos são mostrados no Quadro 4.1. Quadro Resultados de testes com algoritmos de escalonamento Embora os resultados obtidos nos testes com os algoritmos LBLC, LBLCR, DH e SH possam parecer estranhos, principalmente no que tange as informações na coluna Requisições Respondidas, estes retratam a realidade do funcionamento de cada algoritmo, conforme descrito a seguir: