Tại sao không có ví dụ về cân bằng tải phần mềm có thể mở rộng theo chiều ngang cân bằng ssl?

Tôi có một loạt các câu hỏi liên quan đến ssl, phiên địa phương và cân bằng tải dường như được kết nối với nhau, vì vậy tôi xin lỗi trước về độ dài của câu hỏi này.

Tôi có một trang web sử dụng các phiên dựa trên tệp. Bản chất của trang web là hầu hết là http, nhưng một số phần là ssl. Hiện tại, do các phiên dựa trên tệp, nên cần có bất kỳ yêu cầu ssl nào truy cập vào cùng một máy chủ như mọi yêu cầu http trước đó.

Do hạn chế về thời gian, tôi muốn làm điều dễ nhất có thể để tải cân bằng tăng lưu lượng truy cập http và ssl.

Dường như có 2 tùy chọn cho các thuật toán cân bằng tải dính:

• dựa trên ip
• dựa trên cookie

Giải pháp dựa trên ip có thể sẽ hoạt động, nhưng thuật toán băm sẽ có khả năng thay đổi máy chủ mà người dùng truy cập khi máy chủ ngừng hoạt động hoặc được thêm vào, điều không mong muốn với thiết lập phiên dựa trên tệp hiện tại. Tôi cũng cho rằng về mặt kỹ thuật, người dùng có thể thay đổi ips một cách hợp pháp trong khi duyệt trang web.

Thuật toán dựa trên cookie có vẻ tốt hơn, nhưng không thể kiểm tra cookie khi được mã hóa bằng ssl dường như có vấn đề riêng của nó.

Tôi đã tìm hiểu các ví dụ về cách tải ssl cân bằng và dường như tôi không thể tìm thấy bất kỳ ví dụ rõ ràng nào về các thiết lập có thể thực hiện cân bằng tải dựa trên cookie VÀ có thể xử lý tải ssl tăng bằng cách thêm một bộ giải mã ssl khác.

Hầu hết các ví dụ rõ ràng tôi đã thấy có bộ giải mã ssl (thường là phần cứng, apache_mod_ssl hoặc nginx) nằm giữa trình duyệt máy khách và bộ cân bằng tải. Các ví dụ thường có vẻ như thế này (được sửa đổi từ http://haproxy.1wt.eu/doad/1.3/doc/arch architecture.txt ):

      192.168.1.1 192.168.1.11-192.168.1.14
 ------- + ----------- + ----- + ----- + ----- +
        | | | | |       
     + - + - + + - + - + + - + - + + - + - + + - + - + +    
     | LB1 | | Một | | B | | C | | D |    
     + ----- + + --- + + --- + + --- + + --- +    
     apache 4 máy chủ web giá rẻ
     mod_ssl
     haproxy 

Phần giải mã ssl trong ví dụ trên dường như là một nút cổ chai tiềm năng không thể mở rộng theo chiều ngang.

Tôi đã xem haproxy và dường như có tùy chọn 'mode tcp' sẽ cho phép một cái gì đó như thế này, cho phép bạn có nhiều bộ giải mã ssl:

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

Tuy nhiên, trong thiết lập như vậy, có vẻ như bạn sẽ mất ip máy khách vì haproxy không giải mã được ssl: https://cloud-support.engineyard.com/discussions/probols/335-haproxy-not-passing-x-forwarded -cho

Tôi cũng đã xem nginx và tôi cũng không thấy bất kỳ ví dụ rõ ràng nào về bộ giải mã ssl có thể mở rộng theo chiều ngang. Dường như có nhiều ví dụ về những người có nginx là một nút cổ chai tiềm năng. Và ít nhất liên kết này dường như gợi ý rằng nginx thậm chí không có tùy chọn thiết lập giống như haproxy, nơi bạn sẽ mất ip bằng cách nói rằng nginx "không hỗ trợ chuyển các kết nối TCP trong suốt sang phụ trợ" Cách vượt qua Apache Lưu lượng SSL nginx proxy? .

Câu hỏi:

• Tại sao dường như không có nhiều ví dụ về các thiết lập thêm nhiều bộ giải mã ssl để đối phó với lưu lượng truy cập tăng?
• Có phải vì bước giải mã ssl chỉ là một nút cổ chai về mặt lý thuyết và thực tế mà nói, một bộ giải mã về cơ bản sẽ là đủ ngoại trừ các trang web có lưu lượng vô lý?
• Một giải pháp khả thi khác xuất hiện trong đầu có lẽ là bất kỳ ai có nhu cầu ssl tăng cao như vậy cũng có một cửa hàng phiên tập trung, do đó, máy khách sẽ truy cập vào máy chủ nào theo yêu cầu tuần tự. Sau đó, bạn có thể kích hoạt mod_ssl hoặc tương đương trên mọi máy chủ web.
• Giải pháp haproxy được trích dẫn ở trên dường như hoạt động (bên cạnh vấn đề IP của máy khách), nhưng có ai gặp phải một giải pháp cân bằng tải phần mềm dựa trên cookie dính sẽ hoạt động bằng cách tăng số lượng bộ giải mã trong khi giữ IP của máy khách, hoặc có lẽ về mặt kỹ thuật thì không có thể (vì bạn phải giải mã yêu cầu lấy IP của máy khách, trong trường hợp đó, chúng tôi có nút cổ chai giải mã).

Giả sử rằng tất cả những gì tôi nói là đúng, những điều này dường như là lựa chọn của tôi:

• sử dụng băm ip (xấu cho người dùng có khả năng thay đổi hợp pháp ips và cho các tình huống thêm và thả máy chủ)
• sử dụng nginx hoặc mod_ssl làm chương trình đầu tiên chạm vào yêu cầu ssl, đây sẽ là một nút cổ chai giải mã ssl tiềm năng
• sử dụng haproxy làm chương trình đầu tiên chạm vào yêu cầu ssl, đạt được khả năng mở rộng ssl ngang, nhưng không có ips được ghi ở cấp máy chủ web cho các yêu cầu ssl (có thể tạm thời ok)
• trong thời gian dài hơn, hãy tiến tới một cửa hàng phiên di động hoặc tập trung, làm cho các phiên dính không cần thiết

"Điều đơn giản nhất", trong tất cả sự nghiêm túc, là chuyển đến một cửa hàng phiên tập trung. Bạn đã phải thiết lập tất cả hệ thống ống nước này với các bộ cân bằng tải, haproxy, SSL và phần còn lại của nó, khi mỗi bit mã xử lý phiên tôi từng thấy làm cho việc cắm các công cụ lưu trữ khác nhau trở nên tầm thường bit mã và rất, rất ít phức tạp thêm giải quyết tất cả các vấn đề của bạn.

womble là đúng về cửa hàng phiên chia sẻ làm cho mọi thứ xung quanh dễ dàng hơn nhiều. Ngoài câu trả lời của anh ấy, tôi có thể mở rộng một chút về các phần cân bằng tải của câu hỏi:

Tại sao dường như không có nhiều ví dụ về các thiết lập thêm nhiều bộ giải mã ssl để đối phó với lưu lượng truy cập tăng?

PC đa lõi hiện đại có thể thực hiện vài nghìn giao dịch SSL mỗi giây. Và nếu điều đó trở thành nút cổ chai thì một thiết bị chuyên dụng từ F5 , Citrix, Cisco hoặc tương tự có thể còn nhanh hơn nữa. Vì vậy, hầu hết các trang web không bao giờ vượt quá giải pháp cân bằng tải & SSL một thiết bị tốt.

Giả sử rằng tất cả những gì tôi nói là đúng, những điều này dường như là lựa chọn của tôi:

Có các tùy chọn để mở rộng quy mô giải mã SSL theo chiều ngang, nếu bạn cần điều này.

Cách tiếp cận phổ biến là sử dụng DNS Round Robin cho các cặp trình tăng tốc SSL khả dụng cao, tức là xuất bản nhiều địa chỉ IP cho tên miền, mỗi địa chỉ IP trỏ đến một cặp trình tăng tốc SSL.

Trong trường hợp này, bạn có thể lo lắng về việc hết thời gian DNS DNS ở giữa phiên người dùng, đưa người dùng đến một máy chủ ứng dụng khác. Đó không phải là một sự xuất hiện phổ biến, nhưng nó có thể xảy ra. Một cửa hàng phiên chia sẻ là giải pháp phổ biến, nhưng nó có thể được xử lý theo những cách khác.

Như một ví dụ, bạn có thể tách giải mã SSL khỏi cân bằng máy chủ ứng dụng. Việc xử lý SSL tốn nhiều CPU hơn so với cân bằng tải cơ bản, do đó, một bộ cân bằng tải duy nhất sẽ có thể bão hòa một vài bộ tăng tốc SSL. Như thế này:

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

Như đã đề cập ở phần đầu, một cửa hàng phiên chia sẻ đơn giản hóa nhiều thứ và gần như chắc chắn là một giải pháp lâu dài tốt hơn so với việc đưa nhiều phức tạp vào lớp cân bằng tải SSL / tải của bạn.

Thật thú vị khi trả lời các câu hỏi 2 năm tuổi như thế này khi các sản phẩm đã phát triển. Ngay bây giờ haproxy hỗ trợ giao thức PROXY, cho phép nó chuyển IP của máy khách sang bước nhảy tiếp theo ngay cả trong chế độ TCP thuần túy. Nó cũng hỗ trợ SSL gốc, cũng như độ dính SSL nếu bạn muốn sử dụng nó làm lớp đầu tiên trước trang trại SSL (có thể được tạo từ các máy chủ haproxy). Vì vậy, có vẻ như yêu cầu của bạn đã đi trước một chút và việc triển khai đã bắt kịp :-)

Tôi đồng ý với womble và Jesper ở đây. Cách dễ nhất / tốt nhất là sửa mã. Tất nhiên, vì các hệ thống quản trị hệ thống, chúng ta thường không có tùy chọn đó, nhưng ngay cả trong trường hợp đó, vẫn có đủ các thủ thuật để bạn có được phần cứng hiện đại tương đối rẻ để mở rộng đủ cho dù không thực sự theo chiều ngang.

