ขยายเซสชัน VPN ตามบทบาท แล้วตรวจสอบสำรองเมื่อเกิดความล้มเหลว

คุณเพิ่มเกตเวย์ตัวที่สอง คอนโซลแสดงสมาชิกที่สุขภาพดีสองตัว และเพดานเซสชันแทบไม่ขยับ เพราะไม่มีอะไรบอกไคลเอนต์ว่าจะไปถึงกล่องใหม่ได้อย่างไร การขยายบริการ VPN คือสองการตัดสินใจตามลำดับ กลไกใดกระจายไคลเอนต์สำหรับการเชื่อมต่อประเภทนี้ และเหลือความจุเท่าใดหลังการสูญเสียครั้งเดียวที่แย่ที่สุด หากทำสลับลำดับ จะได้การออกแบบที่ดูซ้ำซ้อนและล้มเหลวพอดีในเวลาที่ต้องใช้ เริ่มที่คอนโซล แล้วจึงคิดเลข

จับคู่กลไกกับประเภทเซสชัน

ผู้ใช้ระยะไกล คู่ค้าระหว่างไซต์ และอุโมงค์อุปกรณ์ที่เปิดตลอดเวลาไม่ใช่เซสชันที่แลกเปลี่ยนกันได้ ฟีเจอร์กระจายที่สร้างขึ้นสำหรับอย่างใดอย่างหนึ่งมักเปลี่ยนเส้นทางไคลเอนต์ระหว่างการเจรจา ซึ่งไม่มีความหมายสำหรับคู่ค้าที่มีที่อยู่คงที่และการกำหนดค่าคงอยู่แล้ว

คู่มือความพร้อมใช้งานสูงของ ASA จาก Cisco แยกความสามารถสามอย่างออกจากกัน การกระจายโหลด VPN สำหรับการเข้าถึงระยะไกล การสลับเมื่อขัดข้องแบบเก็บสถานะ และการคลัสเตอร์ระหว่างไซต์ มีเพียงอย่างแรกที่ย้ายไคลเอนต์ที่เข้าเกณฑ์จากรายการกลุ่มไปยังสมาชิก และการเชื่อมต่อ LAN ถึง LAN อยู่นอกการกระจายนั้น ตัวกระจายโหลด TCP ทั่วไปไม่สามารถแทนที่ขั้นตอนเปลี่ยนเส้นทางของโปรโตคอลเองได้ เพราะแฮนด์เชกของอุโมงค์ไม่ใช่ HTTP ธรรมดาที่พร็อกซีเขียนทับได้ ผลในทางปฏิบัติคือตัวกระจายที่รับการเชื่อมต่อแต่ยังทำให้ไคลเอนต์สร้างอุโมงค์ไม่ได้

อ่านรายการฟีเจอร์เทียบกับประเภทเซสชันของคุณก่อนสั่งอุปกรณ์ตัวที่สอง บรรทัดไลเซนส์และบรรทัดกลไกเป็นรายการแยกกัน และอย่างหนึ่งไม่ได้หมายถึงอีกอย่าง

คำนวณตัวอย่างแทนการเดา

สมมติว่าเกตเวย์สามตัวได้รับการตรวจสอบที่ 800 อุโมงค์พร้อมกันภายใต้ภาระงานที่คุณอนุมัติ รวมเป็น 2,400 เป้าหมาย 1,650 ในชั่วโมงเร่งด่วนดูสบายจนกว่าจะสูญเสียหนึ่งหน่วย แล้วคู่ที่เหลือต้องรักษา 1,650 ไว้กับ 1,600 ที่แข็ง การออกแบบล้มเหลวไปแล้ว และการปรับแต่งสลับเมื่อขัดข้องไม่สามารถแก้เลขคณิตได้

