Какой raid для vmware

Обновлено: 04.07.2024

В данном материале описываются требования инфраструктуры VMWare к хранилищу, технические характеристики RAIDIX и рекомендации по настройке СХД на базе RAIDIX для нужд виртуализации.

Особенности СХД для виртуализации

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

Решение RAIDIX для хранения данных в виртуализированной среде позволяет упростить процесс управления системой, сделать его более автоматизированным и получить больше ИТ-ресурсов за каждый рубль, вложенный в корпоративную инфраструктуру.

Среди ключевых параметров хранения:

Средства соединения

Для соединения VMware ESXi и СХД можно использовать различные протоколы подключения — FCP, iSCSI, NFS. Виртуальные машины (ВМ) могут использовать соответствующие файлы (конфигурация и vDISKs) на всех предоставляемых датасторах. При этом могут использоваться все функции VMware, связанные с хранением данных (VMotion, VMware DRS, VMware HA и VMware Storage VMotion).

Производительность

Достигаемая производительность зависит от используемого для хранения сервера (функций RAID-контроллера и дисков). Благодаря уникальным алгоритмам «Рэйдикс» и эффективной параллелизации вычислений RAIDIX поддерживает максимально возможную — с аппаратной точки зрения — пропускную способность. Кроме того, системы на базе RAIDIX позволяют достичь эластичной масштабируемости без потери в скорости при увеличении количества виртуальных машин и параллельных высоконагруженных потоков данных.

Совместимость

RAIDIX поддерживает платформы виртуализации VMware ESX 5.0/5.1/5.5/6.0; KVM (Kernel-based Virtual Machine); RHEV (Red Hat Enterprise Virtualization), Microsoft Hyper-V Server, XenServer.

Архитектура RAIDIX для задач виртуализации

Рис. 1. Схема работы VMWare на СХД RAIDIX

Настройка виртуальной инфраструктуры на RAIDIX

1. Установка RAIDIX

Рекомендуется использовать массив RAID 6 с двойным распределением четности, основанный на математических алгоритмах собственной разработки «Рэйдикс». RAID 6 обеспечивает повышенную производительность, так как каждый диск массива обрабатывает I/O запросы самостоятельно, позволяя осуществлять доступ к данным в параллельном режиме.

RAID 6 может выдержать полный отказ двух дисков в одной группе. Для повышения производительности в корпоративной среде массивы RAID 6 рекомендуется инициализировать (RAID 6i, где i — initialized). В процессе инициализации диски изначально заполняются нулями, что в дальнейшем способствует более быстрому выполнению транзакционных операций.

Для эффективной работы системы также рекомендуется активировать функцию упреждающей реконструкции. Данный механизм позволяет оптимизировать скорость чтения в процессе восстановления данных на дисках за счет исключения из процесса дисков, скорость чтения с которых ниже, чем у остальных.

Упреждающая реконструкция может использоваться в следующих режимах:

Постоянно: система «запоминает» диски с наибольшим временем отклика и перестает отправлять им запросы в течение одной секунды, при этом данные восстанавливаются за счёт решения системы уравнений. Затем система выявляет другие диски, и данные вновь восстанавливаются. Таким образом, удается увеличить производительность системы.
По требованию: механизм запускается только в том случае, если в RAID-группе появляется один медленный диск. Система перестает отправлять ему запросы, в UI диску присваивается статус «медленный», а администратору предоставляется возможность выполнить замену.

2. Настройка ESXi

В первую очередь осуществляется настройка таргета (например, Fibre Channel). Таргет подключается к VMware ESXi. Затем происходит настройка датасторов в двухконтроллерном режиме (Active-Active). В данном режиме оба узла активны, работают одновременно и имеют доступ к единому набору дисков. Под узлами понимаются аппаратно-независимые компоненты системы хранения данных, которые имеют собственные процессоры, кэш-память, материнскую плату и могут быть объединены в кластер.

RAIDIX обеспечивает непрерывность доступа к данным и высокую степень отказоустойчивости за счет:

дублирования узлов;
дублирования каналов подключения к дискам (оба узла подключены к единому набору дисков).

Взаимодействие узлов системы между собой осуществляется по каналам InfiniBand, iSCSI (через Ethernet), Fibre Channel, SAS, что позволяет производить синхронизацию данных и состояния кэшей.

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

Дублирование аппаратных компонентов и интерфейсов обеспечивает защиту от следующих сбоев:

В наш век облачных сервисов, AWS Lambda и прочих ~~шаред хостингов~~ абсолютно неосязаемых вычислительных ресурсов иногда хочется немножко своего. Кроме желания, иногда бывают и потребности вдумчиво покрутить тот или иной программный продукт с минимальными затратами на платформу. Найти какие-то излишки матчасти можно почти всегда, иногда даже получается собрать всё вместе и включить. Если излишки эти представляют собой CPU хотя бы на 4-6 ядер и памяти от 64ГБ — вообще отлично, можно брать ESXi и работать с чем угодно. Одна проблема: с дисковой ёмкостью на бытовом железе у VMWare — совсем никак. Производительность локальных одиночных HDD невысокая, а уж утратить содержимое отдельно взятого, сферического в вакууме винта в 21м веке — это как здрасьте. Попробуем подключить что-нибудь по сети.

TL;DR> объединение, балансировка, rr limit, вот это вот всё.

Собственно, текст далее не про то, что это вообще возможно или ноу-хау какое-то. Интернет полон статьями для чайников (вот здесь ставим галочки, затем Next, Next, Done) о том, как подать дисковую ёмкость по iSCSI. Пишу как раз для того, чтобы исключить «ошибки выживших» и поделиться моментами, когда «всё пойдёт не так» (а оно пойдёт, Мерфи был прав), и при попытке нагрузить решение оно просто падает.

Итак, мы попробуем раздушить наш «бытовой гипервизор» внешним дисковым массивом, подключенным по сети. Поскольку у нас всё крутится вокруг «недорого», пусть это будет FreeNAS и 4 SATA-диска, которые обслуживает средненький 3 ГГц 45-нм проц. Смотрим на Ebay, и за сравнимые с б/у RAID-контроллером деньги тащим оттуда пару сетевых карточек i350-T4. Это четырёхпортовые гигабитные адаптеры от Intel. По ним и будем связывать хранилку с гипервизором.

Немножко посчитаем. Средняя скорость передачи данных среднего SATA диска — 160-180 МБ/сек при ширине интерфейса в 6 Гбит/с. Фактически, реальная скорость передачи данных с HDD не превышает 2 Гбит/с. Не такая уж большая цифра, учитывая, что связь мы планируем по 4м гигабитным портам (как именно превратить 4x1Гбит в 4 Гбит — обсудим далее). Намного хуже все со скоростями произвольного доступа — здесь всё падает чуть ли не до уровня дискет.

Учитывая, что профиль дисковой нагрузки от множества гостевых ОС — далёк от линейного, хотелось бы видеть более веселые цифры. Для исправления ситуации в файловой системе гипервизора ( VMFS v6) размер блока составляет 1 МБ, что способствует уплотнению множества случайных операций и ускоряет доступ к данным на виртуальных дисках. Но даже с этим одного физического диска будет недостаточно для обработки операций ввода-вывода от всех «гостей».

Сразу оговорюсь — всё дальнейшее имеет смысл, если у вас адаптеров для «сети хранения» больше двух. ESXi с бесплатной однопроцессорной лицензией умеет подключаться, кроме локальных дисков, к хранилищам двух типов — NFS и iSCSI. NFS предполагает доступ файлового уровня и тоже по-своему хорош. На нем можно развернуть гостей, нетребовательных к дисковой производительности. Бэкапить их — одно удовольствие, т.к. можно открыть эту же NFS шару ещё куда-либо и копировать снапшоты вм. В общем, с одним сетевым интерфейсом (если это не 10GE, конечно) — NFS ваш выбор.

