2011年11月17日

ネットアップ株式会社 技術本部 技術コンサルティング部 コンサルティング システムエンジニア 神原 豊彦 様

企業クラウド環境の オーケストレーションにおける データ管理

本社：米国 カリフォルニア州 サニーベール

– データ・ストレージ製品の提供、革新的な技術開発

– 従業員：11,000以上 / 150以上の世界拠点

– 5年連続 20%成長 (CAGR)

ネットアップ株式会社

2

$4B

$3B

$2B

$1B

$5B

FY11 : $5.1B

04 05 06 07 08 09 10 11

20%+

CAGR

3

Source: Gartner, Inc. Nov 2010

Roger W. Cox、Jimmie Chang、Pushan Rinnen、Stanley Zaffos

Magic Quadrant for Midrange and High-End

Modular Disk Arrays

This Magic Quadrant was published as part of a

larger research note and should be evaluated in

the context of the entire report. The report is

available upon request from NetApp.

The Magic Quadrant is copyrighted Nov 15, 2010 by Gartner, Inc. and is

reused with permission. The Magic Quadrant is a graphical representation

of a marketplace

at and for a specific time period. It depicts Gartner's analysis of how

certain vendors measure against criteria for that marketplace, as defined

by Gartner. Gartner does not endorse any vendor, product or service

depicted in the Magic Quadrant, and does not advise technology users

to select only those vendors placed in the "Leaders" quadrant. The Magic

Quadrant is intended solely as a research tool, and is not meant to be a

specific guide

to action. Gartner disclaims all warranties, express

or implied, with respect to this research, including

any warranties of merchantability or fitness for

a particular purpose.

市場からの評価 ： ストレージ技術のリーダー

Gartner社 Magic Quadrant 2010/11 ミッドレンジ・ハイエンド・モジュラー型ディスクアレイ・ベンダ

クラウド時代のお客様 ： 新しいアプローチを模索

4

固有アーキテクチャや固定観念を変革し、次世代のシステム基盤を模索

サービスプロバイダを利用？ 今までにないコスト効率と即応性を実現

プライベートクラウドを構築？ 同程度のコストでビジネスのニーズに応える

外部サービス

プライベート IT

固有のアーキテクチャ

クラウド時代のお客様 ： 重要となる転換手法

5

同一の目的地への異なる旅路

サービスレベルを向上させる 柔軟で効率的な 共有ITインフラ

ストレージ

サーバ

アプリケーション

ネットワーク

外部サービス

プライベート IT

手法を問わずに、企業データの効率的な管理を実現

転換に向けて (1/2) ： 推進要因

6 Do not Distribute this page.

転換に向けて (2/2) ： 抑止要因

7 Do not Distribute this page.

1. オーケストレーションとは？

2. 企業クラウドにおけるデータ管理手法 ストレージ・サービス・カタログ

3. オーケストレーションとの連携 データ管理の自動化

8

9

1. オーケストレーションとは？

ストレージ

サーバー

アプリ

ネットワーク

ITインフラの進化 ： 仮想からクラウドへ

10

業務システム サイロ

従来型の アプローチ

集中化 標準化 自動化

プライベート・クラウド

セルフ・サービス化

パブリック・クラウド

ハイブリッド

シェアード・ITインフラ クラウド型のアプローチ

仮想化 統合化

複数の仮想環境 ゾーン

途上期間

オーケストレーション

オーケストレーションとは？ (1/3)

11

ハイパーバイザー

サーバ管理者

ネットワーク管理者

ストレージ管理者

利用希望者

200GBの RDBMSを 2つ欲しい

RDMS管理者

1. ネットワーク設定の実施 • 利用セグメントの確定 • IPアドレスの割り当て • ファイアーウォール設定

2. ストレージ設定の実施 • 本番領域の確保 • バックアップ領域の確保・設定 • サーバへの割当設定

3. サーバ設定の実施 • 物理サーバの設定 • 仮想マシンの作成 • OSのインストール

