Diseño de la copia de base de datos

 

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

Última modificación del tema: 2010-11-11

Al diseñar una solución altamente disponible para servidores Buzón de correo, debe asegurar la alta disponibilidad para una serie de componentes de infraestructura:

• Servicios de infraestructura, por ejemplo Active Directory y sistema de nombres de dominio (DNS)

• Servidores de miembros del grupo de disponibilidad de base de datos (DAG)

• Determinados componentes de almacenamiento, por ejemplo discos, controladores y estantes

• Determinados componentes de red, por ejemplo enrutadores, conmutadores y agregadores

• Bastidores de almacenamiento y servidor

• Buses de alimentación

• Centros de datos

Cada una de estas áreas de componentes constituyen puntos de errores potenciales, que en ocasiones se denominan dominios de errores. Como consecuencia, el nivel de disponibilidad del DAG depende, en última instancia, de cómo se diseñe la solución para aislar y minimizar los efectos negativos que un error en uno de estos dominios puede tener en el entorno del DAG. Para lograr la independencia entre dominios de errores, cada dominio de error debe tener una copia de la base de datos. Además, como un error puede hacer que varias copias dejen de estar disponibles, no se necesita más de una copia por dominio de error.

Por ejemplo, imagine que tiene dos copias de una base de datos. Cada copia se guarda en un conjunto de discos independiente pero que se ubican en la misma matriz de almacenamiento. Si por algún motivo se produce un error en la matriz de almacenamiento o ésta deja de estar disponible, ninguna de las copias tampoco estará disponible. En este ejemplo, el dominio de error está en la matriz de almacenamiento. Es recomendable que en la matriz haya únicamente solamente una copia de cada base de datos de buzones de correo. De lo contrario, si se produce un error en la matriz, varias copias de la base de datos o quizá todas dejarán de estar disponibles.

A la hora de planear una arquitectura de buzones de correo, tenga en cuenta también estos puntos de diseño:

• ¿Implementará varias copias de bases de datos?

• ¿Cuántas copias de bases de datos implementará?

• ¿Dispondrá de una arquitectura resistente para sitios?

• ¿Qué clase de modelo de resistencia de servidores de buzones implementará?

• ¿Cuántos servidores de buzones de correo implementará?

• ¿Qué modelo de copia de seguridad usará?

• ¿Qué arquitectura de almacenamiento usará?

Para obtener más información sobre cómo planear esta serie de aspectos, consulte Descripción de los factores de alta disponibilidad.

Contenido

Diseños de copias de bases de datos desequilibradas

Preparación de un diseño de copias de bases de datos equilibradas

Distribución de bases de datos activas en una situación hipotética de ejemplo durante errores de servidor

Situaciones hipotéticas de diseño

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

Diseños de copias de bases de datos desequilibradas

Para comprender el modo en que se deben distribuir las copias de bases de datos en un DAG, suponga que Contoso, Ltd planea diseñar un DAG para su solución de servidor Buzón de correo de alta disponibilidad. Contoso configura un DAG que se compone de:

• 4 servidores de buzones

• 20 bases de datos de buzones

• 2 copias de cada base de datos de buzones

Todos los servidores se implementan en un solo centro de datos, cada servidor tiene su almacenamiento exclusivo y cada servidor se implementa en su propio bastidor.

Contoso necesita que estén disponibles permanentemente dos copias de bases de datos de alta disponibilidad (por ejemplo, no atrasadas) y que la solución supere dos interrupciones simultáneas de miembros de DAG sin que ello afecte negativamente a la disponibilidad de las bases de datos.

Teniendo en cuenta estos requisitos, en la figura siguiente se muestra el diseño de las copias de bases de datos que se usa.

Diseño inicial de copias de bases de datos

En principio, el diseño parece correcto porque distribuye las copias activas de cada base de datos entre los cuatro miembros del DAG. Sin embargo, este diseño comporta problemas. No es óptimo en lo concerniente a los recursos de servidores. Por ejemplo, si se produce un error en uno solo de los servidores, tiene lugar una distribución desigual de las bases de datos, como se muestra en la figura siguiente.

Diseño de copias de bases de datos tras el error de un servidor

El error de Server4 hace que las bases de datos DB16 a DB20 se activen en Server1, en lugar de distribuirse entre los otros tres servidores. La consecuencia es una distribución desigual de bases de datos de buzones activadas, así como el uso desequilibrado de los recursos de servidores. Si se compara con los otros dos servidores (Server2 y Server3), Server1 se utiliza el doble.

Otro problema es que el DAG no dispone de copias suficientes para superar dos interrupciones simultáneas de servidores en todos los casos. Otro error en un servidor podría hacer que el 50 por ciento de las bases de datos no quedara disponible. Si se produce un error en Server1 y Server4, o de inmediato no quedan disponibles uno con respecto al otro, no estarían disponibles 10 bases de datos, como se ilustra en la figura siguiente.

Diseño de copias de bases de datos tras el error de dos servidores

Este diseño no se ajusta al requisito principal de poder superar el error en dos servidores. Para superar un error en dos servidores y mantener activas todas las bases de datos, se debe implementar una tercera copia y preparar un diseño nuevo.

Volver al principio

Preparación de un diseño de copias de bases de datos equilibradas

Un diseño de copias de bases de datos equilibradas podría requerir la revisión de varias decisiones de diseño para obtener un diseño óptimo. A la hora de diseñar copias de bases de datos, aplique los principios de diseño siguientes:

• Asegúrese de minimizar los errores en varias copias de bases de datos de una base de datos de buzones aislando cada copia y colocando cada una de ellas en errores de dominio diferentes. Por ejemplo, no coloque más de una sola copia de base de datos de una determinada base de datos de buzones en el mismo bastidor de servidores o en la misma matriz de almacenamiento.

• Disponga las copias de bases de datos de manera distribuida y coherente para asegurarse de que las bases de datos de buzones activas se distribuyan uniformemente después de un error. La suma de las preferencias de activación de cada copia de base de datos de cualquier servidor debe ser igual o casi igual. Esto permite una distribución prácticamente equitativa después del error, suponiendo que la replicación tenga un estado normal y esté actualizada.

Bloques de creación

Para ajustarse a los principios de diseño anteriores, se recomienda colocar la copias de bases de datos de manera que se asegure la distribución simétrica de todas las copias activas entre el mayor número posible de servidores. La organización de copias de bases datos tiene en cuenta el concepto del bloque de creación.

El primer bloque de creación (denominado bloque de creación de nivel 1) se basa en el número de servidores Buzón de correo que hospedarán copias de bases de datos activas. Suponga que este número es N. N define el número de servidores Buzón de correo y el número de bases de datos en el bloque de creación. Se distribuye una copia de base de datos activa en cada servidor, cosa que conforma un patrón en diagonal. Como en el ejemplo anterior, hay 4 servidores Buzón de correo y 20 bases de datos de buzones. El tamaño del primer bloque de creación de nivel 1 es 4, como se muestra en la figura siguiente.

Bloque de creación de nivel 1

El mismo patrón se repite en cada conjunto de bloques de creación de nivel 1. Como hay 20 bases de datos, hay cinco conjuntos de bloques de creación de nivel 1, como se muestra en la figura siguiente.

Cinco bloques de creación de nivel 1 para 20 bases de datos

Al agregar una segunda copia de base de datos, colóquela de manera diferente en cada conjunto de bloques de creación. Como un servidor ya hospeda la copia activa, hay N – 1 servidores disponibles para hospedar la segunda copia de base de datos. A medida que usa cada uno de estos N – 1 servidores una vez, tiene una distribución simétrica completa que conforma el nuevo bloque de creación más grande. Por lo tanto, el tamaño del nuevo bloque de creación (bloque de creación de nivel 2) es de N × (N – 1) bases de datos. Eso significa que la segunda copia de base de datos de la primera base de datos se coloca en el segundo servidor; por lo tanto, cada segunda copia se implementa en un patrón en diagonal en el bloque de creación. Después de completar el patrón en el primer conjunto de bloques de creación de nivel 1, la posición inicial de la segunda copia del bloque siguiente se desplaza un lugar, de forma que la segunda copia comienza en el tercer servidor.

En el ejemplo, el tamaño del bloque de creación es 4× (4 – 1) = 4× 3 = 12; eso significa que 12 bases de datos componen cada conjunto de bloques de creación de nivel 2. En cuanto al conjunto de bloques de creación de nivel 1 (de DB1 a DB4), la segunda copia de DB1 se coloca en Server2; en lo concerniente al segundo conjunto de bloques de creación de nivel 1 (de DB5 a DB8), la segunda copia de DB5 se coloca en Server3. La colocación del servidor de inicio de cada conjunto de bloques de creación de nivel 1 se desplaza un servidor respecto al conjunto anterior de bloques de creación de nivel 1. Este diseño continúa con la colocación de la segunda copia de DB9 en Server4. De este modo, se asegura que un error en Server1 active las segundas copias en los otros tres servidores, en lugar de activar varias bases de datos en el mismo servidor.

Bloque de creación de nivel 2 con tres bloques de creación de nivel 1

El mismo patrón se repite en todos los demás segundos conjuntos de bloques de creación. Como hay 20 bases de datos, en este ejemplo hay dos conjuntos de bloques de creación de nivel 2. Observe que la segunda copia de DB13 se coloca en Server2.

Bloque de creación de nivel 2 con los otros dos bloques de creación de nivel 1

Para comprender mejor esta lógica, compare la colocación de copias de bases de datos de DB1, DB5 y DB9. Cada una de estas bases de datos tiene una copia activa hospedada en Server1. Si se produce un error en Server1, dispone de segundas copias de bases de datos activadas en otros servidores para tener una distribución equilibrada de la carga. Esto es posible colocando una segunda copia de base de datos de DB1 en Server2, una segunda copia de base de datos de DB5 en Server3 y una segunda copia de base de datos de DB9 en Server4. A partir de DB13, lo único que debe hacer es repetir el patrón. Las demás copias de bases de datos se agregan en un patrón en diagonal, como se muestra en la figura siguiente.

Colocación de la copia de base de datos para la distribución equitativa

Observe que el segundo bloque de creación (de DB13 a DB20) contiene solamente ocho bases de datos, no 12. Por lo tanto, este diseño no será simétrico del todo si se produce un solo error. Para brindar una distribución completamente simétrica, planee la arquitectura de modo que el número de bases de datos sea múltiplo del tamaño de bloque de creación más grande. (En este ejemplo, los números óptimos son 24, 36, 48 o 60 bases de datos, y así sucesivamente.)

Al agregar una tercera copia de base de datos, de nuevo la debe colocar de forma distinta en cada grupo de ahora N × (N – 1) bases de datos. Como ya dispone solamente de N – 2 servidores en los que poder seleccionar para la colocación de la tercera copia de base de datos, se generan N – 2 variaciones. El nuevo bloque de creación (bloque de creación de nivel 3) es de N × (N – 1) × (N – 2) bases de datos. Así pues, la tercera copia de base de datos de la primera base de datos se coloca en el tercer servidor; por lo tanto, cada tercera copia se implementa en un patrón en diagonal según la posición inicial en este nuevo bloque de creación. Después de completar el patrón en el primer conjunto de bloques de creación de nivel 1, la posición inicial se desplaza un lugar, de forma que la tercera copia se coloca en la cuarta posición.

En este ejemplo, el tamaño del bloque de creación es 4 × (4 – 1) × (4 – 2) = 4 × 3 × 2 = 24; eso significa que 24 bases de datos componen cada conjunto de bloques de creación de nivel 3. Para producir el patrón de colocación simétrica de bases de datos, coloque la tercera copia de base de datos de DB1 en Server3 (que es el primer servidor disponible porque Server1 hospeda la primera copia y Server2 hospeda la segunda copia); a continuación, desplace cada copia adicional una posición hasta llegar al final del primer conjunto de bloques de creación de nivel 1. En el siguiente bloque de creación, coloque la tercera copia de base de datos en el siguiente servidor disponible (Server4) y continúe del mismo modo hasta DB12, que marca el final del primer conjunto de bloques de creación de nivel 2. De DB13 a DB20, siga el mismo patrón pero desplace un lugar la colocación de la tercera copia de base de datos para que no finalice en los mismos servidores que de DB1 a DB12.

Diseño equilibrado con tres copias de bases de datos y cuatro servidores

Una vez más, para comprender mejor esta lógica, compare la colocación de copias de bases de datos de DB1 a DB13. Estas bases de datos hospedan la copia de base de datos activa en Server1 y la segunda copia, en Server2. Si se produce un error en estos servidores, dispone de terceras copias de bases de datos activadas en otros servidores para tener una distribución equilibrada de la carga. Esto se consigue colocando la tercera copia de base de datos de DB1 en Server3 y la tercera copia de base de datos de DB13 en Server4. Se forman pares similares con DB2 y DB14, DB3 y DB15, y así sucesivamente. A partir de DB25, solamente se debe repetir el patrón (este ejemplo no abarca tantas bases de datos).

Observe que el tercer bloque de creación (de DB1 a DB20) contiene únicamente 20 bases de datos, no 24. Como consecuencia, este diseño no será totalmente simétrico en caso de errores dobles. Como ya se ha dicho, para brindar una distribución completamente simétrica, planee la arquitectura de modo que el número de bases de datos sea múltiplo del tamaño de bloque de creación más grande. (En este ejemplo, los números óptimos son 24, 48, o 72 bases de datos, y así sucesivamente.)

Al agregar una cuarta copia de base de datos, de nuevo la debe colocar de forma distinta en cada grupo de ahora N × (N – 1) × (N – 2) bases de datos. El nuevo bloque de creación es de N × (N – 1) × (N – 2) × (N – 3) bases de datos. Se sigue el mismo planteamiento lógico y se asegura una distribución uniforme de las bases de datos en el nuevo bloque de creación en caso de error en tres servidores.

El ejemplo de cuatro servidores permite solamente una variación para colocar la cuarta copia de base de datos (queda disponible un único servidor). Por lo tanto, el tamaño del bloque de creación se queda en 24. Esto resulta evidente también al usar la fórmula para el tamaño del bloque de creación: 4 × 3 × 2 × (4 – 3) = 4 × 3 × 2 × 1 = 24.

Al ir agregando copias de bases de datos, el bloque de creación sigue creciendo de forma que la fórmula general del tamaño del bloque de creación es Perm(N,M) = N × (N – 1) … (N – M + 1) = N!/(N – M)! = CNMM!, donde N = número de servidores y M = número de copias de bases de datos. Es algo que resulta obvio al observar que se obtiene la distribución simétrica completa de las copias de bases de datos seleccionando todas las permutaciones posibles de M copias de bases de datos en N servidores disponibles.

Al usar esta metodología deben tenerse en cuenta algunas consideraciones:

• Implementar un número de bases de datos que no sea múltiplo del tamaño de bloque de creación más grande genera una distribución asimétrica de bases de datos activas cuando se producen errores.

• La implementación de arquitecturas para mitigar varios dominios de errores puede comportar la distribución asimétrica de bases de datos activas cuando se producen errores. Eso se debe a que las definiciones de dominios de errores imponen restricciones en la colocación de copias de bases de datos, cosa que desequilibra la simetría del patrón.

• Implementar soluciones resistentes para sitios que den como resultado bases de datos fuera del sitio puede generar una distribución asimétrica de bases de datos durante los errores de servidores de centros de datos principales.

Volver al principio

Distribución de bases de datos activas en una situación hipotética de ejemplo durante errores de servidor

Siguiendo el ejemplo anterior, en el caso de error de un servidor, por ejemplo Server4, las bases de datos de buzones activas se distribuyen como se muestra en la figura siguiente. La segunda copia se activa para DB4, DB8, DB12, DB16 y DB20, marcadas como Active de color naranja.

Distribución de copias de bases de datos activas tras el error de un servidor

Si se produce un error en dos servidores (la tercera copia se activa en varias bases de datos, indicado como Active de color verde), los otros dos servidores, Server1 y Server3, tendrán el mismo número de bases de datos de buzones activadas.

Distribución de copias de bases de datos activas tras un error en dos servidores

Sin embargo, como el número de bases de datos de este ejemplo no es múltiplo del bloque de creación de tamaño más grande (24 bases de datos), no todos los errores en dos servidores generarán una distribución simétrica.

Distribución de copias de bases de datos activas tras un error diferente en dos servidores

Volver al principio

Situaciones hipotéticas de diseño

Para comprender el principio de diseño del diseño de copias de bases de datos y la fórmula matemática asociada, se recomienda tener en cuenta otros dos diseños de arquitectura.

Situación hipotética de diseño: Solución resistente para sitios de distribución de usuario activo/activo

En esta situación, Contoso decide implementar la arquitectura siguiente:

• El DAG se extiende en dos centros de datos que operan en un modelo de distribución de usuario activo/activo.

• Cada servidor se implementa en un bastidor de servidores diferente.

• Cada almacenamiento del servidor se aísla del almacenamiento de otros servidores del centro de datos.

• Hay cuatro servidores Buzón de correos por centro de datos.

• Hay un total de 24 bases de datos de buzones.

• La finalidad es tener cuatro copias de bases de datos altamente disponibles y superar un error de dos servidores o un error en un centro de datos.

En este ejemplo, el bloque de creación de nivel 1 es 4, las bases de datos se agrupan en unidades de cuatro y las copias activas se distribuyen en los cuatro servidores del bloque de creación.

Distribución uniforme de la primera copia en un bloque de creación

En cada servidor que hospeda copias activas, la segunda copia de base de datos se distribuye lo más uniformemente posible en todos los demás servidores siguiendo un patrón en diagonal porque cada copia se aísla con respecto a las demás. En este ejemplo, el bloque de creación de nivel 2 se convierte en 12, que constituye el conjunto de repetición cada 12 bases de datos.

Distribución uniforme de una segunda copia en un bloque de creación

Como esta solución de resistencia de sitios es para un modelo de distribución de usuario activo/pasivo con un número igual de servidores y copias de bases de datos en los dos centros de datos, la tercera copia de base de datos se coloca en un patrón en diagonal en Server5 y Server6 utilizando el valor 4 del bloque de creación de nivel 1. De este modo, se asegura que Server5 y Server6 reflejen la primera colocación de copias de bases de datos de Server1 a Server4.

Distribución uniforme de una tercera copia en el segundo bloque de creación

Como esta solución de resistencia de sitios es para un modelo de distribución de usuario activo/pasivo con un número igual de servidores y copias de bases de datos en los dos centros de datos, la cuarta copia de base de datos se coloca en un patrón en diagonal en Server5 y Server6 utilizando el valor 12 del bloque de creación de nivel 2. De este modo, se asegura que Server5 y Server6 reflejen la segunda colocación de copias de bases de datos de Server1 a Server4.

Distribución uniforme de una cuarta copia en el segundo bloque de creación

Si se produce un error en un servidor, los otros tres servidores del centro de datos principal tendrán un número igual de bases de datos de buzones activadas (ocho por servidor).

Distribución de copias de bases de datos activas tras el error de un servidor

Si se produce un error en dos servidores a la vez, los otros tres servidores del centro de datos principal tendrán un número igual de bases de datos de buzones activadas (10 por servidor), mientras que cuatro bases de datos se activarán en el centro de datos secundario.

Distribución de copias de bases de datos activas tras el error de dos servidores

Situación hipotética de diseño: Varios dominios de errores

En este ejemplo, Wingtip Toys decide implementar la arquitectura siguiente:

• Todos los servidores se implementan en un solo centro de datos.

• Los servidores se agrupan en unidades de tres.

• Cada uno de los tres servidores se coloca en el mismo bastidor con su almacenamiento.

• Hay un total de tres bastidores y nueve buzones.

• Hay un total de 18 bases de datos de buzones.

• La finalidad es tener tres copias de bases de datos altamente disponibles y superar un error de dos servidores o un error en un bastidor.

En este ejemplo, el bloque de creación de nivel 1 es 6, las bases de datos se agrupan en unidades de seis y las copias activas se distribuyen en los seis servidores del bloque de creación.

Diseño de la copia de base de datos para el bloque de creación de nivel 1

En cada servidor que hospeda copias activas, la segunda copia de base de datos se distribuye lo más uniformemente posible en todos los demás servidores y, al mismo tiempo, se asegura de que dos copias de la misma base de datos no se coloquen en el mismo bastidor de servidores. En este ejemplo, en lugar de la fórmula del bloque de creación de nivel 2 de N × (N – 1), se usa la fórmula de N × (N – 2) para asegurarse de que dos copias de la misma base de datos no se coloquen en el mismo bastidor. Eso significa que el bloque de creación del nivel 2 es 6 × 4 = 24.

Diseño de copias de bases de datos para las primeras y las segundas copias

La tercera copia de base de datos se coloca en un patrón en diagonal en los servidores, una vez más asegurándose de que varias copias de la misma base de datos no se coloquen en el mismo bastidor de servidores. En este ejemplo, en lugar de la fórmula del bloque de creación de nivel 3 de N × (N – 2), se usa la fórmula de N × (N – 2) × (N – 4) para asegurarse de que dos copias de la misma base de datos no se coloquen en el mismo bastidor. Eso significa que el bloque de creación del nivel 3 es 6 × 4 × 2 = 48.

Diseño de copias de bases de datos para las primeras, las segundas y las terceras copias

Si se produce un error en un servidor, los otros cinco servidores del centro de datos principal tendrán un número casi igual de bases de datos de buzones activadas. Cuatro servidores tendrán 10 bases de datos activadas por servidor y un servidor (el asociado del bastidor) tendrá ocho bases de datos activadas.

Diseño y recuento de bases de datos activas tras el error de un servidor

Si se produce un error en dos servidores a la vez (bastidores diferentes), los otros cuatro servidores tendrán un número casi igual de bases de datos de buzones activadas.

Diseño y recuento de bases de datos activas tras el error de dos servidores (bastidores diferentes)

Si se produce un error en dos servidores a la vez (mismo bastidor), los otros cuatro servidores tendrán un número igual de bases de datos de buzones activadas.

Diseño y recuento de bases de datos activas tras el error de dos servidores (mismo bastidor)

Volver al principio

 © 2010 Microsoft Corporation. Reservados todos los derechos.