كيفية عمل موازنة الحمل في الخدمة العالمية يعمل GSLB

منشور من طرف Zevenet | 16 يناير 2018

GSLB نظرة عامة

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

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

يتطلب اعتماد وتنفيذ خدمات تكنولوجيا المعلومات في السحابة أن الطريقة القائمة على شبكة WAN هي أفضل خيار لتوفير حلول عالية التوافر في موقع Geo. هذا ما نسميه موازنة خدمة عالمية or 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 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.

حركة مرور DNS مع ميزات GSLB

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

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

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

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

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

قم بالاتصال بلوحة Zevenet على الويب في مركز البيانات 1 (فرانكفورت لحالتنا) ، انقر في القائمة الرئيسية GSLB وحدة نمطية وإنشاء جديد مزرعة، في مثالنا سيتم استدعاء DNS1 فرانكفورت في المنفذ الظاهري 53.

إنشاء مزرعة GSLB في مركز بيانات واحد

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

قم بإنشاء منطقة GSLB في أول مركز بيانات

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

GSLB منطقة التحرير في أول مركز بيانات

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

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

إنشاء مزرعة GSLB في مركز بيانات DR الثاني

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

تكوين منطقة GSLB في مركز البيانات الثاني

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

GSLB منطقة التحرير في تورونتو

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

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

إنشاء خدمة GSLB مع أولوية

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

GSLB تحرير أولوية الخدمة

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

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

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

GSLB تستخدم أولوية الخدمة

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

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

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

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

يعرض طلب DNS التالي تهيئة Nameservers لـ zvnlb.net وقرار DNS للمضيف www.zvnlb.net.

user@client:# host -t ns zvnlb.net
zvnlb.net name server ns2.zvnlb.net.
zvnlb.net name server ns1.zvnlb.net.

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

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

user@client:# nslookup www.zvnlb.net
Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
Name:	www.zvnlb.net
Address: 188.166.230.211

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

user@client:# nslookup www.zvnlb.net
Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
Name:	www.zvnlb.net
Address: 139.59.186.84

بمجرد فشل خادم التطبيق ، فإن قرار DNS سيغير المضيف إلى مركز البيانات 2. بمجرد المضيف في مركز البيانات 1 هو ما يصل سيتم تطبيق الفشل الخلفي تلقائيا.

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

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

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

إنشاء خدمة GSLB بمراكز بيانات مشتركة ونشطة

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

إنشاء مورد نظام أسماء النطاقات لخدمة GSLB مع جولة روبن

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

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

user@client:# nslookup www.zvnlb.net
Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
Name:	www.zvnlb.net
Address: 188.166.230.211
Name:	www.zvnlb.net
Address: 139.59.186.84

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

وبمجرد إخفاق المضيف ، سيتغير قرار نظام أسماء النطاقات تلقائيًا. انظر أدناه ما يحدث.

root@client:# nslookup www.zvnlb.net
Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
Name:	www.zvnlb.net
Address: 139.59.186.84

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

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

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

في حالة المنطقة العامة (على سبيل المثال zvnlb.net) التي تقدم خدمة GSLB كمحلل خادم الأسماء الذي يحتاج إلى التعرف عليه من قبل خوادم DNS العامة لهذا المجال ، ثم يلزم تسجيل عنوان IP العام الذي تستخدمه خدمة GSLB في مسجل المجال الخاص بك (مثل NameCheap أو Goddady أو غيرهما) . يوضح الارتباط التالي كيفية تسجيل GSLB IPs كخوادم أسماء في إجراء مسجل المجال.

تسجيل مضيف باسم NameServer

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

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

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

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

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

إنشاء منطقة فرعية bind9 DNS

الآن اتبع القسم تفويض منطقة في خدمة Zevenet 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 (على سبيل المثال zevenet.io تدار بواسطة Bind9) مثل الاسم المقبول or CNAME كما هو موضح أدناه:

إنشاء CNAME إلى منطقة GSLB

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

لاحظ أن هذا المثال يتم في خادم DNS Bind9 لكن أسماء Canon أو CNAMES هي تكوينات مضيف DNS مدعومة بأي تطبيق لخدمة ملقم DNS.

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

مشاركة مع :

وثائق بموجب شروط رخصة جنو للوثائق الحرة.

هل كان المقال مساعدا؟!

مقالات ذات صلة