เหตุใดจึงไม่มีตัวอย่างของตัวปรับสมดุลโหลดซอฟต์แวร์ในแนวนอนปรับสมดุล ssl?

ฉันมีคำถามมากมายเกี่ยวกับ ssl เซสชันท้องถิ่นและ load balancing ซึ่งดูเหมือนจะเชื่อมโยงกันดังนั้นฉันต้องขออภัยล่วงหน้าสำหรับคำถามนี้

ฉันมีเว็บไซต์ที่ใช้ไฟล์เป็นครั้งคราว ลักษณะของเว็บไซต์คือส่วนใหญ่เป็น http แต่บางส่วนเป็น ssl ปัจจุบันเนื่องจากเซสชันที่ใช้ไฟล์เป็นสิ่งจำเป็นสำหรับการร้องขอ ssl ใด ๆ ที่จะเข้าชมเซิร์ฟเวอร์เดียวกันกับการร้องขอ http ก่อนหน้านี้

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

ดูเหมือนจะมี 2 ตัวเลือกสำหรับอัลกอริทึมการปรับสมดุลภาระแบบเหนียว:

• ตาม IP
• ตามคุกกี้

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

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

ฉัน googling สำหรับตัวอย่างเกี่ยวกับวิธีการโหลด ssl และฉันไม่สามารถหาตัวอย่างที่ชัดเจนของการตั้งค่าที่สามารถทำโหลดบาลานซ์ตามคุกกี้และสามารถจัดการกับโหลด ssl ที่เพิ่มขึ้นได้โดยการเพิ่ม ssl ตัวถอดรหัสอีกตัว

