עיצוב מרכזי נתונים וירטואליים

מבוא

מערכת מידע מנקודת מבטו של המשתמש מוגדרת היטב ב- GOST RV 51987 - "מערכת אוטומטית, שתוצאתה היא הצגת מידע פלט לשימוש מאוחר יותר." אם ניקח בחשבון את המבנה הפנימי, אז בעצם כל IS הוא מערכת של אלגוריתמים מחוברים המיושמים בקוד. במובן הרחב של התזה של Turing-Church, אלגוריתם (או IS) הופך קבוצה של נתוני קלט לקבוצה של נתוני פלט.
אפשר אפילו לומר שהטרנספורמציה של נתוני קלט היא המשמעות של קיומה של מערכת מידע. בהתאם לכך, ערך ה-IS ומכלול ה-IS נקבע באמצעות ערך נתוני הקלט והפלט.
על בסיס זה, התכנון חייב להתחיל ולהיות מונחה נתונים, תוך התאמת ארכיטקטורה ושיטות למבנה ומשמעות הנתונים.

נתונים מאוחסנים
שלב מרכזי בהכנה לתכנון הוא השגת המאפיינים של כל מערכי הנתונים המתוכננים לעיבוד ואחסון. מאפיינים אלה כוללים:
- נפח נתונים;
- מידע על מחזור החיים של נתונים (גידול של נתונים חדשים, תוחלת חיים, עיבוד נתונים מיושנים);
- סיווג נתונים מנקודת המבט השפעה על עסקי הליבה של החברה (שלישיית הסודיות, היושרה, הזמינות) יחד עם אינדיקטורים פיננסיים (לדוגמה, עלות אובדן הנתונים בשעה האחרונה);
- גיאוגרפיה של עיבוד נתונים (מיקום פיזי של מערכות עיבוד);
- דרישות רגולטוריות עבור כל מחלקת נתונים (לדוגמה, חוק פדרלי-152, PCI DSS).

מערכות מידע

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

מודל איום

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

דרישות רגולטוריות

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

יעדי RPO/RTO

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

חלוקה למאגרי משאבים

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

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

כוח עיבוד

תקציר, דרישות כוח העיבוד של מרכז נתונים וירטואלי נמדדות במונחים של מספר המעבדים הווירטואליים (vCPUs) ויחס האיחוד שלהם במעבדים פיזיים (pCPU). במקרה הספציפי הזה, מעבד אחד = ליבת מעבד פיזית אחת (למעט Hyper-Threading). מספר ה-vCPUs מסוכם על פני כל מאגרי המשאבים המוגדרים (שלכל אחד מהם יכול להיות גורם קונסולידציה משלו).
מקדם האיחוד למערכות עמוסות מתקבל באופן אמפירי, בהתבסס על תשתית קיימת, או באמצעות התקנת פיילוט ובדיקת עומסים. עבור מערכות לא טעונות, נעשה שימוש ב"שיטות עבודה מומלצות". באופן ספציפי, VMware מציינת את היחס הממוצע כ-8:1.

RAM

דרישת ה-RAM הכוללת מתקבלת על ידי סיכום פשוט. שימוש במנוי יתר של RAM אינו מומלץ.

משאבי אחסון

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

משאבי רשת נתונים

דרישות רשת הנתונים מתקבלות על ידי סיכום פשוט של כל מאגרי רוחב הפס.
יש לציין בנפרד דרישות איכות השירות (QoS) והשהייה (RTT) עבור מאגרים או מערכות ספציפיות.
כחלק מהדרישות למשאבי רשת נתונים, מצוינות גם דרישות לבידוד ו/או הצפנה של תעבורת רשת ומנגנונים מועדפים (802.1q, IPSec וכו').

בחירת אדריכלות

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

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

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

מעבד/זיכרון

כדי לחשב נכון את התצורה, עליך להבין את סוג העומס עבור הסביבה או כל אחד מהאשכולות העצמאיים.
קשור למעבד - סביבה מוגבלת בביצועים על ידי כוח מעבד. הוספת זיכרון RAM לא תשנה דבר מבחינת ביצועים (מספר ה-VMs לשרת).
זיכרון קשור - סביבה מוגבלת על ידי זיכרון RAM. יותר זיכרון RAM בשרת מאפשר לך להריץ יותר VMs בשרת.
GB / MHz (GB / pCPU) - היחס הממוצע בין צריכת זיכרון RAM וכוח מעבד לפי עומס מסוים זה. ניתן להשתמש כדי לחשב את כמות הזיכרון הנדרשת עבור ביצועים נתונים ולהיפך.

חישוב תצורת שרת

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

עבור כל אשכול, חלק את סכום הדרישות של מאגר vCPU במקדם:
vCPUsum / vCPU:pCPU = pCPUsum – המספר הנדרש של יחידות פיזיות. ליבות
pCPUsum / 1.25 = pCPUht - מספר הליבות מותאם עבור Hyper-Threading
נניח שיש צורך לחשב אשכול עם 190 ליבות / 3.5 TB של זיכרון RAM. במקביל, אנו מקבלים עומס יעד של 50% מעוצמת המעבד ו-75% מזיכרון RAM.

PCPU
190
שימוש במעבד
50%

ממ
3500
כלי שירות Mem
75%

שֶׁקַע
ליבה
Srv/CPU
Srv Mem
Srv/Mem

2
6
25,3
128
36,5

2
8
19,0
192
24,3

2
10
15,2
256
18,2

2
14
10,9
384
12,2

2
18
8,4
512
9,1

במקרה זה, אנו תמיד משתמשים בעיגול כלפי מעלה למספר השלם הקרוב ביותר (=ROUNDUP(A1;0)).
מהטבלה מתברר שמספר תצורות שרת מאוזנות עבור מחווני היעד:
— 26 שרתים 2*6c / 192 GB
— 19 שרתים 2*10c / 256 GB
— 10 שרתים 2*18c / 512 GB

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

תכונות של בחירת תצורת שרת

מכשירי VM רחבים. אם יש צורך לארח מכשירי VM רחבים (בהשוואה לצומת NUMA אחד או יותר), מומלץ, במידת האפשר, לבחור שרת עם תצורה המאפשרת ל-VMs כאלה להישאר בתוך הצומת NUMA. עם מספר רב של מחשבי VM רחבים, קיימת סכנה של פיצול משאבי אשכולות, ובמקרה זה נבחרים שרתים המאפשרים להציב מחשבי VM רחבים בצפיפות רבה ככל האפשר.

גודל תחום כשל יחיד.

הבחירה בגודל השרת מבוססת גם על העיקרון של מזעור תחום הכשל הבודד. לדוגמה, כאשר בוחרים בין:
- 3 x 4*10c / 512 GB
- 6 x 2*10c / 256 GB
כל שאר הדברים שווים, עליך לבחור באפשרות השנייה, שכן כאשר שרת אחד נכשל (או מתוחזק), לא 33% ממשאבי האשכול הולכים לאיבוד, אלא 17%. באותו אופן, מספר ה-VMs וה-ISs שהושפעו מהתאונה מצטמצם בחצי.

חישוב מערכות אחסון קלאסיות לפי ביצועים

מערכות אחסון קלאסיות מחושבות תמיד באמצעות התרחיש הגרוע ביותר, לא כולל השפעת המטמון התפעולי ואופטימיזציה של הפעולות.
כמחווני ביצועים בסיסיים, אנו לוקחים ביצועים מכניים מהדיסק (IOPSdisk):
– 7.2k – 75 IOPS
– 10k – 125 IOPS
– 15k – 175 IOPS

לאחר מכן, מספר הדיסקים במאגר הדיסקים מחושב באמצעות הנוסחה הבאה: = TotalIOPS * ( RW + (1 –RW) * RAIDPen) / IOPSdisk. איפה:
- TotalIOPS - סך הביצועים הנדרשים ב-IOPS ממאגר הדיסקים
- RW – אחוז פעולות הקריאה
- עט RAID – עונש RAID עבור רמת ה-RAID שנבחרה

קרא עוד על Device RAID ו-RAID Penalty כאן - ביצועי אחסון. חלק ראשון. и ביצועי אחסון. חלק שני. и ביצועי אחסון. חלק שלישי

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

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

חישוב מערכות היברידיות בטווח נמוך/בינוני

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

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

שימוש ב-SSD במאגר דיסקים מדורג

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

מקור: www.habr.com