@456Q OK I understand, totally different from our business.

Some of our bigger clients demands total segmentation for the system that we're hosting (Its developed by our sister company) so we're building a separate infrastructure for each client with AD, App, Db, File and RDS on its own private VLAN.

It is a traditional 3 layer application with DB backend, App server and then different clients connected to the App server. To ensure redundancy we run the clients App server on the WSFC as well as other related services and the file server.
There can only be 1 App server running, else the DB will be corrupted since it has locks in the DB and other oldschool stuff.

@456Q Yea in failover-cluster the secondary SQL service is not started, it starts when the failover is initiated.
How do you handle your applications? For example we have multiple customers where we have the following setup:

2 VM's running Windows Server, identical CPU/RAM/Disk and they have 1 shared disk for WSFC Witness and 1 shared disk for WSFC SQL Server Data.
On this WSFC we have the following "roles" or whatever to call them:

• SQL Server: The clients databases are in this SQL Server.
• File server: The clients files are on this file server.
• Applications and Services: The clients applications and services runs here, many using the databases hosted in the same SQL Server.

When we have maintenance on VM1 we just failover the whole WSFC and the SQL Server, File Server and Applications and Services running on that VM1 is failed over to VM2 and everything is done within 1-2 minutes.

I dont think AlwaysOn supports this kind of scenario because it does not hare any shared storage. Am I correct in my assumption?

@456Q That's neat, we'll look into that for sure.
Another good thing with the failover cluster and shared disks is that you may run services in "HA" mode and fail over between nodes as you failover the SQL server.
Is that something that works as well? I dont see how you could achieve it without shared storage.

@tjkreidl said in Some HA Questions Memory Error, Parallel Migrate, HA for all VMs,:

@nikade No, but I've done a lot -- probably one or two dozen -- when doing updates to help speed up the evacuation of hosts. You can check the queue with
"xe task-list" to see what's being processed or queued.

Cool, I rarely do migrate them manually so I wouldn't know.

@tjkreidl said in Some HA Questions Memory Error, Parallel Migrate, HA for all VMs,:

@nikade And if you queue up more than three migration instances, my experience has been that then they are processed such that no more than three run concurrently.

Yeah, thats good to hear.
Any idea if there's a max number of migrations you can queue?

@tjkreidl said in Some HA Questions Memory Error, Parallel Migrate, HA for all VMs,:

@nikade In XenServer at least, I thought the limit was three VMs being able to be migrated in parallel, according to this:
https://docs.xenserver.com/en-us/xencenter/current-release/vms-relocate.html

Yeah, that seems to be correct. I would asume XCP has the same baseline.

@456Q said in Let's Test the HA:

@nikade said in Let's Test the HA:

The only thing stopping us from migrating from vSAN is that vSAN has native support for Microsoft SQL Server Failover Cluster which is a huge deal for many of our customers.

Thats interesting and might be good for a new topic. The HA SQL Cluster was pretty much the first thing that we migrated over to XCP-NG. We would have stayed with VMware if this would not work.

I assume you have set up a SQL Server Cluster on WSFC where IP and DISKs failover from node1 to node2?

We have moved on many years ago (before XCP time) from this configuration to an Always On availability group for SQL. Its still a windows cluster that will failover the IP for legacy applications but does not have the disk requirement. It comes with many advantages such as:

• You can setup the SQL HA cluster cross vSAN cluster or XCP pools. You can even mix.

• Each SQL has independent disks and don't share "just" one. You could loos all disks in one cluster without causing downtime for SQL.

• Always on group allow to fail over individual databases. So you can split the load between two server if you have many databases.

There might be something that i dont know. But i know for sure that our SQL cluster is working fine on XCP-ng

Our setup is rather legacy, what SQL license are you using and do you have to license "passive" nodes with AlwaysOn?
When we started our "best practice" AlwaysOn wasnt available in the SQL Standard license and last time I research it I think there was a limitation on how many databases you were allowed to run in the SQL Standard AlwaysOn edition. Maybe that has changed now?

We're using the "legacy" setup with a shared disk for SQL Witness and a shared disk for the SQL Server Data, which vSAN supports natively without having to setup iSCSI.

@456Q said in Let's Test the HA:

Some time past and I like to pick up this old topic as I recently did some DR testing with XOSTOR as well. My pool is HA enabled and the VM configured to restart.

I started with some basic vm migration and reboot of hosts. Disk will sync and resync fine. I was not able to cause an error performing those tasks.

I further removed power from the active host to cause a serious outage. The VM became unavailable. XOSTOR shortly after enabled the disk on the other node and restarted my vm automatically.

I verified that no data was lost. Made some file modifications within the vm and powered up the other node again. It re-joined the pool and synced disk no problem.

Its pretty much the exact same behavior we are used to have with vSAN. I'm very happy with this result !!

I hope this helps someone that is looking for this kind of setup.

Stefan

Very impressive, we have about the same experience with vSAN.
The only thing stopping us from migrating from vSAN is that vSAN has native support for Microsoft SQL Server Failover Cluster which is a huge deal for many of our customers.

Maybe one day we'll use something else which enables us to migrate, untill then we're stuck with VMWare at work.
From a private side its XCP all the way!