今回は、SPP のクラスタ構成について紹介します。
SPP は安全かつ堅牢なアプライアンスですが、万一障害が発生して利用不能となってしまった場合、重要な IT資産への特権アクセスができなくなるため（※） 、業務に大きな支障が生じる可能性があります。
※ SPP は、特権アカウントのパスワードおよび SSH キーを厳重に管理するアプライアンスです。SPP で管理されている特権アカウントの現在のパスワードおよび SSH キーは、SPP の申請承認ワークフローを介してのみ取得することができます。つまり、SPP が故障してしまった場合、（SPP での申請承認が行えないため）特権パスワードおよび SSH キーを知ることができなくなります。
SPP をクラスタ構成で運用することで、障害が発生した場合に迅速な復旧や業務の継続が可能となります。
SPP のクラスタ構成
クラスタ構成とは、「複数のサーバーを連携して １つのシステムとして運用する冗長化構成」 のことです。
SPP は、３台 または ５台 のアプライアンスでクラスタを構成することができます。
クラスタ内の １つのアプライアンスが プライマリ、プライマリ以外のアプライアンスは レプリカ と呼ばれます。
３台構成の場合
プライマリアプライアンス １台、レプリカアプライアンス ２台で構成されます。
５台構成の場合
プライマリアプライアンス １台、レプリカアプライアンス ４台で構成されます。
プライマリ と レプリカ
プライマリ は 設定の追加、編集、削除が可能な（マスター）アプライアンスです。
レプリカ は プライマリの複製であり、（一部の設定を除き）読み取り専用のアプライアンスです。
クラスタの管理
レプリカの追加や参加解除などのクラスタの管理作業は、「アプライアンス」アクセス許可権限を持つ管理ユーザーが プライマリ アプライアンスから行います。
SPP の管理設定
設定の追加、編集、削除などの SPP の管理作業は、（クラスタのコンセンサスが成立しているとき）プライマリ アプライアンスからのみ可能です。
申請承認ワークフロー
パスワード/SSH キー、セッションの利用申請やパスワード/SSH キーの取得は、（クラスタのコンセンサスが成立しているとき）プライマリ、レプリカ のどちらからでも可能です。また、オフラインワークフローモードのアプライアンスからも可能です。
クラスタ構成の利点その１ – 可用性の向上
SPP は、クラスタを構成する一部のアプライアンスに障害が発生し利用不能となっている間も、クラスタのコンセンサスが成立している場合は、サービスの提供を継続することができます。
コンセンサスの成立条件（クォーラム・コンセンサス）
SPP のクラスタは、クラスタを構成する過半数のアプライアンスがオンラインであり、通信が可能な場合にコンセンサスが成立します（クォーラム・コンセンサス）。コンセンサスが成立している場合、ユーザーは SPP の申請承認ワークフローを利用することができます。
クォーラム・コンセンサス：
クォーラム（quorum：定足数）を満たす場合に、コンセンサス（consensus：合意）が成立します。
SPP クラスタのクォーラム（定足数）は、過半数です。
３台構成の場合：
クォーラムは ２です。
３台中２台以上のアプライアンスがオンラインであり、通信可能であればコンセンサスが成立します。
５台構成の場合：
クォーラムは ３です。
５台中３台以上のアプライアンスがオンラインであり、通信可能であればコンセンサスが成立します。
コンセンサスが成立しているとき
クラスタのコンセンサスが成立している場合、ユーザーは申請承認ワークフローを利用できます。
例えば３台構成の場合に、クラスタのコンセンサスが成立するのは次のときです：
利用不能となったアプライアンスの問題が解決してオンラインに戻ると、自動的にサービスの提供が再開されます。
（Ｃ）の場合（コンセンサスは成立しているがプライマリが利用不能な場合）、レプリカの１つを手動でプライマリへ昇格させることができます。これを SPP では、「フェイルオーバー」 と呼びます。
コンセンサスが成立していないとき
クラスタのコンセンサスが成立していない場合、ユーザーは申請承認ワークフローを利用できず、承認済みのパスワード/SSH キーも取得できません。
例えば３台構成の場合に、クラスタのコンセンサスが成立していないのは次のときです：
クラスタのコンセンサスが回復すると自動的にサービスの提供が再開されますが、（A または B のように）利用可能なアプライアンスが存在する場合は、このアプライアンスを「オフラインワークフローモード」に切り替えることで、このアプライアンスから申請承認ワークフローを利用できるようにすることができます。
フェイルオーバー（レプリカをプライマリに昇格させる）
プライマリが利用不能な場合、フェイルオーバーを行うことでレプリカをプライマリに昇格させることができます。
フェイルオーバーを行うためには、クラスタのコンセンサスが成立していることが必要です。
例えば３台構成の場合に、フェイルオーバーが可能なのは次の (A) のときです：
フェイルオーバーは、「アプライアンス」アクセス許可権限を持つ管理ユーザーが手動で行います。
フェイルオーバー処理中は、クラスタがロックされ、クラスタ内のすべてのアプライアンスがメンテナンスモードになります。
処理が完了すると、フェイルオーバー実行時に選択したレプリカがプライマリとして表示され、クラスタ内の（「古い」プライマリを含む）その他のアプライアンスはレプリカになります。
オフラインワークフローモード
クラスタのコンセンサスが成立していない場合、ユーザーは（利用可能な SPP アプライアンスへアクセスしても）申請承認ワークフローを利用することができません。
コンセンサスをすぐに回復できない場合は、利用可能なアプライアンスを オフラインワークフローモード に切り替えることで、このアプライアンスをクラスタの他のメンバーから分離させ、申請承認ワークフローを利用できるようにすることができます。
オフラインワークフローモードへの切り替えは、手動または自動で行うことができます。
- オフラインワークフローモードでは、アプライアンスにキャッシュされているポリシーが使用されます。
- チェックイン後のパスワード/SSH キーの変更はバイパスされ、再スケジュールされます。
- オフラインワークフローモードは読取り専用モードであるため、設定の追加、変更、削除は行えません。
問題が解決してクラスタがコンセンサスを回復したら、オフラインワークフローモードのアプライアンスを オンラインワークフローモード へ自動または手動で切り替えます。
オンラインワークフローモードに戻すと、オフラインワークフローモードのアプライアンスの監査ログがクラスタの監査ログとマージされます。
クラスタ構成の利点その２ – 負荷分散
SPP をクラスタ構成で利用することで、負荷分散が可能となります。
SPP のクラスタでは、それぞれのアプライアンスが管理するネットワークを設定し、パスワード/SSH キーの確認や変更、資産/アカウント検出などのスケジュールタスクの負荷を分散させることができます。
下は管理対象ネットワークの追加例です。
SPP クラスタには、すべてのクラスタメンバーで構成されるデフォルトの管理対象ネットワーク（Default Managed Network）が存在します。このデフォルトの管理対象ネットワークは、編集できません。
追加した管理対象ネットワークを指定することで、例えばターゲット資産に最も近いアプライアンスに特定のタスクを実行させるように設定することができます。
さいごに
SPP は安定したアプライアンスですが、重要なシステムの特権アカウントのパスワードや SSH キーが保存されているため、高い可用性が求められます。万一の障害が発生した場合の迅速な復旧や業務の継続が可能となるよう、SPP をクラスタ構成で運用いただくことを推奨します。
SPP には、仮想アプライアンスの評価版がございます。クラスタ構成も評価いただくことができます。ぜひ、評価版で動作をご確認ください。
SPP 製品紹介ページ
SPP には、この記事で紹介した以外にも機能があります。
その他の特長や機能については、それぞれの製品紹介ページをご参照ください。
SPP 評価版
SPP の評価版は、仮想アプライアンス（OVAまたはVHDXファイル）で提供いたします。
SPP の評価版では、すべての機能を 90日間無料でご利用いただけます。
評価版の利用をご希望いただく場合は、下記お問い合わせフォームから評価ライセンスをお申し込みください。
お問い合わせ
購入前の SPP に関するお問い合わせは、下記お問い合わせフォームからお問い合わせください。
