NetApp解決策 for silly rename問題 for NFS to Kafka workloads.
変更を提案
PDF
Kafkaは、基盤となるファイルシステムがPOSIXに準拠していることを前提に構築されています。たとえば、XFSやext4です。Kafkaリソースのリバランシングは、アプリケーションがまだファイルを使用している間にファイルを削除します。POSIX準拠のファイルシステムでは、リンク解除を続行できます。ただし、ファイルへのすべての参照が失われた後にのみ、ファイルが削除されます。基盤となるファイルシステムがネットワークに接続されている場合、NFSクライアントはunlink呼び出しを代行受信してワークフローを管理します。リンク解除されているファイルでは保留中のオープンがあるため、NFSクライアントはNFSサーバに名前変更要求を送信し、リンク解除されたファイルの最後のクローズ時に、名前変更されたファイルに対して削除操作を実行します。この動作は、一般にNFSのsilly renameと呼ばれ、NFSクライアントによってオーケストレーションされます。
NFSv3サーバのストレージを使用するKafkaブローカーでは、この動作が原因で問題が発生します。ただし、NFSv4.xプロトコルには、リンクされていない開いたファイルをサーバが処理できるようにすることで、この問題 に対処する機能があります。このオプション機能をサポートするNFSサーバは、ファイルを開いたときに所有権機能をNFSクライアントに通知します。その後、オープン保留中の状態があるとNFSクライアントはリンク解除の管理を中止し、サーバがフローを管理できるようにします。NFSv4の仕様には実装に関するガイドラインが規定されていますが、これまでこのオプション機能をサポートする既知のNFSサーバの実装はありませんでした。
NFSサーバとNFSクライアントで、silly rename問題 に対処するには、次の変更が必要です。
-
* NFSクライアント（Linux）への変更。*ファイルを開くときに、NFSサーバは、開いているファイルのリンクを解除する機能を示すフラグを返します。NFSクライアント側の変更により、フラグが指定された状態でNFSサーバがリンク解除を処理できるようになります。ネットアップでは、これらの変更でオープンソースのLinux NFSクライアントを更新しました。更新されたNFSクライアントがRHEL8.7およびRHEL9.1で一般提供されるようになりました。
-
* NFSサーバーへの変更。* NFSサーバーはオープンを追跡します。既存の開いているファイルのリンク解除は、POSIXセマンティクスと一致するようにサーバーによって管理されるようになりました。最後に開いていたファイルが閉じると、NFSサーバによって実際のファイルの削除が開始されるため、名前の変更が不要になります。この機能は、ONTAP NFSサーバの最新リリースであるONTAP 9.12.1で実装されています。
NFSクライアントとNFSサーバに対する上記の変更により、Kafkaはネットワーク接続型NFSストレージのすべてのメリットを安全に享受できます。