چرا Datastore در VMware ESXi ناگهان Read-Only می‌شود؟ 9 علت و روش رفع مشکل

یکی از مشکلاتی که ممکن است در یک محیط VMware بدون هشدار جدی ظاهر شود، Read-Only شدن Datastore در ESXi است. در این وضعیت معمولاً ماشین‌های مجازی همچنان قابل اجرا هستند و حتی ممکن است بتوانید فایل‌های موجود در Datastore را ببینید، اما ایجاد فایل جدید، تغییر فایل‌های VM، حذف فایل یا انجام بعضی عملیات مدیریتی با خطا مواجه می‌شود. همین موضوع باعث می‌شود بسیاری از مدیران شبکه در ابتدا تصور کنند مشکل از خود ESXi سرور HP یا تنظیمات دسترسی Datastore است، در حالی که ریشه مشکل در بسیاری از موارد در لایه Storage، مسیرهای ارتباطی یا حتی خرابی Metadata مربوط به VMFS قرار دارد.

نکته مهم این است که Read-Only شدن Datastore همیشه به معنی خراب شدن خود فایل‌سیستم نیست. گاهی ESXi در واکنش به یک خطای جدی در Storage یا ارتباط با LUN، برای جلوگیری از آسیب بیشتر، عملیات Write را متوقف می‌کند. بنابراین قبل از هر اقدامی مثل Reboot کردن Host، Unmount کردن Datastore یا اجرای ابزارهای تعمیر، باید مشخص شود مشکل دقیقاً از کدام لایه است.

۹ علت رایج Read-Only شدن Datastore در VMware ESXi و روش بررسی و رفع هرکدام

1. خرابی VMFS Metadata

یکی از جدی‌ترین دلایل Read-Only شدن Datastore، VMFS Corruption یا خرابی Metadata فایل‌سیستم است. VMFS برای مدیریت فایل‌ها، Blockها، Lockها و ساختار Datastore از Metadata استفاده می‌کند. اگر بخشی از این اطلاعات خراب شود، ESXi ممکن است نتواند عملیات Write را با اطمینان انجام دهد.

در چنین شرایطی ممکن است در vmkernel.log پیام‌هایی مانند موارد زیر مشاهده کنید:

VMFS volume ... has been detected corrupted

یا:

Volume ... might be damaged on the disk

Broadcom نیز خرابی Metadata مربوط به VMFS را یکی از دلایل اصلی inaccessible شدن Datastore معرفی کرده است.

روش بررسی

ابتدا Datastore و Device مربوط به آن را پیدا کنید:

esxcfg-scsidevs -m

سپس در صورت فراهم بودن شرایط، می‌توان Metadata را با ابزار VOMA بررسی کرد:

voma -m vmfs -f check -d /vmfs/devices/disks/naa.xxxxxxxxx:1

هشدار: اجرای عملیات Fix روی VMFS بدون داشتن Backup معتبر می‌تواند خطرناک باشد. VOMA برای همه انواع خرابی راه‌حل ندارد و در موارد شدید ممکن است نیاز به مهاجرت VMها یا بازیابی اطلاعات باشد.

2. مشکل در Storage Array یا Write-Protect شدن LUN

گاهی مشکل اصلاً از ESXi نیست. ممکن است Storage Array، LUN را در وضعیت Read-Only یا Write-Protected قرار داده باشد. این اتفاق می‌تواند به دلایلی مثل خطای Controller، وضعیت حفاظتی Storage، مشکلات RAID یا سیاست‌های خود Storage Array رخ دهد. در این حالت ESXi تلاش می‌کند Write انجام دهد اما Storage فرمان را قبول نمی‌کند. در vmkernel.log ممکن است خطاهایی مانند:

Read only

یا Sense Codeهای مربوط به Write Protection دیده شود. در ESXi 8، Broadcom نمونه‌ای از همین وضعیت را مستند کرده که در آن Storage Device از سمت Array به حالت Read-Only رفته و Write Commandها با خطای Data/Write Protection مواجه شده‌اند.

راهکار

