Descripción de los factores de alta disponibilidad

 

Se aplica a: Exchange Server 2010 SP2, Exchange Server 2010 SP3

Última modificación del tema: 2015-03-09

Al planificar una arquitectura de base de datos y servidor Buzón de correo de alta disponibilidad, se deben tomar decisiones de diseño, por ejemplo:

  • ¿Se implementarán varias copias de base de datos?

  • ¿Cuántas copias de base de datos se implementarán?

  • ¿Se utilizará una arquitectura que proporciona resistencia al sitio?

  • ¿Qué tipo de modelo de resistencia de servidor Buzón de correo se implementará?

  • ¿Cuántos servidores Buzón de correo se implementarán?

  • ¿Cómo se distribuirán las copias de base de datos?

  • ¿Qué modelo de copias de seguridad se usará?

  • ¿Qué arquitectura de almacenamiento se usará?

Microsoft Exchange Server 2010 le permite implementar una infraestructura de servidores de buzones con servidores de buzones independientes o servidores de buzones configurados para resistencia de buzón de correo. Los servidores de buzones configurados para resistencia de buzón de correo utilizan un grupo de disponibilidad de base de datos (DAG) con varias copias de base de datos distribuidas de manera eficiente en el DAG. En la implementación de varias copias de bases de datos, puede:

  • Diseñar una solución para mitigar las razones más frecuentes por las que se usa una copia de seguridad. Las copias de base de datos ofrecen protección contra errores de centros de datos, software y hardware.

  • Aumentar el tamaño de la base de datos hasta 2 terabytes, ya que su mecanismo de recuperación es la creación de otra copia de base de datos en lugar de la restauración desde la copia de seguridad.

  • Considerar alternativas de arquitectura de almacenamiento para la configuración tradicional de RAID como un conjunto de discos (JBOD) si implementa tres o más copias de base de datos. La combinación de JBOD y discos más económicos permite ahorrar costos en la organización.

Mediante la distribución de bases de datos activas entre todos los servidores que participan de un DAG, es posible maximizar la eficiencia del hardware.

Para obtener información detallada, consulte Diseño de alta disponibilidad y resistencia de sitios y Descripción de la copia de seguridad, restauración y recuperación ante desastres.

Contenido

Planificación de la cantidad de copias de base de datos que se implementarán

Tipos de copia de base de datos

Resistencia del sitio

Planificación del modelo de resistencia de servidores Buzón de correo

Planificación de la cantidad de servidores Buzón de correo que se implementarán

Planificación del diseño de las copias de base de datos

Planificación de la arquitectura del modelo de copias de seguridad

Planificación de la arquitectura del modelo de almacenamiento

¿Está buscando las tareas de administración relacionadas con la alta disponibilidad? Consulte Administración de la alta disponibilidad y la resistencia de sitios.

Planificación de la cantidad de copias de base de datos que se implementarán

Como se analizó en Descripción de copias de bases de datos de buzones de correo, un miembro de DAG puede hospedar una copia de cada base de datos de buzón de correo, con un máximo de 100 bases de datos por servidor en la Enterprise Edition del producto (tanto las copias activas como las pasivas se consideran para este límite). Esto significa que se admite un límite de 1.600 bases de datos en un DAG de 16 miembros (100 copias de base de datos por servidor × 16 servidores por DAG ÷ 1 copia por base de datos = 1.600 bases de datos por DAG).

En una configuración de alta disponibilidad, la implementación de una sola copia de base de datos no tiene valor, ya que no proporciona redundancia de datos. Se usa una fórmula para determinar la cantidad de bases de datos que un DAG específico puede admitir. Por ejemplo, si elige que D sea la cantidad de bases de datos que se implementan, que C sea la cantidad de copias de cada base de datos y que S sea la cantidad de servidores, se aplicará lo siguiente:

  • D × C = cantidad total de copias de base de datos en el DAG

  • (D × C) ÷ S = copias de base de datos por servidor

Nota

La cantidad resultante de bases de datos por servidor debe ser 100 o menos al usar Enterprise Edition, y 5 o menos al usar Standard Edition.

