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

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

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

ما به یک معیار نیاز داریم، بنابراین از معیار خودِ صنعت استفاده می‌کنیم: PUE یا «اثربخشی مصرف انرژی»، که برابر است با کل توان مصرفی تأسیسات تقسیم بر توانی که در نهایت به تجهیزات محاسباتی می‌رسد. یک دیتاسنتر در مقیاس بزرگ (Hyperscale) عددی در حدود 1.1 دارد: تقریباً هر وات انرژی، کار مفیدی انجام می‌دهد. یک اتاق سرور سازمانی مناسب، عددی در حدود 1.5 را مدیریت می‌کند. هدف ما 4.0 یا بالاتر است؛ به این معنی که به ازای هر وات توان محاسباتی، سه وات دیگر بیهوده هدر می‌رود. ما در این متن، همان‌طور که راهنماهای جدی به پشتیبان‌گیری (Backup) ارجاع می‌دهند، مکرراً به این عدد اشاره خواهیم کرد.

انتخاب محل: گرما هدف اصلی است

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

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

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

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

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

این سرور یک نام دارد. نه یک 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 روز آسیب‌پذیری کرنل است که توسط هیچ‌کس وصله نشده است. به هر حال، ریبوت کردن اصلاً مطرح نیست؛ ریبوت همان راهی است که از طریق آن متوجه می‌شوید کدام سرویس‌ها در سال 2021 به‌صورت دستی اجرا شده‌اند و هرگز در یک unit فایل systemd نوشته نشده‌اند. هیچ‌کس به یاد نمی‌آورد کدام‌یک از آن‌ها هستند. این سرور اکنون در نمودار سازمانی، نقش یک ستون اصلی را ایفا می‌کند.

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

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

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

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

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

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

فایروال در سال 2021 به‌طور موقت برای عیب‌یابی غیرفعال شد. عیب‌یابی به پایان رسید، اما فایروال هرگز به حالت فعال بازنگشت. تمام پورت‌های روتر به سمت سرور فوروارد شده‌اند تا «بعداً در زمان صرفه‌جویی شود» و پنل مدیریت روتر با رمز عبور پیش‌فرض کارخانه از سمت WAN برای مدیریت از راه دورِ راحت، در دسترس است. هم برای شما و هم برای دیگران.

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

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

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

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

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

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

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

نظارت بر خود

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

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

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

این بخشی است که مدام آن را به تعویق می‌انداختم. هیچ‌کدام از این‌ها تخیلی نیست. سرور محبوب و غیرقابل‌جایگزین، RAID 0 با بک‌آپ‌هایی که روی همان volume قرار دارند، فایروالی که «به‌طور موقت» غیرفعال شده، کلاستر Kubernetes که فقط یک صفحه را سرویس می‌دهد، مانیتوری که خودش را مانیتور می‌کند؛ من همهٔ این‌ها را در محیط production دیده‌ام. برخی از آن‌ها را همین امسال دیده‌ام. یکی دو مورد از آن‌ها را هم در روزهای ابتدایی کارم، خودم ساخته‌ام.

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

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

FAQ

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

خیر. هر بخش از این راهنما یک الگوی ضد-بهینه (anti-pattern) مستندشده است که باعث از دست رفتن آخر هفته‌های بسیاری شده است. اگر پیکربندی فعلی شما بیش از دو بخش از این راهنما را شامل می‌شود، به آخرین سؤال در این بخش FAQ بروید. ترتیب سؤالات را رعایت کنید، چرا که این ترتیب بر اساس اولویت‌بندی بحران (triage) تنظیم شده است.

مقدار PUE مناسب در واقعیت چقدر است؟

دیتاسنترهای مقیاس بزرگ (Hyperscale) در حدود 1.1 کار می‌کنند، یک اتاق سرور سازمانی با مدیریت خوب بین 1.4 تا 1.6 است، و یک کمد بدون سیستم سرمایشی که با بخاری برقی در حال رقابت است، می‌تواند به‌راحتی از 3 فراتر رود. شما در خانه نمی‌توانید به‌طور معناداری با عدد 1.1 رقابت کنید؛ این همان استدلال اقتصادی بی‌سروصدایی است که اجارهٔ توان پردازشی از کسی که توانایی رسیدن به این اعداد را دارد، توجیه می‌کند.

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

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

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

امشب از داده‌ها نسخه پشتیبان (Backup) تهیه کنید، در مکانی که سرور نباشد؛ سپس یک بازیابی آزمایشی انجام دهید، چرا که پشتیبان تست‌نشده فقط یک شایعه است. دوم، وصله‌ها (Patches) را اعمال کنید و سروری که از ریبوت کردن آن اجتناب می‌کردید را در یک بازه زمانی برنامه‌ریزی‌شده ریبوت کنید تا متوجه شوید در حین نظارت شما چه چیزی از کار می‌افتد. سوم، نقطه شکست واحد (single point of failure) را تفکیک کنید: DNS و مانیتورینگ را از روی آن دستگاه خارج کنید. بقیه موارد می‌توانند تا یک هفته آرام‌تر صبر کنند، اما این سه مورد نمی‌توانند.