Docker ベースの Redis 1 マスター、2 スレーブ、3 センチネルの実装

現在、Redis とコンテナについて学習中なので、Docker を使用して Redis マスタースレーブシステムを構築し、理解を深めたいと考えています。この記事を読むには、Docker に関する一定の基礎知識と、Redis のマスター/スレーブおよびセンチネルのメカニズムに関するある程度の理解が必要になる場合があります。

この実験のために 3 つのクラウドホストが用意されました。システムは Debian で、IP アドレスは次のとおりです。

35.236.172.131 、
35.201.200.251、
34.80.172.42.

まず、これら 3 つのホストにそれぞれ docker をインストールし、各ホストで redis コンテナを起動して redis-server サービスを実行します。35.236.172.131 をマスター、他の 2 台のマシンをスレーブとして使用します。最後に、3 つのホストそれぞれで redis コンテナを起動し、redis-sentinel を実行します。なぜまだ Redis コンテナなのでしょうか? sentinel は実際には redis サーバーですが、sentinel モードで実行され、sentinel に必要な一部のコマンドのみを処理できます。

Dockerをインストールする

docker をインストールする方法は多数ありますが、ここでは紹介しません。今回はスクリプトを使ってDockerをインストールします。Debianシステムのスクリプトインストールは以下のとおりです。他のシステムの場合はDocker公式サイトのインストール方法を参考にしてください。

参考: https://docs.docker.com/install/linux/docker-ce/debian/

ただし、国産イメージの方が高速な場合が多いため、以下のコマンドは公式サイトのコマンドをベースにイメージソースをAlibaba Cloudに変更します。

スクリプトインストールdocker

物理ホストまたはクラウド仮想ホストで以下のコマンドを実行して、docker のインストールを完了します。もちろん、私は Debian システムを使用しています。他のシステムの場合は、公式サイトの方法を参照してください。

$ curl -fsSL https://get.docker.com -o get-docker.sh
$ sudo sh get-docker.sh --mirror Aliyun

Docker CEを起動する

Docker はクライアントとサーバーのモデルで実行されるため、最初に Docker サーバーを実行する必要があります。サーバーはデーモンとして実行されます。 Docker CE は Docker のコミュニティバージョンです。

$ sudo systemctl dockerを有効にする
$ sudo systemctl dockerを起動します

Dockerが正常にインストールされていることを確認する

次のコマンドは、公式 Docker リポジトリから hello-world という名前のイメージをプルし、このイメージを使用してコンテナを起動します。

$ docker run hello-world

実行結果が以下の通りであれば、Hello from Docker! と表示され、Docker が正常にインストールされたことがわかります。

$ docker run hello-world
ローカルでイメージ 'hello-world:latest' が見つかりません
最新: library/hello-world から取得
1b930d010525: プル完了 
ダイジェスト: sha256:6540fc08ee6e6b7b63468dc3317e3303aae178cb8a45ed3123180328bcc1d20f
ステータス: hello-world:latest の新しいイメージをダウンロードしました
 
Dockerからこんにちは！
このメッセージは、インストールが正常に動作していることを示しています。
 
このメッセージを生成するために、Docker は次の手順を実行します。
 1. Docker クライアントが Docker デーモンに接続しました。
 2. Docker デーモンは Docker Hub から「hello-world」イメージを取得しました。
  (amd64)
 3. Dockerデーモンは、そのイメージから新しいコンテナを作成し、
  現在読んでいる出力を生成する実行可能ファイル。
 4. Dockerデーモンはその出力をDockerクライアントにストリーミングし、Dockerクライアントはそれを
  端末に。
 
もっと野心的なことに挑戦するには、次のコマンドで Ubuntu コンテナを実行できます。
 $ docker run -it ubuntu bash
 
無料の Docker ID を使用して、イメージを共有したり、ワークフローを自動化したりすることができます。
 参考:
 
その他の例やアイデアについては、以下をご覧ください。
 詳しくはこちら

コンテナを起動してマスターとスレーブを構築する

docker が正常にインストールされたら、redis サービスのデプロイを開始できます。まず、公式の Docker パブリックリポジトリから redis イメージをプルし、次に redis サービスの構成ファイルを変更し、最後にコンテナーを起動して redis サーバーを起動します。複数のマシンで Redis サーバーを実行し、マスターとスレーブの関係を確立します。

Redis のマスタースレーブ構造は、Redis クラスターと Redis Sentinel の高可用性を実現するための基礎です。Redis のマスタースレーブ構造により、スレーブはマスター上のデータを複製できます。スレーブとマスター間のネットワークが切断された場合、スレーブは自動的にマスターに再接続します。

Redisイメージを取得する

次のコマンドは、Redisイメージの最新の公式バージョンを取得します。

$ docker pull redis

ミラーを見る

$ dockerイメージls
リポジトリ タグ イメージ ID 作成 サイズ
redis 最新 bb0ab8a99fe6 7日前 95MB
hello-world 最新 fce289e99eb9 6ヶ月前 1.84kB

Redis設定ファイルを取得して変更する

Redis はサンプル構成ファイルを公式に提供しており、wget ツールを使用してダウンロードできます。 root ユーザーを使用して、/root ディレクトリに直接ダウンロードしました。

$ wget http://download.redis.io/redis-stable/redis.conf

ダウンロードしたファイルを開くと、多くの構成があることがわかります。テスト用にサービスを設定しただけなので、必要な項目のみを変更しました。オンラインで適用する場合は、必要に応じてすべての設定を変更する必要があります。

Redis サーバーのマスターロールとスレーブロールで使用される構成ファイルは若干異なります。これについては以下で説明します。

マスターの場合、設定ファイルは次の項目を変更します。

# この行をコメントアウトして、Redis が任意の IP アドレスからの接続を受け入れることを示します # 127.0.0.1 をバインドします 
 
# 保護モードを無効にする protected-mode no 
 
# Redis サービスをバックグラウンドで実行します daemonize yes 
 
# パスワードを設定します (オプション。ここでパスワード要件を有効にすると、スレーブ構成にパスワードを追加する必要があります。これは単なる練習用構成なので、パスワード認証は使用されません)
# requirepass マスターパスワード 
 
# ログパスを設定します。トラブルシューティングを容易にするために、Redis ログファイルディレクトリ logfile "/var/log/redis/redis.log" を指定します。

スレーブの場合は、構成ファイル内の次の項目を変更します。

# この行をコメントアウトして、Redis が任意の IP アドレスからの接続を受け入れることを示します # 127.0.0.1 をバインドします 
 
# 保護モードを無効にする protected-mode no 
 
# Redis サービスをバックグラウンドで実行します daemonize yes 
 
# パスワードを設定します (オプション。ここでパスワード要件が有効になっている場合は、スレーブ構成にパスワードを追加する必要があります)
requirepass マスターパスワード 
 
# 認証用のマスターデータベースパスワードを設定します。マスターデータベースで requirepass オプションが有効になっている場合は、対応するパスワード masterauth <master-password> を入力する必要があります。
 
# マスターのIPとポート番号を設定します。Redis設定ファイルのデフォルトのポート番号は6379です。
# Redis の以前のバージョンでは、これは同じ意味の slaveof になります。slave はデリケートな言葉なので、slave の概念は Redis のそれ以降のバージョンでは使用されなくなりました。代わりに replica に置き換えられました。
# 35.236.172.131 をマスターとして設定し、他の 2 台のマシンをスレーブとして設定します。 IP とポート番号は、マシンと構成に応じて変更する必要があります。
レプリカ 35.236.172.131 6379
 
# ログパスを設定します。トラブルシューティングを容易にするために、Redis ログファイルディレクトリ logfile "/var/log/redis/redis.log" を指定します。

コンテナを起動する

上記の方法に従って、ホストマシンとスレーブマシンにそれぞれ設定ファイルを作成し、正しいことを確認してからコンテナを起動します。

3 台のマシンでそれぞれコンテナのエイリアスを redis-1、redis-2、redis-3 として指定します。これにより、区別と説明が容易になります。Docker は --name パラメータを使用してコンテナのエイリアスを指定します。 redis-1 はマスター上のコンテナのエイリアスであり、redis-2 と redis-3 は 2 つのスレーブ上のエイリアスです。

以下では、コンテナの起動プロセスを説明するために、redis-3 コンテナを例として使用します。他の 2 台のマシン上のコンテナ redis-1 と redis-2 の動作は同じですが、マスターとスレーブの設定ファイルが異なることに注意してください。ただし、最初にメインサーバー (redis-1 コンテナー) を起動する必要があります。次に、redis-2 と redis-3 を起動します。

# まずコンテナをバックグラウンドモードで実行します $ docker run -it --name redis-3 -v /root/redis.conf:/usr/local/etc/redis/redis.conf -d -p 6379:6379 redis /bin/bash
# コンテナが正常に起動すると、コンテナIDの長い文字列が出力されます。
a3952342094dfd5a56838cb6becb5faa7a34f1dbafb7e8c506e9bd7bb1c2951b
# ps コマンドでコンテナのステータスを確認すると、redis-3 が起動していることがわかります。$ docker ps
コンテナID イメージ コマンド 作成ステータス ポート名
a3952342094d redis "docker-entrypoint.s..." 8 分前 8 分前にアップ 0.0.0.0:6379->6379/tcp redis-3

