تستمر هذه المقالة لدينا
مواد الهجرة RabbitMQ
الأخيرة ومكرسة ل MongoDB. نظرًا لأننا نخدم العديد من مجموعات Kubernetes و MongoDB ، فقد وصلنا إلى الحاجة الطبيعية لترحيل البيانات من تثبيت إلى آخر والقيام بذلك دون توقف. السيناريوهات الرئيسية هي نفسها: نقل MongoDB من خادم افتراضي / حديد إلى Kubernetes أو نقل MongoDB داخل كتلة Kubernetes (من مساحة اسم واحدة إلى أخرى).
تم إعداد الوصفة الخاصة بنا للحالات التي تعمل فيها مجموعة MongoDB القديمة (على سبيل المثال ، من 3 عقد وموجودة إما بالفعل في K8s أو على خوادم قديمة) التي يعمل بها تطبيق مستضاف في Kubernetes:
كيف سننقل مثل هذه الكتلة إلى إنتاج جديد في Kubernetes؟
نظرية
تشبه خوارزمية الترحيل العامة تلك الموضحة في الموقف مع RabbitMQ.
من المهم الإشارة إلى أن القدرة على الحركة تتطلب وجود خوادم لها MongoDB و Kubernetes على نفس الشبكة. ستتواصل عقد نظام مجموعة MongoDB مع بعضها البعض عبر عنوان IP الخاص بالخوادم القديمة (حيث توجد عمليات تثبيت MongoDB القديمة) وأسماء نظام أسماء النطاقات (DNS) الخاصة بالقرون من برنامج MongoDB في K8s. لذلك ، على خوادم الحديد (مع التركيبات القديمة) ، سيكون من الضروري إعادة توجيه المسارات إلى أجهزة الكمبيوتر ، ثم تكوينها لاستخدام خادم DNS الذي يعمل في Kubernetes (أو تسجيل الأسماء اللازمة في
/etc/hosts ، على الرغم من أنه في الحالة العامة ، من الأفضل تجنب هذا الاحتمال ).
والخطوة التالية هي رفع كتلة MongoDB في قرون Kubernetes. في حالتنا ، تتكون مجموعة قاعدة البيانات من 3 عقد ، وتقع كل عقدة في pod'8 K8s منفصلة - ومع ذلك ، قد يكون عددها مختلفًا. في ConfigMap ، يجب عليك تحديد عنوان MongoDB الرئيسي من التثبيت القديم: ثم ستبدأ مزامنة العقد MongoDB الموجودة في الحافظات في K8s على الفور.
بعد ارتفاع جميع القرون ، يتم تشكيل كتلة MongoDB ذات 6 عقدة:
يرجى ملاحظة أن القرون سوف ترتفع لفترة طويلة ، حيث يبدأ كل قرنة بدوره ، وفي وقت إطلاقها ، يقوم بمزامنة البيانات من المعالج.
بعد ذلك ، يمكنك تبديل التطبيق لاستخدام خوادم MongoDB الجديدة:
ويبقى فقط لإزالة العقد القديمة من كتلة MongoDB ، وبعد ذلك يمكن اعتبار الخطوة مكتملة:
غالبًا ما نستخدم هذا المخطط في الإنتاج ، ولتيسير استخدامه ، قمنا بتطبيقه داخل وحدة
المشغل الإضافي (
أعلنا هذه الأداة
مؤخرًا ) ، مما يسمح لنا بتوزيع تكوينات MongoDB النموذجية عبر العديد من المجموعات. نعتزم نشر وحداتنا في المستقبل القريب ، لكن في الوقت الحالي نقدم إرشادات منفصلة يمكنك من خلالها تجربة الحل المقترح في العمل وبدون استخدام عامل التشغيل الإضافي.
نحاول في الممارسة
متطلبات
تفاصيل:
- مجموعة Kubernetes (minikube مناسب أيضًا) ؛
- مجموعة MongoDB (يمكن نشرها على المعدن العاري ، وجعلها كتلة منتظمة في Kubernetes من مخطط هيلم الرسمي).
في المثال الموضح أدناه ، سيتم تسمية الكتلة القديمة مع MongoDB باسم
mongo-old وتثبيتها في نفس مجموعة Kubernetes ، حيث سنقوم في المستقبل بتثبيت المجموعة الجديدة (
mongo-new ).
تحضير الكتلة القديمة
1. للحصول على مثال يوضح المخطط الموضح في العمل ، سنقوم بإنشاء مجموعة MongoDB "القديمة" (أي ، عرضة للهجرة) مباشرة في Kubernetes (في الواقع ، يمكن أن تكون موجودة أيضًا على خوادم منفصلة خارج K8s). للقيام بذلك ، قم بتنزيل مخطط Helm:
helm fetch --untar stable/mongodb-replicaset
... وقم بتحريره قليلاً عن طريق إعداد التفويض:
auth: enabled: true adminUser: mongo adminPassword: pa33w0rd # metricsUser: metrics # metricsPassword: password # key: keycontent # existingKeySecret: # existingAdminSecret: # exisitingMetricsSecret:
أيضا في
values.yaml يمكنك تكوين الشهادات وأكثر من ذلك بكثير.
2. تعيين المخطط:
helm install . --name mongo-old --namespace mongo-old
بعد ذلك ، سيتم إطلاق التثبيت "القديم" لاختبار MongoDB:
kubectl --namespace=mongo-old get pods
دعنا نذهب إلى قرنة مع سيدها وإنشاء قاعدة اختبار:
kubectl --namespace=mongo-old exec -ti mongo-old-mongodb-replicaset-0 mongo use admin db.auth('mongo','password') use music db.artists.insert({ artistname: "The Tea Party" }) show dbs
عند إدخال قرون مختلفة ، اكتشفت أن المعلم هو
mongo-old-mongodb-replicaset-0 . ومع ذلك ، للحصول على حل أكثر ملاءمة لهذه المشكلة ، بعد تثبيت مخطط Helm ، يتم عرض أمر حول كيفية تحديد
MASTER_POD . في حالتي (
mongo-old من 3 عقد) يبدو الأمر كما يلي:
for ((i = 0; i < 3; ++i)); do kubectl exec --namespace mongo-old mongo-old-mongodb-replicaset-$i -- sh -c 'mongo --eval="printjson(rs.isMaster())"'; done
على هذا ، فإن إعداد تثبيت MongoDB القديم ، الذي سيتم نقل بياناته ، جاهز.
ترحيل مجموعة MongoDB
سننشر الآن تثبيت MongoDB الجديد ، والذي سيكون موجودًا في Kubernetes ويستخدمه التطبيق في الإنتاج.
ملحوظة : يرجى ملاحظة أنه يجب استخدام نفس الإصدار من MongoDB كما كان من قبل. خلاف ذلك ، هناك خطر من مشاكل التوافق.قياسًا على القسم السابق (حيث قمنا بمحاكاة تثبيت MongoDB "القديم") ، نأخذ مخطط Helm المذكور مسبقًا (باستخدام الأمر
helm fetch ) وتكوين التخويل ، وكذلك المعلمات الأخرى ، إذا تم استخدامها. بالإضافة إلى ذلك ، سنقوم بإصلاح ملف
init/on-start.sh بإضافة عنوان المعالج الذي تم الحصول عليه في الخطوة السابقة إليه مؤقتًا (أو المعروف لك من تثبيت MongoDB على خوادم منفصلة):
peers='mongo-old-mongodb-replicaset-0.mongo-old-mongodb-replicaset.mongo-old.svc.cluster.local:27017'
نحن على استعداد لإنشاء تثبيت MongoDB جديد:
helm install . --name mongo-new --namespace mongo-new
ننتظر حتى تبدأ جميع البرامج (إذا كان هناك الكثير من البيانات ، فإن إطلاقها قد يستغرق ساعات):
الآن نجعل
exec في جراب جديد وننظر إلى قائمة القواعد:
kubectl --namespace=mongo-new exec -ti mongo-new-mongodb-replicaset-0 mongo
يتم دمج مجموعتين MongoDB في واحدة ، تتكون من 6 العقد.
في الوقت الحالي ، يمكنك بالفعل تبديل التطبيق إلى كتلة جديدة ، ولكن لا تزال هناك بضع خطوات لإكمال الترحيل.
من
init/on-start.sh في التثبيت الجديد ، أزلنا السطر الذي
init/on-start.sh :
peers='mongo-old-mongodb-replicaset-0.mongo-old-mongodb-replicaset.mongo-old.svc.cluster.local:27017'
الآن دعنا نذهب إلى المعلم القديم للمجموعة و "إسقاطها" - ثم سيتم تعيين سيد جديد في الكتلة. نذهب إلى جراب مع mongoDB الرئيسي:
kubectl --namespace=mongo-old exec -ti mongo-old-mongodb-replicaset-0 mongo use admin db.auth('mongo','password')
بعد ذلك ، نقوم بتغيير أولويات العقد وتغيير المعالج:
cfg = rs.conf() cfg.members[5].priority = 2 rs.reconfig(cfg) rs.stepDown(120)
توقفت العقدة الحالية عن أن تكون سيدة - ستحدث انتخابات جديدة. عندما قمنا بتغيير الأولويات ، ستصبح العقدة التي نحتاج إليها هي الرئيسية.
ملحوظة : افتراضيًا ، يكون لكل عقد MongoDB أولوية 1. فوق نرفع إلى 2 أولوية العقدة التي نحتاجها. وبالتالي ، فإن عضوًا في مجموعة جديدة سيصبح بالتأكيد سيدًا مشتركًا. يمكنك قراءة المزيد حول كيفية عمل هذه الآليات في MongoDB في الوثائق .تعطيل تثبيت MongoDB القديم ، ثم انتقل إلى المعالج الجديد وحذف العقد القديمة:
rs.remove("mongo-old-mongodb-replicaset-0.mongo-old-mongodb-replicaset.mongo-old.svc.cluster.local:27017") rs.remove("mongo-old-mongodb-replicaset-1.mongo-old-mongodb-replicaset.mongo-old.svc.cluster.local:27017") rs.remove("mongo-old-mongodb-replicaset-2.mongo-old-mongodb-replicaset.mongo-old.svc.cluster.local:27017")
بعد ذلك ، يمكن اعتبار الترحيل مكتملاً: لقد تحولنا بنجاح من نظام MongoDB القديم إلى المجموعة الجديدة!
النتائج
المخطط الموضح مناسب لجميع الحالات تقريبًا عندما تحتاج إلى نقل MongoDB أو الانتقال فقط إلى مجموعة جديدة.
ربما يكون الاختلاف الرئيسي أثناء النقل هو الحاجة إلى إعادة توجيه عناوين IP الخاصة بالقرون الجديدة إلى خوادم تثبيت MongoDB القديم ، إذا كان خارج K8s ، وتسميتها بشكل صحيح في DNS (أو
/etc/hosts ). في المثال ، لم تكن هذه الخطوات مطلوبة ، حيث حدث الترحيل بين مساحات أسماء مختلفة من مجموعة Kubernetes نفسها.
PS
اقرأ أيضًا في مدونتنا: