Merge pull request #15882 from MicrosoftDocs/master

huypub · web-flow · commit 21c14308b153 · 2020-07-08T15:29:30.000-07:00
7/08 PM Publish
diff --git a/docs/big-data-cluster/deploy-openshift.md b/docs/big-data-cluster/deploy-openshift.md
@@ -32,32 +32,44 @@ This article outlines deployment steps that are specific to the OpenShift platfo
 > [!IMPORTANT]
 > Below pre-requisites must be performed by a OpenShift cluster admin (cluster-admin cluster role) that has sufficient permissions to create these cluster level objects. For more information on cluster roles in OpenShift see [Using RBAC to define and apply permissions](https://docs.openshift.com/container-platform/4.4/authentication/using-rbac.html).
 
-1. Create a custom security context constraint (SCC) using the attached [`bdc-scc.yaml`](#bdc-sccyaml-file).
+1. Ensure the **pidsLimit** setting on the OpenShift is updated to accommodate SQL Server workloads. The default value in OpenShift is too low for production like workloads. We recommend a value of at least **4096**, but the optimal value will depend of the *max worker threads* setting in SQL Server and the number of CPU processors on the OpenShift host node. 
+    - To find out how to update **pidLimit** for your OpenShift cluster see [here]( https://github.com/openshift/machine-config-operator/blob/master/docs/ContainerRuntimeConfigDesign.md). Note that OpenShift versions before **4.3.5** had a defect causing the updated value to not take effect. Make sure you upgrade OpenShift to the latest version. 
+    - To help you compute the optimal value depending on your environment and planned SQL Server workloads, you can use the estimation and examples below:
 
-   ```console
-   oc apply -f bdc-scc.yaml
-   ```
+    |Number of processors|Default max worker threads|Default workers per processor|Minimum pidsLimit value|
+    |--------------------|--------------------------|-----------------------------|-----------------------|
+    |          64        |           512            |             16              | 512 + (64 *16) = 1536 |
+    |         128        |           512            |             32              | 512 + (128*32) = 4608 |
 
-   > [!NOTE]
-   > The custom SCC for BDC is based on the built-in *nonroot* SCC in OpenShift, with additional permissions. To learn more about security context constraints in OpenShift see [Managing Security Context Constraints](https://docs.openshift.com/container-platform/4.3/authentication/managing-security-context-constraints.html). For a detailed information on what additional permissions are required for big data clusters on top of the *nonroot* SCC, download the whitepaper [here](https://aka.ms/sql-bdc-openshift-security).
+    > [!NOTE]
+    > Other processes (e.g. backups, CLR, Fulltext, SQLAgent) also add some overhead, so add a buffer to the estimated value.
+
+2. Create a custom security context constraint (SCC) using the attached [`bdc-scc.yaml`](#bdc-sccyaml-file).
 
-2. Create a namespace/project:
+    ```console
+    oc apply -f bdc-scc.yaml
+    ```
+
+    > [!NOTE]
+    > The custom SCC for BDC is based on the built-in *nonroot* SCC in OpenShift, with additional permissions. To learn more about security context constraints in OpenShift see [Managing Security Context Constraints](https://docs.openshift.com/container-platform/4.3/authentication/managing-security-context-constraints.html). For a detailed information on what additional permissions are required for big data clusters on top of the *nonroot* SCC, download the whitepaper [here](https://aka.ms/sql-bdc-openshift-security).
+
+3. Create a namespace/project:
 
    ```console
    oc new-project <namespaceName>
    ```
 
-3. Assign the custom SCC to the service accounts for users within the namespace where BDC is deployed:
+4. Assign the custom SCC to the service accounts for users within the namespace where BDC is deployed:
 
    ```console
    oc adm policy add-scc-to-group bdc-scc system:serviceaccounts:<namespaceName>
    ```
 
-4. Assign appropriate permission to the user deploying BDC. Do one of the following. 
+5. Assign appropriate permission to the user deploying BDC. Do one of the following. 
 
-   1. If the user deploying BDC has cluster-admin role, proceed to [deploy big data cluster](#deploy-big-data-cluster).
+   - If the user deploying BDC has cluster-admin role, proceed to [deploy big data cluster](#deploy-big-data-cluster).
 
-   1. If the user deploying BDC is a namespace admin, assign the user cluster-admin local role for the namespace created. This is the preferred option for the user deploying and managing the big data cluster to have namespace level admin permissions.
+   - If the user deploying BDC is a namespace admin, assign the user cluster-admin local role for the namespace created. This is the preferred option for the user deploying and managing the big data cluster to have namespace level admin permissions.
 
    ```console
    oc adm policy add-role-to-user cluster-admin <deployingUser> -n <namespaceName>
@@ -73,10 +85,7 @@ This article outlines deployment steps that are specific to the OpenShift platfo
 
 1. Install latest [azdata](deploy-install-azdata.md).
 
-2. Clone one of the built-in configuration files for OpenShift.
-
-    1. If your target environment is OpenShift.
-    2. Clone one of the built-in configuration files for OpenShift, depending on your target environment (OpenShift on premises or ARO) and deployment scenario. See this section [link](//TODO add link) on settings that are specific to OpenShift in the built-in configuration files. For more details on available configuration files see [deployment guidance](deployment-guidance.md).
+1. Clone one of the built-in configuration files for OpenShift, depending on your target environment (OpenShift on premises or ARO) and deployment scenario. See the *OpenShift specific settings in the deployment configuration files* section below for settings that are specific to OpenShift in the built-in configuration files. For more details on available configuration files see [deployment guidance](deployment-guidance.md).
 
    List all the available built-in configuration files.
 
@@ -96,24 +105,24 @@ This article outlines deployment steps that are specific to the OpenShift platfo
    azdata bdc config init --source aro-dev-test --target custom-openshift
    ```
 
-3. Customize the configuration files control.json and bdc.json. Here are some additional resources that guide you through the customizations supported for various use cases:
+1. Customize the configuration files control.json and bdc.json. Here are some additional resources that guide you through the customizations supported for various use cases:
 
-   1. [Storage](concept-data-persistence.md)
-   1. [AD related settings](deploy-active-directory.md)
-   1. [Other customizations](deployment-custom-configuration.md)
+   - [Storage](concept-data-persistence.md)
+   - [AD related settings](deploy-active-directory.md)
+   - [Other customizations](deployment-custom-configuration.md)
 
    > [!NOTE]
    > Integrating with Azure Active Directory for BDC is not supported, hence you can not use this authentication method when deploying on ARO.
 
-4. Set [environment variables](deployment-guidance.md#env)
+1. Set [environment variables](deployment-guidance.md#env)
 
-5. Deploy big data cluster
+1. Deploy big data cluster
 
    ```console
    azdata bdc create --config custom-openshift --accept-eula yes
    ```
 
-6. Upon successful deployment, you can log in and list the external cluster endpoints:
+1. Upon successful deployment, you can log in and list the external cluster endpoints:
 
 ```console
    azdata login -n mssql-cluster
@@ -122,7 +131,7 @@ This article outlines deployment steps that are specific to the OpenShift platfo
 
 ## OpenShift specific settings in the deployment configuration files
 
-SQL Server 2019 CU5 introduces two feature switches to control the collection of pod and node metrics. These parameters  are set to *false*  by default in the built-in profiles for OpenShift since the monitoring containers require [privileged security context](https://www.openshift.com/blog/managing-sccs-in-openshift), which will relax some of the secuirty constraints for the namespace BDC is deployed on.
+SQL Server 2019 CU5 introduces two feature switches to control the collection of pod and node metrics. These parameters  are set to *false*  by default in the built-in profiles for OpenShift since the monitoring containers require [privileged security context](https://www.openshift.com/blog/managing-sccs-in-openshift), which will relax some of the security constraints for the namespace BDC is deployed on.
 
 ```json
     "security": {
@@ -137,13 +146,11 @@ The name of the default storage class in ARO is managed-premium (as opposed to A
     },
     "storage": {
       "data": {
-        "className": "default",
         "className": "managed-premium",
         "accessMode": "ReadWriteOnce",
         "size": "15Gi"
       },
       "logs": {
-        "className": "default",
         "className": "managed-premium",
         "accessMode": "ReadWriteOnce",
         "size": "10Gi"
@@ -157,7 +164,7 @@ apiVersion: security.openshift.io/v1
 kind: SecurityContextConstraints
 metadata:
   annotations:
-    kubernetes.io/description: SQL Server BDC Nonroot scc is based on 'nonroot' scc plus additional capabilities.
+    kubernetes.io/description: SQL Server BDC custom scc is based on 'nonroot' scc plus additional capabilities.
   generation: 2
   name: bdc-scc
 allowHostDirVolumePlugin: false
@@ -168,30 +175,30 @@ allowHostPorts: false
 allowPrivilegeEscalation: true
 allowPrivilegedContainer: false
 allowedCapabilities:
-- SETUID
-- SETGID
-- CHOWN
-- SYS_PTRACE
+  - SETUID
+  - SETGID
+  - CHOWN
+  - SYS_PTRACE
 defaultAddCapabilities: null
 fsGroup:
   type: RunAsAny
 readOnlyRootFilesystem: false
 requiredDropCapabilities:
-- KILL
-- MKNOD
+  - KILL
+  - MKNOD
 runAsUser:
   type: MustRunAsNonRoot
 seLinuxContext:
   type: MustRunAs
 supplementalGroups:
   type: RunAsAny
 volumes:
-- configMap
-- downwardAPI
-- emptyDir
-- persistentVolumeClaim
-- projected
-- secret
+  - configMap
+  - downwardAPI
+  - emptyDir
+  - persistentVolumeClaim
+  - projected
+  - secret
 ```
 
 ## Next steps
diff --git a/docs/big-data-cluster/deployment-guidance.md b/docs/big-data-cluster/deployment-guidance.md
@@ -17,31 +17,13 @@ ms.technology: big-data-cluster
 
 A SQL Server big data cluster is deployed as docker containers on a Kubernetes cluster. This is an overview of the setup and configuration steps:
 
-- Set up a Kubernetes cluster on a single VM, cluster of VMs, or in Azure Kubernetes Service (AKS).
+- Set up a Kubernetes cluster on a single VM, cluster of VMs, in Azure Kubernetes Service (AKS), Red Hat OpenShift or in Azure Red Hat OpenShift (ARO).
 - Install the cluster configuration tool `azdata` on your client machine.
 - Deploy a SQL Server big data cluster in a Kubernetes cluster.
 
-
 ## Supported platforms
 
-This section explains platforms that are supported with BDC.
-
-### Kubernetes platforms
-
-|Platform|Supported versions|
-|---------|---------|
-|Kubernetes|BDC requires Kubernetes version minimum 1.13 for both server and client (kubectl). See [Kubernetes version and version skew support policy](https://kubernetes.io/docs/setup/release/version-skew-policy/) for Kubernetes version support policy.|
-|Azure Kubernetes Service (AKS)|BDC requires AKS version minimum 1.13.<br/>See [Supported Kubernetes versions in AKS](/azure/aks/supported-kubernetes-versions) for version support policy.|
-
-> [!NOTE]
-> Note that the client and server Kubernetes versions should be within +1 or -1 minor version. For more information, see [Kubernetes release notes and version skew SKU policy)](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/release/versioning.md#supported-releases-and-component-skew).
-
-### Host OS for Kubernetes
-
-|Platform|Supported versions|
-|---------|---------|
-|Red Hat Enterprise Linux|7.3, 7.4, 7.5, 7.6|
-|Ubuntu|16.04|
+See [Supported platforms](release-notes-big-data-cluster.md#supported-platforms) for a complete list of the various Kubernetes platforms validated for deploying SQL Server Big Data Clusters.
 
 ### SQL Server Editions
 
@@ -51,8 +33,6 @@ This section explains platforms that are supported with BDC.
 
 ## <a id="prereqs"></a> Kubernetes
 
-
-
 ### <a id="kubernetes"></a> Kubernetes cluster setup
 
 If you already have a Kubernetes cluster that meets the above prerequisites, then you can skip directly to the [deployment step](#deploy). This section assumes a basic understanding of Kubernetes concepts.  For detailed information on Kubernetes, see the [Kubernetes documentation](https://kubernetes.io/docs/home).
diff --git a/docs/big-data-cluster/quickstart-big-data-cluster-deploy-aro.md b/docs/big-data-cluster/quickstart-big-data-cluster-deploy-aro.md
@@ -220,10 +220,10 @@ allowHostPorts: false
 allowPrivilegeEscalation: true
 allowPrivilegedContainer: false
 allowedCapabilities:
-- SETUID
-- SETGID
-- CHOWN
-- SYS_PTRACE
+  - SETUID
+  - SETGID
+  - CHOWN
+  - SYS_PTRACE
 apiVersion: security.openshift.io/v1
 defaultAddCapabilities: null
 fsGroup:
@@ -236,21 +236,21 @@ metadata:
   name: bdc-scc
 readOnlyRootFilesystem: false
 requiredDropCapabilities:
-- KILL
-- MKNOD
+  - KILL
+  - MKNOD
 runAsUser:
   type: MustRunAsNonRoot
 seLinuxContext:
   type: MustRunAs
 supplementalGroups:
   type: RunAsAny
 volumes:
-- configMap
-- downwardAPI
-- emptyDir
-- persistentVolumeClaim
-- projected
-- secret
+  - configMap
+  - downwardAPI
+  - emptyDir
+  - persistentVolumeClaim
+  - projected
+  - secret
 ```
 
 ## Next steps
diff --git a/docs/database-engine/configure-windows/configure-the-max-degree-of-parallelism-server-configuration-option.md b/docs/database-engine/configure-windows/configure-the-max-degree-of-parallelism-server-configuration-option.md
@@ -32,7 +32,7 @@ ms.custom: contperfq4
   
 -   If the affinity mask option is not set to the default, it may restrict the number of processors available to [!INCLUDE[ssNoVersion](../../includes/ssnoversion-md.md)] on symmetric multiprocessing (SMP) systems.  
 
--   The **max degree of parallelism (MAXDOP)** limit is set per [task](../../relational-databases/system-dynamic-management-views/sys-dm-os-tasks-transact-sql.md). It is not a per [request](../../relational-databases/system-dynamic-management-views/sys-dm-exec-requests-transact-sql.md) or per query limit. This means that during a parallel query execution, a single request can spawn multiple tasks which are assigned to a scheduler. For more information, see the [Thread and Task Architecture Guide](../../relational-databases/thread-and-task-architecture-guide.md). 
+-   The **max degree of parallelism (MAXDOP)** limit is set per [task](../../relational-databases/system-dynamic-management-views/sys-dm-os-tasks-transact-sql.md). It is not a per [request](../../relational-databases/system-dynamic-management-views/sys-dm-exec-requests-transact-sql.md) or per query limit. This means that during a parallel query execution, a single request can spawn multiple tasks up to the MAXDOP limit, and each task will use one worker and one scheduler. For more information, see the *Scheduling parallel tasks* section in the [Thread and Task Architecture Guide](../../relational-databases/thread-and-task-architecture-guide.md). 
   
 ###  <a name="Recommendations"></a> Recommendations  
   
diff --git a/docs/relational-databases/replication/configure-distribution-availability-group.md b/docs/relational-databases/replication/configure-distribution-availability-group.md
@@ -68,7 +68,7 @@ After a distribution database in the AG is configured based on the steps describ
    >[!NOTE]
    >Before executing any of replication stored procedures (for example - `sp_dropdistpublisher`, `sp_dropdistributiondb`, `sp_dropdistributor`, `sp_adddistributiondb`, `sp_adddistpublisher`) on secondary replica, make sure the replica is fully synchronized.
 
-- All secondary replicas in a distribution database AG should be readable. If a secondary replica is not readable, distributor properties in SQL Server Management Studio on the particular secondary replica can not be accessed.
+- All secondary replicas in a distribution database AG should be readable. If a secondary replica is not readable, distributor properties in SQL Server Management Studio on the particular secondary replica can not be accessed, however replication will continue to work correctly. 
 - All the nodes in the distribution database AG need to use the same domain account to run SQL Server Agent, and this domain account needs to have the same privilege on each node.
 - If any replication agents run under a proxy account, the proxy account needs to exist in every node in the distribution database AG and have the same privilege on each node.
 - Make changes to distributor or distribution database properties in all replicas participating in distribution database AG.
diff --git a/docs/relational-databases/thread-and-task-architecture-guide.md b/docs/relational-databases/thread-and-task-architecture-guide.md
