SM-NOTIFY(8) دستورات مدیریت سیستم SM-NOTIFY(8)

sm-notify - ارسال اعلان راه‌اندازی مجدد سیستم به میزبان‌های NFS

/usr/sbin/sm-notify [-dfn] [-m minutes] [-v name] [-p notify-port] [-P path]

دستور sm-notify به سرورها و کلاینت‌های همسایه NFS اطلاع می‌دهد که این سیستم راه‌اندازی مجدد شده تا قفل‌های فایل بازنشانی شوند.

قفل‌های فایل بخشی از وضعیت پایدار فایل‌سیستم نیستند. بنابراین هنگامی که یک میزبان راه‌اندازی مجدد می‌شود، وضعیت قفل از دست می‌رود.

فایل‌سیستم‌های شبکه‌ای نیز باید زمانی که وضعیت قفل به دلیل راه‌اندازی مجدد یک میزبان دوردست از دست می‌رود را شناسایی کنند. پس از راه‌اندازی مجدد یک کلاینت NFS، سرور NFS باید تمام قفل‌های فایل نگه‌داشته‌شده توسط برنامه‌هایی که روی آن کلاینت اجرا می‌شدند را آزاد کند. پس از راه‌اندازی مجدد یک سرور، کلاینت باید قفل‌های فایل نگه‌داشته‌شده توسط برنامه‌های در حال اجرا روی کلاینت را به سرور یادآوری کند.

در NFS نسخه ۲ و نسخه ۳، پروتکل Network Status Monitor (یا به اختصار NSM) برای اعلان راه‌اندازی‌های مجدد به همتایان NFS استفاده می‌شود. در لینوکس، دو مولفه مجزا در فضای کاربر سرویس NSM را تشکیل می‌دهند:

یک برنامه کمکی که پس از راه‌اندازی مجدد سیستم محلی، به همتایان NFS اطلاع می‌دهد
دیمنی که به اعلان‌های راه‌اندازی مجدد از سایر میزبان‌ها گوش می‌دهد و فهرست میزبان‌هایی را که باید هنگام راه‌اندازی مجدد سیستم محلی به آن‌ها اطلاع داده شود، مدیریت می‌کند

مدیر قفل محلی NFS به rpc.statd محلی خود درباره هر همتای دوردستی که باید پایش شود هشدار می‌دهد. هنگامی که سیستم محلی راه‌اندازی مجدد می‌شود، دستور sm-notify راه‌اندازی مجدد را به سرویس NSM در همتایان پایش‌شده اعلام می‌کند. هنگامی که یک سیستم دوردست راه‌اندازی مجدد می‌شود، آن همتا به rpc.statd محلی اطلاع می‌دهد، که آن نیز به نوبه خود اعلان راه‌اندازی مجدد را به مدیر قفل محلی NFS منتقل می‌کند.

نخستین تعامل قفل‌گذاری فایل میان یک کلاینت و سرور NFS باعث می‌شود که مدیران قفل NFS در هر دو همتا با سرویس NSM محلی خود برای ذخیره اطلاعات درباره همتای مقابل ارتباط برقرار کنند. در لینوکس، مدیر قفل محلی با rpc.statd تماس می‌گیرد.

دستور rpc.statd اطلاعات مربوط به هر همتای NFS پایش‌شده را در ذخیره‌ساز پایدار ثبت می‌کند. این اطلاعات نحوه تماس با همتای دوردست در صورت راه‌اندازی مجدد سیستم محلی، نحوه تشخیص اینکه کدام همتای پایش‌شده در حال گزارش راه‌اندازی مجدد است، و نحوه اطلاع‌رسانی به مدیر قفل محلی هنگام اعلام راه‌اندازی مجدد توسط یک همتای پایش‌شده را شرح می‌دهد.

یک کلاینت NFS یک نام میزبان، معروف به caller_name کلاینت، را در هر درخواست قفل فایل ارسال می‌کند. سرور NFS می‌تواند از این نام میزبان برای ارسال فراخوانی‌های ناهمگام GRANT به کلاینت یا اعلان راه‌اندازی مجدد به کلاینت استفاده کند.

سرور NFS لینوکس می‌تواند caller_name کلاینت یا آدرس شبکه کلاینت را به rpc.statd ارائه دهد. برای اهداف پروتکل NSM، این نام یا آدرس به عنوان mon_name همتای پایش‌شده شناخته می‌شود. علاوه بر این، مدیر قفل محلی به rpc.statd می‌گوید که نام میزبان خود را چه می‌اندیشد. برای اهداف پروتکل NSM، این نام میزبان به عنوان my_name شناخته می‌شود.

هیچ تعامل معادلی میان سرور و کلاینت NFS برای آگاه کردن کلاینت از caller_name سرور وجود ندارد. بنابراین کلاینت‌های NFS در واقع نمی‌دانند که سرور NFS ممکن است از چه mon_name در یک درخواست SM_NOTIFY استفاده کند. کلاینت NFS لینوکس نام میزبان سرور استفاده‌شده در دستور mount را برای شناسایی سرورهای NFS در حال راه‌اندازی مجدد ضبط می‌کند.

هنگامی که سیستم محلی راه‌اندازی مجدد می‌شود، دستور sm-notify فهرست همتایان پایش‌شده را از ذخیره‌ساز پایدار می‌خواند و یک درخواست SM_NOTIFY به سرویس NSM در هر همتای دوردست فهرست‌شده ارسال می‌کند. این دستور از رشته mon_name به عنوان مقصد استفاده می‌کند. برای شناسایی اینکه کدام میزبان راه‌اندازی مجدد شده است، دستور sm-notify معمولاً رشته my_name ثبت‌شده در هنگام پایش آن سیستم دوردست را ارسال می‌کند. سرویس rpc.statd دوردست درخواست‌های ورودی SM_NOTIFY را با استفاده از این رشته، یا آدرس شبکه فراخواننده، با یک یا چند همتا در فهرست پایش خود مطابقت می‌دهد.

اگر rpc.statd همتایی را در فهرست پایش خود پیدا نکند که با درخواست ورودی SM_NOTIFY مطابقت داشته باشد، اعلان به مدیر قفل محلی ارسال نمی‌شود. علاوه بر این، هر همتا شماره وضعیت NSM مخصوص به خود را دارد؛ یک عدد صحیح ۳۲ بیتی که پس از هر راه‌اندازی مجدد توسط دستور sm-notify افزایش می‌یابد. سرویس rpc.statd از این شماره برای تمایز بین راه‌اندازی‌های مجدد واقعی و اعلان‌های تکراری استفاده می‌کند.

بخشی از بازیابی قفل NFS کشف مجدد همتایانی است که باید دوباره پایش شوند. دستور sm-notify فهرست پایش روی ذخیره‌ساز پایدار را پس از هر راه‌اندازی مجدد پاک می‌کند.

دستور sm-notify را به ترمینال کنترلی متصل و در پیش‌زمینه در حال اجرا نگه می‌دارد تا پیشرفت اعلان‌ها مستقیماً قابل پایش باشد.
اعلان‌ها را حتی اگر sm-notify از زمان آخرین راه‌اندازی مجدد سیستم اجرا شده باشد، ارسال می‌کند.
مدت زمان (به دقیقه) را برای ادامه تلاش مجدد ارسال اعلان‌ها به میزبان‌های بدون پاسخ مشخص می‌کند. اگر این گزینه مشخص نشود، sm-notify تلاش می‌کند اعلان‌ها را به مدت ۱۵ دقیقه ارسال کند. تعیین مقدار 0 باعث می‌شود که sm-notify تا زمانی که به صورت دستی خاتمه داده شود، به ارسال اعلان‌ها به همتایان بدون پاسخ ادامه دهد.
اگر ارسال با شکست مواجه شود، میزبان دوردست پاسخ ندهد، سرویس NSM سیستم دوردست ثبت نشده باشد، یا خطای DNS رخ دهد که مانع از ترجمه mon_name میزبان دوردست به یک آدرس شود، اعلان‌ها مجدداً تلاش می‌شوند.
میزبان‌ها تا زمانی که پاسخی معتبر دریافت نشود از فهرست اعلان حذف نمی‌شوند. با این حال، رویه SM_NOTIFY نتیجه‌ای بدون بازگشت (void) دارد. هیچ راهی برای sm-notify وجود ندارد که تشخیص دهد آیا میزبان دوردست فرستنده را شناخته و بازیابی قفل مناسب را آغاز کرده است یا خیر.
از به‌روزرسانی شماره وضعیت NSM سیستم محلی توسط sm-notify جلوگیری می‌کند.
شماره درگاه مبدایی را که sm-notify باید هنگام ارسال اعلان‌های راه‌اندازی مجدد استفاده کند، مشخص می‌کند. اگر این گزینه مشخص نشود، از یک درگاه موقت که به صورت تصادفی انتخاب شده استفاده می‌شود.
این گزینه می‌تواند برای عبور از فایروال میان کلاینت و سرور استفاده شود.
مسیر دایرکتوری والد را که اطلاعات وضعیت NSM در آن قرار دارد مشخص می‌کند. اگر این گزینه مشخص نشود، sm-notify به طور پیش‌فرض از /var/lib/nfs استفاده می‌کند.
پس از شروع، sm-notify تلاش می‌کند شناسه کاربری (UID) و شناسه گروهی (GID) موثر خود را برابر با مالک و گروه زیردایرکتوری sm از این دایرکتوری تنظیم کند. پس از تغییر شناسه‌های موثر، sm-notify تنها نیاز به دسترسی به فایل‌های موجود در sm و sm.bak درون مسیر دایرکتوری وضعیت دارد.
آدرس شبکه‌ای که باید اعلان‌های راه‌اندازی مجدد از آن ارسال شوند و آرگومان mon_name برای استفاده هنگام ارسال درخواست‌های SM_NOTIFY را مشخص می‌کند. اگر این گزینه مشخص نشود، sm-notify از یک آدرس وایلدکارت به عنوان آدرس اتصال ترابری استفاده می‌کند و از my_name ثبت‌شده در هنگام پایش سیستم دوردست به عنوان آرگومان mon_name هنگام ارسال درخواست‌های SM_NOTIFY استفاده می‌نماید.
قالب ipaddr می‌تواند به عنوان یک آدرس نمایشی IPv4 یا IPv6 بیان شود. اگر از قالب ipaddr استفاده شود، دستور sm-notify این آدرس را به یک نام میزبان تبدیل می‌کند تا به عنوان آرگومان mon_name هنگام ارسال درخواست‌های SM_NOTIFY استفاده شود.
این گزینه می‌تواند در پیکربندی‌های چند‌اتصالی که در آن‌ها سیستم دوردست نیاز به اعلان از یک آدرس شبکه مشخص دارد، مفید باشد.

بسیاری از گزینه‌هایی که می‌توان در خط فرمان تنظیم کرد، از طریق مقادیر تعیین‌شده در بخش [sm-notify] یا در یک مورد، بخش [statd] از فایل پیکربندی /etc/nfs.conf نیز قابل کنترل هستند.

مقادیر شناخته‌شده در بخش [sm-notify] شامل موارد زیر است: retry-time، outgoing-port و outgoing-addr. این مقادیر به ترتیب همان اثر گزینه‌های خط فرمان m، p و v را دارند.

یک مقدار اضافی شناخته‌شده در بخش [sm-notify] گزینه lift-grace است. به طور پیش‌فرض، اگر میزبانی برای اعلان وجود نداشته باشد، sm-notify دوره مهلت سرویس lockd را زودتر از موعد پایان می‌دهد. برخی از پیکربندی‌های دسترسی‌پذیری بالا (HA) به ازای هر آدرس IP شناور، یک نمونه از sm-notify را اجرا می‌کنند. در این پیکربندی‌ها، پایان دادن زودهنگام به دوره مهلت ممکن است مانع از بازیابی قفل‌ها توسط کلاینت‌ها شود. تنظیم lift-grace روی n از پایان زودهنگام دوره مهلت توسط sm-notify جلوگیری می‌کند. گزینه lift-grace هیچ گزینه خط فرمان معادلی ندارد.

مقدار شناخته‌شده در بخش [statd] گزینه state-directory-path است.

