MEJORES PRÁCTICAS Y REGLAS DE DISEÑO DE MICROSOFT SQL SERVER PARA EL ALMACENAMIENTO DE EMC

Transcripción

1 Informe técnico MEJORES PRÁCTICAS Y REGLAS DE DISEÑO DE MICROSOFT SQL SERVER PARA EL ALMACENAMIENTO DE EMC Familia EMC VNX, sistemas EMC Symmetrix VMAX y productos de servidor EMC Xtrem Mejores prácticas para el dimensionamiento y el diseño Aceleración del rendimiento de SQL Server con tecnologías flash Mejores prácticas para la recuperación de desastres y la alta disponibilidad Soluciones de EMC Resumen Este informe técnico identifica las mejores prácticas y los puntos de decisión clave para la planificación e implementación de Microsoft SQL Server con la familia EMC VNX de almacenamiento unificado, el almacenamiento de la serie EMC Symmetrix VMAX y los productos de EMC XtremSF y EMC XtremSW Cache. Octubre de 2013

2 Copyright 2013 EMC Corporation. Todos los derechos reservados. EMC considera que la información de esta publicación es precisa en el momento de su publicación. La información está sujeta a cambios sin previo aviso. La información contenida en esta publicación se proporciona tal como está. EMC Corporation no se hace responsable ni ofrece garantía de ningún tipo con respecto a la información de esta publicación y específicamente renuncia a toda garantía implícita de comerciabilidad o capacidad para un propósito determinado. El uso, la copia y la distribución de cualquier software de EMC descrito en esta publicación requieren una licencia de software correspondiente. Para obtener una lista actualizada de nombres de productos de EMC, consulte las marcas comerciales de EMC Corporation en (visite el sitio web de su país correspondiente). Todas las marcas comerciales incluidas/utilizadas en este documento pertenecen a sus respectivos propietarios. Número de referencia H12341 Mejores prácticas y reglas de diseño de Microsoft SQL Server para el 2 2

3 Tabla de contenido Resumen... 7 Propósito de este informe... 7 Público al que va dirigido... 7 Alcance... 7 Terminología... 8 Componentes y arquitectura de Microsoft SQL Server Descripción general de SQL Server Versiones de SQL Server SQL Server Ediciones de SQL Server Componentes de SQL Server Windows Server Tipos de volumen de Windows SMB Arquitectura de SQL Server Componentes lógicos de SQL Server Componentes físicos de SQL Server Tipos de archivos Página y extensión Log de transacciones Grupo de archivos Características de I/O y de ancho de banda de SQL Server Descripción general OLTP Base de datos de Data warehouse/olap Páginas de lectura Páginas de escritura Log Manager Uso de Tempdb Patrones de I/O Mejores prácticas para el dimensionamiento y el aprovisionamiento del almacenamiento de SQL Server Descripción general Mejores prácticas generales del almacenamiento de SQL Server Mejores prácticas básicas para SQL Server Mejores prácticas básicas para el almacenamiento Consideraciones sobre la agrupación en clusters Consideraciones para las versiones anteriores Consideraciones generales para el almacenamiento Consideraciones de rendimiento frente a capacidad Selección del tipo de disco Microsoft Exchange: Mejores prácticas Storage y reglas Best de Practices diseño de and Microsoft Design Guidance SQL Server for para EMC el Storage 3 3

4 Pools y tipos de RAID Consideraciones para el aprovisionamiento virtual del almacenamiento LUN delgado frente a LUN grueso Mejores prácticas para el dimensionamiento del almacenamiento Consideraciones para el dimensionamiento de la base de datos OLTP Mejores prácticas para el dimensionamiento de FAST VP Consideraciones para el dimensionamiento de la base de datos OLAP Consideraciones de almacenamiento para hipervisor Reglas generales para la virtualización Mejores prácticas para el ambiente VMware vsphere Microsoft Hyper-V Consideraciones de almacenamiento para la agrupación en clusters de SQL Server Reglas de diseño de almacenamiento para Symmetrix VMAX Consideraciones para el diseño de hardware de la serie VMAX Consideraciones y mejores prácticas del aprovisionamiento virtual Consideraciones y mejores prácticas de FAST VP para un sistema de almacenamiento VMAX Reglas de diseño de almacenamiento para VNX Consideraciones y mejores prácticas para FAST Cache Consideraciones y mejores prácticas para FAST VP FAST Cache frente a FAST VP Consideraciones para flash de servidor Descripción general de XtremSF Mejores prácticas de diseño para XtremSF Descripción general de XtremSW Cache Mejores prácticas de diseño para XtremSW Cache Mejores prácticas de diseño para XtremSW Cache en un ambiente virtualizado Consideración de dimensionamiento para XtremSF y XtremSW Cache Automatización con ESI Protección de SQL Server Descripción general Grupos de disponibilidad continua Protección de datos nativa de SQL Server Copias recuperables frente a copias reiniciables Marcos de trabajo de VDI y VSS para la replicación del respaldo Ofertas de protección de datos y alta disponibilidad de EMC para SQL Server Tecnologías de replicación Herramientas de administración de replicaciones Recuperación de desastres de múltiples sitios Consideraciones Tecnologías de replicación de múltiples sitios Herramientas para la automatización del reinicio Herramientas de automatización de instancias virtualizadas Opciones de recuperación de desastres para SQL Server Recomendaciones de respaldo adicionales Disponibilidad continua para la alta disponibilidad y la recuperación de desastres Mejores prácticas y reglas de diseño de Microsoft SQL Server para el 4 4

5 Disponibilidad continua con FAST Suite Disponibilidad continua con XtremSW Cache/XtremSF con tecnología flash Conclusiones Resumen Información adicional Apéndice A: EMC Data Protection Advisor para análisis de replicación Descripción general Asistentes de descubrimiento y recopilación de datos Descubrimiento y recopilación de datos Descubrimiento de arreglos de almacenamiento Configuración de Data Protection Advisor para el monitoreo de Microsoft SQL Server Visualización y creación de informes de brechas y exposiciones Apéndice B: Herramientas para el monitoreo del rendimiento, optimización y dimensionamiento de SQL Server Descripción general Herramientas en el nivel de aplicaciones EMC DBclassify Perfcollect PAL Herramientas en el nivel de base de datos de SQL Server Herramienta para dimensionamiento de VSPEX SQL Server Transact-SQL SQL Server Profiler Asistente para la optimización de motor de base de datos de SQL Server Vistas de administración dinámica de SQL Server Herramienta en el nivel de host de Windows Windows Performance Monitor (Perfmon) Herramientas en el nivel de hipervisor Métricas clave para monitorear ESX Métricas clave para monitorear Hyper-V Herramientas en el nivel de caché de almacenamiento/servidor Unisphere Analyzer XtremSW Cache Performance Predictor EMC Storage Configuration Advisor Apéndice C: Herramientas de generación de tipos de carga de SQL Server Descripción general Presentación de herramientas SQL Server Profiler IOMeter SQLIO SQLIOSim Quest Benchmark Factory Microsoft Exchange: Mejores prácticas Storage y reglas Best de Practices diseño de and Microsoft Design Guidance SQL Server for para EMC el Storage 5 5

6 Apéndice D: Diseños y arquitecturas de referencia para el almacenamiento de muestra Descripción general Diseño de almacenamiento de Microsoft SQL Server en VMAX con FAST VP Fase 1: recolectar requisitos del usuario Fase 2: diseñar la arquitectura del almacenamiento según los requisitos del usuario Cálculo de IOPS Cálculo de capacidad Enfoque de diseño del componente básico para data warehouse Consideraciones para el diseño de un componente básico Detalles del diseño de un componente básico Implementación de componentes básicos Diseño de asignación de máquina virtual y LUN de SQL Server Solución de protección de SQL Server EMC RecoverPoint EMC Replication Manager VMware vcenter SRM Mejores prácticas y reglas de diseño de Microsoft SQL Server para el 6 6

7 Resumen En las fases de planificación y diseño de una implementación de Microsoft SQL Server, es importante comprender cómo la aplicación interactúa con la plataforma de almacenamiento. También es fundamental saber cuáles son las mejores prácticas de almacenamiento y diseño que se deben seguir para evitar problemas y lograr un alto rendimiento. Desde una perspectiva de diseño del almacenamiento, tenga en cuenta la arquitectura de la aplicación y las características del perfil de usuario de Microsoft SQL Server en cuanto a rendimiento, protección y crecimiento de la base de datos de SQL Server. Este informe puede ayudar a los profesionales de soluciones a evaluar y a cumplir los requisitos de almacenamiento de SQL Server para el rendimiento, la escalabilidad y la disponibilidad: Siempre es preferible recopilar datos reales desde el sitio. Si no existen datos reales de rendimiento, puede formular una serie de hipótesis razonables para el diseño de un ambiente típico. Tenga siempre presente los requisitos de protección para el diseño de un sistema de almacenamiento. Propósito de este informe Público al que va dirigido Alcance Este informe presenta el conjunto de mejores prácticas recomendadas y actuales de EMC para que el diseño de almacenamiento sea compatible con Microsoft SQL Server. Las reglas se presentan en el contexto de la implementación de SQL Server en la familia EMC VNX, en la serie EMC Symmetrix VMAX y en la familia EMC Xtrem. Este informe incluye reglas para implementar SQL Server en ambientes físicos y virtuales. Este informe técnico está dirigido a los clientes, partners de EMC y al personal de servicio que tenga en mente la implementación de un ambiente de base de datos con Microsoft SQL Server o que considere la actualización de una versión anterior de SQL Server. Suponemos que la audiencia está familiarizada con Microsoft SQL Server, los productos de como VNX, Symmetrix VMAX, XtremSF y XtremSW Cache, así como con los ambientes virtuales de VMware o Microsoft Hyper-V. Este documento presenta las mejores prácticas recomendadas de EMC para el diseño de almacenamiento para alojar Microsoft SQL Server en el almacenamiento EMC VNX, en el almacenamiento EMC Symmetrix VMAX y en XtremSF o XtremSW Cache en ambientes físicos y virtuales. Este informe incluye ejemplos de dimensionamiento y diseño basados en los enfoques comprobados de EMC. Las instrucciones detalladas para la implementación de punto a punto están más allá del alcance de este documento. Microsoft Exchange: Mejores prácticas Storage y reglas Best de Practices diseño de and Microsoft Design Guidance SQL Server for para EMC el Storage 7 7

8 Terminología Este informe técnico incluye la siguiente terminología. Tabla 1. Terminología Término Grupos de disponibilidad (AG) Réplica de disponibilidad Sincronización de datos EMC XtremSF emlc FAST Cache Fully Automated Storage Tiering for Virtual Pools (FAST VP) Flash con celda de múltiples niveles (MLC) NAND Definición Una característica de alta disponibilidad (HA) y de recuperación de desastres en SQL Server Mediante la maximización de la disponibilidad de un conjunto de bases de datos de usuario, proporciona una alternativa de nivel empresarial al espejeado de la base de datos. Es una instancia de un grupo de disponibilidad que se aloja en una instancia específica de SQL Server y mantiene una copia local de cada base de datos de disponibilidad que pertenezca al grupo de disponibilidad. Existen dos tipos de réplicas de disponibilidad, una única réplica primaria (consulte Réplica primaria en esta tabla) y hasta cuatro réplicas secundarias (consulte Réplica secundaria legible). Es el proceso en el que los cambios realizados a una base de datos primaria se reproducen en una base de datos secundaria. Es una única tarjeta de hardware flash de servidor de bajo perfil que se adapta a cualquier servidor de montaje en rack dentro del ámbito de alimentación de un único slot PCIe y que está disponible con un conjunto amplio de capacidades de celda de múltiples niveles empresarial (emlc) y de celdas de un solo nivel (SLC). Celda de múltiples niveles empresariales. Una celda de múltiples niveles es una tecnología de memoria flash diseñada para ofrecer bajas tasas de error mediante el uso de múltiples niveles por celda para permitir el almacenamiento de un número mayor de bits con el mismo número de transistores. Fully Automated Storage Tiering (FAST) Cache es el software de EMC que les permite a los clientes incorporar varias capacidades de disco flash para ampliar la capacidad de caché existente y así mejorar el rendimiento del sistema. FAST Cache ahora se ofrece con configuraciones de mayor capacidad que emplean el disco flash de 100 GB o el disco flash de 200 GB. Estas configuraciones adicionales solo están disponibles en el arreglo de almacenamiento VNX. Es una función de los arreglos de almacenamiento VNX que automatiza la identificación de volúmenes de datos con el propósito de asignar o reasignar datos de aplicaciones empresariales a diferentes niveles de rendimiento y de capacidad dentro del arreglo de almacenamiento. Una tecnología de memoria flash que usa múltiples niveles por celda para permitir que se almacenen más bits con la misma cantidad de transistores. La memoria flash de tipo NAND es un tipo de tecnología de almacenamiento no volátil que no requiere alimentación para conservar los datos. Mejores prácticas y reglas de diseño de Microsoft SQL Server para el 8 8

9 Término OLTP Réplica primaria RAID Réplica secundaria legible Replicación Flash con celda de un solo nivel (SLC) SP SQL Server 2012 AlwaysOn Pool de almacenamiento LUN delgado LUN grueso VMDK Definición Procesamiento de transacciones en línea (Online transaction processing). Las aplicaciones típicas de OLTP incluyen entrada de datos y procesamiento de recuperación de transacciones. La réplica de disponibilidad que hace que las bases de datos primarias estén disponibles para conexiones de lectura/escritura por parte de clientes y envía registros de log de transacciones para cada base de datos primaria a cada réplica secundaria. El arreglo redundante de discos independientes (RAID) es un método de almacenamiento de datos en múltiples unidades de discos para aumentar el rendimiento y la capacidad de almacenamiento; además de proporcionar redundancia y tolerancia a fallas. Bases de datos de réplica secundaria configuradas para permitir conexiones de cliente de solo lectura. Es el proceso de copiar una base de datos de una réplica primaria a las correspondientes réplicas secundarias. Un tipo de almacenamiento de estado sólido (disco SSD) que almacena un bit de información por celda de medio flash. Procesador de almacenamiento. Es una solución integral de alta disponibilidad y recuperación de desastres para SQL Server La disponibilidad continua presenta funcionalidades nuevas y mejoradas tanto para bases de datos específicas como para instancias completas, lo que proporciona flexibilidad para admitir varias configuraciones de alta disponibilidad. Son estructuras virtuales que permiten la transferencia dinámica de datos a través de distintos niveles de almacenamiento según la actividad comercial de los datos. Con los sistemas VNX y VMAX, los pools de almacenamiento están completamente automatizados y cuentan con autoadministración. Es un tipo de LUN que se crea en el pool de almacenamiento, en el cual el espacio físico asignado puede ser inferior a la capacidad de usuario que observa el servidor host. Es un tipo de LUN que se crea en el pool de almacenamiento, en el cual el espacio físico asignado es igual a la capacidad de usuario que observa el servidor host. Formato de archivo de disco de máquina virtual en un servidor ESXi. VHDX Formato de disco duro virtual en Windows Server 2012 Hyper-V. Microsoft Exchange: Mejores prácticas Storage y reglas Best de Practices diseño de and Microsoft Design Guidance SQL Server for para EMC el Storage 9 9

10 Componentes y arquitectura de Microsoft SQL Server Descripción general de SQL Server Microsoft SQL Server es el sistema de administración de bases de datos relacionales y de análisis para las soluciones de funcionamiento diario y de data warehousing. La versión actual es Microsoft SQL Server 2012 y las versiones anteriores incluyen Microsoft SQL Server 2008 R2, SQL Server 2008, SQL Server 2005 y SQL Server Versiones de SQL Server En la versión SQL Server 2000, Microsoft se enfocó en la funcionalidad de Business Intelligence, que incluye la herramienta de extracción, transformación y carga (ETL), servidor de informes y los servicios de análisis de procesamiento analítico en línea (OLAP). SQL Server 2005 presentó el tipo de datos XML, las vistas de administración dinámica (DMVS) para el monitoreo y diagnóstico del estado y rendimiento del servidor y Common Language Runtime (CLR) para integrar con.net Framework. El Service Pack 1 (SP1) de SQL Server 2005 agregó el espejeado de la base de datos para la redundancia y la funcionalidad de failover en el nivel de la base de datos. SQL Server 2008 introdujo las tecnologías de disponibilidad continua para reducir el tiempo fuera y apuntaba a hacer que la administración de datos contara con ajuste automático, organización automática y que se mantuviera a sí misma. SQL Server 2008 R2 añadió Master Data Services para administrar de manera centralizada las entidades de datos y jerarquías, además de la administración de varios servidores para centralizar múltiples instancias y servicios de SQL Server. SQL Server 2012 presentó instancias de cluster de failover de SQL Server y grupos de disponibilidad continuos para mejorar la disponibilidad de la base de datos, índices de almacén de columnas para aumentar el rendimiento de las consultas, bases de datos independientes para simplificar la transferencia entre instancias de bases de datos y una mejor administración de memoria. Cada versión de SQL Server viene en varias ediciones, que se pueden considerar como un subconjunto de las características del producto. Los usuarios pueden verificar la edición que están ejecutando con la consulta: select serverproperty( edition ). Las ediciones principales incluyen las siguientes ediciones: Datacenter, Enterprise, Standard, Web, Business Intelligence, Workgroup y Express. SQL Server 2012 SQL Server 2012 es la última versión de Microsoft SQL Server. Admite alta disponibilidad y recuperación de desastres a través de los clusters de disponibilidad continua y de los grupos de disponibilidad, almacenamiento en memoria xvelocity para un rendimiento rápido de las consultas, exploración rápida de datos mediante PowerView y modelado tabular en Analysis Services, además de nuevas capacidades de administración de datos con Data Quality Services. Ediciones de SQL Server 2012 Microsoft SQL Server 2012 incluye las siguientes ediciones principales: SQL Server Standard Edition: esta edición proporciona administración básica de datos y capacidades de creación de informes y análisis de Business Intelligence. Brinda una administración eficaz de base de datos con un mínimo de recursos de TI. Mejores prácticas y reglas de diseño de Microsoft SQL Server para el 10 10

11 Business Intelligence Edition: además de todas las funcionalidades de la edición estándar de SQL Server, esta edición también es compatible con soluciones de BI de autoservicio y escalables. Características de TI: PowerView: una función de complemento de los servicios de SQL Reporting para lograr un descubrimiento rápido de datos PowerPivot: es una característica que colabora y comparte fácilmente la información con los datos de acceso y datos combinados Master Data Services: se usa para mantener los datos maestros que se utilizan para el mapeo de objeto, datos de referencia y administración de metadatos en la estructura de la organización Modelo semántico de BI: proporciona una vista coherente de los orígenes de datos heterogéneos y transforma las aplicaciones que crea el usuario en soluciones corporativas de BI Enterprise Edition: esta edición ofrece una funcionalidad integral de centro de datos de gama alta. Puede manejar tipos de carga exigentes con un rendimiento rápido, a la vez que mantiene el tiempo de actividad y la protección de datos requeridos. Características de TI: Disponibilidad continua de SQL Server: proporciona un mayor tiempo de actividad, failover más rápido y un mejor uso de los recursos de hardware con una solución unificada de alta disponibilidad PowerView: crea e interactúa con vistas de datos de modelos de datos basados en libros de trabajo de PowerPivot y proporciona una creación de informes intuitiva y ad hoc xvelocity: usa almacenamiento en columnas con almacenamiento en caché de memoria, escaneo de datos altamente paralelos y algoritmos de agregación para impulsar el rendimiento en el warehousing de datos y Business Intelligence Data Quality Services: mejora la calidad de los datos mediante el uso de conocimientos organizativos y proveedores de datos de otros fabricantes a fin de determinar el perfil de los datos, limpiarlos y hacer que coincidan Componentes de SQL Server Windows Server SQL Server consta de cuatro componentes claves: Motor de base de datos de SQL Server: crea e impulsa bases de datos relacionales SQL Server Integration Services (SSIS): realiza el proceso de extracción, transformación y carga (ETL) para limpiar y dar formato a los datos crudos de sistemas de origen para las bases de datos como información lista para usar SQL Server Analysis Services (SSAS): es el componente de análisis de datos que crea cubos OLAP y minería de datos SQL Server Reporting Services (SSRS): proporciona una plataforma de creación de informes para crear, administrar e implementar informes tabulares gráficos de matriz La plataforma de base de datos está estrechamente relacionada con el sistema operativo. Microsoft Windows Server proporciona una infraestructura sólida para SQL Server. Microsoft Exchange: Mejores prácticas Storage y reglas Best de Practices diseño de and Microsoft Design Guidance SQL Server for para EMC el Storage 11 11

12 Tipos de volumen de Windows Los estilos de partición de volumen de Windows incluyen MBR y GPT: MBR: es el estilo de particionamiento existente, que permite un máximo de cuatro particiones. La tabla de partición se guarda solo al inicio del disco. GPT: es un estilo de particionamiento con la capacidad para administrar particiones de más de 2 TB. Su tabla de partición se guarda en múltiples ubicaciones. Se puede recuperar fácilmente si se daña alguna partición. Se admiten dos tipos de modos de discos: Básico: el disco más básico, que contiene las particiones primarias y, en caso de ser necesario, las particiones extendidas. Las características del modo básico incluyen: Partición primaria: una partición estándar que se puede iniciar. Partición extendida: una partición que no se puede iniciar. Es la cuarta partición en un disco MBR básico, que contiene particiones lógicas, de esta manera se permiten más de cuatro particiones. Partición lógica: una partición que no se puede iniciar y que está contenida en la partición extendida para ampliar el disco básico. Interfaz extensible del firmware (EFI): se usa para almacenar archivos de inicio en sistemas compatibles con EFI. Partición reservada de Microsoft (MSR): solo está disponible en discos básicos de GPT y se usa para reservar espacio para uso futuro. Dinámico: un disco dinámico es un administrador de volúmenes lógicos nativo basado en host, responsable de agregar discos a los volúmenes lógicos con múltiples opciones. Crea dos particiones; una que contiene todos los volúmenes dinámicos y otra oculta que contiene la base de datos de Logical Disk Manager (LDM). Esta base de datos se replica en todos los discos dinámicos del sistema para que se pueda recuperar. Puede alojar hasta 2,000 volúmenes dinámicos (se recomienda un máximo de 32). Las características del modo dinámico incluyen: Simple: volumen independiente Fraccionado: al igual que RAID 0, el volumen fraccionado escribe un bloque de datos para ambos discos. Los volúmenes que integran esta disposición deben tener el mismo tamaño. Distribuido: como RAID 0, con volúmenes concatenados. Si el disco falla, se perderá solo una parte de los datos. No es necesario que los volúmenes tengan el mismo tamaño. Tiene un rendimiento inferior al de los volúmenes fraccionados con la misma cantidad de discos. Espejeado: RAID 1 RAID: RAID 5 La Tabla 2 describe los volúmenes típicos que se crean en el almacenamiento de EMC y que se usan en el ambiente de SQL Server. Mejores prácticas y reglas de diseño de Microsoft SQL Server para el 12 12

13 Tabla 2. Partición de volumen Implementación típica de SQL Server para el Disco Volumen Tamaño de asignación Opciones de formato MBR Básico NTFS 64 kb Formato rápido* Nota: Como el arreglo de EMC brinda protección RAID de almacenamiento, se deben evitar en lo posible los discos dinámicos, ya que complican la administración del almacenamiento y la recuperación de desastres (DR) local y remota. Se requieren opciones de formato rápido para los LUN delgados. SMB 3.0 Server Message Block (SMB) 3.0 es una nueva versión del protocolo de uso compartido de archivos de red, permite que las aplicaciones en un equipo lean y escriban a los archivos y que soliciten servicios de programas de servidor en una red informática. SMB 3.0 se introdujo en Windows Server 2012 y SQL Server 2012 lo ha admitido como topología de almacenamiento viable para las bases de datos desde la versión RTM de SQL Server SQL Server 2012 es compatible con ambos discos virtualizados (VHD/VHDX) y las bases de datos alojadas directamente en los recursos compartidos de SMB 3.0. Los recursos compartidos se pueden presentar a Windows Server 2012 o a múltiples servidores en cluster. SMB 3.0 proporciona la capacidad de sobrellevar fallas de hardware que de otra manera causarían un impacto en el acceso a los archivos. EMC proporciona soporte total para SMB3.0 como topología de almacenamiento NFS para SQL Server. Consulte Storage Windows 2012 para obtener descripciones detalladas del almacenamiento de Windows. Arquitectura de SQL Server La Figura 1 muestra los cuatro componentes principales de la arquitectura de SQL Server: SQL OS, motor de almacenamiento, procesador de consultas y capa del protocolo. Microsoft Exchange: Mejores prácticas Storage y reglas Best de Practices diseño de and Microsoft Design Guidance SQL Server for para EMC el Storage 13 13

14 Figura 1. Arquitectura de SQL Server SQL OS es la capa de aplicación en el nivel más bajo del motor de base de datos de SQL Server. Se encarga de actividades como la calendarización, la detección de bloqueo y la administración de memoria. SQL Server administra sus recursos de memoria de manera dinámica. El pool de buffer es el componente principal de memoria en SQL Server. La memoria que no utilizan otros componentes de memoria permanece en el pool de buffer y se usará como caché de datos para las páginas que se lean desde los archivos de base de datos en el disco. El administrador de memoria administra las funciones de I/O del disco para incluir las páginas de datos y de índice al caché de datos, a fin de que los datos se puedan compartir entre usuarios. El motor de almacenamiento administra todo el acceso a datos a través de comandos de transacción y operaciones masivas. Tiene tres áreas clave: métodos de acceso, servicio de bloqueo y transacción y comandos de la utilería. La capa del procesador de consultas (motor relacional) acepta lotes T-SQL y determina qué hacer. Analiza, compila y optimiza las solicitudes de consulta T-SQL y monitorea el proceso de ejecución del lote. A medida que se ejecuta el lote, pasa una solicitud para los datos al motor de almacenamiento. El procesador de consultas tiene dos componentes: El optimizador de consultas y el ejecutor de consultas. El optimizador de consultas determina el mejor plan de ejecución. El ejecutor de consultas ejecuta la consulta. Mejores prácticas y reglas de diseño de Microsoft SQL Server para el 14 14

15 El procesador de consultas también administra la ejecución de consultas que solicitan datos del motor de almacenamiento y procesa los resultados obtenidos. El conjunto de filas Object Linking and Embedding Database (OLE DB) es el canal de comunicación entre el motor relacional y el motor de almacenamiento. El analizador de comandos maneja los eventos de idioma T-SQL que se envían a las instancias de SQL Server, comprueba la sintaxis adecuada y traduce los comandos T-SQL en un árbol de consulta. El optimizador de consultas toma la consulta y la prepara para su ejecución mediante la compilación del lote de comandos, la optimización de las consultas y la búsqueda de la mejor forma para procesarla en un plan de ejecución. El ejecutor de consultas pone en acción el plan de ejecución, que actúa como distribuidor para todos los comandos en el plan de ejecución. La capa del protocolo recibe la solicitud desde la aplicación del usuario y la traduce a una forma que pueda usar el motor relacional. También traduce los resultados de las consultas, los estados y los mensajes de error a un formato que el cliente pueda comprender. Componentes lógicos de SQL Server Microsoft SQL Server incluye dos componentes lógicos principales: Motor relacional (procesador de consultas), que se usa para verificar declaraciones SQL y seleccionar la manera más eficaz para recuperar los datos de la consulta Motor de almacenamiento, se usa para ejecutar solicitudes de I/O físicas y devolver la fila que solicitó el motor relacional Estos dos motores funcionan en conjunto para proporcionar integridad de datos para SQL Server. La arquitectura lógica de SQL Server define la forma en que se agrupan lógicamente los datos y se presentan a los usuarios. A continuación, se encuentran los componentes principales de esta arquitectura: Tablas: las tablas se forman con páginas de datos que se agregan de manera lógica (el formato básico para los datos). Las columnas y filas son los dos componentes principales de una tabla de SQL Server. Índices: un índice creado en una o más columnas de una tabla y asociado a una tabla o vista acelera la recuperación de datos. Se admiten índices agrupados y no agrupados en clusters. Una tabla puede tener un único índice agrupado en cluster que defina el orden en el que se almacenarán los datos en la tabla. Una tabla de montón es una tabla sin índice. Vistas: una vista puede ser una tabla virtual o una consulta almacenada. Los datos que regresan de una vista se almacenan en la base de datos a través de la declaración seleccionada. Procedimiento almacenado: un procedimiento almacenado es un grupo de declaraciones Transact-SQL compiladas en un único plan de ejecución. Restricciones, reglas y desencadenadores: son componentes que se usan para mantener el tipo de datos y la integridad de los datos de la tabla. Funciones definidas por el usuario: las funciones se usan para encapsular la lógica que se ejecuta frecuentemente. Desencadenadores: un desencadenador es similar a un procedimiento almacenado. Se adjunta a una tabla y se ejecuta solo cuando lo desencadena un comando INSERT, UPDATE o DELETE. Microsoft Exchange: Mejores prácticas Storage y reglas Best de Practices diseño de and Microsoft Design Guidance SQL Server for para EMC el Storage 15 15

