जावा ईई वेब ऐप के लिए अमेज़ॅन क्लाउड कॉन्फ़िगरेशन MySQL

Question

मेरे काम में मुझे कुछ मौजूदा एंटरप्राइज़ जावा एप्लिकेशन को AWS में स्थानांतरित करने की आवश्यकता है। मैं aws.amazon.com पर कई पेजों से गुजर चुका हूं और पर्याप्त रूप से गुग हो गया हूं। इसके अलावा, मैंने स्टैक ओवरफ्लो पर सभी संबंधित प्रश्नों को पार करने की कोशिश की है। इन सभी चीजों ने कई चीजों को स्पष्ट किया, हालांकि, मुझे अभी भी कुछ भ्रम है। यहां हमारी आवेदन संरचना है:

1. यह एक वसंत आधारित अनुप्रयोग है जो स्प्रिंग एमवीसी का प्रेजेंटेशन लेयर और सादे जावा इंटरफेस और क्लासेस को व्यापार और डेटा तर्क को संभालने के लिए उपयोग करता है।
2. MySQL दृढ़ता के लिए उपयोग किया जाता है।

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

1. उच्चतर दोष सहिष्णुता:

   अब यहाँ हम क्या एडब्ल्यूएस में जाने से प्राप्त करने की आवश्यकता है। हाल ही में हमें कुछ समय के लिए समर्पित होस्टिंग में सर्वर/पावर विफलता का सामना करना पड़ा।

2. प्रतिक्रिया समय और थ्रूपुट के संदर्भ में आवेदन के सभी उदाहरणों के लिए उच्च प्रदर्शन।
3. MySQL के लिए उच्च गलती सहनशीलता। हाल ही में कुछ हार्डवेयर (हार्ड ड्राइव) के कारण हमारे सर्वरों में से एक पर अनुप्रयोग उदाहरण नीचे आ गए, जो मूल रूप से MySQL को अप्रत्याशित रूप से बंद कर देता था। हार्ड ड्राइव पर पूरी फ़ाइल सिस्टम केवल उस सर्वर पर होस्ट किए गए अनुप्रयोग उदाहरणों के खराब होने के कारण पढ़ा गया।
4. स्पष्ट रूप से बुनियादी लागत प्रबंधन की कुल लागत और ओवरहेड को कम करना।

जहां तक ​​मेरा अब तक एडब्ल्यूएस बुनियादी ढांचे को समझने में सक्षम हूँ, यहाँ क्या हम अपने सेटअप के लिए एडब्ल्यूएस में की आवश्यकता होगी है: कुछ EBS की,

1. 4 उदाहरणों, प्रत्येक के बारे में 10 आवेदन उदाहरणों की मेजबानी टॉमकैट और MySQL के साथ आधारित LINUX AMI उस पर स्थापित है।
2. मुझे लगता है कि हमें उन सभी 4 उदाहरणों में से प्रत्येक के लिए गलती सहनशीलता के लिए 1 उदाहरण की आवश्यकता होगी।
3. सभी सर्वर उदाहरणों में लगभग 160GB ईबीएस होगा।
4. 4 लचीला आईपी
5. 4 लचीला लोड balancers
6. स्नैपशॉट आदि जैसे अन्य सामान

अब यहाँ मेरे प्रश्न हैं:

1. मैं वास्तव में उस अतिरिक्त सर्वर उदाहरण है की जरूरत है (गलती सहनशीलता के लिए) प्रत्येक मुख्य सर्वर उदाहरण के लिए, ईबीएस द्वारा स्वचालित रूप से बैक अप किए गए चेहरे पर विचार करते हुए और वे हार्डवेयर विफलता के मामले में एक ही डेटा के साथ नई ईबीएस प्रदान करेंगे?

2. मैं उपरोक्त परिदृश्य में सभी सर्वर उदाहरणों (4x2) के बीच डेटाबेस कैसे साझा करूं? एक विकल्प जो मैं देख रहा हूं वह उन सर्वर उदाहरणों के बीच MySQL क्लस्टरिंग को कार्यान्वित करना है। आइए कहें, MySQL क्लस्टर में 1 प्रबंधन नोड, 3 एसक्यूएल नोड्स और 4 डेटा नोड्स होंगे।हालांकि, इस मामले में क्लस्टर को बनाए रखना हमारे लिए एक अतिरिक्त ओवरहेड होगा और यह स्वीकार नहीं किया जा सकता है क्योंकि हम बुनियादी ढांचे प्रबंधन से छुटकारा पा सकते हैं।

3. क्या मुझे डेटाबेस के बजाय आरडीएस होना चाहिए और सभी सर्वर isntances (4x2) से MySQL उदाहरणों को निकालना है? यदि हां, तो मुझे ईसी 2 उदाहरणों के अलावा आरडीएस उदाहरण खरीदने की ज़रूरत होगी (मुझे लगता है कि अगर मुझे आरडीएस के लिए अलग-अलग उदाहरण खरीदने की ज़रूरत है तो कुल बुनियादी ढांचे की लागत कम से कम 75% तक बढ़ जाएगी।) या आरडीएस के उदाहरण भी गणना इकाइयां देते हैं आवेदन विकास के लिए आवेदन तैनाती के लिए उदाहरणों की कुल संख्या को कम करना?

