Выбор технологии SAN для сотен виртуальных веб-серверов

Проблема

У нас есть проблема с производительностью на существующей платформе, поэтому я обращаюсь к улье за ​​вторым мнением по этому вопросу. Пока проблема с производительностью связана с IOPS, а не с пропускной способностью.

Сценарий

Блейд-центр из 16 хостов, каждый с 64 ГБ оперативной памяти. (Это Dell M1000e с M610s, но это, вероятно, не имеет значения) 500 виртуальных машин, все веб-серверы (или связанные с ними веб-технологии, такие как MySQL, балансировщики нагрузки и т. Д.), Около 90% составляют Linux и остальные Windows. Гипервизор - это VMWare vSphere. Нам нужно предоставить HA HA, чтобы локальное хранилище вышло. Таким образом, хосты просто имеют SD-карту для загрузки.

Немного фона мышления

На данный момент у нас до 6 хостов (центральный блейд-сервер будет работать на полную мощность через несколько лет при текущем росте) и мы используем iSCSI для Dell MD3220i с MD1220 для расширения.

Возможные варианты, которые мы рассмотрели, и ближайшие мысли вместе с ними:

• Распределение виртуальных машин по хранилищам данных NFS и запуск хранилища NFS, отвечающего требованиям к производительности для определенного количества виртуальных машин. NFS кажется более дешевым в масштабировании, а также абстрагировано немного больше, чем хранилище на уровне блоков, поэтому мы можем перемещать его по мере необходимости.
• Добавление большего количества контроллеров / целей MD3220i. Мы обеспокоены тем, что это может как-то негативно повлиять на то, как VMWare справится с множеством целей.
• Обмен всех дисков с Nearline SAS на SSD. Это должно полностью решить проблему IOPS, но имеет очевидный побочный эффект - сокращение нашей емкости хранения. Также это все еще очень дорого.
• vSphere 5 имеет устройство хранения. Мы не так много исследовали, но это должно работать хорошо?

Вопрос

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

Я не ищу ответы «Купи SAN x, потому что это лучшее». Я ищу мысли о различных технологиях SAN (iSCSI, FC, FCoE, InfiniBand, NFS и т. Д.), Различных типах хранилищ (SATA, SAS, SSD) и методологиях обработки хранилищ для сотен виртуальных машин (консолидация, разделение). , Шардинг и тд).

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

Большое спасибо заранее за любой вклад!

Обновление 5 марта '12

Некоторые фантастические ответы до сих пор, большое спасибо всем!

Продолжая ответы на этот вопрос до сих пор, я начинаю думать, что следующим путем является путь:

• Распределите доступное хранилище по кластеру VMWare и поместите диски VM в подходящее хранилище для своих рабочих нагрузок.
• Потенциально используйте SAN, которая способна автоматически управлять размещением данных в подходящем хранилище.
• Infiniband выглядит наиболее экономически эффективным для получения необходимой пропускной способности при полной загрузке хостов.

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

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

Ключом к хорошей платформе хранения VMWare является понимание того, какую нагрузку создает VMWare.

• Во-первых, поскольку вы размещаете много серверов, рабочая нагрузка обычно является случайной. Есть много потоков ввода-вывода, идущих одновременно, и не многие из них могут быть успешно предварительно кэшированы.
• Во-вторых, это переменная. Во время обычной работы вы можете увидеть 70% случайного чтения, однако в тот момент, когда вы решите переместить ВМ в новое хранилище данных или что-то еще, вы увидите массивную последовательную запись 60 ГБ. Если вы не заботитесь об архитектуре, это может нанести ущерб способности вашего хранилища обрабатывать нормальный ввод-вывод.
• В-третьих, небольшая часть вашей среды обычно генерирует большую часть рабочей нагрузки хранилища.

Лучший способ создать хранилище для платформы VMWare - начать с основ.

