Comments 13
В статье написана каша.
Если корректно настроено proxy_arp, то маршрутизаторы прекрасно видят IP внутри виртуалок.
При миграции с одной ноду на другую, траффик какое-то время будет ходить через старую ноду, а потом, когда MAC исчезнет из ARP-cache — через новую ноду.
Использовать OSPF нужно только в очень специфичных случаях использования контейнеров.
Но для того, чтоб контейнер был доступен из сети, следует использовать адреса из той же IP сети, к которой подключён физический сервер (HN).
Если корректно настроено proxy_arp, то маршрутизаторы прекрасно видят IP внутри виртуалок.
При миграции с одной ноду на другую, траффик какое-то время будет ходить через старую ноду, а потом, когда MAC исчезнет из ARP-cache — через новую ноду.
Использовать OSPF нужно только в очень специфичных случаях использования контейнеров.
0
> Если корректно настроено proxy_arp, то маршрутизаторы прекрасно видят IP внутри виртуалок.
а если, адрес контейнера из другой подсети (не совпадающей с IP сетями на интерфейсах хоста),
откуда маршрутизаторы узнают, что контейнер на этом сервере?
статику на роутере прописывать?
>При миграции с одной ноду на другую, траффик какое-то время будет ходить через старую ноду, а потом, когда MAC исчезнет из ARP-cache — через новую ноду.
это если ноды в одном сегменте, а если в разных?
а если, адрес контейнера из другой подсети (не совпадающей с IP сетями на интерфейсах хоста),
откуда маршрутизаторы узнают, что контейнер на этом сервере?
статику на роутере прописывать?
>При миграции с одной ноду на другую, траффик какое-то время будет ходить через старую ноду, а потом, когда MAC исчезнет из ARP-cache — через новую ноду.
это если ноды в одном сегменте, а если в разных?
0
а если, адрес контейнера из другой подсети (не совпадающей с IP сетями на интерфейсах хоста),
откуда маршрутизаторы узнают, что контейнер на этом сервере?
статику на роутере прописывать?
Почитайте, что такое proxy_arp и как работать с MAC адресами.
это если ноды в одном сегменте, а если в разных?
Ноды в кластеры используют multicast для обмена информацией.
Если они не обмениваются мультикастом, тогда это ноды разных кластеров.
У меня перед глазами работающие ноды, они прекрасно обходятся без OSPF.
0
Почитайте, что такое 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.
0
всегда думал что знаю… но вдруг?
объясните, если сервер соеденён с маршрутизатором через сеть 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- контейнера.
0
> Если корректно настроено proxy_arp, то маршрутизаторы прекрасно видят IP внутри виртуалок.
а если, адрес контейнера из другой подсети (не совпадающей с IP сетями на интерфейсах хоста),
откуда маршрутизаторы узнают, что контейнер на этом сервере?
статику на роутере прописывать?
>При миграции с одной ноду на другую, траффик какое-то время будет ходить через старую ноду, а потом, когда MAC исчезнет из ARP-cache — через новую ноду.
это если ноды в одном сегменте, а если в разных?
а если, адрес контейнера из другой подсети (не совпадающей с IP сетями на интерфейсах хоста),
откуда маршрутизаторы узнают, что контейнер на этом сервере?
статику на роутере прописывать?
>При миграции с одной ноду на другую, траффик какое-то время будет ходить через старую ноду, а потом, когда MAC исчезнет из ARP-cache — через новую ноду.
это если ноды в одном сегменте, а если в разных?
0
кошмар сетевика какой-то…
OSPF в общей сети, причем без контроля редистрибьюции… и будет 40 нод виртуализации, каждая с кучей контейнеров.
ладно бы в отдельной NSSA, с суммаризацией (а для этого надо, чтобы /32 были не external относительно маршрутизации).
OSPF в общей сети, причем без контроля редистрибьюции… и будет 40 нод виртуализации, каждая с кучей контейнеров.
ладно бы в отдельной NSSA, с суммаризацией (а для этого надо, чтобы /32 были не external относительно маршрутизации).
0
а что вас так пугает?
сказали админам: " пользуйтесь адресами из этих сеток как хотите" и если не доверяете (а я бы не доверял) — накрутите роутмапы на кваге, разрешающие только эти сети.
или вас пугают таблицы маршрутизации не помещающиеся на один экран?
сказали админам: " пользуйтесь адресами из этих сеток как хотите" и если не доверяете (а я бы не доверял) — накрутите роутмапы на кваге, разрешающие только эти сети.
или вас пугают таблицы маршрутизации не помещающиеся на один экран?
0
Sign up to leave a comment.
OpenVZ, Quagga и LiveMigration