Comunicação de vários clusters

Artigo
07/03/2024

A rede deve ser configurada de modo que qualquer silo do Orleans possa se conectar a qualquer outro silo do Orleans por meio de TCP/IP, independentemente de onde está localizado no mundo. A maneira exata como isso é realizado está fora do escopo do Orleans, pois depende de como e onde os silos são implantados.

Por exemplo, no Windows Azure, podemos usar VNets para conectar várias implantações em uma região e gateways para conectar VNets em diferentes regiões.

Identificador de cluster

Cada cluster tem sua própria ID do cluster exclusiva. A ID do cluster deve ser especificada na configuração global.

As IDs do cluster não podem estar vazias nem conter vírgulas. Além disso, se estiver usando o Armazenamento de Tabelas do Azure, as IDs do cluster não podem conter os caracteres proibidos para chaves de linha (/, #, ?).

É recomendável usar cadeias de caracteres muito curtas para as IDs do cluster, pois as IDs do cluster são transmitidas com frequência e podem ser colocadas no armazenamento por alguns provedores de exibição de log.

Gateways de cluster

Cada cluster designa automaticamente um subconjunto dos silos ativos para atuar como gateways de cluster. Os gateways de cluster anunciam diretamente os endereços IP para outros clusters e, portanto, podem atuar como "pontos de primeiro contato". Por padrão, no máximo, 10 silos (ou qualquer número configurado como MaxMultiClusterGateways) são designados como gateways de cluster.

A comunicação entre silos em clusters diferentes nem sempre passa por um gateway. Depois que um silo aprende e armazena em cache o local de uma ativação de granularidade (independentemente do cluster), ele envia mensagens diretamente para esse silo, mesmo que o silo não seja um gateway de cluster.

Gossip

O gossip é um mecanismo usado para que os clusters compartilhem informações de configuração e status. O gossip é descentralizado e bidirecional: cada silo se comunica diretamente com outros silos, tanto no mesmo cluster quanto em outros clusters, para trocar informações em ambas as direções.

Content. O gossip contêm algumas ou todas as seguintes informações:

A configuração de vários clusters atual com carimbo de data/hora.
Um dicionário que contém informações sobre os gateways de cluster. A chave é o endereço do silo e o valor contém (1) um carimbo de data/hora, (2) a ID do cluster e (3) um status, que é ativo ou inativo.

Propagação lenta e rápida. Quando um gateway altera o status ou quando um operador injeta uma nova configuração, essas informações de gossip são enviadas imediatamente para todos os silos, clusters e canais de gossip. Isso acontece rapidamente, mas não é confiável. Se a mensagem se perder devido a quaisquer motivos (por exemplo, corridas, soquetes quebrados, falhas de silo), nosso gossip geral periódico garante que as informações se espalhem eventualmente, embora mais lentamente. Todas as informações são propagadas eventualmente em todos os lugares e são altamente resilientes a falhas e perdas ocasionais de mensagens.

Todos os dados de gossip recebem o carimbo de data/hora, o que garante que informações mais recentes substituam as mais antigas, independentemente do tempo relativo das mensagens. Por exemplo, as configurações de vários clusters mais recentes substituem as mais antigas e as informações mais recentes de um gateway substituem as mais antigas. Para obter mais detalhes sobre a representação de dados de gossip, confira a classe MultiClusterData. Ela tem um método Merge que combina dados de gossip, que resolvem conflitos usando carimbos de data/hora.

Canais de gossip

Quando um silo é iniciado pela primeira vez ou quando é reiniciado após uma falha, ele precisa ter uma maneira de inicializar o gossip. Essa é a função do canal de gossip, que pode ser definido na Configuração do Silo. Na inicialização, um silo busca todas as informações dos canais de gossip. Após a inicialização, um silo continua executando o gossip periodicamente, a cada 30 segundos ou o que estiver configurado como BackgroundGossipInterval. Ele sempre sincroniza as informações de gossip com um parceiro selecionado aleatoriamente em todos os gateways de cluster e canais de gossip.

Embora não seja estritamente necessário, é recomendável configurar sempre pelo menos dois canais de gossip, em regiões distintas, para maior disponibilidade.
A latência da comunicação com canais de gossip não é crítica.
Vários serviços diferentes podem usar o mesmo canal de gossip sem interferência, desde que o ServiceId Guid (conforme especificado pela respectiva configuração) seja diferente.
Não há requisitos rigorosos de que todos os silos usem os mesmos canais de gossip, desde que os canais sejam suficientes para permitir que um silo se conecte inicialmente com a "comunidade do gossip" quando for inicializado. Mas se um canal de gossip não fizer parte da configuração de um silo e esse silo for um gateway, ele não enviará as atualizações de status para o canal (propagação rápida), então pode levar mais tempo até que cheguem ao canal por meio do gossip geral periódico (propagação lenta).

Canal de gossip baseado em tabela do Azure

Já implementamos um canal de gossip baseado em Tabelas do Azure. A configuração especifica as cadeias de conexão padrão usadas para contas do Azure. Por exemplo, uma configuração pode especificar dois canais de gossip, com contas de armazenamento separadas do Azure usa e europe da seguinte maneira:

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=...")
        });
    })

Vários serviços diferentes podem usar o mesmo canal de gossip sem interferência, desde que o ServiceId Guid especificado pela respectiva configuração seja diferente.

Compartilhar via