Comunicação multi-cluster
A rede deve ser configurada de tal forma que qualquer Orleans silo possa se conectar a qualquer outro Orleans silo via TCP/IP, independentemente de onde no mundo ele está localizado. Exatamente como isso é conseguido está fora do escopo do Orleans, pois depende de como e onde os silos são implantados.
Por exemplo, no Windows Azure, podemos usar redes virtuais para conectar várias implantações em uma região e gateways para conectar redes virtuais em diferentes regiões.
Identificador de cluster
Cada cluster tem sua própria ID de cluster exclusiva. A ID do cluster deve ser especificada na configuração global.
As ids de cluster não podem estar vazias, nem podem conter vírgulas. Além disso, se estiver usando o Armazenamento de Tabela do Azure, as ids de cluster podem não conter os caracteres proibidos para chaves de linha (/, , #, ?).
Recomendamos o uso de cadeias de caracteres muito curtas para as ids de cluster, porque as ids de cluster são transmitidas com freqüê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 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 grão (não importa em qual cluster), ele envia mensagens para esse silo diretamente, mesmo que o silo não seja um gateway de cluster.
Gossip
A fofoca é um mecanismo para clusters compartilharem informações de configuração e status. Como o nome sugere, a fofoca é descentralizada 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.
Conteúdo. Gossip contém algumas ou todas as seguintes informações:
- A configuração atual de multi-cluster com carimbo 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 carimbo de data/hora, (2) a ID do cluster e (3) um status, que está ativo ou inativo.
Propagação rápida ou lenta. Quando um gateway muda de 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 rápido, mas não é confiável. Se a mensagem for perdida devido a quaisquer razões (por exemplo, corridas, tomadas quebradas, falhas de silo), nossas fofocas periódicas de fundo garantem que a informação eventualmente se espalhe, embora mais lentamente. Todas as informações são eventualmente propagadas em todos os lugares e são altamente resilientes a perdas e falhas ocasionais de mensagens.
Todos os dados de fofoca têm carimbo de data/hora, o que garante que as informações mais recentes substituam as informações mais antigas, independentemente do tempo relativo das mensagens. Por exemplo, as configurações multi-cluster mais recentes substituem as mais antigas, e as informações mais recentes sobre um gateway substituem as informações mais antigas sobre esse gateway. Para obter mais detalhes sobre a representação de dados de fofocas, consulte a MultiClusterData
classe. Tem um Merge
método que combina dados de fofocas, resolvendo conflitos usando carimbos de data/hora.
Canais de fofoca
Quando um silo é iniciado pela primeira vez, ou quando é reiniciado após uma falha, ele precisa ter uma maneira de arrancar a fofoca. Este é o papel do canal de fofocas, que pode ser configurado 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 fica fofocando periodicamente, a cada 30 segundos, ou o que quer que seja configurado como BackgroundGossipInterval
. Cada vez que 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.
- A latência da comunicação com canais de fofoca não é crítica.
- Vários serviços diferentes podem usar o mesmo canal de fofoca sem interferência, desde que o ServiceId
Guid
(conforme especificado por sua respetiva configuração) seja distinto. - Não há nenhuma exigência estrita de que todos os silos usem os mesmos canais de fofoca, desde que os canais sejam suficientes para permitir que um silo se conecte inicialmente com a "comunidade de fofocas" quando ele for iniciado. Mas se um canal de fofoca não faz parte da configuração de um silo, e esse silo é um gateway, ele não empurra suas atualizações de status para o canal (propagação rápida), então pode levar mais tempo até que eles cheguem ao canal por meio de fofocas periódicas de fundo (propagação lenta).
Canal de fofocas baseado em tabela do Azure
Já implementamos um canal de fofocas baseado nas 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 usa
de armazenamento do Azure separadas 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 fofoca sem interferência, desde que o ServiceId Guid
especificado por sua respetiva configuração seja distinto.