כיצד גלובל שירות איזון עומס GSLB עובד

פורסם על ידי זאבנט | 16 בינואר, 2018

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

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

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

אימוץ והטמעת שירותי ה- IT בענן דורש ששיטה המבוססת על WAN היא האפשרות הטובה ביותר לספק פתרונות זמינות גבוהה הממוקמים גיאוגרפית. לזה אנחנו קוראים איזון עומס שירות גלובלי 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 Balancers על פני שני מרכזי נתונים באתרים שונים, פרנקפורט 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-Toronto ביציאה הווירטואלית 53.

ליצור חוות GSLB במרכז הנתונים השני DR

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

להגדיר את אזור GSLB במרכז הנתונים השני

לאחר יצירת אזור חדש זה, בצע את התצורה הראשונה כדלקמן:

עריכת אזור בטורונטו

כמו במקרה של GSLB ב מרכז הנתונים 1, את שרתי שם n1 ו n2 יצביע על שירותי GSLB בשניהם מרכז הנתונים 1 ו מרכז הנתונים 2, בהתאמה.

לאחר מכן לחץ על הכרטיסייה שירותים וליצור שירות חדש, לדוגמה webpriority:

ליצור שירות GSLB עם עדיפות

בחר אַלגוֹרִיתְם אוֹפְּצִיָה עדיפות: חיבורים תמיד לפריו הכי זמין וכן להגדיר את השירות כדלקמן:

GSLB עריכת עדיפות שירות

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

שים לב שאם שומר החווה לא מוגדר להחיל כל בדיקה רפואית, שירות GSLB משתמש ברירת המחדל check_tcp ליציאת ה- TCP המוגדרת בשדה בדיקת הבריאות בתצורת השירות.

כדי להפעיל את השירות החדש, עבור אל האזור שנוצר (zvnlb.net במקרה שלנו) וליצור חדש משאב. לאחר מכן ליצור אותו על ידי בחירת חדש שֵׁרוּת כפי שמוצג להלן.

GSLB להשתמש עדיפות שירות

לבסוף, שמור את השינויים. נדרש להחיל תצורה זו בשני מרכזי הנתונים.

בשלב זה, המארח www.zvnlb.net מנוהל על ידי מודול GSLB ב עדיפות מצב, אז כל התנועה יישלח אל מרכז הנתונים 1 ולאחר מכן, אם הוא נכשל, התנועה תנותב מחדש לזמין מרכז הנתונים 2.

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

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

בקשת DNS הבאה מציגה את תצורת השמות עבור 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 הנוכחיים שלך כדי לפתור את המארח (לדוגמה www) באזור זה:

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 ולשנות את תצורת המשאבים www באופן הבא:

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

לאחר המארח יש כישלון, ההחלטה 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.

האצלת אזור בשירות זבנט GSLB

במקרה של אזור ציבורי (לדוגמה zvnlb.net) המספק שירות GSLB כמפתן שרת שמות שצריך להכיר על ידי שרתי DNS ציבוריים עבור תחום כזה, אז נדרש לרשום את כתובת ה- IP הציבורית המשמשת את שירות GSLB ברשם התחום שלך (כמו NameCheap, Goddady או אחרים) . הקישור הבא מסביר כיצד לרשום כתובות IP של GSLB כשרתי שמות בהליך רשם הדומיינים.

רישום מארח כמסמך

לאחר הליך נתון אתה צריך להירשם ns1.zvnlb.net ו ns2.zvnlb.net עם כתובות IP הנתונות.

יצירת תת אזור ייעודי עבור GSLB

רק למקרה שלא ניתן להאציל את רזולוציית ה- DNS לשירות ה- GSLB של Zevenet, ניתן לבצע את התצורה שתוסבר להלן. הדוגמה הבאה מראה כיצד לבנות a תת אזור ל 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 שלנו באופן הבא:

צור אזור משנה של DNS bind9

עכשיו בצע את הקטע האצלת אזור בשירות זבנט 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) כמו a שם קנוני or CNAME כפי שמוצג להלן:

יצירת CNAME לאזור GSLB

לאחר השינוי מוחל, www.zevenet.io יהיה מצביע www.zvnlb.net, אבל אם את ההחלטה המארחת www.zvnlb.net שינויים ואז אוטומטית www.zevenet.io ישתנה גם כן.

שים לב שדוגמה זו נעשית בשרת DNS Bind9 אבל שמות קנוניים או CNAMES הם תצורות DNS מארח הנתמכות על ידי יישום שירות שרת DNS.

הסבר פשוט זה מראה כי ניתן להשתמש בשירות GSLB גם אם שירות ה- DNS הנוכחי שלנו אינו מציע יכולות GSLB, רק מעביר רק את הרזולוציה של המארח הנתון באזור שאינו GSLB לשירות GSLB ב- Zevenet Load Balancer.

תשתף:

תיעוד על פי תנאי הרישיון לשימוש חופשי במסמכים של גנו.

האם המאמר הזה היה מועיל?

מאמרים נוספים