ハイブリッドストレージシステムのバックアップの落とし穴

もちろん、データを損失から保護する方法は、情報の量とデータが保存されているデバイスの両方によって決まります。 それと、別のものは常に進化しています。



したがって、バックアップに対する従来のアプローチの支持者と、使用されるストレージシステムのアーキテクチャの観点からより便利なデータを保護する新しい方法を探している人々の間で、長い間紛争が続いています。 現在、さまざまな種類のストレージシステムが急速に成長しているため、この議論はエスカレートしています。 それらのいくつかを使用するには、通常の操作タスクへのアプローチを変更し、バックアップなどのアクセシビリティを確保する必要があります。これについては、ここで説明します。



従来のアプローチでは、バックアップをテープに保存することすらできません。 バックアップ専用に設計されたストレージシステムでのバックアップの可用性について説明しています。 ディスクIBSであろうと、テープIBSであろうと、違いはありません。 この従来のアプローチは、最も関連性のある生産データを保存する生産的なシステムがあり、このデータのコピーが定期的に保存されるシステムがあることを意味します。 特に、EMCはこのためにData Domainストレージを提供しています。









従来のバックアップのスキーム。



このプロセスを集中管理するために、バックアップサーバーもよく使用されます。 また、ソースデータが破損または紛失した場合、情報の復元も実行します。 Networkerはこの分野で実績を上げています。 これは、多くの規制法を満足させる、実績のあるデータ保護ツールです。 また、アプリケーション用のソフトウェアクライアントの存在のおかげで、Networkerはそれらと完全に統合されています。



従来のアプローチとは対照的に、ストレージシステムによるデータ複製が行われます。 この場合、生産性の高いデータは同じものに複製（ミラーリング）され、別のストレージシステムに複製されました。 複数のリカバリポイントを作成するために、このミラーからスナップショットが定期的に作成されます。これは数百まで可能です。 利便性のため、このアプローチは過去数年で徐々に人気を集めています。 ほとんどの場合、彼が選ばれました：

• スナップショットがアーキテクチャに深く結び付けられているNetApp実稼働システム管理者は、
• 使い捨てメディアに関する準拠法に特に注意を払っていない人、
• そして、アプリケーションとの完全な統合を気にしない人。

一般的に、これらの2つのアプローチの間の闘争は、それが進行中だったが、あまり熱がなかった。 私の意見では、これらの2つの世界はほとんど交差していないためです。 ところで、このテーマに関する私の考えはここにあります： http : //denserov.com/2013/01/30/bu-vs-rep/



バックアップの世界は、すぐに重量が増加した新しいタイプのストレージシステムが登場したときに根本的に変化し始めたと思います。



変化するバックアップアプローチのコンテキストでは、3つの主な新しいタイプのストレージがあります。

1. 2層および3層ストレージ（SSD / SAS / NL-SAS）を使用するハイブリッドストレージ。 VNX、VMAX、およびそれらのアナログなどのシステム。
2. 大規模なスケールアウトストレージシステム（Isilon、ScaleIO、Elastic Cloud Storageおよびそれらのアナログ）。
3. 生産的なデータの重複排除を備えたシステム。 たとえば、XtremIO。 場合によっては、VNX。

おそらく、多くの人々は、これらの3種類のストレージがバックアップに特別なアプローチを必要とすることに気づいているでしょう。 以下では、最も一般的なハイブリッドシステムのバックアップに関する考慮事項の概要を説明し、今後の出版物では残りの2つのタイプを検討します。

バックアップ

現在、これらは企業セグメントで最も一般的なストレージシステムです。 それらのほとんどのアーキテクチャは、従来のストレージシステムの開発の結果であり、原則として、従来のバックアップツール（EMC Networkerおよびその類似製品）と組み合わされていました。 従来のストレージシステムはハイブリッドシステムに変化し、バックアップへのアプローチはほぼ同じままです。 すべてが従来のシステムである場合、これらのシステムのバックアップの問題は何ですか？









典型的なハイブリッドストレージシステムには、高速、中、低速のメディアが含まれます。



誰かがすでに、この問題は「最下位」のデータが「移動する」ストレージの最低レベルにあると推測しました。 経済的な理由から、このレベルは非常に少数の大容量ディスク（NL-SAS、7200 rpm、1〜6 TB）で構成される場合があります。



自動階層ストレージのハイブリッドシステムで2TBを超えるNL-SASドライブを使用しないでください。 誘惑に抵抗してください。 そして、ここに理由があります。



システムを容量とパフォーマンスのために設計した場合、すべてが何らかの形でバックアップで落ち着くと仮定するのは間違いです。



3層システムを設計する場合、下位レベルから、バックアップからレポート作成まで、さまざまなタスクのためにデータを迅速に上げる必要があることを覚えておく必要があります。



数百TBのデータベース用のハイブリッドストレージシステムの設計には、悲しい規則性に直面する必要があります。 時には、そのようなボリュームのMS SQLデータベースを作成し、電子文書をデータベースにまとめます。 同時に、バックアップにかかる時間については誰も考慮していません。また、層は6TBディスク上でより低いレベルのマルチレベルストレージを規定しています。 場合によっては5400 rpmでも安くなります。



ディスクのセットが不良ではない小規模なハイブリッドシステムを考えます。

• RAID 5（7 + 1）の16個の200GB SSDドライブ
• RAID 1の32 600GB 15,000 rpmドライブ
• RAID6（6 + 2）の8つの2000GB 7200 rpmドライブ

10進数の容量（RAIDを含む）：

• SSD-2800 GB
• SAS 15000 rpm-9600 GB
• NL-SAS 7200 rpm-24000 GB

合計36,400 GB。



生のパフォーマンス：

• SSD 16 * 3500 = 80,000 IOPS
• SAS 15000 rpm 32 * 180 = 5760 IOPS
• NL-SAS 7200 rpm 8 * 80 = 640 IOPS

合計86,400 IOPS。



このようなシステムのボリュームとパフォーマンスはわずか56枚のディスクで印象的でした。 これで、これらすべてが60個のディスクの1つのディスクシェルフに収まります。 最悪の場合、15個のディスクの4つのシェルフ。



自動階層化技術を使用しない同様の「フラット」システムは、480個の15,000 rpmディスクで構成され、大幅に多くの電力を消費し、より多くのスペースを占有します。 「ハイブリッド」アプローチの経済的利益は明らかです。



もちろん、ここでは、ワークロードプロファイルに応じたこのシステムの設計が正しく選択され、ホットデータとコールドデータが正しく「落ち着いた」ことを認めています（この興味深い問題の解決策は、別の非常に興味深い記事のトピックです）。



次に、このような「うまく設計された」ハイブリッドシステムのバックアップがどのように発生するかを正確に検討したいと思います。 従来のバックアップを使用しているとします。 つまり 金曜日の夜に完全バックアップを行い、その後、一連の増分バックアップを行います。 そして毎週。



ゼロ次近似で、生産的な負荷がない場合に、ハイブリッドシステムから36 TBの完全バックアップにかかる時間を計算してみましょう。











この計算は、バックアッププロセス中に他のボトルネックがなく、ストレージコントローラーもターゲットバックアップシステムもディスクがバックアップ用のデータを提供することを妨げないという仮定に基づいています。



図から、低いストレージレベルはバックアップ時間の94％を「食べ」、7日間かかったことがわかります。 これは受け入れられません。 実際、これは階層型ストレージを使用した結果です。 アプリケーションのパフォーマンスは、上位レベルの速度とそのボリュームによって決まります。 そして、バックアップ（およびリカバリ！）の速度は、下位レベルとそのボリュームの速度です。 これは、ハイブリッドシステムが実際の生活にほとんど適応していないことを意味しますか？ 誰かがイエスと言うでしょう。 しかし、ストレージ効率の観点からそれらを使用すると、非常に大きな利点が得られます。 したがって、操作のルールを再考し、常識に従う必要があります。



ハイブリッドシステムには次のソリューション（またはそれらの組み合わせ）があります。



最初のもの。 大量のデータの完全バックアップを拒否します。 合成完全バックアップに移動し、バックアップを適時に配布します。 つまり 特定の時間間隔で送信されるデータの量を減らします。 このオプションの利点は、条件付きの低コストです。



大きな欠点は、リカバリを完了するための時間です。 ここでは、合成がバックアップであったかどうかは関係ありません。 下位レベルでもデータを完全に入力する必要があります。 これにより、毎日のデータ損失に約1週間のダウンタイムが追加されます。



二番目。 下位レベルをそれほど遅くならないようにしてください。 結局のところ、1 TBのドライブで構成することができ、GBあたりの価格で、2 TBと同じ価格カテゴリーに属します。 許容可能なバックアップ時間を確保するために、追加のスピンドルをより低いストレージレベルに正確に配置できます。 これについて事前に考える必要があります。 つまり バックアップのためのデータの「戻り」の速度を上げ、潜在的な回復の速度を計画します。



これは最初のオプションよりも少し高価ですが、数倍高速になる可能性があります。 最初と2番目のオプションは自由に組み合わせることができます。



3番目 。 階層化ボリュームの階層3ストレージの100％リサイクルを避けます。 結局、100％ではなく15〜20％の「戦闘」データで満たすことができ、残りの80％は、たとえば、より頻繁にバックアップできないアーカイブデータに割り当てられます。 これは、アーカイブデータと運用データの根本的な違いです。 まだ奇妙に聞こえるかもしれませんが、アーカイブとバックアップは根本的に異なります。 アーカイブは、オンラインストレージからそこに移動される不変データの長期ストレージです。 バックアップとは、リカバリのために定期的に作成される運用データのコピーです。 つまり、アーカイブは移動操作であり、バックアップはコピーです。 アーカイブの詳細については、EMC Webサイトをご覧ください 。









アーカイブとバックアップの組み合わせ。



4番目。 上記のすべてで状況を大幅に改善できない場合は、バックアップの基本的なアプローチを修正する価値があるかもしれません。 長い間、たとえばAvamarやVmware Data Protection Advancedなど、ソースにデータ重複排除を備えたバックアップシステムがあります。 このテクノロジーは、クライアントとバックアップサーバー間で転送されるデータの量を非常に効果的に削減します。 別の選択肢は、スナップショットを使用した別のストレージシステムへのデータの連続レプリケーションです。 たとえば、RecoverPointを使用します。



ご覧のとおり、ハイブリッドストレージシステムを設計する際には、バックアップコンテキストを考慮する必要があります。 ストレージとバックアップが異なるプロジェクトであっても。

回復

自動階層ストレージを備えたシステムがあり、そこからバックアップを正常に作成できると想像してください。 さらに、設計プロセスでは、復旧の速度を考慮しましたが、これも深刻な問題を引き起こしません。



アプリケーションはハイブリッドストレージシステム上で実行され、十分なパフォーマンスが得られます。 ただし、現代の環境では、ほとんどの負荷がごく少量のデータにかかっていることを思い出してください。











問題は、半日前に行われたバックアップからの正常なリカバリ後、アプリケーションがどの速度で動作するかということです。 IBSからの回復時に、データブロックが障害前の「温度」に正確に従ってメディア上で必ずばらばらになることを保証するものはありません。 最新の「ホット」データはストレージキャッシュではなく、データベースサーバーとアプリケーションのRAMにあり、バックアップからデータを復元するときに、すべてのメモリをゼロから「ウォームアップ」する必要があることを考慮すると、ディスクシステムの負荷は引き続きいつもより高い。 状況は快適ではありません。



一部の場所のハイブリッドストレージシステムは、ストレージの問題を解決するためのほぼ標準的なアプローチになっているため、障害後の潜在的な回復の問題は繰り返し発生し、運用中の管理者の前に生じると思います。



人々が毎日バックアップに出くわすと、本格的なリカバリが何百倍も少なくなると思います。 したがって、実際にここで検討したシナリオに遭遇すると、これは不快ではあるが、非常に予測可能なイベントであることがわかります。 おそらくそれを事前に予測して検討する価値がありますか？



しかし、バックアップを設計するとき、データのコピー/復元について話しているため、リカバリ後のパフォーマンスは保証されないため、このトピックはほとんどの場合、アーキテクトの注意のどこかに残っています。 そして、このプロジェクトにどの予算を融資すべきかは明確ではありません。 バックアップまたはストレージ？ おそらくそれが、アーキテクチャを計画するときにこの主題に関する明確で正確な推奨事項をまだ思いついていない理由です。 どうやら、多くの人は、回復の主なことは回復することだと考えています。 そしてさらに-これらは小さなニュアンスです。



ここで、バックアップからのデータの正常な回復がアプリケーションの正常な起動を許可しなかった場合があることに注意する必要があります。 数百および数千のユーザーが文字通り「加熱されていない」ストレージシステムに「侵入」し、正常にいっぱいになり、アプリケーションサーバーがcom睡状態になり、場合によってはデータを破損することさえありました。 ハイブリッドシステムはもちろん、従来のストレージシステムでも同様の状況が発生します。











したがって、完全バックアップからの復元は最後の手段であることに注意してください。 そして、あなたが本当にそれに頼るなら、あなたは完全な能力でアプリケーションの即時リリースを期待するべきではありません。 また、ほとんどの場合、しばらく前にデータのロールバックに関連する組織の問題を解決する必要があります。 しかし、これは技術サポートの問題を議題から取り除くものではありません。

問題解決

ハイブリッドシステムを含むすべてのディスクシステムに典型的なこの問題を解決するために何をアドバイスできますか？



まず 、ストレージシステムを加熱する可能性を検討します。 一部のハイブリッドストレージシステムのアルゴリズムは、キャッシュメモリの拡張としてFlashを使用し 、数分でアプリケーションのニーズに対応できますが、バックアップからの回復後、低速ディスクから高速ディスクにデータを回復するのに少なくとも3日必要なものもあります。 そのため、ハイブリッドシステムの応答があまり速くない場合は、低速ドライブで無理をしないことが重要です。 これらは、負荷がかかったときにシステムが「ウォームアップ」する能力を大幅に制限する可能性があります。



2番目 ：外部IBSへのバックアップは、最後の手段である「プランB」であり、他に何も機能していない場合は常にそうです（ 別の記事を参照 ）。 したがって、データ回復後のアプリケーションの速度の不確実性を最小限に抑えるために、データをより「ポイント単位」、「ブロック単位」で回復できるオンライン回復ツールを使用します。



ストレージレベルでのレプリケーション（クローン、スナップショット）とアプリケーションレベルでのレプリケーション（Data Guardなど）の両方について説明しています。 このアプローチにより、リカバリ時間とデータ損失が最小限に抑えられるだけでなく、リカバリ後の予測可能なパフォーマンスの面で管理者の神経が節約されます。 つまり、外部デバイスへのバックアップとデータ複製を組み合わせて、目的を実現するのが最善です。



3番目 ：最初の2つの規定が考慮されているが、さらに必要な場合は、同期の耐クラッシュ性クラスターペアで動作する2つのハイブリッドシステムを使用できます。 ストレージシステムの1つが完全に故障していても、データの損失やアプリケーションのシャットダウンは発生せず、障害が発生したシステムを復元した後、クラスターは両方のシステムのレベルでデータとその配置を同期できます。



一般に、適切なバックアップはアプリケーションレベルだけでなく、生産性の高いストレージシステムとも統合し、スナップショットと同様に個々のデータブロックのバックアップと復元の両方を行える必要があるという意見を共有しています。 そして、この傾向については現在、バックアップ市場で観察されているようです。



これらの考慮事項において、私は意図的にハイブリッドストレージシステムの保護と復元のみを遵守しました。 フラッシュシステムの問題については、次のいずれかの記事で説明します。 お楽しみに！





デニス・セロフ