A IMPLEMENTAÇÃO DE WEB SERVERS ROBUSTOS E ESCALÁVEIS USANDO O EDDIE

Transcrição

1 Instituto Superior de Engenharia do Porto A IMPLEMENTAÇÃO DE WEB SERVERS ROBUSTOS E ESCALÁVEIS USANDO O EDDIE José Mendonça i Projecto orientado por: Engº Paulo Ferreira Setembro 2000

2 Índice Índice 1. Introdução Conceitos e Terminologia Aplicações distribuídas Clusters Erlang O que é o Eddie Componentes Características Balanceamento de carga Escalabilidade Optimização do desempenho Qualidade de serviço Fiabilidade Plataformas suportadas Instalação Pré-requisitos Criação do utilizador do Eddie Instalação da Package RPM Configuração Configuração do Eddie Enhanced DNS Configuração Geral do Eddie Configuração do HTTP Gateway e do Cluster: cenários de configuração Um Servidor DNS com balanceamento de carga Utilização simples de Front Ends e Back Ends Um gateway/apache cluster básico Sobreposição de Clusters Apache Clusters Gateway/Apache sobrepostos Inicialização e Controlo Comandos do Eddie O comando lbdns O comando eddie Preparação e Inicialização do Eddie Controlo do Eddie Alternativas ao Eddie Aplicações comerciais Aplicações não comerciais Conclusões Bibliografia

3 Introdução 1. Introdução A utilização da Internet está a aumentar a uma taxa enorme e a Web disponibiliza um número crescente de serviços comerciais. Estes serviços variam desde simples procura de informação até serviços de correio electrónico. No entanto, a fiabilidade dos serviços prestados actualmente é tipicamente menor do que o requerido por aplicações críticas. Neste momento é muito importante melhorar o desempenho da Web de forma a torná-la tão fiável como, por exemplo, os telefones, proporcionando um meio adequado aplicações críticas de grande volume. As redes de telecomunicações possuem um conjunto de objectivos bem definidos durante periodos de congestionamento e falha parcial do sistema: manutenção de uma boa performance, mesmo durante periodos de extremo congestiomento; assegurar ao utilizador atrasos toleráveis, não muito maiores que em condições normais; assegurar que não existirá nenhuma avaria durante o congestionamento; assegurar a integridade e a capacidade de resposta do sistema; providenciar uma degradação da qualidade do serviço se esta for inevitável; Infelizmente, a Web ainda não possui a maturidade suficiente que permita atingir estes objectivos. Na verdade, na Web e particularmente em servidores Web, não é muito clara a existência de objectivos que sejam aceites com clareza pela generalidade dos agentes. Enquanto a utilização de servidores Web cresce a uma taxa enorme, a sua fiabilidade não possui a mesma taxa de crescimento. Durante periodos de grande carga, os servidores Web tendem a aceitar pedidos de novos utilizadores, degradando a qualidade de serviço prestada aos utilizadores que já estavam no sistema. Existem vários exemplos de sobrecargas que resultaram em rupturas graves no serviços e perdas financeiras. Um grande número de empresas, como a Cisco, IBM e outras, estão a trabalhar no sentido de melhorar a capacidade dos servidores Web principalmente em ambientes distribuidos. As soluções propostas por estas empresas variam desde software até hardware. No entanto, estas soluções possuem várias deficiências: Incapacidade de ajustar no servidor a utilização de recursos, resultando ou na admissão de muitos utilizadores devido a uma configuração demasiado permissiva, ou então no controle exagerado da admissão limitando artificialmente a capacidade do servidor. Ignorar os utilizadores depois de estes terem ganho acesso ao serviço, podendo resultar, em periodos de maior carga, na perda da qualidade de serviço prestado a esses utilizadores em deterimento de utilizadores que tenham ganho acesso ao serviço mais recentemente. As soluções baseadas em hardware requerem equipamento especial, resultando em problemas de escalabilidade e limitam a sua capacidade para suportar servidores Web distribuidos geograficamente. Necessidade de utilização de sistemas operativos específicos, limitando a flexibilidade da solução relativamente ao número de aplicações que podem ser suportadas pelo sistema, obrigando o proprietário a seguir um caminho de desenvolvimento particular. Devido a estes factos, existe uma grande necessidade de desenvolver sistemas robustos e escaláveis que permitam colmatar as falhas dos sistemas actuais. 2

