Estou usando um Docker Swarm que abrange vários data centers. O Swarm é executado em uma “nuvem privada virtual”.
Um dos data centers participantes da configuração possui um link um pouco mais lento que os outros. Gostaria de evitar que um serviço particularmente sensível à latência fosse agendado nesse data center.
- Posso usar restrições de posicionamento, mas isso afetará a disponibilidade. Se o data center "lento", por algum motivo, for o único em execução, as restrições garantirão que o serviço restrito nunca seja agendado nesse data center. Disponibilidade de impacto.
- Posso usar preferências de posicionamento, mas isso é apenas uma preferência. Se eu adicionar o rótulo
lowlatency
a todos os nós, exceto aqueles no data center "lento", o serviço ainda poderá ser agendado lá. Afinal, é apenas uma preferência.
Existe uma maneira de restringir de alguma forma um serviço a determinados nós, mas permitir que o Docker agende o serviço em outros nós se os nós preferenciais não estiverem disponíveis?
Responder1
Não, este não é um recurso integrado ao modo Swarm.
A única preferência de posicionamento disponível atualmente é distribuir a carga de trabalho pelos valores de um rótulo. Isto é usado para evitar que todas as réplicas sejam agendadas em uma única zona de disponibilidade, por exemplo, todas as cargas de trabalho no mesmo rack, datacenter, etc. Não há preferência de posicionamento que funcione como uma restrição suave.
A outra opção disponível no agendamento de enxame é uma restrição e é uma restrição rígida. As cargas de trabalho não serão agendadas em nós que não correspondam à restrição, mesmo que isso signifique que não possam ser agendadas em nenhum lugar e que o serviço permaneça inativo.
O mais próximo que você pode chegar do objetivo desejado é executar um processo adicional para detectar a interrupção de todos os outros datacenters e ajustar a restrição do seu serviço; no entanto, suspeito que isso terá dois problemas correspondentes. Primeiro, com os outros datacenters inativos, você provavelmente perdeu o quorum com seus gerentes, nenhuma atividade de agendamento ocorrerá e os comandos para qualquer gerente em execução falharão devido à perda de um líder. E segundo, se você tiver quorum, os nós no datacenter restante provavelmente ficarão superprovisionados devido às outras cargas de trabalho que estão sendo reprogramadas. Isso é conhecido como o problema do rebanho trovejante, que exige a configuração de requisitos de CPU e memória em seus contêineres. Esses requisitos bloqueariam o agendamento de novos trabalhos no nó para evitar uma interrupção adicional e impedir que seu serviço alterado encontrasse um nó com capacidade.