Pull to refresh

Comments 11

А не тестировали производительность? Хотелось бы увидеть сравнение Catalyst с Nexus по IOPS и Latency.
проверял nexus 5010
для iscsi печально с латенси, FC\FCoE не пробовал, бытует мнение что они годны только для FC\FCoE
HP Pro Curve 6120XG from HP c7000 хорошо себя показал
На счет FC/FCoE могу заверить, что проблем с latency вообще не было, у меня была отдельная плата FC, как положено, настроен zoning и прочее, если честно завелось с пол пинка, поэтому проводить замеры по скоростям не стали, да и особо времени не было.
На счет iscsi к сожалению ничего сказать не могу.
А вы использовали QoS, MTU900, функции DCB такие как LLDP, TLV, PFC?
QoS и MTU 9000
nexus 5010 не умеет DCB нормально для iscsi, нету всех TLVs
согласно рекомендациям делл отключили DCB
Задержка заметно возросла по сравнению с 6120XG
Использую HP Pro Curve 6120XG (MTU 9000) и FAS2240. Игрался с дёрганьем линков и ребутом голов/свичей под нагрузкой. Протормозок не заметил, но им особо не откуда было бы взяться, максимальная нагрузка на порт составила всего 40%
У меня с 6120 и mtu 9000 почему-то кластерная сеть не поднялась с ontap 8.3rc1/8.3.1rc1.
Вы могли бы дать свой конфиг свича, версию прошивки, включенные фичи?
Не уточнил, у меня не кластер, а обычный HA Pair 7-Mode. Стоит ontap 8.1.2, одна полка FAS2240-2 с двумя головами, два свича, с каждой головы по шнурку в каждый свич. У каждого коннекта свой IP и на клиенте все 4 подключены в iSCSI Multipath. Всё как по учебнику :)
Первый вариант был с объединением линков в LAGG, но тогда при пропадании линка терялась пара пакетов, что не айс, а в таком конфиге как сейчас, всё ок.
navion
Производительность свичей не тестировалась. В данном случае в этом нет большой надобности.

Так как архитектура кластеризации Data ONTAP устроена таким образом, чтобы кластерные интерконнекты исспользовались только в редких ситуациях. Как правило каждый контроллер и его порты обслуживают данные, которые непосредственно расположены на том же контроллере, для, чего разработан ряд механизмов, таких как:
  • ALUA (для SAN)
  • pNFS 4.1 (NAS)
  • и CIFS v3.0 (NAS)

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

Вопрос ухудшения отклика меня не интересовал, так при выборе двух из трех пунктов
  • Онлайн миграция
  • Скорость отклика
  • Возможность исспользования подручных свичей

Вопрос скорости отклика был на самом последнем приоритете.
Неплохо бы добавить информацию о том, что при обращении в техподдержку NetApp, такое решение поддерживаться не будет :)
А в целом очень полезная статья. У многих существует соблазн построить кластер на уже имеющихся коммутаторах хотя бы для тестов. Хоть цены на CN1610 более, чем адекватные.
Вы абсолютно правы, именно по-этому во всей статье постоянно делается упор на то, что это временная конфигурация.
Only those users with full accounts are able to leave comments. Log in, please.