نواجه بانتظام قاعدة بيانات Apache Cassandra والحاجة إلى تشغيلها في إطار البنية التحتية القائمة على Kubernetes. في هذه المقالة ، سوف نشارك رؤيتنا للخطوات والمعايير والحلول اللازمة (بما في ذلك نظرة عامة على المشغلين) لترحيل كاساندرا إلى K8s.
"من يستطيع السيطرة على امرأة سيتعامل مع الدولة"
من هو كاساندرا؟ إنه نظام تخزين موزع مصمم لإدارة كميات كبيرة من البيانات مع توفير إتاحة عالية دون نقطة فشل واحدة. بالكاد يحتاج المشروع إلى مقدمة طويلة ، لذلك سأقدم فقط الميزات الرئيسية لكاساندرا ، والتي ستكون ذات صلة في سياق مقالة محددة:
- كاساندرا مكتوب بلغة جافا.
- تتضمن طوبولوجيا كاساندرا عدة مستويات:
- عقدة - مثيل واحد نشر كاساندرا.
- Rack - مجموعة من مثيلات Cassandra ، متحدة بأي سمة ، موجودة في مركز بيانات واحد ؛
- مركز البيانات - إجمالي جميع مجموعات حالات كاساندرا الموجودة في مركز بيانات واحد ؛
- الكتلة - مجموعة من جميع مراكز البيانات.
- يستخدم كاساندرا عنوان IP لتحديد المضيف.
- لسرعة عمليات القراءة والكتابة ، تقوم كاساندرا بتخزين جزء من البيانات في ذاكرة الوصول العشوائي.
الآن للانتقال الفعلي المحتمل إلى Kubernetes.
تحقق من قائمة للهجرة
عند الحديث عن هجرة Cassandra إلى Kubernetes ، نأمل أن يصبح الأمر أكثر ملاءمة لإدارة هذه الخطوة. ما سوف تكون مطلوبة لهذا ، ما سوف يساعد في هذا؟
1. تخزين البيانات
كما هو محدد بالفعل ، جزء من البيانات كاساندا يخزن في ذاكرة الوصول العشوائي - في
Memtable . ولكن هناك جزء آخر من البيانات التي يتم حفظها على القرص - في شكل
SSTable . يضاف إلى هذه البيانات
سجل سجل الكيان - سجلات جميع المعاملات التي يتم حفظها أيضا على القرص.
كاساندرا كتابة خطة المعاملاتفي Kubernetes ، يمكننا استخدام PersistentVolume لتخزين البيانات. بفضل الآليات المتطورة ، يصبح العمل مع البيانات في Kubernetes أسهل كل عام.
لكل جراب مع كاساندرا سنخصص لدينا PersistentVolumeمن المهم أن نلاحظ أن كاساندرا نفسها تنطوي على تكرار البيانات ، وتقدم آليات مدمجة لذلك. لذلك ، إذا كنت تقوم بإنشاء مجموعة كاساندرا من عدد كبير من العقد ، فلا داعي لاستخدام أنظمة موزعة مثل Ceph أو GlusterFS لتخزين البيانات. في هذه الحالة ، سيكون من المنطقي تخزين البيانات على القرص المضيف باستخدام
الأقراص الثابتة المحلية أو
hostPath المتصاعد.
سؤال آخر هو ما إذا كنت تريد إنشاء بيئة تطوير منفصلة لكل فرع من فروع الميزات. في هذه الحالة ، تتمثل الطريقة الصحيحة في رفع عقدة واحدة من كاساندرا ، وتخزين البيانات في وحدة التخزين الموزعة ، أي Ceph و GlusterFS المذكورة ستكون خيارك. عندها سيتأكد المطور من أنه لن يفقد بيانات الاختبار حتى في حالة فقد إحدى عقد مجموعة Kuberntes.
2. الرصد
يعد Prometheus أحد الخيارات غير البديلة للمراقبة في Kubernetes
(تحدثنا عن ذلك بالتفصيل في التقرير المقابل ) . كيف حال كاساندرا مع المصدرين المتريين لبروميثيوس؟ وما هو الأهم من ذلك بطريقة أو بأخرى ، مع لوحات المعلومات المناسبة لهم لغرافانا؟
مثال على ظهور الرسوم البيانية في جرافانا لكاساندرالا يوجد سوى مصدرين اثنين:
jmx_exporter و
cassandra_exporter .
اخترنا الأول لأنفسنا ، لأن:
- JMX Exporter ينمو ويتطور ، في حين أن Cassandra Exporter لم تتمكن من الحصول على الدعم المناسب من المجتمع. لا يزال Cassandra Exporter لا يدعم معظم إصدارات Cassandra.
- يمكنك تشغيله كـ javaagent عن طريق إضافة علامة
-javaagent:<plugin-dir-name>/cassandra-exporter.jar=--listen=:9180 . - بالنسبة له يوجد dashboad الكافي الذي لا يتوافق مع Cassandra Exporter.
3. اختيار Kubernetes البدائية
وفقًا للهيكل أعلاه من مجموعة كاساندرا ، سنحاول ترجمة كل ما هو موصوف هناك إلى مصطلحات Kubernetes:
- كاساندرا العقدة → قرنة
- كاساندرا الرف → StatefulSet
- كاساندرا مركز البيانات → تجمع من StatefulSets
- كاساندرا كلاستر → ؟؟؟
اتضح أن بعض الكيانات الإضافية مفقود لإدارة مجموعة كاساندرا بأكملها في وقت واحد. ولكن إذا لم يكن هناك شيء ما ، فيمكننا إنشاؤه! Kubernetes لديه محرك
مخصص لتعريف الموارد يسمى
Custom Resource Definitions .
الإعلان عن موارد إضافية للسجلات والتنبيهاتلكن الموارد المخصصة وحدها لا تعني أي شيء: أنت بحاجة إلى
وحدة تحكم لذلك. قد تضطر إلى اللجوء إلى مساعدة أحد
مشغلي Kubernetes ...
4. تحديد القرون
النقطة أعلاه ، اتفقنا على أن عقدة كاساندرا واحدة تساوي جراب واحد في Kubernetes. لكن عناوين IP الخاصة بـ pod ستكون مختلفة في كل مرة. ويحدث تحديد العقدة في كاساندرا على وجه التحديد بناءً على عنوان IP ... اتضح أنه بعد كل عملية إزالة للعنصر ، ستضيف مجموعة كاساندرا عقدة جديدة.
هناك مخرج ، ولا حتى واحد:
- يمكننا الاحتفاظ بالسجلات بواسطة معرفات المضيف (UUIDs التي تحدد بشكل فريد مثيلات كاساندرا) أو عن طريق عناوين IP وحفظ كل هذا في بعض الهياكل / الجداول. الأسلوب له عيبان رئيسيان:
- خطر حدوث حالة سباق عند سقوط عقدتين في وقت واحد. بعد الترقية ، ستذهب عقد كاساندرا في وقت واحد لطلب عنوان IP لأنفسهم من الجدول والتنافس على المورد نفسه.
- إذا فقدت عقدة كاساندرا بياناتها ، فلن نتمكن من تحديدها بعد الآن.
- الحل الثاني يبدو وكأنه اختراق صغير ، ولكن مع ذلك: يمكننا إنشاء خدمة مع ClusterIP لكل عقدة كاساندرا. مشاكل مع هذا التطبيق:
- إذا كان هناك الكثير من العقد في مجموعة كاساندرا ، فسيتعين علينا إنشاء الكثير من الخدمات.
- يتم تطبيق ميزة ClusterIP من خلال iptables. يمكن أن يكون هذا مشكلة إذا كان لدى الكتلة Cassandra (1000 ... أو حتى 100؟) العقد. على الرغم من أن التوازن على أساس IPVS يمكن أن يحل هذه المشكلة.
- الحل الثالث هو استخدام شبكة من العقد لعقد Cassandra بدلاً من شبكة pod مخصصة من خلال تمكين
hostNetwork: true الإعداد hostNetwork: true . هذه الطريقة تفرض قيودًا معينة:
- لتحل محل العقد. من الضروري أن يكون للمضيف الجديد عنوان IP نفسه كما هو الحال مع العنوان السابق (في السحب مثل AWS ، GCP ، يكون هذا مستحيلًا تقريبًا) ؛
- باستخدام شبكة عقد الكتلة ، نبدأ في التنافس على موارد الشبكة. لذلك ، سيكون وضع عقدة كتلة واحدة مع أكثر من جراب مع Cassandra مشكلة.
5. النسخ الاحتياطي
نريد الاحتفاظ بالإصدار الكامل من البيانات لعقدة واحدة من كاساندرا وفقًا لجدول زمني. توفر Kubernetes فرصة مريحة باستخدام
CronJob ، ولكن هنا يقوم Cassandra بإدراج العصي في العجلات.
اسمحوا لي أن أذكركم بأن هذا الجزء من البيانات يخزنها كاساندرا في الذاكرة. لعمل نسخة احتياطية كاملة ، تحتاج إلى نقل البيانات من الذاكرة (
Memtables ) إلى القرص (
SSTables ). عند هذه النقطة ، تتوقف عقدة كاساندرا عن قبول الاتصالات ، متوقفة تمامًا عن الكتلة.
بعد ذلك ، تتم إزالة نسخة احتياطية (
لقطة ) ويتم
حفظ المخطط (
keyspace ). ثم اتضح أن مجرد نسخة احتياطية لا تعطينا أي شيء: تحتاج إلى حفظ معرفات البيانات التي كانت عقدة كاساندرا مسؤولة عنها - هذه رموز مميزة.
توزيع الرمز المميز لتحديد البيانات المسؤولة عن عقد كاساندرايمكن العثور على مثال نصي لإزالة كاساندرا من Google في Kubernetes على
هذا الرابط . النقطة الوحيدة التي لا يأخذها البرنامج النصي في الاعتبار هي إلقاء البيانات على العقدة قبل إزالة اللقطة. وهذا هو ، يتم إجراء النسخ الاحتياطي ليس للحالة الحالية ، ولكن بالنسبة للحالة في وقت سابق قليلا. لكن هذا لا يساعد في إخراج العقدة من العمل ، الأمر الذي يبدو منطقياً للغاية.
set -eu if [[ -z "$1" ]]; then info "Please provide a keyspace" exit 1 fi KEYSPACE="$1" result=$(nodetool snapshot "${KEYSPACE}") if [[ $? -ne 0 ]]; then echo "Error while making snapshot" exit 1 fi timestamp=$(echo "$result" | awk '/Snapshot directory: / { print $3 }') mkdir -p /tmp/backup for path in $(find "/var/lib/cassandra/data/${KEYSPACE}" -name $timestamp); do table=$(echo "${path}" | awk -F "[/-]" '{print $7}') mkdir /tmp/backup/$table mv $path /tmp/backup/$table done tar -zcf /tmp/backup.tar.gz -C /tmp/backup . nodetool clearsnapshot "${KEYSPACE}"
مثال باش النصي لإزالة النسخ الاحتياطي من عقدة كاساندرا واحدةحلول جاهزة لكاساندرا في Kubernetes
ما الذي يستخدمونه حاليًا لنشر Cassandra في Kubernetes ، وأي منها يناسب أكثر المتطلبات المحددة؟
1. StatefulSet أو حلول مخطط هيلم
يعد استخدام StatefulSets الأساسي لبدء مجموعة Cassandra خيارًا جيدًا. باستخدام قوالب Helm chart و Go ، يمكنك تزويد المستخدم بواجهة مرنة لنشر Cassandra.
عادة ما يكون هذا جيدًا ... حتى يحدث شيء غير متوقع - على سبيل المثال ، تنخفض العقدة. أدوات Kubernetes القياسية ببساطة لا يمكن أن تأخذ في الاعتبار جميع الميزات المذكورة أعلاه. بالإضافة إلى ذلك ، هذا النهج محدود للغاية في كيفية توسيعه للاستخدام أكثر تعقيدًا: استبدال العقدة ، النسخ الاحتياطي ، الاستعادة ، المراقبة ، إلخ.
ممثلين:
كلا المخططين جيدان على حد سواء ، لكنهما عرضة للمشاكل الموضحة أعلاه.
2. حلول قائمة على مشغل Kubernetes
تعد هذه الخيارات أكثر إثارة للاهتمام لأنها توفر إمكانات واسعة لإدارة الكتلة. لتصميم بيان Cassandra ، مثل أي قاعدة بيانات أخرى ، يبدو النموذج الجيد مثل Sidecar <-> Controller <-> CRD:
مخطط إدارة العقدة في بيان Cassandra المصمم بشكل صحيحالنظر في العوامل الحالية.
1. كاساندرا المشغل بواسطة instaclustr
- جيثب
- الاستعداد: ألفا
- الترخيص: أباتشي 2.0
- نفذت في: جافا
هذا بالفعل مشروع واعد جدًا وسريع التطور من شركة تقدم عمليات النشر التي تديرها كاساندرا. كما هو موضح أعلاه ، يستخدم حاوية جانبية تقبل الأوامر عبر HTTP. إنه مكتوب بلغة جافا ، لذلك في بعض الأحيان يفتقر إلى وظائف مكتبة العميل المتقدمة. أيضًا ، لا يدعم المشغل رفوف مختلفة لمركز بيانات واحد.
لكن لدى المشغل مزايا مثل دعم المراقبة وإدارة الكتلة عالية المستوى باستخدام CRD وحتى الوثائق المتعلقة بإزالة النسخ الاحتياطية.
2. المستكشف بواسطة جيتستاك
- جيثب
- الاستعداد: ألفا
- الترخيص: أباتشي 2.0
- نفذت في: Golang
بيان لنشر DB-as-a-Service. يدعم حاليا اثنين من قواعد البيانات: Elasticsearch وكاساندرا. لديها حلول مثيرة للاهتمام مثل التحكم في الوصول إلى قاعدة البيانات عبر RBAC (لهذا ، يتم رفع الملاح المستقل الخاص بها). مشروع مثير للاهتمام ، والذي يستحق نظرة فاحصة ، ولكن تم الالتزام الأخير منذ عام ونصف العام ، مما يقلل بوضوح من إمكاناته.
3. كاساندرا المشغل من vgkowski
- جيثب
- الاستعداد: ألفا
- الترخيص: أباتشي 2.0
- نفذت في: Golang
لم يعتبروا الأمر "جديًا" ، لأن الالتزام الأخير بالمستودع كان منذ أكثر من عام. تم التخلي عن تطوير المشغل: أحدث إصدار من Kubernetes ، أعلن أنه مدعوم ، هو 1.9.
4. كاساندرا المشغل من الرخ
- جيثب
- الاستعداد: ألفا
- الترخيص: أباتشي 2.0
- نفذت في: Golang
مشغل لا يتم تطويره بالسرعة التي نودها. لديه بنية CRD مدروسة لإدارة الكتلة ، يحل مشكلة تحديد العقد باستخدام الخدمة مع ClusterIP (نفس "الاختراق") ... ولكن في الوقت الحالي ، كل هذا. لا توجد مراقبة ونسخ احتياطية خارج الصندوق الآن (بالمناسبة ،
بدأنا في مراقبة
أنفسنا ). نقطة مهمة هي أنه باستخدام هذا المشغل ، يمكنك أيضًا نشر ScyllaDB.
ملحوظة: استخدمنا هذا المشغل مع تعديلات طفيفة في أحد مشاريعنا. لم تكن هناك مشاكل في عمل المشغل أثناء العملية بأكملها (حوالي 4 أشهر من التشغيل).5. كاسكوب البرتقالي
- جيثب
- الاستعداد: ألفا
- الترخيص: أباتشي 2.0
- نفذت في: Golang
أصغر مشغل في القائمة: تم الالتزام الأول في 23 مايو 2019. بالفعل ، لديه في ترسانته عدد كبير من الميزات من قائمتنا ، ويمكن الاطلاع على مزيد من التفاصيل عنها في مستودع المشروع. يعتمد المشغل على المشغل sdk الشهير. يدعم مراقبة خارج الصندوق. الفرق الرئيسي بين المشغلين الآخرين هو استخدام
المكون الإضافي CassKop ، الذي تم تنفيذه في بيثون ويستخدم للتواصل بين عقد كاساندرا.
النتائج
يتحدث عدد من الأساليب والخيارات الممكنة لنقل Cassandra إلى Kubernetes عن نفسه: الموضوع في الطلب.
في هذه المرحلة ، يمكنك تجربة أحد الإجراءات المذكورة أعلاه على مسؤوليتك الخاصة والمخاطر: لا يضمن أي من المطورين عمل حلولهم بنسبة 100٪ في بيئة الإنتاج. ولكن الآن ، تبدو العديد من المنتجات واعدة لمحاولة استخدامها في منصات التطوير.
أعتقد في المستقبل أن هذه المرأة على السفينة سوف تضطر إلى الذهاب!
PS
اقرأ أيضًا في مدونتنا: