Implant A Cio de Clusters

Autorizada la entrega del proyecto del alumno:
Manuel Reao Costales

EL DIRECTOR DEL PROYECTO
Miguel Angel Robles Rumayor

Fdo: Fecha:

V B del Coordinador de Proyectos
David Contreras Brcena

Fdo: Fecha:

PROYECTO DE FIN DE CARRERA

IMPLANTACIN DE CLUSTERS DE ALTA
DISPONIBILIDAD

DIRECTOR: Miguel Angel Robles
AUTOR: Manuel Reao Costales
UNIVERSIDAD PONTIFICIA COMILLAS

ESCUELA TCNICA SUPERIOR DE INGENIERA (ICAI)
INGENIERO EN INFORMTICA
RESUMEN DEL PROYECTO
En los entornos empresariales se demanda cada vez ms que las aplicaciones den
servicio de forma continua, siendo necesario para muchas aplicaciones de produccin
ofrecer una disponibilidad de 24x7. Esta necesidad lleva a muchas empresas a firmar
Acuerdos de Niveles de Servicio (ANS) que establecen los tiempos de parada mximos
que son asumibles por el negocio. Estos ANS pueden ser acuerdos internos con los
departamentos de IT de la propia empresa, pero tambin pueden ser externos con otras
empresas, si tienen externalizados los servicios de administracin IT, o si sus
aplicaciones dependen de aplicaciones de terceros.
Dentro de este marco, todas las tareas destinadas a evitar los fallos o a minimizar el
impacto de dichos fallos toman mucha ms importancia, puesto que cada incidencia
penaliza en cuanto al resultado de los ANS.
Sin embargo, no son las cadas por causas accidentales las responsables de la mayor
parte tiempo de no disponibilidad. Las tareas necesarias para la administracin y el
mantenimiento de los servidores y las aplicaciones son las causantes del 85% de media
del tiempo total de indisponibilidad, frente al 1% causado por fallos del HW, y el 14%
debido a otros factores, en su mayora errores humanos en la administracin.
Este proyecto nace de las dificultades que experimentaba el departamento de IT de una
empresa para alcanzar los niveles marcados por los ANS que tienen firmados. Los
servidores tenan problemas de rendimiento y cortes de servicio de las aplicaciones de
explotacin. Estos cortes estaban provocados tanto por la sobrecarga experimentada y
por incidencias accidentales como por las tareas de mantenimiento, cada vez ms
frecuentes a medida que la plataforma HW se quedaba obsoleta. Una vez identificada la
problemtica, la empresa ha solicitado presupuesto a varias compaas para que diseen
una solucin que corrija su situacin. Este proyecto conforma la propuesta presentada a
dicha empresa, y ha sido seleccionado e implantado con xito.
Para solucionar estos problemas, este proyecto propone dos aspectos: la renovacin de
los sistemas y la implantacin de una solucin de alta disponibilidad. La renovacin
HW pretende solucionar los problemas de rendimiento y reducir las tareas de
mantenimiento, y la solucin de alta disponibilidad pretende minimizar el impacto de
las cadas accidentales y enmascarar los tiempos de las paradas planificadas.
La primera etapa de este proyecto ha sido la de anlisis de requisitos y se ha realizado
de forma previa a la presentacin de la propuesta. Esta etapa ha consistido en la
identificacin de la plataforma HW del cliente y de las aplicaciones que componen sus
sistemas de produccin, desarrollo y calidad. Se han tomado datos de rendimiento de los
servidores para identificar los cuellos de botella y poder dimensionar correctamente los
nuevos sistemas.
La segunda etapa del proyecto, realizada tambin antes de la presentacin de la
propuesta, ha sido la del diseo de la solucin. Esta etapa se ha dividido en dos fases:
diseo de la plataforma HW y diseo de la topologa de cluster. Para la plataforma HW
se ha seleccionado entre los distintos servidores IBM System p5, que utilizan un sistema
operativo de tipo UNIX propietario de IBM llamado AIX. Para la solucin de clusters
de alta disponibilidad se ha seleccionado una solucin llamada IBM HACMP, y se han
configurado 4 clusters de dos nodos, en modo activo-activo para soportar todas las
aplicaciones de produccin de la empresa. Una vez realizado el diseo de la solucin se
ha presentado la propuesta al cliente.
Una vez aprobada la oferta, la siguiente etapa del proyecto ha sido la implantacin de la
solucin. Esta implantacin ha incluido la instalacin completa de los servidores y la
configuracin de los clusters, y la realizacin de pruebas de rendimiento y de
funcionamiento de HACMP. Esta etapa se ha concluido con la aceptacin por parte del
cliente de los resultados de las pruebas.
La ltima etapa del proyecto ha sido la entrega de la documentacin al cliente y el cierre
del proyecto. Dentro de la documentacin entregada se han incluido las conclusiones
que confirman que los objetivos iniciales se han alcanzado, y tambin se ha incluido una
serie de propuestas, para futuras ampliaciones o mejoras de los sistemas. Con le entrega
de la documentacin y la aceptacin por parte del cliente de las conclusiones se ha dado
por finalizado este proyecto.
HIGH AVAILABILITY CLUSTERS IMPLANTATION
ABSTRACT
In enterprises environments, there is a growing demand for their business applications
to offer a continuous availability, being necessary for some live applications to run in a
24x7 way. This necessity forces a lot of enterprises to sign Service Levels Agreements
(SLA), which establish the maximum downtimes that can be accepted by business.
This makes all the tasks focused on avoiding failures or diminishing the impact of these
failures to take much more relevance, since each incidence penalizes SLAs results.
Nevertheless, its not unplanned downtimes, due to accidental factors, that are
responsible of the longest total downtime. Tasks needed and scheduled for the
administration and maintenance of systems and applications are responsible for 85% of
the total system downtime, meanwhile HW failures only represents 1% and other
factors like human errors represents 14%.
This project is born of the difficulties that an IT department experienced to achieve their
SLAs signed levels. Their servers had performance issues and their applications
suffered loss of service. This downtimes were caused by servers overload, accidentals
failures and by maintenance tasks, more and more frequent as the HW remained
obsolete. Once they did identify the problem, this company asked several providers for
a solution that corrects their situation. This project is a proposal made to this company,
and it has been selected and successfully installed.
To solve these problems, this project suggests two ways: HW renovation and a high
availability (HA) clustering solution. HW renovation will lead to a performance
increase and will reduce maintenance necessity, and the HA solution will reduce
unplanned downtimes and it will also mask planned downtime.
The first step is to analyze the clients requirements, study their HW platform and their
applications. The performance has been analyzed, collecting the performance data to
identify bottlenecks and to determine the new systems capacities.
This projects second step is to design the HW platform and the clusters topology. HW
has been chosen from the IBM System p5 family, which runs a UNIX like operating
system called IBM AIX. The selected HA clustering solution is IBM HACMP,
configured with 4 two-node clusters, in an active-active topology, to achieve continuous
availability for their live applications.
The next step is the implantation. This step includes the servers complete installation,
the HA clusters configuration, and the performance and availability tests. This step is
concluded when the client gives its agreement to the results of the tests.
The last step of this project is the delivery of the documentation to the client. Within the
delivered documentation there are some conclusions that prove that the initial goals
have been achieved, and there are also some new proposals, for future upgrades and
improvements of the systems. Once the documentation has been delivered, the project
ends with the clients agreement to the conclusions presented.
ndice
I. Introduccin 1
II. Objetivos del proyecto 3
III. Alta Disponibilidad 6
IV. Anlisis de requisitos 12
IV.1. Situacin actual del cliente 12
IV.2. Rendimiento actual de los servidores 15
IV.3. Anlisis de los datos obtenidos 19
IV.4. Requisitos de los nuevos sistemas 22
V. Estudio de soluciones 24
V.1. Sistema operativo IBM AIX 24
V.2. Servidores IBM pSeries 25
V.3. Particionamiento Lgico LPAR 26
V.4. Ampliacin de capacidad bajo demanda (CUoD) 30
V.5. Habilitacin de capacidad bajo demanda (CoD) 30
V.6. IBM HACMP Clusters de Alta Disponibilidad 31
VI. Diseo de la solucin 36
VI.1. Configuracin hardware 36
VI.2. Configuracin HACMP 50
VI.3. Diseo final 56
VII. Evaluacin Econmica de la Oferta 62
VII.1. Valoracin Econmica HW/SW 62
VII.2. Valoracin Econmica servicios 84
VII.3. Valoracin Econmica Total 85
VIII. Implantacin de la solucin 86
VIII.1. Enracado de los servidores 86
VIII.2. Interconexin HMC Sistemas gestionados 88
VIII.3. Creacin de particiones 89
VIII.4. Instalacin del sistema operativo 98
VIII.5. Configuracin HACMP 99

IX. Configuracin adicional 107
IX.1. Auditoria de eventos 107
IX.2. Movimiento de recursos 108
IX.3. Sincronizacin horaria 110
X. Conclusiones 111
X.1. Objetivos alcanzados 111
X.2. Mejoras propuestas 117
Bibliografa 120
Anexos 121
Anexo A Auditoria 121
Anexo B Movimientos de recursos 127
Anexo C Configuracin de ntp 132
Anexo D Alta Disponibilidad sobre Linux 135

Manuel Reao Costales Implantacin de Clusters
de Alta Disponibilidad
Pgina 1 de 142

I. Introduccin

En los entornos empresariales, las aplicaciones de produccin as como los datos
que stas manejan constituyen dos de los activos ms valiosos y a la vez ms crticos de
las empresas. Su falta de disponibilidad puede suponer perjuicios graves tanto en
trminos econmicos como de prdida de confianza de los clientes y de merma de la
imagen. Garantizar la mxima disponibilidad de estos activos se ha convertido por lo
tanto en una de las principales prioridades de muchas empresas, dedicando a ello cada
vez mayores recursos. Claros ejemplos de esto son empresas como los bancos o las
empresas aseguradoras, cuyo negocio depende cada vez en mayor medida de las
aplicaciones on-line, pero tambin las administraciones pblicas que estn realizando
cuantiosas inversiones para desarrollar la llamada e-administracin.

Para poder aumentar la disponibilidad de las aplicaciones es vital conocer cuales
son los factores que pueden afectarla. Dichos factores se pueden englobar en tres
grandes categoras: disminucin de la disponibilidad por causas accidentales, por
gestin del sistema y por sobrecarga del sistema.

Disminucin de la disponibilidad por causas accidentales
Son tiempos de parada no planificados, y las causas ms comunes son:
- Fallo de un componente del servidor (alimentacin, adaptador de red,
procesador, memoria, etc)
- Fallo completo del servidor
- Fallo de acceso a los datos
- Fallo de un disco
- Fallo de un componente de la red (switches, cableado, etc)
- Fallo del suministro elctrico

Disminucin de la disponibilidad por gestin del sistema
Son tiempos de parada necesarios y planificados, y segn las estadsticas son la causa de
la mayor parte del tiempo de indisponibilidad. Las causas ms comunes son:
Pgina 2 de 142

- Actualizacin de versiones (del sistema operativo o de las aplicaciones)
- Aplicacin de parches
- Tareas de administracin, mantenimiento y gestin (procesos batch, copias
de seguridad, etc)
- Pasos a produccin de nuevas aplicaciones

Disminucin de la disponibilidad por sobrecarga del sistema
- Normalmente picos temporales (horas punta, finales de mes, etc)
- Disminucin del rendimiento
- Ralentizacin de las transacciones
- Desconexin por time-out en las aplicaciones cliente

Los clusters de alta disponibilidad estn enfocados a paliar los efectos de las dos
primeras categoras (accidente y gestin). Son soluciones que mediante el uso de
elementos hardware y software intentan minimizar los tiempos de cada por accidente y
eliminar o enmascarar los tiempos de parada planificada por tareas de gestin. Se basan
en el uso de componentes hardware redundantes y de scripts para la automatizacin de
las tareas.

En el caso de la sobrecarga del sistema, los mecanismos ofrecidos por los
clusters de alta disponibilidad no mejoran el rendimiento, de hecho las medidas
adoptadas por estas soluciones pueden afectar en momentos puntuales el rendimiento.
Para estos casos hay que implementar soluciones que permitan la habilitacin de
capacidad bajo demanda (CoD, Capacity on Demand).

Pgina 3 de 142

II. Objetivos del proyecto

Este proyecto nace debido a las dificultades que tiene el departamento de IT de
una empresa para cumplir los acuerdos de nivel de servicio (SLA, Service Level
Agreement) que tiene definidos, tanto internamente con otros departamentos de la
empresa como externamente con otras empresas. Debido a estos problemas se ha
planteado una renovacin de la plataforma hardware existente, consolidacin de
servidores de produccin y desarrollo, y la implantacin de alguna solucin que permita
aumentar la disponibilidad de las aplicaciones de produccin. Una vez planteado el
proyecto se ha solicitado una solucin a varios proveedores, que incluya los siguientes
requerimientos y condicionantes:
- Aumento del rendimiento
- Disminucin del tiempo de indisponibilidad
- Plataforma hardware ampliable
- Futura integracin de nuevas aplicaciones
- Ahorro de espacio

Es con estos condicionantes como se enfoca inicialmente este proyecto,
definiendo una lista de objetivos a cumplir:

Plataforma IBM AIX
Los sistemas actuales del cliente se basan en el sistema operativo IBM AIX
(sistema operativo UNIX propietario de IBM). Si bien no es requisito indispensable, el
uso de un sistema operativo conocido por el cliente, y la continuidad del soporte a las
aplicaciones es un factor positivo a la hora de presentar la oferta al cliente.

Aumento del rendimiento
El hardware ofertado debe ofrecer un rendimiento mayor del que obtienen con
su plataforma hardware actual.

Pgina 4 de 142

Asegurar la capacidad de proceso (CoD)
La sobrecarga generada en horas punta puede llegar a provocar una prdida de
disponibilidad. Mediante la habilitacin de capacidad bajo demanda se elimina un
posible punto de fallo.

Eliminacin de los puntos nicos de fallo (SPOF, Single Point Of
Failure)
Los SPOFs son componentes que constan de un solo elemento dentro del
sistema. Asegurando redundancia de todos los componentes se eliminan dichos SPOFs
y se asegura la disponibilidad en el caso de un fallo.

Eliminar o enmascarar el tiempo de parada planificado
El tiempo de parada planificado representa ms del 80% del tiempo total de no
disponibilidad de los sistemas. Eliminar este tiempo de parada supone por lo tanto una
mejora sustancial a la hora de cumplir con los acuerdos SLA.

Minimizar el tiempo de cada accidental
El tiempo de recuperacin tras una cada accidental depende del tiempo que se
tarda en detectar la cada y el componente que la ha causado. Haciendo que sea el
sistema quien detecte las cadas y automatizando el proceso de recuperacin se reduce
al mnimo posible este tiempo de no disponibilidad.

Asegurar la validez y consistencia de los datos
Si no se puede asegurar la validez de los datos estos carecen de valor para la
empresa. Una integracin adecuada de las aplicaciones con la solucin se logra
mediante el uso de scripts que controlan el estado de las bases de datos en el arranque y
en la parada de las aplicaciones.

Pgina 5 de 142

Integrar las aplicaciones de produccin
El objetivo de los clusters no es disponer de hardware redundante o de
servidores en alta disponibilidad, sino que se trata de poner en alta disponibilidad las
aplicaciones. La solucin adoptada debe por lo tanto permitir la integracin de muy
diversas aplicaciones, tanto comerciales como desarrollos propios.

Ahorro de espacio
Para el cliente el ahorro de espacio es muy importante, ya que sus servidores se
encuentran alojados en las instalaciones de un proveedor de servicios de hosting y
housing. En estas condiciones un ahorro de espacio supone para el cliente un ahorro de
costes en la relacin con su proveedor.

Asegurar capacidad de crecimiento
Para el cliente es primordial asegurar la capacidad de crecimiento de la solucin
adoptada, ya que en caso contrario no se justifica la inversin necesaria para realizar el
proyecto.

Ahorro de costes
Este proyecto conforma la oferta que se va a realizar a un cliente que ha
solicitado una solucin a varios proveedores, por lo que debe ser econmicamente
competitivo.

Pgina 6 de 142

III. Alta Disponibilidad

Este proyecto consiste en su mayor parte en el diseo, la implantacin y la
configuracin de una solucin de alta disponibilidad por lo que es conveniente aclarar lo
que se entiende por alta disponibilidad en los sistemas informticos y ver las diferencias
respecto de otras soluciones.

Los sistemas informticos se pueden clasificar en funcin de la disponibilidad y
fiabilidad que ofrecen en las siguientes categoras:
- sistemas stand-alone
- sistemas mejorados
- clusters de alta disponibilidad
- sistemas tolerantes a fallos

Sistemas stand-alone
Es la configuracin ms sencilla, y consta de un servidor nico y sin acceso a
almacenamiento externo. Si bien en la actualidad la mayora puede ofrecer muchas
mejoras, sigue teniendo mltiples SPOFs.

Puntos fuertes
- sistema de ficheros registrado por diario (por ejemplo JFS, Journaled File
System), que ofrece deteccin recuperacin de fallos leves
- fuentes de energa redundantes
- sistemas de refrigeracin redundantes
- memoria ECC, con cdigo de correccin de errores (ECC, Error Correcting
Code)
- desactivacin de procesadores en caliente
- procesador de servicio o similar, para una mejor administracin del HW y
administracin en remoto (incluido arranque en remoto)
- discos en distintos niveles de RAID
- kernel dinmico
Pgina 7 de 142

Puntos nicos de fallo
- cada del servidor
- fallo de un interfaz de red
- fallo de la red
- fallo de la aplicacin
- fallo del sistema operativo
- camino nico a los datos
- discos no reemplazables en caliente
- fallo del site

Sistemas mejorados
Los sistemas mejorados disponen de acceso a almacenamiento externo con
distintos niveles de raid y que puede soportar el acceso a los datos por mltiples
caminos.

Puntos fuertes
- sistema de ficheros JFS
- memoria ECC
- procesador de servicio
- kernel dinmico
- tarjetas reemplazables en caliente (hot-swap)
- mltiples caminos a los datos
- discos reemplazables en caliente (hot-swap)
- discos de reemplazo automtico (hot-spare)
- sistema de almacenamiento independiente
- fuentes de energa del almacenamiento redundantes
- sistemas de refrigeracin del almacenamiento redundantes

Pgina 8 de 142

- cada del servidor
- fallo de un interfaz de red
- fallo de la red
- fallo de la aplicacin
- fallo del sistema operativo
- fallo del site

Sistemas de alta disponibilidad
Los sistemas de alta disponibilidad intentan solventar los problemas de los
sistemas stand-alone y mejorados mediante la redundancia de todos sus componentes.
Si uno de sus componentes fallase, otro componente de backup est a la espera para
asumir su carga de trabajo. Por ejemplo, si falla un adaptador de red otro adaptador
asume de manera automtica su direccin IP y su carga de trabajo.

Puntos fuertes
- memoria ECC
- kernel dinmico
- tarjetas reemplazables en caliente (hot-swap)
- discos reemplazables en caliente (hot-swap)
- discos de reemplazo automtico (hot-spare)
- adaptadores de disco duales
Pgina 9 de 142

- nodos redundantes (sistema operativo y aplicaciones)
- adaptadores de red redundantes
- redes redundantes
- monitorizacin de las aplicaciones
- sites redundantes mediante la replicacin a larga distancia

- fallo de la replicacin del site

Sistemas tolerantes a fallos
Los sistemas tolerantes a fallos estn diseados para no fallar nunca. Son
soluciones extremadamente complejas y costosas si se comparan con soluciones
basadas en clusters de alta disponibilidad. Los escasos fabricantes que venden sistemas
tolerantes a fallos ofrecen una gama reducida de soluciones, lo que significa poca
compatibilidad y poca escalabilidad.
En estos sistemas, la relacin entre precio y beneficio supone un problema,
como tambin lo supone la naturaleza propietaria del hardware y del sistema operativo,
lo que suele implicar el desarrollo a medida de todas las aplicaciones.
Dicho esto, los sistemas tolerantes a fallos estn diseados para no fallar, por lo
que si no se puede permitir ningn tiempo de cada de las aplicaciones (sistemas crticos
para la vida humana) entonces hay que plantearse este tipo de soluciones.

Puntos fuertes
- memoria ECC
- kernel dinmico
- tarjetas hot-swap
Pgina 10 de 142

- discos hot-swap
- discos hot-spare
- adaptadores de disco duales
- nodos redundantes
- adaptadores de red redundantes
- redes redundantes
- monitorizacin de las aplicaciones
- sites redundantes
- procesadores a prueba de bloqueos
- procesadores sncronos (lock-step)
- sistema operativo a prueba de bloqueos
- sistema operativo sncrono (lock-step)
- reinicio en continuo

- en teora ninguno, si bien en algunas configuraciones puede darse fallo del
site

La siguiente tabla ofrece la relacin entre algunos factores relevantes a la hora
de disear un sistema, en cuanto a disponibilidad se refiere:
Stand-alone Mejorados
Alta
disponibilidad
Tolerantes a
fallos
Tiempo de
recuperacin
Puede llegar a
das
Un par de
horas
Cinco
minutos
En teora
nulo
Disponibilida
d de los datos
La ltima
copia de
seguridad
disponible
La ltima
transaccin
La ltima
transaccin
Sin prdida
de datos
Coste
relativo
1 1,5 2-3 > 10
Pgina 11 de 142

Beneficios de las soluciones de alta disponibilidad
Las distintas soluciones de alta disponibilidad ofrecen los siguientes beneficios:
- uso de componentes estndar, sin necesidad de hardware especializado
- se pueden implementar usando sistemas ya disponibles, por lo que se puede
evitar el gasto de invertir en HW nuevo
- funcionan con casi cualquier tipo de aplicacin, en cuanto a aplicaciones
comerciales se refiere
- trabajan sobre sistemas operativos comunes
- ofrecen una gran disponibilidad a un coste relativamente bajo

Requisitos para la alta disponibilidad
Para que un sistema de alta disponibilidad funcione correctamente y rentabilice la
inversin, es necesario cumplir una serie de requisitos:
- un diseo robusto y una planificacin detallada
- eliminacin de los puntos nicos de fallo
- seleccin del HW apropiado (si bien no necesita HW especializado para alta
disponibilidad, si que debe tener unas caractersticas mnimas)
- implementacin correcta y cuidadosa
- disciplina a la hora de administrar el sistema
- documentacin detallada y actualizada
- realizar pruebas exhaustivas

Pgina 12 de 142

IV. Anlisis de requisitos

Para poder presentar una configuracin adecuada es necesario realizar un estudio
detallado de la situacin actual del cliente, la plataforma hardware, el sistema operativo
y las aplicaciones que tiene. De esta manera se podrn definir los requisitos mnimos
que deben tener los nuevos sistemas para cumplir con los objetivos.

IV.1. Situacin actual del cliente

En la actualidad el cliente tiene sus aplicaciones sobre mquinas con las
siguientes caractersticas:
- servidores 7026-B80 (pSeries 640 Model B80)
- 1 o 2 procesadores POWER3-II 375 MHz
- entre 512 MB y 4 GB de memoria ECC SDRAM
- 1 o 2 discos internos de 36,4 GB
- modelo enracable de 5 Us de alto