У iSCSI есть ряд преимуществ перед NFS. Для того, чтобы реализовать их в полной мере, мы уже подготовились — заложив для сети хранения аж 4 гигабитных порта. Как обычно происходит расширение пропускной способности сети при известной скорости интерфейсов? Правильно, агрегацией. Но для полной утилизации агрегированного канала нужен целый ряд условий, и это подходит больше для связи коммутаторов между собой либо для сетевого аплинка гипервизора. Реализация протокола iSCSI предусматривает такую функцию, как multipathing (дословно, много путей) — возможность подключения одного и того же тома через разные сетевые интерфейсы. Само собой, про возможность балансировки нагрузки там тоже есть, хотя основное назначение — отказоустойчивость сети хранения. (Справедливости ради, NFSv4.1 поддерживает session trunking на базе совершеннейшей магии типа RDMA и MPTCP, но это попытка переложить проблемы файлового доступа ~~с больной головы на здоровую~~ на нижние уровни.)

Итак, для начала опубликуем наш таргет. Считаем, что FreeNAS установлен, IP-адрес управления исправно отгружает нам web-интерфейс, массив и zvol на нём мы нарезали в полном соответствии с нашими внутренними убеждениями. В нашем случае это 4 х 500ГБ диска, объединённых в raidz1 (что даёт всего 1,3 ТиБ эффективной ёмкости), и zvol размером в 1 ТБ ровно. Настроим сетевые интерфейсы i350, для простоты принимаем, что все будут принадлежать разным подсетям.

Затем настраиваем iSCSI-шару методом «Next, Next, Done». При настройке портала не забываем добавить туда все сетевые интерфейсы, выделенные для iSCSI. Выглядеть должно примерно так, как на картинках.

Чуть больше внимания потребуется уделить настройке extent — при презентации тома необходимо форсировать размер блока 512 байт. Без этого инициатор ESXi вообще отказывался опознавать презентованные тома. Для верности лучше отключить проброс размеров физ блока (которого на zvol нет и быть не может) и включить режим поддержки Xen.
С FreeNAS пока всё.

Особое внимание при настройке сети под iSCSI уделяем параметру MTU. Это как раз тот случай, когда «размер имеет значение» — берём максимум, который позволяют установить все компоненты сети. Если карточки соединены напрямую, можно указать mtu 9000 на обоих сторонах, на ESXi и FreeNAS. Впрочем, нормальные коммутаторы это значение поддержат. Пингуем, видим, что сеть у нас в норме, и пакеты требуемого размера проходят. Отлично. Поджигаем инициатор.

Включаем iSCSI, добавляем IP-адреса в динамическую секцию настройки (Storage -> Adapters -> Configure iSCSI -> Dynamic targets). После сохранения будет выполнен опрос iSCSI порталов по этим адресам, инициатор определит, что за каждым из них стоит один и тот же том, и подключится к нему по всем доступным адресам (тот самый multipath). Дальше нам потребуется создать datastore на появившемся устройстве.

После этого можно раскатать виртуальную машинку и замерить, что у нас получилось.

Не такие уж впечатляющие результаты. Открываем консоль хранилища, выводим текущее состояние сети и запускаем тесты.

Утилизирован лишь один сетевой порт из четырёх (igb1). Происходит это потому, что механизм балансировки, предусмотренный по умолчанию для multipath, с каждым пакетом данных выбирает один и тот же адаптер. Нам же надо задействовать из все.
Подключаемся к гипервизору по SSH и командуем.
Для начала глянем, какой ID у луна с multipath, и как он работает:

] esxcfg-mpath -b
naa.6589cfc000000b478db42ca922bb9308 : FreeNAS iSCSI Disk (naa.6589cfc000000b478db42ca922bb9308)

] esxcli storage nmp device list -d naa.6589cfc000000b478db42ca922bb9308 | grep PSP
Path Selection Policy: VMW_PSP_MRU

