אחסון משותף, VPS או שרת ייעודי: איך לבחור

על מה אתם בעצם מחליטים

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

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

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

אחסון משותף

הרבה אתרים רצים על שרת אחד, תחת מערכת הפעלה אחת ושרת web אחד, כל אחד בחשבון משלו עם לוח בקרה כמו cPanel,‏ Plesk או DirectAdmin. הספק מטפל בשרת; אתם מטפלים באתר.

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

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

‏VPS

שרת וירטואלי פרטי הוא מכונה וירטואלית על hypervisor, בדרך כלל KVM, שמנוהל לרוב דרך פלטפורמה כמו Proxmox VE (שמנהלת מכונות KVM וקונטיינרים של LXC) או מערכת של הספק עצמו. ב-VPS מבוסס KVM מקבלים kernel ומערכת הפעלה משלכם, הקצאה של vCPU, זיכרון ודיסק, וגישת root.

אפשר להריץ את מה שהאפליקציה צריכה: Nginx ו-PHP-FPM מכוונים, Redis,‏ queue workers,‏ Node.js,‏ Docker ומשימות מתוזמנות.
החומרה עדיין משותפת. תלוי בספק, המעבד עשוי להיות מוקצה ליותר לקוחות ממה שיש בו, ו-I/O הדיסק משותף עם מכונות אחרות על אותו מארח.
כדי לגדול, בדרך כלל מגדילים את המכונה, ולרוב זה דורש הפעלה מחדש קצרה.
בלי ניהול, כל מה שמעל ה-hypervisor באחריותכם: עדכונים, חומת אש, הקשחת SSH, גיבויים וניטור.

חלק מהחבילות הזולות הן בעצם קונטיינרים (LXC,‏ OpenVZ או Virtuozzo) שחולקים את ה-kernel של המארח, ולכן מודולים והגדרות של ה-kernel ותוכנות מסוימות לא זמינים. בדקו מה אתם קונים. ‏VPS מתאים לחנויות אונליין, אפליקציות web, מערכות CRM וקבוצות של אתרים עם עומס צפוי.

שרתים ייעודיים

מכונה פיזית שלמה שלכם. שום דבר אחר לא רץ עליה, ולכן המעבד, הזיכרון וקצב ה-NVMe צפויים. אתם בוחרים את מבנה הדיסקים, בדרך כלל דיסקים במראה עם ZFS או RAID תוכנתי של Linux‏ (mdadm); ‏ZFS צריך לראות את הדיסקים ישירות ולא לשבת מעל בקר RAID חומרתי. אפשר גם להריץ פלטפורמת וירטואליזציה משלכם, למשל Proxmox VE, כדי לחלק את המכונה לכמה מכונות וירטואליות וקונטיינרים.

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

מי אחראי על מה

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

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

מתי לשדרג

עברו מאחסון משותף ל-VPS כאשר:

אתם נתקלים במגבלות משאבים בתנועה רגילה, לא רק בשיאים.
האפליקציה צריכה תוכנה שהחבילה לא מאפשרת: Redis,‏ queue workers,‏ Node.js, גרסה או הרחבה מסוימת של PHP.
שאילתות למסד הנתונים מאטות כי שרת מסד הנתונים משותף.
אתם צריכים כתובת IP משלכם, יומנים משלכם או שליטה על מי שיש לו גישה.

עברו מ-VPS לחומרה ייעודית כשהמעבד נשאר גבוה לאורך זמן, כשה-steal time (עמודת st ב-top או ב-vmstat) נשאר גבוה כי שכנים על המארח לוקחים מעבד שהוקצה לכם, כשזמני ה-I/O wait מראים שאתם מתחרים על הדיסק, כשמסד הנתונים כבר לא נכנס בנוחות בזיכרון, או כשאתם רוצים להריץ כמה מכונות וירטואליות מבודדות על חומרה שבשליטתכם.

דגימה אחת בשנייה, חמש פעמים: שימו לב לעמודות st ו-wa

vmstat 1 5

גיבויים והתאוששות מאסון

מחוץ לשרת. שמרו גיבויים אצל ספק אחר או במיקום אחר. ‏snapshot על אותו מארח לא עוזר כשהמארח עצמו נופל.
‏RPO ו-RTO. החליטו כמה מידע אתם יכולים להרשות לעצמכם לאבד (נקודת השחזור) וכמה זמן המערכת יכולה להיות מושבתת (זמן השחזור). שני המספרים האלה קובעים את תדירות הגיבויים ואת הארכיטקטורה.
מסדי נתונים עקביים. השתמשו ב-dump תקין, או בשחזור לנקודת זמן מתוך binary logs‏ (MySQL,‏ MariaDB) או מארכיון WAL‏ (PostgreSQL). העתקה של הקבצים של מסד נתונים שרץ היא לא אמינה.
שמירת גרסאות. שמרו עותקים יומיים, שבועיים וחודשיים, כדי שתוכלו להתאושש מכופרה או משינוי גרוע שהתגלה באיחור.
בדיקות שחזור. שחזרו לשרת נפרד באופן קבוע. גיבוי שמעולם לא שוחזר הוא הנחה, לא גיבוי.
תוכנית לתקלת חומרה. בשרתים ייעודיים, כתבו מה קורה כשדיסק או לוח אם מתקלקלים, וכמה זמן לוקחת הבנייה מחדש.

מנוהל או לא מנוהל

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

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

כלל אצבע קצר

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

איפה אנחנו נכנסים

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

דברו עם מהנדס