Rubrikについて vol.3
前回に引き続き、Rubrikについて、いろいろと書いていきます。
↓vol.2はこちら↓
今回のテーマは、Rubrikの細かい仕様です。
いくつかのテーマに分類してつらつらと書いていきます。
今後のメジャーアップグレードで機能変更はあると思うので、注意点としては前回の記事同様です。
注意
本記事はRubrikのCDMバージョンは9.0の前提で書いています
バックアップ関連
ここではRubrikの主要機能であるバックアップ周りの細かい仕様を列挙していきます。
1.Rubrik自身のバックアップについて
これは、現時点では機能として提供されていません。よくあるConfigのバックアップですね。
以前Rubrikのイベントでエンジニアの方から「機能要望として多く上がってきているので、今後のアップグレードで対応していくと思います」と聞きました。
今後に期待です。
2.保持期間変更時の挙動
例えば保持期間30日間でSLAドメインを設定しているとします。
SLAドメインを編集し、保持期間を10日間に変更した場合の挙動は、デフォルトでは画像のような動きとなります。
つまり、設定変更後に取得したバックアップは変更後の保持期間が適用されるが、設定変更前に取得されたバックアップは設定変更前の保持期間で保管されます。
オプション設定で、SLAドメインの編集の際に、「既存のスナップショットへ変更を適用する」という選択項目があります。つまり、既存のバックアップデータの保持期間を短くする(or長くする)ことも可能です。
3.暗号化した仮想マシンのバックアップについて
vSphere環境の仮想マシンを暗号化し、そのバックアップおよびリストアに関しては、特に影響なく実施が可能です。
↓仮想マシンの暗号化についてはこちら↓
バックアップを取得する際に復号化を行い、Rubrikのストレージにデータが保管されるため、リストアする際は暗号化されていない状態でリストアされます。
なので、再度暗号化が必要な場合は、手動で仮想マシンを暗号化する必要があります。
※基本的にRubrikにvCenterを登録する際、管理者権限を持ったユーザで登録していれば、復号化は行えます。vCenterのユーザーを手動で作成し権限を絞っている場合は、必要な権限が付与されていないと復号化を自動で行えないため、注意が必要です。
4.帯域制御について
現在のバージョンでは、バックアップの取得の際にRubrikの機能として、帯域制御はできません。
(今後機能として追加されればとてもうれしい...)
ただ、レプリケーションに限っては、帯域制御が可能となっています。
5.オンデマンドスナップショット(手動バックアップ)の保持期間について
Rubrikでは、バックアップ対象をSLAドメインに割り当て、いい感じで時間や負荷を分散して自動でバックアップを取ってくれる、というのが基本になります。
ただ時と場合によっては、手動でバックアップを取得したい場合があります。その際はオンデマンドスナップショットを使用します。
オンデマンドスナップショットの実行時、何日間保管するポリシーを決めるために、SLAドメインを選択する必要がありますが、オプションとして、保持期間を永久とするオプションがあります。
注意点としては、手動でこのスナップショットを削除しない限りはRubrikのストレージに残り続けるので、忘れないようにちゃんと管理する必要があります。
6.バックアップ同時実行数の上限について
vSphere環境のバックアップに限った話にはなりますが、
バックアップ同時実行数の上限は下表の通りとなります。
| 項目 | 同時実行数(上限) | 上限数の引き下げ |
|---|---|---|
| ESXiホスト1台あたり | 3VM | 可能 |
| Rubrik 1ノードあたり | 4VM | 可能 |
| オンデマンドスナップショット | 上限なし | 不可 |
ここで、Rubrik1ノードあたりと記載されているので、1Brikに4ノード搭載している筐体であれば、16VMが上限となります。
また、オンデマンドスナップショットには注意が必要なので、表の中に記載しました。
オンデマンドスナップショットは優先度の高いジョブとして処理されるため、上2項目の制限には引っかかりません。
vSphere側でのスナップショット同時実行も、ESXiのリソース負荷が上がってしまうため、基本的には実施しないことが推奨です。
それと同じくRubrikのオンデマンドスナップショットの同時実行も、基本的には1台ずつ実施した方がよいと思います。
7.バックアップデータの手動削除について
RSC上からバックアップデータ(スナップショット)を手動で削除しても、ストレージの使用率が変わらないといった挙動が、実際の構築案件内で起きました。
Rubrikサポートに確認したところ、インテリジェントデータロック(IDL)といわれる機能があり、手動でバックアップの削除などアヤシイ挙動でデータが削除された際、7日間はRubrikの内部でデータを持ち続ける仕様があると、回答をもらいました。
7日後にしっかりストレージ使用率は減っていたので、頭の片隅に入れておいてもらえるとよいのかなと思います。
8.バックアップ実行結果について
Rubrikでは、vSphere環境の仮想マシンをバックアップする際、特別な要件がない限りはAgentlessでバックアップが可能です。
ですが、RubrikのAgent(RBS)を仮想マシンにインストールしていない場合、バックアップ完了時のステータスが「警告ありの成功」となってしまいます。
ジョブの詳細警告メッセージ
これについては回避策もないので、そういう仕様と思ってください。
なお、仮想マシンが停止している場合やRBSをインストールしている場合は、「成功」と表示されます。
その他
ここでは、Rubrik周りの設計時に「これ設計時にしってたらなぁ～」と思った仕様や、バックアップ以外の細かい仕様について列挙していきます。
1.ストレージ使用率監視について
デフォルトでストレージの使用率監視がされており、使用率が設定してある値を超えると、アラートが発報されます。サポートに問い合わせて初めて知った設定値だったので、共有です。
デフォルトでは以下のような設定値になっています。
85%で警告、90%でアラート発報、80％に下がるまでアラートを発報し続ける
またこれらの閾値はユーザ側で変更ができないため、RubrikのPS(初期セットアップサービス)時や、Rubrikサポートに問い合わせて設定をしてもらう必要があります。
パラメータも下記に記載しておきますので、ご活用ください！
X%で警告、Y%でアラート発報、Z％に下がるまでアラートを発報し続ける
・systemStorageNotificationThreshold: X
・systemStorageNotificationResendThreshold: Y
・systemStorageThresholdNotificationReset: Z
2.インターネット接続に関して
以前の記事でも記載したと思いますが、現在RubrikでサポートされているCDMバージョンでは、インターネット接続が必須となっています。
※基本的に物理筐体であるRubrik CDMクラスターでの管理ではなく、クラウドのRSCでの管理が主流となっているため。
なので、設計時点で意識しておく必要があります。
2.「リテンションロック機能」と「クォーラム認証機能」について
これらはCDMバージョン9.0以降でしかサポートされていないため、8.0や8.1以前を使用している場合は使用できません。
設計時にバージョンを確認し、機能設計をする必要があります。
3.「リテンションロック機能」と「クォーラム認証機能」について
CDMクラスターやRSCのログインはMFAの有効化が必須になっています。
ハードウェアMFAやアプリケーション(Google Authenticatorなど)の使用ができるので、ここも設計が必要な箇所かなと思いました。
4.ジャンボフレームについて
Rubrikでバックアップ取得の際などに、ジャンボフレームは使用できない仕様となってます。
また、MTUも1500から変更不可。
5.メール通知について
RSC経由でメール通知がされるため、既存のメールサーバと連携することなく、各種アラートのメール通知が可能となってます。
6.Syslog、SNMPについて
Syslogについては、RSCからテストメッセージの送信が可能です。
疎通確認や受信確認をする際は、この機能を使うのが良いと思います。
SNMPについては、CLIから下記コマンドで疎通確認ができます。
cluster snmp test_trap_receivers
7.NTPについて
Rubrikでは、Bootstrap(初期設定)時に参照先のNTPを準備しておく必要があります。
デフォルトでは、time.google.comが指定されています。
また、Rubrikの仕様として、指定したNTPサーバを参照するのは2ノードのみで、ほかのノードはこの代表する2ノードを参照して時刻同期を行います。
※3Brik=12ノードの際も、2ノードのみがNTPサーバと通信します。
また、どのノードが代表して時刻同期しに行くかはランダムっぽいです。
さいごに
vol.1~3である程度かきたいことはかけたかなと思います。
Rubrikについて知らない方もこれを読めばOK！とまではいきませんが、なんとなくのイメージはできるんじゃないかと思います。
vol.4では、実際の構築手順的なものを書いていきたい(予定)ので、興味あるかたは見てやってください！
それではまたどこかで。