タイトルのドリーシープは、科学によって作成された高レベルの生き物の最初の成功したクローンの姓です。 クローンの生物学はまだ実験的な分野ですが、ITおよびデータストレージの分野では、クローンのトピックはしっかりと広く定着しています。
さまざまな大規模データの完全なコピーを迅速に（そして最も重要なこと-経済的に）作成する機能は、今日非常に厳しいタスクです。 このようなデータのクローンは、「戦闘データ」でこれを行うことが望ましくない、または直接不可能な場合、テスト、開発、およびその他の実験に使用できます。
クローンを適用する場所と方法の実用的な例。
たとえば、ERPシステムのベースなど、ビジネス全体が集中している大規模なデータベースを使用しているとします。 もちろん、ビジネスの存続と成長は、当社の成長とともに、開発チームがベースの新しい機能を作成し、新しいジョブを設計し、新しいビジネスロジックをデータベースに書き込みます。 そして、データのテストと検証に必要なすべてのこと。 さらに、より多くの実際のデータがあればあるほど、テストはより効果的で正確になります。
理想的には、企業の実際のデータに基づいて、実際のデータでテストする必要があります。 しかし、彼らの正しい考えの中で、「戦闘」ベースで何かをテストできるのは誰ですか？
さて、特にテスト用に、現在の状態でデータベースの正確なコピーを作成できたら！
しかし、完全な独立したクローンを作成するには、少なくともメインベースの容量に等しいストレージボリュームが必要です。 さらに、そのようなベースの速度は、理想的には「戦闘」に等しくなければなりません。つまり、それらを「USBドライブの束」にコピーするのは適切ではありません。 たとえば、SAPなどのERPシステムの実装条件では、開発されたインフラストラクチャに開発およびQAユニット（品質保証、検証、チェック）が必要であり、多くの場合、実行の基礎となるという事実については話していません新しいユーザーのトレーニングと教育を行い、それぞれが現在のデータベースの独自のコピーを持っている必要があります。これは、アプリケーションの開発と制御、およびスタッフのトレーニングです。
これらの要件により、ERPを実装する企業は自動的にメインストレージシステムに2つまたは3つ、またはその2倍の3倍のディスクに自動的に分類され、購入だけでなく運用にも費やします。サービス、管理など。 ただし、コピーの関連性を維持することは依然として重要です。つまり、コピーの変更を定期的にロールアップし、状態のメインコピーの最新の状態を維持することを意味します。
ここでは何もできません。 ベースの複数の同一コピーを保持する必要があります。
それともまだ可能ですか？
そして、ここでクローンがプレイし始めます。
クローンは、完全なコピーとして機能するデータの完全なコピーです。つまり、「読み取り専用」ではなく、通常のコピーのように機能します。 このようなクローンの内容は、読み取るだけでなく、変更することもできます。つまり、アプリケーションに通常のデータセクションとの作業を区別することなく、完全に書き込むことができます。
クローンを作成するには3つの方法があります。 まず、データを自由な場所にコピーし、その関連性を手動で維持します。 これは明らかであり、面白くありません。 むしろコピーであり、クローンではありません。 このオプションは、高価な保管場所の巨大なスペースとその作成に多くの時間を費やします。
2番目のオプションは、いわゆるコピーオンライト（COW）コピーです。 これらには、たとえば、テスト対象のアプリケーションが「コピー」を入れようとするレコードが含まれており、元のデータセットとその変更の両方が保存される一方で、ソースデータが特別な予約スペースにコピーされます。 ここでの問題はCOWスナップショットの問題と同じであり、そのようなストレージのパフォーマンスはほぼ3倍になります。 そして、これも面白くない。
そして、3番目のオプションはNetAppによって実装されました。
既にご存知のように、すべてのNetAppストレージシステムの基盤であるWAFLと呼ばれる基礎となるデータブロック割り当て構造は、実際に変更されたブロック内ではなく、現在の状態データポインターが再配置されるボリュームの空きスペース内でブロック変更が行われるように設計されています。
このスキームにより、クローン内の可変ブロックの問題を簡単かつエレガントに解決できます。 クローンは常にデータの仮想「コピー」と同じままです（つまり、ディスクスペースを占有することはできませんが、そこからソースデータのブロックを参照するだけです）。クローンインスタンスで行ったブロックへの変更はすべて個別に蓄積されます。
したがって、このようなクローンは、クローンに加えられた変更の量だけでディスクスペースを占有します。
開発部門のプログラマーがデータベースのクローンの仮想コピー（サイズが6TB）の数テラバイトのデータを変更した場合、クローンはディスク上のこれらの2TBを空き領域から正確に取得します。それだけです。
スクリーンショットでは、このようなクローンが実際にどのように見えるかがわかります。 10GBのエクスプローラーから見ると、ディスクには3つのファイルがありますが、3つすべてがディスクが占めるスペースは10GBだけです。
また、このようなクローンが元のボリュームから簡単に「削除」され、必要に応じて物理コピーに変換できることも役立ちます。
開発者は、データベースを新しいバージョンにアップグレードするプロセスをチェックしましたか、それともパッチをテストしましたか？ 彼らはアップグレードし、すべてのソフトウェアが新しいバージョンで正しく動作することを確認し、すべてが更新されたデータベースで動作することを確認し、作業ボリュームを更新され検証された「クローン」で簡単に置き換えました。かなりフルボリューム。
ちなみに、各ボリュームには（システム全体ではなく、各ボリュームで！）最大255個のクローンが存在できます。また、クローンの数に制限はありません。 開発者に複数のオプションがあり、そのうちの1つを選択する場合は、各オプションのクローンを提供し、実験と選択をさせて、必要なすべてのオプションを一度に比較します。
ご覧のとおり、データをクローンするためのこのようなシンプルで効果的なメカニズムの存在は、その使用に対するアプローチを大きく変えることがよくあります。 例として「不可能だから」、これまでに行われなかったことは、実データでの同じ実用的なデバッグ、またはそのようなクローンを使用した大量のマルチギガバイトおよびテラバイトのデータでの並行開発は、非常に実現可能です。
記事のタイトルの写真に