16 Componentes físicos de SQL Server Los componentes físicos de SQL Server determinan la forma en que se almacenan los datos en el sistema de archivos del sistema operativo. Los archivos de bases de datos, de página, de extensión y los archivos de log de transacciones son los principales componentes físicos de SQL Server. Tipos de archivos Las bases de datos de SQL Server tienen los siguientes tipos de archivos: Los archivos de datos primarios tienen una extensión MDF. Una base de datos requiere al menos un archivo de datos primario. Los archivos de datos secundarios tienen una extensión NDF. Todos los archivos de datos en una base de datos que no sean archivos de datos primarios, son archivos de datos secundarios. No se requieren los archivos de datos secundarios y una base de datos puede tener varios archivos secundarios o ninguno. Los archivos de log tienen una extensión LDF. Contienen toda la información de log de transacciones necesaria para recuperar la base de datos. Cada base de datos tiene un archivo de log, sin importar la cantidad de archivos de datos. Datos de almacenamiento de los archivos de datos e información de índice. La Figura 2 representa la capa física de un único objeto de archivo de datos que muestra la relación de páginas y extensiones. Figura 2. Archivo de datos, página y extensiones Página y extensión Una página de SQL Server es la unidad básica del almacenamiento de datos lógicos. Con un tamaño de página de 8 kb (128 páginas por megabyte), cada página comienza con un encabezado de 96 bytes que contiene información del sistema sobre la página. El espacio de disco asignado al archivo de datos primario o secundario (.mdf o.ndf) se divide de manera lógica entre las páginas. Las operaciones de I/O del disco se realizan en el nivel de página. Mejores prácticas y reglas de diseño de Microsoft SQL Server para el 16 16

17 Las extensiones son las unidades básicas que administran el espacio. Cada extensión tiene ocho páginas físicamente adyacentes que son 64 kb (16 extensiones por megabyte). Una tabla o índice se asigna generalmente con páginas de extensiones combinadas. Las extensiones uniformes se usan para asignaciones posteriores, después de superar las ocho páginas. Log de transacciones El log de transacciones mantiene las modificaciones que realizan las transacciones dentro de los archivos de datos. Contiene información sobre los siguientes eventos: El inicio y término de cada transacción Modificación de datos Asignación y desasignación de extensión y página Creación y eliminación de una tabla o índice El log de transacciones es fundamental para recuperar las bases de datos durante una falla del sistema. Los registros de log se almacenan en una secuencia serial y cada registro contiene un identificador de transacción. Un único log físico de transacciones se segmenta lógicamente en logs virtuales según los algoritmos internos de SQL Server y el tamaño inicial del log de transacciones. Un log virtual dentro del archivo de log físico registra la información transaccional cuando comienza la actividad de transacciones. Grupo de archivos Un grupo de archivos de SQL Server se puede usar con el fin de separar archivos para tablas e índices; esto permite su ubicación selectiva en el nivel del disco. Puede: Separar tablas e índices en el nivel del disco Separar los objetos que requieren más archivos de datos debido a su alta tasa de asignación de páginas El administrador de la base de datos de SQL Server puede: Crear un respaldo en el grupo de archivos o en el nivel de los archivos. SQL Server tiene la capacidad para proporcionar disponibilidad parcial a un grupo de archivos específico. Puede permanecer en línea siempre y cuando el grupo de archivos primario esté en línea, incluso cuando otros grupos de archivos se encuentren offline. Un grupo de archivos está disponible si todos sus archivos también lo están. Usar grupos de archivos separados para los datos en fila y para los datos de grandes objetos en tablas e índices Usar un grupo de archivos para las tablas particionadas: Cada partición puede estar en su propio grupo de archivos Las particiones se pueden alternar dentro y fuera de la tabla para conseguir un mejor archiving Microsoft Exchange: Mejores prácticas Storage y reglas Best de Practices diseño de and Microsoft Design Guidance SQL Server for para EMC el Storage 17 17

18 Características de I/O y de ancho de banda de SQL Server Descripción general Es fundamental comprender el patrón y las características de I/O de SQL Server para el diseño y la implementación de aplicaciones de SQL Server. Un subsistema de I/O configurado correctamente puede optimizar el rendimiento de SQL Server. Existen dos tipos genéricos de tipos de carga de base de datos de SQL Server: OLTP y data warehouse/olap. Una base de datos de usuario específica podría generar un tipo de carga de I/O muy diferente a los del parámetro estándar. La única forma para determinar las necesidades de rendimiento de I/O es analizar la base de datos bajo una carga típica en tiempo real. OLTP Los tipos de carga OLTP producen muchas transacciones simultáneas con importantes lecturas y escrituras aleatorias de I/O (IOPS). Las bases de datos OLTP cambian constantemente. La mayoría de las aplicaciones ad hoc generan un tipo de carga OLTP. Según los artículos de Mejores prácticas de Microsoft SQL Server, los tipos de carga de bases de datos OLTP contienen los siguientes patrones: Las lecturas y escrituras que generan los archivos de datos tienen, por lo general, una naturaleza aleatoria. La actividad de lectura (en la mayoría de los casos) tiene una naturaleza constante. La actividad de escritura a los archivos de datos ocurre durante las operaciones de punto de comprobación (la frecuencia la determina la configuración del intervalo de recuperación). Las escrituras del log tienen una naturaleza secuencial y su tamaño varía según la naturaleza del tipo de carga (alineación del sector hasta 60 kb). Las lecturas del log tienen una naturaleza secuencial (alineación del sector hasta 120 kb). Las bases de datos OLTP tienen generalmente varias actividades de escritura que presionan al subsistema de I/O, en especial al LUN del log, ya que la escritura va primero al log de transacciones. Un sistema típico de OLTP tiene una gran cantidad de conexiones simultáneas que agregan y modifican los datos de manera activa, por ejemplo, en un sistema de reservas en línea de una aerolínea. Un sistema OLTP requiere que los logs de transacciones se respalden con frecuencia y aumenta las exigencias en el subsistema de I/O. En configuraciones que usan la replicación de transacciones, luego de que ocurra el snapshot, los datos posteriores cambian y las modificaciones que se hacen al esquema se entregan al suscriptor; esto impulsa más actividad de lectura para el log de transacciones en la base de datos del publicador. El uso de índice es otro factor que afecta al subsistema de I/O. Los sistemas OLTP altamente indexados pueden admitir un alto nivel de simultaneidad con baja latencia para recuperar una pequeña cantidad de filas de los conjuntos de datos que contienen pocos datos históricos. La volatilidad de las transacciones en un sistema OLTP podría requerir un mantenimiento frecuente de índices que ubique las solicitudes de lectura y escritura de gran actividad en el subsistema de I/O. Mejores prácticas y reglas de diseño de Microsoft SQL Server para el 18 18

19 Por lo general, los sistemas OLTP generan una gran cantidad de operaciones de entrada/salida por segundo (IOPS). Más unidades de disco admiten una mayor capacidad de IOPS. Base de datos de Data warehouse/olap Data warehousing suele ser la base de un sistema de toma de decisiones (DSS) o de un sistema Business Intelligence. Es un catálogo de los datos de una organización, diseñado para facilitar actividades complicadas de consultas analíticas mediante el uso de grandes conjuntos de datos para la creación de informes y análisis. Las bases de datos de data warehouse son del tipo Procesamiento analítico en línea (OLAP), que por lo general usan análisis complejos con datos agregados o resumidos en data warehouse. Los datos en el sistema data warehouse son generalmente estáticos, con lectura secuencial y muy poca actividad de escritura, a excepción de las típicas actualizaciones por lote. El ancho de banda de I/O es más importante que IOPS. El tipo de carga típico en un data warehouse tiene gran actividad de I/O, con operaciones como grandes cargas de datos y creación de índices, creación de vistas y consultas en grandes volúmenes de datos. El subsistema de I/O subyacente de data warehouse debe cumplir con estos requisitos de gran ancho de banda. Las características de I/O para data warehouse son: Lecturas y escrituras secuenciales, que generalmente son el resultado de escaneos de tabla o índice y de operaciones de inserciones masivas Datos no volátiles y conjuntos de datos históricos más grandes Índice ligero en la tabla de Hechos (Fact) Simultaneidad baja Gran actividad de Tempdb Variación en el tamaño de I/O: por lo general es superior a 8 kb. La lectura anticipada es cualquier múltiplo de 8 kb a 512 kb. Las operaciones de carga masiva son cualquier múltiplo de 8 kb a 128 kb. Cuando se usa la indexación de almacenamiento en columnas, el tamaño de la base de datos del archivo de I/O es bastante superior a 256 kb. Una consideración clave en cuanto al diseño de una solución de almacenamiento para data warehouse (DW) es equilibrar las funcionalidades del sistema DW a través de las capas de cómputo, redes y almacenamiento. Por ejemplo, la capa de cómputo debe tener la capacidad de procesar datos en tasas de ancho de banda que puede proporcionar el almacenamiento en niveles cómodos de utilización. A su vez, la creación de redes de capas de cómputo y almacenamiento debe bastar para mantener el máximo rendimiento posible entre las capas de cómputo y almacenamiento. Idealmente, para garantizar una solución DW rentable, un elemento de la solución no debe tener una funcionalidad excesiva sobre otro. Cuando se diseña un data warehouse, hay que calcular cuánto ancho de banda de I/O podrían usar potencialmente un determinado servidor y una tarjeta HBA, además de garantizar que la configuración de I/O seleccionada será capaz de satisfacer el requisito del servidor. Microsoft Exchange: Mejores prácticas Storage y reglas Best de Practices diseño de and Microsoft Design Guidance SQL Server for para EMC el Storage 19 19

20 Un sistema de data warehouse bien diseñado optimiza el sistema de almacenamiento para que realice operaciones centradas en el escaneo; el CPU del servidor puede recibir y procesar los datos que entrega el almacenamiento en el mismo ancho de banda. Como las consultas en data warehouse pueden recuperar millones de registros de la base de datos para su procesamiento, los datos suelen ser demasiado grandes para ajustarse a la memoria. Un buen diseño de almacenamiento debería ubicar y proporcionar los datos rápidamente desde el disco para que los procesadores puedan realizar la agregación y el resumen. Páginas de lectura Las lecturas de I/O del motor de base de datos de SQL Server son de los siguientes tipos: Lectura lógica: ocurre cuando el motor de base de datos solicita una página de la caché del buffer Lectura física: realiza una copia de la página del disco en la caché si la página no se encuentra actualmente en la caché del buffer El motor relacional se encarga de controlar las solicitudes de lectura y el motor de almacenamiento las optimiza. El mecanismo de lectura anticipada prevé las páginas de datos e índice necesarias para un plan de ejecución de consultas y agrega las páginas a la caché del buffer antes de que las utilice la consulta. Este mecanismo hace que sea posible sobrescribir el cómputo con las I/O para usar completamente la CPU y el disco, y optimizar el rendimiento. Páginas de escritura Las escrituras de I/O de una instancia del motor de base de datos son de los siguientes tipos: Escritura lógica: ocurre cuando se modifican los datos en una página en la caché del buffer Escritura física: ocurre cuando se escribe la página desde la caché del buffer al disco Las lecturas y escrituras de página ocurren en la caché del buffer. Cada vez que se modifica una página en la caché del buffer, se marca como desfasada. Una página puede tener más de una escritura lógica antes de escribirse físicamente en el disco. Los registros de log se deben escribir en el disco antes de escribir en el disco la página desfasada asociada. Para garantizar la coherencia de datos, SQL Server usa el registro de escritura previa, con el fin de evitar que se escriba una página desfasada antes de escribir el registro de log asociado en el disco. La Figura 3 muestra la operación de escritura de página en SQL Server. Figura 3. Operación de escritura de página en SQL Server Mejores prácticas y reglas de diseño de Microsoft SQL Server para el 20 20

21 Una página desfasada se escribe en un disco de una de las siguientes formas: Escritura diferida: es un sistema de proceso que mantiene disponibles los buffer libres gracias a la eliminación de páginas que se usan rara vez de la caché del buffer. Las páginas desfasadas se escriben en primer lugar en el disco. Escritura diligente: este proceso de sistema escribe páginas desfasadas con operaciones sin registro, como la inserción masiva o selección. Punto de comprobación: la operación de punto de comprobación escanea de forma periódica la caché del buffer en busca de páginas de base de datos y escribe todas las páginas desfasadas en el disco. Los procesos de escritura diferida, escritura diligente y de punto de comprobación usan I/O asíncrona, que permite que el hilo de ejecución que llama continúe con el procesamiento mientras la operación de I/O se realiza en segundo plano para maximizar los recursos de CPU y de I/O para las tareas adecuadas. Log Manager Uso de Tempdb Patrones de I/O El tipo de carga del log es la I/O en función del log de transacciones. Por lo general tiene escrituras secuenciales y requiere una baja latencia para tipos de carga de transacción de gran escala. Las escrituras del archivo de log de transacciones son síncronas para una transacción determinada, ya que SQL Server elimina todas las actualizaciones asociadas a una transacción asignada al log antes de que el hilo de ejecución del usuario pueda comenzar la siguiente transacción. Tempdb es una base de datos de sistema que utiliza SQL Server como espacio de trabajo temporal. El patrón de I/O para Tempdb es similar a los patrones OLTP. Según el tipo de carga, la Tempdb puede variar de una actividad baja (en tipos de carga del tipo OLTP) a una extremadamente alta (tipos de carga DSS u OLAP). La Tabla 3 resume los patrones de I/O involucrados en cada tipo de base de datos. Tabla 3. Tipos y características de I/O Archivos de datos Patrones de I/O de diferentes tipos de carga para una base de datos de SQL Server Archivo de base de datos del procesamiento de transacciones en línea (OLTP) I/O más pequeñas y aleatorias (de 8 a 64 kb) Alta proporción de lecturas en comparación con las escrituras (por lo general, una tasa de lectura/escritura entre 90/10 y 70/30) Por lo general, se puede conseguir un alto rendimiento y protección con RAID 10. Con el almacenamiento en niveles, se puede usar RAID 5 o RAID 6 en el pool de almacenamiento para proporcionar el rendimiento necesario. Decision Support System (data warehouse, OLAP) I/O más grandes y secuenciales (principalmente de 64 kb y pueden ser de más de 256 kb con el índice de almacenamiento en columnas) Baja proporción de escrituras en comparación con las lecturas, a veces de solo lectura RAID 5 suele proporcionar el rendimiento adecuado y mucho más espacio utilizable para una cantidad determinada de discos Microsoft Exchange: Mejores prácticas Storage y reglas Best de Practices diseño de and Microsoft Design Guidance SQL Server for para EMC el Storage 21 21

22 Tipos y características de I/O Archivo de log de la base de datos Archivo de datos de Tempdb Archivo de base de datos del procesamiento de transacciones en línea (OLTP) Decision Support System (data warehouse, OLAP) I/O pequeñas y altamente secuenciales (algunas múltiples de 512 bytes) Casi exclusivamente escrituras, con lecturas ocasionales durante grandes reversiones o respaldos de log Se recomienda RAID 1/0 para los logs. RAID 5 también podría brindar un rendimiento adecuado (debido a las escrituras en fracciones completas). Es posible que disminuya el rendimiento cuando haya una falla de una unidad (la disminución del rendimiento se puede ignorar en el caso de discos flash). La variación de tamaño depende del uso (por lo general, son I/O de mayor tamaño que no exceden los 64 kb) I/O seriales o aleatorias, un tipo de carga determinado podría ser algo secuencial, muchos tipos de carga que se ejecutan simultáneamente podrían dar una apariencia de I/O aleatoria a la Tempdb Generalmente, una división con un 50 % de escrituras y un 50 % de lecturas Basado en la naturaleza impredecible de la Tempdb y en combinación con su habitual proporción alta de escrituras, RAID 1/0 suele proporcionar el mejor rendimiento para una cantidad determinada de discos. De manera similar a los archivos de log, RAID 5 también podría brindar el rendimiento adecuado, en especial cuando se usan los discos flash. La actividad de Tempdb varía. Por lo general, no es muy activa cuando hay exigencias bajas de rendimiento. Puede ser muy activa para la creación frecuente de informes y para grandes combinaciones de tablas. Tempdb puede exigir un alto rendimiento que requiera almacenamiento flash del lado del servidor, como XtremSF. Mejores prácticas y reglas de diseño de Microsoft SQL Server para el 22 22

23 Mejores prácticas para el dimensionamiento y el aprovisionamiento del almacenamiento de SQL Server Descripción general El diseño del almacenamiento es uno de los elementos más importantes para conseguir una implementación exitosa de Microsoft SQL Server. Para lograr un diseño de almacenamiento que consiga los niveles óptimos de confiabilidad, rendimiento, costo y facilidad de uso, es necesario seguir las reglas recomendadas para el almacenamiento. Esta sección proporciona las mejores prácticas generales para la implementación de SQL Server en el, como el almacenamiento de la serie Symmetrix VMAX, el almacenamiento unificado de VNX, XtremSF y XtremSW Cache, además de recomendaciones para características específicas del arreglo de con SQL Server. Ya que la virtualización de un ambiente de SQL Server requiere su propio conjunto de consideraciones, esta sección también incluye orientación al respecto. Mejores prácticas generales del almacenamiento de SQL Server EMC recomienda que comience con un diseño de SQL Server con cinco LUN, como se muestra en la Figura 4 y ampliarse según los requisitos de rendimiento de la aplicación. Figura 4. La configuración de SQL Server En el caso de la configuración de SQL Server, hay que considerar primero los siguientes requisitos básicos: Archivos binarios del sistema operativo y de SQL Server En una implementación típica de SQL Server, el servidor es para uso exclusivo de SQL Server y los archivos binarios están en el mismo LUN que el sistema operativo. Siga la recomendación de Microsoft para el tipo de sistema operativo y versión de SQL Server y tenga en cuenta la sobrecarga para las aplicaciones que necesita instalar en ese servidor. Los LUN típicos para las bases de datos de los archivos binarios del sistema operativo, de SQL Server y del sistema son de 60 a 120 GB. Por lo general, esta necesidad la pueden cubrir los discos de alta capacidad y bajo rendimiento de un pool de almacenamiento de RAID 5. Microsoft Exchange: Mejores prácticas Storage y reglas Best de Practices diseño de and Microsoft Design Guidance SQL Server for para EMC el Storage 23 23

24 Bases de datos del sistema En la mayoría de los ambientes, las bases de datos de sistema no suelen modificarse o cambiarse y pueden ubicarse en el mismo LUN que el sistema operativo. Logs para las bases de datos de usuarios Los logs para las bases de datos de usuarios generalmente necesitan IOPS bajos (principalmente escrituras secuenciales). Incluso con una replicación como el grupo de disponibilidad continua (AAG), los IOPS que se necesitan en estos LUN no suelen ser muy exigentes. De esta manera, los LUN de logs se configuran generalmente con discos de Fibre Channel (en un pool de almacenamiento puede estar anclado en el nivel de Fibre Channel) que pueden satisfacer la necesidad de capacidad con al menos un 10 % de espacio extra. Tempdb En un ambiente OLTP, es posible que la Tempdb no exija muchas I/O y que pueda seguir el mismo principio de diseño que los logs. En este caso, generalmente se encuentran en el mismo pool que los LUN de logs de la base de datos de SQL Server. Cuando se lleva a cabo la creación de informes calendarizada o ad hoc, o grandes combinaciones de tablas, la Tempdb podría experimentar un uso intensivo. Tiene que medir las necesidades del sistema SQL para determinar el uso de Tempdb. Una Tempdb en un data warehouse o para tipos de carga OLAP suele tener grandes exigencias de I/O y garantiza una atención especial en estos ambientes. El diseño de la Tempdb en estos ambientes debe seguir el principio de diseño de la base de datos en cuanto a dimensionamiento y ubicación, en caso de ser necesario. Base de datos de usuario Por lo general, los LUN de la base de datos de usuario son el enfoque principal para el diseño del almacenamiento. Los tipos de LUN varían según los requisitos de rendimiento y capacidad, así como el tipo de carga. Siga las mejores prácticas generales para el almacenamiento de SQL Server de Microsoft TechNet. A continuación, se muestran algunos puntos clave: Mejores prácticas básicas para SQL Server Las siguientes son algunas de las mejores prácticas básicas para SQL Server: Seleccione la política Lock pages in memory (Bloquear páginas en la memoria) para la cuenta de inicio de SQL Server y para evitar que SQL Server intercambie memoria. Asigne los archivos de datos previamente para evitar el Crecimiento automático durante los tiempos de mayor actividad. Establezca la Reducción automática como desactivada para los archivos de datos y de log. Cree archivos de datos de igual tamaño en la misma base de datos. SQL Server usa un algoritmo de relleno proporcional que favorece a las asignaciones en archivos con más espacio libre. Lleve a cabo un mantenimiento rutinario con una reconstrucción de índice o reorganización mediante el comando dbcc checkdb. Mejores prácticas y reglas de diseño de Microsoft SQL Server para el 24 24

25 Consideraciones de archivos y grupos de archivos Las siguientes son consideraciones sobre el grupo de archivos en SQL Server: Se puede acceder a los grupos de archivos en paralelo. Ubicar grupos de archivos en diferentes conjuntos de discos o pools de almacenamiento puede mejorar el rendimiento. Organice los archivos de datos de SQL Server que tengan necesidades similares de rendimiento y protección en un grupo de archivos en el momento de diseñar una base de datos. Para asignar bases de datos con gran actividad como la Tempdb, cree de 0.25 a 1 archivo de datos por grupo de archivos para cada CPU, cuando sea necesario. Comience con una cantidad pequeña de archivos de datos. Aumente la cantidad a medida que sea necesario. Cree un archivo de log en un ambiente típico. Más archivos de log no mejorarán el rendimiento. Consulte Uso de archivos y grupos de archivos en la Microsoft MSDN Library para obtener más información. Mejores prácticas básicas para el almacenamiento A continuación, se presentan algunas de las mejores prácticas básicas para el diseño del almacenamiento. Los detalles se analizan en la Consideraciones generales para el almacenamiento. Planificación para el rendimiento, la capacidad y la protección. La Tabla 4 enumera los tiempos de respuesta para el archivo de datos y para los archivos de log. Tabla 4. Tiempos de respuesta para el archivo de datos y para los archivos de log Tiempo de respuesta de I/O Archivo de datos registro Muy bueno Menos de 10 ms Menos de 5 ms Aceptable De 10 a 20 ms De 5 a 15 ms Necesita investigación y mejoras Superior a 20 ms Superior a 15 ms Al crear un volumen en Windows, establezca la unidad de asignación de Windows en 64 kb para la base de datos de SQL Server y los LUN de logs. Para conseguir un rendimiento óptimo con un nivel de servicio predecible, ubique la Tempdb, los datos y los archivos de log en diferentes LUN. Para dejar espacio para el crecimiento de datos, evite sobrepasar el 80 % de la capacidad de los LUN para los archivos de base de datos. Ubique los LUN para los archivos de datos en unidades más rápidas o use la organización automática en niveles para ubicarlos. Ubique los LUN para los archivos de log en discos SAS o Fibre Channel sin usar la organización automática en niveles. Use drivers HBA actualizados y recomendados por el fabricante. Asegúrese de que el firmware del arreglo de almacenamiento esté actualizado. Microsoft Exchange: Mejores prácticas Storage y reglas Best de Practices diseño de and Microsoft Design Guidance SQL Server for para EMC el Storage 25 25

26 Considere el uso de múltiples rutas para lograr más disponibilidad/ redundancia y para mejorar la optimización, en especial para configuraciones basadas en iscsi o en archivos. Consideraciones sobre la agrupación en clusters La protección es necesaria para una Tempdb en SQL Server. El archivo Tempdb se vuelve a crear cada vez que se inicia una instancia de SQL Server. En los ambientes XtremSF, VPLEX y Cluster Enabler (CE) las particiones de disco no compartidas se pueden usar para la Tempdb en un cluster FCI de SQL Server 2012 cuando sea posible para reducir los costos y el ancho de banda. Consideraciones para las versiones anteriores Tenga presente lo siguiente para el uso de versiones anteriores de SQL Server y Windows: Para SQL Server 2005 y versiones anteriores, active el privilegio de Windows Instant File Initialization otorgando privilegios a la cuenta de inicio de SQL Server. Para versiones de Windows anteriores a Windows 2008, verifique que la configuración de alineación de sector sea la correcta. Windows 2008 y las versiones superiores alinean los sectores de manera predeterminada. Consideraciones generales para el almacenamiento Consideraciones de rendimiento frente a capacidad Cuando implemente Microsoft SQL Server, considere siempre los requisitos de rendimiento, protección y capacidad. Para los tipos de carga típicos de OLTP, es probable que las mediciones de rendimiento en IOPS superen el requisito de capacidad para los archivos de base de datos y para los archivos de log. Los archivos de la Tempdb están generalmente enlazados a la capacidad, debido a la naturaleza baja de I/O del tipo de carga. En un ambiente OLAP, las mediciones de ancho de banda en megabytes o gigabytes son más dominantes para los archivos de bases de datos, mientras que es probable que los archivos de la Tempdb requieran un rendimiento superior (IOPS). Los archivos de logs y de bases de datos de usuarios deben estar bien protegidos para evitar la pérdida de datos. Debido a que el archivo de la Tempdb contiene solo datos temporales y se puede volver a crear con el inicio de SQL Server, la protección de la Tempdb no se considera de prioridad alta. Cuando el rendimiento de la Tempdb es crítico (como en el ambiente OLAP), es ideal que la Tempdb use un disco flash de servidor como XtremSF para minimizar la latencia de almacenamiento. Al momento de diseñar almacenamiento para diferentes tipos de carga, tenga en cuenta el tipo de carga y su patrón típico de I/O en los archivos de base de datos, de log y de la Tempdb. Calcule los requisitos de rendimiento y capacidad para asegurarse de cumplir con ambos. Selección del tipo de disco Una de las primeras decisiones clave que debe tomar cuando diseña el almacenamiento de SQL Server es la selección del tipo o tipos de discos que se adapten mejor a sus necesidades. Los tipos de discos que son adecuados para su implementación de SQL Server dependen de varios factores, como el tamaño de su base de datos y los requisitos IOPS. Mejores prácticas y reglas de diseño de Microsoft SQL Server para el 26 26

27 La Table 5 muestra los tipos de discos que ofrece EMC con su familia VNX de almacenamiento unificado y con el almacenamiento de la serie Symmetrix VMAX. También se usa flash como XtremSF y XtremSW Cache. Tabla 5. Tipos de disco que ofrece EMC Tipo de disco Características Consideración de la selección Fibre Channel (FC) Unidades de disco confiables con velocidades altas de lectura/escritura. Ideal para los altos requisitos de I/O, aunque podría no ser adecuado para los requisitos de alta capacidad Disco SAS SATA SAS NL (NL-SAS) Flash Como una mejora de los discos tradicionales SCSI, los discos SAS proporcionan alta capacidad con una velocidad de I/O moderada. Discos de gran capacidad con una velocidad de I/O menos exigente. Tal como con los discos SATA, los discos SAS NL son una buena opción para una I/O menos exigentes pero con grandes requisitos de capacidad. Los discos flash tienen la velocidad de I/O más alta con un bajo consumo de energía. Sumamente adecuados para los ambientes de SQL Server con altos requisitos de IOPS. Adecuados para bases de datos grandes con bajos requisitos de I/O. Son más adecuados para data warehouse y bases de datos de contenido de SharePoint Los discos SAS NL pueden admitir bases de datos grandes a un costo relativamente bajo. Los discos SAS NL suelen ser la mejor opción para las bases de datos grandes con perfiles bajos de I/O. En general, los discos flash se pueden usar de la siguiente manera: En el arreglo de almacenamiento como parte de las características de la organización en niveles de almacenamiento automática, como EMC FAST VP o FAST Cache para manejar cualquier imprevisto de I/O. En servidores como XtremSF o XtremSW Cache EMC también proporciona un arreglo de solo flash XtremIO para el ambiente de SQL Server más exigente. Siga las siguientes reglas generales cuando seleccione los tipos de disco: Para los requisitos de IOPS bajos, de latencia de disco aceptable y de alta capacidad de la base de datos, use discos SATA o SAS NL. Para los requisitos de IOPS altos, de latencia de disco baja y de alta capacidad de la base de datos, use discos de Fibre Channel o SAS de gran capacidad. Para requisitos superiores de IOPS, de latencia de disco muy baja y requisitos inferiores de capacidad de base de datos, use discos flash en la organización en niveles de almacenamiento o FAST Cache. Para los requisitos más exigentes de IOPS y latencia de disco y requisitos inferiores de capacidad de base de datos, use XtremSF y XtremSW Cache. Microsoft Exchange: Mejores prácticas Storage y reglas Best de Practices diseño de and Microsoft Design Guidance SQL Server for para EMC el Storage 27 27

