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