فضای ذخیره سازی در Kubernetes: OpenEBS vs Rook (Ceph) vs Rancher Longhorn در مقابل StorageOS در مقابل Robin vs Portworx vs Linstor

به روز رسانی!. در نظرات، یکی از خوانندگان پیشنهاد کرد که تلاش کنید لینستور (شاید خودش روی آن کار می کند) بنابراین من بخشی در مورد این راه حل اضافه کردم. من هم نوشتم پست در مورد نحوه نصب آن، زیرا این روند با بقیه بسیار متفاوت است.

راستش من تسلیم شدم و تسلیم شدم کوبرنیتس (حداقل در حال حاضر). من استفاده خواهم کرد هروکو. چرا؟ به دلیل ذخیره سازی! چه کسی فکرش را می‌کرد که من بیشتر از خود Kubernetes با فضای ذخیره‌سازی کار کنم. من استفاده می کنم هتزنر ابرچون ارزان است و عملکرد خوب است و از همان ابتدا کلاسترها را با استفاده از رانچر. من خدمات مدیریت Kubernetes را از Google/Amazon/Microsoft/DigitalOcean و غیره و غیره امتحان نکردم، زیرا می‌خواستم همه چیز را خودم یاد بگیرم. من هم مقتصد هستم

بنابراین بله، من زمان زیادی را صرف تصمیم‌گیری در مورد اینکه کدام فضای ذخیره‌سازی را انتخاب کنم، هنگام ارزیابی یک پشته احتمالی Kubernetes صرف کردم. من راه‌حل‌های منبع باز را ترجیح می‌دهم، نه تنها به دلیل قیمت، بلکه از روی کنجکاوی به چند گزینه پولی نگاه کردم زیرا نسخه‌های رایگان با محدودیت‌هایی دارند. هنگام مقایسه گزینه‌های مختلف، برخی از اعداد آزمایش‌های اخیر را یادداشت کرده‌ام، و ممکن است برای کسانی که در مورد ذخیره‌سازی Kubernetes یاد می‌گیرند، جالب باشد. اگرچه من شخصاً در حال حاضر با Kubernetes خداحافظی کرده ام. من هم می خواهم اشاره کنم درایور CSI، که می تواند به طور مستقیم حجم های Hetzner Cloud را ارائه دهد، اما من هنوز آن را امتحان نکرده ام. من به فضای ذخیره‌سازی تعریف‌شده توسط نرم‌افزار ابری نگاه کردم، زیرا به تکرار و توانایی نصب سریع حجم‌های ثابت روی هر گره، به‌ویژه در صورت خرابی گره‌ها و سایر موقعیت‌های مشابه، نیاز داشتم. برخی از راه حل ها عکس های لحظه به لحظه و پشتیبان گیری خارج از سایت را ارائه می دهند که راحت است.

من 6-7 راه حل ذخیره سازی را آزمایش کردم:

OpenEBS

همانطور که قبلاً گفتم در پست قبلیبا آزمایش بیشتر گزینه های لیست، در ابتدا روی OpenEBS قرار گرفتم. نصب و استفاده OpenEBS بسیار آسان است، اما صادقانه بگویم، پس از آزمایش با داده های واقعی تحت بار، از عملکرد آن ناامید شدم. این منبع باز است و توسعه دهندگان خودشان هستند کانال شل همیشه وقتی به کمک نیاز داشتم بسیار مفید است. متأسفانه عملکرد بسیار ضعیفی نسبت به سایر گزینه ها دارد، بنابراین آزمایش ها باید دوباره اجرا می شد. OpenEBS در حال حاضر 3 موتور ذخیره سازی دارد، اما من نتایج بنچمارک را برای cStor ارسال می کنم. من هنوز شماره ای برای Jiva و LocalPV ندارم.

