高可用性のためにPostgreSQLストリーミングレプリケーションでOdoo12をクラスター化する方法

Odoo（旧称OpenERP）は、オープンソースのビジネスアプリのスイートです。コミュニティとエンタープライズの2つのバージョンがあります。このプラットフォームに統合されている最も人気のある（そして無料の）アプリには、ディスカッション、CRM、在庫、ウェブサイト、従業員、休暇、採用、経費、経理、請求、POSなどがあります。

このブログ投稿では、Odooをクラスター化して高可用性とスケーラビリティを実現する方法について説明します。この投稿は、Drupal、WordPress、Magentoのスケーリングに関する以前の投稿と似ています。使用されるソフトウェアは、Odoo 12、HAProxy 1.8.8、Keepalived 1.3.9、PostgreSQL 11、およびOCFS2（Oracle Cluster File System）です。

セットアップは6台のサーバーで構成されています：

lb1（HAProxy）+キープアライブ+ ClusterControl-192.168.55.101
lb2（HAProxy）+キープアライブ+共有ストレージ-192.168.55.102
odoo1-192.168.55.111
odoo2-192.168.55.112
postgresql1（マスター）-192.168.55.121
postgresql2（スレーブ）-192.168.55.122

すべてのノードはUbuntu18.04.2LTS（Bionic）で実行されています。 ClusterControlを使用して、PostgreSQL、Keepalived、およびHAProxyをデプロイおよび管理します。これにより、多くの作業を節約できます。 ClusterControlはlb1のHAProxyと同じ場所に配置され、共有ストレージプロバイダーとして使用するディスクをlb2に追加します。このディスクは、OCFS2と呼ばれるクラスター化されたファイルシステムを共有ディレクトリとして使用してマウントされます。仮想IPアドレス192.168.55.100は、データベースサービスの単一のエンドポイントとして機能します。

次の図は、システムアーキテクチャ全体を示しています。

以下は、すべてのノードの/ etc/hostsの内容です。

192.168.55.101  lb1.local lb1 cc.local cc
192.168.55.102  lb2.local lb2 storage.local storage
192.168.55.111  odoo1.local odoo1
192.168.55.112  odoo2.local odoo2
192.168.55.121  postgresql1.local postgresql1
192.168.55.122  postgresql2.local postgresql2

PostgreSQLストリーミングレプリケーションの導入

lb1にClusterControlをインストールすることから始めます：

$ wget severalnines.com/downloads/cmon/install-cc
$ chmod 755 ./install-cc
$ sudo ./install-cc

インストールウィザードに従ってください。プロセス中にいくつかの質問に答える必要があります。

ClusterControlノード（lb1）からClusterControlによって管理されるすべてのノード（lb1（それ自体）、lb2、postresql1、postgresql2）へのパスワードなしのSSHをセットアップします。ただし、最初にSSHキーを生成します：

$ whoami
ubuntu
$ ssh-keygen -t rsa # press Enter on all prompts

次に、ssh-copy-idツールを使用してすべてのターゲットノードにキーをコピーします。

$ whoami
ubuntu
$ ssh-copy-id [email protected]
$ ssh-copy-id [email protected]
$ ssh-copy-id [email protected]
$ ssh-copy-id [email protected]

http://192.168.55.101/clustercontrolでClusterControlUIを開きますパスワードを使用してスーパー管理者ユーザーを作成します。 ClusterControlUIダッシュボードにリダイレクトされます。次に、トップメニューの[展開]ボタンをクリックして、新しいPostgreSQLクラスターを展開します。次の展開ダイアログが表示されます：

次のダイアログ「PostgreSQLサーバーの定義」に入力した内容は次のとおりです。

サーバーポート： 5432
ユーザー： postgres
パスワード： s3cr3t
バージョン： 11
Datadir：<空白のまま>
リポジトリ：ベンダーリポジトリを使用する

[トポロジの定義]セクションで、postgresql1とpostgresql2のIPアドレスを適宜指定します。

最後のセクション「デプロイメントの概要」の下に、同期レプリケーションを有効にするオプションがあります。スレーブはフェイルオーバーの目的でのみ使用するため（スレーブは読み取り操作を提供しません）、デフォルト値をそのままにします。次に、「Deploy」を押してデータベースクラスターの展開を開始します。 アクティビティ>ジョブ>クラスターの作成を確認することで、展開の進行状況を監視できます。：

その間、コーヒーを飲み、クラスターの展開は10〜15分以内に完了する必要があります。

PostgreSQLサーバーへのロードバランサーと仮想IPの導入

