2018年1月2日 星期二

如何快速在AWS EC2與AWS Microsoft AD上建立SQL Server AlwaysOn。

在之前的文章,我介紹過許多安裝SQL Server AlwaysOn的方式,但現在我來介紹一個快速安裝的方式,可以在AWS EC2上快速的透過範本(CloudFormation)進行建立所需要的SQL Server AlwaysOn的架構。

另外在安裝上由於透過AWS Microsoft AD與SQL Server AlwaysOn這二個選項安裝時,在建立Availability Group Listener會遇到一些問題,所以本篇也特別說明如何排除,再請參考。

建立步驟:
一、環境安裝與建立
1、請先點選下列的網址 -> Launch Quick Start (for New VPC),進行建立。

SQL Server on the AWS Cloud: Quick Start Reference Deployment
https://docs.aws.amazon.com/quickstart/latest/sql/welcome.html


2、透過範本的方式快速的建立,在此請先確定你要建立的Regions為何,另外可以在下方看到範本的位址,當然如果你有興趣,也可以自行下載進行修改與調整。


3、在此由於我以簡單的二個節點進行安裝,所以在Availability Zones我只選擇二個,另外關於每個節點的劃分,如沒有特別的規劃,可以使用預設值即可。

4、選擇自已的Key Pair,此處可以選擇已存在此Regions的Key Pair,如果沒有新增的話,請記得先行設定。

5、在此處,我們選擇使用AWS Directory Service for Microsoft AD,當然你也可以選擇Microsoft AD on Amazon EC2的方式進行,此時系統會自行建立二台EC2 for AD進行。

6、選擇Microsoft SQL Server的版本,目前可以選擇的有2014、2016、2017的版本可以選擇。

7、最後勾選確認後,即可開始進行。

8、切換到CloudFormation,確認是否已建立完成,約不到30分鐘的時間,一個AD服務與四台EC2都已建立完成。

9、切換到EC2的頁面,你也可以看到4台EC2也確認都建立完成了。另外RDGW是主要負責對外連線的電腦,所以我們要透過此電腦進行連線。

10、透過RDGW,然後再連到Node1進行確認,你可以看到此時二台的SQL Server皆已安裝完成。


二、AlwaysOn建立與測試
1、請先手動建立一個測試用的資料庫,並請確認複原模式為Full,建立完成後也請手動進行一次完整備份。


2、此時如果你直接進行AlwaysOn安裝的話,由其是在建立Listener,你會遇到下列的錯誤,所以我們要先作一些設定。

錯誤訊息:
Create failed for Availability Group Listener 'carylistener'.

The WSFC cluster could not bring the Network Name resource with DNS name 'carylistener' online. The DNS name may have been taken or have a conflict with existing name services, or the WSFC cluster service may not be running or may be inaccessible. Use a different DNS name to resolve name conflicts, or check the WSFC cluster log for more information.


PS:此問題我原先是懷疑是否是已有存在相同的名稱,但是一來這是新建的AD,二來透過不同的名稱建立也是相同的情況,所以排除此情況的可能性。

3、此時我先透過RDGW的機器安裝AD的管理工具,藉以進行管理AWS Microsoft AD。

4、安裝完成後,請開啟Active Directory Users and Computers,並連線到AWS Microsoft AD -> AD的OU名稱 -> Computer。

5、選擇新增Computer物件。


5、啟用進階設定。

6、選擇建立好的Listener -> Properties -> Security -> Add -> Cluster Name -> 並請將下列的權限進行賦予,或是你也可以直接給予Full Control的權限。

建議權限:
Read
Allowed To Authenticate
Change Password
Receive As
Reset Password
Send As
Validate write To DNS Host Name
Validate Write To Service Principle Name
Read Account Restrictions
Write Account Restrictions
Read DNS Host Name Attributes
Read MS-TS-GatewayAccess
Read Personal Information
Read Public Information


7、連線到主要的節點上,選擇Availability Groups -> New Availability Group Wizard

8、在Replicas的部份請記得將二個節點都加入,然後切換到Listener的部份,名稱請使用在第5個步驟中設定的名稱,而IP請選擇各節點中的Secondary Proviate IPs中的第二個加入。

第一個節點


第二個節點


 9、確定建立完成。

10、檢查並確認Listener建立完成。


上述的方式提供給大家不同安裝AlwaysOn的方式,依照上述的設定,其實真的不用10分鐘就可以建立完成(不包含等待的30分鐘),而且跟自已手動建立的,真的沒有其他的不同,推鑑下次大家可以參考看看。


參考連結:
SQL Server on the AWS Cloud: Quick Start Reference Deployment
https://docs.aws.amazon.com/quickstart/latest/sql/welcome.html
Create Listener Fails with Message ‘The WSFC cluster could not bring the Network Name resource online’
https://blogs.msdn.microsoft.com/alwaysonpro/2014/03/25/create-listener-fails-with-message-the-wsfc-cluster-could-not-bring-the-network-name-resource-online/
Create Availability Group Listener Fails with Message 19471, ‘The WSFC cluster could not bring the Network Name resource online’
https://blogs.msdn.microsoft.com/alwaysonpro/2013/10/30/create-availability-group-listener-fails-with-message-19471-the-wsfc-cluster-could-not-bring-the-network-name-resource-online/

2017年12月22日 星期五

如何在AWS透過EC2建立自動彈性延伸的網站

在傳統的網站部份,如果針對特定的節日或進行行銷時,可能網站會有較多的流量,此時原先的主機可能無法承受負載,所以通常會進行網站設備上的擴充,但是在時間過了之後,可能就沒有這麼多的使用者與流量時,就會造成設備的閒置與浪費,所以此時雲端是一個很好的選擇。

在各家的雲端上建置IaaS的部份VM皆可以選擇不同的Instance Type,當然我們可以在不同的時間點進行切換,比如當有節日或活動要進行時,我們可以彈性的調整Instance Type,但目前在AWS EC2上有不同的選擇,您可以透過Auto Scaling與Load Balance的功能整合,藉以達到快速的Scale Out,來更合適的完成公司的商業需求。

建置方式:
1、建立環境所需的影像檔

1-1 先針對你的網站設計好需要的網頁與功能,然後制作成一個Image.
1-2 方法很簡單,請到EC2 -> Instances -> 選擇你要制作的Instance -> Image -> Create Image


輸入Image的名稱與預設的Disk

送出Create Image的請求,需至下一步驟進行確認是否已建立完成。

1-3 建立完成後,請到Images -> AMIS -> 確認Image是否已建立完成 。


2、建立Load Balancing

由於在後續上會有多個Instance Type自動進行建立,而且也需要進行負載平衡,所以此步驟我們建立一個Load Balanc er進行。

2-1 撰擇Load Balancing -> Load Balancers -> Create Load Balancer

2-2 在選擇Load Balancer時有三種項目可能選擇,這三種的選擇上看你的應用程式類型選擇Application Load Balancer或Network Load Balancer,基本上不建議再選擇第三種傳統模式,此部份我們選擇第二種高效能的Network Load Balancer進行。

2-3 決定NLB的名稱與開放的Port、如果您的網站有使用HTTPS的話,請將443也一同加入。

2-4 指定在Region中特定的AZ(Availability Zones)區域。

2-5 定義Target Group去指定特定的Instance。

2-6 指定特定的Instance到此Target Group中,但由於我們後續會由Auto Scaling自行啟動,所以此處不進行手動加入。
2-7 建立完成。



3、建立Auto Scaling

3-1 建立 Auto Scaling Lunch Configuration
3-1-1 選擇Auto Scaling -> Launch Configuration -> 建立Auto Scaling

3-1-2 進入後,頁面說明會有二個步驗,分別是建立設定檔與群組的部份,首先我們就先建立設定檔的動作。

3-1-3 選擇我們在步驟1-3之中所建立的Image。

3-1-4 選擇後續自動延伸時所建立的Instance Type

3-1-5 輸入Launch Configuration的名稱,建議也可以勾選透過CloudWatch進行監控。

PS:由於啟用CloudWatch進行監控時可能會有額外的費用產生,所以再請注意。

3-1-6 選擇啟動後的Instance上的Disk大小。

3-1-7 設定Security Group,此部份我只有開啟80(HTTP)與3389(RDP)二個,當然你也可以將443(HTTPS)加入,由於我之前已有設定的Security Group符合,所以我就將之前的加入。
3-1-8 再次檢示Launch Configuration的設定並確認建立。

3-1-9 設定你key pair的檔案,此處由於之前也設定過了,所以可以使用相同的檔案即可。

3-2 建立Auto Scaling Group

3-2-1 輸入Group Name與預計進行Scaling的網路區段,你可以將多個區段加入,藉以避免因單一區段發生問題時,整體無法運作,此區請至少加入一個Network與Subnet。

在進階設定的部份,請將第2步驟中建立的NLB加入,並將請將Health Check Type設定為預設的EC2,請為這樣我們就可以透過CPU與或網路流量來設定條件,藉以達到自動延伸的功能。

3-2-2 此部份由於我們要模擬當使用者過多時,CPU使用率過高,造成網站回應過慢,所以我先設定為1-5個Instance,當使用率超過50%的時候,就自動進行Scal Out。

3-2-3 設定警告通知,當遇到勾選的事件產生時,即會自動寄出通知。

3-2-4 最後檢示Auto Scaling Group的設定


3-2-5 建立完成

3-3 測試網站連結

3-3-1 建立完成後,我們可以到Auto Scaling -> Auto Scaling Groups 確認目前已自動啟動的Instance為何。

3-3-2 接下來我們同樣的透過Load Balancer的DNS來連線到網站,確認是否可以正常的連線。
請到Load Balancing -> Load Balancers -> 已建立的NLB -> Description中,即可看到。

3-3-3 測過此網址進行確認是否可以正常的連線。

 4、Auto Scaling測試

4-1 由於我們在3-2-2之中,設定Auto Scaling的規則為CPU使用率超過50%,所以最快的方式我使用了測試軟體(Intel Brun Test)去直接的快速提高CPU的使用率。


4-2 經過一段時間,系統就會自動再產生一個Instance,然後自動加入NLB中。

4-3 最後,由於CPU 使用率持續不斷的增加,所以Instance數量成長到我設定的最大值。


4-4 Instance 的成長區間圖
4-5 我透過NLB的DNS網址進行連結測試,你會發現五個Instance皆會輪序的進行訪問,當然如果你要確認他有連結到那一台Instance的話,你可以逐一連到Instance中,然後修改頁面即可確認。

上述的介紹,你可以透過Auto Scaling與Elastic Load Balancing的整合,藉以快速的達到Scale Out的需求,也可以達到效益的最佳化,當然此部份後續仍有其他可以研究的部份,如程式的修改與部署的部份,我們將會在後續的章節繼續再跟大家介紹,謝謝。


關鍵字:
Amazon EC2Elastic Load BalancingAuto ScalingAWS

參考連結:
Getting Started with Auto Scaling
http://docs.aws.amazon.com/autoscaling/latest/userguide/GettingStartedTutorial.html
Elastic Load Balancing
https://aws.amazon.com/tw/elasticloadbalancing/
What Is Elastic Load Balancing?
http://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html

2017年11月28日 星期二

如何透過Web Deploy工具進行網站的轉移 - 舊版網站轉換(IIS6 -> IIS7 Up)

常見的當我們要進行網站的昇級、搬移或同步時,常需要將原先的網站同步到其他台的電腦上,所以本篇透過Web Deploy的工具整理一些常見的情況來說明如下,後續上如有遇到的話,也可以藉以參考,直接使用。

由於章節過多,所以我將此Web Deploy的部份分成幾個章節進行說明。在進行說明前,由於需要進行網站ID的設定,所以先說明在IIS上,該如何找到自已所需的ID編號,如下圖,點選站台後,即可看到。

識別方式:

舊版網站轉移:
目前在Windows 2003上,其實有下列的工具(IEMT)可以進行轉換,工具的使用方法很簡單,所以就不特別介紹,但有時候可能會發生無法轉換的情況,所以這時候就是將Web Deploy拿出來用的時候了。

轉換工具:
IIS Easy Migration Tool (IEMT)
https://www.iis.net/downloads/community/2013/04/iis-easy-migration-tool-iemt

在安裝上,由於Win2003只能安裝舊版本,在測試上只能安裝Web Deploy 1.1的版本。

工具下載:
1、Web Deploy 1.1(for Win2003):

在安裝後,請先確認下列的事項:
1、Web Deployment Agent Service是否有啟動。
2、由於彼此是透過Port 80進行,所以請確認是否有開啟。
3、如果要透過二台電腦直接進行同步時,請確認執行的身份,建議可以透過Domain Account進行。

執行同步方式:
1、登入目的端電腦。
2、開啟Dos Command視窗,切換到 C:\Program Files\IIS\Microsoft Web Deploy
3、輸入下列的指令:
msdeploy -verb:sync -source:metakey=lm/w3svc/1,computername=cary-srcweb -dest:metakey=lm/w3svc/1 -enableLink:AppPoolExtension -verbose
上述的指令在目的端電腦執行時,會將來源端的電腦(cary-srcweb)IIS站台中的ID編號1的站台,同步到目的端的ID編號1的站台上,-enableLink:AppPoolExtension會確認當AppPool不存在時,會自動建立,最後-verbose主要是指定執行過程中會輸出詳細的執行過程。

另外你也可以透過封存的方式進行,先將來源端上的網站封存成一個壓縮檔,然後再到目的地端上進行還原的動作。

執行封存的方式:
1、登入來源端電腦。
2、開啟Dos Command視窗,切換到 C:\Program Files\IIS\Microsoft Web Deploy
3、輸入下列的指令:
msdeploy -verb:sync -source:metakey=lm/w3svc/1 -dest:package=c:\share\20170524weblist.zip,encryptPassword=12345 -enableLink:AppPoolExtension -verbose

還原封存的方式:
1、登入目的端電腦。
2、開啟Dos Command視窗,切換到 C:\Program Files\IIS\Microsoft Web Deploy
3、輸入下列的指令:
msdeploy -verb:sync -source:package=c:\share\20170524weblist.zip -dest: metakey=lm/w3svc/1,encryptPassword=12345 -enableLink:AppPoolExtension -verbose

參考網址:
Synchronize IIS 6.0 Web Sites
https://docs.microsoft.com/en-us/iis/publish/using-web-deploy/synchronize-iis-60-web-sites
Migrate a Web Site from IIS 6.0 to IIS 7 or above
https://docs.microsoft.com/en-us/iis/publish/using-web-deploy/migrate-a-web-site-from-iis-60-to-iis-7-or-above

2017年11月17日 星期五

網頁執行錯誤HTTP 500.19 - 解決方法


最近遇到客戶反應,當網頁的使用者過多時,尤其是特定的時段,網頁會發生HTTP 500的錯誤,在進一步的確認後發現初步的問題如下。

從下列的錯誤來看,其實可以看到已有提到可以有參考的KB,而且也有詳細的錯誤,找一下Google大神後,你會找到不少的文章與解決方法,但如果真的這麼簡單的話,我也不會寫下這篇文章了,其實在我嘗試了不同網站寫的方法後,其實都無法解決,而且最重的事如果你照著設定的話,你會發生系統會發生問題,無法進行檔案分享,而且關機時會無法正常進行,如下列的畫面。

就因為如此,所以我才特別整理此篇文章,希望大家可以藉以解決此問題。

錯誤訊息:
[From Web Page]

[From Failed Request Tracing Log]

[From Event Log]
Event Level:Error
Source:ASP.NET 4.0.30319.0
Event ID:1185
Message:Failed to start monitoring changes to '\\caryhsu\my_fav\video' because the network BIOS command limit has been reached. for more information on this error, please refer to Microsoft knowledge base article 810886. Hosting on a UNC share is not supported for the Windows XP Platform.

設定錯誤時,嘗試關機的畫面:

環境描述:
1、IIS Server(Windows 208R2)
2、File Server(Windows 2003R2)

目前已知在新版的環境上也都可以重現此問題。

問題重現:
1、由於此問題在大量的透過網路分享時就會遇到,所以我建立一個站台,然後建立50個虛擬目錄。


2、在各虛擬目錄上我也分別設定特定的使用者。

 3、為了模擬大量的使用者,所以透過Visual Stdio進行壓測,果然立即就發生相同的情況。

解決方法:
在此處設定的值非常的重要,如果在IIS端設定錯誤時,可能就會造成此主機在分享目錄上發生問題,所以強烈建議請參考下列的值進行設定即可。

For IIS(Windows 2008R2)
HKLM\system\currentcontrolset\services\lanmanworkstation\parameters\MaxCmds=REG_DWORD value=5000(十進位制)

再次強調,上述的值(5000),請勿設定過大,否則會造成系統問題。

For File Server(Windows 2003R2)
HKLM\system\currentcontrolset\services\lanmanserver\parameters\Maxwi=REG_DWORD value=65535(十進位制)

HKLM\system\currentcontrolset\services\lanmanserver\parameters\MaxMpxCt=REG_DWORD value=65535(十進位制)

設定完成後,再請重新啟動電腦後即可。


關鍵字:KB810886500.19network BIOS command limit has been reached

參考連結:


2017年3月1日 星期三

如何進行App Service for Web問題排除

網站發生問題時,往往都會手忙腳亂,雖然Azure有提供良好的服務可以直接請工程師進行問題的排除(Azure Technical Support),但有時候問題的情況過了之後就需要再等待問題的重現,所以我們本篇就介紹一些基本的排除方式,在第一時間發生時,即可以收集並進行初步的分析與問題排除,另外也可以將收集到的資訊提供給專業的微軟工程師進行初步的分析,藉以快速的找出問題。

其實當問題發生時,可以先初步的確認Azure Service Status的網站,確認此次的問題是否可能與Azure本身的服務有關,當如果真的是Azure本身發生問題時,通常發生問題會以Data Center為區域性影響,網站上也會進行公告,但有時候可能公告訊息不一定會立即列出問題的區域,如果沒有顯示會並非Azure本身的問題的話,我們接下來後續的處理。

基本上App Service for Web(Windows)本身的核心就是IIS,所以我們可以透過一些IIS的除錯方式進行處理,另外在問題除錯上,非常不建議在正式的網站啟用Remote Debug Mode進行,因為會造成網站整個被咬住,造成許多問題。

建議如果可以的話,可以嘗試在Deployment Slot新增一個測試站台,然後再透過此測試網站進行遠端除錯,老話一句正式環境不到最後一步,儘可能不要使用遠端除錯的方法。

可能的問題情況:
1、Azure Portal介面操作無法完成,出現錯誤等情況。

1-1 請先嘗試將語言與地區格式切換至英文(English)後,再進行確認。
1-2 如果都無法完成你要的作業時,此時建議可以將錯誤畫面截圖並將操作過程透過瀏覽器的開發者工具(F12)或是透過Fiddler進行收集,並在Azure Portal上建立Support Request請微軟的工程師進行協助。

2、網頁無法顯示或是顯示錯誤訊息為500、50x類型:

2-1 請確認空白網頁(html)是否也會有相同的情況。
2-2 請確認下列的#a收集網站的詳細錯誤訊息,確已確認問題為何。
2-3 透過下列的#b的方式進行memory dump的捉取,並再進行分析找出問題。

3、特定網頁開啟緩慢

3-1 請確認空白網頁(html)是否也會有相同的情況。
3-2 透過Application Insights觀察目前網站的情況,藉以確認是否網站無法負荷,可以嘗試增加Instance,藉以加快處理。
3-3 如果程式語言為.net時,建議可以透過下列的方式在程式中加入執行計時分析,藉以找出真正慢的區塊為何。

Stopwatch 類別
https://msdn.microsoft.com/zh-tw/library/system.diagnostics.stopwatch(v=vs.110).aspx

3-4 在網頁過慢的時候,透過Hang Dump的方式建立Memory Dump,藉以分析當下網站主要的問題為何。

4、網頁發生列外狀態(Exception)。

4-1 透過Application Insight可以收集到程式是否有產生Exception。
4-2 透過#a的log可以知道是那一支程式發生Exception。
4-3 在有問題的程式區塊透過Try-Catch進行例外的捉取,
4-4 透過#c的方式主動觀察網站,並產生Exception Dump。

PS:如果你的網站有多個網頁都有發生例外時,可能你會收到太多種的Exception Dump,所以可能會收到的檔案並非預期頁面的檔案,這時就要分析這些檔案的資訊,再逐一解決這些問題。

5、CPU High

5-1 透過Application Insights觀察目前網站的情況是否正常,如流量與CPU比率等。
5-2 當問題發生時透過#b的方式進行Hang Dump的產生,再進行分析。
5-3 問題發生時可能無法當下手動產生,可以透過#c的方式進行自動監控,藉以當CPU超過一定的比率時,自動產生Hang Dump File,

6、網站發生Crash

6-1 透過後台觀察網站有自動進行重啟。
6-2 透過Application Insights發現網站有重啟的情況。
6-3 透過#c的方式自動觀察網站,當發生Crash時,即會自動產生Crash Dump。

資訊收集:
a. 啟用詳細的Log File與Failed Request Tracing

這個其實就是捉取IIS的Log File,另外也可以透過Failed Request Tracing當問題發生時詳細記錄錯誤訊息。

在 Azure App Service 中針對 Web 應用程式啟用診斷記錄功能
https://docs.microsoft.com/zh-tw/azure/app-service-web/web-sites-enable-diagnostic-log

b. 將網站手動產生Memory Dump

登入SCM的後台,選擇 Tools -> Diagnostic dump即可產生Memory Dump,千萬記住在產生時,系統會全部暫時凍結住,所以會影響前端的操作,這部份再請注意。

Using KUDU with Microsoft Azure Web Apps
https://blogs.msdn.microsoft.com/benjaminperkins/2014/03/24/using-kudu-with-windows-azure-web-sites/

c. 透過網站的擴充功能(Extensions)啟用自動監控,即可當網站發生預期的問題時,即可自動產生Memory Dump。

假設我們啟用監控CPU當超過60%又超過10秒時,自動產生Memory Dump。

從網站的處理序總管即可看到會有二個新增的Process,名稱為CrashDiagnoserProcDump,當設定的條件達到時,即會自動產生。

How to capture and analyze a dump file when intermittent High CPU happens on Azure Web Apphttps://blogs.msdn.microsoft.com/asiatech/2016/01/20/how-to-capture-dump-when-intermittent-high-cpu-happens-on-azure-web-app/

d. 分析Memory Dump。

基本上對底層架構沒有一定的熟悉時,是很難可以自行分析的,但其實我們可以過一些方式簡單的進行分析,如果還是不行的話,其實還是可以透過Support Request請微軟的工程師進行分析。

net 程式進階除錯教學 - 使用WinDbg
http://caryhsu.blogspot.tw/2011/11/net-windbg.html

Analyze a memory dump using the Debug Diagnostic tool
https://blogs.msdn.microsoft.com/benjaminperkins/2016/02/01/analyze-a-memory-dump-using-the-debug-diagnostic-tool/

Using Visual Studio 2013 to Diagnose .NET Memory Issues in Production
https://blogs.msdn.microsoft.com/visualstudioalm/2013/06/20/using-visual-studio-2013-to-diagnose-net-memory-issues-in-production/


關鍵字:AzureWeb AppsApp Service for WebTroubleshooting問題排除Memory Dump