高可用性 (HA: High Availability) はクラウド・インフラストラクチャー・ソリューションと関連付けられることが多い用語です。HA が実質的に意味していることはマシンのダウンタイムを最小限にとどめてビジネスを継続できる性質です。具体的に言えば、どのようなクラウド・インフラストラクチャーでも HA を実現しようとする場合には以下のような点を目標にする必要があります。

• 計画的なダウンタイムを削減する
• 予定外のダウンタイムを防止する
• システムダウンから迅速に回復する
• 可用性を維持する

クラウド・インフラストラクチャーの基礎となる最近のハイパーバイザーは、HA の実現を可能にするフィーチャーおよび機能の大半を備えています。この記事では、IBM SmarterCloud Enterprise+ がサーバーの計画的なダウンタイムや予定外のダウンタイムの処理、システムダウンからの回復、継続的なサーバー可用性の保証をどのように行っているかについて簡単に説明します。次に IBM SmarertCloud Enterprise+ において、IBM System x プラットフォームや System p プラットフォームに実装された VMware や AIX の論理パーティション (LPAR) 上で実行される仮想マシン (VM) に対して HA を実現する方法について説明します。

計画的なダウンタイムを削減する

計画的なダウンタイムは通常、ソフトウェアの保守、リリース、アップグレードのためや、機器の修理の予定に合わせてスケジューリングされます。ほとんどのクラウド・プロバイダーは何らかの計画的なダウンタイムをスケジューリングしますが、彼らのビジネスは高いアップタイムを提供することを基本とするので、計画的なダウンタイムは最小限にとどめられます。

IBM SmarterCloud Enterprise+ では、OS に対するセキュリティー・アップデートやセキュリティーとは無関係のアップデートが含まれたパッチを自動的に VM に当てる方法を用意しています。この方法は、事前に設定された定期的なサイクルに従って自動的にアップデートをデプロイするため、まったく手作業を必要としません (ユーザーは特定のサイクルでどの VM にパッチが必要なのかを決定することができます)。パッチを当てる処理が完全に自動的に行われるこの方法では、計画的なダウンタイムを大幅に削減することができ、VM はほとんどの時間利用可能となり、ビジネスを継続させることができます。

予定外のダウンタイムを防止する

クラウド環境でサーバーのダウンタイムが予定外に発生する場合、いくつかの原因が考えられます。主な原因としては、ハイパーバイザー・インフラストラクチャーの障害、OS の障害、ネットワークの障害があります。

IBM SmarterCloud Enterprise+ では、これらの一般的な障害のほとんどを最小限のダウンタイムで処理することができます。この記事で後ほど説明するように、System x 上のエージェントや System p のネイティブ・デーモンの 1 つを監視することで OS の障害を検出することができます。また System x 上で VMware のハートビートの時間間隔を監視したり、System p のネイティブ・デーモンのいくつかを監視したりすることでネットワークの障害を検出することができます。

システムダウンから迅速に回復する

予定外のダウンタイムによってシステムが停止した場合、回復の速さは障害の性質に依存します。システムの停止はホスト・プラットフォームやストレージの障害によって発生する場合もあれば、OS やネットワークの障害によって発生する場合もあります。ホスト・プラットフォームやストレージの障害によってシステムが停止すると、そうした障害に対するクラウド・プロバイダーの準備が適切でなかった場合には、データやランタイムの損失の規模は他の障害の場合よりも大きくなる可能性があります。

IBM SmarterCloud Enterprise+ のフェイルオーバー・メカニズムは、ホスト・プラットフォームやストレージの障害からの迅速な回復を可能にします。障害が発生したホスト・プラットフォームのワークロードはすべて、最小限のダウンタイムで他のホスト・プラットフォームに分散されます。ストレージの障害はミラーリングされたデータストアを使用することで対処されます。VM のデータはすべて複製されて 2 つのデータストアに格納されます。一方のデータストアに障害が発生した場合でも、VM は複製されたデータストアによって通常どおり動作を継続することができます。

可用性を維持する

計画的なダウンタイムや予定外のダウンタイムの削減、そして障害からの迅速な回復といったすべてが可用性の維持に寄与します。それにより、(Platform-as-a-Service クラウドの) サーバーはほとんどの時間、稼働状態を継続することができ、ダウンタイムをごく最小限にとどめることができます。可用性を維持するために必要な事項は以下のとおりです。

• 基礎となるハイパーバイザーの HA フィーチャーの適切な構成
• OS に用意された障害検出フィーチャーの使用
• OS での障害を監視できる監視サービス
• アプリケーションの高可用性を維持するためのアプリケーションの監視

