March 9, 2016 at 12:00 am
Comments posted to this topic are about the item Stairway to Always On Level 8: Segregate Mirror Traffic in AlwaysOn
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
March 9, 2016 at 6:51 am
thanks as always Perry.
I presume if you decide to segregate the traffic after initial set up you can do this by use of the alter endpoint command?
---------------------------------------------------------------------
March 9, 2016 at 7:17 am
Thanks for the post. But I don't understand the "DNS A" part of code.
March 9, 2016 at 8:57 am
Please note that the code used to create the Endpoint in this article specifies RC4 for the encryption type and RC4 has been deprecated. It would be best to use AES, which is what the GUI will use.
As for the question on altering the endpoint, please see these two blog posts that should help.
http://www.ryanjadams.com/2016/01/change-availability-group-endpoint-ip
http://www.ryanjadams.com/2016/01/change-availability-group-endpoint-port
March 9, 2016 at 9:24 am
thought so, cheers Adam
---------------------------------------------------------------------
March 10, 2016 at 4:46 pm
Thanks for the article.
March 14, 2016 at 10:59 am
george sibbald (3/9/2016)
thanks as always Perry.I presume if you decide to segregate the traffic after initial set up you can do this by use of the alter endpoint command?
either alter the endpoint or just drop and recreate
Ryan Adams (3/9/2016)
Please note that the code used to create the Endpoint in this article specifies RC4 for the encryption type and RC4 has been deprecated. It would be best to use AES, which is what the GUI will use.As for the question on altering the endpoint, please see these two blog posts that should help.
http://www.ryanjadams.com/2016/01/change-availability-group-endpoint-ip
http://www.ryanjadams.com/2016/01/change-availability-group-endpoint-port
Ryan, thanks for highlighting this and yes of course we should always follow best practice.
Recall though that the mirror network should be segregated, if the mirror network is truly segregated and isolated (as it should be), then no traffic may be intercepted "across the wire" by other machines, only the machines involved in the mirror session have access.
Sending RC4 communications out over a public network is a real concern.
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
February 1, 2017 at 4:08 pm
Thank you for this article and the series itself !
Historically, perhaps others have explored problems with interruptions / exceptions, err events, in mirror traffic described here.
Any "common-type" problems, DBAs periodically experience with heavy trxs in today's more "modern" networks ( local, wans )
assuming network infrastructure, related configs, etc are well made and implemented optimally ?
Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply