微软云
「云计算」微软Azure虚拟机的SLA
对于在同一Azure区域中的两个或多个可用区中部署了两个或更多实例的所有虚拟机，我们保证至少有99.99％的时间将虚拟机连接到至少一个实例。
对于在同一可用性集中部署了两个或更多实例的所有虚拟机，我们保证至少有99.95％的时间将虚拟机连接到至少一个实例。
对于使用所有操作系统磁盘和数据磁盘的高级存储的任何单实例虚拟机，我们保证您的虚拟机连接性至少为99.9％。
介绍
此Microsoft Online Services服务级别协议（此“SLA”）是Microsoft批量许可协议（“协议”）的一部分。本SLA中使用但未定义的大写术语将具有协议中赋予它们的含义。此SLA适用于此处列出的Microsoft在线服务（“服务”或“服务”），但不适用于与服务一起提供或连接到服务的任何单独品牌服务，也不适用于属于任何服务的任何内部部署软件。服务。
如果我们未按照本SLA中的规定实现并维护每项服务的服务级别，那么您可能有资格获得部分月服务费用。在您的订阅的初始期限内，我们不会修改您的SLA条款;但是，如果您续订订阅，续订时当前的此SLA版本将在整个续订期限内适用。我们将至少提前90天通知此SLA的不利材料变更。
一般条款
定义
“适用的月度期限”是指对于所欠服务积分的日历月，您是服务订户的天数。
“适用的每月服务费”是指您为服务实际支付的总费用，适用于所欠服务积分的月份。
“停机时间”是针对以下服务特定条款中的每项服务定义的。
“错误代码”表示操作已失败，例如5xx范围内的HTTP状态代码。
“外部连接”是支持的协议（如HTTP和HTTPS）上的双向网络流量，可以从公共IP地址发送和接收。
“事件”是指（i）导致停机的任何单个事件或（ii）任何一组事件。
“管理门户”是指Microsoft提供的Web界面，客户可通过该界面管理服务。
“服务积分”是微软索赔批准后记入您的每月适用服务费的百分比。
“服务级别”是指Microsoft在提供服务时同意满足的本SLA中规定的性能指标。
“服务资源”表示可在服务中使用的单个资源。
“成功代码”表示操作已成功，例如2xx范围内的HTTP状态代码。
“支持窗口”是指支持服务功能或与单独产品或服务兼容的时间段。
条款
声明
为了让Microsoft考虑索赔，您必须向Microsoft Corporation的客户支持提交索赔，包括Microsoft验证索赔所需的所有信息，包括但不限于：（i）事件的详细说明; （ii）关于停机时间和持续时间的信息; （iii）受影响用户的数量和地点（如适用）; （iv）您在事件发生时尝试解决事件的说明。
对于与Microsoft Azure相关的声明，我们必须在作为声明主题的事件发生的结算月结束后的两个月内收到声明。对于与所有其他服务相关的索赔，我们必须在事件发生月份之后的日历月结束时收到索赔。例如，如果事件发生在2月15日，我们必须在3月31日之前收到索赔和所有必需的信息。
我们将评估我们合理可用的所有信息，并确定是否欠服务信用。我们将采取商业上合理的努力，在接下来的一个月内以及收到后的四十五（45）天内处理索赔。您必须遵守本协议才有资格获得服务积分。如果我们确定欠您的服务积分，我们会将服务积分应用于您的每月适用服务费。
如果您购买了多个服务（不是套件），那么您可以根据上述流程提交索赔，就好像每个服务都包含在单个SLA中一样。例如，如果您同时购买了Exchange Online和SharePoint Online（而不是套件的一部分），并且在订阅期间，事件导致两个服务的停机时间，则您可能有资格获得两个单独的服务信用（每个服务一个）服务），根据本SLA提交两项索赔。如果由于同一事件而未能满足特定服务的多个服务级别，则您必须仅选择一个服务级别，根据该事件进行索赔。除非特定SLA另有规定，否则每个服务仅允许在适用的月度期间使用一个服务积分。
服务积分
对于协议和本SLA下的任何服务的任何性能或可用性问题，服务积分是您唯一且唯一的补救措施。对于任何性能或可用性问题，您不得单方面抵消您的适用月服务费用。
服务积分仅适用于为未达到服务级别的特定服务，服务资源或服务层支付的费用。如果服务级别适用于单个服务资源或单独的服务层，则服务信用仅适用于为受影响的服务资源或服务层支付的费用（如果适用）。对于特定服务或服务资源，在任何结算月份中授予的服务积分在任何情况下都不会超过您在结算月份中针对该服务或服务资源的每月服务费（如适用）。
如果您购买服务作为套件或其他单一优惠的一部分，则每项服务的适用每月服务费和服务积分将按比例分配。
如果您从经销商处购买了服务，您将直接从经销商处获得服务积分，经销商将直接从我们处获得服务积分。服务信用将基于适用服务的估计零售价，由我们自行决定。
限制
此SLA和任何适用的服务级别不适用于任何性能或可用性问题：
由于我们无法合理控制的因素（例如，自然灾害，战争，恐怖主义行为，骚乱，政府行为，或我们数据中心外部的网络或设备故障，包括您的站点或您的站点与我们的数据中心之间） ;
这是因为使用了我们未提供的服务，硬件或软件，包括但不限于带宽不足或与第三方软件或服务相关的问题;
在我们建议您修改您对服务的使用后，如果您未按照建议修改您的使用，则由您使用服务引起;
在预览，预发布，测试版或试用版本的服务，功能或软件（由我们确定）或使用Microsoft订阅信用额进行购买期间或与之相关;
这是因为您未经授权的行动或在需要时没有采取任何行动，或来自您的员工，代理商，承包商或供应商，或通过您的密码或设备访问我们网络的任何人，或因您未能遵守适当的安全措施而导致的做法;
这是因为您未能遵守任何所需的配置，使用支持的平台，遵循任何可接受的使用策略，或以与服务的特性和功能不一致的方式使用服务（例如，尝试执行操作不支持）或与我们发布的指南不一致;
这是由错误的输入，指令或参数引起的（例如，访问不存在的文件的请求）;
这是因为您试图执行超过规定配额的操作或因我们对可疑的滥用行为进行限制而导致的操作;
由于您使用了相关支持Windows之外的服务功能;要么
对于事故发生时保留但未支付的许可证。
通过开放式，开放式价值和开放式价值订购批量许可协议购买的服务以及以产品密钥形式购买的Office 365小型企业高级套件中的服务不符合基于服务费的服务积分。对于这些服务，您可能有资格获得的任何服务积分将以服务时间（即天）的形式记入贷方，而不是服务费，任何对“适用的每月服务费”的引用都将被删除并替换为“适用”每月期。“
SLA细节
其他定义
“可用性集”是指跨不同故障域部署的两个或更多虚拟机，以避免单点故障。
“可用区”是Azure区域内的故障隔离区域，提供冗余电源，冷却和网络。
“数据磁盘”是一个永久虚拟硬盘，连接到虚拟机，用于存储应用程序数据。
“Fault Domain”是一组服务器，它们共享电源和网络连接等公共资源。
“操作系统磁盘”是一个永久虚拟硬盘，连接到虚拟机，用于存储虚拟机的操作系统。
“单实例”定义为任何单个Microsoft Azure虚拟机，它们未部署在可用性集中，或者只在可用性集中部署了一个实例。
“虚拟机”是指可以单独部署或作为可用性集的一部分部署的持久性实例类型。
“虚拟机连接”是使用TCP或UDP网络协议在虚拟机和其他IP地址之间的双向网络流量，其中虚拟机配置为允许的流量。 IP地址可以是与虚拟机相同的Cloud Service中的IP地址，与虚拟机在同一虚拟网络中的IP地址，也可以是公共的可路由IP地址。
可用区中虚拟机的每月正常运行时间计算和服务级别
“最大可用分钟数”是在一个结算月内，在同一地区的两个或多个可用区中部署了两个或更多实例的总累计分钟数。最大可用分钟数是从同一区域中两个可用区中的至少两个虚拟机同时启动的结果开始计算的，这些虚拟机是由客户发起的操作导致客户已启动将导致停止或删除虚拟机的操作的时间。
“停机时间”是在该区域中没有虚拟机连接的最大可用分钟数的总累计分钟数。
可用区中的虚拟机的“每月正常运行时间百分比”计算为最大可用分钟数减去停机时间除以给定Microsoft Azure订阅的结算月份中的最大可用分钟数。每月正常运行时间百分比由以下公式表示：
每月正常运行时间％=（最大可用分钟数 - 停机时间）/最大可用分钟数X 100
以下服务级别和服务信用适用于客户使用虚拟机，部署在同一地区的两个或多个可用区中：
每月最高百分比服务信贷
<99.99％10％
<99％25％
<95％100％
可用性集中虚拟机的每月正常运行时间计算和服务级别
“最大可用分钟数”是在同一可用性集中部署了两个或更多实例的所有虚拟机的计费月份内的总累计分钟数。最大可用分钟数是从同一可用性集中的至少两台虚拟机同时启动的结果开始计算的，这些虚拟机是由客户发起的操作导致客户发起导致停止或删除虚拟机的操作的时间。
“停机时间”是指没有虚拟机连接的最大可用分钟数的总累计分钟数。
虚拟机的“每月正常运行时间百分比”计算为最大可用分钟数减去停机时间除以给定Microsoft Azure订阅的结算月份中的最大可用分钟数。每月正常运行时间百分比由以下公式表示：
每月正常运行时间％=（最大可用分钟 - 停机时间）/最大可用分钟数X 100
以下服务级别和服务信用适用于客户在可用性集中使用虚拟机：
每月最高百分比服务信贷
<99.95％10％
<99％25％
<95％100％
单实例虚拟机的每月正常运行时间计算和服务级别
“月中的分钟数”是指给定月份的总分钟数。
“停机时间”是指本月内没有虚拟机连接的分钟的总累计分钟数。
“每月正常运行时间百分比”是按月中的分钟百分比计算的，其中任何使用高级存储的单实例虚拟机对所有操作系统磁盘和数据磁盘都具有停机时间。
每月正常运行时间％=（月份的分钟数 - 停机时间）/月份的分钟数X 100
以下服务级别和服务积分适用于客户使用单实例虚拟机：
每月最高百分比服务信贷
<99.9％10％
<99％25％
<95％100％
- 66 次浏览
「云计算架构:Dynamics」多租户 或多实例 ?
Dynamics 365（在线）为您提供了隔离Dynamics 365数据和用户访问权限的选项。 对于大多数公司而言，在订阅中添加和使用多个实例可提供正确的功能组合和易管理性。 具有不同地理位置的企业可能会考虑使用多个租户来分离Dynamics 365（在线）许可证。 多个实例可以在实例之间共享用户; 多个租户不能。
租户和实例的概念和操作虽然相似，但Dynamics 365的On-line和On-premis部署有所不同。这个主题是为那些管理Dynamics 365(在线)部署的人准备的.
术语
Tenant:
对于Dynamics 365(在线)，租户是您在Microsoft在线服务环境中注册一个Dynamics 365(在线)订阅时创建的帐户。租户包含唯一标识的域、用户、安全组和订阅，并且可以包含多个Dynamics 365(在线)实例。
为您创建的租户的域名为.onmicrosoft.com。例如,contoso.onmicrosoft.com。
Instance:
当您注册一个试用版或购买一个Dynamics 365(在线)订阅时，将创建一个Dynamics 365(在线)生产实例。您添加的每个额外的生产或非生产(沙箱)Dynamics 365(在线)实例都会在同一个租户上创建一个独立的Dynamics 365组织。
实例具有URL格式:https://.crm.dynamics.com。例如,https://contososales.crm.dynamics.com。
Multiregional instance:
与您的Dynamics 365(在线)租户所在的区域不同的实例。本地实例可以为该区域的用户提供更快的数据访问。更多信息:添加和编辑多区域实例
Subscription:
订阅由您在Dynamics 365(在线)账户中注册的试用或付费服务所包含的Dynamics 365许可证和附件组成。Dynamics 365订阅可能在许可类型、价格和终止日期方面有所不同。
例如，订阅一个可能是100个Dynamics 365(在线)专业许可证和10个Dynamics 365(在线)企业许可证。
Identity:
用户帐户曾经登录到Dynamics 365（在线）。您还可以使用此身份访问其他微软在线服务，如Office 365或SharePoint Online。管理员可以决定是否要在Dynamics 365(在线)和on-premises Active Directory之间联合用户标识管理。
User account:
由组织（工作，学校，非营利组织）分配给其成员（员工，学生，客户）的用户帐户，该帐户提供对组织的一个或多个Microsoft云服务订阅（如Exchange）的登录访问权限 在线或Dynamics 365（在线）。 对在线服务的访问权限由分配给用户帐户的许可证控制。
用户帐户存储在Azure Active Directory中组织的云目录中，通常在用户离开组织时删除。 组织帐户与Microsoft帐户的不同之处在于，它们由组织中的管理员创建和管理，而不是由用户创建和管理。
Security group:
如果您的公司有多个Dynamics 365(在线)实例，您可以使用实例安全组来控制哪些许可用户可以访问特定的实例。更多信息:控制用户对实例的访问:安全组和许可证.
使用多个实例
Dynamics 365(在线)实例在概念上类似于按照业务功能组织楼层的高层业务综合体。将建筑物内的每一层视为应用程序(销售/服务/营销、供应商管理、财富管理)，并将每一层中的每一个单元视为生产、培训、测试和开发等特定用途的实例。
当需要隔离插件、工作流或管理资源时，需要多个实例，这些资源不能通过在Dynamics 365中使用业务单元轻松隔离。
一个多实例部署
典型的Dynamics 365(在线)部署仅包含一个租户。租户可以包含一个或多个Dynamics 365(在线)实例;然而，Dynamics 365(在线)实例总是与单个租户关联。
这个示例为三个团队使用了两个实例:销售、营销和服务。
销售和营销共享一个实例，这样双方都可以很容易地访问Lead信息。服务有自己的实例，所以门票和保修可以与活动和其他与销售相关的活动分开管理。
您可以很容易地提供对一个或两个实例的访问。销售和营销用户可以局限于他们的实例，而具有扩展访问权限的服务用户可以更新与这两个实例中的帐户相关的支持升级记录。
关于具有多个实例的单个租户:
- 一个租户可以包含50个Dynamics 365(在线)生产实例和75个非生产(沙箱)实例。
- 租户中的每个实例都接收自己的SQL数据库。
- Dynamics 365数据不跨实例共享。
- 存储在主实例和任何其他实例之间共享。
- 单个客户租户的所有实例都将在最初为其帐户注册的地理位置中设置。对客户租户的所有实例进行汇总和跟踪存储消耗。
- 您可以为所有实例设置单独的安全组。
- 授权的Dynamics 365(在线)用户可以潜在地访问与租户关联的所有Dynamics 365(在线)实例。访问由实例安全组成员控制。
- 您可以通过附加实例附加组件购买其他实例。额外的实例只能添加到“付费”订阅中——而不是试验或内部使用权(IUR)。如果您通过批量许可购买了Dynamics 365(在线)订阅，那么您必须通过您的大型帐户经销商(LAR)购买额外的实例。更多信息:账单和订阅支持
- 您不能将现有的试验或订阅合并到其他实例中;相反，您将需要移动数据和定制。
为什么使用多个实例?
下面是多实例部署的常见用例。在确定最适合公司需求的部署类型时，请考虑这些示例。
主数据管理
在这个场景中，“主”数据集通过中央主数据源提供变更管理。这种方法要求中央主数据与所有实例同步，以便每个实例都能访问最新版本的核心信息。对信息的请求更改可以直接在主系统内进行。或者，用户可以显式地访问主系统或捕获本地实例中的更改，这些更改随后会传递给主实例。
要求集中进行更改可以提供集中更改控制。例如，可以执行反欺诈检查，以确保更改仅由中心团队进行，而不是由可能从更改(如更改信用限额)中获益的本地团队进行。这将提供第二个级别的更改授权和验证，从而避免单个人或一组密切合作的人员协作影响欺诈。将请求推给不同的、独立的团队可以防止潜在的欺诈。
安全性和隐私
区域的差异，例如欧洲联盟(欧盟)或国家立法的差异，可能导致在部署过程中不同区域或国家对保护数据或维护数据隐私的要求有所不同。在某些情况下，立法/监管限制使得在一个国家或地区之外存放数据是非法的，解决这一挑战在特定的商业部门尤为关键。
例如，考虑到医疗部门对共享病人信息的限制。欧盟的一些法规要求，所有收集到的关于居住在欧盟境内的人的健康信息只能在欧盟范围内进行维护和共享，而关于美国人的类似数据则被保存在美国范围内。还要考虑银行部门对共享客户信息的限制。例如，在瑞士，法律规定在国界之外共享客户信息是违法的。
可伸缩性
尽管Dynamics 365的一个实例可以扩展或扩展，以支持客户业务的增长，并且具有非常高的数据量或复杂度级别，但是还有其他考虑因素。例如，在具有极大容量和/或广泛使用服务调度的环境中，扩展SQL Server可能需要复杂而昂贵的基础设施，而这些基础设施的成本高得令人望而却步，或者难以管理。
在许多场景中，能力需求中存在自然的功能分离。在这种情况下，通过创建基于这些功能划分的扩展场景来委托工作负载可以通过使用商品基础设施来提供更高的容量。
多租户部署
具有不同区域或国家模型的全球企业可以使用租户来考虑方法，市场规模或遵守法律和监管限制的变化。
此示例包括Contoso Japan的第二个租户。
无法在租户之间共享用户帐户，身份，安全组，订阅，许可和存储。所有租户都可以拥有与每个特定租户相关联的多个实例。D365 数据不能跨实例或租户共享。
关于多个租户：
- 在多租户方案中，与租户关联的许可Dynamics 365（在线）用户只能访问映射到同一租户的一个或多个Dynamics 365（在线）实例。要访问其他租户，用户需要单独的许可证和该租户的一组唯一登录凭据。
- 例如，如果用户A具有访问租户A的帐户，则他们的许可允许他们访问在租户A中创建的任何和所有实例 - 如果他们的管理员允许的话。如果用户A需要访问租户B中的实例，他们将需要额外的Dynamics 365（在线）许可证。
- 每个租户都需要具有唯一登录凭据的租户管理员，并且每个租户关联企业将在管理员控制台中单独管理其租户。
- 如果管理员具有访问权限，则可以从Dynamics 365（在线）界面中看到租户中的多个实例。
- 您无法在租户注册之间重新分配许可。注册的会员可以在一次注册下使用许可证减少，并将许可证添加到另一个注册表以促进此操作。
- 除非您具有需要与不同租户联合的顶级域（例如Contoso.com和Fabricam.com），否则无法使用多个租户建立本地Active Directory联合。
为什么使用多个租户?
功能定位
- 这种场景通常出现在功能需求重叠但又独立的组织中。一些常见的例子包括:
- 具有不同业务部门的组织，每个部门都有不同的市场或经营模式。
- 具有区域或国家模式的全球业务，因方法、市场规模或遵守法律和监管限制的差异而有所不同。
- 在这些类型的业务环境中，组织通常具有公共的功能集，这些功能集允许特定的区域、国家或具有一定本地化程度的业务领域:
- 捕获的信息。例如，在美国捕获邮政编码将与在英国捕获邮政编码相关联。
- 表单,工作流。
物理分布
- 对于必须支持长距离物理分布的用户的业务解决方案，特别是对于全局部署，使用单个实例可能不适合，因为与用户连接的基础设施相关的影响(比如WAN延迟)可能会显著影响用户体验。分发实例以向用户提供更多本地访问可以减少或克服与wan相关的问题，因为访问发生在较短的网络连接上。
在批量许可下添加多租户部署
对于多租户部署，您需要一个多租户修正案。 多租户修正案是用于购买许可证的批量许可协议的实际修订。 请与您的Microsoft销售代表或经销商联系以获取修订。
多租户的约束
想要部署和管理多个租户的管理员应该了解以下内容:
- 用户帐户、身份、安全组、订阅、许可和存储不能在租户之间共享。
- 单个域只能与一个租户联合。
- 每个租户必须有自己的名称空间;UPN或SMTP名称空间不能在租户之间共享。
- 如果存在on-premises Exchange组织，则不能将该组织拆分为多个租户。
- 一个整合的全球地址列表将不可用，除非显式地同步到下游。
- 跨租户协作将仅限于Lync联合和Exchange联合功能。
- 跨租户访问SharePoint可能是不可能的。虽然这可以通过合作伙伴访问来解决，但是用户体验会受到干扰，并应用许可方面。
- 在on-premises Active Directory中，在租户或分区之间不能存在重复帐户。
- 14 次浏览
【Azure 云】虚拟网络服务端点
虚拟网络(VNet)服务端点通过直接连接将虚拟网络私有地址空间和VNet身份扩展到Azure服务。端点允许您将关键的Azure服务资源仅保护到您的虚拟网络。从VNet到Azure服务的流量始终保持在Microsoft Azure主干网上。
该特性可用于以下Azure服务和区域，您还可以找到Microsoft。*在为您的服务配置服务端点时需要从子网端启用的资源:
一般可用
- Azure Storage (Microsoft.Storage): Generally available in all Azure regions.
- Azure SQL Database (Microsoft.Sql): Generally available in all Azure regions.
- Azure SQL Data Warehouse (Microsoft.Sql): Generally available in all Azure regions.
- Azure Database for PostgreSQL server (Microsoft.Sql): Generally available in Azure regions where database service is available.
- Azure Database for MySQL server (Microsoft.Sql): Generally available in Azure regions where database service is available.
- Azure Database for MariaDB (Microsoft.Sql): Generally available in Azure regions where database service is available.
- Azure Cosmos DB (Microsoft.AzureCosmosDB): Generally available in all Azure regions.
- Azure Key Vault (Microsoft.KeyVault): Generally available in all Azure regions.
- Azure Service Bus (Microsoft.ServiceBus): Generally available in all Azure regions.
- Azure Event Hubs (Microsoft.EventHub): Generally available in all Azure regions.
- Azure Data Lake Store Gen 1 (Microsoft.AzureActiveDirectory): Generally available in all Azure regions where ADLS Gen1 is available.
- Azure App Service: Generally available in all Azure regions where App service is available
公共预览
- Azure容器注册表(Microsoft.ContainerRegistry):在Azure容器注册表可用的所有Azure区域中提供预览。
对于最新的通知，请查看Azure虚拟网络更新页面。
关键好处
服务端点提供以下好处:
- Azure服务资源的安全性改进:VNet私有地址空间可能会重叠，因此不能用于惟一地标识来自VNet的流量。通过将VNet标识扩展到服务，服务端点提供了将Azure服务资源保护到虚拟网络的能力。一旦在虚拟网络中启用了服务端点，就可以通过向资源中添加虚拟网络规则来保护Azure服务资源。通过完全取消对资源的公共Internet访问，只允许来自虚拟网络的流量，从而提高了安全性。
- 从您的虚拟网络对Azure服务流量进行最优路由:今天，虚拟网络中迫使Internet流量到您的场所和/或虚拟设备的任何路由(称为强制隧道)也会迫使Azure服务流量采取与Internet流量相同的路由。服务端点为Azure流量提供最佳路由。
- 端点总是将服务流量直接从您的虚拟网络带到Microsoft Azure主干网上的服务。在Azure主干网上保持流量允许您通过强制隧道继续审计和监视来自虚拟网络的出站Internet流量，而不会影响服务流量。了解有关用户定义路由和强制隧道的更多信息。
- 设置起来很简单，管理开销更少:您不再需要在虚拟网络中保留公共IP地址来通过IP防火墙保护Azure资源。不需要NAT或网关设备来设置服务端点。通过简单地单击子网来配置服务端点。维护端点没有额外的开销。
限制
- 该特性仅对通过Azure资源管理器部署模型部署的虚拟网络可用。
- 在Azure虚拟网络中配置的子网上启用了端点。端点不能用于从您的场所到Azure服务的流量。有关更多信息，请参见从本地保护Azure服务访问
- 对于Azure SQL，服务端点只适用于虚拟网络区域内的Azure服务流量。对于Azure存储，为了支持RA-GRS和GRS流量，端点还扩展到包含部署虚拟网络的成对区域。了解更多关于Azure配对区域…
- 对于ADLS Gen 1, VNet集成功能仅适用于同一区域内的虚拟网络。还请注意，用于Azure Data Lake Storage Gen1的虚拟网络集成利用虚拟网络服务端点安全性(virtual network service endpoint security)在您的虚拟网络和Azure Active Directory (Azure AD)之间生成额外的安全声明。然后使用这些声明来验证您的虚拟网络到您的数据湖存储Gen1帐户并允许访问。“微软。列出在服务支持服务端点下的AzureActiveDirectory标签仅用于支持ADLS第1代的服务端点。Azure Active Directory (Azure AD)本身并不支持服务端点。了解更多关于Azure数据湖存储Gen 1 VNet集成的信息。
保护Azure服务到虚拟网络
- 虚拟网络服务端点向Azure服务提供虚拟网络的标识。一旦在虚拟网络中启用了服务端点，就可以通过向资源中添加虚拟网络规则来保护Azure服务资源。
- 今天，来自虚拟网络的Azure服务流量使用公共IP地址作为源IP地址。对于服务端点，服务流量交换器在从虚拟网络访问Azure服务时使用虚拟网络专用地址作为源IP地址。此开关允许您访问服务，而不需要在IP防火墙中使用保留的公共IP地址。
请注意
对于服务端点，子网中虚拟机的源IP地址用于服务流量从使用公共IPv4地址切换到使用私有IPv4地址。使用Azure公共IP地址的现有Azure服务防火墙规则将停止使用这个开关。在设置服务端点之前，请确保Azure服务防火墙规则允许这种切换。在配置服务端点时，此子网的服务流量可能会暂时中断。
确保Azure服务从本地访问:
默认情况下，受虚拟网络保护的Azure服务资源不能从本地网络访问。如果你想要允许本地流量，你还必须允许公共(通常是NAT) IP地址从你的本地或ExpressRoute。这些IP地址可以通过Azure服务资源的IP防火墙配置来添加。
ExpressRoute:如果你从你的办公地点使用ExpressRoute，为了公用或微软对等，你需要识别使用的NAT IP地址。对于公用对等网络，当数据流进入微软Azure网络主干网时，每个ExpressRoute线路默认使用两个应用于Azure服务流量的NAT IP地址。对于Microsoft，使用的NAT IP地址要么是客户提供的，要么是由服务提供商提供的。要允许访问您的服务资源，您必须在资源IP防火墙设置中允许这些公共IP地址。要查找您的公共对等ExpressRoute线路的IP地址，请通过Azure门户与ExpressRoute一起打开一个支持票据。了解更多关于ExpressRoute公共和微软窥视NAT。
配置
- 服务端点是在虚拟网络中的子网上配置的。端点可以处理在子网中运行的任何类型的计算实例。
- 您可以在子网上为所有受支持的Azure服务(例如，Azure存储或Azure SQL数据库)配置多个服务端点。
- 对于Azure SQL数据库，虚拟网络必须与Azure服务资源位于同一区域。如果使用GRS和RA-GRS Azure存储帐户，主帐户必须与虚拟网络位于同一区域。对于所有其他服务，Azure服务资源可以被保护到任何区域的虚拟网络。
- 配置端点的虚拟网络可以与Azure服务资源处于相同或不同的订阅中。有关设置端点和保护Azure服务所需的权限的更多信息，请参见配置。
- 对于受支持的服务，可以使用服务端点将新资源或现有资源保护到虚拟网络。
注意事项
- 启用服务端点后，子网中虚拟机的源IP地址在与子网中的服务通信时，从使用公共IPv4地址切换到使用它们的私有IPv4地址。在此切换期间，到服务的任何现有的打开的TCP连接都将关闭。确保在为子网启用或禁用服务端点时不运行任何关键任务。另外，确保您的应用程序可以在IP地址切换后自动连接到Azure服务。
- IP地址交换只影响来自虚拟网络的服务流量。不会对分配给虚拟机的公共IPv4地址的任何其他流量产生影响。对于Azure服务，如果您有使用Azure公共IP地址的现有防火墙规则，那么这些规则将停止与切换到虚拟网络专用地址有关的工作。
- 对于服务端点，Azure服务的DNS条目保持原样，并继续解析分配给Azure服务的公共IP地址。
- 具有服务端点的网络安全组(NSGs):
- 默认情况下，NSGs允许出站Internet流量，因此，也允许从VNet到Azure服务的流量。对于服务端点，这将继续按原样工作。
- 如果您想要拒绝所有的出站Internet流量并只允许特定Azure服务的流量，那么您可以使用NSGs中的服务标记来做到这一点。您可以在NSG规则中指定受支持的Azure服务作为目标，并且Azure提供了对每个标记下的IP地址的维护。有关更多信息，请参见用于NSGs的Azure服务标记。
场景
- 查看、连接或多个虚拟网络:为了将Azure服务保护到虚拟网络内或跨多个虚拟网络中的多个子网，您可以独立地在每个子网上启用服务端点，并将Azure服务资源保护到所有子网。
- 过滤从虚拟网络到Azure服务的出站流量:如果希望检查或过滤从虚拟网络发送到Azure服务的流量，可以在虚拟网络中部署网络虚拟设备。然后，您可以将服务端点应用到部署网络虚拟设备的子网，并将Azure服务资源仅保护到这个子网。如果您希望使用网络虚拟设备过滤将Azure服务访问从您的虚拟网络限制到特定的Azure资源，那么这个场景可能会有所帮助。有关更多信息，请参见网络虚拟设备出口。
- 将Azure资源保护到直接部署到虚拟网络中的服务:各种Azure服务可以直接部署到虚拟网络中的特定子网中。通过在托管服务子网上设置服务端点，可以将Azure服务资源保护到托管服务子网。
- 来自Azure虚拟机的磁盘流量:对于托管/非托管磁盘，虚拟机磁盘流量(包括挂载和卸载、diskIO)不受Azure存储的服务端点路由更改的影响。您可以通过服务端点和Azure存储网络规则来限制REST对页面blob的访问来选择网络。
日志和故障排除
一旦将服务端点配置为特定的服务，通过以下步骤验证服务端点路由是否有效:
- 在服务诊断中验证任何服务请求的源IP地址。所有带有服务端点的新请求都将请求的源IP地址显示为虚拟网络私有IP地址，分配给从您的虚拟网络发出请求的客户机。如果没有端点，地址就是Azure公共IP地址。
- 查看子网中任何网络接口上的有效路由。服务路线:
- 显示更具体的默认路由，以地址每个服务的前缀范围
- 是否有下一个类型的VirtualNetworkServiceEndpoint
- 表示与任何强制的隧道路由相比，到服务的更直接的连接是有效的
请注意
服务端点路由覆盖Azure服务的地址前缀匹配的任何BGP或UDR路由。了解有关使用有效路径进行故障排除的更多信息
供应
对虚拟网络具有写访问权限的用户可以在虚拟网络上独立地配置服务端点。要将Azure服务资源保护到VNet，用户必须拥有Microsoft的权限。网络/虚拟网络/子网/joinViaServiceEndpoint/行动的子网正在添加。默认情况下，此权限包含在内置的服务管理员角色中，可以通过创建自定义角色进行修改。
了解有关内置角色的更多信息，并为自定义角色分配特定的权限。
虚拟网络和Azure服务资源可以在相同或不同的订阅中。如果虚拟网络和Azure服务资源处于不同的订阅中，那么这些资源必须位于相同的Active Directory (AD)租户下。
价格和限制
使用服务端点不需要额外的费用。Azure服务(Azure存储、Azure SQL数据库等)当前的定价模型与今天一样适用。
虚拟网络中的服务端点总数没有限制。
某些Azure服务，比如Azure存储帐户，可能会对用于保护资源的子网的数量施加限制。有关详细信息，请参阅后续步骤中的各种服务的文档。
虚拟网络服务端点策略
虚拟网络服务端点策略允许您过滤虚拟网络流量到Azure服务，只允许特定的Azure服务资源通过服务端点。服务端点策略为Azure服务的虚拟网络流量提供粒度访问控制。更多信息:虚拟网络服务端点策略
原文：https://docs.microsoft.com/en-us/azure/virtual-network/virtual-network-service-endpoints-overview
本文：https://pub.intelligentx.net/azure-virtual-network-service-endpoints
讨论：请加入知识星球【首席架构师圈】或者飞聊小组【首席架构师智库】
- 32 次浏览
【Azure云】Azure上对Azure虚拟机访问的多层保护
视频号
微信公众号
知识星球
解决方案思路
这篇文章是一个解决方案。如果您希望我们用更多信息来扩展内容，例如潜在的用例、替代服务、实施注意事项或
定价指导，请通过提供GitHub反馈让我们知道。此解决方案提供了一种多层方法来保护Azure中的虚拟机（VM）。出于管理和管理目的，用户需要连接到虚拟机。最大限度地减少连接造成的攻击面是至关重要的。
此解决方案通过结合多种保护机制实现了对虚拟机的非持久细粒度访问。它符合最低特权原则和职责分离的概念。为了减少受到攻击的风险，此解决方案锁定了虚拟机的入站流量，但在需要时可以访问虚拟机连接。实现这种类型的保护可以最大限度地降低对虚拟机的许多流行网络攻击的风险，如暴力攻击和分布式拒绝服务（DDoS）攻击。
此解决方案使用许多Azure服务和功能，包括：
- Microsoft Entra特权身份管理（PIM）。
- Microsoft Defender for Cloud的实时（JIT）虚拟机访问功能。
- Azure堡垒。
- Azure基于角色的访问控制（Azure RBAC）自定义角色。
- Microsoft Entra条件访问（可选）。
潜在用例
纵深防御是该体系结构背后的主要思想。在授予用户访问虚拟机的权限之前，此策略向用户提出了几道防线的挑战。目标是确保：
- 每个用户都是合法的。
- 每个用户都有合法的意图。
- 通信是安全的。
- 只有在需要时才提供对Azure中虚拟机的访问。
本文中的纵深防御策略和解决方案适用于许多场景：
在以下情况下，管理员需要访问Azure虚拟机：
- 管理员需要解决问题、调查行为或应用关键更新。
- 管理员使用远程桌面协议（RDP）访问Windows虚拟机，或使用安全外壳（SSH）访问Linux虚拟机。
- 访问权限应包括工作所需的最小权限数。
- 访问权限应仅在有限的时间内有效。
- 访问到期后，系统应锁定VM访问，以防止恶意访问尝试。
- 员工需要访问作为虚拟机托管在Azure中的远程工作站。以下条件适用：
- 员工只能在工作时间访问虚拟机。
- 安全系统应考虑在工作时间之外访问虚拟机的请求是不必要的和恶意的。
- 用户希望连接到Azure VM工作负载。系统应批准仅来自受管理和兼容设备的连接。
- 一个系统经历了大量的暴力攻击：
- 这些攻击的目标是RDP和SSH端口3389和22上的Azure虚拟机。
- 攻击试图猜测凭据。
- 该解决方案应防止3389和22等接入端口暴露在互联网或内部环境中。
架构
显示用户如何获得Azure VM的临时访问权限的体系结构图。
下载此体系结构的Visio文件。
数据流
身份验证和访问决策：根据Microsoft Entra ID对用户进行身份验证，以访问Azure门户、Azure REST API、Azure PowerShell或Azure CLI。如果身份验证成功，Microsoft Entra条件访问策略将生效。该策略验证用户是否符合某些条件。例如，使用托管设备或从已知位置登录。如果用户满足条件，条件访问将授予用户通过Azure门户或其他接口访问Azure的权限。- 基于身份的实时访问：在授权期间，Microsoft Entra PIM会为用户分配一个符合条件的自定义角色。资格仅限于所需资源，是一个有时限的角色，而不是一个永久的角色。在指定的时间范围内，用户通过Azure PIM接口请求激活此角色。该请求可以触发其他操作，例如启动审批工作流或提示用户进行多因素身份验证以验证身份。在审批工作流中，另一个人需要审批该请求。否则，用户将不会被分配自定义角色，并且无法继续执行下一步。
- 基于网络的实时访问：经过身份验证和授权后，自定义角色将临时链接到用户的身份。然后，用户请求JIT VM访问。该访问为RDP打开端口3389上的Azure Bastion子网连接，为SSH打开端口22上的连接。该连接直接运行到VM网络接口卡（NIC）或VM NIC子网。Azure Bastion通过使用该连接打开内部RDP会话。该会话仅限于Azure虚拟网络，并且不暴露于公共互联网。
- 连接到Azure虚拟机：用户通过使用临时令牌访问Azure堡垒。通过此服务，用户建立到Azure VM的间接RDP连接。连接只在有限的时间内有效。
组件
此解决方案使用以下组件：
- Azure虚拟机是一种基础设施即服务（IaaS）产品。您可以使用虚拟机来部署按需、可扩展的计算资源。在使用此解决方案的生产环境中，将工作负载部署在Azure虚拟机上。然后消除对虚拟机和Azure资产的不必要暴露。
- Microsoft Entra ID是一种基于云的身份服务，用于控制对Azure和其他云应用程序的访问。
- PIM是一种Microsoft Entra服务，用于管理、控制和监视对重要资源的访问。在此解决方案中，此服务：
- 限制管理员对标准和自定义特权角色的永久访问权限。
- 提供对自定义角色的基于身份的即时访问。
- JIT虚拟机访问是Defender for Cloud的一项功能，它提供对虚拟机的实时网络访问。此功能将拒绝规则添加到Azure网络安全组，该组保护VM网络接口或包含VM网络接口的子网。该规则通过阻止与虚拟机的不必要通信，最大限度地减少了虚拟机的攻击面。当用户请求访问VM时，该服务会向网络安全组添加临时允许规则。因为允许规则的优先级高于拒绝规则，所以用户可以连接到VM。Azure Bastion最适合连接到虚拟机。但是用户也可以使用直接的RDP或SSH会话。
- Azure RBAC是一种授权系统，提供对Azure资源的细粒度访问管理。
- Azure RBAC自定义角色提供了一种扩展Azure RBAC内置角色的方法。您可以使用它们在满足组织需求的级别上分配权限。这些角色支持PoLP。它们只授予用户为实现其目的所需的权限。要访问此解决方案中的VM，用户将获得以下权限：
- 使用Azure堡垒。
- 正在Defender for Cloud中请求JIT VM访问。
- 读取或列出虚拟机。
- Microsoft Entra条件访问是Microsoft Entra ID用于控制对资源的访问的工具。条件访问策略支持零信任安全模型。在此解决方案中，策略确保只有经过身份验证的用户才能访问Azure资源。
- Azure Bastion为网络中的虚拟机提供安全无缝的RDP和SSH连接。在此解决方案中，Azure Bastion连接使用Microsoft Edge或其他互联网浏览器进行HTTPS或端口443上的安全流量的用户。Azure Bastion设置到VM的RDP连接。RDP和SSH端口不会暴露于互联网或用户的来源。
- Azure堡垒在此解决方案中是可选的。用户可以使用RDP协议直接连接到Azure虚拟机。如果您在Azure虚拟网络中配置Azure Bastion，请设置一个名为AzureBastionSubnet的单独子网。然后将网络安全组与该子网相关联。在该组中，指定HTTPS流量的源，例如用户的本地IP无类域间路由（CIDR）块。通过使用此配置，可以阻止非来自用户本地环境的连接。
- 8 次浏览
【Azure云】Azure上的多区域N层应用程序
视频号
微信公众号
知识星球
此参考体系结构显示了一组行之有效的做法，用于在多个Azure区域中运行N层应用程序，以实现可用性和强健的灾难恢复基础架构。
架构
Azure N层应用程序的高可用网络架构”
Download a Visio file of this architecture.
流
初级和次级区域。使用两个区域以实现更高的可用性。一个是主要地区。另一个区域用于故障切换。
- Azure流量管理器。Traffic Manager将传入请求路由到其中一个区域。在正常操作期间，它将请求路由到主区域。如果该区域不可用，Traffic Manager将故障转移到辅助区域。有关更多信息，请参阅“流量管理器配置”一节。
- 资源组。为主要区域、次要区域和Traffic Manager创建单独的资源组。这种方法使您能够灵活地将每个区域作为一个资源集合进行管理。例如，您可以重新部署一个区域，而不删除另一个区域。链接资源组，以便运行查询以列出应用程序的所有资源。
- 虚拟网络。为每个区域创建一个单独的虚拟网络。确保地址空间不重叠。
- SQL Server始终可用组。如果您使用SQL Server，我们建议使用SQL始终开启可用性组以获得高可用性。创建一个可用性组，其中包括两个区域中的SQL Server实例。
笔记
还可以考虑Azure SQL数据库，它将关系数据库作为云服务提供。使用SQL数据库，您不需要配置可用性组或
管理故障切换。- 虚拟网络对等。对等两个虚拟网络以允许数据从主区域复制到辅助区域。有关详细信息，请参阅虚拟网络对等。
组件
- 【Availability sets 】可用性集确保您在Azure上部署的虚拟机分布在群集中的多个独立硬件节点上。如果Azure中发生硬件或软件故障，则只有您的虚拟机的一个子集受到影响，并且您的整个解决方案仍然可用且可操作。
- 【Availability zones】可用性区域可保护您的应用程序和数据免受数据中心故障的影响。可用性区域是Azure区域内的独立物理位置。每个区域由一个或多个配备独立电源、冷却和网络的数据中心组成。
- 【Azure Traffic Manager 】Azure流量管理器是一个基于DNS的流量负载均衡器，可优化分配流量。它提供跨全球Azure区域的服务，具有高可用性和响应能力。
- 【Azure Load Balancer 】Azure负载平衡器根据定义的规则和运行状况探测来分发入站流量。负载均衡器提供低延迟和高吞吐量，可为所有TCP和UDP应用程序扩展到数百万个流。在此场景中使用公共负载均衡器，将传入的客户端流量分配到web层。在此场景中使用内部负载均衡器，将流量从业务层分配到后端SQL Server集群。
- 【Azure Bastion 】Azure Bastion为其提供的虚拟网络中的所有虚拟机提供了安全的RDP和SSH连接。使用Azure Bastion保护您的虚拟机不向外部世界暴露RDP/SSH端口，同时仍然使用RDP/SSH提供安全访问。
建议
多区域体系结构可以提供比部署到单个区域更高的可用性。如果区域中断影响主区域，则可以使用Traffic Manager故障转移到辅助区域。如果应用程序的单个子系统出现故障，这种体系结构也会有所帮助。
实现跨区域高可用性有几种通用方法：
- 【Active/passive】主动/被动，带热备用。流量流向一个区域，而另一个区域则处于热备用状态。热备用意味着辅助区域中的虚拟机已分配并且始终在运行。
- 【Active/passive 】主动/被动，冷待机。流量流向一个区域，而另一个区域则处于冷备用状态。冷备用意味着在需要进行故障切换之前，不会分配辅助区域中的虚拟机。这种方法运行成本较低，但在出现故障时通常需要更长的时间才能联机。
- 【Active/active】主动/主动。这两个区域都是活动的，请求在它们之间是负载平衡的。如果某个区域不可用，则该区域将退出旋转。
此参考体系结构侧重于使用Traffic Manager进行故障切换的带热备用的主/被动体系结构。您可以部署一些虚拟机进行热备用，然后根据需要进行扩展。
区域配对
每个Azure区域都与同一地理区域内的另一个区域配对。通常，从同一区域对中选择区域（例如，美国东部2和美国中部）。这样做的好处包括：
- 如果出现大范围停电，则优先恢复每对中至少一个区域。
- 计划中的Azure系统更新按顺序推出到成对的区域，以最大限度地减少可能的停机时间。
- 成对驻留在同一地理位置，以满足数据驻留要求。
但是，请确保这两个地区都支持应用程序所需的所有Azure服务（请参阅按地区提供的服务）。有关区域配对的更多信息，请参阅业务连续性和灾难恢复（BCDR）：Azure配对区域。
Traffic Manager配置
配置Traffic Manager时，请考虑以下几点：
- 路由。Traffic Manager支持多种路由算法。对于本文中描述的场景，请使用优先级路由（以前称为故障转移路由）。使用此设置，Traffic Manager会将所有请求发送到主区域，除非主区域无法访问。此时，它会自动故障转移到次要区域。请参阅配置故障转移路由方法。
- 健康探头。Traffic Manager使用HTTP（或HTTPS）探测来监控每个区域的可用性。探测器检查指定URL路径的HTTP 200响应。作为最佳实践，创建一个报告应用程序总体运行状况的端点，并将此端点用于运行状况探测。否则，当应用程序的关键部分实际发生故障时，探测器可能会报告一个健康的端点。有关详细信息，请参阅运行状况端点监视模式。
当Traffic Manager发生故障转移时，客户端会有一段时间无法访问应用程序。持续时间受以下因素影响：
- 运行状况探测器必须检测到主区域已无法访问。
- DNS服务器必须更新IP地址的缓存DNS记录，这取决于DNS生存时间（TTL）。默认TTL为300秒（5分钟），但您可以在创建Traffic Manager配置文件时配置此值。
有关详细信息，请参阅关于流量管理器监控。
如果Traffic Manager发生故障切换，我们建议执行手动故障切换，而不是执行自动故障切换。否则，您可以创建应用程序在区域之间来回翻转的情况。请验证所有应用程序子系统是否正常，然后再进行故障恢复。
Traffic Manager默认情况下会自动故障恢复。若要防止此问题，请在发生故障切换事件后手动降低主区域的优先级。例如，假设主要区域为优先级1，次要区域为优先级2。故障切换后，将主区域设置为优先级3，以防止自动故障回复。当您准备切换回时，将优先级更新为1。
以下Azure CLI命令更新优先级：
Azure CLI
az network traffic-manager endpoint update --resource-group <resource-group>
--profile-name <profile>
--name <endpoint-name> --type azureEndpoints --priority 3
另一种方法是暂时禁用端点，直到您准备好进行故障恢复：
Azure CLI
az network traffic-manager endpoint update --resource-group <resource-group>
--profile-name <profile>
--name <endpoint-name> --type azureEndpoints --endpoint-status Disabled
根据故障切换的原因，您可能需要在区域内重新部署资源。在故障恢复之前，请执行操作准备测试。测试应验证以下内容：
- 虚拟机配置正确。（所有必需的软件都已安装，IIS正在运行，等等。）
- 应用程序子系统是健康的。
- 功能测试。（例如，可以从web层访问数据库层。）
配置SQL Server始终可用组
在Windows Server 2016之前，SQL Server始终开启可用性组需要域控制器，并且可用性组中的所有节点必须位于同一Active Directory（AD）域中。
要配置可用性组，请执行以下操作：
- 在每个区域中至少放置两个域控制器。
- 为每个域控制器提供一个静态IP地址。
- 对等两个虚拟网络以实现它们之间的通信。
- 对于每个虚拟网络，将域控制器（来自两个区域）的IP地址添加到DNS服务器列表中。您可以使用以下CLI命令。有关详细信息，请参阅更改DNS服务器。
Azure CLI
az network vnet update --resource-group <resource-group> --name <vnet-name>
--dns-servers "10.0.0.4,10.0.0.6,172.16.0.4,172.16.0.6"- 创建一个包含两个区域中的SQL Server实例的Windows Server故障转移群集（WSFC）群集。
- 创建一个SQL Server始终可用组，该组包括主区域和辅助区域中的SQL Server实例。有关步骤，请参阅将始终可用性组扩展到远程Azure数据中心（PowerShell）。
- 将主复制副本放在主区域中。
- 在主区域中放置一个或多个辅助复制副本。将这些复制副本配置为使用同步提交和自动故障切换。
- 将一个或多个辅助复制副本放在辅助区域中。出于性能原因，将这些复制副本配置为使用异步提交。（否则，所有T-SQL事务都必须等待通过网络到辅助区域的往返。）
笔记
异步提交复制副本不支持自动故障切换。
注意事项
这些注意事项实现了Azure架构良好的框架的支柱，这是一套可用于提高工作负载质量的指导原则。有关详细信息，请参阅Microsoft Azure架构良好的框架。
可利用性
使用复杂的N层应用程序，您可能不需要在辅助区域中复制整个应用程序。相反，您可以只复制支持业务连续性所需的关键子系统。
Traffic Manager可能是系统中的一个故障点。如果Traffic Manager服务失败，客户端将无法在停机期间访问您的应用程序。查看Traffic Manager SLA，并确定单独使用Traffic Manager是否满足高可用性的业务要求。如果没有，请考虑添加另一个流量管理解决方案作为故障回复。如果Azure流量管理器服务失败，请更改DNS中的CNAME记录以指向其他流量管理服务。（此步骤必须手动执行，在传播DNS更改之前，您的应用程序将不可用。）
对于SQL Server群集，有两种故障切换方案需要考虑：
- 主区域中的所有SQL Server数据库副本都会失败。例如，这种故障可能发生在区域停电期间。在这种情况下，即使Traffic Manager在前端自动进行故障切换，您也必须手动对可用性组进行故障切换。请按照“对SQL Server可用性组执行强制手动故障切换”中的步骤进行操作，该部分介绍了如何在SQL Server 2016中使用SQL Server Management Studio、Transact-SQL或PowerShell执行强制故障切换。
警告
通过强制故障切换，存在数据丢失的风险。一旦主区域恢复在线，请获取数据库的快照，并使用tablediff查找差异。- Traffic Manager故障转移到辅助区域，但主SQL Server数据库副本仍然可用。例如，前端层可能会出现故障，而不会影响SQL Server虚拟机。在这种情况下，Internet流量被路由到辅助区域，并且该区域仍然可以连接到主复制副本。但是，会增加延迟，因为SQL Server连接是跨区域的。在这种情况下，您应该执行手动故障切换，如下所示：
- 临时将辅助区域中的SQL Server数据库复制副本切换到同步提交。此步骤可确保在故障切换过程中不会丢失数据。
- 故障转移到该复制副本。
- 当故障返回到主区域时，恢复异步提交设置。
可管理性
更新部署时，一次更新一个区域，以减少因配置错误或应用程序中的错误而导致全局故障的几率。
测试系统对故障的恢复能力。以下是一些需要测试的常见故障场景：
- 关闭VM实例。
- 压力资源，如CPU和内存。
- 断开/延迟网络。
- 崩溃过程。
- 证书过期。
- 模拟硬件故障。
- 关闭域控制器上的DNS服务。
测量恢复时间并验证它们是否满足您的业务需求。测试故障模式的组合。
成本优化
成本优化是指寻找减少不必要费用和提高运营效率的方法。有关更多信息，请参阅成本优化支柱概述。
使用Azure定价计算器来估计成本。以下是一些其他考虑因素。
虚拟机规模集
虚拟机规模集可用于所有Windows虚拟机大小。您只需对部署的Azure虚拟机以及所消耗的任何添加的底层基础设施资源（如存储和网络）收费。虚拟机规模集服务不收取任何增量费用。
有关单个虚拟机定价选项，请参阅Windows虚拟机定价。
SQL服务器
如果您选择Azure SQL DBaas，您可以节省成本，因为不需要配置始终可用性组和域控制器计算机。有几个部署选项，从单个数据库到托管实例或弹性池。有关更多信息，请参阅Azure SQL定价。
有关SQL服务器虚拟机定价选项，请参阅SQL虚拟机定价。
负载平衡器
您只会根据配置的负载平衡和出站规则的数量收费。入站NAT规则是免费的。在未配置规则的情况下，标准负载平衡器不收取每小时费用。
Traffic Manager定价
Traffic Manager计费基于收到的DNS查询数量，每月收到超过10亿次查询的服务可享受折扣。您还将为每个受监控的端点收费。
有关更多信息，请参阅Microsoft Azure架构良好的框架中的成本部分。
VNET对等定价
使用多个Azure区域的高可用性部署将使用VNET对等。同一区域内的VNET对等和全局VNET对等的收费不同。
有关更多信息，请参阅虚拟网络定价。
DevOps
使用单个Azure资源管理器模板来配置Azure资源及其依赖项。使用相同的模板将资源部署到主区域和辅助区域。将所有资源包括在同一虚拟网络中，以便将它们隔离在同一基本工作负载中。通过包括所有资源，您可以更容易地将工作负载的特定资源与DevOps团队相关联，以便团队能够独立管理这些资源的各个方面。这种隔离使DevOps团队和服务能够执行持续集成和持续交付（CI/CD）。
此外，您可以使用不同的Azure资源管理器模板，并将它们与Azure DevOps Services集成，以在几分钟内提供不同的环境，例如，仅在需要时复制类似生产的场景或负载测试环境，从而节省成本。
考虑使用Azure Monitor来分析和优化基础设施的性能，在不登录虚拟机的情况下监测和诊断网络问题。Application Insights实际上是Azure Monitor的组件之一，它为您提供了丰富的指标和日志，以验证您完整的Azure环境的状态。Azure Monitor将帮助您跟踪基础设施的状态。
不仅要确保监控支持应用程序代码的计算元素，还要监控数据平台，尤其是数据库，因为应用程序数据层的低性能可能会产生严重后果。
为了测试运行应用程序的Azure环境，应该通过与应用程序代码相同的机制对其进行版本控制和部署，然后也可以使用DevOps测试范式对其进行测试和验证。
有关更多信息，请参阅Microsoft Azure架构良好的框架中的卓越运营部分。
Next steps
Related resources
The following architecture uses some of the same technologies:
- 5 次浏览
【Azure云】什么是Azure虚拟网络?
Azure虚拟网络(VNet)是Azure中私有网络的基本构件。VNet支持许多类型的Azure资源，比如Azure虚拟机(VM)，来安全地与internet和内部网络进行通信。VNet类似于您在自己的数据中心中操作的传统网络，但它也带来了Azure基础设施的额外好处，如可伸缩性、可用性和隔离性。
VNet 的概念
- Address space:在创建VNet时，必须使用公共和私有(RFC 1918)地址指定自定义私有IP地址空间。Azure从您分配的地址空间中为虚拟网络中的资源分配一个私有IP地址。例如，如果您在地址空间为10.0.0.0/16的VNet中部署VM，那么将为VM分配一个类似于10.0.0.4的私有IP。
- 子网:子网使您能够将虚拟网络分割成一个或多个子网，并为每个子网分配部分虚拟网络的地址空间。然后可以在特定的子网中部署Azure资源。与传统网络一样，子网允许您将VNet地址空间分割成适合组织内部网络的段。这也提高了地址分配效率。您可以使用网络安全组保护子网中的资源。有关更多信息，请参见安全组。
- 区域:VNet的作用域为单个区域/位置;然而，使用虚拟网络对等技术可以将来自不同区域的多个虚拟网络连接在一起。
- 订阅:VNet的作用域是订阅。您可以在每个Azure订阅和Azure区域内实现多个虚拟网络。
最佳实践
当你在Azure中构建你的网络时，记住以下通用的设计原则是很重要的:
- 确保地址空间不重叠。确保您的VNet地址空间(CIDR块)不与您组织的其他网络范围重叠。
- 您的子网不应该覆盖VNet的整个地址空间。提前计划，为将来预留一些地址空间。
- 建议您使用更少的大型vnet，而不是多个小型vnet。这将防止管理开销。
- 使用网络安全组(NSGs)保护您的VNet。
与互联网沟通
默认情况下，VNet中的所有资源都可以与internet进行出站通信。您可以通过分配公共IP地址或公共负载均衡器与资源进行入站通信。您还可以使用公共IP或公共负载均衡器来管理出站连接。要了解关于Azure中的出站连接的更多信息，请参见出站连接、公共IP地址和负载均衡器。
请注意
仅使用内部标准负载平衡器时，在定义希望出站连接如何使用实例级公共IP或公共负载平衡器之前，出站连接是不可用的。
Azure资源之间的通信
Azure资源之间的安全通信方式有以下几种:
- 通过虚拟网络(virtual network):您可以将vm和其他几种类型的Azure资源部署到虚拟网络中，比如Azure应用程序服务环境、Azure Kubernetes服务(AKS)和Azure虚拟机规模集。要查看可以部署到虚拟网络中的Azure资源的完整列表，请参阅虚拟网络服务集成。
- 通过虚拟网络服务端点(virtual network service endpoint:):通过直接连接将虚拟网络私有地址空间和虚拟网络的身份扩展到Azure服务资源，如Azure存储帐户和Azure SQL数据库。服务端点允许您将关键的Azure服务资源仅保护到一个虚拟网络。要了解更多信息，请参见虚拟网络服务端点概述。
- 通过VNet对等连接(VNet Peering):通过使用虚拟网络对等连接，您可以将虚拟网络连接到其他网络，从而使两个虚拟网络中的资源能够相互通信。您连接的虚拟网络可以位于相同的Azure区域，也可以位于不同的Azure区域。有关更多信息，请参见虚拟网络对等。
与on-premises资源沟通
你可以使用下列选项的任何组合，将你的本地电脑和网络连接至虚拟网络:
- 点到点虚拟专用网(VPN)(Point-to-site virtual private network (VPN)):在虚拟网络和网络中的一台计算机之间建立。希望与虚拟网络建立连接的每台计算机都必须配置其连接。如果您刚刚开始使用Azure，或者对于开发人员来说，这种连接类型非常好，因为它只需要对您现有的网络进行很少或根本不需要进行更改。您的计算机和虚拟网络之间的通信是通过internet上的加密隧道发送的。要了解更多信息，请参见点到点VPN。
- 站点到站点VPN(Site-to-site VPN):在您的本地VPN设备和部署在虚拟网络中的Azure VPN网关之间建立。此连接类型允许您授权访问虚拟网络的任何本地资源。您的本地VPN设备和Azure VPN网关之间的通信是通过internet上的加密隧道发送的。要了解更多信息，请参见站点到站点VPN。
- Azure ExpressRoute:通过一个ExpressRoute合作伙伴，在您的网络和Azure之间建立。这个连接是私有的。网络上没有流量。要了解更多，请参见高速公路。
过滤网络流量
您可以过滤网络之间的网络流量使用以下任一或两个选项:
- 安全组（Security groups）:网络安全组和应用程序安全组可以包含多个入站和出站安全规则，使您能够根据源和目标IP地址、端口和协议对进出资源的流量进行过滤。要了解更多信息，请参见网络安全组或应用程序安全组。
- 网络虚拟设备（Network virtual appliances）:网络虚拟设备是执行网络功能(如防火墙、WAN优化或其他网络功能)的VM。要查看可在虚拟网络中部署的可用网络虚拟设备列表，请参阅Azure Marketplace。
过滤网络流量
默认情况下，Azure路由子网、连接的虚拟网络、内部网络和Internet之间的通信。你可以实现以下选项中的一个或两个来覆盖Azure创建的默认路由:
- 路由表（Route tables）:您可以创建自定义路由表，其中路由控制每个子网的流量被路由到何处。了解更多关于路由表。
- 边界网关协议(BGP)路由（Border gateway protocol (BGP) routes）:如果您使用Azure VPN网关或ExpressRoute连接您的虚拟网络到您的本地网络，您可以将您的本地BGP路由传播到您的虚拟网络。了解更多关于使用Azure VPN网关和express路由的BGP。
Azure VNet限制
您可以部署的Azure资源的数量有一定的限制。大多数Azure网络限制都在最大值处。但是，您可以增加VNet限制（https://docs.microsoft.com/en-us/azure/azure-supportability/networking-…）页面中指定的某些网络限制（https://docs.microsoft.com/en-us/azure/azure-subscription-service-limit…）。
原文：https://docs.microsoft.com/en-us/azure/virtual-network/virtual-networks-overview
本文：https://pub.intelligentx.net/node/819
讨论：请加入知识星球【首席架构师圈】或者飞聊小组【首席架构师智库】
- 53 次浏览
【Azure云】什么是VPN网关?
VPN网关是一种特定类型的虚拟网关，用于在Azure虚拟网络和公共Internet上的本地位置之间发送加密的流量。您还可以使用VPN网关通过Microsoft网络在Azure虚拟网络之间发送加密的流量。每个虚拟网络只能有一个VPN网关。但是，您可以创建到同一VPN网关的多个连接。当您创建到同一VPN网关的多个连接时，所有VPN隧道都共享可用的网关带宽。
什么是虚拟网关?
虚拟网络网关由部署到称为网关子网的特定子网的两个或多个vm组成。虚拟网关vm包含路由表并运行特定的网关服务。这些vm是在您创建虚拟网络网关时创建的。您不能直接配置作为虚拟网络网关一部分的vm。
您为虚拟网络网关配置的一个设置是网关类型。网关类型指定如何使用虚拟网络网关以及网关采取的操作。网关类型“Vpn”指定创建的虚拟网关类型是“Vpn网关”，而不是“高速公路网关”。一个虚拟网络可以有两个虚拟网络网关;一个VPN网关和一个高速公路网关-这是与并存的连接配置的情况。有关更多信息，请参见网关类型。
VPN网关可以部署在Azure可用区域中。这为虚拟网络网关带来了弹性、可伸缩性和更高的可用性。在Azure可用性区域中部署网关在物理上和逻辑上分隔一个区域内的网关，同时保护您的本地网络连接到Azure，防止区域级故障。请参阅Azure可用性区域中的区域冗余虚拟网络网关
创建一个虚拟网关可能需要45分钟才能完成。当您创建虚拟网络网关时，网关vm将部署到网关子网，并使用您指定的设置进行配置。创建VPN网关后，可以在该VPN网关和另一个VPN网关(VNet-to-VNet)之间创建IPsec/IKE VPN隧道连接，或者在VPN网关和内部VPN设备(站点到站点)之间创建跨场所的IPsec/IKE VPN隧道连接。您还可以创建一个点到站点的VPN连接(通过OpenVPN、IKEv2或SSTP创建的VPN)，它允许您从远程位置(例如从会议或家里)连接到您的虚拟网络。
配置VPN网关
VPN网关连接依赖于使用特定设置配置的多个资源。大多数资源可以单独配置，但有些资源必须按一定的顺序配置。
设置
为每个资源选择的设置对于创建成功的连接至关重要。有关VPN网关的个人资源和设置的信息，请参阅VPN网关设置。本文包含帮助您理解网关类型、网关sku、VPN类型、连接类型、网关子网、本地网络网关和您可能需要考虑的各种其他资源设置的信息。
部署工具
您可以使用一个配置工具(如Azure门户)开始创建和配置资源。您可以稍后决定切换到另一个工具，例如PowerShell，以配置额外的资源，或者在适用时修改现有的资源。目前，您无法在Azure门户中配置所有资源和资源设置。文章中针对每个连接拓扑的说明指定了何时需要特定的配置工具。
部署模型
Azure目前有两种部署模型。配置VPN网关时，所采取的步骤取决于用于创建虚拟网络的部署模型。例如，如果您使用classic部署模型创建VNet，那么您可以使用classic部署模型的指导方针和说明来创建和配置您的VPN网关设置。有关部署模型的更多信息，请参见了解资源管理器和经典部署模型。
策划表
下表可以帮助您确定解决方案的最佳连接选项。
The following table can help you decide the best connectivity option for your solution.
| Point-to-Site | Site-to-Site | ExpressRoute | |
|---|---|---|---|
| Azure Supported Services | Cloud Services and Virtual Machines | Cloud Services and Virtual Machines | Services list |
| Typical Bandwidths | Based on the gateway SKU | Typically < 1 Gbps aggregate | 50 Mbps, 100 Mbps, 200 Mbps, 500 Mbps, 1 Gbps, 2 Gbps, 5 Gbps, 10 Gbps |
| Protocols Supported | Secure Sockets Tunneling Protocol (SSTP), OpenVPN and IPsec | IPsec | Direct connection over VLANs, NSP's VPN technologies (MPLS, VPLS,...) |
| Routing | RouteBased (dynamic) | We support PolicyBased (static routing) and RouteBased (dynamic routing VPN) | BGP |
| Connection resiliency | active-passive | active-passive or active-active | active-active |
| Typical use case | Prototyping, dev / test / lab scenarios for cloud services and virtual machines | Dev / test / lab scenarios and small scale production workloads for cloud services and virtual machines | Access to all Azure services (validated list), Enterprise-class and mission critical workloads, Backup, Big Data, Azure as a DR site |
| SLA | SLA | SLA | SLA |
| Pricing | Pricing | Pricing | Pricing |
| Technical Documentation | VPN Gateway Documentation | VPN Gateway Documentation | ExpressRoute Documentation |
| FAQ | VPN Gateway FAQ | VPN Gateway FAQ | ExpressRoute FAQ |
网关sku
创建虚拟网络网关时，指定要使用的网关SKU。根据工作负载、吞吐量、特性和sla的类型选择满足您需求的SKU。有关网关sku的更多信息，包括支持的特性、生产和开发测试以及配置步骤，请参阅VPN网关设置-网关SKUs文章。有关遗留SKU信息，请参见使用遗留SKU。
根据隧道、连接和吞吐量设置网关sku
Gateway SKUs by tunnel, connection, and throughput
| VPN Gateway Generation |
SKU | S2S/VNet-to-VNet Tunnels |
P2S SSTP Connections |
P2S IKEv2/OpenVPN Connections |
Aggregate Throughput Benchmark |
BGP | Zone-redundant |
|---|---|---|---|---|---|---|---|
| Generation1 | Basic | Max. 10 | Max. 128 | Not Supported | 100 Mbps | Not Supported | No |
| Generation1 | VpnGw1 | Max. 30* | Max. 128 | Max. 250 | 650 Mbps | Supported | No |
| Generation1 | VpnGw2 | Max. 30* | Max. 128 | Max. 500 | 1 Gbps | Supported | No |
| Generation1 | VpnGw3 | Max. 30* | Max. 128 | Max. 1000 | 1.25 Gbps | Supported | No |
| Generation1 | VpnGw1AZ | Max. 30* | Max. 128 | Max. 250 | 650 Mbps | Supported | Yes |
| Generation1 | VpnGw2AZ | Max. 30* | Max. 128 | Max. 500 | 1 Gbps | Supported | Yes |
| Generation1 | VpnGw3AZ | Max. 30* | Max. 128 | Max. 1000 | 1.25 Gbps | Supported | Yes |
| Generation2 | VpnGw2 | Max. 30* | Max. 128 | Max. 500 | 1.25 Gbps | Supported | No |
| Generation2 | VpnGw3 | Max. 30* | Max. 128 | Max. 1000 | 2.5 Gbps | Supported | No |
| Generation2 | VpnGw4 | Max. 30* | Max. 128 | Max. 1000 | 5 Gbps | Supported | No |
| Generation2 | VpnGw5 | Max. 30* | Max. 128 | Max. 1000 | 10 Gbps | Supported | No |
| Generation2 | VpnGw2AZ | Max. 30* | Max. 128 | Max. 500 | 1.25 Gbps | Supported | Yes |
| Generation2 | VpnGw3AZ | Max. 30* | Max. 128 | Max. 1000 | 2.5 Gbps | Supported | Yes |
| Generation2 | VpnGw4AZ | Max. 30* | Max. 128 | Max. 1000 | 5 Gbps | Supported | Yes |
| Generation2 | VpnGw5AZ | Max. 30* | Max. 128 | Max. 1000 | 10 Gbps | Supported | Yes |
(*)如你需要超过30个S2S VPN隧道，请使用虚拟广域网。
- 除了调整基本SKU的大小之外，VpnGw SKU的大小可以在同一代中调整。基本的SKU是一个遗留的SKU，具有特性限制。为了从Basic迁移到另一个VpnGw SKU，您必须删除基本的SKU VPN网关，并创建一个具有所需的生成和SKU大小组合的新网关。
- 这些连接限制是独立的。例如，在VpnGw1 SKU上可以有128个SSTP连接和250个IKEv2连接。
- 定价信息可以在定价页面找到。
- SLA(服务级别协议)信息可以在SLA页面找到。
- 在单个隧道中，可以实现最大1gbps的吞吐量。上表中的聚合吞吐量基准测试基于通过单个网关聚合的多个隧道的测量。VPN网关的总吞吐量基准是S2S + P2S组合。如果您有很多P2S连接，那么由于吞吐量限制，它可能会对S2S连接产生负面影响。由于Internet流量条件和应用程序行为，聚合吞吐量基准并不能保证吞吐量。
- 为了帮助我们的客户了解使用不同算法的sku的相对性能，我们使用公共可用的iPerf和CTSTraffic工具来测量性能。下表列出了第1代VpnGw sku的性能测试结果。如您所见，当我们使用GCMAES256算法进行IPsec加密和完整性时，获得了最佳的性能。当使用AES256进行IPsec加密，使用SHA256进行完整性加密时，我们获得了平均性能。当我们使用DES3的IPsec加密和SHA256的完整性，我们得到了最低的性能。
| Generation | SKU | Algorithms used |
Throughput observed |
Packets per second observed |
|---|---|---|---|---|
| Generation1 | VpnGw1 | GCMAES256 AES256 & SHA256 DES3 & SHA256 |
650 Mbps 500 Mbps 120 Mbps |
58,000 50,000 50,000 |
| Generation1 | VpnGw2 | GCMAES256 AES256 & SHA256 DES3 & SHA256 |
1 Gbps 500 Mbps 120 Mbps |
90,000 80,000 55,000 |
| Generation1 | VpnGw3 | GCMAES256 AES256 & SHA256 DES3 & SHA256 |
1.25 Gbps 550 Mbps 120 Mbps |
105,000 90,000 60,000 |
| Generation1 | VpnGw1AZ | GCMAES256 AES256 & SHA256 DES3 & SHA256 |
650 Mbps 500 Mbps 120 Mbps |
58,000 50,000 50,000 |
| Generation1 | VpnGw2AZ | GCMAES256 AES256 & SHA256 DES3 & SHA256 |
1 Gbps 500 Mbps 120 Mbps |
90,000 80,000 55,000 |
| Generation1 | VpnGw3AZ | GCMAES256 AES256 & SHA256 DES3 & SHA256 |
1.25 Gbps 550 Mbps 120 Mbps |
105,000 90,000 60,000 |
连接拓扑关系图
重要的是要知道有不同的配置可供VPN网关连接。您需要确定哪种配置最适合您的需要。在下面的章节中，您可以查看以下VPN网关连接的信息和拓扑图:
- 可用的部署模型
- 可用的配置工具
- 可以直接链接到文章的链接(如果有的话)
使用图表和描述来帮助选择符合您需求的连接拓扑。这些图显示了主要的基线拓扑，但是可以使用这些图作为指导原则来构建更复杂的配置。
站点到站点和多站点(IPsec/IKE VPN隧道)
站点到站点
站点到站点(S2S) VPN网关连接是通过IPsec/IKE (IKEv1或IKEv2) VPN隧道的连接。S2S连接可用于跨场所和混合配置。S2S连接需要一个位于本地的VPN设备，它有一个公共的IP地址，而不是位于NAT后面。
多站点
这种类型的连接是站点到站点连接的变体。您可以从虚拟网关创建多个VPN连接，通常连接到多个本地站点。当使用多个连接时，必须使用基于路由的VPN类型(在使用传统vnet时称为动态网关)。由于每个虚拟网络只能有一个VPN网关，所有通过该网关的连接都共享可用带宽。这种类型的连接通常称为“多站点”连接。
站点到站点和多站点的部署模型和方法
| Deployment model/method | Azure portal | PowerShell | Azure CLI |
|---|---|---|---|
| Resource Manager | Tutorial Tutorial+ |
Tutorial | Tutorial |
| Classic | Tutorial** | Tutorial+ | Not Supported |
- (**)表示该方法包含需要PowerShell的步骤。
- (+)表示本文是为多站点连接编写的。
Point-to-Site VPN
点到点(P2S) VPN网关连接允许您从单个客户机计算机创建到虚拟网络的安全连接。通过从客户端计算机启动P2S连接来建立它。这个解决方案对于想要从远程位置(比如在家里或会议上)连接到Azure vnet的远程工作者非常有用。当您只有几个客户机需要连接到VNet时，P2S VPN也是一个有用的解决方案，可以用来代替S2S VPN。
与S2S连接不同，P2S连接不需要本地面向公共的IP地址或VPN设备。只要两个连接的所有配置要求都是兼容的，就可以通过同一个VPN网关将P2S连接与S2S连接一起使用。有关点到点连接的更多信息，请参见点到点VPN。
P2S的部署模型和方法
Azure本地证书认证
| Deployment model/method | Azure portal | PowerShell |
|---|---|---|
| Resource Manager | Tutorial | Tutorial |
| Classic | Tutorial | Supported |
RADIUS authentication
| Deployment model/method | Azure portal | PowerShell |
|---|---|---|
| Resource Manager | Supported | Tutorial |
| Classic | Not Supported | Not Supported |
VNet-to-VNet连接(IPsec/IKE VPN隧道)
将虚拟网络连接到另一个虚拟网络(VNet-to-VNet)类似于将VNet连接到本地站点位置。这两种连接类型都使用VPN网关来提供使用IPsec/IKE的安全隧道。您甚至可以将vnet到vnet通信与多站点连接配置组合起来。这使您可以建立将跨前提连接与虚拟网络连接相结合的网络拓扑。
你连接的vnet可以是:
- 在相同或不同的地区
- 在相同或不同的订阅
- 在相同或不同的部署模型中
部署模型之间的连接
Azure目前有两种部署模型:classic和Resource Manager。如果您已经使用Azure一段时间了，那么您可能已经在经典的VNet中运行了Azure vm和实例角色。您的新vm和角色实例可能正在资源管理器中创建的VNet中运行。您可以在VNet之间创建连接，以允许一个VNet中的资源与另一个VNet中的资源直接通信。
VNet peering
只要您的虚拟网络满足某些要求，您就可以使用VNet对等连接来创建连接。VNet对等连接不使用虚拟网络网关。有关更多信息，请参见VNet对等连接。
vnet到vnet的部署模型和方法
| Deployment model/method | Azure portal | PowerShell | Azure CLI |
|---|---|---|---|
| Classic | Tutorial* | Supported | Not Supported |
| Resource Manager | Tutorial+ | Tutorial | Tutorial |
| Connections between different deployment models | Tutorial* | Tutorial | Not Supported |
(+)表示此部署方法仅对相同订阅中的vnet可用。
(*)表示此部署方法也需要PowerShell。
ExpressRoute(私有连接)
ExpressRoute允许您通过连接提供商提供的私有连接将您的本地网络扩展到Microsoft cloud。通过ExpressRoute，您可以建立与Microsoft云服务的连接，如Microsoft Azure、Office 365和CRM Online。连接可以是任意到任意(IP VPN)网络、点对点以太网，也可以是通过共存设施上的连接提供者进行的虚拟交叉连接。
高速公路的连接不经过公共互联网。这使得高速公路连接比典型的互联网连接更可靠、速度更快、延迟更短、安全性更高。
高速公路连接使用虚拟网络网关作为其所需配置的一部分。在高速公路连接中，虚拟网络网关配置为网关类型“高速公路”，而不是“Vpn”。虽然在高速公路线路上传输的流量在默认情况下是不加密的，但是可以创建一个允许您通过高速公路线路发送加密流量的解决方案。有关高速公路的更多信息，请参见高速公路技术概述。
站点到站点和ExpressRoute之间的连接是共存的
ExpressRoute是从您的WAN(不是通过公共Internet)到Microsoft服务(包括Azure)的直接、私有连接。站点到站点的VPN流量在公共互联网上加密传输。能够为同一个虚拟网络配置站点到站点的VPN和高速公路连接有几个优点。
您可以将站点到站点的VPN配置为ExpressRoute的安全故障转移路径，或者使用站点到站点的VPN连接到不属于您的网络的站点，但是通过ExpressRoute连接的站点。请注意，对于同一个虚拟网络，此配置需要两个虚拟网络网关，一个使用网关类型“Vpn”，另一个使用网关类型“ExpressRoute”。
S2S和ExpressRoute的部署模型和方法共存
| Deployment model/method | Azure portal | PowerShell |
|---|---|---|
| Resource Manager | Supported | Tutorial |
| Classic | Not Supported | Tutorial |
定价
您需要支付两项费用:虚拟网络网关的每小时计算成本，以及从虚拟网络网关传输出去的数据。定价信息可以在定价页面找到。有关遗留网关SKU定价，请参阅ExpressRoute定价页面并滚动到虚拟网络网关部分。
虚拟网关计算成本
每个虚拟网络网关都有每小时的计算成本。价格基于您在创建虚拟网络网关时指定的网关SKU。这是网关本身的成本，也是通过网关进行的数据传输之外的成本。主动-主动模式的成本与主动-被动模式相同。
数据传输成本
数据传输成本是根据源虚拟网关的出口流量计算的。
- 如果您将流量发送到您的本地VPN设备，它将收取互联网出口数据传输速率。
- 如果您在不同区域的虚拟网络之间发送流量，则定价将基于区域。
- 如果只在同一区域的虚拟网络之间发送流量，则不存在数据成本。同一区域内vnet之间的通信是免费的。
有关VPN网关网关sku的更多信息，请参见网关sku。
原文：https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-about-vpngateways
本文：https://pub.intelligentx.net/node/820
讨论：请加入知识星球【首席架构师圈】或者飞聊小组【首席架构师智库】
- 151 次浏览
【Azure云】使用Azure上的应用程序网关和API管理保护API
视频号
微信公众号
知识星球
随着越来越多的工作负载遵循API-first方法进行设计，以及互联网上对web应用程序的威胁数量和严重程度不断增加，制定保护API的安全策略至关重要。实现API安全的一个步骤是通过使用网关路由模式来保护网络流量。除了支持灵活的路由规则外，您还可以使用网关来限制流量源位置和流量质量。本文介绍了如何使用Azure应用网关和Azure API管理来保护API访问。
架构
本文不涉及应用程序的底层服务，如应用程序服务环境、Azure SQL托管实例和Azure Kubernetes服务。图中的这些部分只展示了作为更广泛的解决方案可以做些什么。本文特别讨论了阴影区域、API管理和应用程序网关。
显示应用程序网关和API管理如何保护API的图表。
Download a Visio file of this architecture.
数据流
- 应用程序网关接收其子网的网络安全组（NSG）允许的HTTP请求。
- 然后，应用程序网关上的Web应用程序防火墙（WAF）根据WAF规则（包括Geomatch筛选）检查请求。如果请求有效，则继续请求。
- 应用程序网关设置一个URL代理机制，将请求发送到适当的后端池。例如，根据API调用的URL格式：
- URL格式类似
api.<some-domain>/external/*可以到达后端与请求的API进行交互。 - 格式化为api的调用
api.<some-domain>/*进入死端（下沉池），这是一个没有目标的后端池。
- URL格式类似
- 此外，应用程序网关在api下接受和代理来自同一Azure虚拟网络中资源的内部调用<某些域>/internal/*。
- 最后，在API管理层，API被设置为接受以下模式下的调用：
api.<some-domain>/external/*api.<some-domain>/internal/*
在这种情况下，API管理使用两种类型的IP地址，公共和私有。公共IP地址用于端口3443上的内部通信，以及用于外部虚拟网络配置中的运行时API流量。当API管理将请求发送到公共的互联网交换后端时，它会显示一个公共IP地址作为请求的来源。有关更多信息，请参阅VNet中API管理服务的IP地址。
- 应用程序网关级别的路由规则正确地重定向门户下的用户<一些域>/*到开发人员门户，以便开发人员可以从内部和外部环境管理API及其配置。
组件
- Azure虚拟网络使许多类型的Azure资源能够通过互联网和本地网络进行私人通信。
- Azure应用程序网关是一个web流量负载均衡器，用于管理web应用程序的流量。这种类型的路由被称为应用层（OSI第7层）负载平衡。它承载一个Web应用程序防火墙（WAF），以防止常见的基于Web的攻击向量。
- Azure API管理是针对所有环境的API的混合、多云管理平台。API管理为现有后端服务创建一致的现代API网关。
建议
此解决方案的重点是实现整个解决方案，并测试从API管理虚拟网络内部和外部对API的访问。有关API管理虚拟网络集成过程的更多信息，请参阅将API管理与应用网关集成在内部VNET中。
要在后端与专用资源通信，应用程序网关和API管理必须与资源位于同一虚拟网络中，或者位于对等虚拟网络中。
- 私有的内部部署模型允许API管理连接到现有的虚拟网络，使其可以从该网络上下文内部访问。若要启用此功能，请部署开发人员或高级API管理层。
- 管理Azure密钥保管库中的证书和密码。
- 要个性化与服务的交互，可以使用CNAME条目。
选择
您可以使用其他服务提供类似级别的防火墙和Web应用程序防火墙（WAF）保护：
- Azure前门
- Azure防火墙
- 合作伙伴解决方案，如Barracuda
- Azure市场中提供的其他解决方案
注意事项
可靠性
Azure应用程序网关始终以高度可用的方式部署，无论实例数量如何。为了避免区域故障的影响，您可以将应用程序网关配置为跨多个可用区域。有关更多信息，请参阅自动缩放和高可用性。
为API管理服务组件启用区域冗余，以提供弹性和高可用性。区域冗余在物理上分离的区域中跨数据中心复制API管理网关和控制平面，使其对区域故障具有弹性。API管理高级层需要支持可用性区域。
API管理还支持多区域部署，这可以在一个区域离线时提高可用性。有关详细信息，请参见多区域部署。在这种拓扑结构中，每个区域也有一个应用程序网关很重要，因为应用程序网关是一个区域服务。
安全
有关应用程序网关安全性的更多信息，请参阅应用程序网关的Azure安全基线。
有关API管理安全性的更多信息，请参阅API管理的Azure安全基线。
Azure DDoS防护与应用程序设计最佳实践相结合，提供了增强的DDoS缓解功能，以提供更多抵御DDoS攻击的防御。您应该在任何外围虚拟网络上启用Azure DDOS保护。
成本优化
此体系结构的成本取决于配置方面，如：
- 服务层
- 可扩展性，即服务为支持给定需求而动态分配的实例数量
- 此体系结构是连续运行还是每月仅运行几个小时
评估完这些方面后，请转到Azure定价计算器来估计定价。
性能效率
应用程序网关是该体系结构的入口，WAF功能需要为每个请求分析提供额外的处理能力。为了允许应用程序网关在现场扩展其计算能力，启用自动缩放非常重要。有关详细信息，请参见指定自动缩放。按照产品文档中的建议确定应用程序网关的子网大小。这样可以确保子网足够大，以支持完全扩展。
若要支持高度并发的场景，请启用API管理自动缩放。自动缩放扩展了API管理功能，以应对不断增长的传入请求。有关详细信息，请参阅自动缩放Azure API管理实例。
部署此场景
此场景在具有内部API管理和Web应用程序的应用程序网关的Azure Quickstart库发布中演示。
Next steps
Design your APIs following good Web API design guidelines and implement them using good Web API implementation practices.
Related resources
- 6 次浏览
【Azure云】服务端点（Service Endpoint）和私有链接(Private Link)有什么区别?
很长一段时间以来，如果您在许多Azure服务上使用多租户、PaaS版本，那么您必须通过internet访问它们，并且无法限制对您的资源的访问。这种限制主要是由于对多租户服务进行这种限制的复杂性。目前，获得这种限制的唯一方法是考虑使用单租户解决方案，如应用服务环境（ASE)或在VM中自己运行服务，而不是使用PaaS。
这种公共访问是许多人关心的问题，因此微软实现了允许您限制对这些多租户服务的访问的新服务。今天，我们有两个表面上看起来非常相似的解决方案:服务端点和私有链接。这两个服务的设计都允许您限制谁连接到您的服务以及如何连接。因此，要知道应该使用哪种服务以及它的好处是什么可能会让人感到困惑。在本文中，我们将研究这些服务，并尝试使决策更加清晰。
注意，在本文中，我们只讨论公开多租户PaaS服务的方法，而没有讨论“私有链接服务”( “Private Link Service”)，它允许服务提供者通过私有链接向客户端公开服务。
服务端点(Service EndPoint)
服务端点是引入的第一个允许锁定多租户服务的服务。服务端点允许您将对PaaS资源的访问限制为来自Azure虚拟网络的流量。对于服务端点，PaaS服务仍然独立于您的vNet，流量离开虚拟网络来访问PaaS服务。然而，PaaS服务被配置为能够识别来自虚拟网络的流量并允许这样做，而不需要配置vNet上的公共IP来允许过滤。
服务端点通过启用虚拟网络上的子网来支持服务端点来工作。完成此操作后，可以将PaaS资源配置为只接受来自这些子网的流量。没有要求做任何IP过滤或NAT转换;告诉PaaS资源从哪个vNet和子网允许流量。当服务端点被启用时，PaaS资源将看到来自vNets私有IP的流量，而不是它的公共IP。
使用服务端点的另一个优势是流量被最优地路由到Azure资源。即使您的vNet上有UDRs来将internet流量路由回本地或通过防火墙设备，使用服务端点也意味着流量被直接发送到Azure资源。
Generally available
- Azure Storage (Microsoft.Storage): Generally available in all Azure regions.
- Azure SQL Database (Microsoft.Sql): Generally available in all Azure regions.
- Azure Synapse Analytics (Microsoft.Sql): Generally available in all Azure regions.
- Azure Database for PostgreSQL server (Microsoft.Sql): Generally available in Azure regions where database service is available.
- Azure Database for MySQL server (Microsoft.Sql): Generally available in Azure regions where database service is available.
- Azure Database for MariaDB (Microsoft.Sql): Generally available in Azure regions where database service is available.
- Azure Cosmos DB (Microsoft.AzureCosmosDB): Generally available in all Azure regions.
- Azure Key Vault (Microsoft.KeyVault): Generally available in all Azure regions.
- Azure Service Bus (Microsoft.ServiceBus): Generally available in all Azure regions.
- Azure Event Hubs (Microsoft.EventHub): Generally available in all Azure regions.
- Azure Data Lake Store Gen 1 (Microsoft.AzureActiveDirectory): Generally available in all Azure regions where ADLS Gen1 is available.
- Azure App Service (Microsoft.Web): Generally available in all Azure regions where App service is available.
- Azure Cognitive Services (Microsoft.CognitiveServices): Generally available in all Azure regions where Cognitive services are available.
Public Preview
- Azure Container Registry (Microsoft.ContainerRegistry): Preview available in limited Azure regions where Azure Container Registry is available.
For the most up-to-date notifications, check the Azure Virtual Network updates page.
服务端点确实有一些限制或缺点。
- 首先，关键是要记住，到服务端点的流量仍然在离开虚拟网络，Azure PaaS资源仍然在其公共地址上被访问。
- 通过VPN或Express路由在本地发起的流量不能使用服务端点，只能用于来自Azure虚拟网络的流量。
- 如果您希望允许您的本地资源访问，您还需要将它们的公共IP列入白名单。
更多信息:https://docs.microsoft.com/en-us/azure/virtual-network/virtual-network-…。
私人连接(Private Link)
私有链接是比服务端点更新的解决方案，大约在一年前引入。私有链接和服务端点之间的关键区别在于，使用私有链接，您将多租户PaaS资源注入虚拟网络。与服务端点，流量仍然离开你的vNet和击中PaaS资源的公共端点，与私有链接的PaaS资源坐在你的vNet和得到你的vNet上的私有IP。当您向PaaS资源发送流量时，它并不离开虚拟网络。
与Private Link的另一个关键区别是，当启用时，您将授予对虚拟网络中特定PaaS资源的访问权。这意味着您可以控制到PaaS资源的出口。例如，如果您愿意，您可以使用NSG来阻止对所有Azure SQL数据库的访问，然后使用Private Link来只授予对您特定的Azure SQL服务器的访问权。
与服务端点不同，私有链接允许通过VPN或高速路由从您的本地网络上的资源访问，以及从窥视网络访问。您还可以连接到跨地区的资源。
可用性
The following table lists the Private Link services and the regions where they're available.
| Supported services | Available regions | Additional considerations | Status | |
|---|---|---|---|---|
| Private Link services behind standard Azure Load Balancer | All public regions All Government regions All China regions |
Supported on Standard Load Balancer | GA Learn how to create a private link service. |
|
| Azure Blob storage (including Data Lake Storage Gen2) | All public regions All Government regions |
Supported on Account Kind General Purpose V2 | GA Learn how to create a private endpoint for blob storage. |
|
| Azure Files | All public regions All Government regions |
GA Learn how to create Azure Files network endpoints. |
||
| Azure File Sync | All public regions | GA Learn how to create Azure Files network endpoints. |
||
| Azure Queue storage | All public regions All Government regions |
Supported on Account Kind General Purpose V2 | GA Learn how to create a private endpoint for queue storage. |
|
| Azure Table storage | All public regions All Government regions |
Supported on Account Kind General Purpose V2 | GA Learn how to create a private endpoint for table storage. |
|
| Azure SQL Database | All public regions All Government regions All China regions |
Supported for Proxy connection policy | GA Learn how to create a private endpoint for Azure SQL |
|
| Azure Synapse Analytics | All public regions All Government regions |
Supported for Proxy connection policy | GA Learn how to create a private endpoint for Azure Synapse Analytics. |
|
| Azure Cosmos DB | All public regions All Government regions All China regions |
GA Learn how to create a private endpoint for Cosmos DB. |
||
| Azure Database for PostgreSQL - Single server | All public regions All Government regions All China regions |
Supported for General Purpose and Memory Optimized pricing tiers | GA Learn how to create a private endpoint for Azure Database for PostgreSQL. |
|
| Azure Database for MySQL | All public regions All Government regions All China regions |
GA Learn how to create a private endpoint for Azure Database for MySQL. |
||
| Azure Database for MariaDB | All public regions All Government regions All China regions |
GA Learn how to create a private endpoint for Azure Database for MariaDB. |
||
| Azure Key Vault | All public regions All Government regions |
GA Learn how to create a private endpoint for Azure Key Vault. |
||
| Azure Kubernetes Service - Kubernetes API | All public regions | GA Learn how to create a private endpoint for Azure Kubernetes Service. |
||
| Azure Search | All public regions All Government regions |
Supported with service in Private Mode | GA Learn how to create a private endpoint for Azure Search. |
|
| Azure Container Registry | All public regions All Government regions |
Supported with premium tier of container registry. Select for tiers | GA Learn how to create a private endpoint for Azure Container Registry. |
|
| Azure App Configuration | All public regions | Preview Learn how to create a private endpoint for Azure App Configuration |
||
| Azure Backup | All public regions All Government regions |
GA Learn how to create a private endpoint for Azure Backup. |
||
| Azure Event Hub | All public regions All Government regions |
GA Learn how to create a private endpoint for Azure Event Hub. |
||
| Azure Service Bus | All public region All Government regions |
Supported with premium tier of Azure Service Bus. Select for tiers | GA Learn how to create a private endpoint for Azure Service Bus. |
|
| Azure Relay | All public regions | Preview Learn how to create a private endpoint for Azure Relay. |
||
| Azure Event Grid | All public regions All Government regions |
GA Learn how to create a private endpoint for Azure Event Grid. |
||
| Azure Web Apps | All public regions | Supported with PremiumV2, PremiumV3, or Function Premium plan | GA Learn how to create a private endpoint for Azure Web Apps. |
|
| Azure Machine Learning | All public regions | GA Learn how to create a private endpoint for Azure Machine Learning. |
||
| Azure Automation | All public regions | Preview Learn how to create a private endpoint for Azure Automation. |
||
| Azure IoT Hub | All public regions | GA Learn how to create a private endpoint for Azure IoT Hub. |
||
| Azure SignalR | EAST US, SOUTH CENTRAL US, WEST US 2, All China regions |
Preview Learn how to create a private endpoint for Azure SignalR. |
||
| Azure Monitor (Log Analytics & Application Insights) |
All public regions | GA Learn how to create a private endpoint for Azure Monitor. |
||
| Azure Batch | All public regions except: Germany CENTRAL, Germany NORTHEAST All Government regions |
GA Learn how to create a private endpoint for Azure Batch. |
||
| Azure Data Factory | All public regions All Government regions All China regions |
Credentials need to be stored in an Azure key vault | GA Learn how to create a private endpoint for Azure Data Factory. |
|
| Azure Managed Disks | All public regions All Government regions All China regions |
Click here for known limitations | GA Learn how to create a private endpoint for Azure Managed Disks. |
For the most up-to-date notifications, check the Azure Private Link updates page.
私有链接的一个缺点是，为了支持使用相同名称解析PaaS资源，您需要实现DNS来解析特定资源的私有链接区域。您可以通过集成Azure私有DNS来设置这个功能，但如果您的DNS服务已经在运行，或者您不想在虚拟网络中使用Azure私有DNS，那么这可能会有问题。
更多信息:https://docs.microsoft.com/en-us/azure/private-link/private-link-overvi…。
选择哪一个?
现在，您已经对每个服务进行了快速介绍，问题归结为应该使用哪个服务?答案将基于几个因素。
首先，查看您想要访问的资源，并查看它所支持的服务。有些服务将只受其中一种或另一种支持，因此这将为您选择。
假设您可以为您的服务使用任何一个选项，那么决定可能会归结为复杂性。
服务端点比私有链接更直接、更容易设置。您可以通过在门户中单击几次来启用服务端点，并且不需要任何其他服务。然而，私有链接需要您实现DNS更改，并可能使用Azure私有DNS，它还需要决定服务将连接到您的虚拟网络的何处。因此，如果您需要对PaaS服务快速进行额外的访问限制，或者没有权利或知识对DNS进行更改，那么服务端点可能是最好的选择。
除了复杂性之外，私有链接在几乎所有其他方面都优于服务端点。如果您可以设置这个，并且您的服务支持它，那么我建议您在服务端点上使用私有链接。特别是与私人链接，你可以:
- 加入你的PaaS资源到你的vNet，并给它一个私有IP
- 确保流量保持在虚拟网络中
- 将出口限制到特定的PaaS服务，并防止数据泄漏
- 支持从现场和窥视网络访问
- 连接到跨区域的资源，甚至Azure的广告租户
对于大多数关注PaaS资源的安全性和访问限制的人来说，Private Link将是更好的选择。在这一点上，我很惊讶地看到支持服务端点的资源列表超出了现有可用资源的范围，大多数PaaS资源希望发布私有链接产品。
原文：https://samcogan.com/service-endpoints-and-private-link-whats-the-difference/
本文：http://jiagoushi.pro/node/1379
讨论：请加入知识星球【首席架构师圈】或者小号【jiagoushi_pro】或者QQ群【11107777】
- 429 次浏览
【Azure云架构】用于Azure计算服务选型的决策树
Azure提供了许多托管应用程序代码的方法。术语compute指的是应用程序所运行的计算资源的托管模型。下面的流程图将帮助您为应用程序选择计算服务。该流程图指导您通过一组关键的决策标准来实现推荐。
将此流程图视为一个起点。每个应用程序都有独特的需求，所以要以推荐作为起点。然后进行更详细的评估，比如:
- 特性集
- 服务限制
- 成本
- SLA
- 区域的可用性
- 开发人员生态系统和团队技能
- 计算对比表
如果您的应用程序包含多个工作负载，请分别评估每个工作负载。完整的解决方案可能包含两个或多个计算服务。
有关在Azure中托管容器的选项的更多信息，请参见Azure容器。
流程图
定义
“Lift和shift”是一种将工作负载迁移到云上而无需重新设计应用程序或更改代码的策略。也叫重新承载。有关更多信息，请参见Azure迁移中心。
云优化是一种通过重构应用程序以利用云本地特性和功能来迁移到云的策略。
下一个步骤
有关要考虑的其他标准，请参见选择Azure计算服务的标准。
原文：https://docs.microsoft.com/en-us/azure/architecture/guide/technology-choices/compute-decision-tree
本文：https://pub.intelligentx.net/decision-tree-azure-compute-services
讨论：请加入知识星球【首席架构师圈】或者飞聊小组【首席架构师智库】
- 111 次浏览
【Azure云架构】选择Azure计算服务的标准
术语compute指的是应用程序所运行的计算资源的托管模型。下表比较了几个轴上的Azure计算服务。在为应用程序选择计算选项时，请参考这些表。
托管模式
| Criteria | Virtual Machines | App Service | Service Fabric | Azure Functions | Azure Kubernetes Service | Container Instances | Azure Batch |
|---|---|---|---|---|---|---|---|
| Application composition | Agnostic | Applications, containers | Services, guest executables, containers | Functions | Containers | Containers | Scheduled jobs |
| Density | Agnostic | Multiple apps per instance via app service plans | Multiple services per VM | Serverless 1 | Multiple containers per node | No dedicated instances | Multiple apps per VM |
| Minimum number of nodes | 1 2 | 1 | 5 3 | Serverless 1 | 3 3 | No dedicated nodes | 1 4 |
| State management | Stateless or Stateful | Stateless | Stateless or stateful | Stateless | Stateless or Stateful | Stateless | Stateless |
| Web hosting | Agnostic | Built in | Agnostic | Not applicable | Agnostic | Agnostic | No |
| Can be deployed to dedicated VNet? | Supported | Supported5 | Supported | Supported 5 | Supported | Not supported | Supported |
| Hybrid connectivity | Supported | Supported 6 | Supported | Supported 7 | Supported | Not supported | Supported |
笔记
- 如使用消费计划。如果使用App服务计划，则在分配给您的App服务计划的vm上运行函数。参见为Azure功能选择正确的服务计划。
- 具有两个或多个实例的高级SLA。
- 推荐用于生产环境。
- 可以缩小到零后，工作完成。
- 需要App服务环境(ASE)。
- 使用Azure应用服务混合连接。
- 需要App服务计划。
DevOps
| Criteria | Virtual Machines | App Service | Service Fabric | Azure Functions | Azure Kubernetes Service | Container Instances | Azure Batch |
|---|---|---|---|---|---|---|---|
| Local debugging | Agnostic | IIS Express, others 1 | Local node cluster | Visual Studio or Azure Functions CLI | Minikube, others | Local container runtime | Not supported |
| Programming model | Agnostic | Web and API applications, WebJobs for background tasks | Guest executable, Service model, Actor model, Containers | Functions with triggers | Agnostic | Agnostic | Command line application |
| Application update | No built-in support | Deployment slots | Rolling upgrade (per service) | Deployment slots | Rolling update | Not applicable |
笔记
- 选项包括IIS Express for ASP。NET或node.js (iisnode);PHP web服务器;Azure Toolkit for IntelliJ, Azure Toolkit for Eclipse。App Service也支持部署web App的远程调试。
- 请参阅资源管理器提供程序、区域、API版本和模式。
Scalability
| Criteria | Virtual Machines | App Service | Service Fabric | Azure Functions | Azure Kubernetes Service | Container Instances | Azure Batch |
|---|---|---|---|---|---|---|---|
| Autoscaling | Virtual machine scale sets | Built-in service | Virtual machine scale sets | Built-in service | Pod auto-scaling1, cluster auto-scaling2 | Not supported | N/A |
| Load balancer | Azure Load Balancer | Integrated | Azure Load Balancer | Integrated | Azure Load Balancer or Application Gateway | No built-in support | Azure Load Balancer |
| Scale limit3 | Platform image: 1000 nodes per scale set, Custom image: 100 nodes per scale set | 20 instances, 100 with App Service Environment | 100 nodes per scale set | 200 instances per Function app | 100 nodes per cluster (default limit) | 20 container groups per subscription (default limit). | 20 core limit (default limit). |
笔记
- 看到自动pods.。
- 参见自动扩展集群以满足Azure Kubernetes服务(AKS)上的应用程序需求。
- 参见Azure订阅和服务限制、配额和约束。
Availability
| Criteria | Virtual Machines | App Service | Service Fabric | Azure Functions | Azure Kubernetes Service | Container Instances | Azure Batch |
|---|---|---|---|---|---|---|---|
| SLA | SLA for Virtual Machines | SLA for App Service | SLA for Service Fabric | SLA for Functions | SLA for AKS | SLA for Container Instances | SLA for Azure Batch |
| Multi region failover | Traffic manager | Traffic manager | Traffic manager, Multi-Region Cluster | Not supported | Traffic manager | Not supported | Not Supported |
关于服务保障的指导学习，请查看核心云服务——Azure架构和服务保障。
Other
| Criteria | Virtual Machines | App Service | Service Fabric | Azure Functions | Azure Kubernetes Service | Container Instances | Azure Batch |
|---|---|---|---|---|---|---|---|
| SSL | Configured in VM | Supported | Supported | Supported | Ingress controller | Use sidecar container | Supported |
| Cost | Windows, Linux | App Service pricing | Service Fabric pricing | Azure Functions pricing | AKS pricing | Container Instances pricing | Azure Batch pricing |
| Suitable architecture styles | N-Tier, Big compute (HPC) | Web-Queue-Worker, N-Tier | Microservices, Event-driven architecture | Microservices, Event-driven architecture | Microservices, Event-driven architecture | Microservices, task automation, batch jobs | Big compute (HPC) |
原文：https://docs.microsoft.com/en-us/azure/architecture/guide/technology-choices/compute-comparison
本文：
讨论：请加入知识星球【首席架构师圈】或者飞聊小组【首席架构师智库】
- 65 次浏览
【Dynamics 】成功实施Dynamics 365的五个技巧
Content+Cloud的企业应用程序解决方案专家Duncan Kerr为成功实施Microsoft Dynamics 365提供了五条建议，帮助您的企业避免与该过程相关的常见陷阱。
在获取和实施任何应用程序的过程中，IT决策者都面临一些挑战。其中包括如何真正了解他们正在购买的东西，确保它能满足他们的需要，以及他们如何获得最大的投资回报。
Microsoft Dynamics 365也不例外。因此，在实施之前充分考虑以下五点，可以使流程尽可能顺利。
1.知道你在买什么以及为什么
首先，问问自己“我真的知道我在买什么吗？”Microsoft Dynamics 365涵盖了非常广泛的应用程序，从财务和人力资源到现场服务和项目。
如图所示，它还位于Power Platform、Microsoft 365和AppSource的更广泛的生态系统中。
因此，与其专注于特定的应用程序，不如考虑你试图解决什么问题，以及你需要如何解决它。以诸如“我们需要一个CRM系统”之类的语句开头不再合适。“我们需要了解我们的客户、他们的需求和当前情况”更像是这样。但继续往下钻。“我如何做到这一点，我需要知道什么，这些知识将从何而来？”这些是更相关的问题。
我认为，如果我们忽视价格和知识产权，上述生态系统可以解决几乎所有的需求，但需求定义不佳是一个问题。我并不是说你需要一份1200行的提案申请问卷——这个问题不是关于非常具体的需求。相反，重点应该是它将为组织带来哪些好处。无论是增加收入、降低成本还是加快决策。
不再有一个应用程序能满足您的需求——我相信，这就是为什么以Dynamics 365为中心的Microsoft生态系统是理想的。它可以根据您的需要延长时间，并快速满足不断变化的业务需求。
对我来说，这么说可能太容易了，但成本并不是决定的主要因素。当然，总体预算很重要。但明智地花钱，注重投资回报和成功结果，是至关重要的。
将更大的问题分解为更小的挑战，一次专注于一个。这样你就可以让自己获得最大的投资回报。此外，找出首先要克服的最重要的问题。你不可能一次解决所有问题，所以要优先考虑。
2.研究并定制订阅
购买Microsoft Dynamics 365相对容易——在最基本的水平上，它是按用户每月定价的。然而，您可以选择额外的选项，使您能够更紧密地将套餐与您的业务需求相匹配。
要获得正确的平衡，请关注业务成果。问问自己“我怎样才能让我的用户尽可能容易地更有效地操作？”
Dynamics365为您提供了“公民开发者”方法的极大灵活性。但在购买时，您需要决定您将在内部做多少工作，以及您希望您的it合作伙伴做多少工作。记住，在一个快速数字化转型的世界中，有必要定期审查和修改您的方法。
我认为有两种截然不同的方法。对于基于ERP的解决方案（财务、供应链、业务中心）以及一定程度上的运营平台（人力资源、现场服务和项目运营），有必要纠正核心流程。毕竟，增值税申报必须准确，对吗？这保证了瀑布式方法——它需要在上线时准确无误。账单必须准时，现金收款必须容易。因此，购买这项服务需要对任务进行详细的分解，才能投入使用。
或者，一些Dynamics 365应用程序受益于不断创新——新领域、流程和运营——以满足不断变化的需求。这将采取更灵活的方法。建立你的用户故事，考虑你可以用预算、时间和收益做什么。然后重新投资并重复该过程。
3.从各个角度看待训练
培训被充分理解为一项实施要求。当然，管理者会通过留出时间来提供必要的支持。
然而，仍然存在一些挑战。通常，员工很长时间没有接受过系统培训，如果有的话。他们在学习新系统的来龙去脉方面可能没有很好的实践。
跳探戈确实需要两个人——他们必须参与这个过程才能从中受益。做笔记、截屏和提问都是这方面的积极迹象。同样重要的是，提供者为他们设置练习，以测试他们的理解，而不仅仅是向他们展示一个系统。现在也很容易录制训练课程。但诚实地问自己，他们多久会回复一次？
另一个考虑因素是“培训培训师”。
这是一个很好的概念，可以为组织节省大量成本。但要考虑三件事——培训最终用户需要多少内部时间，这些时间真的会被提供吗？你的超级用户是否具备以吸引人的方式传递知识的技能？仅仅因为某人了解一个系统，并不意味着他们还具备有效教授或指导正确受众的技能。
4.充分准备数据以进行迁移
在这种情况下，处理数据是一项重大挑战——首先，应该设定期望值。很难证明迁移所有数据的合理性。其中大部分内容可能不干净，格式肯定会有所不同。此外，随着时间的推移，对它的需要也会迅速减少。
但是，出于法律和业务原因，您可能需要将数据保存一段时间。根据格式的不同，有很多选项。保持旧服务器的运行，迁移到Azure和冷存储，将数据迁移到SQL数据库或数据仓库，以便仍然可以访问。
另一个问题是，您的数据很可能比您最初预期的更糟，特别是在您的业务上次审查数据后已经过了一段时间的情况下。清理数据是项目中一个耗时、富有挑战性且常常吃力不讨好的部分，但正确处理至关重要。此外，一旦它被清洗，你必须在迁移之前找出如何保持它在这种状态。
最后，您的数据真的需要迁移吗，还是可以重新键入？这是唯一一次值得考虑手动过程。但如果要求员工将数据重新输入新系统，以使其符合要求，清理数据，并扩展和丰富数据，这可能会带来好处。
5.不要跳过用户验收测试
过去，需要对系统进行测试以确保其代码正常工作。对于基于SaaS的解决方案，这一点不那么重要——尽管如果您已经以任何方式扩展了系统，它仍需要测试。
用户验收测试（UAT），也称为测试版或最终用户测试，可以执行非常重要的验证，您购买的软件符合您的业务目标。这样做的机制是在您的用户中进行测试，这些用户知道您的业务每天需要什么。
您执行的UAT应回答以下问题。
- 系统是否正确配置并以预期方式工作？
- 数据是否已适当迁移，例如，邮政编码是否在正确的字段中？
- 用户是否知道如何在系统中执行所有任务？这包括有效性和完整性
这意味着UAT对项目的成功至关重要。然而，像培训一样，用户可能不知道如何实现这一点。它必须是正式的，你需要详细的脚本，明确的测试列表和预期结果。最重要的是，您需要管理流程，并确保在上线之前，所有测试都以您满意的方式完成。这需要大量的内部努力，必须留出充足的时间。
与数字化转型一样，我们必须以不同的方式实施Microsoft Dynamics 365等项目。重要的是要有一个诚实的技术合作伙伴，他也会挑战你作为一个关键的朋友。他们必须努力取得相互成功的结果，专注于挑战，并确保双方都能提前解决。
- 61 次浏览
【云治理】Azure企业脚手架：规定性订阅治理
视频号
微信公众号
知识星球
企业越来越多地采用公共云，因为它具有灵活性和灵活性。他们依靠云的优势来创造收入并优化业务的资源使用。Microsoft Azure提供了大量服务和功能，企业可以像构建块一样组装这些服务和功能来解决各种工作负载和应用程序。
决定使用Microsoft Azure只是实现云优势的第一步。第二步是了解企业如何有效使用Azure，并确定需要具备的基线功能，以解决以下问题：
- “我担心数据主权；我如何确保我的数据和系统符合我们的监管要求？”
- “我如何知道每种资源支持的是什么，这样我才能对其进行核算并准确地收回？”
- “我想确保我们在公共云中部署或做的一切都从安全第一的心态开始，我该如何帮助实现这一点？”
没有护栏的空订阅的前景令人望而生畏。此空格可能会阻碍您迁移到Azure。
本文为技术专业人员提供了一个起点，以解决治理需求，并在其与敏捷性需求之间取得平衡。它引入了企业脚手架的概念，指导组织以安全的方式实施和管理其Azure环境。它为制定有效和高效的控制措施提供了框架。
治理需求
在迁移到Azure时，您必须尽早解决治理主题，以确保在企业内成功使用云。不幸的是，创建全面治理系统的时间和官僚作风意味着一些业务组在不涉及企业IT的情况下直接求助于提供商。如果资源管理不当，这种方法可能会让企业面临妥协。公共云的特点——灵活性、灵活性和基于消费的定价——对于需要快速满足客户（内部和外部）需求的业务组来说很重要。但企业IT需要确保数据和系统得到有效保护。
创建建筑时，脚手架用于创建结构的基础。脚手架引导总体轮廓，并为安装更永久的系统提供锚点。企业脚手架是一样的：一组灵活的控件和Azure功能，为环境提供结构，并为构建在公共云上的服务提供锚。它为构建者（It和业务组）提供了创建和附加新服务的基础，同时考虑到交付速度。
脚手架是基于我们从与各种规模的客户的多次接触中收集到的实践。这些客户包括在云中开发解决方案的小型组织，以及正在迁移工作负载和开发云原生解决方案的大型跨国企业和独立软件供应商。企业脚手架是“专门构建的”，可以灵活地支持传统的IT工作负载和敏捷工作负载，例如开发人员基于Azure平台功能创建软件即服务（SaaS）应用程序。
企业脚手架可以作为Azure中每个新订阅的基础。它使管理员能够确保工作负载满足组织的最低治理要求，而不会阻止业务组和开发人员快速实现自己的目标。我们的经验表明，这大大加速而不是阻碍了公共云的增长。
笔记
微软发布了一项名为Azure蓝图的新功能，使您能够跨订阅和管理组打包、管理和部署通用映像、模板、策略和脚本。这种能力是脚手架作为参考模型的目的和将该模型部署到您的组织之间的桥梁。
下图显示了脚手架的组件。该基金会依赖于一个坚实的管理层次结构和订阅计划。支柱包括资源管理器策略和强大的命名标准。脚手架的其余部分是Azure的核心功能和特性，它们能够实现并连接一个安全和可管理的环境。
定义层次结构
脚手架的基础是企业协议（EA）注册到订阅和资源组的层次结构和关系。注册从合同的角度定义了贵公司内Azure服务的形式和使用。在企业协议中，您可以将环境进一步细分为部门、帐户、订阅和资源组，以匹配组织的结构。
Azure订阅是包含所有资源的基本单元。它还定义了Azure中的几个限制，例如核心数量、虚拟网络和其他资源。资源组用于进一步完善订阅模型，并实现更自然的资源分组。
每个企业都是不同的，上图中的层次结构使Azure在公司内部的组织方式具有很大的灵活性。对层次结构进行建模以反映公司的计费、资源管理和资源访问需求是在公共云中启动时做出的第一个也是最重要的决定。
部门和账户
EA注册的三种常见模式是：
功能模式：
业务单元模式：
地理格局：
尽管这些模式有自己的位置，但业务单元模式因其在建模组织成本模型以及反映控制范围方面的灵活性而越来越多地被采用。微软的核心工程和运营团队已经创建了一个以联邦、州和地方为模型的业务单元模式的有效子集。有关详细信息，请参阅组织订阅和资源组。
Azure管理组
Microsoft现在提供了另一种建模层次结构的方法：Azure管理组。管理组比部门和账户灵活得多，它们可以嵌套到六个级别。管理组允许您创建一个独立于计费层次结构的层次结构，仅用于有效管理资源。管理组可以镜像您的计费层次结构，而且企业通常都是这样开始的。但是，当您使用管理组对组织进行建模、将相关订阅分组（无论其在计费层次结构中的位置如何）并分配常见角色、策略和计划时，管理组的功能就在于此。一些例子包括：
- 生产与非生产。一些企业创建管理组来识别其生产和非生产订阅。管理组使这些客户能够更轻松地管理角色和策略。例如，非生产订阅可能允许开发人员访问“贡献者”，但在生产中，他们只能访问“读者”。
- 内部服务与外部服务。企业通常对内部服务和面向客户的服务有不同的要求、策略和角色。
精心设计的管理小组，以及Azure政策和政策倡议，是Azure高效治理的支柱。
订阅
在决定您的部门和帐户（或管理组）时，您主要是在评估如何安排Azure环境以匹配您的组织。然而，订阅才是真正的工作所在，您在这里的决策会影响安全性、可扩展性和计费。许多组织使用以下模式作为指南：
- 应用程序/服务：订阅表示应用程序或服务（应用程序组合）
- 生命周期：订阅表示服务的生命周期，如生产或开发。
- 部门：订阅代表组织中的部门。
前两种模式是最常用的，强烈推荐使用这两种模式。生命周期方法适用于大多数组织。在这种情况下，一般建议使用两个基本订阅，生产和非生产，然后使用资源组进一步分离环境。
资源组
Azure资源管理器使您能够将资源组织到有意义的组中进行管理、计费或自然亲和。资源组是具有公共生命周期或共享属性（如“所有SQL服务器”或“应用程序a”）的资源容器。
资源组不能嵌套，并且资源只能属于一个资源组。某些操作可以作用于资源组中的所有资源。例如，删除资源组会删除该资源组中的所有资源。与订阅一样，在创建资源组时也有常见的模式，从传统的IT工作负载到敏捷的IT工作负荷都会有所不同：
- 传统的IT工作负载通常按同一生命周期内的项目分组，例如应用程序。按应用程序分组允许单独的应用程序管理。
- 敏捷的IT工作负载往往集中在面向外部客户的云应用程序上。资源组通常反映部署层（如web层或应用程序层）和管理层。
了解您的工作量有助于制定资源组策略。这些图案可以混合搭配。例如，共享服务资源组可以与敏捷工作负载资源组位于同一订阅中。
命名标准
脚手架的第一根支柱是一致的命名标准。设计良好的命名标准使您能够识别门户、账单和脚本中的资源。您可能已经有了内部部署基础设施的现有命名标准。将Azure添加到环境中时，应将这些命名标准扩展到Azure资源。
提示
对于命名约定：
- 审查并尽可能采用云采用框架命名和标记指南。本指南帮助您确定一个有意义的命名标准，并提供了大量示例。
- 使用资源管理器策略来帮助实施命名标准。
记住，以后很难更改名称，所以现在几分钟可以省去以后的麻烦。
将命名标准集中在那些更常用和搜索的资源上。例如，所有资源组都应遵循明确性的严格标准。
资源标签
资源标记与命名标准紧密一致。随着资源被添加到订阅中，出于计费、管理和运营目的对资源进行逻辑分类变得越来越重要。有关详细信息，请参阅使用标记组织Azure资源。
重要的
标签可能包含个人信息，可能属于GDPR的规定范围。仔细计划标签的管理。如果您正在查找有关GDPR的一般信息，请参阅Microsoft Service Trust Portal的GDPR部分。
除了计费和管理之外，标签还有很多用途。它们通常被用作自动化的一部分（见后面的部分）。如果不提前考虑，这可能会导致冲突。最佳做法是在企业级别（如ApplicationOwner和CostCenter）识别所有常见标签，并在使用自动化部署资源时一致地应用它们。
Azure政策和计划
脚手架的第二个支柱涉及使用Azure策略和计划，通过对订阅中的资源和服务执行规则（具有效果）来管理风险。Azure策略计划是旨在实现单个目标的策略集合。然后将政策和举措分配到资源范围，以开始执行这些政策。
当与前面提到的管理小组一起使用时，政策和举措甚至更加强大。管理组允许将计划或策略分配给一整套订阅。
资源管理器策略的常见用法
政策和计划是强大的Azure工具。策略允许公司为传统IT工作负载提供控制，为业务线应用程序提供稳定性，同时也允许更灵活的工作负载开发，例如在不使企业面临额外风险的情况下开发客户应用程序。最常见的策略模式是：
- 地理法规遵从性和数据主权。Azure在世界各地拥有越来越多的地区。企业通常需要确保特定范围内的资源保留在一个地理区域内，以满足监管要求。
- 避免公开服务器。Azure策略可以禁止部署某些资源类型。通常会创建一个策略来拒绝在特定范围内创建公共IP，从而避免服务器意外暴露在互联网上。
- 成本管理和元数据。资源标签通常用于向资源和资源组（如CostCenter和Owner）添加重要的计费数据。这些标签对于资源的准确计费和管理是非常宝贵的。策略可以强制将资源标签应用于所有部署的资源，使其更易于管理。
举措的共同用途
计划为企业提供了将逻辑策略分组并将其作为单个实体进行跟踪的能力。计划有助于企业解决敏捷和传统工作负载的需求。倡议的常见用途包括：
- 在Microsoft Defender for Cloud中启用监控。这是Azure策略中的默认计划，也是计划的一个很好的例子。它使策略能够识别未加密的SQL数据库、虚拟机（VM）漏洞以及更常见的安全相关需求。
- 具体监管举措。企业通常将管理要求（如HIPAA）的通用策略分组，以便有效地跟踪控制和对这些控制的遵守情况。
- 资源类型和SKU。创建一个限制可以部署的资源类型以及可以部署的SKU的计划，有助于控制成本，并确保您的组织只部署您的团队有技能和程序支持的资源。
提示
我们建议您始终使用计划定义，而不是策略定义。将计划分配到范围（如订阅或管理组）后，您可以轻松地将另一个策略添加到计划中，而无需更改任何分配。这使得了解所应用的内容和跟踪合规性变得更加容易。
政策和倡议分配
创建策略并将其分组为逻辑计划后，必须将策略分配给一个范围，例如管理组、订阅或资源组。分配还允许您从策略的分配中排除子范围。例如，如果您拒绝在订阅中创建公共IP，则可以为连接到受保护DMZ的资源组创建具有排除的分配。
Azure策略GitHub存储库中提供了显示如何将策略和计划应用于Azure中的资源的示例。
身份和访问管理
采用公共云时要问的关键问题是“谁应该有权访问资源？”和“我如何控制这种访问？”控制对Azure门户和资源的访问对您在云中的资产的长期安全至关重要。
为了确保对资源的访问安全，您将首先配置身份提供程序，然后配置角色和访问权限。连接到本地Active Directory的Azure Active Directory（Azure AD）是Azure中身份的基础。但是，Azure AD与本地Active Directory不同，了解什么是Azure AD租户以及它与您的注册之间的关系很重要。查看Azure中的资源访问管理，以深入了解Azure AD和本地Active Directory。若要将本地目录连接并同步到Azure AD，请在本地安装并配置Azure AD connect工具。
Azure最初发布时，对订阅的访问控制是基本的：可以为用户分配管理员或联合管理员角色。访问此经典模型中的订阅意味着访问门户中的所有资源。这种细粒度控制的缺乏导致了订阅的激增，从而为注册提供了合理级别的访问控制。订阅量的激增已不再需要。使用Azure基于角色的访问控制（RBAC），您可以将用户分配给提供通用权限的标准角色，如所有者、参与者或读取器，甚至可以创建自己的角色。
在实施Azure基于角色的访问控制时，强烈建议采用以下做法：
- 控制订阅的管理员和联合管理员角色，因为这些角色具有广泛的权限。如果订阅所有者需要管理Azure经典部署，您只需要将其添加为联合管理员。
- 使用管理组可以跨多个订阅分配角色，并减轻在订阅级别管理角色的负担。
- 将Azure用户添加到Active Directory中的组（例如，Application X Owners）中。使用同步组为组成员提供管理包含应用程序的资源组的适当权限。
- 遵循给予完成预期工作所需最少特权的原则。
重要的
请考虑使用Azure AD特权身份管理、Azure多因素身份验证和Azure AD条件访问功能，以在Azure订阅中提供更好的安全性和管理操作的可见性。这些功能来自有效的Azure AD Premium许可证（取决于功能），以进一步保护和管理您的身份。Azure AD PIM通过审批工作流实现实时管理访问，并对管理员激活和活动进行全面审计。Azure多因素身份验证是另一项关键功能，它支持登录Azure门户的两步验证。当与Azure AD Conditional Access控件相结合时，您可以有效地管理您的妥协风险。
规划和准备您的身份和访问控制，并遵循Azure身份管理最佳实践，是您可以采用的最佳风险缓解策略之一，应被视为每次部署的强制性策略。
安全
传统上，云应用的最大障碍之一是对安全性的担忧。IT风险经理和安全部门需要确保Azure中的资源在默认情况下得到保护和安全。Azure提供了可用于保护资源的功能，同时检测和消除针对这些资源的威胁。
Microsoft云卫士
Microsoft Defender for Cloud除了提供高级威胁保护外，还提供了整个环境中资源安全状态的统一视图。云卫士是一个开放平台，使微软合作伙伴能够创建插入并增强其功能的软件。云卫士免费层的基线功能提供了增强您安全态势的评估和建议。它的付费层实现了额外的宝贵功能，如即时特权访问和自适应应用程序控制（allowlists）。
提示
云卫士是一个功能强大的工具，它会定期进行改进，并提供新功能，用于检测威胁和保护您的企业。强烈建议始终启用云卫士。
Azure资源的锁定
随着您的组织将核心服务添加到订阅中，避免业务中断变得越来越重要。一种常见的中断发生在Azure订阅中执行的脚本或工具无意中删除资源时。锁限制了对高价值资源的操作，修改或删除这些资源会产生重大影响。您可以对订阅、资源组或单个资源应用锁。将锁应用于基础资源，如虚拟网络、网关、网络安全组和密钥存储帐户。
Azure的安全DevOps工具包
Azure安全DevOps工具包（AzSK）是一个脚本、工具、扩展和自动化功能的集合，最初由微软自己的IT团队创建，并通过GitHub作为开源发布。AzSK通过广泛的自动化和将安全顺利集成到本地DevOps工作流中，满足团队的端到端Azure订阅和资源安全需求，帮助实现以下六个重点领域的安全DevOps：
- 确保订阅安全
- 实现安全开发
- 将安全性集成到CI/CD中
- 持续保证
- 警报和监控
- 云风险治理
AzSK是一套丰富的工具、脚本和信息，是完整Azure治理计划的重要组成部分，将其纳入您的脚手架对于支持您的组织风险管理目标至关重要。
Azure更新管理
确保环境安全的关键任务之一是确保服务器使用最新更新进行修补。虽然有许多工具可以实现这一点，但Azure提供了Azure更新管理解决方案，以解决关键操作系统补丁的识别和推出问题。它使用Azure Automation，这将在本指南稍后的“自动化”部分中介绍。
监控和警报
收集和分析遥测数据，以便了解您在Azure订阅中使用的服务的活动、性能指标、运行状况和可用性，这对于主动管理您的应用程序和基础设施至关重要，也是每个Azure订阅的基本需求。每个Azure服务都以活动日志、度量和诊断日志的形式发出遥测。
- 活动日志描述对订阅中的资源执行的所有操作。
- 度量是由资源发出的数字信息，用于描述资源的性能和运行状况。
- 诊断日志由Azure服务发出，并提供有关该服务操作的丰富、频繁的数据。
这些信息可以在多个层面上查看和采取行动，并且正在不断改进。Azure通过下图中列出的服务提供Azure资源的共享、核心和深度监控功能。
共享功能
- 警报：您可以从Azure资源中收集每个日志、事件和度量，但由于无法收到关键情况的通知并采取行动，这些数据仅用于历史目的和取证。Azure警报会主动通知您在所有应用程序和基础架构中定义的条件。您可以跨日志、事件和度量创建警报规则，这些规则使用操作组来通知收件人集。操作组还提供了使用外部操作（如webhook）自动修复的能力，以运行Azure Automation Runbook和Azure Functions。
- 仪表板：仪表板使您能够聚合监控视图，并跨资源和订阅组合数据，从而为您提供Azure资源遥测的企业范围视图。您可以创建和配置自己的视图，并与其他人共享。例如，您可以创建一个由各种瓦片组成的仪表板，供数据库管理员提供所有Azure数据库服务的信息，包括Azure SQL数据库、Azure database For PostgreSQL和Azure database For MySQL。
- 度量资源管理器：度量是由Azure资源生成的数值（CPU百分比或磁盘I/O度量），可以深入了解资源的操作和性能。使用度量资源管理器，您可以定义感兴趣的度量，并将其发送到日志分析以进行聚合和分析。
核心监测
- Azure监视器：Azure监视器是为监视Azure资源提供单一源的核心平台服务。Azure Monitor的Azure门户界面为Azure的所有监控功能提供了一个集中的起点，包括Application Insights、Log Analytics、网络监控、管理解决方案和服务地图的深度监控功能。使用Azure Monitor，您可以在整个云环境中可视化、查询、路由、归档和操作来自Azure资源的度量和日志。除了门户之外，您还可以通过Azure Monitor PowerShell cmdlet、跨平台CLI或Azure Monitor REST API检索数据。
- Azure顾问：Azure顾问不断监控您的订阅和环境中的遥测数据。它还推荐了成本优化Azure资源以及提高应用程序资源的性能、安全性和可用性的最佳实践。
- Azure服务运行状况：Azure服务运行状态可识别Azure服务中可能影响您的应用程序的任何问题，并帮助您规划计划维护窗口。
- 活动日志：活动日志描述了对订阅中资源的所有操作。它提供了一个审计跟踪，以确定对资源执行任何CRUD（创建、更新、删除）操作的内容、人员和时间。活动日志事件存储在平台中，可查询90天。您可以将活动日志吸收到日志分析中，以获得更长的保留期，并跨多个资源进行更深入的查询和分析。
深度应用程序监控
- Application Insights:Application Insights使您能够收集特定于应用程序的遥测数据，并监控云中或本地应用程序的性能、可用性和使用情况。通过使用支持的多种语言的SDK（包括.NET、JavaScript、Java、Node.js、Ruby和Python）来检测您的应用程序。Application Insights事件包含在同一个日志分析数据存储中，该数据存储支持基础结构和安全监控，使您能够通过丰富的查询语言随时间关联和聚合事件。
深度基础设施监控
- 日志分析：日志分析通过从各种来源收集遥测和其他数据，并提供查询语言和分析引擎，让您深入了解应用程序和资源的操作，在Azure监控中发挥着核心作用。您可以通过快速日志搜索和视图直接与日志分析数据交互，也可以在其他Azure服务中使用分析工具，将其数据存储在日志分析中，如Application Insights或Microsoft Defender for Cloud。
- 网络监控：Azure的网络监控服务使您能够深入了解网络流量、性能、安全性、连接和瓶颈。精心规划的网络设计应包括配置Azure网络监控服务，如network Watcher和ExpressRoute Monitor。
- 管理解决方案：管理解决方案是为应用程序或服务打包的逻辑、见解和预定义的日志分析查询集。他们依靠日志分析作为存储和分析事件数据的基础。示例管理解决方案包括监控容器和Azure SQL数据库分析。
- 服务地图：服务地图提供了一个图形视图，可以查看您的基础结构组件、它们的流程以及其他计算机和外部流程上的相互依存关系。它在日志分析中集成了事件、性能数据和管理解决方案。
提示
在创建单个警报之前，请创建和维护一组可在Azure警报中使用的共享操作组。这将使您能够集中维护收件人列表、通知传递方法（电子邮件、短信电话号码）和外部操作（Azure Automation Runbook、Azure Functions and Logic Apps、ITSM）的网络挂钩的生命周期。
成本管理
当你从内部部署云转移到公共云时，你将面临的一个主要变化是从资本支出（购买硬件）转向运营支出（在使用服务时支付服务费用）。这种转变还需要对成本进行更仔细的管理。云的好处是，你只需在不需要的时候关闭或调整服务的大小，就可以从根本上积极影响你使用的服务的成本。谨慎地在云中管理成本是一种最佳做法，也是成熟客户每天都要做的事情。
Microsoft提供了多种工具，可帮助您可视化、跟踪和管理成本。我们还提供全套API，使您能够自定义成本管理并将其集成到自己的工具和仪表板中。这些工具松散地分为Azure门户功能和外部功能。
Azure门户功能
这些工具可以为您提供有关成本的即时信息以及采取行动的能力。
- 订阅资源成本：Azure成本管理+计费视图位于门户中，可按资源或资源组快速查看您的成本和每日支出信息。
- Azure成本管理+计费：这允许您管理和分析您的Azure支出以及您在其他公共云提供商上的支出。有免费和付费两种级别，具有丰富的功能。
- Azure预算和行动小组：直到最近，了解某件事的成本并采取行动更多的是一项手动练习。随着Azure预算及其API的引入，现在您可以创建在成本达到阈值时运行的操作。例如，当测试资源组的消耗量达到其预算的100%时，您可以关闭它。
- Azure顾问：知道一些东西的成本只是战斗的一半；另一半是知道如何处理这些信息。Azure Advisor为您提供有关节省资金、提高可靠性甚至提高安全性的操作建议。
外部成本管理工具
- Power BI Azure消费洞察：你想为你的组织创建自己的可视化吗？如果是这样，那么Power BI的Azure Consumption Insights内容包就是您的首选工具。使用此内容包和Power BI，您可以创建自定义可视化来表示您的组织，对成本进行更深入的分析，并添加其他数据源以进一步丰富。
- Azure消费API：除了预算、保留实例和市场费用信息外，消费API还为您提供对成本和使用情况数据的编程访问。这些API仅适用于EA注册和一些Web Direct订阅，但它们使您能够将成本数据集成到自己的工具和数据仓库中。您还可以通过Azure CLI访问这些API。
长期和成熟的云用户遵循某些最佳实践：
- 积极监控成本。成熟的Azure用户组织不断监控成本，并在需要时采取行动。一些组织甚至专门派人进行分析并建议更改使用情况，而这些人在第一次发现运行了数月的未使用HDInsight集群时，付出的不仅仅是自己的代价。
- 使用Azure保留的VM实例。在云中管理成本的另一个关键原则是为工作使用正确的工具。如果您的IaaS虚拟机必须全天候运行，那么使用保留实例将为您节省大量资金。在自动关闭虚拟机和使用保留实例之间找到正确的平衡需要经验和分析。
- 有效地使用自动化。许多工作负载不需要每天都运行。每天关闭虚拟机四小时可以为您节省15%的成本。自动化将很快得到回报。
- 使用资源标记以提高可见性。如本文档其他部分所述，使用资源标签可以更好地分析成本。
- 成本管理是公共云高效运行的核心。取得成功的企业可以控制成本，并将其与实际需求相匹配，而不是过度购买并希望需求到来。
自动化
区别使用云提供商的组织成熟度的众多功能之一是它们所包含的自动化水平。自动化是一个永无止境的过程。当您的组织迁移到云计算时，这是一个您需要投入资源和时间来构建的领域。自动化有很多用途，包括资源的一致部署（直接与另一个核心脚手架概念、模板和DevOps联系在一起）和问题的补救。自动化将Azure脚手架的每个区域连接在一起。
有几种工具可以帮助您构建此功能，从Azure Automation、事件网格和Azure CLI等第一方工具，到Terraform、Jenkins、Chef和Puppet等大量第三方工具。核心自动化工具包括Azure automation、事件网格和Azure云外壳。
- Azure Automation允许您在PowerShell或Python中编写运行手册，用于自动化流程、配置资源，甚至应用补丁。Azure Automation有一套广泛的跨平台功能，这些功能是您部署不可或缺的，但过于广泛，无法在此处深入介绍。
- 事件网格是一个完全管理的事件路由系统，允许您对Azure环境中的事件做出反应。正如Azure自动化是成熟云组织的结缔组织一样，事件网格也是良好自动化的结缔组织。使用事件网格，您可以创建一个简单的无服务器操作，以便在创建新资源时向管理员发送电子邮件，并将该资源记录到数据库中。当资源被删除并从数据库中删除项目时，相同的事件网格可以发出通知。
- Azure云外壳是一个交互式的、基于浏览器的外壳，用于管理Azure中的资源。它为PowerShell或Bash提供了一个完整的环境，可以根据需要启动（并为您维护），以便您有一个一致的环境来运行脚本。Azure云外壳提供了对其他关键工具（已安装）的访问，以自动化您的环境，包括Azure CLI、Terraform和越来越多的其他工具，以管理容器、数据库（sqlcmd）等。
自动化是一项全职工作，它将迅速成为云团队中最重要的运营任务之一。采用“自动化优先”方法的组织在使用Azure方面取得了更大的成功：
- 管理成本：积极寻找机会并创建自动化，以调整资源大小、扩大或缩小规模，并关闭未使用的资源。
- 操作灵活性：通过自动化（以及模板和DevOps），您可以获得一定程度的可重复性，从而提高可用性、安全性，并使您的团队能够专注于解决业务问题。
模板和DevOps
如前所述，作为一个组织，您的目标应该是通过源代码管理的模板和脚本来提供资源，并最大限度地减少环境的交互配置。这种“基础设施即代码”的方法，以及用于连续部署的有纪律的DevOps流程，可以确保一致性并减少环境中的漂移。几乎每个Azure资源都可以通过Azure resource Manager JSON模板与PowerShell或Azure跨平台CLI以及HashiCorp的Terraform等工具进行部署，该工具具有一流的支持和与Azure云外壳的集成）。
使用Azure资源管理器模板的最佳实践等文章极好地讨论了使用Azure DevOps工具链将DevOps方法应用于Azure资源管理者模板的最佳做法和经验教训。花时间和精力开发一套特定于组织需求的核心模板，并使用DevOps工具链（如Azure DevOps、Jenkins、Bamboo、TeamCity和Concourse）开发连续交付管道，尤其是针对您的生产和QA环境。GitHub上有一个大型的Azure Quickstart模板库，您可以将其用作模板的起点，并且可以使用Azure DevOps快速创建基于云的交付管道。
作为生产订阅或资源组的最佳实践，您的目标应该是在默认情况下使用Azure RBAC安全性来禁止交互式用户，并使用基于服务主体的自动连续交付管道来提供所有资源和交付所有应用程序代码。任何管理员或开发人员都不应接触Azure门户以交互方式配置资源。这一级别的DevOps需要协同努力，并使用Azure脚手架的所有概念，提供一个一致且更安全的环境，以满足您的组织的扩展需求。
提示
- 在设计和开发复杂的Azure资源管理器模板时，请使用链接的模板从单一的JSON文件中组织和重构复杂的资源关系。这将使您能够单独管理资源，并使模板更具可读性、可测试性和可重用性。
- Azure是一个超大规模的云提供商。当您将组织从内部部署服务器转移到云时，依赖云提供商和SaaS应用程序使用的相同概念将帮助您的组织更有效地响应业务需求。
核心网络
Azure脚手架参考模型的最后一个组件是您的组织如何以安全的方式访问Azure的核心。对资源的访问可以是内部的（在公司网络内），也可以是外部的（通过互联网）。组织中的用户很容易无意中将资源放错位置，并可能使其受到恶意访问。与本地设备一样，企业必须添加适当的控制措施，以确保Azure用户做出正确的决策。对于订阅治理，我们确定提供基本访问控制的核心资源。核心资源包括：
- 虚拟网络是子网的容器对象。虽然不是严格必要的，但它通常用于将应用程序连接到公司内部资源。
- 用户定义的路由允许您在子网中操作路由表，使您能够通过网络虚拟设备或对等虚拟网络上的远程网关发送流量。
- 虚拟网络对等使您能够在Azure中无缝连接两个或多个虚拟网络，从而创建更复杂的轮辐式设计或共享服务网络。
- 服务端点。过去，PaaS服务依赖于不同的方法来确保从虚拟网络访问这些资源。服务端点允许您仅从连接的端点安全访问启用的PaaS服务，从而提高整体安全性。
- 安全组是一组广泛的规则，提供允许或拒绝进出Azure资源的入站和出站流量的能力。安全组由可以使用服务标签（定义常见的Azure服务，如Azure密钥库或Azure SQL数据库）和应用程序安全组（定义应用程序结构，如web或应用程序服务器）来增强的安全规则组成。
使用网络安全组中的服务标签和应用程序安全组可以：
- 增强规则的可读性，这对理解影响至关重要。
- 在更大的子网中实现有效的微分段，减少扩展并提高灵活性。
Azure虚拟数据中心
Azure通过我们广泛的合作伙伴网络提供内部和第三方功能，为您提供有效的安全保障。更重要的是，微软以Azure虚拟数据中心（VDC）的形式提供了最佳实践和指导。当您从单个工作负载转移到使用混合功能的多个工作负载时，VDC指南将为您提供“配方”，以实现一个灵活的网络，该网络将随着您在Azure中的工作负载的增长而增长。
接下来的步骤
治理对于Azure的成功至关重要。本文针对企业脚手架的技术实现，但只涉及更广泛的过程和组件之间的关系。策略治理自上而下，由业务想要实现的目标决定。当然，Azure治理模型的创建包括来自IT的代表，但更重要的是，它应该有来自业务组领导人以及安全和风险管理的强有力的代表。归根结底，企业脚手架是为了降低业务风险，促进组织的使命和目标。
既然您已经了解了订阅管理，请查看Azure准备就绪的最佳实践，以便在实践中看到这些建议。
- 13 次浏览
【云计算架构】:Azure]比较流，逻辑应用(Logic App),函数和 WebJobs
所有这些服务都可以解决集成问题并自动化业务流程。 它们都可以定义输入、操作、条件和输出。 可以在日程安排或触发器中运行其中一个。 但是，每种服务都有其独特的优点，本文将介绍这些差异。
比较 Microsoft Flow 和 Azure 逻辑应用
流和逻辑应用都是可以创建工作流的“设计器优先”集成服务。 这两种服务都与各种 SaaS 和企业应用程序相集成。
流构建在逻辑应用之上。 它们有相同的工作流设计器和相同的连接器。
借助流，任何办公室工作人员都可以执行简单的集成（例如，对 SharePoint 文档库的审批过程），无需求助开发人员或 IT 部门。 另一方面，逻辑应用可启用需要企业级 DevOps 和安全实践的高级集成（例如 B2B 流程）。 对于业务工作流，其典型特征就是复杂性会随时间增长而增加。 相应地，可以先从流开始，然后根据需要将其转换到逻辑应用。
下表有助于确定流或逻辑应用是否最适合给定的集成。
比较 Azure Functions 和 Azure 逻辑应用
函数和逻辑应用是用于启用无服务器工作负荷的 Azure 服务。 Azure Functions 是一种无服务器计算服务，而 Azure 逻辑应用提供无服务器工作流。 这两种服务都可以创建复杂“业务流程”。 业务流程是函数或步骤（在逻辑应用中称为“操作”）的集合，将执行这些函数或步骤来完成复杂任务。 例如，若要处理一批订单，可以并行执行某个函数的许多实例，等待所有实例完成，然后执行某个函数来计算聚合结果。
对于 Azure Functions，你通过编写代码并使用 Durable Functions 扩展（预览版）来开发业务流程。 对于逻辑应用，你通过使用 GUI 或通过编辑配置文件来创建业务流程。
在构建业务流程、从逻辑应用中调用函数以及从函数中调用逻辑应用时，可以混合使用各种服务。 可以根据服务功能或你的个人喜好选择如何构建每个业务流程。 下表列出了这些服务之间的一些主要区别：
比较函数和 WebJobs
与 Azure Functions 一样，包含 WebJobs SDK 的 Azure 应用服务是一项代码优先的集成服务，专为开发人员设计。 二者都是在 Azure 应用服务 上构建的，支持源代码管理集成、身份验证以及使用 Application Insights 集成进行监视等功能。
WebJobs 和 WebJobs SDK
可以使用应用服务的 WebJobs 功能，在应用服务 Web 应用上下文中运行脚本或代码。 WebJobs SDK 是一个为 WebJobs 设计的框架，可以简化为响应 Azure 服务中的事件而编写的代码。 例如，若要响应在 Azure 存储中创建映像 Blob 这一事件，可以创建一个缩略图。WebJobs SDK 以 .NET 控制台应用程序的方式运行，可以部署到 WebJob。
WebJobs 和 WebJobs SDK 在一起使用时效果最佳，但也可在没有 WebJobs SDK 的情况下使用 WebJobs，反之亦然。 WebJob 可以运行任何在应用服务沙盒中运行的程序或脚本。 WebJobs SDK 控制台应用程序可以在运行控制台应用程序的任何位置运行，例如本地服务器。
比较表
Azure Functions 是在 WebJobs SDK 上构建的，因此共享许多相同的事件触发器以及到其他 Azure 服务的连接。 在选择 Azure Functions 还是选择带 WebJobs SDK 的 WebJobs 时，请考虑下面一些因素：
1 WebJobs（不带 WebJobs SDK）支持 C#、JavaScript、Bash、.cmd、.bat、PowerShell、PHP、TypeScript、Python 等。 这不是完整的列表；WebJob 可以运行任何程序或脚本，只要该程序或脚本可以在应用服务沙盒中运行。
2 WebJobs（不带 WebJobs SDK）支持 NPM 和 NuGet。
摘要
Azure Functions 可以改进开发人员工作效率，并提供更多的编程语言选项、更多的开发环境选项、更多的 Azure 服务集成选项，以及更多的定价选项。 大多数情况下，它是最佳选择。
下面两种情况最适合选择 WebJobs：
- 需要对侦听事件的代码（JobHost 对象）进行更多的控制。 若要在 host.json 文件中自定义 JobHost 行为，则 Functions 提供的方式有限。 有时候，需要执行的操作无法在 JSON 文件中通过字符串来指定。 例如，只有 WebJobs SDK 允许配置 Azure 存储的自定义重试策略。
- 你已经有需要为其运行代码片段的应用服务应用，且需要在同一 DevOps 环境中同时管理它们。
对于其他需要运行代码片段来集成 Azure 或第三方服务的情况，请选择 Azure Functions 而不是带 WebJobs SDK 的 WebJobs。
流(Flow)、逻辑应用(Logic Apps)、Functions 和 WebJobs 一起
不需只选择一项这样的服务；这些服务彼此集成，也与外部服务集成。
流可以调用逻辑应用。 逻辑应用可以调用函数，而函数也可以调用逻辑应用。 请参阅相关文档，例如，创建与 Azure 逻辑应用集成的函数。
随着时间的推移，Flow、逻辑应用和 Functions 之间的集成将得到进一步改进。 可以在某服务中构建一些项，并将其用于其他服务。
- 30 次浏览