\chapter{Cluster de Aplica��o}
\label{clusteraplicacao}
\cutname{clusteraplicacao.html}
Um cluster de aplica��o � um conjunto de servidores que respondem coletivamente por um servi�o. Esse conjunto de servidores pode dividir entre si a carga do sistema, ou simplesmente aguardar um dos servidores falhar para assumir o servi�o. Esta tecnologia tem sido muito utilizada na Internet, como em sites de portais, e-commerce, e-business, abrangendo desde situa��es onde � necess�rio tratar milhares de requisi��es simult�neas, at� a demanda do servi�o que exige 99.99\% do tempo on-line por exemplo.

Clusters de aplica��o, em geral, s�o tecnologias maduras e est�veis para serem utilizadas. E se subdividem basicamente em 2 grupos:

\begin{itemize}
\item Alta disponibilidade;
\item Balanceamento de carga;
% \item Aplica��es WEB.
\end{itemize}


Neste cap�tulo ser�o descritas tecnologias que executam ou prestam suporte para a obten��o destas caracter�sticas.
\newpage

%sess�o LVS
\input{parte3/lvs.tex}

\input{parte3/tomcat.tex}

\section{Heartbeat}
\label{heartbeat}
% \cutname{heartbeat.html}
% \url{http://www.linux-ha.org/}
O \textit{High Availability Linux Project\footnote{s�tio do projeto: \www{http://www.linux-ha.org/}}} (Projeto Alta Disponibilidade Linux) tem por objetivo desenvolver solu��es para GNU/Linux que promovam confiabilidade, disponibilidade e suportabiidade (\textit{serviceability}) atrav�s do esfor�o de uma comunidade de desenvolvimento.

O \textit{Heartbeat}, fruto deste projeto, � um \textit{software} que gerencia falhas de recursos entre dois computadores, procurando eliminar pontos �nicos de falhas aumentando a disponibilidade do sistema formado por estes computadores. O principio de funcionamento � o de \textit{heartbeat} (o conceito n�o se resume ao \textit{software}), onde um componente de um sistema de alta disponibilidade � respons�vel por monitorar os servi�os do sistema trocando mensagens entre os servidores para verificar se ainda est�o ativos.

Normalmente o \textit{Heartbeat} trabalha com os conceitos de servidor prim�rio e secund�rio, ou seja, um servidor que de fato atende a demandas (prim�rio) e outro que fica em espera para assumir os servi�os caso algo de errado aconte�a ao prim�rio. Neste ambiente, um intervalo de tempo para troca de mensagens entre os servidores � especificado; caso n�o haja troca de mensagens, o \textit{Heartbeat} entende que o prim�rio est� fora do ar; assumindo assim o servidor secund�rio os servi�os que eram disponibilizados.

Para verifica��o do estado de cada n�, o \textit{Heartbeat} pode usar uma ou mais conex�es f�sicas, podendo ser a conex�o \textit{ethernet} normal para comunica��es de rede, interfaces dedicadas ligadas por cabo \textit{crossover} ou atrav�s de cabo serial. A conex�o normal de rede n�o � recomendada por conta do tr�fego de dados das aplica��es que ela suporta, sendo ideal o uso de interfaces dedicadas ligadas por \textit{crossover} ou mesmo cabo serial, que � uma boa op��o pela simplicidade e seguran�a e tamb�m por ser usada apenas para esse fim.


\section{Zope Cluster}
\label{zope}
% \cutname{zope.html}

H� uma rela��o n�o linear entre o aumento de acesso a um servidor WEB e seu tempo de resposta �s requisi��es. O uso de uma m�quina mais poderosa geralmente n�o � a resposta para o problema. Uma solu��o � usar mais de um servidor para realizar o trabalho e distribuir as requisi��es de servi�os entre eles.

Normalmente, um sistema que produz p�ginas din�micas � chamado servidor de aplica��o, que � composto, tipicamente, por tr�s partes distintas: um servidor HTTP, um banco de dados e alguma aplica��o (\textit{middleware}) que serve de interface aos outros dois componentes. Estas tr�s partes podem estar todas em uma mesma m�quina para o caso de sistemas que n�o se espera muita carga. Para o caso de sistemas com alta carga, os diferentes requisitos de cada componente sugerem separa��o para \textit{hardware} adequadamente ajustado para atender �s suas necessidades.

Zope � uma solu��o que integra um servidor Web (\textit{ZServer}), \textit{middleware} e um servidor de dados (ZODB) em um �nico pacote. Como parte desta solu��o, Zope pode emular a separa��o entre o servidor WEB e o servidor de dados atrav�s de ZEO (\textit{Zope Enterprise Objects}).

ZEO � uma parte do sistema Zope que permite que um \textit{Zope Object Database} seja compartilhado entre mais de um processo Zope. Com o uso de ZEO, pode-se rodar m�ltiplas inst�ncias de Zope em um �nico computador ou em v�rios computadores, acrescentando escalabilidade ao sistema, j� que, para atender ao poss�vel (e muito prov�vel) aumento de demanda, mais m�quinas podem ser acrescentadas ao sistema, al�m do aumento de confiabilidade, caso uma m�quina apresente problemas as outras ativas poder�o atender a requisi��es at� que a falha seja resolvida.

Os servidores Zoe (inst�ncias do Zope) que servem a aplica��o aos clientes (da Internet ou Intranet) s�o chamados de clientes nesta arquitetura j� que acessam o servidor de aplica��o.

Os clientes e servidores ZEO se comunicam atrav�s de TCP/IP, o que permite que eles sejam distribu�dos, inclusive, geograficamente, sendo capaz de gerenciar uma grande quantidade de requisi��es simult�neas, a partir de \textit{hardware} de baixo custo. A �nica ressalva em rela��o a esta arquitetura e que n�o h� mecanismos de redund�ncia nativa do ZODB (servidor de armazenamento). Isso pode ser resolvido com o uso de \textit{hardware} especializado (sistemas de armazenamento externo) ou com dispositivo de bloco como DRBD que pode ser usado para a replica��o do banco. Combinado com alguma ferramenta de monitoramento (\textit{Heartbeat} ou \textit{Keepalived}), pode-se conseguir redund�ncia para o servidor de armazenamento com o uso de \textit{hardware} n�o especializado.

Nativamente n�o h� suporte a balanceamento de carga no Zope, sendo necess�rio o uso de ferramentas externas. V�rios m�todos podem ser utilizados para distribuir as requisi��es dos clientes entre os servidores ZOE, como DNS \textit{round-robin}, o m�dulo mod\_proxy do servidor http Apache ou \textit{switch} de camada 4, sendo o LVS o mais conhecido deles.

Uma solu��o, para o caso de servidores de p�ginas est�ticas, � usar DNS \textit{round-robin} para distribuir as requisi��es recebidas por uma URL entre v�rios IP�s de uma rede interna, sendo cada nova requisi��o enviada para um servidor diferente da anterior. Sendo id�ntico o conte�do de todos os servidores, esse processo � transparente para o usu�rio. Contudo, esta � uma solu��o atraente por sua simplicidade entretanto apresenta seus reveses; por exemplo, arquivos de diferentes tamanhos geram eventualmente mais carga para alguns servidores que para outros. Outro problema � que o servidor DNS do cliente pode fazer \textit{cache} do endere�o IP acessado e usar� este mesmo dado para uma consulta futura.

\begin{figure}[!htb]
\centering
\insimg{0.45}{imagens/dnszope.png}
\caption{DNS round-robin}
\label{fig:dnszope}
\end{figure}

O DNS \textit{round-robin} � uma maneira de se resolver um nome para v�rios endere�os IP fazendo uso do servidor de DNS para realizar a fun��o de balanceamento de carga, sem o uso de uma m�quina dedicada para isso. O servidor DNS resolve www.dominiozope.com, por exemplo, para os endere�os IP de ZEO Server1, ZEO Server2 e ZEO Server3 para os clientes 1, 2 e 3, respectivamente.

Outra solu��o � o uso de balanceamento de carga din�mico, tamb�m tratado como roteador de camada 4. Neste caso um endere�o especifico � resolvido para apenas um IP que pertence ao roteador que por sua vez, transparentemente, redireciona as conex�es para um grupo de servidores em cluster. Preferencialmente, estes servidores possuem a capacidade de informar sobre sua carga de trabalho ao roteador, que depois de obter essa informa��o decide a qual servidor enviar uma nova requisi��o. Uma solu��o em \textit{software} muito utilizada para isso � o LVS, parte integrante do kernel Linux que o transforma em um \textit{switch} de camada 4.

O outro problema da arquitetura de cluster Zope � a falta de redund�ncia nativa do servidor de armazenamento. Uma maneira de se retirar esse ponto de falha, al�m do uso de \textit{hardware} especializado, � o uso conjugado de DRBD, OCFS2, \textit{Heartbeat} ou \textit{Keepalived} e LVS. O uso de DRBD (vers�o 0.8 ou superior) pode ser usado com OCFS2 para se criar um dispositivo que possa ser acessado por duas m�quinas com inst�ncias ZODB lendo e escrevendo ao mesmo tempo. \textit{Heartbeat} ou \textit{Keepalived} verifica o estado de sanidade dessas m�quinas, tomando providencias necess�rias (rein�cio, notifica��o administrativa) caso haja algum problema. O LVS, que pode ser usado como balanceador de carga de requisi��es clientes, pode tamb�m balancear a carga dos ZEO clientes quando acessarem os servidores ZODB.

\begin{figure}[!htb]
\centering
\insimg{0.5}{imagens/zopelvsdrbd.png}
\caption{ZEO/ZODB + LVS+OCFS2}
\label{fig:zopelvsdrbd}
\end{figure}







%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% H� uma rela��o n�o linear entre o aumento de acesso a um servidor web e seu tempo de resposta �s requisi��es. O uso de uma m�quina mais poderosa geralmente n�o � a resposta para o problema. Uma solu��o � usar mais de um servidor para realizar o trabalho e distribuir as requisi��es de servi�os entre eles.
% 
% Uma solu��o, para o caso de servidores de p�ginas est�ticas, � usar DNS round-robin para distribuir as requisi��es recebidas por uma URL entre v�rios IP�s de uma rede interna, sendo cada nova requisi��o enviada para um servidor diferente da anterior. Sendo id�ntico o conte�do de todos os servidores, esse processo � transparente para o usu�rio. Contudo, esta � uma solu��o atraente por sua simplicidade entretanto apresenta seus reveses. Por exemplo, arquivos grandes carregaram mais um servidor que esteja atendendo � sua requisi��o, gerando eventualmente mais carga para alguns servidores que para outros. Outro problema � que o servidor DNS do cliente pode fazer \textit{cache} do endere�o IP acessado e usar� este mesmo dado para uma consulta futura.
% 
% Outra solu��o � o uso de balanceamento de carga din�mico, tamb�m tratado como roteador de camada 4. Neste caso um endere�o especifico � resolvido para apenas um IP que pertence ao roteador que por sua vez, transparentemente, redireciona as conex�es para um grupo de servidores em cluster. Preferencialmente, estes servidores possuem a capacidade de informar sobre sua carga de trabalho ao roteador, que depois de obter essa informa��o decide a qual servidor enviar uma nova requisi��o.
% 
% Normalmente, um sistema que produz p�ginas din�micas � chamado servidor de aplica��o, que � composto, tipicamente, por tr�s partes distintas: um servidor HTTP, um banco de dados e alguma aplica��o (middleware) que serve de interface aos outros dois componentes. Estas tr�s partes podem estar todas em uma mesma m�quina para o caso de sistemas que n�o se espera muita carga. Para o caso de sistemas com alta carga, os diferentes requisitos de cada componente sugerem separa��o para que \textit{hardware} adequadamente ajustado para atender �s suas necessidades.
% 
% Zope � uma solu��o que integra um servidor Web (ZServer), middleware (ZPublisher) e um servidor de dados (ZODB) em um �nico pacote. Como parte desta solu��o, Zope pode emular a separa��o entre o servidor Web e o servidor de dados atrav�s de ZEO (Zope Enterprise Objects). ZEO permite que v�rias inst�ncias de Zope rodem a partir de v�rios servidores e compartilhem a mesma base de dados, usando uma arquitetura cliente/servidor, sendo que cada inst�ncia de Zope � um cliente e todos estes acessam o mesmo servidor de armazenamento.
% 
% Os clientes e servidores ZEO se comunicam atrav�s de TCP/IP, o que permite que eles sejam distribu�dos, inclusive, geograficamente, sendo capaz de gerenciar uma grande quantidade de requisi��es simult�neas, a partir de \textit{hardware} de baixo custo.

% \section{Alta-Disponibilidade}
% 
% Num cluster de alta disponibilidade, existem dois ou mais servidores, onde um servidor (MASTER) est� respondendo por um servi�o e se comunicando com outros servidores (BACKUP) que ficam inativos, esperando o servidor MASTER falhar para assumir as requisi��es. Dessa forma � poss�vel conseguir um alto n�vel de disponibilidade, com servidores de \textit{hardware} 'comodity'. Principal Desvantagem � a ociosidade do servidor de Backup, que fica inativo enquanto o servidor master estiver funcionando corretamente.
%  Algumas das maneiras de se realizar esse tipo de sistema s�o apresentadas abaixo:
%  
% \begin{itemize}
% \item Protocolo tcp/ip: HSRP (Roteadores CISCO), VRRP (Keepalived), CARP (www.ucarp.org).
% \item Sistema de Heartbeat: Heartbeat + mon.
% \end{itemize}
% 
% 
% \section{Balanceamento de Carga (Load Balance)}
% 
% \begin{itemize}
% 
% \item Balanceamento via DNS : um dos primeiros e mais utilizados m�todos de balanceamento, pouco din�mico, sem capacidade de detectar a falha de algum servidor, somente dois algoritmos de balanceamento poss�veis: Round Robin e Weighted Round Robin, simples de ser implementado.
% 
% \item Balanceamento em camada TCP/IP: Principal representante: Linux Virtual Server e IPVS, realiza o balanceamento de conex�es TCP/IP e UDP (s�o consideradas ``conex�es"~ UDP pacotes enviados por um mesmo ip para um mesmo destino num intervalo de tempo definido.), v�rios algoritmos de balanceamento foram implementados para atender as mais diversas demandas, no ipvs os algoritmos de balanceamento s�o m�dulos diferentes do m�dulo central do ipvs, dessa forma � poss�vel implementar novos algoritmos de balanceamento de carga sem afetar o funcionamento do sistema como um todo. Principal vantagem: MUITO ESCAL�VEL, algoritmos prontos para atender muitos tipos de demandas de balanceamento, interoper�vel - Pode ser utilizado para fazer o balanceamento de carga de qualquer aplica��o TCP/IP em qualquer tipo de sistema operacional. � necess�rio levar em considera��o a especializa��o de cada aplica��o, bem como a sincroniza��o das informa��es entre as aplica��es precisam ser tratadas. Desvantagem: Como faz o balanceamento no Layer-4, n�o guarda nenhuma informa��o de sess�o ou do layer-6 e layer-7 (OSI).
% 
% \item Balanceamento na pr�pria aplica��o. Nesse caso o balanceamento de carga � feito na pr�pria aplica��o, alguns exemplos de aplica��es que suportam esse tipo de balanceamento: Tomcat e JBoss (java), Zope (python), Apache, etc. Principal vantagem: O balanceamento � realizado ao n�vel de sess�o, o que permite uma melhor distribui��o e controle dos acessos dos usu�rios e integridade das sess�es.
% \item  Balanceamento de Conte�do: Balanceamento e distribui��o de carga na camada OSI 7. Existem switches de conte�do que realizam esse tipo de opera��o, e tamb�m existe uma implementa��o no kernel KTCPVS que realiza esse tipo de balanceamento para HTTP e HTTPS. http://www.linuxvirtualserver.org/software/ktcpvs/ktcpvs.html
% \end{itemize}
% 
% \section{Balanceamento de Carga e Alta Disponibilidade ( LB + HA )}
% 
% Nesse tipo de cluster o objetivo � se atingir as vantagens da alta disponibilidade, com a escalabilidade do balanceamento de cargas. Tratar ``10 a 100 milhares de conex�es"~ simult�neas entre servidores distintos, de forma que a falha de qualquer servidor n�o interrompa ou prejudique a execu��o do servi�o.
% Normalmente uma solu��o desse tipo � a combina��o de diversas solu��es de LB e HA.
%  exemplos: 
% \begin{itemize}
% \item  LVS + HEARTBEAT + MON
% \item  LVS + HEARTBEAT + LDIRECTORD
% \item  http://www.linuxvirtualserver.org/HighAvailability.html
%  \end{itemize}
% 
% 
% \section{Aplica��es WEB}
% mais o que que eu vou falar la em casa ???
% lvs, tomcat, jboss, sequoia
