Insight and analysis on the data center space from industry thought leaders.

Finding Common Ground Between Sys Admins and Database Admins

There are many factors that impact application-level availability, and each of these has the potential to cause misunderstandings and, ultimately, problems that could be avoided when both admins are on common ground.

3 Min Read
DataCenterKnowledge logo in a gray background | DataCenterKnowledge

David_Bermingham_468.jpgDKlee_20002.jpg

Dave Bermingham is Microsoft Cloud and Datacenter Management MVP at SIOS Technology, and David Klee is Founder and Chief Architect at Heraflux Technologies.

System administrators are from Venus. Database administrators are from Mars. Or, at least they may as well be when it comes to high availability (HA). Each has—for his or her job—the appropriate perspective on HA. But those different perspectives can lead to consternation and conflict, and more importantly, wasted investments and excessive downtime.

This three-part Industry Perspectives series will explore the differences in Sys admin and DB admin perspectives, and show how both can find common ground in an approach to HA that spans private, public and hybrid cloud configurations. This part introduces the topic by examining the different perspectives both parties have regarding high availability.

Perspectives on High Availability

At a high level, high availability seems simple. HA should deliver minimal or no downtime, resulting in uptime measured in nine’s. And the more nine’s the better with a minimum of five, or 99.999 percent, being a common goal for mission-critical application-level uptime. Downtime includes both the planned and unplanned variety, with the former being scheduled for system and software maintenance, and the latter being caused when something somewhere breaks. Ideally the uptime is guaranteed with a comprehensive and written service level agreement (SLA) that might specify consequences for excessive downtime.

At a low level, however, availability normally means different things to different constituencies. From a database administrator’s perspective, the infrastructure underlying the application should be utterly dependable. If the Sys admins are doing their jobs, all server, storage and networking hardware will be redundant with no single points of failure. And even in worst case scenarios where multiple, concurrent failures might occur, there should always be instantaneous and automatic failover with zero data loss to a functioning system somewhere. To the DB Admin, it is more important that this all happens—with no exceptions—than how it happens.

These “never fail” provisions should also function perfectly during periods of maintenance when the hardware and/or system software is being upgraded and/or updated. This same capability would, of course, also enable the DB Admins to keep all database applications live 24x7 while the software is being updated and the data is being backed up.

From the Sys admin’s perspective, the DB admin’s perspective is unrealistic. Stuff happens. Things fail. Get real. But there’s more. SQL Server is a resource hog, so DB admin’s are always asking for more CPU and memory and storage and bandwidth, creating more opportunities for failure. And they get cranky when they can’t get these additional physical or virtual resources that, according to Sys admins, are really only required to compensate for poorly-designed, inefficient application software.

Seeking Common Ground

In many ways, both admins are right. Sys admins should provide a highly reliable infrastructure, and DB admin’s should be more realistic about reliability and its dependency on resource utilization. And they are both wrong in other ways about the other’s perspective.

Consider, for example, the storage area network. SANs are popular based on their scalability and affordability. SANs also make it possible to consolidate and, therefore, simplify data storage and backup with the ability to create the different recovery point and recovery time objectives needed to satisfy different SLAs for different applications. But SANs are usually managed to emphasize capacity and not performance, making them potentially unsuitable for many of the database applications managed by DB admins.

There are other technology- and solution-specific considerations that impact on application-level availability, and each of these has the potential to cause misunderstandings and, ultimately, problems that could easily be avoided when both admins are on common ground.

Part 2 of this series will explore these considerations involving the high-availability provisions for three popular solutions: SQL Server, VMware and public cloud offerings.

Opinions expressed in the article above do not necessarily reflect the opinions of Data Center Knowledge and Informa.

Industry Perspectives is a content channel at Data Center Knowledge highlighting thought leadership in the data center arena. See our guidelines and submission process for information on participating.

Subscribe to the Data Center Knowledge Newsletter
Get analysis and expert insight on the latest in data center business and technology delivered to your inbox daily.

You May Also Like