एक बैंडविड्थ वितरण के लिए कई स्थिर फ़ाइल सर्वरों पर संतुलन लोड करने का सबसे अच्छा तरीका?


12

सबसे पहले, मैं आपको अपनी स्थिति समझाता हूँ। मैं एक साइड प्रोजेक्ट के रूप में एक काफी लोकप्रिय वेबसाइट चला रहा हूं, इसलिए मैं वास्तव में इसमें एक टन पैसा नहीं लगा सकता। मेरे पास वर्तमान में अपाचे के सामान्य अनुरोधों को भेजने के लिए HAProxy के साथ सिर्फ एक सर्वर है, और लाइटटैप्ड के लिए सभी स्थिर फ़ाइल अनुरोध हैं। यह वास्तव में अच्छी तरह से काम कर रहा है क्योंकि सभी php और पोस्ट अनुरोध Apache द्वारा संभाले जाते हैं, जबकि सभी छवियां तेजी से Lighttpd को भेजी जाती हैं (साइट ज्यादातर छवियां हैं, इसलिए यह वास्तव में महत्वपूर्ण है)। छवियों की सेवा के लिए एक उप-डोमेन स्थापित नहीं करना अच्छा होगा, क्योंकि लघु URL वास्तव में भी महत्वपूर्ण हैं, इस प्रकार HAProxy का उपयोग करने का मेरा कारण है।

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

मैंने अपने विकल्पों में बहुत सोचा है, इसलिए मैं हर एक को आपको समझाऊंगा। उम्मीद है कि आप कुछ जानकारी दे सकते हैं जिसमें से एक मेरे लिए सबसे अच्छा विकल्प है, या शायद वहाँ एक और विकल्प है जो मैंने अभी तक नहीं सोचा है।

आवश्यकताएँ:

  • यहां तक ​​कि बैंडविड्थ वितरण भी जरूरी है। मेरे पास एक बहुत शक्तिशाली सर्वर है, इसलिए स्केलिंग एक विकल्प नहीं है। मुझे अधिक बैंडविड्थ हासिल करने के लिए स्केल करने की आवश्यकता है।

  • लघु यूआरएल। मैं वास्तव में अपनी छवियों की सेवा करने के लिए img.example.com की तरह उपडोमेन सेटअप करना नहीं चाहता। example.com/image.jpg यह अब कैसा है, और मैं वास्तव में कैसे रहना पसंद करूंगा। लेकिन अगर कोई और रास्ता नहीं है, तो मैं समझता हूं।

  • अनुरोध को संभालने वाला क्लॉस्टेस्ट सर्वर वास्तव में अच्छा होगा, लेकिन जरूरी नहीं। मन में कुछ रखने के लिए।

भारोत्तोलन में बाधा:

  • यह वास्तव में करना आसान होगा क्योंकि मैं पहले से ही HAProxy का उपयोग कर रहा हूँ। हालांकि, मुझे लगता है कि बैंडविड्थ वितरित करते समय समस्या आती है। मैं इस पर गलत हो सकता है, लेकिन क्या HAProxy एक सर्वर को अनुरोध नहीं भेजता है जहां सर्वर इसे संसाधित करता है और फिर इसे HAProxy के माध्यम से क्लाइंट को वापस भेजता है? इस प्रकार, सभी ट्रैफ़िक लोड बैलेंसर के माध्यम से वापस चला जाता है, जिससे सभी सर्वरों के साथ अधिक से अधिक बैंडविड्थ का उपयोग होता है।

DNS राउंड रॉबिन:

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

डायरेक्ट सर्वर रिटर्न:

  • यह वास्तव में जटिल लगता है, लेकिन एक अच्छा विकल्प हो सकता है। क्या मैं अभी भी कुछ सर्वरों के लिए कुछ URL भेज पाऊंगा? HAProxy के साथ अभी की तरह, सही फ़ाइल एक्सटेंशन में समाप्त होने वाले प्रत्येक URL को लाइटटैप पर भेजा जाता है, जबकि अन्य एक्सटेंशनों को Apache पर भेजा जाता है। इसलिए मुझे कुछ इसी तरह की जरूरत होगी। जैसे, सभी php रिक्वेस्ट को उसी सर्वर द्वारा नियंत्रित किया जाता है जो बैलेंसिंग सॉफ़्टवेयर चला रहा हो, जबकि सभी jpg अनुरोध कई सर्वरों को भेजे जाते हैं।

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

