CentOS7でRedisクラスターを構成する方法

提供：Dev Guides
移動先:案内、検索

序章

RedisはオープンソースのKey-Valueデータストアであり、永続性のためにオプションのディスク書き込みを備えたメモリ内ストレージモデルを使用しています。 トランザクション、pub / sub、自動フェイルオーバーなどの機能を備えています。 実稼働環境ではLinuxでRedisを使用することをお勧めしますが、開発者は、開発およびテストするプラットフォームとしてOSXについても言及しています。 Redisには、ほとんどの言語で記述されたクライアントがあり、推奨されるクライアントはそのWebサイトで紹介されています。

実稼働環境では、少なくとも2つのノード間でデータを複製することがベストプラクティスと見なされます。 冗長性により、環境障害が発生した場合の回復が可能になります。これは、アプリケーションのユーザーベースが拡大する場合に特に重要です。

このガイドの終わりまでに、次のように、DigitalOceanに2つのRedisドロップレットを設定します。

  • Redisマスターサーバー用の1つのドロップレット
  • Redisスレーブサーバー用の1つのドロップレット

また、スレーブサーバーに切り替えて一時マスターとして設定する方法についても説明します。

複数のスレーブサーバーを自由に設定してください。

この記事では、マスタースレーブのRedisクラスターのセットアップに焦点を当てています。 Redisの一般的な使用法とデータベースとしての基本的な使用法の詳細については、この使用法チュートリアルを参照してください。

前提条件

これは以前のリリースや他のLinuxディストリビューションでも機能する可能性がありますが、CentOS7を使用することをお勧めします。

テストの目的で、処理する実際のワークロードがないため、小さなインスタンスを使用しますが、実稼働環境ではより大きなサーバーが必要になる場合があります。

  • CentOS 7
  • 必要なサイズの2つの液滴。 1つのマスターと1つ以上のスレーブ
  • CentOS 7を使用したサーバーの初期設定で説明されているように、sudo非rootユーザーを使用してSSH経由でマシンにアクセスする

ステップ1—Redisをインストールする

マスターサーバーをホストするDropletから始めて、最初のステップはRedisをインストールすることです。 まず、マシンでEPELリポジトリを有効にする必要があります。 慣れていない場合、EPELはエンタープライズLinuxリポジトリ用の追加パッケージであり、RHELベースのディストリビューションのエンタープライズユーザーに高品質のサードパーティパッケージを提供することを目的としてFedoraプロジェクトによって開発されました。 

wget http://dl.fedoraproject.org/pub/epel/7/x86_64/e/epel-release-7-5.noarch.rpm

wgetが認識されない場合は、上記のコマンドの前にyum install wgetを実行してみてください。

今実行します： 

sudo rpm -ivh epel-release-7-5.noarch.rpm

そして今、入力します： 

sudo yum -y update

これが完了するまでに時間がかかる場合があることに注意してください。 これで、次のコマンドを実行して、マシンにRedisをインストールできます。 

sudo yum install redis -y

インストールプロセスが完了したら、次のコマンドを入力してRedisサービスを開始します。 

sudo systemctl start redis.service

また、そのステータスの確認は、次のコマンドで実行できます。 

sudo systemctl status redis.service

これは次のようなものを出力します： 

Outputredis.service - Redis persistent key-value database
   Loaded: loaded (/usr/lib/systemd/system/redis.service; disabled)
  Drop-In: /etc/systemd/system/redis.service.d
           └─limit.conf
   Active: active (running) since Wed 2015-07-22 02:26:31 EDT; 13s ago
 Main PID: 18995 (redis-server)
   CGroup: /system.slice/redis.service
           └─18995 /usr/bin/redis-server 127.0.0.1:6379

最後に、以下を実行してRedisセットアップをテストしましょう。 

redis-cli ping

これにより、応答としてPONGが出力されます。 この場合、サーバーでRedisが実行されているので、構成を開始できます。 セットアップの追加テストは、次のコマンドを実行して実行できます。 

redis-benchmark -q -n 1000 -c 10 -P 5

上記のコマンドは、redis-benchmarkをクワイエットモードで実行し、合計1000のリクエスト、10の並列接続、パイプライン5のリクエストを実行することを示しています。 Redisのベンチマークの実行の詳細については、端末でredis-benchmark --helpと入力すると、例とともに役立つ情報が出力されます。

ベンチマークを実行してみましょう。 完了すると、次のような出力が表示されます。 

OutputPING_INLINE: 166666.67 requests per second
PING_BULK: 249999.98 requests per second
SET: 200000.00 requests per second
GET: 200000.00 requests per second
INCR: 200000.00 requests per second
LPUSH: 200000.00 requests per second
LPOP: 200000.00 requests per second
SADD: 200000.00 requests per second
SPOP: 249999.98 requests per second
LPUSH (needed to benchmark LRANGE): 200000.00 requests per second
LRANGE_100 (first 100 elements): 35714.29 requests per second
LRANGE_300 (first 300 elements): 11111.11 requests per second
LRANGE_500 (first 450 elements): 7194.24 requests per second
LRANGE_600 (first 600 elements): 5050.50 requests per second
MSET (10 keys): 100000.00 requests per second

ここで、Redisスレーブサーバーについてこのセクションを繰り返します。 より多くのドロップレットを構成する場合は、必要な数のスレーブサーバーをセットアップできます。

この時点で、Redisは2つのノードにインストールされて実行されています。 いずれかのノードの出力が上記のようになっていない場合は、セットアッププロセスを慎重に繰り返し、すべての前提条件が満たされていることを確認してください。

ステップ2—Redisマスターを構成する

2つのDropletクラスターでRedisが稼働しているので、構成ファイルを編集する必要があります。 これから説明するように、マスターサーバーとスレーブの構成にはわずかな違いがあります。

まず、マスターから始めましょう。

お気に入りのテキストエディタで/etc/redis.confを開きます。 

sudo vi /etc/redis.conf

次の行を編集します。

TCPのキープアライブタイマーに適切な値を設定します。

/etc/redis.conf 

tcp-keepalive 60

次の行をコメントアウトして、Web上の誰もがサーバーにアクセスできるようにします。

/etc/redis.conf 

#bind 127.0.0.1

Redisの性質とその非常に高速性を考えると、攻撃者は多くの問題なしにパスワードをブルートフォース攻撃する可能性があります。 そのため、requirepass行のコメントを解除し、複雑なパスワード（またはできれば複雑なパスフレーズ）を追加することをお勧めします。

/etc/redis.conf 

requirepass your_redis_master_password

使用シナリオに応じて、次の行を変更するかどうかを指定できます。 このチュートリアルでは、キーの削除が発生してはならないことを前提としています。 この行のコメントを外し、次のように設定します。

/etc/redis.conf 

maxmemory-policy noeviction

最後に、データのバックアップに必要な次の変更を加えます。 コメントを外すか、次のようにこれらの行を設定します。

/etc/redis.conf 

appendonly yes
appendfilename "appendonly.aof"

変更を保存します。

Redisサービスを再起動して、構成の変更を再読み込みします。 

sudo systemctl restart redis.service

マスターサーバーの準備ができたので、スレーブマシンに移りましょう。

ステップ3—Redisスレーブを構成する

スレーブサーバーがマスターインスタンスに接続できるように、いくつかの変更を加える必要があります。

お気に入りのテキストエディタで/etc/redis.confを開きます。 

sudo vi /etc/redis.conf

次の行を編集します。 一部の設定はマスターの設定と同様になります。

次の行をコメントアウトして、Web上の誰もがサーバーにアクセスできるようにします。

/etc/redis.conf 

#bind 127.0.0.1

スレーブサーバーにもパスワードが必要なので、コマンド（INFOなど）を与えることができます。 この行のコメントを解除し、サーバーパスワードを設定します。

/etc/redis.conf 

requirepass your_redis_slave_password

この行のコメントを外し、マスターサーバーに到達できるIPアドレスを示し、その後にそのマシンに設定されているポートを示します。 デフォルトでは、ポートは6379です。

/etc/redis.conf 

slaveof your_redis_master_ip 6379

masterauth行のコメントを解除し、マスターサーバーで以前に設定したパスワード/パスフレーズを入力します。

/etc/redis.conf 

masterauth your_redis_master_password

これらの変更を保存して、ファイルを終了します。 次に、マスターサーバーで行ったようにサービスを再起動します。 

sudo systemctl restart redis.service

これにより、Redisが再初期化され、変更されたファイルが読み込まれます。

Redisに接続します： 

redis-cli -h 127.0.0.1 -p 6379

スレーブサーバーのパスワードを使用して承認します。 

AUTH your_redis_slave_password

この時点で、両方のマシンが適切に構成された、機能的なマスタースレーブRedisクラスターを実行しています。

ステップ4—マスター/スレーブレプリケーションを確認します

セットアップをテストすることで、フェイルオーバー動作のスクリプト作成を開始した後、Redisドロップレットの動作をよりよく理解できるようになります。 ここで実行したいのは、構成が正しく機能していること、およびマスターがスレーブRedisインスタンスと通信していることを確認することです。

まず、マスターサーバーのターミナルを介してRedisに接続します。

最初にローカルインスタンスに接続し、デフォルトでポート6379で実行します。 ポートを変更した場合は、それに応じてコマンドを変更してください。 

redis-cli -h 127.0.0.1 -p 6379

次に、マスターの構成時に設定したパスワードを使用してRedisで認証します。 

AUTH your_redis_master_password

そして、応答としてOKを取得する必要があります。 今、あなたは実行する必要があるだけです： 

INFO

マスターRedisサーバーについて知っておく必要のあるすべてが表示されます。 特に#Replicationセクションに関心があり、次の出力のようになります。 

Output. . .

# Replication
role:master
connected_slaves:1
slave0:ip=111.111.111.222,port=6379,state=online,offset=407,lag=1
master_repl_offset:407
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:406

. . .

connected_slaves:1行に注目してください。これは、他のインスタンスがマスタードロップレットと通信していることを示しています。 また、ポート、状態、およびその他の情報とともに、スレーブIPアドレスを取得していることもわかります。

次に、スレーブマシンの#Replicationセクションを見てみましょう。 プロセスは、マスターサーバーの場合と同じです。 Redisインスタンスにログインし、INFOコマンドを発行して、出力を表示します。 

Output. . .

# Replication
role:slave
master_host:111.111.111.111
master_port:6379
master_link_status:up
master_last_io_seconds_ago:3
master_sync_in_progress:0
slave_repl_offset:1401
slave_priority:100
slave_read_only:1
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

. . .

このマシンにはスレーブの役割があり、マスターRedisサーバーと通信しており、独自のスレーブがないことがわかります。

ステップ5—スレーブに切り替えます

このアーキテクチャを構築するということは、データの整合性を確保し、アプリケーションのダウンタイムをできるだけ少なくするような方法で障害を処理することも望んでいることを意味します。 どのスレーブもマスターに昇格させることができます。 まず、手動で切り替えをテストしてみましょう。

スレーブマシンでは、Redisインスタンスに接続する必要があります。 

redis-cli -h 127.0.0.1 -p 6379

次に、スレーブの構成時に設定したパスワードを使用してRedisで認証します 

AUTH your_redis_slave_password

スレーブの動作をオフにします。 

SLAVEOF NO ONE

応答はOKである必要があります。 次のように入力します。 

INFO

# Replicationセクションを探して、次の出力を見つけます。 

Output. . .

# Replication
role:master
connected_slaves:0
master_repl_offset:1737
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

. . .

予想どおり、スレーブはマスターになり、他のマシン（存在する場合）からの接続を受け入れる準備ができました。 メインマスターサーバーをデバッグする際の一時的なバックアップとして使用できます。

最初のマスターに依存する複数のスレーブがある場合は、それらすべてを新しく昇格したマスターに向ける必要があります。


これは簡単にスクリプト化でき、障害が検出されたら次の手順を実行する必要があります。

  • アプリケーションから、Redisのすべてのリクエストをスレーブマシンに送信します
  • そのスレーブで、SLAVEOF NO ONEコマンドを実行します。 Redisバージョン1.0.0以降、このコマンドは、データの複製を停止し、マスターサーバーとしての機能を開始するようにスレーブに指示します。
  • 残りのすべてのスレーブ（存在する場合）でSLAVEOF hostname portを実行すると、古いマスターからの複製を停止し、廃止されたデータを完全に破棄して、新しいマスターからの複製を開始するように指示されます。 hostnameとportを、新しく昇格したマスターの正しい値に置き換えてください。
  • 問題を分析した後、特定のセットアップで必要な場合は、最初のサーバーをマスターとして使用できるようになります。

上で説明した手順を実行する方法はたくさんあります。 ただし、ご使用の環境に適切なソリューションを実装し、実際の障害が発生する前に徹底的にテストするのはユーザーの責任です。


ステップ6—マスターに再接続します

元のマスターサーバーに再接続しましょう。 スレーブサーバーで、Redisにログインし、以下を実行します。 

SLAVEOF your_redis_master_ip 6379

INFOコマンドを再度実行すると、元の設定に戻ったことがわかります。

結論

1つはRedisマスターとして機能し、もう1つはスレーブとしてデータを複製する2つのサーバーで構成される環境を適切に設定しました。 このようにして、マスターサーバーがオフラインになったり、データが失われたりした場合に、問題が解決するまで、回復のためにスレーブの1つに切り替える方法を知っています。

次のステップには、自動フェイルオーバー手順のスクリプトを作成することや、OpenVPNなどのVPNソリューションを使用してすべてのドロップレット間の安全な通信を確保することが含まれる場合があります。 また、構成を検証するには、テスト手順とスクリプトが不可欠です。

さらに、この種のセットアップを実稼働環境に展開する場合は、予防策を講じる必要があります。 Redisのドキュメントページを調べて、アプリケーションに適したセキュリティモデルを明確に理解する必要があります。 私たちはRedisをセッションストアとして使用することが多く、そこに含まれる情報は攻撃者にとって貴重なものになる可能性があります。 一般的な方法は、これらのマシンにプライベートネットワーク経由でのみアクセスできるようにし、セキュリティの複数のレイヤーの背後に配置することです。

これは、データストアを構築するための簡単な出発点です。 マスタースレーブアーキテクチャを使用するようにRedisを設定するための完全なガイドではありません。 このガイドでカバーすべきと思われることがあれば、以下にコメントを残してください。 このトピックの詳細とヘルプについては、 DigitalOcean Q＆A 始めるのに良い場所です。

「https://www.finddevguides.com/index.php?title=CentOS7でRedisクラスターを構成する方法&oldid=102751」から取得
Powered by MediaWiki