Teknisk information om migrering till Azure Cloud Services (extended-support)
I den här artikeln beskrivs teknisk information om migreringsverktyget som rör Cloud Services (klassisk).
Information om funktioner/scenarier som stöds för migrering
Migrering av tillägg och plugin-program
- Alla aktiverade och tillägg som stöds migreras.
- Inaktiverade tillägg migreras inte.
- Plugin-program är ett äldre begrepp och bör tas bort före migreringen. De stöds för migrering, men efter migreringen måste plugin-programmet tas bort först innan tillägget installeras om tillägget behöver aktiveras. Plugin-program och tillägg för fjärrskrivbord påverkas mest av detta.
Certifikatmigrering
- I Cloud Services (utökat stöd) lagras certifikat i ett Key Vault. Som en del av migreringen skapar vi ett Nyckelvalv för de kunder som har namnet på molntjänsten och överför alla certifikat från Azure Service Manager till Key Vault.
- Referensen till det här Nyckelvalvet anges i mallen eller skickas via PowerShell eller Azure CLI.
Tjänstkonfigurations- och tjänstdefinitionsfiler
- .cscfg- och .csdef-filerna måste uppdateras för Cloud Services (utökad support) med mindre ändringar.
- Namnen på resurser som virtuellt nätverk och VM SKU skiljer sig. Se Översättning av resurser och namngivningskonvention efter migrering
- Kunder kan hämta sina nya distributioner via PowerShell och REST API.
Molntjänst och distributioner
- Varje distribution av Cloud Services (utökad support) är en oberoende molntjänst. Distributionen grupperas inte längre i en molntjänst med hjälp av fack.
- Om du har två platser i molntjänsten (klassisk) måste du ta bort en plats (mellanlagring) och använda migreringsverktyget för att flytta den andra platsen (produktion) till Azure Resource Manager.
- Den offentliga IP-adressen för cloud service-distributionen förblir densamma efter migreringen till Azure Resource Manager och exponeras som en grundläggande SKU IP-resurs (dynamisk eller statisk).
- DNS-namnet och domänen (cloudapp.net) för den migrerade molntjänsten förblir desamma.
Migrering av virtuellt nätverk
- Om en Cloud Services-distribution finns i ett virtuellt nätverk migreras alla molntjänster och associerade virtuella nätverksresurser under migreringen tillsammans.
- Efter migreringen placeras det virtuella nätverket i en annan resursgrupp än molntjänsten.
- För virtuella nätverk med flera Molntjänster migreras varje molntjänst en efter en.
Migrering av distributioner som inte finns i ett virtuellt nätverk
- I slutet av 2018 började Azure automatiskt skapa nya distributioner (utan kundens angivna virtuella nätverk) till en plattform som skapats som "standard" virtuellt nätverk. Dessa virtuella standardnätverk är dolda för kunder.
- Som en del av migreringen exponeras det här virtuella standardnätverket för kunder en gång i Azure Resource Manager. För att hantera eller uppdatera distributionen i Azure Resource Manager måste kunderna lägga till den här informationen för virtuella nätverk i avsnittet NetworkConfiguration i .cscfg-filen.
- Det virtuella standardnätverket, när det migreras till Azure Resource Manager, placeras i samma resursgrupp som molntjänsten.
- Cloud Services som skapats före den här tiden (före slutet av 2018) finns inte i något virtuellt nätverk och kan inte migreras med verktyget. Överväg att omdistribuera dessa molntjänster direkt i Azure Resource Manager. En annan metod är att migrera via att skapa en ny mellanlagringsdistribution och VIPSwap Kontrollera mer information här
- Om du vill kontrollera om en distribution är berättigad att migrera kör du validerings-API:et i distributionen. Resultatet av Validerings-API:et innehåller ett felmeddelande som uttryckligen anger om den här distributionen är berättigad att migrera.
Load Balancer
- För en molntjänst som använder en offentlig slutpunkt exponeras en plattform skapad lastbalanserare som är associerad med molntjänsten i kundens prenumeration i Azure Resource Manager. Lastbalanseraren är en skrivskyddad resurs och uppdateringar begränsas endast via filerna Service Configuration (.cscfg) och Service Definition (.csdef).
Key Vault
- Som en del av migreringen skapar Azure automatiskt ett nytt Key Vault och migrerar alla certifikat till det. Med verktyget kan du inte använda ett befintligt Nyckelvalv.
- Cloud Services (utökad support) kräver ett Nyckelvalv som finns i samma region och prenumeration. Det här Key Vault skapas automatiskt som en del av migreringen.
Resurser och funktioner är inte tillgängliga för migrering
Det här är de främsta scenarierna som omfattar kombinationer av resurser, funktioner och Molntjänster. Den här listan är inte fullständig.
| Resurs | Nästa steg/work-around |
|---|---|
| Regler för automatisk skalning | Migreringen går igenom men reglerna tas bort. Återskapa reglerna efter migreringen på Cloud Services (utökad support). |
| Aviseringar | Migreringen går igenom men aviseringar tas bort. Återskapa reglerna efter migreringen på Cloud Services (utökad support). |
| VPN Gateway | Ta bort VPN Gateway innan du påbörjar migreringen och återskapa sedan VPN Gateway när migreringen är klar. |
| Express Route Gateway (i samma prenumeration som endast virtuellt nätverk) | Ta bort Express Route Gateway innan du påbörjar migreringen och återskapa sedan gatewayen när migreringen är klar. |
| Säljbudget | Kvoten migreras inte. Begär ny kvot i Azure Resource Manager före migreringen för att verifieringen ska lyckas. |
| Tillhörighetsgrupper | Stöds ej. Ta bort eventuella tillhörighetsgrupper före migreringen. |
| Virtuella nätverk med peering för virtuella nätverk | Innan du migrerar ett virtuellt nätverk som är peer-kopplat till ett annat virtuellt nätverk tar du bort peering, migrerar det virtuella nätverket till Resource Manager och skapar peering igen. Detta kan orsaka stilleståndstid beroende på arkitekturen. |
| Virtuella nätverk som innehåller App Service-miljöer | Stöds inte |
| Virtuella nätverk med Azure Batch-distributioner | Stöds inte |
| Virtuella nätverk som innehåller HDInsight-tjänster | Stöds ej. |
| Virtuella nätverk som innehåller Azure API Management-distributioner | Stöds ej. Om du vill migrera det virtuella nätverket ändrar du det virtuella nätverket för API Management-distributionen. Det här är en driftstoppsåtgärd. |
| Klassiska Express Route-kretsar | Stöds ej. Dessa kretsar måste migreras till Azure Resource Manager innan PaaS-migreringen påbörjas. Mer information finns i Flytta ExpressRoute-kretsar från den klassiska till Resource Manager-distributionsmodellen. |
| Rollbaserad åtkomstkontroll | Efter migreringen måste URI:n för resursen ändras från Microsoft.ClassicCompute till Microsoft.Compute RBAC-principer uppdateras efter migreringen. |
| Application Gateway | Stöds inte. Ta bort Application Gateway innan du påbörjar migreringen och återskapa sedan Application Gateway när migreringen har slutförts till Azure Resource Manager |
Konfigurationer/migreringsscenarier som inte stöds
| Konfiguration/scenario | Nästa steg/work-around |
|---|---|
| Migrering av vissa äldre distributioner som inte finns i ett virtuellt nätverk | Vissa molntjänstdistributioner som inte finns i ett virtuellt nätverk stöds inte för migrering. 1. Använd validerings-API:et för att kontrollera om distributionen är berättigad att migrera. 2. Om de är berättigade flyttas distributionerna till Azure Resource Manager under ett virtuellt nätverk med prefixet "DefaultRdfeVnet" |
| Migrering av distributioner som innehåller distribution av både produktions- och mellanlagringsfack med hjälp av dynamiska IP-adresser | Migrering av en molntjänst med två fack kräver borttagning av mellanlagringsplatsen. När mellanlagringsplatsen har tagits bort migrerar du produktionsplatsen som en oberoende molntjänst (utökad support) i Azure Resource Manager. Distribuera sedan om mellanlagringsmiljön som en ny molntjänst (utökad support) och gör den utbytbar med den första. |
| Migrering av distributioner som innehåller distribution av både produktions- och mellanlagringsfack med hjälp av reserverade IP-adresser | Stöds ej. |
| Migrering av produktions- och mellanlagringsdistribution i olika virtuella nätverk | Migrering av en molntjänst med två fack kräver att mellanlagringsplatsen tas bort. När mellanlagringsplatsen har tagits bort migrerar du produktionsplatsen som en oberoende molntjänst (utökad support) i Azure Resource Manager. En ny Distribution av Cloud Services (utökad support) kan sedan länkas till den migrerade distributionen med växlad egenskap aktiverad. Distributionsfiler för den gamla distributionen av mellanlagringsplatsen kan återanvändas för att skapa den nya utbytbara distributionen. |
| Migrering av tom molntjänst (molntjänst utan distribution) | Stöds ej. |
| Migrering av distribution som innehåller plugin-programmet för fjärrskrivbord och tillägg för fjärrskrivbord | Alternativ 1: Ta bort plugin-programmet för fjärrskrivbord före migreringen. Detta kräver ändringar i distributionsfiler. Migreringen går sedan igenom. Alternativ 2: Ta bort fjärrskrivbordstillägget och migrera distributionen. Ta bort plugin-programmet efter migreringen och installera tillägget. Detta kräver ändringar i distributionsfiler. Ta bort plugin-programmet och tillägget före migreringen. Plugin-program rekommenderas inte för användning i Cloud Services (utökad support). |
| Virtuella nätverk med både PaaS- och IaaS-distribution | Stöds inte Flytta antingen PaaS- eller IaaS-distributionerna till ett annat virtuellt nätverk. Detta orsakar stilleståndstid. |
| Molntjänstdistributioner med äldre rollstorlekar (till exempel Small eller ExtraLarge). | Rollstorlekarna måste uppdateras före migreringen. Uppdatera alla distributionsartefakter för att referera till dessa nya moderna rollstorlekar. Mer information finns i Tillgängliga VM-storlekar |
| Migrering av molntjänsten till olika virtuella nätverk | Stöds inte 1. Flytta distributionen till ett annat klassiskt virtuellt nätverk före migreringen. Detta orsakar stilleståndstid. 2. Migrera det nya virtuella nätverket till Azure Resource Manager. Eller 1. Migrera det virtuella nätverket till Azure Resource Manager 2. Flytta molntjänsten till ett nytt virtuellt nätverk. Detta orsakar stilleståndstid. |
| Molntjänst i ett virtuellt nätverk men har inget explicit undernät tilldelat | Stöds ej. Åtgärd innebär att du flyttar rollen till ett undernät, vilket kräver en omstart av rollen (stilleståndstid) |
Översättning av resurser och namngivningskonvention efter migrering
Som en del av migreringen ändras resursnamnen och få Cloud Services-funktioner exponeras som Azure Resource Manager-resurser. Tabellen sammanfattar de ändringar som är specifika för Cloud Services-migrering.
| Cloud Services (klassisk) Resursnamn |
Cloud Services (klassisk) Syntax |
Cloud Services (utökad support) Resursnamn |
Cloud Services (utökad support) Syntax |
|---|---|---|---|
| Molntjänst | cloudservicename |
Inte associerad | Inte associerad |
| Distribution (portalen har skapats) Distribution (inte portalen har skapats) |
deploymentname |
Cloud Services (utökad support) | cloudservicename |
| Virtual Network | vnetname Group resourcegroupname vnetname Inte associerad |
Virtuellt nätverk (inte portalen har skapats) Virtuellt nätverk (portalen har skapats) Virtuella nätverk (standard) |
vnetname group-resourcegroupname-vnetname VNet-cloudservicename |
| Inte associerad | Inte associerad | Key Vault | KV-cloudservicename |
| Inte associerad | Inte associerad | Resursgrupp för molntjänstdistributioner | cloudservicename-migrated |
| Inte associerad | Inte associerad | Resursgrupp för virtuellt nätverk | vnetname-migrated group-resourcegroupname-vnetname-migrated |
| Inte associerad | Inte associerad | Offentlig IP-adress (dynamisk) | cloudservicenameContractContract |
| Reserverat IP-namn | reservedipname |
Reserverad IP -adress (skapas inte i portalen) Reserverad IP-adress (portalen har skapats) |
reservedipname group-resourcegroupname-reservedipname |
| Inte associerad | Inte associerad | Load Balancer | LB-cloudservicename |
Migreringsproblem och hur du hanterar dem.
Migreringen har fastnat i en åtgärd under en längre tid.
- Det kan ta lång tid att checka in, förbereda och avbryta beroende på antalet distributioner. Tidsgränsen för åtgärder kommer att överskridas efter 24 timmar.
- Inchecknings-, förberedelse- och abortåtgärder är idempotent. De flesta problem kan åtgärdas genom att försöka igen. Det kan finnas tillfälliga fel som kan försvinna om några minuter. Vi rekommenderar att du försöker igen efter en lucka. Om du migrerar med Hjälp av Azure-portalen och åtgärden har fastnat i ett "pågående tillstånd" använder du PowerShell för att försöka utföra åtgärden igen.
- Kontakta supporten för att migrera eller återställa distributionen från serverdelen.
Migreringen misslyckades i en åtgärd.
- Om verifieringen misslyckades beror det på att distributionen eller det virtuella nätverket innehåller ett scenario/en funktion/resurs som inte stöds. Använd listan över scenarier som inte stöds för att hitta work-around i dokumenten.
- Förbered åtgärden utför först validering, inklusive vissa dyra valideringar (omfattas inte av verifieringen). Förberedelsefelet kan bero på ett scenario som inte stöds. Hitta scenariot och arbetet i de offentliga dokumenten. Avbryt måste anropas för att gå tillbaka till det ursprungliga tillståndet och låsa upp distributionen för uppdateringar och borttagningsåtgärder.
- Om avbrottet misslyckades försöker du utföra åtgärden igen. Kontakta supporten om försöken misslyckas.
- Om incheckningen misslyckades försöker du utföra åtgärden igen. Kontakta supporten om det inte går att försöka igen. Även vid incheckningsfel bör det inte finnas något problem med dataplanet i distributionen. Distributionen bör kunna hantera kundtrafik utan problem.
Portalen har uppdaterats efter Förbered. Upplevelsen har startats om och Incheckning eller Avbryt visas inte längre.
- Portalen lagrar migreringsinformationen lokalt och därför startar den efter uppdateringen från valideringsfasen även om molntjänsten är i förberedelsefasen.
- Du kan använda portalen för att gå igenom verifieringen och förbereda stegen igen för att exponera knappen Avbryt och Checka in. Det orsakar inga fel.
- Kunder kan använda PowerShell eller REST API för att avbryta eller checka in.
Hur lång tid kan åtgärderna ta?
Validering är utformat för att gå snabbt. Förbered körs längst och tar lite tid beroende på det totala antalet rollinstanser som migreras. Det kan också ta tid att avbryta och checka in, men det tar mindre tid än att förbereda. Alla åtgärder överskrider tidsgränsen efter 24 timmar.
Nästa steg
Mer information om hur du migrerar din Cloud Services-distribution (klassisk) till Cloud Services (utökad support) finns på vår startsida för support och felsökning .