פריסת צומת TON: צומת מלא, מאמת, שרת קל

פריסת נוד TON: היכן נשברת הסנכרון

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

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

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

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

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

מה נותן נוד ייעודי: תגובתיות, עצמאות, זמינות

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

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

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

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

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

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

מצבי נוד: ארכיוני, ולידטורי, שירותי

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

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

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

איך זה מתחבר בפועל

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

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

שלבי הפריסה: מביקורת ועד העברה לתמיכה

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

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

1. ביקורת תשתית. אנחנו מעריכים את המרווח בדיסק ואת פרופיל פעולות הדיסק, יציבות הערוץ, פריסה לפי אזורי כשל. כאן גם מתברר אם הפלטפורמה תעמוד בכתיבה מתמדת.
2. תכנון סכימת הצומת. אנחנו קובעים את המצב: full node לקריאת הרשת, validator להשתתפות בקונסנזוס, lite-server כנקודת שירות לבקשות. ובנוסף סכימת הרשאות, אחסון מפתחות וניטור.
3. פריסה וסנכרון. מעלים את השירות, מגדירים הפעלה אוטומטית ועדכונים, מביאים את הצומת למצב הרשת העדכני ובודקים שהפיגור לא גדל עם הזמן.
4. בדיקה תחת עומס. מריצים פרופיל של בקשות אמיתיות, בוחנים את ההתנהגות בשיאים, מפעילים מחדש את הצומת ומודדים את זמן החזרה לסנכרון.
5. קבלת הצומת. משווים את המדדים לאלה שסוכמו מראש: יציבות החיבורים, עומק הסנכרון, התגובה לכשל דיסק או רשת.
6. העברה לתמיכה. מוסרים הרשאות, סכימה, הוראות תורנות והתראות מוגדרות — צוות הלקוח יכול להפעיל את הצומת בלעדינו.

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

ערכת האספקה: קונפיגורציות, סכימות, נהלים

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

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

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

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

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

לפני: כיצד נראה הכשל

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

אחרי: מה שינו ומה השתנה

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

רציפות העבודה עלתה מ-97% ל-99.9%, שיעור הבקשות הקלות המוצלחות — מ-92% ל-99.6%. זמן השחזור הצטמצם משעות רבות לדקות: הצומת עולה מצילום המצב האחרון ומדביק רק את שארית השרשרת. סוג הכשלים "נפל ונשר מהרשת לזמן רב" נסגר — כשל בודד כבר לא הופך להשבתה של שירות הלקוח.

במה שונה נוד TON לקריאה מוולידטור

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

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

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

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

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

ספקות טכניים: משאבים, אמינות, עדכונים

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

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

כיצד לעבור עדכוני רשת?

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

מה קורה בכשל של הצומת?

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

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

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

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

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