Xenserver and Storage
-
@kooler said in Xenserver and Storage:
@olivier said in Xenserver and Storage:
Having local storage is good for perfs, but you can't live migrate without moving the disks or HA on the other host.
I did a recap on local vs (non hyperconverged) shared storage in XS:
Most of the "budget" SMB customers shouldn't care about that.
This is not my point of view. Eg even for my small production setup, hosted in a DC, it's not obvious to migrate big VMs on local SR from a host to another to avoid service interruption.
edit: I'm using XOSAN for my own production setup, best way to sell a product
-
@olivier said in Xenserver and Storage:
Having local storage is good for perfs, but you can't live migrate without moving the disks or HA on the other host.
I did a recap on local vs (non hyperconverged) shared storage in XS:
That's not really a sensible statement. You can't live migrate the STORAGE of the VMs without moving the storage. If you want to move your VMs without moving storage, you stay in the same boat as with any external storage. If you need to move the storage live with external storage, you have the same issues.
You have to treat the two things differently to give any advantage to external storage on dedicated hardware. Literally, anything that looks like an advantage is always expecting it to "deliver less" than the local disks and therefore not asking as much of it. Like we expect the local disks to live migrate, but completely ignore asking the external storage to do that.
How does security improve by having more points to attack?
-
@olivier said in Xenserver and Storage:
@kooler said in Xenserver and Storage:
@olivier said in Xenserver and Storage:
Having local storage is good for perfs, but you can't live migrate without moving the disks or HA on the other host.
I did a recap on local vs (non hyperconverged) shared storage in XS:
Most of the "budget" SMB customers shouldn't care about that.
This is not my point of view. Eg even for my small production setup, hosted in a DC, it's not obvious to migrate big VMs on local SR from a host to another to avoid service interruption.
edit: I'm using XOSAN for my own production setup, best way to sell a product
SMBs should not be worried, in 99% of cases, about migrating VMs around. That's not an SMB need.
-
I consider myself as a SMB (3 sockets!) and I need live migration, that's really something useful. That's also used a LOT by our customers. Maybe a XenServer users bias. But it's real there.
-
@olivier said in Xenserver and Storage:
I consider myself as a SMB (3 sockets!) and I need live migration, that's really something useful. That's also used a LOT by our customers. Maybe a XenServer users bias. But it's real there.
Used by, and should be used by are not the same things. SMBs are famous for wasting money where it is pointless, doing complex things because it makes them feel good, and not spending more (or effort) where it actually matters. Why would SMBs need to live migrate services around?
-
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)
-
@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.