Por ejemplo, supongamos que tiene un DAG con 6 servidores y 84 bases de datos de buzón de correo, con 3 copias de cada base de datos. (Tenga en cuenta que 6 servidores es un múltiplo entero de las 3 copias). Se aplica lo siguiente:

  • 84 bases de datos × 3 copias = 252 bases de datos en total

  • 252 bases de datos ÷ 6 servidores = 42 copias de base de datos por servidor

Consideremos otro ejemplo: tiene un DAG con 4 servidores y 136 bases de datos de buzón de correo, con 3 copias de cada base de datos. Se aplica lo siguiente:

  • 136 bases de datos × 3 copias = 408 bases de datos en total

  • 408 bases de datos ÷ 4 servidores = 102 copias de base de datos por servidor

Dado que 102 es mayor que 100, el escenario propuesto no es un diseño de DAG válido.

Volver al principio

Tipos de copia de base de datos

Hay dos tipos de copias de base de datos:

  • Copias de base de datos de alta disponibilidad

  • Copias de base de datos retrasadas

Las copias de base de datos de alta disponibilidad son copias configuradas con un retraso de reproducción igual a cero. Como su nombre lo indica, las copias de base de datos de alta disponibilidad se mantienen actualizadas por medio del sistema, pueden ser activadas automáticamente por el sistema y se usan para brindar alta disponibilidad a los datos y el servicio de buzón de correo.

Las copias de base de datos retrasadas son copias configuradas para retrasar la reproducción del registro de transacciones durante un período de tiempo. Las copias de base de datos retrasadas están diseñadas para brindar protección de un momento dado, que puede utilizarse para recuperarse de daños de lógica del almacén, errores administrativos (por ejemplo, eliminación o purgación de un buzón de correo desconectado) y errores de automatización (por ejemplo, purgación masiva de buzones de correo desconectados).

Por lo general, las copias de base de datos retrasadas no se activan debido al algoritmo de selección de copia del administrador activo. Dado que las copias de base de datos retrasadas se implementan para mitigas los riesgos operativos, no deben activarse. Si se activan y se emite una solicitud de montaje, comenzará la reproducción de todos los archivos de registros requeridos para actualizar la base de datos y establecerla en un estado de cierre correcto, por lo que se perderá la capacidad de un momento dado.

Para obtener más información acerca de cómo bloquear la activación a nivel de servidor Buzón de correo o cómo suspender la activación de una o más copias de base de datos a fin de evitar que una copia de base de datos (por ejemplo, una copia de base de datos retrasada) se active automáticamente, consulte Set-MailboxServer y Suspend-MailboxDatabaseCopy.

Volver al principio

Resistencia del sitio

El entorno puede constar de varios centros de datos. Como parte del diseño de Exchange 2010, se debe determinar si se implementará la infraestructura de Exchange en un solo centro de datos o si se distribuirá en dos o más centros de datos. Los acuerdos de nivel de servicio (SLA) de recuperación de la organización deden definir el nivel de servicio requerido después de un error en el centro de datos principal.

Si la implementación de Exchange se realizará en varios centros de datos para admitir objetivos de resistencia del sitio, considere cuál es el modelo de distribución de usuarios que corresponde. Hay dos tipos de modelo de distribución de usuarios, según la localización del buzón de correo con respecto al centro de datos:

  • Modelo de distribución de usuarios activo/pasivo

  • Modelo de distribución de usuarios activo/activo

Si los buzones de correo de usuario se ubican, principalmente, en un solo centro de datos (o si los usuarios acceden a sus datos mediante un solo centro de datos) y hay un requisito de SLA para que los usuarios continúen accediendo a sus datos por medio del centro de datos principal durante el funcionamiento normal, la arquitectura tiene un modelo de distribución de usuarios activo/pasivo.

Si los buzones de correo de usuario están dispersos en diferentes centros de datos y hay un requisito de SLA para que los usuarios continúen accediendo a sus datos por medio del centro de datos principal durante el funcionamiento normal, la arquitectura tiene un modelo de distribución de usuarios activo/activo.

En un modelo de distribución de usuarios activo/pasivo, es posible implementar la arquitectura como se muestra en la siguiente figura, en la que los buzones de correo activos se hospedan desde el centro de datos principal, pero las copias de base de datos se implementan en el centro de datos secundario.

Modelo de distribución de usuarios activo/pasivo con dos centros de datos

Modelo de distribución de usuario activo/activo

La arquitectura que se muestra en la siguiente figura podría utilizarse para un modelo de distribución de usuarios activo/activo.

Modelo de distribución de usuarios activo/activo con dos centros de datos

Modelo de distribución activo/pasivo

Sin embargo, la arquitectura que se muestra en la figura anterior presenta un riesgo. La red de área extensa (WAN) es un único punto de posible error para el DAG. La pérdida de la WAN provocará la pérdida del quórum para los miembros del DAG en el segundo centro de datos. En este ejemplo, el clúster de conmutación por error de Windows tiene un total de cinco votos (cuatro miembros del DAG más el servidor testigo) y requiere tres votos para estar disponible de manera continua a fin de que el clúster de conmutación por error siga funcionando. Tres de los votos se ubican en el centro de datos de Redmond y dos de los votos se ubican en el centro de datos de Portland. La pérdida de la conexión de WAN provoca que el centro de datos de Portland hospede solo dos votos, lo cual no es suficiente para mantener el quórum. El centro de datos de Redmond tiene tres votos y, por lo tanto, puede mantener el quórum y continuar brindando servicios a los buzones de correo activos (mientras esos tres votos continúen funcionando).

A fin de mitigar este riesgo para modelos de distribución de usuarios activo/activo, se recomienda implementar dos DAG, como se muestra en la siguiente figura.

Dos DAG para el modelo de distribución de usuarios activo/activo

Dos DAG entre dos centros de datos activos

DAG1 hospeda los buzones de correo activos para el centro de datos de Redmond y se implementa como un modelo de distribución de usuarios activo/pasivo, con copias de base de datos pasivas implementadas en el centro de datos de Portland. DAG2 hospeda los buzones de correo activos para el centro de datos de Portland y se implementa como un modelo de distribución de usuarios activo/pasivo, con copias de base de datos pasivas implementadas en el centro de datos de Redmond.

Esta arquitectura puede sobrevivir a la pérdida de la WAN:

  • En el centro de datos de Redmond, los miembros de servidor Buzón de correo para DAG2 se establecen en un estado de error debido a la pérdida de quórum, pero los miembros de servidor Buzón de correo activos para DAG1 continúan funcionando y brindando servicios a los usuarios.

  • En el centro de datos de Portland, los miembros de servidor Buzón de correo para DAG1 se establecen en un estado de error debido a la pérdida de quórum, pero los miembros de servidor Buzón de correo activos para DAG2 continúan funcionando y brindando servicios a los usuarios.

Para obtener más información, consulte Diseño de alta disponibilidad y resistencia de sitios.

Volver al principio

Planificación del modelo de resistencia de servidores Buzón de correo

Un aspecto clave de la planificación de capacidad de servidores Buzón de correo de Exchange 2010 es determinar cuántas copias de base de datos se desea activar en cada servidor en configuraciones para resistencia de buzón de correo. Existe una gama de diseños posibles, pero se recomiendan los dos modelos que se describen en las secciones siguientes.

Diseño para todas las copias de bases de datos activadas

Es posible diseñar la arquitectura del servidor para que administre todas las copias de base de datos hospedadas que se activan. Por ejemplo, si su servidor hospeda 35 copias de base de datos, debe diseñar el procesador y la memoria para hospedar las 35 bases de datos que están activas durante el período de actividad máxima de usuarios. Esta solución, por lo general, se implementa en pares. Por ejemplo, si se implementan cuatro servidores, un par serán los servidores 1 y 2, y el segundo par serán los servidores 3 y 4. Además, al diseñar este escenario, se asigna un máximo del 40% de los recursos disponibles para cada servidor a fin de lograr un funcionamiento con tiempos normales de ejecución.

De los dos modelos analizados en este tema, este modelo es el que tiene la mayor cantidad de servidores.

Diseño de escenarios de error de destino

Es posible diseñar la arquitectura del servidor para que administre la carga de buzones de correo activos durante el peor caso de error que desee controlar. Para este modelo se deben tener en cuenta muchos factores; por ejemplo, la resistencia del sitio, el almacenamiento RAID frente al JBOD, el tamaño del DAG y la cantidad de copias de base de datos. Este modelo de planificación de capacidad ofrece un equilibrio entre los costos de capital, la disponibilidad y las características de rendimiento del cliente.

Suponiendo que las copias de base de datos están distribuidas de manera aleatoria y uniforme:

  • Seleccione un diseño para error automático de servidor de un solo miembro en configuraciones de DAG de dos o tres miembros con dos copias de bases de datos de alta disponibilidad por base de datos Buzón de correo.

  • Seleccione un diseño para error de servidor de dos miembros (activación manual después del segundo error) en configuraciones de DAG de tres miembros con tres copias de base de datos de alta disponibilidad por base de datos Buzón de correo.

  • Seleccione un diseño para errores automáticos de servidor de dos miembros en configuraciones de DAG de cuatro o más miembros y tres o más copias de base de datos de alta disponibilidad por base de datos Buzón de correo.

Si elige este modelo de planificación de capacidad, se recomienda restringir la cantidad de bases de datos que pueden activarse por servidor a fin de evitar que se sobrecargue un solo servidor y se brinde una experiencia de usuario deficiente.

Para restringir la cantidad de bases de datos puede establecer la configuración del máximo de bases de datos activas. Puede configurar ese límite en la Consola de administración de Exchange ejecutando: Set-MailboxServer -MaximumActiveDatabases. Configure este límite en cada servidor del DAG para que coincida con el máximo de bases de datos activas admitido por la implementación.

Para obtener más información, consulte Ejemplos de diseño de grupos de disponibilidad de base de datos.

Volver al principio

Planificación de la cantidad de servidores Buzón de correo que se implementarán

Al determinar la cantidad de servidores Buzón de correo que se implementarán, debe usarse un múltiplo de la cantidad de copias de base de datos de la implementación. Por ejemplo, si desea implementar tres copias de base de datos, comience el diseño con 3, 6, 9, 12 o 15 servidores.

Después de determinar la cantidad inicial de servidores dentro del DAG, escale los miembros del DAG de manera adecuada en función de la cantidad de buzones de correo, el modelo de diseño de error y otros límites de diseño que puedan incrementar o reducir la cantidad de servidores Buzón de correo necesaria.

Un límite de diseño en muchas organizaciones es la cantidad máxima de buzones de correo que se pueden colocar en un servidor. Por ejemplo, si una organización tiene 20.000 buzones de correo y solo el 25% pueden recibir el impacto de un evento de error, la cantidad máxima de buzones de correo que se puede implementar en un solo servidor es 5.000. Esto requiere la implementación de un mínimo de cuatro servidores Buzón de correo.

También es posible que el hardware de servidor y el modelo de almacenamiento seleccionados provoquen un ajuste en la cantidad de buzones de correo o de la cantidad de copias de base de datos que se implementan por servidor, lo cual puede afectar la cantidad total de servidores Buzón de correo.

Comparación de los servidores con varios roles y los servidores con roles independientes

En Exchange Server 2007, los roles de servidor Acceso de cliente y Transporte de concentradores deben estar en servidores separados de los servidores Buzón de correo en clústeres. En Exchange 2010, los servidores Buzón de correo en clústeres ya no existen por lo que esta restricción no se aplica. Los roles de servidor Acceso de cliente y Transporte de concentradores pueden hospedarse en miembros del DAG, lo cual brinda opciones de implementación mejorada.

Al implementar servidores con varios roles (roles de servidor Buzón de correo, Acceso de cliente y Transporte de concentradores en el mismo servidor), la mayoría de las arquitecturas se simplifican. Excepto los servidores Transporte permimetral y Mensajería unificada, todos los servidores Exchange 2010 pueden ser idénticos. Estos servidores pueden tener el mismo hardware, el mismo proceso de instalación de software y las mismas opciones de configuración. La coherencia entre servidores puede simplificar la administración de la implementación de Exchange.

El servidor con varios roles (en entornos de gran escala) brinda un uso más eficiente de los servidores con gran cantidad de núcleos, lo cual brinda altas capacidades de megaciclos. Cada rol, cuando se lo implementa individualmente, tiene una cantidad máxima recomendada de dos sockets de procesador utilizados. Al combinar roles, la cantidad máxima recomendada de sockets de procesador es cuatro. Los servidores pueden tener mayores cargas de trabajo, lo cual permite reducir la cantidad total de servidores de la organización. La implementación de menos servidores reduce el costo de administración de esos servidores, ya que el servidor con varios roles cambia el costo de un gasto operacional periódico a un gasto de capital que se realiza una sola vez. Una cantidad reducida de servidores puede resultar en reducciones considerables en alimentación, enfriamiento y espacio de centro de datos, lo cual puede reducir aún más los gastos operacionales periódicos.

Aunque el concepto de varios roles es eficiente, es posible que los roles independientes de servidor resulten adecuados. Por ejemplo, las implementaciones de roles independientes probablemente resulten adecuadas en ciertos entornos virtualizados o cuando se usan ciertas arquitecturas de hardware (como una infraestructura de servidores blade en la que no se pueda aislar el hardware adecuadamente).

Al implementar servidores con varios roles, debe diseñarse la arquitectura de procesador y de memoria adecuadamente. Desde la perspectiva del procesador, debe asegurarse de que el rol de servidor Buzón de correo no consuma más del 40% de los megaciclos disponibles durante el modo de error y dejar 40% para los roles Transporte de concentradores y Acceso de cliente. Para garantizar que la memoria adecuada esté disponible para todos los roles de servidor, siga las pautas de memoria establecidas en Descripción de la memoria caché de la base de datos de buzones.

Para obtener más información, consulte Descripción de varias configuraciones del rol del servidor en la planificación de capacidad.

Volver al principio

Planificación del diseño de las copias de base de datos

Como parte del diseño de alta disponibilidad, se debe crear un diseño equilibrado de copias de base de datos. Al planificar el diseño de las copias de base de datos, deben seguirse los siguientes principios de diseño:

  • Asegúrese de minimizar los errores de copias de base de datos de una base de datos de buzón de correo específica mediante el aislamiento de cada copia. Por ejemplo, no coloque más de una copia de base de datos en una base de datos de buzón de correo específica en la misma estantería de servidor o en la misma matriz de almacenamiento. De lo contrario, un error de estantería o de matriz provocará un error en varias copias de la misma base de datos, lo cual afectará la disponibilidad de la base de datos.

  • Cree un diseño consistente y distribuido de las copias de base de datos a fin de asegurarse de que las bases de datos de buzón de correo activas se distribuyan de manera uniforme después de un error. El total de las preferencias de activación de cada copia de base de datos en un servidor específico debe ser el mismo o casi el mismo, ya que esto permitirá conservar aproximadamente la misma distribución después del error, suponiendo que la replicación está en buen estado y actualizada.

Para obtener más información, consulte Diseño de la copia de base de datos.

Volver al principio

Planificación de la arquitectura del modelo de copias de seguridad

Exchange 2010 incluye varias características y cambios de arquitectura que, cuando se implementan y se configuran de manera correcta, pueden ofrecer protección de datos nativos y, así, eliminar la necesidad de realizar copias de seguridad tradicionales de los datos. Utilice la siguiente tabla para decidir si necesita continuar usando un modelo de copias de seguridad tradicional o si puede implementar las características de protección de datos nativos en Exchange 2010.

Problema Mitigación

Errores de software

Resistencia de buzón de correo (varias copias de base de datos)

Errores de hardware

Resistencia de buzón de correo (varias copias de base de datos)

Errores de sitio o de centro de datos

Resistencia de buzón de correo (varias copias de base de datos)

Eliminación accidental o malintencionada de elementos

Recuperación de elementos individuales o retención de elementos eliminados con una ventana que cumple o supera el SLA de recuperación de elementos

Escenarios de daños físicos

Restauración de páginas individuales (copias de base de datos de alta disponibilidad)

Escenarios de daños de lógica

