Uso de las plataformas de virtualización VMware con EMC VPLEX - PDF\nUso de las plataformas de virtualización VMware con EMC VPLEX\nDownload "Uso de las plataformas de virtualización VMware con EMC VPLEX"\nInmaculada Hidalgo Castellanos\n1 Uso de las plataformas de virtualización VMware con EMC VPLEX Planificación de mejores prácticas En este white paper, se describen las funciones y la funcionalidad de EMC VPLEX presentes en las plataformas de virtualización VMware. Asimismo, se exponen las mejores prácticas para configurar un ambiente VMware a fin de aprovechar EMC VPLEX de la manera más conveniente. El white paper también explica las metodologías para llevar a cabo la migración de una implementación de VMware existente a EMC VPLEX. Mayo de 2010\n2 Copyright 2010 EMC Corporation. Todos los derechos reservados. EMC considera que la información de esta publicación es precisa en el momento de su publicación. La información está sujeta a cambios sin previo aviso. LA INFORMACIÓN DE ESTA PUBLICACIÓN SE PROPORCIONA TAL CUAL. EMC CORPORATION NO SE HACE RESPONSABLE NI OFRECE GARANTÍA DE NINGÚN TIPO CON RESPECTO A LA INFORMACIÓN DE ESTA PUBLICACIÓN Y, ESPECÍFICAMENTE, RENUNCIA A TODA GARANTÍA IMPLÍCITA DE COMERCIABILIDAD O CAPACIDAD PARA UN PROPÓSITO DETERMINADO. El uso, la copia y la distribución de cualquier software de EMC descrito en esta publicación requieren una licencia de software correspondiente. Para obtener una lista actualizada de nombres de productos de EMC, consulte las marcas comerciales de EMC Corporation en (visite el sitio web de su país correspondiente). Todas las demás marcas comerciales que aparecen en este documento son propiedad de sus respectivos dueños. Número de referencia h7118 Planificación de mejores prácticas 2\n3 Tabla de contenido Resumen... 4 Introducción... 4 Público al que está dirigido... 4 Descripción general de EMC VPLEX... 5 Arquitectura de EMC VPLEX... 5 EMC VPLEX... 6 Arquitectura de agrupamiento en clusters de EMC VPLEX... 6 Aprovisionamiento de almacenamiento VPLEX en ambientes VMware... 8 Consideraciones sobre la conectividad Múltiples paths y balanceo de carga VMware ESX Server versión 3 y balanceo estático de carga VMware ESX Server versión 4 y NMP VMware ESX Server versión 4 con PowerPath/VE Funciones de PowerPath/VE Administración de PowerPath/VE Migración de ambientes VMware existentes a VPLEX Migraciones no disruptivas mediante Storage VMotion Migración mediante la encapsulación de dispositivos existentes Implementaciones de VMware en un ambiente VPLEX Metro Configuración de clusters VMware Migración no disruptiva de máquinas virtuales con VMotion Cambio de la configuración de los volúmenes VPLEX Metro no replicados vcenter Server virtualizado en VPLEX Metro Conclusión Referencias Planificación de mejores prácticas 3\n4 Resumen Los productos EMC VPLEX que ejecutan el sistema operativo EMC GeoSynchrony proporcionan una amplia oferta de nuevas funciones y funcionalidades para la era de cloud computing. EMC VPLEX traspasa las barreras físicas de los data centers y permite a los usuarios acceder a una sola copia de los datos en ubicaciones geográficas diferentes de manera simultánea, lo cual hace posible la migración transparente de la ejecución de máquinas virtuales entre data centers. Esta capacidad permite el uso compartido de cargas transparente entre varios sites y brinda la flexibilidad de migrar cargas de trabajo entre sites con anticipación a eventos planificados. Más aún, en caso de eventos no planificados que causan interrupciones de servicios en uno de los data centers, se pueden reiniciar los servicios fallidos en el site no afectado, con un mínimo de esfuerzo y minimizando el objetivo de tiempo de recuperación (RTO). La plataforma de virtualización VMware virtualiza toda la infraestructura de TI, incluidos servidores, almacenamiento y redes. El software de VMware incorpora estos recursos y presenta un conjunto uniforme de elementos en el ambiente virtual. Por lo tanto, VMware vsphere 4 aporta el poder de cloud computing al data center, lo que reduce los costos de TI y aumenta la eficiencia de la infraestructura. Además, para los proveedores de servicios de hosting, VMware vsphere 4 permite un camino más económico y eficiente hacia la prestación de servicios de nube compatibles con las infraestructuras de nube interna de los clientes. VMware vsphere 4 ofrece importantes mejoras en el performance y la escalabilidad con respecto a la generación anterior, VMware Infrastructure 3, para permitir la implementación en nubes internas de aplicaciones, incluso de las que requieren muchos recursos, como las bases de datos de gran tamaño. Gracias a estas mejoras en el performance y la escalabilidad, VMware vsphere 4 puede permitir una nube interna completamente virtualizada. En consecuencia, EMC VPLEX es la opción naturalmente apropiada para un ambiente de virtualización basado en tecnologías VMware. La funcionalidad de EMC VPLEX de ofrecer tanto federación local como distribuida que posibilita la cooperación transparente de elementos de datos físicos dentro de un solo site o dos sites geográficamente separados permite a los administradores de TI traspasar las barreras físicas y ampliar su oferta de nube basada en VMware. Las funcionalidades de federación local de EMC VPLEX permiten la recopilación de las soluciones de almacenamiento de datos heterogéneos en un site físico y presentan el almacenamiento como un pool de recursos para la plataforma de virtualización VMware, lo que permite los principios más importantes de una oferta de nube. Específicamente, la ampliación de las funcionalidades de VPLEX para abarcar varios data centers permite a los administradores de TI aprovechar las ofertas de nube privada o pública de los proveedores de servicios de hosting. Las sinergias que proporciona una oferta de virtualización VMware conectada a EMC VPLEX ayudan a los clientes a reducir el costo total de propiedad a la vez que se proporciona un servicio dinámico que puede responder rápidamente a las necesidades cambiantes del negocio. Introducción En este white paper, se presenta EMC VPLEX, su arquitectura de clusters, las funciones y la funcionalidad que están presentes en las soluciones que permiten nubes privadas. Luego, se explica el aprovisionamiento del almacenamiento VPLEX a los ambientes VMware y se brindan pautas sobre la metodología óptima para conectar las plataformas de virtualización VMware a EMC VPLEX y seleccionar una política de múltiples paths a fin de obtener la mejor resiliencia y el mejor performance posibles del ambiente virtualizado. El white paper también presenta diversas técnicas para llevar a cabo la migración de implementaciones de VMware existentes a EMC VPLEX. Por último, se explican las mejores prácticas para aprovechar EMC VPLEX Metro en un ambiente VMware a fin de brindar el máximo de flexibilidad, resiliencia y protección de datos, y minimizar los riesgos de la falta de disponibilidad de datos debido a eventos no planificados. Público al que está dirigido Este white paper está dirigido a administradores de VMware, administradores de almacenamiento y arquitectos de TI responsables del diseño de arquitectura, la creación, la administración y la utilización de ambientes de TI virtualizados que emplean las tecnologías de VMware vsphere y EMC VPLEX. En este white paper, se da por supuesto que el lector está familiarizado con la tecnología VMware, EMC VPLEX y las herramientas de software relacionadas. Planificación de mejores prácticas 4\n5 Descripción general de EMC VPLEX EMC VPLEX con el sistema operativo EMC GeoSynchrony es una solución de federación basada en SAN que elimina las barreras físicas dentro de uno o varios data centers virtualizados. EMC VPLEX es la primera plataforma del mundo que proporciona federación local y distribuida. La federación local brinda la cooperación transparente de elementos de almacenamiento físico dentro de un site, mientras que la federación distribuida amplía el concepto entre dos ubicaciones a distancia. La implementación de la federación distribuida es posible mediante una tecnología innovadora disponible con VPLEX, AccessAnywhere, que permite reubicar y compartir una copia de datos, y acceder a ella a distancia. La combinación de un data center virtualizado con la oferta EMC VPLEX proporciona a los clientes maneras completamente nuevas de resolver problemas de TI e incorporar nuevos modelos de servicios informáticos. En concreto, los clientes pueden llevar a cabo las siguientes tareas: Transferir aplicaciones virtualizadas entre data centers. Utilizar el balanceo de cargas de trabajo y la reubicación entre sites. Agregar data centers y proporcionar disponibilidad ilimitada. Arquitectura de EMC VPLEX EMC VPLEX constituye la arquitectura de última generación para transferencia de datos y acceso a la información. La nueva arquitectura es resultado de la experiencia de más de veinte años de EMC en el diseño, la implementación y el perfeccionamiento de soluciones de protección de datos distribuidas y caché inteligente de clase empresarial. Como se muestra en la Figura 1, VPLEX es una solución para la federación de almacenamiento de EMC y de otros fabricantes. VPLEX reside entre los recursos de almacenamiento heterogéneo y los servidores, y presenta una arquitectura nueva con características exclusivas: Hardware de agrupamiento en clusters de escalamiento horizontal, que permite que los clientes comiencen con poco y crezcan con niveles de servicio predecibles. Almacenamiento avanzado de datos en caché, que utiliza caché SDRAM a gran escala para aumentar el performance y reducir la latencia de I/O y los conflictos de los arreglos. Coherencia de caché distribuida para uso compartido, balanceo de carga y failover de I/O automatizado en el cluster. Vista consistente de uno o más LUN entre clusters VPLEX separados por una corta distancia con un data center o por distancias síncronas, lo que permite nuevos modelos de alta disponibilidad y reubicación de la carga de trabajo. Figura 1. Funcionalidad de federación de almacenamiento heterogéneo de EMC VPLEX Planificación de mejores prácticas 5\n6 EMC VPLEX EMC VPLEX consta de dos ofertas: VPLEX Local: solución adecuada para clientes que están interesados en la federación de sistemas de almacenamiento homogéneos o heterogéneos en un data center, y para la administración de la transferencia de datos entre entidades físicas de almacenamiento de datos. VPLEX Metro: solución destinada a clientes que requieren acceso simultáneo y transferencia de datos entre dos ubicaciones separadas a distancias síncronas. La oferta VPLEX Metro también incluye la funcionalidad exclusiva de permitir que un site remoto VPLEX Metro presente LUN sin necesidad de almacenamiento físico para esos LUN en el site remoto. EMC VPLEX con los límites actuales en cuanto a la arquitectura se muestra en la Figura 2. Figura 2. Oferta de EMC VPLEX con límites en la arquitectura Arquitectura de agrupamiento en clusters de EMC VPLEX VPLEX utiliza una arquitectura de agrupamiento en clusters exclusiva que ayuda a los clientes a traspasar los límites del data center y permite a los servidores en múltiples data centers tener acceso de lectura y escritura simultáneas a los dispositivos compartidos de almacenamiento en bloque. Un cluster VPLEX, que se muestra en la Figura 3, puede escalar de manera vertical mediante la incorporación de más motores y puede hacerlo de manera horizontal por medio de la conexión de múltiples clusters para formar una configuración de VPLEX Metro. En la versión inicial, VPLEX Metro soporta hasta dos clusters, que pueden estar en el mismo data center o en dos sites diferentes situados a distancias síncronas (aproximadamente hasta 100 kilómetros o 60 millas). Las configuraciones de VPLEX Metro ayudan a los usuarios a transferir y compartir cargas de trabajo de manera transparente, a consolidar data centers y a optimizar la utilización de recursos entre data centers. Además, los clusters VPLEX proporcionan transferencia de datos no disruptiva, administración de almacenamientos heterogéneos y disponibilidad de aplicaciones mejorada. Planificación de mejores prácticas 6\n7 Figura 3. Representación esquemática de EMC VPLEX Metro Un cluster VPLEX está compuesto por uno, dos o cuatro motores. El motor es responsable de la federación del flujo de I/O y se conecta con los hosts y el almacenamiento por medio del uso de conexiones Fibre Channel para el transporte de datos. Un solo cluster VPLEX está compuesto por un motor con los siguientes componentes principales: Dos directores que ejecutan el software GeoSynchrony y se conectan al almacenamiento, a los hosts y a otros directores en el cluster con conexiones Fibre Channel y Gigabit Ethernet. Una fuente de alimentación en standby que proporciona alimentación de backup para mantener el funcionamiento del motor durante una pérdida transitoria de alimentación. Dos módulos de administración con interfaces para administrar de manera remota un motor VPLEX. Cada cluster también está formado por lo siguiente: Un servidor de administración que administra el cluster y proporciona una interfaz desde una estación de administración remota. Un gabinete de EMC estándar de 40 unidades para albergar todos los equipos del cluster. Además, los clusters que contienen más de un motor incluyen lo siguiente: Un par de switches Fibre Channel utilizados para la comunicación entre directores de varios motores. Un par de fuentes de alimentación universales que proporcionan alimentación de backup a los switches Fibre Channel y permiten al sistema enfrentar una pérdida transitoria de alimentación. Planificación de mejores prácticas 7\n8 Aprovisionamiento de almacenamiento VPLEX en ambientes VMware EMC VPLEX proporciona una interfaz de administración intuitiva y guiada por asistente para provisionar almacenamiento a varios sistemas operativos, incluida la plataforma de virtualización VMware. El sistema también brinda una interfaz de línea de comando (CLI) para usuarios avanzados. La Figura 4 muestra la interfaz GUI para el aprovisionamiento de almacenamiento de EMC VPLEX. Figura 4. Interfaz de administración GUI de EMC VPLEX La interfaz de administración basada en navegador, como se observa en la Figura 4, muestra de manera esquemática los diversos componentes que forman parte del proceso. El almacenamiento de EMC VPLEX se expone mediante el uso de una construcción lógica, denominada Storage View, que es la unión de los objetos Iniciadores registrados, Puertos VPLEX y Volumen virtual. El objeto Iniciadores registrados enumera el WWPN de los iniciadores que necesitan acceso al área de almacenamiento. En el caso de un ambiente VMware, la entidad Iniciadores registrados contiene el WWPN de las HBA en los servidores VMware ESX Server conectados a EMC VPLEX. El objeto Puertos VPLEX contiene los puertos front-end del arreglo VPLEX a través de los cuales el objeto Iniciadores registrados tiene acceso a los volúmenes virtuales. El objeto Volumen virtual es una recopilación de volúmenes que se genera a partir de volúmenes de almacenamiento proporcionados a Planificación de mejores prácticas 8\n9 EMC VPLEX desde los arreglos de almacenamiento back-end. Se puede observar en el recuadro de la esquina inferior izquierda de la Figura 4 que un volumen virtual se construye a partir de un Dispositivo que a su vez puede ser una combinación de diversos dispositivos construidos sobre la base de una entidad abstracta denominada Extensión. La figura también muestra que una entidad Extensión se crea a partir del objeto Volumen de almacenamiento expuesto a EMC VPLEX. También se muestran en el recuadro de la esquina inferior derecha de la Figura 4 los siete pasos que se requieren para provisionar almacenamiento desde EMC VPLEX. El asistente soporta un mecanismo centralizado para provisionar almacenamiento a distintos elementos del cluster en el caso de EMC VPLEX Metro. El primer paso del proceso de aprovisionamiento de almacenamiento desde EMC VPLEX es el descubrimiento de los arreglos de almacenamiento conectados a este. Este paso debe ejecutarse con poca frecuencia, ya que EMC VPLEX monitorea proactivamente los cambios del ambiente de almacenamiento. El segundo paso del proceso es la reclamación del almacenamiento que se ha expuesto a EMC VPLEX. El proceso de reclamación del almacenamiento genera el Volumen de almacenamiento del objeto mostrado en la Figura 4. La Figura 5 es un ejemplo de este proceso. En esa figura, se puede observar que el software VPLEX simplifica el proceso mediante la sugerencia automática de nombres sencillos para los dispositivos que se han expuesto desde los arreglos de almacenamiento. Figura 5. Reclamación de volúmenes de almacenamiento mediante el asistente de VPLEX Planificación de mejores prácticas 9\n10 Después de la creación de los volúmenes de almacenamiento, se deben determinar las extensiones de esos volúmenes. El sistema de administración de VPLEX proporciona un asistente para esta actividad. Si hace clic en la URL, Step 3: Create Extents from Storage Volumes, que se muestra en la Figura 4, se iniciará el asistente. La Figura 6 muestra el primer paso del asistente. Figura 6. Primer paso del asistente para crear una extensión Para mayor simplicidad, en ambientes VMware, se recomienda generar una sola extensión en el volumen de almacenamiento que se creó en el dispositivo presentado desde el arreglo de almacenamiento. En ese caso, no es necesario modificar las entradas predeterminadas que se muestran en el área resaltada en amarillo en la figura. Un paso posterior del asistente permite a los usuarios crear una sola extensión que abarque toda la capacidad del volumen de almacenamiento. Esto se muestra en la Figura 7. Figura 7. Especificación de la capacidad de una extensión al crear una extensión a partir de un volumen de almacenamiento Como se muestra en la Figura 7, al hacer clic en el botón Next, los usuarios pueden analizar la configuración propuesta y ejecutar el plan. El último paso del proceso verifica las operaciones llevadas a cabo por EMC VPLEX. En la Figura 8, se muestran los dos últimos pasos del asistente. Planificación de mejores prácticas 10\n11 Figura 8. Creación de una extensión mediante el asistente de VPLEX El siguiente paso del proceso de aprovisionamiento de almacenamiento a un ambiente VMware desde EMC VPLEX es la creación de un dispositivo VPLEX con el uso de la extensión que se creó en el paso anterior. El asistente que lleva a cabo este paso puede iniciarse desde la página de inicio de la herramienta de administración de GUI para EMC VPLEX. Si hace clic en la URL, Step 4: Create Devices from Extents, como se observa en la Figura 4, se crea una nueva ventana emergente que aparece en la Figura 9. Planificación de mejores prácticas 11\n12 Figura 9. Creación de un dispositivo VPLEX mediante una extensión En la figura, se puede observar que el asistente ofrece la posibilidad de crear un volumen virtual mediante el dispositivo VPLEX (el área resaltada en amarillo en la Figura 9). La opción, que está seleccionada de manera predeterminada, debe seleccionarse, salvo que esté planificado un volumen virtual que contenga varias extensiones o cuando se crean dispositivos para utilizarlos en ambientes VPLEX Metro. Siempre que sea posible, el volumen virtual para ambientes VMware se debe crear mediante mapeo de uno a uno, es decir, un solo volumen virtual para cada extensión. El objetivo principal de esto es mantener el mayor nivel de simplicidad de la infraestructura. Sin embargo, a fin de mostrar el asistente para crear volúmenes virtuales, como se observa en la Figura 9, para el ejemplo utilizado en este white paper, se creó un dispositivo VPLEX sin crear un volumen virtual. Un volumen virtual se puede crear con el uso de uno o más dispositivos VPLEX. La Figura 10 muestra el asistente para crear volúmenes virtuales. En la figura, se observa que el dispositivo VPLEX creado en el paso anterior es el nombre del volumen de almacenamiento precedido por device_. Figura 10. Creación de volúmenes virtuales desde dispositivos VPLEX El volumen virtual se puede exponer a la plataforma de virtualización VMware, como se explicó anteriormente, mediante la creación de una vista de almacenamiento al combinar los objetos Iniciadores registrados, Puertos VPLEX y Volúmenes virtuales. Para ello, el WWN de los iniciadores en servidores VMware ESX Server debe registrarse primero en EMC VPLEX. La pantalla que se muestra en la Figura 11 aparece cuando se hace clic en la URL Step 6: Register Initiators. Planificación de mejores prácticas 12\n13 Figura 11. Lista de iniciadores que se registraron e iniciaron sesión en EMC VPLEX Cuando se lleva a cabo la zonificación de los iniciadores a los puertos front-end EMC VPLEX, estos inician sesión automáticamente en EMC VPLEX. Como se observa en la Figura 11, estos iniciadores se muestran con el prefijo UNREGISTERED- seguido del WWPN del iniciador. Sin embargo, los iniciadores también pueden registrarse manualmente antes de que se lleve a cabo su zonificación a los puertos front-end VPLEX. Se debe seleccionar el botón resaltado en verde en la Figura 11 para ejecutar esta operación. Los iniciadores que iniciaron sesión en EMC VPLEX pueden registrarse resaltando el iniciador no registrado y haciendo clic en el botón Register. Esto se muestra en la Figura 12. El recuadro de la figura muestra la ventana que se abre cuando se hace clic en el botón Register. El recuadro también muestra la funcionalidad que ofrece EMC VPLEX para asignar un nombre sencillo al iniciador no registrado y para seleccionar un tipo de host para el iniciador que se desea registrar. Planificación de mejores prácticas 13\n14 Figura 12. Registro de las HBA de VMware en EMC VPLEX El último paso para el aprovisionamiento de almacenamiento de EMC VPLEX al ambiente VMware es la creación de la vista de almacenamiento. Para realizar este paso, se debe seleccionar el último asistente (Step 7: Create Storage Views) en la página de inicio del sistema de administración de VPLEX. La Figura 13 muestra la ventana que se abre cuando se selecciona el último paso en la página de inicio. El panel izquierdo de la ventana muestra los pasos que se deben ejecutar para crear una vista de almacenamiento. La implementación de los pasos del asistente provisiona los volúmenes virtuales adecuados a la plataforma de virtualización VMware mediante el conjunto definido de puertos frontend VPLEX. Tenga en cuenta que la recomendación sobre los puertos VPLEX que se deben utilizar al conectar servidores VMware ESX Server a EMC VPLEX se analiza en la sección siguiente, Consideraciones sobre la conectividad. Figura 13. Asistente para crear una vista de almacenamiento VPLEX Planificación de mejores prácticas 14\n15 La Figura 14 muestra la vista de almacenamiento creada mediante el uso del asistente. En la figura, se resalta el WWN del volumen virtual que se expone por medio de la vista. La plataforma de virtualización VMware utiliza esta información a fin de identificar los dispositivos. Figura 14. Visualización de los detalles de una vista de almacenamiento mediante la interfaz de administración VPLEX El almacenamiento recientemente provisionado puede detectarse en servidores VMware ESX Server mediante la ejecución de un nuevo examen del bus SCSI. El resultado del análisis se muestra en la Figura 15. Se puede observar que VMware ESX Server tiene acceso a un dispositivo con el WWN a001b Una comparación rápida del WWN con la información resaltada en verde en la Figura 14 confirma que el dispositivo detectado por VMware ESX Server es efectivamente el volumen virtual VPLEX recientemente provisionado. En la figura, también se muestra como 00:01:44 el identificador único organizacional (OUI) FC para los dispositivos EMC VPLEX. Figura 15. Detección del almacenamiento VPLEX recientemente provisionado en VMware ESX Server Planificación de mejores prácticas 15\n16 Después de que los servidores VMware ESX Server detectan el dispositivo VPLEX, se pueden utilizar para crear un file system VMware (almacén de datos) o como un RDM. Sin embargo, para lograr un performance óptimo, resulta importante garantizar que las operaciones de I/O dirigidas a EMC VPLEX se ajusten a un límite de bloque de 64 KB. Además, en determinados escenarios de fallas, existe una pequeña probabilidad de que se produzcan daños en los datos cuando las operaciones de I/O dirigidas a EMC VPLEX no están ajustadas. Por lo tanto, EMC requiere que toda la actividad de I/O del sistema operativo host dirigida a EMC VPLEX se ajuste a un límite de 64 KB. El file system VMware creado mediante VMware Infrastructure Client o vsphere Client se adapta automáticamente a los bloques del file system. Sin embargo, una partición mal ajustada en un sistema operativo huésped puede afectar negativamente el performance, y como se mencionó anteriormente, en determinadas circunstancias puede ocasionar daños en los datos. Por lo tanto, resulta importante asegurarse de que todas las particiones creadas en el sistema operativo huésped (ya sea un disco virtual presentado desde un file system VMware o un RDM) se ajusten a un múltiplo de 64 KB. Consideraciones sobre la conectividad EMC VPLEX presenta un nuevo tipo de paradigma de federación de almacenamiento que permite un aumento de la resiliencia, el performance y la disponibilidad. En el párrafo siguiente, se plantean las recomendaciones para la conexión de servidores VMware ESX Server a EMC VPLEX. Las recomendaciones garantizan el nivel más alto de conectividad y disponibilidad de la plataforma de virtualización VMware, incluso durante operaciones anormales. Como mejor práctica, cada VMware ESX Server en el ambiente VMware vsphere o VMware Infrastructure debe tener al menos dos HBA físicas, y cada HBA debe estar conectada a por lo menos dos puertos front-end en distintos directores de EMC VPLEX. Esta configuración garantiza el uso continuo de todas las HBA en VMware ESX Server, incluso si uno de los puertos front-end de EMC VPLEX queda offline para eventos de mantenimiento planificados o interrupciones no planificadas. Cuando una configuración de un solo motor VPLEX se conecta al ambiente VMware vsphere o VMware Infrastructure, cada HBA debe conectarse a los puertos front-end proporcionados en los directores A y B dentro del motor VPLEX. La conectividad a los puertos front-end VPLEX debe comprender, en primer lugar, la conexión de hosts únicos al puerto 0 de cada módulo de I/O que emula los directores front-end antes de conectar hosts adicionales a los puertos restantes del módulo de I/O. En la Figura 16, se muestra un ejemplo esquemático del diagrama de cableado para una plataforma de virtualización VMware de cuatro nodos conectada a un solo motor VPLEX. Planificación de mejores prácticas 16\n17 Figura 16. Conexión de un servidor VMware vsphere a un cluster VPLEX de un solo motor Si se dispone de varios motores VPLEX, como es el caso de configuraciones de clusters VPLEX medianas y grandes, las HBA de los servidores VMware ESX Server se deben conectar a motores distintos. Por ejemplo, en la Figura 17, se muestra esquemáticamente el diagrama de conectividad para un cluster de servidores VMware ESX Server de cuatro nodos conectado a un cluster VPLEX de dos motores. Resulta importante tener en cuenta que, tanto en la Figura 16 como en la Figura 17, no se muestra la conectividad entre los motores VPLEX y los arreglos de almacenamiento. La conectividad de los motores VPLEX a los arreglos de almacenamiento debe seguir la recomendación de mejores prácticas para el arreglo. Un análisis detallado de las mejores prácticas para la conexión del almacenamiento back-end está fuera del alcance de este white paper. Los lectores interesados en el tema deben consultar EMC VPLEX Architecture and Deployment: Enabling the Journey to the Private Cloud TechBook. Planificación de mejores prácticas 17\n18 Figura 17. Conexión de servidores ESX a un cluster VPLEX de varios motores Cuando VMware ESX Server se conecta a EMC VPLEX usando las mejores prácticas analizadas en esta sección, el kernel de VMware asociará cuatro paths a cada dispositivo presentado desde el sistema. La Figura 18 muestra los paths disponibles y que utiliza el kernel de VMware para uno de los dispositivos federados presentados desde EMC VPLEX. Como se observa en la figura, el kernel de VMware puede tener acceso al dispositivo mediante uno de los cuatro paths posibles. Resulta importante tener en cuenta que EMC VPLEX es un arreglo activo/activo que permite el acceso simultáneo a cualquier dispositivo VPLEX desde cualquiera de los puertos front-end. El kernel de VMware reconoce esta situación de manera automática, y se resalta en verde en la Figura 18. Planificación de mejores prácticas 18\n19 Figura 18. Paths del kernel de VMware para un dispositivo VPLEX La conectividad de los servidores VMware ESX Server al cluster VPLEX de varios motores tiene capacidad de escalamiento a medida que se incorporan más motores. Las metodologías analizadas en esta sección garantizan el uso de todos los puertos front-end y proporcionan el máximo posible de performance y balanceo de carga para la plataforma de virtualización VMware. Múltiples paths y balanceo de carga VMware ESX Server proporciona funcionalidades nativas de failover de canal. De manera predeterminada, el servidor ESX para sistemas de almacenamiento activo/activo asigna el path que descubre primero a cualquier dispositivo con conexión SCSI como el path preferido con una política de failover fija. Este path se utiliza siempre como el path activo para enviar actividad de I/O a dicho dispositivo, a menos que no esté disponible debido a un evento planificado o no planificado. Los paths restantes que detecta VMware ESX Server para el dispositivo se emplean como un path de failover pasivo y solamente se utilizan si el path activo falla. Por lo tanto, los servidores VMware ESX Server colocan en cola de manera automática todas las operaciones de I/O en la primera HBA disponible del sistema, mientras que la otra HBA no se utiliza activamente, a menos que se detecte una falla en la HBA primaria. Este comportamiento genera una configuración no balanceada en el servidor ESX y en EMC VPLEX. Existen diversas maneras de enfrentar esta cuestión. El método más adecuado, como se menciona en las secciones siguientes, depende de la versión de VMware ESX Server y del software de múltiples paths utilizado. VMware ESX Server versión 3 y balanceo estático de carga Con VMware ESX Server versión 3, a los dispositivos EMC VPLEX se les suele asignar la política de administración de paths De uso reciente. Dado que VPLEX es un sistema activo/activo, es necesario estar seguro de que la política de failover de paths esté configurada como Fija. Asimismo, para lograr el balanceo de carga y múltiples paths, se debe ejecutar una asignación estática de paths preferidos alternativos a los dispositivos exportados desde EMC VPLEX. De acuerdo con las recomendaciones de la sección anterior para la conexión de servidores VMware ESX Server a EMC VPLEX, cada servidor Planificación de mejores prácticas 19\n20 ESX debe tener al menos cuatro paths independientes. Con este enfoque, el file system VMware que reside en EMC VPLEX debe tener sus paths balanceados equitativamente en función de los recursos disponibles. Tenga en cuenta que los cambios del path preferido se deben ejecutar en todos los servidores ESX que tengan acceso a los dispositivos VPLEX. El path preferido se puede establecer mediante las utilerías de líneas de comandos o VMware Infrastructure Client. En la Figura 19, se muestra un ejemplo de esto. La Figura 20 muestra la configuración del path preferido para dos almacenes de datos, cada uno de los cuales reside en un dispositivo EMC VPLEX presentado desde los puertos front-end A0-FC00, A1-FC00, B0-FC00 y B1-FC00. En la figura, se observa que se ha modificado el path preferido para el segundo almacén de datos para usar la segunda HBA. Figura 19. Configuración del path preferido en VMware ESX Server versión 3 Figura 20. Dispositivos EMC VPLEX con balanceo estático de carga en WMware ESX Server versión 3 VMware ESX Server versión 4 y NMP VMware ESX Server versión 4 incluye funcionalidades avanzadas de balanceo de carga y administración de paths expuestas por medio de las políticas del tipo Fija, Round-robin y De uso reciente. La política predeterminada que utiliza el kernel de ESX para arreglos activos/activos es Fija. Sin embargo, para la mayoría de los arreglos activos/activos, como los arreglos EMC Symmetrix, la más adecuada es la política round-robin. No obstante, las funciones avanzadas de administración de caché que proporciona EMC VPLEX pueden verse interrumpidas por el uso de un simple algoritmo de balanceo de carga por la política round-robin. Por lo tanto, para VMware ESX Server versión 4 conectado a EMC VPLEX, EMC recomienda el uso de la política Fija con balanceo Planificación de mejores prácticas 20\n21 estático de carga, similar al recomendado para VMware ESX Server versión 3. Además, las modificaciones en el path preferido deben realizarse en todos los servidores ESX que tienen acceso a los dispositivos VPLEX. El path preferido en VMware ESX Server versión 4 se puede establecer mediante vsphere Client. La Figura 21 muestra el procedimiento que se puede utilizar para establecer el path preferido para un disco físico en un ambiente VMware vsphere. La Figura 22 muestra la configuración del path preferido para dos almacenes de datos, cada uno de los cuales reside en un dispositivo EMC VPLEX presentado desde los puertos front-end A0-FC00, A1-FC00, B0-FC00 y B1-FC00. Figura 21. Configuración del path preferido en VMware ESX Server versión 4 Figura 22. Dispositivos EMC VPLEX con balanceo estático de carga en VMware ESX Server versión 4 VMware ESX Server versión 4 con PowerPath/VE EMC PowerPath /VE ofrece funciones de múltiples paths de PowerPath para optimizar los ambientes virtuales VMware vsphere. Con PowerPath/VE, es posible estandarizar la administración de paths en ambientes virtuales y físicos heterogéneos. PowerPath/VE permite automatizar la utilización óptima de servidores, almacenamiento y paths en un ambiente virtual dinámico. Mediante la hiperconsolidación, un ambiente virtual puede tener cientos y hasta miles de máquinas virtuales independientes en ejecución, incluidas máquinas virtuales con diversos niveles de intensidad de la actividad de I/O. Las aplicaciones con mucha actividad de I/O pueden interrumpir las operaciones de I/O de otras aplicaciones y, antes de la disponibilidad de PowerPath/VE, como se explicó en secciones anteriores, el balanceo de carga en un sistema host ESX debía configurarse manualmente para corregir este problema. Las operaciones manuales de balanceo de carga para garantizar que todas las máquinas Planificación de mejores prácticas 21\n22 virtuales reciban sus tiempos de respuesta necesarios individuales llevan mucho tiempo y son logísticamente difíciles de lograr de manera eficiente. PowerPath/VE funciona con VMware ESX y ESXi como un plug-in de múltiples paths (MPP) que proporciona funcionalidades avanzadas de administración de paths a los hosts ESX y ESXi. PowerPath/VE se soporta con vsphere (VMware ESX Server versión 4) únicamente. Las versiones anteriores de ESX no cuentan con el PSA, que requiere PowerPath/VE. PowerPath/VE se instala como un módulo de kernel en el host vsphere. Como se muestra en la Figura 23, PowerPath/VE se conecta al marco de trabajo del agrupamiento de I/O de vsphere para ofrecer las funcionalidades avanzadas de múltiples paths de PowerPath (balanceo dinámico de carga y failover automático) a la plataforma VMware vsphere. Figura 23. API de PowerPath/VE vstorage para el plug-in de múltiples paths En el centro de la administración de paths de PowerPath/VE, se encuentra el software residente en el servidor insertado entre el nivel del driver del dispositivo SCSI y el resto del sistema operativo. Este software de driver crea un único pseudodispositivo para un determinado volumen de arreglos (LUN), independientemente de la cantidad de paths físicos en los que aparece. El pseudodispositivo, o volumen lógico, representa todos los paths físicos a un dispositivo determinado. Luego, se utiliza para crear un file system VMware o para el mapeo de dispositivos raw (RDM). Estas entidades se pueden usar para el acceso a bases de datos y aplicaciones. El valor de PowerPath/VE reside fundamentalmente en su arquitectura y su posición en el agrupamiento de I/O. PowerPath/VE se ubica encima de la HBA, lo cual permite el soporte heterogéneo de sistemas operativos y arreglos de almacenamiento. Mediante la integración con los drivers de I/O, todas las operaciones de I/O se ejecutan por medio de PowerPath y permiten que sea un único punto de control y administración de I/O. Dado que PowerPath/VE reside en el kernel de ESX, reside debajo del nivel del SO huésped, de aplicaciones, de bases de datos y de file systems. La posición exclusiva de PowerPath/VE en el agrupamiento de I/O lo convierte en un punto de control y capacidad de administración de la infraestructura, lo que ofrece más valor al agrupamiento. Funciones de PowerPath/VE PowerPath/VE soporta las siguientes funciones: Balanceo dinámico de carga. PowerPath está diseñado para usar todos los paths en todo momento. PowerPath distribuye las solicitudes de I/O a un dispositivo lógico entre todos los paths disponibles, en lugar de requerir un solo path para soportar toda la carga de la actividad de I/O. Restauración automática de paths. La restauración automática periódica reasigna los dispositivos lógicos cuando se restauran los paths a partir de un estado de falla. Finalizada la Planificación de mejores prácticas 22\n23 restauración, los paths vuelven a balancear automáticamente la actividad de I/O en todos los canales activos. Asignación de prioridades de dispositivos. La asignación de una prioridad alta para uno o varios dispositivos mejora el performance de la actividad de I/O a expensas de los dispositivos restantes, mientras que, por otra parte, se mantiene el mejor balanceo de carga posible en todos los paths. Esto resulta especialmente útil cuando se reúnen varias máquinas virtuales en un host con distintos requerimientos de disponibilidad y performance de las aplicaciones. Optimización automatizada del performance. PowerPath/VE identifica automáticamente el tipo de arreglo de almacenamiento y configura el modo de optimización de performance más alto de manera predeterminada. Para VPLEX, el modo predeterminado es Adaptive. Recuperación y failover de paths dinámicos. Si un path falla, PowerPath/VE redistribuye el tráfico de I/O de dicho path a los paths en funcionamiento. PowerPath/VE interrumpe el envío de operaciones de I/O al path fallido y busca un path alternativo en actividad. Si un path activo está disponible, PowerPath/VE redirige la actividad de I/O a lo largo de dicho path. PowerPath/VE puede compensar varias fallas en el canal de I/O (por ejemplo, HBA, cables de fibra óptica, switches Fibre Channel, puertos de arreglos de almacenamiento). Monitoreo y creación de informes sobre estadísticas de I/O. Mientras PowerPath/VE realiza el balanceo de carga de la actividad de I/O, mantiene estadísticas de todas las operaciones de I/O de todos los paths. El administrador puede visualizar estas estadísticas mediante rpowermt. Pruebas automáticas de path. PowerPath/VE prueba de manera periódica tanto los paths activos como los paths inactivos. Al probar paths activos que pueden encontrarse en un estado de inactividad, es posible identificar un path fallido antes de que una aplicación dirija las operaciones de I/O hacia este. Al marcar el path como fallido antes de que la aplicación lo detecte, se reducen el tiempo de espera agotado y las demoras ocasionadas por los reintentos. Mediante la prueba de los paths identificados como fallidos, PowerPath/VE podrá restaurar el servicio de estos de manera automática después de que hayan pasado la prueba. La carga de I/O se balanceará automáticamente entre todos los paths activos disponibles. Administración de PowerPath/VE PowerPath/VE utiliza un conjunto de comandos, denominado rpowermt, para monitorear, administrar y configurar PowerPath/VE for vsphere. La sintaxis, los argumentos y las opciones son muy similares a los de los comandos powermt tradicionales que se utilizan en todas las demás plataformas de sistemas operativos soportadas por PowerPath Multipathing. Existe una diferencia importante: rpowermt es una herramienta de administración remota. No todas las instalaciones de vsphere cuentan con una interfaz de consola de servicio. A fin de administrar un host ESXi, los clientes tienen la opción de usar vcenter Server o vcli (también denominadas Herramientas remotas VMware) en un servidor remoto. PowerPath/VE for vsphere utiliza la utilería de línea de comandos rpowermt tanto para ESX como para ESXi. PowerPath/VE for vsphere no se puede administrar en el host ESX en sí. No existe una GUI local ni remota para PowerPath en ESX. Los administradores deben designar un SO huésped o una máquina física para administrar uno o varios hosts ESX. La utilería, rpowermt, se soporta en Windows 2003 (de 32 bits) y Red Hat 5 Update 2 (de 64 bits). Cuando el servidor host vsphere se conecta a EMC VPLEX, el módulo de kernel de PowerPath/VE que ejecuta el host vsphere asocia todos los paths a cada dispositivo presentado desde el arreglo y asigna un nombre de pseudodispositivo (como se analizó anteriormente). Se puede ver un ejemplo de esto en la Figura 24, que muestra la salida de rpowermt display host=x.x.x.x dev=emcpower11. Observe en la salida que el dispositivo tiene cuatro paths y muestra el modo de optimización predeterminado para los dispositivos VPLEX: ADaptive. Sin embargo, como se analizó en la sección anterior, el sistema avanzado de administración y coherencia de caché utilizado por EMC VPLEX no se aprovecha completamente cuando se utiliza la política ADaptive. Por lo tanto, EMC recomienda cambiar de ADaptive a StreamIO (si) la política de administración de paths de PowerPath para todos los dispositivos VPLEX. En el futuro, los algoritmos de PowerPath asignarán automáticamente la política adecuada para los dispositivos EMC VPLEX que detecte el sistema. Planificación de mejores prácticas 23\n24 Figura 24. Salida del comando rpowermt display en un dispositivo VPLEX La política de administración de paths para los dispositivos VPLEX se puede cambiar a StreamIO mediante el comando rpowermt. La Figura 25 muestra el comando para ejecutar el cambio. La figura también muestra la política nueva vigente para el dispositivo emcpower11 que se mostró en la Figura 24. Figura 25. Cambio de la política de administración de paths de PowerPath/VE para los dispositivos VPLEX El comando que se muestra en la Figura 25 utiliza la definición de clases para los dispositivos VPLEX (Invista ) para modificar la política. En el caso excepcional de que la plataforma de virtualización VMware se exponga tanto a dispositivos VPLEX como a dispositivos Invista, el cambio en la política de administración de paths deberá ejecutarse en cada dispositivo. Para obtener más información sobre cómo ejecutar esta tarea y sobre los comandos rpowermt y su salida, consulte PowerPath/VE for VMware vsphere Installation and Administration Guide, disponible en Powerlink. Resulta importante destacar que, a medida que más motores VPLEX se vuelven disponibles en un cluster, la conectividad tiene la capacidad de escalar según sea necesario. PowerPath/VE soporta hasta 32 paths a un dispositivo. Estas metodologías de conectividad garantizan el uso de todos los procesadores y directores front-end, lo que proporciona el máximo posible de performance y balanceo de carga para los hosts vsphere conectados a EMC VPLEX en combinación con PowerPath/VE. Migración de ambientes VMware existentes a VPLEX Es posible la migración de las implementaciones existentes de las plataformas de virtualización VMware a ambientes VPLEX. Existen diversas alternativas que se pueden aprovechar. El método más sencillo para llevar a cabo la migración a un ambiente VPLEX consiste en usar Storage VMotion. Sin embargo, esta técnica es viable solo si el arreglo de almacenamiento tiene suficiente almacenamiento libre para admitir el almacén de datos más grande en el ambiente VMware. Asimismo, el uso de Storage VMotion puede resultar tedioso si existen cientos de máquinas virtuales o terabytes que se deben convertir, o si las máquinas virtuales tienen snapshots existentes o si la plataforma de virtualización VMware consta de VMware ESX Server versión 3.0 o superior. En estos escenarios, sería adecuado aprovechar la funcionalidad de EMC VPLEX para encapsular los dispositivos Planificación de mejores prácticas 24\n25 existentes. Sin embargo, esta metodología es disruptiva y requiere interrupciones planificadas de la plataforma de virtualización VMware. Migraciones no disruptivas mediante Storage VMotion Figura 26 muestra los almacenes de datos disponibles en VMware ESX Server versión 3.5 administrado por vsphere vcenter Server. La vista está disponible mediante el plug-in del lado del cliente EMC Virtual Storage Integrator que extiende la información relacionada con el almacenamiento que se muestra desde vsphere Client. Se puede encontrar más información acerca de EMC Virtual Storage Integrator en la documentación enumerada en la sección En la Figura 26, se puede observar que la máquina virtual W2K8 VM1 (VI3) reside en el almacén de datos DataStore_1 albergado en el dispositivo 4EC en un arreglo Symmetrix VMAX. El recuadro de la figura muestra la versión del kernel de ESX (3.5 compilación ) para el servidor Figura 26. Detalles del dispositivo de almacenamiento de EMC que muestra EMC Storage Viewer La Figura 27 muestra los dispositivos visibles en el servidor ESX. Se puede observar que existen dos dispositivos con la identificación de producto Invista, pero sin detalles. Esto sucede porque EMC Virtual Storage Integrator en esta instancia no cuenta con la funcionalidad para resolver los dispositivos presentados desde EMC VPLEX. En la figura, también se puede ver el número de NAA para los dispositivos. Como se explicó anteriormente, el OUI FC, 00:01:44, corresponde a los dispositivos EMC VPLEX. Por lo tanto, se puede concluir a partir de la imagen que VMware ESX Server se presenta con dispositivos de arreglos EMC Symmetrix VMAX y EMC VPLEX. Planificación de mejores prácticas 25\n26 Figura 27. Visualización de dispositivos EMC VPLEX presentados a un cluster de servidores VMware ESX Server La migración de los datos de los arreglos Symmetrix VMAX al área de almacenamiento presentada desde VPLEX se puede llevar a cabo mediante Storage VMotion una vez creados los almacenes de datos adecuados en los dispositivos presentados desde VPLEX. La Figura 28 muestra los pasos que deben realizarse para iniciar la migración de una máquina virtual desde Datastore_1 al almacén de datos de destino, Target_1, que reside en un dispositivo VPLEX. Es importante tener en cuenta que si bien se utilizó VMware ESX Server versión 3.5 para mostrar el procedimiento de migración, el mismo proceso se aplica a los servidores ESX que ejecutan la versión 4.0 o posterior. Asimismo, también se debe considerar que el asistente de migración que se muestra en la figura 28 esta disponible solo cuando se utiliza vcenter Server versión 4.0 o superior. La funcionalidad de Storage VMotion está disponible a través de la utilería de línea de comandos para vcenter Server versión 2.5. El análisis detallado de Storage VMotion está fuera del alcance de este white paper. Se puede encontrar información detallada acerca de Storage VMotion en la documentación de VMware que se enumera en la sección Referencias. Planificación de mejores prácticas 26\n27 Figura 28. Uso de Storage VMotion para migrar máquinas virtuales a dispositivos VPLEX Migración mediante la encapsulación de dispositivos existentes Como se mencionó anteriormente, si bien Storage VMotion cuenta con la funcionalidad de llevar a cabo migraciones no disruptivas desde una implementación existente de VMware hasta EMC VPLEX, es posible que no siempre sea una herramienta viable. En estos casos, se pueden aprovechar las funcionalidades de encapsulación de EMC VPLEX. El proceso, sin embargo, es disruptivo, pero la duración de la interrupción se puede minimizar mediante planificación y ejecución adecuadas. Es necesario seguir los siguientes pasos para llevar a cabo el encapsulamiento y la migración de una implementación existente de VMware. 1. Lleve a cabo la zonificación de los puertos back-end de EMC VPLEX a los puertos front-end del arreglo de almacenamiento que ofrece actualmente los recursos de almacenamiento. 2. El paso siguiente debe ser modificar el enmascaramiento de LUN en el arreglo de almacenamiento de manera que EMC VPLEX tenga acceso a los dispositivos que albergan los almacenes de datos de VMware. En el ejemplo que se utilizó en la sección anterior, los dispositivos 4EC (para Datastore_1) y 4F0 (para Datastore_2) deben enmascararse para EMC VPLEX. La Figura 29 muestra los dispositivos visibles para EMC VPLEX después de haber realizado los cambios de enmascaramiento y un nuevo examen del arreglo de almacenamiento en EMC VPLEX. En la figura, también se observan la salida de SYMCLI de los dispositivos Symmetrix VMAX y los WWN correspondientes. Una comparación rápida muestra claramente que EMC VPLEX tiene acceso a los dispositivos que albergan los almacenes de datos que deben encapsularse. Planificación de mejores prácticas 27\n28 Figura 29. Detección de dispositivos que se deben encapsular en EMC VPLEX 3. Después de que los dispositivos están visibles para EMC VPLEX, se deben reclamar. Este paso se muestra en la Figura 30. El indicador -appc durante el proceso de reclamación garantiza la preservación del contenido del dispositivo que se reclama y la encapsulación del dispositivo para su uso posterior en EMC VPLEX. Figura 30. Encapsulamiento de dispositivos en EMC VPLEX mientras se preservan los datos existentes 4. Después de la reclamación de los dispositivos, se debe crear una sola extensión que abarque todo el disco. La Figura 31 muestra este paso para los dos almacenes de datos que se encapsulan en este ejemplo. Planificación de mejores prácticas 28\n29 Figura 31. Creación de extensiones en volúmenes de almacenamiento encapsulados que reclama VPLEX 5. Se debe crear un dispositivo VPLEX (dispositivo local) con un solo miembro RAID 1 mediante el uso de la extensión creada en el paso anterior. Esto se muestra en los dos almacenes de datos, Datastore_1 y Datastore_2, albergados en los dispositivos 4EC y 4F0, respectivamente, en la Figura 32. Se debe repetir el paso para todos los dispositivos del arreglo de almacenamiento que deben encapsularse y exponerse al ambiente VMware. Figura 32. Creación de un dispositivo VPLEX protegido por RAID 1 en dispositivos VMAX encapsulados 6. Se debe crear un volumen virtual en cada uno de los dispositivos VPLEX generados en el paso anterior. Esto se muestra en la Figura 33 para los almacenes de datos Datastore_1 y Datastore_2 VMware. Planificación de mejores prácticas 29\n30 Figura 33. Creación de volúmenes virtuales en VPLEX para exponer a la plataforma de virtualización VMware 7. Es posible crear una vista de almacenamiento en EMC VPLEX mediante el registro manual del WWN de las HBA en los servidores VMware ESX Server que forman parte del dominio de virtualización VMware. La vista de almacenamiento se debe crear con anticipación para permitir que la plataforma de virtualización VMware tenga acceso a los volúmenes virtuales que se crearon en el paso 6. Mediante esta acción, se puede minimizar la interrupción del servicio durante el switchover del arreglo de almacenamiento original a EMC VPLEX. En la Figura 34, se muestra un ejemplo de este paso para el ambiente utilizado en este estudio. Figura 34. Creación de una vista de almacenamiento para presentar dispositivos encapsulados a los servidores VMware ESX Server 8. Al mismo tiempo que se realizan las operaciones en EMC VPLEX, se deben crear nuevas zonas que permitan que los servidores VMware ESX Server que participan en la migración tengan acceso a los puertos front-end EMC VPLEX. Estas zonas también se deben incorporar al conjunto de zonas correspondiente. Además, las zonas que permiten el acceso de VMware ESX Server al arreglo de almacenamiento cuyos dispositivos se encuentran en proceso de encapsulamiento deben eliminarse del conjunto de zonas. Sin embargo, el conjunto de zonas modificado no se debe activar hasta que surja la ventana de mantenimiento cuando las máquinas virtuales VMware se puedan cerrar. 9. Cuando la ventana de mantenimiento está abierta, todas las máquinas virtuales que pueden verse afectadas por la migración se deben cerrar primero de manera correcta. Esto se puede realizar mediante VMware Infrastructure Client, vsphere Client o las utilerías de líneas de comandos que aprovechan VMware SDK. 10. Los dispositivos presentados desde el sistema VPLEX albergan el almacén de datos original. Sin embargo, los hosts VMware ESX no montan los almacenes de datos de manera automática, dado que VMware ESX considera los almacenes de datos como un snapshot debido a que el Planificación de mejores prácticas 30\n31 WWN de los dispositivos expuestos por medio del sistema VPLEX difiere del WWN de los dispositivos presentados desde el sistema Symmetrix VMAX. VMware vsphere permite que el proceso de repetición de identificación de los almacenes de datos considerados snapshots se ejecute en cada dispositivo. Esto reduce el riesgo de volver a firmar erróneamente los dispositivos encapsulados del sistema VPLEX. El uso del montaje persistente también brinda otras ventajas, como la conservación del historial de todas las máquinas virtuales. Por lo tanto, para un ambiente homogéneo vsphere, EMC recomienda el uso de montajes persistentes para los almacenes de datos de VMware encapsulados por VPLEX. Para ambientes VMware que contienen VMware ESX versión 3.5 o superior, se debe omitir este paso. Active el conjunto de zonas creado en el paso 8. Un nuevo examen manual del bus SCSI en los servidores VMware ESX Server debe eliminar los dispositivos originales y agregar los dispositivos encapsulados presentados desde el sistema VPLEX. La Figura 35 muestra un ejemplo de esto para un ambiente VMware vsphere. La figura muestra que todas las máquinas virtuales originales en el ambiente están marcadas como inaccesibles. Esto sucede debido a que los almacenes de datos, Datastore_1 y Datastore_2, creados en los dispositivos presentados desde el sistema WMAX, ya no están disponibles. Figura 35. Nuevo análisis del bus SCSI en servidores VMware ESX Server En la figura siguiente, se muestran los resultados posteriores al montaje persistente de los almacenes de datos presentados desde EMC VPLEX. Se puede observar que todas las máquinas virtuales que no estaban accesibles están disponibles ahora. El montaje persistente de los almacenes de datos que se consideran snapshots conserva el UUID del almacén de datos y la etiqueta. Dado que se hace referencia cruzada de las máquinas virtuales mediante el UUID de los almacenes de datos, el montaje persistente permite a vcenter Server volver a descubrir las máquinas virtuales que anteriormente se consideraban inaccesibles. Los pasos del 11 al 14, que se enumeran a continuación, no se aplican a ambientes homogéneos vsphere y se deben omitir. Planificación de mejores prácticas 31\n32 Figura 36. Montaje persistente de almacenes de datos en dispositivos VPLEX encapsulados 11. Si el ambiente VMware cuenta con VMware ESX versión 3.5 o superior (incluso si está administrado por VMware vcenter Server versión 4), se recomienda volver a identificar los dispositivos encapsulados presentados desde EMC VPLEX. Esta recomendación se basa en el hecho de que, en estas versiones de VMware ESX Server, el proceso de repetición de identificación de dispositivos considerados snapshots no es selectivo y no se puede revertir. VMware ESX Server versión 4.0 o posterior proporciona a los usuarios un mecanismo para volver a identificar selectivamente los dispositivos que se consideran snapshots. Las máquinas virtuales albergadas en los almacenes de datos se deben eliminar del inventario de vcenter Server. Esto se puede realizar mediante Virtual Infrastructure Client, vsphere Client o las utilerías de líneas de comandos que aprovechan VMware SDK. Tenga en cuenta que cuando se elimina el registro de las máquinas virtuales, toda la información del historial de la máquina virtual se elimina de la base de datos de Virtual Center. 12. Cambie el indicador Advanced Settings, LVM.EnableResignature, en uno de los hosts VMware ESX para repetir el proceso de identificación de los almacenes de datos y activar el conjunto de zonas creado en el paso 8. En esta instancia, se debe activar el conjunto de zonas creado en el paso 8. Un nuevo examen manual del bus SCSI en los servidores VMware ESX Server debe eliminar los dispositivos originales y agregar los dispositivos encapsulados presentados desde EMC VPLEX. La Figura 37muestra los almacenes de datos después de completar el proceso de repetición de identificación. Como se puede observar en la figura, se ha agregado el prefijo snap-xxxxxxxx a la etiqueta original de los almacenes de datos. Planificación de mejores prácticas 32\n33 Figura 37. Repetición del proceso de identificación de almacenes de datos en dispositivos VPLEX encapsulados 13. Después de la detección de los dispositivos VPLEX y de la repetición del proceso de identificación de los almacenes de datos VMware, el parámetro avanzado LVM.EnableResignature debe configurarse en Las máquinas virtuales que no se registraron en el paso 10 se pueden reincorporar al inventario de vcenter Server mediante Virtual Infrastructure Client, vsphere Client o las utilerías de líneas de comandos en función de VMware SDK. En la Figura 38, se puede ver un ejemplo de esto. Figura 38. Incorporación a vcenter Server de máquinas virtuales de dispositivos VPLEX con repetición del proceso de identificación 15. Después de identificar o registrar las máquinas virtuales de manera correcta, se pueden encender. Planificación de mejores prácticas 33\n34 El proceso descrito anteriormente utilizó la interfaz de línea de comando de VPLEX para ejecutar la operación de administración en EMC VPLEX. Sin embargo, se pueden ejecutar las mismas operaciones con el uso de la interfaz de administración GUI que proporciona VPLEX. Implementaciones de VMware en un ambiente VPLEX Metro EMC VPLEX traspasa las barreras físicas de los data centers y permite a los usuarios tener acceso a los datos en distintas ubicaciones geográficas de manera simultánea 1. Esta funcionalidad en un contexto de VMware activa funciones que no estaban disponibles anteriormente. En concreto, la capacidad de acceso simultáneo al mismo conjunto de dispositivos independientemente de la ubicación física permite clusters distantes desde el punto de vista geográfico en función de la plataforma de virtualización VMware 2. Esto permite el uso compartido de carga transparente entre varios sites y brinda la flexibilidad de migrar cargas de trabajo entre sites con anticipación a eventos planificados, como el mantenimiento de hardware. Más aún, en los casos de eventos no planificados que causan interrupciones de servicios en uno de los data centers, los servicios fallidos se pueden reiniciar, de manera rápida y sencilla, y con un mínimo de esfuerzo, en el site no afectado. No obstante, el diseño del ambiente VMware debe responder ante diversos escenarios de fallas posibles y moderar el riesgo relacionado con la interrupción de los servicios. En los párrafos siguientes, se analizan las mejores prácticas para el diseño del ambiente VMware para garantizar una solución óptima. Para obtener más información sobre la configuración de EMC VPLEX Metro, los lectores deben consultar el TechBook EMC VPLEX Architecture and Deployment: Enabling the Journey to the Private Cloud, disponible en Powerlink. Configuración de clusters VMware Un cluster VMware HA utiliza un heartbeat para determinar si los nodos pares del cluster están accesibles y tienen capacidad de respuesta. En caso de que se produzca una falla en la comunicación, el software VMware HA que se ejecuta en VMware ESX Server suele utilizar el gateway predeterminado para el kernel de VMware a fin de determinar si debe llevar a cabo su propio aislamiento. Este mecanismo es necesario porque no es posible determinar desde el punto de vista programático si una interrupción en la comunicación se debe a una falla en el servidor o a una falla en la red. La misma cuestión fundamental presentada anteriormente (si la falta de conectividad entre los nodos de los clusters VPLEX se debe a una falla de comunicación de la red o a una falla del site) se aplica a los clusters VPLEX que están separados por distancias geográficas. Una falla en la red se maneja en EMC VPLEX mediante la suspensión automática de toda la actividad de I/O hacia un dispositivo ( desconectado ) en uno de los dos sites en función de un conjunto de reglas predefinidas. Las operaciones de I/O en el otro site dirigidas hacia el mismo dispositivo continúan normalmente. Además, dado que las reglas se aplican a cada dispositivo, es posible contar con dispositivos activos en ambos sites en caso de partición de la red. La imposición de las reglas para minimizar el impacto de las interrupciones de red realmente genera un impacto en caso de una falla en el site. En este caso, según las reglas que definen el site que se desconecta en caso de una interrupción en las comunicaciones, el cluster VPLEX en el site no afectado suspende automáticamente las operaciones de I/O que se dirigen hacia algunos de los dispositivos del site que no tuvo problemas. Para enfrentar esta cuestión, el software de VPLEX presenta la funcionalidad de reanudar manualmente las operaciones de I/O que se dirigen hacia los dispositivos desconectados. Sin embargo, un análisis más detallado del procedimiento para ejecutar estas operaciones está fuera del alcance de este white paper. EMC VPLEX Architecture and Deployment: Enabling the Journey to the Private Cloud TechBook para obtener más información sobre EMC Metro-Plex. La Figura 39 muestra la configuración de clusters recomendada para implementaciones de VMware que aprovechan los dispositivos presentados por medio de EMC VPLEX Metro. En la figura, se puede observar que la plataforma de virtualización VMware está dividida en dos clusters VMware independientes. Cada cluster incluye los servidores VMware ESX Server en cada data center físico (site A y site B). Sin embargo, los dos clusters VMware se administran bajo una sola entidad 1 Si bien la arquitectura de VPLEX está diseñada para soportar el acceso simultáneo a diversas ubicaciones, la primera versión del producto soporta una configuración de dos sites separados a una distancia síncrona. 2 La solución requiere la extensión de VLAN a distintos data centers físicos. Se pueden aprovechar tecnologías como Cisco Overlay Transport Virtualization (OTV) para proporcionar el servicio. Planificación de mejores prácticas 34\n35 Datacenter, que representa la combinación lógica de varios sites físicos que participan de la solución. La figura también muestra, en un recuadro, la configuración de cada cluster. El recuadro muestra que VMware DRS y VMware HA están activos en cada cluster, lo que limita el dominio de operaciones de estos componentes de la oferta de VMware a una única ubicación física. Figura 39. Configuración de clusters VMware que utilizan dispositivos de EMC VPLEX Metro Si bien la Figura 39 muestra solamente dos clusters VMware, se permite la división de los servidores VMware ESX Server en cada ubicación física entre varios clusters VMware. El objetivo de la configuración recomendada es evitar entremezclar los servidores ESX en diversas ubicaciones en un único objeto de cluster VMware. Los almacenes de datos VMware presentados a la representación lógica de los data centers físicos combinados (site A y site B) se muestran en la Figura 40. En esta figura, se observa que se presenta una cantidad de almacenes de datos VMware en ambos data centers 3. Por lo tanto, la separación lógica del dominio VMware HA y VMware DRS no afecta de ningún modo, como se explica en la sección siguiente, la funcionalidad de VMware VCenter Server para llevar a cabo la migración transparente de las máquinas virtuales que operan en el cluster designado para cada site a su site par. La figura también destaca que una configuración de VPLEX Metro no incluye el requerimiento de replicar todos los volúmenes virtuales creados en EMC VPLEX Metro a todas las ubicaciones de los data centers físicos 4. Sin embargo, las máquinas virtuales que se albergan en almacenes de datos encapsulados en volúmenes 3 La creación de un almacén de datos compartido que sea visible para los servidores VMware ESX Server en ambos sites es posible mediante la creación de un dispositivo distribuido en EMC VPLEX Metro. El análisis detallado de los procedimientos para crear dispositivos distribuidos está fuera del alcance de este white paper. Los lectores deben consultar el TechBook EMC VPLEX Architecture and Deployment Enabling the Journey to the Private Cloud para obtener más información. 4 Es posible presentar un volumen virtual que no esté replicado a clusters VMware en ambos sites. En dicha configuración, cuando la actividad de I/O generada en el site que no cuenta con una copia de los datos no está en la caché del cluster VPLEX en dicho site, se ejecuta por medio del arreglo de almacenamiento que alberga el volumen virtual. Esta configuración puede generar disminuciones de performance graves y no protege al Cliente en caso de eventos no planificados en el site que alberga la replicación del arreglo de almacenamiento o en caso de una migración única de máquinas virtuales entre data centers. Planificación de mejores prácticas 35\n36 virtuales con una sola copia de los datos y que se presentan al cluster VMware en dicha ubicación están vinculadas a ese site y no se pueden migrar sin interrupciones al segundo site mientras se proporciona protección contra los eventos no planificados. La necesidad de albergar un conjunto de máquinas virtuales en volúmenes virtuales no replicados puede estar impulsada por diversas razones, entre ellas, la importancia para el negocio de contar con máquinas virtuales albergadas en dichos almacenes de datos. Figura 40. Vista de almacenamiento de los almacenes de datos presentados a clusters VMware La Figura 41 es una ampliación de la información que se muestra en la Figura 40. Esta figura incluye información sobre las máquinas virtuales y los almacenes de datos en la configuración utilizada en este estudio. En esta figura, se muestra que un almacén de datos alberga máquinas virtuales que se ejecutan en una única ubicación física. Asimismo, se observa el WWN del dispositivo SCSI que alberga el almacén de datos Distributed_DSC_Site_A. La configuración del volumen virtual de VPLEX Metro con el WWN que se muestra en la Figura 41se exhibe en la Figura 42. La figura muestra que el volumen virtual se exporta a los hosts en el cluster VMware en el site A. Planificación de mejores prácticas 36\n37 Figura 41. Vista de los almacenes de datos y las máquinas virtuales utilizados en este estudio Figura 42. Información detallada sobre un volumen Metro-Plex presentado a un ambiente VMware Planificación de mejores prácticas 37\n38 La Figura 43 muestra las reglas aplicadas en el volumen virtual que alberga el almacén de datos Distributed_DSC_Site_A. En dicha figura, se puede observar que las reglas están configuradas para suspender las operaciones de I/O en el site B en caso de producirse una partición de la red. Por lo tanto, las reglas garantizan que si existe una partición de la red, las máquinas virtuales albergadas en el almacén de datos Distributed_DSC_Site_A no se vean afectadas. De manera similar, para las máquinas virtuales en el site B, las reglas están configuradas para garantizar que las operaciones de I/O dirigidas a dichos almacenes de datos no se vean afectadas en caso de producirse una partición de la red. Figura 43. Visualización de las reglas de desconexión en dispositivos VPLEX distribuidos Migración no disruptiva de máquinas virtuales con VMotion La Figura 44 es un ejemplo de la funcionalidad de migrar máquinas virtuales en ejecución entre el cluster y, en consecuencia, data centers físicos. La figura muestra claramente que, desde la perspectiva de VMware vcenter Server, la ubicación física de los data centers no incide en la funcionalidad de transferir las cargas de trabajo activas entre sites soportados por EMC VPLEX Metro. Planificación de mejores prácticas 38\n39 Figura 44. vcenter Server permite la migración activa de máquinas virtuales entre sites La Figura 45 muestra un snapshot durante la migración no disruptiva de una máquina virtual de un site a otro. La figura también muestra la consola de la máquina virtual durante el proceso de migración y destaca la ausencia de impacto en la máquina virtual durante el proceso. Figura 45. Evolución de VMotion entre dos sites físicos Resulta importante tener en cuenta que EMC no recomienda la migración de una sola máquina virtual de un site a otro, ya que afecta el paradigma analizado en los párrafos anteriores. Una migración parcial de las máquinas virtuales albergadas en un almacén de datos puede causar una interrupción innecesaria Planificación de mejores prácticas 39\n40 del servicio si se produce una partición de la red. Por ejemplo, después de una migración exitosa de la máquina virtual IOM02 que se muestra en la Figura 44 y la Figura 45, si existe una partición de red, las reglas vigentes en los dispositivos albergados en el almacén de datos suspenden las operaciones de I/O en el site en el que se está ejecutando la máquina virtual migrada. La suspensión de las operaciones de I/O genera una interrupción abrupta de los servicios proporcionados por IOM02. Para evitar este inconveniente, EMC recomienda la migración de todas las máquinas virtuales albergadas en un almacén de datos seguida de un cambio en las reglas vigentes para el dispositivo que alberga el almacén de datos afectado. Las reglas nuevas deben garantizar que la actividad de I/O dirigida al dispositivo continúe en el site en el que se produjo la migración. Cambio de la configuración de los volúmenes VPLEX Metro no replicados Como se mencionó en los párrafos anteriores, EMC VPLEX Metro no limita la configuración del volumen virtual exportado por el cluster. Una configuración de VPLEX Metro puede exportar una combinación de volúmenes virtuales replicados y no replicados. Por lo general, los requerimientos del negocio determinan el tipo de volumen virtual que se debe configurar. Sin embargo, si los requerimientos del negocio cambian, la configuración del volumen virtual en el que se albergan las máquinas virtuales se puede cambiar de manera no disruptiva por un volumen virtual replicado y se puede presentar a varios clusters VMware en distintas ubicaciones físicas para el acceso simultáneo. Planificación de mejores prácticas 40\n41 La Figura 46 muestra el almacén de datos Conversion_Datastore que actualmente está disponible solamente en un cluster albergado en un solo site (en este caso, el site A). Por lo tanto, las máquinas virtuales contenidas en este almacén de datos se pueden migrar de manera no disruptiva al segundo site disponible en la configuración 5 de VPLEX Metro, a menos que el acceso remoto esté activado para el dispositivo en el que se ha creado el almacén de datos, Conversion_Datastore, o que la configuración del dispositivo VPLEX se convierta en un dispositivo distribuido con copias de los datos en ambos sites. Figura 46. Almacén de datos VMware disponible en un único site en una configuración de Metro-Plex La Figura 47 muestra la configuración del volumen virtual en el que se ubica el almacén de datos. En la figura, se puede observar que el volumen virtual contiene un solo dispositivo disponible en el mismo site. Si el requerimiento del negocio, en constante cambio, exige que el almacén de datos se replique y esté disponible en ambas ubicaciones, la configuración puede modificarse de manera sencilla siempre y cuando haya suficiente almacenamiento físico disponible en el segundo site que en ese momento no contiene una copia de los datos. 5 Se pueden utilizar tecnologías como Storage VMotion para migrar la máquina virtual a un volumen virtual VPLEX Metro que está replicado y disponible en ambos sites y, en consecuencia, se activa la funcionalidad de migrar la máquina virtual entre sites de manera no disruptiva. Sin embargo, este método agrega complejidad innecesaria al proceso. No obstante, este proceso se puede aprovechar para transportar máquinas virtuales que no pueden tolerar la sobrecarga de la replicación síncrona. Planificación de mejores prácticas 41\n42 Figura 47. Información detallada de un volumen virtual Metro-Plex no replicado A continuación, se presenta el proceso para convertir un dispositivo no replicado encapsulado en un volumen virtual a fin de que se replique en el segundo site y se presente al cluster VMware en el segundo site. El proceso consta de cuatro pasos: 1. Creación de un dispositivo en el site en el que debe residir la copia de los datos. El proceso para crear un dispositivo, que se muestra en la Figura 48, es independiente del sistema operativo host y se analizó en la sección Aprovisionamiento de almacenamiento VPLEX en ambientes VMware. Figura 48. Creación de un dispositivo en EMC VPLEX mediante la GUI 2. El siguiente paso es la incorporación de un dispositivo recientemente creado como un espejeado al dispositivo existente que necesita protección geográfica. Esto se muestra en la Figura 49 y, al igual que en el paso anterior, es independiente del sistema operativo host que utilizan los volúmenes virtuales creados con el uso de los dispositivos. Planificación de mejores prácticas 42\n43 Figura 49. Cambio del tipo de protección de un dispositivo VPLEX RAID 0 a un dispositivo RAID 1 distribuido 3. Creación o modificación del enmascaramiento de LUN en EMC VPLEX Metro para permitir que los servidores VMware ESX Server conectados a los nodos en el segundo site tengan acceso al volumen virtual que contiene los dispositivos replicados. La Figura 50 muestra los resultados posteriores a la ejecución del proceso. Figura 50. Creación de una vista para exponer el volumen virtual de VPLEX al segundo site 4. El volumen virtual VPLEX recientemente exportado que contiene los dispositivos replicados debe ser detectado en el cluster VMware en el segundo site. Este proceso es idéntico al proceso Planificación de mejores prácticas 43\n44 de incorporación de cualquier dispositivo SCSI a un cluster VMware. La Figura 51 muestra que el almacén de datos replicado ahora está disponible en ambos clusters VMware en el site A y el site B después del nuevo examen del bus SCSI. Figura 51. Visualización de los servidores VMware ESX Server que tienen acceso a un almacén de datos vcenter Server virtualizado en VPLEX Metro VMware soporta instancias virtualizadas de vcenter Server versión 4.0 o posterior. La ejecución de vcenter Server y componentes asociados en una máquina virtual brinda a los clientes gran flexibilidad y comodidad, dado que se pueden aprovechar todos los beneficios de un data center virtual para todos los componentes en una implementación de VMware. Sin embargo, en un ambiente EMC VPLEX Metro, una implementación poco metódica de vcenter Server que se ejecuta en una máquina virtual puede presentar retos interesantes en caso de que se produzca una falla en el site. Esto sucede especialmente si vcenter Server se utiliza para administrar ambientes VMware también implementados en el mismo cluster EMC VPLEX Metro. Como se explicó en párrafos anteriores, si se produce una falla en un site o una partición de la red entre los sites, EMC VPLEX suspende automáticamente todas las operaciones de I/O en un site. El site en el que se suspenden las operaciones de I/O se determina por medio de un conjunto de reglas que está activo cuando ocurre el evento. Este comportamiento puede aumentar el RTO si se produce una falla en un site y VMware vcenter Server está ubicado en un volumen distribuido de EMC VPLEX que se replica en ambos sites. Esta cuestión se puede explicar mejor con un ejemplo. Considere una implementación en un ambiente VMware en la cual vcenter Server y SQL Server se ejecutan en máquinas virtuales independientes. Sin embargo, las dos máquinas virtuales están albergadas en un dispositivo EMC VPLEX replicado, D, entre dos sites, A y B. En este ejemplo, supongamos que vcenter Server y SQL Server se ejecutan en el site A. Por lo tanto, la mejor práctica recomendada es exigir que las operaciones de I/O dirigidas al dispositivo D se suspendan en el site B. Esta recomendación permite que las máquinas virtuales en las que están albergadas las aplicaciones de administración de vsphere continúen ejecutándose en el site A en caso de que se produzca una partición de la red 6. Sin embargo, si un evento disruptivo causa la pérdida de todo el servicio en el site A, el ambiente VMware no se podrá administrar, dado que la instancia del dispositivo D en el site B estará en estado suspendido. Para la restauración, se deben llevar a cabo diversas medidas correctivas, que se enumeran a continuación: 1. Se deben reanudar las operaciones de I/O dirigidas al dispositivo D en el site B. Esto se puede llevar a cabo por medio de la interfaz de administración de VPLEX. 6 Cabe destacar que, en el caso de una partición de la red, las máquinas virtuales que se ejecutan en el site B continúan ejecutándose sin interrupción alguna. Sin embargo, dado que vcenter Server, ubicado en el site A, no tiene conectividad de red con los servidores en el site B, el ambiente de VMware ESX Server en el site B no se puede administrar. Esto incluye la falta de disponibilidad de funciones avanzadas, como DRS y VMotion. Planificación de mejores prácticas 44\n1 LOS PILARES DEL DATACENTER Federación de recursos 2 Evolución del Almacenamiento Virtual Federación de Consolidación Pools de Cooperación Almacenamiento y Servidores n Standalone Standalone Pools de\nWhite. paper. Optimización del centro de datos virtual con pools de rutas de datos. EMC PowerPath/VE. Febrero de 2011\nWhite paper Optimización del centro de datos virtual con pools de rutas de datos EMC PowerPath/VE Por Bob Laliberte Febrero de 2011 Este informe técnico de ESG fue encargado por EMC y distribuido bajo\nEMC VSPEX PARA MICROSOFT SQL SERVER VIRTUALIZADO EN EMC XTREMIO\nGUÍA DE DISEÑO EMC VSPEX PARA MICROSOFT SQL SERVER VIRTUALIZADO EN EMC XTREMIO EMC VSPEX Resumen Esta guía de diseño describe cómo diseñar recursos de Microsoft SQL Server virtualizado en una infraestructura\nNUBE PRIVADA DE EMC VSPEX:\nNUBE PRIVADA DE EMC VSPEX: VMware vsphere 5.5 y EMC ScaleIO EMC VSPEX Resumen En este documento se describe la solución de infraestructura comprobada EMC VSPEX para implementaciones de nube privada con\nCONTINUIDAD DEL NEGOCIO DE MISIÓ N CRÍTICA DE EMC PARA SAP\nInforme técnico CONTINUIDAD DEL NEGOCIO DE MISIÓ N CRÍTICA DE EMC PARA SAP Administración simplificada para ofrecer alta disponibilidad y continuidad del negocio Implementaciones resistentes de misión\nNUBE PRIVADA DE EMC VSPEX: EMC VSPEX Resumen En este documento se describe la solución de infraestructura comprobada de EMC VSPEX para implementaciones de nube privada con Microsoft Hyper-V y la tecnología\nEMC VNXe Usar un sistema VNXe con VMware NFS o VMware VMFS\nEMC VNXe Usar un sistema VNXe con VMware NFS o VMware VMFS VNXe Operating Environment Versión 2.4 NÚMERO DE REFERENCIA 300-010-553 REV 04 Conectar a almacenamiento Copyright 2013 EMC Corporation. Todos\nEMC VSPEX PARA MICROSOFT SQL SERVER 2012 VIRTUALIZADO CON MICROSOFT HYPER-V\nGUÍA DE IMPLEMENTACIÓN EMC VSPEX PARA MICROSOFT SQL SERVER 2012 VIRTUALIZADO CON MICROSOFT HYPER-V EMC VSPEX Resumen Esta Guía de implementación describe, de manera general, los pasos necesarios para implementar\nACELERACIÓN DE LA TRANSFORMACIÓN DE TI CON LA ÚLTIMA GENERACIÓN DE ALMACENAMIENTO UNIFICADO Y RESPALDO DE EMC\nACELERACIÓN DE LA TRANSFORMACIÓN DE TI CON LA ÚLTIMA GENERACIÓN DE ALMACENAMIENTO UNIFICADO Y RESPALDO DE EMC La virtualización, en particular VMware, ha cambiado el modo en el que las empresas miran la\nInforme de validación de Lab\nInforme de validación de Lab EMC PowerPath en comparación con MPIO nativo de Windows Administración de rutas de datos automatizada, failover y recuperación, y balanceo de carga optimizado Por Vinny Choinski\nEspecialistas en virtualización de centros de datos Un datacenter virtual en su empresa\nEspecialistas en virtualización de centros de datos Un datacenter virtual en su empresa 2009 www.ideasmultiples.com 1 De 11 Virtualización La virtualización consiste en dividir un servidor físico nodo\nImplementación de una estrategia integral de continuidad de negocio y recuperación ante desastres con VMware\nImplementación de una estrategia integral de continuidad de negocio y recuperación ante desastres con VMware VMware vforum, 2014 2014 VMware Inc. Todos los derechos reservados Temas del programa Definición\nGUÍA DE DISEÑO EMC VSPEX PARA APLICACIONES VIRTUALIZADAS SAP BUSINESS SUITE EMC VSPEX Resumen Esta guía de diseño describe cómo diseñar recursos de aplicaciones virtualizadas SAP Business Suite en la infraestructura\nSede internacional: 5 Speen Street Framingham, MA 01701 Estados Unidos Telf. +1 508.872.8200 Fax +1 508.935.4015 www.idc.com W H I T E P A P E R L a p r o m e s a d e l a l m a c e n a m i e n t o v i\nEMC VSPEX PARA MICROSOFT SQL SERVER 2012 VIRTUALIZADO\nGUÍA DE DISEÑO EMC VSPEX PARA MICROSOFT SQL SERVER 2012 VIRTUALIZADO EMC VSPEX Resumen Esta guía de diseño describe cómo diseñar recursos virtualizados de Microsoft SQL Server en la nube privada EMC VSPEX\nNUBE PRIVADA DE EMC VSPEX\nNUBE PRIVADA DE EMC VSPEX Microsoft Windows Server 2012 R2 con Hyper-V para hasta 1,000 máquinas virtuales Activado por EMC VNX y EMC Powered Backup EMC VSPEX Resumen En este documento, se describe la\nGUÍA DE DESCRIPCIÓN DE PRODUCTO DE EMC EMC SYMMETRIX VMAX CON ENGINUITY\nGUÍA DE DESCRIPCIÓN DE PRODUCTO DE EMC EMC SYMMETRIX VMAX CON ENGINUITY 2 TABLA DE CONTENIDO Público al que va dirigido 3 Capítulo 1: Introducción 4 Capítulo 2: Arquitectura de Symmetrix VMAX 10 Capítulo\nGUÍA DE DISEÑO EMC VSPEX PARA MICROSOFT SQL SERVER 2012 VIRTUALIZADO Habilitado por EMC VNX de última generación y el respaldo de EMC EMC VSPEX Resumen Esta guía de diseño describe cómo diseñar recursos\nGuía del administrador de VMware Integrated OpenStack\nGuía del administrador de VMware Integrated OpenStack VMware Integrated OpenStack 2.0.0 Este documento admite la versión de todos los productos enumerados y admite todas las versiones posteriores hasta\nItem 1 Solución de Respaldo\nItem Solución de Respaldo Requisitos Solución de respaldo nivel enterprise 3 Solución redundante con posibilidad de clusterización, o esquemas activo-activo o activo-standby. La solución deberá contar\nINFRAESTRUCTURA DE EMC PARA APLICACIONES DE MICROSOFT EN LA NUBE PRIVADA\nInforme técnico INFRAESTRUCTURA DE EMC PARA APLICACIONES DE MICROSOFT EN LA NUBE PRIVADA Optimización automatizada del rendimiento Administración simplificada y centralizada Recuperación de desastres automatizada\nGuía de infraestructura comprobada NUBE PRIVADA DE EMC VSPEX VMware vsphere5.5 para hasta 100 máquinas virtuales Habilitado por Microsoft Windows Server 2012, EMC VNXe y respaldo suministrado por EMC EMC\nGUÍA DE IMPLEMENTACIÓN CÓMPUTO DEL USUARIO FINAL DE EMC VSPEX VMware Horizon View 6.0 y VMware vsphere para hasta 2,000 escritorios virtuales Con tecnología de EMC VNX y protección de datos de EMC EMC\nNovedades en vsphere 5.0\nNovedades en vsphere 5.0 Con esta versión, el sistema operativo de centro de datos virtual de VMware continúa transformando la infraestructura de TI x86 en el más eficiente compartida, la utilidad, a la\nGUÍA DE DISEÑO EMC VSPEX PARA MICROSOFT SQL SERVER 2012 VIRTUALIZADO EMC VSPEX Resumen Esta guía de diseño describe cómo diseñar recursos de Microsoft SQL Server virtualizado en la infraestructura comprobada


