HighAvailabilityOpenERP Documentation

Release 0.2

OpenERP S.A.

June 26, 2012

CONTENTS

Load-Balancing 1.1 Synopsis . 1.2 Nginx . . . 1.3 Gunicorn . 1.4 OpenERP .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

3 3 3 4 4 5 5 7

High Availability 2.1 PostgreSQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 PG-Pool II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

ii

HighAvailabilityOpenERP Documentation, Release 0.2

Note: We use Ubuntu 12.04 LTS for this tutorial

CONTENTS

HighAvailabilityOpenERP Documentation, Release 0.2

CONTENTS

CHAPTER

ONE

LOAD-BALANCING
1.1 Synopsis
In this part, we will explain how to create a load-balancer with nginx for a lot of OpenERP servers. The load-balancing and the multi-process mode of OpenERP only work with gunicorn. And in this case, the cron are not launched by the system.

1.2 Nginx
Nginx is a free, open-source, high-performance HTTP server and reverse proxy You can copy/paste the code in /etc/nginx/sites-enabled/ with a lename You will nd the documentation about the upstream keyword at http://wiki.nginx.org/HttpUpstreamModule
upstream openerp_servers { server openerp-server1.back.local max_fails=3 fail_timeout=30s; server openerp-server2.back.local max_fails=3 fail_timeout=30s; server openerp-server3.back.local max_fails=3 fail_timeout=30s; } serfver { listen 80; server_name openerp.example.com; rewrite ^ https://$server_name$request_uri? permanent; } server { listen 443; server_name openerp.example.com; access_log /var/log/nginx/openerp.example.com-access.log; error_log /var/log/nginx/openerp.example.com-error.log debug; ssl on; ssl_certificate /etc/nginx/ssl/server.crt; ssl_certificate_key /etc/nginx/ssl/server.key; ssl_session_timeout 5m; ssl_protocols SSLv3 TLSv1;

HighAvailabilityOpenERP Documentation, Release 0.2

ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv3:+EXP; ssl_prefer_server_ciphers on; location / { proxy_pass http://openerp_servers; proxy_set_header Host $http_host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }

1.3 Gunicorn
Gunicorn is a Python WSGI HTTP Server for UNIX. We will use it for the multi-process mode of OpenERP. On the OpenERP servers, just install gunicorn via apt-get
# apt-get install python-gunicorn

1.4 OpenERP
You should congure OpenERP with the gunicorn mode. In the directory of the server, you can execute gunicorn with the following command
cd /home/openerp/server gunicorn openerp:wsgi.proxied.application -c gunicorn.conf.py

Chapter 1. Load-Balancing

CHAPTER

TWO

HIGH AVAILABILITY
2.1 PostgreSQL
2.1.1 Synopsis
PostgreSQL is a free and open source database server. In this documentation, we will use PostgreSQL 9.x because this is the rst release with the Streaming Replication. In PostgreSQL, there are two kind of replication. Warm Standby Its a simple replication without any access. Hot Standby, in this mode, you can connect to the database but only in read access. We will use the Hot Standby mode for the Streaming Replication. In this tutorial, we suppose that you use an unix account, named openerp. Firstly, we have to congure two PostgreSQL servers, the master and the slave.

2.1.2 Streaming Replication

Here is the directory structure for the tutorial
root@vm:/# tree home home |-> openerp |-> postgresql |-> master |-> standby mkdir /home/openerp/postgresql

Master Via this command we initialize a new PostgreSQL cluster.

cd /home/openerp/postgresql /usr/lib/postgresql/9.1/bin/initdb -D master

HighAvailabilityOpenERP Documentation, Release 0.2

The wal_level parameter species the hot_standby mode and the max_wal_senders is the number of slave servers. In this case, the value is one.
cat >> master/postgresql.conf << _EOF_ > include replication.conf > _EOF_ cat >> master/replication.conf << _EOF_ > wal_level = hot_standby > max_wal_senders = 1 > archive_mode = on > #archive_command = cp %p /home/stephane/postgresql/test/archives_xlog/%f > _EOF_

We start the new PostgreSQL cluster

/usr/lib/postgresql/9.1/bin/pg_ctl -D master start

Authentication We will use the replication via the network, in this case, we have to congure the PostgreSQL server to use a dedicated user for the replication. In our case, this is the openerp user. Its a normal postgresql user, dont forget to set all the rights for this user and a password.
createuser openerp psql -d postgres -c "ALTER USER openerp PASSWORD secret;"

Note: Here is a part of the content of the master/pg_hba.conf le

# The replication database is a virtual database used by the replication process host replication openerp 127.0.0.1/32 md5

# Dont forget to restart the master server before the slave because without that, the slave cant be /usr/lib/postgresql/9.1/bin/pg_ctl -D master restart

Slave To create a backup of the master for the slave, you can use the pg_basebackup command provided with PostgreSQL 9.1.

cd /home/openerp/postgresql /usr/lib/postgresql/9.1/bin/pg_ctl/pg_basebackup -D standby -v -P -Fp -l backup -h 127.0.0.1 -U opene

We congure the standby server to listen to the port 5433 (because we are on the same physical server). If the standby server is another server, dont forget to use 5432.
cat > standby/replication.conf << _EOF_ > port = 5433 > hot_standby = on > _EOF_

The primary_conninfo is used by the Streaming Replication, the parameter have the hostname of the master with the port and the pair user/password.

Chapter 2. High Availability

HighAvailabilityOpenERP Documentation, Release 0.2

cat > standby/recovery.conf << _EOF_ > standby_mode = on > primary_conninfo = host=127.0.0.1 port=5432 user=openerp password=secret > trigger_file = /tmp/standby > _EOF_

In this cong le, the trigger_le key will be used by the server, if there is a touch on this le, the standby server will automatically pass in the master mode with the read/write accesses.

2.2 PG-Pool II
For the load-balancing and the failover features, we will use PgPool2.

2.2.1 Installation
# apt-get install pgpool2 # apt-get install postgresql-9.1-pgpool2

2.2.2 Conguration
Here is the basic conguration for the load-balancing and the failover. The failover_command is important because if pgpool cant make a connection to the master, it will touch /tmp/standby le and this le will be triggered by the standby server. If you want to use this feature with a remote standby server, you can use ssh to touch a le on a remote server. But dont forget to change the cong le of the standby server and set the right value for the trigger_file parameter.
cat >> /etc/pgpool2/pgpool.conf << _EOF_ > port = 5434 > load_balance_mode = on > backend_hostname0 = localhost > backend_port0=5432 > backend_weight0=1 > backend_flag0 = ALLOW_TO_FAILOVER > backend_hostname1 = localhost > backend_port1=5433 > backend_weight0=1 > backend_flag1 = ALLOW_TO_FAILOVER > failover_command = touch /tmp/standby > _EOF_

2.2. PG-Pool II