＃IGNITE2018會話：通過基於雲的災難恢復，Azure Site Recovery確保應用程序可用性

我是Azure Site Recovery for Disaster Recovery的忠實粉絲所以，我很高興參加今天由Rochak Mittal和Ashish Gangwar BRK3304呈現的Ignite會議 – 在Azure上構建關鍵任務，高性能SAP工作負載此會議關於確保應用程序可用性基於雲的災難恢復，Azure Site Recovery提供了特別豐富的信息。在其中一個體系結構幻燈片中，他們展示瞭如何通過Azure Site Recovery（ASR）保護整個SAP部署，並在幾分鐘內發生災難時恢復。使用Azure恢復計劃可以讓您明確控制恢復。它包括創建對資源的依賴關係以及在VM中調用腳本以幫助促進完全恢復。好像昨天。但它早在2014年5月，當時我第一次開始協助微軟為Azure中的SAP ASCS提供HA解決方案。該解決方案涉及使用DataKeeper為ASCS構建SANless集群解決方案。它仍然是今天唯一的HA解決方案，它也可以與ASR一起用於災難恢復配置，例如Ignite的演示中所示。 Azure中的共享磁盤與SIOS DataKeeper [/ caption]想知道如何通過基於雲的災難恢復，Azure Site Recovery確保應用程序可用性，讓我們來看看知道，我們很樂意提供幫助。經Clusteringformeremortals.com許可轉載

循序漸進：如何從Windows性能監視器觸發電子郵件警報

Windows性能計數器警報可以配置為通過使用用戶定義的數據收集器集在任何性能監視器（Perfmon）計數器上觸發。但是，如果您希望在觸發警報時通過電子郵件收到通知，則必須使用Perfmon，任務計劃程序和好的'Powershell'的組合。按照以下步驟從Windows性能監視器觸發電子郵件警報。

第1步 – 編寫Powershell腳本

您需要做的第一件事是編寫一個Powershell腳本，在運行時可以發送電子郵件。在研究這個問題時，我發現了很多方法來完成這項任務。 我要向您展示的只是一種方式，但您可以隨意嘗試並使用適合您環境的方法。在我的實驗室中，我沒有運行自己的SMTP服務器。我編寫了一個可以利用我的Gmail帳戶的腳本。您將在我的Powershell腳本中看到，對SMTP服務器進行身份驗證的電子郵件帳戶的密碼是純文本格式。如果您擔心某人可能有權訪問您的腳本並發現您的密碼，那麼您將需要加密您的憑據。Gmail需要和SSL連接。您的密碼應該是安全的，就像任何其他電子郵件客戶端一樣。以下是與Task Scheduler和Perfmon結合使用時Powershell腳本的示例。它們可以在滿足任何用戶定義的性能計數器閾值條件時自動發送電子郵件警報。在我的環境中，我將其設置為C： Alerts Alerts.ps1

