【Ask the Expert】エキスパートに聞こう！VNX FILE Replicationに関する技術・構成・運用・トラブルの疑問点を解決

エキスパートからのコメント・・・・・

VNX FILE Replication は非同期型のデータ複製機能です。筐体内(ローカル・レプリケーション)や筐体間(リモート・レプリケーション)でデータ保護や災害対策ソリューションを実現します。

FILE OE(OS)に組込まれていますので、ライセンス購入で簡単に構築できるのが大きなメリットで、スナップショットと共に多くのお客様に使って頂いている、定番ソフトウェアオプションです。

今回のATEは、プリセールスからサポートまで幅広いチームメンバーを揃えました。

これから導入を検討している方の素朴な疑問、

例えば、「同期転送はできないの？」とか

現在利用中で使いの方の詳細な質問、

例えば、「XXXのためのオプション設定はないか？」など、

こんな質問でいいかなと気兼ねなく、気軽に投稿頂けると嬉しいです。

ではお待ちしています！

チームリーダー　Miho Naozumi

質問させてください。

2台のVNXにてRemote Replicationを利用しております。

かつ本番用として利用しているVNX側のUser MapperがSecondary、バックアップ用として利用しているUser MapperがPrimaryとなっております。

この度、バックアップ用のVNXのみを移転させることになりました。

(1)User MapperがPrimaryで動作しているバックアップ用VNXが停止している間は、本番用VNXもサービス停止になってしまうのでしょうか？それともsecmapがあるから本番用VNXはサービス停止にはならないのでしょうか？

(2)本番用VNXをサービス停止にさせないためには、バックアップ用VNXをどのような手順・注意事項をもって移転を進めるのが良いでしょうか？

(1)はご想像通りsecmapにいるユーザ/グループである限り本番用VNXはサービス停止にはならないです。

新規ユーザ/グループのアクセスがあった場合にそれをどうするか、が(2)にも関係する考慮事項となります。

ということで手順を単純に記述すると次のようになります。

1. 本番用VNXをPrimary Usermapperに変更する
2. バックアップ用VNX移転
3. 本番用VNXからUsermapper DBをExportする
4. バックアップ用VNXにUsermapper DBをImportする
5. 本番用VNXをSeconday Usermapperに戻す ←誤記修正しました(7/8 16:48)

移転前後のsecmapを比較して、新規ユーザ/グループが無ければ4を省略する、というのも可能です。

Usermapper DBの整合性を保つため、2以外の実行は本番用VNXをサービス停止することになります。

※新規ユーザ/グループとは今まで一度もアクセスしたことのないユーザ(及びその関連グループ)の意味です

Replicatorを使用している場合の、VNX FILE OE（NAS OS）のバージョンアップについて確認させて頂けますでしょうか？

現在の推奨手順ですと、Replicatorのセッションは停止せずに、FILE OEを

バージョンアップすることになっているか思いますが、停止することのメリット、

及びリスク（あれば）について、教えて頂けますでしょうか？

というのも、VNX以前のモデル（Celerra）では、NAS OSバージョンアップ時に、

Replicatorを一旦停止することが推奨手順となっていたかと思います。

この従来の手順を踏襲すると、VNXでもバージョンアップ時にReplicatorの

セッションを停止することが求められことがあるため、VNXのケースのメリット

や注意すべき事項について確認したいと考えております。

Toyodaです。

VNXシリーズに実装されているReplicator v2においては、

File OEアップグレード時にReplicatorセッションを停止する必要は有りません。

アップグレード手順において停止のステップを必要としていたのは

かつてのNAS5.6まで実装していたReplicator v1の制約で、

それ以降のReplicator v2においては停止ステップは排除されました。

これはチェックポイントを用いた差分ブロック転送のアーキテクチャが変わった事で、

アップグレード時のチェックポイントの挙動に手順上で配慮する必要が無くなったからです。

停止する事のメリットは特に無く、リスクとしては停止から再開時までに発生する差分が

SavVolの容量をどれだけ使用するか注意を払う必要がある、といった程度です。

VNX File環境におけるReplicatorとRecoverPointを利用した際の違いについて下記の視点から教えて頂けないでしょうか？

