大約 7 年前，第一個專案簡單而樸實地遷移到我們的雲端。 虛擬機器映像上傳到 FTP 伺服器，或傳送到硬碟上。 然後，透過特殊的導入伺服器，將虛擬機器上傳到雲端。
如果客戶端關閉虛擬機器一兩天沒有問題（或沒有其他選擇），那麼可以這樣做。 但如果停機時間最長為一個小時，則此方法將無法運作。 今天，我將告訴您哪些工具可以幫助您以最短的停機時間遷移到雲，以及我們的遷移過程本身是如何運作的。
使用 Veeam Backup and Replication 進行遷移
每個人都知道 Veeam Backup and Replication 作為建立備份和副本的工具。 我們使用它在我們的站點之間進行遷移，並將客戶從私有虛擬化傳輸到我們的雲端。 客戶的虛擬機器被複製到我們的 vCenter，之後工程師將它們加入 vCloud Director。
主複製發生在已開啟電源的虛擬機器上。 在約定的時間，客戶端機器關閉。 複製再次運行以延續自第一次複製以來發生的更改。 之後，虛擬機器將在我們的雲端中啟動。
通常，從機器在客戶端基礎架構上關閉的那一刻起，到在我們的雲端中開啟機器的那一刻起，不會超過半小時，而是 15-20 分鐘。
在這種情況下，原始虛擬機器仍保留在用戶端網站上。 如果突然出現問題，您可以隨時回滾並打開它。 這種方法對客戶來說也很方便，因為它不需要他擁有 Veeam。
情況1
該客戶擁有自己的基於 VMware 的虛擬基礎架構 - 40 個虛擬機，容量為 30 TB。 部署叢集的設備已經過時，客戶決定不再購買新設備，而是遷移到公有雲。 關鍵系統的停機時間需求不超過一個小時。 選擇 Veeam Replication 作為工具。 另一個優點是客戶的網路供應商位於我們的資料中心，這使得組織良好的管道成為可能。 遷移耗時約一個月，每組虛擬機器切換期間的停機時間長達 30 分鐘。
使用 Veeam Cloud Connect 進行遷移
Veeam Cloud Connect 是一款可協助您在服務供應商的雲端中設定虛擬機器複製和啟動副本的工具。 更新到後 今年，將虛擬機器直接複製到 vCloud Director 成為可能。 唯一的條件是在客戶端，Veeam Backup and Replication 必須至少部署版本 9。簡而言之（詳細版本 ），那麼整個過程就是這樣的。
在 vCloud Director 中，使用必要的資源和網路來建立組織。 在 Veeam Cloud Connect 中，我們建立一個帳戶，客戶端從他的 Veeam B&R 連接到該帳戶，選擇 DataLine 提供者和組織，並配置複製任務。 除了在此類遷移期間停機時間將在 15-20 分鐘內之外，客戶端不以任何方式依賴提供者的技術支援並獨立管理整個流程：建立複製任務、複製本身、關閉機器並在新站點上啟動它們。
情況2
計劃遷移的客戶基礎設施位於白俄羅斯。 儘管 Internet 通道為 90 Mbit/秒，但仍需傳輸 27 個虛擬機，總容量為 100 TB。 如果您進行備份並立即將其上傳到我們的雲，那麼對於某些虛擬機器來說，這可能需要幾天的時間。 在此期間，虛擬機器上會出現較大的增量，這可能會對電腦的效能產生負面影響，或者更糟的是，資料儲存上的空間可能會耗盡。 我們的營運流程如下：首先，客戶進行本機完整備份，並透過 Veeam Cloud Connect 將其副本傳輸到我們的雲端。 然後我製作增量並將其傳輸到雲端。 原來的虛擬機器繼續運作。 關閉虛擬機器後，客戶端再次增量，也將其傳輸到雲端。 在我們這邊，我們從完整備份部署了一個虛擬機，然後在其上滾動了兩個增量。 該方案最終使切換到我們站點時的停機時間降至 2 小時成為可能。
使用 VMware vCloud 可用性進行遷移
今年3.0月，VMware發布了vCloud Availability XNUMX，它允許您在不同雲端之間（vCloud Director - vCloud Director）以及從私有客戶虛擬化網站到雲端（vCenter - vCloud Director）遷移虛擬機器。 主要的便利在於與 vCloud Director 介面的整合。 這極大地簡化了複製管理流程並最大限度地減少了切換期間的停機時間。
使用此工具，我們將其中一個客戶端從莫斯科雲端遷移到聖彼得堡的雲端。 需要傳輸 18 台虛擬機，總容量為 14 TB。 在聖彼得堡雲端中為客戶創建了一個組織，並組織了必要的網路。 接下來，客戶端從 vCloud Director 介面進入 vCloud Availability 設置，建立複製作業，並在方便的時間切換到聖彼得堡網站。 切換期間的停機時間為 12 分鐘。
聖彼得堡和莫斯科 DataLine 雲端之間的遷移方案。
vCloud Availability 具有將虛擬機器從客戶網站遷移到我們的雲端的機制。 為此，需要在客戶端的 vCenter 中部署特殊的 vCloud Availability 應用程式。 簡單設定後，您可以連接到雲端並配置遷移任務。 客戶也獨立管理整個流程，並將遷移時間保持在最低限度。
將虛擬機器從私有安裝遷移到雲端的方案。
VMware vCloud Availability 還有許多其他用例；我們很快就會在另一篇文章中討論它們。
準備遷移
要選擇工具並實際開始遷移，您需要確定以下幾點：
我們從哪裡遷移？ 如果您從私有解決方案遷移，那麼您可以完全自由地選擇工具。 如果您離開您的提供者，那麼事情就會變得更加複雜。 由於安全原因，連結兩個提供者的基礎設施並簡單地拖放虛擬機器很可能行不通。 有時，客戶即將拒絕的提供者會開始調皮並拖延時間。 您可以採用老式方式擺脫提供者：將虛擬機器上傳到磁碟和 FTP，或在應用程式層級進行遷移。 後者的名稱是有條件的，看起來像這樣。
情況3
需要從歐洲供應商遷移客戶的 SAP 系統：34 個虛擬機，容量為 54 TB。 客戶在我們的雲端中分配了資源。 我們和歐洲供應商的基礎設施之間組織了網路連線。 應用程式伺服器被重新部署，並滾動了必要的配置。 透過將備份上傳到我們的雲端來遷移大型資料庫。 接下來，在我們和原始網站上的資料庫之間配置複製。 在約定的時間，我們切換到雲端中的資料庫。
數據量和網際網路通路。 我們通常要求客戶提供系統上傳的記憶體、CPU、磁碟參數。 我們評估該通道是否足以直接發送虛擬機器的副本或備份。
可接受的停機時間。 對於不同的系統以及相應的虛擬機，它可能會有所不同，具體取決於其業務關鍵性。 通常客戶對遷移過程中的停機時間有現成的要求，我們根據此選擇合適的工具和遷移計劃。 我們嘗試將最終切換安排在晚上或週末，這樣即使是輕微的停機時間也不會被客戶的最終用戶注意到。
根據此數據，您可以選擇一個工具並開始遷移本身。 接下來會發生什麼事。
- 設定網路連線。 我們組織雲端和客戶基礎設施之間的網路連接。 虛擬機器將透過該網路進行複製。 如果使用 Veeam Backup and Replication，則這是專用通道，很少是 VPN 通道。 如果是 Veeam Cloud Connect，那麼一切都透過網路或相同的專用通道進行。
然後為雲端中的VM配置網路。 汽車通常成群行駛且行駛時間超過一天。 一旦虛擬機器被帶到我們這裡並啟動，它們必須與仍保留在原始站點的電腦進行通訊。
- 遷移時間表。 當汽車很多時，將它們分成組並分批運輸是有意義的。 我們與客戶一起商定了一項計劃，其中指定何時以及哪些機器將移動，以及何時執行最終複製和切換到新站點。
- 測試遷移。 我們遷移測試虛擬機器並檢查所有設定是否正確：網站之間的網路連線、虛擬機器對來源站點上的電腦的可用性、帳戶權限等。 此測試有助於避免戰鬥遷移階段出現問題。
這就是我的全部。 在評論中提出問題並告訴我們您的遷移經驗。
來源： www.habr.com