28 Los diferentes tipos de discos admiten diferentes IOPS con el mismo requisito de latencia. Considere esto cuando calcule los requisitos de disco para su ambiente. La siguiente tabla proporciona datos de IOPS de disco aleatorio desde la validación más reciente de SQL Server en el VNX y VMAX. Estos resultados están sujetos a cambios según pruebas futuras. Nota: EMC recomienda enfáticamente usar los valores de la Tabla 6 para calcular los requisitos de IOPS para la implementación de SQL Server en arreglos de almacenamiento de VNX y VMAX. Estos números servirán de base para el rendimiento típico aceptable que se muestra en la Tabla 4. Para las aplicaciones que requieren un mejor rendimiento, agregue más discos o use almacenamiento en caché del arreglo como FAST Cache o almacenamiento en caché del servidor como XtremSW Cache. Tabla 6. IOPS para I/O de lectura aleatoria de 8 kb en varios tipos de discos en el arreglo de Tipo de disco IOPS por disco Disco SAS de 15,000 r/min 180 Disco SAS de 10,000 r/min 140 Discos SAS NL de 7,200 r/min 70 Disco de estado sólido (SSD) 3,500 La Tabla 7 describe los IOPS para flash de servidor. Tabla 7. IOPS aleatorias de 8,000 IOPS de SQL Server para modelos XtremSF XSF550 MLC * XSF550 MLC * XSF2200 MLC * XSF2200 MLC * XSF320 SLC XSF700 SLC Lectura 131, , , , , ,906 Escritura 23,592 16,235 53,713 35,654 67, ,593 Lectura/es critura (70/30) 56,255 42, ,162 93, , ,169 * En el modo de rendimiento. Los IOPS serán inferiores si se configuran en el modo de capacidad predeterminado. Pools y tipos de RAID Seleccionar el tipo adecuado de RAID para su ambiente es otra decisión importante para conseguir una implementación exitosa de SQL Server. Es posible usar cualquier tipo de RAID si hay suficientes discos disponibles para manejar las I/O y los requisitos de capacidad de almacenamiento. En general, las decisiones del tipo de RAID se basan en un conjunto de requisitos determinados. Para seleccionar un tipo de RAID adecuado para su ambiente, considere sus requisitos específicos de rendimiento, capacidad y disponibilidad. Mejores prácticas y reglas de diseño de Microsoft SQL Server para el 28 28

29 Nivel de RAID RAID 1/0 Los sistemas de son compatibles con RAID 1/0, RAID 5 y RAID 6 con el uso de discos flash, Fibre Channel, SAS, SAS NL y SATA. Cada tipo de RAID proporciona diferentes niveles de rendimiento, capacidad y protección. RAID 1/0. Brinda protección de datos mediante el espejeado de datos en otro disco. Esto produce un mejor rendimiento y un impacto mínimo o inexistente en el rendimiento en el caso de falla de discos. En general, RAID 1/0 es la mejor opción para SQL Server, en especial si se utilizan discos SATA o SAS NL. RAID 5. Sus datos se fraccionan en discos en tamaños grandes de fracciones. La información de paridad se almacena en todos los discos para poder reconstruir los datos. Esto puede entregar protección en caso de una falla de disco único. Con su alta penalidad de escritura, RAID 5 es más adecuado para los ambientes con I/O que son principalmente de lectura y donde se implementen grandes bases de datos. En el caso de los discos flash SSD, esta preocupación de rendimiento se elimina y la mayoría de los ambientes con discos flash se pueden configurar como RAID 5 para admitir los altos requisitos de I/O con latencia de disco muy baja. RAID 6. Sus datos también se fraccionan en discos en tamaños grandes de fracciones. Sin embargo, se almacenan dos conjuntos de información de paridad en todos los discos para que los datos se puedan reconstruir en caso de ser necesario. RAID 6 puede aceptar la falla simultánea de dos discos sin pérdida de datos. La Tabla 8 muestra la información de sobrecarga de RAID, rendimiento y utilización de almacenamiento para cada tipo de RAID. Nota: El valor de sobrecarga de RAID adquiere importancia cuando se realizan cálculos de I/O para la cantidad de discos requeridos. RAID 5 y RAID 6 afectan el rendimiento cuando falla un disco y se debe reconstruir. En la Tabla 8, se compara al rendimiento con la misma cantidad y el mismo tipo de discos en las configuraciones de RAID. La utilización de almacenamiento se compara con los mismos tipos de discos en las configuraciones de RAID para generar los mismos IOPS con una latencia similar. Tabla 8. Aleatorio Lectura Características de rendimiento del nivel de RAID Escritura aleatoria Lectura secuencial Escritura secuencial Valor de sobrecarga de la escritura de RAID Excelente Excelente Excelente Excelente 2 Baja RAID 5 Excelente Moderado Bueno Moderado 4 Alta RAID 6 Bueno Deficiente Bueno Moderado 6 Media Utilización del almacenamiento Los pools de almacenamiento son construcciones virtuales que permiten que los datos se transfieran dinámicamente a través de diferentes niveles de unidades (desde un alto rendimiento hasta menores costos/alta capacidad y viceversa), según la actividad comercial de los datos. Con los sistemas VNX y VMAX, los pools de almacenamiento están completamente automatizados y cuentan con autoadministración. Microsoft Exchange: Mejores prácticas Storage y reglas Best de Practices diseño de and Microsoft Design Guidance SQL Server for para EMC el Storage 29 29

30 El uso de pools de almacenamiento simplifica el aprovisionamiento de almacenamiento. El aprovisionamiento basado en pools proporciona beneficios similares al fraccionado de metalun en varios discos, pero a diferencia de los metalun, los pools de almacenamiento requieren una planificación mínima y esfuerzos de administración. Los pools de almacenamiento admiten los mismos niveles de protección RAID que los grupos de RAID: RAID 5, RAID 6 y RAID 1/0. Los pools de múltiples niveles con diferentes RAID y tipos de discos pueden estar en el mismo pool de almacenamiento. Los pools de almacenamiento también proporcionan servicios de datos avanzados como FAST VP, compresión, deduplicación y opciones de protección de datos como VNX Snapshots. La mayoría de los ambientes de base de datos de SQL Server se pueden beneficiar de las configuraciones basadas en pool de almacenamiento. Consideraciones para el aprovisionamiento virtual del almacenamiento Los sistemas EMC VMAX y VNX ofrecen aprovisionamiento virtual, que en el sector se conoce generalmente como aprovisionamiento delgado. El aprovisionamiento virtual o delgado puede simplificar la administración de almacenamiento y reducir los costos de almacenamiento mediante el aumento en la utilización de la capacidad para varios casos de uso de SQL Server. El aprovisionamiento virtual permite que SQL Server adquiera más capacidad que la asignada físicamente. El almacenamiento físico se asigna a la base de datos según demanda desde un pool compartido, según sea necesario. La capacidad de almacenamiento físico se asigna por completo durante la creación de LUN para LUN gruesos. Aunque los LUN delgados tienen menos capacidad de almacenamiento físico asignada a ellos en un comienzo, el pool de almacenamiento proporciona almacenamiento físico real que admite asignaciones de LUN delgados cuando es necesario. El almacenamiento físico se asigna automáticamente solo cuando se escriben nuevos bloques de datos en el LUN delgado. Los LUN gruesos y delgados pueden proporcionar las características requeridas de rendimiento para cualquier tipo de carga de SQL Server. LUN delgado frente a LUN grueso Los dispositivos delgados pueden crearse con capacidad ampliada, porque el espacio de almacenamiento real para los datos escritos en ellos proviene de los dispositivos de datos. Para un sistema operativo de host, los dispositivos delgados tienen la misma capacidad configurada que los dispositivos estándares y el host interactúa con ellos de la misma manera que con los dispositivos estándares. El LUN delgado se puede usar en la mayoría de los ambientes con rendimiento razonable, en especial con FAST VP (VNX y VMAX) y/o con FAST Cache (en VNX). Las principales consideraciones de rendimiento relacionadas con los LUN delgados son: Los LUN delgados proporcionan ahorros de almacenamiento considerables y se adaptan al crecimiento futuro. Hay una pequeña sobrecarga de almacenamiento cuando se amplía un LUN para admitir las escrituras entrantes. Mejores prácticas y reglas de diseño de Microsoft SQL Server para el 30 30

31 En resumen, cuando decida usar pools de almacenamiento, LUN delgados, LUN gruesos o RAID para la configuración de LUN, considere lo siguiente: Use pools de almacenamiento para aprovechar los servicios de eficiencia de datos (como FAST VP), la compresión, la deduplicación y otras opciones basadas en pool. Use LUN delgados con los pools para conseguir una configuración y administración sencilla, mejor eficiencia de espacio, ahorros de energía y capital y bases de datos con consumo flexible de espacio con el paso del tiempo. Use LUN gruesos para las bases de datos que tienen requisitos predecibles de espacio. Use grupos de RAID y LUN tradicionales para las bases de datos que no requieren modificar los requisitos de tamaño y rendimiento con el paso del tiempo, para ubicar de forma precisa los objetos de datos lógicos en discos físicos y para separar los datos físicamente. Mejores prácticas para el dimensionamiento del almacenamiento Las características de rendimiento de SQL Server pueden variar considerablemente entre un ambiente y otro, según la aplicación. Estas características se dividen en dos categorías generales: OLTP genera principalmente tipos de carga de lectura aleatorias y data warehouse genera principalmente tipos de carga de lectura secuenciales, como se describe en la Tabla 9. En un ambiente OLTP, use IOPS de lectura/escritura para el dimensionamiento del almacenamiento. Para un ambiente de data warehouse, use ancho de banda (MB/s) para el dimensionamiento del almacenamiento. Para obtener cálculos de rendimiento precisos, ejecute pruebas en condiciones que sean lo más cercanas posible al mundo real. Durante estas pruebas, use logs de monitor de rendimiento para capturar las características (como IOPS: lecturas por segundo y escrituras por segundo, ancho de banda: MB/s) de los volúmenes que se usan para almacenar archivos de base de datos. Notas: No use contadores de IOPS que se promedien con el paso del tiempo para el diseño del almacenamiento. EMC recomienda identificar el percentil 90 de las muestras de IOPS y realizar el diseño para ese nivel de rendimiento. Esto permite que el sistema responda bien a los imprevistos según demanda. Los requisitos de IOPS para un grupo RAID se deben calcular de forma independiente para lecturas y escrituras. Consideraciones para el dimensionamiento de la base de datos OLTP Dimensionamiento para el rendimiento Calcule el número de discos para la necesidad de rendimiento con la siguiente fórmula: Cantidad de discos = IOPS de lectura + (IOPS de escritura x sobrecarga de rendimiento de RAID) IOPS por disco Nota: Es posible que deba ajustar el conteo de discos para cumplir con los requisitos para el nivel RAID seleccionado. Por ejemplo, no puede haber un conjunto RAID 1/0 de siete discos. En esos casos, se requiere un conjunto RAID 1/0 de ocho discos. IOPS por Disco es la cantidad de IOPS del tipo de unidad seleccionado. Microsoft Exchange: Mejores prácticas Storage y reglas Best de Practices diseño de and Microsoft Design Guidance SQL Server for para EMC el Storage 31 31

32 La Tabla 6 en Selección del tipo de disco proporciona los IOPS por disco para los diferentes tipos de discos que se recomiendan a fin de calcular las necesidades de disco de la configuración RAID y la configuración del almacenamiento en niveles. En el caso de la configuración del almacenamiento en niveles, también debe calcular los requisitos de capacidad para diferentes niveles. Las siguientes herramientas pueden ayudar en el diseño del almacenamiento en niveles: EMC Storage Configuration Advisor para el dimensionamiento Necesita datos históricos del rendimiento de los arreglos de almacenamiento. Para obtener más información, consulte el sitio web de EMC. Herramienta de evaluación del rendimiento del tipo de carga También conocida como Mitrend, muestra el mapa de puntos problemáticos de FAST VP. Para obtener más información, visite Herramienta para dimensionamiento de VSPEX (VNX) Para obtener más información, consulte (visite el sitio web de su país correspondiente). Dimensionamiento para la capacidad Una vez finalizado el dimensionamiento de rendimiento, debe considerar el requisito de capacidad del almacenamiento. Aunque el dimensionamiento típico para la base de datos OLTP tiende a vincularse con el rendimiento, compruebe el requisito de capacidad antes de que se complete el diseño final. Calcule el dimensionamiento para la capacidad según la configuración de la Tabla 9. Tabla 9. Tipo de RAID Dimensionamiento para la capacidad Sobrecarga de RAID para la capacidad Sobrecarga de RAID para el rendimiento (penalización de escritura) Unidades mínimas Discos mínimos requeridos para el tamaño de LUN 1/0 1/ tamaño de LUN 5 4/ /4 tamaño de LUN 6 4/ /4 tamaño de LUN Use la siguiente fórmula para calcular la cantidad de discos para la capacidad: Cantidad de discos = Capacidad total necesaria Sobrecarga de RAID para la capacidad Nota: En el momento de calcular el tamaño de LUN, considere el crecimiento futuro del tamaño de la base de datos. Le recomendamos reservar al menos un 10 % de la capacidad para los LUN de archivos de bases de datos. Diseño final Use el número más grande como el dimensionamiento final para satisfacer los requisitos de rendimiento y capacidad. Mejores prácticas y reglas de diseño de Microsoft SQL Server para el 32 32

33 Mejores prácticas para el dimensionamiento de FAST VP Por lo general, un pequeño porcentaje de la capacidad utilizada es el responsable de la mayoría de la actividad de I/O en una base de datos determinada. A esto se le conoce como desviación entre tipos de carga. El análisis de un perfil de I/O podría indicar que el 85 % de I/O a un volumen involucra solo el 15 % de la capacidad. La capacidad activa resultante se denomina conjunto de trabajo. Los software como FAST VP y FAST Cache pueden mantener al conjunto de trabajo en el nivel de rendimiento más alto. Las siguientes son algunas de las mejores prácticas para el dimensionamiento de FAST VP: Idealmente, el conjunto de trabajo debe estar en el nivel más alto (Fibre Channel/SAS/flash). Un conjunto de trabajo típico para un tipo de carga OLTP es de un 10 % a un 30 % del archivo de la base de datos. Dimensione el nivel superior en FAST VP para asegurarse de que el conjunto de trabajo se pueda migrar al nivel de rendimiento más alto. Las unidades de nivel de rendimiento de FAST VP son versátiles en el manejo de una amplia gama de perfiles de I/O. Por lo tanto, EMC recomienda tener unidades de nivel de rendimiento en cada pool. Las unidades de alta capacidad pueden ayudar a optimizar el costo total de propiedad y a menudo componen de un 60 % a un 80 % de la capacidad de un pool. Los perfiles con un bajo IOPS/GB y/o tipos de carga secuenciales pueden usar una gran cantidad de unidades de alta capacidad en un nivel más bajo. Es importante determinar la desviación de I/O antes del dimensionamiento de los niveles FAST VP. La desviación de SQL puede variar y depende del perfil real de SQL Server. Use solo dos niveles para la mayoría de las tareas de dimensionamiento de VNX: un nivel de rendimiento (Fibre Channel/SAS/flash) y un nivel de capacidad (SATA/SAS NL). Suponga un tipo de carga OLTP con una desviación de 85/15 y realice ajustes según el ambiente real: El 85 % de I/O con el 15 % de capacidad en el nivel de rendimiento (Fibre Channel/SAS/flash) El 15 % de I/O con el 85 % de datos en el nivel de capacidad (SATA/SAS NL) En VMAX, puede haber hasta tres niveles. Con un tipo de carga OLTP, suponga una desviación activa/semiactiva/inactiva de 75/15/10 para la I/O y luego realice ajustes según el ambiente real: El 10 % de I/O y el 75 % de la capacidad en SATA El 15 % de I/O y el 15 % de la capacidad en Fibre Channel El 75 % de I/O y el 10 % de la capacidad en flash Los servicios profesionales de EMC y los partners calificados le pueden ayudar a conseguir un dimensionamiento adecuado para los niveles y pools con el fin de maximizar la inversión. Cuentan con las herramientas y la experiencia para hacer recomendaciones específicas sobre la composición de los niveles, basándose en un perfil existente de I/O. Microsoft Exchange: Mejores prácticas Storage y reglas Best de Practices diseño de and Microsoft Design Guidance SQL Server for para EMC el Storage 33 33

34 Dimensionamiento para el rendimiento Los IOPS y el cálculo de disco son igual al que proporciona el grupo RAID con desviación: Número de discos por nivel = IOPS de lectura + (IOPS de escritura sobrecarga de rendimiento de RAID) Desviación de I/O por nivel IOPS por disco Nota: Cada nivel se debe redondear al siguiente conteo de unidades lógicas, así como el nivel con su tipo de RAID específico. Por ejemplo, para RAID 5 (4+1), se requiere un conjunto de 10 discos en lugar de uno de siete discos. Cálculo basado en la capacidad Calcule los ejes del disco según la capacidad para cada nivel con la siguiente fórmula: Capacidad total x desviación de capacidad para el nivel Número de discos por nivel = Sobrecarga de capacidad de RAID Diseño final Use el número más grande para cada nivel como el dimensionamiento final para satisfacer los requisitos de rendimiento y capacidad. Para obtener más información sobre el dimensionamiento para la organización en niveles de FAST VP, consulte el documento EMC Virtual Infrastructure for MS Applications enabled by Symmetrix VMAX and MS Hyper-V White Paper. Consideraciones para el dimensionamiento de la base de datos OLAP Para conseguir un rendimiento de ancho de banda predecible, EMC recomienda un enfoque de componente básico que considere lo siguiente: Ancho de banda planificado Consumo de memoria Cantidad de CPU Dimensionamiento de la base de datos Dimensionamiento de Tempdb Los principios de diseño son los siguientes: Diseñar para ancho de banda y luego para la capacidad de la base de datos. En el caso de las bases de datos OLAP, para lograr la meta de completar todas las consultas para generar los informes a tiempo, el diseño de almacenamiento tiene que cumplir con el ancho de banda requerido. Verificación del rendimiento de disco. Para los tipos de carga con I/O secuenciales, de gran tamaño y de solo lectura (por lo general 64,000 o más), calcule el ancho de banda para un tamaño determinado de I/O con el IOPS. Número de discos por nivel = Tamaño promedio de I/O x IOPS de solo lectura Mejores prácticas y reglas de diseño de Microsoft SQL Server para el 34 34

35 Calcular el requisito de almacenamiento para los archivos de base de datos. Calcule la cantidad de discos que se necesitan para el rendimiento de la siguiente manera: Ancho de banda requerido Número de discos para el rendimiento = Ancho de banda por disco Calcule la cantidad de discos que se necesitan para la capacidad de la siguiente manera: Capacidad requerida Número de discos por capacidad = Sobrecarga de RAID para la capacidad Redondee a la siguiente cantidad de unidades lógicas para su tipo de RAID específico en cada uno de los cálculos. Para el almacenamiento en niveles, calcule las necesidades de almacenamiento en niveles del tipo de carga OLTP según la desviación, como se analizó en Mejores prácticas para el dimensionamiento de FAST VP. Use la relación de 1:5 recomendada para el tamaño de Tempdb. EMC recomienda una Tempdb de 100 GB por cada 500 GB de archivos de base de datos en un ambiente OLAP. El tamaño real de Tempdb depende del ambiente específico. Para obtener más información sobre el diseño de componentes básicos de OLTP, consulte Enfoque de diseño del componente básico para data warehouse. También puede revisar el documento SQL SERVER 2012 DATA WAREHOUSE EMC VNX5500 HB, VMware vsphere 5, Windows 2012 White Paper. Consideraciones de almacenamiento para hipervisor Como la tecnología de servidor actual está reduciendo rápidamente los costos del poder de procesamiento, la mayoría de los ambientes de servidores físicos no se utilizan con tanta frecuencia. Aun así, algunas funciones deben estar en servidores separados para que las aplicaciones de SQL Server funcionen adecuadamente. La virtualización puede optimizar los recursos del centro de datos mediante la consolidación de los recursos de servidor a unos pocos servidores físicos. Esto reduce el consumo de energía, ahorra espacio, mejora el retorno de la inversión (ROI), aumenta la capacidad de administración y la flexibilidad e introduce nuevas opciones de alta disponibilidad. El programa de validación de virtualización del servidor (SVVP) de Windows, que se encuentra disponible en el sitio web de Microsoft, proporciona información sobre el compatible con la virtualización de ambientes de SQL Server. La virtualización de un ambiente de SQL Server requiere algunas de las mejores prácticas únicas de diseño del almacenamiento. Con la virtualización de un ambiente de SQL Server alojado en la familia EMC VNX o en el almacenamiento de la serie Symmetrix VMAX, los clientes puede usar funciones como VMware vmotion y las herramientas de migración en vivo de Microsoft Hyper-V. Estas características permiten que los servidores virtuales se muevan entre diferentes plataformas del hardware del servidor sin interrumpir las aplicaciones. Microsoft Exchange: Mejores prácticas Storage y reglas Best de Practices diseño de and Microsoft Design Guidance SQL Server for para EMC el Storage 35 35

36 Reglas generales para la virtualización A continuación, se presentan las reglas generales que se aplican en la virtualización de Microsoft SQL Server: Siga los principios generales de diseño de SQL Server: Diseñe para conseguir rendimiento, confiabilidad y capacidad. Diseñe para perfiles de usuario (como OLTP y OLAP). Dimensione las máquinas virtuales según la función de SQL Server (parte de SAP o SharePoint). El dimensionamiento físico se continúa aplicando para calcular la cantidad de discos o FAST VP. Le recomendamos instalar PowerPath en hosts físicos de Hyper-V o ESX para balanceo de carga, administración de rutas y detección de falla de ruta I/O. Consideración sobre los recursos del sistema de una máquina virtual: Dimensione los servidores físicos para admitir la cantidad de huéspedes. Mantenga la cantidad de núcleo físicos y vcpu en una relación de 1:1. Asegúrese de que no haya CPU sobreasignados. No sobrepase el tamaño del nodo NUMA en el servidor físico cuando dimensione las máquinas virtuales. Para obtener más información, visite Uso de sistemas NUMA con ESX/ESXi. Reserve por completo la memoria RAM para las máquinas virtuales de SQL Server a fin de evitar el incremento de memoria. Comprenda los límites del hipervisor (Hyper-V y VMware): Memoria máxima: 1 TB (ESXi 5.1, Windows 2012 Hyper-V) LUN de SCSI por máquina virtual: 256 (ESXi 5.1, Windows 2012 Hyper-V) Límites del procesador VMware vsphere 5.1: 32 CPU virtuales Windows 2012 Hyper-V: 64 CPU virtuales Use páginas de gran tamaño en el huésped (inicie SQL Server con un indicador de rastros: T834) para mejorar el rendimiento de un SQL Server dedicado de 64 bits. Otorgue los privilegios de Bloquear páginas en la memoria para la cuenta de servicio de SQL Server. Consideraciones para los grupos de disponibilidad continua: Distribuya réplicas de los grupos de disponibilidad continua entre múltiples hosts físicos para minimizar cualquier tiempo fuera potencial en caso de tener problemas en el servidor físico. Si las máquinas virtuales de SQL Server en un grupo de disponibilidad continua son parte de un cluster de failover y tecnología de migración basada en host del hipervisor, configure las máquinas virtuales para que no guarden o restauren su estado en el disco cuando se muevan o desconecten. Soporte de VMware para clusters de servidores SQL. Mejores prácticas y reglas de diseño de Microsoft SQL Server para el 36 36

37 Tabla 10. Hay limitaciones para la agrupación en clusters de FCI y de los grupos de disponibilidad AlwaysOn (AAG) para VMware, como se aprecia en la Tabla 10. Limitaciones de VMware para los clusters de Microsoft SQL Server Característica Disco compartido Disco no compartido Agrupación en clusters de Microsoft en VMware MSCS con disco compartido Agrupación en clusters de SQL Disponibilidad continua de SQL Cluster de failover instancia Balance de carga de red Soporte de vsphere Sí Sí Sí Sí Sí Disponibilidad continua de SQL Disponibilidad Grupo Soporte de alta disponibilidad de VMware Sí 1 Sí 1 Sí 1 Sí 1 Sí 1 Soporte de vmotion DRS No No No Sí Sí Soporte de Storage vmotion No No No Sí Sí Límites del nodo MSCS 2 (5.1) 5 (5.5) 2 (5.1) 5 (5.5) 2 (5.1) 5 (5.5) Los mismos que los del SO/aplicación Los mismos que los del SO/aplicación Soporte para los protocolos de almacena miento Disco compartido Fibre Channel Sí Sí Sí Sí Sí iscsi del SO en el huésped Sí Sí Sí Sí Sí Nativas iscsi Sí 2 Sí 2 Sí 2 Sí Sí SMB del SO en el huésped Sí 3 Sí 3 Sí 3 N/D N/D FCoE Sí 4 Sí 4 Sí 4 Sí Sí RDM Sí Sí Sí N/D N/D VMFS Sí 5 Sí 5 Sí 5 N/D N/D Para obtener más información sobre las limitaciones de VMware con Microsoft, consulte la Knowledge Base de VMware. Consideración de alta disponibilidad y recuperación de desastres: desactive las tecnologías de migración que guardan el estado y migración. Realice siempre una migración activa o apague completamente las máquinas virtuales. Desactive las funciones de ajuste automático basado en hipervisor. 1 Cuando se usan las reglas de afinidad y anti-afinidad de DRS. 2 Solo vsphere Solo para Windows Server 2012 Failover Clustering. 4 En vsphere 5.5, se admite FCoE nativo. En la actualización 1 de vsphere 5.1 y la actualización 3 de 5.0, la configuración de dos nodos de cluster con las tarjetas CNA de Cisco (VIC 1240/1280) y la versión del controlador son compatibles con el SO huésped de Windows 2008 R2 SP1 64-bit. Para obtener más información, consulte la guía de compatibilidad de hardware de VMware: Cisco UCS VIC1240, Cisco UCS VIC Compatible solo en configuraciones Cluster in a Box (CIB). Para obtener más información, consulte la sección Consideraciones para la agrupación en clusters del almacenamiento compartido que se encuentra en este artículo. Microsoft Exchange: Mejores prácticas Storage y reglas Best de Practices diseño de and Microsoft Design Guidance SQL Server for para EMC el Storage 37 37

38 Para conseguir el rendimiento óptimo con las instancias de misión crítica de nivel 1 del servidor SQL: Siga las mismas reglas que se aplican al ambiente físico, es decir, separar los LUN para datos y logs. Asegúrese de que cada servidor ESXi o Hyper-V tenga al menos cuatro rutas (dos adaptadores de bus de host (HBA)) para el almacenamiento, con un total de cuatro puertos. Asegúrese de que la conectividad para el arreglo de almacenamiento se proporcione a ambos SP para VNX, o a través de múltiples directores front-end en VMAX. Ubique el almacenamiento de SQL Server en discos separados del almacenamiento físico del sistema operativo huésped (VHD/VHDX o VMDK). Para conseguir un rendimiento aceptable con el nivel 2 y con instancias de menor nivel de servicios: Los discos duros virtuales para los LUN del sistema operativo de la máquina virtual pueden compartir un LUN en el nivel de hipervisor (área de almacenamiento de datos para vsphere o los LUN de nivel de host para VHD/ VHDX en Hyper-V) con los LUN de la base de datos y logs de SQL Server, si la facilidad de implementación es la preocupación principal y el rendimiento es algo secundario. Varias máquinas virtuales o bases de datos pueden compartir LUN en el nivel de hipervisor (área de almacenamiento de datos para vsphere o los LUN de nivel de host para VHD/ VHDX en Hyper-V), si el nivel de alta disponibilidad y recuperación de desastres es aceptable para el ambiente específico. Microsoft proporciona información y recomendaciones adicionales para la virtualización de SQL Server. Mejores prácticas para el ambiente VMware vsphere Las siguientes son algunas de las mejores prácticas generales para la implementación de SQL Server en un ambiente virtual de VMware VSphere: Implemente máquinas virtuales de aplicaciones en almacenamiento compartido. Esto permite el uso de funciones de vsphere como vmotion, alta disponibilidad y DRS. Cree VMFS de vcenter para garantizar la alineación de la partición. Agregue cerca de un 5 % a los requisitos de CPU para la sobrecarga del hipervisor. Cuando use VMFS para el almacenamiento de datos, el formato de los archivos VMDK debe ser eagerzeroedthick (específicamente para los archivos de base de datos y de log.) Use varios adaptadores PVSCSI y distribuya de manera equitativa los dispositivos de destino. Los adaptadores VMware Paravirtual SCSI (PVSCSI) son unidades de almacenamiento de alto rendimiento que pueden mejorar el rendimiento y reducir el uso de CPU. Los adaptadores PVSCSI son una mejor opción para los ambientes SAN, en los que el hardware o las aplicaciones impulsan un alto rendimiento de I/O. Figura 5 muestra que el tipo de controlador SCSI se cambió a Paravirtual para mejorar la eficiencia del controlador. El controlador SCSI predeterminado es LSI Logic SAS. Los LUN se distribuyen a través de todas las unidades SCSI disponibles. Mejores prácticas y reglas de diseño de Microsoft SQL Server para el 38 38

