寄稿：米国サイオス VP Cassius Rhue
※この記事は翻訳されたものです。本記事の原文はこちら
Contents
SIOS Protection Suite クラスター環境での簡単なデプロイ方法
何かを避けること、それは誰にも経験があるはずです。夫婦で歩いているときに店で見かけた昔の恋人、「買う気」がないときの販売員、さらには休暇で出かけている時に遭遇した上司など。私が開発チームのマネージャーだった頃、直属の部下が病気で仕事を休んだはずなのに、買い物をしているところを見かけたことがあります。彼らは洋服のラックの間に隠れ、隣の通路を急いで通り抜け、そそくさと帰っていきました。
このような経験は誰にでもあると思いますが、精神衛生上、身体衛生上、あるいはプライベートで個人的な理由のために、何らかの回避策が必要な場合があります。高可用性においても、それは同じです。では、高可用性環境にはどのように回避策を加えればいいのでしょうか。そしてその理由はなぜでしょうか。
高可用性で回避戦略を使用する4つの理由
1.パフォーマンスの向上（サーバーの過負荷を最小化する）
HAにおいて回避戦略を用いる理由の1つは、アプリケーションとサーバーのパフォーマンスを向上させるためです。本番ワークロードを実行している3台のサーバーを、仮にサーバーA、サーバーB、サーバーCと呼ぶことにします。サーバーAとBではデータベースにバックアップされた重要なアプリケーションを実行し、サーバーCではレポートとデータ変換ジョブを実行しています。サーバーAで障害が発生した場合、従来はサーバーBにフェイルオーバーされていました。
しかし、サーバーBはすでに大規模なワークロードを実行しているため、結果としてアプリケーションの負荷が増えると、望ましくないサーバーの過負荷や、両方のアプリケーションのパフォーマンス低下が発生する可能性があります。そのため、フェイルオーバー先としてサーバーCが選択されるように回避策を導入するのが賢明です。
2.パフォーマンスの最適化
A、B、Cの3台のサーバーのシナリオをもう一度考えてみましょう。サーバーAとBはピーク時のワークロードに対応できるように拡張されており、サーバーCはコストが最適化されたサーバーです。サーバーAとサーバーBで障害が発生した場合、コストが最適化されたサーバーであるCに対してフェイルオーバーされます。しかし、このサーバーはピーク時のワークロードや、サーバーAとサーバーBの両方のワークロードを同時に処理できるようにはスケーリングされていません。この場合、別のホストが利用可能になり次第、片方または両方のワークロードをサーバーCから自動的に移動させるという回避戦略を使用することで、パフォーマンスを最適化することが可能です。
3.HAの最適化
HAの最適化も回避戦略を実施するシナリオの一つです。パフォーマンス最適化戦略と同様に、HAの最適化は、環境がほとんどの障害シナリオに耐えられるようにし、アプリケーションがどの時点でも可能な限り高いレベルの可用性を提供できるよう最適化するために実施されます。
SAP のような複製されたエンキュープロセスを持つアプリケーションでは、HA の最適化が重要になります。
どのようなSAP環境でも、ASCS（ABAP SAP Central Service）とERS（Enqueue Replication Server）インスタンスが同じサーバーに長時間常駐することは、ロックの喪失やジョブのキャンセルのリスクがあるため、避けたいものです。これを防ぐには、ERSインスタンスとASCSインスタンスが常に反対側のクラスターノードで実行されるようにする回避策を使用することができます。
本番ワークロードを実行している3台のサーバーをサーバーA、B、Cと呼ぶことにしましょう。サーバーAはASCSインスタンスを実行し、サーバーBはERSインスタンスを実行しています。サーバーCはサーバーB（ERS）とサーバーA（ASCS）両方のフェイルオーバーのための3番目のノードとなります。
サーバーBがクラッシュした場合、ERSリソースをASCSインスタンスと同じノードで実行することは望ましくありません。そのため、最初に自動的にチェックして2つのアプリケーションが別々のサーバー上にあることを確認する回避戦略を展開することにより、SAP ASCS/ERSのフェイルオーバーをブロックするというベストプラクティスを維持できます。
4.DRの回避
たとえば、2つのデータセンターがあるとします。A市とB市は約110キロメートル離れており、ほとんどのクライアントはこの2つのデータセンターの中間に集中しています。しかし、最近の社内組織の変更、合併・閉鎖・買収、ガバナンスの要件などにより、ITチームはA市とB市から約560キロ離れたC市にある第3のデータセンターを追加しなければならなくなりました。主にA市とB市で保護されていたリソースが、C市にも拡張されたのです。
ほとんどのユーザーとチームがAおよびB拠点の近くにいて、一番遠いユーザーでも近隣の都市にいることを考えると、チームはC拠点へのフェイルオーバーを回避する必要があります。他の戦略と同様に、DR回避は、いずれかのリージョン内の1つのノードだけが故障した場合にDRノードを回避することによって、パフォーマンス、リージョン内外のデータコスト、レイテンシー、クライアントアクセスを最適化しようとするものです。また、両方のノードに異なるタイミングで障害が発生した場合でも、DRに移行する前に必ずクラスターまたはデータセンター内の他のノードにフェイルオーバーが行われるようになります。
では、どのように回避策を展開すればいいでしょうか。多くのプロバイダーは、構成可能なアフィニティルールを用意していますが、サーバーの優先順位や手動ステップを組み合わせて使用するプロバイダーもあります。SIOS Protection Suite for Linuxでは以下のような多くの方法が組み込まれており、これらを利用することができます。
リソースの優先順位付け
障害が発生した場合、リソースは残りの優先度が最も低いサーバーにフェイルオーバーし、追加のサーバー（A、B、およびC）にカスケードされます。
サーバーAはResource.HRのプライマリーサーバー、サーバーBはResource.MFGのプライマリーサーバーです。サーバーCはすべてのリソース/サーバーのバックアップサーバーです。 リソースの優先順位付けを使用すると、Resource.HRの優先順位はサーバーAで1、サーバーCで2になります。Resource.MFGは、サーバーBでは優先順位1、サーバーCでは優先順位が2になります。
環境の利用を最適化したい場合、Resource.HRはサーバーCで優先順位3、Resource.MFGはサーバーAで優先順位を3にすることができます。サーバーAに障害が発生した場合、リソースResource.HRは、サーバーAでのサービス開始（復旧）を試行する前に、まずサーバーCにフェイルオーバーします。
SIOS Protection Suite for Linux（UIおよびCLI）を使用すると、ユーザーはサーバーとリソースの組み合わせごとに優先順位を指定できます。
ポリシーまたはアフィニティルール
ポリシールールを使用して、特定のサーバーでリソースのリカバリーが発生しないようにし、それによって、より重要な、またはリソース集約的なワークロードを実行している可能性がある特定のサーバーを避けることができます。一般的なポリシーは以下の通りです。
- デフォルトで特定のサーバーからのアプリケーションをブロックする制約ポリシー
- 十分なリソースがないサーバーからのアプリケーションをブロックするリソースポリシー
- システムからリソースを許可または禁止する期間を定義する一時的なポリシー
- クラスター内の優先サーバーや可能なアプリケーションの所有能力を定義するカスタムポリシー
SIOS Protection for Linux CLIを使用すると、ユーザーは指定したサーバーの特定のリソースへのフェイルオーバーを無効にしたり、障害から保護する一時的なポリシーを提供したり、特定のアプリケーションタイプの障害を無効にしたり、制約ポリシーやカスタムポリシーを無効にしたりできるポリシールールを指定できます。
特定の回避リソース
リソース回避戦略を確立するための最もきめ細かい方法は、各階層内に特定の回避スクリプトを展開することです。この方法では、特定のアプリケーション（app1とapp2など）を可能な限り互いに回避するように設定し、他のアプリケーションは制限なく実行できるようにすることができます。
A、B、Cの3つのサーバーと、app1、app2、app3の3つのリソースの場合、この方法が最も柔軟性が高くなります。この例では、サーバーに障害が発生した場合、app1とapp2は共存を回避しようとしますが、app3はそのような制限を受けずに優先順位に基づいて次に利用可能なノードにフェイルオーバーします。
回避戦略とリソースのその他の例については、SIOS Protection Suite for Linuxのドキュメントを参照してください。可能な限り異なるノード上で実行する必要がある2つのアプリケーション、app1とapp2を使用している場合、SIOS Protection Suite for Linux gen/appリソースと「/opt/LifeKeeper/lkadm/bin/avoid_restore」スクリプトを使用して2つの回避ターミナルリーフノードリソースを作成することができます。
