SIOS SANless clusters High-availability Machine Learning monitoring
在本集中TFiR：我們來談談，主持人 Swapnil Bhartiya 接受採訪戴夫·伯明翰SIOS Technology 的客戶成功總監談到了高可用性和彈性為何對企業至關重要。樓宇維護與保全系統伯明罕解釋了這些系統與其他樓宇技術的區別，以及它們之間經常存在的互動方式，並闡述了不間斷運作對於保障居住者安全和樓宇功能的重要性。對話探討了組織如何平衡安全性和可訪問性，人工智慧、機器學習和物聯網等新興技術在提升可靠性方面的作用，以及透過冗餘、監控和風險規劃來確保系統可用性的最佳實踐。
作者：Beth Winkowski，SIOS Technology Corp. 公共關係部
經許可轉載SIOS
迄今為止，本系列文章探討了技術設計與修辭之間的相似之處。技術方案的“修辭”，即傳達意義和目的的策略，是透過設計模式和概念來呈現的。設計模式和概念作為概念基礎而存在，其意義在實施過程中轉化為可應用的形式。
如前所述，這種連續性和完整性概念基礎確保解決方案始終保持符合維護、改進和長期可靠性標準的要求至關重要。外部影響解決方案設計的因素挑戰旨在維護解決方案設計中提出的概念基礎的目標。這些外部因素可能與既定原則相衝突，因此，解決方案中使用的工具、應用程式和平台必須經過慎重選擇。
在本部落格系列的第三部分也是最後一部分中，我們將探討模組化和抽象化作為一種設定界限的手段，以確保廣泛的項目能夠繼續從結構良好、論證合理的設計中獲益。
在探討模組化和抽象化這兩種策略之前，首先需要先理解為什麼要實施它們。我們可以用一個類比來說明：演講者為了說服聽眾接受自己的方案，首先需要闡述幾個基本要點。這樣，他們就能逐一提出並論證論點的各個支柱。
演講者首先必須建立「A蘊含B」與「C蘊含D」的基礎，在此基礎上才能建構「B和D蘊含E」的論證。這種策略確保了「A蘊含B」的推理不會與「C蘊含D」這個獨立論點相互幹擾，從而避免削弱後者。這種策略之所以被廣泛運用，是因為它允許演講者論證的每個組成部分獨立存在。即使「C蘊含D」的論證有缺陷，也可以透過其他方式加以修正，而「A蘊含B」的論證仍然有效。
這種結構的原因與技術系統採用去中心化的原因相同——銷售點系統的問題可以單獨解決，而無需將修復工作擴展到資料庫、API、網路架構等等。上述策略當然是指模組化和抽象的概念。
首先，談到模組化，它指的是用自包含的元件來建構系統。從修辭意義上講，「A蘊含B」和「C蘊含D」這兩個論證只是推理模組，它們被組合成一個完整的論證。
更具體地說，模組化組件（例如前面例子中的銷售點系統）允許在問題產生的模組內部完全解決問題。解決方案中的每個模組都像一個構建塊，單個構建塊中的問題無需拆卸整個解決方案即可解決。
與模組化密切相關的是「抽象」。抽像是指確保整體解決方案的設計獨立於構成該整體解決方案的各個模組的設計，並且與這些模組的設計無關。
此外，抽象化作為一種設計策略，其核心在於每個模組都是獨立且與其他模組的設計無關的。當解決方案採用抽像元素時，這些元素可以重複使用並應用於各種用例，從而在整個專案中加深理解。
當設計採用模組化組件時，需要劃定邊界。這些邊界確保每個模組都能「互不干擾」。當元件被抽象化後，每個模組的內容就更容易理解。
反過來，這些邊界構成了一種結構，透過這種結構可以理解設計；而邊界內的抽象則為理解用例的基礎提供了切入點。模組化和抽象所提供的結構，與修辭在建構理解目的的框架中所扮演的角色相呼應。
隨著技術解決方案的不斷開發以應對日益複雜的問題，對這些解決方案設計中穩固框架的需求也日益增長。網路架構通常是眾多本身就十分複雜的解決方案的最終產物，它完美地詮釋了日益複雜的問題以及對穩固設計框架日益增長的需求。此外，網路架構往往面臨持續成長的挑戰，因為它必須整合為實現業務目標而不斷擴展的龐大系統網路。
在此基礎上，解決方案架構也必須採用以下解決方案：高可用性和/或災難復原這會造成設計衝突的發生，但可以透過模組化和抽象化的策略輕鬆緩解。
好處高可用性軟體無需繁瑣的設計和臨時拼湊的解決方案，即可實現高可用性。 SIOS LifeKeeper 就是一個符合設計規範的高可用性工具範例，其運作原理能夠與使用環境無縫整合。
LifeKeeper 採用模組化設計，不會對受 LifeKeeper 保護的系統以外的系統提出任何要求。 LifeKeeper 還有助於將基礎設施元件抽象化為易於管理的小單元——協同工作以確保可用性的系統被分組到一個「集群」中。
透過這種抽象，環境的邏輯依然清晰——理解一個集群的構成是理解所有集群的基礎。設計的各個層級可以根據其用途進行理解；無需對不同實現方式的差異進行特殊標註和考慮。由於各個集群獨立於其他集群或外部解決方案元件運行，因此可以劃定一個邊界，將每一層級的設計元素包含在其中，從而避免與其他基礎設施層級發生衝突。
就像任何軟體或工具一樣，SIOS 保護套件SIOS LifeKeeper 和/或 SIOS DataKeeper 會影響其使用環境的設計。雖然這些模式的引入源自於 LifeKeeper 和 DataKeeper 的保護環境，但 SIOS LifeKeeper 和 SIOS DataKeeper 精心挑選了所使用的模式，以確保這些模式能夠實現整個解決方案的抽象和模組化。由於 LifeKeeper 和 DataKeeper 實現了分層抽象，這些實用程式的引入有助於與 IT 基礎架構集成，從而保持解決方案設計的一致性。
由於採用了特定的設計模式，由 SIOS Protection Suite（LifeKeeper 和/或 DataKeeper）保護的叢集構成了一個抽象且模組化的元素，能夠無縫整合到現有的設計和解決方案中。 LifeKeeper 和 DataKeeper 的功能遠不止於簡化單一系統或各個集群的管理；它們也與部署過程中遵循的原則相契合。
透過 SIOS Protection Suite，基礎架構的創建變得更加簡單且有效率。該套件提供了一種簡單的方法來理解系統在設計中的作用，同時也提供了一種簡單的方法來實施高可用性和災難復原。管理員可以將 LifeKeeper 和 DataKeeper 作為工具，在未來幾年內更好地理解、操作和改進解決方案。
了解高可用性如何在不增加複雜性的情況下支援您的基礎架構設計。立即申請演示！
作者：Philip Merry，SIOS 的客戶體驗軟體工程師
經許可轉載SIOS
對於管理現代應用程式的IT團隊而言保持高可用性推出更新可能充滿挑戰。實現可靠性的關鍵在於將品質保證 (QA) 環境與生產環境分開。這看似微不足道，但對於發現潛在問題和增強維護工作的信心至關重要。
QA環境是生產環境的副本。它提供了一個沙箱，可以在其中對新功能、配置變更和修補程式進行全面測試。除了功能測試之外，QA環境還支援流程驗證、效能基準測試、負載測試和安全驗證。
這些活動至關重要，可以在瓶頸、漏洞或整合問題有機會影響最終用戶或損害您的環境之前，識別它們。對於分散式系統或雲端架構QA 環境可以幫助模擬網路延遲、資料庫複製延遲以及其他操作邊緣情況，這些情況如果不經過測試，可能會中斷業務營運。
生產環境是最終使用者依賴系統穩定運作的環境。任何計劃外停機或故障都可能直接導致業務損失，從收入損失到聲譽受損不等。
透過將生產環境與正在進行的開發和測試工作隔離，IT 團隊可以確保營運穩定性。配置完善的生產環境應包括：冗餘策略故障轉移機制和監控工具在部署前已在品質保證環境中通過測試驗證。
高可用性不僅意味著保持系統正常運行，它還包括使更新可預測。 QA 環境可以支援結構化的部署流程，從而實現分階段發布和藍綠發布等多種策略。在 QA 環境中預先驗證的回溯流程，能夠幫助團隊在出現意外問題時快速復原。結構化的方法使更新可預測，並有助於維護客戶信任。
擁有獨立的品質保證 (QA) 和生產環境也有助於合規性、審計準備和跨團隊協作。測試系統和生產系統之間的清晰界限有助於維運和開發團隊高效協作。它還有助於為監控、故障排除和維護提供可重複的框架。災難復原計劃。
品質保證 (QA) 和生產環境在確保系統平穩運作方面發揮著至關重要的作用。透過隔離環境、進行全面測試以及謹慎管理部署，IT 團隊可以減少停機時間、保持高可用性，並實現無縫更新過渡。這些實踐有助於確保系統在發展過程中保持可靠性和彈性。
準備好提升品質保證和生產環境的高可用性了嗎？申請演示了解 SIOS 如何幫助團隊自信地部署更新並保持關鍵系統運作。
作者：Tristan Allen，SIOS Technology公司客戶體驗軟體工程師
經 SIOS 授權轉載
「關機重開機。」任何有電腦故障排除經驗的人都聽過這項建議。它臭名昭著，是最常見的技術解決方案，而且似乎能讓每個人都變成IT故障排除高手。問題在於，它從來都不是真正的解決方案；它只是碰巧能解決大多數問題而已。透過關機重啟，我們能迅速恢復運行，但卻永遠無法真正找到問題的根源。
此外，在高可用性的世界中，「關閉它」可能會造成巨大的問題。即使是幾分鐘的…停機時間對於那些必須確保關鍵基礎設施持續運作的公司來說，這可能是一個重大問題。正因如此，身為SIOS的技術支援人員，我們很少給出這項臭名昭著的技術建議，但我們確實有自己的一套應對方法。
許多致電SIOS尋求技術支援的人都遇到了以下問題：Windows Data Keeper如果遇到鏡像問題，系統會提示執行「cleanupmirror」指令。在特定情況下，該命令可以快速解決重大問題。它實際上會徹底刪除鏡像配置及其所有殘留數據，以便我們可以重新建立鏡像，擺脫之前存在的所有問題。請注意，此命令不會刪除任何數據，只會刪除系統間的鏡像複製。
該命令無需停機，但意味著在鏡像完成重新同步之前，系統可用性會受到影響。這是我們在技術支援中常用的故障排除步驟之一，但就像「重啟」一樣，它有時會掩蓋更嚴重的潛在問題，有時也可能矯枉過正。
今天，我想談談這樣一個案例：執行 cleanupmirror 指令雖然幫助客戶解決了燃眉之急，但差點讓我們忽略了一個相當嚴重的問題，這個問題可能會影響到很多客戶，不過這個問題其實有一個非常簡單的解決方法。
當支援團隊加入時，客戶已經排查故障相當長一段時間了，他們開始感到恐慌。他們正在進行最後的嘗試。切換在進行遷移測試時，DataKeeper鏡像開始出現問題。此時，他們的關鍵基礎設施癱瘓，他們擔心這會影響業務運作。情況十分危急，但幸運的是，我們的支援工程師表現出色。他們權衡了壓力、時間緊迫和尋找有效解決方案的迫切需求，運行了久經考驗的「cleanupmirror」命令，隨後重建了鏡像並使其恢復正常運作。他們幫助客戶擺脫了困境，一切又恢復正常了。值得慶幸的是，他們還要求客戶發送日誌，以「確保萬無一失」。
此案的日誌有些令人困惑。日誌顯示：某個卷冊已調整大小但客戶聲稱他們在通話中沒有進行任何調整大小的操作。有時客戶會遺漏重要訊息，所以我們一開始以為他們可能在通話中漏掉了這個細節，但這次調整大小的操作實在令人費解。大小的變化非常小，而且所有捲都在第一次切換時同時發生了變化。客戶不可能在第一次切換時，一次性減少不到 1GB 的空間來調整其 TB 級大容量硬碟的大小，這顯然不合邏輯，所以我們進行了更深入的調查。結果發現，目標硬碟的容量略大於來源硬碟，而我們的產品在處理容量不匹配的硬碟時有問題。
一旦我們弄清楚這一點，就意識到解決這個問題只需要繼續鏡像。這是一個常見、快速且簡單的操作，只需幾秒鐘就能徹底修復問題。無需耗時數天重新同步，即可恢復高可用性。此外，一旦我們發現這個問題，在下一個產品版本中實現修復也非常快速方便。
原來，客戶的遷移場景比較特殊，由於目標系統的大小無法完全匹配，他們必須將目標系統的大小略微擴大一些。他們還有幾個系統需要遷移，如果我們只停留在「清理鏡像」階段，他們每次都會遇到這個問題。由於我們找到了根本原因，因此能夠為他們提供一個快速簡便的臨時解決方案，以及一個更快捷的預防措施，讓他們在執行首次切換之前就能採取。我們也發布了解決方案，以便下一個遇到類似問題的客戶能夠在幾分鐘內解決。
那麼，「關機重開機」到底有什麼大問題呢？它掩蓋了問題的根本原因。這是否意味著你永遠不該使用它？它仍然是最好的技術建議之一。很多時候，你根本不需要知道問題的根本原因，而關機重開機就能幫你快速擺脫困境。
對於IT專業人員來說，重要的是，在無需緊急處理問題且有時間先進行調查的情況下，應該這樣做。如果時間緊迫，則應該稍後查看日誌，嘗試找出問題所在。
所以，請隨意開關機。做個幾分鐘就解決問題的魔術師，讓大家好奇你是怎麼做到的。但是……偶爾……也應該花點時間想想，為什麼要開關機……並考慮一下，有沒有更簡單的解決方法。
要了解更多關於 SIOS DataKeeper 和高可用性解決方案如何幫助您避免此類隱藏問題的信息，申請演示今天我們團隊的發言。
作者：Carter Chandler，SIOS Technology公司客戶體驗助理、軟體工程師
經許可轉載SIOS
SIOS 合作夥伴關係在實現高可用性、雲端彈性和整合基礎架構解決方案方面發揮關鍵作用。
在本期播客中Harry 和 Kelly 將帶領聽眾深入了解 SIOS 的合作夥伴生態系統，從與微軟、AWS 和谷歌雲端的雲端聯盟，到與 Exabeam、Milestone 和 Cimcor 等策略性獨立軟體開發人員 (ISV) 的卓有成效的合作。他們探討了 SIOS 如何接納和支持新合作夥伴，分享了多年來構建成功整合方案的經驗教訓，並重點介紹了合作夥伴驅動的創新未來的發展方向——包括人工智慧、混合雲和邊緣運算領域的機會。
播客最後提供了一些實用建議和成功案例，展示了強大的技術合作夥伴關係對業務的影響。
經許可轉載SIOS