(cache) rsyncによるファイルサーバのバックアップ

▼ rsyncの知識 ▽ rsyncの基本 ▽ rsync用システムの構成 ▽ rsync動作の実態
▼ rsync対応FS構成例 ▽ タワー型GbE/10GbE ▽ 1UラックGbE ▽ 2UラックGbE ▽ 2Uラック10GbE ▽ 5Uラック10GbE

はじめに

ファイルサーバのデータを安全に保管するためにはデータのバックアップは欠かせません。ところが、計算機の高性能化によりデータ量が膨大になったことでバックアップ時間が長くなり、バックアップ作業が難しくなることがあります。そこで、安全にバックアップを行うための堅実なバックアップ法を提案します。

▲ページの先頭へ

rsyncの基本

Linuxでのバックアップの定番は「rsync」コマンド

Linuxでのファイルサーバのデータ同期作業 (バックアップ) では「rsync」コマンドが広く利用され実績があります。rsyncはオプション指定することで高速かつ確実に、データ更新やデータ同期ができる優秀なアルゴリズムを持っています。

rsyncの基本的な動き

1, ２つの異なる指定したパス以下のディレクトリとファイルのリストを作成
2. リスト同士での比較を実行
3. 指定されたオプションに従い、データのコピーや削除などを高速に実行

rsyncの動作では、ディレクトリ数やファイル数増加に従い計算機リソースが必要 (Point)

1. リスト管理ではメモリ量が必要となる
2. リスト比較ではCPUが必要となる
3. ファイル転送では通信性能が必要となる

rsyncの負荷のパターン

rsyncを２台のサーバで動かした場合の負荷のかかり方を示します。rsyncを利用する場合はこの特徴に最適化された計算機構成が必要です。

◇ rsyncを実行する側のサーバでは２つのプロセスが動作 (バックアップ側での利用を推奨)
◇ リモート側のサーバでは１つのプロセスが動作 (ファイルサーバ側では負荷が低減される (CPU、メモリ))

※ バックアップの対象となるサーバのOS仕様に不安があったり、計算機リソースが不足気味の場合には、バックアップ側のサーバにファイルシステムをNFSマウントし、全てのrsync処理をバックアップ側で動作させる手法を推奨します。

rsyncは負荷が高いためQuad-Core Xeonの採用や、大容量メモリの搭載を推奨

バックアップ処理は負荷が重いため、Quad-Core Xeonの利用を推奨します。また、リスト処理はメモリ上で行われるため、十分な容量のメモリ搭載も必要です。

▲ページの先頭へ

rsync用システムの構成

サーバ２台 (ノード間バックアップ)

◇ rsyncをバックアップサーバ側で実行すると、メインサーバ側のCPU負荷とメモリ負荷が軽減される
◇ メインサーバ側ではファイルサーバの動作にCPU、メモリなどのリソースを配分できる
◇ メインサーバ側が落ちても、バックアップサーバ側をファイルサーバとして利用できる
◇ メインサーバ側のファイルを誤操作などで消しても、バックアップ側から直ぐに読み出せる
※ テープバックアップとの違い、バックアップデータをリストアせずに、そのまま使える
※ テープバックアップの問題、戻す先のファイルサーバが落ちていると、復旧できない

⇒ バックアップサーバは4コア搭載を推奨
rsyncを実行するバックアップサーバでは２プロセスが動作します。そのため、バックアップサーバには最低でも2CPUコア以上の搭載が望ましいです。その他の処理を考えるとQual-Core Xeon 1CPU 4コア構成を推奨します。

⇒ メインサーバには4コア搭載を推奨
rsyncでのバックアップ時には、メインサーバでも派生的なrsyncプロセスが１プロセスrsh動作します。そのため、メインサーバでのファイルサーバ処理を考慮するとQual-Core Xeon 1CPU 4コア以上の構成を推奨します。

⇒ バックアップサーバには多くのメモリ搭載を推奨 (容量例)
バックアップサーバではリスト比較がメモリ上で行われるので、ファイル数に対応したメモリ搭載量が必要です。例えば1,000万ファイルを扱おうとするとrsyncが２プロセス動作し約2GBのメモリを必要します。さらにリモートI/O用のキャッシュやOSの使用するメモリなども加味すると、約4GB程度のメインメモリ搭載が望ましいです。

⇒ メインサーバには多のメモリ搭載を推奨
メインサーバもrsyncが１プロセス動作するため、1,000万ファイルを扱おうとすると約1GBのメモリを必要とします。さらに、ディスクキャッシュやOSでも最低1GBは必要です。もちろんメインサーバの本来の役割であるファイルサーバ機能にもメモリは必要ですから2GBはミニマム、できれば4GB以上のメインメモリ搭載が望ましいです。

⇒ サーバのネットワーク強化は効果的
メインサーバのネットワークに負荷が集中するおそれがある場合は、ネットワークの増設が効果的です。もちろん、バックアップサーバのネットワークの増設も効果的です。さらにスループットを上げるためにネットワークのボンディングや10GbEの採用も効果的です。

