Parallels RAS - ロードバランシングとフェイルオーバーとは

Parallels RAS – ロードバランシングとフェイルオーバーとは

By ジャパンマーケティング

高可用性を実現する方法として、ロードバランシングとフェイルオーバーがあります。ロードバランシングは、単一のシステムが過負荷にならないように作業負荷を分散させることで、またフェイルオーバーは、メインシステムに障害が発生したときに、ワークロードをバックアップシステムにリダイレクトすることで実現されます。

このロードバランシングとフェイルオーバーの記事では、ロードバランシングとフェイルオーバーの実装における重要な概念、どちらかを選択するかの方法、そしてあらゆる形式の高可用性を適用する際に考慮すべき点についてご説明します。

>>参考資料・Login VSI による Parallels RAS スケーラビリティテスト Task Woker (250ユーザー)

ロードバランシングの実現に向けて

システムが利用できなくなる原因の一つは、そのシステムが最大限の能力に達した場合です。言い換えれば、過負荷になったということです。たとえば、1台のサーバーに過剰な数のリクエストがあると、やがてCPUとRAMの使用量が最大になります。このとき、そのサーバーはこれ以上クライアントからのリクエストを受け付けられなくなります。

ロードバランシングの定義

システムの過負荷を防ぐために、ロードバランシングを実装することができます。ロードバランシングとは、ワークロードを単一のシステムだけに向けるのではなく、2つ以上のシステム間で分散させることによって、高いレベルの可用性を実現する方法です。複数のシステムにワークロードを分散させることで、1つのシステムが過負荷に陥るリスクを最小化することができます。

ロードバランシングの実装方法

さて、ロードバランシングを実現するには、いくつかの方法があります。ひとつは、システムをコンポーネントに分割し、各コンポーネントに特定の機能を持たせる方法です。例えば、ウェブサーバーとデータベースサーバーが1つのホストで動作している場合、それらを分割してそれぞれを別のホストに配置することができます。

もう一つの方法は、同様のシステムのコピーを複数作成し、それらの類似したシステムにワークロードを分散させる方法です。例えば、全く同じウェブサービスを提供するサーバーインスタンスを4台用意し、それぞれのサーバーをロードバランサーの背後に置き、ワークロードをこれらのウェブサーバーに分散させることができます。

ロードバランシングのアルゴリズム

ロードバランサーは、ロードバランシングアルゴリズムと呼ばれる一定のルールに従い、ワークロードを分散させます。よく使われるアルゴリズムのひとつにラウンドロビンがあります。ラウンドロビンは、単純にロードバランサーの背後にある各システムに周期的にワークロードを分散させます。ラウンドロビンはある程度は有効ですが、限界もあります。何らかの理由で、あるシステムが他のシステムよりも早く上限に達してしまった場合はどうすれば良いのでしょうか？

このような状況を回避するために、エンジニアはより洗練されたロードバランシングアルゴリズムを開発しました。その一例が、Parallels® RAS で使用されているリソースベースのロードバランシングアルゴリズムです。このアルゴリズムは、既存のユーザセッションの数、メモリおよび CPU の使用率など、特定のメトリクスを追跡します。ワークロードを分配する際には、これらのメトリクスを考慮します。

ロードバランサーの種類

ロードバランシングには通常、ワークロードを分散させるロードバランサーの存在が必要であることは言うまでもありません。ロードバランサーには様々なタイプがあり、物理的なネットワーク上に物理的に配置されるハードウェアベースのロードバランサー、ホスト上にインストールするソフトウェアベースのロードバランサー、また、仮想アプライアンスロードバランサーの場合は、仮想環境に展開することができます。

フェイルオーバーの実現に向けて

負荷分散が過負荷によるシステム障害の防止を目的とするのに対し、フェイルオーバーは過負荷によるシステム障害の有無にかかわらず、システム障害が発生した場合の対処に重点を置いています。例えば、あるサーバーが設置されている施設の停電で停止してしまったとします。

もし、そのサーバーが別の施設にあるバックアップサーバーとフェイルオーバーするように設定されていれば、停電が続いている間でも業務を再開することができます。フェイルオーバーの目的は、サービスを提供するメインシステムが停止しても、ワークロードをバックアップシステムにリダイレクトすることで、サービスを利用可能にすることです。

フェイルオーバーの実装

お気づきのように、フェイルオーバーには、メインシステムの全機能を実行できるバックアップシステムの存在が必要です。メインシステムがアクティブな間、バックアップシステムは単にスタンバイモードとなり、何もしません。つまり、いわゆる「パッシブ」な状態となります。

アクティブ-アクティブおよびアクティブ-パッシブ構成

ロードバランシングでは、すべてのシステムがアクティブモードになっています。フェイルオーバーの設定では、あるシステムがアクティブで、別のバックアップシステム（あるいは他の複数のバックアップシステム）がパッシブとなります。このため、ロードバランシングのセットアップは通常アクティブ-アクティブ高可用性構成と呼ばれ、フェイルオーバーのセットアップは通常アクティブ-パッシブ高可用性構成と呼ばれています。

フェイルオーバーの要件

