Han pasado mas de dos años desde que realice la siguiente ponencia publicada en este blog con anterioridad. Si bien es cierto que en aquel periodo inicial, la presentacion giraba en torno a la definicion de los distintos modelos (SaaS, PaaS e IaaS) del Cloud Computing, la posible aplicacion de los casos de uso de sus diferentes tipologias (publica, privada e hibrida) y una descripcion cualitativa de los riesgos previamente identificados.

Sin embargo, actualmente y fruto de la evolucion de estos años se han ido decantando fundamentalmente dos modelos, cada uno de ellos orientado a un tipo concreto de organizaciones:

- En el caso particular de las Pymes, la orientacion a la Nube Publica es mayor debido fundamentalmente al ahorro de costes tanto en la adquisicion del software como en el mantenimiento de la infraestructura y la posibilidad de utilizacion de los mismos recursos de infraestructura que las grandes organizaciones (computacion, red, almacenamiento, backup, etc...).

- En el caso concreto de las grandes organizaciones, la aproximación se esta produciendo en la orientacion interna al Servicio y a la trasformacion del Datacenter propio bajo el modelo de la Nube Privada.


Sin entrar a valorar las principales ventajas y beneficios del Cloud Computing (pago por uso, autoservicio y elasticidad) al igual que sus desventajas (garantias de seguridad de la información), si me gustaria destacar que la VIRTUALIZACION (aunque no es un requerimiento, como se puede apreciar en el modelo SaaS) si es la tecnologia habilitadora que esta permitiendo la evolución del modelo IaaS en base al siguiente recorrido: Nube Privada -> Nube Hibrida bajo un nuevo paradigma de adquisicion y entrega Servicios IT.

En este sentido, es de considerar la prevision que Marlon Molina expone en su blog, ya que mas alla de los cambios tecnologicos que estamos viviendo y su impacto en la gestion tecnica de la operativa diaria, este nuevo paradigma en la entrega de Servicios IT y el enfasis en la calidad del Servicio lleva consigo asociado de forma inevitable (nos guste o no) un importante cambio desde el punto de vista operativo en todo tipo de organizaciones sean de la naturaleza que sean, fundamentalmente debido a que esta orientacion a Servicio requiere una mayor gobernanza (ITIL, ISO 20000, etc...) alcanzable mediante la correcta implementacion de Servicios Gestionados, lo que igualmente obedece a una gestion mas eficaz y eficiente de la tecnologia.

Finalmente, aprovecho este articulo para identificar las soluciones existentes en la actualidad que permiten implementar nubes privadas y algunas de las citadas escalar a nubes hibridas bajo el ya mencionado modelo IaaS:

- VMWare vCloud
- OpenStatck (a destacar la implementacion de StackOps)
- RedHat Cloudforms
- Xen Cloud Platform
- CloudStack

Finalmente y como continuacion a la parte I y la parte II de esta serie de articulos (de vital importancia la relaccion entre la Gestion de la Disponibilidad y la Gestion de la Continuidad), en esta ocasion me gustaria destacar las principales ventajas que aporta la VIRTUALIZACION DEL ALMACENAMIENTO desde el punto de vista del negocio:
Como bien indica Josep Ros en su blog, esto es especialmente importante debido fundamentalmente a que los Virtualizadores de Almacenamiento se van a encargar de realizar toda la logica de la gestión del almacenamiento (salvo la parte evidente de los switches de la SAN), donde destaca la generacion y entrega de las LUNs creadas entre distintas cabinas de diferentes fabricantes incluyendo nuevas funcionalidades propias del frontend de dichos sistemas de almacenamiento como es el caso del Thin Provisioning. Esto repercute directamente en que las cabinas de almacenamiento de proposito general puedan ser de un menor nivel [al margen de nuevas funcionalidades propias del backend de dichos sistemas de almacenamiento como son: tiering (dinamico o manual) de LUNs o de bloques, compresion de datos, controladoras activo-activo, multiprotocolo (FC, FCoE, iSCSI, NFS, CIFS), etc...]

Sin embargo, en el caso concreto que nos ocupa (Datacenter Activo - Activo en un entorno de Produccion de Virtualizacion de Servidores) este nuevo enfoque supone una importante oportunidad de mejora con respecto al primer y segundo escenarios descritos anteriormente.

El en primer escenario la implementacion de los Virtualizadores de Almacenamiento va a permitir que con un correcto diseño y configuracion de la arquitectura logica de almacenamiento sea posible resolver el punto de fallo que suponia la caida de la cabina como almacenamiento compartido del cluster extendido de los hypervisores. La oportunidad de mejora consiste en la utilizacion de los dispositivos de bloques (discos FC, SSD, SAS, SATA) de cada una de las cabinas que residen fisicamente en cada uno de los CPDs de forma conjunta y balanceada en el proceso de generacion y entrega de las LUNs como Datastores compartidos. Nota importante la configuracion en Alta Disponibilidad de los propios Virtualizadores de Almacenamiento ubicados fisicamente cada uno de ellos en uno de los CPDs implicados.

En el segundo escenario la implementacion de los Virtualizadores de Almacenamiento representa una menor oportunidad de mejora ya que en este caso el diseño y configuracion de la arquitectura logica de virtualizacion y almacenamiento esta ideada en base a la disposicion local con pesos del 50% de los productos que corren en las VMs implicadas directamente en la prestacion del servicio.


En base a mi experiencia en clientes destaco los siguientes Virtualizadores de Almacenamiento mas conocidos:

• NetApp V-Series
• EMV vPlex
• IBM SVC

Como continuacion al anterio articulo de este blog, en este post me gustaria dar un enfoque diferente a como se aborda de forma tradicional la Gestión de la Continuidad y su viculacion con la Gestion de la Disponibilidad dentro del alcance de un proyecto de Virtualizacion de Servidores o/y en el caso de un proyecto especifico a tal efecto y/o finalmente dentro de la explotacion de un servicio; con el conocido software VMWare Site Recovery Manager.

