מדוע נדרש GeoDNS כאשר יש כתובת אחת לכל האזורים
כל עוד השירות פועל מאתר אחד, נקודת כניסה אחודה נראית הגיונית: כתובת אחת, תצורה אחת, סט כללים אחד. הבעיה מתגלה כאשר הקהל מפוזר — הרזולבר מחזיר לכולם את אותה הכתובת, וחלק מהלקוחות עוברים דרך טרנזיט מרוחק, מפני שהאתר הקרוב אליהם אינו ידוע. זמן התגובה אצל משתמשים כאלה גבוה באופן ניכר, אף שלצד שלכם הכול עובד כשורה.
הפגיעה ניתנת למדידה: החיבור מוקם זמן רב יותר, התשובות הראשונות מגיעות לאט יותר, ושיעור הניסיונות החוזרים בקרב לקוחות ניידים עולה. במסלולים ארוכים יש יותר אובדנים בצמתי ביניים, וזמינות השירות מתחילה להיות תלויה בקטעי רשת שאינכם מנהלים.
ההשפעה השנייה — שבריריות. כתובת אחת משמעה שנפילה של אתר או ערוץ באזור מסוים מפילה את השירות כולו, עד שפג תוקפה של הרשומה במטמון הרזולברים. המעבר ברגע זה נעשה ידנית, ו-TTL קצר אינו פתרון חינם: הוא מגדיל את מספר השאילתות לשרתים הסמכותיים של הדומיין.
GeoDNS מטפל בכך ברמת פתרון השם. הלקוח מקבל את הכתובת של האתר הקרוב אליו, ולכן ניתוב התעבורה לפי אזורים מתרחש לפני הבקשה הראשונה, ולא אחריה. לכל אזור משויך מאגר כתובות משלו, וכשל של אתר מטופל באמצעות שינוי משקלים והסרתו מהתשובה — בלי להמתין שפג התוקף של המטמון אצל כולם.
בהמשך נפרט כיצד נבנית תכנית כזו: אילו אזורים להקצות, כיצד לקבוע סדרי עדיפויות בין אתרים ומה לעשות עם לקוחות שהרזולבר שלהם אינו מדווח על מיקומם.
מה נותן GeoDNS: זמן תגובה, יציבות ופריקת ערוצים
GeoDNS מחזיר ללקוח את הכתובת של האזור שממנו הגיעה הבקשה, ולא כתובת יחידה של האתר המרכזי. את הבקשה משרת האזור הקרוב: העמוד וקריאות ממשק התכנות עוברים במסלול קצר, ולא חוצים חצי יבשת. בפועל זמן התגובה מתקצר פי כמה, והרווח ניכר בכל בקשה, ולא רק בטעינה הראשונה.
ההשפעה השנייה — יציבות. תשובות ניתנות רק עבור אתרים פעילים: אם אזור מפסיק להשיב לבדיקות, הכתובות שלו מוסרות מהתשובות, והתעבורה עוברת למסלול גיבוי. כך נמנע סוג שלם של כשלים — נפילת אתר מפסיקה להיות כשל של השירות, והלקוח ממשיך לעבוד, ולו גם עם זמן תגובה מעט גבוה יותר.
ההשפעה השלישית — פריקת ערוצים. בלי ניתוב אזורי כל המשתמשים מושכים נתונים מהמרכז, ורשת הליבה עובדת עבור טרנזיט בין ערים במקום עומס מועיל. כאשר האזור הקרוב משרת את לקוחותיו בעצמו, תעבורת הבין-עירונית יורדת פי כמה, ומפנה רוחב פס לשיאים ולשכפול.
מה מודדים לפני ואחרי: שיעור הבקשות שנכנסו למסלול המקומי, התפלגות זמן התגובה לפי אזורים, נפח הטרנזיט בין האתרים וזמן המעבר בעת הוצאה מתוכננת של אזור מהתשובות. את האחרון בודקים בתרגיל — מכבים אתר ובודקים אם הלקוח הבחין בכך.
אפשרויות לניתוב תעבורה לפי אזורים והמגבלות שלהן
בחירת התכנית נתקלת בשתי שאלות: באיזו מידה יש צורך להפריד את התעבורה לפי אזורים, ובמה אנחנו מוכנים לשלם עבור דיוק זה.
שיוך גיאוגרפי ברמת הרשומות מפצל לקוחות בין מאגרים בלי חוליה מתווכת, אך טעות במאגר הכתובות מובילה את הבקשה למקום הלא נכון, וצמתי מטמון מתווכים מחזיקים את התשובה הישנה יותר מזמן החיים של השינוי עצמו. לכן משווים תכניות לא לפי מהירות התגובה, אלא לפי יכולת החיזוי ופי כמה מהר אפשר לבטל תיקון שלא צלח.
| תכנית | מתי מתאימה | מגבלות |
|---|---|---|
| רשומות עם שיוך גיאוגרפי | אזור גדול אחד או שניים, הרכב המאגרים משתנה לעיתים רחוקות | זיהוי כתובת לא מדויק; צמתי מטמון של ספקים מחזיקים תשובה ישנה; כל אזור חדש — תיקון ידני |
| מאזן עומסים עם מאגרים אזוריים | כמה אזורים, נדרשות בדיקות זמינות והוצאה מהירה של צומת מפעילות | החוליה המרכזית הופכת לנקודת כשל; השהיה לפנייה הראשונה; ניפוי באגים מורכב יותר מצד הלקוח |
| היברידי: שיוך בתוספת צמתי מטמון מקומיים | שיעור גבוה של בקשות חוזרות, דרישות מחמירות לזמן תגובה בכל אזור | יקר יותר לתחזוקה; נדרשת עקביות כללים בין השכבות; סיכון לנתונים מיושנים במטמונים |
המגבלות של התכנית חשובות מיתרונותיה: כמעט תמיד הבחירה מצטמצמת לשאלה איזה סוג כשל זול יותר עבורכם — אזור שגוי, השבתה של החוליה המרכזית או אי-סנכרון כללים בין השכבות. בהמשך נפרט כיצד אנו בודקים תרחישים אלה לפני מעבר של תעבורה חיה.
כיצד אנו מיישמים ניתוב גיאוגרפי: שלבי העבודה
ניתוב גיאוגרפי מתחיל לא בעריכת אזור, אלא בהבנה מאין באמת מגיעים המשתמשים וכיצד הרזולברים בכל אזור מגיבים לכך. להלן הרצף שלפיו אנו מובילים את היישום: מביקורת תשתית ועד מסירת תכנית עבודה לצוות שלכם.
- ביקורת תשתית ומיפוי אזורים. אוספים את האזורים, הרשומות, ההאצלה, רשימת הספקים ונקודות הנוכחות הנוכחיות. מבהירים אילו אזורים יש להפריד ולפי איזה סימן — מדינה, מפעיל, יבשת.
- מדידות על רזולברים אמיתיים. מנקודות שונות בודקים אילו שרתי שמות מחזירים תשובה ועד כמה יציב מזוהה מקור הבקשה. זה מראה היכן השיוך הגיאוגרפי עובד באופן אמין והיכן נדרש סימן נוסף.
- תכנון תכנית הניתוב. מקבעים מטריצה «אזור → סט כתובות», סדרי עדיפויות, ערכי TTL והתנהגות כאשר צומת אינו זמין. את התכנית מתאמים לפני עריכות באזור העבודה, כדי שהשינויים יהיו צפויים.
- הגדרה ובדיקות זמינות של צמתים. פורסים שיוכים ובקרות זמינות: כאשר צומת כושל, התעבורה עוברת למסלול גיבוי, ולא נשארת על כתובת שאינה מגיבה. מגדירים זמן התכנסות יעד ועוקבים אחריו.
- בדיקת מעבר. מבצעים כשלים מבוקרים: מכבים צומת, מחליפים את סימן האזור, בודקים תשובות בפועל והתנהגות מטמונים אצל ספקים שונים.
- מסירה לתפעול. מוסרים תצורות, תכנית, נוהל שינויים וסדר חזרה לאחור. הצוות שלכם רואה מה ומדוע משתנה בעת הוספת אזור, ומכאן והלאה עורך את התכנית בעצמו.
כל שלב מסתיים בתוצר: מפת אזורים, מטריצה מאושרת או דוח מעברים. כך רואים על מה מבוסס הפתרון הנוכחי ומה לשנות ביציאה לאזור חדש.
מה נשאר אצלכם: תצורות, תכניות ונהלים
הפיתוח אינו מסתיים במעבר תעבורה — הלקוח מקבל סט תוצרים שלפיהם המערכת חיה ומשתנה בלעדינו. להלן רשימת מה שמועבר לצוות הלקוח: קבצים, תכניות וסדר העבודה איתם. הכול נשמר במאגר שלכם, ולא בתיקייה אישית של מישהו.
- תצורות של אזורים וכללים: שיוך אזורים למאגרי כתובות, זמן חיים של רשומות במטמון הרזולברים, סטים נפרדים למסלול הראשי ולמסלול הגיבוי. כל שינוי עובר סקירה לפני יישום.
- מפת אזורים ומסלולים: איזה אזור מוביל לאיזה מסלול, היכן נמצא אתר הגיבוי, כיצד התעבורה מתחלקת בעת אי-זמינות חלקית. התכנית משקפת את המצב בפועל, ולא את הכוונה הראשונית.
- כללי מעבר: תנאים להוצאת צומת משירות, ספי פגיעה, השהיה לפני החלפת תשובה, התנהגות בעת כשל באחד מערוצי התקשורת. מנוסחים כך שניתן לבדוק אותם בסביבת בדיקות, ולא רק לקרוא אותם.
- תרשים ניתוב הבקשה: המסלול מפניית המשתמש ועד לשרת היעד, הנקודות שבהן מתקבלת ההחלטה על האזור, והמקומות שבהם התשובה נשמרת במטמון.
- נוהל שינויים: מי מאשר עריכת מפת האזורים, באיזה סדר היא נפרסת, כיצד מתבצעת חזרה לגרסה הקודמת ובתוך כמה זמן. בנוסף, הפרדת הרשאות בין מסלול הבדיקות למסלול הייצור.
- תיעוד: תיאור האזורים והבעלים שלהם, אנשי קשר של תורנויות, תרחישים אופייניים — להוסיף אזור, להוציא אתר לתחזוקה, לנתח אי-התאמה בתשובות.
- נראות: סט מדדים לפי רזולברים וחלק התשובות שעברו למסלול הגיבוי, עם התראות מוגדרות.
סט כזה מאפשר לשנות את הניתוב בכוחות עצמכם, בלי להתחיל את הפרויקט מחדש, ולהבין מה בדיוק קרה כאשר התעבורה התנהגה שלא לפי התכנית.
מקרה בוחן: מנקודת כניסה משותפת למסלולים אזוריים
בתחילה כל האזורים הצביעו לרשומה משותפת אחת: צומת יחיד קיבל גם תעבורה מקומית וגם תעבורת טרנזיט. כאשר אתר נעשה לא זמין, התורן תיקן ידנית את האזור והמתין שפג זמן החיים של הרשומה אצל הרזולברים — זה ארך מחצי שעה עד ארבעים דקות, וכל אותו זמן המשתמשים ראו שגיאה.
את הניתוח התחלנו במדידות: מדדנו זמן תגובה לפי אזורים, חישבנו את שיעור הבקשות שעברו דרך צומת מרוחק, וקבענו את זמן המעבר הידני כמדד בסיס. ההשערה אושרה — חלק ניכר מההשהיה נבע לא מהקוד, אלא מהמסלול לנקודת הכניסה היחידה.
בהמשך הפרדנו מסלולים אזוריים: את האזורים הסמכותיים העברנו ל-Cloudflare, לכל אזור הגדרנו סט כתובות משלו, הפעלנו בדיקות זמינות והסטת תעבורה אוטומטית בעת נפילת אתר. את זמן החיים של הרשומה עבור שמות שירות הקטנו, כדי שהמעבר יתבצע בדקות ולא בעשרות דקות.
מדדים לאחר מכן: מעבר — כדקה וללא מעורבות תורן, זמן התגובה באזורים מרוחקים נמוך ב-38%, שיעור תעבורת הטרנזיט דרך מסלול זר ירד מ-46% ל-7%. מסוג שלם של כשלים יצא מכלל פעולה — אי-זמינות של צומת אחד אינה מעידה עוד על אי-זמינות השירות בכל האזורים.
בנפרד קבענו נוהל: כיצד מחובר אזור חדש, לפי אילו ספים בדיקות מכריזות על אתר כלא פעיל, כיצד מתבצעת חזרה לאחור של תצורת האזור. זהו המעבר מנקודת כניסה אחת לסט מסלולים אזוריים בלתי תלויים.
מה לעשות אם הניתוב כבר מוגדר אצל הספק
מצב שבו חלק מכללי הגיאו כבר נמצאים אצל ספק חיצוני נפוץ יותר ממעבר «נקי»: אצל הספק נשארים דומיינים ברמה העליונה, חלק מתת-הדומיינים וענפים אזוריים נפרדים.
מתחילים במיפוי הכללים: מייצאים את כל הרשומות, משווים אותן לתעבורה אמיתית מהלוגים, וקובעים אילו אזורים באמת משרתים לוגיקת גיאו ואילו נותרו «לזכר» ניסויים קודמים. בלי שלב זה כל מעבר הופך להעברה של תצורה זרה יחד עם השגיאות שלה.
בהמשך מגדירים גבולות ומבצעים האצלה חלקית: אזורים שבהם הניתוב קריטי למוצר נלקחים לשליטתנו, ותת-דומיינים פריפריאליים נשארים בשלווה אצל הספק — לו מואצלת הענף כולו, ואנחנו לא מתערבים בו.
כך תחום האחריות נעשה ברור: אצלנו — כללי חלוקה לפי אזורים, בדיקות זמינות ויומני תשובות; אצל הספק — מה שאנחנו במודע לא נוגעים בו.
מעבר ללא השבתה מבוסס על הכנה, ולא על מהירות. מראש מקטינים את זמן החיים של הרשומות במטמון, כדי שרזולברים בכל העולם יפסיקו להחזיק תשובות ישנות; מרימים תצורה חדשה במקביל ומשווים אותה לזו הנוכחית לפי מדגם בקשות מרשתות שונות. רק לאחר התאמת התשובות משתנות רשומות ההאצלה, והתכנית הקודמת נשארת מוכנה לחזרה במשך כמה שעות.
בנפרד מקבעים מה נשאר אצל הספק לאחר המעבר: מסלול חירום למקרה כשל בתשתית שלנו או הגנת היקף. זו אינה פשרה, אלא עתודה מודעת — בעת תקלה ניתן להחזיר את התעבורה לתכנית הקודמת. בהמשך נפרט כיצד תכנית היברידית כזו מתוחזקת בלי עריכות ידניות.
ספקות טכניים לפני ההתחלה
צוותי הנדסה לפני ההתחלה שואלים בערך את אותו סט שאלות: כמה מהר התכנית תתחיל להעביר תעבורה, האם אנחנו פוגעים בלקוחות פעילים, במה בודקים נכונות ומי מתחזק אותה בהמשך. להלן תשובות ישירות לחמש השאלות הנפוצות ביותר, בלי מילים כלליות.
כמה מהר מתחיל לעבוד המעבר בין אזורים?
את המהירות קובע לא לוח הבקרה, אלא זמן החיים של הרשומה במטמון הרזולברים. אנחנו מקטינים אותו מראש באזורים הנדרשים, ולכן החלפת המסלול נקלטת בתוך חלון זה, ולאחר התייצבות הערך מוחזר לקדמותו.
מה יראו לקוחות פעילים ברגע החלפת המסלול?
סשנים שכבר נפתחו אינם מתנתקים — הם חיים בצד השירותים, ולא בניתוב. בקשות חדשות עוברות לאזור היעד, ולכן המשתמש במקרה הגרוע יקבל תשובה מהאתר הקודם עוד מחזור אחד.
האם אפשר לבדוק את התכנית לפני יציאה לתעבורת ייצור?
כן, מרימים מסלול בדיקות: אזור נפרד, אותו סט כללים וסקר מכמה נקודות. מריצים תרחישים של כשל אזור, אי-זמינות בדיקת תקינות ותיקון נתוני גיאו — ורק אחר כך מעבירים את התצורה.
כיצד לוודא שהמסלולים ניתנים נכון?
מגדירים סקר תקופתי של רזולברים מאזורים שונים עם השוואת התשובות למידע ייחוס. אי-התאמה מגיעה כהתראה לערוץ התורנות, ולכן רואים את השגיאה לפני תלונות המשתמשים.
מי מתחזק את התכנית לאחר ההשקה?
מוסרים תצורה עם תיאור כללים, רשימת בדיקה לשינויים אופייניים והרשאות לפי תפקידים. בהמשך ניתן לתחזק את התכנית בכוחות עצמכם או להשאיר את התמיכה אצלנו — נוהל העדכונים והתורנות נקבעים כבר בהתחלה.
נדון במשימה שלכם: מה לשלוח להערכה
דיוק הערכת העבודה על GeoDNS נקבע לפי הנתונים הראשוניים: היקף העבודה עבור אזור אחד עם שני אזורים ועבור עשר נקודות נוכחות עם הוצאה אוטומטית של צמתים מהתשובות שונה פי כמה.
כדי לחזור עם תכנית יישום ולוחות זמנים, ולא עם טווח «מכאן ועד כאן», די לנו שתתארו את המשימה ותשלחו את הנתונים הבאים.
- רשימת דומיינים ותת-דומיינים שנדרש עבורם ניתוב אזורי, עם ציון היכן מואצלים כעת האזורים ומי מנהל את הרשומות.
- מפת אזורים: אילו מדינות או קבוצות מדינות מטופלות, האם יש דרישות לנוכחות מקומית ואחסון נתונים בשטח.
- תשתית מאחורי האזורים: נקודות נוכחות, מאגרי כתובות, איזה שירות מקבל את התעבורה וכיצד היא מתחלקת כעת.
- קריטריון לבחירת אזור: השהיית תגובה, זמינות צמתים או עלות יציאה — מה נחשב לעדיפות בעת התנגשות.
- דרישות לעמידות בכשלים: זמן מעבר מותר בעת כשל בצומת, האם נדרשת הוצאה אוטומטית של אזור מהתשובות.
- מגבלות: מדיניות ארגונית, מאיץ אספקת תוכן חיצוני, רשומות קיימות שאסור לשבור בעת ההעברה.
לפי נתונים ראשוניים אלה אנו מתארים את היקף העבודה: ביקורת האזור הנוכחי, תכנית חלוקה לאזורים ולמאגרים, כללי מעבר, סדר פריסה עם בדיקה בדומיין בדיקות. בתכנית היישום מקבעים שלבים, נקודות בדיקה ודרך חזרה לתכנית הניתוב הקודמת — העריכות באזור מבוצעות בהדרגה, בלי לפגוע בשירות. תארו את המשימה ושלחו את הנתונים הראשוניים — נחזור עם הערכת עבודה ותכנית.