DeviceOn 不怕斷線！研華高可用性架構實測：Helmsman + S2D 讓您的 IoT 平台穩定運行！

嗨，各位讀者！想像一下，您的 IoT 平台是您業務運作的心臟，它負責管理遍布各地的設備、收集關鍵數據、執行重要指令。如果這個心臟突然停止跳動，哪怕只是幾分鐘，都可能造成難以估計的損失。在現今高度依賴數據與自動化的時代，確保 IoT 平台的「高可用性」（High Availability, HA）已經不是選項，而是必須！

研華深知平台穩定性的重要，因此我們的工程團隊不斷投入研發，尋找能讓 DeviceOn 平台更加強韌、不怕單點故障的解決方案。今天，我們就要來分享一項令人振奮的實驗成果：如何透過研華自主開發的 Helmsman 工具，搭配微軟的 Storage Spaces Direct (S2D) 技術，為多個 DeviceOn 實例打造一個簡單卻高效的故障轉移架構！

為什麼需要高可用性？DeviceOn 在其中扮演的角色

#

DeviceOn 是研華為物聯網應用打造的設備管理與監控平台。從遠端設備連線、數據採集、軟體更新到安全管理，DeviceOn 扮演著核心樞紐的角色。試想，如果負責監控工廠生產線的 DeviceOn 伺服器突然當機，生產數據無法即時回傳、設備狀態無法掌握，甚至遠端控制失靈，這將直接影響生產效率與營運安全。

因此，確保 DeviceOn 平台即使在硬體故障或軟體異常的情況下，也能快速恢復服務，甚至無縫切換到備用系統，是我們持續努力的目標。這就是「高可用性」的價值所在——讓您的關鍵 IoT 應用永不斷線！

我們的秘密武器：Helmsman 與 S2D

#

為了實現 DeviceOn 的高可用性，我們引入了兩個關鍵技術：

1. Helmsman (舵手)： 這是研華工程師為了解決 DeviceOn HA 問題而特別開發的「協調者」工具。您可以想像 Helmsman 就像一位經驗豐富的船長，負責協調多艘 DeviceOn 船隻（實例），確保在主船發生狀況時，能迅速指派備用船隻接手，維持航行（服務）不中斷。Helmsman 目前專為 Windows 環境設計，與 DeviceOn 緊密整合。

2. Storage Spaces Direct (S2D)： 這是微軟 Azure Stack HCI 和 Windows Server 的一項強大功能。簡單來說，S2D 能將多台伺服器內部的儲存空間虛擬化並整合成一個共享的、具備容錯能力的「軟體定義儲存池」。所有連接到這個儲存池的伺服器都能存取相同的數據，而且數據會自動在不同伺服器之間複製，即使其中一台伺服器的硬碟故障，數據依然安全無虞。S2D 為 DeviceOn 的 HA 架構提供了可靠的共享數據基礎。

透過 Helmsman 的協調能力和 S2D 的共享儲存優勢，我們可以讓多個 DeviceOn 實例共享同一份數據，並確保在任何時間點，只有一個 DeviceOn 實例處於「啟用」（Active）狀態提供服務，其他實例則處於「待命」（Standby）狀態，隨時準備接手。

實驗過程大公開：一步步打造 DeviceOn HA 環境

#

我們的工程師捲起袖子，開始了這項重要的實驗。以下是我們建構這套 DeviceOn HA 架構的關鍵步驟與發現：

環境準備：

首先，我們需要一個符合 S2D 要求的 Windows Server 環境。實驗中，我們使用了 Windows Server 2019 Datacenter Edition。幾個重要的先決條件包括：

1. Active Directory 網域控制器： S2D 要求所有叢集節點都必須加入同一個 Active Directory 網域。
2. 獨立的管理系統 (建議)： 為了方便遠端部署與管理，我們準備了一台獨立的 Windows Server 或 Windows 10 電腦，並安裝了遠端伺服器管理工具 (RSAT) 和相關 PowerShell 模組。
3. 符合 S2D 硬體需求的伺服器節點： 至少需要兩台伺服器作為 DeviceOn 節點。微軟建議使用五台或更多以達到最佳可靠性。為了簡化硬體準備，我們的實驗環境是建立在 Azure Cloud 上，這也是一個快速驗證 S2D 環境的可行方式。如果您選擇本地部署，請務必確認硬體符合 S2D 需求。

實驗環境拓撲與假設：

為了讓實驗過程更具體，我們設定了一個簡單的環境拓撲與相關假設：

網域名稱設定為 s2d.test，叢集名稱為 S2D-Cluster。

建立 Storage Spaces Direct (S2D) 共享儲存

#

這是整個 HA 架構的基礎。S2D 負責將多個節點的內部儲存整合成一個可靠的共享儲存空間，DeviceOn 的數據庫和重要檔案將會存放在這裡。以下是建立 S2D 的詳細步驟（這些步驟主要在獨立的管理系統 s2d-mgr 上透過 PowerShell 遠端執行）：

步驟 1：安裝作業系統 在每個將加入叢集的節點 (s2d-1 和 s2d-2) 上安裝 Windows Server Datacenter Edition。強烈建議使用 Windows Server 2019 Datacenter Edition 並執行 Windows Update 至最新。如果在 Azure Cloud 上部署，請確保每個節點至少附加兩個獨立的數據磁碟。

步驟 2：檢查連線能力 從管理系統 (s2d-mgr) 透過 PowerShell 檢查是否能遠端連線到每個節點。

# 連線到 s2d-1
Enter-PSSession -ComputerName 10.1.0.6 -Credential localhost\s2d-1

# 連線到 s2d-2
Enter-PSSession -ComputerName 10.1.0.7 -Credential localhost\s2d-2

如果遇到 WinRM 連線問題，可能需要將節點 IP 加入管理系統的 TrustedHosts 列表：

Set-Item WSMAN:\Localhost\Client\TrustedHosts -Value 10.1.0.* -Force

步驟 3：加入網域並新增網域帳戶 將所有節點加入 Active Directory 網域 (s2d.test)，並確保用於管理的網域帳戶 (s2d\s2d-adc) 擁有每個節點的本地 Administrators 權限。

# 從管理系統執行，將節點加入網域
Add-Computer -DomainName "s2d.test" -Credential "s2d\s2d-adc" -Restart -Force

# 將網域管理員帳戶加入節點的本地 Administrators 群組
Net localgroup Administrators "s2d\s2d-adc" /add

步驟 4：安裝角色與功能 在所有節點上安裝必要的 Windows Server 角色與功能，包括 Failover Clustering、Hyper-V (如果非 Azure 環境)、File Server 等。

# 從管理系統執行
$ServerList = "s2d-1", "s2d-2"
$FeatureList = "Failover-Clustering", "Data-Center-Bridging", "RSAT-Clustering-PowerShell", "Hyper-V-PowerShell", "FS-FileServer" # 非 Azure 環境需加入 "Hyper-V"

Invoke-Command ($ServerList) {
    Install-WindowsFeature -Name $Using:Featurelist
}
# 安裝完成後需重啟節點

步驟 5：設定網路 由於實驗在 Azure Cloud 進行，網路部分由 Azure 管理，此步驟可跳過。本地部署請參考微軟文件進行網路配置。

步驟 6：設定 Storage Spaces Direct 這些步驟應在管理系統 (s2d-mgr) 的本地 PowerShell 中以管理員權限執行。

• 步驟 6-1：清理磁碟 確保所有非系統磁碟都是空的，沒有舊的分區或數據。

  # 從管理系統執行
  $ServerList = "s2d-1", "s2d-2"
  
  Invoke-Command ($ServerList) {
      Update-StorageProviderCache
      Get-StoragePool | ? IsPrimordial -eq $false | Set-StoragePool -IsReadOnly:$false -ErrorAction SilentlyContinue
      Get-StoragePool | ? IsPrimordial -eq $false | Get-VirtualDisk | Remove-VirtualDisk -Confirm:$false -ErrorAction SilentlyContinue
      Get-StoragePool | ? IsPrimordial -eq $false | Remove-StoragePool -Confirm:$false -ErrorAction SilentlyContinue
      Get-PhysicalDisk | Reset-PhysicalDisk -ErrorAction SilentlyContinue
      Get-Disk | ? Number -ne $null | ? IsBoot -ne $true | ? IsSystem -ne $true | ? PartitionStyle -ne RAW | % {
          $_ | Set-Disk -isoffline:$false
          $_ | Set-Disk -isreadonly:$false
          $_ | Clear-Disk -RemoveData -RemoveOEM -Confirm:$false
          $_ | Set-Disk -isreadonly:$true
          $_ | Set-Disk -isoffline:$true
      }
      Get-Disk | Where Number -Ne $Null | Where IsBoot -Ne $True | Where IsSystem -Ne $True | Where PartitionStyle -Eq RAW | Group -NoElement -Property FriendlyName
  } | Sort -Property PsComputerName, Count
  