क्या आप मेरी समस्या को समझते हैं? मुझे बताएं कि क्या मैंने कुछ सही नहीं समझाया या अगर आपको अधिक जानकारी की आवश्यकता है।


1
यह इमगुर है और हाल ही में 40 मिलियन डॉलर जुटाए हैं। : O
L1th1um

जवाबों:


3

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

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


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

परिज्ञान के लिए धन्यवाद। दुर्भाग्य से एक विडंबना यह है कि आपके निष्कर्षों की लिंक नीचे है, क्या आप इसे ठीक कर सकते हैं?
TCB13

3

कुछ जवाब:

  • हां, सभी ट्रैफ़िक HAProxy से होकर गुजरते हैं, क्योंकि यह HTTP स्तर के प्रॉक्सी के रूप में काम करता है। यदि HAProxy को किसी भिन्न सर्वर पर स्थापित किया जाता है, तो भी ऐसा ही होगा, जो एकाधिक बैक एंड सर्वर को संतुलित करता है। इस प्रकार यदि आपका होस्टिंग प्रदाता केवल 100MBit नेटवर्क पोर्ट की आपूर्ति करता है, और आप पहले से ही 100MBit को आगे बढ़ा रहे हैं, तो आपको समस्या है।
  • डोमेन के बारे में, सबसे अच्छी बात यह होगी कि आप अपने वेबऐप की तुलना में एक अलग डोमेन से छवियों की सेवा कर सकते हैं - एक उपडोमेन नहीं, एक अलग, ताकि कुकीज़ को छवि अनुरोधों पर साथ न भेजा जाए। स्टीव सॉडर्स मूल कार्य , या स्टैक ओवरफ्लो पर यहां कार्यान्वयन देखें । यदि शॉर्ट यूआरएल आपके लिए बहुत महत्वपूर्ण हैं, तो हो सकता है कि सबसे अच्छी बात यह होगी कि मुख्य URL से वेबएप को स्थानांतरित किया जाए, यानी फाइल प्रबंधन एप्लिकेशन को login.sitename.com पर ले जाएं?

क्या आपको छवि अनुरोधों पर प्रमाणीकरण की आवश्यकता है? यदि नहीं, तो Amazon S3 जैसी किसी चीज़ का उपयोग करने के बारे में कैसे? यह बड़े पैमाने पर स्केलेबल है, और डेटा ट्रांसफर लागत काफी सस्ता है। इस स्थिति में मैं Amazon S3 बकेट होस्टनाम के लिए DNS CNAME के ​​रूप में i.sitename.com जैसे somthing का उपयोग करूंगा, Amazons डॉक्स देखें । AFAIK में आपके पास CNAME के ​​रूप में मूल डोमेन नाम (sitename.com) नहीं हो सकता है, इसलिए आपको इसके लिए i.sitename.com जैसे उपडोमेन का उपयोग करना होगा।

आप कई सर्वरों पर अपनी छवियों को हैश कर सकते हैं। यानी आप एक DNS संरचना बनाते हैं जैसे login.sitename.com और a.sitename.com; b.sitename.com; c.sitename.com et cetera द ए।" और बी।" आदि सर्वरों में केवल छवियों के साथ एक फ़ाइल सिस्टम और एक हल्का HTTP सर्वर होता है (आप पहले से ही लाइटटैप का उपयोग कर रहे हैं, इसलिए इसका उपयोग जारी रखें। भविष्य की परियोजना के लिए, मैं nginx को एक बेहतर प्रतिस्थापन के रूप में देखना चाहूंगा।) जब कोई उपयोगकर्ता अपलोड करता है। एक छवि, आप एक विशिष्ट पहचानकर्ता का हैश बनाते हैं , शायद उसका उपयोगकर्ता नाम, शायद नाम, या कई पहचानकर्ताओं का संयोजन । इस हैश से, आप यह निर्धारित करते हैं कि किस सर्वर पर इमेज को स्टोर करना है।

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

मुझे नहीं पता कि आपको इसकी कितनी सस्ती ज़रूरत है - लेकिन जब आप 100MBit नेटवर्क ट्रैफ़िक को आगे बढ़ा रहे हैं, तो "सस्ता और अच्छा" जल्दी से एक भ्रम बन जाता है। शायद आपको पहले एक अच्छा व्यवसाय मॉडल प्राप्त करना चाहिए, ऐसा कुछ जो आवर्ती राजस्व प्रदान करता है, और फिर बाद में उपयुक्त तकनीक को लागू करना चाहिए?


