☰

¿Por qué WinDRBD se vuelve sin disco/independiente (ambos nodos)?

tag-icon • tag-icon drbd window-server-2019
¿Por qué WinDRBD se vuelve sin disco/independiente (ambos nodos)?

Tengo una pregunta.

Actualmente, este sistema operativo es Windows Server 2019. La configuración del volumen es Raid-5. Los dos servidores están conectados mediante una red de latidos. Ambos nodos se duplicaron utilizando WinDRBD. Ambos nodos tienen la misma configuración. Dejé G: sin formato y configuré D: para que fuera visible para el nodo principal.

mis recursos están debajo

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 nodos funcionaron normalmente. Las pruebas se completaron cambiando de roles. ( primaria → secundaria / secundaria → primaria )

Sin embargo, el problema ocurrió después del arranque.

Después del arranque, el estado aparece como se muestra a continuación. (ambos nodos)

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

Pensé y busqué mucho, pero no pude encontrar una respuesta.

Había algunas cosas de las que sospechaba.

Me pregunto si es porque lo intenté antes de que se asignara la letra G: a la unidad. Si mi pensamiento es correcto, ¿existe alguna solución?

Si es mi opinión ahora, pero el problema anterior continúa ocurriendo, ¿cuál es la causa?

Una vez solucionado de la siguiente manera. Pero quiero encontrar la causa y solucionarla con precisión.

drbdadm down foo
drbdadm up foo

Gracias de antemano por tu ayuda.

Respuesta1

WinDRBD pierde latidos, lo que provoca el problema que estás viendo. Corta los cables del h/b y reproducirás fácilmente el problema. La escritura está en la pared: no use WinDRBD en producción al menos todavía. Es frágil.

Respuesta2

@BaronSamedi1958 en realidad tiene razón: WinDRBD no es una solución nativa de Windows, fue descaradamente portado a Windows desde Linux con la ayuda de los contenedores que emulan las API del kernel de Linux.

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

"Técnicamente, el controlador WinDRBD para Windows consiste en una delgada capa de compatibilidad con Linux que emula las API del kernel de Linux utilizadas por el controlador DRBD para la plataforma Windows. Dentro de esta capa, el motor DRBD original (con algunos parches específicos del compilador) está funcionando. "

Como resultado, WinDRBD no tiene mucha idea de lo que está haciendo y de lo que está pasando. Durante la inicialización, intenta establecer una conexión de red con el nodo asociado y falla porque... dentro del ecosistema del kernel de Windows, la pila de almacenamiento comienza ANTES de que la pila de red esté completamente en funcionamiento. WinDRBD no puede hacer ping al nodo asociado, por lo que supone que algo sale mal y no activa el grupo de almacenamiento para preservarlo y evitar la corrupción de datos.

Hay algunas formas de resolver este problema:

  1. Establezca una dependencia inicial para el controlador windrbd en el minipuerto NDIS que controla las NIC utilizadas por WinDRBD.

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

En realidad, es una forma poco convencional, ya que cambiar el adaptador de red arruinará la configuración. + hay un montón de controladores encima del minipuerto NDIS, como filtros NDIS (¿firewall?), controladores de protocolo NDIS (¿TCP/IP?), etc., de los que no sabes mucho y tendrás que retroceder con herramientas especiales que puedas tener. no estoy familiarizado con.

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

  1. Evite el inicio automático de WinDRBD y utilice algún script dependiente del inicio de sesión para iniciarlo de forma pseudoautomática. Durante el proceso de inicio de sesión, todos los componentes del kernel están listos y, en el peor de los casos, puede registrar los problemas de inicio fallidos del controlador en algún archivo de registro, analizarlo, reintentar el script, etc.

Esto se puede hacer, por supuesto, pero requiere algunos retoques con PowerShell. Algunos buenos puntos de partida se pueden obtener de este hilo de discusión a continuación.

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

  1. Utilice algo diseñado para Windows desde cero, como StarWind vSAN Free o el SDS integrado de Microsoft con, por ejemplo, AzS HCI.

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

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

Respuesta3

Es posible que desee actualizar su versión de WinDRBD. La versión que está utilizando todavía es una versión candidata (1.0.0-rc14 más o menos, adivinándose por la fecha de su publicación). Actualice a un WinDRBD más nuevo. Encontrará instaladores precompilados en:

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

Al momento de escribir este artículo, la última versión es 1.1.10.

Si la unidad G: es su dispositivo de respaldo, entonces esta configuración es correcta.

Si el problema persiste por favor hágamelo saber.

información relacionada