نشر DNS VNF مع شبكة SRIOV على OpenStack CVIM - مثال تكوين ل Prime Network Registrar (DNS)

المقدمة

يصف هذا المستند نشر حماية مستوى التحكم (CPNR) خطوة بخطوة على برنامج OpenStack Cisco Virtualized Infrastructure Manager (CVIM) باستخدام SR-IOV وميزة النسخ الاحتياطي النشط.

المتطلبات الأساسية

المتطلبات

توصي Cisco بأن تكون لديك معرفة بالمواضيع التالية:

• الإلمام بمفاهيم OpenStack و Single Root Input/Output Virtualization (SR-IOV)
• معرفة العمل على مدير الواجهة الظاهرية (VIM) من Cisco ووحدة التحكم المرنة في الخدمات وأوامر Linux والشبكات

المكونات المستخدمة

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

تم إنشاء المعلومات الواردة في هذا المستند من الأجهزة الموجودة في بيئة معملية خاصة. بدأت جميع الأجهزة المُستخدمة في هذا المستند بتكوين ممسوح (افتراضي). إذا كانت شبكتك قيد التشغيل، فتأكد من فهمك للتأثير المحتمل لأي أمر

معلومات أساسية

في المشهد الحالي للشبكة، تلعب وظائف الشبكة الظاهرية (VNFs) دورا حاسما في تمكين خدمات الشبكة الرشيقة، والقابلة للتطوير، والفعالة. وبالنسبة لواجهات الشبكة الخاصة الظاهرية (VNF) التي تتطلب اتصال شبكة فائق الأداء، تعد تقنية SR-IOV تقنية شائعة الاستخدام. يسمح الطراز SR-IOV لشبكات VNF بتجاوز المحول الافتراضي لبرنامج Hypervisor والوصول المباشر إلى موارد وحدة التحكم في واجهة الشبكة المادية (NIC)، مما يقلل زمن الوصول ويزيد من سعة المعالجة.

التكوين

قبل متابعة النشر، تأكد من استيفاء هذه المتطلبات الأساسية.

1. متطلبات الأجهزة

• بطاقات واجهة شبكة (NIC) قادرة على دعم SR-IOV:
  • بطاقتا واجهة شبكة (NIC) فيزيائيتان على الأقل طراز SR-IOV مع تمكين SR-IOV في واجهة نظام الإدخال والإخراج الأساسي (BIOS)/البرنامج الثابت الموحد القابل للتوسع (UEFI).
  • مثال:sriov0معين إلى عقدة Non-Uniform Memory Access (NUMA) 0 andsriov1 المعين إلى عقدة NUMA 1.

• الأجهزة المضيفة التي تعتمد على NUMA:
  • يجب أن تدعم عقد الحوسبة بنية NUMA.
  • يجب تمكين دعم NUMA في الأجهزة المضيفة BIOS/UEFI.

2. تحديد بطاقات واجهة الشبكة (NIC) من Intel

تستخدم بطاقات واجهة الشبكة (NIC) طراز XL710 وE810CQDA2 من Intel بشكل شائع لشبكات SR-IOV عالية الأداء. للتحقق من نموذج بطاقة NIC على المضيف، ارجع إلى الخطوات التالية:

الخطوة 1. إستخدام أمر LSPCI

قم بتنفيذ هذا الأمر لسرد أجهزة ربط مكونات الأجهزة الطرفية (PCI) المتعلقة بوحدات التحكم في الشبكة:

lspci | grep -i ethernet

مثال على الإخراج:

81:00.0 Ethernet controller: Intel Corporation Ethernet Controller XL710 for 40GbE QSFP+ (rev 02)
82:00.0 Ethernet controller: Intel Corporation Ethernet Controller E810-C for QSFP (rev 03)

الخطوة 2. التحقق من XL710

إذا كانت بطاقة واجهة الشبكة (NIC) هي Intel XL710، فيمكنك مشاهدة وحدة تحكم الإيثرنت XL710 في الإخراج.

الخطوة 3. التحقق من E810CQDA2

إذا كانت بطاقة واجهة الشبكة (NIC) هي Intel E810CQDA2، فيمكنك مشاهدة خرج وحدة التحكم في الإيثرنت E810-cin.

الخطوة 4. تأكيد دعم برامج التشغيل

للتحقق من برنامج تشغيل بطاقة واجهة الشبكة (NIC) المستخدم، قم بتشغيل:

ethtool -i 

مثال إخراج ل XL710:

driver: i40e
version: 2.13.10

مثال إخراج ل E810CQDA2:

driver: ice
version: 1.7.12

تأكد من تطابق إصدار برنامج التشغيل مع مصفوفة التوافق الخاصة ببرنامج OpenStack و Linux.

3. تكوين نظام الإدخال والإخراج الأساسي (BIOS)/UEFI

• تمكين SR-IOV:

تأكد من تمكين SR-IOV في الخوادم BIOS/UEFI.

