Estou configurando 4 hosts, cada um exportando um dispositivo de armazenamento local iscsicom target. Todos os outros hosts o importam de forma que cada host tenha acesso simultâneo a todos os 4 dispositivos de armazenamento. Criei um LVMgrupo de volume compartilhado que inclui todos esses 4 iscsidispositivos. Neste grupo de volumes, criei 4 volumes lógicos, cada um com um dos iscsidispositivos importados. Por fim, uso o mecanismo de sincronização LVMcompartilhada VG, usando lvmlockdedlm para garantir que apenas um host possa usar esses volumes lógicos por vez. Por fim, construí um raid6array em cima desses 4 volumes lógicos, para que a princípio eu possa ter até 2 hosts inativos sem interromper o serviço de armazenamento.
Eu gerencio tudo usando pacemaker, desde a exportação iscside volumes targetaté a construção da raid6matriz. Até agora, tudo funciona perfeitamente, exceto gerenciar cenários em que 1 ou 2 nós estão inativos; os dados estão seguros, mas como defino restrições para iniciar a raid6matriz depois que os recursos de 4 volumes lógicos são iniciados, pacemakerdesativa a matriz assim que pelo menos 1 host fica offline. Eu gostaria pacemakerde continuar o serviço até a perda de 2 hosts.
Para isso, eu precisaria de restrições de ordem (e colocation) que habilitassem o raid6array se e somente se pelo menos 2 desses volumes lógicos estivessem online. Melhor ainda: habilite o raid6array se e somente se no máximo 2 volumes lógicos não puderem ser colocados online, por qualquer motivo. Infelizmente, pacemakerpermite apenas que conjuntos de recursos predecessores em ordem e restrições de colocação (ou seja, o recurso ou conjunto de recursos que deve iniciar primeiro) sejam considerados como iniciados se todos os recursos do conjunto forem iniciados ( require-all=true) ou se pelo menos um for iniciado ( require-all=false) , mas não se pelo menos dois forem iniciados ou no máximo dois estiverem ausentes.
Como solução alternativa, considero criar 11 raid6recursos, um para cada cenário utilizável possível, ou seja, um para cada cenário possível em que faltam no máximo 2 dispositivos lógicos:
LVs1 e 2 estão disponíveisLVs1 e 3 estão disponíveisLVs1 e 4 estão disponíveisLVs2 e 3 estão disponíveisLVs2 e 4 estão disponíveisLVs3 e 4 estão disponíveisLVs1, 2 e 3 estão disponíveisLVs1, 2 e 4 estão disponíveisLVs1, 3 e 4 estão disponíveisLVs2, 3 e 4 estão disponíveisLVs1, 2, 3 e 4 estão disponíveis
Eu criaria raid6recursos com restrições de ordem e colocação, cada uma correspondendo a uma linha na enumeração acima. Em seguida, preciso de uma restrição adicional que exclua cada um desses raid6recursos mutuamente, de modo que, a qualquer momento, o array real seja montado apenas uma vez.
Então aqui vão minhas 3 perguntas:
- Existe alguma maneira de expressar "no máximo 2 ausentes" no predecessor definido na ordem e na restrição de colocação ou, se não, existe alguma construção de restrição semelhante "pelo menos 2 ativos"?
- Se a resposta da questão 1 for não, existe alguma maneira de expressar a exclusão mútua entre um par ou recursos, ou dentro de um conjunto de recursos, preferencialmente com configurações de prioridade que favoreçam as variantes de recursos que usam o maior número de dispositivos?
- Existe alguma outra solução alternativa que qualquer assistente de marca-passo possa sugerir?
Acontece que o agente
ocf:heartbeat:mdraidque uso é perfeitamente capaz de montar um dispositivo com volumes ausentes. Portanto criei 11 recursos fictícios seguindo o esquema descrito na minha pergunta, ou seja:LVs1 e 2 recursos.LVs1 e 3 recursos.LVs1 e 4 recursos.E fiz o recurso raid para começar depois de todos esses recursos fictícios, com
require-all=falseo conjunto de recursos fictício definido na restrição.O próximo problema é o colocation para
LVs1, 2, 3 e 4 adicionar implicitamente uma restrição de ordem deLV 1paraLV 2, paraLV 2paraLV 3, etc., o que significa que se por qualquer motivoLV 3for interrompido,LV 4também será interrompido; mesmo que nada mais o bloqueie. Resolvi removendo a restrição de colocation entre todos osLVrecursos, adicionando outro recurso fictício e criando 4 restrições de colocation entre esse recurso fictício e cada arquivoLV.Este problema parece estar resolvido. Ainda há mais para resolver, mas estão fora do escopo desta questão.