Follow along with the video below to see how to install our site as a web app on your home screen.
Note: This feature may not be available in some browsers.
Came here to say this. Always On is what you want.Make sure you do always on. Standard clustering in SQL on Vmware is no bueno
Also, while I know you can technically virtualize MS SQL, I would exercise caution and analyze your current I/O performance and compare it to what you will get in the VMware cluster. SANS wont match the performance of direct attached SAS drives which could be a critical factor in DB performance.
Doesn't VMWare have its own VSAN solution which can be used for SQL FCI?
Yea sql licensing is a bitch. Not to mention if you need more than two sql servers in an AG now you need enterprise anyway.Please take note of MSSQL licensing. to get full Alwayon AG features, you need enterprise, and list price of an enterprise 2-core pack is around $14k. so in a lot of cases, although its nice to have, its not the best solution (unless you have dependency on enterprise features like TDE, online indexing, readable-secondaries, etc...). FCI on shared storage works just fine, and only uses MSSQL standard ($3-4k per 2-core pack). Also, VMware and Hyper-V does support shared storage - and if for some reason that it's not possible to implement on the hypervisor level, you can virtualize this in a hyperconverged configuration with Storage Spaces Direct.
This can of course go a lot deeper, but from a total solution perspective, its best to always incorporate licensing/cost/TCO.
Grimlakin vSAN is perfectly fine for these types of deployments and is fully supported. Newer versions of ESXi with vSAN also do not require RDM disks any more either for Windows Fail over clustering to work, and can be fully run on a vSAN cluster so Always on is not always needed (preferred for sure, but if you just need to P2V).VMwares VSAn isn't that great for these types of deployments in my experience. The level of fault tolerance is less and the ability to loose data is in my experience worse. A solid Unity or like attached fiber storage will provide ample performance unless the databases are insanely large/busy.
Grimlakin vSAN is perfectly fine for these types of deployments and is fully supported. Newer versions of ESXi with vSAN also do not require RDM disks any more either for Windows Fail over clustering to work, and can be fully run on a vSAN cluster so Always on is not always needed (preferred for sure, but if you just need to P2V).
The level of fault tolerance is however you design it. If you have a single SAN, you have a single point of failure, vs a 3 node VSAN cluster. You scale out with vSAN not up to give more redundancy and performance.
So if you lose data more and redundancy - you designed it wrong from the start. That is no fault of VMware and vSAN.
No longer the case. vSAN supports it natively as does FC storage for vmdk....
Also if you MS cluster your SQL servers you will need to use RDM drives which are their own special flavor of headaches, again depending on what type of storage.
No longer the case. vSAN supports it natively as does FC storage for vmdk.
See Vladan's post here: https://4sysops.com/archives/vmware-vsphere-7-clustered-vmdk/
Shared VMDK requirements:
I am seeing less clients use this approach and more using the Always On method due to the limitations around snapshotting using this method. To be fair though, if you were using the RDM approach you also had this limitation and were doing native SQL Maintenance Plans anyways.
- A fiber channel array only.
- The array must support ATS, SCSI-3 PR–type Write Exclusive–All Registrant (WEAR).
- The datastore must be formatted with VMFS 6 (VMFS 5 is not supported).
- VMDK must be Eager Zero Thick (no thin provisioned VMDKs).
- If you have DRS configured in your environment, you must create an anti-affinity rule so that the VMs can run on separate hosts.
- vCenter server 7.0 and higher.
- Snapshots, cloning, and storage vMotion are not supported (no backup of nodes is possible, because backup software uses snapshots).
- Fault tolerance (FT), hot change to the VMS virtual hardware, and hot expansion of clustered disks are not
- vMotion is supported, but only for hosts that meet the same requirements.
Good to know. However personally I don't know anyone that uses VSAN in a large scale enterprise environment.... the no snapshot thing is a bummer and our backup methods also employs snaps.
Burticus Deployed 32 nodes VxRail across 4 clusters, just under $3 million in hardware, one cluster specifically for SQL only VMs. "If you're using a NAS for iscsi, or using Vsan.... the performance is going to suck." this is not true either, if anything performance is better as you eliminate latency using local disks vs going to an array of some sort. Also if performance sucks, it means you did not spec it out properly for the work loads. These are all flash nodes.Good to know. However personally I don't know anyone that uses VSAN in a large scale enterprise environment.... the no snapshot thing is a bummer and our backup methods also employs snaps.
This is the only way to do it and imo still is a pita compared to always onBurticus Deployed 32 nodes VxRail across 4 clusters, just under $3 million in hardware, one cluster specifically for SQL only VMs. "If you're using a NAS for iscsi, or using Vsan.... the performance is going to suck." this is not true either, if anything performance is better as you eliminate latency using local disks vs going to an array of some sort. Also if performance sucks, it means you did not spec it out properly for the work loads. These are all flash nodes.
As for snapshots,VM level yes, this client uses Dell EMC Avamar, that does snapshots, storage level snapshots are not needed like they used to be. You may want to read up on more recent vSAN documentation, plenty has changed in the vSAN space...
https://blogs.vmware.com/virtualblocks/2019/12/04/closer-look-vsan-snapshots/