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

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

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

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

متى تستخدم GSLB #

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

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

بالتأكيد، عندما يكون من المطلوب مشاركة المستخدمين وحركة المرور بين الخوادم حول العالم دون نقاط فشل، فإن 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 or 8.8.4.4 في هذه الحالة، يكتشف ذلك ns1.zvnlb.net و ns2.zvnlb.net هم المسؤولون عن حلول المنطقة zvnlb.net لذلك يقومون بإرسال استعلام DNS الذي تلقاه العميل (على سبيل المثال، ما هو عنوان IP الخاص بـ www.zvnlb.net؟ ) إلى واحد منهم.

أحد خوادم الأسماء إما ns1.zvnlb.net or ns2.zvnlb.net يتلقى استعلام DNS من 8.8.8.8 or 8.8.4.4 وبعد ذلك، يقوم خادم الأسماء الذي يستقبل الطلب بالتحقق من الخوادم المتاحة للمضيف www.zvnlb.net وسوف يستجيب لاستعلام DNS بقائمة خوادم التطبيقات المتاحة لخدمة التطبيق الحقيقي للمضيف 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 or 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 الجديدة وانتقل إلى علامة التبويب مناطق، قم بإنشاء منطقة DNS هنا التي سيتم إدارتها بواسطة خدمة GSLB هذه zvnlb.net كما يلي:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

المستخدم@العميل:# 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 الخاصة بك والتي تسمى موازنة التحميل الدائرية روبن كما هو موضح في المثال للخدمة الجديدة المسماة الويب:

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

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

لاختباره، حاول حل المضيف 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 كمحلل لخادم الأسماء، ويحتاج إلى أن تتعرف عليه خوادم DNS العامة لهذا النطاق، فيلزم تسجيل عنوان IP العام الذي تستخدمه خدمة GSLB لدى مسجل نطاقك (مثل NameCheap أو Goddady أو غيرها). يشرح الرابط التالي كيفية تسجيل عناوين 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 مثل خوادم أسماء DNS لهذا الغرض.

لقد قمنا بإنشاء المنطقة الفرعية لنطاقنا cluster.zvnlb.net في خوادم DNS 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) مثل الاسم المقبول or CNAME كما هو موضح أدناه:

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

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

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