Exchange 2010 DAG + Metrocluster

[mg]

Hello,

Aside the fact that it’s in some ways a waste because DAG + SyncMirror means 4 copies of a database, are there any specific limitations to hosting Exchange 2010 DAG on a fabric MetroCluster?

Thanking you in advance for your help,

Kind regards,

Michel

[ple]

Hello Michel,

I think the best practices is to exclude the exchange 210 DAG environment from the MC operation (use of SyncMirror)  :

Create 2 specific aggregates for Exchange 2010 DAG environment  1 on site1 an the second on site 2) and don't  use "syncMirror" to synchronise these agregates, use only the Exchange 2010 replication process.

Regards

Philippe

[thomas_glodde]

hi phil,

when doing so (having unmirrored aggregates in a MC) you expose your whole system to unplanned outages as a nonmirrored aggregate can cause a whole MC to stop.

Regarding Exchange 2010, we either go for the 4 copies (for small environments) or we put both copys on one netapp node (if the MC isnt stretched few miles apart) and dedupe these 2 copies to 1.

Regards,

Thomas

[abuchmann]

Hi Thomas

This is interessting. We have our exc2010 dbs on mirrored aggregates, but I'm planing to build a new, unmirrored aggregate to save some space. (also because of sql 2012)

Do you have more information for the fact that this can cause a whole MC to stop?

Kind regards,

adrian

[ple]

Hi Adrian,

I think Thomas talk about  (FAQ MetroCluster - June 2012):

"

Can non-mirrored aggregates be used on MetroClusters?

Yes, non-mirrored aggregates can be used for both Stretch and Fabric MetroCuster. However, with Fabric MetroCluster all
storage must connect through the switches (no direct attached), and with Stretch MetroCluster all storage must be seen by both controllers.

Also, non-mirrored aggregates will not be available during takeover and multi-disk failures on non-mirrorred aggregates
can cause the system to panic, thus affecting overall availability of the MetroCluster.

"

For my opinion, we can take the risk.

Philippe

[thomas_glodde]

hi there,

phil is right, like described, unmirrored aggregates put the whole system at risk. Its not just due to automated crashes, its also due to administrative error since for a planned maintenance, the aggregates have to be offlined manualy, bringing a more complex action plan for your next site maintenance/planned power outage etc..

Usualy we suggest a 2nd netapp system with unmirrored disks for the "not so important" data.

Current concepts might have to be reviewed/rebuild when it comes to large exchange 2010 or sql 2012 installations.

Kind regards,

Thomas