仮想化専門コンサルタントが教える 「成功する仮想化導入のポイント」

日本仮想化技術株式会社 代表取締役社長兼CEO

宮原 徹 miyahara@VirtualTech.jp

日本仮想化技術株式会社 概要

•  社名：日本仮想化技術株式会社 –  英語名：VirtualTech Japan Inc. –  略称：日本仮想化技術／VTJ

•  設立：2006年12月 •  資本金：20,000,000円 •  本社：東京都渋谷区渋谷1-8-1 •  取締役：宮原 徹（代表取締役社長兼CEO） •  伊藤 宏通（取締役CTO） •  スタッフ：9名（うち、6名が仮想化技術専門エンジニアです） •  URL：http://VirtualTech.jp/ •  仮想化技術に関する研究および開発

–  仮想化技術に関する各種調査 –  仮想化技術に関連したソフトウェアの開発 –  仮想化技術を導入したシステムの構築

ベンダーニュートラルな独立系仮想化技術の エキスパート集団

2

会社沿革

•  2001年1月 株式会社びぎねっと 設立 –  代表取締役社長に宮原 徹が就任 –  Linux/OSS技術者教育を中心に事業を展開

•  2006年1月 （株）びぎねっと 年間新規事業開発テーマを「仮想化技術」に設定 –  日本で初めてXen上でWindowsの動作に成功

•  2006年12月 新規事業会社として「日本仮想化技術株式会社」を設立 –  （株）びぎねっとの兄弟会社として設立 –  代表取締役社長に宮原 徹、CTOに伊藤 宏通が就任

•  2008年8月 第三者増資を行い、資本金を1425万に増資 •  2012年5月 第三者増資を行い、資本金を2000万に増資 •  2012年5月 オフィスを渋谷区渋谷1-8-1 第3西青山ビルに移転

3

代表略歴

•  本名：宮原 徹 •  1972年1月 神奈川県生まれ •  1994年3月 中央大学法学部法律学科卒業 •  1994年4月 日本オラクル株式会社入社

–  PCサーバ向けRDBMS製品マーケティングに従事 –  Linux版Oracle8の日本市場向け出荷に貢献

•  2000年3月 株式会社デジタルデザイン 東京支社長および株式会社アクアリウムコンピューター 代表取締役社長に就任 –  2000年6月 （株）デジタルデザイン、ナスダック・ジャパン上場

（4764） •  2001年1月 株式会社びぎねっと 設立 •  2006年12月 日本仮想化技術株式会社 設立 •  2008年10月 IPA「日本OSS貢献者賞」受賞 •  2009年10月 日中韓OSSアワード 「特別貢献賞」受賞

4

導入・移行

仮想化環境構築をトータルサポート

設計

•  戦略立案 –  コスト削減、社内標準化、将来プランのコンサルティング

•  設計 –  要求仕様の策定 –  サーバ、ストレージからネットワークまでアプリケ

ーションまで考慮した設計 適化 –  キャパシティプランニング（ベンチマーク）

•  導入 –  仮想化ソリューションパッケージの提供 –  仮想化統合（P2V既存環境移行）

•  運用保守 –  エンジニア教育

–  技術サポートの提供 –  OSSソースコードレベルサポート

運用保守

ベンダーニュートラルなワンストップ・サポートをご提供 5

戦略立案

本日のアジェンダ

•  仮想化技術の現状 •  仮想化環境設計の基礎

– 仮想化環境のパフォーマンス – ストレージ

•  仮想化環境の運用管理 •  クラウドの活用

6

仮想化技術の現状

7

サーバー仮想化は普及段階に

•  ハードウェアの仮想化 適化 –  マルチコアCPU・大容量メモリ搭載

•  大規模なシステムほど仮想化に移行済み –  中小規模システムの仮想化移行フェーズに –  クラウドサービス利用も促進

•  仮想化の導入よりも運用管理に悩み –  性能不足・容量不足 –  障害対応・BCP対応

•  一層のランニングコスト削減要請 –  省電力サーバーへの変更による電力コスト削減 –  高集約環境へのV2V移行による仮想インフラ再圧縮

8

ハイパーバイザーの 新動向

•  VMware vSphere 5でのライセンスの変更 – 仮想マシンに割り当てたメモリ容量による課

金体系に変更 •  不評だったためvSphere 5.1から取りやめ

– ホスト数が多いとコストがネックに •  Hyper-V 2012の登場

– Windows Server 2012に搭載 – 機能面でvSphereを追従 – Windows多用の場合、コスト面でメリット

9

ストレージの課題と注目技術

一層の大容量化 仮想ストレージ 重複排除

バックアップ／リカバリ D2Dバックアップ バックアップ統合

性能要求の高速化・多様化

SSD/SSSの採用 SANの高速化 分散ストレージ

BCP対策 遠隔複製機能 クラウドストレージ

10

ネットワークの課題と注目技術

通信量の増加 10Gイーサネット InfiniBand

仮想ネットワークの一元管理

分散仮想スイッチ OpenFlow ファブリック

BCP対策 高速WAN

モバイル 高速ワイアレス通信

11

仮想化環境設計の基礎

12

仮想化環境設計の基本方針

•  複数サーバで負荷分散と冗長化を図る – 無停止運用、HA（高可用性）構成を実現 – サーバ単体性能は追求しない

•  ネットワークは役割別にセグメントを分割 •  ストレージは容量、速度、耐障害性、コス

トのバランスを – バックアップ／リカバリも考慮して

13

構成例

14

仮想マシンホスト 仮想マシンホスト

ストレージ

ストレージ用

管理用

ライブマイグレーション用

管理端末

クライアントネットワーク ネットワークは 少なくとも4系統は考える必要がある

無停止や耐障害性設計

•  冗長化・HA構成による耐障害性の向上 – 基本的な設計はこのレベル – 物理サーバーは3台1組構成を基本に

•  ライブマイグレーションで無停止システム – ハードウェアのシャットダウンを伴うメンテナ

ンスもシステムを無停止で実施可能 •  ストレージの冗長化も

– データのバックアップをしっかりと行う

15

障害に強いシステムの実現

•  Server Aに障害は発生した場合

1. Server Aに障害発生 2. VM1をServer Bで

再起動（システムは共有ストレージ上に）

3. Server A復旧後、 VM1をServer Aに復帰

16

VM1 VM2

Server A Server B

VM1 VM2

Server A Server B

VM1

Server A Server B

VM2

ライブ マイグレーション

1.

2.

3.

数分程度で フェールオーバー

無停止運用の実現

•  Server Aをハードウェア的に停止してメンテナンスしたい場合

1. VM1をServer Bにライブマイグレーション（システムは無停止）

2. Server Aを停止し、メンテナンス

3. VM1をServer Aに復帰

17

VM1 VM2

Server A Server B

ライブ マイグレーション

VM1 VM2

Server A Server B

VM1

Server A Server B

停止メンテナンス

VM2

ライブ マイグレーション

1.

2.

3.

仮想化環境のサイジング

仮想サーバ環境全体のリソース量を算定 – 既存環境から仮想化環境への移行見積もり

•  各リソースの使用状況を調査・予測 – CPU・メモリ・ストレージ・ネットワーク

•  リソース使用率評価前にシステム性能が不足していないか主観的に判断 – 主観的判断：システムが遅くないかどうか – 遅いと感じられる場合はボトルネック調査

18

基本的な高速化の手法

•  仮想マシンを増やして負荷を分散 –  Webアプリケーションサーバー、メールサーバ

ーなどに有効 •  マルチプロセス／スレッド処理はCPU追加で

– 負荷の高いプロセスが並列化できる場合に有効 •  メモリ追加でアプリのチューニング

–  DBなどメモリ上での処理が多いアプリに有効 •  ストレージ高速化でiowaitを減らす

–  メモリを増やしてバッファキャッシュを増やすのも有効

19

CPUのサイジング

•  仮想化のCPUオーバーヘッドは10%程度 •  旧世代CPUから新世代CPUへの移行に

より性能アップ •  両者が打ち消し合うため、新旧のクロッ

ク性能は同じと考える •  CPU使用率が計測できる場合は平均使

用率、あるいは 大使用率で必要クロック数を算出

20

