1© copyright 2013 emc corporation. todos los derechos reservados. microsoft exchange mejores...

1© Copyright 2013 EMC Corporation. Todos los derechos reservados.

Microsoft ExchangeMejores prácticas y reglas de diseño para el almacenamiento de EMC• Exchange 2010 y Exchange 2013• Sistemas de almacenamiento VNX y VMAX

Strategic Solutions Engineering

Actualizado en octubre de 2013


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?• Cambios 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?

Exchange 2007

◊ Windows de 64 bits◊ Caché de base de datos de más de

32 GB◊ Tamaño de bloques de 8 kB◊ Relación de lectura/escritura de la

base de datos de 1:1◊ Reducción del 70 % en los IOPS de

Exchange 2003

Exchange 2010

◊ Windows de 64 bits◊ Caché de base de datos (DAG) de

100 GB◊ Tamaño de bloques de 32 kB◊ Relación de lectura/escritura de la base

de datos de 3:2◊ Reducción del 70 % en los IOPS de

Exchange 2007

Exchange 2013

◊ Windows de 64 bits◊ Caché de base de datos (DAG) de 100 GB◊ Tamaño de bloques de 32 kB◊ Relación de lectura/escritura de la base

de datos de 3:2◊ Reducción del 33 % en los IOPS de

Exchange 2010


Cambios en el perfil de usuario de Exchange

Mensajes enviados/recibidos

por buzón de correo por día

IOPS de Exchange 2010 estimados por buzón de correo (activos o pasivos)

IOPS de Exchange 2013 estimados por

buzón de correo(activos o pasivos)Resistencia del buzón de correo Independiente

50 0.05 0.06 0.034

100 0.100 0.120 0.067

150 0.150 0.180 0.101

200 0.200 0.240 0.134

250 0.250 0.300 0.168

300 0.300 0.360 0.201

350 0.350 0.420 0.235

400 0.400 0.480 0.268

450 0.450 0.540 0.302

500 0.500 0.600 0.335


Cambios en los requisitos del procesador de Exchange

Mensajes enviados o

recibidos por buzón de

correo por día

Megaciclos por usuarioCopia de base de datos activa o independiente

(solo MBX)

Megaciclos por usuarioCopia de base de datos activa o independiente

(multifunción)

Megaciclos por usuarioCopia pasiva de base

de datos

Exchange 2010

Exchange 2013

Exchange 2010

Exchange 2013

Exchange 2010

Exchange 2013

50 1 2.13 N/D 2.66 0.15 0.69

100 2 4.25 N/D 5.31 0.3 1.37

150 Tres 6.38 N/D 7.97 0.45 2.06

200 4 8.50 N/D 10.63 0.6 2.74

250 5 10.63 N/D 13.28 0.75 3.43

300 6 12.75 N/D 15.94 0.9 4.11

350 7 14.88 N/D 18.59 1.05 4.80

400 Ocho 17.00 N/D 21.25 1.2 5.48

450 9 19.13 N/D 23.91 1.35 6.17

500 10 21.25 N/D 26.56 1.5 6.85


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

Tipo de I/O Exchange 2007 Exchange 2010 Exchange 2013

I/O de base de datosI/O de escritura aleatorio de 8 kB

I/O aleatorio de 32 kB I/O aleatorio de 32 kB

I/O de mantenimiento de base de datos de fondo (BDM)

N/DI/O de lectura secuencial de 256 kB

I/O de lectura secuencial de 256 kB

I/O de logVaría en tamaño de 512 bytes al tamaño de buffer de log (1 MB)

Varía en tamaño de 4 kB al tamaño de buffer de log (1 MB)

Varía en tamaño de 4 kB al tamaño de buffer de log (1 MB)


Relaciones de lectura/escritura de I/O de la base de datos del buzón de correo de Exchange 2010/2013Mensajes enviados/recibidos por buzón de correo por día

Bases de datos independientes

Bases de datos que participan en la resistencia del buzón de correo

50 1:1 3:2

100 1:1 3:2

150 1:1 3:2

200 1:1 3:2

250 1:1 3:2

300 2:3 1:1

350 2:3 1:1

400 2:3 1:1

450 2:3 1:1

500 2:3 1:1


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

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

Exchange 2010 Exchange 2013Tamaño de I/O de lectura 256 kB 256 kB

Finalización del escaneo de la base de datos Una semana Cada cuatro semanas

IOPS por base de datos 30 9

Ancho de banda 7.5 MB/s* 2.25 MB/s*

* 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 24x7)

– La copia pasiva se “codifica” para el escaneo 24x7– 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

BD2Copiar

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 MBX3MBX2


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

http://mexico.emc.com/solutions/application-environment/microsoft/solutions-for-microsoft-exchange-unified-communications.htm

http://mexico.emc.com/solutions/application-environment/microsoft/solutions-for-microsoft-exchange-unified-communications.htm

http://technet.microsoft.com/es-mx/exchange/ff182054.aspx


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

Tipo de disco

IOPS de base de datos de Exchange 2010/2013 por disco

(carga de trabajo aleatoria)

IOPS de logs de base de datos de Exchange Server 2010/2013 por disco

(carga de trabajo secuencial)

VNX/VMAX VNX VMAX VNX y VMAX

Discos SAS NL/SATA de 7,200 r/min

65 60 180

Discos SAS/FC de 10,000 r/min

135 130 270

Discos SAS/FC de 15,000 r/min

180 180 450

Flash 1,250 1,250 2,000


Virtualización de Exchange• Recomendaciones 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

http://go.microsoft.com/fwlink/?LinkId=125375



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



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



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



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



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



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 (\\server\share\db1\db1.edb)


Ejemplo de configuración compatible con SMB 3.0



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



VMFS RDMEl volumen puede alojar muchas máquinas virtuales (o se puede dedicar a una máquina virtual)

Asigna un solo LUN a una máquina virtual; I/O aislado

Aumenta la utilización de almacenamiento, proporciona mejor flexibilidad y simplifica la administración y el almacenamiento

Más LUN = es más fácil llegar al límite de LUN de 256 que se pueden presentar a ESX Server

No puede tener respaldos de VSS activados por hardware Obligatorio para las herramientas de replicación y VSS de hardware que se integran a las bases de datos de Exchange

Grandes ecosistemas de otros fabricantes con productos V2P para prestar ayuda en determinadas situaciones de soporte

Puede ayudar a reducir el tiempo de migración físico a virtual

Sin soporte para la agrupación en clusters de disco compartido

Obligatorio para la agrupación en clusters de disco compartido

Soporte total para VMware Site Recovery Manager Soporte total para VMware Site Recovery Manager

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

http://www.microsoft.com/es-mx/download/details.aspx?id=2428

http://www.microsoft.com/es-mx/download/details.aspx?id=2428

http://download.microsoft.com/download/4/A/C/4AC32FD3-220E-45DC-AA97-DBDBE19C15B2/Best_Practices_for_Virtualizing_and_Managing_Exchange_2013.pdf

http://www.vmware.com/files/pdf/Exchange_2010_on_VMware_-_Best_Practices_Guide.pdf

http://www.vmware.com/files/pdf/exchange-2010-on-vmware-design-and-sizing-examples.pdf


Mejores prácticas y diseño de almacenamiento de Exchange• Metodologí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 ExchangeFase 1:Recopilación de requisitos

• Cantidad total de usuarios• Cantidad de usuarios por

servidor• Perfil de usuario y tamaño

del buzón de correo• Simultaneidad de usuarios• Requisitos de alta

disponibilidad (configuración de DAG)

• SLA de respaldo y restauración

• Software de otros fabricantes en uso (archiving, Blackberry, etc.)

Fase 2:Diseño del componente básico y la arquitectura de almacenamiento

