אדמין ללא ידיים = היפר התכנסות?

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

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

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

וזה פתאום התברר כפתרון טוב מאוד לגיבוי מרכזי נתונים (Disaster Recovery). אני אגיד לך למה ואיך עכשיו. ואני אראה לך את מבחני האשכול.

היכן שצריך

היפרקונברגנציה היא:

1. העברת דיסקים לצמתי מחשוב.
2. אינטגרציה מלאה של תת-מערכת האחסון עם תת-מערכת הוירטואליזציה.
3. העברה/אינטגרציה עם תת-מערכת הרשת.

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

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

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

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

בדיקות

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

שינויים ב-v4חבורה של באגים תוקנו.

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

כעת כל בעיות הילדות תוקנו, HyperFlex יכול להתמודד גם עם ESXi וגם Hyper-V, בנוסף זה אפשרי:

1. יצירת אשכול מתוח.
2. יצירת אשכול למשרדים ללא שימוש ב- Fabric Interconnect, משניים עד ארבעה צמתים (אנו קונים רק שרתים).
3. יכולת עבודה עם מערכות אחסון חיצוניות.
4. תמיכה בקונטיינרים ו-Kubernetes.
5. יצירת אזורי זמינות.
6. אינטגרציה עם VMware SRM אם הפונקציונליות המובנית אינה משביעת רצון.

הארכיטקטורה אינה שונה בהרבה מהפתרונות של המתחרים העיקריים שלה; הם לא יצרו אופניים. הכל פועל על פלטפורמת הווירטואליזציה של VMware או Hyper-V. החומרה מתארחת בשרתי Cisco UCS קנייניים. יש כאלה ששונאים את הפלטפורמה בגלל המורכבות היחסית של ההגדרה הראשונית, הרבה כפתורים, מערכת לא טריוויאלית של תבניות ותלות, אבל יש גם כאלה שלמדו זן, שואבים השראה מהרעיון ולא רוצים יותר. לעבוד עם שרתים אחרים.

נשקול את הפתרון עבור VMware, מכיוון שהפתרון נוצר עבורו במקור ויש לו יותר פונקציונליות; Hyper-V התווסף לאורך הדרך על מנת לעמוד בקצב של המתחרים ולעמוד בציפיות השוק.

יש אשכול שרתים מלא בדיסקים. ישנם דיסקים לאחסון נתונים (SSD או HDD - לפי טעמכם וצרכיכם), יש דיסק SSD אחד לאחסון במטמון. בעת כתיבת נתונים למאגר הנתונים, הנתונים נשמרים בשכבת המטמון (דיסק SSD ייעודי ו-RAM של השירות VM). במקביל, בלוק נתונים נשלח לצמתים באשכול (מספר הצמתים תלוי בגורם שכפול האשכולות). לאחר אישור מכל הצמתים על הקלטה מוצלחת, אישור ההקלטה נשלח ל-hypervisor ולאחר מכן ל-VM. הנתונים המוקלטים משוכפלים, נדחסים ונכתבים לדיסקי אחסון ברקע. במקביל, תמיד נכתב בלוק גדול לדיסקי האחסון וברצף, מה שמפחית את העומס על דיסקי האחסון.

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

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

בקר שירות מיוחד VM Cisco HyperFlex Data Platform, שנוצר בכל צומת אחסון, אחראי על כל לוגיקה הפעולה של תת-מערכת הדיסק. בתצורת השירות VM שלנו, הוקצו שמונה מעבדי vCPU ו-72 GB של זיכרון RAM, וזה לא כל כך מעט. הרשו לי להזכיר לכם שלמארח עצמו יש 28 ליבות פיזיות ו-512 GB של זיכרון RAM.

ל-VM של השירות יש גישה לדיסקים פיזיים ישירות על ידי העברת בקר SAS ל-VM. התקשורת עם ה-Hypervisor מתרחשת באמצעות מודול מיוחד IOVisor, המיירט פעולות I/O, ושימוש בסוכן המאפשר לשלוח פקודות ל-Hypervisor API. הסוכן אחראי לעבודה עם צילומי מצב ושיבוטים של HyperFlex.