Политика выбора путей — MRU, то бишь most recently used. Все данные идут в один и тот же порт, перевыбор пути происходит только при недоступности сетевого соединения. Меняем на round-robin, при которой все интерфейсы меняются по очереди после какого-то числа операций:

] esxcli storage nmp device set -d naa.6589cfc000000b478db42ca922bb9308 -P VMW_PSP_RR

Перезагружаем ESXi, открываем мониторинг, запускаем тесты. Видим, что нагрузка распределяется по сетевым адаптерам равномерно (как минимум, пиковые значения, лишнее поскипано), результаты теста тоже повеселее.

Есть некоторые отклонения по портам, это возникает из-за лимитов Path Selection Policy — числа операций либо байт, после которого происходит переключение на другой порт. По умолчанию 1000 IOPS, то есть если обмен данными уложился в 999 операций — он пройдет через один сетевой порт. Можно менять, сравнивать и подбирать подходящее значение. Можно не менять, дефолта достаточно для большинства задач.

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

Особенности СХД для виртуализации

Среди ключевых параметров хранения:

Средства соединения

Производительность

Совместимость

Архитектура RAIDIX для задач виртуализации

Рис. 1. Схема работы VMWare на СХД RAIDIX

Настройка виртуальной инфраструктуры на RAIDIX

1. Установка RAIDIX

Упреждающая реконструкция может использоваться в следующих режимах:

Постоянно: система «запоминает» диски с наибольшим временем отклика и перестает отправлять им запросы в течение одной секунды, при этом данные восстанавливаются за счёт решения системы уравнений. Затем система выявляет другие диски, и данные вновь восстанавливаются. Таким образом, удается увеличить производительность системы.
По требованию: механизм запускается только в том случае, если в RAID-группе появляется один медленный диск. Система перестает отправлять ему запросы, в UI диску присваивается статус «медленный», а администратору предоставляется возможность выполнить замену.

2. Настройка ESXi

RAIDIX обеспечивает непрерывность доступа к данным и высокую степень отказоустойчивости за счет:

дублирования узлов;
дублирования каналов подключения к дискам (оба узла подключены к единому набору дисков).

Дублирование аппаратных компонентов и интерфейсов обеспечивает защиту от следующих сбоев:

Я создаю виртуальную среду для малого бизнеса. Он основан на одном хосте ESXi 5.1, на котором будет размещено около полудюжины виртуальных машин. Однако у меня есть некоторые сомнения относительно того, как реализовать хранилище. Я, естественно, хочу, чтобы хранилище данных было отказоустойчивым, но я не могу получить средства на отдельный накопитель или дорогостоящие аппаратные RAID-решения, поэтому я бы хотел использовать некоторый программный RAID (lvm /mdadm, скорее всего). Как это можно реализовать? Моя единственная идея до сих пор заключалась бы в создании виртуальной машины с адаптером хранения как сквозной, помещает некоторый программный RAID поверх дисков, а затем представляет результирующие тома «назад» на хост ESXi, который затем создает хранилище данных, из которого другие виртуальные машины получить их хранение.

Это вроде бы круто, у меня есть лучшие варианты? Из моих исследований, транзит, похоже, имеет немало недостатков, таких как отсутствие приостановки /возобновления и т. Д.

ESXi не является ОС общего назначения и не должен считаться полностью привязанным к списку совместимости оборудования и, следовательно, использовать проверенный и одобренный аппаратный RAID-адаптер. Выберите, чтобы сделать что-нибудь еще, и вы присоединитесь к другим людям, которые срезали углы и вернулись сюда, жалуясь на то, что их системы не работают или они потеряли данные - мы получаем много из них.

Кажется, это круто, у меня есть лучшие варианты?

Ваша общая идея - спот-он. Я лично предложил бы использовать ZFS с Solaris или FreeBSD, но mdadm также может работать. Может быть, хотя у вас нет всех преимуществ, о которых я пишу в этом посте, так что возьми это как отказ от ответственности. Этот пост будет довольно длинным, я заранее извиняюсь за стену текста.

Из моих исследований, сквозной проход, похоже, имеет немало недостатков, таких как отсутствие приостановки /возобновления и т. д.

