Как стать автором
Обновить

Citrix Xen Center – Опыт работы с полностью бесплатной виртуализацией

Время на прочтение9 мин
Количество просмотров37K

Сразу опишу главный плюс такого решения – Это бесплатно! Любой может более менее полноценно администрировать рабочие места(Windows машины/сервера, linux сервера, любые ОС), работать с бекапами и эффективно использовать мощность железа.

Так уж вышло, что профессиональные решения типа VM Ware стоят очень приличных денег.

Введение

Данная статья преследует цель упростить жизнь таким же энтузиастам, которые по какой-то причине, не являясь большими devOps специалистами, уже развернули визор Xen Server и запустили на нем продакшен проекты.

Как правило, сталкиваясь с проблемами и сложностями на уже запущенной системе, с проектами в продакшене право на ошибку нет.

Здесь мы рассмотрим свой опыт работы, проблемы и их решения, приходящие в процессе эксплуатации Xen Server в полностью бесплатном режиме и без какой-либо подготовки, в формате «разберемся в процессе».

1. Базовая настройка и нюансы установки

Начнем с установки. Процесс довольно прост: скачиваем iso, нарезаем на usb и устанавливаем на свой новоиспеченный сервер, который по нашему плану будет крутить на себе много разных виртуальных машин на разных ip-адресах, позволяя использовать ресурсы оборудования значительно эффективнее и предоставлять нам прекрасные возможности создания снепшотов и работы с ними.

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

Итак, в процессе установки, точнее при ее завершении, будет задан важный вопрос про объединенную файловую систему – Enable thin provisioning (Optimised storage for XenDesktop). Суть всего этого глубже, но нам следует знать важную деталь: если мы ответим да, сможем в дальнейшем при подключении по ssh складывать файлы образов, используя пространство дисков, которые выбрали при установке. Стоит отметить, что в дальнейшем после установки мы сможем прицеплять сколько угодно новых дисков и инициализировать их в системе, но не в общем пространстве, о котором нас спрашивают при установке.

Почему важно иметь возможность использовать общее пространство? Это слегка упрощает разворачивание больших бекапов (снепшотов или образов). Если делать это через интерфейс, то при обрыве соединения весь процесс будет потерян. В случае передачи по sftp вы всегда сможете вернуться к тому же моменту и догрузить файл используя ftp клиент. Можно так же примонтировать сетевой диск и выполнить импорт с него, но здесь важна стабильность сетевого канала.

Есть важный нюанс: доступ к общему пространству, где по совместительству лежат все виртуальные машины основного раздела, происходит по адресу: /run/sr-mount/. Загружая туда файл, нам будет доступно все место из Local storage, но учтите, что в интерфейсе все, что мы займем своими бекапами, учитываться не будет и система в GUI будет говорить, что места больше (на самом деле нет). За этим необходимо следить.

!Важно! Если мы займем все место, а система будет думать, что оно есть, с виртуальными машинами начнет происходить страшная магия, и они начнут выключаться на ровном месте. Самое страшное в этой истории то, что не все машины запустятся после того как мы освободим место. С этим нужно быть предельно внимательными.

Все остальное в процессе установки на дальнейшую работу особо не влияет (по крайней мере в наших сценариях).

2. Запуск, подключение дисков, iso-образов и создание машин

После успешного запуска и подключение визора XenCenter из-под Windows (GUI работает только под ним) нам предоставляется возможность пользоваться благами виртуализации и создавать виртуальные машины.

При попытке создать машину нам сразу будет предложено использовать стандартный шаблон, загруженный через импорт снепшот (бекап) или снепшот от текущих машин. Есть так же Xen App, но в нашем бесплатном использовании он не актуален.

Как правило, стандартные шаблоны бесполезны и при создании новой машины, где мы будем устанавливаться с iso, нужно выбирать Other install media. В случае развертывания из снепшотов, разумеется, выбираем снепшот.

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

