رمزنگاری Native ZFS در Open-E JovianDSS Up33؛ مزایا و مقایسه با SED

رمزنگاری Native ZFS در Open-E JovianDSS Up33؛ مزایا و مقایسه با SED

تهیه شده توسط تیم فنی پردیسکو | تاریخ انتشار: ۲۷ مهر ۱۴۰۵

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

نسخه Open-E JovianDSS Up33 با معرفی قابلیت Native ZFS Encryption، امکان رمزنگاری داده‌ها را در سطح Dataset و Volume (zvol)، بدون اتکا به قابلیت رمزنگاری سخت‌افزاری Disk Controller، فراهم کرده است. این قابلیت در کنار رمزنگاری سخت‌افزاری SED، گزینه‌های بیشتری برای حفاظت از داده‌ها در اختیار سازمان‌ها قرار می‌دهد.

رمزنگاری Native ZFS در Open-E JovianDSS Up33؛ مزایا و مقایسه با SED

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

از SED تا Native ZFS Encryption؛ گسترش روش‌های رمزنگاری

پیش از انتشار Open-E JovianDSS Up33، رمزنگاری داده‌ها در این محصول عمدتاً به درایوهای خودرمزنگار (SED) متکی بود. پشتیبانی از این درایوها در نسخه Up29r2 برای Nodeهای مستقل و کلاسترهای Shared Storage به‌طور قابل‌توجهی گسترش یافت و در نسخه Up30 نیز به کلاسترهای Non-Shared Storage اضافه شد. این روش با انجام عملیات رمزنگاری در سخت‌افزار درایو، سربار پردازشی رمزنگاری را از CPU سرور برمی‌داشت.

سیر تکامل قابلیت‌های رمزنگاری
از گسترش پشتیبانی SED تا اضافه‌شدن رمزنگاری داخلی ZFS

Up29r2
Node مستقل و Shared Storage

Up30
کلاسترهای Non-Shared Storage

Up33
Native ZFS Encryption

بااین‌حال، مدیران زیرساخت باتجربه از محدودیت مهم این روش آگاه‌اند: درایوهای SED به Firmware مشخص و آزمایش‌شده نیاز دارند. در صورت خرابی Controller یا اختلال در عملکرد داخلی درایو، رفع مشکل تا حد زیادی به سازنده سخت‌افزار وابسته خواهد بود.

مزیت Native ZFS Encryption
Native ZFS Encryption این وابستگی را کاهش می‌دهد، زیرا رمزنگاری را در سطح فایل‌سیستم انجام می‌دهد و به استفاده از درایوهای SED متکی نیست.

مزایای Native ZFS Encryption در Open-E JovianDSS Up33

قابلیت Native ZFS Encryption در Open-E JovianDSS Up33 به‌صورت پیش‌فرض از الگوریتم رمزنگاری AES-256-GCM استفاده می‌کند. بااین‌حال، امکان انتخاب الگوریتم‌های دیگر نیز وجود دارد. اضافه‌شدن این قابلیت در نسخه جدید، علاوه بر افزایش انعطاف‌پذیری در طراحی معماری ذخیره‌سازی، مزایای دیگری نیز به همراه دارد:

۱. عملیات نگهداری بدون بارگذاری کلید رمزگشایی 

رمزنگاری داخلی ZFS با آگاهی از ساختار Metadata عمل می‌کند. این ویژگی امکان انجام عملیات مهم نگهداری مانند Scrub، Resilver و ایجاد Snapshot را حتی زمانی که Dataset یا Volume در حالت Unmounted قرار دارد و کلیدهای رمزگشایی بارگذاری نشده‌اند، فراهم می‌کند.
به این ترتیب، می‌توان یکپارچگی داده‌ها (Data Integrity) را بررسی و افزونگی داده‌ها (Redundancy) را حفظ کرد، بدون آنکه اطلاعات به‌صورت رمزگشایی‌شده (Plaintext) افشا شوند.

۲. حفظ Compression و بهره‌وری ذخیره‌سازی 

داده‌هایی که پیش‌تر رمزنگاری شده‌اند، معمولاً قابلیت فشرده‌سازی مؤثری ندارند. به همین دلیل، ترتیب اجرای Compression و Encryption در حفظ بهره‌وری ذخیره‌سازی اهمیت دارد.
در Open-E JovianDSS، عملیات Compression پیش از Encryption انجام می‌شود. این ترتیب باعث می‌شود در کنار رمزنگاری داده‌ها، همچنان بتوان از مزایای فشرده‌سازی با الگوریتم LZ4 یا سایر الگوریتم‌های موردنظر بهره‌مند شد و به کاهش هزینه کل مالکیت (TCO) کمک کرد.

۳. رمزنگاری بدون نیاز به درایوهای SED 

با استفاده از Native ZFS Encryption، دیگر نیازی به محدودکردن انتخاب سخت‌افزار به درایوهای SED موجود در فهرست سازگاری (Compatibility List) نیست.
این قابلیت امکان پیاده‌سازی رمزنگاری داخلی روی درایوهای استاندارد و پرسرعت NVMe یا SAS را فراهم می‌کند. در نتیجه، سازمان‌ها می‌توانند با انتخاب سخت‌افزارهای متناسب با نیاز خود، هزینه‌های زیرساخت را مدیریت کرده و ضمن کاهش وابستگی به تأمین‌کنندگان خاص (Vendor Lock-in)، به بهبود بازده سرمایه‌گذاری (ROI) کمک کنند.

Native ZFS Encryption یا SED؛ کدام روش برای سازمان مناسب‌تر است؟

انتخاب میان Native ZFS Encryption و SED به محدودیت‌های معماری، نیازهای عملکردی و بودجه سازمان بستگی دارد. مهم‌ترین تفاوت این دو روش در محل اجرای رمزنگاری، میزان استفاده از CPU، انتخاب سخت‌افزار و انعطاف‌پذیری عملیاتی است.

SED
Hardware Encryption

نحوه عملکرد
رمزنگاری در سطح Controller درایو، بدون تحمیل بار رمزنگاری به CPU سرور.
چه زمانی مناسب‌تر است؟
هنگامی که عملکرد خام اولویت دارد و بودجه سخت‌افزارهای تخصصی فراهم است.

Native ZFS
Software Encryption

نحوه عملکرد
رمزنگاری در سطح فایل‌سیستم، با استفاده از CPU و کنترل در سطح Dataset یا Volume.
چه زمانی مناسب‌تر است؟
هنگامی که انعطاف سخت‌افزاری و امکان استفاده از Nodeهای متداول اولویت دارد.

درایوهای SED عملیات رمزنگاری را در سطح Controller خود انجام می‌دهند و بار پردازشی رمزنگاری را به‌طور کامل از CPU سرور برمی‌دارند. این ویژگی به‌ویژه در سیستم‌هایی با پردازنده‌های ضعیف‌تر یا Workloadهایی با IOPS بسیار بالا که هر چرخه پردازشی اهمیت دارد، مزیت مهمی محسوب می‌شود.
در مقابل، Native ZFS Encryption در Open-E JovianDSS برای اجرای الگوریتم AES-256-GCM یا سایر الگوریتم‌های رمزنگاری از CPU سیستم استفاده می‌کند و به توان پردازشی کافی نیاز دارد. این روش امکان کنترل دقیق رمزنگاری در سطح Dataset یا Volume را فراهم می‌کند، اما در صورت کافی‌نبودن توان CPU، ممکن است بر توان عملیاتی سیستم (Throughput) تأثیر بگذارد.
در نهایت، اگر اولویت سازمان دستیابی به حداکثر عملکرد باشد و بودجه کافی برای استفاده از سخت‌افزارهای تخصصی با Firmware آزمایش‌شده وجود داشته باشد، SED همچنان گزینه‌ای مطمئن است.
در مقابل، اگر سازمان ترجیح دهد به‌جای پرداخت هزینه بالاتر برای درایوهای SED، روی Nodeهایی با سخت‌افزار متداول و توان پردازشی بیشتر سرمایه‌گذاری کند، Native ZFS Encryption انعطاف‌پذیری لازم برای رمزنگاری داده‌ها در سطح فایل‌سیستم را فراهم می‌کند.
جدول زیر مهم‌ترین تفاوت‌ها و ملاحظات انتخاب میان رمزنگاری سخت‌افزاری و رمزنگاری نرم‌افزارمحور را در محیط Open-E JovianDSS خلاصه می‌کند:

معیار مقایسه Self-Encrypting Drives (SED) Native ZFS Encryption
سربار پردازشی CPU رمزنگاری در خود درایو انجام می‌شود و بار پردازشی رمزنگاری به CPU سرور تحمیل نمی‌شود. از CPU سیستم استفاده می‌کند؛ پشتیبانی از AES-NI توصیه می‌شود.
انتخاب سخت‌افزار محدود به درایوهای موجود در Compatibility List و Firmwareهای مشخص. مستقل از سخت‌افزارهای اختصاصی رمزنگاری؛ قابل استفاده با درایوهای متداول.
لایه اجرای رمزنگاری در سطح کنترلر داخلی درایو و لایه سخت‌افزار. در سطح فایل‌سیستم و با آگاهی از Metadata.
ساختار هزینه‌ها معمولاً هزینه بیشتر به‌ازای هر دیسک؛ نیاز کمتر به توان پردازشی CPU. معمولاً هزینه کمتر برای دیسک‌ها؛ نیاز به توان پردازشی کافی در CPU.
انعطاف‌پذیری عملیاتی وابسته به قابلیت‌های سخت‌افزار و سازوکار مدیریت کلید و بازکردن قفل درایو. امکان اجرای عملیات Scrub ،Resilver و Snapshot بدون بارگذاری کلید رمزگشایی (No-Key Operations).

جمع‌بندی؛ انتخاب روش رمزنگاری متناسب با نیاز سازمان

Native ZFS Encryption در Open-E JovianDSS Up33، گزینه جدیدی برای حفاظت از داده‌های حساس در اختیار سازمان‌ها قرار می‌دهد. این قابلیت با کاهش وابستگی به درایوهای SED، امکان انتخاب سخت‌افزارهای متنوع‌تر را فراهم می‌کند و انعطاف‌پذیری بیشتری برای Off-Site Replication و حفاظت از داده‌ها در Cold Storage ارائه می‌دهد.
بااین‌حال، انتخاب میان Native ZFS Encryption و SED باید بر اساس نیازهای امنیتی، توان پردازشی، بودجه و معماری زیرساخت انجام شود. هر دو روش می‌توانند در شرایط مناسب، بخشی از راهبرد حفاظت از داده‌های سازمان باشند.

پیشنهاد مطالعه:

برای آشنایی با سایر قابلیت‌ها و تغییرات این نسخه، مقاله «معرفی Open-E JovianDSS Up33؛ رمزنگاری Native ZFS و سایر قابلیت‌های جدید» را مطالعه کنید.

امتیاز دهید
پیمایش به بالا