4. RDBMSの導入設定

VLAN

RDBMS

仮想化技術の進化により 作業が迅速化・定型化

オーケストレーションとは？ (2/3)

12

ハイパーバイザー

サーバ管理者

ネットワーク管理者

ストレージ管理者

RDMS管理者

VLAN

RDBMS

情報システム責任者

VLAN

RDBMS

VLAN

RDBMS

・・・

性能・容量 管理

認証・ID 管理

構成・変更 管理

•新規リクエスト •設定変更リクエスト •解除・削除リクエスト

サービスレベル管理・課金 情報システムロードマップ

自動化のスコープは、展開作業だけでは無い 日々のIT業務を含めた自動化＝オーケストレーションが重要

ユー

ザID

管理

・ア

クセ

ス制

御

IT サービス・カタログ

セルフサービス・ポータル

オーケストレーションとは？ (3/3)

× 処理の自動化を支援する

○ サービスの運用管理を支援

13

統合

サー

ビス

管理

基盤認証・ワークフロー

課金管理

ライフサイクル管理

構成・変更管理

性能・容量/リソース管理

ストレージ

ネットワーク

CPU / メモリ

仮想化

外部

クラ

ウド連

携 /

クラ

ウド・コ

ネク

ター

■ 基本的な機能 – 定型処理の自動制御 – 構成の把握 – リソース状況・状態の把握

■ 応用的な機能 – 認証・リクエストワークフロー – 課金

■ 拡張的な機能 – ユーザ・ポータル – カタログ管理 – 外部クラウド連携

ストレージ ≒ データ格納サービスの提供

インターナル・クラウド実現に向けた4つの基本要素

14

サービス・カタログ

• ポリシーを適切に定義し、サービス・レベルとストレージの属性を自動的に対応付ける • 定義されたポリシーの組み合わせにより、サービス・カタログを構成する

サービス分析

• 監視・計測・ショーバック/チャージバック機能の一元化によりサービスを最適化 • サービス提供にかかるコストと、サービスレベルの可視化を高め、管理を強化

自動化

• 初期展開時のプロビジョニングのみならず、データ保護、日々の運用プロセスまでを範囲 • 統合・自動化することで、サービスの迅速な展開とニーズの変化に合わせた柔軟性を確保

セルフサービス

• 担当者を経由せず、利用者からのサービス要求にセルフ・サービス・ポータルから応える • 企業IT部門のスタッフと、エンドユーザの権限を強化し、生産性の高いITを提供する

15

企業クラウドにおける データ管理手法 ストレージ・サービス・カタログ

2つのアプローチ : サービスの提供

16

サービス・メニューからの選択

Gold Silver Bronze

•容量 500GB～ •性能 <20ms •4時間以内復旧 •2サイト保管 •災害時自動切換

•容量 500GB～ •性能 <40ms •当日復旧 •2サイト保管 •災害時データ復旧

•容量 1TB～ •性能 BestEffort •3日復旧 •単一サイト保管 •外部テープ保管

・改竄防止 ・VM連携 ・DB連携 ・ウイルス対策

200GBのRDBMSを 2つ欲しい

システムA 開発担当者

システムB 開発担当者

システムC 開発担当者

システムA 開発担当者

システムB 開発担当者

1. 200GB 2. 3年保管 3. Gold Level

1. 200GB 2. 2年保管 3. Bronze

+WORM

1. 200GB 2. 5年保管 3. Silver

システムC 開発担当者

200GBのRDBMSを 2つ欲しい

リソース・プール化されたIT基盤

1. 200GB 2. 30MBps 3. 3年保管 4. 前日B/R 5. DB連携 6. FCP

1. 200GB 2. 問わない 3. 2年保管 4. 10分前B/R 5. ウイルス対策 6. CIFS

1. 200GB 2. 100MBps 3. 5年保管 4. 自動切換 5. 改竄防止 6. NFS

従来型のアプローチ サービス型のアプローチ

効率化は難しい

個別最適化 / 詳細要件へ対応 / 異なる設計 / 異なる運用

サービス・カタログとは？

17

200GBの RDBMSを 2つ欲しい

項目 レベル 詳細

RDBMS Silver • データベース x1 • 作成ユーザ x2 • メモリ 4GB….etc

OS Gold • Windows 2008 SE • 管理権限付与 • 月次パッチ適用

サーバ Silver • 仮想環境 • 2cpu / 6GB mem • GbEther x2

ネットワーク Bronze • 冗長化 • ファイウォール設定

ストレージ Gold

• 性能 : 600iops • 容量 : GB単位 • 期間 : 6か月単位 • 保護 : 災害対策

RDBMS Service Menu

ITサービスの提供

「サービス・カタログ」

各要素の組み合わせ

各レイヤー毎の 管理ポリシー 利用ポリシー 課金ポリシー

管理ポリシーの策定

ポリシー管理化 と ストレージ・サービス・カタログ

18

ストレージ ≠データ格納装置 ≒データ保管・保護サービスの提供

No. 項目 内容 数的単位

1 容量 必要とされる容量 GB, TB

2 性能 必要とされる性能 IOPS, MBps, ms（レイテンシ）

3 保管期間 ライフサイクル 時間、週、月、年

4 保護 データ保護レベル

a 論理障害対策 ダーティ・データ（誤ったデータ）への対策 （必要性の有無、保護単位）

b 物理障害対策 システム障害への対策 （必要性の有無、保護単位）

c RTO 復旧許容時間 秒、分、時間、日

d RPO 必要となる復旧時点 トランザクション単位、時間単位

e 距離 保管場所に対する地理的要件、外部保管の有無

5 機能 ウイルス対策、改竄制限などの機能要件

6 通信方法 ホストとの通信プロトコル NFS/CIFS/iSCSI/FCP/FCoE

Bronze

Silver

必要となるストレージ・サービス・カタログの整理

19

提供費用

サービスレベル

Gold

A 基幹ERPシステム

B 在庫管理システム C

D

カスタマー・サポート

H

開発環境

E

メール・情報共有システム

G カタログ・帳票管理

J

K 部門CADシステム

性能：xxxx iops 容量：500GB～ 期間：3か月単位 費用：￥xxxx～ データ保護：週次取得/3日復旧

性能：xxxx iops 容量：300GB～ 期間：6か月単位 費用：￥xxxx～ データ保護：1時間取得/3時間復旧 事業継続対策：有り

社内プロジェクト 情報共有システム

I

F

ストレージ・サービスとポリシー、システムのマッピング

20

SLA

ストレージ 利用者

サービス・カタログ

サービスレベル

Gold

Silver

Bronze

ストレージ属性

セキュリティ

効率性

保護

可用性

vFiler

重複排除 シン・プロビジョニング

BU&R

HAペア

サービス・レベルを、構成ポリシー、システム属性設定に マッピングするフレームワークが必要

サービス・カタログの属性に基づき 最適化されたリソース・プールとして

ストレージを管理

ストレージ 担当者

物理装置

企業クラウドへの変革を阻害する階層化アプローチ

21

仮想化レイヤー

AP AP

AP

DB DB

Web Web Web

Web Web

Sys Sys

Sys

SAN

Bin Log

Log Cont

NAS

DB

SAN

×階層化の継続 仮想化前

Sys

Web

Log Cont

Sys

AP

Bin Log

Sys

DB

DB

NAS SAN Local

仮想化レイヤー

AP AP

AP

DB DB

Web Web Web

Web Web

Sys Sys

Sys

SAN

Bin Log

Log Cont

NAS

DB

SAN

◎ポリシー管理化

データ種別を論理的な 格納ポリシーとして実装

データ種別毎に物理的な 装置を使い分けて利用

企業クラウドへの変革を阻害する階層化アプローチ

– ポイント

データの重要性に応じた「物理装置」の選択

※ 経済性や調達の容易性

– デメリット

高コスト化：常に同様の環境を準備する必要性

求められるサービス・レベルに対して、異なる実装内容

日々の運用業務の定型化が困難

※ 異なる「装置」間でのデータ同期には、特殊な機構が必須

※ 自動化を行うにあたり、複数の異なる実装が必要

– 現実解

利用する装置の機能に依存した、サービス定義

最小公倍数的な業務の定型化アプローチ

インターナル・クラウド化への阻害ポイント

22

仮想化レイヤー

Sys Sys

Sys

SAN

Bin Log

Log Cont

NAS

DB

SAN

×階層化の継続

クラウド化!?

$

$

$ $

$ $

$ $ $

$ $ $

手法の煩雑化＝$$ 機材の調達＝$$ 運用委託＝$$ etc...

コンプライアンス アーカイブ

$

2次バックアップ （災害対策）

（サイト外保管）

$

1次バックアップ （サイト内保管）

$

企業クラウドへの変革を阻害する階層化アプローチ

論理障害対策 (Snapshot)

$ 本番データ

サービス担当者

開発・テスト・検証 データ複製

$

データ保護との関連性 不明瞭なコスト構造 困難なサービスの可視化

困難な整合性の維持 ポリシーの複雑化 管理の煩雑化

ストレージ管理者

23

企業クラウドの準備：企業データのポリシー管理化

– ポイント

データの重要性に応じた「管理ポリシー」の設定

※ ビジネス要件に合わせた重要度のマッピング

オーケストレーション連携 ＝ 管理ポリシーの展開

– メリット

「管理ポリシー」を定義することで、手法の選択肢が広がる

※ 手法の選択≒「サービス・レベル」の選択

※ 外部クラウド・サービスは、「サービス・レベル」を提供している

装置仕様に依存する「無駄な領域」を排除し、最適化可能

※ データ管理の効率化は、機材総量に直結する

スタッフの習熟≒ポリシー管理業務

– 得られる選択肢

レベルに応じた、適切なアーキテクチャ

管理ポリシー ＝ サービス連携

オーケストレーション ＝ 管理ポリシーの複製

24

仮想化レイヤー

Sys Sys

Sys

SAN

Bin Log

Log Cont

NAS

DB

SAN

◎ポリシー管理化

オーケストレーション連携 ＝ 管理ポリシーの複製

容量、性能、RTO/RPO、保管世代、 アーカイブ、暗号化、セキュリティ、

ウイルス対策、アクセス権限管理、etc.. 共通したデータ管理ポリシーを定義

コンプライアンス アーカイブ

2次バックアップ （災害対策） （サイト外保管）

1次バックアップ （サイト内保管）

企業クラウドの準備：企業データのポリシー管理化

$$

論理障害対策 (Snapshot)

本番データ

サービス担当者

開発・テスト・検証 データ複製

サービス型のアプローチ データ保護

ストレージ管理者

明瞭なコスト効果 サービスの可視化

実績ある提供形態 容易なポリシー管理 ニーズの変化に対して 迅速且つ柔軟に対応

25

NetApp OnCommand ソフトウェア （製品標準機能）

26

インターナル・クラウドの実現要素

共有インフラ

ストレージ効率化技術

展開を容易にするフレームワーク

サービス・レベル管理

データ保護機能の統合

セキュア・マルチ・テナント

データ・モビリティ

ストレージ・サービス・カタログ フレームワーク クラウドを支える、サービス・レベル単位での管理手法

拡張性・柔軟性に優れ、迅速に横展開可能な ストレージ・リソースを効率化するための手法

動的なサービス展開・管理を実現

NetApp OnCommand

NetApp OnCommand ：サービス・カタログの実現

27

プロビジョニング ポリシー

プロテクション ポリシー

ストレージ・サービス

A社データセット

B社データセット C社データセット

災害対策環境 本番環境 バックアップ環境 Bronze

Silver

Gold A

B C

D

H

E

G

J K

I

F

A社 財務システム

B社 財務システム

C社 財務システム

