जीरो डाउनटाइम परिनियोजन प्राप्त करने से एक ही मुद्दे पर संपर्क हुआ, लेकिन मुझे एक रणनीति पर कुछ सलाह की आवश्यकता है, जिस पर मैं विचार कर रहा हूं।
प्रसंग
सर्वर-साइड प्रोसेसिंग के लिए Apache / PHP के साथ एक वेब-आधारित एप्लिकेशन और दृढ़ता के लिए MySQL DB / filesystem।
वर्तमान में हम आधारभूत संरचना का निर्माण कर रहे हैं। सभी नेटवर्किंग हार्डवेयर में अतिरेक होगा और सभी मुख्य नेटवर्क केबलों का उपयोग दोष-सहिष्णुता के लिए बंधुआ जोड़े में किया जाएगा। सर्वर को हार्डवेयर फॉल्ट-टॉलरेंस के लिए उच्च-उपलब्धता जोड़े के रूप में कॉन्फ़िगर किया जा रहा है और वर्चुअल-मशीन फॉल्ट-टॉलरेंस और सामान्य प्रदर्शन दोनों के लिए लोड-संतुलित होगा।
यह मेरा इरादा है कि हम बिना किसी डाउन-टाइम के एप्लिकेशन को अपडेट करने में सक्षम हैं। मैंने यह सुनिश्चित करने के लिए बुनियादी ढांचे को तैयार करते समय बहुत दर्द उठाया है कि मैं 100% समय प्रदान कर सकता हूं; हर बार अपडेट लागू होने के बाद 10-15 मिनट डाउन होना बेहद निराशाजनक होगा। यह विशेष रूप से महत्वपूर्ण है क्योंकि हम एक बहुत तेजी से रिलीज चक्र का इरादा रखते हैं (कभी-कभी यह प्रति दिन एक या अधिक रिलीज तक पहुंच सकता है।
नेटवर्क टोपोलॉजी
यह नेटवर्क का सारांश है:
Load Balancer
|----------------------------|
/ / \ \
/ / \ \
| Web Server | DB Server | Web Server | DB Server |
|-------------------------|-------------------------|
| Host-1 | Host-2 | Host-1 | Host-2 |
|-------------------------|-------------------------|
Node A \ / Node B
| / |
| / \ |
|---------------------| |---------------------|
Switch 1 Switch 2
And onward to VRRP enabled routers and the internet
नोट: DB सर्वर मास्टर-मास्टर प्रतिकृति का उपयोग करते हैं
सुझाई गई रणनीति
इसे प्राप्त करने के लिए, मैं वर्तमान में DB स्कीमा उन्नयन स्क्रिप्ट को दो भागों में तोड़ने के बारे में सोच रहा हूं। अपग्रेड इस तरह दिखेगा:
- नोड ए पर वेब-सर्वर को ऑफ-लाइन लिया जाता है; नोड बी पर वेब-सर्वर द्वारा ट्रैफ़िक को संसाधित किया जाना जारी है
- संक्रमणकालीन स्कीमा परिवर्तन DB सर्वरों पर लागू होते हैं
- वेब-सर्वर एक कोड-आधार अपडेट किया गया है, कैश को मंजूरी दे दी गई है, और किसी भी अन्य अपग्रेड कार्रवाई की जाती है।
- वेब-सर्वर ए को ऑनलाइन लाया जाता है और वेब-सर्वर बी को ऑफलाइन लिया जाता है।
- वेब-सर्वर बी कोड-बेस अपडेट किया गया है, कैश को मंजूरी दे दी गई है, और किसी भी अन्य अपग्रेड कार्रवाई की जाती है।
- वेब-सर्वर बी को ऑनलाइन लाया जाता है।
- अंतिम स्कीमा परिवर्तन DB पर लागू होते हैं
'संक्रमणकालीन योजनाएं' को एक क्रॉस-संस्करण संगत डीबी स्थापित करने के लिए डिज़ाइन किया जाएगा। यह ज्यादातर तालिका विचारों का उपयोग करता है जो पुराने संस्करण स्कीमा का अनुकरण करते हैं जबकि तालिका खुद नए स्कीमा में बदल जाएगी। यह पुराने संस्करण को डीबी के साथ सामान्य रूप से बातचीत करने की अनुमति देता है। तालिका के नामों में यह सुनिश्चित करने के लिए स्कीमा संस्करण संख्या शामिल होगी कि यह लिखने के लिए किस तालिका के बारे में कोई भ्रम नहीं होगा।
'अंतिम स्कीमा' पीछे की संगतता को हटा देगा और स्कीमा को साफ करेगा।
सवाल
संक्षेप में, यह काम करेगा?
अधिक विशेष रूप से:
क्या संक्रमणकालीन स्कीमा परिवर्तन के विशिष्ट बिंदु पर समवर्ती लिखने की क्षमता के कारण समस्याएं होंगी? क्या यह सुनिश्चित करने का एक तरीका है कि प्रश्नों का समूह जो तालिका को संशोधित करता है और पीछे की ओर-संगत दृश्य बनाता है, को लगातार निष्पादित किया जाता है? अर्थात जब तक स्कीमा परिवर्तन पूरा नहीं हो जाता है, तब तक बफर में आयोजित होने वाले किसी भी अन्य प्रश्नों के साथ, जो आमतौर पर केवल मिलीसेकंड होगा।
क्या ऐसे सरल तरीके हैं जो इस डिग्री को स्थिरता प्रदान करते हैं जबकि डाउन-टाइम के बिना भी अपडेट की अनुमति देते हैं? यह 'विकासवादी' स्कीमा रणनीति से बचने के लिए भी पसंद किया जाता है क्योंकि मैं बैकवर्ड स्कीमा संगतता में बंद नहीं होना चाहता।