Configuração de vários clusters

A configuração multi-cluster determina quais clusters fazem parte atualmente do multi-cluster. Não muda automaticamente, mas é controlado pelo operador. Assim, é bastante diferente do mecanismo de associação usado dentro de um cluster, que determina automaticamente o conjunto de silos que fazem parte do cluster.

Usamos a seguinte terminologia para os clusters em um serviço:

• Um cluster estará ativo se tiver pelo menos um silo ativo e inativo caso contrário.
• Um cluster é associado se fizer parte da configuração atual de vários clusters e não ingressado caso contrário.

Ser ativo/inativo é independente de estar junto/não associado: todas as quatro combinações são possíveis.

Todos os clusters para um determinado serviço são conectados por uma rede de fofocas. A rede de fofocas propaga informações de configuração e status.

Injetar uma configuração

Um operador emite alterações de configuração injetando-as na rede multi-cluster. As configurações podem ser injetadas em qualquer cluster e espalhadas a partir daí para todos os clusters ativos. Cada nova configuração consiste em uma lista de ids de cluster que formam o multi-cluster. Ele também tem um carimbo de data/hora UTC que é usado para rastrear sua propagação através da rede de fofocas.

Inicialmente, a configuração de vários clusters é nula, o que significa que a lista de vários clusters está vazia (não contém clusters). Assim, o operador deve inicialmente injetar uma configuração multi-cluster. Uma vez injetada, essa configuração persiste em todos os silos conectados (durante a execução) e em todos os canais de fofoca especificados (se esses canais forem persistentes).

Colocamos algumas restrições à injeção de novas configurações que um operador deve seguir:

• Cada nova configuração pode adicionar vários clusters ou remover alguns clusters (mas não ambos ao mesmo tempo).
• Um operador não deve emitir uma nova configuração enquanto uma alteração de configuração anterior ainda estiver sendo processada.

Essas restrições garantem que protocolos como o protocolo de instância única possam manter corretamente a exclusão mútua de ativações, mesmo sob alterações de configuração.

Gestão de cereais

As configurações de vários clusters podem ser injetadas em qualquer nó de qualquer cluster, usando o Orleans Management Grain. Por exemplo, para injetar uma configuração de vários clusters que consiste nos três clusters { us1, eu1, us2 }, podemos passar uma cadeia de caracteres enumerável para o grão de gerenciamento:

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

O primeiro argumento é InjectMultiClusterConfiguration(IEnumerable<String>, String, Boolean) uma coleção de ids de cluster, que definirá a nova configuração de vários clusters. O segundo argumento é uma cadeia de caracteres de comentário (opcional) que pode ser usada para marcar configurações com informações arbitrárias, como quem as injetou e por quê.

Há um terceiro argumento opcional, um booleano chamado checkForLaggingSilosFirst, que tem como padrão verdadeiro. Isso significa que o sistema executa uma verificação de melhor esforço para ver se há algum silo em qualquer lugar que ainda não alcançou a configuração atual e rejeita a alteração se encontrar tal silo. Isso ajuda a detetar violações da restrição de que apenas uma alteração de configuração deve estar pendente de cada vez (embora não possa garanti-la em todas as circunstâncias).

Configuração predefinida

Em situações em que a configuração de vários clusters é conhecida com antecedência e a implantação é atualizada toda vez (para teste), podemos fornecer uma configuração padrão. A configuração global suporta um atributo DefaultMultiCluster opcional que usa uma lista separada por vírgulas de ids de cluster:

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

Depois que um silo é iniciado com essa configuração, ele verifica se a configuração atual de vários clusters é nula e, em caso afirmativo, injeta a configuração fornecida com o carimbo de data/hora UTC atual.

Aviso

Os canais de fofoca persistentes de vários clusters (com base no AzureTable) mantêm a última configuração injetada, a menos que sejam excluídos explicitamente. Nesse caso, especificar um DefaultMultiCluster não tem efeito ao reimplantar um cluster porque a configuração armazenada nos canais de fofoca não é nula.>

Canal de fofocas

Um operador também pode injetar a configuração diretamente no canal de fofocas. As mudanças no canal são captadas e propagadas automaticamente pela fofoca periódica de fundo, embora possivelmente muito lentamente (usar o grão de gerenciamento é muito mais rápido). Uma estimativa aproximada do tempo de propagação é de 30 segundos (ou qualquer intervalo de fofoca especificado na configuração global) vezes o logaritmo binário do número total de silos em todos os clusters. Mas como os pares de fofocas são selecionados aleatoriamente, eles podem ser muito mais rápidos ou muito mais lentos.

Se estiver usando o canal de fofocas baseado em tabela do Azure, os operadores podem injetar uma nova configuração simplesmente editando o registro de configuração no , usando alguma ferramenta para editar dados em tabelas do OrleansGossipTableAzure. O registro de configuração tem o seguinte formato:

Nome	Tipo	valor
PartitionKey	String	o ServiceId
RowKey	String	"CONFIGURAÇÃO"
Clusters	String	Lista separada por vírgulas de IDs de cluster, por exemplo, "us1,eu1,us2"
Comentário	String	comentário opcional
GossipTimestamp	DateTime	Carimbo de data/hora UTC para a configuração

Nota

Ao editar esse registro no armazenamento, o GossipTimestamp também deve ser definido para um valor mais recente do que tem atualmente (caso contrário, a alteração será ignorada). A maneira mais conveniente e recomendada de fazer isso é excluir o GossipTimestamp campo - nossa implementação de canal de fofoca o substitui automaticamente por um carimbo de data/hora correto e atual (ele usa o carimbo de data/hora da tabela do Azure).

Procedimentos de agrupamento

Adicionar ou remover um cluster do multi-cluster geralmente precisa ser coordenado dentro de algum contexto maior. Recomendamos sempre seguir os procedimentos descritos abaixo ao adicionar/remover clusters do multicluster.

Procedimento para adicionar um cluster

1. Inicie um novo Orleans cluster e aguarde até que todos os silos estejam em funcionamento.
2. Injete uma configuração que contenha o novo cluster.
3. Comece a rotear solicitações de usuário para o novo cluster.

Procedimento para remover um cluster

1. Pare de rotear novas solicitações de usuário para o cluster.
2. Injete uma configuração que não contenha mais o cluster.
3. Pare todos os silos do cluster.

Depois que um cluster for removido dessa forma, ele poderá ser adicionado novamente seguindo o procedimento para adicionar um novo cluster.

Atividade em clusters não aderidos

Pode haver períodos breves e temporários em que um cluster está ativo e não associado:

• Um cluster recém-iniciado pode começar a executar código antes de estar na configuração de vários clusters (entre as etapas 1 e 2 do procedimento para adicionar um cluster)
• Um cluster que está sendo desativado ainda pode executar código antes que os silos sejam desligados (entre as etapas 2 e 3 do procedimento para remover um cluster).

Durante essas situações intermédias, são possíveis:

• Para grãos globais de instância única: um grão pode ter uma ativação duplicada em um cluster não associado.
• Para grãos versionados: ativações em clusters não associados não recebem notificações quando o estado do grão muda.