遅延およびパケット損失のあるネットワークでデータをバックアップするためのネットワークプロトコル

信頼できるデータストレージを確保する最も一般的な方法は、定期的にバックアップすることです。 最新のリモートバックアップサービスを使用すると、クラウドサーバーにバックアップを保存し、世界中のどこからでもバックアップにアクセスできます。

数千キロメートルの距離でデータを転送するには数百ミリ秒かかり、パケットの一部は単に宛先に届かない-途中で失われます。 遅延とパケット損失は、インターネットで一般的に使用されているTCPトランスポートプロトコルのパフォーマンスに悪影響を及ぼします。 たとえば、モスクワにいて、3GBファイルをバックアップしたいとします。 このファイルを市内にあるサーバーに転送するには10〜15分かかります。 さて、中国などで外出中にこのファイルを復元したい場合、同じファイルをネットワーク上で数百ミリ秒の遅延で転送すると数時間かかります。







この記事では、インターネット上のバックアップの転送を最適化する方法を検討し、大きな遅延とパケット損失のあるネットワークで作業するときにパフォーマンスを向上させるリモートバックアッププロトコルの概念について説明します。 この記事は、アクロニスのエンジニアの指導の下、ロシア科学アカデミーのアカデミック大学の学生の修士課程の一環として実施された研究に基づいています。



問題を解決する既存の方法を見てみましょう。 1つ目は、コンテンツ転送および配信ネットワーク（CDN）の使用です。 同時に、データは地理的に分散した複数のサーバーに配置されるため、サーバーからクライアントへのネットワークルートが削減され、データ交換手順が高速化されます。 ただし、バックアップを作成するとき、メインデータストリームはクライアントからサーバーに流れます。 さらに、データの物理的な場所には法律および企業の制限があります。



次のアプローチは、WANオプティマイザーを使用することです。 WANオプティマイザーは、ほとんどの場合、広域ネットワークでのアプリケーションパフォーマンスの低下の根本原因を排除または弱めるハードウェアソリューションです。 これを行うには、データ圧縮、キャッシュ、アプリケーションプロトコルの最適化などのメカニズムを使用します。 この種の既存のソリューションは、ほとんどの場合、追加のハードウェアを必要とし、クライアントモビリティを考慮せず、リモートバックアップアプリケーションプロトコルを使用するために強化されていません。



したがって、トランスポートプロトコルレベル以下で動作する既存の方法は、このタスクには適していません。 最適なソリューションは、リモートバックアップ用のアプリケーションプロトコルの開発かもしれません。これは、ネットワークを介したデータ伝送の機能を考慮することができます。 私たちは、まさにそのようなアプリケーションプロトコルの開発に従事します。



すべてのアプリケーションプロトコルは、データ配信にトランスポートレイヤーのサービスを使用するため、最も適切なトランスポートプロトコルを選択することから始めることをお勧めします。 最初に、TCPトランスポートプロトコルのパフォーマンスが低い理由を見てみましょう。 このプロトコルでのデータ転送は、スライディングウィンドウメカニズムによって制御されます。 ウィンドウは基本的に重要です。確認を受信せずに送信できるセグメントの数を決定します。 このウィンドウのサイズの調整には、接続の帯域幅を最大限に活用することと、ネットワークの輻輳を防ぐことの2つの目的があります。 したがって、遅延と損失がある場合のチャネルの負荷不足の原因は、送信機のスライディングウィンドウのサイズの最適でない制御であると結論付けることができます。 TCP輻輳ウィンドウ制御メカニズムは非常に複雑であり、プロトコルバージョンごとに詳細が異なります。 TCPウィンドウ管理の改善は、活発な研究分野です。 提案されているTCP拡張機能（Scalabale TCP、High Speed TCP、Fast TCPなど）のほとんどは、アプリケーションのパフォーマンスを改善するために、ウィンドウ管理の保守性を低くしようとしています。 ただし、大きなマイナス点は、限られた数のプラットフォームで実装しているだけでなく、クライアントおよびサーバーのオペレーティングシステムのカーネルを変更する必要があることです。



遅延とパケット損失のあるネットワークで良好なパフォーマンスを示す可能性のあるトランスポートプロトコルを考慮すると、UDTプロトコルには特に注意を払う必要があります。 UDTプロトコルは、高速ネットワーク用のUDPベースのデータ転送プロトコルです。 UDTプロトコルの機能はTCPプロトコルに似ています。これは、事前に設定された接続でデータストリームを送信するための二重プロトコルであり、配信を保証し、フロー制御メカニズムを提供します。 プロトコルの大きな利点は、アプリケーションレベルでの操作です。これにより、オペレーティングシステムのカーネルに変更を加える必要がなくなります。



TCPとUDTのパフォーマンスを比較するために、クライアント、サーバー、ネットワークエミュレーターで構成されるテストベンチを作成しました。 クライアントおよびサーバーのタスクには、指定されたパラメーターを使用した継続的なトラフィックによるネットワーク負荷が含まれます（このため、iperfユーティリティを使用しました）。 ネットワークエミュレータを使用すると、クライアントとサーバー間で必要なネットワーク特性を変更できます（iproute2パッケージのtcユーティリティ）。







以下の図は、UDTプロトコルのパフォーマンスが、伝送ネットワークの遅延が増加するにつれて、はるかにゆっくりと低下することを示すグラフを示しています。 ただし、多くのインターネットプロバイダーは、ネットワーク機器の負荷を分散するときにUDPトラフィックを制限することが多いことに注意してください。 したがって、インターネット上では、UDPプロトコル（UDPを介して実装）は、そのすべての利点を失うリスクがあります。 それが、このプロトコルが私たちの問題に対する効果的で普遍的な解決策ではない理由です。







次に、SCTPトランスポートプロトコルを調べました。 このプロトコルは、スライディングウィンドウを変更するためにTCPに似たアルゴリズムを使用しますが、エラー制御システムの改善、マルチスレッド、監視付きのパス検索など、多くの追加の利点があります。 ただし、遅延のあるネットワークで作業する場合、ベンチテストではパフォーマンスが低いことが示されました。







その結果、アプリケーションレベルで多数の最適化を使用して、TCPプロトコルをトランスポートとして選択することにしました。 遅延と損失のあるネットワークで作業するときにTCPプロトコルのパフォーマンスを最適化する方法の1つは、最適なウィンドウサイズを選択することです（図a、b）







OSのカーネルレベルでウィンドウサイズを自動調整するアプローチは非常に効果的であるため、ほとんどの最新のOSに組み込まれています。 ただし、これにより、遅延のあるネットワークでチャネルを完全に利用することはできません。これは、テストベンチで実行されたテストで確認されています。 これは、OSの構成で定義されている厳密に制限された間隔でウィンドウサイズの自動調整が行われるという事実によって説明されます。 したがって、大容量のチャネルでは、ウィンドウは最適なサイズに達しません。



2番目の最適化方法は、複数の並列接続を作成することです（図c）。 Wを単一の接続ウィンドウのサイズとすると、利用可能なすべての帯域幅Pが使用されます。帯域幅は、すべてのアクティブなTCP接続間で均等に分割されます。 それらをNとすると、各並列接続で利用可能な帯域幅はP / Nであり、したがって、最適なウィンドウサイズはW / Nです（W = P * RTTであるため）。 したがって、各並列接続の固定ウィンドウサイズがスループットに最適になるようなNを選択できます。 その後、各接続は割り当てられた帯域幅を完全に利用します。 これにより、最終的にシステム全体の生産性が向上します。



また、複数の接続を作成することにより、パケット損失がトランスポートのパフォーマンスに与える悪影響を減らします。 TCPパケット損失が検出されると、プロトコルはウィンドウサイズを乗法的に減少させます。 接続の1つでパケットが失われると、それ自体のウィンドウ（W / N）のみが減少し、単一の接続の場合のWウィンドウは減少しません。 その結果、システムは帯域幅の最大値をすばやく復元できます。



このアプローチの主な問題は、接続数の最適な選択です。不十分な数はネットワークの負荷を軽減し、過剰供給は輻輳を引き起こす可能性があります。 アプリケーションプロトコルの主な目的は、大量のデータの転送です。 これにより、このデータの送信情報を使用して現在のチャネル容量を推定できます。 したがって、最適な接続数を決定するために、次のアプローチを使用することが決定されました。アクティブな並列接続の数は動的に決定され、ネットワークの現在の状態に適応します。 最初に、システムは帯域幅測定間隔としきい値で初期化されます。 次に、データはすべてのアクティブな接続を介して並行して転送されます。 各測定間隔は、送信されたデータに基づいてスループットを推定します。 現在の値は最大値と比較され、しきい値に基づいて、接続数を追加的に増減する決定が行われます。 次に、最大値が更新され、プロセスが再度繰り返されます。 したがって、接続数は最適値の領域で徐々に確立され、チャネルの最大利用率が達成されます。







ここで、作業中のコンピューターのオペレーティングシステムをバックアップすることを考えてみましょう。 高い確率のストレージサーバーには、同じオペレーティングシステムを持つ他のクライアントから到達したデータのブロックがすでにいくつかあると結論付けるのが論理的です。 明らかに、転送されるデータの量を減らすことは、アプリケーションバックアッププロトコルの優れた最適化として役立ちます。 これを行うために、プロトコルにデータ重複排除メカニズムのサポートを追加しました。 その本質は次のとおりです。クライアントデータを小さなセグメントに分割します（プロトコルは既成のセグメントを送信するためのインターフェイスのみを提供します。データを効率的に分割する方法は大きな別のトピックです）。 各セグメントのハッシュ値を計算し、その可用性の要求をサーバーに送信します。 一意のセグメントのみがネットワーク経由で送信されます。