به طور خلاصه، Jiva کمی سریعتر است، و LocalPV به طور کلی سریع است، بدتر از معیار دیسک مستقیم نیست. مشکل LocalPV این است که حجم فقط در گره ای که در آن آماده شده است قابل دسترسی است و اصلاً تکراری وجود ندارد. من در بازگردانی یک نسخه پشتیبان از طریق مشکلاتی داشتم قایق بادبانی در یک خوشه جدید زیرا نام گره ها متفاوت بود. اگر در مورد پشتیبان گیری صحبت کنیم، cStor دارد پلاگین برای Velero، که با آن می توانید در یک نقطه از زمان از عکس های فوری پشتیبان خارج از سایت تهیه کنید که راحت تر از پشتیبان گیری در سطح فایل با Velero-Restic است. نوشتم چندین اسکریپت، برای سهولت در مدیریت پشتیبان گیری و بازیابی با این افزونه. در کل، من خیلی OpenEBS را دوست دارم، اما عملکرد آن ...

رخ

Rook همچنین منبع باز است، و چیزی که آن را از بقیه گزینه های موجود در لیست متمایز می کند این است که یک سازمان دهنده ذخیره سازی است که وظایف پیچیده مدیریت ذخیره سازی را با باطن های مختلف انجام می دهد، به عنوان مثال. سف, EdgeFS و دیگران که کار را بسیار ساده می کند. من وقتی چند ماه پیش آن را امتحان کردم با EfgeFS مشکل داشتم، بنابراین عمدتاً با Ceph تست کردم. Ceph نه تنها ذخیره سازی بلوکی را ارائه می دهد، بلکه ذخیره سازی اشیاء سازگار با S3/Swift و سیستم فایل توزیع شده را نیز ارائه می دهد. چیزی که من در مورد Ceph دوست دارم، توانایی پخش داده های حجمی در چندین دیسک است به طوری که حجم می تواند از فضای دیسک بیشتری نسبت به فضای موجود در یک دیسک استفاده کند. راحت است. یکی دیگر از ویژگی های جالب این است که وقتی دیسک ها را به یک کلاستر اضافه می کنید، به طور خودکار داده ها را در همه دیسک ها توزیع می کند.

Ceph عکس های فوری دارد، اما تا آنجا که من می دانم، آنها را نمی توان مستقیماً در Rook/Kubernetes استفاده کرد. درست است، من به این موضوع عمیق نرفتم. اما هیچ نسخه پشتیبان خارج از سایتی وجود ندارد، بنابراین باید از چیزی با Velero/Restic استفاده کنید، اما فقط پشتیبان‌گیری در سطح فایل وجود دارد، نه عکس‌های لحظه به لحظه. چیزی که من در مورد Rook خیلی دوست داشتم این بود که کار با Ceph چقدر آسان است - تقریباً همه چیزهای پیچیده را پنهان می کند و ابزارهایی برای صحبت مستقیم با Ceph برای عیب یابی ارائه می دهد. متأسفانه، در طول تست استرس جلدهای Ceph، من مدام با آن مشکل داشتم این مشکل، که باعث می شود Ceph ناپایدار شود. هنوز مشخص نیست که آیا این یک اشکال در خود Ceph است یا مشکلی در نحوه مدیریت Ceph است. تنظیمات حافظه رو سرهم کردم و بهتر شد اما مشکل به طور کامل حل نشد. Ceph عملکرد مناسبی دارد، همانطور که در بنچمارک های زیر می بینید. داشبورد خوبی هم داره.

Rancher Longhorn

