USO DE VPLEX METRO Y RECOVERPOINT CON VMWARE SRM EN UN ENTORNO ORACLE … · con Oracle Applications en Oracle RAC extendido para ... FAST VP en el cluster VPLEX Metro ... Interfaz

Informe técnico

Resumen

Este informe técnico analiza cómo configurar un VPLEX Metro con Oracle Applications en Oracle RAC extendido para replicar en un tercer sitio RecoverPoint y VMware vCenter Site Recovery Manager para conseguir alta disponibilidad y recuperación de desastres. Julio de 2013

USO DE VPLEX METRO Y RECOVERPOINT CON VMWARE SRM EN UN ENTORNO ORACLE EXTENDED RAC E-BUSINESS SUITE DEMOSTRACIÓN DE LA INTEROPERABILIDAD DE VPLEX, RECOVERPOINT Y VMWARE SRM CON LAS APLICACIONES DE ORACLE Y RAC EXTENDIDO PARA ALTA DISPONIBILIDAD Y RECUPERACIÓN DE DESASTRES

2 USO DE VPLEX METRO Y RECOVERPOINT CON VMWARE SRM EN UN ENTORNO ORACLE EXTENDED RAC E-BUSINESS SUITE

Copyright © 2013 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 mexico.emc.com (visite el sitio web de su país correspondiente). VMware, ESXi, VMotion y vSphere son marcas registradas o marcas comerciales de VMware, Inc. en los Estados Unidos y en otras jurisdicciones. Todas las demás marcas comerciales utilizadas en este documento pertenecen a sus respectivos propietarios. Número de referencia h11767.1


Tabla de contenido

Resumen ejecutivo .................................................................................................. 6 Público de destino ............................................................................................................. 6 Terminología ...................................................................................................................... 6 Alcance y limitaciones del documento ................................................................................ 7

Introducción ............................................................................................................ 8

Symmetrix VMAX con Enginuity 5876 ....................................................................... 8

EMC Unisphere for VMAX y VPLEX ............................................................................ 9

EMC Virtual Storage Integrator ............................................................................... 11

VMware ESXi versión 5.x con PowerPath/VE ........................................................... 14

Symmetrix Virtual Provisioning .............................................................................. 16

Fully Automated Storage Tiering (FAST) .................................................................. 17 FAST y Fully Automated Storage Tiering con pools virtuales (FAST VP) ............................... 18 Objetos administrados por FAST ....................................................................................... 18

Asignación de FAST VP por la política de FAST ........................................................ 19

Oracle Applications ............................................................................................... 19

VPLEX ................................................................................................................... 20 Movilidad ..................................................................................................................... 21 Disponibilidad ............................................................................................................. 21

Ofertas de productos VPLEX ............................................................................................. 21 Volúmenes de registro ...................................................................................................... 23 Redundancia con RecoverPoint ........................................................................................ 23 VASA con VPLEX ............................................................................................................... 24

FAST VP y Oracle Applications 12 ........................................................................... 25 Arquitectura de las aplicaciones ....................................................................................... 25 Trabajar con FAST VP y Oracle Applications en VMware vSphere ....................................... 26 Modelo de espacios de tablas para aplicaciones Oracle ................................................... 27 Implementación de Oracle Applications ........................................................................... 27 Implementación de Oracle Applications ........................................................................... 28 Diseño de hardware ......................................................................................................... 29

FAST VP en el cluster VPLEX Metro .......................................................................... 29 Sitio remoto de RecoverPoint............................................................................................ 35

Anclaje de dispositivos en FAST VP para la base de datos de Oracle ....................... 36 Anclaje de dispositivos REDO en FAST VP ......................................................................... 36

Dispositivos distribuidos VPLEX y grupos de consistencia ...................................... 38 Ejemplo de aprovisionamiento de almacenamiento ......................................................... 38

Asistente de volúmenes virtuales de VPLEX .................................................................. 40 Creación de un dispositivo distribuido VPLEX ............................................................... 47


Estado de fallo de un dispositivo distribuido ................................................................ 52 Activación de RecoverPoint en el grupo de consistencia VPLEX .................................... 53 Adición de dispositivos distribuidos a las vistas de almacenamiento ........................... 53 Visualización en VMware .............................................................................................. 57

Dispositivos locales VPLEX para registros de RecoverPoint ..................................... 59 Creación de grupos de consistencia para el registro de RecoverPoint ........................... 59 Adición del registro de RecoverPoint a una vista de almacenamiento ........................... 62

Implementación de VMware .................................................................................. 63 Implementaciones de VMware en un ambiente VPLEX Metro ............................................ 63 VPLEX Metro Witness ........................................................................................................ 63

Manejo de fallos de VPLEX ........................................................................................... 66

Configuración de clusters VMware con VPLEX Metro Witness .................................. 67 Configuración de clusters VMware ................................................................................ 67 Grupos y reglas de VMware DRS ................................................................................... 68

Mejores prácticas con VMware HA y VPLEX Metro ............................................................. 73

Oracle Real Application Clusters (RAC) en VPLEX Metro ........................................... 73 RAC extendido y Oracle Clusterware con VPLEX Witness ................................................... 73 Oracle en VMware ............................................................................................................ 74 Oracle Real Application Clusters (RAC) y Oracle E-Business Suite ..................................... 74 Oracle Real Application Clusters (RAC) en VMFS ............................................................... 75

Implementación de Oracle Clusterware ........................................................................ 75 Instalación de Oracle RAC extendido ................................................................................ 75

Procedimiento .............................................................................................................. 76 Redes ............................................................................................................................... 78

EMC RecoverPoint ................................................................................................. 81 RPA .............................................................................................................................. 81 Volúmenes ................................................................................................................... 81 Snapshot/PiT ............................................................................................................... 82 Acceso registrado (físico) ............................................................................................. 82 Acceso directo .............................................................................................................. 82

RecoverPoint 4.0 .............................................................................................................. 82 RecoverPoint CDP y SRDF .............................................................................................. 83

Configuración de VPLEX Metro RecoverPoint ........................................................... 83 VPLEX Metro y RecoverPoint CRR/CLR ............................................................................... 83

Unisphere for RecoverPoint .................................................................................... 85

Configuración de RecoverPoint para ambientes Oracle ........................................... 87 Licencias de RecoverPoint ................................................................................................ 88

Configuración de RecoverPoint .............................................................................. 91 Registros de RecoverPoint ................................................................................................ 91 Réplicas de RecoverPoint ................................................................................................. 92


Creación de grupos de consistencia ................................................................................. 92 Configuración de administración externa para un grupo de consistencia ...................... 98 Creación de conjuntos de grupos ................................................................................. 99

Instalación de VMware SRM ................................................................................. 101 RecoverPoint SRA ........................................................................................................... 101

Protección y grupos de usuarios de VMware SRM ................................................. 102 Adición de un administrador de arreglos de RecoverPoint .............................................. 102 Creación del grupo de protección de VMware SRM ......................................................... 105

Failover de prueba de VMware SRM ..................................................................... 108

VSI: RecoverPoint Management ........................................................................... 108

Prueba de failover de RecoverPoint con VSI .......................................................... 110 Asignación de un punto en el tiempo en VSI para los grupos de consistencia de RecoverPoint .................................................................................................................. 110

Prueba de failover ...................................................................................................... 113

PiT de RecoverPoint con VSI en la recuperación de desastres ................................ 119 Activación de PiT con VSI RM en el sitio de recuperación ................................................ 120

Recomendaciones para el uso de RecoverPoint con VMware SRM ......................... 127

Conclusión .......................................................................................................... 127

Referencias ......................................................................................................... 128 EMC ................................................................................................................................ 128 VMware .......................................................................................................................... 128 Oracle ............................................................................................................................ 129


Resumen ejecutivo La familia EMC® VPLEX™ elimina las barreras físicas dentro de los centros de datos y entre ellos. VPLEX Metro proporciona acceso a los datos y movilidad de datos entre dos clusters VPLEX situados a distancias síncronas. Con una exclusiva arquitectura de escalamiento horizontal, las funciones avanzadas de almacenamiento en caché de datos y coherencia de caché distribuida de VPLEX ofrecen resistencia de los tipos de cargas, uso compartido automatizado, balanceo y failover de dominios de almacenamiento, y permiten obtener acceso a datos locales y remotos con niveles de servicio predecibles.

Con VMware vSphere™, resulta más fácil y menos costoso proporcionar niveles más altos de disponibilidad para aplicaciones importantes. Mediante vSphere, las organizaciones pueden aumentar fácilmente el nivel de base de disponibilidad que se proporciona para todas las aplicaciones, además de ofrecer mayores niveles de disponibilidad de forma más fácil y rentable. vSphere permite reducir el tiempo fuera planificado y no planificado. Las capacidades revolucionarias de VMware VMotion™ (vMotion) en vSphere permiten realizar mantenimiento planificado sin tiempo fuera de las aplicaciones, mientras VMware vCenter Site Recovery Manager aporta a los ambientes virtualizados una solución de recuperación de desastres sólida.

EMC RecoverPoint es una solución avanzada de recuperación de desastres de clase empresarial que admite ambientes heterogéneos de almacenamiento y servidores. RecoverPoint ayuda a los clientes a acelerar la protección y proporciona recuperación de desastres y operacional para el ambiente VMware vSphere, sin afectar los ambientes de producción. RecoverPoint es ideal para replicar y proteger ambientes virtualizados.

Al combinar estas tecnologías y una solución de software ERP y CRM empresarial, tal como Oracle Applications que se ejecuta en Oracle RAC extendido, proporciona una solución de hardware y software de alta disponibilidad para recuperación de desastres sin igual.

Público de destino

Este informe técnico está dirigido a los administradores de VMware, los administradores de bases de datos Oracle, los administradores de servidores y los administradores de almacenamiento que están a cargo de la creación, administración y utilización de VMware, así como sus dispositivos de almacenamiento subyacentes, para los ambientes VMware vSphere conectados a un arreglo de almacenamiento Symmetrix VMAX™ que ejecuta Enginuity™ 5876. En este informe técnico, se da por supuesto que el lector está familiarizado con las bases de datos y las aplicaciones de Oracle, los ambientes VMware, EMC Symmetrix VMAX, EMC VPLEX, EMC RecoverPoint y el software relacionado.

Terminología

Término Definición Dispositivo LUN, volumen lógico. Volumen LUN, volumen lógico. Unisphere Unisphere for VMAX, VPLEX o RecoverPoint según el contexto. SYMCLI/CLI Interfaz de la línea de comandos de Solutions Enabler.


Metavolumen Una recopilación de dispositivos Symmetrix que representan un dispositivo al nivel del host.

Volumen de almacenamiento LUN o unidad de almacenamiento que los arreglos de back-end presentan a VPLEX.

Volumen de metadatos Volumen del sistema VPLEX que contiene los metadatos de dispositivos, los volúmenes virtuales y la configuración de cluster.

Extensión Todo o una parte de un volumen de almacenamiento en una configuración de VPLEX.

Dispositivo El esquema de protección de VPLEX que se aplica a una extensión o un grupo de extensiones.

Volumen virtual Unidad de almacenamiento que los puertos de front-end de VPLEX presentan a los hosts.

Puerto de front-end Puerto de director conectado a los iniciadores de host (actúa como destino) en referencia a VPLEX.

Motor Consta de dos directores y es la unidad de escala para la solución VPLEX.

Cluster VPLEX Una recopilación de motores VPLEX en un rack.

VPLEX Metro La cooperación de dos clusters de VPLEX, donde cada uno brinda servicio a su propio dominio de almacenamiento a distancia síncrono para formar un volumen distribuido activo/activo.

Oracle RAC extendido

Un modelo de implementación de Oracle Real Application Clusters en el que los nodos de servidor residen en distintas ubicaciones físicas. Este tipo de implementación tiene requisitos estrictos de software y hardware pero puede activarse con tecnologías avanzadas como VPLEX Metro.

Acrónimo/abreviatura Definición LUN Número de la unidad lógica. TDEV Dispositivo delgado Symmetrix. FAST VP Fully Automated Storage Tiering con pools virtuales. SG Grupo de almacenamiento. RDM Mapeo de dispositivos crudos. VMFS VMware vStorage Virtual Machine File System.

Alcance y limitaciones del documento

Este documento se aplica a EMC VPLEX Metro configurado con VPLEX Witness, EMC RecoverPoint, VMware vSphere y vCenter Site Recovery Manager, así como Oracle Applications y Oracle RAC. Los detalles que se brindan en este informe técnico están basados en el siguiente software y hardware:

• VPLEX GeoSynchrony 5.1 o superior

• VPLEX Metro únicamente (Local y Geo no son compatibles con FT o alta disponibilidad en una configuración ampliada)

• Los clusters VPLEX se encuentran a una distancia de hasta 5 milisegundos (ms) para permitir alta disponibilidad de VMware

• VPLEX Witness se implementa en un tercer dominio de fallo. La funcionalidad Witness se requiere para que “VPLEX Metro” se use como verdadero cluster de almacenamiento activo/activo de disponibilidad continua


• ESXi y vSphere 5.1

• VMware vCenter Site Recovery Manager 5.1

• Cualquier par calificado de arreglos enumerados en EMC Simple Support Matrix (ESSM), en este caso Symmetrix VMAX

• EMC RecoverPoint 4.0 P1 y EMC RecoverPoint SRA 2.1

• Función EMC VSI para RecoverPoint Management 5.5

• Oracle Applications versión 12

• Oracle RAC 11g R2

• EMC Enginuity 5876 2013 Q2 SR con FAST VP

Introducción El propósito de este documento no es presentar los resultados de las pruebas de rendimiento o escalabilidad de los diferentes productos incluidos, sino explicar cómo estas distintas tecnologías pueden integrarse y trabajar en conjunto para proporcionar una solución sólida de alta disponibilidad y recuperación de desastres.

Este documento, por lo tanto, presentará las mejores prácticas para los diversos componentes incluidos en la solución, aunque el ambiente de laboratorio utilizado puede no haber tenido acceso a todos los componentes necesarios. Incluso si este ambiente de laboratorio cumpliera perfectamente los requisitos físicos, es posible que no pueda replicar el ambiente de un cliente específico. No obstante, al incluir las mejores prácticas, los clientes pueden utilizar la información y los recursos disponibles para diseñar el mejor ambiente para sus necesidades.

Los detalles acerca de la configuración del hardware físico se mencionan únicamente cuando sean necesarios para la solución, por ejemplo, en el caso de los pools delgados de Symmetrix VMAX. Se aconseja a los clientes trabajar con EMC para asegurarse de que el hardware físico para VPLEX y RecoverPoint esté instalado y configurado correctamente con el fin de aprovechar las soluciones, como la que se presenta en este informe técnico.

Symmetrix VMAX con Enginuity 5876 La versión más reciente de Enginuity 5876, 2013 Q2 SR (5876.229.145) lleva el desarrollo extendido y sistemático de funciones más allá que las generaciones anteriores de Symmetrix. Esto significa que todas las funciones de confiabilidad, disponibilidad y capacidad de servicio, toda la interoperabilidad y la cobertura de sistemas operativos de host, y todas las capacidades de software de aplicaciones desarrolladas por EMC y sus partners continúan funcionando de manera productiva y sin inconvenientes, incluso a medida que se actualiza la tecnología subyacente.


EMC Unisphere for VMAX y VPLEX

A partir de Enginuity 5876, Symmetrix Management Console fue reemplazado por EMC® Unisphere™ for VMAX™, que ofrece navegación con botones grandes y operaciones optimizadas para simplificar y reducir el tiempo necesario para administrar un centro de datos. Unisphere for VMAX simplifica la administración de almacenamiento en el marco de trabajo común e incorpora Symmetrix Performance Analyzer, que anteriormente requería una interfaz distinta.

Además, con la opción de monitoreo del rendimiento, Unisphere for VMAX proporciona herramientas para realizar análisis y obtener tendencias históricas de los datos de rendimiento del sistema Symmetrix.

El tablero de la GUI se presenta en la Figura 1.

La figura 1. Unisphere for VMAX: tablero

Unisphere for VMAX, que se muestra en la figura anterior, se puede ejecutar en diferentes tipos de host de sistemas abiertos, ya sean físicos o virtuales. Unisphere for VMAX también está disponible como dispositivo virtual para la versión 4.0 de ESX(i) (y versiones posteriores) en VMware vSphere. Para obtener más información visite Support.EMC.com (visite el sitio web de su país correspondiente).


Unisphere for VPLEX™, si bien sigue siendo una aplicación separada, proporciona la misma apariencia que la GUI de Unisphere for VMAX, junto con los mismos tipos de capacidades. El acceso a Unisphere for VPLEX se logra mediante una conexión segura (HTTPS) al servidor de administración. En el caso de VPLEX Metro, cualquier servidor de administración proporciona acceso a ambos clusters. El usuario puede pasar desde la recuperación de almacenamiento hasta la presentación de un dispositivo distribuido al host. La página de estado se muestra en la Figura 2. Tenga en cuenta que el estado de los clusters de RecoverPoint siempre aparecerá junto al cluster al que se tiene acceso a través del servidor de administración, independientemente dónde está configurado el dispositivo RecoverPoint (RPA).

La figura 2. Unisphere for VPLEX: estado del sistema


La GUI de Unisphere for VPLEX contiene varias estadísticas de rendimiento clave para el rendimiento del host y el estado general. Pueden encontrarse en la pestaña del tablero de rendimiento y se pueden agregar a los gráficos de rendimiento predeterminados que se muestran. A partir de los datos proporcionados, el administrador de VPLEX puede determinar rápidamente el origen de los problemas de rendimiento dentro de un ambiente. En la Figura 3, se muestra el tablero.

La figura 3. Unisphere for VPLEX: tablero de rendimiento

EMC Virtual Storage Integrator EMC Virtual Storage Integrator (VSI) para vSphere Client versión 5.5 proporciona varios conjuntos de funciones, entre los que se incluyen: Storage Viewer (SV), Path Management, Unified Storage Management, RecoverPoint Management y Symmetrix SRA. La funcionalidad Storage Viewer extiende VMware vSphere Client para facilitar el descubrimiento y la identificación de los dispositivos de almacenamiento de EMC Symmetrix, VPLEX CLARiiON®, Isilon®, VNX® y Celerra® que están asignados a los hosts de VMware ESX/ESXi y a las máquinas virtuales. Unified Storage Management simplifica el aprovisionamiento de almacenamiento en pools virtuales de Symmetrix VMAX para centros de datos, servidores ESX, clusters y pools de recursos. Path Management permite que el usuario controle de qué manera se tiene acceso a las áreas de almacenamiento de datos, mientras que las utilidades RecoverPoint Management y SRA proporcionan un marco de trabajo para usar ambientes VMware vCenter Site Recovery Manager (VMware SRM). Es posible tener acceso a la administración de VSI a través de la pantalla de inicio y del icono de EMC VSI que se muestra en la Figura 4.


