3つの条件で製品を選定

成城大学がバックアップ製品を「Avamar」「VDP」から「Rubrik」に変えた理由

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

公開 2019年12月16日 05時04分

更新 2022年10月05日 10時08分

著者

大久保心織

[TechTargetジャパン]

印刷する

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

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

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

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

教育機関のインフラ運用

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

成城大学の五十嵐一浩氏

　五十嵐氏らのシステム運用チームは、成城大学内で運用している学内サービス用の認証サーバ、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．エージェントレスであること

　サーバの再起動中やアプリケーションのインストール中など、各部門が利用するサーバを運用担当者が勝手に操作できないことがある。その場合でも、専用のアプリケーション（エージェント）をVMにインストールしなくてもバックアップを作成、管理できる「エージェントレス型」製品である必要があった。

条件3．管理画面が分かりやすいUIを備えること

　運用チームの特定のメンバーにスキルが依存しないよう、誰でも簡単に操作できる製品であることが望ましい。そのため管理画面のUIが分かりやすいかどうかを重視して選定した。

　移行先の製品を探していた五十嵐氏は、2016年にVMwareが米国で開催したイベント「VMworld 2016 US」に参加し、そこで展示されていたRubrikに興味を持ち、詳細を調べるに至ったという。「今では他にも要件を満たす製品が出てきているが、当時はRubrikだけがわれわれの要求に合致していた」と同氏は述べる。

バックアップポリシー策定による自動化も実現

　五十嵐氏らは2018年6月からRubrikのアプライアンス版のうち「r334」2台を利用し、仮想環境のバックアップを運用している。1台を大学に、もう1台を成城大学が沖縄に構えるDR（災害復旧）センターに設置し、作成したバックアップをレプリケーションするという構造だ。「ほとんど検証期間がないままの導入だったが、すぐに利用できた」と同氏は振り返る。

　Rubrikはエージェントレス型であるため（注）、管理対象のVMと同一のサーバにエージェントやバックアップ用VMを配置する必要がない。それらを配置する必要がある場合と比べ、リソースへの負荷軽減が期待できる。管理画面は単一のWebアプリケーションとして提供されており、五十嵐氏は「直感的なUIで処理に必要な操作を実行しやすくなっただけでなく、ファイル単位で検索やリストアが可能になったことも評価できる」と説明する。

※注：仮想アプライアンス版Rubrikをクラウドに導入する場合はエージェントが必要。

　簡略化できた点は他にもある。Rubrikはスナップショットの作成頻度や保存期間などを定めた、バックアップのSLA（サービスレベル契約）に基づいたポリシー（ルール）を策定できる。フォルダやVMといった新たなバックアップ対象を作成する際、このポリシーを適用することで、自動で設定に沿ったバックアップを取得できるようになる。それまでは新しくバックアップ対象を作成するたびに、バッチ稼働のルールを記述しなければならず、手間になっていた。

高速ネットワークの利用で広がる可能性

　Rubrikを用いたバックアップは、2019年12月時点までで特に障害なく運用できており、運用面での課題は「特にない」（五十嵐氏）という。「実際にはどこかのノードで障害が発生していることもあるようだが、3台のノードが自動で負荷を分散しているため、システム全体としての不具合はない」（同氏）

　五十嵐氏は、Rubrikの活用を広げる上で改善を望む点として「ディスクの読み書き速度向上」「より高速なネットワークインタフェースの搭載」を挙げる。バックアップ処理にかかる時間の短縮はもとより、沖縄のDRセンターで利用している大学・研究機関向けネットワーク「SINET」が高速化した際の有効利用を視野に入れているためだ。

　現在DRセンターで利用するSINETの通信速度は10Gbpsであり、運用中のr334も10ギガビットイーサネット（GbE）の通信インタフェースを備えている。「DRセンターでより高速なネットワークを利用できるようになれば、全てのバックアップデータをDRセンターで管理するとしても十分な通信容量を確保できるだろう」と五十嵐氏は展望を述べる。

　作成したバックアップファイルの活用も検討している。例えばVM以外にもバックアップ対象を広げた上で、Rubrikが提供するバックアップファイル分析ツール「Polaris GPS」を使うことを構想中だという。「所有者ごとにファイルの所在や更新日時などの情報を自動取得することにより、大学全体で『誰が、何を、どこに保管しているか』を管理できるようになるとよい」（五十嵐氏）。成城大学の取り組みは、仮想環境のバックアップデータ管理からその有効利用までの一連を検討する教育機関や企業の参考となるだろう。

印刷する