Configuración de varios clústeres

La configuración de varios clústeres determina qué clústeres forman parte actualmente del grupo. No cambia automáticamente, pero está controlada por el operador. Por lo tanto, es muy diferente del mecanismo de pertenencia que se usa en un clúster, que determina automáticamente el conjunto de silos que forman parte del clúster.

Usamos la siguiente terminología para los clústeres de un servicio:

• Un clúster está activo si tiene al menos un silo activo. De lo contrario, está inactivo.
• Un clúster está unido si forma parte de una configuración actual de varios clústeres. De lo contrario, está no unido.

Estar activo o inactivo es independiente de estar unido o no unido: las cuatro combinaciones son posibles.

Todos los clústeres de un servicio determinado están conectados por una red de cuchicheos (“gossip network”). La red de cuchicheos propaga la información de configuración y estado.

Inserción de una configuración

Un operador emite cambios de configuración insertándolos en la red del grupo de varios clústeres. Las configuraciones se pueden insertar en cualquier clúster y distribuirse desde ahí a todos los clústeres activos. Cada nueva configuración consta de una lista de identificadores de clústeres, que sirven para iniciar el grupo de varios clústeres. También tiene una marca de tiempo UTC, que se usa para realizar un seguimiento de su propagación a través de la red de cuchicheos.

Inicialmente, la configuración de varios clústeres tiene un valor null, lo que significa que la lista de varios clústeres está vacía (no contiene ningún clúster). Por lo tanto, el operador debe insertar inicialmente una configuración de varios clústeres. Una vez insertada, esta configuración persiste en todos los silos conectados (mientras se ejecuta) y en todos los canales de cuchicheos especificados (si esos canales son persistentes).

Hay algunas restricciones que el operador debe seguir respecto a la inserción de nuevas configuraciones:

• Cada nueva configuración puede añadir varios clústeres o quitarlos, pero no las dos acciones al mismo tiempo.
• Un operador no debe emitir una nueva configuración mientras se sigue procesando un cambio de configuración anterior.

Estas restricciones garantizan que protocolos como el de instancia única puedan mantener correctamente la exclusión mutua de las activaciones incluso en los cambios de configuración.

Grano de administración

Las configuraciones de varios clústeres se pueden insertar en cualquier nodo de cualquier clúster mediante el grano de administración de Orleans. Por ejemplo, para insertar una configuración de varios clústeres que consta de los tres clústeres { us1, eu1, us2 }, podemos pasar una cadena enumerable al grano de administración:

var clusters = "us1,eu1,us2".Split(',');
var mgtGrain = client.GetGrain<IManagementGrain>(0);
mgtGrain.InjectMultiClusterConfiguration(clusters, "my comment here"));

El primer argumento de InjectMultiClusterConfiguration(IEnumerable<String>, String, Boolean) es una colección de identificadores de clústeres, que van a definir la nueva configuración del grupo de varios clústeres. El segundo argumento es una cadena de comentario (opcional) que se puede usar para etiquetar configuraciones con información arbitraria, como quién las insertó y por qué.

Hay un tercer argumento opcional, un booleano denominado checkForLaggingSilosFirst, que tiene “true” como valor predeterminado. Esto significa que el sistema realiza una comprobación de mejor esfuerzo para ver si hay algún silo en alguna parte al que no se le haya aplicado todavía la configuración actual, y rechaza el cambio si encuentra un silo en ese estado. Esto ayuda a detectar infracciones de la restricción de que solo se permite un cambio de configuración cada vez (aunque no puede garantizar que esto se cumpla en todas las circunstancias).

Configuración predeterminada

En situaciones en las que la configuración de varios clústeres se conoce de antemano y la implementación es nueva cada vez (para las pruebas), es posible que queramos proporcionar una configuración predeterminada. La configuración global admite un atributo DefaultMultiCluster opcional, que toma una lista, separada por comas, de identificadores de clústeres:

