Merge pull request #311112 from johndowns/reliability-service-bus

Service Bus - Integrate with Reliability Hub documentation

Author: JillGrant615

articles/service-bus-messaging/TOC.yml

@@ -156,6 +156,8 @@
         href: https://github.com/Azure-Samples/azure-messaging-replication-dotnet/tree/main/functions/config/ServiceBusCopyToEventHub
       - name: Acquire messages from Event Hubs
         href: https://github.com/Azure-Samples/azure-messaging-replication-dotnet/tree/main/functions/config/EventHubCopyToServiceBus
+  - name: Reliability
+    href: /azure/reliability/reliability-service-bus?toc=/azure/service-bus-messaging/TOC.json
   - name: Security
     items:
     - name: Security baseline

articles/service-bus-messaging/prepare-for-planned-maintenance.md

@@ -25,5 +25,6 @@ If your namespace is experiencing connection failures, check the [Resource Hea
 
 ## Next steps 
 
+- To learn about how to make Azure Service Bus resilient to a range of problems, see [Reliability in Azure Service Bus](/azure/reliability/reliability-service-bus?toc=/azure/service-bus-messaging/TOC.json).
 - For more information about retry logic, see [Retry logic for Azure services](/azure/architecture/best-practices/retry-service-specific). 
 - Learn more about handling transient faults in Azure at [Transient fault handling](/azure/architecture/best-practices/transient-faults). 

articles/service-bus-messaging/service-bus-async-messaging.md

@@ -22,7 +22,11 @@ In order to maintain availability of any of these entities, consider a number of
 
 For each of these failures, different failure modes exist that enable an application to continue to perform work at some level of reduced capability. For example, a system that can send messages but not receive them can still receive orders from customers but cannot process those orders. This topic discusses potential issues that can occur, and how those issues are mitigated. Service Bus has introduced a number of mitigations which you must opt into, and this topic also discusses the rules governing the use of those opt-in mitigations.
 
-## Reliability in Service Bus
+> [!NOTE]
+> To learn about how Service Bus is resilient to a range of problems, and the capabilities that you can use to increase its reliability, see [Reliability in Azure Service Bus](/azure/reliability/reliability-service-bus?toc=/azure/service-bus-messaging/TOC.json).
+
+## Failure mode types
+
 There are several ways to handle message and entity issues, and there are guidelines governing the appropriate use of those mitigations. To understand the guidelines, you must first understand what can fail in Service Bus. Due to the design of Azure systems, all of these issues tend to be short-lived. At a high level, the different causes of unavailability appear as follows:
 
 * Throttling from an external system on which Service Bus depends. Throttling occurs from interactions with storage and compute resources.
@@ -32,8 +36,6 @@ There are several ways to handle message and entity issues, and there are guidel
 
 > [!NOTE]
 > The term **storage** can mean both Azure Storage and SQL Azure.
-> 
-> 
 
 Service Bus contains a number of mitigations for these issues. The following sections discuss each issue and their respective mitigations.
 
@@ -50,10 +52,7 @@ Other components within Azure can occasionally have service issues. For example,
 ### Service Bus failure on a single subsystem
 With any application, circumstances can cause an internal component of Service Bus to become inconsistent. When Service Bus detects this, it collects data from the application to aid in diagnosing what happened. Once the data is collected, the application is restarted in an attempt to return it to a consistent state. This process happens fairly quickly, and results in an entity appearing to be unavailable for up to a few minutes, though typical down times are much shorter.
 
-In these cases, the client application generates a timeout exception or a messaging exception. Service Bus contains a mitigation for this issue in the form of automated client retry logic. Once the retry period is exhausted and the message is not delivered, you can explore using other mentioned in the article on [handling outages and disasters][handling outages and disasters].
+In these cases, the client application generates a timeout exception or a messaging exception. Service Bus contains a mitigation for this issue in the form of automated client retry logic. Once the retry period is exhausted and the message is not delivered, you can use [geo-replication](./service-bus-geo-replication.md), [geo-disaster recovery](./service-bus-geo-dr.md), or another approach to [switch to a different namespace](./service-bus-outages-disasters.md).
 
 ## Next steps
-Now that you've learned the basics of asynchronous messaging in Service Bus, read more details about [handling outages and disasters][handling outages and disasters].
-
-[Best practices for insulating applications against Service Bus outages and disasters]: service-bus-outages-disasters.md
-[handling outages and disasters]: service-bus-outages-disasters.md
+Now that you've learned the basics of asynchronous messaging in Service Bus, read more details about [Reliability in Azure Service Bus][/azure/reliability/reliability-service-bus?toc=/azure/service-bus-messaging/TOC.json].

articles/service-bus-messaging/service-bus-geo-dr.md

@@ -16,7 +16,7 @@ The Geo-Disaster Recovery feature ensures that the entire configuration of a nam
 
 ## Comparison with Geo-Replication
 
-Azure Service Bus offers two features for geographic resilience: Geo-Replication and [Geo-Disaster Recovery](service-bus-geo-dr.md). The key difference is that Geo-Replication replicates both metadata and data (messages, message states, property changes), while Geo-Disaster Recovery replicates metadata only. For most disaster recovery scenarios, Geo-Replication is the recommended choice. For a detailed comparison, see [High-level feature differences](service-bus-outages-disasters.md#high-level-feature-differences).
+Azure Service Bus offers two features for geographic resilience: Geo-Replication and [Geo-Disaster Recovery](service-bus-geo-dr.md). The key difference is that Geo-Replication replicates both metadata and data (messages, message states, property changes), while Geo-Disaster Recovery replicates metadata only. For most disaster recovery scenarios, Geo-Replication is the recommended choice. For a detailed comparison, see [Reliability in Azure Service Bus - Resilience to region-wide failures](/azure/reliability/reliability-service-bus?toc=/azure/service-bus-messaging/TOC.json#resilience-to-region-wide-failures).
 
 ## Important points to consider
 
@@ -124,7 +124,7 @@ Once the failover is initiated -
 1. Pull messages from the former primary namespace once it's available again. After that, use that namespace for regular messaging outside of your Geo-Disaster Recovery setup, or delete the old primary namespace.
 
 > [!NOTE]
-> Only fail forward semantics are supported. In this scenario, you fail over and then re-pair with a new namespace. Failing back is not supported; for example, like in a SQL cluster. 
+> Only *fail-forward* semantics are supported. When you initiate a failover with geo-disaster recovery, you can re-pair with a new namespace after failover completes. You can't fail back to the previous primary replica. These semantics might be different to other data stores you're used to, like Microsoft SQL Server clusters.
 
 You can automate failover either with monitoring systems, or with custom-built monitoring solutions. However, such automation takes extra planning and work, which is out of the scope of this article.
 

articles/service-bus-messaging/service-bus-geo-replication.md

@@ -38,7 +38,7 @@ This feature allows promoting any secondary region to primary, at any time. Prom
 
 ## Comparison with Geo-Disaster Recovery
 
-Azure Service Bus offers two features for geographic resilience: Geo-Replication and [Geo-Disaster Recovery](service-bus-geo-dr.md). The key difference is that Geo-Replication replicates both metadata and data (messages, message states, property changes), while Geo-Disaster Recovery replicates metadata only. For most disaster recovery scenarios, Geo-Replication is the recommended choice. For a detailed comparison, see [High-level feature differences](service-bus-outages-disasters.md#high-level-feature-differences).
+Azure Service Bus offers two features for geographic resilience: Geo-Replication and [Geo-Disaster Recovery](service-bus-geo-dr.md). The key difference is that Geo-Replication replicates both metadata and data (messages, message states, property changes), while Geo-Disaster Recovery replicates metadata only. For most disaster recovery scenarios, Geo-Replication is the recommended choice. For a detailed comparison, see [Reliability in Azure Service Bus - Resilience to region-wide failures](/azure/reliability/reliability-service-bus?toc=/azure/service-bus-messaging/TOC.json#resilience-to-region-wide-failures).
 
 ## Scenarios
 The Geo-Replication feature can be used to implement different scenarios, as described here. For guidance on when to trigger a promotion, see [Recommended scenarios to trigger promotion](#recommended-scenarios-to-trigger-promotion).

articles/service-bus-messaging/service-bus-migrate-standard-premium.md

@@ -216,4 +216,4 @@ However, if you can migrate during a planned maintenance/housekeeping window, an
 ## Next steps
 
 * Learn more about the [differences between standard and premium Messaging](./service-bus-premium-messaging.md).
-* Learn about the [High-Availability and Geo-Disaster recovery aspects for Service Bus premium](service-bus-outages-disasters.md#protection-against-outages-and-disasters).
+* Learn about the [high availability, geo-replication, and geo-disaster recovery aspects for Service Bus premium](/azure/reliability/reliability-service-bus?toc=/azure/service-bus-messaging/TOC.json).