مستند معماری و پیکربندی Storage سازمانی Plaivid

نکته

راهنمای سریع برای متخصصان: اگر فقط دستورات اجرایی را می‌خواهید، به انتهای مستند بخش Quick Reference (مرجع سریع) مراجعه کنید.

این مستند بر اساس استانداردهای Enterprise برای محیط مجازی‌ساز Plaivid و زیرساخت PVM تدوین شده است. هدف، آماده‌سازی و مدیریت فضای ذخیره‌سازی برای استفاده در محیط مجازی‌سازی، شامل ایجاد RAID، پیکربندی LVM و معرفی فضای ذخیره‌سازی به PVM است.

در معماری PVM، پس از ایجاد Volume Group (VG)، نیازی به ایجاد فایل‌سیستم‌هایی مانند ext4 و انجام عملیات Mount برای استفاده از آن به‌عنوان Storage وجود ندارد. در این معماری، Volume Group مستقیماً در بخش Storage Manager به‌عنوان Storage با نوع volume group به PVM معرفی می‌شود و مدیریت فضای ذخیره‌سازی توسط خود PVM انجام می‌گیرد.

در ادامه، دیسک‌های ماشین‌های مجازی روی این Storage به‌صورت Logical Volume (LV) ایجاد و مدیریت می‌شوند؛ به‌طوری‌که هر دیسک ماشین مجازی یک LV متناظر در Volume Group خواهد داشت.

در صورتی که فضای ذخیره‌سازی به File System نیاز داشته باشد، روش ایجاد و آماده‌سازی فایل‌سیستم ext4 نیز در این مستند ارائه شده است تا بتوان از فضای ذخیره‌سازی به‌صورت فایل‌سیستم معمولی استفاده کرد.

هشدار

نکته مهم: این راهنما برای استوریج‌هایی نوشته شده که از قبل RAID شده‌اند (چه سخت‌افزاری، چه نرم‌افزاری) اما هنوز در سطح سیستم‌عامل پارتیشن‌بندی، فرمت و مونت نشده‌اند. هدف، اتصال این فضاها به سرور به‌صورت استاندارد و امن برای ذخیره‌سازی داده‌های ماشین‌های مجازی Plaivid و همچنین Backup است.

چرا این مستند مهم است؟

قبل از هر چیز باید بفهمیم چرا نمی‌توانیم یک دیسک خام را مستقیماً به سرور بدهیم و از آن استفاده کنیم.

وقتی یک دیسک جدید (چه فیزیکی، چه RAID شده) به سرور متصل می‌شود، سیستم‌عامل فقط یک «قطعه سخت‌افزار» می‌بیند؛ چیزی شبیه یک انبار خالی و بدون در و پنجره. برای اینکه بتوانیم داخل این انبار چیزی ذخیره کنیم، به یک زنجیره از کارها نیاز داریم.

اطلاعات

تحلیل ساده مسأله:
تصور کن یک زمین خالی خریده‌ای (دیسک RAID شده خام). برای آماده‌سازی آن در محیط Plaivid / PVM باید:
۱. در صورت نیاز، ساختار اولیه دیسک را آماده کنی (پارتیشن‌بندی)
۲. فضای ذخیره‌سازی را به یک ساختار منعطف و قابل مدیریت تبدیل کنی (LVM)
۳. فضای ایجادشده را به‌صورت Volume Group (VG) مستقیماً به PVM معرفی کنی؛ در این حالت نیازی به ایجاد File System و Mount نیست.
۴. PVM دیسک‌های ماشین‌های مجازی را روی این Storage به‌صورت Logical Volume (LV) ایجاد و مدیریت می‌کند.
۵. اگر فضای ذخیره‌سازی به‌صورت فایل‌سیستم نیاز داشته باشد، می‌توان روی فضای موردنظر ext4 ایجاد کرده و آن را Mount کرد.

بدون هر یک از این مراحل، دیسک برای سیستم‌عامل و برای Plaivid غیرقابل استفاده است.

Mental Map: تصویر کلی معماری

قبل از ورود به جزئیات، باید نقشه ذهنی کامل داشته باشیم. این نقشه به شما می‌گوید در هر مرحله «کجای مسیر» هستید.

نکته کلیدی: هر لایه فقط با لایه بالا و پایین خودش صحبت می‌کند. اگر در یک لایه مشکلی پیش بیاید، لایه‌های بالاتر کار نمی‌کنند. این اصل، پایه اصلی عیب‌یابی است.

مفاهیم پایه

در این بخش هر مفهوم را با سه سطح توضیح می‌دهیم: ساده → مثال → فنی.

استوریج (Storage) چیست؟

یاداشت

به زبان ساده: استوریج یعنی «هر جایی که داده‌ها را نگه می‌داریم». مثل یک انبار برای فایل‌ها.

مثال ملموس: هارددیسک لپ‌تاپ شما، فلش USB، کارت حافظه دوربین، همه استوریج هستند. در سرور Enterprise، استوریج معمولاً چند دیسک ترکیب شده به‌عنوان یک واحد بزرگ‌تر و امن‌تر (RAID) است.

از دید فنی: در لینوکس هر دستگاه ذخیره‌سازی به‌صورت یک Block Device در مسیر /dev/ ظاهر می‌شود؛ مثلاً /dev/sda, /dev/sdb, /dev/nvme0n1.

RAID چیست و چرا مهم است؟

یاداشت

به زبان ساده: RAID یعنی «ترکیب چند دیسک برای اینکه سرعت بیشتر شود، یا اگر یک دیسک خراب شد، داده‌ها از بین نروند».

سطح RAID	نقش	افزونگی	کاربرد
RAID 0	فقط سرعت	ندارد	تست / محیط غیرحساس
RAID 1	آینه (Mirror)	دارد	OS Disk
RAID 5	Stripe + Parity	تحمل ۱ دیسک	استوریج عمومی
RAID 6	Stripe + Double Parity	تحمل ۲ دیسک	استوریج بزرگ
RAID 10	Mirror + Stripe	بالا	DataStore حساس / DB

از دید فنی: در سرورهای HPE، RAID توسط Smart Array Controller مدیریت می‌شود و ابزار مدیریت آن ssacli است. RAID در سطح سخت‌افزار انجام می‌شود و سیستم‌عامل فقط یک Logical Drive یکپارچه می‌بیند (مثل /dev/sdb).

هشدار

مهم: این مستند فرض می‌کند RAID از قبل ساخته شده. ما فقط RAID را بررسی می‌کنیم، نه اینکه بسازیم.

پارتیشن (Partition) چیست؟

یاداشت

به زبان ساده: پارتیشن یعنی «تقسیم یک دیسک بزرگ به چند بخش کوچک‌تر». مثل تقسیم یک آپارتمان بزرگ به چند اتاق.

مثال ملموس: یک دیسک 10TB را می‌توانیم به یک پارتیشن 10TB (تمام دیسک) یا چند پارتیشن 2TB + 3TB + 5TB تقسیم کنیم.

از دید فنی: دو نوع اصلی جدول پارتیشن وجود دارد:

• MBR (قدیمی): حداکثر 2TB، حداکثر ۴ پارتیشن Primary.
• GPT (مدرن): پشتیبانی از دیسک‌های بزرگ‌تر از 2TB، تا 128 پارتیشن، استاندارد Enterprise.

خطر

در محیط Enterprise همیشه GPT انتخاب می‌کنیم. چون دیسک‌های RAID تقریباً همیشه بزرگ‌تر از 2TB هستند.

LVM چیست و چرا حیاتی است؟

یاداشت

به زبان ساده: LVM یعنی یک لایه «انعطاف» بین دیسک و فایل‌سیستم. به کمک آن می‌توانید بدون از دست دادن داده، فضای ذخیره‌سازی را بزرگ‌تر یا کوچک‌تر کنید.

مثال ملموس: فرض کن یک اتاق داری که پُر شده. بدون LVM، مجبوری همه وسایل را جابجا کنی تا اتاق را بزرگ کنی. با LVM، فقط یک دیوار را جلو می‌بری و اتاق بزرگ‌تر می‌شود — بدون دست زدن به وسایل داخلش.

سه سطح LVM:

فایل‌سیستم (ext4) چیست؟

یاداشت

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

چرا ext4؟

