🏈 👩🏾‍🤝‍👨🏽 👨‍💼 حالة وأداء حلول التخزين المستمرة من Kubernetes 🖌️ 👨‍👩‍👦‍👦 👐

ملحوظة perev. : على الرغم من أن هذه المراجعة لا تدعي أنها مقارنة فنية مصممة بعناية للحلول الحالية للتخزين الدائم للبيانات في Kubernetes ، إلا أنها يمكن أن تكون نقطة بداية جيدة للمشرفين ذوي الصلة بهذه المشكلة. تم إيلاء أكبر قدر من الاهتمام لحل Piraeus ، الألفة التي ستفيد ليس فقط عشاق Linstor ، ولكن أيضًا أولئك الذين لم يسمعوا عن هذه المشاريع.

هذه نظرة عامة غير علمية على حلول التخزين لـ Kubernetes. بيان المشكلة: يتطلب القدرة على إنشاء وحدة تخزين ثابتة على أقراص العقدة ، سيتم حفظ بياناتها في حالة تلف العقدة أو إعادة تشغيلها.

الدافع وراء هذه المقارنة هو الحاجة إلى ترحيل أسطول خوادم الشركة من عدة خوادم معدنية مخصصة مخصصة إلى مجموعة Kubernetes.

شركتي شركة ناشئة برازيلية Escavador مع احتياجات حوسبة ضخمة (بشكل أساسي وحدة المعالجة المركزية) وميزانية محدودة للغاية. نقوم بتطوير حلول البرمجة اللغوية العصبية لهيكلة البيانات القانونية.

بسبب الأزمة مع COVID-19 ، انخفض الريال البرازيلي إلى مستوى قياسي منخفض مقابل الدولار الأمريكي

إن عملتنا الوطنية في الواقع أقل من الواقع حقًا ، لذا فإن متوسط راتب أحد كبار المطورين هو 2000 دولار أمريكي فقط في الشهر. وبالتالي ، لا يمكننا تحمل رفاهية إنفاق مبالغ كبيرة على الخدمات السحابية. عندما أجريت الحسابات لآخر مرة ، [بفضل استخدام خوادمي] وفرنا 75٪ مقارنة بما سأدفعه مقابل AWS. بعبارة أخرى ، يمكن توظيف مطور آخر مقابل المال المدخر - أعتقد أن هذا استخدام أكثر عقلانية للأموال.

مستوحاة من سلسلة من المنشورات من Vito Botta ، قررت إنشاء مجموعة K8s باستخدام Rancher (وحتى الآن ...). أجرى Vito أيضًا تحليلًا ممتازًا لحلول التخزين المختلفة. الفائز الواضح كان Linstor (حتى أنه خص بهالدوري الخاص ). المفسد: أتفق معه.

لبعض الوقت كنت أتابع حركة المرور حول Kubernetes ، لكنني قررت مؤخرًا المشاركة فيها. هذا يرجع في المقام الأول إلى حقيقة أن المزود لديه خط جديد من معالجات Ryzen. ثم فوجئت للغاية برؤية أن العديد من الحلول لا تزال في حالة تطور أو غير ناضجة (خاصة بالنسبة لمجموعات المعادن العارية: VM virtualization ، MetalLB ، وما إلى ذلك). لا تزال الخزائن على المعدن العاري في مراحلها الناضجة ، على الرغم من أنها ممثلة بالعديد من الحلول التجارية والمفتوحة المصدر. قررت مقارنة الحلول الرئيسية الواعدة والمجانية (اختبار منتج تجاري واحد في نفس الوقت لفهم ما أفقده). مجموعة من حلول

التخزين في CNCF Landscape

لكن بادئ ذي بدء ، أريد أن أحذرك من أنني جديد على K8s.

للتجارب ، تم استخدام 4 عمال مع التكوين التالي: معالج Ryzen 3700X ، ذاكرة ECC 64 جيجابايت ، حجم NVMe 2 TB. تم إجراء sotoaster/dbench:latestمقاييس الأداء باستخدام الصورة (على نظام المعلومات) مع العلم O_DIRECT.

قرون طويلة

الترخيص: أباتشي 2
الدعم التجاري: Rancher
URL: github.com/longhorn/longhorn
النجوم على جيثب: 1.3 ألف

أنا حقا أحب Longhorn. إنه متكامل تمامًا مع Rancher ويمكنك تثبيته من خلال Helm بنقرة واحدة.

