Comunicação de vários clusters

Você deve configurar a rede para que qualquer Orleans silo possa se conectar a qualquer outro Orleans silo por meio de TCP/IP, independentemente de onde ela esteja localizada no mundo. Exatamente como você consegue isso está fora do escopo de Orleans, pois depende de como e onde você implanta os silos.

Por exemplo, no Azure, você pode 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 de cluster exclusiva. Você deve especificar a ID do cluster na configuração global.

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

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

Gateways de cluster

Cada cluster designa automaticamente um subconjunto de seus silos ativos para servir como gateways de cluster. Os gateways de cluster anunciam diretamente seus endereços IP para outros clusters e, portanto, podem servir como "pontos do primeiro contato". Por padrão, Orleans designa no máximo 10 silos (ou o número configurado como ) como MaxMultiClusterGatewaysgateways 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 grãos (independentemente do cluster), ele envia mensagens diretamente para esse silo, mesmo que o silo de destino não seja um gateway de cluster.

Fofoca

O Gossip é um mecanismo para os clusters compartilharem informações de configuração e status. Como o nome sugere, a fofoca é descentralizada e bidirecional: cada silo comunica-se diretamente com outros silos, tanto dentro do mesmo cluster quanto em outros clusters, para trocar informações em ambas as direções.

Conteúdo: o Gossip contém algumas ou todas as seguintes informações:

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

Propagação Rápida &Lenta: quando um gateway altera seu status ou quando um operador injeta uma nova configuração, essas informações de fofoca são imediatamente enviadas para todos os silos, clusters e canais de fofoca. Isso acontece rapidamente, mas não é confiável. Se a mensagem for perdida por qualquer motivo (por exemplo, corridas, soquetes quebrados, falhas de silo), fofocas periódicas de fundo garantem que as informações eventualmente se espalhem, embora mais lentamente. Todas as informações eventualmente se propagam em todos os lugares e são altamente resilientes a falhas e perdas ocasionais de mensagens.

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

Canais de fofoca

Quando um silo começa pela primeira vez, ou quando é reiniciado após uma falha, ele precisa de uma maneira de inicializar as fofocas. Essa é a função do canal de fofocas, que você pode configurar na Configuração do Silo. Na inicialização, um silo busca todas as informações dos canais de fofoca. Após a inicialização, um silo continua fofocando periodicamente a cada 30 segundos (ou o intervalo configurado como BackgroundGossipInterval). Cada vez, sincroniza suas informações de fofoca com um parceiro selecionado aleatoriamente de todos os gateways de cluster e canais de fofoca.

• Embora não seja estritamente necessário, recomendamos sempre configurar pelo menos dois canais de fofoca em regiões distintas para melhor disponibilidade.
• Latência de comunicação com canais de fofocas não é crítica.
• Vários serviços diferentes podem usar o mesmo canal de fofocas sem interferência, desde que o ServiceIdGuid (especificado em suas respectivas configurações) seja distinto.
• Não há nenhum requisito estrito de que todos os silos usem os mesmos canais de fofoca, desde que os canais sejam suficientes para permitir que um silo inicialmente se conecte com a "comunidade fofoqueira" quando começar. No entanto, se um canal de fofoca não fizer parte da configuração de um silo e esse silo for um gateway, ele não enviará suas atualizações de status para esse canal (rápida propagação). Portanto, pode levar mais tempo para que essas atualizações cheguem ao canal por meio de fofocas periódicas de fundo (propagação lenta).

Canal de fofoca baseado em tabela do Azure

Implementamos um canal de fofocas baseado em Tabelas do Azure. A configuração especifica cadeias de conexão padrão usadas para contas do Azure. Por exemplo, uma configuração pode especificar dois canais de fofoca com contas de armazenamento separadas usa do Azure 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 fofocas sem interferência, desde que as ServiceIdGuid especificadas por suas respectivas configurações sejam distintas.