39 Figura 5. Controladores SCSI Aumente la profundidad de la línea de espera de HBA en el servidor ESXi para mejorar el rendimiento de las tarjetas HBA en los servidores ESXi. Observamos un beneficio cuando se configura la profundidad de la línea de espera de HBA en 64 (el valor predeterminado es 32 en ESXi 5.0 y 64 en ESXi 5.1). Los resultados pueden variar en ambientes específicos. Notas: La mayor profundidad de línea de espera configurable para los puertos HBA en ESXi 5.0 es 128 y en ESXi 5.1 es 256, si los LUN asociados tienen puertos de servidor ESXi asociados. Para los servidores ESXi 5.0 con múltiples máquinas virtuales, el valor de Disk.SchedNumReqOutstanding en las opciones avanzadas de VMware tiene que coincidir con la profundidad de la línea de espera. Para obtener más información sobre la configuración del servidor ESXi, consulte el sitio web de la Knowledge Base de VMware y el manual de rendimiento de almacenamiento escalable de VMware ESX. VMFS frente a RDM VMFS y RDM tienen, por lo general, un rendimiento similar, aunque RDM proporciona un rendimiento levemente superior. El VMFS se puede usar en casi todos los ambientes, a menos que exista un requisito específico para la agrupación en clusters y la replicación de snapshot. Visite el sitio web de VMware para obtener más información. La Tabla 11 realiza una comparación entre VMFS y RDM en el ambiente VMware de SQL Server. Tabla 11. VMFS VMFS frente a RDM Mejor consolidación del almacenamiento: múltiples discos virtuales y máquinas virtuales por LUN de VMFS; aun así admite una máquina virtual por LUN Consolidación de máquinas virtuales en LUN: hay menos posibilidades de alcanzar el límite de LUN para ESX de 255 Administración de rendimiento: la cantidad de IOPS combinados de todas las máquinas virtuales en el LUN es menor que la clasificación de IOPS del LUN Tamaño de LUN limitado (2 TB para vsphere 5.1 y 62 TB para vsphere 5.5) RDM Aplica el mapeo 1:1 entre la máquina virtual y el LUN Más probabilidades de alcanzar el límite de LUN para ESX de 255 No se ve afectado por los IOPS de otras máquinas virtuales Tamaño de LUN ilimitado Microsoft Exchange: Mejores prácticas Storage y reglas Best de Practices diseño de and Microsoft Design Guidance SQL Server for para EMC el Storage 39 39

40 VMFS Funciona bien para la mayoría de los ambientes que no requieran mapeo de dispositivos crudos (RDM) RDM Necesario para la agrupación en clusters (disco de quórum); por ejemplo, agrupación en clusters de failover de SQL Server Necesario para las tareas de administración de SAN como el respaldo y los snapshots Microsoft Hyper-V Opciones de almacenamiento para SQL Server VHDX es el nuevo formato de disco duro virtual que se incorporó en Windows Server 2012 Hyper-V; brinda una mejor capacidad de almacenamiento y protección de datos. VHD, el disco duro virtual de Windows Server 2008 Hyper-V, se puede convertir a VHDX en Windows Server 2012 Hyper-V. Los archivos de base de datos o de log de SQL Server pueden residir en VHD o VHDX. VHDX se puede crear en un volumen compartido de cluster (CSV) para aprovechar las funciones de alta disponibilidad y recuperación de desastres que ofrece Hyper-V. CSV es una característica de la agrupación en clusters de failover, que se introdujo por primera vez en Windows Server 2008 R2 para su uso con Hyper-V. CSV es un disco compartido que contiene un volumen de sistema de archivos NT (NTFS) al cual tienen acceso todos los nodos de un cluster de failover de Windows Server para operaciones de lectura y escritura. El disco de paso puede omitir la capa del hipervisor y maximizar el rendimiento de los discos subyacentes. NPIV (virtualización ID de N_Port) es una función de Fibre Channel virtual para Hyper-V que se introdujo en Windows Permite conectarse al almacenamiento de Fibre Channel desde una máquina virtual. Con NPIV, los tipos de carga virtualizados pueden usar inversiones existentes de Fibre Channel. También es compatible con varias características relacionadas, como SAN virtuales, migración en línea e I/O de múltiples rutas (MPIO). Esta función proporciona un rendimiento cercano al del disco de paso con nivel de protección y migración sencilla de Hyper-V. Fibre Channel virtual para Hyper-V le proporciona al sistema operativo huésped un acceso directo a la red de almacenamiento SAN mediante el uso de un World Wide Name (WWN) estándar asociado a una máquina virtual. Ahora los usuarios de Hyper-V pueden usar SAN Fibre Channel para virtualizar tipos de carga que requieren acceso directo a los LUN de SAN. SAN Fibre Channel también le permite operar en nuevos escenarios, como la ejecución de la función de agrupación en clusters de failover que se encuentra dentro del sistema operativo huésped de una máquina virtual conectada al almacenamiento compartido de Fibre Channel. Los arreglos de cuentan con una funcionalidad de almacenamiento avanzada que ayuda a descargar determinadas tareas de administración de los hosts a los SAN. Fibre Channel virtual ofrece una ruta de I/O alternativa y basada en hardware para el paquete de discos duros virtuales del software de Microsoft. Esto le permite usar funcionalidades avanzadas como snapshots de hardware directamente desde las máquinas virtuales de Hyper-V. Para obtener más información sobre Fibre Channel virtual de Hyper-V, visite Microsoft TechNet. Mejores prácticas y reglas de diseño de Microsoft SQL Server para el 40 40

41 Consideraciones de almacenamiento para la agrupación en clusters de SQL Server Los grupos de disponibilidad continua (AAG), una función de alta disponibilidad y recuperación de desastres que se presentó en SQL Server 2012, requieren el cluster de failover de Windows Server (WSFC). Los grupos de disponibilidad continua no dependen de la instancia de clusters de failover (FCI) de SQL Server. En una instancia de clusters de failover (FCI) de SQL Server, los archivos de base de datos y log de SQL Server se comparten entre todos los nodos de un cluster, así que los LUN de almacenamiento que alojan a estos archivos deben estar disponibles desde todos los nodos. Esto significa que todos los LUN se deben configurar y zonificar a los nodos del cluster de manera simultánea. Se puede acceder a los LUN específicos de base de datos y log desde el nodo que ejecute activamente la instancia de SQL Server. Aunque las copias primarias y secundarias de las bases de datos no comparten almacenamiento en los grupos de disponibilidad continua (AAG), cada nodo del cluster necesita tener configurado y zonificado su propio almacenamiento. Se puede acceder a la copia de la base de datos en el nodo secundario de un grupo de disponibilidad continua si está configurada como copia legible, la cual es independiente de la copia primaria. Esto se puede usar para permitir que se descargue la funcionalidad de creación de informes en la copia secundaria desde la copia primaria. La Figura 6 muestra la diferencia entre FCI y AAG. Figura 6. FCI frente a AAG Las limitaciones de compatibilidad de la agrupación en clusters de SQL Server en un ambiente VMware se detallan en la Tabla 10. Reglas de diseño de almacenamiento para Symmetrix VMAX La serie EMC Symmetrix VMAX es un almacenamiento de gama alta para el centro de datos. El sistema escala a un masivo 2 PB y consolida más tipos de carga con mucho menos espacio físico que otros arreglos. La arquitectura Virtual Matrix Architecture de EMC Symmetrix escala sin problemas el rendimiento, la capacidad y la conectividad según demanda para cumplir con todos los requisitos de la aplicación. El sistema es compatible con discos flash, Fibre Channel y discos SATA, además de contar con una organización en niveles automatizada y optimizada con FAST VP. El sistema también es compatible con servidores virtualizados y físicos, lo cual incluye a sistemas abiertos, mainframe y a servidores IBM i. Microsoft Exchange: Mejores prácticas Storage y reglas Best de Practices diseño de and Microsoft Design Guidance SQL Server for para EMC el Storage 41 41

42 Consideraciones para el diseño de hardware de la serie VMAX A continuación, se describen algunas de las consideraciones más importantes con respecto al diseño para SQL Server en VMAX: En el momento de crear LUN, use menos hipervolúmenes pero que sean de mayor tamaño para mejorar el rendimiento. Use un mínimo de dos tarjetas HBA por servidor, cada una debe estar conectada, por lo menos, a dos puertos de director (a través de múltiples motores VMAX, de ser posible). Para los LUN gruesos y delgados, use metavolúmenes fraccionados. Consideraciones y mejores prácticas del aprovisionamiento virtual Con las funcionalidades de formato NTFS compatibles con dispositivos delgados de Microsoft Windows y los mecanismos de Instant File Initialization de Microsoft SQL Server, SQL Server puede obtener los máximos beneficios del aprovisionamiento virtual con EMC Symmetrix. Además, se recomiendan los pools de LUN delgados para SQL Server en Symmetrix VMAX. El rendimiento de un dispositivo delgado es equivalente al rendimiento de un dispositivo regular (grueso) en VMAX y, en la mayoría de los casos, el uso de pools delgados puede reducir el requisito inicial de almacenamiento. A continuación, se resumen las mejores prácticas para la configuración de Microsoft SQL Server con aprovisionamiento virtual en EMC Symmetrix VMAX: Use el aprovisionamiento virtual cuando la sobreasignación del almacenamiento del sistema sea algo típico. Use el aprovisionamiento virtual cuando se espera un rápido crecimiento con el tiempo, pero con un tiempo fuera limitado. Configure las bases de datos de SQL Server con Instant File Initialization (esta es la configuración predeterminada para SQL Server 2012). Considere usar la herramienta de umbral de utilización del pool delgado para monitorear a los pools y evitar que los pools delgados se queden sin espacio. Evite el aprovisionamiento virtual para los siguientes ambientes: Sistemas en los que las asignaciones compartidas de un pool común de dispositivos delgados no cumplen con los requisitos del cliente. Sistemas en los que no se puede recuperar una gran cantidad de espacio eliminado. Sistemas que no pueden tolerar un aumento ocasional en el tiempo de respuesta de aproximadamente un milisegundo, debido a escrituras en bloques sin inicializar. Consideraciones y mejores prácticas de FAST VP para un sistema de almacenamiento VMAX FAST VP proporciona SQL Server con administración reducida y resolución más rápida de problemas de espacio y de I/O. En especial con el tipo de carga OLTP, FAST VP proporciona un uso eficaz del almacenamiento y transfiere los datos a los que se accede con más frecuencia al nivel de rendimiento más alto. Mejores prácticas y reglas de diseño de Microsoft SQL Server para el 42 42

43 Las siguientes son algunas consideraciones y mejores prácticas para el uso de FAST VP: Evite poner LUN de log en un nivel de flash, ya que los logs generan principalmente escrituras secuenciales y no se beneficiarán de un dispositivo flash. Vincule los LUN de la base de datos con el nivel de Fibre Channel para comenzar con FAST VP y proporcionar almacenamiento suficiente para tener en cuenta la capacidad en el caso de que los datos activos deban transferirse al nivel superior. Cuando use FAST VP con los grupos de disponibilidad continua, ponga copias del grupo de disponibilidad de la misma base de datos en diferentes pools para conseguir una mejor disponibilidad. Los logs se pueden anclar en un nivel específico cuando se ubican en el mismo pool de almacenamiento con LUN de archivos de datos. Realice el dimensionamiento según las Mejores prácticas para el dimensionamiento de FAST VP. Nota: Las tasas de desviación pueden variar y depende del perfil específico de SQL Server. Reglas de diseño de almacenamiento para VNX La familia EMC VNX ofrece innovaciones líderes del sector y funcionalidades empresariales para el almacenamiento de archivos y bloques en una solución escalable y fácil de usar. Esta plataforma de almacenamiento de última generación combina hardware flexible y eficiente con software de protección, administración y eficiencia avanzadas a fin de satisfacer las exigentes necesidades de las grandes empresas de la actualidad. La familia VNX incluye la serie VNXe, especialmente diseñada para el administrador de TI en ambientes para principiantes, y la serie VNX, creada para satisfacer los requisitos de alto rendimiento y alta escalabilidad de las medianas y grandes empresas. EMC FAST Suite es una función avanzada de software que proporciona mayor flexibilidad para administrar los aumentos en requisitos de rendimiento y capacidad del ambiente de SQL Server. EMC FAST Suite usa discos SSD, SAS y configuración de almacenamiento SAS NL para equilibrar las necesidades de rendimiento y almacenamiento. El conjunto de aplicaciones FAST incluye FAST Cache y FAST VP. Application Protection Suite automatiza las copias coherentes con la aplicación y le permite efectuar recuperaciones a niveles de servicio definidos. Las funciones de usuario permiten la administración de copias mediante autoservicio y, al mismo tiempo, mejoran la visibilidad para todos los puntos de recuperación de las aplicaciones. Se generan alertas de manera automática, lo que permite una resolución rápida de las brechas de recuperación. Los informes integrados pueden demostrar el cumplimiento de normas con políticas de protección. Las aplicaciones compatibles incluyen Oracle; Microsoft SQL Server, SQL Server y SharePoint; VMware; y Hyper-V. Application Protection Suite incluye: Para la serie VNX: Replication Manager, AppSync y Data Protection Advisor para el análisis de replicación Para VNXe: Replication Manager Microsoft Exchange: Mejores prácticas Storage y reglas Best de Practices diseño de and Microsoft Design Guidance SQL Server for para EMC el Storage 43 43

44 Consideraciones y mejores prácticas para FAST Cache EMC FAST Cache aumenta la caché del sistema de almacenamiento mediante la extensión de la funcionalidad de la caché de DRAM y con el mapeo de los datos de acceso frecuente al disco SSD. Las capacidades de FAST Cache van de 73 GB a 2 TB, lo cual es muy superior a la caché DRAM disponible de los sistemas de almacenamiento existentes. Si la aplicación del usuario accede frecuentemente a un fragmento de datos en especial, ese fragmento se promueve automáticamente a FAST Cache, se copia de las unidades de disco duro a los discos flash. Cuando posteriormente se accede a ese fragmento, se hace con tiempos de respuesta de disco flash, lo que impulsa el rendimiento del sistema de almacenamiento. FAST Cache es más adecuado para tipos de carga aleatorios con gran actividad de I/O en conjuntos de trabajo pequeños. Una base de datos OLTP típica con este tipo de perfil podría aprovechar FAST Cache para mejorar el rendimiento y el tiempo de respuesta. Monitoree los grupos de archivos de la base de datos de SQL Server y active FAST Cache en los pools de almacenamiento altamente activos donde se ubican esos datos. El artículo EMC FAST Cache: un análisis detallado, que se encuentra disponible en el sitio web de servicio de soporte en línea de EMC, proporciona más información sobre los conceptos de diseño, planificación y las reglas de uso de FAST Cache. Las pruebas indican que la inclusión de FAST Cache da como resultado un aumento de 300 % en transacciones por segundo (TPS) para un tipo de carga OLTP de SQL que usa la misma cantidad de unidades de disco duro en el back-end. El artículo EMC Unified Storage for Microsoft SQL Server 2008: Enabled by EMC CLARiiON and EMC FAST Cache Reference Architecture, disponible en el servicio de soporte en línea de EMC, proporciona más información sobre cómo crear una solución con EMC FAST Cache. Cuando use FAST Cache, permita una cantidad suficiente de tiempo para que la caché se prepare y pueda utilizar la caché por completo. En nuestras pruebas con tipos de carga OLTP, FAST Cache tardó entre una y dos horas para prepararse. El tiempo de preparación depende del tipo y de la cantidad de unidades de disco duro de back-end, del tamaño de FAST Cache y del tamaño del conjunto de trabajo. EMC Unisphere tiene varios contadores FAST Cache que puede monitorear para obtener la utilización y el tiempo de preparación óptimos. El documento EMC CLARiiON, Celerra Unified, and VNX FAST Cache White Paper, disponible en mexico.emc.com (visite el sitio de su país correspondiente), proporciona más información. Consideraciones y mejores prácticas para FAST VP Según los analistas del sector, entre un 60 % y un 80 % de los datos operativos de la base de datos están inactivos y aumentan a medida que lo hace el tamaño de la base de datos. Las unidades giratorias de bajo costo y alta capacidad son la opción ideal para los datos inactivos, mientras que las unidades de alto rendimiento son ideales para los datos de acceso frecuente. Clasificar y almacenar datos de forma manual en el nivel indicado es una tarea compleja y desafiante y, por lo general, requiere de tiempo fuera para transferir los datos. EMC FAST VP transfiere los datos de acceso frecuente a un almacenamiento físico más rápido dentro de un pool y transfiere automáticamente los datos a los que se accede rara vez a un almacenamiento físico menos costoso dentro del pool. Mejores prácticas y reglas de diseño de Microsoft SQL Server para el 44 44

45 Con FAST VP puede: Controlar cuándo FAST VP puede transferir los datos para evitar cualquier impacto en las solicitudes de I/O del host durante los períodos con alto uso del sistema. Mejorar el rendimiento general del sistema sin necesidad de invertir en unidades físicas adicionales de alto rendimiento. Aplicar FAST VP a cualquiera o todos los LUN de base de datos basados en pool en un sistema de almacenamiento. Cuando los LUN de log tienen que estar en el mismo pool de LUN de base de datos, ánclelos al nivel SAS y no permita la reubicación de datos en estos LUN. En un tipo de carga OLTP, ancle la Tempdb en el nivel SAS y no permita la reubicación de datos para estos LUN. Configurar la política de FAST en Start High then Auto Tier (predeterminado). El documento Understanding Microsoft SQL Server OLTP Performance Characterization for EMC VNX Series, disponible en el sitio web del servicio de soporte en línea de EMC, proporciona más información sobre el uso de FAST VP con SQL Server. FAST VP se ejecuta en segundo plano, mientras que los LUN permanecen en línea y disponibles para el acceso del host. Se puede controlar la velocidad de transferencia de los datos para minimizar el impacto en el rendimiento general del sistema (puede configurar la tasa de reubicación en alta, media o baja). FAST Cache frente a FAST VP FAST Cache impulsa el rendimiento de forma inmediata para los patrones de acceso aleatorio y los datos en ráfagas, mientras que FAST VP permite que el sistema de almacenamiento transfiera los datos inactivos a un nivel de almacenamiento de menor costo. FAST Cache opera en unidades de 64 kb y FAST VP opera en fragmentos de 1 GB. FAST VP puede promover los metadatos delgados y los datos de usuario con mayor acceso al nivel más alto, mientras que FAST Cache promueve los metadatos para mejorar el rendimiento del LUN delgado. FAST Cache y FAST VP pueden funcionar juntos en una base de datos de SQL Server para mejorar el rendimiento, lograr un mayor uso de la capacidad y disminuir los requisitos de potencia y enfriamiento. A continuación, se presentan las mejores prácticas para el uso de FAST Cache y FAST VP: Cuando haya un número limitado de discos flash disponible, primero use discos flash para crear FAST Cache. FAST Cache es global y se puede beneficiar de múltiples pools en el sistema de almacenamiento. FAST Cache usa fragmentos de 64 kb mientras que FAST VP usa fragmentos de 1 GB, lo cual resulta en beneficios de mayor rendimiento y de un tiempo de reacción más rápido para cambiar los patrones de uso. Use discos flash para crear un nivel de rendimiento FAST VP para un pool específico, con el fin de garantizar el rendimiento de los datos de misión crítica. El nivel FAST VP está dedicado a un pool de almacenamiento y no se comparte con otros pools de almacenamiento en el mismo arreglo de almacenamiento. Microsoft Exchange: Mejores prácticas Storage y reglas Best de Practices diseño de and Microsoft Design Guidance SQL Server for para EMC el Storage 45 45

46 Consideraciones para flash de servidor Descripción general de XtremSF XtremSF es una única tarjeta de hardware flash de servidor de bajo perfil que se adapta en cualquier servidor de montaje en rack dentro del ámbito de alimentación de un solo slot PCIe, disponible con un conjunto amplio de capacidades emlc y SLC. Se puede implementar: Como almacenamiento local ubicado en el servidor para brindar un alto rendimiento En combinación con el software de almacenamiento en caché basado en servidores XtremSW Cache para mejorar el rendimiento del arreglo de almacenamiento en red, mientras se mantiene el nivel de protección requerido por los ambientes de las aplicaciones críticas. Mejores prácticas de diseño para XtremSF XtremSF de NAND SLC y MLC ofrecen funcionalidades que sirven para dos tipos de aplicaciones: aquellas que requieren un alto rendimiento a un costo atractivo por bit (MLC) y aquellas que son más costosas y buscan un rendimiento aún mayor con el tiempo (SLC). En un data warehouse o ambiente OLAP de alta exigencia, y a veces en un ambiente OLTP en el que se utilice mucho la Tempdb, se puede usar XtremSF como almacenamiento de Tempdb para reducir la contención de la Tempdb y, de esa forma, mejorar el ancho de banda. XtremSF es mejor para bases de datos de SQL Server que tengan una relación de lectura/escritura de un 70 % a un 90 % y que cuenten con una protección de datos en el nivel de SQL Server. Con tarjetas XtremSF de mayor tamaño es posible admitir una completa base de datos en una única tarjeta XtremSF. Los casos de uso que se pueden beneficiar de XtremSF local se presentan en el documento EMC XtremSF Performance Acceleration for Microsoft SQL Server 2012 White Paper. Descripción general de XtremSW Cache XtremSW Cache es un software de almacenamiento en caché basado en servidores de EMC para tarjetas flash PCIe que completa XtremSF con datos para utilizarlo como caché. XtremSW Cache está diseñado para seguir estos principios básicos: Rendimiento: Reducir la latencia y aumentar el rendimiento para mejorar considerablemente el rendimiento de las aplicaciones. Inteligencia: Agregar otro nivel de inteligencia mediante la extensión de la tecnología basada en arreglos FAST en el servidor. Protección: Brindar un rendimiento con protección mediante las funciones de alta disponibilidad y recuperación de desastres del almacenamiento en red de EMC. Los tipos de carga de SQL Server que se pueden beneficiar más con XtremSW Cache son: Las aplicaciones que tienen altas relaciones de tipos de carga de lecturaescritura. La máxima eficacia se obtiene cuando los mismos trozos de datos se leen muchas veces y se escriben pocas veces. Mejores prácticas y reglas de diseño de Microsoft SQL Server para el 46 46

47 Las aplicaciones con un conjunto de trabajo pequeño, que reciben el máximo aumento posible. Las aplicaciones con tipos de carga de lectura predominantemente aleatorios. Los tipos de carga secuenciales que tienden a tener un conjunto de datos activo mucho más grande (como data warehousing) en proporción al tamaño disponible de XtremSW Cache no se benefician mucho con XtremSW Cache. Las aplicaciones con un alto grado de simultaneidad de I/O (es decir, varios hilos de I/O). Las aplicaciones con tamaños de I/O más pequeños (8 kb o menos) pero que generan tamaños de I/O grandes. El software XtremSW Cache le permite ajustar características, como el tamaño de página y los tamaños máximos de I/O, lo que ayuda mucho en estos ambientes para acelerar determinadas I/O y para ignorar otras (como I/O de lectura de respaldo). XtremSW Cache puede acelerar las operaciones de lectura, mientras todas las operaciones de escritura se escriben en el arreglo de almacenamiento y no se ven afectadas por XtremSW Cache. En muchos casos, se puede observar una mejora en el rendimiento de escritura en la medida en que XtremSW Cache descarga las operaciones de lectura, lo que permite que el arreglo maneje más operaciones de escritura como un beneficio adicional. XtremSW Cache puede no ser adecuado para las aplicaciones secuenciales o con gran actividad de escritura, como aplicaciones de data warehousing, de medios en tiempo real o de big data. Para resumir, puede usar XtremSF como almacenamiento local para la aceleración de lectura y escritura, los datos temporales y los grandes conjuntos de trabajo, mientras que XtremSF con XtremSW Cache se puede usar para la aceleración de lectura de los datos de misión crítica con conjuntos de trabajo pequeños que requieren protección de datos. Mejores prácticas de diseño para XtremSW Cache A partir de la configuración de almacenamiento básica, determine el SQL Server que necesite aceleración de XtremSW Cache. En un ambiente típico de OLTP de SQL Server: Use XtremSF con XtremSW Cache para la aceleración de lectura de los datos de misión crítica con conjuntos de trabajo lo suficientemente pequeños como para quedar en la caché. Use XtremSW Cache Performance Predictor para realizar un análisis de beneficios inicial de SQL Server con XtremSW Cache. Los LUN de archivos de datos de la base de datos que tienen mucha actividad de lectura tienen, por lo general, tipos de carga de gran actividad, sujetos a una desviación de alta actividad de lectura, y son buenos candidatos para XtremSW Cache. Los archivos de datos de OLTP de SQL Server experimentan lecturas aleatorias constantes y contribuyen a la duración general de los tiempos de las transacciones. Los archivos de datos también experimentan ráfagas regulares de actividad de escritura durante una operación de puntos de comprobación. El uso de XtremSW Cache para almacenar en caché las lecturas y para evitar un tipo de carga de I/O en el arreglo de EMC permite que el arreglo consuma las ráfagas de escritura más rápidamente y se evitan retrasos de lectura en las transacciones. Microsoft Exchange: Mejores prácticas Storage y reglas Best de Practices diseño de and Microsoft Design Guidance SQL Server for para EMC el Storage 47 47

48 Los LUN de log y los LUN de Tempdb en las bases de datos de OLTP presentan gran actividad de escritura y, por lo general, no se benefician con XtremSW Cache. En los ambientes de disponibilidad continua de SQL Server, las bases de datos secundarias no necesitan aceleración, a menos que un requisito de rendimiento específico justifique el uso de XtremSW Cache. Defina el tamaño de página en 64 kb en XtremSW Cache para admitir la gran cantidad de I/O para la base de datos de SQL Server. Si no se espera que el tipo de carga aumente después de implementar XtremSW Cache, no hay necesidad de agregar recursos del sistema adicionales, como memoria o CPU. Coloque al menos dos tarjetas XtremSF dentro de su infraestructura de servidor cuando se requiera redundancia. Por lo general, la deduplicación no beneficia al patrón de I/O de SQL Server. Mejores prácticas de diseño para XtremSW Cache en un ambiente virtualizado A continuación, se describen algunas de las mejores prácticas de diseño para XtremSW Cache en un ambiente virtualizado: Coloque al menos dos tarjetas XtremSF dentro de su infraestructura de servidor de hipervisor cuando se requiera redundancia. Si se requiere vmotion, calcule la capacidad y la ubicación de XtremSF de manera que la capacidad de XtremSF y el servidor restantes aún sirvan para la configuración de XtremSW Cache de todas las máquinas virtuales cuando se usa vmotion. Por ejemplo, si 10 máquinas virtuales se configuran para usar 100 GB de XtremSW Cache, lo que requiere un total de 1 TB de capacidad de XtremSW Cache, en el momento del uso de vmotion, los servidores restantes del cluster virtualizado con XtremSW Cache necesitan facilitar al menos 1 TB de espacio de caché. Si las aplicaciones solo necesitan una pequeña parte de la capacidad de la tarjeta XtremSF para cada máquina virtual, las máquinas virtuales con estas aplicaciones pueden compartir la misma tarjeta física y colocarse en una mejor ubicación en el mismo host ESXi o Hyper-V. Si una determinada aplicación exige toda la capacidad disponible de la tarjeta XtremSF, el host debería dedicar esa tarjeta específica a la máquina virtual. Se pueden instalar varias tarjetas XtremSF en el mismo servidor, si fuera necesario. Varias tarjetas XtremSF se pueden configurar en el mismo hipervisor para crear varios dispositivos de caché para esa máquina virtual. Para determinados tipos de carga de aplicaciones que se hayan seleccionado para usar la funcionalidad de tarjeta dividida, una parte de la tarjeta se puede configurar para satisfacer las necesidades de almacenamiento en caché de la máquina virtual; la otra parte se puede configurar como almacenamiento XtremSF para satisfacer la necesidad de un área de almacenamiento de datos temporal, como el espacio de almacenamiento de la Tempdb. Se deben tener en cuenta consideraciones adicionales para la portabilidad de la máquina virtual en el ambiente virtualizado de esta configuración, ya que ahora la máquina virtual depende del almacenamiento local en ese servidor. Mejores prácticas y reglas de diseño de Microsoft SQL Server para el 48 48

