The Inverted Pyramid of Doom Challenge
-
@hutchingsp had a good success story that I'm not sure I agree with, mostly because I'm unsure of the details. But he did an HDS HUS 110 based IPOD that was a pretty well planned out implementation. I'd like to see him present.
-
@Breffni-Potter said:
Is there a prize if someone does nail it?
If so I think I won it in a PM to Scott, I wouldn't care to repeat it though lol
-
Not sure I'd go so far as to call it a "presentation" but we went with HDS for servers and storage as Scott mentioned.
My reasoning is that we're used to shared storage, and done correctly it's a godsend vs. the terrible burden that many people make it out to be.
We're a VMware shop and we have about 75 VM's (and increasing) and about 20TB of data (and increasing).
I looked at a lot of options.
Local storage is, to me, not an option at this scale, and I say that simply because with a single 10TB (and growing) file server on a single box you're going to have a bad day if that box fails, and it makes updates such as firmware and ESXi updates on the box something which have to be planned for.
Replicated local storage is something that I considered as we have experience of HP StoreVirtual, albeit the physical version vs. the virtual appliance.
In the end I ruled it out because it introduces more complexity than I wanted, and once you're into three hosts and 35-40TB usable and you want decent IOPS you end up buying an insane amount of RAW capacity.
I did a lot of research and came to the conclusion that for us, I needed to put to one side every "geek" instinct that I had and look at what we needed - which was dumb, deathly reliable block storage.
I'd seen HDS mentioned a fair bit on Spiceworks so spoke to John773 (@John-Nicholson) about them and got a ton of useful advice and found HDS the most helpful, easiest to deal with, and least slimy of all the vendors I'd been speaking to.
We settled on a HUS110 with a couple of tiers of disks combined into a single dynamic pool, so it just presents as 36TB (or so) of usable storage which we carve into LUNs and the hot/cold data automatically tiers between the fast and slow disk.
Connectivity is direct attached FC so there are no switches, the hosts just connect directly into the controllers so it's really being used as a high end DAS array rather than a true SAN (though at that point I think most people would use the term "SAN" even if semantically it is incorrect).
The HUS is 99.999% uptime rated - the environment it's in is not, so the HUS is not the thing I should be worrying about in terms of reliability.
There endeth the presentation.
-
@hutchingsp Thanks for popping in!
-
@hutchingsp said in The Inverted Pyramid of Doom Challenge:
In the end I ruled it out because it introduces more complexity than I wanted, and once you're into three hosts and 35-40TB usable and you want decent IOPS you end up buying an insane amount of RAW capacity.
We have this now and we use the same capacity with replicated local disks as you would with a SAN with RAID 10. Are you using RAID 6 or something else to get more capacity from the SAN than you can with RLS? We aren't wasting any capacity having the extra redundancy and reliability of the local disks with RAIN.
-
@hutchingsp said in The Inverted Pyramid of Doom Challenge:
In the end I ruled it out because it introduces more complexity than I wanted, and once you're into three hosts and 35-40TB usable and you want decent IOPS you end up buying an insane amount of RAW capacity.
We are getting 66K IOPS from one tier. And then more, but nowhere close, from the spinning tier. Maybe another 2K. It's not insane IOPS, but it is good.
-
@hutchingsp said in The Inverted Pyramid of Doom Challenge:
In the end I ruled it out because it introduces more complexity than I wanted...
I'm confused here. How does RLS introduce more complexity? Our RLS system is so simple I couldn't possible install any enterprise SAN on the market as easily. It takes literally no knowledge or setup at all. We are using Scale's RLS hyperconverged system and I literally cannot fathom it being easier today. Just making a LUN would be more complex than using RLS alone. Just needing to know that you need to make a LUN is more complex. With the RLS that we have, you just "use it". If you want more power, you can choose to manage your performance tiering manually, but there is no need to if you don't want to as it does it automatically for you out of the box.
-
@hutchingsp said in The Inverted Pyramid of Doom Challenge:
Local storage is, to me, not an option at this scale, and I say that simply because with a single 10TB (and growing) file server on a single box you're going to have a bad day if that box fails,
No issues there. A 10TB fileserver failing over with local storage is automatic recovery in about one second. It's effectively instant. No different than failing over any other workload type.
-
@hutchingsp said in The Inverted Pyramid of Doom Challenge:
and it makes updates such as firmware and ESXi updates on the box something which have to be planned for.
No issues there either. Our firmware updates are painless and transparent. We still don't do it during the middle of the day for obvious reasons, unnecessary risk is unnecessary risk. But if we did, no one would notice.
-
@hutchingsp sorry that it was so long for me to address the post. When you first posted it seemed reasonable and we did not have any environment of our own that exactly addressed the scale and needs that you have. But for the past seven months, we've been running on a Scale cluster, first a 2100 and now a 2100/2150 hybrid and that addresses every reason that I feel that you were avoiding RLS and addresses them really well.
The concern that I would have with your design is not reliability, the HUS SANs are very reliable. But they are far from free and far from easy to use. That cost is not cheap. You are in great shape that you can do direct connections (DAS) rather than SAN for better reliability and nominally better performance with much lower cost, but at three hosts plus the SAN, I can only imagine that you had to spend a lot more for that complex and limited setup than you would have with RLS that would not have the issues that you feel that it would.
Of course to really know we'd have to compare real world numbers. And compare soft benefits. How well suited is the HUS plus three node design to scaling up? If you add one more node, do you need switches? Is it two more nodes? With the RLS design, in our situation at least, we can add many additional nodes and scale up transparently gaining capacity and IOPS performance and throughput.
I don't have enough details to compare the final decision that you made compared to some other solutions that are out there. But in the real world, the reasons that you listed as to why you felt RLS was not an option for you are demonstrably not concerns in our environment. It's not a theoretical case, but one that we run every day.
-
@hutchingsp said in The Inverted Pyramid of Doom Challenge:
The HUS is 99.999% uptime rated - the environment it's in is not, so the HUS is not the thing I should be worrying about in terms of reliability.
We get that from normal servers. If the HUS isn't saving costs, nor improving reliability, what is the benefit? I'm shocked that the HUS is only five nines. Not that that is the deciding factor, but with all of your concerns about firmware, failing of 10TB workloads and such... why did that not rule out the HUS? It seems like either the HUS isn't "up" enough to justify the cost and/or your other downtimes are so great that it doesn't matter anywhere. I'm just curious as to the cost benefit of the HUS over local storage given that your HUS isn't getting a significant improvement in uptime and the downtime that it does get is hidden in the "background noise" or your environment's outages?
-
In the scenario above, using the SAN here is much like a lab scenario. You don't care about the reliability, it's "reliable enough" and it is recognized that reliability is not the concern. So that is much like a lab environment. What I am unclear about, though is without that reliability goal, what goal did the SAN address? It seems like it is both slower and much more expensive than local storage would be. So cost and performance don't seem like they could be the drivers. And while reliability was listed as not a key factor, it was mentioned in the list as a key factor, which seems to go against the final conclusion.
-
Actually had one come up today where a company had thirteen hosts and was using a SAN. Of course, the problem with this isn't that the design is wrong but that it totally fits the guidelines of when you should use a SAN. So in no way does it go against the stated guidance on SAN and IPOD choices. It's an enterprise SAN with more than thirteen attached nodes (and more being added) so it is well within the range of scale where we expect an IPOD/SAN combo to be totally logical and valid.
https://community.spiceworks.com/topic/1741842-migrating-boot-from-san-hosts
The real question is "is this actually an SMB that just has huge needs, or is it a larger business?" But in either case, it's a good example of where a SAN actually makes total sense (but isn't a requirement, other viable options at that size, too), but does so meeting the established, traditional guidelines (more than a dozen nodes on the same shared storage pool) so is not an exception or revelation in any way.
-
@scottalanmiller said in The Inverted Pyramid of Doom Challenge:
We have this now and we use the same capacity with replicated local disks as you would with a SAN with RAID 10. Are you using RAID 6 or something else to get more capacity from the SAN than you can with RLS? We aren't wasting any capacity having the extra redundancy and reliability of the local disks with RAIN.
With HDT pools you could have Tier 0 be RAID 5 SSD, RAID 10 for 10K's in the middle Tier, and RAID 6 for NL-SAS with sub-lun block tiering across all of that. Replicated local you generally can't do this (or you can't dynamically expand individual tiers). Now as 10K drives make less sense (hell magnetic drives make less sense) the cost benefits of a fancy tiering system might make less sense. Then again I see HDS doing tiering now between their custom FMD's regular SSD's, and NL's in G series deployments so there's still value in having a big ass array that can do HSM.
-
@scottalanmiller His previous RAIN system (HP Store Virtual) requires local RAID. So your stuck with nested RAID 5's (Awful IO performance) or nested RAID 10 (awful capacity capabilities, but great residency). Considering the HDS has 5 nines already though kinda moot.
-
@scottalanmiller said in The Inverted Pyramid of Doom Challenge:
@hutchingsp said in The Inverted Pyramid of Doom Challenge:
In the end I ruled it out because it introduces more complexity than I wanted...
I'm confused here. How does RLS introduce more complexity? Our RLS system is so simple I couldn't possible install any enterprise SAN on the market as easily. It takes literally no knowledge or setup at all. We are using Scale's RLS hyperconverged system and I literally cannot fathom it being easier today. Just making a LUN would be more complex than using RLS alone. Just needing to know that you need to make a LUN is more complex. With the RLS that we have, you just "use it". If you want more power, you can choose to manage your performance tiering manually, but there is no need to if you don't want to as it does it automatically for you out of the box.
To be fair in comparison he could have deployed Hitachi Unified Compute (Their CI stack) and gotten the same experience (basically someone builds out the solution for you and gives you pretty automated tools to abstract the complexity away, as well as have API drive endpoints for provisioning against etc). This isn't an argument for an architecture (and I like HCI, I REALLY do) this is an argument about build vs. buy your making. HCI with VSA's can be VERY damn complicated. HCI can be very simple (especially when it's built by someone else). CI can do this too.
-
@scottalanmiller said in The Inverted Pyramid of Doom Challenge:
@hutchingsp sorry that it was so long for me to address the post. When you first posted it seemed reasonable and we did not have any environment of our own that exactly addressed the scale and needs that you have. But for the past seven months, we've been running on a Scale cluster, first a 2100 and now a 2100/2150 hybrid and that addresses every reason that I feel that you were avoiding RLS and addresses them really well.
The other issue with Scale (and this is no offense to them) or anyone in the roll your own hypervisor game right now is there are a number of verticle applications that the business can not avoid, that REQUIRE specific hypervisors, or storage be certified. To get this certification you have to spend months working with their support staff to validate capabilities (performance, availability, predictability being one that can strike a lot of hybrid or HCI players out) as well as commit to cross engineering support with them. EPIC EMR (and the underlying Cachè database), application from industrial control systems from Honeywell and all kinds of others.
This is something that takes time, it takes customers asking for it, it takes money, and it takes market clout. I remember when even basic Sage based applications refused to support virtualization at all (then Hyper-V). It takes time for market adoption and even in HCI there are still some barriers (SAP is still dragging their feat on HANA certifications for HCI). At the end of the day customer choice is great, and if you can be a trailblazer and risk support to help push vendors to be more opened minded (That's great) but not everyone can do this.
There are other advantages to his design over a HCI design. If he has incredibly data heavy growth in his environment he doesn't have to add hosts. As licensing for Microsoft applications stacks (datacenter, SQL etc) are tied to CPU Core's here in the near future adding hosts to add storage can be come rather expensive if you don't account for it properly. Now you could mount external storage to the cluster to put the growing VM's on, but I'm not sure if Scale Supports that? He also within the HUS can either grow existing pools, add new pools (maybe a dedicated cold Tier 3) or PIN LUN's to a given tier (Maybe put a database always in flash). There's a lot of control here of storage costs and performance (if you have patience to manage it. Sadly no VVOLs support coming to the old HUS's.
-
At the time of going the HUS route the HCI solutions were limited.
We looked at a couple of the big names, pricing was insane though I'd happily have a rack of either if money wasn't a factor in any of the lifecycle beyond just the initial purchase price.
That left a whole bunch of "roll your own" solutions, Scale at the time didn't seem to scale plus we're comfortable on ESXi, could we change? Yes of course, but then you're migrating to a hypervisor with a more limited support ecosystem however rock solid that hypervisor may be so I'm not sure what we actually gain there?
Starwind and other solutions are a bit too roll-your-own as was, I felt, StoreVirtual, in that if it all went wrong you're possibly stuck between the hardware vendor, the switch vendor, the OS vendor, the HCI stack vendor and so on which is great when you've saved a few $$$ but not so good when your business is down and nobody wants to own the issue.
Scale, Simplivity, Nutanix etc. are (or were when we purchased, maybe it's changed) all designed on the principle you scale compute and storage linearly and we don't which means that if/when I needed to add another TB of capacity I'd either be bolting on NAS and stuff to a HCI solution, or I'd be buying additional nodes giving me compute and storage and licensing costs when really all I needed was a disk tray and a couple of drives which I can do with the HDS.
In short it's simple and it's reliable and from the numbers at the time I know we didn't pay massively more than anything I could have rolled ourselves and ended up with a lot more complexity for very little gain.
That said, when the replacement time comes I suspect the HCI and VSA options will have matured a lot from where they were 2 years ago so there will be some more interesting options on the table - but I see that as being more in terms of things like stretching clusters than chasing 9's from a pile of kit all sitting in the same rack.
-
@scottalanmiller said in The Inverted Pyramid of Doom Challenge:
to hit checkboxes while resting on fragile, single point of failure storage (SAN, NAS, DAS, etc.)
As I've heard many times, even once from one of my own employees who argued with me about this "but how often do SANs/NASes/etc fail? Basically never, so it's not a single point of failure, and it makes it easier to move from one VM host to another."
I'm still baffled by this, and actually have seen them fail and take all customer data with them. What in God's name makes people seem to believe that you're more likely to have a motherboard or power supply fail in a server (since they don't use the disks) than actual harddisks. For well over a year we've had a no hire policy during interview if someone describes inverted pyramid as a proper way to set something up,. Yes, they can learn to do otherwise, but:
- I don't want to teach them nor do I want my employees to waste their time teaching them something they should have figured out themselves.
- If they just thought about it logically for even a second, they'd see how it's probably a stupid idea to put all your eggs in one basket.
I have no regrets. At no point in time was "needing the space" a good enough reason, unless the SAN was for one VM host or something like that possibly, but these days that kind of thing is rare anyway, at least in the environments for our customers, and our own.
-
@John-Nicholson said in The Inverted Pyramid of Doom Challenge:
@scottalanmiller said in The Inverted Pyramid of Doom Challenge:
We have this now and we use the same capacity with replicated local disks as you would with a SAN with RAID 10. Are you using RAID 6 or something else to get more capacity from the SAN than you can with RLS? We aren't wasting any capacity having the extra redundancy and reliability of the local disks with RAIN.
With HDT pools you could have Tier 0 be RAID 5 SSD, RAID 10 for 10K's in the middle Tier, and RAID 6 for NL-SAS with sub-lun block tiering across all of that. Replicated local you generally can't do this (or you can't dynamically expand individual tiers). Now as 10K drives make less sense (hell magnetic drives make less sense) the cost benefits of a fancy tiering system might make less sense. Then again I see HDS doing tiering now between their custom FMD's regular SSD's, and NL's in G series deployments so there's still value in having a big ass array that can do HSM.
We have only two tiers, but they can be dynamically expanded. Any given node can be any mix of all slow tier, all fast tier or a blend. There is a standard just because it's pre-balanced for typical use, but nothing ties it to that.