• 步驟 6-2：驗證叢集 執行叢集驗證工具，確保節點配置適合建立 S2D 叢集。

  # 從管理系統執行
  Test-Cluster -Node "s2d-1", "s2d-2" -Include "Storage Spaces Direct", "Inventory", "Network", "System Configuration"
  

  只要驗證報告顯示 “The configuration appears to be suitable for clustering.” 即可，警告訊息通常可以忽略。

• 步驟 6-3：建立叢集 建立故障轉移叢集。

  # 從管理系統執行
  New-Cluster -Name S2d-Cluster -Node s2d-1,s2d-2 -NoStorage
  

• 步驟 6-4：設定叢集見證 (Witness) 為叢集設定見證，以避免「腦裂」(Split-Brain) 問題，特別是雙節點叢集，見證是必須的。我們使用檔案共享作為見證。

  1. 在 AD 網域控制器 (s2d-adc) 上建立一個共享資料夾 (例如 C:\Witness)。

     

     

     

     

  2. 從管理系統連線到任一節點，設定檔案共享見證。

     # 從管理系統執行，連線到任一節點
     Enter-PSSession -ComputerName s2d-1 # 或 s2d-2
     # 在節點的 PowerShell 中執行
     Set-ClusterQuorum -FileShareWitness \\s2d-adc\Witness -Credential (Get-Credential)
     # 結束連線
     Exit-PSSession
     

• 步驟 6-5：啟用 Storage Spaces Direct 啟用 S2D 功能，系統會自動建立儲存池、設定快取、建立儲存層。

  # 從管理系統執行
  Enable-ClusterStorageSpacesDirect -CimSession S2D-Cluster
  

• 步驟 6-6：建立磁碟區 (Volume) 在 S2D 儲存池上建立一個共享磁碟區，用於存放 DeviceOn 的數據。

  # 從管理系統執行，連線到任一節點
  Enter-PSSession -ComputerName s2d-1 # 或 s2d-2
  # 在節點的 PowerShell 中執行
  New-Volume -FriendlyName "DeviceOn-Data" -FileSystem CSVFS_ReFS -StoragePoolFriendlyName S2D* -Size 10GB # 磁碟區大小可依需求調整
  # 結束連線
  Exit-PSSession
  

  完成後，在每個節點的檔案總管中，您應該會看到 C:\ClusterStorage\DeviceOn-Data 這個路徑。在這個共享資料夾中建立的檔案，在所有節點上都能看到，這就是 S2D 共享儲存的魔力！

  

部署 DeviceOn

#

在每個節點 (s2d-1 和 s2d-2) 上安裝 DeviceOn 伺服器。請注意，所有節點上的 DeviceOn 版本必須完全一致！

步驟 1：取得安裝程式 從研華取得適用於 Windows 的 DeviceOn 伺服器安裝程式。

步驟 2：執行安裝程式 在每個節點上執行安裝程式。安裝過程中，對於主機名稱/IP 以外的設定，強烈建議在所有節點上使用相同的值。

步驟 3：取得獨立授權請求檔 這一步非常重要，必須在部署 Helmsman 之前完成！ 在每個節點上的 DeviceOn 安裝完成後，登入 DeviceOn Portal (使用 root 帳號)，進入產品啟用頁面，匯出「獨立授權請求檔」(License Request File)。

步驟 4：取得 HA 授權檔 收集所有節點的獨立授權請求檔，聯繫研華以換取一個適用於 HA 環境的授權檔。

部署 Helmsman

#

萬事俱備，只欠 Helmsman 這位「舵手」了！Helmsman 的部署也需要在每個節點上本地執行。

步驟 1：取得安裝包 從研華取得 Helmsman 安裝包 (一個 zip 檔案)，解壓縮到每個節點的本地磁碟上。找到 Helmsman.Deploy.exe 執行檔。

步驟 2：執行安裝程式 執行 Helmsman.Deploy.exe。這是一個圖形化介面程式，操作直觀。