ตั้งเป้าหมายให้ชุดที่เหลือยังทำได้ ซึ่งสำหรับกลุ่มสามสมาชิกหมายถึงอยู่ต่ำกว่าสองในสามของยอดรวม อัตราส่วนนั้นเป็นสมบัติของเลขคณิต ไม่ใช่ของผลิตภัณฑ์ใด จึงคำนวณใหม่ทุกครั้งที่ตัวเลขที่ตรวจสอบของสมาชิกเปลี่ยน เก็บจำนวนที่ได้รับไลเซนส์ ค่าสูงสุดที่บันทึกไว้ และตัวเลขที่คุณวัดเองไว้ในสามคอลัมน์ เพราะแทบไม่ตรงกันและค่าที่เล็กที่สุดเป็นตัวกำหนด คอลัมน์ที่สี่สำหรับจุดสูงสุดของชั่วโมงเร่งด่วนที่สังเกตได้ช่วยให้แผนซื่อสัตย์แม้ผ่านเดือนแรกไปแล้ว

วางงบสำหรับการเชื่อมต่อใหม่ ไม่ใช่แค่สภาวะคงที่

เซสชันบนสมาชิกที่ล้มเหลวไม่ปรากฏขึ้นใหม่เงียบ ๆ ที่อื่น ขึ้นอยู่กับกลไก พวกมันย้ายไปพร้อมสถานะ เจรจาใหม่ตั้งแต่ต้น หรือรอให้แอปพลิเคชันลองใหม่ตามตารางของตัวเอง

ไคลเอนต์หลายพันรายที่ลองใหม่ภายในหนึ่งนาทีเป็นเหตุการณ์ที่ต่างจาก 1,650 ที่คงที่ และเซิร์ฟเวอร์ตรวจสอบสิทธิ์รู้สึกได้ก่อน ตรวจสอบพื้นที่พูลด้วย เพราะการเปลี่ยนเส้นทางไม่ได้สอบถามพูล สมาชิกที่จัดสรรที่อยู่ไม่ได้ยังรับไคลเอนต์แล้วทิ้งทราฟฟิกของมัน

ตรวจสอบความจุพร้อมพูลและเส้นทาง

การตรวจสอบเป็นแบบอ่านอย่างเดียวที่จับข้อผิดพลาดการออกแบบส่วนใหญ่ก่อนหน้าต่างบำรุงรักษาจะเปิด เก็บพูลต่อสมาชิก จำนวนเซสชันที่ใช้งาน และเส้นทางกลับไปยังซับเน็ตของไคลเอนต์ แล้วเปรียบเทียบแต่ละอย่างกับแผน พูลหมดและเส้นทางกลับที่หายไปทั้งคู่ปรากฏเป็นไคลเอนต์ที่ตรวจสอบสิทธิ์แล้วสูญเสียทราฟฟิก

show vpn-sessiondb summary
show running-config ip local pool
show vpn load-balancing
show route 10.40.12.0 255.255.255.0

รันการอ่านเหล่านั้นกับทุกสมาชิกในชั่วโมงเร่งด่วนปกติ ไม่ใช่ชั่วโมงเงียบ สมาชิกที่รายงานเซสชันแต่ไม่มีที่อยู่ว่างอยู่ในขีดจำกัดจริงแล้ว ไม่ว่าไลเซนส์จะว่าอย่างไร บันทึกเวอร์ชันเฟิร์มแวร์ข้างเอาต์พุตแต่ละรายการ เพราะชื่อคำสั่งเปลี่ยนระหว่างรีลีส

ฝึกการสูญเสียหนึ่งครั้งโดยเจตนา นอกเวลาทำการ และบันทึกว่าสมาชิกที่เหลือรายงานอะไรระหว่างนั้น สมาชิกที่รับการเปลี่ยนเส้นทางแต่ไม่มีพื้นที่ในพูลจะปรากฏเป็นการจัดสรรล้มเหลว ซึ่งแบนด์วิดท์เพิ่มเติมไม่เคยแก้ไข เก็บตัวเลขที่ตรวจสอบแล้วพร้อมวันที่ข้างแผน เพื่อให้การทบทวนความจุครั้งถัดไปเริ่มจากหลักฐาน ไม่ใช่ตารางไลเซนส์ เพิ่มผลของการฝึกนั้นลงในหน้าเดียวกัน แม้ตัวเลขจะตรงกับแผน