В конце прошлого года я участвовал в проекте миграции систем SAP на новую платформу, где, в частности, использовалась виртуализация. Так как до этого с продуктивным использованием сред виртуализации не сталкивался, а здесь пришлось достаточно глубоко погрузиться в эту область, я хочу поделиться своими знаниями.
Под средой виртуализации я имею ввиду продукты компании VMware. Для корпоративных систем, наверное, это самое распространённое решение по виртуализации.
Начнём с того, что SAP поддерживает виртуализацию для своих продуктов. Конечно, официально поддерживаются далеко не все продукты существующие на рынке, а в большей части только корпоративные и имеющие поддержку на уровне Enterprise. Список поддерживаемых и не поддерживаемых продуктов можно найти в SAP note 1122387 - Linux: SAP Support in virtualized environments.
Если кратко, то в продуктивной среде можно использовать:
- основанные на Xen, но в рамках корпоративных версий Linux и Citrix,
- основанные на KVM, но опять же в рамках Enterprise продуктов (SUSE, Red Hat, IBM и т.п.),
- линейку продуктов VMware от версии 5.x и выше,
- виртуализацию типа LPAR (логическое разбиение физического сервера на отдельные машины) от разных вендоров.
Точно не поддерживаются Microsoft Hyper-V, Virtual PC, Virtual Server, Oracle VirtualBox, Parallels Virtuozzo Containers, а также контейнеры от Linux (LXC, Docker). Отмечу, что в целях разворачивания обучающих систем, это всё можно смело использовать. И 80% их будет работать. Официальная поддержка относится к продуктивному использованию на боевых системах.
Теперь рассмотрим VMware. За одним этим словом скрывается огромный зоопарк различных систем и решений, который за более чем 20 лет существования компании разрастался, видоизменялся и переименовывался. Типичная конфигурация (рис. 1) представляет собой несколько физических машин, на которых устанавливается как операционная система специальное программное обеспечение - гипервизор. Гипервизор управляет ресурсами физической машины, распределяя их между работающими виртуальными машинами. У VMware гипервизор это продукт под названием ESXi сервер. В целом ESXi представляет собой узкоспециализированный дистрибутив Linux, который умеет рулить оборудованием и виртуальными машинами. VMware ESXi имеет очень небольшие требования к дисковому пространству, поэтому в качестве носителя может быть использована даже SD карта. После старта весь образ этой специфичной ОС хранится в оперативной памяти.
Накладные расходы (overhead) со стороны VMware ESXi минимальны, немного процессорных ресурсов и чуть-чуть оперативной памяти. :)
 |
| Рис. 1. Типовая схема виртуализации VMware. |
К серверам подключается один или несколько дисковых массивов. Причём, современные решения от разных вендоров имеют хорошую интеграцию с VMware, поддерживая различные фишки через общий API. Например, "тонкие виртуальные диски" на уровне СХД.
Стоит также отметить, что многие вендоры оборудования тесно работают с VMware и в плане серверного оборудования тоже. В результате на свои сервера поставляют собственные сборки VMware ESXi, куда интегрированы специфичные драйвера и патчи.
Стоит также отметить, что многие вендоры оборудования тесно работают с VMware и в плане серверного оборудования тоже. В результате на свои сервера поставляют собственные сборки VMware ESXi, куда интегрированы специфичные драйвера и патчи.
Сам по себе ESXi не имеет графического интерфейса: на экране консоли сервера после загрузки появляется минималистичная заставка, отображающая только IP адрес и hostname, по которому можно войти через http-интерфейс для управления средой виртуализации (рис. 2).
 |
| Рис. 2. Пример начального экрана консоли сервера с VMware ESXi. |
В консоли есть возможность перейти в настройки конфигурации по клавише F2 (в основном, доступны только настройки сети) и выключить/перезагрузить сервер (клавиша F12). Все остальные функции по управлению виртуальной средой осуществляются через web-интерфейс сервера ESXi. Для очень тонкой настройки есть возможность активировать доступ через ssh (по-умолчанию, доступ закрыт) и войти на сервер через удалённую консоль.
Компания VMware умеет прекрасно продавать свои продукты. За это перед ними снимаю шляпу. Наверное, поэтому web-интерфейс VMware ESXi имеет лишь базовый набор функций. Для получения полного функционала рекомендуется приобрести продукт под названием VMware vCenter Server, который разворачивается в виде отдельной виртуальной машины (внутри представляет собой опять же Linux). И вот уже его web-интерфейс (VMware vSphere Client) имеет больше возможностей. Например, можно делать шаблоны виртуальных машин, клонировать их или осуществлять глубокий мониторинг производительности. На ESXi мониторинг ресурсов ограничивается только текущим состоянием (последний час).
Компания VMware умеет прекрасно продавать свои продукты. За это перед ними снимаю шляпу. Наверное, поэтому web-интерфейс VMware ESXi имеет лишь базовый набор функций. Для получения полного функционала рекомендуется приобрести продукт под названием VMware vCenter Server, который разворачивается в виде отдельной виртуальной машины (внутри представляет собой опять же Linux). И вот уже его web-интерфейс (VMware vSphere Client) имеет больше возможностей. Например, можно делать шаблоны виртуальных машин, клонировать их или осуществлять глубокий мониторинг производительности. На ESXi мониторинг ресурсов ограничивается только текущим состоянием (последний час).
Несколько физических машин, каждая под управлением ESXi, могут быть объединены в кластер на уровне VMware. Машины в одном кластере должны иметь максимально похожие модели процессоров, а лучше вообще быть идентичны по всем параметрам. Поэтому для VMware конфигурации идеально подходят блейд-системы, когда на одном шасси функционирует несколько идентичных лезвий-серверов.
Другой продукт от компании VMware - vMotion позволяет переносить виртуальные машины между физическими узлами одного кластера. В случае ручного переезда останова гостевых операционных систем и приложений не происходит, пользователи процесса даже не замечают. То есть происходит, так называемая "живая" миграция (live migration).
В случае автоматического переезда, как в High-Availability решении, возможно два варианта:
- рестарт виртуальной машины на резервной ноде в случае падения на основной,
- "бесшовный" рестарт, который достигается за счёт использования решения VMware Fault Tolerance.
Во втором решении используется одновременная работа двух виртуальных машин на разных узлах с полной синхронизацией и горячее переключение на резервную в случае сбоя основной машины. У решения есть строгие ограничения по количеству виртуальных процессоров и жёсткие требования к инфраструктуре.
Лично я отношусь к VMware как к еще одному слою абстракции, который съедает определённые ресурсы для своей работы (overhead) и обязательно рано или поздно даст о себе знать дополнительной головной болью. В принципе, как и любое другое программное обеспечение.
Но, стоит признать и ряд несомненных плюсов в системе виртуализации. Во-первых, это абстрагирование виртуального сервера с операционной системой и SAP от физического сервера. Благодаря этому мы можем легко перенести систему на другое оборудование (при идентичности архитектуры конечно). При использовании "живой" миграции не нужно планировать downtime. Можно освободить физический сервер и провести на нём необходимые работы. Конечно, чтобы была такая возможность полностью освободить физический сервер от виртуальных машин, необходимо тщательно планировать ресурсы физических машин в кластере. Запас по ресурсам должен быть всегда.
Во-вторых, это лёгкость разворачивания новых серверов с SAP системами, путём клонирования/копирования существующих виртуальных машин или шаблонов. Если вы опять же оставите ресурсы в кластере, то можно создавать системы для тестирования и экспериментов. В частности, создавать машины для тестирования разворачивания резервных копий продуктивных систем.
В-третьих, так как виртуализация не любит зоопарка решений в плане физических серверов и архитектур, вам придётся унифицировать оборудование, что может в дальнейшем снизить расходы на администрирование и обслуживание.
Еще можно отметить возможность использования дополнительного уровня резервного копирования через сохранение всей виртуальной машины. Причем можно использовать функцию VMware - snapshot, которая позволит минимизировать время простоя приложения во время создания резервной копии.
Но при этом надо понимать, что виртуальная среда это идеальное решение когда у вас много маленьких виртуальных машин, а реализация огромных серверов будет затруднительна. Да и накладные расходы тут уже будут мешать. Если у вас требования к оборудованию одного сервера равны мощностям физического узла, то реализация такого сервера в виртуальной среде ни одного плюса не даст. А при съедании всех ресурсов большой виртуальной машиной ESXi скорее всего "встанет колом", потому что начнётся активный swapping и очереди к процессорным ресурсам.
На русском языке есть очень хорошая книга "Администрирование VMware vSphere 5" от Михаила Михеева. Самая последняя версия - 3-издание от 2012 года. Более свежей версии нет, так как автора взяли работать в VMware и он книгу обновлять перестал. :) Но для понимая всех продуктов книга подходит отлично. Поищите, в сети её найти можно.
Продолжение в этом посте.
Автор: Шиболов Вячеслав Анатольевич
