Swapping out a physical hardware Head Office DC onto new hardware, the old Server 2008 R2 was dcpromo'd down - and removed from the domain and new 2012 R2 put in it's place and dcpromo'd up. As dcpromo no longer exists in Server 2012 I suppose we should say 'promoted to a DC'.
Things went wrong as the new HO DC used a Remote Site DC as its logonserver etc, and the AD had not replicated the information about the new DC to the remote site. This created a mess that needed tidying up - another story.
The main question was why the new HO DC did not use another HO DC after reboot for logons etc. Why had it gone off to a remote DC?
My colleague started looking through the dcpromo logs and found that this server was unable to work out what site the server was in. This data had not changed for years and indeed the site subnet was correct...on IP4.
There was no site subnet entry for IP6. A site subnet entry for IP6 was added in Active Directory Sites and Services and the promotion retried after tidying up, and all went perfectly.
The relationship/usage of IP4 and IP6 in different parts of Windows has never been effectively documented, and it appears that at sometime this code was changed from using IP4 site lookup to IP6.
There are 2 things to take from this dcpromo:
1) Always leave time for AD replication to happen between each part of the DC promotion process if you can afford to
2) Fill in IP6 site subnets if using Server 2012 R2
If you really want/need to speed up intra site replication beyond the 15 minute minimum limit allowed by the Windows GUI then read this article:
http://blogs.technet.com/b/qzaidi/archive/2010/09/23/enable-change-notifications-between-sites-how-and-why.aspx
Showing posts with label Replica. Show all posts
Showing posts with label Replica. Show all posts
Saturday, 8 March 2014
Sunday, 25 August 2013
EnableWriteOrderPreservationAcrossDisks not in Hyper-V Replica GUI or set ON by default for new replicas
One of the most frustrating things about Hyper-V Replica (which I believe is the best feature of Hyper-V Server 2012 and truly a game changer to SMBs) is the lack of totally CLEAR and UNAMBIGUOUS up front information relating to the support of mission critical systems like SQL Server and Exchange.
Both SQL Server and Exchange databases have one thing in common - they write out to a log whenever data is committed before they write out to the main data store. This ensures consistency under all recovery situations with excellent performance and the ability to replay transactions etc etc. Best practice is to put the logs and databases onto 'different disks' to improve performance/recovery. In the context of Hyper-V this is interesting as it means placing a Hyper-V vhd(x) file onto it's own physical disk. Either way that is a different discussion.
However, this is the undoing of Hyper-V Replica since it does not guarantee that writes to different disks will be applied to the replica in the same order. This could create disastrous results where the log and main data store are subtly out of sync whilst fooling the administrators of the system that everything is working perfectly. That is the worst possible scenario. During a planned fail-over when the primary is closed down in an orderly manner it would appear to work beautifully as the disks would all be sync'd but come the day of disaster and the writes have not been applied in the correct sequence it would not work correctly and you are out of business - literally. There should be far more on this subject.
The worst aspect is that you have to know the problem might exist to start hunting down the answer and that means you will be trawling around for a while looking for reasonably definitive information. Those unaware of the foibles of SQL, Exchange et al are waiting to fall at the first unplanned fail-over.
At time of writing I found that SQL Server is supported
http://support.microsoft.com/kb/956893
and Exchange is not supported
http://blogs.technet.com/b/rmilne/archive/2013/07/29/exchange-and-hyper-v-replica-support.aspx
However, I cannot see any reason why Exchange not using DAGs would not work perfectly. I suspect that DAGs are the supported option so that is what you are forced to use. The Hyper-V replica is certainly much easier to set up and maintain for smaller organisations with say 1 Exchange server than a DAG. I can see Hyper-V replica and DAGs together would be a very poor idea.
When Hyper-V 1 first came out (remember the 180 day promise after Server 2008 RTM!) I ran a Blackberry Enterprise Server 4.1 on it even though it was not supported. I knew it would just work and it did for several years until the BES Server was replaced. I did not expect any support from anyone but that is always the best way so you know in your own mind you are doing it right!
So if you want to use a SQL Server workload you will need to use the EnableWriteOrderPreservationAcrossDisks flag on replica creation using the
Set-VMReplication cmdlet.
This means you must use PowerShell to create the replica as unfortunately this flag is not available in the GUI so the unknowing will not set it or be aware of it.
This flag should be in the GUI, and it should have comments like:
This feature ensures data writes are consistent across disks for Enterprise database systems such as SQL Server
This flag should be set if you are running a SQL Server workload - see KB111111
Exchange workloads are specifically not supported - see KB222222
For other workloads please read KB333333
What I don't understand is that if there is little performance loss or other downsides (I don't know) then setting that flag ON should be the default behavior when you create a replica and not a hidden away afterthought.
Both SQL Server and Exchange databases have one thing in common - they write out to a log whenever data is committed before they write out to the main data store. This ensures consistency under all recovery situations with excellent performance and the ability to replay transactions etc etc. Best practice is to put the logs and databases onto 'different disks' to improve performance/recovery. In the context of Hyper-V this is interesting as it means placing a Hyper-V vhd(x) file onto it's own physical disk. Either way that is a different discussion.
However, this is the undoing of Hyper-V Replica since it does not guarantee that writes to different disks will be applied to the replica in the same order. This could create disastrous results where the log and main data store are subtly out of sync whilst fooling the administrators of the system that everything is working perfectly. That is the worst possible scenario. During a planned fail-over when the primary is closed down in an orderly manner it would appear to work beautifully as the disks would all be sync'd but come the day of disaster and the writes have not been applied in the correct sequence it would not work correctly and you are out of business - literally. There should be far more on this subject.
The worst aspect is that you have to know the problem might exist to start hunting down the answer and that means you will be trawling around for a while looking for reasonably definitive information. Those unaware of the foibles of SQL, Exchange et al are waiting to fall at the first unplanned fail-over.
At time of writing I found that SQL Server is supported
http://support.microsoft.com/kb/956893
and Exchange is not supported
http://blogs.technet.com/b/rmilne/archive/2013/07/29/exchange-and-hyper-v-replica-support.aspx
However, I cannot see any reason why Exchange not using DAGs would not work perfectly. I suspect that DAGs are the supported option so that is what you are forced to use. The Hyper-V replica is certainly much easier to set up and maintain for smaller organisations with say 1 Exchange server than a DAG. I can see Hyper-V replica and DAGs together would be a very poor idea.
When Hyper-V 1 first came out (remember the 180 day promise after Server 2008 RTM!) I ran a Blackberry Enterprise Server 4.1 on it even though it was not supported. I knew it would just work and it did for several years until the BES Server was replaced. I did not expect any support from anyone but that is always the best way so you know in your own mind you are doing it right!
So if you want to use a SQL Server workload you will need to use the EnableWriteOrderPreservationAcrossDisks flag on replica creation using the
Set-VMReplication cmdlet.
This means you must use PowerShell to create the replica as unfortunately this flag is not available in the GUI so the unknowing will not set it or be aware of it.
This flag should be in the GUI, and it should have comments like:
This feature ensures data writes are consistent across disks for Enterprise database systems such as SQL Server
This flag should be set if you are running a SQL Server workload - see KB111111
Exchange workloads are specifically not supported - see KB222222
For other workloads please read KB333333
What I don't understand is that if there is little performance loss or other downsides (I don't know) then setting that flag ON should be the default behavior when you create a replica and not a hidden away afterthought.
Subscribe to:
Posts (Atom)