最小化Azure中的停機時間

Question

今天，我們的Azure應用程序正在經歷非常嚴重的計划外停機，而現在正要花費9個小時。 我們已向Azure支持人員報告，操作團隊正在積極嘗試解決此問題，我對此並不懷疑。 我們設法使我們的應用程序在我們擁有的另一個“測試”托管服務上運行，並重定向了CNAME以指向實例，以便我們的客戶滿意，但“主要”托管服務仍然不可用。

我本人的“空中手指”本能是，問題與我們的數據中心（西歐）內的網絡有關，實際上，當天晚些時候，該區域的服務儀表板已經變成紅色，並帶有相應的信息。 （我們的應用程序在門戶中顯示為“健康”，但無法通過cloudapp.net URL訪問。此外，我們應用程序中的線程正在將sql連接異常記錄到我們的存儲帳戶中，因為它無法聯系數據庫）

但是，非常奇怪的是，我上面提到的“測試”實例也位於同一數據中心，並且與數據庫聯系沒有問題，並且其外部端點完全可用。

我想問一下社區，是否有什么我可以做得更好的方法來避免停機？ 我遵守有關每個角色至少有兩個角色實例的指導，但是我仍然很生氣。 我應該搬到一個更可靠的數據中心嗎？ 我應該將我的應用程序部署到多個數據中心嗎？ 我如何管理我的SQL-Azure數據庫位於同一數據中心的事實？

任何建設性的指導將不勝感激-作為一名技術人員，我從未有過更沮喪的一天無法采取任何措施來解決此問題。

Answer 1

今天，歐洲數據中心因SQL Azure發生了故障。 我們的一些客戶受到打擊，不得不搬到另一個數據中心。

如果您正在運行無法關閉的任務關鍵型應用程序，那么我會將其部署到多個區域。 DNS解析現在顯然是Azure中的薄弱環節，但是可以解決（如果您僅運行網站，則可以使用Response.Redirects或類似方法非常簡單地完成）

現在，Microsoft提供了一個數據同步服務，該服務將同步多個SQL Azure數據庫。 在這里檢查。 這樣，您可以在不同區域中建立鏡像站點，並使它們與SQL Azure透視圖同步

另外，最好使用第三方監視服務，該服務將在外部檢測已部署實例的問題。 如果您選擇的話，當某些實例變為“無響應”時， AzureWatch可以通知甚至部署新節點

希望這可以幫助

Answer 2

我可以根據我們的經驗提供一些指導：

1. 在多個數據中心中托管您的應用程序，並帶有Sql Azure數據庫。 您可以將每個應用程序連接到其數據中心特定的Sql Server。 您還可以在特定於數據中心的Windows Azure計算機上緩存任何外部資產（圖像/ JS / CSS），或利用Azure Blog Storage。 注意：將產生額外費用。
2. 在主Sql Azure數據庫和另一個數據中心中的實例之間設置單向SQL復制。 如果要進行雙向復制，請查看MSDN站點以獲取指導。
3. 利用Azure Traffic Manager將流量路由到距離用戶最近的數據中心。 它具有地理檢測功能，這也將改善應用程序的延遲。 因此，您可以將地圖http://myapp.com重定向到數據中心的內部URL，歐洲的用戶應自動重定向到歐洲數據中心，反之亦然。 注意：在撰寫本文時，尚無法自動檢測並故障轉移到數據中心。 一旦檢測到故障轉移且故障轉移已完成，將涉及手動步驟（即，您將對Windows Azure和Sql Azure實例進行故障轉移）。 如果要進行微級故障轉移，則建議將所有配置都放在服務配置文件中並加密值，以便您可以編輯連接字符串以將實例X連接到數據庫Y。
4. 你們都准備好了。 我將創建或安裝本地應用程序以檢測站點的可用性。 更好的解決方案是創建一個頁面，通過編寫診斷頁面或Web服務來檢查應用程序特定組件的可用性，然后從本地計算機對其進行輪詢。

高溫超導

Answer 3

在部署到Azure時，您對SQL Server的設置沒有太多控制。 MS已經對其進行了設置，以使其高度可用。

話雖如此，MS在過去幾天似乎一直在與SQL Azure發生問題。 有人告訴我們，它僅影響“少數用戶” 。 某一時刻， 服務儀表板有5個受問題影響的數據中心。 我在其中一個數據中心中有3個數據庫，每次都關閉了兩次，每次大約一個小時，但是在另一個受影響的數據中心中的一個數據庫卻沒有中斷。

如果數據庫連接對您的應用程序至關重要，則在Azure環境中確保避免MS尚未針對其解決的問題（此最新技術問題，地震，流星撞擊）的唯一方法是將sql數據共存在另一個數據中心。 目前，最實用的方法是使用synch框架 。 可以復制SQL Azure數據庫 ，但這僅在數據中心內有效。 將數據放在其他位置時，如果主數據庫不可用，則可以將應用程序指向新數據庫。

盡管在紙面上看起來不錯，但這可能並沒有幫助您解決最新的問題，因為它確實影響了多個數據中心。 如果您只是定期制作數據庫副本，那可能足以使您順利完成工作。 或不。

（我會在服務器故障時發布此答案，但找不到問題）

Answer 4

這只是有關編程/體系結構的問題，但是您艾米也想在webmasters.stackexchange.com上提問

在得出任何結論之前，您需要找出根本原因。

然而。 我猜兩件事之一是問題

• 對於測試系統和生產系統，ISP連接有所不同。 他們要么使用不同的ISP，要么使用同一ISP的不同線路。 當我在一家托管公司工作時，我們確保IP連接至少經過兩個不同的ISPS，它們不共享光纖到我們的房屋（並且在可能的情況下，他們到建築物的物理路徑不同-反鏟的歸巢能力有一條關鍵的纖維可以挖掘

• 您的數據中心在某些共享生產基礎架構上存在問題。 這些可能是邊緣路由器，防火牆，負載平衡器，入侵檢測系統，流量整形器等。這些通常也通常僅安裝在生產系統上。 這里的防御措施包括了解體系結構並確保提供程序具有（經過測試！）DR計划，以便在事情成對發生時恢復某些服務。 我在這里看到的Neatest黑客正在說服一個IPS（入侵防御系統），說它自己的管理服務器是惡意的。 因此，您根本無法重新配置它。

只是一個想法-您的DC沒有托管任何Wikileaks鏡像或Paypal / Mastercard / Amazon（目前誰正在接受Wikileaks支持者的DDOS）？