Merge pull request #218410 from alfpark/batch1

Update Batch simplified recommendations

Author: v-regandowner

articles/batch/TOC.yml

@@ -105,11 +105,13 @@
     href: batch-compute-node-environment-variables.md
   - name: Feature retirements
     items:
+    - name: Cloud Service Configuration Pools
+      href: batch-pool-cloud-service-to-virtual-machine-configuration.md
     - name: Batch certificates
       href: batch-certificate-migration-guide.md
     - name: Pools without public IP addresses (classic)
       href: batch-pools-without-public-IP-addresses-classic-retirement-migration-guide.md
-    - name: TLS 1.0 and TLS 1.1 
+    - name: TLS 1.0 and TLS 1.1
       href: batch-tls-101-migration-guide.md
     - name: Job and pool lifetime statistics
       href: job-pool-lifetime-statistics-migration-guide.md
@@ -135,8 +137,6 @@
       href: batch-customer-managed-key.md
     - name: Move between regions
       href: account-move.md
-    - name: Use simplified compute node communication
-      href: simplified-compute-node-communication.md
   - name: Authenticate with Azure AD
     items:
     - name: Azure AD with Batch service
@@ -156,6 +156,8 @@
       href: resource-files.md
   - name: Create and manage pools
     items:
+    - name: Use simplified compute node communication
+      href: simplified-compute-node-communication.md
     - name: Autoscale compute nodes
       displayName: scaling, dynamic, formula
       href: batch-automatic-scaling.md

articles/batch/batch-pool-cloud-service-to-virtual-machine-configuration.md

