Tier-1プラットフォームにおいてはシステム内で格納されたデータの整合性は非常に重要です。デイトリウムはデータの信頼性については高性能を維持しつつ非常に綿密に検証しています。 製品の基本要素を設計した当初から考え、多くのリソースと考えを洗練されたデータチエックが行える堅牢なシステムを開発するために投資しました。 1つの方法では十分な信頼性を保てないと考え、多くの技術を組み合わせて実現されました。 このホワイトペーパーではDVXでどのようにデーターの信頼性を実現しているかを説明します。

1. Datrium DVX
データの完全性を常時提供
テクニカル
レポート
デイトリウムジャパン合同会社 info.japan@datrium.com | www.datrium.co.jp

2. 2
はじめに
デイトリウムは高性能と
共に高度なデータの安
全性を提供します
DVXはハイブリッドクラウド環境で高性能なプライマリシステムとVMベ
ースのデータ保護と実用的なRPO、RTOが最初から組み込まれた、低コス
トのセカンダリを単一システムで提供するオープンコンバージドシステム
です。
製品の目的:
1 ] エンタープライズレベルの信頼性
2 ] シンプル, ゼロクリック管理
3 ] 最高のパフォーマンス
4 ] 最初から組み込まれたバックアップ機能
5 ] データロスが発生しない
ほとんどのストレージシステムはいくつかのコモディティハードウエアで
構成されてます。そして多くのコンポーネントは障害を起こす可能性があ
り、それに対処する必要があります。さらにソフトウエアも存在しています
ので微妙なバグが、ファイルシステムを壊してしまう事もあります。通常の
システムでは基本的な整合性チェックは行いますが、性能が重要視され
優先されてしまい詳細な検証は行なってません。
Tier-1プラットフォームにおいてはシステム内で格納されたデータの整合
性は非常に重要です。デイトリウムはデータの信頼性については高性能
を維持しつつ非常に綿密に検証しています。製品の基本要素を設計した
当初から考え、多くのリソースと考えを洗練されたデータチエックが行え
る堅牢なシステムを開発するために投資しました。1つの方法では十分な
信頼性を保てないと考え、多くの技術を組み合わせて実現されました。
このホワイトペーパーではDVXでどのようにデーターの信頼性を実現し
ているかを説明します。

3. 3
データ整合性は重要なトピックでデイトリウムでは設計プロセスでの最
重要項目にしています。ここではどのような思想で製品化の当初からこ
れを実現したかを説明します。
基本的な考え
製品の問題が少なくなる事は顧客にとって有益だという事は明らかで
す。また、問題の修正作業も少なくなりエンジニアは新しい機能の開発に
多くの時間を使えるという別の利点もあります。
相互評価
デイトリウムではファイルシステムチームのエンジニアが作業しているモ
ジュールの設計ドキュメントを必ず作成します。そしてそれは彼らのソフ
トウエアが内部でどのようにデータの安全性を確保しているかを開発チ
ーム全員が納得できる内容になっていなければなりません。例えばどの
ようにして入力データや、モジュール内に展開されたデータの安全性を
保証するのかになります。これらの作業は非常に厳密に行われ、厄介な
作業になります。
詳細な設計をドキュメントに落として、それをチーム全体でレビューする
ことはスタートアップの企業においては非常に珍しい事です。この作業自
体は非常に大変ですがチーム全体がデータの整合性に対して同じ認識
を持つという点では重要だと考えます。また長期的な目標の下しっかりと
した基礎を確立するという点でも重要な事です。
性能への影響
整合性の確認を行うためには多くのステップが必要で全く性能の劣化無
しには実現できませんが、この確認作業は最も重要な要項の1つですの
で５％未満の性能劣化は許容されると判断しそれを実現しました。
操作ボタンなし＝簡単な管理
多くのシステムではイレージャーコーディング、重複排除、圧縮、チェック
サム、といった様な一般的な機能は後付けされていてそれを使用するか
どうかはユーザーの判断に任されます。そしてこれらの機能は効率的に
動作させることが困難なので選択式になってます。その時ユーザーはこ
れらの機能の設計、構成、トレードオフ等について熟知している必要があ
り、見えない部分で問題が発生する可能性もあります。さらに大きな副
作用としてこれらの全ての機能が影響し合うであろうと考えられる複雑
な組み合わせのマトリックスも必要になります。QAチームは予めこれら
全ての組み合わせのテストを行う必要があります。Datrium DVXは選択
肢を無くすという設計思想から開発され、全ての機能は常時使用されま
す。このことによりシステム内部の複雑性を無くすだけでなく、ユーザー
に簡単な設計、管理を提供することができました。
さらに一部のHCIに於いてはバックアップの機能、常時重複排除、大規模
なスナップショット、バックアップカタログ等の機能を持っていませんの
で、この側面からもエンタープライズのユーザーの要求にはミートしませ
ん。
設計プロセス

4. 4
テストの自動化
デイトリウムは会社設立当初からテスト自動化のフレームワークの構築
に大規模の投資をしました。ラップトップに分散システムをエミュレート
しテストが簡単にしかも迅速に行われる様なシュミレーターを作成しま
した。テスティングのフレームワークに投資してもそれが簡単に行われ
なければ誰もテストを行いません。全てのエンジニアは彼らのモジュー
ルが信頼性があるということを証明するために様々な方法で自動的にス
トレステストが行われる事を望んでいます。この自動テストもまた全員
でレビューしています。このテストでは全てのテストが少し異なっている
様にランダムに実行されます。chaos monkeyのアプローチにすこし似て
ます。
デイトリウムはハードウエアが（対処を施さないと）必ずデータをロスト
するということを前提にソフトウエアを開発しました。その問題からデ
ータを守る為に以下のうような複数の対策を取っています。
チェックサム
デイトリウムは分散システム製品です。ユーザーデータはシステムに入っ
てくると即座にチェックサムが付加されます。全てのネットワークで転送
されるデータブロックは、チェックサムが行われ受信側で検証されます。
ディスクに書かれているデータも全てチェックサムが行われて、それらは
リードされた時に検証されます。ディスク上の全てのデータは問題検出
のために複数の方法でチェックサムされてますが、ディスクがデータを間
違えた時等はそれでも不十分です。このため、参照による整合性確認も
行なってます。
参照
ディスク上のデータではチェックサムだけでは不十分です。例えばチェッ
クサムの正しい古いデーターがディスクから帰ってきた時はどうなるでし
ょう。不自然かもしれませんがディスクは既に失効したデータを返す時が
多々あります。ディスクから読み取られたデータが期待されたデータであ
ることを確認するにはチェックサムを違う場所に格納する必要がありま
す。クリプトハッシュがここでは最適だと考えます。クリプトハッシュは重
複排除でも使用されています。クリプトハッシュを使用すると、データの変
更が行われるとハッシュのミスマッチが検出されるといったブロックチェ
ーンに似たいくつかの重要な利点があります。
ステートレス ホスト＆キャッシュ
デイトリウムのアーキテクチャーはソフトウエアが各ホストで実行される
スプリット・プロビジョニングを使用しホストフラッシュの優位性からくる
驚異的な性能を提供します。そして全てのデータを格納する為のオフホ
スト・ストレージプールもあります。ホストのキャッシュはステートレスで
設計され、リードの高速化に利用されます。全ての永続的データはストレ
ージプールに格納されます。ホストもしくはホストのフラッシュを失って
もデータの安全性は保たれますのでデータロストの危険性はありませ
ん。
ハードウエア障害か
らのデーター保護

5. 5
ソフトウエア障害か
らのデータ保護
ホストフラッシュ上のデータは全て重複排除、圧縮、チェックサムが行わ
れてます。ホストフラッシュからのデータリード時に再度チェックサムを
確認します。もしホストフラッシュのデータに障害があっても問題にはな
りません。その時はストレージノードからデータを読み、フラッシュに再
格納します。
２重ディスク障害への対応
デイトリウムはストレージプール内の２重ディスク障害時にも耐えられ
る様なイレージャーコーディングを常時行ってます。あるHCIベンダーは
基本的には単一ディスク障害時の対処法のみ（RF=2)を行ってます。し
かしながら、この単一ディスク障害対応には問題があります。ほとんどの
ストレージ業界の製品は論理的な理由により20年以上前から２重障害
対応へ移行してます。２重障害は主にLSE（潜在しているセクターエラ
ーやアンコレクタブルエラー）対応です。ドライブの２重障害の確率は低
いですがドライブ障害の時のリビルドサイクルの中でLSEが発生する確
率はかなり高いです。その対応がこの２重障害対応の主な理由になりま
す。単一ドライブ障害対応では不十分であるということを証明する数字
は一般的に公開されてます。デイトリウムのソフトウエアはディスクの２
重障害対応を正確に行います。
ドライブ ベリフィケーション＆スクラビング
デイスクやSSDは時間の経過と共にLSEが増加します。全てのストレージ
プールからのリードはデータのチェックサムの整合性と参照の整合性を
確認します。もし問題が検知されればイレージャーコーディングのロジッ
クを使い修正を行います。さらにはディスクはプロアクティブにスクラビ
ングをバックグランドで行っており事前にLSE欠陥の検知、修復を行って
ます。このスクラブはバックグランドで低プライオリティで行ってますの
で性能へのインパクトはありません。スクラブではイレージャーコーディ
ングのRAIDストライプのベリファイも行ってますのでドライブのリビルド
が完全に問題なく行われたことの証明にもなります。
これまでのセクションではハードウエアの障害からどうやってシステム
がデータ保護を行っているかを説明しました。データの整合性における
もう一つの脅威はファイルシステムになります。ソフトウエア自身のバグ
によってデータやメタデータの上書きが行われ破損に繋がる可能性が
あるからです。ここではソフトウエアの問題からデータを保護する為の
いくつかの重要なステップを説明します。
LFS = 上書きしない
従来のソフトウエアは新規データ書き込み時に古いデータを壊す可能
性のある場所に書き込みます。その時にデータの整合性を脅かす危険
性があります。典型的なRAIDシステムでは同じ場所でのストライプアッ
プデートを行うので新規書き込み時は古いデータが上書きされwrite-
holeの問題が存在し、この時に電源断等の障害が発生すると新規データ
も古いデータも失ってしまいます。

6. 6
Datrium DVXではログ構造化ファイルシステム（LFS）を採用し非常にシ
ンプルで且つ上書きを行わないファイルシステムの設計を行ってます。
全ての新規書き込みはフルストライピング・ライトでログの様に常に新
しい領域へ書き込みを行います。これによりシステムは非常にシンプル
になり、しかも高速化を実現し、上書きによるデータ障害から回避されま
す。
リファレンスカウントの削減
重複排除ファイルシステムを設計する一つの方法はいくつのブロック
が1つのブロックを参照してるのかを明確にするリファレンスカウント
(refcounts)を使用する方法です。リファレンスカウントがゼロになれば
データーは消去されます。この方法ではバグによりカウントが消去され
る可能性があるので全てのカウントを常に正常に保持する必要がありま
す。簡単なクラッシュ時でもこのカウントが正常にアップデートされたの
かの確認も必要になります。
デイトリウムではこれらのリファレンスカウントを使わない特有な手法で
ファイルシステムが設計されていますので、この障害から完全に回避され
ます。この手法は非常にシンプルで変更の整合性を決定する時に強い
不変量を持ったシステムが構築できます。LFSと同様にリファレンスカウ
ントを使用しない事によりデータの整合性に最大のプラスのインパクト
を与えることができましたし、ファイルシステムの実装も大幅に簡単にな
りました。
ブルートフォーステスティング vs. 組み込み検証
論理的にはソフトウエアが100％信頼がおけることを証明するためにあ
らゆる組み合わせのテストを書くことは可能ですが、実際には大量の組
み合わせが存在するので不可能です。デイトリウムでは以下の2つの方
法論でこの矛盾を解決しています。(a)自動化されたテストの中で必要な
種類を行うのに十分なランダム係数を投入する。(b)製品内部に継続的
に検証を行うためのチェックを組み込む。
継続的ファイルシステムの検証
デイトリウム製品はファイルシステム全体を１日に数回継続的に検証を
行うよう設計されています。全てのライブVMのデータは参照型整合性
チェックが行われます。全てのオブジェクトにおいてもデータが安全であ
ることの参照型確認が行われてます。検証ロジックについては非常に細
部にわたり繊細に設計されているため、ここでの説明は省きます。あえ
て一言でいうならクリプト・ハッシュを使用することで検証は迅速、簡単に
かつ完全に行ってます。この継続的ファイルシステムの検証はディスク・
スクラブをバックグランドで実行する事により行われてます。
継続的検証には(a)ソフトウエアにはバグが発生するという事にアクティ
ブに同意し認める(b)整合性問題が恒久的な損失にならない様事前に検
知し修復する(c)より多くのチェックを行い基本的な問題を少なくする。と
いった複数の目的があります。

7. 7
継続的整合性チェックはソフトウエアの開発、テスト段階も含め常に行わ
れてます。常に行うことの優位性はシステムを立ち上げる時はどの様な状
況でもデータ整合性のテストを行うという点です。この様に徹底的にテス
トを行う事により、より多くの問題が排除されます。これによりユーザーへ
システムを出荷する前には検出できないソフトウエアの問題がほんとんど
無くなります。
検証が性能に影響しない
製品内の全体にファイルシステムの継続検証すると性能に影響を及ぼす
可能性があり、はたして良いことなのかと疑問の思われるかもしれません。
確かにこれを行うために性能を犠牲にするという選択を我々は選びました
が、実際には5％未満の影響に抑えることができました。
HDDでランダムリードを行うと性能に大きな影響を与えますので継続的な
検証を行うために最適なシーケンシャルなリードを行う設計にしました。
これが実現できれば性能に影響する事なくファイルシステム全体の検証
を１日に数回実行できますし、この検証を停止する必要も無くなります。
外部の第３者機関のベンチマークによりこのチェックが性能に影響しない
ことが証明されてます。製品にファイルシステム検証を組み込むためには
大変な技術が必要ですが、これを行うことがお客様のデータの整合性を保
つ唯一の方法ですのでデイトリウムでは実装しました。
Datrium DVXはVM保護ポリシーを確保し超高性能でVMが実行できる
クラウド・プラットフォームとして設計されてます。VMセントリックなシステ
ムであるため、VMの論理データをソフトウエアの障害から保護するため
のチェックをさらに上のレベルまで引き上げることは非常に重要な事で
す。
VM スナップショット&ビルトインされたバックアップ
それぞれのVMにはチェックサムが付いてます。（データのローリングチェッ
クサム）。これはディスクのチェックサムとは別で論理チェックサムになりま
す。継続的ファイルシステム検証の一部としてこのチェックサムも１日に数
回検証されます。このレベルの検証は組み込みバックアップ製品を設計す
るには必須になります。VMスナップショットのチェックサムは 参照の整合
性を取るために別の領域に保存され、データの変更が発生するとチェック
サムの不整合を検出します。スナップショットは全て合成フルバックアップ
です。その優位性は従来のバックアップとは異なりスナップショット間の連
携問題が発生しない点です。これによりユーザーは任意の順序でファイル
の削除、期限切れの設定ができ、レプリケーションもVM単位で任意の順番
で実行できます。
Datrium DVXは100万以上のスナップショットを保存可能です。ファイい
るシステム検証中に全てのVMのチェックサムもチェックされます。そして
100万以上のスナップショットを保存できるにも関わらず性能の影響はほ
とんどありません。これは高度の技術を効率的に利用しているからです。
VMデータ保護

8. 8
独立したスナップストア
ライブVMはデータストア内部に位置されますがVMのポリシー、スナッ
プショット、メタデータは全てスナップストアという別モジュールで管理さ
れます。データストアとスナップストアは論理的に区別され、独自のデー
タベースで構築されています。スナップストアにより、ライブVMの性能が
スナップショットから分離することが可能になりました。全てのスナップス
トアのオブジェクトも継続的ファイル検証の一部に含まれます。
レプリケーションの保証
VMのスナップショットがサイトA側で安全性を確認されたとして、どうや
って反対側のサイトBでも安全にレプリケーションさせている事を確認す
ればよいのでしょうか？そのためにデイトリウムでは様々な具体的チェッ
クを行なっています。
ここにそれを実現してるステップを紹介します:
1. VMスナップショットデータは転送前にサイトA側でパックします。
2. パッケージは改ざん防止の目的でクリプト・ハッシュで作成されます。
3. 全てのパッケージの受信が終了した時にサイトB側でクリプト・ハッシ
ュを使い整合性の確認を行います。
4. サイトB側でデータが受け付けられると、最終的に安全であることを
保証するためにシステム内に格納時に作成されるチェックサムとマ
ッチングを取り、さらなるチェックを行います。
ソフトウエアのバグは回避できませんがレプリケーションはそれに対処
できるように組み込まれてます。実行中にデータの不整合が検出される
と転送全体がリジェクトされプロセスは最初からリスタートします。もし障
害がサイトAで起きたならばレプリケーション前に検出され、WAN上やソ
フトウエアのバグによるものなのかの検知やサイトB側でのレプリケーシ
ョン後での不整合等、全て検出する様に実装しています。この様な高い
レベルのデータ信頼性の保証があるので組み込みバックアップ、DRの機
能を自信を持ってユーザーへ提供できます。
ゼロRTO = インスタント・リカバリー
ゲストVMは外部のウイルスに感染する可能性やユーザーの操作によ
り、誤ってデータを破損してしまう可能性があります。その場合直前の
VMを瞬時に復元する必要があります。Datrium DVXはバックアップがビ
ルトインされており100万のVMでも短時間のRTOで復元できます。復
元されたVMはわずかワンクリックで迅速にリスタートし有効化されます。
この処理を行うときに、同時にリストアを行う前に実行中の追加スナップ
ショットも作成します（復元中に問題が発生した時のため）。

9. 9
他社製のバックアップデバイスではこの様な手法が実現できません。さ
らにDVX内のスナップショットはエンドツーエンドでデータの一貫性、信
頼性が保証されているので安心して行えます。管理者は1000以上のVM
を一度にスナップショットすることができます。DVXは1000のVMが同時
にブートしても支障無く稼働する様に設計されてます。この様なレベルの
急速リカバリーは他社のバックアップでは実現できません。ゼロRTOはIT
プロセスの複雑化も解消します。
デイトリウムはCloud DVXというパブリッククラウドのSAAS製品も提供して
ます。これはオンプレミスのDVXからクラウドへ直接バックアップを行える
製品です。以下の章ではどの様にしてパブリッククラウド環境でのデータの
安全性を確保しているかを説明します。
Cloud DVXのデーター安全性
Cloud DVXは全てオンプレミスのDVXと同じデータ安全性のチェックを
行なってます。パブリッククラウドで同じファイルシステムが稼働しデータ
整合性チェックも有効になってます。AWSの場合はrawディスクのかわり
にS3を使用します。
AWS S3を利用する場合、正しく使わないとデータの不整合が起きる可能
性があります。S3では一貫性を保つため部分的上書きを行わずオブジェ
クト単位で書き込みます。これは大きなバッチ処理で行われ、まさにデイ
トリウムが内部で使用しているログ構造化ファイルシステムと同じ動き
になります。オンプレミスでのイレージャーコーディングはS3のオブジェク
トで同様の保護がなされてます。
グローバル重複排除 =さらなるデータ信頼性
これはクラウド間のデータ移動には必要な機能です。デイトリウムはグロ
ーバル重複排除をクリプト・ハッシュを使用しオンプレミスとクラウド間で
行なってます。（これによりWANの転送レートを極限まで少なくできます）
さらに、データの転送が確実に行われることの保証もしなければなりま
せん。 デイトリウムのグローバル重複排除は正確性を確実に保証する
ためのコンテンツ・アドレッシングスキームを持ってます。これはあまり知
られてませんが、グルーバル重複排除の属性の中に転送されたデーター
を両方のサイトで検証し保証される機能も追加されています。
Datrium DVX製品はデータの一貫性、安全性を保証する機能の拡充の
ため多大な投資が行われました。DVXは分散型拡張性ハイパフォーマン
スシステムでしかもファイルシステムを極限までシンプルにするための
多くの機能を組み込みました。このことによりエンタープライズクラスの
アプリケーションをご利用のユーザーが最新のテクノロジーでデータの
安全性を監視、保護する事が可能になっています。
クラウドバックアップ
最後に