סקירה כללית של GSLB #

כיום, זמינות גבוהה של שירותי IT היא חובה ולכן זו חברות וארגונים לפתח מערכות מחשוב מופץ ברחבי העולם, שירותי אירוח ביותר ממרכז נתונים אחד, שכן הוא מציע את היתרונות הבאים:

עמידות בפני תקלה: כאשר השירות מתארח במרכז הנתונים נכשל השירות ממשיך בכל אחד מהאתרים הזמינים האחרים.
שחזור אוטומטי של מרכז הנתונים: כאשר מרכז נתונים אחד נכשל השירות מנותב באופן אוטומטי לכל מרכז נתונים זמין אחר.
איזון עומסים: התנועה יכולה להיות ממוטבת על ידי הפצת העומס בין כל האתרים הזמינים לשפר את חביון ולהפוך את אספקת השירות מהר יותר.
זמן אחזור משופר: התנועה יישום הלקוח הוא ישירות עם השרת האמיתי, אין צורך להעביר את כל נתוני היישום באמצעות איזון עומס.

אימוץ ויישום של שירותי IT בענן דורש ששיטה המבוססת על 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 ויגיב לשאילתת ה-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 או 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 (פרנקפורט במקרה שלנו), לחץ על התפריט הראשי GSLB מודול וליצור חדש משק, בדוגמה שלנו ייקרא DNS1 - פרנקפורט ביציאה הווירטואלית 53.

לאחר יצירת החווה, אנא ערוך אותה, עבור ללשונית אזורים וצור את אזור ה-DNS שינוהל על ידי מודול GSLB, במקרה זה zvnlb.net , באופן הבא:

לאחר שנוצר אזור זה אנא בצע את התצורה הראשונה כפי שהיא מוצגת למטה:

שימו לב ש- ns1 ו- ns2 הם שרתי השמות האחראים על רזולוציות ה-DNS עבור האזור zvnlb.net (במקרה שלנו, שירות GSLB אחד בפרנקפורט ואחר בטורונטו).

לאחר מכן, התחברו ל- RELIANOID פאנל אינטרנט במרכז הנתונים 2, בתפריט הראשי בחר GSLB וליצור חדש משק, במקרה שלנו ייקרא DNS2-Toronto ביציאה הווירטואלית 53.

ערוך את חוות GSLB החדשה ועבור לכרטיסייה אזורים , צור כאן את אזור ה-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 במצב Priority , כך שכל התעבורה תישלח למרכז נתונים 1 ולאחר מכן, אם היא נכשלת, התעבורה תנותב למרכז נתונים 2 הזמין האחר.

ה- TTL הוגדר ל -5, זהו סוג תאריך התפוגה שמונח ברשומת DNS. ה- TTL משמש להגיד לשרת הרקורסיבי או לפותר המקומי כמה זמן עליו לשמור את הרשומה האמורה במטמון שלה. אז ערך נמוך יותר מוגדר מהר יותר השינויים מתגלים.

יישום שיטה זו נוכל להוסיף כמו מרכזי נתונים רבים לפי הצורך על ידי הכללת שרתים חדשים עם שירות GSLB.

בקשת ה-DNS הבאה מציגה את תצורת שרתי השמות עבור zvnlb.net ואת רזולוציית ה-DNS עבור המארח www.zvnlb.net.

משתמש@לקוח:# host -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 יהיה פעיל, פעולת ה-failback תחול אוטומטית.

קביעת תצורה של 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 מחזיר את שני שרתי היישומים במקום אחד כמו במקרה Disaster Recovery.

לאחר המארח יש כישלון, ההחלטה 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 ולהגדיר 2 חוות 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 לאיזון עומסים במצבי עדיפות ו-Round Robin, כך שנוכל לעשות שימוש חוזר בתצורה זו על מנת להציע יכולות 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 מאזן עומסים.