マルチリージョン２次バックアップパターンの有効性を解説| Fujitsu Cloud Direct

FJcloud実践

マルチリージョン２次バックアップパターンの有効性を解説

2021年12月24日

この記事は、FJcloud-V(旧ニフクラ)ブログで2021-12-24に公開された記事を移転したものです。 こんにちは、FJcloud-V(旧ニフクラ)技術支援チームです。

近年、企業や公共機関が災害対策におけるDR（Disaster Recovery）を目的として本番サーバーを設置している場所以外の遠隔地に、データをバックアップする需要が増えています。

FJcloud-V(旧ニフクラ)では、複数リージョンを使用できるので遠隔地にバックアップが可能です。

FJcloud-V(旧ニフクラ)で提供しているプライベートブリッジは、プライベートLAN同士をL2接続するネットワークサービスですが、この機能を利用することで簡単にセキュアなネットワーク構成を構築することができます。

ただし、直接別リージョンにバックアップする場合以下のような問題が発生する可能性があります。

夜間などのサービス時間外にバックアップを設定してもサービス開始前までにバックアップが完了しない。
RTOを重視したいが、復旧データの転送時間が遅い。

FJcloud-V(旧ニフクラ)ではそのようなマルチリージョン間でのバックアップの問題を解決するために、

マルチリージョン２次バックアップパターン

を提案しています。

バックアップを1次(バックアップ元)、2次(別リージョン)に分割して、1次バックアップに使用する増設ディスクとして高速フラッシュドライブを使用することで所要時間を短縮する方法があります。

今回、直接別リージョンにバックアップする場合とマルチリージョン２次バックアップパターンでバックアップする場合の性能比較検証を通して

マルチリージョン２次バックアップパターンの有効性をご紹介します。

前提条件

本ブログは、以下の前提知識がある方を想定しています。

FJcloud-V(旧ニフクラ)の基本的なコントロールパネルの操作、サービスを利用する知識

(サーバー作成、ネットワーク構築など) * Linuxサーバーの基本的な操作、知識

検証概要

検証環境構成パターン

以下(1)～(3)の構成パターンで、リージョン間をプライベートブリッジで接続して性能比較を実施検証しました。

プライベートブリッジの構築はブログ：プライベートブリッジでプライベートLAN同士を接続する方法を参照してください。

構成パターン(1)

1次バックアップ高速フラッシュドライブ、2次バックアップ標準フラッシュドライブ使用

構成パターン(2)

1次バックアップ標準フラッシュドライブ、2次バックアップ標準フラッシュドライブ使用

構成パターン(3)

検証実施内容

100MB、500MB、1GBのファイルを各50ファイル作成して合計80GB 150ファイルをrsyncコマンドでバックアップを実行し、所要時間とスループットを計測します。 (ファイルは非圧縮)

利用リソース

今回の検証を実施するにあたり、利用したFJcloud-V(旧ニフクラ)のリソース情報に関して以下に記載します。

※各リソースのアクセス制限に関しては、FJcloud-V(旧ニフクラ)のファイアウォール等を用いて適切に設定の上実施しています。

リソース	数量
プライベート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	-

事前準備

増設ディスクのマウント

サーバー、増設ディスクが作成されて、増設ディスクをマウントしていることをFJcloud-V(旧ニフクラ)ヘルプ(追加したディスクの設定方法)を参照して確認してください。

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

2.crontab設定

# 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)標準フラッシュ⇒標準フラッシュ
---	---	---	---

| 実行時間[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つのだと思います。
- Type-hの詳細、ご検討こちら
- 高速フラッシュディスクの詳細、ご検討こちら

注意事項

本記事については検証結果の１つとなります。実際に検討される場合は、事前にそれぞれの要件を鑑みて実装するか確認してください。
本記事ではOS上の操作についても記載していますが、FJcloud-V(旧ニフクラ)ではOS以上はご利用者様の責任範囲となりますのでご留意ください。
本記事に記載されている会社名、製品名等の固有名詞は各社の商号、登録商標または商標です。

Fujitsu Cloud Direct当社が提供するサービスを法人のお客様へ直接販売するサイトです。

CLOUD NAVIクラウドとは？からクラウドを支える技術や関連用語まで解説