การจัดการเซิร์ฟเวอร์ Windows
IIS: เว็บเซิร์ฟเวอร์ Windows ถือเป็นเรื่องจริงจัง
IIS เป็นเว็บเซิร์ฟเวอร์ที่สร้างไว้ใน Windows Server: กลุ่มแอปพลิเคชันสำหรับการแยกกระบวนการและการรีไซเคิล โมดูลสำหรับการรับรองความถูกต้องและการเขียน URL ใหม่ และการผสานรวมกับ Microsoft Stack (ASP.NET, ส่วนหน้าแบบ ADFS, การทำพร็อกซีย้อนกลับคลาส ARR) มันสมควรได้รับสิ่งที่ดีกว่าแบบแผนของมันในฐานะตัวแทน Apache ที่เงอะงะ ขีดจำกัดที่แท้จริงของมันคือสถาปัตยกรรม และการรู้ว่าจุดไหนที่ทำให้มันสามารถจัดการได้
ประเด็นสำคัญ
- กลุ่มแอปพลิเคชันเป็นหน่วยการจัดระเบียบหลัก: แต่ละพูลเป็นขอบเขตกระบวนการ w3wp ที่มีเอกลักษณ์เฉพาะตัว การตั้งค่าการรีไซเคิล และโหมดไปป์ไลน์ของตัวเอง แนวทางปฏิบัติในการกำหนดขนาดมาตรฐานคือหนึ่งพูลต่อแอปพลิเคชัน เนื่องจากรีไซเคิลการแยกความผิดพลาดโดยไม่ต้องทำลายเพื่อนบ้าน
- การรีไซเคิลจำเป็นต้องมีการกำกับดูแล: การรีไซเคิลตามระยะเวลาตามค่าเริ่มต้น (มักเป็นเวลา 29 ชั่วโมง) เกิดขึ้นเพื่อปกปิดการรั่วไหล แต่จะทำให้เซสชั่นลดลงโดยไม่ทราบสาเหตุ ปรับเวลาการรีไซเคิล, โหลดล่วงหน้าของ AlwaysRunning และระยะหมดเวลาที่ไม่ได้ใช้งานโดยเจตนา แทนที่จะยอมรับค่าเริ่มต้น
- โมดูลมีการกำหนดค่า: เขียน URL ใหม่, ARR (การพร็อกซีย้อนกลับ), การรับรองความถูกต้องของ Windows/Forms และ Let's Encrypt ผ่านโมดูล ACME มิเรอร์โมดูลทั่วไปของ Apache กับโมดูล IIS แต่ดูหน่วยความจำเนื่องจากการซ้อนโมดูลเป็นวิธีที่กล่อง IIS ขยายตัว
- รูปแบบพร็อกซีแบบย้อนกลับนั้นถูกต้องตามกฎหมาย: ARR ที่ด้านหน้าเว็บฟาร์มของ IIS อย่างน้อยหนึ่งรายการจะสะท้อนรูปแบบ nginx-as-proxy โดยที่การรับส่งข้อมูลส่วนใหญ่เป็นแบบคงที่หรือการใช้พร็อกซีแบบย้อนกลับของ API ตามขนาด nginx หรือ LB เฉพาะจะชนะในด้านต้นทุนและความเรียบง่าย
- การกำหนดค่าคือ XML ภายใต้ประทุน (applicationHost.config บวก web.config); การแปลงการกำหนดค่าและข้อมูลเริ่มต้นเผยแพร่ได้ดีผ่าน CI แต่การต่อสู้การกำหนดค่าระหว่างระดับลำดับชั้นนั้นเป็นเรื่องจริง เก็บแหล่งความจริงแหล่งเดียวเท่าที่เป็นไปได้
- ทางลัดด้านประสิทธิภาพ: การแคชเอาต์พุต (โหมดเคอร์เนลหากเป็นไปได้), การบีบอัด (การอุ่นการบีบอัดแบบคงที่ล่วงหน้า), โมดูล WOFF/Brotli และกฎแคช ARR การตั้งค่า SSL/TLS เป็นไปตามเรื่องราวของชุดการเข้ารหัสของ Windows (TLS 1.2/1.3 ผ่านนโยบายการลงทะเบียนหรือการเข้ารหัสลับ) ซึ่งเป็นที่มาของการค้นพบผู้ตรวจสอบส่วนใหญ่
บันทึกจากหน้างาน
กล่อง IIS ที่เราสืบทอดมานั้นมีพูลแอปพลิเคชันที่รีไซเคิลตามค่าเริ่มต้น 29 ชั่วโมง ซึ่งหมายความว่าตั๋วออกจากระบบของลูกค้าทุกใบจะอยู่ในปฏิทิน การตั้งค่า AlwaysRunning และการปรับจูนแบบตรงไปตรงมาจะหยุดตั๋ว ลูกค้าคิดว่าเราพบจุดบกพร่อง เราพบค่าเริ่มต้น
คำถามที่พบบ่อย
IIS ควรอยู่หลัง nginx ในไฮบริดสแตกหรือไม่
รูปแบบทั่วไปที่ตรวจสอบแล้ว: nginx ยุติ TLS ให้บริการไฟล์คงที่ และคำขอพร็อกซีย้อนกลับแบบไดนามิกไปยังกลุ่มแอป IIS โดยรวมประสิทธิภาพของ Edge เข้ากับการรวมแอปพลิเคชันของ Microsoft ชิ้นส่วนที่เคลื่อนไหวเพิ่มเติมจำเป็นต้องได้รับการตรวจสอบจากแดชบอร์ดเดียวกัน
มีการกำหนดค่าแบบยืดหยุ่น .htaccess-class หรือไม่
IIS ใช้ web.config กับกฎการเขียน URL และส่วนข้อจำกัด IP/ความปลอดภัยในระดับไดเร็กทอรี มีพฤติกรรมที่เทียบเท่ากัน แต่ลำดับชั้นการกำหนดค่า IIS แตกต่างกัน และต้องเรียนรู้ไวยากรณ์โมดูลการเขียนใหม่แยกต่างหาก
อะไรทำให้เกิดการออกจากระบบแบบสุ่มบนแอป IIS
โดยปกติแล้วการรีไซเคิลจะจับคู่กับสถานะเซสชันที่กำลังดำเนินการหรือฟาร์มที่ขยายขนาดออกโดยไม่มีเซสชันที่ติดหนึบ/การจัดตำแหน่งคีย์เครื่อง การแก้ไขคือการกำหนดค่า (เซิร์ฟเวอร์สถานะเซสชันหรือ AlwaysRunning) ไม่ใช่การรีบูตลึกลับ
มันเปรียบเทียบกับ Apache และ nginx โดยรวมได้อย่างไร?
ในกรณีที่แอปพลิเคชันเป็น .NET บน Windows IIS เป็นตัวเลือกที่สอดคล้องกัน สำหรับคุณสมบัติ Linux และบทบาท Edge/พร็อกซี nginx หรือ Apache เป็นตัวเลือกที่ตรงไปตรงมาตามการเปรียบเทียบเว็บเซิร์ฟเวอร์ของเรา
Kinetikatech ช่วยเรื่อง การจัดการเซิร์ฟเวอร์ windows ได้อย่างไร
ข้อเสนอง่าย ๆ แบบนี้: เร็วๆ นี้: การตรวจสอบ แพตช์ และการป้องกันแบบ brute-force สำหรับ Windows Server, ระเบียบวินัยเดียวกันตลอด 24 ชั่วโมงทุกวัน, เครื่องมือแบบเนทีฟ ส่งให้บริการ การเฝ้าระวัง Windows Serverและการจัดการเซิร์ฟเวอร์ ของเราดูแล มีการประเมินอย่างเหมาะสม ลงมือแบบสะอาด และมีคนเฝ้าตลอด 24 ชั่วโมง