$ counter = $ Args [0]
$ dtandtime = $ Args [1]
$ ctr_value = $ Args [2]
$ threshold = $ Args [3]
$ value = $ Args [4]
$文件名=“$ ENV：計算機名”
$ EmailFrom =“sios@medfordband.com”
$ EmailTo =“dave@medfordband.com”
$ Subject =“來自$ FileName的警報”
$ Body =“數據和警報時間：$ dtandtime`nPerfmon計數器：$ ctr_value`nThreshold值：$ threshold`n當前值：$ value”
$ SMTPServer =“smtp.gmail.com”
$ SMTPClient = New-Object Net.Mail.SmtpClient（$ SmtpServer，587）
$ SMTPClient.EnableSsl = $ true
$ SMTPClient.Credentials = New-Object System.Net.NetworkCredential（“sios@medfordband.com”，“ChangeMe123”）;
$ SMTPClient.Send（$ EmailFrom，$ EmailTo，$ Subject，$ Body）

從Powershell腳本生成的電子郵件示例如下所示。 你可能已經註意到這個Powershell腳本有四個參數。它還將它們分配給輸出中使用的變量。它將計算機名稱保存到變量中，該變量用作輸出的一部分。通過這樣做，該腳本可用於在任何Perfmon警報計數器和任何服務器上發送電子郵件，而無需額外的自定義。

第2步 – 設置計劃任務

在任務計劃程序中，我們將在以下屏幕截圖中顯示創建新任務。 為任務命名，您需要記住它以進行下一步。 請注意，沒有觸發器。此任務實際上將通過我們將在步驟3中設置的Perfmon計數器警報觸發。 您想在“操作”選項卡上定義新操作。操作將是啟動程序並使用以下輸入。請根據您的具體環境進行調整。程序腳本：C： Windows System32 WindowsPowerShell v1.0 powershell.exe添加參數：-File C： Alerts Alerts.ps1 $（Arg0）

第3步 – 創建性能計數器

創建新的數據收集器集添加要監視的性能計數器並設置警報閾值。 創建數據收集器集後，請進入其屬性，並確保為每個性能計數器正確設置警報閾值和样本間隔。請記住，如果您每10秒採樣一次，那麼只要性能計數器超過您設置的閾值，您就應該每隔10秒收到一封電子郵件。 如果選擇在應用程序事件日誌中記錄條目，則不希望在正常的應用程序事件日誌中看到任何條目。它將寫入應用程序和服務日誌目錄中的Microsoft-Windows-Diagnosis-PLA / Operational日誌。 然後最後我們必須設置一個警報任務，它將觸發我們在步驟2中創建的計劃任務（EmailAlert）。您會看到我們還傳遞了一些Powershell腳本使用的Task參數，以自定義具有與Alert相關的確切錯誤條件的電子郵件。 正確配置Data Collector後，您將需要啟動它。 如果您正確配置了所有內容，則應在滿足警報閾值時開始查看電子郵件。如果它似乎不起作用，請檢查以下內容……

• 手動運行Powershell腳本以確保其有效。您可能需要手動設置一些變量以用於測試目的。在我的情況下，需要稍微調整以使Powershell腳本正常工作，所以從此開始。
• 檢查任務歷史記錄以確保警報計數器正在觸發任務。
• 手動運行任務，看它是否觸發Powershell。

步驟4 – 將性能計數器設置為自動運行

如果您認為已全部設置為從Windows性能監視器觸發電子郵件警報，則還有一個步驟。每當您重新啟動服務器時，Perfmon Counter Alert都不會自動啟動。為了在重新啟動後繼續運行，您必須在命令提示符下運行以下命令。注意下面腳本中引用的“警報”是我的用戶定義的數據收集器集的名稱。

schtasks / create / tn Alerts / sc onstart / tr“logman start Alerts”/ ru system

有一些邊緣情況，您可能需要創建另一個觸發器來啟動Data Collector集。例如，SIOS DataKeeper Perfmon計數器僅從鏡像源收集數據。如果您嘗試在目標服務器上啟動數據收集集，您將看到它無法啟動。但是，如果您的群集進行故障轉移，則舊目標現在將成為鏡像的源，因此您需要開始監視該新源上的DataKeeper計數器。您可以創建一個群集通用腳本資源，在故障轉移時啟動數據收集器集，但這是另一個主題。確保計數器在新源上運行的更簡單方法是設置由EventID觸發的計劃任務，該事件ID指示服務器正在成為鏡像源。在這種情況下，我在兩個系統上設置觸發器，以便每次發生EventID 23時，Trigger運行Logman以啟動數據收集器集。每次發生故障轉移時，新系統成為源時會記錄事件ID 23，因此數據收集器集將自動開始。 就是這樣，如果您關心的任何Perfmon計數器開始失控，您現在可以直接從您的服務器接收電子郵件警報。

發生了什麼？這是我們的Azure Outage Post Mortem第2部分

我之前的博客文章稱，雲到雲或混合雲可以讓您與CSP可能遇到的任何問題隔離開來。但是，如果在中南部地區提供可用區，則可以避免由此自然災害造成的大部分停機時間。微軟發布了9月4日南中央停電的初步RCA。整個摘要中最重要的部分如下……

“儘管有現實的冗餘，有一些情景，其中一個數據中心的冷卻故障會影響受影響的數據中心的客戶工作。”

這對你來說代表著什麼？

如果您的應用程序都在同一個數據中心運行，那麼您將來可能會遇到相同類型的中斷。在微軟的辯護中，這對你來說真的不應該是新聞。無論您是在Azure，AWS，Google還是自己的數據中心運行，這一直都是如此。未能提前計劃將數據複製到不同的數據中心以及製定快速恢復應用程序的計劃只是缺乏您的計劃。Microsoft未發布確切的可用區位置。如果你相信這張地圖發表在這裡，你可能會猜到它們可能相距2-10英里。 除了最極端的情況之外，在可用區之間複製數據應該足以用於數據保護。某些應用程序（如SQL Server）內置了複製技術。但是，對於廣泛的應用程序，操作系統和數據類型，請研究塊級複製SANless群集解決方案。SANless集群解決方案傳統上用於多站點集群。但是，相同的技術也可以在可用區，區域或混合雲中的雲中使用，以實現高可用性和災難恢復。無論是Azure，AWS還是Google，實施跨越可用區的SANless群集都是一個非常簡單的過程，只需要合適的工具。作為宰藍式停電事件的一部分，這裡有一些資源可以幫助您入門。循序漸進：在Azure中配置跨越可用區的文件服務器群集如何在Google Cloud Platform中構建SANless SQL Server故障轉移群集實例MS SQL Server v.Next在具有復制和高可用性的Linux上#Azure #Cloud #Linux在AWS快速入門中的AWS SANless Linux群集中的#Azure資源管理器（ARM）SAN SANless SQL Server群集中部署Microsoft SQL Server 2014故障轉移群集

Azure Outage Post Mortem的教訓

如果您在Azure中，則可能還需要考慮Azure站點恢復（ASR）。ASR允許您將整個VM從一個Azure區域複製到另一個區域。ASR將實時復制您的虛擬機，並允許您隨時進行無中斷的災難恢復測試。它支持大多數版本的Windows和Linux，並且相對容易設置。您還可以創建具有“多VM一致性”的複製作業。這意味著必須從完全相同的時間點恢復服務器，這些時間點可以放在此一致性組中，並且它們將具有完全相同的恢復點。實質上，如果您在單個區域中構建具有DataKeeper的SANless群集以實現高可用性，則DR有兩個選項。一種是您可以將SANless群集擴展到不同區域中的節點，或者可以使用ASR複製一致性組中的兩個節點。

有什麼不同？

與ASR的權衡是RPO和RTO不如使用SANless多站點群集那麼好。雖然它很容易配置並適用於任何應用程序。小心點 如果您的應用程序定期超過10 MBps的磁盤寫入活動，ASR將無法跟上。此外，基於Storage Spaces Direct的群集無法使用ASR進行複制，並且在Azure中使用時通常缺乏良好的DR策略。管理磁盤發布後的一段時間，ASR直到大約一年後才完全支持它們。對於許多希望使用ASR的人來說，對託管磁盤的全面支持是一個很大的障礙。幸運的是，從2018年2月開始，ASR完全支持託管磁盤。但是，剛剛引入了另一個問題。隨著可用區的引入，ASR再次落後於時代。它們目前不支持已部署在可用區中的VM。

無論如何我繼續嘗試了。似乎可以配置複製，我能夠進行測試故障轉移。

了解有關Azure Outage Post Mortem的分析的更多信息，經過Clusteringformeremortals.com的許可轉載