Crear un entorno de alta disponibilidad para determinados recursos ...

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: [email protected]

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.

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.

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.


la consola de gestión de los propios servidores a través de interfaz web (DRAC – Dell Remote

Access Controller).


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.


- 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).


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.


- 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.


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 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 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 Puerto 1 controladora B de la cabina.

- Zona 3.


o Puerto 1 controladora A de la cabina.

- Zona 4.


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.


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.


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.

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 PCI, puerto 1: Módulo 6 switches redundantes, puerto 9.


28

Tarjetas de fibra:

o Tarjeta 1, puerto 1: Switch de fibra 1, 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.


4.1.2.- Nodo 2 del clúster

Nombre gestión: ENT900PD01

Hostname: ENT900PD

Tarjetas de red:





Tarjetas de fibra:



Tarjeta DRAC (Dell Remote Access Controller): Módulo 4 switches redundantes, puerto 41.

Fuentes de alimentación:



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


4.1.5.- Controladora A de la cabina de almacenamiento

Nombre gestión: trancosa

Hostname: trancos


4.1.6.- Controladora B de la cabina de almacenamiento

Nombre gestión: trancosb

Hostname: trancos


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




exit




exit




exit


description 'CX310C_SPA'


exit


description 'DRAC_ENT900PD01'


exit


description 'SW29_FC_GESTION'


exit




exit




exit




exit




exit

32


description 'CX310C_SPB'


exit


description 'DRAC_ENT900PD00'


exit


description 'SW30_FC_GESTION'


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:

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


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


DEVICE=eth1

BOOTPROTO=none


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


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


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


TYPE=BOND

BOOTPROTO=none

37

4.3.3.2.3.- Ifcfg-eth0


DEVICE=eth0

BOOTPROTO=none


ONBOOT=yes

TYPE=Ethernet

USERCTL=no

IPV6INIT=no

PEERDNS=no

MASTER=bond0

SLAVE=yes

4.3.3.2.4.- Ifcfg-eth1


DEVICE=eth1

BOOTPROTO=none


ONBOOT=yes

TYPE=Ethernet

USERCTL=no

IPV6INIT=no

PEERDNS=no

MASTER=bond1

SLAVE=yes

4.3.3.2.5.- Ifcfg-eth2


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


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



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.

http://public-yum.oracle.com/

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.

https://ent900pd00:8084/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...
















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


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:


- 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


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:


- 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.

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


Resultados esperados: El servidor debe tener conectividad con las interfaces de red de todos los

dispositivos involucrados.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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


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.


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).



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


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.


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 PCI 1 Up Down Down


Nodo ENT900PD00 DRAC N/A 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.


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.


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.


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.


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.


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


los que se pierda la conectividad de fibra en alguno de los switches de fibra.




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.


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


los que se pierda la conectividad de fibra en alguna de las controladoras de 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.


- 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


durante las campañas en distintas fábricas.

Fase de realización de la prueba: Durante las campañas (Verano 2012).

102



consultora externa.


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


durante el cierre contable del año 2012.

Fase de realización de la prueba: Durante el cierre contable (Diciembre 2012 a Enero 2013).



consultora externa.


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


durante el día a día.

Fase de realización de la prueba: Monitorización diaria de la plataforma.



consultora externa.


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

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

https://ent900pd00.cidacos.com:8084/luci

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.


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.


Escobés.


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.


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.


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.


Escobés.


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.

Crear un entorno de alta disponibilidad para determinados recursos ...

Documents

Transcript of Crear un entorno de alta disponibilidad para determinados recursos ...