IBM SmarterCloud Enterprise+ はハイパーバイザーに用意された HA フィーチャーの大部分を活用しています (ホスト・プラットフォームに対するフェイルオーバー・メカニズム、再起動の優先順位付け、ハートビートの間隔検出、OS の監視と障害検出、異常終了の検出など)。

SLA ベースの HA

IBM SmarterCloud Enterprise+ における HA の構成は、顧客が特定の VM に対して選択する SLA (Service-Level Agreement: サービス・レベル・アグリーメント) に基づいています。IBM SmarterCloud Enterprise+ では、System x プラットフォームや System p プラットフォーム上の VM に対し、以下の 4 つのレベルの SLA を定義しています。

• プラチナ
• ゴールド
• シルバー
• ブロンズ

エラーが発生した場合、プラチナ SLA は最小限のタイムアウトで最優先に再起動されます。エラー発生時の再起動の優先順位は、ゴールド、シルバー、ブロンズの順に下げられ、タイムアウトも長くなります。この記事のこれから先では、これらの優先順位とタイムアウトの詳細について説明します。注: これらの SLA にはインフラストラクチャーのコンポーネントと VM のコンポーネントの両方についての記述が含まれます。この記事では VM のコンポーネントについてのみ説明します。

上に戻る

System x で HA を実現する

IBM SmarterCloud Enterprise+ で VMware HA (VMware vSphere High Availability) フィーチャーを利用すると、IBM System x 上にプロビジョニングされた VM に対して HA を自動的に構成することができます。このフィーチャーには再起動の優先順位とハートビートという 2 つの重要な要素があります。

再起動の優先順位

VM を再起動するための優先順位の値を使用することで、リソースの競合を解決することができます。障害の発生した VM すべてに対応できるほど十分なキャパシティーがない場合、どの VM を VMware HA が優先するのかをこの優先順位によって決定することができます。ホスト上で高い優先順位を持った VM は低い優先順位の VM よりも優先して処理されます。

1 つの VM の HA を構成するための有効なパラメーターは、disable (無効)、high (高)、medium (中)、low (低) です。

ハートビートの時間間隔

IBM SmarterCloud Enterprise+ の VMware VM ヘルス・モニター・フィーチャーは VM のハートビート・サービスでの応答を常に確認しています (VM のハートビート・サービスは指定されたホスト上のすべての VM にある VMware ツールの中で実行されます)。構成可能なタイムアウト間隔内にハートビート・サービスがヘルス・モニター・サービスに応答できない場合、その VM は「障害が発生した VM」とみなされ、その障害に対応したリセット・アクションが実行されます。

ハートビートのタイムアウト間隔の値が小さければ小さいほど、VM のリブートが実行されるまでの時間が短くなります。ハートビートの時間間隔はプラチナ SLA が最も短く、次いでゴールド、シルバー、ブロンズの順に長くなります。

表 1 は各 SLA レベルに対して構成される再起動の優先順位とハートビートの値を示しています。

* IBM はこれらの値を推奨します。ベンダー、クラウド管理者、ユーザーは、支配的な環境条件やワークロード条件に応じてタイムアウト間隔を調整することができます。

プラチナ VM には表 1 の設定の他に、ミラーリングされたデータストアにストレージが割り当てられます。そのため、たとえストレージ機器に障害が発生した場合にも VM の可用性は維持されます。

VMware vSphere API による実装

VMware には柔軟で使いやすい vSphere API が用意されているため、必要な HA 構成の設定をプログラムで行うことができます。

再起動の優先順位を構成するために、IBM SmarterCloud Enterprise+ は reconfigureComputeResource_Task API といくつかの vSphere データ・オブジェクトを使用します。リスト 1 のコード・セグメントは VIPort インターフェースの reconfigureComputeResource_Task メソッドに ClusterConfigSpecEx データ・オブジェクトを渡す場合を示しています。

// Initialize the ClusterConfigSpceEx data object and subobjects 
// required for enabling restart priority.
ClusterConfigSpecEx spec = new ClusterConfigSpecEx();
ClusterDasVmConfigSpec[] clusterDasVmConfigSpec = new ClusterDasVmConfigSpec[1];
clusterDasVmConfigSpec[0] = new ClusterDasVmConfigSpec();
spec.setDasVmConfigSpec(clusterDasVmConfigSpec);
ClusterDasVmConfigInfo clusterDasVmConfigInfo = new ClusterDasVmConfigInfo();
clusterDasVmConfigSpec[0].setInfo(clusterDasVmConfigInfo);
ArrayUpdateOperation arrayUppdateSpec = ArrayUpdateOperation.add;
clusterDasVmConfigSpec[0].setOperation(arrayUppdateSpec);

// VM managed object reference (MOR) must be provided as a key for ClusterDasVmConfigInfo.
clusterDasVmConfigInfo.setKey(VM MOR);

// Set the restart priority for the VM
ClusterDasVmSettings clusterDasVmSettings = new ClusterDasVmSettings();
clusterDasVmConfigInfo.setDasSettings(clusterDasVmSettings);

// Restart priority value is obtained from the SLA (see Table 1). 
clusterDasVmSettings.setRestartPriority(restartPriority based on SLA);
ManagedObjectReference taskMor 
   = con._service.reconfigureComputeResource_Task(clsMor, spec, true);

ハートビートの間隔を構成する場合にも、reconfigureComputeResource_Task API といくつかの vSphere データ・オブジェクトを使用します。リスト 2 のコード・セグメントは VIPort インターフェースの reconfigureComputeResource_Task メソッドに ClusterConfigSpecEx データ・オブジェクトを渡す場合を示しています。

// Initialize the ClusterConfigSpceEx data object and subobjects
//  required for enabling the heartbeat interval.
ClusterConfigSpecEx spec = new ClusterConfigSpecEx();
ClusterDasVmConfigSpec[] clusterDasVmConfigSpec = new ClusterDasVmConfigSpec[1];
clusterDasVmConfigSpec[0] = new ClusterDasVmConfigSpec();
spec.setDasVmConfigSpec(clusterDasVmConfigSpec);
ClusterDasVmConfigInfo clusterDasVmConfigInfo = new ClusterDasVmConfigInfo();
clusterDasVmConfigSpec[0].setInfo(clusterDasVmConfigInfo);
ArrayUpdateOperation arrayUppdateSpec = ArrayUpdateOperation.add;
clusterDasVmConfigSpec[0].setOperation(arrayUppdateSpec);

// VM managed object reference (MOR)must be provided as a key for ClusterDasVmConfigInfo.
clusterDasVmConfigInfo.setKey(VM MOR);

// Set the heartbeat interval for the VM.
ClusterDasVmSettings clusterDasVmSettings = new ClusterDasVmSettings();
clusterDasVmConfigInfo.setDasSettings(clusterDasVmSettings);
ClusterVmToolsMonitoringSettings clusterVmToolsMonitoringSettings = 
   new ClusterVmToolsMonitoringSettings();
clusterDasVmSettings.setVmToolsMonitoringSettings(clusterVmToolsMonitoringSettings);

// Heartbeat interval is obtained from the SLA (see Table 1) 
clusterVmToolsMonitoringSettings.setFailureInterval(heartBeatInterval based on SLA);
ManagedObjectReference taskMor 
   =con._service.reconfigureComputeResource_Task(clsMor, spec, true);

上に戻る

System p で HA を実現する

System p で HA を実現するための機能には、優先順位ハング検出、I/O 損失ハング検出、異常終了検出があります。

表 2 は、これらの HA フィーチャーに対して構成される値を各 SLA レベルで示しています。

* IBM はこれらの値を推奨します。ベンダー、クラウド管理者、ユーザーは、支配的な環境条件やワークロード条件に応じてタイムアウト間隔を調整することができます。

優先順位ハング検出

プロセス (スレッドとも呼ばれます) はすべて、優先順位に従って実行されます。この優先順位は 0 から 126 の範囲で表現され、0 が最も優先順位が高く、最も低い優先順位は 126 です。どのスレッドでも、デフォルトの優先順位は 60 です。すべてのユーザーは nice コマンドを使用してプロセスの優先順位を下げることができます。ルート権限を持つ人であれば、プロセスの優先順位を上げることもできます。

カーネルのスケジューラーは実行可能スレッドのうち最も優先順位の高いスレッドを常に選択し、CPU を割り当てます。そのため、マシンが完全に占有されてしまうだけの十分な数の優先順位の高いスレッドによって、優先順位の低いスレッドはまったく実行されない、ということが起こり得ます。実行されているスレッドの優先順位がデフォルトの 60 よりも高い場合、それによって通常のシェルやログインがすべてロックアウトされてしまい、システムがハングアップしたように見えてしまうこともあります。システム・ハング検出フィーチャーはこうした状況を検出するためのメカニズムであり、システム管理者はこのフィーチャーを利用してシステムをハングアップ状態から回復させることができます。このフィーチャーは最も高い優先順位で処理が実行されるデーモン (shdaemon) として実装されています。shdaemon はカーネルに問い合わせを行い、指定された期間の中で最も低い優先順位で実行されるスレッドについての情報を取得します。そのスレッドの優先順位が構成されたしきい値よりも高い場合には、shdaemon はいくつかのアクションのうちの 1 つを実行します。これらの各アクションは、単独で実行可能であり、任意の期間にわたって任意の優先順位でトリガーされるように構成することができます。

IBM SmarterCloud Enterprise+ でシステム・ハング検出フィーチャーを構成するためには、以下のように shconf コマンドを使用して、システムをリブートするためのアクションを構成します。

$: shconf -l pio -a pp_reboot=enable -a pp_rto=priority hang timeout based on SLA 

I/O 損失ハング検出

AIX は I/O ハング状態を検出し、ユーザーが定義したアクションに基づいてハング状態からの回復を試みることもできます。

I/O エラーによって I/O パスがブロックされた状態になり、さらにそのパス上の I/O が影響を受ける場合があります。そうした状況では、OS がユーザーに対して警告を表示し、ユーザーが定義したアクションを実行することが不可欠です。shdaemon は論理ボリューム・マネージャー を活用し、I/O 損失ハング検出および通知フィーチャーの一部として一定期間 I/O バッファーをモニターし、処理待ちの時間が長すぎる I/O がないかどうかをチェックします。shconf ファイルによって定義されたしきい値よりも待ち時間が長くなると、I/O 損失として検出され、さらなるアクションが実行されます。I/O 損失に関する情報はエラー・ログに記録されます。また、shconf ファイルの設定に基づき、I/O 損失状態から回復するためにシステムがリブートされる場合もあります。

IBM SmarterCloud Enterprise+ で I/O 損失ハング検出を構成するには、以下のように shconf コマンドを使用し、システムをリブートするためのアクションを設定します。

$: shconf -l lio -a lio_reboot=enable -a lio_to=Lost I/O timeout based up on SLA

異常終了検出

OS が異常終了した場合には、自動的に再起動させることによって動作を継続させる必要があります。IBM SmarterCloud Enterprise+ では、異常終了検出フィーチャーによって、chdev コマンドを使用したリブートが可能になります (chdev コマンドによって、システム・オブジェクトのデバイス・プロパティー autorestart が true に変更されます)。

$: chdev -l sys0 -a autorestart=true

上に戻る

まとめ

この記事で説明した HA フィーチャーにより、IBM SmarterCloud Enterprise+ はエンタープライズ市場で最も信頼性の高いクラウド・オファリングの 1つとなっており、常にビジネスの継続性を約束します。HA に関する要件を変更した場合にも、IBM SmarterCloud Enterprise+ では低い SLA レベルから高い SLA レベルに容易に変更することができます。

参考文献

• IBM SmarterCloud Enterprise+: IBM SmarterCloud Enterprise+ は完全に管理されたセキュアな本番対応のクラウド環境であり、エンタープライズ・クラスのパフォーマンスと可用性を確実に実現できるように設計されています。
  
  
• クラウド管理のサービス・レベル・アグリーメント: IBM SmarterCloud Enterprise+ の SLA パッケージについて学んでください。
  
  
• VMware vSphere API Reference Documentation: vSphere API を通じて利用可能なデータ構造のすべてについて説明した正式なドキュメントを調べてみてください。
  
  
• 「システム・ハング検出の構成」: AIX でシステム・ハングの検出を構成する方法についての資料を読んでください。
  
  
• 「クラウド・ベースの高可用性のための実用的な手法」(M. Tim Jones 著、developerWorks、2011年10月): ステートレスなフェイルオーバーやステートフルなフェイルオーバーなど、クラウド・ベースの高可用性を実現するための実用的な手法について、また HA システムに使用されるオープンソースの各種ソフトウェア・コンポーネントについて学んでください。
  
  
• 「ハイパーバイザー、仮想化、そしてクラウド」(Bhanu Tholett 著、developerWorks、2011年9月): この著者による連載記事を読み、クラウド内でシステムの仮想化を実現するための 5 つのハイパーバイザーに関して、それらの機能、デプロイメント・プロセス、VM 管理の問題について学んでください。
  
  

著者について

この記事を評価する

コメント

上に戻る

目次

• System x で HA を実現する
• System p で HA を実現する
• まとめ
• 参考文献
• 著者について
• コメント