أعطال وحدة معالجة الرسوميات في Kubernetes: التعامل مع أعطال الأجهزة دون انتظار لا نهائي

تسلط المقالة الضوء على تجربة Meta في تدريب نموذج Llama 3 405B، حيث شهدت مجموعة مكونة من 16,384 وحدة معالجة رسومية من نوع H100 حدوث 419 انقطاعًا، كان 58.7% منها متعلقًا بوحدات معالجة الرسوميات. وتشير إلى أن نظام Kubernetes يعالج تقليديًا فشل الأجهزة مثل فشل الخدمات عديمة الحالة، حيث يحاول إعادة التشغيل على نفس وحدة معالجة الرسوميات المعطلة، مما يؤدي إلى حلقة انهيار (crash loop). ولمعالجة هذه المشكلة، يقدم Kubernetes 1.36 عدة آليات: تخصيص الموارد الديناميكي (DRA) أصبح مستقرًا منذ الإصدار 1.34، حيث يوفر نموذجًا قائمًا على الكائنات بدلاً من العداد البسيط؛ وقائمة الأولويات (firstAvailable) للأجهزة الاحتياطية؛ وحالة صحة الجهاز في حالة الحاوية (pod status)؛ والعلامات (taints) والتسامحات (tolerations) للأجهزة؛ وشروط ربط الأجهزة، وغيرها. قام المؤلف ببناء منصة اختبار على VK Cloud Managed Kubernetes 1.36 مع عقدة GPU، ومحاكاة فشل وحدة معالجة الرسوميات عن طريق الإزالة الساخنة لجهاز PCIe. وأظهروا أن العقدة تبلغ عن الجهاز كجهاز غير صحي وينخفض العدد المخصص، لكن الحاوية تستمر في إعادة التشغيل على وحدة معالجة الرسوميات المعطلة دون أي إعادة جدولة. ويختتم المقال بشرح سبب عدم توفير Kubernetes لإلغاء الجدولة المدمج للحاويات في حالة CrashLoopBackOff، ويذكر أنماطًا تصنعها بنفسك مثل وحدات التحكم في صحة العقدة التي تقتل العقدة بأكملها، وهو أسلوب غير دقيق.