• فایل‌سیستمی پایدار، بالغ و پرکاربرد در محیط‌های Linux و Enterprise است.
• از فایل‌ها و فضاهای ذخیره‌سازی بزرگ پشتیبانی می‌کند.
• دارای قابلیت Journaling است که با ثبت تغییرات فایل‌سیستم، احتمال بروز ناسازگاری و خرابی ساختار فایل‌سیستم را پس از خاموشی ناگهانی یا قطع برق کاهش می‌دهد.
• برای سناریوهایی مانند DataStore و BackupStore، در صورت نیاز به استفاده از فایل‌سیستم، گزینه‌ای مناسب و متداول محسوب می‌شود.

اطلاعات

نکته در معماری PVM: برای Storage مبتنی بر Volume Group در PVM، ایجاد ext4 و عملیات Mount الزامی نیست؛ VG مستقیماً توسط PVM به‌عنوان Storage مدیریت می‌شود. استفاده از ext4 زمانی مطرح است که فضای ذخیره‌سازی قرار باشد به‌صورت یک File System معمولی مورد استفاده قرار گیرد.

Mount چیست؟

یاداشت

به زبان ساده: Mount یعنی «وصل کردن یک فضای ذخیره‌سازی به یک پوشه در سیستم‌عامل». بعد از Mount، هر چیزی که در آن پوشه بنویسید، در واقع در آن دیسک ذخیره می‌شود.

مثال: اگر LV را روی /plaivid/datastore مونت کنیم، هر فایلی که Plaivid در این مسیر می‌سازد، در واقع روی دیسک RAID ذخیره می‌شود.

نکته حیاتی: Mount موقت با ریبوت از بین می‌رود. برای Mount دائمی باید در فایل /etc/fstab ثبت شود.

Checkpoint بخش مفاهیم

در این مرحله باید بتوانید توضیح دهید:

• تفاوت پارتیشن و LVM چیست؟
• چرا فقط پارتیشن‌بندی کافی نیست؟
• چرا Mount دائمی نیاز به fstab دارد؟

پیش‌نیازها (Before Action)

قبل از شروع، این موارد را چک کنید:

#	پیش‌نیاز	چرا مهم است؟
1	دسترسی root یا sudo	همه دستورات نیاز به مجوز بالا دارند
2	نصب ابزارها: parted, lvm2, e2fsprogs, ssacli	ابزارهای اصلی این مستند
3	تأیید RAID سالم	نصب روی RAID خراب = فاجعه
4	دیسک هدف خالی باشد	نبود داده مهم روی دیسک
5	Backup از fstab	جلوگیری از boot failure در صورت اشتباه

شناسایی دیسک‌ها و بررسی RAID

اصل مهم: قبل از هر کاری باید مطمئن باشیم که روی «دیسک درست» کار می‌کنیم.

نمایش تمام دیسک‌های متصل

lsblk
lsblk -f
fdisk -l

خروجی نمونه lsblk:

NAME     MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda        8:0    0   480G  0 disk
├─sda1     8:1    0     1G  0 part /boot
└─sda2     8:2    0   479G  0 part /
sdb        8:16   0    10T  0 disk   ← دیسک RAID خام و بدون پارتیشن

تفسیر خروجی:

• sda دیسک سیستم‌عامل است (پارتیشن دارد، Mount شده).
• sdb دیسک RAID شده هدف ماست: هیچ پارتیشنی ندارد، Mount نشده. این همان چیزی است که باید آماده کنیم.

خطر

هشدار حیاتی: قبل از هر عملیات، نام دیسک هدف را دقیقاً یادداشت کنید. اجرای دستور روی دیسک اشتباه = از دست رفتن کامل داده‌ها.

بررسی RAID با ssacli

هدف: مطمئن شویم که دیسک /dev/sdb واقعاً یک Logical Drive سالم RAID است.

# 1. لیست کنترلرها
ssacli controller all show status

# 2. نمایش Logical Driveها
ssacli controller slot=0 ld all show

# 3. جزئیات کامل
ssacli controller slot=0 ld all show detail

# 4. بررسی دیسک‌های فیزیکی
ssacli controller slot=0 pd all show status

خروجی نمونه:

Smart Array P408i-a in Slot 0
   Controller Status: OK
   Cache Status: OK
   Battery/Capacitor Status: OK

   Array A
     logicaldrive 1 (10.0 TB, RAID 5, OK) ← وضعیت آرایه سالم است

تفسیر: اگر همه وضعیت‌ها OK بود، RAID سالم است و می‌توانیم ادامه دهیم. اگر Failed, Rebuilding یا Degraded دیدید، متوقف شوید و ابتدا مشکل RAID را حل کنید.

وضعیت	معنی	اقدام
OK	سالم	ادامه بده
Rebuilding	در حال بازسازی	صبر کن تا تمام شود
Degraded	یک دیسک خراب، RAID هنوز کار می‌کند	تعویض دیسک
Failed	RAID خراب است	قبل از هر کار، بازیابی

Checkpoint شناسایی دیسک

• نام دقیق دیسک هدف را می‌دانید؟ (مثلاً /dev/sdb)
• تأیید کرده‌اید که RAID سالم است؟
• تأیید کرده‌اید که دیسک خالی است؟
  اگر پاسخ هر سه «بله» است، ادامه دهید.

پارتیشن‌بندی (دو روش)

در این بخش دو روش را بررسی می‌کنیم: parted و fdisk. فقط یکی از این دو را انتخاب کنید — هر دو نتیجه یکسانی دارند.

چرا دو روش؟

ابزار	مزایا	معایب	مناسب برای
parted	مدرن، Script-friendly، سریع	Syntax متفاوت با ابزارهای قدیمی	Automation، محیط Enterprise
fdisk	تعاملی، آشنا، پیش‌فرض همه توزیع‌ها	برای Script نیاز به مهارت بیشتر	افراد آشنا با ابزار سنتی

توصیه: در Plaivid، ما parted را ترجیح می‌دهیم چون در Automation عملکرد بهتری دارد. اما fdisk هم برای درک بهتر عالی است.

روش اول — پارتیشن‌بندی با parted

# 1. ساخت جدول پارتیشن GPT
parted /dev/sdb mklabel gpt

# 2. ساخت پارتیشن (100% کل دیسک)
parted /dev/sdb mkpart primary 0% 100%

# 3. فعال‌سازی فلگ LVM
parted /dev/sdb set 1 lvm on

# 4. تأیید ساختار
parted /dev/sdb print

توضیح دستورات:

• mklabel gpt : ساخت جدول پارتیشن از نوع GPT.
• mkpart primary 0% 100% : ساخت یک پارتیشن Primary که کل دیسک را می‌گیرد. استفاده از 0% و 100% باعث می‌شود پارتیشن align شده باشد (بهترین عملکرد).
• set 1 lvm on : فلگ LVM را روی پارتیشن ۱ فعال می‌کند تا LVM آن را تشخیص دهد.

روش دوم — پارتیشن‌بندی با fdisk

fdisk تعاملی است. دستور زیر را بزنید:

fdisk /dev/sdb

داخل محیط fdisk این حروف را به ترتیب وارد کنید:

• g : ساخت جدول پارتیشن GPT
• n : ساخت پارتیشن جدید
• 1 : شماره پارتیشن
• Enter : بخش شروع (پیش‌فرض)
• Enter : بخش پایان (تمام دیسک)
• t : تغییر نوع پارتیشن
• 31 : انتخاب کد Linux LVM در GPT
• p : نمایش برای تأیید
• w : ذخیره و خروج

یاداشت

در fdisk مدرن (util-linux)، شماره نوع Linux LVM در GPT برابر 31 است. اگر شماره را نمی‌دانید، در پرامپت t عبارت L را بزنید تا لیست کامل نمایش داده شود.

تأیید پارتیشن

lsblk /dev/sdb
partprobe /dev/sdb   # اطلاع‌رسانی به کرنل

خروجی نمونه:

NAME      MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
sdb         8:16   0   10T  0 disk
└─sdb1      8:17   0   10T  0 part  ← پارتیشن آماده برای LVM

Checkpoint پارتیشن‌بندی

پارتیشن /dev/sdb1 باید در خروجی lsblk دیده شود.

ساخت معماری LVM

سه مرحله دارد: PV → VG → LV. هر مرحله به مرحله قبل وابسته است.

ساخت Physical Volume (PV)

pvcreate /dev/sdb1
pvs                     # نمایش خلاصه
pvdisplay /dev/sdb1     # نمایش کامل

ساخت Volume Group (VG)

قرارداد نام‌گذاری: برای DataStore از vg_datastore و برای BackupStore از vg_backupstore استفاده می‌کنیم.

vgcreate vg_datastore /dev/sdb1
vgs
vgdisplay vg_datastore

