Kết nối Luôn luôn vấn đề người nghe AG

Tôi là người mới sử dụng công nghệ microsoft và tôi gặp sự cố trong phần kết nối cho SQL Server 2014. Đây có thể là một vấn đề dễ dàng nhưng tôi bị mắc kẹt.

Tôi có 4 máy chủ. Một trong số đó là Bộ điều khiển miền Active Directory, một là máy chủ ứng dụng và những cái khác đang được sử dụng cho Máy chủ SQL. Vì đó là vấn đề kết nối, IP cho máy chủ là; -AD DC: 10.6.0.100 (Cũng là Máy chủ DNS) -APP: 10.6.0.110 -Query 1: 10.6.0.120 -Query 2: 10.6.0.121

Tôi đã tạo thành công cụm chuyển đổi dự phòng (DBCLUSTER) và đặt địa chỉ IP của FC là 10.6.0.130 ( không phải là IP máy chủ thực tế, tôi thực sự không có phần này ..).

Sau đó, tôi đã tạo Nhóm Luôn sẵn sàng cho các máy chủ sql. Tôi đã tạo thành công AG mà không cần người nghe. Tôi có thể kết nối với các máy chủ với nhau, cơ sở dữ liệu đồng bộ hóa mà không có vấn đề. Sau đó, tôi đã tạo một trình lắng nghe ( AG-LISTENER ) và đặt ip của nó là 10.6.0.131 ( một lần nữa không phải là IP máy chủ thực tế ?) Và đặt cổng của nó thành 5525 . Nó không có vấn đề gì.

Vì vậy, tôi muốn kiểm tra kết nối. Khi tôi muốn tạo kết nối từ máy chủ APP tới SQL 1 hoặc SQL 2 trực tiếp , tôi có thể kết nối mà không gặp vấn đề gì. Nhưng khi tôi cố gắng kết nối với AG-LISTENER , nó không thể tìm thấy nó trên mạng. Khi tôi kiểm tra các bản ghi DNS. Tôi có thể thấy nó như được lưu trữ vào ngày 10.6.0.131 .

Khi tôi cố gắng ping đến AG-LISTENER từ các máy chủ AD-DC, APP, SQL 2 , nó phản hồi rằng máy chủ đích không thể truy cập được (nó ping 10.6.0.131 nhưng phản hồi đến từ IP của AD-DC, APP và SQL 2 may chủ). Nó có thể kết nối từ máy chủ SQL 1, là chính cho AG.

Tôi đã kiểm tra tường lửa, không có vấn đề gì. Nhưng tôi nghĩ đây là một vấn đề mạng mà tôi không có manh mối.

PS: Máy chủ đang hoạt động trên Windows Server 2012 và không được lưu trữ trên Azure.

GIẢI PHÁP

Nguyên nhân của vấn đề là cấu trúc liên kết mạng của nhà cung cấp dịch vụ. Người ta thấy rằng 10.6.0.0 / 32 của IP có thể được sử dụng bởi các máy chủ khác của các khách hàng khác. Vì vậy, họ đã phân bổ cho chúng tôi một khối IP khác mà chỉ chúng tôi có quyền truy cập và nó hoạt động như một cơ duyên.

Nó có thể kết nối từ máy chủ SQL 1, là chính cho AG.

Bằng cách "kết nối", bạn có nghĩa là nó có thể ping AG-LISTENER từ SQL1?

Có vẻ như vấn đề của bạn là gì với số cổng bạn đã chọn cho người nghe. Bằng cách chọn 5525, bạn đang chọn một cổng không mặc định (1433 sẽ là mặc định).

Vậy khi bạn cố gắng kết nối với người nghe, chuỗi kết nối của bạn trông như thế nào? Tôi đoán nó trông giống như thế này:

data source = ag-listener; initial catalog = ...

Bạn có hai lựa chọn ở đây. Bạn có thể rõ ràng với số cổng của người nghe:

data source = ag-listener,5525; initial catalog = ...

Tương tự như vậy, nếu bạn đang thử nghiệm này với SQL Server Management Studio (SSMS), sau đó cho Connect to Server hộp thoại, thay vì đặt ở ag-listenercho Server name text box, đưa vào ag-listener,5525.

Hoặc bạn có thể thay đổi cổng mà người nghe của bạn đang nghe đến 1433 (đọc tài liệu tham khảo BOL dưới đây trước khi xem xét thay đổi này):

alter availability group YourAvailabilityGroupName
modify listener 'AG-LISTENER'
(
    port = 1433
);

Điều đáng chú ý khi bạn có thể sử dụng cổng mặc định (1433). Hãy xem tài liệu tham khảo này trên BOL giải thích khi bạn có thể và không thể sử dụng 1433 cho người nghe (trích đoạn / dán bên dưới để tham khảo):

Bạn có thể định cấu hình cổng mặc định thành 1433 để cho phép đơn giản các chuỗi kết nối máy khách. Nếu sử dụng 1433, bạn không cần chỉ định số cổng trong chuỗi kết nối. Ngoài ra, vì mỗi trình nghe nhóm khả dụng sẽ có một tên mạng ảo riêng biệt, mỗi trình nghe nhóm khả dụng được cấu hình trên một WSFC có thể được cấu hình để tham chiếu cùng một cổng mặc định 1433.

(các phần bị bỏ qua cho ngắn gọn)

Nếu bạn sử dụng cổng mặc định 1433 cho các VNN của nhóm khả dụng, bạn vẫn cần đảm bảo rằng không có dịch vụ nào khác trên nút cụm đang sử dụng cổng này ; nếu không thì điều này sẽ gây ra xung đột cổng.

EDIT : Nếu ở trên không phải là vấn đề của bạn (như được thấy từ bình luận của bạn bên dưới) thì sau khi bạn xem qua nhật ký, tôi sẽ nói cách hành động tốt nhất tiếp theo là bắt đầu nhìn vào lưu lượng mạng để xem đó là gì ( và không) xảy ra. Bạn có thể sử dụng một công cụ giám sát mạng như netmon để thực hiện việc này.

Một điều nữa tôi sẽ làm và tôi nhận ra rằng bạn nói rằng tường lửa không phải là vấn đề, nhưng tôi sẽ xem cổng có thực sự lắng nghe không (công cụ yêu thích của tôi cho việc này là portqry ).