Amazon Web ServicesでデータとMySQLをバックアップする方法

みなさんこんにちは！
Amazon Web ServicesでファイルバックアップとMySQL / XtraDBを整理した経験を共有したいと思います。 特に、クラウドにプロジェクトを展開するように「強制」されており、時間が限られている場合、情報が役立つことを願っています:-)
しかし、まず、Amazonが提供するデータストレージテクノロジーについて簡単に説明します。

仮想マシンのデータはどこにありますか？

それでは、Amazonが提供する仮想マシンデータの保存から始めましょう-仮想EBSブロックデバイス。 このようなディスクは簡単に作成され、2回のクリックでサーバーに接続されます。 最大ディスクサイズは1TBです。 デフォルトでは、5000ドライブと20TBに制限がありますが、最初のリクエストで増加します。
ローカルブロックデバイスの技術も提案されており、そのデータは...サーバーと共に消えます（マシンがクラッシュすると簡単に発生します）-しかし、私はそれについては書きません。 私たちはそれを実験しませんでした。

EBSパフォーマンス

鉄よりも遅いことがすぐにわかります。 デバイスの飽和状態（％util、iostatコマンド）で、ランダムな読み取りボリュームが1ダースまたは2 MB / s（書き込みでさらに少ない）になると、すぐに100％に近づきます。 ブレーキは、フォルダをディスクからディスクにコピーする、アーカイブを展開するなどの一般的な操作で明確に表示されます。 部品とベンチマークはオンラインで簡単に見つけることができます。

襲撃？

Amazonディスクの操作を適切に開始するための最も簡単な方法は、ディスクをソフトウェアRAIDに「移動」することです。 データベースの場合、ext4とxfsの両方の8つのEBSディスクでraid-10を使用します。 ソフトウェアの襲撃は非常に簡単に行われ、長時間にわたって機能し、実際には壊れません。
空襲は、EBSドライブが突然クラッシュした場合に特に役立ちます。
それでも、一部のタスクではRAIDを使用しません。たとえば、MySQLバイナリログの保存、バックアップなどに使用します。また、nginxキャッシュの保存には、EBSディスクのraid0が正常に機能しました。

EBSドライブの信頼性

正直に言うと、Amazon EBSディスクでの作業の1年半は、落胆することはありませんでした（「悪い」、読み取りエラーなどの愚かなことはありません）...雷がAmazonのアイルランドのデータセンターに当たった場合を除いて-その後、複数のディスクが一度に飛びましたraid-10から:-)
ただし、Amazonがディスクの信頼性について書いていることを注意深く読んだ場合、RAIDともちろん定期的なバックアップを行う必要があることを理解できます。
Amazon EBSボリュームデータは、1つのコンポーネントの障害によるデータの損失を防ぐために、アベイラビリティーゾーンの複数のサーバーに複製されます。 ボリュームの耐久性は、ボリュームのサイズと、最後のスナップショット以降に変更されたデータの割合の両方に依存します。 例として、最新のAmazon EBSスナップショット以降に変更されたデータが20 GB以下で動作するボリュームは、0.1％から0.5％の年間故障率（AFR）を予測できます。故障とは、ボリュームの完全な損失を指します。 これは、一般に約4％のAFRで故障する市販のハードディスクと比較して、EBSボリュームの信頼性を一般的な市販のディスクドライブの10倍にします。
一方、100を超えるEBSディスクが実稼働環境にあり、1年半でIOのエラーが原因でソフトウェアの襲撃がディスクをノックアウトしたことはありません。 「鉄」ディスク上の複数のデバイスを変更したはずなので、結論を導きます。

利用可能なバックアップ技術

データが比較的小さく、頻繁に変更されない場合は、tarをいじることができます。 しかし、データベースとディスク上のファイルの両方にビジネス情報を保存する大規模なオンラインストアを想像してください。新しいファイルが毎分表示され、コンテンツの合計サイズは数百ギガバイトです。
DRBD？ はい、しかし彼らはAmazonでこのテクノロジーを試したことはありません。エラーが発生したときの驚異的なブレーキングについて同僚からよく耳にします。
copy-on-writeモードのLVMとスナップショットは、このテクノロジーに似ていますが、追加の特典があり、Amazonを提供します。 ブロックデバイスのスナップショットは、必要な回数だけ実行できます。 この場合：

