ذخیره‌سازی بلوکی یک حجم ارائه می‌دهد، ذخیره‌سازی فایلی یک رابط سیستم فایل ارائه می‌دهد و ذخیره‌سازی شیء اشیائی را ارائه می‌دهد که از طریق یک API آدرس‌دهی می‌شوند. رابطی را انتخاب کنید که نرم‌افزار شما انتظار دارد، سپس سازگاری، دسترسی، عملکرد و بازیابی را مقایسه کنید. هیچ‌یک از این برچسب‌ها به‌تنهایی یک پشتیبان یا وعده ظرفیت نامحدود را اثبات نمی‌کند.
با رابط برنامه شروع کنید
پیش از مقایسه ترابایت‌ها، مشخص کنید برنامه چگونه داده را می‌خواند و تغییر می‌دهد. آیا انتظار یک حجم محلی mountشده، یک مسیر اشتراکی با مجوزهای فایل یا یک API را دارد که یک شیء را با کلید بازیابی می‌کند؟ این رابط‌ها متفاوت هستند. محصولی با ظرفیت فراوان می‌تواند همچنان به تغییرات قابل توجه برنامه نیاز داشته باشد اگر مدل دسترسی نادرستی ارائه دهد.
عملیات مشخصی را بنویسید: افزودن به یک فایل، به‌روزرسانی بخشی از یک پایگاه داده، فهرست کردن یک پوشه، ارائه یک تصویر بزرگ یا اجازه دادن به چند ماشین برای ویرایش همان سند. انتخاب ذخیره‌سازی باید آگاهانه از این عملیات پشتیبانی کند. ابزارهای کلاینت راحت را به‌عنوان سازگاری‌هایی برای بررسی در نظر بگیرید، نه اینکه فرض کنید همه بک‌اندها را قابل تعویض می‌کنند.
مسئولیت‌های ذخیره‌سازی بلوکی را درک کنید
ذخیره‌سازی بلوکی یک رابط شبیه حجم ارائه می‌دهد که یک سیستم می‌تواند روی آن یک سیستم فایل یا چیدمان داده دیگری بسازد. سیستم‌عامل و برنامه معمولاً معنای داده نوشته‌شده در آن بلوک‌ها را مدیریت می‌کنند. این یک پایه رایج برای دیسک‌های سیستم و برنامه‌هایی است که انتظار یک حجم mountشده را دارند، اما قواعد دقیق اتصال و اشتراک‌گذاری آن به پیاده‌سازی بستگی دارد.
پیش از استفاده از حجم، پارتیشن‌بندی، قالب‌بندی، ظرفیت سیستم فایل و بازیابی را برنامه‌ریزی کنید. یک تخصیص بلوکی به‌طور خودکار یک پشتیبان سازگار با پایگاه داده ایجاد نمی‌کند یا به‌طور ایمن اجازه نمی‌دهد چند ماشین نامرتبط همزمان بنویسند. مدل اتصال محصول و هر هماهنگی نرم‌افزاری موردنیاز آن را تأیید کنید. الگوی دسترسی درست به‌اندازه عدد ظرفیت مهم است.
معناشناسی ذخیره‌سازی فایلی را درک کنید
ذخیره‌سازی فایل به برنامه‌ها از طریق یک واسط سیستم فایل، نام و مسیر می‌دهد. یک سرویس اشتراکی ممکن است پروتکلی مانند NFS را با مجوزها، قفل‌گذاری و رفتار سازگاری وابسته به پیاده‌سازی ارائه کند. Amazon EFS یک نمونه مستند از سرویس مبتنی بر NFS است؛ قابلیت‌های آن EFS را توصیف می‌کند، نه هر سیستم فایل اشتراکی یا یک گزینه ذخیره‌سازی SwissOctet را.
برای یک فضای کاری تیمی بپرسید هویت‌ها چگونه به مجوزها نگاشت می‌شوند و وقتی دو کلاینت یک فایل را به‌روزرسانی می‌کنند چه اتفاقی می‌افتد. برای یک برنامه، عملیات‌هایی را که به آن‌ها وابسته است بررسی کنید، نه اینکه فقط فهرست یک پوشه را آزمایش کنید. دسترسی‌پذیری شبکه و پیکربندی کلاینت بخشی از طراحی سیستم‌عامل هستند زمانی که فایل‌ها از راه دور دسترسی می‌یابند.
ذخیره‌سازی شیء را به‌عنوان یک API درک کنید
ذخیره‌سازی شیء به محتوای ذخیره‌شده از طریق کلیدها و فراداده‌های مرتبط آدرس‌دهی می‌کند. Amazon S3 این مدل را با سبدها، کلیدهای شیء و شناسه‌های نسخه مستند می‌کند. یک واسط شیء برای نرم‌افزاری مناسب است که برای بارگذاری و بازیابی محتوا از طریق آن API طراحی شده است. این انتزاعی متفاوت از دیسکی است که سیستم‌عامل آن را سوار می‌کند یا پوشه‌ای اشتراکی با عملیات معمول فایل.
فرض نکنید که یک مرورگر شبیه پوشه، معناشناسی سیستم فایل را ایجاد می‌کند. پیشوندها می‌توانند به سازمان‌دهی نام‌ها کمک کنند در حالی که API هنوز کنترل می‌کند اشیاء چگونه ایجاد و تغییر می‌کنند. رفتار سازگاری، نسخه‌بندی و کنترل دسترسی سرویس انتخاب‌شده را بررسی کنید. این جزئیات تعیین می‌کنند که آیا یک گردش کار بارگذاری، فهرست رسانه یا مخزن برون‌ریزی می‌تواند از این واسط به‌صورت ایمن و کارآمد استفاده کند.
یک پروژه عملی را به رابط‌ها نگاشت کنید
یک برنامه نمونه با پایگاه داده رابطهای، تصاویر بارگذاری‌شده توسط کاربر و پوشه‌ای اشتراکی میان کارگران دسته‌ای را در نظر بگیرید. پایگاه داده ممکن است به یک حجم مناسب نیاز داشته باشد، تصاویر ممکن است با طراحی برنامه شیءآگاه سازگار باشند و کارگران ممکن است به یک سیستم فایل اشتراکی نیاز داشته باشند. ترکیب واسط‌ها می‌تواند منطقی باشد زمانی که هرکدام نقش روشنی ایفا کنند، نه اینکه هر مجموعه داده را به زور در یک محصول ذخیره‌سازی جای دهیم.
جدول زیر نقطه شروعی برای پرسش‌هاست، نه توصیه محصول یا ادعایی درباره سرویس‌های شیء SwissOctet که اکنون موجودند. فهرست، منابع ذخیره‌سازی را برای پیکربندی‌های واقعی خود فهرست می‌کند. اگر می‌خواهید خودتان یک سرویس فایل یا شیء ارائه دهید، نرم‌افزار، نیازهای منابع و کار مدیریتی لازم برای ساخت آن را بررسی کنید.
| نیاز برنامه | واسطی که باید ارزیابی شود | پرسش پیش از استقرار |
|---|---|---|
| سیستم سوارشده یا حجم پایگاه داده | بلوک | آیا برنامه از حجم و روش بازیابی پشتیبانی می‌کند؟ |
| مسیرهای اشتراکی میان کلاینت‌ها | فایل | آیا مجوزها، قفل‌گذاری و سازگاری مناسب هستند؟ |
| بارگذاری‌های رسانه مبتنی بر API | شیء | آیا برنامه از API و قواعد دسترسی پشتیبانی می‌کند؟ |
| مخزن پشتیبان‌گیری مستقل | هر هدف پشتیبانی‌شده | آیا ابزار بازیابی این قالب را بررسی و بازیابی می‌کند؟ |
عملکرد را بدون مخلوط کردن معیارها مقایسه کنید
ظرفیت، تأخیر عملیات و انتقال پایدار ویژگی‌های متفاوتی هستند. یک بار کاری که اشیاء رسانه‌ای بزرگ را می‌خواند با یکی که فایل‌های کوچک یا صفحات پایگاه داده زیادی را به‌روزرسانی می‌کند متفاوت است. یک آزمون نماینده با اندازه داده و همزمانی واقع‌گرایانه بسازید. پردازش کلاینت و انتقال شبکه را در جایی که به آن تعلق دارند بگنجانید، نه اینکه کل نتیجه را به بک‌اند ذخیره‌سازی نسبت دهید.
همچنین بررسی کنید سیستم نزدیک محدودیت‌های عملی خود چگونه رفتار می‌کند. رشد فایل‌ها، عملیات فهرست شیء، فعالیت فراداده و کلاینت‌های همزمان می‌توانند تصویر منابع را تغییر دهند. دوره‌های عادی و پرترافیک را اندازه بگیرید، برای نگهداری ظرفیت باقی بگذارید و پیش از پر شدن محیط هشدارها را تعریف کنید. برچسبی مانند NVMe یک فناوری ذخیره‌سازی را مشخص می‌کند، نه هر نتیجه‌ای برای برنامه.
امنیت و بازیابی را در هر رابط حفظ کنید
از یک مدل دسترسی مناسب برای هر مجموعه داده استفاده کنید. اعتبارنامه‌های مدیریتی را از دسترسی برنامه جدا نگه دارید و هر کلید لازم برای رمزگشایی داده‌های نگهداری‌شده را محافظت کنید. قرار گرفتن در معرض عمومی را صریحاً بررسی کنید: یک اشتراک فایل یا مجموعه شیء که به‌طور خصوصی در نظر گرفته شده نباید صرفاً به این دلیل که برنامه‌اش با پیش‌فرض‌های راحت مستقر شده، قابل دسترسی شود.
در نهایت، بازیابی‌ای برنامه‌ریزی کنید که همه مخازن مرتبط را پوشش دهد. نقطه بازیابی پایگاه داده و فایل‌های بارگذاری‌شده‌ای که به آن‌ها ارجاع می‌دهد باید با هم کار کنند. مالکیت، قالب پشتیبان‌گیری و ترتیب بازیابی را مستند کنید. هنگام مقایسه SwissOctet Vault یا ذخیره‌سازی سرور، تخصیص و گزینه‌های دقیق را بخوانید؛ از یک برچسب گسترده ذخیره‌سازی، یک API شیء مدیریت‌شده، سیاست تکرار یا تضمین پشتیبان‌گیری را استنباط نکنید.
چک‌لیست عملی شما.
- عملیات‌هایی را که برنامه نیاز دارد فهرست کنید.
- واسط ذخیره‌سازی مورد انتظار آن را مشخص کنید.
- اشتراک‌گذاری، قفل‌گذاری و معناشناسی دسترسی را بررسی کنید.
- داده و همزمانی واقع‌گرایانه را آزمایش کنید.
- دسترسی برنامه و مدیریتی را جدا نگه دارید.
- همه مجموعه داده‌های مرتبط را با هم بازیابی کنید.
جزئیاتی که اهمیت دارند.
آیا ذخیره‌سازی شیء می‌تواند مانند یک دیسک معمولی استفاده شود؟+
ابزارهای سازگارسازی وجود دارند، اما API و معناشناسی زیربنایی متفاوت است. عملیات مورد نیاز برنامه را اعتبارسنجی کنید، نه اینکه فرض کنید یک واسط سوارشده آن‌ها را معادل می‌کند.
آیا SAN به‌طور خودکار ذخیره‌سازی شیء است؟+
خیر. برچسب SAN یک API شیء را اثبات نمی‌کند. مشخصات واقعی حجم و دسترسی را بخوانید و تأیید کنید پیکربندی چه چیزی را ارائه می‌دهد.
کدام واسط برای پشتیبان‌گیری بهتر است؟+
هدفی را انتخاب کنید که ابزار پشتیبان‌گیری شما از آن پشتیبانی می‌کند و جداسازی دسترسی، نگهداری و بازیابی را بررسی کنید. واسط به‌تنهایی کیفیت پشتیبان‌گیری را تعیین نمی‌کند.
به منبع بروید.
این منابع از مفاهیم فنی این راهنما پشتیبانی می‌کنند. پیش از تغییر یک سیستم تولیدی، مستندات جاری را دنبال کنید.
- AWS: مقایسه ذخیره‌سازی بلوک، فایل و شیء aws.amazon.com
- Amazon S3: مرور کلی اشیاء docs.aws.amazon.com
- Amazon EFS: واسط سیستم فایل و معناشناسی دسترسی docs.aws.amazon.com
راهنمایی تحریریه توسط SwissOctet. مثال‌ها نمایشی هستند. مشخصات خدمات، گزینه‌های موجود و شرایط قراردادی باید جداگانه تأیید شوند.