SQLServerAlwaysOn架构及原理.doc

SQL Server AlwaysOn架构及原理 SQL Server2012所支持的AlwaysOn技术集中了故障转移群集、数据库镜像和日志传送三者的优点，但又不相同。故障转移群集的单位是SQL实例，数据库镜像和日志传送的单位是单个用户数据库，而AlwaysOn支持的单位是可用性组，每个组中可以包括一个或者是多个用户数据库。也就是说，一旦发生切换，则可用性组中的所有数据组会作为一个整体进行切换。 ? ?AlwaysOn底层依然采用Windows 故障转移群集的机制进行监测和转移，因此也需要先建立Windows Cluster，只不过可用性组中的数据库不一定非要再存放在共享存储上了。可以是存储在本地磁盘上。 ? ?AlwaysOn的关键特性： ? ?1. 同故障转移群集一样，也需要一个虚拟网络名称用于客户端的统一连接。 ? ?2.一个主服务器可以最多对应四个辅助服务器，总数达到五个，而且辅助服务器支持只读功能。 ? ?3.辅助服务器可以独立执行备份和DBCC维护命令。通过配置，可以实现客户端的只读请求可以被自动定向到辅助服务器。 ? ?4.主服务器和辅助服务器之间的数据会被加密和压缩，以提高安全性和网络传输效率。 ? ?5..支持自动、手动和强制三种故障转移方式。 ? ?6.有仪表盘用于监控AlwaysOn的运行状态。 ? ?7.可以实现多站点的部署，即主站点和辅助站点可以跨物理网络。 AlwaysOn的基本架构 ? ?在Windows MSCS故障转移群集的基础上部署AlwaysOn高可用组，用户可以在群集节点上安装SQL Server单机实例，也可以安装SQL Server群集实例，AlwaysOn仅要求所有SQL Server实例都运行在同一个MSCS中，但SQL Server实例本身是不需要群集模式的，这与SQL Server2008 群集的实例完全不同。在此推荐使用单机模式的SQL Server，好处是：可用性副本是个单机实例，那么数据库副本就存放在该运行该实例节点的本地磁盘上；如果可用性副本是个群集实例，那么数据库副本就存放在共享磁盘上。 ? ?可用性组从Windows群集角度来看，就是一个群集资源，其中的所有数据库作为一个整体在节点间进行故障转移，当然这不包括系统数据库，系统数据库是不能加入高可用性组中的。 ? ?因为需要借助Windos群集实现监控和转移，所以AlwaysOn会受到一些限制： ? ?一个可用性组中的所有可用性副本必须运行在单一的Windows群集上，跨不同Windows群集的SQL Server实例不能配置成一个AlwaysOn可用性组。 ? ?一个可用性组的所有可用性副本必须运行在Windows群集的不同节点上。运行在同一个节点上的两个不同实例不能用作同一个可用性组的副本。 ? ?如果某个可用性副本实例是一个SQL群集实例，那同一个SQL群集的其他非活跃节点上安装的任何其他SQL实例都不能作为它的辅助副本。 ? ?一个数据库只能属于一个可用性组。 ? ?AlwaysOn最多可以支持五个副本，但只有一个可用性副本上运行的数据库是处于可读写状态。这个可读写的数据库被称为主数据库（PrimaryDatabase），同时这个可用性副本被称为主副本（primaryreplica）。其余的副本都被称为辅助副本（secondaryreplica），辅助副本上的数据库可能是不可访问的，或者是只能接受只读操作（取决于可用性组的配置），这些数据库被称为辅助数据库。一但发生故障转移，任何一个辅助副本都可以成为新的主副本实例。主副本会不断地将主数据库上的数据变化发送到辅助副本，来实现副本间的数据库同步。下图就显示了一个可用性组中各副本之间的关系。 下图展示了AlwaysOn可用性组与Windows故障转移群集之间的关系，在这个图中，Windows的故障转移群集使用到了两个子网，在左边的子网里，有两个节点 ；右边的子网里有三个节点，其中最右边两个节点上创建了一个SQL Server的群集实例，存放于共享存储；其他三个节点安装的是单机实例，存放于本地存储；一共四个实例组成了一个AlwaysOn可用性组，其中一个主副本，其他的都是辅助副本。 侦听器 ? ?AlwaysOn创建后，客户端就需要进行连接，为了让应用程序能够透明地连接到主副本而不受故障故障转移的影响，我们需要创建一个侦听器，侦听器就是一个虚拟的网络名称，可以通过这个虚拟网络名称访问可用性组，而不用关心连接的是哪一个节点，它会自动将请求转发到主节点，当主节点发生故障后，辅助节点会变为主节点，侦听器也会自动去侦听主节点。 一个侦听器包括虚拟IP地址、虚拟网络名称、端口号三个元素，一旦创建成功