Ethernet Storage

“Ethernet storage” принято называть все системы хранения, использующие ethernet для передачи данных. Это могут быть NFS или CIFS NAS, а также iSCSI или FCoE SAN.

??спользование Ethernet как среды передачи данных систем хранения становится все популярнее, однако задачи создания “сети хранения данных” с использованием ethernet предъявляют особые требования к стабильности и надежности работы сети. То что “прокатит” для раздачи интернета в офисе может “не прокатить” при создании сети IP-SAN или NFS для критически важных для бизнеса задач.

Если перед вами стоит задача организации такой сети передачи данных, хочу обратит ваше внимание на свежий перевод в библиотеке Netwell: TR-3802 Ethernet Storage Best Practices.

Как организовывать и настраивать транкинг VLAN? Как работает и чем полезен протокол Spanning Tree? Что такое, и как работает VIF – Virtual Interfaces в NetApp? Чем отличаются Single mode и Multi-mode VIF? Static и Dynamic Multimode VIF? Почему объединенные в etherchannel (ethernet-транкинг) порты могут не давать ожидаемой от этого объединения увеличения полосы пропускания? Как работают Jumbo Frames и Flow Control на уровне Ethernet, и как правильно его применять?

Все это в исключительно полезном документе техбиблиотеки NetApp доступном теперь и на русском языке:

TR-3802 Ethernet Storage Best Practices.

PS. Кстати может быть полезен и не только пользователям NetApp.

