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

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

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

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

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

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

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

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

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

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

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

Если вам нужен iscsi или nfs, то, как минимум, вам понадобится несколько портов 10/40 ГБ или Infiniband, что на сегодняшний день является самым дешевым вариантом, но собственные решения для хранения данных для Infiniband кажутся ограниченными. Проблема будет в модуле bladecenter, каковы его параметры, обычно 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, то это решение, которое вам следует выбрать.

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

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

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