• For This Session： 包含兩個選項。
  • ☐ This host is the first one to execute this deployment program.：只有在第一個部署 Helmsman 的節點上需要勾選！ 勾選此項會將本地 DeviceOn 的數據複製到 S2D 共享儲存中。請注意，這會覆蓋 S2D 中可能已存在的 DeviceOn 數據。
  • ☑ Starts up Helmsman services once the deployment is completed.：部署完成後是否自動啟動 Helmsman 服務，通常保持勾選。
• Actions： 顯示部署過程中將執行的任務列表。

根據您是第一個部署的節點還是後續節點，選擇正確的選項後，點擊「Go」按鈕開始部署。

步驟 3：驗證部署結果 部署完成後，檢查每個節點的狀態。以我們的實驗為例，先部署 s2d-1 (勾選 “This host is the first one…")，再部署 s2d-2 (不勾選 “This host is the first one…")。

• s2d-1 (第一個部署節點):

  

  所有任務都應成功完成。檢查 DeviceOn Server Control，所有服務應為綠燈，表示 s2d-1 是目前的 Active 節點。

• s2d-2 (後續部署節點):

  

  「Clone DeviceOn Data Files」任務應為灰色（未執行）。檢查 DeviceOn Server Control，所有服務應為紅燈，表示 s2d-2 是目前的 Standby 節點。

• 檢查共享儲存： 在任一節點上打開檔案總管，進入 C:\ClusterStorage\DeviceOn-Data 路徑。您會看到 DeviceOn 的數據庫檔案以及 Helmsman 相關檔案已經複製到這裡。這證明數據已成功遷移到共享儲存。

  

步驟 4：匯入 HA 授權檔 使用瀏覽器連線到目前 Active 的 DeviceOn 節點 (例如 s2d-1) 的 Portal，登入 root 帳號。進入產品啟用頁面，匯入您從研華取得的 HA 授權檔。

至此，DeviceOn HA 環境的建置就完成了！

故障轉移實測：驗證 HA 機制是否有效

#

建好環境只是第一步，關鍵在於它是否真的能在故障發生時順利轉移。我們進行了一個簡單的故障轉移測試：

步驟 1：在 Active 節點上新增數據 連線到目前 Active 的 DeviceOn Portal (s2d-1)，登入 root 帳號。在「帳號」頁面新增一個測試用的系統管理員帳號 (例如 Demo.Test)。

步驟 2：模擬 Active 節點故障 登入 Active 節點 (s2d-1)，打開工作管理員 (Task Manager)。找到 DeviceOn Portal 的主要程序 tomcat9.exe，並強制結束它。

觀察故障轉移： 立即觀察 s2d-1 的 DeviceOn Server Control，服務狀態會逐漸從綠燈變成紅燈。

步驟 3：在新 Active 節點上驗證數據 現在，嘗試連線到新的 Active 節點 (s2d-2) 的 DeviceOn Portal。登入 root 帳號，再次進入「帳號」頁面。您會發現，剛才在 s2d-1 上新增的 Demo.Test 帳號赫然出現在列表中！

這證明了即使 Active 節點故障，備用節點也能迅速接手，並且因為數據存放在 S2D 共享儲存上，所有數據都能在新 Active 節點上無縫存取，確保業務連續性。

當原來的 Active 節點 (s2d-1) 恢復正常後，Helmsman 會將其狀態標記為「故障」(malfunction)，直到問題修復並手動移除安裝目錄下的 __MALFUNCTION__ 檔案後，它才會回到「待命」(idle) 狀態，準備在未來再次被提升為 Active。

結論與未來展望

#

這項實驗成功驗證了透過研華 Helmsman 工具與微軟 Storage Spaces Direct 技術，可以為 DeviceOn 平台建構一個可靠的高可用性架構。這意味著我們的客戶在部署 DeviceOn 於關鍵應用場景時，能夠大幅提升平台的穩定性與可靠性，降低因伺服器故障導致的營運中斷風險。

這項成果不僅展現了研華在提升 DeviceOn 平台穩定性上的持續投入與創新能力，也證明了我們能有效整合業界領先的技術，為客戶提供更強大、更可靠的 IoT 解決方案。

未來，研華將持續投入研發，進一步優化 Helmsman 的功能，探索更多提升 DeviceOn 高可用性與災難復原能力的技術，以滿足日益複雜和嚴苛的工業物聯網應用需求。研華致力於成為您最值得信賴的 IoT 夥伴，用創新技術為您的業務保駕護航！

如果您對 DeviceOn 的高可用性解決方案感興趣，或有任何相關需求，歡迎隨時與研華聯繫！