PROYECTO FIN DE CARRERA. Crear un entorno de alta disponibilidad para determinados recursos utilizando clustering en Linux

Transcripción

1 PROYECTO FIN DE CARRERA Título Crear un entorno de alta disponibilidad para determinados recursos utilizando clustering en Linux Autor/es Alberto Díez Escobés Director/es Eloy Javier Mata Sotés y Eduardo Sáenz de Cabezón Irigaray Facultad Facultad de Ciencias, Estudios Agroalimentarios e Informática Titulación Proyecto Fin de Carrera Departamento Matemáticas y Computación Curso Académico

2 Crear un entorno de alta disponibilidad para determinados recursos utilizando 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ón Irigaray (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. El autor Universidad de La Rioja, Servicio de Publicaciones, 2013 publicaciones.unirioja.es publicaciones@unirioja.es

3 Índice 1.- IN TRODUC CIÓN La Empresa Descripción general de la empresa El departamento de informática Función propia en la empresa Descripción del proyecto DOCUMENTO DE OBJETIVO S DE L PROYECTO Antecedentes Objetivos Entregables Descripción de la empresa y del proyecto Documento de objetivos del proyecto Documentación del análisis y diseño del sistema Documentación de las pruebas del sistema Documentación sobre la gestión del proyecto Documentación sobre explotación Actas de reuniones Alcance Estructura de descomposición de tareas Plan de trabajo Riesgos Costes 9

4 3.- ANÁLISIS Y DISEÑO DE L SISTE M A Evaluación de alternativas Alternativa Alternativa Elección de la alternativa más válida Requisitos hardware de la alternativa elegida Requisitos software de la alternativa elegida Configuración del software Estructura y desarrollo de la alternativa elegida Switches Ethernet Servidores Switches de fibra óptica Cabina de almacenamiento (SAN) IMPLAN TACIÓN DE L S ISTEMA Asignación de recursos a los servidores e interfaces de gestión Nodo 1 del clúster Nodo 2 del clúster Switch de fibra Switch de fibra Controladora A de la cabina de almacenamiento Controladora B de la cabina de almacenamiento Instalación del sistema operativo en los servidores Configuración de la red Configuración de los puertos en los switches Configuración del direccionamiento IP de dispositivos Configuración de las interfaces de red de los s ervidores 34

5 4.4.- Configuración de los switches de fibra óptica Configuración de los alias Configuración de las zonas Configuración del acceso al almacenamiento de los servidores Instalación de paquetes necesarios para almacenamiento en los servidores Creación del raid group en la cabina de almacenamiento Creación de las LUNs que se asignarán a los servidores Creación del storage group para dar acceso a los servidores Configuración del modo de acceso de los servidores a la cabina Instalación y configuración de software Instalación de los paquetes necesarios Creación del clúster Configuración de parámetros globales del clúster Creación del disco de quórum y configuración para que sea utilizado por el clúster Creación de los recursos a los que dará servicio el clúster Creación del recurso de IP virtual del clúster Configuración y creación del recurso de almacenamiento compartido Configuración y creación del recurso de Samba Configuración y creación del recurso de impresión Creación del dominio fail -over para los servicios del clúster Creación del servicio que dará soporte a los recursos Configuración de opciones de fencing Revisión del estado del clúster tras su creación 80

6 5.- P RUE BAS Pruebas tras la implantación Pruebas de configuración Pruebas de error a nivel de red Pruebas de error a nivel eléctrico Pruebas de error a nivel de almacenamiento Fase de producción Pruebas de rendimiento Análisis de problemas GE S TIÓN DE L PROYECTO Estimación inicial Factores que han afectado al ciclo de vida Realización de cursos necesarios para el trabajo en la 105 empresa Monitorización de rendimiento en determinadas 105 circunstancias Viajes a las distintas fábricas Necesidad de incorporación de modificaciones Problemas con dispositivos del sistema Necesidad de realización de otras tareas en la empresa Comparativas Comparativa de horas estimadas con las reales Repartición en tareas de las horas reales dedicadas al 107 proyecto Comparativa de las tareas a lo largo del tiempo Conclusiones 108

7 A NE XO I: INS TALACIÓN DE L S ISTE M A OPE RATIVO E N LOS S E RVIDORE S 111 A NE XO II: MANUA L DE E XPLOTACIÓN P OR LÍNE A DE COMANDOS 123 A NE XO III: A CTAS 127

8

9 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 La empresa 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 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 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. 1

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

11 ** 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. 3

12 4

13 2.- Documento de objetivos del proyecto 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 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 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. 5

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

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

16 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. - Plan de pruebas. 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. o Infraestructura. o Sistema de clúster. o Aceptación. - Documentación de la solución. o Manual de explotación 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 8

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

18 10

19 3.- Análisis y diseño del sistema 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 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. 11

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

21 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 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 o o o 2 puertos Gigabit Ethernet integrados. 1 tarjeta adicional con 2 puertos Gigabit Ethernet. 1 tarjeta HBA con dos puertos para las conexiones de fibra óptica. 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 o Puedan funcionar de forma redundante. 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 o o Creación de particiones o LUNs (Logical Unit Numbers) para asignación a servidores. Gestión de acceso a las distintas particiones. Posibilidad de selección del nivel de RAID para los grupos de discos para tener tolerancia a errores de disco. 13

22 - 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 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 o o CUPS clusterizado para dar soporte a impresión de documentos. Samba clusterizado para el intercambio de ficheros con otros sistemas operativos. Módulo de lógica de negocio de JDEdwards que será instalado y configurado por una empresa consultora externa especializada 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 Sistema operativo 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. 14

23 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 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 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 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: 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. 15

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

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

26 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 Switches Ethernet Stack de switches Dell PowerConnect 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. 18

27 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: 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 Puertos En cuanto a los puertos hay que definir dos conceptos que serán necesarios para poder entender las necesidades para cada uno de ellos a la hora de conectar los servidores. - Cuatro puertos, dos en cada switch, pertenecientes a la VLAN 3 (INFRAESTRUCTURA) para la conexión de los puertos que irán conectada a la red pública del clúster. Dos para cada uno de los servidores. - Cuatro puertos, dos en cada switch, pertenecientes a la VLAN 1100 (CLUSTERSUITE_1) para la conexión de los puertos que irán conectados a la red privada del clúster. Dos para cada uno de los servidores. - Dos puertos, uno en cada switch, pertenecientes a la VLAN 100 (GESTIÓN) para la conexión de las controladoras de la cabina de almacenamiento a red para gestionarla a través de red. - Dos puertos, uno en cada switch, pertenecientes a la VLAN 100 (GESTIÓN) para la conexión de la consola de gestión de los propios servidores a través de interfaz web (DRAC Dell Remote Access Controller). - Dos puertos, uno en cada switch, pertenecientes a la VLAN 100 (GESTIÓN) para la conexión de las interfaces de gestión de los switches de fibra y poder gestionarlos a través de la red. 19

28 Servidores Servidores: Dell PowerEdge 2950 III Características - 2 x QUAD-CORE XEON E GHZ. - 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) Descripción En este apartado se hará una descripción de cómo debe estar configurado cada servidor. Se especificará para uno de ellos siendo extensible para el otro 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. 20