Есть некоторые, в частности:

Работает только с поддержкой vt-d (или AMD IOMMU) на процессоре (Intel) или плате ЦП + (AMD): нет проблем, сегодня без него невозможно получить сервер, так как каждый процессор Intel за исключением того, что Atoms имеют его (даже в базовых системах от HP, Dell и других).
VMware-снимки всех виртуальных машин с переданными элементами не могут быть созданы: в теории проблема, но это затрагивает только вашу виртуальную машину хранения, которая имеет минимальную настройку конфигурации и не используется ни для чего другого. Вы можете делать снимки на уровне хранилища, где они быстрее, дешевле и не замедляют работу системы. Кроме того, вы можете без проблем сфотографировать все другие виртуальные машины на хосте (и даже объединить их с моментальными снимками файловой системы для мощных параметров восстановления и долговременного архивирования состояний).
В некоторых областях ваша внутренняя сложность увеличивается. На первый взгляд это правда - вы добавляете дополнительный слой, и вам нужно управлять большим количеством вещей, например, вашей новой внутренней SAN (настройка сети /VLAN в VMware) или самой виртуальной памяти вашего хранилища (обновления и т. д.). Но, с другой стороны, у вас также есть простота и гибкость:
- Согласованные резервные копии запущенных виртуальных машин могут создаваться автоматически с помощью нескольких простых скриптов и полностью бесплатны. Они также могут быть сохранены на другой машине, диске или облаке (зашифрованы), без каких-либо дополнительных дорогостоящих программных решений.
- Если ваш сервер умирает, просто купите новую замену, установите ESXi, включите сквозной проход, настройте свою сеть, добавьте диски и загрузите виртуальную машину хранилища. После того, как он встал, выполните повторное сканирование вашего хранилища, и это похоже на простое сбой питания, все ваши данные безопасны, и вы это знаете (вместо этого с HW RAID вы надеетесь, что это так).
- Особые требования могут быть выполнены с минимальными изменениями по мере необходимости. У бизнеса есть устаревшее приложение, для которого требуются локальные диски для резервного копирования? Просто настройте iSCSI и прозрачно представляйте свое хранилище. Они испытывают рост и нуждаются в большем объеме хранения? Просто увеличьте пул с большим количеством дисков и представите их либо непосредственно через iSCSI, либо через VMware (NFS или iSCSI с vmdk сверху). Они хотят использовать базу данных на гибком отдельном сервере? Просто откройте свою NFS на другой LAN /VLAN и поставьте ее на новый сервер как «реальную» SAN.
Простой графический процессор работает только для дорогих карт Nvidia и всех карт AMD: В настоящее время это правда, но для виртуальной машины хранения в любом случае не требуется выделенный графический процессор.

Существуют также общие досады, не связанные с прохождением:

Чтобы перезагрузить виртуальную машину хранения, все остальные виртуальные машины, которые зависят от нее, должны быть сначала отключены: Эта очевидная проблема редко упоминается, но в моих глазах наиболее раздражает. Конечно, обновления для ESXi также требуют полной перезагрузки, но поскольку у вас теперь есть две системы, время может не синхронизироваться отлично. Я рекомендую стабильную операционную систему и выравнивание некритических обновлений между обеими системами. Кроме того, вы должны ограничить VM хранилища своей собственной внутренней виртуальной локальной сетью, что еще больше уменьшит необходимость применения исправлений сразу после их выпуска. Обратите внимание, что это также относится к случайным перезагрузкам виртуальной машины хранения из графического интерфейса пользователя.
Ошибки в базовом стеке делают вашу машину неработоспособной: Этот риск увеличивается по сравнению с ESXi, потому что теперь у вас есть две системы и два сетевых стека между ними. С яркой стороны как ваша виртуальная память, так иESXi обычно должен быть стабильным, а ошибок должно быть немного. Тем не менее, я советую запланировать обновления несколько дней /недель после выпуска, чтобы вы могли увидеть, есть ли у других проблемы. Не меняя конфигурацию, с другой стороны, это очень стабильно, что является плюсом для SME (требуется меньше поддержки).
Решение не известно стороннему персоналу службы поддержки: Это довольно редкая настройка, поэтому вероятность того, что ваша случайная замена может понять ее без вашей документации с самого начала, - это может быть проблема или преимущество, в зависимости от ваших бизнес-целей. Это можно смягчить с помощью некоторой базовой документации, объясняющей структуру установки (используйте рисунки /диаграммы!), Сравнение с традиционной настройкой RAID и что делать в общих случаях (резервное копирование, восстановление, замена диска, обновления, сетевые изменения, аппаратное расширение).

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

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