この時点で、マスタースレーブセットアップで実行されている2ノードのPostgreSQLレプリケーションクラスターがすでにあります。

次のステップは、データベースのロードバランサー層をデプロイすることです。これにより、データベースを仮想IPアドレスに結び付け、アプリケーションに単一のエンドポイントを提供できます。 HAProxyの展開オプションを次のように構成します。

このアプリケーションはネイティブで読み取り/書き込み分割をサポートしていないため、アクティブ-パッシブ方式を使用して高可用性を実現します。一度に1つのPostgreSQLノードしか使用していないため、最適な負荷分散アルゴリズムは「ソース」ポリシーです。

他のロードバランサーlb2についても同じ手順を繰り返します。代わりに、「サーバーアドレス」を192.168.55.102に変更してください。 [ノード]ページに移動すると、展開が完了した後の状態は次のようになります。

最初のリスナーの赤い線は、ヘルスチェックスクリプトがノードがアップしているがマスターではないことを返すため、HAProxyがpostgresql2（192.168.55.122）がダウンしていることを示していると予想されます。青い線の2番目のリスナー（haproxy_5434_ro）は、ノードがUPであるが、「バックアップ」状態にあることを示しています。ただし、アプリケーションは読み取り/書き込み分割をサポートしていないため、このリスナーは無視できます。

次に、これらのロードバランサーの上にKeepalivedインスタンスをデプロイして、単一の仮想IPアドレスでそれらを結び付けます。 管理->ロードバランサー->キープアライブ->キープアライブのデプロイに移動します最初と2番目のHAProxyインスタンスを指定してから、リッスンする仮想IPアドレスとネットワークインターフェイスを指定します。

「キープアライブのデプロイ」をクリックして、デプロイメントを開始します。これで、PostgreSQL接続サービスはいずれかのデータベースノードに負荷分散され、192.168.55.100ポート5433を介してアクセスできます。

iSCSIの構成

ストレージサーバー（lb2）は、iSCSIを介してディスクをエクスポートして、両方のOdooアプリケーションサーバー（odoo1とodoo2）にマウントできるようにする必要があります。 iSCSIは基本的に、カーネルにSCSIディスクがあることを通知し、そのアクセスをIP経由で転送します。「サーバー」は「ターゲット」と呼ばれ、そのiSCSIデバイスを使用する「クライアント」は「イニシエーター」です。

まず、iSCSIターゲットをlb2にインストールします：

$ sudo apt install -y tgt

起動時にtgtを有効にする：

$ systemctl enable tgt

ファイルシステムクラスタリング用に別のディスクを用意することをお勧めします。したがって、lb2（/ dev / sdb）にマウントされた別のディスクを使用して、アプリケーションサーバー（odoo1とodoo2）間で共有します。まず、tgtadmツールを使用してiSCSIターゲットを作成します。

$ sudo tgtadm --lld iscsi --op new --mode target --tid 1 -T iqn.2019-02.lb2:odcfs2

次に、ブロックデバイス/ dev /sdbをターゲットID1とともに論理ユニット番号（LUN）1に割り当てます。

$ sudo tgtadm --lld iscsi --op new --mode logicalunit --tid 1 --lun 1 -b /dev/sdb

次に、同じネットワーク上のイニシエーターノードがこのターゲットにアクセスできるようにします。

$ sudo tgtadm --lld iscsi --op bind --mode target --tid 1 --initiator-address 192.168.55.0/24

tgt-adminツールを使用してiSCSI構成行をダンプし、構成ファイルとして保存して、再起動後も永続的にします。

$ sudo tgt-admin --dump > /etc/tgt/conf.d/shareddisk.conf

最後に、iSCSIターゲットサービスを再起動します。

$ sudo systemctl restart tgt

**次の手順は、odoo1とodoo2で実行する必要があります。

それぞれのホストにiSCSIイニシエーターをインストールします：

$ sudo apt-get install -y open-iscsi

自動的に開始するようにiSCSIイニシエーターを設定します：

$ sudo systemctl enable open-iscsi

以前に設定したiSCSIターゲットを検出します：

$ sudo iscsiadm -m discovery -t sendtargets -p lb2
192.168.55.102:3260,1 iqn.2019-02.lb2:odcfs2

上記と同様の結果が表示された場合は、iSCSIターゲットを確認して接続できることを意味します。次のコマンドを使用して、lb2のiSCSIターゲットに接続します。

$ sudo iscsiadm -m node --targetname iqn.2019-02.lb2:odcfs2 -p lb2 -l
Logging in to [iface: default, target: iqn.2019-02.lb2:odcfs2, portal: 192.168.55.102,3260] (multiple)
Login to [iface: default, target: iqn.2019-02.lb2:odcfs2, portal: 192.168.55.102,3260] successful.

/ devディレクトリの下にリストされている新しいハードディスク（/ dev / sdb）が表示されていることを確認してください：

$ sudo ls -1 /dev/sd*
/dev/sda
/dev/sda1
/dev/sda2
/dev/sda3
/dev/sdb

これで、共有ディスクが両方のアプリケーションサーバー（odoo1とodoo2）にマウントされました。

Odoo用のOCFS2の構成

**特に指定がない限り、次の手順はodoo1で実行する必要があります。

OCFS2では、ファイルシステムを複数の場所にマウントできます。 odoo1サーバーとodoo2サーバーの両方にOCFS2ツールをインストールします。

$ sudo apt install -y ocfs2-tools

ハードディスクドライブ/dev/ sdbのディスクパーティションテーブルを作成します：

$ sudo cfdisk /dev/sdb

cfdiskウィザードで次のシーケンスを使用してパーティションを作成します。新規>プライマリ>受け入れサイズ>書き込み>はい>終了 。

/ dev / sdb1：

にOCFS2ファイルシステムを作成します

$ sudo mkfs.ocfs2 -b 4K -C 128K -L "Odoo_Cluster" /dev/sdb1
mkfs.ocfs2 1.8.5
Cluster stack: classic o2cb
Label: Odoo_Cluster
Features: sparse extended-slotmap backup-super unwritten inline-data strict-journal-super xattr indexed-dirs refcount discontig-bg append-dio
Block size: 4096 (12 bits)
Cluster size: 131072 (17 bits)
Volume size: 21473656832 (163831 clusters) (5242592 blocks)
Cluster groups: 6 (tail covers 2551 clusters, rest cover 32256 clusters)
Extent allocator size: 4194304 (1 groups)
Journal size: 134217728
Node slots: 8
Creating bitmaps: done
Initializing superblock: done
Writing system files: done
Writing superblock: done
Writing backup superblock: 3 block(s)
Formatting Journals: done
Growing extent allocator: done
Formatting slot map: done
Formatting quota files: done
Writing lost+found: done
mkfs.ocfs2 successful

/etc/ocfs2/cluster.confにクラスター構成ファイルを作成し、ノードとクラスターのディレクティブを以下のように定義します。

# /etc/ocfs2/cluster.conf
cluster:
        node_count = 2
        name = ocfs2
node:
        ip_port = 7777
        ip_address = 192.168.55.111
        number = 1
        name = odoo1
        cluster = ocfs2
node:
        ip_port = 7777
        ip_address = 192.168.55.112
        number = 2
        name = odoo2
        cluster = ocfs2

nodeまたはcluster句の下の属性は、タブの後にある必要があることに注意してください。

**特に指定がない限り、次の手順はodoo1とodoo2で実行する必要があります。

odoo2に同じ設定ファイル（/etc/ocfs2/cluster.conf）を作成します。このファイルは、クラスター内のすべてのノードで同じである必要があり、このファイルに加えられた変更は、クラスター内の他のノードに伝播される必要があります。

o2cbサービスを再起動して、/ etc / ocfs2 / cluster.confで行った変更を適用します：

$ sudo systemctl restart o2cb

/ var / lib / odooの下にOdooファイルディレクトリを作成します：

$ sudo mkdir -p /var/lib/odoo

/ dev/sdb1デバイスのブロックIDを取得します。 iSCSIデバイスを使用する場合は、fstabでUUIDをお勧めします：

$ sudo blkid /dev/sdb1 | awk {'print $3'}
UUID="93a2b6c4-d800-4532-9a9b-2d2f2f1a726b"

次の行を/etc/ fstabに追加するときは、UUID値を使用します。

UUID=93a2b6c4-d800-4532-9a9b-2d2f2f1a726b       /var/lib/odoo     ocfs2   defaults,_netdev        0 0

ocfs2クラスターを登録し、fstabからファイルシステムをマウントします：

$ sudo o2cb register-cluster ocfs2
$ sudo mount -a

確認方法：

$ mount | grep odoo
/dev/sdb1 on /var/lib/odoo type ocfs2 (rw,relatime,_netdev,heartbeat=local,nointr,data=ordered,errors=remount-ro,atime_quantum=60,coherency=full,user_xattr,acl,_netdev)

すべてのアプリケーションサーバーで上記の行が表示されている場合は、Odooをインストールすることをお勧めします。

Odoo12のインストールと構成

**特に指定がない限り、次の手順はodoo1とodoo2で実行する必要があります。

パッケージリポジトリからOdoo12をインストールします：

$ wget -O - https://nightly.odoo.com/odoo.key | sudo apt-key add -
$ echo "deb http://nightly.odoo.com/12.0/nightly/deb/ ./" | sudo tee -a /etc/apt/sources.list.d/odoo.list
$ sudo apt update && sudo apt install odoo

デフォルトでは、上記のコマンドは、Odoo依存関係の一部として同じホストにPostgreSQLサーバーを自動的にインストールします。とにかくローカルサーバーを使用しないので、おそらく停止したいと思います：

$ sudo systemctl stop postgresql
$ sudo systemctl disable postgresql

postgresql1で、「odoo」というデータベースユーザーを作成します。

$ sudo -i
$ su - postgres
$ createuser --createrole --createdb --pwprompt odoo

プロンプトでパスワードを指定します。次に、postgresql1とpostgresql2の両方で、pg_hba.conf内に次の行を追加して、アプリケーションノードとロードバランサーノードが接続できるようにします。私たちの場合のように、それは/etc/postgresql/11/main/pg_hba.confにあります：

host  all  all       192.168.55.0/24    md5

次に、PostgreSQLサーバーをリロードして、変更をロードします。

$ su - postgres
$ /usr/lib/postgresql/11/bin/pg_ctl reload -D /var/lib/postgresql/11/main/

/etc/odoo/odoo.confにあるOdoo構成ファイルを編集し、それに応じてadmin_passwd、db_host、およびdb_passwordパラメーターを構成します。

[options]
; This is the password that allows database operations:
admin_passwd = admins3cr3t
db_host = 192.168.55.100
db_port = 5433
db_user = odoo
db_password = odoopassword
;addons_path = /usr/lib/python3/dist-packages/odoo/addons

両方のサーバーでOdooを再起動して、新しい変更をロードします。

$ sudo systemctl restart odoo

、Webブラウザを介してアプリケーションサーバーの1つでOdooを開きます。この例では、odoo1に接続しているため、URLは http://192.168.55.111:8069/です。次の最初のページが表示されます：

Odoo構成ファイルで定義されているadmin_passwd値と同じ「マスターパスワード」を指定します。次に、このプラットフォームを使用する新会社に必要なすべての情報を入力します。

完了したら、初期化が完了するまでしばらく待ちます。 Odoo管理ダッシュボードにリダイレクトされます：

この時点で、Odooのインストールが完了し、この会社のビジネスアプリの構成を開始できます。このアプリケーションサーバーによって行われたすべてのファイル変更は、「/ var / lib / odoo / .local」（別のアプリケーションサーバーodoo2にもマウントされています）にあるクラスター化されたファイルシステム内に保存されますが、データベースへの変更は行われます。 PostgreSQLマスターノード上。

2つの異なるホストで実行されているにもかかわらず、この記事ではOdooアプリケーション自体の負荷分散が行われていないことに注意してください。データベースクラスターにデプロイされたHAProxyインスタンスを使用して、データベースサービスと同じように可用性を向上させることができます。さらに、両方のアプリケーションサーバーで使用される共有ディスクファイルシステム（OCFS2）は、すべてlb2で同じiSCSIデバイスを使用しているため（lb2にアクセスできない場合を想像してください）、単一障害点にさらされます。

データベースフェイルオーバー操作

PostgreSQLマスターがダウンした場合に何が起こるのか疑問に思われるかもしれません。その場合、以下のスクリーンショットに示すように、ClusterControlは実行中のスレーブをマスターに自動的に昇格させます。

フェイルオーバーは自動的に実行されるため（30秒の猶予期間後）、エンドユーザーから何もする必要はありません。フェイルオーバーが完了すると、新しいトポロジはClusterControlによって次のように報告されます。

古いマスターが復旧すると、PostgreSQLサービスは自動的にシャットダウンされ、ユーザーが次に行う必要があるのは、ノードアクション>レプリケーションスレーブの再構築> ：

同期操作が完了すると、古いマスターは新しいマスターのスレーブになります。

ClusterControlは、自動リカバリ機能によりデータベースの可用性を確実に向上させ、不良データベースノードの再同期は2回クリックするだけです。壊滅的な障害イベントの後、それはどれほど簡単ですか？

今のところこれですべてです。ハッピークラスタリング！