من لانگ هورن را خیلی دوست دارم. به نظر من، این یک راه حل امیدوارکننده است. درست است که خود توسعه دهندگان (Rancher Labs) اعتراف می کنند که هنوز برای محیط کار مناسب نیست و این نشان می دهد. منبع باز است و عملکرد مناسبی دارد (اگرچه هنوز آن را بهینه نکرده اند)، اما ولوم ها زمان زیادی طول می کشد تا به پاد متصل شوند، و در بدترین موارد 15 تا 16 دقیقه طول می کشد، به خصوص پس از بازگردانی یک نسخه پشتیبان یا بزرگ. ارتقاء حجم کار دارای عکس‌های فوری و پشتیبان‌گیری خارج از سایت از این عکس‌های فوری است، اما آنها فقط برای حجم‌ها اعمال می‌شوند، بنابراین برای پشتیبان‌گیری از منابع دیگر همچنان به چیزی مانند Velero نیاز دارید. پشتیبان گیری و بازیابی بسیار قابل اعتماد هستند، اما به طرز غیرعادی کندی هستند. به طور جدی، فقط فوق العاده کند است. استفاده از CPU و بار سیستم اغلب هنگام کار با مقدار متوسط ​​داده در Longhorn افزایش می یابد. یک داشبورد مناسب برای مدیریت Longhorn وجود دارد. قبلاً گفته بودم که Longhorn را دوست دارم، اما نیاز به کار دارد.

StorageOS

StorageOS اولین محصول پولی در لیست است. یک نسخه توسعه دهنده با حجم ذخیره سازی مدیریت شده محدود 500 گیگابایت دارد، اما فکر نمی کنم محدودیتی در تعداد گره ها وجود داشته باشد. بخش فروش به من گفت که هزینه از 125 دلار در ماه برای 1 ترابایت شروع می شود، اگر درست یادم باشد. یک داشبورد اولیه و یک CLI راحت وجود دارد، اما چیز عجیبی با عملکرد در حال رخ دادن است: در برخی از معیارها کاملا مناسب است، اما در تست استرس حجم صدا من اصلا از سرعت آن خوشم نیامد. در کل نمیدونم چی بگم بنابراین من واقعاً چیز زیادی متوجه نشدم. در اینجا هیچ نسخه پشتیبان خارج از سایت وجود ندارد و همچنین باید از Velero با Restic برای تهیه نسخه پشتیبان استفاده کنید. عجیب است، زیرا محصول پرداخت می شود. و توسعه دهندگان مشتاق به برقراری ارتباط در Slack نبودند.

سینه سرخ

من در مورد رابین در Reddit از مدیر فنی آنها یاد گرفتم. من تا به حال نام او را نشنیده بودم. شاید به این دلیل که من به دنبال راه حل های رایگان بودم، اما رابین پول می گیرد. آنها یک نسخه رایگان بسیار سخاوتمندانه با 10 ترابایت فضای ذخیره سازی و سه گره دارند. به طور کلی، این محصول کاملاً مناسب است و ویژگی های خوبی دارد. یک CLI فوق‌العاده وجود دارد، اما جالب‌ترین چیز این است که می‌توانید از کل برنامه عکس بگیرید و پشتیبان‌گیری کنید (در انتخابگر منابع به این نسخه‌های Helm یا «برنامه‌های انعطاف‌پذیر» می‌گویند)، از جمله حجم‌ها و منابع دیگر، بنابراین می‌توانید بدون Velero این کار را انجام دهید. و اگر یک جزئیات کوچک نباشد، همه چیز فوق العاده خواهد بود: اگر برنامه را در یک خوشه جدید بازیابی کنید (یا "وارد کنید"، همانطور که در رابین نامیده می شود) - به عنوان مثال، در صورت بهبودی از یک فاجعه - بازیابی، البته، کار می کند، اما همچنان به پشتیبان گیری از برنامه ممنوع است. همانطور که توسعه دهندگان تایید کرده اند، این به سادگی در این نسخه امکان پذیر نیست. این، به بیان ملایم، عجیب است، به خصوص با توجه به مزایای دیگر (به عنوان مثال، پشتیبان گیری و بازیابی فوق العاده سریع). توسعه دهندگان قول می دهند که تا نسخه بعدی همه چیز را برطرف کنند. عملکرد به طور کلی خوب است، اما من متوجه یک نکته عجیب شدم: اگر معیار را مستقیماً روی یک حجم متصل به میزبان اجرا کنم، سرعت خواندن بسیار سریعتر از اجرای همان حجم از داخل پاد است. همه نتایج دیگر یکسان هستند، اما در تئوری نباید تفاوتی وجود داشته باشد. اگرچه آنها روی آن کار می کنند، اما من از مشکل بازیابی و پشتیبان گیری ناراحت بودم - فکر می کردم بالاخره راه حل مناسبی پیدا کرده ام و حتی حاضر بودم وقتی به فضای بیشتر یا سرورهای بیشتری نیاز داشتم هزینه آن را بپردازم.

