Autorizada la entrega del proyecto del alumno: Manuel Reaño Costales. EL DIRECTOR DEL PROYECTO Miguel Angel Robles Rumayor

Transcripción

1 Autorizada la entrega del proyecto del alumno: Manuel Reaño Costales EL DIRECTOR DEL PROYECTO Miguel Angel Robles Rumayor Fdo: Fecha: Vº Bº del Coordinador de Proyectos David Contreras Bárcena Fdo: Fecha:

2 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO EN INFORMÁTICA PROYECTO DE FIN DE CARRERA IMPLANTACIÓN DE CLUSTERS DE ALTA DISPONIBILIDAD DIRECTOR: Miguel Angel Robles AUTOR: Manuel Reaño Costales

3 RESUMEN DEL PROYECTO En los entornos empresariales se demanda cada vez más que las aplicaciones den servicio de forma continua, siendo necesario para muchas aplicaciones de producción ofrecer una disponibilidad de 24x7. Esta necesidad lleva a muchas empresas a firmar Acuerdos de Niveles de Servicio (ANS) que establecen los tiempos de parada máximos que son asumibles por el negocio. Estos ANS pueden ser acuerdos internos con los departamentos de IT de la propia empresa, pero también pueden ser externos con otras empresas, si tienen externalizados los servicios de administración IT, o si sus aplicaciones dependen de aplicaciones de terceros. Dentro de este marco, todas las tareas destinadas a evitar los fallos o a minimizar el impacto de dichos fallos toman mucha más importancia, puesto que cada incidencia penaliza en cuanto al resultado de los ANS. Sin embargo, no son las caídas por causas accidentales las responsables de la mayor parte tiempo de no disponibilidad. Las tareas necesarias para la administración y el mantenimiento de los servidores y las aplicaciones son las causantes del 85% de media del tiempo total de indisponibilidad, frente al 1% causado por fallos del HW, y el 14% debido a otros factores, en su mayoría errores humanos en la administración. Este proyecto nace de las dificultades que experimentaba el departamento de IT de una empresa para alcanzar los niveles marcados por los ANS que tienen firmados. Los servidores tenían problemas de rendimiento y cortes de servicio de las aplicaciones de explotación. Estos cortes estaban provocados tanto por la sobrecarga experimentada y por incidencias accidentales como por las tareas de mantenimiento, cada vez más frecuentes a medida que la plataforma HW se quedaba obsoleta. Una vez identificada la problemática, la empresa ha solicitado presupuesto a varias compañías para que diseñen una solución que corrija su situación. Este proyecto conforma la propuesta presentada a dicha empresa, y ha sido seleccionado e implantado con éxito. Para solucionar estos problemas, este proyecto propone dos aspectos: la renovación de los sistemas y la implantación de una solución de alta disponibilidad. La renovación HW pretende solucionar los problemas de rendimiento y reducir las tareas de mantenimiento, y la solución de alta disponibilidad pretende minimizar el impacto de las caídas accidentales y enmascarar los tiempos de las paradas planificadas. La primera etapa de este proyecto ha sido la de análisis de requisitos y se ha realizado de forma previa a la presentación de la propuesta. Esta etapa ha consistido en la

4 identificación de la plataforma HW del cliente y de las aplicaciones que componen sus sistemas de producción, desarrollo y calidad. Se han tomado datos de rendimiento de los servidores para identificar los cuellos de botella y poder dimensionar correctamente los nuevos sistemas. La segunda etapa del proyecto, realizada también antes de la presentación de la propuesta, ha sido la del diseño de la solución. Esta etapa se ha dividido en dos fases: diseño de la plataforma HW y diseño de la topología de cluster. Para la plataforma HW se ha seleccionado entre los distintos servidores IBM System p5, que utilizan un sistema operativo de tipo UNIX propietario de IBM llamado AIX. Para la solución de clusters de alta disponibilidad se ha seleccionado una solución llamada IBM HACMP, y se han configurado 4 clusters de dos nodos, en modo activo-activo para soportar todas las aplicaciones de producción de la empresa. Una vez realizado el diseño de la solución se ha presentado la propuesta al cliente. Una vez aprobada la oferta, la siguiente etapa del proyecto ha sido la implantación de la solución. Esta implantación ha incluido la instalación completa de los servidores y la configuración de los clusters, y la realización de pruebas de rendimiento y de funcionamiento de HACMP. Esta etapa se ha concluido con la aceptación por parte del cliente de los resultados de las pruebas. La última etapa del proyecto ha sido la entrega de la documentación al cliente y el cierre del proyecto. Dentro de la documentación entregada se han incluido las conclusiones que confirman que los objetivos iniciales se han alcanzado, y también se ha incluido una serie de propuestas, para futuras ampliaciones o mejoras de los sistemas. Con le entrega de la documentación y la aceptación por parte del cliente de las conclusiones se ha dado por finalizado este proyecto.

5 HIGH AVAILABILITY CLUSTERS IMPLANTATION ABSTRACT In enterprises environments, there is a growing demand for their business applications to offer a continuous availability, being necessary for some live applications to run in a 24x7 way. This necessity forces a lot of enterprises to sign Service Levels Agreements (SLA), which establish the maximum downtimes that can be accepted by business. This makes all the tasks focused on avoiding failures or diminishing the impact of these failures to take much more relevance, since each incidence penalizes SLA s results. Nevertheless, it s not unplanned downtimes, due to accidental factors, that are responsible of the longest total downtime. Tasks needed and scheduled for the administration and maintenance of systems and applications are responsible for 85% of the total system downtime, meanwhile HW failures only represents 1% and other factors like human errors represents 14%. This project is born of the difficulties that an IT department experienced to achieve their SLA s signed levels. Their servers had performance issues and their applications suffered loss of service. This downtimes were caused by servers overload, accidentals failures and by maintenance tasks, more and more frequent as the HW remained obsolete. Once they did identify the problem, this company asked several providers for a solution that corrects their situation. This project is a proposal made to this company, and it has been selected and successfully installed. To solve these problems, this project suggests two ways: HW renovation and a high availability (HA) clustering solution. HW renovation will lead to a performance increase and will reduce maintenance necessity, and the HA solution will reduce unplanned downtimes and it will also mask planned downtime. The first step is to analyze the client s requirements, study their HW platform and their applications. The performance has been analyzed, collecting the performance data to identify bottlenecks and to determine the new systems capacities. This project s second step is to design the HW platform and the clusters topology. HW has been chosen from the IBM System p5 family, which runs a UNIX like operating system called IBM AIX. The selected HA clustering solution is IBM HACMP, configured with 4 two-node clusters, in an active-active topology, to achieve continuous availability for their live applications.

6 The next step is the implantation. This step includes the servers complete installation, the HA clusters configuration, and the performance and availability tests. This step is concluded when the client gives its agreement to the results of the tests. The last step of this project is the delivery of the documentation to the client. Within the delivered documentation there are some conclusions that prove that the initial goals have been achieved, and there are also some new proposals, for future upgrades and improvements of the systems. Once the documentation has been delivered, the project ends with the client s agreement to the conclusions presented.

7 Índice I. Introducción 1 II. Objetivos del proyecto 3 III. Alta Disponibilidad 6 IV. Análisis de requisitos 12 IV.1. Situación actual del cliente 12 IV.2. Rendimiento actual de los servidores 15 IV.3. Análisis de los datos obtenidos 19 IV.4. Requisitos de los nuevos sistemas 22 V. Estudio de soluciones 24 V.1. Sistema operativo IBM AIX 24 V.2. Servidores IBM pseries 25 V.3. Particionamiento Lógico LPAR 26 V.4. Ampliación de capacidad bajo demanda (CUoD) 30 V.5. Habilitación de capacidad bajo demanda (CoD) 30 V.6. IBM HACMP Clusters 31 VI. Diseño de la solución 36 VI.1. Configuración hardware 36 VI.2. Configuración HACMP 50 VI.3. Diseño final 56 VII. Evaluación Económica de la Oferta 62 VII.1. Valoración Económica HW/SW 62 VII.2. Valoración Económica servicios 84 VII.3. Valoración Económica Total 85 VIII. Implantación de la solución 86 VIII.1. Enracado de los servidores 86 VIII.2. Interconexión HMC Sistemas gestionados 88 VIII.3. Creación de particiones 89 VIII.4. Instalación del sistema operativo 98 VIII.5. Configuración HACMP 99

8 IX. Configuración adicional 107 IX.1. Auditoria de eventos 107 IX.2. Movimiento de recursos 108 IX.3. Sincronización horaria 110 X. Conclusiones 111 X.1. Objetivos alcanzados 111 X.2. Mejoras propuestas 117 Bibliografía 120 Anexos 121 Anexo A Auditoria 121 Anexo B Movimientos de recursos 127 Anexo C Configuración de ntp 132 Anexo D Alta Disponibilidad sobre Linux 135

9 Página 1 de 142 I. Introducción En los entornos empresariales, las aplicaciones de producción así como los datos que éstas manejan constituyen dos de los activos más valiosos y a la vez más críticos de las empresas. Su falta de disponibilidad puede suponer perjuicios graves tanto en términos económicos como de pérdida de confianza de los clientes y de merma de la imagen. Garantizar la máxima disponibilidad de estos activos se ha convertido por lo tanto en una de las principales prioridades de muchas empresas, dedicando a ello cada vez mayores recursos. Claros ejemplos de esto son empresas como los bancos o las empresas aseguradoras, cuyo negocio depende cada vez en mayor medida de las aplicaciones on-line, pero también las administraciones públicas que están realizando cuantiosas inversiones para desarrollar la llamada e-administración. Para poder aumentar la disponibilidad de las aplicaciones es vital conocer cuales son los factores que pueden afectarla. Dichos factores se pueden englobar en tres grandes categorías: disminución de la disponibilidad por causas accidentales, por gestión del sistema y por sobrecarga del sistema. Disminución de la disponibilidad por causas accidentales Son tiempos de parada no planificados, y las causas más comunes son: - Fallo de un componente del servidor (alimentación, adaptador de red, procesador, memoria, etc ) - Fallo completo del servidor - Fallo de acceso a los datos - Fallo de un disco - Fallo de un componente de la red (switches, cableado, etc ) - Fallo del suministro eléctrico Disminución de la disponibilidad por gestión del sistema Son tiempos de parada necesarios y planificados, y según las estadísticas son la causa de la mayor parte del tiempo de indisponibilidad. Las causas más comunes son:

10 Página 2 de Actualización de versiones (del sistema operativo o de las aplicaciones) - Aplicación de parches - Tareas de administración, mantenimiento y gestión (procesos batch, copias de seguridad, etc ) - Pasos a producción de nuevas aplicaciones Disminución de la disponibilidad por sobrecarga del sistema - Normalmente picos temporales (horas punta, finales de mes, etc ) - Disminución del rendimiento - Ralentización de las transacciones - Desconexión por time-out en las aplicaciones cliente Los clusters de alta disponibilidad están enfocados a paliar los efectos de las dos primeras categorías (accidente y gestión). Son soluciones que mediante el uso de elementos hardware y software intentan minimizar los tiempos de caída por accidente y eliminar o enmascarar los tiempos de parada planificada por tareas de gestión. Se basan en el uso de componentes hardware redundantes y de scripts para la automatización de las tareas. En el caso de la sobrecarga del sistema, los mecanismos ofrecidos por los clusters de alta disponibilidad no mejoran el rendimiento, de hecho las medidas adoptadas por estas soluciones pueden afectar en momentos puntuales el rendimiento. Para estos casos hay que implementar soluciones que permitan la habilitación de capacidad bajo demanda (CoD, Capacity on Demand).

11 Página 3 de 142 II. Objetivos del proyecto Este proyecto nace debido a las dificultades que tiene el departamento de IT de una empresa para cumplir los acuerdos de nivel de servicio (SLA, Service Level Agreement) que tiene definidos, tanto internamente con otros departamentos de la empresa como externamente con otras empresas. Debido a estos problemas se ha planteado una renovación de la plataforma hardware existente, consolidación de servidores de producción y desarrollo, y la implantación de alguna solución que permita aumentar la disponibilidad de las aplicaciones de producción. Una vez planteado el proyecto se ha solicitado una solución a varios proveedores, que incluya los siguientes requerimientos y condicionantes: - Aumento del rendimiento - Disminución del tiempo de indisponibilidad - Plataforma hardware ampliable - Futura integración de nuevas aplicaciones - Ahorro de espacio Es con estos condicionantes como se enfoca inicialmente este proyecto, definiendo una lista de objetivos a cumplir: Plataforma IBM AIX Los sistemas actuales del cliente se basan en el sistema operativo IBM AIX (sistema operativo UNIX propietario de IBM). Si bien no es requisito indispensable, el uso de un sistema operativo conocido por el cliente, y la continuidad del soporte a las aplicaciones es un factor positivo a la hora de presentar la oferta al cliente. Aumento del rendimiento El hardware ofertado debe ofrecer un rendimiento mayor del que obtienen con su plataforma hardware actual.

