本地資料中心的高可用性

本地資料中心的高可用性

實現本地資料中心高可用性的三個要素

對於運行本地資料中心的組織而言，保持強大的高可用性實踐對於保持關鍵系統在線至關重要。

儘管雲端基礎設施持續擴展，但許多組織仍然依賴自己的基礎設施。根據…Uptime Institute約 48% 的北美公司繼續經營自建資料中心。

對於這些組織而言，投資於高可用性對於維持業務連續性、保障收入以及為使用者提供可靠的服務而言，高可用性至關重要。無論您是建置新的基礎架構還是管理現有系統，以下三個面向都是實現高可用性的關鍵：

• 保護實體資料中心
• 設計具有韌性的基礎設施
• 使用合適的操作工具

確保高可用性的實體資料中心安全

在討論高可用性時，物理環境往往被忽略。然而，基礎設施的可靠性始於保護設施本身。

各組織應採取措施防止因停電、環境問題或未經授權的存取而造成的業務中斷。常見的安全措施包括：

• 安全攝影機和存取控制
• 備用電源系統，例如發電機和不間斷電源（UPS）單元
• 像FM-200這樣的滅火系統
• 環境監測溫度和濕度

這些保護措施有助於確保系統保持穩定運作。

確保持續正常運作的彈性基礎設施

高可用性取決於消除單點故障。透過建構冗餘建立基礎設施後，即使系統發生故障，組織仍能繼續運作。

常用策略包括故障轉移叢集、冗餘網路路徑、RAID 儲存和異地​​資料複製。災後復原有些組織也會採用混合雲或多雲架構，以減少對單一供應商的依賴。

如果使用備用資料中心，則不應與主資料中心共用相同電力基礎架構。災難復原和業務連續性計劃還應包括本地備份和異地備份。

高可用性維運工具和集群

維運工具可協助 IT 團隊監控系統、應對突發事件並維持服務連續性。

許多組織首先採用 IT 維運管理平台來發現網路資產並維護配置管理資料庫 (CMDB)。然後，應用效能監控 (APM) 工具可以提供更深入的系統運作狀況洞察，幫助團隊做出更明智的維運決策。

另一個關鍵組成部分是聚類。高可用性集群當發生故障時，自動將應用程式和服務遷移到輔助節點。這些叢集可以使用共享儲存或基於軟體的無SAN架構。

如今，許多組織更傾向於…無SAN叢集因為它們具備與傳統SAN叢集相同的故障轉移能力，同時又提供了更高的靈活性和更低的成本。它們還支援本地部署、雲端部署和混合部署，包括用於災難復原的地理分散式環境。

保持本地資料中心服務的可用性

儘管IT環境不斷發展演變，但有一項優先事項始終不變：最大限度減少停機時間並保持服務的可用性。

透過專注於實體安全、彈性架構和有效的營運工具，企業可以增強其本地資料中心的可靠性，並確保關鍵應用程式保持在線狀態。

準備好增強本地環境的高可用性了嗎？立即申請 SIOS 演示了解我們的叢集解決方案如何幫助您保持關鍵應用程式的線上狀態。

經過：戴夫·伯明翰

經許可轉載SIOS

APM 工具和高可用性叢集如何提高網路彈性

APM 工具和高可用性叢集如何提高網路彈性

網路韌性是指網路在發生中斷時仍能保持連線並繼續運作的能力。對於高度依賴技術的組織而言，維持這種韌性已成為營運的必要條件。西門子近期分析研究發現，即使只是一小時的停機時間，也可能造成企業數百萬美元的損失。停機會中斷生產、違反服務等級協議 (SLA)、導致交易中斷，並產生與加班費、外部顧問費、事故調查費和監管處罰相關的巨額支出。

在某些行業，例如金融服務網路韌性薄弱的後果可能遠遠超出單一組織的範圍。全球經濟依賴營運良好的金融機構。穩定高效率的IT系統這些系統每年能夠處理數兆美元的交易。任何對這些系統不可靠的認知都可能影響整個市場。因此，巴塞爾委員會和聯準會等監管機構都制定了嚴格的營運彈性標準。同樣，在以下行業中運作的組織也需要遵守這些標準：衛生保健電信和關鍵基礎設施必須遵循相關準則，以確保網路可靠性和連續性達到較高水準。

具有韌性的組織會投資智慧基礎設施

無論部署在本地端、雲端或混合架構中，IT 環境的規模和複雜性都在不斷增長。因此，IT 團隊需要能夠提供更佳可視性並支援更明智決策的工具。現代 IT 維運越來越依賴數據驅動的洞察和自動化來支援 IT 專業人員的工作。

因此，具有前瞻性的組織正在投資於能夠增強韌性和提高營運感知能力的技術。其中兩種特別適合協同工作的技術是應用效能監控 (APM) 平台和高可用性（HA）叢集解決方案。

應用效能管理 (APM) 工具透過收集和分析整個 IT 環境中的效能資料發揮關鍵作用。這些數據可幫助組織更了解其係統的運作狀況和行為，從而使管理員能夠為警報和自動回應設定更精確的閾值。高可用性叢集透過確保服務在發生中斷時可以故障轉移到備用系統來增強此功能。這些叢集可以依賴傳統 SAN 環境中的共享存儲，也可以使用基於軟體的雲端平台。無SAN叢集在節點間複製資料。

結合應用效能管理 (APM) 和高可用性 (HA) 以增強網路彈性

什麼時候APM 工具和高可用性叢集一起部署。企業透過這些平台獲得更強大的網路彈性提升能力。來自應用效能管理 (APM) 平台的監控洞察可以為自動化和運維決策提供信息，而高可用性 (HA) 叢集則確保即使發生故障，工作負載也能持續運作。

這種組合支援自動故障轉移、預測分析、自癒流程和更快的事件回應等功能。這些功能有助於企業保持更高的正常運作時間並提供穩定的應用程式效能。

在多雲環境這種方法的價值就更加凸顯。如果雲端服務供應商發生故障，服務可以故障轉移到備用雲端環境。企業也可以將工作負載分佈在多個雲端平台上，從而消除單點故障，提高整體系統彈性。

隨著企業不斷朝向更自主的IT運維方向發展，應用效能管理（APM）工具收集的資料能夠提供系統效能和運作狀況的詳細視圖。這些資訊使IT團隊能夠制定精確的策略和運作閾值，從而在出現問題時做出自信且明智的決策。

利用監控數據支援故障轉移決策

設想這樣一種情況：IT 管理員必須決定是否啟動故障轉移以防止潛在的系統中斷。手動啟動故障轉移的成本可能超過 5 萬美元，因為這會造成營運中斷和恢復流程。然而，等待時間過長可能會導致代價更高的故障。

缺乏清晰的數據，決策者可能會猶豫不決。他們可能擔心僅憑不完整的資訊或直覺就啟動代價高昂的干預措施。可靠的績效數據能夠提供客觀證據，支持明智的行動，有助於消除這種不確定性。

借助精準的監控數據，團隊可以判斷系統狀況是否真的需要故障轉移。如果需要幹預，他們可以憑藉數據支撐的充分理由自信地採取行動。

正是在這裡，APM 工具與高可用性叢集的結合才顯得格外重要。當效能下降、意外事件或大規模中斷威脅到營運時，它們能夠共同幫助維持服務的連續性。APM 監測它能夠提供基礎設施組件運作狀況的可見性，使管理員能夠及早發現問題並在停機前做出回應。如果需要進行故障轉移，則會根據組織的風險承受能力，並依照明確定義的參數做出決策。

具備APM功能的HA叢集的優勢

當高可用性叢集與組織的 APM 平台整合時，關鍵業務應用程式和服務可以自動故障轉移，最大限度地減少中斷。自動故障轉移降低了手動恢復過程中可能出現的延遲或錯誤風險，並允許在解決根本問題的同時繼續運行。

如今，許多組織正在採用無SAN叢集方案。這些方案提供與傳統基於SAN的叢集相同的故障轉移能力，但無需共用儲存基礎架構的成本和複雜性。無SAN叢集可在節點間複製數據，並在本地端、雲端或混合式環境中有效運作。

它們還支援跨多個資料中心或區域的地理分散式部署，這對於有效部署至關重要。災難復原計劃。

無論企業身處監管嚴格的行業，還是僅僅希望提升可靠性和運作穩定性，將應用效能管理 (APM) 監控與高可用性叢集結合，都是一種切實有效的策略。這些技術協同工作，能夠以簡單且有效率的方式提升正常運作時間、增強系統韌性，並滿足日益增長的可靠 IT 服務需求。

利用高可用性叢集增強網路彈性

即使發生故障，也能確保應用程式持續運作。 SIOS 高可用性叢集可協助企業維持正常運作時間、自動進行故障轉移，並保護關鍵系統免受停機影響。

申請演示了解 SIOS 如何協助增強您的網路彈性。

經許可轉載SIOS

為雲端 SQL Server 高可用性選擇適當的存儲

為雲端 SQL Server 高可用性選擇適當的存儲

適用於 SQL Server 高可用性的 Azure 和 AWS 儲存選項

BetaNews 的文章“如何為雲端 SQL Server 高可用性選擇適當的儲存方案SIOS 高級技術推廣專家 Dave Bermingham 探討如何為部署選擇合適的雲端儲存。具備高可用性的 SQL Server（旨在跨主要雲端平台提供至少 99.99% 的正常運作時間）Microsoft Azure和亞馬遜網路服務。

Dave 解釋說，傳統的共用磁碟或低層磁碟選項通常速度太慢，無法滿足高效能 SQL Server 環境的需求。他重點介紹了更合適的儲存方案，例如 Azure Premium SSD v2 或 Ultra Disk 以及 AWS GP2/GP3 卷，並權衡了效能、成本和配置方面的差異。文章也探討了儲存方案如何與 SQL Server 可用性群組或第三方無 SAN 叢集等高可用性方法相結合，以及這些決策（包括虛擬機器容量和授權的考量）如何影響高可用性雲端部署的整體成本和效能。

經許可轉載SIOS

在不可預測的世界中製定災難復原計劃

在不可預測的世界中製定災難復原計劃

電腦系統和電腦化基礎設施已成為承重部分。現代商業環境因此，停機不僅令人煩惱，而且代價高昂。雖然世界變幻莫測，但制定有效的災難復原計畫並做好緊急應變計畫，可以確保意外問題不會導致更嚴重的後果。這正是高可用性和災難復原解決方案的作用所在。

了解高可用性和災難復原

高可用性和災難復原是一個多面向、相互支援的過程。雖然這些概念相輔相成、互相促進，但了解它們之間的界線至關重要。

什麼是高可用性？

高可用性指系統、應用程式或其他基礎設施元件能夠迅速恢復運作的能力。這包括基礎設施元件在重新啟動、遷移或以其他方式恢復時，盡可能減少運作狀態的損失或退化。

也就是說，基礎設施能夠持續發揮其指定作用，並獲取最新資訊。此外，高可用性基礎設施可以支援多個基礎設施元件共同承擔主要角色，從而確保可用性。

什麼是災難復原？

災後復原指的是系統、應用程式或基礎設施組件承受災難性故障的能力。通常，災難復原關注的是某些基礎設施元件遭受的災難性且不可挽回的損失。

災難復原解決方案的一個簡單例子是，將資料備份並異地儲存。這樣做是為了保護資料免受可能導致原始儲存媒體無法恢復的全面災難的影響，並且符合災難復原解決方案的標準，儘管其實現方式仍有改進空間。

高可用性和災難復原如何協同工作

高可用性和災難復原相結合，兩者可以相互促進，共同實現各自的目標。高可用性解決方案能夠確保系統及時恢復運行，而用於恢復系統運行的基礎設施通常是災難復原解決方案的一部分。

如果規劃得當，將工作負載遷移到健康的基礎設施的能力可以使災難復原解決方案快速有效地運作。最大限度減少停機時間這兩個要素相輔相成，共同營造出兼顧韌性和正常運作時間的環境。

停機的真正成本

生產環境中的任何電腦系統、基礎設施組件或其他要素都可能故障。一旦發生故障，損失的收入、生產力下降以及修復故障根源的成本等機會成本很容易衡量。根據國際技術情報顧問公司 (International Technology Intelligence Consulting) 2024 年的一項研究顯示，光是這些成本就相當於每小時停機損失 30 萬美元或更多。在估算停機成本時，91% 的中大型企業都提到了這個數字。

然而，停機帶來的「軟性成本」往往被忽略。停機會削弱客戶信心，損害企業聲譽，並給負責環境的人員帶來額外壓力。雖然停機確實會對企業造成非常直接且實實在在的損失，但此類事件的連鎖反應可能會在未來幾個月甚至幾年內持續影響企業營運。

將韌性作為設計要求

基礎設施只有在設計之初就以打造高可用性環境並製定強大的災難復原計畫為目標時，才能達到高可用性和最高災難復原能力的巔峰。

將高可用性/災難復原作為設計要求的第一步是設定切合實際的預期。通常，這些預期可以透過以下方式概括：「恢復點目標」（RPO）與「復原時間目標」（RTO）。

簡要描述這些指標：

• 復原點目標 (RPO) 描述了組織在從備份還原時可能會遺失的資料量
• 恢復時間目標描述了在不可用環境能夠恢復運作之前所需的理想時間。

定義這些指標自然而然地避開了一個常見問題。由於系統是根據其高可用性/災難復原 (HA/DR) 需求進行優先排序的，因此對停機時間具有更高復原能力的系統可以使用更簡單的實施方案。反過來，那些需要極低恢復時間目標 (RTO) 和恢復點目標 (RPO) 指標的系統，則可以投入更多精力來確保這些系統上部署的解決方案能夠滿足更高的運作標準。

利用自動化降低災難復原計畫中的風險

在探討高可用性和災難復原策略時，我們通常會專注於業務關鍵型系統。這些系統往往需要快速可靠地解決問題，以防止問題失控。儘管負責這些系統的人員都是環境方面的專家，但在解決問題的過程中，人為錯誤的可能性仍然是一個可以避免的風險因素。

一個強大的高可用性和災難復原解決方案可整合自動故障偵測和自動恢復操作。這樣不僅可以更快地回應問題（問題能夠被自動偵測並執行相應的復原計畫），而且自動回應還能有條不紊、有效率地採取行動，避免人為錯誤。

建構超越技術層面的冗餘

儘管在設計時考慮高可用性/災難復原 (HA/DR) 並確保解決方案能夠提供自動化回應至關重要，但在關鍵系統的設計、創建和維護過程中，仍然存在人為因素。在這些解決方案中充分發揮人員作用的關鍵在於，為團隊創造一個低壓力的工作環境，使其能夠採用謹慎且有條不紊的問題解決方法。任何涉及人員參與的工作，其結果都應經過驗證流程，以確保解決方案能夠如預期運作。

除了工作環境之外，確保員工能夠獲得有效工作所需的知識也至關重要。如果團隊中只有一人能夠勝任某項維護工作，那麼一旦該人員無法工作，營運就可能出現中斷。

營運連續性規劃不僅限於系統內部的考量。確保團隊協作以減少知識孤島，並在投入生產前對成果進行測試，可以有效避免問題，從而保護系統。

彈性系統的災難復原規劃最佳實踐

