بضع كلمات حول ما نفعله. تشارك DINS في تطوير ودعم خدمة UCaaS في السوق الدولية للعملاء من الشركات. يتم استخدام الخدمة من قبل الشركات الصغيرة والشركات الناشئة والشركات الكبرى. يتصل العملاء عبر الإنترنت عبر بروتوكول SIP عبر TCP أو TLS أو WSS. وهذا يخلق حمولة كبيرة إلى حد ما: حوالي 1.5 مليون اتصال من الأجهزة الطرفية - هواتف Polycom / Cisco / Yealink وعملاء البرامج للكمبيوتر / Mac / IOS / Android.
في هذه المقالة ، أتحدث عن كيفية ترتيب نقاط دخول VoIP.
الخلفية
على محيط النظام (بين الأجهزة الطرفية والنواة) توجد SBC تجارية (وحدة تحكم حدود الجلسة).
منذ عام 2012 ، نستخدم حلولًا من Acme Packet ، حصلت عليها Oracle لاحقًا. قبل ذلك ، استخدمنا NatPASS.
اذكر باختصار الوظيفة التي نستخدمها:
• اجتياز NAT.
B2BUA ؛
• تطبيع SIP (الرؤوس المسموح بها / غير المسموح بها ، قواعد معالجة الرأس ، إلخ)
• تفريغ TLS و SRTP ؛
• تحويل النقل (داخل النظام نستخدم SIP عبر UDP) ؛
• رصد MOS (عبر RTCP-XR) ؛
• ACLs ، اكتشاف Bruteforce ؛
• انخفاض حركة التسجيل بسبب زيادة انتهاء صلاحية الاتصال (انخفاض انتهاء الصلاحية على جانب الوصول ، وارتفاع الجانب الأساسي) ؛
• رسائل SIP لكل طريقة اختناق.
تحتوي الأنظمة التجارية على إيجابياتها الواضحة (الوظائف خارج الصندوق ، الدعم التجاري) والقصور (السعر ، وقت التسليم ، قلة الفرص أو المواعيد النهائية طويلة جدًا لتنفيذ الميزات الجديدة التي نحتاجها ، المواعيد النهائية لحل المشكلات ، إلخ). تدريجيا ، بدأ تفوق العيوب ، وأصبح من الواضح أن هناك حاجة ماسة لتطوير حلولنا الخاصة.
تم إطلاق التطوير منذ عام ونصف. في النظام الفرعي للحدود ، ميزنا تقليديًا مكونين رئيسيين: خوادم SIP و Media ؛ موازن التحميل فوق كل مكون. أنا أعمل على نقاط الدخول / الموازنات هنا ، لذلك سأحاول التحدث عنها.
المتطلبات
- التسامح مع الخطأ: يجب أن يوفر النظام خدمة في حالة فشل مثيل واحد أو أكثر في مركز البيانات أو مركز البيانات بأكمله
- إمكانية الخدمة: نريد أن نتمكن من تبديل الأحمال من مركز بيانات إلى آخر
- قابلية التوسع: أريد زيادة السعة بسرعة وغير مكلفة
موازنة
اخترنا IPVS (الملقب LVS) في وضع IPIP (نفق المرور). لن أخوض في تحليل مقارن لـ NAT / DR / TUN / L3DSR ، (يمكنك أن تقرأ عن الأوضاع ، على سبيل المثال ، هنا ) ، سأذكر فقط الأسباب:
- لا نريد فرض شرط على الخلفية ليكون على نفس الشبكة الفرعية مثل LVS (تحتوي التجمعات على نقاط خلفية من كل من مراكز البيانات الخاصة بنا والبعيدة) ؛
- يجب أن تتلقى الواجهة الخلفية IP المصدر الأصلي للعميل (أو NAT الخاص به) ، بمعنى آخر ، مصدر NAT غير مناسب ؛
- يجب أن تدعم الخلفية العمل المتزامن مع العديد من الشخصيات المهمة.
نحن نوازن حركة مرور الوسائط (اتضح أنها صعبة للغاية ، وسنرفضها) ، وبالتالي فإن مخطط النشر الحالي في مركز البيانات هو كما يلي:
استراتيجية موازنة IPVS الحالية هي "sed" (أقصر تأخير متوقع) ، وأكثر من ذلك. على عكس وحدة التحكم الموزونة في جولة روبن / الأقل مرجحًا ، فإنه يسمح لك بعدم نقل حركة المرور إلى الوصلات الخلفية ذات الأوزان المنخفضة حتى الوصول إلى حد معين. يتم حساب أقصر تأخير متوقع باستخدام الصيغة (Ci + 1) / Ui ، حيث Ci هو عدد الاتصالات على الواجهة الخلفية i ، Ui هي وزن الواجهة الخلفية. على سبيل المثال ، إذا كانت هناك خواص خلفية في البركة بأوزان تبلغ 50.000 و 2 ، فسيتم توزيع الاتصالات الجديدة بواسطة الأول منها حتى يصل كل خادم إلى 25000 اتصال أو حتى يتم الوصول إلى الحد الأقصى - وهو حد على إجمالي عدد الاتصالات.
قراءة المزيد عن استراتيجيات التوازن في الرجل ipvsadm .
يبدو تجمع IPVS بهذا الشكل (هنا وأدناه ، يتم سرد عناوين IP الوهمية):
# ipvsadm -ln Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 1.1.1.1:5060 sed -> 10.11.100.181:5060 Tunnel 50000 5903 4 -> 10.11.100.192:5060 Tunnel 50000 5905 1 -> 10.12.100.137:5060 Tunnel 2 0 0 -> 10.12.100.144:5060 Tunnel 2 0 0
يتم توزيع التحميل على VIP على الخوادم التي يبلغ وزنها 50000 (يتم نشرها في نفس مركز البيانات كمثيل LVS محدد) ، إذا كانت محملة فوق طاقتها أو تدخل في قائمة سوداء ، سينتقل الحمل إلى جزء النسخة الاحتياطية من التجمع - الخوادم التي يبلغ وزنها 2 مركز البيانات المجاورة.
بالضبط نفس التجمع ، ولكن مع المقاييس ، على العكس من ذلك ، تم تكوينه في مركز البيانات المجاور (في نظام الإنتاج ، وعدد الخلفية ، بطبيعة الحال ، أكبر بكثير).
يتيح تزامن الاتصالات عبر ipvs sync للنسخ الاحتياطي LVS معرفة جميع الاتصالات الحالية.
من أجل التزامن بين مراكز البيانات ، تم تطبيق تقنية "قذرة" ، ومع ذلك تعمل بشكل جيد. تعمل مزامنة IPVS فقط من خلال البث المتعدد ، والذي كان من الصعب علينا توصيله بشكل صحيح إلى العاصمة المجاورة. بدلاً من الإرسال المتعدد ، نقوم بتكرار ازدحام المرور عبر iptables الهدف TEE من ipvs الرئيسي إلى نفق ip-ip إلى الخادم في العاصمة المجاورة ، وقد يكون هناك عدة مضيفين مستهدفين / مراكز بيانات:
#### start ipvs sync master role: ipvsadm --start-daemon master --syncid 10 --sync-maxlen 1460 --mcast-interface sync01 --mcast-group 224.0.0.81 --mcast-port 8848 --mcast-ttl 1 #### duplicate all sync packets to remote LVS servers using iptables TEE target: iptables -t mangle -A POSTROUTING -d 224.0.0.81/32 -o sync01 -j TEE --gateway 172.20.21.10 # ip-ip remote lvs server 1 iptables -t mangle -A POSTROUTING -d 224.0.0.81/32 -o sync01 -j TEE --gateway 172.20.21.14 # ip-ip remote lvs server 2 #### start ipvs sync backup role: ipvsadm --start-daemon backup --syncid 10 --sync-maxlen 1460 --mcast-interface sync01 --mcast-group 224.0.0.81 --mcast-port 8848 --mcast-ttl 1 #### be ready to receive sync sync packets from remote LVS servers: iptables -t mangle -A PREROUTING -d 224.0.0.81/32 -i loc02_srv01 -j TEE --gateway 127.0.0.1 iptables -t mangle -A PREROUTING -d 224.0.0.81/32 -i loc02_srv02 -j TEE --gateway 127.0.0.1
في الواقع ، كل خادم من خوادم LVS يلعب كلا الدورين في آن واحد (رئيسي ونسخ احتياطي) ، من ناحية ، إنه مناسب تمامًا ، لأنه يزيل تغيير الدور عند تبديل حركة المرور ، من ناحية أخرى ، لأن كل وحدة تحكم المجال تعالج حركة مرور المجموعة بشكل افتراضي كبار الشخصيات العامة.
تحميل التبديل بين مراكز البيانات
في التشغيل العادي ، يتم الإعلان عن كل عنوان IP عام على الإنترنت من أي مكان (في هذا المخطط ، من مركزين للبيانات). يتم توجيه حركة المرور التي تدخل VIP إلى العاصمة التي نحتاجها في الوقت الحالي باستخدام سمة BGP MED (تمييز الخروج المتعدد) بقيم مختلفة لـ DC النشطة و DC للنسخ الاحتياطي. في نفس الوقت ، يكون Backup DC مستعدًا دائمًا لقبول حركة المرور إذا حدث شيء ما للنشاط النشط:
من خلال تغيير قيم BGP MEDs واستخدام مزامنة IPVS عبر المواقع ، سنحصل على فرصة لنقل حركة المرور بسلاسة من الواجهة الخلفية لمركز بيانات إلى آخر ، دون التأثير على المكالمات الهاتفية الثابتة ، والتي سوف تنتهي عاجلاً أم آجلاً بشكل طبيعي. تتم العملية تلقائيًا بالكامل (لكل شخص لديه زر في وحدة التحكم بالإدارة) ، ويبدو كما يلي:
SIP-VIP نشط في DC1 (يسار) ، الكتلة في DC2 (يمين) لا لزوم لها ، وذلك بفضل تزامن IPvs ، لديه معلومات حول الاتصالات القائمة في ذاكرته. على اليسار ، يتم الإعلان عن الشخصيات المهمة النشطة بقيمة 100 MED ، على اليمين - بقيمة 500:
زر التبديل يؤدي إلى تغيير في ما يسمى "Target_state" (مفهوم داخلي يعلن عن قيم BGP MEDs في وقت معين). هنا لا نأمل أن يكون DC1 في حالة جيدة وجاهزة لمعالجة حركة المرور ، وبالتالي فإن LVS في DC2 تأتي في حالة "القوة النشطة" ، وتخفيض قيمة MEDs إلى 50 ، وبالتالي تجذب حركة المرور إلى نفسها. إذا كانت الخلفية في DC1 حية ومتاحة ، فلن تنقطع المكالمات. سيتم إرسال جميع اتصالات TCP الجديدة (التسجيلات) إلى الواجهة الخلفية في DC2:
تلقى DC1 نسخة متماثلة target_state جديدة وتعيين قيمة النسخ الاحتياطي MEDs (500). عندما يكتشف DC2 حول هذا الموضوع ، فإنه يضبط قيمته (50 => 100). يبقى الانتظار لاستكمال جميع المكالمات النشطة في DC1 وقطع الاتصالات tcp المنشأة. مثيلات SBC في DC1 تقدم الخدمات الضرورية لما يسمى حالة "إيقاف التشغيل الرشيق": يستجيب "503" لطلبات SIP التالية وانقطع الاتصال ، ولكن لا تقبل الاتصالات الجديدة. أيضا ، هذه الحالات تندرج في القائمة السوداء على LVS. عند الانقطاع ، يقوم العميل بإنشاء تسجيل / اتصال جديد ، والذي يأتي بالفعل في DC2:
تنتهي العملية عند كل حركة المرور في DC2.
DC1 و DC2 تبديل الأدوار.
في ظروف الحمل العالي المستمر على نقاط الدخول ، اتضح أنه مناسب جدًا لتكون قادرًا على تبديل حركة المرور في أي وقت. تبدأ نفس الآلية تلقائيًا في حالة بدء تشغيل النسخة الاحتياطية DC فجأة في تلقي حركة المرور. في الوقت نفسه ، للحماية من الخفقان ، يتم تشغيل التبديل مرة واحدة فقط في اتجاه واحد ويتم ضبط القفل على التبديل التلقائي ، لإزالته ، مطلوب تدخل بشري.
ما في الداخل
مجموعة VRRP ومدير IPVS: Keepalived. Keepalived هي المسؤولة عن تبديل الشخصيات المهمة داخل المجموعة ، وكذلك عن التحقق من الصحة / القائمة السوداء.
BGP المكدس: ExaBGP. إنه مسؤول عن الإعلانات عن الطرق المؤدية إلى عناوين VIP ولصق BGP MEDs المقابلة. تسيطر بالكامل من قبل خادم الإدارة. يتطور نشاط برنامج BGP الموثوق به المكتوب بلغة بيثون ؛ وهو يؤدي مهمته بنسبة 100٪.
خادم الإدارة (API / مراقبة / إدارة المكونات الفرعية): Pyro4 + Flask. إنه خادم الدعم لـ Keepalived و ExaBGP ، ويدير جميع إعدادات النظام الأخرى (sysctl / iptables / ipset / etc) ، ويوفر المراقبة (gnlpy) ، ويضيف ويزيل الواجهة الخلفية عند الطلب (يتواصلون مع API الخاصة به).
الأرقام
يقدم الجهاز الظاهري المزود بأربعة مراكز أساسية Intel Xeon Gold 6140 CPU @ 2.30GHz تدفق حركة يصل إلى 300Mbps / 210Kpps (تتم معالجة حركة مرور الوسائط ، حوالي 3 آلاف مكالمة متزامنة في وقت الذروة). استخدام وحدة المعالجة المركزية في نفس الوقت - 60 ٪.
هذا يكفي الآن لخدمة حركة مرور ما يصل إلى 100 ألف من الأجهزة الطرفية (هواتف سطح المكتب). لخدمة كل حركة المرور (أكثر من مليون جهاز طرفي) ، نقوم ببناء حوالي 10 أزواج من هذه المجموعات في العديد من مراكز البيانات.