この投稿では、NetApp
FASシリーズ
ストレージシステムにデータをバックアップする方法を検討したいと思います。
バックアップアーキテクチャそして、私は遠くから始めます-スナップショットで。 スナップショットテクノロジーは、1993年にNetAppによって最初に発明（および特許）され、Snapshot™という言葉はその商標です。 スナップショットテクノロジーは、
WAFLファイル構造から論理的に流れました。
WAFLがファイルシステムではない理由は、こちらをご覧ください。 実際、
WAFLは常に新しいデータを「新しい場所に」書き込み、新しいデータの内容へのポインターを新しい場所に移動するだけです。古いデータは削除されず、ポインターのないこれらのデータブロックは新しいレコード用に解放されたと見なされます。 「常に新しい場所にある」この記録機能により、スナップショットメカニズムは
WAFLに簡単に統合されました。そのため、このようなスナップショットはリダイレクト（書き込み）と呼ばれます。
WAFLの詳細。
内部ユニットWAFL
スナップショットはデータ自体ではなくデータブロックへのiノード（リンク）のコピーであり、システムが古い場所に書き込むことはないため、NetAppシステムのスナップショットは
WAFLのパフォーマンスにまったく影響しません。
しばらくして、「ローカルスナップショット」の機能が他の機器メーカーから要求されていることが判明したため、
COWスナップショットテクノロジーが発明されました。 このテクノロジーの違いは主に、他のすべてのファイルシステムとブロックデバイスには、原則として「新しい場所」に書き込むための組み込みメカニズムがありませんでした。 書き換え時の古いデータブロックは実際に上書きされます。元のデータは消去され、新しいデータが代わりに書き込まれます。 また、このようなダビング後のスナップショットへの損傷を防ぐために、スナップショットの安全な保管のために専用の領域が提供されます。 そのため、スナップショットに関連するファイルシステム内のデータブロックを上書きする場合、そのようなブロックは最初にスナップショット用に予約されたスペースにコピーされ、新しいデータが代わりに書き込まれます。 このようなスナップショットが増えると、寄生操作が追加され、ファイルシステムまたはブロックデバイスの負荷が大きくなり、その結果、ディスクサブシステム全体、場合によっては
ストレージシステム全体が大きくなります。
これに関連して、大部分の
ストレージメーカーとソフトウェアメーカーは、通常1〜5個のスナップショットを作成することを推奨しています。 また、負荷の高いアプリケーションでは、通常、スナップショットを作成したり、バックアップに必要なものだけを削除したりする必要があります。
バックアップには、純粋なソフトウェアとハードウェアアシスタントの2つのアプローチがあります。 2つの違いは、スナップショットが実行されるレベル（ホストレベル（ソフトウェア）または
ストレージレベル（HWアシスタント））です。
「ソフトウェア」スナップショットは「ホストレベル」で実行され、スナップショットからデータをコピーするときに、ホストがディスクサブシステム、
CPU、およびネットワークインターフェイスに負荷をかける可能性があります。 このようなスナップショットは、通常、オフピーク時に実行されます。 ソフトウェアスナップショットでは、
COW戦略を使用することもできます
。COW戦略は、多くの場合、ファイルシステムレベルまたはホスト
OSから管理できるファイル構造で実装されます。 例には、
ext3cow 、
BTRFS 、
VxFS 、
LVM 、
VMwareスナップショットなどが含まれます。
ストレージ内のスナップショットは、多くの場合、バックアップの基本機能です。
COWの欠点にもかかわらず、
ストレージレベルでハードウェアアシスタントスナップショットを使用すると、なんらかの方法でそれと共存でき、バックアップ時にホスト全体ではなく
ストレージシステムのみをロードし、スナップショットをすぐに削除して
ストレージをロードしません。
だからここに。 すべては相対的です。
NetAppにはスナップショットによるパフォーマンスの問題がないため、スナップショット
はFASシリーズストレージシステムのバックアップパラダイムの基礎になりました 。
FASシステムはボリュームごとに最大255個のスナップショットを保存できるため、データがローカルにある場合ははるかに高速に回復できます。 結局、回復用のデータがローカルにあり、回復がデータをコピーするのではなく、単に「古い場所」へのポインタを書き換えている場合、回復は非常に便利で迅速です。 他のメーカーでは、
理論的に可能なスナップショットの数は数
千に
達する可能性がありますが、操作に関するドキュメントを読んだ後、
負荷の高いシステムでCOWスナップショットを
使用すること
はお勧めできません 。
では、NetAppのアプローチと、スナップショットをバックアップのベースとして使用する他のメーカーとの違いは何ですか？ NetAppは、バックアップとリカバリの戦略の一部として、また複製のためにローカルスナップショットを真剣に使用しますが、他のメーカーはパフォーマンスの低下というオーバーヘッドのためにローカルスナップショットを購入する余裕がありません。 これにより、バックアップアーキテクチャに大きな変更が加えられます。
「自分で」撮影されたスナップショットは、クラッシュコンシステントリカバリを提供します。 このようなワンショットスナップショットにロールバックすると、アプリケーションを使用してサーバーの[リセット]ボタンをクリックして起動したようになります。 Application Consistent Backupを提供するには、スナップショットの前にデータを適切に準備するために、
ストレージシステムとアプリケーションの相互作用が必要です。
ストレージシステムとアプリケーション間の相互作用は、アプリケーション自体が存在する同じホストにインストールされたエージェントを使用して実現できます。
NetApp
FASシステムでHWスナップショットをサポートするさまざまなアプリケーション（SAP、Oracle DB、ESXi、Hyper-V、MS SQL、Exchange、Sharepoint）とやり取りできるバックアップソフトウェアがいくつかあります。
物理的なフォールトトレランスを確保するために、ローカルバックアップの失敗の可能性を減らす多くのメカニズムがあります
-RIAD 、コンポーネントの複製、パスの複製など。 すでに存在するハードウェアフォールトトレランスを使用しないのはなぜですか？ 言い換えれば、スナップショットは、誤った削除、ウイルスによる情報の損傷などから、論理データエラーから保護するバックアップです。 スナップショットは、
ストレージシステム自体の物理的な障害から保護しません。
物理的な破壊（火災、洪水、地震、没収）から保護するには、データを予備のサイトにバックアップする必要があります。 標準的なバックアップ方法では、全量のデータがリモートサイトに転送されます。 少し後に彼らは、このデータを圧縮するというアイデアを思いつきました。 データの圧縮（および抽出）のメカニズムでは、
CPUリソースが大幅に消費されることに注意してください。 その後、増分だけを転送し、少し後で逆増分バックアップを考え出しました（復旧時にフルバックアップで増分を収集する時間を無駄にしないため）。また、信頼性のために、完全なデータセットを定期的に転送します。
そして、ここでも、スナップショットが助けになります。 それらは、作成に長い時間を必要としない逆増分バックアップと比較できます。 そのため、NetAppシステムは最初に完全なデータセットを転送し、その後は常にスナップショット（増分）のみをリモートシステムに転送し、バックアップとリカバリの速度を向上させます。 途中で、送信データの圧縮を有効にすることができます。
クローン作成（およびその他）を使用したバックアップのテストなど、いくつかのタスクに同じデータを使用することが一般的になり始めており、コピーデータ管理（CDM）と呼ばれています。 クローンの「非生産的な」サイトでは、陰極化、バックアップ検証、
および予約データのシンクローンに
基づくテストと開発を実行することも便利です。
したがって、NetApp
FAS ストレージのバックアップパラダイムは、次の一連のアプローチで構成されています。
- 同じストレージシステム上のローカルとリモートの両方で、長期間保存された一貫性のあるスナップショットの削除
- アーカイブ/バックアップとリカバリのためのシンレプリケーション
- テスト用のシンクローニング
上記により、勤務時間中であってもサービスを中断することなく、パフォーマンスの問題が発生せず、より迅速かつ一貫してデータを削除（バックアップウィンドウを縮小）および複製できます（その結果、より頻繁にバックアップを取得できます）。 完全なコピーではなく、データ間の「差分」のみを送信するスナップショットを使用すると、リモートサイトからのリカバリがはるかに高速になります。 また、論理データが破損した場合のローカルスナップショットにより、リカバリウィンドウを数秒に短縮できます。
テキストのエラーに関するメッセージをLANに送ってください。反対にコメントと追加はコメントしてください