none
Hyper-V Cluster, изменить время реакции на сбой RRS feed

  • Общие обсуждения

  • Коллеги, здравствуйте.

    Столкнулся с проблемой. Есть кластер Hyper-V из 16 хостов (+ System Center).  Физических серверах всего два 10G интерфейса, которые объединены в группу (Switch Independent, Hyper-V, Active-Active). Диски (кроме системного, который локальный) подключаются по iSCSI. ПО используется стандартное Windows (ISCSI Initiator + MPIO). Некоторые параметры служб изменены следующим образом:

        Set-MSDSMGlobalDefaultLoadBalancePolicy -Policy RR
        Set-MPIOSetting -NewDiskTimeout 60

        $rp = "HKLM:\System\CurrentControlSet\Services\mpio\Parameters"
        Set-ItemProperty -Path $rp -Name PDORemovePeriod -Value 120
        Set-ItemProperty -Path $rp -Name PathRecoveryInterval -Value 25
        Set-ItemProperty -Path $rp -Name UseCustomPathRecoveryInterval -Value 1
        Set-ItemProperty -Path $rp -Name PathVerifyEnabled -Value 1
        Set-ItemProperty -Path $rp -Name DiskPathCheckInterval -Value 25

        $rp = "HKLM:\SYSTEM\CurrentControlSet\Control\Class\{4D36E97B-E325-11CE-BFC1-08002BE10318}\0003\Parameters"
        Set-ItemProperty -Path $rp -Name MaxRequestHoldTime -Value 90
        Set-ItemProperty -Path $rp -Name LinkDownTime -Value 35
        Set-ItemProperty -Path $rp -Name EnableNOPOut -Value 1

    Как видим из настроек, 120 секунд сервер должен все i/o операции писать в RAM. Проверка путей идет через 25 секунд, 3 (дефолтное значение RetryCount) раза. Для Failover Cluster установлены значения (специально ставил максимум):

    SameSubnetDelay 2
    SameSubnetThreshold 120
    CrossSubnetThreshold 120

    Собственно, проблема. При аварийном отключении одного из коммутаторов имеем лаг в 20 секунд. Сеть в это время не работает. Соответственно, нет доступа к СХД. И вот из-за этого часть виртуальных машин уходит в ребут. Причем это происходит как-то некорректно. После того, как они загружаются, недоступна сеть, которая использует виртуализацию Hyper-V. Помогает только миграция (live) машины на любую другую ноду. 

    Может кто сталкивался с подобной проблемой? Что можно еще донастроить? Очень важно, чтобы ВМ не перезагружались. Надо как-то сделать так, чтобы система секунд 25 вообще никак не реагировала на сбой сети и СХД и спокойно записывала изменения в RAM.
    12 июля 2016 г. 22:00

Все ответы

  • Во-первых, воспользуйтесь информацией из KB3153887.

    Во-вторых, ознакомьтесь со статьёй о тюнинге кластерных сетей и о Resource Hosting Subsystem.

    13 июля 2016 г. 8:24
    Модератор
  • Денис, спасибо за ответ.

    Все эти статьи я видел - не помогло. Но у меня уже есть предположения, что еще можно подправить. Если получится, я отпишусь.

    13 июля 2016 г. 19:43
  • Привет Артем,

    Вы успели найти решение Вашей проблемы?


    Мнения, высказанные здесь, являются отражением моих личных взглядов, а не позиции корпорации Microsoft. Вся информация предоставляется "как есть" без каких-либо гарантий. Не забывайте помечать сообщения как ответы и полезные, если они Вам помогли.

    25 июля 2016 г. 10:43
    Модератор
  • Добрый день, коллеги.

    В первом посте я не уточнил, что в кластере находилось больше 1000 ВМ (не придал этому значения). Оказалось, это очень важно. В итоге мы имели следующую гремучую смесь:

    1. Нет выделенной сети для СХД

    2. Core коммутаторы ZTE, которые работают на уровне "отвратительно" (R&D ZTE особо помочь не может, обещают через N месяцев выпустить патчи)

    3. Относительно большое количество ВМ на хост

    Помог решить ЭТУ проблему какой-то патч ZTE (release note никто нам не дал). После него сеть стала работать заметно лучше. Потерю коммутатора мы более-менее терпимо переживали. Но появились НОВЫЕ проблемы при его запуске - сеть отваливалась, машины Windows уходили в ребут, Linux, если выживали, переводили диски в RO. 

    Решить НОВЫЕ проблемы получилось удалив 1000 тестовых машин (простое выключение не помогало).

    Теперь, когда количество ВМ на хосте не превышает 20, все работает нормально. 

    Как я понял, проблема была из-за того, что при лаге сети службы FC опрашивали состояние всех ресурсов на серверах (ну а ВМ это и есть ресурс). В итоге из-за наложения проблем не всегда получалось получить корректный ответ от WMI (хост переходил в статус "Not Responding") и сервис считался умершим. Далее система выполняла его перенос на "рабочий" сервер и из-за этого начинался хаос. 

    Тюнинг WMI не помогал, премьер сапорт МС тоже не смог разобраться. Нода, кстати, могла уйти в статус "Not Responding" и без миграции. Это случалось тогда, когда на ней одновременно находилось, ориентировочно, более 100 ВМ (не важно, запущены или остановлены).

    Какое-то сумбурное у меня получилось описание ошибки :) Если интересно, можете задавать еще уточняющие вопросы.

    28 июля 2016 г. 7:33