DataDomainの暗号化機能(Encryption)での暗号化キーの変更手順について

shinさん

詳細な手順の記載をありがとうございます。頂戴した質問に以下の通り回答します。

（質問1）

EMC Data Domain Operating System バージョン 6.0 管理ガイドP.491 表179の「Destroyed」状態の定義に記載があるように、Data Domainは古いキーで暗号化されたデータを全て復元して新しいキーで再暗号化した後に、古いキーのステータスをMarked-For-DestroyからDestroyedに変更するという動きをします。

つまり、古いキーが必要な状態では「Destroyed」状態にはなりえません。従いまして、古いキーの状態をきちんと「Destroyed」の状態に持ってきている上記手順はどちらも正しいです。

（質問2）

はい。キーの変更だけでは基本的にExisiting Dataへの新たなキーの適用はないとご理解ください。

（注：今回例のように新たなキーの適用後に古いキーを削除する際には逆に全てのExisiting Dataへの適用がなされます）

（質問3）

一般に公開されているドキュメントにはケースバイケースとしか記載がないのですが、社内にあったFAQドキュメントにあくまでも「参考値」として既存データの暗号化に必要な時間サンプルが出ていました。

それによると1TBのデータを処理するのにDD9500では11分半、DD4200では25分強といったところです。

ご質問の例では新しいキーでの暗号化の前に古いキーでの復号化が入ってくるのでもう少し時間がかかるかとは思いますが、暗号化して書き込みを行うのにそこそこの時間がかかるようなので、その復号化の時間は誤差として扱ってもよさそうです。

（質問4）

はい。合っています。

【参考】

EMC Data Domain Operating System バージョン 6.0 管理ガイドP.372より

［MTree またはディレクトリ レプリケーション］の場合、ソースとデスティネーションの両方で暗号化の構成を同じにする必要はありません。その代わり、レプリケーション関連づけフェーズ中にソースとデスティネーションでデスティネーションの暗号化キーが安全に交換されます。データはデスティネーションの暗号化キーを使用してソースで再暗号化されてから、デスティネーションに送信されます。

（質問5）

Datadomainのレプリケーション時間についてにもあるように完了を把握する方法はありません。レプリケーションが正常に動作をしていることによって問題なく暗号化も動いていると判断してください。

（質問6）

Enable Encryption Over Wireはデータ転送中のパケットを取得されないためのSSLトンネリング技術なので意味があるといえばあるのですが、shinさんがおっしゃる通りデータ自体がきちんとEncryptionされていればどうせパケットを盗み取られてもデータ復元は出来ないので意味がないとも言えそうです・・・

まぁ、悪意のある人がパケットキャプチャをそもそも諦めるというようなメリットはあるのかと。

（質問7）

これも（質問3）の回答と同様にケースバイケースで特に明記した注意点などは見つかりません。

とはいえ完了までに数時間から場合によっては数日必要となることも考えられるので、運用状況に合わせた実行タイミングや負荷を考慮して頂いた方がよいということは言えそうです。

Ueharaさん

判りやすく、ご回答頂きありがとうございました。

ご参考にさせて頂きます。

ueharaさん

すみません。

（質問5）に絡むのですが、レプリケーションの同期完了の確認方法について確認させて下さい。

https://community.emc.com/thread/204749?start=0&tstart=0

などを参考にさせて頂き、レプリケーションの完了確認方法は、

「Pre-compressed bytes remaining: 0」によりレプリケーションの完了と認識しています。

下記の例は、Mtree repicationのペアを組んでいて、ほぼ同じ時刻(6/20 17時位）にソース、ディスティネーションで、

① 「replication show  stats all」で、「Pre-compressed bytes remaining」を確認

② ASUPで、「Pre-compressed bytes remaining」を確認

③ GUI画面上での確認

した結果です。

ソース側はバックアップジョブで書き込んでおり、6/20 の13時ごろにジョブによる書き込みが完了しているようにのですが、それからレプリケーションの転送が始まっているように見え、ソース側では14～15時位まで   Replicated (KB) Networkに、同期データが流れているようです。

▼ソース側

ソース側　replication show  stats all   （6/20 17位のログ）

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

:

Network bytes sent to destination:          3,085,781,555,400                              

Pre-compressed bytes written to source:     25,581,047,563,440                             

Pre-compressed bytes sent to destination:   25,451,195,637,616                             

Pre-compressed bytes remaining:            512   ★                                          

Compression ratio:                          8.2                                            

Sync'ed-as-of time:                         Tue Jun 20 16:53 

ASUP

Replication Detailed History

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

Directory/MTree Replication:

Date         Time       CTX   Pre-Comp (KB)   Pre-Comp (KB) Replicated (KB)

                                    Written       Remaining         Network

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

2017/06/20   12:15:58     1               0               0              21

2017/06/20   13:15:58     1      79,182,007      10,785,493       7,087,615

2017/06/20   14:15:58     1               0               0       2,231,602

2017/06/20   15:15:58     1               0               0             131

2017/06/20   16:15:58     1               0               0               2

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

▼ディスティネーション側

ディスティネーション側　replication show  stats all （6/20 17位のログ）

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

:

Network bytes received from source:         3,086,563,096,948                              

Pre-compressed bytes written to source:     25,581,047,563,440                             

Pre-compressed bytes sent to destination:   25,451,195,637,616                             

Pre-compressed bytes remaining:             0                                              

Compression ratio:                          8.2                                            

Sync'ed-as-of time:                         Tue Jun 20 16:53                               

ASUP

Replication Detailed History

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

Directory/MTree Replication:

Date         Time       CTX   Pre-Comp (KB)   Pre-Comp (KB)  Replicated (KB)

                                    Written       Remaining          Network

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

2017/06/20   12:26:45     1               0               0               18

2017/06/20   13:26:45     1      79,182,007               0        9,321,903

2017/06/20   14:26:45     1               0               0              295

2017/06/20   15:26:45     1               0               0                0

2017/06/20   16:26:45     1               0               0                0

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

質問なのですが、

（１）同期完了のタイミングについて

ソース側のバックアップジョブ完了後、その一連のデータがレプリケーションされディスティネーション側に同期が完了するのを確認する場合、ASUPでは、14時中くらいに「Pre-compressed bytes remaining: 0」となっていますが、実際には同期は、15時中位まで転送が続いておりますので、どのタイミングで、「replication show  stats all」又は、GUIのSUmmaryで確認するのが妥当でしょうか？

（２）同期完了の確認方法について、下記で宜しいものでしょうか？

・CLI では

  ソースとディスティネーション両方で「replication show  stats all」を

　実行し、両方とも 「Pre-compressed bytes remaining: 0」になっていること。

・GUIでは

・ソースとディスティネーション両方で、Replication Summary の

　「Pre-Comp-Remaining」の表示が、"0"になっていること。（ディスティネーション側はN/Aでも問題無いか？）

（３）6/20 17時位に確認した際の結果について

・上記のサンプルですと17時位のタイミングで、

  CLIでは、

　ソース側の　Pre-compressed bytes remaining:      512                                            

　ディスティネーションの Pre-compressed bytes remaining:    0

この違いは、ソース側に書き込みはないので、管理データ的なもので"512"が存在し、それがディス手ネーション側に転送完了していないという理解であっていますでしょうか？

  GUIでは

　 ソース側の「Pre-Comp-Remaining」の表示が、"0"

   ディスティネーションの 「Pre-Comp-Remaining」の表示が　"N/A"

   ディスティネーション側で、N/Aはどのようなケースで表示されるものでしょうか？

色々、申し訳ありませんが、何卒、宜しくお願い致します。

shinさん

（１）と（２）に関しては同期完了の確認はSync'ed-as-of timeの更新で確認をしてください。少なくともその時間のデータまでは同期が完了していると言える値なので。

（Data Domain Mtree Replicationについても参考になると思います）

（３）に関しては、ソース側に何も書き込みがなかったにも関わらずPre-compressed bytes remainingに値が出てきているということは何か内部処理などでの書き込みがあったと考えられるのですが、具体的にそれが何か（DDでレプリケーションに影響する内部処理が何か）というところまではKBなどを調べてみても出てきませんでした。。

また、「Pre-Comp-Remaining」の表示がN/Aになっているものはラボマシンを見ても一つもない上にKB、アドミンガイド、オンラインヘルプを見てもどこにも見つからないので、英語フォーラムに質問を投稿しています（[DD Replication] Pre-Comp Remaining: N/A ?）。

Ueharaさん

すみません。

もう一つ忘れていました、（１）と（２）の確認は、ソース、ディスティネーションの両方のDDで確認したほうが良いですよね。

Ueharaさん

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

双方のDDで、「Sync'ed-as-of time」が、バックアップジョブが完了した時刻（ソース側）への書き込みが完了した時刻）以降になっていて、「Pre-compressed bytes remaining」がゼロになったら、そのバックアップデータがディスティネーションに反映された目安となる旨、ご説明しようと思います。

また、「Pre-compressed bytes remaining」完全にセロにならないケースは内部処理等の影響の可能性が考えられるが、内部処理に関しての詳細は公開情報がないということでご説明しようと思いますが、N/A表示について何か判りましたら、ご一報頂けると幸いです。

はい。英語サイトで回答を得ることが出来たらこちらのスレッドにも情報展開します！

はい。念のために両方のDDで確認することをおすすめします。

Ueharaさん

ありがとうございます。

宜しくお願い致します。

ueharaさん

英語サイトに確認をお願いしていた、「Pre-compressed bytes remaining」=N/A の表示の件ですが、英語サイトの問いにもまだ回答を得られていないようですが、更新は無いでしょうか？

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

「Pre-compressed bytes remaining」完全にセロにならないケースは内部処理等の影響の可能性が考えられるが、内部処理に関しての詳細は公開情報がないということでご説明しようと思いますが、N/A表示について何か判りましたら、ご一報頂けると幸いです。

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

実は、お客様より回答を急がれており、再度、ご確認頂くことは可能でしょうか？

また、ソース側で「Pre-compressed bytes remaining」完全にセロにならないケースですが、今回のように暗号化機能を使用している場合、暗号化キーの授受などにより、完全にゼロ表示にはならないというようなことは考えられませんでしょうか？

お客様の環境で、その後も確認していたところ、ソース側で「Pre-compressed bytes remaining」の表示が完全にゼロとなることは無いようです。

レプリケーション自体は問題無く実施出来ているようですので、暗号化機能を使用している場合、

ソース側：ゼロに近い値（完全にゼロにはならない）

ディスティネーション側（N/A の表示）

になっているのが、通常ではないかとも推察しております。

お手数をお掛けしますが、引き続きご確認宜しくお願い致します。

shinさん

社内のData Domainに詳しい人達に聞いてみたのですが、今回の事象は暗号化を行っているが故に発生している事象、別の言い方をすると暗号化を行っている場合には今回のような動作をするのが自然ということでは「ない」というのが結論です。

ソース側のPre-compressed bytes remainingの値に関しては、レプリケーションが終わっているのに0にならない事象が過去にもいくつか散見されていることが確認できました（例：KB487918-Data Domain replication pre-comp remaining on the source is greater than zero when mtree is in sync）。

また、デスティネーション側でCLIを利用して「Pre-compressed bytes remaining:」の値が0になっていることが確認出来た場合に、GUIで確認すると「Pre-Comp Remaining:」の値がN/Aとなっていたという事象を過去に見たことがあるという情報も得ることができました。そう考えるとGUIのN/Aは0と同値で考えることが出来そうです。

Ueharaさん

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

ゼロにならない件、KBの情報もありがとうございます。

レポートされる出力の問題で、実際にはレプリケーションは完了しており、6.0.0.4 以降で改善されている旨、ご説明しようと思います。ということは、Sync-as-of-timeが、お客様のバックアップ完了時間以降であれば、ソース側で「Pre-compressed bytes remaining」が完全にゼロになっていなくても、ディスティネーション側でCLIでの確認結果がゼロであれば、同期完了と見なしてよいということですね。

また、デスティネーション側でCLIでは、ゼロになって、GUI上でN/Aと表示されるのもBugですか？

こちらも表示上の問題だけであれば、そのようにご説明しようと思います。

shinさん

そうですね。Sync-as-of-timeがソース側でのバックアップ終了後の時刻になっていれば、ソース側でPre-compressed bytes remaining:がゼロでなくともディスティネーション側にも問題なく必要なデータが保存されていると判断していただいて結構です。

また、GUI上のN/Aについても表示上の問題（GUIのPre-Comp Remaining:N/A＝CLIのPre-compressed bytes remaining:0という認識でいてください）と判断していただけますようお願いします。

Ueharaさん

見解ありがとうございました。

頂きました内容で、お客様にも説明させて頂きます。