المحتويات
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.
تكوين 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.
بمجرد إنشاء المزرعة ، يرجى تعديلها والانتقال إلى علامة التبويب مناطق وإنشاء منطقة DNS التي ستديرها وحدة GSLB ، في هذه الحالة zvnlb.net، على النحو التالي:
بمجرد إنشاء هذه المنطقة ، يرجى إجراء التكوين الأول كما هو موضح أدناه:
نلاحظ أن ns1 و ns2 هي "خوادم الأسماء" المسؤولة عن دقة DNS للمنطقة zvnlb.net (في حالتنا ، خدمة GSLB واحدة في فرانكفورت وآخر في تورنتو).
ثم ، قم بالاتصال بلوحة الويب Zevenet في مركز البيانات 2 ، في القائمة الرئيسية حدد GSLB وإنشاء جديد مزرعة، في قضيتنا سيتم استدعاؤها DNS2 تورونتو في المنفذ الظاهري 53.
قم بتحرير مزرعة GSLB الجديدة وانتقل إلى علامة التبويب مناطق، أنشئ هنا منطقة DNS التي ستتم إدارتها بواسطة خدمة GSLB هذه لـ zvnlb.net كما يلي:
بمجرد إنشاء هذه المنطقة الجديدة ، يرجى إجراء التهيئة الأولى على النحو التالي:
مثل حالة GSLB في مركز البيانات 1خوادم الاسم n1 و n2 سوف يشير إلى خدمات GSLB في كليهما مركز البيانات 1 و مركز البيانات 2، على التوالي.
ثم انقر في علامة التبويب خدماتنا وإنشاء خدمة جديدة ، على سبيل المثال webpriority:
إختار ال خوارزمية خيار الأولوية: الاتصالات دائمًا إلى معظم prio المتاحة وتكوين الخدمة على النحو التالي:
أعد تشغيل المزرعة لتطبيق التغييرات. يلزم تطبيق نفس تكوين خدمة GSLB في كلا مركزي البيانات.
لاحظ أنه إذا مزرعة الجارديان لم يتم تكوينها لتطبيق أي فحص صحي ، تستخدم خدمة GSLB افتراضيًا check_tcp إلى منفذ TCP المحدد في حقل الفحص الصحي في تكوين الخدمة.
لتمكين الخدمة الجديدة ، انتقل إلى المنطقة التي تم إنشاؤها (zvnlb.net في حالتنا) وإنشاء جديد مورد. ثم قم بإنشائه باختيار الجديد الخدمة كما هو موضح أدناه.
أخيرًا ، احفظ التغييرات. يلزم تطبيق هذا التكوين في كلا مركزي البيانات.
في هذه المرحلة ، المضيف 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 الخاصة بك المسماة جولة روبن تحميل موازنة كما هو موضح في المثال الخاص بالخدمة الجديدة المسماة شبكة:
الآن ، إضافته في المنطقة zvnlb.net وتغيير تكوين الموارد شبكة الاتصالات العالمية كما يلي:
احفظ التغييرات وأعد تشغيل المزرعة عند الطلب.
لاختبار ذلك ، حاول حل المضيف 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 كخوادم أسماء في إجراء مسجل المجال.
بعد إجراء معين عليك التسجيل ns1.zvnlb.net و ns2.zvnlb.net مع عناوين IP المقدمة.
إنشاء منطقة فرعية مخصصة لـ GSLB
فقط في حالة عدم إمكانية تفويض قرار DNS لخدمة GSLB الخاصة بـ Zevenet ، يمكن إجراء التكوين الموضح أدناه. يوضح المثال التالي كيفية إنشاء ملف المنطقة الفرعية For 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 على النحو التالي:
الآن اتبع القسم تفويض منطقة في خدمة 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 كما هو موضح أدناه:
بمجرد تطبيق التغيير ، 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.