> ## Content Index > Fetch the complete content index at: https://arabroot.io/llms.txt > Use this file to discover other available public pages before exploring further. # موازنة الحمل Load Balancing أمام خوادم Asterisk مع Kamailio - URL: https://arabroot.io/articles/موازنة-الحمل-أمام-خوادم-asterisk-مع-kamailio/ - Published: 2026-10-19T08:15:00.000Z - Updated: 2026-10-20T20:47:12.000Z - Description: نضع Kamailio وسيطاً أمام خادمي Asterisk، ونوزع المكالمات بينهما بوحدة dispatcher، ونرى الإخفاق Failover عند توقف أحدهما، ونصد فيضاناً بوحدة pike. - Author: فريق عرب رووت - Tags: الأدلة التقنية, الاستضافة الذاتية والتطبيقات, الشبكات والوصول, تطبيقات لفريقك, Kamailio في مقالات هذه المرحلة بنينا المقسم على خادم Asterisk واحد، وهذا يكفي مكتباً أو شركة متوسطة، ولكن ماذا لو كبر العدد إلى آلاف المكالمات في الوقت نفسه، أو أردت أن تحدث الخادم دون أن تقطع المكالمات، أو أن تصمد الخدمة لو تعطل خادم؟ الخادم الواحد هنا نقطة فشل واحدة Single Point of Failure، فإذا توقف توقف كل شيء، وإذا امتلأ لم يبق مكان. والحل أن تضع أمام الخوادم وسيطاً ذكياً يوزع المكالمات عليها ويتجاوز المتعطل منها، وهذا بالضبط عمل [Kamailio](https://www.kamailio.org/w/?ref=arabroot.io). وهذا المقال من [مرحلة الاتصالات الهاتفية VoIP](https://arabroot.io/start/#stage-voip)، وهو آخرها، وسوف نبني فيه Kamailio وسيطاً أمام خادمي Asterisk، ونوزع المكالمات بينهما، ثم نوقف أحدهما عمداً ونرى كيف يتابع النظام دون أن يشعر المتصل. وكل ذلك داخل شبكة Docker داخلية معزولة على جهازك. وفيما يلي ترتيب مقالات المرحلة: - [مصطلحات الاتصالات الهاتفية VoIP للمبتدئين](https://arabroot.io/articles/%D9%85%D8%B5%D8%B7%D9%84%D8%AD%D8%A7%D8%AA-voip-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86/) - [تتبع مكالمة SIP عبر الشبكة: لماذا يصل الصوت في اتجاه واحد؟](https://arabroot.io/articles/%D8%AA%D8%AA%D8%A8%D8%B9-%D9%85%D9%83%D8%A7%D9%84%D9%85%D8%A9-sip-%D8%B9%D8%A8%D8%B1-%D8%A7%D9%84%D8%B4%D8%A8%D9%83%D8%A9-%D9%88%D8%A7%D9%84%D8%B5%D9%88%D8%AA-%D9%81%D9%8A-%D8%A7%D8%AA%D8%AC%D8%A7%D9%87-%D9%88%D8%A7%D8%AD%D8%AF/) - [لماذا يتقطع الصوت في مكالمات VoIP؟ قياس Jitter وPacket Loss](https://arabroot.io/articles/%D9%84%D9%85%D8%A7%D8%B0%D8%A7-%D9%8A%D8%AA%D9%82%D8%B7%D8%B9-%D8%A7%D9%84%D8%B5%D9%88%D8%AA-%D9%81%D9%8A-%D9%85%D9%83%D8%A7%D9%84%D9%85%D8%A7%D8%AA-voip/) - [ربط المقسم PBX بشبكة الهاتف عبر SIP Trunk والأرقام DID](https://arabroot.io/articles/%D8%B1%D8%A8%D8%B7-%D8%A7%D9%84%D9%85%D9%82%D8%B3%D9%85-%D8%A8%D8%B4%D8%A8%D9%83%D8%A9-%D8%A7%D9%84%D9%87%D8%A7%D8%AA%D9%81-%D8%B9%D8%A8%D8%B1-sip-trunk/) - [دليل Asterisk العملي: من التحويلة Extension إلى الرد الآلي IVR](https://arabroot.io/articles/%D8%AF%D9%84%D9%8A%D9%84-asterisk-%D8%A7%D9%84%D8%B9%D9%85%D9%84%D9%8A-%D9%85%D9%86-%D8%A7%D9%84%D8%AA%D8%AD%D9%88%D9%8A%D9%84%D8%A9-%D8%A7%D9%84%D9%89-%D8%A7%D9%84%D8%B1%D8%AF-%D8%A7%D9%84%D8%A7%D9%84%D9%8A/) - [FreePBX: مقسم هاتف PBX كامل تديره من المتصفح](https://arabroot.io/articles/freepbx-%D9%85%D9%82%D8%B3%D9%85-%D9%87%D8%A7%D8%AA%D9%81-%D9%83%D8%A7%D9%85%D9%84-%D8%AA%D8%AF%D9%8A%D8%B1%D9%87-%D9%85%D9%86-%D8%A7%D9%84%D9%85%D8%AA%D8%B5%D9%81%D8%AD/) - [FreeSWITCH للمنصات الكبيرة ومراكز الاتصال Contact Center](https://arabroot.io/articles/freeswitch-%D9%84%D9%84%D9%85%D9%86%D8%B5%D8%A7%D8%AA-%D8%A7%D9%84%D9%83%D8%A8%D9%8A%D8%B1%D8%A9-%D9%88%D9%85%D8%B1%D8%A7%D9%83%D8%B2-%D8%A7%D9%84%D8%A7%D8%AA%D8%B5%D8%A7%D9%84/) - [3CX أم FreePBX أم FreeSWITCH؟ كيف تختار المقسم PBX](https://arabroot.io/articles/3cx-%D8%A7%D9%85-freepbx-%D8%A7%D9%85-freeswitch/) - [هواتف SIP المكتبية والتطبيقات: لماذا لا يرن الجوال النائم؟](https://arabroot.io/articles/%D9%87%D9%88%D8%A7%D8%AA%D9%81-sip-%D8%A7%D9%84%D9%85%D9%83%D8%AA%D8%A8%D9%8A%D8%A9-%D9%88%D8%A7%D9%84%D8%AA%D8%B7%D8%A8%D9%8A%D9%82%D8%A7%D8%AA-%D9%88%D8%A7%D9%84%D8%AC%D9%88%D8%A7%D9%84/) - [مركز اتصال Call Center على Asterisk: الطابور وتقرير SLA](https://arabroot.io/articles/%D9%85%D8%B1%D9%83%D8%B2-%D8%A7%D8%AA%D8%B5%D8%A7%D9%84-call-center-%D8%B9%D9%84%D9%89-asterisk/) - [تأمين المقسم من الاحتيال على المكالمات Toll Fraud](https://arabroot.io/articles/%D8%AA%D8%A3%D9%85%D9%8A%D9%86-%D8%A7%D9%84%D9%85%D9%82%D8%B3%D9%85-%D9%85%D9%86-%D8%A7%D9%84%D8%A7%D8%AD%D8%AA%D9%8A%D8%A7%D9%84-%D8%B9%D9%84%D9%89-%D8%A7%D9%84%D9%85%D9%83%D8%A7%D9%84%D9%85%D8%A7%D8%AA/) - موازنة الحمل Load Balancing أمام خوادم Asterisk مع Kamailio (الموضوع الحالي) وسوف نتناول فيه ما يلي: - ما دور وسيط SIP Proxy، وكيف يختلف عن المقسم Asterisk. - بناء المختبر: Kamailio أمام خادمي Asterisk في Containers. - توزيع الحمل Load Balancing بوحدة dispatcher، مع إثبات التوزيع بالأرقام. - الإخفاق Failover: توقف خادم وكيف يتجاوزه الوسيط تلقائياً، ثم عودته. - صد فيضان الطلبات بوحدة pike، والإشارة إلى معالج الصوت rtpengine. ## ما دور وسيط SIP Proxy؟ لتفهم دور Kamailio، قارنه بما يفعله Asterisk. فالمقسم Asterisk يسمى وكيل مستخدم خلفي Back-to-Back User Agent، واختصاراً B2BUA، أي أنه ينهي المكالمة عنده ثم ينشئ مكالمة جديدة نحو الطرف الآخر، فهو طرف كامل في كل مكالمة، يعالج الصوت، ويشغل البريد الصوتي، وينفذ خطة الاتصال. أما Kamailio فهو وسيط SIP Proxy، أي أنه يوجه رسائل SIP بين الأطراف دون أن ينهي المكالمة عنده، فلا يعالج الصوت ولا يشغل خطة اتصال، وإنما يقرر إلى أين تذهب الرسالة ويمررها، ثم يبتعد عن مسار الصوت. وهذا الفرق هو سر قدرة Kamailio على التحمل: لأنه لا يحمل عبء الصوت ولا منطق المكالمة، يستطيع خادم واحد منه أن يوجه عشرات الآلاف من المكالمات المتزامنة، بينما يقف خلفه عدد من خوادم Asterisk تتقاسم العمل الثقيل. والصورة التالية تبين التوزيع: ![هاتف يرسل مكالمته إلى وسيط Kamailio الذي يوزع المكالمات على خادمي Asterisk خلفه، as1 وas2، بالتناوب، فتذهب المكالمة الأولى إلى as1 والثانية إلى as2، بينما يبقى Kamailio خارج مسار الصوت الذي يمر مباشرة](https://arabroot.io/content/images/2026/10/kamailio-01-proxy-lb.webp) Kamailio يوجه الإشارة ويوزعها، وخوادم Asterisk تحمل عبء المكالمات وقد يتساءل البعض: لماذا لا نشغل عدة خوادم Asterisk ونوزع عليها في نظام الأسماء DNS؟ والإجابة أن DNS لا يعرف أي خادم ممتلئ وأيها متعطل، فقد يرسل المكالمة إلى خادم متوقف فتفشل، أما Kamailio فيفحص خوادمه باستمرار، ويعرف حالة كل منها، ويوزع بذكاء، ويتجاوز المتعطل في لحظته. ## خريطة المختبر نبني في المختبر Kamailio وسيطاً على العنوان 10.55.70.10، وخلفه خادما Asterisk على 10.55.70.21 و10.55.70.22، وهاتفاً برمجياً يتصل عبر الوسيط. وكل ذلك في شبكة Docker داخلية معزولة أنشأناها بالخيار `--internal`. والصورة التالية تبين الخريطة: ![شبكة Docker داخلية باسم are-kam-net على النطاق 10.55.70.0/24، فيها وسيط Kamailio باسم are-kam-proxy على 10.55.70.10، وخادما Asterisk باسم are-kam-as1 على 10.55.70.21 وare-kam-as2 على 10.55.70.22، وهاتف برمجي caller على 10.55.70.50 يتصل عبر الوسيط، والشبكة معزولة بلا طريق إلى الإنترنت](https://arabroot.io/content/images/2026/10/kamailio-02-lab-map.webp) وسيط واحد أمام خادمين، وكلها Containers على شبكة معزولة نستخدم لخادمي Asterisk الـ Image نفسها التي بنيناها في [مقال تأمين المقسم](https://arabroot.io/articles/%D8%AA%D8%A3%D9%85%D9%8A%D9%86-%D8%A7%D9%84%D9%85%D9%82%D8%B3%D9%85-%D9%85%D9%86-%D8%A7%D9%84%D8%A7%D8%AD%D8%AA%D9%8A%D8%A7%D9%84-%D8%B9%D9%84%D9%89-%D8%A7%D9%84%D9%85%D9%83%D8%A7%D9%84%D9%85%D8%A7%D8%AA/#lab-build)، وهي `are-pbxsec-tools:1`، ونبني لـ Kamailio Image صغيرة من Ubuntu 24.04 فيها الوحدات التي نحتاجها، ونثبت إصدار كل حزمة: ```dockerfile FROM ubuntu:24.04 RUN apt-get update \ && DEBIAN_FRONTEND=noninteractive apt-get install -y --no-install-recommends \ kamailio=5.7.4-1build7 \ kamailio-extra-modules=5.7.4-1build7 \ tcpdump=4.99.4-3ubuntu4.24.04.1 \ sngrep=1.8.0-1build2 \ iproute2 iputils-ping procps \ && rm -rf /var/lib/apt/lists/* ``` وخادما Asterisk إعدادهما واحد: كل منهما يثق بالوسيط Kamailio ويقبل مكالماته دون مصادقة بينهما، لأن المصادقة مهمة الوسيط. وهذا هو `as/pjsip.conf`، وفيه قسم `identify` يتعرف على الوسيط بعنوانه: ```text [transport-udp] type=transport protocol=udp bind=0.0.0.0:5060 [kamailio] type=endpoint context=from-proxy disallow=all allow=ulaw,alaw rtp_symmetric=yes force_rport=yes rewrite_contact=yes [kamailio] type=identify endpoint=kamailio match=10.55.70.10 ``` وخطة الاتصال في `as/extensions.conf` قصيرة: يرد الخادم على أي مكالمة وينتظر ثانيتين ثم يغلق، وهذا يكفي لنرى أي خادم رد على كل مكالمة من سجل المكالمات CDR: ```text [from-proxy] exten => _X.,1,NoOp(Backend handling call to ${EXTEN}) same => n,Answer() same => n,Wait(2) same => n,Hangup() ``` الآن ننشئ الشبكة الداخلية ونشغل الخادمين: ```bash docker network create --internal --subnet 10.55.70.0/24 are-kam-net for pair in as1:10.55.70.21 as2:10.55.70.22; do n=${pair%%:*}; ip=${pair#*:} docker run -d --name are-kam-$n --network are-kam-net --ip $ip \ --cap-add NET_ADMIN --cap-add NET_RAW \ -v "$PWD/as/pjsip.conf:/etc/asterisk/pjsip.conf" \ -v "$PWD/as/extensions.conf:/etc/asterisk/extensions.conf" \ -v "$PWD/as/rtp.conf:/etc/asterisk/rtp.conf" \ -v "$PWD/as/logger.conf:/etc/asterisk/logger.conf" \ are-pbxsec-tools:1 asterisk -f done ``` ## إعداد Kamailio: وحدة dispatcher الوحدة التي توزع المكالمات في Kamailio اسمها [dispatcher](https://www.kamailio.org/docs/modules/5.7.x/modules/dispatcher.html?ref=arabroot.io)، وهي تقرأ قائمة الخوادم الخلفية من ملف، وتختار لكل مكالمة خادماً بحسب خوارزمية تحددها أنت، وتفحص الخوادم دورياً لتعرف المتاح منها. نكتب أولاً قائمة الخوادم في `dispatcher.list`، كلاهما في مجموعة واحدة رقمها 1: ```text # group 1: the two Asterisk backends 1 sip:10.55.70.21:5060 0 0 weight=50;description=as1 1 sip:10.55.70.22:5060 0 0 weight=50;description=as2 ``` ثم نكتب إعداد Kamailio في `kamailio.cfg`، وأهم ما فيه تحميل الوحدات وضبط dispatcher ليفحص الخوادم كل أربع ثوان برسالة `OPTIONS`، وهو ما نحتاجه لكشف الخادم المتعطل: ```text listen=udp:10.55.70.10:5060 loadmodule "dispatcher.so" loadmodule "pike.so" loadmodule "htable.so" # ... tm, sl, rr, pv, ctl ... modparam("dispatcher", "list_file", "/etc/kamailio/dispatcher.list") modparam("dispatcher", "ds_ping_interval", 4) modparam("dispatcher", "ds_ping_method", "OPTIONS") modparam("dispatcher", "ds_probing_mode", 1) ``` وأما منطق التوجيه فقلبه سطر واحد: لكل مكالمة جديدة نختار خادماً بالخوارزمية رقم 4، وهي التوزيع بالتناوب Round-Robin، ثم نمرر الرسالة إليه، ونسجل في حال فشله مساراً بديلاً نعود إليه: ```text request_route { # ... فحص الفيضان ومعالجة الترويسات ... if (is_method("INVITE|REGISTER|MESSAGE")) { record_route(); if (!ds_select_dst("1", "4")) { send_reply("503", "No backend available"); exit; } t_on_failure("MANAGE_FAILURE"); route(RELAY); exit; } route(RELAY); } ``` بعد تشغيل Kamailio نسأله عن حالة الخوادم بالأمر `kamcmd dispatcher.list`: ```bash docker exec are-kam-proxy kamcmd dispatcher.list ``` والمخرج المهم منه حالة كل خادم: ```text URI: sip:10.55.70.22:5060 FLAGS: AP BODY: weight=50;description=as2 URI: sip:10.55.70.21:5060 FLAGS: AP BODY: weight=50;description=as1 ``` الرمز `FLAGS: AP` يعني أن الخادم فعال Active وأن الوسيط يفحصه دورياً Probing، أي أن الخادمين حيان وجاهزان. وهذا الفحص الدوري هو ما يجعل Kamailio يعرف المتعطل قبل أن ترسل إليه مكالمة. ## توزيع الحمل Load Balancing لنثبت أن التوزيع يعمل فعلاً، نجري ثماني مكالمات متتابعة عبر الوسيط من هاتف برمجي، ثم نعد كم مكالمة رد عليها كل خادم من سجل المكالمات CDR. نفرغ أولاً السجل في الخادمين، ثم نطلق المكالمات: ```bash for n in as1 as2; do docker exec are-kam-$n sh -c ': > /var/log/asterisk/cdr-csv/Master.csv' done { for i in 1 2 3 4 5 6 7 8; do echo "/dial 100$i@10.55.70.10"; sleep 4; echo "/hangup"; sleep 1; done; echo "q"; } | \ docker run -i --rm --name are-kam-caller --network are-kam-net --ip 10.55.70.50 \ -v "$PWD/caller:/conf" -v "$PWD/sounds:/sounds:ro" \ are-pbxsec-tools:1 baresip -f /conf for n in as1 as2; do echo -n "$n: "; docker exec are-kam-$n sh -c 'wc -l < /var/log/asterisk/cdr-csv/Master.csv' done ``` والمخرج سوف يكون كما يلي: ```text as1: 4 as2: 4 ``` وزع Kamailio الثماني مكالمات بالتساوي: أربع لكل خادم، وهذا هو التناوب Round-Robin بالضبط. ونرى القرار نفسه في سجل الوسيط، حيث يطبع لكل مكالمة الخادم الذي أرسلها إليه: ```text dispatcher: INVITE to sip:1003@10.55.70.10 via sip:10.55.70.22:5060 dispatcher: INVITE to sip:1004@10.55.70.10 via sip:10.55.70.21:5060 dispatcher: INVITE to sip:1005@10.55.70.10 via sip:10.55.70.22:5060 dispatcher: INVITE to sip:1006@10.55.70.10 via sip:10.55.70.21:5060 ``` المكالمة تذهب إلى 10.55.70.22 ثم 10.55.70.21 ثم تعود، أي أنها تتناوب بين الخادمين. ولو أردت توزيعاً يراعي حمل كل خادم بدل التناوب الأعمى، فهناك خوارزميات أخرى في [وثائق dispatcher](https://www.kamailio.org/docs/modules/5.7.x/modules/dispatcher.html?ref=arabroot.io)، منها التوزيع بحسب عدد المكالمات القائمة، وهو الأنسب عندما تختلف مدد المكالمات كثيراً. ## الإخفاق Failover: توقف خادم الآن نأتي إلى أهم ميزة، وهي أن يصمد النظام عند تعطل خادم. نوقف الخادم الثاني as2 عمداً، كأنه تعطل أو أعيد تشغيله للتحديث، وننتظر حتى يكشف Kamailio ذلك بفحصه الدوري: ```bash docker stop are-kam-as2 sleep 14 docker exec are-kam-proxy kamcmd dispatcher.list ``` والمخرج سوف يكون كما يلي: ```text URI: sip:10.55.70.22:5060 FLAGS: IP URI: sip:10.55.70.21:5060 FLAGS: AP ``` تغير رمز الخادم as2 من `AP` إلى `IP`، والحرف I يعني Inactive، أي أن الوسيط لم يعد يرسل إليه لأن فحصه بـ `OPTIONS` لم يرجع، بينما بقي as1 فعالاً `AP`. الآن نجري ست مكالمات أخرى ونرى أين تذهب كلها: ```bash { for i in 1 2 3 4 5 6; do echo "/dial 200$i@10.55.70.10"; sleep 4; echo "/hangup"; sleep 1; done; echo "q"; } | \ docker run -i --rm --name are-kam-caller --network are-kam-net --ip 10.55.70.50 \ -v "$PWD/caller:/conf" -v "$PWD/sounds:/sounds:ro" are-pbxsec-tools:1 baresip -f /conf docker exec are-kam-as1 sh -c 'wc -l < /var/log/asterisk/cdr-csv/Master.csv' ``` والمخرج سوف يكون كما يلي، وكل المكالمات ذهبت إلى as1 وحده: ```text 6 ``` الست مكالمات كلها ردها as1، ولم تفشل واحدة منها رغم أن نصف الطاقة توقف، وهذا هو الإخفاق Failover: المتصل لا يشعر بشيء، والخدمة مستمرة. وعندما نعيد تشغيل as2، يكشفه الفحص الدوري خلال ثوان ويعيده إلى الخدمة: ```bash docker start are-kam-as2; sleep 12 docker exec are-kam-proxy kamcmd dispatcher.list ``` ```text URI: sip:10.55.70.22:5060 FLAGS: AP URI: sip:10.55.70.21:5060 FLAGS: AP ``` عاد as2 إلى `AP`، فيستأنف الوسيط توزيع المكالمات عليه. وهذا يعني عملياً أنك تستطيع أن تحدث خوادمك واحداً واحداً دون أن تقطع الخدمة: توقف خادماً، تحدثه، تعيده، ثم تنتقل إلى التالي، والوسيط يوزع على الباقي طوال الوقت. ## صد فيضان الطلبات مع وحدة pike الوسيط في مقدمة الشبكة، فهو أول من يستقبل أي فيضان من الطلبات، سواء كان هجوماً أو خطأ في عميل يرسل آلاف الرسائل في الثانية. ووحدة [pike](https://www.kamailio.org/docs/modules/5.7.x/modules/pike.html?ref=arabroot.io) تحسب عدد الطلبات من كل عنوان في وحدة زمنية، فإذا تجاوز عنوان حداً معيناً عدته مصدر فيضان. نضبطها لتسمح بثلاثين طلباً كل ثانيتين، ونربطها بجدول [htable](https://www.kamailio.org/docs/modules/5.7.x/modules/htable.html?ref=arabroot.io) صغير نضع فيه العناوين المحظورة: ```text modparam("pike", "sampling_time_unit", 2) modparam("pike", "reqs_density_per_unit", 30) modparam("htable", "htable", "ipban=>size=8;autoexpire=120;") ``` وفي أول منطق التوجيه نفحص كل طلب: إذا كان عنوانه محظوراً أسقطناه، وإلا مررناه على pike، فإذا أعلنته مصدر فيضان أضفناه إلى قائمة الحظر: ```text request_route { if (src_ip!=myself && $sht(ipban=>$si)!=$null) { xlog("L_WARN", "pike: dropping request from blocked $si\n"); exit; } if (!pike_check_req()) { xlog("L_ALERT", "pike: BLOCKING address $si\n"); $sht(ipban=>$si) = 1; exit; } # ... بقية التوجيه ... } ``` لنجربها نرسل مئتي طلب بأسرع ما يمكن من عنوان واحد نحو الوسيط، ثم نقرأ سجله: ```bash docker run --rm --network are-kam-net --ip 10.55.70.64 \ -v "$PWD/flood.py:/flood.py:ro" are-pbxsec-tools:1 python3 -I /flood.py 10.55.70.64 200 docker logs are-kam-proxy 2>&1 | grep -E 'BLOCKING|dropping' | head ``` والمخرج سوف يكون كما يلي: ```text ALERT: