FC против iSCSI на 10GbE: выбираем хранилище для корпоративного клиента
Проектировали новое SAN-хранилище: 8Gb Fibre Channel против iSCSI на 10GbE. Протестировали задержки, посчитали железо - выбрали iSCSI и сэкономили клиенту 40% на коммутаторах и HBA.
В 2010 году 10GbE iSCSI становится реальной альтернативой 8Gb Fibre Channel для корпоративных хранилищ
Клиент строит новую инфраструктуру с нуля: десяток физических серверов, несколько хостов ESXi, корпоративное SAN-хранилище. Объём данных пока не гигантский, но задержки важны - там база 1С и несколько приложений, которые реально чувствуют I/O. Главный вопрос при проектировании: Fibre Channel или iSCSI?
Пять лет назад вопроса бы не стояло - FC и точка. Но сейчас на рынке появляются 10-гигабитные Ethernet-карты по вменяемым ценам, и iSCSI перестал быть историей про "дёшево и плохо".
Что сравнивали
С одной стороны - 8Gb Fibre Channel. Зрелая технология, предсказуемые задержки, выделенная фабрика, никаких конкурентов за полосу с IP-трафиком. Два FC-коммутатора в отказоустойчивой конфигурации, HBA в каждый сервер.
С другой - iSCSI поверх 10GbE. Тот же Ethernet, но на 10 гигабитах. Карты с поддержкой TOE (TCP Offload Engine) или iSCSI HBA разгружают CPU от обработки стека. Коммутаторы - обычные 10GbE, которые уже есть или стоят дешевле FC-fabric.
Стенд собрали на реальном железе: два сервера HP ProLiant DL380 G6, СХД с одинаковыми дисковыми полками. На FC-стороне - Emulex HBA, 8Gb FC-коммутаторы Brocade. На iSCSI-стороне - QLogic QLE8142 (iSCSI HBA с аппаратным offload), 10GbE-коммутаторы в выделенной VLAN, изолированной от прочего трафика.
Что показал тест
Синтетику гоняли через IOMeter: последовательное чтение и запись, случайный I/O 4K и 64K, разные глубины очередей. Вот где стало интересно.
На последовательных операциях большими блоками разницы практически нет - оба варианта упирались в дисковую полку раньше, чем в сетевой стек. На случайном мелком I/O (4K random read) FC показал чуть меньшие задержки в абсолютных числах - порядка 0,3-0,5 мс против 0,5-0,8 мс у iSCSI при глубине очереди 1. Разница есть, но на практике это не те цифры, из-за которых 1С будет тормозить.
При нагрузке с глубиной очереди 8-16 (что ближе к реальному серверному I/O от нескольких VM) цифры сходились ещё ближе.
Одно важное условие: на iSCSI-стороне выделенная VLAN с QoS, jumbo frames включены (MTU 9000), никакого постороннего трафика на этих портах. Если гнать iSCSI поверх общей корпоративной сети без приоритизации - результаты будут другими, и не в пользу iSCSI.
Почему выбрали iSCSI
Сели считать деньги. Два FC-коммутатора Brocade 300 - это существенная статья. HBA под FC дороже iSCSI-карт на 10GbE при сопоставимых характеристиках. Если у клиента уже есть или планируется нормальный 10GbE для серверной - коммутаторы частично перекрываются. FC - это всегда отдельная фабрика, отдельный capex, отдельная экспертиза.
В итоге iSCSI-конфигурация обошлась клиенту примерно на 40% дешевле по статьям коммутаторов и адаптеров. При этом тест не показал деградации, которая была бы ощутима прикладными системами.
Есть и операционный аргумент: 10GbE умеет каждый сетевой инженер, а FC - это отдельная специализация. Нанять или найти подрядчика по Ethernet-инфраструктуре в 2010 году заметно проще, чем искать FC-специалиста в регионе.
Что взяли в итоге
- Хранилище - Dell EqualLogic PS6010, нативно iSCSI, автоматическое распределение нагрузки между контроллерами.
- Сеть - выделенные 10GbE-порты на серверах, отдельный коммутатор, изолированная VLAN, jumbo frames.
- Серверные карты - iSCSI HBA с аппаратным offload; программный инициатор Microsoft тоже работает, но при серьёзной нагрузке CPU жалко.
- Multipath - через Microsoft MPIO или VMware NMP, зависит от того, физический сервер или хост ESXi.
EqualLogic сам умеет балансировать соединения между несколькими портами и контроллерами через собственный механизм, что упрощает конфигурацию multipath по сравнению с ручной настройкой FC-зонирования.
Где FC всё ещё побеждает
Честно скажем: если у клиента уже есть FC-фабрика и обслуживающий её персонал, тащить iSCSI поверх него ради экономии - сомнительная идея. Стоимость миграции и переобучения съест разницу в железе.
Также FC остаётся более предсказуемым в сценариях с очень высокой нагрузкой и жёсткими требованиями к латентности - там, где задержка в доли миллисекунды действительно имеет значение (высоконагруженные OLTP-базы, трейдинговые системы). Для типичного корпоративного клиента с 1С, Exchange и файловыми серверами - таких требований нет.
Для сопровождения инфраструктуры клиентов без унаследованного FC-оборудования iSCSI на 10GbE стал для нас основным вариантом при проектировании нового хранилища. Не потому что FC плохой - а потому что разница в задержках на практике не оправдывает разницу в бюджете.