Al implementar la réplica multimaestro, debe tener en cuenta aspectos del diseño como los siguientes: arbitraje, enlace y rendimiento.
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.
Topología | ¿Arbitraje de aplicación? | Notas |
---|---|---|
Una línea de dos dominios de servicio de catálogo | Sí | Elija un dominio de servicio de catálogo como árbitro. |
Una línea de tres dominios de servicio de catálogo | Sí | 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 | Sí | 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) | Sí | Todos los nodos raíz deben evaluar solo sus descendientes directos. |
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 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:
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.
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.
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.
A <=> B <=> C <=> D <=> E
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.
Tenga en cuenta las limitaciones siguientes cuando utilice topologías de réplica multimaestro:
Recuerde que los sockets TCP utilizan un mecanismo de ventana deslizando para controlar el flujo de datos masivo. Este mecanismo normalmente limita el socket a 64 KB para un intervalo de viaje de ida y vuelta. Si el intervalo de viaje de ida y vuelta es 100 ms, el ancho de banda se limita a 640 KB/segundo sin ajuste adicional. El uso de todo el ancho de banda disponible en un enlace podría requerir un ajuste específico de un sistema operativo. La mayoría de sistemas operativos incluyen parámetros de ajuste, incluidas las opciones de RFC 1323, para ampliar el rendimiento sobre los enlaces de latencia alta.
La réplica multimaestro añade una cantidad fija de proceso por entrada Map para manejar el mantenimiento de versiones. Cada contenedor también realiza un seguimiento de una cantidad fija de datos para cada dominio de servicio de catálogo de la topología. Una topología con dos dominios de servicio de catálogo utiliza aproximadamente la misma memoria que una topología con 50 dominios de servicio de catálogo. WebSphere eXtreme Scale no utiliza registros de reproducción o colas similares en su implementación. Por lo tanto, no hay ninguna estructura de recuperación lista en el caso de que un enlace de réplica no esté disponible durante el periodo de tiempo considerable y se reinicie posteriormente.