المقدمة
يصف هذا المستند إجراء أستكشاف أخطاء التوفر العالي (HA) وإصلاحها في مدير مجموعات النظام الأساسي للنشر الأصلي للسحابة (CNDP).
المتطلبات الأساسية
المتطلبات
توصي Cisco بأن تكون لديك معرفة بالمواضيع التالية:
- البنية الأساسية للخدمات الدقيقة للمشترك (SMI) من Cisco
- البنية المعمارية 5G CNDP أو SMI-Bare-metal (BM)
- جهاز الكتلة الموزع المنسوخ نسخا متماثلا (DRBD)
المكونات المستخدمة
تستند المعلومات الواردة في هذا المستند إلى إصدارات البرامج والمكونات المادية التالية:
- SMI 2020.02.2.35
- Kubernetes v1.21.0
- DRBD 8.9.10
تم إنشاء المعلومات الواردة في هذا المستند من الأجهزة الموجودة في بيئة معملية خاصة. بدأت جميع الأجهزة المُستخدمة في هذا المستند بتكوين ممسوح (افتراضي). إذا كانت شبكتك قيد التشغيل، فتأكد من فهمك للتأثير المحتمل لأي أمر.
معلومات أساسية
ما هي SMI؟
Cisco SMI هي مجموعة طبقات من تقنيات ومعايير السحابة التي تمكن التطبيقات المستندة إلى الخدمات الدقيقة من وحدات الأعمال Cisco Mobility، و Cable، و Broadband Network Gateway (BNG) - وجميعها تحتوي على وظائف إدارة المشترك المتشابهة ومتطلبات تواجد بيانات مماثلة.
السمات:
- حزمة الشبكة من الطبقة (التقنيات والمعايير) لتوفير عمليات النشر من أعلى إلى أسفل وكذلك إستيعاب البنية الأساسية لشبكات المستخدم الحالية.
- بيئة التنفيذ المشتركة المشتركة التي تشترك فيها جميع التطبيقات للوظائف غير التطبيقية (تخزين البيانات والنشر والتهيئة والقياس عن بعد والإنذار). وهذا يوفر تفاعلا وتجربة متناسقين لجميع نقاط الاتصال الخاصة بالمستخدم ونقاط التكامل.
- يتم نشر التطبيقات وبيئات التنفيذ الشائعة في حاويات الخدمة بالغة الصغر ويتم توصيلها بشبكة خدمة ذكية.
- واجهة برمجة تطبيقات مكشوفة للنشر والتكوين والإدارة، من أجل تمكين التشغيل التلقائي.
ما المقصود ب SMI-BM أو CNDP؟
Cisco SMI-BM أو CNDP هو نظام أساسي أصلي متعهد يوفر البنية الأساسية لنشر وظائف الشبكة الظاهرية (VNF) والوظائف الأصلية للسحابة (CNFs)، التي تتيح إمكانية التنقل من Cisco والكبل ووحدات أعمال BNG.
السمات:
- BM الذي يعمل على التخلص من التكاليف الإضافية المتعلقة بمدير البنية الأساسية الظاهري (VIM).
- أداء محسن:
- المزيد من النوى للتطبيق
- تنفيذ أسرع للتطبيقات
- سير عمل النشر التلقائي، مدمج مع حزمة الوظائف الأساسية (CFP) لخدمات الشبكة Orchestrator (NSO)
- مكدس مخصص لنشر وظائف شبكة Cisco 5G (NFs)
- دليل مبسط للأمر والنشر
ما هو برنامج SMI Cluster Manager؟
مدير نظام المجموعة عبارة عن عقدة ثنائية keepalived نظام المجموعة المستخدم كنقطة أولية لكل من مستوى التحكم ونشر مجموعات مستوى المستخدم. وهو يشغل مجموعة Kubernetes أحادية العقدة ومجموعة من PODs المسؤولة عن إعداد نظام المجموعة بالكامل. مدير نظام المجموعة الأساسي فقط نشط بينما يتولى المدير الثانوي فقط في حالة حدوث عطل أو يتم إسقاطه يدويا لإجراء الصيانة.
ما هو DRBD؟
يتم إستخدام DRBD لزيادة توفر البيانات. وهو عبارة عن مكون برمجي مفتوح المصدر قائم على بيئة لينوكس ويعمل على تسهيل إستبدال أنظمة التخزين المشتركة بمرآة متصلة بالشبكة. وباختصار، يمكنك القول إن هذا هو "نسخة طبق الأصل من RAID 1 للبيانات قائمة على الشبكة".
المشكلة
تتم إستضافة مدير نظام المجموعة في نظام مجموعة يتكون من عقدتين مع جهاز حظر موزع منسوخ نسخا متماثلا (DRBD) و keepalived. يمكن أن ينكسر HA ويمكن أن يصل إلى حالة انقسام الدماغ أيضا. يساعد هذا الإجراء على إستعادة نظام المجموعة المكسورة. الحالة المرغوب فيها لمدير نظام المجموعة HA هي cluster manager1 (CM1) أساسي و cluster manager2 (CM2) ثانوي. هنا، CM1 هو الضحية المنقسم الدماغ.
إجراءات الصيانة
قم بتسجيل الدخول إلى مدير نظام المجموعة وتحقق من حالة مجموعة DRBD.
cloud-user@pod-name-cm-1:~$ drbd-overview
0:data/0 WFConnection Secondary/Unknown UpToDate/DUnknown
cloud-user@pod-name-cm-2:~$ drbd-overview
0:data/0 StandAlone Primary/Unknown UpToDate/DUnknown /mnt/stateful_partition ext4 568G 147G 392G 28%
في هذا السيناريو، يكون CM2 أساسيا وتكون المجموعة في الوضع المستقل. CM1 حاليا ثانوي وفي wait for connection الحالة.
وفيما يلي الحالة الصحيحة لهذا النظام:
cloud-user@pod-name-deployer-cm-1:~$ drbd-overview
0:data/0 Connected Primary/Secondary UpToDate/UpToDate /mnt/stateful_partition ext4 568G 364G 176G 68%
cloud-user@pod-name-deployer-cm-2:~$ drbd-overview
0:data/0 Connected Secondary/Primary UpToDate/UpToDate Move the CM VIP to CM-1 from CM-2 and make CM-1 as primary –
نقل شخصيات CM المهمة إلى CM-1 من CM-2 وجعل CM-1 أساسي (الشخصية المهمة لبرنامج المجموعة هي 10.x.x.65
On CM-2 issue below command
cloud-user@pod-name-cm-2:~$sudo systemctl restart keepalived
On CM-1 issue below command (Make sure that the VIP is now switched over to CM-1)
cloud-user@pod-name-cm-1:~$ip a s | grep 10.x.x
inet 10.x.x.70/26 brd 10.x.x.127 scope global vlan1xx ----> here is the server IP
inet 10.x.x.65/26 scope global secondary vlan1xx. ----> here is the VIP
تحديد مورد DRBD (مشترك عبر الشبكة):
cloud-user@pod-name-deployer-cm-1:/$ cat /etc/fstab
#/mnt/stateful_partition/data /data none defaults,bind 0 0 ---> /data is the resource
#/mnt/stateful_partition/home /home none defaults,bind 0 0
cloud-user@pod-name-deployer-cm-1:/$ df -h
Filesystem Size Used Avail Use% Mounted on
udev 189G 0 189G 0% /dev
tmpfs 38G 22M 38G 1% /run
/dev/sda1 9.8G 3.5G 5.9G 37% /
tmpfs 189G 0 189G 0% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 189G 0 189G 0% /sys/fs/cgroup
/dev/sda4 71G 1.5G 66G 3% /tmp
/dev/sda3 71G 11G 57G 16% /var/log
/dev/drbd0 568G 365G 175G 68% /mnt/stateful_partition -->/dev/drbd0 is the device name
tmpfs 38G 0 38G 0% /run/user/1000
cloud-user@pod-name-deployer-cm-1:/$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 744.1G 0 disk
├─sda1 8:1 0 10G 0 part /
├─sda2 8:2 0 10G 0 part
├─sda3 8:3 0 72.2G 0 part /var/log
├─sda4 8:4 0 72.2G 0 part /tmp
├─sda5 8:5 0 577.6G 0 part
│ └─drbd0 147:0 0 577.5G 0 disk /mnt/stateful_partition ---> /dev/sda5 is used to create drbd0
تحقق من ملف تكوين DRBD للحصول على تفاصيل المورد:
cloud-user@pod-name-deployer-cm-1:/$ cat /etc/drbd.d/data.res
resource data {
protocol C; --->Synchronous replication protocol. Local write operations on the primary node are considered completed only after both the local and the remote disk write have been confirmed. As a result, loss of a single node is guaranteed not to lead to any data loss
....
....
device /dev/drbd0;
disk /dev/disk/by-partlabel/smi-state; --> This translates to /dev/sda5
meta-disk internal;
floating 10.192.1.2:7789;
floating 10.192.1.3:7789;
الآن، قم بإجراء إسترداد DRBD:
On CM-2
cloud-user@pod-name-cm-2:~$ sudo systemctl stop keepalived ---> stop to avoid VRRP VIP switchover
cloud-user@pod-name-cm-2:~$ sudo drbdadm disconnect data ---> data is the cluster resource
cloud-user@pod-name-cm-2:~$ sudo drbdadm secondary data ---> Make it secondary manually
cloud-user@pod-name-cm-2:~$ sudo drbdadm connect --discard-my-data data ---> Force discard of all modifications on the split brain victim
cloud-user@pod-name-cm-2:~$ drbd-overview status
On CM-1:
cloud-user@pod-name-cm-1:~$ sudo systemctl stop keepalived ---> stop to avoid VRRP VIP switchover
cloud-user@pod-name-cm-1:~$ sudo drbdadm connect data ---> Data will be connected as primary
cloud-user@pod-name-cm-1:~$ drbd-overview status
بدء keepalived معالجة على كلا الوثيقتين. VRRP بمساعدة من keepalived يحدد CM-1 كأساسي، بناء على المورد الأساسي المتصل /data:
cloud-user@pod-name-cm-1:~$ sudo systemctl start keepalived
cloud-user@pod-name-cm-1:~$ sudo systemctl status keepalived
cloud-user@pod-name-cm-2:~$ sudo systemctl start keepalived
cloud-user@pod-name-cm-2:~$ sudo systemctl status keepalived
تحقق من حالة DRBD على CM-1 و CM-2. يجب تحويلها إلى حالة نظام مجموعة صحيحة الآن.
cloud-user@pod-name-deployer-cm-1:~$ drbd-overview
0:data/0 Connected Primary/Secondary UpToDate/UpToDate /mnt/stateful_partition ext4 568G 364G 176G 68%
cloud-user@pod-name-deployer-cm-2:~$ drbd-overview
0:data/0 Connected Secondary/Primary UpToDate/UpToDate Move the CM VIP to CM-1 from CM-2 and make CM-1 as primary
/data تم التحميل فقط على العقدة الأساسية.
cloud-user@pod-name-deployer-cm-1:~$ df -h
Filesystem Size Used Avail Use% Mounted on
udev 189G 0 189G 0% /dev
tmpfs 38G 22M 38G 1% /run
/dev/sda1 9.8G 3.5G 5.9G 37% /
tmpfs 189G 0 189G 0% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 189G 0 189G 0% /sys/fs/cgroup
/dev/sda4 71G 1.5G 66G 3% /tmp
/dev/sda3 71G 11G 57G 16% /var/log
/dev/drbd0 568G 364G 175G 68% /mnt/stateful_partition
tmpfs 38G 0 38G 0% /run/user/1000
cloud-user@pod-name-deployer-cm-secondary:~$ df -h
Filesystem Size Used Avail Use% Mounted on
udev 189G 0 189G 0% /dev
tmpfs 38G 2.3M 38G 1% /run
/dev/sda1 9.8G 2.0G 7.3G 22% /
tmpfs 189G 0 189G 0% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 189G 0 189G 0% /sys/fs/cgroup
/dev/sda3 71G 9.3G 58G 14% /var/log
/dev/sda4 71G 53M 67G 1% /tmp
tmpfs 38G 0 38G 0% /run/user/1000
التعليقات