פתרון היפר-קונברזציה AERODISK vAIR. הבסיס הוא מערכת הקבצים ARDFS

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

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

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

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

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

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

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

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

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

קונספט vAIR ראשון

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

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

לא התעסקנו יותר מדי בשם מערכת הקבצים וקראנו לה בתמציתיות ARDFS (נחשו מה זה מייצג))

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

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

צלילה לתוך מערכת הקבצים ARDFS

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

מבנה אחסון

בתוך כל הצמתים של האשכול, ARDFS מארגן מאגר לוגי מכל שטח הדיסק הזמין. חשוב להבין שמאגר הוא עדיין לא נתונים או שטח מעוצב, אלא פשוט סימון, כלומר. כל הצמתים שבהם מותקן vAIR, כאשר הם מתווספים לאשכול, מתווספים אוטומטית למאגר ה-ARDFS המשותף ומשאבי הדיסק משותפים באופן אוטומטי על פני האשכול כולו (וזמינים לאחסון נתונים עתידי). גישה זו מאפשרת לך להוסיף ולהסיר צמתים תוך כדי בלי שום השפעה רצינית על המערכת שכבר פועלת. הָהֵן. קל מאוד להתאים את המערכת "בלבנים", הוספה או הסרה של צמתים באשכול במידת הצורך.

דיסקים וירטואליים (אובייקטי אחסון למכונות וירטואליות) מתווספים על גבי מאגר ARDFS, הבנויים מגושים וירטואליים בגודל 4 מגה-בייט. דיסקים וירטואליים מאחסנים נתונים ישירות. ערכת סבילות התקלות מוגדרת גם ברמת הדיסק הווירטואלי.

כפי שאולי כבר ניחשתם, עבור סובלנות תקלות של תת-מערכת הדיסק, אנחנו לא משתמשים במושג RAID (מערך מיותר של דיסקים עצמאיים), אלא משתמשים ב-RAIN (מערך מיותר של צמתים עצמאיים). הָהֵן. סובלנות תקלות נמדדת, אוטומטית ומנוהלת על סמך הצמתים, לא הדיסקים. דיסקים, כמובן, הם גם אובייקט אחסון, הם, כמו כל דבר אחר, מנוטרים, אתה יכול לבצע איתם את כל הפעולות הסטנדרטיות, כולל הרכבת חומרה RAID מקומי, אבל האשכול פועל ספציפית על צמתים.

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

ערכות סובלנות לתקלות אחסון

יכולות להיות שתי ערכות סובלנות תקלות עבור דיסקים וירטואליים ב-vAIR:

1) מקדם שכפול או פשוט שכפול – שיטת סבילות תקלות זו פשוטה כמו מקל וחבל. שכפול סינכרוני מתבצע בין צמתים עם פקטור של 2 (2 עותקים לכל אשכול) או 3 (3 עותקים, בהתאמה). RF-2 מאפשר לדיסק וירטואלי לעמוד בכשל של צומת אחד באשכול, אך "אוכל" חצי מהנפח השימושי, ו-RF-3 יעמוד בכשל של 2 צמתים באשכול, אך שומר 2/3 מהנפח. נפח שימושי לצרכיו. סכימה זו דומה מאוד ל-RAID-1, כלומר, דיסק וירטואלי המוגדר ב-RF-2 עמיד בפני כשל של כל צומת אחד באשכול. במקרה הזה הכל יהיה בסדר עם הנתונים ואפילו ה-I/O לא יפסיק. כאשר הצומת שנפל יחזור לשירות, שחזור/סנכרון אוטומטי של נתונים יתחיל.

להלן דוגמאות להפצה של נתוני RF-2 ו-RF-3 במצב רגיל ובמצב של כשל.

יש לנו מכונה וירטואלית עם קיבולת של 8MB של נתונים ייחודיים (שימושיים), הפועלת על 4 צמתים vAIR. ברור שבמציאות לא סביר שיהיה נפח כל כך קטן, אבל עבור תוכנית שמשקפת את ההיגיון של פעולת ARDFS, הדוגמה הזו היא המובנת ביותר. AB הם בלוקים וירטואליים בנפח 4MB המכילים נתוני מחשב וירטואלי ייחודי. RF-2 יוצר שני עותקים של בלוקים אלה A1+A2 ו-B1+B2, בהתאמה. בלוקים אלה "מונחים" על פני צמתים, תוך הימנעות מהצלבה של אותם נתונים באותו צומת, כלומר, עותק A1 לא ימוקם באותו צומת כמו עותק A2. אותו דבר עם B1 ו-B2.

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

לפיכך, הדיסק הוירטואלי (וה-VM, בהתאם) יכולים לשרוד בקלות את הכישלון של צומת אחד בסכימת RF-2.

סכימת השכפול, אמנם פשוטה ואמינה, אך סובלת מאותה בעיה כמו RAID1 - אין מספיק מקום שמיש.

2) קידוד מחיקה או קידוד מחיקה (הידוע גם בשם "קידוד מיותר", "קידוד מחיקה" או "קוד יתירות") קיים כדי לפתור את הבעיה לעיל. EC היא סכמת יתירות המספקת זמינות נתונים גבוהה עם תקורה נמוכה יותר של שטח דיסק בהשוואה לשכפול. עקרון הפעולה של מנגנון זה דומה ל-RAID 5, 6, 6P.

בעת הקידוד, תהליך ה-EC מחלק בלוק וירטואלי (4MB כברירת מחדל) למספר "נתחי נתונים" קטנים יותר בהתאם לסכימת ה-EC (לדוגמה, סכימת 2+1 מחלקת כל בלוק של 4MB ל-2 נתחי 2MB). בשלב הבא, תהליך זה יוצר "נתחי זוגיות" עבור "נתחי הנתונים" שאינם גדולים מאחד החלקים שחולקו קודם לכן. בעת הפענוח, EC מייצר את הנתחים החסרים על ידי קריאת הנתונים "השורדים" על פני כל האשכול.

לדוגמה, דיסק וירטואלי עם ערכת EC 2+1, המיושמת על 4 צמתים של אשכול, יעמוד בקלות בכשל של צומת אחד באשכול באותו אופן כמו RF-2. במקרה זה, עלויות התקורה יהיו נמוכות יותר, בפרט, מקדם הקיבולת השימושי עבור RF-2 הוא 2, ועבור EC 2+1 הוא יהיה 1,5.

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

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

להלן דוגמה, עם אותה מכונה וירטואלית של 8 מגה-בייט ו-4 צמתים, אך עם סכימת EC 2+1.

בלוקים A ו-B מחולקים לשני חלקים של 2 מגה-בייט כל אחד (שניים כי 2+1), כלומר, A1+A2 ו-B1+B2. בניגוד לעתק, A1 אינו עותק של A2, זהו בלוק וירטואלי A, מחולק לשני חלקים, אותו דבר עם בלוק B. בסך הכל, נקבל שתי סטים של 4MB, שכל אחד מהם מכיל שני חלקים של שני מגה-בייט. לאחר מכן, עבור כל אחת מהקבוצות הללו, הזוגיות מחושבת בנפח של לא יותר מחתיכה אחת (כלומר 2 מגה-בייט), נקבל תוספת + 2 חתיכות של זוגיות (AP ו-BP). בסך הכל יש לנו נתונים של 4×2 + זוגיות של 2×2.

לאחר מכן, החלקים "מונחים" בין הצמתים כך שהנתונים לא יצטלבו עם הזוגיות שלהם. הָהֵן. A1 ו-A2 לא יהיו באותו צומת כמו AP.

במקרה של כשל של צומת אחד (לדוגמה, גם השלישי), הבלוק שנפל B1 ישוחזר אוטומטית משוויון ה-BP, המאוחסן בצומת מס' 2, ויופעל בצומת שבו יש. אין זוגיות B, כלומר. חתיכת BP. בדוגמה זו, זהו צומת מס' 1

אני בטוח שלקורא יש שאלה:

"כל מה שתיארת מיושם מזמן הן על ידי מתחרים והן בפתרונות קוד פתוח, מה ההבדל בין היישום שלך של EC ב-ARDFS?"

ואז יהיו תכונות מעניינות של ARDFS.

מחק קידוד עם התמקדות בגמישות

בתחילה, סיפקנו סכימת EC X+Y גמישה למדי, כאשר X שווה למספר מ-2 עד 8, ו-Y שווה למספר מ-1 עד 8, אך תמיד פחות או שווה ל-X. סכמה זו מסופקת. לגמישות. הגדלת מספר חלקי הנתונים (X) אליהם מחולק הבלוק הווירטואלי מאפשרת הפחתת עלויות התקורה, כלומר, הגדלת שטח שמיש.
הגדלת מספר נתחי הזוגיות (Y) מגבירה את האמינות של הדיסק הוירטואלי. ככל שערך ה-Y גדול יותר, כך יותר צמתים באשכול עלולים להיכשל. כמובן, הגדלת נפח הזוגיות מפחיתה את כמות הקיבולת השמישה, אבל זה מחיר שצריך לשלם עבור אמינות.