雖然實施高可用性和災難復原解決方案沒有萬能的模式，但有一些指導原則和最佳實踐可以幫助建立適合貴組織的災難復原計畫策略。上述幾點是很好的基礎。此外，還可以透過一些普遍適用的目標來改進，例如尋找並消除單點故障、記錄流程並明確角色和職責、維護與生產環境完全相同的品質保證 (QA) 副本以驗證流程、將系統分佈在地理位置不同的區域，以及定期審查和更新文件。

為應對下一次突發事件做好災難復原計畫的準備

中斷是不可避免的，沒有一個組織願意經歷中斷。停電避免了一場本可預測和避免的失敗。採取有計劃的安排和分階段實施的解決方案，可以有效應對此問題。提供具有高可用性和災難復原能力的環境確保無論問題是否可預測，環境都能做好準備應對問題並繼續滿載運轉，從而使企業能夠順利運作。

申請演示了解 SIOS 高可用性和災難復原解決方案如何協助保護關鍵系統並保持您的業務運作。

作者：Philip Merry，SIOS Technology Corp.

經許可轉載SIOS

主動-主動 vs. 主動-被動

主動-主動 vs. 主動-被動

高可用性架構指南

主動-主動和主動-被動是兩種不同的架構配置。高可用性叢集中的伺服器節點雙活架構是指兩台伺服器都處於開機狀態並處理資料。雙被動架構則截然不同，它只有一台伺服器處於活動狀態處理數據，而備用伺服器則處於非活動狀態，以便在活動伺服器發生故障時接管控制權。

高可用性系統和核心組件

高可用性其核心在於消除單點故障，這意味著，如果某個節點出現問題，另一個節點可以接手該節點的工作。

高可用性系統的關鍵組成部分：

• 一個有記憶體和電源的主處理核心節點
• 一個帶有記憶體和電源的備用處理核心節點
• 兩個核心組件之間的通訊鏈路
• 本機儲存或核心元件之間共用的存儲

主動-主動架構

在雙活架構中，兩台相同的伺服器同時運行，均處於活動狀態，且都能處理事務。事務可以由任一伺服器處理。

主動-主動架構的優勢

兩台伺服器始終處於運作狀態，而其他配置中則存在一些在正常運作期間未使用的節點。潛在優勢如下：

• 可擴展性，尤其是利用雲端平台，使得高峰使用問題成為過去。
• 可以平衡伺服器的工作負載，避免單一伺服器過載。
• 整體而言，在硬體數量相同的情況下，吞吐量有所提高。

可擴展性

在雲端平台上，雙活架構具有很強的可擴展性。例如，可以使用 AWS AutoScale 按需新增更多 EC2 實例，使叢集能夠擴展以應對資料高峰。

負載平衡

可以在節點上游配置負載平衡器，將交易傳送到負載較輕的伺服器，從而確保叢集內的流量平衡，以確保工作項目的高吞吐量。

主動-主動用例

資料量大、事務處理量大以及多節點託管應用程式最適合採用主動/主動配置。以下是一些範例：

• 多節點、全球分散式資料庫系統
• 用於即時應用的數學數據處理
• 大數據/資料倉儲
• 高流量網站託管
• 電信網路和簡訊

主動-被動架構

在主備架構中，叢集環境採用兩台伺服器。一台伺服器被指定為活動模式，負責執行處理任務。另一台伺服器則處於備用模式，不執行任何資料處理，但隨時準備在需要時接管。故障轉移來自活動節點或用戶簽發的切換來自活動節點。

主動-被動架構的優勢

由於同一時間只有一台伺服器處於活動狀態，因此另一台伺服器可以享受停機時間（開機但處於待機模式，主要負責滿足活動伺服器的資料複製需求，隨時準備在需要時接管控制權，但實際上不處理任何實際工作）。潛在的優點如下：

