Следуя за инновациями в ИТ, а иногда — просто за модой, украинские компании бросились неустанно переводить бизнес на технологии виртуализации. Однако, лишь немногие получают необходимую отдачу после такого перехода. Какие ошибки отдаляют ИТ-специалистов от широчайших возможностей виртуализации и как их избежать?

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

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

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

• Третья и, по совместительству, четвертая проблема — неправильный сайзинг конечных виртуальных машин, а также нехватка ресурсов некоторых компонентов.

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

• Шестая проблема касается, в основном, крупной ИТ-инфраструктуры и подразумевает невозможность предсказать будущие проблемы и критические точки инфраструктуры. К счастью, всем вышеперечисленным ошибкам есть объяснение и «противоядие».

Шаг первый. Борьба с неправильным распределением ресурсов

Первостепенное внимание стоит уделить проблеме неправильного распределения ресурсов и сайзингу. Вопрос актуален даже при небольших инфраструктурах, где виртуализированы 2-3 хоста и 10 виртуальных машин. В таких инфраструктурах система хранения данных (СХД) занимает второе место по степени использования ресурсов после оперативной памяти. И если оперативную память легко нарастить, то для СХД необходимо докупать дорогостоящие полки расширения и дополнительные диски. Для решения вышеуказанной задачи можно предложить две интересные технологии.

Первая — технология тонких дисков (thin provisioning). Вопреки распространенному мнению, сегодня не следует бояться тонких дисков, их функционал полностью пересмотрен и расширен. Вторая технология — storage tearing, позволяющая повысить производительность дисковой системы конечных сервисов. Это многоуровневая модель работы с СХД, которая использует несколько типов дисков с разной производительностью и объемами. При высокой производительности дисковой подсистемы можно переносить файлы виртуальной машины между различными СХД в ручном режиме либо автоматизировать данный процесс с помощью гипервизоров, которые предлагают вендоры.

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

Шаг второй. Правильная конфигурация

После того как повышена дисковая производительность, сэкономлено место и средства на СХД, ИТ-специалистам важно не потерять бдительность в «паутине» конфигураций.

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

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

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

Необходимо также обращать внимание на использование «правильных» виртуальных устройств. Шаблоны, созданные по рекомендациям вендоров, не обязательно будут соответствовать требованиям и ожиданиям конкретной компании. Гарантирована работа ОС, но не конечного приложения. Если не хватает, например, сетевых ресурсов, нужно вспомнить, что у всех гипервизоров уже давно реализована поддержка различных типов и моделей виртуализованных сетевых адаптеров, вплоть до поддержки устройств 10 Гбит/с для конечных ВМ. Но даже при наличии такой поддержки, ни в одном шаблоне по умолчанию этих адаптеров нет. То же самое касается и некоторых других настроек. Соответственно, при правильной конфигурации «железа» виртуальных машин можно получить дополнительную производительность конечных сервисов.

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

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

Шаг третий. Оптимизация операционных расходов

В ходе работы с ИТ-инфраструктурой возникает вопрос оптимизации операционных расходов на ее администрирование и содержание.

Говоря об администрировании, стоит отметить, что с ростом инфраструктуры, количество сервисов и виртуальных машин стремительно возрастает, что влечет за собой сложность определения «что и где находится». Ощутимая проблема возникает, когда основной сервис, состоящий из большого набора виртуальных машин, необходимо перезапустить по определенным параметрам. ИТ-специалист должен понимать, что именно перезапускать, в каком порядке, какие сервисы нужны и чего ждать от перезапуска. Также, необходима оперативная реакция для миграции сервиса в короткие сроки, в случае его падения или при недостатке ресурсов инфраструктуры для корректной работы сервиса. Это те операционные задачи, которые занимают много времени ИТ-специалистов и, к сожалению, они не всегда знают, что эти процессы довольно просто оптимизировать.

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

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

Кроме повышения утилизации, присутствует также проблема небольшой периодичности работы этих сервисов — 99% инфраструктур в определенные моменты не используются в полную силу. В таком случае серверы загружены не полностью, обеспечена избыточная отказоустойчивость, повышено энергопотребление систем охлаждения и т. д. Соответственно, ресурсы тратятся впустую. Для решения проблемы у гипервизоров уже есть готовый функционал управления электропитанием и объемами. Идея в том, что если гипервизор видит падение активности на серверах, часть из них он переводит в ждущий режим. В данном режиме серверы потребляют в десятки раз меньше энергии, охлаждение не требуется. Благодаря этому, на остальных компонентах повышается серверная утилизация, а на серверах в режиме stand-by уменьшается энергопотребление и увеличивается срок жизни компонентов, просто потому что они не используются.

Конечно, стоит упомянуть и о позиции ИТ-специалистов, которые при включении автоматического управления жалуются на то, что критический сервис начал потреблять много ресурсов, а серверы не поднялись вовремя. Такие жалобы появляются у тех, кто не умеет правильно конфигурировать сервис. По умолчанию, у гипервизоров стоит определенный таймаут на отключение серверов, который измеряется часами. К примеру, у Citrix и VMware этот таймаут составляет порядка 8 часов. Поэтому гипервизор примет решение по переводу сервера в «ждущий режим» только на основании 8- часовой статистики. Существуют также обратные счетчики по «возвращению» хостов в строй (например, у Citrix и VMware они определяются минутами). То есть, при возникновении лавинообразной нагрузки на серверы в течение нескольких минут, серверы автоматически начнут «подниматься» из режима stand-by.

Но есть еще один момент — многие забывают, что кроме автоматического функционала есть ручной режим. ИТ-специалист, зная время «лавины» (прежде всего это касается ситуаций, когда в компании четкий регламент рабочего дня), может задавать время «пробуждения» в ручном режиме. Соответственно, когда пойдет высокая нагрузка, серверы будут готовы к росту производительности.

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

Автор статьи — архитектор облачных технологий компании IT-Solutions