Skip to content

Commit 8ba9792

Browse files
asudbringasudbring
committed
Merge branch 'main' of https://github.com/MicrosoftDocs/azure-docs-pr into pl-terraform-qs
2 parents 8e939bd + bcd339e commit 8ba9792

File tree

4 files changed

+62
-72
lines changed

4 files changed

+62
-72
lines changed

‎articles/azure-functions/durable/durable-functions-instance-management.md

Lines changed: 16 additions & 22 deletions
Original file line numberDiff line numberDiff line change
@@ -712,13 +712,11 @@ public static async Task Run(
712712
[DurableClient] IDurableOrchestrationClient client,
713713
[QueueTrigger("suspend-resume-queue")] string instanceId)
714714
{
715+
// To suspend an orchestration
715716
string suspendReason = "Need to pause workflow";
716717
await client.SuspendAsync(instanceId, suspendReason);
717718

718-
// Wait for 30 seconds to ensure that the orchestrator state is updated to suspended.
719-
DateTime dueTime = context.CurrentUtcDateTime.AddSeconds(30);
720-
await context.CreateTimer(dueTime, CancellationToken.None);
721-
719+
// To resume an orchestration
722720
string resumeReason = "Continue workflow";
723721
await client.ResumeAsync(instanceId, resumeReason);
724722
}
@@ -732,13 +730,11 @@ const df = require("durable-functions");
732730
module.exports = async function(context, instanceId) {
733731
const client = df.getClient(context);
734732

733+
// To suspend an orchestration
735734
const suspendReason = "Need to pause workflow";
736735
await client.suspend(instanceId, suspendReason);
737736

738-
// Wait for 30 seconds to ensure that the orchestrator state is updated to suspended.
739-
const deadline = DateTime.fromJSDate(context.df.currentUtcDateTime, {zone: 'utc'}).plus({ seconds: 30 });
740-
yield context.df.createTimer(deadline.toJSDate());
741-
737+
// To resume an orchestration
742738
const resumeReason = "Continue workflow";
743739
await client.resume(instanceId, resumeReason);
744740
};
@@ -754,13 +750,11 @@ from datetime import timedelta
754750
async def main(req: func.HttpRequest, starter: str, instance_id: str):
755751
client = df.DurableOrchestrationClient(starter)
756752

753+
# To suspend an orchestration
757754
suspend_reason = "Need to pause workflow"
758755
await client.suspend(instance_id, suspend_reason)
759756

