Pull to refresh

Comments 13

В статье написана каша.
Но для того, чтоб контейнер был доступен из сети, следует использовать адреса из той же IP сети, к которой подключён физический сервер (HN).


Если корректно настроено proxy_arp, то маршрутизаторы прекрасно видят IP внутри виртуалок.
При миграции с одной ноду на другую, траффик какое-то время будет ходить через старую ноду, а потом, когда MAC исчезнет из ARP-cache — через новую ноду.

Использовать OSPF нужно только в очень специфичных случаях использования контейнеров.
> Если корректно настроено proxy_arp, то маршрутизаторы прекрасно видят IP внутри виртуалок.

а если, адрес контейнера из другой подсети (не совпадающей с IP сетями на интерфейсах хоста),
откуда маршрутизаторы узнают, что контейнер на этом сервере?
статику на роутере прописывать?

>При миграции с одной ноду на другую, траффик какое-то время будет ходить через старую ноду, а потом, когда MAC исчезнет из ARP-cache — через новую ноду.

это если ноды в одном сегменте, а если в разных?
а если, адрес контейнера из другой подсети (не совпадающей с IP сетями на интерфейсах хоста),
откуда маршрутизаторы узнают, что контейнер на этом сервере?
статику на роутере прописывать?

Почитайте, что такое proxy_arp и как работать с MAC адресами.

это если ноды в одном сегменте, а если в разных?

Ноды в кластеры используют multicast для обмена информацией.
Если они не обмениваются мультикастом, тогда это ноды разных кластеров.

У меня перед глазами работающие ноды, они прекрасно обходятся без OSPF.
Почитайте, что такое proxy_arp и как работать с MAC адресами.

всегда думал что знаю… но вдруг?
объясните, если сервер соеденён с маршрутизатором через сеть 192.168.1.0/24, на нём крутится контейнер с адресом 100.10.10.10,
и вот компьютер с адресом 172.0.0.1, подключённый к другому интерфейсу маршрутизатора (или вообще из интернета), хочет обратится к контейнеру. В каком месте будет proxy_arp, если явного маршрута к 100.10.10.10 через 192.168.1.0 не прописано нигде?
Ноды в кластеры используют multicast для обмена информацией.
Если они не обмениваются мультикастом, тогда это ноды разных кластеров.

ну и что? OpenVZ и без кластера работает.
более того, живые люди хотят объдинять в кластер сервера из разных сегментов.
Т.е. если такая хотелка есть, то описаный сценарий сильно упрощает жизнь.
если же и так всё устраивает, то у меня тоже
перед глазами работающие ноды, они прекрасно обходятся без OSPF.
всегда думал что знаю… но вдруг?
объясните, если сервер соеденён с маршрутизатором через сеть 192.168.1.0/24, на нём крутится контейнер с адресом 100.10.10.10,
и вот компьютер с адресом 172.0.0.1, подключённый к другому интерфейсу маршрутизатора (или вообще из интернета), хочет обратится к контейнеру. В каком месте будет proxy_arp, если явного маршрута к 100.10.10.10 через 192.168.1.0 не прописано нигде?


Наконец-то живой пример!
Или статически на маршрутизаторе прописать маршрут:
route add 100.10.10.10/32 <Ip сервера>

Или добавить на маршрутизаторе второй IP-алиас из сети 100.10.10.0/24
И тогда через бродкаст запросы будет получен MAC openvz- контейнера.
Не, ну тогда вообще динамическая маршрутизация не нужна :)
Можно всё руками настраивать. У меня был перед глазами пример, когда в живой сети на 28 роутеров все маршруты везде прописывались вручную. Красиво так всё, рекурсивно. За 10-15 минут можно легко новую сетку добавить :)
Еще есть RIPv1, он должен справится с маршрутизацией на 26 устройствах.

А вообще, рисуйте схему и прикладывайте ее к статье, чтоб было видно практической применение маршрутизации контейнеров с Openvz в сети с 26-ю маршрутизаторами.
> Если корректно настроено proxy_arp, то маршрутизаторы прекрасно видят IP внутри виртуалок.

а если, адрес контейнера из другой подсети (не совпадающей с IP сетями на интерфейсах хоста),
откуда маршрутизаторы узнают, что контейнер на этом сервере?
статику на роутере прописывать?

>При миграции с одной ноду на другую, траффик какое-то время будет ходить через старую ноду, а потом, когда MAC исчезнет из ARP-cache — через новую ноду.

это если ноды в одном сегменте, а если в разных?

кошмар сетевика какой-то…
OSPF в общей сети, причем без контроля редистрибьюции… и будет 40 нод виртуализации, каждая с кучей контейнеров.
ладно бы в отдельной NSSA, с суммаризацией (а для этого надо, чтобы /32 были не external относительно маршрутизации).
а что вас так пугает?
сказали админам: " пользуйтесь адресами из этих сеток как хотите" и если не доверяете (а я бы не доверял) — накрутите роутмапы на кваге, разрешающие только эти сети.
или вас пугают таблицы маршрутизации не помещающиеся на один экран?
и большие таблицы (разбиение пары /24 на /32 — не самая хорошая идея для FIB), и большое количество LSA при большом количестве маршрутизаторов в ospf
Sign up to leave a comment.

Articles