29 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 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 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 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 21

30 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 Switches fibra óptica Brocade Silkworm 200E Características - Permiten la creación de alias para identificar las conexiones por nombre y no por identificador de la tarjeta (WWN). - Permiten la creación de zonas para gestionar qué dispositivos son capaces de establecer conexión entre ellos con independencia del puerto en que se conecten Descripción Los switches de fibra se encargarán de la comunicación de los servidores con la cabina de almacenamiento, de forma que cada servidor sea capaz de ver las controladoras. Para ello las conexiones de fibra a los switches deben estar repartidas de la siguiente forma para garantizar alta disponibilidad: - Conexiones al switch de fibra 1: o Una tarjeta de fibra del nodo 1. o Una tarjeta de fibra del nodo 2. o o Un puerto de la controladora A de la cabina. Un puerto de la controladora B de la cabina. - Conexiones al switch de fibra 2. o Una tarjeta de fibra del nodo 1. o Una tarjeta de fibra del nodo 2. o o Un puerto de la controladora A de la cabina. Un puerto de la controladora B de la cabina. 22

31 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 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 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 Zonas Las zonas permiten establecer qué dispositivos son capaces de comunicarse entre sí. Para ello se utilizan los alias que deben haber sido creados con anterioridad. Se necesitarán tantas zonas como pares de dispositivos que necesitan conectarse entre sí, en este caso para el primero de los switches quedaría como sigue: - Zona 1. o Tarjeta 1 de fibra del nodo 1. o Puerto 1 controladora A de la cabina. - Zona 2. o Tarjeta 1 de fibra del nodo 1. o Puerto 1 controladora B de la cabina. - Zona 3. o Tarjeta 1 de fibra del nodo 2. o Puerto 1 controladora A de la cabina. - Zona 4. o Tarjeta 1 de fibra del nodo 2. o Puerto 1 controladora B de la cabina. De esta forma se permite que la tarjeta de cada servidor sea capaz de acceder a los puertos de las controladoras de la cabina que están conectados al mismo switch. Con esto se consigue independizar por completo el puerto en el que se conecte cada dispositivo siempre que estén conectados al mismo switch. 23

32 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 Cabina de almacenamiento (SAN) Dell EMC cx3-10c Características La cabina se encargará de facilitar el almacenamiento compartido para ambos servidores y gestionar el acceso al mismo. - Permite registrar los servidores que accederán a la cabina de almacenamiento. - Permite generar distintos Raid Groups que serán grupos de discos que comparten el mismo nivel de RAID. Nivel físico. - Permite crear distintas LUN (Logical Unit Number) que son particiones que se hacen a los Raid Groups. Nivel lógico. - Permite gestionar el acceso de los servidores registrados a las distintas LUN mediante una asignación explícita utilizando los Storage Groups. - Permite gestionar el modo de acceso de los servidores a la cabina. o 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. Modo activo-activo: Los servidores podrán acceder simultáneamente a través de las dos controladoras de modo concurrente Descripción Para el acceso de los servidores a la cabina habrá que configurar cada uno de los elementos mencionados en el apartado anterior 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. 24

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

34 26

35 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 Asignación de recursos a los servidores e interfaces de gestión Nodo 1 del clúster Nombre gestión: ENT900PD00 Hostname: ENT900PD Tarjetas de red: o Integrada, puerto 1: Módulo 4 switches redundantes, puerto 9. o Integrada, puerto 2: Módulo 4 switches redundantes, puerto 10. o PCI, puerto 1: Módulo 6 switches redundantes, puerto 9. o PCI, puerto 2: Módulo 6 switches redundantes, puerto

36 Tarjetas de fibra: o Tarjeta 1, puerto 1: Switch de fibra 1, puerto 6. o Tarjeta 2, puerto 1: Switch de fibra 2, puerto 6. Tarjeta DRAC (Dell Remote Access Controller): Módulo 6 switches redundantes, puerto 41. Fuentes de alimentación: o Fuente de alimentación 1: SAI 1. o Fuente de alimentación 2: SAI Nodo 2 del clúster Nombre gestión: ENT900PD01 Hostname: ENT900PD Tarjetas de red: o Integrada, puerto 1: Módulo 4 switches redundantes, puerto 11. o Integrada, puerto 2: Módulo 4 switches redundantes, puerto 12. o PCI, puerto 1: Módulo 6 switches redundantes, puerto 11. o PCI, puerto 2: Módulo 6 switches redundantes, puerto 12. Tarjetas de fibra: o Tarjeta 1, puerto 1: Switch de fibra 1, puerto 7. o Tarjeta 2, puerto 1: Switch de fibra 2, puerto 7. Tarjeta DRAC (Dell Remote Access Controller): Módulo 4 switches redundantes, puerto 41. Fuentes de alimentación: o Fuente de alimentación 1: SAI 1. o Fuente de alimentación 2: SAI Switch de fibra 1 Nombre gestión: sw29 Hostname: sw29 Tarjeta de gestión: Módulo 4 switches redundantes, puerto

37 Switch de fibra 2 Nombre gestión: sw30 Hostname: sw30 Tarjeta de gestión: Módulo 6 switches redundantes, puerto Controladora A de la cabina de almacenamiento Nombre gestión: trancosa Hostname: trancos Tarjeta de gestión: Módulo 4 switches redundantes, puerto Controladora B de la cabina de almacenamiento Nombre gestión: trancosb Hostname: trancos Tarjeta de gestión: Módulo 6 switches redundantes, puerto 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 Configuración de la red 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. 29

38 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 exit interface vlan 10 name "GESTION" routing ip address 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: /24 (Será el Gateway de la subred). - VLAN 10 Capaz de enrutar tráfico Dirección IP: /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 30