49 El tamaño mínimo para el disco virtual de XtremSW Cache es de 20 GB para cualquier máquina virtual que necesite la aceleración de la caché flash. Ubicar solo los VHDX que requieren aceleración XtremSW Cache en los LUN configurados con XtremSW Cache. Se acelerarán todos los VHDX en el LUN configurado con XtremSW Cache. Consideración de dimensionamiento para XtremSF y XtremSW Cache Hay recomendaciones de dimensionamiento disponibles para cada tipo de aplicación. Los ambientes son diferentes, por lo tanto, las implementaciones también son diferentes. A continuación, se incluyen las configuraciones mínimas recomendadas para cada aplicación, según nuestras pruebas con un tipo de carga de base de datos y un tipo de trabajo de aplicación típicas. En la mayoría de los casos, agregar más XtremSW Cache otorga un mejor rendimiento hasta que el tamaño de la caché iguala o supera el del conjunto de trabajo. Para determinar el dimensionamiento que mejor se adecua a una aplicación y ambiente específicos, es importante considerar tanto el nivel de rendimiento que necesita como el costo que puede afrontar. La Tabla 12 proporciona recomendaciones sobre XtremSW Cache para cada aplicación. La relación de caché y almacenamiento 6 depende en gran medida del conjunto de trabajo activo de la base de datos y cambiará según el uso real. Estas recomendaciones se basan en las pruebas que realizamos en un ambiente controlado. Es posible que su ambiente sea diferente, así que le recomendamos usar los números que se proporcionan como guía. Tabla 12. Aplicación Caché recomendada para cada aplicación Tipo de base de datos Relación de lecturaescritura SQL Server OLTP 90:10 1:10 SQL Server OLTP 70:30 1:5 Relación recomendada de XtremSW Cache y el almacenamiento SharePoint Contenido/ rastreo 100 % lectura 1:5 SQL Server OLAP 100 % lectura 1:5 (Tempdb en XtremSF: tamaño de la base de datos) Para las aplicaciones de procesamiento analítico en línea (OLAP) de SQL Server, como un ambiente de data warehouse, emlc XtremSF (solo o en modo de tarjeta dividida) se puede usar como la Tempdb para mejorar el rendimiento de las consultas. Considere un espacio de Tempdb de al menos 200 GB por cada 1 TB de base de datos. Para obtener más información sobre todas las mejores prácticas para el diseño y la configuración relacionadas con XtremSF y XtremSW Cache, consulte la EMC VSPEX with EMC XtremSF and EMC XtremSW Cache Design Guide. Este documento es para VSPEX, pero los principios de diseño y mejores prácticas se pueden aplicar a la mayoría de los ambientes. 6 La relación de XtremSW Cache y el almacenamiento es la relación de la caché y el tamaño de almacenamiento de la base de datos. Si la relación es de 1:10, entonces por cada 10 GB de datos, proporcione al menos 1 GB de XtremSW Cache. Microsoft Exchange: Mejores prácticas Storage y reglas Best de Practices diseño de and Microsoft Design Guidance SQL Server for para EMC el Storage 49 49

50 Automatización con ESI EMC Storage Integrator (ESI) para el conjunto de aplicaciones de Windows es un conjunto de herramientas orientadas a los administradores de aplicaciones de Microsoft y Microsoft Windows. El conjunto de aplicaciones incluye ESI para Windows, ESI PowerShell Toolkit, ESI Service, paquetes de administración de ESI para System Center Operations Manager (SCOM) y ESI Service PowerShell Toolkit. ESI para Windows Proporciona la capacidad de ver, provisionar, monitorear y administrar el almacenamiento de bloques y de archivos para Microsoft Windows. ESI es compatible con la serie EMC Symmetrix VMAX y con la serie EMC VNX. ESI también admite aprovisionamiento de almacenamiento y descubrimiento para las máquinas virtuales que se ejecutan en Microsoft Hyper-V, Citrix XenServer y VMware vsphere. Como se aprecia en la Figura 7, ESI simplifica la administración de almacenamiento para Windows y aplica automáticamente algunas de las mejores prácticas de configuración de almacenamiento, además de simplificar la implementación del almacenamiento para Windows. Figura 7. ESI para la administración de almacenamiento de Windows Paquetes de administración de ESI para Systems Center Operations Manager 2012 Permite la administración de infraestructura de almacenamiento en una única interfaz de usuario. Con la integración de SCOM 2012, los administradores de Windows pueden descubrir recursos de almacenamiento, mapear objetos físicos y lógicos, administrar alertas y resumir estados de mantenimiento con umbrales de parámetros configurables de System Center EMC PowerShell Toolkit (PSToolkit) Es una utilería diseñada para que los administradores y usuarios de Windows puedan brindar asistencia en la administración de sistemas de almacenamiento. Los cmdlets de PSToolkit permiten que los administradores de sistema de almacenamiento obtengan información sobre el sistema de almacenamiento, cree o elimine pools de almacenamiento, grupos de almacenamiento y volúmenes de almacenamiento y también mapearlos o enmascararlos a cualquier servidor host disponible. Este conjunto de herramientas permite que los administradores puedan crear scripts automatizados de manera eficaz para la creación y eliminación dinámica de máquinas virtuales según lo necesiten los usuarios. Mejores prácticas y reglas de diseño de Microsoft SQL Server para el 50 50

51 Protección de SQL Server Descripción general Microsoft mejoró las funcionalidades de protección de datos y alta disponibilidad nativas de SQL Server en el nivel de base de datos para SQL Server 2012 presentando la función de grupos de disponibilidad continua. EMC tiene varias opciones y productos para la protección de datos que complementan los grupos de disponibilidad y que pueden proteger aún más su ambiente SQL Server de la pérdida de bases de datos, servidores o del sitio completo. En esta sección se describen varias opciones de recuperación de desastres y alta disponibilidad de SQL Server Los sistemas de ofrecen una amplia variedad de funciones para la protección de bases de datos y la alta disponibilidad de SQL Server. Las tecnologías de replicación de EMC, como TimeFinder, SRDF y los snapshots/clones de VNX, brindan la mejor protección de datos del sector. RecoverPoint, con sus herramientas de protección continua y de administración de replicación, tales como AppSync y Replication Manager, brindan protección para SQL Server en el nivel de aplicaciones. Puede aprovechar la tecnología de EMC en los procesos de respaldo de SQL Server para: Reducir el impacto en el sistema de producción durante el proceso de respaldo. Crear imágenes de respaldo coherentes. Integrar los procesos de respaldo y recuperación de SQL Server. Grupos de disponibilidad continua Ante una falla de hardware o software, las múltiples copias de la base de datos en un grupo de disponibilidad continua permiten una alta disponibilidad con procesos de failover rápidos y sin pérdida de datos. Esto elimina el tiempo fuera del usuario final, que implica una costosa recuperación a partir de un respaldo en un punto en el tiempo pasado desde un disco o una cinta, como se muestra en la Figura 8. Los grupos de disponibilidad continua se pueden extender a varios sitios y ofrecen resistencia contra fallas del centro de datos. Proporcionan replicación en el nivel de base de datos con failover automatizado. Figura 8. SQL Server y grupos de disponibilidad AlwaysOn Microsoft Exchange: Mejores prácticas Storage y reglas Best de Practices diseño de and Microsoft Design Guidance SQL Server for para EMC el Storage 51 51

52 Protección de datos nativa de SQL Server Si se requiere una copia en un punto en el tiempo previa de una base de datos, puede usar SQL Server para crear una copia retrasada en un ambiente de grupo de disponibilidad. Esto puede ser útil si una corrupción lógica se replica en todas las bases de datos en el grupo de disponibilidad continua, lo que da lugar al retorno a un punto en el tiempo anterior. También es útil si un administrador borra accidentalmente los datos de usuario. EMC es capaz de proporcionar los mismos niveles de protección, e incluso mejores, pero usa mucho menos almacenamiento gracias a los snapshots. Copias recuperables frente a copias reiniciables Las tecnologías de replicación de EMC pueden crear dos tipos diferentes de copias de bases de datos: recuperables o reiniciables. Puede usar cualquiera de estas tecnologías, o ambas, para satisfacer las necesidades de RPO de respaldo y otros requisitos. Copia recuperable de la base de datos Una copia recuperable de la base de datos es un respaldo en el que se aplican logs a la base de datos y que puede realizar roll forward a cualquier punto en el tiempo después de la creación de la copia de la base datos. Ante una falla de la base de datos de producción, la base de datos se puede recuperar al punto en el tiempo del último respaldo y puede realizar roll forward de las transacciones posteriores hasta el punto de falla. Esta es una función muy importante para la base de datos de SQL Server, así como para muchos otros requisitos del negocio. La Tabla 13 indica las tres maneras de crear una copia recuperable de una base de datos de SQL Server. Tabla 13. Metodología de SQL Server para crear una copia recuperable de la base de datos Metodología de respaldo Respaldo de flujo VDI VSS Descripción Declaración T-SQL o respaldo nativo de SQL Server Interfaz de dispositivo virtual para software de otros fabricantes Servicio de shadow copy de volumen para software de otros fabricantes Soportado Respaldo nativo de SQL, Networker VMAX/VNX/VNXe Networker, Replication Manager, AppSync, RecoverPoint VMAX/VNX/VNXe Networker, Replication Manager, AppSync, RecoverPoint Los tres tipos de respaldo están integrados con SQL Server y se consideran respaldos en activo. SQL Server registra el momento en que se lleva a cabo el respaldo. Copia reiniciable de la base de datos Al crear una copia de la base de datos en un nivel de almacenamiento sin ninguna integración en el nivel de base de datos, SQL Server puede usar la copia de la base de datos para realizar una recuperación de desastres y llevar la base de datos al punto en el tiempo en que se realizó la copia. Esto se considera una copia reiniciable de la base de datos. Mejores prácticas y reglas de diseño de Microsoft SQL Server para el 52 52

53 En este caso, todas las transacciones registradas como asignadas y escritas en el log de transacciones, con sus páginas de datos correspondientes escritas en los archivos de datos, realizan roll forward (reconstitución). Luego, SQL Server revertirá los cambios registrados que no se asignaron (como páginas defectuosas eliminadas por una escritura diferida). Esto da como resultado un estado de la base de datos con un punto en el tiempo transaccionalmente coherente. El respaldo de logs de transacciones adicionales no se puede aplicar a una base de datos en este estado, lo que conlleva a la recuperación de la base de datos solo al punto en el tiempo del respaldo. Una copia reiniciable de la base de datos se considera una copia en frío de la base de datos. No hay registros de respaldo en SQL Server. La tecnología de coherencia de EMC se puede usar para crear copias reiniciables de una base de datos de origen de SQL Server. Este tipo de tecnología no es invasiva para las operaciones de bases de datos de producción y se lleva completamente a cabo en el nivel de arreglos de almacenamiento. Las imágenes reiniciables representan imágenes coherentes de escritura dependiente de todos los objetos relacionados que se definieron en el grupo de coherencia. Marcos de trabajo de VDI y VSS para la replicación del respaldo EMC VMAX, VNX y VNXe también implementan la tecnología de coherencia integrada con la tecnología de snapshots de VDI y el marco de trabajo de VSS a fin de crear una copia recuperable de la base de datos. EMC RecoverPoint, Replication Manager, y AppSync se crearon a partir de estas tecnologías para brindar protección de datos y adaptarse a diversos ambientes. Ofertas de protección de datos y alta disponibilidad de EMC para SQL Server Si bien la protección de datos nativa de SQL Server es suficiente para algunos clientes, la mayoría aún requiere funcionalidades de respaldo y restauración completas para las bases de datos de SQL Server. EMC ofrece una amplia variedad de opciones para brindar protección de datos y alta disponibilidad con SQL Server. Solución de protección de SQL Server en el Apéndice D proporciona los detalles de la solución, incluidas algunas de las ofertas de protección indicadas para SQL Server. La Table 14 indica las opciones de la base de datos de SQL Server. Categoría Disponibilida d continua Tabla 14. Herramienta/ sistema Opciones de protección de datos y alta disponibilidad de EMC Recursos Descripción RecoverPoint CDP Síncrona Protección de recuperación local VMAX/VNX con un splitter de RecoverPoint incorporado CRR CLR CDP/CRR/CLR Asíncrona Replicación remota continua Datos simultáneos locales y remotos Combina CDP y CRR Los arreglos VMAX y VNX tienen opciones que incorporan el splitter de RecoverPoint, el cual funciona como disponibilidad continua nativa VMAX SRDF Replicación continua Microsoft Exchange: Mejores prácticas Storage y reglas Best de Practices diseño de and Microsoft Design Guidance SQL Server for para EMC el Storage 53 53

54 Categoría Herramienta/ sistema Recursos Descripción Recuperación a partir de una replicación rápida de un punto en el tiempo AppSync Replicación solo a partir de snapshots en VNX Una administración de almacenamiento simple, con protección de datos de autoservicio y dirigida por acuerdos de nivel de servicio (SLA) para SQL Server También funciona con RecoverPoint en VNX No se requieren agentes Replication Manager SAN Copy con snapshots/clone s para VMAX y VNX Un software de protección de datos integral Se debe instalar el agente en SQL Server VMAX TimeFinder Copia espejeada Operaciones de control y monitoreo generales para los volúmenes de continuidad del negocio (BCV) CG Grupos de consistencia Clon Las sesiones de clones ocupan el mismo tamaño que los LUN de producción, pero no tienen ningún efecto después de su creación Snapshot Los snapshots ocupan menos espacio que los clones, pero tienen un mayor impacto en los LUN de producción si los datos cambian frecuentemente en los LUN VNX Clon Las sesiones de clones ocupan el mismo tamaño que los LUN de producción, pero no tienen ningún efecto después de su creación Snapshot Los snapshots ocupan menos espacio que los clones, pero tienen un mayor impacto en los LUN de producción si los datos cambian frecuentemente en los LUN Respaldo y restauración eficientes de un punto en el tiempo EMC Avamar Una completa solución de hardware y software La deduplicación de longitud variable reduce considerablemente el tiempo de ejecución del respaldo almacenando solamente los cambios diarios únicos, a la vez que conserva los respaldos diarios completos para brindar restauración inmediata en un solo paso. EMC NetWorker Solución de software de respaldo y restauración tradicionales Centraliza, automatiza y acelera el respaldo y la recuperación de datos con una amplia variedad de opciones de protección de datos Cada producto tiene sus propios beneficios y consideraciones. La decisión depende de los requisitos de nivel de servicio para cada caso de uso. Mejores prácticas y reglas de diseño de Microsoft SQL Server para el 54 54

55 Los productos para la toma de snapshots y la creación de clones basados en hardware de EMC se han integrado con la VDI y la tecnología VSS de Microsoft por muchos años. Symmetrix TimeFinder y VNX SnapView (o Advanced Snap en su versión posterior) permiten la toma de snapshots de un punto en el tiempo y la creación de clones de datos locales para las operaciones de respaldo y recuperación. Estos productos permiten operaciones de respaldo no destructivas con snapshots que ahorran espacio y copias de clones bloque por bloque completas de sus bases de datos y logs. Con estos productos, los respaldos y las restauraciones pueden realizarse en segundos. EMC Replication Manager permite la administración de las tecnologías de replicación de un punto en el tiempo de EMC para SQL Server mediante una consola de administración centralizada. Replication Manager coordina todo el proceso de replicación de datos, desde el descubrimiento y la configuración hasta la administración de varias réplicas basadas en disco y coherentes con las aplicaciones. Las bases de datos se pueden descubrir automáticamente con una administración optimizada para la calendarización, el registro, el catálogo y el vencimiento automático de replicaciones. EMC recomienda enfáticamente el uso de un método sólido que permita el respaldo y la restauración rápidos de la base de datos de SQL Server. EMC Replication Manager, EMC Avamar y EMC Networker ofrecen funcionalidades para el truncamiento de logs y el montaje de bases de datos a hosts alternativos. Incluso si se usan los grupos de disponibilidad continua nativos de Microsoft SQL Server 2012, EMC recomienda enfáticamente una estrategia de protección de datos alternativa, sólida y de un punto en el tiempo de SQL Server para protegerse contra eventos de corrupción lógica. Tecnologías de replicación SQL Server requiere recursos de sistema dedicados. Al implementar un mecanismo de protección en el ambiente SQL, considere el impacto que conlleva en el rendimiento de SQL Server. EMC RecoverPoint RecoverPoint replica los datos para proteger el ambiente de SQL Server contra desastres. Ofrece tres opciones: Protección de replicación local (CDP). Esta opción brinda protección síncrona mediante la captura de cada transacción en una base de datos y su escritura simultánea a una ubicación de almacenamiento secundario. Replicación remota continua (CRR). Es una opción de protección asíncrona que puede replicar los datos a cualquier distancia. Protección de datos local y remota simultánea (CLR), que combina los métodos de replicación CDP y CRR a fin de brindar protección local y remota para un ambiente SQL Server. RecoverPoint escala adecuadamente y se puede implementar en ambientes de SQL Server muy grandes. Puede proporcionar copias reiniciables continuas de archivos de log y de bases de datos de usuarios a prácticamente cualquier punto en el tiempo. Los arreglos VNX y VMAX más recientes están integrados con el splitter de RecoverPoint. El documento EMC RecoverPoint Replicating Microsoft SQL Server Technical Notes, disponible en el sitio web del servicio de soporte en línea de EMC, proporciona más información. Microsoft Exchange: Mejores prácticas Storage y reglas Best de Practices diseño de and Microsoft Design Guidance SQL Server for para EMC el Storage 55 55

56 EMC TimeFinder EMC TimeFinder posee características de continuidad del negocio que permiten operaciones de control en pares de dispositivos dentro de un ambiente de replicación local con la siguiente funcionalidad: TimeFinder/Mirror: operaciones de control y monitoreo generales para los volúmenes de continuidad del negocio (BCV) TimeFinder/CG: grupos de coherencia TimeFinder/Clone: sesiones de copia de clones TimeFinder/Snap: sesiones de copia de snapshots Estas funciones pueden ser usadas por el administrador de almacenamiento o combinadas con otro software de replicación de datos para proporcionar copias de snapshots o clones de VSS o VDI integradas a SQL Server. Clones/snapshots de VNX Local Protection Suite combina snapshots y clones con recuperación en un punto en el tiempo con funcionalidades de reversión similares a DVR que brindan continuidad del negocio en el almacenamiento basado en bloques, lo que permite la recuperación de las aplicaciones de producción con una exposición mínima de los datos. Los propietarios de las aplicaciones pueden ajustar los objetivos de punto de recuperación en función de la importancia de los datos y ejecutar procesos de recuperación más rápidos mediante funcionalidades de autoservicio. Las copias de los datos de producción pueden utilizarse para el desarrollo, las pruebas, las herramientas de asistencia para el proceso de toma de decisiones, los informes y la aceleración del respaldo: SnapView SnapSure Protección continua de datos (CDP) de RecoverPoint/SE Herramientas de administración de replicaciones Application Protection Suite automatiza la creación de copias reiniciables de bases de datos coherentes con las aplicaciones, de manera que la base de datos de SQL Server se pueda recuperar a niveles de servicio determinados. En el caso de las copias reiniciables de bases de datos, los logs de transacciones de SQL Server se deben respaldar aparte: Para que la serie VNX incluya Replication Manager/AppSync y Data Protection Advisor para el análisis de replicación. Para que la serie VNXe incluya Replication Manager/AppSync. Para que la serie VMAX incluya Replication Manager/AppSync. A fin de lograr una recuperabilidad de un punto en el tiempo para Replication Manager o AppSync, los respaldos completos que se realizan con snapshots o clones deben combinarse con respaldos de logs de SQL Server. Restaurar bases de datos a un punto de una copia de seguridad, disponible en Microsoft MSDN Library, proporciona más información acerca de la recuperación de un punto en el tiempo. Mejores prácticas y reglas de diseño de Microsoft SQL Server para el 56 56

57 Recuperación de desastres de múltiples sitios Consideraciones Los requisitos más importantes para implementar una solución de recuperación de desastres de múltiples sitios que generalmente aparecen en los acuerdos de nivel de servicio (SLA) son: Objetivo de tiempo de recuperación (RTO): El tiempo que el usuario final de SQL Server puede tolerar la interrupción del servicio. Objetivo de punto de recuperación (RPO): La cantidad de pérdida de datos que se puede tolerar. Costo: El costo de la solución para que dicho acuerdo de nivel de servicio (SLA) sea posible. Con una solución de replicación sincronizada, los datos se reconocen únicamente cuando se asignan los datos del sitio remoto: Ventajas: Ausencia de pérdida de datos (0 RPO) en todo momento. Desventajas: Esto podría ralentizar el ambiente de producción con enlaces lentos a larga distancia. Es posible que la replicación síncrona a distancias superiores a 200 km no sea posible. Una solución de replicación sincronizada no tendrá limitaciones de distancia debido a que los datos se asignarán antes de que el sitio remoto envíe el reconocimiento: Ventajas: No hay limitaciones para la distancia de replicación. Desventajas: Podría presentar pérdidas de datos. La cantidad de datos/volúmenes protegidos es otra consideración del diseño de la protección de múltiples sitios: Se replican todos los datos. Se puede configurar en el sitio remoto para iniciarse automáticamente cuando se requiere failover, lo cual proporciona el RTO de manera instantánea. La transferencia de más datos mediante la red puede degradar el rendimiento de la producción. Elija solo los archivos de log y de bases de datos de usuarios que desea replicar. Una menor transferencia de datos mediante la red implica un mejor rendimiento de la producción y menos pérdidas de datos. Una menor cantidad de datos en el grupo de coherencia podría prolongar el procedimiento y el tiempo de recuperación (RTO más extensos). Para lograr el nivel más alto de RTO y RPO, elija la solución sincronizada, posiblemente con un producto de agrupación en clusters geográficamente dispersos, lo que brindará soluciones sin pérdida de datos con un RTO extremadamente reducido y con la mayoría de los procesos automatizados (VMAX SRDF/CE). Esto requiere la inversión en enlaces rápidos entre sitios. Para lograr un nivel superior de RTO y RPO, VPLEX brinda resultados similares con arreglos heterogéneos en el sitio remoto. RecoverPoint, Replicator, y el resto de las tecnologías de replicación de múltiples sitios de EMC pueden proporcionar RTO y RPO muy buenos con una intervención mínima por parte del usuario para volver a activar el sitio remoto cuando se requiere recuperación de desastres. Microsoft Exchange: Mejores prácticas Storage y reglas Best de Practices diseño de and Microsoft Design Guidance SQL Server for para EMC el Storage 57 57

58 Tecnologías de replicación de múltiples sitios Para extender la funcionalidad de configuraciones de clusters de failover de Windows de un único sitio y proporcionar protección adicional a múltiples sitios, EMC brinda las siguientes soluciones: VMAX SRDF/Cluster Enabler para el producto de agrupación en clusters geográficamente dispersos, MSCS. RecoverPoint brinda protección remota síncrona y asíncrona. La protección asíncrona puede replicar datos a cualquier distancia. VPLEX otorga acceso a una sola copia de datos en ubicaciones geográficamente diferentes de manera simultánea, lo cual permite una migración transparente de máquinas virtuales en ejecución entre los centros de datos. VNX Remote Protection Suite brinda protección mediante Replicator, MirrorView y RecoverPoint/SE CRR (protección de datos continua). VNXe Replicator brinda protección remota para iscsi y NAS VNX Remote Protection Suite VNX Remote Protection Suite ofrece replicación unificada de archivos y bloques, lo cual proporciona recuperación de desastres para ambientes NAS y SAN. Brinda protección de recuperación de desastres para cualquier host y aplicación sin compromiso; con una reversión a un punto en el tiempo inmediata y similar a DVR. Las funcionalidades incluyen compresión y deduplicación para la reducción de ancho de banda de la WAN, objetivos de punto de recuperación específicos de las aplicaciones y opciones de replicación para una o varias configuraciones. Este conjunto de aplicaciones para la serie VNX incluye Replicator, MirrorView/A, MirrorView/S y RecoverPoint/SE CRR (protección de datos continua). Este conjunto de aplicaciones para la serie VNXe incluye Replicator (iscsi y NAS). MirrorView replica los LUN de la base de datos de SQL Server a ubicaciones remotas para la recuperación de desastres. La replicación de MirrorView es transparente para el host. Si el host de producción o el sistema de almacenamiento de producción falla, los recursos de replicación remota realizan failover a la imagen espejeada secundaria. El software MirrorView ofrece dos productos de espejeado complementarios: MirrorView/S puede espejear de manera sincronizada y en tiempo real las imágenes de datos de los host LUN de producción a un almacenamiento secundario que se encuentra en un sitio remoto. Esto permite la ausencia de pérdida de datos ante una falla en el sitio de producción. MirrorView/A ofrece replicación a larga distancia basada en un modelo de actualización incremental periódico. Actualiza periódicamente la copia remota de los datos con todos los cambios que se produjeron en la copia local desde la última actualización. Esto puede ocasionar pérdida de datos ante una falla en el sitio de producción. MirrorView funciona bien en ambientes SQL Server pequeños y medianos. El documento EMC Business Continuity for Microsoft SQL Server 2008 Enabled by EMC CLARiiON and EMC MirrorView /A White Paper en el sitio web de EMC proporciona más información acerca de MirrorView. Mejores prácticas y reglas de diseño de Microsoft SQL Server para el 58 58

59 Herramientas para la automatización del reinicio La instancia de clusters de failover (FCI) de Microsoft brinda la automatización del reinicio volviendo a activar el sitio secundario de manera automática si el servidor del sitio primario queda inactivo. VMAX SRDF/CE para MSCS brinda una solución de agrupación en clusters, geográficamente dispersos con un alto nivel de automatización que evita la pérdida de datos y ofrece RTO extremadamente pequeños para la recuperación de desastres de SQL Server en un sitio diferente en el nivel de la instancia. Los grupos de disponibilidad continua de Microsoft proporcionan recuperación de desastres para servidores en múltiples sitios con una opción de failover automático en el nivel de base de datos si la base de datos primaria queda inactiva. Herramientas de automatización de instancias virtualizadas vcenter Site Recovery Manager (SRM) brinda recuperación de desastres automatizada para la recuperación rápida y eficiente de las aplicaciones críticas, como SQL Server, simplificando la recuperación y eliminando los errores humanos del proceso. El diseño de muestra y la arquitectura de referencia de Protección de la solución vcenter SRM proporcionan los detalles de configuración de SRM. Opciones de recuperación de desastres para SQL Server 2012 EMC ofrece varias opciones de recuperación de desastres para SQL Server La Tabla 15 describe algunas opciones usadas frecuentemente. Cada opción tiene ventajas y desventajas. La mejor opción para un ambiente está determinada por sus requisitos de recuperación de desastres específicos. Tabla 15. Ofertas de recuperación de desastres de EMC para SQL Server Oferta Método de replicación Descripción Grupos de disponibilidad continua Replicación continua nativa de SQL Server Integrados en SQL Server 2012 para obtener alta disponibilidad y recuperación de desastres Portabilidad de la base de datos Transferencia de servidores/sitios EMC RecoverPoint EMC VPLEX EMC RecoverPoint EMC VPLEX EMC VMAX SRDF/Cluster Enabler EMC Replicator Solo se replican los datos de SQL Server. Requiere ajustes de DNS cuando realiza failover a una réplica secundaria Los datos del SO y de SQL Server se replican y el failover incluye el inicio del servidor, el ajuste de IP y la actualización de DNS Recomendaciones de respaldo adicionales Siga estas recomendaciones adicionales para los respaldos de SQL Server a fin de reducir la degradación de rendimiento: Con tipos de carga medianos a altos, no realice respaldos directamente desde el SQL Server de producción. En vez de ello, monte un snapshot o clon de un punto en el tiempo en un servidor diferente y realice respaldos de ese servidor o con una copia secundaria en un grupo de disponibilidad continua. Calendarice los respaldos para que se lleven acabo durante horas de inactividad siempre que sea posible. Microsoft Exchange: Mejores prácticas Storage y reglas Best de Practices diseño de and Microsoft Design Guidance SQL Server for para EMC el Storage 59 59

60 Disponibilidad continua para la alta disponibilidad y la recuperación de desastres El grupo de disponibilidad continua es una solución de replicación continua nativa de Microsoft SQL Server que se encuentra integrada en SQL Server 2012 para obtener alta disponibilidad y recuperación de desastres. La implementación de los grupos de disponibilidad continua se adapta sin inconvenientes con las soluciones basadas en flash de EMC, como FAST VP, FAST Cache, flash XtremSW Cache y XtremSF. Disponibilidad continua con FAST Suite Cuando se configuran grupos de disponibilidad continua como parte del plan de HA y DR para la base de datos de SQL Server, se pueden usar las mejores prácticas que se muestran a continuación para el diseño de la copia secundaria de los grupos de disponibilidad continua: Si la copia secundaria no necesita admitir tipos de carga de creación de informes intensivos, puede residir en un almacenamiento de nivel inferior si puede admitir adecuadamente el tipo de carga requerido cuando ocurre un failover. Cuando se activa FAST VP o FAST Cache para la copia secundaria, el tipo de carga de solo lectura se puede mejorar. Si la copia secundaria no comparte el pool con la primaria, el sitio primario no se verá afectado. Esto también permite el máximo nivel de rendimiento cuando un failover requiere la copia secundaria. El documento EMC Mission Critical Infrastructure for Microsoft SQL Server 2012 White Paper proporciona un diseño de muestra, una arquitectura de referencia y otros de detalles de implementación. Disponibilidad continua con XtremSW Cache/XtremSF con tecnología flash Al implementar la tecnología flash del lado del servidor, el aumento del rendimiento en los tipos de carga de SQL Server permite un rendimiento mucho mayor con una latencia extremadamente baja. Las mejores prácticas y las consideraciones de diseño para XtremSW Cache y XtremSF son las siguientes: Por lo general, XtremSW Cache solo debe configurarse en el sitio primario, a menos que el sitio secundario requiera un aumento del rendimiento en el tipo de carga de solo lectura (solo cuando el tipo de carga es aleatorio), o se requiera un rendimiento mayor para realizar failovers al sitio secundario. Si las copias secundarias en los grupos de disponibilidad continua también poseen XtremSF con una red de alta velocidad y a corta distancia, la copia sincronizada se puede implementar con un impacto mínimo en el servidor de producción y una pérdida de datos ínfima cuando se realiza el failover. Varias copias secundarias de los grupos de disponibilidad continua tienen menos impacto en el servidor de producción al usar XtremSF para los sitios primario y secundario con un enlace de red rápido. XtremSW Cache se puede usar junto a FAST Suite de EMC para aumentar aún más el rendimiento de SQL Server. El documento EMC XtremSF Acceleration for Microsoft SQL Server 2012 White Paper proporciona más detalles acerca del diseño y la implementación de XtremSF. El documento EMC Infrastructure for High Performance Microsoft and Oracle Database System White Paper proporciona más detalles acerca del diseño y la implementación de XtremSW Cache. Mejores prácticas y reglas de diseño de Microsoft SQL Server para el 60 60

