Kiến trúc đề nghị cho cân bằng tải ASP.NET trang web

Question

CẬP NHẬT 2009-05-21

Tôi đã thử nghiệm phương pháp # 2 của việc sử dụng một mạng chia sẻ duy nhất. Nó được dẫn đến một số vấn đề với Windows Server 2003 dưới tải:

http://support.microsoft.com/kb/810886

cuối cập nhật

tôi đã nhận được một đề nghị cho một trang web ASP.NET mà làm việc như sau:

Phần cứng cân bằng tải -> 4 máy chủ web IIS6 -> SQL Server DB với cụm chuyển đổi dự phòng

Đây là vấn đề ...

Chúng tôi đang chọn nơi lưu trữ tệp web (aspx, html, css, hình ảnh). Hai tùy chọn đã được đề xuất:

1) Tạo các bản sao giống hệt nhau của các tệp web trên mỗi máy chủ IIS.

2) Đặt một bản sao của các tệp web trên một mạng chia sẻ có thể truy cập bởi 4 máy chủ web. Các webroots trên 4 máy chủ IIS sẽ được ánh xạ tới một mạng chia sẻ.

Giải pháp nào tốt hơn? Tùy chọn 2 rõ ràng là đơn giản hơn cho việc triển khai vì nó yêu cầu sao chép các tập tin vào chỉ một vị trí duy nhất. Tuy nhiên, tôi tự hỏi liệu có vấn đề về khả năng mở rộng hay không vì bốn máy chủ web đều truy cập một tập hợp các tệp. IIS sẽ lưu các tệp này cục bộ? Nó sẽ nhấn chia sẻ mạng trên mọi yêu cầu của khách hàng? Ngoài ra, sẽ truy cập vào một mạng chia sẻ luôn luôn chậm hơn so với nhận được một tập tin trên một ổ đĩa cứng địa phương? Liệu tải trên mạng chia sẻ trở nên tồi tệ hơn đáng kể nếu nhiều máy chủ IIS được thêm vào?

Để cung cấp cho phối cảnh, đây là trang web hiện nhận được ~ 20 triệu lần truy cập mỗi tháng. Ở đỉnh cao gần đây, nó đã nhận được khoảng 200 lượt truy cập mỗi giây.

Vui lòng cho tôi biết nếu bạn có trải nghiệm cụ thể với thiết lập như vậy. Cảm ơn các đầu vào.

CẬP NHẬT 2009-03-05

Để làm rõ tình hình của tôi - những "triển khai" trong hệ thống này thì ngày càng thường xuyên hơn so với một ứng dụng web điển hình. Trang web là giao diện người dùng cho CMS trở lại văn phòng. Mỗi lần nội dung được xuất bản trong CMS, các trang mới (aspx, html, v.v.) được tự động đẩy lên trang web trực tiếp. Các triển khai về cơ bản là "theo yêu cầu". Về mặt lý thuyết, sự thúc đẩy này có thể xảy ra vài lần trong vòng một phút hoặc hơn. Vì vậy, tôi không chắc chắn nó sẽ là thực tế để triển khai một máy chủ web tại thời điểm. Suy nghĩ?

Answer 1

Tôi muốn chia sẻ tải giữa 4 máy chủ. Nó không phải là nhiều.

Bạn không muốn một điểm tranh chấp nào đó khi triển khai cũng như không có điểm lỗi duy nhất trong sản xuất.

Khi triển khai, bạn có thể thực hiện chúng 1 lần. Các công cụ triển khai của bạn nên tự động hóa điều này bằng cách thông báo cho cân bằng tải rằng máy chủ không nên được sử dụng, triển khai mã, bất kỳ công việc biên dịch trước nào cần thiết và cuối cùng thông báo cho bộ cân bằng tải mà máy chủ sẵn sàng.

Chúng tôi đã sử dụng chiến lược này trong một trang trại máy chủ web hơn 200 và nó hoạt động tốt để triển khai mà không bị gián đoạn dịch vụ.

Answer 2

Nếu mối quan tâm chính của bạn là hiệu suất, tôi cho rằng đó là vì bạn chi hết số tiền này vào phần cứng, thì việc chia sẻ hệ thống tập tin mạng chỉ nhằm mục đích thuận tiện là không có ý nghĩa. Ngay cả khi các ổ đĩa mạng hoạt động cực kỳ cao, chúng sẽ không hoạt động tốt như các ổ đĩa gốc.

Việc triển khai nội dung web của bạn cũng được tự động hóa (phải không?) Để thực hiện nó theo bội số không thực sự gây ra nhiều bất tiện.

Nếu nó phức tạp hơn bạn đang cho phép, thì có thể một cái gì đó như DeltaCopy sẽ hữu ích để giữ cho các đĩa đó được đồng bộ hóa.

Answer 3

Một lý do chia sẻ trung tâm là xấu bởi vì nó làm cho NIC trên máy chủ chia sẻ nút cổ chai cho toàn bộ trang trại và tạo ra một điểm lỗi duy nhất.

Answer 4

Những gì bạn đạt được trên NLB với 4IIS, bạn mất nó với BottleNeck bằng máy chủ ứng dụng.

Để có khả năng mở rộng, tôi sẽ đề xuất các ứng dụng trên máy chủ web giao diện người dùng.

Ở đây trong công ty của tôi, chúng tôi đang triển khai giải pháp đó. Ứng dụng .NET ở đầu phía trước và máy chủ APP cho Sharepoint + Cluster SQL 2008.

Hy vọng điều đó sẽ hữu ích!

liên quan!

Answer 5

Sử dụng công cụ triển khai, với quy trình triển khai từng lần một và phần còn lại của hệ thống tiếp tục hoạt động (như Mufaka đã nói). Đây là một quá trình được thử nghiệm sẽ làm việc với cả hai tệp nội dung và bất kỳ phần nào được biên dịch của ứng dụng (mà triển khai gây ra một quá trình tái chế của quá trình asp.net).

Về tỷ lệ cập nhật đây là điều bạn có thể kiểm soát. Có các bản cập nhật đi qua hàng đợi và có một quy trình triển khai duy nhất kiểm soát thời điểm triển khai từng mục. Lưu ý điều này không có nghĩa là bạn xử lý từng bản cập nhật riêng biệt, vì bạn có thể lấy các bản cập nhật hiện tại trong hàng đợi và triển khai chúng cùng nhau. Các cập nhật khác sẽ đến hàng đợi và sẽ được chọn sau khi tập hợp cập nhật hiện tại kết thúc.

Cập nhật: Giới thiệu câu hỏi trong nhận xét. Đây là giải pháp tùy chỉnh dựa trên kinh nghiệm của tôi với các quy trình nặng/dài cần tốc độ cập nhật được kiểm soát. Tôi không có nhu cầu sử dụng cách tiếp cận này cho các kịch bản triển khai, như đối với nội dung động như vậy, tôi thường đi với một sự kết hợp của DB và bộ nhớ cache ở các cấp độ khác nhau.

Hàng đợi không cần giữ thông tin đầy đủ, nó chỉ cần có thông tin thích hợp (id/đường dẫn) sẽ cho phép quá trình của bạn vượt qua thông tin để bắt đầu quá trình xuất bản bằng công cụ bên ngoài. Vì đó là mã tùy chỉnh, bạn có thể có nó tham gia thông tin được xuất bản, do đó bạn không phải giải quyết vấn đề đó trong quá trình/công cụ xuất bản.

Việc thay đổi DB sẽ được thực hiện trong quá trình xuất bản, một lần nữa bạn chỉ cần biết thông tin cho các thay đổi bắt buộc là gì và để cho quy trình/công cụ xuất bản xử lý nó. Về những gì để sử dụng cho hàng đợi, những cái chính tôi đã sử dụng là msmq và một triển khai tùy chỉnh với thông tin trong máy chủ sql. Hàng đợi chỉ ở đó để kiểm soát tốc độ của các bản cập nhật, vì vậy bạn không cần bất cứ điều gì đặc biệt nhắm mục tiêu vào việc triển khai.

Cập nhật 2: đảm bảo thay đổi DB của bạn tương thích ngược. Điều này thực sự quan trọng, khi bạn đang đẩy các thay đổi trực tiếp đến các máy chủ khác nhau.

Answer 6

