From World of VOC - Wiki

Jump to: navigation, search

Contents

Setting up Master-Master or Master-Slave

Single Server Configuration

In the single server configuration all clients connect to one SessionVOC instance. The SessionVOC is started with

 --server.session-port <host1>:<port1>
 --server.admin-port <host1>:<port1>

The client API connects to <host1>:<port1> to manage the sessions. The client API is configured in such a way that it knows <host1>:<port1>. For example, the PHP extension init file sessionvoc.ini contains

 extension=sessionvoc.so

 sessionvoc.directory_servers= localhost:8208
 sessionvoc.connect_timeout=5000

 sessionvoc.auto_start = On

 sessionvoc.session_name = SESSIONVOC
 sessionvoc.cookie_path = "/"

The session.directory_servers must match the configuration <host1>:<port1> of the SessionVOC. The default sessionvoc.ini contains localhost:8208. However, in a real setup it is more likely that there are more than one web server and one dedicated machine for the SessionVOC and other back-end systems. In this case you must replace localhost by the real address.

SessionVoc-Single-Server1.png

There are several web server talk to the back-end over the 192.168.0.0/24 network, while the administrator accesses the network over the 192.168.1.0/24. In this setup the SessionVOC will be started with

 --server.session-port 192.168.0.0:8208
 --server.admin-port 192.168.1.0:8209

Multi-Server Configuration

In the multi-server configuration there are two sever. Either configured as Master/Slave or as Master/Master

Master/Master Configuration

This setup is generally used if you have two data centers connected via a reliable network. A SessionVOC is running in both data center. Each SessionVOC serves the clients in its own data ceneter. In case of a failure of one data center all traffic is routed to the other data center.

Master-Master1.png

Server Configuration

The configuration is now a bit more complex. First of all the SessionVOC servers must be started in replication mode. Each server gets a unique instance number. In our example the left server is instance 0 and the right server is instance 1.

For SessionVOC 0 the configuration now looks like

 --replication.start 1
 --replication.server-instance 0

 --server.session-port 192.168.0.1:8208
 --server.admin-port 192.168.1.1:8209

 --replication.local-server 192.168.5.1:8210
 --replication.remote-server 192.168.5.2:8210

This configures the SessionVOC in such a way that

  • it starts in replication mode (either Master/Master or Master/Slave is possible)
  • has instance number 0
  • opens port 192.168.0.1:8208 for access by the client on network 192.168.0.0/24
  • opens port 192.168.1.1:8209 for access by the administrator on network 192.168.1.0/24
  • opens port 192.168.5.1:8210 for access by the SessionVOC 1 on network 192.168.5.1/24
  • knows that SessionVOC 1 will be listing for SessionVOC 0 on port 192.168.5.2:8210

Note that it is not necessary that the networks session port and the admin port are on different networks. It is also possible that they live on the same work. In this case you should restrict access from the web servers to port 8209 using an internal firewall.

Note that it is not necessary that the local-server and remote-server live on one network segment. The SessionVOC 1 could, for example use 192.168.6.1:8210 and there is a router or firewall between SessionVOC 0 and SessionVOC 1. These details are left out in order to keep the example as simple as possible.

For SessionVOC 1 the configuration is reversed

 --replication.start 1
 --replication.server-instance 1

 --server.session-port 192.168.2.1:8208
 --server.admin-port 192.168.3.1:8209

 --replication.local-server 192.168.5.2:8210
 --replication.remote-server 192.168.5.1:8210

Client Configuration

The client must be configured in such a way, that he knows which SessionVOC to contact. For example in PHP use

 ; client identifier
 sessionvoc.client_token=0
 sessionvoc.directory_servers= 192.168.0.1:8208, 192.168.2.1:8208

in data center 0 and

 ; client identifier
 sessionvoc.client_token=1
 sessionvoc.directory_servers= 192.168.2.1:8208, 192.168.0.1:8208

in data center 1.

Server Startup

Starting the server in such a way will allow either Master/Slave or Master/Master configurations.

After both servers are up and running, the following shell script must be executed to setup master-master replication

  /usr/sbin/setup.py --base-servers 192.168.5.1:8210,192.168.5.2:8210 --base-config master,master

This script can either be executed on the SessionVOC 0 machine or the SessionVOC 1 machine. It must be able to connected both server on 192.168.5.1:8210 and 192.168.5.2:8210.

The script will configure SessionVOC 0 in such a way, that it will be responsible for all sessions starting with "0000" up-to "0049" and SessionVOC 1 will be responsible for all sessions starting with "0050" up-to "0099".

Fail-Over

Scenario 1

If, for example, the internet connection of data center 1 is broken, then it will be necessary to switch all users to data center 0. The client API of the web server knows that the session between "0050" and "0099" belong to SessionVOC 1 and will try to contact this SessionVOC for the corresponding sessions.

Scenario 2

However, if for some reason it is now longer possible to contact SessionVOC 1 from data center 0, than SessionVOC 0 must be switch to full master for all sessions.

Use the follwing script to switch SessionVOC 0 to master and SessionVOC 1 to slave

 /usr/sbin/setup.py --base-servers 192.168.5.1:8210,192.168.5.2:8210 --base-config master,slave

If the problem has been solved switch back to master-master

 /usr/sbin/setup.py --base-servers 192.168.5.1:8210,192.168.5.2:8210 --base-config master,master
Scenario 3

If it is impossible to contact data center 1 from data center 0, then first switch SessionVOC 1 to slave executing the following on the SessionVOC 1 server


Second switch SessionVOC 0 to master executing the following on the SessionVOC 0 server


If the problem has been solved switch back to master-master

 /usr/sbin/setup.py --base-servers 192.168.5.1:8210,192.168.5.2:8210 --base-config master,master
Scenario 4

If the SessionVOC 1 server died switch SessionVOC 0 to master executing the following on the SessionVOC 0 server

 /usr/sbin/setup.py --base-servers 192.168.5.1:8210 --base-config master

If the problem has been solved and SessionVOC 1 is up again, switch back to master-master

 /usr/sbin/setup.py --base-servers 192.168.5.1:8210,192.168.5.2:8210 --base-config master,master