Отказоустойчивое Hyper-V-хранилище

Поставьте слова «Microsoft» и «хранилище» рядом в одном и том же предложении, и большинство из нас, ветеранов ИТ, просто усмехнется. Добавьте слово «отказоустойчивый», и, пожалуй, над вами от души посмеются. Как вы знаете, раньше союз Microsoft и хранилищ был не особо счастливым. Многие испытывали горькое разочарование, когда тома Windows неожиданно терпели крах, или попадали в дурацкую ситуацию, когда у серверов, которые должны работать бесперебойно, основные диски становились динамическими.

И теперь вы, вероятно, думаете: «Отказоустойчивость для VM Hyper-V? Программная? Да вы с ума сошли!». В прошлые годы эти понятия были совершенно несовместимыми. К счастью, времена меняются, и поставщики ОС тоже. Если вы посмотрите архитектуры хранения, встроенные в современную ОС Windows Server 2012, то увидите, что Microsoft передает большой привет поставщикам, предлагающим хранилища для виртуализации.

В центре всех этих чудес находятся две технологии, которые при совместном использовании оказываются достойной альтернативой отказоустойчивым VM Hyper-V: Server Message Block (SMB) 3.0 и Scale-Out File Server (SOFS). Благодаря большим инвестициям в первый из них этот когда-то отвергнутый протокол по производительности почти не уступает аппаратным реализациям, и обладает впечатляющей масштабируемостью. Благодаря выпуску второго стало существенно проще соединение серверов Hyper-V и их VM. Мне нравится думать, что с помощью SOFS можно без труда сделать доступной любую VM.

Купили SAN, хотим NAS

SAN в течение долгого времени были разумным выбором хранилищ для виртуализации. Такая структура совместно используемого хранилища стала обязательной при переносе VM без их остановки. Однако самая сильная сторона SAN при поддержке такого переноса приводит и к самым большим затруднениям. SAN используют в соединениях своих хранилищ низкоуровневые протоколы, такие как iSCSI и Fibre Channel. Эти протоколы обеспечивают огромную гибкость, если вам приходилось часто разбираться в их тонкостях. В противном случае они могут стать кошмаром для администратора.

Если вы когда-либо пытались установить несколько соединений Multipath I/O (MPIO) с iSCSI SAN или Fibre Channel через адаптеры шины (host bus adapters, HBA), вам знакома эта головная боль (рис. 1). Вы должны тщательно настроить каждое соединение, причем для обеспечения избыточности каждый сервер должен поддерживать несколько соединений. Автоматизация минимальна. Запросто можно ошибиться. Повторите эти операции на нескольких хостах Hyper-V, и ваша сеть хранения вскоре будет напоминать карту Парижа.

Рис. 1. Для поддержки прямых соединений с SAN требуется много сложных соединений

Windows Server 2012 SOFS (рис. 2) чрезвычайно упрощает управление паутиной соединений между Hyper-V-серверами и хранилищами. В сочетании с SMB 3.0, обеспечивающим более высокую производительность и масштабируемость, он выполняет большую часть работы по созданию соединений без вашего участия.

При использовании SOFS для доступа к VM Hyper-V требуется указать UNC-путь: \\сервер\общий каталог \папка\vm.vhdx и приложить еще немного усилий. SMB 3.0 автоматически обеспечит все остальное —  избыточность, балансирование нагрузки, восстановление после сбоя и еще целый ряд отказоустойчивых сетевых функций. Кроме того, кластер SOFS по своей природе работает в режиме «активный-активный», значит, для поддержки хранилища ваших VM Hyper-V не придется покупать сервер, который не будет использоваться.

Рис. 2. Scale-Out File Server объединяет соединения с SAN, действуя как объединенное хранилище SAN

Такая архитектура определяет отказоустойчивое хранилище. Эта цель достигается за счет того, что она становится похожей на NAS, больше чем на SAN. Если предположить, что внутри вашей SAN-инфраструктуры обеспечивается высокая доступность, все, о чем вам нужно позаботиться, — правильное объединение NIC (сетевых адаптеров) на хостах Hyper-V hosts. Это проще, удобнее и лучше.

