ステップ2：ネットワーク技術検討

　ハイパーバイザーの次に検討すべき要素はネットワークだ。

　ネットワークの検討で最も悩ましいのは、OpenStackプロジェクトで開発している技術、いわゆるリファレンス実装を使うか、商用製品を使うかである。

　OpenStackプロジェクトではリファレンス実装の開発が盛んだ。分散仮想ルーター（DVR）、ロードバランサー、ファイアウォール、VPNゲートウェイなどさまざまな機能が、Open vSwitchやLinux機能、オープンソースソフトの組み合わせで実現できるようになっている。これらは商用製品と比べれば実績は劣るものの、うまく利用できれば劇的な設備コスト削減につながる。ディストリビューションベンダーのサポートが期待できるのであれば、挑戦する価値は大いにある。

　一方、商用製品を否定するものではない。特にネットワークハードウェアと連係し、処理をオフロードできる製品は、性能面のアドバンテージが大きい。性能にシビアな環境において、メリットといえる。コストと得られる価値のバランスで判断すればよいだろう。

　なお、採用技術の検討の他にネットワークで課題になりがちなのは、既存ネットワークとの接続、既存ポリシーの踏襲である。

　OpenStack環境は、大量のサーバを並べてもシンプルさを維持できる物理構成が望ましい。よって10Gbpsイーサネットなど広帯域の物理リンクに、複数種別のネットワークをVLANで集約するケースが多い。OpenStack、周辺ツールの開発者もそのような環境を想定している。一方、企業においては、ネットワークの設計ポリシーが決まっている場合がある。運用LANは物理的に分離するなどだ。そのようなポリシーに、OpenStackの導入や維持に用いるインストーラーや構成管理ツールが対応できるか、事前に確認した方がよい。

　できない場合、テクノロジーリフレッシュのタイミングと考え、ポリシーを見直す良い機会かもしれない。

ステップ3：ストレージ技術検討

　ここまで検討が進んでいれば、おおよその全体像は見えてきているだろう。最後はストレージだ。

　経験上、ストレージでの落とし穴は多くない。主要ストレージベンダーが対応製品を出しており、選択肢に困ることはないだろう。これまでの検討で採用ディストリビューションが絞れておれば、それがサポートするストレージを検討する。

　ベンダー、製品の対応状況は、公式ページに分かりやすくまとまっている。

　ただ、これまでの検討同様、環境全体での整合性確認は必要である。ストレージ視点だけでは見えない制約がないか確認しよう。サーバからのマルチパス設定条件、OpenStack GUI／APIからストレージ拡張機能を利用できるかどうかなど、ユーザー視点で、エンドツーエンドで確認してほしい。

　本稿では、OpenStackでプライベートクラウドを設計するに当たってのおすすめのステップを紹介した。OpenStackは多様な技術の集合体である。枝葉にとらわれず、優先順位や全体を常に意識して設計を進める必要がある。また、さまざまな技術がOpenStackに対応しているが、それらを「組み合わせて」使うことができるかは、常に確認していただきたい。これはOpenStackに限らず、オープンシステムの宿命ではあるが。

　全6回にわたるこの連載は今回で終了である。運用やアプリケーションの作り方など、他にも触れたいテーマはあったが、Web連載という体裁上ここまでとしたい。

　いよいよ本格的に企業での採用がはじまったOpenStackではあるが、まだ情報は多くない。少しでも当連載が皆さまの参考となれば幸いである。

真壁 徹（まかべ　とおる）

米Hewlett-Packard Company クラウドチーフテクノロジスト

　HPのクラウドの方向性、最先端の開発状況を日本のお客さまにお伝えし、かつ日本のお客さまの声を米国HP本社にフィードバックする役割を担う。アーキテクトとして設計支援も担当。

　公共分野のソフトウェアエンジニア、通信業界担当のプリセールスエンジニアを経て現職。趣味はビール。

伊藤雅典（いとう　まさのり）

日本ヒューレット・パッカード株式会社 ソリューション・アーキテクト

日系ベンダー、SIerを経て現職。アジアパシフィックリージョンの導入、構築案件などを担当。趣味は子育て。