איך בונים חוות עיבוד היברידית

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

סקירה כללית

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

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

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

• פריסת משימות למשאבים מקומיים ולמשאבים מבוססי-ענן.
• ניהול יחסי תלות בין משימות.
• תקשורת עם מערכות לניהול נכסים.
• מספקות למשתמשים ממשק משתמש וממשקי API לשפות נפוצות כמו Python.

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

אלה האפשרויות הזמינות ליצירה ולניהול של צינורות עיבוד ותהליכי עבודה בסביבת ענן או בסביבת ענן היברידי:

• אם אין לכם כבר משאבים מקומיים או משאבי ענן, אתם יכולים להשתמש בשירות עיבוד מבוסס-ענן של תוכנה כשירות (SaaS), כמו Conductor.
• אם אתם רוצים לנהל את התשתית שלכם בעצמכם, אתם יכולים ליצור ולפרוס את משאבי הענן שמתוארים במסמך הזה.
• אם אתם רוצים ליצור תהליך עבודה מותאם אישית לפי הדרישות הספציפיות שלכם, אתם יכולים לעבוד עם שותפים לשילוב שירותים כמו Gunpowder או Qodea. Google Cloud היתרון של האפשרות הזו הוא שכל שירותי הענן פועלים בסביבה מאובטחת משלכם. Google Cloud

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

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

מתבצע חיבור לענן

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

התחברות דרך האינטרנט

בלי קישוריות מיוחדת, אתם יכולים להתחבר לרשת של Google ולהשתמש במודל האבטחה מקצה לקצה שלנו על ידי גישה לשירותי Google Cloud דרך האינטרנט. כלי עזר כמו Google Cloud CLI ומשאבים כמו Compute Engine API משתמשים באימות, בהרשאה ובהצפנה מאובטחים כדי לעזור לכם להגן על הנתונים.

Cloud VPN

לא משנה איך אתם מחוברים, מומלץ להשתמש ברשת וירטואלית פרטית (VPN) כדי לאבטח את החיבור.

‫Cloud VPN עוזר לכם לחבר באופן מאובטח את הרשת המקומית שלכם לרשת הענן הווירטואלי הפרטי (VPC) של Google באמצעות חיבור IPsec VPN. נתונים שנמצאים בהעברה מוצפנים לפני שהם עוברים דרך מנהרת VPN אחת או יותר.

איך יוצרים VPN לפרויקט

VPN שסופק על ידי הלקוח

אפשר להגדיר שער VPN משלכם כדי להתחבר ישירות ל-Google, אבל אנחנו ממליצים להשתמש ב-Cloud VPN, שמציע גמישות רבה יותר ושילוב טוב יותר עם Google Cloud.

Cloud Interconnect

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

‫Cross-Cloud Interconnect מאפשר לכם ליצור קישוריות ייעודית עם רוחב פס גבוה ל- Google Cloudעבור הנתונים שלכם בענן אחר. כך אפשר לצמצם את מורכבות הרשת, להפחית את עלויות העברת הנתונים ולאפשר חוות רנדור מרובות עננים עם תפוקה גבוהה.

Dedicated Interconnect

‫Dedicated Interconnect מספק חיבורים פיזיים ישירים ותקשורת RFC 1918 בין הרשת המקומית שלכם לרשת של Google. הוא מספק קיבולת חיבורים דרך סוגי החיבורים הבאים:

• חיבור אתרנט אחד או יותר במהירות של ‎10 Gbps, עם עד שמונה חיבורים או ‎80 Gbps בסך הכול לכל חיבור בין רשתות.
• חיבור אתרנט אחד או יותר של ‎100 Gbps, עם שני חיבורים לכל היותר או ‎200 Gbps בסך הכול לכל חיבור בין רשתות.

התנועה ב-Dedicated Interconnect לא מוצפנת. אם אתם צריכים להעביר נתונים בצורה מאובטחת באמצעות Dedicated Interconnect, אתם צריכים ליצור חיבור VPN משלכם. ‫Cloud VPN לא תואם ל-Dedicated Interconnect, ולכן במקרה הזה תצטרכו לספק VPN משלכם.

