mejores prácticas y reglas de diseño de microsoft sql server para el

Transcripción

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
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 http://mexico.emc.com/ (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
almacenamiento de EMC
Serie EMC VNX, sistemas EMC Symmetrix VMAX y productos de servidor EMC Xtrem
2
2
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 ....................................................................... 10
Descripción general de SQL Server ................................................................................................. 10
Versiones de SQL Server............................................................................................................ 10
SQL Server 2012 ............................................................................................................................ 10
Ediciones de SQL Server 2012 ................................................................................................... 10
Componentes de SQL Server .......................................................................................................... 11
Windows Server ............................................................................................................................. 11
Tipos de volumen de Windows .................................................................................................. 12
SMB 3.0 .................................................................................................................................... 13
Arquitectura de SQL Server ............................................................................................................ 13
Componentes lógicos de SQL Server .............................................................................................. 15
Componentes físicos de SQL Server ............................................................................................... 16
Tipos de archivos ...................................................................................................................... 16
Página y extensión .................................................................................................................... 16
Log de transacciones................................................................................................................. 17
Grupo de archivos ..................................................................................................................... 17
Características de I/O y de ancho de banda de SQL Server ................................................................ 18
Descripción general ....................................................................................................................... 18
OLTP .............................................................................................................................................. 18
Base de datos de Data warehouse/OLAP ....................................................................................... 19
Páginas de lectura ......................................................................................................................... 20
Páginas de escritura....................................................................................................................... 20
Log Manager .................................................................................................................................. 21
Uso de Tempdb .............................................................................................................................. 21
Patrones de I/O .............................................................................................................................. 21
Mejores prácticas para el dimensionamiento y el aprovisionamiento del almacenamiento de SQL
Server .............................................................................................................................................. 23
Mejores prácticas generales del almacenamiento de SQL Server ................................................... 23
Mejores prácticas básicas para SQL Server................................................................................ 24
Mejores prácticas básicas para el almacenamiento ................................................................... 25
Consideraciones sobre la agrupación en clusters ...................................................................... 26
Consideraciones para las versiones anteriores .......................................................................... 26
Consideraciones generales para el almacenamiento ...................................................................... 26
Consideraciones de rendimiento frente a capacidad ................................................................. 26
Selección del tipo de disco ........................................................................................................ 26
Microsoft Exchange:
Mejores prácticas
y reglas
diseño de
Microsoft
SQL Server
3
Storage
Bestde
Practices
and
Design Guidance
forpara
EMCelStorage
3
Pools y tipos de RAID ................................................................................................................. 28
Consideraciones para el aprovisionamiento virtual del almacenamiento ........................................ 30
LUN delgado frente a LUN grueso .............................................................................................. 30
Mejores prácticas para el dimensionamiento del almacenamiento ................................................. 31
Consideraciones para el dimensionamiento de la base de datos OLTP ........................................... 31
Mejores prácticas para el dimensionamiento de FAST VP .......................................................... 33
Consideraciones para el dimensionamiento de la base de datos OLAP .......................................... 34
Consideraciones de almacenamiento para hipervisor .................................................................... 35
Reglas generales para la virtualización ...................................................................................... 36
Mejores prácticas para el ambiente VMware vSphere ................................................................ 38
Microsoft Hyper-V ...................................................................................................................... 40
Consideraciones de almacenamiento para la agrupación en clusters de SQL Server ...................... 41
Reglas de diseño de almacenamiento para Symmetrix VMAX ......................................................... 41
Consideraciones para el diseño de hardware de la serie VMAX.................................................. 42
Consideraciones y mejores prácticas del aprovisionamiento virtual .......................................... 42
Consideraciones y mejores prácticas de FAST VP para un sistema de almacenamiento VMAX ... 42
Reglas de diseño de almacenamiento para VNX ............................................................................ 43
Consideraciones y mejores prácticas para FAST Cache .............................................................. 44
Consideraciones y mejores prácticas para FAST VP .................................................................... 44
FAST Cache frente a FAST VP ...................................................................................................... 45
Consideraciones para flash de servidor.......................................................................................... 46
Descripción general de XtremSF ................................................................................................ 46
Mejores prácticas de diseño para XtremSF ................................................................................ 46
Descripción general de XtremSW Cache .................................................................................... 46
Mejores prácticas de diseño para XtremSW Cache .................................................................... 47
Mejores prácticas de diseño para XtremSW Cache en un ambiente virtualizado ........................ 48
Consideración de dimensionamiento para XtremSF y XtremSW Cache ....................................... 49
Automatización con ESI ................................................................................................................. 50
Protección de SQL Server .................................................................................................................. 51
Grupos de disponibilidad continua ................................................................................................ 51
Protección de datos nativa de SQL Server ...................................................................................... 52
Copias recuperables frente a copias reiniciables ....................................................................... 52
Marcos de trabajo de VDI y VSS para la replicación del respaldo ............................................... 53
Ofertas de protección de datos y alta disponibilidad de EMC para SQL Server ............................... 53
Tecnologías de replicación ........................................................................................................ 55
Herramientas de administración de replicaciones ..................................................................... 56
Recuperación de desastres de múltiples sitios............................................................................... 57
Consideraciones........................................................................................................................ 57
Tecnologías de replicación de múltiples sitios........................................................................... 58
Herramientas para la automatización del reinicio ...................................................................... 59
Herramientas de automatización de instancias virtualizadas .................................................... 59
Opciones de recuperación de desastres para SQL Server 2012 ...................................................... 59
Recomendaciones de respaldo adicionales ................................................................................... 59
Disponibilidad continua para la alta disponibilidad y la recuperación de desastres ....................... 60
4
4
Disponibilidad continua con FAST Suite .................................................................................... 60
Disponibilidad continua con XtremSW Cache/XtremSF con tecnología flash.............................. 60
Conclusiones .................................................................................................................................... 61
Resumen ........................................................................................................................................ 61
Información adicional .................................................................................................................... 61
Apéndice A: EMC Data Protection Advisor para análisis de replicación .............................................. 62
Asistentes de descubrimiento y recopilación de datos ................................................................... 62
Descubrimiento y recopilación de datos......................................................................................... 62
Descubrimiento de arreglos de almacenamiento ....................................................................... 62
Configuración de Data Protection Advisor para el monitoreo de Microsoft SQL Server ............... 63
Visualización y creación de informes de brechas y exposiciones ............................................... 64
Apéndice B: Herramientas para el monitoreo del rendimiento, optimización y dimensionamiento de
SQL Server ....................................................................................................................................... 66
Herramientas en el nivel de aplicaciones ....................................................................................... 68
EMC DBclassify.......................................................................................................................... 68
Perfcollect ................................................................................................................................. 70
PAL ............................................................................................................................................ 70
Herramientas en el nivel de base de datos de SQL Server .............................................................. 70
Herramienta para dimensionamiento de VSPEX SQL Server ....................................................... 70
Transact-SQL ............................................................................................................................. 71
SQL Server Profiler..................................................................................................................... 72
Asistente para la optimización de motor de base de datos de SQL Server ................................. 72
Vistas de administración dinámica de SQL Server ..................................................................... 73
Herramienta en el nivel de host de Windows .................................................................................. 73
Windows Performance Monitor (Perfmon) .................................................................................. 73
Herramientas en el nivel de hipervisor ........................................................................................... 74
Métricas clave para monitorear ESX ........................................................................................... 74
Métricas clave para monitorear Hyper-V .................................................................................... 76
Herramientas en el nivel de caché de almacenamiento/servidor .................................................. 77
Unisphere Analyzer ................................................................................................................... 77
XtremSW Cache Performance Predictor ...................................................................................... 77
EMC Storage Configuration Advisor ........................................................................................... 80
Apéndice C: Herramientas de generación de tipos de carga de SQL Server ........................................ 83
Presentación de herramientas........................................................................................................ 84
SQL Server Profiler..................................................................................................................... 84
IOMeter ..................................................................................................................................... 84
SQLIO ........................................................................................................................................ 84
SQLIOSim .................................................................................................................................. 84
Quest Benchmark Factory .......................................................................................................... 84
Microsoft Exchange:
Mejores prácticas
y reglas
diseño de
Microsoft
SQL Server
5
Storage
Bestde
Practices
and
Design Guidance
forpara
EMCelStorage
5
Apéndice D: Diseños y arquitecturas de referencia para el almacenamiento de muestra .................... 85
Diseño de almacenamiento de Microsoft SQL Server en VMAX con FAST VP ................................... 85
Fase 1: recolectar requisitos del usuario ................................................................................... 85
Fase 2: diseñar la arquitectura del almacenamiento según los requisitos del usuario ............... 85
Cálculo de IOPS ......................................................................................................................... 86
Cálculo de capacidad ................................................................................................................ 86
Enfoque de diseño del componente básico para data warehouse .................................................. 88
Consideraciones para el diseño de un componente básico ....................................................... 88
Detalles del diseño de un componente básico .......................................................................... 89
Implementación de componentes básicos ................................................................................ 91
Diseño de asignación de máquina virtual y LUN de SQL Server .................................................. 92
Solución de protección de SQL Server ............................................................................................ 93
EMC RecoverPoint ..................................................................................................................... 93
EMC Replication Manager ........................................................................................................ 102
VMware vCenter SRM .............................................................................................................. 104
6
6
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
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.
Público al que
va dirigido
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 almacenamiento de EMC como VNX, Symmetrix VMAX,
XtremSF™ y XtremSW™ Cache, así como con los ambientes virtuales de VMware
o Microsoft Hyper-V.
Alcance
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
y reglas
diseño de
Microsoft
SQL Server
7
Storage
Bestde
Practices
and
Design Guidance
forpara
EMCelStorage
7
Terminología
Este informe técnico incluye la siguiente terminología.
Tabla 1.
Terminología
Término
Definición
Grupos de disponibilidad
(AG)
Una característica de alta disponibilidad (HA) y de
recuperación de desastres en SQL Server 2012. 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.
Réplica de disponibilidad
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).
Sincronización de datos
Es el proceso en el que los cambios realizados a una base
de datos primaria se reproducen en una base de datos
secundaria.
EMC XtremSF
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).
eMLC
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.
FAST™ Cache
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.
Fully Automated Storage
Tiering for Virtual Pools
(FAST VP)
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.
Flash con celda de múltiples
niveles (MLC)
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.
NAND
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.
8
8
Término
Definición
OLTP
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.
Réplica primaria
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.
RAID
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.
Réplica secundaria legible
Bases de datos de réplica secundaria configuradas para
permitir conexiones de cliente de solo lectura.
Replicación
Es el proceso de copiar una base de datos de una réplica
primaria a las correspondientes réplicas secundarias.
Flash con celda de un solo
nivel (SLC)
Un tipo de almacenamiento de estado sólido (disco SSD)
que almacena un bit de información por celda de medio
flash.
SP
Procesador de almacenamiento.
SQL Server 2012 AlwaysOn
Es una solución integral de alta disponibilidad y
recuperación de desastres para SQL Server 2012. 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.
Pool de almacenamiento
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.
LUN delgado
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.
LUN grueso
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.
VMDK
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
y reglas
diseño de
Microsoft
SQL Server
9
Storage
Bestde
Practices
and
Design Guidance
forpara
EMCelStorage
9
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 2000.
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.
10 10
•
•
Componentes de
SQL Server
Windows Server
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
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
y reglas
diseño de
Microsoft
SQL Server
11 11
Storage
Bestde
Practices
and
Design Guidance
forpara
EMCelStorage
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.
12 12
Tabla 2.
Implementación típica de SQL Server para el almacenamiento de EMC
Partición de
volumen
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 2012.
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
y reglas
diseño de
Microsoft
SQL Server
13 13
Storage
Bestde
Practices
and
Design Guidance
forpara
EMCelStorage
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.
14 14
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.
•
Componentes
lógicos de SQL
Server
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.
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
y reglas
diseño de
Microsoft
SQL Server
15 15
Storage
Bestde
Practices
and
Design Guidance
forpara
EMCelStorage
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.
16 16
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
y reglas
diseño de
Microsoft
SQL Server
17 17
Storage
Bestde
Practices
and
Design Guidance
forpara
EMCelStorage
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.
18 18
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
y reglas
diseño de
Microsoft
SQL Server
19 19
Storage
Bestde
Practices
and
Design Guidance
forpara
EMCelStorage
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
20 20
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
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.
Uso de Tempdb
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).
Patrones de I/O
La Tabla 3 resume los patrones de I/O involucrados en cada tipo de base de
datos.
Tabla 3.
Patrones de I/O de diferentes tipos de carga para una base de datos de SQL
Server
Tipos y
características
de I/O
Archivo de base de datos del procesamiento
de transacciones en línea (OLTP)
Decision Support System
(data warehouse, OLAP)
Archivos de
datos
• I/O más pequeñas y aleatorias
(de 8 a 64 kB)
• 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)
• 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.
• 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
y reglas
diseño de
Microsoft
SQL Server
21 21
Storage
Bestde
Practices
and
Design Guidance
forpara
EMCelStorage
Tipos y
características
de I/O
Archivo de log
de la base de
datos
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).
Archivo de
datos de
Tempdb
• 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.
22 22
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 almacenamiento de EMC, 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 almacenamiento de EMC 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
y reglas
diseño de
Microsoft
SQL Server
23 23
Storage
Bestde
Practices
and
Design Guidance
forpara
EMCelStorage
•
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.
24 24
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
y reglas
diseño de
Microsoft
SQL Server
25 25
Storage
Bestde
Practices
and
Design Guidance
forpara
EMCelStorage
•
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:
Consideraciones
generales para el
almacenamiento
•
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 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.
26 26
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
Como una mejora de los
discos tradicionales SCSI,
los discos SAS proporcionan
alta capacidad con una
velocidad de I/O moderada.
Sumamente adecuados para los
ambientes de SQL Server con altos
requisitos de IOPS.
SATA
Discos de gran capacidad
con una velocidad de I/O
menos exigente.
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
SAS NL
(NL-SAS)
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 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.
Flash
Los discos flash tienen la
velocidad de I/O más alta
con un bajo consumo de
energía.
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
y reglas
diseño de
Microsoft
SQL Server
27 27
Storage
Bestde
Practices
and
Design Guidance
forpara
EMCelStorage
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 almacenamiento de EMC 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 almacenamiento de EMC
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 de SQL Server para modelos XtremSF
IOPS
aleatorias
de 8,000
XSF550
MLC *
XSF550
MLC *
XSF2200
MLC *
XSF2200
MLC *
XSF320
SLC
XSF700
SLC
Lectura
131,795
128,207
258,838
256,887
376,072
395,906
Escritura
23,592
16,235
53,713
35,654
67,635
133,593
Lectura/es
critura
(70/30)
56,255
42,471
120,162
93,848
171,666
191,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.
28 28
Los sistemas de almacenamiento de EMC 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.
Características de rendimiento del nivel de RAID
Lectura
secuencial
Escritura
secuencial
Valor de
sobrecarga
Utilización del
de la
almacenamiento
escritura de
RAID
Excelente Excelente
Excelente
Excelente
2
Baja
RAID 5
Excelente Moderado
Bueno
Moderado
4
Alta
RAID 6
Bueno
Bueno
Moderado
6
Media
Nivel
de
RAID
Aleatorio
Lectura
RAID
1/0
Escritura
aleatoria
Deficiente
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
y reglas
diseño de
Microsoft
SQL Server
29 29
Storage
Bestde
Practices
and
Design Guidance
forpara
EMCelStorage
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.
30 30
En resumen, cuando decida usar pools de almacenamiento, LUN delgados, LUN
gruesos o RAID para la configuración de LUN, considere lo siguiente:
Mejores prácticas
para el
dimensionamiento
del
almacenamiento
•
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.
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:
𝐶𝑎𝑛𝑡𝑖𝑑𝑎𝑑 𝑑𝑒 𝑑𝑖𝑠𝑐𝑜𝑠 =
𝐼𝑂𝑃𝑆 𝑑𝑒 𝑙𝑒𝑐𝑡𝑢𝑟𝑎 +
(𝐼𝑂𝑃𝑆 𝑑𝑒 𝑒𝑠𝑐𝑟𝑖𝑡𝑢𝑟𝑎 𝑥 𝑠𝑜𝑏𝑟𝑒𝑐𝑎𝑟𝑔𝑎 𝑑𝑒 𝑟𝑒𝑛𝑑𝑖𝑚𝑖𝑒𝑛𝑡𝑜 𝑑𝑒 𝑅𝐴𝐼𝐷)
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
y reglas
diseño de
Microsoft
SQL Server
31 31
Storage
Bestde
Practices
and
Design Guidance
forpara
EMCelStorage
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
https://emc.mitrend.com.
•
Herramienta para dimensionamiento de VSPEX (VNX)
Para obtener más información, consulte
http://mexico.emc.com/microsites/vspex-ebook/vspex-solutions.htm
(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.
Dimensionamiento para la capacidad
Tipo
de
RAID
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/2
2
4
2 × tamaño de LUN
5
4/5
4
3
5/4 × tamaño de LUN
6
4/6
6
4
6/4 × tamaño de LUN
Use la siguiente fórmula para calcular la cantidad de discos 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.
32 32
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
y reglas
diseño de
Microsoft
SQL Server
33 33
Storage
Bestde
Practices
and
Design Guidance
forpara
EMCelStorage
Dimensionamiento para el rendimiento
Los IOPS y el cálculo de disco son igual al que proporciona el grupo RAID con
desviación:
𝑁ú𝑚𝑒𝑟𝑜 𝑑𝑒 𝑑𝑖𝑠𝑐𝑜𝑠 𝑝𝑜𝑟 𝑛𝑖𝑣𝑒𝑙 =
𝐼𝑂𝑃𝑆 𝑑𝑒 𝑙𝑒𝑐𝑡𝑢𝑟𝑎 + (𝐼𝑂𝑃𝑆 𝑑𝑒 𝑒𝑠𝑐𝑟𝑖𝑡𝑢𝑟𝑎 ×
𝑠𝑜𝑏𝑟𝑒𝑐𝑎𝑟𝑔𝑎 𝑑𝑒 𝑟𝑒𝑛𝑑𝑖𝑚𝑖𝑒𝑛𝑡𝑜 𝑑𝑒 𝑅𝐴𝐼𝐷)
× 𝐷𝑒𝑠𝑣𝑖𝑎𝑐𝑖ó𝑛 𝑑𝑒 𝐼/𝑂 𝑝𝑜𝑟 𝑛𝑖𝑣𝑒𝑙
𝐼𝑂𝑃𝑆 𝑝𝑜𝑟 𝑑𝑖𝑠𝑐𝑜
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:
𝐶𝑎𝑝𝑎𝑐𝑖𝑑𝑎𝑑 𝑡𝑜𝑡𝑎𝑙 𝑥
𝑑𝑒𝑠𝑣𝑖𝑎𝑐𝑖ó𝑛 𝑑𝑒 𝑐𝑎𝑝𝑎𝑐𝑖𝑑𝑎𝑑 𝑝𝑎𝑟𝑎 𝑒𝑙 𝑛𝑖𝑣𝑒𝑙
𝑁ú𝑚𝑒𝑟𝑜 𝑑𝑒 𝑑𝑖𝑠𝑐𝑜𝑠 𝑝𝑜𝑟 𝑛𝑖𝑣𝑒𝑙 =
𝑆𝑜𝑏𝑟𝑒𝑐𝑎𝑟𝑔𝑎 𝑑𝑒 𝑐𝑎𝑝𝑎𝑐𝑖𝑑𝑎𝑑 𝑑𝑒 𝑅𝐴𝐼𝐷
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.
𝑁ú𝑚𝑒𝑟𝑜 𝑑𝑒 𝑑𝑖𝑠𝑐𝑜𝑠 𝑝𝑜𝑟 𝑛𝑖𝑣𝑒𝑙 = 𝑇𝑎𝑚𝑎ñ𝑜 𝑝𝑟𝑜𝑚𝑒𝑑𝑖𝑜 𝑑𝑒 𝐼/𝑂 𝑥 𝐼𝑂𝑃𝑆 𝑑𝑒 𝑠𝑜𝑙𝑜 𝑙𝑒𝑐𝑡𝑢𝑟𝑎
34 34
•
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:
𝑁ú𝑚𝑒𝑟𝑜 𝑑𝑒 𝑑𝑖𝑠𝑐𝑜𝑠 𝑝𝑎𝑟𝑎 𝑒𝑙 𝑟𝑒𝑛𝑑𝑖𝑚𝑖𝑒𝑛𝑡𝑜 =
𝐴𝑛𝑐ℎ𝑜 𝑑𝑒 𝑏𝑎𝑛𝑑𝑎 𝑟𝑒𝑞𝑢𝑒𝑟𝑖𝑑𝑜
𝐴𝑛𝑐ℎ𝑜 𝑑𝑒 𝑏𝑎𝑛𝑑𝑎 𝑝𝑜𝑟 𝑑𝑖𝑠𝑐𝑜
Calcule la cantidad de discos que se necesitan para la capacidad de la
siguiente manera:
𝑁ú𝑚𝑒𝑟𝑜 𝑑𝑒 𝑑𝑖𝑠𝑐𝑜𝑠 𝑝𝑜𝑟 𝑐𝑎𝑝𝑎𝑐𝑖𝑑𝑎𝑑 =
𝐶𝑎𝑝𝑎𝑐𝑖𝑑𝑎𝑑 𝑟𝑒𝑞𝑢𝑒𝑟𝑖𝑑𝑎
𝑆𝑜𝑏𝑟𝑒𝑐𝑎𝑟𝑔𝑎 𝑑𝑒 𝑅𝐴𝐼𝐷 𝑝𝑎𝑟𝑎 𝑙𝑎 𝑐𝑎𝑝𝑎𝑐𝑖𝑑𝑎𝑑
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 almacenamiento de EMC 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
y reglas
diseño de
Microsoft
SQL Server
35 35
Storage
Bestde
Practices
and
Design Guidance
forpara
EMCelStorage
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.
36 36
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.
Tabla 10.
Limitaciones de VMware para los clusters de Microsoft SQL Server
Característica
Disco 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
Disponibilidad
continua de
SQL
Disponibilidad
Grupo
Soporte de vSphere
Sí
Sí
Sí
Sí
Sí
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
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
Disco
compartido
Disco no compartido
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.
Solo vSphere 5.5.
3
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 1.5.0.8 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 VIC1280
5
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.
2
Microsoft Exchange:
Mejores prácticas
y reglas
diseño de
Microsoft
SQL Server
37 37
Storage
Bestde
Practices
and
Design Guidance
forpara
EMCelStorage
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.
38 38
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 frente a RDM
VMFS
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
Aplica el mapeo 1:1 entre la máquina
virtual y el LUN
Consolidación de máquinas virtuales en
LUN: hay menos posibilidades de
alcanzar el límite de LUN para ESX de 255
Más probabilidades 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
No se ve afectado por los IOPS de otras
máquinas virtuales
Tamaño de LUN limitado (2 TB para
vSphere 5.1 y 62 TB para vSphere 5.5)
Tamaño de LUN ilimitado
Microsoft Exchange:
Mejores prácticas
y reglas
diseño de
Microsoft
SQL Server
39 39
Storage
Bestde
Practices
and
Design Guidance
forpara
EMCelStorage
VMFS
RDM
Funciona bien para la mayoría de los
ambientes que no requieran mapeo de
dispositivos crudos (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 2012. 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 almacenamiento de EMC 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.
40 40
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
y reglas
diseño de
Microsoft
SQL Server
41 41
Storage
Bestde
Practices
and
Design Guidance
forpara
EMCelStorage
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.
42 42
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
y reglas
diseño de
Microsoft
SQL Server
43 43
Storage
Bestde
Practices
and
Design Guidance
forpara
EMCelStorage
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.
44 44
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
y reglas
diseño de
Microsoft
SQL Server
45 45
Storage
Bestde
Practices
and
Design Guidance
forpara
EMCelStorage
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.
46 46
•
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
y reglas
diseño de
Microsoft
SQL Server
47 47
Storage
Bestde
Practices
and
Design Guidance
forpara
EMCelStorage
•
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.
48 48
•
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.
Caché recomendada para cada aplicación
Aplicación
Tipo de base
de datos
Relación de
lecturaescritura
Relación recomendada de XtremSW
Cache y el almacenamiento
SQL Server
OLTP
90:10
1:10
SQL Server
OLTP
70:30
1:5
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
y reglas
diseño de
Microsoft
SQL Server
49 49
Storage
Bestde
Practices
and
Design Guidance
forpara
EMCelStorage
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 2012.
•
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.
50 50
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 2012.
Los sistemas de almacenamiento de EMC 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:
Grupos de
disponibilidad
continua
•
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.
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
y reglas
diseño de
Microsoft
SQL Server
51 51
Storage
Bestde
Practices
and
Design Guidance
forpara
EMCelStorage
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
Soportado
Declaración T-SQL o
respaldo nativo de
SQL Server
Respaldo nativo de SQL,
Interfaz de
dispositivo virtual
para software de
otros fabricantes
VMAX/VNX/VNXe
Servicio de shadow
copy de volumen
para software de
otros fabricantes
VMAX/VNX/VNXe
Networker®
Networker, Replication Manager,
AppSync, RecoverPoint
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.
52 52
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.
Tabla 14.
Categoría
Disponibilida
d continua
Opciones de protección de datos y alta disponibilidad de EMC
Herramienta/
sistema
Recursos
Descripción
RecoverPoint
CDP
• Síncrona
• Protección de recuperación local
CRR
• Asíncrona
• Replicación remota continua
CLR
• Datos simultáneos locales y remotos
• Combina CDP y CRR
VMAX/VNX con
un splitter de
RecoverPoint
incorporado
CDP/CRR/CLR
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
y reglas
diseño de
Microsoft
SQL Server
53 53
Storage
Bestde
Practices
and
Design Guidance
forpara
EMCelStorage
Herramienta/
sistema
Categoría
Recuperación
a partir de
una
replicación
rápida de un
punto en el
tiempo
AppSync
Descripción
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
SAN Copy con
snapshots/clone
s para VMAX y
VNX
• Un software de protección de datos
integral
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
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
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
Replication
Manager
VMAX
TimeFinder
VNX
Respaldo y
restauración
eficientes de
un punto en el
tiempo
Recursos
• Se debe instalar el agente en SQL Server
Cada producto tiene sus propios beneficios y consideraciones. La decisión
depende de los requisitos de nivel de servicio para cada caso de uso.
54 54
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
y reglas
diseño de
Microsoft
SQL Server
55 55
Storage
Bestde
Practices
and
Design Guidance
forpara
EMCelStorage
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.
56 56
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
y reglas
diseño de
Microsoft
SQL Server
57 57
Storage
Bestde
Practices
and
Design Guidance
forpara
EMCelStorage
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.
58 58
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 2012.
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
EMC RecoverPoint
Solo se replican los datos de SQL Server.
Requiere ajustes de DNS cuando realiza
failover a una réplica secundaria
Transferencia de
servidores/sitios
EMC RecoverPoint
EMC VPLEX
EMC VPLEX
EMC VMAX
SRDF/Cluster Enabler
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
EMC Replicator
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
y reglas
diseño de
Microsoft
SQL Server
59 59
Storage
Bestde
Practices
and
Design Guidance
forpara
EMCelStorage
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.
60 60
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
almacenamiento de EMC 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:
Información
adicional
•
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.
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
y reglas
diseño de
Microsoft
SQL Server
61 61
Storage
Bestde
Practices
and
Design Guidance
forpara
EMCelStorage
Apéndice A: EMC Data Protection Advisor para análisis de replicación
Descripción
general
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.
Asistentes de
descubrimiento
y recopilación de
datos
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.
Descubrimiento
y recopilación de
datos
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.
62 62
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.
5.
Ubicación del recopilador
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
y reglas
diseño de
Microsoft
SQL Server
63 63
Storage
Bestde
Practices
and
Design Guidance
forpara
EMCelStorage
c.
Figura 11.
6.
Verifique Microsoft SQL Server, como se muestra en la Figura 11.
Recopilación de datos
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.
64 64
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
y reglas
diseño de
Microsoft
SQL Server
65 65
Storage
Bestde
Practices
and
Design Guidance
forpara
EMCelStorage
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
(http://mexico.emc.com/dom
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
(http://emc.ms/Perfcollect)
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.
EMC
Workload
Performance
Assessment
EMC
(https://emc.mitrend.com)
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.
PAL
Analizador del rendimiento de
logs de código abierto
(http://www.codeplex.com/PAL)
Se utiliza para la solución de
problemas de rendimiento.
66 66
Nivel
Herramienta
Origen/enlaces
Descripción
Base de datos de SQL
Server
Herramienta
para
dimensionam
iento de
VSPEX SQL
EMC
(http://express.salire.com/go/
emc)
Se puede usar para determinar
la infraestructura comprobada
VSPEX recomendada para SQL
Server virtualizado, basado en
los requisitos del usuario.
T-SQL
Microsoft (se proporciona con
la instalación del servidor
SQL)
Brinda los procedimientos
Transact-SQL almacenados en
el sistema para crear rastros en
una instancia del motor de base
de datos de SQL Server.
SQL Server
Profiler
Microsoft (servicios de
análisis de SQL Server)
Brinda capturas de SQL Trace y
las reproduce en una interfaz
gráfica del usuario.
SQL
Database
Tuning
Advisor (DTA)
DTA brinda sugerencias para la
optimización de SQL Server
tales como la indexación y el
particionamiento.
Dynamic
Management
Views (DMV)
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
vSphere
Client GUI
Interfaz gráfica del usuario del
cliente de vSphere
Herramienta principal para
rastrear el rendimiento y
configurar los datos en uno o
más hosts ESX/ESXi.
Resxtop/
Esxtop
ESX/ESXi
Proporciona una matriz de
rendimiento, pero requiere
acceso a la raíz.
Perfmon
Windows Performance Monitor
Proporciona una matriz de
rendimiento para Hyper-V y las
máquinas virtuales.
Unisphere
Analyzer
Se incluye con los sistemas de
Brinda funcionalidades de
monitoreo del rendimiento para
los sistemas de
almacenamiento de EMC.
Herramienta
XtremCache
Performance
Predictor
https://support.emc.com/sea
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.
VMware
Hyper-V
Caché de
almacenamiento/
servidor
Microsoft Exchange:
Mejores prácticas
y reglas
diseño de
Microsoft
SQL Server
67 67
Storage
Bestde
Practices
and
Design Guidance
forpara
EMCelStorage
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.
68 68
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
y reglas
diseño de
Microsoft
SQL Server
69 69
Storage
Bestde
Practices
and
Design Guidance
forpara
EMCelStorage
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
70 70
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
y reglas
diseño de
Microsoft
SQL Server
71 71
Storage
Bestde
Practices
and
Design Guidance
forpara
EMCelStorage
Tabla 17.
Procedimientos Transact-SQL almacenados para el rastro del servidor SQL
Procedimiento almacenado
Tarea realizada
fn_trace_geteventinfo (Transact-SQL)
Proporciona información acerca de los
eventos incluidos en un rastro.
fn_trace_getinfo (Transact-SQL)
Proporciona información acerca de un
rastro específico para todos los rastros
existentes.
sp_trace_create (Transact-SQL)
Crea una definición de rastro. El nuevo
rastro se encontrará detenido.
sp_trace_generateevent (Transact-SQL)
Crea un evento definido por el usuario.
sp_trace_setevent (Transact-SQL)
Agrega o elimina una clase de evento o una
columna de datos en un rastro.
sp_trace_setstatus (Transact-SQL)
Inicia, detiene o cierra un rastro.
fn_trace_getfilterinfo (Transact-SQL)
Proporciona información acerca de los
filtros aplicados a un rastro.
sp_trace_setfilter (Transact-SQL)
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.
72 72
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.
Contadores útiles para evaluar el rendimiento del almacenamiento en
ambientes SAN
Contador
Función medida
Transferencia promedio de
discos/s
Latencia de almacenamiento
general
Lectura promedio de
discos/s
Latencia de lectura
Escritura promedio de
discos/s
Latencia de escritura
Transferencia promedio de
bytes/disco
Tamaño de I/O
Bytes de discos/s
Rendimiento
Lecturas de discos/s
Lectura de IOPS
Escrituras de discos/s
Escrituras de IOPS
Microsoft Exchange:
Mejores prácticas
y reglas
diseño de
Microsoft
SQL Server
73 73
Storage
Bestde
Practices
and
Design Guidance
forpara
EMCelStorage
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.
Contadores útiles para evaluar el rendimiento del almacenamiento en
ambientes NAS
Contador
Función medida
Solicitud de datos promedio
por segundo
Latencia de almacenamiento
general
Lecturas promedio por
segundo
Latencia de lectura
Escrituras promedio por
segundo
Latencia de escritura
Bytes de datos promedio por
solicitud
Tamaño de I/O
Solicitudes de datos por
segundo
Rendimiento
Solicitudes de lectura por
segundo
Lectura de IOPS
Solicitudes de escritura por
segundo
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 Métricas clave para monitorear ESX
nivel de hipervisor 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
74 74
•
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 (%)
%RDY
Tiempo de CPU empleado en el estado
preparado (solo para máquinas virtuales)
%SYS
Porcentaje de tiempo empleado en el
kernel de la máquina virtual de ESXServer
Swapin,
Swapout
Memoria que el host ESX intercambia de
entrada/salida desde o hacia el disco (por
máquina virtual o acumulativa en el host)
MCTLSZ (MB)
Cantidad de memoria recuperada del pool
de recursos en incrementos
Reads/s,
Writes/s
Lecturas y escrituras realizadas en el
intervalo de recopilación
DAVG/cmd
Latencia promedio (ms) del dispositivo
(LUN)
KAVG/cmd
Latencia promedio (ms) en el kernel de la
máquina virtual, también conocido como
tiempo de espera
GAVG/cmd
Latencia promedio (ms) en el huésped.
GAVG = DAVG +KAVG
MbRX/s,
MbTX/s
Cantidad de datos transmitidos por
segundo
PKTRX/s,
PKTTX/s
Paquetes transmitidos por segundo
%DRPRX,
%DRPTX
Paquetes descartados por segundo
Memoria
Disco
Red
Microsoft Exchange:
Mejores prácticas
y reglas
diseño de
Microsoft
SQL Server
75 75
Storage
Bestde
Practices
and
Design Guidance
forpara
EMCelStorage
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
\Processor(*)\%
Processor Time
Utilización del tiempo de CPU
\Hyper-V Hypervisor
Logical
Processor(_Total)\%
Total Run Time
Consumo entre un 60 % y un 89 % =
Monitorear o tomar precauciones
Memoria
\Memory\Available
Mbytes
Consumo inferior al 60 % = En buen estado
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
\Memory\Pages/sec
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
Disco
Red
\Logical Disk(*)\Avg.
sec/Read,
Latencia de lectura y escritura.
\Logical Disk(*)\Avg.
sec/Write
De 15ms a 25ms = Advertencia o monitorear
\Network
Interface(*)\Bytes
Total/sec
De 1ms a 15ms = En buen estado
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
76 76
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 almacenamiento de EMC. 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
y reglas
diseño de
Microsoft
SQL Server
77 77
Storage
Bestde
Practices
and
Design Guidance
forpara
EMCelStorage
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
78 78
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
y reglas
diseño de
Microsoft
SQL Server
79 79
Storage
Bestde
Practices
and
Design Guidance
forpara
EMCelStorage
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
almacenamiento de EMC 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.
80 80
•
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
y reglas
diseño de
Microsoft
SQL Server
81 81
Storage
Bestde
Practices
and
Design Guidance
forpara
EMCelStorage
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
82 82
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
• Relativamente complejo
• Simula desviaciones
• Ejerce presión sobre el CPU y
la memoria
• Es fácil de configurar
IOMeter
• Se puede optimizar
• Es aleatorio/secuencial
• Tasa de lectura/escritura
• No requiere la experiencia de
los administradores de bases
de datos
• Requiere la experiencia de
los administradores de
bases de datos para su
ejecución
• Requiere privilegios de
administrador de SQL
• Las replicaciones de
desviaciones resultan
difíciles
• Las mediciones
secuenciales resultan
difíciles
• No ejerce la presión
apropiada sobre el CPU
• Puede sobreponer tipos de
carga que no sean de SQL
(como respaldos)
• Facilidad de configuración
SQLIO
• Descubre rápidamente los
límites de la infraestructura
• 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
• Tarifa de licencia alta
• 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
• 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
y reglas
diseño de
Microsoft
SQL Server
83 83
Storage
Bestde
Practices
and
Design Guidance
forpara
EMCelStorage
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 http://go.microsoft.com/fwlink/?LinkId=115176.
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: http://support.microsoft.com/kb/231619.
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.
84 84
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
Activo/Semiactivo/Inactivo
RPO
Remoto: menos de cinco minutos, local: seis horas
RTO
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
y reglas
diseño de
Microsoft
SQL Server
85 85
Storage
Bestde
Practices
and
Design Guidance
forpara
EMCelStorage
Cálculo de IOPS
Calcule IOPS de la siguiente manera:
•
La I/O total para 225,00 usuarios es 6000 + el 20 % = 6000 + 1200 = 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) =
(720×0.85) + 2 (720×0.15) = 828

I/O total para RAID 5 de Fibre Channel = (el 15 % de 7,200) =
(1080×0.85) + 4(1080×0.15) = 1,566

I/O total para RAID 5 de flash = (el 75 % de 7200) = (5040×0.85) +
4 (5040×0.15) = 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: 300 + el 20 % = 360 GB

Semiactivo: 400 + el 20 % = 480 GB

Inactivo: 700 + el 20 % = 840 GB
86 86
•
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 = 2448×0.75 = 1836 GB

Fibre Channel = 2448×0.15 = 368 GB

Flash = 2448×0.1 = 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 Fibre Channel de 600 GB y 10,000 r/min

Microsoft Exchange:
Mejores prácticas
y reglas
diseño de
Microsoft
SQL Server
87 87
Storage
Bestde
Practices
and
Design Guidance
forpara
EMCelStorage
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
12 discos Fibre Channel de 600 GB y
10,000 r/min
Tamaños de LUN delgado (base
de datos)
Activo, 360 GB
Semiactivo, 480 GB
Inactivo, 840 GB
Tamaños de LUN delgado (log)
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.
88 88

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
y reglas
diseño de
Microsoft
SQL Server
89 89
Storage
Bestde
Practices
and
Design Guidance
forpara
EMCelStorage
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.
Tres componentes básicos probados
Tabla 26.
Las configuraciones del componente básico
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
500 GB
1 TB
2 TB
Ancho de banda
determinado
(MB/s)
100
200
400
Diseño del LUN
de base de datos
1 x LUN de datos de 2 TB 2 x LUN de datos de 2 TB 4 x LUN de datos de 2 TB
8 x archivo de datos de 8 x archivos de datos
16 x archivos de datos
80 GB
de 126 GB
de 126 GB
Diseño de log
1 LUN de log (archivo
de log de 5 GB)
de log de 12 GB)
1 LUN de log (archivo de
log de 12 GB)
Diseño de
Tempdb
1 LUN de datos (1 x
archivo de datos de
100 GB)
de log de 2 GB)
1 LUN de datos (2 x
archivos de datos de
100 GB)
de log de 2 GB)
1 LUN de datos (4 x
archivos de datos de
100 GB)
1 LUN de log (archivo de
log de 2 GB)
Configuración
del disco
5 discos SAS
10 discos SAS
20 discos SAS
Memoria (GB)
8
16
32
CPU virtual
(2.4 GHz)
2
4
8
Configuración
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.
90 90
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)
Cantidad de discos
RAID 5 (4+1)
Mínimo
16
4
5
/TB
16
4
10
/(100 MB/s)
8
2
5
500 GB (100 MB/s)
8
2
5
1 TB (200 MB/s)
16
4
10
2 TB (400 MB/s)
32
8
20
4 TB (800 MB/s)
64
16
40
6 TB (800 MB/s)
96
24
60
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
y reglas
diseño de
Microsoft
SQL Server
91 91
Storage
Bestde
Practices
and
Design Guidance
forpara
EMCelStorage
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.
92 92
Tabla 28.
Host
Asignación
CPU
(core)
Memoria
(GB)
Tamaño de
la base de
datos (TB)
Cantidad
de discos
Ancho de
banda
(MB/S)
ESXi 01
(40 cores,
256 GB
RAM)
VM1
16
64
2
20
400
VM2
8
32
2
20
400
ESXi 02
(80 cores,
512 GB
RAM)
VM3
24
96
2
20
400
2
20
400
1
10
200
0.5
5
100
0.5
5
100
Total
Solución de
protección de
SQL Server
Implementación del concepto básico de la solución en la máquina virtual y
en el servidor ESXi
VM4
24
96
2
20
400
4 máquinas
virtuales
72
288
noviembre
180
3,600
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
y reglas
diseño de
Microsoft
SQL Server
93 93
Storage
Bestde
Practices
and
Design Guidance
forpara
EMCelStorage
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.
94 94
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.
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)
Flujo de datos de CRR (replicación
remota de RecoverPoint)
Una escritura a un
LUN protegido por
RecoverPoint
El splitter de RecoverPoint
intercepta la escritura.
El splitter de RecoverPoint
intercepta la escritura.
El splitter divide a
la escritura
De forma simultánea, la
envía al volumen de
producción y al RPA local
De forma simultánea, la envía al
volumen de producción y al RPA
local.
Reconocimiento
Las escrituras se confirman
desde el RPA y el LUN de
producción de manera
inmediata.
Replicación asíncrona: Las
escrituras se confirman desde el
RPA y el LUN de producción de
manera inmediata.
Operaciones
Replicación remota síncrona:
El reconocimiento (ACK) se lleva a
cabo cuando se recibe la escritura
en el sitio remoto.
El registro de
fecha y hora y el
marcador se
escriben en el
registro
El RPA escribe los datos en
el volumen del registro,
junto con los metadatos
del registro de fecha y hora
y del marcador.
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
y reglas
diseño de
Microsoft
SQL Server
95 95
Storage
Bestde
Practices
and
Design Guidance
forpara
EMCelStorage
Operaciones
Finalizada
Flujo de datos de CDP
(replicación local de EMC
RecoverPoint)
Flujo de datos de CRR (replicación
remota de RecoverPoint)
N/D
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.
N/D
El RPA remoto escribe los datos
en el volumen del registro.
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.
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.
96 96
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
y reglas
diseño de
Microsoft
SQL Server
97 97
Storage
Bestde
Practices
and
Design Guidance
forpara
EMCelStorage
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:
(datos por segundo) ×
(tiempo requerido de reversión en segundos)
Tamaño del registro =
(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 = 69.213 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.
98 98
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
y reglas
diseño de
Microsoft
SQL Server
99 99
Storage
Bestde
Practices
and
Design Guidance
forpara
EMCelStorage
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
Detalles
Activar el acceso a la imagen del último
marcador.
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.
En RecoverPoint Management
Application o con la consola de
administración de Unisphere,
seleccione failover a la réplica remota.
Confirmar que el almacenamiento remoto
sea completamente accesible para el
servidor ESX.
Reexaminar todo el almacenamiento en
el servidor ESX remoto a través de la
consola remota de vCenter.
Registrar la máquina virtual del sitio
remoto.
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.
Iniciar 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.
100100
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 10.10.10.x a 10.20.20.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.
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.
Figura 36.
La vNIC está configurada y conectada
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
y reglas
diseño de
Microsoft
SQL Server
101 101
Storage
Bestde
Practices
and
Design Guidance
forpara
EMCelStorage
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).
102102
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
y reglas
diseño de
Microsoft
SQL Server
103 103
Storage
Bestde
Practices
and
Design Guidance
forpara
EMCelStorage
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, almacenamiento de EMC 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.
104104
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
y reglas
diseño de
Microsoft
SQL Server
105 105
Storage
Bestde
Practices
and
Design Guidance
forpara
EMCelStorage
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.
106106
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
y reglas
diseño de
Microsoft
SQL Server
107 107
Storage
Bestde
Practices
and
Design Guidance
forpara
EMCelStorage
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.
108108
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
y reglas
diseño de
Microsoft
SQL Server
109 109
Storage
Bestde
Practices
and
Design Guidance
forpara
EMCelStorage
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.
3.
Establecer la copia de réplica remota de RecoverPoint como la copia de
producción
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.
110110
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
y reglas
diseño de
Microsoft
SQL Server
111 111
Storage
Bestde
Practices
and
Design Guidance
forpara
EMCelStorage
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.
112112

mejores prácticas y reglas de diseño de microsoft sql server para el

Transcripción

Documentos relacionados

Analizar y Mantener el código PowerBuilder

Sistema de Comisiones Vendedores externos

Descargar La protección de la información del futuro

Manual de Instalación - NT-ware