دنیا کا سب سے کم مؤثر datacenter: مکمل guide

آپ کیا بنا رہے ہیں

اس سائٹ کی ہر guide آپ کو کوئی کام درست طریقے سے کرنا سکھاتی ہے: commands درست ترتیب میں، درست نتیجے کی شکل، اور failure modes کی واضح نشاندہی۔ یہ guide مختلف ہے۔ آج ہم مکمل طور پر فرضی طور پر ایسے datacenter کا design بنائیں گے جو پیسے، بجلی اور خود پسندی سے ممکنہ طور پر سب سے کم مؤثر ہو۔

ہمیں ایک metric درکار ہے، اس لیے ہم industry کا اپنا metric استعمال کریں گے: PUE، یعنی Power Usage Effectiveness۔ یہ total facility power کو اس power سے تقسیم کرنے کا نتیجہ ہے جو حقیقت میں computing equipment تک پہنچتی ہے۔ ایک hyperscale datacenter کا PUE تقریباً 1.1 ہوتا ہے: تقریباً ہر watt مفید کام کرتا ہے۔ ایک مناسب enterprise server room کا PUE عموماً 1.5 ہوتا ہے۔ ہمارا ہدف 4.0 یا اس سے زیادہ ہے، یعنی computing کے ہر watt کے لیے مزید تین watts بے فائدہ ضائع ہوں۔ ہم اس number کا بار بار حوالہ دیں گے، بالکل اسی طرح جیسے سنجیدہ guides backups کا حوالہ دیتی ہیں۔

جگہ کا انتخاب: حرارت ہی اصل مقصد ہے

حقیقی data center میں cooling سب سے بڑا اضافی خرچ ہے، اسی لیے ہمارا data center thermodynamics کا مقابلہ اسی کے میدان میں کرے گا۔ مثالی جگہ attic ہے۔ جنوب کی سمت رخ رکھنے والی۔ بہتر یہ ہے کہ skylight ایسی جگہ ہو جہاں سے براہِ راست server پر روشنی پڑے، تاکہ machine کو اپنی waste heat کے ساتھ سورج کی heat بھی ملے؛ یہ آپ کے electricity bill اور ایک ستارے کا مشترکہ تعاون ہوگا۔

سردیوں میں cooling window کھول کر کی جائے گی۔ حقیقی data centers باہر کی ہوا استعمال کرتے ہیں۔ اس تکنیک کو free cooling کہا جاتا ہے، اور اس میں engineering، filtration اور humidity control شامل ہوتے ہیں۔ ہم اسے اتفاقاً استعمال کریں گے، ایسی window کے ذریعے جو بارش، pollen اور ہر quarter میں کم از کم ایک الجھے ہوئے پرندے کو بھی اندر آنے دے گی۔

حقیقی فن کاری کے لیے ایک air conditioner نصب کریں، پھر اس کے thermostat سے دو feet کے فاصلے پر space heater رکھیں اور اسے air conditioner's target سے دو degrees زیادہ پر set کریں۔ اب دونوں machines مسلسل، ہمیشہ، کامل اختلاف کے ساتھ چلتی رہیں گی۔ power company آپ کو Christmas پر ایک card بھیجے گی۔

ایک سرور، بڑا اور محبوب

اضافی سرور commitment کو کمزور کرتے ہیں۔ ہمارے datacenter میں بالکل ایک سرور ہے، اور یہ بہت بڑا ہے، کیونکہ 512 GB RAM والی ایک مشین infrastructure محسوس ہوتی ہے، جبکہ چار چھوٹی مشینیں صرف کاموں کی فہرست معلوم ہوتی ہیں۔

سرور کا ایک نام ہے۔ یہ hostname نہیں بلکہ نام ہے۔ عموماً Gandalf یا Odin۔ آپ Odin کو decommission نہیں کر سکتے۔ Odin پانچ سال سے up ہے:

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

یہ number باعثِ فخر ہے، اسی لیے آپ اس کا screenshot لے کر اسے post کرتے ہیں۔ یہی وجہ ہے کہ screenshot دیکھنے والا ہر attacker بھی اسے متاثر کن سمجھتا ہے: 1,847 دن کا uptime دراصل kernel vulnerabilities کے 1,847 دن ہیں، جنہیں کسی نے patch نہیں کیا۔ ویسے بھی reboot کا سوال ہی پیدا نہیں ہوتا، کیونکہ reboot سے معلوم ہو جاتا ہے کہ 2021 میں کون سی services دستی طور پر start کی گئی تھیں اور کبھی systemd unit میں درج نہیں ہوئیں۔ کسی کو یاد نہیں کہ وہ کون سی services ہیں۔ اب یہ سرور organizational chart میں load-bearing حیثیت رکھتا ہے۔

Storage: رفتار، اور ڈیٹا ضائع ہونے کے دیگر طریقے

کارکردگی بہتر بنانے کے لیے disks کو RAID 0 میں configure کیا گیا ہے۔ صفر سے مراد ان disks کی تعداد ہے جو fail ہو سکتی ہیں۔ زیادہ سے زیادہ اثر کے لیے array کو مختلف ماخذ والے storage پر stripe کریں: دو معیاری SSDs، ایک پرانا spinning disk، اور conference سے حاصل کی گئی ایک USB stick۔ array کی reliability conference stick جتنی ہی ہے، اور design بھی یہی ہے۔

Backups اسی array پر موجود backup_final_v2_REAL نامی directory کے ذریعے handle کیے جاتے ہیں۔ اس directory میں پچھلے naming scheme کا tarball موجود ہے۔ Off-site backups کی نمائندگی ایک sticky note کرتا ہے، جس پر "set up off-site backups" لکھا ہے۔ تکنیکی طور پر یہ note اس وقت off-site stored ہوتا ہے جب آپ اسے اپنے laptop کے lid پر رکھ کر گھر لے جاتے ہیں۔

درست نتیجہ کچھ یوں نظر آتا ہے: df کی رپورٹ میں 97% usage، اور اس سے نمٹنے کا plan next sprint کے لیے مقرر ہو۔

نیٹ ورکنگ: ہر چیز کی ایک ہی کڑی

DNS server خود اسی machine پر چلتا ہے۔ اس لیے جب server بند ہوتا ہے تو وہ DNS record بھی ساتھ لے جاتا ہے جس سے آپ یہ معلوم کر سکتے تھے کہ مسئلہ کیا ہے۔ اسے consolidation کہتے ہیں۔

Firewall کو 2021 میں کسی مسئلے کی debugging کے لیے عارضی طور پر disabled کیا گیا تھا۔ debugging مکمل ہو گئی، لیکن firewall دوبارہ فعال نہیں کیا گیا۔ Router کا ہر port server کو forward کیا جاتا ہے، تاکہ "بعد میں وقت بچایا جا سکے"۔ Remote management آسان بنانے کے لیے router کا admin panel WAN side سے اس کے factory password کے ساتھ قابل رسائی ہے۔ آپ کا بھی، اور دوسروں کا بھی۔

Server حالیہ دنوں میں غیر معمولی طور پر گرم چل رہا ہے، حتیٰ کہ attic کے معیار کے مطابق بھی، اور top دکھاتا ہے کہ سب سے مصروف process کا نام xmrig ہے۔ ہم فرض کرتے ہیں کہ یہ وہ monitoring tool ہے جسے ہم استعمال کر رہے ہیں۔ ہم نے اسے install نہیں کیا تھا۔ Ports forward کیے جانے کے کچھ ہی دیر بعد یہ خود ظاہر ہو گیا، جسے ہم اس بات کی علامت سمجھتے ہیں کہ ecosystem اچھی طرح چل رہا ہے۔ یہ چوبیس گھنٹے monitoring کرتا ہے۔

Power صارفین کے لیے بنائی گئی power strips کی ایک زنجیر سے آتی ہے، جس کی مجموعی لمبائی breaker panel تک پیدل پہنچنے کے فاصلے سے بھی زیادہ ہے۔ ایک لحاظ سے یہ مؤثر انتظام ہے، کیونکہ آپ breaker panel پر بار بار جائیں گے۔

پیچیدگی کے ذریعے redundancy

جہاں redundancy اہم تھی وہاں اسے مسترد کرنے کے بعد، اب اسے وہاں شامل کیا گیا ہے جہاں اس کی کوئی ضرورت نہیں۔ کمپنی کا homepage، جو صرف ایک static HTML فائل ہے، بارہ node پر مشتمل Kubernetes cluster کے ذریعے serve کیا جاتا ہے۔ اس سے وہ چیز حاصل ہوتی ہے جسے انجینئرز resume-driven architecture کہتے ہیں: صفحہ انہی چالیس milliseconds میں load ہوتا ہے جن میں nginx اسے deliver کر دیتا، لیکن اب یہ ایسے طریقوں سے fail ہو سکتا ہے جن کے لیے consultant درکار ہوتا ہے۔

Isolation کے لیے cluster خود ایک virtual machine کے اندر ایک virtual machine کے اندر ایک virtual machine میں چلتا ہے۔ ہر layer security میں اضافہ کرتی ہے، بالکل اسی طرح جیسے turducken کی ہر layer میں ایک اور پرندہ شامل ہوتا ہے۔ Contact form نو microservices پر مشتمل ہے۔ ان میں سے دو کو کبھی invoke نہیں کیا گیا۔ ان میں سے ایک load-bearing ہے، اور کسی کو معلوم نہیں کہ وہ کون سا ہے۔

بطور سروس حرارت

ایک جدید server بجلی کو computation اور heat میں تبدیل کرتا ہے، اور ہمارا مقصد دوسرے output کو زیادہ سے زیادہ کرنا ہے۔ GPU کے بغیر media server اس کی روایتی مثال ہے: ایک 4K stream کو CPU کے ذریعے transcode کرنے سے سولہ cores مسلسل مصروف ہو سکتے ہیں اور ایک چھوٹا bedroom گرم ہو سکتا ہے؛ یہ ایسا space heater ہے جو movies بھی چلاتا ہے۔ زیادہ پرجوش operator CPU پر ایک بڑے language model کو چلانے کی طرف بڑھتا ہے؛ یہ 70-billion-parameter والا space heater ہے جس کے ساتھ API موجود ہے اور جو tokens ایسی رفتار سے پیدا کرتا ہے جسے ناپنے کے لیے موسمی پیمانہ زیادہ موزوں ہے۔

مانیٹر خود کو مانیٹر کرتا ہے

Observability اہم ہے، اس لیے ہم اسی سرور پر self-hosted uptime monitor deploy کرتے ہیں جس کی یہ نگرانی کرتا ہے۔ جب Odin بند ہو جاتا ہے تو مانیٹر بھی اسی کے ساتھ بند ہو جاتا ہے، اور یہاں نفاست کا پہلو یہ ہے: کوئی alert نہیں آتا۔ کوئی alert نہ آنے کا مطلب ہے کہ کوئی incident نہیں ہوا۔ کوئی incident نہ ہونے کا مطلب ہے کہ ریکارڈ کے مطابق uptime مکمل ہے۔ ماہانہ رپورٹ اس سے بہتر کبھی نظر نہیں آئی۔

مکمل وضاحت کے لیے، alert emails ایسے mail server کے ذریعے relay کی جاتی ہیں جو Odin پر بھی چل رہا ہے۔ اس طرح alerting pipeline مکمل طور پر self-contained ہے، بالکل اس طرح جیسے کوئی سانپ اپنی دم نگل کر پوری طرح سیر ہو جاتا ہے۔

غیر آرام دہ حقیقت

یہ وہ حصہ ہے جسے میں مسلسل مؤخر کرتا رہا ہوں۔ اس میں کچھ بھی افسانوی نہیں ہے۔ ایسا server جس کے بغیر کام نہ چلنے کا گمان ہو، اسی volume پر backups کے ساتھ RAID 0، "عارضی طور پر" disabled firewall، صرف ایک page پیش کرنے والا Kubernetes cluster، اور خود کو monitor کرنے والا monitor، یہ سب میں نے production میں دیکھے ہیں۔ ان میں سے کچھ میں نے اسی سال دیکھے ہیں۔ اپنے ابتدائی دور میں، ان میں سے ایک یا دو میں نے خود بنائے تھے۔

حقیقی efficiency کی شکل غیر دلچسپ ہوتی ہے۔ اسی لیے عین وقت پر بحث میں ہار جاتی ہے اور ایک دہائی کے دوران جیت جاتی ہے: ایسا PUE جس کے بارے میں آپ کبھی نہیں سوچتے، کیونکہ کسی اور نے اسے engineer کیا ہے۔ Machines کو مالک کے self-image کے مطابق نہیں، بلکہ ان کے workload کے مطابق size کیا گیا ہو۔ Blast radius پر دھماکے سے پہلے غور کیا گیا ہو۔ Backups کو باقاعدہ schedule کے مطابق restore کر کے test کیا جاتا ہو، calendar reminder کے ساتھ اور کسی heroism کے بغیر۔ Redundancy سادہ اور غیر دلچسپ ہو؛ ہر بار، اور ہر اس failure میں جس کے لیے مجھے page کیا گیا، ایک شاندار چیز کے بجائے سستی چیز کی دو units زیادہ قابلِ اعتماد ثابت ہوئی ہیں۔

اور سب سے efficient datacenter وہ ہے جسے آپ چلاتے ہی نہیں۔ VPS power، cooling، redundancy اور رات 3 بجے ہونے والی hardware failures کی ذمہ داری ایسے لوگوں کو دے دیتا ہے جو یہ کام بڑے پیمانے پر اور غیر نمایاں انداز میں کرتے ہیں۔ Infrastructure کے لیے اس سے بڑا compliment ممکن نہیں۔ اس کے بعد واقعی دلچسپ حصہ آپ کے لیے باقی رہتا ہے، یعنی اپنی services اس کے اوپر چلانا، ایسی machine پر جسے کھونے کا خرچ آپ برداشت کر سکتے ہوں۔ تجربات کے لیے آپ کو ہمیشہ اسی قسم کی machine استعمال کرنی چاہیے۔

FAQ

کیا مجھے واقعی یہ سب کرنا چاہیے؟

نہیں۔ اس رہنما کے ہر حصے میں ایک documented anti-pattern بیان کیا گیا ہے، جس نے بے شمار weekends ضائع کیے ہیں۔ اگر آپ کا موجودہ setup دو سے زیادہ sections سے مشابہ ہے تو اسی ترتیب سے اس FAQ کے آخری سوال پر جائیں، کیونکہ یہی ترتیب triage ہے۔

دراصل اچھا PUE کیا ہوتا ہے؟

Hyperscale datacenters عموماً 1.1 کے قریب رہتے ہیں، اچھی طرح چلنے والا enterprise room 1.4 سے 1.6 تک رہتا ہے، جبکہ بغیر cooling کے ایسا closet جہاں space heater سے بھی مسئلہ ہو، واقعی 3 سے تجاوز کر سکتا ہے۔ آپ گھر میں 1.1 کا بامعنی مقابلہ نہیں کر سکتے۔ یہی اس بات کی خاموش معاشی دلیل ہے کہ compute ایسے فراہم کنندہ سے کرائے پر لیا جائے جو یہ کام کر سکتا ہو۔

کیا servers سے عمارت کو گرم کرنا واقعی ممکن ہے؟

ہاں، اگر یہ مناسب طریقے سے کیا جائے۔ کئی ممالک میں district-heating projects heat exchangers کے ذریعے datacenter کی waste heat حاصل کرتے ہیں اور engineering اور contracts کے تحت اسے گھروں تک pipe کرتے ہیں۔ اوپر کی طنز اس بات پر نہیں کہ server heat کسی کمرے کو گرم کر سکتی ہے؛ مسئلہ یہ ہے کہ یہ کام حادثاتی طور پر کیا جائے اور اس حادثے کو strategy قرار دیا جائے۔

میرا server پہلے ہی ایسا دکھائی دیتا ہے۔ مجھے سب سے پہلے کیا کرنا چاہیے؟

آج رات backups بنائیں، ایسی جگہ پر جو server نہ ہو، اور پھر test restore کریں۔ غیر آزمودہ backup محض ایک افواہ ہے۔ دوسرا قدم patches نصب کرنا اور وہ reboot کرنا ہے جس سے آپ گریز کرتے رہے ہیں۔ یہ کام ایک planned window میں کریں، تاکہ آپ نگرانی کرتے ہوئے معلوم کر سکیں کہ کیا خراب ہوتا ہے۔ تیسرا قدم single point of failure ختم کرنا ہے: DNS اور monitoring کو اس box سے منتقل کریں۔ باقی سب کچھ زیادہ پرسکون ہفتے تک مؤخر کیا جا سکتا ہے؛ یہ تین کام نہیں۔