次の方法で共有

クラウド コンピューティング: マイクロソフト プライベート クラウドを設計する

  • [アーティクル]

この 4 部構成シリーズでお届けする記事の第 1 部では、プライベート クラウドについて説明し、ホストされたサービスとしてのインフラストラクチャがプライベート クラウドをどのようにサポートするのかを取り上げます。

David Ziembicki、Adam Fazio

クラウド コンピューティングには多くの定義がありますが、米国標準技術局 (NIST) で定義されているものが、簡潔で広く認識されている定義の 1 つです。NIST では、5 つの基本的な特徴、3 つのサービス モデル、および 4 つの展開モデルを定義しています。基本的な特徴は、定義の中核を成しています。真のクラウドと呼ばれるソリューションには、次の特徴が備わっている必要があります。

  • オンデマンドのセルフ サービス
  • 広範なネットワーク アクセス
  • リソース共有
  • 迅速な弾力性
  • 規則的なサービス

NIST では、次の 3 つのサービス モデルも定義しています (これらは、アーキテクチャ層と呼ばれることもあります)。

  • サービスとしてのインフラストラクチャ (IaaS)
  • サービスとしてのソフトウェア (SaaS)
  • サービスとしてのプラットフォーム (PaaS)

また、次の 4 つの展開モデルも定義しています。

  • プライベート クラウド
  • コミュニティ クラウド
  • パブリック クラウド
  • ハイブリッド クラウド

クラウド入門

Microsoft Services では、Windows Server、Hyper-V、および System Center を使用してプライベート クラウド/IaaS ソリューションを設計、構築、および実装しました。この 4 部構成シリーズの記事は、各コンポーネント製品をソリューションとして統合および展開する方法を紹介すると同時に、弾力性、リソース共有、セルフ サービスなど、重要なクラウドの特徴について説明することを目的としています。

第 1 部では、プライベート クラウド/IaaS を定義し、クラウドの特徴と要件として使用するデータセンターの設計原理について説明し、この要件を満たすために作成したリファレンス アーキテクチャの詳細を紹介します。第 2 部と第 3 部では、リファレンス アーキテクチャの詳細な設計、各層と各層に含まれる製品、およびプロセスとワークフローの自動化を取り上げます。第 4 部では、Microsoft Deployment Toolkit と Hydration Framework を使用して、一貫性のある再現可能な実装を実現する展開の自動化について説明します。

クラウドの定義の一貫性を保つため、この記事では NIST の展開モデルを使用し、対象となるサービス モデルの名称を明言することなく、さまざまな状況で "プライベート クラウド" という用語を頻繁に使用します。

NIST の定義に含まれている特徴以外に、この記事を執筆するにあたって、いくつかの追加の要件を盛り込みました。

  • 復元性と冗長性
  • 均一化と標準化
  • リソース共有
  • 仮想化
  • ファブリック管理
  • 弾力性
  • 共有リソースの分割
  • コストの透過性

マイクロソフト社内のチームが、これらの原理を収集して定義しました。このチームでは、メガ データセンターを運営している Global Foundation Services (GFS)、マイクロソフト社内のインフラストラクチャとアプリケーションを管理している MSIT、およびこの調査に協力することを承諾してくれた数社の大企業のプロファイリングを行いました。上記の定義と要件に基づいて、アーキテクチャの設計に取り掛かりました。この段階では、要件の定義を進めて、要件を実現するためのアーキテクチャ モデルを作成しました。

プライベート クラウド/IaaS リファレンス アーキテクチャ

私が執筆した 2010 年 6 月号の The Architecture Journal の技術記事「From Virtualization to Dynamic IT」(仮想化と動的な IT、英語) で紹介したアーキテクチャ アプローチを使用して、図 1 のモデルをリファレンス アーキテクチャの基盤として使用することにしました。  

図 1 リファレンス アーキテクチャの主な構成要素

ハードウェア層

ハードウェア層には、データセンターの施設、機械装置、ストレージ、ネットワーク、およびコンピューティング インフラストラクチャが含まれます。これらの各要素では、上位レベルのアーキテクチャを操作するための管理インターフェイスを提供する必要があります。たとえば、Web Services-Management (WS-Management) をサポートするサーバー、Windows PowerShell や Storage Management Initiative – Specification (SMI-S) インターフェイスを提供するストレージ アレイです。

マイクロソフトは、マイクロソフト製ソフトウェアを組み合わせて使用したり、ガイドラインを統合したり、コンピューター、ネットワーク、およびストレージについて OEM パートナーの構成を評価したり、プライベート クラウド ソリューションを作成する目的でソフトウェア コンポーネントに付加価値を提供したりするために Microosft Hyper-V Cloud FastTrack プログラムを開発したと述べています。Hewlett-Packard Co.、Dell Inc.、IBM Corp.、Fujitsu、Hitachi Ltd.、および NEC Corp. は、FastTrack プログラムに参加しているパートナー企業で、ハードウェア層向けの有効な統合ソリューションを提供しています。

仮想化層

Windows Server 2008 R2 (現在は、サービス パック 1 がリリースされています) と Hyper-V で、仮想化層を提供しています。この層により、VLAN で仮想マシン (VM) やネットワークを使用したり、クラスター共有ボリュームや仮想ディスクを使用してストレージを提供することが可能になります。仮想化層は、リソース共有や弾力性など、NIST が定義するクラウドの基本的な特徴を実現するのに役立ちます。また、容量をより迅速に共有および準備できます。

自動化層

自動化層は、下から 3 番目の層です (図 2 参照)。IT プロセスの自動化という観点では、自動化層、管理層、およびオーケストレーション層は、非常に細かいものから幅広いものに至るまで、さまざまなもので構成されています。この 3 層の中で最下位に位置している自動化層には、Windows PowerShell 2.0、Windows Management Instrumentation (WMI)、および WS-Management などのテクノロジが含まれています。これらの基本的なテクノロジでは、上位レベルの管理システム、物理リソース、および仮想リソースを操作するインターフェイスを提供します。

図 2 プライベート クラウド モデルで採用されているボトムアップのアーキテクチャ

管理層

管理層は、更新プログラムの基準を満たしているかどうかの確認、更新プログラムの展開、インストールの確認などの管理タスクの実行に自動化層のテクノロジを使用する、いくつかの Microsoft System Center の製品で構成されています。管理層では、基本的な処理の自動化を実現しますが、通常、その対象はサーバーの管理ライフサイクルの特定の側面 (展開、更新プログラムの適用、監視、バックアップなど) に制限されています。

オーケストレーション層

オーケストレーション層は、従来の IT 環境にはあまり見られないものですが、クラウドの特徴を提供するうえで欠かせません。オーケストレーション層では、複数の製品、テクノロジ、およびプロセスをバインドして、エンド ツー エンドの IT プロセスの自動化を実現します。System Center Configuration Manager では、更新プログラムの展開を自動化できますが、サービス管理システムや他のサードパーティ製品/ソリューションと統合するには、オーケストレーション層で、複数の製品においてエンド ツー エンドなプロセスを調整する必要があります。

この層では、System Center Opalis を使用します (この製品は、近日、System Center Orchestrator と改名される予定です)。Opalis では、System Center 製品を統合して、多数のサードパーティ製ソリューションやパートナー ソリューションとの統合を促進します。オーケストレーション層は、クラスターの展開、ホストへの更新プログラムの適用、VM の準備など、複雑なタスクを自動化するワークフローやランブックを作成するのに役立ちます。

オンデマンドのセルフサービスと管理者インターフェイス

NIST が定義しているクラウドの特徴であるオンデマンド (ユーザー) のセルフ サービスは、多くの IT 組織にとって新しい概念です。基本的には、ユーザーの IT リソースに対するニーズとリソースの提供の間にある障壁を取り除くことです。たとえば、新しいサーバーの要求があってから、実際に新しいサーバーが利用できるようになるまでに最大 6 か月かかる組織もあります。プロセスとテクノロジの制限により、この遅延が生じます。

セルフ サービスの機能を実現するには、ユーザーがサービスを要求するための新しいインターフェイスが必要になります。このインターフェイスとして、多くのコミュニティでは、IT セルフ サービス ポータルが採用されています。このようなポータルでは、ユーザーが、新しい項目 (VM など) を要求できるサービス カタログを提供します。

私たちのリファレンス アーキテクチャでは、ユーザー用のセルフ サービス インターフェイスと IT 組織用の一元管理者インターフェイスの両方を用意しました。マイクロソフトでは、ユーザー用のインターフェイスについては、System Center Virtual Machine Manager (VMM) Self-Service Portal 2.0 を提供し、カスタム シナリオと管理者用のインターフェイスについては、Dynamic Datacenter Toolkit for Hosters (DDTK-H) を提供しています。私たちのソリューションでは、カスタマイズと自動化が必要だったので DDTK-H をカスタマイズしたものを使用しました。今後リリースされるマイクロソフト製品では既定に近い状態で使用できるソリューションが提供されることを期待します。

管理者インターフェイスには、System Center Service Manager (SCSM) と System Center のインターフェイスを使用しました。SCSM は、Microsoft System Center の中で最も新しい製品で、構成管理データベース (CMDB) と堅牢な変更管理ソリューションを提供します。私たちのソリューションでは、すべての一般的な操作が SCSM の変更要求として発信されます。この変更要求により、Opalis の自動化されたワークフローがトリガされます。このようにして、適切な変更管理を行いながら、高度な自動化の機能を提供しています。

プライベート クラウド/IaaS 論理モデル

従来のデータセンターおよびサーバーで構成された環境とプライベート クラウドを明確に区別するのは、サーバー、ネットワーク、ディスクなどの物理リソースの抽象化です。物理リソースは、上位レベルの論理グループ (リソース共有、障害ドメイン、アップグレード ドメインなど) に配置されます。これらの論理グループは、物理インフラストラクチャにマッピングされており、インテリジェントなプロビジョニングや管理上の判断を下すのに役立ちます。Global Foundation Services、Windows Azure、および MSIT の調査によると、私たちのリファレンス アーキテクチャでは論理モデルを使用していることがわかりました (図 3 参照)。

図 3 プライベート クラウド/IaaS の論理グループ モデル

オブジェクトの定義は次のとおりです。

IaaS ファブリック: ファブリックは、リファレンス アーキテクチャの制御下にある、すべてのインフラストラクチャとシステムで、複数のサイトやデータセンターで構成されていることがあります。

データセンター/サイト: 1 つ以上のリソース共有をホストしている物理的な場所またはサイト。

リソース共有: リソース共有は、同じハードウェアと構成の基準を使用しているサーバー、ネットワーク、およびストレージのスケール単位で構成されています。他のリソース共有とは同じ単一障害点を共有しません (ただし、施設自体は除きます)。リソース共有は、障害ドメインに分割できます。この場合、障害ドメインは、他の障害ドメインと同じ単一障害点を持たない共通の構成を使用する物理的なインフラストラクチャを意味します。簡略化のため、私たちのソリューションでは、リソース共有と障害ドメインは同等にしました。

スケール単位: スケール単位は、1 つの単位として展開されているサーバー、ネットワーク、およびストレージ容量です。これはファブリックに展開される容量の最小単位です。顧客の規模によっては、スケール単位は、4 台のノードで構成された Hyper-V クラスターの場合もあれば、ラック一杯に搭載された 64 台のブレード サーバーの場合もあります。通常、このサイズは、3 か月ごとに必要になる平均的な容量に設定します。一度に 1 台ずつサーバーを展開するのではなく、追加の容量が必要になったときには新しいスケール単位を展開して、拡張の余地を残します。

ホスト クラスター: ホスト クラスターは、フェールオーバー クラスター構成の 2 ～ 16 台の Hyper-V サーバーと関連のあるネットワークとストレージです。

アップグレード ドメイン: アップグレード ドメインは、VM やリソース共有で実行しているワークロードでダウンタイムを発生させることなく、VM のメンテナンス、オフライン化、およびアップグレードを実行できるリソース共有に含まれる一連のインフラストラクチャです。このアーキテクチャでは、リソース共有 1 のすべてのクラスターの各ノード 1 がアップグレード ドメインになります。各クラスターにはスペア ノードがあるので (15 + 1)、各クラスターでは、ダウンタイムを発生させることなく 1 つのノードのメンテナンスを実施できます (VM のライブ マイグレーションは、メンテナンス前に実行されます)。そのため、リソース共有 1 のすべてのノード 1 は、アップグレード ドメイン 1 として定義されます。すべてのノード 2 は、アップグレード ドメイン 2 として定義され、それ以降についても同様です (図 4 参照)。

図 4 リソース共有と子スケール単位

これらのコンテナーは、インテリジェントなプロビジョニングと管理を実現できるようにするために定義および実装しています。たとえば、4 台のサーバーがある Web ファームでは、サイトで障害が発生した場合に備えて、少なくとも 1 つのサイトで高可用性を確保する必要があります。そのために必要なのは、プロビジョニングの要求が 2 つのサイトと 2 つ以上のリソース共有に送信されるようにすることだけです。これは、リソース共有と物理インフラストラクチャへのマッピングの定義によって実現されます。VM を適切にレイアウトすると、サービスの弾力性が得られます。

System Center に慣れ親しみのあるユーザーは、この記事で取り上げたコンテナーと定義が System Center に既定で用意されているものでないことにお気付きでしょう。ここでは SCSM の CMDB の拡張性を利用して、これらのコンテナー、属性、およびリレーションシップを定義しました。Opalis のワークフローの自動化では、これらに基づいて処理を実行しています。VMM 2012 では、これらのコンテナーとリレーションシップの多くが既定で利用できるようになる予定です (ただし、名前付け規則は異なります)。

プライベート クラウド/IaaS リファレンス アーキテクチャの実装

管理プラットフォームの論理部分と物理部分を VM ホスティング プラットフォームから切り離すことは、それぞれを個別にスケールするのに役立ちます (図 5 参照)。図 5 の中央には、管理システムの管理下にあるリソース共有があり、ソリューション全体を既存のデータセンターに配置できることが示されています。

図 5 アーキテクチャの実装方法を示す論理図

