VMware и многие сетевые евангелисты пытаются сказать вам, что сложные (= дорогие) оптоволоконные сети SAN - это «единственный» вариант хранения для серверов VMware ESX и ESXi. Ну да, конечно. Использование SAN - это быстро, надежно и делает возможным vMotion. Отлично. Но: действительно ли все пользователи ESX / ESXi могут позволить себе сети SAN?
Моя теория заключается в том, что менее 20% всех инсталляций VMware ESX на этой планете фактически используют оптоволоконные сети или iSCS SAN. Большинство этих установок будет производиться более крупными компаниями, которые могут себе это позволить. Я бы предположил, что в большинстве установок VMware используется «подключенное хранилище» (виртуальные машины VMDK хранятся на дисках внутри сервера). Большинство из них работают в малых и средних предприятиях, а их так много!
Мы запускаем два сервера ESX 3.5 с подключенным хранилищем и два сервера ESX 4 с iSCS san. И «настоящая живая разница» между ними едва заметна :-)
Знаете ли вы какую-либо официальную статистику по этому вопросу? Что вы используете в качестве носителя информации?
Я провожу много консультационной работы с VMware и могу сказать, что процентное соотношение около 80% установленной базы использует разделяемое хранилище высокой доступности (FC, iSCSI или high-end NAS), и многие мои клиенты - это SME. Ключевым фактором, который я обнаружил, является то, считает ли бизнес время безотказной работы сервера критичным или нет, для большинства предприятий сегодня так оно и есть.
Вы, безусловно, можете запускать очень высокопроизводительные виртуальные машины из хранилища с прямым подключением (HP DL380 G6 с 16 внутренними дисками в массиве RAID 10 будет иметь довольно быстрый дисковый ввод-вывод), но если вы создаете VMware или любую другую виртуализированную среду для замены десятков, сотен , или тысячи серверов, то вы безумны, если не вкладываете много усилий (и, возможно, денег) в надежную архитектуру хранения.
Вам не нужно покупать высокопроизводительную SAN для функций кластеризации - вы можете реализовать их с помощью довольно дешевого NAS (или виртуализированного SAN, такого как VSA HP \ Lefthand) и при этом использовать сертифицированное хранилище. Однако, если вы используете общее хранилище, и оно не имеет избыточности во всех точках инфраструктуры 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. Это полностью зависит от:
Что касается надежности и скорости, я не думаю, что вы можете превзойти 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.2k и iSCSI Enterprise Target (производительность не так уж хороша, но это помогает).
Многие люди также склонны работать против акций NFS в более крупных средах. Я хотел поиграть с этим какое-то время, но не нашел времени.
Мы запускаем четыре (ну, четыре действующие, один для тестирования) хоста ESXi с фабрикой iSCSI, построенной из стандартных коммутаторов, и младший Hitachi SAN - SMS-100.
Даже на этом уровне у нас есть двойные контроллеры, каждый из которых имеет двойные порты на объединительной плате SAS, поэтому любой контроллер может захватывать диски, и двойные сетевые адаптеры, которые мы переключаем на сдвоенные коммутаторы и на двойные сетевые адаптеры в хостах ESX.
У каждого тома vfs есть четыре видимых пути, так что это достаточно терпимо. Мы используем коммутатор Dell poweredge для коммутационной сети - у них наверняка есть потенциальные проблемы (меньше всего, отсутствие резервных блоков питания) .. но они также достаточно дешевы, поэтому наличие двух предварительно настроенных запасных частей в коробке, готовой к замене, становится реальной возможностью.
очевидно, что если вы хотите больше девяток, вам нужно потратить больше денег, но я думаю, что прелесть iSCSI, ESXi и обычного комплекта Gigabit Ethernet в том, что вы можете превзойти свой вес с точки зрения устойчивости и производительности.
У всего есть свои плюсы и минусы ... Итог - SLA, загрузка приложений и масштабирование. Так что, если вам нужно высокопроизводительное хранилище для небольшого развертывания (1-5 хостов), вы, вероятно, могли бы справиться с этим с помощью NFS (на самом деле однажды я добился большей задержки с NFS, чем с SAN с использованием RAM-дисков). Теперь попробуйте масштабировать это, и вы обнаружите, что стоимость репликации вашей установки в масштабе очень сравнима с хорошей SAN, что делает FC единственным логичным вариантом для просмотра ... В большинстве случаев я использую комбинации для различных служб (приложений , БД, бэкапы, архивы) ни одной платформы для оптимизации затрат в зависимости от потребностей.