var silo = new HostBuilder()
    .UseOrleans(builder =>
    {
        builder.Configure<MultiClusterOptions>(options =>
        {
            options.DefaultMultiCluster = new[] { "us1", "eu1", "us2" };
        })
    })
    .Build();

Después de iniciar un silo con esta configuración, comprueba si la configuración actual de varios clústeres es null y, si es así, inserta la configuración especificada con la marca de tiempo UTC actual.

Advertencia

Los canales persistentes de cuchicheos de varios clústeres (basados en AzureTable) conservan la última configuración insertada a menos que se eliminen explícitamente. En ese caso, especificar un elemento DefaultMultiCluster no tiene ningún efecto al volver a implementar un clúster porque la configuración almacenada en los canales de cuchicheos no es null.>

Canal de cuchicheos

Un operador también puede insertar la configuración directamente en el canal de cuchicheos. Los cuchicheos periódicos que hay en segundo plano seleccionan y propagan automáticamente los cambios en el canal, aunque es posible que lo hagan muy lentamente (el grano de administración es mucho más rápido). Una estimación aproximada del tiempo de propagación es de 30 segundos (o cualquier intervalo de cuchicheos especificado en la configuración global) multiplicados por el logaritmo binario del número total de silos en todos los clústeres. Pero dado que los pares de cuchicheos se seleccionan aleatoriamente, pueden ser mucho más rápidos o mucho más lentos.

Si usa el canal de cuchicheos basado en tablas de Azure, los operadores pueden insertar una nueva configuración simplemente editando el registro de configuración en OrleansGossipTable, mediante alguna herramienta para editar datos en tablas de Azure. El propio registro de configuración presenta el siguiente formato:

Nombre	Tipo	Value
PartitionKey	String	el Id. de servicio (ServiceId)
RowKey	String	"CONFIG"
Clústeres	String	lista separada por comas de identificadores de clústeres, por ejemplo, "us1,eu1,us2"
Comentario	String	comentario opcional
GossipTimestamp	DateTime	Marca de tiempo UTC para la configuración

Nota

Al editar este registro en el almacenamiento, GossipTimestamp también debe establecerse en un valor más reciente que el que tiene actualmente (de lo contrario, se omite el cambio). La manera más cómoda y recomendada de hacerlo es eliminando el GossipTimestamp campo: nuestra implementación del canal de cuchicheos lo reemplaza automáticamente por una marca de tiempo actual y correcta (utiliza la marca de tiempo de tabla de Azure).

Procedimientos para los clústeres

A menudo, la adición o eliminación de un clúster del grupo de varios clústeres debe coordinarse dentro de un contexto más grande. Se recomienda seguir siempre los procedimientos descritos a continuación al añadir o quitar clústeres del grupo.

Procedimiento para añadir un clúster

1. Inicie un clúster de Orleans nuevo y espere hasta que todos los silos estén en funcionamiento.
2. Inserte una configuración que contenga el nuevo clúster.
3. Inicie el enrutamiento de solicitudes de usuario al nuevo clúster.

Procedimiento para quitar un clúster

1. Detenga el enrutamiento de nuevas solicitudes de usuario al clúster.
2. Inserte una configuración que ya no contenga al clúster.
3. Detenga todos los silos del clúster.

Una vez que se ha quitado un clúster de esta manera, se puede volver a añadir siguiendo el procedimiento para añadir un nuevo clúster.

Actividad en clústeres no unidos

Puede haber períodos breves y específicos en los que un clúster esté activo y no unido:

• Un clúster recién iniciado puede empezar a ejecutar código antes de que esté en la configuración de varios clústeres (entre los pasos 1 y 2 del procedimiento para añadir un clúster)
• Un clúster que se retira puede seguir ejecutando código antes de que se apaguen los silos (entre los pasos 2 y 3 del procedimiento para quitar un clúster).

Durante esas situaciones intermedias, puede ocurrir lo siguiente:

• En los granos de instancia única global: un grano puede tener una activación duplicada en un clúster no unido.
• En los granos con versiones: las activaciones en clústeres no unidos no reciben notificaciones cuando el estado del grano cambia.