معمولا ذخیره‌سازی پایدار اصلی‌ترین نیاز هر سیستم ذخیره‌سازیه. چه سرویس ذخیره‌سازی ابری باشه و یا سیستم ذخیره‌سازی شبکه‌ای مشترک و یا حتی یک درایو تنها.      

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

یکی از جاهایی که مبحث ذخیره‌سازی پایدار مطرح میشه توی محیط کانتینر‌هاست؛ یعنی برای اینکه بتونیم با استفاده از کانتینرها برنامه‌های stateful بسازیم لازمه که از ذخیره‌سازی پایدار استفاده کنیم.

البته خوبه که بدونین ذخیره‌سازی پایدار از ابتدا یک چالش توی کانتینرها نبوده و قرار بر این بوده که وقتی کار یک کانتینر تموم میشه خروجی رو به هر منبعی که لازمه تحویل بده و داده‌های موجود توی اون کانتینر از بین بره.

بنابراین اگر نیاز داشته باشین که بعد از حذف شدن کانتینر، داده‌های اون از بین نره باید از  فضای ذخیره‌سازی در خارج از کانتینرها استفاده کنین.    

الزامات ذخیره‌سازی پایدار در کانتینرها 

یک عنصر اصلی و قابل اطمینان در ساخت برنامه‌های کاربردی مبتنی بر کانتینر، وجود یک راه حل ذخیره‌سازی مناسبه و اگر این راه‌حل درست انتخاب بشه، یک مزیت رقابتی خیلی خوب به حساب میاد. 

اگر دوست دارین بدونین یک راه‌حل درست چه ویژگی‌هایی داره، با ما همراه باشین:

 Redundant (افزونگی) 

یکی از دلایل انتقال برنامه به کانتینرها اینه که بتونیم گره‌های فیزیکی زیادی داشته باشیم تا با وجود خرابی داده‌هامون رو از دست ندیم.

 Distributed (توزیع شدگی) 

باید از نظر جغرافیایی محل ذخیره‌سازی‌مون رو جوری توزیع کنیم که دسترسی به فضای ذخیره‌سازی از هر مکانی با سرعت بالا و کم‌ترین تاخیر انجام بشه.

Dynamic (پویایی)

معماری کانتینر مدام در حال تغییر و تحوله. تو این نوع معماری، باید تامین فضای ذخیره‌سازی و آزادسازی اون به صورت پویا امکان‌پذیر باشه. 

Flexible ( انعطاف‌پذیری)

تکنولوژی کانتینر به سرعت در حال پیشرفته و ما باید بتونیم راه‌حل‌های جدید ذخیره‌سازی رو معرفی کنیم که قادر به پشتیبانی از هر زیرساخت اساسی باشن.

Transparent (شفافیت)

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

توی بخش بعدی با دو روش ذخیره‌سازی موقت و پایدار در کانتینرها آشنا می‌شیم. 

ذخیره‌سازی پایدار در کانتینرها

یکی از ویژگی‌‌های کانتینرها، ذخیره‌سازی‌های موقت و زودگذر هستن؛ به این صورت که هر تغییری رو می‌تونین اعمال کنین، بعد اون کانتینر رو متوقف کنین و کانتینر جدیدی رو استفاده کنین. بعد از این کار، فایل‌های قبلی حذف و ریست می‌شن و شما دیگه به داده‌های قبلی دسترسی ندارین.
توی مثال زیر یک کانتینر داکری ایجاد و اجرا شده. داده‌ها در مسیر /hello-file ذخیره شدن، اما بعد از متوقف شدن کانتینر و اجرای مجدد اون در مسیر مربوطه، در کانتینر داده‌ای باقی نمونده: 

# docker run -it centos
[root@d42876f95c6a /]# echo "Hello world" > /hello-file
[root@d42876f95c6a /]# exit
exit
# docker run -it centos
[root@a0a93816fcfe /]# cat /hello-file
cat: /hello-file: No such file or directory

برای ذخیره‌سازی داده‌های انبوه، نمی‌تونیم فقط از ذخیره‌سازی موقت و زودگذر استفاده کنیم. کانتینرها باید بتونن به ذخیره‌سازی دائمی و پایدار هم دسترسی داشته باشن. 

برای ذخیره سازی دائم و پایدار توی کانتینرها می‌تونیم یک دایرکتوری (مسیر) رو تو سیستم فایل میزبان ایجاد کنیم.

