Lycn 2013 with SQL AlwaysOn 「三」后续问题
在前面兩節當中，我們殺雞取卵，偷梁換柱，終于迎娶白富美（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有系統性的診斷工具，倒是可以進行一次健康度測試或者壓力測試，如果各位看官發現了其他問題，也歡迎留言交流。雖說是旁門左道，可是在中小型環境里，數據庫大多堆在一塊的場景下，這種架構的存在其實是非常節省成本的高可用解決方案！
轉載于:https://blog.51cto.com/sodaxu/1658696
總結
以上是生活随笔為你收集整理的Lycn 2013 with SQL AlwaysOn 「三」后续问题的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 《Python语言程序设计基础》——读书
- 下一篇： linux cmake编译源码,linu