SCVMM2012R2服务模板系列（五）创建一个开箱即用的双层服务模版
有关开箱即用的单层Web应用服务模版，可参考之前的文章：
http://maomaostyle.blog.51cto.com/2220531/1336130
这次分享的是追加了SQL层的双层模板，使得整套服务更加的饱满；前端应用不必指向已有的SQL实例，这样不同用户的数据源相对独立，可以更自由的管理和维护
首先介绍一下环境：
SCVMM2012 R2，Web应用依旧选用了开源CMS门户“DotNetNuke”，数据库版本2012SP1，下面开始上图
#####################################################################################
对于SQL和应用程序配置文件的相关说明，我在此不做过多赘述，感兴趣的朋友可以参考本系列之前的内容，下面的图示主要提醒一些需要注意的地方：
首先我们的SQL配置文件需要修改验证方式为“SQL验证”，并且给sa密码一个映射，也就是图中所选账户的密码将作为SQL实例的sa密码，因此请确保Run As Account账户有效，注意这里不是让你创建一个sa；之所以选择了sa验证，是因为“图个方便”，究竟是什么方便呢？后面会揭晓
接下来需要准备我们的数据库“素材”；找一台SQL服务器为我们的应用创建一个库
然后选择生成脚本，如下图所示；双层服务模版的SQL层其实最重要的工作就是要自动生成你想要的库，并且根据需求产生相应的表结构及内容等等
生成脚本的向导十分简单
基本保持默认设置一路下一步
这里根据不同的需求来做适当的修改，是否包含对象的DROP或CREATE语句等等，这里我只导出数据
确认无误后下一步生成
看到返回成功即表示完成了脚本生成
然后来做下一步，就是把数据库提取成一个DAC包，DAC里面包含了该库的Schema
同样也是一个很简单的向导，如下图所示
自定义一个好记的名称和存放路径
确认无误后导出
看到返回成功即表示完成
在这里要提醒大家一下，如果你当前的SQL数据及日志路径为非默认路径，那么之后你通过导出的DAC和Script部署SQL虚机时候也要确保该虚机有这个路径，举个例子也就是说如果你当前路径不是下图所示的C盘，而是独立的数据盘或者日志盘比如E；但是你的虚机只使用了默认Disk配置，那么就会报错（见第二张报错截图）
打包好数据库“素材”后，将其上传至SCVMM共享库中
上传后别忘记刷新噢~
#####################################################################################
接下来就该准备配置文件了，SQL层不光要有数据库配置文件，还要给它挂一个应用程序配置文件，这个应用程序配置文件里面就是附加了我们刚才导出的DAC包以及数据库脚本，我们的SQL层要依靠这些“素材”然后再配合生成的实例才能创建我们想要的库；选择我们的DAC包并配置运行方式账户
在DAC下面的脚本中，选择我们准备好的数据库脚本并配置运行方式账户；同时根据需要你可以指定一个Log输出路径
########################################################################################
应用程序层的准备工作和之前博文里的一样，只不过我们这次打包的应用不需要指向已有的SQL实例，因此不用添加“Connection String”
这里顺便回顾一下：应用程序配置文件下挂的两个脚本，一个是安装WebDeploy，以便导入上面的应用程序zip包
第二个脚本用来修改解包之后的应用程序目录权限，赋予everyone的full control，当然也可以根据需求自行调整，比如只赋予NETWORK SERVICE权限
###################################################################################
至此我们前期准备工作已就绪，下面就来看看双层模板的配置，以下图这个“Scal-Out WebApp 2-Tier”为例（同样也是支持前端可扩展的呦）
先看一下该模板的属性，在这里可以给配置文件中的脚本变量赋值，比如在这里我们给@NameforIISSite@指定dotnetnuke这个值，以后每次部署前就不用去定义了（这个值就是解压后的应用程序文件夹名）
再看一看此模版都依赖了哪些资源，还真不少。。
然后打开设计器来更直观的看一下双层模板的结构
首先是数据库层，可以看到预览图里面显示了它所包含的DAC包，SQL配置文件以及虚机信息等；此外注意下方对该层并没有启用可扩展（虽然没有启用，但仍然可以对这一层做Scale-Out操作，只不过在向导界面会有个Warning叹号而已。。）
再看一下前端Web应用层，包含一个zip包以及虚机信息；另外下方对该层启用了可扩展，并且对初始数量和最大数量做了限制（其实到了限制之后依然可以扩，只不过向导界面会有个Warning叹号。。）
关于负载平衡器的连接方法，我们只需要对前端启用，因此按照下图方法连接即可
另外在此处还可以对该服务模版设置优先级，如下图所示
如果我们打算把模板发布到门户上，比如App-Controller或者Azure-pack等，可以在计算机层属性内定义配额点
##################################################################################
接下来我们开始正式部署这个服务模版，点击“Configure Deployment”
选择一个目标位置并输入一个服务名称
服务模版在正式部署前还可以再对配置进行一次确认，假如我们的脚本还有没赋值的字段，都可以在这一步里进行操作
等待若干时间后部署成功了（我的环境用了一个小时左右，出去吃了午饭溜溜达达回来再聊几句天就好了）
对比之前坐过的单层服务模版，发现多了一个SQL层
展开SQL层之后可以看到生成了我们需要的数据库，如下图所示
##################################################################################
服务部署好了，就可以验证Web应用了，下图中的第2个IP是这个双层模板负载平衡器的地址
在此之前先来试一试我们的SQL实例可否访问，尝试用sa验证来登陆，输入之前定义好的密码
哒哒~成功，说明SQL层使用了混合验证并且启用了sa账户，还记得之前说过的用sa验证是为了“图个方便”么？一会就揭晓原因
######################################################################################
通过输入NLB地址可以正常打开DotNetNuke应用，说明前端工作也OK，下图是DotNetNuke应用初始化界面，需要配置
主要是这一部分，连接我们的数据库；输入SQL实例地址和库名称，保持windows验证不变并点击继续
呃！？报错了，连不上。。。shit；不会花了一个多小时功亏一篑吧
###################################################################################
下面正式进入我们的Troubleshooting阶段以及揭晓为什么要“图个方便”：
由于我们在DotNetNuke配置向导中保持了默认的windows验证，虽然当前是以域管理员账户登录的，但是应用去连接SQL实例使用的是它自身的凭据，那么我们先来看一下DotNetNuke这个应用所用的程序池是哪个；如下图所示“DefaultAppPool”
然后就分析分析这个默认程序池，来看看它的高级设置
噢~~~原来是用了这么个�潘科揪堇醋鲅橹ぃ�那必然不行啊，我们需要更换一个凭据以便连接SQL实例
更换谁好呢？前提是要看你当前实例级别的登陆账户有哪些，假如你换成了“LOCAL SYSTEM”，那么本身LOCAL SYSTEM是以计算机账户来使用的，那么你就要把前端server加入到SQL的本地管理员组中才能赋予它login权限，以此类推；你要是用普通域账户，你也要提前给予权限才能连接；那么很显然我们的SQL默认实例登陆权限是根据模板中的SQL配置文件来生成的，之前我只给了sa和域管理员，所以在此为了节省时间我直接换成域管账户来试一下（注意两台前端服务器都要改哦）
再次点击“continue”，如下图所示成功；此阶段是DotNetNuke在创建表数据等配置工作
完成了，我们可以点击查看网页来看一下效果
OK，看来没有什么问题；综上所述，之所以在SQL配置文件中选择SA验证方式，就是为了规避windows验证所带来的不便；不管是现成的第三方App，还是自主开发的，使用sa相对比较省事
至此双层服务模版的部署告一段落了，后期我们可以根据需要对不同的层级进行扩展
######################################################################################
有了SCVMM的服务模版，我们就可以通过SCOM和Orchestrator来配合对其实现自动的负载监控；下图是一个DEMO；在SCO中做一个runbook，这个脚本主要是从SCOM中定期的去get-alert（指定的警报类型），一旦发现目标警报，就去触发一个Scale-Out动作
如下图所示我们对部署好的应用配置.NET APM监控（有关操作可参考之前的博文http://maomaostyle.blog.51cto.com/2220531/1315674）
接着模拟多用户访问对前端Web加压
如下图触发了一个性能告警，而这个告警正是SCO中所检测的，一旦捕获到就立即触发扩展动作，然后再把这个警报状态改为“已解决”
######################################################################################
以上只是一个简单的思路，具体场景需要根据不同的情况来考虑，希望可以帮助到有需要的朋友们；对于双层服务模板，其实最重要的就是解决下面几个问题：
1、确保SQL层要自动生成所需要的库（如果不是像DotNetNuke这种案例，就需要我们把带有表结构和数据内容的DB成功导出成DAC及Script）
2、确保应用连接SQL时有足够的权限（DotNetNuke根据不同的用户会有不同的初始化配置，而如果是一些自主开发的应用，就需要在应用程序配置文件中多添加一些脚本来实现修改AppPool账户的功能，还有自动获取到SQL层主机名并建立对应的Connection String）
3、建议使用sa作为SQL层实例的验证方式，这样会方便一些，或者可以在SQL层赋予脚本来grant账户权限