こんにちは、SRE部ZOZO SREチームの中道です。
私が所属するZOZO SREチームは、普段ZOZOTOWNのインフラをメインに、サーバ・ネットワーク・仮想基盤・クラウド・バックアップなどの構築運用を担当しています。
DRやBCP対策の中でバックアップ/リカバリの体制や構築に悩むことは多いと思います。今後DRを検討していくにあたり、バックアップ/リカバリ方式改善のために導入したCohesityについて紹介したいと思います。
環境や状況によってバックアップ/リカバリに関する課題は様々ですが、チーム内で主にあがっていた課題は以下の3点です。
既存フローの課題点
- それまで利用していたバックアップ/リストアの方式がベンダー考案・構築されているものが多い
- OS、DB、Webなどの対象ごとにバックアップ/リストア方式（手順書）が異なる
- 手順書が長く複雑で、手数が多く、リストア実績が少ない
以前まではツールの選定やフローの導入をベンダーに任せていた事が多かったため、ベンダー依存から脱却し、まずは自分たちでしっかり対応できる環境を整備する必要がありました。
複数のOS、物理サーバ、仮想サーバ、DBなどの対象ごとにバックアップ/リストアの方式が異なり、別々で手順が用意されているため、手順書が多く複雑でスムーズに対応できませんでした。チーム全員が同じレベルでの理解・把握が難しく、手順書を見てすぐ対応できるとは言い難い体制であったと思います。
定期的に復旧訓練を実施していますが、本番と同等の環境での訓練は難しかったりもします。また、実際に障害が起きたとき、迷いなくスムーズにリカバリを行えるのか？ 自信をもってできるといえるのか？ そこには不安な部分もあり、大きな課題であったと思います。
また既存バックアップ製品ではバックアップとリカバリに時間がかかり、SLA要件を満たせないなどの問題がでてくることもあると思います。
そうしたことから、インテリジェンスなリカバリを行える環境・体制を整える必要となり、バックアップソリューションのリプレイスを進めることになりました。比較検討した結果、運用している環境にマッチしていること・設定の容易性・単一インタフェースで対応できることによる統合効果などから、 Cohesityの導入を進めました。
Cohesityの機能について簡単に説明していきたいと思います。
Cohesityについて
- ハイパーコンバージド型の統合セカンダリ・ストレージがコンセプト
- データ保護のサイロをなくし、単一の管理UIでポリシーベースの保護が可能
- 制限がなく、透過的なスケールアウトやオンラインでのアップグレードと拡張が可能
- グローバル重複排除と圧縮による効率化の実現
- データ保護だけでなく、ファイル、オブジェクト、分析、テスト/開発などさまざまな活用が可能
- 広範なアプリケーションとインフラストラクチャのサポート
Cohesityの基盤となるのが、ストレージ基本管理ソフトウェアのCohesity DataPlatformとバックアップ管理ソフトウェアのCohesity DataProtectです。
Cohesity DataPlatform
Cohesity DataPlatformは、Webスケールのアーキテクチャーを基本として、独自の分散ファイルシステムであるSpanFSに基づくスケールアウトソリューションです。複数のセカンダリワークロードを単一のプラットフォームに統合することで、セカンダリデータとセカンダリアプリケーションの管理をモダナイズおよびシンプル化します。
Cohesity DataProtect
Cohesity DataProtectは、コア、クラウド、エッジまでの広範囲をカバーし、最新のアプリケーション主導型インフラストラクチャを実現する、高パフォーマンス且つソフトウェアデファインドのデータ保護ソリューションです。仮想または物理的なDB、NAS、クラウド環境といったさまざまな場所のワークロードをポリシーベースですべて管理し、包括的に保護します。サイロ化した従来のバックアップをなくし、バックアップとリカバリを操作しやすい単一のユーザーインタフェースによって管理することで、データ保護を根本的に簡素化します。
Cohesityの導入によって目指した改善点は主に以下の3点です。
Cohesity導入で目指す改善点
- 作業手順の簡素化・単純化
- バックアップリストア方式の統一化
- 運用の省力化
具合的にCohesityの機能・操作について、説明しながらみていきたいと思います。
ダッシュボード
VM、物理サーバ、NASなどのバックアップはすべてデフォルトのDashboardから情報が確認できます。MS SQLだけが独立のDashboardとなり、下記のようにより詳細な情報の確認が可能です。
バックアップ
バックアップ取得までの流れを説明します。必要な操作は下記のステップになります。
- 対象ソースの登録
- ポリシーの作成
- バックアップジョブの作成・実行
- バックアップジョブの実行確認
1. 対象ソースの登録
物理マシンにはCohesity Agentをインストールします。Cohesity AgentはDashboardからダウンロードできます。仮想マシンでは、例えばVMであればvCenterを登録することで、仮想マシンのバックアップの取得が可能になります。
2. ポリシーの作成
ポリシーの作成で実行頻度、保持期間、バックアップ形式等を設定します。ひとつのポリシーを複数のバックアップジョブで利用できます。デフォルトで3つのポリシーが用意されており、そのまま利用することもできますし、デフォルトポリシーを元に編集し利用することも可能です。
3. バックアップジョブの作成・実行
バックアップジョブの作成でソースの選択、オブジェクトの追加、ポリシーの選択、実行時間等を設定します。永久増分バックアップなので、2回目以降のバックアップの所要時間が短縮されます。VM、DBも同じステップで設定可能です。
4. バックアップジョブの実行確認
Protection Jobs画面から実行のステータスを確認できます。
リカバリ
次にリカバリ方法について説明します。必要な操作は下記のステップになります。
- リカバリジョブの実行
- リカバリジョブの実行確認
1. リカバリジョブの実行
ここでは仮想マシンのリカバリの手順を記載します。リカバリ画面でVMsを選択し、対象マシン、任意のデータを選択します。リカバリ対象の仮想マシンがすでに削除されている場合は、Rename Recovered VMsのチェックを外すことで同一の仮想マシンとしてリカバリできます。Networking OptionsでDetach networkにチェックを入れることで、ネットワークから切り離された状態でリカバリできます。
Point-in-timeのリカバリ
SQLサーバでは、データベースのバックアップおよびT-logのバックアップを組み合わせて、Point-in-time（いつの状態でもリカバリ可能）のリカバリが対応可能です。Point-in-timeリカバリの画面は下記のようになります。カレンダーベースとなり非常にわかりやすい画面です。
2. リカバリジョブの実行確認
Recovery画面から実行のステータスを確認できます。
クローン
さらにクローン機能について触れたいと思います。Test & Devという機能で、バックアップデータをテスト利用することが可能です。
| 対象 | 動作 |
|---|---|
| VM | 指定スナップショットをNFS共有して、vCenter & ESXi上にデータストアとしてマウント、VM起動します。 |
| SQL | 指定スナップショットを、SMB共有してWindowsサーバ側でマウントし、SQLサーバはSMB共有上のデータ・ログファイルを使って、データベースを定義します。 |
必要な操作は下記のステップになります。
- クローンの作成
- クローンの実行確認
- クローンの削除（ティアダウン）
1. クローンの作成
ここでは仮想マシンのクローンの手順を記載します。Test & Dev画面でVMsを選択し、対象マシン、任意のデータを選択します。詳細設定を行いクローンを生成します。
2. クローンの実行確認
Test & Dev画面から実行のステータスの確認ができます。
3. クローンの削除（ティアダウン）
Test & Dev画面からTear Downを実行します。
動作のまとめ
SQL
バックアップ
- SQLサーバのバックアップ機能ではなく、OSレベルのVSSを利用してバックアップを行う。 ※今後VDI APIを利用しての動作に変更予定。
- ログはVDIを利用してバックアップ。 ※VDIは無停止が可能。
- WindowsにインストールしたCohesity Agentに、Cohesityから指示を送って実施する。
- WindowsがデータをCohesityに送信。
- Cohesity Agentが、SQLサーバの情報を読み取りVSSを含め適切に動作。
リカバリ
- Cohesity本体上の指定スナップショットをSMB共有して、Windowsサーバ側でマウント。
- SMB共有上のデータ・ログファイルを使ったCohesity Agentが、SQLのリストアコマンドを発行。
- 必要なログのマージなどもここで実施。
- リストアコマンドに基づいてデータベースがアクセス可能な状態になる。
クローン
- Cohesity本体上の指定スナップショットをSMB共有して、Windowsサーバ側でマウント。
- SQLサーバはSMB共有上のデータ・ログファイルを使って、データベースを定義。
- 上記の動作を約10秒程度で準備し、データベースとしてアクセス可能（Read/Write共にOK）な状態にできる。
- 最終的にTear Downボタンにて廃棄する動作（廃棄までがクローンの一連の流れ）
VM
バックアップ
- vCenterと高度な連携を行い、最新の管理情報を元にした動作を行う。
- vCenterを経由したAPI情報を元に、vCenterライクなUIによって対象を決定。
- バックアップ操作を行うと、ESXi上でスナップショットの取得を実施。
- Cohesityのボリュームを、NFSでESXi上にマウント。
- 上記スナップショットを、CohesityのNFSデータストアにESXiが書き込み。
- バックアップ終了後、ESXi上のスナップショットを削除。NFSのアンマウント。
リカバリ
- Cohesity本体上の指定データストアとしてスナップショットをNFS共有して、vCenter & ESXi上にマウント。
- 上記のファイルを利用してVMのインベントリ登録＆起動（PowerOnを選んだ場合）※インスタント・マス・リカバリ機能。
- 裏ではストレージvMotionを利用して、指定ターゲットにファイルを配備。
- ストレージvMotionの途中でVMは利用可能になる（PowerOnを選んだ場合）
- すべてが終わったらNFS共有がアンマウントされる。インベントリ情報も実際のターゲットのデータストアに切り替わる。
クローン
- Cohesity本体上の指定スナップショットをNFS共有して、vCenter & ESXi上にデータストアとしてマウント。
- 上記のファイルを利用してVMを起動（PowerOnを選んだ場合）
- 上記の動作を約20秒程度で準備し、その後OSが起動すれば利用できる（検証環境では、ログインプロンプトまで3-5分程度かかった）
- Read/WriteいずれもOK。バックアップには影響なし。
- 最終的にTear Down Cloneボタンにて廃棄する動作（廃棄までがクローンの一連の流れ）
※上記の数値は弊社での検証時の値になります。
上述した通り、VM、SQLのバックアップ・リカバリ・クローンの操作感はほぼ変わらないことがわかるかと思います。現代的なUIのもと、非常にテンポよく操作が可能です。VMとSQLが同じコンソールで対応できることによる、統合効果も大きいと思います。
導入による効果
既存のバックアップソリューションでは手順書で10ページ以上はあった各手順が、直感的に操作可能なUIによって作業手順の簡素化、単純化を可能にしました。さらに複数あったバックアップ/リストア方式の統一化を可能にしました。
今後既存バックアップを集約することで運用の省力化をさらにはかってきたいと考えています。
ZOZOテクノロジーズでは、一緒にサービスを作り上げてくれる仲間を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください！
