вторник, 2 июня 2009 г.

Bank

Недавно я был в гостях ИТ отдела одного из банков. Было очень интересно послушать людей, для которых внедрение виртуализации принесло кучу плюсов, которые весьма масштабно ее внедрили, и имеют свое апробированное мнение и рекомендации по вопросу.

Это - просто мой "отчет", что запомнилось и было интересно лично мне.

До виртуализации админы на работе сидели все время - то сервер привезут, надо вводить в эксплуатацию. То что то где то подкрутить.
Сейчас - месяцами в серверную не заходят.

Стало возможно не торопиться, и покупать то, что нужно, а не то, что есть у поставщика.

Виртуализация внедрялась помаленьку. Сначала она дала возможность консолидировать бюджет с различных мелких проектов в течении года, с целью закупки оборудования высокого уровня; а под проекты ресурсы выделять сразу, а не по истечении нескольких месяцев (согласования, выбор поставщика, размещение заказа, доставка, ввод в эксплуатацию)
После виртуализации потребление упало на ~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.
  • Итерацию повторить.
4.5 террабайта, и все виртуализованное железо за 2 дня перевезли, без простоя ВМ. У многих ВМ аптайм больше, чем существует новый ЦОД и само здание принадлежит банку(!).

Прочее, не виртуализованное железо ~ 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 комментариев:

  1. В целом очень позитивные впечатления.
    Чего я не понял:
    1) Почему не виртуализовывались сервера с большим объемом данных? Physical RDM вроде вполне нормально пробрасывает такие объемы;
    2) Почему Netbackup требует дополнительных людских ресурсов по сравнению с Veeam?

    ОтветитьУдалить
  2. С бэкапом странная ситуация...
    вим кроме виртуальных машин ничего бэкапить не умеет.. получается у них должно быть две разных системы резервного копирования и два набора лент... странно.

    ОтветитьУдалить
  3. Я не критикую и не придираюсь, но просто как то не сходится:
    - всего в платформе 25 серверов?
    - консолидайция 15-18 к 1 = 375-450
    - ферму citrix обслуживают 8 хостов - 34 ВМ с Citrix -> 5 к 1
    - большая часть из 250 ВМ -> 250/25 -> консолидация 10 к 1
    - с учетом цитрикса - (250-34)/(25-8) -> консолидация 13 к 1

    Опять получаем маркетинг... ;(

    Hitachi USP VM тоже под виртуализацию используют?
    Как разделены iops между хранилищами?

    ОтветитьУдалить
  4. Вопрос: 1) Почему не виртуализовывались сервера с большим объемом данных? Physical RDM вроде вполне нормально пробрасывает такие объемы
    Ответ: для работы RDM в нашем случае, необходимо либо поддержка NPIV (у нас ее нет), либо отдавать лун с данными гостевой системы всем ESX'ам.

    Вопрос: 2) Почему Netbackup требует дополнительных людских ресурсов по сравнению с Veeam?
    Ответ: Для работы Netbackup нужно выполнять ряд обязательных процедур, которые на наш взгляд ничем не обоснованны с точки зрения vmware. вот основные из них требующих постоянного сопровождения:
    - наличие реверсной зоны DNS (естественно и прямой) и обязательное ее поддержание в актуальной форме, т.е. адресам виртуальных машин должны соответсвовать hostname, которые отдают vmware tools. в нашем случае реверсная зона, за 13-ти летнюю историю нашего банка, была организованна впервые и только для этой задачи
    - обязательное описание каждой виртуальной машины в политиках бэкапа. учитывая то что виртуализация дала нам возможность более динамично изменять набор работающих серверов, это требует постоянное внимание и со стороны специалистов ответственных за бэкап.
    - ну и самое вопиющее, обязательное условие для прохождения бэкапа статус vmware tools должен быть в состоянии "OK". Т.е. после апгрейда esx'ов, которые выходят в среднем раз в 3-4 месяца Вы остаетесь без бэкапа, пока не обновите тулзы на гостевых системах (мы не можем себе позволить ребут 260 серверов каждые 3 и даже 6 месяцев). Соответственно если тулзы для гостевой системы не предусмотрены, то бэкап ее производиться не будет.
    - есть еще ряд нюансов, но они более мелкие.
    И это в системе СРК за 1 000 000$ ;-)
    В итоге нетбэкапом мы заматываем на ленты то что получается от veeam. Veeam обещает в будущем агента для NetBackup.

    Вопрос: С бэкапом странная ситуация...
    вим кроме виртуальных машин ничего бэкапить не умеет.. получается у них должно быть две разных системы резервного копирования и два набора лент... странно.

    Ответ: набор лен один и его пользует Netbackup. мы используем 3-х уровневую систему бэкапа. данные -> HDD-staging -> лента

    Вопрос: Я не критикую и не придираюсь, но просто как то не сходится:
    - всего в платформе 25 серверов?
    - консолидайция 15-18 к 1 = 375-450
    - ферму citrix обслуживают 8 хостов - 34 ВМ с Citrix -> 5 к 1
    - большая часть из 250 ВМ -> 250/25 -> консолидация 10 к 1
    - с учетом цитрикса - (250-34)/(25-8) -> консолидация 13 к 1

    Ответ: Коллеги не забываем про то что физическая утилизация систем не должна достигать 100%. у нас рабочая нагрузка 60%. граница добавления новых серверо в фермы - 80%.
    Консолидацая цифра обобщенная, все зависит от класса виртуализованных систем местами она 25 к 1, местами 5-6 к 1.

    Вопрос: Hitachi USP VM тоже под виртуализацию используют?
    Как разделены iops между хранилищами?
    Ответ: мы используем виртуализацию почти во всех возможных ее проявлениях СХД, Itanium&RISC, SPARC, x86.
    Массив Hitachi USP VM это хай-енд массив с достаточно широкими возможностями, ее родной брат HP XP20000. Имхо это тема не для данного блога ;-)

    ОтветитьУдалить
  5. Круто! Респекты Мичигану и Фостеру!

    ОтветитьУдалить
  6. Foster, насколько я знаю, именно так RDM и раздается: лун с данными отдается всем ESX. Косяк в том, что другие хосты не знают, что это RDM лун. Вроде бы это поправлено в vSphere - лун можно подписать.

    Вряд ли это Сбер - банку 13 лет. Скорее всего, НБ "Траст".

    ОтветитьУдалить
  7. Это точно не сбер... Во всех Сберах обратные зоны есть... ;-)

    Фостер: спасибо за ответы.

    Про цитрикс ферму подробностей расскажете?
    - Какая версия продуктов?
    - Количество одновременных сессий?
    - Загрузка процессоров и памяти?
    - Средний объем памяти на одну сессию?

    И еще вопрос, как-нибудь меряли падение производительности приложений?

    Когда будете внедрять vdi? ;-) Нам ваш хеппи-стори ой как нужен...

    ОтветитьУдалить
  8. Это Траст ребята:)

    ОтветитьУдалить
  9. 2Denis Baturin>
    - Citrix PS4.5 ent
    - ~1700 и увеличивается в связи с переходом на новую АБС по филиалам
    - 1vCPU+3840Mb = ~70 сессий
    деградации работы приложений замечено не было

    VDI скорее всего внетдрять не будем, т.к. стратегическая цель отнять у юзеров десктоп в принципе. Оставить только seamless-приложения в Citrix.

    ОтветитьУдалить
  10. Вопрос:
    1. Cколько % осталось не виртуальных машин?
    2. Виртуализованы ли базы данных , есле да то какие MSSQL/Oracle?

    ОтветитьУдалить
  11. И еще очень интересно, как удалось достичь такого большого количества одновременных сессий на терминальном сервере, обычно больше 35 это проблема. Особенно в контексте утилизации процессора.

    ОтветитьУдалить
  12. Зависит от приложения в Citrix - при указанном обьеме памяти 70 сессий не проблема, при условии что приложение не очень тяжелое. Мой потолок это 100 сессий на железку - уперлись в память, по CPU непаханное поле.

    ОтветитьУдалить
  13. Т.е. если сравнить виртуальные сервера с 1 vCPU:
    1. Win 2003 + дефолтная терминальная служба
    2. Win 2003 + Citrix

    При одинаковых приложениях Citrix может держать одновременных сессий больше ?

    P.S. У меня, в первом варианте, при Office 2003, IE 7 и не тяжелом приложении сейлов, после 35 сессий, начинается постоянная утилизация процессора на 100% (2.66 Ghz ядро). Выше 40 сессий тормоза.
    Причем все приложения потребляют по-немногу, отдельных всплесков нет.

    ОтветитьУдалить
  14. если это банк Траст , то бугогааа ... это у них там всё красиво на бумаге .. реально всё работает через жопу ... клиенты толпами уходят , говоря , что надоело ждать когда все заработает ...

    ОтветитьУдалить

Примечание. Отправлять комментарии могут только участники этого блога.