Kiểm tra cụm mới - Thực hành tốt nhất


7

Chúng tôi đã hoàn tất thiết lập cụm SQL Server 2005 4 nút. Chúng tôi đang sử dụng Windows 2008 R2 làm hệ điều hành cơ bản.

Chúng tôi đang tìm kiếm đề xuất về một tập hợp các bài kiểm tra mà chúng tôi có thể thực hiện để kiểm tra chuyển đổi dự phòng của các Thực thể SQL?


2
Đây có vẻ là một tài nguyên khá tốt: blog.technet.com/b/vipulshah/archive/2009/06/17/ Kẻ
Thomas Stringer

Câu trả lời:


5

Thậm chí không gần với toàn diện, nhưng tôi sẽ bắt đầu bằng: 1. Kéo (các) cáp ethernet cho giao diện ip công cộng trên nút chính / hoạt động của bạn. Xác nhận chuyển đổi dự phòng. 2. Kéo (các) cáp quang SAN cho nút hoạt động của bạn. Xác nhận chuyển đổi dự phòng. 3. Kéo (các) cáp nguồn cho nút hoạt động của bạn. Xác nhận chuyển đổi dự phòng.

Những loại này đại diện cho các loại thất bại chính mà MS Clustering sẽ bù đắp ngay từ đầu ...

Tôi nghĩ rằng tôi đã tách db thực sự / prod của mình hoặc ngoại tuyến trong khi tôi chơi các trò chơi này. *


5

Liên kết mà Thomas cung cấp trong nhận xét của mình về câu hỏi là một nguồn tốt của một số tình huống để kiểm tra. Bob cũng cung cấp một số bài kiểm tra tốt, nhiều bài trong số đó được bao gồm trong bài đăng trên blog được liên kết.

Tôi muốn nói ngoài những danh sách tuyệt vời về "cái gì" cần kiểm tra, bạn cũng muốn xem xét các kịch bản ứng dụng khác nhau để kiểm tra chuyển đổi dự phòng trong thời gian. Tôi đã thấy rất nhiều cụm được xây dựng và sau đó được kiểm tra từ phía nhóm máy chủ / nhóm DBA - nhưng các nhóm ứng dụng không bao giờ tham gia.

Điều gì xảy ra với các ứng dụng của bạn trong quá trình chuyển đổi dự phòng đó? Bây giờ, nó thực sự trông giống như khởi động lại ứng dụng (thực tế đó là sự chuyển đổi dự phòng .. Dịch vụ đi xuống trên Nút A .. Dịch vụ đi lên trên Nút B .. SQL thực hiện những gì nó làm khi SQL bị tắt và khởi động lại hoặc khi nó gặp sự cố và quay trở lại .. DB trải qua quá trình khôi phục ở phía bên kia của khởi động lại, tất cả các kết nối bị mất ở nơi chúng đang ở, v.v.) Vì vậy, có vẻ như vô nghĩa để kiểm tra, nhưng thật tốt để xem loại quy trình nào người dùng sẽ trải nghiệm và để hiểu những gì các chủ sở hữu ứng dụng và người trợ giúp, v.v. cần phải làm gì khi việc chuyển đổi dự phòng đó xảy ra.

Bạn nên đặt câu hỏi như:

  1. Có một số thành phần cần phải được thiết lập lại hoặc khởi động lại sau khi khởi động lại cơ sở dữ liệu?
  2. Bạn có phải tuân theo một thứ tự hoạt động rất cụ thể để tắt / khởi động lại SQL Server trong các cửa sổ bảo trì không? Điều đó có thể trông giống như các ứng dụng hoặc máy chủ phần mềm trung gian đi xuống trước, sau đó là cơ sở dữ liệu. Trong một chuyển đổi dự phòng cụm, bạn nhận được DB đi xuống trước. Điều này có ý nghĩa gì với bạn và công ty của bạn?
  3. Các nhà cung cấp gói phần mềm bên thứ ba của bạn có hỗ trợ cài đặt trên một cụm không? Họ nên, nó không khác nhau nhiều nhưng họ có thể có hướng dẫn về những điều cần xem xét trong quá trình chuyển đổi dự phòng.
  4. Các ứng dụng của bạn có tự động thử kết nối lại một số lần nhất định không? Nếu không, họ có thể? Đây có thể là một điều tốt để xem xét trong môi trường cụm của bạn để tiết kiệm thời gian trong việc kết nối lại và quay trở lại công việc chuyển đổi dự phòng.

Và khi bạn thực hiện một số thử nghiệm này, hãy để ứng dụng của bạn chạy (không phải sản xuất trực tiếp ...) với người dùng hoặc tập lệnh thử nghiệm thực hiện công việc trong quá trình chuyển đổi dự phòng. Chuyện gì đã xảy ra? Xem bất cứ điều gì cần được chăm sóc?

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.