הגדרת תשתית ענן ב-Hetzner Cloud מקצה לקצה

תשתית ב-Hetzner Cloud: מה נשבר בהגדרה ידנית

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

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

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

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

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

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

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

מה נותנת תשתית מנוהלת: ההשפעה על לוחות זמנים ואמינות

תשתית מנוהלת משנה לא מדד בודד אלא את התנהגות המערכת תחת עומס וברגע של כשל. תיאורי הסביבות נשמרים במאגר (repository), כל שינוי עובר בדיקה ומשוחזר באופן זהה בכל הסביבות — ב-Hetzner Cloud זה נבנה מתמונות ותבניות בלי התאמות ידניות על השרתים. מכאן נובעות שלוש תוצאות מדידות.

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

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

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

Hetzner Cloud: מצבי פריסה ומתי כל אחד מתאים

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

אזור האחריות: היכן נגמר הספק ומתחילים אנחנו

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

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

איך בוחרים מצב

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

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

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

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

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

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

3. הגדרת רשתות והרשאות. רשתות פרטיות, כללי חומת אש, Bastion לגישת ניהול, מודל תפקידים. הסודות נשמרים במאגר סודות ולא במאגר הקוד; גישה ניתנת לפי המינימום הנדרש.

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

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

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

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

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

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

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

מקרה בוחן: העברת שירות לענן ומדדים לפני ואחרי

התשתית לפני העבודה

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

מה שינינו ומה יצא

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

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

השחזור לאחר כשל צומת התקצר מ-4-6 שעות ל-10-15 דקות, סביבת הייצור נפרסת ב-20 דקות במקום חצי יום, המהדורות עברו לקצב יומי, והחזרה לתמונה הקודמת אורכת דקות. ההשבתה בעבודות מתוכננות — דקות בודדות בזכות פריסה בלי עצירת השירות.

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

במה נבדלות מכונות וירטואליות בענן משרת ייעודי

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

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

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

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

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

שאלות טכניות נפוצות: הרשאות ועמידות בכשלים

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

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

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

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

איך בנויים הגיבויים והעמידות בכשלים?

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

אפשר אחר כך לחזור אחורה או לעבור לאתר אחר?

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

איך מתחילים מעבר לענן: נדון במשימה שלכם

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

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

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