👩🏿‍💻 👈🏼 😰 Amazonのサーバーを「バックアップ」してピラニアを防ぐ方法 🤵🏻 🙄 🚵🏻

人気のあるAmazonクラウドプロバイダーがホストするWebプロジェクトの所有者の多くは、おそらく、効率的で信頼性の高いWebソリューション構成の作成方法、マシンのバックアップ方法、およびサーバーが配置されているデータセンターの崩壊に対処する方法について考えるでしょう。残念ながら、クラウドホスティングの公式ドキュメントは、Webサービスの信頼性と内部実装のトピックについてはややこしいです。したがって、操作と軍隊の工夫で、独自の戦闘経験に頼らなければなりません。

クラウド内のすべてが非常に信頼性が高く、快適に眠ることができるという誤解に対する現在の反対により、状況は悪化しています。ハードドライブは「チタン」で作られており、ネットワークトラフィックは「金線」に沿って流れ、エンジニアは小便器を半分に切るタフな男たちがいます- クラウドからの推奨事項「十分な信頼性とDC間での高速チャネルのサービスを提供します。プロジェクトアーキテクトのタスクは、9つの技術を適切な量にすることにより、技術を結合することです。」

記事では、6か月間のサービスの動作、Webプロジェクトの信頼性と生産性を確保するためのEBSドライブのアーキテクチャソリューション、および日常業務で使用する特定のバックアップ手法に関する観察結果を共有したいと思います。

EBSディスクの信頼性-RAID1または「さらに悪い」？

正直に言うと、EBSディスクに関するAmazonの公式ドキュメントから、RAID1よりも信頼性が高いかどうかはまだわかりませんでした。ディスクのボリュームの機能依存性、ディスクの最後のスナップショットの時間、ウィザードのひげの髪の毛の数、月の満ち欠けは楽観的ではありません：

「ボリュームの耐久性は、ボリュームのサイズと、前回のスナップショット以降に変更されたデータの割合の両方に依存します。 例として、最新のAmazon EBSスナップショット以降の変更データが20 GB以下で動作するボリュームは、0.1％から0.5％の年間故障率（AFR）を予測できます。ここで、故障とはボリュームの完全な損失を指します»

Amazonの欧州DCでの最近の事故では、データセンターの停電のため、2つのディスクがソフトウェアRAID10からすぐに飛び出しました。 EBSディスクが突然「クラッシュ」し、「残念ながらデータが失われました」という件名でクライアントに手紙が送信されたという不気味なメッセージがネットワークに表示されることがあります。ディスクが故障する1分前にスナップショットを取ることを公式に推奨します:-)スナップショットメカニズムは、非常に信頼性の低いEBSドライブの障害の「セーフティネット」専用に登場しました。

独自のプライベートイメージを作成するために使用されるパブリック仮想マシンには、EBSドライブが1つしかありません。これはRAIDになく、ルートパーティションにあります。そして、ソフトウェアRAIDにルートパーティションを持つマシンをロードする-ファイルを使わずに穏やかに置くのは簡単ではなく、時間がかかります。

それにもかかわらず、半年間、Amazonで1台のディスクが飛び出したことはなく（約50台あります）、落雷後の停電をカウントせず、多かれ少なかれ信頼できる「RAID1」ドライブ（ノック、ノック）として扱うことができます;同じデータセンターにある1つのデバイスへの複製）、 s3に対する信頼性は劣ります（異なるデータセンターの2つのデバイスに追加で複製され、一般にブロックデバイスではありません）が、通常のハードドライブの10倍の信頼性があります。

ソフトウェアRAIDと低EBSパフォーマンス

今年の初めにAmazonに移行した後、EBSディスクのパフォーマンスがかなり低下しました。これは、MySQLを搭載したマシンで特に顕著でした。 RDSでアイデアを「見た」（AmazonはEBSディスクの総量に応じて自動的にデータベース情報をソフトウェアRAIDに配置します）軍隊の工夫を使用して、EBSディスクから作成されたソフトウェアRAID10（Linuxではmdadm）にデータを転送しました：

cat /proc/mdstat 
      

        
        
        
      

     Personalities : [raid10] 
      

        
        
        
      

     md0 : active raid10 sdo[0] sdj[8](S) sdi[7] sdh[6] sdg[5] sdn[4] sdm[3] sdl[2] sdk[1] 
      

        
        
        
      

     629145344 blocks 64K chunks 2 near-copies [8/8] [UUUUUUUU]

ああ、予備ディスク、ご覧の通り、私たちは:-) 'sdj [8]（S）'を使用しています。それでも同じように、彼らはフォールトトレランスのレベルを上げるために襲撃を行うことにしました。

RAIDへのデータの移行後、マシン上のディスクサブシステムのパフォーマンスの問題は気になりなくなりました。

クラスタファイルシステムとEBSドライブ

なぜならメインサイト（www.1c-bitrix.ru）はWebクラスター構成で動作します。2台のWebマシン、データベース（マスター+スレーブ）を備えた2台のマシン-バランサー（nginx）の背後に、クラスターファイルシステムを使用したかったのです。 OCFS2やGFS2など。しかし、EBSディスクを複数の仮想マシンに同時にマウントできないことが判明しました。そのため、コンテンツクラスタリングにはcsync2ユーティリティを使用します。これは、アドインによって、 inotifyに基づいて頻繁に更新される重いフォルダーを「迅速に」同期するように強制されます（必要に応じて詳細を説明します）。

バックアップEBSドライブ

仮想マシンディスクは非常に簡単にバックアップできます。この目的のために、ブロックデバイススナップショットを作成するツールが作成されました。

ec2-create-snapshot vol-a5rtbvwe

操作は非常に迅速（数秒）に開始し、スナップショットのs3へのロードは、ディスクサイズとAmazonの負荷に応じて特定の時間（最大数十分）続きます。

私たちは大人であり、ディスクの全体的なスナップショットは次の場合に成り得ることを理解しています。

ドライブは事前にマウント解除されています：「umount -d / dev / sdh」。
サーバーは以前に停止されています。
ファイルシステムは凍結されています。この場合でも、アプリケーションにデータをディスクにフラッシュするように指示する必要があります。

それ以外の場合、「突然の電源オフ後のように」ディスクのスナップショットを取得し、マシンの起動時にディスクを処理する必要があります（fsck）-最新のジャーナリングファイルシステム（ext3、ext4、xfs など）のおかげで、気付かれないために頻繁に発生します雑誌をする。ライブ（マウント解除なし）ext3およびxfsを使用してディスクのスナップショットの作成をテストしました-ログの再生を一時停止した後、ディスク（スナップショットから作成）がマウントされて動作します。

ファイルシステムを「フリーズ」および「フリーズ」する

「サスペンション」をサポートするファイルシステムとして、 xfsを選択しました。このFSはAmazon によって推奨され、 ec2-consistent-backupタイプの完全なスナップショットを作成するユーティリティによって使用されます：

xfs_freeze -f | -u mount-point

実際、「xfs_freeze -f」の後にディスクのスナップショットが作成されると、非常に迅速にログを再生せずにマウントされます。

CentOS6（および明らかに「更新された」カーネルを備えた他のディストリビューション）では、 fsfreezeコマンドでext3 / ext4などのデフォルトのファイルシステムを「フリーズ」することも可能になりました。 EBSディスクの全体的なスナップショットを作成するコンテキストで、このユーティリティを十分にテストする予定です。

ソフトウェアRAIDバックアップ

論理的に考えると、a）raidファイルシステムを「停止」し、b）各物理raidディスクのスナップショットの作成を開始し、c）raidファイルシステムを「解放」する必要があります。

