NetApp Tech OnTap
クラウド導入を成功に導く“6つ”のヒント
~ニーズに合ったクラウドの選択~

クラウド・インフラについては、現場での経験に基づく実際的なアドバイスよりも、マーケティング的な盛り上がりが先行しているというのが現状です。私は幸いにも、TelstraSensisなどの企業で大規模な共有インフラの構築をお手伝いし、最近ではほかの大企業がダイナミック・インフラ・サービスを構築する手法を、直に目にする機会にも恵まれました。このような環境の構築を通じてNetAppが得た経験は、NetApp Dynamic Data Centerに結実しています。これは、柔軟性の高いクラウド・ストレージ・ソリューションでクラウドを導入する、NetAppベスト・プラクティスを集約したものです。

この記事では、エンタープライズクラスのクラウド・サービスを検討する際、最も重要と思われるいくつかの事項について説明します。これらのヒントは、社内クラウド・インフラの導入を検討している企業にも、要求の厳しいクラウド・カスタマー向けにエンタープライズ・サービス・レベルの提供を検討しているサービス・プロバイダにも、同じように役立つはずです。Tech OnTap今月号のケーススタディには、私がこれから説明するヒントの多くを実践した、あるサービス・プロバイダの事例が紹介されています。

クラウドとは、標準化された再利用可能なサービスとして、テクノロジをパッケージ化し、価格を設定し、提供することです。これから説明する最初の2つのヒントは、クラウド・サービスをどのように定義するかに説明の重点を置いています。3番目以降のヒントでは、テクノロジについて詳しく検証します。

ヒント1:必要なクラウドのタイプを判別する

まずすべきことは、クラウド・サービスの境界を定めることです。何をプロビジョニングするか、何を自分で管理するか、(コンピューティング、ネットワーク、ストレージ、OS、アプリケーション、データ保護の観点で)サービスの物理的な境界をどこにするかを決定します。サービス・レベル・アグリーメント(SLA)に適合するためには、自分が提供するもの(と、お客様が提供するもの)を明確にしておかなければなりません。NetAppでは、IT as a Service(ITaaS)という大きい傘の下に、次の4つのサブカテゴリのサービスを用いています(図1を参照)。

図1)利用可能なクラウド・サービスの種類

図1)検討すべきクラウド・サービスのタイプ

ニーズに合ったクラウドを選択するには、現実的な目標から始める必要があります。シンプルにStorage as a ServiceまたはInfrastructure as a Service、あるいはDesktop as a Service(IaaSの一種)から始めると良いでしょう。何を提供するか、管理の境界線をどこにするか、安全なマルチテナント環境が必要なレイヤはどれか(クライアント間の安全な分離をアプリケーション内で行うか、それともインフラ内で行うか)を決定します。しっかりした基盤を作ることが重要です。基本的な機能を立ち上げれば、その上に機能を追加していくことができます。

何をクラウドで調達できるかについても、考える必要があります。例えば多くのアプリケーション・チームが、開発やテスト・インフラに関するニーズを満たすために外部のクラウド・サービスを利用しています。業務ITのすべてをアウトソーシングしている企業もあります。最大規模のクラウド・サービス・プロバイダの多くは、仮想コンピューティング、ネットワーク、ストレージを備えたホスティング環境としてのIaaSだけでなく、管理されたOSやアプリケーション、さらには開発環境(実質的にIaaS、PaaS、SaaS)も提供しているので、きわめて大規模な企業でも、希望すればIT全体をクラウドで調達することが可能です。T-Systemsは、その好例です。同社が構築したエンタープライズクラスのIaaS、PaaS、SaaSクラウドは、数百社の大企業に利用されています。

この選択肢における最後のアドバイスは、ポリシー、ガバナンス、セキュリティ、調達の一元化などを含めて、あらゆる決定事項に対して経営陣からの賛同を取り付けることです。クラウドへの移行は、新しいプロセスや組織変更を伴う場合が多いので、社内のあらゆるレベルからの支援が必要になります。

ヒント2:提供するサービスは「80:20の法則」を応用して決定する

