בדף הזה מתוארים דפוסי ארכיטקטורה לעומסי עבודה של אוטומציה לתכנון אלקטרוני (EDA) ב-Google Cloud NetApp Volumes.
NetApp Volumes מספק אחסון משותף ב-NFS שניתן להרחבה כדי לתמוך בעומסי עבודה של EDA. עומסי העבודה האלה מעבדים מערכי נתונים בגודל פטה-בייט שכוללים מיליוני קבצים קטנים, מבצעים פעולות בספריות עם הרבה מטא-נתונים ומפעילים קלט/פלט מקבילי עם פרצי פעילות על פני אלפי ליבות מחשוב. NetApp Volumes מאפשר לשמור על הגישה לספריות עיצוב, לשרשראות כלים ולנתוני גירוד, על ידי שינוי הגודל של נפחי האחסון מפרויקטים קטנים לנפחי אחסון גדולים, עם FlexCache אופציונלי לעיצובים היברידיים ולעיצובים מסוג fan-out. התבניות הבאות ממפות מודלים נפוצים של פריסת EDA ליכולות האלה.
לדוגמאות של הטמעת הפניות ב-GitHub, כמו eda-all-on-cloud ו-eda-hybrid-cloud, אפשר לעיין בדוגמאות של EDA בערכת הכלים לאשכולות.
תבניות אדריכליות
בטבלה הבאה ריכזנו דוגמאות לתבניות נפוצות של עומסי עבודה ב-EDA. הדפוס הכי טוב לתרחיש השימוש שלכם תלוי במיקום הנתונים העיקריים ובאופן שבו אתם רוצים לשפר את ביצועי הקריאה והחישוב.
| דוגמת קוד | תרחיש שימוש | היכולות העיקריות של NetApp Volumes |
|---|---|---|
| כוננים בנפח גדול לאשכולות מחשוב | נתוני התכנון ושרשראות הכלים נמצאים ב- Google Cloud ונדרש מרחב שמות משותף יחיד בהיקף גדול | בריכות וכרכים גדולים, פריסה של כרכים מרובים ומחזור החיים של קבוצת פריסה |
| שימוש בענן לפרצי תנועה | מערכי הנתונים הראשיים נמצאים בתשתית מקומית או באזור אחר, ואתם צריכים מחשוב ענן כדי לעמוד בביקוש בשיא | FlexCache ממקור ONTAP מקומי, מילוי מראש ונפחים קיימים |
| שיפור הביצועים באמצעות מטמון מסוג fan-out | בשלבים שבהם יש הרבה קריאות, נדרשת תפוקה מצטברת או לוקאליות גבוהה יותר ממה שייצוא בודד יכול לספק | כמה נפחי אחסון של FlexCache או כמה נקודות סיום לאחסון לכל נפח אחסון גדול |
שימוש באמצעי אחסון בנפח גדול לאחסון קבצים באשכולות מחשוב
אפשר להשתמש בדפוס הזה כשמחשוב ונתונים קבועים פועלים ב- Google Cloud, למשל, חוות EDA חדשות, מרכזי עיצוב שהועברו או מחיצות ייעודיות של cloud burst שמכילות את מערכי הנתונים שלהן.
אתגרים שנפתרים באמצעות נפחים גדולים
נפחי אחסון גדולים מאפשרים לעמוד בדרישות הקיבולת, הביצועים והמקביליות הגבוהות של עומסי עבודה של EDA בקנה מידה גדול. ההגדרה הזו פותרת את הבעיות הבאות:
מגבלות קיבולת: מתאים למערכי עבודה גדולים, כמו ספריות, בלוקים של כתובות IP ונתוני גירוד של רגרסיה.
עומס גבוה של מטא-נתונים וקלט/פלט: מטפל בנתיבי מטא-נתונים אינטנסיביים (כולל פעולות
readdirו-stat), קלט/פלט אקראי קטן ורוחב פס רציף גבוה.
פריסה מומלצת
במקום להציב את כל הנתונים שלכם בכרך אחד גדול, כדאי לחלק את הנתונים לכמה כרכים על סמך מחזור החיים ודפוסי הגישה שלהם.
בטבלה הבאה מתואר הפריסה המומלצת לחלוקת הנתונים:
| תפקיד נפח | סוגי נתונים נפוצים | דפוסי גישה ומחזור חיים |
|---|---|---|
| כלים | קובצי הפעלה בינאריים של ספקים והתקנות EDA עם רישיון | קריאה בלבד ברובה, שמירה לטווח ארוך וייצוא יציב |
| ספריות | ערכות PDK, תאים רגילים ועיצובים לדוגמה | קריאה בעיקר, מספר גדול של קבצים ויתרונות משיפור המטמון של מאפיינים בלקוחות |
| בית | קבצי dot של משתמשים ומצב של פרויקטים קטנים | שיעורים מעורבים של קריאה/כתיבה וניהול מטא-נתונים |
| Scratch | הפעלת ספריות ותוצאות ביניים | שיעור נטישה גבוה, קיבולת גדולה וביקוש גבוה ל-IOPS |
התוכנית eda-all-on-cloud של Cluster Toolkit מספקת את הפריסה הזו עם מחיצות Compute Engine שמנוהלות על ידי Slurm ומבצעות mount של NetApp Volumes באמצעות NFS.
מתי כדאי להשתמש באמצעי אחסון בנפח גדול
אם נפח האחסון גדול מ-4.8TiB (Flex Unified) או מ-15TiB (Premium ו-Extreme), צריך ליצור נפחי אחסון גדולים. הנפחים האלה ניתנים להרחבה לקיבולת גדולה מאוד, ומספקים תפוקה גבוהה יותר ומגבלות גבוהות יותר של IOPS. התצורה הזו מתאימה לנפחי אחסון של Scratch ולספריות שחורגים מהמגבלות של נקודת קצה יחידה.
התפלגות הלקוחות בנפחים גדולים
נפח גדול של נתונים חושף כמה נקודות קצה של אחסון (כתובות IP) לאותו ייצוא. כדי להגדיל את קצב העברת הנתונים הכולל ולמנוע מצב שבו כתובת IP אחת הופכת לצוואר בקבוק, כדאי לפזר את לקוחות NFS על פני כמה נקודות קצה. אפשר לבחור באחת מהאפשרויות הבאות:
Round-robin DNS (מומלץ בהיקף גדול): יוצרים רשומת A ב-Cloud DNS שמפרטת כמה כתובות IP. מבצעים Mount באמצעות FQDN כדי שכל לקוח יבצע Resolve לכתובת אחת בזמן ה-Mount. אם משנים את רשומות ה-DNS, צריך להפעיל מחדש את הכונן.
Static sharding: חלוקת הלקוחות לכמה קבוצות והעלאת כל קבוצה לנקודת קצה שנבחרה לצורך מיקום עומס דטרמיניסטי.
בארכיטקטורה שכולה בענן, אתם מקצים ייצוא נפרד של NetApp Volumes באזור Google Cloud אחד לכלים, לספריות ולנתונים זמניים. בכלים ובספריות יש נתוני הפניה שרובם ניתנים לקריאה בלבד. ב-scratch יש ספריות הפעלה ונקודות ביקורת, ולרוב מדובר בנפח גדול. צמתים ב-Compute Engine שמנוהלים על ידי Slurm באותו VPC מבצעים mount לכל ייצוא באמצעות NFS. האחסון נפרס בbase קבוצת פריסה והמחשוב בcluster קבוצה, כדי לאפשר לכם לשנות את גודל האשכול או למחוק אותו בלי למחוק את אמצעי האחסון.
מעבר לענן
כדאי להשתמש בדפוס הזה כשנתוני עיצוב סמכותיים נשארים בפריסה מקומית או במערכת ONTAP מרוחקת, ואתם רוצים להפעיל משימות רגרסיה, אפיון או קיבולת שיא ב- Google Cloud compute בלי להעתיק קודם ספריות שלמות.
פתרון אתגרים באחסון בענן היברידי באמצעות FlexCache
כרכים של FlexCache פותרים אתגרים נפוצים באחסון בענן היברידי בסביבות EDA, ומספקים את היתרונות הבאים:
ביצועי גישה שדומים ל-LAN: חביון WAN ורוחב פס מגבילים את המהירות שבה ליבות של מחשוב ענן יכולות לקרוא מערכי נתונים מקומיים. כדי לפתור את הבעיה הזו, FlexCache משרת שלבים עם פעולות קריאה רבות ופעולות מטא-נתונים באופן מקומי אחרי שמטמון של קבוצות עבודה נוצר.
שמירת נתונים במטמון ברמת הבלוק לפי דרישה: העתקה של ספריות מלאות לענן לפני כל משימה גורמת לעיכובים בהפעלה ולכפילויות באחסון. FlexCache שומר במטמון רק את בלוקי הנתונים שהייתה אליהם גישה, וכך מקצר את זמני ההפעלה ומצמצם את נפח האחסון הנדרש בענן.
מקור נתונים מגובש: במקום לנהל עותקים מנותקים של הנתונים, אפשר להשתמש בייצוא NFS מקומי בענן ועדיין לשמור על עותק יחיד ועקבי בנפח המקור המקומי.
התנהגות ומאפיינים של FlexCache
יוצרים נפח FlexCache ב-NetApp Volumes שמצביע על נפח מקור קיים של ONTAP. קריאות של נתונים שנשמרו במטמון מוגשות על ידי Google Cloud. קריאות קרות מאחזרות בלוקים מנפח המקור של ONTAP פעם אחת ואז מציגות אותם באופן מקומי. כברירת מחדל, פעולות כתיבה משתמשות בכתיבה מסביב: המטמון מעביר פעולות כתיבה למקור ומבטל את התוקף של הנתונים המושפעים במטמון, וכך שומר על עקביות בין המטמונים.
המאפיינים העיקריים של FlexCache בסביבות EDA הם:
שמירת נתונים במטמון ברמת הבלוק, רק נתונים שנשלפים: רק נתונים שנשלפים תופסים נפח במטמון. כרכים דלילים יעילים לספריות גדולות שמתבצעת אליהן גישה חלקית בכל הפעלה.
קריאות עקביות ועדכניות: הנתונים שנקראים מהמטמון או מהמקור עקביים. הגישה הזו מתאימה לספריות הפניה משותפות כשדפוסי הכתיבה תואמים להנחיות של FlexCache.
זמן אחזור לקריאה שדומה ל-LAN אחרי חימום: שלבים של קריאה עם הרבה מטא-נתונים וקצב העברה גבוה, כמו מעבר בין ספריות וקבצים חוזרים של הפניות, מרוויחים אחרי שמטמון של קבוצות עבודה נוצר.
מילוי מראש: כדי להימנע מקנס על קריאה קרה בגישה הראשונה, צריך למלא מראש ספריות לרשימות הפעלה ידועות לפני שמתחילים עבודה.
תוכנית עבודה היברידית
eda-hybrid-cloud
מטמיע נפחים קיימים מראש, כמו כלים, ספריות, בית ו-scratch, באמצעות pre-existing-network-storage. הנפחים יכולים להיות NetApp Volumes, נפחים גדולים או נפחי FlexCache. הקצאת נפח אחסון מחוץ לתרשים האשכול מונעת מחיקה מקרית כשמבטלים את המחשוב, ותומכת במקורות FlexCache שמנוהלים ב-ONTAP.
כדאי להקפיד על ההנחיות הבאות:
הגודל של נפחי המטמון צריך להתאים לסט העבודה, ולא לקיבולת המלאה של נפח המקור.
כדי למנוע ביטול תוקף מיותר של מטמון, משביתים או מגבילים את העדכונים של זמן הגישה בנפח המקור (
-atime-updateב-ONTAP). מידע נוסף זמין במאמר סקירה כללית על FlexCache.מפעילים את נעילת הקבצים הגלובלית רק אם התהליך דורש סמנטיקה קפדנית של דחיית קריאה בין מטמונים. הגישה הזו מוסיפה זמן אחזור ומקשרת את הזמינות לקישור המקורי.
תכנון הקישוריות והרוחב הפס בין מקור התוכן לביןGoogle Cloud. כשמשתמשים בשיטת הכתיבה מסביב, שלבי הכתיבה האינטנסיבית נשארים קשורים למקור או לקישור לרשת.
בארכיטקטורה ההיברידית של קריאת פרצים, כלי הרשאות ונתוני ספרייה נמצאים במערכת ONTAP מקומית. NetApp Volumes מארח נפחי FlexCache ב- Google Cloud שמפנים למקורות האלה באמצעות WAN או קישור פרטי. צמתי Slurm ב Google Cloud מרכיבים את קובצי הייצוא של FlexCache. קריאות מוגשות מהמטמון כשהנתונים חמים. קריאות קרות מאחזרות בלוקים מהמקור המקומי. כדי לשמור על כתיבות מקומיות במקום לנתב תנועת כתיבה מתמשכת דרך FlexCache עם מקור מקומי, צריך ליצור נפח גירוד נפרד מבוסס-ענן באותו אזור כמו האשכול עבור גירוד ונקודות ביקורת שמקבלים תנועת כתיבה כבדה מ-Cloud Compute.
שיפור הביצועים באמצעות מטמון fan-out
משתמשים בתבנית הזו כשפעולת ייצוא אחת, גם אם היא בנפח גדול, לא מספקת מספיק תפוקת קריאה מצטברת או פיצול לקוחות לשלב מסוים בתהליך.
יש שתי דרכים להטמיע את התכונה fan-out:
נפחי אחסון של FlexCache עם פיצול
יוצרים כמה נפחי FlexCache שמגובים על ידי אותו נפח מקור, ומפעילים מאגרי מחשוב שונים (או סוגי משימות) במטמון שונה. כל מטמון מתחמם בנפרד, משנה את קנה המידה של קלט/פלט של קריאה בנקודות קצה נפרדות של NetApp Volumes, ומבודד את התנודות בין עומסי עבודה, למשל, עיבוד מקדים של ספריות לעומת רגרסיה ארוכה.
בטבלה הבאה מוצגת השוואה בין גישות לפריסת FlexCache יחיד ו-FlexCache מרובים.
| גישה | משקלים | השפעות |
|---|---|---|
| Single FlexCache | פשוט, נתיב הרכבה אחד | תפוקה ומגבלת קיבולת של מטמון אחד |
| FlexCache מרובים (fan-out) | קצב העברת נתונים מצטבר לקריאה במטמון; בידוד לכל מאגר | יותר נפחי אחסון לניהול; קבוצת העבודה מפוצלת בין מטמונים |
| מקור בלבד (ללא מטמון) | עקביות הכתיבה הכי חזקה לאתר יחיד | זמן האחזור של WAN למחשוב ענן |
אם אתם יודעים מראש מהם נתוני הקלט של העבודה, אתם יכולים להשתמש באכלוס מראש של כל מטמון fan-out.
Fan-out on large capacity volumes with multiple endpoints
נפחים גדולים ונפחי FlexCache בקנה מידה גדול חושפים כתובות IP מרובות לכל נפח. כל כתובת IP נחשבת לנקודת קצה של אחסון עם תקציב משבצות חיבור משלה.
אם יש לכם מאות או אלפי לקוחות NFS, כדאי לשקול את האפשרויות הבאות:
ערכים נמוכים יותר בטבלת משבצות ה-RPC לכל לקוח: לדוגמה, 8 משבצות לכל לקוח ב-NFSv3, כך שמספר הפעולות הכולל בהמתנה לכל נקודת קצה יישאר בגבולות המומלצים (כ-10,000 משבצות לכל נקודת קצה בחוות השרתים). מידע נוסף זמין במאמר בנושא בו זמניות של Linux NFS.
פיזור הנקודות לחיבור בין נקודות קצה: שימוש ב-Cloud DNS round-robin או ב-sharding סטטי.
כדי להטמיע FlexCache fan-out, משתמשים בכרך מקור אחד (ב-ONTAP מקומי או בכרך במצב ONTAP בענן) כדי לגבות כמה כרכים של FlexCache ב-NetApp Volumes. כדי לבודד את קבוצות העבודה ואת עומסי הקריאה בין הפעולות של ייצוא, צריך לטעון כל מטמון באמצעות צרכנים שונים, כמו מחיצה או סוג משימה של Slurm.
כדי להטמיע פיצול לנקודות קצה מרובות, משתמשים באמצעי אחסון גדול עם קיבולת גבוהה שחושף את אותו ייצוא NFS בכמה כתובות IP. כדי לפזר את הלקוחות בין נקודות הקצה האלה, אפשר להקצות קבוצות לקוחות קבועות לכל כתובת IP, או להוסיף שם DNS שמתבצעת התאמת נתונים (resolve) שלו לכתובת אחת לכל הוספה. לכל נקודת קצה יש תקציב חיבורים משלה. חלוקת הלקוחות עוזרת למנוע ריכוז של קלט/פלט ברמת החווה בכתובת IP אחת.
שילוב דפוסים
בסביבות EDA של ייצור, אפשר לשלב את דפוסי הארכיטקטורה האלה כדי לשפר את הביצועים:
הכול בענן: שימוש בכרכים גדולים של אחסון זמני ובכרכים קטנים יותר של אחסון רגיל לכלים ולבית.
היברידי: שימוש ב-FlexCache לספריות ולכלים, עם נפח אחסון זמני שמוקצה בענן לפלט של העבודות.
Fan-out: שימוש ב-FlexCache לכל אתר או לכל תור של מתזמן, בנוסף ל-DNS עם כמה נקודות קצה לנפח גדול של אחסון זמני בענן.
התאימו את רמת השירות של נפח האחסון ואת סוג המאגר (Flex Unified רגיל לעומת קיבולת גדולה) לקיבולת ולביצועים הנדרשים בכל רמה. מידע נוסף זמין במאמר בנושא רמות שירות.