Son muchas y conocidas las ventajas que aporta este tipo de software en los referente a la VIRTUALIZACION, como es la integracion con los distintos sistemas de almacenamiento multivendor (EMC, NetApp, IBM, etc...) de proposito general ya sean cabinas de tipo SAN (protocolos FC, FCoE) o dispositivos NAS (rotocolos CIFS, NFS, iSCSI) y sobre todo por la naturaleza de los servidores implementados como maquinas virtuales (VMS) la posibilidad de gestionar y automatizar un plan de recuperacion ante desastres de una forma mucho mas agil, dinamica y funcional que una prueba de contingencia en un entorno fisico, tal y como se puede apreciar en las imagenes adjuntas.

Sin embargo, al margen de su coste una de sus posibles desventajas reside en la naturaleza misma de dicho producto, debido a que esta diseñado y desarrollado para implantar planes de contigencia en el caso concreto de un escenario de DATACENTER ACTIVO - PASIVO lo que esta relaccionado directamente con la replicacion (normalmente sincrona, al margen de si la fibra es oscura y dedicada o multiplexada a través de equipos DWDM) entre dos sistemas de almacenamiento ubicados cada uno de ellos en un CPD diferente actuando el pricipal como origen del entorno de Produccion y el secundario como destino (directamente relaccionado con los dos indicadores de gestion fundamentales en este aspecto de las infraestructuras: RTO y RPO).

Por otro lado, para implementar un plan de recuperacion ante desastres (es decir un DRP: Disaster Recovery Plan) como parte tecnologica dentro de un plan de continuidad de negocio (es decir BCP: Business Continuity Plan) es posible analizar otras opciones que pasan por la generacion de una SAN extendida (de tipo FRABRIC) y una LAN extendida entre los distintos CPDs implicados; contituyendo asi un DATACENTER ACTIVO - ACTIVO tal y como se puede apreciar en la imagen final del escrito.

En un primer escenario, es especialmente importante la configuracion de un cluster extendido (HA, DRS) entre los hypervisores de cada CPD con su propio sistema de almacenamiento como Datastore compartido entre ambos centros de datos, pero ubicado y funcionando unicamente en uno de ellos. Este es precisamente el punto de fallo de mayor impacto ya que la caida de la cabina de almacenamiento requiere que se disparen procesos de respaldo tradicionales ya sean manuales o automatizados lo que implica la aceptacion de un tiempo de parada en la prestacion del servicio y su posterior restablecimiento con un rendimiento al 100%. Sin embargo la posibilidad de mover servidores (VMs) entre los sites implicados supone una ventaja a considerar.

En un segundo escenario, es especialmente importante el balanceo de carga y la alta disponibilidad de los productos que se ejecutan en las maquinas virtuales (VMs) dentro de cada cluster local de hypervisores, ya que se debe ser especialmente riguroso para conseguir una distribucion donde los pesos de los dos sitios sean del 50% con su propio sistema de almacenamiento como Datastore no compartido entre ambos centros de datos. La ventaja principal reside en que el servicio no solo esta protegido ante la caida de los hypervisores que conforman el cluster local, sino que ademas esta cubierto ante la caida del sistema de almacenamiento de forma directa sin la necesidad de activar ningun proceso ya sea este de tipo automático o manual y sobre todo sin suponer en ningun caso la parada en la prestacion del servicio. La desventaja consiste en la perdida de rendimiento ya que el 50% de los servidores (VMs) que daba servicio esta caido y unicamente se presta el servicio por el otro site que aporta el 50% de la capacidad de procesamiento. Este ultimo esquema es compatible con soluciones que automatizan planes de contingencia tradicionales como hemos visto, aunque no seria necesario si ante una situacion de contingencia esta validada y prevista la prestacion del servicio con la mitad de rendimiento.

Otra de las buenas practicas (compatible con ambos escenarios descritos) que esta directamente relacciona con la Gestion de la Configuracion ante planes de contigencia y de recuperacion ante desastres en un entorno de VIRTUALIZACION es la agrupacion de los servidores (VMs) que prestan un determinado servicio de forma completa en Aplicaciones Virtuales (vAPPs) y la asignacion de una LUN dedicada a dicha vAPP, siempre y cuando no sea un requerimiento de los productos que corren en las VMs la asignacion dedicada de la LUN (RDM).

A raiz de una consulta de mi amigo Máximo, aprovecho este post para exponer las alternativas en cuanto a soluciones de almacenamiento NAS (CIFS y NFS) y SAN (iSCSI) de tipo Open Source con respecto a otro otras de tipo propietario como pueden ser Dell EquaLogic y HP Lefthand.


En el mundo de las distribuciones Linux esta teniendo un gran apoyo y aceptación OpenFiler el cual incorpora entre otras ventajas la posibilidad de realizar Bonding entre sus diferentes interfaces de red.

A medio camino, es necesario nombrar la existencia de FreeNAS, el cual permite comparticion de ficheros a través de NFS y CIFS al igual que servir dispositivos de bloques via iSCSI. Sin embargo a diferencia de su equivalente anterior en el mundo Linux, la gestión del almacenamiento es posible realizarla con ZFS (con todas las ventajas que esto supone) aunque en una version anterior a la implementación de ZFS bajo las distribuciones y appliances basados en OpenSolaris incluido Solaris.

En el ámbito de las distribuciones OpenSolaris, es de destacar las ventajas que incorporan tanto Open Storage (Sun Microsystems) y NexentaStor (Nexenta Systems) al incluir igualmente la funcionalidad de Link Aggregation (Nivel II) al mismo tiempo que IPMP (Nivel III) entre sus diferentes interfaces de red.


Al implementar ZFS como motor de almacenamiento interno (sistemas de ficheros al igual que gestor de discos), resulta realmente interesante al margen de todas las opciones de snapshots, clones (tercera copia), replicación asincrona, "thin provisioning" y deduplicación a nivel de bloque como funcionalidades de serie, la capacidad de poder realizar la distribución de las distintas caches de lectura y escritura en diferentes discos (SATA, SAS, SSD e incluso memorias Flash) como se puede apreciar facilmente en siguiente ilustración:

Al margen de las conocidas utilidades de hardenning de sistemas UNIX/Linux como son CISscan, Titan, Jassp, Yassp, Bastille y demás citadas en la presentación de Seguridad en OpenSolaris; las cuales desde el punto de vista de auditoría permiten conocer a un nivel de test interno como de "seguro" (mejor dicho inseguro) se encuentra el sistema a bastionar... posteriormente siempre podemos recurrir al test externo con herramientas como Nmap (la version 5 es una maravilla ;-), Nemesis, AutoScan, Superscan, Zenmap, NetGrok, OpenVAS, Nessus (desde la version 3 aunque ya no goza de licencia GPL, aunque en la version 4 incorpora mejoras realmente potentes).

Todo esto enlaza directamente con las distintas etapas de un test de penetración de seguridad IT (Planificación, Reconocimiento, Descubrimiento y Ataque) el cual proporciona un buen inventario de los activos de información decubiertos de igual modo que sus vulnerabilidades en el momento de la realización de la prueba.

Una vez alcanzado esta primera fase de identificación y escaneo, posteriormente es posible centrar el tiro en un determinado servicio (como por ejemplo el servicio web: protocolo http (puerto tcp 80) y protocolo https (puerto tco 443)) a través de otras utilidades mas concretas como nikto o su version grafica Wikto y asi sucesivamente con el objetivo de identificar vulnerabilidades facilmente trasformables en amenazas debido a la existencia y ejecución de exploits que compromentan dicho activo de información.

El siguiente paso deberia ser medir el riesgo
que supondria explotar estas vulnerabilidades inherentes a los sistemas de información, convirtiendose entonces en amenazas de los mismos. El propósito es poder cuantificar la probabilidad de su ocurrencia al igual que su posible impacto. En una fase posterior finalmente deberiamos ser capaces de materializar todas las salvaguardas proactivas que lleguen a evitar en mayor o en menos medida el riesgo de exposición a esas amenazas de cada uno de los activos descubiertos, de igual modo que articular las contramedidas necesarias siempre que sea posible mitigar dicho riesgo de una forma mas reactiva.

Tradicionalmente en el mundo de las Redes de Almacenamiento (SAN) desde el punto de vista del protocolo Fibre Channel (FCP) las medidas de seguridad podian ser:

* Físicas: caso del Mapping, es decir la relación entre las diferentes LUNs de los DiskGroup definidos en el RAID hardware de las cabinas de discos de proposito general y los puertos de fibra del Storage Procesor de las mismas.

* Lógicas: caso del Masking, es decir la relación entre los WWPNs de las HBAs de los servidores con respecto a los LUNs (previamente mapeados en el Mapping) de las cabinas de discos; como desde el lado del Switch al realizar el Zonning, es decir la relación entre los distintos puertos de fibra de las cabinas y de los servidores ó mediante la relación de los WWPNs de las HBAs de los servidores y los WWPNs de los puertos de fibra de las cabinas.

Sin embargo, actualmente se esta produciendo un importante avance en la convergencia de las Redes de Almacenamiento al mundo TCP/IP, es decir al de las Redes de Datos. Este es el caso del protocolo Fibre Channel over Ethernet (FCoE) como de iSCSI. En el primer caso (debido a que se trata en todo momento de Ethernet) el equivalente al Zonning en el lado del Switch sería realizar el establecimiento de VLANs a Nivel II (MAC), es decir similar a la segmentación física de los dominios de broadcast tal y como se realiza a nivel físico en las Redes de Datos.

En el segundo caso, iSCSI funciona igualmente bajo Ethernet con lo cual la seguridad física se implementaría del mismo modo citado anteriormente para FCoE, en el lado del Switch. La diferencia aparece en el lado de las cabinas de discos de tipo iSCSI desde el punto de vista de la seguridad lógica. Es posible definir el Masking, es decir establecer una relación entre los IQNs de los Servidores y los LUNs que sirven las cabinas de discos y por otro lado posibilita igualmente el realizar autenticación CHAP unidireccional ó bidireccional (tanto en el lado del target como en el del initiator).

En esta ultima linea, adjunto los diferentes pantallazos de la realización de dichas medidas de seguridad en una SAN de tipo iSCSI, teniendo en cuenta la cabina de discos esta basada en ZFS como gestor de discos (RAID Z con doble paridad) y de volumenes dinamicos implementando de serie importantes funcionalidades como es el caso de ILM en cuanto al reparto de las caches de lectura y escritura, deduplicación en origen, replicación asincrona y thin provisioning al margen de otras ya citadas anteriormente en este blog.

Tal y como se puede apreciar, desde el punto de vista de los servidores (los cuales tienen acceso a los diferentes LUNs que sirve la cabina de discos iSCSI, de forma selectiva) se han realizado las pruebas con los sistemas operativos mas comunes y utilizados en este momento como es el caso de MS Windows 2008 Server R2, CentOS Linux 5.4, Sun Solaris 10u8 y OSX 10.4.11.

De forma similar se podrian implantar igualmente las medidas de seguridad lógica descritas en el caso concreto de entornos basados en la Virtualización de Servidores utilizando los hypervisores mas demandados en el mercado como es el caso de VMWare vSphere (ESX v3.5/4), Citrix XenServer (v5.0/5.5) y RHEV.

El objetivo de este articulo es dar a conocer las diferentes opciones de Alta Disponibilidad y Balanceo de Carga en cuanto a la gestión del acceso al Almacenamiento (ya sean configuraciones singlepath o multipath) que se pueden realizar por parte de los 3 hypervisores comentados anteriormente en este blog (vSphere, XenServer y RHEV) utilizando para ello OpenStorage como cabina de discos.




Antes de nada es importante destacar que en el caso de las redes SAN de tipo FibreChannel (FCP) es habitual que los frontend de los Storage Processors de las cabinas de almacenamiento de proposito general soporten de serie dichas opciones de configuracion. Sin embargo en las cabinas de almacenamiento multiprotocolo y/o dispositivos NAS en el caso concreto de las redes SAN de tipo iSCSI es necesario para poder habilitar el acceso a disco mediante multipath que soporten el estandard ALUA (Asymmetric Logical Unit Access).



Concretamente vSphere (tanto vía CLI como a través de su conocida GUI vCenter) soporta de serie configurar estos tres metodos de acceso a disco de tipo multipath: Fixed, Most Recently Used y Round Robin, tal y como se puede apreciar facilmente en los pantallazos adjuntos a dicho post.


