מדוע מסדי נתונים מנוהלים ב-Azure מדרדרים תחת עומס
שיא עומס לעיתים רחוקות שובר מסד נתונים מנוהל ב-Azure בבת אחת. תחילה גדל זמן התגובה: שאילתות שהגיבו מהר בבוקר ממתינות בשיא הערב לשחרור חיבור מהמאגר, חלק מהטרנזקציות נכנסות לנעילות, ויישומי לקוח מתחילים להיתקל בפסקי זמן.
הסיבה בדרך כלל אינה בכוח החומרה, אלא בצוואר בקבוק של המסד — תוכנית שאילתה לא מוצלחת, אינדקס חסר או רמת שירות שהפסיקה להתאים לנפח הנתונים.
חמור יותר הוא מקרה השבתה עקב כשל אזור. אם למסד אין רפליקה באזור אחר, מעבר אוטומטי לא יתרחש: השירות מושבת לחלוטין, והעלאה מגיבוי אורכת שעות. הנתונים מתגלגלים אחורה לרגע תמונת המצב האחרונה, וכל מה שנכתב לאחר מכן צריך לאסוף ידנית.
התרחיש השלישי אינו מורגש עד הרגע האחרון — היעדר נראות. בלי מדדים לזמן המתנה, מספר חיבורים פעילים והשהיית קלט/פלט, הדרדור מתבטא רק בתלונות משתמשים. המהנדס לא יכול להבחין בין עלייה במספר הפניות לבין דליפת חיבורים לבין מיצוי רוחב הפס של האחסון, ולכן ההגדרה נעשית לפי ניחוש.
כל שלושת הכשלים נמצאים במישור אחד — קונפיגורציה, טופולוגיה וניטור. נפרט כיצד זה נסגר.
מה משתנה לאחר ההגדרה: זמינות וזמן שחזור
לאחר ההגדרה של מסדי נתונים מנוהלים ב-Azure משתנים לא רק פרמטרי הקונפיגורציה, אלא גם התנהגות המערכת בעת כשל ודרדור. מצבים שהעסק תלוי בהם — מעבר רפליקות, שחזור מגיבוי, תגובה לעלייה בהשהיות — מפסיקים להיות "בערך" ונבדקים בקבלה. להלן מה שאנחנו מתעדים כתוצאה.
עמידות בפני כשלים ומעבר אוטומטי של רפליקות. צומת ראשי ורפליקות מופרדים לאזורי זמינות, מעבר אוטומטי של רפליקות מופעל ברמת האשכול, ולא באמצעות סקריפט של תורן.
בעת כשל בצומת, רפליקה מוכנה מקבלת את תפקיד הראשי, האפליקציה מתחברת מחדש דרך מחרוזת חיבור עם ניסיונות חוזרים — זמן השחזור של המסד מתקצר משעות של טיפול ידני לשניות. ההבדל הוא פי עשרות, והוא משוחזר: אנחנו בודקים את המעבר בבדיקה, ולא ממתינים לתקלה אמיתית.
גיבוי ושחזור ניתנים לבדיקה. גיבויים מלאים וגיבויי יומן — לפי לוח זמנים, תקופות שמירה נקבעות במדיניות ואינן גדלות ללא בקרה, חלק מהגיבויים נמצאים באחסון מרוחק גיאוגרפית. העיקר — שחזור למופע נפרד לפי נוהל: אנחנו יודעים שהגיבוי נפרס, ולא רק ש"נוצר". שחזור לנקודת זמן מחזיר למצב של דקות לפני הכשל.
נראות של המסד. מדדים, יומנים ושאילתות איטיות נאספים במקום אחד, התראות מוגדרות למיצוי מקום, עלייה בזמני המתנה וירידה ברוחב פס. התקרית נראית לפני שהמשתמש מבחין בה, והניתוח אורך דקות.
מצבי פריסה ב-Azure: שרת בודד, מאגר או אשכול
הבחירה במצב פריסה במסדי נתונים מנוהלים ב-Azure קובעת שני דברים: כיצד יגדל העומס ומה יהיה צריך לשנות בסכמת הנתונים בעת המעבר. שרת בודד, מאגר אלסטי ואשכול עם רפליקות — אינם תעריפים הניתנים להחלפה, אלא מודלים שונים של בידוד משאבים.
| אפשרות | מתי מתאימה | מגבלות של מסד מנוהל |
|---|---|---|
| שרת בודד | מסד אחד, עומס צפוי, הגדרות משלו ולוח זמנים לגיבויים | משאבים אינם מופרדים; תחזוקה מתוכננת עם ניתוק חיבור |
| מאגר אלסטי | עשרות מסדים קטנים עם עומס שונה ועומס שיא | תקרת משאבים כוללת ומגבלת חיבורים; שאילתות חוצות מסדים אינן זמינות |
| אשכול עם רפליקות | עומס קריאה, דרישה למעבר מהיר | רפליקות לקריאה בלבד, השהיית רפליקציה, שינוי סכמה מורכב יותר |
מגבלת המצב מתבטאת בשני תרחישים — שינוי סכמה ומעבר בעת כשל. במאגר, מיגרציה כבדה של מסד אחד פוגעת בשכנים בגלל התקרה המשותפת, ולכן מפזרים אותה על פני חלונות.
באשכול, הרפליקות קוראות את אותה סכמה, שינויים נפרסים בהדרגה, והמעבר האוטומטי אורך שניות, אך דורש מהאפליקציה לטפל נכון בניתוק חיבור.
לפני הפריסה מחשבים כיצד המסד יגדל: הרבה מסדים קטנים — מאגר, אחד עם קריאה כבדה — אשכול, תחזית מלאה — שרת בודד. טעות בבחירה צפה לא בהתחלה, אלא בהרחבה הראשונה, כאשר המעבר כבר נוגע בסכמה ובמחרוזות חיבור.
שלבי יישום: מביקורת הסכמה הנוכחית ועד מסירת נהלים
המעבר של מסדי נתונים מנוהלים ב-Azure למצב עמיד בפני כשלים מתבצע באופן רציף: כל שלב נשען על הנתונים של השלב הקודם, ולכן ביקורת עומס תמיד קודמת לבחירת טופולוגיה. בכניסה נדרשים מדדים מתקופה מייצגת — החלטה שהתקבלה לפי עומס ממוצע מתפרקת בשיא.
- ביקורת תשתית המסדים. מתעדים פרופיל שאילתות, נפח וקצב גדילת נתונים, שעות שיא, תחרות על נעילות. בודקים כללי רשת והרשאות של אפליקציות — לרוב דווקא הם מפריעים לבנות סכמת עמידות בפני כשלים.
- תכנון סכמת עמידות בפני כשלים. בוחרים טופולוגיה: אזור זמינות אחד או גיבוי גיאוגרפי, כתיבה סינכרונית או אסינכרונית. מתעדים זמן השבתה יעד ואובדן נתונים מותר — זו המסגרת לכל ההגדרות הבאות.
- הגדרת רפליקציה. מפזרים תעבורת קריאה לצמתים משניים, קובעים סדר מעבר בעת כשל, בוחרים רמת עקביות לפי לוגיקת האפליקציה. אחרת, במקום שבו נדרשת טריות נתונים, מופיעים נתונים מיושנים.
- ניטור. מכסים השהיית רפליקציה, גדילת אחסון, המתנות בגלל נעילות ושגיאות חיבור. ספי התראות משייכים לתורנות, כדי שהאות יגיע למי שיכול לפעול.
- בדיקת שחזור. מכבים צומת, מעלים את המסד מגיבוי במתחם נפרד, מודדים זמן בפועל עד לכשירות. פער מהיעד — סיבה לחזור לטופולוגיה, ולא לנוהל.
- מסירת נהלים. מוסרים סכמה עם נקודות כשל, הוראות לתקריות טיפוסיות, לוח זמנים לגיבויים ומדיניות שמירה, סדר שינויים והרשאות. הצוות מפעיל בעצמו, ואנחנו מלווים שינויים.
מה מועבר לידיים שלכם: קונפיגורציות, סכמות, מדיניות גישה
אנחנו מוסרים לא רק מסד עובד, אלא את כל הערכה שתאפשר לצוות שלכם להמשיך להפעיל אותו בלעדינו. כל הארטיפקטים רשומים על חשבונות שלכם ונמצאים במאגר שלכם — אנחנו לא נשארים מחזיקי המפתחות.
- קונפיגורציית המסד: פרמטרים של המופע, רמת עמידות בפני כשלים, כללי גדילת אחסון — בקבצים דקלרטיביים, שלפיהם נפרסת סביבה זהה.
- סכמת תשתית: טופולוגיה עם אזורי זמינות, רפליקות קריאה, נקודות חיבור פרטיות וגבולות של מקטעי רשת.
- מדיניות גישה ותפקידים: הפרדה בין מנהלים, מפתחים וחשבונות שירות, הרשאות מינימליות נדרשות, ביקורת חיבורים.
- נהלי גיבוי: לוח זמנים לגיבויים, תקופת שמירה, שחזור לנקודת זמן ובדיקת שחזור חובה בסביבת בדיקה.
- ניטור: מדדים עם ספים — השהיית רפליקציה, מילוי אחסון, שאילתות ארוכות — ומסלולי התראות עם מטריצת אסקלציה.
- סדר תורנות: זמני תגובה, מה נחשב לתקרית, אילו פעולות מותרות ללא אישור.
- העברת ידע: סקירת ארכיטקטורה עם הצוות שלכם, יומן שינויים, הוראות לעדכון, חזרה אחורה ומעבר.
כל ארטיפקט מתאמים לפני מסירה, ולכן המסמכים מתארים סביבה אמיתית, ולא תבנית גנרית. חודש לאחר ההפעלה אנחנו עורכים השוואה: בודקים מה בקונפיגורציה לא תאם לתיאור, ומחזירים את הפערים לקבצים — אחרת התיעוד מתיישן בשקט ומפסיק להיות מקור אמת.
מקרה בוחן: אשכול עם מעבר אוטומטי במקום פעולות ידניות
לפני המעבר לניהול, המסד חי על צומת אחד: צומת גיבוי הוקם ידנית לפי הוראות, והמעבר ארך בין ארבעים דקות לשעה. התורן ביצע 12–14 צעדים ידניים — מעצירת האפליקציות ועד החלפת נקודת החיבור, וכל צעד יכול היה להתבצע בסדר שגוי.
מה שינינו
פרסנו אשכול של מסדי נתונים מנוהלים ב-Azure עם רפליקות באזורי זמינות שונים: בדיקת זמינות מורידה בעצמה צומת שכשל, העלאת רפליקה והפניית חיבורים מבוצעות על ידי הפלטפורמה.
הגדרנו לוח זמנים לגיבויים מלאים ושמירת יומני ביניים, הוספנו שחזור לנקודת זמן שרירותית, וניטור — התראות על השהיית רפליקציה, חיבורים פנויים ושאילתות ממושכות. לתורן נשאר נוהל קצר: לאשר את התקרית ולבדוק שהאפליקציות חזרו לעבוד.
מה השתנה
המעבר התקצר ל-60–90 שניות, פעולות ידניות בעת כשל בצומת — אפס במקום 12–14. שמונה מתוך עשרה כשלים נסגרים בלי מעורבות התורן: הפלטפורמה מעבירה תעבורה לרפליקה חיה, והצוות לומד על כך מהיומן, ולא משיחת טלפון באמצע הלילה.
«קודם לכן מחצית מהמעברים התרחשו בלילה, ועד הבוקר אף אחד לא הבין מה מצב המסד. כעת האפליקציה עוברת כשל בצומת בלי שהמשתמש מבחין», — מהנדס תשתיות ראשי
מה עושים אם כבר פרוס אשכול משלכם על השרתים שלכם?
המעבר לא חייב להיות חד-פעמי. בדרך כלל מחלקים את המתחם לקבוצות: מסדי דוחות וניתוח, תורים ושירותים בשימוש נדיר מועברים ראשונים, והליבה עם דרישות השהיה קפדניות נשארת על השרתים שלכם עד שהמסד המנוהל יוכיח התנהגות תחת עומס אמיתי.
מיגרציה מדורגת נראית כך: טעינה ראשונית של תמונת מצב אל Azure, לאחר מכן רפליקציה רציפה של שינויים והשוואת סכומי ביקורת לפי טבלאות. כל עוד הפער אינו אפס, המקור נשאר ראשי, ומסד היעד עובד במצב קריאה — אפשר להעביר אליו את האפליקציה לפני הכתיבה.
תאימות דרייברים נבדקת לפני העברת התעבורה: מחרוזות חיבור, מאגר חיבורים, התנהגות בעת ניתוק, קידודים וסוגי נתונים. חלק מספריות הלקוח דורשות הגדרות מפורשות, אחרת לאחר המעבר האפליקציה נכנסת לניסיונות חוזרים ומכריעה את המסד בחזרות.
סנכרון הנתונים בשלב המעבר נשען על יומן השינויים — הוא גם מאפשר זרימה חזרה, אם יהיה צורך לחזור. חלון המעבר נמדד בדקות, והחזרה אחורה — בהחזרת התעבורה לרפליקות שלכם ללא אובדן רשומות.
במקום הגיוני להשאיר משימות רקע כבדות, גישות לדיסקים מקומיים וסכמות עם הרחבות שאין בצד השירות. את השאר מעבירים בגלים, ולכל שלב יש קריטריון בדיק — ולכן השאלה "מה אם זה לא יתאים" נפתרת בשלב ביניים, ולא אחרי פירוק מלא של האשכול.
ספקות אופייניות: תאימות, חזרה אחורה, אזורי זמינות
לפני תחילת העבודה הלקוח בודק ארבעה דברים: האם האפליקציה תעבוד על מסדי נתונים מנוהלים ב-Azure בלי לכתוב אותה מחדש, האם אפשר להחזיר עדכון אחורה, מה יקרה בכשל של אזור זמינות והיכן עובר גבול האחריות של הקבלן.
האם יהיה צורך לכתוב את האפליקציה מחדש בעת המעבר?
בדרך כלל לא: שומרים על הדיאלקט, מחרוזות החיבור והדרייברים, בנפרד בודקים את רמת התאימות, פרמטרי השרת וההרחבות. לפני המעבר מרימים עותק, מריצים פרופיל שאילתות אמיתי ומשווים תוכניות ביצוע — פערים נראים לפני ההרצה בפרודקשן.
כיצד מחזירים עדכון כושל אחורה?
את הסכמה משנים במיגרציות, שלכל אחת יש פעולה הפוכה, וההחלה מתבצעת תחילה במתחם בדיקות. החלפת גרסאות נעשית ברמת מחרוזות החיבור, ולכן החזרה אורכת דקות; אם הנתונים נפגעו, מרימים את המסד לנקודת זמן לפני השינוי.
מה יקרה אם אזור זמינות ייכשל?
המסד נפרס עם רפליקה באזור אחר, המעבר בעת כשל אוטומטי, האפליקציה מתחברת מחדש בעצמה. התפקידים כאן שונים: רפליקה מגנה מפני כשל חומרה, וגיבוי — מפני טעות אנוש ופגיעה בנתונים, אחד לא מחליף את השני.
מי אחראי לתקלה — אנחנו או הפלטפורמה?
הפלטפורמה אחראית על התשתית הפיזית וזמינות השירות, ואנחנו — על ההגדרה, נהלי הגיבוי, הניטור והשחזור. את הגבול מתעדים במסמך: מה אנחנו מנטרים, מה הפלטפורמה מכסה ובאיזה חלון אנחנו מחויבים להגיב.
נדון במשימה ונחזור עם תוכנית עבודה
תוכנית עבודה אנחנו לא מרכיבים "בערך" — היא נשענת על ניתוח הסכמה הנוכחית, ולכן להערכה מספיק מיפוי מלאי: אילו מסדי נתונים מנוהלים ב-Azure נמצאים בשימוש, באילו אזורים, כיצד האפליקציות מתחברות אליהם, אילו דרישות לזמינות ולשלמות נתונים הוצהרו.
אם התשתית כבר מתוארת בקוד, שלחו את המאגר והקונפיגורציות; אם לא — די בייצוא של רשימת שרתים ומסדים, סכמות הגיבוי הנוכחיות והגדרות הגישה. זה מספיק כדי לחזור עם תוכנית יישום, ולא עם שאלות הבהרה.
- ניתוח הסכמה הנוכחית: טופולוגיה, רפליקציה, עמידות בפני כשלים, מגבלות רשת, נקודות כשל ברורות.
- רשימת סיכונים עם עדיפות: היכן כשל יגרום להשבתה, והיכן הנתונים לא ישוחזרו בזמן הנדרש.
- ארכיטקטורת יעד: רמת זמינות, גיבוי גיאוגרפי, פרמטרי אחסון, מדיניות גיבוי ושחזור לנקודת זמן.
- סדר העבודה לפי שלבים: הכנה, העברה, בדיקת תרחישי כשל, העלאה לפרודקשן.
- הערכת מאמץ לכל שלב עם הנחות ותלויות — ההיקף והמועדים שקופים לפני ההתחלה.
- נוהל ניטור: אילו מדדים נאספים, ספי התראות, מי מגיב ובאיזה סדר.
- מסירה לתמיכה ותחזוקה: הרשאות, תיעוד, הדרכת הצוות שלכם וחלון לתיקון הערות.
כל שלב נסגר בתוצאה ניתנת לבדיקה: מיגרציית בדיקה, דוח בדיקת כשל, התראות עובדות. תארו את המשימה — נחזור עם ניתוח, סיכונים ותוכנית עבודה.