Configuração de vários clusters

A configuração de vários clusters determina quais clusters atualmente fazem parte do multicluster. Ele não é alterado automaticamente, mas é controlado pelo operador. Portanto, é bem diferente do mecanismo de associação usado em 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; caso contrário, estará inativo.
• Um cluster será ingressado se fizer parte da configuração atual multicluster; caso contrário, será não ingressado.

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

Todos os clusters de 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 multicluster. As configurações podem ser injetadas em qualquer cluster e distribuídas de lá para todos os clusters ativos. Cada nova configuração consiste em uma lista de IDs de cluster que formam o multicluster. Ele também tem um carimbo de data/hora UTC usado para acompanhar sua propagação pela rede de fofocas.

Inicialmente, a configuração multicluster é nula, o que significa que a lista multicluster está vazia (não contém clusters). Portanto, o operador deve inicialmente injetar uma configuração multicluster. Depois de 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).

Apresentamos 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.

Granularidade de gerenciamento

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

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

O primeiro argumento para InjectMultiClusterConfiguration(IEnumerable<String>, String, Boolean) é uma coleção de IDs de cluster, que definirá a nova configuração multicluster. 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 booliano chamado checkForLaggingSilosFirst, que usa como padrão true. 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 tenha alcançado a configuração atual e rejeita a alteração se encontra esse silo. Isso ajuda a detectar violações da restrição de que apenas uma alteração de configuração deve estar pendente por vez (embora não possa garantir isso em todas as circunstâncias).

Configuração padrão

Em situações em que a configuração de vários clusters é conhecida com antecedência e a implantação é nova sempre (para teste), pode ser útil fornecer uma configuração padrão. A configuração global dá suporte a um atributo opcional DefaultMultiCluster 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 multicluster é nula e, nesse caso, injeta a configuração fornecida com o carimbo de data/hora UTC atual.

Aviso

Os canais de fofoca multicluster persistentes (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 implantar novamente 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 alterações no canal são captadas e propagadas automaticamente pelas fofocas periódicas em segundo plano, embora possivelmente muito devagar (usar a granularidade de gerenciamento é muito mais rápido). Uma estimativa aproximada sobre o tempo de propagação é de 30 segundos (ou qualquer intervalo de fofocas especificado na configuração global) vezes o logaritmo binário do número total de silos em todos os clusters. Porém, como os pares de fofocas são selecionados aleatoriamente, eles podem ser muito mais rápidos ou muito mais lentos.

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

Nome	Tipo	Valor
PartitionKey	String	a ServiceId
RowKey	String	"CONFIG"
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

Observação

Ao editar esse registro no armazenamento, GossipTimestamp também deve ser definido como um valor mais recente do que atualmente (caso contrário, a alteração será ignorada). A maneira mais conveniente e recomendada de fazer isso é excluir o campo GossipTimestamp – nossa implementação de canal de fofocas então o substitui automaticamente por um carimbo de data/hora atual correto (ela usa o Carimbo de Data/Hora da Tabela do Azure).

Procedimentos de cluster

A adição ou remoção de um cluster do multicluster muitas vezes precisa ser coordenada em 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 cluster do Orleans e aguarde até que todos os silos estejam funcionando.
2. Injete uma configuração que contém o novo cluster.
3. Inicie o roteamento de 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 contém 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 cluster.

Atividade em clusters não ingressados

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

• Um cluster que acaba de ser iniciado pode começar a executar o 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 o código antes que os silos sejam desligados (entre as etapas 2 e 3 do procedimento para remover um cluster).

Durante essas situações intermediárias, o seguinte é possível:

• Para granularidade de instância única global: uma granularidade pode ter uma ativação duplicada em um cluster não ingressado.
• Para granularidades com controle de versão: ativações em clusters não ingressados não recebem notificações quando o estado da granularidade muda.