コマンドラインからLinuxサーバーを移行するときにrsyncを高速化する

注：この記事はガイドであり、段階的なプロセスではありません。 Linux®システム管理とrsyncに精通していることを前提としています。ユーティリティ。コマンドに精通していない場合は、この記事のコマンドを実行しないでください。すべての場合において、このガイドの手順を実行する前に、データをバックアップしたことを確認してください。標準の帯域幅料金が適用されます。

このガイドは、サーバーの移行時間を短縮するのに役立ちます。サーバーのアプリケーションがこの記事で強調表示されている特性のいずれかに一致する場合は、読み進めてください。この記事を使用すると、rsync時間が短くなり、予測しやすくなる可能性があります。また、予防措置を講じてから移行時間を短縮するショーショーもあります。

rsyncプロセスを高速化

サーバー上の使用済みディスクスペースの量によって、rsync時間が決まります。つまり、コピーするデータが多いほど、ジョブにかかる時間が長くなります。通常、空のOS rsyncが完了するまでに10〜15分かかります。次のサーバーのユースケースは、rsync時間を大幅に延長する可能性があります。

Rubyセッションファイル、キャッシュファイル、メールサーバーメッセージファイル、ウェブサーバー画像のサムネイルなどの小さなファイルを多数含むサーバー。 rsyncを使用してこのようなデータを移行すると、予想よりも完了するまでに時間がかかります。これは、initialrsyncに時間がかかることを意味しますが、レスキューモードでの2回目のパス（関連するダウンタイムを含む）は短くなります。
ライブrsync中に更新された複数のファイルを含むサーバー 。通常、これらはMySQL®MyISAMテーブルファイルまたは複数のドメインをホストするWebサーバーであり、それぞれが個別のファイルにログを記録するように構成されています。最初のパスのrsyncコピーの後にこれらのアクティブに書き込まれたファイルを更新する必要があるため、再起動からrsyncプロセスの2番目のパスを完了するまでのダウンタイムが延長されます。
移行中に更新された1つ以上の大きなファイルを含むサーバー 。例としては、InnoDB形式を使用するMySQLデータベース、大きなメールログを持つメールサーバー、単一の大きなファイルにログを記録するWebサーバーなどがあります。これらのアクティブに書き込まれたファイルを、最初のパスのrsyncコピーの後に2番目のrsyncで更新すると、関連するダウンタイムが大幅に延長される可能性があります。

rsync時間を短縮する秘訣は、サーバー上のデータを管理し、ライブマイグレーション中にディスクに書き込むアプリケーションを特定することです。

問題：小さなファイルのオーバーヘッド

個々のディスクスペースをあまり占有しませんが、多くの小さなファイルをホストしているサーバーは、rsyncプロセスに多くのfile-openを実行させます。、file-copy 、およびfile-check プロセス。

たとえば、1ギガバイトのデータファイルには、ファイルのオープン、コピー、およびチェックプロセスのセットが1つ必要です。これとは対照的に、1ギガバイトのデータチャンクが10,000個の個別のファイルに分散しており、10,000個の個別のファイルプロセスセットが必要です。これは、システムとネットワークのオーバーヘッドがはるかに大きくなります。

次のリストは、多くの小さなファイルを作成し、移行の準備時間が長いアプリケーションを示しています。

多くの小さなサムネイルまたは画像ファイルを提供するWebサーバー
小さなファイルでディスクにキャッシュするサーバーのキャッシュ
削除されていない電子メールの大規模なアーカイブを備えた電子メールサーバー
RubyまたはRailsサーバー。複数の小さなセッションファイルを作成し、それらを削除しない傾向があります
gitリポジトリ
訪問者ごとにセッションファイルを作成するが削除しないカスタムアプリケーションサーバー

小さなファイルの問題 rsyncの予測が難しくなり、時間がかかります。

移行方法

上記のリストに対してサーバーアプリケーションを確認してください。アプリケーションがリストに含まれている場合は、実際のrsyncを実行する前に、不要な小さなファイルを整理するためにできることを実行してください。指図。 RubyまたはRailsを実行している場合は、最悪のコミュニティフォーラムを想定して、一般的なセッションとキャッシュファイルの場所、および安全に削除できる場所を特定する方法を確認してください。次のコマンドを使用してMySQLでセッションデータを保存することを検討します。

rake db:sessions:create

log /のログファイルを切り捨てます次のコマンドでゼロバイトにします：

rake log:clear

RAMではなくディスクにキャッシュするキャッシングサーバーを実行している場合は、そのfile-storagedirectoryを特定し、積極的に整理します。カスタムアプリケーションによって作成された小さなセッションファイルとキャッシュファイルがないか、ファイルシステムを確認してください。繰り返しますが、勢いよく剪定します。 DovecotなどのMailDeliveryAgent（MDA）がインストールされている電子メールサーバーを移行する場合は、最初に電子メールユーザーに古い電子メールの電子メールアーカイブをクリーンアップしてもらいます。

問題：ファイルを絶えず変更する

サーバーを完全に移行するには、rsyncの開始と終了の間で変更されるファイルをフォローアップrsyncで再度コピーする必要があります。このプロセスにより、移行の完了時間が延長されます。

データベースサーバーは、移行の開始と終了の間に大きなデータファイルを更新する最も頻繁な原因です。これらの変更により、システムは、移行で実行する可能性のある2番目のrsyncプロセスでデータベースファイル全体を再度コピーするように強制されます。

データベースの構造とタイプの組み合わせによっては、この種の問題が悪化する傾向があります。たとえば、個々のSQLトランザクション内で更新された多くのテーブルファイルを含むMySQLマルチテーブルMyISAMデータベースがあるとします。その場合、すべてではないにしても、多くのテーブルファイルを2回目のレスキューモードのrsync操作中に再度コピーする必要があります。

データベースファイルが大きくなる可能性があることを考えると、移行時間に対するこれらの更新の影響が明らかになります。移行rsyncにかかる時間を正確に予測することは困難です。結局のところ、移行の開始から終了までの間に発生するSQL更新の数と数をどのように予測できますか？

移行方法

データベースに古いデータが多数含まれている場合は、サーバーを移行する前に、そのデータをアーカイブしてから、ライブデータベースからプルーニングすることを検討してください。たとえば、MySQLでは、mysqldumpを使用してデータをアーカイブできます。スクリプト。その後、ライブデータベース内の古いデータを削除できます。大きなmysqldump 廃止されたデータを含む出力ファイルは、最初のパス以降変更されていないため、2番目のrsyncを拡張しません。

サイズ変更中にアプリケーションが多数のファイルに書き込む場合のもう1つのオプションは、rsyncを実行する直前にアプリケーションを読み取り専用モードに設定することです。指図。通常、データベースを一時的な読み取り専用モードに設定できます。他のアプリケーションでは、マイレージが異なる場合があります。アプリケーションをオフにすることで複数のファイルへの書き込みを防ぐこともできますが、通常はアプリケーションを読み取り専用モードに設定することをお勧めします。

問題：大きく、常に更新されるファイル

rsync中に更新された非常に大きなファイル（10 GB以上）は、移行時間に関して、小さくて常に更新されているファイルと同様の問題を引き起こしますが、ステロイドです。サーバーが頻繁に書き込まれるファイルをホストしている場合は、このセクションが役に立ちます。

2番目のrsyncは、移行またはサイズ変更プロセスの開始後に行われた更新をキャプチャするために、これらの大きくて常に更新されるファイルを完全に再コピーする必要があります。これにより、2番目のrsyncコピーのサイズが原因で、移行時間が大幅に延長されます。

InnoDBデータファイル形式を使用するMySQLデータベースサーバーは、実際に非常に大きくなる単一のファイルにデータを書き込みます。同様に、InnoDBモードのMySQLは、単一の大きなログファイルにログを記録します。

/ var / lib / mysql / ibdata1などの大きなInnoDBMySQLデータまたはログファイルの更新、rsyncプロセスに2回目のパスでファイル全体を再コピーするように強制します。これらのファイルが大きい場合、再コピーに時間がかかる可能性があり、データベースがオフラインのままになります。

大きなファイルのもう1つのソースは、メールサーバーや一部のWebサーバーによって生成されたログを含むアプリケーションログです。 Apache®は16Gb以上のログファイルを生成できるため、Apacheのデフォルトのログがこの大きなファイルの問題を回避するのに役立つと考えるのは安全ではありません。

トランザクションログをオンにしている場合、MySQLトランザクションログも大きくなる可能性があります。人々はめったにそうしません、そして彼らが後でディスクスペースを使い果たすことなくトランザクションログをオンにすることはさらにまれです。それでも、この可能性に注意するのが賢明です。

移行方法

前に説明したように、cruftのデータベースをプルーニングすると、rsyncの合計時間が短縮される可能性があります。移行を試みる前に、古いデータベースまたは廃止されたデータベースをアーカイブおよび削除してください。