アプリケーションプロトコルが実装するクライアント/サーバー相互作用のモデルを要約して簡単に説明します。 プロトコルのクライアント部分は、サーバー上のファイルと対話するためのPOSIXのようなインターフェイスをユーザーに提供します。 リモートバックアップ手順は、サーバー上の必要なファイルを開くことから始まります。 同時に、クライアントはセッションを開始する要求を開始し、ファイルを開く名前と属性、および目的のセッションパラメータを示します。 サーバーは、クライアント要求の処理に必要なすべてのリソースを作成し、要求の結果と確立されたセッションのパラメーター（セッションID、重複排除ブロックサイズ、ハッシュ関数のタイプ）を示すメッセージで応答します。

セッションの作成後、クライアントは対応するファイルへのデータブロックの書き込みを開始します。 各ブロックについて、クライアントは指定されたハッシュ関数の値を計算し、サーバーにブロックの存在の要求を送信します。 この要求を受信すると、サーバーは自身の重複排除キャッシュにブロックが存在するかどうかを確認します。

• 一致が見つかりました：サーバーは、目的のブロックをストレージ領域に書き込み、クライアントに確認を送信します。
  
  
• 一致が見つかりません。サーバーは、クライアントに目的のブロックの転送を開始するように要求するメッセージで応答します。 ブロックを受信すると、サーバーは確認で応答します。
  
  

ストレージ領域内の各データブロックの記録を保証するために、各ブロックを確認するための非同期メカニズムがアプリケーションレベルで実装されています。 セッションは、ファイルを閉じ、サーバーにセッションを終了する要求を送信することで終了します。 サーバーは、操作の成功に関する情報を返すメッセージで応答します。 また、クライアントのタスクには、ローカルメモリリソースの監視と制御、サーバーの輻輳の監視（受信した確認に基づく）が含まれることに注意してください。



結果のソリューションの特性を検証するために、クライアントとサーバーのプロトタイプの実装を開始しました。 クライアントとサーバーのネットワーク層のアーキテクチャは、1つのスレッドで処理されるイベントに基づいています（図を参照）。







ネットワークと対話するには、非同期の非ブロッキング入出力メカニズムが使用されます。 アーキテクチャの基本はメイン処理サイクルであり、イベントキューを順次処理します（データの受信/送信、新しい接続の処理など）。 イベントを登録すると、イベントが発生したときに呼び出されるハンドラーが設定されます。 処理サイクルをブロックしないように、ハンドラーはすべての労働集約的なタスクをスレッドプールに委任します。 このアーキテクチャを実装するために、クロスプラットフォームlibeventライブラリが選択されました。



サーバーロジックには次のものも含まれます。

• セッションの正しいインストールと完了を処理するセッションマネージャー。
  
  
• データをキャッシュし、ブロックの存在に対するクライアントからの要求を処理するための重複排除ブロック。
  
  
• 永続ストレージにブロックを書き込むためのデータマネージャー。
  
  

クライアント側にはさらに次のものがあります。

• 現在のスループットの見積もり。 指定した間隔で現在のスループットを評価できます。 これを行うために、サーバーの確認に関する情報を受け取り、すべての接続の送信バッファーのステータスを監視します。
  
  
• 接続オプティマイザーの数。 このブロックは、前述の接続最適化ロジックを実装します。 また、このユニットは、ランダムな帯域幅変動の影響を排除する問題を解決します。
  
  
• アウトバウンドバランサー。 すべてのアクティブな接続にデータを均等に分散する必要がありました。
  
  

結果の実装のパフォーマンスを検証するために、スタンドでテストが実施されました。 各遅延値について、サイズが8 KBのランダムデータブロックが1分間連続して送信されました。 組み込みのプロトコル重複排除が無効になっています。







このグラフでは、さまざまなリモートバックアッププロトコルの帯域幅が待機時間に依存していることがわかります。 「By」は、単一のTCP接続を使用するプロトコルです。 「Became」は、TCP接続の数を動的に制御するプロトコルです。 数字は、活性化合物の数を示します。

おわりに

この記事では、大きな遅延と損失があるネットワークでのリモートバックアッププロトコルのパフォーマンスの低下の問題に対処するためのアプローチとメカニズムを見つけようとしました。 クライアントに実装されている接続数の動的な最適化により、ネットワーク遅延が大きい場合にスループットを大幅に向上させることができます。 実装された重複排除メカニズムにより、送信されるトラフィックの量を減らすことができます。つまり、システム全体のパフォーマンスが向上します。 ただし、重複排除の有効性を完全に分析するには、大量の実データと複雑な非サーバーキャッシングアルゴリズムを使用してテストする必要があります。これは、この記事とマスターの研究の範囲を超えています。