ما هو موازن الأحمال؟ كيف تُوزَّع حركة المرور وتُفحص ويُعاد توجيهها

ما الذي يفعله موازن الأحمال

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

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

الوظيفة الثانية غالبًا الأهم: خادمان خلف موازن أحمال أقل ما يتعلقان بالسعة وأكثر ما يتعلقان بأن يُسمح لأحدهما بالتعطل. موازن أحمال من الطبقة 7 هو نوع من الوكيل العكسي وظيفته الاختيار بين خوادم خلفية متطابقة؛ يقوم HAProxy وnginx بالوظيفتين.

موازنة الطبقة 4 مقابل الطبقة 7

الطبقة هي مقدار حركة المرور التي يقرأها موازن الأحمال قبل أن يقرر.

يعمل موازن أحمال الطبقة 4 مع اتصالات TCP وحزم UDP. يرى عناوين ومنافذ المصدر والوجهة، ويختار خادمًا خلفيًا عند فتح الاتصال، وينسخ البايتات في الاتجاهين. لا يستطيع رؤية رابط أو ترويسة أو ملف تعريف ارتباط، فكل طلب على ذلك الاتصال يذهب إلى الخادم نفسه. في المقابل هو سريع، ومحايد تجاه البروتوكول (قواعد البيانات، MQTT، SMTP، خوادم الألعاب)، ويستطيع تمرير TLS كما هو، فتبقى الشهادة على الخوادم الخلفية. هنا يعمل mode tcp في HAProxy وكتلة stream {} في nginx.

يتحدث موازن أحمال الطبقة 7 HTTP. ينهي الاتصال، ويقرأ كل طلب، ويستطيع التوجيه بحسب المضيف أو المسار أو الترويسة أو ملف تعريف الارتباط: /api إلى مجموعة، و/ إلى أخرى، وملف تعريف ارتباط للإصدار التجريبي (canary) إلى النسخة الجديدة. يستطيع إعادة محاولة طلب فاشل على خادم آخر وتوزيع طلبات اتصال HTTP/2 واحد على عدة خوادم خلفية (HAProxy بـmode http، وnginx بـhttp {}).

لقراءة HTTP، يجب أن يفكّ موازن الطبقة 7 تشفيرها، فتأتي إنهاء TLS مع الصفقة. تعيش الشهادة على موازن الأحمال وتحصل الخوادم الخلفية على HTTP عادي في شبكة خاصة، أو اتصال TLS ثانٍ إن لم تكن الشبكة موثوقة. التكلفة أن الخادم الخلفي لا يرى العميل بعد ذلك: يرى موازن الأحمال. تحل موازنات الطبقة 7 ذلك بـX-Forwarded-For وX-Forwarded-Proto؛ وتستخدم موازنات الطبقة 4 بروتوكول PROXY، الذي يجب ضبط الخادم الخلفي ليقبله.

خوارزميات الموازنة: Round Robin وLeast Connections والتجزئة والأوزان

Round Robin يسلّم الطلبات لكل خادم بالتناوب. هو الافتراضي في كل مكان تقريبًا، ومناسب عندما تكلّف الطلبات نحو الشيء نفسه والخوادم متطابقة.

Round Robin الموزون (Weighted) يمنح الخادم الأكبر حصة أكبر: بأوزان 2 و2 و1، يحصل الخادم الثالث على خُمس حركة المرور. الأوزان أيضًا هي كيف تُشغّل إصدارًا تجريبيًا (canary): أضِف النسخة الجديدة إلى المجموعة بوزن صغير، وراقب معدل أخطائها، ثم ارفعه.

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

تجزئة IP (balance source في HAProxy، وip_hash في nginx) تربط كل عنوان عميل بالخادم نفسه كل مرة. تمنحك انتماءً دون ملفات تعريف ارتباط، لكن التوزيع يتبع تركيبة العملاء: مكتب واحد أو شركة اتصالات محمولة واحدة خلف عنوان مشترك قد تُنزل آلاف المستخدمين على خادم خلفي واحد.