En particular XenServer soporta igualmente de serie acceso a disco mediante configuración multipath, sin embargo sus opciones de configuración vía CLI y mucho mas a través de su GUI XenCenter resultan bastante mas limitadas en cuanto a plantear las distintas opciones que facilmente hemos revisado con vSphere. En esta linea es necesario recurrir a StorageLink el cual permite una gestión visual y mucho mas avanzada del almacenamiento.

La configuración de Cluster (local o metropolitano) de agrupaciones de varios hypervisores XenServer utilizan asimismo datastores iSCSI y/o NFS para supervisar su estado mediante heartbeat entre los nodos implicados y la capacidad de Live Migration en cuanto a sus VMs.


Finalmente, en cuanto a RHEV al tratarse en todo momento del hypervisor KVM en empotrado en un sistema RHEL las opciones de configuración via CLI son las mismas que en el caso del software multipath (soporta Round Robin) que viene de serie con esta conocida distribución y derivadas (CentOS y Fedora). Sin embargo al igual que XenServer las opciones de configuración a través de su GUI RHEV Manager adolece de las mismas limitaciones en comparación con vSphere.



Imagen diseño SAN iSCI: Angel Ferras

En este post me gustaria tratar el cambio sustancial que supone no solo desde el punto de vista tecnologico la gestión del almacenamiento de las diferentes instancias de una BBDD Oracle directamente por el propio software de Oracle (al margen del sistema operativo) sino por este mismo motivo el cambio organizativo que representa en las operaciones y servicios IT de cualquier organización al igual que ya lo esta suponiendo la Virtualización de Servidores y la Virtualización de Escritorios (VDI).


En concreto el articulo se centra en la versión Oracle11gR1 bajo una maquina en este caso virtual que corre OEL: Oracle Enterprise Linux 5.5 (aunque por este motivo deberia funcionar sin problemas en distribuciones similares como RHEL 5.5, CentOS 5.5 e incluso UNIX como Solaris 10, aunque quedaria pendiente su posible integración con ZFS).

Para esta prueba piloto a nivel funcional se han escogido diferentes escenarios:

1.- Discos asignados directamente a la maquina virtual y posteriormente ofrecidos de forma completa a ASM (Automatic Storage Management) como gestor de almacenamiento de todas las instancias de la BBDD que correran en dicha instalacion

2.- Discos asignados directamente a la maquina virtual, se ha realizado un RAID por software (en particular RAID 1: Mirror) y el dispositivo de bloques resultante si se ha ofrecido de forma completa a ASM

3.- Discos asignados directamente a la maquina virtual, se ha realizado un VOLUMEN DINAMICO por software (en particular con LVM2) y el dispositivo de bloques resultante si se ha ofrecido de forma completa a ASM

4.- Discos asignados directamente a la maquina virtual mediante una SAN iSCSI, los discos asignados mediante el iSCSI initiator se han ofrecido de forma completa a ASM

En cualquiera de los 4 casos anteriormente citados, el resultado ha sido satisfactorio tanto en cuanto al almacenamiento de los datos estructurados de cada una de las instancias de BBDD como el del almacenamiento de los archives de las que tenian dicha funcionalidad de registro activada para mejorar su copia de seguridad, como se puede apreciar en las imagenes adjuntas.

El hecho de funcionar 100% en una SAN iSCSI, hace preveer el mismo resultado satisfactorio en una SAN Fibre Channel tanto con singlepath como con multipath. En ambos casos seria necesario evaluar importantes funcionalidades de cualquier cabina de discos actual como son el "Thin Provisioning" y "Deduplicación".

Por otro lado en la versión Oracle11gR2 se ha incorporado el hecho por el cual ASM es capaz de gestionar no unicamente el almacenamiento de los datos estructurados y archives de las diferentes instancias de una instalación, sino igualmente cualquiera de los sistemas de ficheros con datos no estructurados del sistema operativo (sorprendentemente sin recurrir al mismo) al igual que la incorporación de ACFS (ASM Cluster File System) como sistema de ficheros global en instalaciones de tipo RAC como parte de un nuevo producto y nuevo licenciamiento como es Grid Infraestructure.

Es conocido que la gran mayoria de las organizaciones IT ya han virtualizado en mayor o menor medidad sus servidores o están en proceso de virtualización de sus CPDs (...y los que no, se lo están planteando seriamente por todas aquellas ventajas competitivas que supone) ya sea en el caso de arquitecturas de procesador cerradas (sparc, itanium, power, etc.) o en el caso de procesadores de consumo (x86 y/o x64).

Si bien es cierto que la consolidación de servidores supone unicamente un paso previo a la virtualización completa del CPD, el siguiente escalon lo representa el hecho (en algunas organizaciones IT comienza a ser una realidad... aunque es pronto para ello) de ser capaces de orientar las operaciones IT en servicios gestionados como una nube privada y en el futuro porque no como una nube hibrida (Cloud Computing).

En esta linea de trabajo, la convergencia en la gestión unificada de las infraestructuras de almacenamiento y virtualización (de servidores y/o escritorios) de forma centralizada representa mas que un avance en el camino de la automatización del ciclo de vida de las maquinas virtuales y su operativa diaria. Este post trata de exponer como es posible este cambio tecnologico y mas aun organizativo con las cabinas de disco multiprotocolo y dispositivos NAS de NetApp en el caso concreto de DataONTAP como se puede apreciar en los pantallazos adjuntos tanto con Datastores iSCSI como NFS.


Al igual que ocurria con OpenStorage de Sun Microsystems, es relevante tener en cuenta que es posible realizar la gestión del almacenamiento de la infraestrucuta virtual (particularmente con vsphere [tanto ESX como ESXi] de VMware) con las mas que necesarias funcionalidades de "Thin Provisioning" y "Deduplicación" contando con las ventajas de las opciones multiprotocolo en lo referente al almacenamiento: FC, iSCSI, NFS, CIFS y FCoE (he hechado en falta Infiniband).

Como se puede apreciar la integración de las cabinas y/o dispositivos de NetApp en vCenter es lo que permite este cambio siendo en todo momento compatible con las diferentes herramientas de administración de la citada plataforma de almacenamiento (FilerView, System Manager y CLI).


Sin embargo la integración permite igualmente aprovechar la capacidad de tercera copia (tanto snapshots como clones) de los FlexVolumes lo que posibilita la gestión de la copia de seguridad de las VMs de forma independiente y completamente integrada en la infraestructura de almacenamiento de la cual posteriormeente seria posible realizar backup a cinta con destino VTLs o librerias fisicas si es necesario ir mas allá de la recuperación y dar cabida a los planes de respaldo y continuidad de negocio de la organización.

En el caso concreto del almacenamiento EMC asignado (directamente a los hypervisores ESX/ESXi) mediante el equipamiento NAS Celerra como frontend y como backend el equipamiento de tipo cabina de discos SAN Clariion, es de destacar que con las ultimas versiones del operativo DART del Celerra es posible realizar Thin Provisioning y Deduplicacion como se puede apreciar en la imagen adjunta.


Sin embargo la integracion de los equipos de almacenamiento de EMC con la tecnologia de virtualizacion de servidores de VMWare es posible no solo con los equipos citados (NAS Celerra y cabinas SAN Clariion) sino ademas con el equipamiento de tipo cabina de discos SAN Symmetrix (tanto los antiguos DMXs como los novedosos vMAX) apreciable igualmente en los pantallazos adjuntos.


Como apunte final de dicho articulo, destacer la existencia del software multipath PowerPath compatible con cualquier sistema de almacenamiento, el cual a diferencia del software multipath propio de VMWare (vsphere) citado anteriormente en este blog; soporta configuracion multipath en modo Round Robin pero de forma concurrente.

En posteriores articulos de este blog se tratará dicha integración en el caso particular de otros productos de virtualizacion de servidores como pueden ser Citrix XenServer cuya integración de la tecnologia de NetApp con su consola de gestión XenCenter es también posible aunque en menor medida que la indicada anteriormente. En el caso ultimo de RHEV practicamente no se aprecia dicha integración ni en el caso de la tecnologia de almacenamiento de EMC ni de NetApp, seguramente esto suponga un reto mas que importante a desarrollar en futuras releases y versiones de dicho producto.

Al igual que la fase de diseño resulta de extraordinaria importancia en los proyectos de implantación y/o migración de infraestructura de servidores, almacenamiento y backup en lo que se conoce como conjunto de medidas para evitar en la medida de lo posible la desviación del camino critico; en la explotación del Datacenter la gestión de la capacidad resulta si cabe de mayor relevancia por aquello que dicha infraestructura condicionara el servicio que se entrega directamente a los usuarios en el dia a dia de la operaciones y la futura evolución tanto del Datacenter como del Servicio que se presta.


Al margen de la necesidad de invertir en la gestión a nivel de proceso de la capacidad de cada uno de los servicios que se prestan maxime cuando la infraestructura citada anterormente es compartida, seria mas que positivo considerar la posibilidad de aqduirir una herramienta que posibilite medir de forma sencilla y eficaz la evolución de la infraestructura en la que se apoyan los servicios que ofrece el Datacenter con el animo de intervenir como elemento facilitador en la toma de decisiones en base al control y seguimiento periódico que hay que realizar.


Como se puede apreciar en los pantallazos adjuntos, la posibilidad de poder gestionar igualmente infraestructuras fisicas y virtuales tanto de servidores, como de sistemas de almacenamiento y de backup puede representar mas que una ventaja competitiva en este sentido.


En el caso particular de la Virtualizacion de Servidores implementada con vSphere (ESX/ESXi) de VMWare se deberia permitir la gestión de la capacidad no solo de cada uno de los hosts (mas conocidos como hypervisores) sino ademas de las agrupaciones logicas en modo cluster de los mismos al igual que las VMs (Maquinas virtuales) contenidas o no en vAPPs (Aplicaciones Virtuales) todo ello dentro del ámbito del Datacenter Virtual. Como se puede apreciar en la imagen anexa, se deberia posibilitar igualmente la identificación y evolución de todos y cada uno de los DataStores asociados.


Del mismo modo en el caso concreto de los sistemas de almacenamiento tanto cabinas de discos de proposito general (FCP e iSCSI), como dispositivos de tipo NAS (NFS y CIFS) multifabricante (EMC, NetApp, Sun Microsystems) deberia ser posible medir su evolucion y consumo maxime cuando estan habilitadas las nuevas funcionalidades de Thin Provisioning y Deduplicación online ya que cobra especial relevancia la sobresuscripción y por extencion el posible compromiso del disco logico ofrecido a los sistemas y el disco fisico libre del almacenamiento global.


Para finalizar, con respecto a los sistemas de backup de tipo software mas conocidos en el mercado (Backup Exec, NetBackup, TSM, Commvault, Legato, ARC Serve) tanto si estan basados en las tradicionales librerias fisicas de cintas, como si estan basados en las nuevas VTLs con o sin backend de discos y/o con o sin backend de cintas; deberia ser posible medir la evolución del consumo de GBs, de cintas fisicas y/o drives logicos al mismo tiempo que el rendimiento de los trabajos que son necesarios respaldar en referencia a las distintas politicas de seguridad configuradas. Asimismo, es de remarcar que en cuanto a las VTLs formaria parte de la gestión de su capacidad la medida de la evolución de su ratio de deduplicación y la diferencia entre el espacio nominal y el espacio fisico consumido de manera conjunta a la evolución del uso de la caché.

Al igual que el resto de articulos orientados a la gestión unificada y convergente de las infraestructuras de Almacenamiento y Virtualización, un correcto y periódico "Capacity Planning" representa mas que un avance en la evolución de la Explotación del Datacenter hacia el camino de la nube privada o "Cloud Privado" como fase previa de la nube hibrida en la gestión IT.

Un nivel superior en la convergencia de la gestión conjunta de las infraestructuras de Almacenamiento y Virtualización lo representan las buenas practicas.
Se basan en la necesidad de orquestar cambios organizativos mas allá que la integración de los productos de Virtualización de VMWare, Citrix y RedHat (basados en la figura del hypervisor, OJO que es posible virtualizar servidores sin hypervisor como ya se indico en este blog) con los productos de los fabricantes de Almacenamiento como NetApp, EMC y Sun Microsystems como ya se trató anteriormente en este anterior articulo.

El objetivo de dichas buenas practicas se centra en el requisito que supone el hecho que los administradores de Virtualizacion y los administradores de Almacenamiento trabajen conjuntamente para lograr una mayor eficiencia, control y seguimiento en la explotacion del Datacenter. La idea se basa en evitar los errores de una de las consecuencias mas comunes de la gestión de los entornos virtuales, como es la proliferación sin orden ni criterio de las VMs (Maquinas Virtuales)... mas conocido como VIRTUAL SPRAWL.

Dentro de lo que se conoce como ecosistema VMWare (vSphere: ESX/ESXi) seria necesario considerar la posibilidad de aqduirir una herramienta que posibilite mostrar e identificar de un modo end-to-end la configuración vigente desde la propia VM (Maquina Virtual) hasta el conjunto de bloques (FCP e iSCSI) y ficheros (NFS, CIFS) pasando por todas las rutas I/O a cada Almacenamiento fisico utilizado pudiendo ser cabinas de disco de proposito general o dispositivos de almacenamiento de tipo NAS.

Como se puede apreciar en los pantallazos adjuntos es posible identificar tanto en el lado del Almacenamiento todos aquellos componentes necesarios en la gestión de la/s cabina/s y/o dispositivo/s NAS (RAID, grupos de discos, discos fisicos, volumenes, LUNs, ficheros, etc.), como en el lado de la SAN (Switches de tipo FC como iSCSI) al igual que todos y cada uno de los componentes de los Virtual Datacenters como son los Clusters de hypervisores ESX/ESXi, hosts standalone del mismo tipo ESX/ESXi asimismo como los Datastores utilizados por cualquiera de los protocolos citados.

En el caso concreto y particular de cada una de la VMs (Maquinas Virtuales) se posibilita el conocimiento de su camino fisico y su camino logico desde su host owner (en la arquitectura del Datacenter) hasta el LUN exacto del Almacenamiento que utiliza como Datastore asociado. Del mismo modo que si dicha VM se encuentra en una vAPP (Aplicacion Virtual) como conjunto de VMS desplegadas en un unico cluster como agrupación de varios nodos del tipo hosts ESX/ESXi.


El fondo de toda esta gestion integrada y convergente de las infraestructuras de almacenamiento y virtualización, lo que se persigue es un escalón mas en el ciclo de vida de la evolución del Datacenter hacia lo que se conoce como nube privada o cloud privado como paso previo hacia la expansión a la nube hibrida para poder aprovechar sus capacidades de elasticidad y disponibilidad ante determinadas situaciones bajo demanda, como se puede apreciar en el resumen inferior de dicho post:

Mas allá de la integración, en el caso de la Virtualizacion de VMWare vSphere, con las tecnologias de Almacenamiento de fabricantes como NetApp y EMC como se puede apreciar en este anterior articulo, dicha integración es posible igualmente con otros productos de Virtualización como Citrix XenServer objeto de este nuevo post.


Dicha integración no solo proporciona información en la gestión de la infraestructura virtualizada acerca del almacenamiento utilizado con el maximo nivel de detalle; un correcto alineamiento de los bloques de datos, sino que ademas permite utilizar las funcionalidades de tercera copia propias del sistema de almacenamiento como puede ser el uso de snapshots y clones compatible en todo momento con las capacidades de replicación (mayoritamente sincrona) a nivel hardware y mas que interesantes en el ciclo de vida de las VMs (Maquinas Virtuales).


Como se puede apreciar en los pantallazos adjuntos (Detalle: cluster de dos hypervisores XenServer en HA con acceso compartido a una cabina de discos de proposito general de NetApp que ejecuta DATAOntap), la herramienta de gestión XenCenter permite conectar directamente con cada uno de los agregados y crear Storage Resources directamente especificando incluso el numero de volumenes a crear en la cabina y si estos son servidos con funcionalidades avanzadas como Thin Provisioning y Deduplicacion.


En paralelo, desde la herramienta StorageLink es posible descubrir la configuracion existente del Datacenter virtual, incluyendo el detalle acerca del estado de las VMs y las posibles plantillas existentes o generadas. Asimismo, se permite declarar la configuración de la cabina utilizada donde residen las VMs proporcionando información en base a la utilización de dicho sistema de almacenamiento al igual que la posibilidad de generar nuevos Storage Resources en la infraestrucutra de Virtualización directamente desde los propios agregados de la cabina de discos; posibilitando incluso el hecho de poder especificar igualmente aquellas funcionalidades avanzadas como Thin Provisioning y Deduplicacion y el propio protocolo de almacenamiento FCP/iSCSI.


Finalmente, una de sus funcionalidades menos conocida pero no por ello menos importante, reside en la capacidad como complemento añadido a dicha herramienta de soportar de serie la opcion de diseño y creacion de forma guiada de un plan automatizado de Contigencia del entorno Virtual. Normalmente este "Disaster Recovery Plan" (DRP) formaria parte del "Business Continuity Plan" (BCP) que representa un nivel superior al tecnologico.


La configuracion de este Plan de Contigencia se realizaria por fases como se puede apreciar en la imagen adjunta. En una primera fase seria necesario realizar todas las tareas guiadas sobre el Datacenter Virtual en el SITE principal (normalmente el que da servicio) para lo cual es requisito indispensable tener conectividad IP con el SITE secundario (tanto de la infraestrucutra de Virtualización como la de Almacenamiento).


En una segunda fase posterior, seria necesario realizar igualmente las tareas guiadas sobre el SITE secundario (el que daria servicio ante una caida del principal), lo que incluiria las pruebas funcionales del plan de Contigencia generado y por extencion la puesta en marcha del failover entre SITES de forma automatizada.

Destacar que en las ultimas versiones de XenServer, se ha incorporado StorageLink como parte del core de dicho producto de Citrix al igual que un buen numero de mejoras representativas entre las que seria necesario destacar: Web Self-Service y Distributed Virtual Switching como indica la release notes.

Una de las partes en la que menos enfasis se realiza normalmente en los proyectos de migracion ó implantacion de infraestrucutruas de Virtualizacion (sea de Servidores o de Escritorios) reside en el aspecto de la Monitorizacion. Sin embargo, desde el primer momento de su puesta en produccion y de la responsabilidad de la gestion de la explotacion de este nuevo entorno virtual (dentro del Datacenter) comienza a ser critico todo aquello relaccionado con la monitorizacion; maxime si el servicio esta dentro del marco de las buenas practicas de ITIL o mas aun el cumplimiento de la ISO 20000.

En este sentido, los productos de Virtualización (ya vimos que es posible realizar Virtualizacion de Servidores sin la necesidad de la figura del hypervissor aqui) basados en los hypervisores mas conocidos del mercado como son VMWare vSphere, Citrix XenServer y RHEV permiten su monitorizacion directa o indirecta mas alla del contenido de las VMs (Maquinas Virtuales) que permiten ejecutar.

En el caso de vSphere ESX, XenServer y RHEV es posible realizar su monitorizacion mediante software tradicional de monitorizacion de infraestructuras fundamentalmente basado en el modelo cliente/servidor como son: Nagios, Zabbix, Hyperic, Zenoss, etc. o por el contario a traves del protocolo SNMP (indispensable con vSphere ESXi) como por ejemplo con Cacti tal y como es posible apreciar en las imagenes adjuntas.

Sin embargo en el caso concreto de vSphere ESX/ESXi es posible recurrir a software denominado del ecosistema de VMWare como es el caso tanto de Quest como de Veeam.



La diferencia fundamental de este tipo de software de ecosistema VMWare con respecto al software tradicional de monitorizacion, reside en que el primero de ellos utiliza directamente llamadas a la API de vCenter lo cual no resulta nada intrusivo (no hay necesidad de instalar ningun tipo de agente) ni requiere la modificacion de las politicas de seguridad a nivel de firewall interno) de los hypervisores citados anteriromente.


Por otro lado, volviendo al caso particular de vSphere ESX/ESXi, la integración del software de ecosistema de VMWare (Veeam y Quest) con respecto a la monitorizacion es total y permite el descubrimiento automatico de todos los elementos del vCenter: Cluster de ESX, hosts de ESXi standalone, vAPPs (Virtal Applications) como conjunto logicos de VMs (Virtual Machines), VMs, Datastores, etc. como es posible apreciar en las imagenes adjuntas.


En esta ultima linea de trabajo, en la monitorizacion de la evolucion del consumo de disco por parte de todos y cada uno de los diferentes Datastores del vCenter, es posible conocer dicha evolucion no solamente de los Datastores locales sino igualmente de los remotos como dispositivos de bloques (ya sea via FCP o iSCSI) o sistemas de ficheros (NFS, CIFS) esten o no esten en uso. Detalle de la imagen adjunta con cabinas/NAS de NetApp y EMC.

Dentro de la Gestión de Servicios y mas aun en el mundo de los Servicios Gestionados, al margen de si se constituye una Oficina de Servicio dedicada a velar por la funcion y garantia de ó de los Servicios o si se gobiernan de otra forma mas departamental y por extension mas jerarquica y tradicional; la gestión de la configuración es una de las piezas mas importantes en la gestión de los activos de informacion y su pieza angular sobre la que pivota toda la informacion es la CMDB (Configuration Management DataBase).

Como ya se mostró en la siguiente presentación, al margen de los cambios organizativos que supone la aparición de roles con responsablidades funcionales y la resistencia a este nuevo modelo donde la dependencia organica aporta poco valor; OneCMDB es una herramienta Open Source que proporciona de serie funcionalidades de descubrimiento y carga de Elementos de Configuración (CIs: Configuration Items).

En los proyectos de implantación de una CMDB, mas alla del correcto diseño del modelo de datos una de las tareas que se representa en el camino critico es la carga inicial de activos y su posterior mantenimiento. En este caso concreto OneCMDB proporciona de serie la integración con NMAP para realizar el descubrimiento y al mismo tiempo y de forma compatible la integracion con NAGIOS en cuanto a la incorporación de aquellos componentes que estan siendo monitorizados, lo cual representa una alternativa mas que valida en consideracion con otros productos de mercado.

Finalmente es un hecho conocido que el éxito o fracaso de este tipo de proyectos se basa fundamentalmente en el hecho de no morir de exito, es decir, es preferible tener identificadas aquellas aplicaciones que utilizan mayoritariamente los usuarios y sobre las mismas realizar un mapeo similar a este modelo sencillo: APLICACION (atributos de definición y de utilización) -> SOFTWARE BASE (atributos de definición y utilización de web server, j2ee server, bbdd server, ldap server, etc...) -> HARDWARE BASE (atributos de definición y de utilización de servidor, sistema operativo, interfaces de LAN, LUNs de cabina de discos, DRIVES de robotica de backup, etc... ) -> HARDWARE COMUN (atributos de definición y utilización de redes LAN, redes SAN, cabinas de discos, robótica de backup, etc...); al hecho de tener que configurar de forma completa un Catalogo de Servicios con sus diferentes Niveles de Servicio y en base a los mismos empezar a diseñar el modelo de datos que dará soporte a la CMDB.

Tras un proyecto de implantación de una infraestructra de Virtualizacion de Servidores con su solucion integrada de gestión de Almacenamiento (SAN ó NAS) y Backup (VTL ó Libreria de Cintas) o más aun tras el proceso P2V que suele ser el driver de este tipo de proyectos, desde el dia despues de su paso a producción una de sus mayores justificaciones y/o ventajas comienza a ser su gran paradijma. Me refiero a la rápida capacidad de la nueva infraestructura virtual de provisionar VMs (Virtual Machines) es decir disminuir de forma considerable el "time to service" de un Servicio Informático o el "time to market" de un proveedor de Internet.

En la mayoria de los clientes que he podido visitar, el crecimiento indiscriminado sin seguimiento ni control de la proliferación de VMs comienza a ser un problema no solo en cuanto al espacio en disco ocupado en el sistema de Almacenamiento (lugar donde residen las VMs y su snapshots realizados con vCenter, independientemente de su capacidad de "Thin Provisioning", "Deduplicación" y "Tiering"), en el sistema de Backup (Librerias de cintas tradicionales o VTLs con "Deduplicación offline") sino por el riesgo operativo que supone esta situación.

Existen 3 lineas de trabajo a desarrollar para combatir dicho crecimiento descontrolado de VMs:

1.- Gestión de la Configuración
2.- Gestión de la Capacidad
3.- Gestión de la Seguridad

En el primer caso, podemos recurrir a heramientas comunes de gestión de la configuración, las cuales deberian proveernos de lineas base capaces de comparar en el tiempo este tipo de crecimiento e identificar las nuevas VMs; aunque en el caso concreto de VMWare vSphere (ESX y/o ESXi) existen herramientas de ecosistema como v-Scout o su nueva versión v-Commander las cuales permiten identificar las VMs con atributos personalizados e incluso generar politicas activas tras llegar al fin del ciclo de vida de cada una de las VMs. De hecho en esta linea ya esta trabajando el propio fabricante VMWare como se puede apreciar con: vCenter Configuration Manager y vCenter Discovery Manager.

En el segundo caso, resulta esencial trabajar en la linea de la gestión de la capacidad ya que será la herramienta que permitirá diagnosticar el consumo de infraestructura mas alla que la propia alta-disponibilidad intrinseca de los entornos virtuales. Esta es una de las actividades menos desarrolladas y con mayor efectividad y esta directamente relaccionado igualmente con la monitorización en Virtualización.

El tercer y ultimo caso de las medidas para disminuir este riesgo, reside en la correcta configuración de las directivas de permisos y privilegos de los usuarios locales o remotos (si estan mapeados los permisos contra un determinado Directorio Activo) en lo que se refiere a las politicas de seguridad de vCenter. Es decir restringir la capacidad de los usuarios para crear VMs, clones, templates y snapshots de las mismas.

Este tipo de medidas son especialmente relevantes en aquellas organizaciones IT que ya han comenzado a tras sus primeros pasos hacia el modelo de nube privada y/o nube hidrida dentro del Cloud Computing, aunque cobra su maximo exponente en el caso de la nube publica y aquellos proveedores que utilizan infraestructuras compartidas con multipropiedad (mas conocido como multitenancy) para albergar a sus clientes.

Es habitual en los proyectos de implantación de la infraestrucutra de una plataforma de virtualizacion (de servidores o de escritorios) ya sea mediante la metodologia PMBOK o PRINCE2 el camino critico que representa el proceso P2V (Physical To Virtual) previo assesment de cada uno de las maquinas/escritorios que queremos implantar en la nueva plataforma compartida en almacenamiento y backup.

En este sentido resulta mas que interesante todas y cada una de las nuevas funcionalidades de los diferentes productos de mercado:

- VMware vSphere 5 (Auto Deploy, vSphere Storage Appliance (VSA), Web Client, vCenter Server Appliance (Linux), Storage DRS, FCoE support, Virtual Hardware 8, Storage Profiles, Driver Storage Providers, Secure Syslog, Dump Collector, VMFS5, VDS5, Enhanced Firewall, etc...)

- Citrix XenServer 5.6 (Snapshots Commit & Rollback, Dynamic Workload Balancing, Integrated StorageLink, Distributed Virtual Switching, Web Self Service, etc...)

- RHEV 3.0 (V2V Migration, OVF Import / Export, Dedicated Monitoring & Reporting, VDI Support, Power User Portal (Autoservice), RHEV-Manager Java application, RHEL 6 based, etc...)

- HyperV 3.0 (Cluster Shared Volumes, Storage and network resource pools, Bandwidth Management, Virtual Switch Extensions, etc...)

Sin embargo, desde el dia despues de la entrega del proyecto y su paso a produccion comienza la explotación de esta nueva plataforma que debemos enmarcar dentro del marco de trabajo de la Gestión de Servicios y de las buenas practicas de ITIL teniendo en cuenta todas y cada una de las recomendaciones realizadas en este blog (Gestión del Virtual Sprawl, Gestion de la Capacidad, Gestión de la Configuración, Gestión de la Disponibilidad, etc...).

En este sentido, en el articulo se representan desde el punto de vista cualitativo cada uno de los 34 aspectos mas relevantes de la Virtualizacion y si el mismo supone una Ventaja (V), Desventaja (D) o Riesgo (R) a considerar. Posteriormente, del mismo modo se propone un analisis cuantitativo de esos mismos aspectos con una valoración del 1 (bajo impacto) al 4 (alto impacto) sobre los 6 aspectos troncales (Capacidad, Gestión, Disponibilidad, Coste y Seguridad).

Finalmente, se muestra una tabla de mapeo basada en la correlacion de cada uno de los 34 aspectos mas relevantes indicados anteriormente acerca de la VIRTUALIZACION con la mayoria de los procesos tanto de la parte de soporte al Servicio (Service Suppport) como de entrega de Servicio (Service Delivery) de ITIL v2.

Como conclusion, indicar que el impacto de los aspectos listados (18) de gestión y disponibilidad de la virtualización es alto con respecto al resto. Asimismo con un mayor detalle, los procesos de gestión finaciera, gestión de niveles de servicio, gestión de la continuidad y gestión de la disponibilidad son aquellos en los cuales el impacto de la virtualización es significativo.

A raiz de la realización en la oficina de una propuesta para un cliente, aprovecho este post para exponer el planteamiento de como distribuir la produccion entre dos CPDs en la modalidad Activo - Activo tras un proceso de consolidación basado en la Virtualización de Servidores.


Con cualquiera de las tres principales tecnologias identificadas en anteriores entradas de este blog, tanto en el ecosistema de VMWare vSphere, de Citrix XenServer y de RHEV es posible utilizar con los requerimientos de LAN Extendida y SAN extendida la implementación de un MetroCluster formado por los diferentes hypervisores de cada uno de los productos de mercado citados.

En el caso concreto de VMWare vSphere al margen de la utilización de las tecnologias HA, DRS, VMotion, Storage VMotion, VCB y Fault Tolerance, de forma particular es posible respaldar igualmente vCenter con un enfoque Activo - Pasivo mediante el uso de VCenter Heartbeat, lo que incluye la replicación de todos y cada uno de sus datos de forma consistente.

En el caso opuesto, basado en un enfoque Activo - Pasivo es posible agilizar todo el proceso tradicional de Contingencia mediante la utilización de Site Recovery Manager (SRM) con el propósito de automatizar la Contigencia de un CPD a otro al tratarse las VMs de ficheros. Destacar que SRM soporta este proceso tanto de forma unidireccional como bidireccional y que se apoya fuertemente el la replicación (sincrona o asincrona) propia de las cabinas de almacenamiento de proposito general.