Skip to content

Commit e4d64cc

Browse files
ttorblettorble
authored
Merge pull request #292057 from MicrosoftDocs/main
Publish to live, Tuesday 4 AM PST, 12/17
2 parents 87d281b + d269294 commit e4d64cc

12 files changed

+349
-15
lines changed

‎articles/azure-app-configuration/quickstart-feature-flag-dotnet-background-service.md

Lines changed: 27 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -9,7 +9,7 @@ ms.devlang: csharp
99
ms.custom: devx-track-csharp, mode-other, devx-track-dotnet
1010
ms.topic: quickstart
1111
ms.tgt_pltfrm: .NET
12-
ms.date: 2/19/2024
12+
ms.date: 12/17/2024
1313
ms.author: zhiyuanliang
1414
#Customer intent: As a .NET background service developer, I want to use feature flags to control feature availability quickly and confidently.
1515
---
@@ -52,10 +52,35 @@ Add a feature flag called *Beta* to the App Configuration store and leave **Labe
5252
5353
1. Add a call to the `UseFeatureFlags` method inside the `AddAzureAppConfiguration` call and register feature management services.
5454
55+
### [Microsoft Entra ID (recommended)](#tab/entra-id)
56+
5557
```csharp
5658
// Existing code in Program.cs
5759
// ... ...
60+
builder.Configuration.AddAzureAppConfiguration(options =>
61+
{
62+
string endpoint = Environment.GetEnvironmentVariable("Endpoint");
63+
options.Connect(new Uri(endpoint), new DefaultAzureCredential());
64+
65+
// Use feature flags
66+
options.UseFeatureFlags();
5867
68+
// Register the refresher so that the Worker service can consume it through dependency injection
69+
builder.Services.AddSingleton(options.GetRefresher());
70+
});
71+
72+
// Register feature management services
73+
builder.Services.AddFeatureManagement();
74+
75+
// The rest of existing code in Program.cs
76+
// ... ...
77+
```
78+
79+
### [Connection string](#tab/connection-string)
80+
81+
```csharp
82+
// Existing code in Program.cs
83+
// ... ...
5984
builder.Configuration.AddAzureAppConfiguration(options =>
6085
{
6186
options.Connect(Environment.GetEnvironmentVariable("ConnectionString"));
@@ -73,6 +98,7 @@ Add a feature flag called *Beta* to the App Configuration store and leave **Labe
7398
// The rest of existing code in Program.cs
7499
// ... ...
75100
```
101+
---
76102
77103
> [!TIP]
78104
> When no parameter is passed to the `UseFeatureFlags` method, it loads *all* feature flags with *no label* in your App Configuration store. The default refresh interval of feature flags is 30 seconds. You can customize this behavior via the `FeatureFlagOptions` parameter. For example, the following code snippet loads only feature flags that start with *TestApp:* in their *key name* and have the label *dev*. The code also changes the refresh interval time to 5 minutes. Note that this refresh interval time is separate from that for regular key-values.

‎articles/backup/backup-azure-database-postgresql-flex-support-matrix.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -2,7 +2,7 @@
22
title: Azure Database for PostgreSQL- Flexible server support matrix
33
description: Provides a summary of support settings and limitations of Azure Database for PostgreSQL- Flexible server backup.
44
ms.topic: reference
5-
ms.date: 09/09/2024
5+
ms.date: 12/17/2024
66
ms.custom: references_regions, ignite-2024
77
ms.service: azure-backup
88
author: AbhishekMallick-MS
@@ -25,7 +25,7 @@ Azure Database for PostgreSQL - Flexible server backup is now available in all p
2525

2626
- Both Cross Region and Cross Subscription backups are supported.
2727

28-
- Recommended limit for the maximum database size is 400 GB.
28+
- Recommended limit for the maximum server size is 4 TB.
2929

3030
- Recommended backup frequency for backing up a server is Weekly. In case you opt for Daily backup and observe failures, we recommend decreasing the frequency while relying on automated backup solution to achieve required RPO.
3131

‎articles/hdinsight/hdinsight-release-notes-archive.md

Lines changed: 11 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -154,6 +154,17 @@ For workload specific versions, see [HDInsight 5.x component versions](./hdinsig
154154

155155
The `setOwnerUser` implementation given in Ranger 2.3.0 release has a critical regression issue when being used by Hive. In Ranger 2.3.0, when HiveServer2 tries to evaluate the policies, Ranger Client tries to get the owner of the hive table by calling the Metastore in the setOwnerUser function which essentially makes call to storage to check access for that table. This issue causes the queries to run slow when Hive runs on 2.3.0 Ranger.
156156

157+
**New regions added**
158+
159+
* Italy North
160+
* Israel Central
161+
* Spain Central
162+
* Mexico Central
163+
* Jio India Central
164+
165+
Add to June 2024 Archive Notes
166+
167+
157168
**Coming soon**
158169

159170
* [Basic and Standard A-series VMs Retirement](https://azure.microsoft.com/updates/basic-and-standard-aseries-vms-on-hdinsight-will-retire-on-31-august-2024/).

‎articles/iot-operations/deploy-iot-ops/concept-production-examples.md

Lines changed: 119 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,119 @@
1+
---
2+
title: Production deployment examples
3+
description: Describes some example deployments to help you understand how to scale your solution.
4+
author: dominicbetts
5+
ms.author: dobett
6+
ms.topic: concept-article
7+
ms.date: 12/16/2024
8+
ms.service: azure-iot-operations
9+
10+
#CustomerIntent: I want to see some scaling recommendations before I before deploying to production.
11+
---
12+
13+
# Production deployment examples
14+
15+
This article describes two example Azure IoT Operations deployments that collect data from edge and transfer it to the cloud. These examples are based on real-world scenarios that take hardware capability and data volumes into consideration. Use these examples to better understand how much data Azure IoT Operations can handle with certain hardware.
16+
17+
Microsoft used similar configurations and data volumes to validate Azure IoT Operations and measure its performance.
18+
19+
## Single node cluster
20+
21+
This example shows the capabilities of Azure IoT Operations when it runs on a host with relatively low hardware specification. In this example, Azure IoT Operations is deployed to a single node cluster. Data generated from assets is first aggregated with a PLC, and then sent to the Azure IoT Operations OPC UA connector.
22+
23+
### Configuration
24+
25+
Example hardware specifications:
26+
27+
- K3s on Azure VM (Standard_D4ds_v5 with Intel Xeon Platinum 8370C), 4 core (4 vCPU), 16-GB memory, 30-GB storage.
28+
29+
- AKS-EE on P3 Tiny Workstation (13th Generation Intel® Core™ i7-13700 vPro® Processor), 16 core (24 threads), 32-GB memory, 1-TB storage.
30+
31+
The following table shows the MQTT broker configuration for the single node example:
32+
33+
| Parameter | Value |
34+
|--------------------------|-------|
35+
| frontendReplicas | 1 |
36+
| frontendWorkers | 1 |
37+
| backendRedundancyFactor | 1 |
38+
| backendWorkers | 1 |
39+
| backendPartitions | 1 |
40+
| memoryProfile | low |
41+
42+
The end-to-end data flow in the example looks like this:
43+
44+
`Assets -> PLC -> OPC UA connector -> MQTT broker -> Dataflows -> Event Hubs`
45+
46+
The data volumes in the example are:
47+
48+
- 125 assets aggregated by a single OPC UA server.
49+
- 6,250 tags based on 50 tags for each asset. Each tag updates 2/second and has an average size of 20 bytes.
50+
- The OPC UA connector sends 125 message/second to the MQTT broker.
51+
- One data flow pipeline pushes 6,250 tags to an Event Hubs endpoint.
52+
53+
In this example, Microsoft recommends using Event Hubs because you can only create one dataflow instance with a 4-core CPU. If you choose Event Grid, it can only handle 100 messages/sec.
54+
55+
### Performance
56+
57+
Key performance metrics for this example include:
58+
59+
- Azure IoT Operations and its dependencies consume between 6 GB and 8-GB RAM.
60+
- Azure IoT Operations and its dependencies consume on average 2,400-2,600 millicores.
61+
- 100% of the data is pushed to Event Hubs.
62+
- End-to-end data process latency is less than 10 seconds given ideal network conditions.
63+
64+
## Multi-node cluster
65+
66+
When Azure IoT Operations runs on a multi-node cluster, it can process more data and take advantage of the high-availability capabilities of Kubernetes. In this example, Azure IoT Operations is hosted on a 5-node cluster and processes approximately 50,000 data points per second from two different data sources.
67+
68+
### Configuration
69+
70+
Example hardware specifications:
71+
72+
- 5-node K3s with Azure VMs (Standard_D8d_v5 with Intel Xeon Platinum 8370C), 8 core (8 vCPU), 32-GB memory, 30 GB.
73+
- 5-node K3S with P3 Tiny Workstations (13th Generation Intel® Core™ i7-13700 vPro® Processor), 16 core (24 threads), 32-GB memory, 1-TB storage.
74+
75+
The following table shows the MQTT broker configuration for the multi-node example:
76+
77+
| Parameter | Value |
78+
|--------------------------|-------|
79+
| frontendReplicas | 5 |
80+
| frontendWorkers | 8 |
81+
| backendRedundancyFactor | 2 |
82+
| backendWorkers | 4 |
83+
| backendPartitions | 5 |
84+
| memoryProfile | High |
85+
86+
In this example, there are two types of data source. One connects through the OPC UA connector, and one connects through the MQTT broker.
87+
88+
In this example, an asset doesn't represent a real piece of equipment, but is a logical grouping that aggregates data points and sends messages.
89+
90+
The first end-to-end data flow in the example looks like this:
91+
92+
`Assets -> PLC -> OPC UA connector -> MQTT broker -> Dataflows -> Event Hubs`
93+
94+
The data volumes in the first data flow in the example are:
95+
96+
- 85 assets, aggregated by five OPC UA servers.
97+
- 85,000 tags based on 1,000 tags for each asset. Each tag updates 1/second and has an average size of 8 bytes. Approximately 50% of the tag values change each cycle. The data point update rate is 45,000/second.
98+
- The OPC UA connector sends 85 message/second to the MQTT broker.
99+
- One data flow pipeline pushes 85,000 tags to an Event Hubs endpoint.
100+
101+
The second end-to-end data flow in the example looks like this:
102+
103+
`MQTT client (Paho) -> MQTT Broker -> Dataflows -> Event Hubs`
104+
105+
The data volumes in the second data flow in the example are:
106+
107+
- Two MQTT clients connected directly to MQTT broker.
108+
- Each client publishes 10,000 values/second.
109+
- Approximately 1/3 of the tag values change each cycle.
110+
- Encoded with JSON format. Each item (value) with an approximate size of 180 bytes.
111+
112+
### Performance
113+
114+
Key performance metrics for this example include:
115+
116+
- Azure IoT Operations and its dependencies consume between 25 GB and 30 GB RAM.
117+
- Azure IoT Operations and its dependencies consume on average 2,500-3,000 millicores.
118+
- 100% of the data is pushed to Event Hubs.
119+
- End-to-end data process latency is less than 10 seconds given ideal network conditions.

‎articles/iot-operations/toc.yml

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -29,6 +29,8 @@ items:
2929
href: deploy-iot-ops/howto-enable-secure-settings.md
3030
- name: Production deployment guidelines
3131
href: deploy-iot-ops/concept-production-guidelines.md
32+
- name: Production deployment examples
33+
href: deploy-iot-ops/concept-production-examples.md
3234
- name: Secure your deployment
3335
items:
3436
- name: Certificate management

‎articles/migrate/common-questions-server-migration.md

Lines changed: 4 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -127,11 +127,14 @@ Migration and modernization tool migrates all the UEFI-based machines to Azure a
127127

128128
### Which operating systems are supported for migration of UEFI-based machines to Azure?
129129

130+
> [!Note]
131+
> If a major version of an operating system is supported in agentless migration, all minor versions and kernels are automatically supported.
132+
130133
| **Operating systems supported for UEFI-based machines** | **Agentless VMware to Azure** | **Agentless Hyper-V to Azure** | **Agent-based VMware, physical and other clouds to Azure** |
131134
| ------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------ | ---------------------------------------------------------- |
132135
| Windows Server 2019, 2016, 2012 R2, 2012 | Y | Y | Y |
133136
| Windows 10 Pro, Windows 10 Enterprise | Y | Y | Y |
134-
| SUSE Linux Enterprise Server 15 SP1 | Y | Y | Y |
137+
| SUSE Linux Enterprise Server 15 SP1, SP2, SP3, SP4, SP5, SP6 | Y | Y | Y |
135138
| SUSE Linux Enterprise Server 12 SP4 | Y | Y | Y |
136139
| Ubuntu Server 16.04, 18.04, 19.04, 19.10 | Y | Y | Y |
137140
| RHEL 9.x, 8.1, 8.0, 7.8, 7.7, 7.6, 7.5, 7.4, 7.0, 6.x | Y | Y | Y |

‎articles/migrate/vmware/migrate-support-matrix-vmware-migration.md

Lines changed: 5 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -58,11 +58,14 @@ The VMware vSphere hypervisor requirements are:
5858

5959
The table summarizes agentless migration requirements for VMware vSphere VMs.
6060

61+
> [!Note]
62+
> If a major version of an operating system is supported in agentless migration, all minor versions and kernels are automatically supported.
63+
6164
**Support** | **Details**
6265
--- | ---
6366
**Supported operating systems** | Windows Server 2003 and later versions. [Learn more](/troubleshoot/azure/virtual-machines/server-software-support). <br/><br/> You can migrate all the Linux operating systems supported by Azure listed [here](/troubleshoot/azure/cloud-services/support-linux-open-source-technology).
6467
**Windows VMs in Azure** | You might need to [make some changes](../prepare-for-migration.md#verify-required-changes-before-migrating) on VMs before migration.
65-
**Linux VMs in Azure** | Some VMs might require changes so that they can run in Azure.<br/><br/> For Linux, Azure Migrate makes the changes automatically for these operating systems:<br/> - Red Hat Enterprise Linux 9.x, 8.x, 7.9, 7.8, 7.7, 7.6, 7.5, 7.4, 7.3, 7.2, 7.1, 7.0, 6.x<br> - CentOS Stream</br> - SUSE Linux Enterprise Server 15 SP4, 15 SP3, 15 SP2, 15 SP1, 15 SP0, 12, 11 SP4, 11 SP3 <br>- Ubuntu 22.04, 21.04, 20.04, 19.04, 19.10, 18.04LTS, 16.04LTS, 14.04LTS<br> - Debian 11, 10, 9, 8, 7<br> - Oracle Linux 9, 8, 7.7-CI, 7.7, 6<br> - Kali Linux (2016, 2017, 2018, 2019, 2020, 2021, 2022) <br> For other operating systems, you make the [required changes](../prepare-for-migration.md#verify-required-changes-before-migrating) manually.<br/> The `SELinux Enforced` setting is currently not fully supported. It causes Dynamic IP setup and Microsoft Azure Linux Guest agent (waagent/WALinuxAgent) installation to fail. You can still migrate and use the VM. The `SELinux Permissive` setting is supported.
68+
**Linux VMs in Azure** | Some VMs might require changes so that they can run in Azure.<br/><br/> For Linux, Azure Migrate makes the changes automatically for these operating systems:<br/> - Red Hat Enterprise Linux 9.x, 8.x, 7.9, 7.8, 7.7, 7.6, 7.5, 7.4, 7.3, 7.2, 7.1, 7.0, 6.x<br> - CentOS Stream</br> - SUSE Linux Enterprise Server 15 SP6, 15 SP5, 15 SP4, 15 SP3, 15 SP2, 15 SP1, 15 SP0, 12, 11 SP4, 11 SP3 <br>- Ubuntu 22.04, 21.04, 20.04, 19.04, 19.10, 18.04LTS, 16.04LTS, 14.04LTS<br> - Debian 11, 10, 9, 8, 7<br> - Oracle Linux 9, 8, 7.7-CI, 7.7, 6<br> - Kali Linux (2016, 2017, 2018, 2019, 2020, 2021, 2022) <br> For other operating systems, you make the [required changes](../prepare-for-migration.md#verify-required-changes-before-migrating) manually.<br/> The `SELinux Enforced` setting is currently not fully supported. It causes Dynamic IP setup and Microsoft Azure Linux Guest agent (waagent/WALinuxAgent) installation to fail. You can still migrate and use the VM. The `SELinux Permissive` setting is supported.
6669
**Boot requirements** | **Windows VMs:**<br/>OS Drive (C:\\) and System Reserved Partition (EFI System Partition for UEFI VMs) should reside on the same disk.<br/>If `/boot` is on a dedicated partition, it should reside on the OS disk and not be spread across multiple disks. <br/> If `/boot` is part of the root (/) partition, then the '/' partition should be on the OS disk and not span other disks. <br/><br/> **Linux VMs:**<br/> If `/boot` is on a dedicated partition, it should reside on the OS disk and not be spread across multiple disks.<br/> If `/boot` is part of the root (/) partition, then the '/' partition should be on the OS disk and not span other disks.
6770
**UEFI boot** | UEFI-based virtual machines are migrated to Azure's Generation 2 VMs. However, it's important to note that Azure Generation 2 VMs lack the Secure Boot feature. For VMs that utilized Secure Boot in their original configuration, a conversion to Trusted Launch VMs is recommended after migration. This step ensures that Secure Boot, along with other enhanced security functionalities, is re-enabled.
6871
**Disk size** | Up to 2-TB OS disk for gen 1 VM and gen 2 VMs; 32 TB for data disks. Changing the size of the source disk after initiating replication is supported and won't impact ongoing replication cycle.
@@ -81,7 +84,7 @@ The table summarizes agentless migration requirements for VMware vSphere VMs.
8184
**IPv6** | Not supported.
8285
**Target disk** | VMs can be migrated only to managed disks (standard HDD, standard SSD, premium SSD) in Azure.
8386
**Simultaneous replication** | Up to 300 simultaneously replicating VMs per vCenter Server with one appliance. Up to 500 simultaneously replicating VMs per vCenter Server when an additional [scale-out appliance](../how-to-scale-out-for-migration.md) is deployed.
84-
**Automatic installation of Azure VM agent (Windows and Linux Agent)** | Windows: <br/>Supported for Windows Server 2008 R2 onwards. <br/><br/>Linux: <br/>- Red Hat Enterprise Linux 9.x, 8.x, 7.9, 7.8, 7.7, 7.6, 7.5, 7.4, 7.0, 6.x<br/>- CentOS Stream<br/>- SUSE Linux Enterprise Server 15 SP4, 15 SP3, 15 SP2, 15 SP1, 15 SP0, 12, 11 SP4, 11 SP3<br/>- Ubuntu 22.04, 21.04, 20.04, 19.04, 19.10, 18.04LTS, 16.04LTS, 14.04LTS<br/>- Debian 11, 10, 9, 8, 7<br/>- Oracle Linux 9, 8, 7.7-CI, 7.7, 6<br/>- Kali Linux (2016, 2017, 2018, 2019, 2020, 2021, 2022)<br/>
87+
**Automatic installation of Azure VM agent (Windows and Linux Agent)** | Windows: <br/>Supported for Windows Server 2008 R2 onwards. <br/><br/>Linux: <br/>- Red Hat Enterprise Linux 9.x, 8.x, 7.9, 7.8, 7.7, 7.6, 7.5, 7.4, 7.0, 6.x<br/>- CentOS Stream<br/>- SUSE Linux Enterprise Server 15 SP6, 15 SP5, 15 SP4, 15 SP3, 15 SP2, 15 SP1, 15 SP0, 12, 11 SP4, 11 SP3<br/>- Ubuntu 22.04, 21.04, 20.04, 19.04, 19.10, 18.04LTS, 16.04LTS, 14.04LTS<br/>- Debian 11, 10, 9, 8, 7<br/>- Oracle Linux 9, 8, 7.7-CI, 7.7, 6<br/>- Kali Linux (2016, 2017, 2018, 2019, 2020, 2021, 2022)<br/>
8588

8689
> [!NOTE]
8790
> Ensure that the following special characters are not passed in any credentials as they are not supported for SSO passwords:

‎articles/migrate/vmware/prepare-for-agentless-migration.md

Lines changed: 4 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -19,12 +19,15 @@ This article provides an overview of the changes performed when you [migrate VMw
1919
Before you migrate your on-premises VM to Azure, you may require a few changes to make the VM ready for Azure. These changes are important to ensure that the migrated VM can boot successfully in Azure and connectivity to the Azure VM can be established.
2020
Azure Migrate automatically handles these configuration changes for the following operating system versions for both Linux and Windows. This process is called *Hydration*.
2121

22+
> [!Note]
23+
> If a major version of an operating system is supported in agentless migration, all minor versions and kernels are automatically supported.
24+
2225
**Operating system versions supported for hydration**
2326

2427
- Windows Server 2008 or later
2528
- Red Hat Enterprise Linux 9.x, 8.x, 7.9, 7.8, 7.7, 7.6, 7.5, 7.4, 7.3, 7.2, 7.1, 7.0, 6.x
2629
- CentOS Stream
27-
- SUSE Linux Enterprise Server 15 SP4, 15 SP3, 15 SP2, 15 SP1, 15 SP0, 12, 11 SP4, 11 SP3
30+
- SUSE Linux Enterprise Server 15 SP6, 15 SP5, 15 SP4, 15 SP3, 15 SP2, 15 SP1, 15 SP0, 12, 11 SP4, 11 SP3
2831
- Ubuntu 22.04, 21.04, 20.04, 19.04, 19.10, 18.04LTS, 16.04LTS, 14.04LTS
2932
- Kali Linux (2016, 2017, 2018, 2019, 2020, 2021, 2022)
3033
- Debian 11, 10, 9, 8, 7

0 commit comments

Comments
 (0)