مقدِّمة
توجد العديد من العوامل التي يجب أخذها بالاعتبار قبل اتخاذ قرار بشأن بنية الخادوم المستخدَم في بيئة عملك. هذه العوامل هي الأداء، والقابلية للتوسّع، والتوفّر، والثبات، والثمن، إضافةً لسهولة الإدارة.
نستعرِض في هذا المقال قائمة بإعدادات شائعة للخواديم مع وصف مُختصَر لكل إعداد يتضمن إيجابيات وسلبيات هذا الخيار. ينبغي الانتباه إلى إمكانية دمج الإعدادات في ما بينها حسب حاجة بيئة العمل؛ فلا وجود هنا لإعداد واحد هو الصّحيح وغيره خاطئ.
كل بيئة العمل على نفس الخادوم
في هذا الإعداد توجد جميع مكوّنات بيئة العمل على خادوم واحد. إذا أخذنا مثال تطبيق ويب بهذا الإعداد، فإن خادوم الويب، وخادوم التطبيق وخادوم قاعدة البيانات توجد كلّها على نفس الخادوم. أحد أكثر هذا الإعداد شيوعا هو تنصيب حِزم LAMP: نظام تشغيل Linux، وخادوم ويب Apache، وقاعدة بيانات MySQL ولغة البرمجة PHP؛ الجميع على نفس الخادوم.
حالات الاستخدام
- مناسِب لتنصيب تطبيق بشكل سريع، فهو أبسط إعداد ممكن. ولكن يعيبُه محدودية قابليته للتمدّد وعدم عزل مكوّّنات بيئة العمل عن بعضها.
الإيجابيات
- البساطة
السّلبيات
- يتزاحم كل من التطبيق وقاعدة البيانات - في هذا الإعداد - على نفس الموارد (وحدة المُعالجة CPU، والذاكرة Memory، وحدات الإدخال والإخراج I/O، ...إلخ) مما يتسبب في رداءة الأداء. علاوةً على ذلك يصعُب تحديد مصدَر رداءة الأداء، هل هو التطبيق أم قاعدة البيانات.
- صعوبة التمدّد أفقيا Horizontal scaling.
ملحوظة: المقصود بالتمدّد الأفقي هو استعمال عدة خواديم وتشغليها بحيث تظهر وكأنها خادوم واحد، أما التمدّد العمودي Vertical scaling فيُقصَد به إضافة موارد جديدة لنفس الجهاز (زيادة حجم ذاكرة الوصول العشوائي RAM على سبيل المثال). لا يحتاج التمدّد الأفقي في الغالب لإعادة تشغيل الجهاز أو الخادوم.
خادوم قاعدة بيانات منفصِل
يُمكِن فصل نظام إدارة قواعد البيانات (Database management system, DBMS) عن بقية بيئة العمل، وذلك للحد من التزاحم على الموارد بين التطبيق وقاعدة البيانات. إضافة إلى ذلك، فإن نقل خادوم قاعدة البيانات من الشبكة العمومية أو من المنطقة منزوعة السّلاح DMZ (طريقة لتمكين المستخدمين في الشبكة الخارجية من الوصول إلى بعض الخدمات الموجودة في الشبكة المحلية) يزيدُ من أمان بيئة العمل.
حالات الاستخدام
- مناسِب لتنصيب تطبيق بشكل سريع مع التخلص من تنازع الموارد بين التطبيق وقاعدة البيانات.
الإيجابيات
- لا وجود لتنازع الموارد (وحدة المُعالجة، والذاكرة، وحدات الإدخال والإخراج I/O، ...إلخ) بين مستوى التطبيق ومستوى قاعدة البيانات
- يُمكِن تمديد أي من المستوَييْن (التطبيق وقاعدة البيانات) أفقيًّا حسب الحاجة وبشكل مستقِل عن الآخر.
- زيادة الأمان بنقل قاعدة البيانات من المنطقة منزوعة السّلاح (حسب إعدادات الشبكة).
السّلبيات
- أكثر صعوبة - بقليل - من إعداد بخادوم واحد.
- قد تظهر بعض المشاكل في الأداء إذا كان زمن الوصول Latency بين الخادومين مُعتَبرا (في حال تواجد الخادومين في مكانيْن منفصليْن جغرافيا على سبيل المثال) أو إذا كان عرض الموجة Bandwidth لا يُناسِب حجم البيانات المتبادلة.
دروس متعلِّقة
- كيفية إعداد قاعدة بيانات عن بُعد لتحسين أداء موقع يستخدِم MySQL (المقال الثّالث في هذا المشروع).
موزِّع حِمل Load Balancer (وسيط عكسي Reverse proxy)
تُمكِن إضافة موزعي حِمل إلى بيئة الخادوم للرفع من الأداء والثبات عن طريق توزيع عبْء العمل بين عدّة خواديم. في حال توقف أحد الخواديم التي يُوزَّع الحِمل بينها أو وصوله للحد الأعلى من قدرته على العمَل فإن بقية الخواديم تتكفَّل بالتعامل مع البيانات القادِمة في انتظار عودة الخادوم لحالته الطبيعية. يُمكِن أيضًا استخدام موزِّع حمل يخدُم عدة تطبيقات على نفس المنفَذ Port أو النِّطاق Domain، حيثُ يلعب دور وسيط عكسي على مُستوى التطبيقات.
- أمثلة على برامج تعمل كوسيط عكسي لتوزيع الحِمل (Load balanicig): Varnish و Nginx وHAProxy.
حالات الاستخدام
- بيئات العمل التي تتطلَّب التمدّد أفقيًّا.
الإيجابيات
- سهولة إضافة خواديم جديدة (التمدّد الأفقي).
- يُساعِد على التصدي للهجمات المُوَزَّعة لحجب الخدمة (Distributed Denial Of Service, DDOS).
السّلبيات
- قد يُصبِح موزع الحِمل نفسه عقبة في وجه الأداء إن لم يمتلِك الموارد الكافية أو إن أُعِدَّ بطريقة غير جيّدة.
- تُضيف وجود موزِّع حِمل اعتبارات جديدة ربّما تزيد من التعقيد، مثل الانتقال من اتصال معمّى Encrypted إلى آخر غير معمَّى أو التعامُل مع التطبيقات التي تتطلّب جلسات متماسِكة Sticky sessions (في الجلسات المُتماسِكة تُربَط الاستعلامات القادِمة من جلسة المستخدِم بنفس الخادوم، ممّا يعني أن حِمل الاستعلامات القادِمة من هذا المُستخدِم لا يُوزَّع بين الخواديم).
مسرِّع HTTP (وسيط عكسي مُخبِّئ Caching Reverse Proxy)
يُلجَأ لمسرِّع HTTP (يُسمَّى أيضًا وسيطا عكسيا مُخبئا لطلبات HTTP) للتقليل من المدة اللازمة لتقديم المُحتوى إلى المستخدِم عبر مجموعة متنوِّعة من التقنيات. التقنية الرئيسة هي الاحتفاظ في الذّاكرة بإجابات الاستعلامات المُتلقاة من خادوم ويب أو تطبيق؛ مما ينتُج عنهُ سُرعة حصول الطّلبات المُحتفَظ بها (المُخبَّأة Cached) على الإجابة، مع التّقليل من التفاعل غير الضّروري مع خادوم الويب أو التّطبيق.
- أمثلة على برامج تستطيع العمَل مسرّعاتHTTP:برنامج Varnish، وSquid وNginx.
حالات الاستخدام
- مُناسِب لتطبيقات الويب الديناميكية ذات المحتوى الضخم أو التي تقرأ من ملفات مُشترَكة عديدة.
الإيجابيات
- الرّفع من الأداء بالتقليل من حِمل العمل على وحدة المُعالجة في خادوم الويب واللجوء إلى التخبئة والضغط Compression.
- بالإمكان استخدامُه كموزِّع حِمل (وسيط عكسي).
- تُساعِد بعض برامج التخبِئة في الحد من الهجمات المُوَزَّعة لحجب الخدمة.
السلبيات
- يحتاج إلى ضبط المُسرِّع بطريقة تضمن الحصول على أفضَل أداء.
- يقِل الأداء في حال انخفاض نسبة إصابة التخبِئة Cache-hit، أي نسبة الطّلبات المُحتفَظ بإجاباتِها في ذاكرة التخبِئة.
مُضاعفة قاعدة البيانات بهيئة رئيس-تابِع Master-Slave
تُستخدم مُضاعفة قاعدة البيانات بهيئة رئيس-تابِع لتحسين أداء قواعد البيانات التي تُجري عمليات قراءة كثيرة مقارنة بغمليات الكتابة، كما هو الحال في نُظم إدارة المُحتوى Content managment systems, CMS. يوجد في هذه الحالة قاعدة بيانات رئيسة واحدة إضافةً لقاعدة بيانات تابِعة أو أكثر. عند تحديث قاعِدة البيانات يُرسَل الطّلب إلى قاعدة البيانات الرئيسة، أما عند القراءة فإنه بالإمكان توزيع الطّلب بين قواعد البيانات التابعة.
حالات الاستخدام
- هذا الإعداد جيّد لتحسين أداء جانب قاعدة البيانات من التّطبيق.
- في الشكل أدناه مثال على مُضاعفة قاعدة البيانات بهيئة رئيس-تابِع يوجد به قاعدة بيانات تابِعة واحدة:
الإيجابيات
- يزيد من الأداء في القراءة من قاعدة البيانات عن طريق توزيع العملية بين مختَلف التوابع.
- يُمكن أن يُحسِّن من الأداء في الكتابة بحصر قاعدة البيانات الرئيسة في الكتابة فقط، فلا يستغرق الخادوم الرئيس أي وقت في الإجابة على طلبات القراءة.
السلبيات
- يجب أن توجد في التطبيق آلية للتفريق بين قواعد البيانات الرئيسة والتابعة حتى يعرف إلى أين يُرسل كلا من طلبات القراءة والكتابة.
- تحديث قواعد البيانات التّابعة غير متزامن Asynchronous، أي أنه يوجد احتمال أن تكون البيانات المقروءة لم تعُد صالحة.
- في حال تعثر قاعدة البيانات الرئيسة فلا يُمكن عمل أي تحديث حتى تعود للعمل.
- لا وجود لآلية مُدمَجة لتجاوز الفشل عند تعطّل قاعدة البيانات الرئيسة.
مثال: تجميع المفاهيم
يُمكن توزيع الحِمل بين خواديم التخبئة إضافة إلى خواديم التطبيقات مع مضاعفة قاعدة البيانات، كل ذلك في نفس بيئة العمل. الهدف من جمع هذه التقنيات هو جني ثمار كل واحدة منها دون إثارة الكثير من المشاكل أو التعقيدات. أسفلَه يوجد مُخَطَّط بياني لمثال على دمج هذه التقنيات معًا.
سنفترض أنّ موزّع الحمل مضبوط للتعرّف على المحتوى السّاكن (مثل الصوّر، وملفات CSS و Javascript، ...إلخ) وإرسال الطّلبات لهذا المُحتوى إلى خواديم التخبئة. بالنسبة لبقية الطّلبات فإنه يُرسِلها إلى خواديم التطبيق.
عند طلب محتوى ديناميكي فإن ما يحدُث هو التّالي:
- يطلُب المستخدِم محتوى ديناميكيا من http://example.com، يتلقى مُوزّع الحِمل الطّلب.
- يُمرِّر موزِّع الحِمل الطّلب إلى المُنتهي الخلفي للتطبيق Application Backend.
- يجلب المُنتهي الخلفي المحتوى المطلوب من قاعدة البيانات ويُرسِله إلى موزِّع الحِمل.
- يُمرِّر موزّع الحمل المحتوى المطلوب إلى المستخدِم.
بالنسبة للمحتوى السّاكن فإن الخطوات تكون كالتالي:
- يتعرّف موزِّع الحِمل على المحتوى السّاكِن ثم يتحقق من وجود المحتوى المطلوب لدى خادوم التخبِئة (إصابة التخبِئة) أو عدمه (تفويت التخبِئة Cache-miss).
- في حال إصابة التخبِئة: يُرسِل خادوم التخبِئة المحتوى المطلوب إلى موزِّع الحِمل؛ نُكمِل مع الخطوة 6. في حال تفويت التخبِئة يعيد خادوم التخبِئة الطّلب إلى موزِّع الحِمل.
- يُمرِّر موزِّع الحِمل الطّلب إلى المُنتهي الخلفي للتطبيق.
- يجلب المُنتهي الخلفي المحتوى المطلوب من قاعدة البيانات ويُرسِله إلى موزِّع الحِمل.
- يُمرِّر موزِّع الحِمل الطّلب إلى خادوم التخبِئة الذي يحتفِظ بنسخة من الطّلب والإجابة ثم يُعيده إلى موزِّع الحِمل.
- يُمرِّر موزّع الحمل المحتوى إلى المستخدِم.
تُوفّر بيئة العمل أعلاه كل فوائد الإعدادات المذكورة في هذا الشّرح من ناحية الثبات والأداء، ولكنْ لديها نقطتا ضعف: موزِّع الحمل وقاعدة البيانات الرئيسة.
خاتمة
ينبغي أن تكون لديك الآن، بعد التعرّف على بعض الإعدادات الأساسية للخواديم، رؤيةٌ جيّدة تُمكِّنك من معرفة أي إعداد أنسب لتطبيقاتِك. تذكّر عند العمل على الرّفع من مستوى بيئة عملك أنْ تتدرّج في إدخال التحسينات بحيث لا تُدخِل الكثير من التعقيدات في فترة قصيرة.
ترجمة -وبتصرّف- للمقال: 5 Common Server Setups For Your Web Application
تم التعديل في بواسطة محمد أحمد العيل
أفضل التعليقات
انضم إلى النقاش
يمكنك أن تنشر الآن وتسجل لاحقًا. إذا كان لديك حساب، فسجل الدخول الآن لتنشر باسم حسابك.