IBM PureApplication System でアプリケーション・ランタイム環境を管理する

IBM PureApplication System では、管理者がクラウド・グループと環境プロファイルを使用して定義したランタイム環境に、デプロイヤーがアプリケーションをデプロイします。PureApplication System をセットアップする管理者として、検討および作成しなければならないクラウド・グループおよび環境プロファイルについて学んでください。

Bobby Woolf, Certified Consulting IT Specialist, IBM

Photo of Bobby WoolfBobby Woolf は、IBM PureApplication System、サービス指向アーキテクチャー、イベント駆動型アーキテクチャー、アプリケーション統合に重点に取り組む IBM Software Services for WebSphere (ISSW) のコンサルタントです。『Exploring IBM SOA Technology and Practice』の著者であり、共同で『Enterprise Integration Patterns』および『The Design Patterns Smalltalk Companion』を執筆しました。



2012年 11月 15日

はじめに

IBM PureApplication System W1500 V1.0 (以降、PureApplication System とします) では、管理者がクラウド・グループと環境プロファイルを使用して定義したランタイム環境に、デプロイヤーがアプリケーション (パターン・インスタンスと呼ばれます) をデプロイします。PureApplication System をセットアップする管理者として検討および作成しなければならないクラウド・グループおよび環境プロファイルとは何なのでしょうか?

通常、アプリケーション開発サイクルには、開発の各ステージで個別のランタイム環境が必要になります。必要な環境として例えば、DEV、TEST、PROD があるとすると、これらの環境を互いに切り離すことで、各ステージでのアクティビティーが互いに干渉しないようにしなければなりません。それと同じく、TEST 環境やPROD 環境では、デプロイされるアプリケーションごとに、さらに環境を分割しなければならないこともあります。このように環境を分離するための手段として、PureApplication System のクラウド・グループと環境プロファイルをどのように利用できるのでしょうか?

必要となるクラウド・グループと環境プロファイルを知るには、まず、この 2 つの製品機能が存在する目的を理解しなければなりません。それは、クラウド・コンピューティングの目標と、ハードウェア・リソースが仮想化される仕組みを理解することを意味します。記事ではクラウドの概念を説明した後、PureApplication System に用意されている仮想リソースの管理機能について説明します。その上で、これらの管理機能を利用するためのストラテジーを紹介します。さらに、これらのストラテジーから推論できる原則についても検討します。


クラウドの概念

PureApplication System を理解するために、まずはクラウド・コンピューティングの基本概念をおさらいしておきましょう。

クラウド・コンピューティングでは、複数のワークロード (一般に、実行中のプログラムと呼ばれます) が必要に応じて計算リソースを共有することができます。その制御された方法では、すべてのワークロードを並列に実行することができます。この仕組みを実現するためには、以下の相反する目標を達成しなければなりません。

  • 分離: ワークロードを互いに独立させて、あるワークロードの問題 (例えば、暴走プロセスによって CPU またはメモリーが使い果たされてしまうなど) が他のワークロードに影響しないようにすること。
  • 共有: ワークロードに共通のリソース・プールからリソースを取得させて、一部のワークロードがリソースを必要としない間、他のワークロードがより多くのリソースを使用できるようにすること。
  • 割り当て: 各ワークロードまたは関連するワークロード・セットが利用できる共有リソースに制限を設けることで、ワークロードがリソース使用量の増大を制限して正当な取り分以上の共有リソースを使用しないようにする一方で、最小限のリソースでワークロードが正常に実行されることを確実にすること。

これらの相反する目標をバランス良く達成しなければなりません。すべてのワークロードを完全に分離したとすると、それは個々のアプリケーションをそれぞれ異なるハードウェアにデプロイする古いコンピューティング・モデルと同じことになってしまいます。ワークロードがすべてのリソースを共有するとしたら、いち早くリソースの大部分を取得したワークロードによって、残りのワークロードがリソース不足に陥ってしまいます。分離と共有のバランスを取るには、割り当てを使用します。割り当てによって、ワークロードをグループに分け、グループ内での共有を可能にして、各グループが共通のリソース・プールからリソースを取得できるようにしながらも、グループごとに取得できるリソース量を制限します。このようにすれば、すべてのワークロードが公平にリソースを取得できるので、リソースの競合を解決するにはとりわけ役立ちます。

リソースの分離

「リソースの分離」は、リソースのセットの間にいわゆる「壁」を設け、それぞれのリソースが独立して使われることを可能にします。壁で隔てられたある領域の問題が、他の同じく壁で隔てられた領域に影響することはありません。したがって、壁が設けられた領域の間でリソースを共有することは不可能です。

クラウド・コンピューティングにおける分離には、2 つの主要な側面があります。

  • コンピューターの分離: CPU とメモリーのキャパシティーからなる各グループは、互いに分離されます。互いに分離されたコンピューターで 2 つのワークロードが実行される場合、一方のワークロードによるリソースの使用が、もう一方のワークロードに影響することはありません。この分離は、物理的な分離にすることも、仮想的な分離にすることもできます。
    • コンピューターの物理的分離: 専用リソースとも呼ばれます。各リソースのグループは、回路基盤上の個々のチップで構成されます。
    • コンピューターの仮想的分離: 仮想リソースとも呼ばれます。仮想化層によってグループ化されるリソースは、一見したところ分離されたリソースのグループですが、これらのリソースが実際に同じチップを共有する場合もあります。実際の仮想的分離は、その分離を実装するバーチャライザー (通常はハイパーバイザー) によって決まります。
  • ネットワークの分離: 計算リソース間の通信フローは、個別の接続を介して行われます。この分離は、物理的な分離にすることも、論理的な分離にすることもできます。
    • ネットワークの物理的分離: 別々のネットワーク機器 (ネットワーク・インターフェース・カード (Network Interface Card: NIC)、ケーブル、スイッチなど) 上で、別個のネットワーク接続が実行されます。これにより、あるネットワークに対してハードウェア上で送信される信号が、別のネットワークに送信されることは決してありません。
    • ネットワークの論理的分離: 同じネットワーク機器上で、別個のネットワーク接続が実行されます。これらのネットワーク接続は同じ帯域幅を共有しますが、それぞれのパケットは、共有ハードウェアから異なるブロードキャスト・ドメインを介して別々にルーティングされます。通常、ブロードキャスト・ドメインが仮想ローカル・エリア・ネットワーク (Virtual Local Area Network: VLAN) として実装されます。

リソースの共有

「リソースの共有」は、複数のワークロードが複数の共有リソース・プールからリソースを取得できるようにします。ワークロードにとって、プールからどのリソースを取得するかは重要ではありません。これらのリソースはすべて同等であり、どれを使用するにしても変わりはありません。ワークロードが相当な量のリソースを必要とするときにはプールから多数のアイテムを取得し、そうでなければ少数のアイテムを取得します。リソースを使用し終わると、そのリソースを解放してプールに戻します。

リソースを共有する利点は、リソースの需要が少なくなったワークロードから、より多くのリソースを必要とするワークロードに動的にリソースを割り当てられることです。その一方、不正な動作をするワークロードがプールのリソースを使用しすぎると、他のワークロードでのリソース不足を招く結果になります。

リソースの割り当て

