השוו מודלי אחסון דרך האחריות התפעולית שהם מקצים והארכיטקטורה שהם מאפשרים. קנה מידה של ענן, מכונה וירטואלית וחומרה ייעודית מתארים היבטים שונים של מערכת; אף אחד מהם לבדו אינו מוכיח פרטיות, עלות או התנהגות שחזור.
התחילו מהעבודה שמישהו צריך לקחת עליה אחריות
החלטת אחסון מקצה עבודה תפעולית כמו גם משאבי מחשוב. פרויקט אחד זקוק לחשבון שמריץ אתר אינטרנט קונבנציונלי; אחר זקוק לשליטה בחבילות מערכת ההפעלה ובתהליכי רקע. שלישי זקוק לפלטפורמת מסד נתונים שתחזוקתה מטופלת במסגרת חוזה שירות מסוים. רשמו תחילה את האחריות הזו, יחד עם האנשים הזמינים לתחזק אותה.
אחסון משותף חושף בדרך כלל סביבה ברמת החשבון. VPS חושף מערכת הפעלה אורחת, בעוד חומרה ייעודית מעבירה את גבול המכונה לשרת פיזי. מנוהל הוא שאלה נפרדת: תווית מוצר אינה אומרת לכם מי מיישם עדכונים, משחזר נתונים או חוקר תקרית. בקשו את היקף הניהול ואת נוהל השחזור במקום להתייחס לכך כתכונה אוניברסלית.
הבינו מה הענן מוסיף להשוואה
NIST מתאר מחשוב ענן דרך מאפיינים כמו גישה לפי דרישה, איגום משאבים, גמישות ושירות מדוד. מכונה וירטואלית יכולה להיות רכיב אחד בפלטפורמת ענן, כך ש-VPS וענן אינם טכנולוגיות סותרות. ההשוואה המועילה היא בין השירותים המסוימים המוצעים: מכונה וירטואלית קבועה, צי גמיש או יישום הבנוי סביב שירותים מנוהלים.
Hyperscaler הוא מונח בתעשייה לספק המפעיל תשתית ופלטפורמות שירות בקנה מידה עצום. קנה מידה כזה יכול להציע מגוון רחב של כלי פריסה ואפשרויות גיאוגרפיות; הוא אינו אומר לכם אם ארכיטקטורה מסוימת עונה על הצרכים שלכם. העריכו את האזור, תלויות השירות, מודל הזהות והחוזה של כל רכיב. גם ספק קטן יותר וגם פלטפורמה גדולה דורשים חשבון ברור של לאן הולכים הנתונים.
| מודל תפעול | שליטה הזמינה לפרויקט | שאלה לפני בחירה |
|---|---|---|
| חשבון אחסון משותף | הגדרות האתר בהיקף החשבון | האם סביבת ההרצה מתאימה ליישום? |
| מכונה וירטואלית | מערכת הפעלה אורחת ושירותים מותקנים | מי מתחזק ומשחזר את האורח? |
| מכונה ייעודית | גבול שרת פיזי | האם עומס העבודה מצדיק את הגבול הזה? |
| שירות ענן מנוהל | ה-API של השירות וההגדרות הנתמכות | מה נשאר באחריות הלקוח? |
בחרו ארכיטקטורה שיכולה להשתחזר
מכונה אחת יכולה להיות נקודת התחלה הגיונית ליישום קטן כאשר דרישות השחזור שלו מאפשרות שחזור או חלון תחזוקה מתוכנן. הוספת צומת יישום שנייה משנה את התכנון רק אם ניתוב התעבורה, ההפעלות והנתונים המתמידים פועלים כראוי בשתיהן. שני שרתים שמריצים את אותה תוכנית שחזור חלקית הם עדיין תוכנית שחזור חלקית.
אחסון מבוזר ממחיש את ההבחנה הזו. תוכנה כמו Ceph מפזרת את עבודת האחסון על פני אשכול ומציעה ממשקי אובייקט, בלוק וקובץ. שכפול או קידוד מחיקה עשויים לסייע בעמידה בכשלי חומרה מסוימים, אך האשכול זקוק גם לקיבולת לשחזור ולאיזון מחדש. עותק חי מבוזר אינו מחליף גיבוי עצמאי. החליטו כיצד כתיבות מתנהגות במהלך פיצול רשת ובדקו את מקרי הכשל הרלוונטיים למימוש שבחרתם.
השוו את תקציב התפעול המלא
כתבו את התקציב כעומס עבודה: תעבורה רגילה, פרק זמן עמוס, נתונים מאוחסנים, שמירת גיבויים והעברה הנדרשת לשחזור. כללו תוכנה בתשלום, ממשקי API חיצוניים, זמן ניהול ועלות העברת הנתונים שוב. נתון חודשי התחלתי ואומדן מבוסס שימוש עונים על שאלות שונות. השוו אותם על פני אותה תקופה ושמרו את ההנחות לצד התוצאה.
עבור פלטפורמת ענן גדולה, זהו כל שירות הנדרש כדי לשמור על היישום פועל. עבור VPS, כללו את העבודה ששירותים מנוהלים היו סופגים אחרת. אף גישה אינה זולה יותר באופן אוטומטי. התחילו בפריסה מייצגת קטנה או בהצעת מחיר מתועדת, ואז בחנו את החשבון בפועל מול המודל. השאירו מקום לתעבורת שחזור ולקיבולת הגירה זמנית במקום לתקצב רק את מצב היציב.
התייחסו לפרטיות כמפת תלויות
האזור של המכונה הוא רשומה אחת במפה רחבה יותר. אימות, ניטור, כלי תמיכה, גיבויים וממשקי API של מודלים עשויים לפעול דרך שירותים נפרדים. תעדו מה כל אחד מקבל, מי יכול לגשת אליו וכמה זמן הוא נשמר. מודל האחריות המשותפת של AWS הוא דוגמה אחת לספק שמפריד במפורש בין חובות התשתית שלו לחובות הלקוח; ההיקף משתנה בהתאם לשירות.
השתמשו בהבחנה הזו בעת השוואת ספקים בלי לייבא את החובות של ספק אחד לחוזה של אחר. תצורת SwissOctet מתארת מיקום אחסון ומשאבים רשומים. היא אינה קובעת את מיקום האינטגרציות שתוסיפו מאוחר יותר. צמצמו את הנתונים שכל תלות מקבלת, אבטחו את הניהול ואמתו את יעדי הגיבוי לפני שאתם מצהירים על מסע הנתונים של היישום שלכם.
השתמשו במסלול ההגירה כחלק מההחלטה
בדקו כיצד תוכלו לייצא נתוני יישום, תצורה וזהויות. יישום קונבנציונלי על מכונה וירטואלית עשוי להיות פשוט להעברה, בעוד מסד נתונים או מערכת אירועים ייעודיים לשירות עשויים לדרוש התאמה. ניידות תלויה גם בידע תפעולי: גיבוי שאיש אינו יודע לשחזר הוא תוכנית יציאה חלשה גם אם הפורמט שלו פתוח.
לרשימה קצרה ראשונה של SwissOctet, השוו את Canvas כאשר סביבת ווב ברמת החשבון מתאימה, את Vector לשליטה במערכת ההפעלה האורחת ואת טווחי Metal כאשר הגבול הפיזי חשוב. אפשרויות מוכוונות אחסון תומכות בשאלת קיבולת אחרת ואין לתאר אותן כאשכול מבוזר מנוהל. שמרו על הארכיטקטורה קטנה מספיק לתפעול, והוסיפו מורכבות פלטפורמה כשהיא עונה על דרישה שנבדקה ולא על קנה מידה עתידי מדומיין.
רשימת הבדיקה המעשית שלך.
- הקצו בעלות על ניהול ושחזור.
- הבחינו בין VM לבין פלטפורמת הענן הרחבה יותר.
- תקצבו תלויות, העברה ותחזוקה.
- בדקו גבול כשל לפני הוספת צמתים.
- תעדו מסלול ייצוא נתונים והגירה מעשי.
הפרטים שחשובים.
האם VPS יכול להיות חלק מפלטפורמת ענן?+
כן. מכונה וירטואלית יכולה להיות שירות ענן. השוו את מודל המשאבים, הסקיילינג והניהול בפועל במקום להניח שהשמות מתארים טכנולוגיות בלעדיות.
האם אחסון מבוזר מחליף גיבויים?+
לא. יתירות חיה מטפלת בכשלי רכיבים נבחרים. גיבוי עצמאי ובדיקת שחזור מטפלים בכשלים אחרים כמו מחיקה ונתוני יישום פגומים.
האם ענן גדול הוא תמיד בחירה גרועה לפרטיות?+
לא. העריכו את השירותים המסוימים, זרימות הנתונים והבקרות החוזיות. גודל הספק לבדו אינו קובע את התאמת הארכיטקטורה.
לך למקור.
הפניות אלה תומכות במושגים הטכניים במדריך זה. עקוב אחר התיעוד העדכני לפני שינוי מערכת ייצור.
- NIST SP 800-145: ההגדרה של מחשוב ענן nvlpubs.nist.gov
- AWS: מודל אחריות משותפת aws.amazon.com
- Ceph: ארכיטקטורת אחסון docs.ceph.com
- Ceph: קידוד מחיקה docs.ceph.com
הדרכה עריכתית מאת SwissOctet. הדוגמאות להמחשה. יש לאמת בנפרד מפרטי שירות, אפשרויות זמינות ותנאים חוזיים.