Understanding Server 2012r2 Clustering
-
@scottalanmiller said:
@Dashrender said:
In some cases it comes from places like CDW and Zones who claim they have exactly that, engineering teams who's job it is to help you design the proper solution for your problem.
Everyone claims that. But if they are paid through sales, they are sales people. End of story. It's easy to tell the difference, how do you pay them?
I completely agree with everything you said. The problem is that CDW claims they are doing this for your benefit. SMBs who don't teams of IT to DO IT and haven't been exposed to the correct methods you are indicating. Furthermore, SMB management look at the idea of spending $3000 for what in there mind is "just a recommendation" is generally ludicrous. To them it seems like spending bad. Heck I'm willing to bet most would 'feel' even worse if the consultant told them do nothing after having spent the $3000.
-
@Carnival-Boy said:
If Microsoft and VMware were going round saying don't do it, but the salesman thought 'f[moderated] it, I'm going to recommend it anyway' then I think that would be unethical and I don't believe that any of the people I deal with would have that attitude.
Here is what I don't understand, though. Why do you feel that Microsoft, VMware or the salespeople have any stake in this? None of them do. This is a business decision where internal IT has to weigh risks, needs, cost, etc. It is not the business of any of these entities except for internal IT to care or get involved in a statement of this type. VMware and Microsoft are vendors. They produce tools. They support those tools. But it is up to IT to implement and use those tools well and in the right way for their business.
Chevy doesn't make recommendations about how to drive, what speed to go or what kind of grocery to haul in the trunk. They only make sure that the car itself works. Microsoft does its best to make sure that Exchange works well and in as many cases as possible. Just like Chevy tries to make their cars safe even when you don't wear a seatbelt and drive fast and swerve a lot. They don't recommend that you do those things, but they build the tools that allow you to do it and they "support" you when you do. Supporting it doesn't suggest recommending it. Very different things.
You may feel that sales people won't recommend these things knowing how bad that advice is. But we know that from watching sales people in real life both from VARs and vendors and all over SW (even knowing that they will be pointed out as being reckless and unethical because they've been told why they are putting people at risk) do do it anyway. Not that all will, but it appears that nearly all will in this particular case. Remember, the alternative is normally finding a different line of work here! And it isn't like their customers don't set them up for the question. It's not the sales person's fault in any way that the situation arises.
But, by and large. sales people have no idea that this is risky or reckless. It is not their job to spend their own money to undermine their own companies and jobs. This is something that requires a lot of skill, training, research and understanding. Can sales people do that? Sure. Would they? Why?
-
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.
