如果您要使用開源高可用性，那麼團隊需要具備七項技能

在高可用性（HA）領域中，如果您決定採用開源方式，則團隊需要掌握某些重要技能。 開源的定義是指可以免費使用的軟件。

如今，微軟和SIOS Technology Corp等供應商為許多操作系統提供了高可用性集群的多種商業實現方案。這些商業解決方案提供了資源監視，依賴性管理，故障轉移和集群策略以及某種形式的預先打包和定價的管理方案。商業實現的替代方法是幾種開源選項，這些選項也使公司有機會為其企業提供高可用性。

隨著公司繼續尋求優化，節省成本和潛在的更嚴格控制，越來越多的公司和客戶也正在考慮轉向開源可用性解決方案。

要遷移到開源HA，您的團隊可能需要具備以下7種技能：

1.編碼技巧

在許多情況下，缺少對企業應用程序的預打包和捆綁支持意味著您的團隊將需要能夠開發解決方案來保護組件，解決捆綁組件的問題或編寫應用程序連接器以確保正確處理應用程序意識。很多人都可以編寫腳本，但是您的團隊將需要知道如何創建並遵守合理的開發實踐和標準。這方面的基本知識包括：

• 設計和架構要求
• 設計評論
• 代碼/代碼審查和單元測試（最好是自動化的）

2.對技術環境的了解

許多企業應用程序需要與多個系統集成，以提供滿足服務水平協議（SLA）和服務水平目標（SLO）的高可用性。您的團隊將需要深刻的應用程序意識和對技術環境的了解，才能為與多個企業系統的集成建立保護和解決方案。您需要了解關鍵應用程序的來龍去脈，這些應用程序的技術環境，網絡，硬件，虛擬機管理程序以及對環境和應用程序依賴性的了解的人員。您還需要團隊成員了解開放源代碼社區中打算使用的HA技術的體系結構，功能和局限性。 考慮一下您的團隊了解和了解的這些領域中的多少：

• 數據傳遞和節點通信
• 節點故障
• 應用管理
• 系統恢復並重新啟動
• 記錄和消息
• 數據彈性和保護

3.業務流程知識

您需要有人來了解您的業務需求和業務流程。您的團隊需要專業人士，他們需要了解企業的業務以及推動業務發展的流程。您的團隊將需要了解和了解有多少預算可用於開發解決方案，企業願意承擔多少風險，以及如何收集可能未講或未指定的其他要求。

團隊還需要知道或聘請知道如何將這些業務需求轉換為軟件需求以及如何管理流程以實現最低可行的高可用性解決方案以實現滿足業務需求的成果的人，或者業務，並適合業務流程。

4.具有操作系統，應用程序和基礎架構的經驗

如果您想全力以赴，您的團隊將需要了解操作系統，應用程序和基礎架構的經驗。您需要了解各種操作系統的發行週期，包括Linux的內核版本，Windows的更新和修補程序。您內部有需要支持的應用程序，但也需要勤勉地了解應用程序更新周期，它們的依賴性以及應用程序和操作系統支持矩陣的交集。如果您的環境是均勻的，那就太好了。否則，您的團隊將需要了解RHEL，RHEL派生產品和SUSE之間的區別。如果您同時使用Linux和Windows，則也需要了解它們。您還需要了解基礎架構對應用程序和操作系統組合的影響。AWS和Azure呈現的高可用性差異與GCP，本地和其他虛擬機管理程序有所不同。

5.變更管理能力

想像一下，您擁有一支具有技術和業務知識以及對操作系統，基礎架構和應用程序有紮實了解的開發團隊來創建解決方案。但是，將腳本放在一起僅僅是個開始。您的團隊還需要變更管理功能。您的團隊將如何跟踪代碼更改以及版本，軟件包和軟件包位置？您的團隊將如何管理更新和變更的發布？您的團隊將需要精通git等源代碼存儲庫，Jira等項目管理工具以及發布訓練的熟練程度。您需要一個了解如何進行代碼更新，提供補丁和修復程序，同時又能避免不必要的影響的團隊。

6.數據分析和故障排除經驗

當您進入交付自己的HA解決方案的空間時，您的團隊將需要分析和故障排除經驗。您需要擁有能夠理解應用程序代碼，系統消息以及應用程序錯誤日誌和跟踪文件的交集的資源。發生系統崩潰時，您將不得不更深入地研究日誌以進行故障排除並找到根本原因，分析數據以提出建議，並準備推出更改（請參見上面的＃5）。別忘了，即使沒有錯誤，故障或系統崩潰，您的團隊也需要了解並了解這些日誌和跟踪文件中的數據可以告訴您環境的運行狀況。

7.連接（開發，質量檢查，合作夥伴，社區）

坦白說，您的業務不是要提供高可用性，但是，如果您決定涉足開源HA領域，那麼您不僅需要團隊的智慧，還需要更多的幫助。獲得額外幫助的關鍵是了解從何處開始，然後與社區開發人員，測試專家，HA和應用程序合作夥伴以及開源社區建立正確的聯繫。開放式論壇確實很有幫助，但是您需要仔細檢查響應時間是否符合您的SLA和SLO。

使用開放源代碼解決方案是許多公司選擇的一種選擇，以解決成本問題並意識到靈活性，更低的成本和更低的風險。但是，買方要當心，新技能和管理形式可能存在隱性成本，而使用“開源自己的HA解決方案”所需的開源程序也存在隱性風險。

–客戶體驗副總裁Cassius Rhue

轉載自SIOS

在2020年，我們看到越來越多的企業將更多的任務關鍵型應用程序，ERP和數據庫遷移到雲中。 但是，並非所有這些遷移都很順利。 我親眼目睹了由於缺乏對應用程序可用性的規劃，“ DIY高可用性”改造的複雜性，與“提升和轉變”所帶來的誤解以及意外成本有關的雲遷移項目急劇減慢，甚至停止了。

組織可以採用多種最佳實踐，雲清單和其他方式為雲做準備。 對於那些在2020年雲遷移方面遇到停頓或計劃在2021年取得進步的人們，在高可用性群集的每種遷移策略中都應考慮以下最佳實踐。

雲遷移最佳實踐

收集需求

許多遷移到雲的組織都認為雲是遷移到雲的本地架構。 當內部部署的網絡，存儲，磁盤速度和系統大小與雲現實發生衝突時，對雲遷移的這種誤解通常會導致停頓和延遲。 向雲的更平滑過渡始於收集對基礎架構，治理和合規性，安全性，規模以及相關控制和資源的實際需求。

設計與文件

在設計階段，將本地環境的體系結構映射到已選擇以實現最大可用性並進行了詳細記錄的雲環境。 在此階段，隨著架構的形成，您將確定IP，負載均衡器，IOPS和數據可用性的策略。 團隊需要研究如何通過能夠自動實現雲複雜性的強大應用程序和基礎架構可用性解決方案來增強雲固有的可用性。 在SIOS，我們的AWS和Azure群集及可用性專家與客戶合作，將本地NFS交換為AWS EFS，Azure ANF或獨立的NFS群集層。 此外，此階段成功實施的關鍵部分將記錄所有內容。 文檔是遷移成功的一個經常被忽略但必不可少的要素。

計劃高可用性

要在雲中實現高可用性，需要了解需求，創建設計並記錄計劃以規劃實現這些需求的策略的計劃。 基本計劃應包括人員配備，人員培訓，部署QA系統測試，生產前步驟，部署，部署後驗證以及正在進行的迭代。 雲遷移的最佳結果來自經過深思熟慮的計劃流程；不是臨時的，固定的解決方法。

職員

您的團隊為雲遷移配備了多少人員？ 傳統的服務台，客戶/服務器IT或IT團隊可能不足以進行雲遷移。 如果您的團隊是雲計算的新手，那麼也許是時候考慮添加更多資源或基於專業服務的解決方案了。 如果沒有適當的見識，信息或培訓，遷移到雲可能會很繁瑣，繁瑣且困難。 您的員工是否需要納入與雲環境相關的培訓？ 在尋找培訓和專業服務以協助您的IT團隊時，請與您的供應商聯繫以獲取有關可用性解決方案的培訓。 許多供應商為高可用性解決方案提供了靈活的培訓，可以通過雲供應商或諸如Udemy之類的流行站點獲得云培訓。

部署質量檢查

QA部署階段是團隊執行將實際系統部署到雲中的計劃的階段。 成功的部署團隊將驗證其計劃和策略，了解數據遷移過程，發現所有遺漏的依賴項，並為過程的下一步做準備，尤其是測試。 當跳過或跳過此步驟時，曾經有希望的遷移通常會停滯不前或失敗。 當您進入質量檢查系統部署階段時，您的團隊將繁重地進行雲中應用程序，數據庫和關鍵數據的初始遷移和配置。

測試您的高可用性

在您的質量檢查環境中進行測試是至關重要的一步。 這些測試不是浪費時間；他們節省時間。 與在本地部署相比，在雲中部署環境通常更容易。 您的質量檢查環境可以使用諸如Ansible之類的工具編寫腳本，可以作為雲市場中的模板或克隆映像快速部署，也可以根據云形成模板進行部署和構建。 部署後，可以在災難發生之前（而不是在災難發生之前）對災難場景進行熨平和優化。 可以利用測試方案來確定網絡，磁盤速度方面的過度配置，配置不足或瓶頸。 完整的測試方案也可以用作新員工入職策略的一部分。 此外，還應該對快照和備份執行測試。

部署生產

當測試階段完成並且您的團隊已驗證測試結果時，下一個階段是從質量檢查過渡到預生產，再從預生產過渡到上線。 測試階段是繁重的最後階段，涉及最終用戶驗收測試，最終生產數據的轉換和更新，然後是用戶。

審閱，修訂和重複

成功遷移到上線階段並不會結束，而是會持續到生命週期階段。 在雲遷移策略的上線階段中，您的團隊將繼續審查，修訂和重複從“收集”到“部署生產”的步驟。 實際上，您的團隊應根據特定於發行版，應用程序更新，安全更新，相關係統維護，操作系統版本，災難恢復計劃以及高可用性供應商自身最佳要求的要求來一次又一次地重複此過程。實踐。 雲平台一直在發展，並增加了可以增強您現有的HA解決方案和體系結構的新功能，新功能和更新。 審查，修訂和重複該過程將是成功入職的必要步驟。

在2021年，我們將看到更多的企業將更多的關鍵任務應用程序，ERP和數據庫遷移到雲中。 成功的關鍵因素將是利用雲遷移最佳實踐來避免整個過程中的延遲和失敗。 了解您的業務需求和需求，記錄設計和計劃，在具有特定目的的群集解決方案的QA環境中進行部署以及在上線之前執行廣泛的測試至關重要。 請與SIOS技術部門聯繫，以了解如何將SIOS保護套件包含在周到的雲遷移最佳實踐中。

-客戶體驗副總裁Cassius Rhue

轉載自SIOS

如何構建高度可用的服務器解決方案？

任何高可用性解決方案的關鍵組成部分都是弄清楚如何重定向客戶端流量。 幾乎每個基於用戶的應用程序都需要連接到服務器。 重定向客戶端流量將允許用戶連接，而不必知道應用程序或數據庫實際位於何處。

大多數解決方案建議基於網絡的IP重定向或基於網絡的DNS重定向。 這行得通。 但是，根據我們的經驗，針對高可用性服務器的最佳解決方案是使用可以從一台服務器切換到另一台服務器的虛擬IP地址。 該服務器正在監聽來自虛擬IP地址的連接，該地址今天託管在一台服務器上，另一天又切換到另一台。

要更進一步，您可以使故障轉移自動化。 在此處，系統會做出決策並在檢測到故障時切換應用程序。 請記住，此步驟是構建高可用性解決方案的關鍵。

購買與構建高可用性解決方案的好處

這可以使用腳本和邏輯來檢查從一台服務器到另一台服務器的進程和虛擬IP地址的狀態來實現。 但是，我們在購買與構建高可用性解決方案中面臨的挑戰之一是，我們真正需要花費多少時間來構建。 這包括進行腳本編碼，API開發（例如cloudwatch API或lambda函數）的時間。 讓我們不要忘記測試和維護。

小時候，我很想寫那個代碼。 但是在為《財富》 100強公司工作之後，並被一位高級經理大喊大叫之後，當我的一個腳本在凌晨3點無法正常工作時，我的感受就不同了。 當我發現一年前編寫的代碼的問題時，這個問題更加嚴重。 我的經理們希望這種高度可用的解決方案能夠100％工作。 如果沒有用，請花時間打電話給某人並大喊大叫。

SIOS實現高可用性自動化

從長遠來看，購買解決方案並花一點時間對其進行調整以適應我們的環境是否更便宜？ 無論應用程序或數據庫如何，這都是SIOS高可用性（HA）解決方案出現的地方。 SIOS具有將進程堆棧從一台服務器切換到另一台服務器的代碼。 這使用戶和管理人員可以放心地從自動執行故障轉移流程和高可用性而來。

關於SIOS HA傘，我最喜歡兩件事。 第一，虛擬IP的代碼，其中IP地址已添加到服務器，並且應用程序重新啟動以偵聽連接。 第二個是通過使用SIOS提供的與應用程序無關的API集啟用的。 這樣，任何人都可以使用插件來保護任何應用程序。 立即聯繫SIOS，以了解有關您的環境的高可用性解決方案的更多信息。

– Edmond Melkomian，PMP，MCSD，SIOS Technology，Inc.顧問

轉載自SIOS

IT災難恢復的痛苦階段

如果您沒有實施正確的企業可用性體系結構，災難恢復的痛苦可能使您無所適從。 在IT中與我們的朋友Dave會面，向我們介紹災難的5個階段。

階段1：拒絕

Dave in IT：“哦，哦。那是什麼警報？只是有一點應用程序崩潰，對嗎？沒什麼大不了。我將立即啟動並運行。”

在企業可用性方面，幾乎沒有應用程序崩潰或沒什麼大不了的事情。公司擁有SLA，並且擁有真實的資金。您的選擇現實可能與您的客戶和利益相關者的觀點不同。

階段2：憤怒

戴夫（Dave）：“你在開玩笑嗎？在所有時間[censored]中……今天，該應用程序將無法啟動。嗯我討厭這[censored]個…[censored]…應用程序。等等，這是什麼新提醒。嚴重的是，現在，數據中心已關閉！”

在快速的節奏和高風險的環境中，它確實變得非常非常雜亂。 當未經檢查的警報和故障發生時，問題會隨著壓力，沮喪和憤怒而迅速增加。

狀態3：討價還價

IT中的Dave：“嘿，在應用程序中，這就是IT中的Dave。你們有App1環境的任何備份嗎？ 。 。你確定嗎？您能再檢查一次嗎？我知道您已經檢查了兩次，但您可以再檢查一次。我要在星期二的Taco買飲料！”

Dave in IT：“嘿Donna DBA，這就是Dave in IT。 應用程序中的Art表示您可能會幫助我。您是否偶然為該財務數據庫或庫存管理系統設置了任何數據庫複製？ 。 。 。 你確定嗎？嗯，你還記得我們是否有辦法從嗯中恢復過來。 。 。數據中心崩潰了？”

當我的女兒遇到麻煩時，討價還價是她的第一個去。好的，第二。首先是消失，但你太聰明了，只能走開火焰。但是，IT中的戴夫（Dave）並不是唯一意識到討價還價和乞討不能很好地替代為高可用性和災難恢復制定明確策略的人。跳過討價還價，乞求您的災難，因為“ 80％的人不在乎，而20％的人很高興是您（由Les Brown改寫）。”

階段4：悲傷

Dave in IT：“這真是太好了。應用程序服務器崩潰，數據中心已關閉，如果可以找到備份並可以加載它們，備份將需要幾個小時才能恢復。我沒有辦法擺脫……我把更新的簡歷放在哪裡了。”

當然，您有備份，並且已經對其進行了驗證。但是回到這些備份會對RTO和RPO產生影響。這次你能吸收嗎？當然，那是在您的數據中心恢復之後。

步驟5：驗收

戴夫（Dave）：“已經兩個小時了。我從來不知道我們以前有這麼多的執行干係人。在那之後我永遠都無法慶祝自己的2週年紀念日。好吧，我想明天我要打掃辦公室。我絕對不可能做到這一點！”

失敗會發生。數據中心出現故障。應用程序失敗。不能否認丟失數據中心，服務器故障或應用程序崩潰的可能性。這種接受是正常的，這是提高可用性的一部分。SIOS Technology Corp.的專家希望確保避免因無法實施可用性策略而失業或變得更糟。

不要像IT中的Dave。通過設計和實施企業可用性架構來避免災難性災難以及災難恢復和停機時間，該架構包括最佳的混合，內部部署或云以及最佳的監視，恢復和系統故障轉移自動化解決方案。

–客戶體驗副總裁Cassius Rhue

轉載自SIOS