Кластеризация + виртуализация: Linux HA + OpenVZ. Часть 2: Виртуализация на практике::Журнал СА 12.2006
www.samag.ru
     
Поиск   
              
 www.samag.ru    Web  0 товаров , сумма 0 руб.
E-mail
Пароль  
 Запомнить меня
Регистрация | Забыли пароль?
О журнале
Журнал «БИТ»
Наука и технологии
Подписка
Где купить
Авторам
Рекламодателям
Магазин
Архив номеров
Вакансии
Контакты
   

  Опросы

Какие курсы вы бы выбрали для себя?  

Очные
Онлайновые
Платные
Бесплатные
Я и так все знаю

 Читать далее...

1001 и 1 книга  
20.12.2019г.
Просмотров: 1235
Комментарии: 0
Dr.Web: всё под контролем

 Читать далее...

04.12.2019г.
Просмотров: 1257
Комментарии: 0
Особенности сертификаций по этичному хакингу

 Читать далее...

28.05.2019г.
Просмотров: 3786
Комментарии: 2
Анализ вредоносных программ

 Читать далее...

28.05.2019г.
Просмотров: 4008
Комментарии: 1
Микросервисы и контейнеры Docker

 Читать далее...

28.05.2019г.
Просмотров: 3203
Комментарии: 0
Django 2 в примерах

 Читать далее...

Друзья сайта  

Форум системных администраторов  

sysadmins.ru

 Кластеризация + виртуализация: Linux HA + OpenVZ. Часть 2: Виртуализация на практике

Архив номеров / 2006 / Выпуск №12 (49) / Кластеризация + виртуализация: 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 соответственно:

[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

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 типа виртуальных сетевых интерфейсов:

  • venet – соединения точка-точка между физическим сервером и виртуальным, которые создаются автоматически для каждого виртуального сервера и конфигурируются c помощью vzctl. Они не имеют MAC-адресов, не поддерживают броадкасты (broadcast), на них не работают снифферы и средства учета трафика, использующие libicap (например, tcpdump), на них нельзя строить бриджи.
  • 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

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 нам потребуется настроить:

  • Квоты на процессорное время для виртуальных серверов.
  • Квоты потребления системных ресурсов виртуальными серверами (количество процессов, количество сокетов, объем виртуальной памяти, различных буферов и т. д.).
  • Дисковые квоты.
  • Доступ к физическим устройствам и файловым системам физического сервера, если в этом есть необходимость.

Все перечисленное очень подробно описано в документации. После более тщательной настройки OpenVZ можно переходить к настройке самих виртуальных серверов.

Приложение

Краткий обзор важнейших технологий Sisyphus

Spt (http://wiki.sisyphus.ru/devel/spt) – это инструмент, позволяющий из репозитория Sisyphus создать готовый к загрузке экземпляр системы в виде:

  • Live-CD.
  • Инсталляционного диска, который является частным случаем Live?CD отличается от него только тем, что включает в себя alterator (http://wiki.sisyphus.ru/Alterator) – штатный конфигуратор системы, построеной на основе Sisyphus.
  • Архива корневой файловой системы для использования в качестве виртуального сервера в какой-либо системе виртуализации или для установки на диск физического компьютера.
  • Тонкого клиента для загрузки по сети посредством 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

Комментарии отсутствуют

Добавить комментарий

Комментарии могут оставлять только зарегистрированные пользователи

               Copyright © Системный администратор

Яндекс.Метрика
Tel.: (499) 277-12-41
Fax: (499) 277-12-45
E-mail: sa@samag.ru