הגדרת Yandex Compute Cloud לשרתים וירטואליים

מדוע Yandex Compute Cloud אינו יציב

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

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

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

הסיבה השלישית — היעדר מגבלות ונראות. בלי מכסות על משאבים, תהליך אחד אוכל את הצומת, והשירותים הסמוכים מדרדרים יחד איתו. בלי מדדים והתראות על עומס, הצוות לומד על הבעיה מהמשתמשים ולא מהמערכת, ומכבה את התסמין במקום את הסיבה.

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

מה נותנת תשתית שתוכננה נכון

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

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

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

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

סכימות מיקום ב-Compute Cloud: מה לבחור

סכימת מיקום מגדירה לא «רמת אמינות כללית», אלא סוג תקלה קונקרטי שהמערכת תעבור בלי התערבות אדם. אזור זמינות אחד, שניים-שלושה אזורים, קבוצת סקיילינג אוטומטי או שרת גיבוי — אלה פשרות שונות בין עמידות, מורכבות תחזוקה וצפיות של מעבר. נפרט מה כל אפשרות מכסה ואיפה היא מתחילה להפריע.

ב-Yandex Compute Cloud אפשרויות אלה משולבות: את הפרונט אפשר להחזיק בקבוצת סקיילינג אוטומטי על פני כמה אזורים, ואת השירותים עם מצב — על שרתי גיבוי עם תרחיש מעבר מתורגל. השאלה המרכזית — היכן חי המצב וכמה מהר הוא מתאושש לאחר תקלה.

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

שלבי יישום: מביקורת ועד מסירה

את העבודה מובילים באיטרציות: כל שלב מסתיים בארטיפקט ניתן לבדיקה, ולא ב«נהיה טוב יותר». סדר כזה נדרש כדי שאפשר יהיה לבטל שינויים ב-Yandex Compute Cloud בכל שלב, ולא רק אחרי מעבר מלא של הפרודקשן.

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

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

3. הגדרת שרתים. מתארים משאבים כקוד (Terraform), קונפיגורציה ראשונית — באמצעות תפקידים של Ansible. תמונות מקובעות, קבצי קונפיגורציה מנוהלים בגרסאות, שינויים עוברים סקירה ומשוחזרים מאפס, ולא «תיקון ידני».

4. בדיקת עמידות לתקלות. מכבים צומת אחד בכל קבוצה ובודקים כיצד עוברת התעבורה. מודדים את זמן ההתאוששות של השירות ומשווים לדרישות המוצהרות.

5. גיבוי. מגדירים מדיניות צילומי מצב ובודקים את הנתיב ההפוך: פורסים שרת מעותק בקונטור נפרד ומוודאים שהנתונים שלמים.

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

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

סכימות, גישות ונהלים שנשארים אצלכם

תשתית ב-Yandex Compute Cloud חיה לא בקונסולת ווב, אלא בתיאור: אם היא לא מתועדת בשום מקום, השינוי הבא הופך לארכיאולוגיה, והשחזור — למשא ומתן עם מי שהגדיר. לכן אנחנו מוסרים לא רק שרתים עובדים, אלא גם סט ארטיפקטים שלפיו הסביבה משוחזרת מאפס.

מה נשאר אצל הצוות שלכם:

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

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

מקרה בוחן: עמדו בעלייה בעומס בלי להרכיב מחדש שרתים

הפרויקט — שירות עם עומס לא אחיד לפי ימים: בשעות שיא מספר הבקשות גדול פי שלושה מהממוצע. המכונות ישבו על מכונות וירטואליות קבועות ב-Yandex Compute Cloud, וכל קיבולת חדשה הופיעה רק לאחר פעולות ידניות.

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

מה היה לפני השינויים

שיעור הבקשות המוצלחות החזיק מעמד על 97%: שגיאות נתפסו דווקא בשעות השיא, כשהקיבולת לא הספיקה. ההתאוששות לאחר תקלה ארכה בממוצע 40 דקות — עד שהבחינו בבעיה, הקימו מחליף והחזירו אותו לעבודה. פעולות ידניות בעת כשל של מכונה אחת — יותר מעשר, כל אחת עם סיכון לטעות בחיפזון.

מה שינו

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

מה קיבלו

שיעור הבקשות המוצלחות עלה ל-99.9% ואינו יורד יותר בשיא. ההתאוששות אורכת 2-3 דקות ומתרחשת אוטומטית, בלי מעורבות תורן. פעולות ידניות בכשל צומת — אפס, הקיבולת מתווספת מעצמה לפי גידול התעבורה, ולא לפי בקשה.

במה מסדי נתונים מנוהלים שונים ממסדים על שרתים משלכם?

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

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

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

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

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

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

מה הכי נפוץ שמבהירים לפני תחילת העבודות

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

האם צריך להתאים את האפליקציה?

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

איך מאורגנות הגישות?

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

מה יקרה בגידול בעומס?

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

איך מתאוששים הנתונים?

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

נדון במשימה ונחזור עם הערכה ותוכנית

כדי שהשיחה תהיה עניינית, לא צריך הרבה: גישה לקונפיגורציה הנוכחית, הבנה של העומסים הקריטיים ואדם שמכיר את היסטוריית השינויים. השאר — העבודה שלנו, כולל מלאי של מה שפרוס ב-Yandex Compute Cloud היום.

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

בסוף התהליך תקבלו:

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

תארו את המשימה: מה עובד сейчас, מה מפריע ואיזו תוצאה נדרשת. נחזור עם הערכה ותוכנית, ולשיחה יגיע מהנדס שיוביל את הפרויקט — לא מנהל עם מצגת.