「リソースの割り当て」(「論理的分離」とも呼ばれます) は、リソースの共有に下限と上限を設けて、ワークロードに境界を設定する手法です。割り当てにより、ワークロードはプールから必要最小限のリソースを取得できることが確実になる一方、公平に配分された以上のリソースを使用することはできなくなります。割り当ての制限はあらゆる共有リソースに設定することができます。これには、CPU、メモリー、ストレージ、帯域幅、さらにはソフトウェア・ライセンスまでも含まれます。例えば、同じプールを共有する 2 つのワークロードのそれぞれに許容する CPU を 5 から 10 までの範囲に指定すると、各ワークロードで最小 5 個の CPU を使用できることが保証される一方、ワークロードが大きくなっても、10 個を超える CPU は与えられません。

割り当ては分離と共有のバランスを取り、リソースを共有せずにすべてのワークロードが独自の専用リソースを使用する場合と、共有が制御されずに、どのワークロードにも共有リソースの独占が許される場合との間の適切な中間点を見つけます。割り当てによって、共有は制限内でのみ可能になります。


PureApplication System の環境機能

ワークロードを分離すると同時にリソースを共有するために PureApplication System を最大限有効に利用する方法を理解するには、この製品に用意されている、リソースをクラウドとして共有するための主要な機能を知ることが役に立ちます。

パターン・インスタンスをデプロイして実行する際には、PureApplication System の 5 つのタイプのシステム・リソースが関係してきます。これらのシステム・リソースが、パターンをデプロイするために使用できるランタイム環境を定義し、パターン・インスタンスを実行するために使用可能なリソースを制御します。システム・リソースの 5 つのタイプは、以下のとおりです。

  • 計算ノード: CPU とメモリーを含むコンピューター・ハードウェアのセットであり、ストレージとネットワークにアクセスします。
  • IP グループ: IP アドレスのリストまたは範囲、これらの IP アドレスが属する VLAN の ID、そしてその VLAN が含まれる外部ネットワークへの接続方法を設定します。
  • クラウド・グループ: 1 つ以上の計算ノードと 1 つ以上の IP グループの集合です。クラウド・グループは、実質的には論理コンピューターであり、物理的にリソースを分離します。
  • 環境プロファイル: クラウド・グループへのパターンのデプロイメントに関するポリシーです。リソースを割り当てることにより、リソースを論理的に分離します。
  • ユーザー・グループ: 同じロールを割り当てられたユーザーのリストです。

環境プロファイルでは、ユーザー・グループをクラウド・グループに関連付けることにより、そのユーザー・グループに含まれるユーザーが、そのユーザー・グループに関連付けられたクラウド・グループにパターンをデプロイできるようにします (図 1 を参照)。さらに環境プロファイルでは、ユーザー・グループにアクセス権限を付与することで、その環境プロファイルを使用してパターンをデプロイできるユーザーを指定します。1 つの環境プロファイルで、複数のユーザー・グループにアクセス権限を付与することができます。また、1 つのユーザー・グループに対して、複数の環境プロファイルを使用する権限を付与することができます。環境プロファイルでは、デプロイ先として設定可能なクラウド・グループも指定します。複数の環境プロファイルで同じ 1 つのクラウド・グループをデプロイ先として指定することも、1 つの環境プロファイルで複数のクラウド・グループをデプロイ先として指定することもできます。

図 1. PureApplication System リソース間の関係
PureApplication System リソース間の関係

図 2 に一例として、これらのシステム・リソースのインスタンスを示します。

図 2. 典型的な PureApplication System リソースのインスタンス
典型的な PureApplication System リソースのインスタンス

ユーザー・グループ、環境プロファイル、クラウド・グループの所定の組み合わせで、それぞれのリソースが指定する内容は以下のとおりです。

  • ユーザー・グループは、環境プロファイルを使用してパターンをデプロイできるユーザーを指定します。
  • 環境プロファイルは、特定のユーザーが特定のクラウド・グループに対してパターンをデプロイできることを指定します。
  • クラウド・グループは、デプロイされるパターン (パターン・インスタンス) を実行するハードウェア (具体的には、計算ノードと IP グループ) を指定します。

パターン・インスタンスのデプロイ時にそのインスタンスに割り当てるクラウド・グループ内のリソースは、環境プロファイルの設定によって制御されます。これらの設定がパターン・インスタンスでの設定となり、クラウド・グループを実行する方法、そしてインスタンスを管理する方法が制御されます。この仕組みは、同じクラウド・グループ内で複数のパターン・インスタンスをデプロイして実行する方法を調整し、制御するのに役立ちます。複数のインスタンスが異なる環境プロファイルを使用してデプロイされる場合は、それぞれのインスタンスが異なるリソースを異なる制限内で使用するように設定することができます (詳細については、「環境プロファイル」のセクションを参照)。

PureApplication System 管理コンソールは、以下の 2 つのメイン・タブに分かれています。

  • System Console (システム・コンソール): 管理者ロール用のタブで、PureApplication System のハードウェアを操作することができます。ハードウェア管理者 (PureApplication System を管理するユーザー) が管理することを意図して作られています。
  • Workload Console (ワークロード・コンソール): デプロイヤー・ロール用のタブで、PureApplication System のワークロードを作成することができます。ワークロード管理者 (PureApplication System 上でパターンの開発やデプロイを行うユーザーなど) が管理することを意図して作られています。

クラウド・グループはシステム・コンソールで管理される一方、環境プロファイルはワークロード・コンソールで管理されます。パターン・デプロイヤーがデプロイメント・ターゲットとして検討しなければないのは、クラウド・グループではなく環境プロファイルですが、クラウド・グループを抽象化して見えなくする手段として環境プロファイルだけにフォーカスすると、抽象化に落ち度が出てきます。というのも、パターンをデプロイするときには環境プロファイルを選択しますが、デプロイメントの後、仮想部分のそれぞれについて、クラウド・グループを選択するか、少なくともデフォルトを受け入れる必要があるからです。

計算ノード

「計算ノード」は本質的にはコンピューターであり、どちらかといえばブレード・サーバーのようなものです。コンピューターであることから、計算ノードはオペレーティング・システムを実行することができます。ただし、PureApplication System では、計算ノードが実行するのは従来のオペレーティング・システムではなく、ハイパーバイザーです。以下に、計算ノードに関して知っておく必要がある情報を要約します。ハードウェアの詳細に興味がある場合は、「PureApplication System のハードウェア能力」のセクションを参照してください。

計算ノードは以下のもので構成されます。

  • CPU: 16 基の物理コア (32 基の論理コア) を含む Intel 計算ノード
  • メモリー: 256 GB の RAM を含む Intel 計算ノード

計算ノードがアクセスする以下のリソースは、すべての計算ノードで共有されます。

  • ストレージ: PureApplication System には 2 台の IBM Storwize V7000 ストレージ・ユニットが組み込まれており、6.4 TB の SSD および 48 TB の HDD のストレージを SAN ストレージとして使用します。
  • ネットワーク: PureApplication System には 2 台の BNT (BLADE Network Technologies) 64 ポート・イーサネット・スイッチが組み込まれています。この 2 台が内部ネットワーク・ハードウェアのハブとなり、企業のネットワークへの接続手段となります。

IP グループ

「IP グループ」は、IP アドレスのリストまたは範囲です。1 つのアドレスは、1 つの IP グループにしか属することができません。IP グループには、そのグループに含まれる IP アドレスが属する VLAN の ID、そしてその VLAN が含まれる外部ネットワークへの接続方法も設定されます。

