आइए समस्या को छोटे स्तर पर लें। एक सर्वर, मेल, ActiveDirectory, फ़ाइल साझा और कंपनी के लिए वेब साइट पर चलने वाला एक छोटा सा कार्यालय।
हैकर्स ने इसे मारा और आपको रिबूट करना पड़ा क्योंकि IIS गड़बड़ है। या एक्सचेंज को अपडेट और रिबूट की जरूरत है। या सक्रिय निर्देशिका दूषित हो गई।
इनमें से कोई भी अलग-थलग "एक सेवा नीचे है" समस्याएं पूरे सर्वर को प्रभावित करती हैं, इसलिए उस सर्वर पर कुछ भी साझा करने से रिबूट या कुछ और होने के कारण उन्हें प्रभावित किया जा सकता है।
एक बार जब एक वास्तविक आईटी व्यक्ति उस सर्वर को दिखाता है और देखता है, तो वह उन्हें अलग-अलग सर्वरों में विभाजित करने की सलाह दे रहा है (और बैकअप डोमेन नियंत्रक सर्वर होने पर)।
यह "एक टोकरी में अपने सभी अंडे न डालें" की पुरानी कहावत है
अब वह दर्शन वेब सर्वर पर लागू होता है। यदि मेरे पास केवल एक ही वेब सर्वर है और मैं अपना वेब ऐप (नया MyFaceLink.com) प्रकाशित करता हूं और यह वास्तव में लोकप्रिय हो जाता है, तो मुझे नई मुसीबतें मिल गई हैं। मैं साइट को रखरखाव करने के लिए नीचे नहीं ले जा सकता, जबकि उपयोगकर्ता उस पर हैं। और अगर यह दुर्घटनाग्रस्त हो जाता है या मुझे बहुत सारे उपयोगकर्ता मिलते हैं, तो मैं चंगा हूँ। यहां तक कि दुनिया का सबसे बड़ा एकल सर्वर 1 अरब FB धर्मान्तरित होने से अभिभूत हो जाएगा।
तो, लोड संतुलन खेल में आता है, उसी "अंडे में टोकरी" कारण के लिए। साइट को 3 सर्वरों में फैलाएं, और यदि कोई नीचे जाता है, तो शेष 2 क्षमता को संभालते हैं। अगर मुझे पैचअप करने की ज़रूरत है, तो मैं एक बार में एक करता हूं, और कोई भी नोटिस नहीं करता है।
सरलतम में, यह मेगा-सर्वर की कीमत के बारे में नहीं है या क्या यह वास्तव में लोड को संभाल सकता है (हालांकि यह हो सकता है)। यह विफलता के एकल बिंदु के बारे में है। एक बार व्यापार काफी व्यस्त हो जाता है, और 8-5 काम करने वाले 5 उपयोगकर्ताओं के बजाय 24x7 हो रहा है, डाउनटाइम स्वीकार्य नहीं है। शेड्यूल किए गए आउटेज शेड्यूल करने के लिए कठिन हैं। तो, आप लोड फैलाते हैं।