Nueva normativa para ITV - Volkswagen Ferper\nInicio » Noticias » Nueva normativa para ITV\n17 mayo, 2018 |ITV\nEl próximo domingo, 20 de Mayo de 2018, entra en vigor la nueva normativa sobre la Inspección Técnica de Vehículos (ITV), aprobada a finales del pasado año. La ITV no es sólo un trámite obligatorio sino también absolutamente aconsejable para garantizar la seguridad y buen funcionamiento de los mismos.\n¿Cada cuanto hay que pasar la ITV?\nA partir del 4º año de su primera matriculación, cada 2 años\nA partir del 10º año de su primera matriculación, cada año\nSegunda revisión en otro centro\nCon la normativa anterior, si un vehículo no superaba al primer intento la inspección, el propietario estaba obligado a repetirla en el mismo centro. El real decreto aprobado el 20 de octubre del pasado año permite que, a partir del proximo lunes, el usuario pueda acudir a un centro diferente una vez subsanadas las carencias o defectos que provocaron el informe desfavorable. Eso sí, siempre de los plazos establecidos.\nMás control sobre las emisiones\n¿Necesitas pasar la ITV? ¿Quieres que revisemos tu Volkswage o que la pasemos por ti?\n16 mayo, 2018 Dpt Marketing


Asghar Mohammadi Fazel (Irán), Presidente del OSACTT 13 dio la bienvenida a los delegados y destacó el desafío de brindar un asesoramiento científico oportuno e informado a quienes definen decisiones en un mundo que cambia rápidamente. Alfonso Pecoraro Scanio, Ministro de Ambiente, Tierra y Mar de Italia, destacó al cambio climático como uno de las principales amenazas a los ecosistemas de la región del Mediterráneo, y subrayó la importancia de vincular a las Convenciones de Río para poder superar esa dificultad. Tras subrayar la importancia del Plan de Acción de Bali para el logro del acuerdo sobre los compromisos de reducción de emisiones post 2012, pidió acciones urgentes y ambiciosas para reducir los efectos negativos del cambio climático.\nLa Profesora Rosalía Arteaga Serrano, de Ecuador, se refirió a la unión de silvicultura, agricultura y ambiente en el contexto de la meta de la diversidad biológica 2010. También presentó el término “cuestiones glocales” que busca destacar la importancia de la integración de las perspectivas globales con las locales. Y se refirió a las razones por las que las preocupaciones ambientales se han desconectado de la agricultura y la silvicultura, destacando: el aumento de la presión para la intensificación, que surge como resultado del incremento de la demanda de alimentos, energía y vivienda; la separación de las responsabilidades del sector público hacia el medio ambiente, de aquellas de relaciones con la agricultura, la silvicultura y el agua; la emergencia de mercados que demandan biocombustibles, agrocombustibles y productos orgánicos. Finalmente, explicó que el logro de la reintegración requerirá de una mayor aplicación de los principios del desarrollo sostenible.\nASUNTOS ORGANIZATIVOS Los delegados eligieron a Angheluta Vadineanu (Rumania) como relator; a Gabriela Obermayr (Austria) y a Linus Spencer Thomas (Granada) como presidentes de los grupos de trabajo I y II, respectivamente; y a Hesiquio Benitez (México) y a Asghar Fazel como copresidentes del comité plenario.\nJUSCANZ postuló a Noruega como nuevo miembro del Buró del OSACTT. Las nominaciones de otros grupos regionales quedaron pendientes de consultas regionales.\nLuego, los delegados adoptaron la agenda de la reunión y su organización de trabajo (UNEP/CBD/SBSTTA/13/1 y 1/Add.1). En respuesta a una solicitud de aclaración sobre las sugerencias acerca del procedimiento del OSACTT de UNEP/CBD/SBSTTA/1/Add.2, que incluyen la práctica de enviar las opciones sobre cuestiones sobre las que no se puede llegar a un consenso, el Presidente Fazel explicó que este procedimiento seguirá las prácticas del pasado del OSACTT.\nMODUS OPERANDI PARA LAS CUESTIONES NUEVAS Y EMERGENTES: El Presidente Fazel pidió comentarios sobre el modus operandi del OSACTT para el tratamiento de las cuestiones nuevas y emergentes (UNEP/CBD/SBSTTA/13/8), entre las que se incluyen tres opciones sobre el procedimiento de selección y priorización. Tanzania, por el GRUPO AFRICANO, CANADÁ, FRANCIA, INDONESIA, PORTUGAL, ESLOVENIA, SUIZA y TAILANDIA señalaron su preferencia porque el Buró de OSACTT decida si se debe considerar una cuestión nueva y emergente. ARGENTINA, AUSTRALIA, BRASIL, CUBA y PERÚ apoyaron una opción que especifica que no se establecerán prioridades antes de la nueva reunión de la CdP, destacando que el procedimiento debe respetar la autoridad de definir la agenda de la CdP y solicitar que sea la Secretaría, y no el Buró, quien haga anotaciones en la agenda de OSACTT. INDIA, MALASIA, NUEVA ZELANDA y otros prefirieron que las consideraciones se basen en una opción que describe un procedimiento en dos pasos, de ese modo en la primera reunión de una OSACTT posterior a una CdP se recomendará cómo deberán tratar esas cuestiones, y en la segunda reunión se tratarán esas cuestiones. Se estableció un Grupo de Amigos del Presidente para que avance en un compromiso.\nRevisión del Programa de Trabajo:\nLos delegados consideraron una revisión en profundidad del programa de trabajo sobre la diversidad biológica agrícola (UNEP/CBD/SBSTTA/13/2). Muchos países pidieron una mejora de la cooperación con la FAO y otras organizaciones. Y, la CE hizo hincapié en la cooperación en las áreas de monitoreo y evaluación, y la conservación de los recursos genéticos; NUEVA ZELANDA pidió por la creación de capacidades a nivel nacional para el enfoque hacia los ecosistemas; y JAPÓN advirtió en contra de la duplicación de los esfuerzos.\nCon respecto a los biocombustibles, la CE sugirió que la CdP 9 desarrolle directrices para minimizar los impactos negativos potenciales de la producción y el consumo de biocombustibles. ARGENTINA señaló que las cuestiones del cambio climático y los biocombustibles ya son tratadas en otros foros. BRASIL se opuso a que las recomendaciones fueran más allá de la recolección y difusión de información. El GRUPO AFRICANO pidió conocimiento y orientación adicional sobre la producción y el consumo de bioenergías; ALEMANIA, un análisis completo del ciclo de vida de la producción de combustibles de biomasa y sus impactos sobre el clima; y NORUEGA, mecanismos y sistemas para la producción sostenible de biocombustibles. LIBERIA, BÉLGICA y QATAR dirigieron la atención a los impactos negativos de los biocombustibles LIBERA pidió, además, políticas claras a nivel nacional para evitar los monocultivos a gran escala.\nLos PAÍSES BAJOS subrayaron el desafío de equilibrar los usos agrícolas con la conservación de la vida silvestre. GHANA pidió la identificación, el reconocimiento y el apoyo a las iniciativas regionales pata la agricultura y el desarrollo sostenible. BRASIL sugirió que se ponga el foco en la utilización sostenible de la diversidad biológica del suelo, los recursos hídricos y la gestión integrada de las plagas. ETIOPÍA hizo hincapié en la rehabilitación de los ecosistemas agrícolas degradados, y YEMEN destacó la necesidad de proteger las áreas más frágiles. PAÍSES BAJOS señaló la necesidad de iniciativas conjuntas sobre transferencia de tecnologías para la implementación de los principios de Addis Ababa sobre utilización sostenible de la diversidad biológica.\nTURQUÍA pidió el desarrollo de indicadores para el monitoreo de la implementación de la CDB y apoyo a las investigaciones a largo plazo sobre los vínculos con el clima. SUIZA sugirió la utilización de los indicadores que están siendo desarrollados por la CE, mientras que INDIA cuestionó la utilización de un grupo universal de indicadores, señalando que las Partes deberían seleccionar sus propios indicadores.\nEL SALVADOR destacó la generalización de la diversidad biológica agrícola en las políticas de otros sectores y que las declaraciones de las misiones de los programas de trabajo se centren en los tres objetivos de la CDB. TAILANDIA priorizó las especies extrañas invasoras y la carga de nitrato como amenazas a la diversidad biológica agrícola. POLONIA destacó la necesidad de fortalecer las recomendaciones sobre los instrumentos de implementación nacional.\nLa FAO destacó sus logros como un socio líder en la implementación, haciendo hincapié en la cooperación a través de las organizaciones y desde los productores de alimentos hasta el nivel políticos. El GRUPO CONSULTIVO SOBRE INVESTIGACIÓN AGRÍCOLA INTERNACIONAL recibió con agrado la invitación a apoyar la implementación de la Iniciativa Internacional sobre la Diversidad Biológica para la Alimentación y la Nutrición, mientras que el SERVICIOS DE INFORMACIÓN SOBRE LA DIVERSIDAD BIOLÓGICA MUNDIAL describió como su trabajo taxonómico apoya la Iniciativa Internacional para la Conservación y Utilización Sostenible de los Polinizadores. La PLATAFORMA PARA LA INVESTIGACIÓN EN DIVERSIDAD BIOLÓGICA AGRÍCOLA explicó el papel que cumple como investigador, incluyendo la identificación de usos de la diversidad biológica agrícola en la adaptación al cambio climático y su mitigación. El PNUMA se refirió a una iniciativa que busca minimizar los impactos negativos de la liberación de los mercados sobre la diversidad biológica de la agricultura en los países en desarrollo. La CÁMARA INTERNACIONAL DE COMERCIO destacó la necesidad de prácticas de producción agrícola sostenibles e intensas. El FORO INDÍGENA INTERNACIONAL SOBRE LA DIVERSIDAD BIOLÓGICA destacó que la preservación de la diversidad biológica agrícola requiere de la protección de los derechos locales sobre la tierra y los sistemas socioculturales.\nA pesar de que OSACTT 13 tiene una agenda pesada, que un delegado describió como “cargada de ítems explosivos”, la reunión comenzó con una clara motivación que pudo verse en la metódica sesión del plenario. En ese sentido, varios delegados expresaron su satisfacción por el modo en que se había tratado, de inmediato, la sustancia de la reunión, y un delegado señaló que “por una vez la gente había respondido al pedido del Presidente de evitar pérdidas de tiempo en formalidades como el agradecimiento al Presidente y a la Secretaría”. Otro participante comentó la actitud proactiva del Presidente, que se hizo evidente con el rápido establecimiento de un grupo de Amigos del Presidente para que trabaje sobre la primera cuestión controversial: ¿de qué modo deberá tratar el OSACTT las cuestiones nuevas y emergentes? Además, varios delegados recibieron con agrado la sugerencia del Buró de que el OSACTT debería enviar a la CdP opciones sobre aquellas áreas en las que no pueda llegar a un acuerdo evitando así quedar atrapado en las diferencias políticas. Como sostuvo un delegado, con un procedimiento de este tipo queda claro que la función del OSACTT es “proponer” y no “decidir”.


