1. Подготовим конфиг по умолчанию (пока что разделим все ресурсы поровну на 4 виртуальных сервера):
[root@mx1 ~]# vzsplit -n 4 -f default
The optimal swap space size is 1985 Mb, twice bigger than the RAM size
Config /etc/vz/conf/ve-default.conf-sample was created
2. Создаем и настраиваем первый виртуальный сервер:
[root@mx1 ~]# vzctl create 101 --ostemplate centos-4-x86_64-minimal
Creating VE private area (centos-4-x86_64-minimal)
Performing postcreate actions
VE private area was created
Автозапуск:
[root@mx1 ~]# vzctl set 101 --onboot yes --save
Saved parameters for VE 101
Имя хоста:
[root@mx1 ~]# vzctl set 101 --hostname proxy.lindex.ru --save
Saved parameters for VE 101
"Проброс" интерфейса eth1 в VE101
[root@mx1 ~]# vzctl set 101 --netdev_add eth1 --save
Saved parameters for VE 101
Добавляем "локальный" интерфейс (для общения со своей локальной сетью и другими VE):
[root@mx1 ~]# vzctl set 101 --ipadd 172.16.0.2 --save
Adding IP address(es): 172.16.0.2
Configure meminfo: 49152
Saved parameters for VE 101
Заходим в VE101, настраиваем интерфейс и маршруты и проверяем работу сети:
[root@mx1 ~]# vzctl enter 101
entered into VE 101
[root@proxy /]# ifconfig
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:562958543487006 errors:0 dropped:0 overruns:0 frame:0
TX packets:1195818864963437 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1688892809938396 (1.5 PiB) TX bytes:1886351287 (1.7 GiB)
venet0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:127.0.0.1 P-t-P:127.0.0.1 Bcast:0.0.0.0 Mask:255.255.255.255
UP BROADCAST POINTOPOINT RUNNING NOARP MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
venet0:0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:172.16.0.2 P-t-P:172.16.0.2 Bcast:172.16.0.2 Mask:255.255.255.255
UP BROADCAST POINTOPOINT RUNNING NOARP MTU:1500 Metric:1
[root@proxy /]# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.0.2.0 * 255.255.255.0 U 0 0 0 venet0
169.254.0.0 * 255.255.0.0 U 0 0 0 venet0
default 192.0.2.1 0.0.0.0 UG 0 0 0 venet0
[root@proxy /]# ping 172.16.0.222
PING 172.16.0.222 (172.16.0.222) 56(84) bytes of data.
64 bytes from 172.16.0.222: icmp_seq=0 ttl=127 time=27.6 ms
64 bytes from 172.16.0.222: icmp_seq=1 ttl=127 time=0.136 ms
--- 172.16.0.222 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.136/13.879/27.622/13.743 ms, pipe 2
[root@proxy /]# ifconfig eth1 78.107.3.98/28 up
[root@proxy /]# ifconfig
eth1 Link encap:Ethernet HWaddr 00:04:23:D1:4D:F9
inet addr:78.107.3.98 Bcast:78.107.3.111 Mask:255.255.255.240
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:281021 errors:0 dropped:0 overruns:0 frame:0
TX packets:37609 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:22663307 (21.6 MiB) TX bytes:6182088 (5.8 MiB)
Base address:0x3000 Memory:b8920000-b8940000
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:562958543487008 errors:0 dropped:0 overruns:0 frame:0
TX packets:1195818864963439 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1688892809938593 (1.5 PiB) TX bytes:1886351484 (1.7 GiB)
venet0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:127.0.0.1 P-t-P:127.0.0.1 Bcast:0.0.0.0 Mask:255.255.255.255
UP BROADCAST POINTOPOINT RUNNING NOARP MTU:1500 Metric:1
RX packets:42 errors:0 dropped:0 overruns:0 frame:0
TX packets:43 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:15064 (14.7 KiB) TX bytes:3077 (3.0 KiB)
venet0:0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:172.16.0.2 P-t-P:172.16.0.2 Bcast:172.16.0.2 Mask:255.255.255.255
UP BROADCAST POINTOPOINT RUNNING NOARP MTU:1500 Metric:1
[root@proxy /]# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
78.107.3.96 * 255.255.255.240 U 0 0 0 eth1
192.0.2.0 * 255.255.255.0 U 0 0 0 venet0
169.254.0.0 * 255.255.0.0 U 0 0 0 venet0
default 192.0.2.1 0.0.0.0 UG 0 0 0 venet0
[root@proxy /]# route del default
[root@proxy /]# route add default gw 78.107.3.97
[root@proxy /]# route add -net 172.16.0.0/24 dev venet0
[root@proxy /]# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
78.107.3.96 * 255.255.255.240 U 0 0 0 eth1
172.16.0.0 * 255.255.255.0 U 0 0 0 venet0
192.0.2.0 * 255.255.255.0 U 0 0 0 venet0
169.254.0.0 * 255.255.0.0 U 0 0 0 venet0
default 78.107.3.97 0.0.0.0 UG 0 0 0 eth1
[root@proxy /]# ping 172.16.0.222
PING 172.16.0.222 (172.16.0.222) 56(84) bytes of data.
64 bytes from 172.16.0.222: icmp_seq=0 ttl=128 time=1.18 ms
64 bytes from 172.16.0.222: icmp_seq=1 ttl=127 time=0.212 ms
--- 172.16.0.222 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.212/0.699/1.186/0.487 ms, pipe 2
[root@proxy /]# ping 78.107.3.97
PING 78.107.3.97 (78.107.3.97) 56(84) bytes of data.
64 bytes from 78.107.3.97: icmp_seq=0 ttl=255 time=1.07 ms
64 bytes from 78.107.3.97: icmp_seq=1 ttl=255 time=14.4 ms
--- 78.107.3.97 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1000ms
rtt min/avg/max/mdev = 1.072/7.736/14.400/6.664 ms, pipe 2
[root@proxy /]# ping ya.ru
PING ya.ru (213.180.204.8) 56(84) bytes of data.
64 bytes from ya.ru (213.180.204.8): icmp_seq=0 ttl=56 time=2.56 ms
64 bytes from ya.ru (213.180.204.8): icmp_seq=1 ttl=56 time=8.81 ms
64 bytes from ya.ru (213.180.204.8): icmp_seq=2 ttl=56 time=2.35 ms
--- ya.ru ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 2.355/4.576/8.811/2.996 ms, pipe 2
[root@proxy /]# ping 195.90.159.66
PING 195.90.159.66 (195.90.159.66) 56(84) bytes of data.
64 bytes from 195.90.159.66: icmp_seq=0 ttl=52 time=4.63 ms
64 bytes from 195.90.159.66: icmp_seq=1 ttl=52 time=4.29 ms
--- 195.90.159.66 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 4.290/4.461/4.632/0.171 ms, pipe 2
среда, июля 25, 2007
понедельник, июля 23, 2007
iptables внутри виртуального сервера
Судя по множеству форумов и статей, прочитанных мной за последнее время, iptables должен настраиваться и работать "внутри" виртуального сервера так же, как и на реальном сервере. Однако либо я что то не допонял, либо одно из восьми :-)
Вот конкретная ситуация (или проблема - смотря с какой стороны посмотреть):
На физическом сервере (CentOS 4.4 x86_64) запущено несколько виртуальных, в том числе виртуальный шлюз (101), который должен пропускать весь трафик через себя на остальные сервера. У него есть 2 сетевых интерфейса: venet0 (виртуальный для связи между виртуальными серверами) с адресом из локальной сети (172.16.0.a) и физический, с реальным адресом a.b.c.98.
С этого виртуального сервера (101) нормально пингуются и локальные и внешние адреса (172.16.0.х или например ya.ru). А вот iptables работать не хочет:
# ifconfig
eth1 Link encap:Ethernet HWaddr 00:00:00:00:00:03
inet addr:a.b.c.98 Bcast:a.b.c.111 Mask:255.255.255.240
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:90082 errors:0 dropped:0 overruns:0 frame:0
TX packets:2424 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:6803187 (6.4 MiB) TX bytes:209890 (204.9 KiB)
Base address:0x3000 Memory:b8920000-b8940000
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:10 errors:0 dropped:0 overruns:0 frame:0
TX packets:10 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1356 (1.3 KiB) TX bytes:1356 (1.3 KiB)
venet0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:127.0.0.1 P-t-P:127.0.0.1 Bcast:0.0.0.0 Mask:255.255.255.255
UP BROADCAST POINTOPOINT RUNNING NOARP MTU:1500 Metric:1
RX packets:1395 errors:0 dropped:0 overruns:0 frame:0
TX packets:1429 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:76831 (75.0 KiB) TX bytes:438334 (428.0 KiB)
venet0:0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:172.16.0.2 P-t-P:172.16.0.2 Bcast:172.16.0.2 Mask:255.255.255.255
UP BROADCAST POINTOPOINT RUNNING NOARP MTU:1500 Metric:1
# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
a.b.c.96 * 255.255.255.240 U 0 0 0 eth1
172.16.0.0 * 255.255.255.0 U 0 0 0 venet0
192.0.2.0 * 255.255.255.0 U 0 0 0 venet0
169.254.0.0 * 255.255.0.0 U 0 0 0 venet0
default a.b.c.97 0.0.0.0 UG 0 0 0 eth1
Для упрощения ситуации я использую только те правила iptables, которые непосредственно используются при тестировании:
# iptables -t nat -A PREROUTING -p tcp -d a.b.c.98 --dport 3389 -i eth1 -j DNAT --to-destination 172.16.0.x:3389
# iptables -t nat -A POSTROUTING -s 172.16.0.2 -o eth1 -j SNAT --to a.b.c.98
А вот что происходит дальше:
# tcpdump -vv
tcpdump: WARNING: arptype 65535 not supported by libpcap - falling back to cooked socket
tcpdump: listening on venet0, link-type LINUX_SLL (Linux cooked), capture size 96 bytes
12:51:02.945767 IP (tos 0x0, ttl 114, id 50348, offset 0, flags [DF], proto 6, length: 48) 195.90.159.66.2886 > 172.16.0.x.3389: S [tcp sum ok] 319135398:319135398(0) win 64240
12:51:05.915276 IP (tos 0x0, ttl 114, id 51298, offset 0, flags [DF], proto 6, length: 48) 195.90.159.66.2886 > 172.16.0.x.3389: S [tcp sum ok] 319135398:319135398(0) win 64240
12:51:11.951111 IP (tos 0x0, ttl 114, id 53196, offset 0, flags [DF], proto 6, length: 48) 195.90.159.66.2886 > 172.16.0.x.3389: S [tcp sum ok] 319135398:319135398(0) win 64240
Вот конкретная ситуация (или проблема - смотря с какой стороны посмотреть):
На физическом сервере (CentOS 4.4 x86_64) запущено несколько виртуальных, в том числе виртуальный шлюз (101), который должен пропускать весь трафик через себя на остальные сервера. У него есть 2 сетевых интерфейса: venet0 (виртуальный для связи между виртуальными серверами) с адресом из локальной сети (172.16.0.a) и физический, с реальным адресом a.b.c.98.
С этого виртуального сервера (101) нормально пингуются и локальные и внешние адреса (172.16.0.х или например ya.ru). А вот iptables работать не хочет:
# ifconfig
eth1 Link encap:Ethernet HWaddr 00:00:00:00:00:03
inet addr:a.b.c.98 Bcast:a.b.c.111 Mask:255.255.255.240
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:90082 errors:0 dropped:0 overruns:0 frame:0
TX packets:2424 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:6803187 (6.4 MiB) TX bytes:209890 (204.9 KiB)
Base address:0x3000 Memory:b8920000-b8940000
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:10 errors:0 dropped:0 overruns:0 frame:0
TX packets:10 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1356 (1.3 KiB) TX bytes:1356 (1.3 KiB)
venet0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:127.0.0.1 P-t-P:127.0.0.1 Bcast:0.0.0.0 Mask:255.255.255.255
UP BROADCAST POINTOPOINT RUNNING NOARP MTU:1500 Metric:1
RX packets:1395 errors:0 dropped:0 overruns:0 frame:0
TX packets:1429 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:76831 (75.0 KiB) TX bytes:438334 (428.0 KiB)
venet0:0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:172.16.0.2 P-t-P:172.16.0.2 Bcast:172.16.0.2 Mask:255.255.255.255
UP BROADCAST POINTOPOINT RUNNING NOARP MTU:1500 Metric:1
# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
a.b.c.96 * 255.255.255.240 U 0 0 0 eth1
172.16.0.0 * 255.255.255.0 U 0 0 0 venet0
192.0.2.0 * 255.255.255.0 U 0 0 0 venet0
169.254.0.0 * 255.255.0.0 U 0 0 0 venet0
default a.b.c.97 0.0.0.0 UG 0 0 0 eth1
Для упрощения ситуации я использую только те правила iptables, которые непосредственно используются при тестировании:
# iptables -t nat -A PREROUTING -p tcp -d a.b.c.98 --dport 3389 -i eth1 -j DNAT --to-destination 172.16.0.x:3389
# iptables -t nat -A POSTROUTING -s 172.16.0.2 -o eth1 -j SNAT --to a.b.c.98
А вот что происходит дальше:
# tcpdump -vv
tcpdump: WARNING: arptype 65535 not supported by libpcap - falling back to cooked socket
tcpdump: listening on venet0, link-type LINUX_SLL (Linux cooked), capture size 96 bytes
12:51:02.945767 IP (tos 0x0, ttl 114, id 50348, offset 0, flags [DF], proto 6, length: 48) 195.90.159.66.2886 > 172.16.0.x.3389: S [tcp sum ok] 319135398:319135398(0) win 64240
12:51:05.915276 IP (tos 0x0, ttl 114, id 51298, offset 0, flags [DF], proto 6, length: 48) 195.90.159.66.2886 > 172.16.0.x.3389: S [tcp sum ok] 319135398:319135398(0) win 64240
12:51:11.951111 IP (tos 0x0, ttl 114, id 53196, offset 0, flags [DF], proto 6, length: 48) 195.90.159.66.2886 > 172.16.0.x.3389: S [tcp sum ok] 319135398:319135398(0) win 64240
пятница, июля 20, 2007
Выбор системы виртуализации
Решил я сделать кластер на работе (прокси, файрволл, почта, MySQL).
Долго думал, решил пока остановиться на OpenVZ - благо информации по ней прилично и в инете, и в журнале "Системный администратор" была довольно подробная статья.
Сразу должен заметить что по ходу работы над настройкой OpenVZ уже появились мысли со временем мигрировать на XEN.
Но пока что доводим до ума OpenVZ.
Итак, дано: 2 Intel сервера (по 2 двухядерных Xeon'а, пока что по 1 Гб ОЗУ - нарастим по факту ввода в эксплуатацию, по 2 400 Гб SATA2 винта, по 4 гигабитных сетевых). Дистрибутив (можно считать корпоративный стандарт) - CentOS 4.4. В процессе работы вышел 5.0, но пока я на него не перешел - не все нужные пакеты под него есть на сегодняшний день, а компилить и тем более дорабатывать пакеты для корпоративного сервера я категорически не приемлю - потом с обновлениями запаришься.
Для начала настроил DRBD+HEARTBEAT, особых проблем не было, в основном все по инетовским статьям делал. Единственно до чего сразу не допер, что надо явно указывать скорость синхронизации между узлами, иначе она по дефолту использует что-то вроде 30-50 Кб/с.
А вот дальше начались приключения.
Ставлю ядро OpenVZ - отказывается работать DRBD. Долго экспериментировал над разными ядрами. В итоге вроде последнее ядро из ветки 2.6.9 заработало на тестовой машине, но на сервере при загрузке висло намертво. В итоге поставил принудительно предыдущее - заработало.
Долго думал, решил пока остановиться на OpenVZ - благо информации по ней прилично и в инете, и в журнале "Системный администратор" была довольно подробная статья.
Сразу должен заметить что по ходу работы над настройкой OpenVZ уже появились мысли со временем мигрировать на XEN.
Но пока что доводим до ума OpenVZ.
Итак, дано: 2 Intel сервера (по 2 двухядерных Xeon'а, пока что по 1 Гб ОЗУ - нарастим по факту ввода в эксплуатацию, по 2 400 Гб SATA2 винта, по 4 гигабитных сетевых). Дистрибутив (можно считать корпоративный стандарт) - CentOS 4.4. В процессе работы вышел 5.0, но пока я на него не перешел - не все нужные пакеты под него есть на сегодняшний день, а компилить и тем более дорабатывать пакеты для корпоративного сервера я категорически не приемлю - потом с обновлениями запаришься.
Для начала настроил DRBD+HEARTBEAT, особых проблем не было, в основном все по инетовским статьям делал. Единственно до чего сразу не допер, что надо явно указывать скорость синхронизации между узлами, иначе она по дефолту использует что-то вроде 30-50 Кб/с.
А вот дальше начались приключения.
Ставлю ядро OpenVZ - отказывается работать DRBD. Долго экспериментировал над разными ядрами. В итоге вроде последнее ядро из ветки 2.6.9 заработало на тестовой машине, но на сервере при загрузке висло намертво. В итоге поставил принудительно предыдущее - заработало.
начнем-с ;-)
Долго собирался и вот все таки начинаю свой блог.
Для чего?
Во-первых, для самого себя - что бы не забывать и не искать заново какие то данные, технологии, моменты...
Во-вторых, может кому то еще пригодятся мои наработки...
Для чего?
Во-первых, для самого себя - что бы не забывать и не искать заново какие то данные, технологии, моменты...
Во-вторых, может кому то еще пригодятся мои наработки...
Подписаться на:
Сообщения (Atom)