F5とIBMによるエンタープライズクラウドの構築

ある推定によると、エンタープライズ クラウド (プライベート クラウドとも呼ばれる) は、パブリック クラウドよりも速いペースで導入されています。 エンタープライズコンサルティング会社アクセンチュアは、2011 年末までにプライベート クラウドのエンタープライズ普及率が 77% に達すると予測しています。¹ 俊敏なオンサイト インフラストラクチャを構築するというこの急速な動きの多くは、大規模および小規模の企業の IT 部門がインフラストラクチャとデータの両方を社内で制御および管理する必要性から生じています。

クラウド インフラストラクチャを採用する決定が下されると、コスト、リスク、価値の分析に基づいて、内部/プライベートと外部/パブリックの選択が行われます。 パブリック クラウドは通常、柔軟なアプローチと最大のコスト削減を実現しますが、セキュリティ、サービス レベル契約 (SLA) と可用性、管理に関連するリスクを伴います。 IT は、低い導入コストでほぼ無制限の規模を活用できますが、制御が犠牲になります。 従来のオンサイトまたはホスト型データセンターから外部のパブリッククラウドに移行することは、基本的にデータセンター全体を他者の手に移すようなものです。

エンタープライズ クラウドでは、IT 部門は必要なレベルの制御が可能で、パブリック クラウドに関連するリスクを回避できます。ただし、プライベート クラウドは導入コストが高く、スタッフに高度な知識と専門技術が求められ、オンプレミス データ センターの複雑さが増します。 エンタープライズ クラウド インフラストラクチャは必要に応じて拡張でき、動的なプロビジョニングと俊敏性を提供しますが、その拡張と制御には多くの場合、より高い導入コストが伴います。

F5 Networks® と IBM は協力して、複雑さに伴う多くの課題を軽減するエンタープライズ クラウドのリファレンス アーキテクチャを設計しました。 パブリック クラウドのアーキテクチャとスケール コンポーネントの多くをオンプレミスで実現し、社内の断片的なシステムの構築コストを大幅に削減します。 必要なコンポーネントを事前に定義し、それらのコンポーネントがどのように連携するかを概説することで、F5 と IBM は完全かつ動的で俊敏なエンタープライズ クラウド インフラストラクチャを構築しました。

オンデマンド プロビジョニング システムの最も重要な要素は、イベントに基づいて意思決定を行い、アクションを実行する機能です。 システム内のどこかで発生したイベントによってアラートまたはメッセージが作成され、それがコンポーネント (メッセージ バスにサブスクライブしているコンポーネント、または API 呼び出しを介して直接要求されたコンポーネント) によって取得され、そのメッセージに基づいて処理が行われます。 ワークフローは、コンポーネントがシステム メッセージに基づいて動作するプロセスと順序です。

エンタープライズ クラウドでは、ワークフローは通常、リソースを要求または放棄するプロビジョニング コンポーネントと、リソース割り当てを管理するために必要な手順に分かれます。 仮想マシン(VM) に追加の CPU リソースが必要になると、それらの CPU リソースの取得元を決定し、新しい VM を起動し、IP アドレスを割り当てるなどのワークフローが開始されます。

F5 と IBM のエンタープライズ クラウド アーキテクチャは、次の 2 つの重要な原則に基づいています。

1. イベント通知メッセージを伝送するために使用される集中型メッセージ バスがあり、イベントに応じて動作する必要があるすべてのコンポーネントはバスに関連付けられています。

これら 2 つの原則に加えて、F5 と IBM のリファレンス アーキテクチャは非常に柔軟性が高く、既存のあらゆるデータ センターやクラウド アーキテクチャに適合できます。 たとえば、VM の展開を管理するためのオーケストレーション エンジンがすでに存在する場合は、このリファレンス アーキテクチャを調整して、既存のエンジンを使用できるようにすることができます。 エンタープライズ クラウドの構築に関する誤解の 1 つは、インフラストラクチャ全体を置き換える必要があるというものです。F5 と IBM のソリューションは、あらゆる可能なステップで既存のコンポーネントと統合できるように作成されました。

どのコンポーネントが既に存在し、どのコンポーネントが新規であるかに関係なく、エンタープライズ クラウド ワークフローは、特定のタスクを実行する特定のコンポーネントで構成されます。 クラウド システム全体はこれらの個々のコンポーネントで構成されており、それらが連携して完全なクラウド インフラストラクチャを提供します。 このインフラストラクチャは、クラウド イベントを管理する調整されたタスクであるコンポーネント ワークフローを通じて実行および制御されます。

メッセージ バスは、イベントとアラートに基づいてメッセージを、影響を受ける各コンポーネントに送信するシステムです。 イベントによってメッセージがトリガーされると、そのメッセージはメッセージ バスを介して特定のコンポーネントに送信され、そのコンポーネントにはそのメッセージの処理方法に関するルールが設定されます。 メッセージ バスは、特定のコンポーネントのルールに基づいてメッセージを正規化する役割も担います。

F5 と IBM のリファレンス クラウド アーキテクチャでは、IBM Tivoli Netcool OMNIbus ソリューションを中央メッセージ バスとして使用していますが、任意のエンタープライズ メッセージ バスを使用してシステム全体にイベント通知を送信できます。

オーケストレーターは、エンタープライズ クラウドの頭脳、つまりバス経由で受信したメッセージに基づいてマクロ プロビジョニングの決定のほとんどを行うコンポーネントと考えることができます。 オーケストレーターは、「新しい仮想マシンのプロビジョニング」ワークフローの開始など、クラウド アーキテクチャ内の主要なイベントとワークフローを開始します。 オーケストレーターは、各ワークフローに必要なデータを取得し、該当するコンポーネントに提供する役割も担います。たとえば、オーケストレーターは、新しい VM をプロビジョニングするために必要な IP アドレス情報を提供します。

リファレンス アーキテクチャの場合、オーケストレーターは、バスからのメッセージに基づいて動作し、ワークフロー イベントを開始する一連の解釈されたスクリプトを使用して作成されます。 IBM Tivoli Intelligent Orchestrator、HP Operations Orchestration、VMware vCenter Orchestrator など、あらゆるタイプのオーケストレーターを使用できます。

クラウド コントローラーは、プロビジョニング プロセスを開始するために必要な予備データを収集および集約する役割を担うフロントエンド システムです。 当初、この情報は作成プロセスの一部として管理者によって提供され、プロビジョニングに使用されるワークフローの各タイプに固有のものです。 たとえば、クラウド コントローラーは、VM の場所、applicationのクラス (Web サーバー、データベース サーバー、メール サーバーなど)、最小リソース要件などの情報を収集します。

自動プロビジョニング イベント中に、この予備データがシステムに保存されると、オーケストレーターは既存の情報を要求して抽出し、プロビジョニング ワークフローを開始します。 クラウド コントローラの例としては、Eucalyptus Cloud Controller、VMware vCloud Director、Amazon EC2 などがあります。 将来の成長と他のクラウド プラットフォームへの拡張性を考慮すると、標準のクラウド API セットと統合または通信できるクラウド コントローラーを選択することをお勧めします。 これにより、エンタープライズ クラウド プラットフォームを再設計することなく、クラウド コントローラーをパブリックハイブリッド クラウドプロバイダーに拡張できるようになります。

クラスター コントローラーは、プロビジョニングされている仮想マシンの管理、および VM の実行に必要なストレージとメタデータの管理を担当するエンタープライズ クラウド内のコンポーネントです。 VM 実行環境として、クラスタ コントローラには仮想プラットフォーム ハイパーバイザが含まれており、より大規模なハイパーバイザ管理環境も含めることができます。 たとえば、クラスタ コントローラは、VMware ESXi などの必要最低限のハイパーバイザである場合もあれば、VMware vSphere や VMware vCloud などの分散ハイパーバイザ システムの大規模なコレクションである場合もあります。

ヘルスとステータスの監視は、あらゆるエンタープライズapplicationの展開に不可欠な要素です。 監視では、仮想マシンが起動してネットワーク上の接続に応答しているときなど、プロビジョニング システムのステータス更新も提供されます。 システムを継続的に監視することで、リアルタイムのアラートが提供され、最終的には新しいワークフローに反映され、プロビジョニングの決定に影響を与えます。 applicationとネットワークの状態を監視できるコンポーネントであれば、エンタープライズ クラウドの展開で使用できますが、F5 および IBM リファレンス アーキテクチャでは IBM Tivoli Monitoring ソフトウェアが使用されます。

ドメイン ネーム システム (DNS) は、F5 および IBM エンタープライズ クラウド リファレンス アーキテクチャにおいて重要な役割を果たします。 IPv4 および IPv6 の IP およびドメイン名情報だけでなく、クラウド コントローラーによって収集された情報や固有のマシン識別情報などのシステム メタデータも保存します。 このリファレンス アーキテクチャでは、DNS がメタデータの保存場所として選択されました。これは、DNS がほとんどのネットワークに既に存在する標準ベースのシステムであり、すべてのクラウド コンポーネントで使用可能であり、インフラストラクチャにデータベース タイプのストレージを追加する必要性を軽減するためです。 IT によって管理され、追加のゾーンとゾーン ファイルを追加できる任意の DNS ソリューションを使用できます。

F5 および IBM リファレンス アーキテクチャの場合、クラスタ コントローラはローカル ストレージから仮想マシンを実行します。ただし、クラスタ コントローラが実行されていない場合、VM 仮想ディスクは仮想化ストレージ上にあります。 ワークフロー プロビジョニング イベント中に、クラスター コントローラーはネットワーク ファイル システム (NFS) 経由で仮想ストレージ デバイスから仮想ディスクを要求します。

エンタープライズ クラウドの最後のコンポーネントは、application配信コントローラ (ロード バランサとも呼ばれます) です。これは、F5 および IBM リファレンス アーキテクチャでは、F5® BIG-IP® Local Traffic Manager™ (LTM) です。 BIG-IP LTM は、仮想マシンから送信されるapplicationデータの接続、サービス、配信を管理します。 最終的に、BIG-IP LTM は、ワークフロー プロビジョニング イベントに作用するシステムの最終部分になります。

F5 と IBM のエンタープライズ クラウド リファレンス アーキテクチャの目標は、applicationsを動的に展開するための現実的なリソースベースのプラットフォームを提供することです。 すべてのコンポーネントが配置されると、さまざまなワークフローを通じて連携し、必要に応じて新しいapplicationサービスをプロビジョニングします。 エンタープライズ クラウドに導入されているシステムをプロビジョニングする方法には、手動プロビジョニングと自動プロビジョニングの 2 つがあります。

通常、エンタープライズ クラウドの最初のワークフローは、システム管理者またはapplication要求者からの入力に基づく手動プロセスから開始されます。 ワークフローが手動であるということではなく、システムに情報を初めて入力する行為だけが手動です。 管理者からデータが収集されると、システムはapplicationのプロビジョニング用に事前定義された自動ワークフロー イベントを開始します。

クラウド コントローラ GUI を使用して、管理者 (または新しいプロビジョニング イベントの開始責任者に応じてapplication要求者) は、新しい仮想マシンを起動してapplicationをオンラインにするために必要な情報を入力します。 この情報は通常、次のような高レベルのインフラストラクチャ データです。

• applicationの種類: Microsoft SharePoint、Web サーバー、メール サーバー、Oracle データベースなど、使用可能なapplicationタイプの事前定義されたリスト。
• ネットワーク情報: クラスター IP アドレス、フロントエンド URL、このapplicationが一般公開されるか内部専用になるかなど。
• プロビジョニング情報: プロビジョニング システムに必要な追加情報 (ネットワークの場所 (多くの場合、物理的なデータ センターに関連付けられた地理的参照、たとえば「ヨーロッパ - コペンハーゲン データ センター」) など)、および特定のapplicationタイプの許可されるインスタンスの最小数と最大数に関する制限など。