• تمكين تقنية المحاكاة الافتراضية للإدخال/الإخراج الموجه (VT-d)/معالج AMD-VI:

يجب تمكين تقنية VT-D أو AMD-VI من Intel من أجل مرور بطاقة PCI ووظائف SR-IOV.

4. إعداد OpenStack

• خدمات Core OpenStack:

تأكد من تثبيت خدمات OpenStack مثل Nova و Neutron و Glance و Keystone وتكوينها.

• تشكيل النترونات:

يجب أن يدعم النترون كلا من محول OpenVswitch (المعروف إختصارا باسم OVS) لشبكات التوجيه/الإدارة وتقنية SR-IOV لشبكات التطبيقات/الخدمات.

• تكوين SR-IOV:

يجب تكوين عقد الحوسبة لدعم SR-IOV، مع إنشاء الوظائف الظاهرية (VFs) على بطاقات واجهة الشبكة (NICs).

5. صورة Cisco Prime Network Registrar (CPNR) VNF

• توافق صورة VNF:

يجب أن تدعم صورة بروتوكول CPNR VNF واجهات SR-IOV وأن تتضمن برامج التشغيل الضرورية.

• تحميل إلى لمحة:

تأكد من توفر صورة CPNR VNF في نظرة OpenStack.

6 - الوصول الإداري

• واجهة سطر الأوامر (CLI) ل OpenStack:

تأكد من الوصول إلى واجهة سطر الأوامر (CLI) الخاصة ب OpenStack لإنشاء الشبكات والنكهات وبدء تشغيل VNF.

• امتيازات الجذر أو المسؤول:

وصول جذري أو إداري لتكوين الشبكات على مضيف Linux وداخل VNF.

نظرة عامة على البنية

الرسم التخطيطي لاتصال واجهة شبكة VNF

مخطط التعاقب

سريوف

أمثلة على التكوينات

فيما يلي عينة من XML لوحدة التحكم المرنة في الخدمات (ESC) من Cisco، توضح نشر الجهاز الظاهري (VM) باستخدام شبكة SR-IOV (مع النوع>المباشر</type>) لمستأجر مسمى مستأجر إختبار و VM باسم SRIOV-VM-1. ويتضمن هذا واجهات متعددة، بما في ذلك واجهات SR-IOV (المباشرة):

    
        
            test-tenant
            true
            false
            
                
                    sriov-vm-deployment
                    
                        sriov-vm-1-group
                        
                            vim1
                            default
                        
                        sriov-image
                        custom-flavor
                        300
                        30
                        
                            REBOOT_ONLY
                        
                        
                            
                            
                                0
                                mgmt-net
                                192.168.10.101
                            

                            
                            
                                1
                                direct
                                sriov-net-1
                                
                                    

                                        0
                                        sriov-subnet-1
                                        10.10.10.10
                                    
                                
                            

                            
                            
                                2
                                direct
                                sriov-net-2
                                
                                    

                                        0
                                        sriov-subnet-2
                                        10.10.20.10
                                    
                                
                            
                        
                        
                            1
                            1
                            false
                        
                        
                            
                                --user-data
                                file://tmp/init/sriov-vm-1.cfg
                            
                        
                    
                
            
        
    

النقاط الرئيسية

• النوع>يتيح </type>المباشر تحت <interface>SR-IOV (مرور PCI) لبطاقة واجهة الشبكة (NIC) هذه.

• يكون لكل واجهة SR-IOV شبكتها الخاصة وشبكتها الفرعية.

• يمكنك إرفاق IPv4/IPv6 في <العناوين> حسب الحاجة.

نموذج ملف يوم0 المطلوب تمريره على Cisco ESC XML:

Content-Type: multipart/mixed; boundary="===============2678395050260980330=="
MIME-Version: 1.0`

--===============2678395050260980330==
MIME-Version: 1.0
Content-Type: text/cloud-boothook; charset="us-ascii"

#cloud-boothook
#!/bin/bash
if [ ! -f /etc/cloud/cloud.cfg.orig ]; then
cp /etc/cloud/cloud.cfg /etc/cloud/cloud.cfg.orig
cp /etc/cloud/cloud.cfg.norootpasswd /etc/cloud/cloud.cfg
fi

--===============2678395050260980330==
MIME-Version: 1.0
Content-Type: text/cloud-config; charset="us-ascii"

#cloud-config
hostname: cpnr
ssh_authorized_keys:
 - ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQC7pf8gvOWH/Zv8iAlTv6LWEiPGA3B6t96G6LwTHF6iXOqQxyIUkg8IkqZ6wNwxsDV8DYESOzFGp//aXO6wZDtoawMExe9sNEx0qVOt/ueP3IYQ8731fNJwFtWQsCQTM7VQjpcg5/d6eMxQ8zvmiIYo2huwfclE+zLdihjL/Y6v4HK760u/DQ+OaEIgqTgrwePJK5Db/gMDf+oXI9KvNxDb2vtxzroX0APEnZ9JX+Ic0JGWTkD4smMkTdWsjaqDYXqW6SUsyCc4Bf9tHL5Irr1AgUR4hEbLnbk6NlIqWrgVeI5CQVMMFpWqV0o2hyDz2rMA7tbBeYzD/ynslQAerU7DmBRb1FDVh79+JeaCNIM8EpwbCUKHT6CQAjPK8cYBieO1yEHKjHyFTsZgpvdi4rVMP+Qsvab+J5RPPcJeKj7o8KIrtyyESXbLNcZv1uGwZ8nLZKfZQSJP04HUkRKoQJ/JoMvMurEKG/cJ1VtocV4AJiRHj+367D3uzrKd6eHYlM9oD+zpPeJ1P1J2TDPUp2K7GcKCrItn9blSGo/n/+gYBO793QjSdkmc/Ag4TEVhUfG17l0WlSvAw4L0csMlYBAGGqKAUEEx3BJGYNJ851bj23m6JBe83OVWGRWrDIIE+G14/tx8qYXDaFxFUFPb2zj+gmDXq80hYpv++/yFtTocbw== cpnr@INVITN14SLM1BULD01CO
 - ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDAmkQGCZUrYqkZ0C0J9t7mF9La9zYOqfzzFkk1wWtPga+aANOaFgjqbjj+VlBdd3zJy1p6BMWZhaZIcOh0+knCisJArcHM3HlurQZXO45zHtBcm7tB1FQ0W1HI9GbvJ+IPIe7kpPme/socd5ytTx0ZkYtlcRDDZuxTwYY4P4/vpnzXuwPS2dfcfQscubj6MkSlx4JHhc/hkDsmtJUipkWEungE/UsldjQzkj8oJorymYHQXE/czNxwzCGizK1YinhebeHFcmHd6Jcqd5oZZWnmkGKGeW6o0ddSFI5NmwzHd5RzwjztU2nqmiyOA8mu7YkCm6X82uhACwQlfY0pGRpTVkIhlf+tKDwKQRuwpcbR1ZUHmli0zi5QZtbzc31aLNlUPpR21BptS4GSfbKJaMOaDUClfe8rGk+9GCgm6wnZiT+SMa4/wEA9NILlwobrwHxVsb/kFlFKXg0aPkdvmqWPNcd09vF50enrs0aXFsqCyl6CPMJpZtGAgckvX8iU2bCJkxzD9F4rAu2D/FNb8KG5cbw7uptiwB4yoek6Q36NyxHYYJyOGiV4oQJ02T9MRPkvjLf7ASx9HA25nG+J4CZXWkuV7XYX1N5DFvOg/kwA7xMPyNgTEkblTRpIcfXU2PCWYSZcn1vYmsazf2uVCY+mjfLcvi85c/1mLnUGikiovQ== admin@invitn14slm1escx01co
runcmd:
 - /usr/sbin/useradd FMLVL1 -d /home/FMLVL1 -s /bin/bash -g users; (/bin/echo changeme; /bin/echo changeme) | /usr/bin/passwd FMLVL1
 - nmcli con add type ethernet con-name eth0 ifname eth0 ip4 10.xx.xx.xx/24
 - nmcli con add type ethernet con-name eth1 ifname eth1 ip4 172.xx.xx.xx/23
 - nmcli connection add type bond con-name bond0 ifname bond0 bond.options "mode=active-backup,miimon=1000,fail_over_mac=1" ipv4.addresses 'xx.xx.xx.xx/29' ipv4.gateway 'xx.xx.xx.xx' ipv4.method manual ipv6.addresses '2402:xxxx:xx:0025::5/64' ipv6.gateway '2402:xxxx:xx:0025::1' ipv6.method manual
 - nmcli connection add type ethernet ifname ens6 master bond0
 - nmcli connection add type ethernet ifname ens7 master bond0
 - nmcli con up eth0
 - nmcli con up eth1
 - nmcli con up bond-slave-ens6
 - nmcli con up bond-slave-ens7
 - nmcli con down bond0
 - nmcli con up bond0
 - nmcli connection reload
 - hostnamectl set-hostname CPNRDNS01CO

--===============2678395050260980330==

نشر CPNR VNF مع منافذ SR-IOV وواجهة سندات النسخ الاحتياطي النشط على OpenStack

تعد حماية مستوى التحكم (CPNR) وظيفة شبكة ظاهرية (VNF) حيوية توفر خدمات إدارة عنوان IP (IPAM) و DHCP وخادم اسم المجال (DNS) لشبكات المؤسسة ومزودي الخدمة. يتطلب نشر حماية مستوى التحكم (CPNR) كمحول VNF في OpenStack تخطيطا دقيقا، وخاصة عند زيادة منافذ SR-IOV، وعمليات تهيئة عبر رقم واحد، وواجهة سندات نشطة-إحتياطية للتكرار والأداء.

تشرح هذه المقالة العملية بالتفصيل لنشر بروتوكول CPNR VNF على OpenStack. ويتضمن هذا النهج ما يلي:

• تكوين وضع NUMBER التبادلي، والذي يعد أمرا حيويا للوصول إلى بطاقات واجهة الشبكة (NIC) من SR-IOV من عقد NUMA متعددة.
• إعداد الربط الاحتياطي النشط، مما يضمن التوفر العالي دون الحاجة إلى عمليات التهيئة من جانب المحول.
• تكوين شبكات OpenStack والنكهات والنظرة السريعة.
• تخطيط عنوان IP، وتكوين شبكات Linux باستخدام ملفات ifcfg، ونشر VNF باستخدام Cisco ESC.

الميزات الرئيسية لعملية النشر

1. الوعي عبر NUMA:

   • يمتد بروتوكول CPNR VNF عبر عقد Numa للوصول إلى بطاقات واجهة الشبكة (NIC) الخاصة ب SR-IOV (sriov0 في NUMA 0 وSRIOV1 في NUMA 1).
   • وضع Cross-NUMBER مطلوب لأن، في وضع NUMA أحادي، يسمح OpenStack فقط ل VNF بالاتصال ببطاقات واجهة الشبكة (NICs) الموجودة فعليا على نفس عقدة NUMA حيث يتم تشغيل VNF. من خلال تمكين وضع NUMA، يمكن ل VNF إستخدام بطاقات واجهة الشبكة (NIC) والموارد من كلا عقدتي NUMA.
     
     

2. الربط الاحتياطي النشط:

   • يتم إنشاء واجهة Bond0 باستخدام بطاقات واجهة الشبكة (NIC) من SR-IOV (ETH2 من sriov0 وETH3 من sriov1).
   • يضمن وضع النسخ الاحتياطي النشط إمكانية التكرار ومواجهة الأعطال دون الحاجة إلى عمليات تكوين من جانب المحول.
     
     

3. شبكات OpenStack:

   • شبكات التزامن والإدارة: OpenVswitch-based للتحكم وحركة المرور الإدارية.
   • شبكات التطبيق/الخدمة: طراز قائم على معيار SR-IOV لحركة المرور فائقة الأداء.

لماذا يتطلب وضع NUMA التبادلي

1. الاتصال الشبكي مع NUMA في OpenStack

NUMA هي بنية ذاكرة يتم فيها تجميع كل وحدة معالجة مركزية (CPU) (والذاكرة والأجهزة المحلية الخاصة بها) في عقدة NUMA. في OpenStack، يضمن الوضع القائم على مراعاة NUMA تخصيص شبكات VNF بشكل مثالي للموارد الموجودة على نفس عقدة NUMA لتقليل زمن الوصول وزيادة الأداء إلى الحد الأقصى.

• بطاقات واجهة الشبكة (NIC) من SR-IOV هي Numa-local:

  • يتم ربط كل بطاقة واجهة شبكة (NIC) مادية بعقدة NUMA معينة. على سبيل المثال:
    • Sriov0 متصل بعقدة NUMA 0.
    • يتصل sriov1 ب NUMA node 1.

• تحديد وضع رقم واحد:

  • عندما يتم تشغيل VNF في وضع رقم واحد، يسمح OpenStack فقط ل VNF بالاتصال ببطاقات واجهة الشبكة (NICs) المحلية لعقدة NUMA حيث يتم تشغيل VNF. وهذا يعني:
    • إن أطلقت ال VNF يكون على NUMA 0، هو يستطيع فقط ربطت إلى NICs على sriov0.
    • إن أطلقت ال VNF يكون على NUMA 1، هو يستطيع فقط ربطت إلى NICs على sriov1.

2. لماذا يكون وضع NUMA المشترك ضروريا

يتطلب CPNR VNF الوصول إلى:

• شبكة التنسيق (OpenVswitch، NUMA-agnostic)
• شبكة الإدارة (OpenVswitch، NUMA-agnostic)
• شبكة SR-IOV رقم 1: Tosriov0(عقدة NUMA 0) المتصلة
• شبكة SR-IOV رقم 2: Tosriov1 متصل (عقدة NUMA 1).

في عملية النشر هذه، يتطلب CPNR VNF الوصول إلى بطاقات واجهة الشبكة (NIC) من نوع SR-IOV من كل من NUMA 0 (sriov0) وNUMA 1 (sriov1) لتوفير التكرار والتوفر الفائق. ومن أجل تحقيق ذلك:

• يجب تشغيل VNF في وضع NUMBER التبادلي، والذي يسمح ل OpenStack بتخصيص وحدة المعالجة المركزية (CPU) والذاكرة وبطاقات واجهة الشبكة (NICs) من عقد NUMA المتعددة.
• وهذا يضمن إمكانية اتصال VNF ببطاقات واجهة الشبكة (NICs) على sriov0 وsriov1، مما يتيح إستخدام كلا من منافذ SR-IOV في تكوين سندات النسخ الاحتياطي النشط.

حد حجم الاتصال لمنافذ VOS

ما هو كونتراك؟

ConTrack هو ميزة نواة Linux المستخدمة لتعقب إتصالات الشبكة، وخاصة لترجمة عنوان الشبكة (NAT) وقواعد جدار الحماية. بالنسبة للمنافذ المستندة إلى OS في OpenStack، يتم إستخدام الاتصال لإدارة حالة الاتصال وفرض قواعد مجموعة الأمان.

كيف يؤثر ConnectTrack على منافذ OS

1. جدول الاتصال:

   • يستهلك كل اتصال نشط إدخالا في جدول الاتصال.
   • تم تحديد حجم جدول الاتصال بواسطة thenf_contrack_maxparameter.
     
     

2. الحد الافتراضي:

   • بشكل افتراضي، يكون حجم جدول الاتصال هو 65536 مدخل. لأحمال العمل ذات معدلات الاتصال العالية (على سبيل المثال، VNF مع العديد من التدفقات المتزامنة)، يمكن استنفاد هذا الحد بسرعة، مما يؤدي إلى إسقاط الحزم.
     
     

3. التأثير على منافذ OS:

   • إذا كان جدول التكوين ممتلئا، يتم إسقاط الاتصالات الجديدة، مما قد يؤثر بشدة على أداء VNF.
   • ويكتسي هذا أهمية خاصة لشبكات Cisco وManagement، التي تستخدم منافذ OVS.

كيفية تخفيف قيود الاتصال

1. زيادة حجم جدول Contrack:

   • عرض الحد الحالي:
     
     

     sysctl net.netfilter.nf_conntrack_max
     

   • زيادة الحد:
     
     

     sysctl -w net.netfilter.nf_conntrack_max=262144
     

   • أجعل التغيير مستمرا:
     
     

     echo "net.netfilter.nf_conntrack_max=262144" >> /etc/sysctl.conf
     

2. إستخدام مسار الاتصال للشاشة:

   فحص إحصائيات الاتصال:
   
   

   cat /proc/sys/net/netfilter/nf_conntrack_count
   

3. تحسين قواعد مجموعة الأمان:

   قم بتقليل عدد القواعد المطبقة على منافذ OVS لتقليل تكاليف الاتصال.

كيفية حل SR-IOV لقضايا الاتصال

1. إزالة تبعية ConnectTrack

تتجاوز منافذ SR-IOV نواة بيانات OVS و Linux التي تتميز بميزات مثل ConnectTrack. وهذا يؤدي إلى التخلص من مصروفات تتبع الاتصال بالكامل.

2. قابلية تطوير فائقة

على عكس منافذ OVS، والتي تكون محدودة بحجم جدول الاتصال (nf_contrack_max)، يمكن لمنافذ SR-IOV معالجة عدد غير محدود من الاتصالات بشكل فعلي.

3. تقليل زمن الوصول

من خلال إلغاء تحميل معالجة الحزمة إلى أجهزة NIC، تعمل منافذ SR-IOV على التخلص من زمن الوصول الذي تتيحه معالجة التحكم القائمة على البرامج.

لماذا يتم إختيار وضع النسخ الاحتياطي النشط لمنافذ SR-IOV على CPNR VM

يعد وضع ربط النسخ الاحتياطي النشط مناسبا بشكل خاص لهذا النشر نظرا لما يتسم به من بساطة ومواجهة الأعطال والتوافق مع واجهات SR-IOV. وإليكم السبب:

1. نسخ الاحتياطية بدون تعقيد

• وضع النسخ الاحتياطي النشط: تقوم واجهة واحدة فقط (ActiveInterface) بإرسال حركة مرور البيانات واستقبالها في أي وقت معين. تبقى الواجهة (الواجهات) الأخرى في وضع الاستعداد.
• في حالة فشل الواجهة النشطة (على سبيل المثال، بسبب فشل الارتباط أو إصدار الأجهزة)، يتحول السند تلقائيا إلى واجهة الاستعداد. وهذا يضمن إمكانية اتصال مستمرة بالشبكة دون الحاجة إلى التدخل اليدوي.

2. لا يلزم وجود مجموعة تجميع إرتباطات (LAG)

• على عكس أوضاع الربط الأخرى (على سبيل المثال،802.3adbalanced-alb)، لا يتطلب وضع النسخ الاحتياطي النشط بروتوكول التحكم في تجميع الارتباطات (LACP) أو تكوينات جانب المحول.
• وهذا مهم بشكل خاص لمنافذ SR-IOV، حيث أن شبكات VF التي تدعم SR-IOV لا تدعم عادة تكوينات LACP أو LAG.

3. تجاوز الفشل بسلاسة تامة

• يكون تجاوز الأعطال شبه فوري مع أقل تعطل لحركة المرور.
• عند فشل الواجهة النشطة، يقوم السند على الفور بترقية واجهة الاستعداد إلى الحالة النشطة.

4. إستقلالية الأجهزة

يعمل وضع النسخ الاحتياطي النشط بشكل مستقل عن المحولات أو الأجهزة المادية الأساسية. يكمن منطق تجاوز الفشل بشكل كامل في نواة لينوكس، مما يجعلها قابلة للتنقل بدرجة كبيرة ومتعددة الاستخدامات.

5. محسن ل SR-IOV

ترتبط الأجهزة الافتراضية التي تدعم تقنية SR-IOV ببطاقات واجهة الشبكة (NIC) المادية وعقد NUMA المحددة. باستخدام وضع النسخ الاحتياطي النشط، يمكنك دمج شبكات VF من عقد NUMA مختلفة في واجهة رابطة منطقية واحدة (Bond0). وهذا يضمن توفر عال مع الاستخدام الفعال لموارد NUMA.

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

ما هي واجهة لينوكس للسندات؟

تقوم واجهة الرابطة في Linux بدمج واجهتي شبكة أو أكثر في واجهة منطقية واحدة. يتم إستخدام هذه الواجهة المنطقية، المشار إليها باسم السند (على سبيل المثال، bond0)، لتوفير:

• نسخ الاحتياطية/معلومات مكررة: ضمان التوفر العالي لاتصال الشبكة.
• تحسين الأداء: وفي أوضاع أخرى (على سبيل المثال،BALANCED-RROR802.3ad)، يمكن أيضا تجميع النطاق الترددي العريض.

كيف يعمل وضع النسخ الاحتياطي النشط؟

في وضع النسخ الاحتياطي النشط، يتم إستخدام واجهة واحدة فقط (تسمى الواجهة النشطة) في أي وقت معين لإرسال حركة مرور البيانات واستقبالها. تبقى الواجهة (الواجهات) الأخرى في وضع الاستعداد. في حالة فشل الواجهة النشطة، تتم ترقية إحدى واجهات الاستعداد إلى الحالة النشطة، ويتم إعادة توجيه حركة مرور البيانات تلقائيا إلى الواجهة النشطة الجديدة.

الميزات الرئيسية لوضع النسخ الاحتياطي النشط

1. واجهة نشطة واحدة:

   • وفي أي وقت، تكون واجهة مادية واحدة فقط في السند نشطة لنقل واستقبال حركة المرور.
   • تكون واجهات الاستعداد سلبية تماما ما لم يتم تجاوز الفشل.
     
     

2. تجاوز الفشل التلقائي:

   • إذا فشلت الواجهة النشطة (على سبيل المثال، بسبب مشكلة في الأجهزة أو انقطاع الكابلات أو فشل في الارتباط)، يتحول السند تلقائيا إلى واجهة إحتياطية.
   • تتسم عملية التغلب على الأعطال بالسلاسة التامة ولا تتطلب تدخلا يدويا.
     
     

3. دعم مواجهة الأعطال:

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

4. لا توجد متطلبات لجانب المحول:

   • بخلاف أوضاع الربط الأخرى (على سبيل المثال،802.3adbalanced-rr)، لا يتطلب وضع النسخ الاحتياطي النشط أي تكوين خاص على المحولات المادية (على سبيل المثال، LAG أو LACP).
   • وهذا يجعلها مثالية للسيناريوهات التي لا يكون فيها تكوين جانب المحول ممكنا أو عند ربط الوظائف الظاهرية SR-IOV، التي لا تدعم التداخل.

5. المراقبة:

   • يراقب الرابط باستمرار صحة كل واجهات الأعضاء باستخدام المعلمة Themiimon (مراقبة الواجهة المستقلة للوسائط).
   • وفي حالة اكتشاف فشل إرتباط، يتحول السند على الفور إلى واجهة إستعداد سليمة.

كيفية تدفق حركة المرور في وضع النسخ الاحتياطي النشط

التشغيل العادي

1. الواجهة النشطة:

   • تتدفق حركة المرور بشكل حصري من خلال الواجهة النشطة (على سبيل المثال، eth2 في عقدة الإصدار 2من).
   • تبقى واجهة الاستعداد (eth3) في وضع الخمول ولا تقوم بإرسال حركة مرور البيانات أو استقبالها.
     
     

2. المراقبة:

   • يقوم السند بمراقبة حالة جميع واجهات الأعضاء بشكل دوري. ويتم القيام بذلك باستخدام:
     • ميمون: يتحقق من حالة الارتباط لكل واجهة في فترة قابلة للتكوين (على سبيل المثال، كل 100 مللي ثانية).
     • مراقبة بروتوكول تحليل العنوان (ARP) (إختياري): يرسل طلبات ARP لضمان إمكانية الوصول إلى الواجهة النشطة.

سيناريو تجاوز الفشل

1. فشل الارتباط على الواجهة النشطة:

   في حالة فشل الواجهة النشطة (ETH2) (على سبيل المثال، إلغاء توصيل الكبل أو عطل أجهزة NIC أو الارتباط لأسفل)، يتحقق من مراقبة Miimonor ARP للسندات على الفور.
   
   

2. تجاوز الفشل التلقائي:

   • يتحول السند إلى واجهة الاستعداد (ETH3)، والتي تصبح الواجهة النشطة الجديدة.
   • تتم إعادة توجيه حركة المرور من خلال الواجهة النشطة الجديدة دون الحاجة إلى التدخل اليدوي.
     
     

3. توقيت تجاوز الفشل:

   وعملية تجاوز الفشل شبه آنية (عادة في غضون بضعة أجزاء من الثانية، وفقا للفاصل الزمني الوثيمي).

سيناريو مواجهة الأعطال

1. إستعادة الواجهة الفاشلة:

   • عند إستعادة الواجهة التي فشلت سابقا (eth2)، يمكنها:
     • إستعادة الدور النشط تلقائيا (إذا تم تكوينه للقيام بذلك).
     • البقاء في وضع الاستعداد (السلوك الافتراضي).

2. إستمرارية المرور:

   تتسم عملية التغلب على الأعطال بالسلاسة التامة، مما يضمن عدم حدوث أية أعطال في تدفقات حركة المرور المستمرة.

حالة الاستخدام: ربط إحتياطي نشط مع منافذ SR-IOV

يعد وضع النسخ الاحتياطي النشط ملائما بشكل خاص لواجهات SR-IOV لأن:

• لا تدعم شبكات VF التي تدعم تقنية SR-IOV عادة بروتوكولات تجميع الارتباطات مثل LACP.
• ويمكن أن توفر الرابطة في وضع النسخ الاحتياطي النشط إمكانية التكرار دون أي تكوين من جانب المحول.

على سبيل المثال:

• يتم تعيين ETH2 إلى SR-IOV VF onsriov0 (عقدة NUMA 0).
• تم تعيين ETH3 إلى SR-IOV VF onsriov1(عقدة NUMA 1).
• يجمع الارتباط (Bond0) بين هذه الواجهات، مما يوفر إمكانية تجاوز الأعطال بسلاسة تامة بين الأجهزة الافتراضية التي تدعم تقنية SR-IOV.

الخطوة 1. شبكات OpenStack

يتطلب CPNR VNF الشبكات الأربع التالية:

1. شبكة التزامن: لحركة مرور التحكم والتزامن (المستندة إلى OpenVswitch).
2. شبكة الإدارة: للوصول الإداري (المستند إلى OpenVswitch).
3. شبكة SR-IOV رقم 1: حركة مرور التطبيقات/الخدمات على sriov0.
4. شبكة SR-IOV رقم 2: حركة مرور التطبيقات/الخدمات على sriov1.

النشر بالتفصيل:

الخطوة 1.1. إنشاء شبكات OpenVswitch

• شبكة التزامن:
  
  

  openstack network create --provider-network-type vxlan orchestration-network

• شبكة الإدارة:
  
  

  openstack network create --provider-network-type vxlan management-network

الخطوة 1.2. إنشاء شبكات فرعية لشبكات OpenVswitch

• الشبكة الفرعية للتزامن:
  
  

  openstack subnet create --network orchestration-network \
  --subnet-range 192.168.100.0/24 orchestration-subnet

• الشبكة الفرعية للإدارة:
  
  

  openstack subnet create --network management-network \
  --subnet-range 10.10.10.0/24 management-subnet

الخطوة 1.3. إنشاء شبكات SR-IOV

• شبكة SR-IOV رقم 1:
  
  

  openstack network create --provider-network-type vlan \
  --provider-physical-network sriov0 --provider-segment 101 sriov-network-1

• شبكة SR-IOV رقم 2:
  
  

  openstack network create --provider-network-type vlan \
  --provider-physical-network sriov1 --provider-segment 102 sriov-network-2

الخطوة 2. نكهات OpenStack

الخطوة 2.1. إنشاء نكهة عبر رقم واحد

لضمان إمكانية وصول VNF إلى بطاقات واجهة الشبكة (NIC) الخاصة بالمعالج SR-IOV من كلتا عقدتي NUMA، يمكنك إنشاء طعم مزود بدعم تقنية Cross-NUMBER:

openstack flavor create --ram 8192 --vcpus 4 --disk 40 cross-numa-flavor

الخطوة 2.2. تكوين خصائص NUMA

تعيين الخصائص الخاصة ب NUMA:

openstack flavor set cross-numa-flavor \
--property hw:numa_nodes=2 \
--property hw:cpu_policy=dedicated \
--property hw:mem_page_size=large

الخطوة 3. تكوين الربط في وضع النسخ الاحتياطي النشط

بعد تشغيل VNF، قم بتكوين واجهة السندات لمنافذ SR-IOV (ETH2 وETH3) على VNF.

الخطوة 3.1. تكوين واجهة السندات

إنشاء واجهة رابطة (bond0) في وضع النسخ الاحتياطي النشط:

vi /etc/sysconfig/network-scripts/ifcfg-bond0

DEVICE=bond0
BOOTPROTO=static
ONBOOT=yes
BONDING_OPTS="mode=active-backup miimon=100"
IPADDR=172.16.1.10
NETMASK=255.255.255.0
GATEWAY=172.16.1.1

الخطوة 3.2. تكوين واجهات Slave

• ت إ 2:
  
  

  vi /etc/sysconfig/network-scripts/ifcfg-eth2

  DEVICE=eth2
  ONBOOT=yes
  MASTER=bond0
  SLAVE=yes

• ETH3:
  
  

  vi /etc/sysconfig/network-scripts/ifcfg-eth3

  DEVICE=eth3
  ONBOOT=yes
  MASTER=bond0
  SLAVE=yes

الخطوة 3.3. تطبيق التكوين

قم بإعادة تشغيل خدمة الشبكة من أجل تطبيق التكوين:

systemctl restart network

التحقق من الصحة

بعد نشر التردد اللاسلكي (VNF)، تحقق من وظائفه باستخدام الخطوات التالية:

1. التحقق من حالة VNF

تحقق من أن مثيل VNF نشط:

openstack server show cpnr-instance

تأكد من أن الحالة نشطة.

2. التحقق من اتصال الشبكة

• إختبار إختبار الاتصال: دققت أن ال VNF يستطيع اتصلت عبر كل شبكة:

  ping 
  ping 
  

• واجهة السندات:

  • تأكيد أن Bond0 نشط:
    
    

    cat /proc/net/bonding/bond0
    

    بحث عن:

    • عبد نشيط حاليا: يشير إلى الواجهة النشطة.
    • واجهة العبيد: يؤكد أن Botheth2andeth3 هو جزء من الرابطة.
      
      

3. التحقق من وضع NUMA

تأكد من أن VNF يستخدم موارد من كلا عقدتي NUMA:

nova show  --human | grep numa

أفضل الممارسات

• المراقبة واستكشاف الأخطاء وإصلاحها: إستخدام أدوات liketcpdumpandethtoolto مراقبة واجهات SR-IOV.

• الأمان: إدارة الوصول إلى الشبكة الفعلية بعناية وفرض العزل التام بين المستأجرين.

• القياس: خطط لسعة بطاقة واجهة الشبكة (NIC) المادية عند تطوير عمليات نشر SR-IOV، حيث أن عدد الأجهزة الافتراضية (VFs) المتاحة محدود بواسطة بطاقة واجهة الشبكة (NIC).

استكشاف الأخطاء وإصلاحها

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

1. التحقق من تكوين SR-IOV

• تحقق من تمكين SR-IOV في BIOS:
  
  

  dmesg | grep -i "SR-IOV"
  

• تأكيد إنشاء VFs على NICs:
  
  

  lspci | grep Ethernet
  

2. التحقق من وضع NUMA

إن ال VNF يستطيع لا ينفذ كلا nicS، ضمنت cross-NUMBER أسلوب مكنت:

• التحقق من خصائص NUMA للنكهة:
  
  

  openstack flavor show cross-numa-flavor
  

3 - مسائل واجهة السندات

• تحقق من حالة السند:
  
  

  cat /proc/net/bonding/bond0
  

• إذا كان السند لا يعمل:
  • تأكد من أن واجهات العبيد (th2andeth3) شكلت بشكل صحيح كجزء من الرابط.
  • إعادة تشغيل خدمة الشبكة:
    
    

    systemctl restart network
    

4. مشكلات الاتصال بالشبكة

• التحقق من روابط منفذ OpenStack:
  
  

  openstack port list --server cpnr-instance
  

• تحقق من تكوين IP الصحيح داخل VNF:
  
  

  ip addr show
  

القرار

يتطلب نشر CPNR VNF على OpenStack باستخدام منافذ SR-IOV وضع Cross-NUMBER لتمكين VNF من الاتصال ببطاقات واجهة الشبكة (NICs) من كلتا عقدتي NUMA. وهذا أمر ضروري لأن OpenStack يقيد VNFs في وضع رقم واحد للوصول إلى الموارد (NICs، CPUs، الذاكرة) فقط داخل عقدة NUMA حيث يتم تشغيل VNF. إن الجمع بين وضع NUMA وبين الربط الاحتياطي النشط يضمن التوفر العالي ومواجهة الأعطال والاستفادة الفعالة من الموارد، مما يجعل عملية النشر هذه مرنة للغاية والأداء الفائق.