5

में स्केलिंग अनुप्रयोग पर असफलता का सिंगल प्वाइंट हमारे पास रेल-आधारित एप्लिकेशन है, तैनाती अवरोधक एडब्ल्यूएस पर बाध्यता है। वर्तमान स्कीमा निम्नलिखित परतों में शामिल हैं:एडब्ल्यूएस

  • लोड संतुलन (HAProxy)
  • रेल-आवेदन (EC2) x2
  • mysqld डेटाबेस (EC2 गुरु-दास)
  • Redis, DelayedJob पृष्ठभूमि प्रक्रियाओं
  • Wowza मीडिया सर्वर (EC2)
  • S3 संपत्ति भंडारण (साझा डेटा)

3 एसपीएफ़ हैं: लोड बैलेंसर, डेटाबेस, मीडिया सर्वर

मेरे सवालों का अतिरेक के बारे में हैं, मैं कैसे एसपीएफ़ कम कर सकते हैं:

  1. लोड संतुलन। हमारे पास माध्यमिक लोड बैलेंसर सेट करने की योजना है, लेकिन डोमेन नाम अभी भी वही है। DNS ए/एएएए राउंडोबिन फेलओवर उस मामले में अच्छा समाधान है? क्या एडब्लूएस लोड बैलेंसर उपयोग करने के लिए अच्छा है?
  2. एमएमएम (मल्टी-मास्टर प्रतिकृति प्रबंधक) विश्वसनीय है? यह रेल के साथ कैसे काम करता है (स्वतंत्र मेजबान को पढ़ें/लिखें)?
  3. Wowza मीडिया सर्वर, क्या कोई काम करने के लिए एचए समाधान हैं?

    1) लोड बैलेंसर: अपने अनुप्रयोग स्तर लोड संतुलन ज्ञान और स्वचालित रूप से मांग पर एक नया उदाहरण बनाने की क्षमता के साथ दो ha_proxy उदाहरणों बनाएं

उत्तर

5

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

स्टार्टर्स के लिए, आपके बिगस्ट एसपीएफ़ यह है कि सब कुछ अमेज़ॅन पर है। मुझे कई कारणों से एडब्ल्यूएस पसंद है, लेकिन सभी स्थितियों में जहां आपको वास्तविक उपलब्धता की आवश्यकता है, आप अनिवार्य रूप से 100% पर भरोसा करके पैर में खुद को शूटिंग कर रहे हैं। तो आपकी पहली योजना 1 से अधिक प्रदाता (क्लाउड, वीपीएस, या समर्पित) में अपनी सेवाओं को वितरित करना चाहिए।

मैं आपको एक प्रश्न पूछना चाहता हूं: यदि एडब्ल्यूएस नीचे चला जाता है, तो यह आपको कितना समय/नोटिस लेता है और इसके बारे में कुछ करता है, और बैक अप और चलाने के लिए आपको अपनी सेवाओं की कितनी जल्दी आवश्यकता है ?

कारण मैं पूछता हूं: ए/एएएए रिकॉर्ड का DNS लोड-बैलेंसिंग एक अद्भुत समाधान है, दुर्भाग्यवश आप एसआरवी/एमएक्स रिकॉर्ड के साथ वजन या प्राथमिकताओं को सेट नहीं कर सकते हैं। इसका मतलब है कि यदि एडब्ल्यूएस पूरी तरह से अनुपलब्ध हो जाता है, तो आपको आईपी को हटाने के लिए वास्तव में एक DNS परिवर्तन करना होगा। स्वचालित हो सकता है यदि आपके DNS प्रदाता के पास एक एपीआई है जो इसकी अनुमति देता है। दूसरी तरफ, DNS कैशिंग को इतने सारे स्थानों में किया जाता है कि यह DNS परिवर्तन करने के लायक नहीं हो सकता है, जिसका अर्थ है कि 1 आईपी अनुपलब्ध होने पर आपके पास 50% से 100% उपलब्धता होगी (माना जाता है कि आपके पास 2 ए रिकॉर्ड हैं) क्योंकि कुछ ब्राउज़र दूसरे आईपी को आजमा सकते हैं यदि पहला काम नहीं करता है।

