16 самых больших ошибок при настройке кластеров HA и DRS VMWARE

 

  1. Не планирование изменений в аппаратном обеспечении.

    Включить EVC режим на кластерах, и стараться использовать оборудование, которое имеет очень похожие процессоры. Не смешивайте процессоры Intel и AMD. И даже если все ЦПУ одного вендора, новые процессоры будут поддерживать дополнительные инструкции не доступные на старых моделях. Обратите внимание на Процессоры, которые вы покупаете.

  2. Не планирование svMotion (storage vMotion).

    Снапшоты — зло, и вы НЕ должны их использовать, кроме как в редких случаях. Убедитесь, что ваши VMDK в presistent режиме или используйте RDM. Серверы должны видеть исходный и целевой датастор, и кластер должен иметь достаточно ресурсов, чтобы в момент переноса иметь две одновременно запущенные копии ВМ.

  3. Не достаточно узлов в кластере.

    Планируйте необходимые ресурсы кластера и учитывайте необходимость резерва. Как правило, резервы по ресурсам на хостах должны в сумме быть как один полноценный сервер. Решением является использование политики admission control и планирование выхода из строя одного хоста.

  4. Установка в резерв целиком одного хоста.

    Не все ВМ являются критичными и у каждой есть разный приоритет перезапуска. Резервирование всего выделенного хоста может быть нерациональным. Используйте для резерва процент ресурсов, который чуть меньше, чем вклад каждого хоста в полный кластер, в отношении на суммарное количество хостов. Например, в четырех узловом кластере, каждый сервер вносит 25%, в этом случае можно установить процент резерва примерно 20 или 15%.

  5. Отсутствие приоритетов перезапуска VM.

    Если вы используете предложение из 4-го пункта, необходимо правильно настроить приоритет перезапуска VM, поскольку вы не будете резервировать ресурсы кластера для перезапуска ВСЕХ ваших виртуальных машин. Установите обычным ВМ низкий приоритет, а отдельным ВМ поднимите приоритет до среднего или высокого по мере необходимости.

  6. Отключение контроля за резервом (admission control).

    Плохая идея! Никогда, никогда, никогда не делайте этого! Включите опцию – «do not power on if inadequate cluster resources»

  7. Не изменение процента резервирования ресурсов.

    По мере добавления узлов в кластер необходимо пересчитать процент резервирования ресурсов, иначе система будет разбалансирована.

  8. Покупка разнородных серверов.

    Отказоустойчивость должна предусматривать вариант отказа самого большого сервера в кластере. Если есть кластер из шести серверов с 96 ГБ оперативной памяти, и затем вы добавляете сервер с 384 ГБ оперативной памяти, будут слишком разбалансированные расчеты для резервирования, и у вас останется много неиспользованных ресурсов.

  9. Изоляция хостов.

    Это запутанная тема для многих. До версии vSphere 5.0 в этой настройке можно было сделать ошибки, которые давали не совсем ожидаемые результаты. Можно на уровне хоста настроить отключение виртуальных машин при изоляции, но на уровне каждой конкретной виртуальной машины изменить настройки, если на ВМ есть критические приложения, для которых нужно убедиться, что их отключение не случайная ошибка. Начиная с версии 5.0 к настройке изоляции хоста добавились хартбиты хранилища, которые используются только в случае, если сеть хоста не доступна. Серверы в кластере должны иметь по крайней мере одно общее хранилище.

  10. Чрезмерное использование reservations, limits and affinities для ВМ.

    Используйте shares вместо reservations и ограничьте использование affinities (или anti-affinities) правил. Эти ограничения могут оказать влияние на производительность DRS. Используйте с осторожностью!

  11. Делать ограничение по памяти.

    Никогда не делайте это, никогда, никогда! Ограничивайте использования памяти с помощью приложений, если это возможно. Например, вы можете настроить SQL, чтобы ограничить объем памяти, который он будет использовать внутри гостевой виртуальной машины.

  12. Думать, что вы умнее, чем DRS.

    Ни один человек не может вычислить значения всех переменных и выдать правильный ответ. Пусть программное обеспечение делает свою работу.

  13. Не понимание правил DRS балансировки.

    Расчёты по DRS cлишком сложны

  14. Быть слишком либеральными.

    Миграция отнимает ресурсы, будь они пропускной способностью сети или процессорным временем. Не надо настраивать DRS для постоянном миграции рабочей нагрузки между серверами. Необходимо настроить пороги, чтобы сделать разумной миграцию, когда ресурсы действительно находятся вне баланса. vMotion было прикольным 5 лет назад, но сейчас нет необходимости постоянно двигать ВМ просто для забавы.

  15. Слишком много узлов кластера.

    Хотя технически ограничение на кластер 32 узла, но лучше использовать не более 16-24. Чем больше хостов, тем больше расчетов у DRS и все больше и больше потребление ресурсов.

  16. Создание больших виртуальных машин.

    Это новые значения в схеме лицензирования vSphere 5.0. Назначайте нужное количество памяти и виртуальных ЦП для ВМ. Не будьте слишком либеральны. Делайте правильный размер VM, не увеличивайте их ресурсы без необходимости.

Запись опубликована в рубрике Без рубрики. Добавьте в закладки постоянную ссылку.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Можно использовать следующие HTML-теги и атрибуты: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>