オブジェクトストレージ内のバックアップのストレージを最大 90% 圧縮する方法

当社のトルコの顧客は、データセンターのバックアップを適切に構成するよう私たちに求めてきました。 私たちはロシアでも同様のプロジェクトを行っていますが、ここでの話はどちらかというと最善の方法を研究することについてでした。

ローカル S3 ストレージがあり、データをオブジェクト ストレージに移動するための新しい拡張機能を獲得し、重複排除をサポートする Veritas NetBackup があり、このローカル ストレージの空き領域に問題があるとします。

タスク: バックアップ コピーを保存するプロセスが迅速かつ安価になるようにすべてを行うこと。

実際、これ以前は、S3 内のすべてのものは単なるファイルであり、これらはデータセンターの重要なマシンの完全なキャストでした。 つまり、あまり最適化されていませんが、最初はすべてが機能していました。 今こそ、それを理解し、正しく実行するときです。

写真は私たちがたどり着いたものを示しています:

ご覧のとおり、最初のバックアップはゆっくりと (70 Mb/秒) 行われましたが、同じシステムの後続のバックアップははるかに高速でした。

実際には、どのような機能があるかについてもう少し詳しく説明します。

ダンプの半ページを読む準備ができている人のためのバックアップ ログ再スキャンでフル
Dec 18, 2018 12:09:43 PM — 情報 bpbkar (pid=4452) アクセラレータは 14883996160 バイトのうち 14883994624 バイトをサーバーに送信しました、最適化 0.0%
18 年 2018 月 12 日 10:07:23002 PM - 情報 NBCC (pid=3) StorageServer=PureDisk_rhceph_rawd:s14570817.cloud.ngn.com.tr; レポート = (NBCC) の PDDO 統計 (マルチスレッド ストリーム使用): スキャン: 1760761 KB、送信された CR: 0 KB、FC 経由で送信された CR: 87.9 KB、重複排除: XNUMX%、キャッシュが無効

フル
Dec 18, 2018 12:13:18 PM — 情報 bpbkar (pid=2864) アクセラレータは 181675008 バイトのうち 14884060160 バイトをサーバーに送信しました、最適化 98.8%
18 年 2018 月 12 日 13:40:23527 PM - 情報 NBCC (pid=3) StorageServer=PureDisk_rhceph_rawd:s14569706.cloud.ngn.com.tr; Report=PDDO 統計 (NBCC): スキャン: 45145 KB、CR 送信: 0 KB、FC 経由で送信された CR: 99.7 KB、重複排除: XNUMX%、キャッシュ無効

増分
Dec 18, 2018 12:15:32 PM — 情報 bpbkar (pid=792) アクセラレータは 9970688 バイトのうち 14726108160 バイトをサーバーに送信しました、最適化 99.9%
18 年 2018 月 12 日 15:53:23656 PM - 情報 NBCC (pid=3) StorageServer=PureDisk_rhceph_rawd:s14383788.cloud.ngn.com.tr; Report=PDDO 統計 (NBCC): スキャン: 15700 KB、CR 送信: 0 KB、FC 経由で送信された CR: 99.9 KB、重複排除: XNUMX%、キャッシュ無効

フル
Dec 18, 2018 12:18:02 PM — 情報 bpbkar (pid=3496) アクセラレータは 171746816 バイトのうち 14884093952 バイトをサーバーに送信しました、最適化 98.8%
18 年 2018 月 12 日 18:24:23878 PM - 情報 NBCC (pid=3) StorageServer=PureDisk_rhceph_rawd:s14569739.cloud.ngn.com.tr; Report=PDDO 統計 (NBCC): スキャン: 34120 KB、CR 送信: 0 KB、FC 経由で送信された CR: 99.8 KB、重複排除: XNUMX%、キャッシュ無効

何が問題ですか

