הגדרת Hetzner Cloud Volumes ו-Object Storage מקצה לקצה

למה הדיסקים ב-Hetzner Cloud Volumes מגיעים לגבול

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

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

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

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

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

הרחבת Volumes וצילומי מצב ללא השבתת השירות

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

גדילת הכרך תוך כדי תנועה

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

שחזור מצילומי מצב

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

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

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

מצבי אחסון: כרכי בלוקים, אחסון אובייקטים ומקומי

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

קריטריונים לבחירה

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

צווארי בקבוק אופייניים

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

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

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

ביקורת ותכנון

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

יישום וקבלה

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

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

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

מה כלול בערכת המסירה

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

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

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

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

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

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

מעבר ללא השבתת השירות

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

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

מה לעשות אם האחסון כבר פרוס ומכיל נתונים?

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

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

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

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

תוכנית החזרה לאחור מתועדת לפני ההתחלה: התוכנית הישנה לא מפורקת עד שהחדשה תעבור מחזור מלא של «כתיבה — קריאה — גיבוי — שחזור». ההשבתה במעבר כזה נמדדת בשניות למעבר קריאה, ולא בשעות העתקה; עיקר העבודה מתבצע ברקע, על שירות חי.

ספקות טכניים: שלמות, גישות ועמידות בכשלים

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

איך להפריד הרשאות גישה בין שירותים?

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

מה יקרה בכשל של צומת?

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

איך בנויים הצפנה וביקורת גישות?

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

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

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

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

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

לתוכנית העבודה ייכנסו:

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

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