تثبيت Longhorn من Rancher

هذه أداة مفتوحة المصدر مع حالة مشروع sandbox من Cloud Native Computing Foundation (CNCF). تم تمويل تطويره من قبل Rancher - شركة ناجحة إلى حد ما مع منتج معروف [مسمى].

تتوفر أيضًا واجهة رسومية ممتازة - كل شيء يمكن القيام به من خلاله. مع الأداء ، كل شيء في محله. لا يزال المشروع في مرحلة تجريبية ، وهو ما تؤكده مشكلات على GitHub.

عند الاختبار ، أطلقت معيارًا باستخدام نسختين طبق الأصل و Longhorn 0.8.0:

قراءة / كتابة عشوائية ، IOPS: 28.2k / 16.2k ؛
قراءة / كتابة عرض النطاق الترددي: 205 ميجا بايت / ثانية / 108 ميجا بايت / ثانية ؛
متوسط زمن الوصول للقراءة / الكتابة (usec): 593.27 / 644.27 ؛
القراءة / الكتابة التسلسلية: 201 ميجا بايت / ثانية / 108 ميجا بايت / ثانية ؛
قراءة / كتابة عشوائية مختلطة ، IOPS: 14.7k / 4904.

Openebs

الترخيص: أباتشي 2
الدعم التجاري: عدة شركات (؟) ؛ mayadata.io يبدو الأكبر
URL: github.com/openebs/openebs
النجوم على جيثب: 6 ك

يحتوي هذا المشروع أيضًا على حالة صندوق حماية CNCF. مع وجود عدد كبير من النجوم على GitHub ، يبدو أنه حل واعد للغاية. في مراجعته ، اشتكى فيتو بوتا من عدم كفاية الأداء. هذا ما رد عليه الرئيس التنفيذي لشركة Mayadata:

المعلومات قديمة جدا. تم استخدام OpenEBS لدعم 3 ، ولكنه الآن يدعم 4 محركات ، إذا قمت بتمكين التزويد الديناميكي وتنسيق localPV ، والتي يمكن تشغيلها بسرعات NVMe. بالإضافة إلى ذلك ، محرك MayaStor مفتوح الآن ويتلقى بالفعل مراجعات إيجابية (على الرغم من أنه يحتوي على حالة ألفا).

في صفحة مشروع OpenEBS يوجد مثل هذا التفسير حول حالته:

OpenEBS — Kubernetes. OpenEBS sandbox- CNCF 2019- , - (local, nfs, zfs, nvme) on-premise, . OpenEBS - stateful- — Litmus Project, — OpenEBS. OpenEBS production 2018 ; 2,5 docker pull'.

لديها العديد من المحركات ، وآخرها يبدو واعدًا جدًا من حيث الأداء: "MayaStor - محرك ألفا مع NVMe over Fabrics". للأسف ، لم أختبره بسبب حالة إصدار ألفا.

في الاختبارات ، تم استخدام الإصدار 1.8.0 على محرك jiva. بالإضافة إلى ذلك ، راجعت سابقًا cStor ، لكنني لم أحفظ النتائج ، والتي ، مع ذلك ، كانت أبطأ قليلاً من jiva. بالنسبة للمعيار ، تم تثبيت مخطط Helm مع جميع الإعدادات الافتراضية وتم استخدام فئة التخزين ، التي تم إنشاؤها بشكل قياسي بواسطة Helm ( openebs-jiva-default). تبين أن الأداء هو أسوأ الحلول التي تم النظر فيها (سأكون ممتنًا للحصول على المشورة بشأن تحسينها).

OpenEBS 1.8.0 بمحرك jiva (3 نسخ طبق الأصل؟):

قراءة / كتابة عشوائية ، IOPS: 2182/1527 ؛
عرض النطاق الترددي للقراءة / الكتابة: 65.0 ميجابايت / ثانية / 41.9 ميجابايت / ثانية ؛
/ (usec): 1825.49 / 2612.87;
/: 95.5 / / 37.8 /;
/, IOPS: 2607 / 856.

. Evan Powell, OpenEBS ( , StackStorm Nexenta):

, Bruno! OpenEBS . Jiva, ARM overhead' . Bloomberg DynamicLocal PV OpenEBS. Elastic , . , OpenEBS Director (https://account.mayadata.io/signup). — , .