1. 変更のみがEBSディスクの次のスナップショットに入ります。 さらに、これは完全に透過的であり、ディスク容量の使用に関する毎月の請求書を見ると明らかになります。 500GBのディスクから100枚のスナップショットを取得しても、データが頻繁に変更されることはありません。約600〜800GBを支払うので、もちろんクライアントに有利になります。
2. スナップショットを削除できます-バックアップウィンドウのサイズとデータストレージのコストのバランスを維持するために。 この場合、喜びが生じますが、任意のスナップショットを削除できます-Amazonは正しい方法でデータを自動的に統合します。 そして、それはトピックに関する私の頭を痛めません-どこで基本的なスナップショットであり、どこで増分スナップショットです-それは重要ではありません、あなたは任意の位置から余分なものを削除します（Acronisで働いた人は利便性を高く評価します）。
3. ディスクのスナップショットはS3に保存されます。 S3-おそらく誰もが既に知っているように、これは少なくとも2つのデータセンターにデータを複製する任意の形式のオブジェクトのリポジトリです。 つまり ディスクのスナップショットは実質的に「破壊不可能」になり、デスクトップの下のロックされたナイトスタンドにハードドライブよりも確実に保存されます:-)。
4. ディスクのスナップショットはほぼ瞬時に実行されます-その後、バックグラウンドで、データが一定時間（Amazonがロードされている場合は数十分）S3に転送されます。

つまり、ディスク上の頻繁に変更されるコンテンツの巨大なフォルダーのスナップショットを少なくとも5分に1回取得できることを意味します-それらはS3に安全に保存され、5分前に1 TBの可変データをロールバックする必要がある場合-これを簡単に行うことができます：

1. 保存されたスナップショットからディスクを作成します 。
2. ディスクをサーバーに接続します。

もちろん、S3からEBSディスクが存在するSANに1TBのデータを即座に転送することは技術的に不可能です。そのため、ブロックデバイスはオペレーティングシステムで利用可能になりますが、データは一定時間バックグラウンドでデータに流されます。したがって、最初にディスクを操作する速度はそれほど高くありません。 しかし、それでも、大量のデータの増分バックアップを作成して、たとえば1週間前に5分間隔で任意のポイントにロールバックするのがいかに便利かを同意する必要がありますか？ :-)
EBSドライブからスナップショットを作成する機能に加えて、S3にファイルを直接送信できます。 s3cmdユーティリティを使用すると便利です。ファイルシステムツリーをクラウドと双方向に同期できます（ローカルディスク上のmd5の計算と「ETag」のs3内のmd5オブジェクトのストレージに基づいて変更のみが転送されます）。 FUSE - s3fsテクノロジーに基づいたソリューションを試しましたが、集中的な使用中にLAが増加し、 速度の低下と長期的なフリーズに気づきました。

スナップショットレイド

上で書いたように、EBSディスクはraid0、raid10に結合された場合に十分なパフォーマンスを示します。 RAIDをバックアップする方法は？ 各ディスクのスナップショットは順番に実行されますか？ :-)それは不可能であり、アマゾンは私たちに何も提供しないことを理解しています。
善良な人々は便利なユーティリティ-ec2-consistent-snapshotを書きました。 それを使用するか、スクリプトでそのロジックを繰り返すことができます。

1. 「フリーズ」をサポートするファイルシステムを使用しています。 彼女は現在、ブロックデバイスレベルでスナップショットを取っていることに気付き、バッファをフラッシュし、トランザクションをコミットし、ブロックの変更を一時的に停止する必要があります。 最近まで、XFSはこのコマンド（ xfs_freeze ）を理解していましたが、 「最新の」Linuxディストリビューションでは、他の一般的なファイルシステム「ext3 / ext4、xfs、jfs、reiserfs」 を 「フリーズ」 できました 。
2. 変更を破棄し、FSへの書き込みを一時的に禁止します：“ fsfreeze -f mountpoint”
3. 各RAIDディスクのスナップショットの作成：AWS API呼び出しCreateSnapshot 。
4. FSエントリを許可する：「fsfreeze -u mountpoint」