760-
# Wait for 30 seconds to ensure that the orchestrator state is updated to suspended.
761-
due_time = context.current_utc_datetime + timedelta(seconds=30)
762-
yield context.create_timer(due_time)
763-
757+
# To resume an orchestration
764758
resume_reason = "Continue workflow"
765759
await client.resume(instance_id, resume_reason)
766760
```
@@ -770,20 +764,20 @@ async def main(req: func.HttpRequest, starter: str, instance_id: str):
770764
```powershell
771765
param($Request, $TriggerMetadata)
772766
773-
# Get instance id from body
774767
$InstanceId = $Request.Body.InstanceId
775-
$SuspendReason = 'Need to pause workflow'
776768
769+
# To suspend an orchestration
770+
$SuspendReason = 'Need to pause workflow'
777771
Suspend-DurableOrchestration -InstanceId $InstanceId -Reason $SuspendReason
778772
779-
# Wait for 30 seconds to ensure that the orchestrator state is updated to suspended.
780-
$duration = New-TimeSpan -Seconds 30
781-
Start-DurableTimer -Duration $duration
782-
773+
# To resume an orchestration
783774
$ResumeReason = 'Continue workflow'
784775
Resume-DurableOrchestration -InstanceId $InstanceId -Reason $ResumeReason
785776
```
786777

778+
> [!NOTE]
779+
> This change applies only to the standalone [Durable Functions PowerShell SDK](https://www.powershellgallery.com/packages/AzureFunctions.PowerShell.Durable.SDK), which is currently [in preview](durable-functions-powershell-v2-sdk-migration-guide.md).
780+
787781
# [Java](#tab/java)
788782

789783
```java
@@ -793,14 +787,14 @@ public void suspendResumeInstance(
793787
@DurableClientInput(name = "durableContext") DurableClientContext durableContext) {
794788
String instanceID = req.getBody();
795789
DurableTaskClient client = durableContext.getClient();
790+
791+
// To suspend an orchestration
796792
String suspendReason = "Need to pause workflow";
797793
client.suspendInstance(instanceID, suspendReason);
798794

799-
// Wait for 30 seconds to ensure that the orchestrator state is updated to suspended.
800-
ctx.createTimer(Duration.ofSeconds(30)).await();
801-
795+
// To resume an orchestration
802796
String resumeReason = "Continue workflow";
803-
client.getClient().resumeInstance(instanceID, resumeReason);
797+
client.resumeInstance(instanceID, resumeReason);
804798
}
805799
```
806800

‎articles/azure-monitor/includes/waf-logs-reliability.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -25,7 +25,7 @@ Some availability features require a dedicated cluster, which currently requires
2525

2626
| Recommendation | Benefit |
2727
|:---|:---|
28-
| If you collect enough data, create a dedicated cluster in a region that supports availability zones. | Workspaces linked to a [dedicated cluster](../logs/logs-dedicated-clusters.md) located in a region that supports [availability zones](../logs/availability-zones.md#data-resilience---supported-regions) remain available if a datacenter fails.<br><br> A dedicated cluster requires a commitment of at least 100 GB per day from all workspaces in the same region. If you don't collect this much data, then you need to weight the cost of this commitment with reliability features that it provides. |
28+
| If you collect enough data, create a dedicated cluster in a region that supports availability zones. | Workspaces linked to a [dedicated cluster](../logs/logs-dedicated-clusters.md) located in a region that supports [availability zones](../logs/availability-zones.md#supported-regions) remain available if a datacenter fails.<br><br> A dedicated cluster requires a commitment of at least 100 GB per day from all workspaces in the same region. If you don't collect this much data, then you need to weight the cost of this commitment with reliability features that it provides. |
2929
| If you require data in your workspace to be available in the event of a region failure, send critical data to multiple workspaces in different regions. | Send data to multiple workspaces in different regions. For example, configure DCRs to send data to multiple workspaces from Azure Monitor Agent running on virtual machines, and configure multiple diagnostic settings to collect resource logs from Azure resources to multiple workspaces. <br><br>Even though the data will be available in the alternate workspace in case of failure, resources that rely on the data, such as alerts and workbooks, won't know to use the alternate workspace. Consider storing ARM templates for critical resources with configuration for the alternate workspace in Azure DevOps or as disabled [policies](../../governance/policy/overview.md) that can quickly be enabled in a failover scenario.<br><br>Tradeoff: This configuration results in duplicate ingestion and retention charges so only use it for critical data. |
3030
| For mission-critical workloads requiring high availability, consider implementing a federated workspace model that uses multiple workspaces to provide high availability in the case of regional failure. | [Mission-critical](/azure/well-architected/mission-critical/mission-critical-overview) provides prescriptive best practice guidance for architecting highly reliable applications on Azure. The design methodology includes a federated workspace model with multiple Log Analytics workspaces to deliver [high availability](/azure/well-architected/mission-critical/mission-critical-design-methodology#select-a-reliability-tier) in the case of multiple failures, including the failure of an Azure region.<br><br> This strategy eliminates egress costs across regions and remains operational with a region failure, but it requires additional complexity that you must manage with configuration and processes described in [Health modeling and observability of mission-critical workloads on Azure](/azure/well-architected/mission-critical/mission-critical-health-modeling).|
3131
| If you require data to be protected in the case of datacenter or region failure, configure data export from the workspace to save data in an alternate location. | The [data export feature of Azure Monitor](../logs/logs-data-export.md) allows you to continuously export data sent to specific tables to Azure storage where it can be retained for extended periods. Use [Azure Storage redundancy options](../../storage/common/storage-redundancy.md#redundancy-in-a-secondary-region), including GRS and GZRS, to replicate this data to other regions. If you require export of [tables that aren't supported by data export](../logs/logs-data-export.md?tabs=portal#limitations), you can use other methods of exporting data, including Logic apps, to protect your data. This is primarily a solution to meet compliance for data retention since the data can be difficult to analyze and restore to the workspace.<br><br>This option is similar to the previous option of multicasting the data to different workspaces, but has a lower cost because the extra data is written to storage.<br><br> Data export is susceptible to regional incidents because it relies on the stability of the Azure Monitor ingestion pipeline in your region. It doesn't provide resiliency against incidents impacting the regional ingestion pipeline.|

‎articles/azure-monitor/logs/availability-zones.md

Lines changed: 44 additions & 48 deletions
Original file line numberDiff line numberDiff line change
@@ -12,70 +12,66 @@ ms.custom: references_regions
1212
---
1313
# Enhance data and service resilience in Azure Monitor Logs with availability zones
1414

15-
[Azure availability zones](../../reliability/availability-zones-overview.md) protect applications and data from datacenter failures and can enhance the resilience of Azure Monitor features that rely on a Log Analytics workspace. This article describes the data and service resilience benefits Azure Monitor availability zones provide by default to [dedicated clusters](logs-dedicated-clusters.md) in supported regions.
15+
[Azure availability zones](../../reliability/availability-zones-overview.md) protect applications and data from datacenter failures and can enhance the resilience of Azure Monitor features that rely on a Log Analytics workspace. This article describes the data and service resilience benefits Azure Monitor availability zones provide in supported regions.
16+
17+
> [!NOTE]
18+
> Application Insights resources can use availability zones only if they're workspace-based. Classic Application Insights resources can't use availability zones.
1619
1720
## Prerequisites
1821

19-
- A Log Analytics workspace linked to a [dedicated cluster](logs-dedicated-clusters.md).
22+
- A Log Analytics workspace linked to a shared or [dedicated cluster](logs-dedicated-clusters.md). Azure Monitor creates Log Analytics workspaces in a shared cluster, unless you set up a dedicated cluster for your workspaces.
23+
2024

21-
> [!NOTE]
22-
> Application Insights resources can use availability zones only if they're workspace-based and the workspace uses a dedicated cluster. Classic Application Insights resources can't use availability zones.
2325

2426
## How availability zones enhance data and service resilience in Azure Monitor Logs
2527

2628
Each Azure region that supports availability zones is made of one or more datacenters, or zones, equipped with independent power, cooling, and networking infrastructure.
2729

2830
Azure Monitor Logs availability zones are [zone-redundant](../../reliability/availability-zones-overview.md#zonal-and-zone-redundant-services), which means that Microsoft manages spreading service requests and replicating data across different zones in supported regions. If one zone is affected by an incident, Microsoft manages failover to a different availability zone in the region automatically. You don't need to take any action because switching between zones is seamless.
2931

30-
A subset of the availability zones that support data resilience currently also support service resilience for Azure Monitor Logs, as listed in the [Service resilience - supported regions](#service-resilience---supported-regions) section. In regions that support service resilience, Azure Monitor Logs service operations - for example, log ingestion, queries, and alerts - can continue in the event of a zone failure. In regions that only support data resilience, your stored data is protected against zonal failures, but service operations might be impacted by regional incidents.
31-
32-
## Data resilience - supported regions
33-
34-
Azure Monitor creates Log Analytics workspaces in a shared cluster, unless you [set up a dedicated cluster](../logs/logs-dedicated-clusters.md) for your workspaces.
35-
36-
### Shared clusters (default)
37-
All shared clusters in the following regions use availability zones. If your workspace is in one of these regions, Azure Monitor replicates your logs across the region-specific zones, as of January 2024.
38-
39-
| Americas | Europe | Middle East | Asia Pacific |
40-
| --- | --- | --- | --- |
41-
| Canada Central | France Central | UAE North | Australia East |
42-
| South Central US | North Europe | Israel Central | Central India |
43-
| West US 3 | Norway East | | Southeast Asia |
44-
| | UK South | | |
45-
| | Sweden Central | | |
46-
| | Italy North | | |
47-
48-
49-
### Dedicated clusters
50-
Azure Monitor currently supports data resilience for availability-zone-enabled dedicated clusters in these regions:
51-
52-
| Americas | Europe | Middle East | Africa | Asia Pacific |
53-
|---|---|---|---|---|
54-
| Brazil South | France Central | Qatar Central | South Africa North | Australia East |
55-
| Canada Central | Germany West Central | UAE North | | Central India |
56-
| Central US | North Europe | Israel Central | | Japan East |
57-
| East US | Norway East | | | Korea Central |
58-
| East US 2 | UK South | | | Southeast Asia |
59-
| South Central US | West Europe | | | East Asia |
60-
| West US 2 | Sweden Central | | | |
61-
| West US 3 | Switzerland North | | | |
62-
| | Poland Central | | | |
63-
| | Italy North | | | |
32+
A subset of the availability zones that support data resilience currently also support service resilience for Azure Monitor Logs. In regions that support **service resilience**, Azure Monitor Logs service operations - for example, log ingestion, queries, and alerts - can continue in the event of a zone failure. In regions that only support **data resilience**, your stored data is protected against zonal failures, but service operations might be impacted by regional incidents.
6433

6534
> [!NOTE]
6635
> Moving to a dedicated cluster in a region that supports availablility zones protects data ingested after the move, not historical data.
36+
37+
## Supported regions
6738

68-
## Service resilience - supported regions
69-
70-
When available in your region, Azure Monitor availability zones enhance your Azure Monitor service resilience automatically. Physical separation and independent infrastructure makes interruption of service availability in your Log Analytics workspace far less likely because the Log Analytics workspace can rely on resources from a different zone.
71-
72-
Azure Monitor currently supports service resilience for availability-zone-enabled dedicated clusters in these regions:
39+
| Region | Data resilience - Shared clusters (default) | Data resilience - Dedicated clusters | Service resilience |
40+
| --- | --- | --- | --- |
41+
| **Africa** | | | |
42+
| South Africa North | | :white_check_mark: | |
43+
| **Americas** | | | |
44+
| Brazil South | | :white_check_mark: | |
45+
| Canada Central | :white_check_mark: | :white_check_mark: | |
46+
| Central US | | :white_check_mark: | |
47+
| East US | | :white_check_mark: | |
48+
| East US 2 | | :white_check_mark: | :white_check_mark: |
49+
| South Central US | :white_check_mark: | :white_check_mark: | |
50+
| West US 2 | | :white_check_mark: | :white_check_mark: |
51+
| West US 3 | :white_check_mark: | :white_check_mark: | |
52+
| **Asia Pacific** | | | |
53+
| Australia East | :white_check_mark: | :white_check_mark: | |
54+
| Central India | :white_check_mark: | :white_check_mark: | |
55+
| East Asia | | :white_check_mark: | |
56+
| Japan East | | :white_check_mark: | |
57+
| Korea Central | | :white_check_mark: | |
58+
| Southeast Asia | :white_check_mark: | :white_check_mark: | |
59+
| **Europe** | | | |
60+
| France Central | :white_check_mark: | :white_check_mark: | |
61+
| Germany West Central | | :white_check_mark: | |
62+
| Italy North | :white_check_mark: | :white_check_mark: | :white_check_mark: |
63+
| North Europe | :white_check_mark: | :white_check_mark: | |
64+
| Norway East | :white_check_mark: | :white_check_mark: | |
65+
| Poland Central | | :white_check_mark: | |
66+
| Sweden Central | :white_check_mark: | :white_check_mark: | |
67+
| Switzerland North | | :white_check_mark: | |
68+
| UK South | :white_check_mark: | :white_check_mark: | |
69+
| West Europe | | :white_check_mark: | |
70+
| **Middle East** | | | |
71+
| Israel Central | :white_check_mark: | :white_check_mark: | :white_check_mark: |
72+
| Qatar Central | | :white_check_mark: | |
73+
| UAE North | :white_check_mark: | :white_check_mark: | |
7374

74-
- East US 2
75-
- West US 2
76-
- North Europe
77-
- Italy North
78-
- Israel Central
7975

8076
## Next steps
8177

‎articles/azure-monitor/logs/logs-dedicated-clusters.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -20,7 +20,7 @@ Capabilities that require dedicated clusters:
2020
- **[Cross-query optimization](../logs/cross-workspace-query.md)** - Cross-workspace queries run faster when workspaces are on the same cluster.
2121
- **Cost optimization** - Link your workspaces in same region to cluster to get commitment tier discount to all workspaces, even to ones with low ingestion that
2222
eligible for commitment tier discount.
23-
- **[Availability zones](../../availability-zones/az-overview.md)** - Protect your data from datacenter failures by relying on datacenters in different physical locations, equipped with independent power, cooling, and networking. The physical separation in zones and independent infrastructure makes an incident far less likely since the workspace can rely on the resources from any of the zones. [Azure Monitor availability zones](./availability-zones.md#service-resilience---supported-regions) covers broader parts of the service and when available in your region, extends your Azure Monitor resilience automatically. Azure Monitor creates dedicated clusters as availability-zone-enabled (`isAvailabilityZonesEnabled`: 'true') by default in supported regions. [Dedicated clusters Availability zones](./availability-zones.md#data-resilience---supported-regions) aren't supported in all regions currently.
23+
- **[Availability zones](../../availability-zones/az-overview.md)** - Protect your data from datacenter failures by relying on datacenters in different physical locations, equipped with independent power, cooling, and networking. The physical separation in zones and independent infrastructure makes an incident far less likely since the workspace can rely on the resources from any of the zones. [Azure Monitor availability zones](./availability-zones.md#supported-regions) covers broader parts of the service and when available in your region, extends your Azure Monitor resilience automatically. Azure Monitor creates dedicated clusters as availability-zone-enabled (`isAvailabilityZonesEnabled`: 'true') by default in supported regions. [Dedicated clusters Availability zones](./availability-zones.md#supported-regions) aren't supported in all regions currently.
2424
- **[Ingest from Azure Event Hubs](../logs/ingest-logs-event-hub.md)** - Lets you ingest data directly from an event hub into a Log Analytics workspace. Dedicated cluster lets you use capability when ingestion from all linked workspaces combined meet commitment tier.
2525

2626
## Cluster pricing model

0 commit comments

Comments
 (0)