Do you have someone performing an Infrastructure DBA role within your organisation? Do you realise why today you now might need one?
This is a re-post of a blog article I’ve posted at SQLBlogcasts.com (link)
When I first started working with SQL Server there were three distinct roles in the SQL Server virtual team: developer, DBA and sysadmin.
In my simple terms, the developer looked after the “code”: the schema, stored procedures, and any ETL to get data in, out or updated within the database. They could talk in business entity terms about Customer numbers, Product codes and Contract line items. Whatever else happened in the SQL Server stack didn’t really bother them as long as their code worked.
The DBA knew how SQL Server worked, they’d install the software, create databases, manage indexes and SQL Server Agent jobs, do backups and restores. They’d sometimes write ad-hoc reports so knew which columns held key data but how every bit of database logic worked wasn’t of interest to them. DBAs did however care about the design of the database and the server hardware. Making sure the server hardware was of the right spec and configuration was also another interest for DBAs, along with doing everything to avoid getting called out at 2am.
The sysadmin could never do anything right. He always wanted downtime for Windows patches or firmware upgrades, however, as long as everything got built right and worked we never had to bother him, until a SAN got installed. Then we were never quite sure if he actually knew what he was doing and were pretty sure it wasn’t configured properly.
Ok, there maybe some exaggeration there but with dedicated physical servers those three roles were fairly common throughout the 2000s. Nothing but SQL Server could affect the performance of our database platform, and more importantly with the sysadmin at our side everything was in our control. Equally as important was the fact that our monitoring results were true, no one else’s workloads affected the results.
Role forward to 2010
By the end of 2010 virtualisation and SANs are regularly deployed to host both production and non-production SQL Server environments. The dependency between an instance of SQL Server and physical hardware and disks has been broken, we can create new servers and allocate them storage and resources on demand. However, as the diagram below shows this agility has come from the practice of pooling then sharing our physical resources.
What we must now cater for in our SQL Server is that although hardware resources might be allocated to us, the platforms they come from aren’t dedicated to us. The SAN our data is stored on might also store the Exchange mail server’s data, the virtualisation host server our database server runs on might also be running a web server.
The Infrastructure DBA
This new world brings new responsibilities to a SQL Server administrator, in fact it brings a new role to the SQL Server virtual team. To be able to confidently ensure that SQL Server delivers the performance your applications need in a virtualised world you now need someone who understands:
- the database’s demands of SQL Server
- SQL Server’s demands of the server
- SQL Server’s demands of the storage system
- How the hypervisor is configured, shared and works
- How the SAN is configured, shared and works
Is this because we don’t trust the virtualisation or SAN admins, well I’d hope the answer is no.
However, if we’re to understand how SQL Server is performing, or needs to be configured to perform, when it’s using shared components then we need to know as much about our SAN storage layout as we do the logical TempDB layout, if not more so. Configuration changes can be made which we have no control or influence over which can bring SQL Server to its knees.
As well as defending SQL Server against threats to its performance the Infrastructure DBA can bring new features to the SQL Server toolkit. Infrastructure services such as virtual server snapshotting, SAN snapshotting and SAN-to-SAN replication could be invaluable in some environments. By knowing what the infrastructure you’re using is capable of these feature become options to you.
We will always need application code developers, SSIS junkies, production DBAs, sysadmins, virtualisation admins and SAN admins, but now there’s a place at the table for someone who knows enough about each of these to keep the SQL Server ship sailing, at the right direction and at the right speed.
Welcome to the Infrastructure DBA.