Из практических советов: в названии машины пишите ее полный ip-адрес, это упростит процесс администрирования, когда ваших виртуальных машин станет очень много.

Подключение локального репозитория ISO

Для установки любой ОС (а, разумеется, мы захотим поставить всё и вся) необходимо создать репозиторий, куда мы будем складывать свои iso.

  1. Создаем папку:

    $ mkdir -p /var/opt/xen/ISO_Store

  2. Создаем сам репозиторий, через Storage Manager(SR):

    $ xe sr-create name-label=LocalISO type=iso device-config:location=/var/opt/xen/ISO_Store device-config:legacy_mode=true content-type=iso

    name-label – в данном случае имя репозитория

Сразу после этого в GUI появится новое хранилище:

Чтобы загрузить туда iso нужно загрузить по sftp iso образ в /var/opt/xen/ISO_Store или зайти по ssh в папку и вытянуть образ через wget.

cd /var/opt/xen/ISO_Store

wget https://*address*/*file*.iso

Для активации образов нужно перейти в LocalIso – Storage и нажать кнопку Rescan:

Образ появится в списке.

Так же в список загрузки виртуальной машины(Console – DVD Drive 1) добавится все что инициализировано в локальном репозитории.

Теперь можно выбрать загруженный образ и установить на новую виртуальную машину.

Далее идет обычный процесс установки и использование виртуальной машины. Обратите внимание на то, что лишние виртуальные сетевые карты лучше сразу удалять, чтобы не болтались в системе. По умолчанию там будут все карты сервера.

Подключение дисков к уже настроенной системе

В какой-то момент после запуска и начала использования системы возникнет необходимость подключить новые диски. Сразу отмечу, что есть нюанс с дисками более 2 ТБ, они подключаются немного иначе, ниже это опишу.

Процесс подключения:

1. Нужно посмотреть список дисков:

fdisk -l

2. Далее нужно проверить, есть ли на диске какие-то разделы:

ls -l /dev/disk/by-id/

Если разделов нет, этот шаг можно пропустить.

Если разделы есть и нужно использовать весь диск под хранилище, все разделы нужно будет удалить. Делается это просто с помощью fdisk:

fdisk /dev/sdb

*sdb* тут идентификатор диска, полученный из fdisk -l

Далее нажимаете d, выбираете раздел, который хотите удалить и жмете w, чтобы сохранить изменения.

Если диск больше 2Tb, то следует воспользоваться программой gdisk. Работает так же, как fdisk (gdisk /dev/sdb).

Так как хранилище XenServer использует LVM для разделов, выполним инициализацию диска для работы с LVM:

pvcreate /dev/sdb

Если получаем ошибку

Command not permitted while global/metadata_read_only is set,

нужно выполнить ту же команду, но с дополнительным параметром:

pvcreate /dev/sdb -ff --config global{metadata_read_only=0}

Далее нам нужно получить UUID текущего хоста гипервизора:

xe host-list

Копируем полученный uuid и используем его в непосредственно команде по созданию локального хранилища XenServer:

xe sr-create content-type=user host-uuid=27168638-2022-4dcb-aa1c-56de7d59f989 type=lvm device-config-device=/dev/sdb name-label="Local storage 1.5TB"

Здесь:

  • host-uuid – uuid гипервизора, полученный из xe host-list

  • type – тип файловой системы

  • device-config-device – подключаемый диск

  • name-label – название диска после подключения (так он будет называться в визоре).

После выполненных манипуляций диск сразу станет виден в XenCenter, его можно использовать для создания виртуальных машин.

После подключения новое хранилище можно выставить как хранилище, используемое по умолчанию.

Небольшое отступление на тему lvm:

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

Процесс:

1. Смотрим список томов:

fdisk -l

2. Создаем раздел на указанном диске:

fdisk /dev/xvdb

В примере *xvdb* – выбранный диск

3. Инициализируем lvm:

pvcreate /dev/xvdb1

В примере *xvdb1* – созданный на предыдущем этапе раздел