39 Siguiendo este patrón los puertos quedarán configurados de la siguiente manera: interface ethernet 4/g9 description 'ENT900PD00_BOND0-ETH0' switchport access vlan 1 exit interface ethernet 4/g10 description 'ENT900PD00_BOND1-ETH1' switchport access vlan 110 exit interface ethernet 4/g11 description 'ENT900PD01_BOND0-ETH0' switchport access vlan 1 exit interface ethernet 4/g12 description 'ENT900PD01_BOND1-ETH1' switchport access vlan 110 exit interface ethernet 4/g39 description 'CX310C_SPA' switchport access vlan 10 exit interface ethernet 4/g41 description 'DRAC_ENT900PD01' switchport access vlan 10 exit interface ethernet 4/g44 description 'SW29_FC_GESTION' switchport access vlan 10 exit interface ethernet 6/g9 description 'ENT900PD00_BOND0-ETH2' switchport access vlan 1 exit interface ethernet 6/g10 description 'ENT900PD00_BOND1-ETH3' switchport access vlan 110 exit interface ethernet 6/g11 description 'ENT900PD01_BOND0-ETH2' switchport access vlan 1 exit interface ethernet 6/g12 description 'ENT900PD01_BOND1-ETH3' switchport access vlan 110 exit 31

40 interface ethernet 6/g39 description 'CX310C_SPB' switchport access vlan 10 exit interface ethernet 6/g41 description 'DRAC_ENT900PD00' switchport access vlan 10 exit interface ethernet 6/g44 description 'SW30_FC_GESTION' switchport access vlan 10 exit Configuración del direccionamiento IP de dispositivos 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: 32

41 33

42 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: 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: 34

43 ENT900PD Ifcfg-bond0 DEVICE=bond0 BOOTPRO=static ONBOOT=yes IPADDR= NETMASK= GATEWAY= PEERDNS=no USERCTL=no BONDING_OPTS="mode=0 miimon=100" TYPE=BOND BOOTPROTO=none Ifcfg-bond1 DEVICE=bond1 BOOTPRO=static ONBOOT=yes IPADDR= NETMASK= PEERDNS=no USERCTL=no BONDING_OPTS="mode=0 miimon=100" TYPE=BOND BOOTPROTO=none 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 Ifcfg-eth1 # Broadcom Corporation NetXtreme II BCM5708 Gigabit Ethernet DEVICE=eth1 BOOTPROTO=none HWADDR=00:1E:C9:D6:FE:34 ONBOOT=yes TYPE=Ethernet USERCTL=no IPV6INIT=no PEERDNS=no MASTER=bond1 SLAVE=yes 35

44 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 Ifcfg-eth3 # Intel Corporation 82571EB Gigabit Ethernet Controller DEVICE=eth3 BOOTPROTO=none HWADDR=00:15:17:7B:6F:A3 ONBOOT=yes TYPE=Ethernet USERCTL=no IPV6INIT=no PEERDNS=no MASTER=bond1 SLAVE=yes ENT900PD Ifcfg-bond0 DEVICE=bond0 BOOTPRO=static ONBOOT=yes IPADDR= NETMASK= GATEWAY= PEERDNS=no USERCTL=no BONDING_OPTS="mode=0 miimon=100" TYPE=BOND BOOTPROTO=none Ifcfg-bond1 DEVICE=bond1 BOOTPRO=static ONBOOT=yes IPADDR= NETMASK= PEERDNS=no USERCTL=no BONDING_OPTS="mode=0 miimon=100" TYPE=BOND BOOTPROTO=none 36

45 Ifcfg-eth0 # Broadcom Corporation NetXtreme II BCM5708 Gigabit Ethernet DEVICE=eth0 BOOTPROTO=none HWADDR=00:1E:C9:D6:FE:42 ONBOOT=yes TYPE=Ethernet USERCTL=no IPV6INIT=no PEERDNS=no MASTER=bond0 SLAVE=yes Ifcfg-eth1 # Broadcom Corporation NetXtreme II BCM5708 Gigabit Ethernet DEVICE=eth1 BOOTPROTO=none HWADDR=00:1E:C9:D6:FE:44 ONBOOT=yes TYPE=Ethernet USERCTL=no IPV6INIT=no PEERDNS=no MASTER=bond1 SLAVE=yes Ifcfg-eth2 # Intel Corporation 82571EB Gigabit Ethernet Controller DEVICE=eth2 BOOTPROTO=none HWADDR=00:15:17:7B:6F:B2 ONBOOT=yes TYPE=Ethernet USERCTL=no IPV6INIT=no PEERDNS=no MASTER=bond0 SLAVE=yes Ifcfg-eth3 # Intel Corporation 82571EB Gigabit Ethernet Controller DEVICE=eth3 BOOTPROTO=none HWADDR=00:15:17:7B:6F:B3 ONBOOT=yes TYPE=Ethernet USERCTL=no IPV6INIT=no PEERDNS=no MASTER=bond1 SLAVE=yes 37

46 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 nameserver nameserver 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 localhost.localdomain localhost ENT900PD ENT900PD.cidacos.com ENT900PD00 ENT900PD00.cidacos.com ENT900PD01 ENT900PD01.cidacos.com ENT900PD00-priv ENT900PD01-priv 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 Configuración de los switches de fibra óptica 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. 38

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

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

49 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 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 o Una interfaz de un servidor identificada por su alias. 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. 41

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

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

52 4.5.- Configuración del acceso al a lmacenamiento de los servidores 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 noarch.rpm). Este paquete no necesita configuración adicional por lo que sólo es necesario instalarlo utilizando el siguiente comando: rpm -ivh naviagentcli 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 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. 44

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

54 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: 46

55 Una vez creadas las LUN aparecerán en el desplegable del RAID Group 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. 47

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

57 - En la pestaña Hosts se establecen los servidores que tendrán acceso a las LUN definidas en la pestaña LUNs 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. 49

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

59 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 Instalación y configuración de software 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: 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. 51

60 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 el5 device-mapper-multipath-libs 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 /multipath.conf /etc/multipath/ 52

61 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 ( e d6e09b7ef906e111) 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 ( e d309cf906e111) 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 e d309cf906e111 alias quórum path_grouping_policy multibus path_selector "round-robin 0" failback 0 rr_weight priorities no_path_retry 5 } 53

62 } multipath { wwid e d6e09b7ef906e111 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 el5_7.2 [root@ent900pd ~]# rpm -qa grep rgmanager rgmanager el5 [root@ent900pd ~]# rpm -qa grep gfs2 gfs2-utils el5 [root@ent900pd ~]# rpm -qa grep cluster system-config-cluster cluster-cim el5 modcluster el5 cluster-snmp el5 lvm2-cluster el5 [root@ent900pd ~]# rpm -qa grep luci luci el5 [root@ent900pd ~]# rpm -qa grep ricci ricci 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. 54

63 El siguiente paso es verificar que los servicios de clúster arranquen con el sistema operativo. Se verifican uno por uno como sigue: ~]# chkconfig --list cman cman 0:off 1:off 2:off 3:off 4:off 5:off 6:off ~]# chkconfig cman on ~]# chkconfig --list cman cman 0:off 1:off 2:on 3:on 4:on 5:on 6:off ~]# chkconfig --list rgmanager rgmanager 0:off 1:off 2:off 3:off 4:off 5:off 6:off ~]# chkconfig rgmanager on ~]# chkconfig --list rgmanager rgmanager 0:off 1:off 2:on 3:on 4:on 5:on 6:off ~]# chkconfig --list qdiskd qdiskd 0:off 1:off 2:off 3:off 4:off 5:off 6:off ~]# chkconfig qdiskd on ~]# chkconfig --list qdiskd qdiskd 0:off 1:off 2:on 3:on 4:on 5:on 6:off ~]# chkconfig --list clvmd clvmd 0:off 1:off 2:off 3:off 4:off 5:off 6:off ~]# chkconfig clvmd on ~]# chkconfig --list clvmd clvmd 0:off 1:off 2:on 3:on 4:on 5:on 6:off ~]# chkconfig --list gfs2 gfs2 0:off 1:off 2:off 3:off 4:off 5:off 6:off ~]# chkconfig gfs2 on ~]# chkconfig --list gfs2 gfs2 0:off 1:off 2:on 3:on 4:on 5:on 6:off ~]# chkconfig --list ricci ricci 0:off 1:off 2:off 3:off 4:off 5:off 6:off ~]# chkconfig ricci on ~]# chkconfig --list ricci ricci 0:off 1:off 2:on 3:on 4:on 5:on 6:off ~]# chkconfig --list luci luci 0:off 1:off 2:off 3:off 4:off 5:off 6:off ~]# chkconfig luci on ~]# 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 55

64 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 to access luci [root@ent900pd ~]# service ricci start Starting ricci: [ OK ] 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: El usuario y contraseña será el configurado en el apartado anterior cuando se hizo la configuración inicial de la aplicación luci. 56

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

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

67 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 Creación del disco de quórum y configuración para que sea utilizado 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 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. 59

68 ~]# 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, bytes 255 heads, 63 sectors/track, 8 cylinders Units = cylinders of * 512 = bytes Device Boot Start End Blocks Id System /dev/mapper/quórump Linux Command (m for help): w The partition table has been altered! Calling ioctl() to re-read partition table. Syncing disks. Una vez generada la partición se utilizará la herramienta mkqdisk para crear el nuevo disco de quórum que utilizará el clúster. La sintaxis de este comando es la siguiente: mkqdisk c <partición> -l <etiqueta> [root@ent900pd ~]# mkqdisk -c /dev/mapper/quórump1 -l JDE_LOGCI mkqdisk v0.6.0 Writing new quórum disk label 'JDE_LOGCI' to /dev/mapper/quórump1. WARNING: About to destroy all data on /dev/mapper/quórump1; proceed [N/y]? y Initializing status block for node 1... Initializing status block for node 2... Initializing status block for node 3... Initializing status block for node 4... Initializing status block for node 5... Initializing status block for node 6... Initializing status block for node 7... Initializing status block for node 8... Initializing status block for node 9... Initializing status block for node Initializing status block for node Initializing status block for node Initializing status block for node Initializing status block for node Initializing status block for node Initializing status block for node 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. 60

69 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: 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. 61

70 4.8.- Creación de los recursos a l os que dará servicio el clúster 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. 62

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

72 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. ~]# parted /dev/mapper/jdedwards GNU Parted 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 kB 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 64

73 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 / GB free] Total: 1 [39.96 GB] / in use: 1 [ 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 GB Current LE 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. 65

74 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 GB ( blocks) Filesystem Size: GB ( blocks) Journals: 3 Resource Groups: 1200 Locking Protocol: "lock_dlm" Lock Table: "JDE_LOGCI:gfs" UUID: FFC D98D-C470-3CBCA7354DD Creación del recurso de almacena miento compartido en el 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. 66

75 - 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 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) 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/ 67

76 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 68

77 Una vez terminado el proceso de configuración desmontar el almacenamiento compartido: ~]# umount /opt/jdedwards/ Creación del recurso de Samba Para agregar el recurso al clúster hay que acceder a la opción Add a resource dentro de la pestaña cluster y en el desplegable elegir la opción Script. Hay que rellenar los campos para configurar el recurso de la siguiente manera: - Name: Nombre para identificar el recurso dentro del sistema de clúster. - Full path to script file: Ruta del script de arranque/parada del servicio. El sistema de clúster se encargará de pasar los parámetros de parada o arranque según sea necesario. 69

78 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 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 70

79 etc]# ln -s /opt/jdedwards/cups/etc/cups/ /etc/cups 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 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 71

80 Creación del recurso de impresión Para agregar el recurso al clúster hay que acceder a la opción Add a resource dentro de la pestaña cluster y en el desplegable elegir la opción Script. Hay que rellenar los campos para configurar el recurso de la siguiente manera: - Name: Nombre para identificar el recurso dentro del sistema de clúster. - Full path to script file: Ruta del script de arranque/parada del servicio. El sistema de clúster se encargará de pasar los parámetros de parada o arranque según sea necesario. 72

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

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

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

84 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 76

85 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 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 Configurar el 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. 77

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

87 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 Para el nodo ENT900PD Para el nodo ENT900PD01 79

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

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

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

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

92 84

93 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 o o o o Pruebas de configuración de red. Pruebas de configuración de almacenamiento. Pruebas de balanceo de servicios en el clúster. Pruebas de servicios clusterizados. Pruebas de fencing. - Pruebas de error a nivel de red. o o o Pérdida de conexión de tarjetas de red de servidor. Problema a nivel de switches de red. Pérdida de conexión de dispositivos involucrados. - Pruebas de error a nivel eléctrico. o o Error a nivel de SAI. Pérdida de suministro eléctrico externo. - Pruebas de error a nivel de almacenamiento. o o o Pérdida de conectividad de fibra a nivel de servidor. Pérdida de conectividad de fibra a nivel de switch. Pérdida de conectividad de fibra a nivel de cabina. Fase de producción. - Pruebas de rendimiento. o o o Rendimiento durante el arranque. Rendimiento en campaña. Rendimiento en cierre contable. 85

94 o Rendimiento en circunstancias normales. - Análisis de problemas. o o o Problemas de discos de la cabina. Problemas de discos en los servidores. 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) Pruebas tras la implantación Pruebas de configuración Pruebas de configuración de red Prueba 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 Prueba de conectividad con tarjetas DRAC Prueba de conectividad con interfaz pública del nodo ENT900PD01 Crítico Crítico Crítico 86

95 Prueba de conectividad con interfaz privada del nodo ENT900PD01 Prueba de conectividad con interfaces de red de los switches de fibra óptica Prueba de conectividad con interfaces de red de la cabina de almacenamiento Crítico Sin impacto 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 Prueba de conectividad con tarjetas DRAC Prueba de conectividad con interfaz pública del nodo ENT900PD01 Prueba de conectividad con interfaz privada del nodo ENT900PD01 Prueba de conectividad con interfaces de red de los switches de fibra óptica Prueba de conectividad con interfaces de red de la cabina de almacenamiento OK OK Error Error OK 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 Prueba 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 Prueba de conectividad con tarjetas DRAC Prueba de conectividad con interfaz pública del nodo ENT900PD00 Prueba de conectividad con interfaz privada del nodo ENT900PD00 Prueba de conectividad con interfaces de red de los switches de fibra óptica Prueba de conectividad con interfaces de red de la cabina de almacenamiento Crítico Crítico Crítico Crítico Sin impacto Crítico 87

96 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 Prueba de conectividad con tarjetas DRAC Prueba de conectividad con interfaz pública del nodo ENT900PD00 Prueba de conectividad con interfaz privada del nodo ENT900PD00 Prueba de conectividad con interfaces de red de los switches de fibra óptica Prueba de conectividad con interfaces de red de la cabina de almacenamiento OK OK Error Error OK 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 Pruebas de configuración de almacenamiento Prueba Descripción de la prueba: Comprobar la configuración para almacenamiento y la gestión de caminos con multipath en el nodo ENT900PD00. Fase de realización de la prueba: Tras haber realizado la configuración de almacenamiento tanto en los servidores como en la cabina. Impacto en caso de no pasar la prueba: Volver a revisar la configuración del almacenamiento. No se podría continuar con la implantación hasta no estar solventado. Simulación para la realización de la prueba: N/A. Resultados esperados: El servidor debe ser capaz de obtener acceso al almacenamiento de la cabina por los cuatro caminos disponibles. Resultados obtenidos: Se ha verificado utilizando comandos de multipath que el servidor es capaz de obtener acceso a las dos LUNs configuradas y los cuatro caminos los marca como active. 88

97 Adicionalmente se ha verificado en la interfaz de la cabina que detecta como activos los cuatro caminos por los que accede el servidor Prueba Descripción de la prueba: Comprobar la configuración para almacenamiento y la gestión de caminos con multipath en el nodo ENT900PD01. Fase de realización de la prueba: Tras haber realizado la configuración de almacenamiento tanto en los servidores como en la cabina. Impacto en caso de no pasar la prueba: Volver a revisar la configuración del almacenamiento. No se podría continuar con la implantación hasta no estar solventado. Simulación para la realización de la prueba: N/A. Resultados esperados: El servidor debe ser capaz de obtener acceso al almacenamiento de la cabina por los cuatro caminos disponibles. Resultados obtenidos: Se ha verificado utilizando comandos de multipath que el servidor es capaz de obtener acceso a las dos LUNs configuradas y los cuatro caminos los marca como active. Adicionalmente se ha verificado en la interfaz de la cabina que detecta como activos los cuatro caminos por los que accede el servidor Pruebas de balanceo de servicios en el clúster Prueba Descripción de la prueba: Comprobar el correcto balanceo del servicio del nodo ENT900PD00 al nodo ENT900PD01. Fase de realización de la prueba: Tras haber realizado la implantación completa. Impacto en caso de no pasar la prueba: Volver a revisar la configuración de red privada, servicios y recursos. En caso de error habrá que verificar todo el clúster pues es crítico para la alta disponibilidad. Simulación para la realización de la prueba: Lanzar desde la interfaz web el balanceo del servicio de un nodo al otro. Resultados esperados: Al balancear el servicio, el nodo original deberá perder la IP virtual, desmontar el almacenamiento compartido y parar los procesos de los recursos de Samba y de impresión. Todos los recursos deben activarse en el nodo destino. Resultados obtenidos: Parada del recurso de impresión en el nodo ENT900PD00 Parada del recurso de Samba en el nodo ENT900PD00 Almacenamiento compartido desmontado en el nodo ENT900PD00 OK OK OK 89

98 Recurso de IP virtual desmontado en el nodo ENT900PD00 Recurso de IP virtual montado en el nodo ENT900PD01 Almacenamiento compartido montado en el nodo ENT900PD01 Arranque del recurso de Samba en el nodo ENT900PD01 Arranque del recurso de impresión en el nodo ENT900PD01 OK OK OK OK OK Prueba Descripción de la prueba: Comprobar el correcto balanceo del servicio del nodo ENT900PD01 al nodo ENT900PD00. Fase de realización de la prueba: Tras haber realizado la implantación completa. Impacto en caso de no pasar la prueba: Volver a revisar la configuración de red privada, servicios y recursos. En caso de error habrá que verificar todo el clúster pues es crítico para la alta disponibilidad. Simulación para la realización de la prueba: Lanzar desde la interfaz web el balanceo del servicio de un nodo al otro. Resultados esperados: Al balancear el servicio, el nodo original deberá perder la IP virtual, desmontar el almacenamiento compartido y parar los procesos de los recursos de Samba y de impresión. Todos los recursos deben activarse en el nodo destino. Resultados obtenidos: Parada del recurso de impresión en el nodo ENT900PD01 Parada del recurso de Samba en el nodo ENT900PD01 Almacenamiento compartido desmontado en el nodo ENT900PD01 Recurso de IP virtual desmontado en el nodo ENT900PD01 Recurso de IP virtual montado en el nodo ENT900PD00 Almacenamiento compartido montado en el nodo ENT900PD00 Arranque del recurso de Samba en el nodo ENT900PD00 Arranque del recurso de impresión en el nodo ENT900PD00 OK OK OK OK OK OK OK OK Pruebas de servicios clusterizados Prueba Descripción de la prueba: Comprobar el correcto funcionamiento de todos los recursos del servicio en el nodo ENT900PD00. Fase de realización de la prueba: Tras haber realizado la implantación completa. Impacto en caso de no pasar la prueba: Volver a revisar la configuración de los recursos afectados tanto a nivel del sistema operativo como en el clúster. Habría que solucionar este aspecto antes de poder continuar pues no tiene sentido tener un clúster en el que no funcionen los recursos. 90