التجزئة المتماسكة (Consistent hashing) على مفتاح (الرابط، معرّف مستخدم) تحافظ على المفتاح نفسه عند الخادم نفسه، وعند إضافة خادم أو إزالته تنتقل حصة صغيرة فقط من المفاتيح. هذا ما تريده أمام ذاكرات التخزين المؤقت: جزّئ بحسب الرابط كي يعيش كل عنصر في ذاكرة تخزين مؤقت واحدة بدل كلها. يكتبها nginx كـhash $request_uri consistent;، وHAProxy كـbalance uri مع hash-type consistent.

أي ما تختاره، تهم الخوارزمية أقل من فحوص صحة تقول الحقيقة.

فحوص الصحة وإعادة التوجيه عند الفشل

موازن الأحمال ليس أفضل من فكرته عن أي الخوادم على قيد الحياة.

فحوص الصحة النشطة تستجوب كل خادم خلفي على جدول زمني: فتح اتصال TCP، أو طلب رابط مثل /healthz وتوقّع 200. بعد fall فشلًا متتاليًا يُعلَّم الخادم معطّلًا ولا يستقبل شيئًا؛ وبعد rise نجاحًا يعود. يفعل HAProxy ذلك في النسخة مفتوحة المصدر. لا يفعل nginx مفتوح المصدر ذلك: max_fails وfail_timeout فحوص سلبية، تعدّ الطلبات الفعلية الفاشلة وتُريح الخادم لفترة. الفحوص النشطة في nginx جزء من NGINX Plus التجاري. التوقيت مقايضة: فحص كل ثانيتين مع fall 3 يُزيل خادمًا معطّلًا في نحو ست ثوانٍ؛ وكل 30 ثانية يعني دقيقة ونصف من الأخطاء.

إعادة التوجيه عند الفشل (failover) هي ما يحدث بعدها. تنتقل حركة المرور إلى الخوادم المتبقية، فيجب أن يكون لديها مكان لها: ثلاثة خوادم يعمل كل منها بنسبة 80% لا تستطيع استيعاب فقدان واحد منها. يستقبل خادم backup حركة المرور فقط عندما يكون كل خادم أساسي معطّلًا، وهذا يناسب نسخة احتياطية باردة أو صفحة صيانة.

اجعل نقطة فحص الصحة تجيب عن السؤال الذي يطرحه موازن الأحمال: *هل ينبغي أن يحصل هذا الخادم على حركة مرور الآن؟* يعني ذلك فحص ما هو محلي للعملية (بدأت، تستطيع الوصول إلى اعتمادياتها الخاصة، ليست في طور الإغلاق) والرد بسرعة. خلال النشر، أفشِل الفحص أولًا، واترك الطلبات الجارية تنتهي (استنزاف الاتصالات / connection draining)، ثم أوقف العملية.

ثبات الجلسة (Sticky Sessions)

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

الطرق المعتادة هي ملف تعريف ارتباط مُدرَج (يضيف موازن الأحمال ملف تعريف ارتباط يسمّي الخادم، كما يفعل HAProxy بـcookie SRV insert indirect nocache إضافةً إلى قيمة cookie على كل سطر server)، أو ملف تعريف ارتباط تطبيقي يتعلّم منه (PHPSESSID، JSESSIONID)، أو تجزئة عنوان المصدر. يملك nginx مفتوح المصدر طرق التجزئة فقط (ip_hash أو hash $cookie_name)؛ أما توجيه sticky فيخص NGINX Plus.

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

الحل الدائم هو جعل الخوادم قابلة للتبديل: احفظ الجلسات في مخزن مشترك مثل Redis أو قاعدة البيانات، أو في ملف تعريف ارتباط موقَّع، واترك أي خادم يجيب عن أي طلب. عندها لا يكلّف خادم فاشل أحدًا تسجيل دخوله.

ضبط عملي لـHAProxy

يُقرأ ضبط HAProxy من الأعلى إلى الأسفل: global للعملية، وdefaults يرثها كل قسم، وfrontend يستقبل الاتصالات، وbackend يحمل المجموعة.

ينهي المثال TLS على المنفذ 443 (يحمل ملف .pem سلسلة الشهادة والمفتاح الخاص معًا)، ويعيد توجيه HTTP العادي، ويضيف ترويسات التمرير، ويوازن بـLeast Connections. فحص الصحة طلب HTTP حقيقي بترويسة Host، لأن كثيرًا من التطبيقات تجيب بـ404 أو إعادة توجيه على طلب بلا واحدة، وفحص يتوقع 200 يفشل آنذاك على خادم سليم. يحتاج http-check send إلى HAProxy 2.2 أو أحدث؛ وتضع الإصدارات الأقدم الطلب على سطر option httpchk.

يضبط default-server توقيت الفحص مرة واحدة: استجواب كل ثانيتين، وثلاث حالات فشل لتعليم خادم معطّلًا، ونجاحان لإعادته. app3 جهاز أصغر ويأخذ نصف حصة الآخرين؛ ويحصل spare على حركة مرور فقط عندما تتعطل الثلاثة جميعًا. لجعل الجلسات ثابتة، أضِف cookie SRV insert indirect nocache إلى المجموعة الخلفية وcookie app1 (وكذلك البقية) لكل سطر خادم.

تحقق من الملف بـhaproxy -c -f /etc/haproxy/haproxy.cfg قبل كل إعادة تحميل.

/etc/haproxy/haproxy.cfg: إنهاء TLS، Least Connections، فحوص صحة HTTP

global
    log /dev/log local0
    maxconn 20000

defaults
    mode http
    log global
    option httplog
    timeout connect 5s
    timeout client  60s
    timeout server  60s

frontend fe_web
    bind :80
    bind :443 ssl crt /etc/haproxy/certs/example.com.pem alpn h2,http/1.1
    http-request redirect scheme https unless { ssl_fc }
    option forwardfor
    http-request set-header X-Forwarded-Proto https
    default_backend be_app

backend be_app
    balance leastconn
    option httpchk
    http-check send meth GET uri /healthz ver HTTP/1.1 hdr Host app.example.com
    http-check expect status 200
    default-server inter 2s fall 3 rise 2
    server app1 10.0.0.11:8080 check weight 100
    server app2 10.0.0.12:8080 check weight 100
    server app3 10.0.0.13:8080 check weight 50
    server spare 10.0.0.20:8080 check backup

موازنة الأحمال بـupstream في nginx

في nginx، المجموعة كتلة upstream ويشير proxy_pass إليها باسمها. بلا سطر خوارزمية، يستخدم nginx Round Robin الموزون؛ وتغيّر ذلك least_conn وip_hash وhash … consistent وrandom.

بعض التفاصيل في المثال سهلة الإغفال. يحافظ keepalive 32 على اتصالات خاملة مع الخوادم الخلفية مفتوحة لإعادة استخدامها، لكنه يعمل فقط مع proxy_http_version 1.1 وترويسة Connection فارغة؛ وبدون هذين السطرين يفتح nginx اتصالًا جديدًا لكل طلب. max_fails=3 fail_timeout=10s يُخرج خادمًا لعشر ثوانٍ بعد ثلاث طلبات فاشلة خلال عشر ثوانٍ: هذا فحص الصحة السلبي في nginx. يعمل backup فقط مع Round Robin والموزون وLeast Connections، لا مع طرق التجزئة.

proxy_next_upstream يقرر متى تُعاد محاولة طلب فاشل على الخادم التالي. افتراضيًا يعيد nginx المحاولة عند أخطاء الاتصال والمهلات، ومنذ 1.9.13 لا يعيد المحاولة أبدًا على POST أو LOCK أو PATCH إلا بإضافة non_idempotent. حافظ على ذلك: إعادة محاولة دفعة لأن الخادم الأول انتهت مهلته بعد خصم المبلغ من البطاقة أسوأ من رسالة خطأ. يمنع proxy_next_upstream_tries 2 طلبًا بطيئًا واحدًا من اجتياح المجموعة كاملة. الترويسات هي نفسها التي يحتاجها أي وكيل عكسي؛ ودليل nginx يغطي الباقي.

nginx: مجموعة upstream بأوزان، وفحوص سلبية، وخادم احتياطي، وkeep-alive

upstream app {
    least_conn;
    server 10.0.0.11:8080 weight=2 max_fails=3 fail_timeout=10s;
    server 10.0.0.12:8080 weight=2 max_fails=3 fail_timeout=10s;
    server 10.0.0.13:8080          max_fails=3 fail_timeout=10s;
    server 10.0.0.20:8080 backup;
    keepalive 32;
}

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate     /etc/ssl/example.com/fullchain.pem;
    ssl_certificate_key /etc/ssl/example.com/privkey.pem;

    location / {
        proxy_pass http://app;
        proxy_http_version 1.1;
        proxy_set_header Connection        "";
        proxy_set_header Host              $host;
        proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_next_upstream error timeout http_502 http_503;
        proxy_next_upstream_tries 2;
        proxy_connect_timeout 3s;
    }
}

العالمي مقابل المحلي: DNS وGeoDNS وAnycast وموازنات الأحمال السحابية

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

تناوب DNS (DNS round robin) هو الشكل الأقدم: نشر عدة سجلات A ويسلّمها المحلّلون بترتيب متناوب. لا يكلّف شيئًا ويوزّع حركة المرور تقريبًا، لكن DNS لا يعرف شيئًا عن الصحة. يستمر تسليم عنوان خادم ميت حتى يزيله أحد، وتخزّن المحلّلات والمتصفحات الرد القديم طوال TTL السجل وأحيانًا أطول.

GeoDNS يرد بشكل مختلف بحسب مصدر الاستعلام، فيحصل الزوار في بلد ما على عنوان الموقع القريب. مع فحوص صحة من جهة DNS، يصبح إعادة توجيه DNS عند الفشل (DNS failover): تُسحب منطقة تفشل فحوصها من الردود. القيود هي نفس تخزين TTL المؤقت، وحقيقة أن الموقع هو موقع المحلّل لا الزائر، إلا إن مرّر المحلّل جزءًا من عنوان العميل (EDNS Client Subnet). يغطي دليل DNS مدد TTL والمحلّلات بالتفصيل.

Anycast يعلن عنوان IP نفسه من مواقع كثيرة عبر BGP، ويسلّم توجيه الإنترنت كل حزمة إلى الأقرب. لا يوجد TTL للانتظار: عندما يتوقف موقع عن الإعلان، تنتقل المسارات خلال ثوانٍ إلى دقائق. هكذا تصل خدمات DNS الكبيرة وشبكات CDN إلى عقدها. تتراكب الطبقات: يختار DNS أو Anycast الموقع، ويختار وكيل بداخله الخادم.

موازنات الأحمال السحابية تحزم الأفكار نفسها كخدمة مُدارة. لدى AWS موازن تحميل التطبيقات (طبقة 7) وموازن تحميل الشبكة (طبقة 4)؛ وتقدّم Google Cloud Load Balancing نسخًا عالمية وإقليمية، وتطبيقية وشبكية؛ وتفصل Azure موازن Azure Load Balancer (طبقة 4) عن Application Gateway (طبقة 7). في Kubernetes، يوزّع Service الاتصالات على الحاويات (pods) وتقوم وحدة تحكم Ingress بالتوجيه من الطبقة 7. الخوارزميات وفحوص الصحة والأخطاء الشائعة في هذا الدليل تنطبق عليها دون تغيير.

أخطاء شائعة تسبب الأعطال

موازن الأحمال هو نقطة الفشل الوحيدة. ثلاثة خوادم تطبيقات خلف جهاز HAProxy واحد يعني أن الجهاز صار الآن ما يُسقطك. شغّل اثنين وانقل عنوان IP عائم بينهما بـVRRP (keepalived هي الأداة المعتادة)، أو ضع طبقة مُدارة أو على مستوى DNS أمامهما. ثم اختبر ذلك بإيقاف العنصر النشط.

فحص الصحة يكذب، في أي من الاتجاهين. /healthz يُرجع 200 دائمًا يُبقي خادمًا استُنزِف مجمع اتصالات قاعدة بياناته في التدوير، فتفشل حصة من الطلبات بينما تُظهر لوحة التحكم كل شيء أخضر. العكس سيئ بنفس القدر: فحص يستجوب قاعدة البيانات المشتركة يُخرج *كل* خادم أثناء تعثر قاعدة بيانات لخمس ثوانٍ، فيصبح تباطؤ قصير عطلًا كاملًا. افحص الخادم، لا الأنظمة التي يتشاركها كل الخوادم.

مهلات غير متطابقة. إن أغلق الخادم الخلفي اتصالات keep-alive الخاملة أسرع مما يتوقع موازن الأحمال، يرسل الموازن أحيانًا طلبًا عبر اتصال أغلقه الخادم الخلفي للتو، ويحصل العميل على 502 متقطع. حافظ على مهلة keep-alive للخادم الخلفي أطول من مهلة الخمول في موازن الأحمال. أسباب أكثر في دليل 502 Bad Gateway.

عنوان العميل يختفي. دون X-Forwarded-For (طبقة 7) أو بروتوكول PROXY (طبقة 4)، يسجّل التطبيق عنوان موازن الأحمال، ويحدد المعدل وموقعه الجغرافي بحسبه.

خوادم غير متطابقة. بُنى مختلفة، أو ضبط مختلف، أو أختام زمنية مختلفة للملفات تغيّر ETag الافتراضي، فتعيد إعادة تحقق المتصفح 200 كاملة بدل 304 كل مرة يجيب الخادم الآخر. انشر أصلًا واحدًا في كل مكان.

الاختبار بسيط. اعرض اسم الخادم الخلفي في ترويسة استجابة أثناء الاختبار، وكرّر الطلبات؛ راقب التوزيع، ثم أوقف خادمًا خلفيًا وراقب انتقال الطلبات.

# which backend answered? (expose the server name in a debug header first)
for i in $(seq 1 10); do
  curl -s -o /dev/null -D - https://example.com/ | grep -i '^x-served-by'
done

# HAProxy: live state of every server through the runtime socket
# (needs "stats socket /run/haproxy/admin.sock mode 660 level admin" in global)
echo "show servers state be_app" | socat stdio /run/haproxy/admin.sock

# take one server out gracefully before a deploy, then put it back
echo "set server be_app/app1 state drain" | socat stdio /run/haproxy/admin.sock
echo "set server be_app/app1 state ready" | socat stdio /run/haproxy/admin.sock

أين يتموضع CDN، وماذا يفعل CDN.com.tr

CDN هو موازنة أحمال عالمية لا تحتاج إلى بنائها. يُوجَّه الزوار إلى خادم حافة قريب منهم، وتجيب الحافة من ذاكرتها المؤقتة بما تستطيع، ولا يسافر إلى مصدرك إلا ما لا يُصاب (misses). يشغّل CDN.com.tr خوادم حافة في تركيا وخارجها ويوزّع الزوار عليها، فتوزيع الزوار عبر المواقع منجز أصلًا قبل أن يصل طلب إلى أي شيء تديره.

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

تخفف الحافة أيضًا من أعطال المصدر. يستمر تقديم المحتوى الموجود أصلًا في ذاكرة الحافة المؤقتة طوال TTL خاصته بينما المصدر متعطّل، ويعلّم تقرير جودة حركة المرور نسخة مخزَّنة قُدّمت بينما كان المصدر بطيئًا أو متعطّلًا بـSTALE. ويُظهر التقرير نفسه صحة المصدر: طلبات إلى المصدر، وحصة إعادة المحاولة، وأخطاء الاتصال (502/504)، ومتوسط زمن المصدر للبايت الأول. لا تزال العناصر غير المخزَّنة والمنتهية الصلاحية تحتاج مصدرًا عاملًا، ولهذا لا يزال المصدر يحتاج تكراره الخاص للصفحات الديناميكية.

إن كنت تفضّل عدم تشغيل تلك الطبقة إطلاقًا، تأخذ تطبيقات الحاويات على CDN.com.tr عدد نسخ متماثلة وفحص صحة (مسار HTTP، أو TCP، أو بلا فحص) لكل تطبيق. تدخل حركة المرور عبر الحافة؛ ومع عدة نسخ، إن كانت حاوية تُعاد تشغيلها أو غير سليمة تستمر الأخرى بالخدمة، وتخضع عمليات الطرح (rollouts) لبوابة الصحة، فنشر إصدار جديد لا يفتح نافذة يصبح فيها التطبيق غير قابل للوصول. تدخل الجلسات إلى Redis المُدار، فيبقى المستخدم مسجّل الدخول أي نسخة أجابت عن طلبه التالي: التصميم بلا حالة الموصى به أعلاه، بلا ملف تعريف ارتباط ثابت.