バックアップ-一貫性のないケンタウロスに対する仮想クローン

または、仮想マシンのクローン作成を使用してサーバーを停止せずに一貫したバックアップを作成する簡単な方法

真空での完璧なバックアップ

サーバーにデータバックアップを設定するシステム管理者は、想像力の中で美しい画像を描きます。 バックアップスクリプトは、データを安全にアーカイブに保存し、安心をもたらします。 大変動が発生し、その結果、ディスク上の情報が単一のユニットなしでゼロの連続した連続になります。 パニックは成長しており、監督は銃でオフィスに閉じ込められています。 そして、ここで主人公が現れ、最後のバックアップからデータを落ち着いて復元し、30分後には何も起こらなかったかのようにサーバーが動作します。 荘厳な音楽に、主人公は日没になります。

大まかな現実は調整を行います。コピーの設定時にささいなことを多く提供しないと、リカバリ中に、バックアップのデータの一部が理解できない方法で破損する可能性があります。 簡単なリカバリは、異なるアーカイブ内のピースを探すのに苦労し、1つの全体からそれらを収集することになります。 コピーの一貫性が壊れているため、日没への出発は延期されます。

不整合をコピーする

コピーの不整合という概念は、ある時点での元の状態を反映する単一のデータ配列ではなく、異なる時点での元の対応する部分の状態を反映する複数の部分で構成されることを意味します。

たとえば、2つの異なるファイルで同じカウンタを同時に増やした場合、一貫性のないコピーでは、これらのファイルの値が不一致になる可能性があります。 別の例として、馬を持つ男が道路を歩いているときにコピーすることにした場合、一貫性のないコピーでは、道路に沿って彼らの代わりに1匹のケンタウロスがいます。

ケンタウロスが来る方法

最も簡単で一般的なバックアップ方法は、ファイルシステムのファイルごとのコピーです。 アーカイブは、tarまたはcpioによって作成された完全なコピー、またはdump、rsync、baculaを使用した増分を保存できます。 ファイルシステム内のすべてのファイルはバイパスされ、特定のルールに準拠しているかどうかが確認され、アーカイブにコピーされます。

一貫性違反の最初の明白な理由は、コピー中に発生するファイルの変更です。 サーバーは通常のタスクを実行し続け、ファイルが作成、更新、削除されます。 コピーが長く続くほど、すべてのデータのボリュームが大きくなり、元のデータの変化率が大きくなります-コピーの不整合が大きくなります。 場合によっては、これはそれほど重要ではありません。たとえば、企業のWebサイトが夜間にコピーされ、その時点でログのみが変更される場合です。 ただし、SVNリポジトリへの変更がその時点で記録されていた場合、SVNがトランザクションを使用するという事実にもかかわらず、そのようなバックアップから回復した後、任意のコンポーネントのバージョンの損失または混合が発生する可能性があります。

クローンの作成方法

この問題を解決するために、ディスクまたはファイルシステムのクローン、スナップショットという一般的なスキームがあります。 その実装は異なる可能性があります-たとえば、ファイルシステム自体の手段をUFSおよびZFS、またはそれ以下、LVM / DeviceMapperまたはVHDのブロックデバイスで使用します。 ユーザーの側では、適切なタイミングでオペレーティングシステムがファイルシステムまたはブロックデバイスの2番目のコピーを作成するように見えます。 スナップショットの作成にかかる時間はごくわずか（数ミリ秒から数秒）であるため、アプリケーションの操作に影響を与えることなく、すべての記録操作がブロックされます。 スナップショットの作成中、変更は発生せず、コピーは一貫しています。

スナップショットはバックアップとして適していますか？ 短期的なニーズについては、はい。 たとえば、危険な更新の前に、スナップショットを作成しておくと便利です。何か問題が発生した場合は、このスナップショットの状態をロールバックします。すべてがうまくいけば、スナップショットを削除できます。 スナップショットの使用には代償が伴います-ディスク操作が遅くなり、ディスク容量の消費が増加します。 したがって、スナップショットを長期間使用すると、パフォーマンスが失われるよりも多くの利点が得られます。 スナップショットは元のスナップショットと同じ場所にあるため、バックアップには適していません。 オリジナルが影響を受ける場合、コピーも影響を受ける可能性があります。

バックアップでは、スナップショットは変更されていないファイルシステムとして使用され、必要な限りリモートストレージにコピーでき、コピーの最後のコピーの一貫性は侵害されません。 コピーは同じdump / tar / rsync / baculaで実行できます。 スナップショットが使用されると、リソースが無駄にならないように削除されます。

サーバーデータの一貫性

これはクリーンリカバリの問題を解決しますか？ 部分的にのみ。 ファイルシステムの一貫したコピーを取得しますが、すべてのサーバー情報の一貫したコピーを取得するわけではありません。 結局のところ、RAM内のデータを操作してディスクに保存するアプリケーションがまだあります。 メモリでは、アプリケーションデータは一貫していますが、ディスクには書き込まれません。 情報は、アプリケーションとオペレーティングシステムにとって便利な順序でファイルに書き込まれます。 この順序に関するバックアップシステムの観点は、アプリケーションにとって重要ではありません。 コピーの状態は、突然のシャットダウン（停電など）後のサーバーディスクの状態に対応します。

Webプロジェクトの場合、矛盾の潜在的な犠牲者はMySQLデータベースです。 多数のデータ更新があるアクティブなプロジェクトがあり、データが常にテーブルに書き込まれているとします。 データベースサーバーは、テーブルデータをRAMに保持し、定期的に変更をディスクにフラッシュします。 オペレーティングシステムもこれに参加します。これにより、パフォーマンスを向上させるために必要なものに関する独自の考慮事項に基づいて、書き込みバッファ内のデータが遅延する可能性があります。 この時点でファイルシステムの一貫したコピーを作成すると、異なるテーブルに異なる時点で関連するデータが存在する可能性があり、一部のテーブルでは、その時点で別の場所に転送された場合、データの整合性が侵害される可能性があります。

これにより、サーバー上のデータを変更する各アプリケーションの機能を考慮する必要が生じます。 また、バックアップを作成するプロセスを適応させるために、データを変更する各アプリケーションに、コピーを作成する前にディスクに保存するように強制し、コピー中にデータを変更しないようにします。 MySQLサーバーの場合、これは1つのFLUSH TABLES WITH READ LOCKコマンドでディスクへの変更を書き込みおよび破棄するためにテーブルをロックし、 UNLOCK TABLESコマンドでコピーを作成した後にテーブルをロック解除します。 また、動作が不明なサードパーティのコンポーネントを備えたJavaベースのアプリケーションである場合、状況は複雑であり、アプリケーションは完全に停止します。 Windowsアプリケーションの場合、特別な静止メカニズムが提案されます。これにより、オペレーティングシステムは、バックアップを開始しており、データをディスクにダンプするか、何らかの形でディスクに一貫性のある状態にする必要があることをアプリケーションに知らせます。

実際には、バックアップを設定するときに見落とされることが多いのはこの部分です。または、システム管理者（または開発者）は、自分の状況のリスクがわずかであり、コピーシナリオを複雑化する追加コストの価値がないと考える場合、追加設定を意識的に拒否します。

仮想マシンの仮想クローン

近年、デスクトップとサーバーの両方で仮想マシンが親しまれています。 進歩は人々の生活をより快適にします。 また、システム管理者の生活をより快適にします。 サーバー仮想マシンは、機器の抽象化、ハードウェアリソースの効率的かつ高密度の使用、少数の物理サーバーに統合された多数の機能的に異なるサーバーの便利な管理に便利に使用できます。 また、仮想化により、神話上の生き物や素晴らしいミュータントなしで、完璧なバックアップを作成できます。

多くの仮想化環境では、実行中の仮想マシンのスナップショットを保存できます（ディスクとは異なり、メモリスナップショットとディスクスナップショットを混同しないように、チェックポイントという用語はスナップショットよりも頻繁に使用されます）。 基本的に、それらは開発およびテスト用に設計されており、たとえば、更新前に動作中のサーバーの状態を保持して、失敗した結果がロールバックされるようにします。 バックアップに関しては、メモリとディスクのスナップショットは、すべてのサーバーデータの一貫したコピーです。 したがって、完全なバックアップを取得するためのツールがあり、それを正しく適用する必要があります。

Citrix XenServer（XenServer Freeを含む）およびXCPは、 xe vm-checkpointコマンドを使用して、メモリとディスクを備えた仮想マシンのスナップショットを取得します。 スナップショットの作成中、仮想マシンは一時停止され、完了後も継続されます。 スナップショットは準備が完了してストレージにありますが、その形式では、バックアップとしての価値はわずかです。ディスクのスナップショットの場合のように、オリジナルとともに保存されているものはオリジナルとともに苦しむことがあります。 どこにでも保存できるコピーを取得するには、 xe vm-exportコマンドを使用する必要があります。このコマンドは、出力で、仮想マシンのメモリとディスクをxvaファイルに保存します。

xend + xmの形式のXen Hypervisor 4は、LVMにマシンディスクを配置する場合、ほぼ同じことを実行できます。 標準のxm save -cコマンド（チェックポイントから保存）を使用すると、メモリのスナップショットを保存してから仮想マシンを続行できます。 ディスクスナップショットは、他の誰かがそれを行うことを想定して作成されません。 頭に浮かぶ最初の決定は、ドメインを一時停止し、ディスクのスナップショットを作成し、その後でのみ仮想マシンのスナップショットを作成することです。 しかし、ドメインは保存されるため、パスされないため、Xenでは動作状態になっている必要があります。 この問題を解決するには、いくつかの方法があります。最終的に、最も便利なオプションは、xendを少し変更することです（Xen 4.0を使用してDebian 6の短縮パッチを取得し、必要に応じて必要に応じて変更できます： www.truevds.ru/misc.xen-checkpoint -clone-patch ）。 これを行うには、チェックポイントの作成を担当する関数のコードで、ディスクのスナップショットが保存された仮想マシンの構成で使用され、元の仮想マシンではなく、仮想マシンを再開する前に標準のLVMの方法でこれらのスナップショットを作成することを示すだけで十分です。 その後、仮想マシンのメモリのスナップショットを含むファイルと、ディスクのスナップショットを含むLVMパーティションが作成されます。

Xenベースの仮想化システムに加えて、VMWareとHyper-Vは同様の機能を提供します。 彼らの用語では、チェックポイントはスナップホストと呼ばれます。

良いクローン-オフクローン

小さいデータを持つ小さなサーバーの場合、仮想マシンのメモリとディスクの完全なコピーをアーカイブに保存することはそれほど高価ではありません。 たとえば、8 GBのRAMとディスク上に約100 GBのデータがある訪問サイトの本番サーバーでこのスキームを使用しようとすると、コピーあたり108 GBのネットワーク転送とストレージにより、予約価格がすぐに高くなります。

多数のアーカイブコピーを保存する最も便利な方法は、増分バックアップです。 次のコピーでは、アーカイブはファイルシステムの完全なコピーを記録せず、前のコピーの後に発生した変更のみを記録します。 そのためには、サーバーの一貫したデータが保存されている一貫したファイルシステムが必要です。

ディスク上のデータがアプリケーションによって可能な限り正しく保存され、RAM内で変更されない唯一のサーバー状態があります。 この状態は、正しく停止したサーバーです。 少なくとも何らかの方法でデータの安全性に注意を払うすべてのアプリケーションは、オペレーティングシステムが作業を完了するように要求したときに、停止スクリプトまたはSIGTERMシグナルを送信することで評価し、すぐに従います。 この方法で停止したサーバーのファイルシステムは、すべてのサーバーデータの可能な限り最高の一貫した状態です。

この状態のファイルシステムが必要です。 クローンがあります-仮想マシンのスナップショットとディスクのスナップショットです。 クローン仮想マシンを起動し、そのオペレーティングシステムにシャットダウンコマンドを与える必要があります。 XenServer / XCPでは、このためにxe snapshot-copyコマンドでxe snapshot-copyテンプレートに変換してから、このテンプレートで新しいマシンを起動する必要があります。 Xen Hypervisorは、 xm restore介してマシンを起動するのに十分です。

クローンはオリジナルを傷つけないようにする必要があります。 クローンは、独自のスナップショットをディスクとして使用します（xend / xmでは、これはデフォルトではありませんが、仮想マシンのスナップショットを保存する前述のパッチで修正されます）-元のディスクはクローンにアクセスできません。 ただし、オリジナルがネットワークで機能する場合、クローンには同じ設定のネットワークインターフェイスがあります。 オンにすると、外の世界と通信する権利を得るために、クローンとオリジナルの間で競合が発生します。 そのため、クローンのネットワークインターフェイスは、実際のネットワークに入らない別の仮想ネットワーク内で非アクティブ化または分離する必要があります。 サーバーを停止する方法は、サーバーの構成方法に依存し、ほとんどの場合、 xm shutdowコマンドでPVマシンに十分であり、HVMのACPI電源オフになります。

切断後、クローン仮想マシンは削除できますが、ディスクのスナップショットはまだ完全に停止しています。 純粋な一貫性を持つファイルシステムになります。 通常のディスクスナップショットがコピーされるのと同じ方法で、安心してアーカイブに送信できます。

勝利価格

クローンを実行するにはRAMが必要であるという事実に関連する小さな問題がありますが、これは突然十分ではありません。 メモリが保存されている間、マシンの動作は一時停止されます。 彼らの決定は特定の状況に依存します。 たとえば、まともな人々として夜に予約をすると、写真の前の元のメモリの半分を簡単に取得し、解放された半分でクローンを開始できます。 xendを少し修正すると、仮想マシンを一時停止しなくてもメモリのスナップショットを取得できます（XCPではこれも技術的に可能です。開発者はまだ手をつけていない可能性が高いです）。

負荷の高いインターネットプロジェクトのためにサーバーを仮想マシンに移行することは不要です。 同じタイプのサーバーが数十または数百ある場合、アプリケーションツールを使用して最小の詳細までデバッグし、バックアップ手順を統合してから、仮想化のオーバーヘッドにリソースのわずかな割合を費やすよりも何度も実行する方が実用的です。

小規模なインターネットプロジェクトまたは企業サーバーの混合セットの場合、仮想化を使用してクリーンバックアップを編成するコストは、ほとんどの場合最低です。 その結果、さまざまなアプリケーションのバックアップスクリプトを適合させることなく、通常の一貫したサーバーバックアップを作成する機会が得られます。 これにより、コンポーネントのいずれかが忘れられたり、機能しなくなるリスクが軽減されます。 10分でサーバーを復元したヒーローは、ケンタウロスになる危険を冒すことなく、馬に乗って日没に飛び込みます。