Keeping data identical at two locations is becoming increasingly important in a highly available IT world. A couple of years back in time it used to be an expensive enterprise level luxury. But recently that demand can be found in SMB environments too. The method is called mirroring which can be implemented in two ways.
Asynchronous – Data is being synchronized in defined intervals. In between there is a difference (delta) between source and target.
Synchronous – Data transfer is transaction consistent. I.e. the data is identical on both sides at all times. A write operation is only considered complete when source and target page have confirmed the write.
A prerequisite for high availability is mirroring of data (synchronous or asynchronous). If the data is available at two locations (data centers), a further design question arises: Should the storage target act as a fallback copy in case of emergency (Active-Passive), or should the data be actively used in both locations (Active-Active)?
Active-Passive – Only the active side works and data is transferred to the passive side (synchronous or asynchronous). In case of a failiure, the system switches automatically or manually and the previously passive side becomes active. It remains so until a failback is triggered. This method guarantees full performance even in the event of a total site failure. Resources must be equal on both sides. The disadvantage is that only a maximum of 50% of the total resources may be used.
Active-Active – Resources of both sides can be used in parallel and the hardware is utilized more efficiently. However, this means that in the event of a failure, half of the resources are lost and full performance cannot be guaranteed. Active-Active designs require a synchronous mirror, as both sides have to work with identical data.
Active-Active clusters do exist in many different forms. There’s classic SAN storage with integrated mirroring, or software defined storage (sds) where the mirroring is not in hardware but in the software layer. One example is DataCore SANsymphony. VMware vSAN Stretched Cluster plays a special role and will not be covered in this post.
In the following section I will discuss a special pitfall of LUN based active-active constructs, which is often overlooked, but can lead to data loss in case of an error. VMware vSAN is not affected because its stretched cluster is based on a different design which prevents the following issue.
Runecast Analyzer scans VMware infrastructures for known issues against the VMware-KB, checks hardware compatibility against HCL and compares current settings with VMware best-practice-guidelines and security baselines like DISA STIG, PCI DSS or HIPAA. The most recent version 3.1 now contains baselines from German Federal Office for Information Security (BSI). Germany is an important market for Runecast, so including BSI IT-Grundschutz (BSI IT-Baseline) was an important step to win new customers – especially in the public sector. One of the key selling points of Runecast in that market is its ability to work completely offline. No need to send any data into the cloud. You may update the appliance or get new signatures online, but you can also do this offline by mounting an ISO-image. Yes, Germany is special in that respect, but we had some…. issues.
Fully automated VMware HCL checks in Runecast Analyzer
Runecast opened a beta testing program for early adopters to try their latest feature. In a future release of Runecast Analyzer users will not only be able to scan their environment against VMware KB issues, but also to check their hardware against VMware hardware compatibility list (HCL).
I’ve been talking a lot with the Runecast team about this ‘missing’ feature. Now I’m lucky to be one of the beta testers and can get a glimpse to the future. 🙂
Getting information about software and configuration issues in your vSphere cluster is priceless. But what about hardware?