Giả sử bạn cần đảm bảo ứng dụng của mình dựa trên SQL Server 2012 vì phần phụ trợ cơ sở dữ liệu của nó có sẵn suốt cả ngày, ngay cả khi một máy chủ bị lỗi.

Là một nhà phát triển và không phải là một DBA, tôi đang đấu tranh để hiểu khi nào nên sử dụng kịch bản nào cho chuyển đổi dự phòng / tính sẵn sàng cao của mình:

• Hai (hoặc nhiều) máy chủ trong cụm Windows Failover, SQL Server là một phiên bản cụm
• Hai (hoặc nhiều) SQL Server được cập nhật với bản sao giao dịch
• Hai (hoặc nhiều) Máy chủ SQL trong Nhóm sẵn có của Máy chủ SQL, được định cấu hình ở chế độ cam kết đồng bộ

Cái nào trong số các kịch bản đó hoạt động cho loại khối lượng công việc và loại thất bại / mất điện nào có thể được xử lý bởi các kịch bản đó? Họ thậm chí có thể so sánh / trao đổi?

Cách tôi luôn muốn hình dung các giải pháp khả dụng cao là như sau:

Sơ đồ cụm chuyển đổi dự phòng máy chủ SQL (FCI)

Những gì có sẵn cao? Toàn bộ ví dụ. Điều đó bao gồm tất cả các đối tượng máy chủ (đăng nhập, công việc Đại lý máy chủ SQL, v.v.). Điều này cũng bao gồm cơ sở dữ liệu và các thực thể chứa chúng. Đó là một giải pháp tuyệt vời cho các phiên bản SQL Server khả dụng cao, bởi vì đó sẽ là mức độ ngăn chặn với giải pháp đã cho này.

Báo cáo thì sao? Không, NULL, không tồn tại. Một cá thể cụm chuyển đổi dự phòng có một nút hoạt động cung cấp nhóm cụm chứa cá thể, VNN, v.v. và tất cả các nút khác đều thụ động, không hoạt động (theo như liên quan đến nhóm cụm hiện tại) và chờ chuyển đổi dự phòng.

Điều gì xảy ra khi có failover? Thời gian chết cho một FCI sẽ được xác định bởi lượng thời gian mà nút thụ động mất để lấy tài nguyên cụm và đưa phiên bản SQL Server ở trạng thái chạy. Điều này thường là tối thiểu trong thời gian.

Bất kỳ khách hàng trừu tượng? Có, điều này sẽ được tích hợp sẵn với tên mạng ảo cho trường hợp cụm chuyển đổi dự phòng. Điều này sẽ luôn trỏ đến nút hoạt động hiện đang phân phối tài nguyên cụm SQL Server.

Các nhóm luôn sẵn sàng

Những gì có sẵn cao? Một nhóm khả dụng sẽ là sự ngăn chặn logic của tính sẵn sàng cao ở đây, trong khi một nhóm khả dụng bao gồm một số cơ sở dữ liệu và tên mạng ảo (người nghe, tài nguyên cụm tùy chọn). Điều đáng chú ý là các đối tượng máy chủ như đăng nhập và các công việc của SQL Server Agent sẽ không phải là một phần của giải pháp HA và cần phải xem xét đặc biệt để đảm bảo rằng chúng được thực hiện đúng với một nhóm khả dụng. Không phải là một yêu cầu quá nặng nề, nhưng cần phải được chăm sóc.

Báo cáo thì sao? Đây là một giải pháp tuyệt vời để báo cáo, mặc dù tôi có thể sẽ không sử dụng bản sao đồng bộ làm ví dụ báo cáo của mình. Có hai mối quan hệ cam kết, đồng bộ và không đồng bộ. Theo ý kiến ​​của tôi và từ những gì tôi đã thấy trong thực tế, đó là bản sao thứ cấp đồng bộ của bạn đang chờ đợi một thảm họa. Hãy nghĩ về nó vì bản sao đó đã sẵn sàng để chuyển đổi dự phòng không mất dữ liệu trong trường hợp xảy ra sự cố. Sau đó, có các bản sao không đồng bộ có thể xử lý khối lượng công việc báo cáo đó. Bạn không sử dụng bản sao này làm giải pháp đã nói ở trên, nhưng chỉ là những thứ như báo cáo. Khối lượng công việc báo cáo có thể được trỏ đến bản sao này (trực tiếp hoặc gián tiếp thông qua định tuyến chỉ đọc qua người nghe).

