Мы хотим реализовать iSCSI SAN, и все наши тесты показали, что мы можем реализовать это довольно дешево (цель Starwind, восстановленный массив HP Storage).
Что меня беспокоит, так это пропускная способность / задержка самого коммутатора, поэтому открытые вопросы:
Спасибо,
Рик.
Я полностью согласен с ответом Ингулдина - по большей части любой современный коммутатор, предназначенный для использования в серверной комнате / центре обработки данных, должен быть более чем достаточно хорош для ваших нужд, и поддержание согласованности в вашей среде, вероятно, будет более важным для вас от перспектива поддержки \ управляемости.
Тем не менее, если вы действительно хотите получить максимальную отдачу от настройки iSCSI, используйте переключатели, которые имеют:
Достаточно буферной памяти на порт. В идеале что-то> 512k на порт, но здесь есть компромисс. Некоторые коммутаторы используют большие буферы, чтобы замаскировать низкую скорость переключения, поэтому вам нужно искать больше, чем это. Слишком мало буферной памяти приведет к потере пакетов при большой нагрузке, и уровень TCP будет вынужден повторно отправлять пакеты, что значительно замедлит работу.
Достаточная способность обработки на порт. Это может быть сложно установить - лучший показатель для поиска - это скорость переключения. Коммутатор со скоростью переключения 100 микросекунд может обрабатывать только 10 тыс. Пакетов / сек, которые не смогут переключать GigE на линейной скорости, коммутатор со скоростью переключения 3 микросекунды может (теоретически) обрабатывать до 300 тыс пакетов / сек, и это нормально. Все, что ниже 12 микросекунд, будет достаточно. Быстрее - лучше, но цены растут довольно резко, поскольку это число сводится к низким однозначным цифрам.
Поддержка аппаратного управления потоком (802.3x). Это будет бесполезно, если сетевые адаптеры и массив вашего сервера также не поддерживают это, но если они это сделают, это позволит вашей сети iSCSI более эффективно обрабатывать управление потоком на уровне 2, а не полагаться на управление перегрузкой более высокого уровня, такое как алгоритмы предотвращения перегрузки TCP, которые будет значительно менее эффективным. Тем не менее, сегодня сложно найти подходящий коммутатор, который не поддерживает его.
Поддержка Jumbo-кадров. Опять же, это будет полезно только в том случае, если ваш массив iSCSI, серверное оборудование и ОС также поддерживают jumbo-кадры. На самом базовом уровне Jumbo-кадры уменьшают накладные расходы протокола и могут увеличить пропускную способность на 10-20%, но этот выигрыш в значительной степени зависит от шаблонов трафика. Для расширенной передачи данных с высокой пропускной способностью 9k Jumbo-фреймов также снизят нагрузку на ЦП на вашем массиве, серверах (и коммутаторе) до 80%. Это может быть, а может и не быть значительным в вашей среде, поскольку начальная нагрузка на ЦП может быть относительно низкой. Коммутаторы начального уровня иногда заявляют о поддержке Jumbo-кадров, но не поддерживают Jumbo-кадры 9k, что является общепринятым оптимальным размером для GigE, поэтому сначала проверьте это. Если ваш массив не поддерживает Jumbo-кадры, очевидно, не о чем беспокоиться.
Возможность коммутации и стекирования с высокой пропускной способностью. Для GigE вы должны стремиться к скорости> 1 Гбит / с на порт, в идеале 2 Гбит / с для обработки полнодуплексного трафика на линейной скорости через все порты. Для коммутатора с 24 портами вы хотите, чтобы он имел возможность переключать 48 Гбит / с внутри и иметь возможность стекирования \ восходящего соединения на значительном проценте от этого, если вы используете несколько коммутаторов. Для некоторых архитектур iSCSI (например, HP Lefthand и Dell Equallogic) вам необходимо поддерживать трафик с очень высокой пропускной способностью между всеми портами на всех массивах, и общая скорость коммутации становится очень важной. Для коммутаторов, поддерживающих смешанные 1GigE и 10GigE, отрегулируйте соответственно общую полосу пропускания коммутации, которая должна охватывать все порты, работающие на полной скорости в полнодуплексном режиме.
Spannning Tree. Вы хотите иметь возможность полностью отключить его, если ваша среда iSCSI достаточно проста и изолирована от всего остального или если она поддерживает Rapid Spanning Tree \ Port Fast \ Edge Ports, где вы можете выборочно отключить поведение полного связующего дерева на определенных портах.
GigE - это старая и стабильная технология, и вычислительной мощности современных коммутаторов достаточно, чтобы справиться с ней очень легко, особенно когда это всего лишь одна цель и несколько инициаторов. Вы должны ожидать, что любой приличный коммутатор (за исключением, конечно, за исключением маленьких коробочек-разработчиков-разработчиков за 20 долларов), не будет иметь проблем с синхронизацией или производительностью в среде SAN. Соответствующие наборы функций также практически одинаковы для всех из них, включая jumbo-кадры, управление потоком, VLAN и все остальное, что может вам понадобиться.
Вместо этого вам следует сосредоточиться на бюджете, существующих отношениях с поставщиками, установленном оборудовании и внутреннем опыте: получить то, что вы можете себе позволить и что знаете лучше всего, и придерживаться того же бренда, который вы уже используете (две причины: меньше руководств для чтения означает более глубокое знание того, что у вас есть, и вы избежите проблем с совместимостью). Cisco, ProCurve, Nortel, Netgear высокого класса - все должно быть хорошо.
iSCSI - это такой же протокол, как и любой другой; основная проблема, на которую следует обратить внимание, заключается в том, что вам, вероятно, нужен переключатель, который правильно поддерживает Jumbo Frames.