В четвертой статье этого XenServer серии, решения для хранения данных будут обсуждаться. Как и в случае с сетью, решения для хранения данных в XenServer поначалу зачастую трудно понять. Перед началом любой настройки следует обсудить новую терминологию и концепции, связанные с хранилищем XenServer.
Обновлять:В мае 2016 года Citrix выпустила новую версию платформы XenServer 7. Для установки следуйте:Свежая установка XenServer 7.
XenServer вводит несколько новых терминов в список традиционной терминологии хранения. Хотя понимание концепций всегда важно при работе с любой ИТ-системой, хранилище не так важно, как предыдущая статья, посвященная сетевым концепциям. Однако в этой статье все же потребуется время, чтобы объяснить и попытаться прояснить эти концепции хранения.
Первое, что нужно помнить о хранилище XenServer, - это то, что у нас есть хранилище для самого XenServer. host, а затем у нас также есть хранилище для гостевых или виртуальных машин, которые будут работать на XenServer хозяин. Концептуально это легко понять, но управление им может быть сложной задачей, если администратор не знаком с целями каждого из аспектов хранения.
Первый термин известен как ‘SR’ или Хранилище хранилища. Это, возможно, самый важный термин в системе хранения XenServer, поскольку он представляет собой физический носитель, на котором будут храниться и извлекаться диски виртуальных машин. Репозитории хранилища могут быть любого из нескольких различных типов систем хранения, включая локальное хранилище, физически подключенное к хосту XenServer, iSCSI / Fibre Channel LUN, Общие сетевые файлы NFSили хранилище на устройстве хранения данных Dell / NetApp.
Репозитории хранилища могут быть общими или выделенными и могут поддерживать множество полезных функций, таких как быстрое клонирование, разреженное выделение (хранилище предоставляется по мере необходимости виртуальной машине) и изменяемые размеры образов виртуальных дисков (подробнее об этом потом).
Репозитории хранилища, SR, логически связаны с хостом XenServer с помощью так называемого Физическое блочное устройство, чаще называемый «PBD». В PBD просто ссылка на место хранения. Эти объекты PBD могут быть «подключены» к хосту XenServer, чтобы позволить этому хосту читать / записывать информацию в этот репозиторий хранилища.
Назначение репозиториев хранилища - в первую очередь хранить виртуальную машину. Образ виртуального диска (VDI) файлы. Файлы VDI - это места на SR, которые были выделены для хранения операционной системы и других файлов для виртуальной машины, работающей на хосте XenServer. Файлы VDI могут быть любого из нескольких типов. Тип определяется типом хранилища репозитория.
Распространенными типами VDI в XenServer являются логические тома (LV), управляемые диспетчером логических томов, виртуальным жестким диском (VHD), или они могут быть номерами логических устройств (LUN) на устройстве хранения Dell или NetApp. Примечание: В этой статье будут использоваться LUN на устройстве хранения Dell.
Эти файлы VDI логически связаны с виртуальными машинами через объект, известный как Виртуальное блочное устройство, обычно обозначаемый как «VBD». Эти объекты VBD могут быть прикреплены к виртуальным гостям, что затем позволяет гостевой машине получать доступ к данным, хранящимся в этом конкретном VDI на соответствующем SR.
Как и в случае с сетью в XenServer, чтение о хранилище - это одно, но возможность увидеть взаимосвязь между каждым из этих элементов часто укрепляет концепции. Общие диаграммы, используемые для представления концепций хранилища XenServer, часто сбивают с толку новичков, поскольку диаграммы часто читаются линейно. Ниже приведено одно такое изображение, позаимствованное у Citrix.
Многие люди читают это линейно слева направо, думая, что каждая часть - это отдельное физическое устройство. Это не так и часто приводит к путанице в том, как работает хранилище XenServer. Рисунок ниже пытается объяснить концепции менее линейным, но более прагматичным образом.
Надеюсь, что приведенный выше рисунок не запутает людей в отношении хранилища XenServer. Второе изображение - это попытка показать логические связи (PBD и VBD), которые используются для подключения XenServers и гостей к удаленному хранилищу через одно фактическое сетевое соединение.
С концептуализацией в сторону; можно начинать настройку. Вспоминая первую статью этой серии, в этом руководстве используется устройство хранения Dell PS5500E iSCSI для хранения дисков виртуальных машин (гостевых). В этом руководстве не рассматривается настройка устройства Dell iSCSI.
Этот первый процесс будет включать шаги по созданию программный инициатор iSCSI с хоста XenServer на Dell PS5500E.
Этот конкретный LUN использует Протокол аутентификации вызов-рукопожатие (ГЛАВА), чтобы ограничить доступ к тому iSCSI определенным авторизованным сторонам.
Для создания репозитория хранилища традиционным ‘Xe’ команда будет происходить. Перед созданием репозитория хранилища необходимо получить правильную информацию iSCSI.
Прохождение ‘Sr-probe’ параметр к ‘Xe’ Утилита проинструктирует XenServer запросить у запоминающего устройства iSCSI IQN (полное имя iSCSI).
Первая команда сначала будет выглядеть напряженно, но не так уж плохо, как кажется.
# xe sr-probe type = lvmoiscsi device-config: target = X.X.X.X device-config: chapuser = "tecmint" device-config: chappassword = "tecmint_chap"
Эта первая команда нужна для сбора SCSI IQN для конфигурации хранилища хранилища. Прежде чем двигаться дальше, давайте рассмотрим все части этой команды.
После ввода и отправки команды XenServer попытается войти в устройство iSCSI и вернет некоторую информацию, необходимую для фактического добавления этого устройства iSCSI в качестве хранилища.
Ниже показано, что тестовая система вернула этой командой.
Код ошибки: SR_BACKEND_FAILURE_96. Параметры ошибки:, Параметр SCSIid отсутствует или неверен,версия "1.0" 0 iqn.2001-05.com.equallogic: 0-8a096-0d9a4ab02-46600020343560ef-xenct-xen2
Выделенный здесь фрагмент известен как iSCSI IQN. Это очень важно и необходимо для определения SCSIid для хранилища репозитория. С помощью этой новой информации предыдущая команда может быть изменена для получения SCSIid.
# xe sr-probe type = lvmoiscsi device-config: target = X.X.X.X device-config: targetIQN = iqn.2001-05.com.equallogic: 0-8a0906-0d9a4ab02-46600020343560ef-xenct-xen2 device-config: chapuser = "tecmint" device-config: chappassword = "tecmint_chap"
Единственное, что добавлено к команде, - это targetIQN строфа. Выпуская эту новую команду, система ответит последней частью информации, необходимой для создания репозитория хранилища iSCSI. Последняя часть информации - это идентификатор SCSI.
Код ошибки: SR_BACKEND_FAILURE_107. Параметры ошибки:, Параметр SCSIid отсутствует или неверен,версия "1.0" EQLOGIC 0 107379425280 36090a028b04a9a0def60353420006046
С этого момента доступны все необходимые компоненты для создания репозитория хранилища iSCSI, и пора выполнить команду для добавления этого SR к этому конкретному XenServer. Создание репозитория хранилища из объединенной информации выполняется следующим образом:
# xe sr-create name-label = "Tecmint iSCSI Storage" type = lvmoiscsi content-type = user device-config: target = X.X.X.X device-config: port = 3260 device-config: targetIQN = iqn.2001-05.com.equallogic: 0-8a0906-0d9a4ab02-46600020343560ef-xenct-xen2 device-config: chapuser = "tecmint" device-config: chappassword = "tecmint_chap" конфигурация устройства: SCSIid = 36090a028b04a9a0def60353420006046
Если все пойдет хорошо, система подключится к устройству iSCSI, а затем вернет UUID недавно добавленного репозитория хранилища.
bea6caa4-ecab-8509-33a4-2cda2599fb75.
В UUID выход отличный знак! Как и в случае со всеми задачами системного администрирования, всегда полезно подтвердить, что команда была выполнена успешно. Это можно сделать с помощью другого ‘Xe’ команда.
# xe sr-list name-label = "Хранилище Tecmint iSCSI"
uuid (RO): bea6caa4-ecab-8509-33a4-2cda2599fb75 name-label (RW): Tecmint iSCSI Storage name-description (RW): host (RO): xenct-xen2 type (RO): lvmoiscsi content-type (RO) ): Пользователь.
Из CLI вывод, что XenServer успешно подключился к устройству Dell iSCSI и готов хранить гостевые файлы VDI.
Следующая серия шагов посвящена процессу создания библиотеки ISO. Файлы ISO обычно представляют собой образы установочного компакт-диска (CD).
Создав специальный репозиторий для этих файлов ISO, установку новых гостей можно выполнить очень быстро. Когда администратор хочет создать нового гостя, он может просто выбрать один из файлов ISO, которые существуют в этой библиотеке ISO, вместо того, чтобы физически помещать компакт-диск в XenServer в пуле.
В этой части руководства предполагается, что у пользователя есть рабочий САМБА сервер. Если сервер SAMBA не настроен, прочтите эту статью о том, как выполнить эту задачу в Red Hat / Fedora (в будущем у меня будет руководство по серверу SAMBA Debian):
Первый шаг - собрать необходимые учетные данные и информацию о конфигурации для САМБА ИСО библиотека. Как только имя пользователя, пароль и информация о подключении станут доступны, простой ‘Xe’ вариант команды может использоваться для подключения библиотеки SAMBA к XenServer.
# xe-mount-iso-sr /// ISO -o имя пользователя = , пароль =
Эта команда ничего не выведет на экран, если не завершится ошибкой. Чтобы подтвердить, что он действительно смонтировал общий ресурс SAMBA ISO, выполните еще один ‘Xe’ команда:
# xe sr-list.
uuid (RO): 1fd75a51-10ee-41b9-9614-263edb3f40d6 name-label (RW): Удаленная библиотека ISO на: // / ISO имя-описание (RW): host (RO): xenct-xen2 type (RO): iso тип содержимого (RO): iso.
Этот хост XenServer теперь настроен как с Репозиторий хранилища iSCSI также как и Библиотека CIFS ISO для хранения установочного носителя для виртуальных машин (гостей).
Следующими шагами будут создание виртуальных машин и подключение этих систем к нужным сетям из предыдущей статьи о сети.