繰り返しになりますが、可能であれば、データベースの書き込みをオフにすると、移行時間が短縮されます。ロギングをオフにすることも、InnoDBデータベースに役立ちます。

MySQLトランザクションログをオンにしていて、トランザクションログファイルが大きい場合は、オフにしてアーカイブし、rsyncmigrationを開始する前にスライスから削除する価値があります。

メールサーバーで、/var/log/mail.logのサイズを確認しますまたは/var / log / maillog 移行前。特に、負荷を引き受けるためのバックアップメールサーバーがある場合は、移行前にメールサーバーをオフにすることを検討してください。

同様に、Apacheがどのようにログを記録しているかを確認します。すべてのリクエストを1つのファイルに記録する場合は、そのファイルのサイズを確認し、移行プロセスを開始する前に、ファイルをアーカイブして削除するか、Apacheをオフにすることを検討してください。同じアドバイスが、大きなログファイルに書き込んでいることがわかっている他のアプリケーションにも当てはまります。

これらのアプリケーションやその他のアプリケーションについては、logrotateを確認してくださいポリシー（ある場合）は、ログファイルのサイズをチェックしていることを確認します。これにより、移行中のダウンタイムが節約され、Linuxサーバーでの作業が容易になります。

ツールバッグを梱包する

もちろん、サーバーのセットアップ後に作成されたファイルを追跡することは困難です。これは、セッションファイルを作成するアプリケーションにも当てはまります。これらの小さなファイルの大規模なコレクションを見つけて選別することにはメリットがあります。

次のコマンドをrootとして発行すると、最大の10個のディレクトリとファイルを識別できます。：

du -a / | sort -n -r | head -n 10

その最後の10を変更します検索で返されるファイルとディレクトリの数を変更するには、他の数値に変更します。このコマンドは、小さなファイルと大きなファイルの大きなディレクトリを識別するための優れた中間ツールです。大きなファイルのみを検索する場合は、この大きなファイルファインダーを試してください（rootとして））：

find ~/ -mount -type f -ls|sort -rnk7 |head -30|awk '{printf "%10d MB\t%s\n",($7/1024)/1024,$NF}'

大きなディレクトリのみを検索する場合は、この大きなディレクトリファインダーを試してください（rootとして））：

du -x --max-depth=4 ~/|sort -rn|head -n30|awk '{printf "%10d MB\t%s\n",$1/1024,$2}'

技術的な詳細

サーバーが上記で調べた一般的なタイプのいずれにも一致しないとします。その場合、移行（rsync）プロセスがどのように機能するかを理解した上でアプリケーションを検討すると、移行時間がどのように見えるかを評価できます。

移行の一般的な最初の段階は、基本的にサーバーのファイルシステム全体のコピーであるライブrsyncです。この段階では、すべてのアプリケーションが実行されたままになります。

ここで、移行時間の予測が最初の不確実性にぶつかります。サーバーのファイルシステムの使用状況に関する詳細な知識がなければ、file-copyの長さを正確に予測することはできません。 rsyncのステージが完了するまでにかかります。

この予測不可能性は、Linuxファイルシステムの最終ディレクトリである / var /にも当てはまります。ディレクトリ。 varと呼ばれます保持するデータのサイズは可変であるためサーバーアプリケーションの実行中に変更されます。

2番目の不確実性は、移行の最終段階にレスキューモード（ダウンタイム）コンポーネントが含まれることです。このフェーズでは、ライブrsyncfirstフェーズの開始後に更新されたファイルがプロセスによって再度コピーされます。ダウンタイムの長さは、更新されたファイルのサイズと数によって異なります。繰り返しになりますが、rsyncプロセスは、MySQLなどのアプリケーションがデータファイルに書き込んでいる更新の数を事前に知ることができないため、この最後のレスキューの期間を予測することは困難です-モードrsync コピー。

上記の情報は、一般的な手動移行プロセスに適用されます。私たちのクラウドは、サイズ変更プロセスを変更して、単一のrsyncでサーバーをダウンさせ、ダウンタイムを増やし、同期の信頼性を高めます。

概要

アプリケーションがディスクスペースをどのように使用してファイルに書き込んでいるかを知っている場合は、移行に必要以上に時間がかかるかどうかを判断し、それに応じて準備を行うことができる場合があります。少なくとも、新しく見つけた移行の知識を使用して、タイミング要件に合わせて移行をより適切にスケジュールすることができます。

コメントや質問をするには、[フィードバック]タブを使用します。また、私たちと会話を始めることができます。