数据库集群实施方案.docx
《数据库集群实施方案.docx》由会员分享，可在线阅读，更多相关《数据库集群实施方案.docx（14页珍藏版）》请在冰豆网上搜索。
数据库集群实施方案
-本页仅作为预览文档封面，使用时请删除本页-
数据库集群实施方案（总11页）
数据库集群实施方案
柳州东投数据库系统配置实施文档技术背景数据库系统安全性安全性介绍数据库系统安全是指为数据库系统采取的安全保护措施，防止系统软件和其中数据不遭到破坏、更改和泄漏。
数据库安全的核心和关键是其数据安全。
数据安全是指以保护措施确保数据的完整性、保密性、可用性、可控性和可审查性。
由于数据库存储着大量的重要信息和机密数据，而且在数据库系统中大量数据集中存放，供多用户共享，因此，必须加强对数据库访问的控制和数据安全防护。
数据库系统安全的层次与结构一般数据库系统安全涉及5个层次：
（1）用户层：
侧重用户权限管理及身份认证等，防范非授权用户以各种方式对数据库及数据的非法访问；
（2）物理层：
系统最外层最容易受到攻击和破坏，主要侧重保护计算机网络系统、网络链路及其网络节点的实体安全；（3）网络层：
所有网络数据库系统都允许通过网络进行远程访问，网络层安全性和物理层安全性一样极为重要；（4）操作系统层：
操作系统在数据库系统中，与DBMS交互并协助控制管理数据库。
操作系统安全漏洞和隐患将成为对数据库进行非授权访问的手段；（5）数据库系统层：
数据库存储着重要程度和敏感程度不同的各种数据，并为拥有不同授权的用户所共享，数据库系统必须采取授权限制、访问控制、加密和审计等安全措施。
为了确保数据库安全，必须在所有层次上进行安全性保护措施。
若较低层次上安全性存在缺陷，则严格的高层安全性措施也可能被绕过而出现安全问题。
数据库系统安全解决方案概述环境安全环境安全是指数据库所运行的软硬件环境的安全控制。
正确的架构设计是数据库及其他应用稳定、安全的运行最有力保障，一个正确的架构设计可以较好的体现在物理环境中，通过比较简单的对物理环境的设定，就可以屏蔽大量的安全隐患。
错误的架构设计会导致物理结构散乱，无论从运维还是管理上来说，都有相当大的困难，较多的物理漏洞必须通过繁杂的软件安全控制来屏蔽风险，抛开安全本身无法较好保证而言，更换服务器时对软件的设置相当困难。
软硬件架构按照较大的框架进行分割，我们可以知道任何安全的架构都是传统三层架构的扩展，根本还是在于表示层，业务逻辑层，数据访问层，对于数据库看来则是应用层，中间层，数据层。
逻辑上实现三层架构比较容易，在软件中分离数据访问即可，但是往往我们都忽略了物理三层架构的设置，很多系统往往在软件上实现了三层架构，但是对应的三层架构缺共同存储与一台设备上，这是比较危险的做法，当然从成本出发这是比较节省的方案，存在的问题也显而易见，管理混乱，安全性降低，如果系统没有做好较好的安全控制，那么这个系统就会形成一通百通的局面。
不过成本、效率、高可用性永远是软件系统的铁三角，不同的系统对三者的要求也不一样，我们刚才说到的物理三层结构从成本上来说是最高的，但是大大提高了效率和高可用性中的安全性与稳定性。
数据库架构数据库自身也是一个应用软件，自身也分为三层架构，应用层，交换层，数据层。
如何使数据库具有高效性，高可用性是数据库运维中的重点。
一般来说负荷较大的应用系统都会使用共享存储的模式将数据存储剥离开来，应用服务本身则是使用负载均衡的模式进行部署。
这样的好处是结构清晰可靠，高可用，高性能，数据库可快速或无缝切换，但是相对其他普通方案而言成本较高。
物理访问控制物理访问控制主要是指在现实世界中对服务器、数据存储的访问控制。
物理访问控制主要出现在自建机房中，因托管机房访问控制是由托管服务提供商完成的。
主要的物理访问控制机制要满足，可审计性，非单一性，访问限制等条件。
访问限制：
通过各类门禁隔绝非相关人员。
非单一性：
进入核心机房任何情况下必须有两人同行。
可审计性：
对于一切操作（包括进出机房，操作数据等）必须留下操作痕迹。
操作系统设置操作系统是安装数据库应用服务的基础，很难想象一个不健康的操作系统之上能够运行一个稳定高效的数据库服务。
在操作系统的层面，就安全而言主要还是控制非法终端绕过中间层对数据库进行直接访问。
其主要方法有：
1、数据库系统的宿主操作系统除提供数据库服务外，不得提供其它网络服务，这主要是为了尽量减少端口开放数量以及访问量。
2、应在宿主操作系统中设置本地数据库专用帐户，并赋予该账户除运行各种数据库服务外的最低权限；3、对数据库系统安装目录及相应文件访问权限进行控制，如：
禁止除专用账户外的其它账户修改、删除、创建子目录或文件。
网络安全控制应用系统及数据库系统的网络安全控制其实类似于操作系统安全控制，核心内容是通过网络技术，分割物理或虚拟网络，并通过限制端口，限制访问终端，甚至限制访问内容，从而使非法终端不能绕过中间层直接连接到数据库或直接访问底层数据。
建设思路：
所有独立的数据库应用均只能由指定的前端代理、HA或中间层服务器进行访问，其他机器均不能访问数据库服务以及相应端口。
为方便运维人员进行日常维护，可添加一至两台安全性较高的终端进入可访问列表，进行日常维护。
如能充分保证内网内其他机器的安全性，可适当降低该数据库访问列表权限，使内网均可访问。
应用安全应用安全是泛指与数据库自身相关联的各种应用与设置安全，包括数据账户控制，数据库应用控制，数据库应用规范等。
数据库在安装成功后首先应该对数据库进行安全设置与性能调校，然后导入或新建数据库实例（非实例类为库），并制定相应的数据库操作、开发、维护规范，形成有效的管理机制，对于多实例对方案运行的数据库，必须针对不同的数据实例针对性地写出相应的巡检计划与警告、异常阀值，减少数据库因宕机造成的安全异常。
账户控制帐户安全和口令策略是任何应用系统安全控制的核心机制，数据库也不例外。
账户设置原则严禁不同的数据库系统使用相同的账户与口令；重新命名数据库管理员帐户；数据库应用账户必须与数据库管理员帐户分离；删除或停用不需要的默认账户以及空账户。
账户分离原则系统管理员：
能够管理数据库系统中的所有组件及数据库；应用数据库管理员：
能够管理本数据库中的账户、对象及数据；数据库应用用户：
只能以特定的权限访问特定的数据库对象，不具有数据库管理权限。
权限控制原则针对每个数据库账户按最小权限原则设置其在相应数据库中的权限；系统管理权限：
账户管理、服务管理、数据库管理等；数据库管理权限：
包括创建、删除、修改数据库等；数据库访问权限：
包括插入、删除、修改数据库特定表记录等。
使用数据库系统分配账户的方式鉴别数据库用户，不可使用宿主操作系统的账户鉴别代替数据库账户鉴别。
注：
较高安全等级的数据库一般来说只给用户提供调用特定存储过程和函数的权限，该用户本身对数据库对象不可见。
应用控制数据库应用控制是指应用系统或管理维护人员在操作数据库时的安全控制。
相关应用系统以及管理员必须使用满足操作条件的最小权限用户接入数据库。
数据库操作人员在操作数据库时，必须留有痕迹，最好是记录详尽的操作细节。
应用系统在开发中，最好对流程性对象（存储过程，函数等）中所做的对数据库数据有增、删、改的操作留下记录，写入相应的事件表。
流程性对象在开发完毕后应给予应用用户调用权限，并对对象本身进行封装加密，防止结构泄露。
操作系统管理员与数据库管理员原则上不应为同一人（SQLSERVER除外），任何应用系统都应该制定审计制度，负责审计数据库操作。
应用系统接入数据库时的所有的连接串必须通过可更改的参数文件获取相关连接信息，不允许在程序开发中直接写入数据库相关信息。
所有数据库所执行的应用级操作均不得使用管理员账户进行操作，管理员账户仅仅用于数据库管理员进行维护、调优、与其他设置类操作。
针对于较高安全等级的数据库，数据库操作应尽量封装在流程性对象中，这样对安全性、高效性、可审计性都有极大提升。
前端应用使用数据库时，只通过调用流程性对象完成。
禁止未授权的数据库系统远程管理访问，对于已经批准的远程管理访问，应采取安全措施增强远程管理访问安全，对于高级应用应修改数据库服务端口。
数据库规范数据库规范是我们安全、高效地使用数据库的有力保障，也是我们快速查找问题，减少维护压力强有力的工具。
针对不同的数据库与应用系统在效能、安全、高可用性上有不同的要求。
数据库工程师在制定数据库应用规范框架时，应保障各系统通用性与良好的扩展性。
根据数据库应用规范框架，对每个数据库系统最好建立独立的数据库规范文档，包括命名规范，操作规范，用户管理规范、运行维护规范等。
操作人员在对数据库进行维护，调优及其他操作时必须按照“规范”中描述的内容进行操作，并予以记录。
下级规范的制定必须定位于总体规范框架之内，如与规范框架有冲突，应及时对框架进行评估，并进行调整。
数据安全数据安全范围比较大，概括来说可以包含：
数据物理文件安全，系统冗余、容错，数据备份恢复等。
数据安全的中心思想就是如何保证数据文件本身的安全及如何减少数据库中的脏数据问题。
数据库往往是一个应用系统的核心系统，而数据库的核心也就是数据库中的数据，如何保障数据文件的安全稳定是数据库最为重要又最为薄弱的一环。
同时，正确的数据可以让数据库稳定地运行，过多的错误数据不但影响用户正常使用，也会降低数据库运行效率，还可能导致数据库服务停机，更为严重的是感染正确数据，如何避免错误数据的产生产生错误数据后如何进行清洗这些问题都是数据库开发、应用中经常碰到的问题。
数据文件安全数据文件是指存放电子数据的物理文件。
核心操作系统安全控制物理文件拷贝复制管理内外网文件传递管理防火墙过滤关键字
数据库应用安全管理我们通过以上形式来提升数据文件的安全系数，从根本上来说也就是通过“环境安全”与“应用安全”实现了数据文件安全。
数据备份恢复数据备份及恢复在数据库系统每次成功升级后，数据库管理员都应备份相应的数据库系统软件；数据库管理员应制定数据备份计划，并按照计划定期备份数据库系统中的数据，妥善安全保存这些备份数据，防止备份数据的丢失、泄露与被篡改。
系统及数据恢复，要求数据库管理员应制定数据库系统及数据恢复流程，并至少对恢复流程作三次演练。
系统冗余、容错数据库系统冗余是指对数据库服务以及核心数据通过冗余的方式，提高系统的稳定性。
其主要实现手段还是使用各种集群服务通过共享存储的形式使用数据库。
容错这里主要指除开系统冗余之外的软件自身容错，比如异常的判定，预期异常的排除，错误代码处理，通过进行容错处理，可以降低系统以及数据库运行时产生错误的几率与错误数据产生几率，从而使系统更为稳定的运行。
注：
数据库容错方面最好使用强判定模式，弱判定模式比较容易形成错误数据以及异常。
SQLserver2012高可用性高可用性介绍自从SQLServer2005以来，微软已经提供了多种高可用性技术来减少宕机时间和增加对业务数据的保护，而随着SQLServer2008，SQLServer2008R2，SQLServer2012的不断发布，SQLServer中已经存在了满足不同场景的多种高可用性技术。
在本项目组中，我们期待创建一个任何时刻都在线的数据库系统。
但由于各种各样的因素，无法预估的灾难，需要提前采取各种措施来预防突发情况。
微软的SQLServer提供了多种高可用性技术，这些技术主要包括：
集群、复制、镜像、日志传送、AlwaysOn可用性组以及其它诸如文件组备份还原、在线重建索引等单实例的高可用性技术。
数据库高可用设计遵循的原则RTO（RecoveryTimeObjective）
恢复时间目标，意味着允许多少宕机时间，通常用几个9表示，比如说%的可用性意味着每年的宕机时间不超过5分钟、%的可用性意味着每年的宕机时间不超过分钟、%的可用性意味着每年的宕机时间不超过小时。
值得注意的是，RTO的计算方法要考虑系统是24*365，还是仅仅是上午6点到下午9点等。
您还需要注意是否维护窗口的时间在算在宕机时间之内，如果允许在维护窗口时间进行数据库维护和打补丁，则更容易实现更高的
可用性。
RPO（RecoveryPointObjective）
恢复点目标，意味着允许多少数据损失。
通常只要做好备份，可以比较容易的实现零数据损失。
但当灾难发生时，取决于数据库损坏的程度，从备份恢复数据所需要的时间会导致数据库不可用，这会影响RTO的实现。
一个早期比较着名的例子是某欧美的银行系统，只考虑的RPO，系统里只存在了完整备份和日志备份，每3个月一次完整备份，每15分钟一次日志备份，当灾难发生时，只能够通过完整备份和日志备份来恢复数据，因此虽然没有数据丢失，但由于恢复数据花了整整两天时间，造成银行系统2天时间不可用，因此流失了大量客户。
另外一个相反的例子是国内某在线视频网站，使用SQLServer作为后端关系数据库，前端使用了No-SQL，定期将No-SQL的数据导入关系数据库作为备份，当灾难发生时最多允许丢失一天的数据，但是要保证高可用性。
预算RTO和RPO统称为SLA（服务水平协议），设计高可用性策略时，要根据业务来衡量满足何种程度的SLA，这要取决于预算以及衡量不同SLA在故障时所造成的损失。
SLA并不是越高越好，而是要基于业务需求，通常来说，在有限的预算之下很难实现很高的SLA，并且即使通过复杂的架构实现较高的SLA，复杂的架构也意味着高运维成本，因此需要在预算范围之内选择合适的技术来满足SLA。
SQLServer高可用性解决方案概述SQLServer的高可用性方案有以下几种方式来实现：
故障转移集群故障转移集群为整个SQLServer实例提供高可用性支持，这意味着在集群上某个节点的SQLServer实例发生了硬件错误、操作系统错误等会故障转移到该集群上的其它节点。
通过多个服务器（节点）共享一个或多个磁盘来实现高可用性，故障转移集群在网络中出现的方式就像单台计算机一样，但是具有高可用特性。
值得注意的是，由于故障转移集群是基于共享磁盘，因此会存在磁盘单点故障，因此需要在磁盘层面部署SAN复制等额外的保护措施。
最常见的故障转移集群是双节点的故障转移集群，包括主主节点和主从节点。
事务日志传送事务日志传送提供了数据库级别的高可用性保护。
日志传送可用来维护相应生产数据库（称为“主数据库”）的一个或多个备用数据库（称为“辅助数据库”）。
发生故障转移之前，必须通过手动应用全部未还原的日志备份来完全更新辅助数据库。
日志传送具有支持多个备用数据库的灵活性。
如果需要多个备用数据库，可以单独使用日志传送或将其作为数据库镜像的补充。
当这些解决方案一起使用时，当前数据库镜像配置的主体数据库同时也是当前日志传送配置的主数据库。
事务日志传送可用于做冷备份和暖备份的方式。
数据库镜像数据库镜像实际上是个软件解决方案，同样提供了数据库级别的保护，可提供几乎是瞬时的故障转移，以提高数据库的可用性。
数据库镜像可以用来维护相应生产数据库（称为“主体数据库”）的单个备用数据库（或“镜像数据库”）。
因为镜像数据库一直处于还原状态，但并不会恢复数据库，因此无法直接访问镜像数据库。
但是，为了用于报表等只读的负载，可创建镜像数据库的数据库快照来间接地使用镜像数据库。
数据库快照为客户端提供了快照创建时对数据库中数据的只读访问。
每个数据库镜像配置都涉及包含主体数据库的“主体服务器”，并且还涉及包含镜像数据库的镜像服务器。
镜像服务器不断地使镜像数据库随主体数据库一起更新。
数据库镜像在高安全性模式下以同步操作运行，或在高性能模式下以异步操作运行。
在高性能模式下，事务不需要等待镜像服务器将日志写入磁盘便可提交，这样可最大程度地提高性能。
在高安全性模式下，已提交的事务将由伙伴双方提交，但会延长事务滞后时间。
数据库镜像的最简单配置仅涉及主体服务器和镜像服务器。
在该配置中，如果主体服务器丢失，则该镜像服务器可以用作备用服务器，但可能会造成数据丢失。
高安全性模式支持具有自动故障转移功能的备用配置高安全性模式。
这种配置涉及到称为“见证服务器”的第三方服务器实例，它能够使镜像服务器用作热备份服务器。
从主体数据库至镜像数据库的故障转移通常要用几秒钟的时间。
数据库镜像可用于做暖备份和热备份。
复制复制严格来说并不算是一个为高可用性设计的功能，但的确可以被应用于高可用性。
复制提供了数据库对象级别的保护。
复制使用的是发布-订阅模式，即由主服务器（称为发布服务器）向一个或多个辅助服务器或订阅服务器发布数据。
复制可在这些服务器间提供实时的可用性和可伸缩性。
它支持筛选，以便为订阅服务器提供数据子集，同时还支持分区更新。
订阅服务器处于联机状态，并且可用于报表或其他功能，而无需进行查询恢复。
SQLServer提供四种复制类型：
快照复制、事务复制、对等复制以及合并复制。
AlwaysOnAlwaysOn故障转移群集实例利用WindowsServer故障转移群集（WSFC）功能通过冗余在服务器实例级别（故障转移群集实例（FCI））提供了本地高可用性。
FCI是在WindowsServer故障转移群集（WSFC）节点上和（可能）多个子网中安装的单个SQLServer实例。
在网络上，FCI表现得好像是在单台计算机上运行的SQLServer实例，但它提供了从一个WSFC节点到另一个WSFC节点的故障转移（如果当前节点不可用）。
当服务器上出现硬件或软件故障时，连接到该服务器的应用程序或客户端将会停机。
在将SQLServer实例配置为FCI（而非独立实例）时，该SQLServer实例的高可用性受到FCI中提供的冗余节点的保护。
在FCI中，一次只能有一个节点拥有WSFC资源组。
在出现故障（硬件故障、操作系统故障、应用程序或服务故障）或进行计划的升级时，该资源组的所有权就会转移至另一个WSFC节点。
此过程对于连接到SQLServer的客户端或应用程序是透明的，可以最大限度地缩短出现故障时应用程序或客户端的停机时间。
故障转移群集实例提供的一些主要优点：
通过冗余提供实例级的保护在出现故障（硬件故障、操作系统故障、应用程序或服务故障）时自动进行故障转移支持多种存储解决方案，包括WSFC群集磁盘（iSCSI、光纤信道等）和服务器消息块（SMB）文件共享使用多子网FCI或在AlwaysOn可用性组中运行FCI托管数据库的灾难恢复解决方案。
利用MicrosoftSQLServer2012中的新的多子网支持功能，多子网FCI不再需要虚拟LAN，因此可提高多子网FCI的可管理性和安全性故障转移过程中无需重新配置应用程序和客户端用于实现自动故障转移的针对具体触发器事件的灵活的故障转移策略通过使用专用和持久的连接执行定期的详细运行状况检测，实现可靠的故障转移通过间接后台检查点在故障转移期间实现可配置性和可预测性故障转移期间限制对资源的使用AlwaysOn可用性组基于数据库（组）级别，是将一组用户数据库（可以是一个或多个）划到一个组中。
每组可用性数据库都由一个可用性副本承载。
可用性副本包括一个主副本和一到四个辅助副本。
主副本用于承载主数据库，辅助副本则承载一组辅助数据库并作为可用性组的潜在故障转移目标。
主副本使主数据库可用于客户端的读写连接，实现对数据库的更改操作。
同时在数据库级别进行同步。
主副本将每个主数据库的事务日志记录发送到每个辅助数据库。
每个辅助副本缓存事务日志记录，然后将它们还原到相应的辅助数据库。
主数据库与每个连接的辅助数据库独立进行数据同步。
因此，一个辅助数据库可以挂起或失败而不会影响其他辅助数据库，一个主数据库可以挂起或失败而不会影响其他主数据库。
此外，用户可以借助辅助数据库来实现近实时的报表查询，将查询的负载分担到只读副本。
相对于数据库群集及镜像来说，可以更好的利用硬件资源，从而提高IT效率并降低成本。
数据库系统实施方案技术方案概述考虑到本项目的需求和最佳性能，为了达到最佳可用性，方案采用两台数据库服务器做故障转移集群，连接同一台存储做数据库的共享存储，实现故障自动转移。
数据库系统处于单独一个VLAN，与其他系统默认进行网络隔离。
通过交换机访问规则，控制业务系统与数据库系统的访问，提升系统的安全性。
规划部署图数据库服务器数据库服务器云服务器主域控制器云服务器副域控制器磁盘阵列核心交换机环境要求硬件要求序号名称数量配置要求备注1主域控制器1CPU双核，8G内存，100G硬盘云主机2副域控制器1CPU双核，8G内存，100G硬盘云主机3数据库服务器24颗Intel10核处理器XeonE7-4830v2，内存64GB华为RH5885V34磁盘柜18个8GFC和8个10GE前端主机接口；8个磁盘通道华为OceanStor5800V3
软件要求序号名称数量配置要求备注1操作系统4WindowsServer2012R2标准版
2数据库软件2SQLServer2012企业版
网络环境要求1.安装实施期间，服务器要求能实现互联网访问。
2.运行维护期间，仅允许应用服务器IP访问数据库服务端口；仅允许数据库服务器访问域控制器服务器；禁止其余出站访问。
IP地址划分
节点一节点二外网地址/2/24网关.心跳地址/30/30群集地址/24MSDTC地址/24SQLServer地址/24主域服务器地址/24（以实际为准）副域控制器地址/24（以实际为准）首选DNS服务器（以实际为准）备用DNS服务器（以实际为准）实施步骤故障转移集群的前提条件
使用Windows域帐户
基于WindowsServerFail-overCluster
共享存储至少提供一个LUN，数据库文件（mdf/ndf/ldf）将安装在该LUN
SQLServer标准版/商业智能版（仅直接2个节点），或者企业版/数据中心版本（最多16个节点）
部署SQLServer群集的步骤
确认WindowsFail-overCluster
安装MSDTC（推荐）
安装单节点的SQLServerFail-overCluster
向SQLServerFail-overCluster添加节点
数据库运维运行监控备份策略应急恢复附件：
数据库集群部署操作文档Windowsserver2012系统主域的安装配置配置IP地址和DNS以及属性设置
关闭防火墙
域功能的添加打开服务器管理中的仪表板点“添加角色和功能”
点“下一步”
点“下一步”
选择本机服务器名称点“下一步”
把ActiveDirectory域服务勾选点“下一步”
什么都不选，点“下一步”
点“下一步”
点“安装”
域功能的安装域功能添加完成后不关闭此窗口（如果关闭此窗口，可在服务器管理中的仪表板点“更多”->操作->将此服务器提升为域控制器），点“将此服务器提升为域控制器”
选择“添加新林（F）
”并填入根域名（R）
点“下一步”
填入服务还原模式密码后，点“下一步”
点“下一步”
点“下一步”
点“下一步”
点“下一步”
点“安装”
安装完成后将自动重启。
进系统后关闭域网络设置防火墙
SQL用户的创建和组策略的设置创建SQL用户服务器管理器->工具->ActiveDirectory用户和计算机
在
填写姓名和用户登录名
填写密码以及修改密码属性
填写密码以及修改密码属性
SQL用户创建完成
设置组策略在服务器管理器->工具->组策略管理
点DefaultDomainPolicy->设置右键“策略”点“编辑”
点开“计算机
升级会员 