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

מה אנחנו בונים

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

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

בחירת מיקום: החום הוא העיקר

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

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

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

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

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

לשרת יש שם. לא hostname, אלא שם. בדרך כלל Gandalf, או Odin. אי אפשר להוציא את 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, שלא תוקנו על ידי איש. אתחול ממילא אינו בא בחשבון; אתחול הוא הדרך שבה אתם מגלים אילו שירותים הופעלו ידנית בשנת 2021 ומעולם לא נכתבו עבורם יחידות systemd. איש אינו זוכר אילו מהם. השרת כעת נושא בנטל הארגוני.

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

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

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

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

רשת: מקשה אחת של הכל

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

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

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

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

יתירות באמצעות מורכבות

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

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

חימום כשירות (Heating as a service)

שרת מודרני ממיר חשמל לחישוב ולחום, ואנו שואפים למקסם את התפוקה השנייה. שרת מדיה ללא GPU הוא הגישה הקלאסית: קידוד (transcoding) של זרם 4K בודד באמצעות ה-CPU יעסיק שש-עשרה ליבות ויחמם חדר קטן; זהו תנור חימום שמקרין גם סרטים. מפעיל שאפתן יותר יתקדם ל-הרצת מודל שפה גדול על ה-CPU, תנור חימום בעל 70 מיליארד פרמטרים עם API, המפיק אסימונים (tokens) בקצב שנמדד בצורה הטובה ביותר לפי עונות השנה.

הניטור מנטר את עצמו

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

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

החלק הלא נעים

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

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

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

FAQ

האם כדאי לי באמת לבצע משהו מזה?

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

מהו ערך PUE טוב, בפועל?

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

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

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

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

גיבויים, הלילה, למקום שאינו השרת, ולאחר מכן שחזור בדיקה; גיבוי שלא נבדק הוא בגדר שמועה בלבד. שנית, עדכוני אבטחה (patches) וה-reboot שאתה דוחה, בתוך חלון זמן מתוכנן, כדי שתלמד מה נשבר בזמן שאתה משגיח. שלישית, פצל את נקודת הכשל היחידה: העבר את ה-DNS והניטור מחוץ לשרת. כל השאר יכול לחכות לשבוע רגוע יותר; שלושת אלו לא.