• Diseñe el componente básico mediante las mejores prácticas de Microsoft y EMC

• Diseñe la arquitectura de almacenamiento mediante las mejores prácticas de EMC

• Utilice los informes técnicos de soluciones EMC Proven

• Use la documentación del programa Exchange Solution Review Program (ESRP)

Fase 3:Validación del diseño

• Use las herramientas de validación de Microsoft Exchange:• JetStress: para la

validación del almacenamiento

• LoadGen: para la validación de la carga de trabajo de usuario y la validación de la solución de punto a punto


Diseño de almacenamiento de ExchangeMetodologí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

https://community.emc.com/docs/DOC-13037?et=watches.email.document

http://gallery.technet.microsoft.com/Exchange-2010-Mailbox-Server-Role-/

http://gallery.technet.microsoft.com/Exchange-2013-Server-Role-f8a61780


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.

http://support.microsoft.com/kb/2870270


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

http://technet.microsoft.com/es-mx/library/dd335108

http://blogs.technet.com/b/exchange/archive/2010/01/22/updates-to-the-exchange-2010-mailbox-server-role-requirements-calculator.aspx

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



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



• 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




• 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)




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• Opciones 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 plazoUna 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 tiempoExisten 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



Los respaldos de flujos ya no se admiten ni son compatibles con Exchange 2010/2013EMC 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 VSSDisminuye los requisitos de hardware para los respaldosIntegra mecanismos de deduplicación de datos Alivia la contención de hardware y recursos en el nivel de servidor



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 hardwareRealizan una shadow copy mediante el dispositivo de almacenamiento fuera del SODependen del hardware para realizar el clon/snapshotIncluyen VNX SnapView, VNX Snapshots y Symmetrix TimeFinder


• 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



• 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 XtremCache

ALMACENAMIENTO DE EMC VNX Y VMWARE VSPHERE

Solución completada en marzo de 2013


Arquitectura de la solución


Detalles de los componentes básicos de Exchange 2010

Número total de buzones de correo por servidor 5,000 buzones de correo por servidor

Tamaño de buzón de correo 1.5 GB por usuario

Perfil de usuario 150 mensajes por usuario por día (0.150 IOPS)

Tamaño de mensaje promedio de destino 75 kB

Diseño de base de datos

• Seis bases de datos por servidor

• 833 usuarios por base de datos

• Tamaño de base de datos de 1,300 GB aprox. (tamaño de LUN de 1,650 GB)

Diseño de log Seis LUN de log (tamaño de LUN de 90 GB)

Cantidad de máquinas virtuales de buzón de correo de Exchange por ESX Tres

Configuración de disco por servidor 18 (16 bases de datos más 2 logs), discos SAS NL de 2 TB

Memoria/CPU recomendados por máquina virtual 32 GB de RAM, 29,040 megaciclos de CPU

Ventana de retención de elementos eliminados (“papelera”) 14 días

Buffer de protección de logs Tres días

Configuración de BDM 24x7 Activada

Relación de lectura/escritura de la base de datos 3:2 (en la configuración de resistencia de buzones de correo)


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• 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

http://mexico.emc.com/collateral/hardware/white-papers/h8888-exch-2010-storage-best-pract-design-guid-emc-storage.pdf

https://community.emc.com/community/connect/everything_microsoft

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://technet.microsoft.com/es-mx/library/gg598215.aspx

http://mexico.emc.com/collateral/software/white-papers/h7410-zero-data-loss-exchange-wp.pdf


http://technet.microsoft.com/es-mx/library/dd346703.aspx



• 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

http://technet.microsoft.com/es-mx/library/jj126252.aspx

http://technet.microsoft.com/es-mx/library/dd351192

http://www.windowsservercatalog.com/svvp/

http://technet.microsoft.com/es-mx/library/gg598215(v=exchg.141).aspx

http://technet.microsoft.com/es-mx/library/hh145600(v=exchg.141).aspx


Apéndice• Proceso 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 ExchangeFase 1:Recopilación de requisitos

• Cantidad total de usuarios• Cantidad de usuarios por

servidor• Perfil de usuario y tamaño

del buzón de correo• Simultaneidad de usuarios• Requisitos de alta

disponibilidad (configuración de DAG)

• SLA de respaldo y restauración

• Software de otros fabricantes en uso (archiving, Blackberry, etc.)

Fase 2:Diseño del componente básico y la arquitectura de almacenamiento

• Diseñe el componente básico mediante las mejores prácticas de Microsoft y EMC

• Diseñe la arquitectura de almacenamiento mediante las mejores prácticas de EMC

• Aproveche los informes técnicos de soluciones EMC Proven

• Aproveche la documentación del programa de Exchange Solution Review Program (ESRP)

Fase 3:Validación del diseño

• Use las herramientas de validación de Microsoft Exchange

• JetStress: para la validación del almacenamiento

• LoadGen: para la validación de las cargas de trabajo de usuario y la validación de la solución de punto a punto


Ejemplo de recopilación de requisitosElemento Valor Versión de Exchange. Número total de usuarios activos (buzones de correo) en el ambiente Exchange 2013, 20,000

Requisitos de resistencia del sitio Un solo sitio

Infraestructura de almacenamiento SAN

Tipo de implementación (física o virtual) Virtual (VMware vSphere)

Requisitos de alta disponibilidad Un DAG con dos copias de bases de datos

Límite de tamaño del buzón de correo Cuota máxima de 2 GB

Perfil de usuario 200 mensajes por usuario por día (0.134 IOPS)

Tamaño de mensaje promedio de destino 75 kB

Modo Outlook Modo de caché, MAPI de 100 %

Cantidad de servidores de buzón de correo Ocho

Cantidad de buzones de correo por servidor 5,000 (2,500 activos/2,500 pasivos)

Cantidad de bases de datos por servidor 10

Cantidad de usuarios por base de datos 500

Período de retención de elementos eliminados (DIR) 14 días

Buffer de protección de log (para protección contra fallas de truncamiento de log) Tres días

Configuración de BDM Activada 24x7

Relación de lectura/escritura de la base de datos 3:2 (60/40 %) en una configuración de DAG

Requisitos de simultaneidad de usuarios 100 %

Software de otros fabricantes que afecta el espacio o I/O (por ejemplo, Blackberry, snapshots) Snapshots de almacenamiento para la protección de datos

Tipo de disco Disco SAS NL de 3 TB (7,200 r/min)

Plataforma de almacenamiento VNX


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

IOPS transaccionales totales = IOPS por buzón de correo * buzones de correo por servidor + (porcentaje de sobrecarga recomendada por Microsoft)

IOPS transaccionales totales = 5,000 usuarios * 0.134 IOPS por usuario + 20 % de sobrecarga recomendada por Microsoft = 670 + 134 = 804 IOPS

IOPS de front-end totales = (IOPS transaccionales totales) + (% de sobrecarga exigido por EMC)

IOPS de front-end totales = 804 + 20 % de sobrecarga exigida por EMC = 965 IOPS (redondeado de 964.8)


Requisitos de discos de base de datos para el rendimiento (IOPS)

Discos necesarios para IOPS de base de datos de Exchange = (IOPS de back-end totales de lectura de la base de datos) + (IOPS de back-end totales de escritura de la base de datos)/IOPS aleatorios de Exchange por disco

Donde:

IOPS de back-end totales de lectura de la base de datos = (IOPS de front-end totales) * (porcentaje de IOPS de lectura)

IOPS de back-end totales de escritura de la base de datos = Penalidad de escritura de RAID * (IOPS de front-end totales) * (porcentaje de IOPS de escritura)

Fórmula


Requisitos de discos de base de datos para el rendimiento (IOPS)

Opciones de RAID