12 Página 4 de 142 Asegurar la capacidad de proceso (CoD) La sobrecarga generada en horas punta puede llegar a provocar una pérdida de disponibilidad. Mediante la habilitación de capacidad bajo demanda se elimina un posible punto de fallo. Eliminación de los puntos únicos de fallo (SPOF, Single Point Of Failure) Los SPOFs son componentes que constan de un solo elemento dentro del sistema. Asegurando redundancia de todos los componentes se eliminan dichos SPOFs y se asegura la disponibilidad en el caso de un fallo. Eliminar o enmascarar el tiempo de parada planificado El tiempo de parada planificado representa más del 80% del tiempo total de no disponibilidad de los sistemas. Eliminar este tiempo de parada supone por lo tanto una mejora sustancial a la hora de cumplir con los acuerdos SLA. Minimizar el tiempo de caída accidental El tiempo de recuperación tras una caída accidental depende del tiempo que se tarda en detectar la caída y el componente que la ha causado. Haciendo que sea el sistema quien detecte las caídas y automatizando el proceso de recuperación se reduce al mínimo posible este tiempo de no disponibilidad. Asegurar la validez y consistencia de los datos Si no se puede asegurar la validez de los datos estos carecen de valor para la empresa. Una integración adecuada de las aplicaciones con la solución se logra mediante el uso de scripts que controlan el estado de las bases de datos en el arranque y en la parada de las aplicaciones.

13 Página 5 de 142 Integrar las aplicaciones de producción El objetivo de los clusters no es disponer de hardware redundante o de servidores en alta disponibilidad, sino que se trata de poner en alta disponibilidad las aplicaciones. La solución adoptada debe por lo tanto permitir la integración de muy diversas aplicaciones, tanto comerciales como desarrollos propios. Ahorro de espacio Para el cliente el ahorro de espacio es muy importante, ya que sus servidores se encuentran alojados en las instalaciones de un proveedor de servicios de hosting y housing. En estas condiciones un ahorro de espacio supone para el cliente un ahorro de costes en la relación con su proveedor. Asegurar capacidad de crecimiento Para el cliente es primordial asegurar la capacidad de crecimiento de la solución adoptada, ya que en caso contrario no se justifica la inversión necesaria para realizar el proyecto. Ahorro de costes Este proyecto conforma la oferta que se va a realizar a un cliente que ha solicitado una solución a varios proveedores, por lo que debe ser económicamente competitivo.

14 Página 6 de 142 III. Alta Disponibilidad Este proyecto consiste en su mayor parte en el diseño, la implantación y la configuración de una solución de alta disponibilidad por lo que es conveniente aclarar lo que se entiende por alta disponibilidad en los sistemas informáticos y ver las diferencias respecto de otras soluciones. Los sistemas informáticos se pueden clasificar en función de la disponibilidad y fiabilidad que ofrecen en las siguientes categorías: - sistemas stand-alone - sistemas mejorados - clusters de alta disponibilidad - sistemas tolerantes a fallos Sistemas stand-alone Es la configuración más sencilla, y consta de un servidor único y sin acceso a almacenamiento externo. Si bien en la actualidad la mayoría puede ofrecer muchas mejoras, sigue teniendo múltiples SPOFs. Puntos fuertes - sistema de ficheros registrado por diario (por ejemplo JFS, Journaled File System), que ofrece detección recuperación de fallos leves - fuentes de energía redundantes - sistemas de refrigeración redundantes - memoria ECC, con código de corrección de errores (ECC, Error Correcting Code) - desactivación de procesadores en caliente - procesador de servicio o similar, para una mejor administración del HW y administración en remoto (incluido arranque en remoto) - discos en distintos niveles de RAID - kernel dinámico