この情報は、エンタープライズ クラウド全体の自動プロビジョニングのメタデータとして使用されます。

管理者が必要なデータを送信すると、次のステップでは、クラウド コントローラーがその情報（プロビジョニングのためにこのインスタンスを識別するためにシステム全体で使用される、動的に作成された一意のインスタンス ID「vm12345」など）をパッケージ化し、メッセージ バス経由でオーケストレーターに配布します。

最初のステップで提供されるすべての情報は、オーケストレーターに配信される前にメッセージ バスによって正規化されます。

同時に、クラウド コントローラーは API を介して同じメタデータと一意のインスタンス ID をハイパーバイザーに提供し、必要なapplicationイメージを展開するように指示します。 このイベントは、ハイパーバイザーにクラウドベースのストレージから該当する仮想マシンのディスク イメージを要求するように指示します。 ストレージ デバイスは NFS 経由で適切なディスク イメージを取得し、そのイメージをローカル ストレージにコピーし始めます。

オーケストレーターは、メッセージ バスから正規化されたイベント情報とメタデータを受信すると、監視システムと DNS にメタデータを同時にプッシュする 2 つの異なるワークフローを開始します。 監視システムは、この情報を使用してapplicationの自動監視スケジュールを構成し、起動して実行されているという通知の後にapplicationの監視を開始します。 このステップでは、オーケストレーターは監視システム イベントのしきい値も定義します。たとえば、この仮想インスタンスの CPU 使用率が 75% を超えたときにイベント通知を送信するようにモニターに指示します。

オーケストレーターは仮想インスタンスのメタデータを DNS にもプッシュし、そのデータはエンタープライズ クラウド全体で使用するために保存されます。 オーケストレーターは適切な DNS ゾーン形式でメタデータを送信する責任があるため、インスタンス ID に基づいてドメイン名を構築し、IPv4 および IPv6 DNS レコードを作成し、クラウド コントローラーからインスタンス情報を追加し、新しいインスタンス情報を適切なゾーンに追加する必要があります。 たとえば、オーケストレーターは一意のインスタンス ID を取得し、「vm12345.vm.cloud.example.com」の DNS エントリを作成し、それを既存の example.com ゾーンに追加します。

エンタープライズ クラウド全体にメタデータを配布する最後の手順は、ホスト名、IP アドレス、applicationタイプ (または BIG-IP LTM 上のプール)、監視情報などの新しいインスタンス情報を BIG-IP LTMapplication配信コントローラに入力することです。

ステップ 2 では、クラウド コントローラーがハイパーバイザーに、新しくプロビジョニングされたインスタンスに関連付けられた仮想マシンを起動するように指示しました。 VM が期待どおりに起動して実行され、接続可能になると、メッセージ バス上のイベント アラートを介してオーケストレーターに通知されます。 オーケストレーターは、そのイベント アラートを受け取り、BIG-IP LTM に新しい VM をプール内で使用可能としてフラグ付けし、負荷分散方法に基づいて仮想インスタンスへの新しい接続の送信と配布を開始するように指示するワークフローを開始します。 BIG-IP LTM は、applicationプールに割り当てられた、以前に構成されたapplicationモニターを使用して、新しいインスタンスの監視も開始します。

新しく実行された VM からのイベント アラートにより、オーケストレーターは、エンタープライズ クラウド監視システム全体に通知して、仮想インスタンスの監視を開始するように指示されます。 この時点で、新しくプロビジョニングされた仮想インスタンスがエンタープライズ クラウドで稼働し、applicationサービス要求を処理します。 これは、エンタープライズ クラウドの一部であるすべてのサービスの通常の動作モードです。