• Вам нужна возможность обслуживать большую рабочую нагрузку случайного чтения, что означает более быстрые диски меньшего размера, а также, возможно, SSD. Большинство современных систем хранения данных позволяют автоматически перемещать данные в зависимости от того, как к ним осуществляется доступ. Если вы собираетесь использовать SSD, вы хотите убедиться, что именно так вы его и используете. Это должно быть как способ постепенного уменьшения горячих точек. Независимо от того, используете ли вы SSD или нет, полезно распределить всю работу по всем дискам, поэтому было бы полезно что-то с пулом хранения.
• Вам нужна способность обслуживать прерывистые большие записи, которая не заботится о скорости вращения шпинделя соответствующих дисков, но заботится об эффективности стека контроллера и размере кеша. Если у вас есть зеркальное кэширование (которое не является обязательным, если вы не хотите возвращаться к резервным копиям при возникновении сбоя контроллера), пропускная способность между двумя кешами, используемыми для зеркального отображения, будет вашим узким местом для больших последовательных записей, как правило. Убедитесь, что у вас есть высокоскоростной контроллер (или кластер) для кэширования записи. Сделайте все возможное, чтобы получить высокоскоростную интерфейсную сеть с как можно большим количеством портов, оставаясь при этом реалистичной по цене. Ключом к хорошей производительности внешнего интерфейса является распределение нагрузки на хранилище как можно большим количеством внешних ресурсов.
• Вы можете серьезно сократить расходы, имея уровень для хранилища с низким приоритетом, а также тонкое выделение ресурсов. Если ваша система не выполняет автоматическую миграцию отдельных блоков на дешевые большие или медленные диски (например, SAS или SATA ближней линии с размерами 7200 об / мин и 2 ТБ +), попробуйте сделать это вручную. Большие медленные диски являются отличными целями для архивов, резервных копий, некоторых файловых систем и даже серверов с низким уровнем использования.
• Настаивайте на том, чтобы хранилище было интегрировано с VAAI, чтобы VMWare могла отменить выделение неиспользуемых частей виртуальных машин, а также хранилищ данных.

Мои крупные развертывания VMWare - это NFS и iSCSI более 10GbE. Это означает наличие двухпортовых 10-гигабитных адаптеров на серверах, а также памяти. Я фанат ZFS-хранилища для этого. В моем случае, он обернут вокруг коммерческого NexentaStor , но некоторые предпочитают кататься самостоятельно.

Ключевыми особенностями хранилища на основе ZFS в этом контексте будут функции кэширования ARC / L2ARC, позволяющие размещать хранилища на разных уровнях. Наиболее активные данные найдут свой путь в ОЗУ и SSD-хранилище в качестве второго уровня. Запуск основного пула хранения с дисками SAS 10 или 15 тыс. Также был бы полезен.

Это еще один случай профилирования и понимания вашей рабочей нагрузки. Работайте с кем-то, кто может проанализировать ваши схемы хранения и помочь вам планировать. На стороне ZFS / NexentaStor мне нравится PogoStorage . Без такого понимания метод переноса (FC, FCoE, iSCSI, NFS) может не иметь значения. Есть ли у вас мониторинг вашей существующей инфраструктуры? Как выглядит операция ввода / вывода сейчас?

Ключевой вопрос: "где узкое место?" Вы упоминаете IOPS, но означает ли это, что вы точно определили сами диски как узкое место, или просто то, что порты SAN не работают на полную мощность, или что виртуальные машины находятся в гораздо большем количестве iowait, чем вы хотели бы?

Если вы определенно определили, что диски являются ограничивающим фактором, то переключитесь на NFS или infiniband или что-то еще, что не приведет к приседу для вашей производительности - вам нужны SSD (или, по крайней мере, многоуровневое хранилище с SSD в смеси) или целый комплект, больше шпинделей (решение, которое само по себе стало намного дороже в последнее время, так как мировое производство шаговых двигателей было смыто в океан).

Если вы не уверены на 100%, где на самом деле находится узкое место, вам сначала нужно это выяснить - замена частей вашей инфраструктуры хранения более или менее случайным образом на основе догадок других людей здесь не будет очень эффективно (особенно учитывая, насколько дорогостоящими будут какие-либо изменения).

Если вы хотите использовать iscsi или nfs, вам понадобятся как минимум несколько портов 10/40 ГБ или infiniband, что является самым дешевым вариантом, но собственные решения для хранения данных для infiniband кажутся ограниченными. Проблема будет в модуле для blade-центра, какие у него варианты, обычно 8gb fc или 10 \ 1gbe и, возможно, infiniband. Обратите внимание, что infiniband можно использовать с nfs, и с точки зрения производительности \ цены ничто не закрыто. если блейд-центр поддерживает qdr infiniband, я бы сделал это с каким-нибудь хостом linux с qdr infiniband tca через nfs. Вот хорошая ссылка, описывающая это http://www.zfsbuild.com/2010/04/15/why-we-chose-infiniband-instead-of-10gige

но если BladeCenter может поддерживать QDR Infiniband, и вы можете позволить себе нативную Infiniband, то это решение, которое вы должны выбрать.

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

Локальное хранилище отсутствует? Я вполне доволен пропускной способностью записи на моем локальном RAID 5 с зеркальным отображением с помощью DRBD8 для кластерного партнера моей машины XEN ... (но это, конечно, "не поддерживается").

Кроме того, я совершенно уверен, что mySQL - это проблема вашей производительности (я никогда не видел худшую БД). Попробуйте отключить его и / или попытаться поместить всю БД в кеш файловой системы (для доступа на чтение) ...