☰

Почему WinDRBD становится Diskless/StandAlone (оба узла)

tag-icon • tag-icon drbd window-server-2019
Почему WinDRBD становится Diskless/StandAlone (оба узла)

У меня есть вопрос.

В настоящее время эта ОС — Windows Server 2019. Конфигурация тома — Raid-5. Два сервера соединены сетью heartbeat. Оба узла были зеркалированы с помощью WinDRBD. Оба узла имеют одинаковую конфигурацию. Я оставил неотформатированным G: и сделал D: видимым для основного узла.

мои ресурсы ниже

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;
        }
    }
}

Оба узла работали нормально. Тесты были завершены путем смены ролей. (первичный → вторичный / вторичный → первичный)

Однако проблема возникла после загрузки.

После загрузки статус выглядит следующим образом. (оба узла)

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

Я много думал и искал, но так и не нашел ответа.

Было несколько вещей, которые мне показались подозрительными.

Интересно, это потому, что я пробовал до того, как буква G: была назначена диску. Если я правильно думаю, есть ли обходной путь?

Если сейчас я так считаю, но проблема, указанная выше, продолжает возникать, в чем причина?

Когда-то это решалось следующим образом. Но я хочу найти причину и устранить ее точно.

drbdadm down foo
drbdadm up foo

Заранее спасибо за вашу помощь.

решение1

WinDRBD теряет пульс, что приводит к проблеме, которую вы видите. Отрежьте провода для h/b, и вы легко воспроизведете проблему. Написано на стене: не используйте WinDRBD в производстве, по крайней мере пока. Он хрупкий.

решение2

@BaronSamedi1958 на самом деле прав: WinDRBD не является собственным решением Windows, он был откровенно перенесен на Windows из Linux с помощью оболочек, эмулирующих API ядра Linux.

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

«Технически драйвер WinDRBD для Windows состоит из тонкого слоя совместимости с Linux, который эмулирует API ядра Linux, используемые драйвером DRBD для платформы Windows. Внутри этого слоя работает оригинальный движок DRBD (с несколькими исправлениями, специфичными для компилятора)».

В результате WinDRBD не имеет ни малейшего понятия о том, что он делает и что происходит. При инициализации он пытается установить сетевое соединение с партнерским узлом и терпит неудачу, потому что... в экосистеме ядра Windows стек хранения запускается ДО того, как сетевой стек будет полностью запущен и запущен! WinDRBD не может пинговать партнерский узел, поэтому он предполагает, что что-то пошло не так, и не поднимает пул хранения, чтобы сохранить его и избежать повреждения данных.

Есть несколько способов решить эту проблему:

  1. Установите начальную зависимость для драйвера Windrbd на мини-порте NDIS, управляющем сетевыми картами, используемыми WinDRBD.

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

На самом деле это ненадежный способ, так как смена сетевого адаптера испортит конфигурацию. + есть целая куча драйверов над минипортом NDIS, таких как фильтры NDIS (брандмауэр?), драйверы протокола NDIS (TCP/IP?) и т. д., о которых вы мало что знаете, и вам придется возвращаться к ним с помощью специальных инструментов, с которыми вы, возможно, не знакомы.

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

  1. Избегайте автоматического запуска WinDRBD и используйте некий зависящий от входа скрипт для его псевдоавтоматического запуска. Во время процесса входа все компоненты ядра готовы, и в худшем случае вы можете записать ваши неудачные проблемы с запуском драйвера в какой-нибудь файл журнала, проанализировать его, повторить попытки скрипта и т. д.

Конечно, это можно сделать, но для этого требуется немного повозиться с PowerShell. Некоторые хорошие отправные точки вы можете получить из этой ветки обсуждения ниже.

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

  1. Используйте что-то, разработанное для Windows с нуля, например, StarWind vSAN Free или встроенную в Microsoft SDS, например, AzS HCI.

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

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

решение3

Возможно, вам стоит обновить версию WinDRBD. Версия, которую вы используете, все еще является релиз-кандидатом (1.0.0-rc14 или около того, судя по дате вашего сообщения). Пожалуйста, обновитесь до более новой версии WinDRBD. Вы найдете предварительно скомпилированные установщики по адресу:

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

На момент написания статьи последняя версия — 1.1.10.

Если диск G: является вашим устройством резервного копирования, то эта настройка верна.

Если проблема сохранится, пожалуйста, дайте мне знать.

Связанный контент