SIOS SANless clusters High-availability Machine Learning monitoring
如果您正在考慮在AWS EC2中部署自己的Microsoft SQL Server實例，則需要就解決方案的彈性做出一些決策。 當然，如果您在不同的可用區域中部署兩個或更多實例，AWS將為您的Compute資源提供99.99％的SLA。 但不要上當，在計算真正的應用程序可用性時，還需要考慮許多其他因素。 我最近在博客上發表了有關如何在雲中計算應用程序可用性的博客。 在繼續之前，您可能應該快速閱讀該文章。
在確保Microsoft SQL Server實例高度可用時，它實際上可以歸結為兩個基本選擇：始終可用性組（AG）或SQL Server故障轉移群集實例（FCI）。 如果您正在閱讀本文，則假定您對這兩個選項都非常了解，並正在認真考慮使用SQL Server故障轉移群集實例而不是SQL Server Always On AG。
以下列表總結了AWS所說的是SQL Server FCI的優點：
當以下是您使用案例的優先考慮因素時，對於SQL Server高可用性部署，FCI通常比AG更可取：
許可證成本效率：運行AG所需的是SQL Server的企業版許可證，而運行FCI的僅需Standard Edition許可證。 它通常比企業版便宜50–60％。 儘管您可以從SQL Server 2016開始在Standard Edition上運行AG的基本版本，但它的局限性在於每個AG僅支持一個數據庫。 在處理需要多個數據庫（例如SharePoint）的應用程序時，這可能成為一個挑戰。
實例級保護與數據庫級保護：使用FCI，可以保護整個實例-如果主節點不可用，則將整個實例移到備用節點。 這將照顧存儲在系統數據庫中的SQL Server登錄名，SQL Server代理作業，證書等，這些數據庫實際上存儲在共享存儲中。 另一方面，使用AG，只能保護組中的數據庫，並且不能將系統數據庫添加到AG中-僅允許用戶數據庫。 數據庫管理員負責將更改複製到所有AG副本上的系統對象。 這留下了人為錯誤的可能性，導致數據庫無法被應用程序訪問。
DTC功能支持：如果您使用的是SQL Server 2012或2014，並且您的應用程序使用分佈式事務處理協調器（DTC），則您將無法使用AG，因為它不受支持。 在這種情況下，請使用FCI。
當然。 建立跨越可用性區域的FCI的挑戰是缺少通常需要的共享存儲設備。 因為群集的節點分佈在多個數據中心，所以傳統的SAN對於共享存儲來說不是可行的選擇。 這為集群存儲留出了兩個選擇：第三方存儲類資源，例如SIOS DataKeeper或新的Amazon FSx。
正如我在如何計算應用程序可用性中所寫的那樣，您的整體應用程序SLA僅與最弱的鏈接一樣好。 在這種情況下，FSx SLA為99.9％。
通常99.99％的可用性代表著“高可用性”的起點。 這是當兩個或多個部署在不同的可用區域中時，AWS向您承諾的計算資源。
萬一您不知道三個九與四個九之間的區別…
儘管您具有99.99％的計算可用性，但是通過將群集存儲託管在FSx上，您的整體應用程序可用性將達到99.9％。 相比之下，跨越可用性區域的EBS卷（例如在DataKeeper部署中）在存儲和計算層均符合99.99％的SLA。 這意味著您的整體應用程序可用性為99.99％。
為高可用性配置FSx時，您將需要啟用多可用區支持。 通過啟用多可用區，您可以有效地擁有“首選”可用區和“備用”可用區。 部署SQL Server FCI節點時，您將希望將這些節點分佈在相同的可用區中。
現在，在正常情況下，您將需要確保活動群集節點與首選FSx存儲節點位於相同的可用區中。 這是為了最大程度地減少存儲距離和延遲。 而且還可以最大程度地減少與跨可用區進行數據傳輸相關的成本。 根據FSx價格指南中的規定，“標準數據傳輸費適用於AZ之間或區域間對文件系統的訪問。”
在不幸的情況下，如果您遇到SQL Server FCI故障，但沒有FSx故障，則沒有將存儲和計算結合在一起的機制。 如果FSx進行故障轉移，它將自動故障恢復到主要可用性區域。 但是，最佳實踐指示SQL FCI仍在輔助節點上運行，直到執行根本原因分析並且通常計劃在維護期間進行故障回复。 這使您處於存儲位於其他可用區的情況，這將產生額外的費用。 當前，跨可用區和入口的數據傳輸成本為$ 0.01 / GB。
如果不密切關注FSx和SQL Server FCI的狀態，您甚至可能都不知道它們在不同的區域中運行，直到您在月底看到數據傳輸費用為止。
相反，在使用SIOS DataKeeper的配置中，存儲故障轉移是SQL Server FCI恢復的一部分，從而確保存儲始終通過SQL Server實例進行故障轉移。 這樣可以確保SQL Server始終在讀寫直接連接到活動節點的EBS卷。 請記住，DataKeeper將產生與在AZ或區域之間複製的寫操作相關的數據傳輸成本。 通過使用DataKeeper中可用的壓縮，可以將這種數據傳輸成本降到最低。
在FSx多子網配置中，存在首選的可用性區域和備用可用性。 如果首選可用性區域中的FSx文件服務器出現故障，備用AZ中的文件服務器將恢復。 AWS報告說，使用標準共享時，此恢復時間大約需要30秒。 通過使用連續可用的文件共享，Microsoft報告此故障轉移時間可以接近15秒。 在此故障轉移時間內，將在讀取和寫入暫停的情況下發生電源不足，但是一旦恢復完成，該電源將繼續。
FSx多站點已啟用自動故障回复。 這意味著，對於FSx的每個計劃外故障轉移，您還將具有計劃外的故障回复。 相反，通常，當SQL Server FCI經歷計劃外的故障轉移時，您要么只是使其在輔助服務器上運行，要么計劃在幾個小時後或下一個維護期間進行故障回复。
如果要群集SSAS，則需要群集磁盤資源，例如SIOS DataKeeper。 如何群集SQL Server Analysis Server白皮書明確指出無法使用SMB，並且必須使用帶驅動器號的群集驅動器。 相反，DataKeeper卷資源將其自身顯示為群集磁盤，並且可以與SSAS一起使用。
雖然FSx對於Windows用戶文件和其他非關鍵服務等典型的SMB使用肯定是有意義的，其中SLA滿足99.9％的可用性，但如果您的應用程序要求高可用性（99.99％）或還具有高可用性的HA / DR解決方案，則FSx是一個不錯的選擇區域，SIOS DataKeeper是正確的選擇。
在最近與SIOS專業服務團隊的合作中，一位客戶詢問如何使用SIOS Protection Suite for Linux解決方案保護自定義應用程序。 SIOS Technology Corp.一位經驗豐富的高可用性專家之一，幫助理解了客戶的應用程序，並列出了SIOS提供的用於自定義應用程序支持的方法。
適用於Linux的SIOS Protection Suite提供了多種向自定義應用程序添加高可用性和應用程序監視的方法。這些選項包括：
| 類型 | 編碼複雜度 | 監控方式 | 復甦 |
| 自定義應用程序恢復工具包Resource1 | 最高 | 最高 | 最高 |
| 通用應用程序資源 | 中 | 高 | 高 |
| 快速服務保護資源 | 低 | 中 | 中 |
圖表中使用的定義
監視-定義確定受保護的應用程序，數據庫或服務的可用性，可訪問性和功能的能力。較低級別的應用程序，數據庫或服務監視提供了基本的覆蓋範圍，例如，檢查正在運行的進程，是否存在pid_file或狀態命令在執行時返回“ true”結果。注意：返回值為``true''或“0（零）''並不表示該應用程序，數據庫或服務正在運行。 但是只有執行的命令才能成功完成狀態為正（“true''或“0（零）''）的結果。最高級別的監視表明，除了較低級別的方法（例如進程狀態，ps輸出或systemd狀態返回）外，還應用了特定於應用程序的知識來確定應用程序的運行狀況和功能。最高級別的監視通常會應用有關運行狀況檢查操作的建議順序的知識，相關性的知識以及對從狀態和監視命令獲得的結果的分析。
恢復-定義為重新啟動失敗的應用程序，數據庫或服務的能力。低級別的恢復能力意味著發出了用於重新啟動的命令，並且從命令的發出中獲得了預期的輸出。最高級別的監視指示特定於應用程序的知識用於確定如何啟動應用程序，數據庫或服務的有序重新啟動，這可能需要了解操作的建議順序，依賴項，回滾或對失敗的其他相關補救措施服務。
在這種參與中，客戶的應用程序具有系統兼容性。 基於避免編碼的總體要求，最少的監視需求和簡單的恢復過程，我們建議使用快速服務保護（QSP）資源。
QSP資源的工作原理是為Linux資源保護的SIOS Protection Suite快速添加對systemd服務的支持。對於Customer Example.com，他們具有系統兼容的服務，並且具有啟動和停止其應用程序所需的最低要求。
| [Unit]
Description = SIOS“現狀”示例服務2020 之後= network.target 類型=簡[Service]單 重啟=總是 RestartSec = 3 用戶= root ExecStart = / example_app / bin / exampleapp開始 ExecStop = / example_app / bin / example[Install]app停止 WantedBy =多用戶目標 |
Example.com systemd文件
SIOS建議在嘗試使用適用於Linux的SIOS Protection Suite進行資源保護之前，請通過systemctl驗證示例應用程序已停止並相應地啟動：
＃systemctl狀態示例
* example.service – SIOS“現狀”示例服務2020
已加載：已加載（/usr/lib/systemd/system/example.service；已禁用；供應商預設：已禁用）
有效：無效（無效）
＃systemctl啟動示例
＃systemctl狀態示例
* example.service – SIOS“現狀”示例服務2020
已加載：已加載（/usr/lib/systemd/system/example.service；已禁用；供應商預設：已禁用）
活動：自星期五2020-08-21 14:53:27開始活動（運行）； 5秒前
主PID：19937（exampleapp）
CGroup：/system.slice/example.service
-19937 / usr / bin / perl / example_app / bin / exampleapp開始
＃systemctl停止示例
＃systemctl狀態示例
* example.service – SIOS“現狀”示例服務2020
已加載：已加載（/usr/lib/systemd/system/example.service；已禁用；供應商預設：已禁用）
有效：無效（無效）
在通過systemd驗證應用程序正常運行後，重新啟動服務並確保服務正在運行。
＃systemctl啟動示例
＃systemctl狀態示例
* example.service – SIOS“現狀”示例服務2020
已加載：已加載（/usr/lib/systemd/system/example.service；已禁用；供應商預設：已禁用）
活動：自星期五2020-08-21 15:59開始活動（運行）； 3min 2s前
主PID：30740（exampleapp）
有關資源創建過程的更多詳細信息，請參閱適用於Linux的SIOS Protection Suite快速安裝保護套件文檔。
使用SPS-L UI選擇“創建”選項，在“全局UI資源工具欄”中通過以下圖標指示
：
啟動創建嚮導後，在“創建資源嚮導”窗口中選擇“快速服務保護”選項。
在
下一個提示“Switchback Type''的提示中，選擇使用智能切回還是自動切回。
選擇“切回類型''後，將出現``服務器''對話框，允許您選擇自定義應用程序的主服務器。
（注意：如果服務需要存儲，請確保選擇先前為存儲資源選擇的同一主服務器。）
在“服務名稱”對話框中，找到自定義應用程序的服務。
例如，選擇正確的服務後，確定要啟用監視還是禁用監視服務。請參閱文檔以了解QSP資源提供的監視。2
接下來
，選擇一個資源標籤。資源標籤應該是一個有意義的名稱，它將幫助您的IT團隊快速確定哪種SPS-L資源可以保護您的應用程序或服務。
最後，按照最後的對話完成資源創建過程。創建資源後，使用UI將資源擴展到其他服務器。 如有必要，請在新保護的自定義服務/應用程序與任何其他所需資源（例如存儲或IP資源）之間創建依賴關係。
筆記：
1可以通過與SIOS Technology Corp.專業服務團隊合作來創建客戶應用程序恢復工具包。欲了解更多信息，請聯繫professional-services@us.sios.com
2 QSP恢復工具包quickCheck只能執行簡單的運行狀況（使用service命令的“ status”操作）。 QSP不保證提供服務或過程正常運行。 如果需要復雜的啟動和/或停止操作，或者需要進行更強大的運行狀況檢查操作，則建議使用通用應用程序或自定義應用程序ARK
轉載自SIOS
休斯頓，我們有一個問題！這是一條標誌性的台詞，提醒無數太空迷和電影迷想起阿波羅13號太空任務的巨大難度，潛在的災難和危險狀態，這項任務被NASA稱為“成功失敗”。忽略自己的應用程序可用性警報可能不會在歷史上成為決定性的時刻，但也會造成類似的破壞
現在回到1970年：
“對氧氣罐進行例行攪拌會點燃其內部損壞的電線絕緣層，從而引起爆炸，從而將兩個服務模塊（SM）氧氣罐的內容物排空。 沒有呼吸和發電所需的氧氣，SM的推進和生命維持系統將無法運行。 必須關閉命令模塊（CM）的系統，以保留其剩餘的再入資源，從而迫使機組人員以救生艇的身份轉移到月球模塊（LM）。 隨著月球著陸的取消，任務負責人努力使機組人員還活著。”
氧氣罐的爆炸觸發了警報，警告，壓力和電壓下降，通信中斷，然後是宇航員與任務控制系統之間現在著名的無線電通信。但是，如果在爆炸之後機組人員什麼也沒做呢？ 如果他們從未檢查過爆炸，從未對警告和量具做出回應，也從未告知任務控制部有問題該怎麼辦？如果任務控制在控制中心的儀表板上收到通知或提醒後，從未嘗試提供任何幫助怎麼辦？如果團隊把頭埋在沙子裡，或者為了命運和機會而辭職，卻從未嘗試從遇到的失敗中學習，即興發揮或改善自己，該怎麼辦？結果將是悲慘的！它可能是一部紀錄片，但幾乎沒有一部具有標誌性線條的大片。
除非您當然在NASA工作，否則太空行走與我們的日常活動相去甚遠，但是最近有關Apollo 13的博客確實引發了一個有關可用性的問題。當您的環境中觸發警報時，您該怎麼辦？ 你只是忽略它嗎？您是否低估它，等待警報，日誌消息或其他指示符消失？您是否與供應商支持聯繫以了解如何禁用這些警報，警告和消息？還是說：“我們這裡有問題，需要解決”？
作為SIOS Technology Corp.客戶體驗的副總裁，我們在警報和指示器方面都有著豐富的經驗。我們與選擇忽略警告的客戶進行了艱苦的交流，關閉了指示問題的嚴重警報，這些警告的範圍從應用程序閾值到網絡不穩定到潛在的數據不一致。我們還看到了一些客戶，他們調動了他們的警報，調查了為什麼警報響起，發現了根本原因並享受了勞動成果。這種成果通常是提高穩定性，創新和學習或避免災難的甜蜜收穫。
警報或錯誤是否表示警告，錯誤或嚴重問題？ 幫助您和您的團隊了解關鍵性的一個好地方是查閱可用的文檔。 檢查產品文檔，在線論壇，知識庫文章（KBA）以及內部團隊數據和流程手冊。
對於警告和錯誤，它們有多大可能發展為嚴重的問題或事件。對於關鍵問題和警報，這可能很明顯，但是即使對關鍵事件進行評估，也可以為您的後續步驟提供一些指導；自我更正，問題隔離或立即升級。
您還可以訪問其他哪些來源來確定警報條件？ 例如，如果警報與存儲有關，是否還有其他工具可以揭示存儲的運行狀況？如果問題是網絡警報，是否部署了虛擬機監控程序工具，流量工具，NIC統計信息或其他專用的監視工具來幫助進行分析。
換句話說，如果不確定，請通知任務控制。 確定類型，評估即時性並諮詢其他資源之後，最好與供應商聯繫以尋求支持。關於API調用閾值的警告似乎是無害的。 但是，如果一旦達到這樣的限制，API調用將失敗，則可能導致立即採取措施。 獲得專家的授權可能有助於保持內心的平靜和避免災難。
SIOS等經驗豐富的供應商可以幫助您快速確定問題的原因並推薦最佳解決方案。
反复忽略可用性環境中的問題可能會導致意外的後果，但同樣會帶來災難性的後果。 解決由警報，日誌消息，警告指示符或其他已安裝和配置的指示符指示的問題，可以在給您的客戶，企業，團隊和您自己帶來“解決問題的機會”之前，將其變為災難。 同時，增強您的可用性策略和基礎架構。您會選擇哪一個？
– Cassius Rhue，客戶體驗副總裁
轉載自SIOS