Я бы уволил тебя, если бы я был маленьким бизнесом, и ты развернул что-то вроде этого . Это обычная тема. VMware имеет четко определенный список совместимости оборудования . Однако при использовании в качестве автономного сервера вы используете аппаратный RAID NEED . Не-RAID-диски будут работать, но это не то, что вы хотите. Итак, мои вопросы:

Недостаточно средств для хранения? Что это за серверное оборудование? Вы можете позволить себе диски, но не RAID-контроллер? Совместимый RAID-контроллер не стоит дорого.
Разве это не случай управления ожиданиями клиентов? Очевидно, что отдельное хранилище будет более дорогостоящим, чем аппаратный RAID.
Пока решения для хранения «все-в-одном» , они лучше подходят для конкретных технических требований, а не для сокращения затрат.

Это случай злоупотребления VMware. Программный RAID не поддерживается. Я бы вернулся к клиенту и пересмотрел сборку /требования.

«Сколько стоят ваши данные?»

Это означает, что предупреждения об использовании стандартного оборудования действительны. ESXi довольно придирчив.

«Я, естественно, хочу, чтобы хранилище данных было отказоустойчивым, но я не могу получить средства для отдельной накопительной машины или дорогостоящий аппаратный RAID решений, поэтому я хотел бы использовать некоторый программный RAID (lvm /mdadm, most скорее всего). Как это можно реализовать?

esxi не будет работать без RAID-массива REAL HW для хранилища данных . Не будет работать даже программный рейд на базе BIOS.

Получил мой контроллер рейда Adaptec 6405e за 100 $ на Ebay!

НО в отношении следующей части

Моя единственная идея до сих пор заключалась в том, чтобы создайте виртуальную машину с адаптером хранения как сквозную, добавьте некоторые программный RAID поверх дисков, а затем представляет тома «назад» на хост ESXi, который затем создает хранилище данных из которые другие виртуальные машины получают в своем хранилище ».

Мой «FileServer» состоит из 4x5TB HD передается непосредственно на VM . Затем я построил mdadm Raid 5 в общей сложности около 14 ТБ и экспортировал его по NFS ко всем моим виртуальным машинам. Около 15/20 в любое время, с 10/20 dev VM, которые отключены, если не используются. Это хорошо сработало для меня, но это не с большой группой пользователей. Infact Я действительно единственный локальный пользователь, но у меня есть веб-сайты, которые генерируют некоторый трафик, но опять же, они статичны в основном.

Хороший вопрос, который нужно задать в этом сценарии, если вы подумываете об использовании этой идеи, для чего нужен FileServer?

В моем случае 90% моих виртуальных машин, если не все, размещают все необходимые данные внутри виртуальной машины (linux) и имеют размер менее 20 ГБ. Я использую FileServer в качестве центрального репо для резервных копий, также любые мультимедийные приложения, такие как Plex, будут считывать с FileServer, а мой P2P сохраняет непосредственно на FileServer, но не на моих хостах есть база данных или все, что находится на FileServer. Тем не менее, они делают все свои резервные копии на FileServer. Мой файловый сервер - это моя единственная виртуальная машина, на которой размещаются 2 службы, и это NFS для виртуальных машин, а также SMB для доступа к Windows через графический интерфейс. Это чудесно сработало для меня. Я также установил FileServer через NFS в качестве хранилища данных, и я смогу подключить ISO к новым виртуальным машинам из хранилища данных. Я также резервирую OVA snapshopts поверх SMB в окнах непосредственно на FileServer. Запуск виртуальных машин на экспортированном программном рейде NFS будет сумасшедшим, но экспорт большого хранилища данных NFS обратно на хост esXi имеет много преимуществ.

