Ensuring SQL Server High Availability in the Cloud

Theoretically, the cloud seems tailor-made for ensuring high availability (HA) and disaster recovery (DR) solutions in mission critical SQL Server deployments. Azure, AWS, and Google have distributed, state-of-the-art data centers throughout the world. They offer a variety of SLAs that can guarantee virtual machine (VM) availability levels of 99.95% and higher.

But deploying SQL Server for HA or DR has always posed a challenge that goes beyond geographic dispersion of data centers and deep levels of hardware redundancy. Configuring your SQL Server for HA or DR involves building a Windows Server Failover Cluster (WSFC) that ensures not only the availability of different machines running SQL Server itself but also — and most importantly — the availability of storage holding the data in which SQL Server is interacting.

Are You Taking the Right Approach to Cloud Databases?

Trends in cloud data storage continue to accelerate at a rapid pace. Now more than ever, organizations must evaluate their current and future data storage needs to find solutions that align with business goals. While cloud databases are relatively new to the scene, they show tremendous prospect in securing and managing data.

In selecting our topic for this Trend Report, we found the amount of promise and advancement in the space to be unparalleled. This Report highlights DZone’s original research on cloud databases and contributions from the community, as well as introduces new offerings within DZone Trend Reports.

Checksums in Storage Systems and Why the Enterprise Should Care

Random bit flips are far more common than most people, even IT professionals, think. Surprisingly, the problem isn’t widely discussed, even though it is silently causing data corruption that can directly impact our jobs, our businesses, and our security. It’s really scary knowing that such corruptions are happening in the memory of our computers and servers – that is before they even reach the network and storage portions of the stack. Google’s in-depth study of bit-level DRAM errors showed that such uncorrectable errors are a fact of life. And do you remember the time when Amazon had to globally reboot their entire S3 service due to a single bit error?

The Error-Prone Data Trail

Let’s assume for a moment that your data survives its many passes through a system’s DRAM and emerges intact. That data must then be safely transported over a network to the storage system where it is written to disk. How do you assure the data remains unaltered along the way? Well, if you’re using one of the storage protocols that lack end-to-end checksums (e.g. NFSv2, NFSv3, SMBv2), your data remains susceptible to random bit flips and data corruption. Even NFSv4 plus Kerberos 5 with integrity checking (krb5i) doesn’t offer true end-to-end checksums. Once the data is extracted from the RPC, it is unprotected once again. In addition, widespread adoption of NFSv4 hasn’t happened, and fewer still use krb5i.