Azure 计划程序的高可用性和可靠性High availability and reliability for Azure Scheduler

重要

Azure 逻辑应用将替换即将停用的 Azure 计划程序。Azure Logic Apps is replacing Azure Scheduler, which is being retired. 若要继续使用在计划程序中设置的作业,请尽快迁移到 Azure 逻辑应用To continue working with the jobs that you set up in Scheduler, please migrate to Azure Logic Apps as soon as possible.

Azure 计划程序为作业提供了高可用性和可靠性。Azure Scheduler provides both high availability and reliability for your jobs. 有关详细信息,请参阅 SLA 计划程序For more information, see SLA for Scheduler.

高可用性High availability

Azure 计划程序[高度可用],并使用地域冗余服务部署和地理区域作业复制。Azure Scheduler is [highly available] and uses both geo-redundant service deployment and geo-regional job replication.

异地冗余的服务部署Geo-redundant service deployment

Azure 计划程序已在中国的两个区域推出:中国东部和中国北部。Azure Scheduler is available in two regions in China, China East and China North. 如果托管区域中的 Azure 数据中心变得不可用,仍可以使用 Azure 计划程序,因为该服务的故障转移功能使计划程序可在另一个数据中心提供。If an Azure datacenter in a hosted region becomes unavailable, you can still use Azure Scheduler because the service's failover capabilities make Scheduler available from another datacenter.

地理区域作业复制Geo-regional job replication

在 Azure 计划程序中,你自己的作业在 Azure 区域中复制。Your own jobs in Azure Scheduler are replicated across Azure regions. 因此如果一个中断,Azure 计划程序将进行故障转移,并确保配对地理区域中的另一个数据中心运行作业。So if one region has an outage, Azure Scheduler fails over and makes sure that your job runs from another datacenter in the paired geographic region.

例如,如果在“中国东部”创建了一个作业,Azure 计划程序会自动在“中国北部”复制该作业。For example, if you create a job in China East, Azure Scheduler automatically replicates that job in China North. 如果在“中国东部”发生故障,则 Azure 计划程序将在“中国北部”运行作业。If a failure happens in China East, Azure Scheduler runs the job in China North.

Azure 计划程序还可确保数据仍保留在同一个但更广泛的地理区域,以防 Azure 发生故障。Azure Scheduler also makes sure your data stays within the same but wider geographic region, just in case a failure happens in Azure. 因此,只需要高可用性时无需重复作业。So, you don't have to duplicate your jobs when you just want high availability. Azure 计划程序会自动为作业提供高可用性。Azure Scheduler automatically provides high-availability for your jobs.

可靠性Reliability

Azure 计划程序可保证其自身的高可用性,但提供不同的途径访问用户创建的作业。Azure Scheduler guarantees its own high-availability but takes a different approach to user-created jobs. 例如,假设你的作业调用不可用的 HTTP 终结点。For example, suppose your job invokes an HTTP endpoint that's unavailable. Azure 计划程序仍尝试通过为你提供处理故障的替代方法来成功运行作业:Azure Scheduler still tries to run your job successfully by giving you alternative ways for handling failures:

  • 设置重试策略。Set up retry policies.
  • 设置备用终结点。Set up alternate endpoints.

重试策略Retry policies

Azure 计划程序允许你设置重试策略。Azure Scheduler lets you set up retry policies. 如果作业失败,默认情况下,计划程序以 30 秒的间隔继续重试作业四次。If a job fails, then by default, Scheduler retries the job four more times at 30-second intervals. 可以放宽此重试策略,例如每 30 秒重试 10 次,或者提高限制,例如每日重试两次。You can make this retry policy more aggressive, such as 10 times at 30-second intervals, or less aggressive, such as two times at daily intervals.

例如,假设你创建了一个调用 HTTP 终结点的每周作业。For example, suppose you create a weekly job that calls an HTTP endpoint. 如果在作业运行时,HTTP 终结点变得不可用并持续几个小时,你可能不希望再等一个星期再次运行该作业,这是因为默认重试策略在此情况下不起作用。If the HTTP endpoint becomes unavailable for a few hours when your job runs, you might not want to wait another week for the job to run again, which happens because the default retry policy won't work in this case. 因此,你可能想要更改标准重试策略,以便进行重试,例如,每三个小时,而不是每 30 秒。So, you might want to change the standard retry policy so that retries happen, for example, every three hours, rather than every 30 seconds.

若要了解如何设置重试策略,请参阅 retryPolicyTo learn how to set up a retry policy, see retryPolicy.

备用终结点Alternate endpoints

如果 Azure 计划程序作业调用无法访问的终结点,即使已遵循重试策略,计划程序会回到可以处理此类错误的备用终结点。If your Azure Scheduler job calls an endpoint that is unreachable, even after following the retry policy, Scheduler falls back to an alternate endpoint that can handle such errors. 因此,如果设置此终结点,计划程序就会调用该终结点,这使得你自己的作业在发生故障时高度可用。So, if you set up this endpoint, Scheduler calls that endpoint, which makes your own jobs highly available when failures happen.

例如,下图显示了在调用纽约的 Web 服务时,计划程序如何遵循重试策略。For example, this diagram shows how Scheduler follows the retry policy when calling a web service in New York. 如果重试失败,计划程序将检查备用终结点。If the retries fail, Scheduler checks for an alternate endpoint. 如果终结点存在,计划程序就会开始向备用终结点发送请求。If the endpoint exists, Scheduler starts sending requests to the alternate endpoint. 相同的重试策略适用于原始操作和备用操作。The same retry policy applies to both the original action and the alternate action.

使用重试策略和备用终结点的计划程序行为

备用操作的操作类型可能不同于原始操作。The action type for the alternate action can differ from the original action. 例如,虽然原始操作调用 HTTP 终结点,但备用操作可以通过使用存储队列、服务总线队列或服务总线主题操作来记录错误。For example, although the original action calls an HTTP endpoint, the alternate action might log errors by using a Storage queue, Service Bus queue, or Service Bus topic action.

若要了解如何设置备用终结点,请参阅 errorActionTo learn how to set up an alternate endpoint, see errorAction.

另请参阅See also