IBM SmarterCloud Enterprise+ 内の仮想マシンで高可用性を実現する

クラウドにおける System x および System p 用の SLA ベースの高可用性

高可用性 (HA: High Availability) はクラウド・インフラストラクチャーにとって不可欠の特性です。この記事では、HA を確実に実現するために IBM SmarterCloud Enterprise+ に採用されている多面的な手法の概要について説明します。また、System x プラットフォームと System p プラットフォーム上で実行される仮想マシンで HA を実現するための詳細についても説明します。

Bhanu P Tholeti, Systems Engineer and Architect, IBM

Bhanuprakash はこれまで 8 年以上、ソフトウェア業界でさまざまな技術と製品に取り組んできました。今まで扱ってきた技術と製品には、Pocket PC でのアプリケーション開発、Web ベースのアプリケーション、動画配信ソリューション、そして Tivoli Workload Scheduler、WebSphere Data Interchange、Tivoli Service Automation Manager、Tivoli Provisioning Manager などがあります。IBM SmartCloud Enterprise の一員として、クラウド・インフラストラクチャーおよびハイパーバイザーに関する豊富な知識を培ってきました。



K. Sowjanya Chakravarthi, Systems Engineer, IBM

Sowjanya CK はこの 4 年以上 IBM に在籍しており、さまざまな製品に携わってきました。彼はこれまで、z/Linux への Tivoli Provisioning Manager のポーティング、Go Symphonyプラグインの開発、SCEplus の開発に携わってきました。



2012年 10月 18日

高可用性 (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 レベルに対して構成される再起動の優先順位とハートビートの値を示しています。

表 1. System x 上の VM に対する再起動の優先順位とハートビートの値
SLA再起動の優先順位ハートビートのタイムアウト間隔 (秒)*
プラチナhigh (高)30
ゴールドmedium (中)60
シルバーlow (低)120
ブロンズlow (低)180

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

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

VMware vSphere API による実装

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

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

リスト 1. 再起動の優先順位をプログラムによって構成する
// 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 データ・オブジェクトを渡す場合を示しています。

リスト 2. ハートビートの間隔をプログラムによって構成する
// 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 レベルで示しています。

表 2. System p で HA を実現するためのプロパティーに対する各 SLA の設定値
SLA優先順位に関する問題発生時のタイムアウト (秒)*I/O 損失ハング検出時のタイムアウト (秒)*クラッシュ検出
プラチナ1020enable (有効)
ゴールド2040enable (有効)
シルバー3560enable (有効)
ブロンズ60180enable (有効)

* 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 コマンドによって、システム・オブジェクトのデバイス・プロパティー autorestarttrue に変更されます)。

$: 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 管理の問題について学んでください。

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。プロフィールで選択した情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Cloud computing
ArticleID=840728
ArticleTitle=IBM SmarterCloud Enterprise+ 内の仮想マシンで高可用性を実現する
publish-date=10182012