نظرة عامة على GSLB #

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

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

يتطلب تبني وتطبيق خدمات تكنولوجيا المعلومات في الحوسبة السحابية أن يكون استخدام طريقة تعتمد على شبكة واسعة النطاق (WAN) هو الخيار الأمثل لتوفير حلول عالية التوافر موزعة جغرافيًا. وهذا ما يُعرف بموازنة أحمال الخدمات العالمية ( GSLB).

متى تستخدم GSLB #

يوصى باستخدام خدمة GSLB في حالات الاستخدام التالية:

الشركات التي تستضيف خدماتها في أكثر من مركز بيانات من خلال شبكة WAN.
الشركات التي تتطلب إنشاء توفر عالٍ للخدمات أو مراكز البيانات.
مزودي خدمة الإنترنت لإنشاء خدمات موازنة التحميل الواردة لاستخدامها من قبل المستخدمين.

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

كيف يعمل GSLB #

GSLB هي آلية لموازنة الأحمال تعتمد على بروتوكول DNS ، وهي سريعة وموثوقة لأنها تستخدم بروتوكول UDP واستجابة العميل تكون في الوقت الفعلي تقريبًا.

في طلب DNS شائع، على سبيل المثال www.zvnlb.net ، يقوم العميل بإرسال طلب DNS إلى خوادم DNS المحلية المُكوّنة (على سبيل المثال 8.8.8.8 و 8.8.4.4 )، ثم يختار نظام العميل عشوائيًا أحد الخوادم لإجراء الاستعلام وإرساله.

يستقبل خادم DNS المحدد الطلب من العميل (على سبيل المثال، ما هو عنوان IP الخاص بـ www.zvnlb.net ؟) وتحاول خوادم DNS المحلية المُكوّنة العثور على المسؤول عن حل منطقة DNS zvnlb.net.

يكتشف نظام أسماء النطاقات (DNS) المستخدم من قبل العميل، 8.8.8.8 أو 8.8.4.4 في هذه الحالة، أن ns1.zvnlb.net و ns2.zvnlb.net مسؤولان عن تحليل النطاقات لـ zvnlb.net، لذلك يرسلان استعلام DNS الذي يتلقاه العميل (على سبيل المثال، ما هو عنوان IP الخاص بـ www.zvnlb.net ؟) إلى أحدهما.

يستقبل أحد خوادم الأسماء، إما ns1.zvnlb.net أو ns2.zvnlb.net، استعلام نظام أسماء النطاقات (DNS) من 8.8.8.8 أو 8.8.4.4 ، ثم يقوم خادم الأسماء الذي يستقبل الطلب بالتحقق من الخوادم المتاحة للمضيف www.zvnlb.net ، وسيرد على استعلام نظام أسماء النطاقات بقائمة خوادم التطبيقات المتاحة لخدمة التطبيق الفعلي للمضيف www.zvnlb.net ، وبالتالي ستتلقى هذه المعلومات في النهاية من قبل العميل.

الآن سيختار العميل عشوائياً أحد خوادم التطبيقات من القائمة التي تم استلامها في استعلام DNS وسيرسل الطلب مباشرة إلى التطبيق http://www.zvnlb.net.

يقوم خادما أسماء النطاقات ns1.zvnlb.net (الموجود في فرانكفورت في مثالنا) و ns2.zvnlb.net (الموجود في تورنتو في مثالنا) بفحص حالة تطبيق المضيف www.zvnlb.net ( 192.235.113.3 و 194.23.52.21 في حالتنا) بشكل دوري. إذا اكتشف أيٌّ من الخادمين ns1.zvnlb.net أو ns2.zvnlb.net أي مشكلة أثناء فحص حالة أحد الخوادم، فسيتم تعطيل الخادم غير المتاح مؤقتًا، ولن يظهر عنوان IP الخاص به في استعلامات نظام أسماء النطاقات (DNS) حتى يصبح متاحًا مرة أخرى.

يُظهر الرسم التخطيطي التالي حركة مرور DNS الموصوفة بإمكانيات GSLB.

تكوين GSLB لاستعادة البيانات بعد الكوارث من مراكز البيانات #

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

يرجى اتباع هذا المثال الحقيقي لتكوين GSLB لبناء مركز بيانات نشط-سلبي للتعافي من الكوارث.

لقد قمنا بنشر اثنين RELIANOID موازنات التحميل عبر مركزين للبيانات في مواقع مختلفة، فرانكفورت 159.89.7.124 وتورنتو 159.203.12.35 ولدينا خدمة ويب تستجيب لمضيف DNS www.zvnlb.net، تم تكوينه في مركز البيانات 1 و مركز البيانات 2سيسمح تصميم هذه البنية التحتية بإرسال جميع حركة مرور العملاء إلى مركز البيانات 1 ولكن إذا فشل فإنه يقوم بإعادة توجيه العملاء إلى مركز البيانات 2.

وللوصول إلى هذا التكوين اتبع الإجراء الموضح أدناه.

تواصل مع RELIANOID لوحة الويب في مركز البيانات 1 (فرانكفورت في حالتنا)، انقر في القائمة الرئيسية جي إس إل بي وحدة وإنشاء وحدة جديدة مزرعة، في مثالنا سيتم استدعاؤه DNS1-فرانكفورت في المنفذ الافتراضي 53.

بمجرد إنشاء المزرعة، يرجى تعديلها، والانتقال إلى علامة التبويب " المناطق" وإنشاء منطقة DNS التي ستتم إدارتها بواسطة وحدة GSLB، في هذه الحالة zvnlb.net ، كما يلي:

بمجرد إنشاء هذه المنطقة، يرجى إجراء التكوين الأول كما هو موضح أدناه:

لاحظ أن ns1 و ns2 هما خادما الأسماء المسؤولان عن عمليات تحليل DNS لمنطقة zvnlb.net (في حالتنا، خدمة GSLB واحدة في فرانكفورت وأخرى في تورنتو).

ثم قم بالاتصال بـ RELIANOID لوحة الويب في مركز البيانات 2، في القائمة الرئيسية حدد جي إس إل بي وإنشاء جديد مزرعة، في حالتنا سيتم استدعاؤها DNS2-تورنتو في المنفذ الافتراضي 53.

قم بتحرير مزرعة GSLB الجديدة وانتقل إلى علامة التبويب Zones ، ثم أنشئ هنا منطقة DNS التي ستتم إدارتها بواسطة خدمة GSLB هذه لـ zvnlb.net على النحو التالي:

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

كما هو الحال بالنسبة لـ GSLB في مركز البيانات 1 ، فإن خوادم الأسماء n1 و n2 ستشير إلى خدمات GSLB في كل من مركز البيانات 1 ومركز البيانات 2 ، على التوالي.

ثم انقر في علامة التبويب "الخدمات" وقم بإنشاء خدمة جديدة، على سبيل المثال webpriority :

حدد خيار الخوارزمية " الأولوية: الاتصالات دائماً مع الأولوية الأعلى المتاحة" وقم بتكوين الخدمة على النحو التالي:

أعد تشغيل المزرعة لتطبيق التغييرات. يلزم تطبيق نفس تكوين خدمة GSLB في كلا مركزي البيانات.

لاحظ أنه إذا لم يتم تكوين Farm Guardian لتطبيق أي فحص صحي، فإن خدمة GSLB تستخدم فحصًا افتراضيًا لـ check_tcp لمنفذ TCP المحدد في حقل الفحص الصحي في تكوين الخدمة.

لتفعيل الخدمة الجديدة، انتقل إلى المنطقة التي تم إنشاؤها ( zvnlb.net في حالتنا) وأنشئ موردًا جديدًا . ثم أنشئه عن طريق تحديد الخدمة الجديدة كما هو موضح أدناه.

أخيرًا، احفظ التغييرات. يلزم تطبيق هذا التكوين في كلا مركزي البيانات.

في هذه المرحلة، تتم إدارة المضيف www.zvnlb.net بواسطة وحدة GSLB في وضع الأولوية ، لذلك سيتم إرسال جميع حركة المرور إلى مركز البيانات 1 ، ثم إذا فشل، فسيتم إعادة توجيه حركة المرور إلى مركز البيانات 2 المتاح الآخر.

تم ضبط مدة الصلاحية (TTL) على 5، وهو نوع من تاريخ انتهاء الصلاحية المُضاف إلى سجل DNS. يُحدد هذا التاريخ للخادم المتكرر أو المُحلِّل المحلي المدة التي يجب أن يحتفظ بها بالسجل في ذاكرة التخزين المؤقت. لذا، كلما كانت القيمة المُهيأة أقل، كلما تم اكتشاف التغييرات بشكل أسرع.

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

يوضح طلب نظام أسماء النطاقات التالي تكوين خوادم الأسماء لـ zvnlb.net وحل نظام أسماء النطاقات للمضيف www.zvnlb.net.

المستخدم@العميل:# المضيف -t ns zvnlb.net خادم اسم zvnlb.net ns2.zvnlb.net. خادم اسم zvnlb.net ns1.zvnlb.net.

يستخدم كلا خادمي الأسماء عناوين IP الافتراضية المكوّنة في مزارع GSLB.

الآن، استخدم خوادم نظام أسماء النطاقات (DNS) الحالية لديك لحل اسم مضيف (على سبيل المثال www ) في هذه المنطقة:

المستخدم@العميل:# nslookup www.zvnlb.net الخادم: 8.8.8.8 العنوان: 8.8.8.8#53 إجابة غير معتمدة: الاسم: www.zvnlb.net العنوان: 188.166.230.211

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

المستخدم@العميل:# nslookup www.zvnlb.net الخادم: 8.8.8.8 العنوان: 8.8.8.8#53 إجابة غير معتمدة: الاسم: www.zvnlb.net العنوان: 139.59.186.84

بمجرد تعطل خادم التطبيق، سيقوم نظام أسماء النطاقات (DNS) بتغيير المضيف إلى مركز البيانات 2. وبمجرد عودة المضيف في مركز البيانات 1 إلى العمل، سيتم تطبيق عملية العودة التلقائية.

تكوين GSLB لمراكز البيانات النشطة #

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

في مثل هذه الحالات، يرجى استخدام طريقة المشاركة لخدمة GSLB الخاصة بك والتي تسمى Round Robin Load Balancing كما هو موضح في المثال الخاص بالخدمة الجديدة المسماة web :

الآن، أضفه إلى نطاق zvnlb.net وقم بتغيير إعدادات الموارد www كما يلي:

احفظ التغييرات وأعد تشغيل المزرعة إذا طلب ذلك.

لاختبار ذلك، حاول الوصول إلى المضيف www.zvnlb.net وسيبدو الناتج كما هو موضح:

المستخدم@العميل:# nslookup www.zvnlb.net الخادم: 8.8.8.8 العنوان: 8.8.8.8#53 إجابة غير معتمدة: الاسم: www.zvnlb.net العنوان: 188.166.230.211 الاسم: www.zvnlb.net العنوان: 139.59.186.84

لاحظ أن مُحلل DNS يقوم بإرجاع كلا خادمي التطبيق بدلاً من خادم واحد كما هو الحال في حالة استرداد الكوارث.

عند تعطل المضيف، سيتغير حل DNS تلقائيًا. انظر أدناه لمعرفة ما يحدث.

root@client:# nslookup www.zvnlb.net الخادم: 8.8.8.8 العنوان: 8.8.8.8#53 إجابة غير موثوقة: الاسم: www.zvnlb.net العنوان: 139.59.186.84

تم إلغاء تنشيط خادم التطبيق غير المتاح من قائمة استجابة DNS.

بمجرد أن يصبح المضيف 188.166.230.211 متاحًا مرة أخرى، سيتم تضمينه مرة أخرى في عملية تحليل DNS.

تفويض منطقة في RELIANOID خدمة GSLB #

في حالة وجود نطاق عام (مثل zvnlb.net ) يُقدّم خدمة موازنة تحميل الخدمة العالمية (GSLB) كمُحلِّل أسماء يحتاج إلى أن تتعرف عليه خوادم نظام أسماء النطاقات العامة لهذا النطاق، فإنه يلزم تسجيل عنوان IP العام الذي تستخدمه خدمة GSLB لدى مسجّل نطاقك (مثل NameCheap أو Goddaddy أو غيرهما). يشرح الرابط التالي كيفية تسجيل عناوين IP الخاصة بخدمة GSLB كخوادم أسماء في إجراءات مسجّل النطاق.

تسجيل المضيف كخادم أسماء

باتباع الإجراء الموضح، يجب عليك تسجيل ns1.zvnlb.net و ns2.zvnlb.net باستخدام عناوين IP المحددة.

إنشاء منطقة فرعية مخصصة لـ GSLB #

فقط في حالة عدم إمكانية تفويض حل DNS إلى خدمة GSLB RELIANOIDيمكن تنفيذ التكوين الموضح أدناه. يوضح المثال التالي كيفية إنشاء المنطقة الفرعية لـ zvnlb.net يشير هذا إلى خوادم الأسماء الخاصة بهذه المنطقة الفرعية الجديدة في خدمة GSLB.

العقدة 1 (على سبيل المثال ns1.zvnlb.net بعنوان IP 162.243.5.109 ) والعقدة 2 (على سبيل المثال ns2.zvnlb.net بعنوان IP 178.62.233.104 ) عبارة عن خوادم أسماء مُهيأة لتقديم خدمات تحليل أسماء النطاقات (DNS) لمنطقة zvnlb.net . تقع هذه المنطقة ضمن خدمة DNS عامة من Bind9، ونرغب في توفير إمكانيات موازنة تحميل الخدمة العالمية (GSLB) لبعض مضيفي بنيتنا التحتية، لذلك قررنا إنشاء منطقة DNS الفرعية cluster.zvnlb.net وتكوين مجموعتين من خوادم أسماء GSLB لهذا الغرض.

لقد أنشأنا المنطقة الفرعية لنطاقنا cluster.zvnlb.net في خوادم نظام أسماء النطاقات Bind9 الخاصة بنا على النحو التالي:

الآن اتبع القسم تفويض منطقة في RELIANOID خدمة GSLB من أجل الحفاظ عليها 159.89.7.124 و 159.203.12.35 في مثالنا كخوادم أسماء معترف بها للمنطقة cluster.zvnlb.net من خلال خوادم DNS العامة.

بعد ذلك، يمكنك تطبيق التكوين كما هو موضح للنطاق zvnlb.net في القسم أعلاه " تكوين GSLB لاستعادة مراكز البيانات في حالات الكوارث".

توجيه المضيف في DNS الخاص بنا إلى خدمة GSLB #

في الأقسام السابقة قمنا بإنشاء مضيف باسم www.zvnlb.net مع موازنة التحميل في وضع الأولوية ووضع التوزيع الدوري، لذلك يمكننا إعادة استخدام هذا التكوين من أجل توفير إمكانيات GSLB لخادم أسماء DNS آخر لا يدعم هذه الميزة بشكل افتراضي.

لتحقيق هذا التكوين، ما علينا سوى إنشاء مورد جديد في منطقة DNS لا يدعم خيارات GSLB (على سبيل المثال ، تتم إدارة relianoid.io بواسطة Bind9) مثل الاسم المتعارف عليه أو CNAME كما هو موضح أدناه:

بمجرد تطبيق التغيير، سيشير www.relianoid.io إلى www.zvnlb.net ، ولكن إذا تغير حل المضيف www.zvnlb.net ، فسيتغير www.relianoid.io تلقائيًا أيضًا.

لاحظ أن هذا المثال تم إجراؤه في خادم DNS Bind9 ولكن الأسماء الأساسية أو CNAMES هي تكوينات مضيف DNS التي يدعمها أي تنفيذ لخدمة خادم DNS.

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