Ресурсные группы ESX 3.5

Я являюсь администратором баз данных и управляю кластером vmware ESX 3.5, в котором преимущественно размещаются SQL-серверы и несколько серверов приложений, и у меня есть вопрос о том, как настроить группы ресурсов, но я конфликтую с одним из системных администраторов ESX о том, как управлять ресурсами.

В кластере (3 узла, 32 ГБ на узел) в настоящее время размещено 33 гостя, настроенных на использование 77 ГБ ОЗУ, хотя ESX сообщает, что только 44 ГБ активно. В кластере размещаются живые, тестовые серверы, серверы разработки и несколько других гостей.

Что я хотел бы сделать, так это упростить управление ресурсами серверов и иметь возможность управлять и сообщать о производительности связанных серверов.

Например, потребляемые ресурсы (ОЗУ, диск, ЦП) для серверов Live SQL, серверов SharePoint, серверов CRM и т. Д.

Затем я создал 4 группы ресурсов "верхнего уровня".

1-High    - For the most mission critical services (ie. the live SQL server)
  32768 memory shares
2-Normal  - For the majority of the remaining live systems (CRM, Sharepoint etc)
  16384 memory shares
3-Dev     - Test and development systems
  8192 memory shares
4-Low     - Non supported servers (no sla, temporary build servers etc)
  1024 memory shares

Я сгруппировал серверы в свои собственные группы ресурсов приложений (SQL Live, SQL Test, CRM Live, CRM Test и т. Д.), Но не установил каких-либо явных ограничений ресурсов для этих групп.

Затем я помещаю группы "приложения" в соответствующую группу ресурсов "верхнего уровня".

Например, каждая подгруппа имеет 4 гостя, каждый 1 процессор и 1 ГБ оперативной памяти

1-High               32768 shares
    SQL Live         4 guests
2-Normal             16384 shares
    CRM Live         4 guests
    Sharepoint Live  4 guests
3-Dev                16384 shares
    CRM Test         4 guests
    SQL Test         4 guests
    Sharepoint test  4 guests
4-Low 
    Remaining cruft  4 guests

Парень сисадмина говорит мне, что "Sharepoint получит только 28% из 50% ресурсов, которые ему нужны!"

Прежде чем я отвечу ему, могу ли я получить несколько советов и проверить мои предположения:

  • При нормальной работе кластер не перегружает ОЗУ (или ЦП), поэтому ограничения на ресурсы не применяются к любому гостю, будь то ЦП или ОЗУ.
  • В случае сбоя одного из хостов будет доступно только 64 ГБ ОЗУ. После перезапуска гостей (у нас включены HA и DRS), остальные хосты начнут перезапускать гостей, и это приведет к перегрузке ОЗУ.
  • Я хочу, чтобы сервисы с наивысшим приоритетом сохраняли свой сервис
  • Я не хочу микроуправлять каждым отдельным гостем!

Каковы ваши мысли и опыт??

Источник

2 ответа

Решение

Если я правильно читаю это, то вы правы в отношении нормальной работы вашей среды, но я не уверен, правильно ли кто-либо из вас работает, когда возникает конфликт.

Когда нет конфликта (конфликт начинается, когда использование ресурсов превышает 80% BTW), тогда акции не имеют никакого эффекта. Таким образом, что касается нормальных операций в вашей среде, группы ресурсов будут косметическими.

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

Вы не говорите, изменили ли вы общие ресурсы в дочерних пулах ресурсов. Я собираюсь предположить, что они все установлены в нормальное состояние.

Предполагая, что существует конфликт, хотя способ использования общих ресурсов заключается в том, что каждый пул ресурсов получает долю ресурсов, которая равна его доле от общего количества акций на этом уровне. Для вашего первого уровня у вас есть ~58 тыс. Акций, так что High Pool получает около 56%, обычный получает 28%, Dev получает 14%, а Low получает 1,7%. В каждом пуле подпулы распределяют ресурсы этого пула в равной степени, если только вы явно не задали дополнительные ресурсы на этом уровне, если применяются те же правила, но общая сумма для пула остается неизменной.

Таким образом, в вашем случае, когда возникает конфликт, системы Live Sharepoint получат 50% от 28% конкурирующих ресурсов, то есть 14%.

Можно несколько помочь, выделив резервирование для абсолютных минимальных значений ЦП и ОЗУ, которые нужны каждой системе. Зарезервированные значения гарантируются системным пулам ресурсов, которым вы их распределяете, и не распределяются по общим ресурсам. Ключевой недостаток с ними заключается в том, что если значения слишком высоки, кластер может даже не попытаться перезапустить виртуальную машину, поскольку ресурсы не могут быть гарантированы.

Также помните, что даже если ваши системы потребляют ~44 ГБ при нормальной работе с системами Windows, 100% памяти (кратко) выделяется при запуске виртуальной машины. Это может вызвать конфликтный сценарий для памяти во время восстановления после сбоя, даже если оперативной памяти достаточно для систем, когда они работают. За этим нужно следить не только за беспокойством, но и при перезапуске HA.

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

В вашем примере, скажем, у нас есть 4 виртуальные машины Sharepoint в их дочерней RG и 2 виртуальные машины CRM в их дочерней группе. Виртуальные машины Sharepoint получают ~3,5% каждая (50% от 28% / 4), а виртуальные машины CRM получают 7% каждая (50% от 28% /2). Если вы теперь переместите все их в родительскую RG и удалите пустые дочерние RG, у вас теперь есть 6 виртуальных машин, которые совместно используют 28% ресурсов, доступных для обычной RG, и каждая из них получит ~ 4,7% (28% / 6).

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

Источник

Определения ресурсов вступают в силу только в перегруженном кластере.

Источник
Другие вопросы по тегам