遷移至 Azure 雲端服務 (延伸支援) 的技術詳細資料
本文討論移轉工具 (如雲端服務 (傳統)) 的相關技術詳細資料。
關於移轉支援的功能/案例的詳細資料
延伸模組和外掛程式移轉
- 將移轉所有已啟用和支援的延伸模組。
- 停用的延伸模組將不會移轉。
- 外掛程式是舊版概念,並且應該在移轉之前移除。 支援移轉外掛程式,但在移轉之後,如果需要啟用延伸模組,必須先移除外掛程式,才能安裝延伸模組。 受這項限制影響最多的是遠端桌面外掛程式和延伸模組。
憑證移轉
- 在雲端服務 (延伸支援) 中,憑證會儲存在 Key Vault 中。 隨著移轉的一部分,我們會為擁有雲端服務名稱的客戶建立 Key Vault,並將所有憑證從 Azure Service Manager 轉移至 Key Vault。
- 此 Key Vault 的參考是在範本中指定,或透過 PowerShell 或 Azure CLI 傳遞。
服務設定和服務定義檔案
- 必須更新 .cscfg 和 .csdef 檔案,才能為雲端服務 (延伸支援) 進行次要變更。
- 虛擬網路和虛擬機器 (VM) SKU 等資源的名稱有所不同。 請參閱移轉後資源和命名慣例的轉譯
- 客戶可以透過 PowerShell 和 REST API 擷取其新部署。
雲端服務和部署
- 每個雲端服務 (延伸支援) 部署都是獨立的雲端服務。 不再使用位置將部署分組到雲端服務。
- 如果您的雲端服務 (傳統) 中有兩個位置,您需要刪除一個位置 (預備),並使用移轉工具來將另一個 (生產) 位置移至 Azure Resource Manager。
- 移轉至 Azure Resource Manager 之後,雲端服務部署上的公用 IP 位址會維持不變,並且會以基本 SKU IP (動態或靜態) 資源的形式公開。
- 已移轉雲端服務的 DNS 名稱和網域 (cloudapp.net) 會保持不變。
虛擬網路移轉
- 如果雲端服務部署位於虛擬網路中,則移轉期間會一起移轉所有雲端服務和相關聯的虛擬網路資源。
- 移轉之後,虛擬網路會放置在與雲端服務不同的資源群組中。
- 對於具有多個雲端服務的虛擬網路,每個雲端服務會逐一移轉。
移轉不在虛擬網路中的部署
- 在 2018 年末,Azure 開始自動將新的部署 (沒有客戶指定的虛擬網路) 建立至平台建立的「預設」虛擬網路。 這些預設虛擬網路會向客戶隱藏。
- 在移轉過程中,此預設虛擬網路會在 Azure Resource Manager 中向給客戶公開一次。 若要在 Azure Resource Manager 中管理或更新部署,客戶必須在 .cscfg 檔案的 NetworkConfiguration 區段中新增此虛擬網路資訊。
- 預設虛擬網路會在移轉至 Azure Resource Manager 時,放在與雲端服務相同的資源群組中。
- 在此時間 (在 2018 年底之前) 之前建立的雲端服務不會位於任何虛擬網路中,且無法使用此工具進行移轉。 考量直接在 Azure Resource Manager 中重新部署這些雲端服務。 另一種方法是透過建立新的預備部署和 VIPSwap 移轉,請參閱這裡的更多詳細資料
- 若要檢查部署是否符合移轉資格,請在部署上執行驗證 API。 驗證 API 的結果會包含明確提及此部署是否符合移轉資格的錯誤訊息。
Load Balancer
- 針對使用公用端點的雲端服務,平台建立、與雲端服務相關聯的負載平衡器即會在 Azure Resource Manager 的客戶訂用帳戶內公開。 該負載平衡器是唯讀資源,而且更新僅限於透過服務設定 (.cscfg) 和服務定義 (.csdef) 檔案來進行。
Key Vault
- 隨著移轉的一部分,Azure 會自動建立新的 Key Vault,並將所有憑證移轉至其中。 該工具不允許您使用現有的 Key Vault。
- 雲端服務 (延伸支援) 需要位於相同區域和訂用帳戶的 Key Vault。 此 Key Vault 會自動隨著移轉的一部分建立。
無法移轉的資源和功能
此清單包含涉及資源、功能和雲端服務組合的常見案例。 這份清單並不完整。
資源 | 後續步驟/因應措施 |
---|---|
自動調整規則 | 移轉可進行,但會捨棄規則。 在雲端服務 (延伸支援) 上移轉之後重新建立規則。 |
警示 | 移轉可進行,但會捨棄警示。 在雲端服務 (延伸支援) 上移轉之後重新建立規則。 |
VPN 閘道 | 在開始移轉前移除 VPN 閘道,然後在移轉完成後重新建立 VPN 閘道。 |
ExpressRoute 閘道 (僅限與虛擬網路位於相同的訂用帳戶中) | 在開始移轉前移除 ExpressRoute 閘道,然後在移轉完成後重新建立閘道。 |
配額 | 配額不會移轉。 在移轉前在 Azure Resource Manager 上要求新的配額,讓驗證成功。 |
同質群組 | 不支援。 移轉之前移除任何同質群組。 |
使用虛擬網路對等互連的虛擬網路 | 移轉與另一個虛擬網路對等互連的虛擬網路之前,請先刪除對等互連、將虛擬網路移轉至 Resource Manager,並重新建立對等互連。 根據架構,這可能會導致停機時間。 |
包含 App Service 環境的虛擬網路 | 不支援 |
具有 Azure Batch 部署的虛擬網路 | 不支援 |
包含 HDInsight 服務的虛擬網路 | 不支援。 |
包含 Azure API 管理部署的虛擬網路 | 不支援。 若要移轉虛擬網路,請變更 API 管理部署的虛擬網路。 這是不需停機時間的作業。 |
傳統 ExpressRoute 線路 | 不支援。 在開始 PaaS 移轉之前,需要將這些線路移轉至 Azure Resource Manager。 若要深入了解,請參閱將 ExpressRoute 線路從傳統部署模型移至 Resource Manager 部署模型。 |
角色型存取控制 | 移轉後,資源的 URI 會從 Microsoft.ClassicCompute 變更為 Microsoft.Compute ,因此必須在移轉之後更新 RBAC 原則。 |
應用程式閘道 | 不支援。 在開始移轉前移除應用程式閘道,然後在移轉至 Azure Resource Manager 完成後重新建立應用程式閘道 |
不支援的設定/移轉案例
設定/案例 | 後續步驟/因應措施 |
---|---|
移轉不在虛擬網路中的某些較舊的部署 | 不支援移轉某些不在虛擬網路中的雲端服務部署。 1.使用驗證 API 來檢查部署是否符合移轉資格。 2.如果符合資格,部署會移至 Azure Resource Manager 前置詞為 “DefaultRdfeVnet” 的虛擬網路下 |
使用動態 IP 位址移轉包含生產位置和預備位置部署的部署 | 移轉有兩個位置的雲端服務需要刪除預備位置。 刪除預備位置之後,請在 Azure Resource Manager 中將該生產位置移轉至獨立的雲端服務 (延伸支援)。 然後,將預備環境重新部署為新的雲端服務 (延伸支援),並讓其與第一個雲端服務交換。 |
使用保留的 IP 位址移轉包含生產位置和預備位置部署的部署 | 不支援。 |
在不同虛擬網路中移轉生產環境和預備部署 | 移轉有兩個位置的雲端服務需要刪除預備位置。 刪除預備位置之後,請在 Azure Resource Manager 中將該生產位置移轉至獨立的雲端服務 (延伸支援)。 接著新的雲端服務 (延伸支援) 部署可以連結至已啟用可交換屬性的已移轉部署。 您可以重複使用舊預備位置部署的部署檔案,以建立這個新的可交換部署。 |
移轉空白的雲端服務 (沒有部署的雲端服務) | 不支援。 |
移轉包含遠端桌面外掛程式和遠端桌面延伸模組的部署 | 選項 1:移轉之前移除遠端桌面外掛程式。 這需要變更部署檔案。 然後,就會進行移轉。 選項 2:移除遠端桌面延伸模組並移轉部署。 移轉後,移除外掛程式並安裝延伸模組。 這需要變更部署檔案。 移轉之前移除外掛程式和延伸模組。 在雲端服務 (延伸支援) 上使用外掛程式是不建議的作法。 |
同時具有 PaaS 和 IaaS 部署的虛擬網路 | 不支援 將 PaaS 或 IaaS 部署其中一個移至不同的虛擬網路。 這會導致停機。 |
使用舊版角色大小 (例如 Small 或 ExtraLarge) 的雲端服務部署。 | 移轉之前,必須先更新角色大小。 更新所有部署成品,以參考這些新的新式角色大小。 如需詳細資訊,請參閱可用的 VM 大小 |
將雲端服務移轉至不同的虛擬網路 | 不支援 1.在移轉之前,將部署移至不同的傳統虛擬網路。 這會導致停機。 2.將新的虛擬網路移轉至 Azure Resource Manager。 或 1.將虛擬網路移轉至 Azure Resource Manager 2.將雲端服務移至新的虛擬網路。 這會導致停機。 |
虛擬網路中沒有指派具有明確子網路的雲端服務 | 不支援。 緩解措施涉及將角色移至子網路,這需要將角色重新啟動 (停機時間) |
移轉後資源和命名慣例的轉譯
隨著移轉的一部分,資源名稱會變更,而少數雲端服務功能會公開為 Azure Resource Manager 資源。 下表摘要說明雲端服務移轉的特定變更。
雲端服務 (傳統) 資源名稱 |
雲端服務 (傳統) 語法 |
雲端服務 (延伸支援) 資源名稱 |
雲端服務 (延伸支援) 語法 |
---|---|---|---|
雲端服務 | cloudservicename |
沒有關聯 | 沒有關聯 |
部署 (入口網站建立) 部署 (非入口網站建立) |
deploymentname |
雲端服務 (延伸支援) | cloudservicename |
虛擬網路 | vnetname Group resourcegroupname vnetname 沒有關聯 |
虛擬網路 (非入口網站建立) 虛擬網路 (入口網站建立) 虛擬網路 (預設) |
vnetname group-resourcegroupname-vnetname VNet-cloudservicename |
沒有關聯 | 沒有關聯 | Key Vault | KV-cloudservicename |
沒有關聯 | 沒有關聯 | 雲端服務部署的資源群組 | cloudservicename-migrated |
沒有關聯 | 沒有關聯 | 虛擬網路的資源群組 | vnetname-migrated group-resourcegroupname-vnetname-migrated |
沒有關聯 | 沒有關聯 | 公用 IP (動態) | cloudservicenameContractContract |
保留的 IP 名稱 | reservedipname |
保留的 IP (非入口網站建立) 保留 IP (入口網站建立) |
reservedipname group-resourcegroupname-reservedipname |
沒有關聯 | 沒有關聯 | Load Balancer | LB-cloudservicename |
移轉問題以及如何處理。
移轉長時間停滯在某個作業中。
- 根據部署數目而定,認可、準備和中止可能需要很長的時間。 作業會在 24 小時之後逾時。
- 認可、準備和中止作業是等冪的。 大部分的問題都可以藉由重試來修正。 可能會有暫時性錯誤,其在幾分鐘後可能會消失,建議您隔一些時間之後重試。 如果是使用 Azure 入口網站進行移轉,且作業停滯在「進行中」狀態,請使用 PowerShell 來重試作業。
- 請連絡支援人員以協助從後端移轉或復原部署。
移轉於某個作業中失敗。
- 如果驗證失敗,這是因為部署或虛擬網路包含不支援的案例/功能/資源。 使用不支援的案例清單來尋找文件中的因應措施。
- 準備作業會先進行驗證,包括一些昂貴的驗證 (未涵蓋在驗證中)。 準備失敗可能是因為不支援的案例所導致。 在公用文件中尋找案例和因應措施。 必須呼叫中止,才能回到原始狀態,並解除鎖定更新和刪除作業的部署。
- 如果中止失敗,請重試作業。 如果重試失敗,則連絡支援人員。
- 如果認可失敗,請重試作業。 如果重試失敗,則連絡支援人員。 即使在認可失敗中,您的部署應該不會有資料平面問題。 您的部署應該能夠處理客戶流量,而不會發生任何問題。
在準備之後已重新整理入口網站。 遇到重新開機,且認可或中止不再顯示。
- 入口網站會在本機儲存移轉資訊,因此在重新整理之後,即使雲端服務處於準備階段,也會從驗證階段開始。
- 您可以使用入口網站來再次進行驗證並準備步驟,以公開 [中止] 和 [認可] 按鈕。 這不會造成任何失敗。
- 客戶可以使用 PowerShell 或 REST API 來中止或認可。
作業需要多少時間?
驗證的設計目的是要快速。 準備的執行時間最長,且視要移轉的角色執行個體總數而定,會需要一些時間。 中止和認可也可能需要一些時間,但相較於準備,需要的時間較少。 所有作業會在 24 小時之後逾時。
下一步
如需將雲端服務 (傳統) 部署移轉至雲端服務 (延伸支援) 的協助,請參閱支援和疑難排解登陸頁面。