Universidad Dominicana

O&M
Presentacin

Nombres:
- Juan Carlos Custodio Jaquez
- Brian Jimnez
- Juan Algenis Meja
- Johansel Pujols

Matriculas:
- 16-EISN-1-145
- 16-EISN-1-259
- 16-EIST-1-077
- 16-EISM-1-165

Grupo:
#4

Materia:
Introduccin a la gestin de los centros de datos

Maestro:
Edwin Lpez

Tema:
Administracin avanzada de sistemas III: Clustering
Alta disponibilidad
Alta disponibilidad (High availability) es un protocolo de diseo del sistema y su
implementacin asociada que asegura un cierto grado absoluto de continuidad
operacional durante un perodo de medicin dado. Disponibilidad se refiere a la habilidad
de la comunidad de usuarios para acceder al sistema, someter nuevos trabajos, actualizar
o alterar trabajos existentes o recoger los resultados de trabajos previos. Si un usuario no
puede acceder al sistema se dice que est no disponible. El trmino tiempo de inactividad
(downtime) es usado para definir cundo el sistema no est disponible.

Tiempo de inactividad

Tpicamente tiempo de inactividad planificado es el resultado del mantenimiento que

resulta perjudicial para la operacin del sistema y usualmente no puede ser evitado con la
configuracin actualmente instalada. Eventos que generan tiempos de inactividad
planificados quizs incluyen parches al software del sistema que requieran un rearranque
o cambios en la configuracin del sistema que toman efecto despus de un rearranque. En
general el tiempo de inactividad planificado es usualmente el resultado de un evento
lgico o de gestin iniciado.

Tiempos de inactividad no planificado surgen de algn evento fsico tales como fallos en
el hardware o anomalas ambientales. Ejemplos de eventos con tiempos de inactividad no
planificados incluyen fallos de potencia, fallos en los componentes de CPU o RAM, una
cada por recalentamiento, una ruptura lgica o fsica en las conexiones de red, rupturas
de seguridad catastrficas o fallos en el sistema operativo, aplicaciones y middleware.

Muchos puestos computacionales excluyen el tiempo de inactividad planificado de los

clculos de disponibilidad, asumiendo, correcta o incorrectamente, que el tiempo de
actividad no planificado tiene poco o ningn impacto sobre la comunidad de usuarios
computacionales. Al excluir el tiempo de inactividad planificado, muchos sistemas
pueden reclamar tener una fenomenal alta disponibilidad, la cual da la ilusin de
disponibilidad continua. Sistemas que exhiben verdadera disponibilidad continua son
comparativamente raros y caros, y ellos tienen diseos cuidadosamente implementados
que eliminan cualquier punto de fallo y permiten que el hardware, la red, el sistema
operativo, middleware y actualizacin de aplicaciones, parches y reemplazos se hagan en
lnea.

Clculos porcentuales

Disponibilidad es usualmente expresada como un porcentaje del tiempo de

funcionamiento en un ao dado. En un ao dado, el nmero de minutos de tiempo de
inactividad no planeado es registrado para un sistema, el tiempo de inactividad no
planificado agregado es dividido por el nmero total de minutos en un ao
(aproximadamente 525.600) produciendo un porcentaje de tiempo de inactividad; el
complemento es el porcentaje de tiempo de funcionamiento el cual es lo que
denominamos como disponibilidad del sistema. Valores comunes de disponibilidad,
tpicamente enunciado como nmero de "nueves" para sistemas altamente disponibles
son:

99,9% = 43.8 minutos/mes u 8,76 horas/ao ("tres nueves")

99,99% = 4.38 minutos/mes o 52.6 minutos/ao ("cuatro nueves")
99,999% = 0.44 minutos/mes o 5.26 minutos/ao ("cinco nueves")

Es de hacer notar que tiempo de funcionamiento y disponibilidad no son sinnimos. Un

sistema puede estar en funcionamiento y no disponible como en el caso de un fallo de
red. Se puede apreciar que estos valores de disponibilidad son visibles mayormente en
documentos de ventas o marketing, en lugar de ser una especificacin tcnica
completamente medible y cuantificable.

