1. Alluxio アプリケーションのシナリオと背景
Alluxio のクラスタ間同期メカニズムの設計と実装により、複数の Alluxio クラスタを実行するときにメタデータの一貫性が確保されます。
Alluxio はストレージ層とコンピューティング層の間に位置し、基盤となるさまざまなファイル システム (UFS) 上で高性能のキャッシュと統一された名前空間を提供します。Alluxio 経由で UFS を更新すると、Alluxio と UFS の一貫性が保たれますが、1 つ以上の UFS 名前空間を共有する複数の Alluxio クラスタを実行している場合など、場合によってはそうでないことがあります。この場合の一貫性を確保するために、Alluxio はクラスタ間同期メカニズムを実装しました。これについては、この記事で詳しく紹介します。
1. 背景の紹介
データの量が増加するにつれて、データの保存方法とアクセス方法はますます複雑になります。たとえば、データは異なるストレージ システム (S3、GCP、HDFS など) に配置されたり、クラウド上またはローカルに保存されたり、地理的に異なる地域に配置されたり、プライバシーやセキュリティ保護のためにさらに分離されたりする場合があります。さらに、これらの複雑さはデータ ストレージだけでなく、計算にデータが使用される方法にも当てはまります。たとえば、計算はローカルで行われる一方で、データはクラウドに保存される場合があります。
Alluxio は、UFS 上で統合されたアクセス インターフェイスを提供することでそのような複雑さを軽減し、データの局所性とキャッシュを提供することでコンピューティング パフォーマンスを向上させるデータ オーケストレーション プラットフォームです。
多くの組織では、1 つの Alluxio クラスタを実行するだけで十分ですが、組織によっては複数の Alluxio クラスタを実行する必要があります。たとえば、計算が複数のリージョンで実行される場合、各リージョンで Alluxio クラスターを実行する方が有利な場合があります。さらに、組織によっては、データ プライバシーの懸念から個別のクラスターを実行する必要がある場合や、複数のクラスターを実行してスケーラビリティを向上させたい場合があります。データ空間の一部はクラスター内で分離できますが、他のデータは複数のクラスター間で共有できます。たとえば、1 つのクラスターがデータの抽出と変換を担当し、他のいくつかのクラスターがそのデータをクエリして更新を行う場合があります。
各 Alluxio クラスタは UFS ストレージ領域の一部を複製 (つまりマウント) する可能性があるため、Alluxio はそのコピーを UFS と一貫性を保つ責任を負い、ユーザーが最新のファイル コピーをクエリできるようにします。この記事では、1 つ以上のクラスタ間で Alluxio データと UFS の一貫性を保つために使用されるコンポーネントについて説明します。
2. Alluxio データの一貫性
分散システムでデータの一貫性を維持することは複雑であり、数十の異なる一貫性レベルがあり、それぞれのレベルで異なるユーザーが特定の時点でデータの異なる状態をクエリおよび変更できます。これらの整合性レベルは弱いものから強いものまでの範囲を形成し、整合性が強いほど制限が厳しくなり、一般にアプリケーションを構築しやすくなります。Alluxio も例外ではなく、使用される構成と UFS に応じてさまざまな一貫性保証を提供します (詳細については、Alluxio のデータ一貫性モデルを参照してください)。
一貫性に関する議論を簡単にするために、次の仮定を立てます。
● どのようなファイルにおいても、UFS はそのファイルの「唯一の信頼できる情報源」です。
これは、Alluxio のすべてのファイルが UFS 上のファイルに対応し、UFS には常にそのファイルの最新バージョンが存在することを意味します。Alluxio に保存されているファイルのコピーが UFS のファイルと異なる場合、Alluxio のファイル バージョンは一貫性がありません。(ここでは、UFS 自体が強い一貫性、つまり、ある程度の線形化可能性または外部一貫性を保証していると仮定します。高いレベルでは、これにより、ユーザーは (システムが多くの数式部分によって分散されている場合でも) UFS を単一のものとしてアクセスできるようになります。リアルタイムで順次操作を実行するファイル システム。
Alluxio と UFS の間の一貫性について説明する前に、Alluxio の基本アーキテクチャを見てみましょう。Alluxio はマスター ノードとワーカー ノードで構成されます。マスター ノードは、ファイルのパス、サイズなどのメタデータを追跡する責任を負い、ワーカー ノードはデータ自体を保存する責任を負います。クライアントがファイルを読み取りたい場合は、まず特定のマスター ノードからメタデータを読み取り、次にそれを使用してデータのコピーを保存するワーカーを見つける必要があります (必要に応じてデータは UFS からロードできます)。クライアントがファイルを書き込みたい場合は、まずマスター内でファイルのメタデータを作成し、次にワーカーを通じてファイルを UFS に書き込み、最後にマスター上でファイルを完了としてマークする必要があります。ファイルの書き込み中、そのメタデータは不完全としてマークされ、他のクライアントがファイルにアクセスできなくなります。
この基本設計から、ファイルへのすべての更新が Alluxio を通じて UFS に書き込まれる限り、Alluxio のデータは UFS のデータと一致し、クライアントは常に最新のデータ バージョンをクエリすることがわかります。
しかし、実際にはそれほど単純ではありません。たとえば、一部のユーザーが UFS の更新時に Alluxio を渡さない場合や、クライアントが失敗して、Alluxio マスター上で完了マークを付けずに一部のファイルを UFS に書き込むだけである場合があります。 Alluxio と UFS は矛盾しています。
では、これらの問題はどのように解決されるのでしょうか? 主に UFS が唯一のデータ ソースであると想定しているため、これらの不一致を解決するには、Alluxio を UFS と同期させるだけで済みます。
3. メタデータの同期
メタデータ同期は、Alluxio と UFS 間の不一致をチェックして修正するために使用される主要なコンポーネントです。クライアントが Alluxio のパスにアクセスすると、特定の条件下でこの機能がトリガーされることがあります (後述)。基本的な手順は次のとおりです。
● UFS からパスのメタデータをロードします。
● UFS のメタデータを Alluxio のメタデータと比較します。メタデータにはファイル データのフィンガープリント (最終変更時刻や耐衝突ハッシュなど) が含まれており、データの不整合をチェックするために使用できます。
● 不一致が見つかった場合、Alluxio のメタデータが更新され、古いデータはワーカーからの削除対象としてマークされます。最新のデータは、必要に応じて UFS からワーカーにロードされます。
図: クライアントが読み取るときのメタデータ同期プロセス。1. クライアントはファイル システム内のパスを読み取ります。2. マスター上のメタデータ同期モジュールは、ユーザー設定に従って同期が必要かどうかを確認します。3. UFS からメタデータをロードして同期し、Alluxio と UFS のメタデータを比較するためのフィンガープリントを作成します。フィンガープリントが異なる場合、Alluxio のメタデータが更新されます。4. クライアントは、更新されたメタデータに従ってワーカーからファイル データを読み取り、必要に応じて UFS からデータをロードします。
唯一の問題は、このメタデータ同期手順をいつ実行するかを決定することであり、これには、より強力な一貫性とより良いパフォーマンスの間でトレードオフを行う必要があります。
データにアクセスするたびにメタデータを同期
Alluxio のクライアントがパスにアクセスするたびにメタデータの同期を実行すると、クライアントは常に UFS 上の最新のデータ ステータスを表示できるようになります。これにより、最高レベルの一貫性、通常は UFS が保証できる最強の一貫性が得られます。ただし、データへのすべてのアクセス (データが変更されていない場合でも) が UFS と同期するため、パフォーマンスの低下にもつながります。
時間に基づいたメタデータの同期
さらに、物理的な時間間隔に基づいてメタデータの同期を実行できます。この場合、Alluxio マスター上のメタデータには、パスが最後に UFS と正常に同期された時間が含まれています。現在、新しい同期は、ユーザー定義の時間間隔が経過した後にのみ発生します (詳細については、「UFS メタデータの同期」を参照してください)。
このアプローチはパフォーマンスを大幅に向上させる可能性がありますが、結果的な一貫性といった一貫性の保証レベルが比較的弱くなる可能性もあります。これは、特定の読み取り結果が UFS と一致する場合と一致しない場合があることを意味します。さらに、データ更新がクエリされる順序は任意でありえます。たとえば、UFS では、実際にはファイル A の更新は別のファイル B の更新よりも早いですが、Alluxio クラスタはファイル B の更新がファイル A よりも早いことをクエリする場合があります。したがって、システムのユーザーは、これらのさまざまなレベルの一貫性保証を理解し、必要に応じてアプリケーションを調整する必要があります。
2. クラスタ間の同期メカニズム
前の章では、単一の Alluxio クラスターのシナリオ、バックグラウンド、およびメタデータの同期について説明しました。この章では、マルチクラスタ シナリオでメタデータの同期を確立してメタデータの整合性を確保する方法を紹介します。
1. 時刻同期に基づくマルチクラスターの整合性
時間ベースのメタデータ同期の使用例の 1 つは、複数の Alluxio クラスターが使用され、クラスターが UFS データ スペースの一部を共有する場合です。多くの場合、これらのクラスターは、ある時点でデータを共有する必要がある可能性がある別個のワークロードを実行していると考えることができます。たとえば、あるクラスターがある日のデータを取り込んで変換し、翌日には別のクラスターがそのデータをクエリする場合があります。クエリ タスクを実行するクラスターは、常に最新のデータを参照する必要があるわけではありません。たとえば、最大 1 時間の遅延は許容されます。
実際には、特定のワークロードのみがファイルを定期的に更新するため、時間ベースの同期を使用しても常に機能するとは限りません。実際、多くのワークロードでは、ほとんどのファイルは 1 回だけ書き込まれますが、頻繁に更新されるファイルはごく一部です。この場合、ほとんどの同期は不要であり、時間間隔を長くすると、頻繁に変更されたファイルが長期間不整合な状態になるため、時間ベースの同期の効率が低下します。
2. クラスタ間の同期を使用して、マルチクラスタの整合性を実現します。
時間ベースの同期の非効率性を回避するために、クラスタ間同期機能により不整合を直接追跡できるため、必要な場合にのみファイルが同期されます。これは、Alluxio クラスタでパスが変更されるたびに、クラスタはパスが変更されたことを他の Alluxio クラスタに通知する無効化メッセージを発行することを意味します。次回、クライアントがサブスクライブ (クラスター間同期機能) クラスター上のこのパスにアクセスすると、UFS との同期操作がトリガーされます。
クラスタ間同期には、時間ベースの同期に比べて 2 つの主な利点があります。第一に、同期は変更されたファイルに対してのみ実行されます。第二に、あるクラスターから別のクラスターにメッセージを送信するのにかかる時間とほぼ同じ時間で、変更は他のクラスターにすぐに表示されます。
このことから、クラスタ間同期機能は、次の前提条件が満たされる場合に最も効果的であることがわかります。
● 複数の Alluxio クラスタにマウントされた 1 つ以上の UFS にクロスセクションがあります。(システムにデプロイされる Alluxio クラスターの数の適切な範囲は 2 ～ 20 であると考えられます)。
● 少なくとも 1 つのクラスターが UFS 上のファイルを更新します。
● UFS へのすべての更新は、Alluxio クラスターを経由する必要があります (他のケースの処理方法については、以下の「その他の使用例」を参照してください)。
ここで、アプリケーションがクラスタ間でデータを共有できるように、1 つの Alluxio クラスタからの更新が他のすべての Alluxio クラスタで最終的に監視されることを確認します (つまり、クラスタと UFS が結果整合性の保証を満たしている)。
パスの無効化のパブリッシュ/サブスクライブ
クラスタ間同期機能は、パブリッシュ/サブスクライブ (pub/sub) メカニズムに基づいて実装されます。Alluxio クラスタが UFS パスをマウントすると、そのパスをサブスクライブし、クラスタが UFS 上のファイルを変更するたびに、変更されたパスをすべてのサブスクライバに公開します。
表 1: 異なる UFS パスをマウントする 3 つの Alluxio クラスターの例。
表 1 の例を参照すると、Alluxio クラスターが 3 つあり、各クラスターは異なる S3 パスをマウントします。ここで、クラスター C1 は S3 バケット (バケット) s3://bucket/ をローカル パス /mnt/ にマウントし、クラスター C2 は同じバケットのサブセット s3://bucket/folder をローカル パス /mnt /folder にマウントします。 、最後に C3 は s3://bucket/other をルート パス / にマウントします。
したがって、クラスター C1 はパス (pub/sub セマンティクスの「トピック」) s3://bucket にサブスクライブし、クラスター C2 はパス s3://bucket/folder にサブスクライブし、クラスター C3 はパス s3 にサブスクライブします。 //バケツ/その他。サブスクライバーは、サブスクリプションの「トピック」で始まるすべての公開メッセージを受信します。
たとえば、クラスター C1 がファイル /mnt/folder/new-file.dat を作成すると、 s3://bucket/folder/new-file.dat を含む無効なメッセージがパブリッシュされ、クラスター C2 がそれを受信します。また、クラスター C1 がファイル /mnt/other-file.dat を作成する場合、s3://bucket/other-file.dat と一致するトピックを持つサブスクライバーが存在しないため、メッセージは送信されません。
前述したように、Alluxio のメタデータには、そのパスで最後に同期が行われた時刻が含まれています。クラスタ間同期の場合、パブリッシュ/サブスクライブ インターフェイス経由で最後にパス障害メッセージを受信した時刻も含まれます。これを利用して、クライアントがパスにアクセスする際、以下の 2 つの場合に UFS と同期します。
a) パスに初めてアクセスする。
b) パスの障害時刻が最後の同期時刻より後である。
システムに障害がないと仮定すると、結果整合性が保証されることは明らかです。ファイルが変更されるたびに、サブスクライブしている各クラスターが無効化メッセージを受信するため、次回ファイルがアクセスされるときに同期が行われます。
図 1: ファイル作成時のクラスタ間同期のメカニズム。A. クライアントはクラスター 1 にファイルを作成します。B. クライアントはファイルをワーカーに書き込みます。C. ワーカーはファイルを UFS に書き込みます。D. クライアントがマスター上のファイルを完成させました。E. クラスタ 1 は、クラスタ 2 のサブスクライバにファイル無効化メッセージを発行します。F. クラスタ 2 は、メタデータ同期コンポーネントでファイルを同期が必要であるとマークします。今後クライアントがファイルにアクセスするときは、図 1 に示す手順 1 ～ 5 も同期に使用されます。
Pub/subメカニズムを実装する
Pub/sub メカニズムは、クラスターが他のクラスターにマウントされているパスを認識できるようにするディスカバリー メカニズム (ディスカバリー メカニズム)、およびメッセージの送信に使用されるネットワーク コンポーネントを通じて実装されます。
検出メカニズムは、CrossClusterMaster と呼ばれる単一の Java プロセスであり、構成可能なアドレスとポートの組み合わせを介してすべての Alluxio クラスターにアクセスできる必要があります。Alluxio クラスターが起動するたびに、CrossClusterMaster にはクラスターのすべてのマスター ノードのアドレスが通知されます。さらに、クラスターが UFS をマウントまたはアンマウントするたびに、マウントされたパスが CrossClusterMaster に送信されます。これらの値が更新されるたびに、CrossClusterMaster ノードは新しい値をすべての Alluxio クラスターに送信します。
この情報を使用して、各 Alluxio クラスターは、そのローカル UFS マウント パスと外部クラスターのすべての UFS マウント パスの交差部分を計算します。交差するパスごとに、クラスター マスターは GRPC 接続を使用して、そのパスをトピックとして持つ外部クラスター マスターへのサブスクリプションを作成します。表 1 の例では、C1 はトピック s3://bucket/folder を使用して C2 へのサブスクリプションを作成し、トピック s3://bucket/other を使用して C3 へのサブスクリプションを作成します。さらに、C2 はトピック s3://bucket/folder を使用して C1 へのサブスクリプションを作成し、C3 はトピック s3://bucket/other を使用して C1 へのサブスクリプションを作成します。このようにして、クラスターがファイルを作成するなどしてパスを変更するたびに、トピックがそのパスのプレフィックスであるすべてのサブスクライバーに、変更されたパスをパブリッシュします。たとえば、C1 がファイル /mnt/other/file を作成すると、s3://bucket/other/file が C3 に公開されます。
他のクラスターへのサブスクリプションをプロアクティブに維持するために、各 Alluxio マスター上でスレッドが実行され、パスのマウントまたはアンマウント、クラスターの結合または切断、および接続障害が処理されます。
サブスクライバがパスを受信するたびに、有効期限メタデータが現在時刻に更新されるため、次回クライアントがパスにアクセスするときに UFS と同期が行われます。上記の例に従うと、次回クライアントがクラスター C3 上のパス /file を読み取るときに、UFS との同期が s3://bucket/other/file で実行されます。
最終的な整合性を確保する
パブリッシュされた各メッセージがすべてのサブスクライバー (将来のサブスクライバーを含む) に 1 回だけ (正確に 1 回) 配信されることが保証できる場合は、変更のたびにサブスクライバーがパスにアクセスするため、明らかに結果整合性が保証されます。ただし、接続が中断されたり、クラスターが切断されてシステムに接続されたり、ノードに障害が発生したりする可能性があります。メッセージの正確な配信を保証するにはどうすればよいでしょうか? 簡単に言うと、それはできません。代わりに、(基盤となる TCP 接続を使用して) サブスクリプションが実行されている間のみ、1 回だけのメッセージ配信が保証されます。さらに、サブスクリプションが最初に確立されると、サブスクライバーはルート パス (トピック) のメタデータを同期が必要なものとしてマークします。これは、トピックであるスーパーセット パスは、サブスクリプションの確立後に最初にアクセスされたときに同期されることを意味します。
たとえば、C1 がトピック s3://bucket/folder を使用して C2 へのサブスクリプションを確立すると、C1 は s3://bucket/folder を同期が必要なものとしてマークします。その後、たとえば、s3://bucket/folder/file に初めてアクセスすると、同期が行われます。
これにより、システム内の障害や構成変更に対処するタスクが大幅に簡素化されます。ネットワークの問題、マスターフェイルオーバー、構成変更などの何らかの理由でサブスクリプションが失敗した場合でも、回復プロセスは同じです。サブスクリプションが再確立され、対応するパスが非同期としてマークされます。ネットワーク問題の影響を軽減するために、ユーザー定義パラメータを設定して、パブリッシャーの送信キューにバッファリングできるメッセージの数と、キューがいっぱいの場合に操作がブロックされる可能性が高くなる前にタイムアウトまで待機する時間を決定できます。 。
もちろん、予想どおり、システムに障害が発生することはありますが、頻繁に障害が発生したり、パフォーマンスが低下したりすることはありません。幸いなことに、頻繁に障害が発生した場合でも、パフォーマンスの低下は時間ベースの同期を使用した場合と同様です。たとえば、5 分ごとに障害が発生した場合、期待されるパフォーマンスは、時間ベース (5 分間隔) の同期が有効になっている場合と同様になります。
CrossClusterMaster プロセスが失敗した場合、新しいクラスターとパス マウントの検出は機能しませんが、クラスターは既存のサブスクリプションを中断することなく維持することに注意してください。さらに、CrossClusterMaster はステートレス (バーチャル シャーシ アドレスおよびマウント パス内のポイントと考えてください) であるため、必要に応じて停止および再起動できます。
他の使用例
前述したように、この機能が動作するには、UFS へのすべての更新が Alluxio クラスターを経由する必要があります。もちろん、この条件が必ずしも満たされるとは限らず、この問題に対処する方法はいくつかあります。
● ユーザーは手動で証跡を同期が必要なものとしてマークできます。
● 時間ベースの同期は、クラスタ間同期と一緒に有効にすることができます。
3. 議論と結論
1. 議論と今後の取り組み
1 回だけのメッセージ配信を保証するパブリッシュ/サブスクライブ メカニズムを使用してみてはいかがでしょうか?
1 回だけのメッセージ配信を保証する pub/sub メカニズムを使用すると、設計が大幅に簡素化されることはわかっています。実際、この問題を正確に解決するために作成された Kafka や RabbitMQ などの強力なシステムが数多くあります。これらのシステムを使用する利点は、障害によるパフォーマンスへの影響が少なくなることです。たとえば、加入者が接続を失った場合、再接続すると、システムは中断したところから再開できます。
それでも、これらのシステムを維持すること自体が非常に複雑な作業です。まず、デプロイする物理マシンの数、メッセージを複製する回数、メッセージを保持する期間、接続の問題によりメッセージを公開できない場合に操作をブロックするかどうかなど、いくつかの問題を把握する必要があります。 。また、最終的には障害回復メカニズムが必要となり、設計がより複雑になる可能性があります。
(結果整合性を実現するには、実際には少なくとも 1 回のメッセージ配信のみが必要であることに注意してください。複数のメッセージ配信は、データの一貫性ではなく、パフォーマンスに悪影響を与えるだけであるためです。ただし、この場合でも、ほとんどの問題が残ります)。
20 を超える Alluxio クラスターに拡張するか、頻繁な障害に対処する
将来的には、数百の Alluxio クラスターへの拡張をサポートしたいと考えていますが、20 クラスターから数百のクラスターへの拡張には、異なる設計上の考慮事項が必要になる可能性があります。第一に、障害がより頻繁に発生すると予想されます。第二に、設計によりマスターに重大なオーバーヘッドが発生する可能性があります。
前述したように、頻繁に障害が発生すると、時間ベースの同期と同様のレベルまでパフォーマンスが低下する可能性があります。数百のクラスターがある場合、ネットワークまたはマスター ノードの障害がかなりの頻度で発生することが予想されます。(障害は、障害が発生した UFS パスと交差する UFS パスがマウントされているクラスターにのみ影響するため、これは構成にも依存することに注意してください。そのため、クラスターのほとんどが結合されていない UFS パスをマウントしている場合は、大きな問題にならない可能性があります)。さらに、すべてのクラスターによってマウントされたパスが交差する場合、他のすべてのクラスターへのサブスクリプションを維持する必要があり、単一のパブリケーションに対して数百のメッセージを送信する必要があります。
この場合、Kafka や RabbitMQ などの信頼できるパブリッシュ/サブスクライブ メカニズムを組み込む必要があるかもしれませんが、これはピアツーピア サブスクリプションの単なる置き換えであり、システム全体の設計の変更ではありません。障害は依然として発生し、クラスターは同じ方法で回復します。つまり、交差する UFS パスに同期が必要であるとマークが付けられます。強固なパブリッシュ/サブスクライブ メカニズムだけが、Alluxio の失敗の多くを隠すことができます。たとえば、メカニズムがメッセージの最後の 5 分間を確実に保存したい場合、元の方法で回復する必要があるのは 5 分を超えて続く障害のみです。さらに、これらのシステムは、Alluxio クラスターの数に関係なく拡張でき、必要に応じてノードを追加できます。ただし、これらのシステムを使用および保守すると、大量のオーバーヘッドが発生するため、特定の構成でのみ試す価値がある場合があります。
一貫性についての考え
この記事では結果整合性を確保するための基本的な考え方を紹介しますが、詳細には説明されていない重要な内容がまだいくつかあります。
第一に、UFS への変更が完了した後に無効化メッセージを公開する必要があります。第二に、UFS は線形整合性または外部整合性 (S3 での整合性) のレベルで強力な整合性を保証する必要があります。これら 2 つの条件のいずれかが満たされていない場合、サブスクライバが無効化を受信して同期を実行するときに、クラスタはファイルの最新バージョンを監視できない可能性があります。3 番目に、クラスターが CrossClusterMaster から切断され、後で再確立された場合、切断中に外部クラスターがパスをマウントおよび変更した可能性があるため、クラスターもフェイルバック プロセスを実行する必要があります。
完全なメタデータを公開する
前述したように、公開される無効化メッセージには、変更されたパスのみが含まれます。ただし、これらのメッセージにはパスの更新されたメタデータが含まれる場合もあり、サブスクライブしているクラスターでの同期が回避されます。どのバージョンのメタデータが最新バージョンであるかを知る通常の方法がないため、これは行われません。
たとえば、2 つの Alluxio クラスタ C1 と C2 は、UFS 上の同じファイルを更新します。UFS では、クラスター C1 の更新はクラスター C2 の更新の前に行われます。その後、両方のクラスターが更新されたメタデータを 3 番目のクラスター C3 に公開します。ネットワークの状況により、C2 のメッセージは C1 よりも先に到着します。この時点で、C3 はすでに最新のメタデータ バージョンを持っているため、C1 からの更新を破棄する必要があることを認識する必要があります。もちろん、メタデータにバージョン情報が含まれている場合はこれを実行できますが、残念ながら、Alluxio がサポートするすべての UFS では、通常の方法では実行できません。したがって、C3 では、唯一のデータ ソースから直接最新バージョンを取得するために、UFS とのメタデータ同期が依然として必要です。
通知サービスの購読
Amazon SNS や HDFS iNotify などの特定の Underlying Storage System (UFS) は、ファイルが変更されたことをユーザーに知らせる通知サービスを提供します。このタイプの UFS の場合、Alluxio クラスターにサブスクライブするよりも、これらのサービスにサブスクライブする方が良いオプションである可能性があります。この利点は、Alluxio を使用せずに UFS への書き込みをサポートしていることです。繰り返しますが、システム設計は同じままで、他の Alluxio クラスターにサブスクライブする代わりに、そのような通知サービスにサブスクライブするだけです。
Alluxio は HDFS 用の ActiveSync 機能も提供し、メタデータを基礎となる UFS と同期を保つことができることに注意してください。これは、クラスタ間の同期メカニズムとは異なります。ActiveSync はファイルの更新時に同期を実行しますが、クラスタ間同期はファイルがアクセスされたときにのみ同期を実行します。
4. 結論
この記事では主に、複数の Alluxio クラスタを実行することで利点が得られるシナリオと、Alluxio が時間ベースの同期機能とクラスタ間同期機能を使用してクラスタとマウントされた UFS の同期を維持する方法を紹介します。クラスタ間同期機能の導入方法の詳細については、クリックして原文を読んでください。
Alluxio の辛口記事、人気のイベント、専門家の共有について詳しく知りたい場合は、クリックして[Alluxio Think Tank]に入ってください。
