शून्य डाउनटाइम परिनियोजन प्राप्त करना

Question

मैं शून्य डाउनटाइम परिनियोजन प्राप्त करने का प्रयास कर रहा हूं ताकि मैं "धीमी" घंटों के दौरान कम-से-कम तैनात कर सकूं - या सिद्धांत रूप में कभी भी।

मेरा वर्तमान सेटअप, कुछ हद तक सरलीकृत:

• वेब सर्वर A (.NET ऐप)
• वेब सर्वर बी (.NET ऐप)
• डेटाबेस सर्वर (SQL सर्वर)

मेरी वर्तमान तैनाती प्रक्रिया:

1. वेब सर्वर ए और बी दोनों पर साइटों को "रोकें"
2. एप्लिकेशन के संस्करण के लिए डेटाबेस स्कीमा को अपग्रेड किया जा रहा है
3. वेब सर्वर ए को अपडेट करें
4. वेब सर्वर बी अपडेट करें
5. सब कुछ वापस ऑनलाइन लाओ

वर्तमान समस्या

इससे हर महीने एक छोटी राशि घट जाती है - लगभग 30 मिनट। मैं ऐसा घंटों के दौरान करता हूं, इसलिए यह बहुत बड़ी समस्या नहीं है - लेकिन यह ऐसी चीज है जिससे मैं दूर होना चाहता हूं।

इसके अलावा - वास्तव में 'वापस' जाने का कोई तरीका नहीं है। मैं आमतौर पर रोलबैक DB स्क्रिप्ट नहीं बनाता - केवल स्क्रिप्ट को अपग्रेड करता हूं।

लोड बैलेंसर का लाभ उठाना

मैं एक समय में एक वेब सर्वर को अपग्रेड करने में सक्षम होना पसंद करूंगा। वेब सर्वर ए को लोड बैलेंसर से बाहर निकालें, इसे अपग्रेड करें, इसे ऑनलाइन वापस करें, फिर वेब सर्वर बी के लिए दोहराएं।

समस्या डेटाबेस है। मेरे सॉफ़्टवेयर के प्रत्येक संस्करण को डेटाबेस के एक अलग संस्करण के खिलाफ निष्पादित करने की आवश्यकता होगी - इसलिए मैं "अटक" की तरह हूं।

संभावित समाधान

एक वर्तमान समाधान जिस पर मैं विचार कर रहा हूं वह निम्नलिखित नियमों को अपना रहा है:

• डेटाबेस टेबल को कभी भी डिलीट न करें।
• डेटाबेस कॉलम कभी नहीं हटाएं।
• डेटाबेस कॉलम का कभी नाम न लें।
• कभी किसी स्तंभ को पुन: व्यवस्थित न करें।
• हर संग्रहित प्रक्रिया का संस्करण होना चाहिए।
  • अर्थ - 'spFindAllThings' संपादित होने पर 'spFindAllThings_2' बन जाएगा।
  • फिर से संपादित किए जाने पर यह 'spFindAllThings_3' बन जाता है।
  • विचारों पर भी यही नियम लागू होता है।

जबकि, यह थोड़ा चरम लगता है - मुझे लगता है कि यह समस्या को हल करता है। एप्लिकेशन के प्रत्येक संस्करण को गैर ब्रेकिंग तरीके से DB को हिट किया जाएगा। कोड विचारों / संग्रहीत प्रक्रियाओं से कुछ परिणामों की अपेक्षा करता है - और यह उस 'अनुबंध' को वैध रखता है। समस्या यह है - यह सिर्फ मैला ढोना है। मुझे पता है कि थोड़ी देर के लिए ऐप को तैनात करने के बाद मैं पुरानी संग्रहीत प्रक्रियाओं को साफ कर सकता हूं, लेकिन यह सिर्फ गंदा लगता है। इसके अलावा - यह इन नियमों का पालन करने वाले सभी डेवलपर्स पर निर्भर करता है, जो ज्यादातर होगा, लेकिन मुझे लगता है कि कोई गलती करेगा।

अंत में - मेरा प्रश्न

• यह मैला है या हैकी?
• क्या कोई और इस तरह से कर रहा है?
• अन्य लोग इस समस्या को कैसे हल कर रहे हैं?

Comments

आपका बैकआउट प्लान कहां है? आप कैसे परीक्षण करते हैं कि सब कुछ काम करता है और कोई प्रतिगमन नहीं है?

— हिरण हंटर

आपको "कभी नहीं" की आवश्यकता नहीं है: आपको "केवल" यह सुनिश्चित करने की आवश्यकता है कि प्रत्येक दो आसन्न संस्करण समवर्ती रूप से चल सकते हैं। यह आपके अपग्रेड पथों को प्रतिबंधित करता है, लेकिन उतने गंभीर रूप से नहीं जितना कि डीबी स्कीमा को महत्वपूर्ण रूप से बदलने में सक्षम नहीं है।

— जोकिम सॉर

