こんにちは、ニフクラ技術支援チームです。
近年、企業や公共機関が災害対策におけるDR（Disaster Recovery）を目的として本番サーバーを設置している場所以外の遠隔地に、データをバックアップする需要が増えています。
ニフクラでは、複数リージョンを使用できるので遠隔地にバックアップが可能です。
ニフクラで提供しているプライベートブリッジは、プライベートLAN同士をL2接続するネットワークサービスですが、この機能を利用することで簡単にセキュアなネットワーク構成を構築することができます。
ただし、直接別リージョンにバックアップする場合以下のような問題が発生する可能性があります。
- 夜間などのサービス時間外にバックアップを設定してもサービス開始前までにバックアップが完了しない。
- RTOを重視したいが、復旧データの転送時間が遅い。
ニフクラではそのようなマルチリージョン間でのバックアップの問題を解決するために、
を提案しています。
バックアップを1次(バックアップ元)、2次(別リージョン)に分割して、1次バックアップに使用する増設ディスクとして高速フラッシュドライブを使用することで所要時間を短縮する方法があります。
今回、直接別リージョンにバックアップする場合とマルチリージョン２次バックアップパターンでバックアップする場合の性能比較検証を通して
マルチリージョン２次バックアップパターンの有効性をご紹介します。
前提条件
本ブログは、以下の前提知識がある方を想定しています。
- ニフクラの基本的なコントロールパネルの操作、サービスを利用する知識
(サーバー作成、ネットワーク構築など) - Linuxサーバーの基本的な操作、知識
検証概要
検証環境構成パターン
以下(1)～(3)の構成パターンで、リージョン間をプライベートブリッジで接続して性能比較を実施検証しました。
プライベートブリッジの構築はブログ：プライベートLAN同士を接続する機能 プライベートブリッジ の提供を開始しましたを参照してください。
構成パターン(1)
1次バックアップ高速フラッシュドライブ、2次バックアップ標準フラッシュドライブ使用
構成パターン(2)
1次バックアップ標準フラッシュドライブ、2次バックアップ標準フラッシュドライブ使用
構成パターン(3)
直接別リージョンの標準フラッシュドライブへバックアップ
検証実施内容
100MB、500MB、1GBのファイルを各50ファイル作成して 合計80GB 150ファイルをrsyncコマンドでバックアップを実行し、所要時間とスループットを計測します。 (ファイルは非圧縮)
利用リソース
今回の検証を実施するにあたり、利用したニフクラのリソース情報に関して以下に記載します。
※各リソースのアクセス制限に関しては、ニフクラのファイアウォール等を用いて適切に設定の上実施しています。
| リソース | 数量 |
|---|---|
| プライベートLAN | 2 |
| ルーター | 2 |
| サーバー（サーバーOS：Red Hat Enterprise Linux 8.4） | 3 |
| 増設ディスク | 4 |
| ファイアウォール | 2 |
| プライベートブリッジコネクター | 2 |
| プライベートブリッジ(リーチャビリティ) | 1 |
リージョン:east-1
| リソース | ホスト名 | IPアドレス | 備考 |
|---|---|---|---|
| プライベートLAN | CDPLAN01 | 192.168.10.0/24 | |
| ルーター | CDPRouter01 | 192.168.10.1 | |
| サーバー1 | CDP01 | 192.168.10.2 | |
| サーバー2 | CDPbk01 | 192.168.10.3 | |
| サーバー1用増設 ディスク |
CDP01 | - | 標準フラッシュ ドライブ：100GB |
| サーバー2用増設 ディスク |
CDPbk01 | - | 高速フラッシュ ドライブ：100GB |
| サーバー2用増設 ディスク |
CDPbk02 | - | 標準フラッシュ ドライブ：100GB |
| ファイアウォール | FWCDP01 | - | |
| プライベート ブリッジコネクター |
PBCDPeast | - |
リージョン:west-2
| リソース | ホスト名 | IPアドレス | 備考 |
|---|---|---|---|
| プライベートLAN | CDPLAN01 | 192.168.10.0/24 | |
| ルーター | CDPRouter01 | 192.168.10.10 | |
| サーバー3 | CDPbk02 | 192.168.10.11 | |
| サーバー3用増設 ディスク |
CDPbk01 | - | 標準フラッシュ ドライブ：100GB |
| ファイアウォール | FWCDP01 | - | |
| プライベート ブリッジコネクター |
PBCDPeast | - |
事前準備
増設ディスクのマウント
サーバー、増設ディスクが作成されて、増設ディスクをマウントしていることをニフクラヘルプ(追加したディスクの設定方法)を参照して確認してください。
rsync導入
データ転送に必要なrsyncコマンドのパッケージのインストールを行います。
対象サーバー：全サーバー
- rsyncインストール確認
※rsyncが存在する場合は手順２、手順３はスキップ
# yum list installed | grep rsync
2.rsyncインストール
# yum install rsync
3.rsyncインストール確認
# yum list rsync
4.rsync コマンドが利用可能であることを確認
# which rsync
5.rsync動作確認
※rsync -vnは-nオプションでリハーサルをする。実際にバックアップ動作をする場合は外す
# mkdir /root/from/ /root/to/ # ls -l /root/from/ /root/to/ # vi /root/from/test1.txt # rsync -vn /root/from/test1.txt /root/to/
rsync設定
サーバー間の同期を高速にするため、インストールしたrsyncをデーモンモードで動作させrsync サーバー機能を追加します。
対象サーバー：全サーバー
- rsync設定ファイル作成
# vi /root/.ssh/rsyncd.secrets
rsyncd.secretsの設定内容は以下になります。
サーバー１ root:fjadmin
サーバー2 fjadmin
サーバー3 root:fjadmin
2.権限変更
# chmod 600 /root/.ssh/rsyncd.secrets
3.confファイル作成
# vi /etc/rsyncd.conf use chroot = yes ← デフォルト"yes" uid = root ← rsyncをデーモンモードできどうする時の UIDを指定 gid = root ← rsyncをデーモンモードできどうする時の GIDを指定 syslog facility = local0 ← syslogレベル log file = /var/log/rsync.log ← ログファイル出力場所 pid file = /var/run/rsyncd.pid ← pidファイル出力場所 lock file = /var/run/rsync.lock ← lockファイル出力場所 auth users = root ← ユーザー指定 secrets file = /root/.ssh/rsyncd.secrets ← パスワードファイル指定 [add_disk1] ← モジュール名 path = /add_disk1/ ← モジュールのルートにするパスを指定 host allow = [IPアドレス or ホスト名] ← 接続を許可するクライアントのホスト名とIPアドレスパターンを指定（スペース区切り） host allow = 192.168.10.3 192.168.10.11 ← バックアップ元サーバー用 host allow = 192.168.10.2 192.168.10.11 ← 1次バックアップサーバー用 host allow = 192.168.10.2 192.168.10.3 ← 2次バックアップサーバー用 read only = false ← クライアントがファイルをアップロードできるかどうかを設定。"true"だとアップロード不可 auth users = root ← ユーザー指定 secrets file = /root/.ssh/rsyncd.secrets ← パスワードファイル指定
4.デーモン起動
※サーバー１、サーバー３で実施。
# rsync --daemon # ps -ef | grep rsync ← 出力結果に"/etc/rsyncd.conf"の内容があることを確認する。
検証
cron設定でrsyncを周期実行させて各構成パターン(1)～(3)の検証を実施します。
バックアップの実行は以下のコマンドを使用します
time rsync -av --password-file=[パスワードファイル] root@[IPアドレス]::[モジュール名]/[バックアップ元] [バックアップ先]
rsyncのログに記載されるのは以下の内容になります。
転送バイト数：バックアップ元からバックアップ先に対して送られた情報量
平均転送速度[Byte/s]：バックアップ元からバックアップ先への平均転送速度
転送された総容量：バックアップ元のデータをバックアップした際の総容量
転送効率：rsync実行時の転送効率。通常のファイルコピーに比べ、rsyncを使用することで、どの程度効率的にバックアップが行うこと ができたかを判別 ※算出式 4.転送された総容量 / (1.転送バイト数 + 2.受信バイト数)
検証パターン(1)
サーバー２からrsync実行し、サーバー１のデータをローカルへバックアップし、コピーしたデータをサーバー３(リモート)へバックアップします。
また、サーバータイプの違いの性能も計測するため、Type-hの場合とType-cの場合の検証も実施します。
cron設定
- スクリプト作成
# vi /etc/rsync.sh #! /bin/bash # パターン1非圧縮 time rsync -av --password-file=/root/.ssh/rsyncd.secrets root@192.168.10.2::add_disk1 /add_disk1/ >> /var/log/cron_rsync.log && \ time rsync -av --password-file=/root/.ssh/rsyncd.secrets /add_disk1/ root@192.168.10.11::add_disk1 >> /var/log/cron_rsync.log
# crontab -l # crontab -e 書式：分 時 日 月 曜日 <実行コマンド> 0 2 * * * /etc/rsync.sh ←毎日2時にrsync.shを実行する設定 # crontab -l
パターン(1)実行
- 以下cronでの実行結果です。1次バックアップでは、Type-hと比較してType-cは1Gbps程度になっています。公開されているベンチマークの値も同程度のためネットワークのスループットの上限値である模様です。
| 1次バックアップ | パターン(1)(Type-h) 標準フラッシュ⇒高速フラッシュ |
パターン(1)(Type-c) 標準フラッシュ⇒高速フラッシュ |
|---|---|---|
| 実行時間[s] (timeコマンド) |
208秒 | 685秒 |
| 平均転送速度[MB/s] (rsync出力) |
389.5MB/s | 118.5MB/s |
| 2次バックアップ | パターン(1)(Type-h) 高速フラッシュ⇒標準フラッシュ |
パターン(1)(Type-c) 高速フラッシュ⇒標準フラッシュ |
|---|---|---|
| 実行時間[s] (timeコマンド) |
781秒 | 777秒 |
| 平均転送速度[MB/s] (rsync出力) |
104MB/s | 105.2MB/s |
検証パターン(2)
- サーバー２からrsync実行し、サーバー１のデータをローカルへバックアップし、コピーしたデータをサーバー３(リモート)へバックアップします。
cron設定
検証パターン(1)と同じパターン(2)実行
- 以下cronでの実行結果です。1次バックアップでは、パターン➀と比較して高速フラッシュと標準フラッシュの差が出ました。
| 1次バックアップ | パターン(2) 標準フラッシュ⇒標準フラッシュ |
|---|---|
| 実行時間[s] (timeコマンド) |
755秒 |
| 平均転送速度[MB/s] (rsync出力) |
107.5MB/s |
| 2次バックアップ | パターン(2) 標準フラッシュ⇒標準フラッシュ |
|---|---|
| 実行時間[s] (timeコマンド) |
786秒 |
| 平均転送速度[MB/s] (rsync出力) |
103.5MB/s |
検証パターン(3)③
- サーバー１からrsync実行し、サーバー１のデータをサーバー3(リモート)へ バックアップします。
cron設定
対象サーバー：サーバー１
- スクリプト作成
# vi /etc/rsync.sh #! /bin/bash # パターン3非圧縮 time rsync -av --password-file=/root/.ssh/rsyncd.secrets /add_disk1/ root@192.168.10.11::add_disk1
2.crontab設定
検証パターン(1) 2.crontab設定と同じ
パターン(3)実行
- 以下cronでの実行結果です。1次バックアップでは、やはりパターン(1)が有効ですが、パターン(1)2次バックアップ、パターン(2)１、2次バックアップについては差はありませんでした。
| 直接別リージョンバックアップ | パターン(3) 標準フラッシュ⇒標準フラッシュ |
|---|---|
| 実行時間[s] (timeコマンド) |
756秒 |
| 平均転送速度[MB/s] (rsync出力) |
107.4MB/s |
検証結果
最終的な検証結果を下記にまとめました。
- 実行時間
- 平均転送速度
| 1次バックアップ | パターン(1) (Type-h) 標準フラッシュ⇒高速フラッシュ |
パターン(2) 標準フラッシュ⇒高速フラッシュ |
パターン(3) (Type-c) 標準フラッシュ⇒高速フラッシュ |
|---|---|---|---|
| 実行時間[s] (timeコマンド) |
208秒 | 755秒 | 685秒 |
| 平均転送速度 [MB/s] (rsync出力) |
389.5MB/s | 107.5MB/s | 118.5MB/s |
| 2次バックアップ | パターン(1) (Type-h) 高速フラッシュ⇒標準フラッシュ |
パターン(2) 標準フラッシュ⇒標準フラッシュ |
パターン(1) (Type-c) 高速フラッシュ⇒標準フラッシュ |
| 実行時間[s] (timeコマンド) |
781秒 | 786秒 | 777秒 |
| 平均転送速度 [MB/s] (rsync出力) |
104MB/s | 103.5MB/s | 105.2MB/s |
| 直接別リージョンバックアップ | パターン(3) 標準フラッシュ⇒標準フラッシュ |
||
| 実行時間[s] (timeコマンド) |
756秒 | ||
| 平均転送速度 [MB/s] (rsync出力) |
107.4MB/s |
1次バックアップの実行時間では、パターン(1)(Type-h)がパターン(2)、パターン(1)(Type-c)と比べて約3.2～3.6倍速い
1次バックアップの平均転送速度では、パターン(1)(Type-h)がパターン(2)、パターン(3)(Type-c)と比べて約3.2～3.6倍多くデータ転送を行っている
2次バックアップの実行時間、平均転送速度ともにすべてのパターン検証において差はない
パターン(3)の検証では同条件のパターン(2)2次バックアップと比べて実行時間、平均転送速度ともにに差はない
まとめ
本記事では、マルチリージョン二次バックアップパターンの構成をもとに他構成とのバックアップ時間等の比較検証を行いました。
本検証結果の通りサーバーType-h、高速フラッシュディスクを利用して同一リージョン内で一次バックアップすることにより、冒頭で記載した直接別リージョンにバックアップする場合に発生する以下のような問題を解決できる可能性があります。
- 夜間などのサービス時間外にバックアップを設定してもサービス開始前までにバックアップが完了しない。
- RTOを重視したいが、復旧データの転送時間が遅い。
そのためマルチリージョン２次バックアップパターンはマルチリージョンでのバックアップの構成に入れる選択肢の1つのだと思います。
注意事項
- 本記事については検証結果の１つとなります。実際に検討される場合は、事前にそれぞれの要件を鑑みて実装するか確認してください。
- 本記事ではOS上の操作についても記載していますが、ニフクラではOS以上はご利用者様の責任範囲となりますのでご留意ください。
- 本記事に記載されている会社名、製品名等の固有名詞は各社の商号、登録商標または商標です。