1

मुझे लगता है कि HAProxy आपके अन्य अनुप्रयोगों के समान सर्वर पर है? आप अनुरोधों को चलाने के लिए किसी अन्य सिस्टम पर HAProxy को तोड़ सकते हैं और इसे एक सर्वर पर सामान्य अनुरोध भेज सकते हैं, और दूसरे सर्वर को छवि अनुरोध भेज सकते हैं। समस्या यह है कि सभी अनुरोध अभी भी एक बॉक्स में जा रहे हैं, और यदि आप इसकी बैंडविड्थ को संतृप्त कर रहे हैं, तो यह आपकी बहुत मदद नहीं कर सकता है।

आप कहते हैं कि छोटे यूआरएल महत्वपूर्ण हैं। क्यों? क्या वास्तव में "example.com" से "i.example.com" में छवियों को स्विच करना एक बड़ी बात है? आप अपने खुद के आईपी को लाइटटपैड के साथ अपने स्वयं के आईपी पर सेट कर सकते हैं और पूरी तरह से HAProxy को बायपास कर सकते हैं, अपनी विवाद समस्या को हल कर सकते हैं। आपको वेब ब्राउज़र का लाभ भी मिलेगा, जो एक ही बार में अधिक अनुरोधों को खोलने की अनुमति देगा क्योंकि यह उन्हें अलग-अलग डोमेन नाम देगा और अधिक समवर्ती कनेक्शन खोल सकता है। यदि एकल "i" सर्वर संतृप्त हो गया तो आप DNS राउंड-रॉबिन को एक और जोड़ने के लिए नियोजित कर सकते हैं। उम्मीद है कि उस समय तक आप एक बेहतर समाधान को लागू करने के लिए पर्याप्त राजस्व पैदा कर रहे हैं।


हां, HAProxy एक ही सर्वर पर है - मेरे पास केवल एक ही है। यहां तक ​​कि अगर मैंने इसे दूसरे सर्वर से तोड़ दिया है, तो क्या सभी डेटा अभी भी HAProxy के साथ सर्वर के माध्यम से यात्रा नहीं करेंगे, जैसा कि मैंने ऊपर बताया है? लघु URL महत्वपूर्ण हैं क्योंकि यह साइट के उद्देश्य के अनुसार है। यह ImageShack और TinyPic के बीच एक क्रॉसओवर है। URL जितना लंबा होगा, मेरी साइट का पॉइंट उतना ही कम होगा। लेकिन जैसा कि मैंने कहा, यदि केवल व्यवहार्य विकल्प एक उपडोमेन की स्थापना करना है, तो मुझे बस यह करना होगा। मैं वास्तव में हालांकि नहीं पसंद करूंगा।
एलन

1

क्या आपका होस्टिंग प्रदाता लोड संतुलन सेवाओं की पेशकश करता है? मुझे लगता है कि सबसे अच्छा समाधान है।

इसे करने का एक और तरीका है, लेकिन इसका परीक्षण करने की आवश्यकता है, अनुरोधों को फिर से लिखना (हल्के या अपाचे में) है। उदाहरण के लिए: example.com/file.html अपाचे में रहता है और example.com/image.jpg i.example.com/image.jpg पर पुनर्निर्देश करता है। सभी अनुरोधों को अपाचे के माध्यम से प्रबंधित किया जाएगा, लेकिन रिपॉंट्स (अपस्ट्रीम बैंडविड्थ) लाइटटैप सर्वर पर जा रहे हैं। डोमेन उपयोगकर्ता के लिए पारदर्शी है। फिर भी आपको परीक्षण करने की आवश्यकता है कि क्या अपाचे सभी अनुरोधों को संभाल सकता है या शायद लाइटटैप को यह काम करने दे।

आप सही हैं सभी डेटा HAProxy से गुजरते हैं ताकि आप (जहाँ तक मुझे पता है) इसके साथ सीधा सर्वर वापस न कर सकें।

अपडेट करें

में खोज रहे हैं HAProxy प्रलेखन मैं "REDIR" पैरामीटर पाया। मुझे नहीं पता कि यह अपाचे रीराइट की तरह काम कर सकता है लेकिन यह उपयोगी हो सकता है। प्रलेखन कहता है:

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

शायद यह आपके मामले के लिए काम करता है।


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

इस तरह से अलग है कि हल्का सर्वर सीधे अपने स्वयं के बैंडविड्थ का उपभोग करने वाले ग्राहक को प्रतिक्रिया भेज देगा। समस्या यह है कि Apache सर्वर बहुत सारे अनुरोधों को संभाल लेगा। मेरे उत्तर के लिए अद्यतन की जाँच करें, मुझे एक और समाधान मिला।
hdniel

1

मैं मान रहा हूं कि किसी भी बड़े आकार के चित्रों के साथ आप चित्रों को उनके मूल फ़ाइल नाम के आधार पर संग्रहीत नहीं कर रहे हैं क्योंकि आप बहुत जल्दी नाम संघर्ष में भाग लेंगे।

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

/image root/AA/AA/images  
/image root/AA/AB/images

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

नकारात्मक पक्ष यह है कि हैश सही नहीं है और टकराव हो सकते हैं। मुझे यकीन नहीं है कि इससे कैसे निपटा जाएगा। ताकि आपके हिस्से पर थोड़ा शोध हो सके। मुझे लगता है कि प्रॉक्सी में एक पुनर्लेखन नियम A3A8BBC83261.jpg कहने में सक्षम है और इसे http://img3.domain.com/A3/A8/BBC83261.jpg पर फिर से लिखना चाहिए । आप इस पर विचार नहीं कर सकते हैं कि यह एक छोटा यूआरएल है।


हां, यह ठीक है कि मैं छवियों को कैसे संग्रहीत कर रहा हूं। हालाँकि, समस्या भंडारण के साथ नहीं है, यह बैंडविड्थ वितरण के साथ है।
एलन

लेकिन अगर आप AA को एक सर्वर पर 33 और अन्य सर्वर पर 99 के माध्यम से स्टोर करते हैं, तो आप न केवल स्टोरेज की समस्या को दूर करेंगे, बल्कि बैंडविड्थ वितरण भी करेंगे।
3dinfluence

0

अपनी पोस्ट में आपने उल्लेख किया है कि आपको लगा कि DNS राउंड रॉबिन आपका सबसे अच्छा विकल्प हो सकता है लेकिन आप किसी एकल सर्वर के विफल होने के बारे में चिंतित थे ...

अगर ऐसा है तो JH सॉफ्टवेयर से सिंपल फ़ेलओवर पर एक नज़र डालें। मैंने इसे अतीत में इस्तेमाल किया है और यह बहुत अच्छी तरह से काम करता है।

http://www.simplefailover.com

मूल रूप से यह आपके सर्वर पर नज़र रखता है और जब यह देखता है कि यह नीचे चला जाता है तो यह जल्दी से DNS को फिर से मृत सर्वर को रोटेशन से बाहर खींचने के लिए फिर से लिखता है।

यहां उनकी वेबसाइट से एक स्निपेट दिया गया है:

सिंपल फेलओवर आपके सर्वर पर लगातार यह पता लगाने के लिए निगरानी करता है कि कौन से हैं और कौन से नीचे हैं, और फिर यह गतिशील रूप से आपके DNS रिकॉर्ड को तदनुसार अपडेट करता है ताकि आपका डोमेन नाम हमेशा एक कार्यात्मक सर्वर को इंगित करे।

यह वेब-सर्वर (HTTP), मेल-सर्वर (SMTP, IMAP, POP3), FTP- सर्वर और व्यावहारिक रूप से किसी भी अन्य टीसीपी / आईपी आधारित सर्वर प्रकार के साथ काम करता है।

जैसा कि पहले उल्लेख किया गया है, मैंने इसे पूर्व में वेबसाइटों और मेल सर्वर दोनों के लिए उपयोग किया है। इसने काफी अच्छा प्रदर्शन किया। ज्यादातर मामलों में विफलता बहुत जल्दी थी (2-5 मिनट का अनुमान लगाते हुए) और मैं कहूंगा कि लगभग हर कोई 15 मिनट से कम समय में विफल हो गया।

जरूरी नहीं कि सही ... लेकिन निश्चित रूप से त्वरित और आसान।

नोट: यह एक विंडोज़ उत्पाद है। मुझे यकीन नहीं है कि उनके पास एक लिनक्स संस्करण है या नहीं, लेकिन आप किसी भी सर्वर पर पसंद कर सकते हैं जो इसके DNS आधारित है।

हमारे मामले में, हमने इसे एक एक्सपी मशीन पर फेंक दिया, मशीन को रात में एक बार रिबूट करने के लिए कहा, और यह सालों तक ठीक रहा।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.