मेरी राय में, एडब्ल्यूएस के उत्कृष्ट अपटाइम पर विचार करते हुए, आपको अपने डोमेन में 2 अलग-अलग आईपी (2 अलग-अलग प्रदाताओं पर) असाइन करने में कोई गलती नहीं होगी। मुझे लगता है कि 1 आईपी नीचे होने पर 0% उपलब्धता होने से बेहतर है, लेकिन आपके अनुरोधों में से 50% खोने में अभी भी कोई खुशी नहीं है।

आपके पास प्रत्येक प्रदाता पर 2 लोड-बैलेंसर हो सकते हैं, और कुछ उदाहरण/सर्वर नीचे होने पर उन्हें अन्य प्रदाता को अनुरोध अग्रेषित करने दें। दूसरे शब्दों में, आपको केवल एक प्रदाता पर दोनों प्रदाताओं पर कार्यात्मक लोड-बैलेंसर्स और कार्यात्मक सर्वर/उदाहरणों की आवश्यकता होती है। एक वैकल्पिक प्रदाता का चयन करना सुनिश्चित करें जिसमें AWS के लिए बहुत अधिक विलंबता नहीं है;)

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

मैं वूज़ा मीडिया सर्वर से बिल्कुल परिचित नहीं हूं, लेकिन एक त्वरित खोज ने कुछ चीजों को समझाया। चूंकि वाहजा आरटीएसपी (यूडीपी और टीसीपी) का उपयोग करता है, हैप्रोक्सी समाधान नहीं है क्योंकि यह केवल टीसीपी करता है। दूसरी तरफ रखी गई यूडीपी लोड-बैलेंसिंग (यह आईवीपीएस/एलवीएस का उपयोग करती है) कर सकती है। वास्तव में, यदि आपके पास लंबे प्रश्न हैं तो Keepalived का उपयोग आपके डेटाबेस गुलाम लोड-बैलेंसिंग के लिए भी किया जाना चाहिए।

एक अंतिम नोट, एस 3 स्टोरेज जैसे एडब्ल्यूएस जैसी सेवाओं को "खुद को रोल करने" के कई तरीके हैं। यदि आप एसपीएफ़ होने से बचना चाहते हैं लेकिन फिर भी आपकी एडब्ल्यूएस सेवाओं के समान कार्यक्षमता की आवश्यकता है, तो आपको ओपन सोर्स वेरिएंट जैसे कि नीलगिरी/क्लाउड डॉट कॉम/ओपनस्टैक/ग्लस्टरएफएस चलाने में देखना चाहिए। उन सभी चीजों को स्थापित करने में बहुत सारे काम शामिल हैं, लेकिन आप उस दिन से खुश रहेंगे जब आप कह सकते हैं: "तो क्या होगा अगर एक्स प्रदाता नीचे है, वाई ले जा सकता है"।

+0

के समान ही है, मैं बिल्कुल आपके बारे में सहमत हूं ** एडब्ल्यूएस ** सबसे बड़ा ** एसपीएफ़ ** है, इसलिए हम विशिष्ट एडब्ल्यूएस सामान पर निर्भर नहीं हैं। हमारी वर्तमान स्कीमा प्लेटफार्म-अज्ञेयवादी है। यदि एडब्ल्यूएस नीचे चला जाता है, तो मैं बैकअप से मीडिया-सामग्री लाने के लिए 3 घंटे और 8-12hours के दौरान एक ही वातावरण को स्थापित कर सकता हूं। – Anatoly

+0

