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

2017年2月25日 星期六

建置Azure App Service for Web的建議實務 - 進階篇

上一篇我們已介紹完基礎建置的部份,接下來我們來介紹進階管理與應用的部份,功能的部份我也逐一介紹,如有不清楚或較深入整合的應用,我會考慮再加開文章進一步的介紹,也歡迎大家討論。

相關介紹:
建置Azure App Service for Web的建議實務 - 基礎篇
http://caryhsu.blogspot.tw/2017/02/azure-app-service-for-web.html

1、部署位置(Deployment Slot)

一般我們在開發上如果要進行部署時,通常建議先將程式放置在測試機上進行確認,以後我們都需要找二台相同的機器進行正式機與測試機的運作,在App Service for Web上,你可以透過部署位置(Deployment Slot)來完成。

Standard TierPremium Tier等級上可以透過建立部署位置(Deployment Slot)來完成測試的動作,在建立後,你可以將程式先部署至此,然後再進行測試,到時候再透過切換的方式,即可達到快速的換版動作,一來可以先行測試程式,二來也可以減少前端離線的影響,最重要的是此功能在Standard TierPremium Tier等級上是免費的,所以強烈推薦進行使用。

從網站 -> 部署位置中即可看到目前已建立的項目,如下圖我們已先建立好一個部署位置。

從Visual Studio上來看,你也可以看到部署時我們可以選擇將專案部署到特定的位置上。

在應用程式設定的部份,也可以進行位置區分,當進行切換時,也可以保留特定部署位置上的設定值。


2、快取(Cache)

在快取的部份,除了在網站的部份啟用Local Cache外,在App Service for Web中大家常用的有Redis CacheCDN,二個是不同層級的應用,Redis Cache屬於應用程式中的資料快取,在某些資料上沒有即時性的需求時,即可考慮透過此服務來加快讀取,藉以提升速度。

另外由於我們的Web Apps部署時會選定一個資料中心(Data Center)進行存放,但是當使用者的區域與資料中心(Data Center)的位置不同時,可能會造成使用者在讀取上因為網路的傳遞過遠而造成頁面回應過慢的情況,此時你就可以考慮啟用CDN,藉以減少因地理環境不同而造成的讀取回應上過慢的問題。

快取等級:
Local Cache -> 網站內容快取
Redis Cache -> 網站內容中特定資料的快取
CDN -> 網站內容快取,並提供給其他地理位置的使用者進行讀取

3、Application Insights 

在網站架設後,我們要隨時觀察網站的使用量與健康程度,以往我們可以要透過IIS Log進行或是加入Google Analytics等進行網站的分析,其實可以不用這樣麻煩,你可以直接透過Application Insights進行即可,啟用後即可快速的透過此服務進行網站的監控。

3-1 預設上網站並沒有特別啟用Application Insights,請先進行建立。

建立時由於存放Application Insights的Data Center並沒有太多的選擇,所以可以先指定一個先行存放,基本上不會有太大的影響。

3-2 在程式中也需要同時啟用Application Insights,在Visual Studio非常簡單,只需啟用此服務並設定後即可。

3-3 啟用後即可透過即時計量資料流看到即時的資料。


3-4 Dashboard即可顯示監控的資訊,在監控的項目上也非常的多,可以將一些常見的都加入進行觀察。

3-4 在啟用Application Insights後,可以設定警示功能當監控的數值超過一定的數量主動透過E-Mail進行提示。

4、自動調整(Auto-Scaling)

在基礎篇有特別的提過,基本上網站可以應該忙碌的情況進行調整站台的執行個體,在預設的情況下是透過手動的方式進行,但在Standard Tier(含)以上的架構,可以透過CPU百分比排程及效能規則的方式進行自動調整的動作,此部份強烈建議你在啟用Application Insights後對網站的使用率有深入的了解後,即可進行彈性的調整,假設今天你知道晚上有有促銷的活動時,你就可以透過自動調整的規則進行,藉以穩定網頁的回應與整體速度。


5、Traffic Manager

在雲端上的服務基本上在一定的等級上都有服務層級協議(SLA),如App Service的部份只要是Basic Tier(含)以上的等級,就有保證每月最多只會有21分鐘左右的斷線(SLA 99,95),所以基本上也不會是100%保持服務,所以Traffic Manager會是你一個很好的選擇。

下圖是從官網截取而來的圖,從此圖上來看,概念類似負載平衡器,將使用者依據Traffic Manager的設定,如效能、優先權、權重等方式,一般來說常見的就是效能模式,效能模式上可以將使用者導向 "網路延遲" 最少的Data Center,問題當其中的一個Data Center發生問題無法提供服務時,Traffic Manager也可以將使用者導向其他的Data Center。

一般來說使用者最常考量的就是要同時租用多個Data Center,只為了那每個月的可能21分鐘斷線,但換個方向想每次的斷線可能造成當下的交易損失與多一個Data Center的成本相比,我想對大部份的企業來說決對是值得的,而且另一個節點還是有同時提供服務,並不是一般Cluster上的Standby模式,所以相信此服務絕對值得投資。

Traffic Manager架構圖

高效能模式
其實建立的方式也很簡單只要在Azure Portal上選擇Azure Traffic Manager Profile並選擇作業模式,此處的名稱即是後續連線時主要的DNS名再,而且後續無法變更,所以再請注意名稱的定義。


建立完成Traffic Manager Profile之後,再將Web Apps加入。

最後即可透過Traffic Manager對外的DNS名稱連線到Web Apps中。



參考連結:
App Service plans
https://azure.microsoft.com/en-us/pricing/details/app-service/plans/
Set up staging environments in Azure App Service
https://docs.microsoft.com/en-us/azure/app-service-web/web-sites-staged-publishing
Redis 快取
https://azure.microsoft.com/zh-tw/services/cache/
開始使用 Azure CDN
https://docs.microsoft.com/zh-tw/azure/cdn/cdn-create-new-endpoint
設定 ASP.NET 的 Application Insights
https://docs.microsoft.com/zh-tw/azure/application-insights/app-insights-asp-net
Scaling apps in an App Service Environment
https://docs.microsoft.com/en-us/azure/app-service-web/app-service-web-scale-a-web-app-in-an-app-service-environment
Manage an Azure Traffic Manager profile
https://docs.microsoft.com/en-us/azure/traffic-manager/traffic-manager-manage-profiles



關鍵字:App Service for WebAuto ScalingBest Practices、Cahce