ZFS Based Storage for Medium VMWare Workload
-
@donaldlandru said:
@dafyre said:
In your Dev environment, you have 3 servers... with 288GB of Ram, 64GB of RAM, and 16 GB of RAM... Assume RAM compatibility... What happens if you balance out those three servers and get them at least close to having the same amount of RAM?
Does that help you at all? If that is a good idea, then why not look at converting them to XenServer and switching to Local Storage? You could then replicate the VMs to each of the three hosts, or you could set up HA-Lizard.
The two smaller servers pre-date my time with the company and were likely back of truck specials. Both of these are slated to be replaced next year with a single server with similar specs to the big server. The smallest one is already maxed out and the other one doesn't make sense to upgrade just to retire.
I also don't need HA on these (I don't have HA today on these) so I think this is an opportunity to move to different platform.
Something to consider here, is Scale. It would be a forklift operation, more or less, but would let you consolidate everything, get HA thrown in and all for one price. Would not be cheap, but you could move workloads over as needed. Start with three nodes and replace the Dev environment up front and start moving over the Ops environment as you can.
Easily doesn't fit, but it makes this model really easy and gives you all of the features that you want with essentially zero effort.
-
@dafyre said:
If I am not mistaken with planned outages, you can actually Migrate VMs from one XenServer host to another (this is also true for Hyper-V, IIRC) without having shared storage... So for Maintenance, you can live migrate from one XenServer host to another (it would copy the storage too)... Whether or not that is feasible depends on the size of your VMs and speed of your network... among other things.
Yes, because XS includes "Storage vMotion" functionality for free.
-
@donaldlandru said:
- Chassis failure (I am sure it can happen, but the only part in the chassis is the backplane and some power routing)
- Software bug -- most likely failure to occur
- Human error (oops I just unplugged the storage chassis)
Chassis failure is uncommon, but common enough that it gets discussed on SW regularly as people have their units die. Only see that every so many months, but it does happen and is not to be ignored. This one issue puts this into a "blade" risk scenario and we've seen just this month, people lose entire blade enclosures because of backplane or control issues. It's a small risk in the relative sense but a very real one.
Software bugs are huge on the MSA and any device in this class. They are magnified by the dual controllers so become extremely risky and cause outages at a pace that seem to dramatically outscale standard servers.
Human error is big and I've seen some pretty dramatic ones. It's more likely on an MSA than on local storage.
-
@scottalanmiller said:
Human error is big and I've seen some pretty dramatic ones. It's more likely on an MSA than on local storage.
Your example in the Scale panel at SWorld was pretty epic. The woman who delete the wrong thing and had sudden health problems on top of the company being completely down.
-
@donaldlandru said:
All in all I think the operations is pretty well protected, minus the three risks listed above. It is two nodes that can absorb either node failing, it is on redundant 10gig top of rack switches and redundant 1gig switches. Also, backups are done and tested as well with Veeam. Am I missing something here?
Yes, you are missing that it is not protected at all. Even if the server node layer was so well protected that it has no risk at all (which can never actually happen) the MSA represents more risk than a normal server. In no way is this "protected" let alone "well protected." You are running your operations on an expensive, yet "less than standard" level of reliability. The risks that you mention add up to "more than the risks of a normal server."
So calling this "well protected" is misleading. It's "unnecessarily risky" but "above the needs of the business." So you are at risk without reason, overly complex and have spent too much money for what you got from it, but the only thing that we have learned for sure from it are these two things:
- The company will happily spend far in excess of its needs - which is good as long as there is someone making sure that they only buy what they need, not what they can.
- The company has no need for even "standard reliability" let alone anything higher. So any spending on something more than straight servers with zero failover would be wasteful.
-
@scottalanmiller said:
@donaldlandru said:
Real life I am not sure if it works, on paper it does. It is a false sense of security but the MSA does have active/active controllers built in (10GB iSCSI), redundant power supplies, and of course the disks are in a RAID. The risks that are not mitigated by the single chassis are:
Not active/active. It has codependent controllers that fail together. It's the opposite of what people expect when they say "redundant". It's the two straw houses next door in a fire, scenario. Having two houses is redundant, but if they are both made of straw and there is a fire, the redundant house will provide zero protection while very likely making a fire that much more likely to happen or to spread. Active/Active controllers from HP start in the 3PAR line, not the MSAs.
All that other redundant stuff is a red herring. EVERY enterprise server has all of that redundancy but without the cripplingly dangerous dual controllers. Making any normal server MORE reliable than the MSA, not less. If anyone talks to you about the "redundant" parts in an MSA you are getting a sales pitch from someone trying very hard to trick you unless they point out that every server has those things so this is "just another server".
I disagree with this, the controllers fail independently of each other. We have experienced a controller failure in the MSA and while it was degraded performance wise, zero downtime was experienced. HP sent a technician out with replacement controller, hot-swapped and checked configuration 10 minute process again with zero downtime.
Now, if we are worried about the neighbors house on fire, sure we have that issue as everything (operations) is housed in a single data center. We accept the risk that our operations is highly available (might incur downtime during failover) but is not fault-tolerant (services are not running in an active/active format).
Software bugs on the other hand have bit us in the past we makes us very cautious when we do upgrades, scheduled maintenance windows, extra backups on hand, etc.
-
The biggest challenge with local storage is getting your extra capacity where you need it. This is something that matters in development, I can't have an overworked compute node with a boatload of extra storage, and an underworked one with no storage. This is what shared storage (at the dev level) solves for us. And keep in mind, those storage location needs can change at anytime.
-
@scottalanmiller said:
- The company has no need for even "standard reliability" let alone anything higher.
This is the second time in this thread you've said something to this effect. Why do you believe this? Simply because of the choices they made before?
That is a flawed way to look at the companies need for "standard reliability" or even HA. @donaldlandru provided the desired end results in his first and followup posts. Just because the company implemented something that didn't provide those stated goals before, doesn't mean the goals themselves are wrong, it means they were probably sold a bill of goods that couldn't provide those goals and got lucky throughout it's current use.
-
@donaldlandru said:
I disagree with this, the controllers fail independently of each other. We have experienced a controller failure in the MSA and while it was degraded performance wise, zero downtime was experienced. HP sent a technician out with replacement controller, hot-swapped and checked configuration 10 minute process again with zero downtime.
No they can fail independently of one another. That is not the same thing. Under certain types of hardware failure they are redundant, under the most common forms of firmware failure, they are not. This makes them work great in demos as you can reliably yank out a controller and it keeps working but search SW and you'll see the MSAs dying with both controllers going out at once with one killing the other as it goes. They are tightly coupled, you aren't in the range of independent controllers here.
They also die far more frequently than standard RAID controllers. A normal RAID controller is expected to have a multi-decade average life. One of the most reliable components in your servers (I've see this over 80,000 servers over a decade of monitoring.) Your failure rate from that one controller dying in your environment puts the failure rate at hundreds of times higher than I've measured in servers. It's purely anecdotal on your end, but something to consider. How many server controllers have died in the same time period even though you have many more servers?
-
@donaldlandru said:
The biggest challenge with local storage is getting your extra capacity where you need it. This is something that matters in development, I can't have an overworked compute node with a boatload of extra storage, and an underworked one with no storage. This is what shared storage (at the dev level) solves for us. And keep in mind, those storage location needs can change at anytime.
This is why you would build your new Dev servers to be clones... So you build them both with 384GB of RAM (how in the world did you get 288? lol.) and 4 x 6TB drives in RAID 10 (gives you 12TB usable in each server)... Then Setup XenServer + HA-Lizard (or at least DRBD) and it effectively turns that storage into shared storage.
-
@Dashrender said:
@scottalanmiller said:
- The company has no need for even "standard reliability" let alone anything higher.
This is the second time in this thread you've said something to this effect. Why do you believe this? Simply because of the choices they made before?
Because they are happy with the current reliability. If what they have today is "good enough" then better is, by logical extension, not just "good enough" but better. If you need six eggs to feed your family "enough", then seven eggs is "better".
-
Because of the volatility of your dev environment, I wonder if using a SAM-SD for central storage would be best. What happens if the entire storage array is down? Can you live for a day or two without it on the dev environment? What are you planning for backups on it? What is your RTO and RPO?
Your operations systems - I like the two node sync'ed approach, if you even really need that, but you already have the two servers.
-
@scottalanmiller said:
@donaldlandru said:
I disagree with this, the controllers fail independently of each other. We have experienced a controller failure in the MSA and while it was degraded performance wise, zero downtime was experienced. HP sent a technician out with replacement controller, hot-swapped and checked configuration 10 minute process again with zero downtime.
No they can fail independently of one another. That is not the same thing. Under certain types of hardware failure they are redundant, under the most common forms of firmware failure, they are not. This makes them work great in demos as you can reliably yank out a controller and it keeps working but search SW and you'll see the MSAs dying with both controllers going out at once with one killing the other as it goes. They are tightly coupled, you aren't in the range of independent controllers here.
They also die far more frequently than standard RAID controllers. A normal RAID controller is expected to have a multi-decade average life. One of the most reliable components in your servers (I've see this over 80,000 servers over a decade of monitoring.) Your failure rate from that one controller dying in your environment puts the failure rate at hundreds of times higher than I've measured in servers. It's purely anecdotal on your end, but something to consider. How many server controllers have died in the same time period even though you have many more servers?
Yes they can and have failed independently of each other, outside of a demo environment (as I just outlined above). Firmware update risks are everywhere, shared and local storage both so one way or the other doesn't mitigate that risk.
Out of the hardware in our datacenter I have had the one MSA controller fail, a P420 in the HP DL360p G8 and a perc in the dell 2950, all inside the four years I have been here. To me this shows no better level of reliability than the other. Both of the controller failures in the blades caused downtime to the organization, the failure in the MSA did not.
-
@donaldlandru said:
Yes they can and have failed independently of each other, outside of a demo environment (as I just outlined above). Firmware update risks are everywhere, shared and local storage both so one way or the other doesn't mitigate that risk.
Active/Active doesn't have the firmware risk. That's a HUGE deal. MSAs fail, both controllers together, all of the time. At a rate we've observed far higher than servers fail on their own (equivalent servers.) It's just how it is. They can work, but they fail together too often to match the reliability of a normal server.
-
@donaldlandru said:
Out of the hardware in our datacenter I have had the one MSA controller fail, a P420 in the HP DL360p G8 and a perc in the dell 2950, all inside the four years I have been here. To me this shows no better level of reliability than the other. Both of the controller failures in the blades caused downtime to the organization, the failure in the MSA did not.
Those are crazy high failure rates for all of those. PERCs I have not measured in large quantity but SmartArrays I have, by the thousands, and the failure rates are miniscule, a fraction of the failure rates of memory sticks, for example.
-
@Dashrender said:
Because of the volatility of your dev environment, I wonder if using a SAM-SD for central storage would be best. What happens if the entire storage array is down? Can you live for a day or two without it on the dev environment? What are you planning for backups on it? What is your RTO and RPO?
His proposed ZFS-based storage option is a SAM-SD, just in case anyone missed that.
-
@Dashrender said:
Because of the volatility of your dev environment, I wonder if using a SAM-SD for central storage would be best. What happens if the entire storage array is down? Can you live for a day or two without it on the dev environment? What are you planning for backups on it? What is your RTO and RPO?
Your operations systems - I like the two node sync'ed approach, if you even really need that, but you already have the two servers.
That is pretty much where this all started, do I need to fork out the money to HP or is the other way good enough.
In operations the RTO/RPO is 24 hours. We carry our HP care pack on the MSA. Everything is backed up by Veeam several hours throughout the day and replicated offsite. We have physical access to the offsite location in case of datacenter failure for faster recovery.
For the development environments up to six months ago there was no backup of the development environments as the thought was this could be rebuilt from scratch. This was until I outlined the effort it would take to bring everything back. -- roughly 6 months.
Now the RPO is one week with a RTO of 72 hours.
-
@scottalanmiller said:
@Dashrender said:
Because of the volatility of your dev environment, I wonder if using a SAM-SD for central storage would be best. What happens if the entire storage array is down? Can you live for a day or two without it on the dev environment? What are you planning for backups on it? What is your RTO and RPO?
His proposed ZFS-based storage option is a SAM-SD, just in case anyone missed that.
You're right it is, but for the dev environment it might be all that he needs with a good backup solution. He's currently hamstrung by his old servers - two of which are slated to be replaced in the next year or so.
Perhaps he should do nothing until it's time to replace those boxes.
-
@Dashrender said:
@scottalanmiller said:
@Dashrender said:
Because of the volatility of your dev environment, I wonder if using a SAM-SD for central storage would be best. What happens if the entire storage array is down? Can you live for a day or two without it on the dev environment? What are you planning for backups on it? What is your RTO and RPO?
His proposed ZFS-based storage option is a SAM-SD, just in case anyone missed that.
You're right it is, but for the dev environment it might be all that he needs with a good backup solution. He's currently hamstrung by his old servers - two of which are slated to be replaced in the next year or so.
Perhaps he should do nothing until it's time to replace those boxes.
I can't do nothing, I do not have enough storage to host a new client that starts soon. I have to do something there. I am not opposed to overall architecture changes in a refresh cycle, but in the meantime -- I have a budget and need disk.
-
That all supports that HA is total overkill. HA is for when ten minutes is too long. Not for when "we can be down for an hour or two in a disaster."
