Назад | Перейти на главную страницу

Только один клиент привязан к адресу и порту: имеет ли это значение для широковещательной и одноадресной передачи с точки зрения накладных расходов?

Сценарий:

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

Вопрос:

Меня беспокоит то, что я буду использовать широковещательный IP-адрес только для одного узла: мастера. Узел аварийного переключения привязывается только в случае сбоя мастера, другими словами, почти никогда.

Что касается накладных расходов на сеть / трафик, плохо ли разговаривать с не замужем node через широковещательный адрес или сеть каким-то образом достаточно умен, чтобы знать, что никто другой не слушает этот широковещательный адрес, и рассматривает его как одноадресный с точки зрения накладных расходов?

Меня беспокоит то, что я буду наводнять свою сеть пакетами с этого широковещательного адреса, даже если я действительно говорю с одним узлом (главным). Но я не могу использовать одноадресную рассылку, потому что отказоустойчивый узел должен иметь возможность быстро и прозрачно получать главный поток в случае сбоя.

Как правило, сеть не может заранее предсказать или сразу узнать об отказе узла.

Следовательно, вы должны либо:

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

Надежный обмен сообщениями на сетевом уровне сложно и дорого реализовать. Вот почему мы используем простые сети с коммутацией пакетов и обеспечиваем надежность на транспортном уровне. Это сценарий, в котором вы используете плавающий IP-адрес (и, возможно, MAC) и ждете обновления (кэш ARP шлюза / таблицы пересылки коммутаторов).

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

Если вы используете потоки, вместо того, чтобы использовать свой собственный специальный надежный протокол поверх многоадресного udp, вы можете изучить SCTP поскольку он поддерживает множественную адресацию и может успешно заменить udp или tcp.

Похоже, вы пытаетесь заново изобрести объединение / кластеризацию сетевых адаптеров по-своему. Большинство активных / пассивных кластеров будут совместно использовать виртуальный IP-адрес и MAC-адрес, а при выходе из строя одного из блоков вторичный принимает общий MAC-адрес. Использование широковещательного IP-адреса для связи с кластером является необычным и почти наверняка создаст ненужный трафик по всей локальной сети.

Да, у вещания есть накладные расходы. Чем больше узлов вы подключили к коммутатору, тем больше у вас накладных расходов. Таким образом, вы должны отправлять широковещательную рассылку только тогда, когда вы действительно хотите достичь всех узлов и / или когда вы пытаетесь обнаружить узел, который переместился в другое место. Передайте один раз, дождитесь ответа от узла, где бы он ни находился, узнайте его новый адрес и с этого момента выполните одноадресную передачу. Красиво, правда? :)

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

Не зная, что никто не может ответить на ваш вопрос точно.

Однако DHCP - это широковещательный трафик, и в большой сети он может быть довольно разговорчивым. Многие сети не предпринимают никаких специальных действий для управления этим трафиком DHCP - это не проблема. Оцените, будет ли ваша широковещательная передача значительно больше, чем существующий широковещательный трафик DHCP в вашей сети - если да, то, возможно, вам нужно побеспокоиться и реализовать другое решение любой проблемы, с которой вы столкнулись. Если нет, то, скорее всего, вы сможете перейти к следующему испытанию.

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