crear un entorno de alta disponibilidad para determinados … · 2013-10-16 · alberto díez...
Post on 04-Jan-2020
9 Views
Preview:
TRANSCRIPT
Alberto Díez Escobés
Crear un entorno de alta disponibilidad para determinados recursos utilizando clustering en Linux
Eloy Javier Mata Sotés y Eduardo Sáenz de Cabezón Irigaray
Facultad de Ciencias, Estudios Agroalimentarios e Informática
Proyecto Fin de Carrera
Matemáticas y Computación
2012-2013
Título
Autor/es
Director/es
Facultad
Titulación
Departamento
PROYECTO FIN DE CARRERA
Curso Académico
© El autor© Universidad de La Rioja, Servicio de Publicaciones, 2013
publicaciones.unirioja.esE-mail: publicaciones@unirioja.es
Crear un entorno de alta disponibilidad para determinados recursosutilizando clustering en Linux, proyecto fin de carrera
de Alberto Díez Escobés, dirigido por Eloy Javier Mata Sotés y Eduardo Sáenz de CabezónIrigaray (publicado por la Universidad de La Rioja), se difunde bajo una Licencia
Creative Commons Reconocimiento-NoComercial-SinObraDerivada 3.0 Unported. Permisos que vayan más allá de lo cubierto por esta licencia pueden solicitarse a los
titulares del copyright.
Índice
1.- IN TRODUC CIÓN 1
1.1.- La Empresa 1
1.1.1.- Descripción general de la empresa 1
1.1.2.- El departamento de informática 1
1.1.3.- Función propia en la empresa 1
1.2.- Descripción del proyecto 2
2.- DOCUME NTO DE OBJ E TIVO S DE L PROY E CTO 5
2.1.- Antecedentes 5
2.2.- Objetivos 5
2.3.- Entregables 6
2.3.1.- Descripción de la empresa y del proyecto 6
2.3.2.- Documento de objetivos del proyecto 6
2.3.4.- Documentación del análisis y diseño del sistema 6
2.3.5.- Documentación de las pruebas del sistema 6
2.3.6.- Documentación sobre la gestión del proyecto 7
2.3.7.- Documentación sobre explotación 7
2.3.8.- Actas de reuniones 7
2.4.- Alcance 7
2.5.- Estructura de descomposición de tareas 8
2.6.- Plan de trabajo 8
2.7.- Riesgos 9
2.8.- Costes 9
3.- ANÁLIS IS Y DIS E ÑO DE L S IS TE MA 11
3.1.- Evaluación de alternativas 11
3.1.1.- Alternativa 1 11
3.1.2.- Alternativa 2 12
3.2.- Elección de la alternativa más válida 13
3.3.- Requisitos hardware de la alternativa elegida 13
3.4.- Requisitos software de la alternativa elegida 14
3.4.1.- Configuración del software 14
14 3.5.- Estructura y desarrollo de la alternativa elegida 17
3.5.1.- Switches Ethernet 18
3.5.2.- Servidores 20
3.5.3.- Switches de fibra óptica 22
3.5.4.- Cabina de almacenamiento (SAN) 24
4.- IMPLAN TACIÓN DE L S IS T E MA 27
4.1.- Asignación de recursos a los servidores e interfaces de gestión
27
4.1.1.- Nodo 1 del clúster 27
4.1.2.- Nodo 2 del clúster 28
4.1.3.- Switch de fibra 1 28
4.1.4.- Switch de fibra 2 29
4.1.5.- Controladora A de la cabina de almacenamiento 29
4.1.6.- Controladora B de la cabina de almacenamiento 29
4.2.- Instalación del sistema operativo en los servidores 29
4.3.- Configuración de la red 29
4.3.1.- Configuración de los puertos en los switches 29
4.3.2.- Configuración del direccionamiento IP de dispositivos 32
4.3.3.- Configuración de las interfaces de red de los s ervidores 34
4.4.- Configuración de los switches de fibra óptica 38
4.4.1.- Configuración de los alias 38
4.4.2.- Configuración de las zonas 41
4.5.- Configuración del acceso al almacenamiento de los servidores
44
4.5.1.- Instalación de paquetes necesarios para almacenamiento en los servidores
44
4.5.2.- Creación del raid group en la cabina de almacenamiento 44
4.5.3.- Creación de las LUNs que se asignarán a los servidores 46
4.5.4.- Creación del storage group para dar acceso a los servidores
47
4.5.5.- Configuración del modo de acceso de los servidores a la cabina
49
4.6.- Instalación y configuración de software
51
4.6.1.- Instalación de los paquetes necesarios 51
4.7.- Creación del clúster 56
4.7.1.- Configuración de parámetros globales del clúster 58
4.7.2.- Creación del disco de quórum y configuración para que sea util izado por el clúster
59
4.8.- Creación de los recursos a los que dará servicio el clúster
62
4.8.1.- Creación del recurso de IP virtual del clúster 62
4.8.2.- Configuración y creación del recurso de almacenamiento compartido
63
4.8.3.- Configuración y creación del recurso de Samba 67
4.8.4.- Configuración y creación del recurso de impresión 70
4.8.5.- Creación del dominio fail -over para los servicios del clúster
73
4.8.6.- Creación del servicio que dará soporte a los recursos 73
4.8.7.- Configuración de opciones de fencing 77
4.9.- Revisión del estado del clúster tras su creación 80
5.- PRUE BAS 85
5.1.- Pruebas tras la implantación 86
5.1.1.- Pruebas de configuración 86
5.1.2.- Pruebas de error a nivel de red 93
5.1.3.- Pruebas de error a nivel eléctrico 97
5.1.4.- Pruebas de error a nivel de almacenamiento 98
5.2.- Fase de producción 101
5.2.1.- Pruebas de rendimiento 101
5.2.2.- Análisis de problemas 103
6.- GE S TIÓN DE L PROY E CTO 105
6.1.- Estimación inicial 105
6.2.- Factores que han afectado al ciclo de vida 105
6.2.1.- Realización de cursos necesarios para el trabajo en la empresa
105
6.2.2.- Monitorización de rendimiento en determinadas circunstancias
105
6.2.3.- Viajes a las distintas fábricas 106
6.2.4.- Necesidad de incorporación de modificaciones 106
6.2.5.- Problemas con dispositivos del sistema 106
6.2.6.- Necesidad de realización de otras tareas en la empresa 107
6.3.- Comparativas 107
6.3.1.- Comparativa de horas estimadas con las reales 107
6.3.2.- Repartición en tareas de las horas reales dedicadas al proyecto
107
6.3.3.- Comparativa de las tareas a lo largo del tiempo 108
6.4.- Conclusiones 108
ANE XO I: INS TALACIÓN DE L S IS TE MA OPE RATIVO E N LOS
S E RVIDORE S 111
ANE XO II: MANUA L DE E XPLOTACIÓN P OR LÍNE A DE
COMANDOS 123
ANE XO III: ACTAS 127
1
1.- Introducción
En este apartado se hará una descripción de la empresa para la que se realiza el proyecto y una
breve descripción de éste que se irá detallando en los siguientes apartados.
1.1.- La empresa
1.1.1.- Descripción general de la empresa
Conservas Cidacos nace en 1940 como una pequeña empresa familiar en una de las zonas más
fértiles de La Rioja, el valle del río Cidacos, del que toma su nombre. En esta ribera se cultivan las
huertas en las que se siembran, crecen y recogen la excelente cosecha de productos Cidacos.
Hoy, más de medio siglo después, Cidacos ha extendido sus campos de recolección y producción a
sus factorías de Autol (La Rioja), Funes (Navarra), Puebla de Montalbán (Toledo) y Coria (Cáceres).
En 1999 Cidacos inició su expansión internacional con la compra del 60% de Weishan Ciway Food
Co., Ltd., empresa situada en China y dedicada desde sus inicios a la fabricación de espárrago. En el
año 2003 entró a formar parte, con un 51%, de la sociedad Heze Yulu Star, también en China.
Aunando tradición e innovación, Cidacos sigue, como en sus inicios, garantizando la calidad de sus
productos, lo que la ha configurado como una de las marcas de máxima confianza de los
consumidores.
1.1.2.- El departamento de informática
El departamento de informática de Conservas El Cidacos, S.A. se compone de cinco miembros
encargados de las labores de mantenimiento de los sistemas informáticos así como de las
aplicaciones corporativas.
Los roles de los componentes de éste son:
- Un responsable de sistemas informáticos.
- Un desarrollador.
- Un técnico de sistemas.
- Un técnico de soporte senior.
- Un técnico de soporte junior.
El puesto que desempeño dentro de la empresa es el de técnico de sistemas y que se detalla en el
siguiente apartado del documento.
1.1.3.- Función propia en la empresa
Desde el inicio, comenzando con la realización de prácticas a través de la Universidad, se me ha ido
formando continuamente en las diversas áreas relacionadas con la labor informática dentro de la
empresa.
2
Tras más de tres años y habiendo pasado por los puestos de técnico de soporte (junior y senior),
ahora me encuentro en la posición de técnico de sistemas en la cual habría que destacar las
siguientes funciones:
- Mantenimiento de la infraestructura.
- Evaluar de riesgos que podrían afectar al normal funcionamiento de la empresa y
proponer posibles soluciones.
- Comprobar viabilidad de nuevas implantaciones, así como proponer alternativas, si fuese
necesario, para su posterior realización.
- Realización de documentación y procedimientos para gestionar de forma eficaz los
recursos de los que dispone la empresa.
- En caso de haber algún problema en la resolución de alguna incidencia, ésta me sería
escalada como segundo nivel de soporte.
1.2.- Descripción del proyecto
La elaboración de este proyecto responde a la necesidad de crear un entorno de alta disponibilidad
para realizar la implantación del nuevo RP en la empresa. La labor de implantación del RP la está
llevando una consultora externa especializada.
La fecha tope para la realización del proyecto será la última semana del mes de Noviembre debido
a que el lanzamiento del nuevo RP está planificado para el dos de Enero de 2012.
Lo que abarca este proyecto:
Dados los elementos necesarios para montar la infraestructura y concretados los requisitos para la
aplicación, se debe hacer lo siguiente:
- Preparación de la cabina de almacenamiento para crear el almacenamiento compartido.
o Configurar los RAID group necesarios.
o Configurar las LUN para poder asignarlas a los servidores.
o Configurar los Storage Group que enlazarán las LUN con los servidores.
- Conexión de los servidores a la cabina.
o Configurar las conexiones de las HBA de los servidores en los switches para que
les permitan acceder a la cabina.
- Configuración de los elementos de red.
o Configuración de los switches para conectar los servidores de forma redundante.
- Configuración de los servidores.
o Instalación del sistema operativo.
o Configuración de la red en alta disponibilidad.
o Configuración de clúster y sus servicios.
- Pruebas de alta disponibilidad.
3
** El objetivo principal es no tener un punto de fallo único en ninguna de las capas de la
infraestructura que pueda provocar una pérdida de servicio ya que va a pertenecer al entorno de
producción de la empresa. **
Lo que no abarca este proyecto:
- Implantación del nuevo RP ya que como se ha comentado anteriormente lo realizará una
empresa consultora externa especializada en este tipo de implantaciones.
4
5
2.- Documento de objetivos del proyecto
2.1.- Antecedentes
Los únicos precedentes a nivel de la creación de clústers en la empresa han sido utilizando el
sistema operativo Windows. Es la primera implementación de clúster en linux que se pretende
implantar para un sistema que formará parte del entorno de producción.
2.2.- Objetivos
La elaboración de este proyecto responde a la necesidad de crear un entorno de alta disponibilidad
para realizar la implantación del nuevo RP en la empresa. La labor de implantación del RP la está
llevando una consultora externa especializada.
La fecha tope para la realización del proyecto será la primera semana del mes de Diciembre debido
a que el lanzamiento del nuevo RP está planificado para el dos de Enero de 2012.
Es requisito indispensable que no exista ningún punto de error único que pueda provocar la
pérdida de accesibilidad a los servicios montados sobre el clúster. Con ello se pretende garantizar la
redundancia de dispositivos a nivel de infraestructura.
Dados los elementos necesarios para montar la infraestructura y concretados los requisitos para la
aplicación, se debe hacer lo siguiente:
- Preparación de la cabina de almacenamiento para crear el almacenamiento compartido.
- Configurar los RAID Groups necesarios.
- Configurar las LUNs (Logical Unit Numbers) para poder asignarlas a los servidores.
- Configurar los Storage Groups que enlazarán las LUNs con los servidores.
- Conexión de los servidores a la cabina.
- Configurar las conexiones de las HBA de los servidores en los switches de fibra óptica para
que les permitan acceder a la cabina.
- Configuración de los elementos de red.
- Configuración de los switches de red para conectar los servidores de forma redundante.
- Configuración de los servidores.
- Instalación del sistema operativo.
- Configuración de las interfaces de la red en alta disponibilidad.
- Configuración de clúster y sus servicios.
- Pruebas de alta disponibilidad.
Una vez realizada la implantación de la solución, habrá que elaborar un manual de explotación del
sistema.
6
2.3.- Entregables
Los entregables se generarán a partir de cada una de las tareas que se han de realizar durante cada
una de las fases del proyecto. Estos entregables servirán para realizar un seguimiento de la
evolución del proyecto y posteriormente formarán parte de la memoria.
2.3.1.- Descripción de la empresa y del proyecto
Esta documentación incluirá una breve descripción sobre la empresa para la que se va a realizar el
proyecto junto con la descripción inicial del proyecto que se va a llevar a cabo.
2.3.2.- Documento de objetivos del proyecto
Este entregable corresponde a este documento. Incluirá antecedentes relacionados con el
proyecto, los objetivos de éste, entregables, alcance del proyecto, estructura de descomposición
de tareas, plan de trabajo, riesgos y costes.
2.3.3.- Documentación del análisis y diseño del sistema
Esta documentación incluirá la información sobre la fase de diseño del sistema. En esta parte se
incluirá una valoración de las alternativas para satisfacer los objetivos, la alternativa elegida para la
implementación y la justificación de la elección de esa alternativa sobre las restantes.
2.3.4.- Documentación de la implantación del sistema
Esta documentación incluirá la información sobre la fase de implantación del sistema. En esta parte
se detallarán los pasos realizados para llevar a cabo la implantación de la alternativa elegida
durante la fase de análisis y diseño del sistema. En esta parte se incluirá la relación de problemas
encontrados junto con las soluciones adoptadas para subsanarlos. Si estas soluciones implicasen
alguna replanificación, ésta deberá quedar debidamente justificada y documentada donde
corresponda.
2.3.5.- Documentación de las pruebas del sistema
Esta documentación incluirá la información sobre la fase de pruebas del sistema. Este documento
deberá estar lo suficientemente detallado ya que esta es una fase crítica. Las pruebas a realizar con
sus respectivos resultados son cruciales para la aceptación final del sistema.
Cada una de las pruebas que se realizarán estará lo suficientemente documentada especificando
los resultados esperados y, en caso de no satisfacerse, las medidas correctivas para garantizar la
funcionalidad del sistema.
7
2.3.6.- Documentación sobre gestión del proyecto
Esta documentación incluirá un análisis de la planificación original del proyecto con respecto al
tiempo de dedicación real a éste del que se sacaran unas determinadas conclusiones. Se expondrán
los motivos de las desviaciones en la planificación junto con sus causas y posteriormente se
redactará una conclusión sobre los resultados obtenidos.
2.3.7.- Documentación sobre explotación
Esta documentación incluirá la información necesaria una vez hecha la instalación y se haya
realizado la aceptación del sistema. Aquí se incluirán los documentos necesarios para poder llevar a
cabo el mantenimiento y realizar tareas cotidianas sobre el sistema:
- Arranque del sistema.
- Parada del sistema.
- Habilitar/Deshabilitar servicios.
- Herramientas de gestión de los recursos.
2.3.8.- Actas de reuniones
Adicionalmente se crearán una serie de entregables derivados de las reuniones que se realizarán a
lo largo del ciclo de vida del proyecto. Estos serán las actas que se añadirán como anexo a la
memoria y que estarán compuestas por:
Fecha de la reunión.
Asistentes.
Temas tratados.
Temas concretados.
Estos documentos no serán definitivos a la fecha de entrega debido a que pueden ser susceptibles
a modificaciones a lo largo del ciclo de vida del proyecto. Estas modificaciones dependerán de si
hubiese algún cambio en alguna de las fases por detección de algún problema o cambio de alguno
de los requisitos.
2.4.- Alcance
El sistema debe cubrir las necesidades de alta disponibilidad garantizando la disponibilidad del
sistema al ser parte del entorno de producción de la empresa. Para ello, tras la implantación del
sistema y validar su funcionamiento, se deberán realizar pruebas de alta disponibilidad para
garantizar que los sistemas responden a las necesidades.
8
2.5.- Estructura de descomposición de tareas
- Contacto inicial.
o Primera reunión.
o Establecer objetivos y alcance.
o Buscar documentación.
- Análisis y diseño del sistema.
o Evaluación de alternativas y elección de la que se va a implantar.
o Requisitos hardware de la solución elegida.
o Estructura de la solución elegida.
- Implantación del sistema.
o Configuración hardware y storage.
o Instalación de los servidores.
o Configuración de la red.
o Instalación y configuración de librerías necesarias.
o Configuración Cluster Suite.
o Configuración Fencing.
o Configurar el dispositivo de fencing para cada servidor.
o Configuración del cluster para que utilice los dispositivos de fencing.
- Plan de pruebas.
o Infraestructura.
o Sistema de clúster.
o Aceptación.
- Documentación de la solución.
o Manual de explotación.
2.6.- Plan de trabajo
Se seguirá un plan de trabajo lineal pudiendo verse alterado por necesidades que surgiesen en la
empresa sobre la marcha. La finalización de la implementación debe estar finalizada para antes la
primera semana de Diciembre de 2011 para dejar a la empresa consultora un margen para hacer la
instalación del software del RP y posteriormente realizar las pruebas.
En la tabla siguiente se puede apreciar un calendario con las fechas estimadas para cada uno de los
hitos que han de producirse para una satisfactoria elaboración del proyecto.
Hito Fecha de finalización estimada Validación de la solución ofrecida
Diseño del sitema 31 de Octubre de 2011 Responsable de sistemas Cidacos
Implantación del sistema 25 de Noviembre de 2011 Responsable de sistemas Cidacos
Pruebas de alta disponibilidad 28, 29 y 30 de Noviembre de 2011 Responsable de sistemas Cidacos
9
2.7.- Riesgos
El principal riesgo que se puede producir para la realización del proyecto sería la necesidad por
parte de la empresa de dedicar tiempo a la realización de otras tareas que resulten críticas para el
desarrollo normal de la actividad de ésta. Por política de la empresa la parte más crítica sería la
paralización de las expediciones o de la producción de alguna de las líneas en cualquiera de las
fábricas del grupo.
2.8.- Costes
Esta instalación no supone costes adicionales para la empresa a nivel de hardware puesto que se va
a reutilizar material del que ya se dispone. A nivel de software habría que cubrir el gasto de
licencias del sistema operativo para cada uno de los servidores implicados además de el coste de
licencias del RP.
10
11
3.- Análisis y diseño del sistema
3.1.- Evaluación de alternativas
En este apartado se hará un estudio de las distintas alternativas junto a una breve explicación de
cada una de ellas para, posteriormente, elegir la más adecuada para el entorno que se pretende
implantar.
3.1.1.- Alternativa 1
Descripción:
En esta alternativa se dispone de dos servidores miembros del clúster. Cada uno de ellos se conecta
a la red a través de dos interfaces de red mediante una conexión redundante. A través de esa red
los usuarios se conectarán a los servicios publicados en el clúster y a su vez es la que utilizará el
propio clúster para intercambiarse los meta-datos necesarios para la gestión del mismo.
Cada uno de los servidores se conectarán a la cabina a través de dos interfaces de fibra óptica de
forma redundante de forma que si una de ellas fallase se pudiese acceder al almacenamiento
compartido a través de la otra.
Esta sería una alternativa válida ya que se dispone de lo siguiente:
- Conexiones de red redundantes para evitar la pérdida de servicio en un nodo por caída de
una interfaz de red.
- Conexiones de fibra hacia la cabina de almacenamiento redundantes para garantizar el
acceso a datos en caso de pérdida de alguno de los enlaces.
12
3.1.2.- Alternativa 2
Descripción:
En esta alternativa se dispone de dos servidores miembros del clúster. Cada uno de ellos se conecta
a la red a través de cuatro interfaces de red mediante dos conexiones redundante. Una de
esas conexiones redundantes irá conectada a la red pública (desde la que se conectan los
usuarios) y la otra irá conectada a una red privada que utilizará el propio clúster para
intercambiarse los meta-datos necesarios para la gestión del mismo.
Cada uno de los servidores se conectarán a la cabina a través de dos interfaces de fibra óptica de
forma redundante de forma que si una de ellas fallase se pudiese acceder al almacenamiento
compartido a través de la otra.
Esta sería una alternativa válida ya que se dispone de lo siguiente:
- Conexiones de red redundantes para evitar la pérdida de servicio en un nodo por caída de
una interfaz de red.
- Conexiones de fibra hacia la cabina de almacenamiento redundantes para garantizar el
acceso a datos en caso de pérdida de alguno de los enlaces.
- Se independiza el tráfico que genera el propio clúster para su gestión del tráfico necesario
para el acceso de los usuarios al sistema.
- Se reducen los puntos de error al disponer de dos interfaces de red adicionales para cada
uno de los servidores que harían un total de cuatro.
13
3.2.- Elección de la alternativa más válida
Tras valorar las distintas alternativas habría que destacar que la que ofrece más ventajas sobre la
otra es la segunda. Adicionalmente a esto es la opción recomendada por Red Hat, desarrollador de
la solución de clúster que se pretende instalar.
En cuanto a las necesidades de hardware no supondría unos costes adicionales al disponer en la
empresa de tarjetas de red duales para poder instalar en los servidores para satisfacer las
necesidades adicionales que requiere la alternativa 2 en comparación con la alternativa 1.
3.3.- Requisitos hardware de la alternativa elegida
Los requisitos de hardware para poder llevar a cabo la implantación de la alternativa 2 serían los
siguientes:
- Dos servidores para los nodos de clúster con los siguientes requisitos de hardware de red:
o 2 puertos Gigabit Ethernet integrados.
o 1 tarjeta adicional con 2 puertos Gigabit Ethernet.
o 1 tarjeta HBA con dos puertos para las conexiones de fibra óptica.
o Controladora remota para acceder a través de consola web a la interfaz del servidor,
así como a la gestión de energía.
- Dos o más switches Gigabit Ethernet con las siguientes características:
o Puedan funcionar de forma redundante.
o Permitan la creación de VLAN para separar el tráfico de distintas subredes.
- Dos switches de fibra óptica para la conectividad de los servidores con la cabina.
- Cabina de almacenamiento o SAN (Storage Area Network) para el almacenamiento
compartido que permita lo siguiente:
o Creación de particiones o LUNs (Logical Unit Numbers) para asignación a servidores.
o Gestión de acceso a las distintas particiones.
o Posibilidad de selección del nivel de RAID para los grupos de discos para tener
tolerancia a errores de disco.
14
- Latiguillos de red necesarios para las conexiones de red de los servidores. Éstos han de ser de
categoría 6 y debidamente certificados para garantizar un funcionamiento óptimo.
- Cables de fibra óptica necesarios para la conexión de los servidores y la SAN a los switches de
fibra óptica de forma redundante.
3.4.- Requisitos software de la alternativa elegida
Los requisitos software vienen impuestos por la aplicación clusterizada que se va a montar y que
formará parte del RP de la empresa. Las especificaciones para el software serían las siguientes:
- Sistema operativo: Oracle Enterprise Linux x86_64 (Versión 5 Update 5 por requerimientos del
kernel, posteriormente se pueden actualizar paquetes pero no el kernel del sistema que es el
certificado para la aplicación).
- Software multipath para conexión a la cabina: Nativo de UNIX – Device Mapper Multipath
(DM-MPIO). Permite el acceso redundante a las unidades de almacenamiento configuradas
para el servidor.
- Software de clúster: RedHat ClusterSuite: Permite la creación de clústers activo-pasivo en
plataformas Linux basadas en la distribución Red Hat que es lo que se pretende implantar.
o Gestión del clúster a través de interfaz web para gestión remota.
- Software adicional necesario:
o CUPS clusterizado para dar soporte a impresión de documentos.
o Samba clusterizado para el intercambio de ficheros con otros sistemas operativos.
o Módulo de lógica de negocio de JDEdwards que será instalado y configurado por una
empresa consultora externa especializada.
3.4.1.- Configuración del software
En este apartado se hará una breve descripción de la configuración del software para poder
cumplir con los objetivos del sistema.
3.4.1.1.- Sistema operativo
3.4.1.1.1.- Instalación del sistema operativo
El sistema operativo se ha de instalar siguiendo las recomendaciones de Oracle y Red Hat para
poder soportar el funcionamiento correcto tanto de JDEdwards como de ClusterSuite
respectivamente.
15
3.4.1.1.2.- Configuración de la red
Se han de configurar dos interfaces de red redundantes para el correcto funcionamiento del
sistema y además garantizar tolerancia a errores:
- Interfaz redundante para la red pública: Será en la que esté configurada la puerta de enlace
para el enrutamiento pues será a través de la cual accederán los usuarios.
- Interfaz redundante para la red privada: No estará enrutada. Será la que utilizará el software
de clúster para chequear el estado de los nodos y a través de la cual se hará el balanceo de los
servicios.
La resolución de nombres se puede realizar a través de un servidor DNS donde estén registradas las
entradas para cada servidor tanto por la red pública como privada. Oracle recomienda para la
solución registrar las entradas de forma manual para los servicios requeridos para el sistema. Por
ello se habrán de registrar las entradas para acceso público, para el acceso privado y para la
dirección IP virtual que levantará el clúster y que se mencionará posteriormente.
Se ha de configurar correctamente el nombre de la máquina para garantizar el correcto
funcionamiento del software instalado.
3.4.1.1.3.- Configuración de los drivers
Los drivers han de estar correctamente configurados para que el propio sistema sea capaz de
gestionar el hardware instalado en cada servidor de forma correcta.
3.4.1.2.- Configuración de multipath
Se ha establecido como requisito la utilización del software de multipath nativo de Linux (DM-
MPIO).
Cada servidor dispondrá de cuatro caminos de acceso a la cabina. Los discos a los que tenga acceso
cada sistema se verán por ello multiplicados por cuatro (un disco por cada camino del servidor a la
cabina para cada disco que ésta le presente). Con multipath se configura una ruta lógica para
acceso a cada uno de los discos y que gestiona el uso de cada uno de los caminos para acceder.
3.4.1.3.- Configuración de Red Hat Cluster Suite
El software utilizado para crear el clúster será Red Hat Clúster Suite. Para la configuración del
clúster se han de llevar a cabo los siguientes pasos:
3.4.1.3.1.- Instalación del clúster y configuración de paquetes
La instalación de los paquetes necesarios para el clúster se hará durante el proceso de instalación
del sistema operativo pero habrá que verificar que todos los paquetes están disponibles.
Una vez se ha verificado que los paquetes necesarios por el clúster están instalados en los
servidores habrá que configurarlos para el correcto funcionamiento y para permitir la gestión web
de éste.
16
3.4.1.3.2.- Creación del clúster
En esta fase lo que se hace es elegir el nombre que tendrá el clúster y se especifican los nodos que
formarán parte de éste.
3.4.1.3.3.- Gestión del número de votos
El clúster usa un sistema de votos para chequear la salud de éste. Cada uno de los nodos que es
visible por el propio clúster suma un voto. Para que el clúster pueda seguir funcionando
correctamente ha de tener como mínimo N/2+1 votos, siendo N el número de nodos que
pertenecen a éste.
Al disponer de un clúster de dos nodos, si en uno de ellos se produjese un fallo el número de votos
sería menor a la mitad de nodos más uno. Esto provocaría que el clúster dejase de funcionar
correctamente. Para ello se necesita un disco de quórum que lo que hace es añadir un voto
adicional para deshacer el empate.
El disco de quórum debe estar en almacenamiento compartido pues todos los nodos deben ser
capaces de verlo. Este disco ha de ser de no más de 100Mb y para configurarlo habría que seguir
los siguientes pasos:
- Crear la partición en el disco compartido. No necesita ser formateada.
- Inicialización del disco de quórum desde uno de los nodos. En esta parte se especifica la
partición del disco y se le establece un alias.
- Asignación del disco de quórum al clúster.
3.4.1.3.4.- Dominios de fail-over
Los dominios de fail-over son elementos donde se configuran los nodos pertenecientes al clúster
entre los cuales se podrá hacer el balanceo de los servicios. Por ejemplo, si se configura un servicio
y se le asigna un dominio de fail-over en el que está sólo uno de los nodos, si ese nodo fallase el
servicio nunca se balancearía al otro nodo.
En el dominio de fail-over se puede configurar la prioridad que tiene cada nodo a la hora de
levantar uno de los servicios configurados.
3.4.1.3.5.- Recursos
Los recursos son los elementos que formarán parte posteriormente de algún servicio. En este caso
se necesitarán los siguientes recursos para configurar el sistema:
- IP virtual: Dirección IP que apuntará al nodo que esté dando el servicio.
- Almacenamiento compartido: Se ha de configurar el almacenamiento con GFS2 que el sistema
de ficheros soportado y asignarlo a este recurso para que esté disponible para el nodo que
esté dando el servicio.
17
- CUPS clusterizado: Se ha de configurar CUPS de forma clusterizada para que esté activo en el
nodo que esté dando el servicio de forma que éste sea capaz de gestionar tanto las impresoras
como la cola de impresión.
- Samba clusterizado: Se ha de configurar Samba para que arranque en el nodo que está dando
el servicio. Samba no es clusterizable por lo que se ha de igualar la configuración en ambos
nodos.
3.4.1.3.6.-Servicios
Un servicio es un conjunto de recursos que puede servir uno de los nodos del clúster. En el servicio
se establecen las dependencias entre los distintos recursos, el dominio de fail-over con los nodos
que pueden dar el servicio y el comportamiento del servicio en caso de error de uno de los nodos.
3.4.1.3.7.- Fencing
El fencing es una parte fundamental del clúster. Es el encargado de comprobar la salud de cada uno
de los nodos del clúster y se encargará de reiniciar alguno de ellos en caso de que detecte que está
en un estado inconsistente o simplemente le es inaccesible.
Para este caso, se utilizarán las interfaces de gestión de los servidores que son las tarjetas DRAC
(Dell Remote Access Controller) y están soportadas para hacer esta misión.
3.5.- Estructura y desar rollo de la alternativa elegida
Una vez conocidos los requisitos hardware, se podría completar el diagrama de la alternativa 2 con
los distintos elementos para así disponer de un esquema de cómo quedaría el sistema una vez
implantado.
En el diagrama se incluirán los modelos de cada uno de los elementos que formarán parte del
sistema y posteriormente se hará una descripción de cada uno de ellos.
Lo primero se establecerá las necesidades de cada uno de los elementos de infraestructura
pertenecientes a la solución. Además se introducirán los términos necesarios para comprender el
funcionamiento final del sistema completo.
18
NOTAS:
- Las líneas azules son las conexiones de la red pública.
- Las líneas verdes son las conexiones de la red privada.
- Las líneas rojas son las conexiones de la red de gestión de dispositivos.
- Las líneas naranjas son las conexiones de fibra óptica.
3.5.1.- Switches Ethernet
Stack de switches Dell PowerConnect 6248.
3.5.1.1.- Características
- 6 switches conectados mediante cables de stacking en anillo que funcionan como si se tratase
de uno sólo y garantizan el funcionamiento si uno tuviese algún problema.
- Switches capa 2 con funcionalidades de capa 3 a través de software.
- Permiten la creación de VLANs para separar el tráfico de distintas subredes.
- Capacidad de enrutado entre distintas VLANs y enrutado a nivel de red.
19
3.5.1.2.- Descripción
Se han especificado seis switches redundantes conectados en anillo mediante cables de stacking
para la conexión de los cables de red puesto que es lo que hay instalado en la empresa. Para este
caso concreto solamente se hará uso de dos de ellos y requerirán la siguiente configuración:
3.5.1.2.1.- VLANs
Estos switches tienen funcionalidades de capa 2 por lo que permiten la creación de distintas VLAN
(virtual LAN) que son redes lógicamente independientes dentro de una misma red física. La
configuración de éstas quedará como sigue:
- VLAN 3 (INFRAESTRUCTURA): Es la VLAN general de la empresa que está enrutada y a través
de la cual se conectan los usuarios a los dispositivos de la infraestructura.
- VLAN 100 (GESTIÓN): Es la VLAN en la que se encuentran las direcciones de gestión de los
diferentes dispositivos. Está enrutada y permite separar el tráfico generado para la gestión del
general.
- VLAN 1100 (CLUSTERSUITE_1): Es la VLAN que usará el clúster para la red privada. No estará
enrutada por lo que el tráfico que se genere en ella sólo será accesible por los servidores
miembros del clúster.
3.5.1.2.2.- Puertos
En cuanto a los puertos hay que definir dos conceptos que serán necesarios para poder entender
las necesidades para cada uno de ellos a la hora de conectar los servidores.
- Cuatro puertos, dos en cada switch, pertenecientes a la VLAN 3 (INFRAESTRUCTURA) para la
conexión de los puertos que irán conectada a la red pública del clúster. Dos para cada uno de
los servidores.
- Cuatro puertos, dos en cada switch, pertenecientes a la VLAN 1100 (CLUSTERSUITE_1) para la
conexión de los puertos que irán conectados a la red privada del clúster. Dos para cada uno de
los servidores.
- Dos puertos, uno en cada switch, pertenecientes a la VLAN 100 (GESTIÓN) para la conexión de
las controladoras de la cabina de almacenamiento a red para gestionarla a través de red.
- Dos puertos, uno en cada switch, pertenecientes a la VLAN 100 (GESTIÓN) para la conexión de
la consola de gestión de los propios servidores a través de interfaz web (DRAC – Dell Remote
Access Controller).
- Dos puertos, uno en cada switch, pertenecientes a la VLAN 100 (GESTIÓN) para la conexión de
las interfaces de gestión de los switches de fibra y poder gestionarlos a través de la red.
20
3.5.2.- Servidores
Servidores: Dell PowerEdge 2950 III.
3.5.2.1.- Características
- 2 x QUAD-CORE XEON E5410 2.33GHZ.
- 4 x 4GB RAM 667MHZ FBD.
- PERC 6/I INTEGRADA CONTROLADORA RAID
- 4 x HDD 74GB 15K RPM SAS.
- BROADCOM DUAL PORT SERVER INTEGRATED.
- INTEL PRO 1000PT DUAL PORT SERVER ADAPTER.
- 2 x QLOGIC QLE2460, SINGLE PORT 4GB OPTICAL.
- 2 x 5M LC-LC CABLE DE FIBRA OPTICA.
- PE2950 III REDUNDANTE FUENTE DE ALIMENTACIÓN.
- DRAC 5 CARD (Dell Remote Access Controller).
3.5.2.2.- Descripción
En este apartado se hará una descripción de cómo debe estar configurado cada servidor. Se
especificará para uno de ellos siendo extensible para el otro.
3.5.2.2.1.- Almacenamiento local
Cada servidor dispone de cuatro discos duros físicos disponibles para almacenamiento local y una
controladora RAID para poder establecer discos lógicos. Esto permite agrupar los discos entre ellos
para así poder garantizar una tolerancia a errores. La configuración quedará como sigue:
- Unidad de almacenamiento lógico 1 (LUN1): Estará configurada para garantizar tolerancia a
errores utilizando RAID 1 (Mirror) utilizando 2 de los discos. Con esto se reduce la capacidad
de almacenamiento a la mitad de la disponible pero se garantiza la continuidad de servicio en
caso de que uno de los discos falle.
- Unidad de almacenamiento lógico 2 (LUN2): Estará configurada para garantizar tolerancia a
errores utilizando RAID 1 (Mirror) utilizando 2 de los discos. Con esto se reduce la capacidad
de almacenamiento a la mitad de la disponible pero se garantiza la continuidad de servicio en
caso de que uno de los discos falle.
21
3.5.2.2.2.- Conexiones de red
Como se especifica en la sección de características, se dispone de dos adaptadores de red duales
(Una de la marca Broadcom integrada y una tarjeta adicional de la marca Intel conectada a una
ranura PCI-e). Físicamente se dispone de cuatro conexiones de red que se repartirán de la
siguiente forma para garantizar tolerancia a errores de uno de los adaptadores que afectaría a las
dos conexiones de red:
- Una conexión de red del adaptador Broadcom integrado + una conexión de red del adaptador
Intel formarán parte de la conexión a la red pública del clúster.
- La otra conexión de red del adaptador Broadcom + la otra conexión de red del adaptador Intel
formarán parte de la conexión a la red privada del clúster.
Los adaptadores de red son Gigabit Ethernet por lo que permiten conexiones a una velocidad de
1Gbps. Para garantizar que no hay pérdida de rendimiento en las conexiones se utilizarán cables
de red de categoría 6 apantallados para evitar interferencias.
3.5.2.2.3.- Conexiones de fibra óptica
Cada servidor dispone de dos adaptadores de fibra óptica de la marca QLogic de los cuales cada
uno dispone de una conexión de fibra (HBA). Los cables utilizados serán con conectores LC que son
los que se necesitan para poder establecer las conexiones entre las HBA y los switches de fibra
óptica. Al disponer de dos adaptadores de fibra se garantiza alta disponibilidad tanto a nivel de
adaptador como de conector.
En cuanto a la conexión de los cables de fibra a los switches deberá hacerse de la siguiente forma
para garantizar la redundancia:
- Cable de fibra del conector 1 (HBA1): Deberá ir conectado al primero de los switches de fibra.
A través de la configuración de las zonas del switch será capaz de establecer conexión con los
dos extremos de la cabina conectados a ese mismo switch.
- Cable de fibra del conector 2 (HBA2): Deberá ir conectado al segundo de los switches de fibra.
A través de la configuración de las zonas del switch será capaz de establecer conexión con los
dos extremos de la cabina conectados a ese mismo switch.
3.5.2.2.4.- Alimentación eléctrica
Cada servidor dispone de una doble fuente de alimentación. Para maximizar la disponibilidad del
sistema cada una de ellas debe estar conectada a un sistema de alimentación ininterrumpida (SAI)
diferente. Con esto se consigue doble tolerancia, la primera a nivel de fuente de alimentación y la
segunda a nivel de la entrada de alimentación externa al servidor.
3.5.2.2.5.- Controladora remota
Cada servidor dispone de un adaptador de acceso remoto al servidor. Esta tarjeta permite
controlar el servidor de forma remota como si se estuviese conectado directamente a la consola
del servidor con un monitor, teclado y ratón. Adicionalmente servirá para la gestión de energía de
22
los servidores por parte del clúster en caso de que alguno de los nodos se quede inaccesible. Para
poder hacer uso de ella debe cumplir lo siguiente:
- Este adaptador se conecta mediante red a los switches en la VLAN correspondiente a GESTIÓN
(Mencionada con anterioridad en el apartado de los switches Ethernet).
- Direccionamiento IP estático que debe estar configurado con la puerta de enlace
correspondiente de la subred de gestión para que sea accesible.
3.5.3.- Switches fibra óptica
Brocade Silkworm 200E.
3.5.3.1.- Características
- Permiten la creación de alias para identificar las conexiones por nombre y no por identificador
de la tarjeta (WWN).
- Permiten la creación de zonas para gestionar qué dispositivos son capaces de establecer
conexión entre ellos con independencia del puerto en que se conecten.
3.5.3.2.- Descripción
Los switches de fibra se encargarán de la comunicación de los servidores con la cabina de
almacenamiento, de forma que cada servidor sea capaz de ver las controladoras. Para ello las
conexiones de fibra a los switches deben estar repartidas de la siguiente forma para garantizar alta
disponibilidad:
- Conexiones al switch de fibra 1:
o Una tarjeta de fibra del nodo 1.
o Una tarjeta de fibra del nodo 2.
o Un puerto de la controladora A de la cabina.
o Un puerto de la controladora B de la cabina.
- Conexiones al switch de fibra 2.
o Una tarjeta de fibra del nodo 1.
o Una tarjeta de fibra del nodo 2.
o Un puerto de la controladora A de la cabina.
o Un puerto de la controladora B de la cabina.
23
Al distribuir los puertos de esta manera se consigue disponer de cuatro caminos para acceder a la
cabina de almacenamiento para cada servidor. Si fallase uno solo de los componentes esta solución
garantizará el acceso a la cabina de almacenamiento por lo menos por dos caminos.
3.5.3.2.1.- Puertos
Este tipo de switches permiten independizar la configuración del puerto al que se conectan los
dispositivos mediante la utilización de la funcionalidad de los switches de crear alias y zonas.
3.5.3.2.2.- Alias
Los alias lo que hacen es definir un nombre a un determinado dispositivo identificado por su
identificador único (WWN). Se deberán configurar tantos alias como dispositivos implicados para
poder identificarlos de forma más sencilla.
3.5.3.2.3.- Zonas
Las zonas permiten establecer qué dispositivos son capaces de comunicarse entre sí. Para ello se
utilizan los alias que deben haber sido creados con anterioridad. Se necesitarán tantas zonas como
pares de dispositivos que necesitan conectarse entre sí, en este caso para el primero de los
switches quedaría como sigue:
- Zona 1.
o Tarjeta 1 de fibra del nodo 1.
o Puerto 1 controladora A de la cabina.
- Zona 2.
o Tarjeta 1 de fibra del nodo 1.
o Puerto 1 controladora B de la cabina.
- Zona 3.
o Tarjeta 1 de fibra del nodo 2.
o Puerto 1 controladora A de la cabina.
- Zona 4.
o Tarjeta 1 de fibra del nodo 2.
o Puerto 1 controladora B de la cabina.
De esta forma se permite que la tarjeta de cada servidor sea capaz de acceder a los puertos de las
controladoras de la cabina que están conectados al mismo switch. Con esto se consigue
independizar por completo el puerto en el que se conecte cada dispositivo siempre que estén
conectados al mismo switch.
24
Para el otro switch la configuración de zonas sería exactamente igual pero con la tarjeta 2 de fibra
de cada servidor y los puertos 2 de cada una de las controladoras de la cabina.
3.5.4.- Cabina de almacenamiento (SAN)
Dell EMC cx3-10c.
3.5.4.1.- Características
La cabina se encargará de facilitar el almacenamiento compartido para ambos servidores y
gestionar el acceso al mismo.
- Permite registrar los servidores que accederán a la cabina de almacenamiento.
- Permite generar distintos Raid Groups que serán grupos de discos que comparten el mismo
nivel de RAID. Nivel físico.
- Permite crear distintas LUN (Logical Unit Number) que son particiones que se hacen a los Raid
Groups. Nivel lógico.
- Permite gestionar el acceso de los servidores registrados a las distintas LUN mediante una
asignación explícita utilizando los Storage Groups.
- Permite gestionar el modo de acceso de los servidores a la cabina.
o Modo activo-pasivo: Los servidores podrán acceder al almacenamiento por una de las
controladoras, en caso de que ésta fallase entraría en funcionamiento la conexión a
través de la otra.
o Modo activo-activo: Los servidores podrán acceder simultáneamente a través de las
dos controladoras de modo concurrente.
3.5.4.2.- Descripción
Para el acceso de los servidores a la cabina habrá que configurar cada uno de los elementos
mencionados en el apartado anterior.
3.5.4.2.1.- Registro de servidores en la cabina
El registro para los servidores se hará mediante un paquete certificado por el fabricante para
Oracle Enterprise Linux que se encarga de establecer la comunicación con la cabina
automáticamente para registrarse con ella. Este paquete es el denominado “Navisphere agent” que
se encarga de registrar el host en la cabina y le proporciona el nombre del servidor y
automáticamente gestiona el acceso.
25
3.5.4.2.2.- Raid Group
Para este caso será necesaria la creación de un Raid Group con un nivel de RAID 10 para permitir
tolerancia a fallos de disco que proporciona el RAID 1 y permitir la escritura en paralelo de los datos
que proporciona el RAID 0.
3.5.4.2.3.- LUNs (Logical Unit Numbers)
El sistema necesitará dos LUNs presentadas a los servidores para poder configurar lo necesario
para el correcto funcionamiento del sistema:
- LUN para el disco de quórum: Será necesario para montar el disco de quórum que requerirá la
solución de clúster.
- LUN para el almacenamiento compartido: Sobre esta LUN se hará la instalación de los servicios
clusterizados para que sean accesibles desde ambos nodos.
3.5.4.2.4.- Storage Group
Se debe definir un Storage Group para poder definir el acceso de ambos servidores a las LUN
mencionadas en el apartado anterior. Para ello se creará un elemento de este tipo en el que
aparecerán:
- Nodo 1.
- Nodo 2.
- LUN para el disco de quórum.
- LUN para el almacenamiento compartido.
3.5.4.2.5.- Modo de acceso de los servidores
El modo de acceso de los servidores a la cabina será de modo activo-activo mediante el uso del
algoritmo de round-robin pues es el recomendado para este caso.
Para establecer este modo de acceso habrá que hacerlo de forma explícita para cada uno de los
servidores pues el modo por defecto para el acceso a la cabina es activo-pasivo.
26
27
4.- Implantación del sistema
Este documento abarca todo el proceso de implantación del sistema para poder ponerlo en
producción. Para poder llevar a cabo dicha implantación de forma óptima hay que evaluar el orden
en el que llevar a cabo cada una de las tareas para llegar a componer el sistema totalmente
configurado.
- La primera fase a realizar es la asignación de recursos para los servidores e interfaces de
gestión, pues se necesita conocer dónde se va a conectar cada uno de los cables con el fin de
configurar los distintos puertos para cada uno de los dispositivos.
- A continuación se hará la instalación del sistema operativo en los servidores para poder
verificar la configuración y verificación de cada uno de los elementos.
- Una vez instalado el sistema se deberán configurar los puertos de los switches de red para
poder posteriormente configurar las conexiones de los servidores y la gestión de los
dispositivos.
- Lo siguiente es configurar los alias y las zonas en los switches de fibra óptica para permitir el
acceso a través de fibra óptica de los servidores a la cabina de almacenamiento.
- La siguiente fase será la instalación del paquete para registrar los servidores con la cabina de
almacenamiento para poder proceder a la configuración del almacenamiento compartido en la
misma.
- Por último habrá que instalar y configurar las librerías necesarias y el software de clúster así
como los recursos y servicios gestionados por éste.
A continuación se hará una descripción con más detalle de cada una de las fases.
4.1.- Asignación de recursos a los servidores e interfaces de gestión
4.1.1.- Nodo 1 del clúster
Nombre gestión: ENT900PD00
Hostname: ENT900PD
Tarjetas de red:
o Integrada, puerto 1: Módulo 4 switches redundantes, puerto 9.
o Integrada, puerto 2: Módulo 4 switches redundantes, puerto 10.
o PCI, puerto 1: Módulo 6 switches redundantes, puerto 9.
o PCI, puerto 2: Módulo 6 switches redundantes, puerto 10.
28
Tarjetas de fibra:
o Tarjeta 1, puerto 1: Switch de fibra 1, puerto 6.
o Tarjeta 2, puerto 1: Switch de fibra 2, puerto 6.
Tarjeta DRAC (Dell Remote Access Controller): Módulo 6 switches redundantes, puerto 41.
Fuentes de alimentación:
o Fuente de alimentación 1: SAI 1.
o Fuente de alimentación 2: SAI 2.
4.1.2.- Nodo 2 del clúster
Nombre gestión: ENT900PD01
Hostname: ENT900PD
Tarjetas de red:
o Integrada, puerto 1: Módulo 4 switches redundantes, puerto 11.
o Integrada, puerto 2: Módulo 4 switches redundantes, puerto 12.
o PCI, puerto 1: Módulo 6 switches redundantes, puerto 11.
o PCI, puerto 2: Módulo 6 switches redundantes, puerto 12.
Tarjetas de fibra:
o Tarjeta 1, puerto 1: Switch de fibra 1, puerto 7.
o Tarjeta 2, puerto 1: Switch de fibra 2, puerto 7.
Tarjeta DRAC (Dell Remote Access Controller): Módulo 4 switches redundantes, puerto 41.
Fuentes de alimentación:
o Fuente de alimentación 1: SAI 1.
o Fuente de alimentación 2: SAI 2.
4.1.3.- Switch de fibra 1
Nombre gestión: sw29
Hostname: sw29
Tarjeta de gestión: Módulo 4 switches redundantes, puerto 44.
29
4.1.4.- Switch de fibra 2
Nombre gestión: sw30
Hostname: sw30
Tarjeta de gestión: Módulo 6 switches redundantes, puerto 44.
4.1.5.- Controladora A de la cabina de almacenamiento
Nombre gestión: trancosa
Hostname: trancos
Tarjeta de gestión: Módulo 4 switches redundantes, puerto 39.
4.1.6.- Controladora B de la cabina de almacenamiento
Nombre gestión: trancosb
Hostname: trancos
Tarjeta de gestión: Módulo 6 switches redundantes, puerto 39.
4.2.- Instalación del sistema operativo en los servidores
La instalación del sistema operativo se hará desde cero. Partimos de servidores sin sistema
operativo instalado, por lo que hay que hacer la instalación nueva.
El sistema operativo requerido será Oracle Enterprise Linux 5 Update 5 de arquitectura de 64 bits
(x86_64).
El proceso de instalación está especificado en el anexo I.
Una vez finalizada la instalación en cada uno de los servidores se dispone del sistema operativo en
ambos para poder comenzar con la configuración de éste y la posterior instalación y configuración
del software necesario.
4.3.- Configuración de la red
4.3.1.- Configuración de los puertos de los switches
Lo primero que hay que hacer es definir las distintas VLAN que se van a necesitar para configurar la
red tanto de los servidores como de los dispositivos.
30
vlan database
vlan 1,10,110
exit
Una vez se han definido, hay que configurar las características que han de tener cada una de dichas
VLAN.
interface vlan 1
name “GENERAL”
routing
ip address 192.168.10.1 255.255.255.0
exit
interface vlan 10
name "GESTION"
routing
ip address 192.168.47.2 255.255.255.0
exit
interface vlan 110
name "CLUSTERSUITE_1"
exit
Con esta configuración se conseguirá tener configuradas las tres VLAN necesarias con las siguientes
características:
- VLAN 1 Capaz de enrutar tráfico Dirección IP: 192.168.10.1/24 (Será el Gateway de la
subred).
- VLAN 10 Capaz de enrutar tráfico Dirección IP: 192.168.47.2/24 (Será el Gateway de la
subred).
- VLAN 110 El tráfico de esta VLAN no será enrutado No tiene dirección IP.
Una vez configuradas las VLAN, hay que configurar los distintos puertos que se han asignado
previamente para poder conectar cada una de las interfaces de red a los switches en su VLAN
correspondiente.
El patrón de configuración para cada uno de los puertos es el siguiente:
interface ethernet <núm_módulo>/g<núm_puerto>
description '<descripción>'
switchport access vlan <núm_vlan_asignada>
exit
31
Siguiendo este patrón los puertos quedarán configurados de la siguiente manera:
interface ethernet 4/g9
description 'ENT900PD00_BOND0-ETH0'
switchport access vlan 1
exit
interface ethernet 4/g10
description 'ENT900PD00_BOND1-ETH1'
switchport access vlan 110
exit
interface ethernet 4/g11
description 'ENT900PD01_BOND0-ETH0'
switchport access vlan 1
exit
interface ethernet 4/g12
description 'ENT900PD01_BOND1-ETH1'
switchport access vlan 110
exit
interface ethernet 4/g39
description 'CX310C_SPA'
switchport access vlan 10
exit
interface ethernet 4/g41
description 'DRAC_ENT900PD01'
switchport access vlan 10
exit
interface ethernet 4/g44
description 'SW29_FC_GESTION'
switchport access vlan 10
exit
interface ethernet 6/g9
description 'ENT900PD00_BOND0-ETH2'
switchport access vlan 1
exit
interface ethernet 6/g10
description 'ENT900PD00_BOND1-ETH3'
switchport access vlan 110
exit
interface ethernet 6/g11
description 'ENT900PD01_BOND0-ETH2'
switchport access vlan 1
exit
interface ethernet 6/g12
description 'ENT900PD01_BOND1-ETH3'
switchport access vlan 110
exit
32
interface ethernet 6/g39
description 'CX310C_SPB'
switchport access vlan 10
exit
interface ethernet 6/g41
description 'DRAC_ENT900PD00'
switchport access vlan 10
exit
interface ethernet 6/g44
description 'SW30_FC_GESTION'
switchport access vlan 10
exit
4.3.2.- Configuración del direccionamiento IP de dispositivos
4.3.2.1.- Switches de fibra óptica
Se han de configurar los switches de fibra óptica para poder gestionarlos correctamente. Por
defecto estos switches están configurados con una dirección IP estática de fábrica. Para acceder a
ellos se hace a través de interfaz web conectando a dicha dirección para poder cambiar la
configuración.
En la ventana de administración hay que seleccionar la opción “Switch Admin” del menú izquierdo
para acceder a la ventana de configuración.
En la ventana de configuración hay que acceder a la pestaña “Network” para cambiar las opciones
de IP que vienen por defecto. La configuración de cada uno de los switches quedaría como sigue:
33
34
4.3.2.2.- Cabina de almacenamiento
Para configurar las interfaces de gestión de la cabina de almacenamiento hay que acceder a través
de la interfaz web a la dirección IP que por defecto es asignada de forma dinámica por DHCP.
Una vez en la interfaz hay que desplegar las opciones de la matriz y aparecerán las dos
controladoras (SPA y SPB). Hay que pulsar con el botón derecho sobre cada una de ellas y darle a
propiedades. Los parámetros de red se establecen en la pestaña Network.
Las direcciones IP de las controladoras quedarán configuradas como sigue:
4.3.3.- Configuración de las interfaces de red de los servidores
La configuración de la red de los servidores se hará mediante una interfaz redundante para cada
una de las conexiones que necesita (pública/privada). Para ello se utilizarán “bondings” para
agrupar varias interfaces físicas para que se comporten como una única interfaz lógica.
Al disponer de dos adaptadores con dos puertos de red cada uno de ellos se seleccionará un puerto
de cada uno de los adaptadores para cada interfaz redundante para así disponer tolerancia a
errores del adaptador.
Para asignar cada una de las interfaces físicas a cada una de las interfaces redundantes hay que
identificar la dirección física (MAC address) para definirlas en los ficheros de configuración.
Los ficheros de configuración de la red están localizados en /etc/sysconfig/network-scripts y
quedarían como sigue:
35
4.3.3.1.- ENT900PD00
4.3.3.1.1.- Ifcfg-bond0
DEVICE=bond0
BOOTPRO=static
ONBOOT=yes
IPADDR=192.168.10.24
NETMASK=255.255.255.0
GATEWAY=192.168.10.1
PEERDNS=no
USERCTL=no
BONDING_OPTS="mode=0 miimon=100"
TYPE=BOND
BOOTPROTO=none
4.3.3.1.2.- Ifcfg-bond1
DEVICE=bond1
BOOTPRO=static
ONBOOT=yes
IPADDR=10.0.2.2
NETMASK=255.255.255.0
PEERDNS=no
USERCTL=no
BONDING_OPTS="mode=0 miimon=100"
TYPE=BOND
BOOTPROTO=none
4.3.3.1.3.- Ifcfg-eth0
# Broadcom Corporation NetXtreme II BCM5708 Gigabit Ethernet
DEVICE=eth0
BOOTPROTO=none
HWADDR=00:1E:C9:D6:FE:32
ONBOOT=yes
TYPE=Ethernet
USERCTL=no
IPV6INIT=no
PEERDNS=no
MASTER=bond0
SLAVE=yes
4.3.3.1.4.- Ifcfg-eth1
# Broadcom Corporation NetXtreme II BCM5708 Gigabit Ethernet
DEVICE=eth1
BOOTPROTO=none
HWADDR=00:1E:C9:D6:FE:34
ONBOOT=yes
TYPE=Ethernet
USERCTL=no
IPV6INIT=no
PEERDNS=no
MASTER=bond1
SLAVE=yes
36
4.3.3.1.5.- Ifcfg-eth2
# Intel Corporation 82571EB Gigabit Ethernet Controller
DEVICE=eth2
BOOTPROTO=none
HWADDR=00:15:17:7B:6F:A2
ONBOOT=yes
TYPE=Ethernet
USERCTL=no
IPV6INIT=no
PEERDNS=no
MASTER=bond0
SLAVE=yes
4.3.3.1.6.- Ifcfg-eth3
# Intel Corporation 82571EB Gigabit Ethernet Controller
DEVICE=eth3
BOOTPROTO=none
HWADDR=00:15:17:7B:6F:A3
ONBOOT=yes
TYPE=Ethernet
USERCTL=no
IPV6INIT=no
PEERDNS=no
MASTER=bond1
SLAVE=yes
4.3.3.2.- ENT900PD01
4.3.3.2.1.- Ifcfg-bond0
DEVICE=bond0
BOOTPRO=static
ONBOOT=yes
IPADDR=192.168.10.25
NETMASK=255.255.255.0
GATEWAY=192.168.10.1
PEERDNS=no
USERCTL=no
BONDING_OPTS="mode=0 miimon=100"
TYPE=BOND
BOOTPROTO=none
4.3.3.2.2.- Ifcfg-bond1
DEVICE=bond1
BOOTPRO=static
ONBOOT=yes
IPADDR=10.0.2.3
NETMASK=255.255.255.0
PEERDNS=no
USERCTL=no
BONDING_OPTS="mode=0 miimon=100"
TYPE=BOND
BOOTPROTO=none
37
4.3.3.2.3.- Ifcfg-eth0
# Broadcom Corporation NetXtreme II BCM5708 Gigabit Ethernet
DEVICE=eth0
BOOTPROTO=none
HWADDR=00:1E:C9:D6:FE:42
ONBOOT=yes
TYPE=Ethernet
USERCTL=no
IPV6INIT=no
PEERDNS=no
MASTER=bond0
SLAVE=yes
4.3.3.2.4.- Ifcfg-eth1
# Broadcom Corporation NetXtreme II BCM5708 Gigabit Ethernet
DEVICE=eth1
BOOTPROTO=none
HWADDR=00:1E:C9:D6:FE:44
ONBOOT=yes
TYPE=Ethernet
USERCTL=no
IPV6INIT=no
PEERDNS=no
MASTER=bond1
SLAVE=yes
4.3.3.2.5.- Ifcfg-eth2
# Intel Corporation 82571EB Gigabit Ethernet Controller
DEVICE=eth2
BOOTPROTO=none
HWADDR=00:15:17:7B:6F:B2
ONBOOT=yes
TYPE=Ethernet
USERCTL=no
IPV6INIT=no
PEERDNS=no
MASTER=bond0
SLAVE=yes
4.3.3.2.6.- Ifcfg-eth3
# Intel Corporation 82571EB Gigabit Ethernet Controller
DEVICE=eth3
BOOTPROTO=none
HWADDR=00:15:17:7B:6F:B3
ONBOOT=yes
TYPE=Ethernet
USERCTL=no
IPV6INIT=no
PEERDNS=no
MASTER=bond1
SLAVE=yes
38
4.3.3.3.- Resolución de nombres
Hay que añadir la configuración de los servidores DNS y el dominio en el que buscarlos para cada
uno de los servidores dentro del fichero /etc/resolv.conf
search cidacos.com
nameserver 192.168.10.12
nameserver 192.168.10.13
nameserver 192.168.16.2
Hay determinados hosts cuya resolución de nombres es crítica por lo que se añadirán de forma
estática en cada uno de los servidores al fichero /etc/hosts
127.0.0.1 localhost.localdomain localhost
192.168.10.67 ENT900PD ENT900PD.cidacos.com
192.168.10.24 ENT900PD00 ENT900PD00.cidacos.com
192.168.10.25 ENT900PD01 ENT900PD01.cidacos.com
10.0.2.2 ENT900PD00-priv
10.0.2.3 ENT900PD01-priv
4.3.3.4.- Modificación de parámetros generales de red
Adicionalmente hay que añadir las siguientes líneas al fichero /etc/modprobe.conf para indicar al
sistema la existencia de las interfaces virtuales de bonding.
alias bond0 bonding
alias bond1 bonding
Una vez realizados todos los cambios hay que forzar un reinicio de los servicios de red en cada uno
de los servidores para que se establezca la nueva configuración:
service network restart
4.4.- Configuración de los switches de fibra óptica
4.4.1.- Configuración de los alias
Para facilitar la configuración del acceso de los servidores a la cabina de almacenamiento, surge la
necesidad de crear alias. Un alias es la asignación de un nombre lógico a una interfaz de fibra óptica
a través de su identificador único (WWN).
Lo primero que se necesita es localizar el identificador de cada una de las interfaces. Esto se puede
hacer conectando el puerto al switch y consultando el identificador en la interfaz de éste.
39
Siguiendo el procedimiento mencionado anteriormente se obtienen los siguientes identificadores:
Servidor Conexión de fibra Identificador
ENT900PD00 Tarjeta 1 21:00:00:1b:32:12:9f:d5
ENT900PD00 Tarjeta 2 21:00:00:1b:32:12:b9:e4
ENT900PD01 Tarjeta 1 21:00:00:1b:32:12:c1:df
ENT900PD01 Tarjeta 2 21:00:00:1b:32:12:b0:d6
CX3-10c Controladora A – Puerto 1 50:06:01:61:41:e0:ce:6d
CX3-10c Controladora A – Puerto 2 50:06:01:60:41:e0:ce:6d
CX3-10c Controladora B – Puerto 1 50:06:01:68:41:e0:ce:6d
CX3-10c Controladora B – Puerto 2 50:06:01:69:41:e0:ce:6d
Para establecer los alias hay que acceder a la interfaz web de gestión utilizando la dirección IP
previamente configurada. Hay que seleccionar la opción “Zone Admin” que es donde se encuentra
la configuración de los alias.
En la pestaña alias hay que seleccionar la opción “New Alias”.
40
Una vez especificado el nombre pulsar sobre el botón OK para proceder a configurar el dispositivo
a dicho alias.
Seleccionar del desplegable de la izquierda el dispositivo que tiene el identificador que ya se ha
localizado previamente y agregarlo al alias mediante el botón “Add Member”.
Hay que repetir este proceso para todos y cada uno de los puertos de fibra utilizados tanto por los
servidores como por la cabina conectados a ese switch.
41
Una vez se ha finalizado la configuración hay que guardar los cambios para que los aplique al
sistema y para hacerlos persistentes al reinicio del switch. Esto se hace en el menú “Zoning
Actions” en la opción “Save Config”.
Se ha de repetir el mismo proceso para el otro switch de fibra óptica con lo que quedarían todos los
alias configurados para configurar posteriormente las zonas.
4.4.2.- Configuración de las zonas
Una vez se han configurado los alias se puede identificar más facilmente cada dispositivo ya que
permite la creación de las zonas utilizando los nombres asignados a cada interfaz.
Con las zonas se establece la conectividad entre cada una de las interfaces de fibra de los
servidores con cada una de las interfaces de la cabina. Por ello en cada zona habrá que configurar:
o Una interfaz de un servidor identificada por su alias.
o Una interfaz de la cabina identificada por su alias.
Siguiendo esta metodología habrá que configurar en cada switch cuatro zonas de las cuales se
detallará el proceso para crear una de ellas y habría que repetir el proceso para las restantes.
Acceder a la interfaz web de gestión del switch de fibra a través de la dirección IP especificada
anteriormente y entrar en “Zone config” para acceder a la creación de zonas.
42
Las zonas se configuran en la pestaña “Zones” donde hay que pulsar sobre el botón “New Zone”
para crear una nueva zona.
Tras introducir el nombre de la zona pulsar sobre el botón “OK” para poder proceder a configurar
los alias que pertenecen a ella.
43
Para agregar los alias que pertenecerán a cada zona hay que desplegar la opción de “Aliases” en el
bloque izquierdo y tras seleccionarlos pulsar sobre el botón “Add Member”.
Una vez se ha finalizado la configuración hay que guardar los cambios para que los aplique al
sistema y para hacerlos persistentes al reinicio del switch. Esto se hace en el menú “Zoning
Actions” en la opción “Save Config”.
Se ha de repetir el mismo proceso para el otro switch de fibra óptica con lo que quedarían
configuradas todas las zonas.
44
4.5.- Configuración del acceso al a lmacenamiento de los servidores
4.5.1.- Instalación de paquetes necesarios para a lmacenamiento en los servidores
Para registrar los servidores con la cabina es necesario instalar un paquete que se puede descargar
desde la página del proveedor de la cabina, EMC. Para la descarga se necesita una cuenta de acceso
válida.
El paquete es el llamado agente de Navisphere (naviagentcli-6.26.31.2.62-1.noarch.rpm). Este
paquete no necesita configuración adicional por lo que sólo es necesario instalarlo utilizando el
siguiente comando:
rpm -ivh naviagentcli-6.26.31.2.62-1.noarch.rpm
Una vez instalado en ambos servidores, aparecerán dentro de la pestaña “Hosts” en la consola de
gestión de la cabina.
4.5.2.- Creación del raid group en la cabina de almacenamiento
Toda la configuración de la cabina se hace a través de la interfaz web de gestión de la cabina
utilizando la dirección IP de gestión de cualquiera de las controladoras.
El primer paso para crear el almacenamiento compartido es crear un RAID Group que está formado
por un grupo de discos en los que se ha especificado un nivel RAID.
Para crear el RAID hay que seleccionar con el botón derecho la opción “Raid Groups” y seleccionar
la opción “Create Raid Group”.
45
En la ventana que aparece hay que seleccionar el tipo de RAID que se desea que tenga que en este
caso sería RAID 10 para disponer de escritura en paralelo a disco y tolerancia a errores.
Una vez elegido el nivel de RAID hay que seleccionar los discos que pertenecerán al “Raid Group” y
sobre los que se montará el almacenamiento.
Una vez creado, en el desplegable aparecerá el Raid Group creado junto con los discos que se le
han asignado. La creación no es instantánea pues la cabina tiene que dar formato a los discos de
forma que sean capaces de soportar el nivel de RAID deseado.
46
4.5.3.- Creación de las LUNs que se asignarán a los servidores
Las LUN son las unidades lógicas de almacenamiento que se asignarán a los servidores. Cada LUN
debe pertenecer a un raid group que definirá el nivel de RAID que deberá tener.
Para crear una LUN hay que seleccionar el RAID Group en el que se desea crear y elegir la opción
“Bind LUN”.
Las opciones de nivel de RAID y el RAID Group al que pertenecerá vienen implícitas en la
configuración, sólo hay que seleccionar el tamaño que tendrá y la controladora propietaria de
dicha LUN (Por recomendación del fabricante se debe seleccionar una controladora y no ponerla en
modo automático).
Para el sistema se van a crear dos LUN, la primera será la asignada para el almacenamiento
compartido de 300Gb y la segunda será utilizada para el disco de quórum para el clúster de 100Mb.
La configuración queda como sigue:
47
Una vez creadas las LUN aparecerán en el desplegable del RAID Group.
4.5.4.- Creación del storage group p ara dar acceso a los servidores
Los storage groups establecen los permisos de acceso de los servidores a las LUN creadas en la
cabina. Por ello cada storage group estará formado por una o varias LUNS y uno o varios servidores
que tendrán acceso a ellas.
Para crear un storage group hay que pulsar sobre la opción “Storage Groups” y seleccionar la
opción “Create Storage Group”.
48
Se ha de elegir el nombre que tendrá el storage group y que sirva posteriormente para la fácil
identificación de los permisos que contendrá.
Para establecer las asociaciones hay que entrar en las propiedades del storage group donde
aparecerán tres pestañas:
- En la pestaña “General” se puede cambiar el nombre del storage group en cualquier
momento.
- En la pestaña “LUNs” se establecen las distintas LUN a las que se va a dar acceso.
49
- En la pestaña “Hosts” se establecen los servidores que tendrán acceso a las LUN definidas
en la pestaña “LUNs”.
4.5.5.- Configuración del modo de acceso de los servidores a la cabina
La última parte de configuración a nivel de la cabina es la del modo de acceso de los servidores a la
cabina. El modo de acceso de los servidores a la cabina será en modo activo-activo por lo que habrá
que definirles ese tipo de acceso.
Esta opción se encuentra en el menú “Tools” en la opción “Failover Setup Wizard” que nos
mostrará un asistente de configuración.
50
En el asistente hay que seleccionar el servidor al que se aplicará la configuración de acceso.
El siguiente paso es seleccionar la cabina a la que accede el servidor. En este caso se dispone de
una sola cabina.
51
En la última parte del asistente hay que seleccionar el tipo de conector que para sistemas Linux
será “CLARiiON Open”, el modo de acceso será 4 que según la documentación es el que define la
cabina como activo-activo y si se va a establecer permiso a los servidores para comunicar con la
cabina.
4.6.- Instalación y configuración de software
4.6.1.- Instalación de los paquetes necesarios
Lo primero que hay que configurar en cada uno de los servidores son los repositorios a los que será
capaz de conectarse para buscar nuevos paquetes y actualizaciones de los existentes.
El procedimiento de configuración está documentado por Oracle en el siguiente documento:
http://public-yum.oracle.com/
Hay que seguir los pasos para Enterprise Linux 5 y, en el paso de configurar los repositorios,
habilitar los que terminan en 5_5base, latest y addons. Al habilitarlos se tendrá acceso a los
binarios de la instalación de Oracle Enterprise Linux 5, a las últimas versiones de paquetes
disponibles y a paquetes adicionales para poder acceder a determinadas herramientas
respectivamente.
52
El siguiente paso sería instalar actualizaciones de los paquetes en ambos nodos a excepción de los
del kernel por restricciones del aplicativo que se pretende montar sobre el clúster.
[root@ENT900PD ~]# yum -x 'kernel*' update
En Oracle Enterprise Linux, al estar basado el Red Hat, se utiliza la herramienta yum para las
actualizaciones de paquetes del sistema. Al pasarle el modificador –x ‘kernel*’ ignorará los
paquetes pertenecientes al kernel y con el siguiente modificador ‘update’ se le especifica que lo
que se quiere hacer es actualizar los paquetes existentes teniendo siempre en cuenta las
dependencias de éstos.
Como se ha comentado anteriormente, existen cuatro caminos de acceso de cada uno de los
servidores a la cabina. Esto implica que la cabina presenta al sistema operativo 4 veces cada una de
las LUN que están mapeadas a ellos, por lo que habría 8 discos visibles.
Para gestionar los caminos hacia la cabina de almacenamiento se necesita un software de
multipathing que presentará al sistema operativo un nuevo disco y gestionará el balanceo entre los
distintos caminos dando la funcionalidad de no perder el acceso a los discos si alguno de los
caminos falla.
Al haber elegido en la instalación las opciones de “Cluster” y “Cluster Storage” el software para
multipath debería estar instalado. Se comprueba mediante:
[root@ENT900PD ~]# rpm -qa | grep multipath
device-mapper-multipath-0.4.9-46.0.4.el5
device-mapper-multipath-libs-0.4.9-46.0.4.el5
Posteriormente se verifica si el servicio está programado para iniciar cuando arranque el sistema
operativo:
[root@ENT900PD ~]# chkconfig --list multipathd
multipathd 0:off 1:off 2:off 3:off 4:off 5:off 6:off
Por defecto no arranca automáticamente al estar en off para todos los run-levels. Se configura para
que arranque automáticamente:
[root@ENT900PD ~]# chkconfig multipathd on
[root@ENT900PD ~]# chkconfig --list multipathd
multipathd 0:off 1:off 2:on 3:on 4:on 5:on 6:off
El siguiente paso es configurar multipath. Para ello lo primero es copiar el fichero de configuración
por defecto a la ubicación de donde lo lee la aplicación:
[root@ENT900PD ~]# cp /usr/share/doc/device-mapper-multipath-
0.4.9/multipath.conf /etc/multipath/
53
Hay que editar el fichero por defecto y dejar únicamente las siguientes líneas:
[root@ENT900PD ~]# vim /etc/multipath.conf
blacklist {
devnode "^(ram|raw|loop|fd|md|dm-|sr|scd|st)[0-9]*"
devnode "^hd[a-z]"
devnode "^sd[a-b]"
}
defaults {
user_friendly_names yes
}
En el apartado “blacklist” se le indica que los discos que comiencen por los patrones indicados no
sean gestionados por multipath ya que se trata de los discos físicos instalados en cada uno de los
servidores.
En el apartado “defaults” se le indica que sea capaz de usar nombres personalizados para cada uno
de los discos de multipath.
El siguiente paso es iniciar el servicio de multipath y hacer una consulta de los discos que es capaz
de gestionar y sus respectivos caminos:
[root@ENT900PD ~]# service multipathd start
Starting multipathd daemon: [ OK ]
[root@ENT900PD ~]# multipath -ll
mpath0 (360060160e5012100d6e09b7ef906e111) dm-1 DGC,RAID 10
size=301G features='1 queue_if_no_path' hwhandler='1 emc' wp=rw
`-+- policy='round-robin 0' prio=0 status=active
|- 2:0:1:0 sdi 8:128 active ready running
|- 2:0:0:0 sdg 8:96 active ready running
|- 1:0:1:0 sde 8:64 active ready running
`- 1:0:0:0 sdc 8:32 active ready running
mpath1 (360060160e5012100670d309cf906e111) dm-0 DGC,RAID 10
size=100M features='1 queue_if_no_path' hwhandler='1 emc' wp=rw
`-+- policy='round-robin 0' prio=0 status=active
|- 2:0:1:1 sdj 8:144 active ready running
|- 2:0:0:1 sdh 8:112 active ready running
|- 1:0:1:1 sdf 8:80 active ready running
`- 1:0:0:1 sdd 8:48 active ready running
En este caso nos aparecen los dos discos que configuramos en la cabina para el almacenamiento
compartido. En la salida del comando se puede apreciar que los ha identificado como mpath0 y
mpath1 respectivamente y entre paréntesis aparece el identificador único de cada LUN.
En el siguiente paso se modificará los nombres mpath0 y mpath1 para forzar a multipath que
establezca un nombre persistente en caso de reinicio de la máquina, para ello es necesario el
identificador de cada LUN. Hay que añadir las siguientes líneas al fichero de configuración:
multipaths {
multipath {
wwid 360060160e5012100670d309cf906e111
alias quórum
path_grouping_policy multibus
path_selector "round-robin 0"
failback 0
rr_weight priorities
no_path_retry 5
}
54
multipath {
wwid 360060160e5012100d6e09b7ef906e111
alias jdedwards
path_grouping_policy multibus
path_selector "round-robin 0"
failback 0
rr_weight priorities
no_path_retry 5
}
}
En cada entrada “multipath” se le especifica cada identificador de LUN y el nombre que se desea
establecer. El resto de las opciones son para especificar que hay varios caminos para acceso, que
use algoritmo round-robin, recupere caminos automáticamente tras la caída de alguno de ellos y
prioridades de acceso a cabina.
Lo siguiente a realizar es verificar que está instalado el software de clustering en el sistema. En
principio debería estar instalado ya que durante la instalación se seleccionaron las opciones de
“Cluster” y “Cluster Storage”. Se verifica como sigue:
[root@ENT900PD ~]# rpm -qa | grep cman
cman-2.0.115-85.el5_7.2
[root@ENT900PD ~]# rpm -qa | grep rgmanager
rgmanager-2.0.52-21.el5
[root@ENT900PD ~]# rpm -qa | grep gfs2
gfs2-utils-0.1.62-34.el5
[root@ENT900PD ~]# rpm -qa | grep cluster
system-config-cluster-1.0.57-12
cluster-cim-0.12.1-7.0.1.el5
modcluster-0.12.1-7.0.1.el5
cluster-snmp-0.12.1-7.0.1.el5
lvm2-cluster-2.02.88-7.el5
[root@ENT900PD ~]# rpm -qa | grep luci
luci-0.12.2-51.0.1.el5
[root@ENT900PD ~]# rpm -qa | grep ricci
ricci-0.12.2-51.0.1.el5
El paquete de cman es el del “Cluster Manager” que es el servicio principal de clúster y gestiona los
recursos de éste.
El paquete rgmanager es el monitor del clúster que se encarga verificar el estado de los nodos y el
balanceo de los servicios entre ellos.
El paquete gfs2-utils son las utilidades necesarias para montar sistemas de ficheros gfs2 que son los
utilizados para entornos de clúster donde varios nodos llegarán a acceder a los ficheros.
Los paquetes que contienen la palabra clúster son herramientas de configuración para interfaz
gráfica y servicios adicionales del clúster, por ejemplo lvm2-cluster es necesario para poder
gestionar el almacenamiento compartido a través del software del clúster.
El paquete luci es la herramienta para configuración gráfica a través de interfaz web.
El paquete ricci es un agente que utiliza la herramienta de configuración gráfica a través de interfaz
web para poder establecer las modificaciones realizadas a través de este medio a todos los nodos.
55
El siguiente paso es verificar que los servicios de clúster arranquen con el sistema operativo. Se
verifican uno por uno como sigue:
[root@ENT900PD ~]# chkconfig --list cman
cman 0:off 1:off 2:off 3:off 4:off 5:off 6:off
[root@ENT900PD ~]# chkconfig cman on
[root@ENT900PD ~]# chkconfig --list cman
cman 0:off 1:off 2:on 3:on 4:on 5:on 6:off
[root@ENT900PD ~]# chkconfig --list rgmanager
rgmanager 0:off 1:off 2:off 3:off 4:off 5:off 6:off
[root@ENT900PD ~]# chkconfig rgmanager on
[root@ENT900PD ~]# chkconfig --list rgmanager
rgmanager 0:off 1:off 2:on 3:on 4:on 5:on 6:off
[root@ENT900PD ~]# chkconfig --list qdiskd
qdiskd 0:off 1:off 2:off 3:off 4:off 5:off 6:off
[root@ENT900PD ~]# chkconfig qdiskd on
[root@ENT900PD ~]# chkconfig --list qdiskd
qdiskd 0:off 1:off 2:on 3:on 4:on 5:on 6:off
[root@ENT900PD ~]# chkconfig --list clvmd
clvmd 0:off 1:off 2:off 3:off 4:off 5:off 6:off
[root@ENT900PD ~]# chkconfig clvmd on
[root@ENT900PD ~]# chkconfig --list clvmd
clvmd 0:off 1:off 2:on 3:on 4:on 5:on 6:off
[root@ENT900PD ~]# chkconfig --list gfs2
gfs2 0:off 1:off 2:off 3:off 4:off 5:off 6:off
[root@ENT900PD ~]# chkconfig gfs2 on
[root@ENT900PD ~]# chkconfig --list gfs2
gfs2 0:off 1:off 2:on 3:on 4:on 5:on 6:off
[root@ENT900PD ~]# chkconfig --list ricci
ricci 0:off 1:off 2:off 3:off 4:off 5:off 6:off
[root@ENT900PD ~]# chkconfig ricci on
[root@ENT900PD ~]# chkconfig --list ricci
ricci 0:off 1:off 2:on 3:on 4:on 5:on 6:off
[root@ENT900PD ~]# chkconfig --list luci
luci 0:off 1:off 2:off 3:off 4:off 5:off 6:off
[root@ENT900PD ~]# chkconfig luci on
[root@ENT900PD ~]# chkconfig --list luci
luci 0:off 1:off 2:on 3:on 4:on 5:on 6:off
Para poder utilizar la herramienta de administración web es necesario realizar la configuración
inicial para establecer la contraseña de acceso para el usuario “admin”:
[root@ENT900PD ~]# luci_admin init
Initializing the luci server
Creating the 'admin' user
Enter password:
Confirm password:
Please wait...
The admin password has been successfully set.
Generating SSL certificates...
The luci server has been successfully initialized
56
You must restart the luci server for changes to take effect.
Run "service luci restart" to do so
Lo siguiente a realizar es arrancar todos los servicios necesarios para poder comenzar a configurar
el clúster. Este arranque tiene que ser en un orden determinado para que no haya problemas:
Gfs2 Cman Clvmd Rgmanager Luci Ricci
[root@ENT900PD ~]# service gfs2 start
[root@ENT900PD ~]# service cman start
Starting cluster:
Loading modules... done
Mounting configfs... done
Starting ccsd... done
Starting cman... done
Starting qdiskd... done
Starting daemons... done
Starting fencing... done
[ OK ]
[root@ENT900PD ~]# service clvmd start
Starting clvmd:
Activating VG(s): No volume groups found
[ OK ]
[root@ENT900PD ~]# service rgmanager start
Starting Cluster Service Manager: [ OK ]
[root@ENT900PD ~]# service luci start
Starting luci: Generating https SSL certificates... done
[ OK ]
Point your web browser to https://ENT900PD:8084 to access luci
[root@ENT900PD ~]# service ricci start
Starting ricci: [ OK ]
4.7.- Creación del clúster
La configuración del clúster se va a realizar utilizando la herramienta luci que se ha configurado con
anterioridad. Para ello se deberá acceder a través de navegador web a la url:
https://ENT900PD00:8084/luci
El usuario y contraseña será el configurado en el apartado anterior cuando se hizo la configuración
inicial de la aplicación luci.
57
Para crear el clúster hay que ir a la pestaña “cluster” y seleccionar en el menú izquierdo la opción
“Create a New Cluster”.
En las opciones hay que especificar el nombre asignado a la interfaz privada para cada uno de los
nodos y rellenar con la contraseña del superusuario. Marcar las opciones para que
automáticamente descargue los paquetes requeridos para generar el clúster y activar la opción
para permitir almacenamiento compartido.
58
Una vez rellenados los campos necesarios pulsar sobre el botón “View SSL cert fingerprints” con lo
que verificará que los nodos son accesibles al intentar acceder a los fingerprint SSL de cada uno de
ellos.
4.7.1.- Configuración de parámetros globales del clúster
Una vez creado el clúster hay que configurar los parámetros globales de éste. Para ello hay que
acceder a la pestaña “clúster” y en la lista de clústers seleccionar el que se ha creado “JDE_LOGCI”.
En el apartado “General” se puede cambiar el nombre del clúster, muestra la versión del fichero de
configuración y se pueden establecer valores avanzados para la gestión de tiempos para
determinadas funcionalidades del clúster. Sólo se modifica la opción de Token Timeout por
recomendaciones del fabricante y cuyo valor se explicará en el apartado de configuración del
quórum.
En la pestaña de “Fence” se establecen los límites que establecen cuando un nodo del clúster se ha
quedado inaccesible. Se configura para que el fencing reinicie el nodo afectado tras 0 segundos de
detectar el error. El inicio de la monitorización de fencing se realizará 3 segundos después de que el
nodo se haya unido al clúster.
59
En la pestaña “Multicast” se establece que sea el propio clúster el que elija la dirección de multicast
automáticamente así se consigue que sea éste el que busque la mejor opción a la hora de hacer la
comunicación.
4.7.2.- Creación del disco de quórum y configuración para que sea util izado por el clú ster
La primera fase de la creación del disco de quórum es generar una nueva tabla de particiones
“msdos” sobre la cual crear la partición que servirá para alojar los datos para quórum. Para ello se
utilizará la herramienta parted y con el comando mklabel permite generar una nueva tabla de
particiones del formato msdos.
[root@ENT900PD ~]# parted /dev/mapper/quorum
GNU Parted 1.8.1
Using /dev/mapper/quórum
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) mklabel
Warning: The existing disk label on /dev/mapper/quórum will be destroyed and
all
data on this disk will be lost. Do you want to continue?
Yes/No? Yes
New disk label type? [msdos]? Msdos
(parted) quit
Tras crear la tabla de particiones hay que generar la partición sobre la que montar el quórum. Para
ello se utilizará la herramienta fdisk siguiendo el siguiente procedimiento:
- N para crear una nueva partición.
- P para indicar que será una partición primaria.
- 1 para indicar que es la primera partición del disco.
- Los siguientes parámetros se dejarán en blanco para que la partición tenga el tamaño de todo
el disco.
- P para que muestre las particiones generadas en el disco.
- W para guardar los cambios.
60
[root@ENT900PD ~]# fdisk /dev/mapper/quórum
Command (m for help): n
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-8, default 1):
Using default value 1
Last cylinder or +size or +sizeM or +sizeK (1-8, default 8):
Using default value 8
Command (m for help): p
Disk /dev/mapper/quórum: 67 MB, 67108864 bytes
255 heads, 63 sectors/track, 8 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/mapper/quórump1 1 8 64228+ 83 Linux
Command (m for help): w
The partition table has been altered!
Calling ioctl() to re-read partition table.
Syncing disks.
Una vez generada la partición se utilizará la herramienta mkqdisk para crear el nuevo disco de
quórum que utilizará el clúster. La sintaxis de este comando es la siguiente:
mkqdisk –c <partición> -l <etiqueta>
[root@ENT900PD ~]# mkqdisk -c /dev/mapper/quórump1 -l JDE_LOGCI
mkqdisk v0.6.0
Writing new quórum disk label 'JDE_LOGCI' to /dev/mapper/quórump1.
WARNING: About to destroy all data on /dev/mapper/quórump1; proceed [N/y] ? y
Initializing status block for node 1...
Initializing status block for node 2...
Initializing status block for node 3...
Initializing status block for node 4...
Initializing status block for node 5...
Initializing status block for node 6...
Initializing status block for node 7...
Initializing status block for node 8...
Initializing status block for node 9...
Initializing status block for node 10...
Initializing status block for node 11...
Initializing status block for node 12...
Initializing status block for node 13...
Initializing status block for node 14...
Initializing status block for node 15...
Initializing status block for node 16...
Este proceso inicializa los bloques para hasta 16 nodos de clúster que es la limitación del software
en cuanto a número de nodos para esta solución.
61
Una vez creado el disco de quórum se verifica que se ha creado correctamente utilizando el
comando mkqdisk –L para listar los discos de quórum disponibles en el sistema.
[root@ENT900PD ~]# mkqdisk -L
mkqdisk v0.6.0
/dev/dm-2:
/dev/mapper/quorump1:
/dev/mpath/quorump1:
Magic: eb7a62c2
Label: JDE_LOGCI
Created: Mon May 27 21:28:56 2013
Host: ENT900PD
Kernel Sector Size: 512
Recorded Sector Size: 512
Una vez generado el disco hay que volver a la pestaña “Quórum Partition” de la herramienta de
configuración web del clúster para especificar los parámetros de éste. Los parámetros elegidos
para el disco de quórum son los siguientes:
Interval: Frecuencia de comprobación de estado de los nodos en segundos. En este caso se ha
decidido que se compruebe cada 2 segundos.
Votes: El número de votos que el quórum presentará al clúster. En este caso se ha elegido 1 voto
para deshacer el empate en caso de caída de un nodo para permitir que el otro sea capaz
de dar servicio.
TKO: Conocido como “Technical KO” e indica el número de errores consecutivos en la
comprobación de cada nodo antes de darlo por caído. En este caso se establece en 5 por lo
que un nodo se daría por inactivo tras 10 segundos (5 errores * 2 segundos). Según este
parámetro es por el que se establece el timeout de todo el clúster que se recomienda que
sea del doble de este valor.
Minimum score: Puntuación mínima que debe disponer el quórum para darlo como activo. Se
calcula según los valores de las heurísticas que se configuren (floor((n+1)/2)) por lo que
aquí se establecerá un valor de 2 y en el de la heurística en 3.
Label: Etiqueta del disco de clúster. En este caso JDE_LOGCI que es la que se definió al crear el
disco de quórum.
Heuristics: Método adicional para ayudar a decidir al quórum si es clúster podría estar operativo.
Se especifica un script que comprueba el link de la interfaz bond0 y hace un ping a la
puerta de enlace de la red cada 2 segundos y con una puntuación de 3 por lo mencionado
anteriormente.
62
4.8.- Creación de los recursos a l os que dará servicio el clúster
4.8.1.- Creación del recurso de IP virtu al del clúster
Este recurso será la IP virtual que se levantará en el nodo que esté dando el servicio y a través de la
cual los clientes accederán al resto de recursos.
Para crear dicho recurso hay que ir a la opción “Add a Resource” dentro de la pestaña “cluster” en
donde se seleccionará del desplegable la opción “IP address” que es el tipo de recurso que se desea
crear.
63
En cuanto a las opciones de recurso serían las siguientes:
- IP address: Dirección IP virtual que se levantará sobre el nodo que tenga activo el recurso.
- Monitor link: Check para habilitar que el clúster tenga monitorizado el link de la interfaz
virtual. Se deja marcado para que en caso de error de este recurso el clúster gestione la
disponibilidad de todo el servicio.
4.8.2.- Configuración y creación del recur so de almacenamiento compartido
Este recurso será el que monte el sistema de ficheros compartido en el nodo que esté dando
servicio en cada momento. Sobre este almacenamiento es sobre el que se montarán las
aplicaciones para dar servicio con el fin de que estén los mismos ficheros independientemente del
nodo que esté dando el servicio.
4.8.2.1.- Configuración del almacenamiento compartido
La primera fase de configuración del almacenamiento consiste en crear la nueva partición en los
discos compartidos con las opciones necesarias para que pueda ser clusterizado. Esto se hace en
varias fases:
1. Inicializar la partición con sistema de archivos gpt pues es el recomendado para volúmenes
de clúster.
2. Crear una partición con el todo el espacio del disco que es sobre la que se montará el
sistema de archivos GFS2.
64
3. Marcar la partición para habilitar el uso de lvm2 que es necesario para que el clúster sea
capaz de gestionar el almacenamiento.
[root@ENT900PD ~]# parted /dev/mapper/jdedwards
GNU Parted 1.8.1
Using /dev/mapper/jdedwards
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) mklabel gpt
Warning: The existing disk label on /dev/mapper/jdedwards will be destroyed
and
all data on this disk will be lost. Do you want to continue?
parted: invalid token: gpt
Yes/No? Yes
New disk label type? [msdos]? gpt
(parted) print
Model: Linux device-mapper (dm)
Disk /dev/mapper/jdedwards: 302.9GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
(parted) mkpart primary 0 -1
(parted) set 1 lvm on
(parted) print
Model: Linux device-mapper (dm)
Disk /dev/mapper/jdedwards: 302.9GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
1 17.4kB 302.9GB 302.9GB primary lvm
(parted) quit
Information: Don't forget to update /etc/fstab, if necessary.
[root@ENT900PD ~]# partprobe -s /dev/mapper/jdedwards
/dev/mapper/jdedwards: gpt partitions 1
El siguiente paso es activar las opciones de clúster de lvm2 para que el clúster sea capaz de
gestionar el almacenamiento. Una vez hecho reiniciar el servicio de almacenamiento de clústers
(clvmd) para que se activen los cambios.
[root@ENT900PD ~]# lvmconf --enable-cluster
[root@ENT900PD ~]# service clvmd restart
Restarting clvmd: [ OK ]
Hay que crear los volúmenes para que el clúster sea capaz de gestionar el acceso de los nodos al
almacenamiento. Para ello hay que hacer lo siguiente:
1. Configurar el volumen físico (physical volume) sobre la partición que se ha creado
anteriormente.
[root@ENT900PD ~]# pvcreate /dev/mapper/jdedwardsp1
Writing physical volume data to disk "/dev/mapper/jdedwardsp1"
Physical volume "/dev/mapper/jdedwardsp1" successfully created
65
2. Crear el grupo de volúmenes (volume group) con la opción de clustered y con nombre
vg_jdedwards sobre la partición que se ha creado anteriormente.
[root@ENT900PD ~]# vgcreate --clustered y vg_jdedwards
/dev/mapper/jdedwardsp1
Clustered volume group "vg_jdedwards" successfully created
3. Hay que activar el volume group que se ha creado en todos los nodos. Para ello hay que
reiniciar el servicio clvmd en cada uno de ellos y posteriormente forzar al sistema para que
escanee tanto el physical volumen como en volume group.
[root@ENT900PD ~]# service clvmd restart
Restarting clvmd: [ OK ]
[root@ENT900PD ~]# pvscan
PV /dev/mpath/jdedwardsp1 VG jdedwards lvm2 [39.96 GB / 39.96 GB
free]
Total: 1 [39.96 GB] / in use: 1 [299.96 GB] / in no VG: 0 [0 ]
[root@ENT900PD ~]# vgscan
Reading all physical volumes. This may take a while...
Found volume group "vg_jdedwards" using metadata type lvm2
4. Crear el volumen lógico (logical volume) sobre el grupo de volúmenes creado en el paso
anterior y asignarle el 100% del espacio y establecer el nombre a lv_jdedwards.
[root@ENT900PD ~]# lvcreate -l 100%FREE -n lv_jdedwards vg_jdedwards
Logical volume "lv_jdedwards" created
[root@ENT900PD ~]# lvdisplay /dev/vg_jdedwards/lv_jdedwards
--- Logical volume ---
LV Name /dev/vg_jdedwards/lv_jdedwards
VG Name vg_jdedwards
LV UUID 2TF0fk-6DrR-CrEu-bPQN-29tJ-QSdG-xYfopI
LV Write Access read/write
LV Status available
# open 0
LV Size 299.96 GB
Current LE 76732
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 253:4
5. Dar formato como GFS2 al nuevo volumen lógico creado para poder asignarlo al clúster
según las recomendaciones del fabricante:
a. El nombre será <nombre_clúster>:gfs
b. La gestión de bloqueos se hará con la lock_dlm que es la estándar para este tipo
de sistemas de clúster.
c. Número de journals para control de bloqueos sobre los ficheros se establece al
número de nodos más uno.
66
d. Se dará formato directamente al dispositivo de volumen lógico directamente y no
a la partición.
[root@ENT900PD ~]# mkfs.gfs2 -t JDE_LOGCI:gfs -p lock_dlm -j 3
/dev/vg_jdedwards/lv_jdedwards
This will destroy any data on /dev/vg_jdedwards/lv_jdedwards.
Are you sure you want to proceed? [y/n] y
Device: /dev/vg_jdedwards/lv_jdedwards
Blocksize: 4096
Device Size 299.96 GB (10476544 blocks)
Filesystem Size: 299.96 GB (10476543 blocks)
Journals: 3
Resource Groups: 1200
Locking Protocol: "lock_dlm"
Lock Table: "JDE_LOGCI:gfs"
UUID: FFC03938-3775-D98D-C470-3CBCA7354DD8
4.8.2.2.- Creación del recurso de almacena miento compartido en e l clúster
Para agregar el recurso al clúster hay que acceder a la opción “Add a resource” dentro de la
pestaña “cluster” y en el desplegable elegir la opción “GFS file system”.
Rellenar los campos para la creación del nuevo recurso:
- Name: Nombre para identificar el recurso dentro del sistema de clúster.
- Mount point: Punto de montaje del almacenamiento.
- Device: Ubicación del vlumen lógico que se ha creado en los pasos anteriores.
- Filesystem type: Tipo de sistema de ficheros que contendrá el almacenamiento.
67
- Options: Opciones de montaje.
- File System ID: Es opcional y sirve para asignar un identificador al sistema de ficheros.
- Force unmount: Check para forzar que se desmonte el sistema de ficheros en caso de cambiar
el nodo que dará servicio al recurso.
- Reboot host node if unmount fails: Check para forzar que el nodo se reinicie si no es capaz de
desmontar el sistema de archivos antes de que pase a dar servicio para el recurso un nuevo
nodo.
4.8.3.- Configuración y creación del recurso de Samba
El recurso de Samba servirá para permitir que se pueda acceder a determinadas carpetas para
intercambiar datos con otros sistemas (En este caso sistemas Microsoft Windows).
4.8.3.1.- Configuración de Samba
El primer paso a realizar es instalar los paquetes necesarios para Samba en cada uno de los nodos
del clúster:
[root@ENT900PD ~]# yum install samba
Una vez instalado, hay que montar el almacenamiento compartido para crear las carpetas que se
compartirán y guardar en él el fichero de configuración de Samba.
[root@ENT900PD opt]# mount -t gfs2 /dev/vg_jdedwards/lv_jdedwards
/opt/jdedwards/
68
Crear las carpetas que se compartirán con Samba y darles permiso para que cualquiera pueda leer
y escribir sobre ellas:
[root@ENT900PD jdedwards]# mkdir -p /opt/jdedwards/shared/EDI
[root@ENT900PD jdedwards]# mkdir -p /opt/jdedwards/shared/XRT
[root@ENT900PD jdedwards]# mkdir -p /opt/jdedwards/shared/csv
[root@ENT900PD jdedwards]# chmod -R 777 /opt/jdedwards/shared/
Crear una nueva carpeta donde se moverá el fichero de configuración de Samba y crear un enlace
simbólico en la ubicación original de cada servidor para que apunte a él:
[root@ENT900PD jdedwards]# mkdir -p /opt/jdedwards/samba
[root@ENT900PD jdedwards]# mv /etc/samba/smb.conf /opt/jdedwards/samba/
[root@ENT900PD jdedwards]# ln -s /opt/jdedwards/samba/smb.conf
/etc/samba/smb.conf
El servicio de Samba no debe arrancar con el sistema ya que será el propio clúster el que se
encargará de iniciarlo y pararlo en el nodo que vaya a dar servicio:
[root@ENT900PD jdedwards]# chkconfig smb off
[root@ENT900PD jdedwards]# chkconfig --list smb
smb 0:off 1:off 2:off 3:off 4:off 5:off 6:off
[root@ENT900PD jdedwards]# service smb status
smbd is stopped
nmbd is stopped
Hay que configurar los recursos compartidos de Samba en el fichero smb.conf que ahora está
localizado en /opt/jdedwards/samba. Hay que especificar cada uno de los recursos, la ruta a la que
apunta, la máscara de los ficheros creados, el modo escritura y establecerlo como público. Hay que
modificar el fichero para que quede como sigue:
[global]
security = share
client lanman auth = Yes
lanman auth = Yes
[EDI$]
comment = EDI
path = /opt/jdedwards/shared/EDI
create mask = 777
read only = no
writeable = yes
public = yes
[XRT$]
comment = XRT
path = /opt/jdedwards/shared/XRT
create mask = 777
read only = no
writeable = yes
public = yes
[CSV$]
comment = CSV
path = /opt/jdedwards/shared/csv
create mask = 777
read only = no
writeable = yes
public = yes
69
Una vez terminado el proceso de configuración desmontar el almacenamiento compartido:
[root@ENT900PD ~]# umount /opt/jdedwards/
4.8.3.2.- Creación del recurso de Samba
Para agregar el recurso al clúster hay que acceder a la opción “Add a resource” dentro de la
pestaña “cluster” y en el desplegable elegir la opción “Script”.
Hay que rellenar los campos para configurar el recurso de la siguiente manera:
- Name: Nombre para identificar el recurso dentro del sistema de clúster.
- Full path to script file: Ruta del script de arranque/parada del servicio. El sistema de clúster se
encargará de pasar los parámetros de parada o arranque según sea necesario.
70
4.8.4.- Configuración y cr eación del recurso de impresión
Este recurso se encargará de dar soporte a la impresión desde el propio aplicativo que se va a
montar sobre el clúster. Para ello se utilizará CUPS (Common Unix Printing Service) que es el
software genérico que viene por defecto en los servidores Unix para dar soporte a la impresión.
4.8.4.1.- Configuración del recurso de impresión
El primer paso a realizar es instalar los paquetes necesarios para dar soporte a la impresión en cada
uno de los nodos del clúster:
[root@ENT900PD ~]# yum install cups
Lo siguiente a realizar es montar el almacenamiento compartido para poder crear la estructura de
carpetas que necesitará la aplicación CUPS:
[root@ENT900PD opt]# mount -t gfs2 /dev/vg_jdedwards/lv_jdedwards
/opt/jdedwards/
[root@ENT900PD usr]# mkdir -p /opt/jdedwards/cups/etc
[root@ENT900PD usr]# mkdir -p /opt/jdedwards/cups/var/spool
[root@ENT900PD usr]# mkdir -p /opt/jdedwards/cups/var/cache
[root@ENT900PD usr]# mkdir -p /opt/jdedwards/cups/usr/share
Las carpetas seguirán manteniendo su estructura original pero dentro del almacenamiento
compartido dentro de /opt/jdedwards/cups.
Una vez creada la estructura hay que copiar los ficheros y carpetas desde su ubicación original al
almacenamiento compartido:
- Ficheros de configuración.
[root@ENT900PD ~]# cp -R /etc/cups/ /opt/jdedwards/cups/etc/
- Cola de impresión y temporales.
[root@ENT900PD ~]# cp -R /var/spool/cups/ /opt/jdedwards/cups/var/spool/
- Caché de impresión.
[root@ENT900PD ~]# cp -R /var/cache/cups/ /opt/jdedwards/cups/var/cache/
- Elementos involucrados en la impresión (drivers de impresoras, etc.)
[root@ENT900PD ~]# cp -R /usr/share/cups/ /opt/jdedwards/cups/usr/share/
El sistema buscará los ficheros de configuración en su ubicación original a la hora de arrancar el
servicio, por ello se ha de crear un enlace simbólico de la carpeta /etc/cups hacia la nueva
ubicación de los ficheros:
[root@ENT900PD etc]# rm -rf /etc/cups
[root@ENT900PD etc]# rm -rf /etc/cups
71
[root@ENT900PD etc]# ln -s /opt/jdedwards/cups/etc/cups/ /etc/cups
[root@ENT900PD etc]# ll cups
lrwxrwxrwx 1 root root 29 Jun 3 12:59 cups -> /opt/jdedwards/cups/etc/cups/
Una vez creados los directorios deshabilitar el servicio de cups para que no arranque
automáticamente con el sistema operativo pues será el sistema de clúster el que gestionará el
arranque y la parada de éste cuando sea necesario:
[root@ENT900PD etc]# chkconfig cups off
[root@ENT900PD etc]# chkconfig --list cups
cups 0:off 1:off 2:off 3:off 4:off 5:off 6:off
Hay que modificar el fichero de configuración dentro de la nueva ubicación para permitir la
conexión a la interfaz web de configuración y para especificar donde está localizado cada uno de
los elementos dentro del almacenamiento compartido. Las modificaciones se harán sobre el fichero
cupsd.conf.
- Para permitir la conexión a la interfaz web hay que modificar las líneas de escucha y las que
llevan etiqueta “Location” para que queden como sigue:
# Only listen for connections from the local machine.
Listen 631
# Restrict access to the server...
<Location />
Order allow,deny
Allow all
</Location>
# Restrict access to the admin pages...
<Location /admin>
Encryption Required
Order allow,deny
Allow all
</Location>
# Restrict access to configuration files...
<Location /admin/conf>
AuthType Default
Require user @SYSTEM
Order allow,deny
Allow all
</Location>
- Para especificar los directorios de cada uno de los componentes hay que añadir las siguientes
líneas al final del fichero de configuración:
ServerRoot /opt/jdedwards/cups/etc/cups
RequestRoot /opt/jdedwards/cups/var/spool/cups
TempDir /opt/jdedwards/cups/var/spool/cups/tmp
CacheDir /opt/jdedwards/cups/var/cache/cups
DataDir /opt/jdedwards/cups/usr/share/cups
72
4.8.4.2.- Creación del recurso de impresión
Para agregar el recurso al clúster hay que acceder a la opción “Add a resource” dentro de la
pestaña “cluster” y en el desplegable elegir la opción “Script”.
Hay que rellenar los campos para configurar el recurso de la siguiente manera:
- Name: Nombre para identificar el recurso dentro del sistema de clúster.
- Full path to script file: Ruta del script de arranque/parada del servicio. El sistema de clúster se
encargará de pasar los parámetros de parada o arranque según sea necesario.
73
4.8.5.- Creación del dominio fail -over para los servicios del clúster
El dominio de fail-over restringirá a qué nodos podrá balancear o no un determinado servicio. Para
crear uno de estos dominios seleccionar la opción “Add a Failover Domain”. Sólo se especificarán el
nombre y la prioridad de los nodos, el resto de configuración no es necesaria para este caso.
4.8.6.- Creación del servicio que dará soporte a los recursos
El servicio agrupará todos los recursos que se han configurado en los apartados anteriores. Hay que
matizar que los recursos arrancarán/pararán en el orden que se especifique en éste.
Para crear un nuevo servicio acceder a la opción “Add a Service” y rellenar los datos siguientes para
configurarlo:
- Service name: Nombre para identificar el servicio en el sistema de clúster.
- Automatically start this service: Marcar para que el servicio arranque automáticamente al
iniciar el clúster.
- Enable NFS lock workarounds: En este caso al no ser un clúster para NFS no es necesario
marcarlo.
- Run exclusive: Especifica que el nodo que tenga este servicio no podrá tener otros servicios
activos. En este caso, al no haber más servicios, no es necesario marcarlo.
- Failover Domain: Dominio de failover para especificar los nodos que pueden tener activo el
servicio. Seleccionar en el desplegable el que se ha creado en pasos anteriores.
74
- Recovery policy: Política de recuperación del servicio en caso de fallo. En este caso relocate
para que si el nodo que esté dando el servicio falla, éste salte al otro nodo para poder
continuar dando servicio.
Una vez configurado hay que añadir los recursos a los que dará servicio. Los recursos deben seguir
un orden lógico haciendo que cada uno sea dependiente de los anteriores respectivamente ya que
si no se arrancan todos en el orden correcto no se podrá ofrecer un servicio completo para todos
ellos. El orden sería el siguiente:
1º - Recurso de IP que será a donde se conecten los clientes.
2º - Recurso de almacenamiento compartido sobre el que están montado el resto de recursos.
3º - Recurso de Samba para permitir el acceso a los directorios compartidos.
4º - Recurso de CUPS para dar soporte a la impresión desde la aplicación.
Los dos últimos no son realmente dependientes entre sí pero se establece que cada uno cuelgue de
los anteriores para asegurar que para que el servicio pueda estar activo tengan que estar en
funcionamiento todos y cada uno de los recursos.
Para añadir los recursos seleccionar “Add a resource to this service”.
Seleccionar del desplegable de los recursos existentes el recurso de IP que se ha creado en la fase
anterior.
75
Para añadir el recurso de almacenamiento GFS dependiente del anterior seleccionar la opción “Add
a child”
Del desplegable de los recursos existentes seleccionar el recurso GFS-JDEDWARDS creado en la fase
anterior.
El siguiente recurso a añadir al servicio es el de Samba, seleccionar de nuevo la opción “Add a
child”.
76
Del desplegable de recursos existentes seleccionar el recurso Samba creado en la fase anterior.
El último recurso a añadir es el de impresión, volver a seleccionar la opción “Add a child”.
Del desplegable de los recursos existentes seleccionar el recurso CUPS creado en la fase anterior.
Una vez añadidos todos los recursos seleccionar la opción “Submit” para guardar los cambios y
aparecerá la ventana del servicio creado donde muestra el estado. Por defecto, al crear el servicio
77
el sistema de clúster lo marca como activo y arranca automáticamente. En la propia ventana de
estado muestra sobre que nodo está arrancado.
4.8.7.- Configuración de opciones de fencing
El fencing es el sistema dentro del clúster que se encarga del reinicio de los nodos que presenten
algún error dentro de éste. En caso de detección de un error en alguno de los nodos el servicio de
quórum del clúster manda al dispositivo de fencing la orden de reiniciar el nodo para forzar que los
servicios pasen a uno que esté funcionando correctamente.
4.8.7.1.- Configurar e l disposi tivo fencing para cada servidor
En este caso se utilizará la opción de fencing a través de la consola de gestión remota de Dell (Dell
Remote Access Controller – DRAC). Hay que configurar a cada uno de los nodos su tarjeta
correspondiente para que cuando se detecte el error sepa a que tarjeta acceder para gestionar el
nodo afectado.
Dentro del clúster hay que acceder a la opción “Nodes” de la pestaña “clúster”. Para cada unos de
los servidores seleccionar la opción “Manage Fencing for this Node”.
78
Dentro de la sección “Main Fencing Method” seleccionar la opción “Add a fence device to this
level” y de la lista desplegable seleccionar la opción “Dell DRAC”
En las opciones para cada una de ellas hay que rellenar los siguientes campos:
Name: Nombre del dispositivo de fencing para poder localizarlo en la configuración del clúster.
79
IP Address: Dirección IP de la tarjeta DRAC del servidor.
Login: Nombre de usuario para el acceso a la tarjeta DRAC.
Password: Contraseña de acceso a la tarjeta DRAC.
Use SSH (DRAC5 only): Marcar el cuadro de verificación pues las tarjetas DRAC de los servidores son
versión 5 y necesitan utilizar el protocolo SSH para poder autenticar.
4.8.7.1.1.- Para el nodo ENT900PD00
4.8.7.1.2.- Para el nodo ENT900PD01
80
4.9.- Revisión del estado del clúster tras su creación
En la pantalla principal de la pestaña clúster aparece el clúster que se ha creado y muestra
información importante:
- Cluster Name: Nombre del clúster, en verde indica que está arrancado y en rojo que estaría
parado.
- Status: Quorate, Not Quorate. Indica si el clúster tiene la cantidad mínima de votos para poder
funcionar con normalidad.
- Total Cluster Votes: Indica el número total de votos de nodos y discos de quórum de los que
dispone el clúster.
- Minimum Required Quórum: Número de votos necesarios para que el clúster pueda operar
con normalidad.
Adicionalmente muestra los nodos que forman parte del clúster y los servicios que tiene
configurados con el código de colores que marca el estado igual que en “Cluster Name”.
Desde el cuadro desplegable se pueden realizar operaciones sobre el clúster.
- Restart this cluster: Reinicia los servicios de clúster en todos los nodos.
- Stop this cluster: Para los servicios de clúster en todos los nodos.
- Delete this cluster: Elimina el clúster completamente. Esta acción es irreversible si no se
dispone de un backup previo.
81
En la opción “Nodes” se puede obtener información adicional sobre el estado de los nodos y los
recursos que tienen asociados. Para cada nodo mostrará la siguiente información:
Node Name: Nombre del nodo. Aparecerá en verde si está activo y rojo si no lo está.
Status: Estado del nodo. Informa si está unido al clúster o no.
Services on this Node: Muestra si hay algún servicio sobre cada el nodo o si no lo hay. En caso de
haberlo mostrará el nombre y aparecerá en verde si está activo y en rojo si no lo está.
Failover Domain Membership: Muestra si el nodo pertenece a algún dominio de fail-over y en caso
de pertenecer a uno, indica el nombre de éste.
Manage Fencing for this Node: Esta opción es para configuración del fencing a nivel de nodo.
Show recent log activity for this node: Muestra en una ventana emergente los logs del nodo
relacionados con el sistema de clúster.
Si en la pantalla anterior se pulsa sobre cualquiera de los nodos, mostrará información adicional
sobre cada uno de ellos. Se omitirán detalles que se pueden visualizar en la pantalla anterior,
describiendo la información adicional en esta vista.
Cluster daemons running on this node: Muestra los dos procesos esenciales del clúster y su estado.
Aparecen unos cuadros de verificación para seleccionar si se desea que dichos procesos se
arranquen con el sistema operativo. Deshabilitar dichos cuadros provocará que si se reinicia el
nodo, éste no se una automáticamente al clúster.
82
En esta pantalla hay un cuadro de diálogo que permite realizar determinadas tareas de
mantenimiento para los nodos:
Have node leave clúster: Expulsa temporalmente el nodo del clúster. Esta tarea puede ser útil
cuando se desea hacer algún mantenimiento en alguno de los nodos.
Fence this node: Fuerza al sistema de fencing que debe haber sido configurado previamente a que
tire el nodo y lo vuelva a arrancar. Esta parada del sistema sería como si se pulsase el botón de
encendido del servidor y posteriormente se volviese a arrancar.
Reboot this node: Fuerza un reinicio del sistema. Este sería un reinicio ordenado parando servicios
ordenadamente igual que si se lanzase un reinicio a nivel del sistema operativo.
Delete this node: Elimina el nodo del clúster y toda su configuración asociada. Esta tarea es
irreversible si no se ha realizado un backup previo.
83
La última pantalla que muestra información importante es la del servicio. Para ello hay que acceder
a la opción “Services”. La información que muestra esta pantalla es la siguiente:
Service Name: Nombre del servicio. Aparecerá en verde si el servicio está arrancado en alguno de
los nodos o rojo si el servicio está detenido.
Status: Muestra sobre que nodo está corriendo el servicio o si el servicio está parado.
Adicionalmente muestra si el servicio está configurado para arrancar automáticamente tras
formarse el clúster.
Failover Domain Association: Muestra el dominio de failover al que está asociado el servicio o si el
servicio no está asociado a ninguno de éstos.
84
85
5.- Pruebas.
En este documento se recogerán las pruebas realizadas al sistema para evaluar la aceptación de
éste para un entorno de producción. Las pruebas se desarrollarán en función de los elementos que
pudiesen provocar la pérdida de servicio del sistema. Para ello se hará una diferencia de las
pruebas en función del tipo de elemento de la siguiente forma:
Pruebas tras la implantación.
- Pruebas de configuración.
o Pruebas de configuración de red.
o Pruebas de configuración de almacenamiento.
o Pruebas de balanceo de servicios en el clúster.
o Pruebas de servicios clusterizados.
o Pruebas de fencing.
- Pruebas de error a nivel de red.
o Pérdida de conexión de tarjetas de red de servidor.
o Problema a nivel de switches de red.
o Pérdida de conexión de dispositivos involucrados.
- Pruebas de error a nivel eléctrico.
o Error a nivel de SAI.
o Pérdida de suministro eléctrico externo.
- Pruebas de error a nivel de almacenamiento.
o Pérdida de conectividad de fibra a nivel de servidor.
o Pérdida de conectividad de fibra a nivel de switch.
o Pérdida de conectividad de fibra a nivel de cabina.
Fase de producción.
- Pruebas de rendimiento.
o Rendimiento durante el arranque.
o Rendimiento en campaña.
o Rendimiento en cierre contable.
86
o Rendimiento en circunstancias normales.
- Análisis de problemas.
o Problemas de discos de la cabina.
o Problemas de discos en los servidores.
o Problemas de alimentación eléctrica.
Para cada uno de los casos se creará un informe con los siguientes detalles:
- Descripción de la prueba.
- Fase de realización de la prueba.
- Impacto en caso de no pasar la prueba.
- Simulación realizada para la prueba.
- Resultados esperados.
- Resultados obtenidos.
- Correcciones aplicadas (si procede).
-
5.1.- Pruebas tras la implantación
5.1.1.- Pruebas de configuración
5.1.1.1.- Pruebas de configuración de red
5.1.1.1.1.- Prueba 1.1.1
Descripción de la prueba: Comprobar la configuración de la configuración de red del nodo
ENT900PD00.
Fase de realización de la prueba: Tras haber realizado la configuración de la red tanto en
dispositivos como en los nodos.
Impacto en caso de no pasar la prueba: Volver a revisar la configuración de red de los elementos
afectados. No se podría continuar con la implantación hasta no estar solventado para los casos
críticos según la siguiente tabla.
Prueba de conectividad con stack de switches de red Crítico
Prueba de conectividad con tarjetas DRAC Crítico
Prueba de conectividad con interfaz pública del nodo ENT900PD01 Crítico
87
Prueba de conectividad con interfaz privada del nodo ENT900PD01 Crítico
Prueba de conectividad con interfaces de red de los switches de fibra óptica Sin impacto
Prueba de conectividad con interfaces de red de la cabina de almacenamiento Crítico
Simulación para la realización de la prueba: N/A.
Resultados esperados: El servidor debe tener conectividad con las interfaces de red de todos los
dispositivos involucrados.
Resultados obtenidos:
Prueba de conectividad con stack de switches de red OK
Prueba de conectividad con tarjetas DRAC OK
Prueba de conectividad con interfaz pública del nodo ENT900PD01 Error
Prueba de conectividad con interfaz privada del nodo ENT900PD01 Error
Prueba de conectividad con interfaces de red de los switches de fibra óptica OK
Prueba de conectividad con interfaces de red de la cabina de almacenamiento OK
Correcciones aplicadas:
- Se ha revisado la configuración de red de servidor ENT900PD00 OK
- Se ha revisado la conexión de los cables del servidor ENT900PD00 al stack de switches OK
- Se ha revisado la configuración de red del servidor ENT900PD01 OK
- Se ha revisado la conexión de los cables del servidor ENT900PD01 Error. Los cables se han
conectado de forma incorrecta al stack de switches. Estaban intercambiados los cables de los
adaptadores de la red pública con los de la red privada por error. Corregido el cableado OK
5.1.1.1.2.- Prueba 1.1.2
Descripción de la prueba: Comprobar la configuración de la configuración de red del nodo
ENT900PD01.
Fase de realización de la prueba: Tras haber realizado la configuración de la red tanto en
dispositivos como en los nodos.
Impacto en caso de no pasar la prueba: Volver a revisar la configuración de red de los elementos
afectados. No se podría continuar con la implantación hasta no estar solventado para los casos
críticos según la siguiente tabla.
Prueba de conectividad con stack de switches de red Crítico
Prueba de conectividad con tarjetas DRAC Crítico
Prueba de conectividad con interfaz pública del nodo ENT900PD00 Crítico
Prueba de conectividad con interfaz privada del nodo ENT900PD00 Crítico
Prueba de conectividad con interfaces de red de los switches de fibra óptica Sin impacto
Prueba de conectividad con interfaces de red de la cabina de almacenamiento Crítico
88
Simulación para la realización de la prueba: N/A.
Resultados esperados: El servidor debe tener conectividad con las interfaces de red de todos los
dispositivos involucrados.
Resultados obtenidos:
Prueba de conectividad con stack de switches de red OK
Prueba de conectividad con tarjetas DRAC OK
Prueba de conectividad con interfaz pública del nodo ENT900PD00 Error
Prueba de conectividad con interfaz privada del nodo ENT900PD00 Error
Prueba de conectividad con interfaces de red de los switches de fibra óptica OK
Prueba de conectividad con interfaces de red de la cabina de almacenamiento OK
Correcciones aplicadas:
- Se ha revisado la configuración de red del servidor ENT900PD01 OK
- Se ha revisado la conexión de los cables del servidor ENT900PD01 Error. Los cables se han
conectado de forma incorrecta al stack de switches. Estaban intercambiados los cables de los
adaptadores de la red pública con los de la red privada por error. Corregido el cableado OK
- Se ha revisado la configuración de red de servidor ENT900PD00 OK
- Se ha revisado la conexión de los cables del servidor ENT900PD00 al stack de switches OK
5.1.1.2.- Pruebas de configuración de almacenamiento
5.1.1.2.1.- Prueba 1.2.1
Descripción de la prueba: Comprobar la configuración para almacenamiento y la gestión de
caminos con multipath en el nodo ENT900PD00.
Fase de realización de la prueba: Tras haber realizado la configuración de almacenamiento tanto en
los servidores como en la cabina.
Impacto en caso de no pasar la prueba: Volver a revisar la configuración del almacenamiento. No se
podría continuar con la implantación hasta no estar solventado.
Simulación para la realización de la prueba: N/A.
Resultados esperados: El servidor debe ser capaz de obtener acceso al almacenamiento de la
cabina por los cuatro caminos disponibles.
Resultados obtenidos: Se ha verificado utilizando comandos de multipath que el servidor es capaz
de obtener acceso a las dos LUNs configuradas y los cuatro caminos los marca como “active”.
89
Adicionalmente se ha verificado en la interfaz de la cabina que detecta como activos los cuatro
caminos por los que accede el servidor.
5.1.1.2.2.- Prueba 1.2.2
Descripción de la prueba: Comprobar la configuración para almacenamiento y la gestión de
caminos con multipath en el nodo ENT900PD01.
Fase de realización de la prueba: Tras haber realizado la configuración de almacenamiento tanto en
los servidores como en la cabina.
Impacto en caso de no pasar la prueba: Volver a revisar la configuración del almacenamiento. No se
podría continuar con la implantación hasta no estar solventado.
Simulación para la realización de la prueba: N/A.
Resultados esperados: El servidor debe ser capaz de obtener acceso al almacenamiento de la
cabina por los cuatro caminos disponibles.
Resultados obtenidos: Se ha verificado utilizando comandos de multipath que el servidor es capaz
de obtener acceso a las dos LUNs configuradas y los cuatro caminos los marca como “active”.
Adicionalmente se ha verificado en la interfaz de la cabina que detecta como activos los cuatro
caminos por los que accede el servidor.
5.1.1.3.- Pruebas de balanceo de servicios en el c lúster
5.1.1.3.1.- Prueba 1.3.1
Descripción de la prueba: Comprobar el correcto balanceo del servicio del nodo ENT900PD00 al
nodo ENT900PD01.
Fase de realización de la prueba: Tras haber realizado la implantación completa.
Impacto en caso de no pasar la prueba: Volver a revisar la configuración de red privada, servicios y
recursos. En caso de error habrá que verificar todo el clúster pues es crítico para la alta
disponibilidad.
Simulación para la realización de la prueba: Lanzar desde la interfaz web el balanceo del servicio de
un nodo al otro.
Resultados esperados: Al balancear el servicio, el nodo original deberá perder la IP virtual,
desmontar el almacenamiento compartido y parar los procesos de los recursos de Samba y de
impresión. Todos los recursos deben activarse en el nodo destino.
Resultados obtenidos:
Parada del recurso de impresión en el nodo ENT900PD00 OK
Parada del recurso de Samba en el nodo ENT900PD00 OK
Almacenamiento compartido desmontado en el nodo ENT900PD00 OK
90
Recurso de IP virtual desmontado en el nodo ENT900PD00 OK
Recurso de IP virtual montado en el nodo ENT900PD01 OK
Almacenamiento compartido montado en el nodo ENT900PD01 OK
Arranque del recurso de Samba en el nodo ENT900PD01 OK
Arranque del recurso de impresión en el nodo ENT900PD01 OK
5.1.1.3.2.- Prueba 1.3.2
Descripción de la prueba: Comprobar el correcto balanceo del servicio del nodo ENT900PD01 al
nodo ENT900PD00.
Fase de realización de la prueba: Tras haber realizado la implantación completa.
Impacto en caso de no pasar la prueba: Volver a revisar la configuración de red privada, servicios y
recursos. En caso de error habrá que verificar todo el clúster pues es crítico para la alta
disponibilidad.
Simulación para la realización de la prueba: Lanzar desde la interfaz web el balanceo del servicio de
un nodo al otro.
Resultados esperados: Al balancear el servicio, el nodo original deberá perder la IP virtual,
desmontar el almacenamiento compartido y parar los procesos de los recursos de Samba y de
impresión. Todos los recursos deben activarse en el nodo destino.
Resultados obtenidos:
Parada del recurso de impresión en el nodo ENT900PD01 OK
Parada del recurso de Samba en el nodo ENT900PD01 OK
Almacenamiento compartido desmontado en el nodo ENT900PD01 OK
Recurso de IP virtual desmontado en el nodo ENT900PD01 OK
Recurso de IP virtual montado en el nodo ENT900PD00 OK
Almacenamiento compartido montado en el nodo ENT900PD00 OK
Arranque del recurso de Samba en el nodo ENT900PD00 OK
Arranque del recurso de impresión en el nodo ENT900PD00 OK
5.1.1.4.- Pruebas de servicios c lusterizados
5.1.1.4.1.- Prueba 1.4.1
Descripción de la prueba: Comprobar el correcto funcionamiento de todos los recursos del servicio
en el nodo ENT900PD00.
Fase de realización de la prueba: Tras haber realizado la implantación completa.
Impacto en caso de no pasar la prueba: Volver a revisar la configuración de los recursos afectados
tanto a nivel del sistema operativo como en el clúster. Habría que solucionar este aspecto antes de
poder continuar pues no tiene sentido tener un clúster en el que no funcionen los recursos.
91
Simulación para la realización de la prueba: Forzar en el clúster que el servicio se ejecute sobre el
nodo ENT900PD00 para hacer las pruebas.
Resultados esperados: Una vez puesto el clúster en el nodo correspondiente todos y cada uno de
los recursos configurados funciona de la manera esperada.
Resultados obtenidos:
Recurso de dirección IP virtual.
Probar que la IP responde al ping y que direcciona al nodo ENT900PD00 OK
Recurso de almacenamiento compartido.
Probar que el almacenamiento compartido está montado OK
Probar que se pueden hacer operaciones de lectura OK
Probar que se pueden hacer operaciones de escritura OK
Recurso de Samba.
Probar que se puede acceder a los recursos compartidos de Samba desde
cualquier equipo externo
OK
Probar operaciones de lectura de ficheros a través del recurso compartido OK
Probar operaciones de escritura de ficheros a través del recurso compartido OK
Recurso de impresión.
Probar acceso a la interfaz de configuración web OK
Probar a añadir drivers de impresoras OK
Probar creación de impresoras clusterizadas OK
Probar impresión en local desde el nodo OK
5.1.1.4.2.- Prueba 1.4.2
Descripción de la prueba: Comprobar el correcto funcionamiento de todos los recursos del servicio
en el nodo ENT900PD01.
Fase de realización de la prueba: Tras haber realizado la implantación completa.
Impacto en caso de no pasar la prueba: Volver a revisar la configuración de los recursos afectados
tanto a nivel del sistema operativo como en el clúster. Habría que solucionar este aspecto antes de
poder continuar pues no tiene sentido tener un clúster en el que no funcionen los recursos.
Simulación para la realización de la prueba: Forzar en el clúster que el servicio se ejecute sobre el
nodo ENT900PD01 para hacer las pruebas.
Resultados esperados: Una vez puesto el clúster en el nodo correspondiente todos y cada uno de
los recursos configurados funciona de la manera esperada.
Resultados obtenidos:
Recurso de dirección IP virtual.
Probar que la IP responde al ping y que direcciona al nodo ENT900PD00 OK
Recurso de almacenamiento compartido.
Probar que el almacenamiento compartido está montado OK
Probar que se pueden hacer operaciones de lectura OK
92
Probar que se pueden hacer operaciones de escritura OK
Recurso de Samba.
Probar que se puede acceder a los recursos compartidos de Samba desde
cualquier equipo externo
OK
Probar operaciones de lectura de ficheros a través del recurso compartido OK
Probar operaciones de escritura de ficheros a través del recurso compartido OK
Recurso de impresión.
Probar acceso a la interfaz de configuración web OK
Probar a añadir drivers de impresoras OK
Probar creación de impresoras clusterizadas OK
Probar impresión en local desde el nodo OK
5.1.1.5.- Pruebas de fencing
5.1.1.5.1.- Prueba 1.5.1
Descripción de la prueba: Comprobar el correcto funcionamiento del fencing en el nodo
ENT900PD00.
Fase de realización de la prueba: Tras haber realizado la implantación completa.
Impacto en caso de no pasar la prueba: Volver a revisar la configuración de fencing para el nodo
antes de continuar. Este es un aspecto crítico a nivel de clúster pues en caso de error de uno de los
nodos, el clúster no será capaz de resetearlo para que libere los recursos y los pase al otro.
Simulación para la realización de la prueba: Forzar que el servicio se ejecute sobre el nodo
ENT900PD00 y posteriormente en la interfaz del clúster para el nodo ENT900PD00 seleccionar del
desplegable la opción “Fence this node”.
Resultados esperados: Una vez lanzada la orden de fence del nodo, éste deberá apagarse y volver a
iniciar pasando el servicio al otro nodo.
Resultados obtenidos: Cuando se lanza la orden de fence del nodo no hace nada sacando en el log
un error de fencing indicando que no se pudo autenticar con la tarjeta DRAC de éste.
Correcciones aplicadas: Tras ver el error del log se vuelven a configurar las credenciales para el
fencing en el nodo ENT900PD00. Posteriormente se vuelve a realizar la prueba y el servidor se para
y vuelve a arrancar pasando el servicio al nodo ENT900PD00.
5.1.1.5.2.- Prueba 1.5.2.
Descripción de la prueba: Comprobar el correcto funcionamiento del fencing en el nodo
ENT900PD01.
Fase de realización de la prueba: Tras haber realizado la implantación completa.
Impacto en caso de no pasar la prueba: Volver a revisar la configuración de fencing para el nodo
antes de continuar. Este es un aspecto crítico a nivel de clúster pues en caso de error de uno de los
nodos, el clúster no será capaz de resetearlo para que libere los recursos y los pase al otro.
93
Simulación para la realización de la prueba: Forzar que el servicio se ejecute sobre el nodo
ENT900PD01 y posteriormente en la interfaz del clúster para el nodo ENT900PD01 seleccionar del
desplegable la opción “Fence this node”.
Resultados esperados: Una vez lanzada la orden de fence del nodo, éste deberá apagarse y volver a
iniciar pasando el servicio al otro nodo.
Resultados obtenidos: Cuando se lanza la orden de fence del nodo éste se para y vuelve a arrancar
pasando el servicio al nodo ENT900PD00.
5.1.2.- Pruebas de error a nivel de red
5.1.2.1.- Pérdida de conexión de tarjetas de red de servidor
5.1.2.1.1.- Prueba 2.1.1
Descripción de la prueba: Comprobar funcionamiento tras pérdida de link de una de las tarjetas de
red en los servidores.
Fase de realización de la prueba: Tras haber realizado la implantación completa.
Impacto en caso de no pasar la prueba: Revisar la configuración de red y la conexión de los cables
de red del servidor afectado. Este aspecto es crítico para la alta disponibilidad.
Simulación para la realización de la prueba: Soltar el cable de red de una de las interfaces de red en
el servidor para probar la caída de todas y cada una de ellas.
Resultados esperados: Si sólo se pierde la conectividad en una de las interfaces no debería haber
ningún problema a nivel de funcionamiento tanto de nodo como de clúster.
Resultados obtenidos:
Servidor Tarjeta Puerto Interfaz Estado 1 Estado 2 Estado 3 Estado 4
ENT900PD00 Integrada 1 Pública Down Up Up Up
ENT900PD00 Integrada 2 Privada Up Down Up Up
ENT900PD00 PCI 1 Pública Up Up Down Up
ENT900PD00 PCI 2 Privada Up Up Up Down
Resultados: OK OK OK OK
Servidor Tarjeta Puerto Interfaz Estado 1 Estado 2 Estado 3 Estado 4
ENT900PD01 Integrada 1 Pública Down Up Up Up
ENT900PD01 Integrada 2 Privada Up Down Up Up
ENT900PD01 PCI 1 Pública Up Up Down Up
ENT900PD01 PCI 2 Privada Up Up Up Down
Resultados: OK OK OK OK
94
En ninguna de las pruebas el clúster ha detectado ningún error y ha seguido funcionando con
normalidad como si no hubiese caído ninguna interfaz de red.
5.1.2.1.2.- Prueba 2.1.2
Descripción de la prueba: Comprobar funcionamiento tras pérdida de link de dos de las tarjetas de
red en los servidores.
Fase de realización de la prueba: Tras haber realizado la implantación completa.
Impacto en caso de no pasar la prueba: Revisar la configuración de red y la conexión de los cables
de red del servidor afectado. Este aspecto es crítico para la alta disponibilidad.
Simulación para la realización de la prueba: Soltar el cable de red de dos de las interfaces de red en
el servidor para simular todas y cada una de las situaciones de fallo de dos interfaces de red.
Resultados esperados: Si se pierde la conectividad de dos de las interfaces de red hay situaciones
en las que el nodo no podrá dar servicio. Estos casos se producirán cuando el fallo se produzca en
las dos interfaces de la red pública o de la red privada respectivamente.
Resultados obtenidos:
Servidor Tarjeta Puerto Interfaz Estado
1 Estado
2 Estado
3 Estado
4 Estado
5 Estado
6
ENT900PD00 Integrada 1 Pública Down Down Down Up Up Up
ENT900PD00 Integrada 2 Privada Down Up Up Down Down Up
ENT900PD00 PCI 1 Pública Up Down Up Down Up Down
ENT900PD00 PCI 2 Privada Up Up Down Up Down Down
Resultados: OK Error OK OK Error OK
Servidor Tarjeta Puerto Interfaz Estado
1 Estado
2 Estado
3 Estado
4 Estado
5 Estado
6
ENT900PD01 Integrada 1 Pública Down Down Down Up Up Up
ENT900PD01 Integrada 2 Privada Down Up Up Down Down Up
ENT900PD01 PCI 1 Pública Up Down Up Down Up Down
ENT900PD01 PCI 2 Privada Up Up Down Up Down Down
Resultados: OK Error OK OK Error OK
En el estado 2 se produce un error en el nodo afectado puesto que pierde la conectividad de todas
las interfaces de la red pública por la que acceden los clientes.
En el estado 5 se produce un error en el nodo afectado puesto que pierde la conectividad de todas
las interfaces de la red pública por la que se comunican los servicios del clúster.
En estos dos casos el servicio pasa al otro de los nodos en caso de estar activo.
En el resto de los casos sigue funcionando el clúster con normalidad.
Casos especiales: Si coincide que en los dos nodos se produce el estado 2 o el estado 5 el clúster
fallará dejando de dar servicio.
95
5.1.2.1.3.- Prueba 2.1.3
Descripción de la prueba: Comprobar funcionamiento tras pérdida de link de tres o cuatro de las
tarjetas de red en los servidores.
Fase de realización de la prueba: Tras haber realizado la implantación completa.
Simulación para la realización de la prueba: Soltar el cable de red tres o cuatro de las interfaces de
red en el servidor para simular todas y cada una de las situaciones de fallo.
Resultados esperados: Con la pérdida de tres o cuatro interfaces de red en un servidor se producirá
un fallo en el nodo puesto que siempre se dará el caso de que se pierdan las dos interfaces de las
redes pública o privada (o ambas por pérdida total de red en el caso de soltar las cuatro interfaces).
Resultados obtenidos:
Servidor Tarjeta Puerto Interfaz Estado
1 Estado
2 Estado
3 Estado
4 Estado
5
ENT900PD00 Integrada 1 Pública Down Down Down Up Down
ENT900PD00 Integrada 2 Privada Down Down Up Down Down
ENT900PD00 PCI 1 Pública Down Up Down Down Down
ENT900PD00 PCI 2 Privada Up Down Down Down Down
Resultados: Error Error Error Error Error
Servidor Tarjeta Puerto Interfaz Estado
1 Estado
2 Estado
3 Estado
4 Estado
5
ENT900PD01 Integrada 1 Pública Down Down Down Up Down
ENT900PD01 Integrada 2 Privada Down Down Up Down Down
ENT900PD01 PCI 1 Pública Down Up Down Down Down
ENT900PD01 PCI 2 Privada Up Down Down Down Down
Resultados: Error Error Error Error Error
En la prueba se confirma que en estos casos se pierde siempre el nodo. El servicio pasa al otro
nodo del clúster en caso de estar disponible. Si la situación se produce en ambos nodos, entonces
se pierde el servicio del clúster.
5.1.2.2.- Problema a nivel de switches de red
5.1.2.2.1.- Prueba 2.2.1
Descripción de la prueba: Comprobar el funcionamiento del clúster tras caída de uno de los
switches donde están conectados los dispositivos.
Fase de realización de la prueba: Tras haber realizado la implantación completa.
96
Impacto en caso de no pasar la prueba: En caso de no pasar la prueba se ha de revisar la conexión
del cableado de red a los switches para verificar que cada uno de los cables está conectado a ellos
de forma redundante para garantizar la disponibilidad del sistema.
Simulación para la realización de la prueba: Detener alternativamente cada uno de los switches de
red para simular un posible fallo en cada uno de ellos.
Resultados esperados: Si se detiene uno de los switches, el clúster debe estar conectado de tal
forma que sea capaz de seguir dando servicio. En el caso de detener ambos switches de red cada
nodo del clúster se quedará sin conectividad de red de forma que dejará de dar servicio (este
último caso es normal que provoque el fallo pero se realizará por completitud en las pruebas).
Resultados obtenidos: En la siguiente tabla se observan los resultados para los dispositivos en cada
uno de los casos de la prueba:
Dispositivo Tarjeta Interfaz Caída switch 4
Caída switch 6
Caída ambos
Nodo ENT900PD00 Integrada 1 Down Up Down
Nodo ENT900PD00 Integrada 2 Down Up Down
Nodo ENT900PD00 PCI 1 Up Down Down
Nodo ENT900PD00 PCI 2 Up Down Down
Nodo ENT900PD00 DRAC N/A Up Down Down
Nodo ENT900PD01 Integrada 1 Down Up Down
Nodo ENT900PD01 Integrada 2 Down Up Down
Nodo ENT900PD01 PCI 1 Up Down Down
Nodo ENT900PD01 PCI 2 Up Down Down
Nodo ENT900PD01 DRAC N/A Down Up Down
Switch fibra(sw29) N/A Ethernet Down Up Down
Switch fibra(sw30) N/A Ethernet Up Down Down
Cabina almacenamiento SPA Ethernet Down Up Down
Cabina almacenamiento SPB Ethernet Up Down Down
Estado del clúster: Operativo Operativo Caído
En los casos de caída de sólo uno de los switches el clúster sigue operativo ya que cada nodo
dispone de una tarjeta para cada una de las redes de clúster (pública/privada). En cuanto al resto
de dispositivos, el estado no es directamente influyente como se especificará en la siguiente
prueba.
5.1.2.3.- Pérdida de conexión de disposi tivos involucrados
5.1.2.3.1.- Prueba 2.3.1
Descripción de la prueba: Comprobar el funcionamiento del clúster si se produce una caída de red
en los dispositivos involucrados en el clúster. No se tendrán en cuenta la conectividad de las
interfaces de red de los nodos pues ya se han hecho las pruebas exhaustivas anteriormente.
Fase de realización de la prueba: Tras haber realizado la implantación completa.
97
Impacto en caso de no pasar la prueba: En caso de producirse problemas de red en los dispositivos
sería bajo en el peor de los casos.
Simulación para la realización de la prueba: Soltar los cables de red de los dispositivos involucrados
para verificar el impacto sobre el clúster.
Resultados esperados: En esta prueba, al haber diferentes dispositivos, hay que especificar los
resultados en cada uno de ellos:
- Tarjetas DRAC de servidores: En caso de caída de la DRAC de servidores se provocará que no se
podrá hacer fencing del nodo afectado si ocurriese algún problema en él.
- Switches de fibra: No debería tener ningún impacto a nivel de funcionamiento del clúster
puesto que esta interfaz es únicamente para gestión remota de éstos.
- Cabina de almacenamiento: No debería tener ningún impacto a nivel de funcionamiento del
clúster puesto que esta interfaz es únicamente para gestión remota de éstos.
Resultados obtenidos: Los resultados obtenidos se organizarán como en el apartado de los
esperados para diferenciar el impacto sobre el sistema.
- Tarjetas DRAC: OK. Se observa que si se fuerza un fencing del nodo cuya tarjeta DRAC no está
disponible aparece un error al no poder acceder a ella.
- Switches de fibra: OK.
- Cabina de almacenamiento: OK.
5.1.3.- Pruebas de error a nivel eléctrico
5.1.3.1.- Error a nivel de SAI
5.1.3.1.1.- Prueba 3.1.1
Descripción de la prueba: Esta prueba recoge el caso de pérdida de redundancia de alimentación
de los dispositivos producido por el error en alguno de los SAI a los que están conectados.
Fase de realización de la prueba: Tras haber realizado la implantación completa.
Impacto en caso de no pasar la prueba: En caso de producirse algún problema hay que verificar el
cableado de alimentación de los dispositivos afectados.
Simulación para la realización de la prueba: Parar uno de los SAI involucrados para verificar que el
sistema de clúster funciona correctamente.
Resultados esperados: Con la parada de uno de los SAI deberán quedar activos los dispositivos
suficientes para poder seguir dando servicio.
98
Resultados obtenidos: Una vez realizada la parada de cada uno de los SAI el sistema sigue
funcionando correctamente. Los dispositivos que quedan activos en la parada de cada uno de ellos
son:
- 2 x Switches de red (al disponer un módulo diseñado para que dispongan doble fuente de
alimentación).
- 2 x Nodos.
- 1 x Switch de fibra.
- 2 x Controladora de la cabina de almacenamiento (La propia cabina de almacenamiento tiene
un SAI interno para cubrir temporalmente una caída de suministro eléctrico).
5.1.3.2.- Pérdida de suministro e léctrico externo
5.1.3.2.1.- Prueba 3.2.1
Descripción de la prueba: Esta prueba recoge el caso de pérdida de alimentación externa.
Fase de realización de la prueba: Tras haber realizado la implantación completa.
Impacto en caso de no pasar la prueba: En caso de producirse algún problema habrá que contactar
con el soporte técnico de los SAI ya que son los que se verían afectados por este problema.
Simulación para la realización de la prueba: Bajar los diferenciales del cuadro de luz que dan
alimentación a los dos SAI para que estos detecten que han perdido la entrada de corriente.
Resultados esperados: Una vez detectado el fallo, los SAI entrarán en batería y mandarán correo
electrónico para avisar de la situación.
Resultados obtenidos: En cuanto los SAI detectan el fallo entran en batería, envían el correo para
avisar y revisando las pantallas muestra que tendrían una autonomía de más de 30 minutos lo cual
permitiría realizar una parada correcta del sistema.
5.1.4.- Pruebas de error a nivel de almacenamient o
5.1.4.1.- Pérdida de conectividad de fibra a nivel de servidor
5.1.4.1.1.- Prueba 4.1.1
Descripción de la prueba: Comprobar el acceso de los servidores al almacenamiento en los casos en
los que se pierda la conectividad de fibra en éstos de una o de las dos interfaces.
Fase de realización de la prueba: Tras haber realizado la implantación completa.
Impacto en caso de no pasar la prueba: Revisar la conexión de los cables de fibra y la configuración
de éstas en los servidores, los switches de fibra y la cabina.
99
Simulación para la realización de la prueba: Soltar uno o dos cables de fibra de una de las interfaces
de fibra en el servidor para probar la caída de todas y cada una de ellas.
Resultados esperados: Los resultados dependen de cada uno de los casos:
- Pérdida de una interfaz de fibra: El servidor pierde la conectividad por dos de los cuatro
caminos que tiene disponibles para acceso a la cabina. El clúster seguiría funcionando con
normalidad.
- Pérdida de dos interfaces de fibra: El servidor pierde la conectividad de los cuatro caminos que
tiene disponibles. El clúster detecta que el nodo no accede al disco de quórum y el otro nodo
lo reclama para poder dar el servicio y fuerza el reinicio del nodo afectado para que libere
todos los recursos restantes para poder dar servicio.
Resultados obtenidos:
Servidor Tarjeta Puerto Estado 1 Estado 2 Estado 3
ENT900PD00 F.O. 1 Down Up Down
ENT900PD00 F.O. 2 Up Down Down
Resultados: OK OK Error y balanceo.
Servidor Tarjeta Puerto Estado 1 Estado 2 Estado 3
ENT900PD01 F.O. 1 Down Up Down
ENT900PD01 F.O. 2 Up Down Down
Resultados: OK OK Error y balanceo.
En el caso en el que se pierde la conectividad de los dos puertos de fibra, el clúster se balancea al
otro nodo y el afectado es reiniciado por éste.
5.1.4.2.- Pérdida de conectividad de fibra a nivel de switch
5.1.4.2.1.- Prueba 4.2.1
Descripción de la prueba: Comprobar el acceso de los servidores al almacenamiento en los casos en
los que se pierda la conectividad de fibra en alguno de los switches de fibra.
Fase de realización de la prueba: Tras haber realizado la implantación completa.
Impacto en caso de no pasar la prueba: Revisar la conexión de los cables de fibra y la configuración
de éstas en los servidores, los switches de fibra y la cabina.
Simulación para la realización de la prueba: Desconectar la alimentación de los switches de fibra de
forma alterna para probar los casos de caída de cada uno de ellos.
Resultados esperados: Los resultados dependen de cada uno de los casos:
100
- Pérdida de uno de los switches: Ambos nodos pierden la conectividad a través de una de las
interfaces de fibra que es la que va conectada al switch que no esté disponible. A cada uno le
quedarían dos de los cuatro caminos disponibles pudiendo funcionar con normalidad.
- Pérdida de los dos switches: Ambos servidores pierden la conectividad de los cuatro caminos
que tiene disponibles. Al perder la conectividad con el almacenamiento ambos nodos se
produce un error del clúster y se para el servicio.
- Resultados obtenidos:
Switch Estado 1 Estado 2 Estado 3
sw29 Down Up Down
sw30 Up Down Down
OK OK Error
5.1.4.3.- Pérdida de conectiv idad de fibra a nivel de cabina
5.1.4.3.1.- Prueba 4.3.1
Descripción de la prueba: Comprobar el acceso de los servidores al almacenamiento en los casos en
los que se pierda la conectividad de fibra en alguna de las controladoras de la cabina.
Fase de realización de la prueba: Tras haber realizado la implantación completa.
Impacto en caso de no pasar la prueba: Revisar la conexión de los cables de fibra y la configuración
de éstas en los servidores, los switches de fibra y la cabina.
Simulación para la realización de la prueba: Desconectar el cable de fibra de cada una de las
controladoras de la cabina alternativamente.
Resultados esperados: Los resultados dependen de cada uno de los casos:
- Pérdida de una de las controladoras: Ambos nodos pierden la conectividad a través de un
camino de cada una de las interfaces de fibra que es la que va conectada a la controladora que
no está disponible. A cada uno le quedarían dos de los cuatro caminos disponibles pudiendo
funcionar con normalidad.
- Pérdida de las dos controladoras: Ambos servidores pierden la conectividad de los cuatro
caminos que tiene disponibles. Al perder la conectividad con el almacenamiento ambos nodos
se produce un error del clúster y se para el servicio.
- Resultados obtenidos:
Controladora Estado 1 Estado 2 Estado 3
SPA Down Up Down
SPB Up Down Down
OK OK Error
101
5.2.- Fase de producción
5.2.1.- Pruebas de rendimiento
Las pruebas de rendimiento se realizarán una vez está todo el sistema montado, incluyendo el RP
implantado por la empresa consultora externa. Estas pruebas se realizarán como monitorización
una vez puesto en producción con los usuarios accediendo a la aplicación. Lo que realmente se
hace es una monitorización diaria de los sistemas evaluando los tiempos de espera en los procesos
de usuario.
5.2.1.1.- Rendimiento durante e l arranque
5.2.1.1.1.- Prueba P1.1.1
Descripción de la prueba: Esta prueba recoge la monitorización del rendimiento de la plataforma
durante el arranque del nuevo RP.
Fase de realización de la prueba: Tras implantación del RP (Enero 2012).
Impacto en caso de no pasar la prueba: En caso de producirse algún problema hay que verificar la
configuración de la infraestructura por nuestra parte y la configuración del RP por parte de la
consultora externa.
Simulación para la realización de la prueba: Monitorizar acceso de los usuarios a los sistemas y
verificar los tiempos de respuesta que obtienen durante la fase de arranque.
Problemas encontrados: En esta fase de pruebas se han detectado los siguientes problemas:
- Algunos de los procesos que se realizan desde el RP se quedan en espera demasiado tiempo lo
que produce demoras en la realización del trabajo.
o Junto con los consultores se verificó que había un problema conocido con
determinadas versiones de paquetes. Se aplicó la corrección instalando las versiones
recomendadas por el fabricante.
o Junto con los consultores se verificó que para entornos de clúster con
almacenamiento compartido deberían configurarse determinados parámetros de
acceso a disco compartido de una forma determinada. Se aplicó la corrección de los
parámetros recomendados por el fabricante.
5.2.1.2.- Rendimiento en campaña
5.2.1.2.1.- Prueba P1.2.1
Descripción de la prueba: Esta prueba recoge la monitorización del rendimiento de la plataforma
durante las campañas en distintas fábricas.
Fase de realización de la prueba: Durante las campañas (Verano 2012).
102
Impacto en caso de no pasar la prueba: En caso de producirse algún problema hay que verificar la
configuración de la infraestructura por nuestra parte y la configuración del RP por parte de la
consultora externa.
Simulación para la realización de la prueba: Monitorizar acceso de los usuarios a los sistemas y
verificar los tiempos de respuesta que obtienen durante las campañas.
Problemas encontrados: En esta fase de pruebas se han detectado los siguientes problemas:
- Algunos de los procesos del RP se quedaban bloqueados.
o Junto con los consultores se verificó que había un problema de diseño en varios de los
desarrollos del RP que sólo se usan durante la campaña. La empresa consultora
corrigió estos problemas.
5.2.1.3.- Rendimiento en cierre contable
5.2.1.3.1.- Prueba P1.3.1
Descripción de la prueba: Esta prueba recoge la monitorización del rendimiento de la plataforma
durante el cierre contable del año 2012.
Fase de realización de la prueba: Durante el cierre contable (Diciembre 2012 a Enero 2013).
Impacto en caso de no pasar la prueba: En caso de producirse algún problema hay que verificar la
configuración de la infraestructura por nuestra parte y la configuración del RP por parte de la
consultora externa.
Simulación para la realización de la prueba: Monitorizar acceso de los usuarios a los sistemas y
verificar los tiempos de respuesta que obtienen durante el cierre contable.
Problemas encontrados: En esta fase de pruebas no se han detectado problemas.
5.2.1.4.- Rendimiento en circunstancias normales
5.2.1.4.1.- Prueba P1.4.1
Descripción de la prueba: Esta prueba recoge la monitorización del rendimiento de la plataforma
durante el día a día.
Fase de realización de la prueba: Monitorización diaria de la plataforma.
Impacto en caso de no pasar la prueba: En caso de producirse algún problema hay que verificar la
configuración de la infraestructura por nuestra parte y la configuración del RP por parte de la
consultora externa.
Simulación para la realización de la prueba: Monitorizar acceso de los usuarios a los sistemas y
verificar los tiempos de respuesta que obtienen durante el cierre contable.
103
Problemas encontrados: Tras el arranque se detectó que el rendimiento se iba degradando con el
tiempo y los procesos se quedaban en espera cada vez más tiempo.
- Se localizó que el problema de rendimiento era a nivel de acceso a disco compartido. El
problema lo estaba dando la cabina pues mostraba eventos de error en el log. Se avisó al
fabricante y tras diagnosticar el problema instaló una actualización de firmware recomendada
que solucionó el problema.
5.2.2.- Análisis de problemas
5.2.2.1.- Problemas de discos de la cabina
5.2.2.1.1.- Prueba P2.1.1
Problema detectado: Se ha detectado un error de un disco en la cabina.
Situación: En la cabina ha entrado en funcionamiento un disco de reserva para cuando se producen
estos casos.
Solución: Llamar al proveedor para ejecutar la garantía y que envíen un disco para sustituir el
averiado.
Procedimiento realizado: No es necesario realizar ninguna acción sobre el clúster. Basta con sacar
el disco defectuoso de la cabina de almacenamiento y sustituirlo por el que enviaron de reemplazo.
Una vez hecho esto se realiza automáticamente la reconstrucción del RAID sobre el nuevo disco y
desaparece el error.
5.2.2.2.- Problemas de discos en los servidores
5.2.2.2.1.- Prueba P2.2.1
Problema detectado: Se ha detectado un error de uno de los discos en el nodo ENT900PD00.
Situación: El servidor es el que está dando servicio. El sistema sigue en funcionamiento debido a
que están configurados los discos locales en RAID1.
Solución: Llamar al proveedor para ejecutar la garantía y que envíen un disco para sustituir el
averiado.
Procedimiento realizado: Balancear el clúster al otro nodo por seguridad aunque el disco es SAS y
se puede cambiar “en caliente” sin que implique parada del servidor. Se ha preferido hacer de esta
forma ya que durante la reconstrucción del RAID1 tras el cambio del disco se podría degradar el
rendimiento del sistema.
104
5.2.2.3.- Problemas de alimentación e léctrica
5.2.2.3.1.- Prueba P2.3.1
Problema detectado: Avería eléctrica en la fábrica que afecta al CPD.
Situación: Debido a una avería los equipos empiezan a funcionar con la batería de los SAIs.
Solución: Parada organizada de los sistemas para evitar problemas en caso de que se apagase todo
por falta de tensión eléctrica.
Procedimiento realizado: Parada de los sistemas del CPD incluyendo el sistema de clúster con sus
recursos asociados. Posteriormente parada de los SAIs pues no se recomienda que las baterías se
lleguen a agotar completamente. Tras la reparación de la avería se vuelven a arrancar los sistemas
de forma ordenada.
105
6.- Gestión del proyecto
6.1.- Estimación inicial
Inicialmente se hizo una estimación del ciclo de vida incorrecta del proyecto. Estaba planificado
para realizarse para finales de 2011/ primeros de 2012. Esta estimación ha habido que corregirla
por determinadas circunstancias:
- Realización de cursos necesarios para el trabajo en la empresa.
- Necesidad de monitorización del rendimiento en determinadas circunstancias.
- Viajes a las distintas fábricas para despliegue de dispositivos y realización de pruebas con
los usuarios a nivel de rendimiento.
- Modificaciones necesarias en la configuración tras reunión con consultores externos que
han implantado la aplicación.
- Problemas con dispositivos involucrados en el sistema.
- Necesidad de realización de otras tareas en la empresa.
A continuación se detallarán cada una de ellas para especificar las repercusiones que ha tenido
cada una de ellas sobre el ciclo de vida del proyecto.
6.2.- Factores que han afectado al ciclo de vida
6.2.1.- Realización de cursos necesarios para el trabajo en la empre sa
Durante el ciclo de vida del proyecto ha surgido la necesidad de la realización de cursos necesarios
para el desempeño de determinados trabajos en la empresa.
- Curso de organización de CPDs. Dell. 5días. 8h/día.
- Curso de Exchange. Microsoft. 10 días. 8h/día.
- Curso de VMWare. 5 días. 8h/día.
6.2.2.- Monitorización de rendimiento en determinadas circunstancias
Se consideró necesario por parte de la empresa la evaluación del rendimiento del sistema en
determinadas circunstancias para evitar que produzca una parada de servicio de la producción. Se
planteó evaluar el rendimiento fue en las siguientes circunstancias:
- En el arranque del nuevo RP con el fin de detectar errores y verificar si el
dimensionamiento realizado para los sistemas ha sido correcto.
- Durante las campañas en las diferentes fábricas. Esto es debido a que durante esta época
del año es cuando más usuarios concurrentes acceden a la aplicación. Esto es necesario ya
que el rendimiento se puede ver afectado.
106
- Durante el cierre contable. Esto es debido a que para hacer el cierre contable se lanzan
una serie de procesos que tienen que consultar a todos los datos del año y que podría a
llegar a degradar el rendimiento del sistema.
Esto implica un seguimiento durante todo el año puesto que el arranque es en enero, las
campañas son durante el verano y el cierre es a final de año e inicio del siguiente.
6.2.3.- Viajes a las distintas fábricas
Durante el ciclo de vida del proyecto ha sido necesario desplazarse a las distintas fábricas durante
semanas completas para realización de distintas labores:
- Despliegue de dispositivos y pruebas. El nuevo RP incorpora nuevas funcionalidades que
implican el despliegue de dispositivos adicionales en distintos puntos de las fábricas para
controlar el proceso productivo. Este despliegue es necesario para evaluar el rendimiento.
- Verificar la experiencia del usuario final evaluando el tiempo de respuesta del sistema a la
hora de realizar procesos cotidianos.
Cada vez que toca viajar a las fábricas de las provincias de Toledo o Cáceres implica la semana
completa entre el viaje de ida/vuelta y la estancia en la fábrica para realizar las labores necesarias.
6.2.4.- Necesidad de incorporación de modificaciones
El equipo de consultoría externa pasó una serie de recomendaciones tras el arranque que obligaron
a hacer modificaciones en el sistema implantado. Estas modificaciones incluían:
- Actualización de paquetes a excepción de los de kernel en los sistemas operativos de los
servidores.
- Modificación de parámetros recomendados por el fabricante para la implantación de la
solución en sistemas clusterizados.
Estas tareas han implicado hacer las correcciones precisas tanto como las posteriores pruebas de la
aplicación para verificar que funciona correctamente.
6.2.5.- Problemas con dispo sitivos del sistema
Se han producido diferentes problemas durante el ciclo de vida del proyecto que han afectado al
ciclo de vida.
- Problemas de rendimiento interno de la cabina de almacenamiento. Hubo que contactar
con el fabricante de ésta para analizar el problema que estaba sucediendo. Tras realizar el
análisis hubo que hacer una actualización de firmware.
- Necesidad de cambio de piezas en servidores del clúster por avería de estas.
- Avería en un switch de fibra óptica que hubo que reemplazar teniendo que monitorizar el
impacto de rendimiento por haberse perdido caminos de conexión a la cabina de
almacenamiento.
107
Cada una de ellas implicó, tras el cambio, a hacer un análisis del sistema para verificar que todo
funcionaba como es debido.
6.2.6.- Necesidad de realizació n de otras tareas en la empresa
Durante el ciclo de vida ha sido necesario realizar otras tareas dentro de la empresa que han
implicado tiempo dedicado a ellas. Las tareas realizadas son las siguientes:
- Migración de la infraestructura de correo a la nueva versión de Excahnge 2010.
- Migración de servidores a las nuevas versiones de sistema operativo.
- Ampliación de la infraestructura de virtualización.
-
6.3.- Comparativas
6.3.1.- Comparativa de horas estimadas con las reales
En el gráfico se aprecia que hay una gran desviación de las horas estimadas inicialmente con las
reales dedicadas al proyecto. El principal objeto de desvío ha sido la necesidad de monitorización
tras la entrada del sistema en producción en determinadas circunstancias repartidas a lo largo del
primer año tras la implantación.
6.3.2.- Repartición en tareas de las hor as reales dedicadas al proyecto
0
500
1000
1500
Estimadas Reales
Horas
Horas
Reparto de horas
Contacto inicial
DOP
Análisis y diseño
Implantación
Pruebas
108
En el gráfico se aprecia el reparto del tiempo dedicado a cada una de las tareas del proyecto. Se
observa que el mayor tiempo es el dedicado a pruebas debido a la monitorización que ha habido
que realizar durante el primer año tras implantar el sistema.
6.3.3.- Comparativa de l as tareas a lo largo del tiempo
Las mayores desviaciones se aprecian en los siguientes niveles:
- Período de pruebas: Se ha producido una dilatación en el tiempo debido a la necesidad de
monitorizar el sistema una vez puesto en producción para evaluar el rendimiento.
- Realización de la documentación: La desviación en la realización de la documentación se
debe a no haberla dejado organizada directamente en cada una de las fases anteriores del
proyecto. Esto ha implicado tener que volver a recopilar determinada información para
elaborar los documentos lo que ha provocado una mayor dedicación de tiempo.
6.4.- Conclusiones
Las conclusiones que se desprenden tras analizar los factores que se presentan en este documento
se podrían englobar en tres factores principales:
- Realización de otras tareas necesarias en la empresa: Ha producido retraso en la
realización respecto a la planificación original la necesidad de desempeñar otras labores
para la empresa durante la realización del proyecto.
- Ampliación de las necesidades para aceptar el sistema: Lo que más desviación ha
producido con respecto a la planificación original es la necesidad que surgió de hacer
pruebas y monitorizaciones del sistema una vez puesto en producción. Al tener que
10-09-11 28-03-12 14-10-12 02-05-13
Tiempo estimado
Tiempo real Contacto inicial
DOP
Análisis y diseño
Implantación
Pruebas
Documentación
109
realizarlas en momentos puntuales dispersos en el tiempo (Primeros de año, verano y
finales de año) ha producido que se haya tenido que ampliar el tiempo dedicado a la
realización de pruebas.
- Falta de organización a la hora de realizar determinadas tareas: Esto se refiere a la
realización de la documentación. Si se hubiese realizado la documentación conforme se
desarrollaban cada una de las tareas no habría sido necesario tanto tiempo ya que es más
sencillo y rápido ir documentando lo que se va haciendo en cada momento que a
posteriori.
Una vez descritas las causas se puede analizar las partes que se podrían haber optimizado para el
cumplimiento de la planificación original:
- Los dos primeros factores que han implicado la mayor desviación no se pueden optimizar
debido a que son necesidades de la empresa para la cual se está desarrollando el
proyecto.
- En cuanto a la última es un error personal que se debería haber tenido en cuenta
110
111
Anexo I: Instalación del sistema operativo en los servidores
En este anexo se explica la instalación del sistema operativo en los servidores. Los pasos a seguir
son los siguientes:
- Arranque del sistema desde la unidad del DVD de instalación del sistema operativo. Elegir la
opción “OK” para que verifique que el DVD está correcto.
- Seleccionar la opción “Next” para comenzar con la instalación.
112
- El sistema operativo se instalará en inglés por recomendación de Oracle para su software.
- Seleccionar la distribución del teclado en español.
113
- El asistente preguntará si se quieren inicializar los discos disponibles. Seleccionar “Ok” y seguir
con el siguiente paso de la instalación.
- Elegir la opción de “Create custom layout” para crear un diseño personalizado de las
particiones en el desplegable y pulsar el botón “Next”.
- Crear las particiones considerando separar en distintos discos los puntos de montaje / y /home
y considerando que la partición para paginado está en distinto disco del punto de montaje /.
Con ello se pretende distribuir la carga de lectura/escritura en disco. El diseño queda como
sigue:
Punto de montaje Sistema de
ficheros
Tamaño (MB) Tipo Disco
/boot Ext3 101 Primaria /dev/sda1
/ Ext3 75673 Primaria /dev/sda2
N/A Swap 8189 Primaria /dev/sdb1
/tmp Ext3 6142 Primaria /dev/sdb2
/home Ext3 61443 Primaria /dev/sdb3
114
- Elegir la partición en la que se instalará el cargador de arranque GRUB. Solo muestra una
opción que es la del punto de montaje raíz, pulsar sobre “Next”.
- En la siguiente pantalla se solicitan los parámetros de red y el hostname del servidor. El
hostname debe ser el mismo para ambos por restricciones de la aplicación de Oracle que se va
a ejecutar sobre ellos (ENT900PD). La red por el momento dejar la configuración por defecto
por DHCP pues se configurará en la siguiente fase.
115
- Elegir la zona horaria en el mapa, dejar marcado el check que dice que el reloj usa UTC y pulsar
sobre continuar.
- Elegir la contraseña para el superusuario (root) y pulsar sobre “Next”.
116
- Elegir la opción “Customize now” para personalizar los paquetes que se instalarán y pulsar
sobre “Next”.
- Elegir los siguientes paquetes elementos para instalar y después darle a “Next”:
Desktop Environments. o GNOME Desktop Environment.
Applications. o Editors. o Graphical Internet. o Text-based Internet.
Development. o Develpment Libraries. o Development Tools. o Legacy Software Development.
Servers. o Printing support.
Base System. o Administration Tools. o Base. o Java. o Legacy Software Support. o System Tools. o Xwindow System.
Cluster Storage. o Cluster Storage.
Clustering. o Clustering.
Virtualization. o N/A.
Language Support. o Spanish Support.
117
- El sistema comprobará las dependencias entre los paquetes y las seleccionará
automáticamente para su instalación.
- Pulsar sobre el botón “Next” para comenzar con el proceso de instalación del sistema
operativo. El asistente realizará todas las tareas necesarias para la instalación hasta que haya
finalizado.
118
- Una vez finalizada la instalación, retirar el DVD de la unidad y pulsar sobre el botón
“Reboot” para iniciar la nueva instalación de Oracle Enterprise Linux.
- En el primer arranque del sistema operativo aparecerá un asistente para configurar ciertos
parámetros básicos por el sistema operativo.
119
- Una vez revisado el acuerdo de licencia, elegir la opción para aceptarlo y pulsar sobre el botón
“Forward”.
- Al ser un sistema que va a estar en la red interna y no en la perimetral o DMZ, no se va a
activar ni firewall ni SElinux. En las fases de dicha configuración seleccionar la opción
“Disabled” y pulsar sobre el botón “Forward.
120
- No se necesitará tener activado Kdump por lo que se deja el check sin marcar y se sigue con el
siguiente paso del asistente.
- Establecer la fecha y la hora del sistema y seguir con el siguiente paso.
121
- No es necesaria la creación de ningún usuario por el momento. Seguir con el siguiente paso del
asistente.
- El servidor no dispone de tarjetas de sonido por lo que continuaremos con la siguiente fase de
la instalación.
122
- No es necesario añadir ningún CD o DVD adicional para la instalación de paquetes ya que la
instalación o actualizaciones de paquetes en el futuro se hará a través de los repositorios en
red.
123
Anexo II: Manual de explotación por línea de comandos
Administración básica del clúster
A la hora de arrancar los nodos, automáticamente se arrancan en cada uno de ellos los siguientes
servicios de forma ordenada:
- Cman: Servicios del clúster.
- Clvmd: Servicios de almacenamiento compartido para el clúster.
- Rgmanager: Servicio encargado del control de los recursos y servicios configurados en el
clúster.
Comprobar el estado del clúster
Para comprobar el estado del clúster lo primero que hay que comprobar es el estado de cada uno
de los servicios mediante los comandos:
# service cman status
# service clvmd status
# service rgmanager status
Una vez verificados los servicios se puede ver el estado completo del clúster mediante el comando:
# clustat
Arranque de los servicios del clúster
En caso de necesidad de arrancar los servicios del clúster de forma manual, hay que hacerlo en el
orden correcto. Si no se hiciese así podría haber problemas de dependencias entre ellos
provocando que el sistema fuese inconsistente.
Los servicios hay que arrancarlos en el siguiente orden:
1.- Servicio del clúster.
# service cman start
2.- Servicio de almacenamiento compartido para el clúster.
# service clvmd start
3.- Servicios para la gestión de recursos y servicios configurados dentro del clúster.
# service rgmanager start
Los logs del clúster se almacenan en el fichero /var/log/messages por lo que se puede verificar que
todo ha arrancado correctamente.
124
Parada de los servicios del clúster
Al igual que para el arranque, la parada debe hacerse en un orden determinado que sería el inverso
al orden de arranque:
1.- Servicio para la gestión de recursos y servicios configurados dentro del clúster.
# service rgmanager stop
2.- Servicio de almacenamiento compartido para el clúster.
# service clvmd stop
3.- Servicio del clúster.
# service cman stop
Los logs de la parada de los servicios también se guardan en el fichero /var/log/messages. Se puede
verificar en él que la parada se ha realizado correctamente.
Habilitar / Deshabilitar servicios del clúster
A veces es necesario deshabilitar los servicios del clúster en algún nodo para poder llevar a cabo
tareas de mantenimiento sin que el fencing fuerce un reinicio de la máquina.
Esta función sólo es necesaria si se quieren habilitar/deshabilitar que los servicios arranquen con el
sistema operativo. Si sólo se desean parar momentáneamente bastaría con pararlos tal y como se
explica en el apartado anterior.
En este caso el orden de realización de los pasos no es importante y se haría como sigue:
-Habilitar/Deshabilitar servicio de gestión de recursos y servicios clusterizados.
# chkconfig --level 2345 rgmanager [on|off]
-Habilitar/deshabilitar servicio de almacenamiento compartido para el clúster.
# chkconfig --level 2345 clvmd [on|off]
-Habilitar/deshabilitar servicio del cluster.
# chkconfig --level 2345 cman [on|off]
125
Gestión del cluster mediante Conga
El clúster se puede gestionar de diferentes formas:
- Mediante herramientas de línea de comandos (CLI).
- Mediante herramientas gráficas (GUI).
- Mediante conga (conjunto de software integrado para gestión Web del clúster y
almacenamiento).
Conga se compone de dos servicios que son:
- Luci: Servicio de la consola de gestión Web.
- Ricci: Agente que permite a un nodo ser gestionado por Conga con el fin de mantener
actualizada la configuración en todos ellos. Debe estar arrancado en todos y cada uno de
ellos.
Para la gestión de los servicios de Conga se hará mediante los comandos:
# service luci [status|start|stop]
# service ricci [status|start|stop]
El acceso a la gestión se hace a través del navegador Web utilizando la siguiente URL:
https://ENT900PD00.cidacos.com:8084/luci
Usuario: admin Password: P@ssw0rd
126
127
Anexo III: Actas
Acta 1.
Asistentes: Eloy Javier Mata Sotés, Eduardo Sáenz de Cabezón Irigaray, Alberto Díez Escobés.
Fecha: 10 de septiembre de 2011.
Motivo: Contacto inicial.
Temas a tratar:
Toma de contacto inicial.
Acordar tema del proyecto y alcance del mismo.
Evaluar la documentación a presentar.
Tareas a realizar:
Documento de descripción del proyecto.
Documento sobre la empresa.
Comenzar con el documento de objetivos del proyecto.
128
Acta 2.
Asistentes: CNC empresa consultora externa, Alberto Díez Escobés.
Fecha: 27 de octubre de 2011.
Motivo: Concretar detalles técnicos.
Temas a tratar:
Versiones de paquetes del sistema operativo.
Sistemas de ficheros necesarios tanto los clusterizados como los no clusterizados.
Arquitectura del sistema (x86 ó x86_64).
Puntos de montaje para las unidades de almacenamiento compartido.
Necesidades generales para el aplicativo que tienen que montar.
Planes de pruebas para dar por válida la configuración del clúster para garantizar la alta
disponibilidad.
Temas concretados:
Inicialmente la única restricción vendrá a nivel del Kernel que será el que viene por defecto en la
versión 5 Update 5 de Oracle Enterprise Linux.
Los sistemas de ficheros serán ext3 para el almacenamiento local y GFS2 para el almacenamiento
compartido.
La arquitectura del sistema será de 64 bits (x86_64).
Sólo es necesario un punto de montaje compartido que estará localizado en /opt/jdedwards.
Se requiere de recurso de compartición de ficheros Samba y servicios de impresión clusterizados.
Definición de los niveles de pruebas a realizar para dar por válido el sistema.
129
Acta 3.
Asistentes: Responsable de sistemas de Cidacos, Alberto Díez Escobés.
Fecha: 7 de noviembre de 2011.
Motivo: Concretar detalles de diseño.
Temas a tratar:
Revisar las distintas alternativas de diseño.
Evaluar el hardware/software disponible.
Evaluar los posibles costes de las alternativas.
Elegir la alternativa más válida para el correcto funcionamiento de la infraestructura.
Temas concretados:
Se deja concretada la alternativa a seguir para poder implantarla en el sistema.
130
Acta 4.
Asistentes: Responsable de sistemas de Cidacos, CNC empresa consultora externa, Alberto Díez
Escobés.
Fecha: 9 de diciembre de 2011.
Motivo: Revisión de la plataforma desplegada.
Temas a tratar:
Revisar la plataforma implantada.
Temas concretados:
Se revisa la plataforma que se ha implantado para validar que satisface las necesidades.
El CNC de la empresa consultora valida que los paquetes necesarios están instalados en las
versiones correctas, arquitectura del sistema, servicios necesarios.
Se establece fecha para poder hacer las pruebas del sistema.
131
Acta 5.
Asistentes: Responsable de sistemas de Cidacos, CNC empresa consultora externa, Alberto Díez
Escobés.
Fecha: 16 de diciembre de 2011.
Motivo: Realización de las pruebas.
Temas a tratar:
Llevar a cabo las pruebas planteadas para la aceptación del sistema.
Temas concretados:
Tras realizar las pruebas se verifican los fallos detectados para corregirlos y una vez resueltos volver
a probar para aceptar el entorno inicial.
El equipo de consultoría externo comenzará a partir de ese momento la implantación de los
módulos necesarios del RP.
132
Acta 6.
Asistentes: CNC empresa consultora externa, Alberto Díez Escobés.
Fecha: 4 de enero de 2012.
Motivo: Evaluación de errores en el arranque.
Temas a tratar:
Evaluar los errores aparecidos durante los dos primeros días de arranque.
Temas concretados:
Los errores detectados dependen de otras partes de la infraestructura de red y del diseño de
algunos de los desarrollos personalizados realizados por la empresa consultora externa.
Se establece plan de acción por parte de la consultora externa para solucionar los problemas.
Se concretan los errores en infraestructura de red interna para solución a la mayor brevedad.
133
Acta 7.
Asistentes: Responsable de sistemas de Cidacos, CNC empresa consultora externa, Alberto Díez
Escobés.
Fecha: 27 de enero de 2012.
Motivo: Evaluación de las correcciones de errores del arranque.
Temas a tratar:
Validar las modificaciones realizadas para solventar los errores ocurridos durante el arranque.
Temas concretados:
Validar que los errores a nivel de la aplicación están corregidos.
Validar que los problemas surgidos a nivel de la infraestructura de red están corregidos.
134
Acta 8.
Asistentes: Responsable de sistemas de Cidacos, CNC empresa consultora externa, Alberto Díez
Escobés.
Fecha: 1 de junio de 2012.
Motivo: Organización de las pruebas para la campaña.
Temas a tratar:
Organizar las pruebas a realizar durante la campaña en las distintas fábricas.
Temas concretados:
Cuadrar las fechas de inicio y fin de las campañas en cada una de las fábricas.
Evaluar los puntos críticos en los que hay mayor afluencia de usuarios.
Organizar la monitorización a realizar de los sistemas.
135
Acta 9.
Asistentes: Responsable de sistemas de Cidacos, CNC empresa consultora externa, Alberto Díez
Escobés.
Fecha: 30 de octubre de 2012.
Motivo: Evaluación de problemas y soluciones aplicadas durante la campaña.
Temas a tratar:
Analizar los problemas ocurridos en el sistema durante la campaña.
Validar las modificaciones realizadas para solucionar los errores ocurridos durante la campaña.
Temas concretados:
Impacto de cada uno de los problemas.
Áreas afectadas por cada uno de los problemas.
Validar que los errores a nivel de aplicación están corregidos.
Validar que las averías se han solucionado con las medidas tomadas.
Validar que los sistemas están estables tras todas las correcciones.
136
Acta 10.
Asistentes: Responsable de sistemas de Cidacos, CNC empresa consultora externa, Alberto Díez
Escobés.
Fecha: 15 de enero de 2013.
Motivo: Evaluación de problemas y soluciones aplicadas durante el cierre contable.
Temas a tratar:
Analizar los problemas ocurridos en el sistema durante la campaña.
Validar las modificaciones realizadas para solucionar los errores ocurridos durante la campaña.
Temas concretados:
Evaluación de errores a nivel de aplicación.
Validación que los errores a nivel de aplicación han sido corregidos.
137
Acta 11.
Asistentes: Eloy Javier Mata Sotés, Eduardo Sáenz de Cabezón Irigaray, Alberto Díez Escobés.
Fecha: 19 de junio de 2013.
Motivo: Validación de la documentación aportada.
Temas a tratar:
Revisar la documentación aportada.
Temas concretados:
Modificación de algunos aspectos en la documentación.
Organización de la memoria.
Cuadrar fechas y documentación necesaria para depósito y defensa del proyecto.
top related