在前面两节当中，我们杀鸡取卵，偷梁换柱，终于迎娶白富美（AlwaysOn），走向……打住，没测呢还。
对，我们没有进行后端高可用的测试，如何测？
在客户端连接着的情况下，关闭一台后端数据库节点，然后看客户端有没有反应。
Exchange 2010切DAG节点都要断一下重连咧（手动切Active和Passive是不会的，你关掉一台全是Active副本的MBX试试？），你一嫁接起来的Lync关后端节点何德何能客户端会没反应？试试呗
我们关掉目前的主副本，同时观察客户端的反应情况，看到右边窗格里一水的对号是不是很爽？咦嘻嘻……
不行，没爽够再看一遍……
好，回到正题，我们边关机边观察Lync客户端的反应……那就是……没有反应…
打开LyncFE上的日志看看？不大可能啊！一堆报错呢，
安慰自己：不要紧，Exchange关掉一台MBX也会出一堆错误呢……
切回客户端，再看看？
果然求仁得仁，人在做天在看，不信抬头看苍天绕过谁，不做死就不会死！
详细读一下前端的日志吧，发现这样两条。
分析一下，此时我们关闭了LyncBE-1也就是主副本节点，那么AlwaysOn的侦听器会将请求发给LyncBE-2，换句话说，是LyncFE前端，无法连接到LyncBE-2上的Lync数据库。
为什么呢？Contoso\LYNCFE$这是个计算机账户呀……
聪明的你现在一定醒悟了已经，是Sql登录名的关系。
我们对比一下两台后端数据库的登录名列表：
也就是说，在第一次发布拓扑的时候，LyncFE在LyncBE-1上创建了数据库，并且添加了Lync服务账户组到SQL的登录名，并为其分配了登陆角色，然后我们进行AlwaysOn同步，只同步了数据库，而这么重要的登录名（5个功能组！）！我们并没有同步！
换句话说，我们需要手动在LyncBE-2节点上添加关于Lync的一些功能性账户的登陆名。
操作起来非常简单，因为有LyncBE-1节点可以做参照，我们知道需要配置哪些地方，哪些权限。
由于我已经做过对比，这几个登陆名都配置了相同的一条权限，即“连接SQL”，所以我们只需要在域里面，添加一个全局通用组，将这几个Lync功能组拖进去，然后在LyncBE-2上为这个全局通用组创建登陆名，并分配LyncBE-2的连接SQL权限即可。
有了思路就开干！：
添加成员
添加完毕
然后打开LyncBE-2上面的SQL控制台右击安全性- 登陆名 - 新建登陆名
单击搜索，
注意这里默认是没有勾选组的，也就是默认不允许添加组进来。我们需要勾选一下，然后输入组名称LyncBElogin。
然后单击左边的安全对象，单击搜索，选择服务器LyncBE-2
在下面的权限里，勾选“连接SQL”
然后单击确定，这样就可以让Lync服务组以服务账户连接LyncBE-2了！
其实操作到了这一步的时候，只要添加成功，Lync客户端那边马上会有反应，即不会再提示在中断期间有限功能可用。
然而我并没有留下那个截图……
好了，接下来将LyncBE-1启动起来，我们尝试轮流关闭两台后端节点。同时观察客户端反应。
没有反应
依旧没有反应……
前端日志里连个报错都没！
事已至此…基本可以说，在连通性方面，这种架构是允许的且合理的存在的。
后端节点进行故障转移的时候，客户端完全没有任何感觉。但是功能性方面，至发稿为止，我测试过基本IM功能，都没有问题……
至于其他组件，比如存档监控……我就说不好了。
CDR……没错，这个库，是在创建安装前端的时候才会建立的……发布拓扑的时候跟它一点关系也没，所以这个56202报错，就只能让他这么下去了
目前我想到的解决办法是找一个正常的Lync 2013环境，记录下该数据库的配置，如路径，初始大小等，然后把LcsCDR这个数据库在当前架构上手动进行建立，再加到AlwaysOn可用性组里。至于操作，就留给感兴趣的人了……
所以，这个架构仍然是有缺陷和风险的。虽然我目前只发现了这一个问题，但毕竟是测试环境，其余组件的说服力不足…如果Lync有系统性的诊断工具，倒是可以进行一次健康度测试或者压力测试，如果各位看官发现了其他问题，也欢迎留言交流。虽说是旁门左道，可是在中小型环境里，数据库大多堆在一块的场景下，这种架构的存在其实是非常节省成本的高可用解决方案！