Инженерная инфраструктура центров обработки данных (ЦОД)

На самом деле можно выделить три основных подхода виртуализации:

• Консолидация серверов с целью повышения степени утилизации
• GRID-вычисления для сложных, тяжелых приложений
• Виртуализация рабочих мест

     Пройдемся по всем трем, и я дам некие свои комментарии, как я вижу это со стороны заказчика. Смотрите видео.

Консолидация серверов — надо строить кластер

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

GRID вычисления могут сократить время простоя

Основная задача – обеспечить большой пул ресурсов. Ни для кого не секрет, есть сложные, ресурсоемкие приложения, сервера баз данных и они постоянно требуют под себя ресурсы. Постоянно докупать сервера и мигрировать на них, бизнес далеко не всегда на это готов идти, тем более получаются высокие затраты на миграцию с одного оборудования на другое. Гораздо проще построить некий аппаратный стек, который будет позволять добавлять этому приложению или базе данных ресурсов столько, сколько надо. Здесь можно отметить, несмотря на реализацию этой идеи «ресурсов столько, сколько надо», у нас получится неполное использование ресурсов, по той простой причине, что любое приложение в своем жизненном цикле имеет пиковые нагрузки. Применительно к банковской отрасли, конец года — это просто пожирание огромное ресурсов, потому что годовые отчеты перед акционерами, перед регуляторами, подсчет финансовых результатов, наш ОБС, оно съедает очень много ресурсов. И, несмотря на замечательные возможности балансировки ресурсов, как правило, на практике, если мы кому-то отдали ресурсы какого-то приложения, то обратно мы их уже не забираем, потому что реально это не надо. Еще другой аспект, который здесь может быть, который присутствует и при консолидации серверов – это переезд с одного набора оборудования на другое. Для тяжелого набора приложений эта проблема более актуальна, чем в случае с консолидацией. Могу привести пример из практики: нам нужно было произвести апгрейд оборудования для одной из наших СУБД, в принципе, если не считать времени, потраченного администраторами на развертывание инфраструктуры, на тестирование, на какие-то тестовые прогоны, сам переход занял через backup и restore всего лишь 6 часов. В принципе, на выходных можно выйти и сделать. Проблема была только одна: на эту базу у нас был завязан некий клиентский сервис, который мы предоставляем 24 х 7. И 6 часов простоя достаточно не маленькие потери для бизнеса и, несмотря на то, что мы это сделали и уложились в расчетное время, перешли без сбоев, нам было высказано некое «фи». В случае использования GRID-вычислений у нас время простоя составило бы максимум минут 10. И это время ушло бы на выключение виртуальной машины на одном оборудовании и перенос- включение на другом. Согласитесь, время несопоставимо.

Виртуализация рабочих мест

Третье направление, которое интересно и актуально, — это виртуализация рабочих мест. С одной стороны, с точки зрения поддержки инфраструктуры, решение само по себе замечательное. Несчастные специалисты по поддержке рабочих станций перестают постоянно бегать по офису, разбираться с приложениями на местах, с проблемами и уходят уже в консоль. Опять же, собирая в виртуальной среде рабочие станции, мы понижаем риски по утечке информации. Ни для кого не секрет, что сейчас есть масса способов унести с локальной станции. Здесь же мы можем более четко и более жестко контролировать ресурсы, доступ, ограничивать возможность пользователей сунуть какое-то устройство в рабочую станцию и что-то попытаться слить… и так далее и тому подобное. Здесь одним из ограничений является то, что стоимость серверных ресурсов, выделяемых под виртуализацию, пока еще дороже, чем приобретение самой рабочей станции. На мой взгляд, ценовая разница пока еще не настолько велика, чтобы заинтересовать бизнес. Потому что мы все-таки делаем некий просчет этого проекта, и пока то на то и выходит, к сожалению.

Ограничения виртуализации — лицензирование

Еще я хочу затронуть такой вопрос, как ограничения при виртуализации, потому что на самом деле решений много и решения классные, но у них есть на мой взгляд некоторые недостатки. В одном из своих проектов мы столкнулись с тем, что с начала мы виртуализировали нечто, а потом, внимательно перечитав лицензионное соглашение с поставщиком, вынуждены были просто купить оборудование, поставить туда софт и использовать. Поэтому такое ограничение на данный момент есть. Хотя заключаются различные партнерские соглашения, которые позволяют избежать таких коллизий. Следующая вещь, с которой мы столкнулись на своей практике, это всевозможные средства защиты приложений: аппаратные ключи, токены, гардены и так далее. Приходится приобретать дополнительные устройства, дополнительные лицензии, чтобы это поддерживалось в виртуальной среде, и это надо учитывать при расчете проекта.

Обращайте внимание на порядок запуска приложений

Про нагруженные приложения я уже сказал, еще один аспект, на который тоже хочется обратить внимание, — это инфраструктурные сервисы. Первым позывом администраторов бывает загнать их в первую очередь в виртуальную среду, но потом выясняется, что далеко не всегда это хорошо. В случае каких-либо отключений, сбоев бывает нарушен порядок запуска и нам приходится снова стартовать нашу инфраструктуру. Спасибо за внимание, готов отвечать на ваши вопросы.

     Владимир Витальевич Лавриненко, ЗАМЕСТИТЕЛЬ ДИРЕКТОРА ДЕПАРТАМЕНТА ИТ, ЕВРОПЕЙСКИЙ ТРАСТОВЫЙ БАНК