While I work 100% with cloud based SQL Server deployments these days, my life is not all unicorns and PaaS services. Surprisingly (or not) enough, many of the environments in the cloud are still build on top of good, trusty virtual machines. Except that sometimes they’re not good or trusty. There are definitely some good reasons for deploying VM’s in the cloud, however some decisions on the architecture can prove to be a challenge in a long run.
In this post, I’ll share my experience from struggling with some of these decisions, and hopefully help some of you make better decisions out there. Let me share a woeful story about Storage Spaces Direct and Cluster Shared Volumes.
I have previously written quite a few post about how much I like the Platform-as-a-Service databases for SQL Server (and for databases in general), and I do like them quite a bit. But would I recommend them for all use cases and workloads? Heck no! At the moment there are some features and limitations in Azure SQL PaaS databases that, with some of hte SQL Server workloads I have seen, wouldn’t just work all that well.
Also when we look at Azure, there’s some really cool features available for VMs that you can start using today, which are making the good old VMs an interesting option.
I just realized that it has been awhile since my last post, so I figured it’s time to do one before the end of the year. Last few months have been rather hectic with me migrating new workloads to Cloud as well as taking the time to visit PASS Summit 2019 to learn more about Microsoft Data Platform.
I also wanted to finish up my year of blogging by writing about a topic close to my heart, the evolution of the DBA role in the Cloud era. I did have a session about this topic in SQLSaturday Finland earlier this year and I will be doing a PASS Cloud Virtual Group presentation about it on January 16th.
In this post we’ll be looking at one of the Cloud technologies that have significant impact on the DBA role in the future, Platform-as-a-Service databases.
I’ve said it before and I say it again: Understanding how database backups and restores work is one of the more important topics for DBAs to understand. This time we’ll approach the topic from the cloud, and more precisely, from Azure perspective. Why cloud perspective you might as? For one simple reason. Even if you’re not (yet) running your SQL Server workloads in Azure, it doesn’t mean that you can’t make use of it for other purposes, such as backups. And while the idea of placing your data into Azure, or into any other cloud platform, might still seem scary to some, I want to help put your minds at ease. To do this, I’ll just point you to this fine piece of documentation describing the Azure infrastructure security. I think you’ll find it quite satisfying.
As there’s quite a few topics to cover with database backups to Azure, I have split the details into 4 separate posts. You’re now reading Part 1, the introduction.
In previous post, Part 1: Creating Azure Network and Storage, we set up your Azure account ready for two virtual machines that’ll be the backbone of your own testing environment. One of these servers will run the Active Directory and the other one will host your SQL Server 2012 instance. The Active Directory server is really optional, you can do a test environment without it but I prefer test environments that mimic the production.
Now that you’ve setup your Azure account we can get started on building the test environment. First thing you should do is to create a Virtual Azure Network, this will be used for connectivity between your servers. Creating a Network is quite straightforward business. Choose Networks and then Create A Virtual Network.