目次


どこで?なぜ?IBM PureApplicationの仮想マシン配置処理を明らかにする

Comments

はじめに

IBM PureApplication Systemにはインテリジェントな仮想マシン配置エンジンが含まれており、ライセンスやCPU、メモリーの利用状況を最適化していると聞いたことがあるでしょう。また、この配置エンジンは、計算ノードが失われた場合にデプロイメントの可用性を確保してくれるとも聞いているでしょう。しかし、これらの仮想マシン配置が決定される際には、どんなことがおきているのだろうと、いつも不思議に思っていたかもしれません。なぜ配置エンジンはこの仮想マシンをここに配置し、あの仮想マシンをあそこに配置するという決定をしたんだろう? なぜ仮想マシンの計算ノード間の移動が発生した -もしくは発生しなかった- んだろう?

この記事では、PureApplication Systemの配置エンジンを細かく検討した上で、IBM PureApplication Softwareおよび PureApplication Service の配置エンジンの挙動の違いについて簡単に解説します。配置処理には2つの異なる層があること、それぞれがワークロードの負荷分散とリバランスで果たす役割について学ぶでしょう。またパターンが初期デプロイされた際、パターンがスケールした際、その他の変更が起こった際に、いかに配置処理の決定が行われるかを学びます。この変更には、計算ノードが障害で失われた場合やその他のデプロイメントが行われたり削除されたりする場合が含まれます。

2つの層からなる配置エンジン

PureApplication Systemには、仮想システム・インスタンスや仮想アプリケーション・インスタンスの仮想マシンの配置とリバランスを行う、2層からなる配置エンジンがあります。図1 はPureApplicationのPlatform as a Service (PaaS) および Infrastructure as a Service (IaaS) の2つの層で稼働する配置エンジンの役割を図示しています。またマルチ・システム・デプロイメントを利用して2システムにまたがってデプロイが行えること、さらにその場合に各システムにおいて配置エンジンの層がどう関わっているかも示しています。

図1.複数ロケーションにまたがってパターンをデプロイする際の、各配置処理の層の役割

第1層の配置処理

第1層の配置処理は、パターンを最初にデプロイした際に発生します。どのロケーション(PureApplication System)の、どのクラウド・グループ、どのIPグループに仮想マシンを配置するかを選ぶ際に、この層は利用されます。個々の仮想マシンに対してこれらの選択が行われると、仮想マシンは当初に選択されたクラウド・グループ外に移動することはできません(第2層の配置参照)。

複数ラックでのデプロイが行われる仮想マシンは、異なるクラウド・グループに分散される

1ラック内で管理される環境プロファイルにデプロイする場合には、全ての仮想マシンは同じクラウド・グループにデプロイされます。図2に示すように、デプロイメントの最初の画面でこのクラウド・グループを選択することができます。

図2.1ラック内で管理される環境プロファイルにデプロイする際のクラウド・グループの選択

