Pull to refresh

Опыт организации SAN на SAS

Reading time 3 min
Views 30K
Облака и виртуализация – термины уже привычные и плотно вошедшие в нашу жизнь. С ними же пришли и новые проблемы для IT. И одна из основных – как обеспечить в облаке (читайте кластер для виртуализации) адекватную производительность общего дискового хранилища?


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

Правильный системный интегратор скажет, что Infiniband и пара шкафов с 3Par позволит, внедрив их один раз, никогда больше не думать о производительности SAN, но не у всех есть место в аппаратной для установки лишних шкафов с дисками. Что же тогда? В первую очередь нужно определить узкое место, мешающее виртуальным машинам наслаждаться всеми 2000 IOPs, которые обещает отдавать полка с дисками.

На нашем стенде, где мы когда-то учились строить кластер, IOMeter из виртуальной машины загружал 2х1Gbe iSCSI на 100% и показывал отличные результаты – практически те же обещанные 2000 IOPs. Но когда ВМ стало несколько десятков, и все они довольно активно пытались использовать дисковую систему, то обнаружился неприятный эффект – загрузка сети не подходит и к половине, контроллер на полке и IOPs – в запасе, а на виртуальных машинах все тормозит. Оказалось, в таких условиях узкое место – это задержки в сети передачи данных (латентность). И в случае реализации SAN на iSCSI 1Gbe она просто огромна.

Так на основе какого протокола строить SAN, если масштаб не требует подключения сотен систем хранения, тысяч серверов и размещать все планируется в двух – трех стойках одного ЦОДа? iSCSI 10Gbe, FC 8GFC? Есть решение лучше — SAS. И самый лучший аргумент в выборе – это соотношение цена/качество.

Давайте сравним затраты и результат при построении простенькой SAN из 2х СХД с 6 серверами-клиентами.
Требования к SAN:
  • Высокодоступное подключение
  • Скорость передачи данных не менее 8Гб/с

Классическое решение подобной задачи выглядит так:


Допустим, что стоимость СХД с двумя контроллерами iSCSI 10 Gbe, FC или SAS стоят одинаково. Остальные компоненты перечислим в таблице (к ценам можно придираться – но порядок такой):


По цене решение на базе SAS выглядит замечательно! Фактически оно близко к стоимости решения на iSCSI 1Gbe.
Такой подход был использован при построении первой очереди IaaS-платформы Облакотеки.

Что показали тесты?
На виртуальной машине, работающей в релизной SAN среди 200 других, запустили IOMeter.

Нагрузка на СХД до теста:


Нагрузка на СХД во время теста:


Настройки теста IOMeter:


Настройки рабочих процессов IOMeter:


Показатели IOMeter во время тестирования:


Выводы:
Влияние сотни одновременно работающих с СХД виртуальных машин не привели к характерным для iSCSI 1 Gbe падениям производительности. IOMeter показал ожидаемые IOPs для тестовой виртуальной машины – возможный максимум за минусом рабочей нагрузки.

Итак, плюсы этого решения:
  • Пропускная способность. Каждый порт – это 4х канальный SAS2 – т.е. в теории можно получить 24Гбит на каждый порт.
  • Латентность. Она на порядок ниже, чем у iSCSI 10GbE и FC 8GFC. В задаче виртуализации большого количества серверов это становиться решающим значением в битве за виртуальный IOPs.
  • Достаточно прост в настройке.

Есть конечно и минусы:
  • Нет репликации через SAS. Для резервирования данных нужно искать иное решение.
  • Ограничение длины кабеля – 20 метров.

При вроде бы очевидных преимуществах, популярность такого решения не очень высокая. По крайней мере, habr не пестрит отчетами. В чем основная причина: молодость технологии, узкий сегмент применения, слабая масштабируемость…? Или может все втихаря давно используют? :)
Tags:
Hubs:
+17
Comments 37
Comments Comments 37

Articles

Information

Website
www.oblakoteka.ru
Registered
Founded
Employees
Unknown
Location
Россия