2015年12月7日 星期一

網站下載過慢問題分析 - 以MSDN Download為例

最近想從MSDN Download訂閱下載檔案,但發現不管下載什麼檔案時,下載的速度大約都只能在15K~20K左右,而但我的網路是20MB/5MB,在其他的站台下載也不會有這麼慢的速度,透過測試網站進行確認時,也的確如我遇期,所以興起我進一步確認這個問題,也希望可以找到解決的方法。

經過一番的確認後,初步排除基本問題,如共同下載、中毒、網路速度過慢等問題,後來發現一個情況,那就是透過不同的瀏覽器會有不同的下載行為,在我透過Microsoft Internet Explorer、Microsoft Edge與Chrome這三套來分別進行測試時,發現IE與Chrome都只能在20k左右,但是透過Microsoft Edge卻可以達到2MB左右的速度,所以初步懷疑應該也不是網站限制流程的問題。

在以往的解法上,微軟官方在以前有提供透過工具(Microsoft File Transfer Manager)進行下載,可以加速處理,我以前試過也的確可以很快的下載完成,但很可惜的是在2015年3月以後就不支援了,在IE10(含)也無法透過此工具進行,雖然可以透過設定至IE9的相容性模式進行解決,但還是不太方便,而且其他的瀏覽器也無法透過此工具進行。

實際上的解法我放在最下法的部份,下面是我針對此問題透過Wireshark進分析的的過程與個人看法,再請大家參考,如有不對的部份也歡迎討論。


另外雖然看不到程式碼,但我想應該可以透過Wireshark捉個封包來看看,並藉以了解並從中找出一些眉目,所以我就索性在我Windows 10的電腦上同時透過Chrome與Edge分別各捉一個封包進行比較。

捉到的封包我們先透過Wireshark中的Analyze -> Expert Info進行分析,從下圖可以看到在透過Chrome進行下載時,會有多次的out-of order、duplicate ACK與Retransmission的情況發生,而且次數很多,相反的在Microsoft Edge上就沒有這種情況,但問題來了,發生這種情況時該如何進行調整,當然此時的建議或許你使用Microsoft Edge會是比較快的方式(哈)。

封包分析 - Chrome


封包分析 - Microsoft Edge


但進一步的從封包來看,發現從開始下載檔案後,二個瀏覽器在下載的行為上有不同的方式,首先從Chrome的下載行為上來看,Client端會送出一個Windows Size=65535,Len=0的封包,然後下一個封包Server端會回送Windows Size=20440,Len=1460的封包,然後一直反覆的確認每次的傳送。


但是從Microsoft Edge上來看,你可以發現雖然Client端也是送出一個Windows Size=65535與Len=0的封包,但是Server端卻可以直接進行處理,並直接進行傳送。

另外我們檢查在Chrome送出時,在Windows size scaling factor的值為-1。

但是在Microsoft Edge的部份,在Windows size scaling factor值為-2,我想這就是主要的原因所在,因為每次Windows Size都需要重覆的確認,造成傳送上的延遲,另外關於Windows size scaling factor的值說明,可以參考下列的連結說明。

[Window size scaling factor: -1 (unknown)]
https://ask.wireshark.org/questions/10071/window-size-scaling-factor-1-unknown

See RFC 1323 for the specification of the TCP window scale option.
http://www.ietf.org/rfc/rfc1323.txt.pdf

當知道原因後,我進一步的追查,果然找到一個解法,詳細說明請參考下列的說明,解決方法很簡單,只需調整登錄檔中的三個參數值,如下所示。

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{a9469a2f-b852-4e88-a4ee-2d17e7c19c65}]
"MTU"=dword:00000578
"EnablePMTUBHDetect"=dword:00000001
"EnablePMTUDiscovery"=dword:00000000

上述紅色的文字即代表你網路介面卡的GUID,你可開啟一個Dos Command輸入下列的指令進行查詢,再將查詢到的值填入後,再將上述的值貼入.reg檔執行即可。

查詢有線網路卡介面:netsh lan show interfaces
查詢無線網路卡介面:netsh wlan show interfaces



Browser Connections Appear to Stop Responding When Accessing IIS Over SSL
https://support.microsoft.com/en-us/kb/285821

更改後再請重新啟動電腦,再進行確認,發現就算透過Chrome進行下載時,也可以達到2MB左名的速度。


關鍵字:Download SlowMSDN DownloadWindows Size Scaling FactorSpeed up Downloads

2015年12月3日 星期四

在混合雲的架構上建立完整的AlwaysOn架構

在前面的文章中已有多篇介紹如何架設AlwaysOn的教學,不管是在區網內,或在Amazon的EC2上都已有介紹,但是當單一區域發生問題時,還是有可能造成服務的中斷,所以本篇特別介紹如何整合區網與Azure,讓單一區域發生問題時,可以直接飛到雲端,藉以讓服務中斷的可能性降的更低。