4 Conceitos e Terminologia 2. Conceitos e Terminologia 2.1 Aplicações distribuídas As aplicações distribuídas, baseiam-se em processos e comunicação entre processos. Estes podem correr numa mesma máquina (host) ou em máquinas diferentes. Cada processo pode ter funcionalidades espeçíficas que poderão ser utilizadas por um outro processo para efectuar um determinado processamento. Através da comunicação entre processos, é possível criar uma comunidade informática virtual, em que os participantes cooperam entre si para atingir um determinado resultado. A utilização de aplicações distribuídas tem grandes vantagens ao nível da tolerância a falhas, uma vez que podem existir processos que supervisionam outros processos, verificando se existe alguma falha. Se, eventualmente, um processo morrer, o processo supervisor detecta o evento e lança automáticamente um novo processo na mesma máquina ou, se necessário, numa máquina diferente. 2.2 Clusters Basicamente, um cluster pode ser entendido por um conjunto de máquinas servidoras que disponibilizam os mesmos serviços, estando este conjunto aliado a uma máquina (ou mais) que efectua o escalonamento dos pedidos dos clientes pelas máquinas servidores disponíveis. Ao servidor encarregue do escalonamento dos pedidos dos clientes dá-se o nome de Front End Server. Áos servidores que disponibilizam os serviços, encarregues de responder aos pedidos dos clientes, dá-se o nome de Back End Servers. As expressões Front End Server e Back End Server serão utilizadas frequentemente ao longo deste documento, pelo que serão abreviadas para, respectivamente, FES e BES. A utilização de clusters permite que, quando uma determinada máquina do cluster avaria, os pedidos dos clientes deixem de ser redireccionados para essa máquina, mantendo-se o servidor virtual a funcionar desde que, teoricamente, exista pelo menos um Front End Server e um Back End Server operacional. Quando a máquina avariada volta a funcionar, esse acontecimento é detectado pelo(s) Front End Server(s) e os pedidos voltam a ser direccionados também para aquela máquina. Os clusters permitem uma grande tolerância a falhas através desta utilização de réplicas de serviços e informação. Os clusters são normalmente completados com procedimentos de balanceamento de carga entre os Back End Servers e/ou outros procedimentos de optimização. 2.3 Erlang O Erlang é uma linguagem de programação desenvolvida pela Ericsson. Um dos pontos fortes do Erlang é a facilidade de desenvolvimento e implementação de aplicações distribuídas. A filosofia adoptada pelo Erlang permite rapidamente a um programador, aprender e desenvolver aplicações baseadas em processos distribuídos, que comunicam entre si através de mensagens. Existem vários sistemas desenvolvidos em Erlang, principalmente sistemas de telecomunicações. O Erlang é uma linguagem OpenSource, regida pela MPL, o equivalente Sueco da GPL. Para mais informações visitar (fundamental para qualquer programador). 3

5 O que é o Eddie 3. O que é o Eddie O Eddie é uma solução 100% software, Open Source, que foi escrito quase na sua totalidade na linguagem de programação Erlang. O projecto Eddie pretende dar uma resposta ás dificuldades sentidas pelos fornecedores de serviços na Internet, no que respeita a disponibilidade, escalabilidade e qualidade do serviço. Para tal, o Eddie possui um conjunto de componentes que, quando combinados possibilitam a construção de Web Sites extremamente robustos e fácilmente escaláveis. Cada componente pode ser utilizado separadamente, mas a cooperação entre componentes, possibilita implementar uma série de características que serão descritas ao longo deste documento. 3.1 Componentes O Eddie é constituido basicamente por 2 componentes: Um servidor DNS com balanceamento de carga; Um gateway HTTP com migração de endereços IP; A tabela seguinte resume as características principais de cada um dos componentes do Eddie. Componente Enhanced DNS Server Características principais - Balanceamento de carga numa WAN; - Retorna, a partir da informação sobre a carga dos servidores, o servidor Web com menor carga; - Implementa um servidor DNS compatível com BIND4. Intelligent HTTP Gateway - Balanceamento de carga numa LAN; - Recebe pedidos, descodifica-os e separa as diferentes partes do pedido; - Suporta uma sobreposição de grupos de servidores dedicados a tarefas diferentes; - Comunica com os servidores Web (Apache, Netscape e Microsoft, etc.) utilizando o protocolo HTTP; - Efectua controlo de admissão com o intuíto de garantir aos utilizadores qualidade de serviço. - Muda o endereço IP de um host avariado para um outro host disponível em uma LAN; - Quando um host reaparece após uma avaria, recebe automaticamente de volta o seu endereço IP e reinicia a sua actividade. 4

