diff --git a/content/docs/v2024.9.30/examples/mssqlserver/autoscaler/compute/ms-as-compute.yaml b/content/docs/v2024.9.30/examples/mssqlserver/autoscaler/compute/ms-as-compute.yaml new file mode 100644 index 0000000000..8bb784d2be --- /dev/null +++ b/content/docs/v2024.9.30/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/content/docs/v2024.9.30/examples/mssqlserver/autoscaler/compute/mssqlserver-ag-cluster.yaml b/content/docs/v2024.9.30/examples/mssqlserver/autoscaler/compute/mssqlserver-ag-cluster.yaml new file mode 100644 index 0000000000..c43e3b77d1 --- /dev/null +++ b/content/docs/v2024.9.30/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/content/docs/v2024.9.30/examples/mssqlserver/autoscaler/storage/ms-as-storage.yaml b/content/docs/v2024.9.30/examples/mssqlserver/autoscaler/storage/ms-as-storage.yaml new file mode 100644 index 0000000000..796ae16d9a --- /dev/null +++ b/content/docs/v2024.9.30/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/content/docs/v2024.9.30/examples/mssqlserver/autoscaler/storage/mssqlserver-ag-cluster.yaml b/content/docs/v2024.9.30/examples/mssqlserver/autoscaler/storage/mssqlserver-ag-cluster.yaml new file mode 100644 index 0000000000..c43e3b77d1 --- /dev/null +++ b/content/docs/v2024.9.30/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/content/docs/v2024.9.30/examples/mssqlserver/monitoring/mssql-monitoring.yaml b/content/docs/v2024.9.30/examples/mssqlserver/monitoring/mssql-monitoring.yaml new file mode 100644 index 0000000000..da1027aa74 --- /dev/null +++ b/content/docs/v2024.9.30/examples/mssqlserver/monitoring/mssql-monitoring.yaml @@ -0,0 +1,48 @@ +apiVersion: kubedb.com/v1alpha2 +kind: MSSQLServer +metadata: + name: mssql-monitoring + namespace: demo +spec: + version: "2022-cu12" + replicas: 1 + tls: + issuerRef: + name: mssqlserver-ca-issuer + kind: Issuer + apiGroup: "cert-manager.io" + clientTLS: false + monitor: + agent: prometheus.io/operator + prometheus: + exporter: + port: 9399 + resources: + limits: + memory: 512Mi + requests: + cpu: 200m + memory: 256Mi + securityContext: + allowPrivilegeEscalation: false + capabilities: + drop: + - ALL + runAsGroup: 10001 + runAsNonRoot: true + runAsUser: 10001 + seccompProfile: + type: RuntimeDefault + serviceMonitor: + interval: 10s + labels: + release: prometheus + storageType: Durable + storage: + storageClassName: standard + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + deletionPolicy: WipeOut \ No newline at end of file diff --git a/content/docs/v2024.9.30/examples/mssqlserver/restart/msops-restart.yaml b/content/docs/v2024.9.30/examples/mssqlserver/restart/msops-restart.yaml new file mode 100644 index 0000000000..cb6eea527d --- /dev/null +++ b/content/docs/v2024.9.30/examples/mssqlserver/restart/msops-restart.yaml @@ -0,0 +1,11 @@ +apiVersion: ops.kubedb.com/v1alpha1 +kind: MSSQLServerOpsRequest +metadata: + name: msops-restart + namespace: demo +spec: + type: Restart + databaseRef: + name: mssqlserver-ag-cluster + timeout: 3m + apply: Always \ No newline at end of file diff --git a/content/docs/v2024.9.30/examples/mssqlserver/restart/mssqlserver-ag-cluster.yaml b/content/docs/v2024.9.30/examples/mssqlserver/restart/mssqlserver-ag-cluster.yaml new file mode 100644 index 0000000000..12c229439e --- /dev/null +++ b/content/docs/v2024.9.30/examples/mssqlserver/restart/mssqlserver-ag-cluster.yaml @@ -0,0 +1,35 @@ +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 + storageType: Durable + storage: + storageClassName: "standard" + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + deletionPolicy: WipeOut diff --git a/content/docs/v2024.9.30/examples/mssqlserver/restart/mssqlserver-ca-issuer.yaml b/content/docs/v2024.9.30/examples/mssqlserver/restart/mssqlserver-ca-issuer.yaml new file mode 100644 index 0000000000..7a00e196d9 --- /dev/null +++ b/content/docs/v2024.9.30/examples/mssqlserver/restart/mssqlserver-ca-issuer.yaml @@ -0,0 +1,8 @@ +apiVersion: cert-manager.io/v1 +kind: Issuer +metadata: + name: mssqlserver-ca-issuer + namespace: demo +spec: + ca: + secretName: mssqlserver-ca \ No newline at end of file diff --git a/content/docs/v2024.9.30/examples/mssqlserver/scaling/horizontal-scaling/msops-hscale-down.yaml b/content/docs/v2024.9.30/examples/mssqlserver/scaling/horizontal-scaling/msops-hscale-down.yaml new file mode 100644 index 0000000000..750157bc24 --- /dev/null +++ b/content/docs/v2024.9.30/examples/mssqlserver/scaling/horizontal-scaling/msops-hscale-down.yaml @@ -0,0 +1,11 @@ +apiVersion: ops.kubedb.com/v1alpha1 +kind: MSSQLServerOpsRequest +metadata: + name: msops-hscale-down + namespace: demo +spec: + type: HorizontalScaling + databaseRef: + name: mssql-ag-cluster + horizontalScaling: + replicas: 2 \ No newline at end of file diff --git a/content/docs/v2024.9.30/examples/mssqlserver/scaling/horizontal-scaling/msops-hscale-up.yaml b/content/docs/v2024.9.30/examples/mssqlserver/scaling/horizontal-scaling/msops-hscale-up.yaml new file mode 100644 index 0000000000..3723dc67c1 --- /dev/null +++ b/content/docs/v2024.9.30/examples/mssqlserver/scaling/horizontal-scaling/msops-hscale-up.yaml @@ -0,0 +1,11 @@ +apiVersion: ops.kubedb.com/v1alpha1 +kind: MSSQLServerOpsRequest +metadata: + name: msops-hscale-up + namespace: demo +spec: + type: HorizontalScaling + databaseRef: + name: mssql-ag-cluster + horizontalScaling: + replicas: 3 \ No newline at end of file diff --git a/content/docs/v2024.9.30/examples/mssqlserver/scaling/horizontal-scaling/mssql-ag-cluster.yaml b/content/docs/v2024.9.30/examples/mssqlserver/scaling/horizontal-scaling/mssql-ag-cluster.yaml new file mode 100644 index 0000000000..449e0edf60 --- /dev/null +++ b/content/docs/v2024.9.30/examples/mssqlserver/scaling/horizontal-scaling/mssql-ag-cluster.yaml @@ -0,0 +1,46 @@ +apiVersion: kubedb.com/v1alpha2 +kind: MSSQLServer +metadata: + name: mssql-ag-cluster + namespace: demo +spec: + version: "2022-cu12" + replicas: 2 + 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: 1 + memory: "2Gi" + storageType: Durable + storage: + storageClassName: "standard" + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + deletionPolicy: WipeOut \ No newline at end of file diff --git a/content/docs/v2024.9.30/examples/mssqlserver/scaling/mssqlserver-ca-issuer.yaml b/content/docs/v2024.9.30/examples/mssqlserver/scaling/mssqlserver-ca-issuer.yaml new file mode 100644 index 0000000000..7a00e196d9 --- /dev/null +++ b/content/docs/v2024.9.30/examples/mssqlserver/scaling/mssqlserver-ca-issuer.yaml @@ -0,0 +1,8 @@ +apiVersion: cert-manager.io/v1 +kind: Issuer +metadata: + name: mssqlserver-ca-issuer + namespace: demo +spec: + ca: + secretName: mssqlserver-ca \ No newline at end of file diff --git a/content/docs/v2024.9.30/examples/mssqlserver/scaling/vertical-scaling/mops-vscale-ag-cluster.yaml b/content/docs/v2024.9.30/examples/mssqlserver/scaling/vertical-scaling/mops-vscale-ag-cluster.yaml new file mode 100644 index 0000000000..1fc44d9d49 --- /dev/null +++ b/content/docs/v2024.9.30/examples/mssqlserver/scaling/vertical-scaling/mops-vscale-ag-cluster.yaml @@ -0,0 +1,18 @@ +apiVersion: ops.kubedb.com/v1alpha1 +kind: MSSQLServerOpsRequest +metadata: + name: mops-vscale-ag-cluster + namespace: demo +spec: + type: VerticalScaling + databaseRef: + name: mssql-ag-cluster + verticalScaling: + mssqlserver: + resources: + requests: + memory: "1.7Gi" + cpu: "700m" + limits: + cpu: 2 + memory: "4Gi" \ No newline at end of file diff --git a/content/docs/v2024.9.30/examples/mssqlserver/scaling/vertical-scaling/mops-vscale-standalone.yaml b/content/docs/v2024.9.30/examples/mssqlserver/scaling/vertical-scaling/mops-vscale-standalone.yaml new file mode 100644 index 0000000000..9e5d64e8b6 --- /dev/null +++ b/content/docs/v2024.9.30/examples/mssqlserver/scaling/vertical-scaling/mops-vscale-standalone.yaml @@ -0,0 +1,17 @@ +apiVersion: ops.kubedb.com/v1alpha1 +kind: MSSQLServerOpsRequest +metadata: + name: mops-vscale-standalone + namespace: demo +spec: + type: VerticalScaling + databaseRef: + name: mssql-standalone + verticalScaling: + mssqlserver: + resources: + requests: + memory: "5Gi" + cpu: "1000m" + limits: + memory: "5Gi" \ No newline at end of file diff --git a/content/docs/v2024.9.30/examples/mssqlserver/scaling/vertical-scaling/mssql-ag-cluster.yaml b/content/docs/v2024.9.30/examples/mssqlserver/scaling/vertical-scaling/mssql-ag-cluster.yaml new file mode 100644 index 0000000000..1102b8f4fd --- /dev/null +++ b/content/docs/v2024.9.30/examples/mssqlserver/scaling/vertical-scaling/mssql-ag-cluster.yaml @@ -0,0 +1,46 @@ +apiVersion: kubedb.com/v1alpha2 +kind: MSSQLServer +metadata: + name: mssql-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: 1 + memory: "2Gi" + storageType: Durable + storage: + storageClassName: "standard" + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + deletionPolicy: WipeOut \ No newline at end of file diff --git a/content/docs/v2024.9.30/examples/mssqlserver/scaling/vertical-scaling/mssql-standalone.yaml b/content/docs/v2024.9.30/examples/mssqlserver/scaling/vertical-scaling/mssql-standalone.yaml new file mode 100644 index 0000000000..29629d28a1 --- /dev/null +++ b/content/docs/v2024.9.30/examples/mssqlserver/scaling/vertical-scaling/mssql-standalone.yaml @@ -0,0 +1,23 @@ +apiVersion: kubedb.com/v1alpha2 +kind: MSSQLServer +metadata: + name: mssql-standalone + namespace: demo +spec: + version: "2022-cu12" + replicas: 1 + storageType: Durable + tls: + issuerRef: + name: mssqlserver-ca-issuer + kind: Issuer + apiGroup: "cert-manager.io" + clientTLS: false + storage: + storageClassName: "standard" + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + deletionPolicy: WipeOut \ No newline at end of file diff --git a/content/docs/v2024.9.30/examples/mssqlserver/volume-expansion/mops-volume-exp-ag-cluster.yaml b/content/docs/v2024.9.30/examples/mssqlserver/volume-expansion/mops-volume-exp-ag-cluster.yaml new file mode 100644 index 0000000000..c02c193fe1 --- /dev/null +++ b/content/docs/v2024.9.30/examples/mssqlserver/volume-expansion/mops-volume-exp-ag-cluster.yaml @@ -0,0 +1,12 @@ +apiVersion: ops.kubedb.com/v1alpha1 +kind: MSSQLServerOpsRequest +metadata: + name: mops-volume-exp-ag-cluster + namespace: demo +spec: + type: VolumeExpansion + databaseRef: + name: mssqlserver-ag-cluster + volumeExpansion: + mode: "Offline" # Online + mssqlserver: 2Gi diff --git a/content/docs/v2024.9.30/examples/mssqlserver/volume-expansion/mssqlserver-ag-cluster.yaml b/content/docs/v2024.9.30/examples/mssqlserver/volume-expansion/mssqlserver-ag-cluster.yaml new file mode 100644 index 0000000000..c3f849b482 --- /dev/null +++ b/content/docs/v2024.9.30/examples/mssqlserver/volume-expansion/mssqlserver-ag-cluster.yaml @@ -0,0 +1,35 @@ +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 + storageType: Durable + storage: + storageClassName: "longhorn" + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + deletionPolicy: WipeOut \ No newline at end of file diff --git a/content/docs/v2024.9.30/guides/mongodb/backup/kubestash/auto-backup/examples/backupblueprint.yaml b/content/docs/v2024.9.30/guides/mongodb/backup/kubestash/auto-backup/examples/backupblueprint.yaml index dc02d18415..22bf8d23d2 100644 --- a/content/docs/v2024.9.30/guides/mongodb/backup/kubestash/auto-backup/examples/backupblueprint.yaml +++ b/content/docs/v2024.9.30/guides/mongodb/backup/kubestash/auto-backup/examples/backupblueprint.yaml @@ -33,4 +33,4 @@ spec: addon: name: mongodb-addon tasks: - - name: LogicalBackup \ No newline at end of file + - name: logical-backup \ No newline at end of file diff --git a/content/docs/v2024.9.30/guides/mongodb/backup/kubestash/auto-backup/index.md b/content/docs/v2024.9.30/guides/mongodb/backup/kubestash/auto-backup/index.md index 8d4d1aa9b3..bed32db112 100644 --- a/content/docs/v2024.9.30/guides/mongodb/backup/kubestash/auto-backup/index.md +++ b/content/docs/v2024.9.30/guides/mongodb/backup/kubestash/auto-backup/index.md @@ -180,7 +180,7 @@ spec: addon: name: mongodb-addon tasks: - - name: LogicalBackup + - name: logical-backup ``` Here, we define a template for `BackupConfiguration`. Notice the `backends` and `sessions` fields of `backupConfigurationTemplate` section. We have used some variables in form of `${VARIABLE_NAME}`. KubeStash will automatically resolve those variables from the database annotations information to make `BackupConfiguration` according to that databases need. @@ -280,7 +280,7 @@ spec: - addon: name: mongodb-addon tasks: - - name: LogicalBackup + - name: logical-backup failurePolicy: Fail name: frequent repositories: diff --git a/content/docs/v2024.9.30/guides/mongodb/backup/kubestash/customization/examples/backup/passing-args.yaml b/content/docs/v2024.9.30/guides/mongodb/backup/kubestash/customization/examples/backup/passing-args.yaml index c947f7428d..32271cbb29 100644 --- a/content/docs/v2024.9.30/guides/mongodb/backup/kubestash/customization/examples/backup/passing-args.yaml +++ b/content/docs/v2024.9.30/guides/mongodb/backup/kubestash/customization/examples/backup/passing-args.yaml @@ -33,6 +33,6 @@ spec: addon: name: mongodb-addon tasks: - - name: LogicalBackup + - name: logical-backup params: args: "--db=testdb" \ No newline at end of file diff --git a/content/docs/v2024.9.30/guides/mongodb/backup/kubestash/customization/examples/backup/resource-limit.yaml b/content/docs/v2024.9.30/guides/mongodb/backup/kubestash/customization/examples/backup/resource-limit.yaml index 9cb2794841..35f4a18b0d 100644 --- a/content/docs/v2024.9.30/guides/mongodb/backup/kubestash/customization/examples/backup/resource-limit.yaml +++ b/content/docs/v2024.9.30/guides/mongodb/backup/kubestash/customization/examples/backup/resource-limit.yaml @@ -33,7 +33,7 @@ spec: addon: name: mongodb-addon tasks: - - name: LogicalBackup + - name: logical-backup containerRuntimeSettings: resources: requests: diff --git a/content/docs/v2024.9.30/guides/mongodb/backup/kubestash/customization/examples/backup/specific-user.yaml b/content/docs/v2024.9.30/guides/mongodb/backup/kubestash/customization/examples/backup/specific-user.yaml index d3dcc848c5..f3359271ba 100644 --- a/content/docs/v2024.9.30/guides/mongodb/backup/kubestash/customization/examples/backup/specific-user.yaml +++ b/content/docs/v2024.9.30/guides/mongodb/backup/kubestash/customization/examples/backup/specific-user.yaml @@ -33,7 +33,7 @@ spec: addon: name: mongodb-addon tasks: - - name: LogicalBackup + - name: logical-backup jobTemplate: spec: securityContext: diff --git a/content/docs/v2024.9.30/guides/mongodb/backup/kubestash/customization/examples/restore/restore.yaml b/content/docs/v2024.9.30/guides/mongodb/backup/kubestash/customization/examples/restore/restore.yaml index 786b98395c..041bf890ad 100644 --- a/content/docs/v2024.9.30/guides/mongodb/backup/kubestash/customization/examples/restore/restore.yaml +++ b/content/docs/v2024.9.30/guides/mongodb/backup/kubestash/customization/examples/restore/restore.yaml @@ -18,7 +18,7 @@ spec: addon: name: mongodb-addon tasks: - - name: LogicalBackupRestoress + - name: logical-backup-restore jobTemplate: spec: securityContext: diff --git a/content/docs/v2024.9.30/guides/mongodb/backup/kubestash/customization/index.md b/content/docs/v2024.9.30/guides/mongodb/backup/kubestash/customization/index.md index 302e5639ee..97e67b4cb4 100644 --- a/content/docs/v2024.9.30/guides/mongodb/backup/kubestash/customization/index.md +++ b/content/docs/v2024.9.30/guides/mongodb/backup/kubestash/customization/index.md @@ -72,7 +72,7 @@ spec: addon: name: mongodb-addon tasks: - - name: LogicalBackup + - name: logical-backup params: args: "--db=testdb" ``` @@ -119,7 +119,7 @@ spec: addon: name: mongodb-addon tasks: - - name: LogicalBackup + - name: logical-backup jobTemplate: spec: securityContext: @@ -167,7 +167,7 @@ spec: addon: name: mongodb-addon tasks: - - name: LogicalBackup + - name: logical-backup containerRuntimeSettings: resources: requests: @@ -207,7 +207,7 @@ spec: addon: name: mongodb-addon tasks: - - name: LogicalBackupRestoress + - name: logical-backup-restore params: args: "--db=testdb" ``` @@ -246,7 +246,7 @@ spec: addon: name: mongodb-addon tasks: - - name: LogicalBackupRestoress + - name: logical-backup-restore ``` >Please, do not specify multiple snapshots here. Each snapshot represents a complete backup of your database. Multiple snapshots are only usable during file/directory restore. @@ -276,7 +276,7 @@ spec: addon: name: mongodb-addon tasks: - - name: LogicalBackupRestoress + - name: logical-backup-restore jobTemplate: spec: securityContext: @@ -309,7 +309,7 @@ spec: addon: name: mongodb-addon tasks: - - name: LogicalBackupRestoress + - name: logical-backup-restore containerRuntimeSettings: resources: requests: diff --git a/content/docs/v2024.9.30/guides/mongodb/backup/kubestash/logical/replicaset/examples/backupconfiguration-replicaset.yaml b/content/docs/v2024.9.30/guides/mongodb/backup/kubestash/logical/replicaset/examples/backupconfiguration-replicaset.yaml index aa9ada7a11..86a7bb5089 100644 --- a/content/docs/v2024.9.30/guides/mongodb/backup/kubestash/logical/replicaset/examples/backupconfiguration-replicaset.yaml +++ b/content/docs/v2024.9.30/guides/mongodb/backup/kubestash/logical/replicaset/examples/backupconfiguration-replicaset.yaml @@ -33,4 +33,4 @@ spec: addon: name: mongodb-addon tasks: - - name: LogicalBackup \ No newline at end of file + - name: logical-backup \ No newline at end of file diff --git a/content/docs/v2024.9.30/guides/mongodb/backup/kubestash/logical/replicaset/examples/restoresession-replicaset.yaml b/content/docs/v2024.9.30/guides/mongodb/backup/kubestash/logical/replicaset/examples/restoresession-replicaset.yaml index 56920b806c..d814bde882 100644 --- a/content/docs/v2024.9.30/guides/mongodb/backup/kubestash/logical/replicaset/examples/restoresession-replicaset.yaml +++ b/content/docs/v2024.9.30/guides/mongodb/backup/kubestash/logical/replicaset/examples/restoresession-replicaset.yaml @@ -18,4 +18,4 @@ spec: addon: name: mongodb-addon tasks: - - name: LogicalBackupRestore \ No newline at end of file + - name: logical-backup-restore \ No newline at end of file diff --git a/content/docs/v2024.9.30/guides/mongodb/backup/kubestash/logical/replicaset/index.md b/content/docs/v2024.9.30/guides/mongodb/backup/kubestash/logical/replicaset/index.md index f51c514190..1b9260d2c8 100644 --- a/content/docs/v2024.9.30/guides/mongodb/backup/kubestash/logical/replicaset/index.md +++ b/content/docs/v2024.9.30/guides/mongodb/backup/kubestash/logical/replicaset/index.md @@ -311,7 +311,7 @@ spec: addon: name: mongodb-addon tasks: - - name: LogicalBackup + - name: logical-backup ``` Here, @@ -519,7 +519,7 @@ spec: addon: name: mongodb-addon tasks: - - name: LogicalBackupRestore + - name: logical-backup-restore ``` Here, diff --git a/content/docs/v2024.9.30/guides/mongodb/backup/kubestash/logical/sharding/examples/backupconfiguration-sharding.yaml b/content/docs/v2024.9.30/guides/mongodb/backup/kubestash/logical/sharding/examples/backupconfiguration-sharding.yaml index 27389a4bcc..4c65fa04fb 100644 --- a/content/docs/v2024.9.30/guides/mongodb/backup/kubestash/logical/sharding/examples/backupconfiguration-sharding.yaml +++ b/content/docs/v2024.9.30/guides/mongodb/backup/kubestash/logical/sharding/examples/backupconfiguration-sharding.yaml @@ -33,4 +33,4 @@ spec: addon: name: mongodb-addon tasks: - - name: LogicalBackup \ No newline at end of file + - name: logical-backup \ No newline at end of file diff --git a/content/docs/v2024.9.30/guides/mongodb/backup/kubestash/logical/sharding/examples/restoresession-sharding.yaml b/content/docs/v2024.9.30/guides/mongodb/backup/kubestash/logical/sharding/examples/restoresession-sharding.yaml index d0d8614d7d..5d01e36384 100644 --- a/content/docs/v2024.9.30/guides/mongodb/backup/kubestash/logical/sharding/examples/restoresession-sharding.yaml +++ b/content/docs/v2024.9.30/guides/mongodb/backup/kubestash/logical/sharding/examples/restoresession-sharding.yaml @@ -18,4 +18,4 @@ spec: addon: name: mongodb-addon tasks: - - name: LogicalBackupRestore \ No newline at end of file + - name: logical-backup-restore \ No newline at end of file diff --git a/content/docs/v2024.9.30/guides/mongodb/backup/kubestash/logical/sharding/index.md b/content/docs/v2024.9.30/guides/mongodb/backup/kubestash/logical/sharding/index.md index 60cd31a68f..9d42d30ef0 100644 --- a/content/docs/v2024.9.30/guides/mongodb/backup/kubestash/logical/sharding/index.md +++ b/content/docs/v2024.9.30/guides/mongodb/backup/kubestash/logical/sharding/index.md @@ -319,7 +319,7 @@ spec: addon: name: mongodb-addon tasks: - - name: LogicalBackup + - name: logical-backup ``` Here, @@ -534,7 +534,7 @@ spec: addon: name: mongodb-addon tasks: - - name: LogicalBackupRestore + - name: logical-backup-restore ``` Here, diff --git a/content/docs/v2024.9.30/guides/mongodb/backup/kubestash/logical/standalone/examples/backupconfiguration.yaml b/content/docs/v2024.9.30/guides/mongodb/backup/kubestash/logical/standalone/examples/backupconfiguration.yaml index f4b7178ccb..395a8b05ba 100644 --- a/content/docs/v2024.9.30/guides/mongodb/backup/kubestash/logical/standalone/examples/backupconfiguration.yaml +++ b/content/docs/v2024.9.30/guides/mongodb/backup/kubestash/logical/standalone/examples/backupconfiguration.yaml @@ -33,4 +33,4 @@ spec: addon: name: mongodb-addon tasks: - - name: LogicalBackup \ No newline at end of file + - name: logical-backup \ No newline at end of file diff --git a/content/docs/v2024.9.30/guides/mongodb/backup/kubestash/logical/standalone/examples/restoresession.yaml b/content/docs/v2024.9.30/guides/mongodb/backup/kubestash/logical/standalone/examples/restoresession.yaml index 1020635be4..decae59096 100644 --- a/content/docs/v2024.9.30/guides/mongodb/backup/kubestash/logical/standalone/examples/restoresession.yaml +++ b/content/docs/v2024.9.30/guides/mongodb/backup/kubestash/logical/standalone/examples/restoresession.yaml @@ -18,4 +18,4 @@ spec: addon: name: mongodb-addon tasks: - - name: LogicalBackupRestore \ No newline at end of file + - name: logical-backup-restore \ No newline at end of file diff --git a/content/docs/v2024.9.30/guides/mongodb/backup/kubestash/logical/standalone/index.md b/content/docs/v2024.9.30/guides/mongodb/backup/kubestash/logical/standalone/index.md index d7d6b62bc9..1646e6596b 100644 --- a/content/docs/v2024.9.30/guides/mongodb/backup/kubestash/logical/standalone/index.md +++ b/content/docs/v2024.9.30/guides/mongodb/backup/kubestash/logical/standalone/index.md @@ -305,7 +305,7 @@ spec: addon: name: mongodb-addon tasks: - - name: LogicalBackup + - name: logical-backup ``` Here, @@ -512,7 +512,7 @@ spec: addon: name: mongodb-addon tasks: - - name: LogicalBackupRestore + - name: logical-backup-restore ``` Here, diff --git a/content/docs/v2024.9.30/guides/mssqlserver/autoscaler/_index.md b/content/docs/v2024.9.30/guides/mssqlserver/autoscaler/_index.md new file mode 100644 index 0000000000..c03115b970 --- /dev/null +++ b/content/docs/v2024.9.30/guides/mssqlserver/autoscaler/_index.md @@ -0,0 +1,22 @@ +--- +title: Autoscaling +menu: + docs_v2024.9.30: + identifier: ms-autoscaling + name: Autoscaling + parent: guides-mssqlserver + weight: 46 +menu_name: docs_v2024.9.30 +info: + autoscaler: v0.33.0 + cli: v0.48.0 + dashboard: v0.24.0 + installer: v2024.9.30 + ops-manager: v0.35.0 + provisioner: v0.48.0 + schema-manager: v0.24.0 + ui-server: v0.24.0 + version: v2024.9.30 + webhook-server: v0.24.0 +--- + diff --git a/content/docs/v2024.9.30/guides/mssqlserver/autoscaler/compute/_index.md b/content/docs/v2024.9.30/guides/mssqlserver/autoscaler/compute/_index.md new file mode 100644 index 0000000000..6069081ab6 --- /dev/null +++ b/content/docs/v2024.9.30/guides/mssqlserver/autoscaler/compute/_index.md @@ -0,0 +1,22 @@ +--- +title: Compute Autoscaling +menu: + docs_v2024.9.30: + identifier: ms-compute-autoscaling + name: Compute Autoscaling + parent: ms-autoscaling + weight: 10 +menu_name: docs_v2024.9.30 +info: + autoscaler: v0.33.0 + cli: v0.48.0 + dashboard: v0.24.0 + installer: v2024.9.30 + ops-manager: v0.35.0 + provisioner: v0.48.0 + schema-manager: v0.24.0 + ui-server: v0.24.0 + version: v2024.9.30 + webhook-server: v0.24.0 +--- + diff --git a/content/docs/v2024.9.30/guides/mssqlserver/autoscaler/compute/cluster.md b/content/docs/v2024.9.30/guides/mssqlserver/autoscaler/compute/cluster.md new file mode 100644 index 0000000000..586df8023b --- /dev/null +++ b/content/docs/v2024.9.30/guides/mssqlserver/autoscaler/compute/cluster.md @@ -0,0 +1,614 @@ +--- +title: MSSQLServer Availability Group Cluster Autoscaling +menu: + docs_v2024.9.30: + identifier: ms-autoscaling-cluster + name: Cluster + parent: ms-compute-autoscaling + weight: 20 +menu_name: docs_v2024.9.30 +section_menu_id: guides +info: + autoscaler: v0.33.0 + cli: v0.48.0 + dashboard: v0.24.0 + installer: v2024.9.30 + ops-manager: v0.35.0 + provisioner: v0.48.0 + schema-manager: v0.24.0 + ui-server: v0.24.0 + version: v2024.9.30 + webhook-server: v0.24.0 +--- + +> New to KubeDB? Please start [here](/docs/v2024.9.30/README). + +# 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/v2024.9.30/setup/README). 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/v2024.9.30/guides/mssqlserver/concepts/mssqlserver) + - [MSSQLServerOpsRequest](/docs/v2024.9.30/guides/mssqlserver/concepts/opsrequest) + - [Compute Resource Autoscaling Overview](/docs/v2024.9.30/guides/mssqlserver/autoscaler/compute/overview) + - [MSSQLServerAutoscaler](/docs/v2024.9.30/guides/mssqlserver/concepts/autoscaler) + +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/content/docs/v2024.9.30/guides/mssqlserver/autoscaler/compute/overview.md b/content/docs/v2024.9.30/guides/mssqlserver/autoscaler/compute/overview.md new file mode 100644 index 0000000000..a96a31440b --- /dev/null +++ b/content/docs/v2024.9.30/guides/mssqlserver/autoscaler/compute/overview.md @@ -0,0 +1,66 @@ +--- +title: MSSQLServer Compute Autoscaling Overview +menu: + docs_v2024.9.30: + identifier: ms-autoscaling-overview + name: Overview + parent: ms-compute-autoscaling + weight: 10 +menu_name: docs_v2024.9.30 +section_menu_id: guides +info: + autoscaler: v0.33.0 + cli: v0.48.0 + dashboard: v0.24.0 + installer: v2024.9.30 + ops-manager: v0.35.0 + provisioner: v0.48.0 + schema-manager: v0.24.0 + ui-server: v0.24.0 + version: v2024.9.30 + webhook-server: v0.24.0 +--- + +> New to KubeDB? Please start [here](/docs/v2024.9.30/README). + +# 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/v2024.9.30/guides/mssqlserver/concepts/mssqlserver) + - [MSSQLServerOpsRequest](/docs/v2024.9.30/guides/mssqlserver/concepts/opsrequest) + - [MSSQLServerAutoscaler](/docs/v2024.9.30/guides/mssqlserver/concepts/autoscaler) + +## 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/content/docs/v2024.9.30/guides/mssqlserver/autoscaler/storage/_index.md b/content/docs/v2024.9.30/guides/mssqlserver/autoscaler/storage/_index.md new file mode 100644 index 0000000000..1747f46ecb --- /dev/null +++ b/content/docs/v2024.9.30/guides/mssqlserver/autoscaler/storage/_index.md @@ -0,0 +1,22 @@ +--- +title: Storage Autoscaling +menu: + docs_v2024.9.30: + identifier: ms-storage-autoscaling + name: Storage Autoscaling + parent: ms-autoscaling + weight: 20 +menu_name: docs_v2024.9.30 +info: + autoscaler: v0.33.0 + cli: v0.48.0 + dashboard: v0.24.0 + installer: v2024.9.30 + ops-manager: v0.35.0 + provisioner: v0.48.0 + schema-manager: v0.24.0 + ui-server: v0.24.0 + version: v2024.9.30 + webhook-server: v0.24.0 +--- + diff --git a/content/docs/v2024.9.30/guides/mssqlserver/autoscaler/storage/cluster.md b/content/docs/v2024.9.30/guides/mssqlserver/autoscaler/storage/cluster.md new file mode 100644 index 0000000000..f3a96ed2dc --- /dev/null +++ b/content/docs/v2024.9.30/guides/mssqlserver/autoscaler/storage/cluster.md @@ -0,0 +1,464 @@ +--- +title: MSSQLServer Cluster Autoscaling +menu: + docs_v2024.9.30: + identifier: ms-storage-autoscaling-cluster + name: Cluster + parent: ms-storage-autoscaling + weight: 20 +menu_name: docs_v2024.9.30 +section_menu_id: guides +info: + autoscaler: v0.33.0 + cli: v0.48.0 + dashboard: v0.24.0 + installer: v2024.9.30 + ops-manager: v0.35.0 + provisioner: v0.48.0 + schema-manager: v0.24.0 + ui-server: v0.24.0 + version: v2024.9.30 + webhook-server: v0.24.0 +--- + +> New to KubeDB? Please start [here](/docs/v2024.9.30/README). + +# 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/v2024.9.30/setup/README). 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/v2024.9.30/guides/mssqlserver/concepts/mssqlserver) + - [MSSQLServerOpsRequest](/docs/v2024.9.30/guides/mssqlserver/concepts/opsrequest) + - [MSSQLServerAutoscaler](/docs/v2024.9.30/guides/mssqlserver/concepts/autoscaler) + - [Storage Autoscaling Overview](/docs/v2024.9.30/guides/mssqlserver/autoscaler/storage/overview) + +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/v2024.9.30/guides/mssqlserver/clustering/standalone) 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/content/docs/v2024.9.30/guides/mssqlserver/autoscaler/storage/overview.md b/content/docs/v2024.9.30/guides/mssqlserver/autoscaler/storage/overview.md new file mode 100644 index 0000000000..4dbb83f4d9 --- /dev/null +++ b/content/docs/v2024.9.30/guides/mssqlserver/autoscaler/storage/overview.md @@ -0,0 +1,68 @@ +--- +title: MSSQLServer Storage Autoscaling Overview +menu: + docs_v2024.9.30: + identifier: ms-storage-autoscaling-overview + name: Overview + parent: ms-storage-autoscaling + weight: 10 +menu_name: docs_v2024.9.30 +section_menu_id: guides +info: + autoscaler: v0.33.0 + cli: v0.48.0 + dashboard: v0.24.0 + installer: v2024.9.30 + ops-manager: v0.35.0 + provisioner: v0.48.0 + schema-manager: v0.24.0 + ui-server: v0.24.0 + version: v2024.9.30 + webhook-server: v0.24.0 +--- + +> New to KubeDB? Please start [here](/docs/v2024.9.30/README). + +# 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/v2024.9.30/guides/mssqlserver/concepts/mssqlserver) + - [MSSQLServerOpsRequest](/docs/v2024.9.30/guides/mssqlserver/concepts/opsrequest) + - [MSSQLServerAutoscaler](/docs/v2024.9.30/guides/mssqlserver/concepts/autoscaler) + +## 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/content/docs/v2024.9.30/guides/mssqlserver/clustering/ag_cluster.md b/content/docs/v2024.9.30/guides/mssqlserver/clustering/ag_cluster.md index 8ab2d4c612..4024fdf56d 100644 --- a/content/docs/v2024.9.30/guides/mssqlserver/clustering/ag_cluster.md +++ b/content/docs/v2024.9.30/guides/mssqlserver/clustering/ag_cluster.md @@ -873,6 +873,6 @@ If you are just testing some basic functionalities, you might want to avoid addi ## Next Steps - Learn about [backup and restore](/docs/v2024.9.30/guides/mssqlserver/backup/overview/) SQL Server using KubeStash. -- Want to set up SQL Server Availability Group clusters? Check how to [Configure SQL Server Availability Gruop Cluster](/docs/v2024.9.30/guides/mssqlserver/clustering/ag_cluster) -- Detail concepts of [MSSQLServer object](/docs/v2024.9.30/guides/mssqlserver/concepts/mssqlserver). +- Want to set up SQL Server Availability Group clusters? Check how to [Configure SQL Server Availability Group Cluster](/docs/v2024.9.30/guides/mssqlserver/clustering/ag_cluster) +- Detail concepts of [MSSQLServer Object](/docs/v2024.9.30/guides/mssqlserver/concepts/mssqlserver). - Want to hack on KubeDB? Check our [contribution guidelines](/docs/v2024.9.30/CONTRIBUTING). \ No newline at end of file diff --git a/content/docs/v2024.9.30/guides/mssqlserver/concepts/autoscaler.md b/content/docs/v2024.9.30/guides/mssqlserver/concepts/autoscaler.md new file mode 100644 index 0000000000..e72d254e52 --- /dev/null +++ b/content/docs/v2024.9.30/guides/mssqlserver/concepts/autoscaler.md @@ -0,0 +1,119 @@ +--- +title: MSSQLServerAutoscaler CRD +menu: + docs_v2024.9.30: + identifier: ms-concepts-autoscaler + name: MSSQLServerAutoscaler + parent: ms-concepts + weight: 30 +menu_name: docs_v2024.9.30 +section_menu_id: guides +info: + autoscaler: v0.33.0 + cli: v0.48.0 + dashboard: v0.24.0 + installer: v2024.9.30 + ops-manager: v0.35.0 + provisioner: v0.48.0 + schema-manager: v0.24.0 + ui-server: v0.24.0 + version: v2024.9.30 + webhook-server: v0.24.0 +--- + +> New to KubeDB? Please start [here](/docs/v2024.9.30/README). + +# 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/v2024.9.30/guides/mssqlserver/concepts/mssqlserver) 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/v2024.9.30/guides/mssqlserver/concepts/mssqlserver) 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/v2024.9.30/guides/mssqlserver/concepts/opsrequest#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/v2024.9.30/guides/mssqlserver/backup/overview/) SQL Server using KubeStash. +- Learn about MSSQLServer CRD [here](/docs/v2024.9.30/guides/mssqlserver/concepts/mssqlserver). +- Deploy your first MSSQLServer database with MSSQLServer by following the guide [here](/docs/v2024.9.30/guides/mssqlserver/quickstart/quickstart). diff --git a/content/docs/v2024.9.30/guides/mssqlserver/concepts/opsrequest.md b/content/docs/v2024.9.30/guides/mssqlserver/concepts/opsrequest.md new file mode 100644 index 0000000000..a08d194b0c --- /dev/null +++ b/content/docs/v2024.9.30/guides/mssqlserver/concepts/opsrequest.md @@ -0,0 +1,282 @@ +--- +title: MSSQLServerOpsRequest CRD +menu: + docs_v2024.9.30: + identifier: ms-concepts-ops-request + name: MSSQLServerOpsRequest + parent: ms-concepts + weight: 25 +menu_name: docs_v2024.9.30 +section_menu_id: guides +info: + autoscaler: v0.33.0 + cli: v0.48.0 + dashboard: v0.24.0 + installer: v2024.9.30 + ops-manager: v0.35.0 + provisioner: v0.48.0 + schema-manager: v0.24.0 + ui-server: v0.24.0 + version: v2024.9.30 + webhook-server: v0.24.0 +--- + +> New to KubeDB? Please start [here](/docs/v2024.9.30/README). + +# MSSQLServerOpsRequest + +## What is MSSQLServerOpsRequest + +`MSSQLServerOpsRequest` is a Kubernetes `Custom Resource Definitions` (CRD). It provides declarative configuration for [Microsoft SQL Server](https://learn.microsoft.com/en-us/sql/sql-server/) administrative operations like database version updating, horizontal scaling, vertical scaling, reconfigure, volume expansion, etc. in a Kubernetes native way. + +## MSSQLServerOpsRequest CRD Specifications + +Like any official Kubernetes resource, a `MSSQLServerOpsRequest` has `TypeMeta`, `ObjectMeta`, `Spec` and `Status` sections. + +Here, some sample `MSSQLServerOpsRequest` CR for different administrative operations are given below, + +Sample `MSSQLServerOpsRequest` for updating database: + +```yaml +apiVersion: ops.kubedb.com/v1alpha1 +kind: MSSQLServerOpsRequest +metadata: + name: update-ms-version + namespace: demo +spec: + type: UpdateVersion + databaseRef: + name: mssql-ag + updateVersion: + targetVersion: 2022-cu14 +status: + conditions: + - lastTransitionTime: "2020-06-11T09:59:05Z" + message: The controller has scaled/updated the MSSQLServer successfully + observedGeneration: 3 + reason: OpsRequestSuccessful + status: "True" + type: Successful + observedGeneration: 3 + phase: Successful +``` + +Sample `MSSQLServerOpsRequest` for horizontal scaling: + +```yaml +apiVersion: ops.kubedb.com/v1alpha1 +kind: MSSQLServerOpsRequest +metadata: + name: msops-horizontal-up + namespace: demo +spec: + type: HorizontalScaling + databaseRef: + name: mssql-ag + horizontalScaling: + replicas: 5 +status: + conditions: + - lastTransitionTime: "2020-06-11T09:59:05Z" + message: The controller has scaled/updated the MSSQLServer successfully + observedGeneration: 3 + reason: OpsRequestSuccessful + status: "True" + type: Successful + observedGeneration: 3 + phase: Successful +``` + +Sample `MSSQLServerOpsRequest` for vertical scaling: + +```yaml +apiVersion: ops.kubedb.com/v1alpha1 +kind: MSSQLServerOpsRequest +metadata: + name: mops-vscale-standalone + namespace: demo +spec: + type: VerticalScaling + databaseRef: + name: mssql-standalone + verticalScaling: + mssqlserver: + resources: + requests: + memory: "5Gi" + cpu: "1000m" + limits: + memory: "5Gi" +status: + conditions: + - lastTransitionTime: "2020-06-11T09:59:05Z" + message: The controller has scaled/updated the MSSQLServer successfully + observedGeneration: 3 + reason: OpsRequestSuccessful + status: "True" + type: Successful + observedGeneration: 3 + phase: Successful +``` + +Here, we are going to describe the various sections of a `MSSQLServerOpsRequest` CR. + +### MSSQLServerOpsRequest `Spec` + +A `MSSQLServerOpsRequest` object has the following fields in the `spec` section. + +#### spec.databaseRef + +`spec.databaseRef` is a required field that point to the [MSSQLServer](/docs/v2024.9.30/guides/mssqlserver/concepts/mssqlserver) object where the administrative operations will be applied. This field consists of the following sub-field: + +- **spec.databaseRef.name :** specifies the name of the [MSSQLServer](/docs/v2024.9.30/guides/mssqlserver/concepts/mssqlserver) object. + +#### spec.type + +`spec.type` specifies the kind of operation that will be applied to the database. Currently, the following types of operations are allowed in `MSSQLServerOpsRequest`. + +- `UpdateVersion` +- `HorizontalScaling` +- `VerticalScaling` +- `VolumeExpansion` +- `Restart` + +>You can perform only one type of operation on a single `MSSQLServerOpsRequest` CR. For example, if you want to update your database and scale up its replica then you have to create two separate `MSSQLServerOpsRequest`. At first, you have to create a `MSSQLServerOpsRequest` for updating. Once it is completed, then you can create another `MSSQLServerOpsRequest` for scaling. You should not create two `MSSQLServerOpsRequest` simultaneously. + +#### spec.updateVersion + +If you want to update your MSSQLServer version, you have to specify the `spec.updateVersion` section that specifies the desired version information. This field consists of the following sub-field: + +- `spec.updateVersion.targetVersion` refers to a [MSSQLServerVersion](/docs/v2024.9.30/guides/mssqlserver/concepts/catalog) CR that contains the MSSQLServer version information where you want to update. + +>You can only update between MSSQLServer versions. KubeDB does not support downgrade for MSSQLServer. + +#### spec.horizontalScaling + +If you want to scale-up or scale-down your MSSQLServer cluster, you have to specify `spec.horizontalScaling` section. This field consists of the following sub-field: + +- `spec.horizontalScaling.replicas` indicates the desired number of replicas for your MSSQLServer cluster after scaling. For example, if your cluster currently has 4 replicas, and you want to add additional 2 replicas then you have to specify 6 in `spec.horizontalScaling.replicas` field. Similarly, if you want to remove one member from the cluster, you have to specify 3 in `spec.horizontalScaling.replicas` field. + +#### spec.verticalScaling + +`spec.verticalScaling` is a required field specifying the information of `MSSQLServer` resources like `cpu`, `memory` etc. that will be scaled. This field consists of the following sub-fields: + +- `spec.verticalScaling.mssqlserver` indicates the `MSSQLServer` server resources. It has the below structure: + +```yaml +resources: + requests: + memory: "5Gi" + cpu: 1 + limits: + memory: "5Gi" + cpu: 2 +``` + +Here, when you specify the resource request for `MSSQLServer` container, the scheduler uses this information to decide which node to place the container of the Pod on and when you specify a resource limit for `MSSQLServer` container, the `kubelet` enforces those limits so that the running container is not allowed to use more of that resource than the limit you set. you can found more details from [here](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/) + +- `spec.verticalScaling.exporter` indicates the `exporter` container resources. It has the same structure as `spec.verticalScaling.mssqlserver` and you can scale the resource the same way as `MSSQLServer` container. + +>You can increase/decrease resources for both `MSSQLServer` container and `exporter` container on a single `MSSQLServerOpsRequest` CR. + +### spec.volumeExpansion + +> To use the volume expansion feature the storage class must support volume expansion + +If you want to expand the volume of your MSSQLServer cluster, you have to specify `spec.volumeExpansion` section. This field consists of the following sub-fields: + +- `spec.volumeExpansion.mode` specifies the volume expansion mode. Supported values are `Online` & `Offline`. The default is `Online`. +- `spec.volumeExpansion.mssqlserver` indicates the desired size for the persistent volumes of a MSSQLServer. + +All of them refer to [Quantity](https://v1-22.docs.kubernetes.io/docs/reference/generated/kubernetes-api/v1.22/#quantity-resource-core) types of Kubernetes. + +Example usage of this field is given below: + +```yaml +spec: + volumeExpansion: + mode: "Online" + mssqlserver: 30Gi +``` + +This will expand the volume size of all the mssql server nodes to 30 GB. + + +#### spec.timeout + +As we internally retry the ops request steps multiple times, This `timeout` field helps the users to specify the timeout for those steps of the ops request (in second). If a step doesn’t finish within the specified timeout, the ops request will result in failure. + + +#### spec.apply + +This field controls the execution of obsRequest depending on the database state. It has two supported values: `Always` & `IfReady`. Use IfReady, if you want to process the opsRequest only when the database is Ready. And use Always, if you want to process the execution of opsReq irrespective of the Database state. + +### MSSQLServerOpsRequest `Status` + +`.status` describes the current state and progress of the `MSSQLServerOpsRequest` operation. It has the following fields: + +### status.phase + +`status.phase` indicates the overall phase of the operation for this `MSSQLServerOpsRequest`. It can have the following values: + +| Phase | Meaning | +|-------------|----------------------------------------------------------------------------------------| +| Successful | KubeDB has successfully performed the operation requested in the MSSQLServerOpsRequest | +| Progressing | KubeDB has started the execution of the applied MSSQLServerOpsRequest | +| Failed | KubeDB has failed the operation requested in the MSSQLServerOpsRequest | +| Denied | KubeDB has denied the operation requested in the MSSQLServerOpsRequest | +| Skipped | KubeDB has skipped the operation requested in the MSSQLServerOpsRequest | + +Important: Ops-manager Operator can skip an opsRequest, only if its execution has not been started yet & there is a newer opsRequest applied in the cluster. `spec.type` has to be same as the skipped one, in this case. + +#### status.observedGeneration + +`status.observedGeneration` shows the most recent generation observed by the `MSSQLServerOpsRequest` controller. + +#### status.conditions + +`status.conditions` is an array that specifies the conditions of different steps of `MSSQLServerOpsRequest` processing. Each condition entry has the following fields: + +- `types` specifies the type of the condition. MSSQLServerOpsRequest has the following types of conditions: + +| Type | Meaning | +|---------------------|---------------------------------------------------------------------------------------------| +| `Progressing` | Specifies that the operation is now progressing | +| `Successful` | Specifies such a state that the operation on the database has been successful. | +| `HaltDatabase` | Specifies such a state that the database is halted by the operator | +| `ResumeDatabase` | Specifies such a state that the database is resumed by the operator | +| `Failed` | Specifies such a state that the operation on the database has been failed. | +| `Scaling` | Specifies such a state that the scaling operation on the database has started | +| `VerticalScaling` | Specifies such a state that vertical scaling has performed successfully on database | +| `HorizontalScaling` | Specifies such a state that horizontal scaling has performed successfully on database | +| `Updating` | Specifies such a state that database updating operation has started | +| `UpdateVersion` | Specifies such a state that version updating on the database have performed successfully | + +- The `status` field is a string, with possible values `"True"`, `"False"`, and `"Unknown"`. + - `status` will be `"True"` if the current transition is succeeded. + - `status` will be `"False"` if the current transition is failed. + - `status` will be `"Unknown"` if the current transition is denied. +- The `message` field is a human-readable message indicating details about the condition. +- The `reason` field is a unique, one-word, CamelCase reason for the condition's last transition. It has the following possible values: + +| Reason | Meaning | +|------------------------------------------| -------------------------------------------------------------------------------- | +| `OpsRequestProgressingStarted` | Operator has started the OpsRequest processing | +| `OpsRequestFailedToProgressing` | Operator has failed to start the OpsRequest processing | +| `SuccessfullyHaltedDatabase` | Database is successfully halted by the operator | +| `FailedToHaltDatabase` | Database is failed to halt by the operator | +| `SuccessfullyResumedDatabase` | Database is successfully resumed to perform its usual operation | +| `FailedToResumedDatabase` | Database is failed to resume | +| `DatabaseVersionUpdatingStarted` | Operator has started updating the database version | +| `SuccessfullyUpdatedDatabaseVersion` | Operator has successfully updated the database version | +| `FailedToUpdateDatabaseVersion` | Operator has failed to update the database version | +| `HorizontalScalingStarted` | Operator has started the horizontal scaling | +| `SuccessfullyPerformedHorizontalScaling` | Operator has successfully performed on horizontal scaling | +| `FailedToPerformHorizontalScaling` | Operator has failed to perform on horizontal scaling | +| `VerticalScalingStarted` | Operator has started the vertical scaling | +| `SuccessfullyPerformedVerticalScaling` | Operator has successfully performed on vertical scaling | +| `FailedToPerformVerticalScaling` | Operator has failed to perform on vertical scaling | +| `OpsRequestProcessedSuccessfully` | Operator has completed the operation successfully requested by the OpeRequest cr | + +- The `lastTransitionTime` field provides a timestamp for when the operation last transitioned from one state to another. +- The `observedGeneration` shows the most recent condition transition generation observed by the controller. diff --git a/content/docs/v2024.9.30/guides/mssqlserver/monitoring/_index.md b/content/docs/v2024.9.30/guides/mssqlserver/monitoring/_index.md new file mode 100755 index 0000000000..48dc9cd98c --- /dev/null +++ b/content/docs/v2024.9.30/guides/mssqlserver/monitoring/_index.md @@ -0,0 +1,22 @@ +--- +title: Monitoring Microsoft SQL Server +menu: + docs_v2024.9.30: + identifier: ms-monitoring + name: Monitoring + parent: guides-mssqlserver + weight: 50 +menu_name: docs_v2024.9.30 +info: + autoscaler: v0.33.0 + cli: v0.48.0 + dashboard: v0.24.0 + installer: v2024.9.30 + ops-manager: v0.35.0 + provisioner: v0.48.0 + schema-manager: v0.24.0 + ui-server: v0.24.0 + version: v2024.9.30 + webhook-server: v0.24.0 +--- + diff --git a/content/docs/v2024.9.30/guides/mssqlserver/monitoring/overview.md b/content/docs/v2024.9.30/guides/mssqlserver/monitoring/overview.md new file mode 100644 index 0000000000..435dd7e5e8 --- /dev/null +++ b/content/docs/v2024.9.30/guides/mssqlserver/monitoring/overview.md @@ -0,0 +1,115 @@ +--- +title: MSSQLServer Monitoring Overview +description: MSSQLServer Monitoring Overview +menu: + docs_v2024.9.30: + identifier: ms-monitoring-overview + name: Overview + parent: ms-monitoring + weight: 10 +menu_name: docs_v2024.9.30 +section_menu_id: guides +info: + autoscaler: v0.33.0 + cli: v0.48.0 + dashboard: v0.24.0 + installer: v2024.9.30 + ops-manager: v0.35.0 + provisioner: v0.48.0 + schema-manager: v0.24.0 + ui-server: v0.24.0 + version: v2024.9.30 + webhook-server: v0.24.0 +--- + +> New to KubeDB? Please start [here](/docs/v2024.9.30/README). + +# Monitoring MSSQLServer with KubeDB + +KubeDB has native support for monitoring via [Prometheus](https://prometheus.io/). You can use builtin [Prometheus](https://github.com/prometheus/prometheus) scraper or [Prometheus operator](https://github.com/prometheus-operator/prometheus-operator) to monitor KubeDB managed databases. This tutorial will show you how database monitoring works with KubeDB and how to configure Database CR to enable monitoring. + +## Overview + +KubeDB uses Prometheus [exporter](https://prometheus.io/docs/instrumenting/exporters/#databases) images to export Prometheus metrics for respective databases. Following diagram shows the logical flow of database monitoring with KubeDB. + +

