طراحی ناکارآمدترین دیتاسنتر جهان

آنچه در حال ساخت آن هستید

هر راهنمایی در این سایت به شما می‌آموزد که کاری را به درستی انجام دهید: دستورات به ترتیب، ظاهر یک نتیجه صحیح، و نام‌گذاری حالت‌های شکست. این راهنما متفاوت است. امروز، کاملاً به صورت فرضی، قصد داریم ناکارآمد‌ترین دیتاسنتری را طراحی کنیم که پول، برق و غرور انسانی می‌توانند تولید کنند.

ما به یک معیار نیاز داریم، بنابراین از معیار خود صنعت استفاده می‌کنیم: PUE یا Power Usage Effectiveness — مجموع توان کل مجموعه تقسیم بر توانی که واقعاً به تجهیزات محاسباتی می‌رسد. یک دیتاسنتر hyperscale حدود 1.1 کار می‌کند: تقریباً هر وات صرف کار مفید می‌شود. یک اتاق سرور سازمانی مناسب، مقدار 1.5 را مدیریت می‌کند. هدف ما 4.0 یا بالاتر است، به این معنی که به ازای هر وات محاسبات، سه وات دیگر بیهوده هدر می‌رود. ما اغلب به این عدد ارجاع خواهیم داد، همان‌طور که راهنماهای جدی به بک‌آپ‌ها ارجاع می‌دهند.

انتخاب سایت: هدف، گرما است

سرمایش، بزرگترین هزینه سربار در یک دیتاسنتر واقعی است، به همین دلیل دیتاسنتر ما با ترمودینامیک در قلمرو خودش مبارزه خواهد کرد. مکان ایده‌آل، یک اتاق زیرشیروانی است. رو به جنوب. در حالت ایده‌آل با یک skylight که مستقیماً روی سرور قرار گرفته باشد، تا ماشین هم گرمای تلف‌شده خودش و هم گرمای خورشید را دریافت کند؛ همکاری بین قبض برق شما و یک ستاره.

در زمستان، سرمایش با باز کردن پنجره مدیریت می‌شود. دیتاسنترهای واقعی از هوای بیرون استفاده می‌کنند — این تکنیک free cooling نامیده می‌شود و مهندسی شده، فیلتر شده و از نظر رطوبت کنترل شده است. ما از آن به صورت تصادفی، از طریق پنجره‌ای که باران، گرده و حداقل یک پرنده گیج در هر فصل را وارد می‌کند، استفاده خواهیم کرد.

برای هنر واقعی، یک کولر گازی نصب کنید، سپس یک بخاری برقی را در دو فوتی ترموستات آن قرار دهید، با دمایی دو درجه گرم‌تر از هدف کولر. اکنون هر دو دستگاه به طور مداوم، برای همیشه، در مخالفت کامل با هم کار خواهند کرد. شرکت برق در کریسمس برای شما کارت تبریک می‌فرستد.

یک سرور، بزرگ و محبوب

Redundancy (افزونگی) باعث کاهش تعهد می‌شود. دیتاسنتر ما دقیقاً شامل یک سرور است و آن سرور بسیار بزرگ است، زیرا یک ماشین واحد با 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) است که توسط هیچ‌کس وصله نشده است. بازنشانی (reboot) اصلاً مطرح نیست — reboot روشی است که متوجه می‌شوید کدام سرویس‌ها در سال 2021 به صورت دستی اجرا شده‌اند و هرگز در یک unit در systemd نوشته نشده‌اند. هیچ‌کس آن‌ها را به خاطر نمی‌آورد. سرور اکنون در نمودار سازمانی، یک رکن اصلی است.

ذخیره‌سازی: سرعت، و روش‌های دیگر برای از دست دادن داده‌ها

دیسک‌ها برای عملکرد بالا در حالت RAID 0 پیکربندی شده‌اند. عدد صفر به تعداد دیسک‌هایی اشاره دارد که ممکن است خراب شوند. برای حداکثر اثرگذاری، آرایه را روی ذخیره‌سازهایی با منشأ متفاوت ایجاد کنید: دو SSD واقعی، یک هارد قدیمی (spinner)، و یک فلش USB از یک کنفرانس. آرایه دقیقاً به اندازه فلش کنفرانس قابل اعتماد است، که این همان طراحی مد نظر است.

بک‌آپ‌ها توسط دایرکتوری‌ای در همان آرایه به نام backup_final_v2_REAL مدیریت می‌شوند که شامل یک tarball از طرح نام‌گذاری قبلی است. بک‌آپ‌های off-site توسط یک یادداشت چسبان با متن "set up off-site backups" نمایش داده می‌شوند، که از نظر فنی، وقتی آن را با لپ‌تاپ خود به خانه می‌برید، در خارج از سایت ذخیره شده است.

یک نتیجه صحیح به این صورت است: df که 97% استفاده را گزارش می‌دهد، و برنامه‌ای برای رسیدگی به آن در sprint بعدی.

شبکه: یک رشته واحد از همه چیز

سرور DNS روی خود ماشین اجرا می‌شود، بنابراین وقتی سرور از کار می‌افتد، رکورد DNS را که برای فهمیدن علت خرابی استفاده می‌کردید، با خود می‌برد. این را تجمیع (consolidation) می‌نامند.

فایروال در سال 2021 غیرفعال شد — به صورت موقت، برای عیب‌یابی چیزی. عیب‌یابی تمام شد؛ اما فایروال بازنگشت. هر پورت روی روتر برای "صرفه‌جویی در زمان در آینده" به سرور فوروارد شده است، و پنل مدیریت روتر با رمز عبور کارخانه از سمت WAN قابل دسترسی است، برای مدیریت از راه دور راحت. برای شما و دیگران.

سرور اخیراً به طرز غیرمعمولی گرم کار کرده است، حتی با استانداردهای اتاق زیرشیروانی، و top نشان می‌دهد که پرکارترین فرآیند چیزی به نام xmrig است. فرض می‌کنیم این همان ابزار مانیتورینگ است که از آن استفاده می‌کنیم. ما آن را نصب نکردیم — مدت کوتاهی پس از فوروارد شدن پورت‌ها، خودش ظاهر شد، که ما آن را نشانه‌ای از شکوفایی اکوسیستم می‌دانیم. آن به صورت شبانه‌روزی مانیتور می‌کند.

برق از طریق زنجیره‌ای از چندراهی‌های مصرفی می‌رسد که طول مجموع آن‌ها از مسافت پیاده‌روی تا پنل فیوز بیشتر است — که به یک معنا کارآمد است، زیرا شما مکرراً به پنل فیوز سر خواهید زد.

افزونگی از طریق پیچیدگی

ما با رد کردن redundancy در جاهایی که مهم است، اکنون آن را در جاهایی که مهم نیست اضافه می‌کنیم. صفحه اصلی شرکت — یک فایل HTML استاتیک — توسط یک خوشه Kubernetes با 12 نود سرویس‌دهی می‌شود. این کاری را انجام می‌دهد که مهندسان به آن معماری مبتنی بر رزومه می‌گویند: صفحه با همان 40 میلی‌ثانیه‌ای که nginx تحویل می‌داد بارگذاری می‌شود، اما اکنون می‌تواند به روش‌هایی شکست بخورد که نیاز به یک مشاور داشته باشد.

برای جداسازی، خود خوشه داخل یک ماشین مجازی داخل یک ماشین مجازی داخل یک ماشین مجازی اجرا می‌شود، که هر لایه امنیت را مانند لایه‌های یک turducken (مرغ در داخل مرغ) اضافه می‌کند. فرم تماس شامل 9 میکروسرویس است. دو مورد از آن‌ها هرگز فراخوانده نشده‌اند. یکی از آن‌ها رکن اصلی است و هیچ‌کس نمی‌داند کدام است.

گرمایش به عنوان یک سرویس

یک سرور مدرن برق را به محاسبات و گرما تبدیل می‌کند، و ما قصد داریم خروجی دوم را به حداکثر برسانیم. یک media server بدون GPU یک انتخاب کلاسیک است: CPU-transcoding یک استریم واحد 4K، شانزده هسته را درگیر می‌کند و یک اتاق خواب کوچک را گرم می‌کند؛ بخاری‌ای که فیلم هم پخش می‌کند. اپراتور جاه‌طلب به اجرای یک مدل زبانی بزرگ روی CPU ارتقا می‌یابد — یک بخاری با 70 میلیارد پارامتر که یک API دارد و توکن‌ها را با سرعتی تولید می‌کند که بهتر است به صورت فصلی اندازه‌گیری شود.

مانیتور خودش را می‌پوشد

مشاهده‌پذیری (Observability) مهم است، بنابراین ما یک مانیتور uptime خود-میزبان را مستقر می‌کنیم — روی همان سروری که مانیتور می‌کند. وقتی Odin می‌میرد، مانیتور هم با آن می‌میرد، و بخش ظریف کار اینجاست: هیچ هشداری (alert) صادر نمی‌شود. نبود هشدار یعنی نبود حادثه. نبود حادثه یعنی uptime بی‌نقص، طبق اندازه‌گیری. گزارش ماهانه هرگز بهتر از این نبوده است.

ایمیل‌های هشدار، برای تکمیل کار، از طریق یک سرور ایمیل که آن هم روی Odin اجرا می‌شود، ارسال می‌شوند. بنابراین خط لوله هشدار کاملاً خودکفا است، به همان شکلی که یک مار که دم خودش را می‌خورد، کاملاً سیر شده است.

بخش ناخوشایند

این بخشی است که من از آن فرار می‌کردم. هیچ‌کدام از این‌ها تخیلی نیست. سرور محبوب و جایگزین‌ناپذیر، RAID 0 با بک‌آپ در همان حجم، فایروال غیرفعال شده "به صورت موقت"، خوشه Kubernetes که یک صفحه را سرویس می‌دهد، مانیتوری که خودش را مانیتور می‌کند — من همه این‌ها را در محیط عملیاتی (production) دیده‌ام. برخی از آن‌ها را همین امسال دیده‌ام. یک یا دو مورد از آن‌ها را در روزهای اولیه کارم، خودم ساختم.

آنچه کارایی واقعی است، خسته‌کننده است، به همین دلیل است که در لحظه در بحث شکست می‌خورد اما در طول یک دهه پیروز می‌شود: PUE ای که هرگز به آن فکر نمی‌کنید چون شخص دیگری آن را مهندسی کرده است. ماشین‌هایی که به اندازه بار کاری‌شان سایز شده‌اند، نه به اندازه تصویر ذهنی مالکشان. یک شعاع انفجار (blast radius) که قبل از انفجار در نظر گرفته شده است. بک‌آپ‌هایی که با بازیابی آن‌ها، در یک برنامه مشخص، با یک یادآوری تقویم و بدون قهرمان‌بازی تست شده‌اند. Redundancy که کسل‌کننده است — دو عدد از چیز ارزان، همیشه در هر خرابی که من برای آن فراخوانده شده‌ام، بر یک چیز باشکوه پیروز می‌شود.

و کارآمدترین دیتاسنتری که می‌توانید اجرا کنید، دیتاسنتری است که اجرا نمی‌کنید. یک VPS قدرت، سرمایش، افزونگی و خرابی‌های سخت‌افزاری ساعت 3 صبح را به افرادی واگذار می‌کند که این کارها را در مقیاس بزرگ و به صورت کسل‌کننده انجام می‌دهند، که بالاترین تحسین برای یک زیرساخت است — و بخش واقعاً سرگرم‌کننده را برای شما باقی می‌گذارد، که یعنی اجرای سرویس‌های خودتان روی آن، روی ماشینی که می‌توانید از دست دادنش را تحمل کنید، که تنها نوعی است که باید روی آن آزمایش کنید.

FAQ

آیا واقعاً باید هیچ‌کدام از این‌ها را انجام دهم؟

خیر. هر بخش از این راهنما یک anti-pattern مستند شده با تلفات از آخر هفته‌ها است. اگر تنظیمات فعلی شما به بیش از دو بخش شباهت دارد، به آخرین سوال در این FAQ بروید — به ترتیب داده شده، چون ترتیب، اولویت‌بندی است.

در واقع یک PUE خوب چقدر است؟

دیتاسنترهای hyperscale حدود 1.1 کار می‌کنند، یک اتاق سازمانی با مدیریت خوب بین 1.4 تا 1.6 است، و یک کمد بدون سرمایش با یک بخاری برقی می‌تواند واقعاً از 3 فراتر رود. شما نمی‌توانید در خانه به طور معناداری با 1.1 رقابت کنید، که این استدلال اقتصادی آرام برای اجاره کردن توان محاسباتی از کسی است که می‌تواند آن را انجام دهد.

آیا گرم کردن یک ساختمان با سرورها یک موضوع واقعی است؟

بله — اگر به درستی انجام شود. پروژه‌های گرمایش منطقه‌ای در چندین کشور، گرمای تلف‌شده دیتاسنتر را از طریق مبدل‌های حرارتی جذب کرده و طبق طراحی، با مهندسی و قراردادها، به خانه‌ها می‌فرستند. طنز بالا این نیست که گرمای سرور می‌تواند یک اتاق را گرم کند؛ بلکه این است که این کار را به صورت تصادفی انجام دهد و آن تصادف را یک استراتژی بنامد.

سرور من از قبل شبیه این است. اولین قدم چیست؟

بک‌آپ، امشب، به جایی که سرور نباشد، و سپس یک تست بازیابی — یک بک‌آپ تست نشده، فقط یک شایعه است. دوم، وصله‌ها و آن ریبوت که از آن فرار می‌کردید، در یک بازه زمانی برنامه‌ریزی شده، تا یاد بگیرید وقتی تماشا می‌کنید چه چیزی خراب می‌شود. سوم، نقطه شکست واحد را جدا کنید: DNS و مانیتورینگ را از ماشین جدا کنید. بقیه چیزها می‌تواند منتظر یک هفته آرام‌تر بماند؛ اما این سه نمی‌توانند.