IP グループには以下の 3 つの機能があります。

  • 動的 IP アドレス共有: IP グループは、IP アドレスの共有プールです。アプリケーション (パターン・インスタンスとも呼ばれます) を実行する仮想マシンをデプロイするときには、このプールから IP アドレスが選択されます。
  • IP アドレス・プールの分離: 2 つのチームがそれぞれに異なる IP グループを使用できるため、一方のチームが過剰な数のアプリケーションをデプロイして IP グループのすべての IP アドレスを使い果たしたとしても、それとは異なる IP アドレス・プールを使用するもう一方のチームは、アプリケーションを引き続きデプロイすることができます。
  • ネットワークの論理的分離: IP グループの VLAN ID によって指定された VLAN により、その IP グループのアプリケーションは論理的に分離されたネットワーク上で通信することができます。これは、それぞれ異なる VLAN ID が設定された 2 つの IP グループを使用するアプリケーションのネットワーク・トラフィックは、(一見したところ) 独立したネットワークで伝送されることを意味します。このような分離が役立つのは、例えばパターンの HTTP サーバーを、WebSphere Application Server カスタム・ノードとアプリケーション・サーバーとは別のネットワークにデプロイして、この 2 つの層の間にネットワーク・ファイウォールを配置する場合です。また、関連性のないアプリケーションのネットワーク・トラフィックを分離する場合にも同じく役立ちます (例えば、開発環境と本番環境の間や、経理部と人事部の間でネットワーク・トラフィックを分離する場合など)。

IP グループは、あらかじめ企業のネットワーク管理者が IP グループのすべての設定を指定していなければ定義することができません。必要な設定には、IP アドレスのセット、VLAN ID、そして企業ネットワークの接続方法を指定するその他の設定 (ゲートウェイ、サブネット、DNS ホストなど) が含まれます。PureApplication System の管理者はこれらの設定を選ぶことはできません。ネットワーク管理者によって指定された設定を使用して、IP グループを定義します。

ネットワーク管理者が指定した所定のネットワーク設定のセットから、PureApplication System の管理者はセットアップする IP グループの数を決定します。ネットワーク管理者が指定するのは以下の内容です。

  • 一連のネットワーク設定 (ゲートウェイ、サブネット、DNS など)
  • ネットワーク上の VLAN の ID
  • VLAN 上の一連の IP アドレス

PureApplication System の管理者はこれらの設定を、1 つ以上の IP グループとして取り込みます。それぞれの IP グループのネットワーク設定と VLAN ID は同じです。違いは、IP アドレスのセットを複数の IP グループに分割できることにあります。1 つの IP アドレスが属する IP グループは 1 つに限られるため、IP グループの数は最小 1 つから最大で IP アドレスのセットに含まれるアドレスの数と同じにすることができます。例えば、セットに 10 個の IP アドレスが含まれている場合、以下のどの構成にすることもできます。

  • 10 個の IP アドレスをすべて含む 1 つの IP グループ
  • IP アドレスを 5 個ずつ含む 2 つの IP グループ
  • それぞれ 1 個の IP アドレスを含む 10 の IP グループ

どの構成にしたとしても、各グループの VLAN ID とその他のネットワーク設定は共通しています。グループ間で異なるのは、IP アドレスのセットだけです。

クラウド・グループ

「クラウド・グループ」が達成する主な目標は 2 つあります。

  1. システムの区分: PureApplication System を 1 つ以上の論理コンピューターに区分します。これらのクラウド・グループは、それぞれに独立して実行されます。
  2. 計算ノードの集約: 1 つ以上の計算ノードと 1 つ以上の IP グループをまとめて 1 つの論理コンピューターにグループ化し、単一のノードよりも大きなキャパシティーを実現します。

図 1 では、クラウド・グループ (Cloud group)、計算ノード (Compute node)、IP グループ (IP group) の間の関係を示しましたが、この図に示されているように、クラウド・グループには計算ノードと IP グループが含まれます。

クラウド・グループには、計算ノードと IP グループが含まれる他、3 つの主要なプロパティーがあります。

  • name (名前): クラウド・グループの名前です (例えば、「DEV」、「TEST」、「PROD」など)。
  • type (タイプ): この設定は、パターンのデプロイ時にリソース (具体的には CPU) を仮想マシン (Virtual Machine: VM) に割り当てる方法を定義します。この設定により、特定の VM だけでなく、環境プロファイルを使用してデプロイされるすべての VM で使用可能な CPU キャパシティーが決まるため、特に、複数のアプリケーションでユーザー負荷が高くなる場合に重要な意味を持ちます。
    • dedicated (専用): CPU の過剰割り当てはありません。通常の状態でユーザー負荷が高いアプリケーションに適しています。
      • 1 個の仮想 CPU = 1 個の物理 CPU
      • Intel 計算ノード上の 16 個のコアを 16 個の CPU として割り当てます。
      • この設定は、デプロイされたパターンの VM が、その VM に割り当てられた CPU キャパシティーを駆使することを意味します。これは、頻繁に高いユーザー負荷がかかるアプリケーションではありがちなことです。
      • この設定では、クラウド・グループにデプロイできるパターンの数が少なくなりますが、CPU の過剰割り当てによるリソース競合は回避されます。
    • average (平均): 4 対 1 の CPU 過剰割り当て。通常の状態ではユーザー負荷が低いアプリケーションに適しています。
      • 4 個の仮想 CPU = 1 個の物理 CPU
      • Intel 計算ノード上の 16 個のコアを 64 個の CPU として割り当てます。
      • この設定は、デプロイされたパターンの VM が、その VM に割り当てられた CPU キャパシティーをフルには使用しないことを意味します。これは、使用可能な状態でなければならない一方、頻繁には使用されないアプリケーションにありがちなことです。
      • この設定では、クラウド・グループにデプロイできるパターンの数が増えます。ただし、この CPU 過剰割り当てでは、アプリケーションが駆使されると、リソースの競合によってパフォーマンスが劣化することを意味します。
  • management VLAN ID (管理 VLAN ID): クラウド・グループが VM 間の内部通信を可能にするために使用する VLAN の ID です。この VLAN ID は、ネットワークで使用されていないものでなければなりません。VM には IP グループからのアドレスが割り当てられるため、この VLAN に IP アドレスは不要です。

クラウド・グループは、1 つの巨大な論理コンピューターのように機能します。クラウド・グループで実行される各仮想マシンは、クラウド・グループの計算ノードのうちの 1 つで実行され、複数の IP グループのいずれか 1 つに含まれる IP アドレスのうちの 1 つが割り当てられます。IP アドレスの割り当ては、以下のライフサイクルに従います。

  • パターンがデプロイされると、VM に IP アドレスが割り当てられます (つまり、作成中のパターン・インタンスの一部として VM が作成されるときに、IP アドレスの割り当てが行われます)。
  • VM に割り当てられた IP アドレスは、パターン・インスタンスが停止または保管されるとしても、割り当てられたままになります。
  • パターン・インスタンスが削除されると、IP アドレスが IP グループに返されます。

1 つの計算ノードが属することのできるクラウド・グループは、(最大で) 1 つだけです。通常、クラウド・グループには 2 つ以上の計算ノードが含まれます。これは、いずれか 1 つのノードで障害が発生してもクラウド・グループが実行状態を維持できるようにするためです。このことから、1 つの PureApplication System でサポートできるクラウド・グループの数は制限されます。例えば、小規模な Intel 構成に 6 つの計算ノードがあるとします。この場合、この構成でサポートできるのは最大 6 つのクラウド・グループですが、(グループごとに 2 つの計算ノードがあるとすると) 実際にサポートされるのは 3 つのクラウド・グループに限られます。クラウド・グループごとに固有の管理 VLAN も必要となるため、ネットワーク管理者が割り当てる VLAN の数によって、作成できるクラウド・グループの数は制限されます。