La figura 4. Icono de EMC VSI en vSphere Client


En la Figura 5, se muestran algunas de las funciones de VSI instaladas.

La figura 5. Funciones de VSI 5.5

VSI para vSphere Client presenta los detalles de almacenamiento subyacente al administrador del centro de datos virtual y combina los datos de varias herramientas de mapeo de almacenamiento diferentes en unas pocas vistas de vSphere Client transparentes. VSI le permite resolver el almacenamiento subyacente de las áreas de almacenamiento de datos y los discos virtuales de Virtual Machine File System (VMFS) y SAN, así como el mapeo de dispositivos crudos (RDM). Además, se le presentarán listas de arreglos de almacenamiento y dispositivos que están disponibles para los hosts ESX(i) en el centro de datos virtual.


Una de estas funciones, Storage Viewer, se muestra en la Figura 6, donde se presenta cómo obtener información detallada sobre un LUN.

La figura 6. Función Storage Viewer de VSI 5.5

VMware ESXi versión 5.x con PowerPath/VE EMC PowerPath®/VE ofrece funciones de múltiples rutas de PowerPath para optimizar los ambientes virtuales VMware vSphere. Con PowerPath/VE, es posible estandarizar la administración de rutas en ambientes virtuales y físicos heterogéneos. PowerPath/VE permite automatizar la utilización óptima de servidores, almacenamiento y rutas 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 virtuales reciban sus tiempos de respuesta necesarios individuales consumen mucho tiempo y son logísticamente difíciles de lograr de manera eficiente.

PowerPath/VE funciona con VMware ESXi como un plug-in de múltiples rutas (MPP) que proporciona capacidades avanzadas de administración de rutas a los hosts ESX y ESXi. 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 7, PowerPath/VE se conecta al marco de trabajo de la pila de I/O de vSphere para ofrecer las capacidades avanzadas de múltiples rutas de PowerPath (balanceo dinámico de carga y failover automático) a VMware vSphere.

La figura 7. API de PowerPath/VE vStorage para el plug-in de múltiples rutas

Al usar PP/VE en hosts ESXi conectados a VPLEX, el modo de optimización predeterminado para los dispositivos VPLEX es adaptable. El modo de optimización predeterminado es la política más adecuada para la mayoría de los tipos de carga y no se debe modificar. Esta política se muestra en la Figura 8.

La figura 8. Política predeterminada de PP/VE para VPLEX de Adaptive

Usar PP/VE con VMware en VPLEX es una práctica recomendada.


Symmetrix Virtual Provisioning Symmetrix Virtual Provisioning™ es un tipo de dispositivo accesible para el host denominado dispositivo delgado o dispositivo virtual, que puede utilizarse de muchas de las maneras en que se han utilizado tradicionalmente los dispositivos Symmetrix regulares y accesibles para el host. VP ofrece la eficiencia y flexibilidad de almacenamiento que no pueden ofrecer los volúmenes gruesos tradicionales. A diferencia de los dispositivos Symmetrix regulares, los dispositivos delgados no necesitan que el almacenamiento físico esté completamente asignado cuando se crean los dispositivos y se los presenta a un host. El almacenamiento físico que se utiliza a fin de suministrar espacio de disco para un dispositivo delgado proviene de un pool delgado compartido que se ha asociado con el dispositivo delgado. Un pool delgado está compuesto por dispositivos Symmetrix internos denominados dispositivos de datos cuya finalidad consiste en proporcionar el almacenamiento físico real que utilizan los dispositivos delgados. Cuando se crean por primera vez, los dispositivos delgados no se asocian con ningún pool delgado en particular. Se debe llevar a cabo una operación denominada “vinculación” para asociar un dispositivo delgado a un pool delgado.

Figura 9 muestra la relación entre los dispositivos delgados y sus pools delgados asociados. Existen nueve dispositivos asociados al pool delgado A y tres dispositivos delgados asociados al pool delgado B.

La figura 9. Dispositivos delgados y pools delgados que contienen dispositivos de datos


Cuando se ejecuta una escritura a una parte del dispositivo delgado, Symmetrix realiza una asignación mínima de almacenamiento físico desde el pool y asigna ese almacenamiento a una región del dispositivo delgado que incluye el área de destino de la escritura. Las operaciones de asignación del almacenamiento se ejecutan en pequeñas unidades de almacenamiento denominadas “extensión delgada”. Se utiliza un mecanismo de round-robin para balancear la asignación de las extensiones delgadas entre todos los dispositivos de datos en el pool que estén activados y que tengan capacidad restante no utilizada. Una extensión delgada consta de 12 seguimientos de 64 KB (768 KB). Eso significa que la vinculación inicial de un dispositivo delgado a un pool provoca que se asigne una extensión, o 12 seguimientos, por dispositivo delgado.

Cuando se ejecuta una lectura en un dispositivo delgado, los datos que se leen se recuperan del dispositivo de datos correspondiente en el pool de almacenamiento al cual está vinculado el dispositivo delgado. Las lecturas que se dirigen a un área de un dispositivo delgado que no fue mapeado no desencadenan operaciones de asignación. La consecuencia de leer un bloque no mapeado es que se recibirá un bloque en el cual cada byte es igual a cero. Cuando se requiere más almacenamiento para dar servicio a dispositivos delgados existentes o futuros, se pueden agregar dispositivos de datos a los pools delgados existentes. También pueden crearse dispositivos delgados nuevos y asociarlos a los pools delgados existentes.

Un dispositivo delgado siempre está vinculado a un solo pool delgado, pero puede tener extensiones asignadas en múltiples pools dentro de un mismo sistema Symmetrix. Además, con Virtual LUN VP Mobility, es posible transferir un dispositivo delgado a un pool delgado diferente sin ninguna pérdida de datos ni de acceso a los datos. Virtual LUN VP Mobility proporciona la capacidad para migrar un dispositivo delgado de un pool delgado a otro. Si el LUN que se desea transferir forma parte de una política de FAST VP, solo se puede migrar a uno de los pools delgados en la política.

Fully Automated Storage Tiering (FAST) Fully Automated Storage Tiering (FAST) automatiza la identificación de volúmenes de datos para fines de reubicación de datos de aplicaciones entre diferentes niveles de rendimiento/capacidad dentro de un arreglo o en un arreglo externo mediante Federated Tiered Storage (FTS).1

Los beneficios principales de FAST incluyen:

• La eliminación de la necesidad de organización en niveles manual de las aplicaciones cuando los objetivos de rendimiento cambian con el tiempo.

• Automatización del proceso de identificación de datos que pueden beneficiarse de Enterprise Flash Drives o que pueden conservarse en discos SATA menos costosos y de mayor capacidad sin afectar el rendimiento.

1 Con excepción de la breve descripción general proporcionada, no se tratarán las funciones de Federated Tiered Storage en este informe técnico. Para obtener más información sobre FTS, consulte la nota técnica Design and Implementation Best Practices for EMC Symmetrix Federated Tiered Storage (FTS) disponible en Support.EMC.com (visite el sitio web de su país correspondiente).


• Mejora del rendimiento de las aplicaciones con el mismo costo o rendimiento de la misma aplicación con costo más bajo. El costo se define como gastos de adquisición (tanto de hardware como de software), de espacio/energía y de administración.

• Optimización y priorización de las aplicaciones del negocio, para permitirles a los clientes asignar recursos dinámicamente dentro un único arreglo.

• Mayor flexibilidad para cumplir con distintas relaciones precio/rendimiento durante el ciclo de vida de la información almacenada.

FAST y Fully Automated Storage Tiering con pools virtuales (FAST VP)

EMC Symmetrix FAST (FAST DP) y FAST VP automatizan la identificación de volúmenes de datos con el fin de reubicar los datos de las aplicaciones entre los diferentes niveles de rendimiento/capacidad dentro de un arreglo. FAST funciona en dispositivos Symmetrix estándar. Los movimientos de datos ejecutados entre niveles se realizan en el nivel de volumen completo. FAST VP funciona en dispositivos virtuales. Por esto, la ejecución de movimientos de datos se puede realizar en el nivel de subLUN, y un solo dispositivo delgado puede tener extensiones asignadas en varios pools delgados dentro del arreglo. Debido a que FAST DP y FAST VP son compatibles con diferentes tipos de dispositivos, estándares y virtuales respectivamente, ambos pueden funcionar simultáneamente dentro de un único arreglo.2 A excepción de algunos parámetros de configuración compartidos, la administración y el funcionamiento de cada uno están separados.

Objetos administrados por FAST

Existen tres elementos principales relacionados con el uso de FAST y FAST VP en Symmetrix VMAX, que se muestran gráficamente en la Figura 10. Son los siguientes:

• Nivel de almacenamiento: un recurso compartido con tecnologías comunes.

• Política de FAST: administra un conjunto de reglas de uso de niveles que proporciona pautas para la ubicación y la transferencia de los datos entre los niveles de Symmetrix para alcanzar los niveles de servicio y para uno o más grupos de almacenamiento.

• Grupo de almacenamiento: una agrupación lógica de dispositivos para la administración común.

La figura 10. Objetos administrados por FAST 2 Esto se aplica a toda la familia Symmetrix excepto VMAXe/VMAX 10K que solo es compatible con FAST VP, por lo cual es un arreglo completamente de aprovisionamiento delgado.


Cada uno de los tres objetos administrados puede crearse y administrarse utilizando Unisphere for VMAX (Unisphere) o Solutions Enabler Command Line Interface (SYMCLI).

Nota: Para obtener más información sobre FAST VP específicamente, consulte la nota técnica FAST VP for EMC Symmetrix VMAX Theory and Best Practices for Planning and Performance disponible en Support.EMC.com (visite el sitio web de su país correspondiente).

Asignación de FAST VP por la política de FAST Una nueva función de FAST VP en 5876 es la capacidad de que un dispositivo asigne nuevas extensiones desde cualquier pool delgado que forme parte de la política de FAST VP. Cuando esta función está activada, FAST VP intentará asignar nuevas extensiones en el nivel adecuado, en función de las métricas de rendimiento. Si esas métricas de rendimiento no están disponibles, de forma predeterminada realizará la asignación en el pool al cual está vinculado el dispositivo. No obstante, si el pool seleccionado está completo, independientemente de las métricas de rendimiento, FAST VP asignará desde uno de los otros pools delgados de la política. Mientras haya espacio disponible en uno de los pools delgados, las nuevas asignaciones de extensiones se realizarán correctamente.

Esta nueva función se configura en el nivel del arreglo de Symmetrix y se aplica a todos los dispositivos administrados por FAST VP. Por ende, no es posible aplicar la función algunas políticas de FAST VP y no a otras. De forma predeterminada, está desactivada y todas las asignaciones nuevas provendrán del pool al cual el dispositivo está vinculado.

Se considera que un dispositivo anclado no tiene métricas de rendimiento disponibles y, por lo tanto, las asignaciones nuevas se realizarán en el pool al cual el dispositivo está vinculado.

Oracle Applications Oracle Applications, también denominado Oracle E-Business Suite, es una familia estrechamente integrada de productos de aplicaciones financieras, ERP, CRM y de fabricación que comparten una apariencia estándar. Con los menús y las ventanas de Oracle Applications, los usuarios tienen acceso a todas las funciones que necesitan para administrar la información del negocio. Oracle Applications cuenta con una gran capacidad de respuesta frente a los usuarios y es compatible con una GUI de varias ventanas que proporciona a los usuarios capacidad completa del mouse. Además, Oracle Applications ofrece muchas otras funciones, tales como validaciones de campo a campo, y una lista de valores que ayuda a los usuarios a simplificar el ingreso de datos y a mantener la integridad de los datos que ingresan.


VPLEX EMC VPLEX es la tecnología de almacenamiento virtual única que federa los datos ubicados en múltiples sistemas de almacenamiento, de EMC y de otros fabricantes, y permite que los recursos de almacenamiento de múltiples centros de datos se agrupen y permitan el acceso en cualquier lugar. Cuando se combina con los servidores virtuales, es un componente crítico para obtener cómputo en la nube híbrida y privada e implementación de TI como servicio flexible, eficaz, resistente y confiable.

La familia VPLEX se ocupa de tres necesidades de TI primordiales:

• Movilidad: la capacidad de mover aplicaciones y datos entre diferentes instalaciones de almacenamiento, ya sea dentro del mismo centro de datos, a lo largo de un campus, dentro de una región geográfica o, en la actualidad, con VPLEX Geo, entre distancias aún mayores.

• Disponibilidad: la capacidad de crear infraestructuras de almacenamiento de alta disponibilidad con resistencia sin comparación entre estas mismas geografías variadas.

• Colaboración: la capacidad de ofrecer una colaboración eficiente de datos en tiempo real a lo largo de una distancia para las aplicaciones de big data, como los videos, las búsquedas geográficas u oceanográficas, etc.

Todo esto se puede realizar dentro o entre los centros de datos, ubicados a distancias síncronas o asíncronas, en un ambiente heterogéneo.

La familia VPLEX proporciona varias innovaciones y ventajas exclusivas:

• La tecnología VPLEX permite nuevos modelos de aplicación y movilidad de datos gracias al aprovechamiento del almacenamiento virtual distribuido. Por ejemplo, VPLEX se encuentra optimizado específicamente para plataformas de servidores virtuales (como VMware ESXi, Hyper-V, Oracle Virtual Machine y AIX VIOS) y puede simplificar e incluso acelerar la reubicación transparente del tipo de carga a través de distancias, lo que incluye la transferencia de máquinas virtuales entre distancias.

• Gracias a su arquitectura en cluster única, con escalamiento horizontal y de alta disponibilidad, VPLEX puede configurarse con uno, dos o cuatro motores. También es posible agregar motores al cluster VPLEX de manera no disruptiva. Todos los volúmenes virtuales que presenta VPLEX son accesibles en todo momento desde cualquier motor de un cluster VPLEX. Del mismo modo, todos los almacenamientos físicos conectados a VPLEX son accesibles desde cualquier motor en el cluster VPLEX. En combinación, esta arquitectura de escalamiento horizontal asegura de manera exclusiva la disponibilidad máxima, la tolerancia a los fallos y el rendimiento escalable.

• La colaboración de datos avanzada, mediante AccessAnywhere, brinda acceso activo/activo y de memoria caché consistente a los datos ubicados en dos clusters VPLEX a distancias síncronas con VPLEX Metro y a distancias asíncronas con VPLEX Geo.


Movilidad

La movilidad de aplicaciones y datos permite la transferencia de máquinas virtuales (VM) sin tiempo fuera. Los administradores de almacenamiento también pueden balancear cargas automáticamente mediante VPLEX utilizando los recursos informáticos y de almacenamiento de cualquiera de los clusters. Cuando se combina con la virtualización de servidores, VPLEX permite mover y reubicar de manera transparente máquinas virtuales y sus correspondientes aplicaciones y datos a distancia. Esto brinda una función única que permite reubicar, compartir y balancear recursos de infraestructura entre sitios, por ejemplo, dentro de un campus o entre centros de datos, con una latencia de ciclo de ida y vuelta (RTT) de hasta 50 ms entre sí con VPLEX Metro, o a mayor distancia entre distancias asíncronas con VPLEX Geo.

Disponibilidad

Al proporcionar redundancia, flexibilidad y concientización (con VPLEX Witness), GeoSynchrony admite un objetivo de tiempo de recuperación (RTO) reducido y un objetivo de punto de recuperación (RPO).

Todas estas funciones permiten la mayor resistencia posible en caso de una interrupción.

Ofertas de productos VPLEX VPLEX primero satisface los requisitos de movilidad de datos y alta disponibilidad y, luego, escala al rendimiento de I/O requerido para las aplicaciones de front-end y el almacenamiento de back-end.

Las tres ofertas de productos disponibles de VPLEX que se muestran en la Figura 11 junto con una configuración opcional de RecoverPoint son:

• VPLEX Local

• VPLEX Metro

• VPLEX Geo

La figura 11. Configuraciones de VPLEX


Un cluster VPLEX consta de un solo motor, dos motores o cuatro motores y un servidor de administración. Cada motor contiene dos directores. Un cluster de dos o cuatro motores también contiene un par de switches Fibre Channel para la comunicación entre directores y un par de fuentes de alimentación ininterrumpida (UPS) como respaldo de alimentación de la batería de los switches Fibre Channel y el servidor de administración.

El servidor de administración tiene un puerto Ethernet público, que brinda servicios de administración de cluster cuando se conecta a la red del cliente.

VPLEX Local ofrece movilidad de datos transparente y no disruptiva, y permite administrar y realizar el espejeado de varios arreglos heterogéneos desde una sola interfaz dentro de un centro de datos. VPLEX Local consta de un solo cluster VPLEX. VPLEX Local es una arquitectura de última generación que permite mayor disponibilidad, una administración simplificada y una mejor utilización y disponibilidad entre varios arreglos.

VPLEX Metro permite el acceso activo/activo, en el nivel de bloque, a los datos entre dos sitios a distancias síncronas. La distancia es limitada debido a la distancia física y también por los requisitos del host y las aplicaciones. Según la aplicación, los clusters VPLEX se deben instalar con enlaces entre clusters compatibles con un ciclo de ida y vuelta (RTT) de hasta 5 ms.

La combinación de almacenamiento virtual con VPLEX Metro y servidores virtuales permite el movimiento transparente de máquinas virtuales y el almacenamiento en instancias síncronas. Esta tecnología proporciona una mejor utilización y disponibilidad en arreglos heterogéneos y múltiples sitios.

VPLEX Geo permite el acceso activo/activo, en el nivel de bloque, a los datos entre dos sitios a distancias asíncronas. VPLEX Geo permite un uso más rentable de los recursos y la alimentación.