IBM pSeries 640 Model B80

La relacin de los servidores y sus configuraciones con las aplicaciones que
soportan es la siguiente:
Servidor Configuracin Aplicaciones
Baco 1-way 375 MHz, 1 GB
memoria, 2 discos
internos
Produccin: Ediswitch
Pgina 13 de 142

Ceres 1-way 375 MHz, 1 GB
memoria, 2 discos
internos. Utiliza X25
Produccin: Editran +
Expedite
Cupido 1-way 375 MHz, 1 GB
memoria, 2 discos internos
Desarrollo: Informix +
servidor web
Diana 2-way 375 MHz, 1 GB
memoria, 1 disco interno
Produccin: Odex
Febo 1-way 375 MHz, 1 GB
memoria, 1 disco interno.
Utiliza X25
Produccin: Odex
Juno 2-way 375 MHz, 2 GB
memoria, 2 discos
internos
Produccin: Oracle
Jpiter 2-way 375 MHz, 2 GB
memoria, 2 discos
internos
Produccin: Oracle
Marte 2-way 375 MHz, 2 GB
memoria, 2 discos
internos
Produccin: Oracle
Mercurio 1-way 375 MHz, 2 GB
memoria, 2 discos
internos
Produccin: Oracle +
Informix
Minerva 1-way 375 MHz, 2 GB
Desarrollo: Oracle +
Informix
Neptuno 1-way 375 MHz, 1 GB
Desarrollo/Calidad:
Servidor web
Ops 1-way 375 MHz, 4 GB
Desarrollo: Weblogic
Pluton 1-way 375 MHz, 512 MB
Saturno 1-way 375 MHz, 512 MB

Pgina 14 de 142

Urano 1-way 375 MHz, 2 GB
Venus 1-way 375 MHz, 2 GB
Relacin servidores/aplicaciones (en negrita estn las que se quieren poner en alta
disponibilidad

Rendimiento
Para los sistemas IBM pSeries existen varias medidas para el clculo del
rendimiento terico de los servidores. Estas medidas llamadas Relative Online
Transaction Processing (ROLTP) y Relative Performance (rPerf) establecen una
comparacin del rendimiento terico frente a una configuracin de base. En este caso se
usar la unidad rPerf como medida del rendimiento.

Los valores rPerf de los servidores del cliente son los siguientes:
- 1 procesador: rPerf = 1
- 2 procesadores: rPerf 2 (en realidad ligeramente inferior a 2, pero se toma
rPerf = 2 para las estimaciones)
El valor total de rPerf de los sistemas es por lo tanto de 20.

Almacenamiento
Los servidores con 2 discos internos tienen los discos en mirror (RAID nivel 1)
para evitar posibles fallos.
Los discos internos estn dedicados al sistema operativo y los ejecutables de las
aplicaciones.
Las aplicaciones de produccin con necesidades especiales de almacenamiento
(por ejemplo las bases de datos) tienen acceso a almacenamiento externo a travs de una
red SAN (Storage Area Network). Dicho almacenamiento est ubicado en cabinas de
discos externas, con acceso mediante conexiones de fibra ptica (cabinas EMC
CLARiiON).
Las aplicaciones de desarrollo y calidad tienen espacio asignado a travs de una
red NAS (Network Attached Storage).

Pgina 15 de 142

Ubicacin y enracado
Los servidores del cliente se encuentran alojados en las instalaciones de un
proveedor de servicios de hosting y housing. Este proveedor proporciona el espacio
necesario dentro de unas salas de servidores acondicionadas segn los estndares:
suministro elctrico, temperatura y humedad controladas, seguridad de acceso, etc
Los servidores se encuentran enracados en armarios estndar de 36 Us de alto,
ocupando actualmente un total de 86 Us en 3 armarios (16 servidores de 5 Us de alto +
3 pantallas TFT de 2 Us de alto cada una).

IV.2. Rendimiento actual de los servidores
Desde la implantacin de los sistemas actuales, la carga de trabajo de todos los
servidores y las aplicaciones ha aumentado de manera considerable, lo que ha
provocado una disminucin del rendimiento. Dicha disminucin se ha traducido en unos
tiempos de respuesta cada vez mayores, provocando incluso desconexiones por time-out
cada vez ms frecuentes.
Para poder dimensionar correctamente el cliente ha facilitado los datos de
rendimiento de sus sistemas actuales en la situacin actual. En cada caso se va a estudiar
principalmente el rendimiento desde el punto de vista del procesador y de la memoria.
Se ha decidido que los aspectos relativos a los accesos a disco y los protocolos de red no
se tendrn en cuenta para el estudio de la solucin ya que para influir sobre estos dos
aspectos habra que estudiar el diseo de las aplicaciones, y esto est fuera del alcance
de este proyecto. Sin embargo, si en algn momento se detecta un problema con las
operaciones de entrada/salida, tanto en los discos como en la red, que pueda evidenciar
un problema ajeno al diseo de la aplicacin se estudiar una posible mejora de la
situacin, dentro de los lmites de este proyecto.

Servidor Baco
El servidor Baco consta de un procesador y 1 GB de memoria (rPerf = 1). La
aplicacin que soporta es una aplicacin de produccin (Ediswitch).

Pgina 16 de 142

Los datos medios de ocupacin del procesador, obtenidos mediante el comando
sar, son los siguientes:
%usr %sys %wio %idle
Average 45 38 17 0

Los datos medios de utilizacin de la memoria, obtenidos mediante el comando
vmstat, son los siguientes:
kthr memory page faults cpu
----- ------------ ------------------------ -------------- -----------
r b avm fre re pi po fr sr cy in sy cs us sy id wa
19 3 277873 216415 0 14 6 72 600 0 498 5533 816 45 37 0 18

Los datos del espacio de paginacin, obtenidos mediante el comando lsps, son
los siguientes:
PgSpace PhysicalVolume VolumeGroup Size %Used Active Auto Type
hd6 hdisk0 rootvg 2048MB 35 yes yes lv

Servidor Ceres
El servidor Ceres consta de un procesador y 1 GB de memoria (rPerf = 1). Las
aplicaciones que soporta son aplicaciones de produccin (Editran y Expedite).

Average 51 31 13 5

----- ------------ ------------------------ -------------- -----------
8 1 211606 312682 0 17 8 67 743 0 512 6345 724 50 31 6 13

los siguientes:
Pgina 17 de 142


Servidor Pluton
El servidor Pluton consta de un procesador y 512 MB de memoria (rPerf 1).
La aplicacin que soporta es una aplicacin de desarrollo (Weblogic).

Average 37 29 32 2

----- ------------ ------------------------ -------------- -----------
9 2 100766 1564 0 224 123 521 894 0 738 5248 965 36 30 2 32

los siguientes:

Servidor Saturno
El servidor Saturno consta de un procesador y 512 MB de memoria (rPerf 1).
La aplicacin que soporta es una aplicacin de desarrollo (Weblogic).

Average 36 30 31 3

Pgina 18 de 142

----- ------------ ------------------------ -------------- -----------
9 2 101635 2703 0 384 309 639 523 0 863 6150 827 36 30 4 30

los siguientes:

Servidor Diana
El servidor Diana consta de dos procesadores y 1 GB de memoria (rPerf 2). La
aplicacin que soporta es una aplicacin de produccin (Odex).

Average 51 31 13 5

----- ------------ ------------------------ -------------- -----------
8 1 211606 312682 0 17 8 67 743 0 512 6345 724 50 31 6 13

los siguientes:

Si bien aqu solo se presentan los datos medios, el estudio del rendimiento ha
incluido la toma de datos de forma continuada durante un periodo de tiempo. De esta
Pgina 19 de 142

manera tambin se contemplan los picos de sobrecarga temporales, las horas valle y la
evolucin de la carga. Es cierto que el periodo de tiempo no ha sido suficientemente
largo como para poder estudiar la estacionalidad de la carga del sistema, pero las
variaciones provocadas por dicha estacionalidad son mnimas segn los datos del
cliente, por lo que no supone un problema a la hora de dimensionar los nuevos
servidores.

Esta operativa se ha realizado sobre los 16 servidores, obteniendo datos
similares para todos. Con el anlisis de estos datos se obtendrn los problemas y los
cuellos de botella de cada servidor, y se podrn dimensionar los nuevos sistemas.
IV.3. Anlisis de los datos obtenidos
Comando sar
La columna %usr muestra en porcentaje el tiempo de ocupacin del procesador por
parte de los procesos de usuario.
La columna %sys muestra en porcentaje el tiempo de ocupacin del procesador por
parte de procesos del sistema operativo.
La columna %wio muestra en porcentaje el tiempo que el procesador est inactivo
porque algn proceso est a la espera de una operacin de entrada/salida.
La columna %idle muestra en porcentaje el tiempo que el procesador no est ocupado.

Un valor bajo de %idle con valores elevados de %usr y %sys suele indicar un
problema por falta de capacidad de proceso. Si los valores de %usr y %sys no son
elevados el problema se debe a un valor demasiado elevado de %wio, lo que puede
indicar varios problemas (mal diseo de las aplicaciones, problemas con las
controladoras de los discos, problemas de paginacin, etc).

Comando vmstat
Columna pi: pginas cargadas en memoria desde el espacio de paginacin
Columna po: pginas sacadas al espacio de paginacin desde la memoria
Columna fr: pginas liberadas (reemplazadas por otras)
Columna avm: pginas de memoria virtual activas
Pgina 20 de 142

Columna fre: tamao de la free list
Columna r: hilos de ejecucin cargados en la lista de ejecucin
Columna b: hilos de ejecucin bloqueados a la espera de recursos

Un valor elevado de r tiende a indicar una limitacin desde el punto de vista del
procesador.
El valor de b suele ser proporcional al valor de %wio del comando sar. Por lo
tanto un valor elevado de b indica que hay procesos en espera por operaciones de
entrada/salida.
Valores elevados de pi, po y fr suelen indicar problemas por falta de memoria.
En estos casos suele aparecer un valor de fre bastante reducido en comparacin con el
valor de avm.

Comando lsps
Un valor elevado de %Used supone un problema para el servidor, y por lo
general indica un problema por falta de memoria. Si el espacio de paginacin se llena
demasiado el rendimiento del servidor cae de manera drstica hasta el punto de no poder
conectarse a l. Esto se puede solucionar aumentando el tamao del espacio de
paginacin, pero normalmente esta solucin no supone ms que un arreglo temporal por
lo que en esos casos es conveniente aumentar la memoria.

Analizando los datos de los servidores del cliente y teniendo en cuenta estas
consideraciones se observa en los servidores lo siguiente:
- Baco:
o CPU: est muy limitado por la CPU
o Memoria: no est limitado por la memoria
- Ceres:
o CPU: est bastante limitado por la CPU
- Cupido:
- Diana:
Pgina 21 de 142

o CPU: est bastante limitado por la memoria
- Febo:
o CPU: est ligeramente limitado por la CPU
- Juno:
o Memoria: est limitado por la memoria
- Jupiter:
- Marte:
- Mercurio:
- Minerva:
o Memoria: est bastante limitado por la memoria
- Neptuno:
- Ops:
o Memoria: est ligeramente limitado por la memoria
- Pluton:
o Memoria: est muy limitado por la memoria
- Saturno:
o Memoria: est muy limitado por la memoria
- Urano:
Pgina 22 de 142

- Venus:

IV.4. Requisitos de los nuevos sistemas
Rendimiento
Con la configuracin actual los sistemas estn experimentando una carga
demasiado elevada para su capacidad de procesamiento. De manera adicional, la
implantacin de la solucin HACMP puede suponer en momentos puntuales una
sobrecarga en alguno de los sistemas. Para solventar estos problemas de rendimiento y
soportar la sobrecarga puntual provocada por HACMP, se estima que doblando su
capacidad total los sistemas podrn hacer frente a la carga de trabajo actual.
A corto plazo (de aqu a 3 aos), con el ritmo de crecimiento estimado de la
carga de las aplicaciones y la implantacin de nuevas aplicaciones, se estima que la
carga de trabajo que tendrn que soportar los servidores es el doble de la carga actual.
Adicionalmente, los sistemas ofertados deben tener capacidad de crecimiento y
ampliacin ms all de los tres primeros aos, como mnimo del doble del crecimiento
previsto a corto plazo.
Partiendo de un rPerf total actual de 20:
- para solventar los problemas de rendimiento se estima un rPerf total 40
- para hacer frente al crecimiento a corto plazo se estima un rPerf total 80
- para el crecimiento a medio plazo se estima un rPerf total 160

Almacenamiento
Al igual que en la configuracin actual, todos los datos de las aplicaciones de
produccin estarn en almacenamiento externo en la red SAN y se seguirn usando las
mismas cabinas EMC CLARiiON. Esto implica la necesidad de tarjetas de fibra ptica
para el acceso al almacenamiento externo.
Pgina 23 de 142

Las aplicaciones de desarrollo y calidad seguirn usando almacenamiento en una
red NAS.
A diferencia de la configuracin actual, el sistema operativo y los ejecutables de
las aplicaciones deben residir en dos discos internos en mirror en todos los servidores.

Ubicacin y enracado
Los sistemas ofertados se ubicarn en las instalaciones del proveedor de
housing, ocupando el lugar de los servidores actuales. Por lo tanto deben ser todos
modelos enracables (ningn servidor con formato de torre o sobremesa) y deben ocupar
un mximo de 3 armarios de 36 Us (108 Us).
Pgina 24 de 142

V. Estudio de soluciones

V.1. Sistema operativo IBM AIX
El sistema operativo AIX es un sistema operativo de tipo UNIX propietario de
IBM. Tiene dos caractersticas principales que lo diferencian del resto de sistemas tipo
UNIX que son la integracin de un gestor de volmenes (LVM) y de un repositorio de
informacin del sistema (ODM) dentro del ncleo.
El LVM (Logical Volume Manager) es un gestor de volmenes lgicos que se
encarga de establecer el mapeado entre los filesystems, los volmenes lgicos sobre los
que residen y los volmenes fsicos (dispositivos de discos duros). Este gestor facilita
en gran medida la administracin de los discos y del espacio, permitiendo por ejemplo
realizar mirror (raid nivel 1) de los discos a nivel del sistema operativo sin necesidad de
una controladora de raid hardware.
La ODM (Object Data Manager) es un repositorio interno del sistema cuya
estructura mezcla el concepto de base de datos con el de orientacin a objetos. Este
repositorio contiene informacin del estado de todo el sistema, de los dispositivos
conectados, de los drivers que los controlan y del software instalado. Esta base de datos
supone una poderosa herramienta a la hora de administrar el sistema y ofrece mltiples
soluciones para la recuperacin del sistema frente a posibles fallos.

En la actualidad el sistema operativo IBM AIX est ligado a la plataforma
hardware RS6000/pSeries, que es una plataforma hardware propietaria de IBM basada
en la arquitectura RISC (Reduced Instructions Set Computer).
La versin actual de AIX es la versin 5.3 de AIX 5L. La letra L en el nombre
AIX 5L indica afinidad con Linux, lo que se traduce en la posibilidad de integrar
soluciones de Linux en el sistema operativo AIX (como por ejemplo la instalacin de
paquetes rpm).

Pgina 25 de 142

V.2. Servidores IBM pSeries
Como ya se ha visto, la eleccin del sistema operativo IBM AIX condiciona la
eleccin del hardware y obliga al uso de servidores de la plataforma RS6000 de IBM.

La familia de servidores pSeries es la gama actual de la plataforma IBM
RS6000, y sus modelos ms actuales son los modelos IBM System p5.
Los procesadores que utilizan son procesadores de la familiar POWER
(Performance Optimization With Enhanced RISC), y estn actualmente en los modelos
POWER5 y POWER5+. Los servidores con procesadores POWER5+ podrn
actualizarse con procesadores POWER6 cuando estn disponibles (a lo largo de 2007)
mientras que los servidores con procesadores POWER5 no podrn.

El desarrollo de la arquitectura RS6000 y pSeries est estrechamente ligado al
del sistema operativo AIX, hasta tal punto que es la nica arquitectura sobre la que corre
dicho sistema operativo. Sin embargo los ltimos modelos de estos servidores aceptan
tambin Linux (algunas versiones especficas) e i5/OS (nueva versin del AS/400)
como sistema operativo. La arquitectura POWER tambin se ha estado usando en los
procesadores PowerPC, instalados por ejemplo en los ordenadores Macintosh de Apple
(hasta hace poco).

A lo largo de los aos, al desarrollo de estos servidores se han ido incorporando
progresivamente caractersticas propias de los sistemas mainframe de IBM (s390 y
zSeries), como la consola de gestin de hardware HMC (Hardware Management
Console) y el particionamiento LPAR (Logical PARtition).

Los modelos actuales de la familia POWER permiten la ampliacin de
capacidad bajo demanda (CUoD, Capacity Upgrade on Demand) mediante la activacin
de procesadores en caso de necesidad. Tambin permiten la habilitacin de capacidad
bajo demanda (CoD) mediante la asignacin de forma automtica de procesadores
activos pero no usados.

Pgina 26 de 142

V.3. Particionamiento Lgico LPAR
Particin
Una particin es una agrupacin de recursos del sistema. La creacin de
particiones divide el sistema en sistemas virtuales separados. Cada particin es un
entorno operativo independiente.
Cada particin tiene su propio sistema operativo, que puede o no coincidir con el
tipo de sistema operativo del resto de particiones del mismo sistema. Cada particin
puede arrancarse o pararse de manera independiente a las otras particiones.
Existen particiones fsicas y particiones lgicas. Las particiones fsicas se basan
en la divisin de los recursos por bloques fsicos. Cada bloque est compuesto de una
cantidad determinada de recursos (procesadores, memoria, discos y ranuras para
tarjetas), y estos recursos no se pueden compartir entre particiones, ni mover de una a
otra.

Particiones lgicas
Se habla de particiones lgicas cuando la divisin de los recursos se hace
mediante firmware. Al no basarse en bloques fsicos permite configuraciones ms
flexibles.
El particionamiento lgico es la capacidad de hacer que un nico sistema (un
nico bloque fsico) funcione como si fuese dos o ms sistemas. Cada particin
representa una divisin de los recursos del sistema.
Se habla de particionamiento lgico ya que la divisin de los recursos es virtual
y no se basa en asociaciones fsicas. Existen sin embargo ciertas reglas de configuracin
que hay que seguir a la hora de crear las particiones.
La asignacin de los recursos del sistema a las particiones y el acceso a estos se
hace mediante firmware. Aunque existan reglas de configuracin, la granularidad de las
unidades de los recursos que se pueden asignar a las particiones es muy flexible. Se
puede aadir una pequea cantidad de memoria sin importar el tamao de las tarjetas de
memoria y sin aadir ms procesadores o ranuras si no son necesarios.
La administracin de las particiones (creacin, asignacin de recursos,
movimientos de recursos, etc) se hace a travs de una consola externa denominada
HMC (Hardware Management Console) y un procesador adicional del servidor.
Pgina 27 de 142

La consola HMC consiste en un servidor adicional que lleva instalado un
sistema operativo Linux restringido y una aplicacin de gestin. Esta aplicacin se
comunica con el procesador adicional del servidor llamado procesador de servicio.
Este procesador de servicio es un procesador PowerPC a 970 MHz y es donde
corre el firmware que gestiona todos los recursos del servidor y los asignados a cada
particin.

Asignacin de recursos
Procesador
Al hablar de particiones lgicas existen distintos conceptos para los procesadores:
- procesadores fsicos
o procesadores instalados en el sistema.
- procesadores activos/inactivos
o los procesadores instalados pueden estar activos o inactivos. Los
inactivos no se pueden usar, y estn pensados para la ampliacin de
capacidad bajo demanda.
- procesadores dedicados
o los procesadores se pueden asignar a las particiones de manera
dedicada. En este caso se asignan procesadores completos. La
particin utiliza los mismos procesadores mientras est funcionando.
Si la particin se apaga estos procesadores pueden entrar o no en el
pool de procesadores compartidos.
- procesadores compartidos
o los procesadores compartidos son procesadores fsicos que se asignan
a las particiones sobre una base de comparticin del tiempo,
asignando ranuras de tiempo de procesamiento. Las particiones que
utilizan el pool de procesadores compartidos utilizan ranuras de
tiempo de cualquiera de los procesadores compartidos. El mnimo
que se puede asignar a una particin es 0,1 unidad de proceso, y los
incrementos se hacen en cantidades de 0,01 unidad de proceso. Una
unidad de proceso completo equivale al uso en exclusiva de un
procesador durante todo el tiempo. Una gran ventaja es que es posible
asignar menos de un procesador a las particiones con poca necesidad,
Pgina 28 de 142

obteniendo as un importante ahorro. Otra ventaja es que una
particin con sobrecarga puede utilizar unidades de procesamiento
que no estn asignadas en ese momento.
- procesadores virtuales
o en el caso de los procesadores compartidos, el nmero de
procesadores virtuales es el nmero de procesadores fsicos que el
sistema operativo cree que tiene. Con esta cantidad se controla el
nmero de hilos de ejecucin que se pueden ejecutar
simultneamente. Aumentando esta cantidad se puede aumentar el
rendimiento sin aumentar la capacidad de proceso total asignada.
- procesadores lgicos
o el sistema operativo AIX tiene una opcin llamada Simultaneous
Multi-Threading (SMT) que permite la ejecucin de dos threads
distintos de manera simultnea en un mismo procesador (fsico o
virtual). Al activar la opcin de SMT el sistema operativo ejecuta dos
hilos de forma simultnea, usando para un hilo los tiempos de espera
del otro hilo. Esta opcin permite un uso ms eficiente del tiempo del
procesador.

Al asignar los procesadores a una particin, ya sea de manera dedicada o
compartida, hay que indicar tres cantidades: la mxima, la deseada y la mnima.
La cantidad deseada es la cantidad que intenta asignar a la particin al arrancar.
Si no hay disponible tanta cantidad va bajando hasta encontrar una cantidad disponible.
Si al llegar a la cantidad mnima indicada sigue sin haber suficiente no seguir bajando
y no arrancar la particin.
En caso de que la particin experimente una sobrecarga se le puede asignar ms
capacidad (ms procesadores o ms unidades de procesamiento) hasta llegar a la
cantidad mxima. Una vez asignada la capacidad mxima no se le asignar ms
capacidad.
A una particin arrancada nunca se la quitar capacidad de proceso de forma
automtica, pero se le puede quitar de manera manual para asignrsela a otra particin
con ms necesidad (o para realizar pruebas de stress). Si la particin llega a tener solo la
cantidad mnima indicada no se lo podr quitar ms.
Pgina 29 de 142

Memoria
La asignacin de memoria se realiza de manera muy parecida a la asignacin de
los procesadores. A cada particin se le indica una cantidad mnima, una cantidad
deseada y una cantidad mxima. Existe un tamao de los sectores de la memoria que
coincide con la cantidad mnima de memoria que se le puede asignar a una particin y
con el tamao de los incrementos en la asignacin de memoria. Este tamao vara en
funcin del modelo del servidor y del tipo de la memoria.

Slots de I/O
La asignacin de los recursos de entrada/salida se hace asignando las ranuras
(slots) en las que estn pinchadas las tarjetas (de red, de fibra, SCSI, etc). Las ranuras
se pueden asignar como necesarias y tambin como deseadas. En el caso de los
dispositivos asignados como necesarios la particin no arranque si dicho dispositivo no
est disponible (es decir que est asignado a otra particin). Estos dispositivos no se
pueden eliminar de la particin sin pararla, por lo que no se pueden mover de manera
dinmica. En el caso de los dispositivos asignados como deseados la particin intentar
arrancar con el dispositivo, pero si est asignado a otra particin puede arrancar de todas
maneras. Estos dispositivos si se pueden eliminar estando la particin arrancada, por lo
que se pueden mover de manera dinmica de una particin a otra. Esto es muy til en el
caso del lector de CD o la unidad de cinta.

Discos
La asignacin de los discos a las particiones se hace mediante la asignacin de
las controladoras SCSI internas que gestionan las bahas de los discos. Cada
controladora gestiona varias bahas, lo que implica que no se pueden asignar los discos
individualmente sino que hay se asignan por bloques. La cantidad de bahas gestionadas
por cada controladora vara en funcin del modelo del servidor, lo que permite
configuraciones ms flexibles en algunos modelos que en otros. Al igual que con los
slots de I/O las controladoras se pueden asignar como necesarias y como deseadas

Pgina 30 de 142

Virtualizacin
En la mayora de los servidores pSeries se puede dar el caso en el que por
nmero de controladoras de disco y/o por nmero de tarjetas de red no se puedan crear
ms que nmero limitado de particiones, y sin embargo el nmero de procesadores y la
cantidad de memoria permitiran crear ms particiones. En estos casos es posible la
virtualizacin de los discos y de las tarjetas.
Esta virtualizacin se hace creando una particin especial llamada VIO Server
(Virtual I/O Server). Dicha particin lleva instalada una versin especial de AIX que le
permite compartir sus discos y sus adaptadores de red al resto de particiones. En el resto
de particiones se crean dispositivos virtuales que simulan de cara al sistema operativo
los dispositivos fsicos. De esta manera los discos controlados por una nica
controladora pueden estar asignados a varias particiones, y lo mismo con los
adaptadores de red. Esta opcin tiene la desventaja de que se desaprovecha cierta
cantidad de capacidad de procesamiento y de memoria, que est asignada al VIO Server
pero no es aprovechable por las aplicaciones, ya que la versin de AIX del VIO Server
solo est preparada para esta funcin, y no para la ejecucin de aplicaciones.

V.4. Ampliacin de capacidad bajo demanda (CUoD)
Los servidores pSeries permiten la instalacin de procesadores y memoria
inactivos en el sistema para su posterior activacin. La activacin de estos recursos se
puede hacer de manera permanente o de manera temporal. En el caso de la activacin
permanente se habla de ampliacin de capacidad (CUoD, Capacity Upgrade on
Demand). La activacin permanente puede ser necesaria para crear e instalar otra
particin o para aumentar la capacidad de alguna de las ya existentes.

V.5. Habilitacin de capacidad bajo demanda (CoD)
En los casos de activacin temporal de los recursos se habla de habilitacin de
capacidad (CoD, Capacity on Demand). La activacin temporal de procesadores o
memoria puede ser necesaria en ciertos casos como finales de mes o de ao, que pueden
generar sobrecarga en algunos sistemas. En estos casos la activacin se realiza de
manera manual, y solo se paga por los das que han estado activos los recursos.
Pgina 31 de 142

Existe tambin una opcin de CoD temporal sin costes. Esta activacin se realiza
por un periodo de 30 das, por ejemplo para realizar pruebas de una nueva aplicacin.
Adems de estas dos opciones existe tambin otra posibilidad llamada CoD de
Reserva. En esta opcin se solicita cierta cantidad de procesadores activos y cierta
cantidad de procesadores de reserva, pagando nicamente por los procesadores
activos. La caracterstica de esta opcin es que los procesadores de reserva estn en
realidad activos y colocados en el pool de procesadores compartidos, de manera que en
caso de sobrecarga se pueden asignar a las particiones de manera automtica. En este
caso solo se paga por los procesadores de reserva cuando la capacidad total asignada
sobrepasa la capacidad de los procesadores activos iniciales.

V.6. IBM HACMP Clusters de Alta Disponibilidad
Filosofa de HACMP
La solucin HACMP (High Availability Cluster Multi-Processing) es la solucin
de alta disponibilidad que tiene IBM para sus sistemas pSeries y el sistema operativo
AIX, y est basada en la arquitectura de cluster. Proporciona a la vez dos entornos:
- Alta Disponibilidad: se asegura la disponibilidad de una aplicacin mediante
el uso de recursos duplicados y el acceso compartido a los datos. Es la
opcin ms interesante de esta solucin.
- Cluster Multi-Procesamiento: balanceo de la carga de trabajo y de las
comunicaciones mediante el acceso concurrente a los datos desde mltiples
nodos. Esta opcin solo es posible cuando la aplicacin soporta y gestiona el
acceso concurrente y en la actualidad hay muy pocas aplicaciones
comerciales que lo hagan, por lo que no es relevante para este proyecto ya
que no es el caso.

Objetivos de HACMP
Centrndose en la opcin de alta disponibilidad, el objetivo de HACMP es la
disponibilidad en continuo (o por lo menos la mxima posible) de las aplicaciones. Para
lograrlo se centra en dos aspectos:
Pgina 32 de 142

- operacin en continuo
o la arquitectura de cluster permite eliminar, o por lo menos
enmascarar, los tiempos de parada planificados por tareas de gestin.
Al estar constituido el cluster por varios nodos, los tiempos de
indisponibilidad de uno de los nodos no afectan a la disponibilidad de
la aplicacin ya que sta sigue activa en otro nodo.
- alta disponibilidad
o el uso de todos los componentes redundantes, incluidos los nodos, y
la automatizacin de las tareas de recuperacin reducen al mximo
los tiempos de cada por causas accidentales

Fundamentos de HACMP
Es una solucin basada en software pero que requiere que la configuracin
hardware sea adecuada, como por ejemplo el uso de componentes redundantes o la
configuracin de dos tipos distintos de redes de comunicacin (una red IP y una red no-
IP).
El software de HACMP chequea el estado de distintos componentes y la
disponibilidad de la aplicacin y automatiza mediante scripts las tareas de recuperacin
y reasignacin de los recursos (direcciones IP, discos, etc).

La solucin HACMP se basa en la creacin de grupos de recursos y de clusters.
Los clusters son asociaciones de servidores (o particiones) que comparten la
responsabilidad de mantener disponible una misma aplicacin (o varias). Si bien las
configuraciones ms usuales son las configuraciones de clusters de dos nodos se pueden
crear clusters con ms de dos nodos en funcin de las necesidades de cada entorno.
Los grupos de recursos son agrupaciones definidas que incluyen todos los
elementos necesarios para que una aplicacin est funcionando y disponible. Estos
recursos incluyen los discos y los filesystems con los datos, las direcciones IP y la
aplicacin (o las aplicaciones) que tienen que estar levantadas.
Dentro de un cluster, un grupo de recursos se considera como un solo elemento y
todos sus recursos se asignan a la vez a cada nodo, ya que no interesa que un nodo tenga
habilitada la direccin IP de acceso si los datos estn asignados a otro nodo.

Pgina 33 de 142

Clusters activo-activo y clusters activo-standby
Dentro de HACMP existen dos tipos bsicos de clusters diferentes: el cluster
activo-activo y el cluster activo-standby. Estos dos tipos se refieren bsicamente a
clusters de dos nodos, pero son extrapolables a clusters de ms nodos.
Un cluster es activo-activo cuando cada nodo tiene asociado al menos un grupo
de recursos. Esto implica que en condiciones normales cada nodo del cluster tiene al
menos una aplicacin activa. En caso de fallo de uno de los servidores el otro servidor
soporta la carga de las aplicaciones de ambos servidores.
Un cluster es activo-standby si solo uno de los dos servidores (en el caso de
clusters de dos nodos) tiene asociado algn grupo de recursos. Esto implica que en
condiciones normales solo uno de los nodos tiene activa una aplicacin, mientras que el
otro nodo est a la espera, de respaldo del primer nodo. En caso de fallo del servidor
que tiene la aplicacin el otro nodo tomara los recursos y activara la aplicacin. En
caso de fallo del servidor que est a la espera no pasa nada, salvo que el nodo con la
aplicacin se queda sin respaldo.
En el caso de clusters de ms de dos nodos las configuraciones ms usuales son
las siguientes:
- todos los nodos activos
o en esta configuracin todos los nodos tienen asociada una aplicacin.
En caso de fallo se suelen seguir polticas de fallover circulares.
- un nodo standby y el resto activos
o en esta configuracin todos los nodos menos uno tienen asociada una
aplicacin. En caso de fallo de alguno de los nodos activos se suele
tener definido en la poltica de fallover al nodo standby como
siguiente nodo para todas las aplicaciones.

Funcionamiento bsico de HACMP
En un cluster con los nodos y los grupos de recursos ya definidos, al arrancar el
cluster cada aplicacin se activa en un nodo. El nodo de activacin se define siguiendo
distintas polticas (nodo preferido, lista de prioridades, primer nodo activo o ltimo
nodo en el que estuvo activa) y se puede definir para cada aplicacin una poltica de
activacin distinta.
Pgina 34 de 142

La activacin de la aplicacin supone que el nodo se asigna los recursos
definidos para el grupo de recursos de la aplicacin en cuestin: tomar el control de los
discos compartidos y los filesystems con los datos, habilitar las direcciones IP en sus
adaptadores de red y levantar la aplicacin mediante el script definido para dicha tarea.

En ese momento empieza a monitorizar los distintos recursos; algunos elementos
se monitorizan mediante scripts propios de HACMP pero otros se tienen que
monitorizar mediante scripts definidos por el usuario (como por ejemplo la aplicacin o
elementos poco usuales como interfaces para X25). Si en algn momento detecta que
uno de los elementos no est disponible intentar recuperarlo en el mismo nodo. En el
caso del fallo de un adaptador de red habilitar la direccin IP en otro adaptador, o si el
fallo est en uno de los caminos de acceso a los discos compartidos habilitar el acceso
por otro camino. Si no puede recuperar el fallo en el mismo nodo inicia la accin de
fallover que consiste en trasladar los recursos a otro nodo (el siguiente disponible en
la lista de prioridades).
El orden en las listas de prioridades para el fallover se define de manera
independiente para cada grupo de recursos, por lo que distintas aplicaciones pueden
seguir polticas diferentes.

Por otro lado, mientras la aplicacin est activa en un nodo, el resto de nodos
monitoriza la disponibilidad del nodo y de la aplicacin. Si detectan que la aplicacin
no est disponible y que el nodo en el que est activa no puede recuperar el fallo, uno de
los nodos inicia por su cuenta el fallover de esa aplicacin, forzando el traspaso de los
recursos. Si solo existiese una red de comunicacin IP entre los nodos y sta fallase, se
podra dar el caso de que dos (o ms) nodos creyesen que la aplicacin no est
disponible en ningn nodo e intentasen tomar el control de los recursos y levantar la
aplicacin. Esto se conoce como cluster particionado y provoca fallos graves como la
inconsistencia o la corrupcin de los datos.

Los clusters particionados se evitan mediante el uso de dos tipos distintos de
redes de comunicacin. Por un lado estn las redes IP entre los nodos y con el exterior,
y por otro lado est una red no-IP que comunica nicamente los nodos de un cluster. De
Pgina 35 de 142

esta manera si la comunicacin IP entre los nodos falla todava se comunican a travs de
esta segunda red y no levantan varios nodos la aplicacin. Esta segunda red se puede
realizar mediante cables serie (redes punto a punto) o mediante la comunicacin a travs
de los discos compartidos.

En caso de que el nodo original vuelva a estar disponible el grupo de recursos
puede volver o no a dicho nodo, realizando la accin de fallback. La opcin de
realizar o no fallback se define para cada grupo de recursos y puede ser una de las
siguientes: realizar siempre fallback, no realizar nunca fallback y volver al nodo
original al reiniciar el cluster.

Pgina 36 de 142

VI. Diseo de la solucin

VI.1. Configuracin hardware
Servidores pSeries actuales
Dentro de la familia de servidores IBM System p5 los modelos actuales se
encuentran disponibles con procesadores de la gama POWER5 y POWER5+. Como ya
se ha visto, los sistemas con procesadores POWER5+ podrn actualizarse a POWER6
cuando est disponible (a lo largo de 2007), mientras que los sistemas con procesadores
POWER5 no podrn. Por lo tanto tan solo se tendrn en cuenta configuraciones con
procesadores POWER5+.
Dentro de la familia de servidores IBM System p5, teniendo en cuenta que
deben ser enracables y disponer de procesadores POWER5+, se encuentran las
siguientes opciones:

System p5 505 Express
- 1 o 2 procesadores POWER5+ 1,9 GHz o 2 procesadores POWER5+ 2,1
GHz
- de 1 GB a 32 GB de memoria DDR2 SDRAM
- hasta 600 GB de almacenamiento interno (2 bahas de discos)
- controladora Ultra320 SCSI Dual (interna y externa)
- tarjeta ethernet 10/100/1000 Mbps Dual
- 2 slots PCI-X (1 largo, 1 corto)
- enracable, 1 U de alto
- opcional:
o tarjeta Fibre Channel 4 GB
o tarjeta ethernet 10 Gbps

System p5 505Q Express
- 4 procesadores POWER5+ 1,65 GHz
- hasta 600 GB de almacenamiento interno (2 bahas de discos)
Pgina 37 de 142

- 2 slots PCI-X (1 largo, 1 corto)
- enracable, 1 U de alto
- opcional:

IBM System p5 505 y 505Q Express

- 1 o 2 procesadores POWER5+ 1,9 GHz o 2,1 GHz
- hasta 1,2 TB de almacenamiento interno (4 bahas de discos)
- 3 slots PCI-X
- enracable, 2 Us de alto
- opcional:

- 4 procesadores POWER5+ 1,5 GHz o 1,65 GHz
- hasta 1,2 TB de almacenamiento interno (4 bahas de discos)
Pgina 38 de 142

- 3 slots PCI-X
- opcional:


- 1 o 2 procesadores POWER5+ 1,65 GHz o 2,1 GHz o 2 procesadores
POWER5+ 1,9 GHz
- hasta 2,4 TB de almacenamiento interno (8 bahas de discos) hasta 16,8 TB
con cajones de expansin
- controladora Ultra320 SCSI Dual (interna)
- 6 slots PCI-X
- opcional:
o tarjeta Fibre Channel 4GB
o 4x InfiniBand Switch
o hasta 4 cajones de expansin 7311-D20

- 4 procesadores POWER5+ 1,5 GHz o 1,65 GHz
Pgina 39 de 142

- 6 slots PCI-X
- opcional:


- 2 o 4 procesadores POWER5+ 1,65 GHz o 1,9 GHz o 2,1 GHz
- 5 slots PCI-X
- opcional:
Pgina 40 de 142


- 4 u 8 procesadores POWER5+ 1,5GHz o 1,65 GHz
- 5 slots PCI-X
- opcional:


System p5 570
A diferencia de los modelos anteriores, que se componen de un solo bloque con
capacidad de proceso, el modelo 570 puede estar compuesto por ms de un bloque, en
funcin de la cantidad de memoria y del nmero de procesadores, slots PCI-X y bahas
de discos que se necesiten. Cada bloque de 4 Us de alto incorpora sus propios
Pgina 41 de 142

procesadores y memoria, sus bahas de discos internos (6 bahas) y sus slots PCI-X (6
slots), y se interconectan los mdulos de los procesadores y los buses de datos.

Caractersticas de una configuracin con un nico bloque:
- 2 o 4 procesadores POWER5+ 1,9 GHz o 2,2 GHz
- de 2 GB a 64 GB de memoria DDR2 SDRAM a 533 MHz, o de 32 a 128 GB
de memoria DDR2 a 400 MHz (solo con procesadores a 2,2 GHz)
- 2 controladoras Ultra320 SCSI (internas)
- 6 slots PCI-X hot-plug (5 largos, 1 corto)
- opcional:
o tarjeta Fibre Channel 2 GB o 4 GB
Caractersticas de la configuracin mxima con 4 bloques:
- hasta 16 procesadores POWER5+ 1,9 GHz o 2,2 GHz
- hasta 256 GB de memoria DDR2 a 533 MHz o hasta 512 GB de memoria
DDR2 a 400 MHz (solo con procesadores a 2,2 GHz)
- hasta 7,2 TB de almacenamiento interno (24 bahas de discos) hasta 79,2
TB con cajones de expansin
- 8 controladoras Ultra320 SCSI (internas)
- 4 tarjetas ethernet 10/100/1000 Mbps Duales
- 24 slots PCI-X hot-plug (20 largos, 4 cortos)
- opcional:
o tarjeta Fibre Channel 2 GB o 4 GB
Pgina 42 de 142

IBM System p5 570 Configuracin con un bloque

IBM System p5 570 Configuracin con dos bloques

IBM System p5 570 Configuracin con tres bloques

IBM System p5 570 Configuracin con cuatro bloques
Pgina 43 de 142

Cajn de expansin 7311-D20
Como se ha visto, en varios de estos modelos existe la posibilidad de ampliar el
nmero de discos y de ranuras para tarjetas mediante el uso de cajones de expansin
modelo 7311-D20.
Este cajn consiste en un bloque de 4 Us de alto que tiene 16 bahas de discos y
8 ranuras para tarjetas. Los cajones de expansin no incorporan procesadores ni
memoria.
Tablas de rendimiento: datos de rPerf
Las siguientes tablas muestran los datos rPerf de cada una de las configuraciones
presentadas. Estos datos muestran el rendimiento terico relativo en comparacin con la
configuracin base, que es un servidor pSeries 640 con un procesador POWER3-II a
375 MHz.

1.5 GHz 1.65 GHz 1.9 GHz 2.1 GHz

4 8 1 2 4 8 1 2 4 1 2 4
505 Express 4.10 11.49 12.46
505Q Express 20.25
510 Express 6.11 11.49 6.63 12.46
510Q Express 18.75 20.25
520 Express 3.62 10.15 11.16 6.63 12.46
520Q Express 18.75 20.25
550 Express 10.15 20.25 11.16 22.26 12.46 24.86
550Q Express 18.20 34.46 20.25 38.34
Rendimiento: Tabla de valores rPerf para los modelos 505, 510, 520 y 550

1.9 GHz 2.2 GHz
2 4 8 12 16 2 4 8 12 16
570 12.27 24.18 46.36 66.55 85.1 13.83 27.58 52.21 74.95 95.96
Rendimiento: Tabla de valores rPerf para los modelos 570

Eleccin del hardware
Como ya se ha visto, las posibilidades del particionamiento LPAR ofrecen
muchas ventajas en cuanto a aprovechamiento ptimo de los recursos, ahorro de costes
(mediante CoD) y gestin dinmica de los recursos y tambin supone una ventaja el
Pgina 44 de 142

ahorro de espacio que supone tener varios servidores en un mismo sistema. Por este
motivo se va a descartar los modelos 505 y 510 ya que no permiten este tipo de
particionamiento
1
.
Como ya se ha visto, los cajones de expansin 7311-D20 amplan la capacidad
total de discos y tarjetas de los servidores, pero no cuentan con procesadores ni
memoria. Por este motivo no se van a tener en cuenta configuraciones con cajones de
expansin, ya que ocupan espacio del rack sin aportar capacidad de procesamiento.
De manera parecida, la opcin de virtualizacin mediante el uso del VIO Server
aumenta el nmero de particiones posibles por servidor, pero reduce su capacidad de
proceso. Por este motivo tampoco se tendrn en cuenta configuraciones en las que sea
necesaria la virtualizacin.
Con estas restricciones, las configuraciones que cumplen los requisitos de
rendimiento marcados por los datos de rPerf son las siguientes:
Con servidores 520 y 520Q (2 controladoras de disco):
- para lograr un rPerf 40
o 4 servidores 520 con 2 procesadores (1,65 GHz, 1,9 GHz o 2,1 GHz)
16 Us en total
8 particiones mximo
o 2 servidores 520Q con 4 procesadores 1,65 GHz
8 Us en total
4 particiones mximo
o 8 servidores 520 con 2 procesadores 1,65 GHz o 1,9 GHz
32 Us en total
16 particiones mximo
o 7 servidores 520 con 2 procesadores 2,1 GHz
28 Us en total
16 Us en total
8 particiones mximo

1
Los modelos 505 y 510 permiten otro tipo de particionamiento mediante el uso del IVM (Integrated
Virtualization Manager) que no ofrece todas las ventajas del particionamiento LPAR.
Pgina 45 de 142

64 Us en total
60 Us en total
52 Us en total
o 8 servidores 520Q con 4 procesadores 1,65 GHzz
32 Us en total

Con servidores 550 y 550Q (2 controladoras de discos):
12 Us en total
6 particiones mximo
8 Us en total
4 particiones mximo
16 Us en total
8 particiones mximo
o 2 servidores 550 o 550Q con 4 procesadores 1,65 GHz
8 Us en total
4 particiones mximo
8 Us en total
4 particiones mximo
16 Us en total
8 particiones mximo
Pgina 46 de 142

8 Us en total
4 particiones mximo
o 4 procesadores 550 con 2 procesadores 2,1 GHz
16 Us en total
8 particiones mximo
8 Us en total
4 particiones mximo
20 Us en total
12 Us en total
6 particiones mximo
32 Us en total
16 Us en total
8 particiones mximo
12 Us en total
6 particiones mximo
32 Us en total
16 Us en total
8 particiones mximo
28 Us en total
Pgina 47 de 142

16 Us en total
8 particiones mximo
36 Us en total
20 Us en total
64 Us en total
32 Us en total
20 Us en total
60 Us en total
32 Us en total
52 Us en total
28 Us en total

Pgina 48 de 142

Con servidores 570:
o 8 procesadores 1,9 GHz o 2,2 GHz
a repartir en servidores de 2, 4 u 8 procesadores
8 o 16 Us en total (16 con servidores de 2 procesadores)
4 u 8 particiones (8 con servidores de 2 procesadores)
o 16 procesadores 1,9 o 2,2 GHz
a repartir en servidores de 2, 4, 8, 12 y 16 procesadores
entre 16 y 32 Us en total (32 Us con solo servidores de 2
procesadores)
entre 8 y 16 particiones (16 con servidores de 2 procesadores)
o 32 procesadores 1,9 GHz
mnimo de 32 Us (hasta 64 Us si se usan servidores de 2
procesadores)
16 particiones o ms (hasta 32 particiones si se usan
servidores de 2 procesadores)
o 28 procesadores 2,2 GHz
mnimo de 28 Us (hasta 56 Us si se usan servidores de 2
procesadores)
14 particiones o ms (hasta 28 particiones si se usan
servidores de 2 procesadores)

En todos los casos se obtienen datos de rendimiento y de ocupacin de espacio
en los armarios parecidos, aunque un poco superiores las configuraciones con servidores
570 en cuanto a rendimiento. Al no existir una ventaja clara de una configuracin
respecto del resto segn estos parmetros se optar por la configuracin que ofrezca
ms ventajas en cuanto a flexibilidad de las configuraciones, mayor facilidad de
ampliacin y/o menor complejidad de administracin de los sistemas.

Los servidores 570 tienen mayor capacidad de ampliacin y adems se pueden
configurar sistemas de gran capacidad ms sencillos de gestionar que los sistemas
Pgina 49 de 142

equivalentes con servidores 520 y 550 (se puede tener una configuracin de 16
procesadores y 8 particiones en un nico sistema, mientras que con los otros modelos
haran falta 2 o 4 sistemas para obtener eso mismo).

Debido a esto se optar por una configuracin con servidores 570. Dentro de la
gama de los 570, la diferencia de precio entre los procesadores a 1,9 GHz y los
procesadores a 2,2 GHz es bastante ms significativa que la diferencia de rendimiento
que se obtiene. Por esta razn los procesadores a 2,2 GHz resultan menos rentables que
los procesadores a 1,9 GHz, que son los que se usarn en la configuracin ofertada.

Dentro de las configuraciones posibles usando servidores 570 se recomienda una
configuracin que cumpla las siguientes caractersticas:
- capacidad de proceso activada total suficiente para hacer frente a las
previsiones de crecimiento a corto plazo (rPerf 80)
o esto implica un mnimo de 16 procesadores de 1,9 GHz activos.
- capacidad de proceso instalada (activa + inactiva) total suficiente para hacer
frente a las previsiones de crecimiento a medio plazo (rPerf 160)
o esto implica un mnimo de 32 procesadores de 1,9 GHz instalados.
- reparticin de la capacidad en distintos servidores, de manera que todos los
servidores tengan posibilidad de ampliacin
o esto implica que la oferta no debe incluir ningn servidor con 16
procesadores, ya que este servidor no tendra posibilidad de
ampliacin.
- equiparar las particiones de los sistemas con los servidores actuales
o con una configuracin que tenga una particin por servidor se
facilitar en gran medida el proceso de migracin. Esto implica una
configuracin con 16 particiones.

Una vez que se defina la topologa de cluster de la solucin y la asociacin de
nodos en los clusters y de particiones en los sistemas se realizar la configuracin final
a ofertar siguiendo estas recomendaciones.

Pgina 50 de 142

VI.2. Configuracin HACMP

Para definir la topologa de los clusters HACMP, lo primero es identificar las
aplicaciones que tendrn que soportar los nodos de los clusters. Segn la relacin de
servidores y aplicaciones suministrada por el cliente se obtienen los siguientes:
- Servidor Baco: aplicacin Ediswitch
- Servidor Ceres: aplicaciones Editran y Expedite
- Servidor Diana: aplicacin Odex
- Servidor Febo: aplicacin Odex
- Servidor Juno: aplicacin Oracle
- Servidor Jupiter: aplicacin Oracle
- Servidor Marte: aplicacin Oracle
- Servidor Mercurio: aplicaciones Oracle e Informix

Siguiendo las recomendaciones de equiparar los servidores actuales con las
particiones LPAR de los nuevos sistemas, se mantendr esta estructura y no se
agruparn las aplicaciones de varios servidores en un nodo.

Como ya se ha visto HACMP permite crear clusters de diferentes tamaos. Se
podra por lo tanto disear una solucin que en un nico cluster incluyese los 8 nodos, o
dos clusters de 4 nodos cada uno. Sin embargo al aumentar la complejidad de un cluster
aadiendo nodos la dificultad de administracin crece de manera exponencial: es mucho
ms complicado de administrar un cluster de 4 nodos que 2 clusters de 2 nodos cada
uno, aumentando los errores debidos a una mala administracin. Debido a esto se
disear la solucin exclusivamente con clusters de dos nodos.

Con estas premisas, y sabiendo que se van a usar particiones de servidores 570,
se pueden disear varias configuraciones posibles:

Pgina 51 de 142

Configuracin 1
Se trata de una configuracin con 2 servidores 570, con 8 particiones cada
servidor. Consta de 8 clusters de dos nodos en modo activo-standby. Todos las
aplicaciones de produccin estn asociadas a los nodos de las particiones de un mismo
servidor. Las particiones del otro servidor se corresponden con los servidores de
desarrollo y calidad que no necesitan estar en alta disponibilidad.

Configuracin de clusters Configuracin 1

Configuracin 2
Se trata tambin de una configuracin con 2 servidores 570, cada uno con 8
particiones LPAR. Consta tambin de 8 clusters de 2 nodos en modo activo-standby,
pero en este caso la mitad de las aplicaciones de produccin estn asociadas a
particiones de un servidor y la otra mitad de las aplicaciones est asociada a particiones
del otro servidor. El resto de particiones tambin se corresponden con los servidores de
calidad y desarrollo.

LPAR1.1
LPAR1.2
LPAR1.3
LPAR1.4
LPAR1.5
LPAR1.6
LPAR1.7
LPAR1.8
LPAR2.1
LPAR2.2
LPAR2.3
LPAR2.4
LPAR2.5
LPAR2.6
LPAR2.7
LPAR2.8
Cluster1
Cluster2
Cluster3
Cluster4
Cluster5
Cluster6
Cluster7
Cluster8
Servidor 1 Servidor 2
Pgina 52 de 142


Configuracin 3
Se trata tambin de una configuracin con dos servidores 570, cada uno con 8
particiones. La diferencia con las dos configuraciones anteriores reside en que en este
caso consta de solo 4 clusters, cada uno de dos nodos en modo activo-activo. Los
clusters tienen cada nodo en un servidor distinto.

LPAR1.1
LPAR1.2
LPAR1.3
LPAR1.4
LPAR2.5
LPAR2.6
LPAR2.7
LPAR2.8
LPAR2.1
LPAR2.2
LPAR2.3
LPAR2.4
LPAR1.5
LPAR1.6
LPAR1.7
LPAR1.8
Cluster1
Cluster2
Cluster3
Cluster4
Cluster5
Cluster6
Cluster7
Cluster8
LPAR1.1
LPAR1.2
LPAR1.3
LPAR1.4
LPAR2.1
LPAR2.2
LPAR2.3
LPAR2.4
LPAR2.5
LPAR2.6
LPAR2.7
LPAR2.8
LPAR1.5
LPAR1.6
LPAR1.7
LPAR1.8
Cluster1
Cluster2
Cluster3
Cluster4
Pgina 53 de 142

Configuracin 4
A diferencia de las configuraciones anteriores, esta configuracin est
constituida por 4 servidores 570, cada uno con 4 particiones. Consta de 8 clusters de dos
nodos en modo activo-standby.


Configuracin 5
Al igual que en la configuracin anterior, esta es una configuracin con 4
servidores 570, cada uno de 4 particiones. La diferencia reside en que en esta
configuracin los clusters son activo-activo. Es una configuracin con 4 clusters, en la
que cada nodo tiene asociada una aplicacin. Los 4 clusters residen en las particiones de
2 servidores, mientras que las particiones de los otros dos servidores se usan para los
servidores de desarrollo y calidad.

LPAR1.1
LPAR1.2
LPAR1.3
LPAR1.4
LPAR4.1
LPAR4.2
LPAR4.3
LPAR4.4
LPAR2.1
LPAR2.2
LPAR2.3
LPAR2.4
LPAR3.1
LPAR3.2
LPAR3.3
LPAR3.4
Cluster1
Cluster2
Cluster3
Cluster4
Cluster5
Cluster6
Cluster7
Cluster8
Pgina 54 de 142


Configuracin 6
Al igual que las dos configuraciones anteriores, esta configuracin se basa en 4
servidores 570, cada uno con 4 particiones. Al igual que en la configuracin anterior se
basa en 4 clusters de tipo activo-activo, de dos nodos cada cluster. La diferencie de esta
configuracin reside en que los clusters estn repartidos en todos los servidores.
LPAR1.1
LPAR1.2
LPAR1.3
LPAR1.4
LPAR2.1
LPAR2.2
LPAR2.3
LPAR2.4
LPAR4.1
LPAR4.2
LPAR4.3
LPAR4.4
LPAR3.1
LPAR3.2
LPAR3.3
LPAR3.4
Cluster1
Cluster2
Cluster3
Cluster4
Servidor 3
Servidor 4
Pgina 55 de 142


Eleccin de la topologa de los clusters
Las configuraciones con clusters en modo activo-standby tienen una desventaja
frente a las configuraciones con clusters activo-activo. En el primer caso se requiere
licencias para 8 clusters y 16 nodos, mientras que en el segundo solo se requieren para 4
clusters y 8 nodos. El uso de clusters activo-activo supone por lo tanto un ahorro en
licencias de software. Por otro lado en un cluster activo-standby se pueden mezclar los
entornos de produccin y de desarrollo y calidad: en caso de fallover de la aplicacin
de produccin, el nodo de reserva tendra activas a la vez la aplicacin de produccin
del otro nodo y sus propias aplicaciones de desarrollo, lo que no es muy conveniente.

Por otro lado, para crear 8 particiones en un servidor 570 sin usar cajones de
expansin ni VIO Server es necesario que los servidores consten de 4 bloques. En estas
configuraciones los servidores ya no son ampliables en cuanto a nmero de particiones,
por lo que son configuraciones menos flexibles que las de 4 servidores con 4
particiones.

LPAR1.1
LPAR1.2
LPAR3.1
LPAR3.2
LPAR2.1
LPAR2.2
LPAR4.1
LPAR4.2
LPAR2.3
LPAR2.4
LPAR4.3
LPAR4.4
LPAR1.3
LPAR1.4
LPAR3.3
LPAR3.4
Cluster1
Cluster2
Cluster3
Cluster4
Servidor 1
Servidor 2
Pgina 56 de 142

En el caso de las configuraciones 5 y 6 ambas tienen 4 servidores de 4
particiones y ambas tienen 4 clusters en modo activo-activo. La diferencia reside en que
si se cae el servidor 1, en la configuracin 5 se hace fallover de ms aplicaciones que
en la configuracin 6. Por lo tanto es mejor la configuracin 6 ya que distribuye los
clusters por todos los servidores, minimizando las consecuencias de un fallo grave. La
solucin adoptada se basar por lo tanto en la configuracin 6.

Tambin se podran realizar configuraciones utilizando ms servidores 570 con
menos particiones cada uno, por ejemplo 8 servidores de 2 particiones. Esto aumenta el
nmero de servidores fsicos a gestionar, lo que supone una administracin ms
laboriosa sin aportar mucho en cuanto a flexibilidad. Tambin aumentara el coste total
de la solucin, por lo que no se han tenido en cuenta.

VI.3. Diseo final
Configuracin de base
La configuracin de base de los sistemas ofertados es la siguiente:
- 4 servidores IBM Systemp5 570
- cada servidor con 8 procesadores instalados
o 4 de ellos activos
- cada servidor con 32 GB de memoria instalados
o 16 GB activos
- 4 particiones LPAR por servidor
o servidores de dos bloques
- opcin de virtualizacin
o necesaria para procesadores compartidos
- 2 consolas HMC
o cada consola puede gestionar los 4 servidores, se ponen dos para
tener redundancia
- licencias de AIX para los procesadores activos
o si se activan ms procesadores se comprarn las licencias necesarias
- licencias de HACMP para 4 clusters y 8 nodos
Pgina 57 de 142

En base a los datos de rendimiento de los servidores actuales, a otros datos de
afinidad de hardware (como la necesidad de tarjetas X25) y a las configuraciones para
HACMP, se define la asociacin de servidores a particiones LPAR y la asociacin de
nodos en los clusters de HACMP.

Asociacin de servidores a particiones LPAR
Servidor 1:
- LPAR1.1 Servidor Baco
- LPAR1.2 Servidor Ceres
- LPAR1.3 Servidor Pluton
- LPAR1.4 Servidor Saturno

Servidor 2:
- LPAR2.1 Servidor Diana
- LPAR2.2 Servidor Febo
- LPAR2.3 Servidor Urano
- LPAR2.4 Servidor Venus

Servidor 3:
- LPAR3.1 Jupiter
- LPAR3.2 Marte
- LPAR3.3 Cupido
- LPAR3.4 Ops

Servidor 4:
- LPAR4.1 Juno
- LPAR4.2 Mercurio
- LPAR4.3 Minerva
- LPAR4.4 Neptuno

Pgina 58 de 142

Asociacin de nodos en los clusters HACMP
Cluster 1:
- Nodo 1: Servidor Baco (LPAR1.1)
- Nodo 2: Servidor Diana (LPAR2.1)

Cluster 2:
- Nodo 1: Servidor Ceres (LPAR1.2)
- Nodo 2: Servidor Febo (LPAR2.2)

Cluster 3:
- Nodo 1: Servidor Jupiter (LPAR3.1)
- Nodo 2: Servidor Juno (LPAR4.1)

Cluster 4:
- Nodo 1: Servidor Marte (LPAR3.2)
- Nodo 2: Servidor Mercurio (LPAR4.2)

Hardware adicional
Adems de los procesadores y las memorias existen otros recursos que son
necesarios para las particiones. Estos recursos son los discos, los puertos de red ethernet
(y X25 en algunas particiones), las tarjetas de fibra en caso necesario y las unidades de
cinta y CD. En la configuracin de base de los servidores vienen integrados algunos
puertos de red (una controladora de red con dos puertos por cada bloque) pero ninguno
de los otros recursos necesarios.
Por otro lado las consolas HMC necesitan una pantalla, teclado y ratn, por lo
menos en la instalacin ya que despus es posible administrarlas en remoto.
Por lo tanto, para completar la configuracin hardware es necesario incluir los
siguientes elementos:
- discos
- tarjetas de red
- tarjetas de fibra
- unidades de cinta y CD
- pantalla, teclado y ratn
Pgina 59 de 142

Discos
Para estos modelos de servidores existen varios modelos de discos, con distintas
capacidades y velocidades: a 10.000 rpm de 73,4 GB, 146,8 GB y 300 GB, y a 15.000
rpm de 73,4 GB y 146,8 GB. Todos estos modelos son de tipo Ultra320 SCSI.
En esta configuracin los discos internos solo van a soportar el sistema operativo
y los binarios de las aplicaciones y solo en los casos de desarrollo y calidad se utilizarn
para datos de las aplicaciones. Debido a esto no son necesarias ni una gran capacidad ni
la velocidad mxima, por lo que se configurarn discos de 73,4 GB a 10.000 rpm.
Como ya se ha comentado todos las particiones van a usar dos discos internos en
mirror, por lo que en total son necesarios 8 discos por servidor, 32 discos en total.

Tarjetas de red
En cada bloque de los servidores viene integrada una controladora ethernet con
dos puertos. En esta configuracin cada servidor consta de dos bloques, por lo que
vienen dos controladoras y cuatro puertos integrados por servidor.

Cada servidor de desarrollo y training est conectado a las siguientes sub-redes:
- una red de explotacin
o es la red que utilizan los usuarios para acceder a las aplicaciones
- una red de gestin
o es la red que utilizan los administradores del sistema y de las
aplicaciones para la gestin del sistema, de las aplicaciones y para las
copias de seguridad
- una red NAS
o es la red para el acceso a servidores de almacenamiento NAS
Cada particin de desarrollo o calidad necesita por lo tanto al menos 3 puertos de red.

Para la configuracin de HACMP se recomienda utilizar siempre y cuando sea
posible 4 puertos de red repartidos en por lo menos dos controladoras. En este caso
adems es necesario que los servidores de produccin estn conectados a la red de
gestin y tambin a la red NAS.
Pgina 60 de 142

Como los puertos dedicados a HACMP no deben usarse para redes configuradas
fuera del cluster son necesarios por lo menos 6 puertos de red, repartidos en al menos
dos controladoras.

Para los servidores 570 estn disponibles tarjetas PCI-X Ethernet 10/100/1000
Mbps de un puerto, dos puertos y cuatro puertos. Usando los puertos integrados y
tarjetas adicionales, la configuracin que menor nmero de ranuras PCI-X utiliza es la
siguiente:
- particiones de produccin
o a cada particin se le asigna una controladora ethernet integrada y
una tarjeta PCI-X de 4 puertos. Se utilizan los dos puertos integrados
y dos puertos de la tarjeta PCI-X para HACMP, y los dos puertos
restantes de la tarjeta para la red de gestin y para la red NAS.
- particiones de desarrollo/calidad
o a cada particin se le asigna una tarjeta PCI-X de 4 puertos,
quedando un puerto sin usar.
Con esta configuracin son por lo tanto necesarias 4 tarjetas PCI-X de 4 puertos
por cada servidor, 16 tarjetas en total.
Las particiones que necesitan tarjetas X25 utilizarn las tarjetas de los servidores
actuales.

Tarjetas de fibra
Entre las aplicaciones de produccin hay algunas que no tienen necesidad real de
disponer de almacenamiento externo en cabina: no manejan muchos datos, y son datos
que no siempre es necesario poner a disposicin del otro nodo en caso de fallover. Sin
embargo la configuracin de HACMP exige la creacin de una red no-IP, que puede ser
mediante cable serie o a travs de discos compartidos.
Los servidores 570 no tienen puertos serie a disposicin de las particiones, por lo
que para hacer la red no-IP se va a usar la opcin de discos compartidos.
Cada particin necesita 2 puertos de fibra para conectarse a la cabina de discos a
travs de dos caminos, y es recomendable que cada puerto est en una controladora
separada.
Pgina 61 de 142

Se necesitan por lo tanto 2 tarjetas de fibra con un puerto cada una para cada
particin de produccin, lo que hace un total 8 tarjetas de fibra de un puerto.

Unidades de cinta y CD
Las particiones necesitan un lector de CD, por lo menos para la instalacin
inicial, y una unidad de cinta para realizar y restaurar copias de seguridad del sistema
operativo. Los servidores 570 pueden incorporar un lector de CD/DVD integrado, pero
no incluyen unidad de cinta. Para los servidores pSeries existen dispositivos llamados
unidades externas de media, que pueden incorporar hasta 2 lectores de distintos
formatos: CD/DVD, cinta DAT72 de 4mm, cinta VXA-2 o VXA-320, HHLTO Ultrium
2, etc
Ya que es necesaria una unidad de media por servidor, se incorporarn los dos
dispositivos necesarios en dicha unidad, y no se incluir el lector de CD/DVD interno.
Se necesita por lo tanto una unidad de media con lector de CD/DVD y unidad de cinta
DAT72 para cada servidor, en total 4 unidades de media.

La cinta y el CD de la unidad de media se conectan al servidor mediante cables
SCSI, pero el servidor no incluye ningn puerto SCSI. Se necesita un puerto SCSI para
cada dispositivo de la unidad, y existen tarjetas PCI-X SCSI de dos puertos.
Se necesita por lo tanto una tarjeta PCI-X SCSI de dos puertos por servidor, en total 4
tarjetas.

Pantalla, teclado y ratn
En la actualidad el cliente tiene 3 pantallas TFT que tienen integrado el teclado y
un touchpad. Cada una de estas pantallas ocupa 2 Us.
Al principio se pensaba reutilizar 2 de estas pantallas para las consolas HMC,
pero al realizar la configuracin se ha visto que en caso de ampliacin, el hecho de que
las pantallas ocupasen 2 Us en vez de una sola forzaba a usar un tercer armario. Por esto
se ha decidido incluir 2 pantallas TFT, con teclado y trackpoint, de una sola U.

Pgina 62 de 142

VII. Evaluacin Econmica de la Oferta
VII.1. Valoracin Econmica HW/SW

Server 1

********************************* HARDWARE *********************************

Product Description Qty Purchase Maint

9117-570 Server 1:9117 Model 570 1 3.545,00 125,47
265 AIX Partition Specify 4 N/C
1846 Op Panel 1 184,28
1847 Processor Cable, Two-Drawer 1 2.450,00
System
1857 SP Flex Cable, Two-Drawer 1 1.225,00
System
3274 73.4 GB 10,000 RPM Ultra320 8 4.783,52
SCSI Disk Drive Assembly
4650 Rack Indicator- Not Factory 1 N/C
Integrated
5005 Software Preinstall 1 N/C
5716 2 Gigabit Fibre Channel PCI-X 4 8.240,00
Adapter
5736 PCI-X Dual Channel Ultra320 1 1.834,92
SCSI Adapter
5740 IBM 4-Port 10/100/1000 BaseT 4 4.948,00
Ethernet PCI-X Adapter
6671 Power Cord (9-foot), Drawer to 4 74,04
IBM PDU, 250V/10A
7164 IBM Rack-mount Drawer Rail Kit 2 411,68
7300 System Drawer Enclosure w/ 2 1.418,00
Bezel
7665 One way Processor Activation 4 29.384,00 475,04
for Processor FC 7782
7768 Processor Power Regulator 6 4.016,16
7782 2-Way 1.9 GHz POWER5+ 4 29.384,00 529,56
Processor Card, 0-way active,
8 DDR2 Memory Slots
7865 CEC Backplane 2 2.938,00
7866 I/O Backplane 2 10.044,00
7867 Midplane 2 1.225,26
Pgina 63 de 142

7868 DASD Backplane 2 2.938,00
7869 Media Backplane 1 171,53
7870 Power Midplane 2 490,1
7878 System Port Riser Card 2 245,04
7888 AC Power Supply, 240V, 1400 W 4 3.920,88
7892 2GB (4x512MB) DIMMs, 276-pin, 8 20.032,00
533 MHz DDR2 SDRAM
7942 Advanced POWER Virtualization 4 4.848,00
7997 Service Processor Card (FSP) 1 796,91
9169 Order Routing Indicator- System 1 N/C
Plant
9708 Language Group Specify - 1 N/C
Spanish
========== ========
9117-570 Price 139.548,32
Monthly Maintenance 1.130,07

7212-103 Storage Tape and DVD Enclosure 1 1.500,00 11,11
Express Model
1103 DVD-RAM Drive 1 870,84 6,43
1105 DAT72 Tape Drive 1 1.573,00 14,58
1215 Rack Mount Kit 1 174
9006 IBM System p install 1 N/C
9708 Publications - Spanish 1 N/C
9764 4.5m VHDCI/HD68 SCSI Cable 2 N/C
9860 2.7m (9ft) Rack Power 1 N/C
Cord,AC,Single
======== =====
7212-103 Price 4.117,84
Monthly Maintenance 32,12

********************************* SOFTWARE *********************************

Product Description Qty License

5662-HMP HACMP Reg:3Yr 1 N/C
5809 Software Maintenance Agreement 1 N/C
U0CTC5 HACMP Base SW MAINT per proc 3Y 4 4.536,00
Reg MEDIUM
=========
5662-HMP OTC 4.536,00

Pgina 64 de 142

5692-A5L System Software 1 N/C
0999 Virtual I/O Server 1 N/C
1005 Process no-charge 1 N/C
2931 Spanish SBCS Primary Language 1 N/C
3410 CD-ROM 1 N/C

0967 MEDIA 5765-G03 AIX 5L V5.3 1 N/C
0968 Expansion pack 1 N/C
0970 AIX 5L V5.3 Update CD 1 N/C
0975 Microcode Upd Files and Disc 1 N/C
Tool CD
1004 CD-ROM Process Charge 1 57,00
1403 Preinstall 64-bit Kernel 1 N/C
1424 Partition Load Manager 1 N/C
1489 HACMP V5.4 1 N/C
3410 CD-ROM 1 N/C
5924 English U/L SBCS Secondary 1 N/C
Language
PRL1 Preinstall 1 N/C
=========
5692-A5L OTC 57,00

5765-F62 HACMP V5 1 N/C
U7BCC1 Per Proc with 1 Year SW Maint 4 13.352,00
MEDIUM
=========
5765-F62 OTC 13.352,00

5765-G03 AIX 5L V5.3 1 N/C
A4RNK3 Per Processor F5 AIX 5L V5.3 4 5.244,00
=========
5765-G03 OTC 5.244,00

5765-G31 Partition Load Manager 1 N/C
B4RZB4 Per Processor F5 Partition Load 4 N/C
Mgr

5765-G34 Virtual I/O Server 1 N/C
B4RWB4 Per Processor F5 Virtual I/O 4 N/C
Server

5773-PLM Partition Load Manager SW 1 N/C
Maint: 3 year
Pgina 65 de 142

U0NCC5 5773-PLM SW MAINT 3Y Reg F5 4 233,04
=========
5773-PLM OTC 233,04

5773-SM3 Software Maintenance for AIX, 3 1 N/C
Year
U0PLC5 F5 3 Yr SWMA for AIX per 4 9.412,00
Processor Reg
=========
5773-SM3 OTC 9.412,00

5773-VIO Virtual I/O Server SW 1 N/C
Maintenance: 3 Yr
U0NHC5 Per Processor F5 VIO 3 Yr 4 1.029,60
Maintenance
=========
5773-VIO OTC 1.029,60

******************************* GRAND TOTALS *******************************

Hardware Price 143.666,16
Software OTC 33.863,64
=========== ========
System Total 177.529,80

N/O - Not Offered
N/A - Price Not Available in Price Database
N/C - No Charge
A - Annual Maintenance Price
W/D - WITHDRAWN
F - ESA 24x7 Full Coverage
P - ESA 9x5 Prime Coverage

Parts removed as a result of a model upgrade become the property of IBM.

Pgina 66 de 142

************************ ERROR AND WARNING MESSAGES ************************

INFORMATIONAL: Automatically configured
Integrated Ultra320 SCSI controllers (2 per drawer)
System ports (serial) (2)
Integrated 10/100/1000 Mbps Ethernet Port (2 per drawer)
Integrated USB Ports (2 per drawer)
Two HMC ports per active Service Processor

Server 2

********************************* HARDWARE *********************************


9117-570 Server 1:9117 Model 570 1 3.545,00 125,47
1846 Op Panel 1 184,28
System
System
3274 73.4 GB 10,000 RPM Ultra320 8 4.783,52
Integrated
Adapter
SCSI Adapter
5740 IBM 4-Port 10/100/1000 BaseT 4 4.948,00
IBM PDU, 250V/10A
Bezel
Pgina 67 de 142

7782 2-Way 1.9 GHz POWER5+ 4 29.384,00 529,56
8 DDR2 Memory Slots
7866 I/O Backplane 2 10.044,00
7867 Midplane 2 1.225,26
7892 2GB (4x512MB) DIMMs, 276-pin, 8 20.032,00
533 MHz DDR2 SDRAM
Plant
Spanish
========== ========
9117-570 Price 139.548,32

Express Model
1103 DVD-RAM Drive 1 870,84 6,43
1105 DAT72 Tape Drive 1 1.573,00 14,58
9006 IBM System p install 1 N/C
9708 Publications - Spanish 1 N/C
9764 4.5m VHDCI/HD68 SCSI Cable 2 N/C
9860 2.7m (9ft) Rack Power 1 N/C
Cord,AC,Single
======== =====
7212-103 Price 4.117,84

********************************* SOFTWARE *********************************


Pgina 68 de 142

Reg MEDIUM
=========
5662-HMP OTC 4.536,00

3410 CD-ROM 1 N/C

0967 MEDIA 5765-G03 AIX 5L V5.3 1 N/C
Tool CD
1489 HACMP V5.4 1 N/C
3410 CD-ROM 1 N/C
Language
=========
5692-A5L OTC 57,00

5765-F62 HACMP V5 1 N/C
MEDIUM
=========
5765-F62 OTC 13.352,00

5765-G03 AIX 5L V5.3 1 N/C
=========
5765-G03 OTC 5.244,00

Mgr
Pgina 69 de 142

Server

Maint: 3 year
=========
5773-PLM OTC 233,04

Year
Processor Reg
=========
5773-SM3 OTC 9.412,00

Maintenance: 3 Yr
Maintenance
=========
5773-VIO OTC 1.029,60

******************************* GRAND TOTALS *******************************

========== ========

N/O - Not Offered
N/C - No Charge
W/D - WITHDRAWN
Pgina 70 de 142





Server 3

********************************* HARDWARE *********************************


9117-570 Server 1:9117 Model 570 1 3.545,00 125,47
1846 Op Panel 1 184,28
System
System
3274 73.4 GB 10,000 RPM Ultra320 8 4.783,52
Integrated
Adapter
SCSI Adapter
5740 IBM 4-Port 10/100/1000 BaseT 4 4.948,00
IBM PDU, 250V/10A
Pgina 71 de 142

Bezel
7782 2-Way 1.9 GHz POWER5+ 4 29.384,00 529,56
8 DDR2 Memory Slots
7866 I/O Backplane 2 10.044,00
7867 Midplane 2 1.225,26
7892 2GB (4x512MB) DIMMs, 276-pin, 8 20.032,00
533 MHz DDR2 SDRAM
Plant
Spanish
========== ========
9117-570 Price 139.548,32

Express Model
1103 DVD-RAM Drive 1 870,84 6,43
1105 DAT72 Tape Drive 1 1.573,00 14,58
9006 IBM System p install 1
9708 Publications - Spanish 1
9764 4.5m VHDCI/HD68 SCSI Cable 2
9860 2.7m (9ft) Rack Power 1
Cord,AC,Single
======== =====
7212-103 Price 4.117,84

Pgina 72 de 142

********************************* SOFTWARE *********************************


Reg MEDIUM
=========
5662-HMP OTC 4.536,00

3410 CD-ROM 1 N/C

0967 MEDIA 5765-G03 AIX 5L V5.3 1 N/C
Tool CD
1489 HACMP V5.4 1 N/C
3410 CD-ROM 1 N/C
Language
=========
5692-A5L OTC 57,00

5765-F62 HACMP V5 1 N/C
MEDIUM
=========
5765-F62 OTC 13.352,00

5765-G03 AIX 5L V5.3 1 N/C
=========
Pgina 73 de 142

5765-G03 OTC 5.244,00

Mgr

Server

Maint: 3 year
=========
5773-PLM OTC 233,04

Year
Processor Reg
=========
5773-SM3 OTC 9.412,00

Maintenance: 3 Yr
Maintenance
=========
5773-VIO OTC 1.029,60

******************************* GRAND TOTALS *******************************

=========== ========

Pgina 74 de 142

N/O - Not Offered
N/C - No Charge
W/D - WITHDRAWN




Server 4

********************************* HARDWARE *********************************


9117-570 Server 1:9117 Model 570 1 3.545,00 125,47
1846 Op Panel 1 184,28
System
System
3274 73.4 GB 10,000 RPM Ultra320 8 4.783,52
Integrated
5005 Software Preinstall 1
Adapter
SCSI Adapter
Pgina 75 de 142

5740 IBM 4-Port 10/100/1000 BaseT 4 4.948,00
IBM PDU, 250V/10A
Bezel
7782 2-Way 1.9 GHz POWER5+ 4 29.384,00 529,56
8 DDR2 Memory Slots
7866 I/O Backplane 2 10.044,00
7867 Midplane 2 1.225,26
7892 2GB (4x512MB) DIMMs, 276-pin, 8 20.032,00
533 MHz DDR2 SDRAM
Plant
Spanish
========== ========
9117-570 Price 139.548,32

Express Model
1103 DVD-RAM Drive 1 870,84 6,43
1105 DAT72 Tape Drive 1 1.573,00 14,58
9006 IBM System p install 1
9708 Publications - Spanish 1
9764 4.5m VHDCI/HD68 SCSI Cable 2
9860 2.7m (9ft) Rack Power 1
Cord,AC,Single
======== =====
Pgina 76 de 142

7212-103 Price 4.117,84

********************************* SOFTWARE *********************************


Reg MEDIUM
=========
5662-HMP OTC 4.536,00

3410 CD-ROM 1 N/C

0967 MEDIA 5765-G03 AIX 5L V5.3 1 N/C
Tool CD
1489 HACMP V5.4 1 N/C
3410 CD-ROM 1 N/C
Language
=========
5692-A5L OTC 57,00

5765-F62 HACMP V5 1 N/C
MEDIUM
=========
5765-F62 OTC 13.352,00
Pgina 77 de 142

5765-G03 AIX 5L V5.3 1 N/C
=========
5765-G03 OTC 5.244,00

Mgr

Server

Maint: 3 year
=========
5773-PLM OTC 233,04

Year
Processor Reg
=========
5773-SM3 OTC 9.412,00

Maintenance: 3 Yr
Maintenance
=========
5773-VIO OTC 1.029,60

******************************* GRAND TOTALS *******************************

========== ========
Pgina 78 de 142


N/O - Not Offered
N/C - No Charge
W/D - WITHDRAWN




HMC 1

********************************* HARDWARE *********************************


7310-CR3 HMC 1:7310-CR3 Rack-mounted 1 4.116,00 51,77
Hardw.Mgmt.Console
0961 Hardware Management Console for 1 N/C
POWER5 Licensed Machine Code
3645 T117 TFT 17-inch Color Display 1 810,16
4242 6 Foot Extender Cable for 1 134,45
Displays (15 pin D-shell to 15
pin D-shell)
Integrated
Pgina 79 de 142

5956 Full Width Quiet Touch Keyboard 1 131,97
-- USB, Spanish, #172
6458 Power Cord (14ft) 250V/14A, 1 20,48
IEC320/C13, IEC320/C14
6472 Power Cord (9-foot), To 1 20,24
Wall/OEM PDU, (250V, 16A),
Plug Type #18
7801 Ethernet Cable, 6M, Hardware 1 17,35
Management Console to System
Unit
8841 Mouse - Business Black with 1 87,35
Keyboard Attachment Cable
Spanish
========= ======
7310-CR3 Price 5.338,00

********************************* SOFTWARE *********************************


5773-RS3 Initial Software Support 3 Year 1 N/C
7000 Agreement for MCRSA 1 N/C
Z0MFKG Per Processor Software Support 1 723,04
3 Year
=========
5773-RS3 OTC 723,04

******************************* GRAND TOTALS *******************************

Pgina 80 de 142

Software OTC 723,04
==========

N/O - Not Offered
N/C - No Charge
W/D - WITHDRAWN



System port (serial)(1)
Integrated 10/100/1000 Mbps Ethernet Port (2)
Integrated USB Ports (3)
Integrated Graphics Port
1 GB system memory
80 GB Serial ATA HDD
DVD-RAM for backup
HMC 2

********************************* HARDWARE *********************************


7310-CR3 HMC 2:7310-CR3 Rack-mounted 1 4.116,00 51,77
Hardw.Mgmt.Console
0961 Hardware Management Console for 1 N/C
POWER5 Licensed Machine Code
3645 T117 TFT 17-inch Color Display 1 810,16
4242 6 Foot Extender Cable for 1 134,45
Displays (15 pin D-shell to 15
pin D-shell)
Pgina 81 de 142

Integrated
5956 Full Width Quiet Touch Keyboard 1 131,97
-- USB, Spanish, #172
6458 Power Cord (14ft) 250V/14A, 1 20,48
IEC320/C13, IEC320/C14
6472 Power Cord (9-foot), To 1 20,24
Wall/OEM PDU, (250V, 16A),
Plug Type #18
7801 Ethernet Cable, 6M, Hardware 1 17,35
Management Console to System
Unit
8841 Mouse - Business Black with 1 87,35
Keyboard Attachment Cable
Spanish
========= ======
7310-CR3 Price 5.338,00

********************************* SOFTWARE *********************************


5773-RS3 Initial Software Support 3 Year 1 N/C
7000 Agreement for MCRSA 1 N/C
Z0MFKG Per Processor Software Support 1 723,04
3 Year
=========
5773-RS3 OTC 723,04

******************************* GRAND TOTALS *******************************

Pgina 82 de 142

Software OTC 723,04
==========

N/O - Not Offered
N/C - No Charge
W/D - WITHDRAWN



System port (serial)(1)
Integrated 10/100/1000 Mbps Ethernet Port (2)
Integrated USB Ports (3)
Integrated Graphics Port
1 GB system memory
80 GB Serial ATA HDD
DVD-RAM for backup

****************************** SYSTEM SUMMARY ******************************

Server 1
==========

Server 2
Pgina 83 de 142

==========

Server 3
==========

Server 4
==========

HMC 1
Software OTC 723,04
==========

HMC 2
Software OTC 723,04
==========

Pgina 84 de 142

****************************** OVERALL ORDER ******************************

==========

Dentro de este presupuesto no se han incluido las dos pantallas TFT, con teclado
y touchpad incluidos, que se van a utilizar. Este es as porque las pantallas no son un
requerimiento del cliente, sino un aadido a la solucin para optimizar el enracado de
las mquinas. Por esta razn se ha decidido entregarlas sin coste al cliente y asumir
dicho coste.

VII.2. Valoracin Econmica servicios
Esta propuesta incluye los siguientes servicios:
- instalacin fsica de los servidores
- cableado e interconexin
- creacin e instalacin de particiones
- instalacin y configuracin de HACMP
- integracin de los scripts de arranque y parada de las aplicaciones
- pruebas de rendimiento y de funcionamiento de HACMP
Los servicios de instalacin de las aplicaciones y migracin de los datos no estn
contemplados dentro del alcance de esta propuesta.

Para la ejecucin de esta propuesta se estiman los siguientes recursos:
- un tcnico de sistemas con experiencia en LPAR y HACMP
- una duracin de 70 jornadas-persona

Estos servicios suponen un total de 28.000 .

Nota: dentro de esta valoracin econmica, solo estn incluidos los servicios de
implantacin de la solucin, a un precio de 400 por jornada-persona. Las actividades
de anlisis de requisitos, estudio de soluciones y el diseo de la solucin se realizan de
manera previa a la aceptacin por parte del cliente de la oferta, por lo que no estn
Pgina 85 de 142

incluidas en esta valoracin. Estas actividades suponen 22 jornadas-persona, que si se
cobrasen al mismo precio que la implantacin supondran un total de 8.800 , por lo que
el total de los servicios ascendera a 36.800 .

VII.3. Valoracin Econmica Total
Sumando los presupuestos de HW/SW y el de los servicios, este proyecto tiene
un costo total para el cliente de 750.241,28 , a lo que hay que sumar 4.752,3 de
mantenimiento mensual de las mquinas y los gastos del hospedaje y del consumo de
las mquinas.

Pgina 86 de 142

VIII. Implantacin de la solucin

VIII.1. Enracado de los servidores
La primera tarea a realizar es definir cual va a ser la ubicacin de los servidores
dentro de los racks, y para ello hay que ver el tamao de cada elemento de la
configuracin HW:
- Servidores
o Cada servidor consta de 2 bloques de 4Us, lo que hace 8 Us por
servidor y un total de 32 Us
- Consolas HMC
o Cada consola ocupa una U, lo que hace un total de 2 Us
- Unidades de media
o Cada unidad de media ocupa una U, lo que hace un total de 4 Us
- Pantallas TFT
o Cada pantalla ocupa una U, lo que hace 2 Us adicionales

En total esta configuracin hardware ocupa 40 Us. Los armarios utilizados son
racks de 36 Us de alto, por lo que no cabe todo el hardware en un solo armario y
quedar bastante espacio desocupado.
Puesto que hay desperdiciar algo de espacio en los armarios se va a enracar de
manera a facilitar las futuras ampliaciones posibles. La mxima ampliacin que puede
realizarse sobre cada servidor sera aadir 2 bloques de 4Us adicionales, lo que hara un
total de 32 Us. Con esta ampliacin la ocupacin total sera de 72 Us, lo que cabe justo
en dos armarios. Hay que enracar por tanto los servidores en 2 armarios de manera a
facilitar estas posibles ampliaciones.

Pgina 87 de 142

Esta es la situacin actual:

Enracado inicial de los servidores

El enracado se va a realizar colocando cada servidor de manera que tenga
espacio contiguo para las ampliaciones. El enracado realizado por lo tanto en cada
armario es:
- servidor (2 bloques 8 Us)
- espacio para ampliacin (8 Us)
- unidad de media (1 U)
- unidad de media (1 U)
- consola HMC (1 U)
- servidor (2 bloques 8 Us)
- espacio para ampliacin (8 Us)
Pgina 88 de 142

Enracado final de los servidores

VIII.2. Interconexin HMC Sistemas gestionados
Los procesadores de servicio de los servidores pSeries disponen de dos puertos
de gestin para conectarse con las consolas HMC.
Las consolas HMC disponen de dos puertos de red: uno para la conexin con los
procesadores de servicio (formando una red denominada privada) y el otro puerto para
la gestin externa de la HMC.
Pgina 89 de 142

La red privada de cada HMC debe estar completamente aislada de cualquier otra
subred; de hecho, cuando la consola HMC se conecta a un nico servidor se usa cable
directo sin ningn elemento de red.
En este caso, como cada HMC tiene que conectarse a cuatro servidores pSeries a
travs de un nico puerto, la nica forma de hacerlo es mediante el uso de algn
elemento de red. Para mantener esta red completamente aislada del resto se conectarn a
travs de switches de red creando para cada HMC una VLAN privada y aislada.

Vista lgica de la interconexin HMC Sistemas gestionados

VIII.3. Creacin de particiones
A la hora de crear las particiones LPAR hay que indicar las cantidades de
memoria y CPU, as como los recursos fsicos que hay que asignar.

En este caso se van a crear las siguientes particiones:
Servidor 1:
LPAR1.1
Memoria:
Mnima: 1,0 GB
Deseada: 1,0 GB
Mxima: 16,0 GB

Srv 1 Srv 2 Srv 4 Srv 3
HMC 2
HMC 1
VLAN 2
VLAN 1
Red
interna
Pgina 90 de 142

CPU:
Mnima: 1,0
Deseada: 1,0
Mxima: 4,0
Discos (necesario):
Cajn 1 Controladora T12 (3 bahas, 2 discos)
Ethernet (necesario):
Cajn 1 Controladora T6 (Integrada, 2 puertos)
Cajn 1 Tarjeta C01 (Ethernet 4 puertos)
Fibra (necesario):
Cajn 1 Tarjeta C02 (HBA 1 puerto)
CD/Cinta (deseado):
Cajn 1 Tarjeta C06 (SCSI 2 puertos)
LPAR1.2
Memoria:
Mnima: 1,0 GB
Deseada: 1,0 GB
Mxima: 16,0 GB
CPU:
Mnima: 0,5
Deseada: 0,5
Mxima: 4,0
Discos (necesario):
Fibra (necesario):

Pgina 91 de 142

X25 (necesario):
Cajn 1 Tarjeta C05 (X25 1 puerto)
CD/Cinta (deseado):
LPAR1.3
Memoria:
Mnima: 1,0 GB
Deseada: 3,0 GB
Mxima: 3,0 GB
CPU:
Mnima: 0,5
Deseada: 0,75
Mxima: 0,75
Discos (necesario):
CD/Cinta (deseado):
LPAR1.4
Memoria:
Mnima: 1,0 GB
Deseada: 3,0 GB
Mxima: 3,0 GB
CPU:
Mnima: 0,5
Deseada: 0,75
Mxima: 0,75
Discos (necesario):
Pgina 92 de 142

CD/Cinta (deseado):

Servidor 2:
LPAR2.1
Memoria:
Mnima: 1,0 GB
Deseada: 1,0 GB
Mxima: 16,0 GB
CPU:
Mnima: 1,0
Deseada: 1,0
Mxima: 4,0
Discos (necesario):
Fibra (necesario):
CD/Cinta (deseado):
LPAR2.2
Memoria:
Mnima: 1,0 GB
Deseada: 1,0 GB
Mxima: 16,0 GB
CPU:
Mnima: 0,3
Deseada: 0,3
Mxima: 4,0

Pgina 93 de 142

Discos (necesario):
Fibra (necesario):
X25 (necesario):
CD/Cinta (deseado):
LPAR2.3
Memoria:
Mnima: 1,0 GB
Deseada: 3,0 GB
Mxima: 3,0 GB
CPU:
Mnima: 0,5
Deseada: 0,75
Mxima: 0,75
Discos (necesario):
CD/Cinta (deseado):
LPAR2.4
Memoria:
Mnima: 1,0 GB
Deseada: 3,0 GB
Mxima: 3,0 GB
Pgina 94 de 142

CPU:
Mnima: 0,5
Deseada: 0,75
Mxima: 0,75
Discos (necesario):
CD/Cinta (deseado):

Servidor 3:
LPAR3.1
Memoria:
Mnima: 4,0 GB
Deseada: 4,0 GB
Mxima: 16,0 GB
CPU:
Mnima: 1,0
Deseada: 1,0
Mxima: 4,0
Discos (necesario):
Fibra (necesario):
CD/Cinta (deseado):

Pgina 95 de 142

LPAR3.2
Memoria:
Mnima: 4,0 GB
Deseada: 4,0 GB
Mxima: 16,0 GB
CPU:
Mnima: 1,0
Deseada: 1,0
Mxima: 4,0
Discos (necesario):
Fibra (necesario):
CD/Cinta (deseado):
LPAR3.3
Memoria:
Mnima: 0,5 GB
Deseada: 1,0 GB
Mxima: 1,0 GB
CPU:
Mnima: 0,5
Deseada: 0,75
Mxima: 0,75
Discos (necesario):
Pgina 96 de 142

CD/Cinta (deseado):
LPAR3.4
Memoria:
Mnima: 2,0 GB
Deseada: 6,0 GB
Mxima: 6,0 GB
CPU:
Mnima: 0,5
Deseada: 0,6
Mxima: 0,6
Discos (necesario):
CD/Cinta (deseado):

Servidor 4:
LPAR4.1
Memoria:
Mnima: 4,0 GB
Deseada: 4,0 GB
Mxima: 16,0 GB
CPU:
Mnima: 1,0
Deseada: 1,0
Mxima: 4,0
Discos (necesario):
Pgina 97 de 142

Fibra (necesario):
CD/Cinta (deseado):
LPAR4.2
Memoria:
Mnima: 4,0 GB
Deseada: 4,0 GB
Mxima: 16,0 GB
CPU:
Mnima: 1,0
Deseada: 1,0
Mxima: 4,0
Discos (necesario):
Fibra (necesario):
CD/Cinta (deseado):
LPAR4.3
Memoria:
Mnima: 2,0 GB
Deseada: 4,0 GB
Mxima: 4,0 GB
CPU:
Mnima: 0,5
Deseada: 0,8
Mxima: 0,8
Pgina 98 de 142

Discos (necesario):
CD/Cinta (deseado):
LPAR4.4
Memoria:
Mnima: 0,5 GB
Deseada: 1,0 GB
Mxima: 1,0 GB
CPU:
Mnima: 0,5
Deseada: 0,8
Mxima: 0,8
Discos (necesario):
CD/Cinta (deseado):

VIII.4. Instalacin del sistema operativo
A la hora de instalar el sistema operativo existen varias posibilidades, como los
discos a utilizar para la instalacin, el sistema de ficheros o la aplicacin de mecanismos
adicionales de seguridad. En este caso todas las instalaciones van a seguir el siguiente
patrn:
Tipo de instalacin: New and Complete Overwrite. Instalacin nueva, que incluye el
formateo de los datos que pudiese haber en los discos.
Discos para la instalacin: hdisk0. Todas las particiones cuentan con dos discos internos
(hdisk0 y hdisk1), y si se seleccionasen ambos la instalacin se repartira entre los dos,
lo que dificulta posteriormente realizar el mirror entre ambos.
Pgina 99 de 142

Trusted Computing Base: No. Se trata de un mecanismo de seguridad de acceso a los
ficheros y de control de los permisos de los ficheros. Este mecanismo impide ciertos
procesos de HACMP.
Kernel 64 bits: Si. Aunque los procesadores sean de 64 bits existe la posibilidad de
instalar el sistema operativo en modo de 32 bits ya que hay ciertas aplicaciones que no
se ejecutan correctamente en modo 64 bits. En este caso, como no hay ninguna
aplicacin que lo impide, se usar el modo 64 bits nativo que ofrece mejor rendimiento.
Sistemas de ficheros: JFS2 (Enhanced Journaled File System). El sistema de ficheros
JFS2 ofrecen mejoras respecto a los anteriores sistemas JFS, por lo que si no existen
impedimentos por parte de las aplicaciones es recomendable usarlo.

VIII.5. Configuracin HACMP
Una vez instalado el sistema operativo y el software de HACMP, hay que
configurar el cluster y los nodos. En este apartado se indican de forma resumida los
pasos necesarios, detallando un poco ms los pasos ms importantes y delicados y las
tareas menos usuales que sean especficas de la configuracin de este proyecto.

Configuracin LVM
Crear VG en almacenamiento compartido:
En ambos nodos de un cluster:
- identificar los discos externos (nombre y PVID)
- si no coinciden los nombres o los PVIDs eliminar los discos externos y
configurarlos a mano para que sigan la misma nomenclatura
- identificar dos major numbers comunes disponibles en ambos nodos
En un solo nodo del cluster:
- crear con los discos externos dos VGs (uno para cada aplicacin) en modo
concurrente
o utilizando los major numbers seleccionados
o que no se activen automticamente al arrancar
- crear los filesystems necesarios para las aplicaciones en esos VGs
o que no se monten automticamente al arrancar

Pgina 100 de 142

- desmontar los filesystems creados
- desactivar los VGs
- exportar los VGs
En el otro nodo del cluster:
- importar los VGs
- montar los filesystems y comprobar que todo est correcto

Configuracin de red
Red IP:
Definir las direcciones IP a utilizar. Cada nodo necesita 4 direcciones IP, cada una en
una subred distinta pero todas con la misma mscara:
- una IP para adaptador 1
- una IP para adaptador 2
- una IP persistente para el nodo
o activa en todo momento en alguno de los adaptadores
o si la aplicacin se pasa al otro nodo esta IP no se pasa al otro nodo
- una IP para la aplicacin
o activa en alguno de los dos adaptadores cuando la aplicacin est en
el nodo
o si la aplicacin se pasa al otro nodo esta IP se pasa tambin

Con todas las direcciones del cluster (las 4 de cada nodo) crear en ambos nodos un
fichero /etc/hosts. Ambos ficheros deben ser idnticos.

Red no-IP:
Mediante los mens de HACMP crear una red no-IP sobre discos compartidos,
comprobando que se utiliza el mismo disco hdiskX en ambos nodos.
Comprobar la comunicacin entre ambos nodos a travs de la red no-IP:
- en un nodo:
o /usr/sbin/rsct/dhb_read p /dev/hdiskX r (receive, se pone a la
escucha)

Pgina 101 de 142

- en el otro nodo:
o /usr/sbin/rsct/dhb_read p /dev/hdiskX t (transmit, enva datos a
travs del disco)
- en ambos nodos debera aparecer Link operating normally

Configuracin Cluster
Una vez que se han definido los volmenes y filesystems y las redes a utilizar,
hay que configurar el cluster, los nodos, los recursos y las polticas de fallover y
fallback. Toda esta configuracin se realiza desde un solo mediante los mens de
HACMP, y luego HACMP sincroniza la configuracin con el nodo.

Creacin del cluster:
En el momento de la creacin del cluster, se indica tambin a HACMP los nodos
que conforman el cluster. Para esto HACMP lee el fichero /etc/hosts y muestra las
direcciones IP definidas, por eso es tan importante que los ficheros coincidan siempre
en ambos nodos. Una vez definidos los nodos se asignan las direcciones IP persistentes
de cada nodo.

Asignacin de recursos a los nodos:
Desde el punto de vista de HACMP, una aplicacin consiste en una serie de
recursos que son: direccin IP, almacenamiento y filesystems y scripts de arranque y
parada de las aplicaciones. Lo primero es definir los recursos, y luego agruparlos en un
grupo de recursos RG (Resource Group). En este punto todava no estn definidos los
scripts de arranque y parada, por lo que se quedan sin definir y se incluirn en el RG
ms adelante. Hay que crear un RG por cada aplicacin, y asociar cada RG a un nodo
principal. Los recursos que se asignan a cada RG son las direcciones IP de servicio de
las aplicaciones y los VGs compartidos, indicando los filesystems que debe usar.
En esta configuracin, hay adems un cluster que necesita definir dos recursos
adicionales. Estos recursos son dos direcciones MAC virtuales que se asociarn con las
IPs de servicio de las aplicaciones. Al levantar cada direccin de servicio en el nodo que
tenga la aplicacin activa, HACMP sustituir la direccin MAC real de la tarjeta por la
direccin virtual que se ha asociado a dicha IP de servicio. Este movimiento de la
direccin MAC se denomina HWAT (HW Address Takeover). La necesidad de estas
Pgina 102 de 142

dos direcciones MAC virtuales es debida a que las aplicaciones se tienen que conectar
con una aplicacin obsoleta que identifica los clientes por MAC, en vez de por IP.
El problema a la hora de crear una direccin MAC virtual es que cada direccin
MAC debe ser nica, por lo que no se puede definir una MAC virtual sin seguir algn
mtodo que asegure que dicha MAC es nica. Lo que se hace es tomar la direccin
MAC real de una de las tarjetas del nodo, que en teora es nica, y modificarla de
manera que siga siendo nica, con el siguiente procedimiento:
- seleccionar una MAC real
o esta MAC tiene el formato ZX:XX:XX:XX:XX:XX
o en las MAC reales, el primer dgito Z es siempre 0, 1, 2 o 3 y lo
asigna a cada fabricante una autoridad central
- incrementar el primer dgito Z en 4
o esta MAC empezara por 4, 5, 6 o 7, lo que no coincide con ninguna
MAC real
Si nadie ha usado la misma direccin MAC para crear una direccin una
direccin virtual este mtodo asegura que la MAC virtual definida es nica, al igual que
una MAC real.

Polticas de HACMP:
Las polticas de HACMP definen el comportamiento a seguir ante el fallo de uno
de los nodos. En el caso de fallos leves de algn componente que pueda recuperarse
dentro del mismo servidor, el comportamiento viene predefinido y lo marca el software
de HACMP, no se puede configurar mediante las polticas de HACMP
1
.

Las polticas definidas en todos los clusters han sido las siguientes:
Startup: la poltica de startup define los nodos en los que se podr arrancar la
aplicacin. Las diferentes opciones son:
- solo en el nodo principal
- en el primer nodo disponible
- utilizando una poltica de distribucin
- en todos los nodos a la vez

1
Se puede modificar el comportamiento ante estos eventos personalizando los scripts propios de
HACMP. En los casos de HWAT ha sido necesario modificar estos scripts para obtener un
funcionamiento correcto.
Pgina 103 de 142

En este caso se ha seleccionado la opcin de solo pueda arrancar en el nodo principal.

Fallover: la poltica de fallover define el nodo al que se pasa la aplicacin en caso de
fallo del nodo en el que est activa. Las diferentes opciones son:
- al siguiente nodo en la lista de prioridad
- utilizando prioridades dinmicas
- dejar offline en el nodo en error
Estas polticas estn diseadas para poder funcionar con cualquier nmero de nodos. En
este caso solo hay clusters de dos nodos, por lo que se ha seleccionado la primera
opcin, fallover al siguiente nodo.

Fallback: la poltica de fallback define el comportamiento cuando un nodo vuelve a
estar activo despus de haber realizado fallover de una aplicacin, cuando este nodo es
el nodo principal o tiene mayor prioridad que el nodo que tiene la aplicacin. Las
diferentes opciones son:
- realizar fallback al nodo de mayor prioridad en la lista
- no realizar fallback automticamente
En este caso se ha seleccionado no realizar fallback de manera automtica. Si un nodo
se ha cado, es mejor no realizar fallback hasta asegurarse de que el fallo se ha
solucionado y repasar los distintos logs de errores, tanto del sistema operativo como de
HACMP y de la aplicacin.

Una vez configurados los clusters, los recursos y las polticas ya se pueden
realizar una serie de pruebas bsicas para comprobar el funcionamiento de HACMP y
confirmar que la configuracin es correcta. Estas pruebas consisten en simular el fallo
de los distintos componentes y se realizan de manera consecutiva en todos los nodos.
Estos simulacros de fallos consisten por ejemplo en desconectar los cables de red y los
cables de fibra o apagar de forma brusca las particiones.
Estas primeras pruebas han demostrado que todo el funcionamiento es correcto
excepto en los nodos en los que se aplica HWAT y hay que mover las direcciones MAC
virtuales. Despus de realizar ms pruebas, esta vez ms exhaustivas, y de abrir
incidencias con IBM, se ha aislado el problema a nivel de los switches de la red.
Pgina 104 de 142

El problema estriba en los tiempos de refresco de las tablas de rutas, que son
demasiado elevados. Este tiempo es superior al mximo permitido por HACMP, por lo
que se dispara un timeout y se intenta mover la direccin MAC a otra tarjeta o a otro
nodo. La solucin ms adecuada pasa por configurar los switches de la red y reducir los
tiempos de refresco.
Sin embargo en este caso no se ha tenido acceso a la configuracin de los
elemento de red, que dependen del proveedor de housing, por lo que ha habido que
buscar una solucin alternativa. Esta solucin ha consistido en modificar los scripts
propios de HACMP de forma que el tiempo marcado para el timeout se ha incrementado
hasta 60 segundos. Con estas modificaciones se provoca que en algunos casos se tarde
ms en detectar un fallo real, pero se asegura que el movimiento de la direccin MAC
se completa y se pueda hacer fallover de la aplicacin.

Integracin de las aplicaciones
La instalacin de las aplicaciones no entra dentro del alcance de este proyecto,
por lo que es responsabilidad del cliente. Sin embargo si que se ha participado dando
unas recomendaciones para realizar las instalaciones. Estas recomendaciones tienen
como objetivo facilitar en un futuro las tareas de aplicacin de parches y de
actualizacin de versiones.
Se ha recomendado instalar tanto los fuentes de las aplicaciones como los
archivos de configuracin de las mismas en el almacenamiento interno, y dejar el
almacenamiento externo para los datos que manejan las aplicaciones. De esta manera se
podr mantener la aplicacin activa en un nodo mientras en el otro nodo se realizan
tareas que en condiciones implican la parada de la aplicacin, como puede ser una
actualizacin de versin. Una vez realizada la tarea se puede mover la aplicacin de
nodo y realizar la misma tarea en el otro nodo, sin interrupcin del servicio.

Una vez instaladas las aplicaciones, la integracin de las mismas se realiza
creando o modificando los scripts de arranque y parada de las aplicaciones. En la
mayora de los casos estos scripts ya existen, pero es necesario modificarlos para que
tengan en cuenta el funcionamiento de HACMP.
Antes de arrancar la aplicacin, es necesario por ejemplo comprobar que los
filesystems necesarios han sido montados correctamente, o que la direccin IP de
Pgina 105 de 142

servicio est levantada en alguno de los adaptadores de red de la particin. En el caso de
las aplicaciones que utilizan X25 hay que crear un script que monte la pila del
protocolo, ya que HACMP no tiene scripts predefinidos que realicen esta tarea. Una vez
realizadas todas las operaciones ya se puede proceder al arranque normal de las
aplicaciones.
En el caso de los scripts de parada, los scripts de HACMP pueden encargarse de
liberar los recursos compartidos, pero es conveniente comprobar en el script que todos
los recursos han dejado de utilizarse. En el caso de las aplicaciones que utilizan X25 el
script de parada debe tambin desmontar la pila del protocolo.
Desde el punto de vista de HACMP una aplicacin no es ms que un script de
arranque y un script de parada, por lo que una vez creados estos scripts ya se pueden
aadir las aplicaciones a los RGs ya creados. Una vez aadidas las aplicaciones se
pueden crear scripts personalizados que monitoricen las aplicaciones.
Estos scripts comprueban el estado de los procesos al igual que HACMP
comprueba el estado del resto de los componentes, para poder recuperar tambin un
fallo provocado por la parada de las aplicaciones. Estos scripts comprueban que los
procesos de las aplicaciones estn activos y en los casos de las bases de datos realizan
conexiones a las mismas para comprobar que estn activas. En caso de detectar que los
procesos estn cados o que las bases de datos no responden se iniciar el proceso de
fallover.

Realizacin de pruebas
Una vez instaladas las aplicaciones e integradas dentro de HACMP, las primeras
pruebas a realizar son las de arranque y parada de las aplicaciones desde el entorno de
HACMP. Con estas pruebas se confirma que los scripts de arranque y parada son
correctos.
Si las pruebas anteriores son positivas, la siguiente tanda de pruebas a realizar
consiste en volver a simular los fallos de los nodos y de los distintos componentes,
incluyendo esta vez las aplicaciones. Para simular el fallo de la aplicacin y probar los
scripts de monitorizacin se cancelan de manera manual los distintos procesos que son
necesarios para cada aplicacin. De esta manera se comprueba que HACMP es capaz de
recuperar las aplicaciones, y que los scripts de monitorizacin personalizados funcionan
correctamente.
Pgina 106 de 142

Una vez completadas las pruebas de HACMP con las aplicaciones corriendo, las
siguientes pruebas a realizar son pruebas de rendimiento. Estas pruebas consisten en
someter a las aplicaciones a cargas de trabajo muy elevadas y monitorizar el estado de
los servidores y los tiempos de respuesta.
Para la mayora de las aplicaciones comerciales existen aplicaciones sencillas
que simulan cargas elevadas, como por ejemplo realizar conexiones y consultas masivas
a las bases de datos, o realizar cargas o borrados en cascada de datos. Simultneamente
a la realizacin de estas pruebas se someten las aplicaciones a una carga normal de
trabajo, incluyendo los procesos batch, y se monitorizan los tiempos de respuesta y las
posibles desconexiones o incidencias. En este caso estas pruebas han demostrado que el
rendimiento de los nuevos sistemas es superior al de los antiguos servidores.
De forma complementaria a estas pruebas, se realizan otras pruebas de
rendimiento, simulando esta vez fallos de los nodos. Esto se hace para que HACMP
haga fallover de las aplicaciones y se pueda medir el rendimiento de los servidores en
condiciones extremas. En este caso se ha observado una bajada del rendimiento y una
ralentizacin de las transacciones, pero incluso en este caso el rendimiento sigue siendo
superior al de los antiguos servidores como norma general.
Durante la realizacin de estas pruebas se ha observado que cuando los
servidores estn sobrecargados los scripts de monitorizacin pueden dar falsos
positivos e iniciar el proceso de fallover sin una razn verdadera. Esto es debido a que
las conexiones que realizan a las bases de datos pueden dar un timeout debido a la
sobrecarga del sistema. Ha habido por lo tanto que modificar los scripts de
monitorizacin, e incluir un contador de intentos fallidos. De esta manera una sola
conexin fallida no se considera un fallo de la aplicacin, sino que se espera al tercer
intento fallido antes de declarar la aplicacin cada e iniciar el fallover al otro nodo.

Cuando se han concluido todas estas pruebas con resultados satisfactorios y se
ha obtenido la aceptacin del cliente se da por terminada la configuracin de HACMP.
Esto no concluye sin embargo el proceso de implantacin, ya que quedan una serie de
elementos adicionales a configurar
Pgina 107 de 142

IX. Configuracin adicional
Una vez terminada la instalacin y configuracin de HACMP y de las
aplicaciones es conveniente realizar una serie de configuraciones adicionales. Estas
configuraciones tienen como objetivo primordial aumentar la seguridad de los sistemas
y facilitar la administracin de los mismos.

IX.1. Auditoria de eventos
Como ya se ha dicho, los procesos de HACMP no resultan compatibles con
implantaciones del sistema operativo demasiado seguras. Un ejemplo es la necesidad de
ficheros rhosts, que permiten la ejecucin de comandos en sistemas remotos sin que
pida usuario y contrasea.
Si embargo la seguridad es un requisito imprescindible en entornos de
produccin, por lo que resulta necesario implantar algn mecanismo adicional, ya sea de
seguridad de acceso o de registro de eventos de seguridad, para mantener la integridad
del sistema, las aplicaciones y los datos.

El sistema operativo AIX ofrece un proceso de auditoria que permite registrar
eventos que ocurren dentro del sistema. La naturaleza de estos eventos es muy amplia y
se puede personalizar. En el caso de este proyecto, los eventos que ms interesa registrar
son los eventos de login y de administration. Los eventos de login se refieren a los
inicios de sesin y a los cambios de usuario mediante el comando su, y los eventos de
administration se refieren a las lecturas y las modificaciones de ficheros de
configuracin de sistema y de las distintas opciones de configuracin del sistema. El
proceso de auditoria registra tanto los intentos vlidos como los fallidos, la fecha y hora,
el usuario y el terminal o la IP desde el que se ha efectuado.

Debido a la naturaleza y al propsito de estos logs de auditoria, no es
conveniente mantener los archivos dentro del sistema. En este caso se ha decidido
externalizar los logs a intervalos predefinidos a un sistema ms seguro, en el cual se
analizarn de manera automtica en busca de patrones que identifiquen operaciones no
permitidas. De manera adicional estos logs se archivarn a un sistema de
Pgina 108 de 142

almacenamiento y backup en cintas, durante la duracin establecida por las polticas de
seguridad de la empresa.

Auditoria Registro de eventos de seguridad

IX.2. Movimiento de recursos
En esta configuracin, cada uno de los servidores fsicos consta de un nico
lector de CD/DVD y de una nica unidad de cinta, lo que implica que habr que mover
estos recursos entre las distintas particiones cuando se necesite.
Para mover los recursos, hay que desconfigurar y eliminar los dispositivos desde
el sistema operativo de la particin que los tiene asignados, moverlos mediante la
consola HMC y detectarlos y configurarlos en la particin de destino. Esto puede
implicar un problema de seguridad, ya que hay que otorgar los permisos necesarios a los
usuarios que necesiten realizar estas operaciones. En este caso concreto es necesario que
los operadores puedan realizar estas operaciones para realizar las copias de seguridad de
los sistemas operativos a cinta.
En el caso de las consolas HMC, los permisos de los usuarios se definen
mediante la creacin de roles. Los roles otorgan permisos sobre ciertas operaciones y
los usuarios se asocian con estos roles. En este caso se ha creado un rol que solo permite
el movimiento de recursos fsicos entre las particiones, por lo que los usuarios que lo
necesiten se les asociar con este rol.
audit
login
su
log
/etc/passwd
log
analizer
Cintas
Pgina 109 de 142

En el caso de las particiones, para desconfigurar, eliminar, detectar y configurar
los recursos desde el sistema operativo se necesita tener permisos de root o pertenecer al
grupo system lo que supone un grave problema de seguridad, ya que los usuarios
corrientes no deben tener estos permisos, y menos an los operadores de copia. Para
solucionar este problema se ha creado un usuario genrico y un men de movimiento de
recursos.
Se ha creado un usuario genrico, y se le han modificado los valores de UID
(User ID) y GID (Group ID) para que coincidan con los del usuario root (UID = 0) y el
grupo system (GID = 0). A este usuario se le han modificado tambin las caractersticas
para que no pueda iniciar sesin, y solo se pueda acceder a l mediante el comando su.
De esta manera queda constancia en el log de su de quien ha accedido a este usuario
genrico. De manera adicional, se ha modificado este usuario para que al acceder no
tenga acceso a la shell (lo que le permitira ejecutar comandos) y que en su lugar se
ejecute directamente el men creado. De esta manera este usuario genrico tiene
permisos para realizar las operaciones necesarias, pero no puede realizar ninguna otra
operacin fuera de stas.
El men creado para el movimiento de recursos consta de 3 mdulos (2 scripts y
un fichero de configuracin). El primer script lee las opciones permitidas y los
comandos a ejecutar del fichero de configuracin, y se encarga de mostrar al usuario las
distintas opciones. El segundo script tiene que estar incluido entre las opciones
indicadas en el fichero de configuracin y se encarga de realizar las operaciones
necesarias hasta eliminar el dispositivo seleccionado. De manera adicional el primer
script refleja en un archivo de log todas las operaciones realizadas. De esta manera
todos las operaciones de movimiento de recursos entre particiones quedan reflejadas en
los logs de auditoria y del men.

Pgina 110 de 142

Movimiento de recursos Ejemplo de movimiento de cd

IX.3. Sincronizacin horaria
El movimiento de las aplicaciones entre los distintos nodos de un cluster puede
provocar inconsistencias en los datos si los nodos no tienen sincronizada la hora, ya que
HACMP no incluye un mecanismo de ajuste horario. Es necesario por lo tanto utilizar
algn mecanismo de sincronizacin horaria.
Existe un protocolo llamado NTP (Network Time Protocol) que permite
sincronizar la hora de todos los servidores con un servidor NTP central. El cliente
dispone de varios servidores NTP (un servidor principal y dos de contingencia), a los
que se puede conectar el resto de los servidores para ajustar la hora. Estos servidores
NTP se sincronizan a su vez con un servidor NTP pblico disponible a travs de
Internet.
Los pasos a seguir para activar la sincronizacin horaria en cada particin son
los siguientes:
- aadir en el fichero de configuracin de NTP las entradas correspondientes
al servidor principal y los de backup
- sincronizar la hora de manera manual por comando con uno de los
servidores NTP
- arrancar el proceso cliente NTP en la particin
- programar el arranque del proceso cliente en los reinicios de la particin

Men
Eliminar cd
su
login
audit
log log
Men
Configurar cd
su
login
audit
log log
Particin Particin
HM
login
Mover cd
Fase 1
Fase 2
Fase 3
Pgina 111 de 142

X. Conclusiones
Una vez realizadas las pruebas de manera satisfactoria, el proyecto se considera
terminado con la entrega de la documentacin al cliente. Esta documentacin muestra el
estado final de los servidores, las particiones y las consolas, as como la configuracin
de los clusters de HACMP, los nodos y las polticas. Tambin incluye un manual de
administracin bsica del particionamiento LPAR y otro de administracin bsica de
HACMP.
Adems la documentacin incluye datos que demuestran los objetivos que se
han alcanzado, y una serie de propuestas, para su evaluacin como futuros proyectos de
ampliacin y mejora.

X.1. Objetivos alcanzados
A continuacin se muestran una serie de datos que confirman que se han
alcanzado los objetivos planteados inicialmente:

Aumento del rendimiento
Una vez implantada la solucin, durante el periodo de realizacin de pruebas de
rendimiento, se han tomado datos de rendimiento. Estos datos son de los mismos
parmetros que se usaron durante el anlisis de requisitos y su comparacin permite
demostrar el aumento de rendimiento experimentado. Aqu se muestran los datos para
un servidor, pero los incrementos observados son parecidos en todos los casos. Para la
toma de datos en los servidores nuevos se han realizado pruebas de stress al mismo
tiempo que se realizaban las operaciones normales, procesos batch incluidos, mientras
que durante la toma de datos de los servidores antiguos solo se estaban ejecutando las
operaciones normales y los procesos batch.

Memoria y espacio de paginacin:
Servidor antiguo:
Ocupacin media de la memoria: 89,36 %
Ocupacin media de la paginacin: 92,33 %

Pgina 112 de 142

Servidor nuevo:
Ocupacin media de la memoria: 11,36 %
Ocupacin media de la paginacin: 23,18 %

En las siguientes grficas se puede observar la evolucin temporal de la
ocupacin de memoria y paginacin.
0
10
20
30
40
50
60
70
80
90
100
Servidor antiguo - Datos de ocupacin de memoria y paginacin

0
10
20
30
40
50
60
70
80
90
100
Memoria
Paginacin
Servidor nuevo - Datos de ocupacin de memoria y paginacin

Como se puede observar, en el servidor antiguo la ocupacin del espacio de
paginacin rondaba el 100 %, lo que provocada la parada de algunos procesos y
aplicaciones.
Pgina 113 de 142

En el caso del servidor nuevo la ocupacin de la memoria y de la paginacin es
mucho menor, ya no se experimentan las paradas de los procesos y sigue habiendo
margen para un aumento de la carga de trabajo.

Uso de CPU:
Servidor antiguo:
Ocupacin media de CPU:
Usr: 49,90 %
Sys: 30,86 %
Wio: 5,95 %
Idle: 13,3 %

Servidor nuevo:
Ocupacin media de CPU:
Usr: 25,20 %
Sys: 2,22 %
Wio: 0,35 %
Idle: 72,2 %

En las siguientes grficas se puede observar la evolucin temporal de la
ocupacin de CPU.
0
10
20
30
40
50
60
70
80
90
1 3 5 7 9 11 13 15 17 19 21
%usr
%sys
%wio
%idle

Servidor antiguo Datos de uso de CPU

Pgina 114 de 142

0
10
20
30
40
50
60
70
80
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
%usr
%sys
%wio
%idle

Servidor nuevo Datos de uso de CPU

La mejora observada en cuanto al uso de la CPU est provocada por la mejora de
la tecnologa de los procesadores, pero tambin est influenciada por la mejora en el
consumo de memoria y espacio de paginacin. El menor consumo de la paginacin
disminuye las operaciones de entrada-salida, lo que disminuye el porcentaje de wio del
procesador. Esta disminucin tambin hace que disminuyan las intervenciones del
sistema para cambios de contexto, lo que reduce el porcentaje de sys del procesador.

Asegurar capacidad de proceso
Como ya se ha visto, la ocupacin de la CPU y la memoria se ha reducido
considerablemente, lo que deja margen para aumentos de la carga de trabajo. Adems,
la asignacin de los valores mximos de asignacin de memoria y CPU al crear las
particiones asegura que una particin podr disponer de ms recursos cuando su carga
de trabajo exceda las capacidades asignadas inicialmente. Este sera por ejemplo el caso
cuando un nodo de un cluster falla, y el otro nodo debe hacerse responsable de la carga
de dos aplicaciones. Las pruebas de HACMP confirman que los servidores pueden
continuar trabajando prcticamente con total normalidad, experimentando solo ligeros
aumentos de los tiempos de respuesta.

Pgina 115 de 142

Eliminacin de los SPOFs
El diseo de la plataforma HW se ha realizado de manera a eliminar todos los
puntos nicos de fallo inherentes a la plataforma en las particiones de produccin. Se ha
configurado con redundancia a nivel de:
- consolas HMC (2 consolas HMC)
- fuentes de energa (2 fuentes por cajn de cada servidor)
- sistemas de refrigeracin (2 sistemas por cajn de cada servidor)
- almacenamiento interno (2 discos internos en mirror)
- conectividad de red (4 puertos para HACMP, en 2 controladoras)
- conectividad almacenamiento externo (2 tarjetas de fibra)
Existen sin embargo elementos ajenos que intervienen en la solucin sobre los
que no se puede influir, y para los cuales es el cliente o el proveedor de housing el que
debe suministrar la redundancia. Entre estos elementos se incluyen:
- elementos de red LAN (tener switches redundantes)
- elementos de red SAN (tener switches de fibra redundantes)
- almacenamiento externo (realizar raid de los discos externos)
- suministro elctrico (contratar dos proveedores diferentes)

Eliminar el tiempo de parada planificado
Las pruebas de HACMP realizadas demuestran que en condiciones normales se
pueden eliminar los tiempos de parada de las aplicaciones que estn causados por taras
de administracin y mantenimiento (aplicacin de parches, subida de niveles de
firmware, etc). Si embargo, esta configuracin no asegura que se puedan eliminar
ciertos tiempos de parada debido a condiciones fuera de la explotacin y administracin
normal. Estas paradas pueden estar provocadas por ejemplo en caso de traslado de los
servidores a otro edificio, o la redistribucin de las aplicaciones entre las particiones.

Minimizar el tiempo de cada accidental
Una de las funciones de HACMP es automatizar la recuperacin de la
aplicacin, ya sea en el mismo nodo o en otro, tras una cada por causas accidentales.
En condiciones normales, sin alta disponibilidad, el tiempo de recuperacin depende en
Pgina 116 de 142

gran medida del tiempo de deteccin de la cada. Monitorizando el estado de la
aplicacin y automatizando la recuperacin se reduce por lo tanto el tiempo total de
recuperacin. Las pruebas realizadas demuestran que los sistemas son capaces de
detectar las cadas y de recuperar las aplicaciones en un tiempo medio de 20 segundos,
siendo 90 segundos el mximo en los casos en los que es necesario conservar la
direccin MAC del dispositivo de red.

Asegurar la validez y consistencia de los datos
Los scripts de arranque y parada de las aplicaciones estn diseados para tener
en cuenta el estado de las bases de datos antes de arrancar las aplicaciones. Estos scripts
recuperan las bases de datos al ltimo estado consistente, haciendo rollback de las
transacciones no confirmadas que no han hecho commit. Esto no garantiza que todas las
transacciones terminen correctamente cuando se produce un fallo, pero si garantiza la
consistencia de los datos con las transacciones confirmadas.

Integrar las aplicaciones de produccin
En el caso de las aplicaciones, el software de HACMP solo tiene conocimiento
de los scripts de arranque y parada, no de los ejecutables ni del funcionamiento de las
aplicaciones, lo que permite integrar casi cualquier tipo de aplicacin. Los pocos casos
en los que no se podra integrar una aplicacin con HACMP son aplicaciones que
necesitan algn dispositivo HW especfico que no pueda configurarse de manera
automtica mediante el uso de scripts.
En este caso se ha logrado integrar tanto aplicaciones antiguas como
aplicaciones con necesidades espaciales de HW (tarjetas X25).

Ahorro de espacio
Como ya se ha visto, la plataforma HW ofertada ocupa dos racks, frente a los
tres racks iniciales, lo que supone una reduccin del 33 % de ocupacin en planta.
Por otro lado, la ocupacin dentro de los racks es de 40 Us, frente a las 86 Us
iniciales, lo que supone una reduccin del 53,5 % de ocupacin en rack.

Pgina 117 de 142

Asegurar la capacidad de crecimiento
El HW ofertado tiene una capacidad activa total de 16 CPUs y 64 GB de
memoria lo que supone un rPerf 80, que es el crecimiento previsto a corto plazo (de
aqu a 3 aos).
El HW ofertado tiene adems una capacidad instalada pero inactiva de 16 CPUs
y 64 GB de memoria. Activando estos recursos se llegara a un rPerf 160, que es el
crecimiento previsto a medio-largo plazo (ms de 3 aos).
El HW ofertado tiene adems una capacidad de ampliacin de 32 CPUs, lo que
hara un total de 64 CPUs, y 896 GB de memoria, lo que hara un total de 1024 GB.
Con esta capacidad se llegara a un rPerf de 340, lo que est fuera del crecimiento
previsto incluso a largo plazo.
Por otro lado, existe la posibilidad de actualizar estos servidores con los
procesadores POWER6, lo que puede llegar a suponer un aumento del 50 % del
rendimiento en cuanto a datos rPerf.

X.2. Mejoras propuestas
Integracin de SysBack con TSM
Dentro del entorno del cliente existe un sistema de copias de seguridad llamado
TSM (Tivoli Storage Manager). Este sistema automatiza las copias de seguridad de los
datos a un pool de almacenamiento jerrquico, con niveles de almacenamiento en disco
y en una librera de cintas LTO. Este sistema permite realizar copias de seguridad y
archivados de los datos, pero no est diseado para las imgenes de sistema operativo,
por lo que las copias de seguridad de los sistemas operativos se realizan de manera
manual al dispositivo de cintas local de cada servidor.
Existe una solucin llamada SysBack que se puede integrar con el servidor de
TSM y que permite realizar las copias de seguridad de los sistemas operativos mediante
TSM a la librera de cintas, y la reinstalacin del sistema operativo desde la cinta, a
travs de la LAN.
Pgina 118 de 142

La integracin de SysBack dentro con el servidor TSM del cliente simplificara
las tareas de administracin que se realizan actualmente, eliminado los procesos de
copia de seguridad de los sistemas operativos.

Implantacin de una solucin de monitorizacin
Existen varias soluciones de monitorizacin de los sistemas que centralizan los
datos mediante una consola. Estas soluciones permiten consultar en tiempo real el
estado de todos los servidores desde un punto central.
Esto permite adelantarse a ciertos fallos y reaccionar antes de que el problema
produzca una incidencia. Por otro lado estas soluciones guardan un histrico de los
datos, lo que permite estudiar la evolucin de la carga y la ocupacin. A la hora de
planificar las previsiones de crecimiento este histrico facilita la planificacin de las
posibles ampliaciones.
Muchos fabricantes disponen de una solucin de este tipo, normalmente
aplicaciones propietarias, pero tambin existen soluciones Open Source como por
ejemplo Nagios, que ofrecen casi las mismas prestaciones que las de los fabricantes
pero con un coste sensiblemente menor.

Procesadores POWER6
En junio de 2007 IBM ha presentado sus nuevos procesadores POWER6, con
unas frecuencias de 3.5 GHz, 4.2 GHz y 4.7 GHz y varias mejoras respecto a la
memoria cach de nivel L2 (entre otras cosas). Estos procesadores ofrecen un
incremento de hasta el 50 % de los datos de rPerf respecto a los procesadores
POWER5+ actuales.
Utilizados con una nueva versin del software de la consola HMC, estos
procesadores permiten entre otras cosas el movimiento de particiones y aplicaciones
entre servidores distintos, y un mejor aprovechamiento de los recursos de CPU y
memoria. Por otro lado estos procesadores permitirn aprovechar todas las ventajas del
sistema operativo AIX 6.1, que estar disponible a lo largo de 2007.
Por lo tanto, cuando el crecimiento de la carga de trabajo haga necesaria ms
capacidad de proceso, se recomienda actualizar los servidores con procesadores
POWER6 en lugar de aumentar el nmero de procesadores POWER5+. Esta
Pgina 119 de 142

actualizacin permitir reducir el nmero de procesadores necesarios, reduciendo el
nmero de licencias, y aprovechar las ventajas de los nuevos procesadores y el sistema
operativo AIX 6.1.
Pgina 120 de 142

Bibliografa

[IBMC05] International Business Machines Corporation (IBMC), Logical
Partitioning (LPAR) on POWER5 pSeries Systems, USA. Octubre 2005.

[IBMC04] International Business Machines Corporation (IBMC), HACMP
Systems Administration I: Planning and Implementation, USA. Diciembre 2004.

[IBMC03] International Business Machines Corporation (IBMC), HACMP
Systems Administration IV: Master Class, USA. Julio 2003.

[LASC05] Lascu O., S. Bodily, M. K. Esser, M. Herrera, P. Pothier, D. Quintero, V.
Sebesteny, A. Steel, D. Prelec, K. Raymond, A. Socoliuc, Implementing High
Availability Cluster Multi-Processing (HACMP) Cookbook, International Technical
Support Organization, Austin. Diciembre 2005.

[MATS03] Matsubara K., M. Robbins, R. Baker, T. Thitayanun, Effective System
Management Using the IBM Hardware Management Console for pSeries, International
Technical Support Organization, Austin. Agosto 2003.

Pgina 121 de 142

Anexos
Anexo A Auditoria
En este anexo se incluye toda la documentacin necesaria para configurar el
proceso de auditoria y su externalizacin a otro sistema.

Configuracin
El fichero de configuracin del proceso de auditoria es el
/etc/security/audit/config:
start:
binmode = on
streammode = off

bin:
trail = /var/log/auditoria/<hostname>
bin1 = /audit/bin1
bin2 = /audit/bin2
binsize = 10240
cmds = /etc/security/audit/bincmds
freespace = 65536

stream:
cmds = /etc/security/audit/streamcmds

classes:
general =
USER_SU,PASSWORD_Change,FILE_Unlink,FILE_Link,FILE_Rename,FS_Chdir,FS_
Chroot,PORT_Locked,PORT_Change,FS_Mkdir,FS_Rmdir
objects =
S_ENVIRON_WRITE,S_GROUP_WRITE,S_LIMITS_WRITE,S_LOGIN_WRITE,S_PASSWD_RE
AD,S_PASSWD_WRITE,S_USER_WRITE,AUD_CONFIG_WR
SRC =
SRC_Start,SRC_Stop,SRC_Addssys,SRC_Chssys,SRC_Delssys,SRC_Addserver,SR
C_Chserver,SRC_Delserver
kernel =
PROC_Create,PROC_Delete,PROC_Execute,PROC_RealUID,PROC_AuditID,PROC_Re
Pgina 122 de 142

alGID,PROC_Environ,PROC_SetSignal,PROC_Limits,PROC_SetPri,PROC_Setpri,
P
ROC_Privilege,PROC_Settimer
files =
FILE_Open,FILE_Read,FILE_Write,FILE_Close,FILE_Link,FILE_Unlink,FILE_R
ename,FILE_Owner,FILE_Mode,FILE_Acl,FILE_Privilege,DEV_Create
svipc =
MSG_Create,MSG_Read,MSG_Write,MSG_Delete,MSG_Owner,MSG_Mode,SEM_Create
,SEM_Op,SEM_Delete,SEM_Owner,SEM_Mode,SHM_Create,SHM_Open,SHM_Close,SH
M_
Owner,SHM_Mode
mail = SENDMAIL_Config,SENDMAIL_ToFile
cron =
AT_JobAdd,AT_JobRemove,CRON_JobAdd,CRON_JobRemove,CRON_Start,CRON_Fini
sh
tcpip =
TCPIP_config,TCPIP_host_id,TCPIP_route,TCPIP_connect,TCPIP_data_out,TC
PIP_data_in,TCPIP_access,TCPIP_set_time,TCPIP_kconfig,TCPIP_kroute,TCP
IP
_kconnect,TCPIP_kdata_out,TCPIP_kdata_in,TCPIP_kcreate
ipsec =
IPSEC_chtun,IPSEC_export,IPSEC_gentun,IPSEC_imptun,IPSEC_lstun,IPSEC_m
ktun,IPSEC_rmtun,IPSEC_chfilt,IPSEC_expfilt,IPSEC_genfilt,IPSEC_trcbuf
,I
PSEC_impfilt,IPSEC_lsfilt,IPSEC_mkfilt,IPSEC_mvfilt,IPSEC_rmfilt,IPSEC
_unload,IPSEC_stat,IKE_tnl_creat,IKE_tnl_delet,IPSEC_p1_nego,IPSEC_p2_
nego,IKE_activat_c
md,IKE_remove_cmd
lvm =
LVM_AddLV,LVM_KDeleteLV,LVM_ExtendLV,LVM_ReduceLV,LVM_KChangeLV,LVM_Av
oidLV,LVM_MissingPV,LVM_AddPV,LVM_AddMissPV,LVM_DeletePV,LVM_RemovePV,
LVM_
AddVGSA,LVM_DeleteVGSA,LVM_SetupVG,LVM_DefineVG,LVM_KDeleteVG,LVM_ChgQ
uorum,LVM_Chg1016,LVM_UnlockDisk,LVM_LockDisk,LVM_ChangeLV,LVM_ChangeV
G,LVM_CreateLV,LVM
_CreateVG,LVM_DeleteVG,LVM_DeleteLV,LVM_VaryoffVG,LVM_VaryonVG
ldapserver =
LDAP_Bind,LDAP_Unbind,LDAP_Add,LDAP_Delete,LDAP_Modify,LDAP_Modifydn,L
DAP_Search,LDAP_Compare
aacct =
AACCT_On,AACCT_Off,AACCT_AddFile,AACCT_ResetFile,AACCT_RmFile,AACCT_Sw
Pgina 123 de 142

tchFile,AACCT_TridOn,AACCT_TridOff,AACCT_SysIntOff,AACCT_SysIntSet,AAC
CT_P
rIntOff,AACCT_PrIntSet,AACCT_SwtchProj,AACCT_AddProj,AACCT_RmProj,AACC
T_PolLoad,AACCT_PolUnload,AACCT_NotChange,AACCT_NotifyOff

users:
root = general

En este caso, las opciones que interesan son las siguientes:
- seccin start:
o binmode = on y streammode = off. El proceso de auditoria permite
que los logs se guarden en formato binario (binmode) o en formato de
texto (streammode). En modo binario el log ocupa menos espacio y
es ms difcil de alterar.
- seccin bin:
o trail = /var/log/auditoria/<hostname>. El fichero indicado por trail
es el fichero que se usa como log. Se modifica para que lo guarde en
la ruta deseada, y en cada caso se sustituir <hostname> por el
nombre de la particin.
- seccin start:
o Los parmetros de la seccin classes indican las acciones que se
registrarn para los distintos tipos de eventos (acciones sobre
parmetros del kernel, acciones sobre el TCPIP, acciones sobre el
gestor de volmenes LVM, etc). Se han dejado los valores por
defecto, ya que son suficientemente exhaustivos.

Comandos
Los comandos que controlan el proceso de auditoria son los siguientes:
- audit start: cuando el proceso de auditoria no est arrancado, lee el fichero de
configuracin y arranca el proceso.
- audit shutdown: para el proceso de auditoria.
- audit off: pausa el registro de eventos, sin parar el proceso. Esto cierra el
fichero de log y permite manejarlo (para renombrarlo y copiarlo al sistema
externo).
Pgina 124 de 142

- audit on: cuando el proceso de auditoria est pausado lo vuelve a activar,
pero sin leer el fichero de configuracin.
- audit query: muestra el estado del proceso de auditoria, y los parmetros de
configuracin.

Externalizacin del fichero de log
Para externalizar los logs de auditoria de todos los servidores de produccin se
han tenido que realizar varias operaciones, tanto en los sistemas de produccin como en
el sistema externo.
En el sistema externo:
- Se ha creado un filesystem especfico para guardar los ficheros de log.
- Se ha creado un usuario anonymous para realizar ftp annimo desde los
servidores de produccin. Este usuario no tiene contrasea definida y no
puede iniciar una sesin interactiva, solo puede acceder por ftp. Se ha
definido como directorio principal (directorio home) de este usuario el
filesystem creado en el punto anterior. Este usuario solo tiene permisos
(tanto de escritura como de lectura pero no de ejecucin) en su directorio
home. Cada vez que este usuario accede por ftp se le solicita una contrasea,
y se puede indicar cualquiera, y quedar registrada dicha contrasea.

En los sistemas de produccin:
- Se ha creado un fichero .netrc con permisos solo de lectura para root. Este
fichero sirve para poder realizar ftp a otros servidores de manera automtica
sin que pida usuario y contrasea.
- Se ha creado y programado en el crontab del usuario root un script que pausa
el proceso de auditoria, renombra el fichero de log, lo enva de manera
automtica mediante ftp annimo al servidor externo, y borra el log
acumulado hasta el momento.

Pgina 125 de 142

Fichero .netrc:
machine srv_externo login anonymous password <hostname>

macdef sendascii
ascii
put $1 $2
quit

macdef sendbin
bin
put $1 $2
quit

Mediante machine se define un servidor al que se puede acceder y el usuario y la
contrasea que hay que usar. En cada caso se sustituir <hostname> por el nombre del
servidor de produccin, lo que permite identificar los accesos ya que se queda registrado
en el servidor destino (srv_externo).
Mediante macdef se define una macro, que es un serie de comandos a ejecutar
una vez iniciada sesin en el servidor externo. En este caso se han definido dos macros,
una para el envo en modo ascii, y otra para el envo en modo binario.

Script para el envo de los ficheros de log:

FECHA=$(date +"%y%m%d%H%M%S")
NOMBRE=$(hostname)
RUTA=/var/log/auditoria
ERROR_LOG=ERROR.$FECHA.$NOMBRE

Cd $RUTA
audit off
sleep 3
if [ ! -f $NOMBRE ]
then
echo "Servidor $NOMBRE sin fichero de audit el dia $FECHA" >
/tmp/$ERROR_LOG
echo "\$ sendascii /tmp/$ERROR_LOG $ERROR_LOG" | ftp
srv_externo
sleep 3
Pgina 126 de 142

rm /tmp/$ERROR_LOG
audit on
exit
else
mv $NOMBRE $FECHA.$NOMBRE
sleep 1
compress $NOMBRE
ls | while read param;
do
echo "\$ sendbin $param $param" | ftp srv_externo
rm $param
done
audit on
fi
Este script pausa el proceso de auditoria y, en caso de que exista el fichero de
log, lo renombra para indicar la fecha y lo comprime. Luego lo enva por ftp en modo
binario al servidor externo, borra el fichero de log y vuelve a activar el proceso de
auditoria.
En caso de que no exista el fichero enva por ftp en modo ascii un log de error al
servidor externo y vuelve a activar el proceso de auditoria.

Pgina 127 de 142

Anexo B Movimientos de recursos
En este anexo se incluye toda la documentacin necesaria para el movimiento de
las unidades de CD/DVD y de cinta.

Usuario genrico:
Para que usuarios sin permisos de root y que no son miembros del grupo system
puedan mover las unidades de cinta y CD/DVD, se ha creado un usuario genrico
(llamado op_recursos) con las siguientes caractersticas:
username = op_recursos
UID = 0 #UID de root
GID = 0 #GID de system
home = /home/op_recursos
shell = /home/op_recursos/.menush #programa inicial
login = false #no puede iniciar sesin en local
su = true #se puede acceder mediante su
rlogin = false #no puede iniciar sesin en remoto

Script principal:
El programa que se ejecuta cuando este usuario accede al sistema mediante su es
el script /home/op_recursos/.menush:
#!/bin/ksh
HOME=/home/op_recursos

# Trap que impide al usuario hacer break (^-C)
# para salir del men
trap "" 2

# Funcin que ejecuta la opcin seleccionada
procesa()
{
ITEXT=$(grep "^$resp=" $HOME/.menushrc | cut -d'=' -f2)
PROMPT=$(grep "^$resp=" $HOME/.menushrc | cut -d'=' -f4)
CMD=$(grep "^$resp=" $HOME/.menushrc | cut -d'=' -f3)
PG=$(grep "^$resp=" $HOME/.menushrc | cut -d'=' -f5)
if [ "$CMD" != "" ]
then
if [ "$PROMPT" != "none" ]
Pgina 128 de 142

then
echo " "
echo "\t\t\t$PROMPT\c"
read input
echo $(date)" "$ITEXT" "$input >> $HOME/menush.log
if [ "$PG" != "yes" ]
then
eval $CMD $input
else
eval $CMD $input | pg -n
fi
else
echo $(date)" "$ITEXT >> $HOME/menush.log
if [ "$PG" != "yes" ]
then
eval $CMD
else
eval $CMD | pg -n
fi
fi
else
echo $(date)" "$resp" Opcion incorrecta" >>
$HOME/menush.log
echo "\t\t\tOpcion incorrecta"
sleep 2
fi
}

# Leer el fichero de configuracin $HOME/.menushrc
# para mostrar las opciones.
# Si este fichero no existe, salir.
# Si este fichero existe, mostrar el men y ejecutar la
# opcin seleccionada hasta que el usuario
# seleccione 0 para salir.
if [ -r $HOME/.menushrc ]
then
IFS='='
resp="99"
while [ "$resp" != "0" ]
do
exec < $HOME/.menushrc
Pgina 129 de 142

read menuname
clear
echo "\t\t\t\tMenu $menuname"
echo " "
read inum iname icmd iprompt ipg
while [ $inum != "99" ]
do
echo "\t\t$inum\t$iname"
read inum iname icmd iprompt ipg
done
echo "\t\t0\tSalir"
echo " "
exec <&1
echo "\t\t\tOpcion: \c"
read resp
case $resp in
"0") exit;;
"1"|"2"|"3"|"4")
procesa;;
*) echo $(date)" "$resp" Opcion incorrecta" >>
$HOME/menush.log
echo "\t\t\tOpcion incorrecta"
sleep 2;;
esac
done
else
echo "\t\tNo se encuentra .menushrc"
echo $(date)"No se encuentra .menushrc" >> $HOME/menush.log
sleep 2
exit
fi

