Định cấu hình mạng chuyên dụng cho giao tiếp nhóm khả dụng

Nhóm luôn sẵn sàng của SQL Server 2012 yêu cầu điểm cuối phản chiếu cơ sở dữ liệu cho mỗi phiên bản SQL Server sẽ lưu trữ bản sao nhóm khả dụng và / hoặc phiên phản chiếu cơ sở dữ liệu. Điểm cuối phiên bản SQL Server này sau đó được chia sẻ bởi một hoặc nhiều bản sao nhóm khả dụng và / hoặc phiên sao chép cơ sở dữ liệu và là cơ chế giao tiếp giữa bản sao chính và các bản sao thứ cấp được liên kết.

Tùy thuộc vào khối lượng công việc sửa đổi dữ liệu trên bản sao chính, các yêu cầu về thông lượng nhắn tin của nhóm khả dụng có thể không nhỏ. Hoạt động này cũng nhạy cảm với lưu lượng truy cập từ hoạt động nhóm không có sẵn đồng thời. Nếu thông lượng đang bị ảnh hưởng do băng thông bị suy giảm và lưu lượng truy cập đồng thời, bạn có thể cân nhắc việc cô lập lưu lượng nhóm khả dụng với bộ điều hợp mạng chuyên dụng của riêng nó cho mỗi phiên bản SQL Server lưu trữ bản sao khả dụng. Bài đăng này sẽ mô tả quá trình này và cũng mô tả ngắn gọn những gì bạn có thể mong đợi thấy trong tình huống thông lượng bị suy giảm.

Đối với bài viết này, tôi đang sử dụng Cụm chuyển đổi dự phòng Windows Server (WSFC) năm nút khách ảo. Mỗi nút trong WSFC có phiên bản SQL Server độc lập riêng sử dụng bộ nhớ cục bộ không dùng chung. Mỗi nút cũng có một bộ điều hợp mạng ảo riêng cho giao tiếp công khai, một bộ điều hợp mạng ảo cho giao tiếp WSFC và một bộ điều hợp mạng ảo mà chúng tôi sẽ dành cho giao tiếp nhóm khả dụng. Vì mục đích của bài đăng này, chúng tôi sẽ tập trung vào thông tin cần thiết cho các bộ điều hợp mạng dành riêng cho nhóm khả dụng trên mỗi nút:

Việc thiết lập nhóm khả dụng bằng NIC chuyên dụng gần như giống với quy trình NIC dùng chung, chỉ để “ràng buộc” nhóm khả dụng với một NIC cụ thể, trước tiên tôi phải chỉ định LISTENER_IP trong CREATE ENDPOINT , sử dụng các địa chỉ IP nói trên cho các NIC chuyên dụng của tôi. Dưới đây cho thấy việc tạo từng điểm cuối trên năm nút WSFC:

:CONNECT SQL2K12-SVR1
 
USE [master];
GO
 
CREATE ENDPOINT [Hadr_endpoint] 
    AS TCP (LISTENER_PORT = 5022, LISTENER_IP = (192.168.20.31))
    FOR DATA_MIRRORING (ROLE = ALL, ENCRYPTION = REQUIRED ALGORITHM AES);
GO
 
IF (SELECT state FROM sys.endpoints WHERE name = N'Hadr_endpoint') <> 0
BEGIN
    ALTER ENDPOINT [Hadr_endpoint] STATE = STARTED;
END
GO
 
USE [master];
GO
 
GRANT CONNECT ON ENDPOINT::[Hadr_endpoint] TO [SQLSKILLSDEMOS\SQLServiceAcct];
GO
 
:CONNECT SQL2K12-SVR2
 
-- ...repeat for other 4 nodes...

Sau khi tạo các điểm cuối này được liên kết với NIC chuyên dụng, các bước còn lại của tôi trong việc thiết lập cấu trúc liên kết nhóm khả dụng không khác gì trong một kịch bản NIC được chia sẻ.