Я большой поклонник программных RAID (Linux), потому что они гибкие, экономичные, простые в управлении и полностью предсказуемые. В реальных сценариях они всегда выигрывают аппаратные RAID-контроллеры среднего класса для скорости. Единственная проблема - получить надежный RDM или контроллер диска через VM, который запускает NAS. Большинство недорогих контроллеров LSI в режиме ИТ делают трюк. Я получаю потрясающую скорость и стабильность с помощью программного обеспечения RAID10 на виртуальном NAS на базе Openmediavault (адаптер Vmxnet3, Paravirtual disk controller), который экспортирует хранилище данных для других виртуальных машин на том же хосте через NFS (внутренняя ссылка 10 Гбит).

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

Другим преимуществом такой установки будет то, что mdadm хорошо документирован, легко восстановить соединение с другим сервером в случае сбоя сервера.

Однако вы должны учитывать, что обычная настройка ESXi не ожидает, что хранилище данных будет на одном сервере с ESXi. В вашем случае, если жесткий диск с ESXi и /или «виртуальной машиной, у которой адаптер для хранения данных в виде сквозной прогонки» терпит неудачу (и, конечно, не в RAID), ваш хранилище данных больше не будет доступно. Если вы разделили хранилище данных, вам понадобится меньше шагов для восстановления настроек в случае сбоя. Поэтому я считаю, что вам следует попробовать снова найти средства для отдельного компьютера хранилища данных. Это может быть используемый ПК с процессором 1-2 ГГц и контроллером SATA, где вы можете настроить ОС Linux с помощью mdadm.

P.S. Не забудьте настроить мониторинг (например, уведомления по электронной почте) о состоянии вашего RAID-массива mdadm.

Поддержка программного RAID-массива существует в ESXi для динамического интеллектуального контроллера массива HPE. Я использую его на DL20 g9 с зеркальными SSD-накопителями Enterprise, и он отлично работает.

Тем не менее, я просто взял Smart Array 440 от eBay за 200 долларов США, что является аппаратным RAID без каких-либо причин, кроме тех случаев, когда этот выбор предоставляется, всегда идите на оборудование.

Мне понравился ESXi, когда я впервые его использовал, мне все еще нравится, но больше не люблю его, и тестирует proxmox в качестве альтернативы.

Что я узнаю, так это то, что VMWARE, конечно же, хотят зарабатывать деньги, и они, вероятно, согласятся с поставщиками аппаратного обеспечения, чтобы поддерживать только аппаратное обеспечение класса high-end, что повышает их продажи в обмен на откаты от этих поставщиков, я знаю, что другое правдоподобное объяснение для управления их накладными расходами на поддержку, но я думаю, что это больше связано с «поощрением» людей к аппаратным средствам на сервере.

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

Однако мои домашние системы подключены к устройствам ИБП, а мои бизнес-системы в центрах обработки данных имеют ИБП, поставляемый центром обработки данных. Я считаю, что такие вещи, как программный zfs-рейд, намного безопаснее, чем что-то вроде HP smartarray, а также защита от битов, а также прямой доступ к состоянию SMART на диске.

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

Я вижу все негативные комментарии, и я понимаю, что эти люди не знают, как работает VSAN. пожара кого-то , только потому, что они используют технологию, которую VMware поддерживает в своем собственном продукте? Честно говоря, это говорит о недостатке менеджера в поиске и принятии советов или о постоянном обучении.

Прочитайте проект старого SAN (PMS), в котором два хоста с пересылкой на дисковых устройствах Glusterfs тома и обслуживают результирующее хранилище блоков через iSCSi обратно в тот же кластер. Это был гений.

Читайте также: