Добрый!
Купили несколько серверов на удалённом хостинге, в каждом сервере две сетевые карты, одна карта смотрит в общий свич (гигабитный), другая карта каждого сервера смотрит в интернет, и на неё выделяется два белых адреса.
Внутри серверов Hyper-V и windows сеть. Веб сервера, РДП хостинг и тыды. Много всего.
Подскажите как правильно организовать сеть чтобы:
1. Каждая виртуалка могла мигрировать по железным хостам сохраняя по возможности свой ip
2. Каждую виртуалку можно было выставить наружу через любой внешний адрес
3. С любого внешнего адреса была доступна любая виртуальная машина, даже после миграции на другой хост.
Сейчас каждый хост содержит свой маршрутизатор, на него приземляются адреса и он же является NAT. Но в машинах приходится принудительно указывать один их нескольких шлюзов по умолчанию - тот с которого конкретная виртуалка выставлена, это сильно мешает балансировать нагрузку или делать HA.
Повторюсь, основная сложность в том, что сейчас в сети нет единого шлюза по умолчанию и я не понимаю как его можно создать, при том что реальных выходов в интернет несколько.
Коллеги, огромное всем спасибо, за мысли и советы.
Решилось всё так:
1. Вначале я поднял на CentOS на каждой железяке Бриджы между физикой и EoIP туннелем.
2. Приземлил все EoIP туннели на одну машину, и уже от неё отдал VLAN'ами внутрь одного маршрутизатора. VLAN между железками блокирвоал хостер, потому только так.
3. Это в принципе заработало, но что то сломало у хостера, потому он сделал мне общий свич на все внешние интерфейсы на своём уровне
4. Потому я смог приземлить внешние адреса на любое железо и в итоге выкинуть всю эту ахинею и сделать правильно =)
Итого у меня один (плюс реплика) шлюз, несколько внешних IP и плоская сеть =)
В Hyper-V не силен (мерзкий гипервизор), на других гипервизорах можно настроить так:
1) Все гипервизоры через второй сетевой интерфейс объединяем в кластер, миграция виртуалок также будет по этому интерфейсу. - решаем вашу 1 задачу.
2) В качестве интерфейса для виртуалок используем бридж на сетевую гипервизора, а не нат - решаем вашу вторую и третью задачу, так виртуалка с любого из гипервизоров сможет сохранять свой адрес.
К сачатью в этом мерзком (и если бы не проблемы с совместимостью его бы использовать не пришлось бы, но) гипервизаре есть миграция без обьединения в кластер.
А вот сам кластер без внешнего хранилища не собрать.
Сейчас я построил плоскую сеть и все виртуалки внутри неё имеют одну адресацию, так же есть три шлюза, способных пускать наружу или натить трафик внутрь - в этом варианте нет проблем с натом и выставлением наружу, нет проблем с миграцией по хостам, но есть проблемы с тем что шлюз по умолчанию - это всегда одна виртуалка, на конкретном хосте и если она "ляжет" нужно перевыдать адреса или переназначить шлюз по-умолчанию, чтобы трафик продолжал ходить.
Еще раз повторюсь, вам не нужен NAT и шлюзом должен выступать НЕ гипервизор, а внешний маршрутизатор (тот, который прописан шлюзом у самих гипервизоров) в самих гипервизорах нужен бридж. Тогда на каком бы гипервизоре не работала виртуалка шлюз будет один и тот-же.
openvswitch в качестве бриджа и разнесение по vlan c приземлением на vlan интерфейсы маршрутизатора
как вариант VMDq для виртуалок www.intel.com/support/ru/network/sb/cs-030993.htm
маршрутизаторы можно зарезервировать по VRRP