61 Conclusiones Resumen Este documento destaca los puntos de decisión clave en la planificación de una implementación de Microsoft SQL Server con los sistemas de almacenamiento de EMC. Hay varias opciones de configuración disponibles que se adaptan a la mayoría de los ambientes. Los productos de administración de datos y están diseñados para brindar una administración flexible de los ambientes SQL Server de manera que se adapten mejor a sus necesidades de negocio. Las mejores prácticas para el diseño del almacenamiento de SQL Server evolucionan constantemente. Gracias a la rápida optimización de las tecnologías de almacenamiento, es posible que las mejores prácticas tradicionales no se apliquen a todas las configuraciones. Este documento presenta las mejores prácticas actuales recomendadas por EMC para implementar SQL Server con la familia EMC VNX de almacenamiento unificado o la serie de almacenamiento EMC Symmetrix VMAX. El cumplimiento de estas reglas puede ayudarle de gran manera a lograr un ambiente SQL Server eficiente, de alto rendimiento y altamente disponible que cumpla sus requisitos. Este informe presenta los siguientes conceptos, principios y fórmulas para ayudarlo a: Comprender las características de I/O y ancho de banda de SQL Server. Aplicar las mejores prácticas para SQL Server y la serie de almacenamiento VNX o VMAX. Utilizar un componente básico de almacenamiento de SQL Server. Calcular los requisitos de I/O, capacidad y ancho de banda del almacenamiento. Validar su diseño de almacenamiento general. Familiarizarse con las diversas opciones de protección de datos para SQL Server. Información adicional Contáctese con su experto de EMC en SQL Server para obtener ayuda adicional en la implementación de Microsoft SQL Server con la familia EMC VNX o con la serie de almacenamiento EMC Symmetrix VMAX. Microsoft Exchange: Mejores prácticas Storage y reglas Best de Practices diseño de and Microsoft Design Guidance SQL Server for para EMC el Storage 61 61

62 Apéndice A: EMC Data Protection Advisor para análisis de replicación Descripción general Asistentes de descubrimiento y recopilación de datos Descubrimiento y recopilación de datos EMC Data Protection Advisor for Replication Analysis (DPA/RA) automatiza la recopilación de datos de las aplicaciones, hosts y arreglos, monitorea constantemente en busca de exposiciones y envía alertas ante SLA potencialmente perdidos y brechas en los objetivos de protección. Los dispositivos y las aplicaciones de monitoreo se automatizan con el asistente de recopilación de datos y el asistente de descubrimiento, el que configura DPA/RA con una serie de preguntas sobre el dispositivo o la aplicación que se desea monitorear. Después de definir un dispositivo o una aplicación con los asistentes, se agregan uno o más nodos de manera automática a la vista de configuración y al monitoreo de datos para cuando el recopilador se inicie. En este ejemplo, los arreglos de VNX se descubren y se monitorean de manera remota desde el recopilador que se ejecuta en el servidor DPA/RA. El sistema VNX se monitorea para la recuperabilidad y la creación de informes de análisis. El descubrimiento de los arreglos de almacenamiento desde DPA/RA requiere la instalación de EMC Solutions Enabler. Para instalar Solutions Enabler, siga los pasos a continuación: 1. Instale Solutions Enabler en el servidor DPA/RA. 2. Cree un archivo de texto con la siguiente información, una línea por arreglo (en este ejemplo, el nombre del archivo es Clar.txt): 3. Para registrar VNX, ejecute el siguiente comando en el servidor DPA/RA: 4. Para verificar que VNX se haya agregado correctamente, ejecute el siguiente comando: Descubrimiento de arreglos de almacenamiento Para descubrir arreglos de almacenamiento con DPA/RA, siga estos pasos: 1. Desde la barra de herramientas de DPA/RA, seleccione Herramientas, y luego escoja Asistente de descubrimiento. 2. Seleccione Arreglos de almacenamiento, vaya al panel Importar origen y haga clic en Siguiente. El asistente de descubrimiento muestra una lista de todos los arreglos de almacenamiento. Seleccione los arreglos de almacenamiento que dese importar y haga clic en Siguiente. Mejores prácticas y reglas de diseño de Microsoft SQL Server para el 62 62

63 3. Seleccione un calendario para la solicitud de recopilación de datos de recuperabilidad y haga clic en Finalizar. Configuración de Data Protection Advisor para el monitoreo de Microsoft SQL Server A fin de configurar el DPA/RA para el monitoreo de SQL Server, siga los pasos a continuación: 1. Desde la barra de herramientas de DPA/RA, seleccione Herramientas y luego escoja el Asistente de recopilación de datos. 2. Haga clic en Host y, a continuación, en Siguiente. Aparecerá el panel Detalles del host. Figura 9. Asistente de recopilación de datos 3. Ingrese el nombre, la descripción y el tipo de SO del host. 4. En la ubicación del recopilador (Figura 10), elija Sí para Hay algún recopilador instalado en el host o lo habrá en el futuro?, Figura 10. Ubicación del recopilador 5. Para recopilar los datos de utilización de memoria y rendimiento de CPU del SO, en Recopilación de datos: a. Para Desea recopilar información del sistema?, elija Sí. b. Para Desea monitorear las aplicaciones en este host?, elija Sí. Microsoft Exchange: Mejores prácticas Storage y reglas Best de Practices diseño de and Microsoft Design Guidance SQL Server for para EMC el Storage 63 63

64 c. Verifique Microsoft SQL Server, como se muestra en la Figura 11. Figura 11. Recopilación de datos 6. Para agregar una instancia de SQL Server, en el panel Recopilación de datos, haga clic en Agregar. Aparecerá el cuadro de diálogo Agregar instancia de SQL Server. Ingrese las credenciales del servidor SQL correspondientes y cierre el cuadro de diálogo. La Figura 12 muestra que SQL Server se agregó correctamente a la configuración del DPA/RA. Figura 12. Vista del servidor de la base de datos de DPA/RA Visualización y creación de informes de brechas y exposiciones DPA/RA brinda un mapa gráfico intuitivo de las relaciones entre el host y el almacenamiento. DPA/RA presenta las brechas y las exposiciones de recuperabilidad mediante informes y vistas para la resolución de problemas. DPA/RA puede monitorear varias condiciones de error de replicación. Mejores prácticas y reglas de diseño de Microsoft SQL Server para el 64 64

65 La Figura 13 muestra la configuración para establecer un informe calendarizado, mientras que la Figura 14 muestra los detalles de las exposiciones de SQL Server. Esto mapea el almacenamiento a RecoverPoint y luego a la máquina virtual de SQL Server que reside en el cluster ESX. Figura 13. Scheduled Report Editor muestra los sistemas SQL Server monitoreados Figura 14. Detalles de exposición de SQL Server A partir de estos, DPA/RA puede detectar que a la configuración le falta un volumen de aplicación, que la réplica está incompleta y que la aplicación posiblemente no sea recuperable. Puede verificar la configuración y corregirla según corresponda. Microsoft Exchange: Mejores prácticas Storage y reglas Best de Practices diseño de and Microsoft Design Guidance SQL Server for para EMC el Storage 65 65

