Я администратор баз данных и управляю кластером vmware ESX 3.5, на котором преимущественно размещаются SQL-серверы и несколько серверов приложений, и у меня есть вопрос о том, как настроить группы ресурсов, но я не согласен с одним из системных администраторов ESX по поводу управления ресурсами.
В кластере (3 узла, 32 ГБ на узел) в настоящее время размещено 33 гостя, настроенных на использование 77 ГБ ОЗУ, хотя ESX сообщает, что активны только 44 ГБ. В кластере размещаются действующие, тестовые серверы, серверы разработки и несколько других гостей.
Я бы хотел упростить управление ресурсами серверов и иметь возможность управлять производительностью связанных серверов и составлять отчеты о них.
Например, ресурсы, потребляемые (RAM, Disk, CPU) для серверов 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% необходимых ресурсов!»
Прежде чем я отвечу ему, могу ли я получить совет и проверить свои предположения:
Каковы ваши мысли и опыт ??
Если я правильно это понимаю, значит, вы правы в отношении нормальной работы вашей среды, но я не уверен, прав ли кто-либо из вас в отношении того, как это работает при возникновении разногласий.
Когда нет конкуренции (конкуренция начинается, когда использование ресурсов превышает 80% BTW), то акции не действуют. Итак, что касается обычных операций в вашей среде, группы ресурсов будут косметическими.
При возникновении конфликта ресурсы ЦП будут ограничены, как указал ваш системный администратор, но этого не произойдет, если вы потеряете хост.
Вы не говорите, изменили ли вы общие ресурсы в пулах дочерних ресурсов. Я предполагаю, что все они в норме.
Предполагая, что существует конкуренция, хотя способ работы общих ресурсов заключается в том, что каждый пул ресурсов получает долю ресурсов, равную его доле от общего количества акций на этом уровне. Для вашего первого уровня у вас есть ~ 58k долей, поэтому высокий пул получает примерно 56%, нормальный - 28%, Dev - 14%, а низкий - 1,7%. Внутри каждого пула субпулы совместно используют ресурсы этого пула в равной степени, если вы явно не установили дополнительные общие ресурсы на этом уровне, если у вас применяются те же правила, но общая сумма для пула остается неизменной.
Таким образом, в вашем случае при возникновении разногласий системы Live Sharepoint получат 50% из 28% ресурсов, то есть 14%.
Вы можете немного помочь в этом, выделив резервирование для абсолютных минимальных значений ЦП и ОЗУ, которые необходимы каждой системе. Зарезервированные значения гарантируются системам \ пулам ресурсов, которым вы их выделяете, и не распределяются по общим ресурсам. Их ключевой недостаток заключается в том, что, если значения слишком высоки, кластер может быть не в состоянии даже попытаться перезапустить виртуальные машины, поскольку ресурсы не могут быть гарантированы.
Также помните, что даже если ваши системы потребляют только ~ 44 ГБ при нормальной работе с системами Windows, 100% памяти выделяется (на короткое время) при запуске виртуальной машины. Это может вызвать конфликт за память во время аварийного переключения, даже если на самом деле оперативной памяти достаточно для запущенных систем. Это то, за чем нужно следить, а не слишком сильно беспокоиться, но это может вызвать проблемы во время перезапуска высокой доступности.
Отредактировано для добавления
Если вы не внесли изменений в настройки общего ресурса по умолчанию для отдельных виртуальных машин или дочерних групп ресурсов, то пропорция ресурсов, выделенных отдельным виртуальным машинам, не изменится, когда вы переместите все виртуальные машины на уровень выше в структуре, где есть только одна дочерняя группа ресурсов. и поместите их прямо в родительский. Однако, если существует несколько дочерних групп 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).
Конечно, если вы измените общие ресурсы дочерних групп ресурсов или отдельных виртуальных машин, все это изменится.
Определения ресурсов действуют только в кластере с избыточной нагрузкой.