EMC Data Domain　導入事例　日本情報通信株式会社　様

Size: px

Start display at page:

Download "EMC Data Domain　導入事例　日本情報通信株式会社　様"

せせらめいこ
6 years ago
Views:

運用サービスでも数々の実績を持つ有力ベンダーの1 社であるその同社がクラウドサービスに参入したのは 2008 年 2009 年には企業向けクラウドコンピューティングサービスを開始 IA 系サーバーに続き Power Systems を基盤とする Power Cloud i を開始している Power Cloud i は

1 先進ユーザー事例❻日本情報通信株式会社重複排除などの機能により高パフォーマンスを確認ノウハウも獲得 POINT COMPANY PROFILE 横浜と大阪のデータセンターを利用し Data Domainのバックアップ / レプリケーションを検証高いデータ圧縮率や重複排除機能などにより高いパフォーマンスを実証テープバックアップを超えるメリットとパフォーマンスを高く評価し全面導入 IT 通信デリバリ本部インテグレーションサーバーテクノロジーセンター担当課長 2009 年に IBM i 向けクラウドサービスを開始 1985 年に日本 IBM と日本電信電話 (NTT) の合弁によって設立された日本情報通信はシステム開発から基盤構築運用ネットワークサービスまでトータルに ICT ソリューションを提供してきた IBM i の SI / 運用サービスでも数々の実績を持つ有力ベンダーの1 社であるその同社がクラウドサービスに参入したのは 2008 年 2009 年には企業向けクラウドコンピューティングサービスを開始 IA 系サーバーに続き Power Systems を基盤とする Power Cloud i を開始している Power Cloud i は初めはユーザーシステムのクラウド化を支援するプライベートクラウドとしてスタートしたしかし 2010 年に提供するリソースをメニュー化してパブリッククラウドを追加し 2011 年にはインフォアジャパンの ERP 製品 Infor LX を自動車業界向けに提供する Power Cloud ERP をラインナップに加え拡張を図ってきたまたクラウドに対するユーザーの多様なニーズに対応するため各種サービスの拡充にも努めてきた現在提供されているサービスは図表 1の通りだがこのうち B C P 対応監視サービスネットワークサービスは 2012 年以降のサービスであるさらに Power Cloud i とオンプレミスシステムあるいは Power Cloud iと EDI Power Cloud iと他のクラウドサービスとの連携機能も 2012 年以降に提供が始まっているユーザーの問い合わせで Data Domain の検証を開始今回のレポートはこれらのサービスのうちバックアップに関する同社の取り組みである同社は現在 IBM i データのバックアップとリモートサイトへのレプリケーションを EMC ジャパンの Data Domain で行う取り組みを進めている Data Domain は IBM i とファイバーチャネルで接続され圧縮や重複排除などの機能によって高速にバックアップ / レプリケーションできるディスク to ディスクのストレージ装置である Data Domain に着目したきっかけはあるユーザーからの日本情報通信が Data Domain でリモートバックアップサービスをやるのなら利用するが予定はあるかという問い合わせだったそのお客様は首都圏のデータセンターへハウジングしている IBM i