フェイルオーバー設定におけるバックアップまたはフェイルオーバーシステムは、メインシステムがダウンしたときに、すべてのメインシステムの機能を完全に引き継ぐことが期待されます。このため、フェイルオーバーシステムはメインシステムの複製である必要があります。メインシステムのすべての構成とデータを複製する必要があり、これを「冗長性」と言います。

フェイルオーバーを効果的に行うには、フェイルオーバーシステムをメインシステムと同じ場所に設置するべきではありません。たとえば、メインサーバーとフェイルオーバーサーバーを同じラックに設置してはなりません。可能であれば、同じ施設内にも置くべきではありません。そうすれば、施設全体が機能停止した場合でも、フェイルオーバーサーバーには影響が及ばないからです。

単一障害点の問題

フェイルオーバーは単一障害点の問題に対処します。ロードバランサーに適用することもできます。ロードバランサーは、背後にある個々のシステムの障害リスクを最小化するのに役立ちますが、そのロードバランサー自体は単一障害点となります。背後にある他のシステムがすべて良好な状態であっても、関係ないのです。そのロードバランサー自体に障害が発生すると、サービスが利用できなくなります。この問題に対処するには、ロードバランサーにフェイルオーバーシステムを設定し、メインのロードバランサーに障害が発生した場合に、それを引き継ぐことができるようにします。

ロードバランシングとフェイルオーバーの選択

純粋な可用性の観点からは、ロードバランシングはある意味、フェイルオーバーよりも優れています。フェイルオーバーはメインシステムがすでに故障している場合にのみ発動するのに対し、ロードバランシングはそもそも故障の発生を未然に防ぐものです。

ロードバランサーの中には、ノード（負荷を分散しているコンポーネントの1つ）が完全に停止していることを検知できる賢いものもあります。そして、(1)そのノードをロードバランシングプロセスから一時的に外すことができるように警告するか、(2)そのノード自体を外すかのどちらかを行うことができます。その問題のあるノードが停止している間、ロードバランサーは残りのアクティブなノードにのみ負荷を分散させます。

高可用性のコストを評価する

可用性はパーセンテージで測定されます。完全な状態では、可用性は 100％になります。これはダウンタイムがゼロであることに相当します。実際には、稼働率、つまり可用性はほとんどの場合 100％より低くなります。システムの可用性を可能な限り 100％に近づけるように努力するしかありません。IT の世界では、可用性や稼働率は通常 9 の数字で表現されます。

例えば、こんな感じです。

99.9%の稼働率、つまり3ナイン：
これは、年間約8時間46分のダウンタイムに相当します。
99.99%の稼働率、つまり4ナイン：
これは、年間約52分36秒のダウンタイムに相当します。
99.999%の稼働率、つまり5ナイン：
これは、年間約5分15秒のダウンタイムに相当します。
99.9999%の稼働率、つまり6ナイン：
これは、年間約31秒のダウンタイムに相当します。

ロードバランシングやフェイルオーバーなどの手法は、より高い稼働率を達成するために不可欠なものでありますが、その導入にはかなりのコストがかかることも知っておくべきでしょう。システムの目標可用性が高ければ高いほど、より多くの冗長性が必要になります。例えば、バックアップシステムを1台（n+1）ではなく、2台（n+2）、あるいは2倍（2n）の台数が必要になります。冗長化するシステムの数が増えれば増えるほど、コストは高くなります。

フェイルオーバーとロードバランシング：
Parallels RAS はその両方を提供します。

Parallels RAS は、ロードバランシングとフェイルオーバーの両方をサポートするオールインワンの仮想デスクトップインフラ（VDI）ソリューションです。VDI ソリューションとして、Parallels RAS は、データセンターや Amazon Web Services（AWS）、Azure、Google Cloud Platform（GCP）などのパブリッククラウドに、アプリケーションやデスクトップをデプロイすることができます。そして、仮想化されたアプリケーションとデスクトップに、インターネットを介してユーザがアクセスできるようにします。

Parallels RAS には、HALB（High Availability Load Balancing）機能が搭載されています。HALB は、ユーザのエンドポイントデバイス（PC、ラップトップ、電話、タブレット、シンクライアントなど）上で実行される Parallels クライアントと Parallels RAS サーバー間のプロキシとして機能するサービスである Parallels RAS ゲートウェイのトラフィック制限を解消するものです。HALB アプライアンスの数が多ければ多いほど、ユーザがダウンタイムに悩まされる可能性が低くなります。

さらに、Parallels RAS には、サーバー使用率、デバイス使用率、アプリケーションアクセス、およびその他の関連情報を視覚的かつ直感的に把握できるレポートを提供するレポートエンジンが搭載されています。これらのレポートによって、Parallels RAS 環境の健全性を把握し、可用性を向上させるための意思決定に役立てることができます。

最後に、Parallels RAS は Microsoft Hyper-V Failover Cluster をサポートしており、Live Migration もサポートしています。Live Migrationは Hyper-V の機能であり、ユーザがダウンタイムなしに実行中の VM を物理ホストから別のホストに移動することを可能にします。この機能により、高可用性イニシアチブをさらに強化することができます。