VPLEX Geo amplía la distancia para los dispositivos distribuidos y con un ciclo de ida y vuelta de hasta 50 ms. Al igual que con cualquier medio de transporte asíncrono, también se debe tener en cuenta el ancho de banda para garantizar el rendimiento óptimo. Debido a la naturaleza asíncrona de la escritura distribuida, VPLEX Geo cuenta con diferentes características de rendimiento y disponibilidad que Metro.

Para todos los productos VPLEX, GeoSynchrony:

• Presenta volúmenes de almacenamiento desde arreglos de back-end a los motores de VPLEX.

• Federa los volúmenes de almacenamiento en jerarquías de volúmenes virtuales de VPLEX con niveles de protección y configuración definidos por el usuario.

• Presenta volúmenes virtuales a los hosts de producción en la red SAN a través del front-end de VPLEX.

• Para los productos VPLEX Metro y VPLEX Geo, presenta un directorio global en el nivel de bloques para caché distribuida e I/O entre clusters de VPLEX.

La ubicación y la distancia determinan los requisitos de alta disponibilidad y movilidad de datos.


Cuando los arreglos de almacenamiento de back-end o los hosts de aplicaciones abarcan dos centros de datos, la función AccessAnywhere de VPLEX Metro o VPLEX Geo federa el almacenamiento en una configuración activo/activo entre clusters de VPLEX. La elección entre VPLEX Metro o VPLEX Geo depende de la distancia y de los requisitos de disponibilidad y sincronicidad de los datos.

El rendimiento de I/O del almacenamiento de back-end y de aplicaciones, junto con los requisitos de disponibilidad, determinan la cantidad de motores en cada cluster VPLEX.

Las funciones de alta disponibilidad dentro del cluster VPLEX permiten actualizaciones de software no disruptivas y la expansión de hardware a medida que crece el rendimiento de I/O.

Volúmenes de registro

Los volúmenes de registro se utilizan para hacer un seguimiento de los bloques escritos durante un fallo en el enlace entre clusters o cuando un tramo de un RAID-1 distribuido no está disponible y luego se recupera. Después de que se restaure un fallo del enlace o se recupere un tramo no disponible, VPLEX utiliza la información de los volúmenes de registro para sincronizar los espejeados enviando únicamente los bloques modificados por medio del enlace.

Redundancia con RecoverPoint

EMC RecoverPoint brinda protección de datos integral para la replicación continua (split) de la escritura en el host. Con RecoverPoint, las aplicaciones se pueden recuperar a cualquier punto en el tiempo. Las escrituras replicadas se pueden escribir en volúmenes locales para proporcionar recuperación de desastres operacionales, en volúmenes remotos para brindar recuperación de desastres, o en ambos.

RecoverPoint admite tres tipos de splitters:

• Splitters basados en sistema operativo del host

• Splitters basados en fabric inteligente (SANTap y Brocade)

• Splitters basados en almacenamiento (CLARiiON CX4, VNX y Symmetrix VMAX)

A partir de GeoSynchrony 5.1, VPLEX incluye un splitter de RecoverPoint basado en almacenamiento. El splitter está incorporado en VPLEX de forma tal que es posible replicar la actividad de I/O de los volúmenes VPLEX a través de dispositivos RecoverPoint a volúmenes ubicados en VPLEX o en uno o más arreglos de almacenamiento heterogéneos.

Para GeoSynchrony 5.1, la integración de RecoverPoint se ofrece para configuraciones de VPLEX Local y VPLEX Metro (no para Geo).

El splitter VPLEX permite que los volúmenes VPLEX en un sistema VPLEX Local o VPLEX Metro realicen el espejeado de I/O en un dispositivo RecoverPoint que realiza protección continua de datos (CDP), replicación remota continua (CRR) o protección de datos local y remota simultánea (CLR).


VASA con VPLEX

La API de VMware vStorage para Storage Awareness o VASA está disponible con los arreglos de VPLEX y se puede configurar dentro de VMware vCenter. El proveedor de VASA de VPLEX se implementa como una aplicación virtual. Figura 12 muestra la configuración desde vCenter.

La figura 12. Registro de proveedor de VASA de VPLEX

El proveedor de VASA incluye las capacidades de almacenamiento que se pueden utilizar para categorizar máquinas virtuales, áreas de almacenamiento de datos, etc. Las capacidades predeterminadas que se incluyen con el proveedor se muestran en la Figura 13.

La figura 13. Capacidades de almacenamiento de VASA de VPLEX


Los detalles acerca de la implementación de VASA están fuera del alcance de este informe técnico. Si desea obtener más detalles, utilice VPLEX Procedure Generator, que se puede encontrar en Support.EMC.com (visite el sitio web de su país correspondiente).

FAST VP y Oracle Applications 12

Arquitectura de las aplicaciones

La arquitectura de Oracle Applications es un marco de trabajo para la informática distribuida de múltiples niveles compatible con los productos Oracle Applications. En este modelo, se distribuyen varios servidores o servicios entre tres niveles.

Un nivel es una agrupación lógica de servicios, con capacidad para repartirse entre más de una máquina física o virtual. La arquitectura de tres niveles que comprende una instalación de Oracle E-Business Suite está compuesta por el nivel de las bases de datos, que admite y administra la base de datos Oracle; el nivel de las aplicaciones, que admite y administra los diferentes componentes de las aplicaciones y que en ocasiones se denomina nivel medio; y el nivel de los escritorios, que proporciona la interfaz de usuario mediante un componente adicional a un navegador web estándar.

La arquitectura más simple para Oracle Applications es tener todos los niveles, excepto el de escritorios, instalados en un solo servidor. Esta configuración podría ser aceptable en un ambiente de desarrollo, pero para ambientes de producción el escalamiento se convertiría rápidamente en un problema. Por lo tanto, a fin de imitar un entorno de producción más realista, la arquitectura del ambiente de prueba se basa en dos niveles físicos de aplicaciones y dos niveles de base de datos. Los componentes de la arquitectura de Oracle Applications se pueden ver en la Figura 14.


La figura 14. Arquitectura de Oracle Applications

Trabajar con FAST VP y Oracle Applications en VMware vSphere

Debido a la diversidad de Oracle Applications, ya que existen cientos de módulos diferentes dentro de un solo producto, implementarlos adecuadamente en el nivel correcto es una tarea abrumadora. Realizar la implementación en un ambiente VMware que utiliza VPLEX y FAST VP en el arreglo subyacente demostrará de qué manera un cliente puede lograr un rendimiento adecuado y ahorros de costos al mismo tiempo. Para este informe, se instaló y configuró la versión más reciente de Oracle Applications 12. Utilizar la versión más reciente brinda algunos beneficios. En primer lugar, Oracle preconfigura la versión 12 con la versión 11g de la base de datos Oracle. La 11g es la versión de base de datos Oracle más reciente y representa un avance significativo sobre la 10g en cuanto a rendimiento y funcionalidad. En segundo lugar, ahora Oracle se ha disociado de la práctica de tener dos espacios de tablas y, por lo tanto, al menos dos archivos de datos por aplicación. Antes de la versión 12, cada módulo de Applications tenía su propio conjunto de espacios de tablas y archivos de datos, uno para los datos y otro para el índice. Con más de 200 esquemas, administrar una base de datos de más de 400 espacios de tablas y archivos de datos era, y sigue siendo, una tarea considerable. El enfoque nuevo que Oracle utiliza en la versión 12 se denomina modelo de espacios de tablas para aplicaciones Oracle u OATM.


Modelo de espacios de tablas para aplicaciones Oracle

Las versión 12 de Oracle Applications utiliza como estándar una infraestructura moderna para la administración de los espacios de tablas, el Modelo de espacios de tablas para aplicaciones Oracle (OATM). El OATM es similar al modelo tradicional en cuanto a conservar el sistema, las acciones canceladas y los espacios de tablas temporales. La diferencia clave es que los productos de Applications en un ambiente OATM comparten un número mucho menor de espacios de tablas, en lugar de tener sus propios espacios de tablas dedicados.

Los objetos del esquema de aplicaciones se asignan a los espacios de tablas compartidos sobre la base de dos factores principales: el tipo de datos que contienen y las características de I/O, tales como el tamaño, la vida útil, los métodos de acceso y la granularidad del bloqueo. Por ejemplo, las tablas que contienen datos de origen se asignan a un espacio de tabla diferente que las tablas que contienen datos transaccionales. Además, mientras que la mayoría de los índices se mantienen en el mismo espacio de tabla que la tabla base, los índices en las tablas de transacciones se mantienen en un único espacio de tabla dedicado a dichos índices.

Implementación de Oracle Applications

La implementación por parte de un cliente de Oracle Applications no es un proceso rápido. La instalación en sí misma es solamente la primera parte de lo que puede ser un esfuerzo que dure muchos meses o más. A pesar de que hay casi 200 módulos de aplicaciones en Oracle Applications, los clientes rara vez los utilizan todos, si es que alguna vez lo hacen. Utilizan una selección de ellos o, quizás, un paquete, tal como Financials o CRM. Luego, estos módulos se implementan (por lo general) en un enfoque por fases. La transición desde un sistema de aplicaciones existente o la implementación de uno nuevo lleva tiempo. Cómo se utilizará al final ese sistema y, más importante aún, cómo se accederá a esa base de datos representa un verdadero reto para el administrador del sistema y de la base de datos. Estas personas tienen la tarea de proporcionar el rendimiento adecuado para la aplicación adecuada al precio correcto. En otras palabras, tanto la optimización del rendimiento como del costo es extremadamente importante; sin embargo, no es una tarea sencilla lograr el equilibrio entre ambas. Las tres tecnologías de discos que se utilizan en los arreglos para respaldar VPLEX en este ambiente, SATA, FC y EFD, tienen características de rendimiento distintas y costos muy diferentes. Por ejemplo, ¿cómo decidirá el administrador qué parte de la base de datos pertenece a las varias tecnologías de discos que representan el balanceo de costo y rendimiento que intenta lograr cada día? Esto se torna aún más difícil con el nuevo modelo de espacios de tablas para Oracle Applications. El nuevo modelo de Oracle ciertamente hace un buen trabajo en la consolidación de objetos de las bases de datos de alto nivel, con menos espacios de tablas y menos archivos de datos, pero dado que los módulos de aplicaciones ya no están separados en espacios de tablas y archivos de datos individuales, en efecto, no hay una forma práctica de poner los módulos diferentes en niveles de almacenamiento distintos; hasta ahora. FAST VP es el complemento perfecto para la forma en que Oracle implementa la base de datos en la versión 12 del conjunto de aplicaciones Oracle. De hecho, toda la base de datos de los datos del usuario puede colocarse en un único punto de montaje en un disco virtual VMware y, a pesar de eso, aún puede repartirse en las tecnologías de discos adecuadas que se adapten a los requisitos del negocio. FAST VP posibilita la simplicidad de este modelo de implementación.


Para obtener más detalles sobre la implementación de Oracle Applications en un ambiente con FAST VP consulte el informe técnico Storage Tiering for VMware Environments Deployed on EMC SYMMETRIX VMAX with Enginuity 5876 en EMC.com (visite el sitio web de su país correspondiente). El caso de uso presentado en ese documento es similar a la implementación de FAST VP que se usa en este informe técnico.

Implementación de Oracle Applications

El ambiente VMware de Oracle Applications implementado en este estudio consta de dos servidores ESXi 5.1 con un total de cuatro máquinas virtuales, enumeradas en la Tabla 1. Un VMware vCenter Server administra el ambiente. Figura 15 es una representación visual del ambiente.

Tabla 1. Ejemplo de ambiente

Máquina virtual Nombre Modelo SO y versión

CPU RAM (GB)

Disco

Nivel de base de datos RAC, nodo 1

dsib2124 Máquina virtual de VMware

OEL 5 64 bits

4 8 SAN

Nivel de base de datos RAC, nodo 2


OEL 5 64 bits

4 8 SAN

Nivel de aplicaciones 1


OEL 5 64 bits

1 2 SAN

Nivel de aplicaciones 2


OEL 5 64 bits

1 2 SAN

vCenter de producción


Win2008 64 bits

2 4 SAN

vCenter de recuperación


Win2008 64 bits

2 4 SAN

VPLEX Metro Witness

dsib2013 vApp Linux personalizado

1 0.5 SAN

VPLEX VASA dsib2111 vApp Linux personalizado

1 3.6 SAN

EMC Symmetrix VMAX

HK198700067 VMAX 10K Microcódigo 5876.229.145

VPLEX cluster-1 SATA, FC, EFD

EMC Symmetrix VMAX


VPLEX cluster-2 con splitter de RP

SATA, FC, EFD

EMC Symmetrix VMAX


Splitter de sitio remoto con splitter

de RP

SATA, FC, EFD


Diseño de hardware

La figura 15. Diagrama del ambiente físico/virtual

FAST VP en el cluster VPLEX Metro Dado que el cluster VPLEX Metro tiene el respaldo de los arreglos VMAX, y el sitio remoto con RecoverPoint también es un arreglo VMAX, el ambiente aprovecha FAST VP. Cada arreglo tiene tres tecnologías de discos: EFD, FC y SATA. Los discos están configurados de la siguiente manera:

• EFD: RAID-5 3+1

• FC: RAID 1 o espejeado bidireccional

• SATA: RAID-6 (6+2)


La captura de pantalla de la Figura 16 muestra lo siguiente:

La figura 16. Configuración del pool delgado para el arreglo VMAX detrás de VPLEX

Para los dos arreglos en la configuración de VPLEX Metro, la capacidad activada en los pools es casi la misma. Para el sitio de recuperación de desastres, los pools son más grandes, ya que sirven como ambiente de prueba y desarrollo mientras la recuperación de desastres no está activada. Los ajustes de configuración generales para FAST VP se muestran en la Figura 17.

La figura 17. Configuración del sistema FAST VP


La mayoría de los ajustes de configuración se dejaron con el valor predeterminado, con algunas excepciones notables. En primer lugar, se usó la asignación por política de FAST. Esta función se explicó anteriormente y no solo ayuda a colocar la nueva extensión en el nivel adecuado, sino que, si el pool de vinculación está lleno, utilizará otro. La segunda excepción es para la compresión, ya que se activó la compresión de los pools delgados incluidos en la política de FAST VP. La versión de Enginuity 5876.159.102 presenta las capacidades de compresión para ambientes aprovisionados virtualmente (compresión de VP) que proporciona a los clientes una compresión de datos de 2:1 o mayor para datos de acceso poco frecuente3. FAST VP administra automáticamente la compresión. Tenga en cuenta que, para este ambiente, se configuró la cantidad máxima de días (400) ya que los datos financieros requerirán la ejecución de informes mensuales, trimestrales y de fin de año. Ejecutar estos informes a partir de datos comprimidos sería demasiado costoso en términos de potencia de procesamiento y tiempo.

Todos los demás discos de la base de datos se convertirán en parte de la política de FAST VP, denominada EBS_Policy. En esta política, los registros de RecoverPoint también se asignan. Los registros de RecoverPoint aprovechan el mismo conjunto de tecnologías de disco que nuestra base de datos. Los porcentajes de la política de las tecnologías de disco utilizadas en este caso de uso reflejan dos realidades: primero, EFD y FC son medios más costosos que SATA y, segundo, y más importante, solo un pequeño porcentaje de una aplicación o base de datos se utilizará regularmente. FAST está diseñado para usar el disco que se le proporciona. Si el costo no fuera un problema, la mejor política para instituir es 100/100/100, lo que permitirá que FAST use sin inconvenientes el porcentaje de cada nivel que sea necesario. Lamentablemente, en el mundo real el precio es una de las primeras inquietudes. Por lo tanto, los clientes tienen más probabilidades de tener cantidades menores de FC y EFD en su sistema Symmetrix que SATA. Como consecuencia, queda menos para dedicar a una política de FAST VP. Sin embargo, la buena noticia es que la mayoría de los datos en las bases de datos y aplicaciones son de acceso poco frecuente y es poco probable que se requiera una gran cantidad de discos más rápidos, como EFD. Dado que se trata de una implementación de RecoverPoint, la cantidad de espacio necesario para los registros también debe considerarse.

Para cada arreglo, en la Figura 18 se muestran los porcentajes utilizados para la política: 10 % para EFD, 50 % para FC y 100 % para SATA.

La figura 18. Política de FAST VP para el ambiente Oracle EBS

3 A partir de datos que el motor de compresión puede comprimir realmente.


Las políticas de FAST VP deben asociarse a los grupos de almacenamiento para que funcionen en los dispositivos. Más de un grupo de almacenamiento puede asignarse a la misma política, como ocurre en este ambiente, o se pueden crear varias políticas para cada grupo de almacenamiento. Existen varias formas de asignar los grupos de almacenamiento a la política de FAST VP. En la Figura 19, se utiliza la pantalla de grupos de almacenamiento de Unisphere for VMAX. El proceso de cuatro pasos que se muestra es:

1. Seleccionar el grupo de almacenamiento.

2. Seleccionar el botón “Asociar a FAST”.

3. Elegir la política de FAST VP que se asociará.

4. Seleccionar “Aceptar” para finalizar.

La figura 19. Asociación de una política de FAST VP a un grupo de almacenamiento


Este proceso se repite en cada arreglo para los dos grupos de almacenamiento utilizados en cada uno. Figura 20 y Figura 21, se muestra la configuración de FAST VP de cada arreglo que forma parte del cluster VPLEX Metro. Tenga en cuenta que cada arreglo en los grupos de almacenamiento cumple las normas, lo que significa que hay suficiente espacio de pool delgado en cada uno de los niveles para satisfacer la asignación de extensiones en los dispositivos.

La figura 20. Descripción general de FAST VP de la política EBS_Policy en VMAX detrás del cluster-1 de VPLEX


La figura 21. Descripción general de FAST VP de la política EBS_Policy en VMAX detrás del cluster-2 de VPLEX

Aunque no se muestran explícitamente en la Figura 21, los grupos de almacenamiento del arreglo de cluster-2 tienen un mayor requisito de capacidad que los del arreglo cluster-1. El motivo es que cluster-2 también es el sitio local de RecoverPoint. Por lo tanto, hay dispositivos de registro para cada dispositivo correspondiente en la relación distribuida con el arreglo de cluster-1. Esto es importante de recordar cuando se configura un ambiente de cliente: los requisitos de almacenamiento serán superiores para el cluster VPLEX Metro que cumple la doble función de implementación local de RecoverPoint. Si los arreglos de cluster tienen una configuración similar, es posible que uno o más grupos de almacenamiento no cumplan las normas cuando se asocien por primera vez con una política de FAST VP. Esto de por sí no es necesariamente negativo, ya que hay varias extensiones que pueden reubicarse en el nivel SATA donde la política indica que puede residir el 100 % de los dispositivos. Por lo tanto, los grupos de almacenamiento entrarán en cumplimiento de normas poco tiempo después del período de análisis inicial de FAST.


Sitio remoto de RecoverPoint

Así como los dos arreglos asociados con VPLEX Metro emplearán FAST VP para el ambiente, el sitio de recuperación de desastres, VMAX 10K, también lo hará. El VMAX 10K utilizado en la configuración tiene la ventaja de contar con un pool de FC más grande que los arreglos en la configuración de VPLEX y, por lo tanto, incluso con el almacenamiento adicional ordenado por los registros, el grupo de almacenamiento está en cumplimiento de normas inmediatamente después de la asociación con la política de FAST VP. Tenga en cuenta que el sitio de recuperación de desastres que se muestra en la Figura 22 usa un solo grupo de almacenamiento, a diferencia del ambiente de producción. Esta es solo una elección. Las réplicas y los registros se pueden separar en diferentes grupos de almacenamiento y, luego, asociar cada grupo con la misma política de FAST VP. Los requisitos de capacidad, sin embargo, serán los mismos.

Generalmente, los registros en el sitio de recuperación de desastres permanecerán en el disco de mayor rendimiento, tal como FC, porque tienen un nivel elevado de escritura. El caso con la réplica es diferente, pero si se invoca la recuperación de desastres, FAST VP mueve las extensiones de producción a niveles de mayor rendimiento en función del cambio de los patrones de acceso.

La figura 22. Descripción general de FAST VP de EBS_Policy en VMAX en el tercer

sitio con RecoverPoint


Anclaje de dispositivos en FAST VP para la base de datos de Oracle Cuando una política de FAST VP se asocia a un grupo de almacenamiento, también se asocian todos los dispositivos del grupo de almacenamiento. Es posible que sea necesario, o recomendable, evitar que FAST VP mueva las extensiones de algunos dispositivos en el grupo de almacenamiento. Por ejemplo, si hay un dispositivo en el grupo que se utilizará como respaldo para un área de almacenamiento de datos VMFS para las imágenes ISO y se ha vinculado a un pool de SATA, no habría ningún motivo para remitir las extensiones de ese dispositivo. Entonces, mientras se obtiene acceso a él para el uso previsto, hay muy poca posibilidad de que FAST VP ascienda de nivel las extensiones del dispositivo, pero el acceso accidental al área de almacenamiento de datos para una máquina virtual de I/O intensivo podría hacerlo. En este caso, puede resultar mejor simplemente “anclar” el dispositivo. El anclaje impedirá que FAST VP mueva cualquier extensión del dispositivo y la conservará en SATA.

En el ambiente VPLEX Metro, solamente hay dos dispositivos anclados de cada arreglo, los dispositivos REDO de la base de datos. Estos siempre requerirán capacidades de FC RAID 1, por lo que se conservarán en el pool de FC. SATA sería demasiado lento, mientras EFD no sería rentable dada la intensa actividad de escritura de los logs.

Anclaje de dispositivos REDO en FAST VP

El anclaje de un dispositivo se puede realizar en Unisphere for VMAX o por medio de la SYMCLI. En Unisphere, como se muestra en la Figura 23, se navega a través de la ruta de menú: arreglo -> Almacenamiento -> Grupos de almacenamiento, para establecer un disco REDO. El usuario después destaca el dispositivo y hace clic en el icono de la doble flecha en el menú inferior. En el menú emergente, el usuario selecciona “Anclar”. Al anclar el dispositivo, no existe riesgo de que el motor FAST pudiera transferir los grupos de extensiones que pertenecen a ese dispositivo. Tenga en cuenta que se pueden seleccionar varios dispositivos a la vez para anclarlos.


La figura 23. Anclaje de un dispositivo en Unisphere for VMAX


Dispositivos distribuidos VPLEX y grupos de consistencia Los volúmenes que se usan en todo el ambiente constan de dispositivos distribuidos que se incorporan en los grupos de consistencia. Esto es necesario para la integración con RecoverPoint, aunque siempre es una mejor práctica utilizar grupos de consistencia. Los grupos de consistencia se construyen en torno a Oracle RAC y Oracle Applications E-Business Suite.

Ejemplo de aprovisionamiento de almacenamiento

En esta sección se explican la creación de un dispositivo distribuido y su grupo de consistencia y la posterior presentación a un host ESXi y a los dispositivos RecoverPoint. En el ejemplo, se muestra el mismo proceso que se repite para todos los dispositivos distribuidos requeridos en el ambiente RAC extendido de Oracle E-Business Suite. La interfaz que se usa para este ejemplo es Unisphere for VPLEX.

Dado que el proceso de creación de un dispositivo distribuido depende de un dispositivo de almacenamiento de cada cluster VPLEX Metro y un volumen virtual, solo se usará un cluster en el ejemplo. Un proceso duplicado debería ejecutarse en el otro cluster en VPLEX Metro. Tenga en cuenta que como solo se necesita un volumen virtual entre los dos clusters, uno de los volúmenes virtuales se quitará de uno de los clusters y se dejará solo el dispositivo de almacenamiento. El proceso de eliminación del volumen virtual se describe a continuación.

La interfaz GUI de Unisphere for VPLEX proporciona un asistente simplificado que ayuda al usuario en todo el proceso, desde la asignación del almacenamiento hasta la creación del volumen virtual. Por supuesto, existe la posibilidad de adoptar un enfoque gradual al crear un volumen virtual en caso de que haya necesidades específicas, tal como ajustar el tamaño de la extensión o cambiar la configuración de RAID si, por ejemplo, no se usara Symmetrix VMAX o un arreglo de EMC detrás de VPLEX. Afortunadamente, al usar arreglos avanzados como VMAX, las selecciones predeterminadas son las correctas y, por lo tanto, se presenta el asistente simplificado.


Comenzamos el proceso redescubriendo el arreglo en la Figura 24. Esto forzará a reexaminar los HBA para determinar si se ha presentado algún almacenamiento nuevo de VMAX a VPLEX.

La figura 24. Aprovisionamiento de almacenamiento: redescubrimiento del arreglo para los nuevos volúmenes


Asistente de volúmenes virtuales de VPLEX

Una vez que se descubra el almacenamiento, es necesario asignarlo y luego construir un volumen virtual. Esto se realiza mediante un asistente con un solo botón. En la misma pantalla, se selecciona “Crear volúmenes virtuales”, tal como se muestra en la Figura 25.

La figura 25. Aprovisionamiento de almacenamiento: creación de volúmenes virtuales


La primera pantalla solicita optar entre el uso de almacenamiento liberado o asignado. Dado que el almacenamiento recién se ha presentado al VMAX, el almacenamiento está liberado y el botón de opción está seleccionado para reflejar esta situación en la Figura 26.

La figura 26. Aprovisionamiento de almacenamiento: asignación de almacenamiento liberado

En el siguiente paso para VMAX, como se puede observar en la oración destacada en la Figura 27, no es necesario preocuparse por un archivo de mapeo. En este caso, se desea utilizar reconstrucciones delgadas porque todos los dispositivos están aprovisionados en VMAX 10K, un arreglo completamente delgado. VPLEX no detecta automáticamente si un volumen de almacenamiento tiene aprovisionamiento delgado en el arreglo. Cuando se selecciona una reconstrucción delgada, VPLEX conserva la delgadez del dispositivo de destino copiando únicamente los datos diferentes de cero.

La figura 27. Aprovisionamiento de almacenamiento: uso de reconstrucciones delgadas


En la pantalla que se muestra en la Figura 28, se selecciona el único dispositivo que descubrió VPLEX y se solicita la recuperación.

La figura 28. Aprovisionamiento de almacenamiento: asignación de almacenamiento


En la pantalla final que se muestra en la Figura 29, se ofrece la opción de asignar un nombre al volumen virtual. De modo predeterminado, VPLEX asignará un nombre que utilice el ID del arreglo y el ID del dispositivo del arreglo. El nombre se puede personalizar según lo desee. Sin embargo, usar un identificador que se vincule al cluster en el cual se está creando el volumen virtual puede ser útil para los ejercicios posteriores de solución de problemas o en otras herramientas que muestran el nombre al usuario.4 En el siguiente ejemplo, por este motivo, el nombre que se utiliza es “VPLEX_DEMO_cluster-1”.

La figura 29. Aprovisionamiento de almacenamiento: creación del volumen virtual

4 Como se mencionó anteriormente, los nombres de sistema que se generan de manera predeterminada usan una combinación del ID del arreglo y el ID del dispositivo. Si bien esto puede resultar útil inicialmente para distinguir entre los arreglos de almacenamiento de respaldo, las actualizaciones tecnológicas pueden cambiar completamente los arreglos, y la información de los arreglos ya no sería relevante. Puede tener sentido, por lo tanto, usar los nombres relacionados con los hosts o las aplicaciones para los objetos de almacenamiento o, en este caso, por cluster.


Los resultados finales se presentan en la Figura 30, para cluster-1 y para el volumen virtual correspondiente al dispositivo distribuido en cluster-2.

La figura 30. Aprovisionamiento de almacenamiento: volúmenes virtuales VPLEX_DEMO_cluster-1 y VPLEX_DEMO_cluster-2


Una vez que se instalen los volúmenes virtuales en cada cluster, necesitamos quitar el volumen virtual del cluster-2, ya que solo se necesita recuperar un volumen virtual para el dispositivo distribuido. Dado que hay un volumen virtual en cluster-1, se le agregará un espejeado remoto.5 La eliminación del volumen virtual es muy sencilla con el asistente. Para comenzar, seleccione el volumen virtual “VPLEX_DEMO_cluster-2” en la vista de volúmenes virtuales para cluster-2 y seleccione “Eliminar”, tal como se muestra en la Figura 31.

La figura 31. Aprovisionamiento de almacenamiento: eliminación del volumen virtual

5 Para obtener una explicación detallada de la relación entre volúmenes virtuales de VPLEX, dispositivos, extensiones y volúmenes de almacenamiento, seleccione el menú Aprovisionamiento de almacenamiento y la opción Descripción general del aprovisionamiento en Unisphere for VPLEX.


A continuación, confirme que desea eliminar el volumen virtual y cierre la pantalla de resumen, ambas se muestran en la Figura 31. La eliminación del volumen virtual solo elimina ese objeto y deja el dispositivo de almacenamiento subyacente. Este dispositivo ahora puede utilizarse como espejeado remoto del volumen virtual y dispositivo de almacenamiento subyacente en cluster-1. Después de la eliminación, es posible que el usuario desee cambiar el nombre del dispositivo de almacenamiento a un formato similar al que se utiliza en la creación del volumen virtual. En este ejemplo, el nombre del dispositivo de almacenamiento de cluster-2 en Unisphere se cambió a “device_VPLEX_DEMO_cluster-2”.

La figura 32. Aprovisionamiento de almacenamiento: confirmación de la eliminación del volumen virtual

Con el volumen virtual en cluster-1 y el dispositivo correspondiente en cluster-2, estamos preparados para agregar un espejeado remoto. Al agregar un espejeado remoto en el cluster-2, el volumen virtual de cluster-1 estará disponible en ambos clusters. Esto se debe a que el dispositivo debajo del volumen virtual ahora es un dispositivo distribuido.

Se utilizó a la misma convención de asignación nombres para el volumen virtual en cluster-1 y el dispositivo de almacenamiento de cluster-2: VPLEX_DEMO_cluster-1 en cluster-1 y device_VPLEX_DEMO_cluster-2 en cluster-2.


Tenga en cuenta que la creación de dispositivos distribuidos fallará si el dispositivo en ambos cluster tiene el mismo nombre o si el dispositivo remoto es más pequeño que el dispositivo del que se está creando el espejeado. Unisphere for VPLEX no proporcionará advertencias hasta que finalice el asistente y se intente la creación. Por lo tanto, asegúrese de que cada nombre de dispositivo sea único y que el dispositivo remoto sea mayor o igual que el dispositivo del que se está creando el espejeado.

Creación de un dispositivo distribuido VPLEX

Todavía en el asistente de aprovisionamiento, en el menú de la izquierda, seleccione cluster-1 y, luego, Volúmenes virtuales. Resalte el volumen virtual en cluster-1, VPLEX_DEMO_cluster-1. Seleccione “Agregar espejeado remoto” para iniciar el proceso de creación de un dispositivo distribuido. Este proceso se muestra en la Figura 33.

La figura 33. Dispositivos distribuidos: adición de espejeado remoto


En la pantalla siguiente, el volumen virtual ya se encuentra preseleccionado, así que solo se necesita hacer clic en “Siguiente” para continuar. Este caso se ilustra en la Figura 34.

La figura 34. Dispositivos distribuidos: adición de volumen virtual


Dado que hay un solo dispositivo de tamaño adecuado configurado en cluster-2 con el que se puede vincular, el mapeo de espejeado que se muestra en la Figura 35 es simple. Este caso suele ser la excepción, no la regla, y es el motivo por el cual las convenciones de asignación de nombres son importantes para los dispositivos de cada cluster. Puede haber muchos dispositivos del mismo tamaño, y usar solo los nombres del sistema complicaría lo que debe ser un proceso relativamente sencillo. Después de destacar el dispositivo de cluster-1 y de cluster-2, seleccione el botón “Agregar espejado” y haga clic en “Siguiente” o “Finalizar”.

La figura 35. Dispositivos distribuidos: selección de espejeado remoto para el dispositivo distribuido

En la pantalla siguiente, Figura 36, ahora se puede elegir agregar este dispositivo distribuido a un grupo de consistencia existente, o crear uno nuevo. Optaremos por crear uno nuevo y asignarle el mismo nombre que el nombre base para los dispositivos locales, VPLEX_DEMO. Además del grupo de consistencia, se debe aplicar un conjunto de reglas al grupo de consistencia.


Conjunto de reglas y RecoverPoint

El conjunto de reglas define qué cluster VPLEX continuará la actividad de I/O en caso de una partición de WAN doble entre los clusters VPLEX. El sitio elegido seguirá brindando servicio para el I/O del host. Dado que se está usando RecoverPoint en la implementación, se debe elegir el sitio donde está configurado RecoverPoint, o cluster-2, aunque se debe tener presente que VPLEX no impedirá que el usuario seleccione alguna de las otras opciones.6 Esto se debe a que si existe una partición de WAN, es conveniente asegurarse de que los volúmenes protegidos por RecoverPoint sean los que sigan recibiendo I/O. Si se seleccionara cluster-1, RecoverPoint no replicaría los cambios y, por lo tanto, el sitio de recuperación de desastres representaría un punto en el tiempo del fallo de WAN.

La figura 36. Dispositivos distribuidos: creación de un grupo de consistencia

6 Afortunadamente, incluso si se generara un conjunto de reglas incorrecto, una vez que el grupo de consistencia de RecoverPoint se active, VPLEX forzaría el conjunto de reglas correcto y evitaría que el usuario lo modifique.


La pantalla final que se muestra en la Figura 37 resume todo. La pantalla de resultados que se muestra en la Figura 38 indica si la creación se realizó correctamente.

La figura 37. Dispositivos distribuidos: nombre del volumen virtual

La figura 38. Dispositivos distribuidos: análisis de resultados


Estado de fallo de un dispositivo distribuido

Tenga en cuenta que, cuando se sincronizan los dispositivos, Unisphere informa los errores en el dispositivo distribuido porque se está reconstruyendo.7 Este estado se destaca en la Figura 39. Una vez que el estado es “Correcto”, se pueden ejecutar los pasos restantes para que este dispositivo se pueda utilizar en el ambiente.

La figura 39. Dispositivos distribuidos: reconstrucción del estado

La velocidad de reconstrucción se puede controlar ajustando el parámetro de tamaño máximo de transferencia en cada dispositivo distribuido. El valor predeterminado es 128 KB y puede aumentarse según la velocidad de sincronización necesaria. Si aún no se utilizan los volúmenes virtuales, es seguro aumentar este valor a 2 MB para acelerar el proceso para los volúmenes virtuales más grandes. Consulte la documentación de VPLEX para obtener más información sobre cómo hacerlo.

7 De manera predeterminada, VPLEX sincronizará los dispositivos de almacenamiento en cada cluster. Si los dispositivos del arreglo se han aprovisionado recientemente a los clusters VPLEX, puede no ser recomendable sincronizar los dispositivos, ya que no hay datos en ellos y el tiempo que llevará puede ser importante cuando los dispositivos son grandes. Si el usuario no desea sincronizar, los componentes de almacenamiento deben crearse individualmente uno tras otro: volumen de almacenamiento, extensión, dispositivo, etc., en lugar de usar el mismo asistente para la creación del volumen virtual. Con esta metodología, el usuario tendrá la opción de sincronizar en el momento adecuado. La mejor práctica de EMC, sin embargo, es sincronizar los dispositivos.


Activación de RecoverPoint en el grupo de consistencia VPLEX

Suponiendo que RecoverPoint está configurado en VPLEX de acuerdo con la documentación del producto, cuando se complete la reconstrucción es conveniente activar RecoverPoint en el grupo de consistencia antes de implementarlo en las vistas de almacenamiento adecuadas. Seleccione el grupo de consistencia en el cual desea activar RecoverPoint. Se mostrará el cuadro de diálogo que ofrece la opción “Activar el uso de RecoverPoint” en una casilla de verificación. Seleccione la casilla que se muestra en la Figura 40 y seleccione “Aceptar”.

La figura 40. Grupo de consistencia: activación de RecoverPoint

Adición de dispositivos distribuidos a las vistas de almacenamiento

Con RecoverPoint activado, ahora se colocará el dispositivo distribuido en tres vistas de almacenamiento independientes. La primera es la vista que presentará el almacenamiento al host ESXi, conectado a cluster-1 del ambiente RAC extendido, y la segunda a otro host que está en la zona de cluster-2. La tercera vista es solo para cluster-2 y es la vista que presenta el almacenamiento para los dispositivos RecoverPoint. Para usar este dispositivo distribuido con RecoverPoint, RecoverPoint debe poder verlo.


La primera figura, Figura 41, muestra cómo agregar un dispositivo distribuido a DSIB1131_view en un proceso de cuatro pasos:

1. Seleccione Agregar o quitar los volúmenes virtuales.

2. Seleccione el volumen de la columna izquierda y luego seleccione “Agregar” para transferirlos hacia los volúmenes presentados anteriormente.

3. Seleccione “Aceptar” para terminar la adición del volumen.

4. Cierre los resultados.

La figura 41. Vistas de almacenamiento: adición de un volumen


Agregar el volumen a la segunda vista requiere un paso adicional. Cuando se intenta agregar este dispositivo distribuido a la vista DSIB1132_view en cluster-2, inicialmente no se ve en la columna izquierda. Esto se debe a que Unisphere ocultará cualquier dispositivo que ya esté en una vista. Es necesario seleccionar la casilla resaltada en la Figura 42 y permitir que los volúmenes ocultos se muestren, como se observa en la imagen.

La figura 42. Vistas de almacenamiento: vistas múltiples

Aunque esté seleccionada la casilla, Unisphere advierte al usuario, como se muestra en la Figura 43, sobre la incorporación de un dispositivo a una vista cuando este ya se encuentra en otra vista:

La figura 43. Vistas de almacenamiento: advertencia


Se advertirá nuevamente en el resumen que se muestra en la Figura 44. Este ambiente es, sin embargo, una de esas circunstancias específicas a las que hace referencia la advertencia. Tenga en cuenta que se produce el mismo conjunto de eventos nuevamente cuando el dispositivo se agrega a la vista de RecoverPoint.

La figura 44. Vistas de almacenamiento: resumen


Visualización en VMware

Aunque el almacenamiento esté mapeado y enmascarado para el host ESXi, puede descubrirse en vSphere Client. Ejecute un reexamen de los HBA, como se muestra en la Figura 45, para reconocer el nuevo dispositivo distribuido VPLEX.

La figura 45. Reexamen de vSphere de áreas de almacenamiento de datos


Ahora use EMC VSI Storage Viewer (Figura 46) para ver todos los detalles del dispositivo distribuido:

La figura 46. VSI Storage Viewer: dispositivo distribuido VPLEX

En este punto, el dispositivo está listo para usar en el cluster RAC extendido de Oracle E-Business Suite y posteriormente configurarse con RecoverPoint en el tercer sitio. El último paso es configurar el ambiente VMware SRM. Tenga en cuenta que no es necesario que los pasos sigan esta ruta exacta. Una opción sería crear el ambiente VMware VPLEX completo antes de agregar dispositivos a las vistas de RecoverPoint y activar VMware SRM. Es responsabilidad del cliente decidir qué es mejor para su ambiente.


Dispositivos locales VPLEX para registros de RecoverPoint Para los volúmenes VPLEX que se utilizarán como registros de RecoverPoint, el proceso es diferente del que se describió para los dispositivos distribuidos, dado que solo se utiliza un volumen virtual. Recuerde que RecoverPoint está conectado únicamente a uno de los clusters en VPLEX Metro. Por lo tanto, no se usarán los dispositivos distribuidos, solo los volúmenes virtuales regulares. Para crear volúmenes virtuales, se sigue el mismo procedimiento que para los dispositivos distribuidos, pero en un solo cluster. El proceso se detalla en la sección Ejemplo de aprovisionamiento de almacenamiento. Desde aquí, se creará un grupo de consistencia para presentarlo al dispositivo RecoverPoint.

Tenga en cuenta que RecoverPoint solamente puede ofrecer protección para un volumen virtual determinado en uno de los clusters. Por lo tanto, el registro debe ubicarse en el sitio donde reside el RPA que proporciona splitting. No se utiliza un dispositivo distribuido para el registro, ya otro RPA del cluster no lo puede utilizar, incluso si hubiera un splitter. Esto se debe a que si bien VPLEX Metro puede tener clusters RecoverPoint conectados y splitting en ambos clusters, RecoverPoint solo puede proteger cada volumen virtual en un cluster VPLEX a la vez. Tenga en cuenta que el registro de RecoverPoint también se puede colocar directamente en el almacenamiento físico y presentarse al RPA en lugar de hacerlo a través de VPLEX. Esto puede ser adecuado cuando el objetivo es minimizar el impacto de I/O del registro en los motores VPLEX, o si los motores actuales ya alcanzaron la utilización máxima, o están por alcanzarla, antes de la introducción de RecoverPoint. La recomendación de mejores prácticas, sin embargo, es colocar el registro en un volumen VPLEX de modo que una actualización tecnológica en el arreglo subyacente no resulte disruptiva para la replicación de RecoverPoint.

Creación de grupos de consistencia para el registro de RecoverPoint

Para estos volúmenes virtuales designados como registros de RecoverPoint, también es necesario crear un grupo de consistencia o agregarlos a un grupo existente. Dado que existen grupos de consistencia independientes para cada uno de los grupos de RecoverPoint, se creará un grupo separado de RecoverPoint para los registros que también incluirá el dispositivo de catálogo de RecoverPoint. Tener los dispositivos en el mismo grupo de consistencia sería la práctica recomendada.


Utilice el menú bajo Almacenamiento virtualizado para seleccionar Grupos de consistencia. Luego seleccione “Crear” y complete el nombre del grupo de consistencia. De manera predeterminada, se seleccionará el cluster local para designar el origen de los volúmenes virtuales. Observe la casilla de verificación que brinda visibilidad global. Esta casilla debe permanecer sin seleccionar, ya que ninguno de estos volúmenes debería estar disponible para ningún cluster excepto cluster-2. En la Figura 47, se muestra el detalle de los pasos. Seleccione “Siguiente” o “Finalizar” una vez que esté listo.

La figura 47. Creación del grupo de consistencia local

En el siguiente conjunto de capturas de pantalla en la Figura 48, siga los tres pasos:

1. Agregue el volumen virtual de la columna derecha en la columna izquierda y seleccione “Siguiente”.

2. Confirme la creación en la pantalla final.

3. Revise la pantalla de resumen y cierre.


Observe en este ejemplo que el nombre del volumen virtual es “VPLEX_DEMO_1_vol” para no confundirlo con los ejemplos anteriores.

La figura 48. Adición del volumen VPLEX local al grupo de consistencia


Adición del registro de RecoverPoint a una vista de almacenamiento

Ahora es posible agregar los dispositivos a la vista de almacenamiento. Además, a diferencia de los dispositivos distribuidos, los registros se agregarán solo a una vista única y en un solo cluster conectado al splitter de RecoverPoint. Estos son los volúmenes que utiliza RecoverPoint, y ningún host obtiene (ni se permite) acceso a ellos. Figura 49 muestra una guía para la adición del volumen a la vista. Es el mismo proceso que se explicó anteriormente en Figura 41.

La figura 49. Adición del volumen local a la vista de almacenamiento


Implementación de VMware

Implementaciones de VMware en un ambiente VPLEX Metro

EMC VPLEX traspasa las barreras físicas de los centros de datos y permite a los usuarios obtener acceso a los datos en distintas ubicaciones geográficas de manera simultánea. 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 contar con clusters distantes desde el punto de vista geográfico basados en VMware vSphere8. Esto permite el uso compartido de carga transparente entre varios sitios y brinda la flexibilidad de migrar tipos de carga entre sitios con anticipación a eventos planificados, como el mantenimiento de hardware. Más aún, en caso de eventos no planificados que causan interrupciones de servicios en uno de los centros de datos, se pueden reiniciar los servicios fallidos en el sitio no afectado de manera rápida y sencilla, con un mínimo de esfuerzo. No obstante, el diseño del ambiente VMware debe responder ante diversos escenarios de fallos 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, consulte el TechBook EMC VPLEX Metro Witness Technology and High Availability disponible en Support.EMC.com (visite el sitio web de su país correspondiente).

VPLEX Metro Witness

VPLEX utiliza conjuntos de reglas para definir cómo se debe manejar el fallo de un sitio en una configuración VPLEX Metro o VPLEX Geo. Si dos clusters pierden contacto, el conjunto de reglas define qué cluster continúa la operación y qué cluster suspende la actividad de I/O. El conjunto de reglas se aplica a un dispositivo a la vez, en este caso, a un grupo de consistencia. El uso de conjuntos de reglas para controlar qué sitio se selecciona, sin embargo, agrega complejidad innecesaria en caso de fallo del sitio, dado que puede ser necesario intervenir manualmente para reanudar la actividad de I/O en el sitio no afectado. VPLEX con GeoSynchrony 5.0 introdujo un concepto para manejar estos casos, VPLEX Witness. VPLEX Witness se implementa como un dispositivo virtual VMware (vApp) sin costo que se ejecuta en un servidor ESXi suministrado por el cliente. El servidor ESXi reside en un dominio de fallo separado físicamente de los clusters VPLEX y utiliza almacenamiento diferente que el cluster VPLEX.

Ofrece las siguientes características:

• Utilización de ambos centros de datos en modo activo/activo.

• Alta disponibilidad para aplicaciones (sin puntos de fallo de almacenamiento, reinicio automático).

• Manejo de fallos completamente automático.

8 La solución requiere la extensión de VLAN a distintos centros de datos físicos. Se pueden aprovechar tecnologías como, por ejemplo, Cisco Overlay Transport Virtualization (OTV). para proporcionar el servicio.


• Mejor utilización de recursos.

• Reducción de gastos de capital y, en consecuencia, de los gastos operacionales.

Como se puede apreciar en la Figura 50, VPLEX Witness convierte un VPLEX Metro de una solución de movilidad y colaboración activo/activo a un cluster de almacenamiento de disponibilidad continua. Se puede ver que la máquina virtual de Witness se implementa en un dominio de fallo separado (definido por el cliente) y se conecta a ambas estaciones de administración VPLEX mediante una red IP. Además, una vez que se implemente VPLEX Witness, los escenarios de fallo se vuelven autoadministrados (es decir, completamente automáticos), por lo que resulta sumamente simple dado que no hace falta hacer nada, independientemente de la condición de fallo.

La figura 50. VPLEX Witness

Nota: El dominio de falla lo decide el cliente y puede variar desde varios racks en el mismo centro de datos hasta clusters VPLEX a una distancia de 5 ms entre sí (latencia medida de 5 ms o distancia síncrona típica).

Una configuración que utiliza cualquier combinación de VPLEX Metro y VPLEX Witness permite que ambos clusters proporcionen acceso de lectura/escritura coherente al mismo volumen virtual. Esto significa que, en el sitio remoto, las rutas están activas y el almacenamiento está disponible incluso antes de que suceda cualquier failover. Cuando se combina con una tecnología de agrupación en cluster de failover de host, tal como VMware HA, se obtiene reinicio automático de las aplicaciones para cualquier desastre en el nivel de sitio. El sistema supera los fallos de componentes dentro de un sitio, incluidos los fallos de un arreglo completo.


VMware ESXi se puede implementar en ambos clusters VPLEX en un ambiente Metro para crear un ambiente de alta disponibilidad. Figura 51 muestra la configuración de Metro HA que se utiliza en este informe.

La figura 51. VMware Metro HA con VPLEX Witness

En este escenario, una máquina virtual puede escribir en el mismo dispositivo distribuido de cada cluster. En otras palabras, si el cliente utiliza VMware Distributed Resource Scheduler (DRS), que permite una distribución de carga automática en las máquinas virtuales a través de varios servidores ESXi, se puede mover una máquina virtual desde un servidor ESXi conectado a cluster-1 hasta un servidor ESXi conectado a cluster-2 sin perder acceso al almacenamiento subyacente. Esta configuración permite mover máquinas virtuales entre dos ubicaciones geográficamente separadas y con hasta 5 ms de latencia, el límite que admite VMware vMotion.


En caso de un fallo completo del sitio, VPLEX Witness señala automáticamente el cluster no afectado para reanudar la actividad de I/O de acuerdo con el conjunto de reglas. VMware HA detecta los fallos de las máquinas virtuales y reinicia las máquinas virtuales automáticamente en el sitio no afectado sin intervención externa. Es importante destacar que un evento de falta de disponibilidad de datos puede ocurrir cuando no hay una interrupción completa del sitio pero hay una interrupción de VPLEX en cluster-1 y la máquina virtual se está ejecutando en el servidor ESXi conectado a cluster-1. Si esta configuración también contiene VPLEX Witness, este reconoce la interrupción y recomienda que cluster-2 reanude las operaciones de I/O en lugar de seguir el conjunto de reglas. Sin embargo, VMware vSphere no reconoce estos tipos de fallos y no mueve automáticamente las máquinas virtuales fallidas al sitio no afectado. Para evitar esta situación, se puede aprovechar la función de interconexión del sistema de almacenamiento VPLEX. Además, los usuarios pueden intervenir y mover manualmente la máquina virtual al servidor ESX de cluster-2 para proporcionar acceso a los datos. Estas alternativas no se analizan en este informe. Sin embargo, puede encontrar información sobre este tema en los informes de la sección Referencias.

Manejo de fallos de VPLEX

Existen numerosos y excelentes documentos disponibles que abarcan los diferentes escenarios de fallo que pueden afectar el ambiente VPLEX. Por lo tanto, en este documento no se intentará abordarlos sino que se los menciona en la sección Referencias a fin de que el cliente pueda leerlos antes de la implementación.


Configuración de clusters VMware con VPLEX Metro Witness

Configuración de clusters VMware

Figura 52 muestra la configuración de clusters recomendada para implementaciones de VMware que aprovechan los dispositivos presentados por medio de EMC VPLEX Metro con VPLEX Metro Witness. Se puede observar en la figura que VMware vSphere consta de un solo cluster VMware. El cluster incluye dos hosts VMware ESXi con uno en cada centro de datos físico (denominados aquí Boston Norte y Boston Sur). Si también se desea que el sitio tenga alta disponibilidad, se pueden configurar dos o más hosts ESXi en cada sitio. 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 el cluster y que el monitoreo de máquina virtual está activado.

La figura 52. Configuración de clusters VMware con EMC VPLEX Metro usando VPLEX Metro Witness


Para aprovechar toda la funcionalidad de failover de clusters de alta disponibilidad en un cluster VPLEX Metro que utilice VPLEX Witness, es necesario crear grupos DRS y luego las reglas que regirán la manera en que se reiniciará la máquina virtual en caso de fallo. Esta configuración es un proceso bastante simple en vSphere Client. Esto permite el reinicio de la máquina virtual en caso de fallo en Boston Norte o Boston Sur.

Grupos y reglas de VMware DRS

Para obtener acceso a los asistentes para crear grupos y reglas de DRS, haga clic con el botón secundario en el cluster (Metro_Cluster) y vaya a VMware DRS. Deje el nivel de automatización en “Completamente automatizado” para permitir que VMware mueva las máquinas virtuales según sea necesario, como se muestra en la Figura 53.

La figura 53. Configuración de DRS completamente automatizado


Para los grupos de DRS, se deben crear dos grupos de DRS de máquinas virtuales y dos grupos de DRS de host. En la figura Figura 54, se han creado cuatro grupos. North_Boston_DRS_VM_Group contiene las máquinas virtuales asociadas con cluster-1 y North_Boston_DRS_Host_Group contiene los hosts asociados con cluster-1. La configuración de cluster-2 es similar.

La figura 54. Creación de grupos de DRS para hosts y máquinas virtuales


Los hosts y las máquinas virtuales se agregan, respectivamente, a cada grupo, como se ve en la Figura 55.

La figura 55. Adición de hosts y máquinas virtuales a los grupos de DRS adecuados


Una vez establecidos los grupos de DRS, es necesario crear reglas para regir cómo deben comportarse los grupos de DRS cuando se produce un fallo del sitio. Existen dos reglas, una que se aplica a cluster-1 y otra que se aplica a cluster-2. La regla North_Boston_DRS_VM_Rule, como se observa en la Figura 56, establece que la máquina virtual asociada con cluster-1 (mediante el grupo de DRS) “debería ejecutarse” en los hosts asociados con cluster-1 (nuevamente a través del grupo de DRS) y viceversa para las máquinas virtuales de cluster-2. Es importante que la condición para ambas reglas sea “debería ejecutarse” y no “debe ejecutarse”, dado que así se brinda la flexibilidad para que la máquina virtual se inicie en los dos hosts que superan un fallo del sitio. Cada regla permitirá que las máquinas virtuales asociadas con el cluster fallido se proporcionen a los dos hosts que forman parte del sitio sin fallos y, lo que es más importante, migrar automáticamente a los hosts originales cuando se resuelva el fallo en el sitio.


La figura 56. Creación de reglas para grupos de DRS

Estas configuraciones, junto con VPLEX Metro Witness, asegurarán que un fallo de sitio no derribe completamente el ambiente.


Mejores prácticas con VMware HA y VPLEX Metro

Siga estas mejores prácticas para configurar VPLEX Metro en un campus:

• Configure el front-end con una red extendida de capa 2 de modo que, cuando la máquina virtual se mueva entre sitios, mantenga la misma dirección IP.

• Si DRS está activado, utilice reglas de afinidad de host de DRS. Las reglas de afinidad de host mantienen las máquinas virtuales en funcionamiento en el sitio recomendado mientras sea posible y solo mueven las máquinas virtuales al sitio no recomendado si no se pueden ejecutar en el sitio recomendado.

• Implemente VPLEX Witness con este tipo de solución para evitar algunos eventos de falta de disponibilidad de datos en todo el sistema.

Para obtener más información sobre las mejores prácticas de HA y FT consulte el informe técnico Using VMware Fault Tolerance and High Availability with VPLEX™ Metro HA for Ultimate Availability en Support.EMC.com (visite el sitio web de su país correspondiente).

Oracle Real Application Clusters (RAC) en VPLEX Metro

RAC extendido y Oracle Clusterware con VPLEX Witness

Como se explicó anteriormente, Extended Real Application Clusters usa nodos de servidor implementados en diferentes ubicaciones físicas, pero mantiene los requisitos más estrictos de latencia y uso compartido de disco. Este tipo de implementación generalmente se encuentra en un ambiente Metro o un entorno de campus. VPLEX Metro proporciona la solución perfecta para RAC extendido y es completamente compatible con Oracle.

Uno de los beneficios de VPLEX Metro es que no usa un tercer sitio para los discos de votación de Oracle, que generalmente es un requisito de RAC extendido. Un tercer sitio evita una situación en que los nodos de Oracle no saben que hubo un problema de interconexión y ambos lados siguen recibiendo I/O. VPLEX Metro no necesita el tercer sitio porque usa VPLEX Witness en un tercer dominio de falla de sitio, como se explicó anteriormente en este documento. El comportamiento de RAC extendido con VPLEX Witness es el siguiente:

• Si falla una interconexión entre los nodos de Oracle RAC que no está relacionada con VPLEX, Oracle Clusterware se reconfigurará de acuerdo con las reglas de mayoría y el acceso al disco de votación.

• Si hay un fallo de partición de VPLEX de WAN doble o un fallo en el sitio, VPLEX iniciará las reglas de preferencia de sitio con la orientación de VPLEX Witness y continuará las operaciones de I/O en el sitio designado. Los nodos de Oracle RAC que obtienen acceso al almacenamiento en el sitio del cluster VPLEX que no se vio afectado seguirán obteniendo acceso a los discos de votación y, por lo tanto, Oracle Clusterware reconfigurará el cluster de acuerdo con esta situación.


Para obtener más detalles sobre el uso de Oracle Extended RAC con VPLEX, consulte el informe técnico Oracle Real Application Clusters (RAC) on Extended Distance Clusters with EMC VPLEX™ Metro en Support.EMC.com (visite el sitio web de su país correspondiente).

Oracle en VMware

La implementación de Oracle en hardware virtual debe ser esencialmente igual al hardware físico. Es decir, se pueden obtener todos los beneficios de escala del hipervisor sin preocupaciones de que Oracle se ejecuta de manera diferente que cuando se ejecuta en un host físico. Al igual que sus contrapartes de host físico, las implementaciones virtuales deben seguir las mejores prácticas para las bases de datos Oracle. Otras recomendaciones imitan las implementaciones físicas y se encuentran en el sitio web de VMware. En la sección Referencias se incluyen algunos de estos documentos.

Oracle Real Application Clusters (RAC) y Oracle E-Business Suite

La implementación de Oracle E-Business Suite (VIS de base de datos de demostración predeterminada) que se utiliza en este documento se instala como una sola instancia en un nodo. Si el usuario desea usar RAC, debe convertir la base de datos de una instancia a varias instancias. Para las bases de datos independientes, esta no es una tarea simple, pero para los ambientes E-Business Suite es aún más complicado. Oracle ofrece varias notas de soporte para guiar al usuario en la implementación. Existen dos componentes involucrados: las aplicaciones y la base de datos. Dado que Oracle Applications está vinculado integralmente a la base de datos, requiere una actualización, al igual que la base de datos. Existen varios parches y cambios de configuración que deben aplicarse antes de que se pueda mover la base de datos a RAC. Las notas de Oracle son amplias, detalladas y específicas para cada versión de las aplicaciones y la base de datos. También se actualizan frecuentemente con nueva información. Por lo tanto, es imposible explicar correctamente el proceso que se utiliza en este ambiente más allá de la descripción general ya mencionada. Las notas de soporte que se utilizan en esta actualización se incluyen en Referencias como referencia.

El enfoque aquí estará en una ruta de actualización posible para RAC en un ambiente Oracle E-Business Suite. Oracle proporciona la conversión a RAC a través de varias rutas diferentes. La que se utiliza en este informe era una instalación separada de los archivos binarios 11.2.0.3 (grid y base de datos), una conversión a ASM y una actualización de la base de datos de las aplicaciones a la nueva versión de la base de datos y RAC extendido. En este informe se abordará el componente relevante, que es la instalación de RAC en VMware con VPLEX. Esta instalación proporcionará la base para la configuración de RecoverPoint y la configuración de VMware SRM.


Oracle Real Application Clusters (RAC) en VMFS

RAC se puede configurar en VMware con mapeo de dispositivos crudos (RDM) o vmdk. Para esta solución, se seleccionaron vmdk para reducir la complejidad.

Sin bien VMware SRM y RecoverPoint SRA son compatibles con la replicación de mapeo de dispositivos crudos (RDM), se eligió VMFS por su mayor simplicidad. Usar RAC en VMware requiere seguir ciertos pasos para permitir que las máquinas virtuales que se ejecutan como nodos de RAC obtengan acceso a los mismos vmdk. Oracle cuenta con una tecnología en cluster, Oracle Clusterware9, que posee la inteligencia para asegurarse de que dos o más nodos de RAC puedan obtener acceso al mismo disco sin causar problemas de datos. Si bien VMware permitirá que varias máquinas virtuales obtengan acceso simultáneamente al mismo vmdk cuando se usa para tecnologías como VMware Fault Tolerance (FT) donde solo se escribe una máquina virtual, de manera predeterminada, no permite que varias máquinas virtuales escriban en el mismo vmdk. Si dicha restricción no se aplica, VMware no puede garantizar ningún tipo de escritura proveniente de las máquinas virtuales que podría conducir muy fácilmente a daños o pérdidas de datos.

VMware proporciona los medios para anular esta protección a través del indicador de múltiples escrituras que se configura individualmente para cada vmdk. El proceso se encuentra en el artículo 1034165 de la Knowledgebase de VMware. Para este tipo de cambio, VMware hace referencia a software de agrupación en cluster de terceros como RAC. Uno de los requisitos previos para configurar el indicador es que los vmdk de Oracle designados para la base de datos deben crearse con el tipo eagerzeroedthick. Esto se realiza conforme a las mejores prácticas de VMware para las bases de datos Oracle en VMware.

Implementación de Oracle Clusterware

Oracle Clusterware y Automatic Storage Management (ASM) se implementan en volúmenes distribuidos de VPLEX y, como se analizó anteriormente, sin la necesidad de un tercer sitio para los discos de votación. EMC recomienda la implementación de los archivos de Clusterware, OCR y votación en su propio grupo de discos ASM utilizando redundancia “normal”, mientras se usa la redundancia “externa” para los otros grupos de discos.

Instalación de Oracle RAC extendido

A continuación se indican los pasos básicos para configurar Oracle RAC en VMware para este ambiente. Estas acciones se realizaron en cada uno de los dos nodos del ambiente RAC. Dado que esto se realiza en un ambiente VPLEX Metro, de manera predeterminada es una configuración de RAC extendido. En los pasos siguientes, se supone que los dispositivos distribuidos de VPLEX se han presentado a los dos hosts ESXi en el cluster de alta disponibilidad.

9 En 11g R2, Oracle Clusterware y Automatic Storage Management (ASM) forman la infraestructura Oracle.


Tenga en cuenta que, en el ambiente que se utiliza en este informe se utilizaron dos nodos de RAC que se instalaron de forma independiente y con alojamientos de software independientes. Existen varias opciones disponibles para instalar los nodos de RAC, particularmente en VMware. Los usuarios pueden elegir instalar algunos componentes en un solo nodo (p. ej., SO, discos, etc.) y luego crear una plantilla. Esta plantilla permite crear varios nodos de RAC. En ese momento, el usuario puede elegir usar un alojamiento compartido para los archivos binarios de Oracle. Estas opciones son estrictamente preferencias del usuario que hace la instalación y no afectan la funcionalidad del cluster, aunque pueden facilitar la aplicación de parches. Cree VMFS en cada uno de los dispositivos distribuidos presentados desde VPLEX. Habrá algunos para el SO y los archivos binarios, y otros para el ASM configurado para la base de datos de Oracle RAC.

Procedimiento

1. Configure un cliente NTP para usarlo en el ambiente.

2. Cree una máquina virtual con el sistema operativo invitado configurado en Oracle Linux 4/5/6 (64 bits). Cree un vmdk para alojar los archivos binarios del sistema operativo y otro vmdk para alojar los archivos binarios de Oracle Applications.

3. Agregue una segunda NIC. Asegúrese de que ambas NIC estén configuradas en VMXNET3. Estas NIC deben ubicarse en las redes de VMware configuradas en su propio adaptador físico.

4. Instale Oracle Enterprise Linux, las herramientas de VMware y los componentes de ASMLIB. Configure ASMLIB.

5. Configure NTP en el nodo.

6. Cree los vmdk para la base de datos de Oracle y CRS/discos de votación. Las configuraciones pueden variar. Para este ambiente, se crearon varios discos (TDEV) para los archivos de cluster, datos, de reconstitución y archivado. Todos los vmdk deben ser eagerzeroedthick (EZT), si no, habrá problemas como, por ejemplo, la incapacidad para reiniciar la máquina virtual. Asegúrese de que los pools delgados VMAX que alojan los discos detrás de los dispositivos distribuidos de VPLEX no estén sobreasignados; de lo contrario, la creación de disco puede fallar. Los discos se deben asignar a un adaptador Paravirtual SCSI.

7. Utilice el artículo 1034165 de la base de conocimiento de VMware para configurar el indicador de múltiples escrituras10 en los vmdk, lo que permite que más de un nodo obtenga acceso a la unidad.

8. Con fdisk configure una sola partición en todos los discos. Es importante alinear la partición en el disco, ya que ni Oracle ni VMware lo harán automáticamente. VMware garantiza que VMFS esté alineado, pero no controla los sistemas de archivos en los vmdk. VPLEX requiere una compensación de 4 KB, a menos que Symmetrix VMAX respalde el VPLEX. En este caso, deben utilizarse 64 KB, como en este ambiente.

10 El uso del indicador de múltiples escrituras hace que Storage vMotion sea inoperable para el nodo.


9. Utilice oracleasm para crear los discos ASM en uno de los hosts. Luego utilice oracleasm para reexaminar el segundo host y descubrir los discos ASM.

10. Instale y configure la infraestructura Oracle Grid 11.2.0.3. La instalación de Clusterware utilizará un solo grupo de discos ASM durante la instalación. Configure este grupo de discos con redundancia “normal”, que garantizará que haya varios discos de votación ya que Oracle determina automáticamente la cantidad de archivos en función de la redundancia. Este grupo de discos ASM no necesita ser muy grande, ya que los archivos de Clusterware son pequeños.

11. Cree los grupos de discos de ASM restantes mediante la GUI o la interfaz de la línea de comandos de ASM y asegúrese de establecer la redundancia en “externa”. Oracle y EMC recomiendan usar esta redundancia porque la disponibilidad es superior no solo en VPLEX, sino también en EMC Symmetrix VMAX, que respalda el VPLEX en este ambiente. El grupo de discos de Clusterware es el único que requiere una redundancia “normal” por las razones indicadas anteriormente.

12. Instale los archivos binarios de la base de datos de Oracle en ambos nodos al mismo tiempo con el instalador.

13. Convierta la base de datos de demostración de Oracle E-Business Suite a ASM y RAC.


Redes

La configuración de red que se utiliza en este ambiente estuvo limitada a dos tarjetas NIC físicas en los hosts ESXi. Una mejor práctica sería separar la red de administración, la red de vMotion y las redes públicas y privadas de Oracle. Figura 57 muestra la configuración con solo dos NIC:

La figura 57. Redes de vSphere para Oracle RAC


Una vez que la base de datos de Oracle Applications se convierta a RAC, el administrador de bases de datos debe poder ejecutar una comprobación de estado correcta que debería generar resultados similares a los mostrados en la Figura 58. Muestra el estado de un nodo de RAC extendido después de la instalación y la conversión.

La figura 58. Estado de Oracle RAC en el nodo de producción


Para ver detalles de uno de los dispositivos distribuidos de VPLEX, VSI proporciona una vista completa en la Figura 59.

La figura 59. VSI que muestra la anatomía de dispositivos distribuidos de VPLEX


EMC RecoverPoint La familia de productos EMC RecoverPoint brinda una solución integral de protección de datos para clientes empresariales y comerciales. Así, ofrece protección de datos continua e integrada, y replicación remota continua para recuperar aplicaciones en cualquier punto en el tiempo.

Los sistemas RecoverPoint permiten la replicación de datos confiable a cualquier distancia; dentro del mismo sitio (CDP), a otro sitio remoto (CRR) o de ambos simultáneamente (CLR). Específicamente, los sistemas RecoverPoint admiten la replicación de datos que escriben las aplicaciones mediante Fibre Channel al almacenamiento conectado a SAN local. Los sistemas utilizan la infraestructura de Fibre Channel existente para integrarse sin problemas con aplicaciones de host y subsistemas de almacenamiento de datos existentes. En el caso de la replicación remota, los sistemas usan las conexiones de IP existentes para enviar los datos replicados mediante WAN o usan la infraestructura de Fibre Channel para replicar datos de manera asíncrona o síncrona. Los sistemas proporcionan failover de las operaciones en un sitio secundario en caso de que se produzca un desastre en el sitio primario.

Estas son algunas de las definiciones de los componentes de RecoverPoint.

RPA: dispositivo RecoverPoint. El hardware que administra todos los aspectos de la protección de datos. Un RPA puede administrar múltiples grupos de almacenamiento, cada uno con diferentes políticas.

Un mínimo de dos y un máximo de ocho RPA se instalan en cada sitio, en la misma instalación que el host y el almacenamiento. El conjunto de RPA instalados en cada sitio se denomina “cluster de RPA”. Si un RPA del cluster falla, las funciones que proporciona el RPA fallido se mueven automáticamente a uno o más de los RPA restantes.

Los RPA del sitio de producción transfieren el I/O de splitting al sitio de réplicas.

Los RPA en el sitio de réplica distribuyen los datos al almacenamiento de réplica.

En caso de failover, estas funciones pueden invertirse. El mismo RPA puede funcionar como RPA de producción para un grupo de consistencia y como RPA de réplica para otro.

Volúmenes: todos los volúmenes de RecoverPoint pueden alojarse en VPLEX. En la práctica, algunos volúmenes pueden alojarse en VPLEX y otros en el almacenamiento sin VPLEX. Por ejemplo, el volumen de catálogo para un cluster de RPA existente no se puede mover. Si está instalando VPLEX en una configuración existente de RecoverPoint, el volumen de catálogo ya está configurado en el almacenamiento sin VPLEX.


Los siguientes tipos de volúmenes se requieren en todas las configuraciones de RecoverPoint:

• Volumen de catálogo: volumen dedicado a RecoverPoint para cada cluster de RPA. El volumen de catálogo presta servicios a todos los RPA del cluster de RPA particular y al splitter asociado con ese cluster. El volumen de catálogo almacena información de configuración sobre los RPA y los grupos de consistencia de RecoverPoint.

Existe un volumen de catálogo para cada cluster de RPA.

• Volúmenes de producción: los volúmenes que escriben las aplicaciones de host. Las escrituras en los volúmenes de producción se dividen para enviarlas a los volúmenes designados normalmente y a los RPA simultáneamente. Cada volumen de producción debe tener exactamente el mismo tamaño que el volumen de réplica en que se replica.

• Volúmenes de réplica: volúmenes en los cuales se replican los volúmenes de producción. El volumen de réplica debe tener exactamente el mismo tamaño que el volumen de producción.

• Volúmenes de registro: volúmenes que contienen los datos a la espera de su distribución a volúmenes de réplica de destino y copias de datos distribuidos anteriormente a los volúmenes de destino. Los volúmenes de registro permiten realizar una reversión conveniente a cualquier punto en el tiempo, y así lograr una recuperación instantánea para ambientes de aplicación.

Snapshot/PiT: una copia en un punto en el tiempo que conserva el estado de los datos en un instante en el tiempo y almacena solo los bloques que son diferentes de una copia completa existente de los datos.

Los snapshots también se denominan PiT (punto en el tiempo). Los snapshots almacenados en un registro de réplica representan los datos que cambiaron en el almacenamiento de producción desde el cierre del snapshot anterior.

Acceso registrado (físico): se usa para recuperación, failover, pruebas y clonación de producción de una réplica. En este informe técnico también se denomina acceso a imagen.

Acceso directo: este modo de acceso solo puede activarse después de activar el acceso registrado, o acceso virtual con aplicación. Se utiliza para el procesamiento generalizado con una tasa elevada de escritura, cuando se necesita acceso a imagen durante un periodo prolongado (y no se cuenta con el espacio de registro para admitir todos los datos escritos en el log de acceso a imagen en el momento) y cuando no se requiere guardar el historial del registro de la réplica (el registro de la réplica se pierde después del acceso directo).

RecoverPoint 4.0

RecoverPoint lanzó su versión 4.0 del software en el segundo trimestre de 2013. Esta versión cuenta con muchas mejoras, entre las que se incluyen:

• Preparación para RecoverPoint/VE

• Múltiples sitios


• vRPA con splitter VNX

• Escalabilidad y rendimiento

• Nueva GUI de EFX: Unisphere for RecoverPoint

• Capacidad de actualización por el cliente

• Concesión de licencias electrónicas

RecoverPoint CDP y SRDF

Con el lanzamiento de RecoverPoint 4.0, Enginuity Q2 2013 SR y Solutions Enabler V7.6, RecoverPoint CDP y SRDF ahora pueden coexistir en los mismos dispositivos de origen. Esto proporciona la capacidad de tener una copia local de los datos con protección contra daños lógicos mientras se replica a un sitio remoto para recuperación de desastres.

Configuración de VPLEX Metro RecoverPoint

VPLEX Metro y RecoverPoint CRR/CLR

En configuraciones de VPLEX Metro/RecoverPoint CRR/CLR, la actividad de I/O es la siguiente:

• Escritura en ambos clusters VPLEX (comportamiento normal).

• División en un cluster VPLEX a los volúmenes de réplica que se encuentran en el cluster y en un sitio remoto.

Los RPA se implementan en un cluster VPLEX y en un tercer sitio.


El tercer sitio puede ser un cluster VPLEX independiente. Figura 60 es un diagrama de este modelo de implementación, el mismo que se usa en el ambiente detallado en este informe técnico.

La figura 60. Diagrama de alto nivel del ambiente de VPLEX y tercer sitio con RecoverPoint

• Aunque el splitter de RecoverPoint resida en todos los clusters VPLEX, solo un cluster de VPLEX Metro puede tener RPA implementados. Esta configuración admite una cantidad ilimitada de puntos en el tiempo (con granularidad hasta una sola escritura) para los volúmenes virtuales locales y distribuidos de VPLEX.

• Los dispositivos RecoverPoint pueden implementarse solo en un cluster VPLEX en una configuración Metro.

• Todos los volúmenes protegidos por RecoverPoint deben estar en el cluster recomendado, según lo establezcan las reglas de separación del grupo de consistencia de VPLEX.

• Los clientes pueden recuperarse de desastres operacionales y volver rápidamente a cualquier PiT del cluster VPLEX donde se implementaron los RPA o en el tercer sitio.