+  Database Monitoring Flow +

+ +When a user creates a database CR with `spec.monitor` section configured, KubeDB operator provisions the respective database and injects an exporter image as sidecar to the database pod. It also creates a dedicated stats service with name `{database-crd-name}-stats` for monitoring. Prometheus server can scrape metrics using this stats service. + +## Configure Monitoring + +In order to enable monitoring for a database, you have to configure `spec.monitor` section. KubeDB provides following options to configure `spec.monitor` section: + +| Field | Type | Uses | +| -------------------------------------------------- | ---------- | --------------------------------------------------------------------------------------------------------------------------------------------- | +| `spec.monitor.agent` | `Required` | Type of the monitoring agent that will be used to monitor this database. It can be `prometheus.io/builtin` or `prometheus.io/operator`. | +| `spec.monitor.prometheus.exporter.port` | `Optional` | Port number where the exporter side car will serve metrics. | +| `spec.monitor.prometheus.exporter.args` | `Optional` | Arguments to pass to the exporter sidecar. | +| `spec.monitor.prometheus.exporter.env` | `Optional` | List of environment variables to set in the exporter sidecar container. | +| `spec.monitor.prometheus.exporter.resources` | `Optional` | Resources required by exporter sidecar container. | +| `spec.monitor.prometheus.exporter.securityContext` | `Optional` | Security options the exporter should run with. | +| `spec.monitor.prometheus.serviceMonitor.labels` | `Optional` | Labels for `ServiceMonitor` CR. | +| `spec.monitor.prometheus.serviceMonitor.interval` | `Optional` | Interval at which metrics should be scraped. | + +## Sample Configuration + +A sample YAML for MSSQLServer CR with `spec.monitor` section configured to enable monitoring with [Prometheus operator](https://github.com/prometheus-operator/prometheus-operator) is shown below. + +```yaml +apiVersion: kubedb.com/v1alpha2 +kind: MSSQLServer +metadata: + name: mssql-monitoring + namespace: demo +spec: + version: "2022-cu12" + replicas: 1 + tls: + issuerRef: + name: mssqlserver-ca-issuer + kind: Issuer + apiGroup: "cert-manager.io" + clientTLS: false + monitor: + agent: prometheus.io/operator + prometheus: + exporter: + port: 9399 + resources: + limits: + memory: 512Mi + requests: + cpu: 200m + memory: 256Mi + securityContext: + allowPrivilegeEscalation: false + capabilities: + drop: + - ALL + runAsGroup: 10001 + runAsNonRoot: true + runAsUser: 10001 + seccompProfile: + type: RuntimeDefault + serviceMonitor: + interval: 10s + labels: + release: prometheus + storageType: Durable + storage: + storageClassName: standard + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + deletionPolicy: WipeOut +``` + +Here, we have specified that we are going to monitor this server using Prometheus operator through `spec.monitor.agent: prometheus.io/operator`. KubeDB will create a `ServiceMonitor` CR in `monitoring` namespace and this `ServiceMonitor` will have `release: prometheus` label. + +## Next Steps + +- Learn how to monitor Microsoft SQL Server with KubeDB using [Prometheus operator](/docs/v2024.9.30/guides/mssqlserver/monitoring/using-prometheus-operator). diff --git a/content/docs/v2024.9.30/guides/mssqlserver/monitoring/using-prometheus-operator.md b/content/docs/v2024.9.30/guides/mssqlserver/monitoring/using-prometheus-operator.md new file mode 100644 index 0000000000..8b4a371be6 --- /dev/null +++ b/content/docs/v2024.9.30/guides/mssqlserver/monitoring/using-prometheus-operator.md @@ -0,0 +1,450 @@ +--- +title: Monitor SQL Server using Prometheus Operator +menu: + docs_v2024.9.30: + identifier: ms-monitoring-prometheus-operator + name: Prometheus Operator + parent: ms-monitoring + weight: 15 +menu_name: docs_v2024.9.30 +section_menu_id: guides +info: + autoscaler: v0.33.0 + cli: v0.48.0 + dashboard: v0.24.0 + installer: v2024.9.30 + ops-manager: v0.35.0 + provisioner: v0.48.0 + schema-manager: v0.24.0 + ui-server: v0.24.0 + version: v2024.9.30 + webhook-server: v0.24.0 +--- + +> New to KubeDB? Please start [here](/docs/v2024.9.30/README). + +# Monitoring MSSQLServer Using Prometheus operator + +[Prometheus operator](https://github.com/prometheus-operator/prometheus-operator) provides simple and Kubernetes native way to deploy and configure Prometheus server. This tutorial will show you how to use Prometheus operator to monitor MSSQLServer deployed with KubeDB. + +## 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/v2024.9.30/setup/README). 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/). + +- To learn how Prometheus monitoring works with KubeDB in general, please visit [here](/docs/v2024.9.30/guides/mssqlserver/monitoring/overview). + +- To keep Prometheus resources isolated, we are going to use a separate namespace called `monitoring` to deploy respective monitoring resources. We are going to deploy database in `demo` namespace. + + ```bash + $ kubectl create ns monitoring + namespace/monitoring created + + $ kubectl create ns demo + namespace/demo created + ``` + +- We need a [Prometheus operator](https://github.com/prometheus-operator/prometheus-operator) instance running. If you don't already have a running instance, you can deploy one using this helm chart [here](https://github.com/prometheus-community/helm-charts/tree/main/charts/kube-prometheus-stack). + + +> Note: YAML files used in this tutorial are stored in [docs/examples/mssqlserver/monitoring](https://github.com/kubedb/docs/tree/{{< param "info.version" >}}/docs/examples/mssqlserver/monitoring) folder in GitHub repository [kubedb/docs](https://github.com/kubedb/docs). + +## Find out required labels for ServiceMonitor + +We need to know the labels used to select `ServiceMonitor` by `Prometheus` Operator. We are going to provide these labels in `spec.monitor.prometheus.labels` field of MSSQLServer CR so that KubeDB creates `ServiceMonitor` object accordingly. + +At first, let's find out the available Prometheus server in our cluster. + +```bash +$ kubectl get prometheus --all-namespaces +NAMESPACE NAME VERSION DESIRED READY RECONCILED AVAILABLE AGE +monitoring prometheus-kube-prometheus-prometheus v2.54.1 1 1 True True 16d +``` + +> If you don't have any Prometheus server running in your cluster, deploy one following the guide specified in **Before You Begin** section. + +Now, let's view the YAML of the available Prometheus server `prometheus-kube-prometheus-prometheus` in `monitoring` namespace. + +```bash +$ kubectl get prometheus -n monitoring prometheus-kube-prometheus-prometheus -oyaml +``` +```yaml +apiVersion: monitoring.coreos.com/v1 +kind: Prometheus +metadata: + annotations: + meta.helm.sh/release-name: prometheus + meta.helm.sh/release-namespace: monitoring + creationTimestamp: "2024-10-14T10:14:36Z" + generation: 1 + labels: + app: kube-prometheus-stack-prometheus + app.kubernetes.io/instance: prometheus + app.kubernetes.io/managed-by: Helm + app.kubernetes.io/part-of: kube-prometheus-stack + app.kubernetes.io/version: 65.2.0 + chart: kube-prometheus-stack-65.2.0 + heritage: Helm + release: prometheus + name: prometheus-kube-prometheus-prometheus + namespace: monitoring + resourceVersion: "1004097" + uid: b7879d3e-e4bb-4425-8d78-f917561d95f7 +spec: + alerting: + alertmanagers: + - apiVersion: v2 + name: prometheus-kube-prometheus-alertmanager + namespace: monitoring + pathPrefix: / + port: http-web + automountServiceAccountToken: true + enableAdminAPI: false + evaluationInterval: 30s + externalUrl: http://prometheus-kube-prometheus-prometheus.monitoring:9090 + hostNetwork: false + image: quay.io/prometheus/prometheus:v2.54.1 + listenLocal: false + logFormat: logfmt + logLevel: info + paused: false + podMonitorNamespaceSelector: {} + podMonitorSelector: + matchLabels: + release: prometheus + portName: http-web + probeNamespaceSelector: {} + probeSelector: + matchLabels: + release: prometheus + replicas: 1 + retention: 10d + routePrefix: / + ruleNamespaceSelector: {} + ruleSelector: + matchLabels: + release: prometheus + scrapeConfigNamespaceSelector: {} + scrapeConfigSelector: + matchLabels: + release: prometheus + scrapeInterval: 30s + securityContext: + fsGroup: 2000 + runAsGroup: 2000 + runAsNonRoot: true + runAsUser: 1000 + seccompProfile: + type: RuntimeDefault + serviceAccountName: prometheus-kube-prometheus-prometheus + serviceMonitorNamespaceSelector: {} + serviceMonitorSelector: + matchLabels: + release: prometheus + shards: 1 + tsdb: + outOfOrderTimeWindow: 0s + version: v2.54.1 + walCompression: true +status: + availableReplicas: 1 + conditions: + - lastTransitionTime: "2024-10-31T07:38:36Z" + message: "" + observedGeneration: 1 + reason: "" + status: "True" + type: Available + - lastTransitionTime: "2024-10-31T07:38:36Z" + message: "" + observedGeneration: 1 + reason: "" + status: "True" + type: Reconciled + paused: false + replicas: 1 + selector: app.kubernetes.io/instance=prometheus-kube-prometheus-prometheus,app.kubernetes.io/managed-by=prometheus-operator,app.kubernetes.io/name=prometheus,operator.prometheus.io/name=prometheus-kube-prometheus-prometheus,prometheus=prometheus-kube-prometheus-prometheus + shardStatuses: + - availableReplicas: 1 + replicas: 1 + shardID: "0" + unavailableReplicas: 0 + updatedReplicas: 1 + shards: 1 + unavailableReplicas: 0 + updatedReplicas: 1 +``` + +Notice the `spec.serviceMonitorSelector` section. Here, `release: prometheus` label is used to select `ServiceMonitor` CR. So, we are going to use this label in `spec.monitor.prometheus.labels` field of MSSQLServer CR. + +## Deploy MSSQLServer with Monitoring Enabled + +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, let's deploy an MSSQLServer with monitoring enabled. Below is the MSSQLServer object that we are going to create. + +```yaml +apiVersion: kubedb.com/v1alpha2 +kind: MSSQLServer +metadata: + name: mssql-monitoring + namespace: demo +spec: + version: "2022-cu12" + replicas: 1 + tls: + issuerRef: + name: mssqlserver-ca-issuer + kind: Issuer + apiGroup: "cert-manager.io" + clientTLS: false + monitor: + agent: prometheus.io/operator + prometheus: + exporter: + port: 9399 + resources: + limits: + memory: 512Mi + requests: + cpu: 200m + memory: 256Mi + securityContext: + allowPrivilegeEscalation: false + capabilities: + drop: + - ALL + runAsGroup: 10001 + runAsNonRoot: true + runAsUser: 10001 + seccompProfile: + type: RuntimeDefault + serviceMonitor: + interval: 10s + labels: + release: prometheus + storageType: Durable + storage: + storageClassName: standard + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + deletionPolicy: WipeOut +``` + +Here, + +- `monitor.agent: prometheus.io/operator` indicates that we are going to monitor this server using Prometheus operator. + +- `monitor.prometheus.serviceMonitor.labels` specifies that KubeDB should create `ServiceMonitor` with these labels. + +- `monitor.prometheus.interval` indicates that the Prometheus server should scrape metrics from this database with 10 seconds interval. + +Let's create the MSSQLServer object that we have shown above, + +```bash +$ kubectl create -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/examples/mssqlserver/monitoring/mssql-monitoring.yaml +mssqlserverql.kubedb.com/mssql-monitoring created +``` + +Now, wait for the database to go into `Ready` state. + +```bash +$ kubectl get ms -n demo mssql-monitoring +NAME VERSION STATUS AGE +mssql-monitoring 2022-cu12 Ready 108m +``` + +KubeDB will create a separate stats service with name `{mssqlserver cr name}-stats` for monitoring purpose. + +```bash +$ kubectl get svc -n demo --selector="app.kubernetes.io/instance=mssql-monitoring" +NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE +mssql-monitoring ClusterIP 10.96.225.130 1433/TCP 108m +mssql-monitoring-pods ClusterIP None 1433/TCP 108m +mssql-monitoring-stats ClusterIP 10.96.147.93 9399/TCP 108m +``` + +Here, `mssql-monitoring-stats` service has been created for monitoring purpose. + +Let's describe this stats service. + + +```bash +$ kubectl describe svc -n demo mssql-monitoring-stats +``` +```yaml +Name: mssql-monitoring-stats +Namespace: demo +Labels: app.kubernetes.io/component=database + app.kubernetes.io/instance=mssql-monitoring + app.kubernetes.io/managed-by=kubedb.com + app.kubernetes.io/name=mssqlservers.kubedb.com + kubedb.com/role=stats +Annotations: monitoring.appscode.com/agent: prometheus.io/operator +Selector: app.kubernetes.io/instance=mssql-monitoring,app.kubernetes.io/managed-by=kubedb.com,app.kubernetes.io/name=mssqlservers.kubedb.com +Type: ClusterIP +IP Family Policy: SingleStack +IP Families: IPv4 +IP: 10.96.147.93 +IPs: 10.96.147.93 +Port: metrics 9399/TCP +TargetPort: metrics/TCP +Endpoints: 10.244.0.47:9399 +Session Affinity: None +Events: +``` + +Notice the `Labels` and `Port` fields. `ServiceMonitor` will use these information to target its endpoints. + +KubeDB will also create a `ServiceMonitor` CR in `demo` namespace that select the endpoints of `mssql-monitoring-stats` service. Verify that the `ServiceMonitor` CR has been created. + +```bash +$ kubectl get servicemonitor -n demo +NAME AGE +mssql-monitoring-stats 110m +``` + +Let's verify that the `ServiceMonitor` has the label that we had specified in `spec.monitor` section of MSSQLServer CR. + +```bash +$ kubectl get servicemonitor -n demo mssql-monitoring-stats -o yaml +``` + +```yaml +apiVersion: monitoring.coreos.com/v1 +kind: ServiceMonitor +metadata: + creationTimestamp: "2024-10-31T07:38:36Z" + generation: 1 + labels: + app.kubernetes.io/component: database + app.kubernetes.io/instance: mssql-monitoring + app.kubernetes.io/managed-by: kubedb.com + app.kubernetes.io/name: mssqlservers.kubedb.com + release: prometheus + name: mssql-monitoring-stats + namespace: demo + ownerReferences: + - apiVersion: v1 + blockOwnerDeletion: true + controller: true + kind: Service + name: mssql-monitoring-stats + uid: 99193679-301b-41fd-aae5-a732b3070d19 + resourceVersion: "1004080" + uid: 87635ad4-dfb2-4544-89af-e48b40783205 +spec: + endpoints: + - honorLabels: true + interval: 10s + path: /metrics + port: metrics + namespaceSelector: + matchNames: + - demo + selector: + matchLabels: + app.kubernetes.io/component: database + app.kubernetes.io/instance: mssql-monitoring + app.kubernetes.io/managed-by: kubedb.com + app.kubernetes.io/name: mssqlservers.kubedb.com + kubedb.com/role: stats +``` + +Notice that the `ServiceMonitor` has label `release: prometheus` that we had specified in MSSQLServer CR. + +Also notice that the `ServiceMonitor` has selector which match the labels we have seen in the `mssql-monitoring-stats` service. It also, target the `metrics` port that we have seen in the stats service. + +## Verify Monitoring Metrics + +At first, let's find out the respective Prometheus pod for `prometheus-kube-prometheus-prometheus` Prometheus server. + +```bash +$ kubectl get pod -n monitoring -l=app.kubernetes.io/name=prometheus +NAME READY STATUS RESTARTS AGE +prometheus-prometheus-kube-prometheus-prometheus-0 2/2 Running 1 16d +``` + +Prometheus server is listening to port `9090` of `prometheus-prometheus-kube-prometheus-prometheus-0` pod. We are going to use [port forwarding](https://kubernetes.io/docs/tasks/access-application-cluster/port-forward-access-application-cluster/) to access Prometheus dashboard. + +Run following command on a separate terminal to forward the port 9090 of `prometheus-prometheus-0` pod, + +```bash +$ kubectl port-forward -n monitoring prometheus-prometheus-kube-prometheus-prometheus-0 9090 +Forwarding from 127.0.0.1:9090 -> 9090 +Forwarding from [::1]:9090 -> 9090 +``` + +Now, we can access the dashboard at `localhost:9090`. Open [http://localhost:9090](http://localhost:9090) in your browser. You should see `metrics` endpoint of `mssql-monitoring-stats` service as one of the targets. + +

