Главная Virtualization, Новое VMware HA: глубокое погружение
  • VMware HA: глубокое погружение

    vmware-logo-new-2009-400-300x481. Slots & Primary nodes
    2. Isolation

    Многие, пожалуй, встречались с ситуацией, когда в HA-кластере ресурсов на первый взгляд предостаточно, а HA ругается на нехватку ресурсов. Это происходит по причине того, что у HA своя собственная арифметика, основанная на слотах.

    Что такое слот? Слот – это место под условную машину, и возможное количество ВМ в кластере определяется количеством слотов под них. HA берет самый большой резерв по процессорам и памяти в кластере и устанавливает в качестве размера слота (память + overhead). Если нет резервов, то процессорная мощность в слоте устанавливается в 256 MHz, а память в слоте считается по размеру наибольшего overhead.

    Как определяется колчиство слотов на хосте? Делением. При этом, если количество процессорных слотов получается 25, но только 5 слотов по памяти, то считается, что слотов на хосте 5. А далее слоты всех хостов просто суммируются – в итоге мы имеем емкость HA кластера.

    Что в этом случае происходит с несбалансированными кластерами? Несбалансированным кластером, например, является кластер из 5 хостов, в котором на 4х хостах по 16ГБ памяти, а на 5м – 32.

    Одна из ВМ сконфигурирована с 4 vCPU / 4 GB, и поскольку резервов нет, то слоты памяти рассчитываются по оверхеду данной машины – 325 MB.

    Что в итоге дает по 50 слотов для esx01 – esx04, и 100 для esx05. При включенном Admission Control берется худший сценарий и рассчитывается все на случай падения самых мощных хостов. Т.е. при установленном “Host failures cluster tolerates: 1” мы получаем 200 слотов в кластере. В случае 5и хостов по 16ГБ результат был бы тот же самый – “5*50 – 1*50 = 200”.
    Если включаете Admission Control, то балансируйте ваши кластеры.

    Есть в расширенных настройках такие параметры как das.slotCpuInMHz и das.slotMemInMB для принудительной установки размера слота. Эти параметры могут очень помочь, если у нескольких ВМ в кластере высокие значения резервов, однако здесь тоже есть свои нюансы.

    Размер слота памяти установлен в 1024 MB, а VM24 имеет резерв в 4 GB. Как можно заметить, ни у одного из хостов нет 4х свободных слотов, и хотя по сумме слотов требования HA выполняются, есть вероятность, что HA не сможет рестартовать VM24.

    Primary nodes

    HA кластер состоит из максимум 32 узлов, которые в свою очередь подразделяются на Primary и Secondary. Primary узлы являются “управляющими” и держат у себя информацию о конфигурации и состоянии кластера, синхронизируя между собой.

    Primary узлы посылают хартбиты (heartbeat) только Primary узлам, Secondary узлы посылают хартбиты тоже только Primary узлам. По умолчанию 1 хартбит в секунду, но это конфигурируемый параметр: das.failuredetectioninterval.

    Первые 5 узлов, включенные в HA кластер автоматически становятся Primary, а все остальные Secondary. Но если производится действие “Reconfigure for HA”, то узлы назначаются Primary и Secondary случайным образом. vSphere клиент не показывает, является ли выбранный узел Primary или Secondary, есть только одна возможность это увидеть – из сервис-консоли:

    cat /var/log/vmware/aam/aam_config_util_listnodes.log

    или

    /opt/vmware/aam/bin/Cli (ftcli в ранних версиях)
    AAM> ln

    Распространена ошибка, что при падении Primary узла происходят перевыборы. Не в этом случае. Перевыборы Primary (выдвижение Secondary узла на Primary роль) происходят только при введении Primary узла в Maintenance Mode, отключении от кластера (disconnect) или удалении из кластера.

    Если же все 5 Primary узлов упали одновременно, то рестарта виртуальных машин не произойдет, HA требует наличия хотя бы одного Primary узла для работы. Именно поэтому HA кластер может пережить смерть максимум 4 хостов.

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

    Один из Primary узлом получает роль Fail-over coordinator или Active Primary. Именно он управляет рестартом виртуальных машин при выходе узлов из строя. Если падает Active Primary, то эту роль берет на себя один из оставшихся Primary узлов.

    Оригинал – Duncan Epping

    http://blog.vadmin.ru

Комментарии

  1. Спасибо. Читается легко и понятно

  2. Как приятно почитать не маркетинговую чушь, а полезную статью.
    Респект.

  3. Статья полезная, но написано слишком сухо.