Kinh nghiệm sử dụng cân bằng tải phần mềm so với cân bằng tải phần cứng?

Question

Ứng dụng ASP.NET mà tôi hiện đang chịu trách nhiệm cho công việc trong ngày của tôi đã đạt đến giới hạn về khả năng mở rộng bên trong một máy chủ duy nhất. Rõ ràng chúng tôi đang làm việc hướng tới phiên di chuyển ra khỏi quá trình và thử nghiệm và hy vọng ngày triển khai sẽ đến gần. Tôi muốn vẽ trên những trải nghiệm của những người sử dụng tích hợp cân bằng tải trong Windows so với một giải pháp thiết bị chẳng hạn như Baracudda, Coyote Point, F5 ... Bạn đã bắt đầu với một và chuyển sang khác và tại sao?

suy nghĩ và tư vấn đánh giá cao trước ...

Answer 1

Tôi có một số kinh nghiệm về các giải pháp cân bằng tải, tuy nhiên nó thực sự phụ thuộc vào cách mạng và phần mềm của bạn được thiết kế như thế nào đi.

Về giải pháp tôi đã gặp phải:

Được xây dựng vào cân bằng tải trong các cửa sổ hoạt động tốt cho hầu hết các trường hợp, mặc dù bạn cần phải đảm bảo các ứng dụng của bạn có thể xử lý một cách chính xác phiên nếu họ không dính. v.v.

Tôi đã sử dụng các sản phẩm F5, chủ yếu là giải pháp lưu vào bộ nhớ cache, tuy nhiên chúng quá phức tạp đối với chúng tôi. Chúng tôi hiện đang di chuyển chúng, vì các nhà phát triển không sử dụng chúng một cách chính xác vì chúng quá phức tạp. (Xin lưu ý đây là những sản phẩm F5 khá cũ.)

Hiện tại chúng tôi đang thử nghiệm phần cứng cân bằng tải từ Foundry, và chúng tôi có thể đi với chúng vì chúng sẽ phù hợp với kiến ​​trúc mạng của chúng tôi. (Đó là khá phức tạp.).

Vì vậy, tôi muốn nói, nếu bạn muốn một giải pháp đơn giản sử dụng cân bằng tải trong cửa sổ (Nếu ứng dụng của bạn sẽ hoạt động chính xác.).

Nếu không sử dụng cái gì phức tạp hơn.

Bất kể bạn cân bằng tải nào, bạn sẽ làm cho kiến ​​trúc của bạn trở nên phức tạp hơn. Vì vậy, hãy lập kế hoạch và kiểm tra cẩn thận.

Answer 2

một vài suy nghĩ

• WLBS thường là "đủ tốt" để giúp bạn bắt đầu với NLB. Tuy nhiên, giống như bất kỳ kỹ sư vĩ đại nào khác - bạn cần phải "đo lường để biết"
• không chỉ về việc tăng quy mô của nó về dự phòng mềm hoặc cứng. Chúng tôi thường NLB giữa các máy ảo chỉ để cung cấp cho chúng tôi dự phòng mềm.
• NLB áp dụng nhiều cho mạng sau cũng như các mặt trước
• tăng tốc để tăng tốc phần cứng mang lại cho bạn mức độ chi phí ops mới. Hỗ trợ chuyên môn đào tạo mới, leo thang, v.v.
• tìm tăng tốc phần cứng để cung cấp cho bạn nhiều hơn NLB, ví dụ: Bảo vệ DDoS, SSL, Nén, Bộ nhớ đệm, Chuyển đổi nội dung, Tập hợp kết nối, Đệm.
• giáo dục cả hai Devs & Ops SE về lợi ích tăng tốc phần cứng, một thiết kế tuyệt vời có thể hợp nhất dòng giữa các hoạt động mạng và phát triển ứng dụng.
• phần cứng đệm trên chính nó đã làm cho ASP.NET của chúng tôi nhanh hơn khoảng 30% chỉ bằng cách giảm thời gian GC của chúng tôi.
• chuyển đổi nội dung có thể cho phép bạn hợp nhất một cách minh bạch hoặc di chuyển các hệ thống khác nhau. Chúng tôi đã hợp nhất MSDN & nền tảng MSDN2 vào một không gian url duy nhất bằng cách sử dụng kỹ thuật này.
• phiên stickyness là một con dao lưỡi kép - không nên lạm dụng - một lần nữa không thay thế cho kỹ thuật tốt - đo lường và kiểm tra tất cả mọi thứ

Chúng tôi sử dụng cả hai WLBS và NLB trong mạng của chúng tôi - chi phí thường xuyên thúc đẩy cuộc đàm thoại. Hãy xem cả hai công cụ trong hộp công cụ, tìm hiểu sắc thái, mô hình chi phí, v.v.

Answer 3

thiết lập cụm apache mod_proxy. http://www.howtoforge.com/high_availability_loadbalanced_apache_cluster

dễ dàng hơn sau đó bạn nghĩ, và ở một phần nhỏ của giá

Answer 4

F5 đi kèm với SSL Acceleration Chip. Mã hóa SSL & Giải mã (nó rất mạnh CPU) bằng cách sử dụng các máy chủ ứng dụng làm cho chúng làm chậm quá trình xử lý các yêu cầu thực tế. Trong lưu lượng SSL chung được chấm dứt tại F5 và lưu lượng truy cập http bình thường được gửi đến máy chủ ứng dụng. Điều này được gọi là SSL Offloading tại cân bằng tải. Sinces F5 thực hiện Mã hóa SSL này & Giải mã bằng chip (Phần cứng) nhanh hơn từ 30 đến 40 lần so với mã hóa thông thường & lần giải mã.