ضبط forks والتوازي

يتعامل Ansible افتراضيًا مع عدد قليل من المضيفين في كل مرة. وعبر مئات الخوادم، تحوّل هذه الوتيرة التسلسلية play سريعًا إلى انتظار طويل. ⏳

تحدد قيمة forks عدد المضيفين الذين يشغّل عليهم Ansible المهام بالتوازي. وكلما زاد عدد forks، زاد عدد الأجهزة التي تعمل في اللحظة نفسها.

تبلغ قيمة forks الافتراضية 5 فقط. ومع وجود 200 مضيف، يعالج Ansible المضيفين في 40 دفعة، بحيث تنتهي دفعة من خمسة قبل بدء الدفعة التالية.

حدّدوا قيمة افتراضية أعلى في ansible.cfg لكي تستخدمها كل عملية تشغيل. وهذا هو المكان الأنسب لضبط التوازي في أحد المشاريع.

استخدموا الخيار --forks (أو -f) لعملية تشغيل واحدة. فهو يتجاوز قيمة الإعداد من دون الحاجة إلى تعديل أي ملف.

تجعل forks مهمة واحدة تعمل بالتوازي عبر المضيفين، لكن Ansible يظل ينتظر انتهاء جميع المضيفين من المهمة قبل بدء المهمة التالية.

كل fork عبارة عن عملية على عقدة التحكم الخاصة بكم. وتستهلك مئات forks وحدة المعالجة والذاكرة واتصالات SSH المفتوحة، ولذلك يصبح الجهاز نفسه هو الحد.

لا توجد قيمة مثالية. أجروا اختبار أداء لعدة قيم مثل 25 و50 و100، ثم اختاروا القيمة التي تعمل بأسرع وقت من دون زيادة الحمل على عقدة التحكم.

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

تحدد forks الحد الأقصى للتزامن. ثم تقرر إضافة strategy كيفية تحرك المضيفين ضمن مجموعة التنفيذ هذه، ولذلك يعمل الإعدادان معًا.

تفتح قيم forks الكبيرة العديد من جلسات SSH في الوقت نفسه. اجمعوا بين عدد كبير من forks وميزة pipelining وإعادة استخدام الاتصالات للحد من هذا الحمل.

يتقدم play الخاص بكم ببطء عبر 300 مضيف، وتريدون تسريعه.

ارفعوا قيمة forks في ansible.cfg أو باستخدام --forks لتشغيل عدد أكبر من المضيفين في الوقت نفسه. القيمة الافتراضية 5 منخفضة، لكن عقدة التحكم الخاصة بكم تحدد الحد الفعلي. 🚀