 |
|
|
|
Кластеризация + виртуализация: Linux HA + OpenVZ. Часть 2: Виртуализация на практике
Кластеризация + виртуализация: Linux HA + OpenVZ Часть 2: Виртуализация на практике В первой части статьи (в №11 за 2005 г.) мы построили отказоустойчивый кластер с общим дисковым пространством, состоящий из двух узлов: m1 и m2. Теперь нам необходимо построить систему виртуализации с виртуальными серверами, мигрирующими с узла m1 на m2 в случае отказа первого. Строим контейнер для виртуальных серверов и кластеризуем его Приступим к установке выбранной нами системы виртуализации – OpenVZ. Она представляет собой набор патчей к стандартному ядру Linux и userspace-инструменты для управления. В ALT Linux Sisyphus ядро с поддержкой OpenVZ собрано отдельно, поэтому его необходимо установить в дополнение к существующему ядру, установить модуль поддержки DRBD в этом ядре и userspace-инструменты, представленные пакетами vzctl и vzquota: [root@m1 ~]# apt-get install kernel-image-ovz-smp kernel-modules-drbd-ovz-smp vzctl vzquota Для других дистрибутивов Linux ядро с поддержкой OpenVZ в виде бинарных пакетов или исходного кода можно загрузить отсюда – http://openvz.org/download/kernel. В документе http://wiki.openvz.org/Quick_installation описана процедура установки ядра на Fedora Core, Red Hat Enterprise Linux и CentOS. После установки нового ядра проверьте конфигурацию загрузчика и удостоверьтесь в том, что после перезапуска будет загружено ovz-ядро. Если это не так, то вам придётся предпринять для загрузки требуемого ядра необходимые действия. Например, если в качестве загрузчика используется lilo, то его конфигурационный файл может выглядеть так: boot=/dev/hda map=/boot/map default=linux image=/boot/vmlinuz label=linux root=/dev/hda2 initrd=/boot/initrd.img read-only При этом /boot/vmlinuz и /boot/initrd.img должны ссылаться на образ ядра и образ initrd соответственно:
Также с помощью «chkconfig --list» удостоверьтесь, что сервис vz не будет запущен после перезагрузки и затем перезагрузится. После перезагрузки переместите файлы OpenVZ в каталог /d0, куда уже должно быть смонтировано устройство /dev/drbd0, а на старом месте создать символические ссылки: [root@m1 ~]# mkdir /d0/vz [root@m1 ~]# mkdir /d0/vz/etc [root@m1 ~]# mkdir /d0/vz/etc/sysconfig [root@m1 ~]# mkdir /d0/vz/var [root@m1 ~]# mkdir /d0/vz/var/lib [root@m1 ~]# cp -r /etc/vz /d0/vz/etc [root@m1 ~]# cp -r /etc/sysconfig/vz-scripts /d0/vz/etc/sysconfig [root@m1 ~]# cp -r /var/lib/vz /d0/vz/var/lib [root@m1 ~]# cp -r /var/lib/vzquota /d0/vz/var/lib [root@m1 ~]# rm -rf /etc/vz [root@m1 ~]# rm -rf /etc/sysconfig/vz-scripts [root@m1 ~]# rm -rf /var/lib/vz [root@m1 ~]# rm -rf /var/lib/vzquota [root@m1 ~]# ln -s /d0/vz/etc/vz /etc/vz [root@m1 ~]# ln -s /d0/vz/etc/sysconfig/vz-scripts /etc/sysconfig/vz-scripts [root@m1 ~]# ln -s /d0/vz/var/lib/vz /var/lib/vz [root@m1 ~]# ln -s /d0/vz/var/lib/vzquota /var/lib/vzquota После остановки сервиса heartbeat на узле m1 и монтирования drbd-устройства на узле m2 на нем необходимо аналогичным образом удалить каталоги OpenVZ и создать вместо них ссылки на /d0/vz. После того как OpenVZ перенесен на drbd-раздел, необходимо указать сервису heartbeat, что сервис vz должен работать на узле m1, для чего отредактировать файл /etc/ha.d/haresources на обоих узлах: m1.mydomain.com drbddisk Filesystem::/dev/drbd0::/d0::ext3 vz После рестарта heartbeat на обоих узлах необходимо смоделировать отказ узла m1 и убедиться в том, что сервис vz запускается на узле m2. Строим первый виртуальный сервер Теперь мы можем забыть о том, что OpenVZ работает в кластере, и конфигурировать его, опираясь на оригинальную документацию с http://openvz.org/documentation и выжимку из нее, ориентированную на ALT Linux и доступную здесь – http://www.freesource.info/wiki/AltLinux/Dokumentacija/OpenVZ. Существуют уже готовые шаблоны виртуальных серверов, построенных на основе некоторых общедоступных дистрибутивов Linux: CentOS, Debian, Fedora Core, Gentoo, Mandriva, openSUSE. Коммерческие RHEL и SUSE SLES в этом списке отсутствуют. Отсутствует и ALT Linux, хотя ссылки на шаблоны ALT Linux содержатся в приведенной выше ссылке на ALT-ориентированную документацию. Но мы построим шаблон для виртуального сервера на основе ALT Linux самостоятельно. Штатным для OpenVZ средством построения шаблонов является утилита vzpkg. Она использует yum в качестве высокоуровневого средства управления пакетами (поддержку apt обещают чуть позже) и поэтому не может быть использована в тех случаях, когда дистрибутив, на основе которого строится шаблон, не имеет yum-репозиториев. Впрочем, поскольку шаблон – это всего лишь архив корня уже установленной системы в виде tar.gz, изготовить его можно любыми подручными средствами, например, из системы, работающей на физическом сервере. В случае ALT Linux в качестве такого подручного средства удобнее всего использовать spt. Если spt уже установлен (его удобнее держать на выделенном физическом либо виртуальном сборочном сервере), то можно использовать содержимое каталога /usr/share/spt/profile-ovz/ как пример для создания образа, который затем послужит нам шаблоном для создания виртуального сервера. Нет никаких препятствий к тому, чтобы использовать этот образец как есть, но мне показалось более правильным скопировать его в ~/ovz и изменить список пакетов в шаблоне, отредактировав файл ~/ovz/packages/main так: basesystem passwd apt apt-conf-sisyphus etcnet glibc sysklogd mc openssh-server openssh-clients Также мне показалось разумным изменить конфигурацию apt по умолчанию, чтобы сразу иметь возможность устанавливать пакеты из моего локального репозитория. Для этого я создал файл ~/ovz/postinstall/setup.d/01apt c таким содержимым: # Local Sisyphus rpm [alt] ftp://192.168.46.1/distrib/linux/alt-linux-sisyphus i586 classic rpm-src [alt] ftp://192.168.46.1/distrib/linux/alt-linux-sisyphus i586 classic rpm [alt] ftp://192.168.46.1/distrib/linux/alt-linux-sisyphus noarch classic rpm-src [alt] ftp://192.168.46.1/distrib/linux/alt-linux-sisyphus noarch classic END Затем я выполнил команду: spt -v --noiso --image-type=tgz --maketty ~/ovz/ и получил файл ~/ovz/out/altlinux, который можно использовать как шаблон виртуального сервера для OpenVZ. Теперь файл ~/ovz/out/altlinux необходимо скопировать на ведущий узел кластера с именем /var/lib/vz/template/cache/altlinux-sisyphus.tar.gz и выполнить следующее:
Таким образом, мы создали виртуальный сервер, задали для него имя, указали, что он должен загружаться при старте OpenVZ, и присвоили ему FQDN. Везде мы использовали ключ --save, чтобы сохранить внесенные изменения после перезапуска виртуального сервера. Далее необходимо пробросить физический интерфейс eth1, который мы оставили незадействованным на этапе конфигурирования узлов кластера, в виртуальный сервер, чтобы сделать его доступным извне:
Теперь можно запустить виртуальный сервер, войти в него, сконфигурировать сетевой интерфейс eth1 и проверить доступность физических серверов из виртуального и наоборот:
Команды внутри виртуального сервера можно также выполнять с помощью vzctl exec, не переключаясь в консоль через vzctl enter:
http://etcnet.org и http://wiki.sisyphus.ru/admin/etcnet. Второй способ значительно удобнее и функциональнее, также он был указан при генерации шаблона, поэтому нам ничего другого не остается, кроме как настроить именно его:
Сообщения «Operation not permitted» связаны с ограничениями для виртуального сервера, определенными по умолчанию, и в нашем случае на функционировании сети отрицательно не сказываются. Можно закомментировать соответствующие строки в файле /etc/net/sysctl.conf, чтобы эти сообщения больше не появлялись. Созданный нами виртуальный сервер будет использовать сетевой интерфейс eth1 того узла, на котором он в данный момент работает, поэтому в случае отказа узла m1 сервер переместится на узел m2 и будет доступен там по тому же самому адресу. Можно смоделировать эту ситуацию и увидеть с внешнего физического сервера следующее:
Строим виртуальную сеть В большинстве случаев на одном физическом сервере размещают несколько виртуальных серверов, при этом необходимо каким-то образом обеспечить доступность сервисов, работающих на виртуальных серверах, другим физическим машинам. Пробрасывать каждому виртуальному серверу по физическому интерфейсу накладно, да и неудобно. Часто хочется спрятать все виртуальные серверы за одним маршрутизатором/брандмауэром. Посмотрим, какие средства для этого предлагает OpenVZ. Он предлагает 2 типа виртуальных сетевых интерфейсов:
Если в качестве маршрутизатора/брандмауэра для доступа к виртуальным серверам использовать физический сервер, стоит, несомненно, предпочесть venet. Поскольку такая конфигурация более распространена, то и venet-интерфейсы используются чаще. Однако чем сложнее конфигурация маршрутизатора/брандмауэра, тем больше оснований появляется для вынесения его в отдельный виртуальный сервер, чтобы не перегружать физический сервер лишними задачами и лишним ПО. В нашем случае дополнительным поводом стало желание иметь один и тот же адрес виртуального сервера, доступный извне, независимо от адреса узла кластера, на котором он в данный момент работает. Эта конфигурация в некоторых случаях может оказаться еще более сложной, если, например, на проброшенном физическом интерфейсе организовать поддержку IEEE 802.1Q VLAN, чтобы принять несколько vlan, но с точки зрения настройки OpenVZ эта конфигурация не будет ничем отличаться от того, что было рассмотрено выше – разница будет только в настройке проброшенного сетевого интерфейса. Более важным является то, что если использовать в качестве маршрутизатора/брандмауэра виртуальный сервер, более удобным будет построить виртуальную сеть на veth-интерфейсах. Выглядеть это будет так, как показано на рисунке.
Виртуальная сеть Итак, для каждого виртуального сервера мы создаем veth-интерфейс, а концы этих интерфейсов со стороны физического сервера объединяем в бридж – в результате получается аналог хаба, в который включены все виртуальные сервера. Один из них уже имеет проброшенный в него физический интерфейс – этот виртуальный сервер и будет играть роль маршрутизатора/брандмауэра. Создаем и запускаем виртуальные сервера:
Создаем и конфигурируем veth-интерфейсы внутри виртуальных серверов:
Имена интерфейсов и их MAC-адреса мы придумываем сами, поэтому необходимо, чтобы последние не пересекались с существующими. Объединяем концы veth-интерфейсов со стороны физического сервера в бридж: [root@m1 ~]# ip link set veth1 up [root@m1 ~]# ip link set veth2 up [root@m1 ~]# ip link set veth3 up [root@m1 ~]# brctl addbr br0 [root@m1 ~]# brctl addif br0 veth1 [root@m1 ~]# brctl addif br0 veth2 [root@m1 ~]# brctl addif br0 veth3 [root@m1 ~]# ip link set br0 up Проверяем работоспособность внутренней виртуальной сети:
Теперь на виртуальных серверах описываем маршрут во внешнюю физическую сеть: [root@m1 ~]# vzctl exec mail ip route add 192.168.0.0/16 via 192.168.199.1 [root@m1 ~]# vzctl exec dbms ip route add 192.168.0.0/16 via 192.168.199.1 На виртуальном маршрутизаторе включаем пересылку пакетов между физической и виртуальной сетями: [root@m1 ~]# vzctl exec router sysctl -w net.ipv4.ip_forward=1 Теперь если на машине из физической сети 192.168.46.0/24 описать маршрут в сеть 192.168.199.0/24 (или настроить NAT на виртуальном маршрутизаторе), мы получим то, чего и добивались:
Желательно, чтобы все описанные выше настройки сохранялись при перезапуске виртуальных серверов, сервиса vz и ведущего узла кластера. С настройками виртуальных серверов проще всего – их можно сохранить в etcnet: [root@m1 ~]# vzctl enter mail [root@mail /]# mkdir /etc/net/ifaces/eth0 [root@mail /]# echo 192.168.199.2/24 > /etc/net/ifaces/eth0/ipv4address [root@mail /]# echo 192.168.0.0/16 via 192.168.199.1 dev eth0 > /etc/net/ifaces/eth0/ipv4route [root@mail /]# echo "BOOTPROTO=static > ONBOOT=yes > TYPE=eth" > /etc/net/ifaces/eth0/options [root@m1 ~]# vzctl enter dbms [root@dbms /]# mkdir /etc/net/ifaces/eth0 [root@dbms /]# echo 192.168.199.3/24 > /etc/net/ifaces/eth0/ipv4address [root@dbms /]# echo 192.168.0.0/16 via 192.168.199.1 dev eth0 > /etc/net/ifaces/eth0/ipv4route [root@dbms /]# echo "BOOTPROTO=static > ONBOOT=yes > TYPE=eth" > /etc/net/ifaces/eth0/options Для автоматического добавления конца veth-интерфейсов со стороны физического сервера в бридж при старте соответствующего виртуального сервера потребуется исправить скрипт /usr/sbin/vznetcfg, добавив в конец функции init_veth() строку (сделать это нужно на двух узлах кластера): brctl addif br0 ${dev} В будущем разработчики OpenVZ обещают доработать этот скрипт, чтобы подобного рода измения можно было описывать в конфигурационном файле. Наконец, бридж тоже нужно создать, и сделать это необходимо еще до старта всех виртуальных серверов. Лучше всего добавить его создание в конфигурацию etcnet на обоих узлах кластера: [root@m1 ~]# mkdir /etc/net/ifaces/br0 [root@m1 ~]# echo TYPE=bri > /etc/net/ifaces/br0/options Есть одна неприятная деталь. В конфигурацию виртуальных серверов мы добавили маршрут в сеть 192.168.0.0/16, но во многих случаях нам потребуется добавить туда маршрут по умолчанию. Сделать этого мы не сможем, так как такой маршрут, созданный OpenVZ заранее для собственных нужд, уже есть:
add_ip() { local i ip if [ -n "$IP_ADDR" ]; then if [ "$VE_STATE" = "starting" ]; then setup_network fi backup_configs "$IPDELALL" i=0 for ip in ${IP_ADDR}; do i="$(find_unused_alias "$((i+1))")" create_alias "$ip" "$i" done move_configs if [ "$VE_STATE" = "running" ]; then # synchronyze config files & interfaces ifdown "$VENET_DEV" ifup "$VENET_DEV" fi fi } Затем в виртуальных серверах необходимо удалить из etcnet настройки интерфейса venet0: [root@m1 ~]# vzctl exec router rm -rf /etc/net/ifaces/venet0 [root@m1 ~]# vzctl exec mail rm -rf /etc/net/ifaces/venet0 [root@m1 ~]# vzctl exec dbms rm -rf /etc/net/ifaces/venet0 Теперь можно перезапустить сервис vz – в конфигурации виртуальных серверов останутся только те маршруты, которые мы указали явно. Таким образом, мы добились того, чего хотели: в штатном режиме виртуальные серверы mail и dbms работают на узле m1, а в случае его отказа автоматически переезжают на узел m2, при этом с точки зрения внешнего наблюдателя из физической сети 192.168.46.0/24 наблюдается лишь кратковременный перерыв в обслуживании:
Что дальше Итак, мы выполнили базовую настройку двухузлового кластера, подняли систему виртуализации OpenVZ, кластеризовали ее, а затем настроили несколько виртуальных серверов, виртуальную сеть между ними и связали ее с внешней физической сетью. При этом мы показали преимущества такого способа построения систем как с точки зрения надежности, так и с точки зрения снижения затрат на оборудование и его обслуживание. Теперь можно углубляться в детали: садиться и вдумчиво читать OpenVZ Users Guide – http://download.openvz.org/doc/OpenVZ-Users-Guide.pdf (перевод этого руководства доступен на http://www.opennet.ru/docs/RUS/virtuozzo). Для полноценного использования OpenVZ нам потребуется настроить:
Все перечисленное очень подробно описано в документации. После более тщательной настройки OpenVZ можно переходить к настройке самих виртуальных серверов. Приложение Краткий обзор важнейших технологий Sisyphus Spt (http://wiki.sisyphus.ru/devel/spt) – это инструмент, позволяющий из репозитория Sisyphus создать готовый к загрузке экземпляр системы в виде:
Механизм работы spt сводится к установке пакетов, определенных пользователем (и всех зависимых от них) в chroot, и выполнению ряда скриптов, также определенных пользователем. Spt активно использует hasher (http://www.freesource.info/wiki/ALTLinux/Dokumentacija/Hasher), который в общем случае является механизмом помещения в chroot запускаемой программы и установки туда же всех пакетов, от которых эта программа зависит. По этой причине чаще всего hasher используется при сборке пакетов для того, чтобы гарантировать постоянство среды, в которой происходит сборка, и, соответственно, воспроизводимость результатов. В этом качестве hasher используют как члены ALT Linux Team для подготовки своих пакетов, так и Incominger (http://wiki.sisyphus.ru/devel/Incoming) – робот, занимающийся приемом новых пакетов в репозиторий. В настоящее время пакеты поступают в Incoming в виде SRPM, однако многими разработчиками уже используется технология GEAR (http://wiki.sisyphus.ru/devel/git), позволяющая хранить исходный код пакетов в системе контроля версий GIT (http://git.or.cz), первоначально разработанной Линусом Торвальдсом специально для совместной работы над ядром Linux. В самом ближайшем будущем планируется сделать поступление пакетов из GIT-репозиториев напрямую в Incoming более приоритетным, а от SRPMS со временем отказаться. |
ЕВГЕНИЙ ПРОКОПЬЕВ
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