ตัวอย่างที่ชัดเจนที่สุดที่ฉันเคยเห็นมีตัวถอดรหัส ssl (โดยทั่วไปคือฮาร์ดแวร์, apache_mod_ssl หรือ nginx) ที่อยู่ระหว่างเบราว์เซอร์ไคลเอ็นต์และตัวโหลดบาลานซ์ ตัวอย่างมักจะมีลักษณะดังนี้ (แก้ไขจากhttp://haproxy.1wt.eu/download/1.3/doc/architecture.txt ):

      192.168.1.1 192.168.1.11-192.168.1.14
 ------- + ----------- + ----- + ----- + ----- +
        | | | | |       
     + - + - + + - + - + - - + - + - - + - + - + - + -    
     | LB1 | | A | | B | | C | | D |    
     + ----- + + --- + + --- + + --- + + ---    
     apache 4 เว็บเซิร์ฟเวอร์ราคาถูก
     mod_ssl
     haproxy 

ส่วนการถอดรหัส ssl ในตัวอย่างด้านบนดูเหมือนว่าจะเป็นคอขวดที่อาจไม่สามารถปรับขนาดได้ในแนวนอน

ฉันได้ดู haproxy และดูเหมือนว่าจะมีตัวเลือก 'mode tcp' ที่จะอนุญาตสิ่งนี้ซึ่งจะช่วยให้คุณมีตัวถอดรหัส ssl หลายตัว:

              haproxy
                 |
            -------------
            | |
ssl-decoder-1 ssl-decoder2
            | |
        -------------------
        | | |  
      web1 web2 web3

อย่างไรก็ตามในการตั้งค่าดังกล่าวจะปรากฏว่าคุณสูญเสีย IP ของไคลเอ็นต์เนื่องจาก haproxy ไม่ได้ถอดรหัส ssl: https://cloud-support.engineyard.com/discussions/problems/335-haproxy-not-passing-x-forwarded -สำหรับ

ฉันดู nginx ด้วยและฉันก็ไม่เห็นตัวอย่างชัดเจนของ ssl-decoders ที่ปรับขนาดได้ในแนวนอน ดูเหมือนจะมีตัวอย่างมากมายของคนที่มี nginx เป็นคอขวดที่มีศักยภาพ และอย่างน้อยลิงค์นี้แนะนำว่า nginx ไม่มีตัวเลือกในการตั้งค่าเหมือน haproxy ที่คุณจะสูญเสีย ip โดยบอกว่า nginx "ไม่สนับสนุนการส่งผ่านการเชื่อมต่อ TCP ไปยังแบ็กเอนด์อย่างโปร่งใส" วิธีการส่ง Apache การรับส่งข้อมูลผ่าน SSL พร็อกซี nginx .

คำถาม:

• ทำไมดูเหมือนไม่มีตัวอย่างเพิ่มเติมของการตั้งค่าที่เพิ่มตัวถอดรหัส ssl เพิ่มเติมเพื่อจัดการกับปริมาณการใช้ที่เพิ่มขึ้น
• เป็นเพราะขั้นตอนการถอดรหัส ssl เป็นเพียงคอขวดในเชิงทฤษฎีและในทางปฏิบัติจริง ๆ แล้วตัวถอดรหัสหนึ่งตัวจะเพียงพอแล้วยกเว้นไซต์ที่มีปริมาณการใช้งานที่ไร้สาระ?
• วิธีแก้ปัญหาที่เป็นไปได้อีกอย่างหนึ่งที่นึกถึงคือบางทีใครก็ตามที่มีความต้องการ SSL ที่เพิ่มขึ้นเช่นนั้นก็จะมีเซสชั่นสโตร์แบบรวมศูนย์ดังนั้นจึงไม่สำคัญว่าเว็บเซิร์ฟเวอร์ใดที่ไคลเอนต์จะพบลูกค้า จากนั้นคุณสามารถเปิดใช้งาน mod_ssl หรือเทียบเท่าในทุกเว็บเซิร์ฟเวอร์
• โซลูชัน haproxy ที่อ้างถึงข้างต้นดูเหมือนว่าจะทำงานได้ (นอกเหนือจากปัญหา IP ของไคลเอ็นต์) แต่มีใครบางคนที่พบโซลูชันการโหลดบาลานเซอร์ซอฟต์แวร์ที่ทำงานด้วยการใช้คุกกี้เหนียว ๆ ซึ่งจะทำงานโดยการเพิ่มจำนวนเครื่องถอดรหัสในขณะที่รักษา IP ไคลเอนต์ เป็นไปได้ (เนื่องจากคุณต้องถอดรหัสคำขอเพื่อรับ IP ของไคลเอ็นต์ซึ่งในกรณีนี้เรามีคอขวดตัวถอดรหัส)

สมมติว่าทุกสิ่งที่ฉันพูดเป็นจริงสิ่งเหล่านี้ดูเหมือนจะเป็นตัวเลือกของฉัน:

• ใช้ ip hashing (ไม่ดีสำหรับผู้ใช้ที่อาจเปลี่ยน ips อย่างถูกกฎหมายและสำหรับการเพิ่มและการปล่อยเซิร์ฟเวอร์)
• ใช้ nginx หรือ mod_ssl เป็นโปรแกรมที่ 1 แตะที่คำขอ ssl นี่จะเป็นคอขวดการถอดรหัส ssl ที่เป็นไปได้
• ใช้ haproxy เป็นโปรแกรมที่ 1 แตะที่การร้องขอ ssl, เพิ่มความสามารถในการขยาย ssl ในแนวนอน, แต่ใช้งานได้โดยไม่มี ips ที่บันทึกไว้ที่ระดับเว็บเซิร์ฟเวอร์สำหรับการร้องขอ ssl (อาจจะเป็นการชั่วคราว)
• ในระยะยาวให้ย้ายไปที่เซสชั่นมือถือหรือส่วนกลางทำให้เซสชันไม่จำเป็น

"สิ่งที่ง่ายที่สุด" ในความร้ายแรงทั้งหมดคือการย้ายไปที่ร้านเซสชั่นส่วนกลาง คุณต้องติดตั้งระบบประปาทั้งหมดนี้ด้วย load balancer, haproxy, SSL, และส่วนที่เหลือเมื่อรหัสการจัดการเซสชั่นทุกบิตที่ฉันเคยเห็นทำให้ใกล้กับเครื่องมือเก็บข้อมูลอื่นเล็กน้อย รหัสเล็กน้อยและซับซ้อนน้อยมากเป็นพิเศษแก้ปัญหาทั้งหมดของคุณ

womble ถูกต้องเกี่ยวกับร้านค้าเซสชั่นที่แชร์ทำให้ทุกอย่างง่ายขึ้น นอกเหนือจากคำตอบของเขาฉันสามารถขยายส่วนสมดุลของภาระของคำถามได้เล็กน้อย:

ทำไมดูเหมือนไม่มีตัวอย่างเพิ่มเติมของการตั้งค่าที่เพิ่มตัวถอดรหัส ssl เพิ่มเติมเพื่อจัดการกับปริมาณการใช้ที่เพิ่มขึ้น

พีซีแบบ multi-core ที่ทันสมัยสามารถทำธุรกรรม SSL ได้หลายพันรายการต่อวินาที และหากสิ่งนั้นกลายเป็นปัญหาคอขวดเครื่องใช้เฉพาะจากF5 , Citrix, Cisco หรือสิ่งที่คล้ายกันนั้นสามารถทำงานได้เร็วขึ้น ดังนั้นไซต์ส่วนใหญ่จึงไม่เติบโตเกินกว่าโซลูชัน SSL และโหลดบาลานซ์ที่มีอุปกรณ์เดียวที่ดี

สมมติว่าทุกสิ่งที่ฉันพูดเป็นจริงสิ่งเหล่านี้ดูเหมือนจะเป็นตัวเลือกของฉัน:

มีตัวเลือกสำหรับการปรับขนาดการถอดรหัส SSL ในแนวนอนหากคุณต้องการสิ่งนี้

วิธีการทั่วไปคือการใช้ DNS Round Robin กับคู่การเร่งความเร็ว SSL ที่พร้อมใช้งานสูงเช่นการเผยแพร่ที่อยู่ IP หลายโดเมนสำหรับโดเมนแต่ละที่อยู่ IP ชี้ไปที่ตัวเร่งความเร็ว SSL คู่

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

เป็นตัวอย่างหนึ่งที่คุณสามารถแยกการถอดรหัส SSL ออกจากสมดุลของแอพพลิเคชันเซิร์ฟเวอร์ การจัดการ SSL เป็น CPU ที่เข้มข้นกว่าการทำโหลดบาลานซ์พื้นฐานดังนั้นตัวโหลดบาลานซ์เดียวจึงควรทำให้ตัวเร่งความเร็ว SSL สองตัวอิ่มตัว แบบนี้:

Internet --> DNS round robin to multiple SSL accelerators --> plain HTTP to a single HTTP load balancer --> plain HTTP to multiple application servers

ดังที่กล่าวไว้ในตอนต้นเซสชันเซสชันที่ใช้ร่วมกันจะลดความซับซ้อนของสิ่งต่าง ๆ และเป็นวิธีแก้ปัญหาระยะยาวที่ดีกว่าการใส่ความซับซ้อนมากมายใน SSL / load balancing layer

มันสนุกที่จะตอบคำถาม 2 ปีเช่นนี้เมื่อผลิตภัณฑ์มีวิวัฒนาการ ตอนนี้ haproxy สนับสนุนโพรโทคอล PROXY ซึ่งอนุญาตให้ส่ง IP ของไคลเอ็นต์ไปยัง hop ถัดไปแม้ในโหมด TCP บริสุทธิ์ นอกจากนี้ยังรองรับ SSL เนทีฟเช่นเดียวกับ SSL stickiness หากคุณต้องการใช้เป็นเลเยอร์แรกหน้าฟาร์ม SSL (อาจทำจากเซิร์ฟเวอร์ haproxy) ดังนั้นดูเหมือนว่าคำขอของคุณจะค่อนข้างเร็วและการใช้งานได้ทัน :-)

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

