هدف این مقاله آموزش عمیق پروتکل‌ها نیست. مدیر باید بتواند پرسش درست را از تیم فنی و تأمین‌کننده بپرسد: بار کاری چگونه به داده دسترسی دارد، چه سطح کارایی و دسترس‌پذیری لازم است، رشد چگونه اتفاق می‌افتد و چه کنترل‌هایی برای حفاظت نیاز داریم. پاسخ این پرسش‌ها طراحی را هدایت می‌کند.
در این راهنما، موضوع از چند زاویه بررسی می‌شود: داستان سه درخواست متفاوت، File Storage برای کار با پوشه و اشتراک مناسب است، Block Storage به برنامه یک Volume می‌دهد. هدف این است که مخاطب پس از مطالعه، معیارهای تصمیم‌گیری و اقدام بعدی را روشن‌تر ببیند.
در این مقاله می‌خوانید
- داستان سه درخواست متفاوت
- File Storage برای کار با پوشه و اشتراک مناسب است
- Block Storage به برنامه یک Volume می‌دهد
- Object Storage داده و Metadata را در مقیاس نگه می‌دارد
داستان سه درخواست متفاوت
اسناد مشترک باید برای کاربران مانند پوشه و فایل دیده شوند. هر فرد مسیر را باز می‌کند، نام فایل را می‌بیند و بر اساس مجوز خود آن را ویرایش می‌کند. پایگاه داده با Volume و بلوک‌های خام کار می‌کند و خودش ساختار داده را مدیریت می‌کند. بکاپ حجم بزرگی از Objectها را با Metadata نگه می‌دارد و بیشتر به ظرفیت، دوام و سیاست نگهداری نیاز دارد.
اگر این تفاوت‌ها دیده نشوند، مقایسه پیشنهادها فقط به عدد ترابایت و قیمت تبدیل می‌شود. اما یک ترابایت ظرفیت با IOPS بالا و تأخیر کم، همان خدمت یک ترابایت آرشیو کم‌مصرف نیست. پیش از قیمت، نوع مصرف باید روشن شود.
File Storage برای کار با پوشه و اشتراک مناسب است
File Storage داده را در ساختار پوشه و فایل ارائه می‌کند. کاربران و برنامه‌ها می‌توانند با مسیرهای آشنا، نام‌گذاری و مجوزهای سطح فایل کار کنند. این مدل برای اسناد تیمی، Home Directory، محتوای مشترک و بسیاری از برنامه‌های سنتی طبیعی است.
مزیت اصلی آن تجربه ساده و مدیریت متمرکز دسترسی است. با این حال، تعداد بسیار زیاد فایل کوچک، قفل هم‌زمان، جست‌وجو و رشد Namespace می‌تواند بر عملکرد و عملیات اثر بگذارد. طراحی باید تعداد کاربران، الگوی خواندن و نوشتن، اندازه فایل‌ها و نیاز به Snapshot را در نظر بگیرد.
Block Storage به برنامه یک Volume می‌دهد
در Block Storage، سیستم‌عامل یا Hypervisor یک Volume می‌بیند و فایل‌سیستم یا پایگاه داده روی آن ساخته می‌شود. این مدل کنترل بیشتری بر نحوه نوشتن داده می‌دهد و برای پایگاه داده، ماشین مجازی و بارهای تراکنشی رایج است. کارایی با معیارهایی مانند IOPS، Throughput و Latency سنجیده می‌شود.
مدیریت Block معمولاً به تخصص بیشتری نیاز دارد. مالکیت Volume، Multipath، Snapshot، Replication و هماهنگی با فایل‌سیستم یا پایگاه داده باید روشن باشد. ارائه ظرفیت زیاد بدون مانیتورینگ الگوی I/O می‌تواند گلوگاه را پنهان کند یا منابع سریع را به بارهای کم‌ارزش اختصاص دهد.
Object Storage داده و Metadata را در مقیاس نگه می‌دارد
Object Storage داده را به‌صورت Object در یک فضای نام تخت یا Bucket ارائه می‌کند. هر Object شناسه و Metadata دارد و معمولاً از طریق API در دسترس است. این مدل برای داده‌های بدون ساختار، آرشیو، مخزن بکاپ، محتوای رسانه‌ای و مجموعه‌هایی با رشد زیاد مناسب است.
Object Storage لزوماً جایگزین مستقیم File Share یا Disk پایگاه داده نیست. برنامه باید روش دسترسی آن را پشتیبانی کند و انتظار Latency و رفتار به‌روزرسانی با سرویس هماهنگ باشد. مزایایی مانند مقیاس‌پذیری، Policy و امکان Immutability زمانی ارزش دارند که بار کاری با آن سازگار باشد.
نوع دسترسی اولین معیار انتخاب است
کاربر انسانی که فایل Word را از پوشه مشترک باز می‌کند، مسیر و قفل فایل می‌خواهد. پایگاه داده به نوشتن تصادفی بلوک‌ها و تأخیر پایدار نیاز دارد. سامانه بکاپ معمولاً Objectهای بزرگ را می‌نویسد و بر دوره نگهداری و بازیابی تکیه دارد. این سه الگو را نباید تنها با ظرفیت مقایسه کرد.
در کارگاه نیازسنجی، تیم باید مسیر کامل عملیات اصلی را توضیح دهد: چه کسی یا چه برنامه‌ای داده را می‌نویسد، اندازه درخواست چقدر است، چند عملیات هم‌زمان وجود دارد و چه زمانی خواندن رخ می‌دهد. نمونه‌برداری از بار واقعی از حدس دقیق‌تر است.
IOPS Throughput و Latency سه عدد جدا هستند
IOPS تعداد عملیات ورودی و خروجی در ثانیه را نشان می‌دهد. Throughput حجم داده جابه‌جا شده در زمان است و Latency مدت انتظار هر درخواست را بیان می‌کند. بار پایگاه داده با عملیات کوچک ممکن است IOPS و Latency را مهم بداند؛ انتقال فایل بزرگ بیشتر به Throughput وابسته است.
میانگین‌ها نیز همه واقعیت را نشان نمی‌دهند. یک سامانه ممکن است بیشتر روز آرام باشد و در پایان ماه جهش کند. طراحی باید اوج قابل انتظار، الگوی تصادفی یا ترتیبی، نسبت خواندن به نوشتن و حساسیت سرویس به افت عملکرد را ببیند. معیار پذیرش باید روی بار مشابه تولید آزمایش شود.
ظرفیت قابل استفاده با ظرفیت اسمی فرق دارد
عدد روی پیشنهاد ممکن است ظرفیت خام باشد. حفاظت RAID یا Erasure Coding، Replica، Snapshot، فضای رزرو، Metadata و سیاست Overprovisioning بر ظرفیت قابل استفاده اثر می‌گذارند. کاهش داده مانند Deduplication یا Compression نیز به نوع داده وابسته است و نباید با نسبت قطعی فرض شود.
برای مقایسه منصفانه، همه پیشنهادها باید ظرفیت قابل استفاده در سطح حفاظت یکسان را نشان دهند. رشد، حاشیه عملیاتی و دوره خرید نیز مشخص باشد. Storage نزدیک صد درصد ظرفیت معمولاً رفتار مناسبی ندارد و تیم برای عملیات نگهداری به فضای آزاد نیاز دارد.
Availability را در سطح سرویس تعریف کنیم
دو کنترلر یا چند دیسک لزوماً به معنای در دسترس‌بودن برنامه نیست. مسیر شبکه، HBA، Switch، فایل‌سیستم، Cluster و نحوه Failover هم بر نتیجه اثر دارند. هر بار کاری باید سطح تحمل خرابی و زمان بازگشت متناسب با ارزش خود داشته باشد.
برای اسناد اداری شاید توقف کوتاه قابل تحمل باشد، اما پایگاه داده تراکنشی به معماری قوی‌تر نیاز دارد. بکاپ نیز اگر برای مدت طولانی در دسترس نباشد، پنجره حفاظت از دست می‌رود. هزینه Availability باید به اثر کسب‌وکار وصل شود.
Snapshot بکاپ نیست
Snapshot برای بازگشت سریع از برخی تغییرها مفید است، اما معمولاً به همان سامانه یا دامنه مدیریتی وابسته است. خرابی گسترده، حذف عمدی یا آلودگی ممکن است Snapshot را نیز درگیر کند. سیاست حفاظت باید نسخه جدا، دوره نگهداری و آزمون بازیابی داشته باشد.
انتخاب Storage بر طراحی بکاپ اثر می‌گذارد. ابزار باید نوع منبع را پشتیبانی کند، Consistency موردنیاز برنامه را فراهم سازد و بازیابی در سطح فایل، Volume یا Object را ممکن کند. ظرفیت بکاپ و شبکه نیز با رشد منبع هماهنگ می‌شوند.
امنیت از مجوز تا رمزنگاری ادامه دارد
در File Storage مجوز پوشه و فایل، گروه‌های هویتی و ارث‌بری اهمیت دارند. در Block، کنترل دسترسی Host و جداسازی شبکه حیاتی است. در Object، Policy مربوط به Bucket، کلیدها، API و تنظیم عمومی یا خصوصی‌بودن باید دقیق باشد. یک تنظیم اشتباه می‌تواند دامنه داده بزرگی را آشکار کند.
رمزنگاری در انتقال و در حالت سکون، مدیریت کلید، ثبت دسترسی و جداسازی نقش مدیریتی بخش‌های مشترک‌اند. برای مخزن بکاپ، Immutability و جدایی هویت از محیط تولید اهمیت بیشتری پیدا می‌کند. کنترل باید با سناریوی تهدید طراحی شود.
رشد هر بار کاری شکل متفاوتی دارد
اسناد مشترک ممکن است آرام اما پیوسته رشد کنند. لاگ یا داده تصویری جهش‌های بزرگ دارد. پایگاه داده علاوه بر حجم، به افزایش تراکنش حساس است. بکاپ با تغییر نرخ داده، دوره نگهداری و تعداد نسخه‌ها رشد می‌کند. پیش‌بینی فقط با درصد عمومی، این تفاوت‌ها را پنهان می‌کند.
برای هر بار کاری محرک رشد ثبت می‌شود و سناریوی پایه، محتمل و اوج ساخته می‌شود. زمان سفارش، امکان توسعه بدون توقف و اندازه واحد افزایش ظرفیت نیز بررسی می‌گردد. معماری خوب سازمان را مجبور نمی‌کند برای یک رشد کوچک، جهش بزرگ سرمایه‌گذاری انجام دهد.
لایه‌بندی می‌تواند چند مدل را کنار هم قرار دهد
سازمان لازم نیست یک پاسخ برای همه داده‌ها انتخاب کند. اسناد فعال می‌توانند روی File Storage با کارایی مناسب باشند و نسخه‌های قدیمی به آرشیو Object منتقل شوند. پایگاه داده روی Block باقی بماند و بکاپ روی Object Storage دارای سیاست نگهداری قرار گیرد. این ترکیب باید از دید عملیات قابل مدیریت باشد.
تعداد زیاد سکوها نیز هزینه دارد. مانیتورینگ، مهارت، قرارداد و قطعه یدکی پیچیده می‌شوند. بنابراین هر لایه باید حجم و ارزش کافی برای توجیه خود داشته باشد. سادگی عملیاتی یک معیار واقعی در کنار قیمت و کارایی است.
سازگاری برنامه را پیش از خرید آزمایش کنیم
عبارت «S3 Compatible» یا پشتیبانی از یک پروتکل، تمام رفتار موردنیاز برنامه را تضمین نمی‌کند. نسخه API، روش احراز هویت، محدودیت اندازه Object، Consistency و ویژگی‌های Lifecycle باید بررسی شوند. برای File و Block نیز نسخه پروتکل، Multipath و Snapshot سازگار اهمیت دارند.
یک Proof of Concept کوچک باید عملیات اصلی و شرایط خطا را آزمایش کند. فقط سرعت نوشتن در حالت آرام کافی نیست. Failover، بازیابی Snapshot، قطع مسیر، پرشدن ظرفیت و بازگشت سرویس باید در معیار آزمون باشند.
هزینه کل را در دوره مشترک بسنجیم
قیمت اولیه شامل همه هزینه‌ها نیست. مجوز قابلیت‌ها، پشتیبانی، شبکه، Rack، برق، توسعه، نیروی عملیات و مهاجرت داده باید دیده شوند. در سرویس مصرفی نیز هزینه درخواست، خروج داده، ظرفیت رزرو و رشد مصرف اهمیت دارد.
مقایسه باید سطح حفاظت، کارایی و دوره یکسان داشته باشد. راهکار ارزان‌تر با RTO طولانی‌تر یا تیم نگهداری بزرگ‌تر همان خدمت را ارائه نمی‌کند. فرض‌ها باید کنار عدد نوشته شوند تا مدیر مالی بداند اختلاف قیمت از کجا می‌آید.
ماتریس تصمیم را از بار کاری بسازیم
برای هر بار کاری می‌توان نوع دسترسی، ظرفیت، رشد، IOPS، Throughput، Latency، Availability، RPO، RTO، امنیت و مهارت عملیاتی را ثبت کرد. سپس File، Block و Object بر اساس همین معیارها ارزیابی می‌شوند. نتیجه ممکن است برای چند بار کاری متفاوت باشد.
وزن معیارها را مالک سرویس و فناوری با هم تعیین می‌کنند. پایگاه داده تراکنشی Latency را سنگین‌تر می‌بیند، در حالی که آرشیو به هزینه نگهداری و قابلیت جست‌وجو اهمیت می‌دهد. امتیاز بدون شاهد آزمون یا مستند، دقت ظاهری ایجاد می‌کند.
مهاجرت داده بخشی از انتخاب است
حتی بهترین مقصد اگر انتقال آن خارج از پنجره مجاز باشد، راهکار قابل اجرا نیست. حجم، پهنای باند، زمان همگام‌سازی، سازگاری Metadata و امکان بازگشت باید پیش از خرید بررسی شوند. انتقال File با حفظ مجوزها با جابه‌جایی Object یا Volume یکسان نیست.
مهاجرت مرحله‌ای امکان اصلاح می‌دهد. یک مجموعه نماینده منتقل، کارکرد و بکاپ آن تأیید و سپس موج بعد آغاز می‌شود. مالک داده باید صحت و دسترسی را بپذیرد. خاموشی منبع قدیمی پس از دوره توافق‌شده انجام می‌شود تا دو نسخه دائمی شکل نگیرد.
نقش راگا در طراحی Storage
راگا می‌تواند Assessment را از Inventory بارهای کاری و اندازه‌گیری مصرف آغاز کند. سپس نیازهای File، Block و Object، حفاظت داده، شبکه و ظرفیت در یک معماری هماهنگ قرار می‌گیرند. خروجی باید نشان دهد هر داده چرا روی یک لایه قرار می‌گیرد و معیار پذیرش آن چیست.
ممکن است نتیجه استفاده بهتر از Storage موجود، افزودن Object Storage برای بکاپ و آرشیو، تفکیک بار پایگاه داده یا بازطراحی File Service باشد. تصمیم به نام فناوری محدود نمی‌شود؛ باید با بودجه، مهارت، رشد و تداوم سازمان سازگار باشد.
مانیتورینگ باید تجربه بار کاری را نشان دهد
داشبورد Storage اگر فقط سلامت دیسک و کنترلر را نمایش دهد، ممکن است افت تجربه برنامه را پنهان کند. Latency در سطح Host، Queue، مسیر شبکه و زمان پاسخ برنامه باید کنار هم دیده شوند. یک جزء می‌تواند سبز باشد اما زنجیره خدمت کند عمل کند.
خط مبنا در ساعات عادی و اوج ثبت می‌شود. هشدارها بر انحراف معنادار و ظرفیت رو به پایان تمرکز می‌کنند. اتصال رخدادها به تغییر اخیر، تیم را در یافتن علت کمک می‌کند. گزارش ماهانه نیز گلوگاه و اقدام ظرفیت را برای مدیریت خلاصه می‌سازد.
مناقصه باید بار کاری را توصیف کند
درخواست خریدی که فقط ظرفیت و چند نام قابلیت دارد، پیشنهادهای غیرقابل مقایسه تولید می‌کند. RFP بهتر است پروفایل بار، رشد، سطح حفاظت، Availability، Backup، امنیت، توسعه و معیار آزمون را بیان کند. تأمین‌کننده سپس معماری و فرض‌های خود را شفاف می‌سازد.
عددهای عملکرد باید شرایط آزمون داشته باشند. IOPS بدون اندازه Block، نسبت خواندن و نوشتن یا Latency معنای کامل ندارد. ظرفیت قابل استفاده نیز باید پس از حفاظت و فضای رزرو گزارش شود. این دقت از اختلاف پس از تحویل جلوگیری می‌کند.
محل و حاکمیت داده بر طراحی اثر دارند
برخی داده‌ها باید در محل یا دامنه مشخص باقی بمانند. این محدودیت می‌تواند استفاده از سرویس، Replication یا محل Backup را تغییر دهد. مالک داده و امنیت باید پیش از انتخاب معماری، مرز مجاز را تعیین کنند. اگر انتقال بیرونی ممنوع است، این شرط در سناریوی بازیابی نیز رعایت می‌شود.
تصمیم جلسه طراحی
سازمان تصمیم می‌گیرد سه درخواست را در یک خرید عمومی ادغام نکند. برای اسناد مشترک، الگوی فایل و مجوزها بررسی می‌شود. تیم پایگاه داده بار اوج و Latency را اندازه می‌گیرد. واحد بکاپ نیز دوره نگهداری، نرخ تغییر، Immutability و زمان بازیابی را مشخص می‌کند.
پس از این Assessment، گزینه‌ها با ظرفیت قابل استفاده و هزینه سه‌ساله مقایسه خواهند شد. پاسخ ممکن است یک سکوی یکپارچه یا ترکیبی از چند لایه باشد. معیار نهایی روشن است: هر داده باید در جایی قرار گیرد که سطح خدمت موردنیازش را با هزینه و ریسک قابل قبول تأمین کند.
چک‌لیست تصمیم‌گیری
- ظرفیت و کارایی به‌صورت جداگانه اندازه‌گیری شوند.
- نوع بار کاری و الگوی رشد داده مشخص باشد.
- دوره نگهداری و فضای رزرو در محاسبه بیایند.
- آزمون تحویل و بازیابی با داده نماینده انجام شود.
وضعیت Storage را با داده واقعی بررسی کنید
ظرفیت، کارایی، رشد، نگهداری و بازیابی Storage سازمان را پیش از توسعه یا خرید ارزیابی کنید.
سؤالات متداول
فضای آزاد برای ارزیابی Storage کافی است؟
خیر. تأخیر، IOPS، Throughput، نوع بار کاری، رشد و فضای رزرو نیز باید بررسی شوند.
ظرفیت آینده Storage چگونه محاسبه می‌شود؟
نرخ رشد، دوره نگهداری، کاهش داده، فضای رزرو و زمان تأمین باید در مدل ظرفیت لحاظ شوند.
تحویل Storage چگونه تأیید می‌شود؟
آزمون ظرفیت، کارایی، دسترس‌پذیری و بازیابی باید با معیار پذیرش از پیش توافق‌شده انجام شود.
منابع
[۱] Microsoft Learn — آشنایی با سرویس‌های ذخیره‌سازی و سناریوهای File و Block و Object مشاهده منبع
[۲] AWS — راهنمای انتخاب سرویس ذخیره‌سازی مشاهده منبع
مطالب مرتبط در سایت راگا
برای تکمیل این مسیر، خدمات تأمین تجهیزات IT راگا و مقاله «یک حساب مدیریتی برای همه سامانه‌ها دامنه آسیب را گسترش می‌دهد» را ببینید.