99 Simulación para la realización de la prueba: Forzar en el clúster que el servicio se ejecute sobre el nodo ENT900PD00 para hacer las pruebas. Resultados esperados: Una vez puesto el clúster en el nodo correspondiente todos y cada uno de los recursos configurados funciona de la manera esperada. Resultados obtenidos: Recurso de dirección IP virtual. Probar que la IP responde al ping y que direcciona al nodo ENT900PD00 Recurso de almacenamiento compartido. Probar que el almacenamiento compartido está montado Probar que se pueden hacer operaciones de lectura Probar que se pueden hacer operaciones de escritura Recurso de Samba. Probar que se puede acceder a los recursos compartidos de Samba desde cualquier Probar operaciones equipo externo de lectura de ficheros a través del recurso compartido Probar operaciones de escritura de ficheros a través del recurso compartido Recurso de impresión. Probar acceso a la interfaz de configuración web Probar a añadir drivers de impresoras Probar creación de impresoras clusterizadas Probar impresión en local desde el nodo OK OK OK OK OK OK OK OK OK OK OK Prueba Descripción de la prueba: Comprobar el correcto funcionamiento de todos los recursos del servicio en el nodo ENT900PD01. Fase de realización de la prueba: Tras haber realizado la implantación completa. Impacto en caso de no pasar la prueba: Volver a revisar la configuración de los recursos afectados tanto a nivel del sistema operativo como en el clúster. Habría que solucionar este aspecto antes de poder continuar pues no tiene sentido tener un clúster en el que no funcionen los recursos. Simulación para la realización de la prueba: Forzar en el clúster que el servicio se ejecute sobre el nodo ENT900PD01 para hacer las pruebas. Resultados esperados: Una vez puesto el clúster en el nodo correspondiente todos y cada uno de los recursos configurados funciona de la manera esperada. Resultados obtenidos: Recurso de dirección IP virtual. Probar que la IP responde al ping y que direcciona al nodo ENT900PD00 Recurso de almacenamiento compartido. Probar que el almacenamiento compartido está montado Probar que se pueden hacer operaciones de lectura OK OK OK 91

100 Probar que se pueden hacer operaciones de escritura Recurso de Samba. Probar que se puede acceder a los recursos compartidos de Samba desde cualquier Probar operaciones equipo externo de lectura de ficheros a través del recurso compartido Probar operaciones de escritura de ficheros a través del recurso compartido Recurso de impresión. Probar acceso a la interfaz de configuración web Probar a añadir drivers de impresoras Probar creación de impresoras clusterizadas Probar impresión en local desde el nodo OK OK OK OK OK OK OK OK Pruebas de fencing Prueba Descripción de la prueba: Comprobar el correcto funcionamiento del fencing en el nodo ENT900PD00. Fase de realización de la prueba: Tras haber realizado la implantación completa. Impacto en caso de no pasar la prueba: Volver a revisar la configuración de fencing para el nodo antes de continuar. Este es un aspecto crítico a nivel de clúster pues en caso de error de uno de los nodos, el clúster no será capaz de resetearlo para que libere los recursos y los pase al otro. Simulación para la realización de la prueba: Forzar que el servicio se ejecute sobre el nodo ENT900PD00 y posteriormente en la interfaz del clúster para el nodo ENT900PD00 seleccionar del desplegable la opción Fence this node. Resultados esperados: Una vez lanzada la orden de fence del nodo, éste deberá apagarse y volver a iniciar pasando el servicio al otro nodo. Resultados obtenidos: Cuando se lanza la orden de fence del nodo no hace nada sacando en el log un error de fencing indicando que no se pudo autenticar con la tarjeta DRAC de éste. Correcciones aplicadas: Tras ver el error del log se vuelven a configurar las credenciales para el fencing en el nodo ENT900PD00. Posteriormente se vuelve a realizar la prueba y el servidor se para y vuelve a arrancar pasando el servicio al nodo ENT900PD Prueba Descripción de la prueba: Comprobar el correcto funcionamiento del fencing en el nodo ENT900PD01. Fase de realización de la prueba: Tras haber realizado la implantación completa. Impacto en caso de no pasar la prueba: Volver a revisar la configuración de fencing para el nodo antes de continuar. Este es un aspecto crítico a nivel de clúster pues en caso de error de uno de los nodos, el clúster no será capaz de resetearlo para que libere los recursos y los pase al otro. 92

101 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 ENT900PD Pruebas de error a nivel de red Pérdida de conexión de tarjetas de red de servidor Prueba Descripción de la prueba: Comprobar funcionamiento tras pérdida de link de una de las tarjetas de red en los servidores. Fase de realización de la prueba: Tras haber realizado la implantación completa. Impacto en caso de no pasar la prueba: Revisar la configuración de red y la conexión de los cables de red del servidor afectado. Este aspecto es crítico para la alta disponibilidad. Simulación para la realización de la prueba: Soltar el cable de red de una de las interfaces de red en el servidor para probar la caída de todas y cada una de ellas. Resultados esperados: Si sólo se pierde la conectividad en una de las interfaces no debería haber ningún problema a nivel de funcionamiento tanto de nodo como de clúster. Resultados obtenidos: Servidor Tarjeta Puerto Interfaz Estado 1 Estado 2 Estado 3 Estado 4 ENT900PD00 Integrada 1 Pública Down Up Up Up ENT900PD00 Integrada 2 Privada Up Down Up Up ENT900PD00 PCI 1 Pública Up Up Down Up ENT900PD00 PCI 2 Privada Up Up Up Down Resultados: OK OK OK OK Servidor Tarjeta Puerto Interfaz Estado 1 Estado 2 Estado 3 Estado 4 ENT900PD01 Integrada 1 Pública Down Up Up Up ENT900PD01 Integrada 2 Privada Up Down Up Up ENT900PD01 PCI 1 Pública Up Up Down Up ENT900PD01 PCI 2 Privada Up Up Up Down Resultados: OK OK OK OK 93

102 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 Prueba Descripción de la prueba: Comprobar funcionamiento tras pérdida de link de dos de las tarjetas de red en los servidores. Fase de realización de la prueba: Tras haber realizado la implantación completa. Impacto en caso de no pasar la prueba: Revisar la configuración de red y la conexión de los cables de red del servidor afectado. Este aspecto es crítico para la alta disponibilidad. Simulación para la realización de la prueba: Soltar el cable de red de dos de las interfaces de red en el servidor para simular todas y cada una de las situaciones de fallo de dos interfaces de red. Resultados esperados: Si se pierde la conectividad de dos de las interfaces de red hay situaciones en las que el nodo no podrá dar servicio. Estos casos se producirán cuando el fallo se produzca en las dos interfaces de la red pública o de la red privada respectivamente. Resultados obtenidos: Estado Estado Estado Estado Estado Estado Servidor Tarjeta Puerto Interfaz 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 Estado Estado Estado Estado Estado Estado Servidor Tarjeta Puerto Interfaz 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. 94

103 Prueba Descripción de la prueba: Comprobar funcionamiento tras pérdida de link de tres o cuatro de las tarjetas de red en los servidores. Fase de realización de la prueba: Tras haber realizado la implantación completa. Simulación para la realización de la prueba: Soltar el cable de red tres o cuatro de las interfaces de red en el servidor para simular todas y cada una de las situaciones de fallo. Resultados esperados: Con la pérdida de tres o cuatro interfaces de red en un servidor se producirá un fallo en el nodo puesto que siempre se dará el caso de que se pierdan las dos interfaces de las redes pública o privada (o ambas por pérdida total de red en el caso de soltar las cuatro interfaces). Resultados obtenidos: Estado Estado Estado Estado Estado Servidor Tarjeta Puerto Interfaz 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 Estado Estado Estado Estado Estado Servidor Tarjeta Puerto Interfaz 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 Problema a nivel de switches de red Prueba Descripción de la prueba: Comprobar el funcionamiento del clúster tras caída de uno de los switches donde están conectados los dispositivos. Fase de realización de la prueba: Tras haber realizado la implantación completa. 95

104 Impacto en caso de no pasar la prueba: En caso de no pasar la prueba se ha de revisar la conexión del cableado de red a los switches para verificar que cada uno de los cables está conectado a ellos de forma redundante para garantizar la disponibilidad del sistema. Simulación para la realización de la prueba: Detener alternativamente cada uno de los switches de red para simular un posible fallo en cada uno de ellos. Resultados esperados: Si se detiene uno de los switches, el clúster debe estar conectado de tal forma que sea capaz de seguir dando servicio. En el caso de detener ambos switches de red cada nodo del clúster se quedará sin conectividad de red de forma que dejará de dar servicio (este último caso es normal que provoque el fallo pero se realizará por completitud en las pruebas). Resultados obtenidos: En la siguiente tabla se observan los resultados para los dispositivos en cada uno de los casos de la prueba: Dispositivo Tarjeta Interfaz Caída switch 4 Caída switch 6 Caída ambos Nodo ENT900PD00 Integrada 1 Down Up Down Nodo ENT900PD00 Integrada 2 Down Up Down Nodo ENT900PD00 PCI 1 Up Down Down Nodo ENT900PD00 PCI 2 Up Down Down Nodo ENT900PD00 DRAC N/A Up Down Down Nodo ENT900PD01 Integrada 1 Down Up Down Nodo ENT900PD01 Integrada 2 Down Up Down Nodo ENT900PD01 PCI 1 Up Down Down Nodo ENT900PD01 PCI 2 Up Down Down Nodo ENT900PD01 DRAC N/A Down Up Down Switch fibra(sw29) N/A Ethernet Down Up Down Switch fibra(sw30) N/A Ethernet Up Down Down Cabina almacenamiento SPA Ethernet Down Up Down Cabina almacenamiento SPB Ethernet Up Down Down Estado del clúster: Operativo Operativo Caído En los casos de caída de sólo uno de los switches el clúster sigue operativo ya que cada nodo dispone de una tarjeta para cada una de las redes de clúster (pública/privada). En cuanto al resto de dispositivos, el estado no es directamente influyente como se especificará en la siguiente prueba Pérdida de conexión de dispositivos involucrados Prueba Descripción de la prueba: Comprobar el funcionamiento del clúster si se produce una caída de red en los dispositivos involucrados en el clúster. No se tendrán en cuenta la conectividad de las interfaces de red de los nodos pues ya se han hecho las pruebas exhaustivas anteriormente. Fase de realización de la prueba: Tras haber realizado la implantación completa. 96

105 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 Pruebas de error a nivel eléctrico Error a nivel de SAI Prueba Descripción de la prueba: Esta prueba recoge el caso de pérdida de redundancia de alimentación de los dispositivos producido por el error en alguno de los SAI a los que están conectados. Fase de realización de la prueba: Tras haber realizado la implantación completa. Impacto en caso de no pasar la prueba: En caso de producirse algún problema hay que verificar el cableado de alimentación de los dispositivos afectados. Simulación para la realización de la prueba: Parar uno de los SAI involucrados para verificar que el sistema de clúster funciona correctamente. Resultados esperados: Con la parada de uno de los SAI deberán quedar activos los dispositivos suficientes para poder seguir dando servicio. 97

106 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) Pérdida de suministro eléctrico externo Prueba Descripción de la prueba: Esta prueba recoge el caso de pérdida de alimentación externa. Fase de realización de la prueba: Tras haber realizado la implantación completa. Impacto en caso de no pasar la prueba: En caso de producirse algún problema habrá que contactar con el soporte técnico de los SAI ya que son los que se verían afectados por este problema. Simulación para la realización de la prueba: Bajar los diferenciales del cuadro de luz que dan alimentación a los dos SAI para que estos detecten que han perdido la entrada de corriente. Resultados esperados: Una vez detectado el fallo, los SAI entrarán en batería y mandarán correo electrónico para avisar de la situación. Resultados obtenidos: En cuanto los SAI detectan el fallo entran en batería, envían el correo para avisar y revisando las pantallas muestra que tendrían una autonomía de más de 30 minutos lo cual permitiría realizar una parada correcta del sistema Pruebas de error a nivel de almacenamient o Pérdida de conectividad de fibra a nivel de servidor Prueba Descripción de la prueba: Comprobar el acceso de los servidores al almacenamiento en los casos en los que se pierda la conectividad de fibra en éstos de una o de las dos interfaces. Fase de realización de la prueba: Tras haber realizado la implantación completa. Impacto en caso de no pasar la prueba: Revisar la conexión de los cables de fibra y la configuración de éstas en los servidores, los switches de fibra y la cabina. 98

