VPS מנוהל או לא מנוהל: איך לבחור נכון?

VPS מנוהל לעומת לא מנוהל: התשובה הקצרה

הבחירה בין VPS מנוהל ללא מנוהל היא שאלה של כוח אדם, לא של מוצר. שרת לא מנוהל אומר שאתם אחראים על עדכוני אבטחה (patching), ה-firewall, הגיבויים, הניטור והפעלת השרת מחדש בשעה 2 לפנות בוקר. שרת מנוהל אומר שהספק מבצע חלק מהמשימות הללו עבורכם, כאשר היקף השירות משתנה משמעותית בין ספקים. ההשוואה היחידה שמועילה היא רשימת המשימות שכל תוכנית מסירה מכם, מתומחרת מול השעות שלכם.

אין הגדרה סטנדרטית למילה managed (מנוהל). ספק אחד מתכוון לכך שמערכת ההפעלה מקבלת עדכונים ושאדם עונה לכרטיסי תמיכה. אחר מתכוון לכך שהותקן לוח בקרה (control panel) וכל מה שמעליו הוא באחריותכם. שלישי מתכוון לחוזה שירות כתוב הכולל זמן תגובה מוגדר. שתי תוכניות הנושאות את אותו השם יכולות להיות שונות בכל היבט מהותי, לכן קראו את מסמך היקף השירות לפני שאתם בוחנים את המחיר. אם אתם עדיין מחליטים למה המכונה מיועדת, מה אפשר לעשות בפועל עם VPS היא השאלה שעדיף להכריע קודם.

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

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

• עדכוני מערכת ההפעלה, והאתחולים הנדרשים לאחר עדכוני kernel.
• חוקי firewall, שיש לשמור על תקינותם בעת הוספה או הסרה של שירותים. המדריך יסודות ה-firewall מסוג ufw עבור VPS מכסה את מערך החוקים הראשוני.
• גישת SSH: ניהול מפתחות, ביטול כניסה באמצעות סיסמה, ביטול מפתח כאשר משתמש עוזב, וקיום דרך גישה חלופית למקרה שתינעל מחוץ לשרת.
• גיבויים, עותק מחוץ לאתר (offsite), וביצוע בפועל של שחזור כדי לוודא תקינות.
• ניטור, שמשמעותו לדעת שהשרת נגיש, שיש מקום פנוי בדיסק, שהשירות רץ, ושהתעודה לא פגה.
• סקירת לוגים, ותגובה כאשר משהו בלוגים נראה חשוד או שגוי.
• תצורת שירותים עבור שרת ה-web, מסד הנתונים, ה-reverse proxy, והתור (queue) אם קיים כזה.
• חידוש תעודות, ותיקון תקלות כאשר החידוש האוטומטי מפסיק לעבוד.
• קיבולת, שמשמעותה להבחין בכך שהזיכרון עומד להיגמר לפני ש-OOM (Out of Memory) killer יבצע זאת עבורך.
• תגובה לאירועים (incident response), שמשמעותה להיות ער וזמין בשעות שלא בחרת בהן.

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

מה שניהול מנוהל בדרך כלל אינו כולל

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

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

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

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

תוכנה שהתקנתם היא באחריותכם. אם התקנתם Docker, הספק בדרך כלל אחראי על המארח (host) ואתם אחראים על כל מה שנמצא בתוך המכולות.

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

תמחור הזמן שלך מול ההפרש החודשי

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

• מהו הערך הכספי של שעת עבודה שלכם, וכמה שעות בחודש דורשת הרשימה הזו לאחר שהיא עוברת אוטומציה?
• מהי העלות של שעת השבתה אחת עבור השירות שרץ על השרת הזה?

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

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

שאלות שיש להפנות למארח לפני תשלום עבור שירות מנוהל (Managed)

שאלו לפני שתשלמו, ובקשו את התשובות בכתב. דף מכירות אינו מסמך הגדרת היקף עבודה (Scope).

1. מה כלול בהיקף השירות, משימה אחר משימה? בקשו רשימה מפורטת, לא את עלון השיווק.
2. האם התמיכה מכסה תוכנה שאני מתקין, או רק תוכנה שאתם התקנתם?
3. האם אתם מבצעים עדכוני אבטחה (patching) באופן אוטומטי, והאם אתם מבצעים אתחול עבור עדכוני kernel מבלי לבקש את אישורי מראש?
4. מי נושא באחריות אם עדכון שביצעתם גורם לתקלה ביישום שלי?
5. האם אתם מבצעים גיבויים? היכן הם נשמרים, לכמה זמן הם נשמרים, ומי מבצע את השחזור?
6. האם שחזרתם שרת של לקוח לאחרונה, וכמה זמן זה לקח?
7. מהו זמן התגובה לכרטיס תמיכה (ticket), והאם הוא שונה בשעה 03:00 ביום ראשון?
8. האם נשמרת אצלי גישת root, והאם השימוש בה מצמצם את היקף התמיכה שתספקו לי?
9. האם התשלום נגבה לפי שרת או לפי חשבון?
10. אם אעזוב, מה אני לוקח איתי? הגדרה שחיה בתוך לוח בקרה קנייני עלולה להיות קשה לייצוא.

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

דרך האמצע: ניהול עצמי עם אוטומציה

רוב הקוראים הטכניים אינם מעוניינים באף אחד מהקצוות. הם מעדיפים תוכנית ללא ניהול (unmanaged) שבה המכונה מבצעת את העבודה השגרתית, בעוד הם מתפנים לטפל בדברים שמכונה אינה יכולה לשפוט. הגדירו זאת ביום הראשון. עשר הדקות הראשונות ב-VPS חדש הן נקודת התחלה מעשית לכל מי שבוחר בניהול עצמי, והקשחת גישת SSH צריכה להתבצע באותה פגישה ראשונה.

עדכוני אבטחה אוטומטיים

sudo apt update && sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades
cat /etc/apt/apt.conf.d/20auto-upgrades

הקובץ הזה אמור להכיל כעת את APT::Periodic::Update-Package-Lists "1"; ואת APT::Periodic::Unattended-Upgrade "1";. קובץ חסר, או 0 באחת השורות, משמעותם ששום דבר לא רץ ולא תקבלו על כך התראה.

בצעו בדיקה מבלי לשנות את המערכת. שימו לב שהחבילה היא unattended-upgrades בעוד הפקודה היא ביחיד:

sudo unattended-upgrade --dry-run --debug

הפלט מפרט כל חבילה שנבדקה ומסתיים בשורה כמו No packages found that can be upgraded unattended כאשר אין עדכונים ממתינים. הרצות אמיתיות נכתבות ל-/var/log/unattended-upgrades/unattended-upgrades.log, לכן בדקו שם במקום לנחש.

עדכון ליבה (kernel) אינו משנה דבר עד שהמכונה עוברת אתחול, כיוון שהליבה שרצה היא זו שנטענה בזמן ה-boot. הקובץ /var/run/reboot-required מופיע כאשר אתחול ממתין לביצוע. עקבו אחר הקובץ הזה, או תנו למכונה לטפל בכך ב-/etc/apt/apt.conf.d/50unattended-upgrades:

Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-WithUsers "false";
Unattended-Upgrade::Automatic-Reboot-Time "02:00";

Automatic-Reboot-WithUsers "false" מעכב את האתחול כל עוד מישהו מחובר למערכת, מה שמאובטח יותר בשרת שאתם עובדים עליו אינטראקטיבית, אך חסר תועלת בשרת שאף אחד לא מתחבר אליו. הגדרה מלאה של unattended upgrades ב-Ubuntu מכסה את תחביר ה-blocklist ואת אפשרויות הדואר האלקטרוני.

ניטור שרץ במקום אחר

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

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

df -h
sudo du -xh --max-depth=1 /var | sort -h
journalctl --disk-usage

הוסיפו גם heartbeat. טיימר בשרת קורא ל-URL לאחר כל גיבוי מוצלח או בדיקת תקינות, והמנטר מתריע כאשר הקריאה הזו מפסיקה להגיע. שרת שותק מייצר התראה בעצמו, דבר שבדיקת pull-only לא יכולה לעשות כאשר נתיב הרשת הוא זה שקרס.

גיבויים ששחזרתם לפחות פעם אחת

sudo apt install -y restic
sudo sh -c 'umask 077; printf %s "a-long-random-passphrase" > /root/.restic-pass'
export RESTIC_REPOSITORY=sftp:backup@backup.example.com:/srv/restic/web01
export RESTIC_PASSWORD_FILE=/root/.restic-pass
sudo -E restic init

restic init מדפיס את created restic repository <id> at sftp:... פעם אחת. הרצה מול מאגר (repository) שכבר קיים תיכשל במקום לדרוס אותו, וזהו אופן הפעולה הרצוי. שמרו עותק של סיסמת הגישה הזו מחוץ לשרת: המאגר אינו קריא בלעדיה, ואין נתיב שחזור.

sudo -E restic backup /etc /home /srv
sudo -E restic snapshots
sudo -E restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
sudo -E restic check

restic snapshots אמור להציג את ההרצה שביצעתם זה עתה עם התאריך של היום. restic check מאמת את מבנה המאגר ומדפיס את no errors were found. כעת בצעו את החלק שרוב האנשים מדלגים עליו:

sudo -E restic restore latest --target /tmp/restore-check
ls /tmp/restore-check/etc

הקובץ שציפיתם לו נמצא שם או שלא, וגילוי העובדה הזו עכשיו חוסך לכם עשר דקות. לאחר מכן, הגדירו את ההרצה בטיימר כדי שלא תהיה תלויה בכם. כתבו את /etc/systemd/system/restic-backup.service:

[Unit]
Description=restic backup
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
Environment=RESTIC_REPOSITORY=sftp:backup@backup.example.com:/srv/restic/web01
Environment=RESTIC_PASSWORD_FILE=/root/.restic-pass
ExecStart=/usr/bin/restic backup /etc /home /srv
ExecStart=/usr/bin/restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

ואת /etc/systemd/system/restic-backup.timer:

[Unit]
Description=Run restic backup daily

[Timer]
OnCalendar=daily
RandomizedDelaySec=30m
Persistent=true

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now restic-backup.timer
sudo systemctl start restic-backup.service
journalctl -u restic-backup.service -n 30 --no-pager
systemctl list-timers restic-backup.timer

list-timers מציג את ההרצה הבאה ואת הזמן שנותר. תוצאה ריקה משמעותה שהפעלתם את השירות במקום את הטיימר, וזו הטעות הנפוצה ביותר כאן. Persistent=true מריץ משימה שהוחמצה לאחר ה-boot הבא, כך שמכונה שהייתה כבויה במהלך הלילה עדיין תבצע את הגיבוי שלה. גיבויי Restic ב-VPS מעמיק במבנה המאגר ובשמירת גרסאות, ו-שירותי systemd וטיימרים מסביר את קובצי ה-unit שורה אחר שורה.

מה אוטומציה לא קונה לכם

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

systemctl is-enabled nginx docker
sudo reboot

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

מתי שירות מנוהל מצדיק את העלות

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

• אף אחד בצוות לא מפעיל Linux, ואין תוכנית לגייס מישהו כזה.
• דרישת תאימות (compliance) מגדירה גורם אחראי לביצוע עדכוני אבטחה (patching), וגורם זה אינו יכול להיות אתם.
• ה-stack הוא כזה שהספק מתמחה בו, ולכן התמיכה שלהם כבר נתקלה בכשל שלכם בעבר.
• האדם שהיה מבצע את העבודה בדרך אחרת הוא העובד היקר ביותר שלכם, ושעה אחת מזמנו עולה יותר מחודש של שירות פרימיום.

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

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

FAQ

מה ההבדל בין VPS מנוהל לבין VPS לא מנוהל?

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

האם VPS מנוהל אומר שאיני זקוק לגיבויים משלי?

לא. גיבויי הספק נועדו בדרך כלל להגן על ה-image של השרת כולו במקרה של כשל בחומרה המארחת. הם כמעט לעולם לא עוזרים במקרה של מחיקת קובץ בטעות, הרצת הגירה (migration) כושלת, או השחתת נתונים שהתגלתה באיחור. בדקו לכמה זמן נשמרים ה-snapshots, האם ניתן לשחזר קובץ בודד, ומי מבצע את השחזור. שמרו עותק גיבוי חיצוני משלכם בעזרת כלי כמו restic, ובדקו אותו עם restic restore latest --target /tmp/restore-check כדי לוודא שהוא תקין.

האם VPS מנוהל מאובטח יותר מ-VPS לא מנוהל?

לא בהכרח. תוכנית מנוהלת מעדכנת גרסאות מהר יותר מאשר בעלים שאינו מתחבר לשרת לעולם, מה שמפחית סיכונים. עם זאת, תוכניות מנוהלות רבות מתקינות לוח בקרה (control panel), שהוא יישום מורכב החשוף לרשת, עם דף התחברות משלו והיסטוריית פגיעויות משלו. שרת לא מנוהל עם עדכוני אבטחה אוטומטיים, firewall סגור, גישת SSH מבוססת מפתח בלבד וללא שירותים מיותרים, מהווה מטרה קטנה יותר מאשר שרת מנוהל המריץ לוח בקרה.

האם ניתן להתחיל בניהול עצמי ולעבור לניהול על ידי הספק מאוחר יותר?

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

האם נשמרת לי גישת root ב-VPS מנוהל?

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