Azure雲服務內置自動縮放如何工作？

Azure的文檔的擴展研究後，我們還是很懷念的天青如何內置的雲服務自動縮放作品的一些重要細節。我們的雲服務是具有單一Web角色的簡單ASP.NET應用程序。默認情況下，我們將部署到2個實例以獲取SLA覆蓋範圍，並且每次只按一個實例按比例放大或縮小。我們使用啓動任務來配置IIS並在csdef中定義它們。我們使用RoleEntryPoint來指定OnStart事件中的自定義熱身邏輯。我們確信啓動任務和OnStart不會因錯誤而失敗。Azure雲服務內置自動縮放如何工作？

以下問題從我的觀察得到的，並打算如果這是預期的行爲，以澄清。

當雲服務按比例向上或向下當前會有取出負載平衡器的某個時間短量並不會服務器請求每個實例。這是真的嗎？
topologyChangeDiscovery在csdef =「闖天關」不改變這種行爲，並在規模化經營情況仍然取出負載平衡器。這是真的嗎？
如果在雲服務N個實例，並將其擴展到N + 1將會有一些時候，只有N-1情況下的服務請求。這個時間等於N *（單實例配置更改所需的時間）。這是真的嗎？
有沒有辦法設置自動縮放，以確保當前在雲服務中規模化經營將成爲沒有中斷請求的所有實例？（通過任何手段不僅使用Azure的內置自動縮放）

UPDATE：

我已經進行測試，以實際檢查什麼情況下是服務期間大規模事件的請求。簡單的控制檯應用程序輪詢雲服務並記錄哪些實例響應請求。我已將Azure門戶中所有更改的屏幕截圖添加到日誌文件中。

下面是結果：從2到3個實例擴大： https://gist.github.com/samfromlv/8029ff0b3fdb3e6bd02a#file-scaleuplog_withscreens-txt

比例從3降到2實例： https://gist.github.com/samfromlv/8029ff0b3fdb3e6bd02a#file-scaledownlogs_with_screens-txt

控制檯應用程序的源代碼，並記錄格式描述： https://gist.github.com/samfromlv/8029ff0b3fdb3e6bd02a

來源

2016-03-02 samfromlv

你的問題很相似，[這個問題]（http://stackoverflow.com/questions/22252802/azure-autoscale-restarts-running-instances），其中有一些討論的答案行爲。 –

在我們的案例中沒有角色回收（IIS進程未重新啓動）。你特別提到的問題是關於什麼導致回收的問題。 – samfromlv

當你處理1個實例或1個實例時，你會遇到不愉快的結果，這是因爲Azure需要exis將負載平衡器中的「良好」實例關閉。

假設你只處理2+情況下，從來沒有縮減低於2分的情況下，這裏是基於爲天青

只有當運行CloudMonix/AzureWatch自動縮放服務的5yrs一些迴應有如上所述僅剩1個監管
爆炸對負載平衡器應該沒有什麼影響。但是，如果在拓撲事件發生時所有實例都重新啓動，請確保在Web/WorkerRole.cs中的拓撲更改事件期間不會意外返回'true'以重新啓動。如果您有N個實例，其中N> = 2 ，它可以擴展到N + 1，大概需要10分鐘才能到達N + 1。在這種情況下，你不應該有N-1個活躍的。微軟有一個文檔解釋了它如何快速擴展到多個實例，但它與啓動實例計數無關，而是與它啓動的新實例的數量有關。我相信多達100個新實例可以保證在30或60分鐘內完成。不要在此引用我的意思。
您可以使用第三方服務，例如我所隸屬的一個，CloudMonix。但在所有情況下，標準縮放問題都適用於處理1個實例並試圖縮小或縮小它。

HTH

來源

2016-03-02 19:50:04 Igorek

你好，謝謝你的回覆。我們觀察到內置Azure自動縮放的不同行爲，以用於從2個實例縮放到3個實例的情況。請檢查原始問題中的更新以獲取詳細的測試結果。這是預期的行爲？在這種情況下，CloudMonix行爲與Azure內置自動縮放不同嗎？ – samfromlv

Azure雲服務內置自動縮放如何工作？

回答

相關問題