Azure雲服務與現有Asp.Net網站的虛擬機

Question

我已經看到這個問題的變化，但找不到任何與我們特定場景相關的問題。

我們有一個現有的aps.net網站鏈接到SQL Server數據庫。 數據庫具有clr用戶定義類型，因此它只能在Azure VM中託管，因爲Cloud Services不支持所述類型。

我們最初想用一個虛擬機數據庫和雲服務的前端，但隨後一些問題出現了：

1. 我們使用StateServer用於存儲狀態，但Azure不支持。我們需要配置表存儲，SQL數據庫或專用於狀態管理的Worker角色（新角色是增加的成本）。由於性能的原因，表格存儲不太理想。其他兩個選項是可取的，但它們會帶來成本或應用重新配置的缺點。
2. 我們使用SimpleMembership進行用戶管理。我們需要將會員表從我們的vm實例sql server遷移到Azure的SQL數據庫。這是一個不便之處，因爲我們希望將所有表保存在同一個數據庫中，並且拆分2可能需要更改一些代碼。

我們正在尋找一個快速解決方案，讓這個應用程序儘快生活，並以可控的成本。我們正在拼命試圖避免重新考慮我們的代碼，以適應在Azure雲服務中託管部分應用程序。

問題：

• 難道只去託管一切VM路線？
• 利用VM實例（用於SQL Server）和Cloud Service實例（用於前端）是否有任何成本優勢？
• 在我看來，爲Cloud Service添加的每個「後臺進程」都需要新的工作角色。例如，如果我們想爲郵件服務啓用smtp，這將需要一個新的角色，因此成本更高。它是否正確？

Answer 1

要用CLR等運行SQL Server，您需要在虛擬機中運行SQL Server。

對於Web層，有以雲服務（Web角色）的優勢，因爲它們是無狀態的 - 很容易/在向外擴展，不用擔心安裝操作系統。並且啓動時通過啓動腳本完成應用程序設置。如果您可以適當地託管會話內容，則無狀態模型將更容易擴展和維護。但是，如果您需要一些複雜的安裝來執行這些操作需要一段時間（或手動干預），那麼虛擬機確實可能是更好的路由，因爲您可以構建VM，然後從該VM創建主映像。您仍然會遇到操作系統和應用程序維護問題，就像在內部部署環境中一樣。

讓我糾正你的第三個項目符號關於後臺進程。雲服務的Web角色（或工作者角色）實例僅僅是Windows Server VM，其中包含一些用於啓動和進程監視的腳手架代碼。每個人都不需要單獨的角色。隨意在單個Web角色上運行整個應用並向外擴展;你只能在非常粗糙的水平上進行縮放。

Answer 2

有些事情要考慮...

如果您想要便宜，您可以通過添加RoleEntryPoint讓Web/Worker角色在單臺計算機上共享相同的代碼。下面是實際演示瞭如何做你正在嘗試與發送電子郵件做一個帖子： http://blog.maartenballiauw.be/post/2012/11/12/Sending-e-mail-from-Windows-Azure.aspx

會話管理在SQL Azure中DB十分緩慢，我會使用Azure的緩存，如果你can..it快。

帶有虛擬機的SQL Server將給您帶來問題，因爲您還需要在該服務與任何雲服務之間創建虛擬網絡。這真的很愚蠢，但是如果您部署雲服務和虛擬機，它們會通過公共負載平衡器進行通信，從而導致潛在的安全問題和網絡延遲。所以，首先你需要虛擬網絡（這是一個額外的成本）..然後你還需要託管一個DNS服務器來解決SQL Server虛擬機。是的，這是非常愚蠢的，除非你是用你的SQL服務器在互聯網上:)

編輯交流您的Web /輔助角色OK：改變「公共互聯網」到「公共負載平衡器」（並指出延遲）

編輯：上面的信息是100％正確的，與下面David的評論相反。請點擊這裏閱讀微軟的指引：

http://msdn.microsoft.com/library/windowsazure/dn133152.aspx#scenario

直接從Microsoft指導談到跨雲服務通信（VM->網絡/工作者角色）：

「我們建議您實現因爲連接過程不需要通過公共互聯網，因此它可以提供更好的網絡性能。「

從今天（2013年8月29日）起，Azure VM和Worker/Web角色部署到不同的「Cloud Services」中。因此，它們之間的通信需要通過虛擬網絡進行保護，該虛擬網絡在實例之間公開私有IP地址。

爲了跟進David的觀點，關於添加ACL。您仍然使用TDS（SQL Server協議）通過Internet發送數據包。這可以加密，但沒有一個理智的架構師/企業治理/安全管理會「允許」這種情況發生在生產環境中。