Railway की अपनी data center बनाने की कहानी
(blog.railway.com)- Railway ने माना कि GCP-आधारित compute कीमत, support और feature development को सीमित कर रहा है, इसलिए उसने अधिक प्रत्यक्ष नियंत्रण वाली physical infrastructure Railway Metal शुरू की
- जनवरी 2024 में शुरुआत के बाद पहला server जोड़ने में 5 महीने लगे, और user workloads डालने में 3 महीने और लगे; 9 महीने बाद कैलिफ़ोर्निया का पहला site चालू हुआ
- space lease से भी बड़ा प्रतिबंध power और cooling था, और Railway ने Greenfield या rack-unit lease के बजाय Cage Colocation चुना
- network में हर region के लिए कम से कम 2 ISP, पूरा internet routing table, IP prefix के अनुसार route selection, और कई zone डिज़ाइन शामिल हैं, ताकि single data center failure का सामना किया जा सके
- rack layout, cable documentation, PDU, reverse airflow switch, Redfish API, PXE, FRR, और SONiC तक सब कुछ खुद संभालना पड़ता है; अपना cloud बनाना Terraform deploy करने से ज़्यादा घर बनाने जैसा काम है
GCP से Railway Metal पर जाने की वजह
- Railway का compute शुरू से Google Cloud Platform पर बना था
- GCP शुरुआती growth में मददगार था, लेकिन operations बढ़ने के साथ customers को मनचाहा platform देने में सीमाएँ सामने आने लगीं
- hyperscaler-आधारित operations सीधे Railway के pricing, service level, और feature development की सीमा तय कर रहे थे
- egress fee का असर pricing पर पड़ता था
- ऊपर की infrastructure में problem होने पर भी root cause समझ पाना दुर्लभ था
- उनका मानना था कि सालाना कई million dollar खर्च करने पर भी support level, 100 dollar खर्च करने वाले से बहुत अलग नहीं था
- इसके जवाब में Railway ने 2024 में Railway Metal project शुरू किया
- 9 महीने बाद कैलिफ़ोर्निया का पहला site चालू किया
- cage के अंदर fibre cable से लेकर ISP contract तक, design, specification definition, और installation खुद किया
- साथ ही 3 और data center region चालू करने पर काम चल रहा है
पहली जगह का चुनाव: data center cage
- Railway Metal project जनवरी 2024 में शुरू हुआ, और पहला server connect करने में 5 महीने लगे
- user workloads को hardware पर चलाने लायक मानने में 3 महीने और लगे
- अपनी infrastructure के लिए server रखने की जगह, stable power, और पर्याप्त cooling चाहिए थी
- बड़े तौर पर तीन विकल्प थे
- Greenfield buildout: data center खरीदना या lease पर लेना
- Cage Colocation: operator के data center के भीतर mesh wall से घिरी dedicated space लेना
- Rack colocation: colocation data center में individual rack या rack का हिस्सा lease पर लेना
- Railway ने Cage Colocation चुना ताकि उसे चार दीवारें, secure door, और बाकी सब कुछ खुद design करने के लिए खाली space मिल सके
- space की लागत खुद बहुत बड़ी नहीं थी, लेकिन power और उससे जुड़ी cooling की लागत सबसे अधिक थी
- region के अनुसार kW की cost में बड़ा अंतर होता है
- अमेरिका के west coast में यह Singapore की तुलना में आधे से भी कम हो सकती है
- power का भुगतान actual usage से अलग, on-demand availability सुनिश्चित करने के लिए monthly commit के रूप में किया जाता है
power design और PDU
- Railway ने GCP में इस्तेमाल हो रही capacity के हिसाब से target vCPU count, RAM GB, और NVMe TB पहले तय किए
- इन्हीं आँकड़ों के आधार पर server और CPU चुने गए
- मुख्य variable था तय power consumption के भीतर मनचाही compute density भरना, यानी power density
- power calculation सिर्फ watt जोड़ने से पूरी नहीं होती, खासकर 3-phase power में यह और जटिल हो जाती है
- Cloudflare का three-phase power aur PDU parichay इस विषय को समझाता है
- data center में power सबसे महत्वपूर्ण resource है, और power outage का recovery time बहुत लंबा हो सकता है
- हर rack में 2 पूरी तरह independent power feed चाहिए
- सामान्य स्थिति में दोनों feed load बाँटते हैं
- एक feed बंद हो जाए तब भी सिस्टम टिकना चाहिए
- server तक power पहुँचाने के लिए Power Distribution Unit चाहिए
- basic PDU लगभग एक बड़े power strip जैसा होता है
- Railway जिन PDU का उपयोग करता है, उनमें individual socket control और metering संभव है
- हर PDU को network के जरिए access किया जा सकता है, और individual socket को remotely measure और control किया जा सकता है
network: ISP, routing, और region-specific path
- cloud machine अकेले नहीं होती, इसलिए network की भूमिका केंद्रीय है
- Railway ने कम latency के लिए बाहरी दुनिया से मज़बूती से जुड़ी data center facility खोजी
- उनकी पसंद की शर्तें थीं
- Tier 1 ISP के साथ on-network होना
- Internet Exchange का हिस्सा होना
- पास के दूसरे data center तक जोड़ने वाली fibre उपलब्ध होना
- Railway पर deploy की गई applications कई तरह के endpoint से बात करती हैं
- Sydney का residential internet user
- अमेरिका में AWS server पर hosted API
- कम latency और कम bandwidth cost के लिए Railway ने use case के अनुसार optimized कई internet provider के साथ contract किए
- ISP का चुनाव target region में network maturity के आधार पर किया गया
- गलत ISP के साथ काम करने पर किसी खास target market तक पहुँचने में extra network hop जुड़ सकता है, जिससे latency बढ़ती है
- सबसे खराब स्थिति में network path बहुत जटिल और उलझा हुआ हो सकता है
- हर region में local footprint के आधार पर कम से कम 2 अलग network चुने गए
- connect होने के बाद हर ISP से पूरा internet routing table लिया जाता है, और network switch पर उन्हें मिलाकर IP prefix के हिसाब से best route तय किया जाता है
- अगर Australia का user Singapore में deploy किए गए app तक पहुँचता है, तो packet शायद Telstra को दिया जाएगा
- वही app अगर Japan के user या server को packet भेजे, तो वह शायद PCCW को जाएगा
- peering information सार्वजनिक है, और bgp.tools पर network interconnection देखे जा सकते हैं
- redundancy के लिए हर region में कई zone बनाए जाते हैं, और sites के बीच interconnect भी scaling में महत्वपूर्ण है
- dark fiber या wavelength service जैसे विकल्पों की जाँच की गई
- लक्ष्य यह है कि app को फर्क न पड़े कि database उसी कमरे में है या 4 block दूर पड़ोसी building में
- यह design individual data center failure के प्रति resilience बढ़ाने के लिए है
rack, aisle, cooling, और cable path
- data center में racks को पंक्तियों में रखा जाता है, और racks के बीच के aisles को airflow के लिए इस्तेमाल किया जाता है
- Cold Aisle में facility से ठंडी हवा आती है, server इस हवा को अंदर खींचते हैं और पीछे की ओर Hot Aisle में बाहर निकालते हैं
- efficiency बढ़ाने के लिए Cold Aisle और Hot Aisle की हवा आपस में नहीं मिलनी चाहिए
- rack 19-inch width वाले equipment के लिए होते हैं, लेकिन उनकी height, width, और depth को equipment और cable requirements के अनुसार चुना जा सकता है
- ज़्यादातर server equipment maintenance के लिए rails पर आगे खींचे जा सकते हैं, इसलिए cage dimensions में इसकी जगह होनी चाहिए
- cables और cable management के लिए भी जगह चाहिए, इसलिए rack को कितनी घनत्व से भरना है और cage में कितने rack रखने हैं, इसके बीच trade-off बनता है
- Railway के अनुभव में असली space से ज़्यादा बार power और cooling सीमित कारक बने
- नए site पर airflow बेहतर करने के लिए और cables को exhaust path से हटाने के लिए 800mm चौड़े racks चुने गए
- rack के अलावा power और data पहुँचाने के लिए overhead infrastructure और trays भी चाहिए
- cage के किनारे से हर rack तक fibre route की जाती है
- racks के बीच भी cable route की जाती है
- ऐसे items कभी-कभी data center operator cage quote में शामिल करते हैं
- Railway में हर rack पर switch-to-server fibre cable density अधिक होने की वजह से, उन्होंने ऐसे reverse airflow switch खरीदे जिनके ports rack के पीछे की ओर होते हैं
- यानी ऐसे switch जो network port वाली दिशा में exhaust करते हैं
- cable tray को इस तरह मिलाया गया कि सारी cabling rack के एक ही side से हो
- rack के आगे-पीछे cable के zigzag जाने की स्थिति से बचा गया
installation documents और rack-and-stack
- Railway ने शुरुआत में खुद cabling करने की कोशिश की, लेकिन नतीजे एकसमान नहीं थे, इसलिए सही installation के लिए experts लगाए गए
- installation experts को क्या कहाँ लगाना है, यह समझाने के लिए एक व्यापक documentation package चाहिए था
- आम तौर पर दो तरह के documents होते हैं
- Cabling matrix: हर cable के दोनों सिरों पर equipment location, port, cable spec, fibre type, length आदि को define करता है
- Rack elevation: rack के अंदर हर equipment की position और orientation को दृश्य रूप में दिखाता है
- Railway के हर installation phase में 60 से अधिक equipment, 300 से अधिक individual cables, और दर्जनों detail शामिल थीं
- installation और commissioning की बुनियाद बनने वाले written spec और spreadsheet हाथ से बनाए गए
- material site पर पहुँचने के बाद, पूरी installation खत्म करने में लगभग 6~14 दिन लगे
- बाद में Railway ने build specification generation को automate करने के लिए internal tool बनाया
- data center cage बनाना सामान्य software, DevOps, या Terraform stack deploy करने जैसा नहीं, बल्कि घर बनाने के अधिक करीब है
- data center facility, contractor, और vendor के अनुसार, एक ही organization के भीतर भी तरीक़े थोड़े अलग होते हैं, इसलिए operations में बहुत बारीक ध्यान चाहिए
site पर मिले अपवाद और physical समस्याएँ
- एक site पर PDU उल्टा install था, और power नीचे से आती थी, जिससे planning के socket number उलट गए
- Amsterdam site पर dedicated demarcation point की जगह external fibre link सीधे rack के अंदर वाले box में आती थी
- कुछ facility में power socket phase-to-neutral तरीके से wired थे, जबकि दूसरे sites में phase-to-phase तरीके से
- एक मामले में contractor को पता नहीं था कि network equipment reverse airflow है, इसलिए वह उसे उल्टी दिशा में mount करने लगा और उसे लगा कि data cable छोटी पड़ रही है
- कुछ cables पर link up न होने की वजह fibre polarity error निकली, और Railway ने तभी “rolling fibre cables” के बारे में सीखा
- इसमें LC connector का plug निकालकर दोनों ओर बदल दिया जाता है
- एक vendor के लगभग 24 PDU में socket defect था, जिससे power plug ठीक से fit नहीं हो रहा था, और ज़ोर लगाने पर भी समस्या हल नहीं हुई
physical installation के बाद का software काम
- hardware अपनी जगह लगने के बाद काम ज़्यादा परिचित software domain में चला जाता है
- ज़रूरी काम इस प्रकार हैं
- BGP configuration
- OS installation
- monitoring setup
- network equipment configuration
- router configuration लिखना
- RIR, यानी regional internet registry records को update करना
- server और PDU के dedicated controller तक पहुँचने के लिए Redfish APIs का उपयोग किया जाता है
- server को network से boot कराने के लिए PXE का उपयोग होता है
- Railway का network design FRR और SONiC चलाने वाले whitebox network switch का उपयोग करता है
- इस design से Railway control plane के साथ गहराई से integrated L3-only software-driven network बनाया गया
- पिछले कुछ महीनों में Railway ने Railyard और MetalCP नाम के नए software tools बनाए
- नए cage design करना
- cable tracking और visualization
- server OS install करना
- और server को internet से जोड़ने की प्रक्रिया तक button-click अनुभव देना — यही इन tools का काम है
- अगली पोस्ट में बताया जाएगा कि कमरे भर servers के समूह को काम करने वाले Railway zone में कैसे बदला जाता है
1 टिप्पणियां
Hacker News की राय
मेरे अनुभव और ऐसे लेखों को देखकर लगता है कि Google को ग्राहक होना पसंद नहीं है
ऐसा लगता है कि किसी ने तय किया कि “public cloud करना ही है”, इसलिए उन्होंने बना तो दिया, लेकिन ग्राहकों को 3 मीटर लंबी छड़ी से दूर धकेलना चाहते हैं
मुझे 100% यकीन है कि AWS account manager जरूरत पड़ने पर कीचड़ में भी आपके साथ लोटने वाला इंसान होगा। संकट में कहो तो फर्श पर भी आपके साथ सो जाएगा
इसके उलट Google Cloud के लोगों को देखकर दुख होता है। क्योंकि दिखता है कि वे भी Google के अंदर हमसे कम प्यार और कम समर्थन पाते हैं। किसी को अपनी ही कंपनी को ठीक से बेचने और service देने के लिए मनाते देखना दुखद है, और लगता है जैसे उन्हें fail होने के लिए ही set up किया गया है
Microsoft वाले लोग bulletproof जैसे मजबूत हैं, sales भी अच्छा करते हैं, service भी अच्छी देते हैं, मेरी जेब से सारा पैसा निचोड़ लेते हैं और फिर भी मुझे मरते दम तक यह यकीन दिला देते हैं कि यह मेरे लिए अच्छी बात है। बस cloud बहुत अजीब-सा… कुछ है
Railway का bare metal पर जाना, करीब 15 साल करने के अनुभव से कहूं तो मैं कभी, कभी, कभी वापस नहीं जाना चाहूंगा। उसकी कीमत नहीं बनती। लेकिन शायद खुद भुगतकर ही पता चलता है, और रास्ता ऐसा ही होता है
जल्द ही उन्हें समझ आ जाएगा कि Google आखिर इतनी परेशानी क्यों झेलता है। हालांकि, अगर Borg या artificial brain बनाने के बजाय लोगों को services बेचने की इच्छा सच में बहुत मजबूत है, तो वे Google से 100 गुना बेहतर कर सकते हैं
फिर भी नहीं लगता कि वह कीचड़ में साथ लोटेगा, और यही थोड़ा हैरान करता है। सोचता हूं, कीचड़ में साथ जाने वाले level तक पहुंचने के लिए आखिर कितना खर्च करना पड़ता है
पूरी cloud service ऐसी लगती है जैसे cloud computing के बारे में कुछ न जानने वाले, सिर्फ “bare metal server rental” समझने वाले किसी व्यक्ति ने इसे design किया हो। यह cloud computing तो है, लेकिन cloud computing की अवधारणा को ही तोड़ने वाले तरीके से
GCP command-line tool
gcloudभी ज्यादा अच्छी तरह design किया हुआ लगता हैतब हम महीनों का upfront काम बचा सकते थे
निजी अनुभव में, Google Cloud support ने 3 लोगों की छोटी team और बहुत कम खर्च वाली स्थिति में भी हमारे साथ काफी अच्छा व्यवहार किया, और दूसरी company में Microsoft ने भी बहुत अच्छा व्यवहार किया। हालांकि उस समय खर्च का scale शायद data center power grid monitoring से भी track किया जा सकता था
इसके उलट AWS ने feature के बारे में झूठ बोला, और आखिर तक जवाब भी नहीं दिया
senior management के साथ जरूरी multimillion-dollar AWS contract पर बात करने वाले account managers को शायद अच्छी तरह पता होता है कि उस management से कैसे बात करनी है
लेकिन जब असल में दूसरों के लिए product develop और deliver करने की बारी आई, तो हमें धूल में अकेला छोड़ दिया गया
और भी मजेदार बात यह थी कि जिस feature के बारे में झूठ बोला गया था, उसे end-user experience को बेहद शानदार बनाने के लिए core feature बताकर बेचा गया था
support ticket पर reply किया, लेकिन कोई response नहीं आया, और दो AWS contacts को email किया, लेकिन वहां से भी कोई जवाब नहीं मिला
पुराने Rackspace वाले दिन याद आ गए। सच में युद्ध जैसे कई वाकये हुए थे
EMC के लोग टेस्टिंग के लिए storage उपकरण लगाने आए थे, लेकिन आपस में पैर उलझ गए और कॉमेडी की तरह पूरा का पूरा एक server rack गिरा दिया। जाहिर है, contract उन्हें नहीं मिला
एक truck driver को heart attack आया, और accident की वजह से DFW data center offline हो गया। ऐसी स्थिति रोकने के लिए bollards थे, लेकिन उनमें अभी cement भरा नहीं गया था
एक समय तो सड़क के उस पार दूसरी building तक laser से bandwidth भेजकर temporary connection बनाया गया था
एक दिन server सचमुच जलना शुरू हो गया, तो हमने खिड़की तोड़ी और box fans खरीद लाए
Data center engineering शुरुआती दिनों की तुलना में काफी आगे बढ़ चुकी है। उस समय Facebook के साथ OpenCompute Project पर काम किया था, और उस दौर के हिसाब से उसमें बहुत आगे की infrastructure concepts थीं
मुख्य microwave link data link layer की गहराई में intermittent packet errors के साथ बार-बार कटता रहता था। जांच करने पर पता चला कि सड़क के पार पेड़ पर पत्ते आ गए थे, और शाखाएं हिलते हुए हमारी building के equipment की line of sight में आ रही थीं। एक सीढ़ी, एक आरी और 10 मिनट में connection बहाल हो गया
Data center से बाहर जाने वाला main BGP router लगातार reboot हो रहा था। कोई redundant equipment नहीं था। देखा तो data center का temperature बहुत ज्यादा था और cooling बेहद खराब थी, इसलिए intake fan की तरफ हवा का temperature 60°C से ऊपर था। अस्थायी तौर पर एक fan उसकी ओर लगा दिया
कुछ हफ्ते बाद दूसरे कमरे का air conditioner भी जवाब दे गया और Nortel DMS-100 के ऊपर पानी फेंकने लगा। यह अपने switch वाला dial-up ISP था। लगा कि पानी में बिजली हो सकती है, इसलिए पोंछने में मदद करने का मन नहीं था, लेकिन मजबूरी थी
उसके बाद मैंने एक छोटे, दूरदराज island पर भी काम किया, जहां मुख्य internet link GS satellite के जरिए 1MB/s link था और ping 500ms से ज्यादा था। स्थानीय लोग 9600 baud rated microwave telephone network पर dial-up करते थे, लेकिन न जाने कैसे 56k modem काम कर जाता था
एक दिन पता चला कि Solaris box में एक अहम
.soगायब है, और न local backup था, न installation media। UK में एक दोस्त को call करके FTP server पर copy upload करने को कहा और उस box को फिर से online कियाकुछ साल बाद Manchester के Oxford Road पर, जो उस समय Europe का सबसे व्यस्त bus route था, उसके ऊपर laser link लगाकर office और university campus को जोड़ा भी था। मजेदार दिन थे
यह सब बेहद मजेदार था, लेकिन सच कहूं तो खुशी है कि अब मैं लगभग सिर्फ software ही करता हूं
server सचमुच आग में न भी जला हो, फिर भी खिड़कियां खोलकर fan इस्तेमाल करने वाली घटना जनवरी 2024 में Chicago के Equinix CH1 data center में भी हुई थी। Azure ExpressRoute down हो गया था
सुना कि बहुत ज्यादा ठंड हो गई थी और CRAC संभाल नहीं पाया। कहते हैं कि पर्याप्त ठंडा बनाए रखने के लिए सभी दरवाजे और खिड़कियां खोल दी गई थीं, लेकिन आखिरकार नाकामी मिली। CRAC गया तो server भी साथ जाते हैं
वह switch जरूर शापित था। उसी सप्ताह बाद में उसी equipment में spanning tree configuration error हुआ, LINX कई घंटों के लिए रुक गया, और UK ISP peering का आधा हिस्सा अस्थायी अफरा-तफरी में पड़ गया। उस project से जुड़े बाकी लोग भी 2 साल के भीतर चल बसे
कुछ साल बाद facility का दौरा किया, तो उसके नीचे floor पर जला हुआ शव अभी भी पड़ा था
लेख में आया हिस्सा “सालाना लाखों dollars खर्च करने पर भी उतना ही support मिलता है जितना 100 dollar खर्च करने वाले को” चुभता है। Google के लिए यह काफी बड़ी समस्या है
यह लेख खास तौर पर इसलिए दिलचस्प था क्योंकि Blekko infrastructure बनाते समय हमने भी ऐसी ही adventures की थीं
Blekko जैसी कंपनियों में, जहां racks के बीच का traffic—यानी internet से आने-जाने वाले traffic से ज्यादा east-west traffic होता है—यह जरूरी था कि physically साथ रखी services को दूसरे servers के साथ bandwidth के लिए compete न करना पड़े। और SoftLayer, यानी IBM के dependent cloud में ऐसे special case के लिए पैसा देने की तुलना में यह काफी किफायती था
कुछ काफी शानदार कंपनियां भी हैं जो cold aisle को cover करने वाले enclosures बनाती हैं। मूल रूप से वे सुनिश्चित करती हैं कि floor से आने वाली सारी ठंडी हवा servers के पीछे जाए और कहीं और leak न हो। वे side से कम ठंडी हवा को servers में खिंचने से भी रोकती हैं
Data center की HVAC CRAC capacity calculation भी दिलचस्प है। पहले colocation facility में हमारे cage के बगल की floor area तक expand करने का right of first refusal था, लेकिन जब सच में expand करने का समय आया, तो facility में cooling capacity बची ही नहीं थी, इसलिए उसका कोई मतलब नहीं रहा
ऐसी प्रक्रिया करके देखने के बाद 0xide solution कहीं बेहतर समझ आएगा
इसी तरह dominant company बनाई जा सकती है। hyperscaler में फंसा देने वाली रोती-धोती conventional wisdom को ignore करना अच्छा किया
अगर आप infrastructure company हैं, तो जो bare metal बेचते हैं, उसे खुद own करना चाहिए। नहीं तो आप सिर्फ cloud middleman हैं, और कभी भी $0 egress cost वाले bare metal competitor से price में पिछड़ने का risk रहता है
Colocation और peering से egress cost $0 बनाई जा सकती है, इसलिए Cloudflare free plan दे पाता है, और कोई नया entrant cloud services resell करके Cloudflare से compete नहीं कर सकता
दरअसल hyperscalers के लिए bandwidth overcharge सिर्फ revenue source नहीं, बल्कि moat है। यह AWS के ऊपर अगला AWS बनाना असंभव बनाता है, और IaaS के ऊपर “PaaS” नाम का पूरी तरह नया और रणनीतिक रूप से कमजोर market segment पैदा करता है
इससे हम वह cost आधी कर सकते हैं, storage cost भी घटा सकते हैं, और “per seat” pricing भी खत्म कर सकते हैं
सच में उत्साहित हूं
काफ़ी अच्छी पोस्ट है। एक बात जो दिमाग में आती है, वह यह कि rack management के लिए internal tool खुद क्यों बनाया गया। NetBox तो पहले से है
NetBox शानदार है, और 2000 के दशक के मध्य में जब मैं 50 से ज़्यादा racks manage कर रहा था, तब काश यह होता
https://github.com/netbox-community/netbox
लेकिन हमारा बनाया tool, Railyard, इसलिए अच्छी तरह fit बैठता है क्योंकि यह हमारे पूरे software, hardware और orchestration stack के साथ गहराई से integrated है
open source tools की समस्या यह है कि वे बहुत generic होते हैं। समस्या हल करने के बजाय आप समस्या को उस tool के data model के हिसाब से मोड़ने लगते हैं
आखिरकार संभावना है कि हम इस tool को Railway में ही integrate कर देंगे। अगर आप on-premises जाना चाहते हैं, तो button click से hardware design, commissioning, deployment और developer experience तक मिल जाए—कुछ वैसा जैसा Oxide कर रहा है, लेकिन उल्टी दिशा से approach करते हुए
https://github.com/netbox-community/netbox/issues?q=is%3Aiss...
NetBox “network infrastructure का source of truth” बनना चाहता है
हर situation में ज़रूरी चीज़ें अलग होती हैं, लेकिन अगर NetBox ने कुछ items के लिए यह insist न किया होता कि कोई दूसरा system truth नहीं हो सकता, और central repository को लक्ष्य बनाया होता, तो कहानी अलग हो सकती थी
हमने सीखा है कि complexity और control को centralize करने की कोशिश काम नहीं करती। Clinger-Cohen Act पास होने के तुरंत बाद भी यह लगभग साफ हो गया था, और अब ITIL और TOGAF भी इसे साफ तौर पर address करते हैं। अगले कुछ वर्षों में consultants इस point को खूब target करेंगे
state खोजने का एक central consistent तरीका चाहिए। ताकि authoritative information कहाँ ढूंढनी है, इस पर सवाल न रहे
लेकिन scale और growth के लिए, या नए बदलावों के साथ adapt करने के लिए, ऐसे centralized god box जैसे prescriptive systems से बचना चाहिए
यह इस्तेमाल करने में बहुत rewarding software नहीं है
यह आम “हमें X चाहिए और Y, X करता है” वाला मामला है, जिसमें यह ignore कर दिया जाता है कि Y, Z, M, Q भी करता है और बर्तन भी धोता है—और हमें उनकी ज़रूरत नहीं है
कभी-कभी सिर्फ वही बनाना जो आपको चाहिए, सबसे आसान solution होता है। खासकर जब आपकी ज़रूरत database के सामने CRUD की हो
असल में यह सिर्फ scope बढ़ाने की बात है। NetBox अच्छा starting point है, अगर आप वहीं से शुरू कर रहे हैं और system को उसके आसपास fit करने को तैयार हैं
लेकिन अगर आपके पास पहले से system है, या आपको कुछ ऐसा करना है जो NetBox logic में fit नहीं बैठता, तो मौजूदा system को expand करना बेहतर होने की संभावना ज़्यादा है
इस case में Railway को racks, IP addresses और physical servers से कहीं ज़्यादा extra information का ध्यान रखना पड़ता है
मैंने एक बड़ी tech company में equipment repair automation पर काम किया था। Repair को कम आंका जाता है, लेकिन मेरे हिसाब से यह संभालने में सबसे मुश्किल कामों में से एक है
AWS पर चलाते समय आप खराब hardware की लगभग चिंता नहीं करते। आम तौर पर वह अपने आप repair हो जाता है
खुद operate करने पर वह luxury नहीं होती। spare parts, repair करने वाले technicians, hosts से workload हटाने और फिर वापस डालने की process, test suite, hardware monitoring tools, और ऐसी 1001 और चीज़ें चाहिए होती हैं
छोटे scale पर इनमें से कुछ को जैसे-तैसे टाला जा सकता है, लेकिन आखिर में ये आपको पकड़ ही लेंगी। और यह तो सिर्फ servers की बात है
network equipment के अपने अलग मज़ेदार problem set हैं, और fail होने पर पूरा rack down कर सकता है। peak load के दौरान colocation provider power नहीं खोएगा, इस पर आप कितना भरोसा कर सकते हैं? उम्मीद है आप ऐसी स्थितियों के लिए disaster recovery drills करेंगे
इस team को शुभकामनाएँ। मज़ेदार लग रहा है
career के कुछ दिन याद आ गए। 2003~2010 के बीच हमें tens of thousands servers deploy करने पड़े और data centers के बारे में काफ़ी दिलचस्प चीज़ें सीखीं
cable management और standardization बेहद महत्वपूर्ण थे। खराब practices के साथ काम नहीं चल सकता था
जहाँ हर हफ्ते सैकड़ों servers deploy होते थे, वहाँ अगर server किसी main cluster से अलग होता, तो operator के पास चुनने के लिए menu होता था। मूल रूप से chassis के 2 types थे: 2U large-capacity disk server या 1U pizza box। disks में 9/36/146GB SCSI में से चुन सकते थे
सभी same processor के dual-processor थे, और rack के bottom में लगभग 10 2U boxes, बाकी में 20 से ज़्यादा 1U boxes भरते थे
अगर मेरी याद सही है, तो power pricing बहुत अच्छी मिली थी, शायद इसलिए कि हमने cage के अंदर facility racks इस्तेमाल किए थे। लगता है उन racks को इस्तेमाल करने पर पहले दो 30A 240V circuits free मिलते थे
10-year contract था और metering भी नहीं थी, इसलिए हमने हर rack को जितना हो सके उतना dense pack किया। एक side पर दो 30A और दूसरी side पर दो 20A लगाए
हम जितनी heat और power consumption पैदा कर रहे थे, उसे देखते हुए data center शायद लगभग break-even पर रहा होगा। शायद connectivity या peering cost से compensate किया होगा
details ठीक से याद नहीं हैं, इसलिए उस दौर में वहाँ काम करने वाले दोस्त से confirm करना पड़ेगा
कुछ workloads cloud में सही बैठते हैं और कुछ नहीं। सबसे अच्छा उदाहरण high-bandwidth या disk-heavy applications हैं
Netflix को देखें तो लगभग सब कुछ cloud में है, लेकिन actual video delivery अपने hardware से करता है। Netflix के scale पर भी अगर वे इसके लिए किसी और को pay करते, तो यह economically possible होता या नहीं, इस पर शक है
अक्सर दिखने वाले numbers को थोड़ा बदलकर देखें: 20PB egress पर $0.02 per GB हो तो महीने के $400k बनते हैं
20PB लगभग 95th percentile पर 67Gbps के बराबर है
100Gbps flat-rate circuit महीने के $5k में भी ढूंढना मुश्किल नहीं है
बेशक यह बहुत ज़्यादा simplified calculation है, और असल में इसमें कहीं ज़्यादा factors होते हैं। फिर भी gap बड़ा है
कुछ companies के लिए सालाना $4.68M कोई बड़ी बात नहीं हो सकती, लेकिन दूसरों के लिए यह survival का सवाल हो सकता है
काश इसमें और भी ज़्यादा विस्तार होता। WTF सेक्शन सबसे अच्छा लगा
उपकरणों पर “इस तरफ़ को दुश्मन की ओर रखें” जैसे लेबल, या ऐसा उचित affordance चाहिए लगता है जिससे वह सिर्फ़ एक ही दिशा में फिट हो
क्या rack स्तर पर layout को standardize किया गया था? गलतियों को रोकने के लिए कौन-सी poka-yoke प्रक्रियाएँ जोड़ी गईं?
bare metal से boot तक का stack कैसा दिखता है?
दो अलग-अलग cloud providers में काम कर चुके और PXE booting hosts से internal cloud खुद बना चुके व्यक्ति के तौर पर, ऐसी बातें वाकई दिलचस्प हैं
नया datacenter शुरू करते समय, जितना हो सके उसका फायदा उठाकर दिमाग में आने वाले सभी failure scenarios, और random fault injection से वे scenarios भी test करना अच्छा है जिनके बारे में सोचा नहीं गया था
rack-level layout standardization अब कर रहे हैं। दूसरे site के बाद ही यह समझ आया। इससे verification काफी आसान हो गया
verification मुश्किल है और अब तक manually कर रहे हैं। LLDP data scrape करने की कोशिश करना चाहता हूं, लेकिन switch software stack में bug है
यह लगातार evolve होने वाली process है। अलग-अलग contractors के साथ जितना काम करते हैं, उतने अधिक edge cases मिलते हैं और उन्हें शामिल करते हैं
सबसे बड़ा improvement यह रहा कि हमने internal DCIM बनाया, rack designs को template किया, और field technicians के लिए interactive “cabling explorer” export कराया। इसमें port names आदि दिखाने वाले equipment के detailed annotated diagrams भी शामिल हैं। लेख में दिखा rack elevation screenshot उसी tool का हिस्सा है
bare metal से boot तक के लिए https://github.com/danderson/netboot/tree/main/pixiecore के ऊपर hack करके बनाया हुआ कुछ है। यह Debian netboot और preseed files serve करता है
BMC के Redfish API से connect होकर इस device को control करने वाला custom Temporal worker भी है। इसके बाद custom host agent QEMU VM provision करता है, और host पर FRR का उपयोग करके assigned IP को BGP से advertise करता है
नए datacenter failure scenarios के संदर्भ में, हमने पहले ही breakers trip करके test किया था, और उसी से पता चला कि phase balancing बिगड़ी हुई थी। एक दूसरे site पर हम thermal camera लेकर गए थे
अगले हफ्ते AMS site live हो रही है, और लक्ष्य यह देखना है कि fully populated switch fabric को कितनी दूर तक push किया जा सकता है
अच्छा लेख है। जब 100G speed चाहिए होती है, तो Google वाकई बहुत ज़्यादा कीमत वसूलता है। लगभग अपमानजनक हद तक
उदाहरण के लिए, redundant 100G Dedicated Interconnect करीब 35 हजार डॉलर प्रति माह है, और इसमें VLAN attachment, colocation cross-connect fees, transit आदि शामिल नहीं हैं। ऊपर से VLAN attachment की अधिकतम सीमा 50G है
इस cost की तुलना करें तो, उसी पैसे में Arista के नए 32-port 100G switches के 2 units खरीदे जा सकते हैं
North America में 100G WAN circuit, यानी managed Wavelength, 5 हजार डॉलर प्रति माह से कम में मिल सकता है। local metro हो तो dark fiber और भी सस्ता मिल सकता है और उसे अपनी मनचाही speed पर चला सकते हैं