顧客は、できるだけ頻繁にバックアップを作成し、できるだけ安価に保存したいと考えています。 S3 などのオブジェクト ストレージに安価に保存するのが最適です。これは、適切な時間内にバックアップをロールバックできるメガバイトあたりのサービスのコストが最も安価であるためです。 バックアップが大量にある場合、ストレージの大部分が同じデータのコピーで占有されるため、あまり安くはなりません。 トルコの同僚の HaaS の場合、ストレージは約 80 ～ 90% 高密度化できます。 これが特に彼らの特性に関係していることは明らかですが、私は間違いなく少なくとも 50% は祖父に期待しています。

この問題を解決するために、主要ベンダーは長い間 Amazon S3 へのゲートウェイを作成してきました。 Amazon API をサポートしている限り、すべてのメソッドはローカル S3 と互換性があります。 この作業スキームがうまく機能しているため、トルコのデータセンターでは、バックアップが当社の S3 とロシアの T-III「コンプレッサー」に行われています。

また、当社の S3 は Amazon S3 バックアップ方法と完全に互換性があります。 つまり、これらの方法をサポートするすべてのバックアップ ツールを使用すると、「すぐに使える」ストレージにすべてをコピーできます。

Veritas NetBackup には CloudCatalyst 機能が追加されました。

つまり、バックアップが必要なマシンとゲートウェイの間には、SRK エージェントからのバックアップ トラフィックが通過し、S3 に転送される前にオンザフライで重複排除される中間 Linux サーバーが存在します。 以前は圧縮された 30 GB のバックアップが 20 件あった場合、現在は (マシンの類似性により) ボリュームが 90% 小さくなっています。 重複排除エンジンは、Netbackup を使用して通常のディスクに保存する場合と同じように使用されます。

中間サーバーの前で何が起こるかは次のとおりです。

私たちはテストを行った結果、データセンターに実装すると、当社と顧客にとって S3 ストレージのスペースが節約できるという結論に達しました。 もちろん、商用データセンターの所有者として、私たちは占有量に応じて料金を請求しますが、それでも私たちにとっても非常に有益です。ハードウェアのレンタルではなく、ソフトウェアのよりスケーラブルな場所で収益を上げ始めるからです。 そうですね、これは内部コストの削減です。

ログ228 ジョブ (キューに入れられたジョブ 0 アクティブ 0 再試行待機中 0 一時停止中 0 未完了 0 完了 — 228 が選択されました)
(フィルター適用[13])

