הגדרת שרתי Hetzner Dedicated מקצה לקצה

התקנת Hetzner Dedicated: מה נשבר בהתקנה טיפוסית

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

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

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

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

מה משתנה אחרי ההעברה: הרשאות, גיבוי, עדכונים

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

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

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

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

אפשרויות פריסה: הגדרה ידנית, תבניות, אוטומציה

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

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

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

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

שלבי העבודה: מאודיט שרת ועד מסירת הרשאות

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

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

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

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

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

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

מקרה בוחן: איך קיצרנו את זמן השחזור אחרי תקלה

מה היה בנקודת ההתחלה

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

בזמן תקלה השחזור ארך כשלוש שעות: להעלות צומת, להיזכר ברצף הצעדים, לפרוס מעותק הלילה ולאבד נתונים של יממה. עדכון מתוכנן גם הוא означал השבתה של 30-40 דקות.

מה שינינו

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

מה יצא

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

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

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

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

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

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

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

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

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

שאלות טכניות: גיבויים, ניטור, עדכונים

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

מי узнаёт о сбое первым — вы или мы?

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

האם עדכונים דורשים עצירת השירות?

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

אפשר לערוך את השרת בעצמנו אחרי המסירה?

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

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

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

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

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