ソフトウェア・デファインド・データセンター内のハイブリッドIT
ごく最近まで、静的なアーキテクチャーがクライアント/サーバーコンピューティング環境を支配していました。しかしながらモバイルデバイスとそのコンテンツ、サーバー仮想化、ビッグデータ、クラウドなどの登場に伴って状況は一変しました。今日ではSDxの利用が拡大しています。以下ではネットワークを変革するにあたって理解しておくべき事項をご紹介します。
ヨギ・ベラ氏の有名な語録に「分かれ道に来たらとにかく進め」というのがありますが、これは仮想ハイブリッドIT環境への道程にもあてはまります。ごく最近まで、静的なアーキテクチャーがクライアント/サーバーコンピューティング環境を支配していました。しかしながらモバイルデバイスとそのコンテンツ、サーバー仮想化、ビッグデータ、クラウドなどの登場に伴い、エンタープライズデータセンターのトラフィックパターンは一変しました。今日のデータセンターネットワーク需要の増大によって、増加している伝統的なサーバー/クライアント間の南北トラフィックだけでなく、データセンター内およびパブリックやプライベートのクラウド内で発生する新しい東西のマシン間のトラフィックを処理するために、膨大なコンピューティングパワーが必要となっています。
新しいソフトウェア・デファインドの概念と、仮想ソフトウェア・デファインド・データセンター (SDDC) が約束するすべてを最大限に活用するために開発された補完テクノロジーを、企業は受け入れつつあります。完全仮想ハイブリッドIT環境を実現する道のりは複雑ですが、そのパフォーマンス、俊敏性、コストにおける利点を考えれば、その道を進む価値はあります。前進する上で理解しなければならない主な概念とテクノロジーについて詳しく説明していきます。
コンピューターの仮想化: ソフトウェア・デファインド・コンピュートとも呼ばれるコンピューターの仮想化は、SDDCのベースとなる基礎的なテクノロジーです。x86サーバーを必要とし、ほとんどのデータセンターが使用する業界標準のテクノロジーとなります。このテクノロジーは重要です。かつて、従来型でデプロイされたサーバーは、容量の約10~15%しか使用されていなかったからです。仮想化は、メモリとCPUを物理ハードウェアからデカップリング、つまり分離し、これにより必要になるたびに未使用のリソースを使用することができます。デカップリングによって、x86物理サーバーに同時に存在して稼働するアプリケーションやそのオペレーティングシステムに対して、個別のコンテナーまたは仮想マシン (VM) が作成されます。結果として、サーバー容量のほとんどを使用することになります。コンピューターの仮想化によって、サーバー効率を上げ、低いコストでパフォーマンスと可用性を向上させることができます。
ハイパーバイザー: コンピューター仮想化テクノロジーの基本的なピース (要素) がハイパーバイザーです。ソフトウェアのこのピースによって、物理ハードウェアやホストマシンでゲストとして動作するVMの間で、物理デバイスがリソースを共有することができます。Wikipediaには、「ハイパーバイザーまたは仮想マシンモニター (VMM) は、VMを作成して実行するコンピューターソフトウェア、ファームウェア、ハードウェアのピースである。ハイパーバイザーが1つ以上のVMを実行するコンピューターはホストマシンと呼ばれ、各VMはゲストマシンと呼ばれる」と記載されています。
ハイパーバイザーにはいくつかの種類があります。本稼働システムでよく使われる種類は、ベアメタルインストールとして実装されます。これは、オペレーティングシステムとしてインストールされるソフトウェアの最初のピースで、ハイパーバイザーにもなります。リソースが続いて仮想化され動作するVMに提供される基盤となる物理サーバーハードウェアと直接通信します。別のハイパーバイザーとしては、ホステッドハイパーバイザーが挙げられます。このシナリオでは、ソフトウェアはすでに存在するオペレーティングシステム上にロードされます。リソースがVMをパススルーするための追加のホップを必要とする場合でも、レイテンシは最小限に抑制されます。
第三のオプションは、ゲストマシンと呼ばれており、仮想マシンとしても知られています。この場合、ハイパーバイザー上にインストールされるワークロードになります。仮想アプライアンス、オペレーティングシステム、仮想対応ワークロードである可能性があります。これは、専用のリソースを持つ独自のシステムであるかのように、一方的に動作します。仮想化テクノロジーを利用することで、複数のVMが物理ホストの上で動作することができる一方で、リソースは他のVMと共有することができます。
コンテナー: コンテナーとVMは同じものと考えられがちです。実際、この2つはよく似ていますが、異なる重要な長所と短所があります。ITworldの記事の中で、Steven J. Vaughan-Nichols氏は「コンテナーにおいて重要なのは、単一アプリケーションのみを実行することです。コンテナーに多くの機能を期待すれば期待するほど、そもそも仮想マシンを使用するべきであった可能性が高くなります」と語っています。同氏はさらに次のように説明しています。「VMは多くのシステムリソースを消費します。各VMは、オペレーティングシステムの完全なコピーを実行するだけでなく、オペレーティングシステムが実行する必要のあるすべてのハードウェアの仮想コピーも実行します。結局、これによりRAMやCPUサイクル消費量がすぐに膨れ上がります。対照的にコンテナーは、特定のプログラムを実行するためのオペレーティングシステム機能、補足的なプログラムとライブラリ、およびシステムリソースしか必要としません」。
では、結論としてはどういうことなのでしょうか? 同氏は「一般的には、単一のアプリケーションを実行する時はコンテナーを、複数のアプリケーションを実行する時はVMを使用するということです」と語っています。
SDS: ソフトウェア・デファインド・ストレージは、ソフトウェアとして配備されるストレージで、アプリケーションと基礎となるストレージサービスは、ハードウェアリソースを共有します。SDSは、ソフトウェア・デファインド・コンピュートに続き、SDDCインフラストラクチャの実現に向けた第2のステップです。SDSを活用する方法はいくつかあります。アプリケーションと同じ場所に設置される仮想ストレージアプライアンスによるコスト最適化アプローチ、または、大企業のトラフィック要件にもうまく機能する専用仮想マルチテナントシステムを使用するサービスレベル最適化アプローチのいずれかを採用します。SDSは非常に拡張性が高く、業界標準サーバー上に構築できるため、専用アレイを廃止することができます。
SDN: ソフトウェア・デファインド・ネットワーク (SDN) もSDDCに欠かせない構成要素であり、現代のコンピュート環境のニーズに最適です。SDNを活用することで、ネットワーク管理者は下層の機能を抽象化して、ネットワークサービスを管理できます。これは、コントロールプレーン (トラフィックの送信先を決定するシステム) を、データプレーン (選択した宛先にトラフィックを伝送するシステムの基盤) から切り離すことによって実現されます。ネットワークの制御を直接プログラムできるようになり、基盤のインフラストラクチャはアプリケーションやサービスに対して抽象化することができます。他の利点としては、ネットワークの敏捷性の向上や集中制御機能が挙げられます。オープン標準を通じて実装される場合は、ベンダー中立で標準ベースの提案となります。SD-WANは、このテクノロジーを広域ネットワークに適用したものです。
NFV: ネットワーク機能仮想化 (NFV) は、仮想化テクノロジーを使用してネットワーク機能を分離し、ITが自由に接続できる個別の仮想ネットワーク機能 (VNF) を作成します。ファイアウォール、ロードバランサー、WANアクセラレータなどのアプライアンスを仮想化すれば、個別のハードウェアを維持管理する必要がなくなります。VNFは複数のVMまたはコンテナーで構成され、個々のネットワーク機能を提供するハードウェアアプライアンスの代わりに、標準的なインフラストラクチャ上でさまざまなソフトウェアやプロセスを実行します。NFVはSDNと似ていますが、違いもあります。これはSDNに依存しないため、SDNを使わず既存のネットワーク上でVNFを採用できる可能性があります。とは言え、SDDC環境におけるSDNのパフォーマンス/コストメリットは明白であり、複数のベンダーがNFV/SDNプラットフォームを提供しています。
オーケストレーション: SDDCのオーケストレーション/自動化レイヤーでは、SDDCのメリットが稼働中のアプリケーションに直接提供されます。オーケストレーション/管理ソフトウェアはポリシーを確立および自動化し、反復可能な標準プロセスを使用して、データセンター内のアプリケーションやサービスを管理します。高度に自動化された場合、オーケストレーションはITスタッフの負担を大きく軽減できます。またオーケストレーションは、スケーラビリティの向上、コンプライアンスの徹底、カスタマーエクスペリエンスとサービス品質の改善などにも貢献します。オーケストレーションは、SDDC全体にわたるプロビジョニングから容量やコンプライアンスの管理に至るまで、さまざまな処理を取り扱えます。さらにSDDC内のアプリケーション、データ、VM、およびコンテナーを保護するための各種セキュリティサービスを調整して、ディザスタリカバリプロセスを支援することも、オーケストレーションの重要な役割の1つです。
VMベンディング: VMベンディングはVM用の管理ツールです。管理者はこのツールを使用することで、新しいVMの作成や展開を含めて、担当する環境内に存在するすべてのVMのステータスを確認および管理できます。
ここに挙げたテクノロジーとコンセプトはいずれも、各組織がSDDCおよび仮想ハイブリッド環境を運用する上で重要な役割を果たします。これらの要素をどのように活用するかは、各組織のIT部門に委ねられており、IT部門はネットワークトポロジに応じて最適な手法を選択する必要があります。
ローマへの道
「すべての道はローマに通ず」ということわざがあります。企業を仮想ハイブリッドIT環境で調和の取れた点まで導く方法を説明するには、このことわざがぴったりです。Red Hat社のグローバルプロダクトマーケティング担当シニアディレクターであるMargaret Dawson氏は、「ハイブリッドITは、一様とは限りません。その過程で、ハイブリッドで非常に異種混合な環境をうまく統合するために、できることはたくさんあります。ハイブリッドIT環境の複雑さはその構造 (物理インフラストラクチャ、仮想環境、プライベートクラウド、パブリッククラウドが混在) だけにとどまりません。ハイブリッドIT環境内には連携可能または不可能な多種多様のテクノロジーが存在しています」と語っています。
「モダナイゼーションにあたっては、スタックを構成する各レイヤーを入念に検証することが大切です」とDawson氏は続けます。「例えばストレージの場合であれば、従来型のストレージモデルから分散ソフトウェア・デファインド・ストレージ環境への移行が可能かどうかを検討する必要があります。クラウドへの移行を開始する中で、従来型のインフラストラクチャで使用できて、仮想インフラストラクチャでもうまく動作するものを考えてください。」
何社もの著名なITインフラストラクチャ管理およびセキュリティ企業で、最高マーケティング責任者 (CMO) および戦略マーケティングエグゼクティブを務めるAtchison Frazer氏は、この問題と現在の状況を次のように説明しています。「私が確認しているのは、コンテナー化の概念を持ってきて、アプリケーションなどのその他すべてのレガシーコンポーネントに重ねるオーバーレイアプローチです。ある意味で、セキュリティやネットワークのポリシーを、動的な変更も含め、すべてこのレイヤーを通じて完了できるコンテナー化されたファブリックを作成していきます。そうしない場合、あまりにも複雑な入り組んだ方程式に陥ることになります。現時点では、企業は85~90%、レガシーアプリケーションを稼働しています。」
完全な統合ハイブリッドIT環境を1回で手に入れる方法ありませんが、正しい決断を下すためのステップはあります。たどる経路の決定は、自身のネットワークと、この上で動作しているビジネス部門のアプリケーションによって変化します。
マップの使用
ゲートを出発して、ITが移行を計画する上での最初の作業は、すべてのインフラストラクチャハードウェア、各資産のリソース支出、実行されるアプリケーションのネットワークマップを作成することです。ビジネスクリティカルな財務アプリケーションやERPアプリケーションには特に注意してください。会社の所有物か個人の所有物かに関わらず、すべてのモバイル機器を考慮して、すべてのアプリケーションを一覧にします。
これによって、不適切なアーキテクチャー、クラウドスプロール、クラウドに移行したい戦略的なビジネスアプリケーションと同じ仮想レイヤーに展開されてパフォーマンスの低下を引き起こしているサードパーティ製アプリケーションなどの問題点を特定して修復する機会が得られます。ハードウェアのオーバープロビジョニングがある場合も明らかになります。これによって、ビジネスクリティカルなアプリケーションのパフォーマンスの低下を回避し、データセンターで稼働していることに気付いてすらいなかったアプリケーションの存在に気付くことができます。
「どのアプリケーション、あるいはVMワークロードを移行するのか理解して、それが健全であることを確認します」とFrazer氏は語っています。「寿命を迎えたアプリケーションや使用されていないレガシーなアプリケーションは排除してください」。
クラウドスプロールに注意
多くのIT組織は、他の事業部門において、簡単でシンプルなInfrastructure-as-a-Service (IaaS) の活用が進んでいることを認識していません。IT組織は当初、小規模なワークグループが必要な時にコンピュートパワーを増やせる簡単な方法としてIaaSを捉えていました。しかし、結局、その思考が彼らを苦しめています。インスタンスが爆発的に増加し、予算とコンピュートリソースを使い尽くしているからです。
どのアプリケーションから移行を開始するか
では、どのアプリケーションを最初に移行するのでしょうか? この点に関しては2つの考え方があります。すなわち、事業部門にとって投資効果が高いワークロードから移行する方法と、まずは戦略的な重要性の低いアプリケーションから移行を開始し、自社およびビジネスパートナーが十分な経験を積んでからビジネスクリティカルなアプリケーションを移行する方法です。
大規模に移行することはありません。メインフレームで稼働しているアプリケーションがあるビジネスは大量に存在しています。この場合、新しいWebサイトのフロントエンドを構築して、これをメインフレームに置くことに決めたため、大量に投資を行っているアプリケーションがあるかもしれません。他の事例では、コンテナー化や仮想化を含む最新のインフラストラクチャにこれらのアプリを移行することに意味があるかもしれません。「これは、何がビジネスにとって最高なのかという点に着目するワークロード単位の意思決定プロセスです」とDawson氏は語ります。「新しくて魅力的なものに関する単なる技術的決定ではありません。どのワークロードがビジネスに最大の影響を与えるかという点に関するものです。」
慎重な選択が大切
ハードウェア、ソフトウェア、およびテクノロジーに関する詳細な要件が明らかになったら、ベンダーソリューションの選択を開始できます。ソフトウェアおよびオペレーティングシステム両方の観点から、ハードウェアを確認してみましょう。この経路全体を通じて一貫性のある基盤を持てるような、新しい物理インフラストラクチャを選択してください。
「統一性を高めることができれば、拡張してコストメリットを活用し、共通のセキュリティおよびコンプライアンスポリシーを作りやすくなります」とDawson氏は指摘します。「相互運用性の問題が少なくなれば、よりシームレスに移行できるようになります。」
ベンダーからショートリストが提示されたら、購入に先立つ概念実証の実施をベンダーに要請してください。あらゆる要件を単一ベンダーで解決するのは難しい可能性があり、また場合によってはオープンソースの利用を検討することも必要です。
オープンソースの活用
SDN、SDDC環境に移行する企業の主な課題は、寿命の終わっていない古くなった設備と新しいインフラストラクチャの間の相互運用性です。この点についてFrazer氏は次のように指摘しています。「ソフトウェア・デファインド環境で常に注意を要するのが『誰の標準を採用するか』という問題で、SDNコントローラーを販売している企業はそれぞれ独自の標準を保有しています。今日ではオープンソースの利用が拡大しつつあります。オープンソースを活用することで、ベンダーロックインなど、多くの問題を回避することができます」。
Dawson氏も 「オープンAPIインフラストラクチャを持つことは重要です。自社開発のSDKをなくすことで、環境がオープンになり、ピースを簡単に統合することができます」と同意しています。
OpenDaylightコミュニティ (開発者、サービスプロバイダー、エンドユーザーで構成されるグループ) は、広く実装されているオープンソースのSDNコントローラーであるOpenDaylight (ODL) を基盤として、プログラム可能で相互運用性に優れたネットワークおよびツールを提供することに力を入れています。ODLプラットフォームは、オープン標準に従い、オープンAPIを採用しています。ODLユーザーは、必要な機能、アプリケーション、プロトコル、プラグインを複数のベンダーの製品ラインから選択して、サービスプロバイダーや顧客のために接続を提供できます。多くのメリットを提供するODLプラットフォーム の詳細をぜひお確かめください。
結論
SDDCは、完全にクラウドにデプロイされるインフラストラクチャへの単なる通過点ではありません。物理環境、仮想環境、プライベート/パブリッククラウドが混在するハイブリッド環境は、この先長年にわたって主流のIT環境になると予想されます。いずれか1つの環境を選択する必要はありません。むしろ、SDDCは、クラウドへの道に存在し、クラウドは未来のデータセンターの重要な一部なのです。
ソフトウェア・デファインド・データセンター: リーダーへの教訓
- SDDCを実装するには、既存のデータセンターによって提供されるサービスだけでなく、将来の計画も理解する必要があります。
- ソフトウェア・デファインド・インフラストラクチャの取り組みは、IT部門と事業部門の双方から賛同を得た上で、確かな計画に基づいて進めることが大切です。
- ハイブリッドITとSDDCは相補的に機能します。
この記事/コンテンツは、記載されている特定の著者によって書かれたものであり、必ずしもHewlett Packard Enterprise Companyの見解を反映しているとは限りません。

Alyson Behr
フリーの寄稿者
Alyson Behrは、テクニカルライター、編集者、および戦略的コンテンツのコンサルタントです。Alysonは、製品テスト、業界競争分析、および製品レビューに関する豊富な実績と知識を生かして、PC Magazine、Computerworld、eWeek、InfoWorld、InternetWeek、SD Times、InformationWeekなど、数多くのテクノロジー誌の記事を執筆しています。また戦略的コンテンツ開発の専門家として、Alysonはネットワークのテスト/測定コミュニティ向けの初の専門誌である、Spirent Communication社出資のLabRat Magazineの創刊も牽引しました。現在は、IT業界向けの製品/サービスのレビューおよびコンサルティングを主な業務としています。
enterprise.nxt
ITプロフェッショナルの皆様へ価値あるインサイトをご提供する Enterprise.nxt へようこそ。
ハイブリッド IT、エッジコンピューティング、データセンター変革、新しいコンピューティングパラダイムに関する分析、リサーチ、実践的アドバイスを業界の第一人者からご提供します。
関連リンク