Почему трафик iscsi должен быть изолирован?

8

Почему трафик iscsi SAN должен быть изолирован? Я пытаюсь объяснить своему сетевому парню, почему мы должны изолировать трафик.

Джеффри Джаррелс
источник
Пожалуйста, прочитайте techrepublic.com/blog/data-center/…
Энди,
11
Как вы могли бы объяснить это ему, если вы не знаете? Вы выступаете за определенный архитектурный дизайн и реализацию, не зная, почему этот конкретный архитектурный дизайн и реализация важны.
Joeqwerty
1
Нет, я знаю, но это ребята из старой школы, которые просто хотят бросить больше пропускной способности в этом вопросе. Я просто надеялся получить больше информации о том, что я мог бы сказать им, почему и что может произойти, если он не изолирован.
Джеффри Джарреллс

Ответы:

21

Потому что:

  • Очень, очень плохие вещи произойдут, если кто-то получит несанкционированный доступ к вашей сети хранения данных.
  • Очень, очень плохие вещи произойдут, если ваш iSCSI-трафик не будет разделен, и кто-то посчитает отличной идеей обойти топологию STP с помощью граничного коммутатора, в результате чего вся ваша сеть И ваша подсистема хранения будут сразу отключены.
  • Очень, очень плохие вещи произойдут, если проектирование сети iSCSI не будет выполнено тщательно. Хранение его в изолированных VLAN усложняет выполнение глупых действий, таких как попытка передачи трафика iSCSI через маршрутизатор или брандмауэр (в сети iSCSI не должно быть маршрутизаторов или брандмауэров).
  • Очень, очень плохие вещи произойдут, если ваш администратор хранилища / виртуализации хочет внедрить гигантские кадры, а сетевой администратор не хочет внедрять гигантские кадры. Хранение iSCSI на выделенных коммутаторах предотвратит это. Даже совместное использование коммутаторов с обычным сетевым трафиком предотвратит несоответствие MTU, так как вы будете увеличивать MTU только на коммутаторах с трафиком iSCSI, а не на подключенных коммутаторах.

Я мог бы перечислить больше причин, но я думаю, что этого достаточно, чтобы понять. Не смешивайте трафик iSCSI с любым другим типом трафика на тех же портах. Если у вас есть приличные коммутаторы, тогда идите вперед и поделитесь коммутационной матрицей с другим трафиком, но сохраняйте iSCSI на отдельных портах в отдельных VLAN.

pauska
источник
1
Не говоря уже о производительности, производительности и .... производительности.
Symcbean
Итак, подведем итог, произойдут очень и очень плохие вещи: P.
TMH
6

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

Chopper3
источник
Это аргумент в пользу QoS. Вы также поспорите в пользу изоляции трафика VoIP?
MSalters
Таким образом, вам не нужно QoS, обычно оно имеет латентную стоимость
Chopper3
Это сделано специально - QoS позволяет не чувствительным ко времени данным ожидать более срочные данные, такие как трафик iSCSI.
MSalters
1

Вы не хотите, чтобы побочные эффекты от трафика нарушали ваш доступ к SAN. У нас есть небольшая среда VMWare VSphere, в которой сначала трафик VMotion и iSCSI проходил через одни и те же коммутаторы в одной сети. Различные сетевые адаптеры, но одна и та же сеть. Ошибка в ESXi 5.0 приводила к тому, что хосты случайным образом теряли доступ к iSCSI SAN всякий раз, когда было активным более длительное действие VMotion, в котором использовалось более 1 сетевого адаптера. В зависимости от решения SAN и используемых клиентов iSCSI можно ожидать всевозможных забавных действий при смешивании трафика. Конечно, он может работать и без проблем, но это обычно длится только до того дня, когда ваши коллеги уезжают в отпуск, и вдруг весь ад разваливается.

Другая проблема, когда у вас есть системы iSCSI SAN в сети по умолчанию: кто-то может использовать IP-адрес, назначенный вашему узлу SAN. Скорее всего, это не произойдет случайно, но кто-то, пытающийся причинить вам или компании неприятности, может сканировать вашу сеть, обнаружить SAN и использовать любое устройство с IP-поддержкой, чтобы ваша SAN волшебным образом исчезла.

Дирк Трилсбек
источник