6 O que é o Eddie A figura seguinte exemplifica a utilização de servidores Enhanced DNS e Intelligent HTTP Gateway em dois sites distintos. Internet Site 1 Intelligent HTTP Gateway Front End Servers Back End Servers Back End Servers Eddie Enhanced DNS Site 2 Intelligent HTTP Gateway Front End Servers Back End Servers Back End Servers Figura 1: Servidor Web distribuído através da utilização de Enhanced DNS e Intelligent HTTP Gateway Eddie Enhanced DNS Todos os componentes do Eddie foram desenvolvidos na linguagem de programação Erlang/OTP, aproveitando as facilidades disponibilizadas por este suporte de desenvolvimento relativamente ao desenvolvimento e implementação de aplicações/processos distribuídos. Uma aplicação distribuída e cooperativa que corre num determinado servidor, é monitorizada por um supervisor local que coopera com supervisores existentes em outros hosts. Se o host que corre a aplicação avaria, os outros supervisores detectam esse acontecimento e decidem entre eles qual é o host mais apropriado para correr a aplicação que deixou de estar disponível. Como de seguida veremos, todo este processo é inteiramente configurável. O conceito de aplicação distribuida, possibilita a uma aplicação sobreviver enquanto pelo menos um host esteja a funcionar normalmente. Mesmo se o último host disponível avariar, a aplicação pode reaparecer quando o primeiro host voltar a estar operacional. Esta recuperação rápida é possível através da utilização de uma base de dados de tempo real, distribuida e replicada. 5

7 O que é o Eddie 3.2 Características Balanceamento de carga Através do balanceamento de carga num determinado site, o Eddie permite maximizar a sua performance. Esta funcionalidade é possível através dos Front End Servers que procedem á recolha e tratamento de informação detalhada enviada por todos os Back End Servers. Esta informação permitirá aos Front End Servers distribuir os pedidos por todos os Back End Servers. A informação é recolhida e analisada periodicamente, permitindo implementar um balanceamento dinâmico. Este balanceamento de carga é efectuado de forma a manter cada um dos BES a funcionar a uma fracção (pré-definida) da sua capacidade total. Não recorrendo a um balanceamento estático, como o Round Robin, é possível maximizar os recursos de todos os BES, assegurando que em periodos grande carga não existirão servidores subutilizados. Informação sobre a carga dos Backends Internet Front End Servers Back End Servers Eddie Enhanced DNS Front End Servers Back End Servers Eddie Enhanced DNS Informação sobre a carga dos Backends Figura 2: Em cada site, os Front End Servers utilizam a informação sobre a carga para balancear o tráfego que entra através de cada um dos Back End Servers 6

8 O que é o Eddie Escalabilidade Quando existe a necessidade de aumentar a capacidade de um site poderão ser adicionados novos FES e/ou novos BES. Depois de efectuada a reconfiguração do Eddie, a capacidade do novo servidor fica imediatamente disponível. Esta capacidade ficará disponível não só para esse site mas sim para todo o servidor distribuído através da utilização do Enhanced DNS Server. Internet Front End Servers Back End Server adicional Back End Servers previamente existentes Eddie Enhanced DNS Front End Servers Back End Servers adicionais Back End Servers previamente existentes Eddie Enhanced DNS Figura 3: Escalabilidade através da adição de novos computadores ao cluster Optimização do desempenho É muito frequente a utilização de servidores Web específicos para determinadas funções. Essas funções dos servidores Web incluem: Repositório de imagens; Aplicações de bases de dados; Máquinas CGI. O Eddie permite especificar as funções que cada um dos servidores Web desempenha. Através da descodificação e análise dos pedidos HTTP, é possível escalonar os pedidos para os servidores Web apropriados. O ajustamento do desempenho de servidores específicos para efectuar essas funções pode ajudar a maximizar a capacidade total de um servidor web distribuído. 7

9 O que é o Eddie A alocação das diferentes funcionalidades de cada um dos Back End Servers é especificada nos ficheiros de configuração do Eddie. Internet Pedidos de sessões HTTP Download de imagens Transacções CGI Front End Servers Back End Server: repositório de imagens Back End Servers: Máquinas CGI Eddie Enhanced DNS Figura 4: Os Front End Servers segmentam os pedidos e procedem ao seu redireccionamento para os Back End Servers optimizados Qualidade de serviço A qualidade de serviço é proporcionada pelo Eddie através de uma função de controle de admissão. A filosofia adoptada é a seguinte: Se um utilizador recebe a primeira página requisitada, deverá então receber cada página que requisitarem com rapidez, até ter terminado. Se o servidor não conseguir garantir um tempo rápido de resposta, o utilizador deverá ser ou colocado numa fila de espera até que estejam disponíveis recursos suficientes, sendo avisado que será admitido o mais rápidamente possível, ou rejeitado e avisado para voltar mais tarde. As rotinas de monitorização da utilização de cada Front End Server e Back End Server utilizam vários tipos de informação incluindo a informação sobre a carga do CPU, utilização da memória, atrasos no acesso ao disco e filas de espera. O administrador do servidor web efectua a configuração dos limites da utilização de recursos críticos, que serão usados pela função de controle de admissão de forma a decidir se um determinado servidor está ou não sobrecarregado. A informação sobre a carga dos Back End Servers é utilizada pelos Front Ends para estimar a taxa a que novos utilizadores poderão ser enviados para os Back Ends e receberem uma resposta rápida. Quando um Front End recebe um pedido de um utilizador, verifica se foi dada uma autorização recente para o acesso ao site. Se for esse o caso, então o pedido é enviado directamente ao Back End Server que prestou o serviço anterior a este utilizador. Desta forma, qualquer informação de estado sobre o utilizador poderá ser mantida com fiabilidade. Se o utilizador não tiver acedido ao site recentemente, o Front End Server decide se existem recursos suficientes nos Back Ends para autorizar, ou não, o acesso do utilizador. 8

10 O que é o Eddie Se existirem recursos suficientes, o pedido é reencaminhado para um Back End Server e o Front End Server cria um registo na tabela com a hora do pedido do utilizador. Todos os dados entre o utilizador e o Back End Server passam pelo Front End Server que actualiza informação sobre o utilizador. Este procedimento é usado para criar uma sessão para o utilizador. Se o utilizador termina a interacção com o servidor durante um periodo configurável de tempo, 10 minutos por exemplo, a sessão é terminada e os eventuais pedidos subsequentes por parte do utilizador estarão sujeitos ao controle de admissão. Se os recursos forem insuficientes para servir de imediato o cliente, o pedido é colocado em fila de espera e uma página web é enviada informando que o utilizador será admitido brevemente. Esta página é actualizada automaticamente, informando o cliente do estado do seu pedido. Como benefício, desencoraja os utilizadores de clicarem continuamente no mesmo URL, desperdiçando os recursos do servidor. Internet Pedidos de sessões HTTP Pedidos de Sessões HTTP Rejeitados Pedidos de Sessões HTTP Servidos Pedidos de Sessões HTTP Aceites Front End Servers Back End Servers Eddie Enhanced DNS Figura 5: O controle de admissão do Eddie assegura os tempos de resposta em periodos de sobrecarga do servidor É ainda possível discriminar os utilizadores, através da sua classificação em grupos e indicando prioridade de acesso de cada grupo. Esta característica permite a uma empresa, por exemplo, dar prioridade de acesso aos seus clientes Fiabilidade A fiabilidade do sistema é assegurada pela detecção automática de falhas no servidor e uma combinação de roteamento do tráfego e migração de endereços IP. A monitorização efectuada pelos Front End Servers aos Back End Servers permite a detecção de falhas nestes. Se um Back End falha, esta é detectada e os Front End Serves redireccionam imediatamente os pedidos do utilizador para outros Back End Servers que corram a mesma aplicação. 9

11 O que é o Eddie Uma falha num Front End Server é também detectada automáticamente. A capacidade dos Front End Servers de migração de endereços IP assegura que um Front End Server existente no site assuma o endereço IP da unidade avariada. Quando esta é recolocada em funcionamento, o seu endereço IP original é automaticamente migrado. Uma falha na ligação do site á Internet é detectada por cada Enhanced DNS Server que procedem á eliminação dos Front Ends do site afectado da lista de servidores disponíveis. Internet Front End Servers Back End Servers Eddie Enhanced DNS Front End Servers Back End Servers Eddie Enhanced DNS Figura 6: Resposta do Eddie a vários tipos de falhas 3.3 Plataformas Suportadas O Eddie está disponível para as seguintes plataformas: Red Hat Linux 5.2 ou superior; FreeBSD ou superior; Solaris ou superior. É possível compilar o Eddie para correr no Windows NT. No entanto, existe pouca informação sobre os procedimentos de compilação e apenas é recomendada a utilização do Eddie no Windows NT como um nó Backend. 10