手動プロビジョニングは、エンタープライズ クラウド内でサービスをプロビジョニングする際の最初のワークフロー ステップですが、最も頻繁に行われるプロビジョニング形式ではありません。 スムーズに実行されるシステムでは、エンタープライズ クラウドはより動的で流動的な自己監視システムに移行し、必要に応じて需要に基づいて新しいサービスを自己プロビジョニングします。 この俊敏なセルフプロビジョニングは、あらゆるクラウド プラットフォームの中核を成すものであり、リアルタイム イベントの監視と対応のために、追加の自動プロビジョニング イベントとワークフローが必要です。

自動プロビジョニング システムの最初のステップは監視です。つまり、システム全体のイベントを収集して検出することです。 最初の手動プロビジョニングでは、監視システムに、名前、場所、監視の種類、イベントしきい値などの仮想インスタンス情報が入力されました。 この情報は、applicationsと仮想インスタンスの可用性とパフォーマンスを自動的に監視するために使用されます。 監視システムによってイベント (たとえば、特定の仮想インスタンスが使用可能な CPU リソースの 75% 以上を消費している) が検出されると、メッセージ バス上にイベントが生成され、オーケストレーターにリソース不足を警告します。

一般的な自動プロビジョニング シナリオでは、オーケストレーターは、現在のインスタンスのリソース負荷を軽減するのに役立つ新しい仮想インスタンスを作成する役割を担います。 applicationのコンピューティングとネットワークの負荷を分散するために、2 つ以上の仮想インスタンスが使用されます。

自動プロビジョニング ワークフローを開始するには、オーケストレーターがコンポーネント イベントを収集し、新しい仮想インスタンスのプロビジョニングに必要なメタデータを要求する必要があります。 F5 および IBM リファレンス アーキテクチャでは、メタデータは DNS に保存され、元の手動プロビジョニング ワークフローの一部として入力されます。 DNS は、applicationのapplication、地理的な場所、プロビジョニングしきい値などの情報をオーケストレーターに返します。

自動プロビジョニング ワークフローの最終ステップでは、オーケストレーターが DNS から取得したメタデータをメッセージ バス経由でクラウド コントローラーにプッシュします。 基本的に、この自動化されたステップは、管理者がマシン情報を入力し、プロビジョニング ワークフローを手動で開始するステップをシミュレートします。 クラウド コントローラーは、この情報を取得し (手動プロビジョニングで管理者から取得する場合と同様に)、新しい仮想インスタンスのプロビジョニング ワークフローを開始します。 この時点から、新しい仮想インスタンスが起動し、実行され、新しい接続を受け入れるまで、上記のプロビジョニング手順とワークフローが繰り返されます。

一般的なエンタープライズ クラウドの展開には、手動と自動の両方のプロビジョニング ワークフローが含まれます。 新しいサービスまたはapplicationsは、最初は手動ワークフローを使用して展開されるため、管理者はサービスの展開方法と場所を制御できます。 サービスが稼働すると、自動プロビジョニング ワークフローがリソースのニーズと可用性に基づいてプロビジョニングを管理します。

プライベート エンタープライズ クラウドの導入を選択しても、複雑さが増したり、操作性が損なわれるようなことはあってはなりません。 クラウド導入の目的は、新しいサービスを作成する際の障壁を減らし、より俊敏なコンピューティング インフラストラクチャを提供することです。 エンタープライズ クラウドは、データ センターにその俊敏性をもたらし、管理性と制御性を大幅に向上させます。

F5 は IBM と協力して、自動プロビジョニングされたエンタープライズ クラウドのリファレンス アーキテクチャを作成しました。 このアーキテクチャはモジュール式で柔軟性のある設計になっており、既存のコンポーネントを必要に応じて統合したり、エンタープライズ クラウド全体を API と共有メッセージング インフラストラクチャを介して他のクラウド プラットフォームに接続したりすることができます。 プライベート エンタープライズ クラウドはどれもまったく同じではありませんが、F5 と IBM のアーキテクチャはさまざまな環境に適応し、あらゆるapplication展開やデータ センターに俊敏なインフラストラクチャの利点をもたらします。

¹ バブコック、チャールズ（2011年1月18日）。 「プライベート クラウドの普及」 情報ウィーク。 ウェブ。