アクティブ リストア: 災害復旧をより迅速に行うことはできますか? はるかに高速？

重要なデータをバックアップすることは良いことです。 しかし、作業をすぐに続行する必要があり、一刻を争う場合はどうなるでしょうか? アクロニスでは、システムをできるだけ早く起動するという問題を解決できるかどうかを確認することにしました。 これは、Active Restore シリーズの最初の投稿であり、私たちがイノポリス大学と協力してプロジェクトを開始した経緯、見つけたソリューション、そして現在取り組んでいることについて説明します。 詳細はカット中です。

こんにちは！ 私の名前はダウレット・トゥンバエフです。今日は、災害復旧を迅速化するシステムの開発における私の経験を共有したいと思います。 プロジェクトの開発過程全体について話すために、少し離れたところから始めましょう。 私は現在 Acronis で働いていますが、イノポリス大学の卒業生でもあり、ソフトウェア開発管理の修士課程 (MSIT-SE として知られています) を修了しました。 イノポリスは若い大学であり、カリキュラムはさらに新しいものです。 しかし、それはカーネギーメロン大学のカリキュラムに基づいて構築されており、その研究には産業プロジェクトなどのテーマが含まれています。

産業プロジェクトの目的は、学生を実際の開発に没頭させ、得た知識を実践で定着させることです。 これを実現するために、大学は Yandex、Acronis、MTC、その他数十社の企業と協力しています (2018 年の時点で、大学には合計 144 社のパートナーがいました)。 協力の過程で、企業は自分たちの作業領域を大学に提供し、学生はその中から自分の興味や訓練レベルに近いプロジェクトを選択します。 文字通り XNUMX 年前、私はまだ「バリケードの向こう側」にいて、学生として別の Acronis プロジェクトに取り組んでいました。 しかし今回、私は企業側の学生向け技術コンサルタントとなり、Innopolis に Active Restore プロジェクトを提案しました。 Active Restore のアイデアそのものは、Acronis のカーネル チームによって策定されましたが、ソリューションの開発はイノポリス大学と共同で始まりました。

アクティブ リストア - なぜ必要なのでしょうか?

従来、災害復旧は標準的なスキームに従って機能します。 コンピュータに問題が発生した後、Acronis True Image などのバックアップ システムの Web インターフェイスにアクセスし、大きな「復元」ボタンをクリックします。 次に、N 分間待つ必要があります。その後、作業を​​続行できます。

問題は、RTO (目標復旧時間) とも呼ばれるこの数値 N は、許容可能な復旧時間であり、接続速度 (クラウドから復旧する場合)、マシ​​ンのハード ドライブのサイズに応じて非常に大きくなる可能性があることです。 、その他多くの要因が考えられます。 減らすことは可能でしょうか？ はい、可能です。作業を再開するために、必ずしも完全なコンピュータ ディスクが必要なわけではありません。 同じ写真やビデオはデバイスの機能にはまったく影響を与えず、後でバックグラウンドで取得できます。

ドライバーが必要です...

オペレーティング システムは、ディスクが完全に準備された状態で起動することを想定しています。 したがって、Windows はディスクの整合性を確認するために一連のチェックを実行します。 OS が期待するファイルが見つからないか破損している場合、システムは通常の起動を許可しません。 この問題を解決するために、私たちが作成した、いわゆるリダイレクター ファイルをディスク上に配置することにしました。これは、欠落または破損したファイルを置き換えるものですが、実際にはダミーです。 このようなリダイレクターには実際にはコンテンツがないため、作成にはそれほど時間はかかりません。

さらに復元は次のように行われます。 オペレーティング システムの動作と並行して、バックグラウンド プロセスによって「ダミー」にデータが埋め込まれます。 バックグラウンド回復プロセスではディスク負荷が考慮され、設定された制限を超えることはありません。 ただし、ユーザーまたはオペレーティング システム自体が、まだ存在しないファイルを突然必要とする場合があります。 ここで XNUMX 番目の回復モードが登場します。 要求されたファイルの優先度が最大に引き上げられ、回復プロセスによってファイルがディスクに緊急にロードされます。 オペレーティング システムは、わずかな遅れはありますが、必要なファイルを受信します。

理想的な写真はこんな感じです。 しかし、現実の世界には、膨大な数の落とし穴や潜在的な行き詰まりが存在します。 私たちはイノポリスの修士課程の学生たちと協力して、この回復シナリオを調査し、RTO の向上を評価し、そのようなアプローチが実現可能かどうかを理解することにしました。 結局のところ、当時はそのようなソリューションが市場に存在しませんでした。

そして、サービス コンポーネントを Innopolis の人たちに提供することに決めた場合、Acronis 内で作業が始まりました。 ファイル システム ドライバーによるミニフィルター。 これは Windows カーネル チームによって行われました。 計画はこんな感じでした。

• OS起動の初期段階でドライバーを起動し、
• 仕事中、いつ ユーザー空間 完全に準備が整ったので、サービスをダウンロードしてください
• このサービスはドライバーの要求を処理し、その後の作業を調整します。

