Mini ITX Cluster Turing Pi 2 עם 32 GB RAM

שלום לקהילת הבר! לאחרונה כתבתי על לוח האשכולות בגרסה הראשונה שלנו [V1]. והיום אני רוצה לספר לכם איך עבדנו על הגרסה Turing V2 עם 32 GB זיכרון זיכרון RAM.

אנחנו אוהבים מיני שרתים שיכולים לשמש גם לפיתוח מקומי וגם לאירוח מקומי. בניגוד למחשבים שולחניים או מחשבים ניידים, השרתים שלנו מתוכננים לעבוד 24/7, ניתן לאגד אותם במהירות, למשל, היו 4 מעבדים באשכול, ואחרי 5 דקות היו 16 מעבדים (ללא ציוד רשת נוסף) וכל זה במבנה קומפקטי שקט וחסכוני באנרגיה.

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

תחת החתך, איך עברנו מ-V1 ל-V2 ואיך היינו צריכים לצאת עם הפורמט החדש של Raspberry Pi CM4.

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

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

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

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

התחלנו בקביעת מספר הצמתים.

מספר צמתים

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

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

• פחות חומרים לכל לוח אשכול, ומכאן זול יותר לייצור
• כפולה של 4, סה"כ 4 בלוקים נותנים 16 מעבדים פיזיים
• מעגל יציב 1 מאסטר ו-3 עובדים
• וריאציות הטרוגניות יותר, מודולי מחשוב כללי + מחשוב מואץ
• מקדם מיני ITX עם כונני SSD וכרטיסי הרחבה

חישוב מודולים

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

Turing Pi Compute Module תומך Raspberry Pi CM4

באופן כללי, בחיפוש אחר מודולים, נפתח שוק שלם של מודולי מחשוב ממודולים קטנים עם 128 מגה-בייט RAM ועד 8 ג'יגה-בייט RAM. מודולים עם זיכרון RAM של 16 ג'יגה-בייט ועוד לפנינו. עבור אירוח יישומי קצה המבוסס על טכנולוגיות מקוריות בענן, 1 GB של זיכרון RAM כבר לא מספיק, וההופעה האחרונה של מודולים עבור 2, 4 ואפילו 8 GB של RAM מספקת מקום טוב לצמיחה. הם אפילו שקלו אפשרויות עם מודולי FPGA עבור יישומי למידת מכונה, אבל התמיכה שלהם התעכבה בגלל שהמערכת האקולוגית של התוכנה לא מפותחת. תוך כדי לימוד שוק המודולים, הגענו לרעיון ליצור ממשק אוניברסלי למודולים, וב-V2 אנחנו מתחילים לאחד את הממשק של מודולי מחשוב. זה יאפשר לבעלי גרסת V2 לחבר מודולים מיצרנים אחרים ולערבב אותם למשימות ספציפיות.

V2 תומך בכל קו Raspberry Pi 4 Compute Module (CM4), כולל גרסאות Lite ומודולי RAM של 8 GB

פֵּרִיפֶריָה

לאחר קביעת ספק המודולים ומספר הצמתים, ניגשנו לאפיק ה-PCI עליו נמצאים הציוד ההיקפי. אפיק ה-PCI הוא התקן עבור ציוד היקפי והוא נמצא כמעט בכל מודולי המחשוב. יש לנו מספר צמתים, ובאופן אידיאלי, כל צומת אמור להיות מסוגל לשתף התקני PCI במצב בקשה במקביל. לדוגמה, אם מדובר בדיסק המחובר לאוטובוס, הוא זמין לכל הצמתים. התחלנו לחפש מתגי PCI עם תמיכה בריבוי מארחים וגילינו שאף אחד מהם לא מתאים לדרישות שלנו. כל הפתרונות הללו הוגבלו ברובם למארח אחד או לרב מארחים, אך ללא מצב של בקשות במקביל לנקודות קצה. הבעיה השנייה היא העלות הגבוהה של $1 או יותר לשבב. ב-V50, החלטנו לדחות ניסויים עם מתגי PCI (נחזור אליהם בהמשך ככל שנתפתח) והלכנו בדרך של הקצאת תפקיד לכל צומת: שני הצמתים הראשונים חשפו יציאת מיני PCI Express לכל צומת, הצומת השלישי בקר SATA בעל 2 יציאות 2 Gbps חשוף. כדי לגשת לדיסקים מצמתים אחרים, אתה יכול להשתמש במערכת קבצי הרשת בתוך האשכול. למה לא?

הצצה

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

כתוצאה מכך, הגענו ליחידת אשכול עם 4 צמתים של 260 פינים, 2 יציאות מיני PCIe (Gen 2), 2 יציאות SATA (Gen 3). ללוח יש מתג מנוהל Layer-2 עם תמיכה ב-VLAN. מהצומת הראשון הוסרה יציאת מיני PCIe, אליה ניתן להתקין כרטיס רשת ולקבל יציאת Ethernet או מודם 5G נוספת וליצור נתב לרשת על האשכול ויציאות Ethernet מהצומת הראשון.

ל-Cluster Bus יש תכונות נוספות, כולל היכולת להבהב מודולים ישירות דרך כל החריצים וכמובן מחברי FAN בכל צומת עם בקרת מהירות.

בקשה

תשתית Edge עבור יישומים ושירותים שמתארחים בעצמם

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

תחנת עבודה של ARM

עם עד 32 GB RAM לכל אשכול, הצומת הראשון יכול לשמש עבור גרסת שולחן העבודה של מערכת ההפעלה (לדוגמה, Ubuntu Desktop 20.04 LTS) ו-3 הצמתים הנותרים למשימות קומפילציה, בדיקה וניפוי באגים, פיתוח פתרונות ענן מקוריים עבור ARM אשכולות. כצומת עבור CI / CD על תשתית ARM edge בפרוד.

אשכול Turing V2 עם מודולי CM4 כמעט זהה מבחינה ארכיטקטונית (הבדל בגרסאות משניות של ARMv8) לאשכול המבוסס על מופעי AWS Graviton. מעבד מודול CM4 משתמש בארכיטקטורת ARMv8 כך שתוכל לבנות תמונות ויישומים עבור מופעי AWS Graviton 1 ו-2, הידועים כהרבה יותר זולים ממופעי x86.

מקור: www.habr.com