Cluster Shared Volumes (CSV) — установка, использование, отключение
Многое уже было сказано о виртуализации в Windows Server 2008 R2, о новой технологии Cluster Shared Volumes (CSV), позволяющей всем узлам кластера одновременно работать с общим диском, о Live Migration, отчасти ставшей возможной как раз с появлением CSV.
Технология Cluster Shared Volumes позволяет вам размещать на общем кластерном диске виртуальные машины, запускаемые на разных узлах кластера. Это очень удобно, так как позволяет вам переносить виртуальные машины с узла на узел, не смотря на то, какие еще виртуальные машины на данном диске расположены.
Сегодня я не буду рассказывать теорию работы Cluster Shared Volumes — если интерес будет проявлен, опишу её в отдельной статье. Сейчас же мы рассмотрим практическую сторону — как задействовать функционал Cluster Shared Volumes, как включить его для общих дисков, как отключить данный функционал, если потребуется и такой шаг.
Я исхожу из того, что вы уже установили Windows Server 2008 R2 или Hyper-V Server 2008 R2 на один или несколько серверов и создали кластер. Сразу после создания кластера вы не видите в консоли Failover Cluster Manager раздела Cluster Shared Volumes, так как данных функционал отключен по умолчанию.
Как задействовать Cluster Shared Volumes?
Ответ на вопрос будет таким же простым, как его формулировка, — в консоли Failover Cluster Manager выберите корневой элемент созданного кластера. В списке действий увидите команду Enable Cluster Shared Volumes.
Выбрав эту команду, согласитесь с предупреждением системы о том, что CSV поддерживается лишь для отказоустойчивых виртуальных машин, — и вы заметите, что в консоли Failover Cluster Manager появился новый раздел.
Как задействовать Cluster Shared Volumes из PowerShell?
Вы можете включить поддержку CSV на вашем кластере и из PowerShell. Делается это при помощи следующей команды: Get-Cluster | %{$_.EnableSharedVolumes = "Enabled"}
Обратите внимание на то, что по умолчанию в PowerShell не загружаются все возможные модули — и поэтому при обычном запуске Windows PowerShell коммандлет Get-Cluster недоступен. Чтобы воспользоваться специализированным набором коммандлетов, вам потребуется импортировать модуль поддержки технологий кластеризации. Для этого выполните команду import-module failoverclusters или же запустите «Windows PowerShell Modules» из меню «Administrative Tools», что загрузит разом все модули, входящие в стандартный пакет администрирования.
Как отключить поддержку Cluster Shared Volumes?
Интересный момент — включение поддержки CSV возможно из консоли Failover Cluster Manager, а вот возможность отключения там отсутствует. Единственный способ отключить поддержку CSV в кластере — выполнить команду Get-Cluster | %{$_.EnableSharedVolumes = "Disabled"}
Помните о том, что следует импортировать модуль failoverclusters или запускать «Windows PowerShell Modules» из «Administrative Tools».
Включение Cluster Shared Volumes для общих дисков
Задействовав поддержку CSV на кластере, вы еще не сделали ваши общие диски доступными на всех узлах сразу. Это потребуется выолнить для каждого из дисков отдельно. В консоли Failover Cluster Manager в графе Cluster Shared Volumes вы видите, какие диски в данный момент используют технологию CSV.
Если вы хотите включить Cluster Shared Volumes для нового диска, выполните действие «Add Storage» и выберите этот диск.
Добавленный диск также отобразится в списке дисков, использующих CSV.
Создание виртуальных машин на Cluster Shared Volumes
Каждый диск, для которого вы задействовали CSV, будет доступен на всех узлах в виде каталога «C:\ClusterStorage\VolumeX» , где X — номер диска в очерёдности включения CSV (что вовсе не обязательно может совпадать с нумерацией дисков в представлении оснасток Failover Cluster Manager и/или Disk Management).
Теперь создавая виртуальные машины, размещайте их конфигурацию и диски внутри данных каталогов.
Дополнительные соображения
Помните о том, что диски CSV не поддерживают технологию Pass-Through. То есть у вас не получится подключить общий диск кластера напрямую к виртуальной машине. Вместо этого на общих дисках следует создавать виртуальные диски (VHD) и уже их подключать к виртуальным машинам. Впрочем, любая виртуальная машина может одновременно сочетать в себе виртуальные диски (расположенные на CSV) и диски, подключенные как Pass-Though (не задействованные в кластере каким-либо другим способом).
Если вы копируете файлы (например, виртуальные диски) на диск CSV — запускайте процесс копирования на узле-координаторе. Подробнее об этом я расскажу в следующей заметке.
Comments
Anonymous
January 01, 2003
RuStn - что касается того что лишь координатор имеет доступ к ТАБЛИЦЕ - согласен. Остальные, действительно в режиме DirectIO пишут/читают в файлы (сами, напрямую, не через координатор.) Что тут некрасиво не понимаю. Рожать принципиально новую файловую систему, несовместимую со всеми решениями резервного копирования, репликации, VSS было бы много некрасивее. Отсутствие сторонних решений резервного копирования на пару лет было бы ужасно. Microsoft за требование использовать "родной для виртулизации метод резервного копирования", чтобы потом его результат бэкапить другими решениями - просто бы с землёй сравняли громко-кричащие энтузиасты. При том что известен ряд конкретных вендоров, поступающих именно так на своих файловых системах.. и все молчат при кислой мине )) Остальное в вашем посте - скажем так.. бред, соверщенно не вытекающий из здравого первого рассуждения. Если вы, в нарушение явных требований и явного предупреждения системы при включении CSV пробуете хранить на ней что-то кроме кластеризованных виртуальных машин - сами виноваты, комментировать это бессмысленно. Ни разу не видел CSV сломавшуюся при использовании её лишь для задач виртуализации (и хранении на ней лишь кластеризованных ВМ, ибо только Cluster API, а никак не Hyper-V API отвечает за общение с координатором). Если у вас есть проблемы с библиотекой и размещением ВМ с неё на CSV, и вы готовы работать над этой проблемой, напишите мне, соберём логи, проанализируем. Либо найдём причину сбоя в ваших настройках, либо выпустим хотфикс к VMM (а не к CSV). Михаил - про Passthrough диски.. Passthrough диск, это ВЕСЬ ФИЗИЧЕСКИЙ ДИСК (LUN),отданный ВМ. Весь, а не его часть. Именно поэтому нельзя отдать часть диска CSV (папку) виртуальной машине как Passthrough. Если вы даете виртуальной машине отдельный диск (LUN) как Passthrough, то там нет CSV (у вас же нет кластера Hyper-V внутри ВМ) - и если данный LUN доступен всем узлам кластера, то Live Migration с такими дисками работать будет.Anonymous
January 01, 2003
Михаил — у меня прекрасно работает Live Migration с виртуальными машинами, использующими диски PassThrough :)Anonymous
January 01, 2003
Информация о том, как указать DPM, что производить резервное копирование следует строго последовательно, была приведена в документации к продукту — ещё начиная с Beta-версии. Фактически, там требуется ограничить количество одновременно выполняемых операций единицей. Насколько я понимаю, в окончательной версии продукта этот принцип не изменился. Но документации к ней я пока не видел, так что ждём точного прояснения вопроса.Anonymous
January 01, 2003
Замечу, что это не связано с CSV, а с Hyper-V VSS Writer. Ранее DPM бэкапил ВСЕ виртуалки с диска разом. Теперь делает это последовательно. Если есть аппаратный VSS Provider, то возможна параллельная операцияAnonymous
January 01, 2003
Андрей, не совсем. Это особенности бэкапа Hyper-V. Точнее особенности ограничений встроенного в ОС Hyper-V VSS Writer. У аппаратных VSS провайдеров таких ограничений нет. Если вас устроит бэкап выключенных ВМ (без VSS, или бэкап ОС не имеющих поддержки VSS - Linux, Windows 2000,..) то там нет таких ограничений, т.к. испольузется другой VSS провайдер. CSV тут ни при чем, DPM тоже.Anonymous
January 01, 2003
RuStn — вы можете привести критерии «нормальности» решения? Критерий «красиво/не красиво» — вообще несерьёзен. Во-первых, потому что «красота» решения меньше всего волнует заказчиков. Их волнует «выполняет поставленные задачи/не выполняет», «надёжно/не надёжно», «дорого/дёшево» и так далее. Во-вторых, потому, что в сравнении с VMware — там совершенно так же, работу с метаданными тома (например, создание файла, удаление файла, изменение размеров файла) может производить только один узел в кластере. Остальные работают только с данными внутри файлов. Отличия технологий VMware от CSV, конечно, существуют, но они — в реализации, а не в самой концепции на высоком уровне. Поэтому вы можете абсолютно с теми же основаниями обозвать реализацию VMware «некрасивой». По поводу ваших проблем с нестабильно работающим кластером — это гораздо более интересный вопрос. Но поверьте, это не связано с архитектурой CSV, потому что продукт одинаков у всех заказчиков, и в абсолютном большинстве случаев CSV всё-таки работает корректно. Вы можете не верить мне на слово а пройтись по форумам и посмотреть, какие именно проблемы в основном возникают у пользователей. Почему-то так получается, что обычно это не проблемы с CSV. К сожалению, данных для того, чтобы полностью решить вашу проблему, у нас сейчас недостаточно. Я могу лишь предложить пару идей. а) обновить все компоненты решения до текущех версий, рекомендованных производителем (например, последние Firmware для SAN и контроллеров, последние DSM в случае использования MPIO и так далее). б) провести повторную проверку (Validation) кластера — и убедиться в том, что не возникает ни предупреждений, ни ошибок. в) проверить журналы событий кластера и всех его узлов на предмет ошибок или подозрительных сообщений. То же касается серверов VMM и библиотеки. г) убедиться, что хватает производительности (как SAN, так и обычной сети, по которой идёт передача образа из библиотеки; равно как и серверам библиотеки и VMM). д) если ничего не поможет — предоставить больше информации, обратившисть в техническую поддержку Microsoft, на форумы или авторам блога через форму обратной связи.Anonymous
January 01, 2003
Нет не имеет. Равно как и бэкап любыми сторонними средствами, в которых CSV официально завялена. Поддержка CSV решением нужна на деле не для бэкапа, а для восстановления. Чтобы процесс копирования восстанавливаемых файлов на том инициировался через Cluster API, через узел-координатор, а не простым копированием файлов на LUN с импортом. DPM2010 восстанавливает на CSV корректно. Для вас визуально нет разницы, лежит ВМ на CSV или на выделенном LUN.Anonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
Смягчил акцент в первом комментарии. Лучше? Могу спрятать наше обсуждение его если устроит.Anonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
Верно. Для резервного копирования (вообще, а не только CSV) может применяться два способа: просто копирование файлов и VSS. Очевидно, что первый способ не подходит для запущенных виртуальных машин, остаётся второй. Далее, для VSS можно использовать аппаратные провайдеры или программный. В случае использования программного провайдера требуется копировать виртуальные машины строго последовательно, а не одновременно. Подробности об этом есть в документации по DPM.Anonymous
January 01, 2003
Интересует вопрос о совместимости CSVFS с FSRM У меня щас запущен 4х нодовый SO файловый кластер на котором я разместил при помощи политики Folder Redirection пользовательские данные, когда пытаюсь прикрутить контроль FSRM выдаёт ошибку о несовместимости файловой системы. Что делать ? Будет ли поддержка CSVFS с FSRM ?Anonymous
April 22, 2010
И всё же необходимо было больше пояснений, да и статью бы пораньше... Начнём с того, что CSV это не решение (в смысле нормального решения как у VMware), а просто на скорую руку хакнутая NTFS. Ну давайте по порядку: NTFS может работать только с одним провайдером (точнее к ней может обращаться только один сервер, или же объект). В режиме доступа к NTFS таблице только один сервер (как тут написали узел-координатор). Другие сервера в кластере спрашивают у этого координатора, куда писать или где читать, и потом уже в режиме DirectIO работают с томом. НЕ КРАСИВО ПРЕЖДЕ ВСЕГО. Второе, это вытекуающее из первого, в этом режиме становиться не стабильно работающий кластер, всё время наровящий сломаться, а точнее делать всё, чтоб было плохо виртуальным машинам. При этом узел координатор иногда просто не хочет нормально работать с другими серверами, точнее не стабильно работать. По не понятным причинам, виртуальные сервера, которые разворачиваются с библиотеки например, не могут разместиться на этом томе. Обрыв с ничем не связанной ошибкой, а точнее тупо, ресурс назначения не доступен. Всё, просто так, повторное пинание задания, может продолжить копировать на том, а может снова начать с начала.Anonymous
April 22, 2010
не совсем понял про paththrough диски - ВМ с таким диском живую миграцию может делать?Anonymous
April 22, 2010
2Alex - пассаж в сторону закрытости VMFS и того что это плохо как-то некрасиво прозвучал. Это не плохо, это по другому - и сторонние разработчики могут пользоваться соответствующими API.Anonymous
April 23, 2010
>>Я не говорил "плохо". Закрытость означает невозможность сторонним разработчикам писать свои решения по резервному копированию, например. хмммм.... я не буду тут уводить в сторону от темы поста, скажу лишь что считаю данное утверждение неправильным. В контексте такого упоминания о конкуренте это как-то некрасиво.Anonymous
April 23, 2010
А по поводу бекапа CSV будет обещанная статья?Anonymous
April 23, 2010
Я так понимаю все же есть некоторые особенности бекапа CSV связанные с аппаратными провайдерами VSS. Если они не настроены, то при бекапе нескольких виртуальных машин в одной группе возникает ошибка одновременного множественного доступа к CSV.Anonymous
April 23, 2010
Как минимум DPM2010RC последовательно ничего не делает (без дополнительного "тюнинга"), только если вручную все виртуалки настроить на разные группы и поставить разное время резервного копирования. Возможно в DPM2010RTM он все-таки начнет делать бекапы последовательно, но проверить пока не успел.Anonymous
April 25, 2010
Мне кажется это все и является особенностями бекапа CSV с помощью DPM2010, пусть и не в явном виде.Anonymous
April 25, 2010
Алексей, с вашими доводами невозможно не согласиться, если смотреть на ситуацию со стороны человека знающего все нюансы настройки Hyper-V, SAN и DPM. И различающего тонкости реализации бекапа в разных случаях. Но, знаете как по-разному вам будут описывать разницу между ручной и автоматической коробкой передач в автомобиле люди, которые умеют ездить на механике и которые не умеют? (оффтоп) Алексей, я все-таки предложил бы (или попросил бы) написать на эту тему отдельную статью: с описанием этого "нюанса", о том как "донастраивать" DPM2010 на последовательное копирование (актуально не только для CSV) и про программные и аппаратные реализации VSS и VDS с примерами настройки. Мне кажется это все вполне кореллирует с темой вашего блога. Заранее спасибо.Anonymous
April 28, 2010
Добавлю насчет "красивости" реализации VMFS. Начнем с того, что ESX блокирует ВЕСЬ!!! LUN, во время множества операций (включение, выключение ВМ, вмоушн, создание выключение ВМ, расширение раздела, расширение тонких дисков! и т.п., таких операций много), в это время остальные хосты судорожно делают ретраи к целому тому. Красиво? Конечно :) потенциально если у вас 32 узловой кластер и куча машин, это может привести к интересным ситуациям. (конечно в реальной жизни это редкость :) ) ESX использует резервации, которые могут по той же причине привести к потере производительности (http://www.vmware.com/pdf/vsphere4/r40/vsp_40_san_cfg.pdf - тут так и написано) Можно привести еще несколько примеров, но не холивара же ради :) Так что красота она красотой...