Penalidad de RAID Discos necesarios

RAID 1/0 (4+4) 2(965 × 0.60) + 2(965 × 0.40) = 579 + 772 = 1351 / 65 = 21 (redondeado a 24 discos)

RAID 5 (4+1) 4(965 × 0.60) + 4(965 × 0.40) = 579 + 1544 = 2123 / 65 = 33 (redondeado a 35 discos)

RAID 6 (6+2) 6(965 × 0.60) + 6(965 × 0.40) = 579 + 2316 = 2895 / 65 = 45 discos (redondeado a 48 discos)

Cálculos


Fórmula y cálculos

Requisitos de IOPS de logs transaccionales

Discos necesarios para IOPS de base de datos de Exchange = (IOPS de back-end totales de escritura de la base de datos * 50 %) + (IOPS de back-end totales de escritura de la base de datos * 10 %)/ IOPS de Exchange secuenciales por disco

Discos necesarios para IOPS de log de Exchange = (772 IOPS de back-end de escritura * 50 %) + (772 *10 %) / 180 IOPS de Exchange secuenciales por disco = (386 + 77.2) / 180 = 2.57 (redondeado a cuatro discos)


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

Tamaño del buzón de correo en disco = Tamaño máximo del buzón de correo + Espacio en blanco + Papelera

Tamaño de la base de datos en disco = número de buzones de correo por base de datos * tamaño del buzón de correo en disco

Tamaño de LUN de la base de datos = Número de buzones de correo * Tamaño de buzón de correo en disco * (1 + espacio para índices + espacio para índices adicional para mantenimiento) / (1 + espacio libre de LUN)


FórmulaTamaño del buzón de correo en disco

Tamaño del buzón de correo en disco = Tamaño máximo del buzón de correo + Espacio en blanco + Papelera

Donde:Espacio en blanco estimado de la base de datos por buzón de correo = perfil de mensajes diarios por usuario * tamaño promedio de los mensajes

Donde:Papelera = (perfil de mensajes diarios por usuario * tamaño promedio de los mensajes * ventana de retención de elementos eliminados) + (tamaño de cuota del buzón de correo * 0.012) + (tamaño de cuota del buzón de correo * 0.03)


CálculosTamaño del buzón de correo en disco

Espacio en blanco = 200 mensajes/día * 75 kB = 14.65 MB

Papelera = (200 mensajes/día * 75 kB * 14 días) + (2 GB * 0.012) + (2 GB x 0.03) = 205.1 + 24.58 + 61.44 = 291.12 MB

Tamaño del buzón de correo en disco = cuota de buzón de correo de 2 GB + espacio en blanco de la base de datos de 14.65 MB + papelera de 291.12 MB = 2,354 MB (2.3 GB)


Cálculos

Tamaño de la base de datos en disco y tamaño de LUN

Tamaño de la base de datos en disco = 500 usuarios por base de datos * buzón de correo de 2,354 MB en disco = 1,177 GB (1.15 TB)

Tamaño de LUN de base de datos = 1,177 GB * (1 + 0.2 + 0.2) / (1 - 0.2) = 2,060 (2 TB)

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álculosCálculos del espacio de logs

Tamaño de LUN de log = (Tamaño de log) * (Número de buzones de correo por base de datos) * (Días de tolerancia a fallas de respaldo/truncamiento) + (Espacio para admitir las transferencias de buzones de correo) / (1 + espacio libre de LUN)

Capacidad de log para admitir tres días de falla de truncamiento = (500 buzones de correo/base de datos × 40 logs/día × tamaño de log de 1 MB) × 3 días = 58.59 GB

Capacidad de log para admitir las transferencias de buzones de correo del 1 % por semana = 500 buzones de correo/base de datos x 0.01 x tamaño de buzón de correo de 2.3 GB = 11.5 GB

Tamaño de LUN de log = 58.59 GB + 11.5 GB /(1 - 0.2) = 87.61 GB (redondeado a 88 GB)