• La reversión basada en conocimiento de eventos de aplicaciones es compatible con los volúmenes virtuales locales o distribuidos de VPLEX Metro para Microsoft SQL, Microsoft Exchange y aplicaciones de base de datos de Oracle.


• Si el cluster VPLEX falla, los clientes pueden recuperar a cualquier punto en el tiempo en el (tercer) sitio remoto. La recuperación en el sitio remoto a cualquier punto en el tiempo se puede lograr con VMware vCenter Site Recovery Manager, tal como se detalla en este informe técnico.

• Esta configuración puede simular un desastre en el cluster VPLEX para probar las funciones de recuperación de desastres de RecoverPoint en el sitio remoto.

Unisphere for RecoverPoint Unisphere for RecoverPoint es la nueva interfaz GUI de la versión 4.0 para administrar el ambiente RecoverPoint. Proporciona asistentes fáciles de usar para completar todas las tareas relacionadas con la configuración y administración de un ambiente de RecoverPoint. Figura 61 Presenta el tablero de Unisphere que incluye tres pestañas:

• Estado general

• Monitoreo del sistema

• Eventos del sistema

En la pestaña Estado general hay cuatro subpaneles que contienen lo siguiente:

• Mapa de cluster RPA

• Tráfico del sistema

• Alertas


• Estado de transferencia del grupo de consistencia

La figura 61. Tablero de Unisphere for RecoverPoint


Además de las estadísticas del tablero, se pueden obtener más detalles sobre el rendimiento en la pestaña Estadísticas para cada grupo de consistencia. En la Figura 62, se puede ver un ejemplo.

La figura 62. Vista de estadísticas de Unisphere for RecoverPoint

Configuración de RecoverPoint para ambientes Oracle Una vez que el hardware y el software de RecoverPoint se hayan instalado correctamente, se debe contar con las licencias para usarlos con CDP, CRR o ambos en el sitio local y remoto. Aparecerá el asistente de introducción en Unisphere for RecoverPoint, que guiará al usuario a lo largo del proceso de instalación de las licencias para poder usar el producto. Debido a las numerosas aplicaciones de este ambiente de RecoverPoint, las licencias de CRR y CDP se requieren en el sitio local y remoto.


Licencias de RecoverPoint

El asistente muestra el proceso paso por paso para agregar las licencias. Se pueden utilizar licencias de CRR y CDP en el mismo sitio usando dos archivos de licencia en cada sitio. La pantalla de introducción se observa en la Figura 63.

La figura 63. Asistente para licencias de RecoverPoint

Seleccione “Agregar” y proporcione el archivo adecuado que contiene la información de licencia, como se muestra en la Figura 64.

La figura 64. Adición de una licencia a RecoverPoint


Seleccione “Aceptar” y “Siguiente: Activar soporte” y verá la Figura 65. Complete la información adecuada para el ambiente y seleccione “Finalizar”.

La figura 65. Activación del soporte en el asistente de licencias de RecoverPoint


Siga estos mismos pasos para agregar los archivos de licencia restantes. Una vez finalizado el proceso, se debe ver una imagen similar a la de la Figura 66.

La figura 66. Licencias de RecoverPoint CRR y CDP para sitios locales y remotos

Credenciales de VPLEX en el splitter

Una vez terminada la configuración y la aplicación de las licencias, es posible que aparezca una advertencia del splitter VPLEX, como se muestra en la Figura 67.

La figura 67. Advertencia de RecoverPoint que solicita las credenciales de VPLEX


RecoverPoint requiere que se introduzcan las credenciales de VPLEX. Estas deben corresponder al servidor de administración del cluster VPLEX con el cual está asociado el dispositivo RecoverPoint, en este caso, cluster-2. Se muestra un ejemplo en la Figura 68.

La figura 68. Introducción de credenciales para VPLEX Metro

Configuración de RecoverPoint

Registros de RecoverPoint

Los registros de RecoverPoint son volúmenes muy activos en las configuraciones de RecoverPoint. En general, los registros en el arreglo de destino tienen una cantidad de I/O 3 a 5 veces mayor que el origen. Esto se debe simplemente a la naturaleza de funcionamiento de RecoverPoint. Un dispositivo delgado muy activo debe contar con el respaldo de una tecnología de disco de alto rendimiento. En esta configuración, se eligió FC RAID-1 para los registros. Esto asegurará el rendimiento adecuado. El uso de FAST VP, sin embargo, proporcionará las ventajas de mover los datos inactivos a SATA RAID-6 o los datos muy activos a EFD RAID-5. Para la configuración de dispositivos, EMC recomienda el uso de metavolúmenes fraccionados, con 4 u 8 segmentos. El tamaño de los volúmenes debe ser igual, y es mejor utilizar la misma cantidad de volúmenes que los puertos FA disponibles para RecoverPoint. Para esta configuración, por lo tanto, se usaron 4 metavolúmenes fraccionados de 4 segmentos para cada grupo de consistencia de RecoverPoint. RecoverPoint fraccionará los volúmenes de registro y distribuirá el tipo de carga entre los FA.


Réplicas de RecoverPoint

Las réplicas en el tercer sitio reciben el doble de I/O que los volúmenes de producción debido a la actividad de RecoverPoint. Es aceptable configurar las réplicas en discos de rendimiento más lento que los de producción, aunque en el failover esas réplicas se convierten en volúmenes de producción. Si FAST VP está en uso, tal como se recomienda, es posible que los volúmenes ya estén en el nivel correcto.

Creación de grupos de consistencia

Aquí se seguirá el proceso de creación de un grupo de consistencia en el ambiente RecoverPoint. Desde el tablero de Unisphere for RecoverPoint, seleccione el menú “Protección” y luego “Proteger volúmenes”, como se muestra en la Figura 69, para comenzar el asistente.

La figura 69. Creación de grupos de consistencia en Unisphere for RecoverPoint


La primera pantalla define el nombre del grupo de consistencia junto con los volúmenes que se replicarán. Utilice las casillas de verificación para seleccionar los volúmenes. Si los volúmenes reciben un nombre según la función, este proceso es relativamente sencillo. Escriba un nombre de grupo y un nombre de producción. En este ejemplo, el nombre de producción aparece señalado con “Local_” para distinguirlo del sitio remoto que se definirá en una pantalla posterior. El valor predeterminado del cluster de RPA es el local si se obtiene acceso a Unisphere desde el sitio local. Se muestran los detalles en la Figura 70.

La figura 70. Selección de volúmenes de producción para el sitio local


Luego, los volúmenes de producción deben asignarse como se muestra en la Figura 71. Nuevamente, esta es una selección de volúmenes mediante las casillas de verificación. Los volúmenes son fáciles de identificar, ya que la convención de asignación de nombres indica qué volúmenes funcionan como qué componente de la base de datos. Cada grupo de consistencia tiene cuatro volúmenes de registro que se configuran con un 20 % del total de espacio que se está replicando, según las mejores prácticas para los volúmenes de registro. Como el almacenamiento que respalda el ambiente es VMAX, los volúmenes de registro son los metavolúmenes fraccionados que proporcionarán el mejor rendimiento, también indicado anteriormente como mejor práctica.

La figura 71. Definición de los registros de producción para el sitio local


Ahora es necesario definir el sitio remoto. Se suministra un nombre de la copia. En la Figura 72, se muestra que se usa el prefijo “Remote_”. El cluster de RPA predeterminado deberá estar en el sitio remoto. Los volúmenes de producción deben asociarse con un volumen de tamaño similar en el sitio remoto.11 La pantalla de subselección de asociación para cada dispositivo se muestra en la Figura 73. Estos volúmenes remotos son los que se configuraron en el arreglo VMAX del tercer sitio. El modo de replicación es asíncrono, ya que se realizará una transferencia de Boston a San Francisco para ver un escenario real de recuperación de desastres.

La figura 72. Mapeo de volúmenes de producción a volúmenes de tercer sitio remoto

11 Existe la posibilidad de usar un volumen remoto de mayor tamaño.


La figura 73. Pantalla de subselección para mapeo de dispositivos

Después de la asociación, el sitio remoto también necesita volúmenes de registro. Esta selección se observa en la Figura 74, y a los volúmenes se aplican las mismas mejores prácticas que a los registros locales.

La figura 74. Definición del registro de copia para el sitio remoto


En la pantalla final que se muestra en la Figura 75, existe la capacidad de modificar el grupo si algo se configuró incorrectamente. Antes de esta pantalla, la capacidad de reversión siempre estaba disponible.

La figura 75. Resumen de creación del grupo de consistencia


Configuración de administración externa para un grupo de consistencia

Figura 76 muestra cómo configurar el grupo de consistencia en RecoverPoint para administrarlo con una aplicación externa, en este caso, VMware vCenter Site Recovery Manager o SRM. Es fundamental realizar esta configuración antes de utilizar RecoverPoint SRA en VMware SRM. No hacer este cambio impide ver los dispositivos asociados entre VPLEX y RecoverPoint.

La figura 76. Configuración de VMware SRM como administración externa para grupos de consistencia


Creación de conjuntos de grupos

También se aprovechará esta oportunidad para crear un conjunto de grupos, como se muestra en la Figura 77, que marcará todos los grupos de consistencia al mismo tiempo con una sola etiqueta. Para hacerlo, use la GUI de VPLEX -> Protección -> Administrar conjuntos de grupos.

La figura 77. Creación de un conjunto de grupos para marcadores


Este no es el único tipo de conjunto de grupos que puede usarse en un ambiente RecoverPoint. Se utiliza en este caso porque la implementación es para VMware SRM. Sin embargo, la configuración sigue siendo tal que la base de datos de Oracle se ha separado en grupos de consistencia que permitirán que los datos de las bases de datos de Oracle tengan acceso a imagen en un punto en el tiempo diferente que los logs de archivo, lo cual permite un escenario de respaldo en activo. En los ambientes de los clientes, puede necesitarse este tipo de granularidad para que, si el ambiente no solo se utilizó en VMware SRM sino también para otros propósitos, tales como respaldo o pruebas y desarrollo, los diferentes grupos de consistencia puedan tener cada uno un marcador diferente. En un ambiente de doble función VPLEX/RecoverPoint/SRM, recuerde que la administración externa mediante SRM debe desactivarse antes de intentar el acceso a imagen manual. En caso contrario, se generará un error, tal como se muestra en la Figura 78.

La figura 78. Imposibilidad de usar la GUI para la manipulación de imágenes si SRM posee la administración


Instalación de VMware SRM La versión 5.1 de VMware SRM se utilizó en la configuración. La instalación de SRM no se trata en este informe. Consulte la documentación de VMware correspondiente para obtener instrucciones de instalación. De aquí en adelante, se supone que VMware SRM está instalado y configurado correctamente.

RecoverPoint SRA

Se necesita RecoverPoint SRA para usar VMware SRM con RecoverPoint. VMware SRM interactúa con SRA para ejecutar las actividades necesarias de RecoverPoint que permiten el acceso a imágenes. La instalación de SRA implica algunos requisitos previos. El primero es que SRM debe estar instalado y el segundo es que Java Runtime Environment (JRE) versión 6, actualización 7, debe estar instalado en el host de VMware SRM. Sin embargo, si RecoverPoint SRA no encuentra JRE, instalará una versión predeterminada. Lamentablemente, la versión de JRE que instala RecoverPoint solo permitirá finalizar correctamente la instalación de SRA, pero el adaptador no funcionará correctamente. Si SRA no funciona correctamente, examine los archivos de log en busca de información sobre los fallos, uno de los cuales puede ser un problema de JRE.

Aquí se mostrarán los pasos de instalación del adaptador de RecoverPoint SRA. La instalación casi no requiere intervención del usuario y es muy simple. En la pantalla final, Figura 79, el instalador advierte que puede ser necesario reiniciar el servicio de VMware SRM. Si el adaptador de SRA no se reconoce en VMware SRM, puede significar que es necesario un reinicio. Tenga en cuenta que hacerlo interrumpirá cualquier proceso en curso de SRM.

La figura 79. Finalización de la instalación de RecoverPoint SRA


Protección y grupos de usuarios de VMware SRM Una vez que todas las piezas se encuentren en su lugar, se pueden crear los grupos de protección y los planes de recuperación de VMware SRM para realizar pruebas de failover. Primero se agrega el administrador de arreglos al sitio protegido y al sitio de recuperación. Esto se realiza mediante las pantallas de configuración de VMware SRM y la pantalla de selección de VMware SRM que se muestra en la Figura 80.

Adición de un administrador de arreglos de RecoverPoint

La figura 80. Pantalla de selección de SRM


En la Figura 81, después de seleccionar el sitio correspondiente en la pantalla de selección, el usuario selecciona “Agregar administrador de arreglos” y proporciona los detalles del ambiente RecoverPoint. Los pasos se describen a continuación; aquí se usó la dirección IP del servidor de administración en el sitio local, 10.108.246.150.

La figura 81. Adición de un administrador de arreglos a VMware SRM


Después de agregar los administradores de arreglos en cada sitio, active los pares. Si bien cada sitio requiere un administrador de arreglos configurado, la activación de los pares solo debe completarse en un sitio. Active el administrador seleccionando la palabra azul “Activar” en la columna Acciones, que se muestra en la Figura 82.

La figura 82. Activación del administrador de arreglos en VMware SRM

La correcta activación hace que se muestren los pares en cada sitio, como se muestra en la Figura 83.

La figura 83. Pares de dispositivos activados en SRM


Si el grupo de consistencia de RecoverPoint no está configurado con administración externa mediante SRM, los pares de ese grupo no aparecerán en esta pantalla. Vuelva a RecoverPoint, active la administración externa mediante SRM, como se muestra en la Figura 76, y ejecute la actualización desde esta pantalla.

Creación del grupo de protección de VMware SRM

Para crear un grupo de protección, utilice el menú de la Figura 80, seleccione Grupos de protección y, a continuación, seleccione Crear grupo de protección, como se muestra en la Figura 84.

La figura 84. Creación de un grupo de protección de VMware SRM

A continuación, siga el asistente como se detalla en la Figura 93 y proporcione la información solicitada. Tenga en cuenta que, en el paso 2, se selecciona un solo grupo de área de almacenamiento de datos. Para esta configuración, el objetivo es crear una copia consistente para fallas del ambiente Oracle. Aunque es posible implementar un modo de respaldo activo de la base de datos de Oracle, requeriría otro procedimiento y pasos adicionales, como la copia manual de los archivos de log al sitio remoto. Sin embargo, se puede seguir usando una base de datos de Oracle consistente para fallas para respaldo y recuperación.


La figura 85. Creación de un grupo de protección en SRM

Las máquinas virtuales configuradas se incluyen aquí en la Figura 86:

La figura 86. Máquinas virtuales configuradas en un grupo de protección


Cuando termine el grupo de protección, cree el grupo de recuperación. Tenga en cuenta que los grupos de protección y los planes de recuperación se pueden crear tras iniciar sesión en el sitio local o remoto de VMware SRM. Los cinco pasos se muestran en la Figura 87.

La figura 87. Creación de un grupo de recuperación en VMware SRM


Se establece el plan de recuperación para iniciar automáticamente las máquinas virtuales en el ambiente Oracle. Hay ciertos aspectos del plan de recuperación que es importante destacar:

• Las cuatro máquinas virtuales se inician en el mismo host ESXi. Esta era la limitación de este ambiente. El host en cuestión tiene suficientes recursos para ejecutar las cuatro máquinas pero, en un ambiente de cliente, se espera que exista un cluster de alta disponibilidad en el tercer sitio. En este caso, el tercer sitio debe configurarse de manera similar al sitio de producción en términos de VMware DRS. Consulte Configuración de clusters VMware con VPLEX Metro Witness para obtener detalles.

• Las máquinas virtuales del plan de recuperación se configuran para iniciarse automáticamente. Si la base de datos de Oracle RAC se usará para respaldo o para roll forward, el plan se debe cambiar para que no se inicien las máquinas virtuales. Para obtener detalles sobre cómo usar una base de datos de Oracle consistente para fallas para respaldo o recuperación consulte el informe técnico Using EMC SRDF/TimeFinder and Oracle Database 10g/11g. Aunque este informe cubre las tecnologías de EMC SRDF y TimeFinder, el foco está puesto en las bases de datos consistentes para fallas que EMC RecoverPoint genera en este ambiente.

• En un ambiente de Oracle Applications, la base de datos debe ser accesible para que los servicios de aplicaciones puedan iniciarse. El plan de recuperación se puede personalizar para permitir diferentes prioridades al iniciar las máquinas virtuales y los scripts que se ejecutarán. Existen varias formas de configurar el ambiente para automatizar las aplicaciones de Oracle Applications que se ejecutan en una prueba o un escenario de recuperación de desastres.

Failover de prueba de VMware SRM Las siguientes secciones detallan cómo ejecutar el plan de recuperación de VMware SRM creado previamente. Utiliza la versión 5.5 de la función RecoverPoint Management.

VSI: RecoverPoint Management La función RecoverPoint Management 5.5 es una mejora a VSI que permite al usuario seleccionar las copias de punto en el tiempo (PiT) para usarlas en ambientes de pruebas de failover o recuperación de desastres de VMware SRM cuando se utiliza en conjunto con RecoverPoint 4.0 P1. El acceso a la función RecoverPoint Management (RM) 5.5 se obtiene desde VSI, donde también se ejecuta. No tiene como objetivo sustituir la consola de la GUI de RecoverPoint de ninguna manera, ya que se utiliza únicamente junto con Site Recovery Manager. De hecho, el uso de la función solo es posible si RecoverPoint está configurado previamente para permitir que VMware SRM administre el ambiente con el fin tener acceso a imágenes.


Para usar VSI RM con el ambiente VMware SRM, es necesario proporcionar credenciales para los servidores de VMware SRM y el servidor de RecoverPoint. Este paso se muestra en la Figura 88.

La figura 88. Adición de credenciales para SRM y RecoverPoint en VSI


Con las entradas que se muestran en la Figura 89, VSI podrá descubrir información sobre el ambiente RecoverPoint, como grupos de consistencia y marcadores, que permiten la configuración de un punto en el tiempo (PiT) para un grupo de consistencia.

La figura 89. Servidores RecoverPoint y SRM registrados en VSI

