SQL Server Reporting Services有序号么 sql server ha

转载

技术博客领航者 2024-01-07 19:20:50

文章标签 sqlserver 字符串转时间 sqlserver 客户端 文章分类 SQL Server 数据库

带有 SQL Server 的 Azure 虚拟机 (VM) 有助于降低高可用性和灾难恢复 (HADR) 数据库解决方案的成本。Azure 虚拟机支持大多数充当云解决方案和混合解决方案的 SQL Server HADR 解决方案。在仅包含 Azure 的解决方案中，整个 HADR 系统都在 Azure 中运行。而在混合配置中，解决方案的一部分在 Azure 中运行，另一部分则在组织的本地运行。Azure 环境具有灵活性，允许部分或完全迁移至 Azure，以满足 SQL Server 数据库系统对于预算和 HADR 的要求。

备注

Azure 具有用于创建和处理资源的两个不同部署模型：资源管理器部署模型和经典部署模型。这篇文章介绍如何使用这两种模型，但Microsoft 建议大多数最新部署使用 Resource Manager 模型。

有关部署类型，请参阅： https://aka.ms/AA6vwnq

了解对 HADR 解决方案的需求

有责任确保数据库系统拥有服务级别协议 (SLA) 要求的 HADR 功能。Azure 提供了高可用性机制，例如云服务的服务修复和虚拟机的故障恢复检测，但这一事实自身并不保证你能够达到所需 SLA 的要求。这些机制可以保护 VM 的高可用性，但不能保护在 VM 内部运行的 SQL Server 的高可用性。VM 联机并正常运行时，SQL Server 实例也可能会出故障。再者，即便是 Azure 提供的高可用性机制，也会在 VM 遇到从软件或硬件故障进行恢复、操作系统升级等事件时，为其留出可能较长的停机时间。

此外，使用称作异地复制的功能在 Azure 中实现的异地冗余存储 (GRS)，可能不适合作为数据库的灾难恢复解决方案。因为异地复制功能会异步发送数据，在发生灾难的情况下，最近的更新可能丢失。

数据和日志文件各自在不同磁盘上的情况下不支持异地复制部分中提供了有关异地复制限制的详细信息。
详细请参阅：https://aka.ms/AA6vwns

HADR 部署体系结构

Azure 支持的 SQL Server HADR 技术包括：

Always On 可用性组
Always On 故障转移群集实例
日志传送
使用 Azure Blob 存储服务执行 SQL Server 备份和还原
数据库镜像 - SQL Server 2016 中已弃用

可将多种技术配合使用，以实现具有高可用性和灾难恢复功能的 SQL Server 解决方案。根据所用技术的不同，混合部署可能需要使用 VPN 隧道连接 Azure 虚拟网络。以下部分显示了某些部署体系结构的示例。

仅限 Azure：高可用性解决方案

可针对在数据库级别具有 AlwaysOn 可用性组(称为可用性组)的 SQL Server 提供高可用性解决方案。还可以在具有 AlwaysOn 故障转移群集实例的实例级别创建高可用性解决方案。对于其他冗余，可以通过在故障转移群集实例上创建可用性组，在两个级别上创建冗余。

技术	示例体系结构
可用性组	在同一区域的Azure VM 中运行的可用性副本提供高可用性。需要配置域控制器VM，因为Windows故障转移群集需要Active Directory域。为了实现更高的冗余和可用性，Azure Vm 可以部署在不同的可用性区域，https://aka.ms/AA6vwnx中，如可用性组概述，https://aka.ms/AA6w3xl中所述。如果可用性组中的SQL Server Vm 部署在可用性区域中，请使用以下文章中所述的适用于侦听器的标准负载均衡器，https://aka.ms/AA6w3xn- AZURE SQL VM CLI，https://aka.ms/AA6w3xp & azure 快速入门模板，https://aka.ms/AA6w3xq 。有关详细信息，请参阅在 Azure 中配置可用性组 (GUI) ，https://aka.ms/AA6vwo2。
故障转移群集实例	可通过4种不同的方式创建需要共享存储的故障转移群集实例(FCI)。 1. 使用Windows Server 2016 在 Azure Vm 中运行的双节点故障转移群集存储空间直通 (S2D )， https://aka.ms/AA6vwpe提供基于软件的虚拟 SAN。 2. 使用高级文件共享，https://aka.ms/AA6w3z3 在Azure vm 中运行的双节点故障转移群集。高级文件共享是完全支持的、与故障转移群集实例完全支持的、低延迟文件共享。 3. 使用第三方群集解决方案支持的存储在 Azure Vm 中运行的双节点故障转移群集。有关使用 SIOS DataKeeper 的具体示例，请参阅使用故障转移群集和第三方软件 SIOS Datakeeper 的文件共享的高可用性，https://aka.ms/AA6vwph。 4. 通过 ExpressRoute 在具有远程iSCSI 目标共享块存储的 Azure Vm 中运行的双节点故障转移群集。例如，NetApp 专用存储 (NPS) 使用 Equinix 通过 ExpressRoute向Azuer VM 公开 iSCSI 目标。对于第三方共享存储和数据复制解决方案，如有任何关于在故障转移时访问数据的问题，请联系供应商。

