NFS から Kafka へのワークロードの名前変更に関する問題に対するNetApp のソリューション
変更を提案
PDF
Kafka は、基盤となるファイルシステムが POSIX 準拠 (たとえば、XFS または Ext4) であることを前提に構築されています。 Kafka リソースの再バランス調整により、アプリケーションがまだ使用しているファイルが削除されます。 POSIX 準拠のファイル システムでは、unlink を続行できます。ただし、ファイルへの参照がすべてなくなった後にのみファイルが削除されます。基礎となるファイルシステムがネットワークに接続されている場合、NFS クライアントはリンク解除呼び出しをインターセプトし、ワークフローを管理します。リンク解除されるファイルには保留中のオープンがあるため、NFS クライアントは NFS サーバーに名前変更要求を送信し、リンク解除されたファイルが最後に閉じられるときに、名前が変更されたファイルに対して削除操作を発行します。この動作は一般に NFS の奇妙な名前変更と呼ばれ、NFS クライアントによって調整されます。
この動作により、NFSv3 サーバーのストレージを使用する Kafka ブローカーで問題が発生します。ただし、NFSv4.x プロトコルには、開かれたリンクされていないファイルに対してサーバーが責任を持つようにすることで、この問題に対処する機能があります。このオプション機能をサポートする NFS サーバーは、ファイルを開くときに所有権機能を NFS クライアントに伝えます。 NFS クライアントは、保留中のオープンがある場合にリンク解除の管理を停止し、サーバーがフローを管理できるようにします。 NFSv4 仕様では実装のガイドラインが提供されていますが、これまでこのオプション機能をサポートする NFS サーバー実装は知られていませんでした。
不合理な名前変更の問題を解決するには、NFS サーバーと NFS クライアントに次の変更が必要です。
-
*NFS クライアント (Linux) への変更。*ファイルが開かれるときに、NFS サーバーは開かれたファイルのリンク解除を処理できることを示すフラグで応答します。 NFS クライアント側の変更により、フラグが存在する場合に NFS サーバーがリンク解除を処理できるようになります。 NetApp は、これらの変更をオープンソースの Linux NFS クライアントに反映しました。更新された NFS クライアントは、RHEL8.7 および RHEL9.1 で一般公開されました。
-
NFS サーバーへの変更。 NFS サーバーはオープンを追跡します。既存の開いているファイルのリンク解除は、POSIX セマンティクスに合わせてサーバーによって管理されるようになりました。最後のオープンが閉じられると、NFS サーバーはファイルの実際の削除を開始し、無駄な名前変更プロセスを回避します。 ONTAP NFS サーバは、最新リリースのONTAP 9.12.1 でこの機能を実装しました。
NFS クライアントとサーバーに上記の変更を加えることで、Kafka はネットワーク接続された NFS ストレージの利点をすべて安全に享受できるようになります。