התלות של הביצועים במעגלי EC היא כמעט ישירה: ככל שיותר "חתיכות", כך הביצועים נמוכים יותר; כאן, כמובן, יש צורך במבט מאוזן.

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

להלן טבלה המשווה מספר (לא כולן אפשריות) תוכניות RF ו-EC.

הטבלה מראה שאפילו השילוב הכי "טרי" EC 8+7, המאפשר אובדן של עד 7 צמתים במקבץ בו זמנית, "אוכל" פחות שטח שמיש (1,875 לעומת 2) משכפול סטנדרטי, ומגן פי 7 טוב יותר , מה שהופך את מנגנון ההגנה הזה, אם כי מורכב יותר, לאטרקטיבי הרבה יותר במצבים בהם יש צורך להבטיח אמינות מירבית בתנאים של שטח דיסק מוגבל. יחד עם זאת, עליכם להבין שכל "פלוס" ל-X או Y יהיה תוספת ביצועים תקורה, כך שבמשולש שבין אמינות, חיסכון וביצועים עליכם לבחור בקפידה רבה. מסיבה זו, נקדיש מאמר נפרד למחיקת גודל קידוד.

אמינות ואוטונומיה של מערכת הקבצים

ARDFS פועל באופן מקומי בכל הצמתים של האשכול ומסנכרן אותם באמצעים משלו באמצעות ממשקי Ethernet ייעודיים. הנקודה החשובה היא ש-ARDFS מסנכרן באופן עצמאי לא רק את הנתונים, אלא גם את המטא נתונים הקשורים לאחסון. תוך כדי עבודה על ARDFS, למדנו במקביל מספר פתרונות קיימים וגילינו שרבים מסנכרנים את המטא של מערכת הקבצים באמצעות DBMS מבוזר חיצוני, שבו אנו משתמשים גם לסנכרון, אבל רק תצורות, לא מטא נתונים של FS (על זה ועל תת-מערכות קשורות אחרות במאמר הבא).

סנכרון מטא-נתונים של FS באמצעות DBMS חיצוני הוא, כמובן, פתרון עובד, אבל אז העקביות של הנתונים המאוחסנים ב-ARDFS תהיה תלויה ב-DBMS החיצוני ובהתנהגות שלו (ולמען האמת, מדובר בגברת קפריזית), אשר ב הדעה שלנו גרועה. למה? אם המטא-נתונים של ה-FS ייפגעו, ניתן לומר גם על נתוני ה-FS עצמם "להתראות", אז החלטנו ללכת בדרך מורכבת יותר אך אמינה.

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

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

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

מי צריך את הנס הזה?

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

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

מתי מערכת אחסון טובה יותר מ-GKS?

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

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

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

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

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

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

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

והיכן פתרונות היפר-קונברזציה יעבדו טוב יותר ממערכות אחסון?

בהתבסס על הנקודות לעיל, ניתן להסיק שלוש מסקנות ברורות:

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

מהם הפתרונות האלה?

1. כל שירותי התשתית הסטנדרטיים (שירות ספריות, דואר, EDMS, שרתי קבצים, מערכות ERP ו-BI קטנות או בינוניות וכו'). אנו קוראים לזה "מחשוב כללי".
2. התשתית של ספקי ענן, שבה יש צורך להרחיב במהירות ובסטנדרטיזציה אופקית ו"לחתוך" בקלות מספר רב של מכונות וירטואליות עבור לקוחות.
3. תשתית שולחנית וירטואלית (VDI), שבה הרבה מכונות וירטואליות למשתמשים קטנים פועלות ו"צפות" בשקט בתוך אשכול אחיד.
4. רשתות סניפים, שבהן כל סניף צריך תשתית סטנדרטית, סובלנית לתקלות, אך זולה של 15-20 מכונות וירטואליות.
5. כל מחשוב מבוזר (שירותי ביג דאטה, למשל). היכן שהעומס הולך לא "לעומק", אלא "ברוחב".
6. סביבות בדיקה שבהן עיכובים קטנים נוספים מקובלים, אך יש מגבלות תקציב, כי אלו בדיקות.

נכון לעכשיו, עבור המשימות הללו יצרנו את AERODISK vAIR ובהם אנו מתמקדים (בהצלחה עד כה). אולי זה ישתנה בקרוב, כי... העולם לא עומד מלכת.

אז ...

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

נשמח לשאלות, הצעות ומחלוקות בונות.

מקור: www.habr.com