Евгений Прокопьев
В первой части статьи (в №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 соответственно:
[root@m1 ~]# ls
-l /boot/
total 6892
-rw-r--r-- 1
root root 755493 Sep 22 22:45 System.map-2.6.16-ovz-smp-alt7
-rw-r--r-- 1
root root 686841 Oct 9 23:54 System.map-2.6.16-std26-up-alt10
-rw-r--r-- 1
root root 512 Oct 9 23:54 boot.0300
-rw-r--r-- 1
root root 512 Oct 9 23:54 boot.0800
-rw-r--r-- 1
root root 65929 Sep 22 22:39 config-2.6.16-ovz-smp-alt7
-rw-r--r-- 1
root root 66100 Oct 9 23:54 config-2.6.16-std26-up-alt10
-rw------- 1
root root 321240 Oct 10 23:34 initrd-2.6.16-ovz-smp-alt7.img
-rw------- 1
root root 204992 Oct 9 23:54 initrd-2.6.16-std26-up-alt10.img
lrwxrwxrwx 1
root root 30 Oct 10 23:34 initrd-smp.img ->
initrd-2.6.16-ovz-smp-alt7.img
lrwxrwxrwx 1
root root 32 Oct 9 23:54 initrd-up.img ->
initrd-2.6.16-std26-up-alt10.img
lrwxrwxrwx 1
root root 30 Oct 10 23:34 initrd.img -> initrd-2.6.16-ovz-smp-alt7.img
-rw------- 1
root root 31744 Oct 10 23:38 map
lrwxrwxrwx 1
root root 27 Oct 10 23:34 vmlinuz -> vmlinuz-2.6.16-ovz-smp-alt7
-rw-r--r-- 1
root root 1246789 Sep 22 22:45 vmlinuz-2.6.16-ovz-smp-alt7
-rw-r--r-- 1
root root 1132834 Oct 9 23:54 vmlinuz-2.6.16-std26-up-alt10
lrwxrwxrwx 1
root root 27 Oct 10 23:34 vmlinuz-smp -> vmlinuz-2.6.16-ovz-smp-alt7
lrwxrwxrwx 1
root root 29 Oct 9 23:54 vmlinuz-up -> vmlinuz-2.6.16-std26-up-alt10
Также с помощью «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 и выполнить следующее:
[root@m1 ~]#
vzctl create 101 --ostemplate altlinux-sisyphus --config vps.basic
Creating VE
private area: /var/lib/vz/private/101
Performing
postcreate actions
VE private area
was created
[root@m1 ~]#
vzctl set 101 --name router --save
Name router
assigned
Saved
parameters for VE 101
[root@m1 ~]#
vzctl set router --onboot yes --save
Saved
parameters for VE 101
[root@m1 ~]#
vzctl set router --hostname router.mydomain.com --save
Set hostname:
router.mydomain.com
Saved
parameters for VE 101
Таким образом, мы создали виртуальный сервер,
задали для него имя, указали, что он должен загружаться при старте OpenVZ, и
присвоили ему FQDN. Везде мы использовали ключ --save, чтобы сохранить
внесенные изменения после перезапуска виртуального сервера.
Далее необходимо пробросить физический интерфейс
eth1, который мы оставили незадействованным на этапе конфигурирования узлов
кластера, в виртуальный сервер, чтобы сделать его доступным извне:
[root@m1 ~]#
vzctl set router --netdev_add eth1 --save
Saved parameters
for VE 101
Теперь можно запустить виртуальный сервер, войти
в него, сконфигурировать сетевой интерфейс eth1 и проверить доступность
физических серверов из виртуального и наоборот:
[root@m1 ~]#
vzctl start router
Starting VE ...
VE is mounted
Setting CPU
units: 1000
Set hostname:
router.mydomain.com
VE start in
progress...
[root@m1 ~]#
vzctl enter router
entered into VE
101
[root@router
/]# ip address add 192.168.46.200/24 dev eth1
[root@router
/]# ip link set eth1 up
[root@router
/]# ping 192.168.46.1
PING
192.168.46.1 (192.168.46.1) 56(84) bytes of data.
64 bytes from
192.168.46.1: icmp_seq=1 ttl=64 time=5.37 ms
---
192.168.46.1 ping statistics ---
1 packets
transmitted, 1 received, 0% packet loss, time 0ms
rtt
min/avg/max/mdev = 5.376/5.376/5.376/0.000 ms
Команды внутри виртуального сервера можно также
выполнять с помощью vzctl exec, не переключаясь в консоль через vzctl enter:
[root@m1 ~]#
vzctl exec router ping 192.168.46.1
PING
192.168.46.1 (192.168.46.1) 56(84) bytes of data.
64 bytes from
192.168.46.1: icmp_seq=1 ttl=64 time=6.34 ms
Для сохранения сетевых настроек после
перезагрузки в ALT Linux есть 2 механизма конфигурирования сети: net-scripts,
унаследованный от Mandrake и Red Hat, и свой собственный etcnet, о котором
много написано на http://etcnet.org и http://wiki.sisyphus.ru/admin/etcnet.
Второй способ значительно удобнее и
функциональнее, также он был указан при генерации шаблона, поэтому нам ничего
другого не остается, кроме как настроить именно его:
[root@router
/]# mkdir /etc/net/ifaces/eth1
[root@router
/]# echo 192.168.46.200/24 > /etc/net/ifaces/eth1/ipv4address
[root@router
/]# echo default via 192.168.46.1 dev eth1 > /etc/net/ifaces/eth1/ipv4route
[root@router
/]# echo "BOOTPROTO=static
> ONBOOT=yes
>
TYPE=eth" > /etc/net/ifaces/eth1/options
[root@router
/]# service network restart
Computing
interface groups: ... 3 interfaces found
Processing
/etc/net/vlantab: empty.
Stopping group
1/realphys (1 interfaces)
Stopping eth1: ..OK
Stopping group
0/virtual (2 interfaces)
Stopping lo: .OK
Stopping venet0: .OK
error: setting
key "net.ipv4.icmp_echo_ignore_broadcasts": Operation not permitted
error: setting
key "net.ipv4.tcp_syncookies": Operation not permitted
error: setting
key "net.ipv4.tcp_timestamps": Operation not permitted
Computing
interface groups: ... 3 interfaces found
Starting group
0/virtual (2 interfaces)
Starting lo: ....OK
Starting venet0: ......OK
Starting group
1/realphys (1 interfaces)
Starting eth1: ......OK
Processing
/etc/net/vlantab: empty.
Сообщения «Operation not permitted» связаны с
ограничениями для виртуального сервера, определенными по умолчанию, и в нашем
случае на функционировании сети отрицательно не сказываются. Можно
закомментировать соответствующие строки в файле /etc/net/sysctl.conf, чтобы эти
сообщения больше не появлялись.
Созданный нами виртуальный сервер будет
использовать сетевой интерфейс eth1 того узла, на котором он в данный момент
работает, поэтому в случае отказа узла m1 сервер переместится на узел m2 и
будет доступен там по тому же самому адресу. Можно смоделировать эту ситуацию и
увидеть с внешнего физического сервера следующее:
$ ping
192.168.46.200
PING
192.168.46.200 (192.168.46.200) 56(84) bytes of data.
64 bytes from
192.168.46.200: icmp_seq=1 ttl=64 time=0.549 ms
...
From
192.168.46.1 icmp_seq=83 Destination Host Unreachable
...
64 bytes from
192.168.46.200: icmp_seq=179 ttl=64 time=1.05 ms
---
192.168.46.200 ping statistics ---
179 packets
transmitted, 25 received, +93 errors, 86% packet loss, time 178149ms
rtt min/avg/max/mdev
= 0.298/193.970/1702.783/397.285 ms, pipe 3
Строим виртуальную сеть
В большинстве случаев на одном физическом сервере размещают
несколько виртуальных серверов, при этом необходимо каким-то образом обеспечить
доступность сервисов, работающих на виртуальных серверах, другим физическим
машинам. Пробрасывать каждому виртуальному серверу по физическому интерфейсу
накладно, да и неудобно. Часто хочется спрятать все виртуальные серверы за
одним маршрутизатором/брандмауэром. Посмотрим, какие средства для этого
предлагает OpenVZ. Он предлагает 2 типа виртуальных сетевых интерфейсов:
n venet – соединения точка-точка между
физическим сервером и виртуальным, которые создаются автоматически для каждого
виртуального сервера и конфигурируются c помощью vzctl. Они не имеют
MAC-адресов, не поддерживают броадкасты (broadcast), на них не работают
снифферы и средства учета трафика, использующие libicap (например, tcpdump), на
них нельзя строить бриджи.
n veth – соединения точка-точка между
физическим сервером и виртуальным, которые нужно создавать и конфигурировать
вручную средствами того дистрибутива Linux, который работает на физическом и
виртуальном сервере. Они лишены недостатков venet (которые можно рассматривать
и как достоинства с точки зрения безопасности и эффективности) и выглядят как
полноценные ethernet-интерфейсы.
Если в качестве маршрутизатора/брандмауэра для
доступа к виртуальным серверам использовать физический сервер, стоит,
несомненно, предпочесть venet. Поскольку такая конфигурация более
распространена, то и venet-интерфейсы используются чаще. Однако чем сложнее
конфигурация маршрутизатора/брандмауэра, тем больше оснований появляется для
вынесения его в отдельный виртуальный сервер, чтобы не перегружать физический
сервер лишними задачами и лишним ПО. В нашем случае дополнительным поводом
стало желание иметь один и тот же адрес виртуального сервера, доступный извне,
независимо от адреса узла кластера, на котором он в данный момент работает. Эта
конфигурация в некоторых случаях может оказаться еще более сложной, если,
например, на проброшенном физическом интерфейсе организовать поддержку IEEE
802.1Q VLAN, чтобы принять несколько vlan, но с точки зрения настройки OpenVZ
эта конфигурация не будет ничем отличаться от того, что было рассмотрено выше –
разница будет только в настройке проброшенного сетевого интерфейса. Более
важным является то, что если использовать в качестве маршрутизатора/брандмауэра
виртуальный сервер, более удобным будет построить виртуальную сеть на
veth-интерфейсах. Выглядеть это будет так, как показано на рисунке.
Виртуальная сеть
Итак, для каждого виртуального сервера мы создаем
veth-интерфейс, а концы этих интерфейсов со стороны физического сервера
объединяем в бридж – в результате получается аналог хаба, в который включены
все виртуальные сервера. Один из них уже имеет проброшенный в него физический
интерфейс – этот виртуальный сервер и будет играть роль
маршрутизатора/брандмауэра.
Создаем и запускаем виртуальные сервера:
[root@m1 ~]#
vzctl create 102 --ostemplate altlinux-sisyphus --config vps.basic
Creating VE
private area: /var/lib/vz/private/102
Performing
postcreate actions
VE private area
was created
[root@m1 ~]#
vzctl set 102 --name mail --save
Name ve1
assigned
Saved
parameters for VE 102
[root@m1 ~]#
vzctl set mail --onboot yes --save
Saved
parameters for VE 102
[root@m1 ~]#
vzctl set mail --hostname mail.mydomain.com --save
Saved
parameters for VE 102
[root@m1 ~]#
vzctl start mail
Starting VE ...
VE is mounted
Adding IP
address(es): 192.168.199.2
Setting CPU
units: 1000
Set hostname:
mail.mydomain.com
VE start in
progress...
[root@m1 ~]#
vzctl create 103 --ostemplate altlinux-sisyphus --config vps.basic
Creating VE
private area: /var/lib/vz/private/103
Performing
postcreate actions
VE private area
was created
[root@m1 ~]#
vzctl set 103 --name dbms --save
Name ve2
assigned
Saved parameters
for VE 103
[root@m1 ~]#
vzctl set dbms --onboot yes --save
Saved
parameters for VE 103
[root@m1 ~]#
vzctl set dbms --hostname dbms.mydomain.com --save
Saved
parameters for VE 103
[root@m1 ~]#
vzctl start dbms
Starting VE ...
VE is mounted
Adding IP
address(es): 192.168.199.3
Setting CPU
units: 1000
Set hostname:
dbms.mydomain.com
VE start in
progress...
Создаем и конфигурируем veth-интерфейсы внутри
виртуальных серверов:
[root@m1 ~]#
vzctl set router --veth_add veth1,00:12:34:56:78:9A,eth0,00:12:34:56:78:9B
--save
Processing veth
devices
Saved
parameters for VE 101
[root@m1 ~]#
vzctl exec router ip address add 192.168.199.1/24 dev eth0
[root@m1 ~]#
vzctl exec router ip link set eth0 up
[root@m1 ~]#
vzctl set mail --veth_add veth2,00:12:34:56:78:9C,eth0,00:12:34:56:78:9D --save
Processing veth
devices
Saved
parameters for VE 102
[root@m1 ~]#
vzctl exec mail ip address add 192.168.199.2/24 dev eth0
[root@m1 ~]#
vzctl exec mail ip link set eth0 up
[root@m1 ~]#
vzctl set dbms --veth_add veth3,00:12:34:56:78:9E,eth0,00:12:34:56:78:9F --save
Processing veth
devices
Saved
parameters for VE 103
[root@m1 ~]#
vzctl exec dbms ip address add 192.168.199.3/24 dev eth0
[root@m1 ~]#
vzctl exec dbms ip link set eth0 up
Имена интерфейсов и их 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 router ping 192.168.199.2
PING
192.168.199.2 (192.168.199.2) 56(84) bytes of data.
64 bytes from
192.168.199.2: icmp_seq=1 ttl=64 time=15.9 ms
[root@m1 ~]#
vzctl exec router ping 192.168.199.3
PING
192.168.199.3 (192.168.199.3) 56(84) bytes of data.
64 bytes from
192.168.199.3: icmp_seq=1 ttl=64 time=3.71 ms
Теперь на виртуальных серверах описываем маршрут
во внешнюю физическую сеть:
[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 на
виртуальном маршрутизаторе), мы получим то, чего и добивались:
[root@m1 ~]#
vzctl exec mail ping 192.168.46.1
PING
192.168.46.1 (192.168.46.1) 56(84) bytes of data.
64 bytes from
192.168.46.1: icmp_seq=1 ttl=63 time=0.982 ms
Желательно, чтобы все описанные выше настройки
сохранялись при перезапуске виртуальных серверов, сервиса 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 заранее для собственных нужд,
уже есть:
[root@m1 ~]#
vzctl exec mail ip route
192.168.199.0/24
dev eth0 proto kernel scope link src 192.168.199.2
192.0.2.0/24
dev venet0 scope host
192.168.0.0/16
via 192.168.199.1 dev eth0
default via
192.0.2.1 dev venet0
Он создается и автоматически привязывается к
интерфейсу venet0. Ни эта довольно навязчивая автоматика, ни venet-интерфейсы
вообще нам сейчас не нужны, мы используем только veth. Поэтому чтобы такого не
происходило, потребуется исправить скрипт, занимающийся конфигурированием
сетевых интерфейсов виртуального сервера. В случае ALT Linux Sisyphus – это
скрипт /etc/vz/dists/scripts/etcnet-add_ip.sh. В нем нам нужно модифицировать
функцию add_ip() таким образом, чтобы она выполнялась только при наличии
присвоенного venet-интерфейсу адреса:
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 наблюдается лишь
кратковременный перерыв в обслуживании:
$ ping
192.168.199.2
PING
192.168.199.2 (192.168.199.2) 56(84) bytes of data.
64 bytes from
192.168.199.2: icmp_seq=1 ttl=64 time=0.549 ms
...
From
192.168.46.1 icmp_seq=83 Destination Host Unreachable
...
From
192.168.46.200 icmp_seq=83 Destination Host Unreachable
...
64 bytes from
192.168.199.2: icmp_seq=179 ttl=64 time=1.05 ms
---
192.168.46.200 ping statistics ---
179 packets
transmitted, 25 received, +93 errors, 86% packet loss, time 178149ms
rtt
min/avg/max/mdev = 0.298/193.970/1702.783/397.285 ms, pipe 3
Что дальше
Итак, мы выполнили базовую настройку двухузлового кластера, подняли систему
виртуализации OpenVZ, кластеризовали ее, а затем настроили несколько
виртуальных серверов, виртуальную сеть между ними и связали ее с внешней
физической сетью. При этом мы показали преимущества такого способа построения
систем как с точки зрения надежности, так и с точки зрения снижения затрат на
оборудование и его обслуживание. Теперь можно углубляться в детали: садиться и
вдумчиво читать OpenVZ Users Guide – http://download.openvz.org/doc/OpenVZ-Users-Guide.pdf
(перевод этого руководства доступен на http://www.opennet.ru/docs/RUS/virtuozzo).
Для полноценного использования
OpenVZ нам потребуется настроить:
n Квоты на процессорное время для виртуальных
серверов.
n Квоты потребления системных ресурсов
виртуальными серверами (количество процессов, количество сокетов, объем
виртуальной памяти, различных буферов и т. д.).
n Дисковые квоты.
n Доступ к физическим устройствам и файловым
системам физического сервера, если в этом есть необходимость.
Все перечисленное очень подробно описано в документации.
После более тщательной настройки OpenVZ можно переходить к настройке самих
виртуальных серверов.
Приложение
Краткий обзор важнейших
технологий Sisyphus
Spt (http://wiki.sisyphus.ru/devel/spt)
– это инструмент, позволяющий из репозитория Sisyphus создать готовый к
загрузке экземпляр системы в виде:
n Live-CD.
n Инсталляционного диска, который является
частным случаем Live?CD отличается от него только тем, что включает в себя
alterator (http://wiki.sisyphus.ru/Alterator)
– штатный конфигуратор системы, построеной на основе Sisyphus.
n Архива корневой файловой системы для
использования в качестве виртуального сервера в какой-либо системе виртуализации
или для установки на диск физического компьютера.
n Тонкого клиента для загрузки по сети
посредством PXE.
Механизм работы 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 со временем
отказаться.
1. http://linux-ha.org
2. http://drbd.org
3. http://openvz.org
4. http://altlinux.ru
5. http://sisyphus.ru
6. http://freesource.info