CPUの仮想化

21

OS OS OS OS

OS OS OS OS

仮想CPU割当を減らす 物理CPU数を増やす

VM1がCPUリソースを専有 VM切替でVM2がCPUリソース確保

or

VM1 VM2 VM1 VM2

CPU利用状況の 適化

•  仮想CPUの割当数だけ物理CPUをロック – ロックされている間、他の仮想マシンは物理CP

Uを使用できない – 物理CPU割り当ては時分割で強制的なので、仮

想CPUがIdleでもロックは発生する •  ロックを回避し、スループットを向上

– 仮想CPU割当数を減らす – 物理CPU数を増やす（2コア→4コア→6コア→8コ

ア→12コア→16コア）

22

性能不足時のCPU使用率評価

•  使用率が長時間100%（高原型） – 詳細分析の上、高速化の手法を検討 – CPU増設、負荷分散など

•  使用率が特定の時間だけ高い（スパイク型） – CPU増設、負荷分散などで対処 – 処理時間帯をずらして時差処理

•  使用率が乱高下（ノコギリ型） – CPU以外のボトルネックを調査

23

メモリのサイジング

•  実際のメモリ使用／空き容量の調査 – 空き容量が不足し、スワップイン／アウトが

大量に発生していないかどうかを確認 – 適度なスワップアウトは問題なし

•  メモリオーバーコミット機能を考慮しない – HAクラスタによるフェールオーバーのため

に仮想ホストのメモリは空きが必要 – メモリオーバーコミット機能はメモリ不足時

に仮想マシン自体をスワップアウトする機能なので実際には必要とならない

24

ストレージのサイジング

•  必要となる容量と性能からストレージの接続方法およびHDD台数などを割り出す

•  必要となる容量は現在の必要容量＋1年後の増加量で算出 – 不足した場合の対応方法も同時に検討

•  必要となる性能はIOPS中心に – 現在使用しているHDDの台数から簡易算出 – データベース、メールサーバーを中心に – SSDやキャッシュ技術の活用も考える

25

ネットワークのサイジング

•  必要となるネットワーク帯域を試算 – ネットワーク流量の多い特定のサービスは

スイッチ、NIC等で実際に計測 •  ストレージ接続がiSCSI、NFSの場合、ス

トレージ用ネットワーク帯域はストレージ側のポート数・帯域に合わせて検討 –  iSCSI接続はマルチパス接続方式を考慮

26

10GbE・FCoE・CNA

•  10G Ethernet標準搭載サーバーの増加 •  今後、iSCSIやFCoEのHBAを兼ねたCN

A搭載製品が標準に – CNA：Converged Network Adaptor

27 Brocade社製品 QLogic社製品

仮想化環境における ストレージの重要性

28

ストレージ選定

容量

耐障害性 速度

29

ストレージ選定時の考慮点

•  容量 –  今後の増加率の予測も合わせて行う –  無停止増設可能か

•  速度 –  使用アプリケーションの読み書き特性を考慮 –  SSD／NANDフラッシュ、階層化ストレージ、キャッシュ

技術の活用 •  耐障害性

–  単一障害点の排除 –  バックアップリカバリも含めて検討

•  ローカルストレージの活用 –  共有の必要がなければ、ローカルの方が高速の場合も –  システムとデータの分離

30

ストレージで考慮すべき機能

•  バックアップリカバリー – スナップショットとのバックアップ連動 – リモートバックアップとDR

•  ストレージ統合 – 複数ストレージの論理集約 – 統合管理 – 冗長性排除 – 階層化

31

構成設計 まとめ

•  元々のサーバーの利用率や性能が低ければ、性能設計は緩めでも良い

•  集約率と耐障害性は反比例するので、バランスを考えて

•  ボトルネックはI/O、特にストレージ – HDD台数追加やSSDの利用を考慮 – 今後は10GbEによるネットワーク構成も

32

仮想化環境における運用管理

33

仮想化運用管理の基本

•  可能な限り既存の運用管理手法を踏襲 – 仮想化だからといって特別なことは無い – 仮想化することでマシン層とOS層の間に

標準化の線引きが行える – 仮想化レイヤーの監視が増える

34

