Облака и виртуализация – термины уже привычные и плотно вошедшие в нашу жизнь. С ними же пришли и новые проблемы для 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 не пестрит отчетами. В чем основная причина: молодость технологии, узкий сегмент применения, слабая масштабируемость…? Или может все втихаря давно используют? :)
Автор: MaximZakharenko
