Недавно я уже писал о теоретической экономической эффективности технологии Transparent Page Sharing (TPS). А теперь фактический пример.
Специально для иллюстрации смигрировал часть машин на один из хостов нового кластера: HP BL 490c G6, 2 * Xeon 5570, 64 GB RAM. Машин набралось ровно на 64 GB Granted.
Чистый выигрыш по памяти 32 GB. Consumed (т.е. +оверхед) 35 GB.
Память стоит HP модулями по 8ГБ. HP Product Bulletin утверждает, что стоимость одного модуля 1k$. Т.е. TPS уже отработала свое на 4k$.
Память стоит HP модулями по 8ГБ. HP Product Bulletin утверждает, что стоимость одного модуля 1k$. Т.е. TPS уже отработала свое на 4k$.
Consolidation ratio - 37. Но с такой статистикой можно доводить до 50 без всяких проблем.
Загрузка процессоров где-то 20%. По факту получается, что можно один процессор вообще вынуть и лицензия Enterprise Plus не то чтобы дорого получается, а еще и деньги приносит. Но TPS включена не только в Enterprise Plus, а доступна также и в Free ESXi.
Загрузка процессоров где-то 20%. По факту получается, что можно один процессор вообще вынуть и лицензия Enterprise Plus не то чтобы дорого получается, а еще и деньги приносит. Но TPS включена не только в Enterprise Plus, а доступна также и в Free ESXi.
А вдруг какая-то машина захочет памяти и все уйдет в своп?
Во-1, если у вас какая-то машина вдруг захотела много памяти и случилось непредвиденное – вы плохой системный администратор. Системы с высокими уровнями загрузки по памяти следует держать только при условии стабильности и предсказуемости нагрузки, в противном случае всегда нужно оставлять запас ресурсов под пиковые нагрузки.
Во-2, если машина захотела использовать много памяти, а физическая память кончилась, то опять же ничего страшного, неиспользуемую/неактивную память дополнительно отберут у других машин при помощи balloon driver.
В-3, подобный вопрос относится лишь к изданиями без VMotion и DRS, а в случае же с HA / DRS кластером у нас есть не только запас ресурсов под HA, но и автоматическая балансировка нагрузки. В итоге если какая-то машина захочет много ресурсов, то DRS ей их освободит или перебросит туда, где ресурсов достаточно. Если нет DRS (vSphere Advanced), то в данной роли выступит сисадмин и вручную перебросит машины.
В-4, для машин с высокими требованиями к доступной памяти никто не отменял резервирование :)
Во-2, если машина захотела использовать много памяти, а физическая память кончилась, то опять же ничего страшного, неиспользуемую/неактивную память дополнительно отберут у других машин при помощи balloon driver.
В-3, подобный вопрос относится лишь к изданиями без VMotion и DRS, а в случае же с HA / DRS кластером у нас есть не только запас ресурсов под HA, но и автоматическая балансировка нагрузки. В итоге если какая-то машина захочет много ресурсов, то DRS ей их освободит или перебросит туда, где ресурсов достаточно. Если нет DRS (vSphere Advanced), то в данной роли выступит сисадмин и вручную перебросит машины.
В-4, для машин с высокими требованиями к доступной памяти никто не отменял резервирование :)
Сообщения
8 коммент.:
DRS/DPM доступны в редакции Enterprise и Enterprise+
В Advanced роль DRS исполяет администратор.
:)))
В экзамене на VCP порадовал вопрос:
"Что делать, если у вас дико тормозит хост, и на все не хватает памяти"?
По-моему, самый правильный ответ был - выключите нафиг ненужные ВМ ;)
И тут внезапно в гостевые пришел windows update и все встало раком
Ну что ж, если у Вас на серверах Windows Update работает на автомате, то мне остается Вам только посочувствовать.
Вот то то и оно что замечательный функционал TPS за который заплатили денег еще от админа и лишних телодвижений по отслеживанию апдейтов требует.
А если у вас большая инфраструктура в которой сервер апдейтов администрирует один человек а хосты виртуализации другой?
Так и будете при каждом апдейте созваниваться?
ИМХО странная экономия по памяти выходит.
Во-1, если у вас какая-то машина вдруг захотела много памяти и случилось непредвиденное – вы плохой системный администратор.
Особенно хорошо если это не одна, а набор таких машин. Например девелоперы что то тестят. В общем как то слабо с предсказуемостью у Transparent Page Sharing получается.
>Вот то то и оно что замечательный функционал TPS за который заплатили денег
Он бесплатный, и доступен в Free ESXi.
>еще от админа и лишних телодвижений по отслеживанию апдейтов требует.
Надо же, админу занятие нашли, планированием ресурсов заниматься. Админ же должен спать, пиво пить и в игрушки играть.
>А если у вас большая инфраструктура в которой сервер апдейтов администрирует один человек а хосты виртуализации другой?
У меня да. И все отлично работает.
>Так и будете при каждом апдейте созваниваться?
Очень странная ситуация.
во-1, серверы у меня не обновляются автоматически, по команде WSUS и соотв. одновременно.
во-2, я не заметил 100% использования памяти в это время.
Виталий, ну вы хоть подписывайтесь. Неудобно с анонимусом разговаривать.
>Особенно хорошо если это не одна, а набор таких машин. Например девелоперы что то тестят.
У вас девелоперы что-то тестят прям на продакшн кластере? Я Вам искренне сочувствую.
Для тестов существуют тестовые кластеры, ресурс-пулы и лимиты. А для продуктивных машин существуют резервы.
>В общем как то слабо с предсказуемостью у Transparent Page Sharing получается.
Даже уже не смешно Ваши комментарии читать, честное слово.
Отправить комментарий