顧客の要求を100%満たすクラウドを構築しようとすれば、おそらく失敗します。パレートの「80:20の法則」によれば、アプリケーションに関する要求のうち80%は、20%の労力で実行可能な標準サービスセットによって満たすことが可能です。要求の80%を満たすことを目標に、標準サービスのカタログまたはメニューを作成することです。一般にサービス・カタログでは、次のものを提供します。

  • 各種のストレージ階層によって、各アプリケーションの容量やパフォーマンス・ニーズに対応できるようにします。
  • さまざまなRPOおよびRTO要件に対応する、さまざまなデータ保護レベル。
  • 物理OS、仮想OS、およびサーバ・タイプの標準セットをサポート。
  • アプリケーションの結合性やデータ・レイアウトについての基準を示す、アクティベーション・ガイド(スループットや遅延に関してテスト済みのもの)。
  • アーカイブやコンプライアンス・ニーズに対応する長期保持オプション。

カタログの項目ごとに、SLA、セキュリティおよび分離に関する期待値、顧客に対する課金方法、追跡すべきメトリック、各部門への請求方法についても考慮する必要があります。全SLAへの適合状態を示すレポートも、作成できなければなりません。

要求の残り20%に対応するには、労力の残り80%が必要になるはずです。標準的なクラウド・サービスで満たせない、これらの要求に対処するには、はるかに長い期間が必要になり、結果的にコストも高騰します。しかし時間が経つにつれ、このような要求をするユーザが標準的なサービスを利用する利点(開発期間の短縮、コストの削減)を実感するようになるので、新しい要求の90%以上が、標準オファーで十分ということになる可能性があります。

ヒント3:10ギガビット・イーサネットを基盤として使用する

Fibre Channel(FC)ストレージ・エリア・ネットワークに莫大な投資をしてきた企業なら、クラウド・インフラの一部にFCを使用したいと考えるかもしれません。私は、FCの利用をお勧めしません。大規模クラウド・サービスは、サービス・プロバイダか、自社運用かを問わず、そのほとんどがイーサネットを基盤としています。その理由は、イーサネットが提供する高度な柔軟性、拡張性、可視性です。また、スケール・メリットにより、継続的にコストを削減できるという事実もあります。

私がこれまで手がけたクラウドは、主にNFS、一部がiSCSIを使用しており、現在はFibre Channel over Ethernet(FCoE)に関心が集まっています。TSystemsThomson-ReutersOracleTelstraなどの大手プロバイダは、NFSを選択しています。その理由は、低コスト、簡易性、シン・プロビジョニングとクローニングの容易さ、ストレージ・クラウド内のファイルシステムに関する可視性です。これらのプロバイダでは、大容量のOracleデータベースにも、VMware®インフラにもすべてNFSを使用しています。

データセンター間で仮想サーバとストレージを移動可能にしたい場合や、ストレージ・ネットワークおよびコンピューティング・ネットワークが複数のデータセンターにまたがるようにしたい場合には、一般にイーサネットとInternet Protocol(IP)が必要です。これらを使用すると、作業負荷の分散やアプリケーションの移動も容易になります。

現在10ギガビット・イーサネットが広く普及しており、40ギガビット・イーサネットも登場しつつあります。したがって広帯域と低遅延の観点から、イーサネットをデータ・トラフィックとユーザ・トラフィックの両方のバックボーンに選ぶのが合理的です。今後はイーサネット・ストレージが主流になる見込みなので、イーサネット・ストレージを選んでおくと投資が無駄になりません。

ご存知かもしれませんが、CiscoではFCoEやData Center Ethernet(別名、Data Center Bridging [DCB])の研究開発を含めて、イーサネット・テクノロジを成功させるために力を注いでいます。DCE/DCBは、イーサネットでストレージ・トラフィックのロスをなくすだけでなく、さまざまなプライオリティも提供し、重要度に応じたトラフィックの分割を可能にして、プライオリティ別のキューイングを追加することでQoS機能を提供します。Cisco UCSは、間違いなく過去10年間のサーバ設計における最大の変化の1つであり、10 GbE用に最適化されています。

ヒント4:まずネットワーク、サーバ、ストレージを自動化してインフラのオーケストレーション(連携)を簡素化する

クラウドとは要するに、いくつかのサービス・クラスを持つ大容量のリソース・プールとして、インフラの各レイヤを取り扱えるようにすることです。どの物理システムにリソースが存在しているかを意識する必要がなくなり、必要になった時点でリソースを取り出し、不要になればプールに戻すだけです。これを実現可能にするには、適切なツール・セットを選ぶことが重要です。

インフラ内のレイヤごとに、個々のデバイス管理の複雑性を隠し、それらをリソース・プールとして抽象化するための自動化ツールが必要です。例えばNetApp® Protection Managerでは、次の3つの重要なコンセプトに基づいて、大掛かりな変更をわずか数回のクリックで実行することができます。

  • データ・セット
    同じような保護要件のあるデータ・オブジェクトの集合。
  • ポリシー
    さまざまな手順やスケジュールに対して既存のポリシーを使用したり、違いに応じて新しいポリシーを作成したりすることが可能。
  • リソース・プール
    セカンダリ・ストレージ・リソースが「リソース・プール」としてグループ化される。

これらのコンセプトによって、個々のストレージ・システムを管理する必要がなくなり、多くのメリットがもたらされます。例えば、セカンダリ・サイトにデータを複製するサービス・クラスを提供したい場合には、複製するボリュームまたはLUNを含むデータ・セットを定義し、複製ポリシーを適用します。新しいボリュームをこのデータ・セットに追加するだけで、そのボリュームを同じように保護することができます。

サーバ、ストレージ、ネットワーク・リソースをプールできる、個別のツールがあれば、BMC Atrium Orchestrator、IBM TPM、HP Orchestrator、VMware Lifecycle Managerなどの(またはその他の50社以上に及ぶクラウド・オーケストレーション・ベンダー製の)オーケストレーション・ツールを使用して、すべてのクラウド・サービスを簡単に統合することができます。これにより、ストレージの容量管理やパフォーマンスなどを懸念することなく、オーケストレーション・エンジンで簡単にリソースを要求することができます。このエンジンはワークフローと承認を管理し、リソースをカスタマーに割り当てて、課金設定を行います。このエンジンを使用して、クライアントがクラウドにアクセスするために使用する、非常に重要なセルフサービス・ポータルを構築することが可能です。

ヒント5:セキュリティを最初から組み込む

クラウド・インフラ上にエンタープライズ・アプリケーションの導入を検討するとき、セキュリティは重要な考慮事項になります。サーバ、ネットワーク、ストレージがすべて共有リソースである場合、アプリケーション、データ、カスタマー間の安全な分離を保証するには、どうしたらよいでしょうか。効率性の劣る古いサイロ型アーキテクチャに頼らずに、サーバ、ネットワーク、ストレージ上でデータとアプリケーションを効率よくパーティション化できるテクノロジが必要です。これはインフラ全体でセキュリティを多層化することで達成できます。オペレータの操作ミスによる露出を防止するには、インフラ・レイヤごとに最低2層のセキュリティが必要です。検討すべき重要なテクノロジとして、NetApp MultiStore®、vFiler®ユニット、VLAN、仮想データセンター(VDC)、ACL、ポートACL、Cisco Nexus 1000v、VMware VShield Zonesなどがあります。これらはすべて、インフラ・スタック全体で安全なマルチテナント環境を実現するのに役立ちます。

私が最もよく知っているテクノロジを例に挙げて説明しましょう。NetApp MultiStoreソフトウェアは、1つのストレージ・システムに複数のプライベートな論理パーティションを作成し、保護された仮想パーティションの情報を権限のないユーザが不当に表示、使用、ダウンロードできないようにすることで、安全なマルチテナント環境を実現します。MultiStoreは、ストレージ・コントローラのハイパーバイザに相当します。
独立系機関による最近のMultiStoreセキュリティ分析では、MultiStoreの利点が確認されています。NetAppストレージを採用している大規模クラウド・プロバイダは、ほぼ全社がMultiStoreを選択しています。

ヒント6:常時稼動のインフラを作成する

すぐには実感できないかもしれませんが、同じ物理インフラを50ものアプリケーションで共有する場合、メンテナンスのためにインフラをシャットダウンすることは不可能です。私が関係したあるサイトでは、共有ストレージ・システムの停止を計画するのに、18カ月もかかったことがあります。このインフラを利用している大手5社のクライアント(そのうち1社は南半球最大のCRM環境)すべての都合に合った停止期間を決めることができなかったためです。

インフラの停止を引き起こさずに、事前に計画を立て、作業負荷を管理できることが必要です。つまり、機器のメンテナンス、ハードウェア交換、ソフトウェア・アップグレードの際に、ライブ・アプリケーション・マイグレーションを実行できるテクノロジを使用しなければなりません。同じテクノロジを利用して、インフラ全体で負荷を分散することも可能になります。

ライブ・データ・マイグレーションについては、NetAppはData ONTAP® 8およびNetApp Data Motion™を提供し、ストレージ・インフラの容量、パフォーマンス、機器を管理できるようにしています。NetApp Data MotionはNetApp MultiStore、SnapMirror®、Provisioning Managerと統合し、イーサネット・ストレージ作業負荷のライブ・マイグレーションと安全なマルチテナント環境を提供します。アプリケーションを稼働したまま、カットオーバー時にI/Oが短く一時停止するだけで、すべての移行処理を実行できます。ストレージ・システム・レベルで処理が実行されるので、ホスト・システムへの影響はありません。データの移行が完了すると、アプリケーションとクライアントは移行先システムに切り替わり、サービスの中断はまったくありません。

ストレージに対してNetApp Data Motionで実行する処理を、仮想マシンについてはVMware VMotion™、XenServer XenMotion、Microsoft® Hyper-V™ Quick Migrationで実行できます。アプリケーションを中断せずに、物理サーバ間でVMを移行することができます。この機能は無停止メンテナンスおよび無停止アップグレードに加えて、仮想インフラにおける各マシンのパフォーマンスの最適化やその他の要件への対応にも使用できます。

まとめ

以上のアドバイスは、いずれも現時点で使用可能なソリューションに基づいています(NetApp Data Motionは、Data ONTAP 7.3.3で使用可能になります)。誇大宣伝に惑わされず、最新のベスト・プラクティスに注意を払うことで、内外の顧客が期待するサービス・レベルを犠牲にせずに、効率性の向上とコスト削減につながる柔軟なインフラを作成できます。

重要なのは、確かな情報を手に入れ、他社の成功事例に学ぶことです。クラウド・コンピューティングの経験が比較的浅い方は、最近のTech OnTap記事およびホワイトペーパーでさらに詳しい情報をご覧ください。クラウドに関連する導入事例をご覧になるには、NetAppライブラリにアクセスし、「クラウド」で検索するか、この記事に出てきた顧客名のリンクをクリックしてください。NetAppのクラウド・テクノロジに関する全情報は、cloud.netapp.comに用意されています。また、弊社のクラウド・チーム・ブログで最新の開発成果について知ることができます。

この記事についてのご意見
NetApp Communityでは、疑問点やアイデア、意見についてオンラインで話し合うことができます。


Hamish McGovernHamish McGovern
シニア・プロダクト・マネージャー、NetApp

Hamishは2000年にNetAppに入社し、NetApp最大級の顧客であるTelstra担当のテクニカル・チーム・リーダーに就任しました。現在は、NetApp Dynamic Data Centerソリューションのプロダクト・マネージャーを務めています。このソリューションは、安全なマルチテナント環境インフラ、NetAppのIaaSクラウド対応技術、およびNetApp Data Motionによるライブ・マイグレーション機能を備えたIaaSを実現するものです。HamishはNetAppに入社する以前、オーストラリア最大のISPでシステム・インテグレーション・チームの責任者を務め、通信およびオンライン・サービス業界で10年の経験を積んでいます。


関連情報