12 Instalação 4. Instalação Todos os procedimentos de instalação e configuração apresentados neste documento foram testados no sistema Red Hat Linux 6.1, não se garantindo que os procedimentos, ficheiros e directórios de instalação sejam iguais em outras plataformas que o Eddie suporta. Foi utilizada uma versão do Eddie 1.4.1, compilada e distribuída num ficheiro do tipo RPM, que pode ser obtido Existe, no entanto, a possibilidade de efectuar o download de uma versão não compilada do Eddie. Neste documento não serão dadas explicações sobre a instalação do Eddie a partir de uma versão não compilada. Para mais informações consultar Pré-Requisitos Para instalar o Eddie é necessário que estejam previamente instaladas as seguintes aplicações em cada um dos computadores que irá correr o Eddie: Erlang/OTP Esta aplicação pode ser obtido em Secure Shell (SSH1), convenientemente configurado de forma a permitir o acesso remoto do utilizador que irá correr o Eddie a todos os computadores que participam no cluster. Esta aplicação pode ser obtida em A instalação do Secure Shell (ssh) é opcional, uma vez que o Eddie pode utilizar o Remote Shell (rsh) para aceder a computadores remotos. Neste caso, a inexistência do ssh implica a utilização do rsh. No entanto, uma vez que o Secure Shell permite comunicações seguras,através de encriptação de dados, é recomendada a sua utilização para um maior nível de segurança. 4.2 Criação do utilizador do Eddie Para correr o Eddie é necessária a existência de um utilizador que possua os privilégios necessários para correr o Eddie. Por defeito este utilizador tem o username eddie, mas pode ser alterado para outro qualquer nos ficheiros de configuração (como adiante se verá). Assim, se o username do utilizador for eddie, teremos de criar no sistema um utilizador com o username eddie que pertença ao grupo daemon. Este grupo tem os privilégios suficientes para correr o Eddie. 4.3 Instalação da Package RPM Após ter sido obtido o ficheiro de instalação do Eddie (eddie i686.rpm ) e efectuados os procedimentos descritos anteriormente, podemos instalar o Eddie com o comando seguinte: rpm i eddie i686.rpm Este comando instala os ficheiros nos directórios seguintes: /etc/eddie ficheiros de configuração do Eddie; /usr/local/sbin - comandos do Eddie; /usr/local/lib/eddie livrarias e módulos de callback do Eddie 11

13 Configuração: 5. Configuração: Exemplos Após a instalação, os ficheiros de configuração do Eddie estão em /etc/eddie/. O Enhanced DNS Server é compatível com o named-4.x.y (BIND). Neste documento pressupõe-se algum conhecimento sobre a configuração e utilização do named, uma vez que no próximo capítulo apenas estará disponivel a listagem do ficheiro necessário á configuração do balanceamento de carga para os exemplos que serão apresentados. Para informações sobre configuração e utilização do BIND4 consultar A tabela seguinte resume os ficheiros de configuração do utilizados pelo Enhanced DNS Server (com excepção dos ficheiros do BIND). Ficheiro /etc/eddie/lb_dns.boot Descrição Ficheiro que pode ser utilizado opcionalmente pelo DNS para configurar o balanceamento da carga em um ou mais sites. Para a configuração do Intelligent HTTP Gateway existem 3 ficheiros que configuram diferentes funcionalidades do Eddie. A tabela seguinte resume os ficheiros utilizados. Ficheiro /etc/eddie/eddie.conf /etc/eddie/eddie.gate Descrição Ficheiro de configuração geral, utilizado para controlar um determinado número de parâmetros do Eddie, nomeadamente: Cookie que será utilizado para a comunicação entre processos; Localização da base de dados distribuida que contém a informação de estado do site; Directório dos módulos de callback; Localização dos ficheiros de configuração do cluster (.gate e.mig); Utilizado para configurar o Intelligent HTTP Gateway no que concerne a: Portas para comunicação com os BES; Definição das funções que cada BES suporta; Controle de admissão. /etc/eddie/eddie.mig Utilizado para configurar o Intelligent HTTP Gateway no que concerne a: Quais os servidores Enhanced DNS existentes; Qual a configuração do cluster, incluindo a referência a todos nós (FES e BES) existentes no sistema e a sua organização. 12

