Comments 11
А не тестировали производительность? Хотелось бы увидеть сравнение Catalyst с Nexus по IOPS и Latency.
UFO just landed and posted this here
На счет FC/FCoE могу заверить, что проблем с latency вообще не было, у меня была отдельная плата FC, как положено, настроен zoning и прочее, если честно завелось с пол пинка, поэтому проводить замеры по скоростям не стали, да и особо времени не было.
На счет iscsi к сожалению ничего сказать не могу.
На счет iscsi к сожалению ничего сказать не могу.
Использую 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, но тогда при пропадании линка терялась пара пакетов, что не айс, а в таком конфиге как сейчас, всё ок.
Первый вариант был с объединением линков в LAGG, но тогда при пропадании линка терялась пара пакетов, что не айс, а в таком конфиге как сейчас, всё ок.
navion
Производительность свичей не тестировалась. В данном случае в этом нет большой надобности.
Так как архитектура кластеризации Data ONTAP устроена таким образом, чтобы кластерные интерконнекты исспользовались только в редких ситуациях. Как правило каждый контроллер и его порты обслуживают данные, которые непосредственно расположены на том же контроллере, для, чего разработан ряд механизмов, таких как:
Таким образом кластерные свичи, как правило, нужны только для подстраховки на тот момент, пока данные мигрируют из одной ноды на другую. Другими словами в нормально настроенном и работающем продакшн кластерные свичи не вносят коррективов в скорость отклика к данным так как практически не исспользуются.
Вопрос ухудшения отклика меня не интересовал, так при выборе двух из трех пунктов
Вопрос скорости отклика был на самом последнем приоритете.
Производительность свичей не тестировалась. В данном случае в этом нет большой надобности.
Так как архитектура кластеризации Data ONTAP устроена таким образом, чтобы кластерные интерконнекты исспользовались только в редких ситуациях. Как правило каждый контроллер и его порты обслуживают данные, которые непосредственно расположены на том же контроллере, для, чего разработан ряд механизмов, таких как:
- ALUA (для SAN)
- pNFS 4.1 (NAS)
- и CIFS v3.0 (NAS)
Таким образом кластерные свичи, как правило, нужны только для подстраховки на тот момент, пока данные мигрируют из одной ноды на другую. Другими словами в нормально настроенном и работающем продакшн кластерные свичи не вносят коррективов в скорость отклика к данным так как практически не исспользуются.
Вопрос ухудшения отклика меня не интересовал, так при выборе двух из трех пунктов
- Онлайн миграция
- Скорость отклика
- Возможность исспользования подручных свичей
Вопрос скорости отклика был на самом последнем приоритете.
Неплохо бы добавить информацию о том, что при обращении в техподдержку NetApp, такое решение поддерживаться не будет :)
А в целом очень полезная статья. У многих существует соблазн построить кластер на уже имеющихся коммутаторах хотя бы для тестов. Хоть цены на CN1610 более, чем адекватные.
А в целом очень полезная статья. У многих существует соблазн построить кластер на уже имеющихся коммутаторах хотя бы для тестов. Хоть цены на CN1610 более, чем адекватные.
Sign up to leave a comment.
Кластеризация СХД NetApp используя подручные свичи