Использование XenServer и другого free/opensource в ручном тестировании

    Хочу рассказать о том, как прижился XenServer в нашем отделе тестирования, а так же немного о другом используемом free/opensource (DRBL + Clonezilla, Tape redirector, MHVTL). Выбор остановился на этих продуктах не по идеологическим, а сугубо практическим причинам — они удобные и масштабируемые. Но есть и ряд проблем, которым я также уделю внимание в этой статье.
    Под катом много текста и изображений.







    Я работаю в команде тестирования Acronis в отделе поддержки пользователей, воспроизвожу пользовательские проблемы. Начиная с имитации дискового окружения и аппаратной части, заканчивая программным обеспечением и его специфическими настройками. Стояла задача — обеспечить работу тестового стенда с помощью двух рабочих станций. Были перепробованы и ESXi, Hyper-V, Proxmox и другие, но все же остановились на использовании XenServer. И вот что из этого получилось.


    Аппаратное обеспечение


    Изначально имелся один диск, на который и был установлен XenServer 4.2. По началу скорость устраивала. Чуть позже сервером стало пользоваться уже два человека, появилось уже тяжелое окружение (например, Exchange 2003 с базой данных в 300гб, которая постоянно работала под нагрузкой) и сразу стало понятно, что для комфортной работы текущей производительности явно недостаточно. Виртуальные машины грузились долго (а одновременно работает в среднем 20 штук на одном сервере), IO Wait часто достигал нескольких секуд. Надо было что-то делать.

    Первое, что пришло в голову — RAID, но быстро это не реализовать, а решение нужно вчера. Как раз тогда в репозитории Debian добавили ZFS и было решено попробовать именно его.



    Каждая из двух рабочих станций имеет материнскую плату с 4-мя SATA2 портами, 16ГБ ОЗУ и гигабитные сетевые карты.
    Первая машина была выделена под гипервизор и загружается с USB флешки.
    На вторую машину была установлена серверная Ubuntu 11.04, все необходимые пакеты для работы ZFS. Установлены 4ре диска по 1ТБ каждый. Был выбран RAID 10. Так как на материнской плате только 4 SATA порта, то ОС так же установлена на USB флешку.
    Сам гипервизор соединен с ZFS через гигабитный свитч.
    Были проведены эксперименты, прочитаны статьи, в итоге на ZFS была включена поддержка сжатия GZIP, выключена проверка контрольных сум, от дедупликации так же отказались. Это оказалось самым оптимальным решением, все 8 ядер очень редко нагружаются на 100%, и памяти вполне хватает. К сожалению, кэш на SSD протестировать не удалось :)

    Сама файловая система экспортируется наружу через NFS, нативно поддерживаемый самим ZFS. А XenServer, да и ESX работают с NFS хранилищами. Это позволило использовать это же хранилище одновременно и для 2-х XenServer и для 3-х ESXi. Из этого ряда выбивается Hyper-V, который с завидным упорством и в Server 2012 отказывается работать с NFS, но это на совести MS.



    Сконфигурированный ZFS выглядит так:
    root@xenzfs:~# zpool status
      pool: xen
     state: ONLINE
    config:
    
    	NAME        STATE     READ WRITE CKSUM
    	xen         ONLINE       0     0     0
    	  mirror-0  ONLINE       0     0     0
    	    sda     ONLINE       0     0     0
    	    sdb     ONLINE       0     0     0
    	  mirror-1  ONLINE       0     0     0
    	    sdc     ONLINE       0     0     0
    	    sdd     ONLINE       0     0     0
    
    errors: No known data errors
    

    
    root@xenzfs:~# zpool list xen
    NAME   SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT
    xen   1.81T  1.57T   245G    86%  1.00x  ONLINE  -
    


    Скорость записи на диск примерно соответствует удвоенной скорости отдельного диска.

    На данный момент до 40 виртуальных машин одновременно работают без каких либо проблем с производительностью, тогда как раньше 20 машин приводили к провисаниям IOW до 5 секунд. Сейчас, спустя полтора года с запуска ZFS решение можно признать надежным, быстрым и крайне бюджетным. Поднятые NFS и CIFS сервера на хранилище позволяют его использовать и для других целей:
    XenServer позволяет создавать ISO хранилища на сетевых дисках CIFS. Продукты перед релизным тестированием собираются в ISO образ (инсталляторы для Windows и Linux разных локализаций), который, в свою очередь, загружен на сетевой диск во внутренней гигабитной сети. В результате, одним движением мышки (субьективно XenCenter гораздо удобнее и быстрее в такой работе, чем vSphere) или скрипта мы вставляем эту ISO в виртульный CDROM (можно и десяткам машин одновременно) и ставим продукт прямо «с диска», что значительно экономит время на копировании больших (2GB+) файлов. Конечно, такое линейное чтение просаживает сеть, особенно если установка идет сразу с 5+ машин, но это все равно очень удобно.



    Гигабитная сеть, через которую подключено хранилище, доступна и для виртуальных машин. Таким образом, можно использовать CIFS для любых других тестов. Для удобства на ZFS машине так же был поднят DHCP сервер.




    Кроме виртуальных машин, тестировать приходится и на обычных рабочих станциях. Это тестирование и с ленточными накопителями и всевозможные REV, RDX диски и т.д. Нужно постоянно и быстро разворачивать различное окружение на машины. Будь то ESX гипервизор или Windows 2008R2 с Hyper-V или SLES с поднятым iSCSI multipath. Для этой цели используется DRBL

    DRBL в сочетании с Clonezilla позволяет быстро разворачивать образы чере PXE с гибкими сценариями, а так же служит NAT сервером для уже развернутых машин.



    Машины во внутренней сети имеют доступ через NAT во внешнюю сеть, а к ним самим через iptables имеется доступ по RDP.
    
    iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 3390 -j DNAT --to 192.168.1.50:3389
    iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 3391 -j DNAT --to 192.168.1.51:3389
    iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 3392 -j DNAT --to 192.168.1.52:3389
    


    Набор различных ленточных накопителей подключен к одной машине, на которой используется бесплатный Tape Redirector, соответственно любая виртуальная машина может их использовать по iSCSI. Так же имеется отдельная виртуальная машина с поднятым MHVTL, но аппаратные накопители тоже нужны — не все проблемы проявляются на VTL.

    Развертывание/клонирование делается в два клика с помощью утилиты, написанной на Perl+GTK. Работает достаточно просто — компонуется команда из блоков и выполняется через SSH. Кому интересно, репозиторий тут. Код сырой, но работает github.com/Pugnator/GTKdrbl




    Интерфейс



    Субьективно удобный интерфейс представлен только Citrix — XenCenter, но он, к сожалению, только под Windows. Кроме того, по какой-то причине в интерфейс не были выведены важные и полезные возможности, например, возможность поставить виртуальную машину на паузу или, к сожалению, часто нужную опцию перезагрузки XAPI, когда какая-либо виртуальная машина повисает намертво
    image

    Есть и другие варианты, например sourceforge.net/projects/openxenmanager, но они они оказались недостаточно стабильными.

    Существует VNC веб прокси www.xvpsource.org
    image

    Удобно, но требует Java, включенную в браузере (бывают проблемы), ну и в первую очередь это VNC, работать как с полноценным интерфейсом нельзя.

    В результате на GTK3 был написан клиент под Linux, который так же можно использовать и в вебе. GTK Broadway позволяет через HTML5 + WebSockets в браузере получить вот такой инструмент

    image

    Данная технология не позволяет использовать его для множества пользователей одновременно, но с помощью неё можно полноценно работать как на Linux, так и через веб, лишь меняя параметры запуска (например, вынести в две иконки).

    При использовании HTML5 фронтэнда накладывается множество ограничений на само приложение, и эти ограничения почему-то недокументированы. Примером ограничения является невозможность использования иконок в трее, относительного позиционирования окна и прочее. Последствия — от нестабильной работы до падений.
    С документацией все плохо, на данный момент изучение broadway представляет собой чтение исходных кодов GTK3, так как кроме странички описания и новостей 3-х летней давности по broadway ничего нет.


    API



    API существует для C, C#, Java, Python и Powershell. Для С сборка только под линукс, но методом небольшой доработки исходников (на тот момент в mingw отсутствовала реализация какой-то функции) все успешно собралось и под Windows (MinGW). API работает через HTTP(S). API предоставляет и достаточно низкоуровневый доступ к виртуальным машинам.

    Диски


    Хотелось многого, от быстрого просмотра MBR кликнув мышкой, до извлечения файла с виртуалки или закачивания оного назад на выключенной виртуальной машине.
    Такое бывает нужно, к примеру, в случае BSOD — извлечь реестр (и/или отредактировать его и залить обратно, например, выключив какой-либо драйвер), либо отредактировать опции загрузчика (включить дебаг через последовательный порт) и много всего. Для таких целей приходится прибегать к помощи загрузочного диска.
    Но можно и иначе, виртуальную машину возможно экспортировать через HTTP GET в формате XVA, который представляет из себя TAR архив, внутри которого лежат блоки диска.

    $ tar -tvf test.xva
    ---------- 0/0           17391 1970-01-01 01:00 ova.xml
    ---------- 0/0         1048576 1970-01-01 01:00 Ref:946/00000000
    ---------- 0/0              40 1970-01-01 01:00 Ref:946/00000000.checksum
    ---------- 0/0         1048576 1970-01-01 01:00 Ref:946/00000007
    ---------- 0/0              40 1970-01-01 01:00 Ref:946/00000007.checksum
    ---------- 0/0         1048576 1970-01-01 01:00 Ref:949/00000000
    ---------- 0/0              40 1970-01-01 01:00 Ref:949/00000000.checksum
    ---------- 0/0         1048576 1970-01-01 01:00 Ref:949/00000003
    ---------- 0/0              40 1970-01-01 01:00 Ref:949/00000003.checksum
    


    Если на лету читать этот архив, можно легко получить искомый MBR, и узнав смещения и типы разделов, читать файлы. Но на данный момент реализовано только извлечение MBR. Начиная с версии XenServer 6.2 есть возможность экспортировать RAW диск. В будущих версиях XenServer обещают ввести возможность экспортировать только дельту диска с произвольного смещения, что открывает новые возможности.

    Сеть


    Контролировать работу с сетью виртуальной машины можно разными путями. Обычно это wireshark/tcpdump, установленные в виртуальную машину. Собирается нужный дамп и переносится в другое место для изучения. Но есть способ лучше — каждая запущенная виртуальная машина имеет свой dom-id, в соответствии с ним имеется и VIF устройство вида vifDOMID.0, доступное с гипервизора. Подключившись по SSH к гипервизору, можно легко получить дамп для любой произвольной включенной виртуальной машины (разумеется, имеющей добавленные сетевые карты), что делает тестирование чище и удобней (не нужно ставить PCAP драйвера). Далее, согаласно совету из Q&A программа делает пайп и запускает Wireshark. И в режиме реального времени получаем/фильтруем трафик.

    Guest tools и последовательный порт


    API не предоставляет никаких средств, аналогичных guest operation у vix vmWare, например, копирование файлов.
    И если с установкой основного софта проблема решается с использованием ISO на гигабитной сети, то с передачей команд/сборкой логов, просмотром данных все не так гладко. Приходится использовать промежуточные сетевые диски, а это не всегда возможно (условия тестирования, изолированная сеть). В любом случае это отнимает время и неудобно.

    Самая первая идея, пришедшая в голову — использовать виртуальный последовательный порт. Можно активировать виртуальный com-порт, который средствами XenServer транслируется по TCP. Теперь, если по соответствующему адресу открыто соединение, мы можем отправлять/принимать сообщения на скорости 115200. На виртуальной машине же запущена фоновая программа «последовательный порт-CLI прокси», которая и выполняет транслирование команд из последовательного порта и возвращает результаты.
    Тут не обошлось без подводных камней:
    1)Передача обрывается при достижении 65535 переданных байт, если клиент (виртуальная машина) не передала за это время хотя бы один байт.
    2) Включение порта работает только после рестарта. То есть включать необходимо либо на выключенной виртуальной машине, либо перезагружать её.
    3) Если по какой-либо причине соединение оборвется, восстановить его до перезагрузки не имеется возможности.
    4) Ну и самое плохое — если TCP сервер не отвечает — виртуальная машина зависнет на старте.

    По этим причинам, параллельно искались другие методы, например, через xenstore. Это хранилище, доступное разным доменам. В том числе и виртуальным машинам. Там буфер порядка двух мегабайт, и достаточно быстрая запись. Но чтение медленнее чем 115200, требуются установленные xen tools (что не всегда возможно) и требуется тщательно тестировать код. Например, если записать больше, чем XENSTORE_PAYLOAD_MAX, судя по комментариям в исходниках драйверов, это грозит фатальными последствиями.

    На данный момент думаю об использовании паравиртуального последовательного порта виртуальной машины через ssh тоннель на гипервизор, по аналогии с методом, указанным выше про сетевые карты. Судя по всему, это максимально безопасный и быстрый метод. На данный момент лишь проверено, что это осуществимо.

    Точно таким же образом можно производить дебаг ядра Windows/Linux, пробрасывая по TCP/SSH последовательный порт, а локально через пайп уже подключается WinDbg, к примеру. Для таких целей была создана отдельная виртуальная машина с набором символов под все доступные версии Windows.

    Заключение



    Работая с XenServer API и изучая его, на себе испытал многие плюсы и минусы opensource. Широкие возможности упираются в слабую документацию. Если VIX описан очень подробно, то с тем же xenserver api — 3 примера, 4 тестовых файла и комментарии в хэдерах исходников. Код понятный, но как связать отдельные функции — понятно либо разработчикам, либо тем, кто глубоко знает архитектуру Xen. Например, такая задача как узнать размер диска — нигде не описана. А не зная архитектуры — догадаться не слишком просто. Конечно, со временем вникая и углубляясь в строение Xen, многое стало понятней. Но на многие вопросы я так и не получил ответа, а в IRC чатах по выходным никто не отвечает — одинокие посетители пишут, что «сегодня же воскресение» :).
    Но прогресс есть, за год пополнились wiki, статьи, примеры с демонстрацией новых возможностей. Очень надеюсь, что в будущем XenServer сможет стать сильным игроком на рынке с хорошим набором third party software
    Acronis 84,61
    Компания
    Поделиться публикацией
    Комментарии 11
    • 0
      XenServer интересный проект, с туманным будущем.
      Я столкнулся с неприятной особенностью xenserver. Какая либо из функций или вм может перестать работать после совершенно не очевидных действий или вовсе без явной причины, а от лога вы не получите ровном счетом никакой информации.
      Пример из недавнего прошлого. Вы делаете экспорт вм, но в процессе возникает ошибка записи(например nfs сервер на который вы делали экспорт стал недоступен). Ну что же, бывает. Вы пробуете повторить процесс или же просто включить вм, но в ответ получаете ошибку без каких-либо разъяснений.
      Проведя некоторое время с консолью вы заметите что в списке вм присутствуют скрытые (зачем? зачем делать скрытые вм??) которые никак не отображаются в xencentre, c именем vmtransfer. Причем их может быть не одна. Проявив смекалку и на всякий случай закрыв глаза(а кто их знает зачем они) вы удаляет этих призраков и все начинает работать.
      Еще пример. Импорт вм. Допустим случилось страшное и вам нужно восстанавливать вм из резервной копии. Время поджимает, шеф смотрит на вас с надеждой. Но у вас есть бэкап, не о чем волноваться. Так? Не так. Время которое потребуется на восстановление не поддается прогнозированию. 100 гигабайтная вм по гигабитной сети может восстанавливаться 4 часа. Прогресс бар в xencenter не отображает реального прогресса. Через консоль вы тоже не увидите ни скорости копирования ни оставшегося времени.
      Есть конечно и преимущества в виде практически стандартного linux дистрибутива в основе. Однако работать с ним нужно крайне осторожно, любые изменения конфигов или установка софта может совершенно неожиданно повлиять на жизнеспособность xenserver.
      Xenserver бесплатный. Из коробки есть очень много функций за которые у hyper-v или vmware нужно хорошенько заплатить. Но поддержка в некоторых ситуациях может отнимать очень много времени. Если как в вашем примере вы сможете дополнить его другим опесорс\бесплатным софтом то может получится очень интересно.
      • +1
        transfervm испльзуется потому что раньше не было возможности клонировать диск сам по себе. Это делается через аткую промежуточную VM. Она доступна как opensource и кажется имеет кучу скриптов на питоне. Что касается импорта, то тут есть нюанс, он же касается и экспорта. По умолчанию не экспортируются пустые блоки. То есть если блок диска размером в 1Мб имеет внутри одни нули, он просто скипается. Поэтому на выходе получим виртуальную машину размером в, к примеру, 10Гб. А 500гб пустых блоков пропущены. При импорте же, это все будет восстанавливаться и прогресс импорта может подвиснуть надолго…
        • 0
          если вы используете nfs, то диски там по-моему лежат в виде отдельных vhd файлов.
          • 0
            Да, но экспортируется-то как XVA контейнер все равно
      • +1
        Как человек, несколько лет потративший на XenSever, могу сказать только одно — никогда больше. Переходите на KVM, там всё куда более человеческое.
        • 0
          Я с нетерпением ждал именно вашего комментария. KVM в виде Proxmox и RHEV тестил и использую по работе. Первый очень интересен — наблюдаю за ним, времени не так много свободного, но когда я его интенсивно испытывал не было ещё толком никакого API. Но подход авторов понравился.
          • 0
            Вообще, сейчас наступает эпоха, когда будет просто не важно, какой там гипервизор снизу. Ещё несколько лет — и опенстек из шаманства на месяц превратится в что-то подъёмное силами одного человека за пару вечеров, а потом и вовсе в «казуальщину».
            • 0
              Хотелось бы верить. Сейчас путь по которому идет тот же vmWare меня пугает. В том плане что софт тяжелеет, багов все больше. Пытаются охватить все уголки рынка
              • +2
                там революция другого вида назревает. Лозунг примерно такой: not as the pet, but as a kettle.

                Мол, слишком много внимания на нужды самого сервера. Его дело стоять в стойлке и делать что сказали. Отсюда толерантность к потециальной потере одиночного инстанса, особое внимание к orchestration tools, системам автоматического деплоя и шардинга.

                Всё ещё впереди, сейчас оно очень грубое и пугающее — но ситуация с старым легасёвым блотварным серверным хозяйством всех достала.
        • 0
          > Ubuntu 11

          Простите что? Не бывает Ubuntu 11. Бывает 11.04 или 11.10. А 11 не бывает.
          Хоть бы правила нумерации дистриба почитали, прежде чем писать что-то.
          • 0
            Прошу прощения за неточность, поправил

          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

          Самое читаемое