Сообщения
Недавно я был в гостях ИТ отдела одного из банков. Было очень интересно послушать людей, для которых внедрение виртуализации принесло кучу плюсов, которые весьма масштабно ее внедрили, и имеют свое апробированное мнение и рекомендации по вопросу.
Это - просто мой "отчет", что запомнилось и было интересно лично мне.
До виртуализации админы на работе сидели все время - то сервер привезут, надо вводить в эксплуатацию. То что то где то подкрутить.
Сейчас - месяцами в серверную не заходят.
Стало возможно не торопиться, и покупать то, что нужно, а не то, что есть у поставщика.
Виртуализация внедрялась помаленьку. Сначала она дала возможность консолидировать бюджет с различных мелких проектов в течении года, с целью закупки оборудования высокого уровня; а под проекты ресурсы выделять сразу, а не по истечении нескольких месяцев (согласования, выбор поставщика, размещение заказа, доставка, ввод в эксплуатацию)
После виртуализации потребление упало на ~40% (81 кватт). Это только сервера, без охлаждения.
Консолидация 15-18 к 1.
Сервера - блейды.
1 лезвие - 2*4 ЦП, 32 ГБ ОЗУ.
1 ВМ обычно 2-4 ГБ ОЗУ. Некоторые ВМ обслуживают до 5000 человек.
DPM позволяет выключить 4 из 25 серверов(в рабочие часы). По ночам потребление падает с 4.5 до 1.5 КВатта на шасси. Используются 2 шасси.
Используется ферма Citrix до 1700 пользователей одновременно. Ферму обслуживают 8 хостов, хватило бы 4.
34 ВМ с Citrix.
Переезд.
Банк переезжал в другое здание. Между старым и новым зданием положили оптику. СХД там и тут. Привезли одно шасси(пустое), два(с лезвиями) оставили на старом месте.
- Там освободили три лезвия, перевезли.
- Storage vMotion, потом vMotion.
- Итерацию повторить.
Прочее, не виртуализованное железо ~ 70 серверов, перевозили больше недели, 7 рабочих дней.
Нагрузка.
Большая часть из 250 ВМ показывают нагрузку на ЦП порядка 130-250 МГЦ. Например, мне продемонстрировали сервер Lotus, пересылающий 5000 писем в минуту - 247 МГЦ.
2х, 4х процессорных ВМ избегать всеми силами. Если уж 1 вЦП не хватает - даем 2ой, и смотрим - не стало ли хуже.
Сталкивались с интересным багом конкретной софтины -
ВМ с ней, у ВМ 2 вЦП, выданы изначально, по аналогии, т.к. софтину переносили с двухпроцессорного сервера. Заходит первый пользователь - все хорошо. Заходит второй - все ложится. Что то не срасталось в связи с тем, что и ESX пытался нагрузку сбалансировать, и гостевая ОС, и что то софтине не нравилось. Оставили 1 вЦП - все замечательно заработало.
Соображение "чем больше сервер, тем больше на нем ВМ" - не обязательно верно. Можем упереться в шину к памяти.
I\O.
Все ВМ генерят ~ 30 000 I\O. Это 240 дисков, массивы RAID 50, каждый 4 группы по 7 дисков.
Типичный ЛУН ~ 1 ТБ, как раз на 30 ВМ.
mid range СХД ложится под их нагрузкой, сначала по контроллерам, потом по дискам.
high end СХД лучше за счет контроллеров. Их больше, сложнее архитектура. И они умнее - например, позволяют выделять кеш под какие то RAID-группы (LUN'ов в RAID-группе может быть несколько). Они позволяют динамически перераспрелелять ресурсы массива между задачами без остановки самого массива и этих задач.
mid range - AMS1000 Hitachi, HP Eva, EMC Clarion.
high range - USP VM Hitachi, HP XP 20000.
round robin однозначно противопоказан на mid range-системах, и на момент использования ESX 3.5Update 4 имелись проблемы с использованием на high end-системах
написали скрипт, который прописывал предпочитаемый путь для каждого ЛУНа, равномерно.
Желательно выделять raid группы под ESX, убирая физические сервера на другие raid группы. В частности, это очень правильно для разбора статистики, иначе очень тяжело понимать статистику по SAN.
Рекомендации - до 30 ВМ на ЛУН, до 8 хостов к ЛУНу. Опыт показал что это хорошо.
Начиная с 3.5 используются дефолтные настройки для ESX. Разве что, скриптами настраиваются VLAN и пути к ЛУНам.
VCB.
1 сервер. Поставили второй, для сокращения окна бекапа.
Работает отлично. Бекапят vmdk целиком. В основном, потому что сервера с большими объемами данных(файл сервера, архивы и почтовые ящики Lotus, СУБД) не виртуализировались - обратите внимание, не виртуализировались они не из за нехватки ресурсов, а чтобы их данные(~ 1.5 ТБ для сервера) не запихивать в vmdk или RDM. Для бэкапа была выбран Veeam Backup, т.к. veritas netbackup требует необоснованно слишком много дополнительных людских ресурсов для сопровождения резервного копирования виртуальных машин. Так же получили ряд плюсов достаточно эффективная дедупликация и компрессия налету, высокие скорости бэкапа как по LAN так и по SAN, возможность восстановления отдельных файлов гостевых ОС из vmdk.
Прогноз.
На данный момент готовятся к апгрейду на vSphere 4.
16 коммент.: