راه‌اندازی ZFS روی سرور اختصاصی: ساخت Pool، Snapshot و چرا به LVM و mdadm ترجیح داده می‌شود
اگر روی سرور اختصاصی با چند دیسک کار می‌کنید و مدیریت جداگانهٔ RAID با mdadm و volume با LVM برایتان دردسر شده، ZFS همهٔ این کار را در یک فایل‌سیستم انجام می‌دهد. در این مقاله نصب ZFS، ساخت pool با RAID-Z و گرفتن snapshot را قدم‌به‌قدم روی یک سرور اختصاصی لینوکس می‌بینیم و در آخر با جدول مقایسه می‌کنیم که چرا خیلی از ادمین‌ها دیگر سراغ LVM و mdadm نمی‌روند.
ZFS چیست و چه فرقی با فایل‌سیستم‌های معمولی دارد
ZFS هم فایل‌سیستم است و هم volume manager؛ یعنی کاری که در یک سرور معمولی بین mdadm (ساخت RAID از چند دیسک)، LVM (مدیریت volume) و ext4/XFS (فایل‌سیستم) تقسیم می‌شود، در ZFS یک لایه واحد انجام می‌دهد. این یکپارچگی چند فایده مستقیم دارد:
- هر بلوک داده با checksum ذخیره می‌شود، پس خرابی خاموش دیسک (bit rot) قبل از این‌که به backup سرایت کند شناسایی می‌شود.
- Snapshot و clone بر پایهٔ copy-on-write هستند، یعنی گرفتن یک snapshot چند ثانیه طول می‌کشد، نه چند ساعت.
- فشرده‌سازی (lz4/zstd) و دیدوپ روی خود فایل‌سیستم انجام می‌شود، بدون نیاز به ابزار جدا.
روی لینوکس، ZFS معمولا به شکل ماژول کرنل (OpenZFS) نصب می‌شود و روی توزیع‌هایی مثل Ubuntu Server و Debian پشتیبانی رسمی دارد.
قبل از نصب: چه چیزهایی روی سرور اختصاصی باید چک کنید
پیش از نصب، چند نکته را روی سرور اختصاصی بررسی کنید:
- کنترلر دیسک: اگر کارت RAID سخت‌افزاری (hardware RAID) روی سرور نصب است، آن را به حالت HBA یا JBOD بگذارید تا دیسک‌های خام مستقیم به ZFS داده شوند. ZFS خودش RAID را مدیریت می‌کند و دوباره‌کاری با RAID سخت‌افزاری باعث مشکلات شناسایی خرابی می‌شود.
- تعداد دیسک: برای RAID-Z1 حداقل سه دیسک، برای RAID-Z2 حداقل چهار دیسک لازم است (جدول بعدی را ببینید).
- رم: ZFS برای cache خودش (به‌نام ARC) از رم استفاده می‌کند. برای مصرف سبک چیزی در حد چند گیگابایت کافی است، اما برای load سنگین یا دیدوپ، رم بیشتر نتیجهٔ بهتری می‌دهد.
- ECC یا non-ECC: ZFS روی رم بدون ECC هم کار می‌کند، فقط در صورت خرابی رم همان مزیت checksum محدود می‌شود. اگر پلن سرور اختصاصی‌تان گزینهٔ ECC دارد، همان را انتخاب کنید.
نصب ZFS روی اوبونتو و دبیان
روی Ubuntu Server (از نسخه 20.04 به بعد ماژول در کرنل آمده):
apt update
apt install zfsutils-linux
روی Debian باید اول repository مربوط به contrib را فعال کنید:
apt install -y dpkg-dev linux-headers-$(uname -r) linux-image-amd64
apt install -y zfs-dkms zfsutils-linux
بعد از نصب، بررسی کنید ماژول لود شده:
zfs version
ساخت Pool با RAID-Z
Pool واحد اصلی ذخیره‌سازی در ZFS است؛ یک یا چند دیسک را به هم گروه می‌کند. فرض کنید چهار دیسک خام /dev/sdb تا /dev/sde روی سرور اختصاصی دارید:
zpool create tank raidz2 /dev/sdb /dev/sdc /dev/sdd /dev/sde
این دستور یک pool به نام tank با RAID-Z2 می‌سازد. برای مانیتور کردن سلامت pool:
zpool status tank
فرق سطح‌های RAID-Z در همین جا مشخص می‌شود:
| سطح | حداقل دیسک | تحمل خرابی هم‌زمان | مناسب برای |
|---|---|---|---|
| RAID-Z1 | ۳ | یک دیسک | دیسک‌های کوچک، بودجهٔ محدود |
| RAID-Z2 | ۴ | دو دیسک | اکثر سرورهای production |
| RAID-Z3 | ۵ | سه دیسک | آرشیو حساس، دیسک‌های ظرفیت بالا |
برای یک دیتاست داخل pool و فعال کردن فشرده‌سازی:
zfs create tank/data
zfs set compression=lz4 tank/data
zfs set atime=off tank/data
خاموش کردن atime یک کار کوچک و واقعی است که روی سرورهای با I/O زیاد سرعت را حس‌کردنی بالا می‌برد، چون هر خوانده‌شدن فایل دیگر باعث نوشتن متادیتا نمی‌شود.
گرفتن و بازگردانی Snapshot
Snapshot در ZFS یک کپی فقط‌خواندنی و لحظه‌ای از دیتاست است، بدون کپی واقعی داده (فقط بلوک‌های تغییریافته بعدا فضا می‌گیرند):
zfs snapshot tank/data@before-upgrade
لیست snapshotهای یک دیتاست:
zfs list -t snapshot tank/data
اگر بعد از یک آپدیت یا تغییر اشتباه نیاز به برگشت داشتید:
zfs rollback tank/data@before-upgrade
برای انتقال یا بکاپ‌گیری از یک snapshot به سرور دیگر (مثلا یک سرور اختصاصی دوم در لوکیشن دیگر):
zfs send tank/data@before-upgrade | ssh user@backup-server zfs receive backup-pool/data
این دستور فقط تفاوت بلوک‌ها را منتقل می‌کند، پس برای sync تدریجی بین دو سرور خیلی سریع‌تر از rsync روی حجم بالا عمل می‌کند.
چرا ZFS به LVM و mdadm ترجیح داده می‌شود
LVM و mdadm سال‌ها استاندارد مدیریت storage روی لینوکس بودند و هنوز هم جایی که فقط یک volume ساده لازم دارید کار می‌کنند. اما وقتی checksum، snapshot سریع یا resilver (بازسازی بعد از تعویض دیسک) مهم است، تفاوت‌ها خودشان را نشان می‌دهند:
| ویژگی | ZFS | LVM + mdadm |
|---|---|---|
| Checksum روی داده | دارد، هر بلوک | ندارد (فقط metadata در برخی حالت‌ها) |
| Snapshot | copy-on-write، چند ثانیه | معمولا کند، فضای جداگانه لازم دارد |
| فشرده‌سازی داخلی | دارد (lz4/zstd) | ندارد، باید جدا انجام شود |
| بازسازی بعد تعویض دیسک | فقط بلوک‌های استفاده‌شده | کل دیسک، حتی فضای خالی |
| اضافه کردن دیسک به RAID | محدودتر (باید vdev جدید اضافه کرد) | ساده‌تر با mdadm --grow |
| پیچیدگی مدیریت روزمره | یک ابزار (zfs/zpool) | دو ابزار جدا با تنظیمات مستقل |
نکتهٔ مهم همین ردیف آخر جدول است: resilver در mdadm کل دیسک را از اول تا آخر می‌خواند، حتی اگر فضای خالی باشد. ZFS فقط بلوک‌هایی که داده دارند را بازسازی می‌کند، پس روی دیسک‌های بزرگ با فضای خالی زیاد، زمان بازسازی به‌طور محسوس کوتاه‌تر است.
در عوض، گسترش یک RAID-Z با اضافه‌کردن یک دیسک تکی به همان راحتی mdadm نیست؛ معمولا باید یک vdev جدید به pool اضافه کنید. اگر برنامه‌تان این است که هر چند ماه یک دیسک تکی به سرور اضافه کنید، این محدودیت را از قبل در نظر بگیرید.
نگهداری: مصرف رم و scrub دوره‌ای
ARC (کش ZFS) به‌طور پیش‌فرض می‌تواند تا نیمی از رم سرور را بگیرد. برای محدود کردنش:
echo "options zfs zfs_arc_max=4294967296" >> /etc/modprobe.d/zfs.conf
عدد بالا معادل ۴ گیگابایت است؛ بسته به رم سرور اختصاصی‌تان تنظیم کنید و بعد از ری‌بوت اعمال می‌شود.
برای چک‌کردن سلامت داده‌ها به‌صورت دوره‌ای:
zpool scrub tank
zpool status tank
یک scrub ماهانه (با cron) معمولا کافی است تا خرابی خاموش دیسک قبل از این‌که مشکل واقعی بشود کشف شود.
انتخاب سرور اختصاصی مناسب برای ZFS
ZFS خودش به سخت‌افزار خاصی وابسته نیست؛ چیزی که بیشتر اهمیت دارد تعداد و نوع دیسک‌هاست. اگر دنبال سرور اختصاصی ارزان با یک یا دو دیسک هستید، RAID-Z1 یا حتی یک pool تک‌دیسکی (بدون redundancy، فقط برای checksum و snapshot) هم جایز است. برای کارهای production با نیاز به resilver سریع‌تر، RAID-Z2 روی سرور اختصاصی آلمان یا ایران گزینهٔ معقول‌تری است. سرور اختصاصی ترکیه و سرور اختصاصی اروپا هم برای کاربرانی که لتنسی نزدیک به اروپای شرقی یا خاورمیانه می‌خواهند مطرح می‌شوند؛ مشخصات و قیمت دقیق هر پلن را از صفحهٔ سرور اختصاصی آریانت ببینید چون بسته به لوکیشن فرق دارد.
اگر هنوز بین VPS و سرور اختصاصی مانده‌اید، این راهنما تفاوت‌ها را برای تصمیم‌گیری بهتر توضیح می‌دهد — نکتهٔ کوتاه همین‌جا: ZFS روی VPS هم قابل نصب است، اما چون معمولا به دیسک‌های مجازی اشتراکی دسترسی دارید نه دیسک خام، بخشی از مزیت resilver سریع و تشخیص خرابی فیزیکی را از دست می‌دهید.
نتیجه‌گیری
ZFS برای کسی که چند دیسک روی سرور اختصاصی دارد و checksum، snapshot سریع و فشرده‌سازی داخلی می‌خواهد، گزینهٔ راحت‌تری نسبت به ترکیب LVM و mdadm است؛ قیمتش کمی سخت‌تر بودن گسترش pool با یک دیسک تکی است. اگر سرور اختصاصی مناسب برای این سناریو لازم دارید، پلن‌های سرور اختصاصی آریانت در چند لوکیشن قابل بررسی است.
سؤالات متداول
آیا ZFS روی سرور با یک دیسک هم کار می‌کند؟ بله، pool را بدون RAID-Z می‌سازید. redundancy در سطح دیسک نخواهید داشت، اما checksum و snapshot همچنان فعال است.
گرفتن snapshot چقدر فضا اشغال می‌کند؟ در لحظهٔ گرفتن تقریبا هیچ فضایی اشغال نمی‌شود؛ فضا فقط برای بلوک‌هایی که بعدا در دیتاست اصلی تغییر می‌کنند مصرف می‌شود، چون snapshot نسخهٔ قدیمی آن بلوک را نگه می‌دارد.
آیا می‌شود از LVM روی ZFS هم استفاده کرد؟ معمولا لازم نیست؛ خود ZFS با دیتاست‌ها همان کار volume manager را انجام می‌دهد. مخلوط‌کردن دو لایه باعث پیچیده‌تر شدن troubleshooting می‌شود.
ARC چقدر رم مصرف می‌کند؟
به‌طور پیش‌فرض تا نیمی از رم سرور، اما با zfs_arc_max در /etc/modprobe.d/zfs.conf قابل محدود کردن است.
