Eu trabalhei um pouco com clusters. Estas são as minhas opiniões sobre o assunto.
could have simply added force_unmount="1", but I would like to know what is
the reason behind the default behavior. Why is it not unmounted?
Se você optar por configurar gfs como um recurso clusterizado e adicionar o disco clvmd e gfs como recursos, quando o failover com rgmanager it for tentar desmontar o disco , então o que eu faria no seu caso primeiro é verificar logs (ou lsof / fuser etc) para uma indicação porque o umount pode ter falhado. Provavelmente existe um processo com um arquivo aberto ou algo parecido, evitando um umount "limpo".
Pode ser porque você não usa o rgmanager para iniciar seu aplicativo em cluster? Eu não vejo isso no seu cluster.conf. Isso seria verdade se explicasse o comportamento.
Se você escolher force_unmount , o que o rgmanager fará quando falhar / recuperar forçar a anulação de qualquer recurso usando o disco antes de desmontar o disco. O tempo que é uma boa ideia ou não depende.
clvm is stopped, but GFS is not unmounted, so a node cannot alter LVM structure
on shared storage anymore, but can still access data. And even though a node can
do it quite safely (dlm is still running), [...]
Moreover if I later try to stop cman on that node, it will find a dlm locking,
produced by GFS, and fail to stop.
Se você quiser alterar a estrutura do LVM neste cenário, você pode iniciar o daemon clvmd novamente manualmente. se você desmontar o disco gfs antes de parar o cman, isso deve funcionar. Por outro lado, em um cenário de produção, raramente me encontro em uma situação em que gostaria de interromper o CMAN em um nó em cluster.
Minha preferência é seguir a opção 4.
If I understand the latest approach correctly, such cluster only controls
whether nodes are still alive and can fence errant ones, but such cluster
has no control over the status of its resources.
É verdade que, se você não adicionar o recurso gfs2 e clvmd como um recurso de cluster, rgmanager não poderá controlá-lo.
O que eu costumo fazer quando estiver configurando clusters A / A (dependendo do caso, é claro) é que eu adicionaria o script de início para o meu serviço como o recurso em cluster . (O rgmanager chamará o script com o argumento status regularmente para determinar o tempo necessário para a ação configurada). Como meu script tem uma dependência no sistema de arquivos gfs, ele falhará, a menos que esteja montado.
A abordagem 4 implica na atribuição manual de clvmd , cman e gfs2 (e possivelmente outros daemons também dependendo da situação).
Como o sistema de arquivos GFS fica na parte superior de um dispositivo iSCSI, adicionar a opção _netdev à montagem em /etc/fstab é um requisito para que funcione.
- Dessa forma, não obtenho uma configuração de cluster muito complicada, adicionar mais serviços mais tarde será menos uma dor de cabeça (por exemplo, dois serviços usando o mesmo disco ou o que nunca)
- quando algo acontece, minha experiência é que a intervenção manual é muito mais fácil com recursos não gerenciados por
rgmanager - na minha experiência, não são os serviços gfs2 ou clvmd que mais correm mal em um cluster, mas os serviços no topo, portanto, reiniciando / montando-os frequentemente só levarão seu tempo extra.
Há algumas desvantagens em que posso pensar também:
- Como você disse, o rgmanager não irá gerenciar esses recursos e não tomará nenhuma ação se, por exemplo, o sistema de arquivos gfs falhar de alguma forma / obter umount
- ter um sistema de arquivos gfs muito montado pode gerar carga desnecessária no dispositivo, por exemplo
updatedbe outros trabalhos que podem querer atravessar o sistema de arquivos, causando assim a latência do disco (bloqueando o tráfego)
Não importa o que você decida
Eu adicionaria o script de inicialização como um recurso em cluster, e se você escolhesse adicionar gfs e clvm ao cluster como recursos, eu consideraria adicionar o independent_subtree , portanto, se ele falhar, o rgmanager não será re-montado o sistema de arquivos gfs. Isso depende, naturalmente, da sua situação particular. Observe a configuração aninhada no link, marcando uma espécie de árvore de dependência.