66 Apéndice B: Herramientas para el monitoreo del rendimiento, optimización y dimensionamiento de SQL Server Descripción general SQL Server se puede monitorear en varios niveles de forma descendente, que incluyen: Aplicaciones que usan SQL Server para transacciones, bases de datos de SQL Server, hosts de Windows que alojan a SQL Server, hipervisores (si están virtualizados) y la capa de almacenamiento donde residen todos los datos. EMC recomienda recopilar los datos de rendimiento mientras se ejecutan los tipos de carga de producción. En algunos casos, las características de tipo de carga cambian periódicamente (por ejemplo, un sistema podría realizar operaciones de OLTP en la mañana, ETL y creación de informes en la tarde y respaldo en la noche). En este caso, debe capturar todas las fases del día, de manera que pueda dimensionar el sistema para que abarque todas las fases de producción. Al ejecutar un cluster de failover de Windows, EMC recomienda recopilar los datos de todos los nodos simultáneamente, de manera que los datos de rendimiento se recopilen incluso durante un failover de cluster. EMC también recomienda recopilar y analizar los contadores que indican la presión de CPU y memoria en la máquina virtual y física, ya que estos son factores que pueden afectar el rendimiento del almacenamiento. Por ejemplo, la adición de memoria a un servidor puede reducir considerablemente la I/O de almacenamiento, así como la eliminación del cuello de botella de un CPU puede aumentar significativamente la I/O de almacenamiento. La Table 16 indica las herramientas para cada nivel de uso. Tabla 16. Herramientas utilizadas para el monitoreo del rendimiento, optimización y dimensionamiento de SQL Server Nivel Herramienta Origen/enlaces Descripción Aplicación DBclassify EMC ( ains/zettapoint/index.htm Visite el sitio web de su país correspondiente) Monitorea constantemente los datos, aprende sus patrones y su comportamiento anterior y, a continuación, los clasifica y transfiere según las prioridades del negocio. Perfcollect EMC Workload Performance Assessment PAL EMC ( EMC ( Analizador del rendimiento de logs de código abierto ( Automatiza la recopilación de datos de rendimiento relacionados con el servidor SQL. Se usa principalmente para el dimensionamiento del ambiente virtual y del almacenamiento. También se conoce como Mitrend. Herramienta automatizada para la evaluación del rendimiento del tipo de carga en línea, que correlaciona y muestra información de rendimiento clave relacionada con el dimensionamiento. Se utiliza para la solución de problemas de rendimiento. Mejores prácticas y reglas de diseño de Microsoft SQL Server para el 66 66

67 Nivel Herramienta Origen/enlaces Descripción Base de datos de SQL Server Herramienta para dimensionam iento de VSPEX SQL EMC ( emc) Se puede usar para determinar la infraestructura comprobada VSPEX recomendada para SQL Server virtualizado, basado en los requisitos del usuario. T-SQL SQL Server Profiler SQL Database Tuning Advisor (DTA) Dynamic Management Views (DMV) Microsoft (se proporciona con la instalación del servidor SQL) Microsoft (servicios de análisis de SQL Server) Microsoft (servicios de análisis de SQL Server) Microsoft (servicios de análisis de SQL Server) Brinda los procedimientos Transact-SQL almacenados en el sistema para crear rastros en una instancia del motor de base de datos de SQL Server. Brinda capturas de SQL Trace y las reproduce en una interfaz gráfica del usuario. DTA brinda sugerencias para la optimización de SQL Server tales como la indexación y el particionamiento. Dynamic Management Views son estructuras de consultas que exponen información sobre las operaciones del servidor local y el estado del servidor. Host Windows Perfmon Windows performance monitor (se proporciona con la instalación de Windows Server) Perfmon puede rastrear las características de rendimiento de los tipos de carga de SQL Server. Hipervisor VMware vsphere Client GUI Resxtop/ Esxtop Interfaz gráfica del usuario del cliente de vsphere ESX/ESXi Herramienta principal para rastrear el rendimiento y configurar los datos en uno o más hosts ESX/ESXi. Proporciona una matriz de rendimiento, pero requiere acceso a la raíz. Hyper-V Perfmon Windows Performance Monitor Proporciona una matriz de rendimiento para Hyper-V y las máquinas virtuales. Caché de almacenamiento/ servidor Unisphere Analyzer Se incluye con los sistemas de Brinda funcionalidades de monitoreo del rendimiento para los sistemas de. Herramienta XtremCache Performance Predictor rch/?product_id=25208&text =predictor Proporciona una herramienta de predicción de rendimiento para EMC XtremSW Cache a fin de evaluar el ambiente SQL Server para XtremSW Cache. EMC Storage Configuration Advisor Disponible en la preventa y postventa de EMC Ayuda a definir las políticas de almacenamiento en niveles para un ambiente existente; Tier Advisor monitorea la I/O y recomienda los ajustes de la política de almacenamiento en niveles. Microsoft Exchange: Mejores prácticas Storage y reglas Best de Practices diseño de and Microsoft Design Guidance SQL Server for para EMC el Storage 67 67

68 Herramientas en el nivel de aplicaciones EMC DBclassify EMC DBclassify es una solución para la optimización de la base de datos que reduce el costo total de propiedad del almacenamiento de la base de datos y, al mismo tiempo, mejora el rendimiento de las aplicaciones de negocios. DBclassify monitorea constantemente los datos, aprende sus patrones y su comportamiento anterior y, a continuación, los clasifica y transfiere según las prioridades del negocio. DBclassify es ideal para las organizaciones de TI que enfrentan retos de administración, rendimiento y presupuesto asociados con bases de datos cada vez más complejas. DBclassify analiza y diferencia datos estructurados para proporcionar una visibilidad completa del uso real de la base de datos. Mediante un proceso de análisis integral, DBclassify rastrea y clasifica automáticamente cada objeto de la base de datos (tablas, índices y particiones), basado en la información de frecuencia de acceso y tiempo de espera de I/O. Además, DBclassify asocia cada objeto de la base de datos con usuarios y aplicaciones, basado en el uso real. Mediante una fórmula de clasificación única desarrollada por DBclassify, este proporciona una solución de almacenamiento en niveles óptima para las bases de datos en toda la empresa ofreciendo recomendaciones para el objeto, el espacio de tabla o el nivel de archivo, a la vez que funciona como un motor de políticas para la tecnología EMC FAST. En ambientes SQL Server, los datos se recopilan con una conexión de base de datos remota en vez de un agente monitoreado basado en servidor. El proceso de recopilación se ejecuta en el servidor del catálogo de DBclassify y extrae información desde la base de datos monitoreada. La Figura 15 muestra la arquitectura de DBclassify para SQL Server. Mejores prácticas y reglas de diseño de Microsoft SQL Server para el 68 68

69 Figura 15. Arquitectura de DBclassify para SQL Server A continuación, se presentan las mejores prácticas para DBclassify: Implemente DBclassify antes de una actualización/migración importante para realizar un análisis comparativo del perfil de I/O actual. Capture los tipos de carga máximos para análisis de I/O detallados. Genere políticas de FAST VP basadas en diversos niveles de porcentajes de umbrales y la capacidad de almacenamiento en niveles. Cree filtros de negocios que reflejen los tipos de carga y procesos de los clientes. Analice los datos de uso basado en los filtros de negocios. Clasifique los datos de uso en las categorías activo, semiactivo e inactivo. Determine el perfil y realice análisis comparativos de la actividad de I/O en todos los niveles de todas las bases de datos. Agrupe y clasifique las bases de datos según su importancia. Determine el perfil y realice análisis comparativos de la capacidad de almacenamiento en niveles según la clasificación de la base de datos. Puede obtener más información sobre DBclassify en el sitio web de DBclassify: Esta herramienta está disponible a través de su reseller o el ingeniero en sistemas de preventa de EMC. Microsoft Exchange: Mejores prácticas Storage y reglas Best de Practices diseño de and Microsoft Design Guidance SQL Server for para EMC el Storage 69 69

70 Perfcollect EMC brinda un conjunto de herramientas automatizadas denominado Perfcollect, que se encuentra disponible sin cargo. Perfcollect automatiza la recopilación de los contadores de CPU, memoria y almacenamiento de SQL Server, junto a otras informaciones de configuración que ayudan en el dimensionamiento del ambiente virtual y del almacenamiento. La herramienta se puede ejecutar en cualquier servidor con Windows 2003 o superior. Puede analizar manualmente la información de monitoreo del rendimiento con Windows Performance Monitor. Herramienta de evaluación del rendimiento de tipos de carga de EMC La herramienta de evaluación del rendimiento de tipos de carga de EMC se encuentra disponible para los partners de EMC. Esta herramienta automatizada en línea correlaciona y muestra la información de rendimiento clave relacionada con el dimensionamiento. Esta herramienta está disponible a través de su reseller o el ingeniero en sistemas de preventa de EMC. PAL Puede usar la herramienta Performance Analyzer of Logs (PAL) de código abierto para solucionar problemas de rendimiento (a diferencia del dimensionamiento para migraciones). Puede usar los datos recopilados con Perfcollect en conjunto con la herramienta PAL, la que se puede descargar desde el sitio web de CodePlex. Herramientas en el nivel de base de datos de SQL Server Herramienta para dimensionamiento de VSPEX SQL Server La herramienta para dimensionamiento de VSPEX SQL Server se encuentra disponible para dimensionar la infraestructura comprobada de VSPEX para SQL Server 2012 virtualizado, basada en los requisitos del usuario. También puede usar el cálculo de dimensionamiento para otros ambientes virtualizados en el almacenamiento EMC VNX. De la Figura 16 a la Figura 20 se proporcionan ejemplos de salida para el dimensionamiento de una base de datos OLTP de 500 GB con un máximo de 4,000 IOPS y un crecimiento anual del 10 % en un sistema VNX5400 con máquinas virtuales de referencia (RVMs). Figura 16. Configuración de VSPEX Mejores prácticas y reglas de diseño de Microsoft SQL Server para el 70 70

71 Figura 17. Requisitos de disco de VSPEX Figura 18. Entradas de SQL Server 2012 (instancia n.º 1) Figura 19. Requisitos de recursos de SQL Server 2012 Figura 20. Requisitos de disco de SQL Server Transact-SQL Microsoft SQL Server brinda los procedimientos Transact-SQL almacenados en el sistema para crear rastros de una instancia de la base de datos de SQL Server. Estos procesos almacenados en el sistema se pueden usar en sus propias aplicaciones para crear rastros manualmente, en vez de usar SQL Server Profiler. Esto le permite escribir aplicaciones personalizadas específicas para las necesidades de su empresa. La Tabla 17 indica los procedimientos almacenados para rastrear una instancia del motor de base de datos de SQL Server. Microsoft Exchange: Mejores prácticas Storage y reglas Best de Practices diseño de and Microsoft Design Guidance SQL Server for para EMC el Storage 71 71

72 Tabla 17. Procedimientos Transact-SQL almacenados para el rastro del servidor SQL Procedimiento almacenado fn_trace_geteventinfo (Transact-SQL) Tarea realizada Proporciona información acerca de los eventos incluidos en un rastro. fn_trace_getinfo (Transact-SQL) sp_trace_create (Transact-SQL) sp_trace_generateevent (Transact-SQL) sp_trace_setevent (Transact-SQL) sp_trace_setstatus (Transact-SQL) fn_trace_getfilterinfo (Transact-SQL) sp_trace_setfilter (Transact-SQL) Proporciona información acerca de un rastro específico para todos los rastros existentes. Crea una definición de rastro. El nuevo rastro se encontrará detenido. Crea un evento definido por el usuario. Agrega o elimina una clase de evento o una columna de datos en un rastro. Inicia, detiene o cierra un rastro. Proporciona información acerca de los filtros aplicados a un rastro. Aplica un filtro nuevo o modificado a un rastro. El rastro de Microsoft SQL proporciona más detalles. SQL Server Profiler SQL Server Profiler es una interfaz enriquecida para crear y administrar rastro y analizar y reproducir los resultados de rastros. Los eventos se guardan en un archivo de rastro que luego se puede analizar o usar para reproducir una serie de pasos específicos al intentar diagnosticar un problema. SQL Server Profiler se puede usar para las siguientes tareas: Revisión de consultas de problemas para identificar la causa. Búsqueda y diagnóstico de consultas lentas. Captura de la serie de declaraciones de Transact-SQL que ocasionan a un problema. Diagnóstico de problemas en un servidor de prueba mediante la reproducción del rastro guardado. Monitoreo del rendimiento de SQL Server para la optimización de los tipos de carga. Correlación de contadores de rendimiento para el diagnóstico de problemas. Microsoft SQL Server Profiler proporciona más detalles. Asistente para la optimización de motor de base de datos de SQL Server El Asistente para la optimización de motor de base de datos (DTA) de Microsoft analiza las bases de datos y realiza recomendaciones para optimizar el rendimiento de consultas. El DTA se puede usar para seleccionar y crear un conjunto óptimo de índices, vistas indexadas o particiones de tablas sin tener un conocimiento experto de la estructura de la base de datos o los aspectos internos de SQL Server. Mejores prácticas y reglas de diseño de Microsoft SQL Server para el 72 72

73 Con el DTA, puede realizar las siguientes tareas: Solucionar problemas de rendimiento de la consulta de un problema específico Optimizar un gran conjunto de consultas en una o más bases de datos Realizar un análisis exploratorio del tipo y si de modificaciones potenciales en el diseño físico Administrar espacio de almacenamiento Para obtener más información acerca de la optimización del diseño físico de las bases de para los tipos de carga de base de datos, consulte Asistente para la optimización de motor de base de datos. Vistas de administración dinámica de SQL Server Las vistas de administración dinámica (DMVs) de SQL Server son estructuras de consulta que exponen información sobre las operaciones del servidor local y el estado del servidor. La estructura de consulta incluye una interfaz para los conjuntos de filas de esquema que proporcionan información sobre metadatos y el monitoreo de una instancia de Analysis Services. Herramienta en el nivel de host de Windows Windows Performance Monitor (Perfmon) Windows Perfmon rastrea las características de rendimiento de los tipos de carga que se ejecutan en máquinas virtuales y físicas, así como Hyper-V. Se puede usar en tiempo real para ver el rendimiento actual, y también se puede configurar para registrar datos de rendimiento en un archivo a fin de verlos y procesarlos posteriormente. Debido que se recopila desde el mismo ambiente operativo de la aplicación, el monitor de rendimiento más bien refleja el rendimiento desde el punto de vista de la aplicación. La Tabla 18 indica los contadores más útiles para evaluar la actividad y el rendimiento de ambientes de almacenamiento de bloques (Fibre Channel, iscsi y SAS), los que se pueden ver desde los conjuntos de contadores DiscoFísico o DiscoLógico. Tabla 18. Contador Contadores útiles para evaluar el rendimiento del almacenamiento en ambientes SAN Transferencia promedio de discos/s Función medida Latencia de almacenamiento general Lectura promedio de discos/s Escritura promedio de discos/s Transferencia promedio de bytes/disco Bytes de discos/s Lecturas de discos/s Escrituras de discos/s Latencia de lectura Latencia de escritura Tamaño de I/O Rendimiento Lectura de IOPS Escrituras de IOPS Microsoft Exchange: Mejores prácticas Storage y reglas Best de Practices diseño de and Microsoft Design Guidance SQL Server for para EMC el Storage 73 73

74 SQL Server también admite el protocolo SMB para bases de datos y logs de transacciones, el cual requiere el conjunto de contadores Recursos compartidos de cliente de SMB, como se muestra en la Tabla 19. Tabla 19. Contador Contadores útiles para evaluar el rendimiento del almacenamiento en ambientes NAS Solicitud de datos promedio por segundo Función medida Latencia de almacenamiento general Lecturas promedio por segundo Escrituras promedio por segundo Bytes de datos promedio por solicitud Solicitudes de datos por segundo Solicitudes de lectura por segundo Solicitudes de escritura por segundo Latencia de lectura Latencia de escritura Tamaño de I/O Rendimiento Lectura de IOPS Escrituras de IOPS Microsoft definió las latencias de almacenamiento generalmente aceptables. La Tabla 20 indica las reglas para una investigación más a fondo; ciertas aplicaciones podrían beneficiarse de latencias menores o tolerar latencias altas. Tabla 20. Reglas de latencias para el almacenamiento de datos en ambientes OLTP de SQL Server Tipo de carga Latencia promedio Latencia máxima Base de datos <20 ms de lectura <50 ms de lectura Logs de transacciones <10 ms de escritura <50 ms de escritura Partición de sistema/página <10 ms de lectura/escritura <10 ms de lectura/escritura El contador Duración prevista de la página (PLE) es un buen indicador de la presión de memoria (mínimo de 300 ms). Para obtener más información sobre los contadores para monitorear el rendimiento relacionados con SQL Server y al almacenamiento, consulte: Monitoreo del rendimiento de SQL. Herramientas en el nivel de hipervisor Métricas clave para monitorear ESX En el ambiente VMware, las dos maneras de monitorear el rendimiento de ESX/ESXi son: Interfaz vsphere Client GUI: Herramienta principal para observar el rendimiento y configurar los datos en uno o más hosts ESX/ESXi No requiere privilegios de alto nivel para acceder a los datos Mejores prácticas y reglas de diseño de Microsoft SQL Server para el 74 74

75 Resxtop/Esxtop: Otorga acceso a los datos de rendimiento detallados de un host ESX/ESXi Proporciona acceso rápido a una gran cantidad de métricas de rendimiento Requiere acceso en el nivel de raíz Se ejecuta en modo interactivo, de lote o de reproducción La Tabla 21 muestra las métricas clave de los hosts y las máquinas virtuales que se deben monitorear en el ambiente ESXi. Tabla 21. Métricas clave que se deben monitorear en los hosts y las máquinas virtuales ESXi. Recursos Métrica Descripción CPU %USED Uso de CPU durante el intervalo de recopilación (%) Memoria Disco Red %RDY %SYS Swapin, Swapout MCTLSZ (MB) Reads/s, Writes/s DAVG/cmd KAVG/cmd GAVG/cmd MbRX/s, MbTX/s PKTRX/s, PKTTX/s %DRPRX, %DRPTX Tiempo de CPU empleado en el estado preparado (solo para máquinas virtuales) Porcentaje de tiempo empleado en el kernel de la máquina virtual de ESXServer Memoria que el host ESX intercambia de entrada/salida desde o hacia el disco (por máquina virtual o acumulativa en el host) Cantidad de memoria recuperada del pool de recursos en incrementos Lecturas y escrituras realizadas en el intervalo de recopilación Latencia promedio (ms) del dispositivo (LUN) Latencia promedio (ms) en el kernel de la máquina virtual, también conocido como tiempo de espera Latencia promedio (ms) en el huésped. GAVG = DAVG +KAVG Cantidad de datos transmitidos por segundo Paquetes transmitidos por segundo Paquetes descartados por segundo Microsoft Exchange: Mejores prácticas Storage y reglas Best de Practices diseño de and Microsoft Design Guidance SQL Server for para EMC el Storage 75 75

76 Métricas clave para monitorear Hyper-V El rendimiento de Hyper-V se puede monitorear con Perfmon. La Tabla 22 muestra las métricas clave de los hosts y las máquinas virtuales que se deben monitorear en el ambiente ESXi. Tabla 22. Métricas clave que se deben monitorear en los hosts y las máquinas virtuales de Hyper-V. Recursos Métrica Descripción CPU Memoria Disco Red \Processor(*)\% Processor Time \Hyper-V Hypervisor Logical Processor(_Total)\% Total Run Time \Memory\Available Mbytes \Memory\Pages/sec \Logical Disk(*)\Avg. sec/read, \Logical Disk(*)\Avg. sec/write \Network Interface(*)\Bytes Total/sec Utilización del tiempo de CPU Consumo inferior al 60 % = En buen estado Consumo entre un 60 % y un 89 % = Monitorear o tomar precauciones Consumo entre un 90 % y un 100 % = Crítico, el rendimiento se verá afectado de forma negativa La cantidad de memoria física disponible en el host de Hyper-V Un 50 % o más de memoria disponible = En buen estado Un 25 % de memoria disponible = Monitorear Un 10 % de memoria disponible = Advertencia Menos del 5 % de memoria disponible = Crítico, el rendimiento se verá afectado de forma negativa Mide la tasa de lectura o escritura de páginas al disco para resolver las fallas críticas de página. Menor que 500 = En buen estado De 500 a 1000 = Monitorear o tomar precauciones Mayor que 1000 = Crítico, el rendimiento se verá afectado de forma negativa Latencia de lectura y escritura. De 1ms a 15ms = En buen estado De 15ms a 25ms = Advertencia o monitorear Mayor que 26ms = Crítico, el rendimiento se verá afectado de forma negativa El porcentaje de utilización de la red Menos del 40 % de la interfaz consumida = En buen estado De un 41 % a un 64 % de la interfaz consumida = Monitorear o tomar precauciones De un 65 % a un 100 % de la interfaz consumida = Crítico, el rendimiento se verá afectado de forma negativa Mejores prácticas y reglas de diseño de Microsoft SQL Server para el 76 76

77 Recursos Métrica Descripción Network Interface(*)\Output Queue Length La longitud de línea de espera de salida mide la cantidad de hilos de ejecución en espera 0 en el adaptador de red = En buen estado De 1 a 2 = Monitorear o tomar precauciones Mayor que 2 = Crítico, el rendimiento se verá afectado de forma negativa Para obtener información detallada acerca de la implementación de Hyper-V, consulte el documento Virtualizing SQL Server 2008 using EMC VNX Series and Microsoft SQL Server 2008 R2 Hyper-V White Paper. Herramientas en el nivel de caché de almacenamiento/ servidor Unisphere Analyzer Unisphere Analyzer es una herramienta de monitoreo de rendimiento para arreglos de. Esta herramienta no solo muestra el rendimiento específico del almacenamiento, sino que también recopila y muestra cierta información de rendimiento en el nivel de servidor y máquina virtual. Para obtener más detalles, consulte el documento EMC Unisphere Unified Storage Management Solution White Paper. XtremSW Cache Performance Predictor EMC XtremSW Cache Performance Predictor es una herramienta que se puede usar para calcular los beneficios de la implementación de XtremSW Cache en un ambiente específico. La herramienta se ejecuta en dos pasos: 1. Recopilación de datos del lado del host mediante herramientas comunes de recopilación de rastros. 2. Análisis de rastros en un host o en cualquier laptop que cumpla los requisitos del sistema. La herramienta simula la manera en que XtremSW Cache opera y genera archivos de salida en formato PDF. No se requiere la compra de tarjetas o software para ejecutar esta herramienta gratuita, que puede ejecutarse en todos los sistemas operativos compatibles con XtremSW Cache (Windows y Linux). Crea un conjunto de tablas y gráficos que muestran si XtremSW Cache puede beneficiar al ambiente, y luego calcula las mejoras de rendimiento basado en: El tiempo de respuesta del host en observación La capacidad que usa el host El nivel de desviación Microsoft Exchange: Mejores prácticas Storage y reglas Best de Practices diseño de and Microsoft Design Guidance SQL Server for para EMC el Storage 77 77

78 La Figura 21 muestra la recopilación de datos de rendimiento y la configuración de la caché a partir de un ejemplo de salida en formato PDF generado por la herramienta. Figura 21. Ejemplo de salida de XtremSW Cache Performance Predictor: recopilación de datos de rendimiento Mejores prácticas y reglas de diseño de Microsoft SQL Server para el 78 78

79 La Figura 22 muestra la salida de la herramienta de distribución de I/O en el disco. Esta información se puede usar para ajustar el tamaño de página y el tamaño de I/O máximo de XtremSW Cache si se requiere un rendimiento mejorado (el tamaño predeterminado de la página es 8 kb y el tamaño de I/O máximo es 64 kb). Figura 22. Ejemplo de salida de XtremSW Cache Performance Predictor: Distribución del tamaño de I/O La Figura 23 muestra los análisis de lectura de caché. Si la herramienta indica una tasa de aciertos de caché muy alta, entonces el dispositivo con carga es un buen candidato para la aceleración de XtremSW Cache. Figura 23. Ejemplo de salida de XtremSW Cache Performance Predictor: predicción de aciertos de caché Microsoft Exchange: Mejores prácticas Storage y reglas Best de Practices diseño de and Microsoft Design Guidance SQL Server for para EMC el Storage 79 79

80 La Figura 24 muestra un cálculo de las mejoras de rendimiento que se pueden aplicar al disco gracias a la aceleración de XtremSW Cache. Este es un resultado simulado y constituye un buen punto de referencia para comprobar los beneficios de la aceleración de XtremSW Cache en la aplicación. Figura 24. Ejemplo de salida de XtremSW Cache Performance Predictor: predicción de la latencia de disco XtremSW Cache Performance Predictor se debe usar como una herramienta de planificación durante el diseño de XtremSW Cache para lograr el mejor rendimiento. EMC Storage Configuration Advisor EMC Storage Configuration Advisor es un nuevo componente de EMC Storage Resource Management (SRM) Suite que brinda una de las capacidades de administración que abarca desde las aplicaciones hasta el almacenamiento más integrales del sector a fin de obtener información general acerca de la administración en el nivel de servicio, las prioridades y las tareas a medida que los clientes crean su infraestructura de nube. SRM Suite combina los productos EMC ProSphere, EMC Storage Configuration Advisor y el recientemente adquirido EMC Watch4net en un solo paquete práctico de monitoreo y creación de informes. Este paquete ofrece administración del rendimiento, la capacidad y la configuración a gran escala para arreglos de y de otros fabricantes seleccionados para archivos y bloques. Storage Configuration Advisor brinda los siguientes beneficios: Administración de las políticas de mejores prácticas Storage Configuration Advisor proporciona plantillas incorporadas sobre las mejores prácticas generales del sector para permitirle definir y modificar las políticas que se alinean a los requisitos operacionales. Mejores prácticas y reglas de diseño de Microsoft SQL Server para el 80 80

81 Rastreo de cambios Storage Configuration Advisor recibe alertas cuando ocurre un problema que pone en riesgo los niveles de servicio mediante el rastreo continuo de cambios y la validación de la configuración. Análisis de configuración Storage Configuration Advisor valida la alineación estructural con políticas organizacionales y mejores prácticas del sector para relacionar los problemas de configuración con los cambios asociados. Validación de la matriz de soporte de EMC Storage Configuration Advisor descarga automáticamente la matriz de soporte de EMC y verifica el cumplimiento de SAN con las recomendaciones de EMC E-Lab. La Figura 25 muestra el tablero de Storage Configuration Advisor. Figura 25. Interfaz de Storage Configuration Advisor Microsoft Exchange: Mejores prácticas Storage y reglas Best de Practices diseño de and Microsoft Design Guidance SQL Server for para EMC el Storage 81 81

82 El tablero de Storage Configuration Advisor proporciona un snapshot general de la cantidad de cambios y el impacto de estos en el ambiente como se muestra en la Figura 26. Figura 26. Tablero de EMC Storage Configuration Advisor Mejores prácticas y reglas de diseño de Microsoft SQL Server para el 82 82

83 Apéndice C: Herramientas de generación de tipos de carga de SQL Server Descripción general A menudo de recomienda realizar pruebas al tipo de carga en una nueva plataforma de cómputo, red o almacenamiento antes de migrar el tipo de carga de producción. La Tabla 23 describe algunas herramientas de uso común a fin de validar los subsistemas de almacenamiento para SQL Server. Nota: Investigue los conjuntos de herramientas específicos para las aplicaciones antes de seleccionar los conjuntos de herramientas exclusivos para SQL o para el almacenamiento que se describen en la Tabla 23. Por ejemplo, puede usar Microsoft Visual Studio Team Test System (VSTS) para simular los tipos de carga de SharePoint de punto a punto, incluido el componente de SQL Server. Tabla 23. Herramientas comunes para la validación del subsistema de almacenamiento de SQL Server Herramienta Beneficios Desventajas SQL Profiler Duplica de manera precisa el tipo de carga de SQL Simula desviaciones Ejerce presión sobre el CPU y la memoria Relativamente complejo Requiere la experiencia de los administradores de bases de datos para su ejecución Requiere privilegios de administrador de SQL IOMeter SQLIO Es fácil de configurar Se puede optimizar Es aleatorio/secuencial Tasa de lectura/escritura No requiere la experiencia de los administradores de bases de datos Puede sobreponer tipos de carga que no sean de SQL (como respaldos) Facilidad de configuración Descubre rápidamente los límites de la infraestructura Las replicaciones de desviaciones resultan difíciles Las mediciones secuenciales resultan difíciles No ejerce la presión apropiada sobre el CPU No puede aproximar los tipos de carga de producción No ejerce la presión apropiada sobre el CPU SQLIOSim Prueba la estabilidad de I/O No puede validar el rendimiento del subsistema del disco Quest BenchMark factory Puede simular los tipos de carga TPCC, TPCE y TPCH Es una herramienta integral con apoyo comercial que también proporciona soporte técnico Genera un tipo de carga simulado que trabaja con SQL Server para probar todos los recursos del sistema Tarifa de licencia alta La instalación y configuración de la herramienta toma tiempo Debe instalar SQL Server en el servidor que se probará Microsoft Exchange: Mejores prácticas Storage y reglas Best de Practices diseño de and Microsoft Design Guidance SQL Server for para EMC el Storage 83 83

84 Presentación de herramientas SQL Server Profiler SQL Server Profiler es el método más preciso disponible para replicar un tipo de carga. Los administradores de bases de datos pueden usar SQL Server Profiler para capturar rastros y replicarlos en sistemas autónomos. La desventaja principal es que los tipos de carga en capas pueden ocurrir fuera del contexto de SQL Server (como los respaldos). Puede usar Microsoft SQL Server Profiler a fin de capturar las declaraciones de Transact-SQL que se envían a SQL Server y los conjuntos de resultados de SQL Server para estas declaraciones. Para obtener más información acerca de cómo usar SQL Server Profiler, consulte el artículo SQL Server Profiler en el sitio web de Microsoft MSDN. IOMeter IOMeter es una herramienta de código abierto usada para medir el rendimiento de I/O del disco. Con IOMeter, el administrador puede crear rápidamente uno o más trabajadores que simulan un tipo de carga personalizado. Generalmente, el tipo de carga se mide con un monitor de rendimiento o una herramienta basada en arreglos. Los inconvenientes son la dificultad de medir (y, por ende, replicar) las características de rendimiento del almacenamiento, como las desviaciones y secuencias, y sobrecargar los componentes del lado del servidor, como CPU y memoria. El sitio web de IOMeter tiene más información. SQLIO Microsoft desarrolló la herramienta SQLIO para evaluar la capacidad de I/O de una configuración predeterminada. Tal como lo indica su nombre, SQLIO es una herramienta valiosa para medir el impacto de I/O de sistemas de archivos en el rendimiento de SQL Server. SQLIO es una herramienta útil para verificar rápidamente los límites de lectura y escritura de un subsistema de discos. Tiene los mismos inconvenientes que IOMeter, pero es mucho menos configurable. SQLIO se puede ejecutar para crear I/O secuenciales o aleatorias, I/O de bloque grande o pequeño e I/O de lectura o escritura, aunque no al mismo tiempo. Por ejemplo, el uso de IOMeter para recrear un tipo de carga de base de datos que genera I/O de 32 kb, un 80 % aleatorias con una relación de lectura/escritura de 75:25 es una tarea trivial, usar SQLIO para hacer lo mismo resulta imposible. Puede descargar SQLIO desde SQLIOSim SQLIOSim es una herramienta diseñada para verificar la estabilidad, y no el rendimiento, de un subsistema de I/O. Esta herramienta es útil para verificar la conectividad y estabilidad de punto a punto antes o después de la implementación cuando se sospecha de posibles fallas en el subsistema de discos o en la red de almacenamiento. Para obtener más información sobre SQLIOSim y realizar su descarga, consulte el sitio web de Microsoft: Quest Benchmark Factory Quest Benchmark Factory está disponible para generar bases de datos y tipos de carga para bases de datos, incluso la base de datos de SQL Server. Esta herramienta proporciona tipos de carga TPCC, TPCE y TPCH con registro del rendimiento para ejecutar tipos de carga específicos. El soporte técnico está disponible cuando adquiere la licencia. Mejores prácticas y reglas de diseño de Microsoft SQL Server para el 84 84

85 Apéndice D: Diseños y arquitecturas de referencia para el almacenamiento de muestra Descripción general El último paso de la etapa de preproducción de implementación de SQL Server es validar el almacenamiento para que tenga la configuración correcta y mantener las cargas compatibles. Las arquitecturas de referencia y los informes técnicos de EMC sobre el diseño de almacenamiento de SQL Server están disponibles en el sitio web de EMC y en el sitio web de Microsoft. Este ejemplo demuestra un diseño detallado para el almacenamiento en múltiples niveles de un tipo de carga OLTP de SQL Server en un ambiente de nube más grande ubicado en los sistemas de almacenamiento VMAX y en otras aplicaciones. Para obtener más información, consulte el documento EMC Virtual Infrastructure for Microsoft Applications White Paper. Diseño de almacenamiento de Microsoft SQL Server en VMAX con FAST VP Para mantener la flexibilidad, el rendimiento y la granularidad de recuperación, asegúrese de que el dimensionamiento de almacenamiento y la configuración de back-end para SQL Server sean los óptimos. Esta sección proporciona el dimensionamiento para SQL Server en una configuración FAST VP. Fase 1: recolectar requisitos del usuario La Tabla 24 indica la configuración de SQL que cumpla con los requisitos de usuario. Tabla 24. Requisitos de usuario para la configuración de SQL Elemento Equipo del usuario Cantidad total de usuarios 100,000 Usuarios de base de datos por servidor 20,000; 30,000; 50,000 respectivamente IOPS totales 6,000 Cantidad de bases de datos 3 Perfil de base de datos RPO RTO Activo/Semiactivo/Inactivo Remoto: menos de cinco minutos, local: seis horas 60 minutos Relación de lectura/escritura 85:15 Respaldo/restauración requerido Sí (VSS de hardware) Fase 2: diseñar la arquitectura del almacenamiento según los requisitos del usuario EMC le recomienda calcular los discos para que SQL Server pueda satisfacer los requisitos de I/O y luego calcular los requisitos de espacio. A continuación, se muestra el cálculo de dimensionamiento para esta solución. Microsoft Exchange: Mejores prácticas Storage y reglas Best de Practices diseño de and Microsoft Design Guidance SQL Server for para EMC el Storage 85 85

86 Cálculo de IOPS Calcule IOPS de la siguiente manera: La I/O total para 225,00 usuarios es el 20 % = = 7200 IOPS Calcule la I/O de back-end para los requisitos de la política FAST VP para cada nivel. En este ejemplo, el dimensionamiento de FAST VP se basa en la desviación de I/O de un 75 % SATA, un 15 % Fibre Channel y un 10 % flash: I/O de back-end total para RAID 1/0 de SATA = (el 10 % de 7,200) = ( ) + 2 ( ) = 828 I/O total para RAID 5 de Fibre Channel = (el 15 % de 7,200) = ( ) + 4( ) = 1,566 I/O total para RAID 5 de flash = (el 75 % de 7200) = ( ) + 4 ( ) = 7,308 El gran total de I/O de back-end es de 10,224 Los discos SATA que se requieren para dar servicio a 808 I/O en una configuración de RAID 1/0 son 828/50= aproximadamente 17 redondeado a 18 para RAID 1/0 Los discos de Fibre Channel que se requieren para dar servicio a 2,088 I/O en una configuración de RAID 5 son 1566 / 130= aproximadamente 12 Los discos de flash que se requieren para dar servicio a 7308 I/O en una configuración de RAID 5 son 7308/1800= aproximadamente 4 Nota: Cuando se realizan los cálculos para el rendimiento, el nivel más rápido debe dar servicio a la cantidad máxima de I/O. Desde una perspectiva de dimensionamiento de I/O, al usar la configuración de políticas antes mencionada, se requerirán los siguientes discos para el ambiente: 18 discos SATA de 2 TB y 7,200 r/min 12 discos de Fibre Channel de 600 GB y 10,000 r/min 4 discos flash de 200 GB Cálculo de capacidad Tamaño de la base de datos de usuario Activo, de 200 GB Semiactivo, de 300 GB Inactivo, de 600 GB Calcule el tamaño de LUN de la base de datos según los tamaños de base de datos de usuario: Tamaño de LUN de base de datos = <Tamaño de base de datos> + porcentaje del requisito de espacio libre x (20 por ciento) Activo: el 20 % = 360 GB Semiactivo: el 20 % = 480 GB Inactivo: el 20 % = 840 GB Mejores prácticas y reglas de diseño de Microsoft SQL Server para el 86 86

87 Calcule los tamaños de LUN de tempdb y de log para cada una de las bases de datos. Los tamaños de log y de tempdb se calculan como el 20 % del tamaño de la base de datos: Tamaño de log y de Tempdb Base de datos activa: el 20 % de 300 = 60 GB Base de datos semiactiva: el 20 % de 400 = 80 GB Base de datos inactiva: el 20 % de 700 = 140 GB El log y la Tempdb de la base de datos de usuario se disponen en LUN separados para cada base de datos. Basándose en esto, los LUN de log se dimensionan en 120 GB para las bases de datos activas y semiactivas y en 140 GB para las bases de datos inactivas: El tamaño total de la base de datos es la suma de las bases de datos = 2448 GB La capacidad útil disponible por unidad SATA de 2 TB es de 1754 GB La capacidad útil disponible por unidad de Fibre Channel de 600 GB y 10,000 r/min es de 536 GB La desviación de la política de FAST que se usa es el total de un 75 % SATA, un 15 % Fibre Channel y un 10 % flash Capacidad para cada nivel: SATA = = 1836 GB Fibre Channel = = 368 GB Flash = = 245 GB El requisito de disco es <Capacidad total> / <Capacidad utilizable> Discos requeridos para cada nivel: SATA (espejeado) = 4 Fibre Channel (RAID5 3+1) = 4 Flash (RAID5 3+1) = 4 Nota: Cuando se realizan los cálculos para la capacidad, el nivel más lento tiene que alojar a la mayoría de los datos. Desde una perspectiva de dimensionamiento de capacidad, al usar la configuración de políticas antes mencionada, se requieren los siguientes discos para el ambiente: 4 discos SATA de 2 TB y 7,200 r/min 4 discos Fibre Channel de 600 GB y 10,000 r/min 4 discos flash de 200 GB Microsoft Exchange: Mejores prácticas Storage y reglas Best de Practices diseño de and Microsoft Design Guidance SQL Server for para EMC el Storage 87 87

88 La mejor configuración se basa en los requisitos de capacidad y de I/O, como se aprecia en la Tabla 25. Tabla 25. La mejor configuración, basada en los requisitos de capacidad y de I/O Base de datos de SQL Server de 1 TB (200 GB, 300 GB, 500 GB) Cantidad de discos necesarios para satisfacer las necesidades de I/O y de capacidad Tamaños de LUN delgado (base de datos) Tamaños de LUN delgado (log) 18 discos SATA de 2 TB y 7,200 r/min 12 discos Fibre Channel de 600 GB y 10,000 r/min 4 discos flash de 200 GB Activo, 360 GB Semiactivo, 480 GB Inactivo, 840 GB Activo, 120 GB Semiactivo, 120 GB Inactivo, 140 GB Enfoque de diseño del componente básico para data warehouse Esta solución describe un almacenamiento de diseño de componentes básicos de un data warehouse para conseguir flexibilidad y escalabilidad de rendimiento. Para obtener más información, consulte el documento SQL Server 2012 Data Warehouse White Paper. Consideraciones para el diseño de un componente básico La infraestructura que admite data warehouse, incluidos el servidor, la red, el almacenamiento y la aplicación, debe proporcionar una solución sólida, potente y flexible. Este diseño es para data warehouses en un ambiente virtualizado que proporciona un rendimiento predecible. Debe considerar los siguientes criterios para este diseño. Ancho de banda proporcional y predictivo Diseñar para el ancho de banda, no para la capacidad de la base de datos. En este ejemplo, para completar todas las consultas de DSS en este conjunto de aplicaciones de prueba en una ventana de 12 a 14 horas, el ancho de banda deseado es de 100 MB/s para una base de datos de 500 GB, 200MB/s para una base de datos de 1 TB o 400 MB/s para una base de datos de 2 TB. Verificación del rendimiento de disco. Para un tipo de carga DSS con I/O secuenciales de solo lectura de 64,000 r/min, los discos SAS de 600 GB y 10,000 r/min que se usaron en este ejemplo proporcionan IOPS promedio de 320 y un ancho de banda de 20 MB/disco. Se puede calcular el ancho de banda para un tamaño determinado de I/O mediante IOPS: Ancho de banda = tamaño de I/O promedio IOPS Cálculo de los requisitos de almacenamiento del componente básico. Con un tipo de carga DSS de I/O de solo lectura, en una configuración RAID 5 (4+1), los discos SAS de 600 GB y 10,000 r/min necesarios serían: Cantidad de discos = ancho de banda requerido / ancho de banda por disco Para el componente básico de 500 GB con un ancho de banda de 100 MB/s, se requieren cinco discos SAS de 600 GB y 10,000 r/min. Mejores prácticas y reglas de diseño de Microsoft SQL Server para el 88 88

89 Para el componente básico de una base de datos de 1 TB con un ancho de banda de 200 MB/s, se requieren 10 discos. Para el componente básico de 2 TB con un ancho de banda de 400 MB/s, se requieren 20 discos. Escalabilidad de las máquinas virtuales Los requisitos de escalabilidad de la máquina virtual son: Los recursos de máquina virtual como la CPU virtual y la asignación de memoria deben ser parte del componente básico. El componente básico debe tener la capacidad de escalamiento vertical (agregar un componente a la misma máquina virtual) y escalamiento horizontal (agregar el componente básico a otra máquina virtual) para todo con una degradación mínima del rendimiento. Recurso adecuado Confirme que el diseño del componente básico de los discos y de la memoria se utilice adecuadamente de la siguiente manera: La utilización de disco usa adecuadamente el recurso de disco y deja espacio para cualquier actividad de disco máxima posible. La utilización de memoria del sistema es compatible con el tipo de carga diseñado con actividades de carga máxima previstas. La utilización del procesador de la CPU virtual es compatible con el tipo de carga diseñado con actividades de carga máxima previstas. El diseño de Tempdb tiene la capacidad y el rendimiento suficiente para ser compatible con el tipo de carga de la consulta de la base de datos. El tipo de carga DSS tiene una alta exigencia relativa para Tempdb. Utilización de discos balanceados Cree LUN de base de datos en la mayor cantidad de buses posible para evitar un tipo de carga desbalanceado. Esta asignación puede tener posibles beneficios de alta disponibilidad. Detalles del diseño de un componente básico Los componentes básicos mencionados aquí se designan de la siguiente manera: El ancho de banda determinado es de 100 MB/s por LUN (R5 4+1 discos SAS de 600 GB y 10,000 r/min). Si desea un ancho de banda mayor use más discos para el componente básico. En este ejemplo, el tamaño de la base de datos que se escaló para cada LUN (R5 4+1) es de 500 GB. Para una base de datos de 1 TB, se crean dos LUN (10 discos) para los archivos de base de datos. Para una base de datos de 2 TB, se crean cuatro LUN (20 discos). Para admitir el ancho de banda determinado de 100 MB/s por LUN, asigne un mínimo de dos CPU virtuales y 8 GB de memoria en proporción con el componente básico. O una CPU virtual y 4 GB de memoria por cada 50 MB/s de ancho de banda. Microsoft Exchange: Mejores prácticas Storage y reglas Best de Practices diseño de and Microsoft Design Guidance SQL Server for para EMC el Storage 89 89

90 La Figura 27 muestra los tres componentes básicos de este ejemplo según el principio de diseño. La Tabla 26 indica los detalles de los tres componentes básicos. Figura 27. Tabla 26. Tres componentes básicos probados Las configuraciones del componente básico Configuración Componente básico de 500 GB Componente básico de 1 TB Componente básico de 2 TB Tamaño de la base de datos Ancho de banda determinado (MB/s) Diseño del LUN de base de datos Diseño de log Diseño de Tempdb Configuración del disco 500 GB 1 TB 2 TB x LUN de datos de 2 TB 8 x archivo de datos de 80 GB 1 LUN de log (archivo de log de 5 GB) 1 LUN de datos (1 x archivo de datos de 100 GB) 1 LUN de log (archivo de log de 2 GB) 2 x LUN de datos de 2 TB 8 x archivos de datos de 126 GB 1 LUN de log (archivo de log de 12 GB) 1 LUN de datos (2 x archivos de datos de 100 GB) 1 LUN de log (archivo de log de 2 GB) 4 x LUN de datos de 2 TB 16 x archivos de datos de 126 GB 1 LUN de log (archivo de log de 12 GB) 1 LUN de datos (4 x archivos de datos de 100 GB) 1 LUN de log (archivo de log de 2 GB) 5 discos SAS 10 discos SAS 20 discos SAS Memoria (GB) CPU virtual (2.4 GHz) Nota: Los LUN de log en un ambiente de data warehouse no se utilizan demasiado, por lo que varios componentes básicos en la misma máquina virtual podrían potencialmente compartir el mismo LUN de log. Mejores prácticas y reglas de diseño de Microsoft SQL Server para el 90 90

91 La Tabla 27 define los requisitos mínimos para los componentes básicos y las máquinas virtuales en este ejemplo. Tabla 27. Diseño del componente básico Por máquina virtual Memoria (GB) CPU (core) Mínimo /TB /(100 MB/s) GB (100 MB/s) TB (200 MB/s) TB (400 MB/s) TB (800 MB/s) TB (800 MB/s) Cantidad de discos RAID 5 (4+1) Implementación de componentes básicos La Figura 28 muestras las dos maneras para implementar componentes básicos: Diseño de escalamiento vertical que pone a los componentes básicos en la misma máquina virtual. Diseño de escalamiento horizontal que pone cada componente básico en diferentes máquinas virtuales. Figura 28. Escalamiento vertical y horizontal de los componentes básicos Microsoft Exchange: Mejores prácticas Storage y reglas Best de Practices diseño de and Microsoft Design Guidance SQL Server for para EMC el Storage 91 91

92 Diseño de escalamiento vertical El diseño de escalamiento vertical podría ahorrar el costo de licencia para el sistema operativo. Debido a que los recursos de memoria y de CPU virtuales están integrados al diseño del componente básico, estos recursos crecen proporcionalmente con la implementación del componente básico para las mismas máquinas virtuales que se requieren para admitir el componente básico. Diseño de escalamiento horizontal En una implementación de escalamiento horizontal de los componentes básicos, se debe considerar la capacidad de CPU virtual y de memoria del servidor ESXi para admitir la cantidad deseada de componentes básicos. Los recursos del sistema como CPU virtual y memoria están dentro del componente básico. Agregar un componente básico en un escalamiento vertical (a la misma máquina virtual) o en un escalamiento horizontal (a una máquina virtual separada) requiere los mismos recursos, a menos que se cree bajo los requisitos mínimos para una máquina virtual. De esta manera, cuando se tengan componentes básicos pequeños (como una base de datos de menos de un 1 TB con un ancho de banda de 200 MB/s), quizá sea mejor usar el modelo de escalamiento vertical para reducir el desperdicio de los recursos de sistema de la máquina virtual como la memoria y CPU. En un ambiente de tamaño medio como es el caso de esta solución, las organizaciones deberían considerar cuidadosamente el enfoque que más les convenga. Diseño de asignación de máquina virtual y LUN de SQL Server La Tabla 28 y la Figura 29 muestran la configuración de la máquina virtual y la asignación de disco para las diferentes bases de datos utilizadas en este ejemplo. Probamos diferentes maneras para diseñas e implementar un componente básico con un rendimiento razonable. Figura 29. Implementación del componente básico de la solución Nota: En una de las máquinas virtuales, cinco bases de datos de diferentes tamaños y requisitos de ancho de banda ejecutaban un tipo de carga intensivo al mismo tiempo. Por lo tanto, competirán por los recursos y es posible que sufran contenciones en los tiempos de mayor actividad. Incluso en esta situación, SQL Server mantiene un buen rendimiento en la máquina virtual. Mejores prácticas y reglas de diseño de Microsoft SQL Server para el 92 92

93 Tabla 28. Host ESXi 01 (40 cores, 256 GB RAM) Implementación del concepto básico de la solución en la máquina virtual y en el servidor ESXi Asignación CPU (core) Memoria (GB) Tamaño de la base de datos (TB) Cantidad de discos VM VM Ancho de banda (MB/S) ESXi 02 (80 cores, 512 GB RAM) VM VM Total 4 máquinas virtuales noviembre 180 3,600 Solución de protección de SQL Server Esta solución implementó protección continua para SQL Server gracias al uso de EMC RecoverPoint con Replication Manager y de la administración de recursos de almacenamiento de vcenter. Para obtener más información, consulte el documento Continuous Data Protection for Microsoft SQL Server Enabled by EMC RecoverPoint, EMC Replication Manager, and VMware White Paper. EMC RecoverPoint Esta sección describe la configuración requerida para EMC RecoverPoint en el momento de implementar la protección. Proceso de replicación local (CDP) La Figura 30 muestra el proceso de RecoverPoint Continuous Data Protection (CDP) que replica de manera sincrónica los datos de los volúmenes de producción (origen) en los volúmenes de destino locales, a la vez que mantiene una recuperación reversible a través del almacenamiento de registro. Microsoft Exchange: Mejores prácticas Storage y reglas Best de Practices diseño de and Microsoft Design Guidance SQL Server for para EMC el Storage 93 93

94 Figura 30. Flujo de datos de la replicación local (CDP) de EMC RecoverPoint Proceso de replicación remota (CRR) La Tabla 22 muestra el proceso de RecoverPoint Continuous Remote Replication (CRR) que replica bloques de datos en un arreglo de almacenamiento de sitio remoto. Los datos se pueden replicar de manera sincrónica a través de una conexión de Fibre Channel de hasta 200 km/4 ms o de manera asincrónica mediante una conexión IP, que en este ejemplo se probó hasta un viaje de ida y vuelta de 64 ms/6,400 km. Mejores prácticas y reglas de diseño de Microsoft SQL Server para el 94 94

95 La Figure 31 muestra una comparación entre los procesos de CDP y CRR con replicación remota de RecoverPoint. Figura 31. Flujo de datos de la replicación remota (CRR) de RecoverPoint Tabla 29. Operaciones Una escritura a un LUN protegido por RecoverPoint Los procesos de CDP y CRR para replicación local y remota de RecoverPoint: Flujo de datos de CDP (replicación local de EMC RecoverPoint) El splitter de RecoverPoint intercepta la escritura. Flujo de datos de CRR (replicación remota de RecoverPoint) El splitter de RecoverPoint intercepta la escritura. El splitter divide a la escritura Reconocimiento El registro de fecha y hora y el marcador se escriben en el registro De forma simultánea, la envía al volumen de producción y al RPA local Las escrituras se confirman desde el RPA y el LUN de producción de manera inmediata. El RPA escribe los datos en el volumen del registro, junto con los metadatos del registro de fecha y hora y del marcador. De forma simultánea, la envía al volumen de producción y al RPA local. Replicación asíncrona: Las escrituras se confirman desde el RPA y el LUN de producción de manera inmediata. Replicación remota síncrona: El reconocimiento (ACK) se lleva a cabo cuando se recibe la escritura en el sitio remoto. El RPA local combina la escritura con otras escrituras, secuencias y registra la fecha y hora de la escritura. El paquete se comprime y se transmite con una suma de verificación para su envío mediante IP al RPA remoto. Microsoft Exchange: Mejores prácticas Storage y reglas Best de Practices diseño de and Microsoft Design Guidance SQL Server for para EMC el Storage 95 95

96 Operaciones Finalizada Flujo de datos de CDP (replicación local de EMC RecoverPoint) N/D N/D Una vez que los datos están almacenados de forma segura en el registro, se distribuyen datos coherentes con el orden de escritura a la réplica local. Flujo de datos de CRR (replicación remota de RecoverPoint) El RPA remoto recibe el paquete, verifica la suma de verificación para asegurarse de que no haya corrupción en la transmisión y luego descomprime los datos. El RPA remoto escribe los datos en el volumen del registro. Después de que los datos se escriben en el volumen del registro, se distribuyen a los volúmenes remotos. El orden de escritura se conserva durante esta distribución. Grupos de consistencia Un grupo de coherencia es un contenedor lógico dentro de RecoverPoint, lo cual asegura que todos los dispositivos de ese grupo de coherencia sean coherentes (fidelidad del orden de escritura) entre ellos. La versión 3.3 de RecoverPoint admite hasta 128 grupos de coherencia. Para las máquinas virtuales de SQL Server, las políticas de Prioridad de asignación de recursos se definen según los requisitos del volumen: Archivo de SO y de página: los volúmenes de archivos de sistema operativo y de página que tengan una relación natural se mantienen juntos. Con una baja tasa de cambio, la prioridad de asignación de recursos se establece en Normal. Tempdb/Systemdbs: Tempdb y Systemdb se replican para volver a activar todas las máquinas virtuales en el sitio remoto. Como Systemdb no cambia mucho y Tempdb se vuelve a crear cada vez que se reinicia una instancia de SQL Server, esto es prescindible, por lo que la prioridad de asignación de recursos se establece en Baja. Datos/Logs: los datos del usuario son lo más importante del ambiente, así que la prioridad de asignación de recursos se establece en Crítica. La Figure 32 muestra la relación entre los volúmenes NTFS de Windows, sus grupos de coherencia relevantes y la configuración de política para el grupo de coherencia que se definió para las políticas locales y remotas. Mejores prácticas y reglas de diseño de Microsoft SQL Server para el 96 96

97 Figura 32. Volúmenes de Windows para el mapeo del grupo de coherencia de RecoverPoint Cuando se usa la replicación continua local y remota (CLR) para cada grupo de coherencia, se configuraron tres registros: dos en el sitio de producción para admitir a CDP y CRR y una en el sitio de recuperación para CRR. Conjuntos de grupos La función de conjuntos de grupos de RecoverPoint Group Sets permite un marcado coherente entre varios grupos de coherencia. Se puede crear un conjunto de grupo para contener grupos de coherencia para una única máquina virtual. Para acceder a una copia de los datos replicados, active la opción Acceso a imágenes en cada uno de los grupos de coherencia durante el tiempo requerido (Figura 33). Los tres grupos de coherencia se revierten a la misma imagen de destino para garantizar que los volúmenes en el sitio de recuperación de desastres sean máquinas virtuales TPCE1 completamente coherentes y que el servidor se pueda reiniciar en un estado coherente con las fallas. Figura 33. RecoverPoint Management Console: grupos de coherencia Microsoft Exchange: Mejores prácticas Storage y reglas Best de Practices diseño de and Microsoft Design Guidance SQL Server for para EMC el Storage 97 97

98 Ventanas de dimensionamiento y protección del registro Una consideración fundamental es el dimensionamiento de los registros de RecoverPoint. Deben contar con características de rendimiento y capacidad para manejar el rendimiento total de la escritura y para almacenar todas las escrituras del LUN que se está protegiendo. Las dos preguntas más importantes son: Qué tasa de cambio genera el LUN de origen? Qué ventana de retención se necesita? Para calcular la capacidad del registro, hay que medir la tasa de cambio en los LUN de producción. Los contadores de Perfmon se configuran en cada SQL Server para capturar el ancho de banda de la escritura en megabytes por segundo (MB/s). Los datos por segundo se pueden encontrar con Unisphere Analyzer, mientras que la pestaña Stats brinda una ventana en un punto en el tiempo para ver lo que hace cada procesador de almacenamiento. La fórmula de dimensionamiento del volumen es: Tamaño del registro = (datos por segundo) (tiempo requerido de reversión en segundos) (1 tamaño del log en el lado de destino) x 1.05 Se debe reservar un 20 % del registro para el log en el lado de destino y un 5 % para necesidades del sistema interno. Por ejemplo, para admitir un requisito de reversión de 24 horas (86,400 segundos), con 5 megabits por segundo (Mb/s) de nuevas escrituras de datos a los volúmenes de replicación en un grupo de coherencia, el cálculo es: 5 86,400 = 567,000 MB = GB (aproximadamente 70 GB) (1 0.2) x 1.05 Para la solución, se dimensionaron todos los registros para que RecoverPoint pueda revertir al menos siete días. Mejores prácticas y reglas de diseño de Microsoft SQL Server para el 98 98

99 Integración de RecoverPoint con VMware vcenter La vista del servidor vcenter muestra los datos del servidor vcenter a través de la interfaz gráfica del usuario (GUI) de RecoverPoint. Además de mostrar los servidores ESX y todas sus máquinas virtuales, las áreas de almacenamiento de datos y las unidades de RDM, la vista de los servidores vcenter también muestra el estado de replicación de cada volumen. El estado de protección de cada máquina virtual se mide varias veces por hora. Esta ventana se actualiza cuando se crea una nueva máquina virtual o cuando el estado de protección de una máquina virtual cambia. La vista de los servidores vcenter es solo para monitorear (de solo lectura). Por ejemplo, como se aprecia en la Figura 34, RecoverPoint Management Application muestra que todos los volúmenes relevantes para TPCE1 y TPCH2 se replicaron con éxito. Los respectivos grupos de coherencia, la copia que se replica y los conjuntos de replicación asociados se muestran en la Figura 34. Figura 34. Vista de los servidores vcenter en RecoverPoint Management Application Failover de RecoverPoint Cuando falla una máquina virtual, se puede usar el proceso de failover de RecoverPoint para abrir el sitio de recuperación de desastres. Microsoft Exchange: Mejores prácticas Storage y reglas Best de Practices diseño de and Microsoft Design Guidance SQL Server for para EMC el Storage 99 99

100 Figura 35. Proceso de failover de RecoverPoint En este escenario (como se muestra en la Figura 35), use los pasos de la Tabla 30 para el proceso de failover cuando falle una máquina virtual en el sitio de producción. Tabla 30. Pasos del failover Proceso de failover de RecoverPoint Activar el acceso a la imagen del último marcador. Detalles Esto proporciona acceso a la imagen de lectura/escritura de la copia CRR para los servidores ESX remotos y permite el montaje de los volúmenes de VMFS en el vcenter remoto. Confirmar que el failover esté configurado en la réplica remota. Confirmar que el almacenamiento remoto sea completamente accesible para el servidor ESX. Registrar la máquina virtual del sitio remoto. Iniciar la máquina virtual. En RecoverPoint Management Application o con la consola de administración de Unisphere, seleccione failover a la réplica remota. Reexaminar todo el almacenamiento en el servidor ESX remoto a través de la consola remota de vcenter. Haga clic con el botón secundario en el archivo VMX del área de almacenamiento de datos VMFS de LUN del SO y seleccione Realizar inventario de la máquina virtual. Conecte la tarjeta de interfaz de red virtual (vnic) a la red para volver a activar el acceso IP a la máquina virtual y a la base de datos. Mejores prácticas y reglas de diseño de Microsoft SQL Server para el

101 Puede realizar failback cuando apaga la máquina virtual en el sitio remoto y repite los pasos ya mencionados para el sitio de producción. Esta solución permite una portabilidad completa de sus instancias de SQL Server entre los sitios. Subred diferente Si se produce un failover de la máquina virtual a un cluster de vsphere en una subred diferente (por ejemplo, de x a x), es necesario crear un switch distribuido en el cluster ESX de producción con las mismas propiedades que switch virtual distribuido real para el sitio de recuperación de desastres. Para crear una configuración para failover a una subred diferente, debe asignar una vnic en el switch ficticio a las máquinas virtuales de SQL Server en producción. Como se muestra en la Figura 36, se crea un switch ficticio en el sitio de producción del servidor vcenter. Luego, la máquina virtual se configura con una segunda vnic en el switch virtual ficticio de recuperación de desastres. Esto permite que la máquina virtual produzca un failover sin problemas al sitio remoto, sin la necesidad de configuración adicional de red para el sitio de recuperación de desastres. Figura 36. La vnic está configurada y conectada Switch ficticio de recuperación de desastres configurado para la segunda NIC en una máquina virtual para permitir el failover a una subred diferente en el lado de la recuperación de desastres. No hay una NIC conectada a este switch. Cuando se realiza failover a la máquina virtual en el sitio de recuperación de desastres, esta NIC se conectará a la red especificada (sqluce1.com), como se muestra en la Figura 37. Esto hace que la vnic en el sitio de producción tenga una red no identificada, porque el único propósito del switch de producción que se configuró en el sitio de recuperación de desastres es el de configuración y no está disponible en la red. Microsoft Exchange: Mejores prácticas Storage y reglas Best de Practices diseño de and Microsoft Design Guidance SQL Server for para EMC el Storage

102 red sqluce1.com Esto es porque hay una NIC física conectada al switch de recuperación de desastres en el sitio de recuperación de desastres. Cuando se realiza failover de una máquina virtual PCE1 para la recuperación de desastres, se conecta al dominio sqluce1.com mediante la NIC de sitio de DR. Figura 37. Sitio de recuperación de desastres conectado a la red sqluce1.com EMC Replication Manager Esta sección describe la configuración requerida para Replication Manager en el momento de implementar la protección. Integración de Replication Manager con SQL Server Para admitir SQL Server, Replication Manager usa la API de snapshot de la interfaz de dispositivo virtual (VDI) para obtener snapshots en línea, rápidas y coherentes con las aplicaciones de cada base de datos de clase empresarial de SQL Server con una sobrecarga insignificante de host. Replication Manager le permite realizar las siguientes tareas con una interfaz sencilla y guiada por asistente: Especificar las instancias, bases de datos y los correspondientes grupos de archivos a replicar. Garantizar que los datos se puedan replicar de manera segura y rápida. Volver a colocar a la base de datos en operación normal luego de crear la réplica. Montar o recuperar una base de datos en otro host para realizar otras operaciones, como pruebas, creación de informes o minería de datos. Recuperar rápidamente a una base de datos en el host de producción si se dañan los datos. Conjuntos de aplicaciones y trabajos para Microsoft SQL Server Replication Manager usa el concepto de conjuntos de aplicaciones como contenedores para definir los datos que se van a proteger (por ejemplo, Base de datos 1) y los trabajos como una forma de proteger esos datos (por ejemplo, imagen del marcador RecoverPoint). Mejores prácticas y reglas de diseño de Microsoft SQL Server para el

103 Coherencia de las aplicaciones de Microsoft SQL Server En este ejemplo, se configuraron los trabajos de Replication Manager para proteger a las bases de datos de usuario de SQL Server mediante la configuración de la opción Tipo de réplica a Full, Online with advanced recovery using VDI. Esta opción replica toda la base de datos y el log de transacciones. Este tipo de réplica se usa generalmente cuando se considera a la réplica como un respaldo de la base de datos o cuando se monta la réplica para que un producto de otros fabricantes cree un respaldo de la base de datos. Para llevar a la base de datos a un punto en el tiempo más nuevo que el de la réplica, este tipo de réplica le permite restaurar logs de transacciones, suponiendo que haya respaldado esos logs de transacciones. Replication Manager usa snapshots con VDI para crear este tipo de réplica, lo cual garantiza datos coherentes con las aplicaciones. Nota: Las bases de datos del sistema (maestro, MSDB y modelo) no se deben ubicar en el mismo volumen que las bases de datos de usuario. Microsoft SQL Server no es compatible con VDI y con la tecnología de snapshots para restaurar las bases de datos del sistema. Configuración de Replication Manager para comunicarse con vcenter y RecoverPoint Replication Manager puede replicar, montar y restaurar un área de almacenamiento de datos VMFS en el nivel del LUN. No es necesario instalar el software o agente de Replication Manager en el servidor ESXi o máquina virtual. Todas las operaciones se realizan a través del host proxy VMware de vcenter y Replication Manager, este puede ser un host físico o virtual. El host proxy se debe registrar en el servidor de Replication Manager con las credenciales para la administración de vcenter. El host proxy VMware de Replication Manager se comunica con vcenter mediante el puerto 443. Replication Manager puede mapear los volúmenes VMFS asociados con los LUN. En este ejemplo, el host proxy comparte la misma máquina virtual con el servidor de Replication Manager. Replication Manager también puede descubrir los LUN que ha replicado RecoverPoint. La comunicación con RecoverPoint se realiza a través del agente de Replication Manager instalado en las máquinas virtuales de producción y montadas. Reasignación del administrador de volumen lógico La replicación de VMFS requiere que la reasignación del administrador de volumen lógico (LVM) esté disponible en los servidores ESX de producción y montaje. La reasignación de LVM permite que VMware escriba una nueva firma para los LUN en caso de ser necesario. Se debe activar este switch para Replication Manager, de forma que VMFS sea visible en los LUN replicados en el servidor ESX. Esta configuración también se debería activar en el servidor ESX de producción para poder restaurar a ese servidor ESX en cualquier momento. Se debe emitir el siguiente comando en los servidores ESX que se usan para montar réplicas: esxcfg-advcfg -s 1 /LVM/EnableResignature Para obtener más información sobre este tema, consulte la Guía del administrador de EMC Replication Manager, sección Configuración de VMWare. Descubrimiento del dispositivo y el arreglo de almacenamiento RecoverPoint Esta solución usa el splitter RecoverPoint de almacenamiento, que permite que el arreglo de almacenamiento de RecoverPoint descubra al almacenamiento dentro de Replication Manager. Tiene que ingresar sus credenciales de almacenamiento para completar esta tarea de descubrimiento. Microsoft Exchange: Mejores prácticas Storage y reglas Best de Practices diseño de and Microsoft Design Guidance SQL Server for para EMC el Storage

104 Después de configurar las credenciales para al menos un agente de host de Replication Manager, una operación de descubrimiento del arreglo de almacenamiento también detecta al splitter de RecoverPoint. Recuperación de una base de datos de usuario de SQL Server En este ejemplo, EMC simuló un desastre en una base de datos de producción en vivo y probó la solución para recuperar un punto específico en el tiempo. Para la prueba, se eliminó una tabla de una base de datos OLTP a las 14:16:00. Esta es una tabla fundamental para la funcionalidad de la base de datos denominada Accounts Permissions Table. Los usuarios no pueden acceder a los datos sin ella, por lo tanto, a las 14:16:00, el negocio que dependía de la base de datos queda inactivo. Luego, se eliminó la base de datos completa para simular un error humano y se perdió toda la base de datos a las 14:16:15. Replication Manager es la única interfaz que se requiere para recuperar la base de datos, ya que coordina todas las operaciones en todos los niveles del agrupamiento de la solución, lo cual incluye a SQL Server, Windows Server, VMware, y RecoverPoint, para coordinar el proceso de recuperación. La interfaz guiada por asistente es útil para recuperar una base de datos transaccional crítica para el negocio, si se garantiza que se siguen todas las mejores prácticas para lograr una restauración exitosa. Esta solución restauró eficazmente la base de datos de usuario con la copia CRR del sitio remoto, también retrocedió el tiempo a solo un segundo antes de que ocurriera el desastre, a las 14:15:59. Replication Manager accedió a una imagen de la base de datos en ese preciso momento especificado y recuperó la base de datos, lo que dio lugar a un objetivo de punto de recuperación de un segundo. EMC decidió recuperar todos los archivos y grupos de archivos para la base de datos. Replication Manager completó el proceso de recuperación en 3 minutos y 26 segundos y dejo desconectada a la base de datos, lo cual permite que el DBA conecte la base de datos con una integridad garantizada antes de permitir el acceso a los usuarios. Una vez conectada la base de datos, los usuarios en línea pudieron acceder a los datos a las 14:21:45 y se respaldó el giro comercial. Esta solución brindó un objetivo de punto de recuperación de un segundo y un objetivo de tiempo de recuperación de menos de cuatro minutos. El nivel de recuperación es extremadamente poderoso, lo cual le permite cumplir con los estrictos acuerdos de nivel de servicio (SLA). Esto permite tener bases de datos OLTP fáciles y rápidas de recuperar, críticas de negocio y con gran cantidad de transacciones en solo algunos pasos. VMware vcenter SRM Esta sección describe la configuración para VMware vcenter SRM en el momento de implementar la protección. Integración de vcenter SRM con RecoverPoint vcenter SRM reduce el objetivo de tiempo de recuperación para la recuperación de desastres y depende de la replicación basada en bloques para reducir el objetivo de punto de recuperación para la recuperación de desastres. Se usa RecoverPoint SRA para mapear las solicitudes de vcenter SRM a las acciones de RecoverPoint adecuadas. Mejores prácticas y reglas de diseño de Microsoft SQL Server para el

105 vcenter SRM y RecoverPoint automatizan el proceso de recuperación de las máquinas virtuales, convirtiéndolo en algo tan sencillo como presionar un botón. El usuario no interactúa con la consola de RecoverPoint, en vez de eso, vcenter SRM automatiza todo el proceso de failover. La integración entre RecoverPoint y vcenter SRM se controla mediante RecoverPoint Storage Replication Adapter (SRA). RecoverPoint es responsable de la replicación de todos los cambios de los LUN de producción a las réplicas remotas en el sitio de recuperación de desastres. RecoverPoint SRA se instala en los mismos servidores que ejecutan vcenter Server y el plug-in de vcenter SRM en los sitios de producción y de recuperación de desastres. RecoverPoint SRA admite las funciones de vcenter SRM como failover y pruebas de failover con el uso de RecoverPoint para la replicación. Configuración del grupo de coherencia para su administración con vcenter SRM Después de la creación del grupo de coherencia y de la instalación de vcenter SRM, tiene que configurar el grupo de coherencia para que lo administre vcenter SRM. Para hacerlo, use la configuración de políticas de RecoverPoint Management Application, como se muestra en la Figura 38. Figura 38. Configuración del grupo de coherencia para su administración con vcenter SRM Protección de la solución vcenter SRM En este ejemplo, vcenter SRM protege a las máquinas virtuales de SQL Server. Se requiere Replication Manager en el sitio de producción para conseguir una protección local, montar y restaurar. El sitio de recuperación de desastres contiene sus propios servidores virtuales de vcenter y Active Directory, así que no es necesario replicarlos. Microsoft Exchange: Mejores prácticas Storage y reglas Best de Practices diseño de and Microsoft Design Guidance SQL Server for para EMC el Storage

106 La Figura 39 muestra la forma en que vcenter SRM protege a los servidores de SQL con la integración de RecoverPoint y la automatización de los pasos requeridos. Figura 39. Procedimiento de protección de vcenter SRM para el sitio de producción vcenter SRM requiere configuración en los sitios de producción y de recuperación. El sitio de producción requiere la siguiente configuración: Conexión para establecer la comunicación entre vcenter SRM y los servidores de vcenter Administradores de arreglos para detectar dispositivos replicados Mapeos de inventario para carpetas, redes y mapeos de recursos específicos del sitio Grupos de protección para organizar máquinas virtuales en sus respectivas áreas de almacenamiento de datos para la recuperación El sitio de recuperación requiere que configure un plan de recuperación mediante la creación de un manual de ejecución automatizado del proceso de recuperación. Configuración de los grupos de protección de vcenter SRM Un grupo de coherencia de RecoverPoint es un conjunto de datos de volúmenes de almacenamiento conectados a SAN en el sitio de producción y en el sitio de recuperación de desastres. Un grupo de protección de vcenter SRM es un grupo de máquinas virtuales que realizan failover en conjunto (durante la prueba y el failover real). Cuando vcenter SRM realiza un failover, indica a RecoverPoint que opere en los LUN de todas las máquinas virtuales del grupo de protección. Sin embargo, RecoverPoint usa grupos de coherencia para definir los grupos de LUN que se replican juntos. Mejores prácticas y reglas de diseño de Microsoft SQL Server para el

107 Después de la configuración exitosa de la conexión, de los administradores de arreglos y de los mapeos de inventario, tiene que configurar los grupos de protección, como se aprecia en la Figura 40. Figura 40. Configuración de los grupos de protección en vsphere Client Para esta solución se crearon cuatro grupos de protección individual, dos para cada una de las máquinas virtuales TPCE y dos para las máquinas virtuales TPCH. Puede especificar la prioridad de recuperación en cada grupo de protección y para cada máquina virtual. Modificación de la prioridad de inicio de una máquina virtual Es posible que no desee que todas las máquinas virtuales se reinicien simultáneamente en la recuperación, es por eso que EMC configuró las máquinas virtuales TPCE con alta prioridad, ya que son las más críticas para el negocio (como se muestra en la Figura 41), y deja las máquinas virtuales TPCH en una configuración de prioridad baja. Figura 41. Selección de la prioridad de recuperación para las máquinas virtuales Microsoft Exchange: Mejores prácticas Storage y reglas Best de Practices diseño de and Microsoft Design Guidance SQL Server for para EMC el Storage

108 Personalización de las direcciones IP del sitio de recuperación Cuando se realiza failover a un centro de datos diferente, se requieren algunos ajustes a la configuración de IP del host para las diferencias de infraestructura. Cuando se realiza failover de una configuración completa, puede involucrar la actualización de la configuración de múltiples máquinas virtuales. vcenter SRM proporciona una utilería de personalización masiva de IP (dr-ipcustomizer.exe) para actualizar automáticamente la configuración de IP para las máquinas virtuales recuperadas. La utilería genera un archivo CSV que contiene la configuración de IP para todas las máquinas virtuales que se configuraron para realizar el failover de vcenter SRM. Puede editar este archivo para especificar la configuración de IP del sitio de recuperación y luego volver a ejecutar la utilería para cargar la nueva configuración al servidor vcenter del sitio de recuperación. Para esta solución, se usó la utilería para actualizar la configuración de IP del sitio de recuperación de la siguiente manera: 1. Inicie sesión en el servidor vcenter en el sitio de recuperación. 2. Ejecute la utilería dr-ip-customizer.exe y especifique el nombre y ubicación para el archivo CSV, como se muestra. 3. Edite el archivo CSV para proporcionar la configuración de IP para las máquinas virtuales en el sitio de recuperación. La siguiente imagen muestra el archivo editado para esta solución. 4. Ejecute la utilería para cargar la nueva configuración en el servidor vcenter del sitio de recuperación, como se muestra. Nota: Si elimina o vuelve a crear un grupo de protección, debe repetir este proceso para volver a aplicar las personalizaciones de IP. Configuración de los planes de recuperación de vcenter SRM Los planes de recuperación se encuentran en el sitio de recuperación y definen los pasos para recuperar máquinas virtuales. Los planes de recuperación de vcenter SRM pueden usar la funcionalidad de acceso a imagen de RecoverPoint para realizar una prueba no disruptiva del proceso de failover. Esto garantiza que la imagen secundaria sea coherente y se pueda usar. Probar los planes de recuperación de desastres es una acción crítica para garantizar que la recuperación sea confiable. Tradicionalmente, este era un ejercicio complejo, lento y costoso. Con vcenter SRM, puede superar estos obstáculos con la activación de pruebas realistas y frecuentes de los planes de recuperación y con la eliminación de las causas comunes de fallas durante la recuperación. Mejores prácticas y reglas de diseño de Microsoft SQL Server para el

109 Al incluir varios grupos de protección en un único plan de recuperación, todas las máquinas virtuales asociadas están disponibles para la recuperación como parte de ese plan único de recuperación. La Figura 42 muestra el primer paso de la ejecución del plan de recuperación. Figura 42. Ejecución del plan de recuperación Como se muestra en la Figure 43, la máquina virtual priorizada se recupera (reinicia) antes que las otras máquinas virtuales del mismo plan de recuperación. Figura 43. Asignación de prioridades para la recuperación de máquinas virtuales Cuando finaliza el proceso de failover, vcenter SRM muestra un informe de resumen de la recuperación, como se muestra en la Figura 44. Microsoft Exchange: Mejores prácticas Storage y reglas Best de Practices diseño de and Microsoft Design Guidance SQL Server for para EMC el Storage

110 Figura 44. Informe de resumen del failover Configuración del failover de vcenter SRM con RecoverPoint CLR Después de que vcenter SRM complete con éxito el plan de recuperación y todos los sistemas vuelvan a estar operacionales, debe completar los siguientes pasos manuales para reanudar la replicación de CRR completa del sitio de recuperación de desastres al sitio de producción: 1. Asegúrese de que el grupo está en el modo de mantenimiento y que lo está administrado RecoverPoint, con SRM realizando solo el monitoreo. 2. Establezca la copia de réplica remota de RecoverPoint como producción en el sitio de recuperación de desastres, como se muestra en la Figura 45. Figura 45. Establecer la copia de réplica remota de RecoverPoint como la copia de producción 3. Como CDP también se encontraba en el sitio de producción antes del failover, quite una de las copias de datos de réplica del sitio de producción, como se muestra en la Figura 46. Mejores prácticas y reglas de diseño de Microsoft SQL Server para el

111 Figura 46. Eliminación de la réplica local Después de establecer la copia CRR como su copia de producción, se le solicita elegir la copia de los datos en el sitio de producción que se eliminará. Luego, debe decidir si usar la copia de producción o la copia CDP como el objetivo para CRR, esto se hace con la eliminación de la copia que no es necesaria, como se muestra en la Figura 47. Figura 47. Eliminación de la copia innecesaria de los datos Como parte de la configuración CLR de RecoverPoint, el sitio de producción alojó con anterioridad ambas copias, la copia de datos de producción y la copia de datos CDP. Esta nueva configuración de replicación de RecoverPoint es CRR, así que solo se admite una copia de destino de los datos en el sitio de producción. Esta configuración no afecta a la recuperación de las máquinas virtuales en el sitio de recuperación de desastres. Es específica de RecoverPoint y se requiere para la configuración de nuevas relaciones CRR en el sitio de producción. En el caso de que un desastre haga que el sitio de producción se vuelva inaccesible, estos pasos no son necesarios hasta que se restauren las comunicaciones con el sitio de producción. Si las comunicaciones con el sitio de producción están disponibles después de la recuperación, estos pasos se pueden generar por script en la interfaz de la línea de comandos de RecoverPoint. Como parte de un failover controlado, estos comandos se pueden incluir como una operación de script posterior en el plan de recuperación de vcenter SRM. El resultado de la reconfiguración del grupo de coherencia es una replicación sencilla de RecoverPoint CRR desde el sitio de recuperación de desastres al sitio de producción, como se muestra en la Figura 48. Microsoft Exchange: Mejores prácticas Storage y reglas Best de Practices diseño de and Microsoft Design Guidance SQL Server for para EMC el Storage

112 Figura 48. Reconfiguración de un grupo de coherencia Cuando finaliza un failback, el sitio de producción reanuda la producción y se requiere una reconfiguración y resincronización completa de las copias CDP. Nota: Es posible configurar CDP en el sitio de recuperación de desastres y mantener esa configuración, si corresponde. Mejores prácticas y reglas de diseño de Microsoft SQL Server para el