لقد
تحدثنا بالفعل عن كيف / لماذا نحب Rook: إلى حد كبير ، فإنه يبسط العمل مع التخزين في مجموعات Kubernetes. ومع ذلك ، مع هذه البساطة تأتي بعض الصعوبات. نأمل أن تساعد المادة الجديدة في فهم هذه الصعوبات بشكل أفضل حتى قبل أن تظهر بوضوح.
وللقراءة كان أكثر إثارة للاهتمام ، نبدأ مع
عواقب مشكلة افتراضية في الكتلة.
"لقد ذهب كل شيء!"
تخيل أنك قمت بتكوين Rook وتشغيله في مجموعة K8s الخاصة بك ، فقد كان سعيدًا بعمله ، ولكن في بعض الأوقات "الرائعة" ، حدث ما يلي:
- لا يمكن تحميل القرون الجديدة Ceph RBDs.
- لا تعمل الأوامر مثل
lsblk و df على مضيفي Kubernetes. هذا يعني تلقائيًا "هناك خطأ ما" في صور RBD المُثبتة على عقدة. لا يمكنني قراءتها ، مما يدل على عدم إمكانية الوصول إلى الشاشات ... - نعم ، لا توجد شاشات تشغيل في المجموعة. وعلاوة على ذلك - لا توجد حتى القرون مع OSD ، أو القرون من MGR.
متى تم إطلاق
rook-ceph-operator pod
rook-ceph-operator ؟ منذ وقت ليس ببعيد كما تم نشره. لماذا؟ قررت Rook-operator إنشاء مجموعة جديدة ... كيف يمكننا الآن استعادة الكتلة والبيانات الموجودة فيها؟
للبدء ، دعنا نذهب
لفترة أطول إثارة للاهتمام ، بعد إجراء تحقيق مدروس في "الداخلية" من Rook واستعادة مكوناته خطوة بخطوة. بالطبع ، هناك طريقة صحيحة
أقصر : استخدام النسخ الاحتياطية. كما تعلمون ، ينقسم المسؤولون إلى نوعين: أولئك الذين لا يقومون بعمل نسخ احتياطية ، وأولئك الذين يقومون بها بالفعل ... ولكن المزيد عن هذا بعد التحقيق.
القليل من الممارسة ، أو طريق طويل
نلقي نظرة واستعادة الشاشات
لذلك ، دعونا ننظر إلى قائمة ConfigMaps: هناك
rook-ceph-config rook-config-override ضروري للنسخ الاحتياطي. تظهر عند النشر الناجح للكتلة.
ملاحظة : في الإصدارات الجديدة ، بعد اعتماد هذا PR ، توقفت ConfigMaps لتكون مؤشرا على نجاح نشر نظام المجموعة.لتنفيذ مزيد من الإجراءات ، نحتاج إلى إعادة تشغيل ثابتة لجميع الخوادم التي تحتوي على صور RBD (
ls /dev/rbd* ). يجب أن يتم ذلك من خلال sysrq (أو "سيرا على الأقدام" إلى مركز البيانات). سبب هذا المطلب هو مهمة فصل RBDs المحمّلة ، والتي لن تعمل إعادة تشغيلها بشكل منتظم (ستحاول إلغاء تحميلها بشكل طبيعي دون جدوى).
يبدأ المسرح بشماعات ، وتبدأ مجموعة Ceph بشاشات. دعنا ننظر إليهم.
Rook يحمّل الكيانات التالية في جراب الشاشة:
Volumes: rook-ceph-config: Type: ConfigMap (a volume populated by a ConfigMap) Name: rook-ceph-config rook-ceph-mons-keyring: Type: Secret (a volume populated by a Secret) SecretName: rook-ceph-mons-keyring rook-ceph-log: Type: HostPath (bare host directory volume) Path: /var/lib/rook/kube-rook/log ceph-daemon-data: Type: HostPath (bare host directory volume) Path: /var/lib/rook/mon-a/data Mounts: /etc/ceph from rook-ceph-config (ro) /etc/ceph/keyring-store/ from rook-ceph-mons-keyring (ro) /var/lib/ceph/mon/ceph-a from ceph-daemon-data (rw) /var/log/ceph from rook-ceph-log (rw)
دعونا نرى ما هو سر
rook-ceph-mons-keyring :
kind: Secret data: keyring: LongBase64EncodedString=
نقوم بفك تشفير المفاتيح والحصول عليها باستخدام حقوق المسؤول والشاشات:
[mon.] key = AQAhT19dlUz0LhBBINv5M5G4YyBswyU43RsLxA== caps mon = "allow *" [client.admin] key = AQAhT19d9MMEMRGG+wxIwDqWO1aZiZGcGlSMKp== caps mds = "allow *" caps mon = "allow *" caps osd = "allow *" caps mgr = "allow *"
تذكر. انظر الآن إلى سلسلة المفاتيح الموجودة في سلسلة المفاتيح السرية
rook-ceph-admin-keyring :
kind: Secret data: keyring: anotherBase64EncodedString=
ما فيها؟
[client.admin] key = AQAhT19d9MMEMRGG+wxIwDqWO1aZiZGcGlSMKp== caps mds = "allow *" caps mon = "allow *" caps osd = "allow *" caps mgr = "allow *"
نفس واحد. دعنا نرى المزيد ... هنا ، على سبيل المثال ، سر
rook-ceph-mgr-a-keyring :
[mgr.a] key = AQBZR19dbVeaIhBBXFYyxGyusGf8x1bNQunuew== caps mon = "allow *" caps mds = "allow *" caps osd = "allow *"
في النهاية ، نجد المزيد من الأسرار في ConfigMap
rook-ceph-mon :
kind: Secret data: admin-secret: AQAhT19d9MMEMRGG+wxIwDqWO1aZiZGcGlSMKp== cluster-name: a3ViZS1yb29r fsid: ZmZiYjliZDMtODRkOS00ZDk1LTczNTItYWY4MzZhOGJkNDJhCg== mon-secret: AQAhT19dlUz0LhBBINv5M5G4YyBswyU43RsLxA==
وهذه هي القائمة الأولية مع كيرينغ ، حيث تأتي جميع الأسرار المذكورة أعلاه.
كما تعلمون (انظر
dataDirHostPath في
الوثائق ) ، تخزن Rook هذه البيانات في مكانين. لذلك ، دعنا نذهب إلى العقد لإلقاء نظرة على keyring'y الكذب في الدلائل التي يتم تثبيتها في القرون مع شاشات و OSD. للقيام بذلك ، ابحث عن العقد
/var/lib/rook/mon-a/data/keyring وانظر:
# cat /var/lib/rook/mon-a/data/keyring [mon.] key = AXAbS19d8NNUXOBB+XyYwXqXI1asIzGcGlzMGg== caps mon = "allow *"
فجأة ، تحول السر إلى أن يكون مختلفًا - ليس كما هو الحال في ConfigMap.
ماذا عن المشرف كيرينغ؟ لدينا أيضا ذلك:
# cat /var/lib/rook/kube-rook/client.admin.keyring [client.admin] key = AXAbR19d8GGSMUBN+FyYwEqGI1aZizGcJlHMLgx= caps mds = "allow *" caps mon = "allow *" caps osd = "allow *" caps mgr = "allow *"
ها هي المشكلة. كان هناك فشل: تم إعادة إنشاء الكتلة ... ولكن في الواقع لا.
يصبح من الواضح أن سلسلة المفاتيح التي تم إنشاؤها حديثًا يتم تخزينها في أسرار ، وهي
ليست من نظامنا القديم. لذلك:
- نأخذ كيرينغ من الشاشة من الملف
/var/lib/rook/mon-a/data/keyring (أو من النسخة الاحتياطية) ؛ - تغيير كيرينغ في سلسلة المفاتيح السرية
rook-ceph-mons-keyring - تسجيل حلقة مفاتيح من المشرف والشاشة في ConfigMap'e
rook-ceph-mon ؛ - إزالة جراب تحكم مع الشاشات.
لن تستغرق المعجزة وقتًا طويلاً: ستظهر أجهزة العرض وتبدأ. الصيحة ، بداية!
استعادة OSD
نذهب إلى
rook-operator pod
rook-operator : استدعاء
ceph mon dump يدل على أن جميع الشاشات موجودة ،
ceph -s أنها في النصاب القانوني. ومع ذلك ، إذا نظرت إلى شجرة OSD (شجرة
ceph osd tree ) ، فسترى شيئًا غريبًا فيها: بدأت OSD في الظهور ، لكنها فارغة. اتضح أنهم بحاجة أيضًا إلى استعادة بطريقة ما. لكن كيف؟
في هذه الأثناء ،
rook-ceph-config و
rook-config-override over ، بالإضافة إلى العديد من ConfigMaps الأخرى بأسماء النموذج
rook-ceph-osd-$nodename-config ، في ConfigMap. دعنا ننظر إليهم:
kind: ConfigMap data: osd-dirs: '{"/mnt/osd1":16,"/mnt/osd2":18}'
كل شيء خاطئ ، كل شيء مختلط!
قم بتوسيع قرنة المشغل إلى الصفر ، وحذف قرون النشر التي تم إنشاؤها من OSD ، وقم بإصلاح ConfigMaps. ولكن أين يمكن الحصول على خريطة OSD
الصحيحة من خلال العقد؟
- دعونا نحاول الخوض في الدلائل
/mnt/osd[1-2] على العقد مرة أخرى - على أمل أن نتمكن من تعليق شيء ما هناك. - هناك 2 الدلائل الفرعية في الدليل
/mnt/osd1 : osd0 و osd16 . آخر واحد هو فقط ذلك المعرف المحدد في ConfigMap (16)؟ - دعونا
osd0 حجم ونرى أن osd0 أكبر بكثير من osd16 .
نستنتج أن
osd0 هو OSD المطلوب ، والذي تم تحديده كـ
/mnt/osd1 في ConfigMap (لأننا نستخدم
osd المستند إلى الدليل .)
خطوة بخطوة ، نتحقق من جميع العقد ونعدل ConfigMap. بعد كل التعليمات ، يمكنك تشغيل جراب مشغل Rook وقراءة سجلاته. وكل شيء رائع فيها:
- أنا مشغل كتلة ؛
- لقد وجدت محركات الأقراص على العقد.
- لقد وجدت المراقبين.
- أصبح المراقبون أصدقاء ، أي شكلت النصاب القانوني ؛
- تشغيل نشرات OSD ...
دعنا نعود إلى منصة مشغل Rook ونتحقق من قوة الكتلة ... نعم ، لقد ارتكبنا خطأً بسيطًا في الاستنتاجات حول أسماء OSD على بعض العقد! لا يهم: لقد قاموا بتصحيح ConfigMaps مرة أخرى وحذفوا الدلائل الإضافية من أجهزة OSD الجديدة ووصلوا إلى الحالة التي طال انتظارها
HEALTH_OK !
تحقق من الصور في حمام السباحة:
كل شيء في مكانه - يتم حفظ الكتلة!
أنا كسول القيام النسخ الاحتياطي ، أو الطريق السريع
إذا تم عمل نسخ احتياطية لـ Rook ، فإن إجراء الاسترداد يصبح أبسط بكثير ويتلخص في التالي:
- القياس إلى صفر نشر مشغل Rook ؛
- نزيل جميع عمليات النشر باستثناء مشغل Rook ؛
- نستعيد جميع الأسرار و ConfigMaps من النسخة الاحتياطية ؛
- استعادة محتويات الدلائل
/var/lib/rook/mon-* على العقد ؛ - استعادة (إذا فقدت فجأة) CRD
CephCluster ، CephFilesystem ، CephBlockPool ، CephNFS ، CephObjectStore ؛ - قم بتوسيع نطاق نشر مشغل Rook إلى 1.
نصائح مفيدة
عمل نسخ احتياطية!
ولتجنب المواقف التي تحتاج فيها إلى التعافي منها:
- قبل العمل على نطاق واسع مع الكتلة ، التي تتألف من إعادة تشغيل الخادم ، قم بتوسيع عامل التشغيل Rook إلى الصفر بحيث لا يؤدي الكثير.
- على الشاشات ، أضف nodeAffinity مقدمًا.
- انتبه إلى الإعداد المسبق
ROOK_MON_HEALTHCHECK_INTERVAL و ROOK_MON_OUT_TIMEOUT .
بدلا من الاستنتاج
لا يوجد أي جدال في القول بأن Rook ، كونها "طبقة" إضافية (في المخطط العام لتنظيم التخزين في Kubernetes) ، بقدر ما يتم تبسيطها ، فإنها تضيف أيضًا صعوبات جديدة ومشاكل محتملة في البنية التحتية. يبقى الأمر "صغيرًا": اتخاذ قرار متوازن ومستنير بين هذه المخاطر من ناحية والفوائد التي يجلبها الحل في حالتك الخاصة ، من ناحية أخرى.
بالمناسبة ، تمت إضافة قسم "اعتماد مجموعة Rook Ceph موجودة في مجموعة Kubernetes جديدة" مؤخرًا
إلى وثائق Rook. وهو يصف بمزيد من التفصيل ما يجب القيام به من أجل نقل البيانات الحالية إلى كتلة Kubernetes جديدة أو لاستعادة كتلة انهارت لسبب أو لآخر.
PS
اقرأ أيضًا في مدونتنا: