Ядро SAN

[golovoruk]

Коллеги, что лучше: одна фабрика с двумя коммутаторами в ядре или две фабрики?

Критерии "лучшести":
1) доступность
2) управляемость
3) производительность (включая балансировку каналов в фабрике)

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

У меня аргументы в пользу двух фабрик "лучшая балансировка нагрузки".

У него аргументы - "более простая управляемость" , т.к. настройки надо делать только в одной фабрике, а не в двух.

[ITER]

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

У меня аргументы в пользу двух фабрик "лучшая балансировка нагрузки".

У него аргументы - "более простая управляемость" , т.к. настройки надо делать только в одной фабрике, а не в двух.

А с чего вы взяли что будет "лучшая балансировка нагрузки"? По моему единственное преимущество двух фабрик это отказоустойчивость, если слетят настройки в одной, останутся пути через другую.

[CrazyFrog]

Всегда-всегда-всегда в SAN должно быть две независимые фабрики.

Что ты буешь делать, когда понадобится обновить прошивку на коммутаторе? Или когда он будет ребутится с багчеком? (это происходит чаще, чем об этом говорят)

[ITER]

Всегда-всегда-всегда в SAN должно быть две независимые фабрики.

Что ты буешь делать, когда понадобится обновить прошивку на коммутаторе? Или когда он будет ребутится с багчеком? (это происходит чаще, чем об этом говорят)

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

[golovoruk]

А с чего вы взяли что будет "лучшая балансировка нагрузки"?

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

При наличии двух фабрик можно софту мультипафинга приказать "балансировать" и он будет распределять нагрузку трафика через обе фабрики.

Возможно я упускаю какие-то нюансы...
[/quote]

[a_shats]

Только, если multi-path софт поддерживает балансировку нагрузки

[ITER]

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

При наличии двух фабрик можно софту мультипафинга приказать "балансировать" и он будет распределять нагрузку трафика через обе фабрики.

Возможно я упускаю какие-то нюансы...

Ну не знаю, у меня мультипассинг внутри одной фабрики прекрасно работает и задействуются все доступные пути. Опять же, транк между свитчами тоже никто не отменял. По статистике портов работают все. Либо я что-то не понимаю либо...

[golovoruk]

Ну не знаю, у меня мультипассинг внутри одной фабрики прекрасно работает и задействуются все доступные пути. Опять же, транк между свитчами тоже никто не отменял. По статистике портов работают все. Либо я что-то не понимаю либо...

Я опираюсь на материалы INFINITY I/O где черным по белому написано:
"...FSPF - implemets load sharing, not load balancing."
"... FSPF does not load-balance across ISLs. Some ISLs can be congested while others are underutilized"

Похожую тему утверждает руководство от IBM "Designing and Optimizing an IBM Storage Area Network Featuring the IBM 2109 and 3534" стр. 81.

Однако в материалах INFINITY I/O идет пометка, что ряд вендоров ввели балансировку путем внедрения своих проприетарных протоколов балансировки.

Анализируя материалы Cisco вижу, что везде утверждаются, что у них балансировка внутри фабрики осуществляется.

Так же нашел похожее утверждение в документе QLogic.

Т.о. необходимо придерживаться простого правила: применять в одной фабрике коммутаторы одного производителя и тогда балансировка линков скорее всего будет осуществляться.

[ITER]

Т.о. необходимо придерживаться простого правила: применять в одной фабрике коммутаторы одного производителя и тогда балансировка линков скорее всего будет осуществляться.

Это хорошее правило