धन्यवाद जोआचिम ... मुझे निरपेक्षता में बात करना पसंद है ताकि मूल विचार स्पष्ट हो - लेकिन आप सही हैं, हमारे पास एन रिलीज द्वारा पिछड़े संगत होने की नीति हो सकती है, जिस बिंदु पर हम अनावश्यक डीबी ऑब्जेक्ट को हटा सकते हैं।

— मैटवूल

आप एक रोलबैक योजना रखना चाहेंगे। एक दिन आपको इसकी आवश्यकता होगी।

— थोरबजोरन रेव एंडरसन

मेरे अनुभव में, अधिकांश वेबसाइटों के लिए, आपका संभावित समाधान उस समस्या से बदतर है जो इसे हल करती है। जितनी जटिलता आप जोड़ेंगे, उससे अधिक महंगी होगी, जो आप अभी अनुमान लगा सकते हैं। शायद बदलाव करने और सुविधाओं को जोड़ने के लिए कई बार अधिक समय / प्रयास। मैं केवल उन वेबसाइटों के लिए विचार करूँगा जो कभी भी डाउनटाइम, कभी भी नहीं हो सकती हैं ।

— MGOwen

Answer 1

यह डेटाबेस-समर्थित सॉफ़्टवेयर अपग्रेड के लिए एक बहुत ही व्यावहारिक दृष्टिकोण है। इसे 2003 में मार्टिन फाउलर और प्रमोद सदलगे द्वारा वर्णित किया गया था और बाद में इसे रिफ़ैक्टरिंग डेटाबेस: एवोल्यूशनरी डेटाबेस डिज़ाइन में लिखा गया था ।

मैं देख सकता हूं कि जब आप कहते हैं कि इसका मतलब क्या है कि यह टेढ़ा लगता है, लेकिन जब जानबूझकर और पूर्वाभास के साथ किया जाता है, और समय-समय पर अप्रयुक्त संरचनाओं को कोडबेस और डेटाबेस से बाहर निकालने के लिए समय लेते हैं जब वे प्रदर्शनकारी नहीं रह जाते हैं, तो यह बहुत अधिक मजबूत होता है। उन्नयन और रोलबैक स्क्रिप्ट के आधार पर सरल समाधान।

Answer 2

"शून्य डाउनटाइम" इस तरह के दृष्टिकोण के कई संभावित कारणों में से एक है। डेटामोडेल को पीछे की ओर इस तरह से रखने से आपको कई तरह की समस्याओं से निपटने में मदद मिलती है:

• यदि आपके पास बहुत सारे सॉफ़्टवेयर पैकेज हैं जो आपके डेटाबेस तक पहुँचते हैं, तो आपको उन सभी की जाँच नहीं करनी होगी यदि स्कीमा परिवर्तन उन्हें प्रभावित करता है (कई टीमों के साथ बड़े संगठनों में एक ही डेटाबेस को एक्सेस करने वाले सभी प्रोग्राम लिखने के लिए, स्कीमा परिवर्तन बहुत कठिन हो सकते हैं)

• यदि आपको चाहिए, तो आप अपने किसी एक प्रोग्राम के पुराने संस्करण की जांच कर सकते हैं और यह संभवतः एक नया डेटाबेस फिर से चलाएगा (जब तक कि आप पुराने प्रोग्राम को किसी नए कॉलम को सही ढंग से संभालने की उम्मीद न करें)

• वर्तमान डेटाबेस संस्करण में संग्रहीत डेटा का आयात / निर्यात बहुत आसान है

आपकी सूची के लिए यहां एक अतिरिक्त नियम है

• प्रत्येक नया कॉलम या तो NULLable होना चाहिए या एक सार्थक डिफ़ॉल्ट मान प्रदान करना चाहिए

(यह सुनिश्चित करता है कि पुराने प्रोग्राम जो नए कॉलम को नहीं जानते हैं वे आपके डेटाबेस में नए रिकॉर्ड बनाते समय कुछ भी नहीं तोड़ेंगे)।

बेशक, इस दृष्टिकोण में एक वास्तविक दोष है: आपकी डेटामॉडल की गुणवत्ता समय के साथ कम हो सकती है। और यदि आपके पास अपने डेटाबेस तक पहुँचने वाले सभी अनुप्रयोगों पर पूर्ण नियंत्रण है, और आप उन सभी अनुप्रयोगों को आसानी से रिफ्लेक्टर कर सकते हैं जब आप, उदाहरण के लिए, एक कॉलम का नाम बदलने जा रहे हैं, तो आप क्लीनर तरीके से चीजों को रिफलेक्टर करने पर विचार कर सकते हैं।

Answer 3

यह एक तैनाती से दूसरे में भिन्न होता है।

यकीन है, आप एक मेज या एक स्तंभ को कभी नहीं हटा सकते। आप इंटरफ़ेस संगतता को तोड़ने वाली किसी भी चीज़ को कभी नहीं बदल सकते। आप हमेशा अमूर्तता की एक परत जोड़ सकते हैं। लेकिन फिर आपको उस अमूर्त संस्करण और संस्करण को संस्करण करना होगा।

सवाल जो आपको खुद से पूछने की ज़रूरत है, क्या हर एक रिलीज़ स्कीमा को इस तरह से बदल देती है कि यह पीछे की ओर संगत नहीं है?

यदि बहुत कम रिलीज़ स्कीमा को उस तरह से बदलते हैं, तो डेटाबेस समस्या मूक है। बस एप्लिकेशन सर्वर का एक रोलिंग परिनियोजन करें।

जिन दो चीजों को मैंने देखा है, उनमें न्यूनतम-डाउन तैनाती के साथ सबसे अधिक मदद मिलती है:

1. पिछड़े संगतता के लिए कठोर - कम से कम एक रिलीज के भीतर। आप इसे हमेशा प्राप्त नहीं करेंगे, लेकिन मैं शर्त लगा सकता हूं कि आप इसे 90% या अधिक रिलीज़ पर प्राप्त कर सकते हैं, खासकर यदि प्रत्येक रिलीज़ छोटा है।
2. पूर्व-रिलीज़ और रिलीज़-बाद डेटाबेस स्क्रिप्ट है। इससे आप अपने ऐप कोड को तैनात करने से पहले अपना नया ऑब्जेक्ट बनाकर नाम बदलने या इंटरफ़ेस में बदलाव कर सकते हैं, फिर ऐप कोड लागू होने के बाद पुराने को हटा सकते हैं। यदि आप एक नया ग़ैर-अशक्त स्तंभ जोड़ते हैं, तो आप इसे अपनी पूर्व-रिलीज़ स्क्रिप्ट में एक ट्रिगर के साथ अशक्त के रूप में जोड़ सकते हैं जो एक डिफ़ॉल्ट मान को भरता है। फिर आपकी रिलीज़ के बाद, आप ट्रिगर छोड़ सकते हैं।

उम्मीद है कि रखरखाव के खिड़कियों के लिए आपके बाकी हिस्सों को बचाया जा सकता है।

अन्य विचार जो नीचे की आवश्यकता वाले कुछ डिप्लॉय से निपटने में मदद कर सकते हैं:

• आप अपने कोड में पिछड़े संगतता का निर्माण कर सकते हैं? उदाहरण के लिए, क्या आपका कोड कई प्रकार के परिणाम सेटों का समर्थन कर सकता है? यदि आपको एक कॉलम को इंट से डबल में बदलने की आवश्यकता है, तो आपका ऐप कोड इसे एक स्ट्रिंग के रूप में पढ़ सकता है और इसे पार्स कर सकता है। हैक की तरह, लेकिन अगर यह रिलीज की प्रक्रिया के माध्यम से खुद को प्राप्त करने के लिए अस्थायी कोड है, तो यह दुनिया का अंत नहीं हो सकता है।
• संग्रहीत प्रक्रिया स्कीमा परिवर्तनों से आपके ऐप कोड को इंसुलेट करने में मदद कर सकती हैं। यह केवल इतनी दूर जा सकता है, लेकिन थोड़ी मदद करता है।

Answer 4

आप इसे थोड़े अतिरिक्त प्रयास के लिए संभावित रूप से कर सकते हैं।

1. निर्यात करके डेटाबेस का बैकअप लें
2. बैक अप आयात करें लेकिन इसे एक रिलीज संस्करण जैसे myDb_2_1 के साथ नाम बदलें
3. MyDB_2_1 पर डेटाबेस रिलीज़ जारी करें
4. वेब सर्वर ए पर ऐप पूल को रोकें या इसे लोड बैलेंसर से बाहर निकालें
5. वेब सर्वर ए अपडेट करें, यदि आवश्यक हो तो पोस्ट कार्यान्वयन परीक्षण और रोलबैक चलाएं
6. सत्र ने वेब सर्वर बी को ब्लीड किया और वेब सर्वर ए को लूप में वापस रखा
7. वेब सर्वर बी को अपग्रेड करें और फिर लोड बैलेंसर में वापस डालें

स्वाभाविक रूप से वेब अपडेट को नए डीबी स्कीमा को इंगित करने के लिए नई कॉन्फ़िगरेशन प्रविष्टियों की आवश्यकता होगी। बात यह है कि यदि आप महीने में एक बार रिलीज कर रहे हैं और यह एक छोटी सी टीम है तो आप कितने डीबी परिवर्तन कर रहे हैं जो वास्तव में पीछे की ओर संगत नहीं हैं? यदि आप यह नियंत्रित कर सकते हैं कि परीक्षण करके आप बिना समय के साथ स्वचालित तैनाती प्राप्त कर सकते हैं या शायद कम से कम केवल 5 मिनट के समय के लिए।

Comments

क्या होगा यदि (जब) ​​सर्वर ए पर ऐप आपके बैकअप को संग्रहीत करने के बाद उसके डीबी को लिखता है, लेकिन इससे पहले कि आप सर्वर ए को रोक दें? हमेशा "भेद्यता की खिड़की" होती है। ये लेखन खो जाएगा, जो स्वीकार्य नहीं हो सकता है।

— सालेके २ s