Partner Interconnect

‫Partner Interconnect מספק קישוריות בין הרשת המקומית לרשת ה-VPC באמצעות ספק שירות נתמך. חיבור Partner Interconnect שימושי אם התשתית שלכם נמצאת במיקום פיזי שלא ניתן להגיע ממנו למתקן לאחסון ואירוח שרתים (colocation facility) של Dedicated Interconnect, או אם נפח הנתונים שלכם לא מצדיק חיבור שלם של 10Gbps.

סוגי חיבורים אחרים

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

אבטחת התוכן

כדי להפעיל את התוכן שלהם בכל פלטפורמת ענן ציבורית, בעלי תוכן כמו אולפני הוליווד הגדולים דורשים מהספקים לעמוד בשיטות מומלצות לאבטחה שמוגדרות באופן פנימי ועל ידי ארגונים כמו MPAA.Google Cloud מציעה מודלים של אבטחה מסוג אפס אמון שמובנים במוצרים כמו Google Workspace,‏ Chrome Enterprise Premium ו-BeyondProd.

לכל אולפן יש דרישות שונות לאבטחת עומסי עבודה של רינדור. בכתובת cloud.google.com/security אפשר למצוא סקירות טכניות בנושא אבטחה ומסמכי תאימות.

אם יש לכם שאלות לגבי תהליך הביקורת בנושא תאימות לאבטחה, תוכלו לפנות אלGoogle Cloud הנציג שלכם.

ארגון הפרויקטים

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

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

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

משאב הארגון

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

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

הגדרת גישה למשאבים

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

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

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

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

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

היקפי גישה

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

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

הערות לגבי הפקה: כברירת מחדל, מופעים יכולים לקרוא מ-Cloud Storage אבל לא לכתוב בו. אם צינור הנתונים של העיבוד הגרפי כותב עיבודים גרפיים שהסתיימו בחזרה ל-Cloud Storage, צריך להוסיף את היקף ההרשאות devstorage.read_write למופע בזמן היצירה.

בחירת אופן הפריסה של משאבים

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

פריסה על פי דרישה

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

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

פריסת מאגר משאבים

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

רישוי התוכנה

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

שימוש ברישוי מבוסס-מופע

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

כתובות MAC

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

הקצאת כתובת IP סטטית

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

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

מתאמי חומרה

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

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

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

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

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

שרת רישיונות מקומי

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

שרת רישיונות מבוסס-ענן

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

שרת רישיונות היברידי

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

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

export solidangle_LICENSE=5053@x.x.0.1;5053@x.x.0.2

בדוגמה הקודמת, מנוע הרינדור של ארנולד מנסה לקבל רישיון מהשרת בכתובת x.x.0.1, יציאה 5053. אם הניסיון הזה נכשל, המערכת מנסה לקבל רישיון מאותה יציאה בכתובת ה-IP‏ x.x.0.2.

רישוי מבוסס-ענן

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

רישוי לפי שימוש

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

רישוי על בסיס זמן פעולה

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

בחירת אופן האחסון של הנתונים

סוג האחסון שתבחרו ב- Google Cloud תלוי באסטרטגיית האחסון שבחרתם, וגם בגורמים כמו דרישות העמידות והעלות.

דיסק אחסון מתמיד (persistent disk)

אפשר להימנע מהטמעה של שרת קבצים לגמרי על ידי שילוב של דיסקים קבועים (PD) בעומס העבודה. דיסקים מתמידים הם סוג של אחסון בלוקים שתואם ל-POSIX, עד גודל של 64TB, שמוכר לרוב מתקני ה-VFX. דיסקים לאחסון מתמיד (persistent disks) זמינים גם ככוננים רגילים וגם ככונני SSD. אפשר לצרף PD במצב קריאה-כתיבה למכונה אחת, או במצב קריאה-בלבד למספר גדול של מכונות, כמו קבוצה של מכונות לעיבוד תמונה.

אחסון אובייקטים

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

בניגוד לאחסון מסורתי, מערכת הפעלה (OS) לא יכולה לטעון אחסון אובייקטים כנפח לוגי. אם מחליטים לשלב אחסון אובייקטים בצינור העיבוד, צריך לשנות את האופן שבו קוראים וכותבים נתונים, באמצעות כלי שורת פקודה כמו ה-CLI של gcloud או באמצעות Cloud Storage API.

מוצרי אחסון אחרים

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

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

מידע נוסף על אפשרויות לאחסון נתונים

• אפשרויות האחסון הזמינות ב- Google Cloud
• אחסון קבצים ב-Compute Engine
• תכנון אסטרטגיית אחסון אופטימלית לעומס העבודה בענן

הטמעת אסטרטגיות אחסון

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

אסטרטגיה 1: טעינת אחסון מקומי ישירות

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

אסטרטגיה 2: סנכרון לפי דרישה

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

אפשר לבצע סנכרון באמצעות מגוון פקודות, כמו הפקודה scp ב-CLI של gcloud, הפקודה rsync ב-CLI של gcloud או פרוטוקולים להעברת נתונים מבוססי UDP (UDT). אם אתם בוחרים להשתמש ב-UDT של צד שלישי, כמו Aspera,‏ Cloud FastPath,‏ BitSpeed או FDT, כדי לתקשר עם קטגוריה של Cloud Storage, כדאי לעיין במסמכי התיעוד של הצד השלישי כדי לקבל מידע על מודל האבטחה והשיטות המומלצות שלו. ‫Google לא מנהלת את השירותים האלה של צד שלישי.

שיטת דחיפה

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

לדוגמה:

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

שיטת משיכה

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

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

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

אסטרטגיה 3: אחסון מקומי, מטמון קריאה בענן

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

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

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

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

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

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

סינון נתונים

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

ביצוע העברה ראשונית בכמות גדולה

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

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

העברה לארכיון ותוכנית התאוששות מאסון (DR)

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

העברת נתונים לארכיון בענן

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

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

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

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

נושאים נוספים שכדאי להתייחס אליהם:

• להפוך את יצירת התמונות הממוזערות או ה-proxy לאוטומטית עבור תוכן שנמצא בסוגי אחסון ב-Cloud Storage שחלים עליהם דמי אחזור. אפשר להשתמש ב-proxy האלה במערכת לניהול נכסי מדיה, כדי שהמשתמשים יוכלו לעיין בנתונים תוך כדי קריאה רק של ה-proxy, ולא של הנכסים שנארכו.
• כדאי להשתמש בלמידת מכונה כדי לסווג תוכן לייב אקשן. אפשר להשתמש ב-Cloud Vision כדי לתייג טקסטורות ורקעים, או ב-Video Intelligence API כדי לחפש ולשלוף קטעי וידאו להשוואה.
• אפשר גם להשתמש ב-AutoML ב-Gemini Enterprise Agent Platform כדי ליצור מודל תמונות מותאם אישית לזיהוי של כל נכס, בין אם מדובר בפעולה חיה או בהדמיה.
• במקרה של תוכן שעבר רינדור, כדאי לשמור עותק של תמונת הדיסק של תהליך הרינדור יחד עם הנכס שעבר רינדור. אם צריך ליצור מחדש את ההגדרה, גרסאות התוכנה, הפלאגינים, ספריות מערכת ההפעלה והתלויות הנכונות יהיו זמינות אם צריך לעבד מחדש צילום שנשמר בארכיון.

ניהול נכסים והפקה

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

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

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

1. צינור העיבוד של הפרסום מעביר קבצים ל-Cloud Storage ומוסיף רשומה למסד נתונים של נכסים מבוסס-ענן.
2. אומן בלונדון מריץ סקריפט כדי לאסוף נכסים לסצנה. מיקומי הקבצים נשלפים ממסד הנתונים ונקראים מ-Cloud Storage לדיסק המקומי.
3. תוכנה לניהול תור אוספת רשימה של נכסים שנדרשים לעיבוד, שולפת אותם ממסד הנתונים של הנכסים ומורידה אותם מ-Cloud Storage לאחסון המקומי של כל עובד עיבוד.

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

ניהול מסדי נתונים

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

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

ניהול תורים

תוכנות לניהול תורים שזמינות מסחרית, כמו Qube!‎, Deadline, ו-Tractor נמצאים בשימוש נרחב בתעשיית האפקטים הוויזואליים והאנימציה. יש גם אפשרויות לתוכנות קוד פתוח, כמו OpenCue. אפשר להשתמש בתוכנה הזו כדי לפרוס ולנהל כל עומס עבודה של מחשוב במגוון עובדים, ולא רק עיבודים. אתם יכולים לפרוס ולנהל פרסום נכסים, סימולציות של חלקיקים ונוזלים, אפיית טקסטורות והרכבה באמצעות אותה מסגרת תזמון שבה אתם משתמשים לניהול עיבודים.

במתקנים מסוימים הטמיעו תוכנות לתזמון למטרות כלליות, כמו HTCondor מאוניברסיטת ויסקונסין, Slurm מ-SchedMD או Univa Grid Engine, בצינורות העיבוד של האפקטים הוויזואליים. תוכנות שמיועדות במיוחד לתעשיית ה-VFX, אבל שמות דגש על תכונות כמו:

• תלות לפי עבודה, מסגרת ושכבה. כדי להתחיל משימות מסוימות, צריך קודם לסיים משימות אחרות. לדוגמה, מריצים סימולציה של נוזל באופן מלא לפני שמבצעים רינדור.
• קדימות המשימה, שבעזרתה אפשר לשנות את סדר המשימות בהתאם ללוחות זמנים ולתאריכי יעד ספציפיים.
• סוגי משאבים, תוויות או יעדים, שבהם אפשר להשתמש כדי להתאים משאבים ספציפיים למשימות שדורשות אותם. לדוגמה, אפשר לפרוס רינדורים מואצי GPU רק במכונות וירטואליות שמצורפים אליהן יחידות GPU.
• תיעוד היסטורי של נתוני השימוש במשאבים והפיכתם לזמינים באמצעות API או לוח בקרה לצורך ניתוח נוסף. לדוגמה, אפשר לבדוק את השימוש הממוצע במעבד ובשימוש בזיכרון בכמה איטרציות אחרונות של עיבוד כדי לחזות את השימוש במשאבים באיטרציה הבאה.
• משימות לפני ואחרי ההפעלה. לדוגמה, עבודת הכנה לפני הפעלת המטוס מושכת את כל הנכסים הדרושים אל עובד הרינדור המקומי לפני הרינדור. משימה שמתבצעת אחרי הטיסה מעתיקה את הפריים המעובד למיקום ייעודי במערכת קבצים, ואז מסמנת את הפריים כהושלם במערכת לניהול נכסים.
• שילוב עם אפליקציות פופולריות של תוכנות דו-ממד ותלת-ממד כמו Maya,‏ 3ds Max,‏ Houdini,‏ Cinema 4D או Nuke.

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

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

שיקולים בפריסת משרות

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