Комментарии (2)

  1. Korj:

    Бриджи (англ. breeches или britches) — короткие брюки до колен, плотно охватывающие ноги; узкие, длинные шорты.

    ethernet bridge всю жизнь переводился как “мост”.

    “Внимание: Если на коммутаторе сконфигурировано 100 VLAN, то STP - протокол для каждого из 100 VLAN построит отдельное дерево.”
    Понимаю, что так и в оригинале, но в общем случае неверно. Верно только для относительно новой техники с поддержкой MSTP, не считая проприетарных протоколов.

    “Появление в сети меньшего MAC-адреса приводит к полному перестроению дерева STP!”
    Оригинал вообще неудобочитаем, перевод логичнее, но я б написал “Появление в сети _коммутатора_ с меньшим MAC-адресом…”

    “Существует много методов соединения коммутаторов…”
    Там не зря стояло слово “modern” - он пишет только про _современные_ коммутаторы, для xUSSR это ещё более важно - “современность” коммутаторов у нас местами может быть ниже, следовательно ещё больше вероятность встретить топологию без MSTP/PVST.

    “Несколько кабелей, соединяющих порты, сконфигурированные в один VLAN с Etherchannel”
    Стоит использовать стандартное (IEEE 802.1AX-2008) обозначение - агрегация. В оригинале автор использует жаргонное слово “bonding” и проприетарное Etherchannel, у вас ещё хуже - только проприетарное. Также логически неверно писать “в один VLAN с Etherchannel”.
    Предлагаю “Несколько кабелей, соединяющих порты, агрегированные в Etherchannel с одним VLAN”.

    “Смотри главу 4 о работе port bonding.”
    В главе 4(и вообще больше нигде) жаргонное слово “bonding” не встречается, предлагаю заменить на “о работе агрегации портов”.

    Раздел 3.4 вообще можно озаглавить “плевали мы на стандарты, вы посмотрите, какие фичи у нашего партнёра есть!”. Описание проприетарных протоколов и “забывание” о стандартных (в частности MSTP) - это узкий кругозор автора или всё же реклама?

    По всей главе 4 я бы рекомендовал заменить общие слова “объединение” и “связывание” на стандартизированное “агрегация” или хотя бы добавить этот стандартный термин в начало списка жаргонизмов.

    Про trunking в главе 4 автор слишком смело пишет, мол первым был VLAN. Я не уверен. Термин для связистов родной и использовать в Ethernet его стали в общем виде для обозначения магистральных линий. Одни производители, которые специально различали тип порта для VLAN, обозвали trunk-ом порт с несколькими тегироваными VLAN, другие этот термин использовали для своих проприетарных агрегаций каналов. Победила(?) терминология CISCO, но так и нужно писать - исторически использовалось так-то, но во избежание путаницы бла-бла-бла.
    Тот же стандарт 802.1Q использует слово trunk как раз в бытовом значении - магистраль, нигде он как термин не вводится. Авторы опять слишком зациклены на CISCO.

    “Доступны несколько вариантов алгоритма балансировки нагрузки со стороны NetApp FAS, например:
    · По IP-хэшу ??сточника и Получателя.
    · По хэшу MAC-адреса ??сточника и Получателя.
    · Round Robin.”
    Я не знаю, насколько допустимо исправлять при переводе, но оригинал устарел, появился четвёртый тип - Port based.

    “Static mode работает в «принудительном» режиме, без контроля соединения, что может быть результатом проблем типа «черная дыра трафика», о которой мы упоминали ранее.”
    Оригинал трижды ссылается на “black hole” - “см. выше”, а выше ничего и нет. Стоит, возможно, убрать “о которой мы упоминали ранее” - пусть читатель сам гадает. Хотя неплохо бы указать, что проблема может появиться не сама собой, а при неправильной конфигурации. Согласитесь, одно дело пугать пользователя страшными словами, а другое - указать на возможные нюансы конкурирования. Неправильно сконфигурированный коммутатор что угодно вытворять может, что ж теперь вообще ни одной функцией не пользоваться?
    Да, и по-русски всё же будет не “что может быть результатом проблем”, а “результатом чего могут быть проблемы” - принципиальная ошибка, мне кажется.

    “Режим Dynamic multi-mode VIF основан на использовании Link Aggregation Control Protocol (LACP) описанного в стандарте IEEE 802.ad (dynamic).”
    802._3_ad, а если быть точным, то с 2008 года это уже стандарт IEEE 802.1AX-2008.

    В “Против” 4.3 я б добавил, что в NetApp LACP кривой и работает не со всей стандартной техникой. С CISCO работает, а ничего больше у Trey Layton в подвале нет. :)))

    Пока всё. Пардон, что большая часть, наверное, не к переводу, а к самому тексту, но может тут кто прочтёт и пользу извлечёт.

  2. Korj:

    Продолжу. :)
    Глава 2.
    “Однако разделение широковещательных доменов обычно требует физического разделения сетевого оборудования и выделенных портов на больших маршрутизаторах.”
    Это экскурс в историю - там прошедшее время => “требовало”, а не “требует”.
    ?? весь дальнейший абзац тоже в прошедшее время надо перевести.

    “В середине 90-х скорости сети начали расти, и технология маршрутизации между широковещательными доменами появилась и в самих коммутаторах. Такие коммутаторы стали называть «layer 3 switches» и они имеют возможность изолировать порт в его собственном домене коллизий, одновременно позволяя администратору назначить этот порт в тот или иной широковещательный домен, то есть обеспечивая некоторые возможности маршрутизации между широковещательными доменами в единой сети. ”
    Смысловая ошибка перевода. Не “то есть”, а “а также”. Одно из другого не вытекает, это разные функции. В оригинале “while also”.

    “Позволив различным отдельным логическим устройствам жить в одном и том же физическом коммутаторе мы устраняем необходимость выделять отдельным сетям их собственные коммутаторы.”
    По-русски всё же “жить” не очень литературно. Я бы как-то так написал: “Включив различные отдельные логические устройства в состав одного и того же физического коммутатора…”.

    “Более емкие, более эффективные и мощные коммутаторы могут быть использованы в сетевой инфраструктуре для агрегирования устройств.”
    Во избежание путаницы термин “агрегирование” тут не нужен. “В качестве совмещенных устройств могут выступать более эффективные коммутаторы с большей плотностью портов.”
    Тут не имеется в виду “мощность” - в рамках одной линейки коммутаторы разной плотности редко отличаются тем, что можно назвать “мощностью”. Тут именно плотность и эффективность по цене и RU.

    “сетевой администратор может логически назначать устройства коммутатору и сетям, непосредственно с консоли управления коммутатора.”
    неверный перевод. “сетевой администратор может логически перемещать устройства между сетями, непосредственно с консоли управления коммутатора.”

    2.1 “Стандарт IEEE 802.1q предлагает решение такой проблемы”
    802.1_Q_

Оставить комментарий