विंडोज़ सर्वर प्रबंधन
आईआईएस: विंडोज वेब सर्वर, गंभीरता से लिया गया
IIS विंडोज सर्वर में निर्मित वेब सर्वर है: प्रक्रिया अलगाव और रीसाइक्लिंग के लिए एप्लिकेशन पूल, प्रमाणीकरण और यूआरएल पुनर्लेखन के लिए मॉड्यूल, और माइक्रोसॉफ्ट स्टैक (एएसपी.नेट, एडीएफएस-फेसिंग फ्रंटेंड, एआरआर-क्लास रिवर्स प्रॉक्सीइंग) के साथ एकीकरण। यह एक अनाड़ी अपाचे विकल्प के रूप में अपने स्टीरियोटाइप से बेहतर का हकदार है; इसकी वास्तविक सीमाएँ वास्तुशिल्प हैं, और यह जानना कि वे कहाँ काटते हैं, इसे प्रबंधनीय बनाता है।
मुख्य बिंदु
- एप्लिकेशन पूल मुख्य आयोजन इकाई हैं: प्रत्येक पूल अपनी पहचान, रीसायकल सेटिंग्स और पाइपलाइन मोड के साथ एक w3wp प्रक्रिया सीमा है; मानक आकार देने का अभ्यास प्रति एप्लिकेशन एक पूल है, क्योंकि पड़ोसियों को हटाए बिना क्रैश-आइसोलेट को रीसायकल करता है।
- पुनर्चक्रण के लिए प्रशासन की आवश्यकता है: लीक को छुपाने के लिए डिफ़ॉल्ट आवधिक पुनर्चक्रण (अक्सर 29 घंटे) मौजूद होते हैं, लेकिन वे अस्पष्टीकृत सत्र ड्रॉप का कारण बनते हैं; डिफ़ॉल्ट स्वीकार करने के बजाय रीसायकल समय, ऑलवेज रनिंग प्रीलोड और निष्क्रिय टाइमआउट को जानबूझकर ट्यून करें।
- मॉड्यूल में कॉन्फ़िगरेशन होता है: यूआरएल रीराइट, एआरआर (रिवर्स प्रॉक्सीइंग), विंडोज/फॉर्म ऑथ, और एसीएमई मॉड्यूल के माध्यम से एन्क्रिप्ट करें; आईआईएस मॉड्यूल के साथ अपाचे के सामान्य मॉड्यूल को प्रतिबिंबित करें, लेकिन मेमोरी पर ध्यान दें क्योंकि मॉड्यूल स्टैकिंग के कारण आईआईएस बॉक्स फूलते हैं।
- रिवर्स-प्रॉक्सी आकार वैध है: एक या कई IIS वेब फ़ार्म के सामने ARR nginx-as-प्रॉक्सी पैटर्न को प्रतिबिंबित करता है; जहां ट्रैफ़िक अधिकतर स्थिर होता है या एपीआई बड़े पैमाने पर रिवर्स प्रॉक्सी करता है, वहां nginx या एक समर्पित LB लागत और सरलता के मामले में जीत जाता है।
- कॉन्फ़िगरेशन हुड के नीचे XML है (एप्लिकेशनहोस्ट.कॉन्फिग प्लस वेब.कॉन्फिग); कॉन्फ़िगरेशन परिवर्तन और बीज डेटा सीआई के माध्यम से ठीक से प्रकाशित होता है, लेकिन पदानुक्रम स्तरों के बीच कॉन्फ़िगरेशन लड़ाई वास्तविक है; जहां संभव हो सत्य का एक ही स्रोत रखें।
- प्रदर्शन शॉर्टकट: आउटपुट कैशिंग (कर्नेल-मोड जहां संभव हो), संपीड़न (स्थैतिक संपीड़न प्रीवार्मिंग), डब्ल्यूओएफएफ/ब्रॉटली मॉड्यूल, और एआरआर कैश नियम; एसएसएल/टीएलएस सेटिंग्स विंडोज सिफर सुइट कहानी (रजिस्ट्री या क्रिप्टो नीति के माध्यम से टीएलएस 1.2/1.3) का पालन करती हैं, जहां से अधिकांश ऑडिटर निष्कर्ष आते हैं।
क्षेत्रीय टिप्पणी
हमें जो IIS बॉक्स विरासत में मिला था, उसमें 29-घंटे के डिफॉल्ट पर एप्लिकेशन पूल रीसाइक्लिंग थे, जिसका मतलब था कि प्रत्येक ग्राहक लॉगआउट टिकट एक कैलेंडर पर था। ऑलवेज़रनिंग सेटिंग और ईमानदार ट्यूनिंग ने टिकटें रोक दीं; ग्राहक ने सोचा कि हमें एक बग मिला है। हमें एक डिफ़ॉल्ट मिला.
अक्सर पूछे जाने वाले प्रश्न
क्या IIS को हाइब्रिड स्टैक में nginx के पीछे बैठना चाहिए?
एक सामान्य, सत्यापित पैटर्न: nginx TLS को समाप्त करता है, स्थिर फ़ाइलें प्रदान करता है, और IIS ऐप पूल में डायनेमिक अनुरोधों को रिवर्स-प्रॉक्सी करता है, Microsoft एप्लिकेशन एकीकरण के साथ एज दक्षता का संयोजन करता है; अतिरिक्त गतिशील भागों को समान डैशबोर्ड से निगरानी की आवश्यकता होती है।
क्या .htaccess-क्लास लचीला कॉन्फ़िगरेशन उपलब्ध है?
IIS निर्देशिका स्तर पर URL पुनर्लेखन नियमों और IP/सुरक्षा प्रतिबंध अनुभागों के साथ web.config का उपयोग करता है; समतुल्य व्यवहार मौजूद है, लेकिन IIS कॉन्फ़िगरेशन पदानुक्रम भिन्न हैं और पुनर्लेखन मॉड्यूल सिंटैक्स को अलग से सीखना होगा।
IIS ऐप्स पर रैंडम लॉगआउट का क्या कारण है?
आम तौर पर रीसाइक्लिंग को इन-प्रोसेस सत्र स्थिति या चिपचिपा सत्र/मशीन कुंजी संरेखण के बिना स्केल-आउट फ़ार्म के साथ जोड़ा जाता है; समाधान कॉन्फ़िगरेशन (सत्र स्थिति सर्वर या ऑलवेज़ रनिंग) है, मिस्ट्री रीबूट नहीं।
कुल मिलाकर इसकी तुलना Apache और nginx से कैसे की जाती है?
जहां विंडोज़ पर एप्लिकेशन .NET है, आईआईएस सुसंगत विकल्प है; लिनक्स एस्टेट और एज/प्रॉक्सी भूमिकाओं के लिए, nginx या Apache हमारे वेब-सर्वर तुलना के अनुसार सबसे अच्छे विकल्प हैं।
विंडोज़ सर्वर प्रबंधन में Kinetikatech कैसे सहायता करता है
यही हमारा रोज़ का काम है: जल्द ही आ रहा है: विंडोज़ सर्वर के लिए निगरानी, पैचिंग और ब्रूट-फोर्स सुरक्षा, समान 24/7 अनुशासन, देशी टूलींग। हमारी Windows Server निगरानी और सर्वर प्रबंधन सेवा इसे शुरू से अंत तक कवर करती है: आकलन, कार्यान्वयन, 24/7 निगरानी और 30 मिनट में आपात प्रतिक्रिया।