Embed Size (px)
Citation preview
Instituto Superior PolitécnicoJosé Antonio Echeverría
(CUJAE)
Departamento de Telecomunicaciones y Telemática
Reestructuración del centro de datos de laPresidencia de la corporación Cuba Ron S.A, Sede 44.
Presentado por:Irving Leonard Pérez de Alejo
Tutor:Ing. Carlos A. Gómez BrizuelaIng. Lilia Rosa García
a mi familia...
AgradecimientosA mi familia, a mis amigos, de Cuba Ron y todas partes, a mis tutores que supieron sobre-llevarme y no mandarme... GRACIAS.
Declaración de autoríaIrving Leonard Pérez de Alejo, autor de la tesis titulada “Reestructuración del centro de datos de la Presidencia de la Corporación Cuba Ron S.A., Sede 44”, realizada en el año 2011 en el Instituto Superior Politécnico José Antonio Echeverría (ISPJAE), autoriza al Departamento de Telecomunicaciones y Telemática a que utilice con la debida referencia a su autor, la presente tesis.
ResumenSe realizó un estudio de la estructura y funcionamiento de la empresa identificando sus necesidades. Se analizó el estado original del centro de procesamiento de datos (CPD) y se concluyó que no satisfacía los requerimientos de la empresa.
Se estudió el estado del arte en las tecnologías asociadas con el CPD y se seleccionaron las que se consideraron costo-efectivas.
Se expuso la implementación efectuada y se concluyó que aunque el diseño lograba los parámetros requeridos, la escasez de recursos limitó su efectividad.
AbstractA study was made about the business' structure and functionality and identified it needs. The original datacenter state was analyzed and arrived to the conclusion that it doesn't satisfied the business' requirements.
Another study was made about the state of the art associated with the technologies referring to datacenters and the most cost-effective were selected.
The real implementation was exposed and arrived to the conclusion that the design satisfied the requirements but its effectivity was limited by the lack of resources.
Índice de contenidoAgradecimientos...............................................................................................................................3Declaración de autoría.....................................................................................................................4Resumen.......................................................................................................................................... 5Introducción......................................................................................................................................9 Capítulo 1 : Caracterización de la Sede 44 de la corporación Cuba Ron S.A................................11
1.1 Introducción.......................................................................................................11 1.2 Corporación Cuba Ron S.A (Presidencia, Sede 44).............................................11
1.2.1 La Presidencia.............................................................................................................13 1.2.2 Caracterización de la sede 44.....................................................................................13
1.3 Necesidades TICs de la sede 44........................................................................15 1.4 Red corporativa de la Corporación Cuba Ron S.A..............................................16 1.5 Principales parámetros de un centro de datos..................................................17
1.5.1 Flexibilidad..................................................................................................................18 1.5.2 Escalabilidad...............................................................................................................19 1.5.3 Disponibilidad..............................................................................................................20 1.5.4 Seguridad....................................................................................................................21
1.6 Estado inicial del equipamiento y las aplicaciones en el CPD de la Sede 44.....22 1.6.1 Servidores...................................................................................................................22 1.6.2 Almacenamiento..........................................................................................................24 1.6.3 Red.............................................................................................................................25 1.6.4 Gestión........................................................................................................................26
1.7 Presupuesto para la reestructuración................................................................27 1.8 Conclusiones.....................................................................................................27
Capítulo 2 : Tendencias y tecnologías actuales.............................................................................28 2.1 Introducción.......................................................................................................28 2.2 Procesamiento...................................................................................................28
2.2.1 Servidores discretos....................................................................................................28 2.2.2 Clúster de alta disponibilidad.......................................................................................30 2.2.3 Clúster de balanceo de carga......................................................................................31 2.2.4 Virtualización...............................................................................................................32 2.2.5 Supercomputadora......................................................................................................35 2.2.6 Mainframe...................................................................................................................36 2.2.7 Grid Computing...........................................................................................................36
2.3 Almacenamiento................................................................................................37 2.3.1 Redundancia local de datos........................................................................................38 2.3.2 Volúmenes..................................................................................................................41 2.3.3 Volúmenes compartidos..............................................................................................42 2.3.4 Sistemas de archivos de disco compartido..................................................................44 2.3.5 Almacenamiento integrado..........................................................................................45 2.3.6 Mecanismos para la disponibilidad ante catástrofes....................................................45
2.4 Red.................................................................................................................... 46 2.5 Computación en la Nube y Servidor Privado Virtual..........................................47 2.6 Selección de las tecnologías .............................................................................48
2.6.1 Virtualización...............................................................................................................49 2.6.2 Alta disponibilidad........................................................................................................51 2.6.3 Almacenamiento..........................................................................................................51 2.6.4 Especificaciones de la Red de Datos..........................................................................52
2.7 Aspectos de la infraestructura...........................................................................53 2.8 Conclusiones.....................................................................................................54
Capítulo 3 : Solución propuesta....................................................................................................55 3.1 Introducción.......................................................................................................55 3.2 Arquitectura de Servidores................................................................................55 3.3 Arquitectura de Almacenamiento......................................................................56 3.4 Arquitectura de Virtualización...........................................................................58
3.5 Arquitectura de Red...........................................................................................60 3.6 Arquitectura de Gestión.....................................................................................63 3.7 Conclusiones.....................................................................................................64
Conclusiones..................................................................................................................................65Recomendaciones..........................................................................................................................66Bibliografía.....................................................................................................................................67Anexos........................................................................................................................................... 68
IntroducciónEn la era de la información y las comunicaciones la mayoría de las organizaciones soportan sus principales procesos en infraestructuras tecnológicas. Parte medular de estas infraestructuras lo constituye el centro de procesamiento de datos (CPD), lugar donde se ejecutan las aplicaciones empresariales utilizadas en los procesos productivos. En el CPD se encuentran los equipos necesarios para el procesamiento, almacenamiento y transmisión de la información y en cuyo diseño deben tenerse en cuenta parámetros tales como: flexibilidad, escalabilidad, disponibilidad y seguridad.
En la Corporación Cuba Ron S.A. existe un esquema de CPDs distribuidos e independientes entre las diferentes dependencias que la conforman. El CPD perteneciente a la Sede 44 de la Presidencia debe brindarle a la misma los servicios de mensajería, almacenamiento compartido, plataformas web, etc. para un promedio de 40 usuarios. Lo anterior indica que este centro le brinda servicios a una pequeña empresa, soportando una modesta carga de trabajo, aunque representa un punto vital para las actividades de la empresa.
El estado actual de dicho CPD no cumple con los principios de diseño y despliegue básicos de un centro de datos, no haciendo por tanto un uso óptimo de los recursos. Presenta problemas de disponibilidad y seguridad porque la información y el acceso a la misma no están debidamente respaldadas y aseguradas, resultando entonces un ambiente no confiable. Las aplicaciones que ya se encuentran desplegadas no tienen la redundancia requerida por lo que están propensas, ante un fallo, a sufrir problemas de disponibilidad y grandes pérdidas de información.
Dada la situación problemática el problema a resolver en el presente trabajo es el diseño y funcionamiento deficiente del centro de datos de la Sede 44 de la Presidencia de la Corporación de Cuba Ron S.A. que resulta en un centro poco confiable.
El objeto de estudio para poderle dar la solución al problema es la arquitectura y funcionamiento de los Centros de Procesamiento de Datos (CPDs) y como campo de acción está el diseño y despliegue de CPDs para Pequeñas y Medianas Empresas (PyMEs).
El objetivo general del trabajo es el diseño y despliegue de una solución para el
centro de procesamiento de datos de la Sede 44 en la Presidencia de la Corporación Cuba Ron S.A., capaz de brindar los niveles de seguridad, flexibilidad, escalabilidad y disponibilidad que se requieren.
Como objetivos específicos se proponen utilizar software libre donde sea posible persiguiendo la independencia tecnológica y utilizar hardware común para mantener bajos costos.
Las tareas a cumplir para darle cumplimiento al objetivo planteado son:
1. Determinar las necesidades en cuanto a Tecnologías de la Informática y las Comunicaciones (TICs) se refiere en la sede, las proyecciones futuras y los recursos disponibles para satisfacer estas.
2. Analizar la situación actual del CPD que soporta los servicios de la sede.
3. Buscar información actualizada y estudiar acerca del diseño y despliegue de CPDs.
4. Seleccionar la tecnología a utilizar para dar solución a los problemas encontrados.
5. Proponer un diseño que cumpla con los niveles básicos de seguridad, flexibilidad, escalabilidad y disponibilidad.
Para abarcar este trabajo el documento se divide en tres capítulos:
El primer capítulo está dedicado a la descripción de la corporación, sus dependencias y la sede 44, así como el análisis de sus necesidades en cuanto a las TICs se refiere. Se valora además el estado actual del centro así como las capacidades de mejoras y expansión.
En el segundo capítulo se describen y analizan las tecnologías conocidas para la implementación de un CPD, en todos los aspectos que este requiere. Luego se decide el conjunto de tecnologías a usar en la solución propuesta, según los requerimientos y particularidades del centro en cuestión.
En el tercer capítulo se exponen las decisiones específicas, muchas condicionadas por políticas internas, de las implementaciones y esquemas a utilizar.
Capítulo 1 : Caracterización de la Sede 44 de la corporación Cuba Ron S.A.
1.1 Introducción
Las necesidades TICs de una empresa están dadas generalmente por la actividad que esta realiza; así mismo las posibles soluciones estarán dadas por la importancia que la informatización y automatización tengan en el proceso productivo y las posibilidades económicas que tenga dicha empresa para su implementación. La distribución de las funciones también juega un papel clave a la hora del diseño, siendo muy importante la especificación de las responsabilidades de cada entidad.
El presente capítulo pretende hacer una descripción de la corporación, sus dependencias y las necesidades que son motivo del presente trabajo.
1.2 Corporación Cuba Ron S.A (Presidencia, Sede 44)
La Corporación Cuba Ron S.A. es la organización que se ha erigido como productor de grandes marcas de ron en Cuba, depositaria de las más fieles tradiciones de la cultura ronera cubana, como parte enriquecedora e inseparable de la cultura nacional. Posee las principales y más antiguas fábricas del país y cuenta con un equipo de maestros roneros altamente calificados que han sabido hacer suyo el legado trasmitido de generación en generación. Constituida en Noviembre de 1993, es la organización llamada a unificar de modo armónico las principales y más tradicionales fábricas de ron cubano, en una estructura empresarial fuerte y única, con la agilidad necesaria para responder a los requerimientos y retos del comercio mundial actual.
Su misión consiste en tener una cartera de productos para la exportación y el mercado interno en divisas, competitivo y diversificado según los requisitos del cliente.
La visión que persigue, integrada al sistema de perfeccionamiento empresarial, es participar en el proceso de recuperación de la economía cubana, desplegando sus reservas de eficiencia en una estrategia empresarial, dirigida a diversificar en su objeto social.
La estructura de la corporación, encabezada por una presidencia, es la que se muestra en la figura 1.1.
La producción de ron está agrupada en cuatro establecimientos principales Figura 1.2: Distribución geográfica Cuba Ron S.A.
Figura 1.1: Estructura de la Corporación Cuba Ron S.A.
como puede apreciarse en la figura 1.2: Santa Cruz, Cárdenas, Central y Santiago de Cuba.
1.2.1 La Presidencia
La Presidencia tiene como función fundamental la regulación de todas las actividades de la corporación. Establece las estrategias, políticas y reglamentos a seguir por las entidades que conforman el sistema corporativo.
Además controla la implementación de las disposiciones en todas sus dependencias, realizando contactos y visitas de control.
Por otra parte se ocupa de la ejecución de las importaciones y exportaciones siendo un eslabón muy importante dentro de la línea comercial. Desarrolla además la actividad de mercadeo, sobre todo mediante soporte digital.
Este órgano se encuentra geográficamente distribuido, existiendo una Sede 200 (o Sede I) situada en calle 200 y avenida 17, reparto Atabey; y otra Sede 44 (o Sede II) en calle 44 y avenida 3ra, reparto Miramar, ambas en el municipio capitalino de Playa.
1.2.2 Caracterización de la sede 44
En la Sede 44 se encuentran algunas de las estructuras que conforman la presidencia que incluyen la Dirección de Mercado, la Dirección de Compras, el Puesto de Dirección, la Dirección de Informática y Automatización, el Grupo de Transporte, los Apoderados, el Grupo de Perfeccionamiento Empresarial y la Dirección de Fuerza de Trabajo.
La Dirección de Mercado tiene la responsabilidad de garantizar que se comercialicen los productos en el mercado externo de los rones marcas Santiago de Cuba, Cubay, Arecha y Legendario. Entre otras tareas, orienta y controla la Gestión de Mercadotecnia a nivel corporativo, colabora con la alta dirección en la evaluación general de las oportunidades del mercado, asesora a las diversas Unidades Empresariales de Base (UEBs) productoras y comercializadoras de la corporación en cuanto a la función de mercadotecnia y promueve la filosofía de la mercadotecnia al resto de las áreas de organización y control.
La Dirección de Compras desempeña un papel fundamental en el quehacer de
la corporación, pues tiene la responsabilidad de garantizar los insumos necesarios destinados a la producción y por consiguiente a las de la industria, además importa materias primas para otras entidades cubanas que utilizan iguales o similares suministros.
El Puesto de Dirección es un colectivo clave que trabaja las 24 horas del día con el objetivo de mantener un flujo informativo actualizado sobre todo lo que acontece en la corporación relacionado con la producción, ventas, exportaciones, servicios, operaciones especiales, transportaciones específicas, todo lo referente a los planes de defensa civil y las informaciones establecidas ante la aparición de eventos meteorológicos o microbiológicos, hechos extraordinarios que pudieran ocurrir y cualquier situación de excepción que se produzca en alguna de las entidades que integran la organización. Este grupo facilita la toma de decisiones ya que no solo recepciona la información sino que también la analiza y hace sugerencias.
La Dirección de Informática y Automática organiza racionalmente el sistema de información a implantar en el sistema corporativo y elabora los reglamentos y políticas de información y automatización. Garantiza también la certificación de los sistemas y asume el soporte de los usuarios y servicios en la presidencia.
El Grupo de Transporte, perteneciente a la Dirección de Logística funciona para garantizar la disponibilidad técnica de los medios de transporte y ejecutar las transportaciones de los insumos, materias secas y productos terminados. Controla ademas los relacionado con el tema del combustible.
Los Apoderados garantizan los trámites aduanales y otros en general que incluyen la nacionalización de las materias primas, materiales y otros con destino a las industrias del sistema, así como a terceros. Garantizan también los trámites que permitan la exportación del producto terminado.
El Grupo de Perfeccionamiento Empresarial supervisa la aplicación de las políticas, principios y procedimientos generales en el desarrollo del proceso de Perfeccionamiento Empresarial y realiza controles periódicos a las entidades con el objetivo de detectar los problemas que afectan el desarrollo del proceso. Planifica también la actividad de comunicación empresarial de la corporación como herramienta de gestión para el cambio y el mejoramiento en la empresa.
La Dirección de Fuerza de Trabajo conforma, en ocasiones de conjunto con
otras estructuras, los reglamentos y disposiciones laborales relacionadas con las plazas, regímenes de trabajo, capacitación, estimulación, seguridad y salud en el trabajo, aprovechamiento de la jornada laboral, etc. Así mismo definen la política salarial y estudian la relación costo-beneficio de los diferentes sistemas salariales.
1.3 Necesidades TICs de la sede 44.
Existen proyectos y aplicaciones ya desarrolladas para la automatización y/o agilización de los procesos de la empresa. No obstante no ha sido posible explotar esta capacidad al máximo en la sede 44 dada la poca disponibilidad y seguridad de la infraestructura y los servicios que se soportan en el CPD de esta.
La Dirección de Mercado requiere información actualizada de las proyecciones de producción de la corporación, de su capacidad y del estado del mercado mundial. En este caso la disponibilidad es primordial, pues ante un cliente la incapacidad de acceso a los datos genera desconfianza que puede llegar a la pérdida del negocio.
La Dirección de Compras requiere un flujo actualizado de las necesidades de la corporación. El fallo en este intercambio puede detener completamente la producción, siendo la actividad de esta dirección el principio de la línea de producción.
El Puesto de Dirección necesita acceso en tiempo real y todo el tiempo a los datos operativos de la corporación por lo que la disponibilidad es una característica crítica de los sistemas diseñados para este.
La Dirección de Informática y Automatización requiere información actualizada de las necesidades TICs de las otras estructuras. Todas las actividades sobre soporte digital dependen de la gestión de esta dirección por lo que es cada vez más importante el monitoreo de los requerimientos a medida que crece la informatización y automatización de los procesos. Así mismo requiere una solución escalable para ser capaz de satisfacer nuevas necesidades como también que sea flexible para poder redistribuir las existentes.
El Grupo de Transporte trabaja con un flujo constante de información relacionada a las necesidades y resultados de las fábricas. Es un punto crítico
ya que es la interfaz de la línea de producción lo cual influye sensiblemente en la continuidad de la producción por lo que la disponibilidad es una característica esencial.
El Grupo de Perfeccionamiento requiere el aseguramiento de los datos provenientes de toda la corporación. La integridad y seguridad de estos es primordial para su funcionamiento.
La Dirección de Fuerza de Trabajo requiere de una gran seguridad en los datos que maneja. El control de acceso a los datos y su integridad es de vital importancia para la gestión de esta dirección.
Aunque la corporación es una gran empresa con exportaciones en el rango de los millones de dólares anuales, la distribución de los centros de datos, que tributa a la no existencia de uno grande y centralizado, así como la situación económica del país provocan una semejanza de la sede, con un promedio de 40 usuarios, a una pequeña o mediana empresa (PyME). Es por esto que el trabajo se persigue lograr una solución enfocada a las PyME.
Cada una de estas necesidades trae aparejada muy poca carga, producto de las necesidades del personal que las utiliza. No se espera un aumento de la potencia dedicada a estas necesidades a diferencia del número de las mismas que debe crecer.
1.4 Red corporativa de la Corporación Cuba Ron S.A.
Las fábricas requieren que la información fluya por todas las dependencias para lograr una gran eficiencia en la producción. El principal medio utilizado históricamente ha sido el teléfono, la información se intercambia de persona a persona a través de llamadas telefónicas. Esto tiene como desventaja el alto costo por las llamadas de larga distancia y la alta probabilidad de ocurrencia de errores humanos.
Es por ello que en los últimos años se ha venido trabajando en la implementación de una Red de Área Amplia (WAN, por sus siglas en inglés) corporativa que enlace todas las dependencias de la corporación. Este proyecto tiene como principal motivación la disminución de gastos, al encaminar el tráfico telefónico a través de troncos de voz sobre IP (VoIP, por sus siglas en inglés) mediante la WAN, pero también abre todo un nuevo
espectro de posibilidades en la comunicación interna.
La red presenta una topología de estrella, como se observa en la figura 1.3, siendo la sede 200 de la presidencia el nodo central. A este nodo se conectan otras 6 dependencias: la sede 44, la distribuidora y las fábricas de Santa Cruz, Cárdenas, Central y Santiago de Cuba. La dependencia, en cuanto a servicios informáticos, es casi horizontal, siendo cada entidad responsable de sus servicios al tener cada una su canal independiente a Internet (los enlaces de la distribuidora y ronera Santiago están aún en contratación). El uso de la red corporativa es para el consumo de los servicios internos, los cuales pueden ubicarse en cualquiera de las entidades.
Actualmente la red corporativa se encuentra en un proceso de migración a IP/MPLS que disminuirá los costos, lo cual se piensa reinvertir en aumentar los anchos de banda de los enlaces. Esto además mejorará los tiempos de demora al cambiar a una topología de malla.
Figura 1.3: Red corporativa Cuba Ron S.A.
1.5 Principales parámetros de un centro de datos
Se denomina centro de procesamiento de datos (CPD) a aquella ubicación donde se concentran todos los recursos necesarios para el procesamiento de la información de una organización. Es una edificación para albergar sistemas de computadoras y componentes asociados, como sistemas de telecomunicaciones y almacenamiento.
De su correcto funcionamiento depende el desarrollo satisfactorio de las actividades de la empresa por lo que constituye un punto estratégico. Dada la importancia que tiene, debe cumplir con parámetros que justifiquen la responsabilidad que en este se deposita.
1.5.1 Flexibilidad
La flexibilidad se refiere a diseños que pueden adaptarse ante la ocurrencia de cambios externos. Se puede definir como la habilidad de un sistema de responder rápidamente a cambios internos o externos de forma costo-efectiva.
Es poco probable que el CPD se mantenga inmutable por toda su vida, por ello se puede decir que debe existir la posibilidad de reconfigurar los recursos del centro en nuevas distribuciones. Esta reconfiguración a su vez no debe traer aparejado grandes costos sino que se puedan hacer como valor inherente al diseño.
Una técnica desarrollada con este fin y muy utilizada en el mundo es la virtualización. Consiste en convertir los dispositivos físicos, de alguna manera, en dispositivos lógicos los cuales no responden a las mismas restricciones de posicionamiento, así se pueden “mover” los recursos a donde sean más necesarios.
Con esto se habilita al diseño con una posibilidad para reaccionar ante cambios reconfigurando sus recursos. Esta reconfiguración, si se automatiza, puede lograr una alta relación costo-efectividad.
La flexibilidad aporta también a escalabilidad ya que hace posible escalar a recursos en desuso o sub-utilizados.
En el CPD de la sede 44 no era capaz de adaptarse a los cambios sin el agregado de un gran volumen de trabajo manual por parte de los operadores.
El software trabajaba directamente sobre hardware al no existir virtualización de ningún tipo, por lo que no contaba con la capacidad de reconfiguración de forma costo-efectiva. Es por esto que el diseño puede calificarse como poco flexible.
1.5.2 Escalabilidad
La escalabilidad es una propiedad deseable en un sistema, red o proceso que indica la habilidad de soportar crecientes cantidades de trabajo creciendo de forma rápida y sencilla.
La escalabilidad, en cuanto a la carga de trabajo se refiere, es capacidad de asimilar la variación del número de usuarios, aplicaciones y/o tareas sin impactar sustancialmente en el funcionamiento normal. Durante el diseño se deben tener en cuenta las proyecciones de la empresa para el tiempo de vida de forma que se calcule dicho crecimiento y se tomen medidas para poder acomodarlo.
Al culminar el ciclo de vida se deben volver a valorar las necesidades y proyecciones y hacer un nuevo diseño que se adecue a estas. En ocasiones no se logra prever un crecimiento acelerado lo que provoca que el diseño, y por consiguiente el CPD, quede obsoleto antes del tiempo previsto, o sea, que disminuya el tiempo de vida.
Así mismo el hardware y la plataforma de software deben ser capaces de hospedar nuevas aplicaciones acorde al crecimiento esperado. El incremento de las instancias, número de usuarios y equipos no debe conllevar grandes trabajos.
El CPD de la Sede 44 tenía un esquema fijo de aplicación donde no resultaba natural insertar nuevas aplicaciones. Esta operación degradaba aún más el resto de los parámetros, creando más brechas de seguridad y comprometiendo aún más la disponibilidad. La falta de flexibilidad afectaba también la capacidad de crecimiento al no ser posible ocupar cierto hardware sub-utilizado con las aplicaciones que se requería desplegar. Esto demuestra que en su momento no se valoró efectivamente las proyecciones de crecimiento de la estructura.
Por otro lado el aumento del número de usuarios en las aplicaciones existentes
no causaba grandes problemas. La capacidad instalada demostró ser suficiente para el número de usuarios que utilizó el centro.
Se puede calificar entonces el centro como un CPD poco escalable, por lo que se deben analizar las malas proyecciones que se hicieron para evitarlas en el futuro.
1.5.3 Disponibilidad
En cuanto a servicios se refiere se puede decir que cuando un sistema es capaz de ser utilizado por un cliente, un ente para el cual se diseñó el servicio, este está disponible.
La disponibilidad se calcula como el por ciento que el servicio se encontró disponible en un período de tiempo. Cuando esta es mayor del 99% tiende a expresarse en cantidad de 9. La calificación de la disponibilidad se define en dependencia de las característica y necesidades de las empresa, y de las restricciones que esta tenga a la hora del diseño.
Las afectaciones a la disponibilidad vienen dadas por las interrupciones. Las interrupciones programadas, como las tareas de mantenimiento, en ocasiones no se incluyen en el cálculo de la disponibilidad. Las interrupciones no programadas, como las roturas, afectan grandemente el desarrollo de las actividades y de no existir un plan de contingencias, preferiblemente automatizado, o una plataforma altamente disponible, pueden registrarse largos períodos de tiempo fuera de servicio.
Existe una calificación traducible como nivel de portadora (carrier grade) que establece una disponibilidad de 5 nueves para los servicios del CPD. En una pequeña empresa esto eleva demasiado los costos a cambio de muy poca retribución.
En el centro de datos de la sede 44 no existía una plataforma altamente disponible. Los servicios no eran redundantes corriendo una sola instancia por servicio lo que provocaba que cualquier fallo relacionado con esa instancia interrumpía el servicio.
El hardware no era redundante por lo que un fallo de este interrumpía varios servicios de forma simultanea.
La infraestructura no era redundante ya que se contaba con una sola fuente eléctrica, la de la compañía eléctrica. No se disponía de un generador de respaldo y solo se contaba con los minutos que brindaban las fuentes de potencia ininterrumpibles (UPS, por sus siglas en inglés). La climatización la brindaba un solo equipo por lo que un fallo de este provocaba la interrupción de todo el centro.
El plan de contingencias no estaba automatizado por lo que ante la ocurrencia de un fallo debía invertirse gran cantidad de trabajo por parte del operador.
Varias de las actividades que se efectúan en el centro requieren de la disponibilidad todo el tiempo, por lo que no se puede clasificar como un centro altamente disponible.
1.5.4 Seguridad
La seguridad de la información significa proteger esta y los sistemas informáticos del acceso, uso, publicación, interrupción, modificación, inspección, grabación o destrucción no autorizada. Está relacionada con la confidencialidad, integridad y disponibilidad de la información. De esta manera interviene también en la disponibilidad y correcto funcionamiento de los sistemas de computadoras.
En particular no existen métodos científicos comúnmente aceptados para la medición de la seguridad, en cambio se implementan políticas y se refuerzan los puntos que se consideren más importantes.
En un CPD se deben proteger los equipos y los datos de posibles accesos de usuarios no autorizados. Físicamente se logra mediante el aseguramiento con paredes, puertas y demás que sean seguras. Los mecanismos de acceso son un aspecto sensible ya que son un punto de ataque muy común. A su vez, no existe seguridad absoluta por lo que se hacen necesario equipos de monitoreo, tales como alarmas, cámaras de seguridad, etc., que registren y controlen las actividades que ocurren en el centro.
A nivel lógico el acceso se protege mediante la aplicación de reglas de acceso, las cuales definen la compartimentación de los recursos; los cortafuegos son otras herramientas que buscan la implementación de estas políticas. El cifrado de los datos sensibles es una técnica que evita la filtración de los datos hacia
elementos no deseados y desestimula el robo de la información. A su vez las herramientas de detección de intrusos descubren a los individuos que realizan operaciones indeseadas en el centro.
La integridad de los datos es otro aspecto muy importante a tener en cuenta. La replicación local protege contra fallos, siendo posible la continuidad del negocio ante la interrupción de disco. La replicación remota protege los datos del centro ante una catástrofe, donde todos los medios se perdieran irremediablemente. La firma de los datos evita el cambio silencioso de estos de forma que se evita el sabotaje de los mismos.
El centro de datos de la Sede 44 no cumplía con los parámetros básicos de seguridad, siendo numerosos los fallos detectados en auditorías de este tipo. El aseguramiento físico era muy pobre al existir una puerta cortina de plástico resguardando la entrada. El acceso se controlaba mediante un sistema de candado muy simple y vulnerable.
El tráfico de red de todo tipo estaba mezclado, al no existir una segmentación apropiada de la red, lo que permitía a un usuario malintencionado impersonar cualquiera de los servicios del centro. Las aplicaciones corrían sin aislamiento, sobre el mismo ambiente, provocando que una brecha en una de ellas afectara a todas las que compartían ese ambiente. El acceso a las interfaces de administración se hacía mediante el vulnerable par de usuario y contraseña, disminuyendo la protección de autenticación.
La existencia de estas deficiencias en el CPD provoca que no se pueda calificar como un diseño seguro.
1.6 Estado inicial del equipamiento y las aplicaciones en el CPD de la Sede 44.
Como punto de partida se hizo un estudio del estado de los servicios y aplicaciones presentes en el CPD de la sede 44 así como del software y el hardware utilizado para soportar estos.
El hardware con que se contaba incluía tres computadoras, dos dispositivos de almacenamiento en red (NAS, por sus siglas en inglés) y un switch Fast Ethernet los cuales se detallan a continuación.
1.6.1 Servidores
Las computadoras con que se contaban eran:
• Máquina (motherboard) ECS 945GZT-M con un procesador Intel Pentium D @3.2GHz y 768MB de RAM DDR2 llamada Ebox.
• Máquina Intel Desktop DG33BU con un procesador Intel Core 2 Duo E6550 (@2.33GHz) y 2GB de RAM llamada Intel
• Servidor profesional HP ProLiant ML150 G5 (sin modificar: procesador Intel Xeon E5205 @1.86 y 1GB de RAM RDDR2) llamado HP.
El servidor Ebox corría la distribución de Linux llamada eBox, que está basada en Ubuntu 8.04 LTS. Presenta una interfaz web de configuración extensible modularmente, siendo un equivalente en Linux al Windows Server 2003 Standard. A través de los módulos se pueden habilitar servicios, luego configurables a través de la interfaz, parecido funcionalmente al asistente “Configurar mi Servidor” de Windows Server 2003. Este servidor brindaba los servicios de DNS, correo electrónico, proxy HTTP, web y servidor de ficheros.
El servidor Intel contaba con una versión de Windows Server 2003 sobre la que corría un servidor de directorio activo de Windows. Además corría un servidor de Ábaco, software contable utilizado por la corporación, el cual también requiere de un gestor de base de datos Firebird que corría localmente. Se encontraba también un servidor Microsoft SQL Server 2005 para desarrollo, utilizado por programadores en el centro.
El servidor HP no se encontraba realizando ninguna función. En este se encontraban el servicio de correo electrónico y proxy HTTP antes de configurarse el Ebox.
En la defectación realizada sobre los recursos de procesamiento se registraron los siguientes problemas:
• El sistema era poco seguro ya que los servicios, estuvieran relacionados o no, se encontraban instalados y operando sobre un mismo entorno, sin aislamiento mayor que el que le imponía el SO a los procesos y usuarios. No se diferenciaban los servicios con vista pública de los servicios internos (privados), constituyendo una gran brecha de seguridad y amenaza de ataque. Una brecha en alguno de los servicios comprometía
a los demás servicios que compartían ese entorno.
• Al existir una tendencia a la centralización de los servicios en un mismo entorno, existía poco balance en la carga de los servidores. Unos servidores se encontraban sobrecargados, mientras otros tenían muy poca carga.
• Los sistemas estaban instalados directamente sobre hardware heterogéneo, lo que dificultaba cualquier tipo de redistribución de los servicios, siendo una solución poco flexible. La sustitución o mejora de los servidores conllevaba volver a instalar o configurar múltiples servicios.
• Existía poca disponibilidad de los servicios ya que cada servicio instalado era único y no se encontraban implementadas técnicas para redundar tanto la información como los servicios. Cada servicio era un punto simple de fallo: el mantenimiento o fallo de algún tipo impactaba directamente en el servicio; no existían mecanismos de recuperación del servicio de forma automática.
• Los tiempos de recuperación ante fallos de hardware solían ser elevados pues había que partir desde la instalación del sistema hasta la configuración de cada uno de los servicios. Además no se contaba con un manual o salva de configuración.
1.6.2 Almacenamiento
En la arquitectura de almacenamiento se contaba con discos duros conectados directamente, a través del bus Conexión Serie de Dispositivo Avanzado (SATA, por sus siglas en inglés), a las máquinas (equipos de procesamiento). Además existían dos dispositivos de almacenamiento en red (NAS, por sus siglas en inglés) Maxtor Shared Storage II de 500GB, los cuales solo exportaban carpetas compartidas CIFS y debían encenderse de forma manual ante un fallo eléctrico. Los servidores contaban cada uno con un disco Seagate SATA de 160GB.
El almacenamiento de los datos de programas y usuarios se hacía local y existía un complejo esquema de salvas, el cual se realizaba de forma manual y era poco eficiente. Cada usuario debía copiar/actualizar sus datos importantes
en el servidor de ficheros (Ebox) y el administrador debía hacer una copia de esos datos y otros, puntuales, tales como las bases de datos, y enviarla a la sede 200 donde se almacenaban. Este proceso se realizaba una vez al mes por lo que los datos durante el mes estaban propensos a perderse ante un fallo del almacenamiento.
Los datos de otros servicios, como los correos, los datos del dominio, etc., no se duplicaban nunca por lo que ante un fallo de almacenamiento se perderían. Los NAS se utilizaban para guardar los datos de la sede 200.
1.6.3 Red
La red, consistía en una sola red Ethernet que poseía una topología de árbol. Se contaba con un switch Netgear JFS516 (Fast Ethernet de 16 puertos) en el centro de datos (en el mezanine), el cual interconectaba los servidores, un enlace al piso superior (fuerza de trabajo), un enlace óptico al 3er piso (departamento de informática) a través de un conversor de medios Allied Telesyn AT-MC101XL, otro enlace óptico a la otra casa a través de otro conversor Allied Telesyn AT-MC101XL, un enlace hacia Internet a través de un modem/encaminador Huawei Quidway y otro enlace hacia la red corporativa a través de un modem/encaminador Huawei SmartAX MT882. Un esquema
Figura 1.4: Esquema de red original Sede 44
simplificado se puede apreciar en la figura 1.4.
La red IP coincidía exactamente con la red Ethernet al no existir aislamiento de tráfico ninguno. No se brindaba ningún tipo de Calidad de Servicio (QoS, por sus siglas en inglés) ya que no se distinguían los diferentes tipos de tráfico.
Era perfectamente posible para un usuario en cualquier punto de la red utilizar una de las direcciones públicas contratadas por el centro ya que no se encontraban separadas las redes pública y privada. Era posible así también suplantar la identidad del servidor de correo o el proxy HTTP (de cualquiera, en general), habilitando la capacidad de recolectar información privada de los usuarios.
El uso de los recursos influía en todos los puntos de la red, siendo posible por ejemplo que tráfico P2P, como el acceso a un directorio compartido por un usuario por parte de otro, imposibilitara la transmisión de correo. Así mismo un usuario mal intencionado podía desplegar un ataque smurf o fraggle que provocaría radiación de difusión que podría llegar a una tormenta de difusión.
1.6.4 Gestión
Las configuraciones se hacían de forma manual, siendo el operador del CPD el ejecutor. No existían copias de la configuración más que la que estaba en uso, siendo complejo reutilizar las configuraciones en muchos casos y recuperarse ante los fallos.
Los cambios se efectuaban igual de forma manual por parte del operador. No existía un repositorio con los cambios ya que estos solo se registraban en la memoria del operador.
El desempeño se medía por apreciación al no existir mecanismos para obtener tales métricas. De igual forma no se contabilizaba el uso de ningún servicio de forma que no se tenía referencia de su utilización.
Los fallos se resolvían de forma puntual y eventual. No existía metodología para la resolución ni constancia alguna de la ocurrencia en el pasado (excepto en la memoria del operador).
Existía un manual de seguridad de la empresa donde se encontraban
planteadas las políticas a seguir y medidas a tomar. La Dirección de Informática confeccionaba el documento y lo mantenía actualizado. No obstante, no existían medios para la detección de intrusos más que la simple inspección.
1.7 Presupuesto para la reestructuración
Para la reestructuración se cuenta con:
• El hardware existente inicialmente.
• Algunos recursos en especies, los cuales formaron parte de compras anteriores y están enfocados a máquinas de escritorio (discos duros, memorias DDR2, placas madres, microprocesadores).
• Un modesto monto de dinero para adquirir equipamiento de conectividad ascendiente a 2000 CUC.
La empresa tiene personal que se puede ocupar de resolver los problemas en la infraestructura como la seguridad física y la climatización.
No se cuenta con respaldo eléctrico de larga duración (generadores diésel) y es poco probable que se ejecute una inversión en ese sentido.
1.8 Conclusiones
La empresa se encuentra potenciando el uso de los modernos sistemas informáticos y de comunicaciones para lo cual requiere de una infraestructura tecnológica adecuada. Se requiere disponer de una infraestructura confiable que brinde los parámetros necesarios para esta sede.
Las condiciones originales unidas a problemas en el diseño provocaban que el CPD no fuera capaz de brindar los niveles de trabajo necesarios para asumir responsablemente dichas funciones.
Para que el CPD de la Sede 44 pueda soportar este nuevo volumen de carga y responsabilidad se hace imprescindible que cumpla los parámetros básicos de funcionamiento. Esto, unido a la incapacidad del diseño original, sugiere su reestructuración de acuerdo a los principios modernos de diseño e implementación. Se cuenta con los recursos necesarios para llevar a la práctica un centro con semejantes prestaciones.
Capítulo 2 : Tendencias y tecnologías actuales
2.1 Introducción
El CPD es un sistema complejo donde se realizan un gran número de funciones, las cuales deben ser tomadas en cuenta en el proceso de diseño. Existen estudios acerca del diseño de CPDs, donde se analizan muchos aspectos técnicos a valorar, que aunque están enfocados a grandes centros, su filosofía es extrapolable a centros de cualquier tamaño.
Existen muchas tecnologías posibles a utilizar en la implementación de un CPD. En general se deben analizar la disposición de la potencia de procesamiento, la distribución del almacenamiento, el diseño e implementación de la red de datos y los aspectos de infraestructura.
Este capítulo se enfoca en el estudio del estado del arte y la selección de la tecnología a utilizar en el diseño.
2.2 Procesamiento
Una de las funcionalidades del CPD consiste en brindar la capacidad de procesamiento que requieren los servicios y tareas que soporta. Dicha capacidad se diseña atendiendo a la necesidad de grandes picos de procesamiento, alta disponibilidad o gran seguridad y muchas veces es una combinación de estas.
A partir de esta premisa existen soluciones tecnológicas que se han ido desarrollando paulatinamente. Estas soluciones se ven sin cambios en pocos casos, generalmente en ambientes especializados donde hay un requerimiento crucial y el resto tienen muy poca importancia en comparación. Centros como estos pueden ser grandes CPDs en universidades o mega corporaciones, muchas veces dedicados a una actividad en específico. Lo más común es encontrarlas mezcladas, en todo caso, son los bloques básicos para el resto de las soluciones por lo que un análisis de se hace necesario.
2.2.1 Servidores discretos
Esta es tal vez la solución aplicada a los CPDs más conocida y extendida. Consiste en dedicar una máquina servidor a cada aplicación que se corre en el
centro, lo que hace que muchos CPDs se destaquen por su gran extensión.
No se requiere software especializado ni configuración especial alguna, las aplicaciones simplemente se despliegan igual que se encontraban en el entorno de desarrollo. No se necesitan herramientas especiales tampoco, pues el proceso es igual que en cualquier máquina lo que en este caso solo se dedica a una aplicación.
Es poco flexible estando el software instalado directamente sobre el hardware y no utilizar ningún tipo de virtualización.
Los recursos de hardware que posee cada máquina son capaces de acomodar cierta carga de trabajo, por encima de ese límite no es capaz de manejar más trabajo. Para cargas tan grandes queda en manos de la aplicación resolver el problema de la escalabilidad. Esto lo convierte en un diseño poco escalable.
Lograr alta disponibilidad en esta configuración es muy difícil sin mezclarlo con otro tipo de arquitectura. Las soluciones más conocidas que surgieron para esta distribución fueron las implementadas a nivel de aplicación, donde el programa es el encargado de manejar los fallos y redireccionar el tráfico. Por esto no se puede clasificar como altamente disponible.
La instalación de una sola aplicación por servidor logra un aislamiento de los ambientes, porque cada aplicación está en un ambiente separado. Una brecha de seguridad en una aplicación no es capaz de comprometer otra aplicación ya que en cada servidor hay solo una. Es por eso que se puede calificar como un diseño seguro.
Por otro lado, el aislamiento genera mucho trabajo de administración pues por cada aplicación se debe atender un hardware con sus interrupciones, sistemas operativos y sus actualizaciones, monitorear las herramientas de seguridad (cortafuegos, antivirus, etc.) y la aplicación en sí. En general al escalar un sistema de este tipo aumenta la complejidad y con ello los costos de administración asociados.
El sobredimensionamiento provocado por el aislamiento conlleva la utilización poco óptima de los recursos de hardware, subutilizandolo y encareciendo la infraestructura de IT. Existen pocos casos, en comparación, donde una máquina es perfecta para la aplicación, por lo que la baja eficiencia en el uso de los recursos es una característica inherente a este diseño.
Una forma de combatir esto fue unir varias aplicaciones en una misma máquina lo cual aumenta su utilización, pero a la vez niega el principal logro de esta arquitectura que es el aislamiento.
Un ejemplo práctico de esta arquitectura lo constituye el centro de datos del Centro de Estudios de Ingeniería y Sistemas (CEIS) en la CUJAE, donde cada servicio cuenta con hardware dedicado. Un total de 13 máquinas “servidores” brindan la plataforma necesaria para el trabajo.
2.2.2 Clúster de alta disponibilidad
Esta arquitectura se ideó con la disponibilidad como principio fundamental y es básicamente la extensión de los servidores discretos. La idea es evitar los puntos simples de fallo, los cuales son puntos en la arquitectura que al fallar provocan que el servicio deje de funcionar. Partiendo de tener una máquina servidor por cada aplicación se agregan n nuevas máquinas que estarán en espera de un fallo, en cuyo caso entrarán a funcionar en el rol de la fallida.
Es utilizada principalmente por centros críticos, los cuales basan su funcionamiento en la disponibilidad. Fue potenciada originalmente por la rama de las telecomunicaciones donde la disponibilidad es un aspecto crucial. Por sus características los costos suelen ser altos por lo que solo se implementa en las aplicaciones que lo requieran[1].
Para que esta distribución funcione de forma óptima se debe contar con algún tipo de almacenamiento compartido, esto asegura que al fallar una máquina los datos permanezcan accesibles y puedan ser utilizados por la que ocupará su lugar.
Es poco flexible al igual que los servidores discretos al estar el software corriendo directamente sobre el hardware. El almacenamiento es más flexible, al estar virtualizado, ya que debe accederse desde varios miembros del clúster.
Escala igual que los servidores discretos de forma que una aplicación no es capaz de manejar cargas mayores que el hardware que la sostiene.
Una aplicación es capaz de soportar tantos fallos como n máquinas redundantes tenga. Como se pensó en la disponibilidad desde un principio la arquitectura evita los puntos simples de fallo (dobles, triples... en dependencia de n), por lo que en ambientes donde la continuidad del negocio es lo
primordial, esta es sin dudas la mejor solución.
Se mantienen aisladas las aplicaciones, cada una corriendo en su hardware dedicado. Un ataque de negación de servicio (DoS, por sus siglas en inglés) a los efectos del clúster representa una interrupción por lo que se realiza la migración de los servicios hacia una de las máquinas de respaldo, en caso de persistir el ataque provocaría que el clúster oscile, transfiriendo el servicio entre varios nodos.
Este esquema permite que los nodos entren y salgan de servicio de forma silenciosa y simple (de acuerdo al hardware disponible). El mantenimiento o la mejora de las máquinas no repercuten directamente sobre el servicio y no se necesita ser exquisito en cuanto al horario a tomar para ello. Se tienen n máquinas adicionales por aplicación para administrar, por lo que los costos suelen ser bastante elevados.
El sobredimensionamiento se dispara a medida que n es mayor. Por sus características este diseño es muy poco eficiente en cuanto al aprovechamiento de los recursos.
2.2.3 Clúster de balanceo de carga
Esta solución se enfoca en la escalabilidad y funciona creando un director de servicio y teniendo un grupo de servidores de aplicaciones. Este director (conocido técnicamente como balanceador de carga) no corre instancia de aplicación alguna sino que distribuye la carga de trabajo entre los servidores reales que ejecutan la aplicación.
Esta solución es muy popular en las aplicaciones que manejan grandes volúmenes de tráfico como SourceForge.net o Linux.com.
En algunas configuraciones de esta solución se requiere cierto software especial para lograr que el sistema funcione, aunque principalmente el rol del balanceador solo requiere trabajo de red (túneles, traducción de direcciones de red -NAT por sus siglas en inglés etc.). Uno de los problemas consiste en definir la carga de un nodo, su medición y distribución. Hay configuraciones donde el director utiliza los datos de las conexiones para realizar el balanceo, tales como la solicitudes entrantes, la demora de las respuestas, etc. En otros casos cada servidor real debe correr un programa (midleware) que se comunique con el
balanceador y le notifique acerca de su carga de trabajo lo cual es una medida más precisa de la carga de trabajo y en estos casos es más complicado mezclar sistemas operativos diferentes aunque posible.
Es un diseño flexible donde el procesamiento y el almacenamiento están virtualizados. El nodo director trata los servidores reales como unidades de procesamiento de forma que tiene la posibilidad de enfocar la nueva carga en cualquiera de estos. El almacenamiento correspondiente a una aplicación es accesible a la vez por todos los servidores reales que la corran.
Es escalable ya que una aplicación es capaz de manejar cargas mayores que el hardware más potente y hasta la suma de las capacidades de todos los servidores reales que la ejecutan.
Al existir varias instancias de la misma aplicación ejecutándose en el clúster el sistema es capaz de tolerar el fallo de nodos hasta que quede solo 1 corriéndola. Por esto se puede considerar un diseño altamente disponible.
Este caso aumenta aún más el aislamiento de las aplicaciones ya que no solo se tiene una aplicación por nodo sino que se tienen varias instancias de la aplicación corriendo en hardware diferente. En caso de que una de esas instancias sea comprometida no compromete siquiera la aplicación completa. El clúster ve los ataques DoS como carga adicional y es capaz de soportarlos hasta que se agoten los recursos destinados a la aplicación.
Incurre en grandes gastos de administración asociados a la complejidad del sistema ya que hay varias máquinas por cada aplicación. Es posible hacer trabajos de mantenimiento en las máquinas sin que esto constituya una interrupción del servicio.
Esta solución es poco eficiente en el uso del hardware con bajas cargas a diferencia de situaciones de mucha actividad. A medida que halla más carga será mayor la eficiencia.
2.2.4 Virtualización
La virtualización es una de las principales soluciones aplicadas, de alguna forma, en las empresas actuales[2]. Consiste en la distribución lógica de los recursos de cómputo, con lo cual se crean instancias con un subconjunto de los recursos de la configuración base. Existen varios tipos de virtualización, los
cuales se pueden enumerar como:
• La virtualización a nivel de sistema operativo, que se apoya en un núcleo capaz de crear diferentes espacios de memoria, con lo que puede mostrar a cada instancia virtualizada un entorno diferente. La carga adicional es muy pequeña y el costo administrativo también (solo un núcleo corriendo a la vez). Tiene la desventaja de no poder mezclar varios tipos de sistemas operativos, básicamente es capaz de mezclar todos los sistemas operativos que utilicen el mismo núcleo, pero solo estos. Las implementaciones comunes incluyen el núcleo de Linux y FreeBSD, no siendo posible este tipo de virtualización para entornos Windows.
• La virtualización completa consiste en virtualizar todo el hardware de una máquina de forma que un sistema operativo huésped (guest) lo utilice como hardware base. El principal problema consiste en que la arquitectura x86 no cumple con los parámetros necesarios para ser virtualizada de esta forma, por lo que se requieren mecanismos para lograrlo. A grandes rasgos lo que se realiza es interceptar las instrucciones problemáticas y emular el procesador, acción muy costosa que provoca carga adicional. En esta variante es posible correr los más diversos sistemas operativos simultáneamente, siempre y cuando soporten la arquitectura básica. A su vez provoca más carga que las demás ya que el aislamiento total requiere la ejecución al unísono de varios núcleos y demonios básicos por lo que el aumento de requerimientos es lineal con relación al aumento de máquinas virtuales.
• La virtualización completa asistida por hardware, hace uso de las extensiones de virtualización (Intel VT-x y AMD-V). Lleva la implementación al hardware y elimina la emulación del procesador, lo que aumenta la velocidad al eliminar este procesamiento de las colas del microprocesador.
• La paravirtualización es prácticamente una virtualización completa, que no virtualiza las instrucciones problemáticas por lo que el núcleo huésped debe estar modificado para operar en estas condiciones y también son necesarios controladores especiales. Con esta variante se evita cierta
carga adicional provocada por la virtualización completa a cambio de disminuir la compatibilidad.
Se puede considerar como la evolución de los servidores discretos por lo que suele emplearse en centros de datos de propósito general, los cuales tienen un porcentaje considerable en el mundo.
Cualquiera de las configuraciones, de ser aplicables, brinda una gran flexibilidad al ser posible mover aplicaciones completas entre el hardware disponible ya que suelen ser ficheros que se copian y luego se ejecutan. Con el empaquetamiento de las aplicaciones, ya no se necesitan contemplar todos los posibles ambientes sino que se empaquetan ambientes completos, evitando mucho trabajo de compatibilidad y chequeo de errores.
Por otra parte no escala al tener como máxima capacidad algo menos de la que brinda el hardware subyacente. En el otro sentido es capaz de manejar cargas más pequeñas sin incurrir en la ineficiencia al consolidar aplicaciones sobre el mismo hardware.
El problema de la disponibilidad se vuelve más grave al existir un punto de fallo que afecta a varias aplicaciones a la vez.
La seguridad es prácticamente igual que en los servidores discretos ya que a los efectos de la aplicación se encuentra en un ambiente dedicado y totalmente aislado. Una brecha dentro de una máquina virtual, en un sistema bien configurado, no afecta las otras máquinas. Un problema conocido en las implementaciones actuales lo constituye el manejo de los recursos, el hipervisor y/o sistema operativo debe ser lo suficientemente capaz de manejar los recursos compartidos y evitar que las máquinas abusen del hardware, lo cual afecta directamente a las otras.
La capa de abstracción incluye cierta carga extra en el procesamiento, por lo que se requiere un poco más de potencia que si se implementara directamente sobre hardware real.
Se logra la consolidación del centro de datos (menos equipos) que disminuye el costo de funcionamiento. Se ha demostrado un aumento de la utilización del hardware de alrededor del 35% antes de virtualizar a más del 70% luego de la virtualización. En grandes empresas la consolidación aporta directamente al aumento de la capacidad de los grandes CPDs y en las pequeñas se potencia
más la disminución de los costos.
Un ejemplo práctico lo constituye el nodo del Ministerio de la Informática y las Comunicaciones donde todos los servicios se encuentran virtualizados, utilizando virtualización completa, mediante la plataforma VMware vSphere.
2.2.5 Supercomputadora
Son máquinas muy grandes, con cientos de procesadores trabajando en paralelo y buses de interconexión de alta velocidad. Una variante más asequible lo constituyen los clústers de alta velocidad de procesamiento donde estos procesadores se encuentran en máquinas comunes que se interconectan por un bus externo de alta velocidad y baja latencia. Fueron las primeras computadoras enfocadas a las grandes necesidades, pioneras de los que se conoce como supercomputing.
Son utilizadas generalmente por centros de investigación para la resolución de grandes problemas y simulaciones. No acostumbran a usarse para brindar servicios en general, entre otros, por su gran costo.
El software que corre en estos sistemas suele ser diseñado expresamente para estos, ya que se requiere tomar medidas durante el diseño y programación para explotar el gran paralelismo. Se utiliza un middleware, como la interfaz de paso de mensajes (MPI) o la máquina virtual paralela (PVM) para lograr el intercambio entre procesadores.
Son sistemas ciertamente flexibles con grandes capacidades de hardware siendo muy fácil la movilidad de las aplicaciones entre los procesadores por parte del planificador.
Escala en extremo para ser capaz de manejar los grandes volúmenes de instrucciones y datos que procesan.
Producto del gran paralelismo son altamente disponibles al existir grandes cantidades de hardware estrechamente interconectado.
Son sistemas poco seguros, siendo la separación que impone el sistema operativo la única que existe entre las aplicaciones.
Son sistemas muy complejos de gestionar por la especificidad de cada uno. Se requiere un estudio del complejo hardware para ser capaz de administrarlo.
A mediados de los años '80 apareció una nueva clase llamada mini supercomputadora que sustituía gran parte de los microprocesadores por procesadores vectoriales y durante los '90 el desarrollo de los microprocesadores las hizo irrelevantes. En los últimos años se retomó el concepto y muchas veces se añaden coprocesadores (normalmente GPGPUs) a las supercomputadoras para lograr aún más potencia.
2.2.6 Mainframe
Parecidas a las supercomputadoras, compartiendo mucho de su historia, pero diseñadas para uso general. Centradas en las necesidades comunes y no en la gran potencia de procesamiento.
El hardware es muy parecido al de las supercomputadoras, con menos unidades de procesamiento, más capacidad de entrada/salida, redundancia, chequeo y corrección de errores.
Son utilizadas para sostener la operaciones críticas en las grandes corporaciones.
Son sistemas muy flexibles que pueden correr varios sistemas operativos, generalmente variantes de Unix y permiten máquinas virtuales a varios niveles.
Son máquinas diseñadas para escalar siendo posible soportar grandes cargas de trabajo.
Implementan continuidad de negocio ya que generalmente son utilizadas para aplicaciones cruciales donde el tiempo fuera de servicio es muy costoso o catastrófico.
Muy seguras corriendo las aplicaciones en máquinas virtuales e implementando varias tecnologías de integridad de datos.
2.2.7 Grid Computing
A grandes rasgos consiste en llevar los principios del clúster de alta potencia de procesamiento a gran escala.
Las grids están compuestas por máquinas no dedicadas, heterogéneas y geográficamente dispersas, interconectadas por redes LANs, WANs o la
Internet.
Se utiliza el mismo middleware del clúster, generalmente PVM, para el procesamiento paralelo.
Gran flexibilidad ya que trata los procesadores están totalmente virtualizados de forma que el trabajo se puede redistribuir entre ellos.
Esta pensado para escalar al límite, al disminuir la necesidad de bajas latencias y altas velocidades es capaz de crear arreglos increíblemente grandes.
Dado su gran tamaño y la virtualización son capaces de brindar altos niveles de disponibilidad.
Con este acercamiento aparecen problemas de seguridad. Las relaciones de confianza que existan entre el controlador y el miembro determinarán la seguridad que posean los datos intercambiados. Entre los problemas que pueden aparecer están el abuso del controlador de los recursos del usuario o de la existencia de miembros malintencionados que alteren los resultados.
Son sistemas muy grandes y difíciles de gestionar por lo que se implementan métodos automáticos para esto.
Una variante muy utilizada es CPU-scavenging, cycle-scavenging, cycle stealing o shared computing que consiste en crear una grid de recursos en desuso.
2.3 Almacenamiento
El almacenamiento es otro de los servicios que debe ofrecer un CPD, que debido a la creciente informatización de los procesos en las empresas se ha transformado en una actividad muy sensible.
A grandes rasgos se debe respaldar la información y los métodos de acceso a la misma, de forma que un fallo no implique la inaccesibilidad a la información. Medidas deben tomarse además ante un evento de catástrofe, donde todos los medios locales se pierden irremediablemente para lo que una copia lo más actualizada posible se hace necesaria.
2.3.1 Redundancia local de datos
El término muy conocido RAID, es un acrónimo para Arreglo Redundante de
Discos Independientes. Consiste en una tecnología para aumentar la fiabilidad a través de la redundancia y/o las velocidades de transferencia a través sel acceso paralelo. Utiliza la combinación de varios discos en una unidad lógica, donde los datos se distribuyen en una de las varias formas llamadas niveles RAID. Es la técnica de redundancia local por excelencia utilizada en el mundo.
Existen niveles estandarizados que emplean bandas, reflejos, o paridad. Se nombran “RAID”, seguidos por un número de una cifra, así tenemos “RAID 1”, “RAID 2”, etc. Estos niveles requieren del uso de medios de igual tamaño, en caso de utilizar discos de diferente capacidad, el tamaño del disco más pequeño será lo que se utilizará de todos los miembros. Los niveles RAID estándares hasta el momento incluyen:
• RAID 0, que consiste en la creación de bandas de bloques; los bloques se van escribiendo secuencialmente en cada miembro del arreglo, de forma que para leer o escribir una secuencia de los mismos se accede a cada disco de forma secuencial. Con esto se mejoran las velocidades y se construye un solo espacio de la suma de todos los dispositivos. En detrimento aumenta la razón de fallo del arreglo y el fallo de un disco provoca que todos los datos se pierdan. El tamaño mínimo del arreglo es de 2 discos.
• RAID 1 utiliza discos como reflejos de otro, una lectura se puede realizar de todos los dispositivos (por lo que se puede leer de forma secuencial de todos a la vez) y la escritura debe hacerse hacia todos los dispositivos, brindando tolerancia a fallos y aumentando la velocidad de lectura. En sistemas operativos bien configurados no se ve afectación a la velocidad de escritura (que es igual a la del disco más lento). Tolera la pérdida de discos hasta que quede 1. Solo se puede utilizar el espacio de un disco físico ya que el resto está reservado para mantener copias. El tamaño mínimo del arreglo es de 2 discos.
• RAID 2, RAID 3 y RAID 4 son arreglos de al menos 3 discos con paridad dedicada y bandas a diferentes niveles (bit, byte y bloque respectivamente). Se reparte el espacio en 2 discos y el 3ro se dedica a la paridad. La velocidad de lectura mejora al igual que en el nivel 0 y la velocidad de escritura está afectada por el cálculo y escritura de la
información de paridad, siendo el 3er disco un cuello de botella. No son configuraciones usadas o soportadas en general.
• RAID 5 es muy parecido al RAID 4 pero la información de paridad se almacena junto a los datos, de forma que se elimina el cuello de botella del disco de paridad. El tamaño mínimo del arreglo es de 3 discos y tolera el fallo de 1. El espacio equivalente a un disco está reservado para información de paridad, aunque distribuido entre todos los miembros. La velocidad de lectura puede afectarse por la imposibilidad de hacer lecturas secuenciales al encontrarse información de paridad intercalada con los datos y la velocidad de escritura se ve afectada por el cálculo y escritura de la paridad en cada acceso.
• RAID 6 consiste en un RAID 5 extendido que utiliza 2 copias de la información de paridad, siendo capaz de tolerar la pérdida de 2 discos. El tamaño mínimo del arreglo es de 4 discos. Se utiliza para discos grandes y activos donde los tiempos de reconstrucción del arreglo suelen ser grandes, quedando el sistema vulnerable a otro fallo por demasiado tiempo.
Es posible anidar estos niveles (conocido también como RAID híbrido), práctica bastante común, y se utilizan entonces números de más de una cifra para denominarlos o se utiliza un signo “+” entre ellos, el orden de los dígitos es el orden es que es construido el arreglo y no es común encontrar más de dos niveles.
Entre los más utilizados están el RAID 0+1 que consiste en un espejo de bandas, lo cual brinda mayor velocidad, pero solo es tolerante al fallo de 1 disco, o más mientras sean de la misma banda. La mitad del espacio está reservada como reflejo.
El RAID 10 por otro lado hace bandas de espejos, con lo cual se aumenta la velocidad y tolera el fallo de 1 disco, o más mientras los discos no pertenezcan al mismo espejo. Igualmente la mitad del espacio está reservada como reflejo.
El RAID 51 es un espejo de RAID 5, con lo cual se le brinda seguridad extra a los datos del arreglo. Aquí más de la mitad del espacio está reservada para reflejo y paridad.
Existen niveles no estándares, generalmente propietarios, los cuales posibilitan
configuraciones especiales. Estos niveles son poco soportados en comparación con los estándares por lo que es muy posible incurrir en el encierro de proveedor[3]; es por esto que se deben analizar las necesidades y utilizarlo solo cuando no exista otra posible solución.
La implementación de estos niveles puede ser a nivel de hardware o de software. Las implementaciones por software, sobre todo las que calculan paridad, hacen uso de los recursos del procesador para realizar las operaciones, disminuyendo el rendimiento del sistema. Las de hardware, suelen ser difíciles de actualizar y por lo general no son compatibles entre sí, por lo que es muy frecuente caer en el encierro de proveedor. Inclusive, productos de un mismo fabricante pueden tener implementaciones diferentes haciéndolos incompatibles entre sí. Para los niveles 0 y 1, donde no se producen cálculos, las implementaciones por software suelen ser más ventajosas. Algunos administradores de volúmenes y sistemas de archivos también implementan algunos de estos niveles.
En Linux la implementación por excelencia suele ser el controlador md, que soporta los niveles 0, 1, 4, 5, 6 y todas las anidaciones, siendo parte de muchas de las distribuciones. En Windows se utilizan los discos dinámicos que son capaces de hacer arreglos de tipo 0, 1 y 5.
Otra implementación a destacar es DRBD, un módulo para el núcleo de Linux que implementa RAID 1 sobre un enlace de red. En este caso uno de los discos se encuentra conectado directamente a un bus local (Conexión Serie de Dispositivo Avanzado -PATA, por sus siglas en inglés-, SATA, Interfaz de Sistema para Pequeñas Computadoras -SCSI, por sus siglas en inglés-, etc.) y el otro está en otro nodo de la red. La réplica se realiza mediante mensajes a través del enlace, siendo configurable qué tan estricto se comportará para la protección de los datos. Este modelo trae un nuevo grupo de problemas al existir tanta distancia (en cuanto a elementos intermedios) entre los dispositivos de almacenamiento. Es capaz de utilizar cualquier dispositivo de bloques como medio de almacenamiento y a su vez provee un dispositivo de bloques virtual.
2.3.2 Volúmenes
Los volúmenes son la herramienta por excelencia para la administración y distribución del espacio de almacenamiento disponible. El funcionamiento básico consiste en el establecimiento de unidades básicas llamadas extensiones (extents).
En el dispositivo de almacenamiento se crean volúmenes físicos que pueden ocupar el disco completo o ser particiones, los cuales contienen un número de extensiones físicas.
Un grupo de volúmenes es una colección de extensiones formada al agregar a este volúmenes físicos, constituyendo un espacio disponible.
Se establecen entonces extensiones lógicas, las cuales generalmente se relacionan uno a uno con las extensiones físicas. Estas se agrupan en volúmenes lógicos, los cuales pueden utilizarse como dispositivos de bloques, creando sistemas de archivos sobre estos o utilizándolo como espacio de intercambio.
Es posible también crear espejos, en los cuales una extensión lógica se relaciona con dos extensiones físicas, preferiblemente en dispositivos diferentes, de forma que la misma información se encuentre en dos dispositivos diferentes, funcionando como RAID1.
Otra funcionalidad se logra cuando se le agrega soporte copiar al escribir (COW, por sus siglas en inglés) a cada extensión lógica, llamados fotografías (snapshots), utilizando una tabla COW donde se almacena la extensión lógica antes que se escriba en esta. El sistema luego puede reconstruir la versión original del volumen lógico superponiendo la tabla sobre el volumen actual.
La compañía Veritas (actualmente Symantec) posee un administrador propietario conocido como Veritas Volume Manager (VVM o VxVM) capaz de funcionar en diferentes versiones de Unix y Windows. El sistema operativo HP-UX trae una versión modificada de este como su administrador de volúmenes.
El Administrador de Volúmenes Lógicos (LVM, por sus siglas en inglés), en la línea 2.6 del núcleo de Linux, está implementado como un mapeador de dispositivos. Es un simple esquema para crear dispositivos de bloques virtuales y mapear su contenido a otro dispositivo de bloques. Los metadatos se
almacenan en la cabecera de todos los volúmenes físicos, por lo que cada volumen físico cuenta con toda la información de su grupo de volúmenes. Las herramientas de administración trabajan en el espacio de usuario y se utilizan para manejar los mapeos y reconstruir su estado a partir de los metadatos en disco.
El Administrador de Discos Lógicos (diskmgmt.msc) es una implementación propietaria desarrollada por Microsoft y Veritas para Windows que fue introducida con el sistema operativo Windows 2000. Este distingue dispositivos de almacenamiento en básicos y dinámicos, estando los primeros poblados de particiones y los segundos de volúmenes. No es posible mezclar particiones y volúmenes dentro de un mismo disco. Los metadatos, en discos que utilizan registro de arranque maestro (MBR, por sus siglas en inglés), se almacenan en un espacio de 1 MiB al final del disco y el resto del disco se convierte en una partición donde se almacenan los volúmenes. En caso de que se utilice tabla de particiones GUID (GPT, por sus siglas en inglés) se crean dos particiones, una que contiene los metadatos y otra que almacena los volúmenes. Es posible convertir discos básicos en lógicos de forma muy sencilla, utilizando el administrador, no siendo un proceso sencillo el inverso. Los discos dinámicos solo son utilizables en versiones posteriores del Windows 2000, excluyendo Windows XP Home Edition y Windows Vista Home (tanto Basic como Premium). Estos discos también habilitan la posibilidad de utilización de RAID por software.
Vinum es el administrador de volúmenes por excelencia de FreeBSD, aunque existen versiones para otras variantes de BSD. Mezcla además RAID por software siendo capaz de soportar esquemas RAID 0, 1 y 5.
2.3.3 Volúmenes compartidosEsta técnica es la base de las redes de almacenamiento (SAN, por sus siglas en inglés) y consiste en alargar la distancia entre el dispositivo de almacenamiento y el consumidor del mismo, así como desacoplarlos.
La solución más simple puede ser ATA sobre Ethernet (AoE, por sus siglas en inglés) la cual es un protocolo de red diseñado para acceder a dispositivos conectados mediante Conexión de Dispositivo Avanzado (ATA, por sus siglas en inglés) tales como PATA o SATA a través de una red Ethernet. Está
estandarizado en un documento de ocho páginas[4], las cuales son suficientes para explicar el encapsulamiento de los mensajes ATA en las tramas Ethernet así como los simples métodos de control que implementa[5].
Otra posibilidad es utilizar comandos SCSI, muy comunes en ambientes de servidores. HyperSCSI es un protocolo de red para enviar y recibir estos comandos sobre una red Ethernet. No tuvo gran aceptación por parte de los proveedores comerciales, entre otras cosas, porque no está estandarizado. Otra posibilidad es iSCSI, que es uno de los estándares más conocidos y generalmente el punto de entrada; consiste básicamente en transmitir comandos SCSI sobre arquitectura de Internet (TCP/IP, por sus siglas en inglés) utilizando las facilidades de la pila (stack) para el manejo del tráfico[6].
Una evolución la constituyó, en su momento, la tecnología Fibre Channel (FC) que empaquetó los comando SCSI en datagramas y definió toda una pila desde capa física hasta red. Fibre Channel sobre TCP/IP (FCIP) es una adaptación de Fibre Channel que utiliza túneles en redes IP para conectar tejidos (fabrics), generalmente utilizada para conectar redes FC mediante una WAN. Diferente es iFCP que extrapola las facilidades de FC a la tecnología IP, sustituyendo las capas desde físico a red por la pila TCP/IP. Fibre Channel sobre Ethernet (FCoE) encapsula las tramas de FC sobre redes Ethernet; sustituye las capas FC0 y FC1 de la pila FC por Ethernet, evitando las caras interfaces FC por las comunes Ethernet a cambio de menos facilidades y confiabilidad.
En comparación, la pila Fibre Channel se diseñó desde el principio con el problema del almacenamiento en mente, de forma que tiene funcionalidades muy específicas de este tipo de actividad. Desde su nacimiento se persiguieron la alta velocidad y las bajas demoras, siendo generalmente tecnología de punta y por consiguiente muy cara.
La utilización de Ethernet para almacenamiento se ha hecho posible en los últimos tiempos dada la evolución de la tecnología, con altas velocidades y menores demoras. No obstante esta se diseñó como una red de propósito general por lo que no provee funcionalidades requeridas por la actividad de almacenamiento, las cuales deben implementarse en capas superiores.
Las soluciones que utilizan las redes TCP/IP son independientes del medio físico, estas por lo general se utilizan para enlaces de gran distancia (donde se
deben atravesar varias redes) y aumentan la cantidad de carga no útil, la latencia y la potencia de procesamiento necesaria. No obstante, la capacidad, rapidez y demoras de la red pueden definirse mediante el diseño de la red subyacente, por lo que no constituye una deficiencia en si. Comparadas con las implementaciones sobre Ethernet sí están en desventaja en cuanto a la potencia necesaria aunque son superiores en cuanto a la complejidad que pueden alcanzar.
2.3.4 Sistemas de archivos de disco compartido
Un problema del almacenamiento compartido lo constituye el sistema de archivos. Los sistemas de archivos tradicionales como Tabla de Asignación de Archivos (FAT, por sus siglas en inglés), Sistema de Archivos Extendido (EXT, por sus siglas en inglés) y Sistemas de Archivos de Nueva Tecnología (NTFS, por sus siglas en inglés) están diseñados para ser accedidos por un solo nodo. Cuando varios nodos tienen acceso a un mismo sistema de archivos aparecen problemas que los tradicionales no enfrentan. La principal solución la constituye el administrador de bloqueo, el cual media el acceso evitando que la información se corrompa.
Dentro de estos sistemas de archivos se pueden diferenciar dos tipos, los asimétricos, donde los datos se escriben directo a la SAN, pero los metadatos se dirigen a un solo nodo; y los simétricos donde cada nodo escribe tanto los datos como los metadatos a la SAN. Estos últimos son de mayor interés para una pequeña empresa ya que necesitan menos “tipos” de nodos (todos los nodos son iguales) por lo que es más sencilla la redundancia.
El Sistema de Archivos de Clúster de Oracle versión 2 (OCFS2, por sus siglas en inglés) es un sistema de archivos de disco compartido desarrollado por la Corporación Oracle y licenciado bajo la Licencia Pública General de GNU (GPL, por sus siglas en inglés), disponible en el núcleo de Linux a partir de la versión 2.6.16. Esta versión incluye las funcionalidades de la Interfaz de Sistema Operativo Portable de Unix (POSIX, por sus siglas en inglés). Utiliza un administrador de bloqueo distribuido propio y simple llamado O2DLM. Tiene como limitaciones que un directorio solo puede tener 32000 subdirectorios y el tamaño máximo del sistema de archivos es 16 TB[7].
Otro sistema de archivos es el Sistema de Archivos Global versión 2 (GFS2, por las siglas en inglés) desarrollado por Red Hat (anteriormente por Sistina Software) y publicados bajo la GPL. Está disponible en el núcleo de Linux a partir de la versión 2.6.19. Presenta varias mejoras en comparación con la versión anterior, GFS, aunque el formato en disco es muy parecido. Utilizan un administrador de bloqueo llamado Administrador de Bloqueo Distribuido (DLM, por sus siglas en inglés). Tiene como limitación que el tamaño máximo del sistema de archivos es de 25 TB[8].
En general ambas soluciones implementan la mayoría de las facilidades de los sistemas de archivos modernos como registro por diario, extensiones, compatibilidad POSIX, etc.
Sistema de Archivos de Máquina Virtual (VMFS, por sus siglas en inglés) es el sistema de archivos de VMware usado en sus productos ESX Server y la suite VMware vSphere. Diseñado para almacenar los ficheros de las máquinas virtuales, el bloqueo se realiza por fichero y crece hasta un tamaño máximo de 64 TB. Está soportado solo por los productos VMware, existiendo un controlador de código abierto que permite acceso de solo lectura (mantenido por Fluid Operations AG).
2.3.5 Almacenamiento integrado
Existen proveedores de almacenamiento que emplean algunas de las tecnologías expuestas y crean dispositivos que son relativamente fáciles de configurar e instalar, disminuyendo el tiempo necesario para la implementación. Dichos dispositivos pueden ser NAS o servidores de almacenamiento que constituyen una SAN.
Otra posibilidad consiste en alquilar el espacio a terceros que se dedican a proveer almacenamiento que cumpla ciertos parámetros, para lo cual utilizan las tecnologías expuestas. Aunque existe demanda para este servicio no ha podido despegar aún por la sensibilidad a las demoras, las cuales aumentan demasiado con la distancia.
2.3.6 Mecanismos para la disponibilidad ante catástrofes
La protección contra catástrofes generalmente sugiere la existencia de un
centro igual, o de una copia íntegra de los datos del centro. Para protegerse, dichas instalaciones deben compartir el ambiente lo menos posible (diferentes regiones geográficas, países, continentes, etc.)[9].
Los enlaces que los unan entonces no serán los más rápidos e inmediatos (comparados con los enlaces dentro del centro), por lo que mantener una copia actualizada puede tornarse imposible. Realizar una transferencia eficiente es la clave para poder mantener actualizado el respaldo.
Una de las soluciones la constituye rsync, una aplicación y protocolo de red que funciona en Unix, Linux y Windows y que sincroniza ficheros y directorios entre dos nodos. Minimiza la transferencia de datos mediante el uso de una codificación delta. Además combina la librería zlib para comprimir los envíos, disminuyendo aún más el volumen de datos y funciona sobre enlaces SSH para una encriptación de la transmisión[10].
Otra posibilidad es la Compresión Diferencial Remota (RDC, por sus siglas en inglés) que es un algoritmo de sincronización cliente-servidor que permite sincronizar el contenido de dos ficheros comunicando solo la diferencia entre ellos. Fue introducido con Windows Server 2003 R2 y se incluye con las versiones posteriores del sistema operativo[11].
2.4 Red
El tercero de los aspectos a considerar lo constituye la red, existen varias tecnologías que pueden ser explotadas en el entorno de un centro de datos para poder lograr los parámetros de calidad requeridos.
Para los enlaces existe la unión de canales, agregación de enlaces, trunking o teaming, siendo todos lo mismo pero con nombres diferentes en cada contexto. Consiste en unir varios enlaces físicos (puertos) en un solo enlace lógico (tronco). El Instituto de Ingenieros Eléctricos y Electrónicos (IEEE, por sus siglas en inglés) definió un estándar para este propósito nombrado 802.1AX (antiguamente 802.3ad) que utiliza tramas especiales para que los extremos negocien y administren el enlace. Con esto se logra redundancia y se protege de fallos físicos, al fallar un puerto solo se pierde el ancho de banda que este aportaba y solo se experimenta desconexión al fallar todos los puertos del tronco. Del lado del servidor se puede utilizar el módulo bonding del núcleo
Linux o tarjetas de red que soporten teaming en Windows.
Los dispositivos de conectividad requieren de la apilación .Consiste en la unión de varios equipos físicos que pasan a constituir un solo equipo lógico, generalmente conmutadores de capa 2 (switches), con la cantidad de puertos igual a la suma de todos los puertos de todos los equipos de la pila. El fallo de uno de los equipos desconecta los puertos que este aporta, el resto permanecen activos. Mezclado con la agregación de puertos, se utiliza al menos un puerto de cada equipo para crear el tronco de forma que al fallar uno no se pierde el enlace (solo se degrada).
En cuanto a la seguridad se puede utilizar el estándar IEEE 802.3q, también conocido como redes virtuales (VLANs, por sus siglas en inglés), que se emplea para diferenciar las redes dentro del mismo medio. Es posible consolidar varias redes sobre un mismo medio físico sin sacrificar la seguridad que la separación brinda y también se optimiza el uso del ancho de banda.
Otro problema lo presentan las puertas de enlaces de las redes; cada red tiene una única puerta de enlace por defecto configurada en sus clientes, convirtiéndose en un punto simple de fallo. Existen protocolos de redundancia de primer salto que resuelven este problema algunos libres y otros propietarios y que son, a saber: Hot Standby Router Protocol (HSRP), Virtual Router Redundancy Protocol (VRRP), Common Address Redundancy Protocol (CARP), Extreme Standby Router Protocol (ESRP) y Gateway Load Balancing Protocol (GLBP); en general funcionan manejando el tráfico de Protocolo de Resolución de Direcciones (ARP, por sus siglas en inglés) para que en cada momento la dirección IP de la puerta de enlace se asocie a un equipo funcional.
2.5 Computación en la Nube y Servidor Privado Virtual
Existe la posibilidad de implementar una nube privada en el centro de datos o utilizar una nube pública y prescindir del centro, conocido como computación en la Nube.
Esta tecnología no plantea nada nuevo, sino que integra muchas de las técnicas ya expuestas y presenta una interfaz de administración y monitoreo muy útil para el administrador. Combina la virtualización completa asistida por hardware con elementos de balance de carga y alta disponibilidad en una
solución integrada y automatizada.
La opción de utilizar la nube pública inclusive disminuye la necesidad de personal de administración.
Otra posibilidad consiste en prescindir de los recursos del centro de datos, comúnmente mediante Servidor Privado Virtual (VPS, por sus siglas en inglés). Así el centro de datos sería lógico y hospedado por un tercero, disminuyendo nuevamente gastos por concepto de administración.
Las soluciones que funcionan como alquiler tienen sus particularidades. Como toda relación con terceros es importante el establecimiento de obligaciones y responsabilidades de la integridad, seguridad y disponibilidad de los datos durante la contratación. Esta arquitectura también sugiere la existencia de un ancho de banda suficiente, seguro y altamente disponible hacia el proveedor de servicio.
2.6 Selección de las tecnologías
A partir de estas técnicas generales, se pueden combinar las que respondan a los intereses de la empresa para formar así una solución a la medida.
Las supercomputadoras y la computación grid se utilizan para problemas de mucha carga y tráfico por lo que para el CPD en cuestión no tienen aplicación, siendo posible descartarlos.
Los mainframes proveen recursos de alta calidad (disponibilidad, detección y corrección de errores, etc.) que una pequeña empresa no puede costear por lo que es posible desestimarlas.
Los servidores discretos demostraron su ineficacia en la solución que existía originalmente por lo que si no existe una situación excepcional se pueden desestimar.
La virtualización viene a resolver el problema de costo del aún pequeño centro de datos, siendo válida inclusive al convertirse en el gran centro de datos, por lo tanto la base de la solución debe girar alrededor de esta. Para resolver su problema de disponibilidad se deben tomar elementos de los clústers de alta disponibilidad, creando un clúster de alta disponibilidad de máquinas virtuales.
Los elementos del clúster de balance de carga no son requisito del CPD ni se
espera que lo sean en un futuro cercano por lo que pueden desestimarse.
2.6.1 Virtualización
Entre los tipos de virtualización tanto la paravirtualización, como la virtualización a nivel de sistema operativo, tienen muy poca aplicación, por la incapacidad de correr como huésped a los sistemas operativos Windows. Las soluciones que utilizan estas tecnologías no se tomarán en cuenta.
Entre las soluciones de virtualización completa, las que requieren virtualización asistida por hardware no son capaces de funcionar sobre hardware común. Está el caso extremo de VMware ESXi que requiere hardware específico ya que solo funciona con ciertas controladoras de almacenamiento y red. Entre las opciones que por este concepto pueden obviarse se encuentran:
• OpenVZ
• FreeBSD Jail
• Xen
• VMware vSphere
• KVM
• Microsoft Hyper-V
Luego las implementaciones disponibles con virtualización implementada por software son VMware Server y Oracle Virtualbox.
VMware Server (antiguamente GSX) es el producto de VMware Inc. destinado a servidores en las pequeñas y medianas empresas. Es gratis y el soporte es comunitario. La comunidad no cuenta con el código fuente por lo que no es capaz de aportar mejoras. Los desarrolladores lo descontinuaron y cesaron toda actividad relacionada con este en junio de 2011.
El VMware Server corre sobre los sistemas operativos Windows y Linux y es capaz de explotar las extensiones de virtualización de Intel VT-x y AMD-V. Tiene diferencias, aunque pocas, entre las versiones Linux y Windows. En la versión de Linux se pueden almacenar las máquinas virtuales en directorios compartidos de Sistema de Archivo de Red (NFS, por sus siglas en inglés) y en la de Windows serían compartidos de Sistema de Archivos de Internet Común
(CIFS, por sus siglas en inglés). Además, la versión de Windows soporta la salva de máquinas virtuales en caliente, mediante el uso del Servicio de Fotografía de Volumen facilidad que no tiene la versión de Linux.
La compañía Innotek G.m.B.h. desarrolló el Virtualbox[12] como software de virtualización de escritorio, utilizando un sistema de negocio de software restringido, con una versión de código abierto y otra propietaria que incluía soporte del Bus Serie Universal (USB, por sus siglas en inglés).
La compañía fue comprada por Sun Microsistems que continuó con el mismo sistema de negocio. Durante el transcurso de la versión 3 se le agregó una interfaz de soporte de Python que permitía la extensión a través de este lenguaje, y en la 3.2 se le agregó una interfaz de servicios web, para permitir la administración remota. Además se agregó la posibilidad de redirigir la entrada/salida de las máquinas virtuales a través de Computación Virtual en Red (VNC, por sus siglas en inglés) para la versión libre y de Protocolo de Escritorio Remoto (RDP, por sus siglas en inglés) para la propietaria. Otra facilidad añadida es la capacidad de importar y exportar máquinas virtuales en Formato de Virtualización Abierto (OVF, por las siglas en inglés) para su migración a o desde otra plataforma (VMware, KVM, etc.).
Sun fue adquirida por Oracle quien es el actual desarrollador del software. En la versión 4 se cambió el sistema fuente abierta/cerrada a una sola distribución con posibilidad de extensiones, y las facilidades de servidor RDP y filtro USB fueron movidas a una extensión con licencia para uso solo personal o docente.
Existen versiones para Linux, Windows, BSDs, Solaris y todos los sistemas para los que se quiera desarrollar una. El Oracle Virtualbox tiene la ventaja de estar empaquetado para las principales distribuciones de Linux por su naturaleza (código abierto).
El VMware Server no parece tener un futuro halagador al estar descontinuado[13] y la fuente no estar en el dominio público por lo que se puede desestimar.
Por todos estos elementos y la falta de variantes será el Virtualbox el que se implemente en el CPD.
2.6.2 Alta disponibilidad
El Foro de Disponibilidad de Servicio (SAF, por sus siglas en inglés) es un consorcio que desarrolla, publica, educa y promueve especificaciones abiertas para sistemas altamente disponibles. Desarrolla dos especificaciones principales: la interfaz de plataforma de hardware, que abstrae el hardware del middleware de disponibilidad de servicio y los hace independientes; y la interfaz de aplicación que estandariza la interfaz entre el middleware de alta disponibilidad del SAF y los servicios.
En este caso se manejarían las máquinas virtuales como los recursos de alta disponibilidad que el clúster brindaría.
En Linux se puede utilizar el software Pacemaker[14] (interfaz de aplicación), empaquetado para las distribuciones más utilizadas. Este se encarga del manejo de la información del clúster (la unión lógica de los nodos, recursos, etc.) e interactúa con la pila de virtualización.
Heartbeat es uno de las posibles interfaces de plataforma de hardware[15], uno de los primeros también, y el gestor de Pacemaker. Se encuentra finalizado y no será actualizado. La otra posibilidad la constituye openAIS/Corosync, el dúo que está siendo desarrollado activamente. No obstante no es aconsejable aún utilizarlo en entornos de producción.
En Windows no hay implementación conocida de las especificaciones del SAF por lo que el sistema operativo a instalar en la base deberá ser una de las distribuciones de Linux utilizando Pacemaker y Heartbeat.
2.6.3 Almacenamiento
En el diseño de la solución de almacenamiento se sugiere la aplicación de varias tecnologías para lograr los parámetros necesarios.
Se debe utilizar un arreglo RAID 1 para la partición del sistema operativo y así lograr que con el fallo de un disco no se desactive el nodo. Se utiliza DRBD para crear arreglos cíclicos no coincidentes a través del centro, los cuales se exportan mediante una de las tecnologías de volúmenes compartidos, se agregan como volúmenes físicos en cada nodo y se consolidan en un solo volumen lógico sobre el cual se crea un sistema de archivos compartido.
Para no disparar los costos, los servidores de almacenamiento se fusionan con los servidores de máquinas virtuales en el mismo hardware, esto disminuye el rendimiento máximo del servidor de almacenamiento, pero aumenta la utilización de los equipos y evita la compra de más hardware que muy probablemente se sub-utilizaría. Esta unión mantiene el esquema de separar el almacenamiento del servidor de máquinas virtuales.
2.6.4 Especificaciones de la Red de Datos
Para las necesidades que se han venido acumulando en el centro de datos se hace imprescindible una red que opere al menos a 1 Gbps y tenga los parámetros de alta disponibilidad, flexibilidad y seguridad; lograrlos requiere la unión de varias tecnologías.
El conmutador de capa 2 (switch), del cual dependen las conexiones del centro, debe ser redundante, para lo cual debe implementarse una configuración de pila. Para completar la configuración y evitar que el fallo de una conexión (cable, cable parche, conector, etc.) desconecte un nodo se utiliza la agregación de enlace de forma que cada nodo tenga un enlace a cada switch.
En cuanto a la seguridad, una segmentación apropiada sería (Tabla 2.1):
Red Descripción
Conectividad Red a la que se conectan las interfaces de administración de los equipos de conectividad así como los servidores reales.
Administración Red de los administradores y equipos de administración. Única entrada a los equipos de conectividad e interfaces de administración en general.
AlmacenamientoPara tráfico iSCSI, DRBD, etc
Servicios Servidores virtuales que interactúan con el usuario (ej: web)
Interna Tráfico entre servidores virtuales, principalmente para acceder a servicios del backend (ej: base de datos)
Salida Enlace hacia Internet y/o centros secundarios
En la bibliografía se sugiere que el tráfico de almacenamiento tenga un medio dedicado, de alta velocidad y baja latencia. Estos requerimientos están muy ligados al uso de los servicios y se requiere un estudio del tráfico para estimarlos. Es posible utilizar troncos Gigabit Ethernet para este propósito.
Se deben utilizar al menos dos encaminadores que soporten alguno de los protocolos de redundancia de primer salto y también los protocolos ya propuestos, como los IEEE 802.1AX y 802.3q.
Se debe contar con cortafuegos que monitoreen cada enlace, por lo menos dos de estos, de forma que sea posible filtrar todo el tráfico, para mayor seguridad. Es posible también que el cortafuegos se encuentre en el mismo equipo que el encaminador con lo cual solo debe duplicarse la configuración de estos.
Los enlaces de conectividad hacia la WAN/Internet deben ser al menos dos de cada tipo, preferiblemente de Proveedores de Servicio de Internet (ISPs, por sus siglas en inglés) diferentes y no dependientes, eliminando los puntos simples de fallos y evitando así que un problema en uno de los proveedores repercuta directa e irremediablemente en el CPD.
2.7 Aspectos de la infraestructura
La infraestructura debe contar también con características de flexibilidad, escalabilidad, disponibilidad y seguridad para que el CPD pueda implementarlos.
Se debe contar con dos tomas eléctricas separadas e independientes con lo cual se evitan las interrupciones por reparación o avería en una de ellas. En los casos de catástrofe es muy probable que ambas fallen por lo que se debe contar con una fuente local (generador diésel, fuentes de energía renovable, etc.). Deben existir respaldos de batería que funcionen durante la transición entre fuentes y soporten el tiempo suficiente. Deben instalarse dos circuitos independientes y a cada cual se conectará al menos uno de cada tipo de equipo, logrando la total redundancia eléctrica.
Los equipos de climatización deben ser igualmente redundantes, con al menos dos equipos, conectados uno a cada fuente, evitando el sobrecalentamiento al fallar uno de los equipos o la oscilación al fallar una fuente eléctrica.
La forma más sencilla de sustraer los datos, en el momento de escribir este texto, es irrumpiendo en el CPD. Estudios demuestran que no se le da la importancia que lleva al acceso físico al centro provocando este estado. La ingeniería social suele ser un método muy efectivo para lograr tales fines. El correcto confinamiento así como un sistema de acceso respetable son
necesarios para lograr un mínimo de seguridad.
2.8 Conclusiones
Se realizó un estudio del estado del arte en las tecnologías relacionadas con el CPD. A partir de ahí se hizo un análisis crítico de las facilidades y problemas que brindaría su implementación para definir una solución.
Se seleccionó la virtualización como diseño base dada la concordancia que tiene con los problemas actuales del CPD, como la necesidad de consolidación. Se le agregaron elementos de alta disponibilidad tomado de los clústers de este tipo logrando así un clúster de alta disponibilidad de máquinas virtuales.
Se seleccionaron técnicas de almacenamiento acordes a los parámetros que requiere el CPD. Se apilaron varias tecnologías para explotar sus bondades individuales y palear sus problemas.
Se propusieron tecnologías de redes para la implementación de un esquema de red capaz de estar acorde con los parámetros requeridos sin incurrir en grandes gastos.
Por último se analizaron técnicas a implementar en la infraestructura que brinden un entorno acorde a las necesidades del CPD.
Capítulo 3 : Solución propuesta
3.1 Introducción
Una vez estudiada y seleccionada la tecnología a utilizar se procedió a la implementación de la solución (instalación y configuración de los dispositivos). Se expondrán los aspectos en que se analizó la implementación estando así las arquitecturas de servidores, almacenamiento, virtualización y gestión.
3.2 Arquitectura de Servidores
Los trabajos en el centro comenzaron con la actualización del hardware, a partir de los recursos con que se contaban, se concluyó con cuatro máquinas en el centro:
• metal-l es un servidor profesional HP ProLiant ML150 G5 (Intel Xeon E5205 @1.86, 1GB de RAM RDDR2)
• linkin-p es una máquina (motherboard) Asus P5KPL-CM con un microprocesador Intel Pentium 4 HT @3GHz, 4GB de memoria RAM DDR2.
• ramms-t es una máquina Intel Desktop Board DG33BU con un microprocesador Intel Core 2 Duo E6550 @2.33GHz, 8GB de memoria RAM DDR2.
• lacuna-c es una Dell Inspiron 530 (Intel Pentium E2160 @1.8GHz, 4GB de RAM DDR2)
Se instaló el sistema operativo CentOS en su versión 6 el cual, derivado de Red Hat Enterprise Linux, mantiene compatibilidad binaria con este. Se escogió por ser una distribución de Linux con soporte a largo plazo, importante en este caso ya que los nodos no brindan servicios directamente aunque muchos dependen de este. Esta decisión alarga los ciclos de reinstalación y disminuye el costo de administración de la infraestructura. El soporte es comunitario, aunque existe la posibilidad de pagar la versión de Red Hat para obtener soporte profesional.
Las arquitecturas, como elementos funcionales del centro, se concibieron de
forma separada, lo cual brinda una mejor perspectiva de las bondades y problemas de la implementación. Por otra parte, en la práctica tanto el almacenamiento como el procesamiento se realiza sobre el mismo hardware, evitando el sobredimensionamiento y el aumento de los costos.
Es importante tener en cuenta que un problema añadido consiste en que la reestructuración se hace sobre una plataforma en uso y detenerla puede impactar de forma sensible en los procesos de la empresa. Además no se trata de un sistema nuevo sino de una solución que ya existe con sus mecanismos y datos, los cuales será necesario compatibilizar y/o migrar.
3.3 Arquitectura de Almacenamiento
A los servidores se le instalaron nuevos discos duros, que aunque no eran los que se deseaban eran los que estaban disponibles, quedando la configuración:
• metal-l con 1 HDD Seagate de 320GB y otro HDD Seagate de 500GB
• linkin-p 2 HDDs Seagate de 320GB.
• metal-l 2 HDDs Seagate de 320GB
• lacuna-c HDD Seagate de 500GB y 1 HDD Seagate de 320GB.
Los dos NAS Maxtor Shared Storage II de 500GB se mantienen en el centro de datos.
En cada nodo se creó un pequeño volumen (10 GiB) RAID 1 entre los dos discos locales para hospedar el sistema operativo y los programas necesarios. Con esto el fallo de un disco no inhabilita la utilización del nodo, siendo posible arrancar el sistema desde el otro. Para total redundancia debe instalarse el gestor de arranque en ambos discos (los instaladores de los sistemas operativos lo instalan en un solo disco por defecto).
Una pequeña partición de intercambio en cada disco de 1 GiB. Con esto se tiene un espacio de intercambio total de 2 GiB, más de lo que generalmente utilizaría un sistema operativo.
El resto de cada disco se configura en RAID 1 mediante DRBD con otro nodo en forma cíclica, siendo posible el fallo de un nodo. Existen 2 configuraciones comúnmente usadas para DRBD: el protocolo A que notifica como operación
finalizada cuando ha llegado al disco local y a la cola TCP local y el protocolo C donde la notificación es enviada cuando llega a ambos discos. En el segundo se requiere una red de baja latencia o la velocidad de entrada/salida se afecta de sobremanera, por lo que para el caso de la red con que se cuenta se configuró el protocolo A. Es importante que se atiendan los discos fallidos ya que al fallar uno y su respaldo la información se vuelve irrecuperable. Con esto se logra un
Figura 3.1: Esquema de almacenamiento
respaldo de los datos del centro, siendo posible acceder a estos hasta teniendo un fallo simple.
Para flexibilizar el acceso se crean volúmenes físicos sobre los dispositivos lógicos DRBD y se exportan mediante AoE. Todos estos dispositivos en red se consolidan en un volumen de grupo en cada nodo. Este grupo de volúmenes, accesible por cada nodo, constituye el “espacio de almacenamiento” del centro.
Para utilizar el espacio de este grupo de volúmenes se crea un volumen lógico el cual se puede tratar como un dispositivo de bloques. Se crea un sistema de archivos OCFS2 sobre este. Durante la creación del sistema de archivos se debe especificar la cantidad de nodos que lo montarán, en este caso 4. Es importante que en esta fase el trabajo se haga desde un solo nodo ya que la implementación LVM2 no tiene administrador de bloqueo lo cual puede corromper la configuración.
En este punto ya se puede montar el sistema de archivos en los nodos de procesamiento y comenzar a utilizar el espacio disponible. Un esquema lógico de esta distribución se puede apreciar en la figura 3.1.
3.4 Arquitectura de Virtualización
Se concibió un esquema donde el procesamiento se virtualiza a través de un hipervisor, y se tiene acceso a redes de interconexión entre los nodos y almacenamiento compartido como se muestra en la figura 3.2.
Se instaló el hipervisor Virtualbox a través del repositorio de Oracle, el cual tiene paquetes para Red Hat Enterprise Linux, evitando así la compilación y teniendo la posibilidad de obtener actualizaciones. Se habilitó el servicio web de administración, para tener un método a bajo nivel de administración de las máquinas virtuales. Para manejar este acceso se utiliza el software phpvirtualbox.
Se instaló el grupo de software de alta disponibilidad en su combinación Pacemaker/Heartbeat utilizando el repositorio de Cluster LLabs. Se desarrolló un agente de recurso, el cual aún es código inestable e incompleto. Al concluir su desarrollo será publicado y encaminado a integrarse a Pacemaker.
A partir de aquí se cuenta con un ambiente capaz de manejar máquinas
virtuales con aspectos de alta disponibilidad. Las nuevas máquinas se copian al espacio de almacenamiento y se agregan al clúster como recursos altamente disponibles. La operación inversa se realiza para eliminarlas, se elimina el recurso del clúster y luego se elimina del almacenamiento.
No se implementaron mecanismos para la creación de máquinas virtuales al ser esta una infraestructura de producción. Se asume que la creación se hará en ambiente de desarrollo y se agregarán al clúster solo máquinas virtuales ya existentes.
Las cargas en los servicios que se brindarán son pequeñas, pero se requiere de numerosas aplicaciones corriendo de forma concurrente en el CPD. Es por esto
Figura 3.2: Los nodos de virtualización
que los recursos que se asignan a las máquinas virtuales se establecen en función de las sugerencias de los desarrolladores del sistema operativo huésped y se analizan los casos puntuales donde una aplicación pueda necesitar más recursos.
En general las máquinas virtuales que corren algún tipo de Linux se configuran con 512 MiB de memoria RAM y las que ejecutan una versión de Windows con 1 GiB. A cada máquina se le asigna un solo núcleo virtual, siendo problemático integrar alguna que se halla instalado originalmente con varios.
3.5 Arquitectura de Red
En cuanto al hardware el switch fue sustituido por un Allied Telesys 8000S de 26 puertos (24 Fast Ethernet + 2 Gigabit Ethernet). Se recableó el centro utilizando las normas de cableado estructurado, además de instalarse 16 enlaces entre el estante de los servidores y el gabinete de conectividad. Se
Figura 3.3: Diagrama de la red física
agregaron 2 máquinas para hacer función de encaminadores las cuales consisten en:
• night-w es una máquina IBM 6579-LBU (Pentium III @700 MHz con 64 MiB de RAM SDR)
• after-f es una máquina (motherboard) Foxconn (Pentium III @600 Mhz con 128 MiB de RAM SDR)
Estos se conectan como se muestra en la figura 3.3.
Se configuraron 6 troncos, uno a cada máquina, logrando un ancho de banda en cada nodo de 200Mbps y redundancia ante el fallo de un enlace. Aunque para el tráfico entre redes esto es más que suficiente, según se ha visto en la práctica, para el tráfico de almacenamiento esto es insuficiente. Es posible mejorar estas velocidades utilizando un switch Gigabit Ethernet e instalando controladoras de red del mismo tipo en sustitución de las actuales Fast Ethernet, con lo cual se alcanzaría la recomendada velocidad de 2 GBps. Cada máquina servidor cuenta con una controladora Gigabit Ethernet integrada que en el caso de las máquinas encaminadoras son Fast Ethernet.
La red se segmentó para acomodar los distintos tipos de tráfico que concurren en el centro como se puede ver en la tabla 3.1 y la figura 3.4.
Tabla 3.1:
Red VLAN ID Direcciones
Hardware 203 192.168.30.0/25
Administración 209 192.168.30.128/25
Almacenamiento 204 - - - - - - - - - - - - -
Servicios 201 192.168.16.0/24
Interna 202 192.168.17.0/24
Pública 200 200.55.152.40/29
Enlace WAN 299 192.168.31.2/29
Para comunicar las redes se utilizó Vyatta, una distribución de Linux, sobre máquinas de muy bajas prestaciones. Para un centro de este tipo los
requerimientos de hardware para el encaminador son muy modestos por lo que fue factible la decisión.
Vyatta es una distribución orientada a equipos encaminadores que implementa
Figura 3.4: Diagrama de la red lógica
muchas tecnologías y métodos utilizados en este ambiente. La configuración se realizó utilizando la interfaz de línea de comandos, lo cual facilitó la documentación del proceso.
A través de esta interfaz se configura el tronco que transporta el tráfico desde el switch y se definen las puertas de enlace en cada VLAN. Se configuran los servicios de ssh y SNMP para administración remota y monitoreo respectivamente, y NAT para el acceso de algunos servicios a Internet. Se implementan políticas de seguridad a través del cortafuegos siendo posible filtrar todo el tráfico que se mueve entre redes.
Se configuró la conexión con el modem/encaminador hacia la WAN a través de una red IP con máscara 30. Se instalaron las rutas, tanto en los encaminadores Vyatta como en el modem para lograr el flujo de tráfico entre ambas redes.
A partir de este punto es posible la comunicación entre los diferentes elementos del centro de datos así como el acceso a Internet y el resto de los nodos de la corporación.
3.6 Arquitectura de Gestión
Las configuraciones se realizan de forma manual, siguiendo documentación variada. Se almacenan, al igual de forma manual, en una base de conocimientos implementada en forma de wiki.
Los cambios se realizan de forma manual a través de las interfaces con ese propósito. El registro se lleva en forma de foro, donde las decisiones se discuten.
Las herramientas de monitoreo son escasas contándose solo con gráficos del tráfico de la red implementados a través de MRTG.
Las fallas de hardware no detienen el funcionamiento por el diseño empleado y el arreglo de estas se hace de forma manual. Se cuenta con un sistema de gestión de incidencias para el registro de estos hechos.
La seguridad continúa gestionándose basado en las políticas y técnicas descritas en el manual de seguridad del centro.
3.7 Conclusiones
La implementación de la solución de virtualización logró aportar una arquitectura flexible al CPD. Con esto también se logró consolidar los servicios que empezaban a ser muy numerosos para el pequeño CPD que existía.
Las características de clúster de alta disponibilidad resolvieron el problema de disponibilidad siendo capaz de tolerar la pérdida de un nodo sin que esto signifique la pérdida de un servicio.
La arquitectura de almacenamiento resolvió la unificación, aseguramiento y alta disponibilidad del espacio disponible en el centro. La flexibilidad lograda con la virtualización prepara al centro para los cambios siempre presentes en los pequeños CPDs.
La solución de red propuso un ambiente totalmente redundante y seguro que brindaría estas bondades al tráfico del CPD.
El clúster de Pacemaker combinado con Virtualbox, aunque mejora la disponibilidad, no logra evitar pequeñas interrupciones asociadas a operaciones como el movimiento de las máquinas virtuales entre hardware.
La arquitectura de almacenamiento ha demostrado ser muy compleja para el personal que opera el CPD. Es sin dudas el aspecto que más tiempo necesita para preparar a los administradores.
Los equipos con que se cuenta para la red no son capaces de satisfacer las necesidades. La falta de un par de conmutadores de capa 2 apilados crea en este un punto simple de fallo. Así mismo la tecnología utilizada, Fast Ethernet, no es capaz de brindar los anchos de banda requeridos por la arquitectura de almacenamiento.
En general el esquema de gestión “mejoró” aunque es insipiente comparado con las necesidades del CPD.
ConclusionesSe requería un diseño brindara los niveles de flexibilidad necesarios para el funcionamiento óptimo del CPD. En este sentido se logró virtualizar el procesamiento a través de un arquitectura de máquinas virtuales. A su vez en el almacenamiento se implementaron varias técnicas, como el agrupamiento en un solo volumen de todo el espacio existente por separado y la capacidad de acceder a este desde cualquier punto del centro. La arquitectura de red brinda la capacidad, de forma lógica, de establecer nuevas redes, virtualizando así su despliegue. Por tanto se considera una solución suficientemente flexible para el centro en cuestión.
La escalabilidad es otro aspecto que se debía tener en cuenta, aunque no se esperaba el crecimiento de las cargas en las aplicaciones existentes era lo opuesto para la capacidad de hospedar nuevas aplicaciones. La utilización de la plataforma virtualizada provee la capacidad de hospedar un gran número de estas aplicaciones sobre el hardware existente. Existe la posibilidad de crear nuevas redes con poco trabajo en caso de que alguna aplicación lo requiera. Los bajos anchos de banda provocado por la utilización de un conmutador de capa 2 de menos velocidad de la requerida afecta sensiblemente el desempeño de las aplicaciones, lo cual se agrava al aumentar el número de estas. En conclusión la escalabilidad se ve afectada por los no suficientes anchos de banda disponibles para el almacenamiento.
Gran parte de las necesidades se enfocaban en la disponibilidad del servicio como requisito para el correcto funcionamiento de la empresa. Con la implementación del clúster mediante Pacemaker se aumenta de sobremanera el tiempo activo (uptime) de los servicios. El almacenamiento distribuido aporta también a la capacidad de tolerancia a fallos del CPD. La no existencia de conmutador de capa 2 redundante crea un punto simple de fallo y provoca la disminución de la disponibilidad. Así mismo la infraestructura no cuenta con elementos redundantes por lo que se ve afectado grandemente el funcionamiento del CPD. En general la solución no es lo suficientemente disponible dada la ausencia de redundancia en cierto hardware de red.
La seguridad es un aspecto clave para el trabajo de varios elementos de la empresa así como necesaria para todos en general. La virtualización completa
brinda el aislamiento necesario para la ejecución de las aplicaciones. La segmentación de la red asegura las transmisiones contra filtraciones y acceso de elementos no autorizados. La redundancia del almacenamiento brinda seguridad a los datos siendo capaz de resguardarlos de fallos. En general es una solución segura pero no logra ser efectiva por los problemas que presenta la infraestructura subyacente.
RecomendacionesSe recomienda la resolución de los problemas referentes a la infraestructura que echan por tierra todas las bondades del diseño. El confinamiento y correcto control de acceso son aspectos imprescindibles para la seguridad del diseño. La fuente de energía alternativa mejoraría la efectividad de la disponibilidad no siendo posible resolver el problema de los enlaces externos redundantes por la existencia de un solo proveedor en el país.
Adquirir el hardware de red necesario para implementar la propuesta de alta disponibilidad así como el ancho de banda que requiere el almacenamiento.
El diseño e implementación de un esquema eficiente y automatizado de gestión que disminuya las cargas de trabajo de los operadores y permita un mejor manejo del centro
Referencias[1] «Service Availability Forum». [Online]. Available: http://www.saforum.org/.
[Accessed: 05-Sep-2011].
[2] «ibm-vmware-virtual-smb-datacenter-in-a-box-whitepaper.pdf (Objeto application/pdf)». .
[3] «Qué es el “vendor lock-in” - Economias». [Online]. Available: http://www.economias.com/2007-10-03/85/que-es-el-%E2%80%9Cvendor-lock-in%E2%80%9D/. [Accessed: 13-Oct-2011].
[4] «AoEDescription.pdf (Objeto application/pdf)». .
[5] «Kernel Korner - ATA Over Ethernet: Putting Hard Drives on the LAN | Linux Journal». [Online]. Available: http://www.linuxjournal.com/article/8149. [Accessed: 13-Sep-2011].
[6] «TUDP001.PDF (Objeto application/pdf)». .
[7] «ocfs2-1_6-usersguide.pdf». .
[8] «redhat.com | Red Hat Global File System». [Online]. Available: http://www.redhat.com/gfs/. [Accessed: 15-Oct-2011].
[9] Tian, «Data Center Disaster Recovery Plan for Businesses», 07-Abr-2010. [Online]. Available: http://smallbusiness-plan.net/data-center-disaster-recovery-plan-for-businesses/. [Accessed: 02-Jul-2011].
[10]«man page rsync section 1». [Online]. Available: http://www.manpagez.com/man/1/rsync/. [Accessed: 15-Oct-2011].
[11]«TR-2006-157.pdf (Objeto application/pdf)». .
[12]«Changelog - VirtualBox». [Online]. Available: https://www.virtualbox.org/wiki/Changelog. [Accessed: 15-Oct-2011].
[13]«VMware Server, Free Virtualization Download for Virtual Server Consolidation». [Online]. Available: http://www.vmware.com/products/server/overview.html. [Accessed: 15-Oct-2011].
[14]«Pacemaker - ClusterLabs». [Online]. Available: http://www.clusterlabs.org/wiki/Pacemaker. [Accessed: 15-Oct-2011].
[15]«Heartbeat - Linux-HA». [Online]. Available: http://linux-ha.org/wiki/Heartbeat. [Accessed: 15-Oct-2011].
Bibliografía
• ES.EBOX2010, eBox, http://doc.ebox-platform.com/es/intro.html#presentacion
• GUNTHER2007, Neil J. Gunther; “Guerrilla Capacity Planning, A Tactical Approach to Planning for Highly Scalable Applications and Services”
• LINUX2007, Linux Kernel Documentation http://www.kernel.org
• ATS94-2008, Management Software AT-S94 WEB User’s Guide
• VLAN-MAN2010, “Ubuntu Manpage: /etc/network/interfaces (vlan) - vlan extensions for the interfaces(5)”, http://manpages.ubuntu.com/manpages/hardy/man5/vlan-interfaces.5.html
