एक नोड क्लस्टर बन गया, और किसी ऐप्लिकेशन को बदलना नहीं पड़ा
कभी भी बंद हो सकने वाली एक दूसरी मशीन किसी ऐप्लिकेशन को बदले बिना एक चलते हुए सिंगल-नोड क्लस्टर से जुड़ी। हमेशा चालू रहने वाला एक सर्वर कंट्रोल प्लेन, हर डेटाबेस और वॉल्यूम और हर सर्विस की पहली कॉपी रखता है; बिल्ड मशीन एक taint के पीछे बिल्ड और स्टेटलेस सर्विसों की दूसरी कॉपियाँ संभालती है, और उसके सोते समय वे कॉपियाँ वापस लौटने के बजाय इंतज़ार करती हैं। काम खत्म होने पर वह खुद बंद हो जाती है और कोई जॉब कतार में आने पर लौट आती है, एक कंसोल हर नोड, वर्कलोड और उपलब्धता की अवधि दिखाता है, और हमेशा चालू सर्वर की हर CPU request मापी गई, जिससे उसके रिज़र्वेशन आवंटन योग्य क्षमता के 84 से घटकर 56 प्रतिशत पर आ गए।
Md Moniruzzaman
पूरी कहानी
चलते हुए सिस्टम में बिना माइग्रेशन के क्षमता कैसे जोड़ी गई, और यह इंफ्रास्ट्रक्चर किराये पर लेने के बजाय खुद चलाने के बारे में क्या साबित करता है।
एक मशीन सब कुछ करती थी, और उसके रिज़र्वेशन खत्म हो गए
शुरुआती महीनों में क्लस्टर का मतलब था हमेशा चालू रहने वाला एक ही सर्वर, जिस पर सब कुछ था: कंट्रोल प्लेन, हर डेटाबेस और वॉल्यूम, हर पब्लिक साइट, रजिस्ट्री, और हर डिप्लॉय पर खुद बिल्ड भी। किसी भी नोड पर CPU request एक रिज़र्वेशन होता है जिसे शेड्यूलर अलग रख देता है, काम उसे इस्तेमाल करे या न करे, इसलिए एक व्यस्त नोड का काम खत्म होने से बहुत पहले उसके रिज़र्वेशन खत्म हो जाते हैं। हमेशा चालू सर्वर अपने आवंटन योग्य CPU के 84 प्रतिशत तक पहुँच चुका था, इसलिए मशीन कितनी भी शांत दिखे, अगला वर्कलोड उसमें समा नहीं सकता था।
जब नई मशीन कभी गायब न हो, तो क्षमता जोड़ना आसान है। मुश्किल रूप वह है जिसमें दूसरी मशीन किसी भी पल बंद हो सकती है, और यह तभी सुरक्षित है जब क्लस्टर ठीक-ठीक जानता हो कि उस मशीन पर क्या चल सकता है और क्या कभी उस पर निर्भर नहीं होना चाहिए। जिस नियम ने इसे सुरक्षित बनाया वह एक पंक्ति में आ जाता है: डेटा रखने वाली कोई भी चीज़ कभी ऐसी मशीन पर नहीं चलती जो गायब हो सकती है।
उलटी ज़िम्मेदारियों वाली मशीनें
एक सर्वर कभी बंद नहीं होता और उस पर कंट्रोल प्लेन, हर डेटाबेस और वॉल्यूम, रजिस्ट्री और हर सर्विस की पहली कॉपी रहती है। बिल्ड मशीन किसी भी पल बंद हो सकती है, और चालू रहते हुए बिल्ड और दूसरी कॉपियाँ संभालती है। एक रोल लेबल और एक taint तय करते हैं कि क्या कहाँ जा सकता है, और जब तक कोई चीज़ खुद न माँगे, बिल्ड मशीन पर कुछ नहीं जाता।
हर नोड की हालत एक स्क्रीन पर, सोने वाले नोडों समेत
कंसोल का Estate व्यू हर नोड को एक कार्ड देता है: उसका रोल, उसके वर्कलोड ने जितना माँगा है बनाम जितना वे इस्तेमाल करते हैं, वह कितने pod चला रहा है, और पिछले एक दिन या एक हफ़्ते की उपलब्धता की पट्टी, जिसमें Ready और Away की हर अवधि दर्ज है। ये कार्ड जानबूझकर एक-दूसरे के उलट दिखते हैं। कैप्चर वाले दिन हमेशा चालू सर्वर पिछले पूरे सात दिन Ready रहा था, और बिल्ड मशीन उनमें से 37 प्रतिशत समय, 30 दर्ज बदलावों के साथ, क्योंकि जब भी काम नहीं होता वह सो जाती है।
उम्मीद नहीं, रोल और एक taint ही वर्कलोड को उनकी सही जगह पर रखते हैं। हमेशा चालू सर्वर पर उसका रोल है और कोई taint नहीं, इसलिए सामान्य वर्कलोड वहीं जाते हैं। बिल्ड मशीन पर एक taint है जो हर उस pod को लौटा देता है जिसने यह घोषित नहीं किया कि वह गायब हो सकने वाले नोड पर भी रह सकता है, इसलिए गलती से वहाँ कुछ नहीं पहुँचता, और जो वर्कलोड डिस्क पर डेटा रखते हैं वे उसी सर्वर पर पिन हैं जिसमें वह डिस्क लगी है।
गलत नोड पर कुछ नहीं जाता, और किसी को नोड का इंतज़ार नहीं करना पड़ता
ज़्यादा क्षमता से फ़ायदा पाने वाली स्टेटलेस सर्विस को कहीं हटाया नहीं जाता, उसे एक दूसरी कॉपी मिलती है। उसकी मूल कॉपी हमेशा चालू सर्वर पर रहती है और बिल्ड मशीन बंद होने पर अकेले सेवा देती है। दूसरी कॉपी सिर्फ़ बिल्ड मशीन पर चल सकती है, कहीं और नहीं: वह मशीन सो रही हो तो कॉपी रुककर इंतज़ार करती है, और कभी हमेशा चालू सर्वर पर वापस नहीं आती, जिसके रिज़र्वेशन ही सबसे कम पड़ने वाला संसाधन हैं। मशीन लौटते ही कॉपियाँ अपने आप शुरू होकर फिर से ट्रैफ़िक में जुड़ जाती हैं।
एज को ऐसे नोड के लिए ट्यून किया गया है जो बिना बताए गायब हो जाता है। बिजली खो चुकी मशीन पर चल रही कॉपी कनेक्शन ठुकराती नहीं, बस जवाब देना बंद कर देती है, इसलिए राउटर आधे मिनट के बजाय कुछ ही सेकंड में उसे छोड़ देता है और एक बार फिर कोशिश करता है, सिर्फ़ पेज रिक्वेस्ट पर, और विज़िटर को घूमते लोडर के बजाय पेज बस थोड़ी देर से मिलता है। 22 सितंबर को आठ सर्विसों की दूसरी कॉपी थी, जिनमें वेबसाइट और पब्लिक MCP सर्वर भी थे; डेटाबेस, CMS और हर बैकएंड हमेशा चालू सर्वर पर एक ही कॉपी में रहते हैं। कैप्चर दोनों हालतें दिखाते हैं: बिल्ड मशीन के सोते समय रुकी हुई कॉपियाँ, और उसके चालू रहते हुए हर नोड से सेवा पाते वेबसाइट और MCP सर्वर।
काम आने तक सोने वाली क्षमता
बिल्ड मशीन कुछ न करते हुए भी साठ से सत्तर वाट बिजली खींचती है, इसलिए वह बेकार बैठी नहीं रहती। काम खत्म होते ही वह खुद बंद हो जाती है, और कोई जॉब कतार में आते ही कुछ मिनटों में वापस क्लस्टर में आ जाती है, किसी को उसे चालू करना याद नहीं रखना पड़ता। Hosts व्यू मशीनों को साथ-साथ दिखाता है: एक दिन के इतिहास के साथ लोड, मेमोरी, डिस्क, तापमान, और अपनी सीमा के मुकाबले बिल्ड कैश।
फ़ोन का व्यू डिज़ाइन का दूसरा आधा हिस्सा दिखाता है। बिल्ड मशीन मौजूद न हो तो उसकी आख़िरी रीडिंग स्क्रीन पर बनी रहती हैं, यह बताते हुए कि वे कितनी पुरानी हैं, ताकि खाली जगह किसी खराबी की तरह नहीं, आराम कर रही मशीन की तरह पढ़ी जाए। इससे मिलती है ऐसी क्षमता जो काम आने पर चालू रहती है और न आने पर बंद।
रिक्वेस्ट ही सबसे कम पड़ने वाला संसाधन थे, इसलिए हर एक मापी गई
हमेशा चालू सर्वर की हर रिक्वेस्ट को तीस-तीस सेकंड के अंतर पर लिए गए चालीस नमूनों पर मापा गया और हर वर्कलोड के शिखर में थोड़ी गुंजाइश जोड़कर तय किया गया। सर्वर अपने वर्कलोड के असली इस्तेमाल का लगभग नौ गुना रिज़र्व कर रहा था; इसके बाद उसके रिज़र्वेशन आवंटन योग्य क्षमता के 84 से घटकर 56 प्रतिशत पर आ गए, जिससे बिना किसी और मशीन के अगली सर्विस के लिए जगह बन गई।
अगली मशीन एक रोल है, कोई प्रोजेक्ट नहीं
इस पूरे रास्ते में कोई ऐप्लिकेशन नहीं बदला। प्लेसमेंट एक रोल लेबल, एक taint, affinity और हर सर्विस के अपने overlay में रहता है, इसलिए सर्विसों को कभी पता ही नहीं चला कि मशीनें कितनी हैं। यही अगले कदम को रोज़मर्रा का काम बनाता है: अगली मशीन एक रोल और बिल्ड रनर का एक हिस्सा पाकर जुड़ जाती है, कोई सर्विस अपनी ही रिपॉज़िटरी से दूसरी कॉपी चुनती है, और इसी पैटर्न पर बना कोई और क्लस्टर नए डिज़ाइन की ज़रूरत के बिना वही कदम दोहराता है। यह दोनों दिशाओं में बढ़ और घट सकता है, क्योंकि बिल्ड मशीन बंद करने से कुछ नहीं खोता और किसी drain की ज़रूरत नहीं पड़ती; बस अतिरिक्त रफ़्तार चली जाती है।
सीमा पहले से बताई गई है, बाद में खोजी नहीं जाती: बिल्ड के बीच बिजली कटे तो वह बिल्ड फ़ेल होता है, और उसे फिर से चलाया जाता है। यह ऐसे व्यवसाय के लिए सही है जिसके पास अपना हार्डवेयर है और जिसे बिना माइग्रेशन के ज़्यादा क्षमता चाहिए, और यह उस सवाल का जवाब देता है जो कोई CTO इंफ्रास्ट्रक्चर सौंपने से पहले पूछता है: क्या सामने वाला व्यक्ति इसके लिए कोड लिखने के साथ-साथ इसे चला भी सकता है। इसके नीचे का प्लेटफ़ॉर्म स्टूडियो चलाने वाले सेल्फ़-होस्टेड होमलैब की कहानी है, और डिलीवरी के लिए बिल्ड मशीन ने क्या किया, यह होस्टेड CI की जगह अपना रनर पूल लाने की कहानी है।
आपको ये भी पसंद आ सकते हैं
जब होस्टेड CI सबसे धीमा कदम बन गया, तो बिल्ड घर लौट आए
बिल्ड और डिप्लॉय GitHub के होस्टेड रनर से, जहाँ हर रन नई मशीन पर शुरू होता था और रिलीज़ कतारों और गड़बड़ियों का इंतज़ार करती थीं, घर के एक रनर पूल पर आ गए: एक बिल्ड मशीन जो चालू रहते हुए हर जॉब लेती है, और हमेशा चालू सर्वर पर स्टैंडबाय रनर, एक ऐसे वॉचडॉग के पीछे जो शक होने पर शिपिंग जारी रखने की ओर झुकता है। इमेज एक प्राइवेट कंटेनर रजिस्ट्री में जाती हैं और स्टूडियो की लाइब्रेरी एक प्राइवेट npm रजिस्ट्री में, दोनों बिल्डिंग के अंदर, और हर रन GitHub की रिटेंशन से आगे तक संग्रह में रहता है। सबसे धीमा डिप्लॉय आठ मिनट चौबीस सेकंड से तीन मिनट पाँच सेकंड पर आ गया, और CI एक तिहाई तेज़ हो गया।
Md Moniruzzaman
सित 24, 2026
27 Pearls - मोबाइल रिलीज़ और स्टोर सबमिशन
एक तैयार 27 Pearls ऐप एक हफ़्ते के एंगेजमेंट के भीतर App Store और Google Play पर मंज़ूर लिस्टिंग बन गया, बिना किसी दौर की अस्वीकृति के। उस हफ़्ते में रिलीज़ बिल्ड और साइनिंग, छात्र के फ़ायदे को केंद्र में रखकर लिखी लिस्टिंग कॉपी, हर ज़रूरी डिवाइस साइज़ के स्क्रीनशॉट, ऐप जो डेटा लेता है उससे मेल खाती प्राइवेसी घोषणाएँ, और रिव्यूअर के लिए काम करता एक अकाउंट शामिल था। ऐप आज भी Google Play पर है।
Md Moniruzzaman
मई 05, 2023
Fully Booked - बिना डाउनटाइम सेल्फ होस्टेड Kubernetes पर माइग्रेशन
Fully Booked मैनेज्ड क्लाउड इंफ़्रास्ट्रक्चर पर चलता था, जिसका बिल हर महीने बढ़ता था और पूरे स्टैक का स्वामित्व किसी के पास नहीं था। हमने पूरे प्लेटफ़ॉर्म को सेल्फ होस्टेड Kubernetes क्लस्टर पर स्थानांतरित किया, उपयोगकर्ताओं के लिए एक मिनट का भी डाउनटाइम लाए बिना। कटओवर में DNS, इनग्रेस, डेटाबेस और रिलीज़ पाइपलाइन शामिल थे, इस तरह चरणबद्ध कि ट्रैफ़िक तभी हटाया गया जब हर परत नए क्लस्टर पर सिद्ध हो गई। उस सप्ताह ऐप इस्तेमाल करने वाले किसी को पता नहीं चला कि कुछ हुआ है, और यही उद्देश्य था। मासिक बिल अपना हार्डवेयर बन गया, और वही क्लस्टर अब प्लेटफ़ॉर्म की साप्ताहिक रिलीज़ संभालता है।
Md Moniruzzaman
जून 23, 2026
ब्लॉग प्रोडक्शन से लिखे फ़ील्ड नोट्स हैं: आर्किटेक्चर के फ़ैसले, असली उपयोगकर्ताओं के सामने टिके AI सिस्टम, और अपनी लागत खुद निकालने वाला इन्फ्रास्ट्रक्चर। काम से लिखा गया, काम के बारे में नहीं।