OpenStack Swiftを使用したクラウドストレージ用のマルチリージョンクラスターの構成

著者：オレグ・ゲルブフ



昨秋、SwiftStackチームは、複数地域のOpenStack Object Storageクラスター（プロジェクトコード名はSwift）を作成するアプローチの興味深い概要を投稿しました。 このアプローチは、地理的に分散したSwiftクラスターレイアウトに適しています。レプリカの数を減らし（たとえば、3 + 3ではなく3 + 1）、Webexとほぼ同時に作業しました。 私たちのアプローチを簡単に説明し、実装計画とSwiftコードの変更案に焦点を当てたいと思います。

OpenStack Swiftの現状

まず、現在のSwiftアルゴリズムの簡単な概要から始めて、地理的に離れた複数の地域からクラスターを作成するために正確に実行する必要があることを説明します。

指輪

Swiftクラスターの標準リング（リングまたはハッシュリング）は、ストレージデバイスをゾーンに分離できるデータ構造です。 Essexリリースに含まれるswift-ring-builderスクリプトは、オブジェクトのレプリカが同じゾーンに落ちないようにします。



リング構造には、次のコンポーネントが含まれます。

- デバイスリスト ：リングが認識しているすべてのストレージデバイス（ディスク）が含まれます。 このリストの各要素は、デバイス識別子、そのシンボル名、ゾーン識別子、ストレージデバイスがインストールされているデータストレージノードのIPアドレス、ネットワークポート、重み、メタデータを含む辞書です。

- パーティション分散テーブル ：レプリカの数と同じ行数を持つ2次元配列。 配列の各セルには、列インデックスに対応するセクションのレプリカが配置されているデバイスのリスト（デバイスのリストから）が含まれています...

- パーティション領域番号：オブジェクト（/ account / container / objec）へのパスからのMD5チェックサムのビット数。MD5ハッシュのスペース全体をパーティションに分割することを決定します。



フォルサムバージョンでは、リングファイル形式が変更されました。 これらの変更により、処理効率が大幅に向上し、リングバランシングアルゴリズムが再定義されます。 異なるゾーン間でレプリカを配布する必要がある厳密な条件は、ゾーン、ノード、およびデバイスをレイヤーに編成するはるかに柔軟なアルゴリズムに置き換えられました。



リングバランサーは、レプリカをできるだけ遠くに配置しようとします。 できれば異なるゾーンで使用してください。ただし、1つのゾーンしか使用できない場合は、異なるノードで使用してください。 また、使用可能なノードが1つだけの場合は、ノード上のさまざまなデバイスに対して使用できます。 「最大分散」の原理で動作するこのアルゴリズムは、地理的に分散したクラスターをサポートする可能性があります。 これは、地域レベルの図を上部に追加することで実現できます。 リージョンは、ラックまたはデータセンター全体のいずれかである、1つの場所を持つゾーンのグループです。



私たちの提案では、地域はdevsデバイス辞書の同じフィールド（地域）で定義されています。

プロキシサーバー

プロキシサーバーは、クライアントにパブリックSwift APIを提供し、PUT要求での書き込みやGET要求での読み取りなど、オブジェクト、コンテナー、およびアカウントで基本的な操作を実行します。

PUT要求を処理する場合、プロキシサーバーは次のアルゴリズムに従います。



1.オブジェクトへのパスのMD5チェックサムを、形式/アカウント[/コンテナ[/オブジェクト]]で計算します。



2. MD5チェックサムの最初のNビットとしてパーティション番号を計算します。



3.計算されたパーティションのレプリカが保存されているパーティション配布テーブルからデバイスを選択します。



4.手順3で見つかったすべてのデバイスのデバイスのリストから、データストレージノードのIPアドレスとポートを選択します。



5.対応するポート上のすべてのノードへの接続を確立しようとします。少なくとも半分のノードに接続できない場合、PUT要求を拒否します。



6.接続が確立されたすべてのノードでオブジェクトのダウンロード（またはアカウントまたはコンテナの作成）を試みます。 少なくとも半分のダウンロードがキャンセルされた場合、PUTリクエストは拒否されます。



7.データがN / 2 + 1ノード（Nはステップ＃4で見つかったノードの数）にアップロードされると、PUTリクエストが成功したことの確認をクライアントに送信します。



GET要求を処理する場合、プロキシサーバーは一般に次のアルゴリズムを実行します。



1. PUT要求処理アルゴリズムのステップ1〜4を繰り返し、オブジェクトのレプリカを保存するノードのリストを決定します。



2.シャッフル機能を使用してノードのリストをシャッフルし、結果のリストの最初に接続します。



3.接続を確立できない場合は、リストから次のノードに進みます。



4.接続が確立されると、要求への応答としてクライアントへのデータ送信が開始されます。

複製

Swiftのレプリケーションは、個々のオブジェクトではなくパーティションで機能します。 レプリケーターワークフローは、カスタム間隔で定期的に開始されます。 デフォルトの間隔は30秒です。



一般に、レプリケーターは次のアルゴリズムに従います。



1.レプリケータータスクを作成します。 つまり、ノード上のすべてのデバイスをスキャンし、見つかったすべてのデバイスをスキャンし、すべてのパーティションのリストを見つけてから、各セクションの複製辞書を作成します。



{

「パス」：<path_to_partition>、

「ノード」：[replica_node1、replica_node2、...]、

'delete'：<true | false>、

「パーティション」：}



-<path_to_partition>は、パーティションへのファイルシステム内のパスです（/ srv / node // objects /）



-[replica_node1、replica_node2、...]は、パーティションのレプリカを保存するノードのリストです。 リストは、オブジェクトのリングからインポートされます。



-このセクションのレプリカの数がクラスター内の構成されたレプリカの数を超える場合、「delete」はtrueに設定されます。



-セクション識別子番号を表します。



2.複製タスクに従って各セクションを処理します。 それは：



-セクションに削除のマークが付けられている場合、レプリケーターはジョブ['path']ディレクトリの各サブディレクトリをジョブ['nodes']リストのすべてのノードにマップし、レプリカが存在する各ノードにREPLICATE要求を送信し、ジョブ['path']ディレクトリを削除します。



-セクションに削除のマークが付けられていない場合、レプリケーターは、ジョブ['path']ディレクトリのすべてのサブフォルダー（つまり、セクション内のアカウント/コンテナーデータベースおよびオブジェクトファイル）のコンテンツのチェックサムを計算します。 レプリケーターは、ジョブ['partition']セクションのすべてのレプリカに対してREPLICATE要求を発行し、応答としてチェックサム対応セクションのリモートサブフォルダーから受け取ります。 次に、チェックサムマッピングを比較し、rsyncを使用して、変更されたサブフォルダーをリモートノードに送信します。 レプリケーションの成功は、REPLICATE要求を再送信することで確認されます。



3.いわゆる「メイン」レプリカへのアクセスがない場合、レプリケーターはリングクラスのget_more_nodeメソッドを使用します。 この方法は、特定の決定論的アルゴリズムを使用して、このセクションの一時コピーを保存できる「スペア」ノードのセットを決定します...アルゴリズムは、故障した「メイン」デバイスのゾーンを決定し、別のゾーンから「スペア」デバイスを選択して一時を保存しますセクションのレプリカ。 別のデバイスも利用できない場合、3番目のゾーンからノードが選択され、すべてのゾーンとすべてのノードが列挙されるまでサイクルが続きます。

OpenStack Swiftに提案された変更

「領域」レベルをリングに追加する

デバイスのリストに地域フィールドを追加することをお勧めします。 このパラメーターは、以下で説明するようにリングのバランスを取るときにRingBuilderクラスを使用する必要があります。 regionパラメーターは、ゾーンをグループ化することを可能にするシステムの追加レベルです。 したがって、1つのリージョンを構成するゾーンに属するすべてのデバイスは、そのリージョンに属している必要があります。



さらに、リージョンを追加構造としてリングに追加することができます。キーとしてリージョンを、値としてゾーンのリストを含むディクショナリは次のようになります。

キー（地域）	値（ゾーンのリスト）
オースティン	1,2,3
サンノゼ	4,5,6

ゾーンは1つのリージョンにのみ属することができることに注意することが重要です。



この場合、リージョンは以前の使用と同様に使用されますが、リングクラスには、リージョナルゾーン割り当てのディクショナリを処理するための追加コードを含め、特定のデバイスが属するリージョンを決定する必要があります。



デフォルトリージョンをゾーンに割り当てると、すべてのゾーンが単一のデフォルトリージョンに割り当てられ、標準のSwiftの動作が再生されます。



Swiftプロジェクトの最新リリースでは、地域レベルのサポートが既にリングに追加されています。これは、Swiftに基づく地理的に分散したオブジェクトストレージの完全な実装に向けた重要なステップを意味します。

RingBuilderバランシングアルゴリズムの微調整

RingBuilderバランシングアルゴリズムは、デバイスリストの領域設定を認識する必要があります。 アルゴリズムは、さまざまな方法でレプリカを配布するように構成できます。 以下に、プロトタイプの開発用に選択した分散アルゴリズムの可能な実装の1つを示します。

代替配布アルゴリズム

パーティションレプリカは、次の条件下でデバイスに配置する必要があります。

-レプリカは、可能な限り最高レベルの異なるグループに属するデバイスに配置する必要があります（リングバランシングアルゴリズムの標準的な動作）。



-N個のレプリカとM個の領域（ゾーングループ）の場合、各領域に分類されるレプリカの数は、N / M除算の商の整数に等しくなります。 残りのレプリカは、1つのリージョン（このセクションのメインリージョン）に追加されます。



-リージョンには、リージョン内のゾーンの数より多くのレプリカを含めることはできません。



たとえば、このアルゴリズムを使用してN = 3およびM = 2の場合、各領域に1つのレプリカが含まれるリング（3/2の整数部分は1）で、残りの1つのレプリカは2つの領域のいずれかに含まれます。ランダムに選択。 次の図は、上記の例の地域ごとのレプリカの分布を示しています。





プロキシサーバーからリモートリージョンのストレージノードに直接PUT要求を実行することはそれほど簡単ではありません。ほとんどの場合、外部からクラスターの内部ネットワークにアクセスできない場合があります。 したがって、初期実装では、PUT要求の実行時にローカルレプリカのみが記録され、レプリケーションプロセスによってリモートリージョンレプリカが作成されると想定しています。





デフォルトでは、レプリカの数は3で、リージョンは1です。 このケースでは、標準のSwift構成とリングバランシングアルゴリズムを再現しています。

もう一度Get_more_nodesについて

Ringクラスのget_more_nodesメソッドを変更して、一時レプリカの「スペア」ゾーンを選択するときに領域を認識するよう提案します。 アルゴリズムは、失われたレプリカを含む領域のゾーンが最初に選択されるように、「スペア」の候補をソートする必要があります。 ローカルリージョンがゾーンにアクセスできない場合（たとえば、リージョン間のネットワーク接続が閉じられている場合）、アルゴリズムは外部リージョンの1つからゾーンに属するノードを返します。 次の2つのスキームは、2つの極端な場合のアルゴリズムを説明しています。

地域プロキシサーバー

Swiftプロキシサーバーが複数の地理的に分散した地域の環境で正常に動作するには、所属する地域に関する情報が必要です。 プロキシサーバーは、データストレージサーバーに接続するときのネットワーク遅延の分析に基づいて、または構成ファイルから直接この情報を取得できます。 最初のアプローチは、現在のバージョンのSwift（1.8.0）で実装されています。 プロキシサーバーは、各ノードに接続した後の応答時間に基づいてデータストレージノードを並べ替え、読み取りが最も速いノードを選択します。 このアプローチは読み取り要求に対してはうまく機能しますが、書き込み時には、すべての「メイン」ストレージサーバーと、場合によっては複数の「スペア」サーバーを操作する必要があります。 この場合、ローカル領域を決定するための構成方法の方が適しています。



これは、プロキシサーバー構成ファイル（proxy-server.conf）の[DEFAULT]セクションに領域パラメーターを追加することにより、非常に簡単に実装されます。次に例を示します。



[デフォルト]

...

地域=サンノゼ



このパラメーターは、プロキシサーバーがリング読み取り操作に使用します。GET要求を処理するノードを選択する場合にも使用されます。 目標は、プロキシサーバーがローカルゾーン（つまり、プロキシサーバーと同じリージョンに属するゾーン）からストレージノードに接続することを好むことです。



SwiftStackの記事では、この機能はプロキシアフィニティと呼ばれています。



ローカルレプリカが利用可能な場合、プロキシサーバーは外部リージョンに属するホストからデータを読み取らないでください。 これにより、リージョン間のネットワーク接続の負荷を軽減でき、リージョン間にネットワーク接続がない場合にも機能します（一時的な障害またはクラスタートポロジの機能の結果として）。





次に、GETリクエスト処理アルゴリズムのステップ＃2のノードリストシャッフル操作（上記を参照）を、ローカルプロキシサーバー領域に属するドライブがリストの最初に来るようにノードを配置する手順に置き換えます。 このソート後、ローカルリージョナルノードと外部リージョナルノードのリストが個別に混合され、その後、外部リージョナルノードのリストがローカルリージョナルノードのリストに追加されます。 別の方法として、この段階では、最小応答時間でデータストレージノードを選択するための上記の方法を使用できます。

Swiftでのレプリケーション

プロトタイプの地理的に分散したデータセンター間のレプリケーションは、1つのリージョンを持つクラスターの場合と同様に、リージョン全体で機能します。 ただし、複製プロセスの一環として、低速WAN接続を介してクラスター間で大量のREPLICATEを送信できるためです。 これにより、クラスター全体のパフォーマンスが大幅に低下する可能性があります。



この問題の簡単な回避策として、N回目の複製ごとにパーティションがリモート領域のデバイスに転送されるように、カウンターをレプリケーターに追加します。 より複雑なソリューションには、近隣地域に専用のレプリケーターゲートウェイが含まれる場合があり、これは研究プロジェクトの一環として開発されます。



英語のオリジナル記事