Xenserver and Storage
-
@olivier said in Xenserver and Storage:
Because it allows an abstraction of the hardware, for replacing/patching/rebooting stuff without even lose service (or to avoid to do so a week end for instance)
Right, that's a thing SMBs don't need. People sell them that, but I'd be pretty pissed if I found my techs spending money on that. It is only useful for patching the underlying hypervisors. How long does that take? And you have to have longer outages for patching the individual VMs on top already. So just align the patching time. SMBs don't have many workloads and rarely critical ones. Every SMB hates being an SMB and claims big money losses or high criticality for services, but when it comes down to it, it's all bluster 99.99% of the time.
There are cases where this matters, but good luck actually finding one. It's simple a need that the SMB doesn't have in reality. Patching is a trivial process easily scheduled. There is a reason that even the Wall St. banks don't need to do this for their biggest workloads. It's an almost completely fabricated business need.
-
For any shop that actually needs this functionality, you normally need it higher in the stack, at the application level. So when needed, you already have it and don't need the platform to provide it across the board. So in most of the rare cases where the need does exist, you already have the capability.
-
So I should be an exception then
edit: in the end, your perception doesn't really matter if the "market" think otherwise.
-
@olivier said in Xenserver and Storage:
So I should be an exception then
What business need creates it for you? What service do you run that is so critical that you have no greenzones all week long?
And then isn't properly mitigated through application level high availability?
-
Eg XS patching for critical sec reasons, I don't have the resources to make our apps redundant at their level, so I rely on virt (and live mig) to avoid outage.
-
@olivier said in Xenserver and Storage:
Eg XS patching for critical sec reasons, I don't have the resources to make our apps redundant at their level, so I rely on virt (and live mig) to avoid outage.
Sure, but what service is so critical that you can't reboot? SMBs basically never have any service that needs to stay up. That's the thing. I get why services will go down without an HA solution in place, but what no one ever explains to me is why going down is a problem. How many users are impacted and in what way and for how long?
-
Think priorities. It will impact some users (because the updater in XOA), not dramatic for the business but it's better to avoid that. So the cost to have it is negligible (already using virt). And I don't have the resource to make the service app HA (because live migration is free…)
edit: in the end, if I follow your arguments, virtualization is also useless for SMBs.
-
@olivier said in Xenserver and Storage:
edit: in the end, if I follow your arguments, virtualization is also useless for SMBs.
Nope, not in the least. This would imply a misunderstanding of the purpose of virtualization. Virtualization is free and makes things safer. Everyone benefits from virtualization, every time.
HA is not free, adds its own risks (that are very high) and provides uncommon benefits. Most shops are hurt by HA, not helped by it.
Same logic, totally different results.
-
I'm not speaking about HA right now, I'm speaking about live migration
HA is another beast, I agree it should be used only after thinking benefits/problems.
-
It's simply good business, look at the cost of downtime, look at the cost of HA. Then look at the risks without HA and the risks with HA. Put them together in a normal cost/risk analysis and the result is almost always that HA doesn't deliver something of value enough to overcome its costs. And as it adds a lot of risk (not as much as it mitigates) it is far, very far, from a clear win even in the risk portion.
-
@olivier said in Xenserver and Storage:
I'm not speaking about HA right now, I'm speaking about live migration
They are essentially one and the same. The technology to do one does the other. If you have HA, you can live migrate. If you can live migrate, you can't necessarily do HA. I'm giving you the advantage by lumping them together since the cost of one gives you both.
-
HA is automated and more "dangerous". Live migration is a manual process. That was the context I meant.
-
If I'm willing to do live migration without HA, you get even more options, technically, making live migration easier and no shared storage needed at all.
-
@olivier said in Xenserver and Storage:
HA is automated and more "dangerous". Live migration is a manual process. That was the context I meant.
Makes sense. I've seen live migration beliefs take down big banks because someone thought it was safe and did it without a greenzone and the hypervisors (ESXi) died from trying to do it.
-
If live migrations were free, carried no risks, and took no effort, of course they would be a great benefit. But free and riskless they are not. That's what causes problems.
-
I’ve said it before, but I let the VMs do this. It’s less complex (when automated). Gluster does the replication in the VMs (for the very few that need it). Everything else is either stateless with floating IPs and rp/lb or it’s at the application layer.
-
@stacksofplates said in Xenserver and Storage:
I’ve said it before, but I let the VMs do this. It’s less complex (when automated). Gluster does the replication in the VMs (for the very few that need it). Everything else is either stateless with floating IPs and rp/lb or it’s at the application layer.
You are using Gluster inside of the "HA VMs"? So a file server cluster, for example, are VMs on top of local storage, but with Gluster inside of the VMs, so the VMs can be shut down and then fired up on top of any platform including physical or a different hypervisor, or just left off during work because there are other cluster members available, to remove the need for a live migration?
-
@scottalanmiller said in Xenserver and Storage:
@stacksofplates said in Xenserver and Storage:
I’ve said it before, but I let the VMs do this. It’s less complex (when automated). Gluster does the replication in the VMs (for the very few that need it). Everything else is either stateless with floating IPs and rp/lb or it’s at the application layer.
You are using Gluster inside of the "HA VMs"? So a file server cluster, for example, are VMs on top of local storage, but with Gluster inside of the VMs, so the VMs can be shut down and then fired up on top of any platform including physical or a different hypervisor, or just left off during work because there are other cluster members available, to remove the need for a live migration?
Correct. Either scenario. So if we lose a host it’s rekickstarted (which is like 10 mins), the template is added, and then Ansible will recreate the guests and run the provisioning against them. The provisioning joins the VM back into the cluster and data starts replicating to it.
If they aren’t using Gluster they just run whatever provisioning is needed.
-
It’s mainly stuff like repos, misc apps, stupid stuff. Any super important data goes on the Isilon.
-
@olivier said in Xenserver and Storage:
Real life usage
So we decided to take a look with some benchmarks, and despite choosing in priority something safe/flexible, we had pretty nice performances, as you can see in our multiple benchmarks.Your benchmarks leave a lot to be desired. I don't see working set size. Testing the performance of local DRAM (What gluster does). This isn't very real world....