StorageOS

:
URL: storageos.com

هذا حل تجاري مجاني عند استخدام ما يصل إلى 110 جيجابايت من المساحة. يمكن الحصول على ترخيص مطور مجاني عن طريق التسجيل من خلال واجهة مستخدم المنتج ؛ يوفر مساحة تصل إلى 500 جيجابايت. في Rancher ، تم إدراجه كشريك ، لذلك كان التثبيت باستخدام Helm سهلًا وخاليًا من الهموم.

يتم تقديم لوحة تحكم أساسية للمستخدم. كان اختبار هذا المنتج محدودًا لأنه تجاري ولا يناسبنا من حيث القيمة. ولكن ما زلت أريد أن أرى ما هي المشاريع التجارية القادرة.

يستخدم الاختبار فئة التخزين الحالية المسماة "سريع" (قالب 0.2.19 ، 1 ماستر + 0 نسخة متماثلة؟). كانت النتائج مذهلة. لقد تجاوزوا بشكل كبير الحلول السابقة.

قراءة / كتابة عشوائية ، IOPS: 117k / 90.4k ؛
قراءة / كتابة عرض النطاق الترددي: 2124 ميجا بايت / ثانية / 457 ميجا بايت / ثانية ؛
متوسط زمن الوصول للقراءة / الكتابة (usec): 63.44 / 86.52 ؛
القراءة / الكتابة التسلسلية: 1907 ميجا بايت / ثانية / 448 ميجا بايت / ثانية ؛
قراءة / كتابة عشوائية مختلطة ، IOPS: 81.9k / 27.3k.

بيريوس (على أساس لينستور)

الترخيص: GPLv3

الدعم التجاري: لينبيت
URL: github.com/piraeusdatastore/piraeus
بناءً على: github.com/LINBIT/linstor-server
Stars on GitHub: أقل من 100 (لا تبخل ، ضع علامة النجمة على المشروع!)

استقر Vito Botta المذكور بالفعل في النهاية على Linstor ، والذي كان سببًا إضافيًا لتجربة هذا الحل. للوهلة الأولى ، يبدو المشروع غريبًا نوعًا ما. لا يوجد تقريبًا أي نجوم على GitHub ، وهو اسم غير معتاد ولا يوجد حتى في CNCF Landscape. ولكن عند الفحص الدقيق ، كل شيء ليس مخيفًا جدًا ، لأنه:

يتم استخدام DRBD كآلية تكرار أساسية (في الواقع ، تم تطويره من قبل نفس الأشخاص). في نفس الوقت ، كان DRBD 8.x جزءًا من نواة Linux الرسمية لأكثر من 10 سنوات. ونحن نتحدث عن التكنولوجيا التي تم شحذها لأكثر من 20 عامًا.
يتم التحكم في الوسائط بواسطة LINSTOR ، وهي أيضًا تقنية ناضجة من نفس الشركة. ظهر الإصدار الأول من خادم Linstor على GitHub في فبراير 2018. وهو متوافق مع تقنيات / أنظمة مختلفة مثل Proxmox و OpenNebula و OpenStack.
على ما يبدو ، تعمل Linbit بنشاط على تطوير المشروع ، حيث تقدم باستمرار ميزات وتحسينات جديدة فيه. لا يزال الإصدار العاشر من DRBD يتمتع بحالة ألفا ، ولكنه يضم بالفعل بعض الميزات الفريدة ، مثل تشفير المحو (مشابهًا للوظيفة من RAID5 / 6 - تقريبًا.) .
تتخذ الشركة تدابير معينة لتصبح واحدة من مشاريع CNCF.

حسنًا ، يبدو المشروع مقنعًا بما فيه الكفاية لتكليفه ببياناته الثمينة. ولكن هل يستطيع إعادة البدائل؟ دعنا نلقي نظرة.

التركيب

يتحدث Vito عن تثبيت Linstor هنا . ومع ذلك ، في التعليقات ، يوصي أحد مطوري Linstor بمشروع جديد يسمى Piraeus. كما أفهمها ، أصبحت بيريوس مشروع Linbit Open Source ، الذي يجمع بين كل ما يتعلق بـ K8s. يعمل الفريق على عامل التشغيل المناسب ، ولكن في الوقت الحالي ، يمكن تثبيت Piraeus باستخدام ملف YAML هذا:

kubectl apply -f https://raw.githubusercontent.com/bratao/piraeus/master/deploy/all.yaml

انتباه! تلتقط التكوينات من مستودعي الشخصي. تحقق من المستودع الرسمي! لقد قمت بتحديث نسخة الصور لحل الخطأ الذي يحدث عند الاستخدام في Ubuntu.

مستودع بيريوس الرسمي متاح هنا .

يمكنك أيضًا استخدام مستودع kvaps (يبدو أكثر ديناميكية من مستودع piraeus الرسمي): https://github.com/kvaps/kube-linstor (اغتنم هذه الفرصة للتعبير عن التحية إلى Andreykvaps- تقريبا. perev.) .

تعمل جميع العقد بعد التثبيت

الادارة

يتم تنفيذ الإدارة باستخدام سطر الأوامر. من الممكن الوصول إليها من قذيفة الأوامر للعقدة تحكم بيرايوس.

تعمل عقدة وحدة التحكم على خادم linstor. إنها طبقة تجريد فوق drbd ، قادرة على إدارة أسطول العقد بالكامل. تعرض لقطة الشاشة أدناه بعض الأوامر المفيدة للمهام الأكثر شيوعًا ، على سبيل المثال:

linstor node list - عرض قائمة العقد المتصلة وحالتها ؛
linstor volume list - عرض قائمة المجلدات التي تم إنشاؤها وموقعها ؛
linstor node info - إظهار قدرات كل عقدة.

أوامر Linstor تتوفر

قائمة كاملة بالأوامر في الوثائق الرسمية: دليل المستخدم LINSTOR .

في حالة حالات مثل انقسام الدماغ ، يمكن الوصول إلى drbd مباشرة من خلال العقد.

التعافي من الكوارث

لقد بذلت قصارى جهدي لإسقاط مجموعتي ، بما في ذلك إعادة التعيين على العقد. لكن لينستور كان عنيدًا بشكل مدهش.

يتعرف Drbd تمامًا على مشكلة تسمى انقسام الدماغ. في وضعي ، سقطت العقدة الثانوية من التكرار.

Split brain — , - , - Primary, «» . , . , , .

Split brain DRBD , , Heartbeat.

يمكن الاطلاع على التفاصيل في الوثائق الرسمية لـ drbd .

فشلت العقدة الثانوية في النسخ المتماثل.

في حالتي ، لحل المشكلة ، أسقطت البيانات الثانوية وبدأت في المزامنة مع العقدة الأساسية. نظرًا لأنني أفضل الواجهات الرسومية ، فقد استخدمت أداة drbdtop لهذا الغرض. بمساعدته ، يمكنك مراقبة الحالة بشكل مرئي وتنفيذ الأوامر داخل العقد.

كنت بحاجة للذهاب إلى وحدة التحكم على piraues العقدة المشكلة (كان worker2-gpu):

انتقل إلى العقدة

هناك قمت بتثبيت drdbtop. قم بتنزيل هذه الأداة هنا:

wget https://github.com/LINBIT/drbdtop/releases/download/v0.2.2/drbdtop-linux-amd64
chmod +x drbdtop-linux-amd64
./drbdtop-linux-amd64

تشغيل أداة drbdtop

ألق نظرة على اللوحة السفلية. هناك أوامر عليها يمكن استخدامها لإصلاح الدماغ المقسم:

بعد ذلك ، يتم توصيل العقد ومزامنتها تلقائيًا.

كيف تزيد السرعة؟

بشكل افتراضي ، يُظهر Piraeus / Linstor / drbd أداءً ممتازًا (يمكنك مشاهدة ذلك أدناه). الإعدادات الافتراضية معقولة وآمنة. ومع ذلك ، كانت سرعة الكتابة ضعيفة إلى حد ما. نظرًا لأن الخوادم الموجودة في حالتي مبعثرة عبر مراكز البيانات المختلفة (على الرغم من أنها قريبة نسبيًا) ، فقد قررت محاولة ضبط أدائها.

نقطة البداية للتحسين هي تحديد بروتوكول النسخ المتماثل. بشكل افتراضي ، يتم استخدام البروتوكول C ، الذي ينتظر تأكيد الكتابة على العقدة الثانوية البعيدة. فيما يلي وصف للبروتوكولات المحتملة:

Protocol A — . , , TCP- . , TCP . .
Protocol B — . , , .
Protocol C ( ) — . .

