HowardDix85
asked on
Evicting Live Node from DAG
We have 4 servers in a single DAG over 2 sites. There are DB partnerships in both directions
To ensure we stick to best practice we need to create a new DAG and migrate 2 of the servers to the new Dag. This is because the DAg primary server keeps switching between the 2 remote sites at will and we have the potential for split brain syndrome.
Can we evict the active server from the DAG while the Databases are still ownded by that MBXserver? We were going to use a swing server to complete the migration by using DB portability to mount the DB's on the standalone server then re-mount the DB on the existing server once the new DAG was online and the existing server a member of it.
However there is a concern with the storage It is also against best practice to do so. the official thread is to build a new mailbox server and migrate all the mailboxes to new databases.
All the referencing I have shows that the database cant be evicted while holding DB copies as part of a DAG.
To be clear,
1) We would remove all the passive copies leaving only the live copies on the server we want to evict.
2) Can we interactively update the DB master ? This seems to be the issue with evicting from the DAG as the DB master will remain as the DAG name, not the host server.
3) Is this method feasible, has anyone on EE done it this way before.
4) I would prefer to complete this using the BP method but its not 100% feasible.
I will try and deploy a test server
To ensure we stick to best practice we need to create a new DAG and migrate 2 of the servers to the new Dag. This is because the DAg primary server keeps switching between the 2 remote sites at will and we have the potential for split brain syndrome.
Can we evict the active server from the DAG while the Databases are still ownded by that MBXserver? We were going to use a swing server to complete the migration by using DB portability to mount the DB's on the standalone server then re-mount the DB on the existing server once the new DAG was online and the existing server a member of it.
However there is a concern with the storage It is also against best practice to do so. the official thread is to build a new mailbox server and migrate all the mailboxes to new databases.
All the referencing I have shows that the database cant be evicted while holding DB copies as part of a DAG.
To be clear,
1) We would remove all the passive copies leaving only the live copies on the server we want to evict.
2) Can we interactively update the DB master ? This seems to be the issue with evicting from the DAG as the DB master will remain as the DAG name, not the host server.
3) Is this method feasible, has anyone on EE done it this way before.
4) I would prefer to complete this using the BP method but its not 100% feasible.
I will try and deploy a test server
Also... quick extra thought... you could block activation on the remote site... you will still replicate data, however the database will never automatically mount. You will have to manually allow it in the case of failure.
By database
By Server
By database
Suspend-MailboxDatabaseCopy –identity <DBName> –ActivationOnlyResume-MailboxDatabaseCopy –identity <DBName>By Server
Set-MailboxServer –identity EXCH1 –DatabaseCopyAutoActivationPolicy BlockedSet-MailboxServer –identity EXCH1 –DatabaseCopyAutoActivationPolicy Unrestricted
If you remove the copy of the database off that server, then remove the server from the DAG, then Exchange will move the ownership of the database to another server on its own.
The key bit is using the Exchange tools rather than the cluster tools to evict the server. You would only tend to use evict of the server is not behaving itself.
Simon.
The key bit is using the Exchange tools rather than the cluster tools to evict the server. You would only tend to use evict of the server is not behaving itself.
Simon.
ASKER
Hi,
We have DB partnerships in both sites of the Dag so DAC is already configured. We cant have FSW on both sides of the DAG as this will create a split brain. Both Sites are Active / Active as below:
Site1
Svr1: Active DB for Site 1
Svr2: Passive Db for Site2
Site2
Svr3: Active DB for Site2
Svr4: Passive DB for Site1
We want to make
Dag1
Svr1
Svr4
Dag2
Svr3
Svr4
We already prevent activation of the DB's in a failover situation given un-reliable connectivity between the 2 sites.
We are going on MS advise to split both Dag's up and achieve primary / secondary site quorum Independent of both sites being online.
We have DB partnerships in both sites of the Dag so DAC is already configured. We cant have FSW on both sides of the DAG as this will create a split brain. Both Sites are Active / Active as below:
Site1
Svr1: Active DB for Site 1
Svr2: Passive Db for Site2
Site2
Svr3: Active DB for Site2
Svr4: Passive DB for Site1
We want to make
Dag1
Svr1
Svr4
Dag2
Svr3
Svr4
We already prevent activation of the DB's in a failover situation given un-reliable connectivity between the 2 sites.
We are going on MS advise to split both Dag's up and achieve primary / secondary site quorum Independent of both sites being online.
The design you have is one I have come across numerous times, and as you have found it simply doesn't work in the way people expect. I think I removed that design four or five times last year, including for one of the UK's biggest house builders.
What I would do is failover the databases to the servers where you want them to be. Then remove the passive copies completely, deleting the files etc.
You should then be able to remove the two servers you want to move to the second DAG without any problems, then recreate the DAG as you prefer.
Just wait long enough for the domain to fully replicate before making the next change.
Simon.
What I would do is failover the databases to the servers where you want them to be. Then remove the passive copies completely, deleting the files etc.
You should then be able to remove the two servers you want to move to the second DAG without any problems, then recreate the DAG as you prefer.
Just wait long enough for the domain to fully replicate before making the next change.
Simon.
In your case, with the configuration you have I would agree with MS and split the DAG.
Simon's outline above is definitely the way to go.
Simon's outline above is definitely the way to go.
ASKER
Hi,
Im aware of 99% of the procedure. However normally I would build another mailbox server to migrate the DB's to and swing the dag from there. I guess the essense of my question is the following.
Can we evict a mailbox server from a DAG while it contains live databases ?
Sorry to be pedantic but i need a specific answer
Im aware of 99% of the procedure. However normally I would build another mailbox server to migrate the DB's to and swing the dag from there. I guess the essense of my question is the following.
Can we evict a mailbox server from a DAG while it contains live databases ?
Sorry to be pedantic but i need a specific answer
Simple answer - No. You need to stop replication with suspend-mailboxdatabasecop
then Remove-DatabaseAvailabilit
then Remove-DatabaseAvailabilit
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Hi Guy,
I only needed the last answer :) thank you. ill update shortly.
I only needed the last answer :) thank you. ill update shortly.
ASKER
Hi All,
To maintain clarity on this.
To remove the node you must remove all additional copies of databases that are not on the server you want to remove and then complete a full re-seed of all databases.
Additionally you must ensure that all resources are showing as online within the Failover cluster and that the cluster IP address is reachable and responsive. You must also plan to run backups and truncate throughout the process if connectivity is poor as transaction logs must be maintained throughout the reseed on all seeding databases, you cant truncate them.
Managed to split the DAG into 2 independent DAG's without using a swing server or too much hassle over the long weekend.
Thanks guys.
To maintain clarity on this.
To remove the node you must remove all additional copies of databases that are not on the server you want to remove and then complete a full re-seed of all databases.
Additionally you must ensure that all resources are showing as online within the Failover cluster and that the cluster IP address is reachable and responsive. You must also plan to run backups and truncate throughout the process if connectivity is poor as transaction logs must be maintained throughout the reseed on all seeding databases, you cant truncate them.
Managed to split the DAG into 2 independent DAG's without using a swing server or too much hassle over the long weekend.
Thanks guys.
Excellent, good to hear Howard,
This will prevent the feared split brain and give you control of where the databases can be failed over to.
You do this with the command
Open in new window
Have a read of this.. its for 2013 but is exactly the same for 2010
https://technet.microsoft.com/en-us/library/dd979790%28v=exchg.150%29.aspx
I feel you are about to undertake a huge task for something you could remedy with some configuration changes.