クラウド・グループは、あるグループで実行されるプロセスが、他のグループで実行されるプロセスに影響されることのないように、ランタイム環境を分離します。

環境プロファイル

「環境プロファイル」では、パターンを 1 つ以上のクラウド・グループにデプロイする方法と、パターン・インスタンスをクラウド・グループで実行する方法に関するポリシーを定義します。ユーザーはパターンをデプロイする際に、そのデプロイメントに使用する環境プロファイルを選択します。環境プロファイルには、デプロイヤーがパターンをデプロイできるクラウド・グループが記載されています。したがって、デプロイヤーは環境プロファイルにはパターンのデプロイ先が記載されていると考える必要があります。環境プロファイルに従ってパターン・インスタンスがクラウド・グループにデプロイされるという点に関しては、システム・レベルの詳細であるため、デプロイヤーなどのワークロード・レベルのユーザーが認識する必要はありません。

環境プロファイルは、以下の構成設定を指定します。

  • Access granted to (アクセス権限の付与先): この環境プロファイルを使用してパターンをデプロイすることを許可する対象のユーザーです。
  • Deploy to cloud groups (デプロイ先のクラウド・グループ): この環境プロファイルに従ってパターンをデプロイする宛先として使用できるクラウド・グループと、環境プロファイルでクラウド・グループごとに使用できる IP グループのリストです。
  • IP addresses provided (IP アドレスの指定): IP グループから IP アドレスを割り当てる方法です。
    • IP Groups (IP グループ): デプロイメント・プロセスで IP アドレスが自動的に選択されます。
    • Pattern Deployer (パターン・デプロイヤー): ユーザーがデプロイ時に手動で IP アドレスを選択します。
  • Environment limits (環境の制限): この環境プロファイルでデプロイされるパターン・インスタンスが使用できるリソースを制限します。
    • Computational resource (計算リソース): CPU、メモリー、ストレージなどのリソース
    • Licenses (ライセンス): 製品ごとの PVU (Processor Value Unit: プロセッサー・バリュー・ユニット)
  • Virtual machine name format (仮想マシン名のフォーマット): 仮想マシンを作成するときに使用される命名規則です。
  • Deployment priority (デプロイメントの優先順位): リソースの競合 (デプロイメント、ランタイム・リソース、およびフェイルオーバー) を処理する際にパターン・インスタンスに優先順位を付けるために使用される設定です。指定できる優先順位のレベルは、Platinum (プラチナ)、Golden (金)、Silver (銀)、Bronze (銅) です。
  • Environment (環境): 環境が果たすロール (役割) のリストです。これは、ユーザーに便宜を図るためのラベルであり、システムには無視されます。設定可能なロールの例としては、「Production (本番)」、「Test (テスト)」などがあります。

複数の環境プロファイルで同じ 1 つのクラウド・グループをデプロイ先にすることも、1 つの環境プロファイルで複数のクラウド・グループをデプロイ先にすることもできます (図 1図 2 を参照)。すべてのデプロイヤーが、システムのすべての環境プロファイルにアクセスできるわけではありません (次の「ユーザー・グループ」のセクションを参照)。ある特定のクラウド・グループにデプロイするには、そのクラウド・グループに対するデプロイメントを実行可能な環境プロファイルに、デプロイヤーがアクセスする必要があります。そしてその環境プロファイルに、パターンをデプロイする方法に関するポリシーを設定します。

さまざまな環境プロファイルを使用して、ユーザーは同じパターンを同じクラウド・グループにデプロイし、しかも異なる制限と異なる設定をそのパターン・インスタンスに適用することができます。あるパターン・インスタンスをデプロイするように設定された環境プロファイルを使用すると、クラウド・グループの共有リソースの一部がパターン・インスタンスに割り当てられてインスタンスが論理的に分離されます。環境プロファイルでは、同じクラウド・グループに対してデプロイを行う複数の異なるチームに対し、リソースを多く使い過ぎたり (例えば同じ IP グループ (つまり、すべてのIP アドレス) を使用するなど)、CPU キャパシティーを大量に使い過ぎたりしないようにするために、それぞれのチームのパターン・インスタンスが論理的に分離されるように制限を設定することができます。また、環境プロファイルには、クラウド・グループがインスタンスを実行する際に適用されるパターン・インスタンスのプロパティーも設定します。

2 つのユーザー・グループが環境プロファイルを共有する場合 (つまり、両方のユーザー・グループが 1 つの環境プロファイルに割り当てられる場合)、それは、この 2 つのユーザー・グループが同じパターン・デプロイメント・ポリシーを使用し、パターン・インスタンスが同じリソース割り当てを共有することを意味します。それぞれのユーザー・グループに異なるポリシーまたは異なるリソース割り当てを使用させるには、各グループをそれぞれ固有の環境プロファイルに割り当てる必要があります。2 つのグループが同じ環境プロファイルを共有するということは、両方のグループのデプロイメント数が同じ制限に対して計上されるということです。2 つのグループがそれぞれ異なる環境プロファイルを使用する場合には、それぞれのグループ固有の制限に対して、各グループのデプロイメント数が計上されます。

ユーザー・グループ

「ユーザー・グループ」はロールを表します。ロールとは、実行するタスクのタイプと、これらのタスクのタイプを実行するために必要な権限のセットのことです。ユーザー・グループには、主要なプロパティーが 2 つあります。

  • Group members (グループ・メンバー): このロールを持つユーザーのリストです。
  • Permissions (権限): このロールのユーザーがそれぞれのタスクを実行するために必要な能力です。

ユーザー・グループの主な機能の 1 つは、パターンをデプロイするための特定の環境プロファイルを使用できるユーザーを指定することです。


PureApplication System 仮想マシンの振る舞い

アプリケーションは、パターン・インスタンスとして PureApplication System にデプロイされます。パターン・インスタンスはミドルウェアを実行する仮想マシンで構成されており、アプリケーションはこれらの仮想マシンで実行されます。アプリケーションを実行する仮想マシンの振る舞いを調整するには、パターンをデプロイする際に使用する環境プロファイルの設定と、パターン・インスタンスを実行するクラウド・グループの設定を使用します。

環境プロファイルとクラウド・グループの設定が仮想マシンの振る舞いに与える影響は、以下の 2 つの点で現われます。

  • 優先順位付け: 同じクラウド・グループ内のすべての仮想マシンの重要度に対する、各仮想マシンの相対的な重要度。
  • リソース要件: 仮想マシンが、環境プロファイルによって割り当てられ、クラウド・グループから提供されるプールからどれだけのリソースを使用するかは、仮想マシンの要件と、クラウド・グループがこれらの要件をどのように考慮するかに依存します。

次のセクションで、優先順位付けとリソース要件が仮想マシンの振る舞いにどのように影響するかについて説明します。

優先順位付け

デプロイされたパターン (パターン・インスタンスとも呼ばれます) を構成する個々の仮想マシンには、優先順位付けの設定があります。優先順位付けの設定は、「リソース競合」が発生したときに意味を持ってきます。つまり、クラウド・グループの仮想マシンが必要とするリソースの量が、そのクラウド・グループで使用可能なリソースの量を超えた場合です。リソース競合は、以下の場合に発生します。

  • 複数のパターンが同時にデプロイされた場合
  • 割り当てを超える過剰なランタイム・リソースが割り当てられた場合
  • コンピューター間で VM が移植された場合

このような事態が発生すると、システムは最も優先順位が高い VM を優先します。