משאבי הדיסק מותקנים ב-Hypervisor כשיתופי NFS או SMB (בהתאם לסוג ה-Hypervisor, נחשו איזה מהם נמצא היכן). ומתחת למכסה המנוע, מדובר במערכת קבצים מבוזרת המאפשרת להוסיף תכונות של מערכות אחסון מלאות למבוגרים: הקצאת נפח דק, דחיסה ומניעת כפילויות, צילומי מצב בטכנולוגיית Redirect-on-Write, שכפול סינכרוני/אסינכרוני.

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

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

שימוש בצמתי מחשוב מגביר את הגמישות בעת שינוי קנה המידה של משאבי אשכולות: אנחנו לא צריכים לקנות צמתים נוספים עם דיסקים אם אנחנו צריכים רק CPU/RAM. בנוסף, נוכל להוסיף כלוב להב ולחסוך במיקום מתלה של שרתים.

כתוצאה מכך, יש לנו פלטפורמת היפר-קונברזציה עם התכונות הבאות:

• עד 64 צמתים באשכול (עד 32 צמתים אחסון).
• המספר המינימלי של צמתים באשכול הוא שלושה (שניים עבור אשכול Edge).
• מנגנון יתירות נתונים: שיקוף עם פקטור שכפול 2 ו-3.
• אשכול מטרו.
• שכפול VM אסינכרוני לאשכול HyperFlex אחר.
• תזמור של העברת מחשבי VM למרכז נתונים מרוחק.
• צילומי מצב מקוריים באמצעות טכנולוגיית Redirect-on-Write.
• עד 1 PB של שטח שמיש במקדם שכפול 3 וללא מניעת כפילויות. אנחנו לא לוקחים בחשבון את פקטור שכפול 2, כי זו לא אופציה למכירות רציניות.

יתרון ענק נוסף הוא קלות הניהול והפריסה. כל המורכבות של הקמת שרתי UCS מטופלת על ידי VM מיוחד שהוכן על ידי מהנדסי סיסקו.

תצורת ספסל בדיקה:

• 2 x Cisco UCS Fabric Interconnect 6248UP כאשכול ניהול ורכיבי רשת (48 יציאות הפועלות במצב Ethernet 10G/FC 16G).
• ארבעה שרתי Cisco UCS HXAF240 M4.

מאפייני שרת:

CPU

2 x Intel® Xeon® E5-2690 v4

RAM

16 x 32GB DDR4-2400-MHz RDIMM/PC4-19200/דרוג כפול/x4/1.2v

רשת

UCSC-MLOM-CSC-02 (VIC 1227). 2 יציאות Ethernet 10G

אחסון HBA

Cisco 12G Modular SAS Pass through Controller

דיסקי אחסון

1 x SSD Intel S3520 120 GB, 1 x SSD Samsung MZ-IES800D, 10 x SSD Samsung PM863a 960 GB

אפשרויות תצורה נוספותבנוסף לחומרה שנבחרה, האפשרויות הבאות זמינות כעת:

• HXAF240c M5.
• מעבד אחד או שניים החל מ-Intel Silver 4110 ועד Intel Platinum I8260Y. דור שני זמין.
• 24 חריצי זיכרון, רצועות מ-16 GB RDIMM 2600 עד 128 GB LRDIMM 2933.
• מ-6 עד 23 דיסקי נתונים, דיסק מטמון אחד, דיסק מערכת אחד ודיסק אתחול אחד.

כונני קיבולת

