OpenVZ

[McZim]

Всем привет. Хочу поделиться опытом использования системы виртуализации OpenVZ.

Сразу же выражаю ОГРОМНЕЙШУЮ БЛАГОДАРНОСТЬ нашему RXL!!! За помощь в вопросах по OpenVZ.

Я не буду приводить каких то настроек или конфигов, я просто поделюсь опытом.

Итак, в эти новогодние праздники у нас "умерло" два сервера. Оба сервера отвечали за 6 вэб проталов. Мне пришлось выходиь на работу и поднимать временный сервер (в качестве сервера выступал обычный десктопный комп). Некоторые данные (наработки по порталам) удалось спасти, в частности те что были в svn, на другом сервере, а некоторые пришлось восстанавливать, благо они были сделаны в декабре. В это же время был заказан, в срочном порядке, новый сервер. Но почему один? Нужно же два! Я настоял на том что бы купили именно один сервер, тем самым экономя деньги, дальше вы поймете почему.

В период между падением первого и второго серверов, я встречался с RXL попить пивка. Мы немного поговорили о Apache и Nginx, и он мне рассказал про OpenVZ. Я и раньше слышал о Solaris Zones, FreeBSD Jails, но не работал. И тут подвернулся такой случай. После пива, дома вечером я переварил все что мне рассказал Ромка и решил попробовать "рассувать" по виртуальным контейнерам вэб порталы.

На этом же временно сервере, я установил все необходимое ПО для виртуализации, создал необходимые контейнеры, простым копированием файлов переместил все вэб порталы, сделал бэкап контейнеров и стал ждать нового сервера Вчера приехал новый сервер. Я установил на него 64 битную ОС (CentOS 5-5). Подготовил необходимый софт для виртуализации и с помощью восстановления из бэкапа, развернул виртуальные контейнеры. Некоторые контейнеры небольшие, по 200-400 метров, а некоторые по 10-17 гигов.

В итоге, по времени установки ОС на новый сервер, перемещению 10 контейнеров (так как неожиданное еще некоторые сервисы попросились в виртуальное окружение), у меня заняло 5 часов. Сегодня с утра я отнес сервер в серверную, смонтировал в стойку, поднял все виртуальные контейнеры. Затем быстро переключил два патч корда в новый сервер из временного сервера и перезапустил сеть на новом сервере.

Пользователи почувствовали лишь кратковременный обрыв связи, некоторые вообще не в курсе что что-то было, так как пили чай А тем временем они уже на новом железе

Контейнеры по не настроены, им еще предстоит быть ограниченными в ресурсах.

Ну и немного статистики.

[root@openvz-1 ~]# vzlist -a
      CTID      NPROC STATUS    IP_ADDR         HOSTNAME
       101         14 running   192.168.201.101 WEB-bm3
       102         31 running   192.168.201.102 WEB-bm7
       103         17 running   192.168.201.103 WEB-hd
       104          8 running   192.168.201.104 Postfix
       105          8 running   192.168.201.105 Teleports
       106         10 running   192.168.201.106 svn
       107          9 running   192.168.201.107 Redmine
       108          9 running   192.168.201.108 Zabbix
       109         15 running   192.168.201.109 Nginx
       110          9 running   192.168.201.110 OpenVPN

[root@openvz-1 ~]# cat /proc/user_beancounters
Version: 2.5
       uid  resource                     held              maxheld         
      110:  kmemsize                   878015              1795658 
            shmpages                        1                  657                 
            numproc                         9                   20 
            physpages                    1195                 1938
            tcpsndbuf                   35008                63592
            tcprcvbuf                   32768                    0

      101:  kmemsize                  1812381              2591483
            shmpages                      157                  157
            numproc                        14                   20
            physpages                    3656                15885
            tcpsndbuf                  122528               503240
            tcprcvbuf                  114688                    0
           
      102:  kmemsize                  3284544              3704346
            shmpages                     2077                 2093
            numproc                        31                   35
            physpages                    8448                32597
            tcpsndbuf                  422704               757608
            tcprcvbuf                  188976               188976
           
      103:  kmemsize                  2694868              4564797
            shmpages                      157                  813
            numproc                        22                   31
            physpages                    5123               188202
            tcpsndbuf                  140032              2625600
            tcprcvbuf                  131072               990624
           
      104:  kmemsize                   770562              1452279
            shmpages                        1                    1
            numproc                         8                   16
            physpages                     778                 1453
            tcpsndbuf                   17504                    0
            tcprcvbuf                   16384                    0

      105:  kmemsize                   784444              1628135
            shmpages                        1                    1
            numproc                         8                   15
            physpages                     777                 2006
            tcpsndbuf                   17504                    0
            tcprcvbuf                   16384                    0

      106:  kmemsize                   929590              1476534
            shmpages                        1                    1
            numproc                        10                   15
            physpages                    1185                 1791
            tcpsndbuf                   35008                    0
            tcprcvbuf                   32768                    0

      107:  kmemsize                   868884              1605302
            shmpages                        1                    1
            numproc                         9                   15
            physpages                    1052                 1788
            tcpsndbuf                   17504                    0
            tcprcvbuf                   16384                    0

      108:  kmemsize                   870137              1546605
            shmpages                        1                    1
            numproc                         9                   15
            physpages                    1050                 1788
            tcpsndbuf                   17504                    0
            tcprcvbuf                   16384                    0

      109:  kmemsize                  1436309              2139865
            shmpages                      642                  978
            numproc                        15                   20
            physpages                    2443                 2962
            tcpsndbuf                  204760              1229800
            tcprcvbuf                  131072              2395216

top - 14:21:28 up  3:23,  1 user,  load average: 0.03, 0.10, 0.08
Tasks: 544 total,   1 running, 543 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:  14327956k total,  5866316k used,  8461640k free,   106948k buffers
Swap: 10241428k total,        0k used, 10241428k free,  5414216k cached

Как видно второй сервер нам вовсе ненужен.

[Red_Lion]

А если настроить drbd+hb и lvm для бэкапирования, то система будет с минимальным временем лежать даже при физическом отказе одного сервера.

Но для этого понадобится второй сервер...

[RXL]

DRBD - штука неплохая, но производительность оставляет желать лучшего. Лучше использовать NAS: и централизация данных, и независимость от сервера (даже отсутствует необходимость в дисках на рабочих серверах - можно делать сетевую загрузку).

По умолчанию используется протокол Ц, дающий максимум гарантий: данные записываются на локальный диск и на удаленный диск и только потом возвращается управление - это ужасно медленно. Тестировал я с помощью dbench на сетке 1ГБ и дисках SATA enterprise 7200 и 10000 rpm: производительность, по сравнению с одиночным локальным винтом, падает от 2 до 10 и более раз в зависимости от параметров (обычно - в 3-5 раз медленнее). Понятное дело, что быстрее локального диска будет только локальный RAID 0, но как-то уж очень быстро замедляется. Пробовал перейти на протокол Б (аналогичен Ц, но удаленный сервер рапортует только о получении данных, а не о их записи) и повторить тесты - разницы с Ц почти нет. Остается протокол А, где управление возвращается после локальной записи и помещения данных в буфер сокета, но надежность уже отсутствует замедление получается неоправданным.
Еще одним недостатком DRBD является то, что он автоматически работает в узком диапазоне ситуаций, а в остальных нужны ручные манипуляции.
Т.ч. после полугода размышлений и экспериментов решил, что лучше использовать NAS (NFS или SMB - еще надо решить, но думаю, что NFS).

P.S.: расчеты стоимости железа для двух вариантов (2 сервера с DRBD или 2 сервера + NAS) показали, что вариант с NAS даже немного дешевле, а кроме того, сервер NAS может выступать арбитром в HB - трое всегда надежнее, чем двое - опасность brain split ниже.

[Red_Lion]

RXL, syncrate дефолтный? сеть идет через коммутатор?
/me просто когда настраивал схему с drbd именно на этом погорел

Кстати, использовать nfs с openvz не лучшая идея - производительность будет просто ужасная (а с nfs4 вообще не будет работать). iSCSI в данном случае отлично спасает, но там splitbrain по вине hb будет уже критично.

P.S. И нет, это не наезд опять

[RXL]

Да, через свитч включены. Свитч нормальный. FTP между серверами дает 91 МБ/с.

Скорость синхронизации здесь не при чем - она не влияет на скорость работы в засинхронизированном состоянии.

[Red_Lion]

RXL, в документации по drbd есть рекомендация соединять сервера напрямую через 1gb или (лучше) inf. band. Это связано не только с их пропускной способностью, а с задержками в самой сети.

[RXL]

Была у меня мысль про задержки. Делал теоретический расчет. Он показал, что поиск на HDD намного больше сетевых задержек.

Общался прошлым летом на эту тему с людьми на forum.openvz.org. Они критиковали DRBD. После неутешительных результатов моих тестов я их тоже поддерживаю. Если не нужна нагрузка на диск, то DRBD имеет право на жизнь, но для надежности и скорости нужно что-то иное.