Azure：灾难恢复解决方案

可将可用性组、数据库镜像或备份和还原与存储 Blob 配合使用，为 Azure 中的 SQL Server 数据库提供灾难恢复解决方案。

技术	示例体系结构
可用性组	可用性副本在Azure VM 中跨越多个数据中心运行以实现灾难恢复。这种跨区域解决方案可以防止站点完全中断。在某个区域内，所有副本应该位于同一云服务和同一VNet中。由于每个区域将有单独的VNet，因此这些解决方案需要VNet到VNet连接。有关详细信息，请参阅使用Azure门户配置VNet到VNet 连接，https://aka.ms/AA6w7bv。有关详细说明，请参阅在不同区域的Azure 虚拟机上配置SQL Server可用性组，https://aka.ms/AA6wezb。
数据库镜像	主体和镜像以及服务器在不同数据库中运行以实现灾难恢复。必须使用服务器证书进行部署。Azure VM上的SQL Server 2008 和 SQL Server 2008 R2 不支持SQL Server数据库镜像。
使用Azure Blob 存储服务进行备份和还原	生产数据库直接备份到不同数据中心内的Blob存储以实现灾难恢复。有关详细信息，请参阅Azure虚拟机中SQL Server 的备份和还原，https://aka.ms/AA6w3z7。
使用 Azure Site Recovery 将SQL Server 复制和故障转移到Azure	一个Azure数据中心的生产SQL Server 直接复制到其他Azure数据中心的Azure 存储以实现灾难恢复。有关详细信息，请参阅使用 SQL Server 灾难恢复和 Azure Site Recovery来保护 SQL Server，https://aka.ms/AA6vwpk。

混合

混合IT：灾难恢复解决方案

可将可用性组、数据库镜像、日志传送以及备份和还原与 Azure Blob 存储配合使用，在混合 IT 环境中为 SQL Server 数据库提供灾难恢复解决方案。

技术	示例体系结构
可用性组	某些可用性副本运行在 Azure VM 中，另一些则在本地运行，以实现跨站点灾难恢复。生产站点可位于本地，也可以位于 Azure 数据中心。由于所有可用性副本必须在同一故障转移群集中，因此该群集必须同时跨越这两个网络(多子网故障转移群集)。此配置需要在 Azure 与本地网络之间使用VPN 连接。为了成功地对数据库进行灾难恢复，还应在灾难恢复站点上安装副本域控制器。可以使用SSMS中的“添加副本向导”将Azure 副本添加到现有的Always On可用性组。有关详细信息，请参阅教程“将 Always On 可用性组扩展到Azure中”。
数据库镜像	一个伙伴在Azure VM 中运行，另一个则在本地运行，以实现使用服务器证书进行跨站点灾难恢复。合作伙伴不必在同一 Active Directory 域中，并且不需要 VPN 连接。另一种数据库镜像方案是一个合作伙伴在Azure VM中运行，另一个则在同一Active Directory 域中本地运行，以实现跨站点灾难恢复。需要在Azure虚拟网络与本地网络之间使用 VPN 连接，详情参阅，https://aka.ms/AA6wezc。为了成功地对数据库进行灾难恢复，还应在灾难恢复站点上安装副本域控制器。Azure VM 上的SQL Server 2008和SQL Server 2008 R2不支持SQL Server 数据库镜像。
日志传送	一个服务器在Azure VM中运行，另一个则在本地运行，以实现跨站点灾难恢复。日志传送依赖于Windows文件共享，因此需要在Azure虚拟网络与本地网络之间使用VPN连接。为了成功地对数据库进行灾难恢复，还应在灾难恢复站点上安装副本域控制器。
使用Azure Blob存储服务进行备份和还原	本地生产数据库直接备份到Azure Blob存储以实现灾难恢复。有关详细信息，请参阅Azure虚拟机中SQL Server的备份和还原，https://aka.ms/AA6w7bw。
使用Azure Site Recovery将SQL Server复制和故障转移到Azure	本地生产SQL Server直接复制到Azure存储以实现灾难恢复。有关详细信息，请参阅使用SQL Server 灾难恢复和Azure Site Recovery来保护SQL Server， https://aka.ms/AA6wezf。

