如何解決 Azure Always On listener 無法訪問的問題

本文旨在解決Always On無法從secondary replica通過listener連接集群，時而出現(xiàn)不能訪問的常見問題。

Always On介紹

Always on是SQL Server on VM的架構(gòu)下最常見的高可用方案。

其基本原理為創(chuàng)建一個至少為2臺VM所組成的Windows集群，每臺VM上安裝一臺SQL Server Instance。由其中的一臺SQL instance作為主節(jié)點（primary replica）提供對外讀寫訪問，同時通過日志傳輸?shù)男问教峤坏搅硗庖慌_節(jié)點（secondary replica）進行數(shù)據(jù)同步。

Secondary replica可以提供只讀功能，用于做讀寫分離或高可用(強烈建議依舊保持備份的習慣)。

備注

在SQL server 2016之前的版本，組成Windows cluster還需要一臺Domain controller(DC)。搭建步驟：在Azure VM中手動配置Always On可用性組。

在Azure中搭建Always On的過程并不復雜，但是經(jīng)常有客戶會遇到搭建Always On之后無法使用App連接的自動故障轉(zhuǎn)移功能。

Always on的自動故障轉(zhuǎn)移功能基于Always on Listener。Listener會被注冊為一個windows cluster中的resource，類似于VIP概念;在集群發(fā)生故障轉(zhuǎn)移時listener會被漂移到新primary的VM中。對于客戶端來說，只需要訪問Listner的IP地址就可以保證永遠連接到當前的primary數(shù)據(jù)庫上。

在傳統(tǒng)的IDC環(huán)境中，Always On會自動將Listener所屬的虛擬IP地址與網(wǎng)卡物理地址注冊到路由表中，所以無論任何節(jié)點都可以通過Listener找到primary所在的服務器地址并建立鏈接。

在Azure環(huán)境下，該地址無法被注冊，所以我們需要通過增加一個Load Balancer的方式來為Listener的訪問請求進行轉(zhuǎn)發(fā)。

參考示例腳本：使用PowerShell將IP地址添加到現(xiàn)有負載均衡器

該腳本非常重要，會在primary節(jié)點上創(chuàng)建一個始終監(jiān)聽在<n.n.n.n>端口上的監(jiān)聽，并會隨著primary切換而自動轉(zhuǎn)移到新的primary VM上。本示例中使用59999。

在配置好了listener之后可能會遇到以下幾個常見問題：

在primary節(jié)點上可以通過listener IP訪問集群，但在secondary上無法訪問listener IP，只能通過提供primary服務器名或IP的方式來進行連接。

在secondary上有時候可以訪問listener IP有時候就不行，隨機出現(xiàn)。

如果遇到上述問題，我們可以通過以下幾個步驟進行排錯：

開始=>運行=>cmd輸入netstat-a檢查，是否59999監(jiān)聽端口已經(jīng)在primary節(jié)點中存在。

檢查Azure門戶中Load Balancer上的probe（探測器），探測的端口是否為59999或者是之前在PowerShell中創(chuàng)建的<nnnnn>端口。

[int]$ProbePort="<nnnnn>"#Probe port

經(jīng)常會有客戶錯誤配置為1433端口，對于LB來說，1433在primary和secondary都為存活狀態(tài)，所以會隨機的分配request給任何一臺節(jié)點，可能是primary，可能是secondary。

由于Always On必須要先訪問primary，所以如果該請求發(fā)給了secondary就會得不到響應。

Azure門戶中Load Balancer的front IP是否與Windows cluster resource中的listener的IP完全一致。

負載均衡規(guī)則中的probe是否配置。

如果以上步驟全部配置正確，通常就可以正常的使用Always On了。