しかし、複数ラック環境の環境プロファイルにデプロイする場合には、全てのマシンに対して単一のクラウド・グループを選ぶことはできません(図3

図3. 複数ラックの環境プロファイルでは、クラウド・グループは選べない

代わりに図4に示すように複数のクラウド・グループ、さらには複数のPureApplication Systemロケーションにまたがって、VMは分散配置されます。

図4. クラウド・グループとロケーションをまたがったVMの分散配置

この段階では、第1層の配置エンジンが関わってきます。配置エンジンはロケーションとクラウド・グループにまたがって仮想マシンの可能な配置について計算します。配置の決定についてお任せでよければ、クイック・デプロイをクリックして推奨配置を受け入れることができます。 図4に示されるような推奨配置を確認し、場合によっては変更したい場合には、デプロイの準備をクリックして推奨配置を確認することができます。図5はこのデプロイメントの選択肢について示しています。

図5. デプロイメント・ボタン

仮想マシンの配置を選択しデプロイを開始した後、配置エンジンの第1層は、配置について再度検討を行います(十分なIPアドレスがあるか、要求を満たす計算リソースがあるかなど)。もしキャパシティが十分で無い場合には、この時点でデプロイメントは拒否されます。

複数のPureApplication Systemロケーションにまたがってパターンをデプロイする場合には、配置処理の第1層が、全ての必要な作成物(仮想イメージ、スクリプト・パッケージ、アドオン、システム・プラグイン)がそれぞれのマシンに存在しているか、バージョンが一致しているかについて確認を行います。もしシステムで欠けているコンポーネントがあれば、 図6のように、そのデプロイメントは拒否されます。

図6. 複数ロケーションでの作成物の確認

第1層の配置エンジンは、デプロイされるパターンに含まれる各仮想マシンのコンポーネントは、それぞれ別に推奨配置を作成します。十分なキャパシティがあるのであれば、(ロケーションに関わらず)環境プロファイル内の全てのクラウド・グループに、各コンポーネントで均等に仮想マシンを最大限分散しようと試みます。2番目に考慮される点としては、均等な仮想マシン数のクラウド・グループ間の選択であれば、この層の配置エンジンは、より少ない仮想マシンが稼動しているロケーションを選択します。たとえば、ベース・スケーリング・ポリシーに基づく4インスタンスが存在する WebSphere® Application Serverのカスタム・ノードは、できるかぎりロケーションとクラウド・グループを分散して配置されます。しかし、WebSphere® Application Serverのデプロイメント・マネージャー(dmgr)ノードは、カスタム・ノードの配置とは独立して、カスタム・ノードの配置は考慮せずに、配置されます。このため、もしパターンの中に(dmgrやDB2ノードのような)シングルトンなノードが複数存在する場合には、それらが同じロケーションに配置されることも、別のロケーションの配置されることも、同じようにあり得ます。

第2層の配置

配置が検証され、デプロイメントが各ロケーションにサブミットされると、第2層の配置エンジンが稼働し、各クラウド・グループ内で、仮想マシンが配置される個々の計算ノードが決定されます。この層の配置処理がクラウド・グループに対する高可用性を強化します(仮想マシンの高可用性参照)。

このため、クラウド・グループが高可用性を確保できない場合には、デプロイメントは拒否されることがあります。各クラウド・グループ内で、第2層の配置エンジンは、同じデプロイメントで払出される CPUとメモリー設定が同一である全ての仮想マシンを、クラウド・グループ内の計算ノードにまたがって均等に展開(アンチ・コロケーション)しようと試みます。さらに、システムがライセンス管理を強化するよう構成されている場合には、たとえ仮想マシンを同一の計算ノードに乗せたり、デプロイメントを失敗させたりすることになっても、この層の配置処理は厳密にライセンスの超過が発生しないよう管理します。配置エンジンは同時に幾つものゴールを満たすよう最適化を考えるので、仮想マシンの分散やメモリーやCPUの割当てが、クラウド・グループ内の計算ノードで均等でないように見えることは珍しいことではありません。

計算ノードをまたいで仮想マシンを再配置する

PureApplicationでは、5分毎に再配置ジョブがスケジュールされています。ジョブは第2層の配置処理の中で実行され、各クラウド・グループ内の計算ノードにまたがって仮想マシンの現在のリソース割当てや使用率を比較します。再配置ジョブが、仮想マシンを動かすことにより計算ノードに対してよりよくバランスを取ることができる場合は、いくつかの仮想マシンに対して、計算ノード間のライブ・マイグレーションがスケジュールされます。
図7はジョブ・キューに登録されたシステム内部の再配置ジョブを示しています。

図7. 再配置ジョブが含まれているシステム・ジョブ・キュー

再配置ジョブは、計算ノードの仮想マシンの割当てを以下のように調節します:

  • 仮想マシンが削除や保管され、計算ノード上のスペースが開放された場合には、1)仮想マシン移動により、アンチ・コロケーション(できるだけ同じ計算ノードに配置しない)の目的をよりよく達成できる場合、または2)仮想マシンの移動によりライセンスの超過使用状況から回復できる場合には、再配置ジョブは仮想マシンを移動させる可能性があります。
  • クラウド・グループがCPUのオーバー・アロケーションを許すように構成(つまりクラウド・グループが「平均」に設定)されている場合、クラウド・グループ内でより効率的にCPUを利用できるのであれば、再配置ジョブは仮想マシンを移動させる可能性があります。計算ノード上に十分にリソース割当てを受けることができない仮想マシンがいてCPUの割当てを待っている一方で、別の計算ノードにCPU能力の余裕がある状況においては、移動先の計算ノードでリソース集中を起こさないのであれば、再配置ジョブはビジーな計算ノードから仮想マシンを移動させます。再配置ジョブは直近数分の仮想マシンの活動状況を考慮しています。

いくつかの仮想マシンが移動の候補となるのであれば、低い優先度の仮想マシンが選ばれます。 図8は仮想システム・インスタンス・ビューおよび仮想アプリケーション・インスタンス・ビューのデプロイメント優先度の表示です。デプロイメントのタイミングで優先度を設定することができますし、デプロイしたあとでも変更をクリックすることで変更することもできます。

図8. デプロイメント優先度

PureApplication Service と PureApplication Software

PureApplication ServiceとPureApplication Software はマルチ・クラウド またはマルチ・ロケーションを現時点ではサポートしていないという点で、PureApplication Systemと差異があります。結果として、複数のロケーションやクラウド・グループを選ぶという選択はおきないので、第1層の配置処理は適用されません。しかし、第2層の配置処理はPureApplication ServiceにおいてもPureApplication Softwareにおいても行われます。

