Understanding Server 2012r2 Clustering
-
Here's a question, Does Microsoft suggest SAN and DAGs or VMWare suggest using FT with Exchange? If they do, that's a problem and weights heavily on @Carnival-Boy's side. If they don't, then @scottalanmiller's point stands.
-
@Dashrender said:
Here's a question, Does Microsoft suggest SAN and DAGs or VMWare suggest using FT with Exchange? If they do, that's a problem and weights heavily on @Carnival-Boy's side. If they don't, then @scottalanmiller's point stands.
FT with Exchange is okay, the question is around HA with Exchange. Similar, but different technologies with different issues. FT is okay, HA is not. FT doesn't crash, HA does (in the VMware world.)
-
@scottalanmiller said:
@Dashrender said:
Here's a question, Does Microsoft suggest SAN and DAGs or VMWare suggest using FT with Exchange? If they do, that's a problem and weights heavily on @Carnival-Boy's side. If they don't, then @scottalanmiller's point stands.
FT with Exchange is okay, the question is around HA with Exchange. Similar, but different technologies with different issues. FT is okay, HA is not. FT doesn't crash, HA does (in the VMware world.)
My mistake.. so apply my question to HA instead.
-
@Dashrender said:
Here's a question, Does Microsoft suggest SAN and DAGs or VMWare suggest using FT with Exchange? If they do, that's a problem and weights heavily on @Carnival-Boy's side. If they don't, then @scottalanmiller's point stands.
Even if they recommend a SAN, one of them is a SAN vendor and one of them is partnered with SAN vendors. In neither case do they care if you use a SAN because it isn't their problem. That's part of the misconception. Put yourself in their shoes, when you tell people to use a SAN you remove your own responsibility. By putting things on a SAN, when the SAN fails you get to blame the SAN vendor. You shift blame off of you while doing less work. It's a big win for them. No reason for them to go out of their way to take on responsibility that they don't need to.
It is IT's job to protect the business. It is Microsoft's job to make sure Exchange is not to blame. It is not Microsoft's responsibility to make sure that IT understands the issues and implements them correctly for their business' needs.
-
It is when Microsoft is making white papers for good deployment strategies.
-
The VMWare Best Practices document is a great example of how this can work.
http://www.vmware.com/files/pdf/Exchange_2013_on_VMware_Best_Practices_Guide.pdf
Keep in mind that VMware is not here to help you do the right thing, they are here to sell VMware licensing and possibly EMC storage arrays. But let's look closely and what they put...
They carefully word things to make it sound like they are recommending something, but they do not. They use "if" and "when" and let the reader fill in the gaps. FreeNAS does the same thing to "lead" customers without actually telling them something untrue or, in this case, without actually making a recommendation. VMware points out that it is a best practice to buy licensing for features that you really would not want and that are dangerous, could cost you your job (seen in) and put the company at risk and that only, at best, make sense in enormous enterprises (like auto load balancing.)
They also stated that VMware does not support local storage by excluding it from the list, which is simply not true. Again, they are "leading" you to make conclusions that benefit them.
In the end, they never recommend anything. They provide a lot of leading, and some guidance, but never recommend a SAN, NAS, DAS or otherwise. They never address, that I could see, if your nodes should be on the "same" shared storage or different. So even the most important piece is missing.
So I would say that VMware does not provide any guidance here but does have some marketing material to attempt to sell more expensive VMware licenses and says things around storage to lead in that direction, but nothing more.
-
@Dashrender said:
It is when Microsoft is making white papers for good deployment strategies.
Whoa, what brings you to that conclusion? A white paper, as people point out all the time, is nothing but a pamphlet form of advertisement. White papers are marketing, nothing more. Microsoft has things to sell, they are no different from any other vendor. They want you to do sensible things, but they want you to spend money with them first and their partners second more than they want you to be sensible.
There is nothing, anywhere, that would suggest that MS white papers are some exclusion from everything else in every industry. It's just a sales tool like any other.
-
If there are no real recommendations, then how can they honestly call it Best Practices. Doesn't one have to be a lie? Either the title or the lack of real information?
-
@Dashrender said:
If there are no real recommendations, then how can they honestly call it Best Practices. Doesn't one have to be a lie? Either the title or the lack of real information?
Best Practices should come from an industry, not a vendor. Who determines the best practice in building a bridge? Certainly civil engineers and experts, not concrete salesmen?
-
@Dashrender said:
If there are no real recommendations, then how can they honestly call it Best Practices. Doesn't one have to be a lie? Either the title or the lack of real information?
Sure, or it is the best practices as they see it. Assuming that they label it as such. But most vendors lie. When something is put out as marketing, it is assumed to be a lie, or should be. It's understood that stretching the truth is part of marketing. Outright dishonesty is normally not allowed, but in areas like best practices, the whole concept is a grey area and those things do not apply.
Not that Microsoft is going to get reckless, but they aren't necessarily writing papers that are completely in YOUR interest either. They need to sell software and their marketing is not going to eschew that.
-
Here is a quote from the Microsoft Exchange Best Practices:
For an Exchange 2013 virtual machine, do not configure the virtual machine to save state. We recommend that you configure the virtual machine to use a shut down because it minimizes the chance that the virtual machine can be corrupted. When a shut down happens, all jobs that are running can finish, and there will be no synchronization issues when the virtual machine restarts (for example, a Mailbox role server within a DAG replicating to another DAG member).
That save state statement is the big one. Things like HA use the save state as part of the failover mechanism. The thing that @Carnival-Boy was wondering about, why the SAN backed HA rather than a DAG group was an issue, is because this is when corruption can occur. It is the most risky time. Microsoft acknowledges this in their most recent, official best practices guide to Exchange.
While they state it here only at a technology level, it tells us what we need to know. Microsoft isn't going to make a point of pointing out vendors that do this automatically. But they've given the IT pro all that they need to know to determine which solutions are best and which are more risky.
-
So because IT changes so rapidly that any testing isn't really useful, not to mention that, as you've said, who would pay for it then simply release the information for free... Where are newbies and SMB IT personal suppose to glean all this knowledge to make the correctly informed decisions?
-
@Dashrender said:
So because IT changes so rapidly that any testing isn't really useful, not to mention that, as you've said, who would pay for it then simply release the information for free... Where are newbies and SMB IT personal suppose to glean all this knowledge to make the correctly informed decisions?
Now that's a hard but really important question. Something I have been struggling with. The information is out there, books, websites, communities, mentoring. How do other fields to it? Mostly through university. Which is cheating a bit. Not that it is bad, it's just the easy answer. Lock the knowledge up in the university and expect everyone to go there. That's great, but it fails for IT and software engineering. So we lack the easy answer that, say, civil engineering has. It's not the only path for CivE either, but it is the easy, obvious and common one.
IT can't use universities, at least not for now. But the information is really not that hard to come by. But it takes effort. Books have long been the answer, outside of the mentoring system, for thousands of years for all fields. Find experts either in person or in writing and learn from them. Books are important because they have the opportunity to explain the theory, the background, etc. The "Google the answer" approach is what is killing us. Too many IT pros are looking for the "answer" and get hiring because they can do that but we forget that what is important is understanding the solution set, which is much harder and cannot be searched easily.
How did I learn about RAID, for example? Books, lots of them, back in the 1990s. I read books on storage, on systems, etc. The information was there, in print, on paper. Except for some new information that came about in ~2007, everything that I know about RAID was stuff that was expected, common industrial base knowledge in 1998 but seems to have gone away in the years since. But the Microsoft exams required it. The CompTIA exams required it. Any systems book covered it. Anything advanced assumed that you understood it. It was covered from tons of angles.
Today, I can't figure out how people have avoided it. Yet nearly everyone has.
-
IT does not change that rapidly, though. Good training twenty years ago would nearly completely prepare you for IT today. That's faster change than civil engineering has, arches are arches, roads are roads. The Romans had some info that even today we lack. But it doesn't change at a pace that causes real problems. Nearly everything important that I learned was in the 1990s. There is an important element of keeping up to date, but the fundamentals don't change, just the products, prices and some nuances. It is rare that something new comes along that really changes things.
-
@scottalanmiller said:
... it doesn't change at a pace that causes real problems....
Hmmmmmm maybe for some definitions of "real problems"
Also, for fun:
-
It's amazing just how much 1995 was like today. Yeah, it was all old and slow. But from the Windows 95 interface, the Windows NT platform, Linux, UNIX, USB, HTML, PHP, Google (in early phases), Amazon, SSL, Java, JavaScript, Perl, VoIP, PPro (which later became the Intel Core), IE, Opera, Wikis, Ruby, Yahoo, eBay, MSNBC, etc.
-
@scottalanmiller said:
IT does not change that rapidly, though. Good training twenty years ago would nearly completely prepare you for IT today. That's faster change than civil engineering has, arches are arches, roads are roads. The Romans had some info that even today we lack. But it doesn't change at a pace that causes real problems. Nearly everything important that I learned was in the 1990s. There is an important element of keeping up to date, but the fundamentals don't change, just the products, prices and some nuances. It is rare that something new comes along that really changes things.
Like SSDs and how they've turned RAID 5 on it's head from previously conventional wisdom.
-
@Dashrender said:
@scottalanmiller said:
IT does not change that rapidly, though. Good training twenty years ago would nearly completely prepare you for IT today. That's faster change than civil engineering has, arches are arches, roads are roads. The Romans had some info that even today we lack. But it doesn't change at a pace that causes real problems. Nearly everything important that I learned was in the 1990s. There is an important element of keeping up to date, but the fundamentals don't change, just the products, prices and some nuances. It is rare that something new comes along that really changes things.
Like SSDs and how they've turned RAID 5 on it's head from previously conventional wisdom.
That's not a change, though. It's an application of the same knowledge that was known in 1998. The fundamentals are not changed at all. It is condensed, quick rules that have to be updated based on market prices, sizes, supply changes, failure rates, etc. But understanding RAID basics (including URE rates which was the only bit rarely discussed in the 90s) is all that was ever needed. If RAID was known, SSD hasn't changed anything, it's just more of the same foundational data being applied the same way.
The attempt to learn IT by rote, as a set of rules, makes it seem to change rapidly and require constant updating. But learning the foundations provides rules and concepts that are essentially timeless and provide the foundation from which the rote rules are derived.
Back when Microsoft published their big RAID guidance that was such a landmark, they didn't say "use RAID 5", they said "here is why RAID 5 works now, because of these factors" and expected everyone to understand the factors involved. Because of that, the "2009 change" for hard drives was not a change, but a continuation of the previous knowledge, and likewise the move back to RAID 5 on SSDs is, also, a continuation of the same guidance. They are not disruptions, just all applications of the same foundational rules.
-
Aww oK that makes sense.
-
Likewise, triple parity (aka RAID 7 or RAID 5.3) while new in ~2005 with Sun introduced it with ZFS, while a new product, it really did not change anything. The rules that provided information around RAID 5 and how it changed to RAID 6 continued on to RAID 7. The fundamental formulas needed a new entry for RAID 7, but it was all stuff that was projected in the 90s, we just didn't have an implementation yet. And still ten years later we only have the one. Had we talked triple parity in 1995, we could have projected the reliability, capacity and speed impacts accurately, just would have had to waited to see it in action. We have RAID 8 or RAID 5.4 projected in the same way now. It will come someday, we suspected, and will operated almost exactly along a performance and reliability curve that matches others in the R5 family.
