7

Giả sử tôi có dịch vụ cửa sổ độc lập đang chạy trong máy chủ cửa sổ. Làm thế nào để đảm bảo nó có sẵn cao?Dịch vụ Windows - Kịch bản sẵn có cao và cách tiếp cận thiết kế

1). Tất cả các nguyên tắc cấp thiết kế mà bạn có thể đề xuất là gì?

2). Cách làm cho nó có sẵn cao như chính/phụ, ví dụ: các giải pháp phân cụm hiện có sẵn trên thị trường

3). Làm thế nào để đối phó với mối quan tâm xuyên suốt trong mọi trường hợp fail-over kịch bản

Nếu bất kỳ khác mà bạn có thể nghĩ đến xin vui lòng thêm nó ở đây ..

Lưu ý: Câu hỏi đặt ra là chỉ liên quan đến cửa sổ và cửa sổ dịch vụ, hãy cố gắng tuân theo quy tắc này :)

+1

Bạn có thể chia sẻ thêm một chút thông tin về những gì dịch vụ của bạn đang làm không? Các chiến lược HA có thể khác nhau tùy thuộc vào những gì bạn đang cố gắng làm. –

+0

Justin, tôi quan tâm đến các dịch vụ cửa sổ rất tầm thường như người nghe ổ cắm hoặc bỏ phiếu/ghi dữ liệu vào một số datbases/tập tin phẳng, vv, – asyncwait

Trả lời

5

Để giữ cho dịch vụ ít nhất chạy bạn có thể sắp xếp cho Manager của Windows Service để tự động khởi động lại dịch vụ nếu nó bị treo (xem tab phục hồi trên các thuộc tính dịch vụ.) Thông tin chi tiết có sẵn ở đây, trong đó có một kịch bản hàng loạt để thiết lập những đặc tính này - Restart a windows service if it crashes

Tính khả dụng cao hơn nhiều so với việc duy trì dịch vụ từ bên ngoài - bản thân dịch vụ cần được xây dựng với tính sẵn sàng cao (tức là sử dụng thực hành lập trình tốt trong suốt, cơ sở dữ liệu thích hợp, tài nguyên cặp đôi và phát hành), và toàn bộ stress-thử nghiệm để đảm bảo rằng nó sẽ ở lại theo tải dự kiến.

Đối với các lệnh không tải trọng, dung sai các lỗi không liên tục (như tài nguyên bị khóa) có thể đạt được bằng cách gọi lại lệnh một số lần nhất định. Điều này cho phép dịch vụ bảo vệ máy khách khỏi lỗi (đến một điểm.) Máy khách cũng phải được mã hóa để dự đoán lỗi. Máy khách có thể xử lý lỗi dịch vụ theo nhiều cách - ghi nhật ký, nhắc người dùng, thử lại X lần, ghi lại lỗi nghiêm trọng và thoát là tất cả các trình xử lý có thể có - điều nào phù hợp với bạn tùy thuộc vào yêu cầu của bạn. Nếu dịch vụ có "trạng thái trò chuyện", khi dịch vụ không thành công (nghĩa là quá trình được khởi động lại), khách hàng phải biết và xử lý tình huống này, vì điều đó thường có nghĩa là trạng thái cuộc trò chuyện hiện tại đã bị mất.

Một máy đơn sẽ dễ bị lỗi phần cứng, vì vậy nếu bạn định sử dụng một máy đơn lẻ, hãy đảm bảo nó có các thành phần dự phòng. Ổ cứng đặc biệt dễ bị hỏng, vì vậy có ít nhất ổ đĩa được nhân đôi hoặc một mảng RAID. PSU là điểm yếu tiếp theo, do đó PSU dư thừa cũng đáng giá như UPS.

Để phân cụm, Windows hỗ trợ phân cụm dịch vụ và quản lý dịch vụ bằng Tên mạng, thay vì tên máy tính riêng lẻ. Điều này cho phép khách hàng của bạn kết nối với bất kỳ máy nào đang chạy dịch vụ và không phải là một tên mã hóa cứng. Nhưng trừ khi bạn thực hiện các biện pháp bổ sung, đây là chuyển đổi tài nguyên - chuyển yêu cầu từ một trường hợp dịch vụ sang một dịch vụ khác. Trạng thái Converstaion thường bị mất. Nếu các dịch vụ của bạn đang ghi vào cơ sở dữ liệu, thì nó cũng phải được nhóm lại để đảm bảo độ tin cậy và đảm bảo các thay đổi có sẵn cho toàn bộ cụm, và không chỉ là nút cục bộ.

Đây thực sự chỉ là đỉnh của tảng băng trôi, nhưng tôi hy vọng nó sẽ cho bạn những ý tưởng để bắt đầu nghiên cứu sâu hơn.

Microsoft Clustering Service (MSCS)

0

Nếu bạn chia nhỏ các vấn đề bạn đang cố gắng giải quyết, tôi nghĩ bạn có thể sẽ tự mình đưa ra một vài câu trả lời. Như Justin đã đề cập trong bình luận, không có ai trả lời. Nó hoàn toàn phụ thuộc vào dịch vụ của bạn và cách khách hàng sử dụng nó. Bạn cũng không chỉ định bất kỳ chi tiết nào về tương tác giữa máy khách và máy chủ. HTTP? TCP? UDP? Khác?

Dưới đây là một số điều cần suy nghĩ để giúp bạn bắt đầu.

1) Bạn sẽ làm gì nếu dịch vụ hoặc máy chủ bị trục trặc?

  • Làm thế nào để chạy nhiều trường hợp dịch vụ của bạn trên các máy chủ riêng biệt?

2) Ok, nhưng bây giờ làm cách nào để khách hàng biết về nhiều dịch vụ?

  • Bạn khó có thể mã hóa danh sách vào từng khách hàng (không khuyến khích)
  • Bạn có thể sử dụng DNS round-robin để trả lại yêu cầu trên tất cả trong số họ.
  • Bạn có thể sử dụng thiết bị cân bằng tải.
  • Bạn có thể có một dịch vụ riêng biệt biết về tất cả các dịch vụ khác và có thể hướng khách hàng đến các dịch vụ có sẵn.

3) Vì vậy, nếu một dịch vụ đi xuống thì sao?

  • Ứng dụng khách có biết phải làm gì nếu dịch vụ mà họ kết nối không hoạt động? Nếu không, thì họ cần được cập nhật để xử lý tình huống đó.

Điều đó sẽ giúp bạn bắt đầu với ý tưởng cơ bản về cách bắt đầu với tính khả dụng cao. Nếu bạn cung cấp chi tiết cụ thể về kiến ​​trúc của mình, có thể bạn sẽ nhận được phản hồi tốt hơn nhiều.

0

Nếu dịch vụ không tiếp xúc với bất kỳ giao diện để kết nối khách hàng mà bạn có thể:

  • Broadcast hoặc phơi bày một “Tôi còn sống” tin nhắn hoặc báo hiệu một cơ sở dữ liệu/đăng ký/tcp/bất cứ điều gì mà bạn đang sống

  • có một dịch vụ thứ hai (monitor) để kiểm tra cho các “tôi còn sống” tín hiệu và cố gắng khởi động lại dịch vụ trong trường hợp nó là xuống

Nhưng nếu bạn có một máy khách kết nối với dịch vụ này thông qua namedpipes/tcp/etc, máy khách sẽ phải kiểm tra địa chỉ của máy với dịch vụ đang chạy trong cơ sở dữ liệu, hoặc có cái gì đó giống như một switch thông minh để chuyển hướng lưu lượng.