diff --git a/docs/examples/mssqlserver/autoscaler/compute/ms-as-compute.yaml b/docs/examples/mssqlserver/autoscaler/compute/ms-as-compute.yaml new file mode 100644 index 0000000000..8bb784d2be --- /dev/null +++ b/docs/examples/mssqlserver/autoscaler/compute/ms-as-compute.yaml @@ -0,0 +1,24 @@ +apiVersion: autoscaling.kubedb.com/v1alpha1 +kind: MSSQLServerAutoscaler +metadata: + name: ms-as-compute + namespace: demo +spec: + databaseRef: + name: mssqlserver-ag-cluster + opsRequestOptions: + timeout: 5m + apply: IfReady + compute: + mssqlserver: + trigger: "On" + podLifeTimeThreshold: 5m + resourceDiffPercentage: 10 + minAllowed: + cpu: 800m + memory: 2Gi + maxAllowed: + cpu: 1 + memory: 3Gi + containerControlledValues: "RequestsAndLimits" + controlledResources: ["cpu", "memory"] \ No newline at end of file diff --git a/docs/examples/mssqlserver/autoscaler/compute/mssqlserver-ag-cluster.yaml b/docs/examples/mssqlserver/autoscaler/compute/mssqlserver-ag-cluster.yaml new file mode 100644 index 0000000000..c43e3b77d1 --- /dev/null +++ b/docs/examples/mssqlserver/autoscaler/compute/mssqlserver-ag-cluster.yaml @@ -0,0 +1,46 @@ +apiVersion: kubedb.com/v1alpha2 +kind: MSSQLServer +metadata: + name: mssqlserver-ag-cluster + namespace: demo +spec: + version: "2022-cu12" + replicas: 3 + topology: + mode: AvailabilityGroup + availabilityGroup: + databases: + - agdb1 + - agdb2 + internalAuth: + endpointCert: + issuerRef: + apiGroup: cert-manager.io + name: mssqlserver-ca-issuer + kind: Issuer + tls: + issuerRef: + name: mssqlserver-ca-issuer + kind: Issuer + apiGroup: "cert-manager.io" + clientTLS: false + podTemplate: + spec: + containers: + - name: mssql + resources: + requests: + cpu: "500m" + memory: "1.5Gi" + limits: + cpu: "600m" + memory: "1.6Gi" + storageType: Durable + storage: + storageClassName: "longhorn" + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + deletionPolicy: WipeOut \ No newline at end of file diff --git a/docs/examples/mssqlserver/autoscaler/storage/ms-as-storage.yaml b/docs/examples/mssqlserver/autoscaler/storage/ms-as-storage.yaml new file mode 100644 index 0000000000..796ae16d9a --- /dev/null +++ b/docs/examples/mssqlserver/autoscaler/storage/ms-as-storage.yaml @@ -0,0 +1,15 @@ +apiVersion: autoscaling.kubedb.com/v1alpha1 +kind: MSSQLServerAutoscaler +metadata: + name: ms-as-storage + namespace: demo +spec: + databaseRef: + name: mssqlserver-ag-cluster + storage: + mssqlserver: + trigger: "On" + usageThreshold: 60 + scalingThreshold: 50 + expansionMode: "Offline" + upperBound: "100Gi" \ No newline at end of file diff --git a/docs/examples/mssqlserver/autoscaler/storage/mssqlserver-ag-cluster.yaml b/docs/examples/mssqlserver/autoscaler/storage/mssqlserver-ag-cluster.yaml new file mode 100644 index 0000000000..c43e3b77d1 --- /dev/null +++ b/docs/examples/mssqlserver/autoscaler/storage/mssqlserver-ag-cluster.yaml @@ -0,0 +1,46 @@ +apiVersion: kubedb.com/v1alpha2 +kind: MSSQLServer +metadata: + name: mssqlserver-ag-cluster + namespace: demo +spec: + version: "2022-cu12" + replicas: 3 + topology: + mode: AvailabilityGroup + availabilityGroup: + databases: + - agdb1 + - agdb2 + internalAuth: + endpointCert: + issuerRef: + apiGroup: cert-manager.io + name: mssqlserver-ca-issuer + kind: Issuer + tls: + issuerRef: + name: mssqlserver-ca-issuer + kind: Issuer + apiGroup: "cert-manager.io" + clientTLS: false + podTemplate: + spec: + containers: + - name: mssql + resources: + requests: + cpu: "500m" + memory: "1.5Gi" + limits: + cpu: "600m" + memory: "1.6Gi" + storageType: Durable + storage: + storageClassName: "longhorn" + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + deletionPolicy: WipeOut \ No newline at end of file diff --git a/docs/guides/mssqlserver/autoscaler/_index.md b/docs/guides/mssqlserver/autoscaler/_index.md new file mode 100644 index 0000000000..b6fdc08188 --- /dev/null +++ b/docs/guides/mssqlserver/autoscaler/_index.md @@ -0,0 +1,10 @@ +--- +title: Autoscaling +menu: + docs_{{ .version }}: + identifier: ms-autoscaling + name: Autoscaling + parent: guides-mssqlserver + weight: 46 +menu_name: docs_{{ .version }} +--- diff --git a/docs/guides/mssqlserver/autoscaler/compute/_index.md b/docs/guides/mssqlserver/autoscaler/compute/_index.md new file mode 100644 index 0000000000..cea75aa0c6 --- /dev/null +++ b/docs/guides/mssqlserver/autoscaler/compute/_index.md @@ -0,0 +1,10 @@ +--- +title: Compute Autoscaling +menu: + docs_{{ .version }}: + identifier: ms-compute-autoscaling + name: Compute Autoscaling + parent: ms-autoscaling + weight: 10 +menu_name: docs_{{ .version }} +--- diff --git a/docs/guides/mssqlserver/autoscaler/compute/cluster.md b/docs/guides/mssqlserver/autoscaler/compute/cluster.md new file mode 100644 index 0000000000..14bc5ddf97 --- /dev/null +++ b/docs/guides/mssqlserver/autoscaler/compute/cluster.md @@ -0,0 +1,603 @@ +--- +title: MSSQLServer Availability Group Cluster Autoscaling +menu: + docs_{{ .version }}: + identifier: ms-autoscaling-cluster + name: Cluster + parent: ms-compute-autoscaling + weight: 20 +menu_name: docs_{{ .version }} +section_menu_id: guides +--- + +> New to KubeDB? Please start [here](/docs/README.md). + +# Autoscaling the Compute Resource of a MSSQLServer Availability Group Cluster Database + +This guide will show you how to use `KubeDB` to auto-scale compute resources i.e. cpu and memory of a MSSQLServer cluster database. + +## Before You Begin + + +- You need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. If you do not already have a cluster, you can create one by using [kind](https://kind.sigs.k8s.io/docs/user/quick-start/). + +- Now, install KubeDB cli on your workstation and KubeDB operator in your cluster following the steps [here](/docs/setup/README.md). Make sure install with helm command including `--set global.featureGates.MSSQLServer=true` to ensure MSSQLServer CRD installation. + +- To configure TLS/SSL in `MSSQLServer`, `KubeDB` uses `cert-manager` to issue certificates. So first you have to make sure that the cluster has `cert-manager` installed. To install `cert-manager` in your cluster following steps [here](https://cert-manager.io/docs/installation/kubernetes/). + +- Install `Metrics Server` from [here](https://github.com/kubernetes-sigs/metrics-server#installation) + +- You should be familiar with the following `KubeDB` concepts: + - [MSSQLServer](/docs/guides/mssqlserver/concepts/mssqlserver.md) + - [MSSQLServerOpsRequest](/docs/guides/mssqlserver/concepts/opsrequest.md) + - [Compute Resource Autoscaling Overview](/docs/guides/mssqlserver/autoscaler/compute/overview.md) + - [MSSQLServerAutoscaler](/docs/guides/mssqlserver/concepts/autoscaler.md) + +To keep everything isolated, we are going to use a separate namespace called `demo` throughout this tutorial. + +```bash +$ kubectl create ns demo +namespace/demo created +``` +## Autoscaling of MSSQLServer Availability Group Cluster + +Here, we are going to deploy a `MSSQLServer` Availability Group Cluster using a supported version by `KubeDB` operator. Then we are going to apply `MSSQLServerAutoscaler` to set up autoscaling. + +#### Deploy MSSQLServer Availability Group Cluster + +First, an issuer needs to be created, even if TLS is not enabled for SQL Server. The issuer will be used to configure the TLS-enabled Wal-G proxy server, which is required for the SQL Server backup and restore operations. + +### Create Issuer/ClusterIssuer + +Now, we are going to create an example `Issuer` that will be used throughout the duration of this tutorial. Alternatively, you can follow this [cert-manager tutorial](https://cert-manager.io/docs/configuration/ca/) to create your own `Issuer`. By following the below steps, we are going to create our desired issuer, + +- Start off by generating our ca-certificates using openssl, +```bash +openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout ./ca.key -out ./ca.crt -subj "/CN=MSSQLServer/O=kubedb" +``` +- Create a secret using the certificate files we have just generated, +```bash +$ kubectl create secret tls mssqlserver-ca --cert=ca.crt --key=ca.key --namespace=demo +secret/mssqlserver-ca created +``` +Now, we are going to create an `Issuer` using the `mssqlserver-ca` secret that contains the ca-certificate we have just created. Below is the YAML of the `Issuer` CR that we are going to create, + +```yaml +apiVersion: cert-manager.io/v1 +kind: Issuer +metadata: + name: mssqlserver-ca-issuer + namespace: demo +spec: + ca: + secretName: mssqlserver-ca +``` + +Let’s create the `Issuer` CR we have shown above, +```bash +$ kubectl create -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/examples/mssqlserver/ag-cluster/mssqlserver-ca-issuer.yaml +issuer.cert-manager.io/mssqlserver-ca-issuer created +``` + +In this section, we are going to deploy a MSSQLServer Availability Group Cluster with version `2022-cu12`. Then, in the next section we will set up autoscaling for this database using `MSSQLServerAutoscaler` CRD. Below is the YAML of the `MSSQLServer` CR that we are going to create, + +```yaml +apiVersion: kubedb.com/v1alpha2 +kind: MSSQLServer +metadata: + name: mssqlserver-ag-cluster + namespace: demo +spec: + version: "2022-cu12" + replicas: 3 + topology: + mode: AvailabilityGroup + availabilityGroup: + databases: + - agdb1 + - agdb2 + internalAuth: + endpointCert: + issuerRef: + apiGroup: cert-manager.io + name: mssqlserver-ca-issuer + kind: Issuer + tls: + issuerRef: + name: mssqlserver-ca-issuer + kind: Issuer + apiGroup: "cert-manager.io" + clientTLS: false + podTemplate: + spec: + containers: + - name: mssql + resources: + requests: + cpu: "500m" + memory: "1.5Gi" + limits: + cpu: "600m" + memory: "1.6Gi" + storageType: Durable + storage: + storageClassName: "longhorn" + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + deletionPolicy: WipeOut +``` + +Let's create the `MSSQLServer` CRO we have shown above, + +```bash +$ kubectl create -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/examples/mssqlserver/autoscaler/compute/mssqlserver-ag-cluster.yaml +mssqlserver.kubedb.com/mssqlserver-ag-cluster created +``` + +Now, wait until `mssqlserver-ag-cluster` has status `Ready`. i.e, + +```bash +$ kubectl get mssqlserver -n demo +NAME VERSION STATUS AGE +mssqlserver-ag-cluster 2022-cu12 Ready 8m27s +``` + +Let's check the MSSQLServer resources, +```bash +$ kubectl get ms -n demo mssqlserver-ag-cluster -o json | jq '.spec.podTemplate.spec.containers[] | select(.name == "mssql") | .resources' +{ + "limits": { + "cpu": "600m", + "memory": "1717986918400m" + }, + "requests": { + "cpu": "500m", + "memory": "1536Mi" + } +} +``` + + +Let's check the Pod containers resources, there are two containers here, first one with index 0 named `mssql` is the main container of mssqlserver. + +```bash +$ kubectl get pod -n demo mssqlserver-ag-cluster-0 -o json | jq '.spec.containers[0].resources' +{ + "limits": { + "cpu": "600m", + "memory": "1717986918400m" + }, + "requests": { + "cpu": "500m", + "memory": "1536Mi" + } +} +$ kubectl get pod -n demo mssqlserver-ag-cluster-1 -o json | jq '.spec.containers[0].resources' +{ + "limits": { + "cpu": "600m", + "memory": "1717986918400m" + }, + "requests": { + "cpu": "500m", + "memory": "1536Mi" + } +} +$ kubectl get pod -n demo mssqlserver-ag-cluster-2 -o json | jq '.spec.containers[0].resources' +{ + "limits": { + "cpu": "600m", + "memory": "1717986918400m" + }, + "requests": { + "cpu": "500m", + "memory": "1536Mi" + } +} +``` + + +You can see from the above outputs that the resources are same as the one we have assigned while deploying the mssqlserver. + +We are now ready to apply the `MSSQLServerAutoscaler` CRO to set up autoscaling for this database. + +### Compute Resource Autoscaling + +Here, we are going to set up compute resource autoscaling using a `MSSQLServerAutoscaler` Object. + +#### Create MSSQLServerAutoscaler Object + +In order to set up compute resource autoscaling for this database cluster, we have to create a `MSSQLServerAutoscaler` CRO with our desired configuration. Below is the YAML of the `MSSQLServerAutoscaler` object that we are going to create, + +```yaml +apiVersion: autoscaling.kubedb.com/v1alpha1 +kind: MSSQLServerAutoscaler +metadata: + name: ms-as-compute + namespace: demo +spec: + databaseRef: + name: mssqlserver-ag-cluster + opsRequestOptions: + timeout: 5m + apply: IfReady + compute: + mssqlserver: + trigger: "On" + podLifeTimeThreshold: 5m + resourceDiffPercentage: 10 + minAllowed: + cpu: 800m + memory: 2Gi + maxAllowed: + cpu: 1 + memory: 3Gi + containerControlledValues: "RequestsAndLimits" + controlledResources: ["cpu", "memory"] +``` + +Here, + +- `spec.databaseRef.name` specifies that we are performing compute resource scaling operation on `mssqlserver-ag-cluster` database. +- `spec.compute.mssqlserver.trigger` specifies that compute autoscaling is enabled for this database. +- `spec.compute.mssqlserver.podLifeTimeThreshold` specifies the minimum lifetime for at least one of the pod to initiate a vertical scaling. +- `spec.compute.mssqlserver.resourceDiffPercentage` specifies the minimum resource difference in percentage. The default is 10%. + If the difference between current & recommended resource is less than ResourceDiffPercentage, Autoscaler Operator will ignore the updating. +- `spec.compute.mssqlserver.minAllowed` specifies the minimum allowed resources for the database. +- `spec.compute.mssqlserver.maxAllowed` specifies the maximum allowed resources for the database. +- `spec.compute.mssqlserver.controlledResources` specifies the resources that are controlled by the autoscaler. +- `spec.compute.mssqlserver.containerControlledValues` specifies which resource values should be controlled. The default is "RequestsAndLimits". +- `spec.opsRequestOptions.apply` has two supported value : `IfReady` & `Always`. + Use `IfReady` if you want to process the opsReq only when the database is Ready. And use `Always` if you want to process the execution of opsReq irrespective of the Database state. +- `spec.opsRequestOptions.timeout` specifies the maximum time for each step of the opsRequest(in seconds). + If a step doesn't finish within the specified timeout, the ops request will result in failure. + + +Let's create the `MSSQLServerAutoscaler` CR we have shown above, + +```bash +$ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/examples/mssqlserver/autoscaler/compute/ms-as-compute.yaml +mssqlserverautoscaler.autoscaling.kubedb.com/ms-as-compute created +``` + +#### Verify Autoscaling is set up successfully + +Let's check that the `mssqlserverautoscaler` resource is created successfully, + +```bash +$ kubectl get mssqlserverautoscaler -n demo +NAME AGE +ms-as-compute 16s + +$ kubectl describe mssqlserverautoscaler ms-as-compute -n demo +Name: ms-as-compute +Namespace: demo +Labels: +Annotations: +API Version: autoscaling.kubedb.com/v1alpha1 +Kind: MSSQLServerAutoscaler +Metadata: + Creation Timestamp: 2024-10-25T15:02:58Z + Generation: 1 + Resource Version: 106200 + UID: cc34737b-2e42-4b94-bcc4-cfcac98eb6a6 +Spec: + Compute: + Mssqlserver: + Container Controlled Values: RequestsAndLimits + Controlled Resources: + cpu + memory + Max Allowed: + Cpu: 1 + Memory: 3Gi + Min Allowed: + Cpu: 800m + Memory: 2Gi + Pod Life Time Threshold: 5m + Resource Diff Percentage: 10 + Trigger: On + Database Ref: + Name: mssqlserver-ag-cluster + Ops Request Options: + Apply: IfReady + Timeout: 5m +Status: + Checkpoints: + Cpu Histogram: + Bucket Weights: + Index: 0 + Weight: 524 + Index: 20 + Weight: 456 + Index: 28 + Weight: 2635 + Index: 34 + Weight: 455 + Index: 35 + Weight: 10000 + Index: 36 + Weight: 6980 + Reference Timestamp: 2024-10-25T15:10:00Z + Total Weight: 2.465794209092962 + First Sample Start: 2024-10-25T15:03:11Z + Last Sample Start: 2024-10-25T15:13:21Z + Last Update Time: 2024-10-25T15:13:34Z + Memory Histogram: + Bucket Weights: + Index: 36 + Weight: 10000 + Index: 37 + Weight: 5023 + Index: 39 + Weight: 5710 + Index: 40 + Weight: 2918 + Reference Timestamp: 2024-10-25T15:15:00Z + Total Weight: 2.8324869288693995 + Ref: + Container Name: mssql + Vpa Object Name: mssqlserver-ag-cluster + Total Samples Count: 30 + Version: v3 + Cpu Histogram: + Bucket Weights: + Index: 0 + Weight: 10000 + Index: 1 + Weight: 3741 + Index: 2 + Weight: 1924 + Reference Timestamp: 2024-10-25T15:10:00Z + Total Weight: 2.033798492571757 + First Sample Start: 2024-10-25T15:03:11Z + Last Sample Start: 2024-10-25T15:12:22Z + Last Update Time: 2024-10-25T15:12:34Z + Memory Histogram: + Bucket Weights: + Index: 3 + Weight: 1357 + Index: 4 + Weight: 10000 + Reference Timestamp: 2024-10-25T15:15:00Z + Total Weight: 2.8324869288693995 + Ref: + Container Name: mssql-coordinator + Vpa Object Name: mssqlserver-ag-cluster + Total Samples Count: 26 + Version: v3 + Conditions: + Last Transition Time: 2024-10-25T15:10:27Z + Message: Successfully created MSSQLServerOpsRequest demo/msops-mssqlserver-ag-cluster-v5xep9 + Observed Generation: 1 + Reason: CreateOpsRequest + Status: True + Type: CreateOpsRequest + Vpas: + Conditions: + Last Transition Time: 2024-10-25T15:03:34Z + Status: True + Type: RecommendationProvided + Recommendation: + Container Recommendations: + Container Name: mssql + Lower Bound: + Cpu: 844m + Memory: 2Gi + Target: + Cpu: 1 + Memory: 2Gi + Uncapped Target: + Cpu: 1168m + Memory: 1389197403 + Upper Bound: + Cpu: 1 + Memory: 3Gi + Container Name: mssql-coordinator + Lower Bound: + Cpu: 50m + Memory: 131072k + Target: + Cpu: 50m + Memory: 131072k + Uncapped Target: + Cpu: 50m + Memory: 131072k + Upper Bound: + Cpu: 4992m + Memory: 9063982612 + Vpa Name: mssqlserver-ag-cluster +Events: +``` +So, the `mssqlserverautoscaler` resource is created successfully. + +We can verify from the above output that `status.vpas` contains the `RecommendationProvided` condition to true. And in the same time, `status.vpas.recommendation.containerRecommendations` contain the actual generated recommendation. + +Our autoscaler operator continuously watches the recommendation generated and creates an `mssqlserveropsrequest` based on the recommendations, if the database pod resources are needed to scaled up or down. + +Let's watch the `mssqlserveropsrequest` in the demo namespace to see if any `mssqlserveropsrequest` object is created. After some time you'll see that a `mssqlserveropsrequest` will be created based on the recommendation. + +```bash +$ kubectl get mssqlserveropsrequest -n demo +NAME TYPE STATUS AGE +msops-mssqlserver-ag-cluster-6xc1kc VerticalScaling Progressing 7s +``` + +Let's wait for the ops request to become successful. + +```bash +$ kubectl get mssqlserveropsrequest -n demo +NAME TYPE STATUS AGE +msops-mssqlserver-ag-cluster-8li26q VerticalScaling Successful 11m +``` + +We can see from the above output that the `MSSQLServerOpsRequest` has succeeded. If we describe the `MSSQLServerOpsRequest` we will get an overview of the steps that were followed to scale the database. + +```bash +$ kubectl describe msops -n demo msops-mssqlserver-ag-cluster-8li26q +Name: msops-mssqlserver-ag-cluster-8li26q +Namespace: demo +Labels: app.kubernetes.io/component=database + app.kubernetes.io/instance=mssqlserver-ag-cluster + app.kubernetes.io/managed-by=kubedb.com + app.kubernetes.io/name=mssqlservers.kubedb.com +Annotations: +API Version: ops.kubedb.com/v1alpha1 +Kind: MSSQLServerOpsRequest +Metadata: + Creation Timestamp: 2024-10-25T15:04:27Z + Generation: 1 + Owner References: + API Version: autoscaling.kubedb.com/v1alpha1 + Block Owner Deletion: true + Controller: true + Kind: MSSQLServerAutoscaler + Name: ms-as-compute + UID: cc34737b-2e42-4b94-bcc4-cfcac98eb6a6 + Resource Version: 105300 + UID: b2f29a6a-f4cf-4c97-871c-f203e08af320 +Spec: + Apply: IfReady + Database Ref: + Name: mssqlserver-ag-cluster + Timeout: 5m0s + Type: VerticalScaling + Vertical Scaling: + Mssqlserver: + Resources: + Limits: + Cpu: 960m + Memory: 2290649225 + Requests: + Cpu: 800m + Memory: 2Gi +Status: + Conditions: + Last Transition Time: 2024-10-25T15:04:27Z + Message: MSSQLServer ops-request has started to vertically scaling the MSSQLServer nodes + Observed Generation: 1 + Reason: VerticalScaling + Status: True + Type: VerticalScaling + Last Transition Time: 2024-10-25T15:04:30Z + Message: Successfully paused database + Observed Generation: 1 + Reason: DatabasePauseSucceeded + Status: True + Type: DatabasePauseSucceeded + Last Transition Time: 2024-10-25T15:04:30Z + Message: Successfully updated PetSets Resources + Observed Generation: 1 + Reason: UpdatePetSets + Status: True + Type: UpdatePetSets + Last Transition Time: 2024-10-25T15:04:35Z + Message: get pod; ConditionStatus:True; PodName:mssqlserver-ag-cluster-0 + Observed Generation: 1 + Status: True + Type: GetPod--mssqlserver-ag-cluster-0 + Last Transition Time: 2024-10-25T15:04:35Z + Message: evict pod; ConditionStatus:True; PodName:mssqlserver-ag-cluster-0 + Observed Generation: 1 + Status: True + Type: EvictPod--mssqlserver-ag-cluster-0 + Last Transition Time: 2024-10-25T15:05:15Z + Message: check pod running; ConditionStatus:True; PodName:mssqlserver-ag-cluster-0 + Observed Generation: 1 + Status: True + Type: CheckPodRunning--mssqlserver-ag-cluster-0 + Last Transition Time: 2024-10-25T15:05:20Z + Message: get pod; ConditionStatus:True; PodName:mssqlserver-ag-cluster-1 + Observed Generation: 1 + Status: True + Type: GetPod--mssqlserver-ag-cluster-1 + Last Transition Time: 2024-10-25T15:05:20Z + Message: evict pod; ConditionStatus:True; PodName:mssqlserver-ag-cluster-1 + Observed Generation: 1 + Status: True + Type: EvictPod--mssqlserver-ag-cluster-1 + Last Transition Time: 2024-10-25T15:05:55Z + Message: check pod running; ConditionStatus:True; PodName:mssqlserver-ag-cluster-1 + Observed Generation: 1 + Status: True + Type: CheckPodRunning--mssqlserver-ag-cluster-1 + Last Transition Time: 2024-10-25T15:06:00Z + Message: get pod; ConditionStatus:True; PodName:mssqlserver-ag-cluster-2 + Observed Generation: 1 + Status: True + Type: GetPod--mssqlserver-ag-cluster-2 + Last Transition Time: 2024-10-25T15:06:00Z + Message: evict pod; ConditionStatus:True; PodName:mssqlserver-ag-cluster-2 + Observed Generation: 1 + Status: True + Type: EvictPod--mssqlserver-ag-cluster-2 + Last Transition Time: 2024-10-25T15:06:35Z + Message: check pod running; ConditionStatus:True; PodName:mssqlserver-ag-cluster-2 + Observed Generation: 1 + Status: True + Type: CheckPodRunning--mssqlserver-ag-cluster-2 + Last Transition Time: 2024-10-25T15:06:40Z + Message: Successfully Restarted Pods With Resources + Observed Generation: 1 + Reason: RestartPods + Status: True + Type: RestartPods + Last Transition Time: 2024-10-25T15:06:40Z + Message: Successfully completed the VerticalScaling for MSSQLServer + Observed Generation: 1 + Reason: Successful + Status: True + Type: Successful + Observed Generation: 1 + Phase: Successful +``` + +Now, we are going to verify from the Pod, and the MSSQLServer yaml whether the resources of the cluster database has updated to meet up the desired state, Let's check, + +```bash +$ kubectl get pod -n demo mssqlserver-ag-cluster-0 -o json | jq '.spec.containers[0].resources' +{ + "limits": { + "cpu": "960m", + "memory": "2290649225" + }, + "requests": { + "cpu": "800m", + "memory": "2Gi" + } +} + +$ kubectl get ms -n demo mssqlserver-ag-cluster -o json | jq '.spec.podTemplate.spec.containers[] | select(.name == "mssql") | .resources' +{ + "limits": { + "cpu": "960m", + "memory": "2290649225" + }, + "requests": { + "cpu": "800m", + "memory": "2Gi" + } +} +``` + + +The above output verifies that we have successfully autoscaled the resources of the MSSQLServer cluster. + + +### Autoscaling for Standalone MSSQLServer +Autoscaling for Standalone MSSQLServer is exactly same as cluster mode. Just refer the standalone mssqlserver in `databaseRef` field of `MSSQLServerAutoscaler` spec. + +## Cleaning Up + +To clean up the Kubernetes resources created by this tutorial, run: + +```bash +kubectl delete mssqlserver -n demo mssqlserver-ag-cluster +kubectl delete mssqlserverautoscaler -n demo ms-as-compute +kubectl delete issuer -n demo mssqlserver-ca-issuer +kubectl delete secret -n demo mssqlserver-ca +kubectl delete ns demo +``` \ No newline at end of file diff --git a/docs/guides/mssqlserver/autoscaler/compute/overview.md b/docs/guides/mssqlserver/autoscaler/compute/overview.md new file mode 100644 index 0000000000..ac034a16bb --- /dev/null +++ b/docs/guides/mssqlserver/autoscaler/compute/overview.md @@ -0,0 +1,55 @@ +--- +title: MSSQLServer Compute Autoscaling Overview +menu: + docs_{{ .version }}: + identifier: ms-autoscaling-overview + name: Overview + parent: ms-compute-autoscaling + weight: 10 +menu_name: docs_{{ .version }} +section_menu_id: guides +--- + +> New to KubeDB? Please start [here](/docs/README.md). + +# MSSQLServer Compute Resource Autoscaling + +This guide will give an overview on how KubeDB Autoscaler operator autoscales the database compute resources i.e. cpu and memory using `MSSQLServerAutoscaler` crd. + +## Before You Begin + +- You should be familiar with the following `KubeDB` concepts: + - [MSSQLServer](/docs/guides/mssqlserver/concepts/mssqlserver.md) + - [MSSQLServerOpsRequest](/docs/guides/mssqlserver/concepts/opsrequest.md) + - [MSSQLServerAutoscaler](/docs/guides/mssqlserver/concepts/autoscaler.md) + +## How Compute Autoscaling Works + +The following diagram shows how KubeDB Autoscaler operator autoscales the resources of `MSSQLServer` database components. Open the image in a new tab to see the enlarged version. + +
+  Compute Auto Scaling process of MSSQLServer +
Fig: Compute Auto Scaling process of MSSQLServer
+
+ +The Auto Scaling process consists of the following steps: + +1. At first, a user creates a `MSSQLServer` Custom Resource Object (CRO). + +2. `KubeDB` Provisioner operator watches the `MSSQLServer` CRO. + +3. When the operator finds a `MSSQLServer` CRO, it creates required number of `PetSets` and related necessary stuff like secrets, services, etc. + +4. Then, in order to set up autoscaling of the `MSSQLServer` database the user creates a `MSSQLServerAutoscaler` CRO with desired configuration. + +5. `KubeDB` Autoscaler operator watches the `MSSQLServerAutoscaler` CRO. + +6. `KubeDB` Autoscaler operator generates recommendation using the modified version of kubernetes [official recommender](https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler/pkg/recommender) for different components of the database, as specified in the `MSSQLServerAutoscaler` CRO. + +7. If the generated recommendation doesn't match the current resources of the database, then `KubeDB` Autoscaler operator creates a `MSSQLServerOpsRequest` CRO to scale the database to match the recommendation generated. + +8. `KubeDB` Ops-manager operator watches the `MSSQLServerOpsRequest` CRO. + +9. Then the `KubeDB` Ops-manager operator will scale the database component vertically as specified on the `MSSQLServerOpsRequest` CRO. + +In the next docs, we are going to show a step-by-step guide on Autoscaling of various MSSQLServer database using `MSSQLServerAutoscaler` CRD. diff --git a/docs/guides/mssqlserver/autoscaler/storage/_index.md b/docs/guides/mssqlserver/autoscaler/storage/_index.md new file mode 100644 index 0000000000..58a3cd83a4 --- /dev/null +++ b/docs/guides/mssqlserver/autoscaler/storage/_index.md @@ -0,0 +1,10 @@ +--- +title: Storage Autoscaling +menu: + docs_{{ .version }}: + identifier: ms-storage-autoscaling + name: Storage Autoscaling + parent: ms-autoscaling + weight: 20 +menu_name: docs_{{ .version }} +--- diff --git a/docs/guides/mssqlserver/autoscaler/storage/cluster.md b/docs/guides/mssqlserver/autoscaler/storage/cluster.md new file mode 100644 index 0000000000..f95cf858f8 --- /dev/null +++ b/docs/guides/mssqlserver/autoscaler/storage/cluster.md @@ -0,0 +1,453 @@ +--- +title: MSSQLServer Cluster Autoscaling +menu: + docs_{{ .version }}: + identifier: ms-storage-autoscaling-cluster + name: Cluster + parent: ms-storage-autoscaling + weight: 20 +menu_name: docs_{{ .version }} +section_menu_id: guides +--- + +> New to KubeDB? Please start [here](/docs/README.md). + +# Storage Autoscaling of a MSSQLServer Availability Group Cluster + +This guide will show you how to use `KubeDB` to autoscale the storage of a MSSQLServer Availability Group Cluster. + +## Before You Begin + +- You need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. If you do not already have a cluster, you can create one by using [kind](https://kind.sigs.k8s.io/docs/user/quick-start/). + +- Now, install KubeDB cli on your workstation and KubeDB operator in your cluster following the steps [here](/docs/setup/README.md). Make sure install with helm command including `--set global.featureGates.MSSQLServer=true` to ensure MSSQLServer CRD installation. + +- To configure TLS/SSL in `MSSQLServer`, `KubeDB` uses `cert-manager` to issue certificates. So first you have to make sure that the cluster has `cert-manager` installed. To install `cert-manager` in your cluster following steps [here](https://cert-manager.io/docs/installation/kubernetes/). + +- Install `Metrics Server` from [here](https://github.com/kubernetes-sigs/metrics-server#installation) + +- Install Prometheus from [here](https://github.com/prometheus-community/helm-charts/tree/main/charts/kube-prometheus-stack) + +- You must have a `StorageClass` that supports volume expansion. + +- You should be familiar with the following `KubeDB` concepts: + - [MSSQLServer](/docs/guides/mssqlserver/concepts/mssqlserver.md) + - [MSSQLServerOpsRequest](/docs/guides/mssqlserver/concepts/opsrequest.md) + - [MSSQLServerAutoscaler](/docs/guides/mssqlserver/concepts/autoscaler.md) + - [Storage Autoscaling Overview](/docs/guides/mssqlserver/autoscaler/storage/overview.md) + +To keep everything isolated, we are going to use a separate namespace called `demo` throughout this tutorial. + +```bash +$ kubectl create ns demo +namespace/demo created +``` + +## Storage Autoscaling MSSQLServer Cluster + +At first verify that your cluster has a storage class, that supports volume expansion. Let's check, + +```bash +$ kubectl get storageclass +NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE +local-path (default) rancher.io/local-path Delete WaitForFirstConsumer false 4d21h +longhorn (default) driver.longhorn.io Delete Immediate true 2d20h +longhorn-static driver.longhorn.io Delete Immediate true 2d20h +``` + +We can see from the output the `longhorn` storage class has `ALLOWVOLUMEEXPANSION` field as true. So, this storage class supports volume expansion. We can use it. + +Now, we are going to deploy a `MSSQLServer` cluster using a supported version by `KubeDB` operator. Then we are going to apply `MSSQLServerAutoscaler` to set up autoscaling. + +#### Deploy MSSQLServer Cluster + +First, an issuer needs to be created, even if TLS is not enabled for SQL Server. The issuer will be used to configure the TLS-enabled Wal-G proxy server, which is required for the SQL Server backup and restore operations. + +### Create Issuer/ClusterIssuer + +Now, we are going to create an example `Issuer` that will be used throughout the duration of this tutorial. Alternatively, you can follow this [cert-manager tutorial](https://cert-manager.io/docs/configuration/ca/) to create your own `Issuer`. By following the below steps, we are going to create our desired issuer, + +- Start off by generating our ca-certificates using openssl, +```bash +openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout ./ca.key -out ./ca.crt -subj "/CN=MSSQLServer/O=kubedb" +``` +- Create a secret using the certificate files we have just generated, +```bash +$ kubectl create secret tls mssqlserver-ca --cert=ca.crt --key=ca.key --namespace=demo +secret/mssqlserver-ca created +``` +Now, we are going to create an `Issuer` using the `mssqlserver-ca` secret that contains the ca-certificate we have just created. Below is the YAML of the `Issuer` CR that we are going to create, + +```yaml +apiVersion: cert-manager.io/v1 +kind: Issuer +metadata: + name: mssqlserver-ca-issuer + namespace: demo +spec: + ca: + secretName: mssqlserver-ca +``` + +Let’s create the `Issuer` CR we have shown above, +```bash +$ kubectl create -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/examples/mssqlserver/ag-cluster/mssqlserver-ca-issuer.yaml +issuer.cert-manager.io/mssqlserver-ca-issuer created +``` + +Now, we are going to deploy a MSSQLServer cluster database with version `2022-cu12`. Then, in the next section we will set up autoscaling for this database using `MSSQLServerAutoscaler` CRD. Below is the YAML of the `MSSQLServer` CR that we are going to create, + +> If you want to autoscale MSSQLServer `Standalone`, Just deploy a [standalone](/docs/guides/mssqlserver/clustering/standalone.md) sql server instance using KubeDB. + +```yaml +apiVersion: kubedb.com/v1alpha2 +kind: MSSQLServer +metadata: + name: mssqlserver-ag-cluster + namespace: demo +spec: + version: "2022-cu12" + replicas: 3 + topology: + mode: AvailabilityGroup + availabilityGroup: + databases: + - agdb1 + - agdb2 + internalAuth: + endpointCert: + issuerRef: + apiGroup: cert-manager.io + name: mssqlserver-ca-issuer + kind: Issuer + tls: + issuerRef: + name: mssqlserver-ca-issuer + kind: Issuer + apiGroup: "cert-manager.io" + clientTLS: false + podTemplate: + spec: + containers: + - name: mssql + resources: + requests: + cpu: "500m" + memory: "1.5Gi" + limits: + cpu: "600m" + memory: "1.6Gi" + storageType: Durable + storage: + storageClassName: "longhorn" + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + deletionPolicy: WipeOut +``` + +Let's create the `MSSQLServer` CRO we have shown above, + +```bash +$ kubectl create -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/examples/mssqlserver/autoscaler/storage/mssqlserver-ag-cluster.yaml +mssqlserver.kubedb.com/mssqlserver-ag-cluster created +``` + +Now, wait until `mssqlserver-ag-cluster` has status `Ready`. i.e, + +```bash +$ kubectl get mssqlserver -n demo +NAME VERSION STATUS AGE +mssqlserver-ag-cluster 2022-cu12 Ready 4m +``` + +Let's check volume size from petset, and from the persistent volume, + +```bash +$ kubectl get petset -n demo mssqlserver-ag-cluster -o json | jq '.spec.volumeClaimTemplates[].spec.resources.requests.storage' +"1Gi" + +$ kubectl get pv -n demo +NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS VOLUMEATTRIBUTESCLASS REASON AGE +pvc-1497dd6d-9cbd-467a-8e0c-c3963ce09e1b 1Gi RWO Delete Bound demo/data-mssqlserver-ag-cluster-1 longhorn 8m +pvc-37a7bc8d-2c04-4eb4-8e53-e610fd1daaf5 1Gi RWO Delete Bound demo/data-mssqlserver-ag-cluster-0 longhorn 8m +pvc-817866af-5277-4d51-8d81-434e8ec1c442 1Gi RWO Delete Bound demo/data-mssqlserver-ag-cluster-2 longhorn 8m +``` + +You can see the petset has 1GB storage, and the capacity of all the persistent volume is also 1GB. + +We are now ready to apply the `MSSQLServerAutoscaler` CRO to set up storage autoscaling for this database. + +### Storage Autoscaling + +Here, we are going to set up storage autoscaling using a `MSSQLServerAutoscaler` Object. + +#### Create MSSQLServerAutoscaler Object + +In order to set up storage autoscaling for this database cluster, we have to create a `MSSQLServerAutoscaler` CRO with our desired configuration. Below is the YAML of the `MSSQLServerAutoscaler` object that we are going to create, + +```yaml +apiVersion: autoscaling.kubedb.com/v1alpha1 +kind: MSSQLServerAutoscaler +metadata: + name: ms-as-storage + namespace: demo +spec: + databaseRef: + name: mssqlserver-ag-cluster + storage: + mssqlserver: + trigger: "On" + usageThreshold: 60 + scalingThreshold: 50 + expansionMode: "Offline" + upperBound: "100Gi" +``` + +Here, + +- `spec.databaseRef.name` specifies that we are performing volume expansion operation on `mssqlserver-ag-cluster` database. +- `spec.storage.mssqlserver.trigger` specifies that storage autoscaling is enabled for this database. +- `spec.storage.mssqlserver.usageThreshold` specifies storage usage threshold, if storage usage exceeds `60%` then storage autoscaling will be triggered. +- `spec.storage.mssqlserver.scalingThreshold` specifies the scaling threshold. Storage will be scaled to `50%` of the current amount. +- `spec.storage.mssqlserver.expansionMode` specifies the expansion mode of volume expansion `MSSQLServerOpsRequest` created by `MSSQLServerAutoscaler`, `longhorn` supports offline volume expansion so here `expansionMode` is set as "Offline". + +Let's create the `MSSQLServerAutoscaler` CR we have shown above, + +```bash +$ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/examples/mssqlserver/autoscaler/storage/ms-as-storage.yaml +mssqlserverautoscaler.autoscaling.kubedb.com/ms-as-storage created +``` + +#### Storage Autoscaling is set up successfully + +Let's check that the `mssqlserverautoscaler` resource is created successfully, + +```bash +$ kubectl get mssqlserverautoscaler -n demo +NAME AGE +ms-as-storage 17s + + +$ kubectl describe mssqlserverautoscaler ms-as-storage -n demo +Name: ms-as-storage +Namespace: demo +Labels: +Annotations: +API Version: autoscaling.kubedb.com/v1alpha1 +Kind: MSSQLServerAutoscaler +Metadata: + Creation Timestamp: 2024-11-01T09:39:54Z + Generation: 1 + Resource Version: 922388 + UID: 1e239b31-c6c8-4e2c-8cf6-2b95a88b9d45 +Spec: + Database Ref: + Name: mssqlserver-ag-cluster + Ops Request Options: + Apply: IfReady + Storage: + Mssqlserver: + Expansion Mode: Offline + Scaling Rules: + Applies Upto: + Threshold: 50pc + Scaling Threshold: 50 + Trigger: On + Upper Bound: 100Gi + Usage Threshold: 60 +Events: +``` + +So, the `mssqlserverautoscaler` resource is created successfully. + +Now, for this demo, we are going to manually fill up the persistent volume to exceed the `usageThreshold` using `dd` command to see storage autoscaling. + +Lets exec into the database pod and fill the database volume(`/var/opt/mssql/`) using the following commands: + +```bash +$ kubectl exec -it -n demo mssqlserver-ag-cluster-0 -c mssql -- bash +mssql@mssqlserver-ag-cluster-0:/$ df -h /var/opt/mssql +Filesystem Size Used Avail Use% Mounted on +/dev/longhorn/pvc-37a7bc8d-2c04-4eb4-8e53-e610fd1daaf5 974M 274M 685M 29% /var/opt/mssql + +mssql@mssqlserver-ag-cluster-0:/$ dd if=/dev/zero of=/var/opt/mssql/file.img bs=120M count=5 +5+0 records in +5+0 records out +629145600 bytes (629 MB, 600 MiB) copied, 6.09315 s, 103 MB/s +mssql@mssqlserver-ag-cluster-0:/$ df -h /var/opt/mssql +Filesystem Size Used Avail Use% Mounted on +/dev/longhorn/pvc-37a7bc8d-2c04-4eb4-8e53-e610fd1daaf5 974M 874M 85M 92% /var/opt/mssql +``` + +So, from the above output we can see that the storage usage is 92%, which exceeded the `usageThreshold` 60%. + +Let's watch the `mssqlserveropsrequest` in the demo namespace to see if any `mssqlserveropsrequest` object is created. After some time you'll see that a `mssqlserveropsrequest` of type `VolumeExpansion` will be created based on the `scalingThreshold`. + + +```bash +$ watch kubectl get mssqlserveropsrequest -n demo +NAME TYPE STATUS AGE +msops-mssqlserver-ag-cluster-8m7l5s VolumeExpansion Progressing 2m20s +``` + +Let's wait for the ops request to become successful. + +```bash +$ kubectl get mssqlserveropsrequest -n demo +NAME TYPE STATUS AGE +msops-mssqlserver-ag-cluster-8m7l5s VolumeExpansion Successful 17m +``` + +We can see from the above output that the `MSSQLServerOpsRequest` has succeeded. If we describe the `MSSQLServerOpsRequest` we will get an overview of the steps that were followed to expand the volume of the database. + +```bash +$ kubectl describe mssqlserveropsrequest -n demo msops-mssqlserver-ag-cluster-8m7l5s +Name: msops-mssqlserver-ag-cluster-8m7l5s +Namespace: demo +Labels: app.kubernetes.io/component=database + app.kubernetes.io/instance=mssqlserver-ag-cluster + app.kubernetes.io/managed-by=kubedb.com + app.kubernetes.io/name=mssqlservers.kubedb.com +Annotations: +API Version: ops.kubedb.com/v1alpha1 +Kind: MSSQLServerOpsRequest +Metadata: + Creation Timestamp: 2024-11-01T09:40:05Z + Generation: 1 + Owner References: + API Version: autoscaling.kubedb.com/v1alpha1 + Block Owner Deletion: true + Controller: true + Kind: MSSQLServerAutoscaler + Name: ms-as-storage + UID: 1e239b31-c6c8-4e2c-8cf6-2b95a88b9d45 + Resource Version: 924068 + UID: d0dfbe3d-4f0f-43ec-bdff-6d9f3fa96516 +Spec: + Apply: IfReady + Database Ref: + Name: mssqlserver-ag-cluster + Type: VolumeExpansion + Volume Expansion: + Mode: Offline + Mssqlserver: 1531054080 +Status: + Conditions: + Last Transition Time: 2024-11-01T09:40:05Z + Message: MSSQLServer ops-request has started to expand volume of mssqlserver nodes. + Observed Generation: 1 + Reason: VolumeExpansion + Status: True + Type: VolumeExpansion + Last Transition Time: 2024-11-01T09:40:13Z + Message: get petset; ConditionStatus:True + Observed Generation: 1 + Status: True + Type: GetPetset + Last Transition Time: 2024-11-01T09:40:13Z + Message: delete petset; ConditionStatus:True + Observed Generation: 1 + Status: True + Type: DeletePetset + Last Transition Time: 2024-11-01T09:40:23Z + Message: successfully deleted the petSets with orphan propagation policy + Observed Generation: 1 + Reason: OrphanPetSetPods + Status: True + Type: OrphanPetSetPods + Last Transition Time: 2024-11-01T09:46:48Z + Message: get pod; ConditionStatus:True + Observed Generation: 1 + Status: True + Type: GetPod + Last Transition Time: 2024-11-01T09:40:28Z + Message: patch ops request; ConditionStatus:True + Observed Generation: 1 + Status: True + Type: PatchOpsRequest + Last Transition Time: 2024-11-01T09:40:28Z + Message: delete pod; ConditionStatus:True + Observed Generation: 1 + Status: True + Type: DeletePod + Last Transition Time: 2024-11-01T09:41:03Z + Message: get pvc; ConditionStatus:True + Observed Generation: 1 + Status: True + Type: GetPvc + Last Transition Time: 2024-11-01T09:41:03Z + Message: patch pvc; ConditionStatus:True + Observed Generation: 1 + Status: True + Type: PatchPvc + Last Transition Time: 2024-11-01T09:48:33Z + Message: compare storage; ConditionStatus:True + Observed Generation: 1 + Status: True + Type: CompareStorage + Last Transition Time: 2024-11-01T09:42:48Z + Message: create pod; ConditionStatus:True + Observed Generation: 1 + Status: True + Type: CreatePod + Last Transition Time: 2024-11-01T09:42:53Z + Message: running mssql server; ConditionStatus:False + Observed Generation: 1 + Status: False + Type: RunningMssqlServer + Last Transition Time: 2024-11-01T09:48:58Z + Message: successfully updated node PVC sizes + Observed Generation: 1 + Reason: UpdateNodePVCs + Status: True + Type: UpdateNodePVCs + Last Transition Time: 2024-11-01T09:49:03Z + Message: successfully reconciled the MSSQLServer resources + Observed Generation: 1 + Reason: UpdatePetSets + Status: True + Type: UpdatePetSets + Last Transition Time: 2024-11-01T09:49:03Z + Message: PetSet is recreated + Observed Generation: 1 + Reason: ReadyPetSets + Status: True + Type: ReadyPetSets + Last Transition Time: 2024-11-01T09:49:03Z + Message: Successfully completed volumeExpansion for MSSQLServer + Observed Generation: 1 + Reason: Successful + Status: True + Type: Successful + Observed Generation: 1 + Phase: Successful +``` + +Now, we are going to verify from the `Petset`, and the `Persistent Volumes` whether the volume of the database has expanded to meet the desired state, Let's check, + +```bash +$ kubectl get petset -n demo mssqlserver-ag-cluster -o json | jq '.spec.volumeClaimTemplates[].spec.resources.requests.storage' +"1531054080" +$ kubectl get pv -n demo +NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS VOLUMEATTRIBUTESCLASS REASON AGE +pvc-2ff83356-1bbc-44ab-99f1-025e3690a471 1462Mi RWO Delete Bound demo/data-mssqlserver-ag-cluster-2 longhorn 15m +pvc-a5cc0ae9-2c8d-456c-ace2-fc4fafc6784f 1462Mi RWO Delete Bound demo/data-mssqlserver-ag-cluster-1 longhorn 16m +pvc-e8ab47a4-17a6-45fb-9f39-e71a03498ab5 1462Mi RWO Delete Bound demo/data-mssqlserver-ag-cluster-0 longhorn 16m +``` + +The above output verifies that we have successfully autoscaled the volume of the MSSQLServer cluster database. + +## Cleaning Up + +To clean up the Kubernetes resources created by this tutorial, run: + +```bash +kubectl delete mssqlserver -n demo mssqlserver-ag-cluster +kubectl delete mssqlserverautoscaler -n demo ms-as-storage +kubectl delete issuer -n demo mssqlserver-ca-issuer +kubectl delete secret -n demo mssqlserver-ca +kubectl delete ns demo +``` diff --git a/docs/guides/mssqlserver/autoscaler/storage/overview.md b/docs/guides/mssqlserver/autoscaler/storage/overview.md new file mode 100644 index 0000000000..2e537cb4f9 --- /dev/null +++ b/docs/guides/mssqlserver/autoscaler/storage/overview.md @@ -0,0 +1,57 @@ +--- +title: MSSQLServer Storage Autoscaling Overview +menu: + docs_{{ .version }}: + identifier: ms-storage-autoscaling-overview + name: Overview + parent: ms-storage-autoscaling + weight: 10 +menu_name: docs_{{ .version }} +section_menu_id: guides +--- + +> New to KubeDB? Please start [here](/docs/README.md). + +# MSSQLServer Storage Autoscaling + +This guide will give an overview on how KubeDB `Autoscaler` operator autoscales the database storage using `MSSQLServerAutoscaler` CRD. + +## Before You Begin + +- You should be familiar with the following `KubeDB` concepts: + - [MSSQLServer](/docs/guides/mssqlserver/concepts/mssqlserver.md) + - [MSSQLServerOpsRequest](/docs/guides/mssqlserver/concepts/opsrequest.md) + - [MSSQLServerAutoscaler](/docs/guides/mssqlserver/concepts/autoscaler.md) + +## How Storage Autoscaling Works + +The following diagram shows how KubeDB Autoscaler operator autoscales the resources of `MSSQLServer`. Open the image in a new tab to see the enlarged version. + +
+  Storage Auto Scaling process of MSSQLServer +
Fig: Storage Auto Scaling process of MSSQLServer
+
+ + +The Auto Scaling process consists of the following steps: + +1. At first, a user creates a `MSSQLServer` Custom Resource (CR). + +2. `KubeDB` Provisioner operator watches the `MSSQLServer` CR. + +3. When the operator finds a `MSSQLServer` CR, it creates required number of `PetSets` and related necessary stuff like secrets, services, etc. + +4. Each PetSet creates a Persistent Volumes according to the Volume Claim Template provided in the petset's configuration. + +5. Then, in order to set up storage autoscaling of the `MSSQLServer` database the user creates a `MSSQLServerAutoscaler` CRO with desired configuration. + +6. `KubeDB` Autoscaler operator watches the `MSSQLServerAutoscaler` CRO. + +7. `KubeDB` Autoscaler operator continuously watches persistent volumes of the databases to check if it exceeds the specified usage threshold. +8. If the usage exceeds the specified usage threshold, then `KubeDB` Autoscaler operator creates a `MSSQLServerOpsRequest` to expand the storage of the database. + +9. `KubeDB` Ops-manager operator watches the `MSSQLServerOpsRequest` CRO. + +10. Then the `KubeDB` Ops-manager operator will expand the storage of the database as specified on the `MSSQLServerOpsRequest` CRO. + +In the next docs, we are going to show a step-by-step guide on Autoscaling storage of MSSQLServer database using `MSSQLServerAutoscaler` CRD. diff --git a/docs/guides/mssqlserver/concepts/autoscaler.md b/docs/guides/mssqlserver/concepts/autoscaler.md new file mode 100644 index 0000000000..60294932bc --- /dev/null +++ b/docs/guides/mssqlserver/concepts/autoscaler.md @@ -0,0 +1,108 @@ +--- +title: MSSQLServerAutoscaler CRD +menu: + docs_{{ .version }}: + identifier: ms-concepts-autoscaler + name: MSSQLServerAutoscaler + parent: ms-concepts + weight: 30 +menu_name: docs_{{ .version }} +section_menu_id: guides +--- + +> New to KubeDB? Please start [here](/docs/README.md). + +# MSSQLServerAutoscaler + +## What is MSSQLServerAutoscaler + +`MSSQLServerAutoscaler` is a Kubernetes `Custom Resource Definitions` (CRD). It provides a declarative configuration for autoscaling [Microsoft SQL Server](https://learn.microsoft.com/en-us/sql/sql-server/) compute resources and storage of database in a Kubernetes native way. + +## MSSQLServerAutoscaler CRD Specifications + +Like any official Kubernetes resource, a `MSSQLServerAutoscaler` has `TypeMeta`, `ObjectMeta`, `Spec` and `Status` sections. + +Here is a sample `MSSQLServerAutoscaler` CRO for autoscaling is given below: + +**Sample `MSSQLServerAutoscaler` for mssqlserver database:** + +```yaml +apiVersion: autoscaling.kubedb.com/v1alpha1 +kind: MSSQLServerAutoscaler +metadata: + name: standalone-autoscaler + namespace: demo +spec: + databaseRef: + name: mssqlserver-standalone + opsRequestOptions: + apply: IfReady + timeout: 5m + compute: + mssqlserver: + trigger: "On" + podLifeTimeThreshold: 5m + minAllowed: + cpu: 800m + memory: 2Gi + maxAllowed: + cpu: 2 + memory: 4Gi + controlledResources: ["cpu", "memory"] + containerControlledValues: "RequestsAndLimits" + resourceDiffPercentage: 10 + storage: + mssqlserver: + expansionMode: "Online" + trigger: "On" + usageThreshold: 60 + scalingThreshold: 50 +``` + +Here, we are going to describe the various sections of a `MSSQLServerAutoscaler` CRD. + +A `MSSQLServerAutoscaler` object has the following fields in the `spec` section. + +### spec.databaseRef + +`spec.databaseRef` is a required field that point to the [MSSQLServer](/docs/guides/mssqlserver/concepts/mssqlserver.md) object for which the autoscaling will be performed. This field consists of the following sub-field: + +- **spec.databaseRef.name :** specifies the name of the [MSSQLServer](/docs/guides/mssqlserver/concepts/mssqlserver.md) object. + +### spec.opsRequestOptions +These are the options to pass in the internally created opsRequest CRO. `opsRequestOptions` has two fields. They have been described in details [here](/docs/guides/mssqlserver/concepts/opsrequest.md#spectimeout). + +### spec.compute + +`spec.compute` specifies the autoscaling configuration for to compute resources i.e. cpu and memory of the database. This field consists of the following sub-field: + +- `spec.compute.mssqlserver` indicates the desired compute autoscaling configuration for a MSSQLServer database. + +This has the following sub-fields: + +- `trigger` indicates if compute autoscaling is enabled for the database. If "On" then compute autoscaling is enabled. If "Off" then compute autoscaling is disabled. +- `minAllowed` specifies the minimal amount of resources that will be recommended, default is no minimum. +- `maxAllowed` specifies the maximum amount of resources that will be recommended, default is no maximum. +- `controlledResources` specifies which type of compute resources (cpu and memory) are allowed for autoscaling. Allowed values are "cpu" and "memory". +- `containerControlledValues` specifies which resource values should be controlled. Allowed values are "RequestsAndLimits" and "RequestsOnly". +- `resourceDiffPercentage` specifies the minimum resource difference between recommended value and the current value in percentage. If the difference percentage is greater than this value than autoscaling will be triggered. +- `podLifeTimeThreshold` specifies the minimum pod lifetime of at least one of the pods before triggering autoscaling. + +### spec.storage + +`spec.storage` specifies the autoscaling configuration for the storage resources of the database. This field consists of the following sub-field: + +- `spec.storage.mssqlserver` indicates the desired storage autoscaling configuration for a MSSQLServer database. + + It has the following sub-fields: + +- `trigger` indicates if storage autoscaling is enabled for the database. If "On" then storage autoscaling is enabled. If "Off" then storage autoscaling is disabled. +- `usageThreshold` indicates usage percentage threshold, if the current storage usage exceeds then storage autoscaling will be triggered. +- `scalingThreshold` indicates the percentage of the current storage that will be scaled. +- `expansionMode` indicates the volume expansion mode. + +## Next Steps + +- Learn about [backup and restore](/docs/guides/mssqlserver/backup/overview/index.md) SQL Server using KubeStash. +- Learn about MSSQLServer CRD [here](/docs/guides/mssqlserver/concepts/mssqlserver.md). +- Deploy your first MSSQLServer database with MSSQLServer by following the guide [here](/docs/guides/mssqlserver/quickstart/quickstart.md). diff --git a/docs/images/mssqlserver/ms-compute-autoscaling.png b/docs/images/mssqlserver/ms-compute-autoscaling.png new file mode 100644 index 0000000000..ad4de5e7f3 Binary files /dev/null and b/docs/images/mssqlserver/ms-compute-autoscaling.png differ diff --git a/docs/images/mssqlserver/ms-storage-autoscaling.png b/docs/images/mssqlserver/ms-storage-autoscaling.png new file mode 100644 index 0000000000..633350be56 Binary files /dev/null and b/docs/images/mssqlserver/ms-storage-autoscaling.png differ