Словарик: оверселлинг - когда продаётся больше ресурсов, нежели реально возможно предоставить, по очень грубым подсчетам, в настоящее время хостерами продано в 10 раз больше ресурсов нежели имеется аппаратной мощности домен - читай операционная система гипервизор - система запуска всех доменов dom0 - основной домен domU - гостевые домены Привет. В этой статье я бы хотел сделать небольшое how-to если Вы хотите сделать профессиональную систему виртуализации. Хотелось бы поделиться опытом, так как русской документации(АКТУАЛЬНОЙ!) на эту тему очень и очень немного и приходилось по крупицам собирать с рассылки [email protected]. Если Вы планируете профессионально этим заниматься, обязательно подпишитесь. Xen -- это монитор виртуальных машин (VMM, Virtual Machine Monitor) или гипервизор (hypervisor) с поддержкой паравиртуализации (para-virtualization) для процессоров x86 архитектуры, распространяющийся с открытым исходным кодом (opensource). Xen может организовать совместное безопасное исполнение нескольких виртуальных машин на одной физической системе с производительностью близкой к непосредственной (native). Виртуализация будет сделана на базе xen, что обеспечивает максимальную эффективность использования ресурсов, проверено моим опытом. Xen обладает функциональностью ПО корпоративного уровня. Плюсы: Минусы: В первую очередь важно знать, что работа может производиться в HVM режиме и в режиме паравиртуализации. HVM режим должен поддерживаться процессором, запуск некоторых систем(Windows, FreeBSD) возможен только в HVM режиме. Паравиртуализация - это запуск системы с измененным ядром. Загрузка системы xen отличается от обычной: запускается XEN - гипервизор, который стартует основную систему (сравните, обычно система загружается сама первой а затем только стартуются прикладные программы). Далее после старта основной системы можно запускать гостевые домены. Я испробовал Suse, CentOS, Debian и отдал предпочтение Debian Lenny в качестве хост системы. Самый простой вариант - запуск в режиме паравиртуализации: Устанавливаем необходимые пакеты: # aptitude install xen-tools libc6-xen Все остальное подтянется автоматически по зависимостям. Ставим XEN ядро: # aptitude install xen-linux-system-2.6.26-1-xen-686 Все нормально установилось из репозитариев, перезагружаемся с новым ядром. Далее в файле /etc/xen/xend-config.sxp нужно раскомментировать строку network-script network-bridge, чтобы мы могли гостевым системам выдавать ip адреса из нашей локальной сети. Создавать образы гостевой системы мы будем с помощью утилиты xen-tools. Сначала настроим ее. Для этого нужно поправить /etc/xen-tools/xen-tools.conf примерно так: dir = /home/xen # Каталог, куда будут помещены созданные образы install-method = debootstrap # построить систему, с помощью утилиты debootstrap size = 8Gb # Размер образа memory = 512Mb # Сколько оперативной памяти выделяем swap = 512Mb # Размер swap файла fs = ext3 # Какую файловую систему создавать dist = lenny # Какой дистрибутив устанавливать image = sparse # Делает размер образа таким, сколько места реально занято kernel = /boot/vmlinuz-`uname -r` # Использовать ядро основной системы initrd = /boot/initrd.img-`uname -r` # Использовать initrd основной системы mirror = http://mirror.yandex.ru/debian/ # С какого зеркала debootstrap будет брать пакеты ext3_options = noatime,nodiratime,errors=remount-ro # Опции монтирования файловой системы serial_device = hvc0 # Чтобы можно было попасть в консоль гостевой системы с основной Создаем каталоги, куда будут помещаться созданные образы: # mkdir /home/xen # mkdir /home/xen/domains Создаем образ виртуальной машины: # xen-create-image --hostname=guest1 --ip=10.32.0.136 --netmask=255.255.252.0 --gateway=10.32.0.1 --passwd --role udev Утилита xen-tools создаст нам образ гостевой системы на базе Debian lenny с указанными в командной строке сетевыми настройками, спросит пароль для root и создаст конфигурационный файл виртуальной машины. Нам его нужно подправить, так как по крайней мере в XEN версии 3.2 существует ошибка синхронизации времени гостевой системы с основной. Из-за этого в определенных случаях виртуальная машина прекращает работать, выдавая на консоль что-то вроде такого: [134923.954606] clocksource/0: Time went backwards: delta=-6917269595673126078 shadow=134923109294656 offset=845310074 [134928.952308] printk: 1154382 messages suppressed. [134928.952323] clocksource/0: Time went backwards: delta=-6917269590675409336 shadow=134928109321066 offset=842999953 Наш конфиг /etc/xen/guest1.cfg должен выглядеть примерно так: kernel = '/boot/vmlinuz-2.6.26-1-xen-686' ramdisk = '/boot/initrd.img-2.6.26-1-xen-686' memory = '512' vcpus = 2 extra = 'clocksource=jiffies' #Именно это передаем ядру, во избежание проблемы с clocksource root = '/dev/sda1 ro' disk = [ 'file:/home/xen/domains/guest1/disk.img,sda1,w', 'file:/home/xen/domains/guest1/swap.img,sda2,w', ] name = 'guest1' vif = [ 'ip=10.32.0.136,mac=00:16:3E:A3:69:9C' ] on_poweroff = 'destroy' on_reboot = 'restart' on_crash = 'restart' В документации по XEN сказано, что для увеличения производительности дисковой подсистемы виртуальных машин, использующих не физические разделы, а образы – вместо «file:/» использовать «tap:aio:/», но у меня это так и не заработало, даже после плясок с бубном. tap:aio использует драйвер blktap вместо loop, что снимает ограничение на количество одновременно смонтированных устройств, работающих через loopback. Но можно увеличить установленное по умолчанию значение, добавив в в /etc/modules: loop max_loop=255 Теперь настала пора запустить нашу виртуальную машину: # xm create -c /etc/xen/guest1.cfg Опция -c означает, что после запуска виртуальной машины произойдет переключение на ее консоль. Если загрузка прошла успешно, логинимся, и добавляем в конфигурационный файл опций ядра параметр xen.independent_wallclock=1, который обозначает, что не нужно брать системное время от основной системы. После этого, вышеуказанная ошибка синхронизации времени нас беспокоить не будет. Правда придется синхронизировать время например через ntp, но я думаю что это не проблема. # echo "xen.independent_wallclock=1" >> /etc/sysctl.conf Чтобы выйти снова в основную систему, нажимаем CTRL+] Вот краткий перечень наиболее часто используемых команд: xm list - посмотреть список запущенных виртуальных машин xm console guest1 - подключиться к консоли гостевой системы CTRL+] - отключиться от консоли xm create /etc/xen/guest1.cfg - запустить вирт. машину (xm cr /etc/xen/guest1.cfg также возможно использовать) xm shutdown -H guest1 - остановить вирт. машину xm destroy guest1 - принудительно "вырубить" вирт. машину xm top - системный монитор, покажет нагрузку всех вирт. машин xm help - посмотреть список остальных команд Чтобы виртуальная машина стартовала автоматически, нужно добавить симлинк на нее в /etc/xen/auto/: # ln -s /etc/xen/guest1.cfg /etc/xen/auto/guest1.cfg На этом базовая настройка завершена – можно пользоваться. Для увеличения производительности виртуальных машин, лучше всего использовать не файлы с образами систем, а отдавать системам разделы жесткого диска, либо отдельные физические диски. Удобнее всего для этих целей подойдет LVM (Logical Volume Manager): Перед использованием диска или раздела в качестве физического тома необходимо его инициализировать: Для целого диска: %# pvcreate /dev/hdb Для создания группы томов используется команда 'vgcreate' %# vgcreate vg01 /dev/hda1 /dev/hdb1 Для того, чтобы создать логический том "guest1-root ", размером 20000Мб, выполните команду: %# lvcreate -L20000 -nguest1-root vg01 Для свапа: %# lvcreate -L1024 -nguest1-swap vg01 Партиции можно менять, делать что угодно - подробнее http://xgu.ru/wiki/LVM Предположим, что мы выделили для виртуальной машины два логических тома, /dev/vg01/guest1-root для корня и /dev/vg01/guest1-swap для свопа. Перенести виртуальную машину из образа на физический раздел можно так: # dd if=/home/xen/domains/guest1/disk.img of=/dev/vg01/guest1-root bs=64k Если размер тома больше, чем размер образа, то делаем ресайз файловой системы: # e2fsck -f /dev/vg01/guest1-root # resize2fs /dev/vg01/guest1-root Создаем свап: # mkswap /dev/vg01/guest1-swap И исправляем конфигурацию дисков в /etc/xen/guest1.cfg disk = [ 'phy:/dev/vg01/guest1-root,sda1,w', 'phy:/dev/vg01/guest1-swap,sda2,w', ] Запускаем вирт. машину. Теперь она расположена на физических разделах. С использованием LVM, мы можем удобно изменять размер дисков вирт. машин, делать снапшоты для бекапа и многое другое. И в заключении рассмотрим как бекапить все это хозяйство. Если все виртуальные машины у нас находятся в файлах, то можно просто копировать их в надежное место. Но более гибко можно выполнять бекап, если у нас используется LVM. Чтобы выполнять бекап систем без остановки вирт. машин, воспользуемся снапшотами LVM. На жестком диске в Volume group должно быть достаточно свободного места для выполнения снапшота. Создаем снапшот: # lvcreate -L1GB -s -n guest1backup /dev/vg01/guest1-root Можно выполнить бекап всего раздела с помощью dd: # dd if=/dev/vg01/guest1backup bs=64k | gzip -c > /root/guest1_backup.img.gz Но в этом случае будет скопирован весь раздел, включая свободное место, и размер бекапа получится очень большой, поэтому лучше всего использовать утилиту dump: # dump -0af- /dev/vg01/guest1backup | gzip -c > /root/guest1_backup.dump.gz Удаляем снапшот: # lvremove -f /dev/vg01/guest1backup Мы получили полный бекап системы, восстановить который мы сможем куда угодно с помощью утилиты restore. Очень удобно делать подобные бекапы с удаленной машины по ssh периодически, через cron. Для этого на основной XEN машине в /etc/sudoerc добавим возможность группе root выполнять команду dump через sudo без пароля: %root ALL = NOPASSWD: /sbin/dump Нужно добавить пользователя, под которым мы будем ходить по ssh для бекапа в группу root: # gpasswd -a alex root Теперь мы с удаленной машины можем делать бекап командой: # ssh [email protected] 'sudo dump -0af- /dev/vg01/guest1backup | gzip -c' | dd of=./2009-03-05.dump.gz В итоге бекап вирт. машины окажется у нас в текущем каталоге под именем 2009-03-05.dump.gz ---------------------------------------------------------------------------------------------------- Запуск в HVM Описанное выше не подходит для FreeBSD и Windows. Если заинтересуется кто, напишу. FreeBSD поддерживается xen 3.3.1, который требуется установить из исходных кодов. Источники: XEN MANUAL LVM MANUAL Хорошая статья (копипаст с дополнениями)
Полезная статья. + 5 Если описанное - это практика - то очень интересно было бы узнать на каком железе серв.
Пробовал на самых разных машинах, самая сильная: 4 процессора AMD с поддержкой гипертрейдинга, 40Gb памяти, 8 SATA в 10 рейде. Были проблемы с сетевой - так как в стабильных версиях debian не было поддержки, всегда есть возможность в таких случаях использовать более новое ядро для запуска, а потом откатываться на старое с установленными драйверами. Удобно для вынесения различных серверов на одну машину: ресурсы используются практически полностью, безопасность на уровне: к примеру если взломают mysql, web сервер останется в безопасности.
http://www.microsoft.com/windowsserver2008/en/us/hyperv-main.aspx И документация к нему http://www.microsoft.com/downloads/en/results.aspx?pocId=&freetext=Hyper-v%20Guide&DisplayLang=en Входит в состав Windows Server 2008 или распространяется,как отдельный продукт.
Уважаемые разработчики Xen и все кто интересуется Xen. Открылись интересные вакансии для Xen разработчиков. ЗП от 70 000. Информация о вакансиях по ссылкам http://hh.ru/vacancy/4717877 http://hh.ru/vacancy/4739529 Пишите на мыло [email protected] Спасибо за внимание.