• יכול להיות שיהיו הבדלים ברישוי בין פריסות בענן לבין פריסות מקומיות. חלק מהרישיונות מבוססים על צומת, וחלקם מבוססים על תהליך. חשוב לוודא שתוכנת ניהול התור פורסת משימות כדי למקסם את הערך של הרישיונות.
• כדאי להוסיף תגים או תוויות ייחודיים למשאבים מבוססי-ענן כדי לוודא שהם ישמשו רק כשהם מוקצים לסוגי עבודות ספציפיים.
• אפשר להשתמש ב-Cloud Logging כדי לזהות מקרים של מכונות וירטואליות שלא נמצאות בשימוש או בלי פעילות.
• כשמפעילים משימות תלויות, צריך לחשוב איפה הנתונים שיתקבלו יהיו ואיפה הם צריכים להיות בשביל השלב הבא.
• אם מרחבי השמות של הנתיבים שונים בין אחסון מקומי לאחסון מבוסס-ענן, כדאי להשתמש בנתיבים יחסיים כדי לאפשר עיבודים ללא תלות במיקום. אפשרות אחרת, בהתאם לפלטפורמה, היא ליצור מנגנון להחלפת נתיבים בזמן רינדור.
• חלק מהעיבודים, הסימולציות או הפעולות שלאחר העיבוד מסתמכים על יצירת מספרים אקראיים, שיכולה להיות שונה בין יצרני מעבדים שונים. גם מעבדים מאותו יצרן אבל מדורות שונות של שבבים יכולים להפיק תוצאות שונות. אם יש ספק, כדאי להשתמש בסוגי מעבד זהים או דומים לכל הפריים של עבודה.
• אם אתם משתמשים במכשיר מטמון מסוג read-through, כדאי להפעיל משימת בדיקה מוקדמת כדי לחמם מראש את המטמון ולוודא שכל הנכסים זמינים בענן לפני שאתם פורסים משאבי ענן. הגישה הזו מצמצמת את משך הזמן שעובדי הרינדור נאלצים להמתין בזמן שהנכסים מועברים לענן.

רישום ביומן ומעקב

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

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

דרכים אחרות לאיסוף נתוני השימוש במשאבים ולמעקב אחריהם ב- Google Cloud:

• אפשר להשתמש ב-Cloud Logging כדי לתעד את יומני השימוש והביקורת, ולייצא את היומנים שמתקבלים ל-Cloud Storage, ל-BigQuery ולשירותים אחרים.
• משתמשים ב-Cloud Monitoring כדי להתקין סוכן במכונות ה-VM כדי לעקוב אחרי מדדי המערכת.
• משלבים את Cloud Logging API בסקריפטים של צינורות העברת הנתונים כדי להיכנס ישירות ל-Cloud Logging באמצעות ספריות לקוח לשפות סקריפטים פופולריות.
• אפשר להשתמש ב-Cloud Monitoring כדי ליצור תרשימים שיעזרו לכם להבין את השימוש במשאבים.

הגדרת מופעים של עובדי רינדור

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

בחירת תמונת דיסק

אפשר לבחור מתוך אחת מהתמונות הציבוריות או ליצור תמונה מותאמת אישית שמבוססת על תמונת צומת העיבוד המקומי. תמונות ציבוריות כוללות אוסף של חבילות שמגדירות ומנהלות חשבונות משתמשים ומאפשרות אימות שמבוסס על מפתח Secure Shell‏ (SSH).

יצירת תמונה בהתאמה אישית

אם בוחרים ליצור תמונה מותאמת אישית, צריך להוסיף עוד ספריות ל-Linux ול-Windows כדי שהן יפעלו בצורה תקינה בסביבת Compute Engine.

קובץ האימג' בהתאמה אישית צריך לעמוד בשיטות המומלצות לאבטחה. אם אתם משתמשים ב-Linux, אתם צריכים להתקין את סביבת האורח של Linux ל-Compute Engine כדי לקבל גישה לפונקציונליות שאימג'ים ציבוריים מספקים כברירת מחדל. התקנת סביבת האורח מאפשרת לבצע משימות כמו גישה למטא-נתונים, הגדרת המערכת ואופטימיזציה של מערכת ההפעלה לשימוש ב- Google Cloud, באמצעות אותם אמצעי אבטחה שבהם אתם משתמשים בתמונות ציבוריות.

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

אוטומציה של יצירת תמונות ופריסת מופעים

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

בחירת סוג מכונה

ב- Google Cloud, אפשר לבחור אחד מסוגי המכונות המוגדרים מראש או לציין סוג מכונה בהתאמה אישית. שימוש בסוגי מכונות מותאמים אישית מאפשר לכם לשלוט במשאבים, כך שתוכלו להתאים אישית את המופעים על סמך סוגי העבודות שאתם מריצים Google Cloud. כשיוצרים מופע, אפשר להוסיף יחידות GPU ולציין את מספר יחידות ה-CPU, את פלטפורמת ה-CPU, את כמות ה-RAM ואת הסוג והגודל של הדיסקים.

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

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

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

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

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

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

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