Medida e interpretacin

Claramente como la disponibilidad medida est sujeta a algn grado de interpretacin.

Un sistema que ha estado en funcionamiento por 365 das en un ao no bisiesto quiz ha
sido eclipsado por un fallo de red que dur 9 horas durante un periodo de uso pico; la
comunidad de usuarios ver el sistema como no disponible, mientras el administrador del
sistema reclamara el 100% de tiempo de funcionamiento. Sin embargo siguiendo la
verdadera definicin de disponibilidad, el sistema estar aproximadamente 99.897%
disponible (8751 horas de time out de las 8760 horas por ao no bisiesto).

Tambin sistemas experimentando problemas de rendimiento son frecuentemente

estimados como entera o parcialmente no disponibles por los usuarios mientras
administradores quizs tengan una diferente (y probablemente incorrecta, ciertamente en
el sentido del negocio) percepcin. Similarmente no disponibilidad de funciones de
aplicacin no seleccionadas quizs pasen inadvertidas para administradores sin embargo
podran ser devastadoras para usuarios una verdadera medida de disponibilidad es
integral.

Disponibilidad debe ser medida para ser determinada, idealmente con herramientas de
monitorizacin comprensivas ("instrumentacin") que son ellas mismas altamente
disponibles. Si hay una falta de instrumentacin, sistemas soportando un alto volumen de
procesamiento de transacciones a travs del da y la noche tales como procesamiento de
tarjetas de crdito o conmutadores telefnicos, son frecuentemente e inherentemente
mejor monitorizados, al menos por los mismos usuarios, que sistemas que experimentan
pausas peridicas en la demanda.

Conceptos relacionados

Tiempo de recuperacin esta cercanamente relacionado con la disponibilidad, que es el

tiempo total requerido para un apagn planificado o el tiempo requerido para la
recuperacin completa de un apagn no planificado. Tiempo de recuperacin puede ser
infinito con ciertos diseos y fallos del sistema, recuperacin total es imposible. Uno de
tales ejemplos es un incendio o inundacin que destruye un centro de datos y sus sistemas
cuando no hay un centro de datos secundario para recuperacin frente a desastres.

Otro concepto relacionado es disponibilidad de datos, que es el grado para el cual las
bases de datos y otros sistemas de almacenamiento de la informacin que registran y
reportan fielmente transacciones del sistema. Especialistas de gestin de la informacin
frecuentemente enfocan separadamente la disponibilidad de datos para determinar
perdida de datos aceptable o actual con varios eventos de fracasos. Algunos usuarios
pueden tolerar interrupciones en el servicio de aplicacin pero no prdida de datos.

Diseo de un sistema de alta disponibilidad

Paradjicamente, aadiendo ms componentes al sistema total puede socavar esfuerzos

para lograr alta disponibilidad. Esto es debido a que sistemas complejos tienen
inherentemente ms puntos de fallos potenciales y son ms difciles de implementar
correctamente. La mayora de los sistemas altamente disponibles extraen a un patrn de
diseo simple: un sistema fsico multipropsito simple de alta calidad con redundancia
interna comprensible ejecutando todas las funciones interdependientes emparejadas con
un segundo sistema en una localizacin fsica separada.

Este clsico patrn de diseo es comn entre instituciones financieras por ejemplo. La
industria de la informtica y las comunicaciones ha establecido el Servicio Forum de la
Disponibilidad acoger la creacin de productos de infraestructura de red, servicios y
sistemas de alta disponibilidad. El mismo principio de diseo bsico se aplica ms all de
la informtica en diversos campos como potencia nuclear, aeronutica y cuidados
mdicos.

Clster de alta disponibilidad

Un clster de alta disponibilidad es un conjunto de dos o ms mquinas que se
caracterizan por mantener una serie de servicios compartidos y por estar constantemente
monitorizndose entre s.

No hay que confundir un clster de alta disponibilidad con un clster de alto rendimiento.
El segundo es una configuracin de equipos diseado para proporcionar capacidades de
clculo mucho mayores que la que proporcionan los equipos individuales, mientras que
el primer tipo de clster est diseado para garantizar el funcionamiento ininterrumpido
de ciertas aplicaciones.

Clases

Podemos dividirlo en dos clases:

Alta disponibilidad de infraestructura: si se produce un fallo de hardware en alguna de las

mquinas del clster, el software de alta disponibilidad es capaz de arrancar automticamente
los servicios en cualquiera de las otras mquinas del clster (failover). Y cuando la mquina
que ha fallado se recupera, los servicios son nuevamente migrados a la mquina original
(failback). Esta capacidad de recuperacin automtica de servicios nos garantiza la alta
disponibilidad de los servicios ofrecidos por el clster, minimizando as la percepcin del
fallo por parte de los usuarios.
 Alta disponibilidad de aplicacin: si se produce un fallo del hardware o de las aplicaciones
de alguna de las mquinas del clster, el software de alta disponibilidad es capaz de arrancar
automticamente los servicios que han fallado en cualquiera de las otras mquinas del clster.
Y cuando la mquina que ha fallado se recupera, los servicios son nuevamente migrados a la
mquina original. Esta capacidad de recuperacin automtica de servicios nos garantiza la
integridad de la informacin, ya que no hay prdida de datos, y adems evita molestias a los
usuarios, que no tienen por qu notar que se ha producido un problema.

Clculo de la disponibilidad

En un sistema real, si falla uno de los componentes, es reparado o sustituido por un nuevo
componente. Si este nuevo componente falla, es sustituido por otro, y as sucesivamente.
El componente fijo se considera en el mismo estado que un nuevo componente. Durante
su vida til, uno de los componentes pueden ser considerado en uno de estos estados:
funcionando o en reparacin. El estado funcionando indica que el componente est
operacional y el en reparacin significa que ha fallado y todava no ha sido sustituido por
un nuevo componente.

En caso de defectos, el sistema va funcionando en modo reparacin, y cuando se hace la

sustitucin volver al estado funcionando. Por lo tanto, podemos decir que el sistema
tiene durante su vida, una media de tiempo para presentar fallas (MTTF) y un tiempo
medio de reparacin (MTTR). Su tiempo de la vida es una sucesin de MTTFs y MTTRs,
a medida que este va fallando y siendo reparado. El tiempo de vida til del sistema es la
suma de MTTFs en ciclos MTTF + MTTR ya vividos.

En forma simplificada, se dice que la disponibilidad de un sistema es la relacin entre la

duracin de la vida til de este sistema y de su tiempo total de vida. Esto puede ser
representado por la frmula de abajo:

Disponibilidad = MTTF / (MTTF + MTTR)

En la evaluacin de una solucin de alta disponibilidad, es importante tener en cuenta si

en la medicin de MTTF son vistos como fallas las posibles paradas planificadas.

High-Availability Linux
El proyecto Linux-HA ( Linux de Alta disponibilidad ) provee una solucin cluster de
alta disponibilidad para Linux, FreeBSD, OpenBSD, Solaris y Mac OS X promoviendo
fiabilidad, disponibilidad y servicialidad.

El producto principal del proyecto es Heartbeat, un programa de gestin de clusters

portable con licencia GPL para clusters de alta disponibilidad. Sus ms importantes
caractersticas son:

Mximo nmero de nodos no establecidos. Heartbeat puede ser usado tanto para clusters
grandes como clusters de menor tamao.
Motorizacin de recursos : recursos pueden ser reiniciados o movidos a otro nodo en caso de
fallo.
 Mecanismo de cercado para remover nodos fallidos en el cluster
Gestin de recursos basado en directivas, inter-dependencia de recursos y restricciones
Reglas basadas en el tiempo permiten diferentes directivas depndiendo del tiempo.
Varios scripts de recursos ( para Apache, DB2, Oracle, PostgreSQL, etc ) incluidos.
GUI para configurar, controlar y monitorizar recursos y nodos

Historia

El proyecto se origin desde una lista de correo en noviembre de 1997. Eventualmente

Harald Milz escribi una especie rara de Linux-HA HOWTO. Diferentemente de la
mayora de HOWTOs, este no trataba sobre la configuracin de algn software existente
sino que era una coleccin de tcnicas HA que podan ser utilizadas para escribir software
de HA para Linux.

Cambios posteriores

Alan Robertson se inspir en esta descripcin y pens que el quizs podra escribir algo
del software para que el proyecto actuara como una especie de semilla de cristal inicial
de modo a ayudar el autoarranque del proyecto. El consigui ejecutar el software inicial
el 18 de marzo de 1998. Cre el portal web para el proyecto el 19 de octubre de 1998, y
la primera versin del software fue liberada el 15 de noviembre de 1998. El primer cliente
en produccin de este software fue Rudy Pawul de ISO-INE. El portal web de ISO-INE
entr en produccin en el segundo semestre de 1999. En este punto, el proyecto estaba
limitado a dos nodos y la semntica absorbida muy simple y ninguna monitorizacin de
recursos.

Esto fue subsanado con versin 2 del software , el cual aada clusters de nodos,
monitorizacin de recursos, dependencias y directivas. La versin 2.0.0 sali publicada
el 29 de julio del 2005. Este release representaba otro hito importante ya que esta es la
primera versin donde las contribuciones ms grandes ( en trminos de tamao de cdigo
) fueron hechas por la comunidad Linux-HA a mayores. Esta serie de lanzamientos trajo
el proyecto a un nivel caracterstico de paridad o superioridad con respecto al software
comercial HA.

A partir de la distribucin 2.1.3 de Heartbeat , se ha sustituido el cdigo del gestor de

recursos del cluster (el CRM) por el componente pacemaker. Pacemaker constituye, por
si mismo, un proyecto independiente y no es una bifurcacin del proyecto original de
Linux-HA. El CRM que utilizan las nuevas distribuciones de Heartbeat forma parte de
este nuevo proyecto y no volver a distribuirse como parte del proyecto principal.

Los objetivos que se pretenden con esta decisin son, entre otros:

Dar soporte, por igual, tanto a las pilas de cluster OpenAIS como a Heartbeat.
Desacoplar los ciclos de desarrollo de los dos proyectos.
Mejorar y hacer ms estables las interfaces.

El proyecto pacemaker aconseja la utilizacin de OpenAIS.

Qu es un Balanceador de Carga? Qu
es HA Proxy?
Un balanceador de carga es un dispositivo que acta como proxy inverso distribuyendo
el trfico de red o de una aplicacin a varios servidores. Los balanceadores se utilizan
para incrementar la capacidad de procesamiento y confiabilidad. Los balanceadores
aseguran la disponibilidad monitorizando el estado de las aplicaciones y enviando las
peticiones a los servidores que puedan responder.

Los balanceadores se agrupan en 2 categoras:

Layer4: actan sobre los datos de la red y protocolos IP, TCP, FTP y UDP.

Layer7: distribuyen peticiones en la capa de aplicacin con protocolos como HTTP o

TCP

Ambos tipos reciben las peticiones y la distribuyen a un servidor en base a un algoritmo

como:

Round robin

Weighted round robin

Least connections

Least response time

Los balanceadores de tipo Layer7 pueden distribuir las peticiones en datos de aplicacin
como cookies, headers HTPP, datos del mensaje,

HAProxy es un software libre que acta como balanceador de carga (load balancer)
ofreciendo alta disponibilidad, balanceo de carga y proxy para comunicaciones TCP y
HTTP. HAProxy utiliza tcnicas de arquitecturas de SO para ofrecer un gran rendimiento.
HAProxy puede verse como una solucin de emergencia o de respaldo al balanceador
hardware.

HAProxy puede instalarse sobre Linux, Solaris, FreeBSD y OpenBSD.

Otras soluciones para balanceadores de carga software podran ser:

Linux Virtual Servers (LVS)

Nginx (engine X)

Pound

.Pen
Open Grid Scheduler / Grid Engine
Open Grid Scheduler / Grid Engine es un sistema de colas por lotes de cdigo abierto compatible
con soporte comercial para la administracin de recursos distribuidos. OGS / GE est basado en
Sun Grid Engine y mantenido por el mismo grupo de desarrolladores externos (es decir, no Sun)
que comenzaron a contribuir con cdigo desde 2001.

En diciembre de 2010, Oracle pas oficialmente la antorcha para mantener el cdigo

fuente abierto de Grid Engine para el proyecto Open Grid Scheduler .

Propiedad intelectual
Todas las versiones de Grid Engine distribuidas por el proyecto Open Grid Scheduler solo
contienen cdigo escrito por los desarrolladores del proyecto Open Grid Scheduler (es decir,
poseemos completamente la propiedad intelectual) y el cdigo heredado de Sun Grid Engine
6.2u5.

Las contribuciones de cdigo de terceros son bienvenidas, pero necesitaremos auditar

cuidadosamente el cdigo antes de que podamos incluirlo en nuestro rbol. (nase a
nuestra lista de correo y trabajaremos con usted!)

Tenemos proveedores independientes de software que envan nuestro cdigo con sus
productos, por lo que le prestamos especial atencin a cuestiones de propiedad intelectual
y derechos de autor.

Plataformas compatibles
Actualmente, Grid Scheduler / Grid Engine es compatible con las siguientes plataformas:

AIX
BSD, incluidos FreeBSD y NetBSD, en la mayora de las arquitecturas compatibles con
los sistemas operativos
HP-UX en IA64 y PA-RISC
IRIX
Linux en Alpha, ARM, IBM POWER y PowerPC, mainframe IBM System z, IA64,
MIPS y Loongson, SPARC, x86 y x86-64
Mac OS X
Solaris en SPARC, x86 y x86-64
Tru64
Windows (SFU y Cygwin, un puerto nativo de Windows se lanzar en el futuro)

Otras plataformas con soporte limitado: Cray UNICOS, NEC Super-UX, OpenBSD
(avsenos si est ejecutando esos sistemas operativos)

Grid Engine en Oracle

Oracle contina mejorando y manteniendo el producto comercial de Oracle Grid Engine . Hay un
foro en lnea en Oracle , con el apoyo activo de los desarrolladores de Oracle Grid Engine.

Licencia
Open Grid Scheduler / Grid Engine se lanza bajo la Licencia de fuente de estndares de la
industria de Sun (SISSL) . El nuevo cdigo (nuevo archivo) tiene licencia bajo la licencia BSD.
La letra pequea: la mayora del cdigo fue tomado de Sun Grid Engine (ms
especficamente SGE 6.2 actualizacin 5 lanzado en 2009), que fue desarrollado por
Sun Microsystems. Usando 6.2u5 como punto de partida, agregamos nuevas
caractersticas y soluciones para crear Open Grid Scheduler / Grid Engine.

Qu es Grid Engine?
Grid Engine es un software de gestin de clster que gestiona el acceso, informa el uso y
aplica polticas comerciales para un clster informtico. Sin un software de
administracin de clster de este tipo, el uso de los hosts informticos es ms o menos
catico porque algunos hosts suelen estar sobrecargados y otros no se utilizan. Todos los
usuarios deben conocer los hosts y sus recursos, y especialmente los programas paralelos
que abarcan varias computadoras pueden causar problemas. Es difcil recopilar
informacin sobre los recursos que los usuarios utilizaron o limitar el uso de ciertos
recursos de los clusters.

Grid Engine simplifica las ejecuciones de aplicaciones para los usuarios y las
configuraciones de los recursos del clster y las polticas para los administradores. Los
usuarios solo tienen que enviar su script de inicio de aplicacin o binario con la
herramienta de lnea de comandos qsub , el resto depende de Grid Engine. Enva este
trabajo a un host informtico apropiado y lo inicia. Durante el tiempo de ejecucin, el
usuario puede ver el estado del trabajo (recursos consumidos, etc.) con el comando qstat
. El usuario tiene control total sobre el trabajo, es decir, un trabajo puede ser detenido,
reprogramado, etc. Un administrador puede, por ejemplo, agregar usuarios a los proyectos
y dar a los proyectos diferentes ponderaciones, dependiendo de su prioridad. El
programador de Grid Engine respeta esas prioridades y reglas en sus decisiones.