財務システム ストレージ・リソース・プール

インターナル・クラウド環境の実現に向けて

事前定義されたITカタログ・メニューを準備し、利用者が選択して利用

ストレージ ≒ データ格納サービス

サービスの構成要素となる、管理ポリシーを策定

物理装置を準備するのでは無く、論理的な構造体を定義する

全方位的な管理ポリシーの策定では無く、自社に必要な要素のみ実施

作成されたサービス・カタログとシステム設定の間を埋める NetApp OnCommand フレームワーク

28

サービス・カタログ

• ポリシーを適切に定義し、サービス・レベルとストレージの属性を自動的に対応付ける • 定義されたポリシーの組み合わせにより、サービス・カタログを構成する

29

オーケストレーションとの連携 データ管理の自動化

オーケストレーションにおける２つの実装手法 (1)

30

セルフ サービス ポータル

データセンター オーケストレーション

ストレ

ージ

アプ

リケ

ーシ

ョン

サー

バ

ネッ

トワ

ーク

仮想

化

ストレージ 担当者

ダイレクト・コントロール

セルフ サービス ポータル

データセンター オーケストレーション

ストレージ・サービス・カタログ

アプ

リケ

ーシ

ョン

サー

バ

ネッ

トワ

ーク

仮想

化

サービス

リソ

ース

プー

ル

ポリ

シー

メトリ

ック

ス

OnCommand

物理

制御

デー

タ保

護

監視

・管理

技術ビュー サービス・ビュー

サービス・カタログの利用

物理装置の制御

オーケストレーション連携手法 : ダイレクト・コントロール

31

200GBの RDBMSを 2つ欲しい

容量は？ 性能は？ 保管期間は？ バックアップは必要？ いつ停止できる？ プロトコルは？ ウイルス対策は？ ユーザ認証は？

etc…

詳細ヒアリング パラメータ・シート 自動化プログラム作成？

整合性 / 例外処理 RollBack

32

業務システム担当者 200GBのRDBMSが２つ必要

サービス・レベルはGOLD

オーケストレーション・フレームワーク

バック アップ

災害 対策

サービス カタログ

サービス 分析

サービス 監視

ストレージサービス展開 容量；200GB タイプ：GOLD 数量：２

サーバ・サービス展開 Silverのサーバ上に GoldのRDBMSテンプレートを作成

200GBのiSCSI-LUNを 重複排除・シンプロ 利用で2つ作成

ポリシー 管理

オーケストレーション連携手法 : サービス・カタログ (1)

自社開発

本番の展開と同時に バックアップ/災害対策 も同時に展開

オーケストレーション連携手法 : サービス・カタログ (2)

33

ストレージ・サービス・カタログ

オーケストレーション・フレームワーク

エンド・ユーザー・ポータル

アプ

リ サ

ービ

スカ

タロ

グ

CMDB

OS サ

ービ

スカ

タロ

グ

CMDB

サー

バ サ

ービ

スカ

タロ

グ

CMDB

NW

サー

ビス

カタ

ログ

CMDB

サービス化フレームワーク

サービス監視

サービス分析 CMDB

マルチテナント

構成・保護ポリシー

リソース・プール

サービス制御用 インタフェース

システム制御用 インタフェース

サービス管理 ブレームワーク

サービス作成ブレームワーク （サービス・システム間抽象化）

要素毎にサービスを作成し、カタログ管理を行う

連携手法による日々の開発・メンテ効率の差

34

パラメータ の入力

CMDB 既存設定との 整合性確認

確認処理

ネットワーク 準備処理

ネットワーク 処理ネスト

例外処理

ネットワーク 確認準備

確認処理

例外処理 本番領域 作成

Snapshot スケジュール

確認ループ

例外処理

ホスト接続 準備処理

・

・

