لماذا تحتاج إلى خادم، ما هي أنواع الخوادم الموجودة. حالات غير تافهة للعمل مع الخوادم ما هو مبدأ تشغيل الخادم

إذا كنت تستخدم جهاز كمبيوتر متصل بالشبكة يوميًا، وإذا كانت أداة الهاتف المحمول الخاصة بك متصلة أيضًا بالإنترنت، فسيصادف كل مستخدم كلمة "خادم" من وقت لآخر. علاوة على ذلك، يمكن أن تظهر هذه الكلمة في مجموعات مختلفة، وليس كل مستخدم يفهم ما يقال. ما هو المخفي وراء كلمة "الخادم" ولماذا يحتاجها المستخدمون؟

يمكن أن يعني مصطلح "الخادم" جهازًا وبرامج خاصة به (الأجهزة والظاهرية). خادم الأجهزة هو جهاز كمبيوتر منفصل. هناك حاجة لضمان تشغيل أجهزة الكمبيوتر والمعدات المكتبية الأخرى. الخادم الظاهري هو برنامج. في هذه الحالة، يجمع خادم معين بين هذين النوعين.

أول شيء يجب أن تتذكره هو أن وظيفتها هي الحفاظ على الشبكة والمستخدمين، وليس إدارة الشبكة. يقوم المستخدمون أنفسهم بوضع المهام على الخادم، وهو يحلها بسرعة. كلما كان السيرفر مثلا مثل خوادم HP كلما كان أداءه لواجباته أفضل.

ومن الصعب أن نتصور عمل الشركات الكبيرة التي لديها الكثير من المعدات الإلكترونية المثبتة دون دمج كل هذه الأجهزة في شبكة واحدة. يسمح لك الخادم الموجود في المؤسسة بالتحكم عن بعد في المعدات المكتبية ويسمح لأجهزة الكمبيوتر بالتفاعل مع بعضها البعض.

يمكن أن يؤدي فشل الخادم أو عطله إلى حدوث كارثة

في المؤسسات، تتيح الخوادم إمكانية تحسين عمل جميع الأقسام. لكن في الحياة اليومية غالبًا ما نواجه عمل الخوادم. على وجه الخصوص، يستخدم الصرافون في مكاتب النقد والبنوك خادمًا لطباعة المستندات وإجراء الدفعات. يدعم الخادم عمل جميع مرسلي البريد والشبكات الاجتماعية ومديري الاتصالات.

يوفر الخادم إمكانية الوصول إلى الإنترنت. يتم تخزين جميع المواقع على الخوادم. وهذا يوفر استضافة مشتركة. هذه الخدمة مقدمة من شركات الاستضافة.

ما هو خادم الويب؟ من وجهة نظر الشخص العادي، يعد هذا نوعًا من الصندوق الأسود الذي يعالج طلبات المتصفح وينتج صفحات الويب استجابةً لذلك. سوف يقصفك الفني بالكثير من المصطلحات الغامضة. ونتيجة لذلك، يصعب أحيانًا على مسؤولي خادم الويب المبتدئين فهم مجموعة متنوعة من المصطلحات والتقنيات. في الواقع، يتطور مجال تطوير الويب بشكل ديناميكي، لكن العديد من الحلول الحديثة تعتمد على التقنيات والمبادئ الأساسية، والتي سنتحدث عنها اليوم.

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

خادم HTTP

في فجر تطور الإنترنت، كانت المواقع عبارة عن مستودع بسيط للمستندات المميزة خصيصًا وبعض البيانات المرتبطة بها: الملفات والصور وما إلى ذلك. لكي تتمكن المستندات من الرجوع إلى بعضها البعض والبيانات ذات الصلة، تم اقتراح لغة ترميز النص التشعبي الخاصة، HTML، وتم اقتراح بروتوكول HTTP للوصول إلى هذه المستندات عبر الإنترنت. لقد بقيت كل من اللغة والبروتوكول، الذي تم تطويره وتحسينه، حتى يومنا هذا دون تغييرات كبيرة. وقد بدأ للتو في استبدال بروتوكول HTTP/1.1 المعتمد في عام 1999، حيث يجلب بروتوكول HTTP/2 تغييرات أساسية مع مراعاة متطلبات الشبكة الحديثة.

يتم تنفيذ بروتوكول HTTP باستخدام تقنية خادم العميل ويعمل على مبدأ الاستجابة للطلب عديم الحالة. الغرض من الطلب هو مورد معين، والذي يتم تحديده معرف مورد واحد - URI (معرف الموارد الموحد)، يستخدم HTTP أحد أنواع URI - عنوان URL (محدد موقع الموارد الموحد) - محدد موقع الموارد الموحد، والتي، بالإضافة إلى المعلومات حول المورد، تحدد أيضًا موقعه الفعلي.

تتمثل مهمة خادم HTTP في معالجة طلب العميل وتزويده بالمورد المطلوب، أو الإبلاغ عن استحالة القيام بذلك. خذ بعين الاعتبار الرسم البياني التالي:

يطلب المستخدم، من خلال عميل HTTP، وهو متصفح في أغلب الأحيان، عنوان URL معينًا من خادم HTTP، ويقوم الخادم بفحص ملف URL المقابل وإرساله، وعادةً ما يكون صفحة HTML. قد يحتوي المستند الناتج على روابط لموارد ذات صلة، مثل الصور. إذا كانت هناك حاجة للعرض على الصفحة، فسيطلبها العميل بشكل تسلسلي من الخادم، بالإضافة إلى الصور وأوراق الأنماط والبرامج النصية المنفذة من جانب العميل وما إلى ذلك. بعد تلقي جميع الموارد اللازمة، سيقوم المتصفح بمعالجتها وفقا لرمز مستند HTML وتقديم الصفحة النهائية للمستخدم.

كما خمن الكثيرون بالفعل، يوجد كيان معروف اليوم باسم خادم الويب تحت اسم خادم HTTP في هذا المخطط. الهدف والمهمة الرئيسية لخادم الويب هو معالجة طلبات HTTP وإرجاع نتائجها إلى المستخدم. لا يمكن لخادم الويب إنشاء محتوى من تلقاء نفسه ويعمل فقط مع المحتوى الثابت. وهذا ينطبق أيضًا على خوادم الويب الحديثة، على الرغم من ثراء إمكانياتها.

لفترة طويلة، كان خادم ويب واحد كافيًا لتنفيذ موقع ويب كامل. ولكن مع نمو الإنترنت، أصبحت قدرات HTML الثابتة منقوصة بشدة. مثال بسيط: كل صفحة ثابتة مكتفية ذاتيًا ويجب أن تحتوي على روابط لجميع الموارد المرتبطة بها؛ عند إضافة صفحات جديدة، يجب إضافة الروابط إليها إلى الصفحات الموجودة، وإلا فلن يتمكن المستخدم من الوصول إليها أبدًا .

كانت المواقع في ذلك الوقت عمومًا لا تشبه كثيرًا المواقع الحديثة، على سبيل المثال، فيما يلي إطلالة على أحد رواد الإنترنت باللغة الروسية، موقع شركة Rambler:

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

سرعان ما تحولت محاولة إنشاء شيء مشابه إلى حد ما لموقع ويب حديث إلى قدر متزايد من العمل لإجراء تغييرات على الصفحات الموجودة. بعد كل شيء، إذا قمنا بتغيير شيء ما في الجزء العام من الموقع، على سبيل المثال، الشعار الموجود في الرأس، فسنحتاج إلى إجراء هذا التغيير على جميع الصفحات الموجودة. وإذا قمنا بتغيير المسار إلى إحدى الصفحات أو حذفناها، فسنحتاج إلى العثور على جميع الروابط إليها وتغييرها أو حذفها.

لذلك، كانت الخطوة التالية في تطوير خوادم الويب هي الدعم التكنولوجي عوامل التمكين من جانب الخادم - مباحث أمن الدولة (يتضمن جانب الخادم). لقد جعل من الممكن تضمين محتويات الملفات الأخرى في رمز الصفحة، مما جعل من الممكن إزالة العناصر المتكررة مثل الرأس والتذييل والقائمة وما إلى ذلك. في ملفات منفصلة وإدراجها ببساطة أثناء التجميع النهائي للصفحة.

الآن، لتغيير شعار أو عنصر قائمة، يجب إجراء التغييرات في ملف واحد فقط، بدلاً من تحرير جميع الصفحات الموجودة. بالإضافة إلى ذلك، أتاحت SSI عرض بعض المحتوى الديناميكي على الصفحات، على سبيل المثال، التاريخ الحالي وتنفيذ شروط بسيطة والعمل مع المتغيرات. وكانت هذه خطوة مهمة إلى الأمام، حيث جعلت عمل مشرفي المواقع أسهل وحسّنت راحة المستخدمين. ومع ذلك، لا تزال هذه التقنيات لا تسمح لنا بتنفيذ موقع ويب ديناميكي حقًا.

تجدر الإشارة إلى أن SSI لا يزال يستخدم بشكل نشط اليوم، حيث يلزم إدراج بعض المحتوى الثابت في رمز الصفحة، ويرجع ذلك أساسًا إلى بساطته وانخفاض متطلبات الموارد.

CGI

كانت الخطوة التالية في تطوير تكنولوجيا الويب هي ظهور برامج خاصة (برامج نصية) تعالج طلبات المستخدم على جانب الخادم. غالبًا ما تتم كتابتها بلغات البرمجة النصية، في البداية كانت لغة Perl، واليوم تحمل PHP راحة اليد القيادية. وتدريجياً ظهرت فئة كاملة من البرامج - أنظمة إدارة المحتوى - نظام إدارة المحتوى (نظام إدارة المحتوى)، والتي تمثل تطبيقات ويب كاملة قادرة على توفير المعالجة الديناميكية لطلبات المستخدم.

الآن نقطة مهمة: خوادم الويب لم تكن تعرف ولا تعرف كيفية تنفيذ البرامج النصية، ومهمتها هي تقديم محتوى ثابت. هنا يظهر كيان جديد على الساحة - خادم التطبيقات، وهو مترجم للغات البرمجة النصية وبمساعدة تشغيل تطبيقات الويب المكتوبة بها. تُستخدم أنظمة إدارة قواعد البيانات (DBMS) عادةً لتخزين البيانات، نظرًا للحاجة إلى الوصول إلى كمية كبيرة من المعلومات المترابطة.

ومع ذلك، لا يمكن لخادم التطبيق العمل مع بروتوكول HTTP ومعالجة طلبات المستخدم، لأن هذه هي مهمة خادم الويب. ولضمان تفاعلهم، تم تطويره واجهة البوابة المشتركة - CGI (واجهة البوابة المشتركة).

يجب أن نفهم بوضوح أن CGI ليس برنامجًا أو بروتوكولًا، بل هو واجهة على وجه التحديد، أي. مجموعة من طرق التفاعل بين التطبيقات. أيضًا، لا ينبغي الخلط بين مصطلح CGI ومفهوم تطبيق CGI أو برنامج CGI النصي، والذي يشير إلى برنامج (برنامج نصي) يدعم العمل من خلال واجهة CGI.

يتم استخدام تدفقات الإدخال / الإخراج القياسية لنقل البيانات، ويتم نقل البيانات من خادم الويب إلى تطبيق CGI عبر com.stdin، يتم قبولها مرة أخرى من خلال com.stdout، يستخدم لنقل رسائل الخطأ com.stderr.

دعونا نفكر في عملية تشغيل مثل هذا النظام بمزيد من التفصيل. بعد تلقي طلب من متصفح المستخدم، يحدد خادم الويب أن المحتوى الديناميكي مطلوب ويقوم بإنشاء طلب خاص، والذي يرسله إلى تطبيق الويب من خلال واجهة CGI. عند استلامه، يعمل التطبيق ويقدم طلبًا، مما ينتج عنه رمز HTML للصفحة التي تم إنشاؤها ديناميكيًا، والتي يتم تمريرها مرة أخرى إلى خادم الويب، وبعد ذلك يخرج التطبيق.

هناك اختلاف مهم آخر بين الموقع الديناميكي وهو أن صفحاته غير موجودة فعليًا بالشكل الذي يتم تقديمه للمستخدم. في الواقع، هناك تطبيق ويب، أي. توجد مجموعة من البرامج النصية والقوالب، وقاعدة البيانات التي تخزن مواد الموقع ومعلومات الخدمة بشكل منفصل: الصور، ونصوص جافا، والملفات.

بعد تلقي طلب، يقوم تطبيق الويب باسترداد البيانات من قاعدة البيانات ويملأها بالقالب المحدد في الطلب. يتم إرسال النتيجة إلى خادم الويب، الذي يكمل الصفحة التي تم إنشاؤها بهذه الطريقة بمحتوى ثابت (الصور والبرامج النصية والأنماط) ويرسلها إلى متصفح المستخدم. لا يتم حفظ الصفحة نفسها في أي مكان، باستثناء ذاكرة التخزين المؤقت، وعند تلقي طلب جديد، سيتم إعادة إنشاء الصفحة.

تتضمن مزايا CGI الاستقلال اللغوي والمعماري: يمكن كتابة تطبيق CGI بأي لغة والعمل بشكل جيد مع أي خادم ويب. ونظرًا لبساطة المعيار وانفتاحه، فقد أدى ذلك إلى التطور السريع لتطبيقات الويب.

ومع ذلك، بالإضافة إلى مزاياها، فإن CGI لديها أيضًا عيوب كبيرة. العامل الرئيسي هو التكاليف العامة المرتفعة لبدء العملية وإيقافها، مما يستلزم زيادة المتطلبات لموارد الأجهزة وانخفاض الأداء. كما أن استخدام تدفقات الإدخال/الإخراج القياسية يحد من قابلية التوسع والتوافر العالي لأنه يتطلب وجود خادم الويب وخادم التطبيقات على نفس النظام.

في الوقت الحالي، لا يتم استخدام CGI عمليًا، حيث تم استبدالها بتقنيات أكثر تقدمًا.

FastCGI

وكما يوحي الاسم، كان الهدف الرئيسي من تطوير هذه التكنولوجيا هو تحسين أداء CGI. ولتطويره الإضافي، يعد FastCGI بمثابة بروتوكول خادم عميل للتفاعل بين خادم الويب وخادم التطبيقات، مما يوفر أداءً عاليًا وأمانًا.

يحل FastCGI المشكلة الرئيسية لـ CGI - إعادة تشغيل عملية تطبيق الويب لكل طلب؛ حيث تعمل عمليات FastCGI باستمرار، مما يسمح لك بتوفير الوقت والموارد بشكل كبير. لنقل البيانات، نستخدم بدلاً من التدفقات القياسية مآخذ UNIXأو تكب / إب، والذي يسمح لك باستضافة خادم الويب وخوادم التطبيقات على مضيفين مختلفين، وبالتالي ضمان قابلية التوسع و/أو التوفر العالي للنظام.

يمكننا أيضًا تشغيل العديد من عمليات FastCGI على جهاز كمبيوتر واحد، والذي يمكنه معالجة الطلبات بالتوازي، أو أن يكون له إعدادات أو إصدارات مختلفة من لغة البرمجة النصية. على سبيل المثال، يمكنك الحصول في الوقت نفسه على عدة إصدارات من PHP لمواقع مختلفة، وتوجيه طلباتها إلى عمليات FastCGI المختلفة.

يتم استخدام مديري العمليات لإدارة عمليات FastCGI وتوزيع التحميل؛ ويمكن أن يكونوا إما جزءًا من خادم الويب أو تطبيقات منفصلة. تحتوي خوادم الويب الشهيرة Apache وLighttpd على مديري عمليات FastCGI مدمجين، بينما يتطلب Nginx مديرًا خارجيًا للعمل مع FastCGI.

PHP-FPM و تفرخ-fcgi

يشمل المديرون الخارجيون لعمليات FastCGI PHP-FPM وspawn-fcgi. كان PHP-FPM في الأصل عبارة عن مجموعة من تصحيحات PHP من Andrey Nigmatulin، والتي حلت عددًا من المشكلات في إدارة عمليات FastCGI، بدءًا من الإصدار 5.3، وهي جزء من المشروع ومضمنة في توزيع PHP. يمكن لـ PHP-FPM إدارة عدد عمليات PHP ديناميكيًا اعتمادًا على التحميل، وإعادة تحميل التجمعات دون فقدان الطلبات، وإعادة التشغيل الطارئ للعمليات الفاشلة، وهو مدير متقدم إلى حد ما.

يعد Spawn-fcgi جزءًا من مشروع Lighttpd، ولكنه ليس جزءًا من خادم الويب الذي يحمل نفس الاسم؛ افتراضيًا، يستخدم Lighttpd مدير العمليات الخاص به والأبسط. يوصي المطورون باستخدامه في الحالات التي تحتاج فيها إلى إدارة عمليات FastCGI الموجودة على مضيف آخر، أو تتطلب إعدادات أمان متقدمة.

يسمح لك المديرون الخارجيون بعزل كل عملية FastCGI في جذرها الخاص (تغيير الدليل الجذر للتطبيق دون القدرة على الوصول إلى ما وراءه)، والذي يختلف عن كل من جذر العمليات الأخرى وجذر خادم الويب. وكما قلنا من قبل، فهي تسمح لك بالعمل مع تطبيقات FastCGI الموجودة على خوادم أخرى عبر TCP/IP، وفي حالة الوصول المحلي، يجب عليك اختيار الوصول عبر مقبس UNIX كنوع اتصال سريع.

إذا نظرنا إلى الرسم البياني مرة أخرى، فسنرى أن لدينا عنصرًا جديدًا - مدير العمليات، وهو وسيط بين خادم الويب وخوادم التطبيقات. يؤدي هذا إلى تعقيد المخطط إلى حد ما، نظرًا لأنه يجب تكوين وصيانة عدد أكبر من الخدمات، ولكنه في نفس الوقت يفتح إمكانيات أوسع، مما يسمح لك بتكوين كل عنصر من عناصر الخادم خصيصًا لمهامك.

من الناحية العملية، عند الاختيار بين مدير مدمج ومدير خارجي، قم بتقييم الموقف بشكل معقول واختر الأداة التي تناسب احتياجاتك تمامًا. على سبيل المثال، عند إنشاء خادم بسيط لعدة مواقع على محركات قياسية، فمن الواضح أن استخدام مدير خارجي سيكون غير ضروري. على الرغم من أن لا أحد يفرض وجهة نظره عليك. الشيء الجيد في Linux هو أنه يمكن لأي شخص، كما لو كان يستخدم مجموعة أدوات البناء، تجميع ما يحتاج إليه بالضبط.

SCGI، PCGI، PSGI، WSGI وغيرها

عندما تتعمق في موضوع تطوير الويب، ستصادف بالتأكيد إشارات إلى تقنيات CGI المختلفة، والتي أدرجنا أكثرها شيوعًا في العنوان. قد تشعر بالارتباك بسبب هذا التنوع، ولكن إذا قرأت بداية مقالتنا بعناية، فأنت تعرف كيف تعمل CGI وFastCGI، وبالتالي فإن فهم أي من هذه التقنيات لن يكون صعبًا بالنسبة لك.

وعلى الرغم من الاختلافات في تنفيذ حل معين، فإن المبادئ الأساسية تظل مشتركة. توفر كل هذه التقنيات واجهة بوابة ( واجهة البوابة) للتفاعل بين خادم الويب وخادم التطبيقات. تتيح لك البوابات فصل خادم الويب وبيئات تطبيقات الويب، مما يسمح لك باستخدام أي مجموعة دون النظر إلى عدم التوافق المحتمل. ببساطة، لا يهم ما إذا كان خادم الويب الخاص بك يدعم تقنية معينة أو لغة برمجة نصية معينة، طالما أنه يمكنه التعامل مع نوع البوابة التي تحتاجها.

وبما أننا قد أدرجنا بالفعل مجموعة كاملة من الاختصارات في العنوان، فلنستعرضها بمزيد من التفصيل.

SCGI (واجهة بوابة مشتركة بسيطة) - واجهة بوابة مشتركة بسيطة- تم تصميمه كبديل لـ CGI ويشبه FastCGI في العديد من النواحي، ولكنه أسهل في التنفيذ. كل ما تحدثنا عنه فيما يتعلق بـ FastGCI ينطبق أيضًا على SCGI.

بكجي (واجهة بوابة بيرل المشتركة) - مكتبة Perl للعمل مع واجهة CGI، كانت منذ فترة طويلة الخيار الرئيسي للعمل مع تطبيقات Perl عبر CGI، فهي تتمتع بأداء جيد (فيما يتعلق بـ CGI) مع متطلبات متواضعة من الموارد وحماية جيدة من التحميل الزائد.

باريس سان جيرمان (واجهة بوابة خادم الويب بيرل) - تقنية التفاعل بين خادم الويب وخادم التطبيقات لـ Perl. إذا كانت PCGI أداة للعمل مع واجهة CGI كلاسيكية، فإن PSGI تشبه FastCGI. يوفر خادم PSGI بيئة لتشغيل تطبيقات Perl التي تعمل بشكل مستمر كخدمة ويمكنها الاتصال بخادم الويب عبر مقابس TCP/IP أو UNIX وتوفر لتطبيقات Perl نفس المزايا التي يوفرها FastCGI.

WSGI (واجهة بوابة خادم الويب) هي واجهة بوابة محددة أخرى مصممة للتفاعل بين خادم الويب وخادم التطبيقات للبرامج المكتوبة بلغة Phyton.

كما ترون بسهولة، جميع التقنيات التي ذكرناها هي، بدرجة أو بأخرى، نظائرها لـ CGI/FastCGI، ولكن لمجالات تطبيق محددة. ستكون البيانات التي قدمناها كافية تمامًا لفهم عام لمبدأ وآليات عملها، ولن يكون من المنطقي إجراء دراسة أعمق لها إلا عند العمل الجاد مع هذه التقنيات واللغات.

خادم التطبيقات كوحدة أباتشي

إذا تحدثنا سابقًا عن بعض خوادم الويب المجردة، فسنتحدث الآن عن حل ملموس وهذه ليست مسألة تفضيلاتنا. من بين خوادم الويب، يحتل Apache مكانًا خاصًا؛ في معظم الحالات، عندما يتحدثون عن خادم ويب على منصة Linux، وبالفعل عن خادم الويب بشكل عام، سيكون Apache هو المقصود.

يمكنك القول أن هذا نوع من خادم الويب "الافتراضي". خذ أي استضافة جماعية - سيكون Apache موجودًا، خذ أي تطبيق ويب - يتم ضبط الإعدادات الافتراضية لـ Apache.

نعم، من الناحية التكنولوجية، أباتشي ليس تاج التكنولوجيا، لكنه يمثل الوسط الذهبي، فهو بسيط، مفهوم، مرن في الإعدادات، وعالمي. إذا كنت تتخذ خطواتك الأولى في بناء موقع الويب، فإن Apache هو خيارك.

هنا يمكن أن نلوم أن Apache قد عفا عليه الزمن منذ فترة طويلة، وأن جميع "الرجال الحقيقيين" قد قاموا بالفعل بتثبيت Nginx، وما إلى ذلك. الخ، فلنشرح هذه النقطة بمزيد من التفصيل. يتم تكوين جميع أنظمة إدارة المحتوى الشائعة للاستخدام مع Apache، مما يسمح لك بتركيز كل انتباهك على العمل مع تطبيق الويب، والقضاء على خادم الويب كمصدر محتمل للمشاكل.

جميع المنتديات المشهورة بين المبتدئين تستخدم أيضًا Apache كخادم ويب، وستنطبق عليه معظم النصائح والتوصيات بشكل خاص. وفي الوقت نفسه، تتطلب خوادم الويب البديلة عادةً تكوينًا أكثر دقة وحذرًا، سواء من خادم الويب أو من تطبيق الويب. في الوقت نفسه، عادة ما يكون مستخدمو هذه المنتجات أكثر خبرة بكثير ولا تتم مناقشة المشاكل النموذجية للمبتدئين في بيئتهم. ونتيجة لذلك، قد يكون هناك موقف عندما لا يعمل شيء ولا يوجد من يسأل. نضمن عدم حدوث ذلك مع Apache.

في الواقع، ما الذي فعله مطورو Apache ليسمح لبنات أفكارهم باحتلال مكان خاص؟ الجواب بسيط للغاية: لقد ذهبوا في طريقهم الخاص. بينما اقترحت CGI الابتعاد عن حلول محددة والتركيز على بوابة عالمية، قام Apache بذلك بطريقة مختلفة - فقد قام بدمج خادم الويب وخادم التطبيقات قدر الإمكان.

في الواقع، إذا قمنا بتشغيل خادم التطبيق كوحدة نمطية لخادم الويب في مساحة عنوان مشتركة، فسنحصل على مخطط أبسط بكثير:

ما هي الفوائد التي يوفرها هذا؟ كلما كانت الدائرة أبسط واحتوت على عدد أقل من العناصر، كلما كانت صيانتها وصيانتها أسهل وأرخص، وقل عدد نقاط الفشل فيها. على الرغم من أن هذا قد لا يكون مهمًا جدًا لخادم واحد، إلا أنه يعد عاملًا مهمًا للغاية ضمن الاستضافة.

الميزة الثانية هي الإنتاجية. مرة أخرى، سنخيب آمال محبي Nginx، بفضل العمل في مساحة عنوان واحدة، سيكون أداء خادم التطبيقات Apache + mod_php دائمًا أسرع بنسبة 10-20% من أي خادم ويب آخر + FastCGI (أو أي حل CGI آخر). ولكن يجب أن تتذكر أيضًا أن سرعة الموقع لا يتم تحديدها فقط من خلال أداء خادم التطبيقات، ولكن أيضًا من خلال عدد من الشروط الأخرى التي يمكن أن تظهر فيها خوادم الويب البديلة نتائج أفضل بشكل ملحوظ.

ولكن هناك ميزة أخرى خطيرة للغاية: القدرة على تكوين خادم التطبيق على مستوى موقع فردي أو مستخدم. دعنا نعود قليلًا إلى الوراء: في مخططات FastCGI/CGI، يكون خادم التطبيقات عبارة عن خدمة منفصلة، ​​بإعداداتها المنفصلة الخاصة بها، والتي يمكنها أيضًا العمل نيابة عن مستخدم مختلف أو على مضيف مختلف. من وجهة نظر مسؤول خادم واحد أو بعض المشاريع الكبيرة، يعد هذا أمرًا رائعًا، ولكن بالنسبة للمستخدمين ومسؤولي الاستضافة، ليس كثيرًا.

أدى تطور الإنترنت إلى حقيقة أن عدد تطبيقات الويب الممكنة (CMS، والنصوص البرمجية، والأطر، وما إلى ذلك) أصبح كبيرًا جدًا، وقد اجتذب حاجز الدخول المنخفض عددًا كبيرًا من الأشخاص الذين ليس لديهم معرفة تقنية خاصة تطوير الموقع. وفي الوقت نفسه، قد تتطلب تطبيقات الويب المختلفة تكوينًا مختلفًا لخادم التطبيقات. ماذا علي أن أفعل؟ هل تحتاج إلى الاتصال بالدعم في كل مرة؟

تم العثور على الحل بسيط للغاية. نظرًا لأن خادم التطبيقات أصبح الآن جزءًا من خادم الويب، فيمكنك توجيه الأخير لإدارة إعداداته. تقليديا، لإدارة إعدادات Apache، بالإضافة إلى ملفات التكوين، تم استخدام ملفات httaccess، والتي سمحت للمستخدمين بكتابة توجيهاتهم هناك وتطبيقها على الدليل حيث يوجد هذا الملف وأدناه، إذا لم يتم تجاوز الإعدادات هناك من قبلهم ملف هتاتكس. في وضع mod_php، تسمح لك هذه الملفات أيضًا بتغيير العديد من خيارات PHP لموقع أو دليل فردي.

لقبول التغييرات، لا تحتاج إلى إعادة تشغيل خادم الويب وفي حالة حدوث خطأ، سيتوقف هذا الموقع فقط (أو جزء منه) عن العمل. بالإضافة إلى ذلك، حتى المستخدمين غير المدربين يمكنهم إجراء تغييرات على ملف نصي بسيط ووضعه في مجلد على الموقع وهو آمن للخادم ككل.

إن الجمع بين كل هذه المزايا هو ما أعطى Apache هذا الاستخدام الواسع النطاق والمكانة كخادم ويب عالمي. قد تكون الحلول الأخرى أسرع وأكثر اقتصادًا وأفضل، ولكنها تتطلب دائمًا تخصيصًا للمهمة، لذلك يتم استخدامها بشكل أساسي في المشاريع المستهدفة؛ ويهيمن Apache على القطاع الشامل دون أي بديل.

بعد أن تحدثنا عن المزايا، دعنا ننتقل إلى العيوب. وبعضهم ببساطة هو الوجه الآخر للعملة. حقيقة أن خادم التطبيق جزء من خادم الويب يعطي مزايا في الأداء وسهولة التكوين، ولكن في نفس الوقت يحدنا من حيث الأمان - يعمل خادم التطبيق دائمًا نيابة عن خادم الويب، ومن حيث مرونة النظام ، لا يمكننا توزيع خادم الويب وخادم التطبيقات على مضيفين مختلفين؛ ولا يمكننا استخدام خوادم بإصدارات مختلفة من لغة البرمجة النصية أو إعدادات مختلفة.

العيب الثاني هو ارتفاع استهلاك الموارد. في مخطط CGI، يقوم خادم التطبيق بإنشاء صفحة ويرسلها إلى خادم الويب، مما يؤدي إلى تحرير الموارد؛ وتبقي مجموعة Apache + mod_php موارد خادم التطبيق مشغولة حتى يقوم خادم الويب بإرجاع محتويات الصفحة إلى العميل. إذا كان العميل بطيئًا، فستكون الموارد مشغولة طوال مدة خدمته. ولهذا السبب غالبًا ما يتم وضع Nginx أمام Apache، الذي يلعب دور العميل السريع؛ وهذا يسمح لـ Apache بخدمة الصفحة بسرعة وتحرير الموارد عن طريق تحويل التفاعل مع العميل إلى Nginx الأكثر اقتصادًا.

خاتمة

من المستحيل تغطية مجموعة كاملة من التقنيات الحديثة في مقال واحد، لذلك ركزنا فقط على أهمها، وترك بعض الأشياء عمدا وراء الكواليس، ولجأت أيضا إلى تبسيطات كبيرة. مما لا شك فيه، عندما تبدأ العمل في هذا المجال، ستحتاج إلى دراسة أعمق للموضوع، ولكن من أجل إدراك المعرفة الجديدة، فأنت بحاجة إلى أساس نظري معين، والذي حاولنا وضعه مع هذه المادة.

التحكم في الأخطاء عند كتابة التعليمات البرمجية

مراقبة الموقع في محركات البحث

إنشاء رسم تخطيطي لمشروع مستقبلي

خدمات عبر الإنترنت لحل مشاكل التصميم وتطوير الويب

• العمل مع الخادم

تثبيت خادم أباتشي

بفضل برنامج Denver والبرامج المشابهة، أصبح من السهل جدًا تثبيت وتكوين خادم محلي على جهاز الكمبيوتر الخاص بك. لقد كتب الكثير عن هذا، وعملية التثبيت نفسها بديهية. ولكن يمكنك تكوين الخادم دون مساعدة البرامج المساعدة، وتثبيت ما هو مطلوب للعمل فقط. سنتحدث في هذه المقالة عن كيفية تثبيت خادم Apache على جهاز الكمبيوتر الخاص بك وتكوينه لمزيد من العمل.

تثبيت وتكوين PHP

عندما تنتهي كل أعمال تثبيت وتكوين خادم Apache، يمكنك البدء في تثبيت PHP على جهاز الكمبيوتر الخاص بك وتكوينه لمزيد من العمل.

تثبيت وتكوين خادم قاعدة البيانات (MySQL)

إذا كنت ستنشئ مواقع ويب باستخدام قواعد البيانات (وهذا هو الحال على الأرجح)، فمن أجل التشغيل الكامل، بالإضافة إلى Apache وPHP، ستحتاج إلى تثبيت خادم قاعدة البيانات وتكوينه - في حالتنا هو MySQL. وهذا ما سيتم مناقشته في هذه المقالة.

تثبيت وتكوين phpMyAdmin

بالنسبة لأولئك الذين لا يشعرون بأي إزعاج في استخدام سطر الأوامر للعمل مع قواعد البيانات، وكذلك لأولئك الذين يعرفون كيفية العمل مع قواعد البيانات عبر سطر الأوامر، فهذه الخطوة ليست ضرورية. بالنسبة لأي شخص آخر، سيتم هنا وصف الخطوة الأخيرة في إعداد خادم محلي - سنقوم بتثبيت وتكوين غلاف رسومي يسهل العمل مع قواعد البيانات بشكل كبير. سنتحدث عن phpMyAdmin.

لقد أصدرنا كتابًا جديدًا بعنوان تسويق محتوى الوسائط الاجتماعية: كيفية الوصول إلى عقول متابعيك وجعلهم يقعون في حب علامتك التجارية.

خادم الويب هو خادم يقبل الطلبات المقدمة من المستخدم ويزودهم بالردود - مستند أو صفحة أو موقع.

المزيد من مقاطع الفيديو على قناتنا - تعلم التسويق عبر الإنترنت مع SEMANTICA

يمكن تحويل أي جهاز كمبيوتر إلى خادم. للقيام بذلك، تحتاج إلى تثبيت قذيفة خاصة.

يتم تحديد متطلبات الجزء الفني حسب عدد الموارد المخصصة ومتطلبات السرعة. كلما كان حجمها أكبر، كلما كان الكمبيوتر أقوى.
لتوضيح الأمر، دعونا نعطي تشبيهًا. تذهب إلى المكتبة وتطلب منهم أن يعطوك كتابًا. يجد أمين المكتبة ما تحتاجه ويعطيه لك. المكتبة عبارة عن خادم؛ يتم تخزين جميع البيانات فيها. أمين المكتبة هو الصدفة التي قبلت الطلب وأرسلت الرد. أنت العميل.
يمكنك إرسال أمين مكتبة للحصول على مزيد من المعلومات - مثل النقر على الرابط. والفرق هو أن نفس المورد على الإنترنت يمكن قراءته من قبل عدد غير محدود من المستخدمين في وقت واحد.
يتم تنفيذ خدمة العملاء وفقًا لمبدأ مماثل: عندما نأتي لالتقاط كتاب، يمكننا طرح سؤال على أمين المكتبة (محرك البحث) أو البحث في الفهرس (كتالوج ياندكس). وهذا يساعدك في العثور على المعلومات التي تحتاجها.

ماذا يفعل خادم الويب؟

مهمتها الرئيسية هي تخزين المعلومات. الصفحات والملفات والصور والمحتوى النصي.
مهام:

• تلقي الطلبات.
• تشغيل البرامج بلغات برمجة خاصة (الخادم).
• إنشاء صفحات الويب.
• أرسلهم مرة أخرى إلى المستخدم.
• حماية المعلومات.
• تحديد الزوار.
• احتفظ بسجل للطلبات.
• خدمة طلبات من أنواع أخرى: mailto، وما إلى ذلك.

لفهم كيفية عمل خادم الويب، يجب أن يكون لديك فهم لمبادئ نقل المعلومات على الشبكة. ويستند إلى قواعد تسمى البروتوكولات: أي عنوان URL يبدأ بإشارة إلى النوع (ftp، http://، https://، وما إلى ذلك).
بروتوكول نقل النص الفائق - بروتوكول النقل. تكون صفحات الموقع دائمًا على شكل مستند نص تشعبي. هذه هي النتيجة النهائية لأي خادم أو برنامج عميل.

• عندما يُدخل المستخدم عنوانًا أو ينقر على رابط، يقوم المتصفح بتقديم طلب عن طريق تشفير المعلومات وفقًا لهذه القواعد.
• يقوم المضيف الذي يرتبط به هذا العنوان بتشغيل برامج الخادم. كل واحد منهم يؤدي وظائفه الخاصة.
• يتم فك تشفير البيانات المستلمة وتنفيذ الأوامر.
• يتم إنشاء النص التشعبي، وترميزه وإرساله مرة أخرى.
• يتلقى المتصفح الرد، ويحول الكود إلى html ويعرض الصفحة على الشاشة.

ما هو مطلوب لخادم الويب

نحن بحاجة إلى آلة تقوم بمعالجة جميع الطلبات. قم بتقدير الحمل الذي يجب أن يتحمله الخادم. يعتمد ذلك على عدد الزوار: كلما زاد عدد الطلبات، زادت الحاجة إلى الطاقة.

هناك شركات خاصة تقدم خدمات الاستضافة. أنت تستأجر الخادم. يتم منحك حصة لاستضافة ملفات الموقع.
ولكن إذا كان لديك موقع ويب بسيط، فيمكنك القيام بذلك بنفسك.

عندما يتم حل مشكلة الخادم، ستحتاج إلى ربط عنوان IP ثابت به.

يصبح الموقع متاحا على خادم الويب بعد تسجيل اسم النطاق، ويتم ترجمة العناوين بواسطة خدمة DNS - ربط عنوان IP (على سبيل المثال، 111.111.111.111) واسم المجال (www.site.com).

الخوادم الأكثر شيوعا

أباتشي

هذا منتج مجاني وموزع مجانًا وله العديد من المزايا:

• دعم المطور المستمر.
• وحدات للعمل مع لغات برمجة الخادم PHP، Perl، Python، Ruby، ASP، إلخ.
• مفتوح المصدر. يشارك العديد من المبرمجين في إجراء تعديلات لتناسب احتياجاتهم. على سبيل المثال، يقوم المجتمع الناطق بالروسية بتكييفه مع الترميز الروسي.
• . تم إنشاؤه في الأصل لنظام التشغيل Unix، ولكنه أصبح الآن مدعومًا من أنظمة التشغيل Windows وMac OS وBSD وLinux وOS/2 وNovell NetWare.
• أمان.

أثناء التثبيت، حدد اسم المضيف الخاص بك، على سبيل المثال، localhost. انسخ أي صفحة html إلى مجلد htdocs الموجود داخل مجلد Apachex.x (حيث x.x هو رقم الإصدار). أو قم بإنشائه في برنامج "المفكرة" عن طريق إدخال أي نص وحفظه بامتداد html.

عندما يظهر الملف في المجلد، افتح المتصفح واكتب العنوان: localhost://PAGE NAME.html. سيظهر النص الخاص بك على الشاشة - يتم فتح الصفحة من الخادم. إذا رأيت الخطأ "لا يمكن الوصول إلى الموقع"، فهذا يعني أن Apache لا يعمل. أيقونته موجودة في الدرج.
اضغط عليها واختر "تشغيل". بعد هذا كل شيء سوف يعمل.

NGNIX

وتبلغ حصة المواقع النشطة العاملة عليه 21.13% (أبحاث نتكرافت). يتم استخدامه بشكل أساسي من قبل الشركات الكبيرة والمطورين المحترفين: Yandex، Mail.ru، Rambler، إلخ. يمكن لـ NGNIX أن تتحمل عددًا كبيرًا من الزوار، فهي موثوقة وآمنة ومدروسة.
يتم توزيعه مجانًا، ولكن ظهرت إصدارات Plus المدفوعة بتكلفة تبدأ من 2500 دولار.

IIS

شهرتها مضمونة بالاسم الشهير للمطور. إنها مجموعة من خدمات الويب ومتكاملة مع Windows. منصة البرمجة الأصلية هي ASP.NET، ولكن يمكن تنفيذ بديل مثل PHP.

تتطلب الاستضافة الكاملة تثبيت نظام تشغيل خادم من شركة Microsoft – Windows Server. الإصدار السادس لم يكن مخصصًا للاستضافة على الإطلاق؛ بدأ الدعم الكامل في الإصدار السابع. يتم شراؤه تلقائيًا مع نظام التشغيل ويعتمد على خصائصه.

حزم التثبيت

بالنسبة للمبرمجين والمطورين المبتدئين، يتم إنشاء أدوات تسمح لك بنشر خادم ويب على جهاز الكمبيوتر الخاص بك ببضع نقرات.

• خادم مفتوح. بيئة تطوير محمولة تتضمن العديد من قواعد البيانات ولغات البرمجة وإصداراتها بالإضافة إلى خدمات إضافية. على سبيل المثال، واجهة العمل مع قاعدة بيانات PhpMyAdmin. اليوم هذه هي مجموعة التثبيت الأكثر شعبية. حتى أنه يعمل من محرك أقراص فلاش. تحميل مجاني بسرعة منخفضة. مقابل 100 روبل تزيد السرعة بشكل ملحوظ.
• Xampp. الحزمة المدعومة بشكل نشط: Apache، Php، Perl، MariaDB، إلخ. تحتوي على لوحة تحكم. تنزيل مجاني.
• . مجموعة مريحة جدًا من جميع الأدوات الضرورية، بما في ذلك Apache وPHP وMySQL وPhpMyAdmin. لسوء الحظ، يتضمن الإصدار الأخير توزيعات قديمة. بشكل عام، فهي مناسبة أيضًا للتدريب. اذا حكمنا من خلال المنتدى، لم يعد المشروع مدعوما.

أحيانًا تبدأ أي معدات، بما في ذلك معدات الخادم، في العمل بشكل غير متوقع. لا يهم على الإطلاق ما إذا كانت هذه المعدات جديدة أو تعمل بكامل طاقتها لعدة سنوات.

هناك العديد من حالات الفشل والتشغيل غير الصحيح، وغالبًا ما يتحول تشخيص المشكلة إلى لغز مثير.

أدناه سنتحدث عن بعض الحالات المثيرة للاهتمام وغير التافهة.

استكشاف الأخطاء وإصلاحها

يحدث تسجيل المشكلة غالبًا بعد اتصال العملاء بالدعم الفني من خلال نظام التذاكر.

إذا اتصل بنا أحد العملاء واستأجر منا خوادم مخصصة ذات تكوين ثابت، فإننا نقوم بإجراء تشخيصات لنكتشف أن المشكلة ليست برمجية بطبيعتها.

عادةً ما يقوم العملاء بحل مشكلات البرامج بأنفسهم، ومع ذلك، على أية حال، نحاول تقديم المساعدة من مسؤولي النظام لدينا.

إذا أصبح من الواضح أن المشكلة تكمن في الأجهزة (على سبيل المثال، لا يرى الخادم جزءًا من ذاكرة الوصول العشوائي)، ففي هذه الحالة لدينا دائمًا منصة خادم مماثلة في الاحتياطي.

إذا تم تحديد مشكلة في الأجهزة، فإننا نقوم بنقل الأقراص من الخادم الفاشل إلى الخادم الاحتياطي، وبعد إعادة تكوين طفيفة لمعدات الشبكة، يتم تشغيل الخادم. وبالتالي، لا يتم فقدان البيانات، ولا يتجاوز وقت التوقف عن العمل 20 دقيقة من لحظة الوصول.

أمثلة على المشاكل والحلول

فشل الشبكة على الخادم

هناك احتمال أنه بعد نقل الأقراص من خادم فاشل إلى خادم احتياطي، ستتوقف الشبكة الموجودة على الخادم عن العمل. يحدث هذا عادةً عند استخدام أنظمة تشغيل Linux، مثل Debian أو Ubuntu.

والحقيقة هي أنه أثناء التثبيت الأولي لنظام التشغيل، تتم كتابة عناوين MAC لبطاقات الشبكة في ملف خاص موجود في: /etc/udev/rules.d/70-persistent-net.rules.

عند بدء تشغيل نظام التشغيل، يقوم هذا الملف بتعيين أسماء الواجهات إلى عناوين MAC. عند استبدال الخادم بخادم احتياطي، لن تعد عناوين MAC الخاصة بواجهات الشبكة متطابقة، مما يؤدي إلى عدم إمكانية تشغيل الشبكة على الخادم.

لحل المشكلة، تحتاج إلى حذف الملف المحدد وإعادة تشغيل خدمة الشبكة، أو إعادة تشغيل الخادم.

سيقوم نظام التشغيل، الذي لم يعثر على هذا الملف، بإنشاء ملف مشابه تلقائيًا ومطابقة الواجهات مع عناوين MAC الجديدة لبطاقات الشبكة.

ليست هناك حاجة لإعادة تكوين عناوين IP بعد ذلك، ستبدأ الشبكة في العمل على الفور.

مشكلة التجميد العائم

في أحد الأيام، جاء إلينا خادم لتشخيص مشكلة التجميد العشوائي أثناء التشغيل. لقد فحصنا سجلات BIOS وIPMI - فارغة، ولا توجد أخطاء. لقد وضعناه تحت اختبار التحمل، وقمنا بتحميل جميع نوى المعالج بنسبة 100%، مع مراقبة درجة الحرارة في نفس الوقت - فقد تجمد بعد 30 دقيقة من التشغيل.

في الوقت نفسه، كان المعالج يعمل بشكل طبيعي، ولم تتجاوز درجات الحرارة القيم القياسية تحت الحمل، وكانت جميع المبردات في حالة عمل جيدة. أصبح من الواضح أن القضية لم تكن محمومة.

بعد ذلك، كان من الضروري استبعاد حالات الفشل المحتملة لوحدات ذاكرة الوصول العشوائي (RAM)، لذلك قمنا بإخضاع الخادم لاختبار الذاكرة باستخدام Memtest86+ المشهور إلى حد ما. وبعد حوالي 20 دقيقة، تعطل الخادم كما هو متوقع، مما أدى إلى ظهور أخطاء في إحدى وحدات ذاكرة الوصول العشوائي (RAM).

بعد استبدال الوحدة بوحدة جديدة، اختبرنا الخادم مرة أخرى، ولكن كان هناك إخفاق في انتظارنا - تجمد الخادم مرة أخرى، مما أدى إلى ظهور أخطاء لوحدة ذاكرة الوصول العشوائي (RAM) مختلفة. لقد استبدلوه أيضًا. اختبار آخر - تجمد مرة أخرى، مما أدى مرة أخرى إلى ظهور أخطاء في ذاكرة الوصول العشوائي. لم يكشف الفحص الدقيق لفتحات ذاكرة الوصول العشوائي (RAM) عن أي عيوب.

لم يتبق سوى مذنب واحد محتمل - المعالج المركزي. الحقيقة هي أن وحدة التحكم في ذاكرة الوصول العشوائي (RAM) موجودة داخل المعالج وأن وحدة التحكم هذه هي التي قد تفشل.

بعد إزالة المعالج، اكتشفنا كارثة - تم كسر أحد أطراف المقبس في الأعلى، وكان طرف الدبوس المكسور ملتصقًا حرفيًا بلوحة الاتصال الخاصة بالمعالج. ونتيجة لذلك، عندما لم يكن هناك تحميل على الخادم، كان كل شيء يعمل بشكل مناسب، ولكن عندما ارتفعت درجة حرارة المعالج، تم كسر الاتصال، وبالتالي إيقاف التشغيل العادي لوحدة تحكم ذاكرة الوصول العشوائي، مما تسبب في التجميد.

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

تجميد الخادم الوهمي أثناء تثبيت نظام التشغيل

تنشأ حالات مضحكة للغاية عندما يبدأ مصنعو المعدات في تغيير بنية الأجهزة، والتخلي عن دعم التقنيات القديمة لصالح التقنيات الجديدة.

اتصل بنا أحد المستخدمين بشأن شكوى بشأن توقف الخادم عند محاولة تثبيت نظام التشغيل Windows Server 2008 R2. بعد تشغيل برنامج التثبيت بنجاح، توقف الخادم عن الاستجابة للماوس ولوحة المفاتيح في وحدة تحكم KVM. لترجمة المشكلة، قمنا بتوصيل الماوس ولوحة المفاتيح الفعلية بالخادم - كل شيء على حاله، ويبدأ برنامج التثبيت ويتوقف عن الاستجابة لأجهزة الإدخال.

في ذلك الوقت، كان هذا الخادم واحدًا من أوائل الخوادم التي لدينا استنادًا إلى اللوحة الأم X11SSL-f المصنعة بواسطة Supermicro. في إعدادات BIOS، كان هناك عنصر واحد مثير للاهتمام: تثبيت Windows 7، تم ضبطه على "تعطيل". نظرًا لنشر أنظمة التشغيل Windows 7 و2008 و2008 R2 على نفس برنامج التثبيت، فقد قمنا بتعيين هذه المعلمة على "تمكين" وبدأ الماوس ولوحة المفاتيح في العمل بأعجوبة. ولكن هذه كانت مجرد بداية الملحمة مع تثبيت نظام التشغيل.

في وقت اختيار القرص للتثبيت، لم يتم عرض أي قرص، علاوة على ذلك، تم تقديم رسالة خطأ حول الحاجة إلى تثبيت برامج تشغيل إضافية. تم تثبيت نظام التشغيل من محرك أقراص فلاش USB وأظهر البحث السريع على الإنترنت أن هذا التأثير يحدث إذا لم يتمكن برنامج التثبيت من العثور على برامج تشغيل لوحدة تحكم USB 3.0.

ذكرت ويكيبيديا أنه تم حل المشكلة عن طريق تعطيل دعم USB 3.0 (وحدة تحكم XHCI) في BIOS. عندما فتحنا الوثائق الخاصة باللوحة الأم، كانت المفاجأة تنتظرنا - قرر المطورون التخلي تمامًا عن وحدة التحكم EHCI (واجهة وحدة التحكم المضيفة المحسنة) لصالح XHCI (واجهة وحدة التحكم المضيفة القابلة للتوسيع). بمعنى آخر، جميع منافذ USB الموجودة على هذه اللوحة الأم هي منافذ USB 3.0. وإذا قمنا بتعطيل وحدة تحكم XHCI، فسنقوم أيضًا بتعطيل أجهزة الإدخال، مما يجعل من المستحيل العمل مع الخادم، وبالتالي تثبيت نظام التشغيل.

نظرًا لأن منصات الخادم لم تكن مجهزة بمحركات أقراص لقراءة أقراص CD/DVD، كان الحل الوحيد للمشكلة هو دمج برامج التشغيل مباشرة في توزيع نظام التشغيل. فقط من خلال دمج برامج تشغيل وحدة التحكم USB 3.0 وإعادة بناء صورة التثبيت، تمكنا من تثبيت Windows Server 2008 R2 على هذا الخادم، وتم تضمين هذه الحالة في قاعدة معارفنا حتى لا يضيع المهندسون وقتًا غير ضروري في محاولات غير مثمرة.

والأكثر تسلية هو الحالات التي يجلب فيها العملاء لنا معدات للتنسيب، ولا تتصرف كما هو متوقع. هذا هو بالضبط ما حدث مع خط أرفف الأقراص Dell PowerVault.

الجهاز عبارة عن نظام تخزين بيانات مزود بوحدتي تحكم للأقراص وواجهات شبكة للعمل عبر بروتوكول iSCSI. بالإضافة إلى هذه الواجهات، يوجد منفذ MGMT للإدارة عن بعد.

من بين خدماتنا للمعدات المستضافة هناك خدمة خاصة "منفذ إضافي بسرعة 10 ميجابت/ثانية"، والتي يمكن طلبها إذا كان من الضروري توصيل أدوات إدارة الخادم عن بعد. هذه الصناديق تحمل أسماء مختلفة:

• "iLO" من شركة Hewlett-Packard؛
• "iDrac" من شركة Dell؛
• IPMI من شركة سوبرمايكرو.

وظائفهم هي نفسها تقريبًا - مراقبة حالة الخادم والوصول إلى وحدة التحكم عن بعد. وبناء على ذلك، فهي لا تتطلب سرعة قناة عالية - 10 ميجابت/ثانية كافية للعمل المريح. هذه هي الخدمة التي طلبها العميل. لقد وضعنا التوزيع المناسب للنحاس وقمنا بتكوين منفذ معدات شبكتنا.

للحد من السرعة، يتم تكوين المنفذ ببساطة على أنه 10BASE-T ويتم تمكينه بسرعة قصوى تبلغ 10 ميجابت في الثانية. بعد أن أصبح كل شيء جاهزًا، قمنا بتوصيل منفذ MGMT الخاص برف القرص، لكن العميل أبلغ على الفور تقريبًا أنه لم يكن هناك شيء يعمل معه.

بعد التحقق من حالة منفذ التبديل، اكتشفنا الرسالة غير السارة "الرابط الفعلي معطل". تشير هذه الرسالة إلى وجود مشكلة في الاتصال الفعلي بين المحول وجهاز العميل المتصل به.

موصل مجعد بشكل سيء، موصل مكسور، أسلاك مكسورة في الكابل - هذه قائمة صغيرة من المشاكل التي تؤدي على وجه التحديد إلى عدم وجود رابط. بالطبع، أخذ مهندسونا على الفور جهاز اختبار الزوج الملتوي وفحصوا الاتصال. تم توصيل جميع الأسلاك بشكل مثالي، وتم تجعيد طرفي الكابل بشكل مثالي. بالإضافة إلى ذلك، من خلال توصيل كمبيوتر محمول اختباري بهذا الكابل، حصلنا على اتصال بسرعة 10 ميجابت/ثانية كما هو متوقع. أصبح من الواضح أن المشكلة كانت في جانب معدات العميل.

نظرًا لأننا نحاول دائمًا مساعدة عملائنا على حل المشكلات، فقد قررنا معرفة السبب الدقيق لعدم وجود رابط. لقد فحصنا بعناية موصل منفذ MGMT - كل شيء على ما يرام.

لقد وجدنا تعليمات التشغيل الأصلية على موقع الشركة المصنعة لتوضيح ما إذا كان من الممكن "إطفاء" هذا المنفذ من جانب البرنامج. ومع ذلك، لم يتم توفير هذا الاحتمال - تم رفع المنفذ تلقائيًا على أي حال. على الرغم من حقيقة أن هذه المعدات يجب أن تدعم دائمًا Auto-MDI(X) - بمعنى آخر، تحديد الكبل المتصل بشكل صحيح: عادي أو متقاطع، من أجل التجربة، قمنا بتجعيد التقاطع وإدراجه في نفس منفذ التبديل. لقد حاولنا فرض معلمة الطباعة على الوجهين على منفذ التبديل. كان التأثير صفرًا، ولم يكن هناك أي رابط وكانت الأفكار تنفد بالفعل.

هنا قام أحد المهندسين بافتراض غير بديهي تمامًا بأن المعدات لا تدعم 10BASE-T وستعمل فقط على 100BASE-TX أو حتى 1000BASE-X. عادةً ما يكون أي منفذ، حتى على الجهاز الأرخص، متوافقًا مع 10BASE-T، وفي البداية تم رفض افتراض المهندس باعتباره "خيالًا"، ولكن بسبب اليأس قرروا محاولة تبديل المنفذ إلى 100BASE-TX.

لم تكن مفاجأتنا تعرف حدودًا؛ السبب الدقيق وراء عدم دعم 10BASE-T على منفذ MGMT يظل لغزًا. مثل هذه الحالة نادرة جدًا، لكنها تحدث.

لم يكن العميل أقل مفاجأة منا وكان ممتنًا جدًا لحل المشكلة. وبناء على ذلك، فقد تركوا المنفذ في 100BASE-TX، مما يحد من السرعة على المنفذ مباشرة باستخدام آلية تحديد السرعة المدمجة.

فشل توربينات التبريد

في أحد الأيام، جاء إلينا أحد العملاء وطلب منا إزالة الخادم ونقله إلى منطقة الخدمة. لقد فعل المهندسون كل شيء وتركوه بمفرده مع المعدات. مرت ساعة، اثنان، ثلاثة - استمر العميل في تشغيل/إيقاف الخادم وسألنا عن المشكلة.

اتضح أن اثنين من توربينات التبريد الستة الموجودة على خادم Hewlett-Packard تعطلت. يتم تشغيل الخادم ويعرض خطأ في التبريد ويتم إيقاف تشغيله على الفور. في هذه الحالة، يستضيف الخادم برنامج Hypervisor مع الخدمات الهامة. لاستعادة التشغيل العادي للخدمات، كان من الضروري ترحيل الأجهزة الافتراضية بشكل عاجل إلى عقدة فعلية أخرى.

قررنا مساعدة العميل بالطريقة التالية. عادةً ما يفهم الخادم أن كل شيء على ما يرام مع مروحة التبريد بمجرد قراءة عدد الثورات. في الوقت نفسه، بالطبع، قام مهندسو شركة Hewlett-Packard بكل شيء للتأكد من أنه من المستحيل استبدال التوربين الأصلي بموصل تناظري غير قياسي، Pinout غير قياسي.

تبلغ تكلفة القطعة الأصلية من هذا النوع حوالي 100 دولار، ولا يمكنك الذهاب وشرائها ببساطة - بل يتعين عليك طلبها من الخارج. لحسن الحظ، وجدنا على الإنترنت دائرة بها منفذ أصلي واكتشفنا أن أحد الأطراف مسؤول عن قراءة عدد دورات المحرك في الثانية.

كان الباقي مسألة تقنية - لقد أخذنا بضعة أسلاك للنماذج الأولية (بالصدفة كنا في متناول اليد - بعض مهندسينا مهتمون بـ Arduino) وقمنا ببساطة بتوصيل المسامير من التوربينات العاملة المجاورة بموصلات التوربينات الفاشلة . بدأ الخادم وتمكن العميل أخيرًا من ترحيل الأجهزة الافتراضية وبدء الخدمات.

بالطبع، تم كل هذا تحت مسؤولية العميل فقط، ومع ذلك، في النهاية، مثل هذه الخطوة غير القياسية جعلت من الممكن تقليل وقت التوقف عن العمل إلى الحد الأدنى.

أين الأقراص؟

في بعض الحالات، يكون سبب المشكلة في بعض الأحيان غير تافه بحيث يستغرق العثور عليه قدرًا كبيرًا من الوقت. هذا ما حدث عندما اشتكى أحد عملائنا من فشل عشوائي في القرص وتجميد الخادم. منصة الأجهزة - Supermicro في العلبة 847 (عامل الشكل 4U) مع أقفاص لتوصيل 36 محرك أقراص. كان الخادم مزودًا بثلاث وحدات تحكم Adaptec RAID متطابقة، كل منها بها 12 قرصًا متصلاً. عندما حدثت المشكلة، توقف الخادم عن رؤية عدد عشوائي من الأقراص وتجمد. تم إخراج الخادم من الإنتاج وبدأ التشخيص.

أول شيء تمكنا من اكتشافه هو أن الأقراص كانت تتساقط على وحدة تحكم واحدة فقط. في الوقت نفسه، اختفت "محركات الأقراص المسقطة" من القائمة الموجودة في الأداة المساعدة لإدارة Adaptec الأصلية ولم تظهر مرة أخرى إلا عند إيقاف تشغيل الخادم بالكامل ثم توصيله. أول ما يتبادر إلى ذهني هو برنامج التحكم. تحتوي جميع وحدات التحكم الثلاثة على برامج ثابتة مختلفة قليلاً، لذلك تقرر تثبيت نفس إصدار البرنامج الثابت على جميع وحدات التحكم. لقد فعلنا ذلك، وقمنا بتشغيل الخادم في أوضاع التحميل القصوى - كل شيء يعمل كما هو متوقع. وبعد وضع علامة على أن المشكلة قد تم حلها، تم إرجاع الخادم إلى العميل للإنتاج.

وبعد اسبوعين مرة اخرى بنفس المشكلة تقرر استبدال وحدة التحكم بوحدة مماثلة. لقد أكملناها، وقمنا بوميضها، وقمنا بتوصيلها، وقمنا باختبارها. ظلت المشكلة قائمة - بعد بضعة أيام، سقطت جميع الأقراص الموجودة على وحدة التحكم الجديدة وتجمد الخادم بأمان.

قمنا بإعادة تثبيت وحدة التحكم في فتحة أخرى، واستبدلنا اللوحة الإلكترونية المعززة وكابلات SATA من وحدة التحكم إلى اللوحة الإلكترونية المعززة. أسبوع من الاختبار وسقطت الأقراص مرة أخرى - تجمد الخادم مرة أخرى. لم يؤدي الاتصال بدعم Adaptec إلى أي نتائج - فقد قاموا بفحص جميع وحدات التحكم الثلاثة ولم يجدوا أي مشاكل. لقد استبدلنا اللوحة الأم، وأعدنا بناء المنصة من الصفر تقريبًا. تم استبدال كل ما أثار أدنى شك بأخرى جديدة. وعادت المشكلة للظهور. التصوف ولا شيء أكثر من ذلك.

تم حل المشكلة عن طريق الصدفة عندما بدأوا في فحص كل قرص على حدة. تحت حمولة معينة، بدأ أحد محركات الأقراص في ضرب رؤوسهم وقصر الدائرة إلى منفذ SATA، في حين لم يكن هناك إشارة إنذار. وفي الوقت نفسه، توقفت وحدة التحكم عن رؤية بعض الأقراص وبدأت في التعرف عليها مرة أخرى فقط عند إعادة توصيل مصدر الطاقة. هذه هي الطريقة التي أدى بها قرص واحد فاشل إلى تدمير النظام الأساسي للخادم بالكامل.

خاتمة

وبطبيعة الحال، هذا ليس سوى جزء صغير من المواقف المثيرة للاهتمام التي تم حلها من قبل مهندسينا. يصعب "التقاط" بعض المشكلات، خاصة عندما لا يكون هناك أي تلميح في سجلات الفشل الذي حدث. لكن أيًا من هذه المواقف تحفز المهندسين على فهم تصميم معدات الخادم بالتفصيل وإيجاد مجموعة واسعة من الحلول للمشكلات.

هذه هي الحالات المضحكة التي حدثت في ممارستنا.
ما هي تلك التي واجهتها؟ مرحبا بكم في التعليقات.