Políticos: El deber de explicar - El LibrePensador\nPolíticos: El deber de explicar\n1 Los que gobiernan no están ahí por casualidad\n1.1 Solo tienen que asumir que, desde el instante que empiezan a ejercer su función, dejan de trabajar para ellos mismos.\n2 Ocultar y manipular es uno de los peores hábitos de la política contemporánea\n3 Explicar no es una alternativa\n3.1 Es trascendente que el funcionario comprenda que no administra su patrimonio, sino el de todos los ciudadanos.\n3.2 Lamentablemente, el poder obnubila a muchos de los mortales, inclusive a aquellos que, hasta ayer, parecían distintos.\n3.3 Son solo políticos, hombres y mujeres de carne y hueso, sin supremacía sobre los demás.\nLos que gobiernan no están ahí por casualidad\nMariano Rajoy en Cantabria. Foto: Populares de Cantabria\nHan llegado a ocupar esas posiciones porque un número considerable de individuos los ha respaldado en las urnas, asignándole la difícil labor de administrar la cosa pública.\nNo han alcanzado esos puestos contra su propia voluntad. De hecho, se han postulado para ocuparlos sin que nadie los obligue a ello. Han conseguido ese espacio al ser electos, o indirectamente cuando fueron convocados por los que realmente contaron con el apoyo de la gente.\nSolo tienen que asumir que, desde el instante que empiezan a ejercer su función, dejan de trabajar para ellos mismos.\nPodrán imprimirle su impronta a la tarea cotidiana, pero jamás deben olvidar que no les toca gestionar lo propio sino lo ajeno.\nPedro Sánchez en Mérida. Foto: es.wikipedia.org\nOcultar y manipular es uno de los peores hábitos de la política contemporánea\nY una demostración empírica de que aun no se ha comprendido la exacta naturaleza de esta suerte de democracia representativa que, con matices, se ha transformado casi en universal.\nMientras buscaba conseguir votos para acceder al poder se esforzaba por ser carismático, brindaba largas entrevistas a los medios de comunicación y se tomaba el tiempo necesario para dialogar con la gente. Ya en el gobierno, parece olvidar el modo en el que ha logrado ese lugar, y asume con total naturalidad que no existen motivos suficientes para estar explicando las razones que lo empujan a tomar ciertas determinaciones.\nExplicar no es una alternativa\nNo se trata de una posibilidad a evaluar. Es su deber hacerlo, y bien. Sus “jefes” son los votantes. Por eso, no solo debe reportarse ante los que lo consideraron el mejor candidato, sino que también debe hacerlo con aquellos que prefirieron a otros postulantes.\nEs trascendente que el funcionario comprenda que no administra su patrimonio, sino el de todos los ciudadanos.\nPor ende, sus resoluciones deben estar enmarcadas en un proceso de profundo análisis y no plagado de las típicas improvisaciones con las que se convive a diario.\nLamentablemente, el poder obnubila a muchos de los mortales, inclusive a aquellos que, hasta ayer, parecían distintos.\nEs un fenómeno demasiado habitual y casi inevitable. Los que alcanzan el poder tienden a creer, por momentos, que ahora son intocables, iluminados, seres especiales y, por lo tanto, personas que no pueden ser cuestionadas.\nEllos deben rendir cuentas siempre. Tienen que aportar información completa, minuciosa y pormenorizada. Sus decisiones deben contar con una argumentación sólida, al punto de abundar en detalles.\nSon solo políticos, hombres y mujeres de carne y hueso, sin supremacía sobre los demás.\nTienen en sus manos infinitas responsabilidades y, justamente, una de ellas es el deber de explicar.\nA mal testigo, peor juez…\nPolíticos fuertes y honrados. Políticas ambiciosas