В настоящее время мы используем только состояние связи для наших команд сетевых адаптеров на наших хостах виртуальных машин, но недавно столкнулись с проблемой, когда один из наших двух коммутаторов имел ошибку памяти и перестал передавать трафик. Все наши виртуальные машины вышли из строя, и большинство гостей (которые уже использовали этот путь) также перестали отвечать, пока мы не отключили этот переключатель вручную.
В среде связывания Linux вы можете использовать arp_intervals как еще один способ определения статуса соединения, но в VMWare есть только Beacon Probing. BP - это не то же самое, что arp_interval в том, что вы не выбираете хост для проверки подключения, а также вам нужны три или более интерфейса для этого.
Все наши хосты виртуальных машин имеют четыре сетевых адаптера, поэтому выполнение трех требований не должно вызывать особых проблем. Однако, хотя в документации указано только, что требуются как минимум три отдельных физических сетевых адаптера (pNIC), в каждом примере также есть три отдельных физических переключателя, и в нем не указано, является ли это также требованием. Когда я искал ответ на этот вопрос, я наткнулся на этот блог, в котором говорится:
«Не используйте Beacon Probing, если более одного pNIC в vSwitch подключено к одному pSwitch. Это может привести к тому, что один и тот же MAC-адрес будет представлен на двух или более портах на pSwitch, что является« очень плохой вещью »».
У нас нет трех переключателей в нашей конфигурации, чтобы просто добавить к этой проблеме, и в некоторых из моих предварительных тестов у меня были необъяснимые проблемы с переключением каналов, которые могут быть связаны с их подключением к одному и тому же переключателю.
Так необходимы ли три отдельных физических переключателя для зондирования маяка? Могу ли я получить статус ссылки только для моей конфигурации? И, наполовину риторически, почему у них нет опции arp_interval в их команде NIC?
При зондировании маяка рекомендуется использовать не менее 3 pNIC, потому что именно так маяк работает лучше всего. ESXi отправляет широковещательный пакет из физических карт NIC. Затем другие pNIC в том же vSwitch ждут, чтобы увидеть, получат ли они пакеты от других pNIC. Какой бы pNIC не получил широковещательную рассылку, ESXi предполагает, что это нисходящий канал.
Прикрепление всех 3 pNIC к одному коммутатору и использование зондирующего маяка - пустая трата ресурсов, если статус канала будет работать, потому что это проще. Ссылка включена или отключена? Проблемы конфигурации (STP или блоки портов) не отображаются в статусе соединения.
Целью и разработкой зондирующего радиомаяка было подключение pNIC к разным pSwitches, поскольку он использовался для «тестирования» нисходящих коммутаторов; переключатели помимо тех, к которым были подключены pNIC. BP может определить, если, скажем, третий pSwitch, находящийся ниже по течению к iSCSI SAN, вышел из строя, статус соединения не обнаружит этого, но BP должен. Затем сервер ESXi может определить, что он хочет делать. Статус канала будет продолжать попытки отправки пакетов в SAN, даже если он недоступен.