xfsがある場合は、 xfs_freezeコマンドを使用できます。
保存したRAIDを接続するには、ディスクをマシンに接続し、そこからソフトウェアRAIDを起動するスクリプトを作成することをお勧めします。 上記の方法でスナップショットに保存されたRAIDは、ファイルシステムログを失うことなく美しく上昇します。本番環境のさまざまな場所で使用します。
そのため、少なくとも5分に1回の頻度で任意の量のデータを使用してs3でRAIDのスナップショットを作成し、それらからデータを回復する方法を学びました。 これらのことの多くは、クラウド内のさまざまなプロジェクトに役立つと確信しています。

マシン全体のスナップショット

各レイドで別々に入浴するのではなく、 1つのコマンドでマシンのすべてのドライブのスナップショットを作成する方が便利な場合があります。 スナップショットは2つのモードで作成できます。車の停止ありと停止なしです。 後者の場合、ディスク/レイド上のデータの「破損」の可能性について論理的に警告されます。
ファイルシステムのスナップショットを撮るときは、最初にアンマウントすることをお勧めします。 これにより、ファイルシステムのメタデータが一貫した状態になり、「マウントされたインジケータ」がクリアされ、そのファイルシステムを使用するすべてのアプリケーションが停止し、一貫した状態になります。 xfsなどの一部のファイルシステムは、アクティビティをフリーズおよびフリーズ解除できるため、マウント解除せずにスナップショットを作成できます。
マシンのスナップショットを作成した後、AMI（Amazon Machine Image）オブジェクトが表示され、各ドライブの保存されたスナップショットへのリンクがあります。 1つのコマンド-AWS API呼び出しRunInstancesを使用して、このオブジェクトからのすべてのディスク/ RAIDでサーバーを実行できます。 テクノロジーの力を感じましたか？ 稼働中のサーバーは、全体をバックアップできるだけでなく、1つのチームですべてのRAIDを使用して、バックアップの合計から解除することもできます。 このテクノロジーにより、昨年8月にAmazonで事故が発生した場合、数十時間のシステム管理が不要になりました。スナップショットからマシンを取り出し、別のデータセンターに構成を展開しました。
ただし、重大な落とし穴があります-CreateImageコマンドは完全に不透明で、すべてのサーバーディスクからスナップショットを取得するのに1秒または10秒かかりますか？ 科学的突撃の方法は、5秒間隔で選択され、レイドでマシンの完全な画像を撮影できます。 警告-運用を開始する前にスクリプトを徹底的にテストします-ただし、マシンの完全バックアップを作成する技術の「利点」の前に、抵抗するのは難しいことを認めなければなりません:-)

MySQLの増分バックアップ

私たちのタスクを思い出させてください-1日あたり数百万ヒットのトラフィックと非常に頻繁に変化する数百ギガバイトのコンテンツでプロジェクトをバックアップします（最も重いコンテンツはs3に移動され、個別にダウンロードされます）。 MySQLのバックアップに対して、よく知られている合理的なアプローチを繰り返します。

1. スレーブを使用した論理バックアップ。 この場合、メインサーバーの動作を遅くしませんが、「同期していない」データをバックアップするリスクがあります（そのため、たとえばpt-table-checksumを使用して同期を監視する必要があります ）。
2. 戦闘サーバー/スレーブからLVMを使用したバイナリスナップショット、または-ブロックをバックアップマシンのDRBDディスクにコピーします。
3. xtrabackupまたは同様の有料ツールを使用した戦闘サーバーまたはスレーブからの増分バイナリバックアップ。

