تحديث!. في التعليقات اقترح أحد القراء المحاولة (ربما يعمل على ذلك بنفسه) ، لذلك أضفت قسمًا حول هذا الحل. أنا أيضا كتبت لأن العملية مختلفة تمامًا عن البقية.
لأكون صادقًا ، استسلمت واستسلمت (على الأقل لغاية الآن). سأستخدم . لماذا؟ بسبب التخزين! من كان يظن أنني سأقوم بالتخزين أكثر من Kubernetes نفسه. أنا أستعمل ، لأنها غير مكلفة والأداء جيد ، ومنذ البداية قمت بنشر مجموعات مع . لم أجرب خدمات Kubernetes المُدارة من Google / Amazon / Microsoft / DigitalOcean إلخ ، وما إلى ذلك ، لأنني أردت تعلم كل شيء بنفسي. أنا أيضا مقتصد.
لذا - نعم ، لقد قضيت الكثير من الوقت في محاولة تحديد التخزين الذي يجب اختياره عندما كنت أفكر في مكدس محتمل على Kubernetes. أفضل الحلول مفتوحة المصدر ، ليس فقط بسبب السعر ، لكنني نظرت إلى خيارين مدفوعين بدافع الفضول ، لأن لديهم إصدارات مجانية مع قيود. لقد قمت بتدوين بعض الأرقام من المعايير الحديثة عندما كنت أقارن الخيارات المختلفة ، وقد تكون ذات أهمية لأولئك الذين يدرسون التخزين في Kubernetes. على الرغم من أنني شخصياً قلت وداعًا لـ Kubernetes حتى الآن. انا ايضا اريد ان اذكر ، حيث يمكنك توفير وحدات تخزين Hetzner Cloud مباشرة ، لكني لم أجربها بعد. كنت أبحث في التخزين المعرّف بالبرنامج السحابي لأنني كنت بحاجة إلى النسخ المتماثل والقدرة على تحميل وحدات تخزين ثابتة بسرعة على أي عقدة ، خاصة في حالة فشل العقدة وغيرها من المواقف المماثلة. تقدم بعض الحلول لقطات سريعة ونسخ احتياطي خارج الموقع ، وهو أمر سهل الاستخدام.
لقد اختبرت 6-7 حلول تخزين:
كما قلت بالفعل ، بعد أن اختبرت معظم الخيارات من القائمة ، استقرت في البداية على OpenEBS. OpenEBS سهل التثبيت والاستخدام ، ولكن بصراحة ، بعد الاختبار ببيانات حقيقية تحت الحمل ، خيب أملي أداءه. هذا مفتوح المصدر ، والمطورين وحدهم دائما مفيد جدا عندما كنت بحاجة للمساعدة. لسوء الحظ ، يتميز بأداء ضعيف جدًا مقارنة بالخيارات الأخرى ، لذلك اضطررت إلى إجراء الاختبارات مرة أخرى. في الوقت الحالي ، يحتوي OpenEBS على 3 محركات تخزين ، لكني أقوم بنشر نتائج معيارية لـ cStor. ليس لدي أرقام لـ Jiva و LocalPV حتى الآن.
باختصار ، فإن Jiva أسرع قليلاً ، و LocalPV سريع بشكل عام ، وليس أسوأ من معيار القيادة مباشرة. تكمن مشكلة LocalPV في أنه لا يمكن الوصول إلى وحدة التخزين إلا من خلال العقدة التي تم توفيرها بها ، ولا يوجد نسخ متماثل على الإطلاق. واجهت بعض المشاكل في استعادة نسخة احتياطية عبر على الكتلة الجديدة لأن أسماء العقد كانت مختلفة. بالحديث عن النسخ الاحتياطية ، لدى cStor ملفات ، والتي يمكنك من خلالها عمل نسخ احتياطية للقطات خارج الموقع ، وهو أكثر ملاءمة من النسخ الاحتياطية على مستوى الملفات باستخدام Velero-Restic. كتبت لتسهيل إدارة النسخ الاحتياطية والاستعادة باستخدام هذا المكون الإضافي. بشكل عام ، أحب OpenEBS حقًا ، لكن أداءه ...
Rook هو أيضًا مفتوح المصدر ، ويختلف عن بقية الخيارات في القائمة من حيث أنه منظم تخزين يقوم بمهام إدارة التخزين المعقدة مع خلفيات مختلفة ، على سبيل المثال , وغيرها ، مما يبسط العمل بشكل كبير. لقد واجهت مشاكل مع EfgeFS عندما جربته قبل بضعة أشهر ، لذلك اختبرت بشكل أساسي مع Ceph. لا يوفر Ceph التخزين الكتلي فحسب ، بل يوفر أيضًا تخزينًا للكائنات متوافقًا مع S3 / Swift ونظام الملفات الموزع. ما يعجبني في Ceph هو القدرة على نشر بيانات الحجم عبر أقراص متعددة بحيث يمكن لوحدة التخزين استخدام مساحة قرص أكبر مما يمكن أن يتسع على قرص واحد. انها مريحة. ميزة أخرى رائعة هي أنه عند إضافة أقراص إلى المجموعة ، فإنه يعيد توزيع البيانات تلقائيًا عبر جميع الأقراص.
لدى Ceph لقطات ، ولكن بقدر ما أعرف لا يمكن استخدامها مباشرة في Rook / Kubernetes. من المسلم به أنني لم أتعمق فيه. ولكن لا توجد نسخ احتياطية خارج الموقع ، لذا يتعين عليك استخدام شيء ما مع Velero / Restic ، ولكن لا يوجد سوى نسخ احتياطية على مستوى الملف ، وليس لقطات في الوقت المناسب. ما يعجبني حقًا في Rook هو سهولة العمل مع Ceph - فهو يخفي تقريبًا جميع الأشياء المعقدة ويوفر أدوات للتحدث مباشرة إلى Ceph لاستكشاف الأخطاء وإصلاحها. لسوء الحظ ، في اختبار التحمل لأحجام Ceph ، كنت دائمًا أقوم بذلك ، مما يؤدي إلى عدم استقرار Ceph. لم يتضح بعد ما إذا كان هذا خطأ في Ceph نفسه أو مشكلة في كيفية إدارة Rook لـ Ceph. لقد تلاعبت بإعدادات الذاكرة ، وتحسنت ، لكن لم يتم حل المشكلة تمامًا. يتمتع Ceph بأداء جيد كما هو موضح في المعايير أدناه. كما أن لديها لوحة تحكم جيدة.
أنا حقا أحب القرون الطويلة. أعتقد أن هذا حل واعد. صحيح أن المطورين أنفسهم (Rancher Labs) يعترفون بأنه غير مناسب لبيئة الإنتاج بعد ، وهذا يظهر. إنه مفتوح المصدر ولديه أداء لائق (على الرغم من أنهم لم يقوموا بتحسينه بعد) ، ولكن الأحجام تستغرق وقتًا طويلاً جدًا لتوصيلها بالجراب ، وفي أسوأ الحالات يستغرق الأمر من 15 إلى 16 دقيقة ، خاصة بعد استعادة نسخة احتياطية كبيرة أو رفع مستوى عبء العمل. يحتوي على لقطات ونسخ احتياطية خارج الموقع لتلك اللقطات ، لكنها تنطبق فقط على وحدات التخزين ، لذلك ما زلت بحاجة إلى شيء مثل Velero لعمل نسخة احتياطية من بقية الموارد. عمليات النسخ الاحتياطي والاستعادة موثوقة للغاية ، ولكنها بطيئة بشكل غير لائق. على محمل الجد ، فقط بطيء بشكل باهظ. غالبًا ما يرتفع استخدام وحدة المعالجة المركزية وحمل النظام عند العمل مع متوسط كمية البيانات في Longhorn. هناك لوحة قيادة يدوية لإدارة Longhorn. لقد قلت بالفعل إنني أحب Longhorn ، لكن يجب العمل عليه بشكل صحيح.
StorageOS هو أول منتج مدفوع في القائمة. يحتوي على إصدار مطور بسعة تخزينية مُدارة محدودة تبلغ 500 جيجابايت ، لكنني لا أعتقد أن هناك حدًا لعدد العقد. أخبرني قسم المبيعات أن التكلفة تبدأ من 125 دولارًا شهريًا مقابل 1 تيرابايت ، إذا كنت أتذكر بشكل صحيح. هناك لوحة معلومات أساسية و CLI سهل الاستخدام ، لكن شيئًا غريبًا يحدث في الأداء: في بعض المعايير يكون لائقًا تمامًا ، لكن في اختبار الضغط للأحجام ، لم تعجبني السرعة على الإطلاق. بشكل عام ، لا أعرف ماذا أقول. لذلك لم أفهم حقًا. لا توجد نسخ احتياطية خارج الموقع هنا وسيتعين عليك أيضًا استخدام Velero مع Restic لأحجام النسخ الاحتياطي. غريب ، لأن المنتج مدفوع. ولم يكن المطورون متحمسين للتواصل في Slack.
لقد تعلمت عن Robin on Reddit من CTO الخاص بهم. لم اسمع به من قبل. ربما لأنني كنت أبحث عن حلول مجانية ، ويتم الدفع لروبن. لديهم نسخة مجانية سخية جدًا بسعة تخزين 10 تيرابايت وثلاث عقد. بشكل عام ، المنتج لائق تمامًا وله ميزات لطيفة. هناك واجهة سطر أوامر رائعة ، ولكن أروع شيء هو أنه يمكنك التقاط البرنامج بأكمله ونسخه احتياطيًا (يسمى إصدارات Helm أو "التطبيقات المرنة" في محدد الموارد) ، بما في ذلك وحدات التخزين والموارد الأخرى ، بحيث يمكنك الاستغناء عن Velero. وسيكون كل شيء رائعًا إن لم يكن لتفاصيل صغيرة واحدة: إذا قمت باستعادة (أو "استيراد" ، كما يطلق عليه في Robin) تطبيقًا على مجموعة جديدة - على سبيل المثال ، في حالة التعافي من الكوارث - استعادة ، بالطبع يعمل ولكن الاستمرار في النسخ الاحتياطي للتطبيق ممنوع. في هذا الإصدار ، هذا ببساطة غير ممكن ، وقد أكد المطورون. هذا أمر غريب ، على أقل تقدير ، خاصة عندما تفكر في مزايا أخرى (على سبيل المثال ، عمليات النسخ الاحتياطي والاستعادة السريعة بشكل لا يصدق). يعد المطورون بإصلاح كل شيء من خلال الإصدار التالي. الأداء جيد بشكل عام ، لكنني لاحظت شيئًا غريبًا: إذا قمت بتشغيل المعيار مباشرة على وحدة تخزين متصلة بالمضيف ، فإن سرعة القراءة أعلى بكثير من نفس الحجم ، ولكن من داخل الكبسولة. جميع النتائج الأخرى متطابقة ، لكن من الناحية النظرية لا ينبغي أن يكون هناك فرق. على الرغم من أنهم يعملون على ذلك ، إلا أنني شعرت بالإحباط بسبب مشكلة الاستعادة والنسخ الاحتياطي - بدا لي أنني وجدت أخيرًا حلاً مناسبًا ، وكنت على استعداد لدفع ثمنه عندما أحتاج إلى مساحة أكبر أو المزيد من الخوادم.
ليس لدي الكثير لأقوله هنا. هذا منتج مدفوع ، رائع بنفس القدر وباهظ الثمن. الأداء مذهل فقط. حتى الآن هذا هو أفضل مؤشر. أخبرني Slack أن الأسعار تبدأ من 205 دولارات شهريًا لكل عقدة ، كما هو مدرج في GKE Marketplace من Google. لا أعرف ما إذا كان سيكون أرخص إذا اشتريت مباشرة. على أي حال ، لا يمكنني تحمله ، لذلك شعرت بخيبة أمل كبيرة لأن ترخيص المطور (حتى 1 تيرابايت وعقد 3) عديم الفائدة عمليًا مع Kubernetes ، إلا إذا كنت راضيًا عن توفير ثابت. كنت آمل أن يتم تخفيض الترخيص المجمع تلقائيًا إلى مطور في نهاية الفترة التجريبية ، لكن هذا لم يحدث. لا يمكن استخدام ترخيص المطور إلا مباشرة مع Docker ، والإعداد في Kubernetes مرهق ومحدود للغاية. بالطبع ، أنا أفضل المصدر المفتوح ، لكن إذا كان لدي المال ، سأختار Portworx بالتأكيد. حتى الآن ، لا يُقارن أداؤها بالخيارات الأخرى.
لقد أضفت هذا القسم بعد نشر المنشور ، عندما اقترح أحد القراء تجربة Linstor. لقد جربته وأعجبني! لكن لا يزال عليك الحفر. الآن أستطيع أن أقول إن الأداء ليس سيئًا (تمت إضافة نتائج القياس أدناه). في الواقع ، حصلت على نفس أداء القرص مباشرة ، دون أي حمل. (لا تسأل لماذا تعد أرقام Portworx أفضل من معيار محرك الأقراص مباشرة. ليس لدي أي فكرة. أعتقد ذلك. ماجيك). لذا يبدو Linstor فعال للغاية حتى الآن. التثبيت ليس بهذه الصعوبة ، ولكن ليس سهلاً مثل الخيارات الأخرى. اضطررت أولاً إلى تثبيت Linstor (وحدة kernel والأدوات / الخدمات) وإعداد LVM لتوفير الدعم الرقيق ودعم اللقطة خارج Kubernetes ، مباشرة على المضيف ، ثم إنشاء الموارد اللازمة لاستخدام التخزين من Kubernetes. لم يعجبني أنه لم يعمل على CentOS واضطررت إلى استخدام Ubuntu. ليس فظيعًا بالطبع ، ولكنه مزعج بعض الشيء ، لأن الوثائق (التي ، بالمناسبة ، ممتازة) تذكر العديد من الحزم التي لا يمكن العثور عليها في مستودعات Epel المحددة. لدى Linstor لقطات ، ولكن لا توجد نسخ احتياطية من خارج الموقع ، لذلك هنا مرة أخرى كان علي استخدام Velero مع Restic لعمل نسخة احتياطية من المجلدات. أفضل اللقطات على النسخ الاحتياطية على مستوى الملف ، ولكن يمكن تحمل ذلك إذا كان الحل فعالًا وموثوقًا به. Linstor مفتوحة المصدر ولكنها دفعت الدعم. إذا فهمت بشكل صحيح ، فيمكن استخدامه دون قيود ، حتى إذا لم يكن لديك عقد دعم ، ولكن هذا يحتاج إلى توضيح. لا أعرف كيف يتم اختبار Linstor لـ Kubernetes ، لكن طبقة التخزين نفسها خارج Kubernetes ، وعلى ما يبدو ، لم يظهر الحل بالأمس ، لذلك ربما تم اختباره بالفعل في ظروف حقيقية. هل هناك حل هنا يجعلني أغير رأيي وأعود إلى Kubernetes؟ لا أعلم. ما زلنا بحاجة إلى التعمق في دراسة التكرار. دعنا نرى. لكن الانطباع الأول جيد. أفضل بالتأكيد استخدام مجموعات Kubernetes الخاصة بي بدلاً من Heroku للحصول على مزيد من الحرية وتعلم أشياء جديدة. نظرًا لأن تثبيت Linstor ليس سهلاً مثل الآخرين ، فسوف أكتب منشورًا حوله قريبًا.
المعايير
لسوء الحظ ، احتفظت بسجلات قليلة للمقارنة ، لأنني لم أكن أعتقد أنني سأكتب عنها. لدي فقط نتائج مرجعية أساسية 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 أفضل من الآخرين. لكنها باهظة الثمن بالنسبة لي. لا أعرف كم يكلف Robin ، ولكن هناك نسخة مجانية رائعة ، لذلك إذا كنت بحاجة إلى منتج مدفوع ، يمكنك تجربته (آمل أن يحلوا مشكلة عمليات الاستعادة والنسخ الاحتياطية قريبًا). من بين الثلاثة المجانية ، واجهت أقل عدد من المشكلات مع OpenEBS ، لكن أداؤها سيئ للغاية. أنا آسف لأنني لم أحفظ المزيد من النتائج ، لكني آمل أن تساعدك الأرقام وتعليقاتي.
المصدر: www.habr.com