La integración de RecoverPoint y VMware SRM no requiere el funcionamiento de VSI RM. VSI RM proporciona la capacidad de configurar un punto en el tiempo, en lugar de usar el último marcador correcto al probar el failover desde el ambiente de producción. Si VSI RM no está presente en el ambiente, VMware SRM, a través de RecoverPoint SRA, utilizará una imagen en tiempo real y consistente para fallas en todos los grupos de consistencia de RecoverPoint en el grupo de protección.

Prueba de failover de RecoverPoint con VSI En la siguiente sección, se detallará el proceso de una prueba de failover de SRM mediante la función VSI RM y la selección de un PiT.

En las secciones anteriores, se proporcionaron ejemplos para crear grupos de consistencia en VPLEX y luego crear grupos de consistencia en RecoverPoint. Estos grupos se espejean, según lo indican las mejores prácticas. En todos los casos, se requiere un grupo de consistencia de VPLEX para cualquier dispositivo que sea replicado con RecoverPoint.

Asignación de un punto en el tiempo en VSI para los grupos de consistencia de RecoverPoint

Cuando se ejecuta un plan de recuperación para VMware SRM con RecoverPoint, en forma predeterminada, se usará la última imagen consistente entre los grupos de consistencia del grupo de protección. Para muchos clientes, esta situación puede ser aceptable, pero otros desearán la funcionalidad que brinda la función RecoverPoint Management de VSI, que es la selección de un PiT. Con VSI RM, es posible aplicar una imagen de PiT, como la que se crea cada diez minutos por el conjunto de grupos configurado anteriormente, tal como se describió en Creación de conjuntos de grupos. La configuración de PiT se lleva a cabo en el sitio de producción (protegido) en el nivel de máquinas virtuales. La figura 90. Interfaz de VSI RecoverPoint Management muestra la interfaz junto con una prueba de failover activo de VMware SRM con la última imagen consistente.


La figura 90. Interfaz de VSI RecoverPoint Management

En la Figura 91, se muestran los detalles de cómo se aplica un PiT en lugar de utilizar la imagen actual. Solo es necesario aplicar el PiT a una entrada para cada grupo de consistencia. Tenga en cuenta que debe aplicar un PiT a cada grupo de consistencia involucrado en el grupo de protección.

La figura 91. Aplicación de un PiT en VSI para los grupos de consistencia de RecoverPoint


Existe una manera fácil de comprobar que la operación se realizó correctamente. En VSI existe una vista secundaria llamada “Grupos de protección” que muestra todos los grupos de consistencia relacionados con el grupo. La vista que se ve en la Figura 92 se muestra después de aplicar los PiT.

La figura 92. Visualización de PiT asignados en VSI

El usuario también puede establecer una “fecha de vencimiento” para la imagen de modo que no se utilice después de una fecha determinada. Para comenzar, seleccione un grupo de consistencia con un PiT configurado. Elija las palabras azules “Establecer fecha de vencimiento” para abrir el cuadro de diálogo. Seleccione una fecha, tal como se muestra en la Figura 93, para el vencimiento del PiT y seleccione Aceptar. La columna Fecha de vencimiento se actualizará con la fecha. Se recomienda que la fecha de vencimiento sea la misma para todos los grupos de consistencia que participan en la prueba de SRM. Si no se aplica una fecha de vencimiento, el PiT se utilizará en cualquier momento que se ejecute un failover de prueba de SRM, siempre que el PiT no se haya modificado manualmente.


La figura 93. Configuración de una fecha de vencimiento para un PiT de RecoverPoint en VSI

Prueba de failover

Para iniciar una prueba de failover, en el vCenter remoto, desplácese hasta el icono de recuperación de sitios desde la página de inicio de vCenter, como se muestra en la Figura 94.

La figura 94. Icono de Site Recovery Manager en el servidor vSphere vCenter


Inicie sesión en el sitio y seleccione el plan EBS_Recovery_Group creado anteriormente. En este punto, es posible ejecutar la prueba. En la pantalla siguiente, Figura 95, se muestran los tres pasos que deben ejecutarse. Primero, seleccione “Prueba” de las opciones del panel. Cuando se muestra el segundo cuadro de diálogo, deseleccione la casilla para replicar cambios recientes. Esta opción no es pertinente a RecoverPoint SRA pero si se deja seleccionada SRM agrega tiempo de prueba adicional a la prueba de failover. Seleccione “Siguiente” y luego “Iniciar” para comenzar la prueba de failover.

La figura 95. Prueba de failover del ambiente EBS en SRM con RecoverPoint


Mientras se ejecuta la prueba, puede observarse el estado de los grupos de consistencia de RecoverPoint en el sitio remoto para identificar cuándo se activa el acceso a imágenes. Figura 96 muestra la transformación de un estado a otro.

La figura 96. Acceso a imagen de RecoverPoint durante la prueba de failover de SRM


Con las imágenes activadas, las máquinas virtuales se incorporan en el ambiente interno para las pruebas. Figura 97 muestra el paso de recuperación en que las máquinas virtuales están en proceso de inicio.

La figura 97. Pasos de recuperación de SRM, encendido de la máquina virtual

Poco después de que las máquinas virtuales se encienden, la prueba finaliza correctamente, como se muestra en la Figura 98.

La figura 98. Prueba de failover de SRM correcta


Después de completar la prueba de failover, podemos ver que todas las áreas de almacenamiento de datos están conectadas y, de manera predeterminada, tienen una nueva firma y un nuevo nombre, como se ve en la Figura 99.

El prefijo “snap-xxxx” que se muestra en la Figura 99 puede desactivarse a través de VMware SRM para que los nombres del área de almacenamiento de datos sean iguales a los del ambiente de producción. Esto puede ser recomendable si hay scripts del cliente que utilizan los nombres de las áreas de almacenamiento de datos.

La figura 99. Visualización de áreas de almacenamiento de datos para el nodo de RAC en el sitio de prueba de failover


Ahora conecte a la consola uno de los nodos de RAC, dsib2124, que se ejecuta en la red interna (sin conflictos de IP) y ejecute los mismos comandos que se realizaron en Figura 58 (se muestra en la Figura 100).

La figura 100. Estado del nodo de RAC en el sitio de prueba de failover

La prueba se realizó correctamente con todas las máquinas virtuales en funcionamiento, y el ambiente de aplicaciones Oracle está listo para el acceso.12

12 Oracle Applications requiere cierta personalización de los niveles de aplicaciones para automatizar el proceso de los servicios que se presentan.


PiT de RecoverPoint con VSI en la recuperación de desastres

La funcionalidad detallada en esta sección está disponible únicamente con RecoverPoint 4.0 P1 y superior.

Como se muestra en la sección anterior sobre la prueba de SRM con RecoverPoint, para obtener los marcadores de PiT de los grupos de consistencia de RecoverPoint, VSI consulta al dispositivo RecoverPoint del sitio de producción (protegido). En un desastre real, sin embargo, el sitio de producción no está disponible y VSI RM no puede ejecutar la consulta para obtener los PiT. Si un failover de SRM se ejecuta en ese punto, como se muestra en la Figura 101, RecoverPoint usará la última copia consistente (marcador) para todos los grupos de consistencia.

La figura 101. Recuperación de SRM: migración o recuperación de desastres planificada


Para muchas empresas esto será perfectamente aceptable, porque desean contar con un sitio de recuperación de desastres lo más cercano posible al sitio de producción antes del failover. Otras empresas, sin embargo, quizá deseen realizar la recuperación a un punto específico a fin de evitar problemas de daños lógicos, o por motivos de negocios. Si hay un requisito de utilizar un PiT anterior a la última copia consistente, existe un proceso que se debe seguir para permitir la selección de PiT en el sitio de recuperación con VSI RM. Esto se explica en la siguiente sección.

Activación de PiT con VSI RM en el sitio de recuperación

Una vez que se tome la decisión de iniciar una recuperación de desastres con un PiT en lugar de con la última copia consistente, es necesario seguir los siguientes pasos:

1. Para comenzar, active la opción dentro de VSI RM que permite un failover de prueba con el ambiente RecoverPoint en un estado de división. Para configurarlo, abra el ambiente del sitio de recuperación de vCenter. Desplácese hasta el icono de EMC en la página de inicio, que se mostró en la Figura 4, que abrirá la pantalla de administración de VSI. Una vez en VSI, tome las siguientes medidas que se representan en la Figura 102:

1. Seleccione la función RecoverPoint Management del menú izquierdo.

2. Resalte el servidor de RecoverPoint configurado. La configuración de estos servidores se demostró anteriormente en la Figura 88. Este servidor RecoverPoint debe estar en el sitio de failover.

3. Seleccione el botón “Permitir failover de prueba” en la parte superior.

4. Confirme la selección. Aparecerá una tarea para esta acción.


La figura 102. Habilitación del failover de prueba en VSI cuando el sitio protegido no está disponible

2. Cuando la tarea de VMware se indica con el estado “Completada”, ejecute un failover de prueba con VMware SRM. Dado que la funcionalidad de VSI en el sitio de producción no estará disponible, la copia de failover será la última copia consistente O un PiT configurado anteriormente y cuya fecha de vencimiento (si corresponde) no haya pasado. Para ahorrar tiempo y reducir el tiempo fuera total a causa del desastre, puede resultar útil cambiar el estado de encendido de las máquinas virtuales para que no se activen.

Tenga en cuenta que si había un PiT no vencido definido anteriormente y ya no está disponible en los registros, el failover de prueba fallará y la única opción será ejecutar la recuperación de desastres con la última copia consistente. Si la recuperación de PiT es fundamental para el ambiente en caso de desastres, asegúrese de limpiar el PiT en VSI después de cada prueba, o de configurar una fecha de vencimiento para que no haya posibilidad de que se depure el PiT del registro antes de su vencimiento.


3. Una vez que el failover de prueba finalice (antes de la limpieza), todos los PiT estarán disponibles en la pestaña EMC VSI en el sitio de recuperación. Figura 103 demuestra que el sitio de recuperación en San Francisco ahora obtiene acceso a todos los marcadores (snapshots) que estaban disponibles en el sitio protegido antes del desastre.

La figura 103. Selección de PiT en el sitio de recuperación después del failover de prueba


4. Como se muestra en la Figura 91, aplique el PiT deseado a cada uno de los grupos de consistencia.13 En este ejemplo, que se muestra en la Figura 104, se desea usar un PiT de aproximadamente 20 minutos antes del desastre para evitar el daño lógico que ocurrió después de ese momento. Este es EBS_Group_Set 399332 y se muestra en la Figura 104.

La figura 104. Asignación de PiT en el sitio de recuperación antes del failover de recuperación de desastres

13 A diferencia de la Figura 92, la vista Grupos de protección no está disponible en el sitio de recuperación.


5. Una vez configurado el PiT, se requiere una limpieza de SRM para que el PiT real pueda aplicarse durante el failover de recuperación de desastres representado en la Figura 101. La limpieza se muestra a continuación en la Figura 105.

La figura 105. Ejecución de una “limpieza” en VMware SRM después de la selección de un PiT

6. Una vez que se complete la limpieza, si así se configuró anteriormente, modifique las máquinas virtuales que forman parte del plan de recuperación para que se enciendan durante el failover de recuperación de desastres.


7. Ejecute el failover de recuperación de desastres tal como se indica en la Figura 106. Si es un escenario verdadero de recuperación de desastres en que el sitio de producción no está disponible, esta tarea devolverá advertencias y errores, que se muestran en la Figura 107, a pesar de ejecutar el ambiente correctamente. Esta situación es esperada.

La figura 106. Ejecución de recuperación de desastres para VMware SRM

La figura 107. Errores esperados de VMware SRM en un failover real


Cuando finalice, RecoverPoint mostrará el sitio remoto como activo, con acceso directo al almacenamiento y recuperado al PiT elegido, mientras el sitio local es desconocido. El enlace también mostrará un error o el estado N/D, como se muestra en la Figura 108. La recuperación de desastres ha finalizado.

La figura 108. Sitio de RecoverPoint activo después del failover de recuperación de desastres

Una consideración importante al utilizar SRM es que el tiempo necesario para ejecutar una prueba o un failover real se determina en gran parte por el marcador de PiT en RecoverPoint. Cuanto mayor sea la antigüedad del marcador, más demorará RecoverPoint en permitir el acceso a la imagen y, por lo tanto, en completar el failover. VMware SRM 5.x fuerza un tiempo de espera de 300 segundos (cinco minutos) para todas las operaciones de Storage Replication Adapter (SRA). Si un SRA no completa una operación dentro de este límite de tiempo, el SRM finalizará la operación y, posiblemente, provocará que el ambiente tenga un estado no deseado. Es más probable que se agote este tiempo de espera si el PiT de RecoverPoint no es reciente. Para obtener información sobre cómo cambiar el valor de tiempo de espera, consulte la documentación pertinente sobre VMware SRM.


Recomendaciones para el uso de RecoverPoint con VMware SRM Las siguientes son las recomendaciones generales que se deben seguir al utilizar RecoverPoint con SRM:

• Agrupe todos los LUN de grupos de protección de SRM en un solo grupo de consistencia o varios grupos de consistencia de RecoverPoint. Esta agrupación permite garantizar que se incluyan los LUN de grupos de protección de SRM en los grupos de consistencia de RecoverPoint.

• Asegúrese de que los grupos de consistencia de RecoverPoint que contienen LUN de grupos de protección de SRM no contengan LUN de grupos de protección que no sean de SRM. De lo contrario, si estos LUN se agregan al grupo de consistencia, serán manejados por SRM.

• Asegúrese de que los grupos de RecoverPoint no contengan LUN de más de un grupo de protección de SRM. De lo contrario, SRM puede intentar operar simultáneamente en el mismo grupo de consistencia. Este intento puede hacer que las operaciones de SRM fallen o no funcionen como corresponde.

• Además de VMware SRM, puede usar la GUI y la interfaz de la línea de comandos de RecoverPoint para monitorear el sistema RecoverPoint. Sin embargo, no se recomienda ejecutar operaciones simultáneamente en el mismo grupo de consistencia que utiliza VMware SRM y RecoverPoint (GUI o grupo de consistencia), ya que esto puede provocar interferencias entre las operaciones. Sin embargo, por lo general, RecoverPoint impedirá que el usuario ejecute esta acción.

Conclusión EMC VPLEX Metro con el sistema operativo GeoSynchrony es una tecnología de clase empresarial que elimina la distancia mediante la distribución de dispositivos de almacenamiento de bloques heterogéneos gracias a un aumento de la disponibilidad y la movilidad. EMC RecoverPoint ofrece protección de datos y replicación remota continuas para la protección sobre pedido y recuperación a cualquier punto en el tiempo. RecoverPoint garantiza la replicación remota continua sin afectar el rendimiento. RecoverPoint y VPLEX Metro, en combinación con las tecnologías de disponibilidad de VMware y Oracle, VMware SRM y RAC, brindan nuevos niveles de disponibilidad y recuperación de desastres adecuados para los ambientes más importantes sin concesiones, que van más allá de cualquier otra solución disponible en el mercado actual.

Estas tecnologías proporcionan la base a partir de la cual el cliente puede asegurar la alta disponibilidad en hardware y software mediante la naturaleza de VPLEX Metro y de Oracle RAC expandido. No solo el ambiente es altamente disponible, sino que está protegido con una solución de recuperación de desastres sólida, nuevamente a través de hardware y software. RecoverPoint junto con VMware SRM satisfacen los beneficios de una solución de recuperación de desastres de hardware empresarial, con los beneficios de una solución de software empresarial. La administración de estas tecnologías con GUI fáciles de usar hace que el trabajo de administrarlas sea tan simple como la tecnología en sí.


Referencias

EMC • Techbook Using EMC Symmetrix Storage in VMware vSphere Environments

http://www.mexico.emc.com/collateral/hardware/solution-overview/h2529-vmware-esx-svr-w-symmetrix-wp-ldv.pdf

• Implementing EMC Symmetrix Virtual Provisioning with VMware vSphere

http://mexico.emc.com/collateral/hardware/white-papers/h6813-implting-symmetrix-vrtl-prvsning-vsphere-wp.pdf

• Implementing VMware vStorage API for Storage Awareness with Symmetrix Storage Arrays

http://mexico.emc.com/collateral/software/white-papers/h10630-vmware-vasa-symmetrix-wp.pdf

El siguiente material se encuentra disponible en el sitio web Support.EMC.com (visite el sitio web de su país correspondiente):

• Oracle Databases on EMC Symmetrix Storage Systems TechBook

• Implementing Fully Automated Storage Tiering with Virtual Pools (FAST VP) for EMC Symmetrix VMAX Series Arrays

• VSI for VMware vSphere Storage Viewer Product Guide 5.5 Product Guide

• Unisphere for VMAX Product Guide

• Unisphere for VPLEX Product Guide

• EMC VPLEX with GeoSynchrony 5.1 Documentation

• EMC VPLEX Metro 5.0 Witness Technology and Absolute High Availability

• Documentación de RecoverPoint 4.0

VMware • vSphere Storage ESXi 5.1

http://pubs.vmware.com/vsphere-51/topic/com.vmware.ICbase/PDF/vsphere-esxi-vcenter-server-51-storage-guide.pdf

• vSphere Installation and Setup Guide

http://pubs.vmware.com/vsphere-51/topic/com.vmware.ICbase/PDF/vsphere-esxi-vcenter-server-51-installation-setup-guide.pdf

• Virtual Machine Administration Guide

http://pubs.vmware.com/vsphere-51/topic/com.vmware.ICbase/PDF/vsphere-esxi-vcenter-server-51-virtual-machine-admin-guide.pdf

















El siguiente material se encuentra disponible en el sitio web de VMware:

• Oracle Databases on VMware Best Practices Guide

• VMware vSphere Metro Storage Cluster Case Study

Oracle

El siguiente material se encuentra disponible en el sitio web de soporte de Oracle:

• Oracle Applications Installation Guide: Using Rapid Install Release 12

• Oracle Applications Concepts Release 12

• Oracle Database 11g R2 Upgrade Guide

• Using Oracle 11g Release 2 Real Application Clusters with Oracle E-Business Suite Release 12 [ID 823587.1]

• Database Initialization Parameters for Oracle E-Business Suite Release 12 [ID 396009.1]

• Database Documentation Resources for EBS Release 11i and R12 [ID 1072409.1]

USO DE VPLEX METRO Y RECOVERPOINT CON VMWARE SRM EN UN ENTORNO ORACLE … · con Oracle Applications en Oracle RAC extendido para ... FAST VP en el cluster VPLEX Metro ... Interfaz

Documents