ฉันแค่ต้องการโพสต์เพื่อแสดงความคิดเห็นว่าคุณกังวลเกี่ยวกับการสูญเสียลูกค้า -ip หรือไม่ ในโซลูชัน L7 / พร็อกซีหลัก ๆ คุณสามารถแทรกส่วนหัว X-Forwarded-For (หรืออะไรก็ได้ที่คุณต้องการ) ในคำขอ จากนั้นในเว็บเซิร์ฟเวอร์แบ็กเอนด์ที่ได้รับการร้องขอคุณสามารถเปลี่ยนรูปแบบไฟล์บันทึกเพื่อบันทึกค่านั้นในพื้นที่เดียวกันในไฟล์ที่ใช้บันทึกไฟล์ไคลเอนต์ layer3 ด้วยวิธีนี้ซอฟต์แวร์แยกวิเคราะห์บันทึกจะไม่เห็นความแตกต่าง

มีการแลกเปลี่ยนกับทุกสิ่งทุกอย่างและเราไม่เคยได้ยินเรื่องการตั้งค่าของคุณพอรู้ แต่ด้วยท่วงทำนองที่คุณไม่สามารถไปผิดได้, nginx, และวานิชคุณควรย้ายสมดุลย์ของคุณ ไปยังเครื่องมือ proxy-layer ซึ่งจะช่วยแก้ปัญหา ssl ของคุณรวมถึงให้คุณมีตัวเลือกใหม่ ๆ มากมายเช่นแคชการสลับเนื้อหาและการจัดการส่วนหัว

บางความคิดแบบสุ่ม;)

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

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

ประการที่สองคุณเพิ่งพบว่าเหตุผลอันดับหนึ่งที่จะไม่ใช้เซสชันเลย: load balancing FYI - Sticky ไม่ได้แปลว่า Stuck แม้ในขณะที่เปิดเซสชัน Sticky คุณก็ยังสามารถเรียกใช้ความเป็นไปได้ที่แท้จริงของผู้ใช้ที่ถูกสับเปลี่ยนไปยังเซิร์ฟเวอร์อื่นในระหว่างการใช้แอปของคุณ สิ่งนี้จะเกิดขึ้นในเวลาที่ไม่เหมาะสมที่สุด Sticky นั้นหมายถึงว่า load balancer จะพยายามผลักผู้ใช้กลับไปที่เซิร์ฟเวอร์ที่พวกเขาเริ่ม แต่มันก็ไม่ได้รับประกัน

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

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

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

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

แทนที่จะใช้ Haproxy ที่อยู่ด้านหน้าคุณสามารถใช้ round robin DNS เพื่อทำการปรับสมดุลแบบหยาบระหว่างตัวถอดรหัส SSL หลายตัวจากนั้นส่งต่อไปยัง haproxy สำหรับการทำโหลดบาลานซ์ที่เหมาะสม