Merge pull request #288013 from MicrosoftDocs/repo_sync_working_branch

Confirm merge from repo_sync_working_branch to main to sync with https://github.com/MicrosoftDocs/azure-docs (branch main)

Author: Taojunshen

articles/application-gateway/configuration-infrastructure.md

@@ -133,7 +133,7 @@ After you configure *active public and private listeners* (with rules) *with the
 
 | Source  | Source ports | Destination | Destination ports | Protocol | Access |
 |---|---|---|---|---|---|
-|`<as per need>`|Any|`<Public and Private<br/>frontend IPs>`|`<listener ports>`|TCP|Allow|
+|`<as per need>`|Any|`<Public and Private frontend IPs>`|`<listener ports>`|TCP|Allow|
 
 **Infrastructure ports**: Allow incoming requests from the source as the **GatewayManager** service tag and **Any** destination. The destination port range differs based on SKU and is required for communicating the status of the backend health. These ports are protected/locked down by Azure certificates. External entities can't initiate changes on those endpoints without appropriate certificates in place.
 

articles/backup/azure-kubernetes-service-backup-overview.md

@@ -74,7 +74,7 @@ Azure Backup for AKS currently supports the following two options when doing a r
 2. **Patch**: This option allows the patching mutable variable in the backed-up resource on the resource in the target cluster. If you want to update the number of replicas in the target cluster, you can opt for patching as an operation. 
 
 >[!Note]
->AKS backup currently doesn't delete and recreate resources in the target cluster if they already exist. If you attempt to restore Persistent Volumess in the original location, delete the existing Persistent Volumes, and then do the restore operation.
+>AKS backup currently doesn't delete and recreate resources in the target cluster if they already exist. If you attempt to restore Persistent Volumes in the original location, delete the existing Persistent Volumes, and then do the restore operation.
 
 ## Use custom hooks for backup and restore
 

articles/healthcare-apis/fhir/fhir-best-practices.md

@@ -25,7 +25,7 @@ Azure FHIR service supports data ingestion through the import operation, which o
 
 To achieve optimal performance with the import operation, consider the following best practices.
 
-* **Do** use large files while ingesting data. The optimal DNJSON file size for import is 50 MB or larger (or 20,000 resources or more, with no upper limit). Combining smaller files into larger ones can enhance performance.
+* **Do** use large files while ingesting data. The optimal NDJSON file size for import is 50 MB or larger (or 20,000 resources or more, with no upper limit). Combining smaller files into larger ones can enhance performance.
 * **Consider** using the import operation over HTTP API requests to ingest the data into FHIR service. The import operation provides a high throughput and is a scalable method for loading data.
 * **Consider** importing all FHIR resource files in a single import operation for optimal performance. Aim for a total file size of 100 GB or more (or 100 million resources, no upper limit) in one operation. Maximizing an import in this way helps reduce the overhead associated with managing multiple import jobs.
 * **Consider** running multiple concurrent imports only if necessary, but limit parallel import jobs. A single large import is designed to consume all available system resources, and processing throughput doesn't increase with concurrent import jobs.

includes/elastic-san-regions.md

@@ -11,35 +11,35 @@
 ---
 The following list contains the regions Elastic SAN is currently available in, and which regions support both zone-redundant storage (ZRS) and locally redundant storage (LRS), or only LRS:
 
-- South Africa North - LRS
-- East Asia - LRS
-- Southeast Asia - LRS
+- Australia East - LRS
 - Brazil South - LRS
 - Canada Central - LRS
+- Central US - LRS
+- East Asia - LRS
+- East US - LRS
+- East US 2 - LRS
 - France Central - LRS & ZRS
 - Germany West Central - LRS
-- Australia East - LRS
-- North Europe - LRS & ZRS
-- West Europe - LRS & ZRS 
-- UK South - LRS
+- India Central - LRS
 - Japan East - LRS
 - Korea Central - LRS
-- Central US - LRS
-- East US - LRS 
+- North Europe - LRS & ZRS
+- Norway East - LRS
+- South Africa North - LRS
 - South Central US - LRS
-- East US 2 - LRS 
-- West US 2 - LRS & ZRS
-- West US 3 - LRS
+- Southeast Asia - LRS
 - Sweden Central - LRS
 - Switzerland North - LRS
-- Norway East - LRS
 - UAE North - LRS
-- India Central - LRS
+- UK South - LRS
+- West Europe - LRS & ZRS
+- West US 2 - LRS & ZRS
+- West US 3 - LRS
 
 Elastic SAN is also available in the following regions, but without Availability Zone support: 
 - Canada East - LRS
-- North Central US - LRS
 - Japan West - LRS
+- North Central US - LRS
 
 To enable these regions, run the following command to register the necessary feature flag: 
 ```azurepowershell