• HX-SD960G61X-EV 960GB 2.5 אינץ' Enterprise Value 6G SATA SSD (1X סיבולת) SAS 960 GB.
• HX-SD38T61X-EV 3.8TB 2.5 אינץ' Enterprise Value 6G SATA SSD (1X סיבולת) SAS 3.8TB.
• אחסון כוננים במטמון
• HX-NVMEXPB-I375 375GB 2.5 אינץ' Intel Optane Drive, Extreme Perf & Endurance.
• HX-NVMEHW-H1600* 1.6TB 2.5 אינץ' Ent. Perf. NVMe SSD (3X סיבולת) NVMe 1.6 TB.
• HX-SD400G12TX-EP 400GB 2.5 אינץ' Ent. Perf. 12G SAS SSD (10X סיבולת) SAS 400 GB.
• HX-SD800GBENK9** 800GB 2.5 אינץ' Ent. Perf. 12G SAS SED SSD (10X סיבולת) SAS 800 GB.
• HX-SD16T123X-EP 1.6TB 2.5 אינץ' ביצועים ארגוניים 12G SAS SSD (3X סיבולת).

כונני מערכת/יומן

• HX-SD240GM1X-EV 240GB 2.5 אינץ' Enterprise Value 6G SATA SSD (דורש שדרוג).

אתחול כונני

• HX-M2-240GB 240GB SATA M.2 SSD SATA 240GB.

התחבר לרשת באמצעות יציאות 40G, 25G או 10G Ethernet.

ה-FI יכול להיות HX-FI-6332 (40G), HX-FI-6332-16UP (40G), HX-FI-6454 (40G/100G).

הבדיקה עצמה

כדי לבדוק את תת-מערכת הדיסק, השתמשתי ב-HCIBench 2.2.1. זהו כלי חינמי המאפשר לך להפוך את היצירה של עומס ממספר מכונות וירטואליות לאוטומטיות. העומס עצמו נוצר על ידי ה-fio הרגיל.

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

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

תוצאות הבדיקה הן כדלקמן:

100% קריאה 100% אקראית

0% קריאה 100% אקראית

עומק חסימה/תור

128

256

512

1024

2048

128

256

512

1024

2048

4K

0,59 אלפיות השנייה 213804 IOPS

0,84 אלפיות השנייה 303540 IOPS

1,36ms 374348 IOPS

2.47 אלפיות השנייה 414116 IOPS

4,86ms 420180 IOPS

2,22 אלפיות השנייה 57408 IOPS

3,09 אלפיות השנייה 82744 IOPS

5,02 ms 101824 IPOS

8,75 אלפיות השנייה 116912 IOPS

17,2 אלפיות השנייה 118592 IOPS

8K

0,67 אלפיות השנייה 188416 IOPS

0,93 אלפיות השנייה 273280 IOPS

1,7 אלפיות השנייה 299932 IOPS

2,72 אלפיות השנייה 376,484 IOPS

5,47 אלפיות השנייה 373,176 IOPS

3,1 אלפיות השנייה 41148 IOPS

4,7 אלפיות השנייה 54396 IOPS

7,09 אלפיות השנייה 72192 IOPS

12,77 אלפיות השנייה 80132 IOPS

16K

0,77 אלפיות השנייה 164116 IOPS

1,12 אלפיות השנייה 228328 IOPS

1,9 אלפיות השנייה 268140 IOPS

3,96 אלפיות השנייה 258480 IOPS

3,8 אלפיות השנייה 33640 IOPS

6,97 אלפיות השנייה 36696 IOPS

11,35 אלפיות השנייה 45060 IOPS

32K

1,07 אלפיות השנייה 119292 IOPS

1,79 אלפיות השנייה 142888 IOPS

3,56 אלפיות השנייה 143760 IOPS

7,17 אלפיות השנייה 17810 IOPS

11,96 אלפיות השנייה 21396 IOPS

64K

1,84 אלפיות השנייה 69440 IOPS

3,6 אלפיות השנייה 71008 IOPS

7,26 אלפיות השנייה 70404 IOPS

11,37 אלפיות השנייה 11248 IOPS

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

• קריאה רציפה 4432 MB/s.
• כתיבה רציפה 804 מגה-בייט/שנייה.
• אם בקר אחד נכשל (כשל של מכונה וירטואלית או מארח), הירידה בביצועים היא כפולה.
• אם דיסק האחסון נכשל, ההפחתה היא 1/3. בנייה מחדש של דיסק לוקחת 5% מהמשאבים של כל בקר.