PureApplication System は、以下の 2 つの設定に基づいて VM に優先順位を付けます。

  • 環境プロファイルに指定されたデプロイメントの優先順位: パターンをデプロイする際に使用した環境プロファイルに指定されているデプロイメントの優先順位です。デプロイメントの優先順位の値は、その環境プロファイルを作成または編集する管理者が設定します。設定可能な値には、Platinum (プラチナ)、Golden (金)、Silver (銀)、Bronze (銅) があります。
  • デプロイヤーによるデプロイメントの優先順位: パターンをデプロイするためのパターン・デプロイメント・プロパティー・ダイアログ (環境プロファイルもこのダイアログで選択します) で指定された優先順位です (図 3 を参照)。この優先順位の値は、パターンをデプロイするデプロイヤーが設定します。設定可能な値は、High (高)、Medium (中)、Low (低) です。

同じ 1 つのパターン・インスタンスに含まれる VM はすべて一緒にデプロイされるため、同じ優先順位を持ちます。

図 3. パターン・デプロイメント・プロパティー・ダイアログでの優先順位の設定
パターン・デプロイメント・プロパティー・ダイアログでの優先順位の設定

表 1 に、2 つの優先順位の設定の組み合わせを優先順位の高い順に記載します。

表 1. ワークロードの優先順位の重み付け
優先順位重み
Platinum-High (プラチナ – 高)16
Golden-High (金 – 高)12
Silver-High (銀 – 高)8
Platinum-Med (プラチナ – 中)8
Golden-Med (金 – 中)6
Bronze-High (銅 – 高)4
Silver-Med (銀 – 中)4
Platinum-Low (プラチナ – 低)4
Golden-Low (金 – 低)3
Bronze-Med (銅 – 中)2
Silver-Low (銀 – 低)2
Bronze-Low (銅 – 低)1

システムの内部プロセスは重み 20 で実行されるため、すべてのユーザー・ワークロードより優先されます。

この優先順位付けは、フェイルオーバーの際に特に重要になってきます。例えば、ある計算ノードで障害が発生すると、システムがそのノードの VM のリカバリーをするために、同じクラウド・グループ内の他の計算ノードで VM を再起動します。これらの VM は、優先順位に応じた順序で移植されて再起動されるため、優先順位が高いパターン・インスタンスの VM のリカバリーが行われてから、それよりも優先順位の低いパターン・インスタンスの VM のリカバリーが行われます。ターゲットの計算ノードに、障害が発生したすべての VM に対応できるだけの十分なキャパシティーがなければ、優先順位の低い VM は再起動されません。その場合、管理者はこの事態を自らの手で作業することで解決しなければなりません。通常は、一部のパターン・インスタンスを停止して、障害が発生したインスタンスを再起動するという方法が採られます。

リソース要件

デプロイされたパターン (パターン・インスタンスとも呼ばれます) を構成する個々の仮想マシンには、リソース要件の設定があります。リソース要件の設定によって指定されるのは、VM を適切に実行するために必要な以下のリソースです。

  • CPU カウント: この VM に割り当てる仮想 CPU の数です。
  • 仮想メモリー (MB): この VM に割り当てる仮想メモリーの容量です。

CPU カウントの計算は、VM の実行対象のクラウド・グループのタイプ設定に依存します。例えば、VM に 4 個の仮想 CPU が必要だとすると、CPU の割り当ては以下のようになります。

  • dedicated (専用) クラウド・グループは、VM に 4 個の物理 CPU を割り当てます。
  • average (平均) クラウド・グループは、VM に 1 個の物理 CPU を割り当てます。

これらのリソース要件の設定値は、大きなユーザー負荷が見込まれる VM には高く設定する必要があります。VM のリソース要件の設定値が低い場合、その VM に高いユーザー負荷がかかると (そして、パターン・インスタンスが他の VM に負荷を分散しなければ)、リソースが不足してすべてのリクエストに通常の応答時間で対応できなくなるため、その VM のユーザーはパフォーマンスの低下に悩まされることになります。

単純に、パターンのすべての VM にリソースを余分に割り当てるとすると、正常にデプロイして実行できるパターン・インスタンスの数が少なくなってしまいます。VM がスペースを占めるとするとどうなるでしょう?それぞれの VM が大きくなればなるほど、スペースに収まる VM の数が少なくなります。パターンをデプロイすると、そのリソースの合計が、環境プロファイルで設定された環境の制限値から差し引かれます。この値がゼロに達すると、パターン・インスタンスの一部を保管するか、削除するまで、そのプロファイルを使用してパターンをデプロイすることはできなくなります。

同様に、個別の環境プロファイルによってデプロイされた複数のパターンが、クラウド・グループのリソースを過剰に割り当てる可能性もあります。あまりにも寛大にリソースが設定された VM は、この過剰な割り当てを不必要に増やすだけです。クラウド・グループのリソース割り当てが過剰な場合、すべての VM がその割り当てを使用しようとすると、過剰な割り当てがリソースの競合を引き起こし、潜在的な問題が現実の問題に変わります。クラウド・グループは、このリソース競合の問題を優先順位付けによって解決します。優先順位が低いインスタンスは起動しないか、あるはすでに実行中の場合には、必要なリソースを受け取りません。

したがって、パターン内の VM のリソース要件を設定するときには、以下の 2 つの相反する制約の間で最適なポイントを見つける必要があります。

  • アプリケーション・パフォーマンスの最適化: パターンの VM が適切に実行されるために最低限必要なリソースを割り当てること。
  • リソースの使用の最適化: パターンの VM が (想定される負荷状態で) 適切に実行されるために必要な最大限のリソースを割り当てること。これにより、環境プロファイルを使用してデプロイしてクラウド・グループ内で実行できるパターン・インスタンスの数が最大になります。

リソースがあまりにも少ないと、アプリケーションのパフォーマンスに影響が出ます。リソースが過剰だと、多くのアプリケーションをデプロイできなくなります。


PureApplication System での環境ストラテジー

これまで説明した PureApplication System のリソース・タイプを使用してクラウド・コンピューティングの概念を実現する方法を、いくつかの一般的なシナリオで検討します。

以降で取り上げるすべてのシナリオを通して、PureApplication System の 2 つの主要なリソース・タイプの目的を忘れないでください。その目的とは以下のとおりです。

  • クラウド・グループは、パターン・インスタンスを実行できる物理デプロイメント環境を表します。クラウド・グループは物理的に分離されるため、あるクラウド・グループが停止されたり、障害によって機能しなくなったりしても、他のクラウド・グループには影響が及びません。クラウド・グループ内のアプリケーションが何らかの理由で暴走してすべてのリソースを使い果たした場合、同じクラウド・グループ内の他のアプリケーションには影響が出ますが、他のクラウド・グループのアプリケーションへの影響はありません。
  • 環境プロファイルは論理デプロイメント環境を表します。デプロイヤーにとって、環境プロファイルはデプロイメントのターゲットを表すものであり、デプロイメントのポリシーを定義するものです。同じポリシーを使用し、同じリソース割り当てを共有する 2 つのユーザー・グループは、1 つの環境プロファイルを共有することになります (つまり、両方のユーザー・グループが同じ環境プロファイルに割り当てられます)。2 つのユーザー・グループが異なるポリシーを使用する場合、あるいは別々のリソース割り当てが与えられる場合には、ユーザー・グループにそれぞれ固有の環境プロファイルが必要です。

シナリオ: 開発ライフサイクル環境

環境を定義する際の一般的な手法の 1 つは、アプリケーションの開発ライフサイクルを複数のステージに分けることです。ライフサイクルのステージと、それぞれのステージに対応するランタイム環境には、一般に以下のものがあります。

  • DEV: ビジネス・アプリケーションの開発で使用する環境です。
  • TEST: アプリケーションのテストで使用する環境です。
  • PROD: 企業またはエンド・ユーザーがアプリケーションを実行するために使用する環境です。

通常、それぞれの環境は独立したハードウェアのセットで実行されます。その理由の 1 つは、開発環境で発生した問題がテスト環境に影響を与えないようにし、テスト環境での問題が本番環境に影響を与えないようにするためです。

PureApplication System でこれらのランタイム環境を作成して、それぞれの環境を互いに分離する際の優れたプラクティスは、DEV、TEST、PROD という 3 つのユーザー・グループを作成することです。小規模な構成の Intel システム (6 つの計算ノードからなるシステム) では、以下のような構成になります。

  • 1 つの計算ノードからなる DEV クラウド・グループ (Intel 計算ノードの場合、開発者には 16 個の物理コアが与えられます): このクラウド・グループのタイプは「average (平均)」に設定します。開発アプリケーションはそれほど頻繁に使用されることがなく、ユーザー負荷も低いためです。
  • 2 つの計算ノードからなる TEST クラウド・グループ: 2 つの計算ノードは、別々のシャーシに収容し、ラックの別側面に配置する必要があります。このクラウド・グループのタイプは、本番環境に似せるために「dedicated (専用)」に設定します。
  • 3 つの計算ノードからなる PROD クラウド・グループ: 3 つの計算ノードは、3 つの別々のシャーシに収容し、ラックの両側面に分散するように配置します。本番環境のアプリケーションは頻繁に使用されることが想定されるため、このクラウド・グループのタイプは「dedicated (専用)」に設定します。

PureApplication System ラック内でのハードウェア (シャーシに収容される計算ノード、別々に配電される 2 つの棚に積み重ねられる Intel 計算ノードなど) の配置方法は、詳細な内容のトピックですが、この記事では説明しません。システムの個々のハードウェアの概要については、「PureApplication System のハードウェア機能」を参照してください。ラックでのシャーシ内の計算ノードの配置は、PureApplication System コンソールの「Infrastructure Map (インフラストラクチャー・マップ)」で確認することができます。詳細については、PureApplication System インフォメーション・センターのトピック「ハードウェア・インフラストラクチャー・マップの表示」および「インフラストラクチャー・マップのデータ」を参照してください。

これら 3 つのクラウド・グループには、それぞれに 1 つ以上の IP グループも必要です。ネットワーク・トラフィックをクラウド・グループごとに分離するために、IP グループには他で使用されていない VLAN ID を設定する必要があります。

環境プロファイルの数に関しては、ハードウェアに関する制約はないので無制限に作成することができます。ただし、何が必要となるかを説明している実用的なガイドラインもあります。一般に、PROD に対してパターンをデプロイできるデプロイヤーの数は、TEST でのデプロイヤーの数より少なく、TEST でのデプロイヤーの数は DEV でのデプロイヤーの数より少ないのが通常です (図 4 を参照)。

図 4. 環境ごとのデプロイヤーの相対数
環境ごとのデプロイヤーの相対数

同様に、各ランタイム環境に必要な環境プロファイルの数も、DEV から TEST、PROD の順に少なくなっていく傾向があります。

最初にワークロードの「スーパー・ユーザー」のユーザー・グループを定義しておくと役立ちます。

  • ワークロード管理者: これは、システム内のすべてのワークロードを管理するワークロード・スーパー・ユーザー (通常は、ワークロード・リソース管理セキュリティー・ロールを持つユーザー) のグループです。ワークロード・スーパー・ユーザーは、あらゆるプロファイルを使用してパターンをデプロイできなければなりません。したがって、このグループをすべての環境プロファイルに割り当てる必要があります。

以下に、有用な環境プロファイルを記載します。それぞれのプロファイルごとに、対応するユーザー・グループがあります。

  • 本番アプリケーション環境プロファイル: アプリケーションを PROD 環境にデプロイする環境プロファイルです。この環境プロファイルの優先順位は「Golden (金)」に設定してください。オプションで、「Environment (環境)」の設定を「Production (本番)」にすることができます。
    • 環境プロファイルは、本番アプリケーションごとに作成することも、本番アプリケーションをデプロイする部門や事業ごとに作成することもできます。後者の場合、アプリケーションごとにパターンをデプロイできるユーザーを制御するための設定と、アプリケーションやアプリケーションのグループごとに異なるリソース割り当てを行うための設定を有効にします。
    • この環境プロファイルでも、すべてのアプリケーションを本番環境にデプロイする役割を持つユーザーのセットを設定したほうがよい場合があります。その場合、これらのユーザーのすべてが同じ環境プロファイルを使用します。すべてのアプリケーションを同じ環境プロファイルでデプロイすると、すべてのパターン・インスタンスがその環境プロファイルのリソース割り当てを共有することになります。異なるアプリケーションのセットがそれぞれに異なるリソース割り当てからリソースを取得する必要があるとしたら、個別の環境プロファイルを作成し、それらすべての環境プロファイルに対して単一の本番デプロイメント・ユーサー・グループを割り当ててください。
  • テスト・アプリケーション環境プロファイル: この環境プロファイルでは、アプリケーションを TEST 環境にデプロイします。この環境プロファイルの優先順位は「Silver (銀)」に設定し、オプションで「Environment (環境)」の設定を「Test (テスト)」にします。テスト対象のアプリケーションを 1 つ以上デプロイするチームごとに、1 つの環境プロファイルを作成します。チームごとに異なる環境プロファイルを使用して、各環境プロファイルに別個のリソース (別個の IP グループなど) を割り当てると、チームのアプリケーションをクラウド・グループ内で分離した状態にできるため、あるチームがクラウド・グループのリソースを過剰に使用したために、他のチームが十分なリソースを使用できなくなるという事態がなくなります。
  • 開発アプリケーション環境プロファイル: この環境プロファイルでは、アプリケーションを DEV 環境にデプロイします。環境プロファイルの優先順位は「Bronze (銅)」に設定し、オプションで「Environment (環境)」の設定を「Development (開発)」にします。すべての開発者が 1 つの環境プロファイルを共有することは可能ですが、その場合、1 人ひとりの開発者がリソースを使用し過ぎることがないと信頼されていなければなりません。リソースの使用を制限するには、開発チームごと、さらには開発者ごとに別個の環境プロファイルを使用してください。注意する点として、ある環境プロファイルが有用となるのは、その設定が他の環境プロファイルとは異なる場合のみです。例えば、パターンをデプロイできるユーザーの設定、使用する IP グループの設定、あるいは CPU や PVU などのリソースの使用に関する制限の設定が他の環境プロファイルと異なる場合にのみ、その環境プロファイルは有用性を持ちます。

シナリオ: 複数の本番環境

よくある手法として、複数の本番環境を分離する場合もあります。これらの分離された本番環境はいずれも本番アプリケーションに使用されるため、優先順位に差はありません。ただし、それぞれの環境にデプロイされるアプリケーションの用途は異なることから、本番環境を互いに分離する必要があります。

仮に、以下の 3 つの本番環境があるとします。

  • 公開 (Public) Web サイト用: この環境は、顧客がインターネット経由でアクセスする Web アプリケーションをホストします。この環境にアクセスできるのは、企業の顧客です。
  • 内部人事 (HR) アプリケーション用: この環境は、人事部が使用するアプリケーションをホストします。この環境にアクセスできるのは、人事部の従業員に限られます。
  • 内部経理 (Finance) アプリケーション用: この環境は、経理部が使用するアプリケーションをホストします。この環境にアクセスできるのは、経理部の従業員に限られます。