Chúng tôi có tình huống tương tự với bạn và giải pháp của chúng tôi là sử dụng mô hình nhà xuất bản/người đăng ký. Ứng dụng CMS của chúng tôi lưu trữ các tệp thực trong cơ sở dữ liệu và thông báo cho dịch vụ xuất bản khi một tệp đã được tạo hoặc cập nhật. Nhà xuất bản này sau đó thông báo cho tất cả các ứng dụng web đăng ký và sau đó họ đi và lấy tệp từ cơ sở dữ liệu và đặt nó trên hệ thống tệp của họ.

Chúng tôi có người đăng ký được đặt trong tệp cấu hình trên nhà xuất bản nhưng bạn có thể đi toàn bộ con heo và ứng dụng web tự đăng ký để khởi động ứng dụng để quản lý dễ dàng hơn.

Bạn có thể sử dụng UNC để lưu trữ, chúng tôi đã chọn một DB để thuận tiện và di chuyển giữa môi trường sản xuất và thử nghiệm (chúng tôi chỉ sao chép lại DB và chúng tôi có tất cả các tệp trang web trực tiếp cũng như dữ liệu).

Answer 7

Một phương pháp rất đơn giản để triển khai cho nhiều máy chủ (một khi các nút được thiết lập chính xác) là sử dụng robocopy.

Tốt hơn là bạn nên có một máy chủ dàn dựng nhỏ để thử nghiệm và sau đó bạn 'robocopy' cho tất cả các máy chủ triển khai (thay vì sử dụng chia sẻ mạng).

robocopy được bao gồm trong các MS ResourceKit - sử dụng nó với chuyển đổi/MIR.

Answer 8

Để cung cấp cho bạn một số thực phẩm cho suy nghĩ bạn có thể xem một cái gì đó như Microsoft's Live Mesh . Tôi không nói đó là câu trả lời cho bạn nhưng mô hình lưu trữ mà nó sử dụng có thể là.

Với Mesh bạn tải xuống một Dịch vụ Windows nhỏ trên mỗi máy Windows mà bạn muốn trong Lưới và sau đó chỉ định các thư mục trên hệ thống của bạn là một phần của lưới. Khi bạn sao chép một tệp vào thư mục Live Mesh - đó là thao tác chính xác giống như sao chép vào bất kỳ người nào khác trên hệ thống của bạn - dịch vụ sẽ xử lý đồng bộ tệp đó với tất cả các thiết bị tham gia khác của bạn.

Ví dụ tôi giữ tất cả các tệp nguồn mã trong thư mục Lưới và đồng bộ hóa chúng giữa công việc và nhà riêng. Tôi không phải làm bất cứ điều gì cả để giữ cho họ đồng bộ hành động của việc lưu một tập tin trong VS.Net, notepad hoặc bất kỳ ứng dụng khác khởi tạo bản cập nhật.

Nếu bạn có một trang web thường xuyên thay đổi các tệp cần truy cập vào nhiều máy chủ, và có thể là tác giả mutliple cho những thay đổi đó, bạn có thể đặt dịch vụ Mesh trên mỗi máy chủ web và khi tác giả thêm, thay đổi hoặc xóa tệp các bản cập nhật sẽ được đẩy tự động. Theo như các tác giả đi họ sẽ chỉ được lưu các tập tin của họ vào một thư mục cũ bình thường trên máy tính của họ.

Answer 9

Với IIS6 và 7, kịch bản sử dụng chia sẻ một mạng trên N máy chủ web/ứng dụng được đính kèm được hỗ trợ rõ ràng. MS đã làm một tấn thử nghiệm perf để đảm bảo rằng kịch bản này hoạt động tốt. Có, bộ nhớ đệm được sử dụng. Với một máy chủ dual-NIC, một cho internet công cộng và một cho mạng riêng, bạn sẽ nhận được hiệu suất thực sự tốt. Việc triển khai là chống đạn.

Bạn nên dành thời gian để đánh giá nó.

Bạn cũng có thể đánh giá nhà cung cấp đường dẫn ảo ASP.NET, cho phép bạn triển khai một tệp ZIP duy nhất cho toàn bộ ứng dụng. Hoặc, với một CMS, bạn có thể phục vụ nội dung ngay từ một cơ sở dữ liệu nội dung, chứ không phải là một hệ thống tập tin. Điều này trình bày một số lựa chọn thực sự tốt đẹp cho phiên bản.

VPP For ZIP via #ZipLib.

VPP for ZIP via DotNetZip.

Answer 10

Giả sử máy chủ IIS của bạn đang chạy Windows Server 2003 R2 hoặc tốt hơn, chắc chắn xem xét DFS Replication. Mỗi máy chủ có bản sao riêng của các tập tin mà loại bỏ một nút cổ chai mạng chia sẻ như nhiều người khác đã cảnh báo chống lại. Triển khai cũng đơn giản như việc sao chép các thay đổi của bạn tới bất kỳ một trong các máy chủ nào trong nhóm nhân bản (giả sử một cấu trúc liên kết lưới đầy đủ). Việc sao chép sẽ tự động xử lý phần còn lại bao gồm việc sử dụng nén vi sai từ xa để chỉ gửi các vùng của các tệp đã thay đổi.

Answer 11

Tôi chịu trách nhiệm phát triển trang web trò chơi có 60 triệu lượt truy cập mỗi tháng. Cách chúng tôi đã làm nó là lựa chọn # 1. Người dùng đã có khả năng tải lên hình ảnh và như vậy và những người đã được đưa vào một NAS được chia sẻ giữa các máy chủ. Nó làm rất được việc. Tôi giả định rằng bạn cũng đang làm bộ nhớ đệm trang và vân vân, ở phía ứng dụng của ngôi nhà. Tôi cũng sẽ triển khai theo yêu cầu, các trang mới cho tất cả các máy chủ cùng một lúc.

Answer 12

Trong trường hợp có tính sẵn sàng cao lý tưởng, không nên có điểm lỗi duy nhất.

Điều đó có nghĩa là một hộp duy nhất có trang web trên đó là không. Sau khi hoàn thành công việc HA cho một Telco lớn, ban đầu tôi sẽ đề xuất những điều sau đây:

• Mỗi máy chủ đều có bản sao dữ liệu riêng.
• Vào thời điểm yên tĩnh, hãy mang hai máy chủ off-line (tức là, sửa đổi bộ cân bằng HA để loại bỏ chúng).
• Cập nhật hai máy chủ ngoại tuyến.
• Sửa đổi bộ cân bằng HA để bắt đầu sử dụng hai máy chủ mới chứ không phải hai máy chủ cũ.
• Kiểm tra để đảm bảo tính chính xác.
• Cập nhật hai máy chủ khác rồi đưa chúng lên mạng.

Đó là cách bạn có thể thực hiện mà không cần thêm phần cứng. Trong thế giới hậu xử lý của Telco tôi đã làm việc cho, đây là những gì chúng tôi đã làm:

• Chúng tôi đã có tám máy chủ (vào thời điểm đó, chúng tôi có nhiều tiền hơn bạn có thể chọc một cây gậy). Khi đến lúc chuyển tiếp, bốn máy chủ ngoại tuyến sẽ được thiết lập với dữ liệu mới.
• Sau đó, bộ cân bằng HA sẽ được sửa đổi để sử dụng bốn máy chủ mới và ngừng sử dụng các máy chủ cũ. Điều này thực hiện chuyển đổi (và, quan trọng hơn, switchback nếu chúng ta nhồi lên) một quá trình rất nhanh và không đau.
• Chỉ khi các máy chủ mới đã chạy trong một thời gian, chúng tôi sẽ xem xét việc chuyển đổi tiếp theo. Cho đến thời điểm đó, bốn máy chủ cũ đã được lưu giữ ngoại tuyến nhưng sẵn sàng, chỉ trong trường hợp.
• Để có được hiệu ứng tương tự với ít chi phí tài chính hơn, bạn có thể có thêm đĩa thay vì toàn bộ máy chủ phụ. Phục hồi sẽ không được khá nhanh chóng kể từ khi bạn có quyền lực xuống một máy chủ để đưa đĩa cũ trở lại, nhưng nó vẫn sẽ nhanh hơn một hoạt động khôi phục.

Answer 13

Chúng tôi rất vui khi sử dụng 4 máy chủ web với mỗi bản sao cục bộ của các trang và Máy chủ SQL có cụm không thành công.