Skype for business/Lync之数据库架构解析

by 老朱

    你知道SKYPE for business server 2015/LYNC server 2013（以下统一称LYNC，原谅我，这是惯性称呼）用到多少个数据库实例、数据库吗？结果会有点出乎你的意料。大家都知道，数据库就是来存储数据的东西，而SKYPE存储数据的地方有SQL、有AD、还有共享文件夹，AD用来存储基本的用户信息，比如SIP URI、电话号码，而用户策略信息则存储在CMS里（SQL），另外AD用来存储也是为了一个向后的兼容性。

    这里主要谈谈它用到的SQL数据库，按道理来说，LYNC用一个SQL实例就OK了（如上图一样），但实际上，它会用到多个实例，为什么会用到这么多SQL呢，看下这张图大概就明白了，

    从上图可以看出（上图只是涉及到CMS－中央管理存储数据库，并非全部，全部的见后面的列表，这里只是以它举例），即使在前端和后端分离的LYNC SERVER部署设计中（企业版），每个LYNC服务器（包括前端本身）上实际上都会有一个SQL实例（SQL EXPRESS），都会有一个xds数据库，也就是上图CMS中央管理存储的副本，下图另外两个数据库RTC/RTCDYN会在前端角色存在，是两个用户数据库，LYNC2010时代这两个库是放在后端的，而从LYNC2013开始，前端架构有了变化，这两个库也就放在前端了，后端也有一份延迟副本，名字叫RTCXDS。

注意上上图的复制方向，是一种推复制，即从CMS master向各个LYNC SERVER推，从服务控制台可以看到，每个LYNC SERVER都有一个Lync server replica replicator agent服务，它用来接收副本数据并向master反馈复制结果信息的，当然master上有一个对应的Lync server master replicator agent服务。

推复制类似广播，好处是一推大家都更新了，更新很快，不像拉复制，因为拉复制一般不是说某个确定的时间点大家都去取数据，而是说每隔多少时间去取数据，由于起始时间不同，要让所有服务器都得到最新的数据，整个时间就会拉得比较长了。

    很明显，这种设计主要是考虑到一个可用性，比如即使后端数据库宕掉，因为其他LYNC服务器本地还有一份配置副本，LYNC的主要功能是不会有影响的（所以从这个角度来说，后端SQL宕掉并不会导致整个LYNC系统瘫痪，大部分功能都能使用，从这点来说，后端是否需要部署成镜像或群集也值得商讨，因为镜像和群集特别是镜像，虽然提供了高可用，但镜像本身可能成为一个新的故障点，导致更多的维护任务）。我认为这种设计比后端单独两台SQL镜像更可靠。
    另外，前面也提到过，LYNC2013之后前端架构也有了变化，用户数据库放在了前端，对用户数据库来说，前端是主，后端只是一个备，这种变化也让后端SQL的可用性变得更不重要，但凡事有利则有弊，这样也增加了前端的复杂性，从高可用角度考虑，还增加了前端的数量（微软建议前端要三台）。

    从上面的图我们还可以推想LYNC的部署顺序，第一步准备AD，第二步准备CMS要用的SQL，第三步是调用拓扑生成器创建配置保存到CMS，第四步才是根据CMS配置信息安装或更新LYNC，对于标准版，就是下图的顺序，当然对于企业版，第二步不是图中的在标准版上准备CMS存储地，一般是部署后端SQL。从我个人的感觉来说，LYNC这个发布向导界面设计有些问题，没考虑到用户体验，完全不像windows server的1、2、3、4指得那么清清楚楚：）。

    下面用一张表格来表现各种数据库的用途及所在实例（不管是LYNC标准版，还是企业版，都是一样的，只是标准版用的是sql express，企业版后端用的是独立的数据库）。

注意：lync server的标准版实际是一个很有意思的东西，不像其他产品的标准版与企业版的区别主要表现在功能上，lync server标准版功能不缺失，它的特点是只能使用SQL express，但它有个优点，可以把绝大部分角色装在一台服务器上（而企业版还不行），这个特性对一般的中小型环境是很有利的，因为你可以只装一台LYNC SERVER标准版就容纳了所有功能（除了边缘和WAC，另外归档和监控还是需要独立后端，但中小公司也许对这个不感冒，何况归档还可以与邮件集成，不一定用SQL），考虑到高可用，再装一台标准版做备份池，也可以实现几分钟之内的灾难恢复。而企业版由于不能把几个角色合在一台，再加上LYNC2013后前端架构的变化，这样反而把一件事情搞复杂了。

l RTC实例：（就是后端数据库）

l RTCLOCAL实例：（每个LYNC服务器都有，都有XDS库，前端还有RTC/RTCDYN库）

l LYNCLOCAL实例：