Virtualization in Real Life

Мне часто приходится общаться с заказчиками и видеть проекты связанных с виртуализацией на платформе x86. Я хотел бы поделиться некоторыми своими ощущениями и немного опытом: каковы особенности настройки СУБД в виртуализированном окружении, и вообще что дает виртуализация в итоге.

В качестве гипервизора я использую OracleVM for x86, хотя все идеи применимы к любой системе виртуализации.

Итак, вот ситуация из жизни реального заказчика из сегмента middle-бизнеса (фильм основан на реальных событиях, - любые совпадения абсолютно случайны :-) ):

- есть два приложения, которые сейчас работают каждое на своем сервере;
- первое приложение представляет собой систему учета персонала, этот софт разработан независимым поставщиком, работает под управлением Oracle Database версии 10.2 на Linux ;
- второе приложение было разработано собственными силами: использутся Oracle Database 11.2, Oracle HTTP Server 11.1 и APEX (все на платформе Windows x64), эта система автоматизирует вспомогательные бизнес-процессы в компании;
- от этих двух СУБД не требуется экстремальной производительности, и они не являются business-critical (допустимое время простоя измеряется парой часов).

Пришло время менять оборудование - серверы морально и физически устарели. Возникла идея разместить эти две СУБД на одном сервере с помощью виртуальных машин (производительности обычного 2-х сокетного сервера на последних процессорах Intel для этих задач вполне достаточно).

Только факты:
На сервере установлено 4 жестких диска:
- два SAS диска по 300 Гб (15000 об/м)
- два SATA диска по 2 Тб (7200 об/м)

Оперативная память - 16Гб.
Два сетевых интерфейса 1Гб/сек.

Каждая пара дисков была объединена в зеркало, таким образом имеется 300 Гб пространства на быстрых дисках и 2 Тб - на медленных.

Вообщем обычный и недорогой 2-х сокетный сервер начального уровня.


На первом этапе было спланирована структура виртуальных машин (каждая ВМ состоит из 4-х дисков):

Образ диска ВМ с операционной системой (файл system.img);
Образ диска ВМ с выполняемыми файлами (файл orahome.img);
Образ диска ВМ с файлами данных СУБД (размещен напрямую на физическом разделе быстрого жесткого диска);
Образ диска ВМ с файлами flash recovery area и архивными логами (размещен напрямую на физическом разделе медленного жесткого диска).

На сервер был установлен Oracle VM 2.2.1.

Быстрый жесткий диск был разбит на разделы (partitions) следующим образом:
1-ый раздел: 20Гб - для операционной системы Oracle VM (отформатирован);
2-ый раздел: 70Гб - (НЕ форматирован);
3-ый раздел: 70Гб - (НЕ форматирован);
4-ый раздел: 70Гб - (НЕ форматирован);
5-ый раздел: 70Гб - (НЕ форматирован).

Что касается медленного жесткого диска, то он был разбит вот так:
1-ый раздел: 750Гб - для хранения файлов образов ВМ (отформатирован);
2-ый раздел: 250Гб - (НЕ форматирован);
3-ый раздел: 250Гб - (НЕ форматирован);
4-ый раздел: 250Гб - (НЕ форматирован);
5-ый раздел: 250Гб - (НЕ форматирован);
6-ый раздел: 250Гб - (НЕ форматирован).


Думаю идея вам понятна: данные, к которым не требуется быстрого доступа, размещаются на дешевых и медленных SATA-дисках, данные к которым нужен быстрый доступ (файлы данных СУБД) - на дорогих и быстрых SAS-дисках. При этом, для увеличения скорости ввода-вывода в вмртуальном окружении, гостевая машина работает с данными необходимыми СУБД напрямую, - виртуальный диск напрямую размещен на физическом разделе быстрого жесткого диска).

Вот строки из конфигурационного файла гостевой машины:

disk = [
    'file:' + root_dir + '/system.img,hda,w',
    'file:' + root_dir + '/orahome.img,hdb,w',
    'phy:/dev/sda5,hdc,w!',
    'phy:/dev/sdb5,hdd,w!'
]

В свою очередь, внутри виртуальной машины, каждый диск, используемый напрямую, включен в ASM-группу. На каждой виртуальной машине создано две ASM-группы:
- ORADATA (монтирует раздел с быстрого диска);
- ORAFRA (монтирует раздел с медленного диска).

Использование ASM позволяет нам еще больше увеличить производительность ввода-вывода, поскольку устраняется уровень файловой системы.

С какой целью была сделана такая странная разбика дисков на разделы?

Если по ходу эксплуатации понадобится увеличение дискового пространства для файлов СУБД, то будет производится простое добавление свободного раздела в виртуальную машину с последующим добавленим нового виртуального диска в соотвествующую ASM-группу (oradata или orafra). Более того, если позволит мощность сервера, то можно легко запустить третью виртуальную машину дав ей свободные разделы. В результате, появляется гибкость в управлении дисками для виртуальных машин.

Рис. 1 Схема отображения физических дисков в виртуальные

После определения стратегии перехода в виртуализированное окружение, были созданы эталонные виртуальные машины. На первую установлена ОС Linux (OEL 5U5 x86) на вторую MS Windows x64. Установлено необходимое ПО Oracle. Произведен патчинг и настройка всего софта. Полученные "золотые" образы ВМ были после этого немедлено забэкапированы...
Собственно, дальше все как обычно: перенос данных СУБД с старых машин на виртуальные и переключение соответствующих приложений на два новых "сервера".

Рис. 2 Схема запуска виртуальных машин на аппаратном сервере
По признанию самих пользователей, - приложения стали работать быстрее ! :-)
Конечно в этом заслуга новых интеловских процессоров Xeon Nehalem.

Резервные копии ВМ также лежат на втором сервере (используется для тестирования и разработки), чтобы в случае сбоя основного сервера запустить виртуальные машины на резервном.

Что в итоге дала виртуализация:
- консолидация и уменьшение затрат на железо (вместо двух серверов закуплен тольно один);
- необычайная легкость создания тестового и development окружений: простым копированием образа ВМ на другой сервер мгновенно получаем готовое тестовое окружение в точности соотвествующее production-системе (копирование сырых разделов производится командой dd);
- обычные методы резервирования БД (копирование, экспорт-импорт) дополняются возможностью копированием целиком образа жесткого диска с файлами данных;
- бэкапировани ОС и бмнарных файлов теперь производится простым резервированием файлов образов system.img или oracle_home.img
- частичное бэкапирование образа при патчинге (если менялся только бинарный код, то резервировать нужно только виртуальные диски в файлах system.img и oracle_home.img, если менялись только данные - то наоборот: бэкапировать нужно только виртуальные диски с данными);
- если в будущем производительности сервера будет недостаточно для запуска 2-х виртуальных машин, то можно будет практически мгновенно "отвезти" одну гостевую систему на другой сервер;
- можно задавать приоритеты и распределение нагрузки между виртуальными машинами (если одна из них выполняет более приоритетную задачу);
- если в будущем все-таки понадобится обеспечить отказоустойчивость, можно будет ее обеспечить с помошью Live Migration;
- каждую виртуальную машину можно останавливать-запускать по отдельности (по расписанию).

После того, как я поглядел и "потрогал" все это, у меня родились какие-то новые ощущения.
А у вас ?
:-)