يكاد لا يمكن تصوّر شبكة الإنترنت الحديثة بدون محتوى وسائط: فكل جدة تقريبًا لديها هاتف ذكي ، والجميع على الشبكات الاجتماعية ، وتعطل الخدمة مكلف للشركات. لاهتمامكم ، نسخة من قصة الشركة حول كيفية تنظيمها لتسليم الصور باستخدام حل الأجهزة ، وما هي مشكلات الأداء التي واجهتها في العملية ، وما سببها ، وكيف تم حل هذه المشكلات باستخدام حل برمجي يعتمد على Nginx ، مع ضمان التسامح مع الخطأ على جميع المستويات (). نشكر مؤلفي القصة أوليغ إيفيموفا وألكسندرا ديموفا ، اللذان شاركا تجربتهما في المؤتمر .
لنبدأ بمقدمة صغيرة حول كيفية تخزين الصور وتخزينها مؤقتًا. لدينا طبقة حيث نقوم بتخزينها ، وطبقة حيث نقوم بتخزين الصور مؤقتًا. في الوقت نفسه ، إذا أردنا تحقيق خدعة كبيرة وتقليل الحمل على التخزين ، فمن المهم بالنسبة لنا أن تقع كل صورة لمستخدم فردي في خادم تخزين مؤقت واحد. وإلا ، فسيتعين علينا تثبيت عدة أضعاف عدد الأقراص الذي لدينا عدد أكبر من الخوادم. يبلغ معدل نجاحنا حوالي 99٪ ، أي أننا نقلل العبء على التخزين لدينا بمقدار 100 مرة ، ومن أجل القيام بذلك ، قبل 10 سنوات ، عندما كان كل هذا قيد الإنشاء ، كان لدينا 50 خادمًا. وفقًا لذلك ، من أجل إعطاء هذه الصور ، كنا بحاجة ، في الواقع ، إلى 50 نطاقًا خارجيًا تخدمها هذه الخوادم.
بطبيعة الحال ، نشأ السؤال على الفور: إذا تعطل أحد خوادمنا وأصبح غير متاح ، فما هو جزء من حركة المرور التي نخسرها؟ نظرنا إلى ما كان موجودًا في السوق وقررنا شراء قطعة حديد لحل جميع مشاكلنا. وقع الاختيار على حل شركة F5-network (التي ، بالمناسبة ، اشترت NGINX، Inc منذ وقت ليس ببعيد): BIG-IP Local Traffic Manager.
ما تفعله قطعة الحديد هذه (LTM): هو جهاز توجيه حديدي يقوم بعمل فائض من الحديد في منافذه الخارجية ويسمح لك بتوجيه حركة المرور بناءً على هيكل الشبكة ، في بعض الإعدادات ، ويقوم بإجراء فحوصات صحية. كان من المهم بالنسبة لنا برمجة قطعة الحديد هذه. وفقًا لذلك ، يمكننا وصف منطق كيفية إرجاع صور مستخدم معين من ذاكرة تخزين مؤقت معينة. كيف تبدو؟ هناك قطعة من الأجهزة تبحث في الإنترنت لمجال واحد ، عنوان IP واحد ، وتفريغ SSL ، وتوزع طلبات http ، وتحدد رقم ذاكرة التخزين المؤقت من IRule ، إلى أين تذهب ، وتسمح لحركة المرور بالذهاب إلى هناك. في الوقت نفسه ، يقوم بإجراء فحوصات صحية ، وفي حالة عدم توفر جهاز ، قمنا بعمله بحيث انتقلت حركة المرور إلى خادم نسخ احتياطي واحد في ذلك الوقت. من وجهة نظر التكوين ، هناك بالطبع بعض الفروق الدقيقة ، ولكن بشكل عام كل شيء بسيط للغاية: نحن نصف خريطة ، رقم معين يتوافق مع عنوان IP الخاص بنا على الشبكة ، ونقول إننا سنستمع على المنافذ 80 و 443 ، نقول إنه إذا كان الخادم غير متاح ، فأنت بحاجة إلى السماح لحركة المرور بالانتقال إلى النسخة الاحتياطية ، في هذه الحالة ، 35 ، وسنصف مجموعة من المنطق حول كيفية تفكيك هذه البنية. كانت المشكلة الوحيدة هي أن اللغة التي تُبرمج بها قطعة الحديد هي لغة Tcl. إذا كان أي شخص يتذكر هذا على الإطلاق ... فهذه اللغة هي لغة للكتابة فقط أكثر من كونها لغة ملائمة للبرمجة:
ماذا حصلنا؟ لقد حصلنا على قطعة من الأجهزة التي تضمن توافرًا عاليًا لبنيتنا التحتية ، وتوجه جميع حركة المرور لدينا ، وتوفر الفحوصات الصحية وتعمل فقط. علاوة على ذلك ، فقد كان يعمل لفترة طويلة: على مدار السنوات العشر الماضية ، لم تكن هناك شكاوى بشأنه. بحلول بداية عام 10 ، كنا نعرض بالفعل حوالي 2018 ألف صورة في الثانية. هذا في مكان ما حوالي 80 جيجابت من حركة المرور من كلا مركزي البيانات لدينا.
لكن…
في بداية عام 2018 ، رأينا صورة قبيحة على المخططات: لقد زاد وقت إعادة الصور بشكل واضح. ولم يعد يناسبنا. تكمن المشكلة في أن هذا السلوك كان مرئيًا فقط في ذروة حركة المرور - بالنسبة لشركتنا ، هذه الليلة من الأحد إلى الاثنين. لكن بقية الوقت كان النظام يتصرف كالمعتاد ، ولا توجد علامات على الكسر.
ومع ذلك ، كان لا بد من حل المشكلة. حددنا الاختناقات المحتملة وبدأنا في القضاء عليها. بادئ ذي بدء ، قمنا بالطبع بتوسيع الروابط الصاعدة الخارجية ، وقمنا بمراجعة كاملة للوصلات الصاعدة الداخلية ، ووجدنا كل الاختناقات المحتملة. لكن كل هذا لم يعط نتيجة واضحة ، المشكلة لم تختف.
كان هناك اختناق محتمل آخر هو أداء مخابئ الصور نفسها. وقررنا أن المشكلة ربما تقع عليهم. حسنًا ، لقد قمنا بتوسيع الأداء - بشكل أساسي ، منافذ الشبكة في ذاكرة التخزين المؤقت للصور. لكن مرة أخرى ، لم يلاحظ أي تحسن واضح. في النهاية ، أولينا اهتمامًا وثيقًا لأداء LTM نفسها ، وهنا رأينا صورة حزينة على الرسوم البيانية: يبدأ تحميل جميع وحدات المعالجة المركزية بسلاسة ، ولكن بعد ذلك يقع على الرف بحدة. في الوقت نفسه ، تتوقف LTM عن الاستجابة بشكل كافٍ لفحوصات الصحة والارتباطات الصاعدة وتبدأ في إيقاف تشغيلها بشكل عشوائي ، مما يؤدي إلى تدهور خطير في الأداء.
أي أننا حددنا مصدر المشكلة ، وحددنا عنق الزجاجة. يبقى أن نقرر ما سنفعله.
أول شيء واضح يمكننا القيام به هو تحديث LTM نفسها بطريقة ما. ولكن هناك بعض الفروق الدقيقة هنا ، لأن هذه المكواة فريدة تمامًا ، فلن تذهب إلى أقرب سوبر ماركت وشرائها. إنه عقد منفصل ، عقد ترخيص منفصل ، وسيستغرق الكثير من الوقت. الخيار الثاني هو أن تبدأ في التفكير بنفسك ، وتوصل إلى حل خاص بك على مكوناتك الخاصة ، ويفضل أن يكون ذلك باستخدام برنامج مفتوح المصدر. يبقى فقط أن نقرر ما الذي سنختاره بالضبط لهذا ومقدار الوقت الذي سنقضيه في حل هذه المشكلة ، لأن المستخدمين لم يتلقوا الصور. لذلك ، من الضروري القيام بكل هذا بسرعة كبيرة جدًا ، كما يمكن للمرء أن يقول - بالأمس.
نظرًا لأن المهمة بدت مثل "افعل شيئًا بأسرع ما يمكن وباستخدام الأجهزة التي لدينا" ، فإن أول شيء اعتقدناه هو إزالة بعض الأجهزة التي ليست أقوى من المقدمة ، ووضع Nginx هناك ، والذي نعرف كيف للعمل ، ومحاولة تنفيذ كل نفس المنطق الذي كانت تفعله قطعة الحديد. هذا ، في الواقع ، تركنا قطعة الأجهزة الخاصة بنا ، وقمنا بتثبيت 4 خوادم أخرى كان علينا تهيئتها ، وإنشاء مجالات خارجية لهم عن طريق القياس على ما كان عليه قبل 10 سنوات ... لقد فقدنا القليل من التوفر إذا سقطت هذه الأجهزة ، ولكن ، مع ذلك ، حل مشكلة مستخدمينا محليًا بدرجة أقل.
وفقًا لذلك ، يظل المنطق كما هو: نقوم بتثبيت Nginx ، ويمكنه إلغاء تحميل SSL ، ويمكننا بطريقة ما برمجة منطق التوجيه ، والتحقق من صحة التكوينات ، وببساطة تكرار المنطق الذي كان لدينا من قبل.
نجلس لكتابة التكوينات. في البداية بدا أن كل شيء كان بسيطًا للغاية ، ولكن لسوء الحظ ، من الصعب جدًا العثور على أدلة لكل مهمة. لذلك ، لا ننصحك ببساطة بـ google "كيفية تكوين Nginx للصور": من الأفضل الرجوع إلى الوثائق الرسمية ، والتي ستوضح الإعدادات التي يجب لمسها. لكن من الأفضل اختيار معلمة محددة بنفسك. حسنًا ، إذن كل شيء بسيط: نصف الخوادم التي لدينا ، نصف الشهادات ... لكن الشيء الأكثر إثارة للاهتمام هو ، في الواقع ، منطق التوجيه نفسه.
في البداية ، بدا لنا أننا نصف موقعنا ببساطة ، ونطابق رقم ذاكرة التخزين المؤقت للصور فيه ، ونصف بأيدينا أو منشئ المحتوى عدد المنبع الذي نحتاجه ، وفي كل اتجاه ، نشير إلى الخادم الذي يجب أن تذهب إليه حركة المرور ، و خادم النسخ الاحتياطي - في حالة عدم توفر الخادم الرئيسي:
لكن ، على الأرجح ، إذا كان كل شيء بهذه البساطة ، فسنرجع إلى المنزل ولا نخبر شيئًا. لسوء الحظ ، مع الإعدادات الافتراضية لـ Nginx ، والتي ، بشكل عام ، تم إجراؤها على مدار سنوات عديدة من التطوير وليس تمامًا لهذه الحالة ... يبدو التكوين كما يلي: في حالة وجود خطأ في الطلب أو انتهاء مهلة بعض خوادم upstream ، فإن Nginx دائمًا يحول حركة المرور إلى المرحلة التالية. في الوقت نفسه ، بعد الفشل الأول ، سيتم أيضًا إيقاف تشغيل الخادم في غضون 10 ثوانٍ ، سواء عن طريق الخطأ أو عن طريق المهلة - لا يمكن تكوين هذا بأي شكل من الأشكال. بمعنى ، إذا قمنا بإزالة أو إعادة تعيين خيار المهلة في التوجيه الرئيسي ، فعندئذٍ ، على الرغم من أن Nginx لن يعالج هذا الطلب ويستجيب لبعض الأخطاء غير الجيدة ، فسيتم إيقاف تشغيل الخادم.
لتجنب ذلك فعلنا شيئين:
أ) منعوا Nginx من القيام بذلك يدويًا - وللأسف ، الطريقة الوحيدة للقيام بذلك هي ببساطة ضبط إعدادات الفشل القصوى.
ب) تذكرنا أنه في مشاريع أخرى ، نستخدم وحدة تسمح لك بإجراء فحوصات طبية أساسية - وفقًا لذلك ، قمنا بإجراء فحوصات صحية متكررة بحيث يكون لدينا أقل وقت توقف في حالة وقوع حادث.
لسوء الحظ ، هذا ليس كل شيء أيضًا ، لأن الأسبوعين الأولين من تشغيل هذا المخطط أظهر أن فحص صحة TCP هو أيضًا شيء غير موثوق به: لا يمكن تشغيل Nginx أو Nginx في الحالة D على الخادم الرئيسي وفي في هذه الحالة ، ستقبل النواة الاتصال ، وسوف يمر فحص الصحة ، لكنه لن يعمل. لذلك ، استبدلناها على الفور بفحص صحة http ، وقمنا بعمل واحد محدد ، إذا كان يعطي بالفعل 200 ، فكل شيء يعمل في هذا البرنامج النصي. يمكنك عمل منطق إضافي - على سبيل المثال ، في حالة خوادم التخزين المؤقت ، تحقق من تثبيت نظام الملفات بشكل صحيح:
وهذا يناسبنا ، باستثناء أنه في الوقت الحالي كررت الدائرة تمامًا ما فعلته قطعة الحديد. لكننا أردنا أن نفعل ما هو أفضل. في السابق ، كان لدينا خادم نسخ احتياطي واحد ، وربما لا يكون هذا جيدًا جدًا ، لأنه إذا كان لديك مائة خادم ، فعند سقوط عدة خوادم في وقت واحد ، فمن غير المرجح أن يتعامل خادم نسخ احتياطي واحد مع التحميل. لذلك ، قررنا توزيع الحجز بين جميع الخوادم: لقد قمنا ببساطة بعمل المنبع المنفصل الآخر ، وسجلنا جميع الخوادم هناك مع معلمات معينة وفقًا للحمل الذي يمكن أن تخدمه ، وأضفنا نفس الفحوصات الصحية التي أجريناها من قبل:
نظرًا لأنه لا يمكنك الانتقال إلى المنبع الآخر داخل المنبع ، كان من الضروري التأكد من أنه إذا كان المنبع الرئيسي ، الذي كتبنا فيه ببساطة ذاكرة التخزين المؤقت الصحيحة والضرورية للصور ، غير متاح ، فقد ذهبنا ببساطة إلى الرجوع من خلال error_page ، من حيث ذهبنا إلى المنبع الاحتياطي:
وبعد إضافة أربعة خوادم حرفيًا ، حصلنا على هذا: لقد استبدلنا جزءًا من الحمل - تمت إزالته من LTM إلى هذه الخوادم ، وقمنا بتنفيذ نفس المنطق باستخدام الأجهزة والبرامج القياسية ، وحصلنا على الفور على مكافأة يمكن توسيع نطاق هذه الخوادم ، لأنها يمكن أن تكون كذلك ببساطة أدخل بقدر ما تحتاج. حسنًا ، الشيء السلبي الوحيد هو أننا فقدنا التوافر الكبير للمستخدمين الخارجيين. لكن في ذلك الوقت كان علي التضحية بهذا ، لأنه كان من الضروري حل المشكلة على الفور. لذلك ، قمنا بإزالة جزء من الحمل ، كان حوالي 40٪ في ذلك الوقت ، وتحسنت LTM ، وبعد أسبوعين من بدء المشكلة ، بدأنا في تقديم 45 ألف طلب في الثانية ، ولكن 55 ألف طلب. في الواقع ، لقد حققنا نموًا بنسبة 20٪ - ومن الواضح أن هذا هو عدد الزيارات التي لم نعطها للمستخدم. وبعد ذلك ، بدأوا في التفكير في كيفية حل المشكلة المتبقية - لضمان توافر خارجي مرتفع.
توقفنا قليلاً ناقشنا خلاله الحل الذي سنستخدمه لهذا الغرض. كانت هناك مقترحات لضمان الموثوقية باستخدام DNS ، بمساعدة بعض البرامج النصية المكتوبة ذاتيًا ، وبروتوكولات التوجيه الديناميكية ... كان هناك العديد من الخيارات ، ولكن أصبح من الواضح بالفعل أنه من أجل عودة موثوقة حقًا للصور ، تحتاج إلى تقديم طبقة أخرى من شأنها مراقبة هذا. لقد أطلقنا على هذه الآلات صور مديري. البرنامج الذي اعتمدنا عليه كان Keepalived:
بادئ ذي بدء ، ما يتكون منه Keepalived. الأول هو بروتوكول VRRP ، المعروف على نطاق واسع بين المسوقين الشبكيين ، والموجود على معدات الشبكة التي توفر التسامح مع الخطأ لعنوان IP الخارجي الذي يتصل به العملاء. الجزء الثاني هو IPVS ، خادم IP الظاهري ، لتحقيق التوازن بين أجهزة توجيه الصور وتوفير التسامح مع الخطأ في هذا المستوى. والثالث هو الفحوصات الصحية.
لنبدأ بالجزء الأول: VRRP - كيف يبدو؟ هناك عنوان IP افتراضي معين ، له إدخال في نظام أسماء النطاقات badoocdn.com ، حيث يتصل العملاء. في وقت ما ، لدينا عنوان IP على خادم واحد. تعمل الحزم المحفوظة بين الخوادم باستخدام بروتوكول VRRP ، وإذا اختفى الخادم الرئيسي من الرادار - تمت إعادة تشغيل الخادم أو أي شيء آخر ، فسيقوم خادم النسخ الاحتياطي تلقائيًا برفع عنوان IP هذا - لا يلزم اتخاذ إجراءات يدوية. يختلف الرئيسي والنسخ الاحتياطي ، والأولوية بشكل أساسي: فكلما زادت ، زادت احتمالية أن تصبح الآلة هي الشركة الرئيسية. ميزة كبيرة جدًا هي أنك لا تحتاج إلى تكوين عناوين IP على الخادم نفسه ، يكفي وصفها في التكوين ، وإذا كانت عناوين IP تحتاج إلى بعض قواعد التوجيه المخصصة ، فسيتم وصف ذلك مباشرة في التكوين ، في نفس بناء الجملة كما هو موضح في حزمة VRRP. لن تقابل أي أشياء غير مألوفة.
كيف تبدو في الممارسة؟ ماذا يحدث إذا تعطل أحد الخوادم؟ بمجرد اختفاء السيد ، يتوقف النسخ الاحتياطي لدينا عن تلقي الترقيات ويصبح تلقائيًا سيدًا. بعد مرور بعض الوقت ، قمنا بإصلاح النسخة الرئيسية ، وأعدنا تشغيلها ، ورفعنا Keepalived - إعلانات ذات أولوية أعلى من وصول النسخة الاحتياطية ، والنسخ الاحتياطي يعود تلقائيًا ، ويزيل عناوين IP من نفسه ، ولا يلزم اتخاذ إجراءات يدوية.
وبالتالي ، فقد حرصنا على تحمل الخطأ لعنوان IP الخارجي. الجزء التالي هو موازنة حركة المرور بطريقة ما من عنوان IP خارجي إلى أجهزة توجيه الصور التي تنهيها بالفعل. مع موازنة البروتوكولات ، كل شيء واضح بما فيه الكفاية. هذا إما أن يكون مستديرًا بسيطًا ، أو أشياء أكثر تعقيدًا ، wrr ، اتصال قائمة وما إلى ذلك. هذا موصوف أساسًا في الوثائق ، ولا يوجد شيء خاص به. لكن طريقة التسليم ... هنا سوف نتناول المزيد من التفاصيل - لماذا اخترنا واحدًا منهم. هذه هي NAT والتوجيه المباشر و TUN. الحقيقة هي أننا وضعنا على الفور عودة 100 جيجابت من حركة المرور من المواقع. هذا إذا اكتشفت ذلك ، فأنت بحاجة إلى 10 بطاقات جيجابت ، أليس كذلك؟ بطاقات 10 جيجابت في خادم واحد - هذا بالفعل يتجاوز ، على الأقل ، مفهومنا عن "المعدات القياسية". ثم تذكرنا أننا لا نتخلى عن بعض حركة المرور فحسب ، بل نعطي صورًا.
ما هي الميزة؟ - فرق كبير بين حركة المرور الواردة والصادرة. حركة المرور الواردة صغيرة جدًا ، والحركة الصادرة كبيرة جدًا:
إذا نظرت إلى هذه الرسوم البيانية ، يمكنك أن ترى أنه في الوقت الحالي يتم إرسال حوالي 200 ميغا بايت في الثانية إلى المخرج ، وهذا هو اليوم الأكثر شيوعًا. نعيد 4,500 ميجابايت في الثانية ، النسبة حوالي 1/22. من الواضح بالفعل أنه بالنسبة لنا لتوفير حركة مرور صادرة بالكامل إلى 22 خادمًا عاملاً ، يكفي واحد يقبل هذا الاتصال. هنا تأتي خوارزمية التوجيه المباشر ، خوارزمية التوجيه ، لمساعدتنا.
كيف تبدو؟ مدير الصور لدينا ، وفقًا لجدولته ، ينقل الاتصالات إلى أجهزة توجيه الصور. لكن أجهزة توجيه الصور ترسل حركة عكسية مباشرة إلى الإنترنت ، وترسلها إلى العميل ، ولا تعود من خلال مدير الصور ، وبالتالي ، مع الحد الأدنى من عدد الأجهزة ، نقدم التسامح الكامل مع الخطأ وضخ كل حركة المرور. في التكوينات ، يبدو الأمر على النحو التالي: نحدد الخوارزمية ، وفي حالتنا هي rr بسيطة ، ونوفر طريقة التوجيه المباشر ، ثم نبدأ في سرد جميع الخوادم الحقيقية ، وعددها لدينا. الذي سيحدد هذه الحركة. في حالة وجود خادم واحد أو اثنين أكثر ، تظهر عدة خوادم هناك ، تظهر هذه الحاجة - نضيف ببساطة هذا القسم إلى التكوين ولا تقلق كثيرًا. من جانب الخوادم الحقيقية ، من جانب جهاز توجيه الصور ، تتطلب هذه الطريقة الحد الأدنى من التكوين ، وهي موصوفة تمامًا في الوثائق ، ولا توجد عيوب هناك.
ما هو ممتع بشكل خاص هو أن مثل هذا الحل لا يعني تغييرًا جذريًا في الشبكة المحلية ، كان هذا مهمًا بالنسبة لنا ، وكان علينا حلها بأقل تكلفة. إذا نظرتم إلى ثم سنرى كيف يبدو. هنا لدينا خادم افتراضي معين ، على المنفذ 443 ، يستمع ، ويقبل الاتصال ، ويتم سرد جميع الخوادم العاملة ، ومن الواضح أن الاتصال ، زائد أو ناقص ، هو نفسه. إذا نظرنا إلى الإحصائيات على نفس الخادم الظاهري ، لدينا حزم واردة واتصالات واردة ، ولكن ليس لدينا أي اتصالات صادرة على الإطلاق. الاتصالات الصادرة تذهب مباشرة إلى العميل. حسنًا ، تمكنا من عدم التوازن. الآن ، ماذا يحدث إذا فشل أحد أجهزة توجيه الصور لدينا؟ بعد كل شيء ، الحديد هو الحديد. قد يدخل في حالة من الذعر في النواة ، وقد ينكسر ، وقد ينفد مصدر الطاقة. أي شئ. هذا هو الغرض من الفحوصات الصحية. يمكن أن تكون بسيطة مثل التحقق من كيفية فتح المنفذ معنا ، أو بعض البرامج الأكثر تعقيدًا ، حتى بعض البرامج النصية المكتوبة ذاتيًا والتي ستتحقق حتى من منطق الأعمال.
توقفنا في مكان ما في المنتصف: لدينا طلب https لموقع معين ، يتم استدعاء البرنامج النصي إذا استجاب مع استجابة 200 ، نعتقد أن كل شيء على ما يرام مع هذا الخادم ، وأنه على قيد الحياة ويمكن تشغيله بسهولة تامة .
كيف يبدو هذا ، مرة أخرى ، في الممارسة. تم إيقاف تشغيل الخادم ، المسموح به للصيانة - وميض BIOS ، على سبيل المثال. في السجلات ، لدينا على الفور مهلة ، نرى السطر الأول ، ثم بعد ثلاث محاولات يتم تمييزه على أنه "فاشل" ، ويتم إزالته ببساطة من القائمة.
السلوك الثاني ممكن أيضًا ، عندما يتم تعيين VS ببساطة على الصفر ، ولكن في حالة إرجاع صورة ، هذا لا يعمل بشكل جيد. يرتفع الخادم ، ويبدأ Nginx هناك ، وتتفهم الفحوصات الصحية فورًا أن الاتصال يمر ، وأن كل شيء على ما يرام ، ويظهر الخادم في قائمتنا ، ويبدأ التحميل على الفور على الفور. لا توجد إجراءات يدوية مطلوبة من المسؤول المناوب. في الليل ، أعيد تشغيل الخادم - لا يتصل بنا قسم المراقبة بخصوص هذا الأمر في الليل. إنهم يعلمونك بما حدث ، كل شيء على ما يرام.
لذلك ، بطريقة بسيطة إلى حد ما ، بمساعدة عدد صغير من الخوادم ، قمنا بحل مشكلة التسامح الخارجي مع الخطأ.
يبقى أن نقول إن كل هذا ، بالطبع ، يحتاج إلى المراقبة. بشكل منفصل ، تجدر الإشارة إلى أن Keepalivede ، كبرنامج مكتوب منذ وقت طويل جدًا ، لديه مجموعة من الطرق لمراقبته ، سواء باستخدام الشيكات عبر DBus و SMTP و SNMP و Zabbix القياسي. بالإضافة إلى ذلك ، يعرف هو نفسه كيفية كتابة الرسائل إلى كل عطسة تقريبًا ، ولكي نكون صادقين ، فكرنا في وقت ما في إيقاف تشغيله ، لأنه يكتب الكثير من الرسائل لأي مفتاح مرور ، وإدراج ، لكل IP-shnik و هكذا. بالطبع ، إذا كان هناك الكثير من الخوادم ، فيمكنك إغراق نفسك بهذه الرسائل. باستخدام الأساليب القياسية ، نراقب nginx على أجهزة توجيه الصور ، ولم تختف مراقبة الأجهزة. بالطبع ، ننصح بأمرين آخرين: أولاً ، الفحوصات الصحية الخارجية وإمكانية الوصول ، لأنه حتى لو نجح كل شيء ، في الواقع ، من الممكن ألا يتلقى المستخدمون الصور بسبب مشاكل مع مقدمي خدمات خارجيين أو شيء أكثر تعقيدًا. من المفيد دائمًا الاحتفاظ بجهاز منفصل في مكان ما على شبكة أخرى ، في أمازون أو في أي مكان آخر ، يمكنه إجراء اختبار اتصال لخوادمك من الخارج ، كما أنه من المفيد استخدام إما اكتشاف الشذوذ ، لأولئك الذين يجيدون التعلم الآلي الصعب ، أو البسيط المراقبة ، على الأقل من أجل تتبع ما إذا كانت الطلبات قد انخفضت بشكل حاد ، أو العكس ، قد نمت. إنه مفيد أيضًا.
للتلخيص: لقد استبدلنا ، في الواقع ، الحل الحديدي ، الذي توقف في مرحلة ما عن ملاءمتنا ، بنظام بسيط إلى حد ما يفعل كل شيء بالطريقة نفسها ، أي أنه يوفر إنهاء حركة مرور HTTPS والمزيد من التوجيه الذكي بالصحة اللازمة -الفحوصات. لقد قمنا بزيادة استقرار هذا النظام ، أي أننا لا نزال نتمتع بإتاحة عالية لكل طبقة ، بالإضافة إلى أننا حصلنا على مكافأة أنه من السهل جدًا قياس كل ذلك في كل طبقة ، لأن هذا جهاز قياسي مع برنامج قياسي ، وهذا هو ، من خلال القيام بذلك ، قمنا بتبسيط تشخيص المشاكل المحتملة.
ماذا انتهى بنا؟ واجهتنا مشكلة في عطلة يناير من عام 2018. خلال الأشهر الستة الأولى ، بينما كنا نضع هذا المخطط موضع التنفيذ ، ونوسع نطاقه ليشمل كل حركة المرور ، من أجل إزالة كل حركة المرور من LTM ، نمت فقط في حركة المرور في مركز بيانات واحد من 40 جيجابت إلى 60 جيجابت ، وفي نفس الوقت الوقت طوال عام 2018 بأكمله كان قادرًا على إعطاء ما يقرب من ثلاث مرات صورًا في الثانية.
المصدر: www.habr.com