प्रस्तावना
2016 में अपडेट करें। चीजें विकसित हो रही हैं, सभी सर्वर बेहतर हो रहे हैं, वे सभी एसएसएल का समर्थन करते हैं और वेब पहले से कहीं अधिक अद्भुत है।
जब तक कहा नहीं गया है, निम्न व्यवसाय और स्टार्ट-अप में पेशेवरों की ओर लक्षित है, हजारों से लाखों उपयोगकर्ताओं का समर्थन करता है।
इन उपकरणों और आर्किटेक्चर के उपयोगकर्ताओं / हार्डवेयर / पैसा एक बहुत आवश्यकता होती है। आप इसे घर की प्रयोगशाला में या ब्लॉग चलाने के लिए आज़मा सकते हैं, लेकिन इसका कोई मतलब नहीं है।
एक सामान्य नियम के रूप में, याद रखें कि आप इसे सरल रखना चाहते हैं । बनाए रखने के लिए प्रत्येक मिडलवेयर एप्लाइड मिडलवेयर का एक और महत्वपूर्ण टुकड़ा है। पूर्णता तब प्राप्त नहीं होती है जब जोड़ने के लिए कुछ भी नहीं होता है लेकिन जब हटाने के लिए कुछ नहीं होता है।
कुछ सामान्य और दिलचस्प बातें
HAProxy (संतुलन) + nginx (php अनुप्रयोग + कैशिंग)
वेबसर्वर nginx php रनिंग है। जब nginx पहले से ही है तो यह कैशिंग और पुनर्निर्देशन को भी संभाल सकता है।
HAProxy ---> nginx-php
A ---> nginx-php
P ---> nginx-php
r ---> nginx-php
o ---> nginx-php
x ---> nginx-php
y ---> nginx-php
HAProxy (संतुलन) + वार्निश (कैशिंग) + टोमैट (जावा एप्लिकेशन)
URI (* .jpg * .css * .js) के आधार पर HAProxy वार्निश को पुनर्निर्देशित कर सकता है।
HAProxy ---> tomcat
A ---> tomcat
---> tomcat
P ---> tomcat <----+
r ---> tomcat <---+|
o ||
x ---> varnish <--+|
y ---> varnish <---+
HAProxy (संतुलन) + nginx (मेजबान और कैशिंग के लिए एसएसएल) + वेबसर्वर (आवेदन)
वेबसर्वर SSL नहीं बोलते हैं भले ही हर कोई SPE SSL ( विशेषकर यह HAProxy-WebServer लिंक निजी उपयोगकर्ता जानकारी EC2 से गुजर रहा हो )। स्थानीय nginx को जोड़ने से SSL को होस्ट तक लाने की अनुमति मिलती है। एक बार nginx होने के बाद यह कुछ कैशिंग और URL पुनर्लेखन भी कर सकता है।
नोट : पोर्ट पुनर्निर्देशन 443: 8080 हो रहा है लेकिन सुविधाओं का हिस्सा नहीं है। पोर्ट पुनर्निर्देशन करने का कोई मतलब नहीं है। लोड बैलेंसर सीधे वेबसर्वर से बात कर सकता है: 8080।
(nginx + webserver on same host)
HAProxy ---> nginx:443 -> webserver:8080
A ---> nginx:443 -> webserver:8080
P ---> nginx:443 -> webserver:8080
r ---> nginx:443 -> webserver:8080
o ---> nginx:443 -> webserver:8080
x ---> nginx:443 -> webserver:8080
y ---> nginx:443 -> webserver:8080
middleware
HAProxy: लोड बैलेंसर
मुख्य विशेषताएं :
- लोड संतुलन (टीसीपी, HTTP, HTTPS)
- एकाधिक एल्गोरिदम (राउंड रॉबिन, स्रोत आईपी, हेडर)
- सत्र की दृढ़ता
- एसएसएल समाप्ति
इसी तरह के विकल्प : nginx (बहु-उद्देश्य वेब-सर्वर एक लोड बैलेंसर के रूप में विन्यास योग्य)
विभिन्न विकल्प : क्लाउड (अमेज़ॅन ईएलबी, Google लोड बैलेंसर), हार्डवेयर (F5, Fortinet, Citrix netscaler), अन्य और वर्ल्डवाइड (DNS, anycast, CloudFlare)
HAProxy क्या करता है और आप इसका उपयोग कब करते हैं?
जब भी आपको भार संतुलन की आवश्यकता हो। HAProxy समाधान के लिए जाना है।
सिवाय जब आप बहुत सस्ते या जल्दी और गंदे चाहते हैं या आपके पास कौशल उपलब्ध नहीं है, तो आप एक ELB: D का उपयोग कर सकते हैं
सिवाय इसके कि जब आप बैंकिंग / सरकार / समान हैं, तो आपको अपने स्वयं के डेटासेंटर का उपयोग कठिन आवश्यकताओं (समर्पित अवसंरचना, भरोसेमंद फेलओवर, फ़ायरवॉल की 2 परतों, सामान की ऑडिटिंग, SLA डाउनटाइम प्रति मिनट x%, सभी में करने के लिए) के साथ करने की आवश्यकता है। आप अपने 30 एप्लिकेशन सर्वर वाले रैक के ऊपर 2 F5 लगा सकते हैं।
सिवाय इसके कि जब आप 100k HTTP (S) [और मल्टी-साइट्स] पर जाना चाहते हैं, तो आपके पास HAProxy की मल्टीप्लेयर [Global] लोड बैलेंसिंग की एक परत (क्लाउडफ्लेयर, DNS, एनीकास्ट) है। सैद्धांतिक रूप से, वैश्विक बैलेन्सर सीधे वेबर्स से बात कर सकता है जिसने HAProxy को खोदने की अनुमति दी थी। आमतौर पर, आप अपने डीटासेंटर को HAProxy (ओं) को सार्वजनिक प्रवेश बिंदु (ओं) के रूप में रखते हैं और मेजबानों में काफी संतुलन और विचरण को कम करने के लिए उन्नत विकल्पों को ट्यून करते हैं।
पर्सनल ओपिनियन : एक छोटा, सम्मिलित, ओपन सोर्स प्रोजेक्ट, जो पूरी तरह वन ट्रू प्यूरोस को समर्पित है। सबसे आसान कॉन्फ़िगरेशन (एक फ़ाइल) के बीच, मेरे जीवन में सबसे उपयोगी और सबसे विश्वसनीय ओपन सोर्स सॉफ़्टवेयर है।
Nginx: Apache कि चूसना नहीं है
मुख्य विशेषताएं :
- WebServer HTTP या HTTPS
- CGI / PHP / कुछ अन्य में एप्लिकेशन चलाएँ
- URL पुनर्निर्देशन / पुनर्लेखन
- पहुँच नियंत्रण
- HTTP हेडर हेरफेर
- कैशिंग
- रिवर्स प्रॉक्सी
इसी तरह के विकल्प : अपाचे, लाइटटैप, टॉमकैट, गुनिकॉर्न ...
अपाचे डी-फैक्टो वेब सर्वर था, जिसे दर्जनों मॉड्यूल्स के विशाल क्लस्टर के रूप में भी जाना जाता है और httpd.confटूटी हुई रिक्वेस्ट आर्किटेक्चर के शीर्ष पर हजारों लाइनें हैं । कम मॉड्यूल, (थोड़ा) सरल विन्यास और एक बेहतर कोर आर्किटेक्चर के साथ, सभी को nginx फिर से करें।
Nginx क्या करता है और आप इसका उपयोग कब करते हैं?
एक वेबसर्वर अनुप्रयोगों को चलाने का इरादा है। जब आपका एप्लिकेशन nginx पर चलने के लिए विकसित किया जाता है, तो आपके पास पहले से ही nginx होता है और आप इसकी सभी विशेषताओं का उपयोग कर सकते हैं।
सिवाय जब आपके आवेदन के नगीनेक्स पर चलने का इरादा नहीं है और नगीनक्स आपके स्टैक में पाया जाना कहीं नहीं है (तो जावा की दुकान किसी को भी?) तो नगनेक्स में कोई मतलब नहीं है। आपके वर्तमान वेबसर्वर में वेबसर्वर की विशेषताएं मौजूद हैं और अन्य कार्य उपयुक्त समर्पित टूल (HAProxy / Varnish / CDN) द्वारा बेहतर तरीके से संचालित किए जाते हैं।
सिवाय इसके कि जब आपके वेबसर्वर / एप्लिकेशन में सुविधाओं का अभाव है, कॉन्फ़िगर करना मुश्किल है और / या आप इसे देखने के बजाय नौकरी छोड़ देंगे (किसी को भी गुनगुनाएं?), तो आप URL करने के लिए सामने (यानी स्थानीय रूप से प्रत्येक नोड पर) एक nginx डाल सकते हैं। पुनर्लेखन, 301 पुनर्निर्देशन भेजें, अभिगम नियंत्रण लागू करें, एसएसएल एन्क्रिप्शन प्रदान करें और HTTP हेडर को मक्खी पर संपादित करें। [ये एक वेबसर्वर से अपेक्षित विशेषताएं हैं]
वार्निश: कैशिंग सर्वर
मुख्य विशेषताएं :
- कैशिंग
- उन्नत कैशिंग
- फाइन ग्रेन्सिंग कैशिंग
- कैशिंग
इसी तरह के विकल्प : nginx (एक कैशिंग सर्वर के रूप में बहुउद्देश्यीय वेब-सर्वर विन्यास योग्य)
अलग-अलग विकल्प : CDN (अकामाई, अमेज़ॅन क्लाउडफ्रंट, क्लाउडफ्लारे), हार्डवेयर (F5, Fortinet, Citrix Detscaler)
वार्निश क्या करता है और आप इसका उपयोग कब करते हैं?
यह कैशिंग करता है, केवल कैशिंग। यह आमतौर पर प्रयास के लायक नहीं है और यह समय की बर्बादी है। इसके बजाय CDN का प्रयास करें। ध्यान रखें कि कैशिंग एक आखिरी चीज है जिसे आपको वेबसाइट चलाते समय ध्यान रखना चाहिए।
सिवाय जब आप चित्रों या वीडियो के बारे में विशेष रूप से एक वेबसाइट चला रहे हैं तो आपको सीडीएन को अच्छी तरह से देखना चाहिए और गंभीरता से कैशिंग के बारे में सोचना चाहिए।
सिवाय इसके कि जब आप अपने खुद के हार्डवेयर को अपने स्वयं के डेटासेंटर (CDN एक विकल्प नहीं है) का उपयोग करने के लिए मजबूर होते हैं और आपके webservers स्थिर फ़ाइलों को वितरित करने में अधिक भयानक होते हैं (और अधिक webservers मदद नहीं कर रहा है) तो वार्निश अंतिम उपाय है।
सिवाय जब आपके पास ज्यादातर स्थिर-स्थिर-जटिल-गतिशील-उत्पन्न-सामग्री वाली सामग्री है (निम्न पैराग्राफ देखें) तो वार्निश आपके webservers पर बहुत सारी प्रसंस्करण शक्ति बचा सकता है।
स्टैटिक कैशिंग 2016 में खत्म हो गई है
कैशिंग लगभग विन्यास मुक्त, धन मुक्त और समय मुक्त है। बस CloudFlare, या CloudFront या Akamai या MaxCDN की सदस्यता लें। इस लाइन को लिखने में मुझे जो समय लगता है वह यह है कि कैशिंग को सेटअप करने में लगने वाला समय और बीयर को अपने हाथ में पकड़े मैं मंझला CloudFlare सदस्यता से अधिक महंगा है।
ये सभी सेवाएँ स्थिर * .css * .js * .png और अधिक के लिए बॉक्स से बाहर काम करती हैं। वास्तव में, वे ज्यादातर Cache-ControlHTTP हेडर में निर्देश का सम्मान करते हैं । कैशिंग का पहला चरण उचित कैश निर्देश भेजने के लिए अपने webservers को कॉन्फ़िगर करना है। इससे कोई फर्क नहीं पड़ता कि सीडीएन, क्या वार्निश, क्या ब्राउज़र बीच में है।
प्रदर्शन के विचार
वार्निश उस समय बनाया गया था जब औसत वेब सर्वर एक ब्लॉग पर एक बिल्ली की तस्वीर परोसने के लिए घुट रहे थे। आजकल औसत आधुनिक मल्टी-थ्रेडेड अतुल्यकालिक बुलबॉर्ड-चालित वेबसर्वर का एक एकल उदाहरण मज़बूती से पूरे देश में बिल्ली के बच्चे को वितरित कर सकता है। के सौजन्य sendfile()।
मैंने जिस अंतिम प्रोजेक्ट पर काम किया, उसके लिए मैंने कुछ त्वरित प्रदर्शन परीक्षण किए। एक एकल टोमैट इंस्टेंसेस एचटीटीपी पर प्रति सेकंड 21 000 से 33 000 स्टैटिक फ़ाइलों की सेवा कर सकता है (20B से 12kB के लिए अलग-अलग HTTP / क्लाइंट कनेक्शन गिनती के साथ परीक्षण फ़ाइलें)। निरंतर आउटबाउंड यातायात 2.4 Gb / s से परे है। उत्पादन में केवल 1 Gb / s इंटरफेस होगा। हार्डवेयर से बेहतर नहीं कर सकते, वार्निश की कोशिश में भी कोई मतलब नहीं है।
कैशिंग कॉम्प्लेक्स बदलते गतिशील सामग्री
सीडीएन और कैशिंग सर्वर आमतौर पर मापदंडों के साथ URL को अनदेखा करते हैं ?article=1843, जैसे वे सत्र कुकीज़ या प्रमाणित उपयोगकर्ताओं के साथ किसी भी अनुरोध को अनदेखा करते हैं, और वे अधिकांश MIME प्रकारों को अनदेखा करते हैं जिनमें application/jsonसे शामिल हैं /api/article/1843/info। उपलब्ध कॉन्फ़िगरेशन विकल्प हैं, लेकिन आमतौर पर ठीक नहीं है, बल्कि "सभी या कुछ भी नहीं"।
वार्निश में कस्टम जटिल नियम हो सकते हैं (वीसीएल देखें) यह परिभाषित करने के लिए कि क्या कछुआ है और क्या नहीं है। ये नियम URI, हेडर और वर्तमान उपयोगकर्ता सत्र कुकी और MIME प्रकार और सभी TOGETHER सामग्री द्वारा विशिष्ट सामग्री को कैश कर सकते हैं। यह बहुत विशिष्ट लोड पैटर्न के लिए वेबसर्वरों पर बहुत सारी प्रसंस्करण शक्ति बचा सकता है। जब वार्निश काम में है और भयानक है।
निष्कर्ष
मुझे इन सभी टुकड़ों को समझने में थोड़ा समय लगा, जब इनका उपयोग करना था और कैसे वे एक साथ फिट हुए। आशा है इससे आपको सहायता मिलेगी।
यह काफी लंबा हो गया (लिखने के लिए 6 घंटे। OMG !: O)। हो सकता है कि मुझे उस बारे में एक ब्लॉग या एक किताब शुरू करनी चाहिए। मजेदार तथ्य: उत्तर की लंबाई पर कोई सीमा नहीं लगती है।