Ubuntu 18.04LTSでDRBD9の分散ストレージを作るメモです。
DRBD(Distributed Replicated Block Device)とは、Linux上でネットワークを介したストレージをリアルタイムにミラーリングするためのソフトウェアです。
何が出来るかと言えば、2台〜4台のコンピュータ間のストレージで完全に同期を取ることが出来ます。
Active/Standbyで動作しているActive側でストレージに書き込みが行われると、ネットワークを介してSlave側のストレージにも書き込みが行われることで、データが同期されるという仕組みです。
また、同期はブロック単位でおこなわれるので、スライス(パーティション)がそっくり同期されます。その為、ファイルシステムに依存しない事も特徴です。(ファイル単位での同期ならrsync使うとか、他にも方法は色々あるけれど)
通常クラスタ構成のシステムでは共有ストレージなど「高価なハードウェア」を使うか、レプリケーションソフトで定期的に同期を行う方式が一般的だと思います。レプリケーションソフトの同期では同期のタイミングによって時間差が生まれてしまうため、同期が取れていないタイミングが発生しますが、DRBDではブロック単位の書き込みをそのままネットワークを介して行いますのでほぼリアルタイムの同期が行えます。
(市販のクラスタソフトウェアでも似たような仕組みを備えている製品があるようだ・・・)
Linuxではクラスタ自体はPacemaker(旧 Heartbeat)で行えますので、複数のコントローラ、複数のパスを備えた高価なストレージを使わずにクラスタのシステムが作れる事になります。とはいえネットワークを介して同期するってことは、ネットワークに相当負荷が掛かるということですので、高パフォーマンスを要求されると厳しい気がします。
仕組み自体は昔からあった(カーネル2.6の頃・・・2009年位?・・・に生まれたらしい)のですが、これまで触ってこなかったので、今更ながらちょっと触ってみましょうという感じです。
前に書き漏れていた項目
ロケール設定
日本語表示にする
$ sudo localectl list-locales
$ sudo apt-get install language-pack-ja
$ sudo update-locale LANG=ja_JP.UTF-8
タイムゾーン設定
JSTにする
$ sudo timedatectl list-timezones
$ sudo timedatectl set-timezone Asia/Tokyo
systemd-timesyncdサービスの停止
ntpdが動かなくなるので止める。
$ sudo systemctl stop systemd-timesyncd.service
$ sudo systemctl disable systemd-timesyncd.service
これまで(UbuntuでProxyサーバロードバランス(1)、UbuntuでProxyサーバロードバランス(2))構築したとおり、Ubuntu Server 12.04LTSを使ってロードバランサーを構築し、Proxyサーバの負荷分散、障害検知と自動での切り離し、組み込みを動作させるところまで構築しました。
残った問題である、ロードバランサーがダウンしたときに結局システムが止まってしまうという問題に対処するため、ロードバランサーをクラスタ構成してみようと思います。
クラスタ構成と言っても色々ありますが、今回はkeepalivedのVRRPをそのまま使ってロードバランサーをActive / Standby型のクラスタにしてしまいます。
単純にロードバランサー2を追加します。そしてProxyサーバの仮想IPアドレス(192.168.100.10)をVRRPによるフローティングアドレスにしてしまいます。
PROXYサーバをLinuxのLVS(ipvsadm)を使って冗長構成にする事を考えました。
LVSは既に使っている(RedHat Enterprise LinuxでWebサーバロードバランス)のですが、ここではWebサーバのバランシングではなく、Proxyサーバのバランシングを行います。
また、前回の検証時はRedHat Enterprise Linux ES3を使って検証を行っていましたが、今回はUbuntu Server 12.04LTSを使います。ipvsadmがディストリビューションに含まれているため、それにあわせてファイルの配置が変更になります。検証機も実機ではなくESXi上に立てることにします。
今回も目的はProxyサーバの耐障害性の向上で、負荷分散を目的とはしていませんが、構築の順序としては負荷分散機能(ipvsadm)→耐障害機能(keepalived)となります。
※Proxyサーバの仮想IPアドレスは192.168.100.10にする
論理的にはロードバランサーがクライアントからの要求をすべて受けて、2台のProxyサーバに振り分ける構成になるため、図のようにロードバランサーの配下にProxyサーバ2台がぶら下がる構成になります。
物理的には同一セグメントでフラットに接続されている構成になります。
ロードバランサーの構成をNATにしてしまうと、ProxyサーバのアクセスログにクライアントのIPアドレスではなく、ロードバランサーのIPアドレスが記録されてしまう弊害がおきるため、構成はDSRにします。この構成の大きなメリットが2つあり、1つ目がソースIPアドレス(クライアントのIPアドレス)がそのままサーバに伝わることと、戻りパケットの処理にロードバランサーが介在しないことで、ロードバランサー自身の負荷が少なくなる事です。 デメリットはリアルサーバ側に若干細工が必要になることですが、今回はPROXYサーバも自前のため、デメリットになりません。
Proxyサーバの待ち受けポートは8080を使用しています。