\newpage
%===========================================================================
%       x.9 > Clusters HA
%===========================================================================
\pagestyle{empty}
\begin{latexonly}
\ifpdf
 \begin{figure}[htbp]
%      \includegraphics[bb = -250 220 0 0, scale=1]{./TuXes/tux-net.jpg}
 \end{figure}
 \vspace{5in}
\else
 \begin{figure}
%      \includegraphics[-275,650][0,0]{./TuXes/tux-net}
 \end{figure}
\fi
\hfill\line(1,0){400}
\end{latexonly}
\topmargin 1in
\section{CLUSTERS HA}
\begin{latexonly}
\line(1,0){400}
\newpage
\end{latexonly}
\topmargin 0in
\pagestyle{fancy}
%========================cita===============================================
\begin{latexonly}
\hspace{1in}\textcolor{blue_omosix}{{\em Just in terms of allocation of time resources, religion is not very efficient.}}

\hspace{1in}\textcolor{blue_omosix}{{\em There's a lot more I could be doing on a Sunday morning.}}

\hspace{4in}\textcolor{blue_omosix}{{\footnotesize otra muestra de inteligencia de }{\em Bill Gates}}
\vspace{0.5in}
\end{latexonly}
%===========================================================================
\subsection{Introducci\'on}
Los clusters HA estan dise\~{n}ados especialmente para dar un servicio de alta disponibilidad.
 Esto tiene muchas aplicaciones en el mundo actual donde existen gran cantidad
 de servicios inform\'aticos que debe funcionar 24x7x365.
 Estos clusteres son una alternativa real a otros sistemas usados
 tradicionalmente para estas tareas de hardware redundante que son
 mucho m\'as caros, por ejemplo los ordenadores Tandem.
%===========================================================================
\subsection{El inter\'es comercial}
Desde ya hace unos a~{n}os Heartbeat est\'a en las distribuciones SuSE, Conectiva y Mandrake;
 incluso Mission Critical Linux se ha interesado en \'el.
 Todo esto es as\'\i\  porque el mercado de clusters HA es un mercado con muchos
 potenciales clientes y, lo que es quiz\'as m\'as importante, para los
 intereses comerciales de muchas empresas.

Pi\'ensese como ejemplo una empresa de grandes almacenes que tiene ordenadores
 car\'\i simos validando las operaciones de tarjeta de cr\'edito. Estos ordenadores
 no deben cancelar el servicio nunca porque si lo hicieran todo el sistema de tarjetas de
 cr\'editos se vendr\'\i a abajo, con lo que se podr\'\i an ocasionar
 grandes p\'erdidas econ\'omicas.
 
Por todo esto se desarrollan proyectos que intentan conseguir esta
 disponibilidad pero no gracias a un soporte hardware car\'\i simo,
 sino usando clusters.
 Las empresas que necesitan alta disponibilidad suelen pagar a la empresa
 que le ofrece este servicio aun cuando los programas sean de libre distribuci\'on,
 quieren unas garant\'\i as.
 Esto est\'a haciendo que muchas empresas est\'en colaborando en proyectos libres
 de HA, cosa que no deja de ir en pro de la mejora del
 software en cuesti\'on.
 
\vspace{.2in}
Las enormes diferencias entre el precio del hardware de las soluciones
 tradicionales y estas nuevas soluciones hacen que las empresas tengan un
 buen margen de beneficio dando un servicio de soporte.

Es bastante obvio por qu\'e estos clusters estan m\'as solicitados que los de alto
 rendimiento (HP):
 la mayor\'\i a de las empresas se pueden permitir en cierto modo m\'aquinas potentes
 que les solucionen las necesidades de c\'omputo, o simplemente contar con el tiempo suficiente
 para que sus actuales equipos procesen toda la informaci\'on que necesitan.
 En la mayor\'\i a de los casos el tiempo no es un factor cr\'\i tico y por tanto
 la velocidad o la capacidad de c\'omputo de las m\'aquinas no es importante.
 Por otro lado, que se repliquen sistemas de
 archivos para que est\'en disponibles, o bases de datos, o servicios
 necesarios para mantener la gesti\'on de la empresa en funcionamiento, o
 servicios de comunicaci\'on interdepartamental en la empresa y otros servicios,
 son realmente cr\'\i ticos para las empresas en todos y cada uno de los d\'\i as
 en los que estas est\'an funcionando (e incluso cuando no est\'an funcionando).
%===========================================================================
\subsection{Conceptos importantes}
Un buen cluster HA necesita proveer fiabilidad, disponibilidad y
 servicio RAS (explicado m\'as adelante). Por tanto debe existir una forma de saber cu\'ando un servicio ha ca\'\i do
 y cu\'ando vuelve a funcionar.

Esto se puede conseguir de dos maneras, por hardware y por software.
 No se van a tratar aqu\'\i\  los mecanismos que existen para
 conseguir alta disponibilidad por hardware, pues est\'an m\'as all\'a
 de los objetivos de este documento. Baste decir que construir estos ordenadores es muy caro pues necesitan
 gran cantidad de hardware redundante que est\'e ejecutando paralelamente
 en todo momento las mismas operaciones que el hardware principal (por ejemplo
 una colecci\'on de placas base) y un sistema para pasar el control o
 la informaci\'on del hardware con errores a hardware que se ejecute
 correctamente. 

\vspace{.2in}
Los clusters HA solucionan el problema de la disponibilidad con una buena
 capa de software.
 Por supuesto mejor cuanto m\'as ayuda se tenga del hardware: UPS, redes \'opticas, etc.
 Pero la idea tras estos sistemas es no tener que gastarse millones de euros
 en un sistema que no puede ser actualizado ni escalado.
 Con una inversi\'on mucho menor y con software dise\~{n}ado espec\'\i ficamente
 se puede conseguir alta disponibilidad.
 
Para conseguir la alta disponibilidad en un cluster los nodos tienen
 que saber cu\'ando ocurre un error para hacer una o varias de las siguientes
 acciones:
\begin{itemize}
  \item {\bf Intentar recuperar los datos del nodo que ha fallado.}

 Cuando un nodo cae hay que recuperar de los discos duros compartidos por
 los nodos la informaci\'on para poder seguir con el trabajo.
 Generalmente hay {\em scripts} de recuperaci\'on para intentar recuperarse del fallo.
 
  \item {\bf Continuar con el trabajo que desempe\~{n}aba el nodo ca\'\i do.}

 Aqu\'\i\  no se intenta recuperar del fallo sino que cuando se descubre que ocurri\'o
 un fallo otro nodo pasa a desempe\~{n}ar el puesto del nodo que fall\'o.

Esta es la opci\'on que toma por ejemplo Heartbeat: permite que 2 ordenadores
 mantengan una comunicaci\'on por un cable serie o Ethernet, cuando
 un ordenador cae el ordenador que no recibe respuesta
 ejecuta las \'ordenes adecuadas para ocupar su lugar.
\end{itemize}
Las ventajas de escalabilidad y econom\'\i a de los clusters tienen
 sus desventajas. Una de ellas es la seguridad.
 Cuando se dise\~{n}a un cluster se busca que haya ciertas facilidades de comunicaci\'on
 entre las estaciones y en clusters de alta disponibilidad el traspaso
 de informaci\'on puede ser muy importante.

Recordando el ejemplo anterior de las tarjetas de cr\'edito, se ha
 visto que se podr\'\i a crear un cluster de alta disponibilidad que
 costara varias veces menos que el ordenador centralizado. El problema
 podr\'\i a sobrevenir cuando ese cluster se encargara de hacer operaciones con los
 n\'umeros de las tarjetas de cr\'edito y transacciones monetarias de
 la empresa. Las facilidades de comunicaci\'on
 podr\'\i an ocasionar un grav\'\i simo problema de
 seguridad. Un agente malicioso podr\'\i a  hacer creer al cluster que
 uno de los nodos ha ca\'\i do, entonces podr\'\i a aprovechar el
 traspaso de la informaci\'on de los nodos para conseguir
 los n\'umeros de varias tarjetas de cr\'edito.

Este es uno de los motivos por los que, en seg\'un qu\'e entornos, estos sistemas
 no se hayan implantado. 
%---------------------------------------------------------------------------
\subsubsection{Servicio RAS}
En el dise\~{n}o de sistemas de alta disponibilidad es necesario obtener la suma
 de los tres t\'erminos que conforman el acr\'onimo RAS.
\begin{itemize}
  \item {\bf Reliability.}

El sistema debe ser confiable en el sentido de que \'este act\'ue realmente
 como se ha programado. Por un lado est\'a el problema de coordinar el
 sistema cuando \'este est\'a distribuido entre nodos,
 por otro lado hay el problema de que todo el software que integra el
 sistema funcione entre s\'\i\ de manera confiable.

En general se trata de que el sistema pueda operar sin ning\'un tipo de ca\'\i da
 o fallo de servicio.

  \item {\bf Availability.}

Es l\'ogicamente la base de este tipo de clusters.
 La disponibilidad indica el porcentaje de tiempo que el sistema esta disponible
 en su funcionalidad hacia los usuarios.

  \item {\bf Serviceability.}

Referido a c\'omo de f\'acil es controlar los servicios del sistema y qu\'e
 servicios se proveen, incluyendo todos los componentes del sistema.
\end{itemize}
La disponibilidad es el que prima por encima de los anteriores.
 La disponibilidad de un sistema es dependiente de varios factores. Por
 un lado el tiempo que el sistema est\'a funcionando sin problemas, por otro
 lado el tiempo en el que el sistema esta fallando y por \'ultimo el tiempo
 que se tarda en reparar o restaurar el sistema.

Para medir todos estos factores son necesarios fallos.
 Existen dos tipos de fallos: los fallos que provocan los
 administradores (para ver o medir los tiempos de recuperaci\'on y tiempos
 de ca\'\i das) y los fallos no provocados, que son los que demuestran que los
 tiempos de reparaci\'on suelen ser mucho m\'as grandes de los que se estim\'o
 en los fallos provocados.

La naturaleza de los fallos puede afectar de manera diferente al sistema: pudiendolo ralentizar,
inutilizar o para algunos servicios.
%---------------------------------------------------------------------------
\subsubsection{T\'ecnicas para proveer de disponibilidad}
Cualquier t\'ecnica deber\'a, por definici\'on, intentar que tanto el tiempo de fallo del sistema
 como el tiempo de reparaci\'on del mismo sean lo m\'as peque\~{n}os posibles.

Las que tratan de reducir el tiempo de reparaci\'on se componen a base de {\em scripts} o programas que detectan el fallo del sistema y tratan de recuperarlo sin necesidad de un t\'ecnico
 especializado.
 En general son t\'ecnicas de automatizaci\'on de tareas basadas en sistemas
 expertos (SE).
 Al reducir el tiempo de recuperaci\'on, el sistema puede no solamente funcionar
 activamente sin fallos durante m\'as tiempo, sino que tambi\'en se aumenta su confiabilidad.

\vspace{.2in}
{\bf {\em i.-} T\'ecnicas basadas en redundancia}

Por un lado hay las t\'ecnicas basadas en reducir el tiempo de fallo o
 ca\'\i da de funcionamiento, estas t\'ecnicas se basan principalmente en efectuar
 alg\'un tipo de redundancia sobre los dispositivos cr\'\i ticos.
 Saber cu\'ales son estos dispositivos suele ser cuesti\'on de conocimiento
 acerca del sistema y de sentido com\'un.

Las t\'ecnicas basadas en la redundancia de recursos cr\'\i ticos permiten que
 cuando se presenta la ca\'\i da de uno de estos recursos, otro tome
 la funcionalidad. Una vez
 esto sucede el recurso maestro puede ser reparado mientras que el
 recurso {\em backup} toma el control. Entre los tipos de redundancia que pueden presentar los
 sistemas hay:
\begin{itemize}
  \item \underline{Redundancia aislada.}

Es la redundancia m\'as conocida donde existen 2 copias para dar
 una funcionalidad o servicio.
 Por un lado hay la copia maestro y por otro lado la copia esclavo.
 Cuando cae el servicio o recurso la copia redundante pasa a ser la utilizada,
 de esta manera el tiempo de ca\'\i da es m\'\i nimo o inexistente.

Los recursos pueden ser de cualquier tipo: procesadores,
 fuentes de alimentaci\'on, raids de discos, redes, im\'agenes de sistemas operativos...

Las ventajas son cuantiosas: para empezar no existen puntos cr\'\i ticos de
 fallo en el sistema, es decir, el sistema al completo no es tomado
 como un sistema con puntos de fallos que bajen la confiabilidad del mismo.
 Los componentes que han fallado pueden ser reparados sin que esto cause
 sobre el sistema una parada.

 Por \'ultimo, cada componente del sistema puede comprobar de manera peri\'odica
 si se ha producido alg\'un tipo de fallo en los sistemas de backup, de modo
 que se compruebe que \'estos est\'an siempre funcionales. Otra opci\'on es que
 adem\'as de comprobar, presenten habilidades para localizar fallos en sistemas
 y los intenten recuperar de manera automatizada.

  \item \underline{N-Redundancia.}

Es igual que la anterior pero se tienen {\tt N} equipos para ofrecer un mismo
 servicio, con lo cual presenta m\'as tolerancia a fallos.
\end{itemize}
As\'\i\ por ejemplo para dotar de sistema redundante a una red como la que muestra
 el esquema A de la figura deber\'\i a haber el doble de recursos necesarios
 para construirla, e implementarlos como en el sistema B.
\begin{latexonly}
\ifpdf
        \begin{figure}[htbp]
        \includegraphics[bb = -100 300 0 0, scale=.8]{./pics/redundancia.png}
        \vspace{3.2in}
        \caption{Clusters HA. Redundancia}
        \end{figure}
\else
\end{latexonly}
        \begin{figure}
        \centering
        \includegraphics{pics/redundancia}
        \caption{Clusters HA. Redundancia}
        \end{figure}
\begin{latexonly}
\fi
\end{latexonly}
En este caso se replicaron:
\begin{itemize}
  \item LAN
  \item LAN para los servidores
  \item Los servidores
  \item El bus SCSI de acceso a discos duros
  \item Discos duros
\end{itemize}
Como se puede ver la replicaci\'on proporciona rutas alternativas, discos
 alternativos y en general recursos alternativos, y es aplicada sobre todos
 aquellos recursos que se consideren cr\'\i ticos en una red.

\vspace{.2in}
Otro apartado a la hora de considerar la instalaci\'on de dispositivos redundantes
 es la configuraci\'on o el modelo de funcionamiento de los mismos.
 Depende de como se haya implementado el software y como se haya dispuesto el hardware
 y define el modo de comportamiento de la redundancia. Esta redundancia puede ser del tipo:
\begin{enumerate}
  \item {\bf Hot Standby.}

Este tipo de configuraci\'on es la que se ha visto hasta ahora.
 En cuando el nodo maestro cae existe un nodo backup que toma el control
 de sus operaciones.
 Hasta ahora no se ha tenido en cuenta un punto importante: el doble gasto en recursos
 que en un principio y si las cosas van bien se est\'an desperdiciando.

El servidor de backup simplemente monitoriza sus conexiones, la normal y la
 redundante en el caso de que esta exista, para asegurar que cuando el nodo
 maestro caiga tome correctamente el control de las operaciones.
 Exceptuando estas operaciones, el nodo backup no hace nada. 
 
  \item {\bf Toma de cargos mutua.}

La toma de cargos mutua es una configuraci\'on que soluciona la desventaja
 del apartado anterior.
 Mientras el nodo principal se ocupa de proveer de servicio, el nodo de
 backup hace las mismas operaciones que en apartado anterior y adem\'as puede
 efectuar otro tipo de operaciones.
 De este modo, la capacidad de este nodo se est\'a aprovechando m\'as que en
 el anterior y el costo del sistema se ve recompensado con un equipo m\'as
 que se utiliza para efectuar trabajo \'util.
 El problema est\'a cuando el nodo maestro cae.
 En este caso, el comportamiento del backup puede tomar dos v\'\i as.
 \begin{itemize} 
  \item la primera es mantener sus actuales trabajos y tomar los trabajos que el
 maestro ha dejado sin hacer.
 Esta manera de comportarse presenta una bajada de rendimiento del sistema
 cr\'\i tico, pero hace que este est\'e disponible.
 Depende del tipo de trabajo que se presente sobre el backup que ahora ha
 pasado a ser maestro el considerar la prioridad de que trabajos son m\'as
 cr\'\i ticos.

  \item la segunda opci\'on es dejar estos trabajos postergados hasta que el antiguo
 maestro sea reparado (lo cual puede ser hecho por el nodo de backup, es
 decir el nuevo maestro) y cuando \'este tome las tareas de backup, que contin\'ue
 con el trabajo que en un principio estaba efectuando \'el antes de tomar
 el control.
 
 Esta es una soluci\'on mucho m\'as elegante y m\'as dif\'\i cil de implementar.
 Presenta mejor rendimiento coste que la anterior.
 \end{itemize}

  \item {\bf Tolerante a fallos}

Los sistemas redundantes a fallos se basan en la N-Redundancia.
 Si se tienen {\tt N} equipos y caen {\tt N-1} el sistema sigue en funcionamiento.
 Este sistema se puede cruzar con la toma de cargos mutua para no perder
 rendimiento ni elevar el costo del sistema, sin embargo configurar un sistema
 de este tipo es bastante complejo a medida que aumenta {\tt N}.
\end{enumerate}

\vspace{.2in}
{\bf {\em ii.-} T\'ecnicas basadas en reparaci\'on}

Por otro lado est\'an las t\'ecnicas basadas en reducir el tiempo de reparaci\'on.
 Este tipo de t\'ecnicas se componen a base de scripts o programas que detectan
 donde fallo el sistema y tratan de recuperarlo sin necesidad de un t\'ecnico
 especializado.
 En general son t\'ecnicas de automatizaci\'on de tareas basadas en sistemas
 expertos.

Al reducir el tiempo de recuperaci\'on, el sistema puede no solamente funcionar
 activamente sin fallos m\'as tiempo, sino que tambi\'en aumentamos la confiabilidad.
 Se pueden separar en dos tipos de acciones que realizan que pueden ser
 independientes o dependientes entre si:
\begin{itemize}
  \item {\bf Diagn\'ostico.}

La parte de diagnosis simplemente trata de conocer las posibles causas que
 han provocado el error y principalmente localizar el error.

Una t\'ecnica muy utilizada en este campo es una especie de {\em
 piggybacking} aplicada a los pulsos o latidos entre ambos nodos.
 En esta t\'ecnica, se env\'\i a junto con el latido o pulso, la
 suficiente informaci\'on como para prever cual ser\'a el estado de
 los componentes en pr\'oximos tiempos o incluso actualmente, lo cual
 es una ventaja a la hora de saber en todo momento el estado del sistema.
 La implementaci\'on Heartbeat de Linux-HA hace una implementaci\'on muy coherente
 y correcta de esta t\'ecnica.

  \item {\bf Reparaci\'on.}

Son t\'ecnicas mediante las cuales a trav\'es de sistemas expertos o cualquier
 otro tipo de actuaci\'on, el sistema ca\'\i do puede llegar a ser restaurado desde
 una copia del sistema.
 En la mayor\'\i a de los casos basa su funcionamiento en puntos de comprobaci\'on
 o {\em checkpoints} que se efect\'uan sobre el sistema cada cierto
 tiempo, de manera que el servidor ca\'\i do es restaurado al \'ultimo {\em checkpoint} existente.
 Los puntos cr\'\i ticos de este apartado son:
  \begin {itemize}
    \item aislar los componentes que fallan y sustituirlos o repararlos.
 Los componentes que fallan pueden ser localizados mediante programas que
 implementen sistemas de comprobaci\'on o sistemas expertos.
    \item recuperaci\'on mediante puntos de comprobaci\'on o puntos de restauraci\'on.
    \item acoplamiento al cluster actual tomando las acciones que
 ten\'\i a el nodo backup e informando al nodo maestro de que ya existe un nuevo 
 backup en el sistema.
   \end{itemize}
Los puntos de comprobaci\'on son importantes ya que introducen un factor de
 sobrecarga en el sistema y al mismo tiempo son un factor cr\'\i tico a la hora
 de efectuar restauraciones del mismo.
 Un sistema al m\'aximo confiable deber\'\i a guardar el estado de todos los programas
 que est\'a corriendo y comunic\'arselos a su backup en tiempo real para que
 de este modo la ca\'\i da de uno guardase el estado del complementario.
 Ser\'\i an sistemas sim\'etricos.

Este tipo de sistemas solamente son implementados en hardware, ya que exigen
 medios de comunicaci\'on muy r\'apidos (aparte de la sobrecarga al procesador
 que genera estar controlando este tipo de labores).
 Los clusters implementan a un nivel mucho menos eficiente este tipo de
 {\em checkpoints}, y la eficiencia depende generalmente de la capacidad de los
 procesadores y de la capacidad de la red que une maestro y backups. Debido
 a esto los clusters solamente guardan configuraciones y servicios activos,
 pero no el estado de conexiones y dem\'as componentes que har\'\i an que un usuario
 externo observase la ca\'\i da del sistema de modo realmente transparente,
 como si este no existiese.
 
 Esta es una de las grandes diferencias entre entornos de alta disponibilidad
 y entornos de alta confiabilidad, de los cuales
 no se ha visto ninguno implementado debido a que la tecnolog\'\i a actual
 los hace inviables.

Existen varias maneras de efectuar el punto de comprobaci\'on. Por ejemplo
 en los sistemas implementados a nivel de kernel o sistema, el sistema operativo
 se encarga de efectuar este de manera completamente transparente al usuario
 o administrador.
 En los sistemas a nivel de aplicaci\'on son generalmente las bibliotecas
 de funciones las que proveen de estas caracter\'\i sticas.

Otro factor a tener en cuenta acerca de los checkpoints, que marca el rendimiento
 del sistema, es su intervalo. \'Este debe ser \'optimo:
 no crear congesti\'on y permitir copias de restauraci\'on lo suficientemente
 actuales como para que los servicios cuenten con la m\'axima disponibilidad.
 En ocasiones, cuando el checkpoint es muy grande puede provocar congestiones.
 En cualquier caso, el principal problema de un checkpoint es la informaci\'on
 que necesita para hacer la colaboraci\'on eficiente, y esto como hemos visto
 depende siempre del tipo de sistemas.
 
Como \'ultima caracter\'\i stica de los checkpoints, hacer una peque\~{n}a menci\'on
 en los sistemas con m\'as de un nodo de redundancia, en los cuales se pueden
 imaginar dos modos l\'ogicos de hacer los checkpoints: 
  \begin{enumerate}
    \item Como checkpoints aislados, donde cada nodo se encarga de
 hacer los checkpoints de otro nodo al que replica cada intervalo de
 tiempo o por una pol\'\i tica propia del sistema (puede caer en el denominado efecto domino, en el cual
 se guardan copias de sistema que no corresponden con el estado actual de
 los nodos).
    \item Frente a los checkpoints en grupo o checkpoints organizados, en los cuales
 todos los nodos se ponen de acuerdo para hacer un sistema de checkpoints
 efectivo.
 A cambio requiere m\'as dificultad de implementaci\'on, y quiz\'a sobrecarga
 del sistema.
  \end{enumerate}
\end{itemize}
%===========================================================================
\subsection{Soluciones libres}

\vspace{.2in}
{\bf Linux-HA}

Este es el mayor proyecto de software libre de clusters HA que existe, parte
 de este proyecto es Heartbeat y trabajan conjuntamente con
 el grupo encargado de LVS.

Han desarrollado varias aplicaciones comerciales sobre este proyecto
 y se est\'a utilizando en varios servicios con \'exito.
 Como parte de los objetivos que se persiguen se encuentran:
\begin{itemize}
  \item {\em Servicios de membership.}

Estos servicios permiten a\~{n}adir y quitar miembros
 a un cluster. El problema es que la llegada de un miembro a un cluster orientado a estados
 puede hacer cambiar de estado a todo el cluster (esto suele ser lo que
 ocurre en este tipo de clusters) con lo que se env\'\i an demasiados paquetes
 de sobrecarga demasiado a menudo por tanto ante esto se plantean soluciones como
 clusteres jer\'arquicos. Es la soluci\'on que dentro de Linux-HA ha
 sido apoyada por Stephen Tweedie.

  \item {\em Servicios de comunicaci\'on.}

Comunicar informaci\'on cr\'\i tica de forma que una
 ca\'\i da en un sistema no haga que se pierda la informaci\'on y a la vez enviar
 la informaci\'on de una forma suficientemente segura para evitar posibles
 ataques externos.
 Como se ha visto esto es especialmente importante en clusters HA.
 
  \item {\em Manejo del cluster.}

Una serie de servicios que hagan sencillo el manejo
 del cluster en general y de los nodos y procesos en particular.
 Al igual que un sistema operativo provee de servicios para
 administrarlo, un cluster tambi\'en debe proveer de instrucciones
 para gestionar su funcionamiento.

  \item {\em Monitorizaci\'on de los recursos.}

Este punto est\'a muy unido al anterior. Para
 que el administrador detecte prematuramente posibles fallos y pueda ver
 qu\'e ocurre en el cluster necesita algunas facilidades de monitorizaci\'on.
 Por supuesto estos dos puntos no son exclusivos de los clustersHA ni del
 proyecto Linux-HA sino que son necesarios en todos los clusters.
 
  \item {\em Replicaci\'on y/o compartici\'on de datos.}

Para conseguir que los datos que
 estuviera modificando uno de los nodos no se pierda cuando caiga se puede
 replicar la informaci\'on y/o mantenerla en lugares
 compartidos por todos los nodos con lo que cualquier nodo podr\'\i a continuar
 con los datos compartidos.

 Para conseguir tener unos discos compartidos se necesita un hardware caro
 como es SCSI y fibra \'optica.

 La replicaci\'on de informaci\'on no necesita un hardware caro (solamente una
 red tan r\'apida como el coste permita) pero se necesita mantener un equilibrio entre
 los periodos de actualizaci\'on de las copias y el uso de la red.
 Un cluster HA no suele necesitar demasiado ancho de banda por lo que se
 puede dedicar gran parte para este uso.
\end{itemize}

\vspace{.2in}
{\bf HeartBeat }

Esta tecnolog\'\i a implementa {\em heartbeats}, cuya traducci\'on directa ser\'\i a {\em latidos
de coraz\'on}. Funciona enviando peri\'odicamente un paquete que si
no llegara indicar\'\i a que un servidor no est\'a disponible, por lo
tanto se sabe que el servidor ha ca\'\i do y se toman las medidas
necesarias.

Dichos {\em latidos} se pueden enviar por una linea serie, por UDP o por PPP/UDP.
 De hecho los desarrolladores de Heartbeat recomiendan el uso de puertos
 serie por varias razones, entre las que destacan que est\'an aislados de las
 tarjetas de red.

Tambi\'en incluye toma de una direcci\'on IP y una modelo de recursos incluyendo
 grupos de recursos.
 Soporta m\'ultiples direcciones IP y un modelo servidor primario/secundario.
 Por ahora ya se ha probado \'util para varias aplicaciones incluyendo servidores
 DNS, servidores proxy de cache, servidores web y servidores directores
 de LVS.
 El proyecto LVS recomienda HeartBeat para aumentar la disponibilidad de
 su soluci\'on, pero no es parte de LVS.

En Linux-HA Heartbeat es un servicio de bajo nivel. Cuando un ordenador
 se une al cluster se considera que el ordenador se ha unido al canal de
 comunicaciones (por lo tanto {\em late}) y cuando sale que ha dejado
 el canal de comunicaciones.

Cuando un ordenador deja de {\em latir} y se considera {\em muerto} se hace
 una transici\'on en el cluster.
 La mayor\'\i a de los mensajes de manejo del cluster que no son heartbeats
 se realizan durante estas transiciones.

Los mensajes de Heartbeat se env\'\i an por todas las lineas de comunicaci\'on
 a la vez, as\'\i\ si una linea de apoyo cae, se avisar\'a de ese problema antes
 de que la linea principal caiga y no haya una l\'\i nea secundaria para continuar
 el servicio.

Heartbeat tambi\'en se preocupa por la seguridad permitiendo
 firmar los paquetes CRC de 32 bits, MD5 y SHA1.
 Esto puede evitar el desastre que podr\'\i a provocarse si un nodo no miembro se enmascarase como nodo
 miembro del cluster. 
Hay varias operaciones de mantenimiento de seguridad que necesitan ser
 efectuadas en ese tiempo, como pueden ser cambio de claves y de protocolos
 de autentificaci\'on.
 Heartbeat est\'a preparado para esos cambios disponiendo de ficheros para
 la configuraci\'on.

Heartbeat tiene el problema que si no se dispone de una l\'\i nea dedicada, aunque \'esta
 sea una l\'\i nea serie, al tener un tr\'afico que aunque peque\~{n}o es constante,
 suele dar muchas colisiones con otros tr\'aficos que puedan ir por la misma
 red. Por ejemplo openMosix y Heartbeat en una misma red que no tenga gran ancho
 de banda no funcionan bien, sobre todo si hay bastantes nodos, pues los
 heartbeats se env\'\i an de cualquier nodo a cualquier nodo, por lo que podr\'\i an
 llegar a ser un tr\'afico voluminoso.

\vspace{.2in}
{\bf Ldirectord.}

Pensado especialmente para ser usado junto con LVS, utiliza Heartbeat.
 Monitoriza que los servidores reales sigan funcionando peri\'odicamente enviando
 una petici\'on a una url conocida y comprobando que la respuesta contenga
 una cadena concreta.
 Si un servidor real falla entonces el servidor es quitado del conjunto
 de servidores reales y ser\'a reinsertado cuando vuelva a funcionar correctamente.
 Si todos los servidores fallan se insertar\'a un servidor de fallos, que
 ser\'a quitado una vez que los servidores vuelvan a funcionar.

 T\'\i picamente este servidor de fallos es el propio host desdel que
 se realiza el monitoraje.

\vspace{.2in}
{\bf LVS.}

Sobre este proyecto se dedica la siguiente subsecci\'on, por
 tanto de momento basta decir que \'este es seguramente el proyecto
 m\'as implantado y uno de los pilares sobre los que se apoyan las soluciones
 comerciales.
%===========================================================================
\subsection{LVS (Linux Virtual Server)}
%---------------------------------------------------------------------------
\subsubsection{Introducci\'on}
LVS es un proyecto que incluye los programas y documentaci\'on
 necesaria parar montar un cluster de servidores bajo GNU/Linux. El
 proyecto LVS es utilizado principalmente para aumentar rendimiento y
 escalabilidad de servicios ofrecidos sobre la red, es ampliamente
 utilizado por grandes sites como {\tt SouceForge.net} o {\tt Linux.com}.

\vspace{.2in}
La principal idea es proveer de un mecanismo de {\em migraci\'on de sockets}.
 El mecanismo se basa en utilizar una m\'aquina servidora a la que se dirigen
 las peticiones de los usuarios clientes. El interfaz p\'ublico (en Internet) de esta
 m\'aquina normalmente tiene asociada una direcci\'on conocida como
 VIP. El cometido de esta primera computadora es direccionar dichas
 peticiones a otros servidores reales mediante varias t\'ecnicas, de
 este modo los usuarios clientes ven un \'unico servidor. No ostante \'este opera con
 varias m\'aquinas para conceder un servicio \'unico al exterior.

A todo el conjunto de nodos que conforman el servicio y se comportan
 como si fuese un \'unico servidor se le denomina Servidor Virtual.
 El cluster est\'a formado por dos tipos de m\'aquinas:
\begin{itemize}
  \item por un lado est\'an los nodos o {\bf servidores reales}, que corren
 con los servicios habituales que estos suelen proveer,
  \item  por otro lado est\'an los {\bf nodos directores}, de los cuales uno de ellos ser\'a
 el principal y el resto estar\'an preparados para hacer de refuerzo
 de \'este (mediante t\'ecnicas o protocolos como heartbeat) para cuando caiga.
 Estas t\'ecnicas no son propias de LVS, como ya puede saberse a
 partir de las seccines anteriores.
\end{itemize}
En general se puede considerar LVS como una suma de herramientas que permiten
 efectuar la funci\'on ya especificada. Para cosneguirlo se requiere:
\begin{itemize}
  \item el c\'odigo de {\bf ipvs},  un parche al kernel para el nodo director
  \item el programa {\bf ipvsadm}, encargado de configurar las tablas
  internas y algoritmos del kernel del nodo director
\end{itemize}
Ambos constituyen el c\'odigo principal del proyecto LVS, pero se requieren
 otras muchas herramientas como ipchains, iptables o Netfilter (dependiendo
 de la versi\'on del n\'ucleo utilizada ), Ldirectord, Heartbeat, Piranha, MON,
 LVS-gui, {\em etc.}

\vspace{.2in}
 El Servidor Virtual\footnote{Es decir, el conjunto de nodo director y
 bater\'\i a de servidores reales.} requiere de la configuraci\'on de
 todos estos servicios y herramientas para un funcionamiento adecuado,
 y no {\em solamente} del c\'odigo de LVS.
 Es m\'as, dentro del tipo de programas que conforman el Servidor Virtual
 no hay que olvidar los programas o demonios servidores habituales que proveer\'an
 realmente de servicio a los clientes finales (HTTPD, FTPD, SMTP, {\em
 etc.}).

El funcionamiento de LVS es una aproximaci\'on a resolver el problema de la
 escalabilidad y el alto rendimiento muy elegante puesto que permite que cliente
 y servidor trabajen de la manera transparente permitiendo que el balanceo se lleve a cabo por
 el director. Comparado con m\'etodos como el ofrecido por RR-DNS es mucho menos
 intrusivo y m\'as confiable en su servicio.

\vspace{.2in}
Existen otras t\'ecnicas para ofrecer mayor escalabilidad y rendimiento en servicios
 de Internet.
 La alternativa RR-DNS es uno de los m\'etodos m\'as utilizados
 actualmente ya que permite independencia en arquitectura o sistema utilizado
 en el servidor Se basa en un algoritmo Round Robin en el servidor DNS, de manera
 que cuando un cliente solicita la direcci\'on IP de un servidor \'esta le
 es concedida seg\'un el algoritmo. As\'\i\ por ejemplo si existen 4 m\'aquinas servidoras
 que proporcionan el mismo servicio, a la primera conexi\'on entrante
 que solicite el servicio se le asignar\'a la direcci\'on IP del
 primer servidor, a la segunda conexi\'on la IP del segundo servidor y
 a la quinta conexi\'on la IP del primero otra vez.

Uno de los defectos que tiene este m\'etodo es que si uno de los servidores
 cae los clientes que asociaban el dominio a esa direcci\'on IP lo seguir\'an
 haciendo, obteniendo un fallo en sus peticiones.

El servicio RR-DNS puede ser utilizado complementariamente a LVS, es decir,
 se utilizar RR-DNS para solicitar la IP de un Servidor Virtual LVS.
 Otra alternativa es el uso de clientes no transparentes, clientes que
 utilicen alg\'un algoritmo para decidir que servidor utilizan en cada
 petici\'on o sesi\'on, l\'ogicamente estos m\'etodos son muy poco
 utilizados. Esto puede conseguirse mediante applets Java, por ejemplo.

Otras alternativas m\'as conocidas son los proxies inversos,
 esta alternativa supone el mismo funcionamiento de un proxy, pero en el
 caso de los servidores.
 El Proxy recive las peticiones y gestiona una nueva conexi\'on con uno de
 los servidores reales mediante alg\'un tipo de algoritmo de balanceo, el
 servidor responde al proxy y este env\'\i a las peticiones de nuevo al cliente.
 Esta alternativa es muy utilizada, aunque presente menos \'\i ndice
 de escalabilidad y m\'as sobrecarga en los equipos que RR-DNS o
 LVS. El proxy acaba por resultar un cuello de botella ya que \'este
 abre 2 conexiones TCP por cada conexi\'on que se realiza al Proxy, esta soluci\'on a nivel de
 aplicacion se puede realizar mediante programas como SWEB\footnote{{\tt
 \htmladdnormallink{http://www.cs.ucsb.edu/Research/rapid\_sweb/SWEB.html}{http://www.cs.ucsb.edu/Research/rapid_sweb/SWEB.html}}}.

\vspace{.2in}
Por \'ultimo, est\'an las alternativas propietarias de empresas como CISCO,
 IBM, COMPAQ y dem\'as empresas que tienen bastante c\'odigo tanto a nivel de
 aplicaci\'on, kernel y hardware espec\'\i fico para este tipo de tareas.

A pesar de que el director LVS se comporta como un conmutador ({\em switch}) de nivel 4
 no act\'ua como un Proxy inverso. El modo de actuar es bien distinto.
 El nodo director utiliza un kernel especial parcheado que permite el balanceo
 de carga de los servicios mediante varios m\'etodos de planificaci\'on, adem\'as
 es configurable mediante un programa en zona de usuario que permite pasarle
 los par\'ametros al kernel acerca de como debe balancear conexiones.
 El director se comporta como un conmutador de nivel 4 en la arquitectura
 OSI, balancea conexiones o datagramas seg\'un se le haya exigido en su algoritmo
 de balanceo.

El efecto de solicitar una petici\'on sobre el Servidor Virtual LVS es el
 siguiente:
\begin{enumerate}
  \item el cliente solicita un servicio o conexi\'on a la direcci\'on del
 Servidor Virtual LVS (llamada VIP) que posee la interfaz
 p\'ublica del nodo director
  \item el nodo director se encarga de balancear la
 conexi\'on seg\'un el algoritmo programado, hacia el servidor real dentro de
 la bater\'\i a de servidores
  \item el servidor contesta al cliente con su respuesta y la env\'\i
 a hacia \'el.
\end{enumerate}
De esta manera se puede ver que tanto cliente como servidor real trabajan
 de manera transparente en lo que se refiere al nodo director.

La diferencia con un Reverse Proxy estriba en que LVS no requiere de la
 vuelta de las peticiones al director, ya que \'estas pueden ser enviadas
 directamente al cliente, lo que evita que el director se convierta en un
 cuello de botella en el sistema, como ocurre en el caso de los proxys inversos.

LVS puede solucionar muy satisfactoriamente casos de adaptabilidad a requerimientos o escalabilidad,
 redundancia, alta fiabilidad y mayor crecimiento de los servicios ofrecidos.
 Por todo esto se puede considerar dentro de los clusters de Alta Fiabilidad (HA).
\begin{latexonly}
\ifpdf
        \begin{figure}[htbp]
        \includegraphics[bb = -100 250 0 0, scale=.9]{./pics/lvs_basico.png}
        \vspace{3.2in}
        \caption{Clusters HA. Topolog\'\i a t\'\i pica de un LVS b\'asico}
        \end{figure}
\else
\end{latexonly}
        \begin{figure}
        \centering
        \includegraphics{pics/lvs_basico}
        \caption{Clusters HA. Topolog\'\i a t\'\i pica de un LVS b\'asico}
        \end{figure}
\begin{latexonly}
\fi
\end{latexonly}

\vspace{.2in}
Realmente LVS no es un cluster propiamente dicho.
 Un cluster se suele entender en base a una serie de m\'aquinas que act\'uan de manera
 conjunta mediante relaciones entre ellas para resolver un problema (generalmente de c\'omputo).
 LVS no es un cluster en este sentido puesto que cada servidor es independiente
 y solamente est\'a relacionado con los otros mediante un sistema de
 almacenamiento com\'un\footnote{En el caso de que se quiera
 configurar as\'\i\. En ciertos entornos ni siquiera es necesario este tipo de almacenamiento
 y basta con un {\em rsync} de los discos de cada servidor individual.}, los servidores 
 solamente se relacionan con el nodo director para proveer de un servicio.

En cualquier caso y generalizando el concepto de cluster, LVS utiliza varias
 m\'aquinas para aumentar el rendimiento y la fiabilidad de un servicio, es
 decir un problema, y como tal se puede considerar como un cluster.
 La idea de migrar sockets no tiene una soluci\'on general inmediata, MOSIX
 la solucionaba prohibiendo a los procesos servidores de cada m\'aquina que
 migrasen a otros nodos, impidiendo un balanceo perfecto del sistema.
 El que un proceso que tiene un socket migre conlleva un problema de dif\'\i cil
 resoluci\'on.
 LVS proporciona un sistema bastante adaptable para migrar sockets,
 por lo que es un sistema ideal y complementario a otros.

\vspace{.2in}
El nodo director se comporta como un router al que se le han a\~{n}adido en
 el kernel tablas de encaminamiento para reenviar paquetes a los servidores
 reales para los servicios que se hayan configurado en el cluster LVS.

Existen tres maneras de efectuar el reenv\'\i o o encaminamiento en LVS: VS-NAT,
 VS-DR, VS-TUN.
\begin{itemize}
  \item VS-NAT hace uso de NAT din\'amico para efectuar transacciones entre servidor
 real y cliente.
  \item VS-DR o VS-Direct routing hace uso de direcciones virtuales mediante alias
 en dispositivos Ethernet para reenviar a la direcci\'on Virtual del director
 (VIP) a cada servidor real.
  \item VS-TUN hace uso de {\em ip-tunneling} para reenviar los paquetes a los servidores
 reales, esto implica que el sistema operativo deba poder manejar la
 desencapsulaci\'on de estos paquetes especiales.
\end{itemize}
%---------------------------------------------------------------------------
\subsubsection{M\'etodos de balanceo IP}
En esta secci\'on se describir\'an las t\'ecnicas descritas anteriormente con
 las que LVS balancea los paquetes TCP/IP o UDP/IP hacia los servidores
 reales.
 Estas tres t\'ecnicas son bien distintas y permiten configurar LVS de una
 manera espec\'\i fica para cada soluci\'on que se quiera implementar.
 La elecci\'on de una u otra t\'ecnica depende principalmente del servicio que
 se quiera proveer, los conocimientos que se posean de los sistemas, el
 sistema operativo de los servidores, los recursos econ\'omicos que se est\'en
 dispuestos a gastar y consideraciones sobre el rendimiento.

\vspace{.2in}
{\bf VS-NAT}

Es el caso m\'as sencillo de configurar de todos y el que menor rendimiento
 tiene respecto a los otros dos.

VS-NAT hace uso de NAT para modificar direcciones, existen tanto la
implementaci\'on para las versiones de kernel 2.2\footnote{implementac\'\i on
 basada en la de {\em masquerading}, lo que hace que al mostrar
 todas las entradas mediante {\em ipchains -M -L} nos muestre las
 conexiones de LVS,} como para las 2.4\footnote{que ha sido
 completamente reescrita para adaptarse al nuevo Netfilter, el cual no
 necesita incluir ninguna regla para poder gestionar bien los paquetes marcados por LVS.}.
Ambas implementaciones dan soporte SMP para LVS en el nodo director (que
 es el que tiene el kernel modificado), lo que permite una tasa de manejo
 de paquetes muy alta para clusters que proveen de mucho servicio.

VS-NAT se compone de un director que corre el kernel parcheado con LVS (ipvs)
 y de una bater\'\i a de servidores que pueden correr con cualquier sistema
 operativo y cualquier tipo de servicio.
 El nodo director se encarga de recibir las peticiones de los clientes por
 su VIP mediante el algoritmo de balanceo elegido se reenv\'\i an
 los paquetes a el servidor real de manera que el servidor responde a la
 petici\'on y los encamina al nodo director, el cual cambia las direcciones
 de la cabecera de los paquetes IP del servidor, para que el cliente los
 acepte sin problemas.
 Como se puede ver, el mecanismo es muy parecido por no decir igual que
 el de un Proxy inverso, excepto por que el redireccionamiento se hace a
 nivel de kernel.

Primero el director reenv\'\i a sus paquetes mediante el c\'odigo
 ipvs, modificando los paquetes que se recibieron del cliente mediante
 el cambio de la direcci\'on destino hacia los servidores reales y
 luego vuelve a hacer el cambio inverso mediante NAT din\'amico a los
 paquetes que env\'\i an los servidores.
\begin{latexonly}
\ifpdf
        \begin{figure}[htbp]
        \includegraphics[bb = -100 300 0 0, scale=.8]{./pics/lvs_NAT.png}
        \vspace{3.3in}
        \caption{Clusters HA. Configuraci\'on VS-NAT}
        \end{figure}
\else
\end{latexonly}
        \begin{figure}
        \centering
        \includegraphics{pics/lvs_NAT}
        \caption{Clusters HA. Configuraci\'on VS-NAT}
        \end{figure}
\begin{latexonly}
\fi
\end{latexonly}
VS-NAT tiene el mismo problema que los proxys inversos: el nodo director
 llega a ser un cuello de botella en cuanto las exigencias por parte de
 los clientes se hacen muy altas, o el n\'umero de servidores internos a la
 red crece por encima de los 20.
 Es por esto que este tipo de configuraci\'on es la menos utilizada de las
 tres.

\vspace{.2in}
{\bf VS-TUN}

Este m\'etodo es m\'as utilizado que el anterior, se basa en redirigir los paquetes
 IP del nodo director al destino mediante t\'ecnicas de {\em IP-tunneling}, esto
 requiere que tanto el nodo director (que debe correr bajo Linux y por tanto
 puede ser compilado con {\em IP-tunneling}) como el servidor real
 puedan encapsular y desencapsular paquetes especiales. Para esto es
 necesario que la pila IP del sistema operativo lo soporte, y no todos
 los sistemas operativos lo soportan, en general la mayor\'\i a de
 Unix que existen en el mercado si lo soportan, por lo que en un
 principio no debe ser un grave inconveniente para la elecci\'on de
 este m\'etodo como base de LVS.

El funcionamiento mediante este m\'etodo de balanceo es el siguiente:
\begin{itemize}
  \item  el cliente hace la petici\'on a la VIP del director
  \item  el director elige mediante el algoritmo de balanceo cual
  ser\'a el servidor real que atienda la petici\'on 
  \item el servidor encapsula el paquete (que le lleg\'o por la
  interfaz asignada a la VIP) en otro paquete IP con destino el
  servidor real
\end{itemize}
El servidor real atiende la petici\'on de servicio y la responde, poniendo como direcci\'on
 de los paquetes IP generados por este la direcci\'on propia por la que lleg\'o
 el servicio, es decir la VIP. Los env\'\i a directamente al cliente, sin tener
 que pasar los paquetes por el nodo director de nuevo. De esta manera
 se evita el problema de cuello de botella en el director.
\begin{latexonly}
\ifpdf
        \begin{figure}[htbp]
        \includegraphics[bb = -100 380 0 0, scale=.6]{./pics/lvs_TUN.png}
        \vspace{3.3in}
        \caption{Clusters HA. Configuraci\'on VS-TUN}
        \end{figure}
\else
\end{latexonly}
        \begin{figure}
        \centering
        \includegraphics{pics/lvs_TUN}
        \caption{Clusters HA. Configuraci\'on VS-TUN}
        \end{figure}
\begin{latexonly}
\fi
\end{latexonly}

Este mecanismo de redirecci\'on permite que los servidores reales puedan encontrar
se no en una red local, como sucede en el caso de los dos anteriores, sino
 dispersos en otras redes a las cuales se pueda acceder desde el director,
 esto supone el poder distribuir los servicios no solo como m\'etodo
 de incrementar el rendimiento, sino como distribuci\'on geogr\'afica
 de los servidores, lo cual puede ser una ventaja para ciertos sistemas, o una desventaja para
 otros.

La desventaja de esta t\'ecnica est\'a en que tanto el director como el servidor
 tienen que poder crear interfaces de tipo {\em tunneling}, y como consecuencia de hacer 
{\em IP-tunneling} siempre estar\'a impl\'\i cito un tiempo de procesador
ocupado en encapsular o desencapsular los paquetes, que si bien en
algunos sistemas puede ser insignificantes, en otros puede ser
decisivo para la elecci\'on de otro m\'etodo de balanceo.

\vspace{.2in}
{\bf VS-DR}

VS-DR se basa en una tecnolog\'\i a de
 red local (en un \'unico segmento) y en un cambio de direcciones IP-MAC para
 proporcionar el m\'etodo de reenv\'\i o de los paquetes.

Al igual que VS-TUN no requiere reenviar los paquetes al
 nodo director, por lo que no presenta en \'el un cuello de botella.
 Es quiz\'a el m\'as utilizado de los tres, por ser el que mayor rendimiento
 obtiene, pero al igual que el resto, presenta una serie de desventajas
 en su uso y configuraci\'on.

El funcionamiento de VS-DR es similar al de VS-TUN en el sentido de que
 ambos utilizan la direcci\'on VIP no solamente en el nodo director (donde
 esta la direcci\'on VIP real a la que acceden los clientes) sino tambi\'en
 en los nodos servidores.
 En este caso, los servidores poseen dos direcciones asociadas al nodo,
 una es la IP real asociada a la tarjeta Ethernet, la otra es una direcci\'on
 loopback especial configurada con la direcci\'on VIP, es conveniente dejar
 la interfaz loopback que tiene la direcci\'on {\tt 127.0.0.1} sin modificar, por lo
 cual se debe hacer un alias de esta interfaz pero con la direcci\'on conocida
 como VIP.

De este modo los clientes hacen la petici\'on a la VIP del director, \'este
 ejecuta el algoritmo de elecci\'on del servidor, solicitando mediante ARP
 la direcci\'on del servidor al que pretende enviar para conocer la direcci\'on
 MAC asociada a esta IP. Una vez que la conoce env\'\i a un los paquetes del
 cliente, sin ser modificados, en una trama Ethernet con destino la direcci\'on
 del servidor real. \'Este recibe la petici\'on y comprueba que pertenezca a
 alguna de las direcciones que \'el posee, como hemos configurado la VIP en
 un interfaz loopback, la petici\'on se efectuar\'a sin problemas.

\vspace{.2in}
Este m\'etodo requiere en ciertas ocasiones que el servidor acepte las peticiones
 asociadas al interfaz declarado como {\tt lo0:1}, es decir el de {\em
 loopback}, en el caso de ser una m\'aquina Linux.

Esto implica generalmente que el servidor pueda ser configurado para ello,
 por ejemplo en el caso de apache (uno de los servidores m\'as utilizados
 de HTTP), en el fichero de configuraci\'on {\em /etc/httpd.conf} se debe
 especificar en una linea como

\hspace{1in}\colorbox{gray}{{\tt  Listen $<$dir\_VIP$>$:$<$PORT\_VIP$>$}}

 para que el servidor acepte las peticiones provenientes de esta interfaz.
 Esto puede resultar un inconveniente en ciertos servidores.
\begin{latexonly}
\ifpdf
        \begin{figure}[htbp]
        \includegraphics[bb = -0 300 0 0, scale=.8]{./pics/lvs_DR.png}
        \vspace{3.3in}
        \caption{Clusters HA. Configuraci\'on VS-DR}
        \end{figure}
\else
\end{latexonly}
        \begin{figure}
        \centering
        \includegraphics{pics/lvs_DR}
        \caption{Clusters HA. Configuraci\'on VS-DR}
        \end{figure}
\begin{latexonly}
\fi
\end{latexonly}

A pesar de ser el m\'as utilizado por ser el que m\'as alto rendimiento ofrece,
 est\'a limitado en cuesti\'on de escalabilidad debido a que la red
 sobre la que funciona est\'a limitada a un \'unico segmento ethernet
 por motivos de direccionamiento mediante ARP.
 Por otro lado no se necesita tiempo de encapsulaci\'on o desencapsulaci\'on
 de ning\'un tipo y tampoco ning\'un factor de redirecci\'on hacia el nodo servidor.
 El encaminamiento de los servidores reales a el cliente se puede hacer
 mediante otra conexi\'on a red de alta velocidad de manera que el ancho de
 banda este garantizado.

\vspace{.2in}
{\bf Caracter\'\i sticas generales de los t\'ecnicas de balanceo}

Una vez vistos los tres mecanismos principales de las t\'ecnicas de balanceo
 se dar\'an algunas consideraciones de car\'acter general acerca de
 las mismas.

Casi todas las implementaciones de LVS se suelen hacer con el cluster de
 servidores colocado en una red de \'area local, excepto las del tipo VS-TUN.
 Si disponemos de una conexi\'on con el cliente de alto ancho de banda
 estaremos utilizando, en el peor de los casos, VS-NAT, y habr\'a m\'as de 20
 servidores reales en la red privada de 10 Mbps. Probablemente la
 red acabe congestionada con mucha asiduidad, provocando respuestas mucho
 peores de las que podr\'\i a dar un servidor \'unico, m\'as caro.

Por otro lado est\'a el factor de carga de los equipos.
 Cada servicio proporcionado por el servidor virtual puede tener
 como servidores reales destino un subconjunto de la bater\'\i a de servidores.
 Esto implica que cada nodo debe ser convenientemente
 administrado y elegido con recursos y caracter\'\i sticas correctas antes de
 la puesta en funcionamiento del LVS.

En el caso del nodo director sucede lo mismo, \'este debe ser conveniente
 elegido para su cometido, el parche LVS no inhabilita el funcionamiento
 SMP del kernel de Linux\footnote{Si bien est\'a reconocido que el
 rendimiento del funcionamiento SMP en el so Linux no es de los
 mejores, aunque se est\'a
 trabajando en ello obteniendo cada vez mejores resultados.} por lo que
 puede ser elegida una m\'aquina de este tipo para hacer las funciones
de nodo director. El funcionamiento de LVS se basa principalmente en
 {\em enga\~{n}ar} al cliente acerca de qui\'en le est\'a sirviendo. As\'\i\ el cliente aceptar\'a
 todos los paquetes que le vengan con la direcci\'on VIP y determinados n\'umeros
 de secuencia y asentimiento (en el caso de los TCP) con lo que solamente
 hay que elegir entre los diferentes mecanismos para poder llevar a cabo este cambio de
 direcciones: NAT, {\em tunneling} o mediante encaminamiento directo.

Otra de las desventajas que conlleva la instalaci\'on de un sistema LVS es
 la formaci\'on y el conocimiento con el que deben contar los dise\~{n}adores
 de la red y de cada sistema que intervienen en un sistema LVS.
 Al estar formado el sistema por un grupo hetereog\'eneo de elementos, en
 la mayor\'\i a de los casos con una relaci\'on de dependencia bastante fuerte,
 es necesario conocer extensivamente cada uno de los sistemas individuales,
 para que ninguno de ellos falle o baje su rendimiento.
 Por ejemplo es necesario saber el como hacer {\em masquerading} en el nodo director,
 como evitar ICMP Redirects en el director, como evitar los problemas ARP
 (se ver\'a m\'as tarde), como hacer auditor\'\i as a la red y gestionarla para
 ver donde tiene el sistema sus cuellos de botella y un largo {\em
 etcetera} de problemas potenciales que hacen que la puesta en marcha
 de uno de estos sistemas en entornos  de producci\'on sea m\'as
 dif\'\i cil de lo que en un principio pueda parecer.
%---------------------------------------------------------------------------
\subsubsection{Aspectos T\'ecnicos}
La instalaci\'on de LVS requiere el conocimiento de cada uno de los elementos
 que requieren para su funcionamiento correcto (que no son pocos).
 La instalaci\'on o puesta en marcha se puede separar en:
\begin{itemize}
  \item Dise\~{n}o de la red. Direcciones, topolog\'\i a, servicios y
  arquitectura del sistema global.
  \item Preparaci\'on y configuraci\'on de los nodos directores,
  puesto que puede haber m\'as de un nodo director haciendo backup.
  \item Preparaci\'on y configuraci\'on de los nodos que actuar\'an como servidores reales.
  \item Configuraci\'on de los elementos de encaminamiento (enrutadores) y seguridad
  (firewalls\footnote{No debemos olvidar que al utilizar un sistema
  tan hetereog\'eneo con tantos elementos, el sistema es m\'as
  susceptible a debilidades, por lo que ser\'a necesario hacer una
  auditoria de seguridad y un estudio de cuales son los posibles
  puntos de entrada al sistema para taponarlos.}).
  \item Configuraci\'on de la parte que proveer\'a al sistema de alta fiabilidad
 y redundancia.
  \item Configuraci\'on de un sistema de almacenamiento compartido.
\end{itemize}
Se podr\'\i an a\~{n}adir otros tantos puntos para cada sistema espec\'\i fico.
 Pero para un sistema general en producci\'on, los imprescindibles son
 los ya enunciados.

\vspace{.2in}
{\bf Apartado de Red}

El dise\~{n}o y elecci\'on de la topolog\'\i a de red es bastante
 cr\'\i tica en la implantaci\'on del sistema ya que puede
 convertirse en uno de los cuellos de botella.

Generalmente los nodos servidores se encuentran en una red privada Ethernet
 a la que pertenecen tanto la bater\'\i a de servidores como los nodos que act\'uen
 como director en el sistema. Hay que tener en cuenta que por esta red
 pasaran:
\begin{itemize}
  \item las peticiones y respuestas de los clientes en el peor de los casos (VS-NAT),
  \item los paquetes de monitorizaci\'on,
  \item paquetes de sistema de manejo y gesti\'on del cluster, {\em etc}...
\end{itemize}
Es decir, una carga alta dependiendo de el sistema elegido.

\vspace{.2in}
Lo ideal ser\'\i a utilizar tecnolog\'\i as r\'apidas pero baratas como FastEthernet
 (100 Mbps) y separar en tantas redes como sea necesario para tener los
 m\'\i nimos cuellos de botella posibles y la m\'axima escalabilidad (en vista al futuro).

Esto probablemente implica separar por un lado la red por la que se efect\'uan
 todos los intercambios de petici\'on entre el nodo director y los servidores
 reales, una red espec\'\i fica para el sistema de almacenamiento elegido y
 excepto en el caso de VS-NAT una red (o varias dependiendo del ancho de
 banda requerido para proveer servicio) para la salida de las respuestas
 de los servidores reales.
 Aun quedar\'\i an los paquetes de monitorizaci\'on o redes destinadas a openMosix
 o similares.

Por \'ultimo se podr\'\i a utilizar una red m\'as barata entre el nodo director
 y su nodo de backup, en el caso de utilizar Heartbeat\footnote{Este
 caso es estudiado con m\'as profundidad en otro apartado, y ser\'a
 conveniente referirse.}.

Esta trama de redes no es necesaria en todos los sistemas, bastar\'\i a medir
 la congesti\'on en la red para poder ver que servicios se deben separar de
 los otros para evitar las congestiones en cualquiera de los casos.

\vspace{.2in}
En lo referente al direccionamiento, generalmente solamente el nodo director
 debe tener una direcci\'on p\'ublica, mientras que el resto de los nodos servidores
 suelen tener direcciones privadas reservadas.
 El mecanismo de direccionamiento utilizado en Ethernet provoca un problema
 que se tratar\'a m\'as tarde.
 En el caso de los servicios proporcionados.
 En la mayor\'\i a de los casos no interviene ning\'un factor externo
 en la configuraci\'on salvo casos como el explicado en el apartado
 anterior en el que se configura un servicio para un determinado interfaz de la m\'aquina servidora.
 El \'unico problema que plantean los servicios en un cluster del tipo LVS
 es el problema de la persistencia.

Se entiende por conexiones persistentes dos tipos de conexiones:
\begin{itemize}
  \item una es del tipo de los servidores HTTP, en los cuales
 intervienen los tiempos de establecimiento de
 conexi\'on activa, el tiempo de transferencia real y el tiempo de
 aproximadamente 15 segundos (aunque es muy variable) hasta que se
 cierra la conexi\'on con el cliente.

El manejo de esta persistencia es realmente sencillo.

  \item otro tipo de persistencia es la debida a dependencias entre varios sockets,
 como es el caso de servicios como FTP o el paso de HTTP a HTTPS en una
 transacci\'on o compra v\'\i a Internet. Dichas conexiones son m\'as dif\'\i ciles
 de analizar, ya que dependiendo del servicio se establecer\'an factores
 de dependencia entre unos puertos u otros.
\end{itemize}
LVS resuelve el problema de la persistencia de manera
 expl\'\i cita, es decir, de la manera que el administrador le obligue a hacerlo.

\vspace{.2in}
En cualquier caso la configuraci\'on, dise\~{n}o y elecci\'on de red dependen
 de los servicios, situaci\'on geogr\'afica, coste y topolog\'\i a. Tambi\'en dependen
 de la seguridad del sistema.
 LVS tiene un apartado especial para poder hacer balanceo sobre firewalls,
 de manera que los firewalls que ejecutan las mismas reglas pueden actuar
 en paralelo, utilizando de este modo m\'aquinas m\'as baratas para dicha tarea.
 A parte de este servicio, en un entorno de producci\'on ser\'a necesario aislar
 la red completamente del exterior mediante las reglas adecuadas en los
 firewalls.
 La utilizaci\'on de los nodos {\em diskless}, proporciona como se ver\'a m\'as tarde,
 un mecanismo m\'as s\'olido para la construcci\'on de nodos.

Por \'ultimo se deben considerar todos aquellos factores relativos a la
 seguridad en redes que se puedan aplicar en servidores normales, de los
 que se encuentra amplia bibliograf\'\i a.

\vspace{.2in}
{\bf Consideraci\'on respecto al tipo de encaminamiento elegido.}

En lo que se refiere al rendimiento de cada tipo de encaminamiento es obvio
 que hay que separarlo en dos, por un lado VS-NAT y por otro VS-TUN
 y VS-DR.

VS-NAT se basa en el NAT tradicional, esto implica que cada paquete
 ya sea de conexi\'on o de cualquier otro tipo que entra por parte del router
 o cliente es evaluado de la forma antes descrita y reenviado al servidor
 real. La cabecera IP es modificada con los valores fuente del nodo
 director, el servidor procesa la petici\'on y da su respuesta al nodo director,
 que otra vez hace NAT al paquete colocando como destino el nodo cliente,
 y se vuelve a enviar al router por defecto del director.
 
Este mecanismo exige no solamente el balanceo de las conexiones por parte
 del kernel, sino un continuo cambio de direcciones a nivel IP de todos
 los paquetes que pasan por el director, as\'\i\  como la evaluaci\'on de los mismos,
 lo que hace que el rendimiento de este m\'etodo se vea limitado a la capacidad
 de proceso que posea el nodo director.
 Por tanto es muy f\'acil dimensionar mal las capacidades del director o de
 la red y hacer que la salida a trav\'es del director se convierta en un cuello
 de botella.
 En el caso de el VS-NAT existe una opci\'on en el kernel para optimizar
 el reenvi\'o de paquetes para que este sea m\'as r\'apido, que consiste en no
 comprobar ni checksums ni nada, solamente reenviar.

En el caso de VS-DR o VS-TUN el rendimiento no cae tanto sobre el director.
 No obstante \'este sigue siendo un punto cr\'\i tico, pero las soluciones actuales en lo
 que se refiere a capacidad de proceso nos sobran para gestionar cantidades
 considerables.
 El mayor problema de estos dos tipos es el dise\~{n}o de la red interior, para
 que esta no se congestione y por supuesto el problema ARP enunciado en
 el apartado anterior.

 En ambos m\'etodos, las respuestas de los servidores reales se env\'\i an directamente
 a los clientes a trav\'es de un enrutador que puede ser (o no) diferente del
 que env\'\i o la petici\'on inicial al director.
 En el caso de VS-DR se exige, por el modo del algoritmo que todos los servidores reales 
 pertenezcan al mismo tramo de una LAN, esta es la forma m\'as com\'un
 en entornos de producci\'on de configurar LVS, ya que permite el mejor rendimiento y 
 menos carga de la red de los tres.

\vspace{.2in}
{\bf El problema ARP}

Otra consideraci\'on que afecta no solamente a la red sino a la configuraci\'on
 del sistema en general es el problema ARP.
 Como se ha visto hasta ahora la t\'ecnica de balanceo m\'as utilizada es VS-DR,
 esta t\'ecnica ya ha estado descrita.

Para configurar LVS se puede hacer mediante {\em tunneling} o mediante
 DR, en cualquier caso habr\'a que a\~{n}adir direcciones virtuales extras a la
 configuraci\'on de los servidores reales, as\'\i  como a la del nodo director. Para esto
 se deber\'an compilar los n\'ucleos de las m\'aquinas con la opciones de {\tt ip aliasing}
 en el apartado {\em Networking}.

 En la figura se muestra el problema ARP.
\begin{latexonly}
\ifpdf
        \begin{figure}[htbp]
        \includegraphics[bb = -100 350  0 0, scale=.6]{./pics/lvs_DR2.png}
        \vspace{3in}
        \caption{Clusters HA. Problema del ARP}
        \end{figure}
\else
\end{latexonly}
        \begin{figure}
        \centering
        \includegraphics{pics/lvs_DR2}
        \caption{Clusters HA. Problema del ARP}
        \end{figure}
\begin{latexonly}
\fi
\end{latexonly}

Cuando un cliente quiere realizar una conexi\'on con el director lanza un
 paquete ARP (o en su defecto lo manda el router, en cualquier caso el
 problema es el mismo) para saber cual es la direcci\'on MAC del director.
 \'Este hace el reenvi\'o dependiendo del algoritmo de planificaci\'on y al mismo
 tiempo guarda en su tabla el estado de la conexi\'on que se ha realizado.
 
El servidor contesta y se reenv\'\i a la respuesta hacia el cliente.
 Pero ?`qu\'e sucede si en lugar de contestar la m\'aquina que hace las veces
 de director contesta una de las que esta haciendo de servidor? En este
 caso al lanzar el paquete ARP pidiendo {\em Who has VIP tell cliente/router?}
 en lugar de contestar el director contesta una de las m\'aquinas que
 hace de servidor real. De esta manera la conexi\'on se establece pasando por
 encima del LVS en una especie de bypass, sin tener en cuenta al nodo director,
 que no guarda los estados ni la conexi\'on.

De hecho hasta aqu\'\i\  no se produce
 ning\'un error con respecto a el servicio realizado, ya que el servidor procede
 a la entrega de la respuesta, el problema esta en el caso de que la tabla
 ARP del router o cliente se borre\footnote{La asiduidad de este
 efecto depende del sistema operativo utilizado, de hecho es
 configurable, pero suele rondar entre los 2 y 10 segundos.} y vuelva a pedir ARP 
{\em Who has VIP tell cliente/router} concedi\'endose la MAC de otro
 servidor o incluso del nodo director, que no tiene ni idea de como
 lleva la conexi\'on en ese momento ya que el no la estaba sirviendo.
 Como se puede ver es un problema inherente a la manera en la que hemos
 configurado nuestra soluci\'on que podr\'\i a ser resuelto poniendo m\'as de una
 tarjeta de red al director u otras soluciones.
 En cualquier caso, la red se comporta normalmente de manera aleatoria en
 la concesi\'on de la MAC.

En cualquier caso la soluci\'on a este problema esta en conseguir que el
 director conteste a los paquetes ARP {\em Who has VIP tell
 cliente/router}, que son solicitados por el router o cliente.

\vspace{.2in}
Existen varias soluciones, desde parches para el kernel hasta un {\tt
 ifconfig -arp}, pasando por meter una tarjeta de red m\'as en el
 director o incluso modificando la tabla ARP del router para que no
 solicite ARP din\'amicamente sino lo especificado. 

Por ejemplo en {\em /etc/ethers} o directamente cambiando la tabla ARP de manera que todos los paquetes
 IP del router para la direcci\'on VIP queden asociados al director.
 Cualquier soluci\'on es v\'alida.

Al mismo tiempo exige un conocimiento bastante profundo del problema
 para los dise\~{n}adores de la red, ya que cada soluci\'on aportar unas ventajas
 y alguna desventaja.
 Generalmente se suelen utilizar dos opciones: a\~{n}adir nueva tarjeta al director
 o adaptar el kernel de los clientes para que ellos no respondan a las peticiones ARP
 de alguna de sus interfaces, accediendo a {\em /proc/sys/net/ipv4/lo/hidden}
 o similar respecto al interfaz al que hemos asociado la VIP.

Hay que tener en cuenta que la especificaci\'on de
 {\em -arp} en el {\em ifconfig} se deshecha en kernels superiores al
 2.0.* y exige el otro tipo de soluciones. Otra soluci\'on que se
 propone es modificar la tabla ARP que se encuentra en el cliente o
 router que hace el {\em Who has VIP tell router}, pero esto crea
 alguna complicaci\'on a la hora de tener que controlar la ca\'\i da
 del nodo director de {\em backup} en el caso de que exista (caso muy
 probable) y la toma de sus funciones, ya que la MAC del nodo director
 actual cambia y por tanto debe cambiar la tabla MAC-IP configurada en
 el router.

\vspace{.2in}
{\bf Configuraci\'on y elementos que componen el nodo o nodos directores}

El nodo director es uno de los puntos m\'as cr\'\i ticos del sistema, por
 eso debe ser bien elegido y configurado para las tareas que debe hacer.
 Suele tener alg\'un mecanismo de alta fiabilidad con un servidor
 replica que toma las funciones del nodo director cuando este cae de manera
 casi transparente\footnote{El casi se debe a que de momento no se
 provee de ning\'un mecanismo para pasar las tablas de conexiones
 establecidas y monitorizaciones.} al sistema.
 La puesta a punto del nodo director (dejando a un lado el nodo r\'eplica)
 esta formada por la configuraci\'on de varias de las herramientas de las
 que explicamos antes.

Lo primero es encontrar el c\'odigo de lvs, este c\'odigo se puede encontrar
 en la pagina oficial \htmladdnormallink{LinuxVirtualServer}{http://www.linuxvirtualserver.org}.

 El paquete a descargar depende del kernel que se utilice, de
 esta manera se pueden elegir dos tipos de kernel donde instalarlo: la
 serie antigua (2.2) y la nueva (2.4). La manera
 de configurarlos es distinta.

El paquete LVS contiene m\'as programas necesarios para la instalaci\'on de
 LVS y algunas herramientas de ayuda como el script configure del que hablaremos
 m\'as tarde.
 El kernel del director debe ser parcheado, con el c\'odigo de LVS una vez
 puesto el parche al kernel y compilado, se ejecuta y se configura mediante
 un programa en zona de usuario llamado {\em ipvsadm} que permite especificar
 el comportamiento del director.

Antes de seguir avanzando con la instalaci\'on de el kernel es necesario
 conocer, al menos por encima, el funcionamiento del n\'ucleo que vamos a
 utilizar. Ver figura.
\begin{latexonly}
\ifpdf
        \begin{figure}[htbp]
        \includegraphics[bb = -150 350 0 0, scale=.6]{./pics/lvs_kernel.png}
        \vspace{3.1in}
        \caption{Clusters HA. Funcionamiento del kernel LVS}
        \end{figure}
\else
\end{latexonly}
        \begin{figure}
        \centering
        \includegraphics{pics/lvs_kernel}
        \caption{Clusters HA. Funcionamiento del kernel LVS}
        \end{figure}
\begin{latexonly}
\fi
\end{latexonly}

\vspace{.2in}
El n\'ucleo del nodo director ser\'a el que se encargue de establecer, mediante
 un algoritmo de balanceo, quien ser\'a el servidor real de cierta conexi\'on.
 Este algoritmo se encuentra como c\'odigo del n\'ucleo y es elegido antes
 de compilar el kernel ya sea como modulo o como c\'odigo interno al kernel.

 El director hace lo siguiente:
\begin{itemize}
  \item las conexiones que se reciben del cliente (al interfaz que tiene la direcci\'on virtual)
son insertadas en el n\'ucleo de decisiones de LVS,
  \item este n\'ucleo se encarga de hacer la planificaci\'on mediante un mecanismo programado (algoritmo de balanceo)
  \item luego se insertan dichas conexiones en una tabla hash o tabla de dispersi\'on.
\end{itemize}
 Todos los paquetes pertenecientes a conexiones realizadas son comprobados
 en su tabla hash para ver qu\'e servidor real estaba gestionando la
 transacci\'on y poder enviar los paquetes a dicho servidor. Cada
 entrada en la tabla hash ocupa 128 bytes y el n\'umero m\'aximo de
 conexiones que el director puede realizar se puede configurar antes de la compilaci\'on
 del kernel, lo cual implica un estudio previo de las conexiones que se
 estima que se podr\'\i a realizar al director para poder adecuar este a las
 necesidades del sistema, proveerlo de suficiente memoria para que no haya
 problemas con el n\'umero de conexiones\footnote{Las tablas hash de
 LVS asi como el c\'odigo esta marcado como codigo de kernel, y no se
 puede hacer swap con ellas. Si se hiciese se llegar\'\i a a
 una bajada del rendimiento de LVS que haria que no mereciese la pena
 utilizar el sistema por las latencias de la conexi\'on}.

Mediante la elecci\'on de las t\'ecnicas de balanceo ya vistas 
 el n\'ucleo se encarga de formar los paquetes IP que se enviar\'an a los nodos
 servidores.

\vspace{.2in}
En la zona de usuario se ejecuta el programa {\bf ipvsadm}. Este
 programa viene dentro del paquete ipvs, debe ser compilado para cada
 versi\'on espec\'\i fica del parche de kernel ipvs. El programa se encarga mediante la funci\'on
{\em setsockopt()} de configurar el modo de funcionamiento del sistema, y mediante el sistema
 de ficheros {\em /proc} se encarga de leer las configuraciones que este tiene en cada momento.

Existen seis algoritmos para la elecci\'on del funcionamiento del nodo director.
 El algoritmo se selecciona en el kernel antes de la compilaci\'on, en el
 campo IPVS dentro de {\em Networking options}. Se pueden compilar como m\'odulos
 o internos al kernel, se deben compilar todos los algoritmos que m\'as tarde
 se utilizar\'an a la hora de encaminar a los servidores reales mediante la
 configuraci\'on de {\bf ipvsadm}.

Se pueden distinguir dos familias de algoritmos, la din\'amica y la est\'atica.
 Los algoritmos a su vez se pueden separar en 3 tipos y sus derivados para
 pesos constantes.
\begin{itemize}
  \item Round Robin y Round Robin con peso.
  \item N\'umero de conexiones y n\'umero de conexiones con peso.
  \item Algoritmos basados en n\'umero de conexiones y localidad al nodo.
  \item Algoritmos relativos a cache-proxy ({\em squid}) y algoritmos
  relativos a {\em fwmark} (firewalls).
\end{itemize}
Los dos \'ultimos juegos de algoritmos no ser\'an enunciados, pero sirven para
 balancear carga entre {\em squid} y tambi\'en para balancear entre
 varios firewalls. Para m\'as informaci\'on ver la documentaci\'on del
 kernel parcheado o el HOWTO de LVS.

\vspace{.2in}El algoritmo de Round Robin es el
 habitual en el mundo de la inform\'atica. Es un
 algoritmo est\'atico y su ampliaci\'on a Round Robin con peso
 solamente implica que a los nodos m\'as potentes se les asigna m\'as
 cantidad de trabajo que a los menos potentes. En cualquier caso,
 Round Robin no es un algoritmo \'optimo para balancear la carga
 cuando hay un elevado numero de conexiones.

El algoritmo RR es semejante al utilizado en RR-DNS, pero en el caso de LVS la
 granularidad es mucho menor ya que se balancea por conexi\'on. Un
 ejemplo de el algoritmo de Round Robin con peso, podr\'\i a ser el
 caso de tener 3 servidores:
\begin{table}
\begin{center}
\begin{tabular}{ | c | c | c | c | } \hline
SERVIDORES & A & B & C \\ \hline \hline
PESOS & 4 & 3 & 2 \\ \hline
\end{tabular}
\caption{Clusters HA. Disposici\'on de servidores con pesos en LVS}
\end{center}

\begin{center}
\begin{tabular}{ | c | c | c | c | c | c | c | c | c | c | } \hline
RESULTADO & A & A & B & A B & C & A & B & C \\ \hline
\end{tabular}
\caption{Clusters HA. Resultado de la elecci\'on}
\end{center}
\end{table}

\vspace{.2in}
Como se puede ver las conexiones son balanceadas de manera alterna siguiendo
 un algoritmo sencillo de decremento del peso y nodo que lleva m\'as tiempo
 sin ser utilizado.
 Esta es una manera muy sencilla de balancear la carga pero generalmente
 implicar\'a que el balanceo no sea perfecto (en el caso de que el n\'umero de
 conexiones sea muy alto).

El algoritmo por n\'umero de conexiones (o {\em least connections}) y
 {\em wheigthed least-connection} responde a un algoritmo din\'amico.
 Se basa en enviar las nuevas conexiones al nodo que tenga menos conexiones
 abiertas, esto requiere saber en todo momento cuantas conexiones abiertas
 tiene cada nodo, pero supone una ventaja en el comportamiento del sistema
 cuando el n\'umero de conexiones es elevado.
 
El algoritmo, que es sensible a los pesos, act\'ua dependiendo
 de los pesos que cada nodo tiene asignados en el director y se balancea
 seg\'un el n\'umero de conexiones abiertas\footnote{Aqu\'\i\ el problema de
 las conexiones residuales que est\'an en un TIME\_WAIT, un nodo
 puede tener m\'as conexiones que otro pero estar todas en un
 TIME\_WAIT y por lo tanto no consumir recursos, lo que implica que la
 carga no queda homogeneamente distribuida.}.
 Este grupo de algoritmos balancea mejor la carga en lineas generales pero
 requiere un nodo director m\'as potente para llevar el conteo del n\'umero
 de conexiones de cada nodo.

\vspace{.2in}
El algoritmo contador de conexiones con peso ser\'\i a el siguiente.

Existe una bater\'\i a de servidores para un determinado servicio con
{\tt N} servidores, a cada uno se le asigna un peso $W_{i}$(i=1...N) y
n\'umero de conexiones activas $C_{i}$(i=1...N).

 El n\'umero total de conexiones {\bf S} no es m\'as que la suma de
 las conexiones activas de cada nodo. De este modo la siguiente
 conexi\'on para el servicio sera para el nodo {\bf j} que cumpla: 

\vspace{.2in}
$(C_{j}/W_{j})=min\{C_{i}/W_{i}\}$(i= 1..N)

\vspace{.2in}
El \'unico inconveniente es que el kernel no puede realizar esta operaci\'on,
 ya que no dispone de los n\'umeros en coma flotante de forma que esta expresi\'on
 debe ser cambiada a algo como $C_{j}*W_{i}>C_{i}*W_{j}$ de manera que
 la comparaci\'on pueda ser evaluada por el kernel. Lo m\'as
 importante a tener en cuenta es que las conexiones con las que se
 trabaja son conexiones activas. Existen otros dos algoritmos m\'as
 basados en el algoritmo {\em least-connection} que mejoran este en
 algunas situaciones, estos dos algoritmos se basan en la localidad de
 las conexiones, e intentan que el mismo cliente vaya, en caso de que
 el balanceo de la carga lo permita, al mismo nodo servidor que fue en
 otras conexiones realizadas por este cliente.

Una vez vistos los fundamentos te\'oricos para ver como debe compilarse el kernel
 puede pasarse a la instalaci\'on y compilaci\'on del mismo.
 Respecto a este punto se da por sentado que el
 administrador sabe aplicar parches al kernel y compilarlos de manera correcta.
 
\vspace{.2in}
Para empezar hay que obtener las fuentes del parche del kernel,
 el programa {\em ipvsadm} y el script {\em configure}.

 Habr\'a que parchear el kernel (las versi\'on de las fuentes
 del kernel deben coincidir con la versi\'on de LVS), mediante el comando 
{\tt cat $<$parche$>$ | patch -p1} o {\tt patch -p1 $<$ $<$parche$>$}. Luego
 se deber\'an compilar con las opciones descritas anteriormente (para m\'as
 informaci\'on mini-Howto-LVS) y preparar el parche para las
 m\'aquinas que vayan a actuar como director.

 El nodo director puede ser una m\'aquina sin discos que cargue su
 kernel a trav\'es de la red mediante TFTP (ver la secci\'on referente a {\em Nodos sin discos})
 para luego componer su directorio ra\'\i z mediante NFSroot.
 La opci\'on de utilizar un diskette (o lilo) para ejecutar
 el kernel es la m\'as utilizada.

 Luego habr\'a que compilar e instalar las fuentes del programa
 {\bf ipvsadm} y el sistema estar\'a preparado.

\vspace{.2in}A partir de aqu\'\i\ pueden hacerse dos tipos de configuraciones
\begin{itemize}
 \item la primera exige un conocimiento del sistema LVS m\'as profundo, ya que todos los par\'ametros
 se configuraran de manera manual mediante la orden {\bf ipvsadm}
 \item la otra es utilizar el script en perl (para lo cual se debe tener
 instalado perl) para que configure los servidores y el director.
\end{itemize}
El programa {\bf ipvsadm} servir\'a para especificar
\begin{itemize}
  \item servicios y servidores que conoce y gestiona el director
  \item pesos de cada servidor respecto al servicio ofrecido
  \item algoritmo de gesti\'on (de {\em scheduling})
  \item a\~{n}adir servicios y servidores
  \item quitar servicios
  \item tambi\'en existen un par de programas al tipo de ipchains que permiten guardar configuraciones
\end{itemize}
Para configuraciones iniciales o sistemas complejos el script escrito
en perl est\'a preparado para varios sistemas
operativos del tipo Unix, por lo que puede evitar m\'as de un
dolor de cabeza al configurar nuestro sistema. Este script {\em
configure} obtiene la informaci\'on de un fichero de texto (las
fuentes contienen ejemplos de varios de estos ficheros) y genera otros archivos.
 Entre estos archivos est\'an el script de inicializaci\'on de LVS preparado
 para ser incluido en la secci\'on de comienzo {\em rc.d}, que configura desde las
 IP de las m\'aquinas que se le pasaron hasta la tabla de rutas, pasando por
 los interfaces que no deben hacer ARP.

Tambi\'en incluye los programas y archivos de configuraci\'on necesarios para
 luego utilizar en el programa de monitorizaci\'on MON.
 Es una ayuda c\'omoda para los que no quieran tener que configurar a mano
 de manera extensiva su LVS\footnote{Si bien no evita el tener que
 conocer de manera extensa el sistema.}.

Para utilizar {\em configure} simplemente hay que seguir los pasos
 que se ven en uno de los ficheros de configuraci\'on por defecto que
 viene en la versi\'on que se se haya obtenido, configurar los par\'ametros
 del sistema y ejecutar {\tt perl configure $<$fich\_de
 configuraci\'on$>$}. Al estar el script en perl son necesarios que los m\'odulos necesarios para ejecutarlo.
 La salida del programa ser\'a un
 script del tipo {\em rc.d} que puede ejecutarse en los servidores
 reales y en el director (el script sabr\'a donde se ejecuta).

\vspace{.2in}
Otro factor a tener en cuenta a la hora de configurar servicios
mediante {\em ipvsadm} son las conexiones persistentes.
 Hay que atender este tipo de conexiones en casos como 
 una sesi\'on HTTPS, en protocolos del tipo multipuerto como FTP (en los cuales
 los puertos 20 y 21 corresponden al mismo servicio) o sitios comerciales,
 donde un cliente debe cambiar del puerto 80 de HTTP al 443 para enviar
 por HTTPS sus datos bancarios.

Este problema requiere de configuraciones espec\'\i ficas en el director para
 que los servicios sean balanceados al mismo nodo, salt\'andose el algoritmo
 de balanceo.
 El caso de las conexiones persistentes es otro de los casos (junto con
 el de ARP) que dificulta la configuraci\'on de los servicios, pero al mismo
 tiempo es impensable un sitio en Internet que no vaya a proveer conexiones
 seguras a trav\'es de HTTPS o que simplemente tenga un FTP.
 En cualquier caso, la orden {\em ipvsadm} permite configurar este
 tipo de conexiones persistentes de manera bastante c\'omoda.
%---------------------------------------------------------------------------
\subsubsection{Instalaci\'on y configuraci\'on de un caso de estudio}

\hfill\line(1,0){400}

{\em A continuaci\'on se adjunta un caso pr\'actico de instalaci\'on de algunos servicios hasta ahora expuestos.

Corresponde a una de las experiencia pr\'acticas que Carlos Manzanedo y Jordi Polo realizaron en su
 proyecto de fin de Ingenier\'\i a Inform\'atica en el a\~{n}o 2001 en
 la Universidad de Alcal\'a de henares (Madrid).}

\hfill\line(1,0){400}

\vspace{.2in}
Al realizar la instalaci\'on nos hemos encontrado con otros problemas
 debidos mayormente a la topolog\'\i a y dise\~{n}o de la red utilizada.
 En la figura mostramos el esquema de nuestra imaplementaci\'on
 (VS-NAT y VS-DR) para probar LVS con servicios no persistentes como
 HTTP y telnet.
\begin{latexonly}
\ifpdf
        \begin{figure}[htbp]
        \includegraphics[bb = -100 375 0 0, scale=.6]{./pics/lvs_NAT_casa.png}
        \includegraphics[bb = -350 375 0 0, scale=.6]{./pics/lvs_DR_casa.png}
        \vspace{3.5in}
        \caption{Clusters HA. NAT y DR de un caso pr\'actico}
        \end{figure}
\else
\end{latexonly}
        \begin{figure}
        \centering
        \includegraphics{pics/lvs_NAT_casa}
        \includegraphics{pics/lvs_DR_casa}
        \caption{Clusters HA. NAT y DR un caso pr\'actico}
        \end{figure}
\begin{latexonly}
\fi
\end{latexonly}

\begin{table}
\begin{center}
\begin{tabular}{ | c | c | } \hline
Direcci\'on IP & Significado \\ \hline \hline
CIP & Direcci\'on del cliente \\ \hline
VIP & Direcci\'on virtual del servicio (en la red del cliente o
accesible desde \'esta) \\ \hline
DIP & Direcci\'on del director en la red privada de servidores reales \\ \hline
RIPn & Direcci\'o  IP del servidor real \\ \hline
DIR-ROUTER & Resto de las direcciones pertenecientes a los routers \\ \hline
\end{tabular}
\caption{Clusters HA. Relaci\'on de tipos de direcciones IP}
\end{center}
\end{table}

El nodo director es arrancado
 sin discos y esto no supone ninguna diferencia. La red interna pertenece
 a 10.0.0.0/24 y la externa a 192.168.10.0/24, el nodo director pertenece y encamina
 a las dos redes.
 Se ha utilizado un {\em hub} y cable coaxial para la conexi\'on.
 Para trazar paquetes en la red se utilizaron herramientas GPL como 
{\em ethereal} o {\em tcpdump} (suelen venir en la distribuci\'on habitual que utilices)
 y generaciones de filtros para facilitar su uso.

Configuramos LVS con LVS-NAT, de manera que en un principio no nos
tuvimos que preocupar del problema de ARP, que se puede evitar con 

\hspace{1in}\colorbox{gray}{{\tt echo 1 $>$ /proc/sys/net/ipv4/conf/lo0:1/hidden}}

 para que no mande respuestas ARP).

\vspace{.2in}
El funcionamiento es el siguiente\footnote{Para m\'as detalles puede comprobarse mediante {\em
ethereal} y {\em tcpdump}.}:
\begin{enumerate}
  \item el cliente solicita una conexi\'on con alg\'un servicio de VIP
  address, es decir ladirecci\'on virtual de los servicios),
  \item crea alg\'un paquete de nivel cuatro ya
sea TCP o UDP que env\'\i a al director VIP,
  \item  \'este reenv\'\i a el
paquete al nodo servidor real que decida el algoritmo de
encaminamiento pero cambi\'andole el dato destino (se cambia por la
direcci\'on del servidor real),
  \item  el paquete o petici\'on llega al
destino, es atendido por el servidor de dicho servicio (si existe) y
se genera la respuesta que se env\'\i a al cliente.
\end{enumerate}
 En este punto es donde es necesario activar {\em forwarding}
 (router) en el director, y a\'un m\'as, debe estar configurado NAT din\'amico
 para enmascarar todas las respuestas que salen de los servidores reales
 cuando salen hacia el cliente.

Quiz\'a la explicaci\'on sea algo liosa as\'\i\  que pongo un dibujo y explicaci\'on
 por puntos.
\begin{enumerate}
  \item Cliente env\'\i a petici\'on a VIP del director CIP-$>$VIP 
  \item Director LVS consulta tabla-HASH para ver si hay conexi\'on, si no la hay
 la crea seg\'un el algoritmo de {\em scheduling} del servicio.
  \item Director env\'\i a la petici\'on a el servidor elegido cambiando la direcci\'on
 fuente CIP-$>$RIP (paquete replica de el anterior CIP-$>$VIP).
  \item El servidor-real propio del servicio contesta mandando RIP-$>$CIP a su gateway
 por defecto, es decir en nodo director DIP.
  \item El director act\'ua como router-NAT y cambia el paquete de RIP-$>$CIP a VIP-$>$CIP
 y se lo env\'\i a al cliente.
\end{enumerate}
En estos pasos no he tenido en cuenta todas las peticiones ARP pertinentes.
 Estas peticiones pueden parecer que en un principio no tienen
 ning\'un efecto, pero uno de los problemas que hemos tenido en la
 configuraci\'on es que la cache de direccionamiento del kernel
 (as\'\i\  como la de ARP) conten\'\i an rutas que estropeaban el
 direccionamiento. Hemos tenido que limpiar estas caches mediante

\hspace{1in}\colorbox{gray}{{\tt echo 0 $>$ /proc/sys/net/ipv4/route/flush}}

 para {\em limpiar} las rutas, que ha sido lo que m\'as ha molestado.

Para configurar esta red arrancamos el servidor que baja su kernel por bootp/tftp y
 configura su directorio ra\'\i z con nfsroot, una vez que tenemos
 todos los ordenadores encendidos.

\vspace{.2in}
{\bf Configuraci\'on del sistema, relativa a IP's y tablas de rutas}

En esta explicaci\'on por puntos de las pautas seguidas para configurar de
 forma manual el sistema no entraremos en detalles en lo que se refiere
 a conceptos o configuraci\'on de NAT o ipchains, aunque se requiere
 un conocimiento m\'\i nimo de ambos para poder configurar el sistema.
De hecho, en este caso de estudio se dar\'a una configuraci\'on m\'\i nima para
 que el LVS funcione de manera correcta, pero se necesitara de m\'as reglas
 a\~{n}adidas a ipchains o Netfilter para proveer de un sistema seguro.
\begin{itemize}
  \item cliente (Redmond95) ip 192.168.10.2/24 sin {\em gateway} ni DNS (uno de los problemas
 es que requer\'\i a DNS para que funcionase el cliente de HTTP, a pesar de
 no utilizar en ning\'un momento nombres simb\'olicos.
 No sabemos ex\'actamente a qu\'e se puede deber esto.)

  \item servidores reales 
  \begin{itemize}
    \item nodo1 - ip 10.0.0.1/24 rutas a su propia red y gateway por defecto 10.0.0.21 
    \item nodo2 - ip 10.0.0.2/24 rutas a su propia red y gateway por defecto 10.0.0.21
  \end{itemize}

  \item nodo director.
  \begin{itemize}
    \item {\tt ifconfig eth0 10.0.0.21 netmask 255.255.255.0 up  ESTA ES LA DIP}
    \item {\tt ifconfig eth0:1 192.168.10.1 netmask 255.255.255.0 up ESTA ES LA VIP}
    \item {\tt route add -net 192.168.10.0 netmask 255.255.255.0 dev eth0}
    \item {\tt route add -net 10.0.0.0 netmask 255.255.255.0 dev eth0}
  \end{itemize}
 
\item arranque de servicios en nuestro caso {\t /etc/init.d/apache start}
en los dos servidores reales y configuraci\'on de telnet en {\em /etc/inetd.conf}

\item configuraci\'on del director: 

  \begin{itemize}
    \item primero hay que configurarlo como router para que haga NAT, es algo necesario,
 y se puede hacer mediante {\em ipchains} (como en nuestro caso) para
 los nuevos kernels, deben ser compilados sin compatibilidad hacia
 atr\'as con {\em ipchains}, es decir con {\em iptables/Netfilter}, y
 adem\'as no hace falta a\~{n}adir ninguna regla ya que el soporte
 propio de NAT esta implementado en el kernel.
 En nuestro caso:
    \begin{itemize}
      \item {\tt echo 1>/proc/sys/net/ipv4/ip\_forward}
      \item {\tt ipchains -A forward -p (UDP/TCP) -i eth0:1 -s localnet [PUERTO] -d 0/0 -j MASQ}
    \end{itemize}
  \end{itemize}
\end{itemize}
Esta cadena es susceptible de muchos cambios seg\'un el servicio que se quiera
 dar, por otro lado hay que recordar que se procurar\'a que no pasaren los
 mensajes ICMP, entre ambas redes, as\'\i\  que las comprobaciones de destino
 (por ejemplo de RIP->CIP, se deber\'\i an hacer mediante traceroute).
 En un entorno de producci\'on, esta cadena debe ser colocada seg\'un los requerimie
ntos de seguridad del sistema, se debe permitir NAT, pero no descuidar la
 seguridad del sistema.
\begin{itemize}
  \item Por otro lado, generalmente (y este ha sido otro problema a descubrir con
 ETHEREAL y TCPDUMP) los routers tienen habilitado el servicio ICMP-Redirects
 , que env\'\i an paquetes ICMP para que el cliente reenv\'\i e el mismo mensaje
 a dicha IP.
 SE DEBE DESHABILITAR ESTE COMPORTAMIENTO, para poder deshabilitarlo, hacemos:
  \begin{itemize}
    \item {\tt echo 0 $>$ /proc/sys/net/ipv4/conf/all/send\_redirect}
    \item {\tt echo 0 $>$ /proc/sys/net/ipv4/conf/eth0/send\_redirect}
    \item {\tt echo 0 $>$ /proc/sys/net/ipv4/conf/default/send\_redirect}
  \end{itemize}
\end{itemize}

\vspace{.2in}
{\bf Configuraci\'on del director con ipvsadm}

Con esto queda asegurado el buen funcionamiento NAT del servicio.
 En este punto es necesario probar el estado de la red de manera que se
 comporte seg\'un se espera, es mejor ver el comportamiento en un caso simple
 de fallo que en uno complejo, esto se puede probar haciendo un {\em traceroute}
 desde los servidores a el cliente y comprobar que se llega a el en dos
 saltos.

 Una vez comprobado esto, podemos pasar a la configuraci\'on del nodo director
 para que act\'ue de la forma requerida mediante VS-NAT en un primer caso.
 Con la orden {\em ipvsadm}.
 Lo m\'as importante es leer el manual de este programa que es realmente simple
 de configurar.
 En nuestro caso, hemos configurado los servicios telnet y www para ambos
 servidores con distintos algoritmos de balanceo.

\begin{verbatim}
Luis:~# ./activa
Luis:~# chmod 760 config
Luis:~# ./config
Luis:~# cat activa
#!/bin/bash

echo 1 > /proc/sys/net/ip4/ip_forward
echo 0 > /proc/sys/net/ip4/conf/all/send_redirects
echo 0 > /proc/sys/net/ip4/conf/default/send_redirects
echo 0 > /proc/sys/net/ip4/conf/eth0/send_redirects
ifconfig eth0:1 192.168.10.1 netmask 255.255.255.0 up
ifconfig eth0 10.0.0.21 netmask 255.255.255.0 up
ipchains -A forward -i eth0:1 -p tcp -s 10.0.0.0/24 -d 0/0 -j MASQ

Luis:~# cat config
#!/bin/bash

ipvsadm -A -t 192.168.10.1:23 -s wrr
ipvsadm -a -t 192.168.10.1:23 -r 10.0.0.2:23 -m -w 1
ipvsadm -a -t 192.168.10.1:23 -r 10.0.0.1:23 -m -w 1
ipvsadm -A -t 192.168.10.1:23 -s wlc
ipvsadm -a -t 192.168.10.1:23 -r 10.0.0.2:80 -m -w 3
ipvsadm -a -t 192.168.10.1:23 -r 10.0.0.1:80 -m -w 1

Luis:~# ipvsadm -L -n
IP Virtual Server version 1.0.5 (size=4096)
Prot LocalAddress: Port Scheduler Flags
  -> RemoeAddress:Port               Forward Weight ActiveConn InActConn
 TCP 192.168.10.1:23 wrr
  -> 10.0.0.0.1:23                   Masq    1      0          0
  -> 10.0.0.0.2:23                   Masq    1      0          0
 TCP 192.168.10.1:80 wlc
  -> 10.0.0.0.1:80                   Masq    1      0          0
  -> 10.0.0.0.2:80                   Masq    3      0          0
\end{verbatim}

Con estas l\'\i neas queda configurado, podemos ver conexiones y estados mediante
 varios programas como:
\begin{itemize}
  \item {\tt ipvsadm -L -n}, muestra el estado de LVS
  \item {\tt ipchains -L -M}, muestra conexiones enmascaradas
  \item {\tt netstat -c -M}, muestra estado de conexiones enmascaradas
  de manera continua
\end{itemize}
Para hacer la prueba en el cliente, con un navegador conectamos con 192.168.10.1
 en unas cuantas ventanas. Como el sistema de ficheros no es compartido
 en nuestro caso, pudimos ver como en algunas ventanas aparec\'\i a la p\'agina
 principal de un servidor y en otros casos (menos cantidad de ellos) la
 del servidor de menos peso.

\vspace{.2in}
 Con el caso de {\tt telnet} no sucede lo mismo. Para cada nueva conexi\'on
 alterna entre uno y otro servidor, propio del algoritmo de RR. Para poder
 hacer estas comprobaciones hay que deshabilitar la cache del navegador
 de manera que este realice una nueva conexi\'on cada vez que se haga la petici\'on
 de la p\'agina.

Existen herramientas preparadas para medir el rendimiento
 del un servidor web, como {\tt polygraph}.
 Existen diversos programas para probar como es el rendimiento de el servicio
 de los servidores o hacer un mont\'on de conexiones desde un mismo cliente
 a nuestro servicio de LVS.

El rendimiento mejorar\'\i a seguro si en lugar de configurar nuestros servidores
 con NAT los configuramos con DR, para lo cual casi no tenemos que tocar
 nada, {\em solamente} deshabilitar NAT a\~{n}adir interfaces lo con
 la direcci\'on VIP y configurar un router entre los servidores reales y el cliente externo.
 En los servidores reales hacer un:

\hspace{1in}\colorbox{gray}{{\tt echo 1 $>$ /proc/sys/net/ipv4/conf/lo/hidden}}

\vspace{.2in}
Para evitar el problema de ARP y configurar el nodo director de la siguiente manera:

\vspace{.2in}
\hspace{1in}\colorbox{gray}{{\tt ipvsadm -A -t 192.168.10.1:80 -s
wlc}}

 Crea servicio www asociado a la direcci\'on VIP balanceado mediante weight least-connectios

\vspace{.2in}
\hspace{1in}\colorbox{gray}{{\tt ipvsadm -a -t 192.168.10.1:80 -r
10.0.0.1:80 -g -w 1}}

 A\~{n}ade servidor a www con peso 1 

\vspace{.2in}
\hspace{1in}\colorbox{gray}{{\tt ipvsadm -a -t 192.168.10.1:80 -r
 10.0.0.2:80 -g -w 3}}

 A\~{n}ade servidor a www con peso 3

\vspace{.2in}
\hspace{1in}\colorbox{gray}{{\tt ipvsadm -A -t 192.168.10.1:23 -s rr}}

\vspace{.2in}
\hspace{1in}\colorbox{gray}{{\tt ipvsadm -a -t 192.168.10.1:23 -r 10.0.0.1:23 -g -w 1}}

\vspace{.2in}
\hspace{1in}\colorbox{gray}{{\tt ipvsadm -a -t 192.168.10.1:23 -r 10.0.0.2:23 -g -w 1}}

\vspace{.2in}
El par\'ametro {\tt -g} en la configuraci\'on de los clientes implica que la t\'ecnica de balanceo
 sera a traves de gateway, es decir mediante Direct Routing o encaminamiento
 directo. Solamente con cambiar el modo de encaminamiento en los servidores,
 que pasa a ser v\'\i a gateway (propio de DR), queda todo preparado.
 Por otro lado en la tabla de rutas de los servidores tiene que estar
 configurado el encaminador por defecto, y en caso de haber firewall
 \'este debe dejar pasar los paquetes que vayan de VIP-$>$CIP generados por la interfaz virtual
 de los servidores reales.

\vspace{.2in}
Como \'ultimas conclusiones al apartado de configuraci\'on de LVS hemos de
 a\~{n}adir que en las pruebas realizadas en nuestro caso, mediante la topolog\'\i a
 y dise\~{n}o visto arriba sobre un solo tramo Ethernet y con MOSIX instalado
 y funcionando en los servidores reales (es decir CARLOS y PROG) y la m\'aquina
 diskless accediendo mediante NFS a todos sus archivos, el rendimiento de
 la red es p\'esimo. Se producen colisiones cont\'\i nuamente, lo que provoca
 errores y retransmisiones continuas.

 Esta continua congesti\'on, debida a que la red sea lenta (10 Mbps),
 deber\'a tenerse en cuenta seriamente el dise\~{n}o de nuestra red al
 completo para que esta no se convierta en el cuello de botella del sistema.

Los programas sniffers {\em  ethereal} y {\em tcpdump} nos han
 ayudado a detectar los problemas generados por ARP as\'\i\ como el
 problema de inconsistencias de la cache o el env\'\i o de
 ICMP\_REDIRECTS, que hac\'\i an que las primeras pruebas fallasen continuamente.
 De esta manera, mediante filtros, se traceaba la red con fines de ver cual
 era el cambio de comportamiento respecto al explicado te\'oricamente en los
 apartados anteriores, y adecuarlo a las exigencias del m\'etodo elegido en
 LVS.
%---------------------------------------------------------------------------
\subsubsection{?`Y la alta disponibilidad?}
Llegados a este punto, tenemos nuestro servidor LVS funcionando, pero ?`qu\'e
 sucede en el caso de que uno de los servidores o directores falle? ?`c\'omo
 se comporta el sistema?

De la manera que lo tenemos configurado hasta este punto, un fallo en
 cualquier a de los nodos ser\'\i a fat\'\i dico en el sistema. En el
 caso de que el fallo estuviese en uno de los nodos servidores, el
 nodo director intentar\'\i a reenviar los paquetes del cliente al
 servidor, de manera que obtendr\'\i a fallo despu\'es de un tiempo, al estar el nodo o
 servicio ca\'\i do.

En el caso del servidor el problema ser\'\i a a\'un mayor, ya que producir\'\i a
 la p\'erdida total del servicio.
 La intenci\'on de cualquier sitio en Internet no es s\'olo proveer a sus usuarios
 de servicio durante alg\'un tiempo, el servicio debe estar funcionando en
 lo que se denomina en el argot t\'ecnico-empresarial 24x7, es decir 24 horas
 al dia 7 d\'\i as a la semana.
 Es aqu\'\i\ donde el proyecto LVS deja de manos de otras soluciones el proveer
 de alta fiabilidad al sistema.
 En un principio se recomienda utilizar ciertas herramientas con las que
 se han configurado varios sistemas como pueden ser:
\begin{itemize}
  \item Piranha
  \item LVS-GUI + Heartbeat + Ldirectord
  \item MON + Heartbeat
\end{itemize}
Pero sirve cualquier otra opci\'on que nos provea de alg\'un m\'etodo de mantener
 los servicios proporcionados en alto ante el mayor n\'umero de eventos catastr\'oficos.

\vspace{.2in}
Nosotros hemos decidido utilizar MON y heartbeat para nuestro sistema,
 como ejemplo de configuraci\'on para cluster de alta fiabilidad HA, en este
 apartado explicaremos c\'omo hemos configurado MON y qu\'e es este programa.

Para monitorizar los servidores reales, configuramos MON de la manera que
 se explicar\'a en el nodo o nodos servidores, de manera que se \'este continuamente
 monitorizando servidores o servicios, para controlar en todo momento el
 estado del cluster.
 Para asegurar la continuidad de un nodo servidor en el sistema se puede
 utilizar tambi\'en MON, pero es mejor utilizar Heartbeat para hacer la replica
 de este servidor, y en caso de estar en un entorno de producci\'on utilizar
 conexiones Ethernet y serial para asegurarnos de que la comunicaci\'on entre
 los directores es continua.

Para controlar la ca\'\i da de los servidores reales podemos pensar en un principio
 como soluci\'on de aproximaci\'on, un programa que haga pings cada cierto intervalo
 a los servidores y compruebe si \'estos est\'an en la red.
 Este programa lanzar\'\i a la ejecuci\'on de la orden {\em ipvsadm}
 con los par\'ametros adecuados para quitar o introducir al servidor
 en la tabla del nodo director.
 Otra opci\'on es utilizar el protocolo y sistema de gesti\'on de redes SNMP
 para comprobar en cada momento mediante peticiones snmpget, sobre la MIB
 de los agentes (en este caso los servidores) si estos proveen de los recursos
 necesarios a la red, por ejemplo espacio de disco duro, un proceso servidor,
 o incluso la carga y funcionamiento de las interfaces.
 Este sistema es en un principio el m\'as adecuado para la gesti\'on de nuestro
 cluster, pero tiene ciertas desventajas que evitan que sea utilizado.
 Entre estas desventajas se pueden contar:
\begin{enumerate}
  \item {\bf Inseguridad en la que esta actualmente SNMP.}

Hasta que no exista implementaci\'on
 en Linux de SNMPv3, ya que el mecanismo de autenticaci\'on es algo obsoleto
 y se necesita de un alto nivel de seguridad para poder correr SNMP en una
 red privada sin riesgos.

  \item {\bf Complejidad y carga.}

 SNMP permitir\'\i a una gesti\'on a niveles muy complejos.
 Mediante scripts podr\'\i amos comprobar a intervalos regulares el estado de
 los par\'ametros de la MIB sobre cada servidor, lo que implicar\'\i a un modelo
 de monitorizaci\'on complejo y adaptable en el sentido de que podr\'\i amos requerir
 mayor cantidad de informaci\'on que en cualesquiera de los otros m\'etodos,
 pero implicar\'\i a mucha m\'as carga en la red.

Probablemente la soluci\'on est\'a en a\~{n}adir una nueva red para el apartado
 de monitorizaci\'on.

  \item {\bf Mayor conocimiento y estudio del sistema.}

 Lo que supone encarecer el tiempo de creaci\'on de este y abaratar luego
 su mantenimiento.
\end{enumerate}
Existen m\'as puntos a tener en cuenta a la hora de elegir SNMP como m\'etodo
 de monitorizaci\'on.
 En cualquier caso, el uso de traps de SNMP nos permitir\'\i a de manera c\'omoda
 establecer mecanismos suficientes como para que el sistema estuviese funcionand
o de manera correcta sin ning\'un problema.
 Hasta el momento a nadie se ha puesto a dise\~{n}ar una MIB especial para LVS
 en los que se pueda manejar los nodos directores de manera remota o incluso
 la monitorizaci\'on de los nodos servidores, este sistema en el caso de ser
 implantado, ser\'\i a de suma utilidad a la hora de realizar la gesti\'on del
 cluster de una manera c\'omoda y sencilla desde otras estaciones y con programas
 como el HP-OPENVIEW o similares.

El m\'etodo de utilizar scripts para monitorizar y actuar sobre el sistema
 es el punto opuesto a la opci\'on SNMP.
 Tiene como desventajas, que es m\'as lento de desarrollar y cada nueva acci\'on
 de monitorizaci\'on puede tener consecuencias colaterales en el sistema,
 por lo que en muchos casos es necesario realizar un estudio de c\'omo ser\'a
 la monitorizaci\'on y comprobar que todos los componentes sean ortogonales
 entre s\'\i .
 Como ventaja de este sistema es que es tan adaptable como lo queramos hacer,
 lo podemos programar en C, C++, Perl o shell scripts si nos apetece, y
 tan adecuado a nuestro sistema como lo necesitemos, esto es una ventaja
 y un inconveniente a su vez, ya que ser\'a dif\'\i cil reutilizar el c\'odigo de
 un sistema a otro, teniendo por tanto un ciclo de implementaci\'on en varios
 sistemas mucho m\'as largo.

\vspace{.2in}
{\bf MON}

El m\'etodo que utilizaremos en este caso, es el que provee un paquete que
 incluye varios programas llamado MON.
 Este paquete est\'a hecho pr\'acticamente en perl, por lo que deberemos bajar
 no s\'olo el paquete MON sino todos los m\'odulos de perl que se requieran
 para correr el programa.

 La soluci\'on, MON, es una soluci\'on intermedia entre la mastod\'ontica SNMP
 y la casera SCRIPT.
 Es configurable, requiere poco tiempo de puesta a punto, y adem\'as tambi\'en
 aporta tanta adaptabilidad a nuestras exigencias como nosotros queramos.
 Este paquete fue escrito por un administrador de sistemas de Transmeta
 llamado Jim Trocki, la compa\~{n}\'\i a donde trabaja Linus Torvalds,
 y est\'a pr\'acticamente incluido en la totalidad de las
 distribuciones que conozco.

MON es un agente de tipo general para monitorizar tanto servicios como
 servidores y lanzar alertas que pueden ser f\'acilmente implementadas
 en C, perl o cualquier otro lenguaje.
 MON lee de un fichero de configuraci\'on su forma de actuaci\'on, dicho fichero
 tiene una forma similar en funcionamiento a SNMP, es una manera muy adaptable
 de monitorizar cualquier sistema.


En dicho fichero de configuraci\'on podemos encontrar las siguientes secciones:
\begin{itemize}
  \item La primera es la secci\'on {\em hostgroups}, que aporta los grupos a los que se
 realizara la monitorizaci\'on.

\item La segunda es la secci\'on de vistas, que se compone de una o m\'as vistas sobre
 los grupos de trabajo que contiene las especificaciones de la monitorizaci\'on
 y la actuaci\'on que se har\'a acorde con cada evento.
 En las zonas de vistas se pueden separar en: 
  \begin{itemize}
    \item El servicio a monitorizar, pueden contenerse uno o m\'as servicios en cada
 vista, de manera que se especifica en ellos.
    \item El intervalo de resoluci\'on en el que se realizaran los sondeos de las monitoriza
ciones.
    \item Las traps, interrupciones o se\~{n}ales que se utilizar\'an.
    \item El programa monitor que se utilizar\'a para cada servicio.
    \item La dependencia entre servicios y el comportamiento en caso de dependencias
    \item El campo periodo que especifica entre qu\'e fechas se realizar\'a la monitorizaci\'on
 y de qu\'e manera se proceder\'a en caso de ciertos eventos.
 Este campo posee a su vez otros campos como pueden ser
    \begin{itemize}
      \item Periodo real
      \item Programa de alerta o control de eventos
      \item Varios par\'ametros para el funcionamiento y control de las alertas
    \end{itemize}
  \end{itemize}
\end{itemize}
Una vez explicada la estructura del fichero de configuraci\'on, pasaremos
 a explicar cu\'al es el m\'etodo de funcionamiento de MON.

\vspace{.2in}
 MON como ya hemos dicho se compone de un agente planificador que solamente
 se encarga de interpretar el fichero de configuraci\'on y realizar peri\'odicamente
 y en las horas se\~{n}aladas las llamadas oportunas a los programas de monitorizaci
\'on y alerta sobre los nodos perteneciente a un conjunto hostgroup.
 De esta manera, el programa monitor puede ser implementado por un programador,
 de manera que este es independiente de MON, mientras que acepte los par\'ametros
 que MON le env\'\i a y las variables de entorno que adquiere al ser hijo de
 este.

El programa monitor es llamado peri\'odicamente para cada nodo perteneciente
 a un grupo de host o host particulares pertenecientes a dicha vista, hace
 su monitorizaci\'on espec\'\i fica y da un c\'odigo en la llamada {\em exit()}.
 Este c\'odigo debe ser interpretado por la secci\'on de alertas, de manera
 que se proceda a la ejecuci\'on necesaria para el manejo del evento en el
 caso de que el c\'odigo de salida del monitor sea el que decide de que manera
 se controla el evento.

De esta manera, lo \'unico que debe crear el programador son los programas
 monitor y alerta, donde el programa monitor se encargar\'a de monitorizar
 los eventos de los que depende nuestro sistema, ya sean estos adquisici\'on
 en una tarjeta de adquisici\'on de datos como control de un puerto ttyS$<$X$>$
 como el control de acceso a un servidor de un determinado servicio.
 Adem\'as programado mediante el lenguaje que resulte m\'as c\'omodo al programador,
 lo que facilita la tarea.

Por otro lado el programa de alerta debe atender a dos tipos de par\'ametros
 y variables de entorno pasados por MON.
 El primer tipo son los c\'odigos de retorno del programa monitor que deber\'a
 entender a la perfecci\'on para poder ejecutar el manejo del evento que detectase
 el monitor.
 El segundo son los par\'ametros que proporciona MON para el control de ca\'\i da
 o puesta a punto de un servicio.

\vspace{.2in}
El paquete MON lleva incorporado unos cuantos programas monitores y alertas
 que se guardan dentro de {\em /usr/lib/mon/}, estos programas por
 defecto suelen bastar para llevar a cabo la monitorizaci\'on que nosotros necesitamos.
 Entre estos programas se encuentran los siguientes monitorizadores:

{\tt ftp.monitor} monitor de FTP, comprueba el estado para poder acceder a un servidor
 FTPD mediante la cuenta que le proporcionemos como par\'ametro en el fichero
 de configuraci\'on.

{\tt http.monitor} monitor HTTP, igual que el anterior pero para www.

{\tt telnet.monitor} idem que los anteriores.

{\tt smtp.monitor} idem para este otro protocolo.

{\tt dialin.monitor} entradas de llamadas en el modem.

{\tt snmp.monitor} compatible con SNMP, para comprobar el acceso a un agente.

Y muchos otros monitores que permiten monitorizar en general servicios de
 red mediante programas conocidos como ping, o peticiones a determinada
 pagina del servidor o a determinado recurso.
 De esta manera podemos ver el car\'acter adaptable que posee este tipo de
 configuraci\'on.

\vspace{.2in}
Adem\'as de los monitores se encuentran los scripts o programas de alerta
 que funcionan de la misma manera que los monitores, son llamados por MON
 con determinados par\'ametros de manera que se act\'ua acorde con el evento
 que gener\'o la alerta, subsanando alg\'un problema, guardando en los log que
 lo provoc\'o, solucionando en la manera de lo posible dicho problema e informando
 mediante alg\'un m\'etodo al administrador del sistema, acerca del evento que
 produjo la llamada.
 Existen m\'as programas externos que controlan el funcionamiento de MON como
 son, {\em monshow} y {\em  mon-cgi}, estos permiten ver y controlar
 desde l\'\i nea de \'ordenes o desde un navegador mediante el acceso
 a una WEB el estado y funcionamiento de MON. En nuestro caso no los
 hemos probado, ya que la soluci\'on que busc\'abamos no depend\'\i a
 ni requer\'\i a de este CGI.

Una vez explicado el funcionamiento de MON, debemos explicar qu\'e servicios
 debemos monitorizar, de qu\'e manera los podemos monitorizar y que medidas
 debemos tomar ante determinados eventos.
 Nuestra intenci\'on es explicar este apartado utilizando como ejemplo el
 caso de estudio aportado arriba, de manera que se pueda comprobar como
 es el funcionamiento de MON y qu\'e factores son importantes a la hora de
 configurar un sistema de monitorizaci\'on de este tipo.

\vspace{.2in}
{\bf Factores que intervienen en la configuraci\'on de MON}

Para empezar debemos hacer un estudio de ciertos factores que nos pueden
 interesar y que pueden afectar a nuestro sistema como son.
\begin{enumerate}
  \item Servicios que poseemos en nuestro cluster.
  \item M\'aquinas dentro del cluster.
 Es necesario para controlar la resoluci\'on de la monitorizaci\'on, y que la
 carga de esta no sea demasiado alta.
  \item Comportamiento ante ca\'\i das.
\end{enumerate}
El apartado de servicios es necesario conocerlo a fondo.
 Es muy sencillo decir que se necesita un servicio de HTTP, otro de FTP
 y otro de squid, pero saber los temporizadores de cierre de conexi\'on de
 dichos servicios no es tan f\'acil, en cambio seguramente estemos interesados
 en poder disponer de una monitorizaci\'on sobre estos serv\'\i cios.

Pongamos el ejemplo de un servicio de telnet sobre el que se activa alg\'un
 tipo de envoltura como TCP wrapper, o kerberos.
 Este telnet tardar\'a algo m\'as en terminar la configuraci\'on de la sesi\'on
 telnet y por tanto el tiempo de establecimiento sera algo m\'as alto.
 De esta manera cuando un script que intente comprobar el estado de un servidor
 {\em telnetd} y \'este tarde m\'as de lo que esperaba (aunque sea tan solamente un
 segundo), se mandar\'a la alerta apropiada quitando el servicio del LVS,
 aunque dicho servicio funcione y por tanto se dispondr\'a de una m\'aquina
 menos dentro cluster con la que hacer el balanceo.
 Tambi\'en puede ser necesaria hacer una previsi\'on de cu\'ando se deben realizar
 m\'as monitorizaciones sobre un servicio, o las horas a las que no son necesarias
 hacerlas.
 Hay que recordar que MON es un programa que corre en el nodo director,
 y al ser este un punto cr\'\i tico del sistema es conveniente mantenerlo lo
 m\'as descargado posible para que se dedique a lo que realmente debe hacer,
 balancear conexiones y proporcionar servicios.

\vspace{.2in} 
El apartado de las m\'aquinas que contiene el cluster es necesario para establecer
 la tasa o intervalo de monitorizaci\'on.
 Este intervalo afectar\'a en dos aspectos.
 El primero es la carga del nodo director donde se ejecuta MON, al estar
 continuamente lanzando programas monitores y de alerta, el nodo consume
 recursos como son memoria y CPU, por lo que puede ser un factor importante
 a tener en cuenta en caso de haber instalado un nodo director inadecuado
 en requerimientos para dicha labor.

Por otro lado est\'a la carga sobre la red sobre la que tanto estamos hablando
 a lo largo de todo el proyecto.
 Mantener la red lo menos congestionada posible es cuesti\'on de cuidar este
 tipo de apartados y de tener un dise\~{n}o de red previo adaptado a las necesidades
 que se preveen para nuestro sistema.

\vspace{.2in} 
Por \'ultimo hemos de definir cual ser\'a el comportamiento ante ca\'\i das.
 Generalmente en nuestro caso, el comportamiento suele ser algo como, quitar
 la entrada del nodo director DIRECCI\'ON-SERVICIO-PESO, para que dicho nodo
 no sea tenido en cuenta en las siguientes decisiones del nodo director.

Avisar al administrador mediante cualquier m\'etodo o recurso, enviando mensajes
 al m\'ovil o mails a la cuenta del administrador o dando pitidos incesantes
 para que alguien trate de solucionar el problema lo antes posible.
 Intentar solucionar el problema desde el nodo director suele requerir de
 sistemas expertos que eval\'uen las probabilidades de la causa que provoc\'o
 la ca\'\i da e intente solucionarse.
 Registrar los eventos que sucedieron de manera que se sepa cuales fueron
 las causas de ca\'\i da del servicio en cualquier momento.
 
Se pueden monitorizar en un LVS cualquier tipo de servicios o recursos,
 desde la accesibilidad a un nodo con fping.monitor hasta el espacio que
 queda libre en el sistema de almacenamiento distribuido NFS.
 De manera general, se suele monitorizar como m\'\i nimo el acceso a los servidores
 y el acceso a los servicios.

La utilizaci\'on del acceso a los servicios es m\'as conveniente que el acceso
 a ca\'\i da de un servidor, pero implica m\'as carga de red, por lo que depende,
 qu\'e m\'etodo ser\'a elegido monitor del sistema.
 Los programas monitores de un servicio, suelen ser programas que hacen
 una petici\'on al servicio de car\'acter general (como pedir la informaci\'on
 de versi\'on o p\'agina principal de un servidor HTTP), esto conlleva mucha
 m\'as carga en la red y en el sistema general que un fping destinado a un
 grupo de hosts, pero por el contrario, si imaginamos una situaci\'on muy
 usual como es la de tener una m\'aquina con varios servicios activados no
 es dif\'\i cil entender que puede caer un servicio, y seguir funcionando el
 otro, y por lo tanto fping dar\'a una monitorizaci\'on err\'onea respecto a lo
 que en un principio requer\'\i amos para el sistema.
%---------------------------------------------------------------------------
\subsubsection{Conclusiones}
El servicio ofrecido por la conjunci\'on de LVS, MON y Heartbeat pueden llegar
 a ser tan potente como otras aplicaciones o configuraciones propietarias
 que existen en el mercado a un precio mucho mayor.
 Uno de los problemas que no hemos comentado que tiene LVS de momento es
 que al caer el nodo director y retomar su trabajo el nodo de backup mediante
 heartbeat como veremos en el apartado de heartbeat, el contenido de la
 tabla hash, as\'\i\  como las conexiones y toda la informaci\'on del nodo director
 se pierden, esto produce en los clientes que ten\'\i an una conexi\'on en curso,
 la p\'erdida de dicha conexi\'on.

En un principio y dependiendo de qu\'e servicios puede ser m\'as o menos dr\'astico.
 La gente del proyecto LVS esta trabajando en mejorar este comportamiento,
 y se espera que dada la facilidad y adaptabilidad con la que pretende dotar
 Alan Robertson el proyecto heartbeat, cubrir este problema sea m\'as simple
\footnote{Si bien un nodo que ha caido, no puede enviar los \'ultimos ack que recibi\'o
 de una conexi\'on, con lo cual, y pese a los intentos, el problema no es
 de resoluci\'on f\'acil, y ha sido aplazado por la gente de LVS desde hace
 un tiempo.}.