لهذا السبب ، في Linstor ، أستخدم أيضًا البروتوكول غير المتزامن (وهو يدعم النسخ المتزامن / شبه المتزامن / غير المتزامن). يمكنك تمكينه باستخدام الأمر التالي:

linstor c drbd-options --protocol A --after-sb-0pri=discard-zero-changes  --after-sb-1pri=discard-secondary  --after-sb-2pri=disconnect --max-buffers 131072 --sndbuf-size 1085760 --rcvbuf-size 1085760 --c-max-rate 4194304 --c-fill-target 1048576

ستكون نتيجة تنفيذه تفعيل البروتوكول غير المتزامن وزيادة في المخزن المؤقت حتى 1 ميغابايت. إنه آمن نسبيًا. أو يمكنك استخدام الأمر التالي (يتجاهل تدفق القرص ويزيد المخزن المؤقت بشكل ملحوظ):

linstor c drbd-options --protocol A --after-sb-0pri=discard-zero-changes  --after-sb-1pri=discard-secondary  --after-sb-2pri=disconnect --max-buffers 131072 --sndbuf-size 10485760 --rcvbuf-size 10485760 --disk-barrier no --disk-flushes no --c-max-rate 4194304 --c-fill-target 1048576

لاحظ أنه إذا فشلت العقدة الأساسية ، فقد لا يصل جزء صغير من البيانات إلى النسخ المتماثلة.

أثناء التسجيل النشط ، تلقت العقدة مؤقتًا حالة قديمة باستخدام بروتوكول ASYNC

اختبارات

تم تنفيذ جميع المعايير باستخدام الوظيفة التالية:

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
 name: dbench
spec:
 storageClassName:  STORAGE_CLASS
 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

التأخير بين الآلات على النحو التالي: ttl=61 time=0.211 ms. كانت الصبيب المقاس بينهما 943 ميغابت في الثانية. تعمل جميع العقد على Ubuntu 18.04. النتائج ( الجدول على sheetu.com ) كما هو واضح من الجدول ، أظهر بيريوس و StorageOS أفضل النتائج. كان القائد بيرايوس مع نسختين متماثلتين وبروتوكول غير متزامن.

الموجودات

لقد أجريت مقارنة بسيطة وربما ليست صحيحة جدًا لبعض حلول التخزين في Kubernetes.

الأهم من ذلك أنني أحببت Longhorn بسبب واجهة المستخدم الرسومية اللطيفة والتكامل مع Rancher. ومع ذلك ، فإن النتائج ليست ملهمة. من الواضح أن المطورين يركزون في المقام الأول على الأمان والصحة ، تاركين السرعة لوقت لاحق.

لبعض الوقت الآن أستخدم Linstor / Piraeus في بيئات الإنتاج لبعض المشاريع. حتى الآن ، كان كل شيء على ما يرام: تم إنشاء الأقراص وحذفها ، وأعيد تشغيل العقد بدون توقف ...

في رأيي ، Piraeus جاهز تمامًا للاستخدام في الإنتاج ، ولكن يحتاج إلى تحسين. لقد كتبت عن بعض الأخطاء في قناة المشروع في Slack ، لكن ردا على ذلك نصحوني فقط بتدريس Kubernetes (وهذا صحيح ، لأنني ما زلت لا أفهم ذلك جيدًا). بعد مراسلات صغيرة ، تمكنت من إقناع المؤلفين بوجود خلل في نص الحرف الأول. بالأمس ، بعد تحديث النواة وإعادة التشغيل ، رفضت العقدة التمهيد. اتضح أن تجميع النص الذي يدمج وحدة drbd في النواة فشل . التراجع إلى إصدار kernel السابق يحل المشكلة.

هذا ، بشكل عام ، كل شيء. بالنظر إلى أنها نفذت على رأس drbd ، اتضح أنه حل موثوق للغاية مع أداء ممتاز. في حالة حدوث أي مشاكل ، يمكنك الاتصال مباشرة بإدارة drbd وإصلاحه. على الإنترنت هناك العديد من الأسئلة والأمثلة حول هذا الموضوع.

إذا قمت بشيء خاطئ ، إذا كان من الممكن تحسين شيء ما أو كنت بحاجة إلى المساعدة ، فاتصل بي على Twitter أو على GitHub .

حالة وأداء حلول التخزين المستمرة من Kubernetes