دستور sm-notify باید به عنوان ریشه (root) اجرا شود تا امتیازات لازم برای دسترسی به پایگاه‌داده اطلاعات وضعیت را به دست آورد. این دستور به محض راه‌اندازی، امتیازات ریشه را کنار می‌گذارد تا خطر حمله ارتقای امتیاز کاهش یابد.

در طول عملکرد عادی، شناسه کاربری موثری که انتخاب می‌کند، مالک دایرکتوری وضعیت است. این به آن اجازه می‌دهد پس از کنار گذاشتن امتیازات ریشه، همچنان به فایل‌های موجود در آن دایرکتوری دسترسی داشته باشد. برای کنترل اینکه rpc.statd کدام شناسه کاربری را انتخاب کند، کافی است از chown(1) برای تنظیم مالک دایرکتوری وضعیت استفاده کنید.

بازیابی قفل پس از راه‌اندازی مجدد برای حفظ یکپارچگی داده‌ها و جلوگیری از متوقف شدن غیرضروری برنامه‌ها حیاتی است.

برای کمک به rpc.statd در مطابقت دادن درخواست‌های SM_NOTIFY با درخواست‌های NLM، باید تعدادی از بهترین روش‌ها رعایت شوند، از جمله:

نام نود UTS سیستم‌های شما باید با نام‌های DNS که همتایان NFS برای تماس با آن‌ها استفاده می‌کنند مطابقت داشته باشد
نام نود UTS سیستم‌های شما باید همیشه نام‌های دامنه کاملاً واجد شرایط (FQDN) باشند
نگاشت رفت و برگشتی DNS برای نام‌های نود UTS باید سازگار باشد
نام میزبانی که کلاینت برای سوار کردن سرور استفاده می‌کند باید با mon_name سرور در درخواست‌های SM_NOTIFY ارسالی آن مطابقت داشته باشد

پیاده کردن یک فایل‌سیستم NFS لزوماً پایش متقابل کلاینت یا سرور NFS را متوقف نمی‌کند. هر دو ممکن است برای مدتی به پایش یکدیگر ادامه دهند تا در صورت بروز ترافیک بعدی NFS بین آن‌ها که منجر به سوار کردن‌های جدید و قفل‌گذاری مجدد فایل شود، آماده باشند.

در لینوکس، اگر ماژول هسته lockd در طول عملکرد عادی تخلیه شود، تمام همتایان دوردست NFS از پایش خارج می‌شوند. این اتفاق می‌تواند روی یک کلاینت NFS رخ دهد، به عنوان مثال اگر یک برنامه‌ی سوار کردن خودکار تمام نقاط اتصال NFS را به دلیل عدم فعالیت حذف کند.

فناوری TI-RPC پیش‌نیازی برای پشتیبانی از NFS روی IPv6 است. اگر پشتیبانی TI-RPC در دستور sm-notify تعبیه شده باشد، بر اساس آدرس شبکه بازگردانده‌شده توسط DNS برای هر همتای دوردست، ترابری مناسب IPv4 یا IPv6 را انتخاب می‌کند. این دستور باید کاملاً با سیستم‌های دوردستی که از TI-RPC یا IPv6 پشتیبانی نمی‌کنند سازگار باشد.

در حال حاضر، دستور sm-notify تنها از ارسال اعلان از طریق پروتکل‌های ترابری دیتاگرام پشتیبانی می‌کند.

/var/lib/nfs/sm
دایرکتوری حاوی فهرست پایش
/var/lib/nfs/sm.bak
دایرکتوری حاوی فهرست اعلان
/var/lib/nfs/state
شماره وضعیت NSM برای این میزبان
/proc/sys/fs/nfs/nsm_local_state
کپی هسته از شماره وضعیت NSM

rpc.statd(8), nfs(5), uname(2), hostname(7)

RFC 1094 - "NFS: Network File System Protocol Specification"
RFC 1813 - "NFS Version 3 Protocol Specification"
OpenGroup Protocols for Interworking: XNFS, Version 3W - Chapter 11

Olaf Kirch <okir@suse.de>
Chuck Lever <chuck.lever@oracle.com>

مه ۲۰۲۵ nfs-utils