上記でコンテナが起動しました。次にコンテナに入り、redisサーバーを起動します。

# インタラクティブモードでコンテナ redis-3 に入る
$ docker exec -it redis-3 bash
 
# ログファイルディレクトリを作成する $ mkdir /var/log/redis/
$ touch /var/log/redis/redis.log
 
# redis サーバーを起動します。出力がない場合は成功を意味します。$ redis-server /usr/local/etc/redis/redis.conf
 
# コンテナ内でredisクライアントを起動する $ redis-cli 
 
# infoコマンドを実行してサーバのステータスを表示します 127.0.0.1:6379> info
...
# マスターの場合、ここでのロールの値はマスターになり、スレーブの場合、ここでのロールの値はスレーブになります
役割:スレーブ
# スレーブの場合は、master_link_status 属性値も確認してください。スレーブ上のこの属性の値が up の場合、マスターとスレーブ間のレプリケーションは正常であることを意味します。それ以外の場合は、問題が発生しています。スレーブステータスがアップでない場合は、まずホストポートが制限されているかどうかを確認し、次にredisログをチェックして原因を見つけます。master_link_status: up
...
 
# 最後にコンテナを終了します $ exit

マスタースレーブレプリケーションの検証

マスタースレーブが正常に構築された後、マスターにキー値を書き込んでスレーブに同期されるかどうかを確認することで、マスタースレーブ同期が成功したかどうかを確認できます。

# インタラクティブモードでコンテナ redis-1 に入ります $ docker exec -it redis-1 bash

redis-cliを実行し、test_keyに値を書き込む

$ redis-cli
127.0.0.1:6379> test_key hello-world を設定します
わかりました

任意のスレーブマシンのコンテナーに入り、redis-cli を実行してこのキーの値を照会します。この値を照会でき、ホスト上の値と同じである場合、マスターとスレーブの同期が成功したことを意味します。テストの結果、アクティブ同期は成功しました。

127.0.0.1:6379> テストキーを取得 
"こんにちは世界"

センチネルを追加

マスタースレーブ構造が正常に構築され、システムの可用性が高まりますが、マスターに障害が発生した場合は、スレーブを手動でマスターに切り替える必要があります。この切り替え作業は人的リソースを浪費するだけでなく、マスターとスレーブの切り替え期間中に Redis が外部サービスを提供できなくなるという大きな影響も生じます。そこで、Sentinel システムが開発されました。マスターに障害が発生すると、Sentinel は自動的にフェイルオーバーを実行し、スレーブの 1 つを選択してマスターにアップグレードし、元のマスターの監視を継続します。元のマスターが回復すると、新しいマスターのスレーブとして使用されます。

センチネルはまずマスターを監視し、マスターに info コマンドを送信してスレーブの情報を取得し、次にスレーブも監視します。さらに、センチネルはマスターと同様に__sentinel__:helloチャネルをサブスクライブします。新しいセンチネルが参加すると、このチャネルにメッセージが送信されます。このメッセージには、センチネルの IP とポート情報が含まれています。その後、チャネルをサブスクライブしている他のセンチネルはこのメッセージを受信し、新しいセンチネルが参加したことを認識します。

これらのセンチネルは新しく参加したセンチネルとの接続を確立し、リーダー選挙はこの接続を通じて投票する必要があります。この関係は次の図で説明できます。

センチネル設定ファイルを取得して変更する

wgetコマンドでセンチネル設定ファイルを取得する

http://download.redis.io/redis-stable/sentinel.conf を取得します。

次の設定ファイルを変更します

# センチネルサービスをバックグラウンドで実行します。デーモン化します。はい 
 
# ログファイルパス logfile "/var/log/redis/sentinel.log" を変更します
 
# 監視対象のメイン Redis サーバーを変更します。# 最後の 2 つは、2 台のマシンがアクティブ サーバーとパッシブ サーバーがオフラインであると判断すると、フェイルオーバーが実行されることを意味します。
センチネルモニター マイマスター 35.236.172.131 6379 2

コンテナを起動する

redisコンテナの起動と同様に、sentinelというエイリアスのコンテナを起動します。

$ docker run -it --name sentinel -p 26379:26379 -v /root/sentinel.conf:/usr/local/etc/redis/sentinel.conf -d redis /bin/bash