ジョブ ID タイプ 状態 状態の詳細 ステータス ジョブ ポリシー ジョブ スケジュール クライアント メディア サーバー 開始時間 経過時間 終了時間 ストレージ ユニット 試行操作 キロバイト ファイル パス名 完了率 (推定) ジョブ PID 所有者 コピー 親ジョブ ID KB/秒 アクティブ 開始 アクティブ 経過ロボット ボルト プロファイル セッションデータを取り出す ID メディアの移動 オフホスト タイプ マスター優先順位 重複排除速度 トランスポート アクセラレータの最適化 インスタンスまたはデータベース共有ホスト
— 1358 スナップショット完了 0 VMware — NGNCloudADC NBCC Dec 18, 2018 12:16:19 PM 00:02:18 Dec 18, 2018 12:18:37 PM STU_DP_S3_****backup 1 100% root 1358 Dec 18, 2018 12 :16:27 PM 00:02:10 インスタント リカバリ ディスク 標準 WIN-*********** 0
1360 バックアップ完了 0 VMware フル NGNCloudADC NBCC Dec 18, 2018 12:16:48 PM 00:01:39 Dec 18, 2018 12:18:27 PM STU_DP_S3_****backup 1 14,535,248 149654 100% 23858 root 1358 335,098 18月2018日12 、 16 48:00:01 PM 39:0:99.8 インスタント リカバリ ディスク 標準 WIN-*********** 99 XNUMX% XNUMX%
1352 スナップショット完了 0 VMware - NGNCloudADC NBCC Dec 18, 2018 12:14:04 PM 00:02:01 Dec 18, 2018 12:16:05 PM STU_DP_S3_****backup 1 100% root 1352 Dec 18, 2018 12: 14:14 PM 00:01:51 インスタント リカバリ ディスク 標準 WIN-*********** 0
1354 バックアップ完了 0 VMware 増分 NGNCloudADC NBCC Dec 18, 2018 12:14:34 PM 00:01:21 Dec 18, 2018 12:15:55 PM STU_DP_S3_****backup 1 14,380,965 147 100% 23617 root 1352 500,817 18 2018 月12 、 14 34:00:01 PM 21:0:99.9 インスタント リカバリ ディスク 標準 WIN-*********** 100 XNUMX% XNUMX%
1347 スナップショット完了 0 VMware - NGNCloudADC NBCC Dec 18, 2018 12:11:45 PM 00:02:08 Dec 18, 2018 12:13:53 PM STU_DP_S3_****backup 1 100% root 1347 Dec 18, 2018 12: 11:45 PM 00:02:08 インスタント リカバリ ディスク 標準 WIN-*********** 0
1349 バックアップ完了 0 VMware フル NGNCloudADC NBCC Dec 18, 2018 12:12:02 PM 00:01:41 Dec 18, 2018 12:13:43 PM STU_DP_S3_****backup 1 14,535,215 149653 100% 23508 root 1347 316,319 18月2018日12 、 12 02:00:01 PM 41:0:99.7 インスタント リカバリ ディスク 標準 WIN-*********** 99 XNUMX% XNUMX%
1341 スナップショット完了 0 VMware - NGNCloudADC NBCC Dec 18, 2018 12:05:28 PM 00:04:53 Dec 18, 2018 12:10:21 PM STU_DP_S3_****backup 1 100% root 1341 Dec 18, 2018 12: 05:28 PM 00:04:53 インスタント リカバリ ディスク 標準 WIN-*********** 0
1342 バックアップ完了 0 VMware Full_Rescan NGNCloudADC NBCC Dec 18, 2018 12:05:47 PM 00:04:24 Dec 18, 2018 12:10:11 PM STU_DP_S3_****backup 1 14,535,151 149653 100% 22999 root 1341 70,380月18日 2018 12 、 05 47:00:04 PM 24:0:87.9 インスタント リカバリ ディスク 標準 WIN-*********** 0 XNUMX% XNUMX%

1339 スナップショット完了 150 VMware - NGNCloudADC NBCC Dec 18, 2018 11:05:46 AM 00:00:53 Dec 18, 2018 11:06:39 AM STU_DP_S3_****backup 1 100% root 1339 Dec 18, 2018 11: 05:46 AM 00:00:53 インスタント リカバリ ディスク 標準 WIN-*********** 0
1327 スナップショット完了 0 VMware - *******.********.cloud NBCC Dec 17, 2018 12:54:42 PM 05:51:38 Dec 17, 2018 6:46:20 PM STU_DP_S3_****backup 1 100% root 1327 Dec 17, 2018 12:54:42 PM 05:51:38 Instant Recovery Disk Standard WIN-********** 0
1328 バックアップ完了 0 VMware フル *******.********.cloud NBCC Dec 17, 2018 12:55:10 PM 05:29:21 Dec 17, 2018 6:24:31 PM STU_DP_S3_****backup 1 222,602,719 258932 100% 12856 root 1327 11,326 Dec 17, 2018 12:55:10 PM 05:29:21 インスタント リカバリ ディスク 標準 WIN-*********** 0 87.9% 0%
1136 スナップショット完了 0 VMware - *******.********.cloud NBCC Dec 14, 2018 4:48:22 PM 04:05:16 Dec 14, 2018 8:53:38 PM STU_DP_S3_****backup 1 100% root 1136 Dec 14, 2018 4:48:22 PM 04:05:16 Instant Recovery Disk Standard WIN-********** 0
1140 バックアップ完了 0 VMware Full_Scan *******.********.cloud NBCC Dec 14, 2018 4:49:14 PM 03:49:58 Dec 14, 2018 8:39:12 PM STU_DP_S3_****backup 1 217,631,332 255465 100% 26438 root 1136 15,963 14 年 2018 月 4 日 49:14:03 PM 49:58:0 インスタント リカバリ ディスク 標準 WIN-*********** 45.2 0% XNUMX%

