Merge pull request #296241 from roygara/fixPrac

Fixing score and improving readability

Author: JamesJBarnett

articles/storage/elastic-san/elastic-san-best-practices.md

@@ -4,7 +4,7 @@ description: Learn about the best practices for getting optimal performance when
 author: roygara
 ms.service: azure-elastic-san-storage
 ms.topic: conceptual
-ms.date: 08/13/2024
+ms.date: 04/21/2025
 ms.author: rogarana
 ---
 
@@ -14,18 +14,37 @@ This article provides some general guidance on getting optimal performance with
 
 ## Client-side optimizations
 
-### General recommendations (Windows & Linux Virtual Machines)
+### General recommendations
 
-- For best performance, deploy your VMs and Elastic SAN in the same zone and the same region.
+#### Windows & Linux Virtual Machines
+
+- For best performance, deploy your virtual machines (VM) and Elastic SAN in the same zone and the same region.
 
 - VM storage I/O to Elastic SAN volumes uses VM network bandwidth, so traditional disk throughput limits on a VM don't apply to Elastic SAN volumes. Choose a VM that can provide sufficient bandwidth for production/VM-to-VM I/O and iSCSI I/O to attached Elastic SAN volumes. Generally, you should use Gen 5 (D / E / M series) VMs for the best performance.
 
-- Enable “Accelerated Networking” on the VM, during VM creation. To do it via Azure PowerShell or Azure CLI or to enable Accelerated Networking on existing VMs, see [Use Azure PowerShell to create a VM with Accelerated Networking](../../virtual-network/create-vm-accelerated-networking-powershell.md)
+- Enable **Accelerated Networking** on the VM during creation. To do it via Azure PowerShell or Azure CLI or to enable Accelerated Networking on existing VMs, see [Use Azure PowerShell to create a VM with Accelerated Networking](../../virtual-network/create-vm-accelerated-networking-powershell.md)
 
 :::image type="content" source="media/elastic-san-best-practices/enable-accelerated-networking.png" alt-text="Screenshot of VM creation flow, enable accelerated networking highlighted." lightbox="media/elastic-san-best-practices/enable-accelerated-networking.png":::
 
 - You must use 32 sessions per target volume for each volume to achieve its maximum IOPS and/or throughput limits. Use Multipath I/O (MPIO) on the client to manage these multiple sessions to each volume for load balancing. Scripts are available for [Windows](elastic-san-connect-windows.md#connect-to-volumes), [Linux](elastic-san-connect-linux.md#connect-to-volumes), or on the Connect to volume page for your volumes in the Azure portal, which uses 32 sessions by default. Windows software iSCSI initiator has a limit of maximum 256 sessions. If you need to connect more than eight volumes to a Windows VM, reduce the number of sessions to each volume as needed. 
 
+#### Azure VMware Solution
+
+- Deploy your Elastic SAN in the same region and availability zone as your Azure VMware Solution cluster
+-  Configure Private Endpoints before mounting your Elastic SAN volume as an external datastore
+- If you plan for your environment to ever have 16 nodes in an Azure VMware Solution cluster, use one of the following configurations, depending on which hosts you have.
+    - AV36, AV36P, AV52 - Six iSCSI sessions over three Private Endpoints
+    - AV64 - Seven iSCSI sessions over seven Private Endpoints
+- If your environment won't have 16 nodes, use one of the following configurations.
+    -  AV36, AV36P, AV52 - Eight iSCSI sessions over four Private Endpoints
+    - AV64 - Eight iSCSI sessions over eight Private Endpoints
+
+    > [!NOTE]
+    > When an Elastic SAN volume is attached to a cluster, it automatically attaches to all nodes. If you have 16 nodes and each node is configured to use eight iSCSI sessions that uses the maximum number of connections (128). Configuring your nodes to use seven iSCSI sessions ensures that if you need to attach an extra node (for maintenance) then you have available iSCSI sessions. 
+
+- Use eager zeroed thick provisioning when creating virtual disks
+- Size ExpressRoute Gateway so that it can meet your throughput requirements
+- Configure your Elastic SAN to have at least 16 TiB in its base size, so you can get up to the maximum performance on your Elastic SAN datastores
 
 ### MPIO
 
@@ -47,7 +66,7 @@ For more information regarding MPIO cmdlets, see [MPIO reference](/powershell/mo
 
 #### Linux
 
-Update /etc/multipath.conf file with the following: 
+Update /etc/multipath.conf file with the following commands: 
 
 ```config
 defaults {
@@ -66,11 +85,16 @@ devices {
 }
 ```
 
+#### Azure VMware Solution
+
+Microsoft manages MPIO settings for Azure VMware Solution. Optimal values are set when you create a datastore.
+
+
 ### iSCSI
 
 #### Windows
 
-Update the below registry settings for iSCSI initiator on Windows.
+Update the registry settings for iSCSI initiator on Windows.
 
 1.	Open Registry Editor:
 1. Select Start, type regedit in the search box and press enter.
@@ -97,39 +121,56 @@ In cluster configurations, ensure iSCSI initiator names unique across all nodes
 
     :::image type="content" source="media/elastic-san-best-practices/iscsi-initiator-config-widnows.png" alt-text="Screenshot of iSCSI Initiator configuration on Windows." lightbox="media/elastic-san-best-practices/iscsi-initiator-config-widnows.png"::: 
 
-1.	To modify it, select **Change**, enter new initiator name and select OK.
+1.	To modify it, select **Change**, enter new initiator name, and select OK.
 
     :::image type="content" source="media/elastic-san-best-practices/update-iscsi-initiator-name-windows.png" alt-text="Screenshot of updating the iSCSI Initiator Name on Windows." lightbox="media/elastic-san-best-practices/update-iscsi-initiator-name-windows.png"::: 
 
 
 #### Linux
 
-Update the following settings with recommended values in global iSCSI configuration file (iscsid.conf, generally found in /etc/iscsi directory) on the client before connecting any volumes to it. When a volume is connected, a node is created along with a configuration file specific to that node (for example on Ubuntu, it can be found in /etc/iscsi/nodes/$volume_iqn/portal_hostname,$port directory) inheriting the settings from global configuration file. If you have already connected one or more volumes to the client before updating global configuration file, update the node specific configuration file for each volume directly or using the following command:
+Update the following settings with recommended values in global iSCSI configuration file (iscsid.conf, generally found in /etc/iscsi directory) on the client before connecting any volumes to it. When a volume is connected, a node is created along with a configuration file specific to that node (for example on Ubuntu VMs, it can be found in the `/etc/iscsi/nodes/$volume_iqn/portal_hostname,$port` directory) inheriting the settings from global configuration file. If you already connected one or more volumes to the client before updating global configuration file, update the node specific configuration file for each volume directly or using the following command:
 
-sudo iscsiadm -m node -T $volume_iqn -p $portal_hostname:$port -o update -n $iscsi_setting_name -v $setting_value
+```
+# Variable declaration
+volume_iqn=<Elastic SAN volume IQN>
+portal_hostname=<Elastic SAN volume portal hostname>
+port=3260
 
-Where 
-- $volume_iqn: Elastic SAN volume IQN
-- $portal_hostname: Elastic SAN volume portal hostname
-- $port: 3260
-- $iscsi_setting_name: parameter for each setting listed below
-- $setting_value: value recommended for each setting below
+# Set maximum data the initiator sends in an iSCSI PDU to the target to 256 KB
+sudo iscsiadm -m node -T $volume_iqn -p $portal_hostname:$port -o update -n node.conn[0].iscsi.MaxXmitDataSegmentLength -v 262144
 
-|Description  |Parameter and value  |
-|---------|---------|
-|# Set maximum data the initiator sends in an iSCSI PDU to the target to 256 KB     |node.conn[0].iscsi.MaxXmitDataSegmentLength = 262144         |
-|# Set maximum SCSI payload that the initiator negotiates with the target to 256 KB     |node.session.iscsi.MaxBurstLength = 262144         |
-|# Set maximum unsolicited data the initiator can send in an iSCSI PDU to a target to 256 KB     |node.session.iscsi.FirstBurstLength = 262144         |
-|# Set maximum data the initiator can receive in an iSCSI PDU from the target to 256 KB     |node.conn[0].iscsi.MaxRecvDataSegmentLength = 262144         |
-|# Disable R2T flow control     |node.session.iscsi.InitialR2T = No         |
-|# Enable immediate data     |node.session.iscsi.ImmediateData = Yes         |
-|# Set timeout value for WMI requests     |node.conn[0].timeo.login_timeout = 30<br></br>node.conn[0].timeo.logout_timeout = 15         |
-|# Enable CRC digest checking for header and data     |node.conn[0].iscsi.HeaderDigest = CRC32C<br></br>node.conn[0].iscsi.DataDigest = CRC32C         |
+# Set maximum SCSI payload that the initiator negotiates with the target to 256 KB
+sudo iscsiadm -m node -T $volume_iqn -p $portal_hostname:$port -o update -n node.session.iscsi.MaxBurstLength -v 262144
 
+# Set maximum unsolicited data the initiator can send in an iSCSI PDU to a target to 256 KB 
+sudo iscsiadm -m node -T $volume_iqn -p $portal_hostname:$port -o update -n node.session.iscsi.FirstBurstLength -v 262144
 
-In cluster configurations, ensure iSCSI initiator names are unique across all nodes that are sharing volumes. In Linux, you can modify /etc/iscsi/initiatorname.iscsi to update the initiator name.
+# Set maximum data the initiator can receive in an iSCSI PDU from the target to 256 KB 
+sudo iscsiadm -m node -T $volume_iqn -p $portal_hostname:$port -o update -n node.conn[0].iscsi.MaxRecvDataSegmentLength -v 262144
+
+# Disable R2T flow control 
+sudo iscsiadm -m node -T $volume_iqn -p $portal_hostname:$port -o update -n node.session.iscsi.InitialR2T -v No
+
+# Enable immediate data
+sudo iscsiadm -m node -T $volume_iqn -p $portal_hostname:$port -o update -n node.session.iscsi.ImmediateData -v Yes
+
+# Set timeout value for WMI requests
+sudo iscsiadm -m node -T $volume_iqn -p $portal_hostname:$port -o update -n node.conn[0].timeo.login_timeout -v 30
+sudo iscsiadm -m node -T $volume_iqn -p $portal_hostname:$port -o update -n node.conn[0].timeo.logout_timeout -v 15
+
+# Enable CRC digest checking for header and data 
+sudo iscsiadm -m node -T $volume_iqn -p $portal_hostname:$port -o update -n node.conn[0].iscsi.HeaderDigest -v CRC32C
+sudo iscsiadm -m node -T $volume_iqn -p $portal_hostname:$port -o update -n node.conn[0].iscsi.DataDigest -v CRC32C 
+
+```
+
+
+In cluster configurations, ensure iSCSI initiator names are unique across all nodes that are sharing volumes. In Linux, modify /etc/iscsi/initiatorname.iscsi to update the initiator name.
 :::image type="content" source="media/elastic-san-best-practices/update-iscsi-initiator-name-linux.png" alt-text="Screenshot updating the iSCSI Initiator Name on Linux." lightbox="media/elastic-san-best-practices/update-iscsi-initiator-name-linux.png"::: 
 
+#### Azure VMware Solution
+
+Microsoft manages iSCSI settings. Optimal values are set when you create a datastore.
 
 ## Elastic SAN optimizations