+  Prometheus Target +

+ +Check the `endpoint` and `service` labels. It verifies that the target is our expected database. Now, you can view the collected metrics and create a graph from homepage of this Prometheus dashboard. You can also use this Prometheus server as data source for [Grafana](https://grafana.com/) and create beautiful dashboards with collected metrics. + +# Grafana Dashboards + +There are three dashboards to monitor Microsoft SQL Server Databases managed by KubeDB. + +- KubeDB / MSSQLServer / Summary: Shows overall summary of Microsoft SQL Server instance. +- KubeDB / MSSQLServer / Pod: Shows individual pod-level information. +- KubeDB / MSSQLServer / Database: Shows Microsoft SQL Server internal metrics for an instance. +> Note: These dashboards are developed in Grafana version 7.5.5 + + +To use KubeDB `Grafana Dashboards` to monitor Microsoft SQL Server Databases managed by `KubeDB`, Check out [mssqlserver-dashboards](https://github.com/ops-center/grafana-dashboards/tree/master/mssqlserver) + +## Cleaning up + +To clean up the Kubernetes resources created by this tutorial, run following commands + +```bash +kubectl delete -n demo ms/mssql-monitoring +kubectl delete ns demo + +helm uninstall prometheus -n monitoring +kubectl delete ns monitoring +``` + +## Next Steps +- Learn about [backup and restore](/docs/v2024.9.30/guides/mssqlserver/backup/overview/) SQL Server using KubeStash. +- Want to hack on KubeDB? Check our [contribution guidelines](/docs/v2024.9.30/CONTRIBUTING). diff --git a/content/docs/v2024.9.30/guides/mssqlserver/restart/_index.md b/content/docs/v2024.9.30/guides/mssqlserver/restart/_index.md new file mode 100644 index 0000000000..dd57851d24 --- /dev/null +++ b/content/docs/v2024.9.30/guides/mssqlserver/restart/_index.md @@ -0,0 +1,22 @@ +--- +title: Restart MSSQLServer +menu: + docs_v2024.9.30: + identifier: ms-restart + name: Restart + parent: guides-mssqlserver + weight: 46 +menu_name: docs_v2024.9.30 +info: + autoscaler: v0.33.0 + cli: v0.48.0 + dashboard: v0.24.0 + installer: v2024.9.30 + ops-manager: v0.35.0 + provisioner: v0.48.0 + schema-manager: v0.24.0 + ui-server: v0.24.0 + version: v2024.9.30 + webhook-server: v0.24.0 +--- + diff --git a/content/docs/v2024.9.30/guides/mssqlserver/restart/restart.md b/content/docs/v2024.9.30/guides/mssqlserver/restart/restart.md new file mode 100644 index 0000000000..acfba27468 --- /dev/null +++ b/content/docs/v2024.9.30/guides/mssqlserver/restart/restart.md @@ -0,0 +1,287 @@ +--- +title: Restart MSSQLServer +menu: + docs_v2024.9.30: + identifier: ms-restart-guide + name: Restart MSSQLServer + parent: ms-restart + weight: 10 +menu_name: docs_v2024.9.30 +section_menu_id: guides +info: + autoscaler: v0.33.0 + cli: v0.48.0 + dashboard: v0.24.0 + installer: v2024.9.30 + ops-manager: v0.35.0 + provisioner: v0.48.0 + schema-manager: v0.24.0 + ui-server: v0.24.0 + version: v2024.9.30 + webhook-server: v0.24.0 +--- + +> New to KubeDB? Please start [here](/docs/v2024.9.30/README). + +# Restart MSSQLServer + +KubeDB supports restarting the MSSQLServer via a MSSQLServerOpsRequest. Restarting is useful if some pods are got stuck in some phase, or they are not working correctly. This tutorial will show you how to use that. + +## 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/v2024.9.30/setup/README). 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/). + +- To keep things isolated, this tutorial uses a separate namespace called `demo` throughout this tutorial. + +```bash + $ kubectl create ns demo + namespace/demo created + ``` + +> Note: YAML files used in this tutorial are stored in [docs/examples/mssqlserver](https://github.com/kubedb/docs/tree/{{< param "info.version" >}}/docs/examples/mssqlserver) folder in GitHub repository [kubedb/docs](https://github.com/kubedb/docs). + +## Deploy MSSQLServer + +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 database 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 + storageType: Durable + storage: + storageClassName: "standard" + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + deletionPolicy: WipeOut +``` + +Let's create the `MSSQLServer` CR we have shown above, + +```bash +$ kubectl create -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/examples/mssqlserver/restart/mssqlserver-ag-cluster.yaml +mssqlserver.kubedb.com/mssqlserver-ag-cluster created +``` + +Check the database is provisioned successfully +```bash +$ kubectl get ms -n demo mssqlserver-ag-cluster +NAME VERSION STATUS AGE +mssqlserver-ag-cluster 2022-cu12 Ready 4m +``` + + +## Apply Restart opsRequest + +```yaml +apiVersion: ops.kubedb.com/v1alpha1 +kind: MSSQLServerOpsRequest +metadata: + name: msops-restart + namespace: demo +spec: + type: Restart + databaseRef: + name: mssqlserver-ag-cluster + timeout: 3m + apply: Always +``` + +- `spec.type` specifies the Type of the ops Request +- `spec.databaseRef` holds the name of the MSSQLServer database. The db should be available in the same namespace as the opsRequest +- The meaning of `spec.timeout` & `spec.apply` fields can be found [here](/docs/v2024.9.30/guides/mssqlserver/concepts/opsrequest) + +> Note: The method of restarting the standalone & cluster mode db is exactly same as above. All you need, is to specify the corresponding MSSQLServer name in `spec.databaseRef.name` section. + +Let's create the `MSSQLServerOpsRequest` CR we have shown above, + +```bash +$ kubectl create -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/examples/mssqlserver/restart/msops-restart.yaml +mssqlserveropsrequest.ops.kubedb.com/msops-restart created +``` + +Now the Ops-manager operator will first restart the general secondary pods and lastly will restart the Primary pod of the database. + +```shell +$ kubectl get msops -n demo msops-restart +NAME TYPE STATUS AGE +msops-restart Restart Successful 5m23s + +$ kubectl get msops -n demo msops-restart -oyaml +apiVersion: ops.kubedb.com/v1alpha1 +kind: MSSQLServerOpsRequest +metadata: + annotations: + kubectl.kubernetes.io/last-applied-configuration: | + {"apiVersion":"ops.kubedb.com/v1alpha1","kind":"MSSQLServerOpsRequest","metadata":{"annotations":{},"name":"msops-restart","namespace":"demo"},"spec":{"apply":"Always","databaseRef":{"name":"mssqlserver-ag-cluster"},"timeout":"3m","type":"Restart"}} + creationTimestamp: "2024-10-25T06:58:21Z" + generation: 1 + name: msops-restart + namespace: demo + resourceVersion: "771141" + uid: 9e531521-c369-4ce4-983f-a3dafd90cb8a +spec: + apply: Always + databaseRef: + name: mssqlserver-ag-cluster + timeout: 3m + type: Restart +status: + conditions: + - lastTransitionTime: "2024-10-25T06:58:21Z" + message: MSSQLServerOpsRequest has started to restart MSSQLServer nodes + observedGeneration: 1 + reason: Restart + status: "True" + type: Restart + - lastTransitionTime: "2024-10-25T06:58:45Z" + message: get pod; ConditionStatus:True; PodName:mssqlserver-ag-cluster-0 + observedGeneration: 1 + status: "True" + type: GetPod--mssqlserver-ag-cluster-0 + - lastTransitionTime: "2024-10-25T06:58:45Z" + message: evict pod; ConditionStatus:True; PodName:mssqlserver-ag-cluster-0 + observedGeneration: 1 + status: "True" + type: EvictPod--mssqlserver-ag-cluster-0 + - lastTransitionTime: "2024-10-25T06:59:20Z" + message: check pod running; ConditionStatus:True; PodName:mssqlserver-ag-cluster-0 + observedGeneration: 1 + status: "True" + type: CheckPodRunning--mssqlserver-ag-cluster-0 + - lastTransitionTime: "2024-10-25T06:59:25Z" + message: get pod; ConditionStatus:True; PodName:mssqlserver-ag-cluster-1 + observedGeneration: 1 + status: "True" + type: GetPod--mssqlserver-ag-cluster-1 + - lastTransitionTime: "2024-10-25T06:59:25Z" + message: evict pod; ConditionStatus:True; PodName:mssqlserver-ag-cluster-1 + observedGeneration: 1 + status: "True" + type: EvictPod--mssqlserver-ag-cluster-1 + - lastTransitionTime: "2024-10-25T07:00:00Z" + message: check pod running; ConditionStatus:True; PodName:mssqlserver-ag-cluster-1 + observedGeneration: 1 + status: "True" + type: CheckPodRunning--mssqlserver-ag-cluster-1 + - lastTransitionTime: "2024-10-25T07:00:05Z" + message: get pod; ConditionStatus:True; PodName:mssqlserver-ag-cluster-2 + observedGeneration: 1 + status: "True" + type: GetPod--mssqlserver-ag-cluster-2 + - lastTransitionTime: "2024-10-25T07:00:05Z" + message: evict pod; ConditionStatus:True; PodName:mssqlserver-ag-cluster-2 + observedGeneration: 1 + status: "True" + type: EvictPod--mssqlserver-ag-cluster-2 + - lastTransitionTime: "2024-10-25T07:00:40Z" + message: check pod running; ConditionStatus:True; PodName:mssqlserver-ag-cluster-2 + observedGeneration: 1 + status: "True" + type: CheckPodRunning--mssqlserver-ag-cluster-2 + - lastTransitionTime: "2024-10-25T07:00:45Z" + message: Successfully restarted MSSQLServer nodes + observedGeneration: 1 + reason: RestartNodes + status: "True" + type: RestartNodes + - lastTransitionTime: "2024-10-25T07:00:45Z" + message: Controller has successfully restart the MSSQLServer replicas + observedGeneration: 1 + reason: Successful + status: "True" + type: Successful + observedGeneration: 1 + phase: Successful +``` + +We can see that, the database is ready after restarting the pods +```bash +$ kubectl get ms -n demo mssqlserver-ag-cluster +NAME VERSION STATUS AGE +mssqlserver-ag-cluster 2022-cu12 Ready 14m +``` + +## Cleaning up + +To clean up the Kubernetes resources created by this tutorial, run: + +```bash +kubectl delete mssqlserveropsrequest -n demo msops-restart +kubectl delete mssqlserver -n demo mssqlserver-ag-cluster +kubectl delete issuer -n demo mssqlserver-ca-issuer +kubectl delete secret -n demo mssqlserver-ca +kubectl delete ns demo +``` + +## Next Steps + +- Learn about [backup and restore](/docs/v2024.9.30/guides/mssqlserver/backup/overview/) MSSQLServer database using KubeStash. +- Want to set up MSSQLServer cluster? Check how to [Configure SQL Server Availability Group Cluster](/docs/v2024.9.30/guides/mssqlserver/clustering/ag_cluster) +- Detail concepts of [MSSQLServer Object](/docs/v2024.9.30/guides/mssqlserver/concepts/mssqlserver). + +- Want to hack on KubeDB? Check our [contribution guidelines](/docs/v2024.9.30/CONTRIBUTING). diff --git a/content/docs/v2024.9.30/guides/mssqlserver/scaling/_index.md b/content/docs/v2024.9.30/guides/mssqlserver/scaling/_index.md new file mode 100644 index 0000000000..3c79270dde --- /dev/null +++ b/content/docs/v2024.9.30/guides/mssqlserver/scaling/_index.md @@ -0,0 +1,22 @@ +--- +title: Scaling Microsoft SQL Server +menu: + docs_v2024.9.30: + identifier: ms-scaling + name: Scaling Microsoft SQL Server + parent: guides-mssqlserver + weight: 43 +menu_name: docs_v2024.9.30 +info: + autoscaler: v0.33.0 + cli: v0.48.0 + dashboard: v0.24.0 + installer: v2024.9.30 + ops-manager: v0.35.0 + provisioner: v0.48.0 + schema-manager: v0.24.0 + ui-server: v0.24.0 + version: v2024.9.30 + webhook-server: v0.24.0 +--- + diff --git a/content/docs/v2024.9.30/guides/mssqlserver/scaling/horizontal-scaling/_index.md b/content/docs/v2024.9.30/guides/mssqlserver/scaling/horizontal-scaling/_index.md new file mode 100644 index 0000000000..e2c4e4861a --- /dev/null +++ b/content/docs/v2024.9.30/guides/mssqlserver/scaling/horizontal-scaling/_index.md @@ -0,0 +1,22 @@ +--- +title: Horizontal Scaling +menu: + docs_v2024.9.30: + identifier: ms-scaling-horizontal + name: Horizontal Scaling + parent: ms-scaling + weight: 10 +menu_name: docs_v2024.9.30 +info: + autoscaler: v0.33.0 + cli: v0.48.0 + dashboard: v0.24.0 + installer: v2024.9.30 + ops-manager: v0.35.0 + provisioner: v0.48.0 + schema-manager: v0.24.0 + ui-server: v0.24.0 + version: v2024.9.30 + webhook-server: v0.24.0 +--- + diff --git a/content/docs/v2024.9.30/guides/mssqlserver/scaling/horizontal-scaling/mssqlserver.md b/content/docs/v2024.9.30/guides/mssqlserver/scaling/horizontal-scaling/mssqlserver.md new file mode 100644 index 0000000000..3f2a65954e --- /dev/null +++ b/content/docs/v2024.9.30/guides/mssqlserver/scaling/horizontal-scaling/mssqlserver.md @@ -0,0 +1,726 @@ +--- +title: Horizontal Scaling MSSQLServer Cluster +menu: + docs_v2024.9.30: + identifier: ms-scaling-horizontal-guide + name: Scale Horizontally + parent: ms-scaling-horizontal + weight: 20 +menu_name: docs_v2024.9.30 +section_menu_id: guides +info: + autoscaler: v0.33.0 + cli: v0.48.0 + dashboard: v0.24.0 + installer: v2024.9.30 + ops-manager: v0.35.0 + provisioner: v0.48.0 + schema-manager: v0.24.0 + ui-server: v0.24.0 + version: v2024.9.30 + webhook-server: v0.24.0 +--- + +> New to KubeDB? Please start [here](/docs/v2024.9.30/README). + +# Horizontal Scale MSSQLServer Cluster + +This guide will show you how to use `KubeDB` Ops Manager to increase/decrease the number of replicas of a `MSSQLServer` 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/v2024.9.30/setup/README). 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/). + +- You should be familiar with the following `KubeDB` concepts: + - [MSSQLServer](/docs/v2024.9.30/guides/mssqlserver/concepts/mssqlserver) + - [MSSQLServerOpsRequest](/docs/v2024.9.30/guides/mssqlserver/concepts/opsrequest) + - [Horizontal Scaling Overview](/docs/v2024.9.30/guides/mssqlserver/scaling/horizontal-scaling/overview) + +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 +``` + +> **Note:** YAML files used in this tutorial are stored in [docs/examples/mssqlserver/scaling/horizontal-scaling](https://github.com/kubedb/docs/tree/{{< param "info.version" >}}/docs/examples/mssqlserver/scaling/horizontal-scaling) directory of [kubedb/doc](https://github.com/kubedb/docs) repository. + +### Apply Horizontal Scaling on MSSQLServer Cluster + +Here, we are going to deploy a `MSSQLServer` Cluster using a supported version by `KubeDB` operator. Then we are going to apply horizontal scaling on it. + +#### Prepare Cluster + +At first, we are going to deploy a Cluster server with 2 replicas. Then, we are going to add two additional replicas through horizontal scaling. Finally, we will remove 1 replica from the cluster again via horizontal scaling. + +**Find supported MSSQLServer Version:** + +When you have installed `KubeDB`, it has created `MSSQLServerVersion` CR for all supported `MSSQLServer` versions. Let's check the supported MSSQLServer versions, + +```bash +$ kubectl get mssqlserverversion +NAME VERSION DB_IMAGE DEPRECATED AGE +2022-cu12 2022 mcr.microsoft.com/mssql/server:2022-CU12-ubuntu-22.04 176m +2022-cu14 2022 mcr.microsoft.com/mssql/server:2022-CU14-ubuntu-22.04 176m +``` + +The version above that does not show `DEPRECATED` `true` is supported by `KubeDB` for `MSSQLServer`. You can use any non-deprecated version. Here, we are going to create a MSSQLServer Cluster using `MSSQLServer` `2022-cu12`. + +**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 +``` + +In this section, we are going to deploy a MSSQLServer Cluster with 2 replicas. Then, in the next section we will scale up the cluster using horizontal scaling. Below is the YAML of the `MSSQLServer` CR that we are going to create, + +```yaml +apiVersion: kubedb.com/v1alpha2 +kind: MSSQLServer +metadata: + name: mssql-ag-cluster + namespace: demo +spec: + version: "2022-cu12" + replicas: 2 + 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: 1 + memory: "2Gi" + storageType: Durable + storage: + storageClassName: "standard" + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + deletionPolicy: WipeOut +``` + +Let's create the `MSSQLServer` CR we have shown above, + +```bash +$ kubectl create -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/examples/mssqlserver/scaling/horizontal-scaling/mssql-ag-cluster.yaml +mssqlserver.kubedb.com/mssql-ag-cluster created +``` + +**Wait for the cluster to be ready:** + +`KubeDB` operator watches for `MSSQLServer` objects using Kubernetes API. When a `MSSQLServer` object is created, `KubeDB` operator will create a new PetSet, Services, and Secrets, etc. A secret called `mssql-ag-cluster-auth` (format: {mssqlserver-object-name}-auth) will be created storing the password for mssqlserver superuser. +Now, watch `MSSQLServer` is going to `Running` state and also watch `PetSet` and its pod is created and going to `Running` state, + +```bash +$ watch kubectl get ms,petset,pods -n demo +Every 2.0s: kubectl get ms,petset,pods -n demo + +NAME VERSION STATUS AGE +mssqlserver.kubedb.com/mssql-ag-cluster 2022-cu12 Ready 2m52s + +NAME AGE +petset.apps.k8s.appscode.com/mssql-ag-cluster 2m11s + +NAME READY STATUS RESTARTS AGE +pod/mssql-ag-cluster-0 2/2 Running 0 2m11s +pod/mssql-ag-cluster-1 2/2 Running 0 2m6s + +``` + +Let's verify that the PetSet's pods have created the availability group cluster successfully, + +```bash +$ kubectl get secrets -n demo mssql-ag-cluster-auth -o jsonpath='{.data.\username}' | base64 -d +sa +$ kubectl get secrets -n demo mssql-ag-cluster-auth -o jsonpath='{.data.\password}' | base64 -d +123KKxgOXuOkP206 +``` + +Now, connect to the database using username and password, check the name of the created availability group, replicas of the availability group and see if databases are added to the availability group. +```bash +$ kubectl exec -it -n demo mssql-ag-cluster-0 -c mssql -- bash +mssql@mssql-ag-cluster-2:/$ /opt/mssql-tools/bin/sqlcmd -S localhost -U sa -P "123KKxgOXuOkP206" +1> select name from sys.databases +2> go +name +---------------------------------------------------------------------------------- +master +tempdb +model +msdb +agdb1 +agdb2 +kubedb_system + +(5 rows affected) +1> SELECT name FROM sys.availability_groups +2> go +name +---------------------------------------------------------------------------- +mssqlagcluster + +(1 rows affected) +1> select replica_server_name from sys.availability_replicas; +2> go +replica_server_name +------------------------------------------------------------------------------------------- +mssql-ag-cluster-0 +mssql-ag-cluster-1 +(3 rows affected) +1> select database_name from sys.availability_databases_cluster; +2> go +database_name +------------------------------------------------------------------------------------------ +agdb1 +agdb2 + +(2 rows affected) + +``` + + +So, we can see that our cluster has 2 replicas. Now, we are ready to apply the horizontal scale to this MSSQLServer cluster. + +#### Scale Up + +Here, we are going to add 1 replica in our Cluster using horizontal scaling. + +**Create MSSQLServerOpsRequest:** + +To scale up your cluster, you have to create a `MSSQLServerOpsRequest` CR with your desired number of replicas after scaling. Below is the YAML of the `MSSQLServerOpsRequest` CR that we are going to create, + +```yaml +apiVersion: ops.kubedb.com/v1alpha1 +kind: MSSQLServerOpsRequest +metadata: + name: ms-scale-horizontal + namespace: demo +spec: + type: HorizontalScaling + databaseRef: + name: mssql-ag-cluster + horizontalScaling: + replicas: 3 +``` + +Here, + +- `spec.databaseRef.name` specifies that we are performing operation on `mssql-ag-cluster`. +- `spec.type` specifies that we are performing `HorizontalScaling` on our database. +- `spec.horizontalScaling.replicas` specifies the expected number of replicas after the scaling. + +Let's create the `MSSQLServerOpsRequest` CR we have shown above, + +```bash +$ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/examples/mssqlserver/scaling/horizontal-scaling/msops-hscale-up.yaml +mssqlserveropsrequest.ops.kubedb.com/msops-hscale-up created +``` + +**Verify Scale-Up Succeeded:** + +If everything goes well, `KubeDB` Ops Manager will scale up the PetSet's `Pod`. After the scaling process is completed successfully, the `KubeDB` Ops Manager updates the replicas of the `MSSQLServer` object. + +First, we will wait for `MSSQLServerOpsRequest` to be successful. Run the following command to watch `MSSQLServerOpsRequest` cr, + +```bash +$ watch kubectl get mssqlserveropsrequest -n demo msops-hscale-up +Every 2.0s: kubectl get mssqlserveropsrequest -n demo msops-hscale-up + +NAME TYPE STATUS AGE +msops-hscale-up HorizontalScaling Successful 76s + +``` + +You can see from the above output that the `MSSQLServerOpsRequest` has succeeded. If we describe the `MSSQLServerOpsRequest`, we will see that the `MSSQLServer` cluster is scaled up. + +```bash +kubectl describe mssqlserveropsrequest -n demo msops-hscale-up +Name: msops-hscale-up +Namespace: demo +Labels: +Annotations: +API Version: ops.kubedb.com/v1alpha1 +Kind: MSSQLServerOpsRequest +Metadata: + Creation Timestamp: 2024-10-24T15:09:36Z + Generation: 1 + Resource Version: 752963 + UID: 43193e49-8461-4e14-b1c1-7aaa33d0251a +Spec: + Apply: IfReady + Database Ref: + Name: mssql-ag-cluster + Horizontal Scaling: + Replicas: 3 + Type: HorizontalScaling +Status: + Conditions: + Last Transition Time: 2024-10-24T15:09:36Z + Message: MSSQLServer ops-request has started to horizontally scaling the nodes + Observed Generation: 1 + Reason: HorizontalScaling + Status: True + Type: HorizontalScaling + Last Transition Time: 2024-10-24T15:09:39Z + Message: Successfully paused database + Observed Generation: 1 + Reason: DatabasePauseSucceeded + Status: True + Type: DatabasePauseSucceeded + Last Transition Time: 2024-10-24T15:10:29Z + Message: Successfully Scaled Up Node + Observed Generation: 1 + Reason: HorizontalScaleUp + Status: True + Type: HorizontalScaleUp + Last Transition Time: 2024-10-24T15:09:44Z + Message: get current leader; ConditionStatus:True; PodName:mssql-ag-cluster-0 + Observed Generation: 1 + Status: True + Type: GetCurrentLeader--mssql-ag-cluster-0 + Last Transition Time: 2024-10-24T15:09:44Z + Message: get raft node; ConditionStatus:True; PodName:mssql-ag-cluster-0 + Observed Generation: 1 + Status: True + Type: GetRaftNode--mssql-ag-cluster-0 + Last Transition Time: 2024-10-24T15:09:44Z + Message: add raft node; ConditionStatus:True; PodName:mssql-ag-cluster-2 + Observed Generation: 1 + Status: True + Type: AddRaftNode--mssql-ag-cluster-2 + Last Transition Time: 2024-10-24T15:09:49Z + Message: patch petset; ConditionStatus:True; PodName:mssql-ag-cluster-2 + Observed Generation: 1 + Status: True + Type: PatchPetset--mssql-ag-cluster-2 + Last Transition Time: 2024-10-24T15:09:49Z + Message: mssql-ag-cluster already has desired replicas + Observed Generation: 1 + Reason: HorizontalScale + Status: True + Type: HorizontalScale + Last Transition Time: 2024-10-24T15:09:59Z + Message: is pod ready; ConditionStatus:True; PodName:mssql-ag-cluster-2 + Observed Generation: 1 + Status: True + Type: IsPodReady--mssql-ag-cluster-2 + Last Transition Time: 2024-10-24T15:10:19Z + Message: is mssql running; ConditionStatus:True + Observed Generation: 1 + Status: True + Type: IsMssqlRunning + Last Transition Time: 2024-10-24T15:10:24Z + Message: ensure replica join; ConditionStatus:True + Observed Generation: 1 + Status: True + Type: EnsureReplicaJoin + Last Transition Time: 2024-10-24T15:10:34Z + Message: successfully reconciled the MSSQLServer with modified replicas + Observed Generation: 1 + Reason: UpdatePetSets + Status: True + Type: UpdatePetSets + Last Transition Time: 2024-10-24T15:10:35Z + Message: Successfully updated MSSQLServer + Observed Generation: 1 + Reason: UpdateDatabase + Status: True + Type: UpdateDatabase + Last Transition Time: 2024-10-24T15:10:35Z + Message: Successfully completed the HorizontalScaling for MSSQLServer + Observed Generation: 1 + Reason: Successful + Status: True + Type: Successful + Observed Generation: 1 + Phase: Successful +Events: + Type Reason Age From Message + ---- ------ ---- ---- ------- + Normal Starting 2m22s KubeDB Ops-manager Operator Start processing for MSSQLServerOpsRequest: demo/msops-hscale-up + Normal Starting 2m22s KubeDB Ops-manager Operator Pausing MSSQLServer database: demo/mssql-ag-cluster + Normal Successful 2m22s KubeDB Ops-manager Operator Successfully paused MSSQLServer database: demo/mssql-ag-cluster for MSSQLServerOpsRequest: msops-hscale-up + Warning get current leader; ConditionStatus:True; PodName:mssql-ag-cluster-0 2m14s KubeDB Ops-manager Operator get current leader; ConditionStatus:True; PodName:mssql-ag-cluster-0 + Warning get raft node; ConditionStatus:True; PodName:mssql-ag-cluster-0 2m14s KubeDB Ops-manager Operator get raft node; ConditionStatus:True; PodName:mssql-ag-cluster-0 + Warning add raft node; ConditionStatus:True; PodName:mssql-ag-cluster-2 2m14s KubeDB Ops-manager Operator add raft node; ConditionStatus:True; PodName:mssql-ag-cluster-2 + Warning get current leader; ConditionStatus:True; PodName:mssql-ag-cluster-0 2m9s KubeDB Ops-manager Operator get current leader; ConditionStatus:True; PodName:mssql-ag-cluster-0 + Warning get raft node; ConditionStatus:True; PodName:mssql-ag-cluster-0 2m9s KubeDB Ops-manager Operator get raft node; ConditionStatus:True; PodName:mssql-ag-cluster-0 + Warning patch petset; ConditionStatus:True; PodName:mssql-ag-cluster-2 2m9s KubeDB Ops-manager Operator patch petset; ConditionStatus:True; PodName:mssql-ag-cluster-2 + Warning get current leader; ConditionStatus:True; PodName:mssql-ag-cluster-0 2m4s KubeDB Ops-manager Operator get current leader; ConditionStatus:True; PodName:mssql-ag-cluster-0 + Warning is pod ready; ConditionStatus:False; PodName:mssql-ag-cluster-2 2m4s KubeDB Ops-manager Operator is pod ready; ConditionStatus:False; PodName:mssql-ag-cluster-2 + Warning get current leader; ConditionStatus:True; PodName:mssql-ag-cluster-0 119s KubeDB Ops-manager Operator get current leader; ConditionStatus:True; PodName:mssql-ag-cluster-0 + Warning is pod ready; ConditionStatus:True; PodName:mssql-ag-cluster-2 119s KubeDB Ops-manager Operator is pod ready; ConditionStatus:True; PodName:mssql-ag-cluster-2 + Warning is mssql running; ConditionStatus:False 109s KubeDB Ops-manager Operator is mssql running; ConditionStatus:False + Warning get current leader; ConditionStatus:True; PodName:mssql-ag-cluster-0 109s KubeDB Ops-manager Operator get current leader; ConditionStatus:True; PodName:mssql-ag-cluster-0 + Warning is pod ready; ConditionStatus:True; PodName:mssql-ag-cluster-2 109s KubeDB Ops-manager Operator is pod ready; ConditionStatus:True; PodName:mssql-ag-cluster-2 + Warning get current leader; ConditionStatus:True; PodName:mssql-ag-cluster-0 99s KubeDB Ops-manager Operator get current leader; ConditionStatus:True; PodName:mssql-ag-cluster-0 + Warning is pod ready; ConditionStatus:True; PodName:mssql-ag-cluster-2 99s KubeDB Ops-manager Operator is pod ready; ConditionStatus:True; PodName:mssql-ag-cluster-2 + Warning is mssql running; ConditionStatus:True 99s KubeDB Ops-manager Operator is mssql running; ConditionStatus:True + Warning ensure replica join; ConditionStatus:False 98s KubeDB Ops-manager Operator ensure replica join; ConditionStatus:False + Warning get current leader; ConditionStatus:True; PodName:mssql-ag-cluster-0 94s KubeDB Ops-manager Operator get current leader; ConditionStatus:True; PodName:mssql-ag-cluster-0 + Warning is pod ready; ConditionStatus:True; PodName:mssql-ag-cluster-2 94s KubeDB Ops-manager Operator is pod ready; ConditionStatus:True; PodName:mssql-ag-cluster-2 + Warning is mssql running; ConditionStatus:True 94s KubeDB Ops-manager Operator is mssql running; ConditionStatus:True + Warning ensure replica join; ConditionStatus:True 94s KubeDB Ops-manager Operator ensure replica join; ConditionStatus:True + Warning get current leader; ConditionStatus:True; PodName:mssql-ag-cluster-0 89s KubeDB Ops-manager Operator get current leader; ConditionStatus:True; PodName:mssql-ag-cluster-0 + Normal HorizontalScaleUp 89s KubeDB Ops-manager Operator Successfully Scaled Up Node + Normal UpdatePetSets 84s KubeDB Ops-manager Operator successfully reconciled the MSSQLServer with modified replicas + Normal UpdateDatabase 83s KubeDB Ops-manager Operator Successfully updated MSSQLServer + Normal Starting 83s KubeDB Ops-manager Operator Resuming MSSQLServer database: demo/mssql-ag-cluster + Normal Successful 83s KubeDB Ops-manager Operator Successfully resumed MSSQLServer database: demo/mssql-ag-cluster for MSSQLServerOpsRequest: msops-hscale-up + Normal UpdateDatabase 83s KubeDB Ops-manager Operator Successfully updated MSSQLServer +``` + +Now, we are going to verify whether the number of replicas has increased to meet up the desired state. So let's check the new pods coordinator container's logs to see if this is joined in the cluster as new replica. + +```bash +$ kubectl logs -f -n demo mssql-ag-cluster-2 -c mssql-coordinator +raft2024/10/24 15:09:55 INFO: 3 switched to configuration voters=(1 2 3) +raft2024/10/24 15:09:55 INFO: 3 switched to configuration voters=(1 2 3) +raft2024/10/24 15:09:55 INFO: 3 switched to configuration voters=(1 2 3) +raft2024/10/24 15:09:55 INFO: 3 [term: 1] received a MsgHeartbeat message with higher term from 1 [term: 3] +raft2024/10/24 15:09:55 INFO: 3 became follower at term 3 +raft2024/10/24 15:09:55 INFO: raft.node: 3 elected leader 1 at term 3 +I1024 15:09:56.855261 1 mssql.go:94] new elected primary is :mssql-ag-cluster-0. +I1024 15:09:56.864197 1 mssql.go:120] New primary is ready to accept connections... +I1024 15:09:56.864213 1 mssql.go:171] lastLeaderId : 0, currentLeaderId : 1 +I1024 15:09:56.864230 1 on_leader_change.go:47] New Leader elected. +I1024 15:09:56.864237 1 on_leader_change.go:82] This pod is now a secondary according to raft +I1024 15:09:56.864243 1 on_leader_change.go:100] instance demo/mssql-ag-cluster-2 running according to the role +I1024 15:09:56.864317 1 utils.go:219] /scripts/run_signal.txt file created successfully +E1024 15:09:56.935767 1 exec_utils.go:65] Error while trying to get process output from the pod. Error: could not execute: command terminated with exit code 1 +I1024 15:09:56.935794 1 on_leader_change.go:110] mssql is not ready yet +I1024 15:10:07.980792 1 on_leader_change.go:110] mssql is not ready yet +I1024 15:10:18.049036 1 on_leader_change.go:110] mssql is not ready yet +I1024 15:10:18.116939 1 on_leader_change.go:118] mssql is ready now +I1024 15:10:18.127315 1 ag_status.go:43] No Availability Group found +I1024 15:10:18.127336 1 ag.go:79] Joining Availability Group... +I1024 15:10:24.638144 1 on_leader_change.go:94] Successfully patched label of demo/mssql-ag-cluster-2 to secondary +I1024 15:10:24.650611 1 health.go:50] Sequence Number updated. new sequenceNumber = 4294967322, previous sequenceNumber = 0 +I1024 15:10:24.650632 1 health.go:51] 1:1A (4294967322) +``` + + +Now, connect to the database, check updated configurations of the availability group cluster. +```bash +$ kubectl exec -it -n demo mssql-ag-cluster-2 -c mssql -- bash +mssql@mssql-ag-cluster-2:/$ /opt/mssql-tools/bin/sqlcmd -S localhost -U sa -P "123KKxgOXuOkP206" +1> SELECT name FROM sys.availability_groups +2> go +name +---------------------------------------------------------------------------- +mssqlagcluster + +(1 rows affected) +1> select replica_server_name from sys.availability_replicas; +2> go +replica_server_name +------------------------------------------------------------------------------------------- +mssql-ag-cluster-0 +mssql-ag-cluster-1 + +mssql-ag-cluster-2 + +(3 rows affected) +1> select database_name from sys.availability_databases_cluster; +2> go +database_name +------------------------------------------------------------------------------------------ +agdb1 +agdb2 + +(2 rows affected) +``` + +#### Scale Down + +Here, we are going to remove 1 replica from our cluster using horizontal scaling. + +**Create MSSQLServerOpsRequest:** + +To scale down your cluster, you have to create a `MSSQLServerOpsRequest` CR with your desired number of replicas after scaling. Below is the YAML of the `MSSQLServerOpsRequest` CR that we are going to create, + +```yaml +apiVersion: ops.kubedb.com/v1alpha1 +kind: MSSQLServerOpsRequest +metadata: + name: msops-hscale-down + namespace: demo +spec: + type: HorizontalScaling + databaseRef: + name: mssql-ag-cluster + horizontalScaling: + replicas: 2 +``` + +Let's create the `MSSQLServerOpsRequest` CR we have shown above, + +```bash +$ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/examples/mssqlserver/scaling/horizontal-scaling/msops-hscale-down.yaml +mssqlserveropsrequest.ops.kubedb.com/msops-hscale-down created +``` + +**Verify Scale-down Succeeded:** + +If everything goes well, `KubeDB` Ops Manager will scale down the PetSet's `Pod`. After the scaling process is completed successfully, the `KubeDB` Ops Manager updates the replicas of the `MSSQLServer` object. + +Now, we will wait for `MSSQLServerOpsRequest` to be successful. Run the following command to watch `MSSQLServerOpsRequest` cr, + +```bash +$ watch kubectl get mssqlserveropsrequest -n demo msops-hscale-down +Every 2.0s: kubectl get mssqlserveropsrequest -n demo msops-hscale-down + +NAME TYPE STATUS AGE +msops-hscale-down HorizontalScaling Successful 98s +``` + +You can see from the above output that the `MSSQLServerOpsRequest` has succeeded. If we describe the `MSSQLServerOpsRequest`, we shall see that the `MSSQLServer` cluster is scaled down. + +```bash +$ kubectl describe mssqlserveropsrequest -n demo msops-hscale-down +Name: msops-hscale-down +Namespace: demo +Labels: +Annotations: +API Version: ops.kubedb.com/v1alpha1 +Kind: MSSQLServerOpsRequest +Metadata: + Creation Timestamp: 2024-10-24T15:22:54Z + Generation: 1 + Resource Version: 754237 + UID: c5dc6971-5f60-4736-992a-8fdf5a2911d9 +Spec: + Apply: IfReady + Database Ref: + Name: mssql-ag-cluster + Horizontal Scaling: + Replicas: 2 + Type: HorizontalScaling +Status: + Conditions: + Last Transition Time: 2024-10-24T15:22:54Z + Message: MSSQLServer ops-request has started to horizontally scaling the nodes + Observed Generation: 1 + Reason: HorizontalScaling + Status: True + Type: HorizontalScaling + Last Transition Time: 2024-10-24T15:23:06Z + Message: Successfully paused database + Observed Generation: 1 + Reason: DatabasePauseSucceeded + Status: True + Type: DatabasePauseSucceeded + Last Transition Time: 2024-10-24T15:24:06Z + Message: Successfully Scaled Down Node + Observed Generation: 1 + Reason: HorizontalScaleDown + Status: True + Type: HorizontalScaleDown + Last Transition Time: 2024-10-24T15:23:21Z + Message: get current raft leader; ConditionStatus:True; PodName:mssql-ag-cluster-0 + Observed Generation: 1 + Status: True + Type: GetCurrentRaftLeader--mssql-ag-cluster-0 + Last Transition Time: 2024-10-24T15:23:11Z + Message: get raft node; ConditionStatus:True; PodName:mssql-ag-cluster-0 + Observed Generation: 1 + Status: True + Type: GetRaftNode--mssql-ag-cluster-0 + Last Transition Time: 2024-10-24T15:23:11Z + Message: remove raft node; ConditionStatus:True; PodName:mssql-ag-cluster-2 + Observed Generation: 1 + Status: True + Type: RemoveRaftNode--mssql-ag-cluster-2 + Last Transition Time: 2024-10-24T15:23:21Z + Message: patch petset; ConditionStatus:True; PodName:mssql-ag-cluster-2 + Observed Generation: 1 + Status: True + Type: PatchPetset--mssql-ag-cluster-2 + Last Transition Time: 2024-10-24T15:23:21Z + Message: mssql-ag-cluster already has desired replicas + Observed Generation: 1 + Reason: HorizontalScale + Status: True + Type: HorizontalScale + Last Transition Time: 2024-10-24T15:23:26Z + Message: get pod; ConditionStatus:False + Observed Generation: 1 + Status: False + Type: GetPod + Last Transition Time: 2024-10-24T15:23:56Z + Message: get pod; ConditionStatus:True; PodName:mssql-ag-cluster-2 + Observed Generation: 1 + Status: True + Type: GetPod--mssql-ag-cluster-2 + Last Transition Time: 2024-10-24T15:23:56Z + Message: delete pvc; ConditionStatus:True; PodName:mssql-ag-cluster-2 + Observed Generation: 1 + Status: True + Type: DeletePvc--mssql-ag-cluster-2 + Last Transition Time: 2024-10-24T15:24:01Z + Message: get pvc; ConditionStatus:True + Observed Generation: 1 + Status: True + Type: GetPvc + Last Transition Time: 2024-10-24T15:24:01Z + Message: ag node remove; ConditionStatus:True + Observed Generation: 1 + Status: True + Type: AgNodeRemove + Last Transition Time: 2024-10-24T15:24:11Z + Message: successfully reconciled the MSSQLServer with modified replicas + Observed Generation: 1 + Reason: UpdatePetSets + Status: True + Type: UpdatePetSets + Last Transition Time: 2024-10-24T15:24:11Z + Message: Successfully updated MSSQLServer + Observed Generation: 1 + Reason: UpdateDatabase + Status: True + Type: UpdateDatabase + Last Transition Time: 2024-10-24T15:24:11Z + Message: Successfully completed the HorizontalScaling for MSSQLServer + Observed Generation: 1 + Reason: Successful + Status: True + Type: Successful + Observed Generation: 1 + Phase: Successful +Events: + Type Reason Age From Message + ---- ------ ---- ---- ------- + Normal Starting 2m1s KubeDB Ops-manager Operator Start processing for MSSQLServerOpsRequest: demo/msops-hscale-down + Normal Starting 2m1s KubeDB Ops-manager Operator Pausing MSSQLServer database: demo/mssql-ag-cluster + Normal Successful 2m1s KubeDB Ops-manager Operator Successfully paused MSSQLServer database: demo/mssql-ag-cluster for MSSQLServerOpsRequest: msops-hscale-down + Warning get current raft leader; ConditionStatus:True; PodName:mssql-ag-cluster-0 104s KubeDB Ops-manager Operator get current raft leader; ConditionStatus:True; PodName:mssql-ag-cluster-0 + Warning get raft node; ConditionStatus:True; PodName:mssql-ag-cluster-0 104s KubeDB Ops-manager Operator get raft node; ConditionStatus:True; PodName:mssql-ag-cluster-0 + Warning remove raft node; ConditionStatus:True; PodName:mssql-ag-cluster-2 104s KubeDB Ops-manager Operator remove raft node; ConditionStatus:True; PodName:mssql-ag-cluster-2 + Warning get current raft leader; ConditionStatus:True; PodName:mssql-ag-cluster-0 94s KubeDB Ops-manager Operator get current raft leader; ConditionStatus:True; PodName:mssql-ag-cluster-0 + Warning get raft node; ConditionStatus:True; PodName:mssql-ag-cluster-0 94s KubeDB Ops-manager Operator get raft node; ConditionStatus:True; PodName:mssql-ag-cluster-0 + Warning patch petset; ConditionStatus:True; PodName:mssql-ag-cluster-2 94s KubeDB Ops-manager Operator patch petset; ConditionStatus:True; PodName:mssql-ag-cluster-2 + Warning get pod; ConditionStatus:True; PodName:mssql-ag-cluster-2 59s KubeDB Ops-manager Operator get pod; ConditionStatus:True; PodName:mssql-ag-cluster-2 + Warning delete pvc; ConditionStatus:True; PodName:mssql-ag-cluster-2 59s KubeDB Ops-manager Operator delete pvc; ConditionStatus:True; PodName:mssql-ag-cluster-2 + Warning get pvc; ConditionStatus:False 59s KubeDB Ops-manager Operator get pvc; ConditionStatus:False + Warning get pod; ConditionStatus:True; PodName:mssql-ag-cluster-2 54s KubeDB Ops-manager Operator get pod; ConditionStatus:True; PodName:mssql-ag-cluster-2 + Warning delete pvc; ConditionStatus:True; PodName:mssql-ag-cluster-2 54s KubeDB Ops-manager Operator delete pvc; ConditionStatus:True; PodName:mssql-ag-cluster-2 + Warning get pvc; ConditionStatus:True 54s KubeDB Ops-manager Operator get pvc; ConditionStatus:True + Warning ag node remove; ConditionStatus:True 54s KubeDB Ops-manager Operator ag node remove; ConditionStatus:True + Normal HorizontalScaleDown 49s KubeDB Ops-manager Operator Successfully Scaled Down Node + Normal UpdatePetSets 44s KubeDB Ops-manager Operator successfully reconciled the MSSQLServer with modified replicas + Normal UpdateDatabase 44s KubeDB Ops-manager Operator Successfully updated MSSQLServer + Normal Starting 44s KubeDB Ops-manager Operator Resuming MSSQLServer database: demo/mssql-ag-cluster + Normal Successful 44s KubeDB Ops-manager Operator Successfully resumed MSSQLServer database: demo/mssql-ag-cluster for MSSQLServerOpsRequest: msops-hscale-down + Normal UpdateDatabase 44s KubeDB Ops-manager Operator Successfully updated MSSQLServer +``` + +Now, we are going to verify whether the number of replicas has decreased to meet up the desired state, Let's check, the mssqlserver status if it's ready then the scale-down is successful. + +```bash +$ kubectl get ms,petset,pods -n demo +NAME VERSION STATUS AGE +mssqlserver.kubedb.com/mssql-ag-cluster 2022-cu12 Ready 39m + +NAME AGE +petset.apps.k8s.appscode.com/mssql-ag-cluster 38m + +NAME READY STATUS RESTARTS AGE +pod/mssql-ag-cluster-0 2/2 Running 0 38m +pod/mssql-ag-cluster-1 2/2 Running 0 38m +``` + + +Now, connect to the database, check updated configurations of the availability group cluster. +```bash +$ kubectl exec -it -n demo mssql-ag-cluster-0 -c mssql -- bash +mssql@mssql-ag-cluster-0:/$ /opt/mssql-tools/bin/sqlcmd -S localhost -U sa -P "123KKxgOXuOkP206" +1> SELECT name FROM sys.availability_groups +2> go +name +---------------------------------------------------- +mssqlagcluster + +(1 rows affected) +1> select replica_server_name from sys.availability_replicas; +2> go +replica_server_name +-------------------------------------- +mssql-ag-cluster-0 +mssql-ag-cluster-1 + +(2 rows affected) +``` + +You can see above that our `MSSQLServer` cluster now has a total of 2 replicas. It verifies that we have successfully scaled down. + +## Cleaning Up + +To clean up the Kubernetes resources created by this tutorial, run: + +```bash +kubectl delete ms -n demo mssql-ag-cluster +kubectl delete mssqlserveropsrequest -n demo msops-hscale-up +kubectl delete mssqlserveropsrequest -n demo msops-hscale-down +kubectl delete issuer -n demo mssqlserver-ca-issuer +kubectl delete secret -n demo mssqlserver-ca +kubectl delete ns demo +``` diff --git a/content/docs/v2024.9.30/guides/mssqlserver/scaling/horizontal-scaling/overview.md b/content/docs/v2024.9.30/guides/mssqlserver/scaling/horizontal-scaling/overview.md new file mode 100644 index 0000000000..6aac3101f4 --- /dev/null +++ b/content/docs/v2024.9.30/guides/mssqlserver/scaling/horizontal-scaling/overview.md @@ -0,0 +1,67 @@ +--- +title: MSSQLServer Horizontal Scaling Overview +menu: + docs_v2024.9.30: + identifier: ms-scaling-horizontal-overview + name: Overview + parent: ms-scaling-horizontal + weight: 10 +menu_name: docs_v2024.9.30 +section_menu_id: guides +info: + autoscaler: v0.33.0 + cli: v0.48.0 + dashboard: v0.24.0 + installer: v2024.9.30 + ops-manager: v0.35.0 + provisioner: v0.48.0 + schema-manager: v0.24.0 + ui-server: v0.24.0 + version: v2024.9.30 + webhook-server: v0.24.0 +--- + +> New to KubeDB? Please start [here](/docs/v2024.9.30/README). + +# Horizontal Scaling Overview + +This guide will give you an overview of how `KubeDB` Ops Manager scales up/down the number of members of a `MSSQLServer`. + +## Before You Begin + +- You should be familiar with the following `KubeDB` concepts: + - [MSSQLServer](/docs/v2024.9.30/guides/mssqlserver/concepts/mssqlserver) + - [MSSQLServerOpsRequest](/docs/v2024.9.30/guides/mssqlserver/concepts/opsrequest) + +## How Horizontal Scaling Process Works + +The following diagram shows how `KubeDB` Ops Manager used to scale up the number of members of a `MSSQLServer` cluster. Open the image in a new tab to see the enlarged version. + +
+ Horizontal scaling Flow +
Fig: Horizontal scaling process of MSSQLServer
+
+ +The horizontal scaling process consists of the following steps: + +1. At first, a user creates a `MSSQLServer` CR. + +2. `KubeDB` provisioner operator watches for the `MSSQLServer` CR. + +3. When it finds one, it creates a `PetSet` and related necessary stuff like secret, service, etc. + +4. Then, in order to scale the cluster up or down, the user creates a `MSSQLServerOpsRequest` CR with the desired number of replicas after scaling. + +5. `KubeDB` Ops Manager watches for `MSSQLServerOpsRequest`. + +6. When it finds one, it halts the `MSSQLServer` object so that the `KubeDB` provisioner operator doesn't perform any operation on the `MSSQLServer` during the scaling process. + +7. Then `KubeDB` Ops Manager will add nodes in case of scale up or remove nodes in case of scale down. + +8. Then the `KubeDB` Ops Manager will scale the PetSet replicas to reach the expected number of replicas for the cluster. + +9. After successful scaling of the PetSet's replica, the `KubeDB` Ops Manager updates the `spec.replicas` field of `MSSQLServer` object to reflect the updated cluster state. + +10. After successful scaling of the `MSSQLServer` replicas, the `KubeDB` Ops Manager resumes the `MSSQLServer` object so that the `KubeDB` provisioner operator can resume its usual operations. + +In the next doc, we are going to show a step-by-step guide on scaling of a MSSQLServer cluster using Horizontal Scaling. \ No newline at end of file diff --git a/content/docs/v2024.9.30/guides/mssqlserver/scaling/vertical-scaling/_index.md b/content/docs/v2024.9.30/guides/mssqlserver/scaling/vertical-scaling/_index.md new file mode 100644 index 0000000000..2e2dbbf86d --- /dev/null +++ b/content/docs/v2024.9.30/guides/mssqlserver/scaling/vertical-scaling/_index.md @@ -0,0 +1,22 @@ +--- +title: Vertical Scaling +menu: + docs_v2024.9.30: + identifier: ms-scaling-vertical + name: Vertical Scaling + parent: ms-scaling + weight: 20 +menu_name: docs_v2024.9.30 +info: + autoscaler: v0.33.0 + cli: v0.48.0 + dashboard: v0.24.0 + installer: v2024.9.30 + ops-manager: v0.35.0 + provisioner: v0.48.0 + schema-manager: v0.24.0 + ui-server: v0.24.0 + version: v2024.9.30 + webhook-server: v0.24.0 +--- + diff --git a/content/docs/v2024.9.30/guides/mssqlserver/scaling/vertical-scaling/ag_cluster.md b/content/docs/v2024.9.30/guides/mssqlserver/scaling/vertical-scaling/ag_cluster.md new file mode 100644 index 0000000000..9db1c7a561 --- /dev/null +++ b/content/docs/v2024.9.30/guides/mssqlserver/scaling/vertical-scaling/ag_cluster.md @@ -0,0 +1,466 @@ +--- +title: Vertical Scaling MSSQLServer +menu: + docs_v2024.9.30: + identifier: ms-scaling-vertical-ag-cluster + name: Availability Group (HA Cluster) + parent: ms-scaling-vertical + weight: 20 +menu_name: docs_v2024.9.30 +section_menu_id: guides +info: + autoscaler: v0.33.0 + cli: v0.48.0 + dashboard: v0.24.0 + installer: v2024.9.30 + ops-manager: v0.35.0 + provisioner: v0.48.0 + schema-manager: v0.24.0 + ui-server: v0.24.0 + version: v2024.9.30 + webhook-server: v0.24.0 +--- + +> New to KubeDB? Please start [here](/docs/v2024.9.30/README). + +# Vertical Scale SQL Server Availability Group (HA Cluster) + +This guide will show you how to use `kubeDB-Ops-Manager` to update the resources of a SQL Server 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/v2024.9.30/setup/README). 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/). + + +- You should be familiar with the following `KubeDB` concepts: + - [MSSQLServer](/docs/v2024.9.30/guides/mssqlserver/concepts/mssqlserver) + - [MSSQLServerOpsRequest](/docs/v2024.9.30/guides/mssqlserver/concepts/opsrequest) + - [Vertical Scaling Overview](/docs/v2024.9.30/guides/mssqlserver/scaling/vertical-scaling/overview) + +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 +``` + +> **Note:** YAML files used in this tutorial are stored in [docs/examples/mssqlserver/scaling/vertical-scaling](https://github.com/kubedb/docs/tree/{{< param "info.version" >}}/docs/examples/mssqlserver/scaling/vertical-scaling) directory of [kubedb/doc](https://github.com/kubedb/docs) repository. + +### Apply Vertical Scaling on MSSQLServer Availability Group Cluster + +Here, we are going to deploy a `MSSQLServer` instance using a supported version by `KubeDB` operator. Then we are going to apply vertical scaling on it. + +**Find supported MSSQLServer Version:** + +When you have installed `KubeDB`, it has created `MSSQLServerVersion` CR for all supported `MSSQLServer` versions. Let's check the supported MSSQLServer versions, + +```bash +$ kubectl get mssqlserverversion +NAME VERSION DB_IMAGE DEPRECATED AGE +2022-cu12 2022 mcr.microsoft.com/mssql/server:2022-CU12-ubuntu-22.04 3d21h +2022-cu14 2022 mcr.microsoft.com/mssql/server:2022-CU14-ubuntu-22.04 3d21h +``` + +The version above that does not show `DEPRECATED` `true` is supported by `KubeDB` for `MSSQLServer`. You can use any non-deprecated version. Here, we are going to create a mssqlserver using non-deprecated `MSSQLServer` version `2022-cu12`. + + +At first, we need to create an Issuer/ClusterIssuer which will be used to generate the certificate used for TLS configurations. + +#### 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 +``` + +**Deploy MSSQLServer Availability Group Cluster:** + +In this section, we are going to deploy a MSSQLServer instance. Then, in the next section, we will update the resources of the database server using vertical scaling. +Below is the YAML of the `MSSQLServer` CR that we are going to create, + +```yaml +apiVersion: kubedb.com/v1alpha2 +kind: MSSQLServer +metadata: + name: mssql-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: 1 + memory: "2Gi" + storageType: Durable + storage: + storageClassName: "standard" + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + deletionPolicy: WipeOut +``` + +Let's create the `MSSQLServer` CR we have shown above, + +```bash +$ kubectl create -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/examples/mssqlserver/scaling/vertical-scaling/mssql-ag-cluster.yaml +mssqlserver.kubedb.com/mssql-ag-cluster created +``` + + +**Check mssqlserver Ready to Scale:** + +`KubeDB` watches for `MSSQLServer` objects using Kubernetes API. When a `MSSQLServer` object is created, `KubeDB` will create a new PetSet, Services, and Secrets, etc. +Now, watch `MSSQLServer` is going to be in `Running` state and also watch `PetSet` and its pod is created and going to be in `Running` state, + + +```bash +$ watch kubectl get ms,petset,pods -n demo +Every 2.0s: kubectl get ms,petset,pods -n demo + +NAME VERSION STATUS AGE +mssqlserver.kubedb.com/mssql-ag-cluster 2022-cu12 Ready 4m40s + +NAME AGE +petset.apps.k8s.appscode.com/mssql-ag-cluster 3m57s + +NAME READY STATUS RESTARTS AGE +pod/mssql-ag-cluster-0 2/2 Running 0 3m57s +pod/mssql-ag-cluster-1 2/2 Running 0 3m51s +pod/mssql-ag-cluster-2 2/2 Running 0 3m46s +``` + +Let's check pod's `mssql` container's resources, `mssql` container is the first container So it's index will be 0. + +```bash +$ kubectl get pod -n demo mssql-ag-cluster-0 -o json | jq '.spec.containers[0].resources' +{ + "limits": { + "cpu": "1", + "memory": "2Gi" + }, + "requests": { + "cpu": "500m", + "memory": "1536Mi" + } +} +$ kubectl get pod -n demo mssql-ag-cluster-1 -o json | jq '.spec.containers[0].resources' +{ + "limits": { + "cpu": "1", + "memory": "2Gi" + }, + "requests": { + "cpu": "500m", + "memory": "1536Mi" + } +} +$ kubectl get pod -n demo mssql-ag-cluster-2 -o json | jq '.spec.containers[0].resources' +{ + "limits": { + "cpu": "1", + "memory": "2Gi" + }, + "requests": { + "cpu": "500m", + "memory": "1536Mi" + } +} +``` + +Now, We are ready to apply a vertical scale on this mssqlserver database. + +#### Vertical Scaling + +Here, we are going to update the resources of the mssqlserver to meet up with the desired resources after scaling. + +**Create MSSQLServerOpsRequest:** + +In order to update the resources of your database, you have to create a `MSSQLServerOpsRequest` CR with your desired resources for scaling. Below is the YAML of the `MSSQLServerOpsRequest` CR that we are going to create, + + +```yaml +apiVersion: ops.kubedb.com/v1alpha1 +kind: MSSQLServerOpsRequest +metadata: + name: mops-vscale-ag-cluster + namespace: demo +spec: + type: VerticalScaling + databaseRef: + name: mssql-ag-cluster + verticalScaling: + mssqlserver: + resources: + requests: + memory: "1.7Gi" + cpu: "700m" + limits: + cpu: 2 + memory: "4Gi" +``` + +Here, + +- `spec.databaseRef.name` specifies that we are performing operation on `mssql-ag-cluster` database. +- `spec.type` specifies that we are performing `VerticalScaling` on our database. +- `spec.VerticalScaling.mssqlserver` specifies the expected `mssql` container resources after scaling. + +Let's create the `MSSQLServerOpsRequest` CR we have shown above, + +```bash +$ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/examples/mssqlserver/scaling/vertical-scaling/mops-vscale-ag-cluster.yaml +mssqlserveropsrequest.ops.kubedb.com/mops-vscale-ag-cluster created +``` + +**Verify MSSQLServer resources updated successfully:** + +If everything goes well, `KubeDB-Ops-Manager` will update the resources of the PetSet's `Pod` containers. After a successful scaling process is done, the `KubeDB-Ops-Manager` updates the resources of the `MSSQLServer` object. + +First, we will wait for `MSSQLServerOpsRequest` to be successful. Run the following command to watch `MSSQLServerOpsRequest` CR, + +```bash +$ watch kubectl get mssqlserveropsrequest -n demo mops-vscale-ag-cluster +Every 2.0s: kubectl get mssqlserveropsrequest -n demo mops-vscale-ag-cluster + +NAME TYPE STATUS AGE +mops-vscale-ag-cluster VerticalScaling Successful 7m17s +``` + +We can see from the above output that the `MSSQLServerOpsRequest` has succeeded. If we describe the `MSSQLServerOpsRequest`, we will see that the mssqlserver resources are updated. + +```bash +$ kubectl describe mssqlserveropsrequest -n demo mops-vscale-ag-cluster +Name: mops-vscale-ag-cluster +Namespace: demo +Labels: +Annotations: +API Version: ops.kubedb.com/v1alpha1 +Kind: MSSQLServerOpsRequest +Metadata: + Creation Timestamp: 2024-10-24T14:13:05Z + Generation: 1 + Resource Version: 747632 + UID: ed3c5cbc-e74e-46ba-b243-143a6007ac36 +Spec: + Apply: IfReady + Database Ref: + Name: mssql-ag-cluster + Type: VerticalScaling + Vertical Scaling: + Mssqlserver: + Resources: + Limits: + Cpu: 2 + Memory: 4Gi + Requests: + Cpu: 700m + Memory: 1.7Gi +Status: + Conditions: + Last Transition Time: 2024-10-24T14:13:05Z + 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-24T14:13:08Z + Message: Successfully paused database + Observed Generation: 1 + Reason: DatabasePauseSucceeded + Status: True + Type: DatabasePauseSucceeded + Last Transition Time: 2024-10-24T14:13:08Z + Message: Successfully updated PetSets Resources + Observed Generation: 1 + Reason: UpdatePetSets + Status: True + Type: UpdatePetSets + Last Transition Time: 2024-10-24T14:13:13Z + Message: get pod; ConditionStatus:True; PodName:mssql-ag-cluster-0 + Observed Generation: 1 + Status: True + Type: GetPod--mssql-ag-cluster-0 + Last Transition Time: 2024-10-24T14:13:13Z + Message: evict pod; ConditionStatus:True; PodName:mssql-ag-cluster-0 + Observed Generation: 1 + Status: True + Type: EvictPod--mssql-ag-cluster-0 + Last Transition Time: 2024-10-24T14:13:48Z + Message: check pod running; ConditionStatus:True; PodName:mssql-ag-cluster-0 + Observed Generation: 1 + Status: True + Type: CheckPodRunning--mssql-ag-cluster-0 + Last Transition Time: 2024-10-24T14:13:53Z + Message: get pod; ConditionStatus:True; PodName:mssql-ag-cluster-1 + Observed Generation: 1 + Status: True + Type: GetPod--mssql-ag-cluster-1 + Last Transition Time: 2024-10-24T14:13:53Z + Message: evict pod; ConditionStatus:True; PodName:mssql-ag-cluster-1 + Observed Generation: 1 + Status: True + Type: EvictPod--mssql-ag-cluster-1 + Last Transition Time: 2024-10-24T14:14:28Z + Message: check pod running; ConditionStatus:True; PodName:mssql-ag-cluster-1 + Observed Generation: 1 + Status: True + Type: CheckPodRunning--mssql-ag-cluster-1 + Last Transition Time: 2024-10-24T14:14:33Z + Message: get pod; ConditionStatus:True; PodName:mssql-ag-cluster-2 + Observed Generation: 1 + Status: True + Type: GetPod--mssql-ag-cluster-2 + Last Transition Time: 2024-10-24T14:14:33Z + Message: evict pod; ConditionStatus:True; PodName:mssql-ag-cluster-2 + Observed Generation: 1 + Status: True + Type: EvictPod--mssql-ag-cluster-2 + Last Transition Time: 2024-10-24T14:15:08Z + Message: check pod running; ConditionStatus:True; PodName:mssql-ag-cluster-2 + Observed Generation: 1 + Status: True + Type: CheckPodRunning--mssql-ag-cluster-2 + Last Transition Time: 2024-10-24T14:15:13Z + Message: Successfully Restarted Pods With Resources + Observed Generation: 1 + Reason: RestartPods + Status: True + Type: RestartPods + Last Transition Time: 2024-10-24T14:15:13Z + Message: Successfully completed the VerticalScaling for MSSQLServer + Observed Generation: 1 + Reason: Successful + Status: True + Type: Successful + Observed Generation: 1 + Phase: Successful +Events: + Type Reason Age From Message + ---- ------ ---- ---- ------- + Normal Starting 7m46s KubeDB Ops-manager Operator Start processing for MSSQLServerOpsRequest: demo/mops-vscale-ag-cluster + Normal Starting 7m46s KubeDB Ops-manager Operator Pausing MSSQLServer database: demo/mssql-ag-cluster + Normal Successful 7m46s KubeDB Ops-manager Operator Successfully paused MSSQLServer database: demo/mssql-ag-cluster for MSSQLServerOpsRequest: mops-vscale-ag-cluster + Normal UpdatePetSets 7m43s KubeDB Ops-manager Operator Successfully updated PetSets Resources + Warning get pod; ConditionStatus:True; PodName:mssql-ag-cluster-0 7m38s KubeDB Ops-manager Operator get pod; ConditionStatus:True; PodName:mssql-ag-cluster-0 + Warning evict pod; ConditionStatus:True; PodName:mssql-ag-cluster-0 7m38s KubeDB Ops-manager Operator evict pod; ConditionStatus:True; PodName:mssql-ag-cluster-0 + Warning check pod running; ConditionStatus:False; PodName:mssql-ag-cluster-0 7m33s KubeDB Ops-manager Operator check pod running; ConditionStatus:False; PodName:mssql-ag-cluster-0 + Warning check pod running; ConditionStatus:True; PodName:mssql-ag-cluster-0 7m3s KubeDB Ops-manager Operator check pod running; ConditionStatus:True; PodName:mssql-ag-cluster-0 + Warning get pod; ConditionStatus:True; PodName:mssql-ag-cluster-1 6m58s KubeDB Ops-manager Operator get pod; ConditionStatus:True; PodName:mssql-ag-cluster-1 + Warning evict pod; ConditionStatus:True; PodName:mssql-ag-cluster-1 6m58s KubeDB Ops-manager Operator evict pod; ConditionStatus:True; PodName:mssql-ag-cluster-1 + Warning check pod running; ConditionStatus:False; PodName:mssql-ag-cluster-1 6m53s KubeDB Ops-manager Operator check pod running; ConditionStatus:False; PodName:mssql-ag-cluster-1 + Warning check pod running; ConditionStatus:True; PodName:mssql-ag-cluster-1 6m23s KubeDB Ops-manager Operator check pod running; ConditionStatus:True; PodName:mssql-ag-cluster-1 + Warning get pod; ConditionStatus:True; PodName:mssql-ag-cluster-2 6m18s KubeDB Ops-manager Operator get pod; ConditionStatus:True; PodName:mssql-ag-cluster-2 + Warning evict pod; ConditionStatus:True; PodName:mssql-ag-cluster-2 6m18s KubeDB Ops-manager Operator evict pod; ConditionStatus:True; PodName:mssql-ag-cluster-2 + Warning check pod running; ConditionStatus:False; PodName:mssql-ag-cluster-2 6m13s KubeDB Ops-manager Operator check pod running; ConditionStatus:False; PodName:mssql-ag-cluster-2 + Warning check pod running; ConditionStatus:True; PodName:mssql-ag-cluster-2 5m43s KubeDB Ops-manager Operator check pod running; ConditionStatus:True; PodName:mssql-ag-cluster-2 + Normal RestartPods 5m38s KubeDB Ops-manager Operator Successfully Restarted Pods With Resources + Normal Starting 5m38s KubeDB Ops-manager Operator Resuming MSSQLServer database: demo/mssql-ag-cluster + Normal Successful 5m38s KubeDB Ops-manager Operator Successfully resumed MSSQLServer database: demo/mssql-ag-cluster for MSSQLServerOpsRequest: mops-vscale-ag-cluster +``` + +Now, we are going to verify whether the resources of the mssqlserver instance has updated to meet up the desired state, Let's check, + +```bash +$ kubectl get pod -n demo mssql-ag-cluster-0 -o json | jq '.spec.containers[0].resources' +{ + "limits": { + "cpu": "2", + "memory": "4Gi" + }, + "requests": { + "cpu": "700m", + "memory": "1825361100800m" + } +} +$ kubectl get pod -n demo mssql-ag-cluster-1 -o json | jq '.spec.containers[0].resources' +{ + "limits": { + "cpu": "2", + "memory": "4Gi" + }, + "requests": { + "cpu": "700m", + "memory": "1825361100800m" + } +} +$ kubectl get pod -n demo mssql-ag-cluster-2 -o json | jq '.spec.containers[0].resources' +{ + "limits": { + "cpu": "2", + "memory": "4Gi" + }, + "requests": { + "cpu": "700m", + "memory": "1825361100800m" + } +} +``` + +The above output verifies that we have successfully scaled up the resources of the MSSQLServer. + +## Cleaning Up + +To clean up the Kubernetes resources created by this tutorial, run: + +```bash +kubectl delete mssqlserver -n demo mssql-ag-cluster +kubectl delete mssqlserveropsrequest -n demo mops-vscale-ag-cluster +kubectl delete issuer -n demo mssqlserver-ca-issuer +kubectl delete secret -n demo mssqlserver-ca +kubectl delete ns demo +``` + + + diff --git a/content/docs/v2024.9.30/guides/mssqlserver/scaling/vertical-scaling/overview.md b/content/docs/v2024.9.30/guides/mssqlserver/scaling/vertical-scaling/overview.md new file mode 100644 index 0000000000..ff4ba971c3 --- /dev/null +++ b/content/docs/v2024.9.30/guides/mssqlserver/scaling/vertical-scaling/overview.md @@ -0,0 +1,65 @@ +--- +title: Microsoft SQL Server Vertical Scaling Overview +menu: + docs_v2024.9.30: + identifier: ms-scaling-vertical-overview + name: Overview + parent: ms-scaling-vertical + weight: 10 +menu_name: docs_v2024.9.30 +section_menu_id: guides +info: + autoscaler: v0.33.0 + cli: v0.48.0 + dashboard: v0.24.0 + installer: v2024.9.30 + ops-manager: v0.35.0 + provisioner: v0.48.0 + schema-manager: v0.24.0 + ui-server: v0.24.0 + version: v2024.9.30 + webhook-server: v0.24.0 +--- + +> New to KubeDB? Please start [here](/docs/v2024.9.30/README). + +# Vertical Scaling MSSQLServer + +This guide will give you an overview of how KubeDB Ops Manager updates the resources(for example Memory, CPU etc.) of the `MSSQLServer`. + +## Before You Begin + +- You should be familiar with the following `KubeDB` concepts: + - [MSSQLServer](/docs/v2024.9.30/guides/mssqlserver/concepts/mssqlserver) + - [MSSQLServerOpsRequest](/docs/v2024.9.30/guides/mssqlserver/concepts/opsrequest) + +## How Vertical Scaling Process Works + +The following diagram shows how the `KubeDB` Ops Manager used to update the resources of the `MSSQLServer`. Open the image in a new tab to see the enlarged version. + +
+  Vertical scaling process of MSSQLServer +
Fig: Vertical scaling process of MSSQLServer
+
+ +The vertical scaling process consists of the following steps: + +1. At first, a user creates a `MSSQLServer` CR. + +2. `KubeDB` provisioner operator watches for the `MSSQLServer` CR. + +3. When the operator finds a `MSSQLServer` CR, it creates a `PetSet` and related necessary stuff like secret, service, etc. + +4. Then, in order to update the resources(for example `CPU`, `Memory` etc.) of the `MSSQLServer` cluster the user creates a `MSSQLServerOpsRequest` CR with desired information. + +5. `KubeDB` Ops Manager watches for `MSSQLServerOpsRequest`. + +6. When it finds one, it halts the `MSSQLServer` object so that the `KubeDB` provisioner operator doesn't perform any operation on the `MSSQLServer` during the scaling process. + +7. Then the KubeDB Ops-manager operator will update resources of the PetSet's Pods to reach desired state. + +8. After successful updating of the resources of the PetSet's Pods, the `KubeDB` Ops Manager updates the `MSSQLServer` object resources to reflect the updated state. + +9. After successful updating of the `MSSQLServer` resources, the `KubeDB` Ops Manager resumes the `MSSQLServer` object so that the `KubeDB` Provisioner operator resumes its usual operations. + +In the next doc, we are going to show a step-by-step guide on updating resources of MSSQLServer database using vertical scaling operation. diff --git a/content/docs/v2024.9.30/guides/mssqlserver/scaling/vertical-scaling/standalone.md b/content/docs/v2024.9.30/guides/mssqlserver/scaling/vertical-scaling/standalone.md new file mode 100644 index 0000000000..59cf016b31 --- /dev/null +++ b/content/docs/v2024.9.30/guides/mssqlserver/scaling/vertical-scaling/standalone.md @@ -0,0 +1,363 @@ +--- +title: Vertical Scaling MSSQLServer +menu: + docs_v2024.9.30: + identifier: ms-scaling-vertical-standalone + name: Standalone + parent: ms-scaling-vertical + weight: 20 +menu_name: docs_v2024.9.30 +section_menu_id: guides +info: + autoscaler: v0.33.0 + cli: v0.48.0 + dashboard: v0.24.0 + installer: v2024.9.30 + ops-manager: v0.35.0 + provisioner: v0.48.0 + schema-manager: v0.24.0 + ui-server: v0.24.0 + version: v2024.9.30 + webhook-server: v0.24.0 +--- + +> New to KubeDB? Please start [here](/docs/v2024.9.30/README). + +# Vertical Scale MSSQLServer Instances + +This guide will show you how to use `kubeDB-Ops-Manager` to update the resources of a MSSQLServer instances. + +## 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/v2024.9.30/setup/README). 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/). + + +- You should be familiar with the following `KubeDB` concepts: + - [MSSQLServer](/docs/v2024.9.30/guides/mssqlserver/concepts/mssqlserver) + - [MSSQLServerOpsRequest](/docs/v2024.9.30/guides/mssqlserver/concepts/opsrequest) + - [Vertical Scaling Overview](/docs/v2024.9.30/guides/mssqlserver/scaling/vertical-scaling/overview) + +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 +``` + +> **Note:** YAML files used in this tutorial are stored in [docs/examples/mssqlserver/scaling/vertical-scaling](https://github.com/kubedb/docs/tree/{{< param "info.version" >}}/docs/examples/mssqlserver/scaling/vertical-scaling) directory of [kubedb/doc](https://github.com/kubedb/docs) repository. + +### Apply Vertical Scaling on MSSQLServer + +Here, we are going to deploy a `MSSQLServer` instance using a supported version by `KubeDB` operator. Then we are going to apply vertical scaling on it. + +**Find supported MSSQLServer Version:** + +When you have installed `KubeDB`, it has created `MSSQLServerVersion` CR for all supported `MSSQLServer` versions. Let's check the supported MSSQLServer versions, + +```bash +$ kubectl get mssqlserverversion +NAME VERSION DB_IMAGE DEPRECATED AGE +2022-cu12 2022 mcr.microsoft.com/mssql/server:2022-CU12-ubuntu-22.04 3d21h +2022-cu14 2022 mcr.microsoft.com/mssql/server:2022-CU14-ubuntu-22.04 3d21h +``` + +The version above that does not show `DEPRECATED` `true` is supported by `KubeDB` for `MSSQLServer`. You can use any non-deprecated version. Here, we are going to create a mssqlserver using non-deprecated `MSSQLServer` version `2022-cu12`. + + +At first, we need to create an Issuer/ClusterIssuer which will be used to generate the certificate used for TLS configurations. + +#### 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 +``` + +**Deploy MSSQLServer:** + +In this section, we are going to deploy a MSSQLServer instance. Then, in the next section, we will update the resources of the database server using vertical scaling. +Below is the YAML of the `MSSQLServer` CR that we are going to create, + +```yaml +apiVersion: kubedb.com/v1alpha2 +kind: MSSQLServer +metadata: + name: mssql-standalone + namespace: demo +spec: + version: "2022-cu12" + replicas: 1 + storageType: Durable + tls: + issuerRef: + name: mssqlserver-ca-issuer + kind: Issuer + apiGroup: "cert-manager.io" + clientTLS: false + storage: + storageClassName: "standard" + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + deletionPolicy: WipeOut +``` + +Let's create the `MSSQLServer` CR we have shown above, + +```bash +$ kubectl create -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/examples/mssqlserver/scaling/vertical-scaling/mssql-standalone.yaml +mssqlserver.kubedb.com/mssql-standalone created +``` + + +**Check mssqlserver Ready to Scale:** + +`KubeDB` watches for `MSSQLServer` objects using Kubernetes API. When a `MSSQLServer` object is created, `KubeDB` will create a new PetSet, Services, and Secrets, etc. +Now, watch `MSSQLServer` is going to be in `Running` state and also watch `PetSet` and its pod is created and going to be in `Running` state, + + + + + +```bash +$ watch kubectl get ms,petset,pods -n demo +Every 2.0s: kubectl get ms,petset,pods -n demo + +NAME VERSION STATUS AGE +mssqlserver.kubedb.com/mssql-standalone 2022-cu12 Ready 4m7s + +NAME AGE +petset.apps.k8s.appscode.com/mssql-standalone 3m33s + +NAME READY STATUS RESTARTS AGE +pod/mssql-standalone-0 1/1 Running 0 3m33s +``` + +Let's check the `mssql-standalone-0` pod's `mssql` container's resources, `mssql` container is the first container So it's index will be 0. + +```bash +$ kubectl get pod -n demo mssql-standalone-0 -o json | jq '.spec.containers[0].resources' +{ + "limits": { + "memory": "4Gi" + }, + "requests": { + "cpu": "500m", + "memory": "4Gi" + } +} +``` + +Now, We are ready to apply a vertical scale on this mssqlserver database. + +#### Vertical Scaling + +Here, we are going to update the resources of the mssqlserver to meet up with the desired resources after scaling. + +**Create MSSQLServerOpsRequest:** + +In order to update the resources of your database, you have to create a `MSSQLServerOpsRequest` CR with your desired resources for scaling. Below is the YAML of the `MSSQLServerOpsRequest` CR that we are going to create, + +```yaml +apiVersion: ops.kubedb.com/v1alpha1 +kind: MSSQLServerOpsRequest +metadata: + name: mops-vscale-standalone + namespace: demo +spec: + type: VerticalScaling + databaseRef: + name: mssql-standalone + verticalScaling: + mssqlserver: + resources: + requests: + memory: "5Gi" + cpu: "1000m" + limits: + memory: "5Gi" +``` + +Here, + +- `spec.databaseRef.name` specifies that we are performing operation on `mssql-standalone` database. +- `spec.type` specifies that we are performing `VerticalScaling` on our database. +- `spec.VerticalScaling.mssqlserver` specifies the expected `mssql` container resources after scaling. + +Let's create the `MSSQLServerOpsRequest` CR we have shown above, + +```bash +$ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/examples/mssqlserver/scaling/vertical-scaling/mops-vscale-standalone.yaml +mssqlserveropsrequest.ops.kubedb.com/mops-vscale-standalone created +``` + +**Verify MSSQLServer resources updated successfully:** + +If everything goes well, `KubeDB-Ops-Manager` will update the resources of the PetSet's `Pod` containers. After a successful scaling process is done, the `KubeDB-Ops-Manager` updates the resources of the `MSSQLServer` object. + +First, we will wait for `MSSQLServerOpsRequest` to be successful. Run the following command to watch `MSSQLServerOpsRequest` CR, + +```bash +$ watch kubectl get mssqlserveropsrequest -n demo mops-vscale-standalone +Every 2.0s: kubectl get mssqlserveropsrequest -n demo mops-vscale-standalone + +NAME TYPE STATUS AGE +mops-vscale-standalone VerticalScaling Successful 3m22s +``` + +We can see from the above output that the `MSSQLServerOpsRequest` has succeeded. If we describe the `MSSQLServerOpsRequest`, we will see that the mssqlserver resources are updated. + +```bash +$ kubectl describe mssqlserveropsrequest -n demo mops-vscale-standalone +Name: mops-vscale-standalone +Namespace: demo +Labels: +Annotations: +API Version: ops.kubedb.com/v1alpha1 +Kind: MSSQLServerOpsRequest +Metadata: + Creation Timestamp: 2024-10-24T13:43:57Z + Generation: 1 + Resource Version: 744508 + UID: 68bcc122-2ad7-4ae0-ab72-1a3e01fd6f40 +Spec: + Apply: IfReady + Database Ref: + Name: mssql-standalone + Type: VerticalScaling + Vertical Scaling: + Mssqlserver: + Resources: + Limits: + Cpu: 2 + Memory: 5Gi + Requests: + Cpu: 1 + Memory: 5Gi +Status: + Conditions: + Last Transition Time: 2024-10-24T13:43:57Z + 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-24T13:44:24Z + Message: Successfully paused database + Observed Generation: 1 + Reason: DatabasePauseSucceeded + Status: True + Type: DatabasePauseSucceeded + Last Transition Time: 2024-10-24T13:44:24Z + Message: Successfully updated PetSets Resources + Observed Generation: 1 + Reason: UpdatePetSets + Status: True + Type: UpdatePetSets + Last Transition Time: 2024-10-24T13:44:29Z + Message: get pod; ConditionStatus:True; PodName:mssql-standalone-0 + Observed Generation: 1 + Status: True + Type: GetPod--mssql-standalone-0 + Last Transition Time: 2024-10-24T13:44:29Z + Message: evict pod; ConditionStatus:True; PodName:mssql-standalone-0 + Observed Generation: 1 + Status: True + Type: EvictPod--mssql-standalone-0 + Last Transition Time: 2024-10-24T13:45:04Z + Message: check pod running; ConditionStatus:True; PodName:mssql-standalone-0 + Observed Generation: 1 + Status: True + Type: CheckPodRunning--mssql-standalone-0 + Last Transition Time: 2024-10-24T13:45:09Z + Message: Successfully Restarted Pods With Resources + Observed Generation: 1 + Reason: RestartPods + Status: True + Type: RestartPods + Last Transition Time: 2024-10-24T13:45:09Z + Message: Successfully completed the VerticalScaling for MSSQLServer + Observed Generation: 1 + Reason: Successful + Status: True + Type: Successful + Observed Generation: 1 + Phase: Successful +Events: + Type Reason Age From Message + ---- ------ ---- ---- ------- + Normal Starting 3m55s KubeDB Ops-manager Operator Start processing for MSSQLServerOpsRequest: demo/mops-vscale-standalone + Normal Starting 3m55s KubeDB Ops-manager Operator Pausing MSSQLServer database: demo/mssql-standalone + Normal Successful 3m55s KubeDB Ops-manager Operator Successfully paused MSSQLServer database: demo/mssql-standalone for MSSQLServerOpsRequest: mops-vscale-standalone + Normal UpdatePetSets 3m28s KubeDB Ops-manager Operator Successfully updated PetSets Resources + Warning get pod; ConditionStatus:True; PodName:mssql-standalone-0 3m23s KubeDB Ops-manager Operator get pod; ConditionStatus:True; PodName:mssql-standalone-0 + Warning evict pod; ConditionStatus:True; PodName:mssql-standalone-0 3m23s KubeDB Ops-manager Operator evict pod; ConditionStatus:True; PodName:mssql-standalone-0 + Warning check pod running; ConditionStatus:False; PodName:mssql-standalone-0 3m18s KubeDB Ops-manager Operator check pod running; ConditionStatus:False; PodName:mssql-standalone-0 + Warning check pod running; ConditionStatus:True; PodName:mssql-standalone-0 2m48s KubeDB Ops-manager Operator check pod running; ConditionStatus:True; PodName:mssql-standalone-0 + Normal RestartPods 2m43s KubeDB Ops-manager Operator Successfully Restarted Pods With Resources + Normal Starting 2m43s KubeDB Ops-manager Operator Resuming MSSQLServer database: demo/mssql-standalone + Normal Successful 2m43s KubeDB Ops-manager Operator Successfully resumed MSSQLServer database: demo/mssql-standalone for MSSQLServerOpsRequest: mops-vscale-standalone +``` + +Now, we are going to verify whether the resources of the mssqlserver instance has updated to meet up the desired state, Let's check, + +```bash +$ kubectl get pod -n demo mssql-standalone-0 -o json | jq '.spec.containers[0].resources' +{ + "limits": { + "cpu": "2", + "memory": "5Gi" + }, + "requests": { + "cpu": "1", + "memory": "5Gi" + } +``` + +The above output verifies that we have successfully scaled up the resources of the MSSQLServer. + +## Cleaning Up + +To clean up the Kubernetes resources created by this tutorial, run: + +```bash +kubectl delete mssqlserver -n demo mssql-standalone +kubectl delete mssqlserveropsrequest -n demo mops-vscale-standalone +kubectl delete issuer -n demo mssqlserver-ca-issuer +kubectl delete secret -n demo mssqlserver-ca +kubectl delete ns demo +``` + + +## Next Steps + +- Detail concepts of [MSSQLServer object](/docs/v2024.9.30/guides/mssqlserver/concepts/mssqlserver). +- [Backup and Restore](/docs/v2024.9.30/guides/mssqlserver/backup/overview/) MSSQLServer databases using KubeStash. + + diff --git a/content/docs/v2024.9.30/guides/mssqlserver/tls/overview.md b/content/docs/v2024.9.30/guides/mssqlserver/tls/overview.md index 917fcae72f..1d6ce7c0fe 100644 --- a/content/docs/v2024.9.30/guides/mssqlserver/tls/overview.md +++ b/content/docs/v2024.9.30/guides/mssqlserver/tls/overview.md @@ -53,7 +53,7 @@ Read about the fields in details from [MSSQLServer Concepts](/docs/v2024.9.30/gu The following figure shows how `KubeDB` used to configure TLS/SSL in MSSQLServer. Open the image in a new tab to see the enlarged version.
-Deploy MSSQLServer with TLS/SSL +Deploy MSSQLServer with TLS/SSL
Fig: Deploy MSSQLServer with TLS/SSL
diff --git a/content/docs/v2024.9.30/guides/mssqlserver/volume-expansion/_index.md b/content/docs/v2024.9.30/guides/mssqlserver/volume-expansion/_index.md new file mode 100644 index 0000000000..e93fe8e8c3 --- /dev/null +++ b/content/docs/v2024.9.30/guides/mssqlserver/volume-expansion/_index.md @@ -0,0 +1,22 @@ +--- +title: Volume Expansion +menu: + docs_v2024.9.30: + identifier: ms-volume-expansion + name: Volume Expansion + parent: guides-mssqlserver + weight: 42 +menu_name: docs_v2024.9.30 +info: + autoscaler: v0.33.0 + cli: v0.48.0 + dashboard: v0.24.0 + installer: v2024.9.30 + ops-manager: v0.35.0 + provisioner: v0.48.0 + schema-manager: v0.24.0 + ui-server: v0.24.0 + version: v2024.9.30 + webhook-server: v0.24.0 +--- + diff --git a/content/docs/v2024.9.30/guides/mssqlserver/volume-expansion/overview.md b/content/docs/v2024.9.30/guides/mssqlserver/volume-expansion/overview.md new file mode 100644 index 0000000000..c85d50c5d2 --- /dev/null +++ b/content/docs/v2024.9.30/guides/mssqlserver/volume-expansion/overview.md @@ -0,0 +1,68 @@ +--- +title: MSSQLServer Volume Expansion Overview +menu: + docs_v2024.9.30: + identifier: ms-volume-expansion-overview + name: Overview + parent: ms-volume-expansion + weight: 10 +menu_name: docs_v2024.9.30 +section_menu_id: guides +info: + autoscaler: v0.33.0 + cli: v0.48.0 + dashboard: v0.24.0 + installer: v2024.9.30 + ops-manager: v0.35.0 + provisioner: v0.48.0 + schema-manager: v0.24.0 + ui-server: v0.24.0 + version: v2024.9.30 + webhook-server: v0.24.0 +--- + +> New to KubeDB? Please start [here](/docs/v2024.9.30/README). + +# MSSQLServer Volume Expansion + +This guide will give an overview on how KubeDB Ops Manager expand the volume of `MSSQLServer`. + +## Before You Begin + +- You should be familiar with the following `KubeDB` concepts: + - [MSSQLServer](/docs/v2024.9.30/guides/mssqlserver/concepts/mssqlserver) + - [MSSQLServerOpsRequest](/docs/v2024.9.30/guides/mssqlserver/concepts/opsrequest) + +## How Volume Expansion Process Works + +The following diagram shows how KubeDB Ops Manager expand the volumes of `MSSQLServer` database components. Open the image in a new tab to see the enlarged version. + +
+  Volume Expansion process of MSSQLServer +
Fig: Volume Expansion process of MSSQLServer
+
+ +The Volume Expansion 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 `PetSet` and related necessary stuff like secrets, services, etc. + +4. The petSet creates Persistent Volumes according to the Volume Claim Template provided in the petset configuration. This Persistent Volume will be expanded by the `KubeDB` Ops-manager operator. + +5. Then, in order to expand the volume of the `MSSQLServer` database the user creates a `MSSQLServerOpsRequest` CR with desired information. + +6. `KubeDB` Ops-manager operator watches the `MSSQLServerOpsRequest` CR. + +7. When it finds a `MSSQLServerOpsRequest` CR, it pauses the `MSSQLServer` object which is referred from the `MSSQLServerOpsRequest`. So, the `KubeDB` Provisioner operator doesn't perform any operations on the `MSSQLServer` object during the volume expansion process. + +8. Then the `KubeDB` Ops-manager operator will expand the persistent volume to reach the expected size defined in the `MSSQLServerOpsRequest` CR. + +9. After the successful expansion of the volume of the related PetSet Pods, the `KubeDB` Ops-manager operator updates the new volume size in the `MSSQLServer` object to reflect the updated state. + +10. After the successful Volume Expansion of the `MSSQLServer`, the `KubeDB` Ops-manager operator resumes the `MSSQLServer` object so that the `KubeDB` Provisioner operator resumes its usual operations. + +In the next docs, we are going to show a step-by-step guide on Volume Expansion of various MSSQLServer database using `MSSQLServerOpsRequest` CRD. + diff --git a/content/docs/v2024.9.30/guides/mssqlserver/volume-expansion/volume-expansion.md b/content/docs/v2024.9.30/guides/mssqlserver/volume-expansion/volume-expansion.md new file mode 100644 index 0000000000..96dc72505e --- /dev/null +++ b/content/docs/v2024.9.30/guides/mssqlserver/volume-expansion/volume-expansion.md @@ -0,0 +1,280 @@ +--- +title: MSSQLServer Volume Expansion +menu: + docs_v2024.9.30: + identifier: mssqlserver-volume-expansion-guide + name: MSSQLServer Volume Expansion + parent: ms-volume-expansion + weight: 20 +menu_name: docs_v2024.9.30 +section_menu_id: guides +info: + autoscaler: v0.33.0 + cli: v0.48.0 + dashboard: v0.24.0 + installer: v2024.9.30 + ops-manager: v0.35.0 + provisioner: v0.48.0 + schema-manager: v0.24.0 + ui-server: v0.24.0 + version: v2024.9.30 + webhook-server: v0.24.0 +--- + +> New to KubeDB? Please start [here](/docs/v2024.9.30/README). + +# MSSQLServer Volume Expansion + +This guide will show you how to use `KubeDB` Ops-manager operator to expand the volume of a MSSQLServer. + +## 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/v2024.9.30/setup/README). 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/). + +- You must have a `StorageClass` that supports volume expansion. + +- You should be familiar with the following `KubeDB` concepts: + - [MSSQLServer](/docs/v2024.9.30/guides/mssqlserver/concepts/mssqlserver) + - [MSSQLServerOpsRequest](/docs/v2024.9.30/guides/mssqlserver/concepts/opsrequest) + - [Volume Expansion Overview](/docs/v2024.9.30/guides/mssqlserver/volume-expansion/overview) + +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 +``` + +## Expand Volume of MSSQLServer + +Here, we are going to deploy a `MSSQLServer` cluster using a supported version by `KubeDB` operator. Then we are going to apply `MSSQLServerOpsRequest` to expand its volume. The process of expanding MSSQLServer `standalone` is same as MSSQLServer Availability Group cluster. + +### Prepare MSSQLServer + +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 2d +longhorn (default) driver.longhorn.io Delete Immediate true 3m25s +longhorn-static driver.longhorn.io Delete Immediate true 3m19s +``` + +We can see from the output that `longhorn (default)` storage class has `ALLOWVOLUMEEXPANSION` field as true. So, this storage class supports volume expansion. We will use this storage class. + + +Now, we are going to deploy a `MSSQLServer` in `AvailabilityGroup` Mode with version `2022-cu12`. + +### Deploy MSSQLServer + +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 Cluster with 1GB volume. Then, in the next section we will expand its volume to 2GB using `MSSQLServerOpsRequest` 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 + storageType: Durable + storage: + storageClassName: "longhorn" + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + deletionPolicy: WipeOut +``` + +Let's create the `MSSQLServer` CR we have shown above, + +```bash +$ kubectl create -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/examples/mssqlserver/volume-expansion/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 mssqlserver-ag-cluster +NAME VERSION STATUS AGE +mssqlserver-ag-cluster 2022-cu12 Ready 5m1s +``` + +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-059f186a-01a4-441d-85f1-95aef34934be 1Gi RWO Delete Bound demo/data-mssqlserver-ag-cluster-0 longhorn 82s +pvc-87bea35f-4a55-4aa5-903a-e4da9f548241 1Gi RWO Delete Bound demo/data-mssqlserver-ag-cluster-1 longhorn 52s +pvc-9d1c3c9c-f928-4fa2-a2e1-becf2ab9c564 1Gi RWO Delete Bound demo/data-mssqlserver-ag-cluster-2 longhorn 35s +``` + +You can see the petset has 1GB storage, and the capacity of all the persistent volumes are also 1GB. + +We are now ready to apply the `MSSQLServerOpsRequest` CR to expand the volume of this database. + +### Volume Expansion + +Here, we are going to expand the volume of the MSSQLServer cluster. + +#### Create MSSQLServerOpsRequest + +In order to expand the volume of the database, we have to create a `MSSQLServerOpsRequest` CR with our desired volume size. Below is the YAML of the `MSSQLServerOpsRequest` CR that we are going to create, + +```yaml +apiVersion: ops.kubedb.com/v1alpha1 +kind: MSSQLServerOpsRequest +metadata: + name: mops-volume-exp-ag-cluster + namespace: demo +spec: + type: VolumeExpansion + databaseRef: + name: mssqlserver-ag-cluster + volumeExpansion: + mode: "Offline" # Online + mssqlserver: 2Gi +``` + +Here, + +- `spec.databaseRef.name` specifies that we are performing volume expansion operation on `mssqlserver-ag-cluster` database. +- `spec.type` specifies that we are performing `VolumeExpansion` on our database. +- `spec.volumeExpansion.mssqlserver` specifies the desired volume size. +- `spec.volumeExpansion.mode` specifies the desired volume expansion mode (`Online` or `Offline`). Storageclass `longhorn` supports `Offline` volume expansion. + +> **Note:** If the Storageclass you are using support `Online` Volume Expansion, Try Online volume expansion by using `spec.volumeExpansion.mode:"Online"`. + +During `Online` VolumeExpansion KubeDB expands volume without deleting the pods, it directly updates the underlying PVC. And for Offline volume expansion, the database is paused. The Pods are deleted and PVC is updated. Then the database Pods are recreated with updated PVC. + + +Let's create the `MSSQLServerOpsRequest` CR we have shown above, + +```bash +$ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/example/mssqlserver/volume-expansion/mops-volume-exp-ag-cluster.yaml +mssqlserveropsrequest.ops.kubedb.com/mops-volume-exp-ag-cluster created +``` + +#### Verify MSSQLServer volume expanded successfully + +If everything goes well, `KubeDB` Ops-manager operator will update the volume size of `MSSQLServer` object and related `PetSet` and `Persistent Volumes`. + +Let's wait for `MSSQLServerOpsRequest` to be `Successful`. Run the following command to watch `MSSQLServerOpsRequest` CR, + +```bash +$ kubectl get mssqlserveropsrequest -n demo +NAME TYPE STATUS AGE +mops-volume-exp-ag-cluster VolumeExpansion Successful 8m30s +``` + +We can see from the above output that the `MSSQLServerOpsRequest` has succeeded. + +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' +"2Gi" + +$ kubectl get pv -n demo +NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS VOLUMEATTRIBUTESCLASS REASON AGE +pvc-059f186a-01a4-441d-85f1-95aef34934be 2Gi RWO Delete Bound demo/data-mssqlserver-ag-cluster-0 longhorn 29m +pvc-87bea35f-4a55-4aa5-903a-e4da9f548241 2Gi RWO Delete Bound demo/data-mssqlserver-ag-cluster-1 longhorn 29m +pvc-9d1c3c9c-f928-4fa2-a2e1-becf2ab9c564 2Gi RWO Delete Bound demo/data-mssqlserver-ag-cluster-2 longhorn 29m +``` + +The above output verifies that we have successfully expanded the volume of the MSSQLServer database. + +## Standalone Mode + +The volume expansion process is same for all the MSSQLServer modes. The `MSSQLServerOpsRequest` CR has the same fields. The database needs to refer to a mssqlserver +in standalone mode. + +## Cleaning Up + +To clean up the Kubernetes resources created by this tutorial, run: + + +```bash +$ kubectl patch -n demo ms/mssqlserver-ag-cluster -p '{"spec":{"deletionPolicy":"WipeOut"}}' --type="merge" +mssqlserver.kubedb.com/mssqlserver-ag-cluster patched + +$ kubectl delete -n demo mssqlserver mssqlserver-ag-cluster +mssqlserver.kubedb.com "mssqlserver-ag-cluster" deleted + +$ kubectl delete -n demo mssqlserveropsrequest mops-volume-exp-ag-cluster +mssqlserveropsrequest.ops.kubedb.com "mops-volume-exp-ag-cluster" deleted + +kubectl delete issuer -n demo mssqlserver-ca-issuer +kubectl delete secret -n demo mssqlserver-ca +kubectl delete ns demo +``` + +## Next Steps + +- Detail concepts of [MSSQLServer object](/docs/v2024.9.30/guides/mssqlserver/concepts/mssqlserver). +- [Backup and Restore](/docs/v2024.9.30/guides/mssqlserver/backup/overview/) MSSQLServer databases using KubeStash. \ No newline at end of file diff --git a/content/docs/v2024.9.30/guides/singlestore/concepts/opsrequest.md b/content/docs/v2024.9.30/guides/singlestore/concepts/opsrequest.md index cb91891adc..1d91173176 100644 --- a/content/docs/v2024.9.30/guides/singlestore/concepts/opsrequest.md +++ b/content/docs/v2024.9.30/guides/singlestore/concepts/opsrequest.md @@ -139,7 +139,7 @@ metadata: name: sdbops-reconfigure-config namespace: demo spec: - type: Configuration + type: Reconfigure databaseRef: name: sdb-sample configuration: @@ -160,7 +160,7 @@ metadata: name: sdbops-reconfigure-config namespace: demo spec: - type: Configuration + type: Reconfigure databaseRef: name: sdb-standalone configuration: @@ -177,7 +177,7 @@ metadata: name: sdbops-reconfigure-config namespace: demo spec: - type: Configuration + type: Reconfigure databaseRef: name: sdb-sample configuration: @@ -196,7 +196,7 @@ metadata: name: sdbops-reconfigure-config namespace: demo spec: - type: Configuration + type: Reconfigure databaseRef: name: sdb-standalone configuration: diff --git a/content/docs/v2024.9.30/guides/singlestore/reconfigure/reconfigure-steps/index.md b/content/docs/v2024.9.30/guides/singlestore/reconfigure/reconfigure-steps/index.md index 16f836a490..4037320c2d 100644 --- a/content/docs/v2024.9.30/guides/singlestore/reconfigure/reconfigure-steps/index.md +++ b/content/docs/v2024.9.30/guides/singlestore/reconfigure/reconfigure-steps/index.md @@ -230,7 +230,7 @@ metadata: name: sdbops-reconfigure-config namespace: demo spec: - type: Configuration + type: Reconfigure databaseRef: name: custom-sdb configuration: @@ -243,7 +243,7 @@ spec: Here, - `spec.databaseRef.name` specifies that we are reconfiguring `custom-sdb` database. -- `spec.type` specifies that we are performing `Configuration` on our database. +- `spec.type` specifies that we are performing `Reconfigure` on our database. - `spec.configuration.aggregator.applyConfig` is a map where key supports 1 values, namely `sdb-apply.cnf` for aggregator nodes. You can also specifies `spec.configuration.leaf.applyConfig` which is a map where key supports 1 values, namely `sdb-apply.cnf` for leaf nodes. Let's create the `SinglestoreOpsRequest` CR we have shown above, @@ -262,8 +262,7 @@ Let's wait for `SinglestoreOpsRequest` to be `Successful`. Run the following co ```bash $ kubectl get singlestoreopsrequest --all-namespaces NAMESPACE NAME TYPE STATUS AGE -demo sdbops-reconfigure-config Configuration Successful 10m - +demo sdbops-reconfigure-config Reconfigure Successful 10m ``` We can see from the above output that the `SinglestoreOpsRequest` has succeeded. If we describe the `SinglestoreOpsRequest` we will get an overview of the steps that were followed to reconfigure the database. @@ -289,7 +288,7 @@ Spec: sdb-apply.cnf: max_connections = 550 Database Ref: Name: custom-sdb - Type: Configuration + Type: Reconfigure Status: Conditions: Last Transition Time: 2024-10-04T10:18:22Z @@ -408,7 +407,7 @@ metadata: name: sdbops-reconfigure-remove namespace: demo spec: - type: Configuration + type: Reconfigure databaseRef: name: custom-sdb configuration: @@ -438,7 +437,7 @@ Let's wait for `SingleStoreOpsRequest` to be `Successful`. Run the following co ```bash $ kubectl get singlestoreopsrequest -n demo NAME TYPE STATUS AGE -sdbops-reconfigure-remove Configuration Successful 5m31s +sdbops-reconfigure-remove Reconfigure Successful 5m31s ``` Now let's connect to a singlestore instance and run a singlestore internal command to check the new configuration we have provided. diff --git a/content/docs/v2024.9.30/guides/singlestore/reconfigure/reconfigure-steps/yamls/reconfigure-remove.yaml b/content/docs/v2024.9.30/guides/singlestore/reconfigure/reconfigure-steps/yamls/reconfigure-remove.yaml index b557e898e9..49cdc7cc54 100644 --- a/content/docs/v2024.9.30/guides/singlestore/reconfigure/reconfigure-steps/yamls/reconfigure-remove.yaml +++ b/content/docs/v2024.9.30/guides/singlestore/reconfigure/reconfigure-steps/yamls/reconfigure-remove.yaml @@ -4,7 +4,7 @@ metadata: name: sdbops-reconfigure-config namespace: demo spec: - type: Configuration + type: Reconfigure databaseRef: name: custom-sdb configuration: diff --git a/content/docs/v2024.9.30/guides/singlestore/reconfigure/reconfigure-steps/yamls/reconfigure-using-applyConfig.yaml b/content/docs/v2024.9.30/guides/singlestore/reconfigure/reconfigure-steps/yamls/reconfigure-using-applyConfig.yaml index 65b617765d..ecacdbd1ad 100644 --- a/content/docs/v2024.9.30/guides/singlestore/reconfigure/reconfigure-steps/yamls/reconfigure-using-applyConfig.yaml +++ b/content/docs/v2024.9.30/guides/singlestore/reconfigure/reconfigure-steps/yamls/reconfigure-using-applyConfig.yaml @@ -4,7 +4,7 @@ metadata: name: sdbops-reconfigure-config namespace: demo spec: - type: Configuration + type: Reconfigure databaseRef: name: custom-sdb configuration: diff --git a/content/docs/v2024.9.30/images/day-2-operation/mssqlserver/ms-horizontal-scaling.png b/content/docs/v2024.9.30/images/day-2-operation/mssqlserver/ms-horizontal-scaling.png new file mode 100644 index 0000000000..ffd21f300c Binary files /dev/null and b/content/docs/v2024.9.30/images/day-2-operation/mssqlserver/ms-horizontal-scaling.png differ diff --git a/content/docs/v2024.9.30/images/day-2-operation/mssqlserver/ms-tls.png b/content/docs/v2024.9.30/images/day-2-operation/mssqlserver/ms-tls.png new file mode 100644 index 0000000000..3f0abe1c6a Binary files /dev/null and b/content/docs/v2024.9.30/images/day-2-operation/mssqlserver/ms-tls.png differ diff --git a/content/docs/v2024.9.30/images/day-2-operation/mssqlserver/ms-tls.svg b/content/docs/v2024.9.30/images/day-2-operation/mssqlserver/ms-tls.svg deleted file mode 100644 index 819643f928..0000000000 --- a/content/docs/v2024.9.30/images/day-2-operation/mssqlserver/ms-tls.svg +++ /dev/null @@ -1,4 +0,0 @@ - - - -            Enterprise            Operator              Community            Operator
service
se...
secret
se...
tls-secret
tls-secret
Cert- manager
Cert- ma...
StatefulSet
Statef...
Issuer/Cluster Issuer
Issuer...
Kafka
Kafka
Certificates
Certif...
User
User
2.Create
2.Create
1.Create
1.Create
5a.Watch
5a.Watch
3.Watch
3.Watch
4.Create
4.Create
5c.Watch
5c.Watch
6.Create
6.Create
7.Watch
7.Watch
uses
uses
8.Create
8.Create
9.Watch
9.Watch
10.Create
10.Create
5b.Watch
5b.Watch
refers to
refers toText is not SVG - cannot display \ No newline at end of file diff --git a/content/docs/v2024.9.30/images/day-2-operation/mssqlserver/ms-vertical-scaling.png b/content/docs/v2024.9.30/images/day-2-operation/mssqlserver/ms-vertical-scaling.png new file mode 100644 index 0000000000..db35426859 Binary files /dev/null and b/content/docs/v2024.9.30/images/day-2-operation/mssqlserver/ms-vertical-scaling.png differ diff --git a/content/docs/v2024.9.30/images/day-2-operation/mssqlserver/ms-volume-expansion.png b/content/docs/v2024.9.30/images/day-2-operation/mssqlserver/ms-volume-expansion.png new file mode 100644 index 0000000000..14ab5ae1fc Binary files /dev/null and b/content/docs/v2024.9.30/images/day-2-operation/mssqlserver/ms-volume-expansion.png differ diff --git a/content/docs/v2024.9.30/images/mssqlserver/monitoring/mssql-monitoring-targets.png b/content/docs/v2024.9.30/images/mssqlserver/monitoring/mssql-monitoring-targets.png new file mode 100644 index 0000000000..fcdf4c9134 Binary files /dev/null and b/content/docs/v2024.9.30/images/mssqlserver/monitoring/mssql-monitoring-targets.png differ diff --git a/content/docs/v2024.9.30/images/mssqlserver/ms-compute-autoscaling.png b/content/docs/v2024.9.30/images/mssqlserver/ms-compute-autoscaling.png new file mode 100644 index 0000000000..ad4de5e7f3 Binary files /dev/null and b/content/docs/v2024.9.30/images/mssqlserver/ms-compute-autoscaling.png differ diff --git a/content/docs/v2024.9.30/images/mssqlserver/ms-storage-autoscaling.png b/content/docs/v2024.9.30/images/mssqlserver/ms-storage-autoscaling.png new file mode 100644 index 0000000000..633350be56 Binary files /dev/null and b/content/docs/v2024.9.30/images/mssqlserver/ms-storage-autoscaling.png differ