Регистрация Войти
Рейтинг:0
avatar Server

Отделение iSCSI от Ethernet через VLAN

флаг in
Ray

Я создал небольшой кластер из нескольких серверов вместе с SAN. На серверах установлена ​​Ubuntu 20.04 LTS.

Используя инструкции, предоставленные поставщиком (я не могу найти, где я читал это раньше), они предложили, чтобы соединения iSCSI между SAN и серверами были (или, может быть, это было «должно быть»?) отделены от любого Ethernet-трафика. По этой причине я настроил на нашем коммутаторе две сети VLAN — одну для трафика iSCSI и одну для трафика Ethernet между серверами (на которых нет SAN).

Пока вроде нормально. Предположим, что Ethernet находится на 172.16.100.XXX/24, а iSCSI — на 172.16.200.XXX/24. В частности, адреса выглядят примерно так:

машина Ethernet iSCSI Вне Ethernet тоже?
сервер 1 172.16.100.1 172.16.200.1 Да
сервер 2 172.16.100.2 172.16.200.2 Да
сервер 3 172.16.100.3 172.16.200.3 Да
САН Н/Д 172.16.200.4 Нет

Не удивительно, что я могу ssh между серверами, использующими любую VLAN. То есть с сервера 2 на сервер 1 я могу сделать любое из следующего:

  • СШ 172.16.100.1
  • СШ 172.16.200.1
  • ssh через видимый снаружи IP-адрес

Что меня беспокоит, так это то, следует ли мне лучше отделить трафик, отличный от iSCSI, от подсети 172.16.200.X с помощью правил брандмауэра, чтобы порт 22 (ssh) был заблокирован на всех серверах.

Меня не беспокоит обратное — SAN находится только в VLAN 200. Он не знает о существовании VLAN 100, поэтому он не будет внезапно отправлять трафик iSCSI в эту VLAN.

Я использую файловую систему Oracle Cluster, которая, кажется, использует порт 7777 - возможно, мне следует заблокировать все порты в VLAN, чтобы использовался только порт 7777? Создает ли трафик Ethernet в сети iSCSI проблемы (задержки или ошибки?), о которых мне следует знать?

Спасибо!

146
0 + 3
Michael Hampton avatar
флаг cz
Michael Hampton
Отвечает ли это на ваш вопрос? [Смешивание трафика SAN iSCSI с трафиком основной сети, я напрашиваюсь на неприятности?](https://serverfault.com/questions/272115/mixing-san-iscsi-traffic-with-core-network-traffic-am-i- напрашивается на неприятности)
0
Ответить
флаг in
Ray
@MichaelHampton Хмммм... не совсем. Похоже, что ответы касаются наличия отдельного физического коммутатора для iSCSI. Или что разделение двух с помощью VLAN будет работать. У нас есть только один коммутатор — я не принимаю решения о покупке другого коммутатора, хотя это было бы неплохо. И я уже использую VLAN. Я предполагаю, что мой вопрос заключается в том, нужно ли мне использовать брандмауэр (например, «ufw») для предотвращения трафика Ethernet в iSCSI VLAN (например, все порты, кроме 7777)? Наоборот не требуется, так как SAN даже не находится в сети Ethernet VLAN.
0
Ответить
joeqwerty avatar
флаг cv
joeqwerty
**Неудивительно, что я могу использовать ssh между серверами, используя любую VLAN.** - Хммм... они подключены к обеим VLAN. Можете ли вы использовать SSH с хоста в VLAN, отличной от iSCSI, на сервер, используя IP-адрес iSCSI VLAN сервера? Запустите сетевую трассировку на одном сервере и подключитесь по ssh к другому серверу, используя его IP-адрес iSCSI в качестве цели вашего сеанса ssh. Какой исходный интерфейс и IP-адрес вашего сеанса ssh?
0
Ответить
флаг in
Ray
@joeqwerty Спасибо за продолжение! Я обновил свой вопрос таблицей, которая (надеюсь) лучше объясняет мою проблему. Я не уверен, поможет ли это... Что такое команда для «сетевой трассировки»? Я не знал, как это сделать...
0
Ответить
Nikita Kipriyanov avatar
флаг za
Nikita Kipriyanov
Я предполагаю, что «сетевая трассировка» — это traceroute, например, «mtr».
0
Ответить
Рейтинг:1
Zac67 avatar Server
флаг ru
Zac67

Что меня беспокоит, так это то, следует ли мне лучше отделить трафик, отличный от iSCSI, от подсети 172.16.200.X с помощью правил брандмауэра, чтобы порт 22 (ssh) был заблокирован на всех серверах.

Если вы используете DNS-имена для подключения к другим серверам, и они разрешаются в адреса локальной сети, все должно быть в порядке. (В качестве альтернативы вы, конечно, можете напрямую использовать IP-адреса локальной сети.)

если ты В самом деле хотите отключить весь не-iSCSI-трафик в SAN, вам нужно либо

  1. настроить все службы для привязки только к IP-адресам локальной сети
  2. использовать локальные брандмауэры на серверах для фильтрации всего нежелательного трафика
  3. используйте ACL на портах коммутатора iSCSI для фильтрации всего нежелательного трафика

Если вы выполняете фильтрацию, правильным подходом будет просто разрешить iSCSI и запретить все остальное.

Создает ли трафик Ethernet в сети iSCSI проблемы (задержки или ошибки?)

Основная причина разделения трафика LAN и SAN заключается в том, что вы хотите убедиться, что ваша сеть хранения данных не засорится ни при каких обстоятельствах. Если бы это было так, это быстро привело бы к ошибкам ввода-вывода, что, в свою очередь, привело бы к потере данных и даже повреждению. (Очень) низкий объем случайного трафика не является поводом для беспокойства.

Однако я бы использовал подход ACL, если привязки служб (№ 1) нецелесообразны или если есть другие администраторы серверов, которые легкомысленно относятся к этому. Например. динамическое обновление DNS очень легко помещает ваши IP-адреса iSCSI в DNS, и любой межсерверный трафик может быстро попасть в SAN.

0 + 0
флаг in
Ray
Спасибо за понятное объяснение! Инструкции поставщика SAN заключались в том, чтобы разделить два трафика, без четкого объяснения, почему. посмотрю, как пойдет дело; если производительность сети ухудшится, я рассмотрю предложенные вами варианты. Спасибо!
0
Ответить
Zac67 avatar
флаг ru
Zac67
@Ray Я предполагаю, что часть этой рекомендации вызвана тем, что коммутаторы, возможно, ограничены в общей пропускной способности, поэтому кадры могут быть отброшены *до того, как* будут достигнуты ограничения на количество каналов. Однако все современные коммутаторы *неблокирующие*, т.е. ограничено только скоростью интерфейса (за исключением большого модульного шасси).
1
Ответить
флаг Moldova
Admin
Этот вопрос на других языках:

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

Большинство людей не понимают, что склонность к познанию нового открывает путь к обучению и улучшает межличностные связи. В исследованиях Элисон, например, хотя люди могли точно вспомнить, сколько вопросов было задано в их разговорах, они не чувствовали интуитивно связи между вопросами и симпатиями. В четырех исследованиях, в которых участники сами участвовали в разговорах или читали стенограммы чужих разговоров, люди, как правило, не осознавали, что задаваемый вопрос повлияет — или повлиял — на уровень дружбы между собеседниками.