Generally, for most use cases, just having two servers and good backups is the best option. If you have a greenzone, turn your VMs off, do your updates, turn them back on. Updates essentially never cause issues. Not on hypervisors (at least not on KVM/Xen.) Putting in a lot of complexity, cost, or risk to mitigate a shark attack isn't worth it. You will focus on a false risk.

All of the hypervisors are built for this. It's the storage and clustering that may or may not be built for this. As a rule, highest performance systems are not clustered at all, the can't be. Clustering takes a performance hit. But in the extreme performance space products like VMware and Starwind are the top dogs. Both have multiple solutions, but they are using tech like memory sharing, localized data, NVMEoF, log structuring, and others to do things that Gluster just can't do. So much so that products like Gluster sometimes use these techs on top to accelerate them (example: Starwind makes a CEPH accelerator platform.)

@Vlinderbeest said in Infrastructure Needed for Hypervisor Cluster: @scottalanmiller said in Infrastructure Needed for Hypervisor Cluster: Clustering is done when the cost of clustering is low versus the risk of not clustering. I would change that slightly to Clustering is done when the cost of clustering is low versus the cost of not clustering. A risk is always a cost, but some costs are not risks. For example taking down a hypervisor for maintenance vs moving guests to another node and taking down a free node for maintenance. Sure, using risk cost vs investment cost as cost v cost is a perfect valid way to look at it. I use that all the time in the opposite way. You can say that risk is a cost. Or conversely, you can look at the clustering cost up front as essentially a "financial event" similar to an outage.

@travisdh1 said in Supermicro SuperServer E200-8D and E300-8D – review: @DustinB3403 said in Supermicro SuperServer E200-8D and E300-8D – review: @travisdh1 Yeah I saw that, which was why I was asking about it. Just taking a quick look at the pricing, you can get those smaller Dell servers with 4 3.5" bays for less, at least in the US. that's a main problem here in Italy. If you ask for a street price for dell or hpe you go cheeper then supermicro (and local SLA is better).

I understand your goal and the idea isn't bad, it's just not possible. Now, what IS possible, if you really want to do this and are set up as I imagine you are from the description (that is, assuming that this is a data-only array and not the OS... so we assume that the OS is always still intact...) Have a WARM spare (no such thing as a HOT spare with RAID 0, it just is nonsensical, it's a meaningless term to use in that case.) This will sit idly by. Have a monitoring script that looks for an array failure. Have the script talk to the Smart Array utility and disengage the dead drive. Have the script talk to the utility and add in the WARM spare to a new array group. Have the script built a new RAID 0 array. Have the script unmount the old array and remove any legacy bits of it. Detect the new array. LVM the new array. Format the new array. Mount the new array. Signal to the node that it is ready to proceed. So I think that this does what you want, but it is not a HOT spare and it is not the RAID controller doing the work, it is your own script. So your end result can be done, just not using the exact tool and location of tool that you were imagining. But having a spare on board and rebuilding the system is possible. But most likely there will be a better way to skin this cat. But I can see a potential use case for this.

I have a sneaking suspicion that it is the fact that my 2 SQL Servers and the two other nodes that I want to use in this are on different subnets (although I am unsure as to why that would matter). My boss is going to get me an IP addy this morning, and I'll build a totally separate cluster for these two servers and see what happens.

Trying anything I can think of, this part looks promising to maybe be the issue... WSREP_SST: [INFO] Removing the sst_in_progress file (20150615 23:31:45.369) 150615 23:31:45 [ERROR] WSREP: Process completed with error: wsrep_sst_xtrabackup --role 'joiner' --address 'x.x.x.x' --auth 'no:no' --datadir '/db/mysql/' --defaults-file '/etc/mysql/my.cnf' --parent '16465': 32 (Broken pipe) 150615 23:31:45 [ERROR] WSREP: Failed to read uuid:seqno from joiner script. 150615 23:31:45 [ERROR] WSREP: SST failed: 32 (Broken pipe) 150615 23:31:45 [ERROR] Aborting