איך לבנות datacenter הכי לא יעיל בעולם

מה אתם בונים

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

אנחנו זקוקים למדד, לכן נשאיל את המדד של התעשייה: PUE, Power Usage Effectiveness — סך צריכת החשמל של המתקן חלקי החשמל שמגיע בפועל לציוד המחשוב. datacenter בקנה מידה hyperscale עובד סביב 1.1: כמעט כל וואט מבצע עבודה מועילה. חדר שרתים ארגוני מנהל 1.5. היעד שלנו הוא 4.0 ומעלה, מה שאומר שעבור כל וואט של מחשוב, שלושה וואטים נוספים מתבזבזים ללא תועלת. אנחנו נשתמש במספר הזה לעיתים קרובות, בדיוק כפי שמדריכים רציניים מתייחסים לג backups.

בחירת אתר: החום הוא המטרה

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

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

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

שרת אחד, גדול, אהוב

Redundancy (יתירות) מחלישה את המחויבות. מרכז הנתונים שלנו מכיל שרת אחד בדיוק, והוא עצום, כי מכונה אחת עם 512 GB של RAM מרגישה כמו תשתית, בעוד שארבע מכונות קטנות מרגישות כמו רשימת מטלות.

לשרת יש שם. לא hostname — אלא שם. Gandalf, בדרך כלל, או Odin. אי אפשר לבצע decommissioning ל-Odin. Odin פועל כבר חמש שנים:

$ uptime
 09:14:02 up 1847 days,  3:22,  1 user,  load average: 6.41, 6.38, 6.40

המספר הזה הוא מקור לגאווה, וזו הסיבה שצילמתם אותו ומפרסמתם אותו, וזו הסיבה שכל תוקף שרואה את הצילום גם מוצא אותו מרשים: 1,847 ימים של uptime פירושם 1,847 ימים של פגיעויות kernel, שאיש לא תיקן (patched). ריסטארט (reboot) הוא בכלל לא אופציה — reboot הוא הדרך שבה מגלים אילו שירותים הופעלו ידנית בשנת 2021 ומעולם לא נכתבו כ-systemd unit. אף אחד לא זוכר אילו שירותים. השרת הוא כעת עמוד השדרה הארגוני.

אחסון: מהירות, ודרכים אחרות לאבד נתונים

הדיסקים מוגדרים ב-RAID 0, לצורך ביצועים. ה-zero מתייחס למספר הדיסקים שיכולים להיכשל. להשפעה מקסימלית, בצעו striping למערך על גבי אחסון ממקורות מעורבים: שני SSDs תקינים, דיסק מגנטי (spinner) מזדקן אחד, ו-USB stick מכנס. המערך אמין בדיוק כמו ה-USB stick מהכנס, וזה התכנון.

backups מנוהלים על ידי ספרייה באותו array בשם backup_final_v2_REAL, המכילה tarball של שיטת השיום הקודמת. backups מחוץ לאתר (off-site) מיוצגים על ידי פתק דביק שכתוב עליו "set up off-site backups", שזה, מבחינה טכנית, מאוחסן מחוץ לאתר כשאתם לוקחים אותו הביתה על מכסה הלפטופ.

תוצאה תקינה נראית כך: df מדווח על 97% usage, ותוכנית לטיפול בזה ב-sprint הבא.

Networking: חוט אחד של הכל

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

ה-firewall בוטל בשנת 2021 — זמנית, כדי לדבג משהו. הדיבאג הסתיים; ה-firewall לא חזר. כל פורט בנתב (router) מופנה לשרת "כדי לחסוך זמן מאוחר יותר", ופאנל הניהול של הנתב נגיש מצד ה-WAN עם סיסמת היצרן שלו, לניהול מרחוק נוח. שלכם, ושל אחרים.

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

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

Redundancy דרך מורכבות

אחרי שסרנו redundancy במקומות שבהם הוא חשוב, אנחנו מוסיפים אותו במקומות שבהם הוא לא. דף הבית של החברה — קובץ HTML סטטי אחד — מוגש על ידי Kubernetes cluster בעל 12 נודים. זה משיג את מה שמהנדסים מכנים "architecture מונעת-קורות-חיים": הדף נטען באותם 40 מילישניות ש-nginx היה מספק, אבל כעת הוא יכול להיכשל בדרכים שדורשות יועץ.

לבידוד, ה-cluster עצמו רץ בתוך מכונה וירטואלית בתוך מכונה וירטואלית בתוך מכונה וירטואלית, כשכל שכבה מוסיפה אבטחה בדיוק כפי שכל שכבה ב-turducken מוסיפה עוף. טופס הקשר מורכב מ-9 מיקרו-שירותים (microservices). שניים מהם מעולם לא הופעלו. אחד מהם הוא קריטי לתפקוד (load-bearing) ואף אחד לא יודע איזה.

Heating as a service

שרת מודרני ממיר חשמל למחשוב וחום, ואנחנו מתכוונים למקסם את הפלט השני. media server ללא GPU הוא המהלך הקלאסי: CPU-transcoding של זרם 4K יחיד יפעיל 16 ליבות ויחמם חדר שינה קטן, תנור חימום שמקרין גם סרטים. המפעיל השאפתן עובר ל-running a large language model on CPU — תנור חימום עם 70 מיליארד פרמטרים ו-API, שמייצר tokens בקצב שמומלץ למדוד אותו עונתית.

המנטר צופה בעצמו

Observability הוא חשוב, לכן אנו פורסים a self-hosted uptime monitor — על אותו שרת שהוא מנטר. כש-Odin מת, המנטר מת איתו, וכאן נמצא החלק האלגנטי: שום התראה (alert) לא נשלחת. אין התראות פירושו אין תקלות. אין תקלות פירושו uptime מושלם, לפי המדידה. הדו"ח החודשי מעולם לא נראה טוב יותר.

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

החלק הלא נעים

זהו החלק שדחיתי זמן רב. שום דבר מזה אינו בדיוני. השרת האהוב והבלתי ניתן להחלפה, ה-RAID 0 עם backups על אותו volume, ה-firewall שבוטל "זמנית", ה-Kubernetes cluster שמשרת דף אחד, המנטר שצופה בעצמו — ראיתי כל אחד מאלה בייצור (production). חלקם ראיתי השנה. אחד או שניים מהם, בימים הראשונים שלי, בניתי בעצמי.

איך נראה יעילות אמיתית זה משעמם, וזו הסיבה שהיא מפסידה בוויכוח ברגע ומנצחת עליו לאורך עשור: PUE שמעולם לא חושבים עליו כי מישהו אחר תכנן אותו. מכונות המותאמות לעומס העבודה שלהן במקום לתדמית של הבעלים שלהן. blast radius, שנשקל לפני הפיצוץ. backups שנבדקו על ידי שחזור שלהם, על לוח זמנים, עם תזכורת ביומן וללא גבורה. Redundancy שמשעמם — שני דברים זולים מנצחים דבר אחד מפואר, בכל פעם, בכל תקלה שבה קיבלתי הודעה (paged).

וה-datacenter הכי יעיל שאתם יכולים להפעיל הוא זה שאתם לא מפעילים. VPS מעביר את החשמל, הקירור, היתירות ותקלות החומרה בשעה 3 לפנות בוקר לאנשים שעושים זאת בקנה מידה גדול ובצורה משעממת, שזה המחמאה הגבוהה ביותר ש-infrastructure יכולה לקבל — וזה משאיר לכם את החלק המהנה באמת, שהוא running your own services on top of it, על מכונה שאתם יכולים להרשות לעצמם לאבד, וזו היחידה שבה כדאי לכם להתנסות.

FAQ

האם אני באמת צריך לעשות את כל זה?

לא. כל סעיף במדריך זה הוא anti-pattern מתועד עם "מונה קורבנות" של סופי שבוע. אם ההגדרה הנוכחית שלכם דומה ליותר משני סעיפים, דלגו לשאלה האחרונה ב-FAQ הזה — לפי הסדר שניתן, כי הסדר הוא ה-triage (מיון פצועים).

מהו PUE טוב, באמת?

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

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

כן — אם עושים זאת נכון. פרויקטים של חימום עירוני (district-heating) בכמה מדירות לוכדים את חום הפסולת של מרכזי נתונים דרך מחליפי חום ומוליכים אותו לבתים, בתכנון, עם הנדסה וחוזים. הסאטירה לעיל אינה אומרת שחום שרת יכול לחמם חדר; היא אומרת שהם עושים זאת במקרה וקוראים לתקלה אסטרטגיה.

השרת שלי כבר נראה ככה. מה עלי לעשות קודם?

backups, הלילה, למקום שהוא לא השרת, ואז שחזור לבדיקה — backup שלא נבדק הוא רק שמועה. שנית, patches וה-reboot שאתם נמנעים ממנו, בחלון זמן מתוכנן, כדי שתלמדו מה נשבר בזמן שאתם עוקבים. שלישית, פצלו את נקודת הכשל היחידה (single point of failure): העילי את ה-DNS והניטור מחוץ לקופסה. כל השאר יכול לחכות לשבוע רגוע יותר; שלושת אלה לא.