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

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

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

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

הראשון שבהם, כמה שזה נשמע מוזר, הוא הבעיה של בחירת כיוון.

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

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

• אימון רשתות עצביות
• עיבוד זרמי אות
• חשב את מבנה החלבון
• עיבוד סצנות תלת מימד
• הדמיית הידרודינמיקה
• בדוק אסטרטגיות מסחר לבורסות

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

לפיכך, נוצר ההרכב הפונקציונלי של מסגרת נוף המיועדת לבניית מערכות עיבוד מבוזרות:

1. חשבונות משתמש אישיים עם גישה לאינטרנט
2. ערכת תוכנה להתקנה על צמתים
3. לפי מערכת בקרה:
   • תת מערכת בקרת גישה
   • תת-מערכת פירוק משימות רינדור
   • תת מערכת לחלוקת משימות
   • תת מערכת מורכבת
   • תת-מערכת לניהול נוף שרת וטופולוגיה ברשת
   • תת מערכת רישום וביקורת
   • תת מערכת מומחי למידה
   • Rest API או ממשק אחר למפתחים חיצוניים

מה אתה חושב? אילו שאלות מעורר הנושא ובאילו תשובות אתה מעוניין?

מקור: www.habr.com