より高度な考慮事項

PureApplication はシステムの振る舞いをカスタマイズできる方法をいくつか提供しています。オプションとして、高可用性モードでシステムを構成することもできますし、第1層の配置処理に影響を与える配置ポリシーを作成することもできます。これらの構成を採用する前に、これらの構成を採用した際の配置エンジンの挙動を理解しておく必要があります。また、GPFSクラスターをデプロイする際には重要な制約が存在します。

仮想マシンの高可用性

計算ノードに障害が発生した場合に備えて、高可用性のためのリソースを予約するようクラウド・グループを構成することもできます。その際、図9にあるように幾つかの選択肢があります。

図9.クラウド・グループの高可用性のための選択肢

システム・レベルでリソースを予約しておく場合には、システム全体で1つかそれ以上の計算ノードをスペアとして指定することができます。クラウド・グループ内の計算ノードに障害が発生した場合には、スペアの計算ノードが自動的にクラウド・グループに追加され、回復された計算ノードで、障害となっていた仮想マシンは再起動されます。

クラウド・グループ・レベルでリソースを予約しておく場合には、計算ノード1つ分のキャパシティがクラウド・グループ内で予約され、このリソースはデプロイメントに利用することができません。クラウド・グループ内の計算ノードに障害が発生した場合には、クラウド・グループ内の障害が発生していない計算ノード上の予約されたリソースに仮想マシンは移動され、再起動されます。

第2層の配置処理は、クラウド・グループ内に含まれる計算ノード数に応じて、各計算ノード上に確保する予備スペースを算出していることに注意してください。もし4つの計算ノードがあるのであれば、各計算ノードで1/4のCPUとメモリーが高可用性のために確保されます。新しくデプロイメントする際においても、配置エンジンはこの予備スペースを確保できるよう稼働し、以下のように再配置ジョブが仮想マシンの計算ノードを移動させることもありえます:

  • 各計算ノードの予備スペースを確保するため(たとえば、仮想マシンに割り当てるCPUやメモリーを増やした場合など)
  • 予備スペースを復旧するため(たとえば、障害が発生した計算ノードが復旧した場合や保守モードに設定されていた計算ノードが復帰した場合など)

リソースを予め確保しない場合であっても、計算ノードに障害が発生した際にクラウド・グループ内のキャパシティに余裕があるかもしれません。その場合には、クラウド・グループ内の障害が発生していない計算ノードに、優先度の順に応じて、できるだけ多くの仮想マシンを移動できるようシステムは試みます。優先度を変更するには、図8で示した方法で、デプロイメント優先度を変更します。

クラウドの高可用性ページにアクセスするとこで、システム内のクラウド・グループの高可用性のステータスを一覧することができます(図10)。

図10. システム高可用性サマリー

水平スケーリング

自動水平スケーリングまたは手動スケーリングを利用している場合、インスタンスが仮想マシンを増やす際の配置エンジンの挙動について考えておく必要があります。

スケール・アウト

新しい仮想マシンがスケール・アウトされる際、第1層の配置エンジンが呼ばれ、新しい仮想マシンがスケールされるクラウド・グループとロケーションが選ばれます。PureApplication System V2.1では、新しい仮想マシンは同じ仮想マシン・インスタンスが既に稼働しているクラウド・グループのみでスケール・アウトされます。PureApplication System V2.2より、既存の仮想マシン・インスタンスが存在しない環境であっても、作成物とキャパシティのチェックを満たすことができれば、いかなるロケーションやクラウド・グループであっても、新しい仮想マシンはスケールすることができます。いずれの場合も、第1層の配置処理は最も少ない仮想マシンのクラウド・グループまたはシステムを選ぼうとし、選べない場合はランダムでクラウド・グループを選択します。

仮想マシンが起動すると、第2層の配置処理が稼働し、仮想マシンが実行される計算ノードが選ばれます。できるだけ、第2層の配置処理は、同一のデプロイメントに含まれる同一のCPUとメモリー設定を持っている他の仮想マシンとは、別の計算ノードに分散しようと試みます。

スケール・イン

仮想マシンが自動スケーリングまたは手動スケーリングで仮想マシンが削除された際、配置エンジンが削除する仮想マシンを選ぶために呼び出されることはありません。代わりに、スケーリング・エージェントが以下のステップに従い、仮想マシンを選択します:

  1. 実行中ではない仮想マシンを探す
  2. 実行中ではないロールをもつ仮想マシンを探す
  3. 最も少ないCPU使用率の仮想マシンを探す
  4. CPU使用率が一緒であれば、ランダムで仮想マシンを選ぶ

ただし、スケーリング・エージェントは、デプロイメントのマスター仮想マシンを削除する仮想マシンとしては選びません。マスター仮想マシンには、パターン・インスタンスのインスタンス・コンソールが稼働しているからです。

どの仮想マシンがマスターかを判断するには、デプロイメントの管理ユーザー・インターフェースにアクセスし「管理」をクリックします。ブラウザーに表示されるIPアドレスを確認してください。このアドレスがデプロイメントのマスター仮想マシンのIPアドレスです。

配置ポリシー

パターン・エディターで仮想マシンに配置ポリシーを追加することで、第1層の配置処理の決定プロセスに影響を与えることができます(図11)。

図11. 配置ポリシー・コンポーネント

配置ポリシーは仮想マシンの第1層の配置処理に影響を与えます。第1層の配置処理は、単一の仮想マシン・コンポーネントのインスタンスを、クラウド・グループおよびロケーションをまたいでできるだけ同居しないよう配置することがデフォルトの挙動であることを思い出してください。この配置ポリシーを利用することで、ロケーション(PureApplication System)またはクラウド・グループをまたがって、仮想マシンを配置する際に、コロケーションをハード制約とするのかソフト制約とするのか、アンチ・コロケーションとするのか指定することができます。制約が満たされない場合、ハード制約であればパターンのデプロイは失敗し、ソフト制約であれば制約が満たされない場合でも、パターンのデプロイは継続されます。

配置ポリシーを利用して、パターン・エディター上で異なる仮想マシン・コンポーネント間の配置の振る舞いに影響を与えることはできない点に注意してください。配置ポリシーは、単一の仮想マシンのスケールしたインスタンスの挙動の制御のみに利用できます。このポリシーは初期デプロイのタイミングおよび水平スケーリングを実施したタイミングの仮想マシン配置に影響します。

General Parallel File System (GPFS) および共有ブロック・ストレージ

PureApplicationのIntel® 環境(PureApplication System, PureApplication Software および PureApplication Service)では、IBM Pattern for GPFS™を利用して、複数ノードからなるGPFSクラスターをデプロイすることが可能です。クラスターには複数のGPFSサーバー仮想マシンが存在し、単一のブロック・ストレージをパフォーマンスと可用性を向上させて共有することが可能です。IBM POWER® 環境では、PureApplication System と PureApplication Software (V2.2以降) が 複数ノードGPFSクラスターをサポートします。

GPFSパターンは、そのトポロジーにおいて特殊な配置要件を守るよう実装されています。これにより、GPFS仮想マシンは、 (1) 強制的に異なる計算ノードに分散され、また (2) その計算ノードに固定され、たとえ計算ノードに障害が発生してもVM移動が発生しません。これによりGPFSクラスターの高可用性が絶対的に確保されます。3ノードからなるクラスターでは、もしいかなる仮想マシンが同じ計算ノードに配置されてしまっても、その計算ノードに障害が発生した場合にはクラスターが利用できなくなるからです。

これらの特殊な配置要件は、仮想システム・パターン・エディターでは利用できません。DB2® pureScale®, Oracle®, Real Application Clusters (RAC), または Microsoft® Windows® クラスタリング などのために、パターン内で共有ブロック・ストレージを利用したい場合には、IBMにコンタクトして、パターン・トポロジーにこの特殊な配置要件を実装する支援を受けてください。

自動リバランスを無効化して、手動で仮想マシンを移動させる

PureApplicationの第2層の自動リバランス機能を無効化したいというお客様もたまにいらっしゃいます。たとえば高可用性クラスタリング・ソリューションを持っており、仮想マシンの配置を手動で管理したい場合には、自動リバランス機能を無効化したいかもしれません。PureApplication System は、この目的のためのREST APIを提供しています。リソース・セクションに、自動リバランスを無効化し手動で仮想マシンを移動するための情報があります。

IBMは再配置機能を有効化したまま、PureApplicationの配置エンジンが仮想マシンの配置を管理することを推奨しています。

まとめ

この記事では、PureApplication Systemで配置エンジンがどのように稼働しているかを学び、PureApplication Software および PureApplication Serviceでその配置エンジンの役割がどう異なるか学びました。パターンの初期デプロイの際に、さらに後にパターンがスケールして仮想マシンを追加・削除した際に、2つの層の配置処理が仮想マシンを配置場所をどう決定しているかを学びました。この記事では、仮想マシンの利用状況をリバランスするために第2層の配置処理がおこなう決定についても解説しました。さらに可用性計画のための様々なオプションについて解説し、計算ノードに障害が発生した際に、第2層の配置処理がどう可用性を実現するかを解説しました。


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=WebSphere
ArticleID=1032245
ArticleTitle=どこで?なぜ?IBM PureApplicationの仮想マシン配置処理を明らかにする
publish-date=06062016