アクセラレータを使用すると、エージェントからのトラフィックを削減できます。 データ変更のみが送信されます。つまり、メディア サーバーは増分バックアップから後続の完全バックアップを収集するため、完全バックアップであっても完全にはアップロードされません。

中間サーバーには独自のストレージがあり、そこにデータの「キャッシュ」を書き込み、重複排除用のデータベースを維持します。

完全なアーキテクチャは次のようになります。

1. マスター サーバーは構成、更新などを管理し、クラウドに配置されます。
2. メディア サーバー (中間 *nix マシン) は、ネットワークへのアクセスの観点から、冗長システムに最も近い場所に配置する必要があります。 ここでは、予約されたすべてのマシンからのバックアップの重複排除が行われます。
3. バックアップされたマシンには、通常、ストレージにないものだけをメディア サーバーに送信するエージェントがあります。

すべてはフル スキャンから始まります。これは本格的な完全バックアップです。 この時点で、メディアサーバーはすべてを取得し、重複を排除して S3 に転送します。 メディアサーバーまでの速度は遅いですが、そこからの速度は速くなります。 主な制限はサーバーの計算能力です。

次のバックアップはすべてのシステムの観点から完全に作成されていますが、実際には合成完全バックアップのようなものです。 つまり、メディア サーバーへの実際の転送と記録は、これまでの VM バックアップでまだ検出されていないデータ ブロックに対してのみ行われます。 そして、ハッシュがメディアサーバーの重複排除データベースにないデータブロックのみが転送され、S3 に記録されます。 簡単に言うと、これは単一の VM のバックアップではこれまでに見られなかった現象です。

復元中、メディアサーバーは必要な重複排除されたオブジェクトを S3 に要求し、それらをリハイドレートして IRB エージェントに転送します。 復元中のトラフィック量を考慮する必要があります。これは復元される実際のデータ量と同じになります。

これは次のようなものです。

そして、これが別のログです169 ジョブ (キューに入れられたジョブ 0 アクティブ 0 再試行待機中 0 一時停止中 0 未完了 0 完了 — 169 が選択されました)

ジョブ ID タイプ 状態 状態の詳細 ステータス ジョブ ポリシー ジョブ スケジュール クライアント メディア サーバー 開始時間 経過時間 終了時間 ストレージ ユニット 試行操作 キロバイト ファイル パス名 完了率 (推定) ジョブ PID 所有者 コピー 親ジョブ ID KB/秒 アクティブ 開始 アクティブ 経過ロボット ボルト プロファイル セッションデータを取り出す ID メディアの移動 オフホスト タイプ マスター優先順位 重複排除速度 トランスポート アクセラレータの最適化 インスタンスまたはデータベース共有ホスト
— 1372 復元完了 0 nbpr01 NBCC Dec 19, 2018 1:05:58 PM 00:04:32 Dec 19, 2018 1:10:30 PM 1 14,380,577 1 100% 8548 root 1372 70,567 Dec 19, 2018 1:06:00午後 00:04:30 WIN-*********** 90000

データの整合性は S3 自体の保護によって保証されます。SXNUMX には、ハードドライブスピンドルの故障などのハードウェア障害から保護するための十分な冗長性があります。

メディアサーバーには 4 TB のキャッシュが必要です。これはベリタスの推奨最小サイズです。 多ければ多いほど良いのですが、それが私たちのしたことです。

合計

パートナーが当社の S3 に 20 GB を投入したとき、当社はデータの 60 倍の地理的予約を提供しているため、XNUMX GB を保存しました。 現在はトラフィックが大幅に減少しており、チャネルとストレージ料金の両方にとって良いことです。

この場合、ルートは「大きなインターネット」を超えて閉じられますが、VPN L2 経由でインターネット経由でトラフィックを駆動することはできますが、プロバイダーの入口の前にメディア サーバーをインストールすることをお勧めします。

ロシアのデータセンターでのこれらの機能について知りたい場合、または自宅での実装について質問がある場合は、コメントまたは電子メールで質問してください。 [メール保護].

出所： habr.com