本文属于SQL Server虚拟化系列
前言：
现代系统中，虚拟化越来越普遍，如果缺乏对虚拟化工作原理的理解，那么DBA在解决性能问题比如降低资源争用、提高备份还原速度等操作时就会出现盲点。所以基于本人工作环境的情况和大时代的趋势，同时根据个人经验，绝大部分的IT人员都对虚拟化持有怀疑或者保留意见的态度。所以这里开始一个系列文章，介绍SQL Server虚拟化的内容，内容来自 Stairway to Server Virtualizaion ，如后续有更新或者本人有其他内容，也会添加进去。
目前本系列包含以下小节，第一节即本文：
- SQL Server 虚拟化（1）——虚拟化简介
- SQL Server 虚拟化（2）——理想的SQL Server虚拟机架构
- SQL Server 虚拟化（3）——在Vmware上搭建SQL Server
- SQL Server 虚拟化（4）——在Hyper-V上搭建SQL Server
下面开始第一节，虚拟化简介 http://www.sqlservercentral.com/articles/Stairway+Series/112555/
简介：
虚拟化在很长的一段事件里面，是企业数据中心化过程中最具破坏性又非常有益的技术之一。通过虚拟化技术，企业巩固了它们的服务器基础架构，并在过去的十多年中，为数据中心节省了大量的资金，虚拟化已经无处不在。
如果此时此刻还没有虚拟化你的SQL Server，那么对于你的企业来说，这只是时间上的问题。不行的是，从经验来看，很多企业的管理规范中，虚拟层只对基础设施管理员可见，而DBA几乎被完全隔离，对虚拟化平台一无所知。所以，DBA往往会犹豫是否适合把关键服务器放在这个新平台上面。
即使服务器进行了虚拟化，通常来说，DBA也没有被包含在虚拟化过程中，所以也导致了DBA对这个新加入的层了解甚少。就像一个“黑盒”，充满了未知和风险。
如果缺乏对虚拟化工作原理的了解，DBA在尝试解决很多问题，如性能问题（比如降低资源争用、提升备份还原性能）时，就会出现盲点。他们通常不会意识到，可以通过调整虚拟化层中内置的一些特性和功能，就可以解决一些如不稳定的备份策略或者长时间运行的任务这类问题。
本节首先介绍虚拟化是什么，为什么需要理解它的概念，为什么作为DBA需要参与在其中，和如何在虚拟基础设施中运行你的关键SQL Server任务。在后续的文章中，会覆盖关键的虚拟化特定的提示和技巧从而最大化虚拟化平台的SQL Server效率和灵活性。
从物理化到虚拟化：
为了对比虚拟化，首先需要先了解其对应的一方——物理化，下面是传统的服务器基础设施示意图：
在传统服务器基础设施中，每个SQL Server都需要进行下面操作：
- 采购和部署一台物理服务器。
- 配置本地或类似SAN存储等。
- 安装和配置操作系统。
- 安装和配置SQL Server。
- 部署数据库，然后配置应用程序访问。
此时，服务器的物理资源是固定且有限的。而且需要分配比预期资源消耗对象所产生的预期负载还要多的CPU、I/O、内存资源。因此，对于服务器运行过程中的大部分时间而言，资源往往没有被充分利用（上图中百分比） 。
因此，虚拟化应运而生，从功能上来说，虚拟化是一个建立在硬件智商的，允许在同一个物理服务器上运行多个独立操作系统的新的层。虽然他们实际上还是共享物理服务器上的可用物理资源，但是他们都是完全独立，互不感知地在同一台物理服务器上运行。
多个独立的操作系统（也就是虚拟机）可以独立地、同时地运行在同一个物理服务器上，并且每个操作系统不再依赖于特定的物理机器。虚拟层使用队列，让每个虚拟机及其内部应用可以申请相同的计算资源，如CPU或内存。通过合适的队列申请，使得资源请求可以合理地被物理机响应。
最后，虚拟化可以把一台或多台物理服务器组成一个总的计算资源池，同样可以使用队列，让虚拟机和上面的应用访问这个资源池。配置完成后，管理员可以通过创建虚拟服务器切分和分配资源，每个虚拟服务器分配独有的资源。
虚拟化技术：
系统管理员都倾向于使用相同的基础设施专用术语来引用栈的不同部分。如下图：
- Hypervisor：安装和配置在每台物理机器上的虚拟化层。用于处理虚拟机资源请求队列和实现物理机上的资源交付。
- Host：指在集群或者由一群主机按照相同规则组成的一组机器组内的一台物理机器。
- Independent Management System：用于控制host群组中的操作和规则，监控所有基础设施中的组件中断、环境自动化协同情况，并且为管理员提供一个集中的管理环境。
- Guest：在虚拟化“集群”中的一台虚拟机，可以位于物理机（host）集群中的任何一台之上。但是某一时刻仅能位于一台host之上，所以虚拟机的规模会受限于单台host的可用资源情况。
- Interconnects：通过不同的网络和存储连接方式把host连在一起。并且共享存储组件。
市面上主流的虚拟化管理程序有：
从概念层面而言，他们的功能一样：允许多台虚拟机，有各自的操作系统，独立、协同地运行在相同的物理服务器，并且共享一台或多台物理服务器的计算资源。但是不同的厂商对软件有不同的实现方式，所以他们也有自己的特点，但是都是大同小异。因为这个系列关注在SQL Server的虚拟化，所以我们把精力放在架构、性能和特定管理细节上。
虚拟化如何帮助DBA？
我们经常听说要从企业的观点去看问题：节省资金、能源、时间等等。但是到底虚拟化对DBA有什么好处？如果使用合理，那么虚拟化平台可以在DBA的工作生涯的几乎所有地方都能起效。
降低成本：
SQL Server的许可证成本相对于很多DBMS而言非常可观（当然跟Oracle没得比），但是如果被恰当地与虚拟化许可模式搭配，可以降低一定的成本。
独立整合：
通常来说，当DBA考虑整合的时候，头痛的是多个实例合并到一个实例，或者多个应用程序的数据库合并到一个实例的过程所带来的麻烦和挑战。通过虚拟化，可以通过改进资源消耗来合并，使得多个虚拟机可以在一个host上协同存在。从而不需要合并实例或者应用。从另外一个方向来看，在资源消耗观点中，多个操作系统的开销可以忽略不急，所以如果许可证允许，分离实例成为多个独立的宿主机更加可取。
高可用：
虚拟层可以直接和间接地加入到SQL Server的高可用和风险最小化策略（risk minimization strategy）中。如果没有虚拟化，创建高可用的SQL Server环境需要很多复杂的技术。某些情况下，虚拟机的虚拟化高可用性保护可以用一个非常简单而且透明的HA解决方案来替换一个复杂的高可用方案。
比如，在VMware高可用方案中，提供了针对硬件计划外停机的一个复选框，提供了一旦物理机器故障，可以在4分钟内恢复的功能。
即使在一个严格的以虚拟机为中心的HA方案中配置不合理，虚拟机层面的高可用也能对传统SQL Server服务器的稳定性做补充，从而减少因为物理组件故障导致的严重事件。
灾难恢复：
虚拟化后的SQL Server在灾难恢复方面表现得更加好。通常情况下，在灾难恢复站点的SQL Server应该和源服务器几乎完全一样，否则在故障转移过程中可能会出现资源不足以应对压力的情况从而导致异常或转移失败。在物理环境下，进行灾难恢复测试是不可省略的。而在虚拟化的SQL Server环境中，虚拟机不在依赖于物理服务器的细微差别和不同的复杂度。可以在不对特定设备依赖的情况下恢复和提升服务器到活动状态。虚拟化技术可以用来简化、补充甚至替代传统SQL Server灾难恢复技术。
敏捷性和灵活性：
由于消除了对硬件的依赖，使得系统的变化变得相对容易。只要集群中的单个主机能够容纳你的虚拟机，就可以动态调整CPU、内存、网络和硬盘配置。如果虚拟机超过了主机限制，可以购买更高配置的主机，把虚拟机迁移到新的主机上，这个过程可以不影响正在运行的业务。这个过程同样适用于硬件升级。添加新的主机到集群，讲虚拟机迁移到新的设备，然后停止使用旧的硬件。
标准化：
在你的环境中，由多少台服务器组成？其模型如何？BIOS和驱动程序的版本？硬盘配置？文件存放位置如何？通过合适的设计虚拟基础设施，并使用预配置的标准的SQL Server虚拟机模版用于部署。这样你的SQL Server环境就成为一个标准化环境并可以文档化。同时节省了时间。
组织壁垒和优先事项的差异：
虚拟化是一个相对漫长而艰巨的过程，最初，虚拟化用于快速和大规模整合中。早期的虚拟化管理程序整体性能开销远高于现在，使得性能影响非常明显。但是由于早期的虚拟化用于简单的预生产环境负载中，所以性能问题并不非常重要。
随着时间的发展。管理程序持续改进，变得越来越高效，可以支持大型的虚拟机。更多的生产环境被虚拟化。可以说 ，这些平台已经做好了应付整个地球上的生产环境。
但是，不要忘记虚拟化的原始目的——大规模整合。虚拟化管理员被迫尽可能多地把虚拟机挤进他们的环境。整合过程第一个考虑因素——性能。回到现在，在大量环境中，这个问题依旧存在。
现在，DBA有了不同的任务，普通的DBA以数据可用为开始，然后数据一致性，然后性能。前两个和虚拟化管理的目标相同。但是两边的核心冲突——性能和整合依旧存在。回顾一下开始的时候说过，虚拟化真的只有资源和资源队列吗？当你的环境中，越多的资源请求，那么资源争用就越明显。物理服务器的资源争用意味着虚拟机的性能损耗。越多的资源争用，越多的性能损耗。
性能和整合之间的冲突是大多数SQL Server虚拟化过程中的主要问题。SQL Server虚拟化由于虚拟机管理员的不合理创建和管理，导致SQL Server虚拟化的名声不好。虚拟机管理员并不精通应用程序在虚拟化中的细微差别，也不知道他们应该知道些什么内容。但是，他们的最佳实践，通常目标是为了使得环境能适应绝大部分的工作负载。但是这个经常又给DBA带来麻烦。SQL Server是一个延时敏感的应用程序，文件服务器的1~2%性能影响，在大型SQL Server中可能被放大到25%甚至更大的层面。你作为DBA，为了表达这个现象，熟悉虚拟化环境是跟虚拟机管理正常沟通问题的关键。
最简单地表达影响的方式是从概念上理解栈，并且使用对象信息来演示由于基础设施底层问题所带来的性能影响。这些客观的度量标准可能会打破任何进行了虚拟化的应用程序，如果你准备为整个生产系统进行虚拟化，那么对于关键的SQL Server的可用性和性能会对你带来更少的麻烦。
SQL Server虚拟化监控：
监控、收集和对关键性能度量指标进行趋势分析可以帮助DBA跟踪和分析虚拟化前后的性能趋势。试想如果不能客观地证明你的系统在执行虚拟化后性能出现异常，那么如何反馈问题呢？所以简历持续的性能统计收集、分析和基础设施可用性的过程能最大化效率，这在虚拟环境中是关键点。
持续性能收集：
持续地对Windows Server和SQL Server进行性能度量收集是非常关键的。幸运的是，这个配置和维护相对简单。如果你有类似System Center或者其他收集器，那么确保你的全部关键计数器已经被添加。如果没有，可以使用Windows性能计数器。使其不影响Windows和SQL Server运行前提下进行24*7的收集。这部分可以参考作者的博客里面的文章：Ongoing Windows Perfmon Collection Setup
基准和基线：
除了系统性能计数器之外，也应该从SQL Server环境中收集性能重要对象的性能统计信息。包括一些可以衡量性能的对象：长时间运行的查询、备份事件、ETL事件等。
收集的信息应该可以重复执行、结果必须可保存，以便用于趋势分析。
了解虚拟化层：
当你开始虚拟化环境之后。企业虚拟化背后的管理系统从主机、访客机和基础架构下的主机收集如CPU性能、存储消耗和资源队列等待事件等关键指标。至少你需要有对这些你管理的系统有只读访问权。能对这些信息的访问才能快速地分析这些度量标准，定位性能问题。
总结：
本节介绍了SQL Server虚拟化的一些基础、关键的特性及虚拟化过程中的难点。后续章节会对这些部分进行深入介绍。
下一节：
SQL Server 虚拟化（2）——理想的SQL Server虚拟机架构