Вот схема: у нас есть оборудование (сервер), которое предоставляет услугу клиенту (или «внешнему миру», если хотите). Внутри службы и функции распределены по нескольким виртуальным машинам (с разными ролями). Мы используем kvm для виртуализации и libvirt для управления им. Аппаратное обеспечение имеет две сетевые карты, которые перенаправляются на одну из виртуальных машин (называемую gateway-vm) с помощью «однокорневой виртуализации ввода-вывода» (Intel VT-D / AMD IOMMU).
Мы используем openvswitch в базовой операционной системе хоста для создания внутренней сети с частными адресами между всеми виртуальными машинами и хостом. Это потому, что у нас возникли проблемы с привязкой моста к виртуальному интерфейсу. (В отличие от привязки к физическому интерфейсу, операция / команда были приняты, но сетевое взаимодействие больше невозможно)
Это нормально работает. Прокси-сервер в gateway-vm предлагает все внутренние службы внешнему миру. Хорошо, это работает.
У нас даже есть несколько таких машин.
Для обеспечения избыточности мы хотели бы, чтобы одна из внутренних виртуальных машин (которая, конечно, не является шлюзом-vm, назовем ее database-vm) взаимодействовала с базой данных-vm другого оборудования. Поэтому мы следим за тем, чтобы внутренние частные адреса не конфликтовали, например 10.10.1.5 и 10.10.2.5 (каждый / 24).
Наш подход состоит в том, чтобы настроить gre-туннель с ipsec между двумя шлюзами-машинами, что уже работает. 10.10.1.1 может пинговать 10.10.2.1 и наоборот.
Теперь мы застряли в том, чтобы заставить виртуальную машину базы данных одного оборудования разговаривать / пинговать с другой виртуальной машиной шлюза другого оборудования, и наоборот, и в конечном итоге позволить двум виртуальным машинам базы данных общаться друг с другом.
Что было бы правильным способом добиться этого? Мы не уверены, нужен ли нам ip_forwarding на каком-либо из шлюзов и как должен выглядеть маршрут. Или все должны быть одной большой подсетью без маршрутизации?
В настоящее время мы используем ovs v1.7.1, ядро 3.2.6, libvirt v0.10.2, QEMU 1.1.1
Поскольку вы используете прокси-сервер на шлюзах-виртуальных машинах, по-видимому, они не выполняют ip-переадресацию на них.
Вы можете включить ip-forwarding на вашем шлюзе-vm (s) и маршрутизировать трафик, например: database-vm1 <-> gateway-vm1 <-ipsec / gre-> gateway-vm2 <-> database-vm2
Вы должны быть осторожны, чтобы не включить переадресацию трафика для обхода ваших прокси-серверов для исходящего трафика ... маловероятно, вероятно, но о чем нужно знать, когда вы настраиваете это.
Правильная маршрутизация может быть немного сложной. Если вы действительно используете / 16s в сети, в которой находятся серверы баз данных, вам может потребоваться настроить некоторые вещи, поскольку 10.10.1.5 и 10.10.2.5 находятся в том же / 16, что затруднит настройку маршрутизации. Возможно, если вы просто переместите свои сетевые маски на / 24, чтобы они находились в разных IP-сетях, это упростит определение маршрутов?
Я немного странный в сетевом мире, так как мне нравится продвигать решения о маршрутизации дальше к краю, иногда даже на хосты, поэтому я упомяну, что вы, возможно, захотите посмотреть на что-то вроде работы quagga OSPF, возможно, чтобы упростить часть этого. Может, проще не покажется, не уверен.
Общая идея состоит в том, что gateway-vm1 должен иметь маршрут для ссылки gateway-vm2 <-> database-vm2 в своей таблице маршрутизации со следующим переходом к gateway-vm2 через туннель IPSec / GRE. Точно так же gateway-vm2 должен иметь маршрут для ссылки gateway-vm1 <-> database-vm1 в своей таблице маршрутизации со следующим переходом к шлюзу-vm1 через туннель IPSec / GRE.
Если вы используете межсоединения IPSec / GRE ... одна большая подсеть не совсем исключена (теоретически вы могли бы соединить шлюз-vms между виртуальным коммутатором и ссылкой GRE), но я, конечно, не хотел бы настраивать его таким образом.
Если бы я был на вашем месте, я мог бы переосмыслить свое распределение физических сетевых адаптеров и использовать один для межсоединения между оборудованием, чтобы вам не приходилось использовать IPSec / GRE для кроссовера ... с этим вы могли бы запустить экземпляр ovs на каждом оборудовании, подключите к нему кроссоверную сетевую карту и используйте ее в качестве частного межсоединения, и базы данных-vms смогут взаимодействовать друг с другом «напрямую» по этому частному межсоединению.