センチネルを実行する

# コンテナに入る$ docker exec -it sentinel bash
 
# ログディレクトリとファイルを作成する $ mkdir /var/log/redis
$ touch /var/log/redis/sentinel.log
 
# センチネル redis-sentinel を起動します /usr/local/etc/redis/sentinel.conf 
 
# ログを確認すると、センチネルは 1 つのマスターと 2 つのスレーブを正常に監視しました 18:X 2019 年 7 月 11 日 13:25:55.416 # +monitor master mymaster 35.236.172.131 6379 quorum 2
18:X 2019年7月11日 13:25:55.418 * +スレーブ スレーブ 35.201.200.251:6379 35.201.200.251 6379 @ mymaster 35.236.172.131 6379
18:X 2019年7月11日 13:25:55.421 * +スレーブ スレーブ 34.80.172.42:6379 34.80.172.42 6379 @ マイマスター 35.236.172.131 6379

他の 2 台のマシンでも、同じ方法でコンテナ内の Sentinel を実行します。Sentinel は同じ構成ファイルを使用します。

フェイルオーバーを確認する

センチネルメカニズムによるマスターとスレーブの自動切り替えを確認するために、マスター上の redis プロセスを強制終了します。

数秒後、別のスレーブがマスターにアップグレードされます。実験では、3 番目のマシン redis-3 がマスターにアップグレードされます。info コマンドを使用してクエリを実行すると、redis-3 サーバーの役割がマスターになったことがわかります。これは、自動マスター/スレーブ切り替えが成功したことを示します。

127.0.0.1:6379>情報
...
# レプリケーション
役割:マスター
...

次に、先ほど停止したマスターサーバーを再起動します。再起動後、info コマンドを使用して確認すると、redis-3 のスレーブサーバーになっていることがわかります。

次のログは、35.236.172.131 がマスターとして起動し、フェイルオーバー用のマスターセンチネルを選択し、フェイルオーバーを実行し、新しいマスターとスレーブの関係を確立する様子を示しています。

root@4355ca3260c5:/var/log/redis# cat sentinel.log 
17:X 2019年7月11日 13:25:55.395 # oO0OoO0OoO0Oo Redis が起動しています oO0OoO0OoO0Oo
17:X 2019 年 7 月 11 日 13:25:55.395 # Redis バージョン = 5.0.5、ビット = 64、コミット = 00000000、変更 = 0、pid = 17、開始しました
17:X 2019年7月11日 13:25:55.395 # 設定が読み込まれました
18:X 2019年7月11日 13:25:55.398 * 実行モード=sentinel、ポート=26379。
18:X 2019 年 7 月 11 日 13:25:55.398 # 警告: /proc/sys/net/core/somaxconn が 128 という低い値に設定されているため、TCP バックログ設定 511 を適用できません。
18:X 2019年7月11日 13:25:55.416 # センチネルIDは7d9a7877d4cffb6fec5877f605b975e00e7953c1です
18:X 2019年7月11日 13:25:55.416 # +モニターマスター mymaster 35.236.172.131 6379 クォーラム 2
18:X 2019年7月11日 13:25:55.418 * +スレーブ スレーブ 35.201.200.251:6379 35.201.200.251 6379 @ mymaster 35.236.172.131 6379
18:X 2019年7月11日 13:25:55.421 * +スレーブ スレーブ 34.80.172.42:6379 34.80.172.42 6379 @ マイマスター 35.236.172.131 6379
18:X 2019年7月11日 13:26:25.460 # +sdown スレーブ 35.201.200.251:6379 35.201.200.251 6379 @ mymaster 35.236.172.131 6379
18:X 2019年7月11日 14:04:23.390 * +sentinel sentinel 09aa7d2098ad2dc52e6e07d7bc6670f00f5ff3e3 172.17.0.3 26379 @ mymaster 35.236.172.131 6379
18:X 2019年7月11日 14:04:25.418 * +sentinel-invalid-addr センチネル 09aa7d2098ad2dc52e6e07d7bc6670f00f5ff3e3 172.17.0.3 26379 @ mymaster 35.236.172.131 6379
18:X 2019年7月11日 14:04:25.418 * +sentinel sentinel 7d9a7877d4cffb6fec5877f605b975e00e7953c1 172.17.0.3 26379 @ mymaster 35.236.172.131 6379
18:X 2019年7月11日 14:04:25.456 * +sentinel-address-switch マスター mymaster 35.236.172.131 6379 ip 172.17.0.3 ポート 26379 09aa7d2098ad2dc52e6e07d7bc6670f00f5ff3e3
18:X 2019年7月11日 14:08:34.338 * +sentinel-invalid-addr センチネル 09aa7d2098ad2dc52e6e07d7bc6670f00f5ff3e3 172.17.0.3 26379 @ mymaster 35.236.172.131 6379
18:X 2019年7月11日 14:08:34.338 * +sentinel sentinel 28d3c0e636fa29ac9fb5c3cc2be00432c1b0ead9 172.17.0.3 26379 @ mymaster 35.236.172.131 6379
18:X 2019年7月11日 14:08:36.236 * +sentinel-address-switch マスター mymaster 35.236.172.131 6379 ip 172.17.0.3 ポート 26379 09aa7d2098ad2dc52e6e07d7bc6670f00f5ff3e3
18:X 2019年7月11日 14:11:12.151 # +sdown マスター mymaster 35.236.172.131 6379
18:X 2019年7月11日 14:11:12.214 # +odown マスター mymaster 35.236.172.131 6379 #定足数 4/2
18:X 2019年7月11日 14:11:12.214 # +新エポック1
18:X 2019年7月11日 14:11:12.214 # +try-failover マスター mymaster 35.236.172.131 6379
18:X 2019年7月11日 14:11:12.235 # +リーダーに投票 7d9a7877d4cffb6fec5877f605b975e00e7953c1 1
18:X 2019年7月11日 14:11:12.235 # 7d9a7877d4cffb6fec5877f605b975e00e7953c1 は 7d9a7877d4cffb6fec5877f605b975e00e7953c1 に投票しました 1
18:X 2019年7月11日 14:11:12.235 # 28d3c0e636fa29ac9fb5c3cc2be00432c1b0ead9 が 7d9a7877d4cffb6fec5877f605b975e00e7953c1 に投票しました 1
18:X 2019年7月11日 14:11:12.235 # 09aa7d2098ad2dc52e6e07d7bc6670f00f5ff3e3 が 7d9a7877d4cffb6fec5877f605b975e00e7953c1 に投票しました 1
18:X 2019年7月11日 14:11:12.294 # +選出リーダー マスター mymaster 35.236.172.131 6379
18:X 2019年7月11日 14:11:12.294 # +フェイルオーバー状態選択スレーブマスター mymaster 35.236.172.131 6379
18:X 2019年7月11日 14:11:12.394 # -failover-abort-no-good-slave master mymaster 35.236.172.131 6379
18:X 2019年7月11日 14:11:12.453 # 次のフェイルオーバー遅延: 2019年7月11日木曜日 14:17:12 より前にフェイルオーバーを開始しません
18:X 2019年7月11日 14:11:13.050 # +config-update-from sentinel 28d3c0e636fa29ac9fb5c3cc2be00432c1b0ead9 172.17.0.3 26379 @ mymaster 35.236.172.131 6379
18:X 2019年7月11日 14:11:13.050 # +switch-master mymaster 35.236.172.131 6379 34.80.172.42 6379
18:X 2019年7月11日 14:11:13.050 * +スレーブ スレーブ 35.201.200.251:6379 35.201.200.251 6379 @ mymaster 34.80.172.42 6379
18:X 2019年7月11日 14:11:13.050 * +スレーブ スレーブ 35.236.172.131:6379 35.236.172.131 6379 @ mymaster 34.80.172.42 6379
18:X 2019年7月11日 14:11:43.077 # +sdown スレーブ 35.236.172.131:6379 35.236.172.131 6379 @ mymaster 34.80.172.42 6379
18:X 2019年7月11日 14:11:43.077 # +sdown スレーブ 35.201.200.251:6379 35.201.200.251 6379 @ mymaster 34.80.172.42 6379
18:X 2019年7月12日 01:54:05.142 # -sdown スレーブ 35.236.172.131:6379 35.236.172.131 6379 @ mymaster 34.80.172.42 6379
18:X 2019年7月12日 01:54:15.087 * +convert-to-slave スレーブ 35.236.172.131:6379 35.236.172.131 6379 @ mymaster 34.80.172.42 6379

要約する

Redis はマスターとスレーブのレプリケーションによって高可用性を実現しますが、障害が発生すると手動でマスターとスレーブを切り替える必要があり、非効率的です。センチネルメカニズムは、Redis マスターとスレーブの自動切り替えを実現し、Redis クラスターの可用性を向上させ、Redis クラスターのフェイルオーバー効率を向上させます。

以上がこの記事の全内容です。皆様の勉強のお役に立てれば幸いです。また、123WORDPRESS.COM を応援していただければ幸いです。

以下もご興味があるかもしれません: