PaaS でフェイルオーバー アルゴリズムを作成する際に避けるべき 3 つの落とし穴

[[125412]]

クラウド サービスの停止が発生すると、通常はフェイルオーバー メカニズムがアクティブになり、障害が発生したサーバーから機能しているサーバーに切り替えます。こうすることで、フェイルオーバー プロセス中にクラウド サービスは中断や中断なく正常に動作できるようになります。

ただし、フェイルオーバー アルゴリズムに問題がないとは限りません。たとえば、アルゴリズムでは、そのアルゴリズムを実行するのに十分なリソースがあるかどうかが必ずしも事前にわかるわけではありません。フェイルオーバー プロセス中にコンピューティング リソースが使い果たされると、最終的にはクラウド サービスの停止 (Amazon サービスの停止など) が発生します。

停止中、PaaS (Platform-as-a-Service) 開発者と SaaS (Software-as-a-Service) ユーザーは、作業を時間どおりに完了できないと嘆きました。クラウド サービスをできるだけ早くオンラインに戻したいという切実な思いから、彼らは Information as a Service (IaaS) プロバイダーのテクニカル サポート部門に電話をかけ続けています。最終的には、IaaS プロバイダーが問題を解決します。

フェイルオーバーアルゴリズムを作成する際に留意すべき点

クラウド サービスの停止が発生し、IaaS プロバイダーが提供するフェイルオーバー アルゴリズムに満足できない場合は、カスタム フェイルオーバー アルゴリズムを作成することを検討してください。アルゴリズムが正しく動作することを確認するには、さまざまなシナリオでテストする必要があります。すべてのテストで肯定的な結果が返されたら、プロバイダーのフェイルオーバー アルゴリズムが失敗した場合に、次回のクラウド サービスの停止時に運用環境でアルゴリズムをアクティブ化できることについて、IaaS プロバイダーの同意を得る必要があります。

フェイルオーバー アルゴリズムを作成するときに回避する必要がある 3 つの大きな落とし穴があります。

1. 閏年の日付

最後の閏年は 2012 年 2 月 29 日でした。セキュリティ証明書を発行した Microsoft Azure のサーバーがこの日付を認識したかどうかを確認するのを忘れた人がいます。その日付の最初の数分が経過すると、仮想マシンは起動に失敗しました。管理者がこの問題を見つけて解決するのは簡単ではありません。

次の閏年は 2016 年 2 月 29 日なので、同じ災難を避けるには十分な時間があります。 PaaS でいくつかの閏年認識アルゴリズムをテストする必要があります。これにより、セキュリティ証明書が閏年の日付を認識することを確認できます。

2. 不安定な数値アルゴリズム

自分が書いた数値アルゴリズムが不安定であることに気付くのが遅すぎます。このアルゴリズムは、コンピュータのリソースを消費する無限ループを引き起こします。利用可能なリソースがますます不足するにつれて、クラウド サービスのパフォーマンスはますます低下します。リソースがなくなると、クラウド サービスは実行を停止します。

次の簡単なシナリオは、数値アルゴリズムがどのように不安定になるかをより明確に理解するのに役立ちます。

2 の平方根を求めるには、初期近似値 1.4 でアルゴリズムを開始します。小さな値を設定すると、アルゴリズムはその値に収束するはずです。この値に達すると、アルゴリズムはおおよその答え 1.41421 (予想どおり) を返します。この時点で、アルゴリズムは実行を停止します。他の計算タスクのためにリソースが解放されるため、アルゴリズムは安定します。

新しいアルゴリズムにわずかに異なるロジックを組み込みます。初期近似値は 1.4 ではなく 1.42 です。結果が期待値に収束せず、最初の数値アルゴリズムによって得られた近似解から大幅に逸脱していることがわかります。

答えはどんどん長くなっていきます。アルゴリズムは無限ループに陥り続け、リソースを絶えず消費し続けます。リソースがなくなるとアルゴリズムの実行が停止し、不安定であることがわかりました。

この罠を回避するには、アルゴリズムが期待値に収束できるかどうかを判断するために、事前に調べておく必要があります。

3. ハイパーバイザーの障害

すべての PaaS (オープンソースかクローズドソースかに関係なく) は、IaaS の下の仮想マシン上に配置されます。すべての仮想マシンの作成と操作は、仮想マシン ハイパーバイザーの統一された責任の下に行われます。物理サーバーがホストして実行できる仮想マシンの数は、物理サーバーの機能/容量によって異なります。

ハイパーバイザーに障害が発生すると、すべての仮想マシンの実行が停止します。失敗の原因の 1 つは、IaaS インフラストラクチャの専門家が、単一の物理サーバー上でホストできる仮想マシンの数を判断できないことです。プロバイダーはサーバーの機能/容量を正確に検証できませんでした。物理サーバーのリソース制限を超える仮想マシンを追加しようとしました。制限が最大 2 台の VM の場合、プロバイダーがさらに 1 台の VM を追加すると、物理サーバーによってホストされているすべての VM の実行が停止します。

この落とし穴を回避するには、単一の物理サーバー上で実行できる新しい VM の数を把握する必要があります。調査結果を IaaS プロバイダーまたは IaaS インフラストラクチャ スペシャリストの調査結果と比較します。すべての VM を毎日のタスクとして必ずバックアップしてください。

結論

IaaS プロバイダーのフェイルオーバー アルゴリズムだけに依存しないでください。独自のフェイルオーバー アルゴリズムを作成することもできますが、実行する前に IaaS プロバイダーから承認を得ることを忘れないでください。

オリジナルの英語リンク: http://www.techrepublic.com/article/three-pitfalls-to-avoid-when-creating-failover-algorithms-on-a-paas/