אשכול מבוזר גיאוגרפית: היכן נשברת העמידות בפני כשלים
אשכול מבוזר גיאוגרפית נבנה למען עמידות בפני כשלים: האתרים מופרדים, ונפילה של אחד מהם לא אמורה לעצור את השירות. בפועל, דווקא על ההפרדה נשבר מה שעבד במרכז אחד במשך שנים. נבחן שלושה כשלים טיפוסיים שעולים לאחר המעבר לאשכול מבוזר גיאוגרפית.
הראשון — חוסר סנכרון בנתונים. כל עוד הכתיבה מתבצעת לאתר אחד, השכפול מדביק אותה באיחור, ובקריאה מהאתר השני הלקוח רואה סל קניות מיושן, יתרת מלאי ישנה או סטטוס הזמנה שכבר השתנה. השגיאה אינה משוחזרת בסביבת בדיקה עם צומת אחד, והיא מתגלה רק תחת עומס, כאשר תור השכפול גדל.
הפתרון אינו "חיזוק השרת", אלא בחירת מודל עקביות עבור ישויות מסוימות: במקום מסוים קריאה ישירות מהצומת המוביל, ובמקום אחר איחור של חלקי שנייה מותר.
השני — ניתוק סשנים. סשן שנרשם באתר אחד אינו נראה באתר השני, ומאזן העומס שמעביר את התעבורה בעת כשל זורק את כל המשתמשים המאומתים לטופס ההתחברות. עבור חנות מקוונת מדובר בסלים אבודים, ועבור פורטל בבקשות שנקטעות.
כאן חשובים אחסון סשנים משותף, דומיינים ונתיבי cookie תקינים, וכן הסדר שבו מאזן העומס מעביר את התעבורה ביחס למוכנות הצומת.
השלישי — הידרדרות בעת כשל של צומת. האשכול פורמלית חי, אך האתר השני אינו מחזיק את העומס במלואו: אין מספיק כוח, המטמונים אינם מחוממים, והמשימות והסוכנים ברקע אינם מורמים. הכשל עובר "בהצלחה", והשירות מגיב לאט פי כמה או באופן חלקי. לכן עמידות בפני כשלים נבדקת לא לפי עצם המעבר, אלא לפי כמה זמן השירות נשאר בתקינות לאחריו.
שלושת הכשלים מאוחדים על ידי דבר אחד: הם מתגלים במפגש בין האתרים, ולא בתוך כל אחד מהם. נבחן כיצד זה נסגר ברמת הארכיטקטורה והנהלים.
מה נותן קלאסטר geo-distributed במפתח
קלאסטר geo-distributed במפתח — זה לא "אתר על שני שרתים", אלא סכימת פריסה מתוכננת מראש של האפליקציה והנתונים בכמה אתרים עם החלפת תעבורה אוטומטית.
אנו קובעים את זמן השחזור היעד לפני תחילת העבודה ומתאימים את הטופולוגיה אליו: צומת פעיל במיקום אחד עם גיבוי חם באחר, שכפול של מסד הנתונים וקבצים משותפים, נקודת כניסה אחודה עם איזון ובדיקת בריאות של כל צומת.
האפקט המדיד הראשון — קיצור זמן השחזור. כשל של אתר מפסיק להיות אירוע עם טיפול ידני: המאזן מסיר את הצומת מהרוטציה לפי health-check, התעבורה עוברת לגיבוי, מסד הנתונים עולה מהרפליקה. השחזור נמדד בדקות במקום בשעות של השבתה, ולא "איך שיצא".
השני — מחלקת כשלים שנמנעה. שרת בודד נופל כולו: דיסק, חשמל, רשת, התחממות — כל אלה נקודת כשל אחת. בקלאסטר geo-distributed התקלות האלה ממוקמות באתר אחד ואינן עוצרות את השירות.
בנפרד אנו מכסים את מחלקת הכשלים הקשורים לעדכונים: הגרסה נפרסת לצומת אחד, נבדקת, ורק אחר כך עוברת לשאר, לכן שגיאה בקוד אינה מפילה את כל הפרויקט.
השלישי — יציבות בעומס שיא. הסכימה המבוזרת מאפשרת להוסיף צמתים עבור קפיצות עונתיות ולפזר את הגשת הסטטיקה והמטמון בין האתרים, לכן גידול בתעבורה אינו הופך לגידול בזמן התגובה. אנו מדמים מראש את השיא ובודקים שהקלאסטר עומד בו.
מפרקים כיצד זה מכוסה: מביקורת התשתית הנוכחית ובחירת הטופולוגיה ועד הגדרת שכפול, החלפה עמידה בכשלים ותקנון תפעול.
תוכניות פריסה: אקטיב-אקטיב, אקטיב-פסיב, היברידי
בחירת התוכנית נקבעת לא על ידי "אופנתיות" של עמידות בכשלים, אלא על ידי האופן שבו האפליקציה עובדת עם נתונים. קלאסטר 1С-Битрикс מחזיק מצב בשני מישורים: אחסון קבצים (העלאות, מטמון, סשנים) ומסד נתונים.
כל עוד הכתיבה מתבצעת לצומת אחד, כל תוכנית עם שני אתרים פעילים נתקלת בשאלה כיצד אתם מסנכרנים כתיבה ביניהם. מכאן שלושה מצבי עבודה שבהם באמת בוחרים.
אקטיב-אקטיב
שני האתרים מקבלים תעבורה, המאזן מפזר בקשות לפי גיאוגרפיה או משקלים. עובד בצורה צפויה כאשר הכתיבה מרוכזת לנקודה אחת: סשנים מועברים לאחסון משותף, המטמון אינו קשור לדיסק המקומי של הצומת, ושינויים בתוכן עוברים דרך אתר מאסטר אחד.
המגבלה — שכפול מסד הנתונים בין האתרים הוא אסינכרוני, ולכן בקריאה מרפליקה ייתכן עיכוב. עבור קטלוג ותוכן סטטי זה בלתי מורגש, עבור סל קניות ואזור אישי — זה כבר סיכון.
אקטיב-פסיב
התעבורה עוברת לאתר הראשי, השני מחזיק רפליקה ברזרבה חמה ומופעל בעת כשל. פשוט יותר בתחזוקה: נקודת כתיבה אחת, אין קונפליקטים של שכפול, התנהגות צפויה בעת עדכון תוכן. המחיר — השבתה בזמן המעבר והעובדה שהרזרבה אינה מנוצלת. עבור פרויקטים עם עבודת עריכה אינטנסיבית ואינטגרציות עם מערכת חשבונאית זהו המצב הכנה ביותר.
תוכנית היברידית
האתר הראשי מקבל כתיבה, השני משרת קריאה ומגיש תוכן סטטי קרוב יותר למשתמש. פשרה בין עלות לתגובה: חלק מהעומס יורד מהמאסטר, אך לוגיקת הכתיבה נשארת במקום אחד. דורש הגדרה מדויקת של ניתוב — אילו בקשות ניתן להפנות לרפליקה, ואילו רק למאסטר.
| וריאנט | מתי מתאים | מגבלות |
|---|---|---|
| אקטיב-אקטיב | תעבורה גבוהה בקריאה, קהל מפוזר גיאוגרפית | שכפול אסינכרוני, קונפליקטים בכתיבה, תחזוקה מורכבת יותר |
| אקטיב-פסיב | אינטגרציות עם מערכת חשבונאית, עריכה אקטיבית, עדיפות — צפויות | השבתה בעת מעבר, הרזרבה אינה נושאת עומס |
| היברידי | נדרשת תגובה מהירה ללא שכפול מלא של הכתיבה | דורש הפרדה של בקשות לקריאה ולכתיבה, הגדרה מדויקת של ניתוב |
מצב העבודה נבחר לפי פרופיל העומס, ולא להפך. בהמשך נבחן מה בדיוק יש לסנכרן בכל אחד מהווריאנטים.
שלבי היישום: מביקורת ועד מסירה
העבודה על אשכול מבוזר גיאוגרפית מתנהלת בשלבים עם תוצאות מוגדרות בכל אחד מהם: הלקוח רואה מה בדיוק נעשה וכיצד זה נבדק, ולא "העבודה מתבצעת". בין השלבים — נקודות בקרה שבהן ניתן להתאים את סדרי העדיפויות בלי לעצב מחדש את מה שכבר נבנה.
- ביקורת תשתית. משרטטים מפה של המתאר הנוכחי: היכן נמצאים שרתי האינטרנט, מסד הנתונים, אחסון הקבצים, המטמון, וכיצד התעבורה מתחלקת בין האתרים. מתעדים צווארי בקבוק — דיסק משותף, נקודת כשל יחידה, השהיות בין אזורים.
- תכנון סכמת האשכול. מגדירים את הטופולוגיה: אילו אתרים פעילים, היכן נמצא מאסטר מסד הנתונים, כיצד מתפשטת הרפליקציה, ומה שורד כשל מלא. הסכמה מאושרת לפני תחילת העבודה — לאחר מכן בונים ובודקים לפיה.
- הכנת סביבות. פורסים שרתים באתרים, מגדירים את הרשת ביניהם, ומביאים את התצורות לצורה אחידה. בנפרד בודקים שסביבות ניתנות לשחזור: האשכול נבנה מתיאור, ולא "בידיים מהזיכרון".
- הגדרת רפליקציה וסנכרון. מקשרים את מסד הנתונים, הקבצים והמטמון כך שהנתונים מתכנסים בין האתרים באופן צפוי. מגדירים את הפיגור של הרפליקות, את ההתנהגות בעת ניתוק ערוץ התקשורת ואת סדר השחזור לאחר הניתוק.
- בדיקת עמידות בכשלים. מפילים צמתים ואתרים שלמים לפי תרחיש, ומודדים תוך כמה זמן התעבורה עוברת לחלק החי וחוזרת בחזרה. בנפרד בודקים שהמעבר אינו מאבד נתונים ואינו שובר את הפעלות המשתמשים.
- הרצות עומס. מריצים פרופיל קרוב לזה האמיתי: בקשות שיא, שליפות כבדות, עבודה בו-זמנית ממספר אזורים. בוחנים היכן נוצר צוואר הבקבוק קודם — במסד הנתונים, בדיסק או ברשת.
- מסירה ותיעוד. מוסרים את הסכמה, התצורות, נוהל המעבר והשחזור, והוראות למשמרת התורנות. מקיימים הדרכה לצוות הלקוח, כדי שניתן יהיה לתחזק את האשכול בלעדינו.
כל שלב נסגר בתוצאה שניתנת לבדיקה: סכמה, תצורה, דוח הרצה. תארו את המשימה שלכם — נחזור עם הערכה ותוכנית לפי שלבים.
מה הלקוח מקבל לידיו
האשכול נמסר לא "כפי שהוא", אלא כמערכת מלאה, שלפיה הצוות שלכם יוכל להפעיל אותו ולפתח אותו בלעדינו. כל ארטיפקט מכסה סוג אחר של משימות: קונפיגורציות — שחזוריות, תרשימים — הבנת הטופולוגיה, נהלים — צפיות בפעולות בשגרה ובמצב תקלה.
- קונפיגורציות של כל הצמתים — קבצי שרתי הווב, מאזן העומסים, שרתי האפליקציות ומסדי הנתונים במערכת בקרת גרסאות. פריסת צומת חדש מסתכמת בהחלת קונפיגורציה, ולא בהרכבה ידנית מהזיכרון.
- תרשימי פריסה — טופולוגיה של אשכול geo-distributed עם אזורי זמינות, נתיבי תעבורה, נקודות כשל והיגיון מעבר. בנפרד מצוין אילו צמתים מחזיקים מצב, ואילו ניתן להעלות ולכבות בחופשיות.
- נהלי הפעלה — סדר העבודות המתוכננות, הוספת צומת, עדכון הליבה והמודולים, רוטציה של גיבויים. שלב אחר שלב, עם ציון הבדיקות לאחר כל שלב.
- נהלי שחזור — תרחישים לתקלת אזור, צומת אפליקציה ומסד נתונים. עבור כל אחד: סימני הפעלה, רצף הפעולות, זמן חזרה משוער לפעילות.
- ניטור והתראות — בדיקות מוגדרות של זמינות, השהיות רפליקציה ותורים, עם ספים ונתיבי התראות. התורן רואה את ההידרדרות לפני שהמשתמש מבחין בה.
- תיעוד הרשאות — מפת חשבונות, תפקידים והרשאות לפי רכיבים, עם סדר הענקה ושלילה. עזיבת עובד אינה מותירה דלתות פתוחות.
- יומן הטמעה — מה ובאיזה סדר השתנה, אילו החלטות התקבלו ומדוע. כעבור חצי שנה זה חוסך ימים בבירור "מדוע נעשה דווקא כך".
המערכת מתואמת עם המהנדסים שלכם לפני המסירה: אנחנו עוברים על התרשימים והנהלים יחד עם אלה שיישארו להפעיל את האשכול. תארו את המשימה — נחזור עם הערכה ותוכנית.
מקרה בוחן: קלאסטר לחנות מקוונת בשתי פלטפורמות
הלקוח — חנות מקוונת עם עומס שיא במבצעים, פלטפורמה אחת, שרת אפליקציות אחד ומסד נתונים משותף. בשעת שיא הסל ותהליך השלמת ההזמנה הגיבו באיחור, ונפילת צומת משמעה עצירה מוחלטת של המכירות: השחזור ארך שעות, משום שהכל הועלה ידנית וללא גיבוי "חם".
1С-Битрикс בתצורה כזו — נקודת כשל יחידה: גם שכבת האינטרנט, גם מסד הנתונים וגם הסשנים חיים במתחם אחד.
פיצלנו את המערכת לשתי פלטפורמות מרוחקות גיאוגרפית, העברנו את מסד הנתונים לשכפול "מאסטר — רפליקה עם קידום אוטומטי", ואת הסטטיקה והסשנים העברנו לשכבה משותפת הנגישה לשתי הפלטפורמות.
מה השתנה בנתונים
| מדד | לפני | אחרי |
|---|---|---|
| זמן שחזור בעת כשל צומת | שעות של עבודה ידנית | דקות, מעבר אוטומטי |
| זמינות בשעת שיא | ירידות ופסקי זמן | תגובה יציבה תחת עומס |
| כשל של פלטפורמה אחת | עצירה מוחלטת | החנות ממשיכה למכור |
| גיבויים | לפי לוח זמנים, עם פערים | שכפול רציף |
מדוע זה עובד
המפתח — בהפרדת תפקידים: התעבורה מאוזנת בין הפלטפורמות, מסד הנתונים משוכפל באופן סינכרוני לפעולות קריטיות ובאופן אסינכרוני לאנליטיקה, והסשנים נשמרים מחוץ לשרתי האפליקציות. לכן כשל של כל פלטפורמה אחת אינו מפיל את החנות — הנותרת מקבלת את העומס, והרפליקה של מסד הנתונים מקודמת למאסטר.
היציבות עלתה לא בזכות "חומרה גדולה יותר", אלא בזכות ביטול נקודת הכשל היחידה. הרצנו תרחישי כשל בסביבת בדיקות לפני הפרודקשן: ניתקנו צומת, מסד נתונים, ערוץ בין הפלטפורמות — ווידאנו שהמעבר מתבצע ללא אובדן הזמנות. לאחר ההשקה החנות עמדה במספר שיאים ללא התערבות ידנית של מהנדסים.
במה שונה אשכול geo-distributed משכפול רגיל?
שכפול רגיל פותר משימה אחת: להחזיק עותק חם של מסד הנתונים, כך שבמקרה של כשל בצומת הראשי ניתן לעבור לעותק ולא לאבד נתונים. הגיאוגרפיה כאן משנית — העותק יכול לשבת באולם שרתים סמוך, ומנקודת המבט של האפליקציה זה אותו מתאר בדיוק.
אשכול geo-distributed מתחיל במקום שבו הצמתים מפוזרים פיזית בין אתרים שונים, וכל אחד מהם צריך לשרת תעבורה בעצמו, בלי להמתין לתשובה מאזור אחר.
ההבדל המרכזי הוא במודל הכתיבה. שכפול כברירת מחדל הוא אסינכרוני: המאסטר מקבל את הכתיבה, והעותק מדביק אותו באיחור. כל עוד האיחור נמדד בשניות, הכול נראה מצוין, אבל בעת ניתוק הערוץ בין האתרים מתקבלת אי-התאמה בנתונים, ובעת מעבר — אובדן העסקאות האחרונות.
אשכול geo-distributed נבנה סביב קוורום: כתיבה מאושרת רק כאשר רוב הצמתים קיבלו אותה, ולכן מעבר בין אתרים אינו גורם לחזרה אחורה של נתונים שכבר הוצגו למשתמש.
ההבדל השני הוא ניתוב קריאה. בשכפול רגיל מאזן העומס שולח לעיתים קרובות בקשות קריאה לכל צומת זמין, והמשתמש עלול לראות עמוד מיושן מיד לאחר השמירה. במתאר מבוזר הקריאה נקשרת לאתר של המשתמש, והסשן מוצמד לצומת שאישר את הכתיבה האחרונה.
זה משנה באופן מורגש את התנהגות סל הקניות, האזור האישי וממשק הניהול: הפעולות מפסיקות "להיעלם" בעת מעבר בין אזורים.
תפיסה שגויה אופיינית היא לחשוב שמספיק להעלות עותק באזור אחר ולהכריז על כך כאשכול מבוזר. בלי קוורום, בלי מעבר מתואם ובלי בקרה על השהיית השכפול, תכנית כזו נותנת רק האצת קריאה, אך לא עמידות אתר בפני כשל.
הטעות ההפוכה היא לבנות סינכרוניות קפדנית בין כל הצמתים: בפער גדול השהיית אישור הכתיבה גדלה, ופעולות הניהול מתחילות להתעכב באופן מורגש. הפשרה העובדתית היא קוורום סינכרוני בתוך האתר והעברה אסינכרונית בין אזורים עם בקרת פיגור.
ההבדל השלישי הוא תפעול. שכפול חי לפי עקרון "מאסטר ונתינים": צומת אחד ראשי, והשאר קוראים. באשכול geo-distributed יש יותר תפקידים — יש צמתים שמקבלים כתיבה, צמתים לקריאה בלבד, בוררים לקוורום ואתר לשחזור מאסון.
מכאן דרישות נפרדות לניטור: חשוב לראות לא רק "האם הצומת חי", אלא גם את הפיגור בין האתרים, את מצב הקוורום ואת השאלה איזה אתר מחזיק כעת במנהיגות.
ספקות טכניים לפני ההתחלה
פריסה על פני מספר אתרים כמעט תמיד מעלה שלוש שאלות: מה עם התאימות של הקוד הנוכחי, כיצד יתנהג העומס, ומה יקרה לנתונים בעת המעבר. נבחן כל אחת מהן — לגופן.
תאימות
האשכול אינו דורש כתיבה מחדש של האתר: האפליקציה נשארת זהה, מה שמשתנה הוא שכבת האחסון והניתוב. הבעיות צצות בשני מקומות — הפעלות (sessions) וקבצים שהועלו. את ההפעלות מעבירים לאחסון משותף, אחרת המשתמש ינותק בעת מעבר בין אתרים.
את הקבצים — לאחסון אובייקטים או לכרך מסונכרן, כך שתמונה שהועלתה באתר אחד תהיה זמינה מהאחר. אם בקוד קיימות כתיבות ישירות לנתיבים מקומיים או מטמון קבצים ללא backend משותף — אלו נקודות שאנו בודקים בשלב האודיט, לפני ההעברה.
פריסה ועומס
האתרים מחזיקים רפליקה סינכרונית של בסיס הנתונים ועותקים אסינכרוניים לקריאה — הכתיבה מתבצעת לצומת אחד, והקריאה מתחלקת. זה מסיר את העומס העיקרי מבסיס הנתונים ומעניק מרווח למבקרים בו-זמניים.
מאזן העומס בודק את בריאות הצמתים ומוציא מהרוטציה את זה שהפסיק להגיב — התעבורה עוברת לאתר חי ללא התערבות ידנית.
מה יקרה לנתונים אם אתר אחד יכשל?
רפליקה סינכרונית מבטיחה שכתיבה מאושרת קיימת לפחות בשני צמתים. בעת כשל של אתר, מאזן העומס מעביר את התעבורה, ובסיס הנתונים ממשיך לפעול על הצומת שנותר. העותקים האסינכרוניים מדביקים לאחר השחזור — הפער נסגר אוטומטית.
האם ניתן לפרוס אתרים בשלבים, ללא השבתה?
כן. תחילה מעלים את האתר השני ומגדירים רפליקציה, לאחר מכן מעבירים אליו את הקריאה, ורק אחר כך — את הכתיבה. כל שלב ניתן לחזרה: כל עוד התעבורה לא הועברה, האתר הראשי פועל במתכונת הקודמת.
נדון במשימה שלך
פריסת אשכול geo-distributed הגיונית כאשר האתר מפסיק להתאים לצומת אחד: מסד הנתונים ושרתי האינטרנט מתחילים להתחרות על משאבים, וכשל של אתר אחד משמעו עצירה מוחלטת של השירות. אנו מרכיבים תכנית כזו במפתח — מתכנון הטופולוגיה ועד להעלאה לפעולה ותמיכה בהמשך.
כדי לחזור עם הערכה ותכנית עבודה, אנו זקוקים למינימום נתוני פתיחה: הארכיטקטורה הנוכחית, עומסי שיא, דרישות לעמידות בכשלים והגיאוגרפיה של המשתמשים. זה מספיק כדי להציע טופולוגיה קונקרטית, ולא שיקולים כלליים.
- תכנית חלוקת התפקידים בין הצמתים: היכן נמצאים שרתי האינטרנט, מסד הנתונים, המטמון, המאזן ואחסון הקבצים.
- תכנית שכפול נתונים והגדרת עמידות בכשלים עם ציון נקודות כשל והתנהגות בעת נפילת אתר.
- תצורת איזון תעבורה וניתוב משתמשים בין אזורים.
- סדר ההגירה מהמתאר הנוכחי ללא השבתה או עם חלון אי-זמינות מינימלי.
- תקנון גיבוי, ניטור והתראות עבור כל צומת.
- אומדן משאבים: כמה צמתים, איזה סוג שרתים, אילו ערוצי תקשורת בין האתרים.
- תכנית עבודה לפי שלבים עם אחראים וקריטריוני קבלה בכל שלב.
תאר את המשימה — העומס הנוכחי, הגיאוגרפיה של הקהל ודרישות הזמינות. נחזור עם הערכה, אפשרויות טופולוגיה ותכנית עבודה שממנה רואים מה ובאיזה סדר אנו עושים.