מסדים של מכונות, מחוברים בכבלים לספק שעומד בראש השורה. איור.
Interlaken Cloud רץ על תשתית שאנחנו מפעילים בעצמנו, ואנחנו מעדיפים לנקוב בשמה מאשר להסתיר אותה. מתחת לכל כפתור בקונסולה: מיקרו-VM של Firecracker, נתיב נתונים VPP במרחב המשתמש, אמצעי אחסון משוכפלים ב-LINSTOR מעל DRBD, k3s מנוהל, מסדי נתונים שמופעלים על ידי KubeBlocks ובאקטים של MinIO.
01מכונות וירטואליותוירטואליזציית חומרה מלאה, קרנל משלהעלייה מלאה של אורחכשרוצים שרת ארוך טווח שמצפה להיות מכונה אמיתיתVNC וקונסולה סריאליתדיסקים וכרטיסי רשת, תוך כדי ריצהשינוי גודל והפעלה מחדש
02מיקרו-VMבידוד VM של Firecracker, מודל התקנים מינימליבערך שנייהכשרוצים צפיפות והתנעה קרה שאפשר להמתין להקונסולה סריאליתדיסקים, תוך כדי ריצהשינוי גודל והפעלה מחדש
03קונטיינריםמרחבי שמות וקבוצות בקרה, קרנל מארח משותףמהר כמו שהתהליך עולהכשכבר יש אימג' והעומס חסר מצבטרמינל מחוברקבוע בזמן היצירהשינוי גודל והפעלה מחדש
04קבוצות סקיילינגמה שסוג החבר מספקהחברים עולים כמו שהםכשהקיבולת צריכה לעקוב אחרי הביקוש במקום אחרי ניחושלפי חברמוגדר בתבנית החברמונחה מדיניות, לפי מדד
כך נבדלות ארבע צורות המחשוב ב-Interlaken Cloud.
תכונה
מכונות וירטואליות
מיקרו-VM
קונטיינרים
קבוצות סקיילינג
בידוד
וירטואליזציית חומרה מלאה, קרנל משלה
בידוד VM של Firecracker, מודל התקנים מינימלי
מרחבי שמות וקבוצות בקרה, קרנל מארח משותף
מה שסוג החבר מספק
זמן התנעה
עלייה מלאה של אורח
בערך שנייה
מהר כמו שהתהליך עולה
החברים עולים כמו שהם
מתי לבחור
כשרוצים שרת ארוך טווח שמצפה להיות מכונה אמיתית
כשרוצים צפיפות והתנעה קרה שאפשר להמתין לה
כשכבר יש אימג' והעומס חסר מצב
כשהקיבולת צריכה לעקוב אחרי הביקוש במקום אחרי ניחוש
גישה לקונסולה
VNC וקונסולה סריאלית
קונסולה סריאלית
טרמינל מחובר
לפי חבר
חיבור וניתוק חמים
דיסקים וכרטיסי רשת, תוך כדי ריצה
דיסקים, תוך כדי ריצה
קבוע בזמן היצירה
מוגדר בתבנית החבר
סקיילינג
שינוי גודל והפעלה מחדש
שינוי גודל והפעלה מחדש
שינוי גודל והפעלה מחדש
מונחה מדיניות, לפי מדד
"בערך שנייה" הוא הנתון שלנו עבור מיקרו-VM של Firecracker שעולה מאימג' rootfs מוכן על המארחים שלנו. זו אינה השוואה מול אף אחד אחר, והאימג' שלכם קובע את רוב הזמן הזה.
כל חבילה ב-Interlaken Cloud מנותבת על ידי VPP שרץ במרחב המשתמש על המארח. הרשתות הפרטיות שלכם, מאזני העומסים, ה-NAT ותקרות רוחב הפס הם נתיב נתונים אחד, לא ערימה של קופסאות.
כך בקשה מגיעה לעומס עבודה
תעבורה נכנסת נוחתת על כתובת ציבורית שהוקצתה, פוגשת מאזן עומסים, ומגיעה לכרטיס הרשת של עומס העבודה בתוך ה-VPC שלכם. רשתות VPC מחוברות מגיעות לאותו כרטיס דרך שכבת-העל.
01
רשתות VPC ותת-רשתות
מרחב כתובות פרטי משלכם, מחולק לתת-רשתות עם נתיבים משלהן, ערכות אפשרויות DHCP ורשומות DNS.
02
שערים ויציאה
שער יחד עם מיפוי NAT 1:1 הם מה שנותן לעומס עבודה נתיב לאינטרנט. בלי שער אין יציאה — סגור הוא ברירת המחדל, לא תוספת.
03
כתובות ציבוריות
כתובות IP ציבוריות מוקצות מבריכה מנוהלת ונקשרות לכרטיס רשת או למאזן עומסים. אין דבר כזה כתובת לא מנוטרת.
04
IPv6
כתובות ותחיליות IPv6 ציבוריות מוקצות באותה דרך, מהבלוק של הפלטפורמה עצמה.
05
חיבור VPC
רשתות VPC מחוברות מגיעות זו לזו בין מארחים מעל שכבת-על Geneve, ונשארות בתוך מרחב כתובות פרטי כל הדרך.
06
מאזני עומסים
TCP שטוח בשכבה 4, סיום TLS, ניתוב שכבה 7 ב-HTTP/2 ו-HTTP/3 מעל QUIC — ארבעה מצבים, משאב אחד, שרתי גב עם בדיקות תקינות.
07
רוחב פס לכל כרטיס רשת
כרטיס רשת יכול לשאת תקרת תפוקה מצטברת, שנאכפת על ידי מווסת בנתיב הנתונים במקום מתוך אמון במשהו בתוך האורח.
אחסון הבלוקים הוא שכפול DRBD שמנוהל על ידי LINSTOR. אמצעי אחסון נכתב לכמה מארחים ככל שמספר העותקים שלו קובע, כך שאובדן מכונה עולה לכם עותק ולא את הנתונים.
01
אמצעי אחסון משוכפלים
קבעו את מספר העותקים לכל אמצעי אחסון. החיבור עוקב אחרי עומס העבודה, כך שעומס שנודד מוצא את הדיסק שלו איפה שהוא נוחת.
02
תצלומי מצב ושחזור
עותקים של דיסק בנקודת זמן, שניתן לשחזר לאמצעי אחסון חדש בלי להפריע למקור.
03
אימג'ים מוכנים
הכינו דיסק בדיוק כמו שאתם רוצים, פרסמו אותו כאימג' שאפשר לעלות ממנו, והעלו ממנו שוב ושוב.
04
הגדלה בזמן ריצה
הגדילו אמצעי אחסון בזמן שהוא מחובר; מערכת הקבצים שבתוכו מורחבת בהתאם.
05
אחסון אובייקטים
באקטים תואמי S3 על MinIO, עם מפתחות גישה שאפשר להגביל לבאקט אחד, ולצידם מנהל קבצים בקונסולה.
אמצעי אחסון אחד, נכתב סינכרונית לכל מארח בקבוצת העותקים שלו. מספר העותקים נתון לבחירתכם לכל אמצעי אחסון.
04 שירותים מנוהלים
החלקים עם המצב, מופעלים עבורכם
שניים מהדברים הקשים ביותר להפעלה טובה הם מישור בקרה של Kubernetes ומסד נתונים שחשוב. שניהם שירותים מנוהלים כאן, בנויים על אותו מחשוב, אותה רשת ואותו אחסון כמו כל השאר.
01
Kubernetes מנוהל
אשכולות k3s שהצמתים שלהם הם המכונות הווירטואליות שלכם. הפלטפורמה מקצה אותם, שומרת על תוספי האשכול מיושבים, ומחווטת פנימה את שאר Interlaken Cloud.
אמצעי אחסון קבועים מגיעים מאותו אחסון בלוקים משוכפל, דרך מנהל CSI
רשת האשכול ואיזון העומסים הם של הפלטפורמה, לא הברגה מבחוץ
מניפסטי התוספים מוחלים מחדש ברציפות, כך שאשכול לא סוטה
מחווט פנימה
CNI
CSI
איזון עומסים
kubeconfig
אין דמי אשכול — הצמתים מחויבים כמכונות וירטואליות, כי זה מה שהם.
החלקים שקובעים אם פלטפורמה מחזיקה מעמד כשאף אחד לא מסתכל עליה.
01
RBAC בכל קריאה
תפקידים והרשאות נבדקים בכל בקשת API, ולא פעם אחת בכניסה לקונסולה. הקונסולה, ה-CLI וה-API עוברים דרך אותה בדיקה.
02
מדיניות אבטחה בכרטיס הרשת
מדיניות מתקמפלת לרשימות בקרת גישה שנאכפות על כרטיס הרשת בנתיב הנתונים, כך שכלל מחזיק בין אם התעבורה הגיעה מהאינטרנט, מ-VPC אחר או משכן.
03
מפתחות ותעודות
זוגות מפתחות SSH לגישה למופעים, ותעודות X.509 לסיום TLS — מאומתים כזוג תואם כשאתם מעלים אותם, ולא כשבקשה נכשלת.
04
מכסות וקבלה
מגבלות לכל טננט נבדקות לפני שמשהו נוצר, כך שבקשה שחורגת ממכסה נדחית על הסף במקום להשאיר חצי משאב מאחור.
05
חיוב לפי מדידה
משאבים חיים נדגמים ברציפות לרשומות שימוש ומחויבים מדי חודש, מפורטים לפי משאב.
06
יישוב מתמיד
לכל משאב יש מצב רצוי ומצב נצפה, ומיישב עובד על סגירת הפער — ביצירה, אחרי אתחול מארח, אחרי הפעלה מחדש של נתיב הנתונים, ולפי לוח זמנים בין לבין. סטייה מוחלת מחדש במקום שתדווח.
06 גדלים
גדלים, מהמקור
סוגי המופעים והתעריפים השעתיים שלהם מגיעים מהקטלוג של הפלטפורמה בזמן ריצה. שום דבר בדף הזה לא מוקלד ביד.
סוג
vCPU
זיכרון
אחסון
לשעה
vm-xsmall
—
—
—
—
vm-small
—
—
—
—
vm-medium
—
—
—
—
vm-large
—
—
—
—
vm-xlarge
—
—
—
—
vm-2xlarge
—
—
—
—
vm-4xlarge
—
—
—
—
המחשוב מחויב לפי שעת מופע, לפי סוג. התעריפים בדף התמחור.