BALANCEAMENTO DE CARGA EM WEB SERVICES. Sabrina da Silva Leandro

Transcrição

1 UNIVERSIDADE FEDERAL DE SANTA CATARINA DEPARTAMENTO DE INFORMÁTICA E ESTATÍSTICA CURSO DE BACHARELADO EM SISTEMAS DE INFORMAÇÃO BALANCEAMENTO DE CARGA EM WEB SERVICES Sabrina da Silva Leandro Trabalho de conclusão de curso submetido à Universidade Federal de Santa Catarina como parte dos requisitos para obtenção do grau de Bacharel em Sistemas de Informação. Florianópolis - SC 2005/1

2 2 Sabrina da Silva Leandro BALANCEAMENTO DE CARGA EM WEB SERVICES Trabalho de conclusão de curso submetido à Universidade Federal de Santa Catarina como parte dos requisitos para obtenção do grau de Bacharel em Sistemas de Informação. Orientador: Prof. Frank Augusto Siqueira, Dr. Universidade Federal de Santa Catarina Banca examinadora Prof. João Bosco Mangueira Sobral, Dr. Universidade Federal de Santa Catarina Prof. Mario Dantas, Dr. Universidade Federal de Santa Catarina

3 3 AGRADECIMENTOS Gostaria de agradecer a todos que me auxiliaram, direta ou indiretamente, na conclusão deste trabalho. Agradeço aos meus pais pelo apoio e principalmente pelo exemplo, pois além de excelentes profissionais, que me ajudaram com minhas dúvidas de trabalhos acadêmicos, são pessoas maravilhosas das quais me orgulho muito. Agradeço também a força e o ombro do meu amor e melhor amigo João, que me tranqüilizou e acalmou meus anseios. Obrigada ao meu orientador, pela ótima idéia oferecida a mim, que me propiciou muitos aprendizados e novos conhecimentos. Obrigada também por ser meu guia neste trabalho final. Finalmente, não poderia deixar de agradecer aos meus colegas da faculdade e do trabalho. Em especial, Marcus Grando, Gian Carlo Salvati e Fernando Barreto, pela luz que me deram quando me vi perdida em uma área na qual não tinha muita experiência. A todos, um sincero obrigada!

4 4 RESUMO LEANDRO, Sabrina da Silva. Balanceamento de Carga em Web Services Trabalho de Conclusão de Curso (Bacharelado em Sistemas de Informação). Curso de Sistemas de Informação, Universidade Federal de Santa Catarina, Florianópolis. Empresas e instituições sentem cada vez mais a necessidade de interligar processos de negócio e trocar informações com fornecedores, clientes e parceiros. A arquitetura Web Services surge para facilitar a interligação entre as aplicações que implementam esses processos de negócio. Ela permite a conexão de sistemas heterogêneos, pois apresenta características como fraco acoplamento, independência de plataforma e uso de padrões abertos. Entretanto, essa arquitetura ainda possui padronizações a serem definidas, especialmente em questões como disponibilidade, desempenho e qualidade de serviço. Por possuir problemas de desempenho comprovados, é essencial que estas questões sejam tratadas. Este trabalho tem como objetivo propor um mecanismo para balanceamento de carga entre diferentes servidores que disponibilizam um mesmo serviço Web, visando a melhoraria do seu desempenho. O mecanismo proposto usa uma abordagem de balanceamento de carga baseada em despachante. Esse despachante encaminha as mensagens a uma das réplicas de um serviço, usando um protocolo de endereçamento para serviços Web. O mecanismo proposto foi implementado, assim como três algoritmos de balanceamento de carga (Randômico, Round-robin e Menor Carga), que podem ser usados de acordo com as características do serviço e dos servidores que o implementam. Palavras-chave: serviços Web, balanceamento de carga, desempenho.

5 5 ABSTRACT LEANDRO, Sabrina da Silva. Web Services Load Balancing Final Dissertation. Information Systems Graduation Course, Universidade Federal de Santa Catarina, Florianópolis. Companies and institutions feel the need to interconnect business processes, in order to exchange information with suppliers, clients and partners. The Web Services Architecture is a way to facilitate the interconnection between the applications that implement these business processes. It enables the communication between heterogeneous systems because it provides loose coupling, platform independence and the use of open standards. However, this architecture still has standards to be defined, specially concerning availability, performance and quality of service. Since it possesses proven performance problems, it is essential to address these issues. In this dissertation, a mechanism to balance load between different servers that provide the same Web service is proposed, so that the performance of the Web service is improved. The proposed mechanism uses a dispatcher as the load balancing entity. This dispatcher forwards messages to the selected replica of a service using a Web services addressing protocol. The proposed mechanism was implemented as well as three load balancing algorithms (Random, Round-robin, Least Load), that can be chosen based on the characteristics of the service and the servers in which it is deployed. Keywords: Web services, load balancing, performance.

6 6 SUMÁRIO Lista de Figuras 8 Lista de Abreviaturas e Siglas 9 1 Introdução Descrição do Problema Objetivos Justificativa Organização do Texto 14 2 Revisão Bibliográfica Sistemas Distribuídos Sistemas de Clusters de Servidores Web Balanceamento de Carga Abordagem baseada no cliente Abordagem baseada no servidor DNS Abordagem baseada em despachante Abordagem baseada no servidor Web Services Arquitetura Orientada a Serviços SOA Histórico Arquitetura Web Services SOAP WSDL UDDI Web Services Addressing Histórico Detalhes da Especificação WS-Addressing e SOAP WS-Addressing e WSDL Plataformas de Desenvolvimento para Web Services Desempenho de Web Services Considerações Finais 61 3 Balanceamento de Carga em Web Services Algoritmos de Balanceamento de Carga 66 4 Implementação Cliente Despachante WS-LoadBalancer Servidor 75 5 Testes e Resultados Ambiente de Testes Testes Resultados 78

7 7 6 Conclusões e Trabalhos Futuros Conclusões Trabalhos Futuros 80 Referências Bibliográficas 82 Apêndices 86 Apêndice A Código Fonte 86 Apêndice B Artigo 102

8 8 LISTA DE FIGURAS Figura 1 Arquitetura SOA e protocolos Web Services...35 Figura 2 Exemplo de mensagem SOAP enviada por HTTP...40 Figura 3 Exemplo de arquivo WSDL, a interface abstrata e os detalhes de protocolo...42 Figura 4 Exemplo de estrutura UDDI simplificada...45 Figura 5 Exemplo de endpoint reference com um parâmetro de referência...53 Figura 6 Exemplo de endpoint reference em uma mensagem SOAP Figura 7 Mensagem SOAP utilizando WS-Addressing...55 Figura 8 Atributo WS-Addressing em um documento WSDL Figura 9 Três clientes acessando um serviço implementado em duas réplicas, usando WS-LoadBalancer.69 Figura 10 Diagrama de classes do despachante WS-LoadBalancer Figura 11 Exemplo de arquivo de configuração do despachante WS-LoadBalancer...73 Figura 12 Diagrama de Seqüência de chamada de serviço através do despachante WS-LoadBalancer...75 Figura 13 Gráfico tempo de resposta médio dos algoritmos de balanceamento de carga no WS- LoadBalancer....79

9 9 LISTA DE ABREVIATURAS E SIGLAS API Application Program Interface: conjunto de rotinas, protocolos e ferramentas para construção de aplicações. COM Component Object Model: arquitetura de software desenvolvida pela Microsoft para criação de aplicações baseada em componentes. CORBA Common Object Request Broker Architecture: arquitetura do Object Management Group que permite a comunicação entre objetos em diferentes plataformas. DCE Distributed Computing Environment: ambiente desenvolvido pelo The Open Group para criação de aplicações distribuídas que rodam em diferentes plataformas. DCOM Distributed Component Object Model: protocolo de objetos remotos, da Microsoft. EPR Endpoint Reference: referência dinâmica a um ponto de acesso de um serviço que pode receber mensagens SOAP. HTML HyperText Markup Language: linguagem usada para criar documentos na Web. HTTP HyperText Transfer Protocol: protocolo que define como mensagens são formatadas e transmitidas e quais ações servidores Web e navegadores devem tomar em resposta a vários comandos. IP Internet Protocol: protocolo Internet para troca de pacotes. Java RMI Java Remote Method Invocation: conjunto de protocolos desenvolvidos pela Sun que permitem a comunicação remota entre objetos Java. JSP Java Server Pages: extensão da tecnologia servlets da Sun. MEP Message Exchange Pattern: Padrão de Troca de Mensagens. RPC Remote Procedure Call: Chamada Remota de Procedimento. SMTP Simple Mail Transfer Protocol: protocolo para envio de s entre servidores. SNMP Simple Network Management Protocol: conjunto de protocolos para gerência de redes. SOA Service-oriented Architecture: Arquitetura Orientada a Serviços. SOAP: protocolo de transporte de mensagens entre serviços Web. TCP Transmission Control Protocol: protocolo que faz conexão entre hosts para que estes troquem dados. UDDI Universal Description, Discovery and Integration: Integração, Descobrimento e Descrição Universal. Especificação de descobrimento para serviços Web. URI Uniform Resource Identifier: Identificador Uniforme de Recursos, termo genérico para todos os tipos de nomes e endereços que se referem a objetos na Web.

10 10 URL Uniform Resource Locator: Localizador Uniforme de Recursos, endereço global de documentos e outros recursos na Web. W3C World Wide Web Consortium: organização internacional cujo objetivo é desenvolver padrões abertos para a Web. WS Web Services: Serviços Web. WS-Addressing Web Services Addressing: Endereçamento de Serviços Web. WSDL Web Services Description Language: Linguagem de Descrição de Serviços Web. XML Extensible Markup Language: linguagem de tags de marcação baseada em texto. XML Infoset: conjunto de dados definidos pelo W3C para uso nas suas especificações. XML Schema Esquema XML: modelo para descrever a estrutura dos dados XML.

11 11 1 INTRODUÇÃO A Internet surge nos EUA, na década de setenta, inicialmente com objetivo de conectar governos, acadêmicos e pesquisadores [1]. Com o passar do tempo, ela evoluiu para o uso de e sites institucionais, que serviam somente como uma forma de marketing. Atualmente, além da consolidação do comércio eletrônico, está acontecendo uma nova revolução do uso da Internet, que resolve um dos grandes problemas enfrentados pelos desenvolvedores: a integração de sistemas heterogêneos. Ou seja, o uso da Internet está minimizando a complexidade, e conseqüentemente os custos, de se integrar sistemas diferentes. As empresas sentem cada vez mais a necessidade de interligar seus processos de negócio, bem como trocar informações com fornecedores, clientes e parceiros através de processos de negócio externos. Essa cooperação necessita que a conexão entre sistemas de diferentes fabricantes, que implementam esses processos, seja fácil, para que as empresas possam responder de forma rápida e eficiente às exigências de clientes, mudanças de mercados ou ameaças da concorrência. A arquitetura Web Services está possibilitando essa conexão entre sistemas heterogêneos. Por dois motivos, em primeiro lugar porque ela oferece interoperabilidade e fraco acoplamento, por ser independente de plataformas ou sistemas operacionais. Em segundo lugar, essa arquitetura é baseada em padrões abertos e, por isso, todos os envolvidos projetam seus sistemas utilizando os mesmos padrões. Essas duas características possibilitam a fácil integração de sistemas. Mas para que o uso comercial dessa tecnologia se torne corrente, é importante que se tenha uma infra-estrutura confiável para seu desenvolvimento e implantação. Nos últimos anos, um grande número de especificações foi criado por empresas e organizações, mas sem a preocupação de determinar como seria o relacionamento entre essas especificações, e de como elas, juntas, formariam a Arquitetura Web Services [2]. Por ser uma tecnologia nova, questões de desempenho e disponibilidade ainda não foram solucionadas de forma satisfatória, de maneira que permita que esta arquitetura seja usada em todo seu potencial. Este trabalho tem como objetivo propor um mecanismo para balanceamento de carga entre réplicas de serviços Web. A distribuição das requisições baseada em algoritmos

12 12 de balanceamento de carga permite melhorar o desempenho, aumentar a disponibilidade, diminuir o tempo de resposta e possibilita prover tolerância a faltas. Entende-se que a melhoria dessas características, trazida pela solução proposta, deverá permitir que esta nova e interessante arquitetura possa ser mais amplamente difundida e que cada vez mais novos serviços Web sejam implantados. 1.1 DESCRIÇÃO DO PROBLEMA O uso da Internet está cada vez mais difundido. A evolução dos sistemas disponíveis através da Internet é constante; a gama de serviços acessados via Web está cada vez mais abrangente; surgem novos componentes de hardware, como celulares e palmtops, para acessar a grande quantidade de informações existentes na Web. Portanto é imprescindível também que surjam meios mais seguros e confiáveis de tornar essas informações disponíveis para todos esses novos usuários. As estruturas de tecnologia de informação devem estar suficientemente maduras para lidar com o aumento do acesso e o alto tráfego de informações. Os Web Services se enquadram entre os novos meios criados para o acesso a informações e a solicitação de serviços implementados remotamente. A arquitetura orientada a serviços, utilizando serviços Web, está sendo muito discutida tanto no meio acadêmico quanto nas empresas. Ela é considerada uma solução ideal para integração e comunicação entre aplicações e processos. Mas a arquitetura Web Services ainda é uma tecnologia nova, com padronizações a serem definidas, especialmente no que se refere a questões de disponibilidade, desempenho, segurança e qualidade de serviço. Enquanto essas questões não forem tratadas e resolvidas, essa nova tecnologia não poderá ser utilizada em todo seu potencial [3] [4]. 1.2 OBJETIVOS Este trabalho de conclusão de curso tem como objetivo principal estudar maneiras de distribuir a carga, ou seja, as requisições recebidas através de uma rede de computadores, entre Web services replicados em diferentes máquinas. Pretende-se, ao

13 13 final, propor uma heurística para balanceamento de carga entre réplicas de serviços Web em um conjunto de servidores de aplicação. Para tanto, os seguintes objetivos específicos foram determinados: Estudar as características da arquitetura Web Services e dos seus suportes de execução, os servidores de aplicação; Estudar as especificações na área de roteamento e endereçamento de serviços Web; Estudar técnicas clássicas para balanceamento de carga, com o intuito de verificar sua aplicabilidade para balanceamento de carga entre Web services; Depois de determinar qual técnica de balanceamento de carga é melhor para os objetivos do trabalho, desenvolver e implementar uma solução de balanceamento de carga para serviços Web; Implementar diferentes algoritmos de balanceamento de carga e realizar testes de comparação, com o objetivo de verificar qual algoritmo é mais apropriado para o balanceamento de mensagens destinadas a serviços Web. 1.3 JUSTIFICATIVA A tecnologia de Serviços Web ainda não está completamente madura, e diversas pesquisas ainda estão sendo realizadas nessa área. Atualmente, especificações para diversas funcionalidades consideradas importantes em um ambiente distribuído, como segurança e mensagens confiáveis, estão sendo desenvolvidas por órgãos como o World Wide Web Consortium (W3C) [5]. Apesar de suas limitações, diversas empresas e instituições têm apostado nesta tecnologia como o futuro padrão de mercado para interconexão de aplicações. Os Web services são serviços fim a fim disponíveis em um sistema distribuído e para que possam ser utilizados em larga escala devem possuir características específicas de desempenho. Para os Serviços Web serem uma realidade, eles devem possuir alta disponibilidade e confiabilidade para servir aos milhares de usuários potenciais. Em Tian et al [6], foi comparado o comportamento de servidores Web, durante sobrecarga, para interações Web tradicionais (conteúdo dinâmico) e para serviços Web. Foi concluído que os serviços Web impõem uma sobrecarga adicional no servidor, porque

14 14 necessitam realizar a análise dos dados XML. Além disso, o tamanho dos dados transferidos aumenta. Os experimentos mostraram que a sobrecarga causada pelos serviços Web não pode ser negligenciada, pois pode reduzir a vazão do servidor e aumentar consideravelmente o tempo de resposta durante uma demanda alta. O balanceamento de carga existe porque, na maioria das vezes, a transmissão de dados em rede é mais rápida do que o processamento desses dados por uma aplicação. Atualmente, há um aumento no número de usuários e de acessos a aplicações Web e um aumento do número de aplicações que se deseja tornar disponíveis online. Considerando que, além disso, nos serviços Web há uma maior complexidade de processamento, devido à análise das mensagens, verifica-se a importância que é tratar do desempenho de serviços Web. O desempenho de aplicações Web é normalmente medido pela rapidez com que a aplicação responde a requisições URL. Entretanto, para uma avaliação mais completa deveria ser incluído também o efeito de requisições simultâneas, a latência das respostas, a escalabilidade, ou seja, poder lidar com o crescimento da demanda, e os níveis de degradação operacional devido ao aumento da carga das requisições. Existem muitos desafios no desenvolvimento de sistemas distribuídos utilizando a tecnologia Web Services. A arquitetura Web Services precisa evoluir para que atenda todos os requisitos necessários para sistemas distribuídos. Este trabalho vem contribuir para esta evolução, inserindo-se em uma discussão importante para uma tecnologia recente. A autora tem certeza de que para que essa tecnologia progrida e resista ao longo do tempo, precisam ser apresentadas soluções para o seu problema de desempenho [4] [7] [8]. Pois, mesmo com as interessantes características positivas dos Serviços Web, o mercado de tecnologia da informação só investe e implanta tecnologias comprovadamente eficientes. 1.4 ORGANIZAÇÃO DO TEXTO O primeiro capítulo introduziu o assunto a ser abordado neste trabalho. Uma descrição do problema pesquisado foi feita, assim como, a justificativa para a sua resolução. Os objetivos do trabalho foram traçados.

15 15 O capítulo dois trata da revisão bibliográfica dos assuntos abordados neste trabalho. Em primeiro lugar, apresenta-se uma revisão bibliográfica dos principais conceitos de sistemas distribuídos e balanceamento de carga. Em segundo lugar, são introduzidos os conceitos e as principais especificações da arquitetura Web Services, especialmente a especificação WS-Addressing. Por último, mostra-se um resumo dos problemas de desempenho relacionados a essa arquitetura. No capítulo três, descreve-se a metodologia utilizada para solucionar o problema apresentado neste trabalho. A solução proposta para o balanceamento de carga em Serviços Web é mostrada, explicando-se as decisões tomadas. No capítulo 4, apresentam-se detalhes da implementação da solução proposta. As ferramentas utilizadas e as decisões de implementação são descritas. Foram realizados testes para comparação do tempo de resposta utilizando a solução apresentada com os algoritmos de balanceamento de carga implementados. Esses testes e seus resultados são apresentados no capítulo 5. Finalmente, as conclusões e resultados deste trabalho são apontados no capítulo 6. Neste capítulo também são apresentadas sugestões para trabalhos futuros.

16 16 2 REVISÃO BIBLIOGRÁFICA 2.1 SISTEMAS DISTRIBUÍDOS De acordo com Veríssimo et al [9], um sistema distribuído é um sistema composto de vários computadores os quais se comunicam através de uma rede, hospedando processos que usam um conjunto comum de protocolos distribuídos para auxiliar à correta execução de atividades. Segundo o W3C [10], um sistema distribuído é um conjunto de agentes de software que estão em ambientes de processamento diferentes e devem cooperar para realizar alguma tarefa. Para isso, eles precisam se comunicar usando pilhas de protocolos de hardware ou software através de uma rede. A Internet é uma rede de computadores, e não um sistema distribuído em si. Isso porque uma das características principais nesse tipo de sistema é o compartilhamento de estado que há entre processos que cooperam para atingir um determinado objetivo. Entretanto, os dois conceitos se relacionam, pois muitos sistemas distribuídos se utilizam da Internet e das tecnologias relacionadas a ela como meio de realizar essa cooperação. Por ser feita através de uma rede, a comunicação em um sistema distribuído é intrinsecamente menos rápida e menos confiável que aquela usando invocação direta de código e memória compartilhada. Isso acarreta implicações importantes na arquitetura desses sistemas, requerendo características como bom desempenho e a consideração de problemas como latências imprevisíveis, concorrência e a possibilidade de falhas. Entre os requisitos que um sistema distribuído deve apresentar para prover uma funcionalidade completa está o desempenho. O desempenho é medido em termos de vazão e latência. Alta vazão e baixa latência representam um serviço com bom desempenho. A vazão (throughput) é a taxa na qual o trabalho computacional é feito [11]. Ou seja, ela representa o número de requisições servidas durante um período de tempo. Essa medida é afetada pelas velocidades de processamento nos clientes e no servidor e pelas taxas de transmissão de dados entre eles. Latência, ou tempo de resposta, é o tempo entre o envio de uma requisição e o recebimento da resposta. A questão do desempenho em um sistema distribuído é essencial devido às limitadas capacidades de processamento e comunicação entre computadores e redes.

17 17 Usuários de aplicações interativas esperam um tempo de resposta pequeno e constante. Essas exigências são difíceis de atingir quando serviços remotos são utilizados, já que o tempo em que a resposta é retornada depende não só dos processos no sistema servidor, mas também da carga da rede empregada para comunicação. O balanceamento de carga computacional é um mecanismo importante usado para atingir escalabilidade e melhorar o desempenho em um sistema distribuído, que será discutido a seguir Sistemas de Clusters de Servidores Web O crescimento contínuo da Web tem causado um aumento nos problemas de desempenho no acesso ao seu conteúdo, como altos tempos de resposta, congestionamento na rede e negação e indisponibilidade de serviços. Além disso, atualmente, a maioria dos conteúdos acessados na Web são dinâmicos. Esse tipo de conteúdo aumenta a demanda nos servidores, principalmente para operações de entrada e saída e de CPU. Isso faz com que o servidor, e não mais a rede e a sua largura de banda, se torne o gargalo mais crítico no acesso a sites Web. Para solucionar esse problema, adquirir uma máquina mais poderosa para o servidor Web nem sempre é ideal, tanto pela pouca escalabilidade 1 quanto pelo alto custo. Uma solução mais interessante para dar suporte a esse aumento de demanda seria utilizarse de um agregado, ou cluster, de processadores que trabalham conjuntamente, servindo como um único servidor Web. Um Sistema de Servidores Web Distribuído pode ser visto como qualquer arquitetura que consista de vários servidores que utilizam o mesmo mecanismo para espalhar as requisições dos clientes entre esses servidores [12]. Os nós podem ser localmente ou geograficamente distribuídos. É assumido que qualquer servidor no sistema pode responder a qualquer requisição. A arquitetura em cluster pode ser considerada um Sistema de Servidores Web Distribuído localmente. Nela, um conjunto de servidores Web distribuídos localmente se mostra para o exterior como uma entidade única, na qual chegam todas as requisições dos clientes. Essa arquitetura também pode ser chamada de Sistema Paralelo. Essa solução possibilita que múltiplas máquinas trabalhem como um único servidor, tornando o sistema 1 Por escalabilidade entende-se a habilidade do sistema de suportar o crescimento no número de usuários.

18 18 mais poderoso, pois os recursos de todos computadores que formam o cluster são compartilhados para atender às requisições dos clientes. Entre as vantagens existentes na utilização de um cluster de servidores Web encontram-se: Aumento de desempenho, pois há aumento na capacidade de receber solicitações; Melhor confiabilidade 1 e disponibilidade 2, pois o servidor pode continuar operando mesmo se uma das máquinas no cluster falhar. A disponibilidade é provida através de redundância de servidores. Quando um desses servidores falhar, esta falha será mascarada, pois as requisições poderão ser enviadas a outros servidores ativos, provendo maior confiabilidade; Tolerância a faltas 3, bem como a possibilidade de adicionar e retirar servidores do cluster sem tornar as aplicações hospedadas no servidor indisponíveis; Escalabilidade facilitada, pois é simples aumentar a capacidade de um cluster pela adição de novos servidores; Interface externa é única para todos computadores do cluster; assim, alterações na configuração do cluster não afetam as aplicações clientes. É importante que o ambiente de comunicação em um cluster seja bem implementado para que os nós possam se comunicar uns com os outros e verificar com maior precisão caso ocorra falha em um deles. O conteúdo servido por um cluster pode ser replicado em cada máquina, compartilhado usando um sistema de arquivos em rede ou acessado em um sistema de arquivos distribuído. Em um sistema Web não se pode prever quando haverá um aumento tal no número de clientes que tornará difícil o processamento das requisições. Com isso, podem ocorrer falhas de sistema causadas por sobrecargas de requisições, que tornam os serviços indisponíveis. Por essa razão, para utilização de servidores em cluster, fazem-se necessários mecanismos de distribuição e balanceamento de carga entre os computadores que 1 Confiabilidade representa o grau de capacidade de manter o serviço e a qualidade desse serviço. O número de falhas por mês ou ano representa uma medida de confiabilidade. Outro conceito diz que confiabilidade refere -se à entrega garantida e em ordem de mensagens entre consumidores e provedores de serviços. [6] 2 Disponibilidade é a medida de temp o em que um sistema está ativo e funcionando [8]. 3 Tolerância a faltas é a habilidade de um sistema de continuar a operar de modo válido apesar da ocorrência de uma ou mais faltas no sistema ou em parte dele [8].

19 19 desempenham o papel de servidor para aplicações Web. Como vários servidores podem processar os pedidos, deve-se determinar como alocar eficientemente as requisições nos servidores disponíveis. Dessa maneira, cada requisição destinada ao host será distribuída, baseada em algoritmos de balanceamento de carga, para um dos servidores do cluster. Essa distribuição pode ser feita tanto por um software quanto por um dispositivo de hardware feito especialmente para este fim. Também é necessário o gerenciamento de estado, pois como é possível que vários servidores manipulem a mesma sessão de um usuário, deve-se determinar como manter o estado, ou contexto de sessão, entre os servidores e os clientes. 2.2 BALANCEAMENTO DE CARGA Existem várias abordagens que distribuem as requisições de clientes entre diferentes servidores para melhorar o desempenho de uma aplicação ou site Web. Neste trabalho, será dada atenção às soluções que distribuem requisições em um conjunto de servidores Web. Para o uso da distribuição balanceada de requisições em um sistema de servidores Web, deve haver uma política que distribua a carga recebida de maneira uniforme para todos esses servidores, não sobrecarregando um deles enquanto outro está disponível. Balanceamento de carga (load balancing) é um mecanismo usado para atingir escalabilidade através da redistribuição de carga entre os elementos de processamento em um conjunto de servidores. Entre os objetivos do uso de balanceamento de carga estão o aumento da vazão do sistema e a diminuição do tempo de resposta às requisições de clientes, pela diminuição do tempo de execução da aplicação, o que torna o seu uso crítico ao se manter um cluster de servidores de alto desempenho. As requisições precisam ser distribuídas entre os nós de modo a reduzir o tempo de resposta e prover aos usuários a melhor qualidade de serviço disponível. A distribuição de carga das requisições dos clientes para o servidor apropriado pode ser realizada de várias maneiras. Um exemplo simples é o de sites que espalham seus conteúdos em diferentes servidores, permitindo que o usuário selecione, de uma lista de sites replicados e independentes, o servidor que melhor lhe convém. Porém essa solução não é eficiente, já que depende de uma escolha feita pelo usuário final para melhorar o

20 20 desempenho do site. O interessante é que essa tarefa seja realizada de modo transparente e automatizado. No balanceamento de carga realizado em um sistema servidor Web baseado em cluster existem dois integrantes essenciais: a entidade que realiza a tarefa de balanceamento de carga e o algoritmo usado para decisão de como serão distribuídas as requisições entre os servidores que fazem parte do cluster. Segundo Cardellini et al [12], com relação às entidades que realizam o balanceamento de carga, podem existir quatro abordagens: baseada no cliente, no servidor DNS, em um despachante (dispatcher) e no servidor. A seguir, serão descritas abordagens automatizadas para o balanceamento de carga, segundo esta categorização Abordagem baseada no cliente Esta abordagem pode ser aplicada mesmo em um conjunto de servidores que não estão coordenados entre si. Isso porque a modificação necessária para realizar a distribuição de carga é feita no cliente. Por cliente entende-se um programa, geralmente um navegador, que estabelece conexões com um servidor para responder às requisições do usuário. A implementação da abordagem é feita pela alteração do cliente, seja ele um navegador ou mesmo um servidor proxy, fazendo com que este conheça os diferentes servidores existentes no sistema de servidores Web. Assim, quando ele recebe a requisição do usuário, seleciona um dos nós do cluster e envia esta requisição ao servidor escolhido, que responderá a este cliente. Na próxima requisição do usuário, um servidor diferente pode ser selecionado. Essa é uma solução muito simples e transparente para o usuário final, mas exige o uso de extensões no cliente, com alterações no código do navegador ou pelo uso de applets Java [13], migrando funcionalidades do servidor para a máquina do usuário ou servidor proxy. Apesar dessa abordagem solucionar o problema do balanceamento de carga entre servidores, a necessidade de modificações no cliente a torna quase sempre inviável, visto que os clientes e servidores Web geralmente não são controlados pela mesma instituição ou empresa. Consegue-se maior transparência para os clientes com o uso de abordagens de balanceamento baseadas nas entidades servidoras, como servidores DNS, despachantes ou mesmo os próprios servidores Web.

21 Abordagem baseada no servidor DNS Nesta abordagem, a responsabilidade de distribuir requisições é dada ao servidor Domain Name Service (DNS), serviço de nomes de domínio. Esse servidor tem autoridade para responder ao mapeamento do endereço URL do cluster em um ou mais endereços IP. Assim, ele permite que um mesmo domínio possa ser mapeado para os diferentes endereços IP das máquinas do cluster. O servidor DNS pode implementar vários tipos de políticas de distribuição de tráfego para o servidor mais apropriado. Ao receber uma requisição de mapeamento, o servidor DNS primário do cluster seleciona o nó mais apropriado e especifica um tempo de validade para o cache desse mapeamento, conhecido como Time-To-Live (TTL). Depois que o mapeamento expira, a requisição de mapeamento é novamente enviada para o servidor primário do cluster e então ele pode novamente realizar a distribuição do tráfego. De outra maneira, a requisição de mapeamento é respondida por uma das entidades intermediárias que possuem informações em cache sobre aquela URL. O uso de cache existe para facilitar e agilizar o processo de mapeamento, mas também é um problema dessa abordagem, já que o servidor DNS tem controle limitado sobre a distribuição de carga. Primeiro, a solicitação do cliente é enviada para o servidor DNS local e, se este não puder resolver o nome, ele usa regras bem definidas para enviar a solicitação para outro servidor DNS, e assim por diante. Em último caso, o servidor DNS primário, responsável por resolver o nome em questão e onde é realizado o balanceamento de carga, é quem responde à requisição. Esse é um problema maior especialmente para sites mais populares. Um servidor DNS local utilizado por muitos clientes irá sobrecarregar o servidor indicado pelo endereço IP em cache e fazer com que a informação atual sobre a carga fique obsoleta rapidamente e seja fracamente relacionada com a possível carga futura. Para minimizar esse problema, o valor TTL associado com uma entrada DNS pode ser diminuído. Entretanto, com a diminuição do uso de cache, aumentará a carga no servidor DNS do cluster, que pode se tornar um possível gargalo de requisições. Os algoritmos de distribuição de carga nessa abordagem se dividem naqueles que usam valores de TTL constantes ou adaptáveis. Um exemplo que usa valores constantes é o algoritmo de Round-robin DNS, ou DNS-RR, implementado pelo National Center for

22 22 Supercomputing Applications (NCSA) [14]. O servidor DNS do NCSA foi modificado para implementar um algoritmo Round-robin para o mapeamento de endereços, ou seja, duas requisições consecutivas terão respostas diferentes. A desvantagem desse algoritmo é que ele ignora informações sobre a capacidade e a disponibilidade dos nós. Conhecer as condições do estado atual do cluster de servidores é obrigatório, pois somente assim pode-se excluir nós não-alcançáveis devido a falhas ou congestionamentos. Uma solução simples é usar, em combinação com as políticas DNS, um alarme que avisa quando um servidor está sobrecarregado. Outra solução é basear o balanceamento nas informações sobre a carga atual dos servidores, escolhendo aquele menos carregado. Os algoritmos de distribuição de carga pelo DNS podem usar ainda informações vindas do cliente, como por exemplo: a carga que chega ao sistema para cada domínio conectado e a localização geográfica do cliente. A maioria dos algoritmos DNS consegue melhores resultados quando usa tanto informações de estado do cliente quanto do servidor [15]. Somente explorar a política para escolher o servidor com valores TTL constantes é insuficiente. Por isso foram propostas soluções que ajustam os valores do TTL baseado em diferentes critérios. Uma melhor alternativa é dar diferentes valores de TTL para cada requisição de endereço (algoritmos TTL adaptativo), para levar em conta situações como a distribuição desigual da carga dos domínios e as diferentes capacidades dos servidores. O TTL adaptativo usa um processo de decisão de dois passos. No primeiro, o DNS seleciona o servidor Web e, no segundo, escolhe o valor apropriado para o TTL. A distribuição desigual de carga de domínio é controlada pelo uso de valores de TTL inversamente proporcionais à taxa de requisição do domínio. Por exemplo, as requisições de endereço vindos de domínios muito populares receberão um valor menor de TTL do que aquelas vindas de domínios menores. Algoritmos de TTL adaptativo são mais robustos e efetivos no balanceamento de carga, mesmo na presença de cargas com variância e servidores de nome não-cooperativos (que não usam o TTL configurado pelo DNS primário). Uma política que usa TTL adaptativo e informações de localização do cliente pode conseguir desempenho melhor ainda.

23 23 Uma grande desvantagem do uso de cluster de servidores baseado em DNS é que os endereços IP de todos os nós do cluster estão expostos para a Internet. Quando um servidor falha ou é posto em manutenção, um cliente pode ainda tentar acessar essa máquina, porque o servidor DNS não está ciente do estado do servidor ou o endereço IP dessa máquina está em cache em um dos intermediários entre o cliente e o servidor. Ainda, por controlar somente uma parte das requisições, o distribuidor DNS precisa utilizar algoritmos sofisticados para conseguir um bom desempenho. Eles são tipicamente baseados em informações sobre o estado dos servidores e informações dos clientes Abordagem baseada em despachante Ao contrário da anterior, esta abordagem objetiva ter controle total sobre as requisições de clientes e mascara o roteamento dessas requisições entre os vários servidores. Para esse propósito, ela estende a virtualização de endereços, que no DNS era feita no nível do endereço URL. Agora, ela é feita para o endereço IP, fazendo com que o cluster Web tenha somente um único endereço IP virtual (IP-SVA, ou IP-Single Virtual Address). Na verdade, este é o endereço de IP do despachante, ou dispatcher, que age como um centralizador, com controle total sobre as requisições dos clientes. Essa abordagem geralmente usa algoritmos mais simples para selecionar o nó servidor porque o despachante deve gerenciar todas as requisições que chegam no cluster, e a quantidade de processamento necessária para cada requisição deve ser mantida ao mínimo. Os tipos de algoritmo de balanceamento comumente usados nessa abordagem são o Round-robin (RR), que não considera a carga atual de cada um dos servidores, Least Connection (LC), que distribui a carga baseado no servidor que tem menos conexões HTTP e Least Loaded (LL), que distribui as requisições baseado na carga de trabalho, isto é, a soma do tempo de serviço de todas requisições pendentes em um servidor. Segundo Teo et al [16], que apresenta comparações entre esses três algoritmos, o LL é o melhor algoritmo, com o RR apresentando os piores resultados. Com o aumento da taxa de requisições, o desempenho dos três algoritmos converge, com os algoritmos LL e LC tendo um melhor desempenho para cargas médias e altas. O despachante pode ser hardware ou software e interceptar os pedidos em diferentes camadas do modelo OSI. Despachantes da camada quatro, de Transporte, não têm informações sobre o conteúdo da requisição, pois eles determinam o servidor alvo