・各機能でできることの違い

・メリット、デメリット

・利用用途、ターゲット市場

・導入実績

・今後の方向性

etc...

ご回答ありがとうございます。

モデルやOSの違いではなく、ReplicatorのV1とV2のアーキテクチャの違いにより、

停止の有無が変わり、V2ではむしろ停止した場合にSavVolの容量枯渇を考慮

する必要があると理解致しました。

Celerra/VNX Replicatorについて

レプリケーションで使用されるチェックポイントの更新/切り替わりタイミングについて教えてください。

たとえば、

ユーザがファイルを開いて、修正し上書き保存する場合に、
上書きするデータが大量であると、クライアントから複数の書き込み要求はcifsサーバに行われます。

ちょうど、複数の書き込み要求処理を行っている途中に、レプリケーションのチェックポイントの切り替えタイミングが

発生した場合に、レプリケーションのチェックポイントの切り替えは、無条件で行われるのでしょうか。

以下に書き込みとレプリケーション用チェックポイントの更新を時系列で記載します。

このケースの場合、レプリケーション先のファイルシステムの該当ファイルを見ると、

(A)のレプリケーション更新では、2つ目まで更新されたファイルが見え、

次の(B)のレプリケーションの更新で、上書きされたすべてのデータが見えると考えてよいでしょうか。

それとも、書き込み要求がすべて完了する(B)までレプリケーションの更新は発生しないのでしょうか。

1)クライアントがファイルをオープン

2)クライアントがファイルのデータを読み取り

3)クライアント側でデータを変更

4)クライアントからファイルの上書きを実行

　※クライアントから、3つの書き込み要求が発生したケースです

　4-1)一つ目の書き込み

　4-2)二つ目の書き込み

　　　<-- (A)この時点で、レプリケーション用のチェックポイントの切り替えが発生

　4-3)3つ目の書き込み

5)ファイルのクローズ

　　　<-- (B)この時点で、次のレプリケーション用のチェックポイントの切り替えが発生

VNX Replicatorについて

スケジュールで実行しているReplicatorについて、

同期感覚の調整を考えています。

Re: Replicator V2の同期間隔の調整に関して

では定期的にnas_replicateを実行してくださいとのことですが、

定期的に転送時間を確認できない場合に確認する方法はありますでしょうか?

ログ等から判断する方法があればご教示ください。

Ryo.Tさんの質問に回答します。

ReplicatorはVNX File環境専用のデータ複製機能です。
これに対し、RecoverPoint（以下RP）は元来VNX Block環境のデータ複製ソリューションですが、File環境に応用することが出来ます。 以下に代表的な違いを記します。

「Replicator」
1) 管理                       　：GUI及びCLIで容易
2) 構成                   　    ：ローカルとリモート
3) 用途                   　    ：データ保護、災害対策
4) 複製側アクセス　　    ：読取専用で常時アクセス可能、フェイルオーバで書込み可能
5) 追加機器                  ：不要（ライセンスのみ）
6) RPO                         ：数十分から数時間
7) フェイルオーバ単位   ：ファイルシステム
8) ファイルサーバ切替   ：別途切替操作が必要

「RecoverPoint for VNX File」
1) 管理                          ：CLIのみ
2) 構成                          ：リモートのみ
3) 用途                          ：災害対策
4) 複製側アクセス          ：フェイルオーバ時のみアクセス可能
5) 追加機器                   ：RPアプライアンスが必須
6) RPO                          ：数分
7) フェイルオーバ単位    ： DataMover（もしくはVNX筐体）
8) ファイルサーバ切替    ：フェイルオーバと同時

10数年前に遡り、歴史的な経緯から紹介します。 当時Symmetrix環境にて、SRDFは堅牢な災害対策ソフトとして定番オプションでした。　このSymmetrixに接続するNASとしてCelerraがリリースされ、続いてSRDFベースの災害対策機能（SRDF with Celerra）が提供されました。
これが発展して、CLARiXベースのMirrorViewと組み合わせた災害対策機能（MirrorView with VNX File）となり、さらに発展して、現在のRecoverPointベースのRecoverPoint with VNX Fileになっています。

これらの共通している点は、Blockベーステクノロジーを基にして、ファイル環境のデータ複製機能を実現していると言うことです。　動作としては、1台のVNXの中で行うDataMoverのフェイルオーバを、VNXを跨いで行うイメージです。

これに対して、Replicatorは全く異なる生い立ちです。　CelerraのOS(DART)レイヤで実装したファイル環境専用のデータ複製機能として、2002年にリリースされ、SnapSureベースのReplicator V2として発展し現在に至っています。　GUIやCLIでとても簡単に、設定やフェイルオーバ/フェイルバック等が行えます。　

現在のFile環境では、Replicatorを使う場合がほとんどです。
上記1から5ではReplicatorの方が有利で、例えばHDDの複数障害に備え別RAID（またはPOOL）に複製を行ったり、複製先でテープバックアップや書込み可能SNAPを使ってテスト環境を構築することも可能です。

ではどのような場合にRP（もしくはBlockベーステクノロジー）が選択肢になるかというと、地域や建屋全体の災害に備え、システム全体で災対サイトに切替える運用などが対象になります。
上記6から8は有利に働きます。例えばフェイルオーバ時にDataMover上のCIFS/NFSサーバも同時に切替わるため、クライアントから透過的にアクセスできます。　但し、一つのファイルシステムだけフェイルオーバするといった事はできません。　従って、BlockベーステクノロジーをFile環境で使っているのは、業務継続性要件が厳しい一部のシステムやSymmetrixユーザが継続して利用している場合等に限定されます。

現時点の方向性としては、どちらも発展を続けていて適材適所に使い分けられることになります。

参考資料：「VNX_for_FileでのRecoverPoint/SEを使用した災害復旧」
https://support.emc.com/docu41535_VNX_for_FileでのRecoverPoint/SEを使用した災害復旧.pdf

Toyodaです。　hanakoさんのご質問にお答えします。

チェックポイント更新の振る舞いは、上位のCIFS I/Oには配慮しません。

複数の書き込み要求が仕掛かり中の状態でも、更新オペレーション時の

point-in-timeのファイルシステムイメージがチェックポイントとして確保されます。

つまりhanakoさんご提示のケースでは、(A)の時点でチェックポイントは更新され、

且つ二つ目の書き込みまでの状態が反映されており、

(B)の更新ではその複数書き込み要求が全て完了した状態が反映される事になります。

imaiyさんのご質問にお答えします。

ログでの確認は難しいので、server_stats コマンドでご確認いただくのがよいのではないかと思います。

$ server_stats server_2 -interval 1 -monitor rep.v2.Session.ALL-ELEMENTS.Transfer
server_2      RepV2 Session      Transfer      Start Time           End Time          Total      Transfer   Disk Read    Disk  
Summary                                                                             Copied 8KB     Rate       Rate       Write 
                                                                                      Blocks       KB/s       KB/s     Rate KB/s
<略>
11:27:19   rep_name001           previous  07/10/13 11:23:54   07/10/13 11:27:18           2997        120       8256       1205
<略>
11:30:18   rep_name001           previous  07/10/13 11:27:19   07/10/13 11:30:18           2606        120       7839       1241
<略>
11:34:24   rep_name001           previous  07/10/13 11:31:07   07/10/13 11:34:24           2879        120       7111       1201
<略>

と言った感じです。

同期間隔の調整に関してもう少し確認させてください。

Last Sync Timeを参照する他に同期間隔の調整を行う指標として何か使っているものはあったりしますでしょうか。

例えば、nas_fsやfs_ckptコマンドなどを利用してSavvolやファイルシステムの使用率などをみて、

同期に要する時間を推測する手法などがあれば教えてください。

VDMレプリケーションのフェイルオーバの順番について

VDMとファイルシステムをフェイルオーバする際の順番に関して、明確な定義、注意事項はございますでしょうか？

VDMから先にフェイルオーバした方がよいようなことをどこかで聞いた（見た）ような気がして

VDM、ファイルシステムという順番だと認識していたのですが、検証機レベルではどちらを先に

フェイルオーバしても特に問題なさそうでした。

フェイルオーバの順番について何か注意事項等ありましたら教えて頂けますでしょうか。

VDMのマニュアルには、ESX環境の場合の手順としてのみ下記の記載があり、

ファイルシステム、VDMという順番でフェイルオーバするようになっていました。

ただ、この手順はインターフェースの停止がポイントのように見えるので順番は

どちらでもよいようにも思えます。

---------マニュアル抜粋-----------------------------------------------------------

ESXデータストアを使用したNFS用VDMの複製

ESXデータストアに使用するNFSファイルシステム用VDMを複製する場合、次の手順を実行

し、VMがオフラインになっていないことを確認する必要があります。

注： 次の手順が順序どおりに実行されない場合、ESXサーバがデータストアにアクセスできなくな

ります。

次の手順は、NFSデータストアがIPアドレスを経由してVNXに接続していると仮定していま

す。

● VDMにマウントされているPFS（本番ファイルシステム）をフェイルオーバーする

● ソース上のインタフェースを停止する

● VDMをフェイルオーバーする

● 宛先上のインタフェースを作動する

注意：

VDMがユーザーのファイルシステムの前にフェイルオーバーされると、ESXサーバはエ

ラーNFS3ERR_STALE（無効なファイルハンドル）を受け取ります。そのため、ESXクライ

アントはファイルシステムがダウンとしていると見なします。

このエラーが発生しないようにするには、VDMにマウントされているPFSがフェイルオー

バーされたときに、ソースでserver_ifconfigコマンドを使用してVDMインタフェースを

停止に設定します。これでVDMがフェイルオーバーされます。VDMがレプリケーションサ

イトで再起動されると、server_ifconfigコマンドを使用してVDMインタフェースを作動

に設定することができます。

--------------------------------------------------------------------

compusさん、

明確な指標というものはありませんので、環境と要件に応じて調整する、というのが実情です。
実際のところは、調整して結果・影響を確認する、ということになると思います。
曜日や時間帯によってアクセス状況(更新量)が異なり、週平均としてReplicationセッションが
維持されているような場合は、ピーク時の影響には注意が必要です。
考えられる影響で一番大きなものは、ReplicatorによるストレージへのRead負荷になります。
RPOを短くし過ぎると転送されっぱなし、のような状態になりますので、本当に高負荷状態で
使っているストレージでは考慮が必要です。

具体的な手法ですが、ご推察通り、転送量の把握がポイントの１つとなります。

server_statsで見られなかった頃は、fs_ckptでおおよその容量を確認することや、
クライアントから検索をかけて特定日時の更新量を確認することもありました。
今は、上で書かせていただいたように、server_statsコマンドで各数値が分かります。
再掲して補足説明させていただきます。

11:27:19   rep_name001           previous  07/10/13 11:23:54   07/10/13 11:27:18           2997        120       8256       1205

     11:27:19            → server_statsコマンドが出力した時間
     rep_name001     → Replication Session名
     previous             → 前回転送時の情報(currentというのも出ますが転送が完了したものは

                                   previousとして出ますので、通常はpreviousを確認します)
     07/10/13 11:23:54 → 転送開始日時
     07/10/13 11:27:18 → 転送終了日時
     2997                 → 転送ブロック数(x8KBが容量)
     120                   → 転送レート(この環境は -bandwidth /1024 でした)
     8256                 → Disk Readレート
     1205                 → Disk Writeレート

転送ブロック数に8KB掛けることで転送量が分かりますので、特定期間の転送量を集計して、
使用可能なネットワーク帯域で割ることで、所要時間が推測できます。
使用可能なネットワーク帯域も、上記の転送レートを集計、平均値化して使うことができます
(転送ブロック数が小さい時の値はあまり正確ではないので除外します)。

なお、server_statsコマンドは-fileオプションで結果をファイル出力できますし、-format csvと

すればCSV出力にもなりますので、-countオプションと合わせて、

$ server_stats server_2 -interval 1 -count 86400 -format csv -monitor rep.v2.Session.rep_name001.Transfer -file filename001.csv &

として24時間分の確認をする、というような使い方が便利です(Control Stationの空容量にはご注意ください)。

# 前回ALL-ELEMENTSだった部分をReplication Session名にしてみました