Scale Computing VS Proxmox
-
@scottalanmiller thank you! We definitely have some apps that some of our users are using that do not offer the ability for application layer failover. Of course those are the apps that the company uses for billing and payroll so they are critical. Based on your's and @JaredBusch's responses it definitely seems like it is worth looking into the renewal of the Scale cluster.
-
@NHCSAdmin said in Scale Computing VS Proxmox:
@scottalanmiller thank you! We definitely have some apps that some of our users are using that do not offer the ability for application layer failover. Of course those are the apps that the company uses for billing and payroll so they are critical. Based on your's and @JaredBusch's responses it definitely seems like it is worth looking into the renewal of the Scale cluster.
Yup, makes sense. of course non-HC makes sense where you need no failover at all, as well.
Your AD controllers are the perfect example of application layer failover. They have that built in so you don't want them being moved by the virtualization layer.
Your accounting needs failover, but has none of its own. So needs the crutch of the HC system.
Your Unifi controller has no problem with downtime, so no failover is necessary at all. Since you have it, might as well use it, but if the controller went down for a while, no big deal.
All three workload scenarios there. Since you have the middle one, you need HC or similar.
-
@scottalanmiller Thanks for the detailed explanation!
-
@NHCSAdmin said in Scale Computing VS Proxmox:
@scottalanmiller Thanks for the detailed explanation!
You bet! Glad to assist.
-
Did scale ever add the ability to unmount and remount disks? The last time I used it (2018) you couldn’t unmount a disk and then mount it to a new machine.
-
@stacksofplates said in Scale Computing VS Proxmox:
Did scale ever add the ability to unmount and remount disks? The last time I used it (2018) you couldn’t unmount a disk and then mount it to a new machine.
They did but I don't know the process.
-
@stacksofplates Yes, we did in 2019. There are a couple of ways that can be done. When you snapshot a VM, any disk in that snap can be mounted to any other vm, provided that the logged in user is at a permissions level allowing it. That is actually part of the mechanism that several backup vendors (acronis, storware,etc) use to do agentless backups of Scale Computing VM's. If you haven't taken a look since 2018, you should take a look again as there has been so very many things added since then.
-
@Aconboy said in Scale Computing VS Proxmox:
@stacksofplates Yes, we did in 2019. There are a couple of ways that can be done. When you snapshot a VM, any disk in that snap can be mounted to any other vm, provided that the logged in user is at a permissions level allowing it. That is actually part of the mechanism that several backup vendors (acronis, storware,etc) use to do agentless backups of Scale Computing VM's. If you haven't taken a look since 2018, you should take a look again as there has been so very many things added since then.
A wild @Aconboy appears!
-
@scottalanmiller I gotta show up from time to time or people think I am a myth
-
@Aconboy said in Scale Computing VS Proxmox:
@stacksofplates Yes, we did in 2019. There are a couple of ways that can be done. When you snapshot a VM, any disk in that snap can be mounted to any other vm, provided that the logged in user is at a permissions level allowing it. That is actually part of the mechanism that several backup vendors (acronis, storware,etc) use to do agentless backups of Scale Computing VM's. If you haven't taken a look since 2018, you should take a look again as there has been so very many things added since then.
Well I guess I mean more without doing a snapshot. The flow we were looking for at the time was we had an ephemeral VM that would boot, mount the disk for storage, we could unmount the disk, destroy the VM, bring it up a new copy and remount the disk. The data disk wouldn't be in the snapshot since it only holds app state. Think of it like persistent volumes for k8s.