PureApplication System でこの 3 つの本番環境を作成して、それぞれの環境を互いに分離するのに有効なプラクティスは、PUBLIC、HR、FINANCE という 3 つのクラウド・グループを作成することです。6 つの計算ノードからなる小規模な構成で、各クラウド・グループに 2 つの計算ノードを割り当てます。これらの計算ノードのペアを別々のシャーシとラックの両側面に分散させて、ペアごとに異なる未使用の VLAN ID を内部で使用させます。各クラウド・グループには、1 つ以上の IP グループを割り当てます。1 つのクラウド・グループ内ではすべての IP グループが同じ VLAN ID を使用することができる一方、異なるクラウド・グループの IP グループが使用する VLAN ID は異なっていなければなりません。これは、クラウド・グループのネットワーク・トラフィックを互いに分離するためです。アプリケーションが頻繁に使用されるとしたら、各クラウド・グループのタイプを「dedicated (専用)」に設定する必要があります。クラウド・グループにそれほど頻繁に使用されないアプリケーションが多数ある場合には、タイプを「average (平均)」に設定します。

本番環境ごとに環境プロファイルを作成して、そこに各環境へのデプロイメントを担当するユーザーからなるユーザー・グループを割り当てます。また、スーパー・ユーザー (すべてのワークロードの管理者) からなるワークロード管理者グループも作成し、そのグループをすべての環境プロファイルに割り当てます。複数のチームが 1 つの環境を共有する一方、チーム間で調整を取るのが難しい場合には、チームごとにユーザー・グループと環境プロファイルを作成してください。これらの環境プロファイルは、パターンをデプロイする対象のクラウド・グループは同じですが、チームのアプリケーションは適切に分離されるように、制限を設けてリソースを割り当てます。

シナリオ: 利用状況に基づく環境

クラウド・グループの機能の 1 つとして、クラウド・グループのタイプ設定があります。

  • dedicated (専用): この設定では、仮想マシンが要求するすべての仮想 CPU に対して 1 個の物理 CPU が提供されます。
  • average (平均): この設定では、仮想マシンが要求するすべての仮想 CPU に対して 4 分の 1 個の物理 CPU が提供されます。

これらのタイプ設定を (環境プロファイルで設定された環境の制限と優先順位、そして仮想マシンのリソース要件と併せて) 使用することで、次の 2 つのタイプのワークロードのうちの一方に対して最適化されたクラウド・グループを作成することができます。

  • 実行するアプリケーションの数は少ない一方、これらのアプリケーションの多くが同時に高い負荷に適切に対応できるようにするクラウド・グループ
  • アプリケーションを実行するのに必要な CPU の 4 倍の CPU を過剰に割り当て、使用率の低いアプリケーションを数多く実行して、ハードウェアの平均使用率を改善するクラウド・グループ

高負荷のアプリケーションと使用率の低いアプリケーションの両方を持つ組織にとって優れたプラクティスとなるのは、それぞれのタイプに応じたクラウド・グループを作成することです。

このプラクティスを適用するには、以下の 2 つのクラウド・グループを作成します。

  • High Load (高負荷): 通常のユーザー負荷が高いアプリケーション用のクラウド・グループです。
    • このクラウド・グループのタイプは「dedicated (専用)」に設定します。
    • 環境プロファイルの環境の制限は控えめに設定して、各ユーザー・グループがパターンを数多くデプロイしすぎないようにします (過剰な数のパターンをデプロイすると、チームごとの制限されたリソースの公正な割り当てを超えるリソースが使用されます)。
    • 一部のアプリケーションの優先順位が他のアプリケーションより高い場合には、パターンをデプロイするときに、環境プロファイルのなかでそれらの優先順位を設定します。ユーザー負荷がクラウド・グループのキャパシティーを超えると、この優先順位の設定が適用されます。
    • パターンの VM のリソース要件は高く設定しますが、ピーク負荷時に必要なだけの値にします。
    • これらのアプリケーションの多くで負荷が同時にピークに達したとしても、このクラウド・グループは、負荷に対処し、応答時間を一定に維持することができます。
  • Underutilized (低使用率): このクラウド・グループは、使用可能な状態を維持する必要があり、ときにはかなりのユーザー負荷を受けることはあっても、通常はそれほど頻繁に使用されないアプリケーション用です。
    • このクラウド・グループのタイプは「average (平均)」に設定します。
    • 環境プロファイルでは環境の制限を寛大に設定し、各チームが多数のパターンをデプロイできるようにします。これは、これらのパターンがあまり多く使用されることはないという前提です。
    • 一部のアプリケーションの優先順位が他のアプリケーションより高い場合には、パターンをデプロイするときに、環境プロファイルのなかでそれらの優先順位を設定します。ユーザー負荷がクラウド・グループのキャパシティーを超えると、この優先順位の設定が適用されます。
    • パターンの VM のリソース要件は控えめに設定しますが、通常の負荷時に正常に実行できるようにします。
    • このクラウド・グループではデプロイできるパターンの数が多くなります。ただし、アプリケーションの多くで同時にピーク負荷に達すると、パフォーマンスが低下するので注意が必要です。

ある 1 つのユーザー・グループが高負荷のアプリケーションと使用率が低いアプリケーションの両方を担当する場合、そのユーザー・グループを両方のクラウド・グループの環境プロファイルに割り当てることができます。両方のクラウド・グループに共通の環境プロファイルを使用することは避けてください。この 2 つのクラウド・グループのリソース制限は別々に設定し、高負荷のグループには制限を控えめにし、低使用率のグループには制限を大胆に行う必要があるためです。

この手法では、高負荷のアプリケーションには、必要なリソースを得られる最大の可能性が与えられる一方、使用率が低いアプリケーションを実行するハードウェアの使用率も可能な範囲で最大限になります。

シナリオ: 開発とテストの共有環境

開発ライフサイクルのランタイム環境のうち、いくつかの環境の結合を検討することができます。ただし、TEST 環境と PROD 環境を結合するのは賢明ではありません。その場合、テストによって PROD のリソースが奪われる可能性があるだけでなく、TEST での問題が PROD にも影響する恐れがあるためです。この 2 つの環境については、異なるクラウド・グループに分けることがより望ましいです。

一方、DEV と TEST は 1 つの環境に結合するほうが理にかなっているかもしれません。この手法には、以下の利点と欠点があります。

  • 利点: ある用途向けには使用されていないリソースを別の用途のために簡単かつ動的に使用することができます。例えば、テスト作業が活発に行われていない間は、テスト用のリソースを開発用に使用し、テスト作業が活発になってきたら、テスト用にリソースを返すようにすることができます。
  • 欠点: 活発なテスト作業でリソースの大部分が使用され、開発で使用できるリソースが制限される可能性があります (開発の優先順位のほうが低く設定されている場合)。開発者たちがテスト作業を行っていることなどが理由で、テスト期間中は開発が活発には行われない場合には、これは利点になりますが、テスト作業が盛んに行われているときに開発者たちが開発を行おうとしている場合には、欠点となります。

この手法を実装するには、1 つの DEV-TEST クラウド・グループを作成します。他のリソース (IP グループ、環境プロファイル、およびユーザー・グループ) でも、DEV と TEST のペアを作成します。当然のことながら、ワークロード管理者ユーザー・グループは、両方またはすべての環境プロファイルに割り当てます。これらのリソースを使用して、2 つの環境プロファイルを表 2 のように設定します。

