#DDBMS # Redundant Docker Networks (Evolutionary edition)

Environment Preparation:

Four Ubuntu server 14.04 configured in VMware (you can install only one system, clone another three Ubuntu using cloning), configure SSH

Each machine is configured with two network cards, like OpenStack, internal and external IPs. Here I let eth0 (NAT) as External,eth1 (host-only) as internal.

The topology diagram is as follows:

Install OvS:

Specific installation tutorial reference here: http://www.sdnlab.com/3166.html

Attach my OvS startup script:

Ovs_launch#!/bin/bash#launch the ovsovsdb-server-v--remote=punix:/usr/local/var/run/openvswitch/db.sock--remote= Db:open_vswitch,open_vswitch,manager_options--private-key=db:open_vswitch,ssl,private_key--certificate=db:Open _vswitch,ssl,certificate--bootstrap-ca-cert=db:open_vswitch,ssl,ca_cert--pidfile--detach#init the Databaseovs-vsctl--no-wait init#launch The main processovs-vswitchd--pidfile--detach#print the version Infomationovs-vsctl--versionecho Echo ' Openvswitch have been launched successfully! '

Save and place the script

chmod +x OVS_LAUNCHMV Ovs_launch/usr/local/bin

To install the Pipework tool:

git clone https://github.com/jpetazzo/pipeworkcp ~/pipework/pipework/usr/local/bin/

Install the latest version of Docker: https://docs.docker.com/installation/ubuntulinux/

Pull an Image:

Docker pull Ubuntu

Create Br0 and BR1 bridges for mounted containers:

Brctl addbr br0ip link set dev br0 upip addr add 192.168.2.1/24 dev br0brctl addbr br1ip link set dev br1 upip addr Add 19 2.168.3.1/24 Dev BR1

Configure OvS on each host (Ovs_launch is performed on each boot):

Ovs-vsctl add-br Ovs0ovs-vsctl Set bridge ovs0 stp_enable=trueovs-vsctl add-port br0ovs-vsctl add-port BR1

Create a host1tohost2 Vxlan or GRE tunnel (I'm using GRE here):

Ovs-vsctl add-port ovs0 gre0--set interface gre0 Type=gre options:remote_ip=10.20.10.71

To create a GRE tunnel for Host2tohost1:

Ovs-vsctl add-port ovs0 gre0--set interface gre0 Type=gre options:remote_ip=10.20.10.70

To create a host2tohost3 tunnel:

Ovs-vsctl add-port ovs0 gre1--set interface Gre1 Type=gre options:remote_ip=10.20.10.72

To create a host3tohost2 tunnel:

Ovs-vsctl add-port ovs0 gre1--set interface Gre1 Type=gre options:remote_ip=10.20.10.71

To create a host3tohost4 tunnel:

Ovs-vsctl add-port ovs0 gre2--set interface Gre2 Type=gre options:remote_ip=10.20.10.73

To create a host4tohost3 tunnel:

Ovs-vsctl add-port ovs0 gre2--set interface Gre2 Type=gre options:remote_ip=10.20.10.72

To create a host4tohost1 tunnel:

Ovs-vsctl add-port ovs0 gre3--set interface Gre3 Type=gre options:remote_ip=10.20.10.70

To create a host1tohost4 tunnel:

Ovs-vsctl add-port ovs0 gre3--set interface Gre3 Type=gre options:remote_ip=10.20.10.73

(Note that the interchange tunnel name between the two hosts is the same, and no tunnel with duplicate names can occur on each OvS)

Start the container and test:

Host1:

Docker run-itd--name=test1 ubuntupipework br0 test1 192.168.2.11/24

Host2:

Docker run-itd--name=test1 ubuntupipework br0 test1 192.168.2.12/24

HOST3:

Docker run-itd--name=test1 ubuntupipework br1 test1 192.168.3.11/24

HOST4:

Docker run-itd--name=test1 ubuntupipework br1 test1 192.168.3.12/24

Enter the container to test, you will find that no matter which container, as long as hanging on the same BR bridge (the same network segment), they are interoperable. Of course, if you use 192.168.2.11 ping 192.168.3.11 that is absolutely not possible (unless you do not put br0 and BR1 on the Ovs0, the route will be routed, in which case interoperability).

For a test on how to enter the container, refer to my blog: http://my.oschina.net/hochikong/blog/369036

At this point, you set up a redundant network of Docker containers.

Summarize:

On the network ha, you can take a simple star topology, but the star topology is only suitable for small-scale clusters. I take the means of enabling all OvS STP (spanning Tree protocol, must be enabled before mounting br0 or BR1), and then connecting the switch to a loop, which can be implemented when one host disconnects and the impact on other hosts is minimized (when the ring is broken, STP will reconfigure a link, causing the network to break for a few seconds, This depends on the distributed application solution in Docker. You can write a program to implement the scheduling function.

In addition, I assign IP addresses manually, and if there is a distributed DHCP service, pipework can also support DHCP assigning IP addresses to containers (refer to section 2.1 here)

Docker is mounted locally by default on Docker0, you do not shut down the Docker0 bridge, and with pipework, the container has two IP addresses (you must configure a default bridge for the container, Otherwise, the external visitors will not be able to access the services in the Docker container via port, so I did not delete the default Docker0 and did not change the configuration of the/etc/default/docker. Pipework by default, a NIC named Eth1 is configured for the container, and you can modify the name as needed in pipework's source code.

In this scenario, distributed applications need to communicate with each other through the eth1 of the container.

The host's internal IP is used by the maintainer for management, and external IP is used to provide services externally.

If you want the container to ping the outside network, you must configure dnat such things.

Hochikong

Reference:

http://blog.163.com/digoal%40126/blog/static/163877040201411602548445/

Http://www.infoq.com/cn/articles/docker-network-and-pipework-open-source-explanation-practice

http://hiaero.net/beginning-openvswitch/

https://docs.docker.com/installation/ubuntulinux/

Http://www.sdnlab.com/3166.html

#DDBMS # Redundant Docker Networks (Evolutionary edition)