alwayson高可用组

We have already configured our Availability Group, now we need to make it flexible and accessible. It’s time to check on how to create a listener in order to make a single access point for you AG!

我们已经配置了可用性组，现在我们需要使其变得灵活且可访问。 现在是时候检查如何创建侦听器以便为您创建一个单一的接入点了！

In continuation to our previous article, we are going to pass to another phase of this setup, as we already have our database in sync and safe, or highly available, depending of the chosen mode/architecture.

在上一篇文章的续篇中，我们将转到此设置的另一个阶段，因为我们已经使数据库同步且安全或具有高可用性，这取决于所选的模式/体系结构。

Notice that the Availability Groups is so flexible, that we can have multiple groups, in the same base cluster, with databases active on different instances. This way, aside of have a very good solution of high availability and disaster recovery, we will have a great option to balance the utilization of our hardware.

请注意，可用性组是如此灵活，以至于我们可以在同一基础集群中拥有多个组，并且数据库在不同实例上处于活动状态。 这样，除了具有非常好的高可用性和灾难恢复解决方案之外，我们还有一个很好的选择来平衡硬件的利用率。

In the previous picture, you can see an example of a configuration involving 3 standalone instances, with 3 Availability Groups setup. If we balance the databases in a proper way, on each Availability Group (AG01, AG02 and AG03) we will be able to keep each Availability Group active in a dedicate node, having the others with a secondary role, which can be read-only, or just closed to connections and acting as a standby database. This situation is comparable to a cluster of two nodes with two clustered instances installed and active on opposite nodes, what people call “active-active” cluster (wrongly by the way).

在上一张图片中，您可以看到一个包含3个独立实例和3个可用性组设置的配置示例。 如果我们以适当的方式平衡数据库，则在每个可用性组（AG01，AG02和AG03）上，我们将能够使每个可用性组在专用节点上保持活动状态，让其他可用性组具有次要角色，这些角色可以是只读的，或者仅关闭连接并充当备用数据库。 这种情况相当于两个节点的群集，其中两个群集实例已安装并且在相对的节点上处于活动状态，这就是人们所说的“主动-主动”群集（顺便说一句）。

With the scenario just described, the use of a listener is highly recommended, allowing us to failover the Availability Group without having to worry about change connection strings.

在上述情况下，强烈建议使用侦听器，这使我们可以对可用性组进行故障转移，而不必担心更改连接字符串。

听众 ( The Listener )

So, now it’s time to configure the listener! But first, what is a listener and for what is this used for?

因此，现在该配置监听器了！ 但是首先，监听器是什么，它的作用是什么？

As we have the virtual AD Computer, in a SQL Server clustered instance, we will have the listener in the Availability Group in order to offer a single point of access to a group of databases. To create a listener, we will also need an IP and Computer in the AD, and don’t forget that the cluster computer should have full access to the SQL Server computer account.

由于拥有虚拟AD计算机，因此在SQL Server群集实例中，我们将在可用性组中具有侦听器，以便提供对一组数据库的单点访问。 要创建侦听器，我们还需要AD中的IP和计算机，并且不要忘记群集计算机应该具有对SQL Server计算机帐户的完全访问权限。

In our case we will be using the following cluster, as shown in the part one:

在本例中，我们将使用以下集群，如第一部分所示：

So, the AD Computer name “W2012R2CLT01” should have full access tour listener “SQLSRVAG01”, associated to the VIP 190.100.100.51. Don’t forget to disable the Computer “SQLSRVAG01” after create, otherwise the listener creation is going to fail.

因此，AD计算机名称“ W2012R2CLT01”应具有与VIP 190.100.100.51关联的完全访问巡回监听器“ SQLSRVAG01”。 不要忘记在创建后禁用计算机“ SQLSRVAG01”，否则侦听器的创建将失败。

You may be asking: Is the listener required? The answer is “no”! You can survive without the listener, like we always survived when using the database mirroring. Its role is just redirect the connections to the right route. By default it will redirect us to the Primary Replica, where the database is both readable and writable.

您可能会问：是否需要听众？ 答案是不”！ 您可以在没有侦听器的情况下生存，就像我们在使用数据库镜像时始终生存一样。 它的作用只是将连接重定向到正确的路由。 默认情况下，它将把我们重定向到主副本，在该副本中数据库是可读写的。

In a scenario of a Disaster Recovery environment, where you have a production instance in a datacenter and the disaster recovery instance in another one, is common to see this approach, as the secondary databases aren’t even readable!

在灾难恢复环境中，在一个数据中心中有一个生产实例，在另一个数据中心中有一个灾难恢复实例，这种方法很常见，因为辅助数据库甚至不可读！

设置监听器 ( Setting up the Listener )

So let’s now check the steps to add a listener to an Availability Group!

现在，让我们检查将侦听器添加到可用性组的步骤！

Assuming that you have the VIP, the AD Computer and that all prerequisites are met, let’s start!

假设您拥有VIP，AD计算机并且满足所有先决条件，那就开始吧！

Connect, using the SQL Server Management Studio, to the instance where the Primary Replica for your Availability Group is active. Expand your group as shown.

使用SQL Server Management Studio连接到您的可用性组的主副本处于活动状态的实例。 如图所示扩展您的组。

Now right-click on “Availability Group Listeners”, and choose the “Add Listener” option.

现在，右键单击“可用性组侦听器”，然后选择“添加侦听器”选项。

A new window will be opened. Fill the “Listener DNS Name” with the name of your AD Computer Name. In our case SQLSRVAG01. In the “Port” field, choose an adequate port, something that is not being used.

将打开一个新窗口。 在“侦听器DNS名称”中填写您的AD计算机名称的名称。 在我们的例子中是SQLSRVAG01。 在“端口”字段中，选择一个未使用的适当端口。

Now in the “Network Mode”, choose the “Static IP” option, and click in the “Add” button in the bottom right of the window.

现在，在“网络模式”中，选择“静态IP”选项，然后单击窗口右下方的“添加”按钮。

Anther window will pop, and it’s time to set the IP of our listener.

将会弹出另一个“花药”窗口，是时候设置监听器的IP了。

Select the proper subnet, related to your IP and fill the IPv4 Address.

选择与您的IP相关的正确子网，并填写IPv4地址。

Now, click ok in this window, and in the remaining one. And this is what you will have:

现在，在此窗口中单击“确定”，然后在其余窗口中单击“确定”。 这就是您将拥有的：

In the failover cluster perspective, this is how it looks like:

从故障转移群集的角度来看，这是这样的：

Notice the dependence between the computer name and the virtual IP. As we are looking to the Failover Cluster Manager now, is a good time to say that, even being feasible to do changes from the Failover Cluster Manager, don’t do this! All the changes need to be made from the SQL Server side, or rephrasing, all the changes must be made from the SQL Server Management Studio! Otherwise you risk to break your configuration.

请注意计算机名称和虚拟IP之间的依赖关系。 现在，我们正在寻找故障转移群集管理器，这是一个很好的时机，即使可以通过故障转移群集管理器进行更改，也不要这样做！ 所有更改都需要在SQL Server端进行，或者改写，所有更改都必须在SQL Server Management Studio中进行！ 否则，您可能会破坏配置。

测试连通性 ( Testing the connectivity )

Now that our listener is online and listening, we can check if it is working fine. First let’s see if the connectivity from the application server is opened, using the famous Telnet Client. In Windows, go to “Run” and write “cmd”, press enter.

现在，我们的监听器已联机并且正在监听，我们可以检查它是否工作正常。 首先，让我们看看使用著名的Telnet客户端是否打开了来自应用程序服务器的连接。 在Windows中，转到“运行”并输入“ cmd”，然后按Enter。

Now, in the command line, write the following:

现在，在命令行中输入以下内容：

“telnet <your listener name> <listener port>”

“ telnet <您的侦听器名称> <侦听器端口>”

As bellow:

如下所示：

If you execute the command and see the following (empty black screen), that means that you were able to connect!! So all good.

如果执行命令并看到以下内容（黑屏为空），则表示您可以连接！！ 一切都很好。

If your result is like the following, something is wrong:

如果您的结果如下所示，则说明有问题：

In that case, check if you didn’t misspell something (the hostname or the port), if all looks good, you might check the Windows Firewall, if enabled, and add the exception for this IP/Port. Another try is use the listener IP, instead f the computer name. If the connection using the IP works, you need to check why the name resolution is not working. Talk with the Domain/DNS/System Administrators in order to troubleshoot that.

在这种情况下，请检查是否没有拼写错误（主机名或端口），如果一切看起来不错，则可以检查Windows防火墙（如果已启用），并为此IP /端口添加例外。 另一种尝试是使用侦听器IP，而不是使用计算机名称。 如果使用IP的连接有效，则需要检查为什么名称解析不起作用。 与域/ DNS /系统管理员联系以解决此问题。

If all looks good on Windows point of view, and if the instance/listener are really only and should be replying, you need to check with the Networking team of your company, on order to have this unlocked. Always pas to them the following information:

如果从Windows的角度看一切都很好，并且实例/侦听器实际上只是一个并且应该答复，则需要与公司的网络团队联系，以解除锁定。 始终向他们提供以下信息：

• Source IP and hostname (from where you are connecting).源IP和主机名（从您连接的地方）。
• Destination IP and hostname.目标IP和主机名。
• Destination port.目的端口。

In the second part of this article, we explained the basic concepts of an Availability Group listener, checked what are the prerequisites, how to actually create a listener using a computer name and a static virtual IP and finally how to test if our application server has connectivity to our newly created access point to the availability groups. Keep tuned, as this series is still not done!

在本文的第二部分中，我们解释了可用性组侦听器的基本概念，检查了先决条件，如何使用计算机名和静态虚拟IP实际创建侦听器，最后如何测试应用程序服务器是否具有与我们新创建的可用性组访问点的连接。 请继续关注，因为该系列仍未完成！

Previous articles in this series:

本系列以前的文章：

• AlwaysOn Availability Groups – How to setup AG between a clustered and standalone instance (Part 1)AlwaysOn可用性组–如何在集群实例和独立实例之间设置AG（第1部分）
• AlwaysOn Availability Groups – How to setup AG between a clustered and standalone instance (Part 2)AlwaysOn可用性组–如何在集群实例和独立实例之间设置AG（第2部分）

翻译自: https://www.sqlshack.com/alwayson-availability-groups-how-to-setup-ag-between-a-clustered-and-standalone-instance-part-3/

alwayson高可用组