14 Neste capítulo serão apresentados vários cenários que irão demonstrar algumas configurações possíveis do Eddie. Para tal iremos considerar uma rede local com 6 hosts: saturno ( ) plutao ( ) marte ( ) jupiter ( ) mercurio ( ) venus ( ) O servidor Enhanced DNS corre no host plutao com o seguinte mapeamento dos domínios: ( {1-6}) www-100.orbita.pt ( { }) www-200.orbita.pt ( { }) O esquema seguinte representa a configuração da LAN. saturno marte jupiter mercurio venus plutao router Figura 7: Exemplo de uma Rede local com 6 hosts 5.1 Configuração do Eddie Enhanced DNS A configuração que será utilizada pelo Enhanced DNS server é realizada através dos seguintes ficheiros: lb_dns.boot named.boot orbita.pt in-addr.arpa in-addr.arpa cache O primeiro ficheiro, lb_dns.boot, configura o balanceamento de carga para ser efectuado pelo servidor DNS. Os restantes são ficheiros BIND4 standart. Uma vez que a configuração de um servidor DNS é algo complexa e foge ao objectivo deste documento não serão apresentados os conteúdos dos ficheiros BIND4, recomendando-se a leitura do documento HOWTO respectivo. Seguidamente descreve-se o conteúdo do ficheiro lb_dns.boot, sabendo que o nosso servidor DNS ficará colocado no computador plutao e será responsável pela resolução de nomes do domínio e www-*.orbita.pt. 13

15 /etc/lb_dns.boot: 1: Port : Esta directiva especifica a porta UDP que o servidor DNS utiliza para escutar os relatórios enviados periodicamente pelos FES sobre a sua carga (por defeito é 4567). 3: TTL 122 4: A directiva TTL especifica um time-to-live para os dominíos com balanceamento da carga. Por defeito o valor é de 120 segundos. Se este valor for demasiado alto, o balanceamento da carga não irá reflectir, num curto prazo de tempo, as mudanças que poderão ocorrer no sistema, tornando pouco eficiente o balanceamento da carga. 5: Netmask /24 6: A directiva Netmask é utilizada para restringir os endereços IP autorizados a enviar informação sobre a sua carga para o servidor. No caso contrário, qualquer servidor poderia enviar informação sobre a sua carga, tendo como efeito potencial a sobrecarga do sistema. Para especificar vários endereços IP autorizados, podem ser dadas várias directivas Netmask ou então várias netmasks por directiva. Se não for dada nenhuma directiva Netmask, não existirão endereços IP autorizados a enviar informação. 7: Domain 8: Domain www-*.orbita.pt # Fim do ficheiro Esta directiva especifica o(s) dominio(s) para efectuar o balanceamento de carga. Para especificar vários dominios, utilizar várias directivas e/ou especificar vários dominios através do wildcard *. Se não forem especificados dominios, então nenhum será balanceado. A configuração do DNS está feita e o servidor pode ser utilizado através do comando lbdns: $ lbdns -b /etc/named/named.boot -l /etc/eddie/lb_dns.boot Se os FES estiverem configurados para utilizar o balanceamento de carga providenciado pelo servidor DNS, os pedidos serão balanceados segundo a informação sobre a carga dos FES. No caso contrário será utilizada o round-robin. 5.2 Configuração Geral do Eddie O ficheiro eddie.conf permite configurar vários parâmetros gerais que serão utilizados pelo Eddie. De seguida descreve-se o conteúdo do ficheiro eddie.conf. /etc/eddie.conf: 1: Cookie=myCookie 2: 14

16 A directiva Cookie, especifica o cookie que será utilizado para a comunicação entre os processos do cluster. Para cada cluster que corra na(s) mesma(s) máquina(s), o valor do cookie deverá ser único. 3: MnesiaDirectory=/var/tmp 4: A directiva MnesiaDirectory especifica a localização da base de dados do Eddie. Mnesia é um sistema de bases de dados distribuídas do Erlang. 5: RuntimeUser=eddie 6: Aqui especificamos o utilizador que irá correr o Eddie. Conforme foi referido no capítulo anterior, este utilizador deverá ser criado no sistema, e deverá pertencer ao grupo daemon. 7: DNSonly=false 8: DNSonly especifica se o Eddie deverá correr apenas no modo DNS, ou seja, se apenas enviará a informação sobre a carga do sistema para o(s) servidor(es) DNS (false) ou se terá também funções de admissão, balanceamento entre BES e/ou HTTP gateway (true). 9: ClusterConfig=/etc/eddie/eddie.mig 10: 11: GatewayConfig=/etc/eddie/eddie.gate # Fim do ficheiro ClusterConfig e GatewayConfig indicam, respectivamente, a localização dos ficheiros de configuração do cluster e do HTTP Gateway. O conteúdo destes ficheiros será descrito no próximo tópico deste documento. 5.3 Configuração do HTTP Gateway e do Cluster: cenários de configuração Para melhor explicar todas as funcionalidades do Eddie, será apresentados 5 cenários de configuração diferentes, que pressupõem que o servidor DNS esteja configurado da forma apresentada em 5.2, e o ficheiro de configuração geral da forma apresentada em 5.2. O ficheiro de configuração com a extensão.mig serve para a definição, localização e organização dos nós do cluster, assim como para a definição de migração de endereços IP. O ficheiro de configuração com a extensão.gate configura os parâmetros de controlo de admissão e do HTTP Gateway. 15

17 5.3.1 Um servidor DNS com balanceamento de carga Neste cenário iremos utilizar um servidor DNS dedicado ao balanceamento de carga entre 3 servidores web a correr o Apache: saturno, marte e jupiter. saturno marte jupiter mercurio venus plutao Front End Server (Apache) Enhanced DNS Server router Figura 8: Um servidor DNS com balanceamento de carga Em cada host que será objecto do balanceamento de carga, deverá estar a correr um nó do Eddie. Estes nós estarão encarregados de recolher a informação do estado do servidor onde correm e enviar essa essa informação para o servidor DNS. Neste caso não iremos utilizar as funcionalidades de migração de endereços IP nem do direccionamento de pedidos para servidores que disponibilizem serviços específicos. O ficheiro responsável pela migração de endereços IP (.mig) apenas especificará os nós que deverão recolher a informação do estado do servidor e quais os valores limites para esses valores. etc/eddie/dns_only.conf: 1: DNSServer plutao.orbita.pt : A directiva DNSServer especifica os servidores DNS aos quais os nós deverão enviar a informação de estado do servidor. Neste caso o servidor é o plutao.orbita.pt e a porta é a Esta porta tem de ser a mesma que foi especificada na configuração do servidor DNS (defeito é 4567). Através de várias directivas DNSServer, poderão ser especificados vários servidores DNS que deverão receber a informação dos nós. 3: <Node eddie@saturno> 4: LoadThreshold : </Node> 6: 7: <Node eddie@marte> 8: LoadThreshold : </Node> 10: 11: <Node eddie@jupiter> 12: LoadThreshold : </Node> 14: 16