表 2. 環境プロファイルの設定
設定TEST プロファイルDEV プロファイル
Access granted to (アクセス権限の付与先)TEST ユーザー・グループDEV ユーザー・グループ
Deploy to cloud groups (デプロイ先のクラウド・グループ)DEV-TEST クラウド・グループDEV-TEST クラウド・グループ
IP addresses (IP アドレス)TEST IP グループDEV IP グループ
Environment limits (環境の制限)10 個の仮想 CPU5 個の仮想 CPU
Deployment priority (デプロイメントの優先順位)Silver (銀)Bronze (銅)
Environment (環境)テスト開発

この手法には、以下のメリットがあります。

  • Access granted to (アクセス権限の付与先): 異なるユーザー・グループで、各プロファイルを使用してパターンをデプロイできるユーザーを制御します。
  • Deploy to cloud groups (デプロイ先のクラウド・グループ): 両方のプロファイルで、共通のクラウド・グループにデプロイされます。
  • IP addresses (IP アドレス): 異なる IP グループを使用することにより、一方のユーザー・グループのパターン・インスタンスがすべてのアドレスを使い切って、もう一方のユーザー・グループに使用できるアドレスがなくなるという事態がなくなります。また、必要な場合には個別の VLAN を使用することもできます。
  • Environment limits (環境の制限): 上記の設定では、DEV が最大 5 個の仮想 CPU の計算処理能力を取得し、TEST は最大 10 個の仮想 CPU の計算処理能力を取得することができます。これらの環境で使用可能な CPU のすべてが使用されている場合、優先順位の高い環境 (TEST) にさらに CPU が必要になると、そのキャパシティーは優先順位の低い環境 (DEV) から取得されます。
  • Deployment priority (デプロイメントの優先順位): 上記の設定では、TEST の優先順位のほうが DEV より高いため、リソースの競合は、TEST プロファイルでデプロイされたアプリケーションを優先して解決されます。
  • Environment (環境): この設定は、システムでは無視されます。

PureApplication System での環境の原則

以上のシナリオでは一貫して、あらゆるシナリオに適用される傾向のある以下の原則に従いました。

  1. クラウド・グループを使用して、PureApplication System を複数の分離された論理コンピューターに分割すること。ネットワークもクラウド・グループごとに分離するには、各クラウド・グループに異なる VLAN ID を設定する必要があります。
  2. 各クラウド・グループを、密度が低い高負荷のアプリケーション、または密度が高い低使用率のアプリケーションのいずれかに応じて調整すること。この両方のタイプのアプリケーションがある場合、それぞれのタイプのクラウド・グループを作成します。
  3. 通常は、デプロイ先のクラウド・グループごとに 1 つの環境プロファイルを使用すること。
  4. 1 つのクラウド・グループを共有するユーザー・グループ (例えば、同じテスト環境にデプロイする複数のチーム) を分離するには、複数の環境プロファイルを使用すること。こうすると、PureApplication System 管理者は、各グループがそれぞれに固有の IP グループ、優先順位、リソースの制限を使用するように制約できるため、ユーザーとそれぞれのアプリケーションをより簡単に連携させられるようになります (あるいは、強制的に連携させられるようになります)。
  5. ワークロード・スーパー・ユーザー (ワークロード・リソース管理セキュリティー・ロールを持つユーザー) 用のワークロード管理者ユーザー・グループを作成して、すべての環境プロファイルに割り当てること。

以上の原則に従うことで、PureApplication System の機能を上手く活用できるようになるはずです。


付録 A: PureApplication System のハードウェア能力

このセクションでは、計算ノードを構成するハードウェアと PureApplication System 内の関連するハードウェアについて簡単に要約します。

計算ノード (もっと一般的には、統合テクノロジー要素 (Integrated Technology Element: ITE) とも呼ばれます) とは、具体的には、PureApplication System の管理ノードの 1 つとして実行するように特殊化されていないノードです。計算ノードは以下の要素で構成されます。

  • CPU: Intel 計算ノードには、2 つの Intel Romley 8 コア Sandy Bridge チップが組み込まれ、ハイパーバイザーが 32 個の論理コアとして使用する合計 16 個の物理コアを提供します。
  • メモリー: Intel 計算ノードには、256 GB の RAM が含まれます。

計算ノードがアクセスする以下のリソースは、すべての計算ノードで共有されます。

  • ストレージ: PureApplication System は、6.4 TB の SSD (Solid-State Drive) と 48TB の HDD (Hard Disk Drive) をストレージとして提供します。このうち、それぞれ 4.8 TB、38.4 TB を使用することができます。
    • ストレージは、RAID-5 構成で組み合わせられた IBM Storwize V7000 ストレージ・ユニットのペアに収容されます。
    • アプライアンス内のディスクには、16 x 400 GB の SSD と 80 x 600 GB の HDD があります。
    • アプライアンスには、IBM Easy Tier ストレージ管理システム・ソフトウェアが組み込まれています。
    • 計算ノードは、8 GB のファイバー・チャネル接続により、SAN としてのストレージにアクセスします。
  • ネットワーク: PureApplication System には、2 台の BNT (BLADE Network Technologies) 64 ポート・イーサネット・スイッチが組み込まれています。
    • 各スイッチのポート 41 から 56 (合計 16 ポート) は、エンタープライズ・ネットワークとの接続用にオープンにされます。
      • 各ポートは、10/1 Gbps のイーサネットです。組み込みコネクターは銅線タイプですが、各ポートに光ファイバー用または DAC (Direct Access Connect: 直接アクセス接続) 用のコネクターを接続することもできます。
      • 高可用性をもたらすには、2 台のスイッチ間でポートのペアをリンク・アグリゲーションによって 1 つに束ねます。
    • ポート 63 (2 台のスイッチのいずれか) はサービス・ラップトップで使用されます。IBM ではこのサービス・ラップトップを使用してシステムを管理します。
    • ポート 64 (両方のスイッチでリンク・アグリゲーションにより束ねられたポート) は、顧客のコンソール用に使用されます。
    • システムの BNT スイッチ上のその他のポートは、3 つのシャーシのスイッチ間にイーサネット接続を提供します。PureApplication System の各シャーシには、計算ノードに接続するための 10 Gbps イーサネット・スイッチのペアが収容されています。シャーシ・スイッチは 40 Gbps イーサネット・トランクを介し、2 つの BNT スイッチ間でシステム・スイッチに接続します。

まとめ

この記事では、PureApplication System で、クラウド・グループおよび環境プロファイルに用意された機能を使用してアプリケーション・ランタイム環境を設計し、作成する方法を説明しました。これらの機能とクラウド・コンピューティングの概念との関係、そしてクラウド・コンピューティングの概念と PureApplication System で関連する機能について説明し、これらの機能を利用するシナリオについて検討した後、最後にそれらのシナリオから導き出せる原則をまとめました。この記事から得られた知識があれば、PureApplication System でランタイム環境を管理する準備は万全です。

謝辞

この記事の執筆に協力してくださった IBM のVishy Gadepalli 氏Stanley Tzue-Ing Shieh 氏Michael Fraenkel 氏Shaun Murakami 氏Jason Anderson 氏Ajay Apte 氏Kyle Brown 氏Rohith Ashok 氏Hendrik van Run 氏に感謝いたします。

参考文献

コメント

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, WebSphere
ArticleID=845659
ArticleTitle=IBM PureApplication System でアプリケーション・ランタイム環境を管理する
publish-date=11152012