4. आरडीएस कार्यान्वयन के मामले में, क्या वास्तव में ईबीएस आधारित ईसी 2 उदाहरणों की आवश्यकता होती है? अगर हम कुछ कर सकते हैं तो आरडीएस उदाहरणों के साथ ईसी 2 उदाहरणों से ईबीएस आवश्यकता को कैसे हटाया जाए, हम कुल लागत को कम कर सकते हैं।

किसी भी मदद की सराहना की जाएगी और कृपया मुझे बताएं कि क्या मैं अपनी समस्या निर्दिष्ट करने के लिए स्पष्ट नहीं हूं और किसी भी बिंदु के लिए अधिक स्पष्टीकरण की आवश्यकता है।

Answer 1

मैं कोई बुनियादी ढांचा विशेषज्ञ नहीं हूं, लेकिन मुझे एडब्ल्यूएस पर कुछ अनुभव है, और मुझे आशा है कि मैं कम से कम आपके कुछ प्रश्नों में सहायता कर सकता हूं। मेरी पृष्ठभूमि मुझे आपके बुनियादी ढांचे के आकार के बारे में कोई सलाह देने की अनुमति नहीं देती है, लेकिन मैं इन्फ्रा के प्रकार पर सलाह देने में मदद कर सकता हूं।
सबसे पहले, मैं निश्चित रूप से ईबीएस के साथ जाऊंगा। अपने आवेदन सर्वर से शारीरिक रूप से अलग होने के अलावा, इसमें उच्च विश्वसनीयता और उच्च उपलब्धता भी है। मैं आपको बता सकता हूं कि यह मुझे दो बार बचाया। हालांकि मैंने कहा कि मैं आपको आकार देने के बारे में कुछ नहीं बताऊंगा, मुझे नहीं लगता कि आपको अतिरिक्त 4 "गलती सहनशीलता" उदाहरणों की आवश्यकता होगी, लेकिन हो सकता है कि आप कुछ मामलों को यातायात को दूर करने के लिए तैयार रह सकें, बस मामले में।

अपने डीबी के संबंध में, आपको निश्चित रूप से आगे बढ़ना चाहिए और MySQL (http://aws.amazon.com/rds/mysql/) के लिए आरडीएस का उपयोग करना चाहिए। वे आपको (आईएमएचओ) छोटी कीमत पर पूर्व-कॉन्फ़िगर किए गए नोड्स, ऑटो-पैचिंग, ऑटो-बैकअप, ऑटो-प्रतिकृति और एक-क्लिक स्केलिंग देते हैं। MySQL के लिए ये सभी सुविधाएं तैयार हैं, आउट ऑफ़ द बॉक्स। आप मेट्रिक्स और निगरानी का भी उपयोग कर सकते हैं, यह सब शामिल है। आरडीएस आपको कंप्यूटिंग इकाइयों नहीं देता है, लेकिन एडब्ल्यूएस में उन्हें अलग रखने के लिए यह एक अच्छा अभ्यास है। आप 4 ईसी 2 टॉमकैट नोड्स + 2 आरडीएस नोड्स के साथ एक सेटअप भी कर सकते हैं। यह :)

आकार आप पहले से ही के बारे में अमेज़न लचीला लोड संतुलन पढ़ चुके हैं का मामला है, यह आपके समाधान के लिए एकदम सही लग रहा है। आप अपने प्रत्येक ईएलबी नोड्स में कुछ ईसी 2 नोड्स संलग्न कर सकते हैं, और लोड संतुलन के बारे में भूल सकते हैं। यह सिर्फ काम करता है, और यदि आप चाहें तो चिपचिपा सत्र भी कॉन्फ़िगर कर सकते हैं। मुझे नहीं पता, हालांकि, आपको कितने ईएलबी नोड्स चुनना चाहिए, लेकिन एक समस्या से अवगत रहें: आप केवल उसी भौगोलिक क्षेत्र (जैसे यूएस पूर्वी तट) से ईसी 2 नोड्स को उसी ईएलबी में जोड़ सकते हैं। यातायात को संतुलित करना संभव नहीं है, उदाहरण के लिए, वेस्ट कोस्ट में टॉमकैट और पूर्वी तट में दूसरा। यदि आप अपने नोड्स को कई क्षेत्रों में वितरित करना चुनते हैं, तो आपको अमेज़ॅन के बाहर एक और एलबी समाधान के साथ आने की आवश्यकता होगी।

मेरी अंतिम सलाह: ईएलबी + ईबीएस-आधारित ईसी 2 + आरडीएस के साथ आगे बढ़ें। यह आपकी निगरानी, ​​तैनाती और रखरखाव को बहुत सरल बना देगा, और लागत बहुत कम हो जाती है। आप शायद इस बारे में अधिक जागरूक हैं कि आपको कितने प्रकार के नोड की आवश्यकता होगी, लेकिन याद करने से डरो मत, क्योंकि एडब्ल्यूएस पर आपके इन्फ्रा को अपस्केल करना या डाउनस्केल करना बहुत आसान है।