بعد از ایجاد Volume Group (VG)، در سناریوی استفاده از Storage مبتنی بر LVM در PVM، ساختار اصلی Storage آماده است و می‌توان VG را مستقیماً در Storage Manager به‌عنوان Storage با نوع volume group معرفی کرد. بنابراین، برای آماده‌سازی Storage جهت استفاده در PVM، ادامه مراحل LVM مانند ایجاد LV به‌صورت دستی الزامی نیست؛ PVM دیسک‌های ماشین‌های مجازی را به‌صورت LV مدیریت می‌کند.

اگر هدف شما آشنایی بیشتر با ساختار LVM و مدیریت دستی Logical Volume (LV) است، یا فضای ذخیره‌سازی قرار است به‌صورت File System مورد استفاده قرار گیرد، می‌توانید بخش‌های بعدی مستند را مطالعه کنید.

در صورت نیاز به ساخت فایل سیستم

از این قسمت به بعد در صورتی که نیاز به ایجاد فایل سیستم دارید می‌توانید ادامه دهید.

ساخت Logical Volume (LV)

lvcreate -l 100%FREE -n lv_datastore vg_datastore
lvs
lvdisplay /dev/vg_datastore/lv_datastore

توضیح پارامترها:

• -l 100%FREE : تمام فضای آزاد VG را استفاده کن.
• -n lv_datastore : نام Logical Volume.
• خروجی نهایی مسیر: /dev/vg_datastore/lv_datastore

نکته

چرا 100%FREE؟ در محیط Plaivid معمولاً یک VG برای یک هدف مشخص (DataStore یا BackupStore) استفاده می‌شود، پس منطقی است تمام فضا در یک LV باشد. اگر می‌خواهید چند LV بسازید، از -L 500G استفاده کنید (مثلاً ۵۰۰ گیگابایت).

Checkpoint ساخت LVM

خروجی lvs باید LV شما را با اندازه صحیح نشان دهد.

فرمت با ext4

حالا LV آماده است، اما هنوز «قابل نوشتن» نیست چون فایل‌سیستم ندارد.

mkfs.ext4 -L datastore /dev/vg_datastore/lv_datastore

توضیح:

• -L datastore : یک Label به فایل‌سیستم می‌دهیم (مفید برای شناسایی).
• فرمت روی LVها سریع است (چند ثانیه تا چند دقیقه بسته به اندازه).

دریافت UUID (برای fstab):

blkid /dev/vg_datastore/lv_datastore

خروجی نمونه:

/dev/vg_datastore/lv_datastore: LABEL="datastore" UUID="a1b2c3d4-5678-90ab-cdef-1234567890ab" TYPE="ext4"

این UUID را کپی کنید — در بخش بعدی نیاز داریم.

اطلاعات

از دید فنی: UUID یک شناسه یکتای فایل‌سیستم است که هرگز عوض نمی‌شود. استفاده از UUID به‌جای /dev/sdX باعث می‌شود اگر ترتیب دیسک‌ها در سیستم عوض شود (مثلاً بعد از تعویض سخت‌افزار)، Mount هنوز درست کار کند.

Mount کردن (موقت و دائمی)

ساخت Mount Point

mkdir -p /plaivid/datastore

Mount موقت (تست)

mount /dev/vg_datastore/lv_datastore /plaivid/datastore
df -hT | grep datastore

اگر خط مربوطه با نوع ext4 و اندازه درست دیده شد، تست موفق بوده. برای برداشتن موقت:

umount /plaivid/datastore

Mount دائمی از طریق fstab

قبل از هر تغییر در fstab، حتماً بکاپ بگیرید.

cp /etc/fstab /etc/fstab.bak.$(date +%F)

افزودن ورودی به fstab:

فایل /etc/fstab را ویرایش کرده و خط زیر را به انتهای آن اضافه کنید:

/etc/fstab

UUID=a1b2c3d4-5678-90ab-cdef-1234567890ab  /plaivid/datastore  ext4  defaults,nofail  0  2

توضیح ستون‌ها:

ستون	مقدار	توضیح
۱ — Device	UUID=...	شناسه یکتای فایل‌سیستم
۲ — Mount Point	/plaivid/datastore	مسیر Mount
۳ — Type	ext4	نوع فایل‌سیستم
۴ — Options	defaults,nofail	گزینه‌های Mount
۵ — Dump	0	Backup توسط dump (غیرفعال)
۶ — fsck	2	ترتیب بررسی fsck هنگام boot

هشدار

چرا nofail؟ اگر روزی این دیسک در دسترس نبود، سیستم‌عامل هنوز boot شود (مانع boot loop می‌شود). برای DataStore و BackupStore بسیار مهم است.

تست fstab قبل از ریبوت (حیاتی):

findmnt --verify --verbose
mount -a
df -hT | grep datastore

خطر

هشدار حیاتی: اگر بدون تست، سرور را reboot کنید و ورودی fstab اشتباه باشد، سیستم ممکن است در حالت emergency mode بالا بیاید. همیشه با mount -a و findmnt --verify تست کنید.

تست نهایی

قبل از تحویل به Plaivid، این تست‌ها را انجام دهید:

# 1. بررسی فضای آزاد
df -hT /plaivid/datastore

# 2. تست نوشتن (100MB)
dd if=/dev/zero of=/plaivid/datastore/testfile bs=1M count=100

# 3. پاکسازی فایل تست
rm -f /plaivid/datastore/testfile

# 4. تست ریبوت (پیشنهادی)
reboot

# پس از بالا آمدن سرور:
df -hT | grep datastore

سناریوی BackupStore

تفاوت با DataStore: BackupStore محل نگهداری نسخه‌های پشتیبان است. مراحل دقیقاً مانند DataStore است، فقط با نام‌های متفاوت.

جدول نام‌گذاری استاندارد:

مورد	DataStore	BackupStore
VG Name	vg_datastore	vg_backupstore
LV Name	lv_datastore	lv_backupstore
Mount Point	/plaivid/datastore	/plaivid/backupstore
Label	datastore	backupstore
اولویت سرعت	بالا (VM Live)	متوسط
RAID پیشنهادی	RAID 10	RAID 5 یا 6

دستورات BackupStore به‌صورت خلاصه (فرض: دیسک /dev/sdc):

parted /dev/sdc mklabel gpt
parted /dev/sdc mkpart primary 0% 100%
parted /dev/sdc set 1 lvm on
pvcreate /dev/sdc1
vgcreate vg_backupstore /dev/sdc1
lvcreate -l 100%FREE -n lv_backupstore vg_backupstore
mkfs.ext4 -L backupstore /dev/vg_backupstore/lv_backupstore
mkdir -p /plaivid/backupstore
blkid /dev/vg_backupstore/lv_backupstore

# UUID را در /etc/fstab اضافه کنید، سپس:
mount -a
df -hT | grep backupstore

عیب‌یابی (Diagnostic Thinking)

اصل طلایی عیب‌یابی: از پایین به بالا حرکت کن. اگر مشکل در Mount است، ممکن است ریشه در LVM، پارتیشن یا حتی RAID باشد.

سناریوهای رایج

علامت (Symptom)	دلیل احتمالی	راه‌حل
دیسک در lsblk نیست	RAID خراب / Slot خالی	ssacli controller slot=0 pd all show
پارتیشن ایجاد نمی‌شود	جدول پارتیشن قدیمی	wipefs -a /dev/sdX سپس دوباره
pvcreate می‌گوید device busy	mapping قدیمی LVM	dmsetup remove_all سپس دوباره
بعد از reboot Mount نیست	خطا در fstab	journalctl -xe + findmnt --verify
Emergency mode بعد از reboot	fstab اشتباه	با mount -o remount,rw / وارد شوید و fstab را اصلاح کنید
mount می‌گوید "wrong fs type"	فایل‌سیستم خراب یا فرمت نشده	blkid را چک کنید، e2fsck بزنید

دستورات کلیدی عیب‌یابی

journalctl -xe                          # لاگ سیستم
dmesg | grep -i -E 'sd|error'           # لاگ کرنل
e2fsck -f /dev/vg_datastore/lv_datastore # بررسی فایل‌سیستم
vgchange -ay                            # فعال‌سازی VG
findmnt --verify --verbose              # تست fstab
ssacli controller slot=0 ld all show detail   # بررسی جزئیات RAID

Emergency Mode: چگونه fstab اشتباه را نجات دهیم؟

اگر سرور به دلیل خطای fstab وارد emergency mode شد، دستورات زیر را اجرا کنید:

# 1. ریمونت پارتیشن روت به‌صورت قابل نوشتن
mount -o remount,rw /

# 2. بازگردانی فایل بکاپ fstab
cp /etc/fstab.bak.YYYY-MM-DD /etc/fstab

# 3. ریبوت سیستم
systemctl reboot

بهترین شیوه‌ها (Best Practices)

• همیشه UUID، نه /dev/sdX: ترتیب دیسک‌ها ممکن است تغییر کند. UUID یکتا و پایدار است.
• استفاده از nofail در fstab: مانع boot failure در صورت دسترسی نداشتن به دیسک می‌شود.
• نام‌گذاری معنایی: vg_datastore بهتر از vg_data است. نام‌ها باید هدف را نشان دهند.
• Backup از fstab: قبل از هر تغییر: cp /etc/fstab /etc/fstab.bak.$(date +%F)
• تست قبل از reboot: همیشه mount -a و findmnt --verify قبل از reboot.
• مانیتورینگ RAID: بررسی هفتگی با ssacli ctrl all show status برای سنجش سلامت دیسک‌ها.

اشتباهات رایج

خطر

اشتباه: فرمت مستقیم دیسک بدون پارتیشن و LVM.
چرا اشتباه است: در آینده امکان گسترش (Extend) وجود ندارد. باید همه چیز را از نو ساخت.
روش درست: همیشه از زنجیره Partition → PV → VG → LV → FS استفاده کنید.

خطر

اشتباه: ورود /dev/sdb1 در fstab.
چرا اشتباه است: با تغییر ترتیب دیسک‌ها، Mount خراب می‌شود.
روش درست: از UUID استفاده کنید.

گسترش استوریج در آینده (Bonus)

یکی از بزرگ‌ترین مزیت‌های LVM: گسترش بدون Downtime. اگر روزی دیسک جدید اضافه شد، به‌راحتی به VG اضافه می‌شود.

# 1. آماده‌سازی دیسک جدید (مثلاً /dev/sdd)
parted -s /dev/sdd mklabel gpt
parted -s /dev/sdd mkpart primary 0% 100%
parted -s /dev/sdd set 1 lvm on
pvcreate /dev/sdd1

# 2. اضافه کردن به VG موجود
vgextend vg_datastore /dev/sdd1

# 3. گسترش LV تا کل فضای جدید
lvextend -l +100%FREE /dev/vg_datastore/lv_datastore

# 4. گسترش فایل‌سیستم (بدون unmount!)
resize2fs /dev/vg_datastore/lv_datastore

# 5. تأیید
df -hT /plaivid/datastore

نکته

جادوی LVM: این کل عملیات بدون قطع سرویس Plaivid انجام می‌شود. VMها همچنان در حال اجرا هستند و در پایان، فضای جدید در دسترس Plaivid قرار می‌گیرد.

سؤال‌های Teach-Back (سنجش درک)

اگر بتوانید به این سؤال‌ها پاسخ دهید، مفهوم را واقعاً یاد گرفته‌اید:

سنجش درک و تسلط

1. چرا در Enterprise همیشه از LVM استفاده می‌کنیم به‌جای پارتیشن ساده؟
2. اگر بعد از reboot سرور، Mount کار نکرد و دیسک هم در lsblk نبود، از کجا شروع می‌کنید؟
3. تفاوت PV، VG و LV را با یک مثال روزمره توضیح دهید.
4. چرا از UUID در fstab استفاده می‌کنیم و نه /dev/sdb1؟
5. اگر دیسک RAID در حالت Degraded باشد، آیا مجاز به پارتیشن‌بندی هستید؟ چرا؟
6. اگر بخواهید فضای DataStore را دو برابر کنید بدون خاموش کردن سرور، چه مراحلی طی می‌کنید؟
7. چرا در fstab گزینه nofail برای DataStore حیاتی است اما برای / نیست؟

سناریوی چالشی

سناریوی عملیاتی واقعی

سناریو:
یک همکار به شما می‌گوید:

«سرور Plaivid بعد از Reboot بالا نیامد و وارد Emergency Mode شد. برای Mount کردن یک دیسک، ورودی /dev/sdb1 را در /etc/fstab اضافه کرده بودم، چون UUID طولانی بود.»

سؤال:

• علت ریشه‌ای مشکل چیست؟
• چگونه سرور را نجات می‌دهید؟
• برای جلوگیری از تکرار این مشکل، چه توصیه‌ای می‌کنید؟

تحلیل پیکربندی:

استفاده از /dev/sdb1 در فایل /etc/fstab، بدون استفاده از UUID و گزینه nofail، می‌تواند باعث بروز دو مشکل جدی در فرآیند Boot شود:

1. وابستگی به نام‌گذاری دستگاه:
   ترتیب شناسایی دیسک‌ها ممکن است تغییر کند و در نتیجه مسیر /dev/sdb1 دیگر به دیسک موردنظر اشاره نکند یا اصلاً وجود نداشته باشد.

2. اختلال در Boot:
   در صورت در دسترس نبودن دیسک، systemd ممکن است Mount موردنظر را ناموفق تشخیص داده و سیستم را وارد Emergency Mode کند.

مسیر بازیابی:

در صورت وقوع این وضعیت، می‌توان از طریق Emergency Mode وارد سیستم شد، فایل‌سیستم Root را به‌صورت rw مجدداً Mount کرد، نسخه پشتیبان fstab را بازیابی نمود و سپس سیستم را Reboot کرد.

توصیه عملیاتی:

برای جلوگیری از وابستگی به نام دستگاه و کاهش ریسک اختلال در فرآیند Boot، استفاده از UUID برای شناسایی دیسک و گزینه nofail برای Mountهای غیرضروری توصیه می‌شود.

Quick Reference — مرجع سریع برای متخصصان

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

متغیرهای قابل تغییر

متغیر	مقدار پیش‌فرض	توضیح
<DISK>	/dev/sdb	دیسک RAID هدف
<VG>	vg_datastore	نام Volume Group
<LV>	lv_datastore	نام Logical Volume
<MOUNT>	/plaivid/datastore	مسیر Mount
<LABEL>	datastore	Label فایل‌سیستم

چک‌لیست اجرای کامل

# ── 0. Pre-flight ──────────────────────────────
ssacli controller slot=0 ld all show          # RAID health
lsblk                                          # confirm target disk
cp /etc/fstab /etc/fstab.bak.$(date +%F)      # backup fstab

# ── 1. Partition (GPT + LVM flag) ──────────────
parted -s /dev/sdb mklabel gpt
parted -s /dev/sdb mkpart primary 0% 100%
parted -s /dev/sdb set 1 lvm on
partprobe /dev/sdb

# ── 2. LVM stack ───────────────────────────────
pvcreate /dev/sdb1
vgcreate vg_datastore /dev/sdb1
lvcreate -l 100%FREE -n lv_datastore vg_datastore

# ── 3. Filesystem ──────────────────────────────
mkfs.ext4 -L datastore /dev/vg_datastore/lv_datastore

# ── 4. Mount point + fstab (UUID-based) ────────
mkdir -p /plaivid/datastore
UUID=$(blkid -s UUID -o value /dev/vg_datastore/lv_datastore)
echo "UUID=$UUID /plaivid/datastore ext4 defaults,nofail 0 2" >> /etc/fstab

# ── 5. Verify BEFORE reboot ────────────────────
findmnt --verify --verbose
mount -a
df -hT | grep datastore

چک‌لیست اعتبارسنجی سریع

پس از اجرا، این چهار مورد را تأیید کنید:

• خروجی lsblk پارتیشن sdb1 را نشان می‌دهد.
• خروجی vgs و lvs VG و LV را با اندازه صحیح نشان می‌دهند.
• خروجی df -hT مسیر Mount را با نوع ext4 و اندازه درست نمایش می‌دهد.
• خروجی findmnt --verify بدون خطا است.

خلاصه

• ساختار لایه‌ای استوریج: رعایت دقیق ترتیب زنجیره (RAID → Partition → LVM → FS → Mount) برای تضمین پایداری سیستم‌عامل و Plaivid الزامی است.
• تفاوت در معماری PVM: برای معرفی Storage به PVM، ساخت Volume Group (VG) کافیست و نیازی به فرمت ext4 یا Mount دست‌کم روی همان لایه نیست.
• امنیت در پیکربندی: همیشه در فایل /etc/fstab از UUID و عبارت nofail استفاده کنید و پیش از ریبوت با findmnt --verify و mount -a صحت آن را بپذیرید.
• انعطاف‌پذیری آنلاین: به لطف لایه LVM می‌توانید در آینده بدون قطعی سرویس (Downtime)، فضای ذخیره‌سازی ماشین‌های مجازی را گسترش دهید.