مرحبًا ، اسمي مكسيم ، وأنا مسؤول نظام. منذ ثلاث سنوات ، بدأت أنا وزملائي في نقل المنتجات إلى الخدمات الصغيرة ، وقررنا استخدام Openstack كمنصة ، وواجهنا عددًا من المكابس غير الواضحة عند أتمتة دوائر الاختبار. تدور هذه المشاركة حول الفروق الدقيقة في إعداد OpenStack ، والتي بالكاد يمكن العثور عليها في الصفحة الخامسة من نتائج محرك البحث (أو أفضل ، فهي سهلة في الصفحة الأولى).
الحمل على النوى: كان - أصبح
NAT
في بعض الحالات ، نستخدم Dualstack. هذا عندما يتلقى الجهاز الظاهري عنوانين في وقت واحد - IPv4 و IPv6. أولاً ، تأكدنا من تعيين عنوان الإصدار 4 "العائم" في الشبكة الداخلية من خلال NAT ، وتلقي الجهاز الإصدار 6 من خلال BGP ، ولكن هناك عدة مشاكل في هذا الأمر.
NAT - عقدة إضافية في الشبكة ، حيث حتى بدونها تحتاج إلى مراقبة توزيع الحمل العادي. غالبًا ما يؤدي ظهور NAT على الشبكة إلى صعوبات في تصحيح الأخطاء - على عنوان IP الخاص بالمضيف ، في قاعدة بيانات أخرى ، ويصبح من الصعب تتبع الطلب. تبدأ عمليات البحث الجماعية ، وسيظل الحل داخل OpenStack.
لا يزال NAT لا يسمح بإجراء تقسيم طبيعي للوصول بين المشاريع. تحتوي جميع المشاريع على شبكات فرعية خاصة بها ، وتنتقل عناوين IP العائمة باستمرار ، ومع NAT يصبح من المستحيل تمامًا إدارة ذلك. تتحدث بعض عمليات التثبيت عن استخدام NAT 1 في 1 (لا يختلف العنوان الداخلي عن العنوان الخارجي) ، ولكن هذا لا يزال يترك روابط غير ضرورية في سلسلة التفاعل مع الخدمات الخارجية. توصلنا إلى استنتاج مفاده أن الخيار الأفضل بالنسبة لنا هو شبكة BGP.
كلما كان ذلك أبسط كلما كان ذلك أفضل
لقد جربنا العديد من أدوات الأتمتة ، ولكننا استقرنا على Ansible. هذه أداة جيدة ، ولكن وظيفتها القياسية (حتى مع مراعاة الوحدات الإضافية) قد لا تكون كافية في بعض المواقف الصعبة.
على سبيل المثال ، من خلال الوحدة النمطية Ansible ، لا يمكنك تحديد عناوين الشبكة الفرعية التي سيتم تخصيصها منها. أي أنه يمكنك تحديد شبكة ، ولكن لا يمكنك تعيين تجمع عناوين محدد. سيساعد الأمر shell الذي ينشئ IP العائم هنا:
openstack floating ip create -c floating_ip_address -f value -project \ {{ project name }} —subnet private-v4 CLOUD_NET
مثال آخر على الوظائف المفقودة: نظرًا للازدواج المزدوج ، لا يمكننا إنشاء جهاز توجيه بشكل صحيح بمنفذين لـ v4 و v6. هذا هو المكان الذي يكون فيه نص bash مفيدًا:
يقوم البرنامج النصي بإنشاء جهاز توجيه ، وإضافة الشبكات الفرعية v4 و v6 إليه ، وتعيين بوابة خارجية.
أعد المحاولة
في أي حالة غير مفهومة - إعادة التشغيل. حاول مرة أخرى ، قم بإنشاء مثيل أو جهاز توجيه أو سجل DNS ، لأنك لا تفهم دائمًا ما هي مشكلتك بسرعة. يمكن أن تؤدي إعادة المحاولة إلى تأخير تدهور الخدمة ، وفي هذا الوقت يمكنك حل المشكلة بهدوء وبدون أعصاب.
جميع النصائح أعلاه تعمل بشكل جيد مع Terraform و Puppet وأي شيء آخر.
كل شيء له مكانه
أي خدمة كبيرة (OpenStack ليست استثناء) تجمع بين العديد من الخدمات الأصغر التي يمكن أن تتداخل مع عمل بعضها البعض. هنا مثال.
وكيل الشبكة Neutron-L2-agent مسؤول عن اتصال الشبكة في OpenStack. إذا كانت جميع العوامل الأخرى موجودة بشكل جزئي على وحدات التحكم ، فإن L2 ، بسبب التفاصيل ، موجودة في كل مكان.
هكذا بدت بنيتنا التحتية في البداية ، حتى تجاوز عدد المخططات 50
عند هذه النقطة ، أدركنا أنه بسبب هذا الترتيب للعوامل ، لم تتمكن وحدات التحكم من التعامل مع الحمل ، ونقلوا العوامل لحساب العقد. فهي أقوى من وحدات التحكم ، وإلى جانب ذلك ، ليس من الضروري أن تتعامل وحدة التحكم مع معالجة كل شيء - يجب أن تعطي المهمة إلى العقدة المنفذة ، وستقوم العقدة بتنفيذها.
وكلاء المحولة لحساب العقد
ومع ذلك ، لم يكن هذا كافيًا ، لأن مثل هذا الترتيب كان له تأثير سيئ على أداء الأجهزة الافتراضية. مع كثافة 14 مركزًا افتراضيًا لكل مادة فعلية ، إذا بدأ وكيل شبكة واحد في تحميل الدفق ، فقد يؤثر ذلك على العديد من الأجهزة الافتراضية في وقت واحد.
التكرار الثالث. ظهرت العقد المختارة.
فكرنا ونقلنا الوكلاء لفصل عقد الشبكة. الآن ، تبقى خدمات الأجهزة الظاهرية فقط على عُقد الحوسبة ، ويعمل جميع الوكلاء على عُقد الشبكة ، ويظل وكلاء bgp الذين يتعاملون مع شبكة v6 فقط على وحدات التحكم (حيث يمكن لعامل bgp أن يخدم نوعًا واحدًا فقط من الشبكة). بقي L2 في كل مكان ، لأنه بدونه ، كما كتبنا أعلاه ، لن يكون هناك اتصال على الشبكة.
قم بتحميل الرسم البياني للعقد الحسابية قبل خلط كل شيء. كان حوالي 60 ٪ ، لكن الحمل انخفض بشكل طفيف
الحمل على softirq قبل عملاء الشبكة إزالة العقد حساب. بقيت 3 نوى محملة. في ذلك الوقت ، اعتقدنا أنه أمر طبيعي
كود التوثيق
في بعض الأحيان يحدث أن الرمز هو التوثيق ، خاصة في الخدمات الكبيرة مثل OpenStack. مع دورة إصدار مدتها ستة أشهر ، ينسى المطورون أو ببساطة ليس لديهم الوقت لتوثيق بعض الأشياء ، وتبين كما هو الحال في المثال أدناه.
حول المهلات
بمجرد أن رأينا أن مكالمات Neutron إلى Open vSwitch لا تصلح في خمس ثوانٍ وتنتهي المهلة.
127.0.0.1:29696: no response to inactivity probe after 10 seconds, disconnecting neutron.agent.ovsdb.native.commands TimeoutException: Commands [DbSetCommand(table=Port, col_values=(('tag', 11),), record=qtoq69a81c6-e2)] exceeded timeout 5 seconds
بالطبع ، افترضنا أنه تم إصلاح هذا في مكان ما من الإعدادات. لقد بحثنا في حزمة التهيئة والوثائق والديون ، لكنهم في البداية لم يجدوا أي شيء. ونتيجة لذلك ، تم العثور على وصف الإعداد المطلوب في الصفحة الخامسة من نتائج البحث - راجعنا الرمز مرة أخرى ووجدنا المكان الصحيح. الإعداد هو هذا:
ovs_vsctl_timeout = 30
وضعناها لمدة 30 ثانية (كانت 5) ، وبدأ كل شيء يعمل بشكل أفضل قليلاً.
إليك أمر آخر غير واضح - عند إعادة تشغيل مكونات الشبكة ، قد تتم إعادة تعيين بعض إعدادات Open vSwitch. يحدث هذا ، على سبيل المثال ، مع عدم نشاط ovs-vsctl. هذا أيضًا مهلة ، ولكنه يؤثر على مكالمات ovs-vsctl نفسها إلى قاعدة بياناته. أضفناها إلى systemd init ، مما سمح لنا ببدء جميع المفاتيح بالمعلمات التي نحتاجها عند بدء التشغيل.
ovs-vsctl set Controller "br-int" inactivity_probe=30000
حول إعدادات مكدس الشبكة
كان علينا أيضًا الابتعاد قليلاً عن الإعدادات المقبولة بشكل عام في حزمة الشبكة ، والتي نستخدمها على خوادمنا الأخرى.
فيما يلي إعداد المدة التي يستغرقها تخزين سجلات ARP في جدول:
net.ipv4.neigh.default.base_reachable_time = 60 net.ipv4.neigh.default.gc_stale_time=60
القيمة الافتراضية هي يوم واحد. بشكل عام ، يمكن أن يعيش مخطط واحد لبضعة أسابيع ، ولكن لمدة يوم واحد ، يمكن إعادة إنشاء المخططات 4-6 مرات ، بينما تتغير مراسلات عنوان MAC وعنوان IP باستمرار. حتى لا تتراكم القمامة ، نضبط الوقت على دقيقة واحدة.
net.ipv4.conf.default.arp_notify = 1 net.nf_conntrack_max = 1000000 (default 262144) net.netfilter.nf_conntrack_max = 1000000 (default 262144)
بالإضافة إلى ذلك ، أجبرنا على إرسال إخطارات ARP عند رفع واجهة الشبكة. قمنا أيضًا بزيادة جدول conntrack ، لأنه عند استخدام NAT و ip العائم ، لم يكن لدينا القيمة الافتراضية. ارتفع إلى مليون (مع الافتراضي في 262144) ، أصبح كل شيء أفضل.
نقوم بتصحيح حجم جدول MAC لـ Open vSwitch نفسه:
ovs-vsctl set bridge bt-int other-config:mac-table-size=50000 (default 2048)
بعد كل الإعدادات ، تحول 40٪ من الحمل إلى صفر تقريبًا
تجزئة تدفق rx
لتوزيع معالجة حركة مرور UDP بين جميع قوائم الانتظار وسلاسل العمليات ، قمنا بتضمين تجزئة تدفق rx. في بطاقات شبكة Intel ، أي في برنامج تشغيل i40e ، يتم تعطيل هذا الخيار افتراضيًا. لدينا hypervisors مع 72 نواة في بنيتنا التحتية ، وإذا كان واحد فقط مشغولًا ، فهذا ليس الأمثل.
يتم ذلك على النحو التالي:
ethtool -N eno50 rx-flow-hash udp4 sdfn
استنتاج مهم: يمكنك تكوين كل شيء على الإطلاق. سيتناسب التكوين الافتراضي في وقت ما (كما فعلنا) ، ولكن مشكلة المهلات جعلت البحث ضروريًا. وهذا أمر طبيعي.
قواعد السلامة
وفقًا لمتطلبات خدمة الأمن ، فإن جميع المشاريع داخل الشركة لديها قواعد شخصية وعالمية - هناك الكثير منها. عندما انتقلنا إلى الخارج من 300 آلة افتراضية إلى برنامج مراقبة افتراضي واحد ، تدفق كل هذا إلى 80 ألف قاعدة لـ iptables. بالنسبة إلى iptables نفسها ، هذه ليست مشكلة ، لكن Neutron يقوم بتحميل هذه القواعد من RabbitMQ في دفق واحد (لأنه مكتوب في Python ، وكل شيء حزين مع تعدد المقالات هناك). يتجمد وكيل النيوترون ويفقد الاتصال مع RabbitMQ ورد فعل متسلسل من المهلات ، وبعد الاسترداد ، يطلب نيوترون مرة أخرى جميع القواعد ، ويبدأ التزامن ، ويبدأ كل شيء من جديد.
إلى جانب ذلك ، زاد وقت إنشاء المدرجات من 20 إلى 40 دقيقة ، في أفضل الأحوال ، إلى ساعة.
في البداية ، قمنا للتو بلف كل شيء مع الاسترداد (أدركنا بالفعل في هذه المرحلة أنه لا يمكن حل المشكلة بهذه السرعة) ، ثم بدأنا في استخدام FWaaS . مع ذلك ، قمنا بإزالة قواعد الأمان مع العقد الحسابية لفصل عقد الشبكة حيث يوجد جهاز التوجيه نفسه.
المصدر - docs.openstack.org
وبالتالي ، يوجد داخل المشروع وصول كامل إلى كل ما هو مطلوب ، ويتم تطبيق قواعد الأمان على الاتصالات الخارجية. لذا قللنا الحمل على النيوترون وعادنا إلى 20-30 دقيقة لخلق بيئة اختبار.
الملخص
OpenStack هو شيء رائع حيث يمكنك إعادة تدوير الحديد وإنشاء سحابة داخلية وإنشاء شيء آخر بناءً عليه. بالإضافة إلى ذلك ، هناك مجتمع كبير ومجموعة نشطة في Telegram ، حيث دفعونا حول المهلات.
هذا كل شيء. اطرح الأسئلة ، أنا وزملائي على استعداد للإجابة عن تجربتنا ومشاركتها.