在前面两节当中，我们杀鸡取卵，偷梁换柱，终于迎娶白富美（AlwaysOn），走向……打住，没测呢还。

对，我们没有进行后端高可用的测试，如何测？

在客户端连接着的情况下，关闭一台后端数据库节点，然后看客户端有没有反应。

Exchange 2010切DAG节点的时候，outlook都要断一下重连咧（手动切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有系统性的诊断工具，倒是可以进行一次健康度测试或者压力测试，如果各位看官发现了其他问题，也欢迎留言交流。虽说是旁门左道，可是在中小型环境里，数据库大多堆在一块的场景下，这种架构的存在其实是非常节省成本的高可用解决方案！