This is a continuation of a series of articles on hosting solutions and services on Azure public cloud with the most recent discussion on Multitenancy here This article continues to discuss Azure Arc enabled servers, their sizing guidance and operational considerations when increasing the numbers but introduces the overall planning required for Azure arc enabled data services deployment.

The tasks to be undertaken include the following: 1. Plan the deployment with the details from this article, 2. Install client tools and 3. Access a Kubernetes cluster 4. Create an Azure Arc data controller in direct connectivity mode, 5. Create a data service and connect with Azure data studio.

It’s important to know the necessary background and information ready. For example, the database workloads, the business continuity, capacity requirements for memory, CPU and storage for the workloads and infrastructure to support these workloads must be studied.

Ensuring a successful deployment after this study requires the right level of access and appropriate capacity for storage, CPU, and memory.  Extensions and client tools must be installed Kubernetes cluster must be accessed to configure with the kubeconfig file. When the infrastructure is prepared, the Azure Arc enabled data services can then be deployed by

1.       Creating an Azure arc-enabled data controller on one of the validated distributions of a Kubernetes cluster and

2.       Creating an Azure arc enabled SQL managed instance and/or an Azure Arc enabled PostgreSQL Hyperscale server group.

Kubernetes services and distributions can be sourced widely but there is an option to use the Azure Kubernetes Service which also comes with a flavor for Azure Stack HCI.

When we are creating Azure arc enabled data services, regardless of the service or the distribution, the following information will be needed: data controller name, username, password, name of the Kubernetes namespace and connectivity modes, azure subscription id, azure resource group name, azure location, service principal information and infrastructure such as azure, and container runtime.

One of the ways to secure this diversity is to operate with least privilege. This grants users and service accounts specific permissions required to perform the required tasks. Both Azure and Kubernetes provide a role-based access control which can be used to grant specific permissions. This article describes common scenarios in which the security of least privilege must be applied. The Azure Arc data controller requires some permissions that fall under high privilege such as creating Kubernetes namespace or cluster role. The deployment of data controller can be separated into multiple steps and each of these can be performed by user or service account. The separation of duties ensures that each user or service account has just the right permissions and nothing more. 

 #codingexercise

int GetNodeWithKLeaves(Node root, int k, ref List<Node> result)

{

if (root == null) return 0;

if (root.left == null && root.right == null) return 1;

int left = GetNodeWithKLeaves(root.left, k, ref result);

int right = GetNodeWithKLeaves(root.right, k, ref result);

if (left + right == k)

{

 result.Add(root);

}

return left + right;

}