Capacidad total por componente básico

Tipo de capacidad de LUN Capacidad de LUN necesaria por servidor

Capacidad de LUN de base de datos

2,060 GB por LUN * 10 LUN por servidor = 20,600 GB

Capacidad de LUN de log 88 GB por LUN * 10 LUN por servidor = 880 GBCapacidad total de LUN por servidor

20,600 + 880 = 21,480 GB

Capacidad total de tamaño de LUN necesaria por servidor = (Tamaño de LUN de base de datos por servidor) + (Tamaño de LUN de log por servidor) * (Número de bases de datos por servidor)


Cantidad total de discos necesarios

Discos de base de datos

Discos de logs

Discos necesarios para la capacidad de base de datos de Exchange = Tamaño total de LUN de base de datos / Capacidad de disco físico * Factor de multiplicación RAID

Discos necesarios para la capacidad de log de Exchange = (Tamaño total de LUN de log) / Capacidad de disco físico * Factor de multiplicación RAID


Requisitos de discos según la capacidad

Opciones de RAID Discos de base de datos necesarios

RAID 1/0 (4+4) 20,600/2794.5 * 2 = 7.37 * 2 = 14.74 (redondeado a 16 discos)

RAID 5 (4 + 1) 20,600/2794.5 * 1.25 = 7.37 * 1.25 = 9.2 (redondeado a 10 discos)

RAID 6 (6+2) 20,600/2794.5 * 1.33 = 7.37 * 1.33 = 9.8 (redondeado a 16 discos)

Opciones de RAID Discos de logs necesarios

RAID 1/0 (1+1) 880 / 2,794.5 * 2 = 0.63 (redondeado a dos discos)


Resumen del componente básico

Resultados finales del cálculo de almacenamiento

Tipo de volumen

Opciones de RAID

Discos necesarios para el rendimiento (IOPS)

Discos necesarios para la capacidad

Mejor opción

Bases de datos de Exchange

RAID 1/0 (4+4) 24 discos 16 discos 24 discos

RAID 5 (4 + 1) 35 discos 10 discos

RAID 6 (6+2) 48 discos 16 discos

Logs de Exchange

RAID 1/0 (1+1) Cuatro discos Dos discos Cuatro discos

Discos totales por componente básico 28 discos


Escalabilidad del componente básico

Resultados finales del cálculo de almacenamiento

Cantidad total de discos necesarios para la solución completa de 20,000 usuarios en un DAG con dos copias = 28 discos por componente básico * 8 componentes básicos = 224 discos en total


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 arregloRendimiento 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:1. Determinar la cantidad de bases de datos en el ambiente de Exchange2. Determinar los requisitos de ancho de banda por base de datos3. Determinar los requisitos necesarios de ancho de banda por bus de arreglo4. 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

5. 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


Ancho de banda por base de datos (MB/s) = IOPS transaccionales totales por base de datos * 32 kB + Rendimiento de BDM estimado por base de datos (MB/s)Donde:• 32 kB es un tamaño de página de Exchange• El rendimiento de BDM estimado por base de datos es de 7.5 MB/s para Exchange 2010 y de 2.25 MB/s para Exchange 2013

Rendimiento en MB/s necesario por bus = (rendimiento en MB/s por base de datos) * (cantidad total de bases de datos activas y pasivas por bus)


Cálculos


IOPS transaccionales totales por base de datos = (500 * 0.134 * 32 kB = 2.1 MB/s Rendimiento por base de datos = 2.1 MB/s + 2.25 MB/s = 4.35 MB/s Rendimiento necesario por bus = 4.35 MB/s * 200 bases de datos por bus = 870 MB/sSupuestos de ejemplo:• 500 usuarios a 0.134 IOPS por base de datos• 200 bases de datos por bus

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




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


• 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

1© copyright 2013 emc corporation. todos los derechos reservados. microsoft exchange mejores...

Documents