Tuffle.com सर्वर आर्किटेक्चर उदाहरण का उपयोग करके क्लाउड समाधान पर समर्पित सर्वरों का लाभ

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

1. अक्सर उच्च यातायात के साथ, सर्वर बस बन्द हो जाता है। मुझे साइट की स्थिति की लगातार जांच करनी थी ताकि समस्याओं का शीघ्रता से जवाब दिया जा सके।

2. प्रबंधन में सीमाएं। हमारा समर्पित सर्वर भी एक वर्चुअल सर्वर था। नतीजतन, सभी गैर-मानक संचालन टिकट प्रणाली का उपयोग करके किए गए थे, और यह बहुत असुविधाजनक है।

3. उपस्थिति में वृद्धि के साथ, सर्वर के लिए मूल्य टैग अनुपात में वृद्धि हुई। यह, यह प्रतीत होता है, काफी स्पष्ट है, केवल एक निश्चित समय पर लागत पूरी तरह से अलोकतांत्रिक हो गई और क्लाउड समाधानों की लागत-प्रभावशीलता पर संदेह किया।

और एक बार उन्होंने हमें लिखा कि हमारे सर्वर से एक DDoS हमला हो रहा है। हमने सब कुछ जांचा, अलार्म गलत निकला, लेकिन अप्रिय स्थिति बनी रही।

उपरोक्त सभी के लिए, हमने अपने स्वयं के सर्वर भंडारण को व्यवस्थित करने का निर्णय लिया। यहीं से शुरू होती है मस्ती।

सचमुच समर्पित सर्वर

और समाधान यह था:

1. "स्वच्छ" अलग सर्वर की एक जोड़ी को अपनाने
2. एक क्षैतिज स्केलिंग प्रणाली विकसित करना
3. सर्वर के बीच व्यक्तिगत कार्यों को वितरित करें। कभी-कभी कुछ कार्य।

सबसे पहले, हम यह देखने के लिए दौड़े कि ऐसे सर्वर कहाँ से लाएँ ताकि चैनल अच्छा रहे और कीमत न काटे। नतीजतन, हम हेटनर पर रुक गए और एक ही बार में 8 सर्वर खरीदे। और आप जानते हैं, यह Selectel से एक की तुलना में सस्ता निकला।

सर्वर आवश्यकताओं

शुरू करने के लिए, हमने एक तालिका तैयार की जिसमें हमने लिखा कि हमें सर्वर की आवश्यकता क्यों है, उनके पास क्या विशेषताएँ होनी चाहिए, आदि।



ऊर्ध्वाधर तीरों के साथ, हमने उन विशेषताओं का संकेत दिया जो किसी विशेष सर्वर के लिए सबसे महत्वपूर्ण थे।

लेकिन, यह पता चला कि Hetzner के साथ आप स्वयं को भरने वाले लोहे को कॉन्फ़िगर नहीं कर सकते हैं। इसलिए, हमारे सभी 8 सर्वर बिल्कुल एक जैसे थे, अर्थात् EX40 । वैसे, यह ध्यान देने योग्य है कि गैर-यूरोपीय देशों के लिए आप सुरक्षित रूप से 19% की राशि से घटा सकते हैं, यह वैट है।

हमने ऊपर स्केलेबिलिटी के बारे में बात की। तो: 3 मुख्य क्षेत्र जिसमें जल्दी से बड़े पैमाने पर करने की क्षमता महत्वपूर्ण है:

1. एप्लिकेशन सर्वर। उच्च भार पर, वे सामना नहीं कर सकते।
2. डेटाबेस डेटाबेस
3. सामग्री सर्वर

बाकी कमोबेश स्थिर है।

इन दिशाओं के लिए मास्टर-दास प्रतिकृति उत्कृष्ट है। स्केलिंग के लिए काम करने के लिए, इसे समझने की आवश्यकता है। इसलिए, हम एक मार्कर लेते हैं और बोर्ड पर आकर्षित करते हैं।



उपयोगकर्ता साइट पर लॉग इन करता है और फ्रंट-सर्वर से संपर्क करता है, जो इस अनुरोध को निष्पादित कर सकता है (इसे हमारे मामले में मास्टर कहा जाता है), या इस अनुरोध को अपने दोस्त (दास सर्वर) को भेजें, जो मास्टर से अलग नहीं है। इसलिए, अगर हमें ऐसी स्थिति का सामना करना पड़ता है जहां 2 सर्वर के पर्याप्त संसाधन नहीं हैं, तो हमें केवल एक और गुलाम सर्वर को जोड़ना होगा।

एक समान पैटर्न डेटाबेस के साथ है।

सामग्री थोड़ी अलग है। एप्लिकेशन को पता होना चाहिए कि किस सर्वर को छवियों और वीडियो को अपलोड करना है और किस सर्वर से पढ़ना है। इसलिए, हमारे पास कई मास्टर सर्वर हैं। और एप्लिकेशन को पता है कि विशिष्ट फ़ाइल कहां है। विस्तार करना भी आसान है, एक सर्वर जोड़ें और चित्र अपलोड करें। और हम पहले से ही अपने सर्वर से प्रत्येक फ़ाइल पढ़ते हैं।

परियोजना Mongo का उपयोग करती है, यहां तक ​​कि इसका अपना एक अलग सर्वर है, जिस पर यह बहुत अच्छा लगता है।

सर्वर सॉफ्टवेयर

तकनीकी स्टैक परिष्कृत नहीं है, हम वर्षों से परीक्षण की गई शास्त्रीय योजना के अनुसार काम करते हैं। इनपुट पर, Nginx - स्टैटिक्स को संसाधित करता है, अपाचे को गतिशील अनुरोध भेजता है। कोड Zend फ्रेमवर्क का उपयोग करके PHP में लिखा गया है। डेटाबेस MySQL है। अस्थायी भंडारण, और कुछ मामलों में स्थायी भंडारण - MongoDB।

उपयोगकर्ता को भेजने के लिए सर्वर कैसे निर्धारित करता है? यह नगनेक्स द्वारा ही किया जाता है, यह क्लाइंट आईपी पते के आधार पर एप्लिकेशन सर्वर के बीच संतुलन बनाता है। एक आईपी से एक अनुरोध हमेशा एक ही सर्वर पर जाएगा। अनुरोध संतुलन को हाइप्रोक्सी का उपयोग करके किया जाता है, जिसे प्रत्येक सर्वर पर स्थापित किया जाना था। इसके अलावा, haproxy MySQL के लिए राउंड-रॉबिन अनुरोधों को संतुलित करता है।

बेशक, हमने केवल आधार को सूचीबद्ध किया है, बहुत सारे सॉफ़्टवेयर स्थापित किए गए हैं जो वीडियो रूपांतरण (एफएफएमपीईजी), पृष्ठभूमि कार्यों आदि से संबंधित हैं।

डेटा

फिर भी, हम भारी सामग्री के साथ काम करते हैं, इसलिए एक बहुत ही गर्म विषय डेटा बैकअप है। हमने बैकअप वृद्धिशील बनाया, लेकिन यह सब नहीं है। अपनी सुरक्षा के लिए, हम तरबूज को "तीसरे" सर्वर पर संग्रहीत करते हैं। प्लूटोव ने पहले से ही लिखा है कि अपने ब्लॉग पर टफ़ल में बैकअप कैसे कॉन्फ़िगर किए गए हैं।

निगरानी

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

निष्कर्ष

हमारे लिए, यह क्लाउड समाधानों की एक सकारात्मक अस्वीकृति है। लगभग छह महीनों में, हमारा सर्वर कभी बंद नहीं हुआ, और अपाचे की मृत्यु नहीं हुई। हम आपकी क्या इच्छा है।