portworx

اینجا چیز زیادی برای گفتن ندارم. این یک محصول پولی است، به همان اندازه جالب و گران است. عملکرد به سادگی شگفت انگیز است. این بهترین شاخص تا کنون است. Slack به من گفت که قیمت از 205 دلار در ماه برای هر گره شروع می شود، همانطور که در بازار GKE گوگل ذکر شده است. نمی دونم با خرید مستقیم ارزون تر میشه یا نه. به هر حال من نمی توانم آن را بپردازم، بنابراین بسیار بسیار ناامید شدم که مجوز توسعه دهنده (حداکثر 1 ترابایت و 3 گره) با Kubernetes عملاً بی فایده است، مگر اینکه به ارائه استاتیک رضایت دهید. من امیدوار بودم که مجوز حجم به طور خودکار در پایان دوره آزمایشی به توسعه دهنده کاهش یابد، اما این اتفاق نیفتاد. مجوز توسعه دهنده فقط می تواند مستقیماً با Docker استفاده شود و پیکربندی در Kubernetes بسیار دست و پا گیر و محدود است. البته من متن باز رو ترجیح میدم ولی اگه پول داشتم حتما Portworx رو انتخاب میکردم. تا کنون، عملکرد آن به سادگی با گزینه های دیگر مقایسه نمی شود.

لینستور

این بخش را بعد از انتشار پست اضافه کردم، زمانی که یکی از خوانندگان پیشنهاد امتحان Linstor را داد. امتحانش کردم و خوشم اومد! اما ما هنوز باید عمیق‌تر بگردیم. حالا می توانم بگویم که عملکرد بد نیست (نتایج بنچمارک را در زیر اضافه کردم). در اصل، من به طور مستقیم و بدون هیچ هزینه اضافی، همان عملکرد دیسک را داشتم. (نپرسید که چرا Portworx مستقیماً اعداد بهتری نسبت به معیار درایو دارد. من هیچ ایده ای ندارم. حدس می زنم جادو.) بنابراین Linstor تا اینجا بسیار مؤثر به نظر می رسد. نصب آن چندان دشوار نیست، اما به آسانی گزینه های دیگر نیست. ابتدا باید Linstor (ماژول هسته و ابزارها/سرویس‌ها) را نصب می‌کردم و LVM را برای thin provisioning و پشتیبانی عکس فوری در خارج از Kubernetes، مستقیماً روی میزبان پیکربندی می‌کردم و سپس منابع مورد نیاز برای استفاده از ذخیره‌سازی را از Kubernetes ایجاد می‌کردم. من دوست نداشتم که روی CentOS کار نمی کند و مجبور شدم از اوبونتو استفاده کنم. البته وحشتناک نیست، اما کمی آزاردهنده است، زیرا در اسناد (که اتفاقاً عالی است) چندین بسته ذکر شده است که در مخازن مشخص شده Epel یافت نمی شوند. Linstor دارای عکس های فوری است، اما نه پشتیبان گیری خارج از سایت، بنابراین در اینجا دوباره مجبور شدم از Velero با Restic برای پشتیبان گیری حجم ها استفاده کنم. من عکس‌های فوری را به جای پشتیبان‌گیری در سطح فایل ترجیح می‌دهم، اما اگر راه‌حل کارآمد و قابل اعتماد باشد، می‌توان آن را تحمل کرد. لینستور منبع باز است اما پشتیبانی پولی دارد. اگر درست متوجه شده باشم می توان بدون محدودیت استفاده کرد، حتی اگر قرارداد پشتیبانی نداشته باشید، اما این باید روشن شود. من نمی دانم Linstor چقدر برای Kubernetes آزمایش شده است، اما خود لایه ذخیره سازی خارج از Kubernetes است و ظاهراً راه حل دیروز ظاهر نشد، بنابراین احتمالا قبلاً در شرایط واقعی آزمایش شده است. آیا راه حلی در اینجا وجود دارد که باعث شود نظرم تغییر کند و به Kubernetes برگردم؟ نمی دانم. ما هنوز باید عمیق‌تر کاوش کنیم و همانندسازی را مطالعه کنیم. اجازه بدید ببینم. اما برداشت اول خوب است. من قطعا ترجیح می دهم از خوشه های Kubernetes خودم به جای Heroku استفاده کنم تا آزادی بیشتری داشته باشم و چیزهای جدید یاد بگیرم. از آنجایی که لینستور به راحتی نصب نمی شود، به زودی پستی در مورد آن خواهم نوشت.