有关

Azure中的SQL Server HADR的重要注意事项

Azure VM、存储和网络的运行特征与本地非虚拟化的 IT 基础结构不同。需要了解这些区别并设计可适应这些区别的解决方案，才能成功地在 Azure 中实现 HADR SQL Server 解决方案。

可用性集中的高可用性节点

使用 Azure 中的高可用性集，可将高可用性节点放置在单独的容错域 (FD) 和更新域 (UD) 中。基础 Azure 平台为可用性集中的每个虚拟机分配一个更新域和一个容错域。数据中心内的这种配置可以确保在发生计划内或计划外维护事件时，至少有一个虚拟机可用，并满足 99.95% 的 Azure SLA 要求。若要配置高可用性设置，请将所有参与的 SQL 虚拟机放置在同一可用性集中，以避免在维护事件期间应用程序或数据丢失。只有同一云服务中的节点可加入同一可用性集。

有关详细信息，请参阅管理虚拟机的可用性：https://aka.ms/AA6w7c5

可用性区域中的高可用性节点

可用性区域是Azure区域中独特的物理位置。每个区域由一个或多个数据中心组成，这些数据中心配置了独立电源、冷却和网络。区域内可用性区域的物理分离可确保至少有一个虚拟机可用，并满足99.99% 的Azure SLA要求，从而保护应用程序和数据免受数据中心故障的影响。若要配置高可用性，请将参与的SQL虚拟机分散到该区域中的可用可用性区域。会产生可用性区域间VM到VM的数据传输费用。

有关详细信息，请参阅可用性区域： https://aka.ms/AA6w7c6

故障转移群集在Azure网络中的行为

Azure中的DHCP服务不符合RFC标准，可能会导致创建某些故障转移群集配置失败，因为向群集网络名称分配了重复的 IP 地址(例如 IP 地址与某个群集节点相同)。实现可用性组时，这种情况会产生一个问题，因为它依赖于Windows故障转移群集功能。

创建两节点群集并使其联机时，请考虑此应用场景：

· 群集联机，NODE1会为群集网络名称请求一个动态分配的IP地址。

· DHCP服务除了NODE1自身的IP地址以外不提供任何 IP地址，因为DHCP服务识别出请求来自NODE1自身。

· Windows检测到同时向NODE1和故障转移群集网络名称分配了一个重复的地址，并且默认群集组未能联机。

· 默认群集组移至NODE2，后者将NODE1的IP地址视为群集IP地址，并使默认群集组联机。

· 当NODE2尝试与NODE1建立连接时，在NODE1上定向的数据包从不离开NODE2，因为后者将NODE1的 IP 地址解析为其自身。NODE2无法与NODE1建立连接，丢失仲裁并关闭群集。

· 同时，NODE1可向NODE2发送数据包，但NODE2无法回复。NODE1丢失仲裁并关闭群集。

可通过将未使用的静态 IP 地址(如 169.254.1.1 等链接本地 IP 地址)分配给群集网络名称，让群集网络名称联机，从而避免这种情况发生。

若要简化此过程，请参阅在 Azure 中针对可用性组配置 Windows 故障转移群集，https://aka.ms/AA6wezu。

有关详细信息，请参阅在 Azure 中配置可用性组 (GUI)，https://aka.ms/AA6w7cc。

可用性组侦听器支持

运行 Windows Server 2008 R2、Windows Server 2012、Windows Server 2012 R2和Windows Server 2016的 Azure VM支持可用性组侦听器。这种支持的实现，是借助于在 Azure VM上启用的负载均衡终结点，它们都是可用性组节点。必须执行特殊的配置步骤，才能让这些侦听器对在Azure中运行和本地运行的客户端应用程序都有效。

有两个主要选项用于设置侦听器：“外部(公共)”或“内部”。外部(公共)侦听器使用面向Internet的负载均衡器并与可通过 Internet访问的公共虚拟IP (VIP)相关联。内部侦听器使用内部负载均衡器，且仅支持同一虚拟网络中的客户端。对于任一负载均衡器类型，都必须启用直接服务器返回。

如果可用性组跨多个Azure子网(例如，跨 Azure 区域的部署)，则客户端连接字符串必须包含“MultisubnetFailover=True”。这会导致与不同子网中的副本建立并行连接。

有关设置侦听器的说明，请参阅：

在 Azure 中配置可用性组的 ILB 侦听器，https://aka.ms/AA6vwpt
在 Azure 中配置可用性组的外部侦听器，https://aka.ms/AA6vwpu

仍可通过直接连接到服务实例，单独连接到每个可用性副本。此外，由于可用性组与数据库镜像客户端向后兼容，因此可以像数据库镜像伙伴一样连接到可用性副本，只要这些副本配置得类似于数据库镜像即可：

一个主副本和一个辅助副本
将辅助副本配置为不可读(“可读辅助副本”选项设置为“否”)

下面是一个示例客户端连接字符串，它对应于这个使用 ADO.NET 或 SQL Server 本机客户端的类似于数据库镜像的配置：

复制

Data Source=ReplicaServer1;Failover Partner=ReplicaServer2;Initial Catalog=AvailabilityDatabase;

有关客户端连接的详细信息，请参阅：

将连接字符串关键字用于 SQL Server 本机客户端，https://aka.ms/AA6vwpw
将客户端连接到数据库镜像会话 (SQL Server)，https://aka.ms/AA6vwpx
在混合 IT 环境中连接到可用性组侦听器，https://aka.ms/AA6wf01
可用性组侦听器、客户端连接和应用程序故障转移 (SQL Server)，https://aka.ms/AA6wf03
将数据库镜像连接字符串用于可用性组，https://aka.ms/AA6wf05

混合 IT 环境中的网络延迟

在部署HADR解决方案时，应该假设本地网络和Azure之间可能存在很高的网络延迟。将副本部署到Azure时，同步模式应使用异步提交而非同步提交。同时在本地和Azure中部署数据库镜像服务器时，请使用高性能模式，而非高安全模式。

异地复制支持

Azure 磁盘中的异地复制不支持将同一数据库的数据文件和日志文件各自存储在不同的磁盘上。GRS独立并异步地复制对每个磁盘的更改。此机制保证单个磁盘中异地复制副本上的写顺序，但不保证多个磁盘的异地复制副本上的写顺序。如果将数据库配置为将其数据文件和其日志文件各自存储在不同的磁盘上，则灾难后恢复的磁盘所含的数据文件副本可能比日志文件副本新，而这违反 SQL Server中的预写日志以及事务的ACID属性。如果无法对存储帐户禁用异地复制，则应将给定数据库的所有数据和日志文件都保留在同一磁盘上。如果因数据库较大而必须使用多个磁盘，则需要部署上面列出的某个灾难恢复解决方案以确保数据冗余。

后续步骤参阅

如果需要创建使用SQL Server的Azure虚拟机，请参阅在 Azure 上预配 SQL Server 虚拟机，https://aka.ms/AA6wf06。

若要使 Azure VM上运行的SQL Server保持最佳性能，请参阅Azure虚拟机中 SQL Server的性能最佳实践中的指导，https://aka.ms/AA6w7ci。

有关其他与在Azure VM中运行SQL Server相关的主题，请参阅SQL Server>(Azure 虚拟机上的 SQL Server)，https://aka.ms/AA6wf09。