16.04前書きRedisはオープンソースのキーと値のデータストアであり、永続化のためにオプションのディスク書き込みを伴うメモリ内ストレージモデルを使用します。subメッセージングパターン、および他の機能の中での自動フェールオーバーを備えています。[彼らのウェブサイト]で紹介されています。実稼働環境では、少なくとも2つのノード間でデータを複製することがベストプラクティスと見なされます。これにより、環境障害が発生した場合の回復が可能になります。これは、アプリケーションのユーザーベースが拡大する場合に特に重要です。本番データを変更したり、パフォーマンスに影響を与えたりすることなく、本番データと安全に対話できます。16.04を実行している2つのサーバー間でレプリケーションを構成します。このプロセスは、必要に応じてより多くのサーバーに簡単に適合させることができます。16.04サーバーにアクセスする必要があります。*サーバーと呼びます。+`権限を持つ非rootユーザーが必要です。このガイドでは、基本的なファイアウォールが設定されていることを前提としています。16.04初期サーバーセットアップガイドに従ってこれらの要件を満たすことができます。開始する準備ができたら、このガイドに進みます。*サーバーの両方にインストールします。PPAを使用して、最新のRedisサーバーパッケージをインストールします。サードパーティのリポジトリを有効にするときは常に注意してください。Leaは多くの高品質パッケージを管理する定評のあるパッケージャーです。最初に、PPAを両方のサーバーに追加します。+`を押してリポジトリを受け入れます。次に、次のように入力して、サーバーのローカルパッケージインデックスを更新し、Redisサーバーパッケージをインストールします。redis-serverこれにより、Redisサーバーがインストールされ、サービスが開始されます。次のように入力して、Redisが稼働していることを確認します。ping次の応答が返されます。OutputPONGこれは、Redisが実行中であり、ローカルクライアントからアクセス可能であることを示しています。ステップ2:2つのサーバー間のトラフィックを保護するレプリケーションを設定する前に、Redisのセキュリティモデルの意味を理解することが重要です。Redisはネイティブ暗号化オプションを提供せず、信頼できるピアのプライベートネットワークに展開されていると想定しています。Redisが分離されたネットワークに展開されている場合...サーバーが分離されたネットワークで動作している場合、おそらく分離されたネットワークIPアドレスにバインドするようにRedisの構成ファイルを調整するだけで済みます。各コンピューターでRedis構成ファイルを開きます。+」行を見つけて、サーバー独自の分離されたネットワークIPアドレスを追加します。127.0.0.1ファイルを保存して閉じます。次を入力してサービスを再起動します。redis-server.serviceRedisポートへのアクセスを開きます。+`コマンドに代替サーバーのIPアドレスを提供することで、一方のサーバーから他方のサーバーにアクセスできるようになります。pingOutputPONGRedisは、分離されたネットワークからの接続を受け入れることができるようになりました。Redisが分離されたネットワークに展開されていない場合...分離されていないネットワークや制御できないネットワークの場合、トラフィックを他の手段で保護することが不可欠です。Redisサーバー間のトラフィックを保護するには、次のような多くのオプションがあります。[stunnelによるトンネリング]:着信および発信が必要になります各サーバーのトンネル。例は、ガイドの下部にあります。spiped:2つのsystemdを作成する必要がありますサーバーごとのユニットファイル。1つはリモートサーバーとの通信用、もう1つは独自のRedisプロセスへの接続の転送用です。詳細はガイドの下部に記載されています。PeerVPNを使用したVPNのセットアップ:両方のサーバーが必要になりますVPNでアクセスできるようにします。上記の方法のいずれかを使用して、Redisマスターサーバーとスレーブサーバー間の安全な通信方法を確立します。各マシンがピアのRedisサービスに安全に接続するために必要なIPアドレスとポートを知っている必要があります。ステップ3:Redisマスターを設定するRedisが各サーバーで稼働し、安全な通信チャネルが確立されたので、構成ファイルを編集する必要があります。*マスター*として機能するサーバーから始めましょう。+`設定を見つけて60秒に設定することから始めます。これは、Redisがネットワークまたはサービスの問題を検出するのに役立ちます。+`ディレクティブを見つけて、強力なパスフレーズに設定します。Redisトラフィックは外部からのセキュリティで保護されている必要がありますが、これによりRedis自体への認証が提供されます。Redisは高速であり、パスワード試行を制限しないため、ブルートフォース攻撃から保護するために強力で複雑なパスフレーズを選択します。/etc/redis/redis.confrequirepass最後に、使用シナリオに応じて調整したいオプション設定がいくつかあります。Redisがいっぱいになったときに古いキーや使用頻度の低いキーを自動的に削除しないようにするには、自動キー削除をオフにできます。/etc/redis/redis.confmaxmemory-policy耐久性の保証を改善するために、追加のみのファイル永続性をオンにできます。これにより、システム障害が発生した場合のデータ損失を最小限に抑えることができますが、ファイルが大きくなり、パフォーマンスがわずかに低下します。""終了したら、ファイルを保存して閉じます。Redisサービスを再起動して、構成の変更を再読み込みします。redis-server.serviceマスターサーバーが構成されたので、少し時間をかけてテストしてください。ステップ4:RedisマスターをテストするRedisクライアントを起動して、設定したパスワードを使用して認証できることを確認します。replication次の応答が返されます。required.これは予想されることであり、Redisサーバーが認証されていないリクエストを正しく拒否していることを示しています。+`コマンドを使用して認証します:auth資格情報が受け入れられたことの確認を受信する必要があります。outputOKコマンドを再試行すると、今回は成功するはずです。Replicationrole:masterconnected_slaves:0master_repl_offset:0repl_backlog_active:0repl_backlog_size:1048576repl_backlog_first_byte_offset:0repl_backlog_histlen:0認証されている間に、後で複製を確認できるようにテストキーを設定します。server'終了したら、オペレーティングシステムシェルに戻ります。exitマスターサーバーの準備ができたので、スレーブマシンに移りましょう。ステップ5:Redisスレーブを構成する次に、*スレーブサーバー*がマスターインスタンスに接続できるように、いくつかの変更を行う必要があります。+`行を見つけてコメント解除します。このディレクティブは、スペースで区切られたマスターRedisサーバーに安全に接続するために使用するIPアドレスとポートを取ります。デフォルトでは、Redisサーバーはローカルインターフェースで6379をリッスンしますが、各ネットワークセキュリティメソッドは外部の関係者のデフォルトを何らかの方法で変更します。使用する値は、ネットワークトラフィックを保護するために使用した方法によって異なります。8000+」になります)。10.8.0」になります。一般的な形式は次のとおりです。/etc/redis/redis.confmasterauth不正アクセスを防ぐために、スレーブサーバーのパスワードを設定します。パスワードの複雑さに関する同じ警告がここに適用されます。/etc/redis/redis.confrequirepass完了したら、ファイルを保存して閉じます。+`キーが設定されていないことを確認しましょう。redis-cli次のように入力して、キーを照会します。test次の応答が返されます。test」という名前のキーがないことを示しています。次のように入力して、シェルに戻ります。exitこれらの変更を実装するには、スレーブでRedisサービスを再起動します。redis-server.serviceこれにより、Redisスレーブ設定ファイルに加えたすべての変更が適用されます。ローカルのRedisインスタンスに再度再接続します。required.次に、最後のセクションで設定したRedisスレーブのパスワードを使用して認証します。outputOK今回キーにアクセスしようとすると、キーが利用可能であることがわかります。server"スレーブでRedisサービスを再起動すると、すぐにレプリケーションが開始されました。`コマンドで確認できます。このコマンドは、レプリケーションに関する情報を報告します。+`オプションに使用した引数と一致する必要があります。Replicationrole:slavemaster_host:master_port:master_link_status:upmaster_last_io_seconds_ago:5master_sync_in_progress:0slave_repl_offset:1387slave_priority:100slave_read_only:1connected_slaves:0master_repl_offset:0repl_backlog_active:0repl_backlog_size:1048576repl_backlog_first_byte_offset:0repl_backlog_histlen:0Redisマスターサーバーで同じ情報を見ると、次のようなものが表示されます。Replicationrole:masterconnected_slaves:1slave0:ip=,port=,state=online,offset=1737,lag=1master_repl_offset:1737repl_backlog_active:1repl_backlog_size:1048576repl_backlog_first_byte_offset:2repl_backlog_histlen:1736ご覧のとおり、マスターサーバーとスレーブサーバーは、定義された関係で互いに正しく識別します。ステップ7:Redisスレーブをマスターにプロモートするレプリケーションを設定する主な理由は、最小限のデータ損失とダウンタイムで障害を処理することです。Redisマスターに障害が発生した場合、Redisスレーブをマスターステータスに昇格して書き込みトラフィックを処理できます。Redisスレーブを手動で昇格するこれは、Redisスレーブサーバーから手動で行うことができます。Redisクライアントでログインします。redis-cliRedisスレーブパスワードを使用して認証します。authRedisスレーブを昇格する前に、テストキーを上書きしてみてください。+`オプションで読み取り専用に設定されているため、これは失敗するはずです。+」コマンドを使用します。outputOK複製情報を再度確認します。Replicationrole:masterconnected_slaves:0master_repl_offset:6749repl_backlog_active:0repl_backlog_size:1048576repl_backlog_first_byte_offset:0repl_backlog_histlen:0ご覧のとおり、スレーブはRedisマスターに指定されています。キーをもう一度上書きしてみてください。今回は成功するはずです。outputOK構成ファイルはまだこのノードをRedisスレーブとして指定しているため、構成を変更せずにサービスを再起動すると、レプリケーションが再開されることに注意してください。Redisマスターに使用した設定をここで再適用する必要がある場合があることに注意してください(たとえば、追加専用ファイルをオンにする、またはエビクションポリシーを変更する)。他のスレーブがある場合は、新しく昇格したマスターをポイントして、変更の複製を続行します。+」コマンドと新しいマスターの接続情報を使用して実行できます。+`コマンドを使用して、暫定マスターとスレーブを元のマスターに戻します。outputOKスレーブのキーをもう一度確認すると、Redisマスターによって元の値が復元されていることがわかります。server"一貫性の理由から、スレーブ上のすべてのデータは、マスターサーバーと再同期されるときにフラッシュされます。Redisスレーブを自動的にプロモートするRedisスレーブを自動的にプロモートするには、アプリケーション層との調整が必要です。実装はアプリケーション環境に大きく依存するため、特定のアクションを提案することは困難です。自動フェールオーバーを実現するために必要な一般的な手順を確認できます。以下の手順は、すべてのRedisサーバーが相互にアクセスするように構成されていることを前提としています。アプリケーションから、マスターサーバーが使用できなくなったことを検出します。+」コマンドを実行します。これにより、レプリケーションが停止し、マスター状態に昇格します。新しいマスターの設定を調整して、以前のマスター設定に合わせます。これは、ほとんどのオプションの構成ファイルで事前に行うことができます。アプリケーションから新しく昇格されたRedisマスターにトラフィックを転送します。これにより、スレーブは古いマスターからの複製を停止し、それらの(現在では廃止された)データを完全に破棄し、新しいマスターからの複製を開始します。元のマスターサーバーにサービスを復元した後、新しく昇格したマスターを指すスレーブとして再参加することを許可するか、必要に応じてマスターとしての職務を再開することができます。結論Redisマスターとして機能するサーバーとスレーブとしてデータを複製するサーバーの2つのサーバーで構成される環境をセットアップしました。これにより、システムまたはネットワークに障害が発生した場合に冗長性が提供され、パフォーマンス上の理由から複数のサーバー間で読み取り操作を分散できます。これは、実稼働アプリケーションとインフラストラクチャのニーズに合わせてRedis構成を設計するための適切な出発点ですが、決して主題に関する包括的なガイドではありません。[その他のRedisチュートリアル]をご覧ください。