Только один клиент привязан к адресу и порту: имеет ли значение широковещательная рассылка по сравнению с одноадресной передачей с точки зрения накладных расходов?
Сценарий:
Я реализую отказоустойчивость для сетевого узла, поэтому моя идея заключается в том, чтобы главный узел прослушивал широковещательный IP-адрес и порт. В случае сбоя главного узла другой отказоустойчивый узел начнет прослушивать этот широковещательный адрес (и порт) и вступит во владение.
Вопрос:
Меня беспокоит то, что я буду использовать широковещательный IP-адрес только для одного узла: мастера. Отказоустойчивый узел связывается, только если мастер отказывает, другими словами, почти никогда.
С точки зрения затрат на сеть / трафик, плохо ли разговаривать с одним узлом через широковещательный адрес или сеть достаточно умна, чтобы знать, что никто не слушает этот широковещательный адрес, и воспринимать его как одноадресный с точки зрения накладные расходы?
Меня беспокоит то, что я буду наводнять свою сеть пакетами с этого широковещательного адреса, даже если подумал, что просто общаюсь с одним узлом (ведущим). Но я не могу использовать одноадресную передачу, потому что отказоустойчивый узел должен иметь возможность быстро и прозрачно выбрать главный поток в случае сбоя.
4 ответа
Как правило, сеть не может заранее предсказать или немедленно узнать о сбое узла.
Следовательно, вы должны либо:
- принять, что это всегда займет небольшое время, чтобы обнаружить сбой и перейти на отказоустойчивый узел
- превентивно отправлять трафик на резервный узел, теряя эффективность сети
Надежный обмен сообщениями на сетевом уровне сложно и дорого реализовать. Вот почему мы используем тупые сети с коммутацией пакетов и реализуем надежность на транспортном уровне. Это сценарий, в котором вы используете плавающий IP-адрес (и, возможно, MAC-адрес) и ожидаете обновления (таблицы переадресации кэша / коммутатора шлюза).
Но если так важно, чтобы вы никогда не пропускали ни одного пакета, вам придется заплатить некоторую эффективность. Если вы используете многоадресные (не широковещательные) адреса и ваши избыточные пути проходят через коммутаторы, способные к отслеживанию IGMP, то они должны быть достаточно умными, чтобы, по крайней мере, не заполнить всю вашу локальную сеть. Вам все еще нужен способ для вашего резервного узла надежно обнаружить сбой главного устройства.
Если вы используете потоки, вместо использования собственного специального надежного протокола поверх многоадресного udp, вы можете захотеть взглянуть на SCTP, так как он обрабатывает множественную адресацию и может выгодно заменить udp или tcp.
Похоже, вы пытаетесь заново изобрести объединение / кластеризацию сетевых карт по-своему. Большинство активных / пассивных кластеров будут совместно использовать виртуальный IP-адрес и MAC-адрес, и при сбое одного из устройств вторичный узел принимает общий MAC-адрес. Использование широковещательного IP-адреса для связи с кластером неортодоксально и почти наверняка создаст ненужный трафик в локальной сети.
Да, вещание имеет накладные расходы. Чем больше узлов вы подключили к коммутатору, тем больше накладных расходов. Поэтому отправлять широковещательную рассылку следует только тогда, когда вы действительно хотите достичь всех узлов и / или когда вы пытаетесь обнаружить узел, который переместился в другое место. Передайте один раз, дождитесь ответа от узла, где бы он ни находился, найдите его новый адрес и с этого момента одноадресный. Красиво, не правда ли?:)
Заполняете ли вы свою сеть, полностью зависит от частоты и размера широковещательных сообщений, размера подсети, в которую вы вещаете, топологии вашей сети и возможностей вашего оборудования.
Не зная, что никто не может точно ответить на ваш вопрос.
Тем не менее, DHCP является широковещательным трафиком, и в большой сети может быть довольно болтливым. Многие сети не будут предпринимать никаких специальных действий для управления этим DHCP-трафиком - это не проблема. Оцените, будет ли ваша широковещательная передача значительно превышать существующий широковещательный DHCP-трафик в вашей сети - если это так, то, возможно, вам придется беспокоиться и найти другое решение для любой проблемы, с которой вы столкнулись. Если нет, то, скорее всего, вы можете перейти к следующему вызову.
Я заинтригован тем, для чего конкретно вы пытаетесь настроить аварийное переключение. Как полагают другие респонденты, существует множество вариантов резервирования, которые вы можете использовать, когда вам не придется об этом беспокоиться, и вы можете использовать опыт других людей.