Este script lee, si existe, el fichero de configuracin /home/op_recursos/.menushrc,
muestra las opciones posibles y ejecuta la opcin seleccionada hasta que el usuario
selecciona salir. Si no existe el fichero de configuracin sale del men de manera
inmediata. Tambin registra todas las acciones en el fichero de log
/home/op_recursos/menush.log.

Pgina 130 de 142

Fichero de configuracin:
Las opciones posibles se definen en el fichero de configuracin
/home/op_recursos/.menushrc:
MoverRecursos
1=Detectar y configurar dispositivos=/usr/sbin/cfgmgr=none=no
2=Ver unidad CD=/usr/sbin/lsdev -l cd0=none=yes
3=Ver unidad cinta=/usr/sbin/lsdev -l rmt0=none=yes
4=Quitar CD y cinta=/usr/sbin/mi_rmdev cd0=none=yes
99

Este fichero define el nmero de opcin y el texto a mostrar para cada opcin, el
comando a ejecutar y dos opciones para la recogida de parmetros y el formateo de la
salida por pantalla.

Script adicional:
La cuarta opcin del fichero de configuracin apunta al segundo script creado,
que se encarga de eliminar los dispositivos del sistema. Este script es el
/usr/sbin/mi_rmdev:
#!/bin/ksh
if [ $# -ne 1 ]
then
echo "Error - Numero de parametros incorrecto"
echo "Sintaxis: $0 dispositivo"
exit
else
if ! expr "$1" : "cd." && ! expr "$1" : "rmt."
then
echo "Error - Dispositivo incorrecto"
echo "Sintaxis: $0 { cdX | rmtX }"
exit
else
DEV=$1
DEVSTAT=$(lsdev -Cl $DEV -F status 2>/dev/null)
case "$DEVSTAT" in
'')
echo "$DEV no asignado"
exit
;;
Pgina 131 de 142

Defined)
echo "$DEV definido pero no asignado"
exit
;;
Available)
while ! expr "$DEV" : "pci."
do
DEV=$(lsdev -Cl $DEV -F parent)
done
echo "Borrando los dispositivos"
rmdev -l $DEV -R
;;
esac
fi
fi

Este script lee el dispositivo pasado como parmetro, y comprueba si es de tipo cd o
cinta (rmt). En caso afirmativo determina si el dispositivo se encuentra asignado y
configurado en esta particin. Si el dispositivo no se encuentra configurado da un error
y sale, en caso contrario busca de manera recursiva el dispositivo padre, hasta
encontrar la tarjeta SCSI fsica (dispositivo pci). Cuando encuentra el dispositivo pci lo
elimina con la opcin recursiva, para que elimine tambin los dispositivos que cuelgan
de dicha tarjeta (el cd y la cinta).

Pgina 132 de 142

Anexo C Configuracin de ntp
En este anexo se incluye toda la documentacin necesaria para la configuracin
de la sincronizacin horaria mediante el protocolo NTP.

Fichero de configuracin:
El fichero de configuracin de ntp en el que se indican los servidores a los que
conectarse y las opciones es el /etc/ntp.conf:
# @(#)48 1.2 src/tcpip/etc/ntp.conf, ntp, tcpip530 2/16/96
# 10:16:34
# IBM_PROLOG_BEGIN_TAG
# This is an automatically generated prolog.
#
# tcpip530 src/tcpip/etc/ntp.conf 1.2
#
# Licensed Materials - Property of IBM
#
# Restricted Materials of IBM
#
# (C) COPYRIGHT International Business Machines Corp. 1996
# All Rights Reserved
#
# US Government Users Restricted Rights - Use, duplication or
# disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
#
# IBM_PROLOG_END_TAG
#
# COMPONENT_NAME: ntp
#
# FUNCTIONS: none
#
# ORIGINS: 27,176
#
#
# (C) COPYRIGHT International Business Machines Corp. 1996
# All Rights Reserved
# Licensed Materials - Property of IBM
# US Government Users Restricted Rights - Use, duplication or
# disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
Pgina 133 de 142

#
#
#
#
# Default NTP configuration file.
#
# Broadcast client, no authentication.
#
broadcastclient
driftfile /etc/ntp.drift
tracefile /etc/ntp.trace
server IP_Srv_ntp_principal prefer iburst
server IP_Srv_ntp_backup1 version 2 prefer
server IP_Srv_ntp_backup2 version 2 prefer

Las entradas que hay que aadir son las entradas relativas a los servidores, y las
distintas opciones son:
- version: existen tres versiones del protocolo NTP. Si no se especifica este
parmetro se usa la versin por defecto que es la 3. En el caso de los
servidores de respaldo, la versin utilizada es ms antigua (la versin 2) por
lo que hay que especificarlo.
- prefer: si se especifica esta opcin se marca este servidor como preferido, y
los paquetes recibidos desde este servidor no pasarn ningn filtro
preliminar.
- iburst: si se especifica esta opcin se enviarn 8 paquetes en intervalos de
dos segundos en la sincronizacin inicial (al arrancar el proceso), en vez de
un solo paquete. El protocolo NTP utiliza UDP y no est orientado a
conexin por lo que no asegura la entrega de un paquete o la recepcin de la
respuesta. Enviando 8 paquetes en vez uno solo se intenta asegurar que se
sincronice la hora por lo menos en el momento del arranque.

Sincronizacin manual y arranque:
Antes de arrancar el proceso de sincronizacin es conveniente que la hora de
ambos servidores no est demasiado desfasada, ya que en ese caso podra tardar ms
tiempo en ajustar el desfase. Esto se hace manera manual mediante el siguiente
comando: ntpdate IP_Srv_NTP
Pgina 134 de 142

Para arrancar el proceso cliente de NTP para que se quede corriendo en la
particin hay que ejecutar el siguiente comando: startsrc s xntpd

Programar el proceso en el arranque:
Para que el proceso de ntp se inicie con el arranque y los reinicios de la particin
hay que incluirlo en el fichero /etc/inittab del sistema. Debido a la importancia de este
fichero est fuertemente desaconsejado editar el fichero de forma manual. Se
recomienda utilizar en su lugar comandos de sistema operativo de alto nivel que validan
los datos que se incluyen el fichero. Para incluir el proceso de ntp en el arranque hay
que hacerlo mediante el comando: mkitab ntp:2:once:/usr/sbin/startsrc s xntpd
Este comando incluye en el fichero /etc/inittab una entrada con el identificador
ntp. Esta entrada se ejecuta cuando el sistema operativo entra en el nivel de ejecucin 2,
que es el nivel de ejecucin por defecto. Con el parmetro once se le indica que se
ejecute y que siga leyendo el fichero /etc/inittab sin esperar a la terminacin del
comando, y que no vuelva a levantar el proceso en caso de que se pare.
Pgina 135 de 142

Anexo D Alta Disponibilidad sobre Linux
En este proyecto se ha implantado HACMP de IBM como solucin de alta
disponibilidad, pero no es la nica solucin de este tipo que existe para sistemas
distribuidos. Existen varias soluciones de alta disponibilidad de otros fabricantes y para
otros sistemas operativos:
- IBM Tivoli System Automation for Multiplatforms (AIX, Linux)
- Legato AAM (AIX, HP-UX, Solaris, Linux, Windows)
- SteelEye LifeKeeper (Linux, Windows)
- Veritas Cluster Server (AIX, HP-UX, Solaris, Linux, Windows)
- Heartbeat (Linux)

Todas estas son soluciones que crean el cluster a nivel de sistema operativo, pero
existen adems aplicaciones que se configuran en cluster y ofrecen alta disponibilidad a
nivel de aplicacin, en vez de a nivel de sistema operativo. Entre estas aplicaciones, los
ejemplos ms importantes son:
- WebSphere Application Server
- IBM MQ Series
- Microsoft SQL Server Failover Cluster (se apoya en el sistema operativo)

En este caso se ha escogido HACMP por su afinidad e integracin con el sistema
operativo AIX, pero su elevado precio y su exclusividad con AIX y sistemas pSeries no
lo hacen apto para fines formativos y de pruebas. Si lo que se desea es experimentar con
sistemas de alta disponibilidad como formacin personal o con fines acadmicos resulta
ms interesante optar por una opcin de menor coste, como por ejemplo Heartbeat.
Heartbeat es una solucin Open Source de alta disponibilidad, en un principio
desarrollada para Linux aunque es fcilmente portable a FreeBSD, Solaris, MacOS/X y
OpenBSD. Tambin existen soluciones de balanceo del trfico como Ultra Monkey que
integran Heartbeat embebido en su desarrollo.
Teniendo en cuenta de que este proyecto es un proyecto de fin de carrera,
adems de un proyecto comercial, resulta interesante ver una solucin de alta
disponibilidad ms adecuada para fines acadmicos.
Pgina 136 de 142

En este anexo se incluye la documentacin necesaria para implementar un
cluster de alta disponibilidad sencillo y econmico, con dos nodos y almacenamiento
externo a travs de NFS. La aplicacin puesta en alta disponibilidad para este ejemplo
es el servidor web Apache. En este documento se suponen conocimientos a nivel de
administracin de Linux.

Configuracin de Heartbeat
Recursos fsicos necesarios:
- 3 PCs (nodo1, nodo2 y servidor NFS) con Linux instalado. Los dos nodos
deben tener un puerto serie. En este caso se ha usado Red Hat Enterprise
Linux.
- un cable serie null-modem. En este caso ha habido que encargarlo, indicando
el cableado
1
.
- conectividad IP entre los 3 PCs.

En este caso, la configuracin IP ha sido la siguiente:
- nodo1:
o Nombre mquina: nodo1.cluster.pruebas
o IP: 10.1.10.2
- nodo2:
o Nombre mquina: nodo2.cluster.pruebas
o IP: 10.1.10.3
- srv_nfs:
o Nombre mquina srv_nfs.cluster.pruebas
o IP: 10.2.6.5
- Servicio:
o Nombre mquina: servicio.cluster.pruebas
o IP: 10.1.10.4
La direccin IP de Servicio es el recurso que se pone en alta disponibilidad, para que se
pueda acceder a la aplicacin desde fuera, sea cual sea el nodo que la est ejecutando en
ese momento. Esta IP debe estar asociada al nombre servicio.cluster.pruebas en el DNS.

Pgina 137 de 142

Lo primero es conectar los dos nodos mediante el cable serie, y comprobar que
pueden comunicarse en ambos sentidos.
Para ello hay que indicar a un nodo (nodo1) que escuche y muestre el puerto serie:
cat < /dev/ttyS0
En el otro nodo (nodo2) hay que enviar algo de texto por el puerto serie:
echo Prueba serie > /dev/ttyS0
En nodo1 debera mostrarse el texto Prueba serie. Si la prueba funciona hay que
hacerla en el sentido contrario, mandando texto desde nodo1 a nodo2.

Lo siguiente es exportar un directorio por NFS en srv_nfs. Se crea un directorio
/nfs_ha y se edita el fichero /etc/exports, aadiendo las siguientes entradas:
/ha_nfs 10.1.10.2(rw,no_root_squash)

Una vez editado el fichero hay que arrancar el servicio de NFS. Si ya estaba
arrancado habra que ejecutar exportfs ra para forzar al servicio a leer de nuevo el
fichero de configuracin.

En nodo1 y nodo2 hay que aadir una entrada al fichero /etc/fstab para incluir
este filesystem de tipo NFS:
srv_nfs.cluster.pruebas:/ha_nfs /ha_nfs nfs noauto,rw,hard 0 0

Una vez realizadas estas configuraciones previas, hay que descargar e instalar el
software de Heartbeat en nodo1 y en nodo2. Una vez descargado el software, hay que
instalar los paquetes siguiendo este orden:
rpm -ivh heartbeat-pils-1.2.2-8.rh.el.3.0.i386.rpm
rpm -ivh heartbeat-stonith-1.2.2-8.rh.el.3.0.i386.rpm
rpm -ivh heartbeat-1.2.2-8.rh.el.3.0.i386.rpm
Cuando el software ya est instalado en ambos nodos, hay que configurar
Heartbeat. Esto se hace simplemente editando tres ficheros de configuracin:
/etc/ha.d/authkeys, /etc/ha.d/ha.cf y /etc/ha.d/haresources.

Fichero /etc/ha.d/authkeys:
Pgina 138 de 142

Este fichero indica los mtodos de autenticacin y las claves que utilizar
Heartbeat para la comunicacin entre los nodos. El formato de este fichero es:
auth <nmero>
<nmero> <mtodo> [clave]
Los mtodos que se pueden usar son crc, md5 y sha1. En este caso, al ser un cluster de
pruebas en un entorno aislado no se necesita demasiada seguridad, por lo que se ha
usado crc, pero en un entorno real se recomienda usar md5 o sha1 (sha1 es ms seguro
pero consume ms CPU).
El fichero /etc/ha.d/authkeys usado es:
auth 2
2 crc
Los permisos de este fichero deben ser 600 (solo lectura para root).

Fichero /etc/ha.d/ha.cf:
Este fichero contiene todas las opciones de configuracin para el funcionamiento
de Heartbeat, pero sin especificar los recursos (IP, almacenamiento) que tendr que
controlar. Existen muchas opciones que se pueden definir, pero para un caso de prueba
como este solo resultan necesarias las siguientes:
# Fichero de debug
debugfile /var/log/ha-debug
# Fichero de log
logfile /var/log/ha-log
# syslog()/logger
logfacility local0
# keepalive: tiempo entre heartbeats
keepalive 2
# deadtime: tiempo hasta que se declara cado
deadtime 60
# warntime: tiempo antes de enviar el warning "late heartbeat"
warntime 10
# initdead: tiempo al arranque hasta que se declara cado
initdead 120
# Frecuencia en baudios para el puerto serie
baud 19200
# Nombre puerto serie
serial /dev/ttyS0
# auto_failback: indica si un recurso debe
# volver de manera automtica a su nodo principal
Pgina 139 de 142

# cuando ste vuelva a estar activo
auto_failback on
# node: indica los nodos que forman el cluster
node nodo1.cluster.pruebas
node nodo2.cluster.pruebas
# Procesos que se arrancan y paran con Heartbeat
# Se rearrancan si se paran,
# excepto si salen con cdigo de retorno rc=100
respawn hacluster /usr/lib/heartbeat/ipfail

Fichero /etc/ha.d/haresources:
Este fichero indica los recursos controlados por Heartbeat. Estos recursos suelen
ser direcciones IP, dispositivos de almacenamiento y scripts de arranque y parada de
aplicaciones. En este caso el fichero contiene nicamente la siguiente entrada (todo est
en una misma lnea):
nodo1.cluster.pruebas 10.1.10.4
Filesystem::srv_nfs.cluster.pruebas:/ha_nfs::/ha_nfs::rw,hard
httpd
Esta entrada en el fichero indica los siguientes recursos:
- nodo1.cluster.pruebas: nombre del nodo principal de la aplicacin
- 10.1.10.4: direccin IP a asociar al nodo activo
- Filesystem::srv_nfs.: filesystem de tipo NFS a asignar al nodo activo, con
las opciones para montarlo
- httpd: script para arrancar la aplicacin. Este script viene incluido con el
software de Heartbeat y arranca y para el servidor Apache.

Prueba de Apache sobre Heartbeat
Para comprobar el funcionamiento de Heartbeat se va a configurar Apache para
que sea capaz de servir pginas web tanto desde el almacenamiento compartido como
desde el almacenamiento local de cada servidor, accediendo nicamente a la direccin
IP de servicio. La pgina web http://servicio.cluster.pruebas/index.html debe residir en
el almacenamiento compartido, y ser por lo tanto siempre la misma. La pgina web
http://servicio.cluster.pruebas/hostname.html debe residir en el almacenamiento local de
cada servidor, y mostrar un resultado diferente en funcin del nodo que tenga la
aplicacin activa.
Pgina 140 de 142

Para que el servidor Apache pueda servir pginas web desde los dos nodos del
cluster, hay que configurarlo para que apunte al almacenamiento compartido por NFS.
Lo primero es crear los directorios /ha_nfs/www y /ha_nfs/www/html dentro del
directorio NFS, desde un solo nodo, y establecer los permisos adecuados:
chmod 775 /ha_nfs/www
chmod 775 /ha_nfs/www/html

Luego hay que renombrar el directorio /var/www/html en ambos nodos, y hacer
que apunten mediante enlaces simblicos al directorio en el almacenamiento
compartido:
mv /var/www/html /var/www/html_local
ln s /ha_nfs/www/html /var/www/html

Ahora hay que copiar en los distintos directorios las pginas web que se van a
servir. Para esta prueba se ha usado un paquete llamado hahbcode.tar.gz, que incluye las
pginas web index.html y hostname.html necesarias para realizar las pruebas. Hay que
descargar este paquete y descomprimirlo en el directorio compartido /ha_nfs:
cd /ha_nfs
tar xvfz hahbcode.tar.gz

Una vez descomprimido hay que copiar el fichero index.html al almacenamiento
compartido, desde un solo nodo:
cp /ha_nfs/hahbcode/www/index.html /ha_nfs/www/index.html
Hay que editar el fichero para modificar el nombre del cluster.

Luego hay que copiar el fichero hostname.html al almacenamiento local, en
ambos nodos:
cp /ha/hahbcode/www/hostname.html /var/www/htmllocal/hostname.html
En cada nodo hay que editar el fichero para modificar el nombre del cluster y del nodo
en cuestin.

Una vez copiado y personalizado el fichero hostname.html en ambos nodos, hay
que crear un enlace simblico desde el directorio compartido al almacenamiento local:
ln s /var/www/htmllocal/hostname.html /ha_nfs/www/hostname.html
Pgina 141 de 142

Con estos pasos ya se ha completado la configuracin, y se pueden realizar las
pruebas. Las pruebas consisten en acceder, desde un sistema externo al cluster, a las
pginas index.html y hostname.html cuando la aplicacin est activa en un nodo, y
luego cuando la aplicacin est activa en el otro nodo. En ambos casos la pgina
index.html debe ser la misma, puesto que solo hay una copia, en almacenamiento
compartido, pero la pgina hostname.html debe mostrar un resultado diferente,
identificando al servidor que tiene la aplicacin activa.

Los pasos a seguir son:
Arrancar el servicio heartbeat, primero en el nodo principal (nodo1) y luego en
el nodo de respaldo (nodo2):
/etc/rc.d/init.d/heartbeat start
Comprobar que en el nodo1 se ha configurado una IP adicional, con la
IP_servicio, y que se han arrancado los servicios de Apache. En el nodo2 no se debera
arrancar ningn servicio de Apache.
Comprobar que se accede de manera correcta a las pginas
http://servicio.cluster.pruebas/index.html y http://servicio.cluster.pruebas/hostname.html
y que la pgina hostname.html muestra el nombre del nodo1.
Simular una cada del servidor nodo1. Esto se puede hacer simplemente parando
los servicios de heartbeat:
/etc/rc.d/init.d/heartbeat stop
Comprobar que en el nodo1 se han parado los servicios de Apache y se ha
eliminado la IP adicional, y que se han pasado al nodo2.
Comprobar que se accede de manera correcta a las misma pginas que antes, y
que la pgina hostname.html muestra el nombre del nodo2.
Rearrancar los servicios de heartbeat en el nodo1. Este debera parar los
servicios de Apache en el nodo2, y volver a arrancarlos en el nodo1, as como volver a
configurar en el nodo1 la IP adicional. Este comportamiento lo tiene porque en el
fichero /etc/ha.d/ha.cf se ha especificado la opcin auto_failback on.

Pgina 142 de 142

Nota 1:
Pineado y seales de un cable null modem de conexin de dos puertos series RS232
estndar DB9-DB9.
DB9 pin D-SUB hembra a PC1 DB9 pin D-SUB hembra a PC2

DB9-
PC 1
DB9-
PC2

Receive Data 2 3 Transmit Data
Transmit Data 3 2 Receive Data
Data Terminal Ready 4 6+1 Data Set Ready + Carrier Detect
System Ground 5 5 System Ground
Data Set Ready + Carrier Detect 6+1 4 Data Terminal Ready
Request to Send 7 8 Clear to Send
Clear to Send 8 7 Request to Send
DSR&CD estn unidos (6 + 1) para indicar a los dispositivos que estn online, esta
opcin no es obligatoria.

Implant A Cio de Clusters

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Implant A Cio de Clusters

Uploaded by

Copyright:

Available Formats

Autorizada la entrega del proyecto del alumno:

Manuel Reao Costales

You might also like