データベースのデータが壊滅的に削除された場合に、5〜10分前に大規模なオンラインストアをすばやくロールバックできるようにするために（複数の注文テーブルのデータを削除する誤った要求-他に誰がいなかったのでしょうか？:-)）-3つのオプションのみが機能するようです。 ただし、判明したように、作成時のバイナリインクリメンタルバックアップは、すでに弱いEBSディスクにかなりの負荷をかけますが、リカバリ中に基本的なバイナリバックアップを復元するのに数時間かかることがあります...数時間！
ここでは、MySQLバイナリログの予備編集を伴う論理バックアップからの復旧シナリオを考慮していません。これを行うのはまだ高速ではありません。
ここでも、Amazonが役立ちます。 MySQLの増分バックアップは次のように行われます。

1. MySQL / InnoDB / XtraDBバッファーをディスクにフラッシュする：「フラッシュロックテーブルと読み取りロック」
2. 変更を破棄し、FSへの書き込みを一時的に禁止します：“ fsfreeze -f mountpoint”
3. マシンのすべてのディスクのスナップショットを作成します： CreateImage 。 落とし穴については上記を参照してください。 懸念がある場合は、データベースから各RAIDディスクのスナップショットを作成します。AWSAPIはCreateSnapshotを呼び出します。
4. FSエントリを許可する：「fsfreeze -u mountpoint」
5. すべてのデータベースのすべてのテーブルのグローバルロック「UNLOCK TABLES」を削除します。

これで、ホットMySQLバックアップを備えたAMIオブジェクトが作成され、バックアップから可能な限り迅速に起動できるように最大限になりました。
したがって、少なくとも5分に1回の頻度でS3のMySQLサーバーの増分バックアップを作成するだけで快適であることがわかりました。 サーバーをレプリケーションで使用する場合、設定で保守的なレプリケーション設定を忘れていない場合、原則として問題なくサーバーを復元します（まあ、またはすぐに手動で作業に戻すことができます）：
sync_binlog = 1
innodb_flush_log_at_trx_commit = 1
sync_master_info = 1
sync_relay_log = 1
sync_relay_log_info = 1

Amazonでアクションをスクリプト化する方法は？

システム管理者には、Amazon RESTメソッドをプルする便利なユーティリティがあります。 使用するWebサービスごとにいくつかのユーティリティがダウンロードされ、ユーティリティへの呼び出しはbashでスクリプト化されます。 サーバー上のハードウェアを変更するスクリプトの例を次に示します。

#!/bin/bash #Change cluster node hw type #Which node to change hardware? NODE_INSTANCE_ID=$1 #To which hw-type to change? #Some 64-bit hw types: t1.micro (1 core, 613M), m1.large (2 cores, 7.5G), m1.xlarge (4 cores, 15G), #m2.xlarge (2 cores, 17G), c1.xlarge (8 cores, 7G) NODE_TARGET_TYPE='c1.xlarge' #To which reserved elastic ip to bind node? NODE_ELASTIC_IP=$2 ec2-stop-instances $NODE_INSTANCE_ID while ec2-describe-instances $NODE_INSTANCE_ID | grep -q stopping do sleep 5 echo 'Waiting' done ec2-modify-instance-attribute --instance-type $NODE_TARGET_TYPE $NODE_INSTANCE_ID ec2-start-instances $NODE_INSTANCE_ID ec2-associate-address $NODE_ELASTIC_IP -i $NODE_INSTANCE_ID 

開発者向けには、Amazon APIを操作するためのさまざまな言語のライブラリがあります。 PHP- AWS SDK for PHPから作業するためのライブラリを次に示します 。
ご覧のとおり、Amazonオブジェクトを使用したスクリプト作成作業は簡単です。

PS

ここでプロジェクトのアーキテクチャを確認します 。 バックアップに加えて、単純なクラスター自動スケーリング技術とデータセンター間のトラフィック切り替えについて書く価値があると思います。 5月22日に、1C企業の会議室で開催されるWebクラスターと高負荷に関する無料セミナーを開催します。
私はそれが面白いことを願っています、来て:-)