【Redisノート】第5編:redisモニタツール-redis sentinel使用説明及び注意事項
前の4つのノートを通じて、redisの基本的な概念と配置についてすでに理解していると信じています.このノートは、公式に発表されたredis sentinelツールを通じてredisの運行状態を監視する方法を重点的に説明しています.またsentinelの使用中の注意点について議論します.
1.Redis Sentine機能Redis Sentineは、Redisインスタンスを管理するための分散システムで、主に3つのタスクを完了する:1)Monitoring:Redis masterまたはslaveインスタンスの実行状況が予想通りかどうかを継続的に監視する2)Notification:監視されたRedisインスタンスが異常に実行された場合、sentinelはAPIを通じて外部(人またはプログラム)に通知します
3)Automation failover:masterインスタンスが障害が発生した場合、sentinelはマスターを再選択して自動障害切替を開始します.slave-priorityが最も小さいslaveインスタンスを選択してmasterに昇格し、他のslaveの構成を変更してmaster構成項目が新しいmasterを指し、old masterが再起動するとnew masterのslaveに自動的に降格します.最後に、構成に従って、Redis Sentineは、現在Redisにアクセスしているアプリケーションに新しいmasterアドレスを通知します.
2.Redis Centinelは、分散システムツールとしてCentinelを導入し、マルチマシンルームのマルチマシン導入を推奨します.
2.1 sentinelプロファイル
各sentinelインスタンスには主に6つの構成項目があり、Redisクラスタの実際の配置状況に応じて構成すればよい.例は以下の通りである.
ここで、port:sentinelのリスニングポート(すなわちredis serverまたはclientとtcp接続を確立するポート)monitorを指定する:sentinelがmonitorを必要とするredisインスタンスを指定し、redisインスタンスの別名(alias)とredisインスタンスのip+portを含む.この行の最後の数字2は、少なくとも2つのsetinelインスタンスがredis server異常を同時に検出した場合、redis serverの状態をreal failと判定した.すなわち、ここで2に構成されているが、実際の配置でsentinelが1セットしか配置されていない場合、redisインスタンスが削除されてもsentinelは警告を与えない.この点は特に注意しなければならない.down-after-milliseconds:sentinelがredisインスタンスに異常がどのくらい続くかを監視した後、その状態がdownであると判定するかを指定します.実際のビジネスでsentinelがredisインスタンスの異常をできるだけ早く判定する必要がある場合、この値は適切に小さくすることができます.failover-timeout:sentinelがこの構成値内でfailover操作(すなわち、障害時にmaster/slave自動切替)を完了できなかった場合、今回のfailoverは失敗したとみなされます.この構成は4つの用途がある、具体的にはsentinelを参照することができる.confの説明は、紙面に限られており、ここでは省略する.parallel-syncs:sentinel reconfigureの最大slaveインスタンス数であるfailoverプロシージャを指定します.reconfigureでは、対応するslaveがクライアント要求への応答を中断するため、すべてのslaveが同時に使用できないように、この値を適切に小さくする必要があります.notification-script:sentinelがmaster-nameが指すインスタンス異常を検出した場合に呼び出されるアラームスクリプトを指定します.この構成項目はオプションですが、オンラインシステムでは構成を推奨します.
2.2モニタリングシステム構成ファイルの修正が完了したら、各モニタリングプロセスを起動すればよい.例えば:
2.3 sentinelはシーン実測を用いてsentinelの使い方を調査研究し、把握した.私はredisテスト環境を構築し、一連の実験を行った.以下、実験状況を詳しく説明する.特に、以下の内容は社内ネットワークアドレスにかかわる可能性があるため、不要なトラブルを避けるために、文字やスクリーンショットにipアドレスが表示される箇所を塗りましたが、説明の問題には影響しません.実験環境(one master/two slaves/two sentinels):a.1つのmaster(slave-priorityは100)はipでxx.xx.234.67の機械で;b.両方のslaves(slave-priorityはそれぞれ90/100)の配置はipがxxである.xx.234.49の機械の上で;c.2つのsentinelプロセスモニタredisクラスタ状態を有効にして6種類のcaseのテストを行った結果、Case 1:masterプロセスと2つのslaveプロセスを順次起動した後、2つのsentinelプロセスを起動し、sentinelは主従関係Case 2:shutdownコマンドでmasterを停止することができることを正常に認識した.sentinelはslave-priorityの小さいslaveプロセスを自動的に選択してnew masterになります.同時に、別のslaveプロセスのmasterを自動的にこのnew master Case 3:case 2に基づいてold masterを再起動し、sentinelはそれをslaveに降格します.そのマスターはcase 2が選択した新しいマスターCase 4:マスターと2つのslaveインスタンスのslave-priorityを互いに異なる値に割り当て、Case 1に基づいてshutdownの現在のマスターは、sentinelが新しいマスターを選択し、reconfigureの他のインスタンスが新しいマスターを指すようになった後(old master異常からsentinel再選択をトリガーするまでの時間はsentinel.confのdown-after-milliseconds構成項目によって指定されます)、old masterを再起動します.システムの最終状態はCase 3と一致します.すなわち、old masterはslaveに降格し、そのmasterはsentinelが選択した新しいマスターを指します.sentinelが新しいマスターを選択したが、他のインスタンスのreconfigureが完了していない前にold masterを再起動すると、new masterを選択できない異常がシステム全体に発生します.詳細は、次のCase 5の説明を参照してください.Case 5:masterと2つのslaveインスタンスのslave-priorityを同じ値にします.Case 1に基づいて、shutdownの現在のmasterは、sentinelが新しいマスターを選択し、reconfigureの他のインスタンスが新しいマスターを指すようにした後、old masterを再起動します.システムの最終状態はCase 3と同じです.つまり、old masterはslaveに降格し、そのmasterはsentinelが選択した新しいマスターを指します.すべてのslave-priorityが同じ値に構成されている場合、sentinelは、slaveインスタンスのrunidの最小slaveをmasterに昇格させます(slaveに対応するredis.confでpromoteがmasterであることが許可されている場合).Case 4で発生した異常と同様に、sentinelが新しいマスターを選択したが、他のインスタンスのreconfigureが完了していない前にold masterを再起動すると、sentinelの自動フェイルオーバーメカニズムが乱れていることがわかります.詳細な異常は以下の通りです.old masterはipがxxである.xx.234.67のマシン上でportのデフォルトは6379である、sentinel切替異常後、このold masterに対してinfoコマンドを実行する出力は以下の通りである:slave-00インスタンスはipがxxである.xx.234.49の機器にポートが6378、sentinel切替異常後、info出力は以下の通りである:slave-01の例はipがxxである.xx.234.49のマシン(slave-00と同じマシンに配備されている)に6377が搭載されており、info出力は以下の通りである:上の3つのredisインスタンスの出力状況から見ると、3つはいずれも自分がslaveだと思っており、システム全体に所有者がいない!ここで、xxに位置する.xx.234.67のold master(上の第1図のmaster_hostフィールドに注意)とxxに位置する.xx.234.49のsalve-00(上の第2図のmaster_hostフィールドに注意)は、slave-01がnew masterであり、xxに位置すると考える.xx.234.49のslave-01は自分がまだslaveだと思って、old masterは今まだmasterだと思っています
(上記第3図のmaster_hostフィールドに注意)
. sentinelプロセスログから見ると、sentinelは新しいマスターを選択できません.つまり、sentinelは2つのマスターcandidatesがどれがnewマスターなのかを確認できません.2つのインスタンス間で頻繁に切り替えます.このような状況は、実際のメンテナンス時に注意する必要があります.
Case 6:
システムがCase 5に示す異常状態に入った後も、shutdownの2つのmaster candidatesの1つのインスタンスでは、sentinelは3つのインスタンスがすべてshutdownになるまで正常にプライマリを選択できず、システム全体にプライマリが存在しません.モニタリングシステム内部の論理状態が混乱していることを基本的に決定することができる.
2.4結論:masterインスタンスが故障した場合、sentinelがnew masterを選択して安定した後(新しいマスターを選択して切替を完了する時間は構成と関係があり、典型的な値は1分以内)、old masterを再起動し、sentinelの誤審を引き起こすことを避け、システム全体がnew masterを選択できないことが望ましい.
【参考資料】1. Redis Sentinel Documentation
=================== EOF ==================
1.Redis Sentine機能Redis Sentineは、Redisインスタンスを管理するための分散システムで、主に3つのタスクを完了する:1)Monitoring:Redis masterまたはslaveインスタンスの実行状況が予想通りかどうかを継続的に監視する2)Notification:監視されたRedisインスタンスが異常に実行された場合、sentinelはAPIを通じて外部(人またはプログラム)に通知します
3)Automation failover:masterインスタンスが障害が発生した場合、sentinelはマスターを再選択して自動障害切替を開始します.slave-priorityが最も小さいslaveインスタンスを選択してmasterに昇格し、他のslaveの構成を変更してmaster構成項目が新しいmasterを指し、old masterが再起動するとnew masterのslaveに自動的に降格します.最後に、構成に従って、Redis Sentineは、現在Redisにアクセスしているアプリケーションに新しいmasterアドレスを通知します.
2.Redis Centinelは、分散システムツールとしてCentinelを導入し、マルチマシンルームのマルチマシン導入を推奨します.
2.1 sentinelプロファイル
各sentinelインスタンスには主に6つの構成項目があり、Redisクラスタの実際の配置状況に応じて構成すればよい.例は以下の通りである.
port 26329
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 60000
sentinel failover-timeout mymaster 180000
sentinel parallel-syncs mymaster
sentinel notification-script <master-name> <script-path>ここで、port:sentinelのリスニングポート(すなわちredis serverまたはclientとtcp接続を確立するポート)monitorを指定する:sentinelがmonitorを必要とするredisインスタンスを指定し、redisインスタンスの別名(alias)とredisインスタンスのip+portを含む.この行の最後の数字2は、少なくとも2つのsetinelインスタンスがredis server異常を同時に検出した場合、redis serverの状態をreal failと判定した.すなわち、ここで2に構成されているが、実際の配置でsentinelが1セットしか配置されていない場合、redisインスタンスが削除されてもsentinelは警告を与えない.この点は特に注意しなければならない.down-after-milliseconds:sentinelがredisインスタンスに異常がどのくらい続くかを監視した後、その状態がdownであると判定するかを指定します.実際のビジネスでsentinelがredisインスタンスの異常をできるだけ早く判定する必要がある場合、この値は適切に小さくすることができます.failover-timeout:sentinelがこの構成値内でfailover操作(すなわち、障害時にmaster/slave自動切替)を完了できなかった場合、今回のfailoverは失敗したとみなされます.この構成は4つの用途がある、具体的にはsentinelを参照することができる.confの説明は、紙面に限られており、ここでは省略する.parallel-syncs:sentinel reconfigureの最大slaveインスタンス数であるfailoverプロシージャを指定します.reconfigureでは、対応するslaveがクライアント要求への応答を中断するため、すべてのslaveが同時に使用できないように、この値を適切に小さくする必要があります.notification-script:sentinelがmaster-nameが指すインスタンス異常を検出した場合に呼び出されるアラームスクリプトを指定します.この構成項目はオプションですが、オンラインシステムでは構成を推奨します.
2.2モニタリングシステム構成ファイルの修正が完了したら、各モニタリングプロセスを起動すればよい.例えば:
nohup ./bin/redis-sentinel ./conf/sentinel.conf > ./log/redis-sentinel.log 2>&1 &2.3 sentinelはシーン実測を用いてsentinelの使い方を調査研究し、把握した.私はredisテスト環境を構築し、一連の実験を行った.以下、実験状況を詳しく説明する.特に、以下の内容は社内ネットワークアドレスにかかわる可能性があるため、不要なトラブルを避けるために、文字やスクリーンショットにipアドレスが表示される箇所を塗りましたが、説明の問題には影響しません.実験環境(one master/two slaves/two sentinels):a.1つのmaster(slave-priorityは100)はipでxx.xx.234.67の機械で;b.両方のslaves(slave-priorityはそれぞれ90/100)の配置はipがxxである.xx.234.49の機械の上で;c.2つのsentinelプロセスモニタredisクラスタ状態を有効にして6種類のcaseのテストを行った結果、Case 1:masterプロセスと2つのslaveプロセスを順次起動した後、2つのsentinelプロセスを起動し、sentinelは主従関係Case 2:shutdownコマンドでmasterを停止することができることを正常に認識した.sentinelはslave-priorityの小さいslaveプロセスを自動的に選択してnew masterになります.同時に、別のslaveプロセスのmasterを自動的にこのnew master Case 3:case 2に基づいてold masterを再起動し、sentinelはそれをslaveに降格します.そのマスターはcase 2が選択した新しいマスターCase 4:マスターと2つのslaveインスタンスのslave-priorityを互いに異なる値に割り当て、Case 1に基づいてshutdownの現在のマスターは、sentinelが新しいマスターを選択し、reconfigureの他のインスタンスが新しいマスターを指すようになった後(old master異常からsentinel再選択をトリガーするまでの時間はsentinel.confのdown-after-milliseconds構成項目によって指定されます)、old masterを再起動します.システムの最終状態はCase 3と一致します.すなわち、old masterはslaveに降格し、そのmasterはsentinelが選択した新しいマスターを指します.sentinelが新しいマスターを選択したが、他のインスタンスのreconfigureが完了していない前にold masterを再起動すると、new masterを選択できない異常がシステム全体に発生します.詳細は、次のCase 5の説明を参照してください.Case 5:masterと2つのslaveインスタンスのslave-priorityを同じ値にします.Case 1に基づいて、shutdownの現在のmasterは、sentinelが新しいマスターを選択し、reconfigureの他のインスタンスが新しいマスターを指すようにした後、old masterを再起動します.システムの最終状態はCase 3と同じです.つまり、old masterはslaveに降格し、そのmasterはsentinelが選択した新しいマスターを指します.すべてのslave-priorityが同じ値に構成されている場合、sentinelは、slaveインスタンスのrunidの最小slaveをmasterに昇格させます(slaveに対応するredis.confでpromoteがmasterであることが許可されている場合).Case 4で発生した異常と同様に、sentinelが新しいマスターを選択したが、他のインスタンスのreconfigureが完了していない前にold masterを再起動すると、sentinelの自動フェイルオーバーメカニズムが乱れていることがわかります.詳細な異常は以下の通りです.old masterはipがxxである.xx.234.67のマシン上でportのデフォルトは6379である、sentinel切替異常後、このold masterに対してinfoコマンドを実行する出力は以下の通りである:slave-00インスタンスはipがxxである.xx.234.49の機器にポートが6378、sentinel切替異常後、info出力は以下の通りである:slave-01の例はipがxxである.xx.234.49のマシン(slave-00と同じマシンに配備されている)に6377が搭載されており、info出力は以下の通りである:上の3つのredisインスタンスの出力状況から見ると、3つはいずれも自分がslaveだと思っており、システム全体に所有者がいない!ここで、xxに位置する.xx.234.67のold master(上の第1図のmaster_hostフィールドに注意)とxxに位置する.xx.234.49のsalve-00(上の第2図のmaster_hostフィールドに注意)は、slave-01がnew masterであり、xxに位置すると考える.xx.234.49のslave-01は自分がまだslaveだと思って、old masterは今まだmasterだと思っています
(上記第3図のmaster_hostフィールドに注意)
. sentinelプロセスログから見ると、sentinelは新しいマスターを選択できません.つまり、sentinelは2つのマスターcandidatesがどれがnewマスターなのかを確認できません.2つのインスタンス間で頻繁に切り替えます.このような状況は、実際のメンテナンス時に注意する必要があります.
Case 6:
システムがCase 5に示す異常状態に入った後も、shutdownの2つのmaster candidatesの1つのインスタンスでは、sentinelは3つのインスタンスがすべてshutdownになるまで正常にプライマリを選択できず、システム全体にプライマリが存在しません.モニタリングシステム内部の論理状態が混乱していることを基本的に決定することができる.
2.4結論:masterインスタンスが故障した場合、sentinelがnew masterを選択して安定した後(新しいマスターを選択して切替を完了する時間は構成と関係があり、典型的な値は1分以内)、old masterを再起動し、sentinelの誤審を引き起こすことを避け、システム全体がnew masterを選択できないことが望ましい.
【参考資料】1. Redis Sentinel Documentation
=================== EOF ==================