There are a few server-wide configurations that you cannot setup during inital Big Data Cluster deployment. One of those is enabling SQL Agent service. That’s right. If you have deployed a Big Data Cluster you will notice the SQL Server Agent is disabled by default (see screenshot below):
In my previous posts, I showed you how to deploy a single node cluster and a multi-node cluster. That’s find and dandy but how do you upgrade to the newest SQL Server CU? This blog post will show you how to easily upgrade a SQL Server Big Data Cluster. This method applies to a single node or multi-node cluster. It does not matter how many nodes your BDC has, this upgrade process will work.
In my previous post, I talked about deploying a Big Data Cluster on a single node Kubernetes cluster. That’s cool and all but what if you’re a business or organization that cannot have your data on the cloud for whatever reason? Is there a way to deploy a Big Data Cluster on-premise? Absolutely! I’ll walk you through setting that up this blog post. I will walk you through deploying a 3-node Kubernetes cluster, then deploying a Big Data Cluster on top of that.
So you want to play around with a Big Data Cluster but on a strict budget? No problem! Keep reading or watch the video below.
If you are interested in deploying a Big Data Cluster on a multi-node kubeadm cluster, check out my post here.
One of the key components of a Big Data Cluster is the data pool. Within that single data pool, there are two SQL Server instances. The primary job of the data pool is to provide data persistence and caching for the Big Data Cluster. (At the time of this blog post, there can only be a single data pool in a Big Data Cluster and the maximum supported number instances in a data pool is eight.) The instances inside the data pool do not communicate with each other and are accessed via the SQL Server Master instance. The data pool instances are also where data marts are created.
A few months ago I posted a blog on deploying a BDC using the built-in ADS notebook. This blog post will go a bit deeper into deploying a Big Data Cluster on AKS (Azure Kubernetes Service) using Azure Data Studio (version 1.13.0). In addition, I’ll go over the pros and cons and dive deeper into the reasons why I recommend going with AKS for your Big Data Cluster deployments.
One of the biggest questions I had when I first started diving into Big Data Clusters was, “What about licensing….how will that work?” With so many different instances running on the storage pool, data pool and compute pool nodes will licensing cost too much? The answer I got from Microsoft was that it will “be competitive”.
Before you deploy big data clusters, you must configure the tools below on a Windows or Linux machine that will act like a “base machine” from which you will be able to deploy, manage, and monitor a SQL Server Big Data Cluster. For the example in this blog I will use a virtual machine running Windows Server 2016 running 4 cores and 8 GB RAM. (This can also work on a Windows 10 Pro machine as well).
A few months ago I posted a blog on deploying a BDC using the built-in ADS notebook. This blog post will talk about the deployment options available for Big Data Clusters and benefits of going with Azure Kubernetes Service (AKS).
I love to share real-life stories when I give talks. I usually start out my sessions with a story on how I got interested in Big Data Clusters. It all starts with my neighbor Tom (not his real name) last year (2018). I was at the bus stop with my 5 yr old son on his first day of Kindergarten. As I am waiting patiently for the bus to arrive I hear a voice say,
“Are you in IT?”
I finally presented my first tech at SQL Saturday Sioux Falls and Baton Rouge. I decided to name my session, “Big Data Clusters for the Absolute Beginner” because beginning of 2019 I *was* the absolute beginner (and I’m learning every day!) So in a way, my session is “based on a true story” :) I’m super-excited because I think it’s the future of SQL Server. Big Data Clusters are new and cutting-edge technology.
— Anthony E. Nocentino (@nocentino) August 17, 2019
— Anthony E. Nocentino (@nocentino) August 17, 2019
Yesterday was the release of SQL Server 2019 CTP 3.2. The biggest change in CTP 3.2 is that Big Data Clusters is now in public preview. That means anyone can go download and deploy it. Prior to CTP 3.2, you had to sign up for the “Early Adoption Program”, wait until you received an email with your Docker credentials, etc. With CTP 3.2, Microsoft has actually done away with Docker credentials. You no longer need that to create your Big Data Cluster as the images needed are on Microsoft’s public repo.
This is part 4 of the “BDC series.” You can read part 1 here, part 2 here, and part 3 here. This blog post will go into the available monitoring tools available to monitor the health of your Big Data Cluster. If you’d like to stay updated, without doing the heavy work, feel free to register for my newsletter. I will email out blog posts of my journey down the wonderful road of BDCs.[Updated for CTP 3.2] – There are kubectl commands and azdata commands to check the health of your cluster but I will focus on the Kubernetes Dashboard for this series. I will blog about some of the useful kubectl and mssqlctl commands in later posts.
This is part 3 of the “BDC series.” You can read part 1 here and part 2 here. This blog post will go into creating the Big Data Cluster on top of the Azure Kubernetes Service (AKS) cluster we created in Part 2. If you’d like to stay updated, without doing the heavy work, feel free to register for my newsletter. I will email out blog posts of my journey down the wonderful road of BDCs.
Before I get started I want to say that there are many ways to deploy a Big Data Cluster. There is a “Default configuration” way and a “Custom configuration” way. You can read more about the custom config way here. I will be posting blogs on the other ways to deploy a BDC but for the sake of this series I will be deploying the BDC via the default way. The BDC team at Microsoft is constantly revamping and tweaking the BDC deployment process in order to make it more streamline and easier.