Поскольку у меня задача схожая, позвольте несколько вопросов:
Зачем нужна коммутация с рабочими станциями по FC? Ведь реально потоки с-на каждую станцию не будут больше 300 Mbitps - простая гигабитка легко потянет. Сегодня на сколько мне известно, существуют коммутаторы Gigabit ethernet с портами FC для сервера - чем плохо такое решение? Что реально дает SAN для подобных целей? - я понимаю, что лет пять назад альтернативы просто не было и в данном конкретном случае замена FC коммутатора может быть дешевле, чем сервер с FC адаптором + соответствующий коммутатор, но стоит ли новую систему собирать с аналогичной архитектурой?
SAN для видео
Модераторы: Trinity admin`s, Free-lance moderator`s
А вариант, когда массив соединяется по файберу с сервером (по файберу - чтобы в случае нужды можно было второй сервер подсоединить), а все рабочие станции через обычный гигабитый коммутатор - к серверу (2 - 4 Гбитных порта в транке)? Понятно, что больше 8 - 10 станций сервер не обслужит, но больше и не нужно.
Насчет отличия FibreChannel и Gigabit Ethernet. Разница здесь в самой технологии.
FibreChannel представляет собой коммутируемое кольцо, где за очередность передачи станций отвечает маркер, который бегает по кругу. И при возрастании сетевой нагрузки скорость падает равномерно на всех станциях, линейно.
Технология Ethernet предусматривает возможность коллизий, когда в случае одновременной передачи несколько станций делается пауза, а потом случайным образом передачу начинает одна станция, затем другая. Падение скорости в этом случае, нелинейное, для передачи файлов это не критично, и при небольших потоках тоже, буфферизация спасает.
Но при возрастании нагрузки, падение скорости ниже необходимой для передачи кадра видеосигнала, допустим, PAL 720х576, 25 к/сек, размером зависящим от используемой компрессии, пусть даже мгновенное, вызывает выпадение кадра, в случае прямого эфира - это брак в эфире, если используются специализированные платы видеомонтажа, они очень не любят такие проблемы и не всегда их корректно обрабатывают.
Мое мнение - Gigabit Ethernet можно использовать в случае достаточного запаса по скорости и при корректной программной обработке вышеуказанных проблем. Кстати, кто какую реальную скорость по меди получал ?
P.S. Я все еще жду результатов тестирования
FibreChannel представляет собой коммутируемое кольцо, где за очередность передачи станций отвечает маркер, который бегает по кругу. И при возрастании сетевой нагрузки скорость падает равномерно на всех станциях, линейно.
Технология Ethernet предусматривает возможность коллизий, когда в случае одновременной передачи несколько станций делается пауза, а потом случайным образом передачу начинает одна станция, затем другая. Падение скорости в этом случае, нелинейное, для передачи файлов это не критично, и при небольших потоках тоже, буфферизация спасает.
Но при возрастании нагрузки, падение скорости ниже необходимой для передачи кадра видеосигнала, допустим, PAL 720х576, 25 к/сек, размером зависящим от используемой компрессии, пусть даже мгновенное, вызывает выпадение кадра, в случае прямого эфира - это брак в эфире, если используются специализированные платы видеомонтажа, они очень не любят такие проблемы и не всегда их корректно обрабатывают.
Мое мнение - Gigabit Ethernet можно использовать в случае достаточного запаса по скорости и при корректной программной обработке вышеуказанных проблем. Кстати, кто какую реальную скорость по меди получал ?
P.S. Я все еще жду результатов тестирования
Сейчас для FC в основном используют коммутаторы (FC-SW). Там нет кольца. Только внутри дисковго массива и то сейчас все вендоры потихоньку двигаются к коммутаторам внутри полок.St писал(а):FibreChannel представляет собой коммутируемое кольцо,
10+ лет технология Ethernet работает через коммутаторы в полнодуплексном режиме. Коллизий там быть не может.Технология Ethernet предусматривает возможность коллизий,
Для gigabit ethernet вообще, AFAIK, возможно только коммутируемые топологии и коллизий там быть не может в принципе.
около сотни МБ/с на Lustre с несколькими 2x Opteron серверами, Cat2960 и джамбо-фреймами.Кстати, кто какую реальную скорость по меди получал ?
Что по-вашему, тогда обозначает выражение public-loop connectivity в описаниях FC коммутаторов ?Сейчас для FC в основном используют коммутаторы (FC-SW). Там нет кольца. Только внутри дисковго массива и то сейчас все вендоры потихоньку двигаются к коммутаторам внутри полок.
Да, при соединении многие со многими коммутация спасает. А как при соединении 1 сервер - куча клиентов ?Для gigabit ethernet вообще, AFAIK, возможно только коммутируемые топологии и коллизий там быть не может в принципе.
Возможность подключения унаследованных устройств, которые кроме FC-AL ничего не умеют. Точно также как поддержка FICON в некоторых коммутаторах вовсе не значит, что они умеют симулировать ридеры перфокарт ;)St писал(а): Что по-вашему, тогда обозначает выражение public-loop connectivity в описаниях FC коммутаторов ?
С точки зрения Ethernet сервер ничем не отличается от клиента.Да, при соединении многие со многими коммутация спасает. А как при соединении 1 сервер - куча клиентов ?Для gigabit ethernet вообще, AFAIK, возможно только коммутируемые топологии и коллизий там быть не может в принципе.
В таком случае switch буферизирует данные, но как только буфер заканчивается, он новые просто откидываетДа, при соединении многие со многими коммутация спасает. А как при соединении 1 сервер - куча клиентов ?
Это конечно с натяжкой можно назвать коллизией (данные то надо будет перепослать), но это совсем не та коллизия которая была изначально в шинном ethernet (на коаксиале) и которую Вы описали. Никто отправителя не уведомляет о том что получатель данные не получил (на уровне ethernet - данные switch-у доставлены, коллизий нет).
Кто сейчас на конференции
Сейчас этот форум просматривают: нет зарегистрированных пользователей и 3 гостя