OpenStack: الحقيقة الكاملة حول الإصدار "الملكي"

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

2016 - اليوم

لم يكن OpenStack هو الحب من النظرة الأولى. الإصدار الأول الذي قمت بنشره للاختبار كان كيلو ، والذي تمت إزالته بكلمة "حزين" بسهولة. بعد أن كان موجودًا لمدة ثلاثة أسابيع بالضبط ، كان يأمل في أن يحل محله ليبرتي ، الذي ، تحت غلاف جذاب - ملاحظات الإصدار - لم يكن قادرًا على تلبية التوقعات العالية. لم تقدم Mitaka الكثير من الوظائف الجديدة لأنها احتوت على الكثير من التصحيحات و "التصحيحات" ، ولا تزال تستخدم (!) بنجاح في البيئات الإنتاجية. في الواقع ، كان نيوتن نقطة تحول في تاريخ OpenStack ، حيث قدم الكثير من التغييرات المعمارية والمنطقية ، ونتيجة لذلك ، تغييرات التكوين التي منعت إلى الأبد مسار الترقية من الإصدار السابق للعديد من الغيوم الخاصة. ولكن مع إطلاق Ocata في عام 2017 ، وفقًا للمحللين ، بدأ "العصر الذهبي" لـ OpenStack ، والذي يشمل Pike و Queens ، وآمل بصدق أن يدخل Rocky ، الذي هو في بداية منخفضة.


ستركز هذه المقالة على أحدث إصدار من OpenStack المستقر - Queens ، على بعض الابتكارات وأوجه القصور - من وجهة نظر شخص كان يعمل على نشره تلقائيًا استنادًا إلى توزيع Ubuntu 16.04 LTS (ويستمر في القيام بذلك لأنه لا يوجد حد للكمال) .

لا يوجد الكثير من المواد حول Queens على الشبكة (إذا قمت باستبعاد الوثائق والتقارير الرسمية من قمة OpenStack الأخيرة في فانكوفر من العينة) ، ويمكن حساب عدد المراجعات من مزودي الخدمات السحابية ودمج الأنظمة على أصابع يد واحدة. ليس من المستغرب أن سلفه - بايك ، الذي سيستمر دعمه الرسمي ثمانية أشهر أخرى - مع عمل مئات المستخدمين وإجراء الترقية الموثق جيدًا ، يبدو أكثر ملاءمة للتنفيذ. لقد ذهب فريقنا ، الذي يتابع عن كثب عملية تطوير Queens منذ البداية ، إلى أبعد من الكثيرين وأطلق بثقة "الجديد" في الإنتاج. فكيف كان عمق أرنب حفرة؟

(فيما يلي مصطلحات OpenStack سيتم استخدامها على نطاق واسع ؛ من المفترض أن القارئ على الأقل على دراية بالبنية النموذجية)

ميزات مفيدة

1. بالنسبة لي شخصيًا ، كانت المكافأة الرائعة في الإصدار الجديد هي توسيع وظائف أداة nova-management: الآن يمكنك حذف المضيفين من بعض الخلايا (الخلايا v2) ونقلها إلى الآخرين! كان على بايك أن يكتب استعلامات قاعدة بيانات منفصلة ، وهو متاح الآن "خارج الصندوق".
2. إنشاء دور مخصص (_member_ بشكل افتراضي) لـ Keystone هو "قطع" من مرحلة التمهيد. كان السبب في ذلك هو الانتقال النهائي إلى API v3 ، الذي يحتوي على أشكال أخرى من آليات التفويض والمصادقة ، مما يزيد أيضًا من أمان البنية التحتية (بعد كل شيء ، كان هناك أيضًا معرف ثابت لدور المستخدم ...) ومع ذلك ، هذا لا يعني على الإطلاق أن دور المستخدم غير مطلوب - مبكرًا أو سيكون عليك إنشائه لاحقًا.
   

   التوقعات: بدءًا من هذا الإصدار ، تم إيقاف Identity API v2 ؛ من المرجح أن يتوقف دعمه تمامًا في غضون عام (متشائم في إصدار شتاين).

3. حصل وكلاء النيوترون l3- و dhcp على فرصة الفشل التلقائي - التحويل التلقائي (إعادة الجدولة) للشبكات والموجهات من وكلاء إيقاف التشغيل إلى وكلاء نشطين. يتم تمكين وظيفة DVR HA افتراضيًا ( [DEFAULT]/router_distributed ، [DEFAULT]/l3_ha ). يتم تخصيص DVR / SNAT في مساحة اسم منفصلة. عند إنشاء جهاز توجيه ، يتم إنشاء snat بشكل افتراضي ، مع أخذ عنوان IP آخر من الشبكة الفرعية الداخلية:
   
   تتيح لك هذه الحزمة التبديل بسرعة من التيار إلى جهاز التوجيه الاحتياطي لعامل l3 الذي يعمل على عقدة أخرى في حالة فشل خدمة SNAT.
4. يتم نقل جميع وظائف Neutron vpn-agent إلى l3-agent ؛ في تكوينه تحتاج إلى إجراء التعديل الوحيد:
   
   

    [agent]/extensions = vpnaas 

   
   أخيرًا ، توقف وجود وكيل vpn عن التدخل في بناء منطق النشر التلقائي في حالة تضمين دور (كان وكلاء vpn و l3 سابقًا متنافيين: إذا وضعت حزمة واحدة ، يتم حذف الأخرى).
5. تم إعلان التسجيل السريع (الوكيل للتفاعل مع قاعدة البيانات في API v1) على أنه خدمة قديمة ، والآن يمكنك تكوين وتحتاج فقط إلى خدمة لمحة سريعة. لا مفاجآت ، ولكن سيتم مناقشتها بعد ذلك بقليل.
6. ماما ميا! يتم تسليم لوحة القيادة الحرارية في حزمة منفصلة (لوحة توصيل) لـ Horizon. خضع البرنامج الإضافي للعديد من التغييرات ، ولكن أكثر الوظائف غير المتوقعة كانت ... سحب وإسقاط الكائنات في عملية إنشاء القوالب. من السهل رؤيته مرة واحدة:
   
   
   
7. تمت إضافة دعم وحدة التخزين متعددة المرفقات في Cinder - القدرة على توصيل قرص واحد بأجهزة افتراضية متعددة. حتى الآن ، تم تنفيذ هذه الوظيفة فقط لعدد محدود من برامج التشغيل التي تدعمها الخدمة: LVM و NetApp / SolidFire و Dell EMC ScaleIO و Oracle ZFSSA - في الواقع ، هذه خطوة كبيرة جدًا للمشروع بأكمله (استغرق تنفيذ الآلية أكثر من عامين ).
   

   التوقعات: لم يتم الإعلان عن دعم Ceph RBD لوحدة التخزين متعددة الأغراض Cinder ؛ على الأرجح ، يجب توقعه في موعد لا يتجاوز العام (بتفاؤل - في إصدار Stein).

البق مزعج

(تم اكتشاف الأخطاء التالية عند نشر OpenStack Queens على توزيع Ubuntu 16.04.4 LTS (Xenial Xerus) ؛ هناك احتمال ألا تظهر في توزيعات Linux الأخرى)

1. في مجتمع Linux ، يوجد شيء مثل "المشرف" - وهو متخصص يقوم بصيانة / صيانة / قيادة مكون برمجي معين (في حالة معينة ، حزمة ثنائية). لذا ، قدم مشرفو Ubuntu مرة أخرى (يوجد خلل في إصدار Pike) حزمًا لخدمة قاعدة بيانات السلاسل الزمنية العادية - Gnocchi. تثبيتها في بيئة Python 2.7 من خلال "فواصل" ملائمة لبعض الخدمات ذات الصلة التي تعمل تحت libapache2-mod-wsgi: Keystone و Cinder و Nova Placement و Horizon. الحالة المحزنة هي عندما تريد استخدام طريقة واحدة لتوصيل الحزم إلى النظام. ومع ذلك ، بينما حاولوا على الأقل Gnocchi تجميع الحزم ، لأن Octavia فقط لا تزال موجودة.
2. أنا لا أتظاهر بالقول ، ولكن ربما كان لدى نفس المشرفين يد المساعدة في إنشاء حزم nova-compute. على الأقل ، قد يفسر هذا السبب عند تثبيتها على النظام (تجميعات kernel 116 و 119 و 124 ؛ إصدارات الحزمة من 17.0.1 إلى 17.0.4) "يتعطل" المثبت مع وجود خطأ:
   
   

    Setting up nova-compute-libvirt (2:17.0.1-0ubuntu1~cloud0) ... adduser: The user 'nova' does not exist. dpkg: error processing package nova-compute-libvirt (--configure): subprocess installed post-installation script returned error exit status 1 dpkg: dependency problems prevent configuration of nova-compute-kvm: nova-compute-kvm depends on nova-compute-libvirt (= 2:17.0.1-0ubuntu1~cloud0); however: Package nova-compute-libvirt is not configured yet. 

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

   UPD: في عملية كتابة المقال ، تم تأكيد الخطأ أخيرًا وتعيين متوسط ​​الأولوية. في وقت حل المشكلة (التبعيات الدورية لحزم نوفا من بعضها البعض) ، اقترح المشرف حلًا آخر: أولاً قم بتثبيت الحزمة المشتركة نوفا ، ثم حساب نوفا. في المستقبل القريب يمكننا أن نتوقع إصدار حزم 17.0.5 ، خالي من هذا العيب.

3. عند اختبار تشغيل خدمة Neutron FWaaS ، اتضح أنه عند إزالة جدار الحماية من جهاز توجيه موزع ، لا يحدث شيء على الإطلاق ... يتغير جدار الحماية من حالة "متصل" إلى حالة "حذف نهائي" ، ويمكنك حل المشكلة إما عن طريق استخدام الاستعلامات إلى قاعدة البيانات أو عن طريق حذف جهاز التوجيه بالكامل (هذا الخطأ موجود في إصدار Pike). المشكلة الرئيسية في الوقت الحالي هي أن الإصلاح (الذي يحل حقًا!) تم اقتراحه قبل بضعة أشهر ، لكنه لم يصل بعد إلى الإصدار المستقر الأخير.
4. بالفعل في مرحلة اختبار الحمل للبنية التحتية ، وجد أن "وحدة المعالجة المركزية النيوترونية المفتوحة EATING AAAAAAA" - في وضع الخمول ، قام وكيل openvswitch بتحميل أحد نوى المعالج بنسبة 100٪:
   
   

    $ ps aux | grep 16233 neutron 16233 99.5 0.0 311112 143156 ? Rs 19:47 67:11 /usr/bin/python2 /usr/bin/neutron-openvswitch-agent --config-file=/etc/neutron/neutron.conf --config-file=/etc/neutron/plugins/ml2/openvswitch_agent.ini --log-file=/var/log/neutron/neutron-openvswitch-agent.log $ time strace -c -p 16233 % time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- 100.00 0.000362 0 95725 epoll_wait 0.00 0.000000 0 15 read 0.00 0.000000 0 6 open 0.00 0.000000 0 6 close 0.00 0.000000 0 6 stat 0.00 0.000000 0 15 fstat 0.00 0.000000 0 20 sendto 0.00 0.000000 0 79 41 recvfrom 0.00 0.000000 0 2 setsockopt 0.00 0.000000 0 94 epoll_ctl ------ ----------- ----------- --------- --------- ---------------- 100.00 0.000362 95968 41 total real 0m10.300s user 0m0.324s sys 0m2.576s 

   
   تم العثور على حل المشكلة من قبل مطوري الخدمة في أقرب وقت ممكن ؛ يتم توفير الإصلاح في إصدار حزمة Neutron 12.0.1-0ubuntu1.1.

رويال فاكاب

في OpenStack Queens ، قدم المطورون طريقة جديدة لتنزيل الصور - تنزيل الويب ، والتي تتيح للمستخدم النهائي "تحميل" صورة حسب المرجع. ذات مرة ، عندما لم يتم إيقاف Image API v1 حتى الآن ولم يتم استبدالها بـ API v2 ، كانت هذه الوظيفة موجودة. يبدو أن ما يمكن أن يكون خطأ؟ ..


