Consideraciones sobre el diseño para la réplica multimaestro

Al implementar la réplica multimaestro, debe tener en cuenta aspectos del diseño como los siguientes: arbitraje, enlace y rendimiento.

Consideraciones sobre arbitraje en el diseño de topología

Se podrían producir colisiones de cambio si se pueden cambiar en dos lugares a la vez los mismos registros. Configure cada uno de los dominios de servicio de catálogo para que tenga aproximadamente la misma cantidad de recursos de procesador, memoria y red. Podría observar que los dominios de servicio de catálogo que realicen el manejo de colisiones de cambio (arbitraje) utilicen más recursos que otros dominios de servicio de catálogo. Las colisiones se detectan automáticamente. Se manejan con uno de dos mecanismos:
  • Árbitro de colisión predeterminado: el protocolo predeterminado utilizará los cambios del dominio de servicio de catálogo con el nombre léxicamente inferior. Por ejemplo, si los dominios de servicio de catálogo A y B generan un conflicto para un registro, el cambio del dominio de servicio de catálogo B se ignorará. El dominio de servicio de catálogo A mantiene su versión y el registro en el dominio de servicio de catálogo B se cambia para que coincida con el registro del dominio de servicio de catálogo A. Este comportamiento se aplica también a las aplicaciones en las que los usuarios o sesiones normalmente se enlazan o tienen una afinidad con una de las cuadrículas siguientes.
  • Árbitro de colisiones personalizado: las aplicaciones pueden proporcionar un árbitro personalizado. Cuando un dominio de servicio de catálogo detecta una colisión, se inicia un árbitro. Para obtener información sobre cómo desarrollar un árbitro personalizado útil, consulte Desarrollo de árbitros personalizados para la réplica con varios maestros.
Para topologías en las que las colisiones son posibles, considere implementar una topología de hub y radio o una topología de árbol. Estas dos topologías son propicias para evitar colisiones constantes, lo que puede suceder en los escenarios siguientes:
  1. Varios dominios de servicio de catálogo sufren una colisión
  2. Cada dominio de servicio de catálogo maneja la colisión localmente, lo que genera revisiones
  3. Las revisiones colisionan, con lo que se producen revisiones de revisiones

Para evitar colisiones, elija un dominio de servicio de catálogo específico, denominado un dominio de servicio de catálogo de arbitraje como el árbitro de colisión para un subconjunto de dominios de servicio de catálogo. Por ejemplo, una topología de hub y radio podría utiliza el hub como el manejador de colisiones. El manejador de colisiones de radio ignora las colisiones detectadas por los dominios de servicio de catálogo de radio. El dominio de servicio de catálogo de hub crea revisiones, lo que evita revisiones de colisiones inesperadas. El dominio de servicio de catálogo que se asigna para manejar colisiones debe enlazar a todos los dominios para los que es responsable para manejar colisiones. En una topología de árbol, los dominios padre internos manejan colisiones para sus hijos inmediatos. Por el contrario, si utiliza una topología en anillo, no puede designar un dominio de servicio de catálogo en el anillo como el árbitro.

En la tabla siguiente se resumen los enfoques de arbitraje que son más compatibles con distintas topologías.
Tabla 1. Enfoques de arbitraje. En esta tabla se indica si el arbitraje de la aplicación es compatible con distintas tecnologías.
Topología ¿Arbitraje de aplicación? Notas
Una línea de dos dominios de servicio de catálogo Elija un dominio de servicio de catálogo como árbitro.
Una línea de tres dominios de servicio de catálogo El dominio de servicio de catálogo intermedio debe ser el árbitro. Considere el dominio de servicio de catálogo intermedio como hub en una topología de hub y radio simple.
Una línea de más de tres dominios de servicio de catálogo No No se admite el arbitraje de aplicaciones.
Un hub con N radios El hub con enlaces a todos los radios debe ser el dominio de servicio de catálogo de arbitraje.
Un anillo de N dominios de servicio de catálogo No No se admite el arbitraje de aplicaciones.
Un árbol dirigido acíclico (árbol n-ario) Todos los nodos raíz deben evaluar solo sus descendientes directos.

Consideraciones sobre enlaces en el diseño de topología

De forma ideal, una topología incluye el número mínimo de enlaces cuando optimiza los compromisos entre las características de latencia de cambios, tolerancia a errores y rendimiento.
  • Latencia de cambios

    La latencia de cambios la determina el número de dominios de servicio de catálogo intermedio por los que debe pasar un cambio antes de llegar a un dominio de servicio de catálogo específico.

    Una topología tiene la mejor latencia de cambios cuando elimina dominios de servicio de catálogo intermedios enlazando cada dominio de servicio de catálogo a cada uno de los otros dominios de servicio de catálogo. Sin embargo, un dominio de servicio de catálogo debe realizar trabajo de réplica en proporción a su número de enlaces. Para topologías grandes, el gran número de enlaces que se definirán puede causar carga administrativa.

    La velocidad a la que se copia un cambio en otros dominios de servicio de catálogo depende de factores adicionales, como por ejemplo:
    • Procesador y ancho de banda de red en el dominio de servicio de catálogo de origen
    • Número de dominios de servicio de catálogo intermedios y enlaces entre los dominios de servicio de catálogo de origen y de destino
    • Recursos de procesador y de red disponibles a los dominios de servicio de catálogo de origen, de destino e intermedio
  • Tolerancia al error

    La tolerancia a errores la determina el número de vías de acceso existentes entre los dos dominios de servicio de catálogo para la réplica de cambios.

    Si solo tiene un enlace entre un par determinado de dominios de servicio de catálogo, una anomalía de enlace no permite la propagación de cambios. De forma similar, los cambios no se propagan entre los dominios de servicio de catálogo si alguno de los dominios intermedios experimenta anomalía de enlace. La topología podría tener un único enlace desde un dominio de servicio de catálogo a otro de tal forma que el enlace pase por dominios intermedios. Si es así, los cambios no se propagarán si alguno de los dominios de servicio de catálogo intermedios está inactivo.

    Considere la topología de línea con cuatro dominios de servicio de catálogo A, B, C, y D:

    Topología de línea

    Si se mantiene alguna de estas condiciones, el Dominio D no verá los cambios de A:
    • El dominio A está activo y el dominio B está inactivo
    • Los dominios A y B están activos y el dominio C está inactivo
    • El enlace entre A y B está inactivo
    • El enlace entre B y C está inactivo
    • El enlace entre C y D está inactivo
    En cambio, con una topología de anillo, cada uno de los dominios de servicio de catálogo puede recibir cambios desde cualquier dirección.

    Topología de anillo

    Por ejemplo, si un servicio de catálogo determinado de la topología de anillo está inactivo, los dos dominios adyacentes aún pueden obtener cambios directamente uno del otro.

    Todos los cambios se propagan mediante el hub. Por lo tanto, a diferencia de las topologías de línea y de anillo, el diseño de hub y radio puede desglosarse, si el hub falla.

    Topología de hub y radio

    Un único dominio de servicio de topología es resistente a una determinada cantidad de pérdida de servicio. Sin embargo, anomalías mayores como interrupciones de la red amplia o la pérdida de enlaces entre centros de datos físicos puede interrumpir cualquiera de los dominios de servicio de catálogo.

  • Enlace y rendimiento

    El número de enlaces definidos en un dominio de servicio de catálogo afecta al rendimiento. Más enlaces utilizan más recursos y como resultado el rendimiento de la réplica puede disminuir. La posibilidad de recuperar cambios para un dominio A mediante otros dominios libera de forma efectiva al dominio A de tener que replicar las transacciones en todas partes. La carga de distribución de cambios de un dominio está limitada por el número de enlaces que utiliza, no por cuántos dominios haya en la topología. Esta propiedad de carga proporciona escalabilidad, de forma que los dominios de la topología pueden compartir la carga de la distribución de cambios.

    Un dominio de servicio de catálogo puede recuperar los cambios indirectamente mediante otros dominios de servicio de catálogo. Considere una topología de línea con cinco dominios de servicio de catálogo.
    A <=> B <=> C <=> D <=> E
    • A extrae los cambios de B, C, D y E a B
    • B extrae los cambios de A y C directamente y los cambios de D y E a C
    • C realiza los cambios de B y D directamente y los cambios de A a B y de E a D
    • D extrae los cambios de C y E directamente y los cambios de A y B a C
    • E extrae los cambios de D directamente, y los cambios de A, B y C a D

    La carga de distribución de los dominios de servicio de catálogo A y E es la menor, ya que cada uno de ellos tiene un enlace a un único dominio de servicio de catálogo. Cada uno de los dominios B, C y D tiene un enlace a dos dominios. Por lo tanto, la carga de distribución de los dominios B, C y D es el doble de la carga de los dominios A y E. La carga de trabajo depende del número de enlaces de cada dominio, no del número global de dominios de la topología. Por lo tanto, la distribución de cargas descrita permanecería constante, incluso si la línea contuviera 1000 dominios.

Consideraciones sobre el rendimiento de réplica multimaestros

Tenga en cuenta las limitaciones siguientes cuando utilice topologías de réplica multimaestro: