Understanding Server 2012r2 Clustering
-
Hey guys,
So I'm hoping to set up a server 2012r2 cluster server with DAG for exchange.
Just trying to get a grasp on this before I start.
So I know I need to have an iSCSI host shared to the rest of the cluster.
Just trying to clarify or not though if my iSCSI host goes down does my cluster and DAG still function? The iSCSI isnt my single point of failure I assume right?
Thanks
-
OK I'm speaking completely out of turn here, but aren't DAGs suppose to provide redundancy without the need for clusters? That's one of their huge advantages.
All commodity (cheap even) hardware.
So instead of two (or more servers in a cluster, and all the baggage that goes with that) you just have two (or more) DAG servers that do replication.
-
Oh really? Oh that sounds so much better!
-
DAG is instead of a SAN. If you use a SAN, the SAN is your dependency and you have generally defeating the point of clustering. If you put DAG on a SAN, it fools the DAG into thinking it is redundant when really, it shares a single point of failure.
-
Alright ya I'm definitely trying to eliminate the single point of failure.
Alright guess step 1 is done (haha) time to pull up a youtube video on DAG's
Thanks guys.
That was easier than I thought. -
Exchange should always be on local storage (which includes DAG) and never on SAN. Exchange was specifically redesigned with this in mind as part of the way the system operates. Now that each Exchange server couldn't have a SAN just for it, but that is just that many more points of failure.
-
Before you implement a new Exchange environment, have you considered Office 365?
-
100% personal and just doing this to learn.
All gets blown away when the trials end
-
@Sparkum said:
100% personal and just doing this to learn.
All gets blown away when the trials end
OH, ok. Makes more sense then.
-
Microsoft has some great free labs and training on 2012 R2 clustering. This helped me out big time when I was taking my MCSA tests.
-
Their online education has gotten really good.
-
-
Oh I'll check those out thanks!
-
Just remember that this "lab" case, for Exchange DAG, is not using Windows clustering but is its own application level clustering. So this clustering stuff is for a different use case.
-
@scottalanmiller -- Just so I understand... In most cases, Application Level Clustering > Windows Failover Clustering ?
-
@dafyre said:
@scottalanmiller -- Just so I understand... In most cases, Application Level Clustering > Windows Failover Clustering ?
Probably in all cases but there must be one where this isn't true. But conceptually, application level clustering is the only way to get true, completely reliable failover (when done right.) Anything else is an attempt to make up for lacking application clustering. Windows Failover, VMware failover, etc. are all "making do", not ideal.
-
Exchange is one time you should never use a SAN. Nor can you use Vmotion with Exchange. If you are running Exchange on site most of the time you might as well look at separate physical boxes but, then that comes down too why are you looking at exchange onsite vs hosted?
-
@thecreativeone91 said:
Exchange is one time you should never use a SAN. Nor can you use Vmotion with Exchange. If you are running Exchange on site most of the time you might as well look at separate physical boxes but, then that comes down too why are you looking at exchange onsite vs hosted?
Other times include MS SQL Server (or pretty much any database), Active Directory, etc. Anything that has an open data connection.
-
The times that SAN can be used for a reliably consistent failover are actually pretty rare and almost always cases where there was an easy way to have done it without a SAN.
-
@scottalanmiller I would argue that about MSSQL and MySQL. We ran those on the Same box (as part of the same cluster) for a number of years. The only minor issue that would happen is that the SIS that the Campus used would throw an error message and wouldn't automatically reconnect. The error message I can understand. But not automatically reconnecting? That is an application issue and not a problem with Failover.
Our MySQL applications never had this problem.
We were probably just lucky, but we never lost any data in MSSQL Server due to a failover event.
