Find more details in the AWS Knowledge Center: repost.aws/knowledge-center/e... Noureddine, an AWS Cloud Support Engineer, create a SQL Server Always On Availability Group Cluster in the AWS cloud?
sorry quick question, i see network interface can have multiple IP addresses? does that act like as though it has 3 network cards/interfaces per ip address or does it just be able to ping those 3 ip addresses per network interface? and just curious why give it 3 ip addresses, and not maybe just give 2 network interface with 1 ip each?
Hi This is a great video. Can you advise how to connect to the SQL instance from another server within the same vpc? I can connect to the private primary IP addresses but cannot figure out how to connect to the Availability Group Listener? What Ip address or server name do I need to use? Thanks Devin
Hello, I followed this set up to configure SQL Server Always On AG with AG Listener, I can connect to the SQL Server using the AG Listener but the application server is not able to connect through the listener and when I ping the AG listener from the application server, the IP resolve to the secondary AG Listener IP instead of the primary AG Listener IP. What could be causing this inconsistency?
Hey, David! 👋 The community on our re:Post forum may be able to assist with this one. Be sure to post more info about your use case, here: go.aws/aws-repost. 📌 You can also check out the following, which addresses quorum settings: go.aws/3LGKeZe. 👈 ^KS
Listener configuration is so WRONG! There should be a single IP address to connect to the PRIMARY REPLICA. Clients should not have to connect to individual nodes. This should be transparent to clients.
The listener config is not wrong. AWS doesn't require a layer 4 load balancer like Azure. So you need to deploy the SQL nodes across subnets and associate the Listener IPs to the EC2 NIC.
Additionally, DNS will register all ips or you could configure the cluster to register the active ip. This may be applicable to older clients that aren't multi-subnet aware. Latest .NET clients are multi subnet aware and will retry until the connection is made to the active IP. I think you may be comparing Azure to AWS listener config or on-premises.
@@noureddineennacir515 Well... Setting up a listener is neither an Azure nor an AWS thing... it's a SQL Server thing... Its purpose is to allow all clients to be able to transparently connect to the cluster using a single address, regardless of which of the nodes currently serves as the Primary Replica. Adding a second IP address to every single replica and offloading the responsibility to find the proper node to the client kind of defeats the purpose of setting up the replica in the first place. Relying on "latest .NET clients" isn't ideal as many client apps are built on different OS and use drivers other than MS native SQL client. Relying on the DNS also sounds like a bad idea, given the TTL and propagation delays. Failovers should be quick, in order to minimize downtime. Bottom line: Clients don't even need to know they are connecting to a Cluster. And they should never be given the responsibility of determining which individual replica they need to connect to.
@@GrosTabarnak He configured the cluster using two separate subnets. Each server is in a different subnet. A SQL Server AG listener needs one IP in each subnet of a multi-subnet cluster.