残念ながら、Amazon APIのドキュメントには、b）とc）の間の経過時間に関する情報が含まれていません。ただし、各RAIDディスクのAPI呼び出しからスナップショット識別子を取得するだけで十分であり、RAIDファイルシステムを「解凍」できることが実験的にわかっています（このユーティリティでも同様に行われます）。RAIDを組み立てるときに再構築せずにピックアップされます。そうでなければ、再構築を開始します。だから私たちはやった：

bxc_exec("/usr/bin/ssh remote_xfs_freezer@hostname".escapeshellarg("sudo /usr/sbin/xfs_freeze -f /xfs_raid_path")); 
      

        
        
        
      

     ... 
      

        
        
        
      

     ec2-create-snapshot -     
      

        
        
        
      

     ... 
      

        
        
        
      

     bxc_exec("/usr/bin/ssh remote_xfs_freezer@hostname".escapeshellarg("sudo /usr/sbin/xfs_freeze -u /xfs_raid_path")); 
      

        
        
        
      

     ... 
      

        
        
        
      

     ec2-create-volume --snapshot id_of_snapshot 
      

        
        
        
      

     ... 
      

        
        
        
      

     ec2-attach-volume volume_id -i instance_id -d device 
      

        
        
        
      

     ... 
      

        
        
        
      

     mdadm --assemble /dev/mdN /dev/sd[az]

スナップショットMySQL？

片手でMySQLデータをディスクにフラッシュできますが、 FLUSH TABLES WITH READ LOCK 、左足でファイルシステムxfs_freeze -f / pathを反転し、鼻でEnterを押してスナップショット削除APIを実行します：ec2-create-snapshot ...別のDCへの非同期MySQLレプリケーションが満たされます:-)。興味深いのは、 xtrabackupを使用したベーススナップショットの作成です-タンバリンとの上記のダンスなし。

マシン全体を一度にバックアップできます！

RAID、RAIDのディスクグループを個別にバックアップする場合、構成が存在する場合、プロセスは安定して透過的に動作します。ただし、AZ（データセンター）アマゾン間を移動する必要がある場合（たとえば、週末にDC落雷で:-)）-インスタンスインスタンス、スナップショット、ディスクよりも高い抽象化レベルを入力し、ロールとイメージのカテゴリで操作するのが簡単です（AMI- Amazon Machine Image ）車。 APIを使用して、タグを Amazonオブジェクトに割り当て、選択をフィルターすることができます。

ロールを定義しました：Webマシン、DBMS、バランサー、モニタリングマシン、およびバックアップスクリプトは次のように機能します。

DBMSタグで車を探し、そのIDを取得します
「フリーズ」車のホイール
ディスクのスナップショットを作成します。スナップショットタグ「DBMS」を設定します。
車のホイールの「霜取り」
古いスナップショットをクリアするには、タグと時間で選択し、不要なスナップショットを削除します。

ただし、実行中の仮想マシンをイメージ（AMIイメージ）にバックアップする方がはるかに簡単です。同時に、設定と作成されたスナップショットへのパスは、マシンのディスクの作成元であるイメージに保存され、起動時に接続されます。

ec2-create-image id_of_instance [--no-reboot] 
      

        
        
        
      

     ... 
      

        
        
        
      

     ec2-run-instances ami_image_id

違いを感じてください！ 1つのコマンドで、9個のディスクのうち10個のRAIDを持つマシンからイメージを作成します。そして、私は彼女のディスクとスナップショットのidshniksについて心配していません-マシンを再作成するために必要なすべての情報はAMIイメージに自動的に書き込まれます。唯一のマイナスは、実行中のマシンのドライブ/レイドをロックして、そこからAMIイメージを作成するのにかかる時間が明確でないことです。経験的に、2〜5秒で十分であることがわかりました。これより短い場合、新しいマシンの作成時にディスク/ RAIDが回復し始めます。また、別のデータセンター（AZ）でバックアップからイメージ（AMI）に車を乗せることができるのも非常に便利です。

