☰

Por que o WinDRBD se torna Diskless/StandAlone (ambos os nós)

tag-icon • tag-icon drbd window-server-2019
Por que o WinDRBD se torna Diskless/StandAlone (ambos os nós)

Eu tenho uma pergunta.

Atualmente, este sistema operacional é o Windows Server 2019. A configuração do volume é Raid-5. Os dois servidores estão conectados por uma rede heartbeat. Ambos os nós foram espelhados usando WinDRBD. Ambos os nós têm a mesma configuração. Deixei G: não formatado e configurei D: para ficar visível para o nó primário.

meus recursos estão abaixo

include "global_common.conf";

resource "foo" {
    protocol    A;

    net {
        use-rle no;
    }
    on node1 {
        address     XXX.XXX.XXX.XXX:7600;
        node-id 1;
        volume 1 {
            disk        "G:";
            device      minor 1;
            meta-disk   internal;
        }
    }
    on node2 {
        address     XXX.XXX.XXX.XXX:7600;
        node-id 2;
        volume 1 {
            disk            "G:";
            device      minor 1;
            meta-disk   internal;
        }
    }
}

Ambos os nós funcionaram normalmente. Os testes foram concluídos com a troca de funções. (primário → secundário/secundário → primário)

No entanto, o problema ocorreu após a inicialização.

Após a inicialização, o status aparece conforme abaixo. (ambos os nós)

foo role:Secondary
  volume:1 disk:Diskless
  node2 connection:StandAlone

Pensei e procurei muito, mas não encontrei resposta.

Havia algumas coisas das quais eu suspeitava.

Eu me pergunto se é porque tentei antes da letra G: ser atribuída à unidade. Se meu pensamento estiver correto, existe uma solução alternativa?

Se for minha opinião agora, mas o problema acima continuar ocorrendo, qual é a causa?

Uma vez que foi resolvido da seguinte maneira. Mas quero encontrar a causa e corrigi-la com precisão.

drbdadm down foo
drbdadm up foo

Agradeço antecipadamente por sua ajuda.

Responder1

WinDRBD perde pulsação, o que leva ao problema que você está vendo. Corte os fios do h/b e você reproduzirá facilmente o problema. A escrita está na parede: não use o WinDRBD em produção, pelo menos ainda. É frágil.

Responder2

@BaronSamedi1958 na verdade tem razão: WinDRBD não é uma solução nativa do Windows, ele foi descaradamente portado do Linux para o Windows com a ajuda dos wrappers que emulam APIs do kernel do Linux.

https://linbit.com/windrbd-replicated-disk-drives-for-windows/

"Tecnicamente, o driver WinDRBD Windows consiste em uma fina camada de compatibilidade Linux que emula as APIs do kernel Linux usadas pelo driver DRBD para a plataforma Windows. Dentro desta camada, o mecanismo DRBD original (com alguns patches específicos do compilador) está funcionando. "

Como resultado, o WinDRBD não tem muita ideia do que está fazendo e do que está acontecendo. Na inicialização, ele tenta estabelecer uma conexão de rede com o nó parceiro e falha porque... dentro do ecossistema do kernel do Windows, a pilha de armazenamento começa ANTES que a pilha de rede esteja totalmente instalada e funcionando! O WinDRBD não consegue executar ping no nó do parceiro, portanto assume que algo está errado e não ativa o pool de armazenamento para preservá-lo e evitar a corrupção de dados.

Existem algumas maneiras de resolver esse problema:

  1. Coloque uma dependência inicial para o driver windrbd na miniporta NDIS controlando as NICs usadas pelo WinDRBD.

https://docs.microsoft.com/en-us/windows-hardware/drivers/install/specifying-driver-load-order

Na verdade, é uma maneira esquisita, pois alterar o adaptador de rede arruinará a configuração. + há um monte de drivers acima da miniporta NDIS, como filtros NDIS (firewall?), drivers de protocolo NDIS (TCP/IP?) etc., sobre os quais você não sabe muito e terá que voltar com ferramentas especiais que você pode ser não estou familiarizado.

https://docs.microsoft.com/en-us/windows-hardware/drivers/network/ndis-driver-stack

  1. Evite o início automático do WinDRBD e use algum script dependente de logon para iniciá-lo pseudo-automaticamente. Durante o processo de logon, todos os componentes do kernel estão prontos e, na pior das hipóteses, você pode registrar os problemas de inicialização malsucedida do driver em algum arquivo de log, analisá-lo, fazer novas tentativas de script e assim por diante.

É claro que isso pode ser feito, mas requer alguns ajustes no PowerShell. Alguns bons pontos de partida que você pode obter neste tópico de discussão abaixo.

https://stackoverflow.com/questions/27599287/powershell-disable-and-enable-a-driver

  1. Use algo projetado para Windows do zero, como fe StarWind vSAN Free ou o próprio SDS da Microsoft integrado com, digamos, AzS HCI.

https://www.starwindsoftware.com/starwind-virtual-san-free

https://docs.microsoft.com/en-us/azure-stack/hci/overview

Responder3

Você pode querer atualizar sua versão do WinDRBD. A versão que você está usando ainda é uma versão canidada (1.0.0-rc14 ou mais, adivinhando pela data da sua postagem). Atualize para um WinDRBD mais recente. Você encontrará instaladores pré-compilados em:

https://linbit.com/linbit-software-download-page-for-linstor-and-drbd-linux-driver/

No momento em que este livro foi escrito, a versão mais recente era 1.1.10.

Se a unidade G: for o seu dispositivo de apoio, esta configuração está correta.

Se o problema persistir, por favor me avise.

informação relacionada