Merge pull request #288424 from kikucher/kikucher-patch-3

Changes for newly added CRC protection feature

Author: JamesJBarnett

articles/storage/elastic-san/elastic-san-networking-concepts.md

@@ -29,6 +29,15 @@ After configuring endpoints, you can configure network rules to further control
 
 You can enable or disable public Internet access to your Elastic SAN endpoints at the SAN level. Enabling public network access for an Elastic SAN allows you to configure public access to individual volume groups in that SAN over storage service endpoints. By default, public access to individual volume groups is denied even if you allow it at the SAN level. If you disable public access at the SAN level, access to the volume groups within that SAN is only available over private endpoints.
 
+## Data Integrity
+
+Data integrity is important for preventing data corruption in cloud storage. TCP provides a foundational level of data integrity through its checksum mechanism, it can be enhanced over iSCSI with more robust error detection with a cyclic redundancy check (CRC), specifically CRC-32C. CRC-32C can be used to add checksum verification for iSCSI headers and data payloads.
+
+Elastic SAN supports CRC-32C checksum verification when enabled on the client side for connections to Elastic SAN volumes. Elastic SAN also offers the ability to enforce this error detection through a property that can be set at the volume group level, which is inherited by any volume within that volume group. When you enable this property on a volume group, Elastic SAN rejects all client connections to any volumes in the volume group if CRC-32C isn't set for header or data digests on those connections. When you disable this property, Elastic SAN volume checksum verification depends on whether CRC-32C is set for header or data digests on the client, but your Elastic SAN won't reject any connections. To learn how to enable CRC protection, see [Configure networking](elastic-san-networking.md#enable-iscsi-error-detection).
+
+> [!NOTE]
+> Some operating systems may not support iSCSI header or data digests. Fedora and its downstream Linux distributions like Red Hat Enterprise Linux, CentOS, Rocky Linux, etc. don't support data digests. Don't enable CRC protection on your volume groups if your clients use operating systems like these that don't support iSCSI header or data digests because connections to the volumes will fail.
+
 ## Storage service endpoints
 
 [Azure Virtual Network service endpoints](../../virtual-network/virtual-network-service-endpoints-overview.md) provide secure and direct connectivity to Azure services using an optimized route over the Azure backbone network. Service endpoints allow you to secure your critical Azure service resources so only specific virtual networks can access them.
@@ -77,4 +86,4 @@ iSCSI sessions can periodically disconnect and reconnect over the course of the
 
 ## Next steps
 
-[Configure Elastic SAN networking](elastic-san-networking.md)
+[Configure Elastic SAN networking](elastic-san-networking.md)

articles/storage/elastic-san/elastic-san-networking.md

@@ -130,6 +130,112 @@ az elastic-san update \
 
 ---
 
+## Configure iSCSI error detection
+
+### Enable iSCSI error detection
+
+To enable CRC-32C checksum verification for iSCSI headers or data payloads, set CRC-32C on header or data digests for all connections on your clients that connect to Elastic SAN volumes. To do this, connect your clients to Elastic SAN volumes using multi-session scripts generated either in the Azure portal or provided in either the [Windows](elastic-san-connect-windows.md) or [Linux](elastic-san-connect-Linux.md) Elastic SAN connection articles.
+
+If you need to, you can do this without the multi-session connection scripts. On Windows, you can do this by setting header or data digests to 1 during login to the Elastic SAN volumes (`LoginTarget` and `PersistentLoginTarget`). On Linux, you can do this by updating the global iSCSI configuration file (iscsid.conf, generally found in /etc/iscsi directory). 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 volumes to your client before updating your 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```
+
+Where
+- $volume_iqn: Elastic SAN volume IQN
+- $portal_hostname: Elastic SAN volume portal hostname
+- $port: 3260
+- $iscsi_setting_name: node.conn[0].iscsi.HeaderDigest (or) node.conn[0].iscsi.DataDigest 
+- $setting_value: CRC32C
+
+### Enforce iSCSI error detection
+
+To enforce iSCSI error detection, set CRC-32C for both header and data digests on your clients and enable the CRC protection property on the volume group that contains volumes already connected to or have yet to be connected to from your clients. If your Elastic SAN volumes are already connected and don't have CRC-32C for both digests, you should disconnect the volumes and reconnect them using multi-session scripts generated in the Azure portal when connecting to an Elastic SAN volume, or from the [Windows](elastic-san-connect-windows.md) or [Linux](elastic-san-connect-Linux.md) Elastic SAN connection articles.
+
+> [!NOTE]
+> CRC protection feature isn't currently available in North Europe and South Central US.
+
+To enable CRC protection on the volume group:
+
+# [Portal](#tab/azure-portal)
+
+Enable CRC protection on a new volume group:
+
+:::image type="content" source="media/elastic-san-networking/elastic-san-crc-protection-create-volume-group.png" alt-text="Screenshot of CRC protection enablement on new volume group." lightbox="media/elastic-san-networking/elastic-san-crc-protection-create-volume-group.png":::
+
+Enable CRC protection on an existing volume group:
+
+:::image type="content" source="media/elastic-san-networking/elastic-san-crc-protection-update-volume-group.png" alt-text="Screenshot of CRC protection enablement on an existing volume group." lightbox="media/elastic-san-networking/elastic-san-crc-protection-update-volume-group.png":::
+
+# [PowerShell](#tab/azure-powershell)
+
+Use this script to enable CRC protection on a new volume group using the Azure PowerShell module. Replace the values of `$RgName`, `$EsanName`, `$EsanVgName` before running the script.
+
+```powershell
+# Set the variable values.
+# The name of the resource group where the Elastic San is deployed.
+$RgName = "<ResourceGroupName>"
+# The name of the Elastic SAN.
+$EsanName = "<ElasticSanName>"
+# The name of volume group within the Elastic SAN.
+$EsanVgName = "<VolumeGroupName>"
+
+# Create a volume group by enabling CRC protection
+New-AzElasticSanVolumeGroup -ResourceGroupName $RgName -ElasticSANName $EsanName -Name $EsanVgName -EnforceDataIntegrityCheckForIscsi $true
+
+```
+
+Use this script to enable CRC protection on an existing volume group using the Azure PowerShell module. Replace the values of `$RgName`, `$EsanName`, `$EsanVgName` before running the script.
+
+```powershell
+# Set the variable values.
+$RgName = "<ResourceGroupName>"
+$EsanName = "<ElasticSanName>"
+$EsanVgName = "<VolumeGroupName>"
+
+# Edit a volume group to enable CRC protection
+Update-AzElasticSanVolumeGroup -ResourceGroupName $RgName -ElasticSANName $EsanName -Name $EsanVgName -EnforceDataIntegrityCheckForIscsi $true
+```
+
+# [Azure CLI](#tab/azure-cli)
+
+The following code sample enable CRC protection on a new volume group using Azure CLI. Replace the values of `RgName`, `EsanName`, `EsanVgName`, before running the sample.
+
+```azurecli
+# Set the variable values.
+# The name of the resource group where the Elastic San is deployed.
+RgName="<ResourceGroupName>"
+# The name of the Elastic SAN.
+EsanName="<ElasticSanName>"
+# The name of volume group within the Elastic SAN.
+EsanVgName= "<VolumeGroupName>"
+
+# Create the Elastic San.
+az elastic-san volume-group create \
+    --elastic-san-name $EsanName \
+    --resource-group $RgName \
+    --volume-group-name $EsanVgName \
+    --data-integrity-check true
+```
+
+The following code sample enable CRC protection on an existing volume group using Azure CLI. Replace the values of `RgName`, `EsanName`, `EsanVgName`, before running the sample.
+
+```azurecli
+# Set the variable values.
+RgName="<ResourceGroupName>"
+EsanName="<ElasticSanName>"
+EsanVgName= "<VolumeGroupName>"
+
+# Create the Elastic San.
+az elastic-san volume-group update \
+    --elastic-san-name $EsanName \
+    --resource-group $RgName \
+    --volume-group-name $EsanVgName \
+    --data-integrity-check true
+```
+
+---
+
+
 ## Configure a virtual network endpoint
 
 You can configure your Elastic SAN volume groups to allow access only from endpoints on specific virtual network subnets. The allowed subnets can belong to virtual networks in the same subscription, or those in a different subscription, including a subscription belonging to a different Microsoft Entra tenant.