הענקת גישה לעובדי רינדור

בעזרת IAM אפשר להקצות גישה למשאבי ענן לאנשים שזקוקים לגישה. במכונות Linux לעיבוד תמונות, אפשר להשתמש ב-OS Login כדי להגביל עוד יותר את הגישה בסשן SSH, וכך לקבוע מי יהיה אדמין.

שליטה בעלויות של חוות רינדור היברידית

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

• שימוש במופעים שניתן להפסיק כברירת מחדל. אלא אם משימת הרינדור שלכם ארוכה במיוחד, ארבע שעות או יותר לכל פריים, או שיש לכם דדליין קשיח למסירת צילום, כדאי להשתמש במכונות preemptible VM.
• צמצום התעבורה היוצאת. מעתיקים רק את הנתונים שרוצים לשחזר לאחסון המקומי. ברוב המקרים, הנתונים האלה יהיו הפריים הסופי שעבר רינדור, אבל הם יכולים להיות גם נתונים של מעברים נפרדים או של סימולציה. אם אתם מטמיעים את ה-NAS המקומי שלכם ישירות, או משתמשים במוצר אחסון שמסנכרן באופן אוטומטי, כתבו את כל הנתונים שעברו רינדור למערכת הקבצים המקומית של עובד הרינדור, ואז העתיקו את מה שאתם צריכים בחזרה לאחסון המקומי כדי להימנע מיציאה של נתונים זמניים ומיותרים.
• בחירת הגודל המתאים למכונות וירטואליות. חשוב ליצור את העובדים לעיבוד עם שימוש אופטימלי במשאבים, ולהקצות רק את מספר המעבדים הווירטואליים הנדרש, את כמות ה-RAM האופטימלית ואת מספר יחידות ה-GPU הנכון, אם יש כאלה. כדאי גם לחשוב איך לצמצם את הגודל של הדיסקים המצורפים.
• חשוב לזכור שהסרטון צריך להיות באורך של דקה לפחות. ב- Google Cloud, החיוב על מופעים הוא לפי שנייה, עם מינימום של דקה אחת. אם עומס העבודה כולל עיבוד של פריימים שנמשך פחות מדקה, כדאי לקבץ את המשימות כדי להימנע מפריסת מופע למשך פחות מדקת זמן מחשוב.
• שמירה של מערכי נתונים גדולים בענן. אם אתם משתמשים בחוות העיבוד שלכם כדי ליצור כמויות גדולות של נתונים, כמו קובצי EXR עמוקים או נתוני סימולציה, כדאי להשתמש בתחנת עבודה מבוססת-Cloud שנמצאת בהמשך תהליך העבודה. לדוגמה, אמן אפקטים מיוחדים עשוי להריץ סימולציה של נוזל בענן, ולכתוב קבצי מטמון לאחסון מבוסס-ענן. אמן תאורה יכול לגשת לנתוני הסימולציה האלה מתחנת עבודה וירטואלית שנמצאת ב-Google Cloud. למידע נוסף על תחנות עבודה וירטואליות, אפשר לפנות אל Google Cloud הנציג שלכם.
• ליהנות מהנחות על שימוש קבוע ומהנחות תמורת התחייבות לשימוש. אם אתם מפעילים מאגר משאבים, הנחות על שימוש מתמשך יכולות לחסוך לכם עד 30% מהעלות של מופעים שפועלים במשך חודש שלם. במקרים מסוימים, כדאי גם להשתמש בהנחות תמורת התחייבות לשימוש.

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

המאמרים הבאים

• כדאי להעמיק את הקריאה ולהכיר דוגמאות לארכיטקטורות, תרשימים ושיטות מומלצות בנושאי Google Cloud. כל אלה זמינים במרכז הארכיטקטורה של Cloud.