CONTINUIDAD DEL NEGOCIO DE MISIÓ N CRÍTICA DE EMC PARA SAP

Transcripción

1 Informe técnico CONTINUIDAD DEL NEGOCIO DE MISIÓ N CRÍTICA DE EMC PARA SAP Administración simplificada para ofrecer alta disponibilidad y continuidad del negocio Implementaciones resistentes de misión crítica de SAP Centro de datos activo/activo EMC Solutions Group Resumen Este informe técnico describe la transformación de una implementación de SAP tradicional en una solución de continuidad del negocio de misión crítica con centros de datos de tipo activo/activo. La solución está conformada por EMC VPLEX Metro, EMC Symmetrix VMAX, VMware vsphere High Availability, Oracle RAC, redes de Brocade y SUSE Linux Enterprise Server for SAP Applications. Noviembre de 2012

2 Copyright 2012 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, VMware vsphere, ESXi, vcenter y vmotion son marcas comerciales o marcas registradas de VMware, Inc. en los Estados Unidos y en otras jurisdicciones. Brocade, DCX, MLX, VCS y VDX son marcas comerciales o marcas registradas de Brocade Communications Systems, Inc. en los Estados Unidos y en otros países. Todas las demás marcas comerciales incluidas/utilizadas en este documento pertenecen a sus respectivos propietarios. Número de referencia H

3 Tabla de contenido Resumen ejecutivo... 5 Análisis de rentabilidad... 5 Descripción general de la solución... 5 Beneficios clave... 6 Introducción... 8 Propósito... 8 Alcance... 8 Público al que va dirigido... 8 Terminología... 8 Descripción general de la solución Introducción Arquitectura de la solución Capas de protección Perfil de la base de datos y del tipo de carga Recursos de hardware Recursos de software Infraestructura de almacenamiento de EMC Introducción EMC Symmetrix VMAX 10K Enginuity EMC Symmetrix VMAX 20K EMC Unisphere for VMAX Configuración de VMAX Infraestructura de EMC VPLEX Metro Introducción Movilidad de datos de VPLEX Configuración de la solución de VPLEX Metro Configuración de VPLEX Witness Monitoreo del rendimiento de VPLEX Infraestructura virtualizada de VMware Introducción Implementaciones de VMware en VPLEX Metro Configuración de cluster extendido de VMware Configuración de VMware vsphere HA Configuración de VMware vsphere DRS EMC Virtual Storage Integrator y VPLEX

4 Arquitectura del sistema SAP Introducción Configuración del sistema SAP Configuración de SUSE Linux Enterprise High Availability Extension Arquitectura de base de datos de Oracle Introducción Oracle RAC y VPLEX Configuración de Oracle ACFS Oracle RAC extendido en VPLEX Metro Configuración del grupo de discos de Oracle ASM Infraestructura de red de Brocade Introducción Configuración de red IP Configuración de red SAN Alta disponibilidad y continuidad del negocio: pruebas y validación Introducción Falla del proceso de servicio de línea de espera de SAP Falla de la máquina virtual de instancia de SAP ASCS Falla de nodo de Oracle RAC Falla del sitio Aislamiento del cluster VPLEX Conclusión Resumen general Hallazgos Referencias EMC Oracle VMware SUSE SAP Apéndice: Configuraciones de ejemplo Ejemplo de configuración de CRM Ejemplo de perfil de instancia de ASCS Ejemplo de perfil de instancia de ERS Ejemplo de perfil de inicio de ERS Ejemplo de perfil de instancia de DI

5 Resumen ejecutivo Análisis de rentabilidad Las empresas globales exigen disponibilidad continua de la información y de las aplicaciones para mantenerse competitivas. La solución de EMC descrita en este informe técnico ofrece una estrategia de alta disponibilidad y continuidad del negocio para aplicaciones de misión crítica, como SAP ERP. Los objetivos de punto de recuperación (RPO) y los objetivos de tiempo de recuperación (RTO) son métricas clave cuando se planifica una estrategia de continuidad del negocio de misión crítica. Responden a dos preguntas fundamentales que los negocios se formulan al considerar el posible impacto de un desastre o una falla: Cuántos datos se puede permitir perder (RPO)? Con cuánta rapidez necesitamos que el sistema o aplicación se recupere (RTO)? La continuidad del negocio de misión crítica para SAP requiere de un RPO y RTO dinámicos para minimizar la pérdida de datos y los tiempos de recuperación. Los principales retos que debe considerar el negocio cuando se diseña una estrategia como esta son los siguientes: Minimización del RPO y el RTO. Eliminación de puntos únicos de falla (SPOF): tecnología, personas, procesos Maximización de la utilización de recursos Reducción de los costos de infraestructura Administración de la complejidad asociada a la integración, el mantenimiento y la prueba de varias soluciones puntuales Este informe técnico presenta una solución de EMC que enfrenta todos estos retos para las aplicaciones de SAP ERP con una capa de base de datos Oracle Real Applications Clusters (RAC) 11g. La solución demuestra un modelo de implementación innovador activo/activo para centros de datos separados por una distancia de hasta 100 km. Esto transforma el modelo de recuperación de desastres en modo activo/pasivo tradicional en una solución de continuidad del negocio de alta disponibilidad, con una disponibilidad de las aplicaciones 24x7, sin puntos únicos de falla, y con RTO y RPO cercanos a cero. Descripción general de la solución EMC VPLEX Metro es la principal tecnología que habilita las funcionalidades de esta solución. VPLEX Metro es una solución de federación basada en SAN que brinda federación de almacenamiento local y distribuido. Su innovadora tecnología, AccessAnywhere TM, permite que los mismos datos existan en dos ubicaciones geográficamente distantes, y permite acceder a ellos y actualizarlos en ambas ubicaciones al mismo tiempo. Con la incorporación de VPLEX Witness a la solución, las aplicaciones continúan estando disponibles, sin interrupciones ni tiempo fuera, incluso en el caso de que ocurra una interrupción en uno de los centros de datos. 5

6 El informe técnico demuestra cómo las siguientes tecnologías crean esta solución de continuidad del negocio innovadora: EMC VPLEX Metro ofrece la capa de almacenamiento virtual que permite un centro de datos Metro activo/activo. La movilidad de datos de VPLEX permite la transferencia no disruptiva de los datos en la capa de almacenamiento. EMC VPLEX Witness es compatible con la disponibilidad continua de las aplicaciones, incluso en el caso de que se produzca una interrupción en uno de los centros de datos. Los arreglos de almacenamiento de la serie EMC Symmetrix VMAX 10K con Enginuity, la disponibilidad comprobada de cinco nueves, la compatibilidad con FAST (Fully Automated Storage Tiering) y las alternativas de tecnologías de replicación proporcionan las plataformas de almacenamiento de clase empresarial para la solución. La migración de una base de datos de única instancia a Oracle RAC en clusters a grandes distancias elimina los puntos únicos de falla en la capa de base de datos y a distancia. VMware vsphere virtualiza los componentes de las aplicaciones de SAP y evita que se conviertan en puntos únicos de falla. VMware High Availability (HA) protege las máquinas virtuales en el caso de que se produzcan fallas en el servidor físico y en el sistema operativo. SUSE Linux Enterprise Server for SAP Applications, con SUSE Linux Enterprise High Availability Extension y el servidor de replicación de línea de espera (ERS) de SAP, protege los servicios centrales de SAP (servidor de mensajes y servidor de línea de espera) en dos nodos de cluster para evitar que estos servicios se conviertan en puntos únicos de falla. Los fabrics Ethernet y los enrutadores centrales MLXe de Brocade ofrecen conexión de red transparente y extensión de la capa 2 entre sitios. Las redes troncales Brocade DCX 8510 ofrecen infraestructura SAN redundante, incluida la extensión de fabric. Beneficios clave Para aumentar la disponibilidad de las aplicaciones de SAP, la solución brinda lo siguiente: Eliminación de puntos únicos de falla en todas las capas del ambiente para crear un sistema SAP distribuido y con alta disponibilidad. Centros de datos de tipo activo/activo que admiten RPO y RTO cercanos a cero y continuidad del negocio de misión crítica. Entre los beneficios adicionales se incluyen los siguientes: Symmetrix VMAX 10K ofrece ambientes de almacenamiento validados y confiables para SAP. Manejo de fallas completamente automático. Mayor utilización de los recursos de hardware y software: Utilización de ambos centros de datos en modo activo/activo. Balanceo automático de carga entre centros de datos. Mantenimiento sin tiempo fuera. 6

7 Administración de SAP simplificada de alta disponibilidad Implementación simplificada de Oracle RAC en clusters a grandes distancias. Menores costos mediante el aumento de la automatización y la utilización de la infraestructura. Transferencia rápida y sencilla de los datos entre los arreglos de almacenamiento. 7

8 Introducción Propósito Este informe técnico describe una solución que aumenta la disponibilidad de las aplicaciones de SAP creando centros de datos de tipo activo/activo en ubicaciones geográficamente distantes y eliminando los puntos únicos de falla en todas las capas del ambiente. En ambientes SAP, la interrupción del negocio puede deberse a fallas técnicas, lógicas o logísticas. Esta solución enfrenta la continuidad del negocio desde la perspectiva técnica. Alcance El alcance de este informe técnico es el siguiente: Presentar las tecnologías habilitadoras clave. Describir la arquitectura y el diseño de la solución. Describir cómo se configuran los componentes clave. Presentar los resultados de las pruebas realizadas para demostrar la eliminación de los puntos únicos de falla en todas las capas del ambiente. Identificar los beneficios clave de la solución para el negocio. Público al que va dirigido Terminología Este informe técnico está dirigido a administradores de SAP Basis, administradores de bases de datos de Oracle, administradores de almacenamiento, arquitectos de TI y administradores técnicos responsables del diseño, la creación y la administración de aplicaciones de SAP de misión crítica en ambientes 24/7. Este informe técnico incluye los términos de la Tabla 1. Tabla 1. Término AAS ABAP ACFS ASCS ASM CIFS CNA CRM DI DPS DRS dvswitch DWDM ERP ERS FAST VP FCoE FEC FRA Terminología Descripción Servidor de aplicaciones adicional de SAP SAP Advanced Business Application Programming Sistema de archivos en cluster de ASM de Oracle Servicios centrales de SAP de ABAP Oracle Automatic Storage Management Common Internet File System Adaptador de red convergente Administrador de recursos de cluster Instancia de diálogo Selección dinámica de rutas VMware vsphere Distributed Resource Scheduler Switch distribuido de vsphere Multiplexación por división en longitudes de onda densas Planificación de recursos empresariales Servidor de replicación de línea de espera Fully Automated Storage Tiering for Virtual Pools Fibre Channel mediante Ethernet Corrección de errores hacia adelante Área de recuperación de flash 8

9 Término HA HAIP HBA IDES ISL LACP LAG LLDP LUW MCT MPLS MPP NAS NFS SAS NL OCR Oracle RAC extendido RAC RFC RPO RTO SAN SBD SFP SLES SLE HAE SMT SPOF STONITH TAF ToR VCS vlag vlan VMDK VMFS VMware HA VPLS VPN VRF VSI Descripción High Availability IP virtual con alta disponibilidad Tarjeta HBA (Host Bus Adapter) Sistema de demostración y evaluación por Internet de SAP Interswitch link Protocolo de control de agregación de enlaces Grupo de agregación de enlaces Link Layer Discovery Protocol Unidad lógica de trabajo Trunking de múltiples chasis Multi-Protocol Label Switching Plug-in de múltiples rutas Almacenamiento conectado en red Network File System Disco SAS nearline Oracle Cluster Registry Oracle RAC en clusters a grandes distancias Real Application Clusters Llamada de función remota Objetivo de punto de recuperación Objetivo de tiempo de recuperación Red de almacenamiento SAN Dispositivo de bloques STONITH Conector Small Form-Factor Pluggable SUSE Linux Enterprise Server SUSE Linux Enterprise High Availability Extension Subscription Management Tool Punto único de falla Shoot The Other Node In The Head Failover transparente de las aplicaciones Parte superior del rack Switch de cluster virtual Grupo de agregación de enlaces virtual LAN virtual Disco virtual Virtual Machine File System VMware High Availability Servicio de LAN privada virtual Red privada virtual Virtual Routing and Forwarding Virtual Storage Integrator 9