Tôi chỉ muốn đăng bài để bình luận về nơi bạn quan tâm về việc mất ip khách hàng. Trong bất kỳ giải pháp L7 / proxy chính nào, bạn có thể chèn tiêu đề X-Forwarded-For (hoặc bất cứ điều gì bạn muốn) trong yêu cầu. Sau đó, trên máy chủ web phụ trợ nhận được yêu cầu, bạn có thể thay đổi định dạng logfile để ghi lại giá trị đó trong cùng một không gian trong tệp mà nó sử dụng để đăng nhập ip máy khách layer3. Bằng cách đó, bất kỳ phần mềm phân tích nhật ký nào cũng không thấy sự khác biệt (cũng như khi bạn làm theo đuôi).

Có sự đánh đổi tất cả mọi thứ và chúng tôi chưa nghe đủ về thiết lập của bạn, nhưng với bộ ba ha-proxy, nginx và véc ni bạn có thể là một ý tưởng tốt để di chuyển cân bằng tải của bạn đến một công cụ lớp proxy. Điều đó sẽ giải quyết vấn đề ssl của bạn cũng như cung cấp cho bạn một loạt các tùy chọn mới như bộ nhớ đệm, chuyển đổi nội dung và thao tác tiêu đề.

Một số suy nghĩ ngẫu nhiên;)

Đầu tiên, bắn người quyết định sử dụng dữ liệu phiên dựa trên tệp. Không có cách nào để đọc / ghi dữ liệu từ một hệ thống tệp sẽ nhanh hơn việc quay trở lại nguồn để lấy dữ liệu bạn cần. Đây là về cách LÀM VIỆC về nó.

Cá nhân tôi chưa bao giờ thấy một tình huống lưu trữ dữ liệu trong một phiên tốt hơn là chỉ lấy nó trực tiếp từ cơ sở dữ liệu khi cần thiết. Điều đó nói rằng, tôi đã thấy việc sử dụng memcache hoặc các chiến lược bộ nhớ đệm tương tự có thể giúp quy mô trang web tới hàng triệu người dùng, nhưng điều đó thậm chí không ở trong cùng một công viên bóng như sử dụng phiên.

Thứ hai, bạn vừa tìm thấy lý do số một để không sử dụng phiên nào cả: cân bằng tải. FYI - Dính không có nghĩa là bị mắc kẹt. Ngay cả khi các phiên dính được bật, bạn vẫn có khả năng người dùng bị xáo trộn sang một máy chủ khác khi đang sử dụng ứng dụng của bạn. Điều này sẽ xảy ra vào thời điểm không thuận lợi nhất. Dính chỉ có nghĩa là bộ cân bằng tải sẽ cố gắng đẩy người dùng trở lại máy chủ mà họ đã khởi động, nhưng điều đó không có nghĩa là đảm bảo.

Điểm này thường dẫn mọi người lưu trữ phiên trở lại trong cơ sở dữ liệu ... Điều mà tôi tin là thất bại hoàn toàn . Để phiên hoạt động, nó phải được tải và viết trên mỗi yêu cầu trang. Khi được lưu trữ trong cơ sở dữ liệu (cần thiết cho các máy chủ cân bằng tải), điều này đòi hỏi hai truy vấn máy chủ: lần đầu tiên để lấy dữ liệu, lần thứ hai để ghi bất kỳ cập nhật nào.

Phần thất bại là mọi người thường sử dụng các phiên để họ không phải quay lại cơ sở dữ liệu để lấy những thứ như tên người dùng ... Nhưng nếu trang phải truy vấn cơ sở dữ liệu để tải phiên thì ... tốt, bạn sẽ có thể thấy vấn đề logic ở đây.

Chỉ có điều tồi tệ hơn với các phiên ... vì bộ xử lý trang của họ phải ghi dữ liệu phiên trở lại cơ sở dữ liệu vào cuối vòng đời của trang .. trong trường hợp có bất kỳ thay đổi nào. Có nghĩa là thay vì một truy vấn để lấy tên người dùng mà bạn kết thúc bằng hai truy vấn. Đối với mỗi tải trang duy nhất. Hơn nữa, nó có nghĩa là tuần tự hóa và giải tuần tự hóa dữ liệu có tác động hiệu suất của chính nó.

Quan điểm của tôi là: phiên là xấu xa và bạn thường tốt hơn nếu không có nó. Các trang web lưu lượng truy cập thấp chỉ chạy trên một máy chủ web không cần tăng hiệu suất có thể xảy ra; và các trang web lưu lượng truy cập cao chạy trên trang trại web bị giới hạn về tỷ lệ do nó.

Thay vì sử dụng Haproxy ở mặt trước, bạn có thể sử dụng DNS vòng tròn để thực hiện cân bằng thô giữa nhiều bộ giải mã SSL, sau đó chuyển nó sang haproxy để cân bằng tải thích hợp.