15 Página 7 de 142 Puntos únicos de fallo - caída del servidor - fallo de un interfaz de red - fallo de la red - fallo de la aplicación - fallo del sistema operativo - camino único a los datos - discos no reemplazables en caliente - fallo del site Sistemas mejorados Los sistemas mejorados disponen de acceso a almacenamiento externo con distintos niveles de raid y que puede soportar el acceso a los datos por múltiples caminos. Puntos fuertes - sistema de ficheros JFS - fuentes de energía redundantes - sistemas de refrigeración redundantes - memoria ECC - desactivación de procesadores en caliente - procesador de servicio - discos en distintos niveles de RAID - kernel dinámico - tarjetas reemplazables en caliente (hot-swap) - múltiples caminos a los datos - discos reemplazables en caliente (hot-swap) - discos de reemplazo automático (hot-spare) - sistema de almacenamiento independiente - fuentes de energía del almacenamiento redundantes - sistemas de refrigeración del almacenamiento redundantes

16 Página 8 de 142 Puntos únicos de fallo - caída del servidor - fallo de un interfaz de red - fallo de la red - fallo de la aplicación - fallo del sistema operativo - fallo del site Sistemas de alta disponibilidad Los sistemas de alta disponibilidad intentan solventar los problemas de los sistemas stand-alone y mejorados mediante la redundancia de todos sus componentes. Si uno de sus componentes fallase, otro componente de backup está a la espera para asumir su carga de trabajo. Por ejemplo, si falla un adaptador de red otro adaptador asume de manera automática su dirección IP y su carga de trabajo. Puntos fuertes - sistema de ficheros JFS - fuentes de energía redundantes - sistemas de refrigeración redundantes - memoria ECC - desactivación de procesadores en caliente - procesador de servicio - discos en distintos niveles de RAID - kernel dinámico - tarjetas reemplazables en caliente (hot-swap) - múltiples caminos a los datos - discos reemplazables en caliente (hot-swap) - discos de reemplazo automático (hot-spare) - sistema de almacenamiento independiente - fuentes de energía del almacenamiento redundantes - sistemas de refrigeración del almacenamiento redundantes - adaptadores de disco duales

17 Página 9 de nodos redundantes (sistema operativo y aplicaciones) - adaptadores de red redundantes - redes redundantes - monitorización de las aplicaciones - sites redundantes mediante la replicación a larga distancia Puntos únicos de fallo - fallo de la replicación del site Sistemas tolerantes a fallos Los sistemas tolerantes a fallos están diseñados para no fallar nunca. Son soluciones extremadamente complejas y costosas si se comparan con soluciones basadas en clusters de alta disponibilidad. Los escasos fabricantes que venden sistemas tolerantes a fallos ofrecen una gama reducida de soluciones, lo que significa poca compatibilidad y poca escalabilidad. En estos sistemas, la relación entre precio y beneficio supone un problema, como también lo supone la naturaleza propietaria del hardware y del sistema operativo, lo que suele implicar el desarrollo a medida de todas las aplicaciones. Dicho esto, los sistemas tolerantes a fallos están diseñados para no fallar, por lo que si no se puede permitir ningún tiempo de caída de las aplicaciones (sistemas críticos para la vida humana) entonces hay que plantearse este tipo de soluciones. Puntos fuertes - sistema de ficheros JFS - fuentes de energía redundantes - sistemas de refrigeración redundantes - memoria ECC - desactivación de procesadores en caliente - procesador de servicio - discos en distintos niveles de RAID - kernel dinámico - tarjetas hot-swap - múltiples caminos a los datos

18 Página 10 de discos hot-swap - discos hot-spare - sistema de almacenamiento independiente - fuentes de energía del almacenamiento redundantes - sistemas de refrigeración del almacenamiento redundantes - adaptadores de disco duales - nodos redundantes - adaptadores de red redundantes - redes redundantes - monitorización de las aplicaciones - sites redundantes - procesadores a prueba de bloqueos - procesadores síncronos (lock-step) - sistema operativo a prueba de bloqueos - sistema operativo síncrono (lock-step) - reinicio en continuo Puntos únicos de fallo - en teoría ninguno, si bien en algunas configuraciones puede darse fallo del site La siguiente tabla ofrece la relación entre algunos factores relevantes a la hora de diseñar un sistema, en cuanto a disponibilidad se refiere: Alta Tolerantes a Stand-alone Mejorados disponibilidad fallos Tiempo de recuperación Disponibilida d de los datos Coste relativo Puede llegar a días Un par de horas Cinco minutos En teoría nulo La última copia de La última La última Sin pérdida seguridad transacción transacción de datos disponible 1 1,5 2-3 > 10

19 Página 11 de 142 Beneficios de las soluciones de alta disponibilidad Las distintas soluciones de alta disponibilidad ofrecen los siguientes beneficios: - uso de componentes estándar, sin necesidad de hardware especializado - se pueden implementar usando sistemas ya disponibles, por lo que se puede evitar el gasto de invertir en HW nuevo - funcionan con casi cualquier tipo de aplicación, en cuanto a aplicaciones comerciales se refiere - trabajan sobre sistemas operativos comunes - ofrecen una gran disponibilidad a un coste relativamente bajo Requisitos para la alta disponibilidad Para que un sistema de alta disponibilidad funcione correctamente y rentabilice la inversión, es necesario cumplir una serie de requisitos: - un diseño robusto y una planificación detallada - eliminación de los puntos únicos de fallo - selección del HW apropiado (si bien no necesita HW especializado para alta disponibilidad, si que debe tener unas características mínimas) - implementación correcta y cuidadosa - disciplina a la hora de administrar el sistema - documentación detallada y actualizada - realizar pruebas exhaustivas

20 Página 12 de 142 IV. Análisis de requisitos Para poder presentar una configuración adecuada es necesario realizar un estudio detallado de la situación actual del cliente, la plataforma hardware, el sistema operativo y las aplicaciones que tiene. De esta manera se podrán definir los requisitos mínimos que deben tener los nuevos sistemas para cumplir con los objetivos. IV.1. Situación actual del cliente En la actualidad el cliente tiene sus aplicaciones sobre máquinas con las siguientes características: - servidores 7026-B80 (pseries 640 Model B80) - 1 o 2 procesadores POWER3-II 375 MHz - entre 512 MB y 4 GB de memoria ECC SDRAM - 1 o 2 discos internos de 36,4 GB - modelo enracable de 5 Us de alto IBM pseries 640 Model B80 La relación de los servidores y sus configuraciones con las aplicaciones que soportan es la siguiente: Servidor Configuración Aplicaciones Baco 1-way 375 MHz, 1 GB memoria, 2 discos internos Producción: Ediswitch

21 Ceres Cupido Diana Febo Juno Júpiter Marte Mercurio Minerva Neptuno Ops Pluton Saturno 1-way 375 MHz, 1 GB memoria, 2 discos internos. Utiliza X25 1-way 375 MHz, 1 GB memoria, 2 discos internos 2-way 375 MHz, 1 GB memoria, 1 disco interno 1-way 375 MHz, 1 GB memoria, 1 disco interno. Utiliza X25 2-way 375 MHz, 2 GB memoria, 2 discos internos 2-way 375 MHz, 2 GB memoria, 2 discos internos 2-way 375 MHz, 2 GB memoria, 2 discos internos 1-way 375 MHz, 2 GB memoria, 2 discos internos 1-way 375 MHz, 2 GB memoria, 2 discos internos 1-way 375 MHz, 1 GB memoria, 2 discos internos 1-way 375 MHz, 4 GB memoria, 1 disco interno 1-way 375 MHz, 512 MB memoria, 1 disco interno 1-way 375 MHz, 512 MB memoria, 1 disco interno Página 13 de 142 Producción: Editran + Expedite Desarrollo: Informix + servidor web Producción: Odex Producción: Odex Producción: Oracle Producción: Oracle Producción: Oracle Producción: Oracle + Informix Desarrollo: Oracle + Informix Desarrollo/Calidad: Servidor web Desarrollo: Weblogic Desarrollo: Weblogic Desarrollo: Weblogic

22 Página 14 de 142 Urano 1-way 375 MHz, 2 GB Desarrollo: Weblogic memoria, 1 disco interno Venus 1-way 375 MHz, 2 GB Desarrollo: Weblogic memoria, 1 disco interno Relación servidores/aplicaciones (en negrita están las que se quieren poner en alta disponibilidad Rendimiento Para los sistemas IBM pseries existen varias medidas para el cálculo del rendimiento teórico de los servidores. Estas medidas llamadas Relative Online Transaction Processing (ROLTP) y Relative Performance (rperf) establecen una comparación del rendimiento teórico frente a una configuración de base. En este caso se usará la unidad rperf como medida del rendimiento. Los valores rperf de los servidores del cliente son los siguientes: - 1 procesador: rperf = 1-2 procesadores: rperf 2 (en realidad ligeramente inferior a 2, pero se toma rperf = 2 para las estimaciones) El valor total de rperf de los sistemas es por lo tanto de 20. Almacenamiento Los servidores con 2 discos internos tienen los discos en mirror (RAID nivel 1) para evitar posibles fallos. Los discos internos están dedicados al sistema operativo y los ejecutables de las aplicaciones. Las aplicaciones de producción con necesidades especiales de almacenamiento (por ejemplo las bases de datos) tienen acceso a almacenamiento externo a través de una red SAN (Storage Area Network). Dicho almacenamiento está ubicado en cabinas de discos externas, con acceso mediante conexiones de fibra óptica (cabinas EMC CLARiiON). Las aplicaciones de desarrollo y calidad tienen espacio asignado a través de una red NAS (Network Attached Storage).

23 Página 15 de 142 Ubicación y enracado Los servidores del cliente se encuentran alojados en las instalaciones de un proveedor de servicios de hosting y housing. Este proveedor proporciona el espacio necesario dentro de unas salas de servidores acondicionadas según los estándares: suministro eléctrico, temperatura y humedad controladas, seguridad de acceso, etc Los servidores se encuentran enracados en armarios estándar de 36 Us de alto, ocupando actualmente un total de 86 Us en 3 armarios (16 servidores de 5 Us de alto + 3 pantallas TFT de 2 Us de alto cada una). IV.2. Rendimiento actual de los servidores Desde la implantación de los sistemas actuales, la carga de trabajo de todos los servidores y las aplicaciones ha aumentado de manera considerable, lo que ha provocado una disminución del rendimiento. Dicha disminución se ha traducido en unos tiempos de respuesta cada vez mayores, provocando incluso desconexiones por time-out cada vez más frecuentes. Para poder dimensionar correctamente el cliente ha facilitado los datos de rendimiento de sus sistemas actuales en la situación actual. En cada caso se va a estudiar principalmente el rendimiento desde el punto de vista del procesador y de la memoria. Se ha decidido que los aspectos relativos a los accesos a disco y los protocolos de red no se tendrán en cuenta para el estudio de la solución ya que para influir sobre estos dos aspectos habría que estudiar el diseño de las aplicaciones, y esto está fuera del alcance de este proyecto. Sin embargo, si en algún momento se detecta un problema con las operaciones de entrada/salida, tanto en los discos como en la red, que pueda evidenciar un problema ajeno al diseño de la aplicación se estudiará una posible mejora de la situación, dentro de los límites de este proyecto. Servidor Baco El servidor Baco consta de un procesador y 1 GB de memoria (rperf = 1). La aplicación que soporta es una aplicación de producción (Ediswitch).

24 Página 16 de 142 Los datos medios de ocupación del procesador, obtenidos mediante el comando sar, son los siguientes: %usr %sys %wio %idle Average Los datos medios de utilización de la memoria, obtenidos mediante el comando vmstat, son los siguientes: kthr memory page faults cpu r b avm fre re pi po fr sr cy in sy cs us sy id wa Los datos del espacio de paginación, obtenidos mediante el comando lsps, son los siguientes: PgSpace PhysicalVolume VolumeGroup Size %Used Active Auto Type hd6 hdisk0 rootvg 2048MB 35 yes yes lv Servidor Ceres El servidor Ceres consta de un procesador y 1 GB de memoria (rperf = 1). Las aplicaciones que soporta son aplicaciones de producción (Editran y Expedite). Los datos medios de ocupación del procesador, obtenidos mediante el comando sar, son los siguientes: %usr %sys %wio %idle Average Los datos medios de utilización de la memoria, obtenidos mediante el comando vmstat, son los siguientes: kthr memory page faults cpu r b avm fre re pi po fr sr cy in sy cs us sy id wa los siguientes: Los datos del espacio de paginación, obtenidos mediante el comando lsps, son