Microsoft Exchange. Mejores prácticas y reglas de diseño para el almacenamiento de EMC
Temas
Exchange: ¿cuáles son los cambios?
Virtualización de Exchange
Mejores prácticas y diseño de almacenamiento de Exchange
Mejores prácticas de respaldo de Exchange
Referencias adicionales
Exchange: ¿cuáles son los cambios?
SubCambios en el perfil de usuario de Exchange
Características de I/O de Exchange
Mantenimiento de base de datos de fondo
Grupo de disponibilidad de base de datos (DAG)
Alternativas de almacenamiento
Exchange… ¿Cuáles son los cambios?
Cambios en el perfil de usuario de Exchange
Cambios en los requisitos del procesador de Exchange
Características de I/O de Exchange
Los IOPS de usuario disminuyeron para Exchange Server 2010/2013, pero el tamaño de I/O aumentó considerablemente
Relaciones de lectura/escritura de I/O de la base de datos del buzón de correo de Exchange 2010/2013
Comprensión de I/O de Exchange
El I/O de Exchange 2010/2013 para la base de datos (.edb) se divide en dos tipos:
I/O transaccional (también conocido como I/O de usuario)
I/O de volumen de base de datos (lecturas y escrituras de la base de datos)
I/O de volumen de log (lecturas y escrituras de log)
Solo se miden los I/O de base de datos al dimensionar el almacenamiento y durante la validación de Jetstress
I/O no transaccional
Mantenimiento de base de datos de fondo (BDM) (suma de verificación)
Para obtener más información, consulte “Descripción de las bases de datos y los factores de rendimiento del registro” en http://technet.microsoft.com/es-mx/library/ee832791(v=exchg.141).aspx
Mantenimiento de base de datos de fondo (BDM)
¿Qué es una BDM y para qué sirve?
Corresponde al proceso de mantenimiento de base de datos de Exchange Server 2010/2013 que incluye desfragmentación en línea y escaneo de base de datos en línea
Se escanean las copias de base de datos activas y pasivas
* Según las pruebas de EMC con Jetstress 2010/2013
Mantenimiento de base de datos de fondo (BDM)
Se escanean las copias de base de datos activas y pasivas
Se puede calendarizar una copia activa para ejecutarse durante la ventana de mantenimiento en línea (lo predeterminado es 24×7)
La copia pasiva se “codifica” para el escaneo 24×7
Jetstress no tiene concepto de copia pasiva; todas son activas
Posibles problemas relacionados con BDM (la mayoría con Exchange 2010):
Se requiere ancho de banda/rendimiento para BDM y los IOPS de BDM
No existen puertos de FE ni puertos de BE suficientes; configuración de RAID inadecuada
Consideraciones del índice de contenido de Exchange
Consideraciones de espacio del índice de contenido:
En Exchange 2010, el espacio del índice de contenido se calcula en alrededor del 10 % del tamaño de la base de datos.
En Exchange 2013, el espacio del índice de contenido se calcula en alrededor del 20 % del tamaño de la base de datos.
Se debe agregar un 20 % adicional para completar las tareas de mantenimiento del índice de contenido (como el proceso de fusión maestra).
BD1
BD3
BD2
Copiar
Copiar
Copiar
Copiar
Copiar
Copiar
Grupo de disponibilidad de base de datos
A = Activo
P = Pasivo
A
A
A
P
P
P
P
P
P
Alta disponibilidad de Exchange
Componente básico del marco de trabajo de alta disponibilidad y resistencia del sitio incorporado en Exchange 2010/2013
Un DAG corresponde a un grupo de servidores que participan en un cluster de failover de Windows con un límite de 16 servidores y 100 bases de datos.
Todos los servidores que participan en un DAG pueden tener una copia de cualquier base de datos del DAG
Cada servidor miembro del DAG puede alojar una copia de cada base de datos, hasta 16 copias, con solo una de ellas activa, pasiva o rezagada
No se requiere configuración de los servicios de cluster; Exchange 2010/2013 controla toda la instalación
Se deben ejecutar los scripts durante el trabajo manual de recuperación de desastres del sitio
Un DAG no proporciona recuperación para daños lógicos en la base de datos
Grupo de disponibilidad de base de datos (DAG)
MBX1
MBX3
MBX2
Alta disponibilidad de Exchange
Asegúrese de que todos los elementos del diseño tengan componentes resistentes
Procesadores de almacenamiento
Conectividad a los servidores
Ejes de almacenamiento
Arreglos múltiples en escenarios de recuperación de desastres
Las copias de DAG se deben almacenar en ejes físicos independientes
Siempre que toda la resistencia se haya alcanzado en el sitio de origen
En SAN, considere el rendimiento de las copias activas y pasivas dentro del arreglo
Guía para implementar DAG
Opciones de almacenamiento de Exchange
Comprenda cuál es el tipo de almacenamiento que mejor cumple con los requisitos de diseño
¿Físico o virtual?
¿Exclusivo de Exchange o compartido con otras aplicaciones?
Siga la guía de EMC Proven para cada plataforma
Informes técnicos de soluciones Proven http://mexico.emc.com/solutions/application-environment/microsoft/solutions-for-microsoft-exchange-unified-communications.htm (visite el sitio web de su país correspondiente)
Presentaciones de la solución de almacenamiento de EMC para el programa Microsoft ESRP http://technet.microsoft.com/es-mx/exchange/ff182054.aspx
¿DAS o SAN?
EMC ofrece ambas opciones
Para bajo costo = DAS
Para eficiencia a gran escala = SAN
Mejor TCO a largo plazo = SAN
Preparado para virtualización = SAN
Iomega
VNXe
VNX
VMAX
IOPS de Exchange Server por discos
Use la siguiente tabla sobre valores de IOPS por unidad al calcular los requisitos de disco para Exchange 2010/2013
Las recomendaciones pueden cambiar según los resultados de pruebas futuras
Virtualización de Exchange
SubRecomendaciones y soporte
Referencias para mejores prácticas de diseño
Configuraciones de implementación compatibles
Mejores prácticas de configuración
Virtualización de Exchange 2010/2013
La virtualización es una tecnología comprobada preparada para la nube
Exchange no está orientado a la virtualización, pero es compatible con esta
EMC recomienda virtualizar Exchange en la mayoría de las implementaciones según los requisitos de usuario
Compatible con Hyper-V, VMware y otros hipervisores
Los proveedores de Hypervisor deben participar en el Programa de validación de virtualización del servidor de Windows (SVVP)
Recomendaciones y soporte
Virtualización de Exchange
DAG
DAG de Exchange en hosts de hipervisor independientes
Servidores de buzón de correo independientes de Exchange en clusters de host de hipervisor
VMware DRS/HA o Windows Cluster
DAG
DAG de Exchange con clusters de host de hipervisor
Configuraciones de implementación compatibles con Exchange 2010/2013 (ejemplo)
VMware DRS/HA o Windows Cluster
Virtualización de Exchange
Conozca los límites de sus hipervisores:
256 discos SCSI por host (o cluster)
Límites del procesador (vCPU por máquina virtual)
Límites de memoria
Esté atento a la sobrecarga de CPU del hipervisor:
Microsoft Hyper-V: de 10 a 12 % aprox.
VMware vSphere: de 5 a 7 % aprox.
Mejores prácticas de configuración: general
Virtualización de Exchange
Se siguen aplicando los principios de diseño principales de Exchange
Diseño para rendimiento y alta disponibilidad
Diseño para cargas de trabajo de usuario
Dimensione las máquinas virtuales específicas para la función de Exchange
Se sigue aplicando el dimensionamiento físico
El servidor de hipervisor físico debe admitir a los huéspedes a los que les brindará soporte
Las copias de DAG se deben distribuir en los hosts físicos para minimizar la interrupción en caso de problemas con el servidor físico
Mejores prácticas de configuración
Virtualización de Exchange
Use el sentido común al ubicar las máquinas virtuales
Implemente máquinas virtuales con la misma función en varios hosts
No implemente máquinas virtuales MBX del mismo DAG en el mismo servidor de host
Mejores prácticas de configuración: recomendaciones para la ubicación de las máquinas virtuales
Virtualización de Exchange
Desactive las tecnologías de migración que guardan el estado y efectúe la migración
Realice siempre una migración activa o apague completamente las máquinas virtuales
Dedique/reserve CPU y memoria para las máquinas virtuales del buzón de correo y no los sobreasigne
Relación de pCPU a vCPU: 2:1 está bien, 1:1 es una mejor práctica
Desactive las funciones de ajuste automático basado en hipervisor
Sin memoria dinámica
El servidor de hipervisor debe tener al menos cuatro rutas (HBA/CNA/iSCSI) al almacenamiento: cuatro puertos en total
Instale EMC PowerPath en el servidor de hipervisor para obtener un máximo rendimiento, balanceo de carga, administración de rutas y detección de fallas en las rutas de I/O
Mejores prácticas de configuración
Virtualización de Exchange
El almacenamiento de Exchange debe encontrarse en ejes independientes del almacenamiento físico del SO huésped
El almacenamiento de Exchange debe estar al nivel de bloque
Los volúmenes de almacenamiento conectado en red (NAS) no son compatibles
Sin NFS, SMB (que no sea SMB 3.0) ni ninguna otra tecnología NAS
El almacenamiento debe ser VHD/VHDX/VMDK fijo, SCSI de paso/RDM o iSCSI
La migración activa de Hyper-V recomienda volúmenes compartidos en cluster con VHD fijo (período de “corte” más rápido)
Mejores prácticas de configuración: almacenamiento
Compatibilidad con SMB 3.0
Solo en configuraciones virtualizadas
Los VHD pueden residir en recursos compartidos de SMB 3.0 presentados al host Hyper-V
Sin soporte para la ruta UNC de los volúmenes de log y base de datos de Exchange (\serversharedb1db1.edb)
Ejemplo de configuración compatible con SMB 3.0
Virtualización de Exchange
SCSI virtual (disco fijo o de paso)
VHD en host: recomendado para SO, archivos de programas
Disco de paso en host: recomendado para volúmenes de log y base de datos de Exchange
iSCSI
iSCSI directo desde una máquina virtual huésped
Iniciador iSCSI en host y disco presentado al huésped como de paso
El iniciador iSCSI desde huésped se ejecuta sin problemas y es fácil de configurar
MPIO o EMC PowerPath: se recomienda PowerPath
Mejores prácticas de configuración: almacenamiento de Hyper-V
Virtualización de Exchange
Mejores prácticas de configuración: desventajas de VMware VMFS y RDM
Mejores prácticas para Exchange virtualizado
Para Hyper-V:
Best Practices for Virtualizing Exchange Server 2010 with Windows Server 2008 R2 Hyper-V
Best Practices for Virtualizing and Managing Exchange 2013
Para VMware:
Microsoft Exchange 2010 on VMware Best Practices Guide
Microsoft Exchange 2010 on VMware Design and Sizing Examples
Microsoft Exchange 2013 on VMware Best Practices Guide
Microsoft Exchange 2013 on VMware Availability and Recovery Options
Microsoft Exchange 2013 on VMware Design and Sizing Guide
Referencias
Mejores prácticas y diseño de almacenamiento de Exchange
SubMetodología del diseño de almacenamiento del servidor de buzón de correo
Recomendaciones y soporte
Referencias para mejores prácticas de diseño
Configuraciones de implementación compatibles
Mejores prácticas de configuración
Metodología del diseño de almacenamiento del servidor de buzón de correo de Exchange
Diseño de almacenamiento de Exchange
Metodología de diseño del componente básico de Exchange
¿Qué es un componente básico?
Un componente básico representa la cantidad de recursos necesarios para brindar soporte a una cantidad específica de usuarios de Exchange en un solo servidor o máquina virtual
Los componentes básicos se basan en requisitos e incluyen:
Requisitos de cómputo (CPU, memoria y red)
Requisitos de disco (base de datos, log y SO)
¿Por qué usar el enfoque de componentes básicos?
Se puede reproducir fácilmente para admitir a todos los usuarios con características de perfil de usuario similares
Hace que las adiciones de ambientes sean mucho más fáciles y directas, lo cual es útil para el futuro crecimiento del ambiente
Ha tenido mucho éxito para muchas implementaciones de clientes del mundo real
Consulte el Apéndice para obtener más información sobre el proceso de diseño del componente básico
Diseño de almacenamiento de Exchange
No dependa únicamente de herramientas automatizadas al dimensionar su ambiente de Exchange
Dedique tiempo y esfuerzo a sus cálculos. Además, proporcione datos objetivos de apoyo sobre sus diseños en lugar de cálculos ficticios
Dimensione Exchange según los requisitos de I/O, de capacidad del buzón de correo y de ancho de banda
Piense en otras variables de sobrecarga como archiving, protección de snapshots, protección de virus, dispositivos móviles y factor de riesgo
Confirme los requisitos de almacenamiento de Exchange con herramientas específicas para el dimensionamiento de arreglos
Diseño de almacenamiento de Exchange
Diseño de almacenamiento de Exchange
EMC Exchange 2010-2013 Designer con DIVA: https://community.emc.com/docs/DOC-13037?et=watches.email.document
Calculadora de requisitos de funciones de servidor de Microsoft Exchange
Exchange 2010: http://gallery.technet.microsoft.com/Exchange-2010-Mailbox-Server-Role-/
Exchange 2013: http://gallery.technet.microsoft.com/Exchange-2013-Server-Role-f8a61780
Herramienta para dimensionamiento VSPEX
Herramientas específicas para el dimensionamiento de arreglos, por ejemplo, VNX Disksizer
Cálculo manual para administradores avanzados
Opciones de herramientas para el dimensionamiento de Exchange
Guía de diseño para el almacenamiento general
Aísle la carga de trabajo de Exchange Server para su propio conjunto de ejes de otras cargas de trabajo para garantizar el rendimiento
Al realizar el dimensionamiento, calcule siempre los requisitos de I/O y de capacidad
Separe la base de datos y los logs en volúmenes diferentes
Implemente copias de DAG en ejes físicos independientes
Las bases de datos de un tamaño máximo de 2 TB son aceptables cuando se usa DAG:
El tamaño exacto se debe basar en los requisitos del cliente
Asegúrese de que su solución sea compatible con varios LUN de más de 2 TB
Mejores prácticas
Guía de diseño para el almacenamiento general
Considere los tiempos de respaldo y restauración al calcular el tamaño de la base de datos
Distribuya la carga de la manera más uniforme posible en los recursos de arreglos, motores VMAX, SP de VNX, buses de back-end, etc.
Formatee siempre los volúmenes NTFS de Windows para bases de datos y logs con un tamaño de unidad de asignación de 64 kB
Use un enfoque de diseño del componente básico de Exchange siempre que sea posible
Mejores prácticas: continuación
Ambos métodos son factibles y ofrecen el mismo rendimiento (pools gruesos frente a grupos RAID)
Los grupos RAID se limitan a 16 discos por grupo RAID, mientras que los pools pueden brindar soporte a más discos
Los pools son más eficaces y fáciles de administrar
Use pools si planea usar funciones avanzadas como:
FAST VP, snapshots de VNX
Los pools de almacenamiento pueden brindar soporte a un solo componente básico o a varios de ellos según los requisitos del cliente
Diseñe y amplíe los pools usando el multiplicador adecuado para obtener el mejor rendimiento (R1/0 4+4, R5 4+1, R6 6+2)
¿Pools o grupos RAID?
Guía de diseño para el almacenamiento general: VNX
Guía de diseño para el almacenamiento general: VNX
Es posible usar LUN gruesos y delgados para el almacenamiento de Exchange (base de datos y logs)
Los LUN gruesos se recomiendan cargas de trabajo de gran actividad con perfiles de usuario de IOPS altos
Los LUN delgados se recomiendan para cargas de trabajo de intensidad media a ligera con perfiles de usuario de IOPS bajos
Beneficios: reduce de manera considerable los requisitos de almacenamiento inicial
Use el optimizador de pools de VNX antes de formatear los volúmenes
Es posible activar FAST Cache o FAST VP para la promoción rápida de metadatos
¿LUN gruesos o delgados?
Recomendaciones de configuración (VNX y VMAX)
Diseño de almacenamiento de Exchange con FAST VP
Separe los datos de los logs, debido a las diferentes cargas de trabajo
Datos: carga de trabajo aleatoria con sesgo; altos beneficios de FAST VP
Logs: datos secuenciales sin sesgo; sin beneficios de FAST VP
Use pools exclusivos
Proporciona una mejor garantía de SLA
Proporciona dominios de fallas
Microsoft lo recomienda para obtener un comportamiento más determinista
Use LUN de pool gruesos para obtener el máximo rendimiento (en VNX)
Los LUN de pool gruesos son aceptables con flash en FAST Cache o pool
Use LUN delgados en VMAX
FAST Cache (solo VNX)
Diseño de almacenamiento de Exchange
FAST Cache permite que el sistema de almacenamiento proporcione rendimiento de nivel de disco flash para tener acceso de manera más profunda a los segmentos de datos en todo el sistema
Absorbe picos de I/O de las aplicaciones y, como consecuencia, reduce la carga en los discos duros de back-end.
Absorbe automáticamente los metadatos de los pools
Mejora el rendimiento de la solución de almacenamiento
Se puede activar/desactivar por bases de pool de almacenamiento
FAST Cache (solo VNX)
Diseño de almacenamiento de Exchange
Uso de FAST Cache
Pools con LUN delgados para el rastreo de metadatos
Pools con LUN delgados y gruesos cuando se usan snapshots de VNX
Pools con LUN gruesos
No son obligatorios pero tampoco se encuentran restringidos
Obligatorios con snapshots de VNX
Guía de dimensionamiento de FAST Cache
Regla general: por cada 1 TB de conjunto de datos de Exchange, provisione 1 GB de FAST Cache
Monitoree y ajuste el tamaño de FAST Cache, su millaje puede variar
Active FAST Cache en los pools solo con LUN de base de datos
Diseño de almacenamiento de Exchange: VMAX
Asegúrese de que las configuraciones iniciales del disco sean compatibles con los requisitos de I/O
Es posible configurar un pool delgado para brindar soporte a un solo componente básico o a varios componentes básicos de Exchange, según los requisitos del cliente
Use Unisphere for VMAX para monitorear la utilización de los pools delgados y evitar que estos se queden sin espacio
Instale el hotfix de Microsoft KB2870270 en los hosts de Windows Server 2012 del ambiente.
Diseño de almacenamiento de Exchange: VMAX
Use el aprovisionamiento virtual de Symmetrix
Es posible compartir bases de datos y volúmenes de log en los mismos discos, pero sepárelos en LUN distintos en los mismos hosts
Para el rendimiento óptimo de Exchange, use metavolúmenes fraccionados
Mejores prácticas de diseño
VMAX FAST VP con Exchange
Siga estas reglas al diseñar FAST VP para Exchange 2010/2013 en VMAX:
Separe las bases de datos y los logs en sus propios volúmenes
Es posible compartir bases de datos y volúmenes de log en los mismos discos.
Excluya los volúmenes de log de transacción de la política de FAST VP o junte todos los volúmenes de log en el nivel en el cual se crearon
Seleccione Allocate by FAST Policy para permitir que FAST VP use todos los niveles para nuevas asignaciones según las restricciones de rendimiento y capacidad
Nueva función presentada en el código de Enginuity™ 5876
Al usar FAST VP con DAG de Exchange, no coloque copias de DAG de la misma base de datos en el mismo pool en los mismos discos
Mejores prácticas de diseño
Herramientas de validación de Exchange
Herramientas JetStress y Load Generator de Exchange: http://technet.microsoft.com/es-mx/library/dd335108
Calculadora de requisitos de funciones de servidores de buzones de correo de Exchange 2010: http://blogs.technet.com/b/exchange/archive/2010/01/22/updates-to-the-exchange-2010-mailbox-server-role-requirements-calculator.aspx
XtremCache con Exchange
XtremCache es una solución de almacenamiento en caché flash en el servidor que reduce la latencia y aumenta el rendimiento para mejorar el rendimiento de las aplicaciones mediante el aprovechamiento del software inteligente y la tecnología flash PCIe.
XtremCache acelera las lecturas de I/O de bloques para las aplicaciones que requieren IOPS mayores o el mínimo tiempo de respuesta.
XtremCache acelera las lecturas y protege los datos mediante una memoria caché de escritura inmediata en el almacenamiento en red para proporcionar alta disponibilidad persistente y recuperación de desastres.
Funciona con software FAST y FAST Cache basado en arreglos
Optimizado para ambientes físicos y virtuales
¿Qué es XtremCache?
¿Por qué XtremCache para Exchange?
Considere XtremCache para Exchange si:
Tiene una solución de Exchange enlazada con I/O
No está seguro de su carga de trabajo anticipada
Necesita garantizar un alto rendimiento y una baja latencia para usuarios específicos (servidores VIP, bases de datos, etc.)
Se ha demostrado que XtremCache mejora el rendimiento de Exchange, ya que:
Reduce las latencias de lectura
Aumenta el rendimiento de I/O
Elimina casi todos los altos aumentos repentinos de latencia
Provisiona más mejoras a medida que aumenta la carga de trabajo
Reduce las latencias de llamadas RPC
Reduce las escrituras al almacenamiento de back-end con deduplicación de XtremCache
XtremCache con Exchange
La tarjeta flash PCI de XtremCache se puede instalar en
Un servidor físico de buzón de correo de Exchange
El servidor de hipervisor que aloje máquinas virtuales del buzón de correo de Exchange (VMware o Hyper-V)
Active la aceleración de XtremCache únicamente en volúmenes de bases de datos
Guía de dimensionamiento de XtremCache:
Para un conjunto de datos en funcionamiento de 1,000 GB, configure 10 GB de dispositivo de XtremCache
Recomendaciones sobre la configuración
XtremCache con Exchange
Al implementar XtremCache con VMware vSphere, considere lo siguiente:
El tamaño de la tarjeta de caché PCI que ha de implementarse
La cantidad de máquinas virtuales de Exchange implementadas en cada host de vSphere que utilizarán XtremCache
Características de la carga de trabajo de Exchange (relación de escritura:lectura, tipo de perfil del usuario)
Tamaño del conjunto de datos de Exchange
La mayoría de los beneficios se obtienen cuando se almacenan en caché todas las lecturas de un conjunto de datos en funcionamiento
Recomendaciones sobre la configuración
XtremCache con Exchange
Al agregar un dispositivo de XtremCache a una máquina virtual de Exchange:
Configure el tamaño de página de caché en 64 kB y de I/O máximo en 64 kB (I/O de BDM no se almacenará en caché)
Puede usar el comando de plug-in de VSI o la CLI de XtemCache para configurar el tamaño de la página de caché en 64 kB y el tamaño máximo de I/O en 64 kB al agregar el dispositivo de caché a una máquina virtual:
vfcmt add -cache < cache_device> -set_page_size 64 -set_max_io_size 64)
Recomendaciones sobre la configuración
XtremCache con Exchange
Evalúe su carga de trabajo antes de considerar activar la deduplicación para los LUN acelerados de Exchange
Considere la sobrecarga del CPU al habilitar la deduplicación
Configure la relación de deduplicación según las características de la carga de trabajo:
Si la relación de deduplicación observada es menor que el 10 %, EMC recomienda apagarla (o configurarla en 0 %), lo que permitirá aprovechar una vida útil más larga de los dispositivos de caché.
Si la relación observada es mayor que el 35 %, EMC recomienda aumentar la ganancia de deduplicación de modo que coincida con la deduplicación observada.
Si la relación observada está entre el 10 % y el 35 %, EMC recomienda dejar la ganancia de deduplicación tal como está.
Recomendaciones sobre la configuración (deduplicación)
Mejores prácticas de respaldo
SubOpciones de respaldo
Proveedores de software y hardware VSS
Mejores prácticas de respaldo
Asegúrese de comprender la importancia de los respaldos y pregunte si existen requisitos de retención a largo plazo
Una opción es usar copias de alta disponibilidad/copias rezagadas de DAG para respaldos en un punto en el tiempo, pero considere lo siguiente:
Los respaldos suelen estar sujetos a requisitos normativos
Retención ampliada en el tiempo
Existen escenarios que la copia regazada/de alta disponibilidad de DAG no abordará
Si se activa la copia rezagada, se debe volver a crear una nueva copia
Mejores prácticas de respaldo de Exchange
Los respaldos de flujos ya no se admiten ni son compatibles con Exchange 2010/2013
EMC recomienda aprovechar la tecnología VSS para la replicación y el respaldo coherentes de las bases de datos y archivos de log de Exchange por los siguientes motivos:
Proporciona recuperación rápida a través de proveedores de hardware VSS
Disminuye los requisitos de hardware para los respaldos
Integra mecanismos de deduplicación de datos
Alivia la contención de hardware y recursos en el nivel de servidor
Mejores prácticas de respaldo de Exchange
Existen dos proveedores VSS: basados en hardware y basados en software. Conozca la diferencia:
Proveedores basados en hardware:
Actúan como una interfaz entre el servicio de shadow copy de volumen y el nivel de hardware trabajando con un adaptador o controlador de almacenamiento de hardware
Realizan una shadow copy mediante el dispositivo de almacenamiento fuera del SO
Dependen del hardware para realizar el clon/snapshot
Incluyen VNX SnapView, VNX Snapshots y Symmetrix TimeFinder
Mejores prácticas de respaldo de Exchange
Proveedores basados en software:
Interceptan y procesan solicitudes de I/O en una capa de software entre el sistema de archivos y el administrador de volumen
Se implementan como controladores de dispositivos DLL en modo usuario y modo kernel. El software ejecuta la shadow copy
No dependen del hardware, de modo que existe un mayor rango de compatibilidad con plataformas
Incluyen Avamar, Networker NMM y NetBackup
Mejores prácticas de respaldo de Exchange
Se recomiendan snapshots con VSS
Ya no se requieren controles de coherencia con dos o más copias de DAG
Se requiere menos espacio de almacenamiento
Son posibles los clones protegidos, pero considere lo siguiente:
Tamaños de bases de datos más grandes
Ejecución del respaldo desde una copia de DAG pasiva
Actividad durante el control de coherencia, respaldo
El respaldo y la restauración tienen la misma granularidad con VSS de hardware:
La recuperación se ejecuta al nivel de LUN. Considere esto durante la etapa de diseño
Considere aprovechar AppSync con ItemPoint para la recuperación de elementos individuales
Soluciones validadas de Exchange
Exchange 2013 ESRP en VNX5700
Exchange con XtremSW Cache
Soluciones VSPEX para Exchange
Aceleración del rendimiento de Microsoft Exchange con EMC XtremCacheAlmacenamiento de EMC VNX y VMware vSphere
Arquitectura de la solución
Detalles de los componentes básicos de Exchange 2010
Diseño de almacenamiento con XtremSW Cache
Dos pools de almacenamiento creados para bases de datos
48 discos SAS NL de 2 TB de 7,200 r/min por pool, RAID 1/0
Cada pool contiene varias copias de diferentes máquinas virtuales
Tres componentes básicos (tres máquinas virtuales)
18 LUN de 1.6 TB (seis LUN por máquina virtual)
El área de almacenamiento de datos VFMS de 326 GB se crea a partir de la tarjeta XtremCache PCI en cada servidor vSphere
Se crean dispositivos de caché de 50 GB por cada máquina virtual de Exchange desde el área de almacenamiento de datos de caché VMFS
La capacidad restante está reservada para máquinas virtuales que se pueden migrar desde el otro servidor vSphere
Referencias adicionales
Referencias adicionales
Informe técnico Exchange Storage Best Practices and Design Guidelines for EMC Storage:
http://mexico.emc.com/collateral/hardware/white-papers/h8888-exch-2010-storage-best-pract-design-guid-emc-storage.pdf
EMC Community Network
https://community.emc.com/community/connect/everything_microsoft
Soluciones virtualizadas probadas de EMC y los partners de Exchange 2010
http://technet.microsoft.com/es-mx/library/gg598215.aspx
http://mexico.emc.com/collateral/hardware/white-papers/h7337-exchange-unified-cisco-hyper-v-wp.pdf
http://mexico.emc.com/collateral/software/white-papers/h7410-zero-data-loss-exchange-wp.pdf
Presentaciones del programa Exchange Solution Review Program (ESRP)
http://technet.microsoft.com/es-mx/exchange/ff182054.aspx
Diseño del almacenamiento del servidor de buzones de correo de Exchange (Microsoft TechNet)
http://technet.microsoft.com/es-mx/library/dd346703.aspx
Referencias adicionales
Información acerca de la virtualización de Exchange 2010: http://technet.microsoft.com/es-mx/library/jj126252.aspx
Descripción del rendimiento de Exchange: http://technet.microsoft.com/es-mx/library/dd351192
Programa de validación de virtualización del servidor: http://www.windowsservercatalog.com/svvp/
Soluciones OEM probadas por EMC para Exchange 2010 (en Hyper-V)
20,000 usuarios del almacenamiento de EMC con aprovisionamiento virtual http://technet.microsoft.com/es-mx/library/gg598215(v=exchg.141).aspx
32,400 usuarios del almacenamiento de EMC con EMC REE http://technet.microsoft.com/es-mx/library/hh145600(v=exchg.141).aspx
Apéndice
SubProceso de diseño del componente básico
ESI para la optimización del pool de VNX
Proceso de diseño del componente básico
Metodología del diseño de almacenamiento del servidor de buzón de correo de Exchange
Ejemplo de recopilación de requisitos
Diseño del componente básico
En nuestro ejemplo definimos un componente básico como:
Un servidor de buzón de correo que admitirá 5,000 usuarios
2,500 usuarios estarán activos durante el tiempo de ejecución normal y los otros 2,500 usuarios serán pasivos hasta que se produzca un cambio desde otro servidor de buzón de correo.
Cada componente básico será compatible con dos copias de base de datos.
Defina y diseñe un componente básico
Proceso de escalamiento y dimensionamiento del componente básico
Realice cálculos para los requisitos de IOPS
Realice cálculos para los requisitos de capacidad según los diferentes tipos de RAID
Determine la mejor opción
Realice el escalamiento del componente básico
Es posible combinar varios componentes básicos para crear la configuración final y el diseño de almacenamiento (pools o grupos RAID)
Proceso de escalamiento y dimensionamiento del componente básico
IOPS de front-end ? IOPS de back-end
IOPS de front-end = IOPS totales del servidor de buzón de correo de Exchange
IOPS de back-end = IOPS del arreglo de almacenamiento (incluida penalidad de RAID)
Comprenda los IOPS de disco según el tipo de RAID
La carga de trabajo de bloque de front-end de la aplicación de Exchange se traduce en una carga de trabajo de disco de back-end diferente según el tipo de RAID en uso.
El tipo de RAID no surte efectos en las lecturas:
Un I/O de lectura de la aplicación = 1 I/O de lectura de back-end
Para escrituras aleatorias como Exchange:
RAID 1/0: Un I/O de escritura de la aplicación = dos I/O de escritura de back-end
RAID 5: Un I/O de escritura de la aplicación = cuatro I/O de discos de back-end (dos I/O de lectura + dos I/O de escritura)
RAID 6: Un I/O de escritura de la aplicación = seis I/O de discos de back-end (tres I/O de lectura + tres I/O de escritura)
Fórmula y cálculos
Requisitos de IOPS para la base de datos
Requisitos de discos de base de datos para el rendimiento (IOPS)
Fórmula
Requisitos de discos de base de datos para el rendimiento (IOPS)
Cálculos
Fórmula y cálculos
Requisitos de IOPS de logs transaccionales
Fórmula
Cálculos de la capacidad de almacenamiento
Calcule el buzón de correo de usuario en disco
Calcule el tamaño de la base de datos en disco
Calcule el tamaño de LUN de la base de datos
Fórmula
Tamaño del buzón de correo en disco
Cálculos
Tamaño del buzón de correo en disco
Cálculos
Tamaño de la base de datos en disco y tamaño de LUN
En nuestro ejemplo:
se agregó un 20 % para el índice
se agregó un 20 % para la tarea de mantenimiento del índice
se agregó un 20 % para la protección del espacio libre de LUN
Fórmula y cálculos
Cálculos del espacio de logs
Capacidad total por componente básico
Cantidad total de discos necesarios
Discos de base de datos
Discos de logs
Requisitos de discos según la capacidad
Resumen del componente básico
Resultados finales del cálculo de almacenamiento
Escalabilidad del componente básico
Resultados finales del cálculo de almacenamiento
Cálculos de ancho de banda
Proceso de escalamiento y dimensionamiento del componente básico
La validación de MB/s de rendimiento del arreglo para Exchange incluye:
Determinar cuántas bases de datos necesitará el cliente
Confirmar que los LUN de base de datos se encuentren distribuidos de manera uniforme entre los buses de back-end y los procesadores de almacenamiento.
Determinar si cada bus puede admitir el máximo rendimiento de la base de datos de Exchange
Use este cálculo para calcular el rendimiento necesario
(Rendimiento de la base de datos * cantidad de bases de datos por bus) = Rendimiento de la base de datos de Exchange
Compare esa cifra con el rendimiento de bus del arreglo
Rendimiento de la base de datos = IOPS transaccionales (usuario) totales por base de datos * 32 kB + (rendimiento de BDM por base de datos en MB/s)
Cantidad de bases de datos por bus = cantidad total de bases de datos activas y pasivas por bus
El proceso
Requisitos del ancho de banda de almacenamiento
El proceso de validación del ancho de banda incluye los siguientes pasos:
Determinar la cantidad de bases de datos en el ambiente de Exchange
Determinar los requisitos de ancho de banda por base de datos
Determinar los requisitos necesarios de ancho de banda por bus de arreglo
Determinar si cada bus puede admitir el ancho de banda máximo de la base de datos de Exchange
Use DiskSizer para VNX o póngase en contacto con el especialista local en almacenamiento para conocer las cifras de rendimiento del arreglo y del bus
DiskSizer está disponible a través del contacto local de USPEED
Distribuya de manera uniforme los LUN de base de datos entre los buses de back-end y procesadores de almacenamiento
La distribución uniforme es clave para lograr un mejor rendimiento
Grupos/POOLS FE/BE/RAID y DAE
Bases de datos distribuidas de manera uniforme en los pools
Use números pares en los loops de disco SAS (0 y 2) para obtener un máximo rendimiento
Cálculos
Requisitos del ancho de banda de almacenamiento
Cálculos
Requisitos del ancho de banda de almacenamiento
Si el arreglo es compatible con un rendimiento máximo de 3,200 MB/s por bus, es posible admitir 200 bases de datos desde una perspectiva de rendimiento.
Se configuraron pools de almacenamiento exclusivos para cada servidor de buzón de correo con 24 discos SAS NL de 3 TB.
Cada pool de almacenamiento contiene dos copias de diferentes servidores de buzón de correo.
Los archivos de log de Exchange se separaron en diferentes pools de almacenamiento.
Para un mejor uso del almacenamiento, se creó un pool de almacenamiento con 16 discos SAS NL de 3 TB para logs cada cuatro componentes básicos del servidor de buzón de correo.
Diseño final
Validación del diseño de almacenamiento
JetStress de Exchange Server
Usa archivos ejecutables de Exchange para simular cargas de I/O (usar misma versión)
Se inicia y ejecuta durante la producción previa, antes de instalar Exchange Server
Pruebas de perfil del buzón de correo y el rendimiento: la aprobación garantiza que el diseño de almacenamiento se ejecutará según lo especificado
Load Generator (LoadGen) de Exchange Server (opcional)
La validación se debe ejecutar en un laboratorio aislado
Produce una carga de trabajo simulada del cliente según una implementación de Exchange de prueba
Número estimado de usuarios por servidor y validación de la implementación de Exchange
Las pruebas de LoadGen pueden tardar varias semanas en configurar y completar las bases de datos
Validación del diseño de almacenamiento
Resultados del programa Exchange Solution Review Program (ESRP)
Programa de Microsoft para la validación de los diseños de proveedores de almacenamiento con Exchange
Los proveedores ejecutan varias pruebas de JetStress según los requisitos de rendimiento, presión, respaldo a disco y reproducción de archivos de log
Revisado y aprobado por Microsoft
http://technet.microsoft.com/es-mx/exchange/ff182054.aspx
Utilería ESI for VNX Pool Optimization (también denominada herramienta SOAP)
Utilería de optimizador de pool de almacenamiento de VNX
¿De qué se trata?
Una utilería para la optimización de LUN (gruesos o delgados) basados en pool que permite obtener el máximo rendimiento
Ofrece la mejor opción para Exchange o cualquier otra aplicación que requiera un alto rendimiento uniforme y determinista en todos los LUN del pool
Asigna segmentos de manera previa y uniforme en un pool en todos los discos y grupos RAID privados
Utilería de optimizador de pool de almacenamiento de VNX
¿Por qué debo utilizarla?
Para obtener el mejor rendimiento para los LUN (principalmente delgados) basados en pool y aprobar las pruebas de JetStress durante la validación del almacenamiento previa a la implementación
Para mitigar el “efecto JetStress”
Cuándo usar la utilería de optimizador
Casos de uso
CX4/VNX (OE for Block anteriores a 5.32 ); solo LUN gruesos
Con VNX OE 5.32 for Block, los LUN de pool gruesos se asignan previamente durante la creación
VNX Rockies (OE for Block 5.33): LUN gruesos y delgados (principalmente delgados)
Use la utilería de la herramienta SOAP con CX4 y VNX OE for Block, versión 32 (Inyo)
Use la nueva utilería ESI para la optimización de pool de VNX OE for Block, versión 33 (Rockies)
El plan a corto plazo es fusionar ambas herramientas en una
El plan a largo plazo es implementar la funcionalidad en un código VNX nativo.
¿Cuál es el problema?
¿Cómo surgió el problema?
Con JetStress, la prueba de la primera base de datos en Exchange Server:
Experimentará latencias más altas que las demás cuando el LUN sea grueso
Experimentará latencias más bajas que las demás cuando el LUN sea delgado
“Efecto JetStress”
El llenado de datos de JetStress produce desequilibrios en los discos virtuales subyacentes de un pool
Proceso de inicialización de JetStress
Funcionamiento de la fase de inicialización de JetStress:
JetStress crea la primera base de datos
Luego, crea las demás bases de datos copiando la primera base de datos en las demás bases de datos de manera simultánea
Análisis más profundo: mapas de segmentos
Sin optimización
Con optimización
Optimización de VMDK
Sin optimización
Con optimización
Opciones para el aprovisionamiento de LUN de pool gruesos
Dos opciones para el aprovisionamiento de LUN de pool gruesos
Para un rendimiento bueno y óptimo: no se necesita usar SOAP. Use aprovisionamiento de LUN de pool predeterminado mediante Unisphere, NaviSecCLI, EMC ESI o EMC VSI
Para el mejor rendimiento (IOPS máx.): use NaviSecCLI para desactivar el aprovisionamiento previo y luego ejecute SOAP
Desactive el aprovisionamiento previo mediante CLI
Ejecute SOAP
Vuelva a activar el aprovisionamiento previo
Solo VNX OE for Block versión 32 (Inyo)
La utilería SOAP antigua está disponible en el sitio de servicio de soporte en línea de EMC
Escriba “soap” en la búsqueda y seleccione “Support Tools”
Únicamente se debe usar con CX4/VNX Inyo (OE 5.32)
Únicamente es compatible con la optimización de LUN grueso
El archivo Zip contiene la herramienta, documentación detallada y un video de demostración
Antigua utilería SOAP: ¿dónde y cómo?
Utilería ESI para la optimización de pool de VNX
Se puede descargar en el sitio de servicio de soporte en línea de EMC en noviembre de 2013
Únicamente se puede usar con la serie VNX de última generación (OE 5.33) (VNX5200, VNX5400, VNX5600,VNX5800, VNX7600, VNX8000)
Compatible con optimización de LUN grueso y delgado