Microsoft предоставляет документацию, описывающую, как развертывать  SOFS. Процесс развертывания состоит из установки роли File Server и компонента Failover Clustering, создания кластера и создания Cluster Shared Volume (совместно используемый том кластера, CSV).

Альтернативные варианты Hyper-V-хранилищ

SAN, возможно, — лучшее решение при организации Hyper-V-хранилищ, но не все из нас — ИТ-профессионалов, мастеров на все руки, — были бы рады иметь ее в своем центре данных. Вы можете сказать,  что угроза простоя среды является не такой уж критичной или что из-за ограниченности бюджета приходится «творчески» подходить к администрированию Hyper-V. В любом случае, Windows Server 2012 поддерживает пару альтернативных способов организации хранилищ, которые могут подойти в вашем случае.

В первом из них используются возможности SMB 3.0. Он не поддерживает функциональность высокой доступности (HA), обеспечиваемую SOFS. Вы можете просто установить роль File Services в экземпляр Windows Server 2012 и создать общий SMB-ресурс для приложений, работающий с напрямую присоединенным хранилищем (direct-attached storage, DAS) (рис. 3). Это специфический вид общего файлового ресурса, который использует преимущества в производительности SMB 3.0 при доступе к VM Hyper-V, но не поддерживает балансирование нагрузки, восстановление после сбоя и другие функции SOFS. Если ваша среда и бюджет позволяют мириться с периодическими простоями, то выполнение VM с общих SMB-ресурсов позволит в полной мере воспользоваться простотой UNC-путей без затрат на дорогостоящую SAN.

Рис. 3. Общий SMB-ресурс — профиль Applications

Вторая альтернатива с момента своего появления стала причиной большой путаницы. Технология Storage Spaces — нововведение Windows Server 2012 и Windows 8. Ее цель — создать среду, подобную SAN, на основе DAS. Подобно своими предшественникам — имеющим неоднозначную репутацию динамическим дискам, — Storage Spaces обеспечивает HA для массово выпускаемых дисков, создавая программный RAID.  Для защиты от потерь данных на отдельных дисках поддерживаются зеркалирование, двойное зеркалирование и контроль четности.

Говоря буквально, сама по себе Storage Spaces — не такая уж революционная технология. Это, по сути, пул дисковых пространств, создаваемый из нескольких устройств хранения. Путаница возникает, когда Storage Space соединяют более чем с одним Windows Server. Такую архитектуру называют Clustered Storage Spaces. Как вы могли бы подумать, Clustered Storage Spaces — это сочетание Failover Clustering со Storage Spaces.

«Пространство», участвующее в кластеризации, существует как «небольшой набор серверов… и набор совместно используемых JBOD-массивов  с доступом через SAS (secure attention sequence)» (и это слова Microsoft). В этой конфигурации серверы соединены SAS-соединениями с одними или несколькими JBOD-массивами (just a bunch of disks, просто пачка дисков) (рис. 4). Оба хоста осуществляют равноправный доступ к дискам массивов, а Storage Spaces служит посредником между хостами при доступе.

Рис. 4. Два сервера, соединенные с массивом SAS JBOD

Пока что некому судить об эффективности такого подхода, в котором то присутствует SAN, то ли ее нет. Похоже, что на данный момент только один поставщик — DataON Storage — предлагает сертифицированные массивы SAS JBOD, соответствующие требованиям Storage Spaces.

SOFS в нашей работе

Пожалуй, хорошо, что у нас под рукой есть SOFS. Больше года назад, когда мне впервые показали SOFS, я громко удивился: «Кто в мире купит эту штуку?». В то время было тяжело увидеть преимущества добавления еще одного уровня в и без того сложные среды наших центров данных.

И все-таки, чем дольше я имел дело с SOFS, тем большим уважением к нему проникался. Он поможет вам заниматься тем, что вы умеете лучше всего, и при этом позволит администраторам Hyper-V сосредоточиться на обеспечении работоспособности своих VM. Совместно с SMB 3.0 SOFS выступает в роли посредника. Он предлагает среду хранения для VM Hyper-V, подобную NAS, и по производительности почти не уступающую традиционным SAN.