@@ -9,7 +9,7 @@ ms.date: 09/03/2021
 
 Currently, Batch pools can be created using either [virtualMachineConfiguration](/rest/api/batchservice/pool/add#virtualmachineconfiguration) or [cloudServiceConfiguration](/rest/api/batchservice/pool/add#cloudserviceconfiguration). We recommend using Virtual Machine Configuration only, as this configuration supports all Batch capabilities.
 
-Cloud Services Configuration pools don't support some of the current Batch features, and won't support any newly-added features. You won't be able to create new 'CloudServiceConfiguration' pools or add new nodes to existing pools [after February 29, 2024](https://azure.microsoft.com/updates/azure-batch-cloudserviceconfiguration-pools-will-be-retired-on-29-february-2024/).
+Cloud Services Configuration pools don't support some of the current Batch features, and won't support any newly added features. You won't be able to create new 'CloudServiceConfiguration' pools or add new nodes to existing pools [after February 29, 2024](https://azure.microsoft.com/updates/azure-batch-cloudserviceconfiguration-pools-will-be-retired-on-29-february-2024/).
 
 If your Batch solutions currently use 'cloudServiceConfiguration' pools, we recommend changing to 'virtualMachineConfiguration' as soon as possible. This will enable you to benefit from all Batch capabilities, such as an expanded [selection of VM series](batch-pool-vm-sizes.md), Linux VMs, [containers](batch-docker-container-workloads.md), [Azure Resource Manager virtual networks](batch-virtual-network.md), and [node disk encryption](disk-encryption.md).
 
@@ -31,7 +31,7 @@ Some of the key differences between the two configurations include:
 - 'virtualMachineConfiguration' pool nodes utilize managed OS disks. The [managed disk type](../virtual-machines/disks-types.md) that is used for each node depends on the VM size chosen for the pool. If a 's' VM size is specified for the pool, for example 'Standard_D2s_v3', then a premium SSD is used. If a 'non-s' VM size is specified, for example 'Standard_D2_v3', then a standard HDD is used.
 
    > [!IMPORTANT]
-   > As with Virtual Machines and Virtual Machine Scale Sets, the OS managed disk used for each node incurs a cost, which is additional to the cost of the VMs. 'virtualMachineConfiguration' pools can use [ephemeral OS disks](create-pool-ephemeral-os-disk.md), which create the OS disk on the VM cache or temporary SSD, to avoid extra costs associated with managed disks.There is no OS disk cost for 'cloudServiceConfiguration' nodes, as the OS disk is created on the nodes local SSD.
+   > As with Virtual Machines and Virtual Machine Scale Sets, the OS managed disk used for each node incurs a cost, which is additional to the cost of the VMs. 'virtualMachineConfiguration' pools can use [ephemeral OS disks](create-pool-ephemeral-os-disk.md), which create the OS disk on the VM cache or temporary disk, to avoid extra costs associated with managed disks.There is no OS disk cost for 'cloudServiceConfiguration' nodes, as the OS disk is created on the node's local disk.
 
 ## Azure Data Factory custom activity pools
 
@@ -40,7 +40,7 @@ Azure Batch pools can be used to run Data Factory custom activities. Any 'cloudS
 When creating your new pools to run Data Factory custom activities, follow these practices:
 
 - Pause all pipelines before creating the new pools and deleting the old ones to ensure no executions will be interrupted.
-- The same pool id can be used to avoid linked service configuration changes.
+- The same pool ID can be used to avoid linked service configuration changes.
 - Resume pipelines when new pools have been created.
 
 For more information about using Azure Batch to run Data Factory custom activities, see [Azure Batch linked service](../data-factory/compute-linked-services.md#azure-batch-linked-service) and  [Custom activities in a Data Factory pipeline](../data-factory/transform-data-using-dotnet-custom-activity.md)
@@ -49,4 +49,4 @@ For more information about using Azure Batch to run Data Factory custom activiti
 
 - Learn more about [pool configurations](nodes-and-pools.md#configurations).
 - Learn more about [pool best practices](best-practices.md#pools).
-- See the REST API reference for [pool addition](/rest/api/batchservice/pool/add) and [virtualMachineConfiguration](/rest/api/batchservice/pool/add#virtualmachineconfiguration).
+- See the REST API reference for [pool addition](/rest/api/batchservice/pool/add) and [virtualMachineConfiguration](/rest/api/batchservice/pool/add#virtualmachineconfiguration).

articles/batch/batch-virtual-network.md

@@ -2,7 +2,7 @@
 title: Provision a pool in a virtual network
 description: How to create a Batch pool in an Azure virtual network so that compute nodes can communicate securely with other VMs in the network, such as a file server.
 ms.topic: how-to
-ms.date: 11/14/2022
+ms.date: 11/15/2022
 ms.custom: seodec18
 ---
 
@@ -44,9 +44,9 @@ or `CloudServiceConfiguration`. `VirtualMachineConfiguration` for Batch pools is
 pools are [deprecated](https://azure.microsoft.com/updates/azure-batch-cloudserviceconfiguration-pools-will-be-retired-on-29-february-2024/).
 
 > [!IMPORTANT]
-> Batch pools can be configured in one of two communication modes. `Classic` communication
-> mode is where the Batch service initiates communication to the compute nodes.
-> [`Simplified` communication mode](simplified-compute-node-communication.md)
+> Batch pools can be configured in one of two node communication modes. Classic node communication mode is
+> where the Batch service initiates communication to the compute nodes.
+> [Simplified](simplified-compute-node-communication.md) node communication mode
 > is where the compute nodes initiate communication to the Batch Service.
 
 ## Pools in Virtual Machine Configuration
@@ -93,8 +93,8 @@ NSG with at least the inbound and outbound security rules that are shown in the
 
 > [!WARNING]
 > Batch service IP addresses can change over time. Therefore, we highly recommend that you use the
-> BatchNodeManagement.*region* service tag (or a regional variant) for the NSG rules indicated in the
-> following tables. Avoid populating NSG rules with specific Batch service IP addresses.
+> BatchNodeManagement.*region* service tag for the NSG rules indicated in the following tables. Avoid
+> populating NSG rules with specific Batch service IP addresses.
 
 #### Inbound security rules
 

articles/batch/best-practices.md

@@ -1,7 +1,7 @@
 ---
 title: Best practices
 description: Learn best practices and useful tips for developing your Azure Batch solutions.
-ms.date: 11/14/2022
+ms.date: 11/15/2022
 ms.topic: conceptual
 ---
 
@@ -20,13 +20,37 @@ This article discusses best practices and useful tips for using the Azure Batch
 
 - **Pool allocation mode:** When creating a Batch account, you can choose between two pool allocation modes: **Batch service** or **user subscription**. For most cases, you should use the default Batch service mode, in which pools are allocated behind the scenes in Batch-managed subscriptions. In the alternative user subscription mode, Batch VMs and other resources are created directly in your subscription when a pool is created. User subscription accounts are primarily used to enable a small but important subset of scenarios. For more information, see [configuration for user subscription mode](batch-account-create-portal.md#additional-configuration-for-user-subscription-mode).
 
-- **'virtualMachineConfiguration' or 'cloudServiceConfiguration':** While you can currently create pools using either configuration, new pools should be configured using 'virtualMachineConfiguration' and not 'cloudServiceConfiguration'. All current and new Batch features will be supported by Virtual Machine Configuration pools. Cloud Services Configuration pools don't support all features and no new capabilities are planned. You won't be able to create new 'cloudServiceConfiguration' pools or add new nodes to existing pools [after February 29, 2024](https://azure.microsoft.com/updates/azure-batch-cloudserviceconfiguration-pools-will-be-retired-on-29-february-2024/). For more information, see [Migrate Batch pool configuration from Cloud Services to Virtual Machine](batch-pool-cloud-service-to-virtual-machine-configuration.md).
+- **`virtualMachineConfiguration` or `cloudServiceConfiguration`:** While you can currently create pools using either
+configuration, new pools should be configured using `virtualMachineConfiguration` and not `cloudServiceConfiguration`.
+All current and new Batch features will be supported by Virtual Machine Configuration pools. Cloud Service Configuration
+pools don't support all features and no new capabilities are planned. You won't be able to create new
+`cloudServiceConfiguration` pools or add new nodes to existing pools
+[after February 29, 2024](https://azure.microsoft.com/updates/azure-batch-cloudserviceconfiguration-pools-will-be-retired-on-29-february-2024/).
+For more information, see
+[Migrate Batch pool configuration from Cloud Services to Virtual Machine](batch-pool-cloud-service-to-virtual-machine-configuration.md).
+
+- **`classic` or `simplified` node communication mode:** Pools can be configured in one of two node communication modes,
+classic or [simplified](simplified-compute-node-communication.md). In the classic node communication model, the Batch service
+initiates communication to the compute nodes, and compute nodes also require communicating to Azure Storage. In the simplified
+node communication model, compute nodes initiate communication with the Batch service. Due to the reduced scope of
+inbound/outbound connections required, and not requiring Azure Storage outbound access for baseline operation, the recommendation
+is to use the simplified node communication model. Some future improvements to the Batch service will also require the simplified
+node communication model.
 
 - **Job and task run time considerations:** If you have jobs comprised primarily of short-running tasks, and the expected total task counts are small, so that the overall expected run time of the job isn't long, don't allocate a new pool for each job. The allocation time of the nodes will diminish the run time of the job.
 
 - **Multiple compute nodes:** Individual nodes aren't guaranteed to always be available. While uncommon, hardware failures, operating system updates, and a host of other issues can cause individual nodes to be offline. If your Batch workload requires deterministic, guaranteed progress, you should allocate pools with multiple nodes.
 
-- **Images with impending end-of-life (EOL) dates:** We strongly recommended avoiding images with impending Batch support end of life (EOL) dates. These dates can be discovered via the [`ListSupportedImages` API](/rest/api/batchservice/account/listsupportedimages), [PowerShell](/powershell/module/az.batch/get-azbatchsupportedimage), or [Azure CLI](/cli/azure/batch/pool/supported-images). It's your responsibility to periodically refresh your view of the EOL dates pertinent to your pools and migrate your workloads before the EOL date occurs. If you're using a custom image with a specified node agent, ensure that you follow Batch support end-of-life dates for the image for which your custom image is derived or aligned with. An image without a specified `batchSupportEndOfLife` date indicates that such a date has not been determined yet by the Batch service. Absence of a date does not indicate that the respective image will be supported indefinitely. An EOL date may be added or updated in the future at anytime.
+- **Images with impending end-of-life (EOL) dates:** We strongly recommended avoiding images with impending Batch support
+end of life (EOL) dates. These dates can be discovered via the
+[`ListSupportedImages` API](/rest/api/batchservice/account/listsupportedimages),
+[PowerShell](/powershell/module/az.batch/get-azbatchsupportedimage), or
+[Azure CLI](/cli/azure/batch/pool/supported-images). It's your responsibility to periodically refresh your view of the EOL
+dates pertinent to your pools and migrate your workloads before the EOL date occurs. If you're using a custom image with a
+specified node agent, ensure that you follow Batch support end-of-life dates for the image for which your custom image is
+derived or aligned with. An image without a specified `batchSupportEndOfLife` date indicates that such a date hasn't been
+determined yet by the Batch service. Absence of a date doesn't indicate that the respective image will be supported
+indefinitely. An EOL date may be added or updated in the future at any time.
 
 - **Unique resource names:** Batch resources (jobs, pools, etc.) often come and go over time. For example, you may create a pool on Monday, delete it on Tuesday, and then create another similar pool on Thursday. Each new resource you create should be given a unique name that you haven't used before. You can create uniqueness by using a GUID (either as the entire resource name, or as a part of it) or by embedding the date and time that the resource was created in the resource name. Batch supports [DisplayName](/dotnet/api/microsoft.azure.batch.jobspecification.displayname), which can give a resource a more readable name even if the actual resource ID is something that isn't human-friendly. Using unique names makes it easier for you to differentiate which particular resource did something in logs and metrics. It also removes ambiguity if you ever have to file a support case for a resource.