107 Simulación para la realización de la prueba: Soltar uno o dos cables de fibra de una de las interfaces de fibra en el servidor para probar la caída de todas y cada una de ellas. Resultados esperados: Los resultados dependen de cada uno de los casos: - Pérdida de una interfaz de fibra: El servidor pierde la conectividad por dos de los cuatro caminos que tiene disponibles para acceso a la cabina. El clúster seguiría funcionando con normalidad. - Pérdida de dos interfaces de fibra: El servidor pierde la conectividad de los cuatro caminos que tiene disponibles. El clúster detecta que el nodo no accede al disco de quórum y el otro nodo lo reclama para poder dar el servicio y fuerza el reinicio del nodo afectado para que libere todos los recursos restantes para poder dar servicio. Resultados obtenidos: Servidor Tarjeta Puerto Estado 1 Estado 2 Estado 3 ENT900PD00 F.O. 1 Down Up Down ENT900PD00 F.O. 2 Up Down Down Resultados: OK OK Error y balanceo. Servidor Tarjeta Puerto Estado 1 Estado 2 Estado 3 ENT900PD01 F.O. 1 Down Up Down ENT900PD01 F.O. 2 Up Down Down Resultados: OK OK Error y balanceo. En el caso en el que se pierde la conectividad de los dos puertos de fibra, el clúster se balancea al otro nodo y el afectado es reiniciado por éste Pérdida de conectividad de fibra a nivel de switch Prueba Descripción de la prueba: Comprobar el acceso de los servidores al almacenamiento en los casos en los que se pierda la conectividad de fibra en alguno de los switches de fibra. Fase de realización de la prueba: Tras haber realizado la implantación completa. Impacto en caso de no pasar la prueba: Revisar la conexión de los cables de fibra y la configuración de éstas en los servidores, los switches de fibra y la cabina. Simulación para la realización de la prueba: Desconectar la alimentación de los switches de fibra de forma alterna para probar los casos de caída de cada uno de ellos. Resultados esperados: Los resultados dependen de cada uno de los casos: 99

108 - 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 Pérdida de conectividad de fibra a nivel de cabina Prueba Descripción de la prueba: Comprobar el acceso de los servidores al almacenamiento en los casos en los que se pierda la conectividad de fibra en alguna de las controladoras de la cabina. Fase de realización de la prueba: Tras haber realizado la implantación completa. Impacto en caso de no pasar la prueba: Revisar la conexión de los cables de fibra y la configuración de éstas en los servidores, los switches de fibra y la cabina. Simulación para la realización de la prueba: Desconectar el cable de fibra de cada una de las controladoras de la cabina alternativamente. Resultados esperados: Los resultados dependen de cada uno de los casos: - Pérdida de una de las controladoras: Ambos nodos pierden la conectividad a través de un camino de cada una de las interfaces de fibra que es la que va conectada a la controladora que no está disponible. A cada uno le quedarían dos de los cuatro caminos disponibles pudiendo funcionar con normalidad. - Pérdida de las dos controladoras: Ambos servidores pierden la conectividad de los cuatro caminos que tiene disponibles. Al perder la conectividad con el almacenamiento ambos nodos se produce un error del clúster y se para el servicio. - Resultados obtenidos: Controladora Estado 1 Estado 2 Estado 3 SPA Down Up Down SPB Up Down Down OK OK Error 100

109 5.2.- Fase de producción 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 Rendimiento durante el arranque 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 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. 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 Rendimiento en campaña Prueba P1.2.1 Descripción de la prueba: Esta prueba recoge la monitorización del rendimiento de la plataforma durante las campañas en distintas fábricas. Fase de realización de la prueba: Durante las campañas (Verano 2012). 101

110 Impacto en caso de no pasar la prueba: En caso de producirse algún problema hay que verificar la configuración de la infraestructura por nuestra parte y la configuración del RP por parte de la consultora externa. Simulación para la realización de la prueba: Monitorizar acceso de los usuarios a los sistemas y verificar los tiempos de respuesta que obtienen durante las campañas. Problemas encontrados: En esta fase de pruebas se han detectado los siguientes problemas: - Algunos de los procesos del RP se quedaban bloqueados. o Junto con los consultores se verificó que había un problema de diseño en varios de los desarrollos del RP que sólo se usan durante la campaña. La empresa consultora corrigió estos problemas Rendimiento en cierre contable Prueba P1.3.1 Descripción de la prueba: Esta prueba recoge la monitorización del rendimiento de la plataforma durante el cierre contable del año Fase de realización de la prueba: Durante el cierre contable (Diciembre 2012 a Enero 2013). Impacto en caso de no pasar la prueba: En caso de producirse algún problema hay que verificar la configuración de la infraestructura por nuestra parte y la configuración del RP por parte de la consultora externa. Simulación para la realización de la prueba: Monitorizar acceso de los usuarios a los sistemas y verificar los tiempos de respuesta que obtienen durante el cierre contable. Problemas encontrados: En esta fase de pruebas no se han detectado problemas Rendimiento en circunstancias normales Prueba P1.4.1 Descripción de la prueba: Esta prueba recoge la monitorización del rendimiento de la plataforma durante el día a día. Fase de realización de la prueba: Monitorización diaria de la plataforma. Impacto en caso de no pasar la prueba: En caso de producirse algún problema hay que verificar la configuración de la infraestructura por nuestra parte y la configuración del RP por parte de la consultora externa. Simulación para la realización de la prueba: Monitorizar acceso de los usuarios a los sistemas y verificar los tiempos de respuesta que obtienen durante el cierre contable. 102

111 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 Análisis de problemas Problemas de discos de la cabina 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 Problemas de discos en los servidores 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. 103

112 Problemas de alimentación eléctrica 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. 104

113 6.- Gestión del proyecto 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 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 Factores que han afectado al ciclo de vida 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 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. 105

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

115 Cada una de ellas implicó, tras el cambio, a hacer un análisis del sistema para verificar que todo funcionaba como es debido 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 Migración de servidores a las nuevas versiones de sistema operativo. - Ampliación de la infraestructura de virtualización Comparativas Comparativa de horas estimadas con las reales Horas 500 Horas 0 Estimadas 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 Repartición en tareas de las hor as reales dedicadas al proyecto Reparto de horas Contacto inicial DOP Análisis y diseño Implantación Pruebas 107

116 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 Comparativa de l as tareas a lo largo del tiempo Tiempo real Contacto inicial DOP Análisis y diseño Implantación Pruebas Tiempo estimado Documentación 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 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 108

117 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 109

118 110

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

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

121 - 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 / Ext Primaria /dev/sda2 N/A Swap 8189 Primaria /dev/sdb1 /tmp Ext Primaria /dev/sdb2 /home Ext Primaria /dev/sdb3 113

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

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

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

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

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

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

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