البحث في الموقع

مقدمة يعدّ توزيع الحِمل Load balancing مكوِّنا أساسيًّا في البنى التحتية عالية التوفر Highly-available، إذ يكثر استخدامه لتحسين الأداء والثبات في مختلف الخدمات على الشبكة؛ بما في ذلك مواقع الوِب، التطبيقات، قواعد البيانات وغيرها. يقوم مبدأ توزيع الحِمل على الاعتماد على أكثر من خادوم وتوزيع العمل المطلوب إنجازه بينها. يوضّح المخطّط التالي بنية تحتية لموقع وِب بدون توزيع حِمل. يتصل الزائر في هذا المثال بخادوم الوِب مباشرة، على العنوان yourdomain.com. إن حدث خلل يجعل الخادوم المضيّف للموقع yourdomain.com غير قادر على العمل فإن الوصول إلى هذا الموقع لن يكون متاحا. علاوةً على ذلك؛ إن أراد الكثير من الزوّار الوصول إلى الموقع في نفس اللحظة ولم يستطع الخادوم التعامل معهم بالسرعة المطلوبة فإن تنزيل صفحات الموقع سيصير بطيئًا، وربما يصبح خارج الخدمة. يمثّل الخادوم في هذه الحالة نقطة إخفاق Point of failure بالنسبة للبنية التحتية، فتوقفه عن العمل يجعل البنية بجميع مكوّناتها خارج الخدمة. يمكن التخفيف من تأثير نقطة الإخفاق الوحيدة هذه بإضافة موزّع حِمل Load balancer وخادوم وِب آخر على الأقل إلى السند الخلفي Backend. تقدّم جميع الخواديم في السند الخلفي نفس المحتوى، فيحصُل الزائر بالتالي على محتوى متجانس بغضّ النظر عن خادوم الوِب الذي أجاب عن طلبه. يتصل الزائر في المخطط أعلاه أولا بموزّع الحِمل الذي يوجّه طلب الزائر إلى خادوم في السند الخلفي. يجيب الخادوم الذي وُجِّه إليه الطلبُ الزائرَ مباشرة. يصبح موزّع الحِمل في هذه الحالة هو نقطة الإخفاق، بمعنى أن توقفه عن العمل يجعل كامل البنية التحتية تتوقف عن العمل. يمكن التغلب على هذا المشكل بإدراج موزّع حِمل ثان؛ إلا أننا سنشرح - قبل أن نناقش هذه الإمكانية - كيفية عمل موزّع الحِمل. ما نوع حركة البيانات التي يمكن لموزع الحمل التعامل معها؟ يستخدم مديرو الأنظمة موزّعات الحمل لإنشاء قواعد توجيه تتعامل أساسا مع أنواع البيانات الأربعة التالية: HTTP: تُوجَّه حركة البيانات في هذه الحالة اعتمادًا على الآليات المعيارية لميثاق HTTP. يعيّن موزّع الحِمل قيم الترويسات X-Forwarded-For، X-Forwarded-Proto وX-Forwarded-Port من أجل تمرير المعلومات الأصلية عن الطلب، أي تلك القادمة من الزائر، إلى الخادوم الذي سيردّ على الطلب . HTTPS: يشبه هذا النوع النوعَ السابق، مع فرق أنه يستخدم التعميّة Encryption. تُعالَج البيانات المعمّاة بإحدى طريقتيْن: تمرير SSL +(أو SSL Passthrough)وتعتمد هذه الطريقة على الاحتفاظ بالتعميّة إلى أن تصل البيانات للخادوم الذي سيجيب على الطلب؛ أما الثانيّة فتُدعى إنهاء SSL (أو SSL Termination) ويوضَع عبء التعميّة وفكّها على موزّع الحمل، غير أن البيانات بين موزّع الحمل وخادوم الوِب تُنقَل دون تعميّة، عكس الطريقة الأولى. TCP: يمكن استخدام ميثاق TCP لتوزيع حركة البيانات بين تطبيقات لا تستخدم HTTP أو HTTPS؛ مثلا بين عنقود Cluster من خواديم قواعد البيانات. UDP: تدعم بعض موزعات الحمل الحديثة توجيه البيانات الخاصّة بمواثيق الإنترنت التي تستخدم حزم UDP مثل نظام أسماء النطاقات DNS وsyslogd. تعرّف قواعدُ التوجيه الميثاقَ والمنفَذ Port على موزّع الحمل وتربطهما بميثاق ومنفَذ موجودين على الخادوم الذي يختاره موزّع الحِمل للإجابة على طلب الزائر. كيف يختار موزّع الحمل خادوما في السند الخلفي؟ يختار موزّع الحمل الخادوم الذي سيتولّى الإجابة على الطلب بناء على عاملَيْن: أولاً؛ يتأكّد موزّع الحمل من قدرة الخادوم على الإجابة على الطلبات التي ترده، ثم يستخدم مجموعة من القواعد المضبوطة مسبقا لاختيار خادوم من بين الخواديم القادرة على الإجابة على الطلب. التحقق من قدرة الخادوم لا يجوز أن توجِّه موزعات الحِمل الطلبات إلى خادوم ليست لديه القدرة على التعامل معها. يراقب موزّع الحمل حالة الخواديم في السند الخلفي بمحاولة الاتصال بها مستخدما الميثاق والمنفَذ المعرَّفيْن في قواعد التوجيه المضبوطة عليه. إن أخفق خادوم في الإجابة على محاولات موزّع الحمل للاتصال به فإن موزع الحمل يعدّه غير قادر على معالجة الطلبات، ويحذفه بالتالي من قائمة الخواديم لديه، فلا يُوجِّه له أي طلب؛ إلى أن يجيب بطريقة مناسبة على محاولات الاتّصال اللاحقة. خوارزميّات توزيع الحِمل تحدّد خوارزميّة خادوما - من بين الخواديم الجاهزة للإجابة - لتوجيه الطلب إليه. تعدّ الخوارزميّات التالية من بين الخوارزميّات الأكثر استخداما في توزيع الحمل: الاختيار الدوري Round robin: تُختار الخواديم في هذه الخوارزميّة بالتتالي. يوجّه موزع الحمل عند استخدام هذه الخوارزمية أول طلب إلى أول خادوم في قائمته، ثم عند وصول الطلب الثاني يوجّهه إلى الخادوم الموالي، وهكذا إلى أن يصل لآخر خادوم في القائمة فيعود للأول. الأقل اتصالات Least connections: يُنصَح بهذه الخوارزميّة عندما تأخذ جلسات الاتصال Sessions آمادا طويلة. يختار الموزّع في هذه الحالة الخادوم ذا الاتصالات النشطة اﻷقل عددا. حسب المصدر Source: يختار موزّع الحمل عند استخدام هذه الخوارزميّة الخادومَ الذي سيجيب على الطلب بناءً على عنوان IP المصدَر، مثلا؛ عنوان IP الزائر. يعني استخدامُ هذه الخوارزميّة أن طلبات زائر معيَّن ستُوجَّه دوما إلى نفس الخادوم. تختلف الخوارزميّات المتاحة للاختيار بينها، حسب التقنيات المستخدمة في موزّع الحمل. كيف تتعامل موزّعات الحِمل مع الحالة State؟ تطلب بعض التطبيقات أن يواصل الزائر الاتصال بنفس الخادوم خلال جلسة الاتصال الواحدة. يمكن عند الاقتضاء استخدام خوارزميّة الاختيار حسب المصدر التي تركّز على عنوان الزائر. توجد طريقة أخرى لتلبية هذه الحاجة، وذلك بتنفيذها على مستوى تطبيق الوِب عبر الجلسات الملتصقة Sticky sessions. إذ يعيّن موزّع الحمل ملف تتبّع Cookie خاصّ بكل جلسة ثم يوجّه الطلبات التابعة لنفس الجلسة إلى نفس الخادوم، اعتمادا على ملف التتبع. تكرار موزّعات الحمل ذكرنا سابقا أن موزّع الحِمل يمكن أن يمثّل نقطة إخفاق إن كان وحيدا، وأنه يمكن تصحيح هذه الوضعية بإضافة موزّع حمل ثان. يتصل موزّع الحِمل الجديد بالأوّل لتشكيل عنقود من خادومَيْ توزيع حِمل يراقب كلّ منهما الآخر ويتأكّد من جاهزيّته لتلقي الطلبات وتوجيهها إلى الخادوم المناسب في المنتهى الخلفي. يمكن لكلٍّ من الخادوميْن في هذه الحالة اكتشاف إخفاق الآخر وعودته إلى العمل. يُحيل نظام أسماء النطاقات DNS المستخدمين إلى موزّع الحِمل الثاني في حال توقّف الأول عن العمل؛ إلا أنّ سجلات أسماء النطاقات يمكن أن تأخذ وقتا حتى يكتمل تحديثها لدى المستخدمين في جميع أنحاء العالم. يلجأ كثير من مديري الأنظمة، للتغلّب على هذا المشكل، إلى وسائل تتيح إعادة تعيين عناوين IP بمرونة، مثل عناوين IP العائمة Floating IPs. تتخلّص هذه الوسائل من مشاكل انتشار السجلات وتحديث التخبئة في سجلات DNS بتوفير عنوان IP ثابت يمكن إعادة تعيينه حسب الحاجة، وبسرعة. لا تغيّر إعادة تعيين IP من العنوان الذي تشير إليه سجلات DNS، إلا أنها تجعل من الممكن نقل عنوان IP نفسه بين خواديم مختلفة. ترجمة - بتصرف - لمقال What is Load Balancing? لصاحبته Melissa Anderson.

يعرض هذا الدّرس والذي يُعتبر الأول من سلسلة ذات ستة أجزاء كيفية إعداد بنية تحتية لتطبيق مكوَّن من خواديم عدة، انطلاقا من الصفر. سيحتوي الإعداد النهائي على آليات للنسخ الاحتياطي Backup، المراقبة Monitoring، نُظُم مركزية للسجلات Centralized logging مما يعزز من إمكانية تشخيص المشاكل واستعادة إعدادات التطبيق عند الحاجة. الهدف الأسمى هو إنشاء نظام إدارة قائم بذاته، والتعريف بأهم المفاهيم والاعتبارات العملية التي ينبغي التنبه لها عند إعداد خادوم موجَّه للإنتاج Production server. ملحوظة: توجد -عادة- أثناء تطوير وإعداد البرامج بيئة إنتاج وبيئة اختبار (أو أكثر). في بيئة الاختبار يستخدم قليلون التطبيق، ويكون المستخدمون في هذه الحالة غالبا مطورين يبحثون عن علل لترقيعها. في الجانب الآخر فإن التطبيق في بيئة الإنتاج يستخدمه المستهدَفون الحقيقيون بالمنتَج (التطبيق)؛ لذا يجب أن يعمل بكفاءة وسلاسة. قراءة الدّرس التالي وفهمه سيساعدك في المضي قدما مع هذا الدّرس: خمسة إعدادات شائعة لتطبيقات الوب.يقدم المقال خطوطا عريضة لإعداد تطبيق موجَّه للإنتاج، بينما يوضح هذا الدّرس كيفية التخطيط لتطبيق نموذجي وإعداده من البداية إلى النهاية. المأمول هو أن يساعدك الدرس في التخطيط لإعداد خادومك الخاص ثم تنفيذ الإعداد حتى ولو كنت تشغِّل حزمة تطبيقات مختلفة تماما. يحيل الدّرس في أحيان كثيرة، نظرا لأنه يغطي مواضيع مختلفة من إدارة النظم، إلى شروحات مفصلة ضمن مقالات أخرى تقدم معلومات إضافية. الهدفسنحصل بنهاية مجموعة المقالات هذه على خادوم إنتاج معدّ لتشغيل تطبيق PHP، ووردبريس على سبيل المثال، يمكن الوصول إليه عبر العنوان https://www.example.com/. سنعدّ أيضا خواديم إضافية لدعم خواديم التطبيق في بيئة الإنتاج. سيبدو الإعداد النهائي على النحو التالي (لا تظهر خواديم نظام إدارة النطاقات DNS الداخلية ولا النسخ الاحتياطية البعيدة في الصورة أدناه): نعُدُّ الخواديم الموجودة في مربع التطبيق ضرورية ليعمل التطبيق على النحو المرجو. تعمل العناصر المتبقية - النسخ الاحتياطية، المراقبة، والسجلات - بجانب خطة الاستعادة وخادوم النسخ الاحتياطي البعيد؛ على دعم خادوم الإنتاج. سنثبت كل عنصر على خادوم Ubuntu 14.04 منفصل ضمن نفس الحيز الجغرافي مع تفعيل التشبيك الخاص Private networking. نستخدم أسماء المستضيفات Hostnames لتمييز الخواديم المكوِّنة للتطبيق: lb1: موزع الحمل HAProxy، يمكن الوصول إليه عبر العنوان https://www.example.com/.app1: خادوم تطبيقات Apache و PHP.app2: خادوم تطبيقات Apache و PHP.db1: خادوم لقاعدة بيانات MySQL.من المهم التنبيه إلى أنه تم اختيار هذا النوع من الإعداد لتوضيح كيف يمكن لعناصر تطبيق أن تُنشأ على خواديم عدة؛ يجب أن يُخصَّص إعداد تطبيقك بناء على احتياجاتك. توجد نقطة إخفاق Point of failure وحيدة في هذا الإعداد، ويمكن التغلب عليها بتركيب موزع حمل إضافي (وخادوم DNS دوري) ومضاعفة قاعدة البيانات؛ وهو ما لن تطرق إليه في هذا الدرس. نميز العناصر الداعمة للتطبيق بأسماء المستضيفات التالية: النسخ الاحتياطية backups: خادوم النسخ الاحتياطي Bacula.المراقبة monitoring: خادوم Nagios.السجلات logging: سجلات مركزية باستخدام حزمة برمجيات مكونة من Kibana (ELK)، Logstash و Elasticsearch.توجد عناصر أخرى لا تظهر في الصورة، وهي: ns1: وهو خادومنا الرئيس لنظام أسماء النطاقات. نستخدم Bind لهذا الغرض.ns2: وهو الخادوم الثانوي لنظام أسماء النطاقات. نستخدم Bind.remotebackups: خادوم بعيد يوجد في منطقة جغرافية أخرى نحفظ عليه نسخ Bacula الاحتياطية احترازا من كارثة تحل بمركز البيانات الذي يوجد فيه التطبيق.يمكنك أيضا استخدام عنوان IP عائم Floating IP؛ وهو عبارة عن عنوان IP ثابت يُتاح للعموم الوصول إليه ويمكن توجيهه إلى أحد خواديمك الافتراضية أو بنيتك التحتية المكرَّرة Redundant ثم إطلاق موقعك أو خدمتك باستخدام عنوان IP عمومي وحيد. يمكن بعدها إعادة توجيه العنوان العائم إلى خادوم جديد من أجل بيئة إنتاج أكثر مرونة وأسرع تجاوبا. سنضع أيضا خطط استعادة لكلٍّ من العناصر المكونة للتطبيق. ستكون لدينا، عند بلوغ الهدف النهائي، عشرة خواديم. سننشئها كلَّها في نفس الوقت لتسهيل بعض الأمور مثل إعداد النطاقات؛ ولكن يمكنك إنشاؤها الواحد تلو الآخر حسب الحاجة. شبكة خاصة افتراضية Virtual Private Network (اختياري)إذا أردت تأمين اتصالات الشبكة بين خواديمك فيجب عليك إعداد شبكة خاصة افتراضية VPN. يصبح تأمين نقل البيانات عبر الشبكة بتعميتها Encryption أكثر أهمية إذا كانت البيانات تمر عبر الإنترنت. من منافع استخدام شبكة خاصة افتراضية التحقق من هوية المستضيفات بالاستيثاق منها؛ وهو ما يحمي من المصادر التي لا يُرخص لها الوصول للخدمات. إذا كنت تبحث عن أداة مفتوحة المصدر فيمكنك استخدام OpenVPN واتباع خطوات درس دليلك لكيفية إعداد خادوم OpenVPN على Ubuntu لإعداده. المتطلباتيتوجب أن يكون لدى كل خادوم أوبنتو 14.04 حساب مستخدم بصلاحيات إدارية غير المستخدم الجذر؛ يمكن إعداد مستخدم لهذا الغرض باتّباع الخطوات المشروحة في مقال الإعداد الابتدائي لخادوم أوبنتو 14.04. سننفّذ كل الأوامر باستخدام هذا الحساب. سنفترض أيضا أن لديك معرفة بالمفاهيم الأساسية للأمان في لينكس. إذا رغبت في درس تمهيدي حول الموضوع فيمكن الاطلاع على مقال 7 تدابير أمنيّة لحماية خواديمك. اسم نطاقنفترض في هذا المقال أن الوصول إلى التطبيق يكون عبر اسم نطاق، example.com مثلا. إنْ لم يكن لديك اسم نطاق فبالإمكان شراء واحد من أحد مسجلي أسماء النطاقات Domain name registrar. نحتاج اسم النّطاق ليس فقط لتسهيل الوصول إلى الموقع (مقارنة بعنوان IP المكون من أرقام فقط) بل أيضا للحصول على فوائد التحقق من الهوية والنطاق؛ وهو ما يتيح إمكانية الاستفادة من شهادات SSL التي تعمّي البيانات المنقولة بين التطبيق ومستخدميه. شهادة SSLيعمل بروتوكول TLS/SSL على تعميّة البيانات والتحقق من نطاقها أثناء الاتصال بين التطبيق ومستخدميه؛ لذا سنستخدم شهادة SSL لإضافة هذا الإعداد. في المثال نريد أن يصل المستخدمون إلى الموقع عبر العنوان www.example.com وهي القيمة التي سنحددها في الاسم الشّائع للشهادة Common Name (أو ما يُعرف اختصارًا بـ CN). سنثبت الشهادة على خادومHAProxy (المُسمّى lb1) وهو ما يعني أنه من الأفضل توليد مفاتيح الشهادة وطلب توقيع الشهادة Certificate Signing Request CSR على هذا الخادوم. إذا احتجت للتحقق من الهوية فستحتاج لشراء شهادة SSL. توجد الكثير من سلطات الشهادات Certificate Authorities التجارية التي يمكن شراء شهادة SSL منها. كما توجد إمكانية لاستخدام شهادة مجانية من StartSSL يتوفر أيضا حل بديل يتمثل في التوقيع الذاتي لشهادة SSL بتنفيذ الأمر التالي: sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout ~/www.example.com.key -out ~/www.example.com.crtالخطوات المتبعة للوصول إلى الهدفعرضنا في الفقرات السابقة نظرة عامة على إعداد تطبيقنا الموجَّه للإنتاج، ننتقل الآن لإنشاء خطة عامة نسير وفقها لتحقيق هدفنا. العناصر الأهم هي تلك التي يتكون منها التطبيق؛ لذا يجب أن نشغلها مبكرا. لكن نظرا لأننا نخطط لاستخدام عنونة تعتمد على أسماء النطاقات للاتصالات ضمن الشبكة الخاصة فيجب أن نعد نظام أسماء النطاقات أولا. سنعدّ، بعد الانتهاء من ضبط إعداد النطاقات، الخواديم التي تكون التطبيق من أجل أن يكون جاهزا للتشغيل. يحتاج التطبيق إلى أن تكون قاعدة بيانات مهيَّأة سلفا، كما يتطلب موزع الحِمل أن يكون التطبيق جاهزا. انطلاقا من هذه الاعتبارات فإن إعداد العناصر سيكون حسب الترتيب التالي: خادوم قاعدة البيانات.خواديم التطبيق.موزع الحمل.سيمكننا - بعد إكمال الخطوات السالفة الذكر من أجل إعداد التطبيق - استنباطُ خطة للاستعادة اعتمادا على سيناريوهات عدة. ستكون خطة الاستعادة أساسية في التخطيط لآليات النسخ الاحتياطي. بعد خطة الاستعادة يأتي دور إعداد النسخ الاحتياطي ثم بعد استكماله يمكن ضبط نظام المراقبة من أجل التأكد من أن جميع الخواديم وكل الخدمات في وضعيةِ عمل مقبولة. ثم نأتي للخطوة الأخيرة وهي إنشاء نظام مركزي لتخزين السجلات مما يسمح بعرضها عند الحاجة، تشخيص المشاكل عند حدوثها وتحليلها لتحديد أنواع الاستخدام وطبيعته. خاتمةخطة العمل جاهزة الآن مما يعني أننا جاهزون للبدء في تنفيذ إعدادات التطبيق. ينبغي تذكر أن هذا الإعداد، رغم أنه يعمل على النحو المراد، يبقى مثالا يجب أن تستطيع التقاط معلومات مفيدة منه ثم استخدام ما تعلمته لتحسين إعداد تطبيقك الخاص. ترجمة -وبتصرّف- لمقال Building for Production: Web Applications — Overview لصاحبه Mitchell Anicas. حقوق الصورة البارزة: Designed by Freepik.