मुझे आश्चर्य है कि कैसे गितब विफलता को संभालता है? मैं एक [ब्लॉग] में पढ़ सकता हूं (https://github.com/blog/493-github-is-moving-to-rackspace) _ रैक स्पेस पर, हमारे बुनियादी ढांचे के प्रत्येक टुकड़े में विफलता होगी। इसका मतलब है कि दो डेटाबेस सर्वर, चार वेब सर्वर, दो गिटहब पेज उदाहरण, दो जेम सर्वर उदाहरण, दो पुरालेख डाउनलोड उदाहरण, वितरित नौकरी धावक, फ़ाइल सर्वर के तीन जोड़े, और बहुत कुछ ._ – Anatoly

+0

मुझे डीबी के बारे में आपके सुझाव को समझ में नहीं आता स्केलिंग _Personally मैं अपने सभी डेटाबेस सर्वर के सामने एक लोड-बैलेंसर रखना पसंद करता हूं और उनको संभालने देता हूं जो request_ प्राप्त करते हैं। वैसे भी यह एक एसपीएफ़ भी हो सकता है। – Anatoly

1

यहाँ कुछ सुझाव हैं। एक ही ha_proxy विफलता के चारों ओर मार्ग के लिए स्वास्थ्य जांच के साथ उनके सामने अमेज़ॅन लोचदार भार संतुलन वायरस। जब कोई विफल रहता है तो गतिशील रूप से नए ha_proxy उदाहरणों में मिलाएं।

2) डेटाबेस: मुझे नहीं लगता कि MySQL में आपके प्राथमिक के स्वचालित विफलता को संभालने का एक तरीका है, लेकिन यदि आप प्रतिलिपि से पढ़ने के लिए एक परत पेश करते हैं और प्राथमिक को लिखते हैं तो आप केवल पढ़ने के लिए सक्षम हो सकते हैं एक प्राथमिक नीचे है तो कार्यक्षमता ऊपर।

3) Wowza: आप लोड संतुलन के लिए अपने ha_proxy परत के पीछे कई Wowza उदाहरणों डब्ल्यू/स्वास्थ्य की जांच तो एक भी Wowza विफलता निष्क्रिय नहीं होती मीडिया

+0

धन्यवाद, यह एक अच्छा जवाब है। मेरे प्रश्न: 1. हम जितना संभव हो एडब्ल्यूएस- स्वतंत्र होने जा रहे हैं। 2. अगर गुलाम चले गए तो पढ़ने के साथ क्या होगा? – Anatoly

+0

3. आप किस स्वतंत्र भंडारण की सलाह देते हैं? HDFS? – Anatoly

+1

मैं क्लाउड-प्लेटफॉर्म अज्ञेय रहने के लिए प्रयास करने का सम्मान करता हूं, लेकिन ईएलबी के पास आपके लोड बैलेंसर्स के लिए सार्वजनिक/स्थायी आईपी (ओं) पर प्रमुख फायदे हैं (आईसी 2 के आस-पास स्थानांतरित होने वाले आईपी के एक निश्चित पूल का उपयोग करके)। अन्यथा आपको DNS राउंड-रॉबिन या कुछ कम आदर्श समाधान का उपयोग करना होगा। साथ ही, यदि आपके मुख्य लोड-बैलेंसर होस्ट्स में से एक नाटकीय रूप से विफल रहता है, तो आपके पास एक नया आईपी प्राप्त करने के लिए DNS प्रक्षेपण देरी होगी। लोचदार आईपी के साथ ईएलबी इस सुंदरता का उपयोग करने के लायक होने के लिए पर्याप्त रूप से पर्याप्त हल करता है। – Winfield

1

स्ट्रीमिंग Scalarium हम एक समाधान है जो कम कर देता है है में सक्षम होना चाहिए एसपीएफ़ नाटकीय रूप से, आप एक जानकारी ग्राफिक Rails in the Cloud पर पृष्ठ 12.

  1. पर देख सकते हैं आप अपने ha_proxy उदाहरणों के बीच के मार्ग को अमेज़न लचीला लोड बैलेंसर का उपयोग करें। और भी सुरक्षा के लिए आप अपने आवेदन को कई उपलब्धता क्षेत्रों में विभाजित कर सकते हैं।

  2. MySQL मास्टर मास्टर प्रतिकृति सबसे आसान बात नहीं है। आपके पास एक एकल मास्टर इंस्टेंस हो सकता है और कई उपलब्धता क्षेत्रों में एकाधिक दास हो सकते हैं। फिर यदि आपका मास्टर चला गया है तो भी आप पढ़ने के कार्यों का समर्थन कर सकते हैं।मुझे लगता है कि विफलता के साथ एक असली मास्टर मास्टर संभव नहीं है।

  3. ha_proxy आपके Wowza उदाहरणों को लोड-बैलेंस करने में सक्षम होना चाहिए।

+0

उत्तर लगभग पहले – Anatoly