本文摘要說明有關 Azure Site Recovery 的常見問題集。 針對特定案例,請檢閱下列文章:
一般
Site Recovery 的功能是什麼?
Site Recovery 可協調並自動執行區域、內部部署虛擬機器和實體伺服器之間至 Azure 的 Azure VM 複寫;協調並自動執行內部部署機器至次要資料中心的複寫,藉此保障您的商務持續性與災害復原 (BCDR) 策略。 深入了解。
是否可以保護具有 Docker 磁碟的虛擬機器?
否,Azure Site Recovery 不支援在虛擬機上執行的 Docker 工作負載。 若要使用 Site Recovery 保護這些虛擬機器,請排除已安裝 Docker 的磁碟。
Site Recovery 如何確保資料完整性?
Site Recovery 會採用各種方法來確保資料完整性。 使用 HTTPS 通訊協定在所有服務之間建立安全連線。 這可確保任何惡意程式碼或外部實體都無法竄改資料。 另一個所採用的方法是使用總和檢查碼。 來源與目標之間的資料傳輸是透過計算其間資料的總和檢查碼來執行的。 這可確保所傳輸的資料是一致的。
如何移轉/保護在虛擬網路上需要永續性 MAC 位址的軟體?
Azure 不支持持續性 MAC 位址,因此無法將具有 MAC 型授權模型的軟體用於內部部署至 Azure 移轉或災害復原。
Azure Site Recovery 目前是否支持暫時性磁碟?
否,Azure Site Recovery 目前不支持暫時磁碟。
Microsoft Azure 復原服務代理程式的用途是什麼?
Microsoft Azure 復原服務代理程式的用途是設定/註冊 Site Recovery 服務,以及用於監視所有元件的健康情況。 此元件是整個 Azure Site Recovery 內部部署基礎結構的基本建置區塊之一。 這有助於將工作負載從內部部署網站復寫至另一個 Azure 區域,並在災害中故障轉移至 Azure。
服務提供者
我是服務提供者。 Site Recovery 是否適用於專用和共用基礎結構模型?
是,Site Recovery 同時支援專用與共用的基礎結構模型。
對服務提供者而言,租用戶的身分識別是否會與 Site Recovery 服務共用?
否。 租用戶身分識別會保持匿名。 您的租用戶不需要存取 Site Recovery 入口網站。 只有服務提供者系統管理員會與入口網站互動。
租用戶應用程式資料是否會傳送到 Azure?
當您複寫至 Azure 時,應用程式資料會傳送到 Azure 儲存體,而非 Site Recovery 服務。 資料會在傳輸中加密 (HTTPS),並在 Azure 中繼續維持加密狀態。
我的租用戶會收到來自 Azure 服務的帳單嗎?
否。 Azure 的計費關係是直接與服務提供者相關。 服務提供者負責為其租用戶產生特定的帳單。
如果我復寫至 Azure,我們一律需要在 Azure 中執行虛擬機嗎?
否,資料會複寫至您訂用帳戶中的 Azure 儲存體。 當您執行測試故障轉移(災害復原演練)或實際故障轉移時,Site Recovery 會自動在您的訂用帳戶中建立虛擬機。
當我複寫至 Azure 時,您會確保提供租用戶層級的隔離嗎?
是。
目前支援哪些平台?
我們支援「Azure 套件」、「雲端平台系統」及 System Center 架構 (2012 及更新版本) 的部署。 深入了解 「Azure 套件」和 Site Recovery 整合
您支援單一 Azure 套件與單一 VMM 伺服器部署嗎?
否,您只能將 Hyper-V 虛擬機複寫至 Azure。
定價
哪裡可以找到定價資訊?
如需詳細資料,請檢閱 Site Recovery 定價。
如何計算使用 Site Recovery 期間的大約費用?
使用 Site Recovery 時是否也會產生快取儲存體帳戶的費用?
是,使用 Site Recovery 複寫虛擬機時,快取記憶體帳戶使用量會產生額外費用。 當復本記憶體的類型是受控磁碟或非受控磁碟時,快取記憶體帳戶成本會維持不變。
我已經使用 Azure Site Recovery 一個多月了。 我的每個受保護的執行個體是否前 31 天仍然都免費?
是。 每個受保護的執行個體在前 31 天皆無 Azure Site Recovery 費用。 例如,如果您過去六個月保護了 10 個執行個體,而現在您將第 11 個執行個體連線到 Azure Site Recovery,則第 11 個執行個體的前 31 天不會有任何費用。 而前 10 個執行個體則因為受保護已超過 31 天,所以會繼續產生 Azure Site Recovery 費用。
在這前 31 天,我是否須負擔任何其他 Azure 費用?
是,即使受保護的執行個體前 31 天的 Site Recovery 免費,您仍有可能需要負擔 Azure 儲存體、儲存體交易與資料傳輸的費用。 復原的虛擬機器也可能會產生 Azure 計算費用。
執行災害復原演練/測試容錯移轉是否有相關成本?
災害復原演練沒有任何個別的成本。 在測試故障轉移之後建立虛擬機之後,會產生計算費用。
安全性
複寫資料會傳送到 Site Recovery 服務嗎?
否,Site Recovery 不會攔截複寫的資料,也不會擁有任何關於您虛擬機器或實體伺服器上執行哪些項目的資訊。 內部部署 Hyper-V 主機、VMware Hypervisor 或實體伺服器,會與 Azure 儲存體或次要站台交換複寫資料。 Site Recovery 並不具有攔截該資料的能力。 只有協調複寫與容錯移轉所需的中繼資料會被傳送給 Site Recovery 服務。
Site Recovery 已通過 ISO 27001:2013、27018、HIPAA、DPA 認證,並且正在進行 SOC2 和 FedRAMP JAB 評定程序。
為了遵循法規,甚至我們的內部部署中繼資料也必須保留在相同的地理區域內。 Site Recovery 可以幫助我們嗎?
是。 當您在某個區域中建立 Site Recovery 保存庫時,我們會確保我們啟用及協調複寫與容錯移轉時所需的一切中繼資料都會保留在該區域地理界限內。
Site Recovery 會將複寫加密嗎?
在將虛擬機器和實體伺服器複寫至 Azure 時,則同時支援傳輸中加密和靜態加密 (在 Azure 中)。
Azure 到 Azure Site Recovery 是否將 TLS 1.2 用於跨 Azure 微服務的所有通訊?
是,預設會針對 Azure 到 Azure Site Recovery 案例強制執行 TLS 1.2 通訊協定。
如何在 VMware 到 Azure 和實體伺服器到 Azure Site Recovery 案例上強制執行 TLS 1.2?
安裝在複寫項目上的行動代理程式只會在 TLS 1.2 上與處理序伺服器通訊。 不過,從組態伺服器到 Azure,以及從處理序伺服器到 Azure 的通訊都可以在 TLS 1.1 或1.0 上進行。 遵循指引,在您設定的所有組態伺服器和進程伺服器上強制執行 TLS 1.2。
注意
現代化體驗會針對所有通訊使用 TLS 1.2,並且預設會予以強制執行。
如何在 Hyper-V 對 Azure Site Recovery 案例上強制執行 TLS 1.2?
Azure Site Recovery 微服務之間的所有通訊都會在 TLS 1.2 通訊協定上發生。 Site Recovery 會使用系統 (OS) 中設定的安全性提供者,並使用最新可用的 TLS 通訊協定。 一個需要在登錄中明確啟用 TLS 1.2,然後 Site Recovery 會開始使用 TLS 1.2 與服務通訊。
如何在 Site Recovery 服務存取的記憶體帳戶上強制執行限制存取,以讀取/寫入復寫數據?
您可以前往 [識別] 設定來開啟復原服務保存庫的受控識別。 在向 Microsoft Entra ID 註冊保存庫之後,您便可以前往自己的儲存體帳戶並將下列角色指派提供給保存庫:
- Resource Manager 型儲存體帳戶 (標準類型):
- Resource Manager 型儲存體帳戶 (進階類型):
- 傳統儲存體帳戶:
受控識別不支援快取記憶體帳戶。
Azure Site Recovery 可以追蹤來源 OS 外部的來源虛擬機變更嗎?
Azure Site Recovery 不會追蹤來源 OS 外部的來源虛擬機變更。 例如,如果您使用 Azure 至 Azure 複寫並變更來源虛擬機的大小,則來源虛擬機的大小變更不會復寫至目標虛擬機。
災害復原
Site Recovery 可以保護什麼?
- Azure 虛擬機:Site Recovery 可以復寫在支援的 Azure 虛擬機上執行的任何工作負載。
- Hyper-V 虛擬機:Site Recovery 可以保護 Hyper-V 虛擬機上執行的任何工作負載。
- 實體伺服器:Site Recovery 可以保護執行 Windows 或 Linux 的實體伺服器。
- VMware 虛擬機:Site Recovery 可以保護 VMware 虛擬機中執行的任何工作負載。
我可以使用 Site Recovery 來保護哪些工作負載?
您可以使用 Site Recovery 來保護在支援的虛擬機或實體伺服器上執行的大部分工作負載。 Site Recovery 支援應用程式感知複寫,可讓應用程式復原為智慧型狀態。 除了與 Microsoft 應用程式 (例如 SharePoint、Exchange、Dynamics、SQL Server 及 Active Directory) 整合之外,它還與產業龍頭 (包括 Oracle、SAP、IBM 及 Red Hat) 密切合作。 深入了解 工作負載保護。
我可以使用 Site Recovery 來管理分公司的災害復原嗎?
是。 當您使用 Site Recovery 來協調分公司中的複寫與容錯移轉時,會為您集中提供所有分公司工作負載的整合協調與檢視。 您不需要造訪分公司,就可以從總公司輕鬆執行所有分公司的容錯移轉及管理災害復原。
Azure 虛擬機是否支援災害復原?
是,Site Recovery 支援 Azure 區域之間 Azure 虛擬機的災害。 檢閱 Azure 虛擬機災害復原的 常見問題。 如果您想要在相同大陸的兩個 Azure 區域之間進行復寫,請使用我們的 Azure 至 Azure 災害復原供應專案。 不需要設定組態伺服器/處理序伺服器和 ExpressRoute 連線。
VMware 虛擬機是否支援災害復原?
是,Site Recovery 支持內部部署 VMware 虛擬機的災害復原。 檢閱 VMware 虛擬機災害復原的常見問題 。
Hyper-V 虛擬機是否支援災害復原?
是,Site Recovery 支持內部部署 Hyper-V 虛擬機的災害復原。 檢閱 Hyper-V 虛擬機災害復原的常見問題 。
是否支援實體伺服器的災害復原?
是,Site Recovery 支援將執行 Windows 和 Linux 的內部部署實體伺服器災害復原至 Azure。 瞭解災害復原至 Azure 的需求。 在故障轉移之後,實體伺服器會在 Azure 中以虛擬機身分執行。 目前不支援從 Azure 容錯回復至內部部署實體伺服器。 您只能容錯回復至 VMware 虛擬機器。
我是否可以將復原服務保存庫移至不同的訂用帳戶?
否,Azure Site Recovery 不支援移動已裝載於其中之虛擬機的復原服務保存庫。
複寫
我可以透過站對站 VPN 複寫至 Azure 嗎?
Azure Site Recovery 會透過公用端點,將資料複製到 Azure 儲存體帳戶或受控磁碟。 然而,也可以透過站對站 VPN 執行複寫。 站對站 VPN 連線可讓組織將現有的網路連線至 Azure,或讓 Azure 網路彼此連線。 站對站 VPN 會透過IPSec通道透過因特網進行,使用 Azure 中現有的內部部署邊緣網路設備和網路設備,例如 Azure 虛擬專用網 (VPN) 網關或第三方選項,例如 Check Point CloudGaurd、Palo Alto NextGen 防火牆等原生功能。
- 透過公用網際網路連線至 Microsoft Edge 的私人連線
- 使用私人端點設定復原服務保存庫的安全性
- 透過客戶私人虛擬網路連線進行複寫
- 輕鬆轉換至「未來狀態」
- 沒有 SLA 和潛在的較高延遲
- 需要有可用的內部部署 VPN 裝置
我可以使用 Riverbed SteelHeads 進行複寫嗎?
我們的合作夥伴 Riverbed 提供有關使用 Azure Site Recovery 的詳細指引。 請檢閱其解決方案指南。
可以使用 ExpressRoute 將虛擬機器複寫到 Azure 嗎?
是的,可以使用 ExpressRoute 將內部部署虛擬機器複寫至 Azure。
- Azure Site Recovery 會透過公用端點,將資料複製到 Azure 儲存體。 您必須設定 Microsoft 對等互連或使用現有的公用對等互連 (已遭新線路棄用),才能使用 ExpressRoute 進行 Site Recovery 複寫。
- 路由網域以進行複寫時建議使用 Microsoft 對等互連。
- 只有當保存庫啟用私人端點時,才能透過私人對等互連支援複寫。
- 如果您要保護 VMware 機器或實體機器,請確定也符合組態伺服器的網路需求。 設定伺服器要求連線至特定 URL,以進行 Site Recovery 複寫的協調流程。 ExpressRoute 無法用於此連線。
- 將虛擬機故障轉移至 Azure 虛擬網路之後,您可以使用 Azure 虛擬網路的私人對等互連設定來存取它們。
如果複寫至 Azure,我需要哪一種儲存體帳戶或受控磁碟?
Azure Site Recovery 不支援使用記憶體帳戶作為目標記憶體。 建議您改為使用受控磁碟作為機器的目標儲存體。 受控磁碟針對資料復原僅支援 LRS 類型。
我可以多久複寫一次資料?
- Hyper-V: Hyper-V 虛擬機可以每隔 30 秒復寫一次(進階記憶體除外)或五分鐘。
- Azure 虛擬機、VMware 虛擬機、實體伺服器: 復寫頻率在這裡並不相關。 複寫是連續的。
我可以將複寫從現有的復原網站延伸到另一個第三網站嗎?
不支援延伸的或鏈結的複寫。 請在 意見反應論壇中提出這項功能的要求。
我可以在第一次複寫至 Azure 時進行離線複寫嗎?
不支援此動作。 請在 意見反應論壇中提出這項功能的要求。
我可以從複寫中排除特定的磁碟嗎?
當您使用 Azure 入口網站 將 VMware 虛擬機和 Hyper-V 虛擬機複寫至 Azure 時,支援此功能。
我可以使用動態磁碟來複寫虛擬機器嗎?
復寫 Hyper-V 虛擬機,以及將 VMware 虛擬機和實體機器復寫至 Azure 時,支援動態磁碟。 作業系統磁碟必須是基本磁碟。
我是否可以將分配給 Hyper-V 複寫流量的頻寬節流?
是。 您可以在下列文章中深入了解如何將頻寬節流:
我是否能在 Linux 伺服器上啟用具備應用程式一致性的複寫?
是。 適用於 Linux 作業系統的 Azure Site Recovery 支援使用應用程式自訂指令碼來達成應用程式一致性。 Azure Site Recovery 行動代理程式會在應用程式一致性期間使用具有預先和後置選項的自定義腳本。 以下是啟用它的步驟。
以 root 身分登入機器。
將目錄變更至 Azure Site Recovery 行動代理程式安裝位置。 預設值為 "/usr/local/ASR"
# cd /usr/local/ASR
將目錄變更至安裝位置下的 "VX/scripts"
# cd VX/scripts
建立名為 "customscript.sh" 且具備 root 使用者執行權限的 bash 殼層指令碼。
a. 指令碼應該要支援 "--pre" 和 "--post" (請注意雙虛線) 命令列選項
b. 搭配前置選項呼叫指令碼時,其應該會凍結應用程式輸入/輸出,而搭配後置選項呼叫時,其應該會將應用程式輸入/輸出解除凍結。
c. 範例範本 -# cat customscript.sh
#!/bin/bash
if [ $# -ne 1 ]; then
echo "Usage: $0 [--pre | --post]"
exit 1
elif [ "$1" == "--pre" ]; then
echo "Freezing app IO"
exit 0
elif [ "$1" == "--post" ]; then
echo "Thawed app IO"
exit 0
fi
- 針對需要應用程式一致性的應用程式,在前置和後置步驟中新增凍結和解除凍結輸入/輸出命令。 您可以選擇新增另一個指令碼來指定那些項目,並搭配前置和後置選項從 "customscript.sh" 中加以叫用。
注意
Site Recovery 代理程式版本應該要是 9.24 或更新版本以支援自訂指令碼。
複寫原則
什麼是複寫原則?
複寫原則會定義復原點保留歷程記錄的設定。 此原則也會應用程式一致快照集的頻率。 Azure Site Recovery 預設會建立具有下列預設設定的新複寫原則:
- 復原點的保留歷程記錄為一天。
- 沒有應用程式一致快照集。
什麼是當機時保持一致復原點?
當機時保持一致復原點具有磁碟上的資料,就像您在擷取快照集期間從伺服器拔掉電源線一樣。 損毀一致復原點不包含擷取快照時記憶體內的任何資料。
現今,大多數應用程式都可以妥善地從當機時保持一致快照集復原。 當機一致的恢復點足以用於無資料庫操作系統和應用程式,例如檔伺服器、DHCP 伺服器和列印伺服器。
當機時保持一致復原點產生的頻率為何?
Site Recovery 會每 5 分鐘建立一次當機時保持一致復原點。
什麼是應用程式一致復原點?
應用程式一致復原點是從應用程式一致快照集建立的。 應用程式一致快照集所擷取的資料與當機時保持一致復原點相同,同時也會擷取記憶體內的所有資料,以及所有進行中的交易。
由於有這些額外的內容,因此應用程式一致快照集包含最多內容,且需要最長的時間。 建議您針對資料庫作業系統和 SQL Server 之類的應用程式,使用應用程式一致復原點。
注意
如果 Windows 機器具有超過 64 個磁碟區,則在其上建立應用程式一致復原點將會失敗。
應用程式一致復原點對應用程式效能有何影響?
應用程式一致復原點會擷取記憶體內的所有資料和進行中的所有資料。 因為復原點會擷取該資料,所以需要類似 Windows 上磁碟區陰影複製服務的架構,來停止應用程式。 如果擷取程序頻繁執行,則當工作負載忙碌時,可能會影響效能。 我們不建議針對非資料庫工作負載的應用程式一致復原點使用低頻率。 即使是針對資料庫工作負載,1 小時就夠了。
應用程式一致復原點產生的最小頻率為何?
Site Recovery 可以建立最小頻率為 1 小時的應用程式一致復原點。
復原點要如何產生和儲存?
若要了解 Site Recovery 如何產生復原點,讓我們看看複寫原則的範例。 此複寫原則具有保留時間範圍為 1 天,且應用程式一致快照集頻率為 1 小時的復原點。
Site Recovery 會每 5 分鐘建立一次當機時保持一致復原點。 您無法變更此頻率。 在最近的 2 小時內,您可以從 24 個損毀一致點和 2 個應用程式一致點中選擇。 經過一段時間後,Site Recovery 會將過去 2 小時以外的所有復原點剪除,而只儲存每小時一個復原點,最多一天 24 個小時。
以下螢幕擷取畫面說明此範例。 在螢幕擷取畫面中:
在過去 2 小時內,每 5 分鐘就有一個復原點。
在過去 2 小時以外的時間,Site Recovery 每小時只會保留一個復原點。
最多可復原至多久之前?
您可以使用的最舊復原點,有受控磁碟是 15 天和非受控磁碟則是三天。
我有一天的複寫原則。 如果某個問題導致 Site Recovery 超過一天無法產生復原點,將會發生什麼情況? 我先前的復原點是否會遺失?
否,Site Recovery 會保留您先前的所有恢復點。 根據復原點的保留時間範圍,Site Recovery 只會在產生新的復原點時,才會取代最舊的復原點。 由於發生問題,Site Recovery 無法產生任何新的復原點。 直到有新的恢復點為止,在您到達保留期間之後,所有舊的點都會維持不變。
在虛擬機上啟用複寫之後,如何變更複製策略?
移至 [Site Recovery 保存庫]>[Site Recovery 基礎結構]>[複寫原則]。 選取您想要編輯的原則,然後儲存變更。 任何變更也適用於所有現有的複寫。
所有恢復點都是虛擬機或差異的完整複本嗎?
所產生的第一個復原點會具有完整複本。 所有後續復原點則具有差異變更。
增長復原點的保留週期是否會增加儲存體成本?
是,如果您將保留期間從一天增加到三天,Site Recovery 會額外儲存恢復點兩天。 增加的時間將會產生儲存體費用,因為將保留期間從一天增加到三天後,便會額外儲存 12 個復原點。 例如,單一復原點可能會有 10 GB 的差異變更,每個月的每 GB 成本為 $0.16。 額外費用將是每月 $1.60 × 12。
容錯移轉
如果我故障轉移至 Azure,如何在故障轉移後存取 Azure 虛擬機?
您可以透過安全的因特網連線、站對站 VPN 或透過 Azure ExpressRoute 存取 Azure 虛擬機。 您必須做好一些準備才能連線。 深入了解。
如果我容錯移轉到 Azure,Azure 如何確定我的資料具有復原能力?
Azure 是針對復原能力而設計的。 Site Recovery 已設計成可根據 Azure SLA 容錯移轉至次要 Azure 資料中心。 如果發生這種情況,我們會確保您的中繼資料和保存庫都保留在您為保存庫選擇的相同地理區域中。
如果我在兩個資料中心之間進行複寫,當我的主要資料中心發生意外中斷時,會發生什麼情況?
您可以從次要站台觸發非計劃性容錯移轉。 Site Recovery 不需要來自主要站台的連線即可執行容錯移轉。
容錯移轉是自動發生的嗎?
容錯移轉並非自動發生。 您可以在入口網站中按一下某個按鈕來起始容錯移轉,或是使用 Site Recovery PowerShell 來觸發容錯移轉。 容錯回復在 Site Recovery 入口網站中是一個簡單的動作。
若要進行自動化,您可以使用內部部署 Orchestrator 或 Operations Manager 來偵測虛擬機器失敗,然後使用 SDK 來觸發容錯移轉。
如果我的內部部署主機沒有回應或當機,我是否能針對不同的主機進行容錯回復?
是,您可以使用替代位置復原從 Azure 針對不同的主機進行容錯回復。
[完成移轉]、[認可] 和 [停用複寫] 之間有什麼差異?
當機器已從來源位置容錯移轉到目標位置時,將會有三個選項可供您選擇。 這三個選項都有不同的用途 -
- 完成移 轉表示您不會再回到來源位置。 您已移轉到目標區域,而且工作已經完成。 按一下 [完成移轉] 會在內部觸發 [認可],接著觸發 [停用複寫]。
- 認可表示這並非您複寫程序的結尾。 複寫項目以及所有設定都會保留下來,您可以在稍後的時間點按一下 [重新保護] 來將電腦複寫回來源區域。
- [停用複寫] 將會停用複寫,並移除所有相關設定。 其不會影響目標區域中的現有機器。
自動化
我是否可以透過 SDK 自動化 Site Recovery 案例?
是。 您可以使用 REST API、PowerShell 或 Azure SDK 將 Site Recovery 的工作流程自動化。 針對使用 PowerShell 來部署 Site Recovery,目前支援的案例包括︰
AzureRM 模組的淘汰是否會影響 Site Recovery 自動更新如何與自動化帳戶搭配運作?
否,AzureRM 模組的淘汰不會影響 Site Recovery 自動更新的運作方式。 內部 Runbook 不需要變更,且就地使用的 REST API 仍會如預期般運作自動化帳戶。