Какой тип хранилища люди фактически используют для серверов VMware ESX?

VMware и многие сетевые евангелисты пытаются сказать вам, что сложные (= дорогие) оптоволоконные SAN являются «единственным» вариантом хранения для серверов VMware ESX и ESXi. Ну да, конечно. Использование SAN быстро, надежно и делает возможным vMotion. Отлично. Но могут ли все пользователи ESX / ESXi действительно позволить себе SAN?

Моя теория состоит в том, что менее 20% всех установок VMware ESX на этой планете на самом деле используют оптоволоконные или iSCS SAN. Большая часть этих установок будет в более крупных компаниях, которые могут себе это позволить. Я бы предсказал, что большинство установок VMware используют «подключенное хранилище» (vmdks хранятся на дисках внутри сервера). Большинство из них работают в МСП, а их так много!

Мы запускаем два сервера ESX 3.5 с подключенным хранилищем и два сервера ESX 4 с iSCS san. И «реальная живая разница» между ними едва заметна :-)

Знаете ли вы официальную статистику по этому вопросу? Что вы используете в качестве носителя?

Я много работаю с консалтингом VMware и скажу, что проценты ближе к 80% установленной базы используют общее хранилище высокой доступности (FC, iSCSI или high-end NAS), и многие из моих клиентов - МСП. Ключевой фактор, который я обнаружил, заключается в том, рассматривает ли компания время работы своего сервера как критическое или нет, для большинства компаний сегодня это так.

Вы, безусловно, можете запускать очень высокопроизводительные виртуальные машины из хранилища с прямым подключением (HP DL380 G6 с 16 внутренними дисками в массиве RAID 10 будет иметь довольно быстрый дисковый ввод-вывод), но если вы создаете VMware или любую другую виртуализированную среду, чтобы заменить десятки, сотни или тысячи серверов, вы безумны, если не вкладываете много сил (и, возможно, денег) в надежную архитектуру хранения.

Вам не нужно покупать высокопроизводительное SAN для функций кластеризации - вы можете реализовать их с помощью довольно дешевого NAS (или виртуального SAN, такого как HP \ Lefthand VSA) и при этом использовать сертифицированное хранилище. Однако, если вы используете общее хранилище, и оно не имеет избыточности во всех точках инфраструктуры SAN \ NAS, тогда вам не следует использовать его для гораздо большего, чем для тестирования. И резервирование - это (как минимум) двойные (независимые) сетевые адаптеры HBA \ хранилища на ваших серверах, двойные независимые матрицы, резервированные контроллеры в сети SAN, резервное копирование кэш-памяти с резервным питанием от батареи, резервные вентиляторы с горячей заменой, блоки питания и т. Д., RAID 5 \ 6 \ 10 \ 50 и соответствующее количество горячих резервов.

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

Поскольку у нас более тысячи хостов, мы начали с FC, некоторое время пробовали iSCSI, но отказались от FC из-за проблем с производительностью. Мы серьезно смотрим на NFS, но пока не имеем никаких выводов. Да, и мы используем HP XP / EVA и некоторые NetApp, у нас нет локальных панелей хранения рабочего стола / хостов разработчиков.

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

Для высокопроизводительных операций записи и чтения я нашел FC непревзойденным по производительности, и хотя цена высока ... Это просто работает ... для более обыденных ожиданий производительности iSCSI на самом деле работает довольно хорошо, поэтому я обычно получаю обмениваться файлами почтовых ящиков сервера в дисковой подсистеме FC и собственно загрузочными дисками на интерфейсном диске iSCSI, причем DNS-серверы и компьютеры Active Directory также работают с iSCSI

Я запускаю ESX с SAN, NAS и DAS. Это полностью зависит от:

1. бюджет
2. опыт
3. центр обработки данных и / или место в стойке
4. Деньги

По надежности и скорости, я не думаю, что вы можете победить SAN.

Для надежности и стоимости я бы пошел с NAS.

А по скорости и стоимости, DAS.

Не то чтобы отдельные варианты не пересекались с некоторыми, но это сильные стороны, которые я засвидетельствовал.

Мы используем 4 сервера ESX 4 и используем EqualLogic iSCSI SAN.

В небольших установках локальное хранилище вполне приемлемо, если у вас есть подходящие диски - я бы сказал, 10k RPM + диски SAS. Единственный раз, когда вы ДОЛЖНЫ использовать общий диск (я намеренно не сказал san, поскольку ваш общий диск может быть отключен, а общий ресурс NFS) - это когда вам нужно выполнить кластеризацию - VMWare HA и DRS.

На данный момент у нас есть 3 уровня хранилища - FiberChannel SAN, High End Equalogix SAN и Low End MD3000i SAN. Последние два - iSCSI. Мы также запускаем некоторые серверы из локального хранилища серверов ESX - в основном это служебные серверы, которые нас не интересуют, если они не работают в течение часа или двух, пока мы исправляем ситуацию, если все пойдет не так.

Мы также запускаем нашу тестовую среду на домашнем NAS-накопителе, используя диски SATA 7,2 КБ и корпоративную цель iSCSI (производительность не так уж и высока, но она нам помогает).

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

Мы запускаем четыре (ну, в общем, четыре в прямом эфире, один для тестирования) хоста ESXi с матрицей iSCSI, построенной из обычных коммутаторов, и низкоуровневую Hitachi SAN - SMS-100.

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

Каждый из томов VFS имеет четыре видимых пути, поэтому он достаточно терпим. Мы используем коммутацию Dell Powerge для фабрики - у них наверняка есть потенциальные проблемы (меньше всего, нет резервных блоков питания) ... но они также достаточно дешевы, так что наличие двух предварительно сконфигурированных запасных частей в коробке, готовой к замене, становится реальной возможностью.

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

У всего есть свои плюсы и минусы ... Итог - SLA, загрузка приложений и масштаб. Поэтому, если вам нужно высокопроизводительное хранилище для небольшого развертывания (1-5 хостов), вы, вероятно, можете использовать его с NFS (на самом деле однажды я достиг лучшей задержки с NFS, чем с SAN с использованием RAM-дисков). Теперь попробуйте масштабировать это, и вы обнаружите, что стоимость репликации вашей установки в масштабе очень сравнима с хорошим SAN, что делает FC единственным логическим вариантом для просмотра ... В большинстве случаев я заканчиваю тем, что использую комбинации для различных сервисов (приложений). БД, резервные копии, архивы) не единой платформой для оптимизации затрат, в зависимости от потребностей.