在實作這個架構後,坦白說你要遇到系統全部掛掉無法使用的機率應該趨近於0,因為不管是本地端的防護或是雲端皆可當成很好的備援,另外此架構也可以有效的分散系統效能的瓶頸,所以建議大家可以參考,只是在安裝上步驟繁瑣而且可能會遇到許多不同的問題,所以特別整理此篇藉以自我參考,也希望可以幫助到大家。

前導文章:
  1. 如何在Amazon上透過EC2,架設完整的AlwaysOn架構。
  2. SQL Server - AlwaysOn連線設定
  3. SQL Server 2012 新功能 - AlwaysOn安裝與設定
  4. SQL Server 2012 (Code Name Denali) - HA 新功能 - AlwaysOn

架構示意圖:

架構說明:
架構上簡單來說會分為公司內部區網與Azure上的區網,然後中間透過Azure的Site to Site VPN來進行連結,其實你可以想像成有二個區網,一個在地面上,也就是公司內部的區網,另一個是在雲端上,也就是Azure上的區網,然後透過Site to Site VPN的服務彼此進行連結。

1、區網架構:
  • Home-AD(Windows 2012) - 192.168.1.2
  • RRAS Server(Windows 2012) - 192.168.1.1
  • AlwaysOn-Node1(Windows 2012+SQL 2014) - 192.168.1.14
  • AlwaysOn-Node2(Windows 2012+SQL 2014) - 192.168.1.15
2、雲端架構:
  • Azure-AD(Windows 2012) - 192.168.2.4
  • AlwaysOn-Node3(Windows 2012+SQL 2014) - 192.168.2.5


安裝步驟:
1、規畫區網內的IP配配。
2、將二個區網透過Site to Site VPN進行綁定,並確認彼此之間可以相互溝通(Ping)。

這個步驟非常的重要,因為二個區網的溝通都是靠此機制(Site to Site VPN)進行,所以我覺得這是混合雲中的關鍵,所以在此我特別說明一下。

基本上由於我由沒有實體的設備可以進行,所以我是透過微軟的Routing and Remote Access(RRAS)服務來完成,詳細的文章由於已有很多參考資料,所以就先不整理,再請參考下列的文章說明。

VPN Gateway FAQ
https://azure.microsoft.com/en-us/documentation/articles/vpn-gateway-vpn-faq/

Creating a site to site (S2S) VPN to Azure with RRAS, one physical NIC and a NAT gateway
http://blogs.technet.com/b/diegoviso/archive/2014/10/28/creating-a-site-to-site-s2s-vpn-to-azure-with-rras-and-one-physical-nic.aspx

PS:
另外說明,在使用Routing and Remote Access(RRAS)服務時需要注意下列連結提到的幾個事項,比如說我原本是透過IP分享器進行上線,但由於不能透過NAT進行,所以我的RRAS主機改由撥接上網,而且也建議透過固定IP進行,要不然的話每次斷線你就需要手動調整Azure上的區網設定,然後又再進行連接。

檢查清單:安裝及設定 RRAS VPN 伺服器
https://technet.microsoft.com/zh-tw/library/dd469733.aspx

3、建議在雲端上建立複本的AD與地面上的AD進行同步,藉以達到備援的動作。

Installing an Additional Domain Controller by Using the Graphical User Interface (GUI).
https://technet.microsoft.com/en-us/library/cc753720(v=ws.10).aspx

Installing a Domain Controller in an Existing Domain
https://technet.microsoft.com/zh-tw/library/cc816609(v=ws.10).aspx

4、請先依照下列的文件將AlwaysOn安裝完成。

特別說明,由於我們透過Site to Site VPN將二個網路綁在一起後,基本上你可以把二個區網當成同一個網路有不同的網段,所以在後續上你可以直接把第三個節點(AlwaysOn-Node3)直接加入Cluster之中,另外在建立AlwaysOn的服務時,也可以直接將第三個節點(AlwaysOn-Node3)直接加入即可。

另外在建立各個節點的分配上,我建議可以透過下列的方式進行配置,如下表所示。

4-1 第一個與第二個節點由於皆在同一個區網內,所以建議可以透過同步的方式進行交易,另外此二個節點也建議不要設定成可讀取,因為在日後交易量過大時,容易造成瓶頸問題。

4-2 另外第三個節點由於在不同的區網內,為了不影響運作,建議採用非同步的交易進行,然後此節點可以開啟唯讀設定,這樣的設定一來可以分散流量,二來又不會影響到交易時間,在實作上是比較合適的作法。


SQL Server 2012 新功能 - AlwaysOn安裝與設定
http://caryhsu.blogspot.tw/2012/04/sql-server-2012-alwayson.html

5、建立AlwaysOn Listener。

其實這個步驟如同我在Amazon上建立時相同,其實我覺得才是最關鍵的部份,而且在建立後其實也有遇到與Amazon上相同的情況,我稍後再整理說明。

5-1 由於我的各個節點都是安裝Windows 2012,所以必須先安裝下列的Hotfix進行修正。

PS:這邊指的是所有的SQL節點,只要是OS為2008R2 or 2012,都需要檢查此KB是否已有安裝,如果沒有的話,則必須一定要安裝。

更新可讓 Windows Server 2008 R2 和 Windows Server 2012 基礎 Windows Azure 虛擬機器上的 SQL Server 可用性群組接聽程式
https://support.microsoft.com/zh-tw/kb/2854082

5-2 為雲端上的每一個節點設定Endpoint藉以進行訊息回傳(direct server return)

5-2-1 請先設定你的PowerShell環境,相關設定請先參考我下列的文章說明。

如何變更Azure上虛擬網路已配置虛擬主機的IP
http://caryhsu.blogspot.tw/2015/09/azureip.html

5-2-2 查詢Azure網段內可用IP有那些

PowerShell語法:
(Test-AzureStaticVNetIP -VNetName "VNet" -IPAddress 192.168.2.0).AvailableAddresses

由於在Azure上目前只有二台主機分別是AzureAD(192.168.2.4)與AlwaysOn-Node3(192.168.2.5),所以照我的規劃有192.168.2.6-192.168.2.11可以使用,所以我預計以192.168.2.9進行使用。

5-2-3 增加Azure-VM-Endpoint

PowerShell語法
$ServiceName = "alwayson-node3" #主機在Azure上的名稱
$AGNodes = "alwayson-node3"     #VM名稱
$EndpointName = "AGLE"          #endpoint name
$EndpointPort = 1433            #endpoint port
$ILBName = "ILBAG"              #internal load balancer name
$SubnetName = "Subnet-1"        #目前在Azure上規劃的子網路(如下圖)
$ILBStaticIP = "192.168.2.9"    #預計設定給Endpoint的IP位址

Get-AzureVM -ServiceName $ServiceName -Name $AGNodes | Add-AzureEndpoint -Name $EndpointName -LBSetName "$EndpointName" -Protocol tcp -LocalPort $EndpointPort -PublicPort $EndpointPort -ProbePort 59999 -ProbeProtocol tcp -ProbeIntervalInSeconds 10  -InternalLoadBalancerName $ILBName -DirectServerReturn $true | Update-AzureVM



建立完成後,你如果仍是使用舊的Portal時,會無法看到,但是透過新的Portal時,就可以看到新增的Endpoint,如下圖所示。

新的Portal:

舊的Portal:

當然你也可以透過PowerShell來查詢特定VM上是否已建立的Endpoint。
Get-AzureInternalLoadBalancer -ServiceName alwayson-node3


5-2-4 建立AlwaysOn Listener

在混合雲的架構下,要新增AlwaysOn Listener是比較特別的,不像一般以往透過SQL Server Management Studio,這時就要透過Failover Cluster Manager來進行,開啟後,請點選目前Primary Node -> Add Resource -> Client Access Point。

輸入你想要的Listener Name,然後再將目前公司區網內預計要分配給Listener的IP指定在下方,另外你還需要配置Azure Listener的IP,但由於介面的關係,所以後續再進行設定即可。


設定完成後,即可在Resource區中看到剛剛新增的項目,此時請再修改Azure節點的IP設定。


先調整名稱的部份,由於原本是設定成動態分配,所以名稱的尾碼為0,目前由於我們改分配成192.168.2.9,所以建議更改成正確認名稱,另外就是設定下方IP分配的選項,如下圖所示。


再請確認剛剛設定的Listener屬性中相依性是否為 "OR" ,因為在節點上不會二個同時上線,所以在規則上請設定成 "OR"即可。

設定完成後,請嘗試將此Listener設定成Online,此時成功後,你就會看到如下圖所示。


最後再選擇 agdemo -> other resources -> agdemo -> Dependences 將Listener加入相依性,最後我們在回到SQL Server Management Studio即可看到Listener已新增完成。



Configure an external listener for AlwaysOn Availability Groups in Azure
https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-sql-server-configure-public-alwayson-availability-group-listener/

6、AlwaysOn Listener問題處理

建立完成後,坦白說跟我在建立Amazon的時候一樣存在二個問題,一個是連線逾時的問題,另一個是無法進行readonly routing的問題,詳細的說明與解法與我下面的文章說明相同,也是一樣的情況,再請參考下列的連結設定,在此我就不再加以贅述。

如何在Amazon上透過EC2,架設完整的AlwaysOn架構。
http://caryhsu.blogspot.tw/2015/10/amazonec2alwayson.html

關鍵字:Hybrid CloudAlwaysOnSite to Site VPNRouting and Remote AccessMulti-Subnet