10 Descripción general de la solución Introducción Implementaciones de SAP: el reto y la solución Las implementaciones de SAP tradicionales tienen varios puntos únicos de falla (SPOF), entre ellos: Servicios centrales Servidor de línea de espera* Servidor de mensajes* Servidor de bases de datos Implementación en un solo sitio Almacenamiento en disco local * En esta solución, los servidores de línea de espera y de mensajes se implementan como servicios dentro de la instancia de servicios centrales de SAP de ABAP (ASCS). Este informe técnico presenta una solución para aumentar la disponibilidad de las aplicaciones de SAP. La arquitectura y los componentes de la solución crean una solución agrupada en clusters de tipo activo/activo para toda la plataforma de SAP a fin de aumentar la confiabilidad y la disponibilidad, a la vez que se simplifican la implementación y la administración del ambiente. Esta solución proporciona los siguientes beneficios: Elimina los puntos únicos de falla en todas las capas del ambiente para crear un sistema SAP de alta disponibilidad. Proporciona centros de datos de tipo activo/activo para permitir la continuidad del negocio de misión crítica. Figura 1 La ilustra los puntos únicos de falla en un ambiente SAP y los componentes de la solución que se utilizan para enfrentarlos. Figura 1. Implementaciones de SAP: el reto y la solución 10

11 Arquitectura de la solución En las secciones siguientes, se describen las soluciones implementadas en cada capa del ambiente para ofrecer alta disponibilidad y continuidad del negocio, como se muestra en la Figura 2. Figura 2. El viaje hacia la alta disponibilidad: vista lógica Alta disponibilidad de la capa de almacenamiento Todo el almacenamiento que necesita cada servidor en el ambiente se transfirió a arreglos de almacenamiento de clase empresarial VMAX 10K y VMAX 20K. Se implementaron redes troncales Brocade 8510 para brindar un fabric para SAN redundante para el acceso al almacenamiento. Esto aprovecha el tiempo de actividad comprobado de cinco nueves que proporcionan los arreglos y las redes troncales de SAN, incluidas sus funciones avanzadas de capacidad de administración y continuidad del negocio. Figura 3. Alta disponibilidad del almacenamiento Alta disponibilidad de la base de datos El servidor de base de datos es el catálogo de datos para la aplicación SAP. Para esta solución, la base de datos de backend se convirtió de una base de datos de única instancia de Oracle en un cluster Oracle RAC de cuatro nodos. De este modo, se eliminó el servidor de base de datos como punto único de falla. Figura 4. Alta disponibilidad de la base de datos 11

12 Alta disponibilidad de las aplicaciones de SAP Los servidores de aplicaciones de SAP se virtualizaron por completo mediante VMware ESXi TM 5.0. Cada una de las máquinas virtuales de SAP se implementó mediante SUSE Linux Enterprise Server for SAP Applications 11 SP1 como el sistema operativo huésped. También se implementaron SUSE Linux Enterprise High Availability Extension y el servidor de replicación de línea de espera (ERS) de SAP para proteger los servidores de línea de espera y de mensajes de SAP. Esto elimina los servicios centrales de SAP de ABAP (ASCS) como punto único de falla. Figura 5. Alta disponibilidad de las aplicaciones de SAP Alta disponibilidad del centro de datos La solución de cluster de alta disponibilidad descrita anteriormente protege a SAP dentro del centro de datos. Para lograr alta disponibilidad entre los centros de datos, la solución utiliza la tecnología de virtualización de almacenamiento EMC VPLEX Metro, como se muestra en la Figura 6. La tecnología exclusiva de agrupación en clusters de tipo activo/activo AccessAnywhere de VPLEX Metro permite el acceso de lectura/escritura a volúmenes distribuidos a distancias síncronas. Mediante el espejeado de los datos entre ubicaciones, VPLEX permite que los usuarios de ambas ubicaciones tengan acceso a la misma información al mismo tiempo. Figura 6. Alta disponibilidad del centro de datos Esta solución combina VPLEX Metro con SUSE Linux Enterprise High Availability Extension (en la capa del sistema operativo) y Oracle RAC (en la capa de la base de datos) para eliminar el centro de datos como punto de falla y ofrecer una estrategia de continuidad del negocio sólida para las aplicaciones de misión crítica. 12

13 Oracle RAC en clusters a grandes distancias por medio de VPLEX brinda los beneficios siguientes: VPLEX simplifica la administración de Oracle RAC extendido, ya que la alta disponibilidad entre sitios se incorpora a nivel de la infraestructura. Para el administrador de bases de datos de Oracle, la instalación, la configuración y el mantenimiento son exactamente iguales a una implementación de Oracle RAC en un solo sitio. VPLEX elimina la necesidad de espejeado basado en host de discos de ASM y los ciclos de CPU del host que consume esta tarea. Con VPLEX, los grupos de discos de ASM se configuran con redundancia externa y se protegen mediante espejeado distribuido de VPLEX. Los hosts deben conectarse a su cluster VPLEX local solamente y el I/O se envía solo una vez desde dicho nodo. Sin embargo, los hosts tienen acceso completo de lectura/escritura a la misma base de datos en los dos sitios. Con el espejeado basado en host de los grupos de discos de ASM, cada I/O de escritura debe enviarse dos veces, una vez a cada copia espejeada. No es necesario implementar un voting disk de Oracle en un tercer sitio para que actúe como dispositivo de quórum a nivel de las aplicaciones. VPLEX le permite crear grupos de consistencia que protegen varias bases de datos y/o aplicaciones como una unidad. La solución utiliza VPLEX Witness para monitorear la conectividad entre los dos clusters VPLEX y garantizar la disponibilidad continua en caso de que se produzca una falla en una partición de red entre clusters o una falla en un cluster. VPLEX Witness se implementa en una máquina virtual en un tercer dominio de falla separado (sitio C). Alta disponibilidad de red En cada centro de datos, se creó un fabric Ethernet mediante la tecnología de switch de cluster virtual (VCS) de Brocade, la cual ofrece una capa de acceso resistente y de autorreparación con reenvío de todos los enlaces. Los grupos de agregación de enlaces virtuales (vlag) conectan los fabrics VCS con los enrutadores centrales Brocade MLXe que amplían la red de la capa 2 en los dos centros de datos. Figura 7 La muestra la arquitectura física de todas las capas de la solución, incluidos los componentes de red. 13

14 Figura 7. Arquitectura de la solución 14

15 Capas de protección Tabla 2 La resume las capas de alta disponibilidad (HA) que la solución utiliza para eliminar los puntos únicos de falla. Tabla 2. Alta disponibilidad local: Alta disponibilidad local: Protección Sitio Componentes protegidos VMware HA y VMware DRS A y B Máquinas virtuales de SAP SUSE Linux Enterprise HAE y servidor de replicación de línea de espera de SAP Varias instancias de diálogo de SAP A y B A y B Servidor de línea de espera de SAP, servidor de mensajes de SAP Procesos de trabajo de SAP (DIA, UPD, UP2, SPO) VMware A, B y C Virtualización de servidores Oracle RAC A y B Base de datos de Oracle Oracle Clusterware A y B Sistema de archivos compartido de SAP Oracle ACFS A y B SAP Oracle Home, directorio global de SAP, directorio de transporte de SAP, directorio de SAP ASCS EMC Symmetrix VMAX 20K A Almacenamiento local, RAID, múltiples rutas EMC Symmetrix VMAX 10K B Almacenamiento local, RAID, múltiples rutas VPLEX Metro amplía la alta disponibilidad con una arquitectura de agrupación en clusters que traspasa las barreras del centro de datos y permite que los servidores de varios centros de datos tengan acceso de lectura/escritura a los dispositivos de almacenamiento de bloques compartidos. Esta transformación del centro de datos lleva la alta disponibilidad tradicional a un nuevo nivel de continuidad del negocio de misión crítica. Figura 8 La ilustra este diseño de alta disponibilidad, con VPLEX Witness y la conexión entre clusters implementados a fin de brindar el nivel más alto de resistencia. Figura 8. Alta disponibilidad local con VPLEX que permite la continuidad del negocio remota 15

16 Cada una de las tecnologías mostradas en la Figura 8 se analiza de manera más detallada en las secciones correspondientes del informe técnico. Perfil de la base de datos y del tipo de carga Tabla 3 La proporciona detalles acerca del perfil de la base de datos y del tipo de carga de la solución. Tabla 3. Perfil de la base de datos y del tipo de carga Característica del perfil Cantidad de bases de datos 1 Detalles Tipo de base de datos Tamaño de la base de datos Nombre de la base de datos Oracle RAC Perfil del tipo de carga SAP OLTP 500 GB VSE 4 nodos físicos Procesos personalizados de la orden al recibo de SAP Recursos de hardware Tabla 4 La describe los recursos de hardware de la solución. Tabla 4. Ambiente de hardware de la solución Propósito Cantidad Configuración Almacenamiento (sitio A) 1 Serie Symmetrix VMAX 20K con Enginuity: 2 motores 171 unidades FC de 450 GB 52 unidades SATA de 2 TB Almacenamiento (sitio B) 1 Serie Symmetrix VMAX 10K con Enginuity: 1 motor 30 discos SAS NL de 2 TB 79 discos SAS de 600 GB Federación de almacenamiento distribuido Servidores de base de datos Oracle RAC 2 Cluster VPLEX Metro, con: 2 motores VS2 4 4 CPU de ocho cores, 128 GB de RAM VMware ESXi Server para SAP 4 2 CPU de cuatro cores, 128 GB de RAM VMware ESXi Server para VPLEX Witness Plataforma de enrutamiento y switch de red 2 2 CPU de dos cores, 48 GB de RAM 2 Red troncal Brocade DCX 8510, con: Tarjeta de extensión FC Fx blades FC de 48 puertos con compatibilidad con velocidad de línea FC de 16 Gb Enrutador Brocade MLXe 4 Brocade VDX 6720 en modo VCS 16

17 Recursos de software Tabla 5 La describe los recursos de software de la solución. Tabla 5. Ambiente de software de la solución Software Versión Propósito EMC Enginuity Enginuity 5876 Q SR Ambiente operativo para Symmetrix VMAX EMC VPLEX GeoSynchrony 5.1, parche 2 Ambiente operativo VPLEX EMC VPLEX Witness 5.1, parche 2 Componente de monitoreo y arbitraje para el manejo de fallas de clusters VPLEX y pérdida de comunicación entre clusters EMC Unisphere TM 5.1 Software de administración de VPLEX EMC Unisphere T Software de administración de VMAX EMC Virtual Storage Integrator (VSI) Integración con almacenamiento de VMware EMC PowerPath/VE 5.7 P01 (compilación 2) Software de múltiples rutas SUSE Linux Enterprise Server for SAP Applications, que incluye SUSE Linux Enterprise High Availability Extension 11 SP1 Sistema operativo para todos los servidores del ambiente VMware vsphere Oracle Database 11g (con Oracle RAC y Oracle Grid Infrastructure) 5.0, actualización 1 Enterprise Edition Hipervisor que aloja todas las máquinas virtuales Software de cluster y base de datos de Oracle SAP ERP 6.04 Sistema SAP ERP IDES 17

18 Infraestructura de almacenamiento de EMC Introducción Descripción general En esta sección, se describe la infraestructura de almacenamiento para la solución: Un arreglo Symmetrix VMAX 20K ofrece la plataforma de almacenamiento en el sitio A. Un arreglo Symmetrix VMAX 10K ofrece la plataforma de almacenamiento en el sitio B. Los dos arreglos de almacenamiento se implementan con una misma configuración de LUN. EMC Symmetrix VMAX 10K Symmetrix VMAX 10K es una nueva plataforma de almacenamiento empresarial especialmente diseñada para proporcionar funcionalidades líderes de almacenamiento virtual de gama alta a un número creciente de organizaciones de TI y proveedores de servicios con requisitos de almacenamiento exigentes y recursos limitados. VMAX 10K está diseñado para ofrecer facilidad de instalación, configuración y uso. Es ideal para clientes que necesitan mayor rendimiento en modo de falla y es un punto de entrada ideal para una infraestructura de almacenamiento basada en Symmetrix. Gracias a que aprovecha Virtual Matrix Architecture, VMAX 10K proporciona confiabilidad, disponibilidad y capacidad de servicio de nivel empresarial. VMAX 10K incluye una preconfiguración para permitir una configuración sencilla en el mismo día en el que se recibe el arreglo, con una instalación que tarda menos de cuatro horas. VMAX 10K es un sistema con aprovisionamiento virtual completo. Virtual Provisioning presenta a un host, a una aplicación o a un sistema de archivos más almacenamiento que el provisionado físicamente. El almacenamiento físico solo se asigna cuando se escriben los datos y no durante la configuración inicial de la aplicación. De esta manera, elimina los cálculos manuales y, además, puede reducir los costos de alimentación y enfriamiento, ya que disminuye la cantidad de capacidad de almacenamiento inactiva en el arreglo. La adición de FAST VP para brindar almacenamiento en niveles completamente automatizado permite que la instalación y el funcionamiento diario sean más sencillos para las organizaciones de TI con personal y recursos de TI limitados. Sobre la base de la integración con VMware líder del sector de EMC, VMAX 10K ahora ofrece almacenamiento empresarial aún más eficiente debido a la nueva integración con la plataforma de infraestructura de nube VMware vsphere 5. EMC Virtual Storage Integrator (VSI) para VMware simplifica el proceso de integración del almacenamiento de EMC en un ambiente virtualizado. El ambiente operativo EMC Enginuity proporciona la inteligencia que controla todos los componentes en un arreglo VMAX 10K. 18

19 Enginuity EMC Symmetrix VMAX 20K EMC Unisphere for VMAX El ambiente operativo Enginuity 5876 Q SR proporciona la inteligencia que controla todos los componentes en un arreglo de almacenamiento EMC Symmetrix. Enginuity es un ambiente operativo de almacenamiento (SOE) inteligente y preventivo que desempeña muchas tareas y controla el flujo de datos de almacenamiento. Es un ambiente completamente dedicado a operaciones de almacenamiento y optimizado para los niveles de servicio requeridos en ambientes de gama alta. Esta versión de Enginuity se centra en: Facilidad de uso, administración Multiusuario Optimización VMAX 10K VMAX 20K ofrece un equilibrio perfecto entre facilidad de uso, rendimiento, alta disponibilidad y precio para empresas más pequeñas o clientes del mediano rango superior que requieren un diseño de almacenamiento con varios controladores. VMAX 20K ofrece niveles más altos de escala, capacidad y rendimiento para clientes con requisitos más exigentes. Todos los sistemas VMAX se basan en Virtual Matrix Architecture líder del sector, ejecutan el mismo código Enginuity y comparten una sola interfaz para administración centralizada: EMC Unisphere for VMAX. Unisphere for VMAX es una GUI avanzada que ofrece una experiencia de usuario de EMC común en diferentes plataformas de almacenamiento. Unisphere for VMAX permite a los usuarios provisionar, administrar y monitorear fácilmente los ambientes VMAX, como se muestra en la Figura 9. Figura 9. Unisphere for VMAX 19

20 Configuración de VMAX Diseño de almacenamiento Para la solución, el diseño de VPLEX Metro, Oracle RAC extendido y los volúmenes de SAP se establece mediante el aprovisionamiento virtual. Esta configuración coloca los archivos de log y archivos de datos de Oracle en distintos pools delgados y permite que cada uno utilice una protección RAID distinta. Los archivos de datos residen en un pool protegido con RAID 5 y los logs de reconstitución, en un pool protegido con RAID 1. El almacenamiento no se asignó previamente a ningún dispositivo, a excepción de los dispositivos de log de reconstitución de Oracle. EMC recomienda que estos dispositivos se asignen previamente por completo en el momento de su creación, mediante una asignación persistente. Esto garantiza que su almacenamiento esté disponible desde el comienzo y, si se ejecuta una recuperación de espacio cero en el pool en cualquier etapa, su capacidad asignada previamente no se devuelve al espacio libre del pool. Figura 10 La es una representación lógica de la manera en que el diseño de almacenamiento se corresponde con los grupos de discos de ASM de Oracle. Figura 10. Grupos de almacenamiento y grupos de discos de ASM Tablas de dispositivos Tabla 6 La muestra el tamaño y el número de dispositivos configurados para cada grupo de discos de ASM. Tabla 6. Tamaños de dispositivos Grupo de almacenamiento Cantidad de dispositivos OCR 5 8 FRA 4 16 RECONSTITUCIÓ N 8 16 DATOS ACFS 4 16 Tamaño de dispositivo (GB) 20

21 Tabla 7 La muestra el tamaño y el número de dispositivos configurados para VPLEX Metro. Tabla 7. Tamaño y el número de dispositivos configurados para VPLEX Metro Dispositivo VPLEX Cantidad de dispositivos Metadatos de VPLEX 2 80 Volumen de logs de VPLEX 2 20 Tamaño de dispositivo (GB) Respaldo de metadatos de VPLEX

22 Infraestructura de EMC VPLEX Metro Introducción Descripción general En esta sección, se describe la infraestructura de VPLEX Metro para la solución, que comprende los siguientes componentes: Cluster EMC VPLEX Metro en cada centro de datos (sitio A y sitio B) EMC VPLEX Witness en un dominio de falla separado (sitio C) EMC VPLEX EMC VPLEX es una solución de virtualización de almacenamiento para arreglos de almacenamiento de EMC y de otros fabricantes. EMC ofrece tres configuraciones de VPLEX para enfrentar las necesidades que el cliente tiene en términos de alta disponibilidad y movilidad de datos, como se muestra en la Figura 11: VPLEX Local VPLEX Metro VPLEX Geo Figura 11. Topologías de VPLEX Para obtener descripciones detalladas de estas configuraciones de VPLEX, consulte los documentos enumerados en Referencias, en la página 74. EMC VPLEX Metro Esta solución utiliza VPLEX Metro, el cual emplea una arquitectura de agrupación en clusters exclusiva que ayuda a los clientes a traspasar los límites del centro de datos y permite a los servidores de múltiples centros de datos tener acceso de lectura/escritura a los dispositivos compartidos de almacenamiento de bloques. VPLEX Metro ofrece acceso a nivel del bloque activo/activo a los datos en dos sitios dentro a distancias síncronas con un ciclo de ida y vuelta de hasta 5 ms. EMC VPLEX Witness VPLEX Witness es un servidor externo opcional que se instala como una máquina virtual en un dominio de falla separado de los clusters VPLEX. VPLEX Witness se conecta con los dos clusters VPLEX mediante una red privada virtual (VPN) por medio de la red IP de administración; requiere un ciclo de ida y vuelta que no sea superior a 1 segundo. Mediante la reconciliación de sus propias observaciones con la información brindada periódicamente por los clusters, VPLEX Witness permite que los clusters distingan entre fallas de partición de red entre clusters y fallas de cluster, y que reanuden las operaciones de I/O automáticamente en el sitio adecuado. 22

23 La semántica de manejo de fallas de VPLEX Witness se aplica solo a los volúmenes distribuidos dentro de un grupo de consistencia y solo cuando las reglas de desconexión identifican un cluster preferido estático para el grupo de consistencia (consulte Grupos de consistencia de VPLEX en la página 24 para obtener más información). EMC Unisphere for VPLEX Puede administrar un ambiente VPLEX con la GUI web de Unisphere for VPLEX (como se muestra en la Figura 12) o puede establecer conexión directamente con un servidor de administración e iniciar una sesión de VPlexcli (interfaz de la línea de comandos de VPLEX). Figura 12. EMC Unisphere for VPLEX Alta disponibilidad de EMC VPLEX VPLEX Metro permite la movilidad de datos y aplicaciones y, cuando se configura con VPLEX Witness, ofrece una infraestructura de alta disponibilidad para aplicaciones agrupadas en clusters, como Oracle RAC. VPLEX Metro le permite crear un cluster ampliado o de expansión como si fuera un cluster local y elimina al centro de datos como punto único de falla. Además, dado que los datos y las aplicaciones están activos en los dos sitios, la solución ofrece una estrategia de continuidad del negocio simple. Mediante una configuración de conexión entre clusters VPLEX, puede lograr un nivel aún más alto de disponibilidad. En este caso, cada host está conectado con los clusters VPLEX en los dos sitios. Esto garantiza que, en el caso poco probable de que se produzca una falla de todo el cluster VPLEX, el host tenga una ruta alternativa al cluster VPLEX restante. 23

24 Estructuras lógicas de almacenamiento de VPLEX VPLEX encapsula los dispositivos de arreglos de almacenamiento físicos tradicionales y aplica capas de abstracción lógica a estos LUN exportados, como se muestra en la Figura 13. Volúmenes virtuales Dispositivo Dispositivo Extensión Volumen de almacenamiento Figura 13. Estructuras lógicas de almacenamiento de VPLEX Un volumen de almacenamiento es un LUN exportado de un arreglo y encapsulado por VPLEX. Una extensión es el mecanismo que utiliza VPLEX para dividir los volúmenes de almacenamiento y puede usar toda la capacidad del volumen de almacenamiento subyacente o parte de ella. Un dispositivo encapsula una extensión o combina varias extensiones u otros dispositivos en un dispositivo grande con un tipo de RAID específico. Un dispositivo distribuido es un dispositivo que encapsula otros dispositivos de dos clusters VPLEX distintos. En la capa superior de las estructuras de almacenamiento de VPLEX se encuentran los volúmenes virtuales. Estos se crean a partir de un dispositivo de nivel superior (un dispositivo o dispositivo distribuido) y siempre utilizan la capacidad completa del dispositivo de nivel superior. Los volúmenes virtuales son los elementos que VPLEX presenta a los hosts mediante sus puertos de frontend. VPLEX presenta un volumen virtual a un host mediante una vista de almacenamiento. VPLEX puede encapsular dispositivos de diferentes arreglos de almacenamiento heterogéneos, incluidos los dispositivos con aprovisionamiento delgado virtual y los LUN tradicionales. Grupos de consistencia de VPLEX Los grupos de consistencia incorporan volúmenes virtuales juntos, de manera que se puedan aplicar las mismas reglas de desconexión y otras propiedades a todos los volúmenes del grupo. Hay dos tipos de grupos de consistencia: Grupos de consistencia síncronos: Se utilizan en VPLEX Local y VPLEX Metro para aplicar las mismas reglas de desconexión y otras propiedades a un grupo de volúmenes en una configuración. Esto simplifica la configuración y la administración en sistemas grandes. Los grupos de consistencia síncronos utilizan almacenamiento en caché de escritura inmediata (conocida como modo de caché síncrono) y, con VPLEX Metro, se admiten en clusters separados con hasta 5 ms de 24

25 latencia. VPLEX Metro envía escrituras a los volúmenes de almacenamiento de back-end y reconoce una escritura en la aplicación solo cuando los volúmenes de almacenamiento de back-end en ambos clusters reconocen la escritura. Grupos de consistencia asíncronos: Se utilizan para volúmenes distribuidos en VPLEX Geo, donde los clusters pueden estar separados por hasta 50 ms de latencia. Reglas de desconexión Las reglas de desconexión son reglas predefinidas que determinan la semántica de procesamiento de I/O para un grupo de consistencia cuando se pierde la conectividad con un cluster remoto, por ejemplo, en caso de que se produzca una falla de particionamiento de red o de cluster remoto. Los grupos de consistencia síncronos son compatibles con las siguientes reglas de desconexión para determinar el comportamiento del cluster durante una falla: La regla de preferencia estática identifica un cluster preferido La regla de ganador no automático suspende el I/O en los dos clusters Cuando se pierde conectividad entre los clusters, se invoca la regla configurada de desconexión de manera automática. Sin embargo, se puede implementar VPLEX Witness a fin de omitir la regla de preferencia estática y garantizar que el cluster no preferido continúe activo si se produce una falla en le cluster preferido. Movilidad de datos de VPLEX Descripción general La función de movilidad de datos de VPLEX permite migrar elementos de almacenamiento (extensiones o dispositivos) dentro de los clusters o entre ellos de manera no disruptiva. La movilidad de datos ofrece los siguientes beneficios: Consolidación de centros de datos Migración rápida de datos entre centros de datos Transferencia y reubicación de aplicaciones y datos a distancia Migración de datos entre arreglos diferentes para: Reubicar un dispositivo activo de almacenamiento más lento a almacenamiento más rápido Reubicar un dispositivo inactivo de almacenamiento más rápido a almacenamiento más lento Retirar un arreglo o volumen de almacenamiento 25

26 Migraciones de extensiones Las migraciones de extensiones se utilizan para transferir datos entre extensiones del mismo cluster. Los volúmenes de almacenamiento se pueden ubicar en el mismo arreglo o en arreglos diferentes. Figura 14 La ilustra la migración de extensiones. Figura 14. Migración de extensiones en un cluster VPLEX Migraciones de dispositivos Los dispositivos no distribuidos de tipo RAID 0, RAID 1 o RAID C pueden utilizar la migración de dispositivos para transferir datos entre dispositivos en el mismo cluster o en clusters diferentes. Los dispositivos se pueden basar en uno o varios dispositivos o extensiones. Figura 15 La ilustra la migración de dispositivos. Figura 15. Migración de un dispositivo dentro de clusters VPLEX o entre ellos Esta solución utiliza dispositivos distribuidos. Para este tipo de dispositivo, las migraciones de extensiones se utilizan para migrar la extensión subyacente en cada tramo del dispositivo. No se admiten migraciones de dispositivos entre dispositivos distribuidos. 26

27 Configuración de la movilidad de datos Los requisitos previos para la extensión o el dispositivo de destino son los siguientes: El destino debe tener un tamaño igual o mayor que el dispositivo o la extensión de origen. Si el destino es mayor que el origen, no se puede utilizar el espacio adicional. No debe existir ningún volumen en el destino. Los trabajos de movilidad de extensiones y dispositivos se pueden crear, ejecutar y monitorear desde: CLI de VPLEX: Las migraciones se pueden ejecutar como trabajos de una sola vez o como trabajos en lotes con archivos de plan de migración reutilizables. Para obtener más información, consulte EMC VPLEX CLI Guide. GUI de Unisphere for VPLEX: La GUI no es compatible con los trabajos de movilidad en lotes. Sin embargo, se pueden migrar varios dispositivos/extensiones mediante un asistente. En un cluster VPLEX, puede haber hasta 25 migraciones locales y 25 migraciones distribuidas en curso simultáneamente. Las migraciones que superen dichos límites se colocan en la línea de espera hasta que se complete una migración existente. Figura 16 La muestra la creación de varios trabajos de movilidad de extensiones con el asistente para movilidad de extensiones de Unisphere for VPLEX. También muestra los trabajos en ejecución y su estado. Figura 16. Creación y monitoreo de trabajos de movilidad de extensiones 27

28 Movilidad de datos en esta solución Esta solución utiliza una infraestructura de VPLEX Metro existente. Como parte de una actualización tecnológica, los arreglos de almacenamiento de back-end se reemplazaron con arreglos VMAX. Se utilizaron trabajos de movilidad de datos de VPLEX para la migración de datos no disruptiva de los arreglos originales a los arreglos nuevos. Los sistemas (en este caso, las máquinas virtuales y ESXi Server) se encendieron y estuvieron disponibles durante toda la migración, como se muestra en la Figura 17. Figura 17. ESXi Server, máquinas virtuales y áreas de almacenamiento de datos disponibles durante la migración Configuración de la solución de VPLEX Metro Estructuras de almacenamiento Figura 18 La muestra la estructura del almacenamiento lógico y físico que utiliza VPLEX Metro en el contexto de esta solución. Existe un mapeo uno a uno entre los dispositivos, las extensiones y los volúmenes de almacenamiento en cada sitio. Todos los dispositivos del cluster 1 se espejean remotamente en el cluster 2, en una configuración distribuida de RAID 1, para crear dispositivos distribuidos. Estos dispositivos distribuidos son encapsulados por volúmenes virtuales, que luego se presentan a los hosts mediante vistas de almacenamiento. 28

29 Figura 18. Estructuras del almacenamiento lógico y físico de VPLEX para la solución Grupos de consistencia Los grupos de consistencia tienen especial importancia para las bases de datos y sus aplicaciones. Por ejemplo: Fidelidad del orden de escritura: Para mantener la integridad de los datos, todos los LUN de bases de datos de Oracle (por ejemplo, archivos de log, datos y control) se deben colocar juntos en un solo grupo de consistencia. Dependencia de transacciones: Con frecuencia, varias bases de datos tienen dependencias de transacciones, por ejemplo, cuando una aplicación ejecuta transacciones en varias bases de datos y espera que las bases de datos sean consistentes entre sí. Todos los LUN que requieran conservar la dependencia de I/O deben residir en un solo grupo de consistencia. Dependencia de aplicaciones: Oracle RAC mantiene los archivos de Oracle Cluster Registry (OCR) y los voting disks dentro de un conjunto de discos que deben ser accesibles para mantener la disponibilidad de la base de datos. Los discos de OCR y la base de datos deben residir en un solo grupo de consistencia. Para la solución, un solo grupo de consistencia síncrono (Extended_Oracle_RAC_CG) contiene todos los volúmenes virtuales que contienen los binarios de la base de datos Oracle 11g, los grupos de discos Oracle ASM, los archivos de OCR y los voting disks. La regla de desconexión para el grupo de consistencia tiene el cluster 1 como el cluster preferido. 29

30 Proceso de configuración Para la solución, las estructuras lógicas de almacenamiento de VPLEX Metro se configuraron de la siguiente manera (de la Figura 19 a la Figura 23, se muestran secciones de los asistentes de configuración que proporciona VPLEX Management Console): Volumen de almacenamiento: Un volumen de almacenamiento es un LUN exportado de un arreglo y encapsulado por VPLEX. Figura 19 La muestra varios volúmenes de almacenamiento creados en el sitio A, como se muestra en VPLEX Management Console. Figura 19. Volúmenes de almacenamiento de EMC VPLEX (sitio A) Extensión: En la solución, hay un mapeo uno a uno entre los volúmenes de almacenamiento y las extensiones, como se muestra en la Figura 19 y la Figura 20. Figura 20. Asistente para la creación de extensiones de EMC VPLEX Dispositivo: En la solución, hay un mapeo uno a uno entre los dispositivos y las extensiones. Figura 21 La muestra la opción utilizada para configurar este mapeo uno a uno. Figura 21. Asistente para la creación de dispositivos de EMC VPLEX Dispositivo distribuido: En la solución, los dispositivos distribuidos se crearon espejeando un dispositivo remotamente en una configuración distribuida de RAID 1, como se muestra en la Figura

31 Figura 22. Asistente para la creación de dispositivos de EMC VPLEX Volumen virtual: En la solución, todos los dispositivos de nivel superior son dispositivos distribuidos. Estos dispositivos son encapsulados por volúmenes virtuales, que VPLEX presenta a los hosts mediante vistas de almacenamiento. Las vistas de almacenamiento definen qué hosts pueden acceder a qué volúmenes virtuales en qué puertos de VPLEX. Grupo de consistencia: La Figura 23 muestra el grupo de consistencia creado para la solución: Extended_Oracle_RAC_CG. Figura 23. Asistente para la creación de grupo de consistencia de EMC VPLEX Configuración de VPLEX Witness La solución utiliza VPLEX Witness para monitorear la conectividad entre los dos clusters VPLEX y garantizar la disponibilidad continua en caso de que se produzca una falla en una partición de red entre clusters o una falla en un cluster. Esto se considera una configuración VPLEX Metro HA, dado que se garantiza la disponibilidad de almacenamiento en el sitio no afectado. VPLEX Witness se implementa en un tercer dominio de falla separado (sitio C) y se conecta a los clusters VPLEX en el sitio A y el sitio B. El sitio C se ubica a una distancia de menos de 1 segundo de latencia de los sitios A y B. Cuando se ha instalado y configurado VPLEX Witness, VPLEX Management Console muestra el estado de los componentes del cluster Witness, como se muestra en la Figura

32 Figura 24. Componentes y estado de EMC VPLEX Witness Monitoreo del rendimiento de VPLEX VPLEX 5.1 ofrece monitoreo mejorado del rendimiento mediante el tablero de monitoreo del rendimiento. Este tablero ofrece una vista personalizable del rendimiento del sistema VPLEX y le permite ver y comparar diversos aspectos del rendimiento del sistema, hasta el nivel de director. En la actualidad, hay muchas métricas diferentes disponibles, entre ellas: Cuadro de latencia de front-end Cuadro de ancho de banda de front-end Cuadro de rendimiento de front-end Cuadro de utilización de CPU Cuadro de estado de reconstrucción Cuadro de rendimiento de enlace WAN Cuadro de latencia de back-end Figura 25 La muestra el rendimiento de CPU y de front-end en el cluster 1 (VPLEX del sitio A) cuando se recopilaron estadísticas de Oracle en la base de datos SAP VSE. Figura 25. Tablero de monitoreo del rendimiento de VPLEX 32

33 Infraestructura virtualizada de VMware Introducción Descripción general Para la solución, los servidores de aplicaciones de SAP se virtualizaron por completo mediante VMware vsphere 5. En esta sección, se describe la infraestructura de virtualización, que utiliza los siguientes componentes y opciones: VMware vsphere 5.0, actualización 1 VMware vcenter TM Server VMware vsphere vmotion VMware vsphere High Availability (HA) VMware vsphere Distributed Resource Scheduler TM (DRS) EMC PowerPath /VE for VMware vsphere versión 5.7 EMC Virtual Storage Integrator for VMware vsphere versión 5.1 VMware vsphere 5 VMware vsphere 5 es la plataforma de virtualización más completa, escalable y sólida del sector, con servicios de infraestructura que transforman el hardware de TI en una plataforma de cómputo compartida de alto rendimiento, y servicios de aplicaciones que permiten que las organizaciones de TI proporcionen los niveles más altos de disponibilidad, seguridad y escalabilidad. VMware vcenter Server VMware vcenter es la plataforma de administración centralizada para ambientes vsphere. Brinda control y visibilidad en cada uno de los niveles de la infraestructura virtual. VMware vsphere vmotion VMware vsphere vmotion es la tecnología de VMware compatible con la migración activa de máquinas virtuales entre servidores sin interrupción para los usuarios ni pérdida de servicio. Storage vmotion es la tecnología de VMware que permite la migración activa del almacenamiento de una máquina virtual sin interrupción de la disponibilidad de la máquina virtual. Esto permite la reubicación de máquinas virtuales activas en nuevas áreas de almacenamiento de datos. VMware vsphere High Availability VMware vsphere High Availability (HA) es un componente de vsphere que proporciona alta disponibilidad para cualquier aplicación que se ejecute en una máquina virtual, independientemente de su sistema operativo o de su configuración de hardware subyacente. VMware vsphere Distributed Resource Scheduler VMware vsphere Distributed Resource Scheduler (DRS) balancea, de manera dinámica y automática, la distribución de la carga y la colocación de máquinas virtuales entre varios servidores ESXi Server. 33

34 EMC PowerPath/VE EMC PowerPath/VE for VMware vsphere ofrece funciones de múltiples rutas de PowerPath para optimizar los ambientes virtuales VMware vsphere. PowerPath/VE se instala como un módulo de kernel en el host ESXi y funciona como un plug-in de múltiples rutas (MPP) que proporciona funcionalidades mejoradas de administración de rutas a los hosts ESXi. EMC Virtual Storage Integrator for VMware vsphere EMC Virtual Storage Integrator (VSI) for VMware vsphere es un plug-in para VMware vsphere Client que proporciona una interfaz única para administrar el almacenamiento de EMC dentro del ambiente vsphere. VSI proporciona una experiencia de usuario unificada y flexible que permite actualizar cada función de manera independiente y agregar nuevas funciones con rapidez, a fin de estar siempre preparados ante los cambios de los requisitos de los clientes. Cuando se instala PowerPath/VE en un host ESXi, VSI presenta detalles importantes sobre la funcionalidad de múltiples rutas para los dispositivos, por ejemplo, la política de balanceo de carga, el número de rutas activas y el número de rutas inactivas. Implementaciones de VMware en VPLEX Metro EMC VPLEX Metro ofrece acceso simultáneo al mismo conjunto de dispositivos en dos ubicaciones físicamente separadas, lo que proporciona la infraestructura activo/activo que permite clusters geográficamente distantes basados en VMware vsphere. El uso de la tecnología de grupo de agregación de enlaces virtual (vlag) de Brocade permite la extensión de redes VLAN (y, por ende, subredes) en diferentes centros de datos físicos. Al implementar las funciones y los componentes de VMware vsphere junto con VPLEX Metro, se pueden obtener las siguientes funcionalidades: vmotion: La capacidad de migrar máquinas virtuales en ejecución entre sitios a fin de anticipar eventos planificados, como tareas de mantenimiento de hardware. Storage vmotion: La capacidad de migrar el almacenamiento de una máquina virtual sin interrupción en la disponibilidad de la máquina virtual. Esto permite la reubicación de máquinas virtuales activas en nuevas áreas de almacenamiento de datos. VMware DRS: Funciones automáticas de distribución de la carga y colocación de máquinas virtuales entre sitios mediante reglas de afinidad y grupos de DRS. VMware HA: Un ambiente VPLEX Metro configurado con VPLEX Witness se considera una configuración VPLEX Metro HA, dado que garantiza la disponibilidad del almacenamiento en el sitio no afectado en caso de que ocurra una falla a nivel de sitio. La combinación de VPLEX Metro HA con una tecnología de agrupación en clusters de failover de host como VMware HA ofrece el reinicio automático de las aplicaciones para cualquier desastre a nivel de sitio. Figura 26 La ilustra esta arquitectura de HA. 34

35 Figura 26. VMware HA con VPLEX Witness: vista lógica Conexión entre clusters de VPLEX Metro HA: Se puede aumentar aún más la protección del cluster VMware HA agregando una conexión entre clusters entre los servidores locales VMware ESXi Server y el cluster VPLEX del sitio remoto. Pueden ocurrir eventos de falta de disponibilidad de datos locales, que VMware vsphere 5.0 no reconoce, cuando no se produce una interrupción de todo el sitio. La interconexión de ambientes vsphere con clusters VPLEX brinda protección contra estos eventos y garantiza que las máquinas virtuales con errores se transfieran automáticamente al sitio no afectado. La conexión entre clusters de VPLEX está disponible para hasta 1 ms de latencia inducida por la distancia. Esta solución utiliza VPLEX Metro HA con conexión entre clusters para maximizar la disponibilidad de las máquinas virtuales VMware, como se muestra en la Figura Para obtener información detallada, consulte EMC TechBook: EMC VPLEX Metro Witness Technology and High Availability. 35

36 Figura 27. VMware HA con VPLEX Witness y conexión entre clusters: vista lógica Configuración de cluster extendido de VMware VMware y EMC ofrecen compatibilidad con una configuración de cluster extendido que incluye hosts ESXi de varios sitios 2. Para la solución, un solo cluster vsphere se extiende entre el sitio A y el sitio B usando un volumen virtual de VPLEX distribuido con VMware HA y VMware DRS. Hay cuatro hosts en el cluster, dos en cada sitio. La conexión entre clusters de VPLEX Metro HA ofrece mayor resistencia a la configuración. En vcenter, es sencillo visualizar la configuración de este cluster (SiteAandSiteB) y las funciones activadas para él, como se muestra en la Figura 28. Esta vista también muestra los recursos de memoria, CPU y almacenamiento disponibles para el cluster. Figura 28. Cluster vsphere con HA y DRS activados 2 Para obtener información detallada sobre los requisitos y escenarios, consulte el artículo de Knowledgebase de VMware : Using VPLEX Metro with VMware HA 36

37 Cada ESXi Server se configura con dos adaptadores físicos de 10 GbE para ofrecer failover de red y alto rendimiento. Un switch distribuido de vsphere (dvswitch) 3 proporciona un solo switch común para todos los hosts. Los adaptadores físicos de 10 GbE (también conocidos como adaptadores de enlace de subida) se asignan al dvswitch. Dos grupos de puertos distribuidos se asignan al dvswitch: dvportgroupsiteab: para el tráfico de red de las máquinas virtuales. Management Network: para el tráfico de VMkernel y, en particular, para el tráfico de vmotion. Figura 29 La muestra la configuración del dvswitch. Dado que tanto los switches distribuidos de vsphere 5.0 como los switches Brocade VCS son compatibles con Link Layer Discovery Protocol (LLDP), las propiedades de los switches físicos asociados se pueden identificar fácilmente desde vcenter. Figura 29. Configuración del dvswitch y detalles de LLDP El área de almacenamiento de datos EXT_SAP_VPLEX_DS01 se creó en un volumen distribuido de VPLEX de 1 TB y se presentó a los hosts ESXi en el cluster extendido. Todas las máquinas virtuales se migraron a esta área de almacenamiento de datos, mediante Storage vmotion, porque necesitan compartir los discos virtuales o tener la capacidad de realizar vmotion entre sitios. Figura 30 La muestra los detalles de configuración para el área de almacenamiento de datos. 3 Un dvswitch proporciona una configuración de red que abarca todos los hosts miembros y permite que las máquinas virtuales mantengan una configuración de red consistente a medida que migran entre los hosts. Para obtener más información, consulte el documento VMware vsphere Networking ESXi

38 Figura 30. Área de almacenamiento de datos EXT_SAP_VPLEX_DS01 y máquinas virtuales y hosts asociados Configuración de VMware vsphere HA Activación de VMware vsphere HA y VMware vsphere DRS vsphere HA aprovecha varios hosts ESXi, configurados como un cluster, para proporcionar recuperación rápida de interrupciones y alta disponibilidad rentable para las aplicaciones que se ejecutan en máquinas virtuales. 4 vsphere HA protege la disponibilidad de las aplicaciones de las maneras siguientes: Brinda protección contra una falla del servidor mediante el reinicio de las máquinas virtuales en otros servidores ESXi Server dentro del cluster. Brinda protección contra fallas de aplicaciones mediante el monitoreo continuo de una máquina virtual y su restablecimiento en el caso de que ocurra una falla en el SO huésped. Para la solución, se activaron tanto vsphere HA como DRS, como se muestra en la Figura 31. Figura 31. Asistente de vsphere HA 4 Para obtener más información acerca de vsphere HA, consulte el documento VMware vsphere Availability ESXi

39 Monitoreo de VM El monitoreo de VM se configuró para reiniciar máquinas virtuales individuales si su latido no se recibía en un lapso de 60 segundos. Opciones de reinicio de máquinas virtuales La opción de prioridad de reinicio de máquina virtual para las cuatro máquinas virtuales de SAP se configuró en el nivel alto. Esto garantiza que las máquinas virtuales se enciendan primero en caso de que ocurra una interrupción. La Figura 32 muestra esta configuración y la configuración de respuesta de aislamiento de host (valor predeterminado). Figura 32. Configuración de prioridad de reinicio de máquina virtual y respuesta de aislamiento de host Latidos del área de almacenamiento de datos Cuando se crea un cluster vsphere HA, se selecciona automáticamente un solo host como el host maestro. El host maestro monitorea el estado de todas las máquinas virtuales protegidas y de los hosts esclavos. Cuando el host maestro no se puede comunicar con un host esclavo, utiliza los latidos del área de almacenamiento de datos para determinar si el host esclavo ha fallado, si se encuentra en una partición de red o si está aislado de la red. Para cumplir con los requisitos de vsphere HA para los latidos del área de almacenamiento de datos, una segunda área de almacenamiento de datos, EXT_SAP_VPLEX_HA_HB, se creó en un volumen distribuido de VPLEX de 20 GB y se presentó a todos los hosts ESXi, como se muestra en la Figura 33. En un ambiente de producción, vcenter selecciona automáticamente dos o más áreas de almacenamiento de datos para este fin, en función de la visibilidad del host. Figura 33. Estado del cluster vsphere HA: áreas de almacenamiento de datos de latidos 39

40 Configuración de VMware vsphere DRS Grupos de hosts y grupos de máquinas virtuales de VMware DRS Los grupos de hosts y los grupos de máquinas virtuales de DRS simplifican la administración de los recursos de hosts ESXi. Estas funciones no se necesitaron para esta solución. Reglas de afinidad de VMware DRS DRS utiliza reglas de afinidad para controlar la colocación de máquinas virtuales en los hosts dentro de un cluster. DRS proporciona dos tipos de reglas de afinidad: Una regla de afinidad entre máquina virtual y host especifica una relación de afinidad entre un grupo de máquinas virtuales y un grupo de hosts. Una regla de afinidad entre máquinas virtuales especifica si determinadas máquinas virtuales deben ejecutarse en el mismo host o mantenerse en hosts distintos. Tabla 8 La y la Figura 34 muestran la regla de afinidad entre máquinas virtuales que utiliza la solución. Tabla 8. Regla de afinidad de VMware DRS Regla de afinidad entre máquinas virtuales SAPASCS Separate Mantiene las máquinas virtuales SAPASCS2 y SAPASCS3 en hosts separados. Figura 34. Regla de afinidad ente máquinas virtuales de DRS para el cluster vplex_esxi_metro_ha EMC Virtual Storage Integrator y VPLEX EMC Virtual Storage Integrator (VSI) brinda visibilidad mejorada de VPLEX directamente desde la GUI de vcenter. Las funciones Storage Viewer y Path Management son accesibles por medio de la pestaña EMC VSI, como se muestra en la Figura 35. En la solución, los volúmenes distribuidos de VPLEX se alojan en el área de almacenamiento de datos Virtual Machine File System (VMFS) EXT_SAP_VPLEX_DS01, y Storage Viewer proporciona detalles de los volúmenes virtuales, volúmenes de almacenamiento y rutas del área de almacenamiento de datos. Como se muestra en la Figura 35, los LUN que componen el área de almacenamiento de datos son cuatro volúmenes distribuidos de VPLEX Metro con RAID 1 y 256 GB accesibles mediante PowerPath. 40

41 Figura 35. VSI Storage Viewer: áreas de almacenamiento de datos 41

42 Arquitectura del sistema SAP Introducción Descripción general En esta sección, se describe la arquitectura del sistema SAP implementada para la solución en los dos centros de datos. La capa de aplicaciones de SAP utiliza los siguientes componentes de SAP y SUSE: Aplicación SAP SAP Enhancement Package 4 para SAP ERP 6.0 IDES SAP NetWeaver Application Server 7.01 para ABAP Servidor de replicación de línea de espera de SAP Sistema operativo SUSE Linux Enterprise Server for SAP Applications 11 SP1 SUSE Linux Enterprise High Availability Extension El sistema SAP se ejecuta en un ambiente híbrido, con los servicios de SAP en máquinas virtuales y la base de datos en servidores físicos. Todas las instancias de SAP se instalan en máquinas virtuales VMware vsphere con SUSE Linux Enterprise Server for SAP Applications como sistema operativo. La base de datos subyacente es una base de datos física Oracle RAC en ASM. Los ambientes VMware y Oracle se describen en secciones separadas del informe técnico (consulte Infraestructura virtualizada de VMware y Arquitectura de base de datos). SAP ERP 6.0 SAP ERP 6.0, que cuenta con la plataforma de tecnología SAP NetWeaver, es una aplicación de planificación de recursos empresariales (ERP) completamente integrada de nivel internacional que satisface las necesidades principales del negocio de medianas y grandes empresas en todos los sectores industriales y segmentos del mercado. SAP ERP 6.0 ofrece un conjunto integral de procesos de negocios interfuncionales e integrados y puede servir como una plataforma de procesos de negocios sólida compatible con el crecimiento continuo, la innovación y la excelencia operacional. SAP IDES (sistema de demostración y evaluación por Internet) es compatible con demostraciones, pruebas y evaluaciones funcionales basadas en clientes y datos preconfigurados. IDES contiene datos de aplicaciones para varios escenarios de negocios, con procesos de negocios diseñados para reflejar requisitos de negocios reales y tener acceso a varias características realistas. Esta solución utiliza IDES para representar una empresa modelo con fines de prueba. SUSE Linux Enterprise Server for SAP Applications SUSE Linux Enterprise Server es un sistema operativo de servidor altamente confiable, escalable y seguro, diseñado para ejecutar aplicaciones físicas, virtuales y de nube. Es una plataforma Linux recomendada para SAP. SUSE Linux Enterprise Server for SAP Applications, basado en la más reciente tecnología de SUSE Linux Enterprise Server, está optimizado para todos los dispositivos y las soluciones de software SAP NetWeaver de misión crítica. SAP y SUSE validan y certifican SUSE Linux Enterprise Server for SAP Applications en conjunto para eliminar posibles incompatibilidades de software. Esta asociación integra estrechamente el tipo de carga de las aplicaciones con el sistema 42