مثلا برای یک کانتینر داکری می‌شه این مدیریت رو به خود Docker سپرد تا بتونه مدیریت فضای ذخیره‌سازی رو انجام بده. 

تو مثال زیر نشون داده شده که داکر چه‌جوری فضای ذخیره‌سازی پایدار رو مدیریت می‌کنه:   

# docker volume create data
data
# docker run -it -v data:/data centos
[root@5238393087ae /]# echo "Hello world" > /data/hello-file
[root@5238393087ae /]# exit
exit
# docker run -it -v data:/data centos
[root@e62608823cd0 /]# cat /data/hello-file
Hello world

داکر volume داده رو حفظ می‌کنه و volume در کانتینر دوم هم mount می‌شه، به همین دلیلم هست که در این حالت ذخیره‌سازی دائمی و پایداره. 

این ذخیره‌سازی دائمی و پایدار، روی یک سیستم واحد به راحتی انجام می‌شه، اما دسترسی به ذخیره‌سازی مداوم و پایدار توی کلاستری از کانتینرها مثل Kubernetes و Mesos پیچیده‌تره. 

ذخیره‌سازی با استفاده از Volumeهای پایدار

همونطور که گفتیم در بستر کانتینری باید این امکان فراهم باشه که بتونیم فضای ذخیره سازی دائم رو برای کلاستری از کانتینرها تامین کنیم و این پیچیدگی‌های خاص خودش رو داره. 

برای ذخیره و مدیریت داده‌های حجیم راه‌حلی به نام volume ارائه شده. منظور از volume، فایل‌سیستمی هست که روی ماشین میزبان و خارج از هر کانتینر قرار داره و باید یک مسیر از هر کانتینر روی اون mount بشه.

 این volume می‌تونه توسط یک یا چند کانتینر در هر زمانی مورد استفاده قرار بگیره. 

یکی از مزایای volume اینه که وقتی کانتینر رو حذف کنین داده‌های مربوط به volume باقی می‌مونه.
volume یک نقطه‌ی نصب دایرکتوریه و تعیین می‌کنه که کانتینر شما داده‌های دائمی خودش رو کجا ذخیره کرده و یا مورد دسترسی قرار می‌ده. همچنین این امکان وجود دارد که فضای ذخیره‌سازی رو روی سرور خودمون فراهم کنیم و یا روی یک سرور دیگه این کار رو انجام بدیم. 

توسعه‌دهندگان وب می‌تونن از Persistent Volume Claims یا PVCها برای درخواست volumeهای پایدار یا PVها استفاده کنن بدون این‌که دانش خاصی از زیرساخت‌های ذخیره‌سازی اصولی داشته باشن. 

PVC‌ها می‌تونن ظرفیت ذخیره‌سازی خاص و حالت‌های دسترسی رو درخواست کنن. به عنوان مثال می‌‌شه اون‌ها رو یک‌بار  به صورت خوندنی/نوشتنی و یا چند بار فقط به صورت خوندنی در کانتینر mount کنیم. 

هر PV دارای spec و status هست که مشخصات و وضعیت اون volume رو نشون می‌ده. به عنوان مثال تعریف شیء  PV این‌جوری انجام می‌شه:

apiVersion: v1
kind: PersistentVolume
metadata:
(1)      name: pv0001 
spec:
  capacity:
 (2)       storage: 5Gi 
   accessModes:
  (3)    - ReadWriteOnce 
(4)    persistentVolumeReclaimPolicy: Retain 
  ...
status:
  ...

(1): نام volume پایدار.

(2): میزان فضای ذخیره سازی موجود در volume.

(3): حالت دسترسی ، تعریف مجوزهای خواندن/ نوشتن و mount شدن.

(4): سیاست تقاضای مجدد، نشان دهنده چگونگی مدیریت منابع پس از انتشار است.

انواع فضاهای ذخیره‌سازی پایدار در کانتینرها

سوالی که مطرح می‌شه اینه که چجوری یک کانتینر می‌تونه PVهای توزیع‌شده رو مورد استفاده قرار بده؟ برای این موضوع سیستم‌فایل‌ها و فضاهای ذخیره‌سازی مختلفی وجود دارن. مثلا glusterFS، EBS، NFS و Samba که می‌تونن امکان ذخیره‌سازی پایدار در کانتینرها رو فراهم کنن. در ادامه سعی می‌کنیم یه دید کلی از هر کدوم بهتون بدیم و بعد از اون روشی رو که سکو برای ذخیره‌سازی پایدار ازش استفاده می‌کنه رو توضیح می‌دیم.

 GlusterFS

glusterFS یک سیستم فایل توزیع شده در فضای کاربره و یکی از ویژگی‌هاش اینه که در اون، داده‌ها تو سیستم فایل‌های بومی مثل ex4، xfs و .. ذخیره می‌شن. این سرویس می‌تونه کلاینت‌های متعددی رو مدیریت و کنترل کنه. 

یک glusterFS daemon‌ روی هر سروری اجرا می‌شه تا یک سیستم فایل محلی رو به عنوان یک volume‌ ارسال کنه و کلاینت هم از طریق پروتکل‌های سفارشی مثلTCP/IP و سوکت مستقیم به سرورها متصل می‌شه و فایل‌ها رو در سرور glusterFS ذخیره می‌کنه. 

Samba

 Samba از زمان انتشار در سال ۱۹۹۲ به دلیل سرویسی که ارائه می‌کنه محبوبیت زیادی پیدا کرده. این نوع روش استفاده، برای سیستم‌های UNIX/LINUX توسعه داده شده و خدماتی ایمن، پایدار، سریع برای اشتراک‌گذاری به کلیه‌ی کلاینت‌هایی که از پروتکل SMB/CIFS استفاده می‌کنن ارائه می‌ده.  

Samba یک مولفه‌ی مهم برای ادغام یکپارچه‌ی سرورهای linux/unix و دسکتاپ در محیط‌های active directory هست و می‌تونه به عنوان یک کنترل‌کننده‌ی دامنه هم عمل کنه.

EBS

 Amazon Elastic Block Store  یا (EBS) یک سرویس ذخیره‌سازی ابری با کارایی بالاست که با استفاده از سیستم‌های محاسبات ابری می‌تونه میزان زیاد بار‌کاری رو در هر مقیاسی مدیریت کنه و در صورت تقاضای افراد و شرکت‌ها به اون‌ها ارائه بده. 

Amazon Elastic Compute Cloud یکی از سرویس‌هاییه که به کاربران اجازه می‌ده یک خوشه‌ی مجازی رایانه که در هر مکان و زمانی از طریق اینترنت در دسترس هست رو در اختیار داشته باشن. 

NFS

یک سیستم‌فایل شبکه (NFS) به میزبان راه دور اجازه می‌ده تا سیستم‌فایل‌ها رو روی یک شبکه mount‌ کنه و با اون‌ها تعامل برقرار کنه.

مدیران سیستم هم می‌تونن منابع رو بر روی سرورهای متمرکز در شبکه تلفیق کنن. 

در حال حاضر استراتژی سکو در رابطه با داده های پایدار چیه؟

ما در سکو هم برای مدیریت برنامه‌های کاربران نیاز به یک فضای ذخیره‌سازی دائمی داریم که داده‌های برنامه حتی بعد از توقف و اجرای مجدد کانتینر هم باقی بمونن. حافظه‌ی تخصیص داده شده توسط سکو بین همه کانتینرهای برنامه‌ی شما مشترک و قابل دسترسی هست. در این حالت باید از گزینه‌ی ذخیره‌سازی دائمی یا پایدار برای داده‌ها استفاده کنین.

 اما چه‌جوری؟!

کانتینرهای مربوط به برنامه‌های هر کاربر توسط Mesos مدیریت می‌شن. معماری مسوس این امکان رو در اختیار سازمان‌ها قرار می‌ده که با ایجاد پلتفرمی یکپارچه بتونن هر ترکیبی از بارهای کاری رو بر روی هر ترکیبی از زیرساخت‌ها، اجرا کنن. 

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

 آدرسی هم که برای ساخت ماژول ذخیره‌سازی اون استفاده می‌کنیم در واقع مسیریه که مشخص می‌کنیم داده‌ها در اون مسیر در glusterFS ذخیره بشن.

 از اون جایی که داده‌های کانتینر از بین نمی‌ره؛ اگر برنامه یا اپلیکیشن شما متوقف بشه و بعد دوباره اجرا بشه شما به اون داده‌ها دسترسی دارین و می‌تونین اون‌ها رو مشاهده کنین.

منبع:

https://dzone.com/refcardz/persistent-container-storage?chapter=1