2 のデータを大阪へバックアップしたいご要望を持っておられましたと日本情報通信の佐藤壮介氏 ( デリバリ本部 i ソリューション部インテグレーションサーバーテクノロジーセンター担当課長 ) は振り返る 2010 年秋のことであるそこで EMC ジャパンに問い合わせ Data Domain の導入支援や検証サポートを受けるなら EMC 代理店のノックスが一番と紹介され同社の協力を得て検証に入った以下は佐藤氏が試みた検証結果の一部である図表 1 Power Cloud i で利用できるサービス黄色の項目は2012 年以降にスタートしたサービス提供サービス項目 Power Systems 利用 Power Platformリソースデリバリーサービステープライブラリ利用サービスデスク Q&A 対応サービスj 障害対応技術支援サービス OSバージョンリリースアップ PTF 適用サービス月次定例会 9 種類のテストでバックアップ状況を検証検証環境は Power 740(4 コア 3.7GHz) と Data Domain 690 を 2 本のファイバーチャネル (FC) で接続し 1つのFCポートに2つのライブラリを割り当て ( 計 4 つのライブラリ ) それぞれのライブラリに各 10 個の仮想テープライブラリ (VTL) を設定した Data Domain 690 は Xeon 2.66GHz メモリ 16GB ディスク 5.76GB(SATA) のスペックである検証では Power 740 上の 2 区画 (HOST2 と A 区画 ) のデータを対象とした ( 図表 2) テストケース 1 では A 区画の全データをバックアップした 10GB のデータサイズで 26 分 20 秒という処理時間である転送レートは秒 6.5MB( 図表 3) テストケース 2 はテストケース 1 でバックアップした 10GB のデータを別の FC ポートにつながる仮想テープライブラリへ複製した結果である所要時間は1 分 23 秒 ( 図表 4) テストケース 3 はテストケース 1 のバックアップデータを今度は同じ FC ポート内の仮想テープライブラリへ複製した結果であるこちらは別ポートのライブラリへの複製よりも速く 1 分 13 秒で終了した ( 図表 5) テストケース 4 は HOST2 区画のシステムヘルスチェックサービス環境移行サービス BCP 対応サービス運用サービス監視サービスネットワークサービスをバックアップした結果であるは HOST2 区画の物理ディスクを他の 4 つの LPAR 区画が仮想 SCSI 経由で各ずつ利用する設定とした災害時の復元を想定した場合区画ごとに OS やデータを復元するよりも区画全体のディスクイメージを復元したほうが速いので物理ディスクを制御する HOST 区画上で仮想ディスクをエラーログチェックパフォーマンスモニターレポートサービスハードウェアの買い取り機器の移設移行計画移行支援ミラーライト利用ミラーソフト利用リモートバックアップテープ交換業務オペレーション Ping 監視メッセージ監視ジョブ監視クラウドコネクトサービス端末認証サービス丸ごとバックアップしたらどうなるか検証しましたと佐藤氏は狙いを説明する結果は 43 分 50 秒転送レートは秒 163.5MBだった ( 図表 6) テストケース 5 はテストケース 4 のをまとめてバックアップするのではなくずつ平行に処理し ( 多重度 4) 4 つのライブラリに書き込んだ時の結果であるこの方法では転送レートが約 1.5 倍高速となり ( 秒 55

3 先進ユーザー事例❻日本情報通信株式会社図表 2 検証環境 IBM i ファイバーチャネル (FC) Data Domain CPU CPU Intel Xeon 2.66GHz Memory 2 ポート 4Gbps メモリ 16GB(667 MHz) Disk 区画間でスイッチディスク SATA 5.76GBx16 RAID6 HOST1 HOST2 A 区画 FC + + ケーブル a b Data Domain 690 ( 4 スロット ) + ES20 (16 スロット拡張スロット ) + VTL オプション FC ポートの割り当て a=2 つのライブラリ b=2 つのライブラリ Power740(4 コア 3.7GHz) 図表 3 ( テストケース 1)A 区画の全データをバックアップ 10GB 10:55:00 11:21:20 0:26:20 1, 図表 4 ( テストケース 2) テストケース 1 のバックアップデータを別の FC ポートにつながるライブラリへ複製 10GB 11:55:43 11:57:06 0:01: 図表 5 ( テストケース 3) テストケース 2 の複製データを同じ FC ポートのライブラリへ複製 10GB 11:58:02 11:59:15 0:01: 図表 6 ( テストケース 4)HOST2 区画で他の LPAR 区画の仮想ディスクデータをバックアップ 12:25:28 13:09:18 0:43:50 2, MB) 29 分 49 秒で終了した約 30% の時間短縮である ( 図表 7) テストケース 6 は多重度を 4から 2 に下げのデータを同一の FC ポートにつながるライブラリへバックアップした結果である処理時間は 31 分 35 秒で多重度 4の場合とあまり変わらない結果となった ( 図表 8) 調べてみると Data Domain のディスク稼働率が 90% となっていて同じ FC ポートのライブラリに書き込むのは効率が悪いことが分かりました ( 佐藤氏 ) テストケース 7 は多重度 2のまま異なる FC ポートの 2 つのライブラリへバックアップした結果であるこのテストケースでは重複排除も設定した結果は 20 分 26 秒に短縮され ( 転送レートは秒 350.8MB) ディスクの稼働率は 10% 台に落ちた ( 図表 9) テストケース 8 はテストケース 5 の多重度 4 の条件で重複排除をかけた場合の結果である処理時間は 15 分

4 秒と約半分に短縮され大きく効果が見られたディスクの稼働率も 20% 台で収まったが CPU の稼働率が 50 % 台となり重複排除をかけ異なる FC ポートへ振り分けると CPU を食うことが分かったと佐藤氏は言う転送レートは秒 455.1MB で今回の一連の検証の中では最速であった ( 図表 10) テストケース 9 はテストケース 1 の多重度 1のまま重複排除をかけ 1つのライブラリへバックアップした時の結果である処理時間は 35 分 57 秒で転送レートは秒 199.4MB だった ( 図表 11) 以上は日本情報通信の横浜にあるデータセンター内 ( 同一サイト ) で行った検証である佐藤氏はさまざまな検証結果からバックアップする際にどこに注意したらいいかポイントがつかめた Data Domain をより有効活用するにはある程度の経験とノウハウが必要と総括する図表 7 ( テストケース 5) テストケース 4 を多重度 4 で 4 つのライブラリへバックアップ 14:12:00 14:12:02 14:12:03 14:12:04 14:12:00 14:38:24 14:41:45 14:41:48 14:41:49 14:41:49 0:26:24 0:29:43 0:29:45 0:29:45 0:29:49 1,584 1,783 1,785 1,785 1, 図表 8 ( テストケース 6) テストケース 4 を多重度 2 で同じ FC ポートの 2 つのライブラリへバックアップ 15:09:56 15:09:59 15:09:56 15:41:31 15:41:33 15:41:31 0:31:35 0:31:34 0:31:35 1,895 1,783 1, ディスク稼働率は90% 台になった図表 9 ( テストケース 7) テストケース 4 を多重度 2 で異なる FC ポートの 2 つのライブラリへバックアップ 16:18:00 16:38:24 0:20:24 1, データ圧縮効果とレプリケーションのテスト結果 16:18:02 16:18:00 16:38:26 16:38:26 0:20:24 0:20:26 1,224 1, 次に Data Domain が持つデータ圧縮機能と重複排除機能による圧縮効果を検証した図表 12 は3 日連続で計測した結果で初日の 478.1GB は圧縮後に 79.1GB となり ( 圧縮率 83.3%) 2 日目の 496.9GB は重複排除が働いて 23.7GB に圧縮され ( 圧縮率 95.2%) 3 日目はさらに重複排除が効いて 512.1GB が 22.5GB となった ( 圧縮率 95.6%) 佐藤氏はここまで圧縮できるのなら日次のデータが 400GB 以上あってもリモートサイトへのレプリケーションは十分に現実的と指摘するそこで横浜と大阪のデータセンター間でレプリケーションを行った検証結果が図表 13であるこの結果を見るとバックアップを取りながらバックアップされたデータが併行してレプリケーションされていることが分かる早朝の重複排除が働きディスク稼働率は 10% 台に落ちた図表 10 ( テストケース 8) テストケース 5 の多重度 4 のバックアップで重複排除をかけた場合データサイズ開始時間終了時間経過時間秒速度 (MB/s) 16:44:26 16:44:31 16:44:35 16:44:39 16:44:26 16:59:56 17:00:05 17:00:10 17:00:11 17:00:11 0:15:30 0:15:34 0:15:35 0:15:32 0:15: CPU 使用率 50% 台ディスク稼働率 20% 台になった図表 11 ( テストケース 9) テストケース 1 で重複排除をかけてバックアップした場合データサイズ開始時間終了時間経過時間秒速度 (MB/s) 17:16:51 1:48 0:35:57 2, CPU 稼働率 20% 弱ディスク稼働率 20% 弱 DD 側に余裕がある場合多重度 1 でこの速度が限界 57

5 先進ユーザー事例❻日本情報通信株式会社22.8 (95.6) 51GB のデータ ( ジョブ 1) でバックまたこれまでテープバックアップの運するしかもテープバックアップでは得アップ開始からレプリケーション終了ま用サービスを利用してきたユーザーのうられない数々のメリットがあると次ので9 分夕刻のGBで3 分 ( ジョブち 6 社が Data Domain によるバックように語る 2) 夜間バッチの 324GB になるとバッアップへ切り替えそのうち数社が大テープバックアップの場合テープのクアップ終了と同時にレプリケーション阪のデータセンターへのレプリケーショ装填ミスやメディアの障害バーコードも終了している ( ジョブ 3) ンを採用しているという今後この流が読めないなど問題が生じる可能性がれは加速すると佐藤氏は言うありさらに復元に時間がかかるといっ佐藤氏は Data Domain の IBM i ユーた難点があります Data Domain ならテープバックアップからザーにとっての長所として仮想テーバックアップを自動化でき高速の復元切り替えるユーザーも続くプライブラリとまったく同じ操作性も可能でしかもテープバックアップよ日本情報通信ではこの検証結果をを挙げる SAVLIB コマンドを使いなりもコストを抑えられるというメリット踏まえて Data Domain の導入を決定がら実際はストレージへ書き込まれがあります当社では今後物理テー 2012 年に 4 台のエントリーモデルを導圧縮や重複排除機能が働いて高速にプから Data Domain によるバックアッ入しさらに 4 台を 2013 年に購入バックアップやレプリケーションが可能プへ切り替えていく方針です現在新たに 4 台の追加を検討中であるです非常に扱いやすい製品と評価図表 12 Data Domain の圧縮効果の検証圧縮前 (GB) 圧縮後 (GB) 重複排除による圧縮効果 LZ1による圧縮効果トータルの圧縮効果 ( 圧縮率 %) 1 日目 2 日目 3 日目過去 24 時間のデータ過去 24 時間のデータ過去 24 時間のデータ (83.3) 21.0 (95.2) 図表 13 横浜から大阪へのデータセンター間のレプリケーション検証結果ジョブ名書き込み量 (GB) 実行日開始時刻バックアップ終了時刻レプリケーション所要時間開始時刻終了時刻バックアップ終了からレプリケーション終了までの所要時間月 2 日 7:37 7:43 0: 月 2 日 19:17 19:24 19:17 19:27 0: :15 4 7:38 7: :14 19:21 19:14 0: :14 1:16 2:14 7 7:40 7: 0: :42 19:52 0:09 19:42 20:02 0: :07 2:05 1:12 2: : 3:59 1:12 2: 4:02 0: :38 7:44 0:05 7: :30 19:32 0: 月 6 日 1:16 *GB 未満は省略した

Microsoft Word - nvsi_050110jp_netvault_vtl_on_dothill_sannetII.doc

Microsoft Word - nvsi_050110jp_netvault_vtl_on_dothill_sannetII.doc Article ID: NVSI-050110JP Created: 2005/10/19 Revised: - NetVault 仮想テープライブラリのパフォーマンス検証 : dothill SANnetⅡSATA 編 1. 検証の目的ドットヒルシステムズ株式会社の SANnetll SATA は安価な SATA ドライブを使用した大容量ストレージでディスクへのバックアップを行う際の対象デバイスとして最適と言えます

EMC Data Domain 導入事例 日本情報通信株式会社 様

EMC Data Domain　導入事例　日本情報通信株式会社　様