try {

$new_dataset = $s.invoke(dataset_create, $xi);

} catch (exception e) {

・

・

サービス見直し、ポリシー変更、新サービス追加、構成アップデート、課金・・・・

OnCommand オープン・マネジメント・インタフェース

35

仮想 ハイパー バイザー

RDBMS アプリ

ケーション

SnapManager

SnapManager （上位レイヤー連携処理）

EMC IBM hp 日立

オーケストレーション・フレームワーク

監視・分析/ OnCommand Insight

NetApp DataONTAP

• Protection Manager • Provision Manager • Operations Manager • System Manager

NetApp OnCommand （ストレージ・サービス化） （自動化・監視・分析）

オープン・マネジメント・インタフェース （SDK、各種プラグイン、コネクター）

サービス連携 / サービス制御 • フレーム・ワークの提供 • 連携API/SDKの公開

個別制御 / モジュール化 • 各種Plugin, コネクタの提供 • モジュール作成ツールの公開

サービス単位のレポートが必須

インターナル・クラウドの管理概念 ： MAPE

従来のサイロ型の管理概念

– 予定された負荷に合わせた リソースの事前準備

緻密な負荷の算出（Plan）

算出結果に基づいた環境（Do）

負荷の閾値を監視（Check）

閾値を超えた際の対処（Action）

サービス型の管理概念

– 過去の利用傾向から 最適なリソースを維持

精密な状況把握（Monitor）

傾向分析と将来予測（Analysis）

予測に基づいた対応計画（Plan）

実施（Execute）

36

MONITOR

PLAN

ANALYSIS EXECUTE MAPE

Loop

PLAN

CHECK

DO ACTION PDCA

Cycle

37

業務システム担当者 サービス状況の把握

改善検討

オーケストレーション・フレームワーク

バック アップ

災害 対策

サービス カタログ

サービス 分析

サービス 監視

ポリシー 管理

オーケストレーション連携手法 : サービス・カタログ (3)

自社開発

自動化

• 初期展開時のプロビジョニングのみならず、データ保護、日々の運用プロセスまでを範囲 • 統合・自動化することで、サービスの迅速な展開とニーズの変化に合わせた柔軟性を確保

インターナル・クラウド環境の実現に向けて

×個別の処理タスクを自動化 ○サービスの展開を自動化

自動化における効率性 ＝ サービス・カタログの活用

初期展開処理のみでは無く、日々の運用プロセスまでを視野に入れる

リソースの最適効率を維持管理するためにも、サービスカットの自動化

PDCAでは無く、MAPEによる管理手法論の実施

自動化実装においても、効率化を支援する NetApp OnCommand フレームワーク

38

39

まとめ

インターナル・クラウド実現に向けて

専門知識を補うオーケストレーションと４つの要素 – サービス・カタログ – サービス分析 – 自動化 – セルフ・サービス

サービス・カタログ化から始める実現への道 – ポリシー管理と、サービス定義

自動化実装におけるサービス・カタログの重要性 – 実装工数の差 と MAPE型維持管理における必要性

重要となるフレームワーク ： NetApp OnCommand

40

NetApp OnCommand : オーケストレーションとの連携

41

ITサービス管理 クラウド環境管理

自社開発ツール 仮想環境管理

多様なオーケストレーション連携

Other as a Service

Infrastructure as a Service

Data Protection as a Service

Messaging & Collaboration as a Service

Desktop as a Service

SAP as a Service

世界中のクラウド・サービスを支えるNetApp

42

NetApp サービス・プロバイダー・プログラム

数百以上のサービスでの実稼働実績 50社以上の戦略的パートナーシップ

多様なクラウド・プラットフォームを支えるNetApp

製品の協業開発、導入経験だけでなく、プロジェクト協業、ビジネス提携までを実施

クラウドインテグレータ / VAR クラウド・サービス・プロバイダ

クラウドテクノロジ / 運用管理パートナー

パブリック/プライベート・クラウド分野における 世界規模のパートナーシップと協業実績

43

クラウド時代のお客様 ： 重要となる転換手法

44

外部サービス

プライベート IT

戦略的パートナーシップと、豊富な実績・経験によるご支援

45