اگر یک NAS دارید که چند هارد دیسک در محفظه‌های آن مشغول کار هستند و یک یا دو اسلات M.2 خالی در داخل بدنه آن باقی مانده است، احتمالاً تا امروز گمان می‌کردید این اسلات‌ها صرفاً تزئینی هستند یا نهایتاً برای کش (Cache) به کار می‌آیند. تجربه عملی روی یک دستگاه Synology DS1621xs+ نشان می‌دهد که انتخاب نوع استفاده از این اسلات‌ها می‌تواند تفاوت چشمگیری در کارایی واقعی سیستم ایجاد کند؛ تفاوتی که در برگه مشخصات فنی (Spec Sheet) هیچ دستگاهی نوشته نشده است.
کش فقط-خواندنی و کش خواندنی-نوشتنی؛ دو موجود کاملاً متفاوت
یک کش فقط-خواندنی (Read-Only Cache) بلوک‌هایی را که زیاد می‌خوانید روی SSD کپی می‌کند تا خواندن بعدی، هارد دیسک را دور بزند. مستندات رسمی کش SSD سینولوژی تصریح می‌کند که این نوع کش تنها ورودی/خروجی تصادفی (Random I/O) را شتاب می‌دهد و نه انتقال‌های متوالی حجیم مانند پخش ویدیو. همچنین تنها داده‌هایی را شتاب می‌دهد که دست‌کم یک بار پیش‌تر خوانده شده باشند؛ رویدادی که در محیط خانگی بسیار کم‌تر از تصور رخ می‌دهد.
در مقابل، کش خواندنی-نوشتنی (Read-Write Cache) نوشتن‌ها را نیز در خود جای می‌دهد، آن‌ها را به‌محض رسیدن به حافظه فلش تأیید می‌کند و بعداً به هارد دیسک‌ها منتقل می‌سازد. سود واقعی همین‌جاست، چون دیتابیس‌ها و کانتینرها به‌طور مداوم می‌نویسند و برای هر نوشتن منتظر می‌مانند. نکته مهم آن است که این نوع کش به دو SSD یکسان در آرایش آینه‌ای (Mirror) نیاز دارد؛ زیرا داده موجود در کش هنوز به هارد دیسک نرسیده و از دست رفتن یک کش نوشتنی بدون آینه می‌تواند همان داده را با خود ببرد.
آزمون عملی: نرخ برخورد ۶۴ درصدی که هیچ سود واقعی نداشت
در این آزمون، یک استخر ذخیره‌سازی (Storage Pool) مبتنی بر RAID 1 از دو هارد ۲۰ ترابایتی Seagate Exos روی DSM 7.4.1 استفاده شده است؛ به این ترتیب هر خواندن کوچک باید منتظر چرخش پلاترها بماند. آزمون‌ها سه بار تکرار شد: یک‌بار روی استخر هارد دیسک خام، یک‌بار با دو ماژول ۱۶ گیگابایتی Intel Optane M10 به‌عنوان کش فقط-خواندنی و یک‌بار با همان ماژول‌ها در نقش کش خواندنی-نوشتنی. گفتنی است Optane تأخیر بسیار کم‌تری از یک درایو NVMe معمولی دارد، بنابراین این اعداد را باید خوش‌بینانه‌ترین حالت ممکن در نظر گرفت.
- خواندن تصادفی 4K با صف ۳۲ (IOPS): فقط هارد دیسک ۸۲۲، کش فقط-خواندنی ۳٫۵۴۲ و کش خواندنی-نوشتنی ۴٫۲۵۰
- خواندن تصادفی 4K با صف ۱ (میانگین تأخیر، میلی‌ثانیه): فقط هارد دیسک ۵٫۹۷، کش فقط-خواندنی ۰٫۲۳ و کش خواندنی-نوشتنی ۰٫۱۸
- نوشتن تصادفی 4K با صف ۳۲ (IOPS): فقط هارد دیسک ۲۷٫۶۴۳، کش فقط-خواندنی ۳۳٫۹۱۸ و کش خواندنی-نوشتنی ۳۳٫۸۷۹
- راه‌اندازی سرد کانتینر Postgres (ثانیه): فقط هارد دیسک ۳۳٫۱، کش فقط-خواندنی ۳۵٫۱ و کش خواندنی-نوشتنی ۷٫۲
- آزمون pgbench با ۸ کلاینت (TPS): فقط هارد دیسک ۱۰۹، کش فقط-خواندنی ۱۱۰ و کش خواندنی-نوشتنی ۳۶۶
- استخراج سورس کرنل لینوکس با ۸۱٫۷۰۳ فایل (ثانیه): فقط هارد دیسک ۱۷٫۹، کش فقط-خواندنی ۱۹٫۰ و کش خواندنی-نوشتنی ۱۹٫۱
- پیمایش سرد پوشه‌های همان فایل‌ها (ثانیه): فقط هارد دیسک ۲٫۱، کش فقط-خواندنی ۵٫۲ و کش خواندنی-نوشتنی ۱٫۲
در این میان، عدد مربوط به نوشتن تصادفی روی هارد دیسک خام را نباید جدی گرفت؛ دو هارد دیسک در واقع نمی‌توانند ۲۷ هزار نوشتن تصادفی در ثانیه انجام دهند. علت آن است که فایل‌سیستم Btrfs از سازوکار کپی-در-هنگام-نوشتن (Copy-on-Write) استفاده می‌کند و نوشتن‌های پراکنده را به نوشتن‌های عمدتاً متوالی تبدیل می‌سازد؛ باقی آن نیز در حافظه رم بافر می‌شود. بنابراین این ردیف بیشتر یک ترفند فایل‌سیستمی است تا معیاری از توان واقعی درایوها.
کش فقط-خواندنی در آزمون‌های مصنوعی درخشان ظاهر می‌شود و تأخیر خواندن را از حدود ۶ میلی‌ثانیه به کم‌تر از یک‌چهارم میلی‌ثانیه می‌رساند؛ تا جایی که Storage Manager پس از آن نرخ برخورد (Hit Rate) ۶۴ درصدی گزارش می‌کند. اما تمام بارهای کاری واقعی یا یکسان اجرا شدند یا کندتر، چون راه‌اندازی کانتینر، دیتابیس و استخراج فایل عمدتاً شامل نوشتن و خواندن‌های بار اول است؛ چیزهایی که کش فقط-خواندنی هرگز آن‌ها را نمی‌بیند.
کش خواندنی-نوشتنی داستان دیگری است. راه‌اندازی سرد Postgres از ۳۳ ثانیه به ۷ ثانیه رسید و توان عبوری دیتابیس بیش از سه برابر شد؛ از ۱۰۹ به ۳۶۶ تراکنش در ثانیه. کارهای متوالی حجیم مانند استخراج سورس کرنل تغییری نکردند، اما هر کاری که منتظر نوشتن‌های کوچک بماند، به‌شدت سریع‌تر شد.
گزینه دیگر: اختصاص یک والیوم مستقل به اپلیکیشن‌ها
به‌جای استفاده از کش، می‌توان به درایو NVMe یک وظیفه مستقل داد: آن را به والیوم (Volume) اختصاصی خودش تبدیل کنید و Docker، دیسک ماشین‌های مجازی و دیتابیس‌ها را روی آن قرار دهید، در حالی که فایل‌های رسانه‌ای روی هارد دیسک‌ها باقی می‌مانند. در این روش، مزیت خودکار بودن کش را از دست می‌دهید، اما در عوض ریسک نوشتن معوق (Write-Back) نیز حذف می‌شود و از کار افتادن یک SSD، استخر اصلی شما را با خود نمی‌برد.
سینولوژی این مسیر را دشوار می‌کند. نسخه DSM 7.4.1 به‌راحتی کش را از ماژول‌های Optane ساخت و تنها آن‌ها را با رنگ نارنجی و پیام «این درایو برای استفاده به‌عنوان کش SSD پشتیبانی نمی‌شود» علامت‌گذاری کرد. اما استخرهای ذخیره‌سازی سخت‌گیرترند. دستگاه DS1621xs+ در زمان عرضه تنها اسلات‌های مخصوص کش را داشت و حدود DSM 7.2 بود که پشتیبانی از استخر ذخیره‌سازی M.2 به آن اضافه شد؛ آن هم فقط با SSDهای تأییدشده سینولوژی. همین دستگاه، Optane را با پیام «این درایو برای استخر ذخیره‌سازی M.2 آزمایش یا تأیید نشده است» قاطعانه رد کرد.
اسکریپت اجتماعی Synology_HDD_db با افزودن درایو شما به فهرست سازگاری DSM این محدودیت را دور می‌زند و روی نسخه ۷.۴.۱ پس از یک راه‌اندازی مجدد و چند دقیقه انتظار کار کرد. اما پس از آن، DSM پارتیشن‌های سیستمی و Swap خود را روی هر دو ماژول نصب کرد و حدود ۱۰ گیگابایت از هرکدام را خورد و در نهایت استخری ۳٫۲ گیگابایتی باقی گذاشت که برای نگه‌داشتن یک والیوم بسیار کوچک بود. با یک درایو ۱۶ گیگابایتی، راه همین‌جا به پایان می‌رسد و آزمون کامل والیوم نیازمند یک درایو ۱ ترابایتی خواهد بود.
سایر پلتفرم‌های NAS بسیار کم‌سخت‌گیرترند
- UGREEN: در جادوگر ذخیره‌سازی UGOS Pro به‌سادگی می‌توانید بین کش یا یک استخر SSD مستقل یکی را انتخاب کنید، بدون هیچ دروازه‌بانی سازگاری.
- QNAP: گزینه سومی به نام Qtier ارائه می‌دهد که داده‌ها را بر اساس میزان دسترسی میان لایه‌ها جابه‌جا می‌کند؛ بنابراین SSD به ظرفیت شما اضافه می‌شود، نه اینکه فقط جلوی آن بنشیند.
- TrueNAS: بیشترین گزینه‌ها و تیزترین لبه‌ها را دارد. L2ARC یک کش خواندنی است که هر زمان می‌توانید آن را حذف کنید، اما vdev ویژه، فراداده (Metadata) استخر شما را نگه می‌دارد و از دست دادن آن به معنای از دست رفتن کل استخر است.
- Unraid: عملاً فرض می‌کند شما این کار را انجام می‌دهید؛ پوشه appdata روی یک استخر سریع قرار می‌گیرد و سرویس Mover بقیه داده‌ها را به آرایه منتقل می‌کند.
پیش از خرید درایو، مطمئن شوید که دو عدد می‌خرید
اگر مسیر کش خواندنی-نوشتنی را انتخاب می‌کنید، بدون استثنا از دو درایو استفاده کنید. یک والیوم روی درایو تک، در صورت پشتیبان‌گیری روی استخر هارد دیسک قابل تحمل است، اما اسنپ‌شات‌های روی همان درایو هرگز جای پشتیبان را نمی‌گیرند. درایوهایی با حافظه DRAM و رتبه استقامت (Endurance) مناسب انتخاب کنید و مدل‌های ارزان QLC بدون DRAM را برای هر کاربری که نوشتن دارد، کنار بگذارید.
همچنین برای سرعت بیش از حد هزینه نکنید. اجرای دستور lspci از طریق SSH نشان می‌دهد هر اسلات M.2 در DS1621xs+ لینک اختصاصی PCIe 3.0 x4 دارد؛ موضوعی که سینولوژی منتشر نمی‌کند و بیشتر اسلات‌های دستگاه‌های NAS نیز نسل سوم هستند. یک درایو نسل پنجم روی چنین اسلاتی سریع‌تر کار نخواهد کرد، پس پول را به استقامت درایو اختصاص دهید.
جمع‌بندی
اگر یک درایو NVMe بلااستفاده در کشوی خود دارید، این اسلات یک ارتقای رایگان است؛ اما آنچه داخل آن می‌گذارید، از خود درایو مهم‌تر است. کش فقط-خواندنی اعداد بنچمارک چشمگیری و صفر سود واقعی به همراه داشت، در حالی که کش خواندنی-نوشتنی آینه‌ای توان عبوری دیتابیس را بیش از سه برابر کرد و زمان راه‌اندازی کانتینرها را نزدیک به ۸۰ درصد کاهش داد. گام بعدی، بررسی این پرسش است که آیا یک والیوم اختصاصی برای اپلیکیشن‌ها می‌تواند از این نتیجه نیز بهتر عمل کند یا نه.