43 operativo y elimina la posibilidad de incompatibilidades cuando se aplican parches a las aplicaciones o al sistema operativo. SUSE Linux Enterprise High Availability Extension SUSE Linux Enterprise Server for SAP Applications incluye SUSE Linux Enterprise High Availability Extension, que ofrece agrupación en clusters de aplicaciones y servicios de alta disponibilidad, sistemas de archivos y sistemas de archivos en clusters, almacenamiento conectado en red (NAS), Network File System, administradores de volúmenes, SAN y controladores, y los medios para administrar todos estos componentes que funcionan en conjunto. SUSE Linux Enterprise High Availability Extension ofrece una solución de agrupación en clusters integrada para implementaciones Linux físicas y virtuales, lo cual permite la implementación de clusters Linux con alta disponibilidad y la eliminación de puntos únicos de falla. Configuración del sistema SAP Arquitectura del sistema SAP La solución implementa una arquitectura de sistema SAP de alta disponibilidad, como se muestra en la Figura 36. Figura 36. Arquitectura del sistema SAP 43

44 El servidor de línea de espera y el servidor de mensajes se desacoplan de la instancia central y se implementan como servicios dentro de la instancia de ASCS 5. SAP ERS se instala como parte de la arquitectura de alta disponibilidad para eliminar la pérdida de bloqueo de aplicaciones y proteger aún más el servidor de línea de espera 6. Se instalan dos instancias de diálogo para ofrecer procesos de trabajo redundantes, por ejemplo, diálogo (DIA), segundo plano (BGD), actualización (UPD), spool (SPO) y gateway. Consideraciones clave sobre el diseño El sistema SAP implementado para la solución cuenta con las siguientes características clave de diseño: La instancia de ASCS se instala con un nombre de host virtual (SAPVIPE), para desacoplarlo del nombre de host de la máquina virtual. La instancia de ERS se instala con otro número de instancia (01), para evitar futuras confusiones cuando ASCS y ERS se encuentran bajo el control del cluster. Todos los parches, los parámetros, la configuración básica y la configuración de balanceo de carga de SAP se instalan y configuran según la guía de instalación de SAP y las notas de SAP mencionadas en la página 74. En esta solución, se adoptan las mejores prácticas de VMware para SAP 7. Los procesos de actualización de SAP (UPD/UP2) se configuran en las instancias adicionales de servidor de aplicaciones. El perfil de la instancia de SAP ASCS, los perfiles de inicio y de la instancia de ERS, y los perfiles de instancias de diálogo se actualizan con las configuraciones de ERS. Consulte Apéndice: Configuraciones de ejemplo para conocer configuraciones de ejemplo. Los sistemas de archivos compartidos de SAP, incluidos /sapmnt/<sid> (disponible para todas las instancias de SAP) y /usr/sap/<sid>/ascs00 (disponible para los nodos de cluster de SAP, la instancia de ASCS y la instancia de ERS), se almacenan en el sistema de archivos en cluster de ASM (ACFS) de Oracle y se montan como recursos compartidos de Network File System (NFS) en las máquinas virtuales de SAP. Estos sistemas de archivos compartidos se presentan como un recurso NFS con alta disponibilidad que es administrado por Oracle Clusterware. 5 El servidor de línea de espera administra los bloqueos lógicos y tiene el fin de minimizar la duración de un bloqueo de base de datos. A diferencia de los bloqueos de base de datos, un bloqueo de SAP puede existir en diversos LUW de bases de datos. El servidor de mensajes informa a todos los servidores (instancias) de un sistema SAP sobre la existencia de los demás servidores. Otros clientes (por ejemplo, clientes SAPlogon y RFC con balanceo de carga) también pueden comunicarse con él para obtener información acerca del balanceo de carga. 6 SAP ERS proporciona un mecanismo de replicación para el servidor de línea de espera mediante la conservación de una copia de la tabla de bloqueos dentro de su segmento de memoria compartida. La instalación de ERS para Linux no forma parte del proceso SAPInst estándar. Para obtener instrucciones de instalación, consulte el portal de ayuda sobre el servidor de replicación de línea de espera de SAP en help.sap.com. 7 Para obtener información detallada, consulte: SAP Solutions on VMware: Best Practices Guide. 44

45 Algunas funcionalidades de IDES, por ejemplo, la sincronización con el sistema GTS externo, están desactivadas a fin de eliminar interfaces externas innecesarias que están fuera del alcance de la solución. El almacenamiento para todo el ambiente SAP está encapsulado y virtualizado para esta solución. El almacenamiento se distribuye entre los dos sitios y está disponible para los servidores de SAP mediante VPLEX Metro. Configuración de SUSE Linux Enterprise High Availability Extension Arquitectura de máquinas virtuales de SAP con SUSE Linux Enterprise High Availability Extension La solución utiliza SUSE Linux Enterprise High Availability Extension para proteger los servicios centrales (servidor de mensajes y servidor de línea de espera) en dos nodos de cluster basados en máquinas virtuales de VMware. VMware High Availability (VMware HA) protege todas las máquinas virtuales de SAP, entre ellas, ASCS y el servidor de aplicaciones adicional (AAS). La Figura 37 muestra esta arquitectura. Figura 37. Arquitectura de cluster de SAP ASCS con SUSE Linux Enterprise HAE Los componentes clave de SUSE Linux Enterprise High Availability Extension implementados en esta solución incluyen: OpenAIS 8 /Corosync 9, un administrador de clusters de alta disponibilidad que es compatible con el failover de múltiples nodos. 8 OpenAIS es una implementación abierta de la interfaz específica de aplicaciones (AIS) que proporciona Service Availability Forum (SA Forum). 9 Corosync Cluster Engine es un sistema de comunicación de grupos con funciones adicionales para implementar la alta disponibilidad dentro de las aplicaciones. 45

46 Agentes de recursos (dirección IP virtual, maestro/esclavo y SAPInstance) para monitorear y controlar la disponibilidad de los recursos. GUI de alta disponibilidad y diferentes herramientas de línea de comandos. Tabla 9 La muestra la configuración de las máquinas virtuales de SAP. Tabla 9. Máquinas virtuales de SAP Función de VM Cantidad CPU virtuales Memoria (GB) Disco de inicio de SO (GB) Nombre de VM SAP ASCS SAPASCS2 SAP ERS SAPASCS3 SAP AAS SAPDI SAPDI2 Proceso de instalación y configuración El informe técnico Running SAP NetWeaver on SUSE Linux Enterprise Server with High Availability Simple Stack de SUSE describe cómo instalar y configurar el software SUSE y SAP NetWeaver. Apéndice: Configuraciones de ejemplo El proporciona un archivo de configuración de ejemplo que es compatible con las características y funciones validadas por esta solución. Los valores de tiempo (tiempo de espera agotado, intervalos, etc.) se deben considerar valores iniciales para ajustar y optimizar según el ambiente particular. Para la solución, SUSE Linux Enterprise High Availability Extension se instaló y configuró mediante la GUI de Pacemaker y YaST. A continuación, se incluye un resumen del proceso de instalación y configuración: 1. Configure un servidor SMT interno (con fines de seguridad) para actualizar todos los paquetes de software con las versiones más recientes. 2. En el módulo YaST Software Management, seleccione Patterns > High Availability para instalar High Availability Extension, como se muestra en la Figura

47 Figura 38. Instalación de SUSE Linux Enterprise High Availability Extension 3. En el módulo YaST Cluster, configure los parámetros básicos del cluster, como se muestra en la Figura 39. Figura 39. Configuración de los parámetros básicos del cluster 47

48 4. En la GUI de Pacemaker, configure los parámetros globales del cluster, como se muestra en la Figura 40. Figura 40. Configuración de los parámetros globales del cluster 5. En la GUI de Pacemaker, abra la categoría Resources y configure los recursos IPaddr2, maestro/esclavo y SAPInstance, como se muestra en la Figura 41. Figura 41. Configuración de recursos 48

49 6. En la GUI de Pacemaker, configure las dependencias de los recursos, como se muestra en la Figura 42. Figura 42. Configuración de dependencias de recursos 7. En la GUI de Pacemaker, inicie el cluster y compruebe que el cluster y todos los agentes de recursos funcionen con normalidad, como se muestra en la Figura 43. Figura 43. Comprobación del estado del cluster 49

50 Consideraciones clave sobre el diseño Configuración del dispositivo STONITH SBD (dispositivo de bloques STONITH) y STONITH (Shoot The Other Node In The Head) permiten el cercado (aislamiento de nodos) en un cluster mediante el almacenamiento compartido. Esta solución utiliza una partición de un disco virtual (VMDK) como un dispositivo SBD STONITH. 10 Por lo tanto, los dos nodos de cluster necesitan acceso simultáneo a este disco virtual. El disco virtual se almacena en la misma área de almacenamiento de datos que las máquinas virtuales de SAP. Está provisionado y protegido por VPLEX y está disponible en los dos sitios. De manera predeterminada, VMFS impide que varias máquinas virtuales accedan al mismo VMDK y escriban en el mismo VMDK. Sin embargo, es posible activar el uso compartido configurando la opción de múltiples escrituras 11, como se muestra en la Figura 44. Figura 44. Opción de múltiples escrituras El dispositivo SBD está protegido por VPLEX y se accede a él mediante el software de múltiples rutas EMC PowerPath/VE. Los parámetros de tiempo de espera agotado para el dispositivo SBD se deben configurar adecuadamente para tener en cuenta el tiempo de espera agotado del cluster Oracle RAC subyacente, al igual que con el proceso de aislamiento de VPLEX. La Figura 45 muestra la configuración utilizada para esta solución. Figura 45. Configuración del dispositivo SBD 10 SBD es esencial para manejar escenarios de división de recursos en el cluster. Para esta solución, se configura un solo dispositivo SBD. La configuración de este único dispositivo SBD tiene fines de prueba solamente; para la configuración de producción, consulte Running SAP NetWeaver on SUSE Linux Enterprise Server with High Availability Simple Stack. 11 Para obtener información detallada, consulte el artículo de Knowledgebase de VMware : Disabling simultaneous write protection provided by VMFS using the multi-writer flag. 50

51 Configuración de maestro/esclavo El agente de recursos SAPInstance controla la instancia de ASCS, además de la instancia de ERS pertinente. Se configura como un recurso maestro/esclavo que amplía las funciones del recurso de iniciado y detenido a maestro y esclavo. Una instancia maestra promovida inicia la instancia de SAP ASCS. La instancia esclava degradada inicia la instancia de ERS. El modo maestro/esclavo garantiza que nunca se inicie una instancia de ASCS en el mismo nodo que ERS. Figura 46 La muestra la configuración del agente de recursos SAPInstance. Figura 46. Configuración del agente de recursos SAPInstance Figura 47 La muestra la configuración del agente de recursos maestro/esclavo. Figura 47. Configuración del agente de recursos maestro/esclavo 51