ドライバーエンジニアリングの繊細さ

私の同僚がこのサービスについて別の投稿で話す場合は、このテキストでドライバー開発の複雑さを明らかにします。 すでに開発されたミニ フィルター ドライバーには、システムが通常モードで起動したときと、システムに障害が発生して復元中のときの XNUMX つの動作モードがあります。 ユーザー ライブラリとアプリケーション、つまりサービスをロードする前に、ドライバーは同じように動作します。 彼はシステムが現在どの状態にあるのか知りません。 その結果、すべての作成、読み取り、書き込みがログに記録され、すべてのメタデータが記録されます。 サービスがオンラインの場合、ドライバーはこの情報をサービスに提供します。

通常の開始の場合、サービスはドライバーに「リラックス」信号を送信してドライバーを「リラックス」させ、すべてのデータの綿密なログ記録を停止します。 この場合、ドライバーはディスク上の変更のみをログに記録するように切り替え、サービスに変更を報告します。サービスは、他の Acronis ツールを使用して、ユーザーが指定したメディア上にディスク バックアップを最新の状態に維持します。 これは、クラウド、リモート、段階的または夜間のバックアップにすることができます。

回復モードが有効な場合、サービスはドライバーに「回復」モードで動作する必要があることを伝えます。 システムはクラッシュから回復したばかりで、ディスク上のファイルを開くリクエストを行うとすぐに、ミニフィルターがこの操作をインターセプトし、このリクエスト自体を作成し、そのようなファイルがディスク上に存在するかどうかを確認する必要があります。開けることができます。

ファイルが見つからない場合、ミニフィルターはこの情報をサービスに送信し、ファイル回復の優先順位を高めます (この間、回復は常にバックグラウンドで行われます)。 このファイルは単にキューの先頭にジャンプしているだけであることがわかります。 この後、サービス自体 (またはアクロニスの他の手段) がこのファイルを復元し、すべてが正常であることをドライバーに伝えます。これでオペレーティング システムがファイルにアクセスできるようになり、ドライバーは元のリクエストをシステムからディスクに「解放」します。

回復が不可能な場合、サービスはファイルがバックアップにないことをドライバーに通知します。 私たちのミニフィルタードライバーはシステムリクエストをさらに渡すだけで、元のリクエスター (OS 自体またはアプリケーション) は「ファイルが見つかりません」エラーを受け取ります。 ただし、ファイルが実際にディスク上にもバックアップ内にも存在しなかった場合、これはごく普通のことです。

もちろん、ファイルやライブラリの読み取りは複数の段階で行われ、場合によってはリモート リソースへのアクセスも行われるため、オペレーティング システムの動作は大幅に遅くなります。 ただし、ユーザーは回復がまだ行われている間、できるだけ早く仕事に戻ることができます。

もっと低く、さらに低くする必要があります...

プロトタイプはその機能性を証明しました。 しかし、場合によっては依然として行き詰まりが存在するため、先に進む必要があることもわかりました。 たとえば、オペレーティング システムは複数のスレッドでさまざまなライブラリを要求する可能性があり、これによりサービスが自身でループバックすることになります。

私が現在取り組んでいる問題は、Active Restore の速度を向上させ、システム セキュリティのレベルを高めることです。 システムがファイル全体を必要とするのではなく、ファイルの一部だけを必要とするとしましょう。 この目的のために、別のドライバー、ディスク フィルター ドライバーが開発されました。 ファイル レベルでは機能しなくなり、ブロック レベルで機能します。 動作原理も同様です。通常の動作モードでは、ドライバは変更されたブロックをディスクに記録するだけですが、リカバリ モードでは、独自にブロックの読み取りを試行し、失敗した場合はサービスに優先順位を上げるように要求します。 ただし、システムの他の部分はすべて同じままです。 たとえば、OS レベルのサービスは、動作に必要なデータを正確に OS に提​​供することが主なタスクであるため、別のドライバーとの通信を要求されているとは考えません。 サービスがブロック レベルでの考え方をまだ理解していないという理由だけで、この領域には大幅な改善が必要です。

次のステップでは、ドライバーをより深く、より早く起動し、サービスではなく UEFI ドライバーとネイティブ Windows アプリケーションのレベルまで降下することにしました。 この目的のために開発されました UEFIブートドライバー (または DXE ドライバー)、OS が起動する前でも起動して終了します。 ただし、UEFI ドライバーの「歴史」、アセンブリとインストールの詳細、および Windows ネイティブ アプリケーションの詳細については、次の投稿で説明します。 ですから、私たちのブログを購読してください。それまでの間、私は仕事の次の段階についての話を準備します。 コメントやアドバイスをいただければ幸いです。

登録ユーザーのみがアンケートに参加できます。 ログインお願いします。

回復に耐え難いほど長い時間がかかった状況に遭遇したことはありますか?

• 視聴者の３８%がはい28

• 視聴者の３８%がNo10

• 視聴者の３８%が考えもしなかった5

43 人のユーザーが投票しました。 3名のユーザーが棄権した。

出所： habr.com