18 A directiva node especifica um valor óptimo para a carga de cada nó. O servidor DNS balanceia os DNS lookups de forma que a carga de cada nó converga para o valor óptimo indica que o valor 30 pode ser visto como 80% da capacidade total do host. 15: <Cluster 16: ClusterType Frontend 17: 18: <Server eddie@saturno> 19: AutoConfig Off 20: IPAddress : </Server> 22: 23: < Server eddie@marte> 24: AutoConfig Off 25: IPAddress : </Server> 27: 28: <Server eddie@jupiter> 29: AutoConfig Off 30: IPAddress : </Server> Aqui é definido um único cluster do tipo Frontend. Nos cenários seguintes, a diferença entre um cluster Frontend e um cluster Backend ficará mais evidente. O nome do cluster ( é apenas descritiva, não tendo influência a nível de resolução de nomes. O cluster especifica três servidores que utilizam o endereço IP por defeito em cada nó. A directiva AutoConfig está no modo Off, ou seja, não há necessidade de utilizar IP aliasing para configurar endereços IP adicionais em cada placa de rede. 32: </Cluster> # Fim do ficheiro A configuração necessária para a implementação deste cenário está terminada, sendo agora apenas necessário inicializar e arrancar o Eddie, conforme descrito no próximo capítulo Utilização simples de frontends e backends O conceito de cluster frontend/backend é fundamental para atingir os objectivos principais do Eddie: robustez, escalabilidade e balanceamento de carga. Neste cenário iremos definir um cluster frontend com um grande conjunto de nós de backup (fail-over nodes) e um único cluster backend. Conforme referido anteriormente, um cluster frontend é tipicamente um conjunto de gateways que efectua o escalonamento dos pedidos para os servidores apropriados nos clusters backend. Um determinado pedido é redireccionado para um servidor backend especifico porque este está pouco carregado ou porque possui recursos únicos (especialização de servidores). Neste cenário dois gateways trabalham em paralelo para servir o dominio www100-orbita.pt. Um servidor DNS standart ou o Enhanced DNS Server escalona os pedidos para os gateways. Em circunstâncias normais, os gateway correm nos servidores saturno e marte, utilizando endereços IP {100,101}, configurados em run-time. Os hosts saturno, marte, jupiter, mercurio e venus estão autorizados a iniciar o serviço de gateway se algum dos servidores que corre o serviço avariar. 17

19 Os são pedidos para os backends jupiter, mercurio e venus ( {4-6}), que correm o Apache. Assume-se que o Apache é iniciado manualmente. Nos cenários seguintes veremos como configurar o Eddie para gerir os BES. saturno marte jupiter mercurio venus plutao Front End Server (Gateway) Back End Server (Apache) Enhanced DNS Server Fail-over set router Figura 9: Um cluster simples /etc/eddie/eddie.mig: 1: DNSServer plutao.orbita.pt : 3: <Node eddie@saturno> 4: Interfaces eth0 5: LoadThreshold : </Node> 7: 8: <Node eddie@marte> 9: Interfaces eth0 10: LoadThreshold : </Node> 12: 13: <Node eddie@jupiter> 14: Interfaces eth0 15: LoadThreshold : </Node> 17: 18: <Node eddie@mercurio> 19: Interfaces eth0 20: LoadThreshold : </Node> 22: 23: <Node eddie@venus> 24: Interfaces eth0 25: LoadThreshold : </Node> 27: Aqui configuramos o sistema de forma a informar o servidor DNS acerca da carga de cada um dos 5 nós. Na directiva Node especificamos os interfaces disponíves em cada nó, bem como o seu valor óptimo. 18

20 Se um nó pára, endereços IP e gateways são automaticamente migrados para um nó de backup. Esta funcionalidade envolve reconfigurações dos interfaces em run-time, de forma a que estes possam lidar com vários endereços IP (através de IP aliasing), alterando tabelas de roteamento e caches ARP. Um nó pode ter vários interfaces para atingir um maior grau de disponibilidade. 28: Netmask : 30: <Cluster www-100.orbita.pt> 31: ClusterType Frontend 32: FailoverNodes eddie@saturno \ 33: eddie@marte \ 34: eddie@jupiter \ 35: eddie@mercurio \ 36: eddie@venus Um cluster frontend pode, opcionalmente, especificar um determinado número de fail-over nodes. A directiva FailoverNodes especifica para onde deve ser efectuada a migração de endereços IP se o nó de origem parar. O conjunto de fail-over nodes pode ser maior do que o conjunto de nós que normalmente servem de frontends. Essa configuração chama-se active/standby. Se o conjunto de fail-over nodes for tão grande ou menor do que o conjunto dos nós que os frontends normalmente correm, então temos uma configuração active/active. Neste cenário os gateways correm em eddie@saturno e eddie@marte. 37: BackendClusters 38: A directiva BackendClusters especifica quais os clusters do tipo backend que este frontend utiliza. Esta informação é usada pelos algoritmos de balanceamento de carga do Eddie. Vários backend clusters podem ser definidos nesta directiva. 39: <Server eddie@saturno> 40: AutoConfig On 41: Interface eth0 42: IPAddress : Port 80 44: Start generic module http11 45: Stop generic module http11 46: </Server> 47: Aqui especificamos que o Intelligent HTTP Gateway deverá correr em eddie@saturn, escutando no endereço na porta 80, utilizando o interface eth0. A directiva AutoConfig está activada, permitindo ao Eddie gerir a configuração do endereço IP. Se outro nó do fail-over set iniciar antes do eddie@saturno, configura o endereço IP e inicia o gateway. Quando, mais tarde, o eddie@saturno iniciar, irá apoderar-se do endereço IP e de todos os servidores que o escutam. Mais tarde veremos como usar o mesmo endereço IP em várias directivas. Para parar e arrancar o gateway, é utilizado, neste caso, um módulo de callback do Erlang, que se chama eddie. O primeiro argumento das directivas Start e Stop é um nó, que nos diz se o script de callback é para ser usado num nó especifico ou genericamente. Neste caso utilizamos generic que significa que o script de call-back pode ser utilizado em qualquer nó no fail-over set. Se os nós do fail-over set estivessem espalhados por diferentes sistemas operativos (por 19