4. Отображаем список групп LVM:

vgdisplay

5. Включаем новый диск в нужную группу LVM :

vgextend ubuntu-vg /dev/xvdb1 - включаем новый диск в группу LVM

В примере *ubuntu-vg* – это выбранная группа LVM.

6. Расширяем выбранную группу на указанный объем:

В данном примере мы увеличиваем объем на 10 ГБ:

lvextend -L +10G /dev/mapper/ubuntu--vg-root

В данном примере мы берем весь объем, который доступен, расширяем на максимум доступного пространства:

lvextend -l +100%FREE /dev/mapper/ubuntu--vg-root

7. Запускаем сам ресайз в реальном времени, группу нужно посмотреть в /dev/mapper/

Cd /dev/mapper/; ls

resize2fs /dev/mapper/ubuntu--vg-root

В примере */dev/mapper/ubuntu--vg-root * выбранная группа

После выполнения команды resize2fs можете проверить доступное место, оно увеличится (df -h).

Нюансы работы со снепшотами

Для создания и администрирования снепшотов требуется довольно много свободного места (больше чем в два раза от размера виртуальной машины).

Если получилось так, что мы создали машину на хранилище, у которого нет достаточного запаса свободного места и создали снепшот, он займет все место.

При попытке его удалить место не вернется назад, но снепшот пропадет (удалится).

Как выйти из этой ситуации?

Есть встроенный механизм для очистки места после удаления снепшотов. Во вкладке Storage есть кнопка «Reclaim free space», но он может не дать желаемого эффекта. Так же стоит учесть, что данная функция создает нагрузку на контроллер и во время выполнения это операции его производительность может сильно упасть.

В этом случае нужно подключить второй диск большего размера, скопировать текущую машину на второй диск, затем удалить ее на первом диске. Virtual Allocated в этом случае исправится сразу, но занятое место не сразу, через некоторое время. На всякий случай можно выполнить команду xe sr-scan uuid

Далее мы копируем машину со второго диска на первый и стартуем ее.

Импорт и экспорт бекапов

При сборке нового сервера стоит учитывать тот факт, что снепшоты снятые с более поздней версии Xen Server. Невозможно импортировать на сервер с более ранней версией Xen Server.

В обратном режиме все работает без проблем, т.е. снепшот, снятый с ранней версии Xen Server корректно импортируется в новую версию.

Также не рекомендуется большие бекапы снепшотов импортировать по сети через визор, надежнее загружать по sftp снепшот и выполнять команду:

xe vm-import filename=/mnt/nfs/TestVM1-compress.xva

filename – адрес расположения бекапа (снепшота)

3. Возможности Xen Server и работа с консолью

Сам по себе Xen Server имеет довольно большое количество функционала, почитать про которые можно тут. Разумеется, полные возможности доступны только из консоли.

Здесь мы разберем буквально пару полезных примеров работы с функционалом Xen Server из консоли.

Пример работы с консолью:

1. Включить автозапуск виртуальной машины после запуска гипервизора:

Получаем uuid нужной виртуальной машины:

xe vm-list

Находим виртуальную машину и копируем uuid, далее включаем автозагрузку, подставляя в команду подходящий uuid:

xe vm-param-set uuid=b23sfeefd-aee0-2def-8f15-55b3ef15ea77 other-config:auto_poweron=true

После выполнения команды виртуальная машина будет запускаться вместе с запуском гипервизора.

2. Активировать все доступные ядра для виртуальной машины.

В Citrix XenCenter могут присутствовать некоторые ограничения на выделение количества процессорных ядер. Например, вы можете столкнуться с ограничением в 32 ядра на одну виртуальную машину.

Для того чтобы использовать все доступные ядра, мы так же прибегаем к помощи консоли:

Получаем uuid нужной виртуальной машины:

xe vm-list

Выполняем обе команды с указанием количества ядер:

xe vm-param-set VCPUs-max=56 uuid=659795da-49cf-5071-27bd-6eab7b0f5951

xe vm-param-set VCPUs-at-startup=56 uuid=659795da-49cf-5071-27bd-6eab7b0f5951

В итоге получаем виртуальную машину с указанным количеством ядер, точнее, потоков.

4. Удивительные, возможно полезные истории

Здесь я хочу рассказать несколько удивительных историй так или иначе связанных с виртуализацией.

1. История с нерабочим экраном консоли

Как-то раз при сборке и настройке нового сервера произошло следующее: Xen Server успешно установлен, успешно подключается от Xen Center, создает/редактирует виртуальные машины, все, казалось бы, отлично! Но при попытке запустить какую-либо из машин на вкладке консоли черный экран и потом ошибка, что-то вроде: «Невозможно создать изображение» (точную формулировку не помню).

Множество часов было потрачен на попытку решить эту проблему, подкидывались разные видео карты, отгуглен весь интернет. В процессе разбора было принято решение залезть в конфиги Xen, в которые залезать нельзя и ковыряться именно с настройками адаптера, т.к. все хоть как-то близкие темы вели именно туда.

После редактирования конфигов все закончилось плохо, и в итоге все пришлось устанавливать заново.

Проблема заключалась в закрытом порте у провайдера. Как только переключились на локальную сеть, все заработало. Если столкнетесь с похожей проблемой в первую очередь переключитесь на локальную сеть для проверки!

2. История с рейд массивами, которые спонтанно разлетались

На протяжении долгого времени на одной из машин мы страдали с непонятной проблемой: рейд разных типов периодически рассыпался. Мог отработать 3 месяца корректно и разбиться, мог отработать неделю корректно и рассыпаться.

Меняли:

  • Материнскую плату (контроллер MegaRaid)

  • Память

  • SSD-диски

Создавалось впечатление, что это помогало, но потом все снова ломалось. В итоге проблема оказалась с корзиной, а, точнее, с бекплейтом. После ее замены проблема ушла.

3. Подключение удаленных hasp-ключей и других удаленных usb устройств:

При организации виртуальной инфраструктуры может возникнуть потребность в подключении hasp ключей или других устройств, которые проблематично вставлять в сервер в дата центре.

Для решения таких задач есть специальные решения. Например, ПО USB Redirector (бесплатно для Linux).

Эта схема позволяет развернуть сервер на физической машине в офисе и прокинуть на клиент в виртуальную машину любые usb устройства и настроить автоподключение.

Так мы легко прокидывали для решения задач клиентов всякого рода usb на виртуальные машины, хотя когда первый раз услышали про такую задачу в голову приходили дурацкие решения, вроде того, чтобы поехать в ДЦ и вставить usb ключ в сервер.

Тема не новая, но возможно кому то эта информация будет полезна. Очень удобная схема для установки программного обеспечения на виртуальные машины, требующего hasp ключи для работы.

5. Выводы

По моему скромному опыту, для организации полноценной работы с точки зрения обеспечения серверной инфраструктуры для мелко-средней веб-студии бесплатные решения на баз Xen Server отлично подходят.

Они позволяют сэкономить на стоимости Enterprise решений и решить большинство задачи, стоящих перед бизнесом.

Если есть в душе какой то интерес к devOps и организации собственной ИТ инфраструктуры, но нет опыта в этой области и хотелось бы войти в царство виртуализации без затрат, XenServer - отличный старт!

Теги:
Хабы:
Всего голосов 13: ↑12 и ↓1+16
Комментарии45

Публикации

Истории

Работа

DevOps инженер
44 вакансии

Ближайшие события

15 – 16 ноября
IT-конференция Merge Skolkovo
Москва
22 – 24 ноября
Хакатон «AgroCode Hack Genetics'24»
Онлайн
28 ноября
Конференция «TechRec: ITHR CAMPUS»
МоскваОнлайн
25 – 26 апреля
IT-конференция Merge Tatarstan 2025
Казань