Skype for Business Server前端高可用原理分析

最近這段時間連續(xù)兩次處理同一客戶的Skype前端服務不能啟動的問題，客戶的環(huán)境總是會有前端服務器意外關機的情況出現(xiàn)，每次處理都會浪費大把時間。今天系統(tǒng)的梳理下Skype for business Server前端的工作原理，以及對應的排錯過程。

Skype for Business Server前端高可用是基于Windows Fabric進行的，Windows Fabric不需要手動安裝，在規(guī)劃拓撲和安裝Skype for business Server組件的時候會自動安裝這個Windows功能并進行自動配置。可以在每臺FE服務器上打開如下文件夾查看整個Fabric的配置。

ClusterManifest.current文件是在每次Windows系統(tǒng)重啟后會自動生成一個且會覆蓋之前的文件，所以千萬不要去手動更改里面的配置，如果手動更改配置會導致路由仲裁丟失嚴重會導致池仲裁丟失，最終導致整個池故障客戶端將無法登錄任何一臺FE服務器。

使用Get-CsUserPoolInfo可以清楚的查看到用戶當前所在的池，以及池中主要的前端服務器是哪一臺

主要注冊服務器 是FE03

主要用戶服務服務器 是FE03

次要服務器是FE01

空閑服務器是FE02

從事件查看器中也看到主要的服務器從FE02轉到FE03，同時用戶屬性的msRTCSIP-UserRoutingGroupID值也是指向到FE03的路由組，這些路由組都是存放到FE前端服務器的SQL數(shù)據(jù)庫中，并不依賴后端SQL

所以可以看出來整個前端高可用基于Windows Fabric，而Fabric基于路由組來進行主服務器的分發(fā)，而這一切都是基于FE前端進行的。

而根據(jù)微軟官方文檔的描述知道前端服務器有偶數(shù)臺或奇數(shù)臺服務器，如果是奇數(shù)臺前端服務器，F(xiàn)abric路由仲裁將在這幾臺前端服務器中進行自我投票，如果是偶數(shù)臺前端服務器那么路由投票將會增加一個后端SQL成員，如果這時候后端數(shù)據(jù)庫使用的是SQL鏡像技術，而這時候SQL服務器又要參與前端FE Fabric路由投票，而如果此時將主服務器故障轉移到鏡像服務器上那么投票將會失敗，進而導致整個前端服務停掉。

所以如果最好可以選擇前端池中有奇數(shù)臺前端服務器。

前面講到了Fabric是基于前端服務器來進行的，而后端數(shù)據(jù)庫是提供整個前端服務的基礎，如果手動關閉后端數(shù)據(jù)庫其實可以發(fā)現(xiàn)一個有意思的現(xiàn)象那就是Skype客戶端將繼續(xù)正常使用，當達到一定時間后就再也無法使用了，通過Get-CsRegistrarConfiguration命令查詢其實可以發(fā)現(xiàn)在沒有后端SQL的情況下Skype前端依然可以存活30分鐘，當然也可以通過Set-CsRegistrarConfiguration去修改這個存活時間，但是微軟官方并不建議這樣做。

以上就分析了Fabric的路由仲裁及投票，以及存在后端SQL的必然性。那么有些同學就要有疑問了，是不是Skype前端高可用必須是3臺？這個答案我更想說：如果要實現(xiàn)前端的高可用那么前端服務器至少需要3臺服務器（當然最多只能有12臺服務器）

但是更多的乙方工程師在項目實施的時候是在前端池中創(chuàng)建的兩臺服務器，這樣一來就不能滿足Windows Fabric的基本條件，無法實現(xiàn)主要服務器，次要服務器，空閑服務器。這時候相當于每一臺前端都是直連后端數(shù)據(jù)庫了，而不會像我前面所說的那樣后端數(shù)據(jù)庫宕機的情況下會有存活時間，而是Skype客戶端立刻進入斷開狀態(tài)導致無法使用。

接下來我跟大家分享一下最近接連兩次處理同一客戶三臺前端全部同時宕機導致整個Windows Fabric路由仲裁，池仲裁全部丟失的情況下怎么恢復前端服務運行正常。

先描述下事情的經(jīng)過：某天客戶的Vmware虛擬化平臺宿主機報警資源不足，需要將虛擬機遷移到另外的宿主機上，3臺前端服務器進行同時遷移，這個并沒有什么問題，悲劇的是Vmware在遷移過程中物理服務器壓力過大直接崩了，導致三臺前端服務器全部意外關機，要知道這個是對Windows Fabric最大的傷害，手動遷移后重新啟動Skype前端虛擬機預料中的情況出現(xiàn)了，Skype前端服務器上所有的服務都無法啟動，客戶慌了，項目經(jīng)理也慌了，客戶給出的處理時間是3個小時，因為3小時后整個集團領導將使用Skype進行音視頻通話。

我剛得到這個消息的時候，其實壓力是非常大的，但是基于之前已經(jīng)處理過一次這種問題，首先也找到客戶溝通，第一件絕對不能做的事情就是恢復虛擬機的快照，因為一恢復快照整個前端的高可用架構就全部亂套了，無形之中增加了解決問題的難度。

接下來我的操作過程如下：

首先手動啟動整個前端服務器上的所有Skype服務，發(fā)現(xiàn)沒有一個可以啟動，而事件查看器中一大堆報錯，都是因為無法連接到后端數(shù)據(jù)庫，前端結構池無法正常啟動之類的。

接下來切到SQL服務器上（SQL做了鏡像高可用），解決所有SQL數(shù)據(jù)庫服務不能正常運行。

然后肯定就是重置前端的結構池了，通過Reset-CsPoolRegistrarState命令來進行重置。而這條命令后面跟的-ResetType參數(shù)有以下類型：

ServiceReset：意思是停止并重新啟動RtcSrv和FabricHostSvc服務

QuorumLo***ecovery：意思是為當前處于仲裁丟失的任何路由組重新加載備份存儲中的用戶數(shù)據(jù)

FullReset：將會執(zhí)行與QuorumLo***ecovery相同類型的重置，但此外，還重建本地Skype for Business Server數(shù)據(jù)庫

MachineStateRemoved：從池中刪除指定的服務器。僅當有問題的服務器（或其數(shù)據(jù)庫）已永久丟失時，才應使用此類型的重置。

其中FullReset參數(shù)我至今沒有使用過，這算是一個大絕招，因為風險實在太大了，所以微軟官網(wǎng)都貼出了這樣一句話：在使用FullReset時最好先咨詢微軟技術工程師。

而我首先的嘗試是使用ServiceReset參數(shù)，通過重啟Fabric服務來重新規(guī)整整個路由，然后重新啟動整個前端服務，在執(zhí)行完命令后驚喜的發(fā)現(xiàn)除了Skype for Business Server前端服務意外的所有服務都已經(jīng)啟動了，業(yè)內人士都知道前端服務如果沒有運行起來，那么所有的客戶端將無法登錄進而無法使用Skype。

此時回到日志中查看依然顯示的錯誤警告是結構池沒有完成用戶初始化

意思就是雖然上面的ServiceReset參數(shù)重置了路由組，但是這個路由組并沒有加載到結構池中去，那么接下來就進行QuorumLo***ecovery命令，直接從備份的存儲中重新加載用戶數(shù)據(jù)。

在運行完命令后會重置整個Windows Fabric和重建整個存儲服務。但是此時Skype for business Server前端服務并不見的會啟動，因為文章一開始就說了Windows Fabric的配置是每次重啟機器后自動會生成一個ClusterManifest.current的XML文件里面都是配置整個Windows Fabric的主要服務器次要服務器和空閑服務器以及整個路由和仲裁，而且手動更改的文件是無效的，所以最好的也是最靠譜的解決方法是等待Skype前端服務器自動停止后將所有前端服務器關機，然后再依次開機，開機后讓三臺前端自動去進行Windows Fabric的路由仲裁投票和結構池仲裁重新設定（這個過程花費的時間視前端服務器數(shù)量而定，我這里3臺前端總共等待了大約30分鐘）

最終將所有結構池和路由仲裁全部自動設定正常，Skype for Business Server前端服務正常運行

最終還是在客戶規(guī)定的時間內解決了這個問題，總算是有驚無險。

所以基于以上的實際案例，強烈建議以下幾點：

1、 后端數(shù)據(jù)庫盡量使用SQL故障轉移群集或者Alwayson，SQL故障轉移群集和Alwayson可以參考我之前的文章

2、 不要把所有“雞蛋”放到一個“籃子”里面，建議將不同的前端服務器放到不同的數(shù)據(jù)中心或者最起碼放到不同的宿主機上

3、 關于前端池中前端服務器的數(shù)量：如果只有一個就直接做標準版把，強烈不建議使用兩臺前端服務器，至少3臺前端服務去，同時建議前端服務器的數(shù)量為奇數(shù)臺（3臺或者5臺是最佳配置，如果是7臺或者9臺就涉及到需要通過命令獲取前5臺服務器名稱，重啟必須按照前5臺的順序啟動，這種大型池故障處理起來更加麻煩）

4、 任何數(shù)量的前端池，如果需要更新補丁，一定要使用Invoke-CsComputerFailOver -ComputerName命令將服務器離線，然后再使用Invoke-CsComputerFailBack -ComputerName命令將服務器聯(lián)機，最好是一臺更新完了再更新第二臺，更新完所有前端服務去后一定記得升級下后端數(shù)據(jù)庫。

以上是我個人的一些知識分享，不代表微軟或者任何產(chǎn)品組，可能措辭不準或描述不準，但希望能幫到各位在實際環(huán)境中解決Skype/Lync Server企業(yè)版前端服務不能啟動的問題，特別是由于結構池異常導致的。