Что такое xen сервер
Облако с нуля с использованием XenServer
Недавно мы создали небольшое облако для решения наших внутренних задач и хотим поделиться этим опытом с читателями Хабра. Здесь мы подробно опишем, какое оборудование было выбрано для развёртывания облака и как создать инфраструктуру облачной системы, опираясь на XenServer от компании Citrix. В этом продукте Citrix решила отказаться от стандартного подхода, когда у облака есть некоторый центральный управляющий узел, они разбили его на несколько составляющих и предложили их тоже поместить в облако. Кому интересно, как это всё работает — добро пожаловать под кат!
В нашей статье мы остановимся на таких моментах, как: подготовка аппаратной части, установка XenServer, установка лицензии, создание виртуальной сетевой инфраструктуры, опишем проблемы, возникшие с виртуальными машинами на ОС Ubuntu, расскажем про динамическую балансировку нагрузки, про настройки и разграничение доступа к облаку, и, разумеется, покажем, что у нас получилось.
Подготовка аппаратной части
Первой задачей становится выбор основы для любого облака, а именно — выбор серверов, на которых будет производиться виртуализация. Мы остановили свой выбор на серверах от компании IBM и выбрали IBMx3850 X5.
Каждый IBM основан на IBM X-Architecture и имеет:
• 4 процессора Intel® Xeon® CPUE7- 8860 с тактовой частотой 2.27GHz, что в итоге даёт 40 ядер на сервер (80 потоков);
• 150Гб RAM;
• 2 независимых блока питания;
• карту расширения fibre channel;
• сетевую карту для 10-гигабитного соединения;
• 2 жестких диска по 500Гб, объединённых в RAID1.
Дальше возникает вопрос: где хранить виртуальные машины? Если их хранить на самих серверах, то это уменьшает надёжность системы, т.к. при выходе из строя сервера мы потеряем все виртуальные машины, которые были на нём. Также такой подход сильно усложняет задачу балансировки нагрузки, потому что миграция виртуальной машины потребует перемещения её диска на другой сервер, а это — достаточно долгий процесс. Поэтому в нашем стенде используется внешнее хранилище DELL md3620f, оснащённое 4 выходами fibre channel. Это хранилище поддерживает до 24 жестких дисков, которые могут быть объединены во все популярные типы рейдов(RAID0, RAID1, RAID5, RAID6, RAID01). Мы в нашем случае используем 10 жестких дисков по 1ТБ, объединённых в RAID5.
Что требуется для быстрой миграции? Для обеспечения быстрой миграции между IBMами в состав стенда был добавлен 10гигабитный коммутатор summit x670, это теоретически должно было ускорить миграцию (самый долгий процесс в миграции – передача данных по сети от одного сервера к другому) в 10 раз, но на практике это дало выигрыш только в 5-6 раз. Чтобы у серверов и виртуальных машин был доступ в локальную сеть и Интернет, в состав стенда был добавлен коммутатор HP ProCurve.Также через него идёт трафик к внешним клиентам.
Подводя итог по аппаратной части, мы имеем стенд, включающий в себя:
• 4 сервера IBMx3850 X5
• коммутатор HP ProCurve для соединения до 1000 Мб/сек
• коммутатор Summit x670 для поддержки соединения 10Гбит/сек
• внешнее хранилище DELL md3620f с 10Тб дисковым массивом
• и прочее (источник бесперебойного питания APC Smart-UPS 3000VA, трансиверы для оптоволокна, восемь десятиметровых оптоволоконных кабелей, 50 метров витой пары )
Всё это выглядит так, как представлено на картинке, внизу пять источников бесперебойного питания, которые в случае выхода из строя центрального энергоснабжения, позволят корректно остановить всё запущенное на сервере и отключить сами сервера.
Логическая схема соединения выглядит следующем образом:
Если суммировать, то мы имеем:
• 160 вычислительных ядер (320 потоков);
• 600Гб RAM;
• 14ТБ дискового пространства;
• Высокоскоростную сетевую инфраструктуру.
Установка XenServer
Для запуска виртуальных машин на выбранном нами железе, было решено развернуть облачную платформу XenServer Platinum.
Краткая общая информация о XenServer, если кто не сталкивался: XenServer — это самостоятельная операционная система, основанная на ядре Linux. В основе всего лежит гипервизор XEN, последняя на данный момент версия — используемая версия XenServer 6.1 — основана на гипервизоре XEN 4.1. Для нормальной работы системы необходим процессор с поддержкой виртуализации и 1Гб RAM. Ребята из Citrix не любят писать свои минимальные требования, предпочитая писать максимальные системные требования, с ними можно ознакомиться тут. В семейство XenServer входит несколько версий продукта, отличающиеся ценой и дополнительными функциями.
На все сервера IBM необходимо установить XenServer. Сама установка XenServer является совершенно несложным процессом и не очень отличается от установки Ubuntu. Куда больший интерес представляет настройка системы для последующей удобной работы, что и будет рассмотрено дальше, основное внимание будет уделено компонентам расширения для XenServer, которые предоставляет Citrix. После установки XenServer на все хосты необходимо зайти в XenCenter (его можно скачать, зайдя на web-интерфейс установленного XenServer или с сайта Citrix). В XenCentеr необходимо создать пул и добавить к нему сервера.
Установка лицензии
После установки XenServer первым делом нужно установить лицензии на сервера. Это делается не с помощью ввода лицензионных ключей, а с помощью установки сертификата, полученного в личном кабинете на сайте Citrix. Сертификат представляет собой текстовый файл с лицензионными ключами, записанными в специальном формате. Его можно получить сразу на несколько серверов. Сертификат необходимо установить в специальный центр лицензирования. Тут стоит отметить, что если хотя бы один из сертификатов является не валидным, то все сертификаты не будут действовать.
Citrix предлагает установить центр лицензирования либо на отдельном хосте, либо на виртуальной машине в вашем облаке (она почти не потребляет ресурсов процессора и требует всего 256 Мб оперативной памяти). Но если вы установите его как виртуальную машину, вас могут ожидать неприятности. Однажды вы можете столкнуться с проблемой, с которой столкнулись мы, когда отключили сервера нашего стенда для их апгрейда, а вместе с ними выключилась, соответственно, и виртуалка с центром лицензирования. После включения XenServer выдал ошибку «Кончился срок пробной лицензии» (центр лицензирования ведь был не запущен). Вроде проблем быть не должно: просто включить виртуальную машину центра лицензирования с нормальной лицензией и принять её. Но не тут-то было: с истёкшей лицензией нельзя включить НИКАКУЮ виртуальную машину. Правда, после первоначальной паники в меню принятия лицензии была найдена кнопка «активировать бесплатную версию», после нажатия которой мы увидели фразу «у вас осталось 30 дней пробной лицензии». И уже потом можно запустить виртуальную машину с лицензией.
Создание виртуальной сетевой инфраструктуры
Чтобы гибко управлять сетевыми настройками виртуальных машин и чтобы они не были в одной подсети с серверами XenServer, необходимо наладить виртуальную сетевую инфраструктуру. Для этих целей у Citrix предусмотрен компонент Distributed Virtual Switch Controller (DVSC). Он также предоставляется в виде виртуальной машины, но она потребляет уже больше ресурсов: 2 VCPU и 2Гб оперативной памяти. Настройки DVSC не представляют собой ничего сложного: необходимо указать свободный IP-адрес для виртуальной машины, после чего добавить пул к DVSC.Всё это делается через web-интерфейс. После этих действий появляется возможность создавать виртуальные сети между виртуальными машинами, находящимися на разных серверах (Cross-ServerPrivateNetwork), тогда как до этого было возможно создавать виртуальные сети только в рамках одного сервера (Single-ServerPrivateNetwork).
Если зайти на web-интерфейс DVSС, то там можно увидеть много полезной информации о сетевой инфраструктуре: список созданных сетей, список виртуальных машин, подключенных к конкретной сети, сообщения об ошибках в сети, графики сетевой активности (как для конкретной виртуальной машины, так и для всей сети в целом).
Также DVSC может выступать в роли простого межсетевого экрана, правила которого можно создавать во вкладке AccessControl. Все политики сетевой безопасности делятся на 4 уровня: глобальные политики (т.к. к одному DVSC могут быть подключены несколько пулов), политики пула, политики конкретной сети, политики конкретной виртуальной машины. Правила описывают тип действия (разрешить или запретить), протокол (можно задать порты получатели и отправителя или указать известный протокол) и для кого это правило применять.
В работу межсетевой экран вступает сразу после установки, и в нём сразу записаны 4 базовых глобальных правила:
• разрешать все ARP-сообщения в сети
• разрешать виртуальным машинам получать IP-адрес по dhсp
• разрешать виртуальным машинам обращаться к DNS-серверам
• разрешать весь сетевой трафик (это правило применяется после проверки всех правил других уровней)
Вообще DVSC всем хорош, и по функционалу чем-то напоминает vShield Edge от VmWare, но Edge кажется удобнее за счёт разных мелочей: возможности создания DHCP-сервера, удобной организации Nat для виртуальных машин и т.д. Всё это (отсутствие DHCP-сервера и Nat), конечно, решается с помощью создания отдельной виртуальной машины на базе Ubuntu, но удобно, когда всё уже решено заранее.
Проблема с созданием виртуальной машины с Ubuntu
Вообще создание виртуальных машин с Ubuntu в первый раз вызывает шок и непонимание — как такое попало в релизную версию продукта? Дело вот в чём:
После создания виртуальной машины из стандартного шаблона она не может запуститься и пишет указанную выше ошибку (Error code: INVALID_SOURCE). Ошибка связана с параметрами загрузки виртуальной машины. Бороться с ней можно следующим образом(описание взято тут и чуть-чуть модифицировано для работы с большим числом виртуальных машин):
1. Зайти в консоль XenServer, что можно сделать через XenCenter (вкладка Console у сервера) или по ssh.
2. Узнать uuid виртуальной машины командой xe vm-listname-label=[НАЗВАНИЕ_ВМ]. В нашем примере это выглядит так:
3. Дальше необходимо установить параметры загрузки следующей командой: xe vm-param-setuuid=[UUID_ВМ] HVM-boot-policy=BIOS\ orderHVM-boot-params:order=dc.
4. После этих несложных манипуляций виртуальная машина успешно запустится.
Но на этом ошибки, связанные с работой Ubuntu, не заканчиваются. При создании нашего стенда было принято решение создать шаблоны виртуальных машин с разными ОС, чтобы не тратить время на установку нужной, а сразу брать готовую и туда ставить уже необходимое ПО. С машинами на базе Windows нет никаких проблем, тогда как с Ubuntu возникает проблема чёрного экрана при создании виртуальной машины из образа. Решение этой проблемы оказалось довольно простым, с одной стороны, и немного неправильным, с другой. Проблема решается простой установкой xen-tools на виртуальную машину. Минус такого решения в том, что невозможно предоставить чистую операционную систему, что иногда требуется в рамках решаемых задач.
Динамическая балансировка нагрузки
В рамках решаемых задач часто нужна динамическая балансировка нагрузки между серверами с XenServer. Для этих целей компания Citrix предоставляет виртуальную машину Citrix WLB Virtual Appliance, которую также необходимо добавить в облако, после чего произвести простую настройку через её консоль (при заходе в консоль все необходимые действия машина подскажет сама). После этого нужно зайти в XenCenter и указать пулу, что именно эта виртуальная машина будет отвечать за балансировку нагрузки между серверами (это действие производится во вкладке WLB).
Эта виртуальная машина отслеживает нагрузку на сервера (количество используемых ядер, количество используемой оперативной памяти, сетевая активность) и распределяет её между серверами. Это происходит как при включении виртуальной машины (она запускается на самом незагруженном сервере), так и во время её работы (за счёт миграции).
Настройка и разграничения доступа к облаку
Последней задачей, которую необходимо решить для нормальной работы, является предоставление доступа к облаку. И тут у Citrix, на наш взгляд, самые большие проблемы. Citrix предлагает два варианта получения доступа к облаку: через XenCenter и через web-интерфейс.
Доступ через XenCenter
Если к пулу подключить Active Directory (AD), то появляется возможность создавать пользователей в XenCenter. Компания Citrix решила отказаться от дискреционной модели доступа в XenCenter и реализовала ролевую. Отсюда основная проблема: ВСЕ пользователи видят и имеют доступ ко ВСЕМ виртуальным машинам, регулируется только тип доступа, но он применяется ко ВСЕМ виртуальным машинам сразу (т.е. если даётся роль на запуск виртуальных машин, то сразу всех). Также стоит отметить, что AD должен постоянно быть доступен, т.к. при перезагрузке AD автоматически не добавляется к пулу, и его необходимо каждый раз добавлять вручную.
Доступ через web-интерфейс
Для дискреционного доступа компания Citrix предлагает использовать доступ через web-интерфейс. Для настройки доступа через web-интерфейс необходимо установить виртуальную машину Citrix XenServer Web Self Service. После простой настройки виртуальной машины через её консоль (необходимо задать ip-адрес или указать, чтобы он получался по DHCP) необходимо выполнить ряд настроек через web-интерфейс. Тут Citrix выше всяких похвал за доступное и понятное описание: если вы вошли в качестве администратора, вам сразу будет показан список шагов, которые необходимо выполнить, а также подробно описано, как это делать.
В Citrix XenServer Web Self Service могут использоваться те же пользователи, что есть в AD, или создаваться новые. При первой загрузке XenServer Web Self Service администратору необходимо указать, как он хочет действовать, и это решение уже потом никак нельзя изменить (конечно, всегда можно переставить виртуальную машину, но это повлечёт за собой новую настройку прав доступа к виртуальным машинам). После настройки любой пользователь может получить доступ к конкретной виртуальной машине через браузер. И тут Citrix тоже очень радует: для работы может быть использован любой браузер, а не какой-то ограниченный набор, как у облака от Microsoft (только InternetExplorer) или VmWare (не поддерживается Opera). Для того чтобы пользователь получил доступ к виртуальной машине, администратор должен разрешить доступ к этой виртуальной машине для данного пользователя, что легко делается через web-интерфейс.
К большим недостаткам работы через web-интерфейс можно отнести невозможность настройки физических параметров виртуальной машины (количество процессоров, количество RAM, настройка подключённых сетей и жестких дисков). Так что web-интерфейс – это доступ к графическому интерфейсу виртуальной машины, а не к управлению её физическими параметрами. Мы выполнили все необходимые действия: подготовили аппаратуру, настроили лицензии, развернули… И теперь облако готово к работе!
Наш эксперимент
Для оценки реальной вычислительной мощности серверов мы провели эксперимент, целью которого было максимально загрузить все 80 логических ядер на системе. В качестве основы для проведения эксперимента была взята программа, выполняющая Ray-Tracing простой сцены, без операционной системы и использующая все ядра на всех процессорах в компьютере. О том, как работает эта программа и как получить исходные коды этой программы, можно прочитать тут.
Для эксперимента программа была немного доработана: добавили анимацию движения для одной из сфер на рисунке, добавлен подсчет скорости работы, и добавлена буферизация при рисовании каждого кадра. Для сравнения мощности работы полученной программы мы запускали ее на нескольких компьютерах разной конфигурации, в том числе, и на наших IBM серверах. В эксперименте выполнялся рендеринг сцены из 5-ти сфер в разрешении 800×600. Эксперимент увенчался успехом и IBM сервера показали внушительные показатели производительности. Для всех экспериментов мы записали видео, где цифры зеленого цвета в левом верхнем углу экрана означают количество кадров в секунду (FPS), цифры красного цвета — количество секунд на кадр. Вот такие результаты мы получили:
1. Обычный компьютер: Intel i3-2100, 3.1 GHz, всего 2 ядра. Для каждого ядра 800×600/2=240000 точек на кадр. Как видно из видео, скорость составила примерно 0.5 FPS (на один кадр тратилось более 2-х секунд).
2. Компьютер на современном мощном процессоре: Intel i7-4770, 3.4 GHz, всего 8 ядер. Для каждого ядра 800×600/8=60000 точек на кадр. Результат — примерно 2 кадра в секунду, как можно видеть на видео.
3. IBM сервер из стойки: Intel Xeon E7-8860 2.3 GHz, на каждом компьютере по 4 процессора по 10 физических ядер (на каждом ядре 2 логических) — итого 80 ядер. Для каждого ядра 800×600/80=6000 точек на кадр. Результат — 12-14 FPS — что значительно больше, чем у других систем.
Интересно, что если запустить на IBM сервере рендеринг в разрешении 1280×1024, и позволить ядрам процессора работать без буферизации, то можно заметить, как кадр рисуется из 80-ти полосок!
Вот что у нас получилось. Надеемся, что, прочитав нашу статью, вы сможете легко сделать облако сами, избежав тех проблем, которые мы здесь описали, или успешно справившись с ними!
Citrix Xen Center – Опыт работы с полностью бесплатной виртуализацией
Сразу опишу главный плюс такого решения – Это бесплатно! Любой может более менее полноценно администрировать рабочие места(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.
Создаем сам репозиторий, через 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.
Для активации образов нужно перейти в LocalIso – Storage и нажать кнопку Rescan:
Образ появится в списке.
Так же в список загрузки виртуальной машины(Console – DVD Drive 1) добавится все что инициализировано в локальном репозитории.
Теперь можно выбрать загруженный образ и установить на новую виртуальную машину.
Далее идет обычный процесс установки и использование виртуальной машины. Обратите внимание на то, что лишние виртуальные сетевые карты лучше сразу удалять, чтобы не болтались в системе. По умолчанию там будут все карты сервера.
Подключение дисков к уже настроенной системе
В какой-то момент после запуска и начала использования системы возникнет необходимость подключить новые диски. Сразу отмечу, что есть нюанс с дисками более 2 ТБ, они подключаются немного иначе, ниже это опишу.
Процесс подключения:
Нужно посмотреть список дисков:
2. Далее нужно проверить, есть ли на диске какие-то разделы:
Если разделов нет, этот шаг можно пропустить.
Если разделы есть и нужно использовать весь диск под хранилище, все разделы нужно будет удалить. Делается это просто с помощью fdisk:
Далее нажимаете d, выбираете раздел, который хотите удалить и жмете w, чтобы сохранить изменения.
Если диск больше 2Tb, то следует воспользоваться программой gdisk. Работает так же, как fdisk (gdisk /dev/sdb).
Так как хранилище XenServer использует LVM для разделов, выполним инициализацию диска для работы с LVM:
Если получаем ошибку
Command not permitted while global/metadata_read_only is set,
нужно выполнить ту же команду, но с дополнительным параметром:
Далее нам нужно получить UUID текущего хоста гипервизора:
Копируем полученный 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 позволяет менять размеры диска на лету, даже если с этого диска запущена система. Это крайне полезная возможность.
Процесс:
Смотрим список томов:
2. Создаем раздел на указанном диске:
В примере *xvdb* – выбранный диск
3. Инициализируем lvm:
В примере *xvdb1* – созданный на предыдущем этапе раздел
4. Отображаем список групп LVM:
5. Включаем новый диск в нужную группу LVM :
В примере *ubuntu-vg* – это выбранная группа LVM.
6. Расширяем выбранную группу на указанный объем:
В данном примере мы увеличиваем объем на 10 ГБ:
В данном примере мы берем весь объем, который доступен, расширяем на максимум доступного пространства:
7. Запускаем сам ресайз в реальном времени, группу нужно посмотреть в /dev/mapper/
В примере */dev/mapper/ubuntu—vg-root * выбранная группа
Нюансы работы со снепшотами
Для создания и администрирования снепшотов требуется довольно много свободного места (больше чем в два раза от размера виртуальной машины).
Если получилось так, что мы создали машину на хранилище, у которого нет достаточного запаса свободного места и создали снепшот, он займет все место.
При попытке его удалить место не вернется назад, но снепшот пропадет (удалится).
Как выйти из этой ситуации?
Есть встроенный механизм для очистки места после удаления снепшотов. Во вкладке 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 из консоли.
Пример работы с консолью:
Включить автозапуск виртуальной машины после запуска гипервизора:
Получаем uuid нужной виртуальной машины:
Находим виртуальную машину и копируем uuid, далее включаем автозагрузку, подставляя в команду подходящий uuid:
xe vm-param-set uuid=b23sfeefd-aee0-2def-8f15-55b3ef15ea77 other-config:auto_poweron=true
После выполнения команды виртуальная машина будет запускаться вместе с запуском гипервизора.
2. Активировать все доступные ядра для виртуальной машины.
В Citrix XenCenter могут присутствовать некоторые ограничения на выделение количества процессорных ядер. Например, вы можете столкнуться с ограничением в 32 ядра на одну виртуальную машину.
Для того чтобы использовать все доступные ядра, мы так же прибегаем к помощи консоли:
Получаем uuid нужной виртуальной машины:
Выполняем обе команды с указанием количества ядер:
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. Удивительные, возможно полезные истории
Здесь я хочу рассказать несколько удивительных историй так или иначе связанных с виртуализацией.
История с нерабочим экраном консоли
Как-то раз при сборке и настройке нового сервера произошло следующее: Xen Server успешно установлен, успешно подключается от Xen Center, создает/редактирует виртуальные машины, все, казалось бы, отлично! Но при попытке запустить какую-либо из машин на вкладке консоли черный экран и потом ошибка, что-то вроде: «Невозможно создать изображение» (точную формулировку не помню).
Множество часов было потрачен на попытку решить эту проблему, подкидывались разные видео карты, отгуглен весь интернет. В процессе разбора было принято решение залезть в конфиги Xen, в которые залезать нельзя и ковыряться именно с настройками адаптера, т.к. все хоть как-то близкие темы вели именно туда.
После редактирования конфигов все закончилось плохо, и в итоге все пришлось устанавливать заново.
Проблема заключалась в закрытом порте у провайдера. Как только переключились на локальную сеть, все заработало. Если столкнетесь с похожей проблемой в первую очередь переключитесь на локальную сеть для проверки!
2. История с рейд массивами, которые спонтанно разлетались
На протяжении долгого времени на одной из машин мы страдали с непонятной проблемой: рейд разных типов периодически рассыпался. Мог отработать 3 месяца корректно и разбиться, мог отработать неделю корректно и рассыпаться.
Материнскую плату (контроллер MegaRaid)
Создавалось впечатление, что это помогало, но потом все снова ломалось. В итоге проблема оказалась с корзиной, а, точнее, с бекплейтом. После ее замены проблема ушла.
3. Подключение удаленных hasp-ключей и других удаленных usb устройств:
При организации виртуальной инфраструктуры может возникнуть потребность в подключении hasp ключей или других устройств, которые проблематично вставлять в сервер в дата центре.
Для решения таких задач есть специальные решения. Например, ПО USB Redirector (бесплатно для Linux).
Эта схема позволяет развернуть сервер на физической машине в офисе и прокинуть на клиент в виртуальную машину любые usb устройства и настроить автоподключение.
Так мы легко прокидывали для решения задач клиентов всякого рода usb на виртуальные машины, хотя когда первый раз услышали про такую задачу в голову приходили дурацкие решения, вроде того, чтобы поехать в ДЦ и вставить usb ключ в сервер.
Тема не новая, но возможно кому то эта информация будет полезна. Очень удобная схема для установки программного обеспечения на виртуальные машины, требующего hasp ключи для работы.
5. Выводы
По моему скромному опыту, для организации полноценной работы с точки зрения обеспечения серверной инфраструктуры для мелко-средней веб-студии бесплатные решения на баз Xen Server отлично подходят.
Они позволяют сэкономить на стоимости Enterprise решений и решить большинство задачи, стоящих перед бизнесом.