none
Отказоустойчивый кластер на 2012r2 RRS feed

  • Вопрос

  • Есть два сервера IBM и SuperMicro

    На них чистая WinServer 20102R2

    Дисковая полка IBM Storwize V3700

    Создан отказоустойчивый кластер, добавлен кворум и общее хранилище.

    На обоих сервера есть c:\clusterstorage\volume1

    Но при проверке кластера 1 ошибка и 1 предупреждение

    Ошибка

    Проверка задержки доступа к диску

    Описание: Проверьте приемлемую задержку для операций чтения и записи на диск.
    Начало: 08.06.2015 16:30:27.
    Проверка задержки чтения на тестовых дисках.
    Проверка задержки записи на тестовых дисках.
    Не удалось получить доступ к тестовому диску 1, или задержка доступа к диску в 5109 мс с узла mall-s-bs1 превышает предел (3000 мс); состояние Операция успешно завершена.
    Завершение: 08.06.2015 16:30:32.

    Не удалось получить доступ к тестовому диску 1, или задержка доступа к диску в 5109 мс с узла mall-s-bs1 превышает предел (3000 мс); состояние Операция успешно завершена.

    Предупреждение

    Проверка дисков на основе Microsoft MPIO

    Описание: Проверка правильности настройки дисков, использующих Microsoft Multipath I/O (MPIO).
    Начало: 08.06.2015 16:30:26.
    Тестовый диск 0 использует Microsoft Multipath I/O (MPIO).
    Число допустимых путей к целевой папке хранилища на тестовом диске 0 узла mall-s-bs1. 1.
    Для каждого тестового диска рекомендуется использовать по крайней мере два независимых пути к целевой папке хранилища.
    Число допустимых путей к целевой папке хранилища на тестовом диске 0 узла mall-s-bs2. 1.
    Для каждого тестового диска рекомендуется использовать по крайней мере два независимых пути к целевой папке хранилища.
    Тестовый диск 1 использует Microsoft Multipath I/O (MPIO).
    Число допустимых путей к целевой папке хранилища на тестовом диске 1 узла mall-s-bs1. 1.
    Для каждого тестового диска рекомендуется использовать по крайней мере два независимых пути к целевой папке хранилища.
    Число допустимых путей к целевой папке хранилища на тестовом диске 1 узла mall-s-bs2. 1.
    Для каждого тестового диска рекомендуется использовать по крайней мере два независимых пути к целевой папке хранилища.

    Получение сведений о зарегистрированных модулях конкретных устройств (DSM) с узла mall-s-bs1

    Как убрать данные предупреждения?

    Спасибо!
    8 июня 2015 г. 13:54

Ответы

  • 3 и 4 интерфесы врткнуты в разные циски для связи с дисковой полкой по 402 влану. Они объединены в группу на каждом физическом сервере

    То есть, имеем независимую от коммутатора группу (team) с динамическим (по умолчанию) распределением и с трафиком от хоста (не от VM). Тогда сначала немного теории.

    В такой группе исходящие кадры с непервичного интерфейса группы имеют адрес MAC источника, никак не связанный с первичным адресом - который работает на приём, и который запоминается в таблице MAC-адресов коммутатора.

    При отказе/отключении первичного интерфейса Windows перенастраивает другой, непервичный, сетевой интерфейс на приём кадров с MAC_адресом первичного интерфейса, но MAC-адрес источника исходящих с этого интерфейса кадров никоим образом не меняется. Поэтому коммутатор не может узнать, что кадры на MAC первичного интерфейса надо пересылать по другому пути и, соответственно, не пересылает их, пока адрес в MAC-таблице не устареет - а у Cisco Catayst, насколько я помню, время устаревания - как раз 5 секунд. Отсюда и возникает та самая задержка, которая не нравится мастеру проверки конфигурации кластера.

    Мой совет по этому поводу: не использовать (расформировать) team, а использовать MPIO (встроенный от MS или от производителя хранилища, если таковой есть).


    Слава России!



    • Изменено M.V.V. _ 9 июня 2015 г. 11:34
    • Помечено в качестве ответа Pogreb 9 июня 2015 г. 12:10
    9 июня 2015 г. 11:32

Все ответы

  • напишите в сапорт IBM возможно они подскажут как сконфигурить полку что бы избавиться от таких задержек
    8 июня 2015 г. 13:58
    Модератор
  • Заявку в IBM сделал, может у кого на практике такое было и решение нашлось?
  • А опишите схему коммутации дисковой стойки и серверов.
  • У каждого сервера по 4 интерфейса

    1 интерфейс - это кросс

    2 интерфейс это влан100 для управления серверами (от одного сервера в циску 1, а от другого сервера в циску2)

    3 и 4 интерфейс объединены в группу и настроен влан 402 для связи с дисковой полкой (физически один провод в одну циску, второй физический провод в другую циску)

    дисковая полка соеденена 3 проводами

    1 порт - влан 100 в циску 1

    2 порт - влан 402 в циску 1

    3 порт - влан 402 в циску 2


    Это все по витой паре
    • Изменено Pogreb 9 июня 2015 г. 8:09
  • тимы собраны на 2 и 3 интерфейсе?
    Модератор
  • не заметил
    Модератор
  • 3 и 4 интерфесы врткнуты в разные циски для связи с дисковой полкой по 402 влану. Они объединены в группу на каждом физическом сервере
    9 июня 2015 г. 10:54
  • 3 и 4 интерфесы врткнуты в разные циски для связи с дисковой полкой по 402 влану. Они объединены в группу на каждом физическом сервере

    То есть, имеем независимую от коммутатора группу (team) с динамическим (по умолчанию) распределением и с трафиком от хоста (не от VM). Тогда сначала немного теории.

    В такой группе исходящие кадры с непервичного интерфейса группы имеют адрес MAC источника, никак не связанный с первичным адресом - который работает на приём, и который запоминается в таблице MAC-адресов коммутатора.

    При отказе/отключении первичного интерфейса Windows перенастраивает другой, непервичный, сетевой интерфейс на приём кадров с MAC_адресом первичного интерфейса, но MAC-адрес источника исходящих с этого интерфейса кадров никоим образом не меняется. Поэтому коммутатор не может узнать, что кадры на MAC первичного интерфейса надо пересылать по другому пути и, соответственно, не пересылает их, пока адрес в MAC-таблице не устареет - а у Cisco Catayst, насколько я помню, время устаревания - как раз 5 секунд. Отсюда и возникает та самая задержка, которая не нравится мастеру проверки конфигурации кластера.

    Мой совет по этому поводу: не использовать (расформировать) team, а использовать MPIO (встроенный от MS или от производителя хранилища, если таковой есть).


    Слава России!



    • Изменено M.V.V. _ 9 июня 2015 г. 11:34
    • Помечено в качестве ответа Pogreb 9 июня 2015 г. 12:10
    9 июня 2015 г. 11:32
  • Спасибо за помощь и за теорию
    9 июня 2015 г. 12:10