Sau khi tạo nhóm khả dụng của mình, nếu tôi bắt đầu điều khiển tải sửa đổi dữ liệu dựa trên cơ sở dữ liệu về tính khả dụng của bản sao chính, tôi có thể nhanh chóng thấy rằng lưu lượng giao tiếp của nhóm khả dụng đang chạy trên NIC chuyên dụng bằng Trình quản lý tác vụ trên tab mạng (phần đầu tiên là thông lượng cho nhóm khả dụng chuyên dụng NIC):

Và tôi cũng có thể theo dõi số liệu thống kê bằng cách sử dụng các bộ đếm hiệu suất khác nhau. Trong hình ảnh bên dưới, Inetl [R] PRO_1000 MT Network Connection _2 là NIC nhóm khả dụng chuyên dụng của tôi và có phần lớn lưu lượng NIC so với hai NIC khác:

Giờ đây, việc có một NIC chuyên dụng cho lưu lượng nhóm khả dụng có thể là một cách để cô lập hoạt động và cải thiện hiệu suất về mặt lý thuyết, nhưng nếu NIC chuyên dụng của bạn không đủ băng thông, như bạn có thể mong đợi hiệu suất sẽ bị ảnh hưởng và sức khỏe của cấu trúc liên kết nhóm khả dụng sẽ suy giảm.

Ví dụ:tôi đã thay đổi nhóm khả dụng chuyên dụng NIC trên bản sao chính thành băng thông truyền đi 28,8 Kbps để xem điều gì sẽ xảy ra. Không cần phải nói, nó không tốt. Thông lượng NIC của nhóm khả dụng giảm đáng kể:

Trong vòng vài giây, tình trạng của các bản sao khác nhau bị suy giảm, với một vài bản sao chuyển sang trạng thái "không đồng bộ hóa":

Tôi đã tăng NIC chuyên dụng trên bản sao chính lên 64 Kbps và sau vài giây cũng có mức tăng đột biến bắt kịp ban đầu:

Trong khi mọi thứ được cải thiện, tôi đã chứng kiến ​​các cảnh báo tình trạng ngắt kết nối và ngắt kết nối định kỳ ở cài đặt thông lượng NIC thấp hơn này:

Còn về số liệu thống kê chờ liên quan trên bản sao chính thì sao?

Khi có nhiều băng thông trên NIC chuyên dụng và tất cả các bản sao sẵn có đều ở trạng thái tốt, tôi đã thấy sự phân bổ sau đây khi tải dữ liệu của tôi trong khoảng thời gian 2 phút:

HADR_WORK_QUEUE đại diện cho một luồng nhân viên nền dự kiến ​​đang chờ công việc mới. HADR_LOGCAPTURE_WAIT đại diện cho một sự chờ đợi mong đợi khác để các bản ghi nhật ký mới có sẵn và theo Books Online, dự kiến ​​sẽ xảy ra nếu quá trình quét nhật ký bị bắt kịp hoặc đang đọc từ đĩa.

Khi tôi giảm thông lượng của NIC đủ để đưa nhóm khả dụng về trạng thái không hoạt động, phân phối kiểu chờ như sau:

Giờ đây, chúng tôi thấy một kiểu chờ hàng đầu mới, HADR_NOTIFICATION_DEQUEUE . Đây là một trong những kiểu chờ “chỉ sử dụng nội bộ” như được định nghĩa bởi Books Online, đại diện cho một tác vụ nền xử lý thông báo WSFC. Điều thú vị là kiểu chờ này không chỉ trực tiếp vào một vấn đề, tuy nhiên, các thử nghiệm cho thấy kiểu chờ này tăng lên hàng đầu cùng với thông lượng nhắn tin của nhóm khả dụng bị suy giảm.

Vì vậy, điểm mấu chốt là việc cô lập hoạt động nhóm khả dụng của bạn với một NIC chuyên dụng có thể có lợi nếu bạn đang cung cấp thông lượng mạng với đủ băng thông. Tuy nhiên, nếu bạn không thể đảm bảo băng thông tốt ngay cả khi sử dụng một mạng chuyên dụng, thì tình trạng của cấu trúc liên kết nhóm khả dụng của bạn sẽ bị ảnh hưởng.