サーバ１台 (ノード内バックアップ)

◇ サーバ内部にストレージを独立して２つ搭載し、ノード内でのバックアップを実施
◇ バックアップの転送速度が高速
◇ 機器構成がシンプル
◇ Quad-Core Xeon 2CPU 8コアのCPUパワーにより計算機リソースも十分　
◇ メインボリュームが壊れてもバックアップボリュームを直ぐに利用できる
◇ メインボリューム側のファイルを誤操作などで消しても、バックアップ側から直ぐに読み出せる
△ ファイルサーバやRAIDコントローラが万一故障すると、すぐに復旧できない

⇒ サーバには8コア搭載を推奨
rsyncの実行に３プロセスが動作します。さらにファイルサーバ処理を考慮するとQual-Core Xeon 2CPU 8コア構成を推奨します。

⇒ サーバには多くのメモリ搭載を推奨 (容量例)
rsyncはリスト比較をメモリ上で行うので、ファイル数に対応したメモリ搭載量が必要です。例えば1,000万ファイルを扱おうとするとrsyncが３プロセス動作し約3GBのメモリを必要します。さらにOSの使用するメモリやファイルサーバで使用するメモリなども加味すると、4GB以上のメインメモリ搭載が望ましいです。

▲ページの先頭へ

rsyncの動作の実際

rsyncによるデータ同期速度の目安 (更新が無い場合は1,000万ファイルの同期チェックで約10分)

rsyncでのデータ同期に要する時間は (ハードウェア性能やシステム設定によって違いがでますが)、弊社推奨のサーバ２台をGbEで接続した構成であれば約1,000万ファイルで、ファイルのリストの同期チェックは (更新データが１個もない) 約１０分程度で完了します。データが更新されている場合は、データのコピーや削除などの処理が追加されます。

rsyncによるデータ同期速度の目安 (600GB/600万ファイルの更新があった場合で約４時間)

弊社推奨のRAID10搭載のサーバ２台をGbEで接続した構成で、実際に600GBの容量で600万ファイルの更新を行いrsyncを実施すると約４時間ほどで処理が完了しました。この時間の殆どはデータの転送に費やされています。600万個の小さなファイルをGbEネットワーク越しに約４時間で転送していますから、実効転送速度は約42MB/s (600GB/(4*60*60)) となります。これは速いです。これなら、データの更新を深夜から実行するように設定すれば、早朝にはデータの更新も終わり、朝から快適に計算機を利用することができます。(これは全更新された場合の差分によるフルバックアップですが、部分的な更新であれば所要時間は短くなります。)

時間の掛かるフルバックアップを基準にするとボリュームサイズは2TB程度が上限

バックアップ作業では、定期的にフルバックアップを行う必要があります。この処理時間は１０時間程度 (一晩) が運用上の限界と考えられます。すると先ほどの600万個の小さなファイルを最悪のケースとし、それよりも少し速い50MB/sを目安とすると、2TB程度が適当だと考えられます。(また、リストアを考慮すると2TB程度が扱いやすく安全です。)

毎日の差分バックアップを推奨

日常のバックアップ作業は、差分バックで済ませます。更新分だけの処理となりますから、リスト比較時間 + 転送時間の合計であり、先ほどの例から時間を見積もると、600GB/600万ファイルの10%が更新されていると仮定して、リスト比較が約10分 + ファイル転送で20分と、合計で約30分と予想できます。これなら毎日でも可能です。そしてフルバックアップは週一回程度の実施が適当であろうと考えます。

古いマシンのバックアップの問題点

◇ OSやrsyncのバージョンが古いと、rsyncに非常に時間がかかることがある
◇ サーバのリソース不足でも、メモリでスワップアウトが発生して一括処理が出来ないことがある
◇ CPUの処理性能の不足で処理時間が掛かることがある
◇ サーバの動作が不安定で、重いバックアップ処理を追加することに不安がある

このようなことでお困りの場合は弊社にご連絡をお願いします。適切なシステム設計を行います。

⇒ CPUコア数が多く、メモリ搭載量が多い最新のサーバをバックアップ機として導入し、全てのrsync処理をバックアップ側で実施し、現行のファイルサーバへの負荷を最小化する構成を推奨します。万一ファイルサーバが故障しても、バックアップサーバをファイルサーバとして即座に利用することができます。

■ rsyncによるバックアップを活用したシステムの導入事例へリンク
□ 2Uラック型サーバDPe2950 ２台間で800万ファイルをバックアップ
□ 既存ファイルサーバの1260万個のファイルをタワー型ファイルサーバDPe2900でバックアップ

rsyncによるバックアップを考慮した機器構成例


▲ページの先頭へ
タワー型サーバDPe2900、GbE x2、10GbE、構成

	◆ ノード内バックアップ、12Gbps SAS経由バックアップ ◆ GbEx2ボンディング / 10GbE接続 ◇ ノード内バックアップで高速 ◇ バックアップ負荷がネットワークにかからない ◇ RAID10 2TB + 2TB + スペアディスク構成 ※ 1.5TB構成、1TB構成も可能 ⇒ 8コア搭載を推奨 ⇒ 大容量メモリ搭載を推奨