في تكوين خدمة look-api ، يتم تمكين كل من طريقتين لتحميل الصور - مباشرة وبواسطة المرجع - افتراضيًا ( [DEFAULT]/enabled_import_methods ). سعياً وراء الهدف البسيط المتمثل في اختبار الخيار ، أقوم بإيقاف تشغيل إحدى الطرق ، وأفرط في الخدمة ، وأسرع!

 CRITICAL glance [-] Unhandled error: ValueError: tuple.index(x): x not in tuple ERROR glance Traceback (most recent call last): ERROR glance File "/usr/bin/glance-api", line 10, in <module> ERROR glance sys.exit(main()) ERROR glance File "/usr/lib/python2.7/dist-packages/glance/cmd/api.py", line 97, in main ERROR glance fail(e) ERROR glance File "/usr/lib/python2.7/dist-packages/glance/cmd/api.py", line 71, in fail ERROR glance return_code = KNOWN_EXCEPTIONS.index(type(e)) + 1 ERROR glance ValueError: tuple.index(x): x not in tuple 

بعد العبث بالرقعة ، أفرط في تحميل الخدمة مرة أخرى:

 glance-api[26538]: ERROR: Value for option enabled_import_methods is not valid: Value should start with "[" systemd[1]: glance-api.service: Main process exited, code=exited, status=4/NOPERMISSION systemd[1]: glance-api.service: Unit entered failed state. systemd[1]: glance-api.service: Failed with result 'exit-code'. 

بجدية أم ماذا ؟! اكتسب الخيار في التهيئة النموذج غير الملائم التالي:

 [DEFAULT]/enabled_import_methods = [glance-direct] 

بالطبع ، تم فتح خطأ بعناية. حتى أن المطورين في وقت حل المشكلة نشروا إعلانًا حول هذه المشكلات المعروفة ، والمعروفة لهم وأرسلوا التزامًا إلى الفرع الرئيسي للمشروع. بعد شهرين من اكتشاف الخطأ ، "ترك" الإصلاح لإصدار مستقبلي ؛ سيتعين على مالكي Queens المحظوظين انتظار حزم Glance الإصدار 16.0.2.
كل شيء على ما يرام ينتهي بشكل جيد.

"لا تفقد رأسك ، أرجح عضلاتك"

خلال عمل أتمتة النشر (الذي يتضمن أيضًا خطوات التكوين والاختبار الوظيفي) ، أثبتت Queens أنها قوية ، وليست محملة بميزات جديدة ، دون وجود "عكاز" يخرج من كل مكان ، مما يرفع المستوى لخلفه.

ومع ذلك ، على الرغم من حقيقة أن كوينز هي الإصدار السابع عشر (!) من OpenStack ، فقد تم الحفاظ على الاتجاه العام لسنوات عديدة: "ما هو غير متوقع لا يمكن توقعه بحدس غير متوقع ". هذا الاقتباس من مسار مشروع Atlantida ، في رأيي ، في أفضل طريقة يصف مجموعة كاملة من الأحاسيس الواردة من التفاعل مع المنتج. من ناحية ، تم تصحيح نشر الخدمات المنتظمة (Keystone ، Glance ، Swift ، Cinder ، Nova ، Neutron ، Horizon) مع الإعدادات الأساسية لفترة طويلة ولن يسبب مشاكل حتى للمهندس المبتدئ. من ناحية أخرى ، عندما يتعلق الأمر بتقديم خدمات الشباب نسبيًا ، تبدأ "العطلة" المذكورة أعلاه: قم بفرزها كما تريد في الوثائق الهزيلة ، واستعد لقضاء أيام في النظر إلى الرمز والجلوس على تعقب الأخطاء الشائعة.

ومع ذلك ، فإن كل هذه المعاناة هي مجرد أثر جانبي لمتلازمة ستوكهولم. ولكن في الواقع ، فإن التمارين المكدسة تهز الدماغ بشكل أسرع من أي لعبة منطقية ، وتطور مهارات مفيدة بشكل كبير ، وتحافظ باستمرار على حالة جيدة وبالتأكيد لا تسمح لك بالملل. من المؤكد أن OpenStack لم يكن حبي من النظرة الأولى ، فقد تحول إلى حرارة بيضاء وإغماء ، لكنه بالتأكيد يستحق القليل من الحب الآن. وإذا كنت على استعداد للمس تقريبًا عبر اللمس من خلال سواد وحدات التحكم ، مدفوعًا بالحاجة إلى إدراك نفسك (وجعل عالم المصدر المفتوح أفضل قليلاً) ، فقد يكون هذا هو طريقك.