Hystax 雲遷移:駕馭雲端

災難恢復解決方案市場的年輕參與者之一是 2016 年成立的俄羅斯初創公司 Hystax。 由於災難恢復這個話題非常流行,而且市場競爭也非常激烈,因此這家初創公司決定專注於不同雲基礎設施之間的遷移。 允許您組織簡單快速的雲遷移的產品對於 Onlanta 的客戶(用戶)來說非常有用 oncloud.ru。 這就是我了解 Hystax 並開始測試其功能的方式。 我將在這篇文章中講述它的結果。

Hystax 雲遷移:駕馭雲端
Hystax 的主要特點是其廣泛的功能,支持各種虛擬化平台、客戶操作系統和雲服務,這使得您可以隨時隨地移動工作負載。

這使您不僅可以創建災難恢復解決方案來提高服務的容錯能力,還可以在不同站點和超大規模服務器之間快速、靈活地遷移資源,以節省成本並為當前的特定服務選擇最佳解決方案。 除了標題圖中列出的平台外,該公司還積極與俄羅斯雲提供商合作:Yandex.Cloud、CROC Cloud Services、Mail.ru 等。 還值得注意的是,2020年該公司在斯科爾科沃開設了研發中心。 

市場上大量玩家選擇一種解決方案,表明了良好的定價政策和產品的高適用性,我們決定在實踐中進行檢驗。

因此,我們的測試任務將包括從我的 VMware 測試站點和物理機遷移到也運行 VMware 的提供商站點。 是的,有很多解決方案可以實現這樣的遷移,但我們將 Hystax 視為通用工具,在所有可能的組合中測試遷移簡直是一項不切實際的任務。 是的,而且 Oncloud.ru 雲是專門基於 VMware 構建的,因此這個平台作為目標,我們更感興趣。 接下來我會描述基本的工作原理,整體上不依賴於平台,VMware可以從任何方面替換為其他廠商的平台。 

第一步是部署 Hystax Acura,它是系統的控制面板。

Hystax 雲遷移:駕馭雲端
它是從模板擴展而來的。 由於某種原因,在我們的案例中,它並不完全正確,而是使用一半的資源部署了 8Gb,而不是推薦的 16CPU。 因此,您一定不要忘記更改它們,否則構建一切的虛擬機內的基礎設施將無法從容器啟動,並且門戶將不可用。 在 部署要求 詳細描述了所需的資源以及所有系統組件的端口。 

而且通過模板設置IP地址也很困難,所以我們從控制台更改了它。 之後,您可以轉到管理 Web 界面並完成初始配置嚮導。 

Hystax 雲遷移:駕馭雲端
Hystax 雲遷移:駕馭雲端
端點 - 我們的 vCenter 的 IP 或 FQDN。 
登錄名和密碼 - 這裡很清楚。 
目標 ESXi 主機名是將復製到的集群中的主機之一。 
目標數據存儲是我們集群中將執行複制的數據存儲之一。
Hystax Acura 控制面板公共 IP - 控制面板可用的地址。

需要對主機和數據存儲進行一些說明。 事實上,Hystax 複製工作在主機和數據存儲級別。 接下來,我將告訴您如何更改租戶的主機和數據存儲,但問題有所不同。 Hystax不支持資源池,即副本總是會發生在集群的根上(在撰寫本文時,Hystax 的人員發布了更新版本,他們很快實現了我有關資源池支持的功能請求)。 另外,不支持 vCloud Director,即。 如果像我的例子一樣,租戶沒有整個集群的管理員權限,而只有特定資源池的管理員權限,並且我們已經授予了 Hystax 的訪問權限,那麼他將能夠獨立復制和運行這些虛擬機,但是他將無法在他有權訪問的VMware 基礎架構中看到它們,並相應地進一步管理虛擬機。 集群管理員需要將虛擬機移至正確的資源池或將其導入 vCloud Director。

為什麼我如此關注這些時刻? 因為,據我了解產品的概念,客戶應該能夠使用 Acura 面板獨立實施任何遷移或災難恢復。 但到目前為止,VMware 的支持略低於對同一 OpenStack 的支持水平,後者已經實現了此類機制。 

但回到部署。 首先,在面板的初始設置之後,我們需要在系統中創建第一個租戶。

Hystax 雲遷移:駕馭雲端
這裡所有的字段都清楚了,我只告訴你Cloud字段。 我們已經擁有在初始配置期間創建的“默認”雲。 但是,如果我們希望能夠將每個租戶放在自己的數據存儲和自己的資源池中,我們可以通過為每個客戶創建單獨的雲來實現這一點。

Hystax 雲遷移:駕馭雲端
以添加新雲的形式,我們指定與初始配置期間相同的參數(我們甚至可以使用相同的主機),指定特定客戶所需的數據存儲,現在在附加參數中我們已經可以單獨指定所需的池資源{"resource_pool" :"YOUR_POOL_NAME"} 

您可能已經註意到,以創建租戶的形式,沒有任何關於資源分配或某種配額的內容 - 系統中沒有任何此類內容。 您不能限制租戶的並發副本數量、用於復制的計算機數量或任何其他參數。 這樣,我們就創建了第一個租戶。 現在有一個不完全合乎邏輯但強制性的事情 - 安裝雲代理。 這是不合邏輯的,因為代理是在特定客戶的頁面上下載的。

Hystax 雲遷移:駕馭雲端
同時,它不與創建的租戶綁定,我們的所有客戶都將通過它工作(或者在幾個之後,如果我們部署它們)。 一名代理支持 10 個並發會話。 一次會話算作一輛車。 有多少磁盤並不重要。 迄今為止,Acura 本身還沒有為 VMware 擴展代理的機制。 還有一個更令人不愉快的時刻 - 我們無法從 Acura 面板中查看該代理的“利用率”,從而得出是否需要部署更多代理或當前安裝是否足夠的結論。 結果,展台看起來像這樣:

Hystax 雲遷移:駕馭雲端
訪問客戶門戶的下一步是創建一個帳戶(首先,創建一個將應用於該用戶的角色)。

Hystax 雲遷移:駕馭雲端
Hystax 雲遷移:駕馭雲端
現在我們的客戶可以獨立使用該門戶。 他所需要做的就是從門戶下載代理並將其安裝在他這邊。 代理分為三種類型:Linux、Windows 和 VMware。

Hystax 雲遷移:駕馭雲端
前兩個放在任何非 VMware 虛擬機管理程序上的物理機或虛擬機上。 這裡不需要額外的配置,代理下載並已經知道在哪裡敲門,一分鐘後汽車就會在 Acura 面板中可見。 使用 VMware 代理時,情況會稍微複雜一些。 問題是 Agent for VMware 也是從已準備好的門戶下載的,並且具有必要的配置。 但是,VMware 代理除了了解我們的 Acura 門戶之外,還需要了解將部署它的虛擬化系統。

Hystax 雲遷移:駕馭雲端
實際上,第一次下載VMware代理時系統會要求我們指定這些數據。 問題是,在我們普遍熱愛安全的時代,並不是每個人都願意在別人的門戶上顯示他們的管理員密碼,這是可以理解的。 從內部來看,部署後,無法以任何方式配置代理(您只能更改其網絡設置)。 在這裡,我預見到特別謹慎的客戶會遇到困難。 

因此,安裝代理後,我們可以返回 Acura 面板並查看我們所有的汽車。

Hystax 雲遷移:駕馭雲端
由於我已經使用該系統一天多了,我的機器處於各種狀態。 所有這些都位於默認組中,但可以根據需要創建單獨的組並將計算機轉移到它們。 這不會影響任何東西 - 只會影響數據的邏輯表示及其分組,以便更方便地工作。 之後我們需要做的第一件也是最重要的事情就是開始遷移過程。 我們可以強製手動執行此操作,也可以設置時間表,包括一次性為所有機器批量執行此操作。

Hystax 雲遷移:駕馭雲端
讓我提醒您一下,Hystax 被定位為一個遷移產品。 因此,為了運行我們的複制機器,我們需要創建一個災難恢復計劃,這並不奇怪。 您可以為已處於同步狀態的計算機創建計劃。 您可以為一個特定虛擬機生成兩者,也可以同時為所有計算機生成這兩者。

Hystax 雲遷移:駕馭雲端
生成災難恢復計劃時的參數集會有所不同,具體取決於您要遷移到的基礎設施。 VMware 環境可以使用最少的選項集。 也不支持機器的重新 IP。 對此,我們感興趣的是以下幾點:在VM的描述中,“子網”參數:“VMNetwork”,我們將VM綁定到集群中的特定網絡。 排名 - 在遷移多個虛擬機時相關,決定它們的啟動順序。 Flavor 描述了 VM 配置,在本例中為 1CPU、2GB RAM。 在子網部分,我們定義“子網”:“VMNetwork”與 VMware 的“VM Network”相關聯。 

創建災難恢復計劃時,無法將磁盤“拆分”到不同的數據存儲上。 它們將位於為此客戶端雲定義的同一數據存儲上,如果您有不同類別的磁盤,這可能會在啟動機器時造成一些困難,並且在啟動並將虛擬機與Hystax“分離”後,它也會需要單獨的遷移磁盤到所需的數據存儲。 然後我們只需要運行我們的災難恢復計劃並等待我們的汽車升起。 P2V/V2V轉換過程也需要時間。 在我最大的 100GB 三個磁盤測試機器上,這最多需要 10 分鐘。

Hystax 雲遷移:駕馭雲端
之後,您應該檢查正在運行的虛擬機、其上的服務、數據一致性和其他檢查。 

那麼我們有兩個選擇: 

  1. 刪除 - 刪除正在運行的災難恢復計劃。 此操作將簡單地關閉正在運行的虛擬機。 這些複製品不會去任何地方。 
  2. 分離 - 從謳歌上撕下複製的汽車,即真正完成遷移過程。 

該解決方案的優點: 

  • 客戶端和提供商端均易於安裝和配置; 
  • 易於設置遷移、創建災難恢復計劃和啟動副本;
  • 支持和開發人員對發現的問題做出快速響應,並通過平台或代理更新來修復它們。 

缺點 

  • Vmware 支持不足。
  • 平台沒有任何租戶配額。 

我還提出了一個功能請求,我們將其交給了供應商:

  1. 通過 Acura 雲代理管理控制台進行使用情況監控和部署;
  2. 租戶配額的可用性; 
  3. 限制每個租戶同時復制的數量和速度的能力; 
  4. 支持VMware vCloud Director; 
  5. 對資源池的支持(在測試期間實現);
  6. 能夠從代理本身配置 VMware 代理,而無需從 Acura 面板中的客戶端基礎設施輸入憑據;
  7.  啟動災難恢復計劃時啟動虛擬機的過程“可視化”。 

唯一引起我大抱怨的是文檔。 我不太喜歡“黑匣子”,更喜歡有關於產品內部工作原理的詳細文檔。 如果對 AWS 和 OpenStack 的產品進行了或多或少的描述,那麼對 VMware 的文檔就很少了。 

有一個安裝指南,僅描述了 Acura 面板的部署,並且沒有提及是否需要雲代理。 產品有全套規格,很好。 有文檔以 AWS 和 OpenStack 為例描述了“從和到”的設置(儘管它讓我更多地想起了一篇博客文章),並且有一個非常小的知識庫。 

一般來說,這不太是我習慣的文檔格式,比如來自較大供應商的文檔格式,所以我不太舒服。 同時,我在這份文檔中並沒有找到有關係統“內部”操作的一些細微差別的答案——我必須通過技術支持來澄清很多問題,這相當拖延了部署展位和部署的過程。測試。 

總而言之,我可以說,總的來說,我喜歡該產品和公司執行任務的方法。 是的,確實存在缺陷,確實嚴重缺乏功能(與 VMware 結合使用)。 可以看出,首先,該公司仍然專注於公有云,特別是AWS,對於某些人來說這已經足夠了。 在很多企業選擇多雲策略的今天,擁有這樣一個簡單、便捷的產品是極其重要的。 鑑於與競爭對手相比價格低得多,這使得該產品極具吸引力。

我們正在尋找一個團隊 監控系統首席工程師。 也許這就是你?

來源: www.habr.com

添加評論