Recuperación de elementos individuales

Asistente de reparación de calendario

Movimientos de buzones de correo

Cmdlet New-MailboxRepairRequest

Copia de seguridad de un momento dado

Errores administrativos

Copia de seguridad de un momento dado

Errores de automatización

Copia de seguridad de un momento dado

Administradores no autorizados

Copia de seguridad de un momento dado (aislada)

Requisitos de cumplimiento de normativas legales y corporativas

Copia de seguridad de un momento dado (aislada)

Los daños de lógica constituyen un escenario que, generalmente, requiere una copia de seguridad de un momento dado. Sin embargo, con Exchange 2010, existen varias opciones disponibles para mitigar la necesidad de una copia de seguridad de un momento dado:

  • Mediante la recuperación de elementos individuales, si el usuario cambia ciertas propiedades de un elemento en cualquier carpeta de buzón de correo, se guarda una copia del elemento en la carpeta Elementos recuperables antes de que la modificación se escriba en la base de datos. Si la modificación del mensaje genera una copia dañada, puede restaurarse el elemento original.

  • El Asistente de reparación de calendario detecta y corrige de manera automática las inconsistencias que se producen en elementos de reuniones únicas y periódicas para buzones de correo hospedados en ese servidor Buzón de correo para que los destinatarios no pierdan anuncios de reuniones o dispongan de información de reuniones poco confiable.

  • Durante los movimientos de buzones de correo, el servicio de replicación de buzones de correo de Exchange detecta elementos dañados y no los mueve a la base de datos de buzón de correo de destino.

  • El Service Pack 1 (SP1) de Exchange 2010 introduce el cmdlet New-MailboxRepairRequest, que permite corregir daños con carpetas de búsqueda, conteos de elementos, vistas de carpetas y problemas de carpetas principales y secundarias.

Una copia de seguridad de un momento dado puede ser una copia de seguridad tradicional o una copia de base de datos retrasada, las cuales brindas las mismas capacidades. La elección de una de las dos depende del SLA de recuperación. El SLA de recuperación define el objetivo de punto de recuperación (si se produce un desastre, los datos deben restaurarse dentro de un período de tiempo específico), además del tiempo durante el cual se deben retener las copias de seguridad. Si el SLA de recuperación es de 14 días o menos, puede utilizarse la copia de base de datos retrasada. Si el SLA de recuperación es de más de 14 días, debe usarse una copia de seguridad tradicional. Para escenarios de administrador no autorizado o de cumplimiento de normativas legales o corporativas, la copia de seguridad de un momento dado, generalmente, se mantiene separada de la infraestructura de mensajería y del personal de mensajería, lo que impone una solución de copia de seguridad tradicional.

Si decide mantener la copia de seguridad de un momento dado, es posible que cambien varios aspectos del diseño:

  • La implementación de copias de base de datos retrasada tiene implicaciones de almacenamiento. Debe asignarse espacio adicional para los registros de transacciones en la copia de base de datos retrasada debido a la configuración de ReplayLagTime. Asimismo, la ubicación de la copia de base de datos retrasada puede afectar la arquitectura de almacenamiento. (Para obtener información detallada, consulte "Planificación de la arquitectura del modelo de almacenamiento" más adelante en este tema).

  • La implementación de una solución de copia de seguridad tradicional tiene implicaciones en el diseño del número de unidad lógica (LUN), según el tipo de solución de Servicio de instantáneas de volumen (VSS), ya que las soluciones de clonación de VSS basadas en hardware requieren dos LUN por arquitectura de base de datos.

Según la arquitectura de almacenamiento, es posible que el uso de una solución de copia de seguridad tradicional requiera una reducción considerable los tamaños deseados de buzón de correo de usuario a fin de cumplir los SLA de período de tiempo para copia de seguridad y restauración.

Cuando se implementa la protección de datos nativos de Exchange, se habilita el registro circular en las bases de datos de buzón de correo. Al activar el registro circular, asegúrese de que la capacidad suficiente esté incorporada al sistema, de modo que la solución sobreviva a eventos de desastre a fin de evitar el truncamiento del registro. Como mínimo, debe asegurarse de que haya al menos tres días de capacidad de registro de transacciones (excluidos los requisitos de copias retrasadas). Para obtener más información acerca del funcionamiento del registro circular con la replicación continua, consulte Descripción de la copia de seguridad, restauración y recuperación ante desastres.

Para obtener información adicional acerca de la planificación de copias de seguridad, consulte:

Volver al principio

Planificación de la arquitectura del modelo de almacenamiento

Exchange 2010 brinda flexibilidad en el diseño de almacenamiento. Exchange 2010 incluye mejoras en rendimiento, confiabilidad y alta disponibilidad que permiten a las organizaciones ejecutar Exchange en distintos dispositivos de almacenamiento. La versión más reciente de Exchange, que aprovecha las mejoras de entrada/salida (E/S) de disco incorporada en Exchange 2007, requiere menos rendimiento del almacenamiento y tiene mayor tolerancia a errores de almacenamiento.

Seleccione una plataforma de almacenamiento que garantice que se equilibren los requisitos de capacidad con los requisitos de E/S, y, a la vez, garantice que la solución proporcione una latencia de disco aceptable y una experiencia rápida para el usuario.

RAID o JBOD

Determine si desea implementar una plataforma de almacenamiento mediante tecnología RAID o un enfoque JBOD (suponiendo que la plataforma de almacenamiento permite configuraciones JBOD). Desde la perspectiva de Exchange, JBOD significa almacenar la base de datos y los registros asociados en un solo disco. Para implementar JBOD, se debe implementar un mínimo de tres copias de base de datos de alta disponibilidad. Si se usa un solo disco, se contará con un único punto de posible error, ya que, cuando se produce un error en el disco, la copia de base de datos que reside en ese disco se pierde. Si se cuenta con un mínimo de tres copias de base de datos, se garantiza la tolerancia a errores, dado que se cuenta con dos copias adicionales en caso de error en una copia (o disco). Sin embargo, la ubicación de tres copias de base de datos de alta disponibilidad, además del uso de copias de base de datos retrasadas, puede afectar el diseño de almacenamiento. La siguiente tabla muestra las pautas para considerar implementaciones de RAID o JBOD.

Consideraciones para RAID o JBOD

Servidores de centro de datos Dos copias de alta disponibilidad (totales) Tres copias de alta disponibilidad (totales) Dos o más copias de alta disponibilidad por centro de datos Una copia retrasada Dos o más copias retrasadas por centro de datos

Servidores de centro de datos principal

RAID

RAID o JBOD (2 copias)

RAID o JBOD

RAID

RAID o JBOD

Servidores de centro de datos secundario

RAID

RAID (1 copia)

RAID o JBOD

RAID

RAID o JBOD

Para una implementación en JBOD con servidores de centro de datos primario, se necesitan tres o más copias de base de datos de alta disponibilidad en el DAG. Si se combinan copias retrasadas en el mismo servidor que hospeda copias de base de datos de alta disponibilidad (por ejemplo, sin usar servidores dedicados para copias de base de datos retrasadas), se necesitan al menos dos copias de base de datos retrasadas.

Para que los servidores de centro de datos secundario usen JBOD, se debe contar con al menos dos copias de base de datos de alta disponibilidad en el centro de datos secundario. La pérdida de una copia en el centro de datos secundario no resultará en la necesidad de reinicialización en toda la WAN o en la disponibilidad de un único punto de error posible en caso de que se active el centro de datos secundario. Si se combinan copias de base de datos retrasadas en el mismo servidor que hospeda copias de base de datos de alta disponibilidad (por ejemplo, sin usar servidores dedicados para copias de base de datos retrasadas), se necesitan al menos dos copias de base de datos retrasadas.

Para servidores de copias de base de datos retrasadas, se requieren al menos dos copias de base de datos retrasadas dentro del centro de datos para utilizar JBOD. De lo contrario, la pérdida de un disco provocará la pérdida de la copia de base de datos retrasada y la pérdida del mecanismo de control.

Para obtener más información, consulte Descripción de la configuración de almacenamiento.

Volver al principio

 © 2010 Microsoft Corporation. Reservados todos los derechos.