←サービス監視 ←OS監視 ←仮想化監視 ←ハードウェア監視

仮想化環境における性能監視

•  死活監視だけでなく性能監視も重要 – ボトルネックの早期発見・早期対応

•  リソース利用量の60%ルールの徹底 – リソース総容量に対する水準線を決めておく – リソース利用量が水準線を越えたらリソー

ス追加を検討 •  リソースの逐次強化

– リソース量を順次増やしていくビジネスプロセス（稟議書→決済）への変革が必要

35

仮想マシン管理の注意点

•  仮想マシンの構成変更が容易 – メモリ量などすぐに変えられてしまう – リソース使用量の急激な変動に繋がる

•  仮想マシンの追加が容易 – リソース使用量の急激な増加に繋がる – 当初想定していた以上のリソース不足

36

構成・変更管理とリソース容量調整が重要

仮想化以外の管理

•  システムやミドルウェアの構成管理 – 仮想マシン毎の分離度が高いため、個別の

コントロールは行いやすい – 仮想マシンの数が多いと、構成・変更管理

が煩雑になる •  ストレージの管理

– スナップショットは便利だが、ストレージ性能が低下するので注意

37

クラウドの有効活用

38

メリットのあるクラウド利用

•  短期の利用 –  「持たない」ことによるメリット

•  迅速な配備 – セルフサービスポータル

•  大量のリソース要求 – ネットワークトラフィックに注意

•  物理的な分散 – BCPの一手段として

39

クラウドサービスの落とし穴

•  従量課金 – 特にネットワークトラフィック課金が大きくなる

•  決済方法 –  「固定課金」では取られすぎの可能性も

•  設計 – 性能が読めない – ネットワーク設計の制約

•  運用管理 – すべてをアウトソースできるわけではない

40

発展的ハイブリッド活用

•  システム発展に合わせてリソース量調整 •  フロー部分はクラウドサービスを利用 •  リソース要求が一定量まとまった時に

プライベートクラウド化 •  可能な限り両者間の移動が

柔軟に行えることが重要

41 時間経過

ー

量

プライベートクラウド成功のポイント

まとめとして

42

何のためのプライベートクラウドか

•  コスト削減を目指した仮想化環境構築 •  サービスレベルの向上 •  レガシーマイグレーション •  システムインフラの標準化 •  情報システム部門の省力化

43

ITアーキテクチャの再構築

プライベートクラウド設計

•  機能要件 – 標準機能とオプション機能の必要性を検討

•  非機能要件 – 構築段階と運用段階のサイジングが重要

•  将来要件 – 標準化 – ○aaS提供 – セルフサービスポータル – ハイブリッドクラウド

44

標準機能とオプション機能

•  標準機能 –  HA（フェールオーバークラスタ） – ライブマイグレーション

•  オプション機能 – 性能 適化

•  性能不足に陥ることは少ない？ – 仮想分散スイッチ

•  仮想ホスト増加時の現実的な課題 –  DR対応

•  回線速度やBCP全体との整合性が必要

45

サイジングのポイント

厳密な分析の前に概算ベースでのサイジングを •  CPU

–  現在の使用クロック数×使用率＋α •  概算として使用率30%〜50%程度で計算 •  ＋αも仮に3割増し程度？

•  メモリ –  現在の使用メモリ量の合算＋α –  N+1台でHA用のキャパシティを確保

•  N台=必要メモリ総容量÷1台あたりの搭載メモリ量

•  ストレージ –  現在の使用データ量の合算＋α

46

運用方針の策定

•  VMあたりの標準リソース量の決定 –  H/Wスペックの個別 適化から標準ベースのシス

テム展開への移行 – サイジング情報から平均値、再頻出値を導出

•  リソース増強ポリシーの決定 –  リソース使用率のしきい値

•  例）ストレージ使用率80%でストレージ増設検討

•  運用監視の統合 – 監視サーバー、ログサーバーなどの導入

•  バックアップの統合 47

お問い合わせ先

「仮想化環境を構築したいが、どこに相談すればいいの？」

まずは我々にご相談ください

http://VirtualTech.jp/ sales@VirtualTech.jp

050-7571-0584 48