בבלוק קטן, אנו מוגבלים על ידי הביצועים של הבקר (מכונה וירטואלית), המעבד שלו נטען ב-100%, וכאשר הבלוק גדל, אנו מוגבלים על ידי רוחב הפס של הפורט. 10 Gbps לא מספיק כדי לפתוח את הפוטנציאל של מערכת AllFlash. למרבה הצער, הפרמטרים של עמדת ההדגמה המסופקת אינם מאפשרים לנו לבדוק את הפעולה במהירות 40 Gbit/s.

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

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

שימוש אמיתי

כדי לארגן מרכז נתונים לגיבוי, אתה יכול להשתמש בשתי גישות (איננו שוקלים למקם גיבוי באתר מרוחק):

1. פעיל סביל. כל האפליקציות מתארחות במרכז הנתונים הראשי. השכפול הוא סינכרוני או אסינכרוני. אם מרכז הנתונים הראשי נכשל, עלינו להפעיל את הגיבוי. ניתן לעשות זאת באופן ידני / יישומי סקריפטים / תזמור. כאן נקבל RPO התואם את תדירות השכפול, וה-RTO תלוי בתגובה ובכישורי המנהל ובאיכות הפיתוח/ניפוי באגים של תוכנית המיתוג.
2. פעיל- פעיל. במקרה זה, יש רק שכפול סינכרוני; זמינות מרכזי הנתונים נקבעת על ידי מניין/בורר שנמצא אך ורק באתר השלישי. RPO = 0, ו-RTO יכול להגיע ל-0 (אם האפליקציה מאפשרת) או שווה לזמן הכשל של צומת באשכול וירטואליזציה. ברמת הווירטואליזציה, נוצר אשכול מתוח (מטרו) הדורש אחסון אקטיבי.

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

תרחיש 1: יש לנו מרכזי נתונים ראשיים וגיבוי, פלטפורמת וירטואליזציה ב-VMware vSphere. כל המערכות הפרודוקטיביות ממוקמות במרכז הנתונים הראשי, ושכפול של מכונות וירטואליות מתבצע ברמת ה-Hypervisor, זה ימנע השארת מחשבי VM מופעלים במרכז הנתונים הגיבוי. אנו משכפלים מסדי נתונים ויישומים מיוחדים באמצעות כלים מובנים ושומרים על ה-VMs מופעלים. אם מרכז הנתונים הראשי נכשל, אנו משיקים מערכות במרכז הנתונים לגיבוי. אנו מאמינים שיש לנו כ-100 מכונות וירטואליות. בעוד שמרכז הנתונים הראשי פועל, מרכז הנתונים בהמתנה יכול להריץ סביבות בדיקה ומערכות אחרות שניתן לכבות אותן אם מרכז הנתונים הראשי יעבור. ייתכן גם שאנו משתמשים בשכפול דו-כיווני. מנקודת מבט של חומרה, שום דבר לא ישתנה.

במקרה של ארכיטקטורה קלאסית, נתקין בכל מרכז נתונים מערכת אחסון היברידית עם גישה דרך FibreChannel, שכבות, מניעת כפילויות ודחיסה (אך לא מקוונת), 8 שרתים לכל אתר, 2 מתגי FibreChannel ו-10G Ethernet. לשכפול וניהול מיתוג בארכיטקטורה קלאסית נוכל להשתמש בכלי VMware (Replication + SRM) או בכלים של צד שלישי, שיהיו קצת יותר זולים ולעיתים נוחים יותר.

האיור מציג את התרשים.

בעת שימוש ב-Cisco HyperFlex, מתקבלת הארכיטקטורה הבאה:

עבור HyperFlex, השתמשתי בשרתים עם משאבי CPU/RAM גדולים, כי... חלק מהמשאבים יעברו ל-HyperFlex Controller VM; מבחינת CPU וזיכרון, אפילו הגדרתי מחדש מעט את תצורת HyperFlex כדי לא לשחק יחד עם Cisco ולהבטיח משאבים עבור ה-VMs שנותרו. אבל אנחנו יכולים לנטוש את מתגי FibreChannel, ולא נצטרך יציאות Ethernet עבור כל שרת; התעבורה המקומית עוברת בתוך FI.

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

שרתים

שרת 8 x 1U (384 GB RAM, 2 x Intel Gold 6132, FC HBA)

8 x HX240C-M5L (512 GB RAM, 2 x Intel Gold 6150, 3,2 GB SSD, 10 x 6 TB NL-SAS)

SHD

מערכת אחסון היברידית עם FC Front-End (20TB SSD, 130TB NL-SAS)

-

LAN

2 x מתג Ethernet 10G 12 יציאות

-

SAN

2 x מתג FC 32/16Gb 24 יציאות

2 x Cisco UCS FI 6332

רישיונות

VMware Ent Plus

שכפול ו/או תזמור של מיתוג VM

VMware Ent Plus

לא סיפקתי רישיונות תוכנת שכפול עבור Hyperflex, מכיוון שזה זמין עבורנו מהקופסה.

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

הפתרון של Cisco HyperFlex התברר כ-13% יותר זול.

תרחיש 2: יצירת שני מרכזי נתונים פעילים. בתרחיש זה, אנו מתכננים אשכול מתוח ב-VMware.

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

ב-HyperFlex אנחנו פשוט יוצרים Stretch Cluster עם אותו מספר צמתים בשני האתרים. במקרה זה, נעשה שימוש במקדם שכפול של 2+2.

התוצאה היא התצורה הבאה:

אדריכלות קלאסית

HyperFlex

שרתים

שרת 16 x 1U (384 GB RAM, 2 x Intel Gold 6132, FC HBA, 2 x 10G NIC)

16 x HX240C-M5L (512 GB RAM, 2 x Intel Gold 6132, 1,6 TB NVMe, 12 x 3,8 TB SSD, VIC 1387)

SHD

2 x מערכות אחסון AllFlash (150 TB SSD)

-

LAN

4 x מתג Ethernet 10G 24 יציאות

-

SAN

4 x מתג FC 32/16Gb 24 יציאות

4 x Cisco UCS FI 6332

רישיונות

VMware Ent Plus

VMware Ent Plus

בכל החישובים לא לקחתי בחשבון את תשתית הרשת, עלויות הדאטה סנטר וכו': הן יהיו זהות לארכיטקטורה הקלאסית ולפתרון HyperFlex.

מבחינת עלות, HyperFlex התברר כיקר ב-5%. כדאי לציין כאן שמבחינת משאבי CPU/RAM הייתה לי הטיה לסיסקו, כי בתצורה מילאתי ​​את ערוצי בקר הזיכרון באופן שווה. העלות מעט גבוהה יותר, אבל לא בסדר גודל, מה שמצביע בבירור על כך שהתכנסות יתר היא לא בהכרח "צעצוע לעשירים", אלא יכולה להתחרות בגישה הסטנדרטית לבניית מרכז נתונים. זה עשוי לעניין גם את מי שכבר יש לו שרתי Cisco UCS ואת התשתית המתאימה להם.

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

לגבי תמיכה, כאן אתה מקבל אותה מספק אחד - סיסקו. אם לשפוט לפי הניסיון שלי עם שרתי Cisco UCS, אני אוהב את זה; לא הייתי צריך לפתוח אותו ב-HyperFlex, הכל עבד בדיוק אותו הדבר. מהנדסים מגיבים מיידית ויכולים לפתור לא רק בעיות טיפוסיות, אלא גם מקרי קצה מורכבים. לפעמים אני פונה אליהם בשאלות: "האם אפשר לעשות את זה, לדפוק את זה?" או "הגדרתי משהו כאן, והוא לא רוצה לעבוד. עֶזרָה!" - הם ימצאו שם בסבלנות את המדריך הדרוש ויצביעו על הפעולות הנכונות; הם לא יענו: "אנחנו פותרים רק בעיות חומרה."

תזכור

• מפרט
• מרכז נתונים וירטואלי
• מרכז נתונים במגירה שולחנית
• הדואר שלי - [מוגן בדוא"ל]

מקור: www.habr.com