タワー型サーバDPe840、GbE、構成

	◆ ノード間バックアップ、GbE経由バックアップ ◆ 冗長化ホスト (本番 + 待機) ◆ GbE接続 ◇ ノード間バックアップによる高い可用性 ◇ バックアップ用に独立したGbEを使用 ※ ボンディングも可能 ◇ RAID10 2TB + 2TB構成 ※ 1.5TB構成、1TB構成も可能 ⇒ 4コア搭載を推奨 ⇒ 大容量メモリ搭載を推奨


▲ページの先頭へ
1UサーバDPe1950、ディスクアレイDPm1000、GbE、構成

	◆ ノード内バックアップ、12Gbps SAS経由バックアップ ◆ GbEx2ボンディング接続 ◇ ノード内バックアップで高速 ◇ バックアップ負荷がネットワークにかからない ◇ 最大物理容量90TB ⇒ 8コア搭載を推奨 ⇒ 大容量メモリ搭載を推奨 △ ホスト系の障害には弱い

	◆ ノード間バックアップ、GbE経由バックアップ ◆ 冗長化ホスト (本番 + 待機) ◆ GbE接続 ◇ ノード間バックアップによる高い可用性 ◇ バックアップ用に独立したGbEを使用 ※ ボンディングも可能 ◇ サーバ一台分のコスト増 ◇ 最大物理容量180TB ⇒ 4コア搭載を推奨 ⇒ 大容量メモリ搭載を推奨 △ GbEボンディングは2Uサーバで

	◆ ノード間バックアップ、GbE経由バックアップ ◆ 冗長化ホスト (双方本番) ◆ GbE接続 ◇ 2台のファイルサーバのサービスにより高速 ◇ ノード間でクロスバックアップし高い可用性 ◇ バックアップ用に独立したGbEを使用 ※ ボンディングも可能 ◇ 最大物理容量180TB ⇒ 8コア搭載を推奨 ⇒ 大容量メモリ搭載を推奨

▲ページの先頭へ
2UサーバDPe2950、ディスクアレイDPm1000、GbE、構成

	◆ ノード内バックアップ、12Gbps SAS経由バックアップ ◆ GbEx3ボンディング接続 ◇ ノード内バックアップで高速 ◇ バックアップ負荷がネットワークにかからない ◇ 最大物理容量90TB ⇒ 8コア搭載を推奨 ⇒ 大容量メモリ搭載を推奨 △ ホスト系の障害には弱い

	◆ ノード間バックアップ、GbE経由バックアップ ◆ 冗長化ホスト (双方本番) ◆ GbEx2ボンディング接続 ◇ 2台のファイルサーバでのサービスにより高速 ◇ ノード間でクロスバックアップし高い可用性 ◇ バックアップ用に独立したGbEを使用 ※ 追加ボンディング (GbE x3) も可能 ◇ 最大物理容量180TB ⇒ 8コア搭載を推奨 ⇒ 大容量メモリ搭載を推奨

▲ページの先頭へ
2UサーバDPe2950、ディスクアレイDPm1000、10GbE、構成

	◆ ノード内バックアップ、12Gbps SAS経由バックアップ ◆ 10GbE接続 ◇ ノード内バックアップで高速 ◇ バックアップ負荷がネットワークにかからない ◇ 10GbEを採用し高速 ◇ 最大物理容量90TB ⇒ 8コア搭載を推奨 ⇒ 大容量メモリ搭載を推奨 △ ホスト機の障害には弱い

	◆ ノード間バックアップ、GbE経由バックアップ ◆ 冗長化ホスト (本番 + 待機) ◆ 10GbE接続 ◇ バックアップ用に独立したGbEを使用 ◇ バックアップ用に独立したGbEを使用 ※ 10GbE化も可能 ◇ 最大物理容量180TB ⇒ 8コア搭載を推奨 ⇒ 大容量メモリ搭載を推奨

	◆ ノード間バックアップ、10GbE経由バックアップ ◆ 冗長化ホスト (双方本番) ◆ 10GbE接続 ◇ バックアップ用に独立した10GbEを使用 ※ 10GbEボンディングも可能 ◇ 最大物理容量180TB ⇒ 8コア搭載を推奨 ⇒ 大容量メモリ搭載を推奨


▲ページの先頭へ
5UサーバDPe2950、ディスクアレイDPm1000、10GbE、構成

	◆ ノード間バックアップ、10GbE経由バックアップ ◆ 冗長化ホスト (双方本番) ◆ 10GbEボディング接続 ◇ バックアップ用に独立した10GbEを使用 ※ 追加ボンディング (10GbE x3) も可能 ◇ 最大物理容量360TB ⇒ 8コア搭載を推奨 ⇒ 大容量メモリ搭載を推奨