24 24 quando o cliente estabelece uma conexão TCP-IP. Já os despachantes da camada sete, de Aplicação, possuem informações úteis sobre o conteúdo da requisição, pois têm acesso à requisição HTTP. Assim, o mecanismo de balanceamento de carga pode ser baseado no serviço que está sendo requisitado. As duas principais formas de classificação nessa abordagem, de acordo com o modo que ela direciona as requisições para um dos nós do cluster são: mecanismos de reescrita e de redirecionamento HTTP. Os mecanismos de reescrita podem ser de dois tipos. Na reescrita única de pacotes pelo despachante, este encaminha pacotes vindos do cliente para o servidor através da reescrita do endereço IP. Todas as requisições HTTP chegam no despachante porque o IP- SVA é o único endereço público. O roteamento para um dos servidores é feito com a reescrita do endereço IP de destino de cada pacote que chega ao despachante, substituindo o seu IP-SVA com o endereço IP do servidor selecionado. Como uma requisição consiste de diversos pacotes, é necessário manter uma lista dos endereços IP fontes para cada conexão TCP estabelecida. Assim, o despachante pode encaminhar sempre ao mesmo nó os pacotes pertencentes à mesma conexão. Da mesma forma, o nó servidor selecionado, antes de enviar os pacotes de resposta ao cliente, precisa substituir o seu endereço IP pelo endereço IP virtual do despachante. Assim, o cliente não tem ciência de que está acessando um cluster de servidores. Na reescrita dupla de pacotes pelo despachante, os passos são os mesmos que os descritos para o primeiro tipo. A diferença é que o despachante, além de reescrever os pacotes que chegam no sistema, também modifica o endereço dos pacotes de resposta, substituindo o endereço do nó escolhido pelo seu endereço IP virtual. Essa opção apresenta piores resultados do que a primeira, pois congestiona ainda mais o despachante. A segunda classificação das abordagens baseadas em despachante compreende as soluções que utilizam o redirecionamento dos pacotes de clientes para encaminhá-los ao servidor escolhido. Um exemplo é a solução da IBM chamada LAN Network Dispatcher [17]. Ela assume que o despachante e os nós servidores estão na mesma rede local, compartilhando o mesmo endereço IP virtual. Os pacotes chegam somente à máquina Network Dispatcher porque os nós desabilitaram seus mecanismos de resolução de endereço ARP. O despachante pode, então, encaminhar esses pacotes para o servidor selecionado usando seu endereço físico, sem modificar o cabeçalho TCP. Esta solução é

25 25 transparente tanto para o cliente quanto para o servidor porque não necessita de reescrita de pacotes. Outro exemplo encontrado é o sistema ONE-IP [18], que publica o mesmo endereço IP secundário, o IP-SVA, dado a todos os nós do cluster de servidores. Nesse exemplo, ao contrário dos outros, nenhuma máquina possui o IP-SVA como seu endereço primário. A comunicação entre servidores do cluster é feita utilizando os seus endereços IP primários e as requisições de clientes chegam somente ao endereço secundário. Ele utiliza uma função hash para identificar unicamente o servidor que foi selecionado para uma determinada requisição. O despachante envia os pacotes a todos servidores, que verificam, através da função hash, se eles são o destino dos pacotes. O uso de hash foi escolhido para solucionar situações em que a grande quantidade de requisições torna o despachante um gargalo de acesso ao sistema. Mas esta solução acaba sendo também o ponto fraco dessa abordagem, pois não permite balanceamento de carga dinâmico e, além disso, não leva em conta a heterogeneidade dos servidores. Em outra abordagem, o redirecionamento é feito por um despachante que distribui as requisições entre os nós do cluster através de um mecanismo existente no protocolo HTTP. Esse protocolo permite que o redirecionamento seja feito pela especificação, na resposta, de um código de status indicando no seu cabeçalho o endereço do servidor no qual o cliente pode conseguir o documento requisitado. Esse redirecionamento é transparente ao usuário, embora seja possível notar um maior tempo de resposta, pois o número de conexões TCP necessárias é duplicado. A maior desvantagem de soluções baseadas em um despachante é a presença de uma única entidade de decisão, tornando-se um ponto de falha único e um gargalo para o sistema quando é submetido a crescentes taxas de requisições. Se o despachante falhar, nenhuma requisição é recebida pelo cluster. Ele também deve ter a capacidade de perceber quando um dos nós do cluster falha. O ideal é que o despachante tenha mecanismos para a detecção de falha, para redirecionar a carga de acordo com essas informações. Nem as soluções baseadas em DNS nem as baseadas em despachantes provêem um modo conveniente para dinamicamente recrutar recursos inativos durante picos de carga. A capacidade de balanceamento de carga provida por um despachante ainda é limitada, pois ele precisa encaminhar os pacotes o mais rápido possível.