• 叢集的功耗降低
• 延長硬體壽命－組件在較低的負載下運行，且不會持續處於極限狀態時，使用壽命更長。
• 冷氣需求減少，冷氣量降低，電費也隨之降低。
• 簡化的資源視圖－資源將在活動節點上處於活動狀態
• 不需要負載平衡器

主動-主動模式與主動-被動模式的成本效益比較

由於叢集的處理能力只有一半被用於實際工作，因此在主動-被動配置中，硬體的總體成本相對於可以執行的處理量而言更高，因此其成本效益略低於主動-主動配置。

簡化管理

資源將在活動節點上處於活動狀態—無需猜測哪個節點目前正在積極託管特定資源。

主動-被動使用場景

必須保持低資料遺失率的重要係統，例如：

• 金融處理系統
• 後端零售系統
• 災難復原解決方案
• 關係型資料庫
• 為中小企業提供成本更低的高可用性
• 需要簡單託管解決方案的遺留系統

災難復原解決方案中的雙活模式與雙活模式

主動-主動模式與主動-被動模式的作用

雙活災難復原 (DR) 系統部署在地理位置分散的節點上，兩個節點都處理生產流量。如果其中一個節點發生故障，工作負載將轉移到仍然運作的系統。停機時間雖然一個系統宕機時工作負載處理可能會下降到比正常水平低的程度，但使用者中斷幾乎無法察覺。

主動-被動災難復原（DR）系統實現了一種災難復原解決方案備用系統會在主系統故障時接手。當活動節點發生故障時，系統切換過程中會出現短暫的停機時間，但備用節點接管原活動系統後，工作負載水準應該與原系統沒有明顯差異。

與冗餘系統集成

使用冗餘系統實施災難復原策略，旨在提供一種將活動切換到同步備份系統的能力，該備份系統上的資料與原有活動系統上的資料保持相同狀態，並且新的活動系統能夠在短時間內上線。在選擇實施冗餘系統時，還應考慮硬體冗餘、通訊路徑冗餘和軟體冗餘（透過高可用性實現）。

為您的企業選擇主動-主動架構還是主動-被動架構

需要考慮的因素

為您的企業選擇合適的架構取決於以下因素：

• 成本，包括如果希望使用雲端託管節點，則需支付的持續雲端費用。
• 是關鍵任務系統，還是高交易資料系統？
• 使用者對偶爾少量停機時間的容忍度，以及性能要求——例如，因正常運作時間不達標而受到的 FCC 處罰？
• 節點和儲存的地理分散化可降低延遲，並能根據需求增加節點以滿足峰值需求。

性能和正常運行時間要求

在確定架構之前，應先明確業務的效能和正常運作時間要求。

對於正常運作時間達到三個九（99.9%），每年僅允許 8 小時停機時間的服務提供者而言，如果故障轉移迅速，並且系統得到良好的監控和維護，那麼使用主動-被動模式當然可以實現這一點。四個九（99.99%）正常運作時間主要屬於主動-主動系統的領域。

也應考慮事務處理層級。如果預計會有大量的連續資料事務處理，則雙活配置可能更合適。

主動-主動架構 vs. 主動-被動架構：哪種架構較適合您的企業？

雙活和雙活系統各有優勢。對企業而言，關鍵系統（絕對不能宕機）可能更適合採用雙活架構。而對於其他可以容忍偶爾停機的系統，雙活架構或許是更適合的選擇。混合使用多種技術或許更能滿足所有系統的需求。企業可以根據自身需求選擇合適的方案：規模較大、業務分散的企業可以受益於雲端託管雙活系統的靈活性，而規模較小的企業則可以享受雙活架構的簡潔性和成本優勢。總有一款解決方案適合您。

如果您正在評估雙活架構和雙活架構在高可用性策略中的應用，申請演示了解 SIOS 如何協助您為您的企業設計合適的架構。

作者：Paul Scrutton，SIOS 軟體系統工程師

經許可轉載SIOS