Stairway to AlwaysOn Level 8: Segregate Mirror Traffic in AlwaysOn

  • Comments posted to this topic are about the item Stairway to AlwaysOn Level 8: Segregate Mirror Traffic in AlwaysOn

    -----------------------------------------------------------------------------------------------------------

    "Ya can't make an omelette without breaking just a few eggs" 😉

  • 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?

    ---------------------------------------------------------------------

  • Thanks for the post. But I don't understand the "DNS A" part of code.

  • 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 J. Adams
    Blog
    Twitter

  • thought so, cheers Adam

    ---------------------------------------------------------------------

  • Thanks for the article.

  • 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" 😉

  • 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