शुरुआती महीनों में क्लस्टर का मतलब था हमेशा चालू रहने वाला एक ही सर्वर, जिस पर सब कुछ था: कंट्रोल प्लेन, हर डेटाबेस और वॉल्यूम, हर पब्लिक साइट, रजिस्ट्री, और हर डिप्लॉय पर खुद बिल्ड भी। किसी भी नोड पर 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 की जगह अपना रनर पूल लाने की कहानी है।