ここで、クラスター構成内のすべてのマシン（数百ギガバイト）のAMIイメージに1日に2回バックアップを作成します。「廃止された」画像のクリーニングは、そのスナップショットとともに、スクリプトによって実行されます。

 function bxc_delete_old_instance_backups( AmazonEC2 $ec2, $instanceRole = '', $bkpsMaxCount = 3) { if (!$instanceRole || !is_object($ec2) || $bkpsMaxCount<1 ) { bxc_log_error("Bad input params: ".__FUNCTION__); return false; } $response = $ec2->describe_images(array( 'Filter' => array( array('Name' => 'tag:Role', 'Value' => 'Image:'.$instanceRole), array('Name' => 'state', 'Value' => 'available'), ) )); if ( !$response->isOK() ) { bxc_log_amazon_error($response, __FUNCTION__.":".__LINE__); return false; } if ( isset($response->body->imagesSet->item) ) { $images = array(); $snaps = array(); foreach ( $response->body->imagesSet->item as $image ) { $images[ (string) $image->name ] = (string) $image->imageId; if ( isset($image->blockDeviceMapping->item) ) { foreach ( $image->blockDeviceMapping->item as $disk ) { $snaps[ (string) $image->name ][] = $disk->ebs->snapshotId; } } } if ($images) { krsort($images); } else { bxc_log("No images with tag:Role=Image:$instanceRole"); return true; } if ( count($images) <= $bkpsMaxCount ) { bxc_log("Nothing to delete"); return true; } $imagesToDelete = array_slice($images, $bkpsMaxCount, count($images)-$bkpsMaxCount, true); foreach ($imagesToDelete as $imageName=>$imageId ) { $r = $ec2->deregister_image($imageId); if ( $r->isOK() ) { bxc_log("Image deleted ok: ".$imageId); sleep(5);//Important. Wait to ami really be deleted ;-) foreach ( $snaps[$imageName] as $snapId ) { $rr = $ec2->delete_snapshot( $snapId ); if ( $rr->isOK() ) { bxc_log("Snapshot deleted ok: ".$snapId); } else { bxc_log_amazon_error($rr, __FUNCTION__); bxc_log_error("Cannot delete snapshot: ".$snapId); } } } else { bxc_log_amazon_error($r, __FUNCTION__); bxc_log_error("Cannot delete image: ".$imageId); } } return true; } else { bxc_log("No images with tag:Role=Image:$instanceRole"); return true; } return false; }

管理者、コンソール、またはAPI

Amazon AWSには優れた管理領域がありますが、多くのことはAPIを介してのみ実行できます。 Linuxの場合、Amazon APIを操作するためのコマンドラインツールをインストールできます。次のツールを使用します。

ls /opt/aws/ 
      

        
        
        
      

     AutoScaling-1.0.39.0 
      

        
        
        
      

     ElasticLoadBalancing-1.0.14.3 
      

        
        
        
      

     ec2-api-tools-1.4.4.1 
      

        
        
        
      

     env-set.sh

最後のスクリプトは、ツールが機能するための環境変数を設定します。ほとんどすべてのAmazon Webサービスには、個別にダウンロードしてインストールする必要がある独自のユーティリティセットがあることに注意してください。たとえば、マシン制御の場合、ドキュメントはこちら、コマンドラインユーティリティはこちらです。

これまでのところ、 PHP用 Amazon API を使用するための公式SDK は良好なパフォーマンスを示しています（上記のスクリプトはこの特定のライブラリを使用しています）。

結論

Amazon EBSは、ソフトウェアRAIDに結合することで効率的に管理できます。残念ながら、EBSディスクを複数の仮想マシンにマウントして、OCFS2、GFS2などのクラスターファイルシステムを操作することはできません。ドライブとEBSレイドの両方のバックアップは簡単です。基本原則を理解し、落とし穴を回避するだけです。別のドライブではなくマシン全体をバックアップすると便利です。これにより、落雷や飛行機がデータセンターに衝突した場合に、近隣のデータセンターに構成を迅速に展開できます。皆さんに幸運を！

Amazonのサーバーを「バックアップ」してピラニアを防ぐ方法