معیارها

متأسفانه، من یادداشت های زیادی در مورد مقایسه نگه نداشتم زیرا فکر نمی کردم در مورد آن بنویسم. من فقط نتایجی از معیارهای پایه fio و فقط برای خوشه‌های تک گره دارم، بنابراین هنوز اعدادی برای پیکربندی‌های تکراری ندارم. اما از این نتایج می توانید یک ایده تقریبی در مورد انتظارات از هر گزینه به دست آورید، زیرا من آنها را روی همان سرورهای ابری، 4 هسته، 16 گیگابایت رم، با 100 گیگابایت دیسک اضافی برای حجم های آزمایش شده مقایسه کردم. من معیارها را سه بار برای هر راه حل اجرا کردم و میانگین نتیجه را محاسبه کردم، به علاوه تنظیمات سرور را برای هر محصول بازنشانی کردم. همه اینها کاملا غیر علمی است، فقط برای اینکه یک ایده کلی به شما بدهم. در تست های دیگر، 38 گیگابایت عکس و فیلم را از روی حجم کپی کردم و خواندن و نوشتن را تست کردم، اما افسوس که اعداد را ذخیره نکردم. به طور خلاصه: Portworkx بسیار سریعتر بود.

برای معیار حجم از این مانیفست استفاده کردم:

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: dbench
spec:
  storageClassName: ...
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
---
apiVersion: batch/v1
kind: Job
metadata:
  name: dbench
spec:
  template:
    spec:
      containers:
      - name: dbench
        image: sotoaster/dbench:latest
        imagePullPolicy: IfNotPresent
        env:
          - name: DBENCH_MOUNTPOINT
            value: /data
          - name: FIO_SIZE
            value: 1G
        volumeMounts:
        - name: dbench-pv
          mountPath: /data
      restartPolicy: Never
      volumes:
      - name: dbench-pv
        persistentVolumeClaim:
          claimName: dbench
  backoffLimit: 4

من ابتدا یک جلد با کلاس ذخیره سازی مناسب ایجاد کردم و سپس کار را با fio در پشت صحنه اجرا کردم. من 1 گیگابایت طول کشید تا عملکرد را تخمین بزنم و زیاد منتظر نمانم. در اینجا نتایج آمده است:

من بهترین مقدار را برای هر متریک با رنگ سبز و بدترین مقدار را با رنگ قرمز مشخص کرده ام.

نتیجه

همانطور که می بینید، در بیشتر موارد Portworx بهتر از دیگران عمل کرد. اما برای من گران است. من نمی دانم هزینه رابین چقدر است، اما آنها یک نسخه رایگان عالی دارند، بنابراین اگر یک محصول پولی می خواهید، می توانید آن را امتحان کنید (امیدوارم به زودی مشکل را با بازیابی و پشتیبان گیری برطرف کنند). از بین سه رایگان، من کمترین مشکل را با OpenEBS داشتم، اما عملکرد آن افتضاح است. حیف که نتایج بیشتری را ذخیره نکردم، اما امیدوارم اعداد و نظرات من به شما کمک کند.

منبع: www.habr.com