Rubrikについてまとめてみた！vol.1

近況

FF7 Rebirthをストーリークリアし、現在トロフィーコンプリートを目指してハードモードを頑張ってます。
楽しすぎて困っています。(※困っていません)
次作はどうなってしまうんだろう...

Rubrikについて

Rubrikの細かい仕様や、構築する上での注意点などが公式のドキュメント以外に見当たらなかったので、いくつかの記事に分けてまとめていこうと思います。
今回のvol.1では、基本的なことについて書いていく予定です。
(あとは、細かい話と構築時の注意点とかを書きたい)

まずRubrikとは

バックアップやリストア、ランサムウェア対策やウィルス検知などの機能を提供するアプライアンス製品です。

1年に1回、Gartner社(IT分野を中心とした調査・助言を行っている企業)が様々なIT分野の製品の評価を行っています。その中でもGartner® Magic Quadrant(エンタープライズ・バックアップ/リカバリ・ソフトウェア・ソリューション部門)でLeaderとよばれる、その分野でも最も評価が高いグループに、Rubrikは属しています。

他のLeaderに選出されている企業は、Veeam、Commvalt、Veritas、Cohesity、Dellがいます。
(2024年2月にVeritasとCohesityは事業統合されました)

Rubrikの構成要素について

まず、①～③をすべてまとめて、Rubrik CDMと呼ばれます。
それぞれの説明については下に記載します。
また、Rubrik CDMそれぞれのコンポーネントは、RSC(Rubrik Security Cloud)と呼ばれるSaaSの管理コンソールにて一元管理されます。
RSCについては④で記載します。

①物理アプライアンス(Brik)

オンプレの仮想化基盤や物理サーバのバックアップを行うには、Rubrikの筐体が必須になります。

前面

背面

なお、Rubrikの筐体の数え方は1Brik、2Brikと数えるようです。
また、1筐体の中に4つのノードがあります。(1Brikの中に4つの物理サーバがあるイメージ)
ノードはそれぞれA~Dが割り当てられています。

②仮想アプライアンス(Edge)

遠隔地やRubrik筐体の置かれているロケーションと離れた環境のバックアップを取得する場合に、EdgeといわれるRubrikの仮想アプライアンスを立てます。
(基本的にRubrik CDMと連携が必要)
物理アプライアンス(Brik)と仮想アプライアンス(Edge)を接続し、バックアップデータをレプリケーションしたり、クラウド上のオブジェクトストレージにアーカイブしたりします。

③クラウド上のアプライアンス(Cloud Cluster ES)

AWS EC2やAzure VMでアプライアンスを展開し、クラウド上にあるOS内のファイルやDB、ファイルサーバなどのバックアップを取得する場合に、Cloud Cluster ESを立てます。
また、VMC(VMware Cloud on AWS)やAVS(Azure VMware Solution)上の仮想マシン保護も可能です。

基本的にデータはAWS S3やAzure Blobに保管されます。

④RSC(Rubrik Security Cloud)

以前はPolarisという名称だったみたいです。
企業ごとにURLが発行され、RSCに接続されたRubrik CDMの管理をWeb ブラウザから行えます。
↓URLはこんな感じです。
https://xxx.my.rubrik.com/

こんな感じのダッシュボードです。(SaaSなので画面は都度アップデートされます)

個人的に有用だな～と思う機能

メジャーアップデートがされるたびに、多くの機能が追加されますが、現時点(CDM ver. 9.0)での個人的なおすすめ機能を列挙します。本当はもっとありますが、別の記事とかで書けたらなと思います。

①SLAドメイン

他のバックアップ製品でいう、いつバックアップを実行するか、保持世代をどうするかを決定する"ジョブ"にあたります。
Rubrikを使う上で、運用的に一番楽になるんじゃないかな～と思います。
他の製品では、仮想マシンAのバックアップは業後の20:00～21:00に実行、仮想マシンBは21:00～22:00に実行といったように、ジョブの管理が結構な負荷になっているかと思います。
Rubrikでは、SLAドメインで実行時間帯(バックアップウィンドウ)と保持世代を決めて、仮想マシンにSLAドメインを割り当てるだけです。
Rubrik側で仮想マシンの負荷状況や同時実行数などをいい感じにやってくれるのが、とてもいいです。
※手動での即時バックアップ実行も可能

②インスタントリカバリ

これもRubrikを使う上での大きな利点かなと思います。
万が一、業務に使用する重要なサーバがトラブルで使用できなくなってしまった際、数分でサーバ復旧ができます。
仕組みとしては、Rubrikのストレージ上に仮想マシンを起動するため、素早いリストアを実現しています。
なお、インスタントリカバリのプロセスの中で、元の仮想マシンの停止なども自動で行います。
また、元の仮想化基盤上に仮想マシンを戻す場合には、Rubrik→仮想化基盤サーバにStorage vMotionをすることで素早い移行ができます。

③RSCでの一元管理

どのバックアップが失敗したかを確認するのに、さまざまな環境を持っている企業だと、AWSやオンプレの仮想化基盤、遠隔地の別環境などいろいろなコンソールに接続し、見に行く必要があります。
RSCで全ての環境を同じポリシーでバックアップの設定・管理を行えることは、運用面での大きな利点になるのではないかと思います。
バックアップの管理以外にも、もっといろいろできます。

さいごに

まだまだ書きたいことがいっぱいありますが、vol.1としてはこれくらいにしようと思います。
記事の内容について質問等があれば、わかる範囲でコメントに返信します！
(完全に個人の意見になるので、そこだけご承知ください)