Рекомендации по общему хранилищу для Hyper-V (часть 1)

Введение

Одно из важнейших соображений, которое необходимо учитывать при развертывании сервера Hyper-V, — это хранилище. Не только ваш сервер должен иметь достаточную емкость хранилища, но и подсистема хранения должна быть способна обеспечить достаточный ввод-вывод для удовлетворения требований виртуальной машины. Кроме того, система хранения должна обеспечивать своего рода избыточность, чтобы не стать единой точкой отказа.

Как вы понимаете, планирование хранилища Hyper-V — непростая задача. К счастью, вариантов много. Хитрость заключается в том, чтобы оценить доступные варианты и выбрать решение, которое соответствует вашим требованиям к производительности, отказоустойчивости и бюджету.

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

Самое важное соображение об отказоустойчивости

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

В этом случае я всегда рекомендую своим клиентам реализовать отказоустойчивый кластер, чтобы предотвратить превращение хост-сервера в единую точку отказа. Проблема в том, что отказоустойчивый кластер для Hyper-V требует использования общего хранилища, что может быть дорогостоящим. Когда Microsoft в конце концов выпустит Windows Server 8 и Hyper-V 3.0, требования к общему хранилищу исчезнут. Однако на данный момент кластеры Hyper-V часто выходят за рамки бюджета небольших организаций. Такие организации обычно заканчивают тем, что используют хранилище с прямым подключением.

Хранилище с прямым подключением

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

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

После рассмотрения очень ограниченного бюджета моего друга и потребностей его бизнеса мы решили купить высокопроизводительный ПК, а не настоящий сервер. У компьютера было шесть портов SATA, поэтому мы планировали использовать один порт для загрузочного диска, один порт для устройства записи DVD (что было бизнес-требованием) и оставшиеся четыре порта для массива RAID 5.

Несмотря на то, что за последние несколько лет RAID 5 вышел из моды, в данном случае это имело смысл, поскольку объединение четырех дисков в массив RAID 5 обеспечило бы более высокую производительность (с точки зрения ввода-вывода), чем зеркальный набор. Хотя RAID 5 не работает так же хорошо, как RAID 0, встроенный контроль четности с лихвой компенсирует любую потерю производительности или емкости.

Когда все детали прибыли, я настроил новый компьютер так, как мы планировали. Однако, несмотря на то, что мы построили массив из дисков SATA 3, которые были рассчитаны на 6 гигабит в секунду, массив был мучительно медленным. На самом деле копирование файлов в массив обеспечивало постоянную скорость передачи всего около 1 МБ в секунду. Более того, массиву почти всегда не удавалось копировать большие файлы.

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

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

Еще я делаю документирование всех настроек BIOS. При документировании настроек BIOS я заметил, что BIOS компьютера идентифицировал все жесткие диски как IDE, а не ACPI. Хотя это, безусловно, могло объяснить проблемы с производительностью, система не позволяла мне установить для дисков ACPI.

После множества проб и ошибок я обнаружил, что порты SATA с первого по четвертый могут работать либо в режиме IDE, либо в режиме ACPI, а порты 5 и 6 могут работать только в режиме IDE. Чтобы решить эту проблему, я переместил загрузочный диск с порта 1 на порт 5 и переместил устройство записи DVD с порта 2 на порт 6. Затем я установил порты с первого по четвертый для использования режима ACPI и подключил диски для массива хранения.

Прежде чем я смог использовать сервер, мне пришлось перенастроить BIOS для загрузки с диска на порту 5. Мне также пришлось использовать консоль управления дисками Windows, чтобы полностью перестроить RAID-массив. Как только я это сделал, дисковый массив начал обеспечивать ожидаемый уровень производительности.

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

Выбор RAID

Если вы в конечном итоге настроите Hyper-V для использования локального массива RAID, вам придется решить, какой тип массива RAID вы хотите использовать. Ваши варианты различаются в зависимости от количества дисков, с которыми вам приходится работать. Вот несколько мыслей о некоторых распространенных уровнях RAID:

Таблица 1

Вывод

До сих пор я говорил о хранилище с прямым подключением для Hyper-V, но хранилище с прямым подключением — не единственный вариант. Во второй части я расскажу об общем хранилище.