Điều gì xảy ra khi có failover? Đối với bản sao thứ cấp cam kết đồng bộ được ghép nối với chuyển đổi dự phòng tự động, đây sẽ là thay đổi trạng thái vai trò bản sao từ SECONDARY_NORMAL thành PRIMARY_NORMAL. Để có chuyển đổi dự phòng tự động, bạn cần có một bản sao thứ cấp đồng bộ hiện đang được đồng bộ hóa và những gì được triển khai là Chính sách chuyển đổi linh hoạt để xác định khi nào thực tế việc chuyển đổi dự phòng này sẽ xảy ra. Chính sách đó thực sự là cấu hình.

Bất kỳ khách hàng trừu tượng? Có, bạn có thể tùy ý định cấu hình trình nghe Nhóm Luôn sẵn sàng. Về cơ bản, đây chỉ là một tên mạng ảo (có thể được xem qua WSFC như một tài nguyên cụm trong nhóm cụm của AG) trỏ đến bản sao chính hiện tại. Đây là một phần quan trọng trong việc thay đổi khối lượng công việc báo cáo của bạn, cũng như thiết lập danh sách định tuyến chỉ đọc trên bất kỳ máy chủ nào bạn muốn chuyển hướng lưu lượng ReadOnly (điều này được đặt qua chuỗi kết nối, với Nhà cung cấp .NET Framework cho SQL Máy chủ, đây sẽ là tham số Ý định ứng dụng , được đặt thành ReadOnly ). Bạn cũng sẽ cần đặt URL định tuyến chỉ đọc cho mỗi bản sao mà bạn muốn nhận khối lượng công việc báo cáo này trong khi ở vai trò bản sao phụ.

Nhân rộng giao dịch

Những gì có sẵn cao? Điều này là có thể tranh cãi, nhưng tôi sẽ không nói gì . Tôi không thấy sao chép là một giải pháp khả dụng cao. Có, sửa đổi dữ liệu đang được đẩy đến người đăng ký nhưng chúng tôi đang nói ở cấp độ xuất bản / bài viết. Đây sẽ là một tập hợp con của dữ liệu (có thể bao gồm tất cả dữ liệu, nhưng sẽ không được thực thi. Tức là bạn tạo một bảng mới trong cơ sở dữ liệu của nhà xuất bản và điều đó sẽ không tự động được đẩy tới người đăng ký). Theo như HA nói, đây là phần cuối cùng và tôi sẽ không nhóm nó trong đó với một giải pháp HA rắn chắc.

Báo cáo thì sao? Một giải pháp tuyệt vời để báo cáo về một tập hợp con dữ liệu, không có câu hỏi về điều đó. Nếu bạn có cơ sở dữ liệu 1 TB có tính giao dịch cao và bạn muốn giữ khối lượng công việc báo cáo đó khỏi cơ sở dữ liệu OLTP, sao chép giao dịch là một cách tuyệt vời để đẩy một tập hợp con dữ liệu đến một thuê bao (hoặc người đăng ký) cho khối lượng công việc báo cáo. Điều gì xảy ra nếu trong số 1 TB dữ liệu đó, khối lượng công việc báo cáo của bạn chỉ khoảng 50 GB? Đây là một giải pháp thông minh và tương đối có thể cấu hình để đáp ứng nhu cầu kinh doanh của bạn.

Tóm lược

Những gì nó sôi nổi là một số câu hỏi cần được trả lời (một phần bởi doanh nghiệp):

1. Những gì cần phải có sẵn cao ?
2. Các làm những gì SLA dictate cho HA / DR?
3. Loại báo cáo nào sẽ diễn ra và độ trễ nào được chấp nhận?
4. Chúng ta cần làm gì với HA phân tán theo địa lý ? (sao chép lưu trữ là tốn kém, nhưng phải có FCI. AG không yêu cầu lưu trữ được chia sẻ từ các trường hợp độc lập và bạn có thể sử dụng một nhân chứng chia sẻ tệp cho đại biểu có khả năng loại bỏ nhu cầu lưu trữ được chia sẻ)

hai (hoặc nhiều) máy chủ trong cụm Windows Failover, SQL Server là một thể hiện của cụm

1. Loại khối lượng công việc? "Nó phụ thuộc" - nhưng nghiêm túc, điều này hữu ích cho một ứng dụng trực tuyến nơi bạn cần có địa phương trong trung tâm dữ liệu Tính sẵn sàng cao. Bạn được bảo vệ trước sự cố của một máy hoặc một hệ điều hành. Tất cả thông tin đăng nhập, công việc, cơ sở dữ liệu mới, bảo trì, v.v. Chuyển đổi dự phòng rất nhanh, nhưng vẫn có một trục trặc trông giống như SQL Server khởi động lại khi chuyển đổi dự phòng xảy ra.

2. Nhược điểm / Mối quan tâm - Điểm thất bại duy nhất là bộ nhớ của bạn và tất cả các thành phần của nó. Các nhà cung cấp SAN luôn nói "SAN không thất bại" nhưng có rất nhiều bộ phận chuyển động trong mạng lưu trữ và khi tôi viết blog về đây , họ có thể. Ngoài ra - bạn đang trả tiền cho một máy chủ thứ cấp không thể làm gì ngoài việc chờ đợi và chờ đợi .. Bây giờ bạn có thể thực hiện Active / Active / Multi-Node và có hai trường hợp hoạt động có thể chuyển đổi theo hướng và sử dụng nút thứ hai.

3. Tự động chuyển đổi dự phòng? Tự động "nhất". Không cần nhân chứng, đó là một cụm. Đây là công việc của một cụm, để làm cho nó liền mạch nhất có thể. Bây giờ với bất kỳ điều nào trong số này, khi chuyển đổi dự phòng xảy ra, bạn sẽ "cảm thấy" nó, bởi vì SQL phải khởi động hoặc các kết nối phải trỏ tới. Ở đây khi điều đó xảy ra, về cơ bản bạn sẽ cảm thấy như khởi động lại SQL, DB quay trở lại và chạy recovery / etc.

Nếu tôi có một khách hàng nói rằng "Tôi muốn có đầy đủ tất cả các cơ sở dữ liệu, tất cả thông tin đăng nhập, v.v." trong môi trường có tính sẵn sàng cao trong trung tâm dữ liệu địa phương của tôi vì tôi có khả năng chịu đựng cực kỳ thấp cho thời gian chết, tôi sẽ xem xét các trường hợp dự phòng (mặc dù tùy chọn cuối cùng mà bạn đề cập là một ứng cử viên mạnh mẽ, tiết kiệm cho việc phải thực hiện một số chi phí quản lý). Tôi có thể sẽ làm một FCI cục bộ và một thứ cấp không đồng bộ AG để bảo vệ chống lại sự cố trang web hoặc lỗi SAN.

hai (hoặc nhiều) phiên bản SQL Server được cập nhật với bản sao giao dịch

1. Loại khối lượng công việc? Tôi thực sự sẽ không đến đây vì rất nhiều trường hợp cần sự sẵn sàng cao hoặc Phục hồi thảm họa là lựa chọn đầu tiên. Chắc chắn không có trong SQL 2012. Nhưng về cơ bản, điều này tốt nếu bạn phải đến một trung tâm dữ liệu không gần, bạn không thể sử dụng AG (có thể là sự cố tên miền ngăn bạn sử dụng cụm cửa sổ cần thiết cho AG), có lẽ bạn muốn trong tiêu chuẩn SQL Server có thể sao chép, nhưng không phải AG nhưng bạn vẫn muốn có khả năng đọc ở phía thứ cấp và không đồng bộ.
2. Nhược điểm / Mối quan tâm - Đó là sự nhân rộng. Nó có chi phí hoạt động, nó có thể không đồng bộ, bạn có thể phát triển các vấn đề với hiệu suất ở phía nguồn, v.v.
3. Tự động chuyển đổi dự phòng - Không. Bạn phải tự quản lý nó. Thông qua các CNAME chỉ ra cái này hay cái kia, và về mặt lý thuyết bạn có thể viết quy trình của riêng bạn để làm điều này, nhưng ngoài hộp không? Lưu ý ở đây.

hai (hoặc nhiều) Máy chủ SQL trong Nhóm sẵn có của SQL Server, được định cấu hình ở chế độ cam kết đồng bộ

Đây là những gì tôi đã giúp mọi người thực hiện ngày càng nhiều hơn, mặc dù đôi khi tôi vẫn đi phân cụm.

1. Loại khối lượng công việc? Đây là tuyệt vời khi tôi có một bộ quản lý cơ sở dữ liệu để giữ cho đồng bộ, và các nguồn lực và thời gian để đảm bảo rằng việc làm, thông tin đăng nhập, cơ sở dữ liệu mới, vv nghỉ đồng bộ (mặc dù nhóm nghiên cứu tại Kỹ năng SQL đã xây dựng một add to lớn trong để tự động hóa một số điều này cho bạn làm cho nó thậm chí còn mạnh mẽ hơn của một tùy chọn). Tôi thích điều này khi tôi muốn giữ mọi thứ hoàn toàn riêng biệt. Tôi đang bảo vệ chống lại các sự cố phần cứng, sự cố hệ điều hành, sự cố cài đặt SQL, sự cố vá lỗi và sự cố SAN / Storage. Tôi cũng nhận được lợi ích của khả năng có một thứ cấp (Nếu tôi muốn trả một giấy phép doanh nghiệp cho nó) để trở thành một thứ cấp hoạt động mà tôi có thể đọc từ đó, hãy sao lưu, v.v. Ngoài ra, trong tương lai tôi có thể thêm một phần ba thứ cấp không đồng bộ tại một trang web từ xa và có failover / DR.
2. Nhược điểm / Quan tâm Cấp phép, số lượng bản sao tối đa, chi phí cấp phép để tận dụng một số lợi ích lớn nhất (hoạt động thứ cấp), yêu cầu doanh nghiệp, yêu cầu lưu trữ gấp đôi so với phân cụm.
3. Chuyển đổi dự phòng tự động - Có. Điều này có thể xảy ra với thiết lập nhân chứng và nhà phát triển ứng dụng của bạn có thể kết nối với người nghe thay vì nút để chuyển đổi dự phòng xảy ra với nơi người nghe chỉ điểm và bạn sẽ ở đó tốt. Vì vậy, có bạn có thể làm điều đó ở đây - và nên - nhưng tất nhiên bạn nên kiểm tra nó tốt.

Tóm lược

HA và DR là khác nhau. Và những công nghệ này giúp cung cấp các phần của một trong hai. Tính sẵn sàng cao có nghĩa là (với tôi) rằng bạn có thể nhanh chóng khôi phục nếu có sự cố không hay xảy ra với một máy, bạn sẽ có Mục tiêu thời gian phục hồi ngắn và Mục tiêu thời gian phục hồi. Đó là phân cụm và một AG đồng bộ.

Phục hồi thảm họa là "bạn có thể thức dậy khi gặp sự cố ngay cả trong giải pháp HA. Đối với tôi đó có thể là AG khi bạn đến một trung tâm dữ liệu khác, phản chiếu hoặc thậm chí sao chép.

Nó cũng quan trọng để xem xét những gì được chia sẻ .

Failover Clustering sử dụng hai hoặc nhiều nút máy chủ chia sẻ một mảng đĩa. Nếu mảng đĩa bị hỏng thì bạn mất dịch vụ, bất kể có bao nhiêu nút máy chủ. Nếu phòng máy chủ nơi đặt đĩa đó bắt lửa hoặc lũ lụt thì bạn sẽ mất dịch vụ.

Các nhóm sẵn sàng và phản ánh cơ sở dữ liệu luôn là một công nghệ phân cụm "không chia sẻ gì". Cơ sở dữ liệu có mặt trên nhiều mảng đĩa trong nhiều máy chủ. Nếu bạn có các liên kết mạng tốt thì nhiều phục vụ có thể ở trong nhiều phòng máy chủ, bảo vệ bạn khỏi hỏa hoạn và lũ lụt.

Chỉ cần cho đầy đủ, có tùy chọn sử dụng phản chiếu cũ đơn giản. Các ưu điểm ở đây bao gồm có hai bản sao của cơ sở dữ liệu mà không phức tạp khi sử dụng Nhóm sẵn có và không cần lưu trữ chia sẻ cho Phân cụm chuyển đổi dự phòng. Nhược điểm, mặc dù nhẹ, là phản chiếu bị phản đối.

Thời gian chuyển đổi dự phòng với phản chiếu là theo thứ tự 10 giây, mặc dù mã ứng dụng cần có thể thử lại bất kỳ giao dịch nào đang xảy ra tại thời điểm chuyển đổi dự phòng.