26 Abordagem baseada no servidor As técnicas baseadas no servidor usam mecanismo de distribuição em dois níveis: uma requisição é inicialmente determinada pelo DNS do cluster para um dos servidores Web, e então o servidor escolhido pode redistribuí-la para qualquer outro nó no cluster. Ao contrário das outras abordagens, esta permite que todos os servidores participem no balanceamento da carga através de mecanismos de redistribuição de requisições. A decisão de servir ou redirecionar uma requisição pode ser feita baseada em diversos critérios. A integração da abordagem baseada no DNS com alguma técnica de redirecionamento feito pelos servidores Web objetiva resolver a maioria dos problemas que afetam as políticas de distribuição DNS, já mencionados anteriormente. As abordagens baseadas no servidor se diferenciam pelo modo como a decisão de redirecionamento é feita e implementada. Um exemplo do redirecionamento HTTP pelo servidor é o sistema Scalable Server World Wide Web (SWEB) [19]. A arquitetura SWEB usa uma política DNS-RR como o modo de distribuição no primeiro nível e um esquema de distribuição assíncrona como modo de distribuição no segundo nível. Cada servidor decide se irá redirecionar baseado em um critério de seleção, que leva em conta capacidades de processamento dos servidores e o atraso e a largura de banda da rede. Uma desvantagem desse método é o aumento no tempo de resposta para o cliente, pois para cada requisição é necessário criar uma nova requisição no redirecionamento. Outra desvantagem é que esse método expõe os endereços IP dos servidores do cluster, diretamente ou através de servidores DNS, podendo ser usados para acessar o site mesmo quando um servidor está indisponível, devido à falha ou à manutenção. Os mecanismos de redistribuição propostos implicam também em uma sobrecarga da comunicação dentro do cluster, pois cada servidor precisa transmitir periodicamente informações sobre seu estado. Entretanto, esse custo pode ser considerado desprezível no tráfego total da rede. Na verdade, a maior desvantagem para o usuário é o redirecionamento HTTP. Outro exemplo de redirecionamento de pacotes pelo servidor é o Distributed Packet Rewriting (DPR) [20] que também utiliza um mecanismo DNS-RR para realizar a primeira distribuição de requisições. O servidor selecionado pode reenviar a requisição para outro servidor através de um mecanismo de reescrita de pacote que é transparente para o cliente.

27 27 Dois algoritmos de balanceamento de carga foram propostos pelos autores do mecanismo. O primeiro usa uma função de roteamento estático, na qual o destino é escolhido por uma função hash, e o segundo requer comunicação periódica entre os servidores sobre a sua carga atual, redirecionando para o servidor com menor carga. 2.3 WEB SERVICES Um serviço é uma abstração de um conjunto de operações, com uma funcionalidade em comum, oferecido a clientes. O termo Web Service pode ser definido de diversas maneiras. Nessa revisão destacam-se três conceitos principais. O primeiro conceito afirma que Web Services é uma arquitetura orientada a serviços que permite interoperabilidade entre diferentes plataformas através do uso de padrões abertos, ou seja, padrões que podem ser implementados por qualquer fabricante [21]. Foi construída utilizando protocolos Web já existentes e é baseada em XML, uma metalinguagem padrão para representação e transferência de dados do tipo texto através de tags de marcação. No segundo conceito diz-se que essa arquitetura disponibiliza um mecanismo único para descrição, localização e comunicação entre aplicações acessíveis online. Assim, por um Web Service entende-se um serviço disponível na Web que pode ser descrito, publicado, localizado e chamado através de protocolos padrões da Internet usando mensagens no formato XML [22]. Por último, o terceiro conceito, de autoria do W3C [23], um Web Service é um sistema de software projetado para dar suporte à interação entre máquinas através de uma rede. Ele possui uma interface descrita em um formato possível de ser processado por computadores (WSDL). Outros sistemas interagem com um serviço Web, baseados na sua descrição, usando mensagens SOAP, normalmente transportadas usando HTTP com serialização XML em conjunto com outros padrões Web. Um Web service é um conceito abstrato que precisa ser implementado por um agente, que é o software ou hardware que envia e recebe mensagens. Resumindo, um Web service é um serviço identificado por um URI (Uniform Resource Identifier) que pode ser acessado por aplicações através de protocolos Web de acordo com o contrato que descreve a sua interface.

28 28 A Web tem tido um gigantesco sucesso na interação entre humanos e computadores. A simplicidade do protocolo HTTP e da linguagem de marcação HTML permitiu que fossem implementados em uma variedade de sistemas operacionais e ambientes de programação. Os Web Services usam muitas das idéias e princípios da Web para interação entre computadores. Assim como a Web, os Serviços Web utilizam protocolos simples e baseados em texto, que podem ser utilizados de forma modular, acrescentando somente as funcionalidades desejadas, e permitem a sua implementação em diversas plataformas. O XML, juntamente com a sua linguagem de definição formal, a XML Schema (esquema XML), ajuda a facilitar e melhorar a integração entre aplicações através da eliminação de ambigüidade e pelo suporte à validação das mensagens trocadas. Cada vez que um usuário visita um site na Web, pode-se dizer que ele está fazendo, indiretamente, uma chamada remota de procedimento, ou Remote Procedure Call (RPC). O RPC é uma abstração para remotamente executar chamadas a procedimentos em uma linguagem de programação. O cliente, um navegador, requisita um arquivo de um servidor com uma requisição em formato HTTP, que então processa e mostra as informações de resposta em formato HTML. Inicialmente, o conceito de Web Services era muito vinculado ao de chamada remota de procedimentos, na qual tanto requisição quanto resposta são codificadas em formato XML. No princípio, o que deu notoriedade à tecnologia Web Services foi a possibilidade de conectar sistemas díspares usando tecnologias independentes de plataforma com a possibilidade de trafegar mesmo através de firewalls. Os desenvolvedores tinham acesso a um conjunto de tecnologias que se assemelhavam à de objetos distribuídos, o SOAP era considerado um protocolo de acesso a objetos e o WSDL era visto como um protocolo de descrição de interface de classes. Não poderia deixar de ser assim, já que, nessa época, o próprio termo SOAP era um acrônimo para Simple Object Access Protocol ou Protocolo Simples de Acesso a Objetos. Tudo isso levava a crer que esta nova arquitetura que surgia era mais um meio de se realizar chamadas remotas a procedimentos ou objetos. Essa idéia inicial está sendo aos poucos substituída por uma visão orientada à troca de mensagens em uma arquitetura orientada a serviços (SOA). Desse modo, pode-se trocar documentos XML completos entre consumidores e serviços. A partir da especificação