Comunicación de varios clústeres

La red debe configurarse de tal manera que cualquier silo de Orleans pueda conectarse a cualquier otro silo de Orleans a través de TCP/IP, con independencia del lugar del mundo en que se encuentre. La manera exacta de lograr esto es fuera del ámbito de Orleans, ya que depende de cómo y dónde se implementan los silos.

Por ejemplo, en Microsoft Azure, podemos usar redes virtuales para conectar varias implementaciones dentro de una región y puertas de enlace para conectar redes virtuales entre distintas regiones.

Identificador de clúster

Cada clúster tiene su propio identificador de clúster único. El identificador de clúster debe especificarse en la configuración global.

Es posible que los identificadores de clúster no estén vacíos ni que contengan comas. Además, si usa Azure Table Storage, es posible que los identificadores de clúster no contengan los caracteres prohibidos para las claves de fila (/, , #, ?).

Se recomienda usar cadenas muy cortas para los identificadores de clúster, ya que se transmiten con frecuencia y algunos proveedores de vistas de registro pueden guardarlos en el almacenamiento.

Puertas de enlace de clúster

Cada clúster designa automáticamente un subconjunto de sus silos activos para que actúen como puertas de enlace de clúster. Las puertas de enlace de clúster anuncian directamente sus direcciones IP a otros clústeres y, por tanto, pueden servir como "puntos de primer contacto". De forma predeterminada, como máximo 10 silos (o cualquier número configurado como MaxMultiClusterGateways) se designan como puertas de enlace de clúster.

La comunicación entre silos en diferentes clústeres no siempre pasa a través de una puerta de enlace. Una vez que un silo ha aprendido y almacenado en caché la ubicación de una activación específica (independientemente del clúster), envía mensajes a ese silo directamente, incluso si el silo no es una puerta de enlace de clúster.

Gossip

El cuchicheo es un mecanismo para que los clústeres compartan información de configuración y estado. Como sugiere el nombre, el cuchicheo está descentralizado y es bidireccional: cada silo se comunica directamente con otros silos, tanto en el mismo clúster como en otros clústeres, para intercambiar información en ambas direcciones.

Content. El cuchicheo contiene alguna o toda la información siguiente:

• La configuración de varios clústeres con la marca de tiempo actual.
• Un diccionario que contiene información sobre las puertas de enlace de clúster. La clave es la dirección del silo y el valor contiene (1) una marca de tiempo, (2) el identificador del clúster y (3) un estado, que está activo o inactivo.

Propagación lenta y rápida. Cuando una puerta de enlace cambia su estado o cuando un operador inserta una nueva configuración, esta información de cuchicheo se envía inmediatamente a todos los canales de silos, clústeres y cuchicheos. Esta acción tiene lugar rápidamente, pero no es confiable. Si el mensaje se pierde por cualquier motivo (por ejemplo, carreras, sockets rotos, errores de silo), nuestro cuchicheo de fondo periódico garantiza que la información finalmente se distribuya, aunque más lentamente. Toda la información se propaga finalmente en todas partes y es muy resistente a errores y pérdida ocasional de mensajes.

Todos los datos de cuchicheo tienen una marca de tiempo, lo que garantiza que la información más reciente reemplace a la información anterior independientemente del tiempo relativo de los mensajes. Por ejemplo, las configuraciones de varios clústeres más recientes reemplazan a las más antiguas y la información más reciente sobre una puerta de enlace reemplaza la información anterior sobre esa puerta de enlace. Para más información sobre la representación de datos de cuchicheo, consulte la clase MultiClusterData. Dicha clase tiene un método Merge que combina datos de cuchicheos y resuelve conflictos mediante marcas de tiempo.

Canales de cuchicheo

Cuando se inicia por primera vez un silo o cuando se reinicia después de un error, debe tener una manera de arrancar el cuchicheo. Esta es la función del canal de cuchicheo, que se puede configurar en la configuración del silo. Al inicio, un silo captura toda la información de los canales de cuchicheo. Después del inicio, un silo mantiene los cuchicheos periódicamente, cada 30 segundos o lo que esté configurado como BackgroundGossipInterval. Cada vez, se sincroniza su información de cuchicheo con un asociado seleccionado aleatoriamente entre todas las puertas de enlace de clúster y canales de cuchicheo.

• Aunque no es estrictamente necesario, se recomienda configurar siempre al menos dos canales de cuchicheo, en regiones distintas, para mejorar la disponibilidad.
• La latencia de la comunicación con canales de cuchicheo no es fundamental.
• Varios servicios diferentes pueden usar el mismo canal de cuchicheo sin interferencias, siempre y cuando el Guid de ServiceId (según lo especificado por su configuración respectiva) sea distinto.
• No hay ningún requisito estricto de que todos los silos usen los mismos canales de cuchicheo, siempre y cuando los canales sean suficientes para permitir que un silo se conecte inicialmente con la "comunidad de cuchicheo" cuando se inicia. Pero si un canal de cuchicheo no forma parte de la configuración de un silo y ese silo es una puerta de enlace, no se insertan sus actualizaciones de estado en el canal (propagación rápida), por lo que puede pasar más tiempo antes de que lleguen al canal a través de cuchicheos de fondo periódicos (propagación lenta).

Canal de cuchicheo basado en tablas de Azure

Ya hemos implementado un canal de cuchicheo basado en tablas de Azure. La configuración especifica las cadenas de conexión estándar que se usan para las cuentas de Azure. Por ejemplo, una configuración podría especificar dos canales de cuchicheo con cuentas de almacenamiento de Azure distintas, europe y usa, como se indica a continuación:

var silo = new HostBuilder()
    .UseOrleans(builder =>
    {
        builder.Configure<MultiClusterOptions>(options =>
        {
            options.GossipChannels.Add(
                "AzureTable",
                "DefaultEndpointsProtocol=https;AccountName=usa;AccountKey=...");
            options.GossipChannels.Add(
                "AzureTable",
                "DefaultEndpointsProtocol=https;AccountName=europe;AccountKey=...")
        });
    })

Varios servicios diferentes pueden usar el mismo canal de cuchicheo sin interferencias, siempre y cuando el Guid de ServiceId especificado por su configuración respectiva sea distinto.