2) I don't buy ancient active-passive SANs. Especially based on generic Windows clusters. "We're not in Kansas any more" (c) ... I mean we're not in 2001.
3) StarWind with 3-way replica allows 2 nodes from 3 being AWOL and cluster still being up and running. So "OK" to double faults.
4) Interesting multi-site cluster design.
Still not sure what you want StarWind to do in a referenced interconnect diagram.
Timothy Mitchell wrote:For any normal filing system this would be true. However, when you consider the impact that live migration or v-motion has on any storage system, local or network, you would always want to use differencing disks.anton (staff) wrote:There are many ways to skin a cat (c) ...
You can handle everything on hypervisor level (diff clones) or you may use deduplicated storage where SAN will take care of mapping the same data to the same blocks
and caching them deduplicated. Result would be pretty much the same.
Why?
During any form of live migration all disks directly associated with a VM must be transferred between hosts. If the hyper visor is not aware of the deduplication method when it transfers a VM between hosts it will copy the full contents of the drive and not just the unique section.
For instance, two systems running a web server, the first uses a single virtual disk for all operating system data and the second uses a differencing disk for the same information. On the first the total VHD disk size is 30G, on the second the parent VHD disk is 25G and the differencing disk is 5G. During a live migration of the first web server the entire 30G VHD must be copied between servers for the migration to occur. For the second web server to live migrate only the differencing disk is transferred between hosts, provided the parent disk is available at the same local or network path. If the parent disk is not at the same path the system will prompt you to include the parent disk in the migration.
The argument can be made that a good deduplication SAN can detect duplicate information being read by one server and written by another and allow the copy process to happen faster. However in my experience this has placed a high and unnecessary load on your network for transferring the information between systems and on the memory and processors of your SAN for detecting the duplicate information.
Pushing this separation architecture to its most efficient, use a differencing disk for your operating system drive and have the OS in the virtual machine directly connect an additional drive letter to a separate ISCSI or SMB shared disk(s) for any installed applications, stored files, and log files (Except ISCSI and SMB logging). This will reduce the size of your differencing disk to typically less than half a Gig and allow live migrations of typically large systems such as SQL or Exchange to occur in a matter of seconds on a standard gigabit network.
As for the non-redundant SANs, we are running redundancy on our SANs and our environment requires us to run N+2 no single point of failure on all systems. This means that we must be able to take two failures or configuration errors within any service layer and continue to operate.anton (staff) wrote:I still don't buy your approach with non-redundant SANs and cannot figure out how failover happens.
Each individual SAN is deployed as a pair running failover clustering. The clustering service is only for ISCSI and SMB VHD access. The active device within the cluster handles VHD access and the passive device runs the volume shadow copy service for creating backups without impacting production performance. The passive device is also configured as preferred for DFS traffic and offsite archive.
Each of our sites contains 3 pairs of SAN units. Each member within a cluster runs on a separate SAN pair. SQL is replicated using transactional synchronization. Exchange databases are replicated using DAG. DNS and Active Directory use their own replication system. Web front ends are configured with secondary SQL servers. UAG load balancers use NLB based VIPs for accessible IPs and are configured to detect web server errors in case multiple SQL failures leave a web front end orphaned from both of its SQL servers. And finally DFS is run directly on the SANs for file replication and availability.
Site to site replication is handled through SQL transaction logging, Exchange DAGs, and DFS. Virtualized GTM load balancers on ANYCAST IP addresses redirect CNAMEs to the nearest available site. This design allows our sites to run independent of each other in the case of complete network outage or area isolation. Any split brain clustering issues are handled through the transactional synchronization system when the sites are able to communicate with each other again.