52 Limitaciones de recursos La instancia de ASCS y su IP virtual están enlazadas juntas mediante restricciones de colocación y orden adecuadas. La Figura 48 muestra la configuración de las restricciones de colocación y orden de recursos. Figura 48. Configuración de las restricciones de colocación y orden de recursos Concepto de sondeo SUSE Linux Enterprise High Availability Extension puede monitorear de manera continua el estado de los procesos de SAP en cada nodo del cluster y tomar las decisiones correctas para promover y degradar la instancia de ASCS y la instancia de ERS, respectivamente. No es necesario implementar el concepto de sondeo de SAP. Asegúrese de que esta función NO esté activada en el perfil de la instancia de ERS. Para obtener un perfil de instancia de ERS de ejemplo, consulte Ejemplo de perfil de instancia de ERS en la página

53 Arquitectura de base de datos de Oracle Introducción Descripción general En esta sección se describen el grid y la base de datos subyacente de las aplicaciones de SAP en la solución. La base de datos se originó como una instancia física única de Oracle Database 11g. Para eliminar el servidor de base de datos como punto único de falla, la base de datos de única instancia se migró a un cluster Oracle RAC 11g físico de cuatro nodos y la base de datos Oracle se implementó en ASM. La solución utiliza los siguientes componentes y opciones de Oracle: Base de datos de Oracle 11g versión 2, Enterprise Edition Oracle Automatic Storage Management (ASM) y sistema de archivos en cluster de ASM (ACFS) de Oracle Oracle Clusterware Oracle Real Applications Clusters (RAC) 11g en clusters a grandes distancias Oracle Database 11g R2 Oracle Database 11g versión 2, Enterprise Edition, ofrece rendimiento, escalabilidad, seguridad y confiabilidad líderes del sector, con alternativas de implementación en un servidor único o en servidores agrupados en clusters que ejecutan Windows, Linux o UNIX. Proporciona funciones integrales para aplicaciones de procesamiento de transacciones, Business Intelligence y administración de contenido. Oracle ASM y Oracle ACFS Oracle ASM es un administrador de discos y sistemas de archivos de base de datos integrado y orientado al cluster. Las funciones de administración de volúmenes y sistemas de archivos de ASM están integradas con el kernel de base de datos de Oracle. En Oracle Database 11g R2, Oracle ASM también se ha ampliado para incluir la compatibilidad con archivos de OCR y voting disks para colocarlos dentro de los grupos de discos de ASM. Oracle ACFS, una función incluida en ASM, en Oracle Database 11g, amplía la funcionalidad de ASM para que actúe como un sistema de archivos de cluster de uso general. Los binarios de la base de datos de Oracle pueden residir en ACFS, del mismo modo que lo pueden hacer los archivos de apoyo, como logs de rastreo y alerta, y los archivos de aplicaciones no pertenecientes a Oracle, como SAP ERP. Los servidores no pertenecientes a Oracle pueden acceder a los volúmenes de ACFS mediante protocolos NAS estándares del sector, como NFS y CIFS (Common Internet File System). Oracle Clusterware Oracle Clusterware es una solución de administración de clusters portátil que se integra con la base de datos de Oracle. Proporciona la infraestructura necesaria para ejecutar Oracle RAC, incluidos los servicios de administración de clusters y los servicios de alta disponibilidad. Una aplicación no perteneciente a Oracle también puede tener alta disponibilidad en el cluster mediante Oracle Clusterware. 53

54 Oracle Grid Infrastructure En Oracle Database 11g R2, Oracle Grid Infrastructure combina Oracle ASM y Oracle Clusterware en un solo conjunto de binarios, separado del software de base de datos. Esta infraestructura ahora ofrece todos los servicios de almacenamiento y de cluster necesarios para ejecutar una base de datos Oracle RAC. Oracle Real Application Clusters 11g Oracle RAC es, principalmente, una solución de alta disponibilidad para las aplicaciones de la base de datos de Oracle dentro del centro de datos. Permite que varias instancias de Oracle tengan acceso a una sola base de datos. El cluster consta de un grupo de servidores independientes que funcionan conjuntamente como un solo sistema y comparten el mismo conjunto de discos de almacenamiento. Cada instancia se ejecuta en un servidor separado del cluster. RAC puede ofrecer beneficios de rendimiento, alta disponibilidad, escalabilidad, tolerancia a fallas y balanceo de carga, y elimina todos los puntos únicos de falla de la solución de base de datos. Oracle RAC en clusters a grandes distancias Oracle RAC en clusters a grandes distancias (Oracle RAC extendido) es una arquitectura que permite que los servidores del cluster residan en ubicaciones físicamente separadas. De este modo, se elimina el centro de datos como punto único de falla. Oracle RAC extendido permite que todos los nodos dentro del cluster, independientemente de la ubicación, estén activos. Proporciona alta disponibilidad y continuidad del negocio durante una falla de red o del sitio, de la siguiente manera: El almacenamiento y los datos permanecen disponibles y activos en el sitio no afectado. Los servicios de Oracle balancean la carga y realizan failover a los nodos de Oracle RAC en el sitio no afectado. El failover transparente de las aplicaciones (TAF) de Oracle permite que las sesiones realicen failover automáticamente a los nodos de Oracle RAC en el sitio no afectado. Las aplicaciones de otros fabricantes colocadas bajo el control de Oracle Clusterware pueden balancear la carga y realizar failover a los nodos de Oracle RAC en el sitio no afectado, por ejemplo, NFS o Apache httpd. Los nodos de Oracle RAC en el sitio no afectado siguen procesando transacciones. Oracle recomienda que la mejor opción para emplear la arquitectura de Oracle RAC extendido es en los casos en que los dos centros de datos están relativamente cerca (a una distancia inferior a 100 km) Consulte el informe técnico de Oracle Oracle Real Application Clusters (RAC) on Extended Distance Clusters. 54

55 Oracle RAC y VPLEX Configuración de Oracle ACFS Oracle RAC, normalmente, se ejecuta en un centro de datos local debido al posible impacto de la latencia inducida por la distancia, y la complejidad y sobrecarga relativas de ampliar Oracle RAC entre centros de datos con espejeado basado en host mediante Oracle ASM. Sin embargo, con EMC VPLEX Metro, una implementación de Oracle RAC extendido, desde la perspectiva del administrador de bases de datos de Oracle, se convierte en una instalación y una configuración estándares de Oracle RAC 13. Esta solución utiliza cuatro volúmenes de ACFS montados en el cluster Oracle RAC, como se muestra en la Tabla 10. Tres de estos volúmenes (SAPMNT, USRSAPTRANS y ASCS00) se exportaron como recursos compartidos NFS a los servidores de SAP, mediante una dirección IP virtual y un recurso NFS con alta disponibilidad bajo el control de Oracle Clusterware. Tabla 10. Puntos de montaje y volúmenes de Oracle ACFS Volumen de ACFS Tamaño (GB) Punto de montaje Descripción SAP_O_HOME 16 /oracle/vse/112 ORACLE_HOME para la base de datos VSE; se comparte en todos los nodos de Oracle RAC SAPMNT 16 /sapmnt/vse Directorio global de SAP, que almacena los kernels y los perfiles; se comparte en todas las máquinas virtuales de SAP USRSAPTRANS 16 /usr/sap/trans Directorio de transporte de SAP, que almacena los archivos de transporte; se comparte en todas las máquinas virtuales de la instancia de diálogo de SAP ASCS00 16 /usr/sap/vse/ascs00 Directorio de la instancia de SAP ASCS, que almacena los archivos relacionados con la instancia; se comparte en los nodos de cluster de SUSE Linux Enterprise High Availability Extension 13 Consulte el informe técnico de EMC Oracle Extended RAC with EMC VPLEX Metro Best Practices Planning. 55

56 Oracle RAC extendido en VPLEX Metro Figura 49 La proporciona una representación lógica de la implementación de Oracle RAC extendido en VPLEX Metro para la solución. Figura 49. Oracle RAC extendido mediante EMC VPLEX Metro Configuración del grupo de discos de Oracle ASM Tabla 11 La muestra el diseño y la configuración del grupo de discos de ASM. Tabla 11. Grupo de discos de ASM* Tamaño y configuración del grupo de discos de Oracle ASM Cant. de discos Tamaño del grupo de discos (GB) Redundancia OCR 5 40 Normal EA_SAP_ACFS 4 64 Externa EA_SAP_DATA 16 2,048 Externa EA_SAP_REDO 4 64 Externa EA_SAP_REDOM 4 64 Externa EA_SAP_FRA Externa * El prefijo EA_SAP_ se utiliza para identificar de manera exclusiva los grupos de discos de ASM relacionados con la aplicación SAP en Oracle RAC extendido. 56

57 Conexión con Oracle RAC desde SAP Para que SAP se pueda conectar con la base de datos Oracle RAC, tnsnames.ora se ubicó en cada una de las máquinas virtuales de SAP (SAPDI1 y SAPDI2), como se muestra en la Figura 50. VSE.WORLD= (DESCRIPTION = (LOAD_BALANCE = OFF) (FAILOVER = ON) (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP) (HOST = sse-ea-erac-scan-c01.sse.ea.emc.com) (PORT = 1521) ) ) (CONNECT_DATA = ) ) (SERVICE_NAME = VSE.sse.ea.emc.com) (FAILOVER_MODE = (TYPE = SELECT) (METHOD = BASIC)) Figura 50. Ejemplo de entrada de archivo tnsnames.ora para la base de datos Oracle RAC El failover transparente de las aplicaciones (TAF) es una función ejecutada en el cliente que permite que los clientes se vuelvan a conectar a las instancias no afectadas si se produce una falla en una instancia de la base de datos. TAF se puede configurar mediante una cadena de conexión especificada en el cliente o atributos de servicio en el servidor. En la solución, el servicio de base de datos VSE.sse.ea.emc.com se configuró para TAF en Oracle RAC. También se configuró en el cliente para permitir que SAP utilice TAF. TAF se configuró para establecer conexiones en el momento del failover y para permitir que los usuarios con cursores abiertos continúen ejecutando operaciones de recuperación después de una falla de operaciones de selección. 57

58 Infraestructura de red de Brocade Introducción Descripción general En esta sección, se describen las redes SAN e IP implementadas para la solución en los dos centros de datos y la extensión de capa 2 entre los centros de datos. La infraestructura de red se diseñó mediante los siguientes componentes de Brocade: Red IP Switches de centro de datos Brocade VDX 6720 Enrutadores de la serie Brocade MLX CNA Brocade 1020 SAN Redes troncales Brocade DCX 8510 Tarjetas HBA Brocade 825 Brocade VDX 6720 El switch de centro de datos Brocade VDX 6720 es un switch de puerto fijo de 10 GbE de velocidad de transferencia, de alto rendimiento y latencia ultrabaja. Está especialmente diseñado para mejorar la utilización de red, maximizar la disponibilidad de las aplicaciones, aumentar la escalabilidad y simplificar considerablemente la arquitectura de red en centros de datos virtualizados. Con un conjunto enriquecido de funciones de capa 2, Brocade VDX 6720 es una plataforma ideal para implementaciones tradicionales de switch en la parte superior del rack (ToR). Gracias a que ofrece la tecnología de fabric Brocade VCS, Brocade VDX 6720 permite a las organizaciones crear fabrics Ethernet de centro de datos, lo cual revoluciona el diseño de las redes de capa 2 y proporciona una base inteligente para centros de datos optimizados para la nube. Serie Brocade MLX Los enrutadores de la serie Brocade MLX están diseñados para permitir redes optimizadas para la nube, ya que proporcionan densidad de velocidad de transferencia de 100 GbE, 10 GbE y 1 GbE líder del sector; funciones enriquecidas de IPv4, IPv6, Multi-VRF, Multiprotocol Label Switching (MPLS) y funcionalidades de Ethernet de operador; y switching avanzado de capa 2. Mediante los enrutadores de la serie Brocade MLX, los centros de datos de misión crítica pueden admitir más tráfico, lograr un nivel mayor de virtualización y ofrecer servicios de alto valor basados en la nube usando menos infraestructura, lo cual permite simplificar las operaciones y reducir los costos. Además, los enrutadores de la serie Brocade MLX pueden reducir la complejidad en las redes de grandes campus, ya que disminuyen las capas principales y de agregación, además de ofrecer conectividad entre los sitios mediante MPLS/VPLS. Todos los enrutadores de la serie Brocade MLX ayudan a reducir los costos de alimentación y enfriamiento con los niveles más bajos de consumo de energía y disipación de calor en su clase. Diseñados para redes de funcionamiento continuo, los enrutadores de la serie Brocade MLX incluyen trunking de múltiples chasis (MCT), que proporciona más de 30 TB/s de ancho de banda de dos chasis, enlaces de enrutamiento de modo activo/activo completo y flujo de trabajo sin interrupción en el caso de un failover de nodo. Las organizaciones pueden lograr una alta resistencia mediante fabrics de switch, módulos de administración, fuentes de alimentación y sistemas de enfriamiento totalmente redundantes. Parar garantizar aún más la disponibilidad de la red y las aplicaciones, el sistema operativo Brocade IronWare incluye actualizaciones de software y failover de administración sin impacto. 58

59 Red troncal Brocade DCX 8510 Las redes necesitan evolucionar a fin de adaptarse a las crecientes exigencias de los ambientes altamente virtualizados y las arquitecturas de nube privada. En la actualidad, Fibre Channel (FC) es el estándar de facto para redes de almacenamiento en el centro de datos. La incorporación de Fibre Channel de 16 Gb/s extiende la vida de esta tecnología de alto rendimiento, sólida y confiable. Esto permite a las organizaciones seguir aprovechando sus inversiones existentes en TI a medida que resuelven sus retos de negocios más difíciles. Las redes troncales Brocade DCX 8510 son la infraestructura de switches Fibre Channel de 16 Gb/s más sólida del sector y proporcionan la base de alto rendimiento más confiable y escalable para el almacenamiento de nube privada y los ambientes altamente virtualizados. Están diseñadas para mejorar la agilidad del negocio proporcionando acceso continuo a la información y reduciendo los costos administrativos y de infraestructura. La funcionalidad de FC de 16 Gb de Brocade DCX 8510 ofrece beneficios significativos para la conectividad de la SAN de Metro de un centro de datos a otro centro de datos: Los 16 Gb representan la conectividad FC de máximo rendimiento y latencia más baja para implementaciones que utilizan conexiones Fibre entre centros de datos. Velocidad de línea de FC de 10 Gb opcional para la utilización óptima de la línea si se implementa una red DWDM entre sitios. Esta función requiere una licencia. Interswitch link (ISL) trunking opcional a nivel de frame que permite una alta utilización en comparación con la función de DPS trunking estándar. Esta función requiere una licencia. Compresión opcional para ISL entre los centros de datos. Esto proporciona mayor ancho de banda para implementaciones en las que el número de conexiones de sitio a sitio son limitadas. Cifrado de datos en transferencia opcional para los ISL entre los centros de datos orientado a implementaciones que requieren niveles muy altos de seguridad de datos. Detección de pérdida de crédito de buffer y recuperación. Corrección de errores hacia adelante (FEC) automática, que corrige proactivamente errores de hasta 11 bits por frame de FC de 2,112 bits. El modo de diagnóstico para los puertos ISL entre los centros de datos se puede utilizar en cualquier puerto ISL (offline) y ofrece las siguientes características: Pruebas de loopback óptico y eléctrico. Prueba de saturación de enlaces. Precisión de medida de distancia entre enlaces de hasta 5 m cuando se utiliza con SFP+ de 8 Gb y de hasta 50 m cuando se utiliza con SFP+ de 10 GbE. 59

60 Configuración de red IP Para la solución, la red IP en cada centro de datos se creó con dos switches Brocade VDX 6720 en una configuración VCS. Todos los servidores se conectaron a la red mediante conexiones de 10 GbE redundantes proporcionadas por CNA Brocade Los dos switches Brocade VDX de cada sitio se conectaron con un enrutador de la serie Brocade MLX mediante un grupo de agregación de enlaces virtual (vlag). Los enrutadores de la serie Brocade MLX extienden la red de capa 2 entre los dos centros de datos. Nota Un vlag es un servicio de fabric que permite que un grupo de agregación de enlaces (LAG) se origine a partir de varios switches Brocade VDX. Del mismo modo que un LAG estándar, un vlag utiliza el protocolo de control de agregación de enlaces (LACP) para controlar la agrupación de varios puertos físicos para formar un solo canal lógico. Oracle RAC depende de una IP virtual de alta disponibilidad (interconexión de RAC o HAIP) para la comunicación con la red privada. Con HAIP, se balancea la carga del tráfico de interconexión entre el conjunto de interfaces identificadas como la red privada. Para la solución, se utilizó una red VLAN (VLAN 10) separada para la interconexión. VLAN 20 manejó todo el tráfico público. Todo el tráfico entre el sitio A y el sitio B se enrutó mediante los enrutadores Brocade MLX usando varios puertos configurados como un LAG. Figura 51 La muestra la infraestructura de red IP. Figura 51. Redes IP de la solución 60

61 Configuración de red SAN La SAN en cada centro de datos se diseñó con redes troncales Brocade DCX 8510, como se muestra en la Figura 52. Todos los servidores se conectaron a la SAN mediante conexiones de 8 Gb redundantes proporcionadas por tarjetas HBA Brocade 825. La conexión de VPLEX a VPLEX entre los centros de datos utiliza varias conexiones FC entre las redes troncales Brocade DCX Estas se usan en modo activo/activo con failover. Figura 52. Redes SAN de la solución 61

62 Alta disponibilidad y continuidad del negocio: pruebas y validación Introducción Falla del proceso de servicio de línea de espera de SAP El equipo de validación de EMC, inicialmente, instaló y validó el ambiente sin ningún esquema de protección de continuidad del negocio o de alta disponibilidad. Luego, transformó el ambiente en la solución de continuidad del negocio de misión crítica descrita en este informe técnico. Realizamos las siguientes pruebas para validar la solución y demostrar la eliminación de todos los puntos únicos de falla del ambiente: Falla del proceso de servicio de línea de espera de SAP Falla de la máquina virtual de instancia de SAP ASCS Falla de nodo de Oracle RAC Falla del sitio Aislamiento del cluster VPLEX Escenario de prueba Este escenario de prueba valida que, si se produce una falla en el proceso del servicio de línea de espera, el cluster SUSE Linux Enterprise High Availability Extension promueve la instancia de SAP ERS a una instancia de ASCS completamente funcional y asume el control de la tabla de bloqueo sin interrupción para el usuario final. A fin de evaluar este escenario de falla, finalizamos el proceso de línea de espera en el nodo activo de ASCS con el comando kill: kill -9 <process id> Comportamiento del sistema El sistema responde ante la falla del proceso del servicio de línea de espera de la siguiente manera: 1. El agente de recursos SAPInstance detecta e informa la falla, como se muestra en la Figura 53. Figura 53. El agente de recursos SAPInstance detecta e informa la falla 62

63 2. El agente de recursos maestro/esclavo promueve el nodo esclavo anterior (SAPASCS2) al nodo maestro, que aloja los servicios ASCS, e inicia ERS como esclavo en el otro nodo (SAPASCS3) cuando se vuelve a unir al cluster (consulte la Figura 54). Figura 54. El agente de recursos maestro/esclavo intercambia los nodos maestro y esclavo 3. Se restaura la tabla de bloqueo replicada, como se muestra en la Figura 55. Figura 55. Restauración de la tabla de bloqueo replicada Resultado El usuario final no nota la falla en el proceso de línea de espera, a menos que una operación de línea de espera esté en ejecución. En este caso, el usuario final experimenta un tiempo de respuesta de transacción más prolongado durante el traspaso. Los usuarios nuevos pueden iniciar sesión en el sistema inmediatamente después del traspaso del servidor de mensajes. No se requiere intervención administrativa. 63

64 Falla de la máquina virtual de instancia de SAP ASCS Escenario de prueba Este escenario de prueba valida que, si se produce una interrupción inesperada de ESXi Server (lo cual equivale a una falla en una máquina virtual), el cluster High Availability Extension promueve la instancia de SAP ERS a una instancia de ASCS completamente funcional y asume el control de la tabla de bloqueo, sin interrupción para el usuario final. Para evaluar este escenario de falla, desactivamos (mediante la consola física remota) el servidor ESXi Server que aloja la máquina virtual de la instancia de SAP ASCS. Luego, reiniciamos el servidor sin entrar en modo de mantenimiento. Comportamiento del sistema El sistema responde ante la falla de la máquina virtual de la siguiente manera: 1. SAPASCS2 deja de estar disponible en vsphere Client (consulte la Figura 56). Figura 56. La máquina virtual falla 64

65 2. El agente de recursos SAPInstance detecta e informa la falla (consulte la Figura 57). Figura 57. El agente de recursos SAPInstance detecta e informa la falla 3. VMware HA reinicia la máquina virtual con errores SAPASCS2 en el host ESXi no afectado, como se muestra en la Figura 58. Figura 58. VMware HA reinicia la máquina virtual fallida 4. El agente de recursos maestro/esclavo promueve el nodo esclavo anterior (SAPASCS3) al nodo maestro, que aloja los servicios ASCS, e inicia ERS como esclavo en el otro nodo (SAPASCS2) cuando se vuelve a unir al cluster (consulte la Figura 59). 65

66 Figura 59. esclavo El agente de recursos maestro/esclavo intercambia los nodos maestro y 5. Se restaura la tabla de bloqueo replicada (consulte la Figura 60). Figura 60. Restauración de la tabla de bloqueo replicada Resultado El usuario final no nota la falla en el proceso de línea de espera, a menos que una operación de línea de espera esté en ejecución. En este caso, el usuario final experimenta un tiempo de respuesta de transacción más prolongado durante el traspaso. Los usuarios nuevos pueden iniciar sesión en el sistema inmediatamente después del traspaso del servidor de mensajes. No se requiere intervención administrativa. Falla de nodo de Oracle RAC Escenario de prueba Este escenario de prueba valida que, si se produce una falla inesperada en un nodo de RAC, las instancias de SAP se conectan automáticamente a otros nodos de RAC. Los usuarios finales pueden seguir con sus transacciones sin interrupción, a menos que se estén ejecutando transacciones no confirmadas (a nivel de la base de datos) en el nodo de RAC con errores. Para evaluar este escenario de falla, reiniciamos el servidor para provocar un failover de nodo de Oracle. 66

67 Comportamiento del sistema El sistema responde ante la falla del nodo de RAC de la siguiente manera: 1. El nodo de RAC se coloca offline y la instancia VSE003 no está disponible, como se muestra en la Figura 61. Figura 61. oracle@sse-ea-erac-n01:~> srvctl status database -d VSE Instance VSE001 is running on node sse-ea-erac-n01 Instance VSE002 is running on node sse-ea-erac-n02 Instance VSE004 is running on node sse-ea-erac-n03 Instance VSE003 is not running on node sse-ea-erac-n04 El nodo de RAC se coloca offline 2. El proceso de trabajo de la instancia de SAP se conecta con otra instancia de RAC, como se muestra en la Figura 62.. Figura 62. La instancia de SAP se conecta con otro nodo de RAC Resultado El usuario final experimenta un tiempo de respuesta de transacción más prolongado cuando el proceso de trabajo de instancia de diálogo se vuelve a conectar con otro nodo de RAC. Las transacciones no confirmadas se revierten a nivel de la base de datos a fin de garantizar la consistencia de los datos. El usuario final recibe un mensaje de error del sistema (volcado corto) y debe reiniciar la transacción. No se requiere intervención administrativa. Falla del sitio Escenario de prueba Este escenario de prueba valida que, si se produce una falla de todo el sitio, los nodos de RAC no afectados conservan las operaciones de base de datos. Para evaluar este escenario de falla, simulamos una falla completa del sitio A, incluidos los componentes del cluster VPLEX, ESXi Server, la red y los nodos de Oracle RAC. VPLEX Witness permaneció disponible en el sitio C. En el sitio B, el cluster VPLEX 2 siguió en comunicación con VPLEX Witness. 67