リファレンス アーキテクチャの実装で重要な要素は、展開の速度と実装の一貫性を向上することを目的とした自動化された展開です。Microsoft Services は、さまざまなパートナーやユーザーと仕事をしているので、これは経験則です。展開を自動化するため、リファレンス アーキテクチャの実装には、無償で使用できる Microsoft Deployment Toolkit (MDT) と Microsoft Services Hydration Framework を含めました。そのため、MDT に加えて、さらに展開を自動化できます。

設計プロセスの次のステップは、詳細な設計が必要な領域を特定することでした。それらを次に示します。

  • 各 System Center 製品の詳細な設計
  • ファブリック管理ホスト インフラストラクチャの詳細な設計
  • ファブリック管理のプロビジョニング
  • スケール単位の設計
  • スケール単位のプロビジョニング
  • ワークフローの設計

リファレンス アーキテクチャでは、NIST が定義するクラウドの各特徴のソリューションと高度な IT の自動化を実現する原動力を提供します。自動化するシナリオを選択するときには、複雑さ、コスト、およびユーザー エラーの可能性の高さに重点を置きました。その結果、ソリューションでは、次のプロセスを自動化することにしました。

ファブリック管理のインストール

  • ファブリック管理の Hyper-V ホストの展開
  • 仮想化された SQL Server クラスターの展開
  • VMM の展開
  • SCSM の展開
  • System Center Operations Manager (SCOM) の展開
  • System Center Configuration Manager (SCCM) の展開
  • System Center Opalis の展開
  • カスタマイズと構成

スケール単位 (ホスト クラスター) のプロビジョニング

  • OS のベアメタル インストール
  • Hyper-V のインストール
  • クラスターの構成

スケール単位 (ホスト クラスター) への更新プログラムの適用

  • アップグレード ドメインごとに、VMM メンテナンス モードと SCOM メンテナンス モードを使用して、更新プログラムを適用するために VM をホストからライブ マイグレーションする調整を行う
  • ホストに更新プログラムを適用して、正常に適用されたことを確認するように SCCM を調整する
  • ホストのメンテナンス モードを解除して、次のアップグレード ドメインの処理に移る

ホストのメンテナンス

  • VMM メンテナンス モードと SCOM メンテナンス モードを使用して、メンテナンスが必要な VM をホストからライブ マイグレーションする調整を行う
  • ホストのメンテナンス モードを解除する

VM のプロビジョニング

  • ポータルのインターフェイスで VM をプロビジョニングする機能を提供する
  • Opalis: プロビジョニングの要求を受け取って、事前に構成されたテンプレートに基づいて VM のプロビジョニングを調整する
  • Opalils: VM が作成され、すべての System Center 製品で確認できるようにする
  • Opalis: 要求された VM に SCOM エージェントをインストールする
  • VM はポータルのインターフェイスで提供され管理できる

VM のプロビジョニング解除

  • ポータルのインターフェイスで VM のプロビジョニング解除を要求する
  • Opalis: プロビジョニング解除の要求を受け取って、System Center 製品から VM を削除し、VM を削除する
  • Opalis: VM の Active Directory コンピューター アカウントと DNS A レコードを削除する

このシリーズの第 2 部では、ファブリック管理アーキテクチャの設計について詳しく説明します。ファブリック管理の Hyper-V クラスターの設計、仮想化された SQL Server クラスターの設計、および各 System Center 製品の設計について取り上げます。また、16 台のノードで構成された Hyper-V クラスターのスケール単位の設計についても説明します。

David Ziembicki David Ziembicki は、Microsoft Public Sector Services で CTO 兼ソリューション アーキテクトとして働いており、仮想化とプライベート クラウド コンピューティングを専門としています。Ziembicki は、Microsoft Certified Architect を保有し、マイクロソフトに 5 年務めており、複数の政府機関でインフラストラクチャ プロジェクトを責任のある立場で担当しました。また、マイクロソフトのプライベート クラウドと仮想化サービスに関して第一線で活躍するアーキテクトで、マイクロソフトが主催する複数のイベントで講演を行ったり、複数の仮想化関連のトレーニングのインストラクターを務めました。ぜひ、彼のブログ (英語) にアクセスしてください。
Adam Fazio Adam Fazio は、US Public Sector Services で CTO 兼ソリューション アーキテクトとして働いています。顧客の IT インフラストラクチャをコスト センターから主要な戦略的な資産に進化させることに情熱を持って取り組んでいます。コア インフラストラクチャの最適化という広範なトピックに取り組んでいますが、プライベート クラウド、データセンター、仮想化、管理と運用、ストレージ、ネットワーク、セキュリティ、ディレクトリ サービス、ユーザーとプロセスを専門としています。Fazio には、「Private Cloud TechNet Blog (英語)」と Twitter (英語) からアクセスできます。

関連コンテンツ