در این شرایط تغییر تنظیمات ESXi معمولاً مشکل را حل نمی‌کند. باید وضعیت LUN، Controller، RAID و Storage Pool را در پنل Storage بررسی کنید. اگر Storage مربوط به HPE، Dell EMC، NetApp، Synology یا SAN دیگری است، وضعیت LUN را مستقیماً در همان Storage بررسی کنید.

3. قطع شدن مسیرهای Storage و ایجاد APD

یکی دیگر از علت‌های مهم، وضعیت All Paths Down یا APD است. فرض کنید ESXi از طریق Fibre Channel، iSCSI یا یک Storage Network به Datastore متصل است. اگر تمام مسیرهای ارتباطی با LUN از دست بروند، ESXi دیگر نمی‌تواند I/O را به Storage ارسال کند. این مشکل ممکن است به دلیل مواردی مثل:

• خرابی HBA
• قطع شدن کابل FC
• مشکل SFP
• خرابی Switch
• اختلال iSCSI Network
• Down شدن Storage Controller
• مشکل Multipathing
• تغییر اشتباه در SAN Fabric

ایجاد شود. APD در اصل به معنی از دست رفتن دسترسی به تمام Pathهاست و لزوماً به معنی خراب شدن Storage نیست. در بعضی شرایط پس از برگشت Connectivity، Datastore نیز دوباره قابل استفاده می‌شود. در لاگ‌ها می‌توانید به دنبال پیام‌هایی مانند:

Device has entered APD state

بگردید.

چه کاری انجام دهیم؟

اول وضعیت Pathها را بررسی کنید:

esxcli storage core path list

همچنین وضعیت Deviceها را بررسی کنید:

esxcli storage core device list

اگر تمام Pathها Dead یا Down هستند، قبل از هرگونه عملیات روی VMFS باید مشکل ارتباط Storage را برطرف کنید.

4. ایجاد PDL یا Permanent Device Loss

PDL یا Permanent Device Loss با APD متفاوت است. در APD، ESXi هنوز نمی‌داند Storage برای همیشه از دست رفته یا موقتاً ارتباط قطع شده است. اما در PDL، Storage یا SAN اعلام می‌کند که Device دیگر قابل دسترسی نیست. برای مثال ممکن است LUN حذف شده باشد، Mapping آن از Storage برداشته شده باشد یا Storage وضعیت Permanent Loss را اعلام کرده باشد.

در این وضعیت معمولاً Datastore به شکل Inaccessible دیده می‌شود و VMهای قرارگرفته روی آن نیز ممکن است Inaccessible یا Orphaned شوند.

بررسی

در vmkernel.log و vobd.log به دنبال پیام‌های PDL و Lost Communication باشید.

همچنین از مسیر:

vSphere Client → Host → Storage → Devices

وضعیت Device و Pathها را بررسی کنید.

اگر LUN عمداً حذف یا Unmap نشده، باید Mapping و وضعیت Storage را در سمت SAN بررسی کنید. در چنین شرایطی، ایجاد مجدد Datastore بدون بررسی وضعیت LUN می‌تواند باعث از بین رفتن اطلاعات شود.

5. خرابی دیسک یا RAID در Storage

گاهی ESXi فقط اولین جایی است که مشکل را نشان می‌دهد، اما علت واقعی در سطح سخت‌افزار Storage قرار دارد. مثلاً ممکن است یکی از دیسک‌های RAID خراب شده باشد، RAID در وضعیت Degraded قرار گرفته باشد یا Storage Controller با خطا مواجه شده باشد. در این حالت ممکن است Storage هنوز قابل دسترسی باشد، اما Write Performance به شدت افت کند یا برخی عملیات Write با خطا مواجه شوند.

بنابراین اگر Datastore ناگهان Read-Only شده، فقط به ESXi نگاه نکنید. وضعیت موارد زیر را نیز بررسی کنید:

• Disk Health
• RAID Status
• Storage Pool
• Controller Status
• Cache Status
• LUN Health
• Storage Events

اگر Storage در حال بازسازی RAID است، فشار شدید I/O روی آن می‌تواند شرایط را بدتر کند. بنابراین قبل از انجام عملیات سنگین مثل Clone، Storage Migration یا Backup، وضعیت Array را بررسی کنید.

6. قطع و وصل شدن مداوم iSCSI یا مشکل در Storage Network

در محیط‌هایی که Datastore روی iSCSI قرار دارد، شبکه نقش بسیار مهمی در پایداری Storage دارد. یک اشتباه رایج این است که iSCSI را مانند ترافیک معمولی شبکه در نظر بگیریم. Packet Loss، Flapping شدن Interface، MTU ناسازگار، VLAN اشتباه یا مشکل در Switch می‌تواند باعث قطع و وصل شدن Pathهای Storage شود.

موارد زیر را بررسی کنید:

esxcli network nic list

و برای بررسی مسیرهای Storage:

esxcli storage core path list

اگر از Jumbo Frame استفاده می‌کنید، MTU باید در تمام مسیر End-to-End یکسان باشد؛ یعنی از VMkernel Interface گرفته تا Switch و Storage. همچنین اگر چند مسیر iSCSI دارید، تنظیمات Multipathing و Port Binding را بررسی کنید.

7. مشکل در کابل، SFP، HBA یا Storage Switch

این مورد به‌خصوص در Datastoreهای Fibre Channel اهمیت زیادی دارد. گاهی یک SFP معیوب یا کابل فیبر مشکل‌دار باعث می‌شود یکی از مسیرهای Storage از دست برود. اگر Multipathing به درستی کار کند، شاید Datastore همچنان Online بماند؛ اما اگر مسیرهای باقی‌مانده نیز دچار مشکل شوند، وضعیت می‌تواند به APD یا PDL برسد.

در محیط‌های FC بهتر است موارد زیر بررسی شوند:

• وضعیت SFP
• Optical Power
• CRC Error
• Link Flap
• Port Error
• HBA Status
• FC Fabric
• WWPN/WWNN
• Zoning
• LUN Masking

اگر مشکل دقیقاً بعد از تعویض SFP، کابل یا تغییرات Switch شروع شده، احتمال ارتباط آن تغییر با Read-Only شدن Datastore بسیار بالاست.

8. اشتباه Storage Mapping یا دسترسی دادن LUN به یک سیستم دیگر

یکی از خطرناک‌ترین سناریوها زمانی رخ می‌دهد که LUN مربوط به VMFS به اشتباه در اختیار یک سیستم‌عامل دیگر قرار بگیرد. برای مثال اگر LUN حاوی VMFS به Windows یا Linux ارائه شود و سیستم‌عامل یا ابزار مدیریت دیسک روی آن عملیات Initialize، Partition یا Format انجام دهد، Metadata مربوط به VMFS ممکن است آسیب ببیند.

Broadcom صراحتاً سناریوی Overwrite شدن VMFS توسط یک سیستم‌عامل دیگر را مستند کرده است؛ در این حالت حتی Partition Table و Headerهای VMFS ممکن است تحت تأثیر قرار بگیرند.

بنابراین LUN مربوط به VMware را بدون دلیل و شناخت کامل به Host دیگری ارائه نکنید.

اگر اخیراً Storage Mapping تغییر کرده، این مورد را حتماً در اولویت بررسی قرار دهید.

9. مشکل Lock یا عملیات Storage در چند ESXi Host

در Datastoreهای Shared، چند ESXi Host می‌توانند هم‌زمان به یک VMFS دسترسی داشته باشند. VMFS برای جلوگیری از تداخل Write و مدیریت دسترسی‌ها از Locking Mechanism استفاده می‌کند. اگر Lockهای مربوط به VMFS دچار مشکل شوند یا Metadata مربوط به Distributed Lock آسیب ببیند، ممکن است Datastore یا VMها رفتار غیرعادی نشان دهند.

در بعضی موارد در لاگ‌ها پیام‌هایی مانند:

Corrupt lock detected

دیده می‌شود.

Broadcom نیز خرابی Distributed Lock یا DLX را در برخی موارد به عنوان عامل اصلی Corruption شدید VMFS معرفی کرده است. در چنین شرایطی، Reboot کردن تصادفی همه Hostها راهکار مناسبی نیست. ابتدا باید مشخص شود آیا واقعاً مشکل Lock، Metadata یا Storage Connectivity وجود دارد.

چطور بفهمیم مشکل واقعاً از Read-Only شدن VMFS است؟

قبل از اینکه سراغ تعمیر بروید، چند تست ساده انجام دهید. در vSphere Client بررسی کنید که Datastore چه وضعیتی دارد و آیا گزینه‌های مربوط به ایجاد یا تغییر فایل‌ها با خطا مواجه می‌شوند. سپس روی ESXi Host لاگ‌ها را بررسی کنید:

tail -f /var/log/vmkernel.log

برای پیدا کردن خطاهای مرتبط با VMFS می‌توانید از:

grep -i "vmfs" /var/log/vmkernel.log

استفاده کنید. برای Storage Path نیز:

esxcli storage core path list

را اجرا کنید. همچنین Device مربوط به Datastore را با:

esxcfg-scsidevs -m

مشخص کنید. این مرحله مهم است، چون بدون پیدا کردن naa.xxxxx مربوط به Datastore، بررسی‌های بعدی می‌توانند روی Device اشتباه انجام شوند.

آیا با Reboot کردن ESXi مشکل حل می‌شود؟

گاهی Reboot می‌تواند یک مشکل موقت در Management Agent یا بعضی وضعیت‌های I/O را برطرف کند، اما Read-Only شدن Datastore را نباید صرفاً با Reboot کردن درمان کرد. اگر علت اصلی APD، PDL، Write-Protect شدن LUN یا VMFS Corruption باشد، Reboot فقط ممکن است علامت مشکل را موقتاً تغییر دهد.

حتی در بعضی سناریوهای APD، Host ممکن است به وضعیت Not Responding برود و Recovery نیازمند بررسی Storage Connectivity و در برخی موارد Reboot Host باشد. بنابراین ترتیب منطقی این است:

Storage → Path → Device → VMFS → Logs → Repair

نه اینکه مستقیماً:

Reboot → امیدوار باشیم درست شود!

قبل از اجرای VOMA چه نکاتی را رعایت کنیم؟

VOMA ابزار مهمی برای بررسی Consistency مربوط به VMFS است، اما نباید بدون برنامه از آن استفاده کرد. قبل از بررسی یا تعمیر:

1. مطمئن شوید Backup معتبر از VMهای مهم دارید.
2. تا حد امکان VMها را به Datastore سالم منتقل کنید.
3. وضعیت Storage و Pathها را بررسی کنید.
4. Device صحیح Datastore را شناسایی کنید.
5. اگر لازم است VOMA اجرا شود، شرایط لازم برای Unmount کردن Datastore را فراهم کنید.
6. قبل از هر عملیات Fix، تأثیر آن روی اطلاعات را بررسی کنید.

Broadcom توصیه می‌کند Datastore هنگام اجرای VOMA روی VMFS از تمام ESXi Hostها Unmount شده باشد و قبل از اجرای دستورات، Backup مناسب وجود داشته باشد.

جمع‌بندی

Read-Only شدن Datastore در VMware ESXi یک خطای ساده و تک‌علتی نیست. ممکن است مشکل از خرابی VMFS Metadata باشد، یا Storage Array، LUN، RAID، کابل و SFP، HBA، iSCSI Network، Multipathing، APD، PDL یا حتی اشتباه در Storage Mapping. بهترین کار این است که قبل از هر اقدام مخرب، ابتدا مشخص کنید ESXi دقیقاً چه چیزی را گزارش می‌کند. بررسی vmkernel.log، وضعیت Device و Pathها و سپس بررسی سلامت Storage معمولاً مسیر عیب‌یابی را مشخص می‌کند.

اگر در لاگ‌ها عبارت‌هایی مانند Read only، APD، PDL، VMFS volume ... corrupted یا Corrupt lock detected مشاهده می‌کنید، آن پیام‌ها سرنخ بسیار مهمی برای پیدا کردن Root Cause هستند. در مواردی که VMFS واقعاً Corrupt شده، نباید با فرمت کردن Datastore یا ساخت مجدد آن عجله کرد؛ چون چنین اقدامی می‌تواند Recovery اطلاعات را بسیار دشوارتر کند. در یک محیط Production، اگر Datastore حاوی VMهای مهم است، اولویت همیشه باید حفظ اطلاعات و مشخص کردن علت اصلی مشکل باشد و بعد سراغ Repair بروید.