成城大学がバックアップ製品を「Avamar」「VDP」から「Rubrik」に変えた理由：3つの条件で製品を選定

学内システムのバックアップに課題を抱えていた成城大学は、バックアップ製品に「Rubrik」を導入した。なぜRubrikを選んだのか。そのメリットと課題は。同校のシステム運用担当者に聞いた。

[大久保 心織，TechTargetジャパン]

成城大学《クリックで拡大》

　成城大学は、仮想マシン（VM）を使って運用する学内システムのバックアップに、バックアップ製品「Rubrik Cloud Data Management」（以下、Rubrik）を利用している。導入以前に抱えていた「バックアップ用VMがリソースを圧迫する」という課題を解消し、バックアップ運用の負荷を軽減できたという。製品選定ポイントや導入効果について、同大学でシステム運用を担当するメディアネットワークセンターの五十嵐 一浩氏に話を聞いた。

併せて読みたいお薦め記事

バックアップとDR対策の方法

• 「VMware vSphere」バックアップのための主要テクニックとNGリスト
• 1回で分かる：仮想マシンを丸ごとバックアップする「VADP」の仕組み
• 災害対策、迷ったらこれを選ぶ　～3つのDR方式を徹底解説

教育機関のインフラ運用

• 京都大学が基幹系をオンプレミスから「AWS」へ移行した理由
• 名門大学は13万人が利用する「VDI」をどのように構築したのか

仮想環境のリソースを圧迫するバックアップ

成城大学の五十嵐 一浩氏

　五十嵐氏らのシステム運用チームは、成城大学内で運用している学内サービス用の認証サーバ、DNS／DHCPサーバ、ネットワーク監視ソフトウェア、セキュリティアプライアンスなど管理系システムの設計、構築、運用管理をしている。これらのシステムが稼働するインフラは、サーバ仮想化ソフトウェア「VMware vSphere」で構築した仮想環境だ。その環境内で「Linux」ベースのVMを使い、各システムを運用している。これらVMのバックアップ運用業務において、同チームはバックアップアプライアンスの「Dell EMC Avamar」と、VMバックアップソフトウェア「VMware vSphere Data Protection」（VDP）を利用していた。これらを活用する中で、以下の課題に直面したという。

• バックアップ管理用のVM（イメージプロキシ）がリソースを圧迫する
  • バックアップデータの取得中にプロセスが停止し、処理が進まなくなった場合、作成途中のスナップショットにロックが掛かってしまう。その結果、作成に失敗したスナップショットが残り続け、“ごみ”データとしてストレージを圧迫する。加えて、そうした断片的なスナップショットは手動でデータを寄せ集め、1つの正常なスナップショットを作成しなければならないため、余計な作業が必要になる。
  • 所有者不明の状態で残ったスナップショットは集約や削除といった操作ができなくなり、VMあるいはホストサーバで稼働するハイパーバイザー「VMware ESXi」を再起動する必要が生じる。だがVMのホストサーバを再起動するには、そのサーバで運用しているシステムを利用する組織に承諾を得なければならず、必要な処理を即実行できない。
• Dell EMC Avamarの管理画面のユーザーインタフェース（UI）が煩雑で操作しづらい
  • 管理画面は操作する機能ごとに個別のウィンドウが開くため、複数のウィンドウを切り替えながら操作しなければならず、管理業務の負担が増える。
  • 複雑な操作ができるメンバーが限られ、作業が属人化する問題も生む。

バックアップ製品の3つの選定条件

　こうした問題を解消すべく、2016年から2017年にかけて、五十嵐氏らは代替となるバックアップ製品の選定を実施した。製品に求めた条件は以下の通りだ。

条件1．ハードウェアのアプライアンスであること

　バックアップ用のVMを作成して運用する方式では、先述のようにリソースの競合が発生する。従って、バックアップシステム単体で運用できるハードウェアのアプライアンスであることが条件となった。

条件2．エージェントレスであること