Häufig gestellte Fragen zu Azure Cloud Services (erweiterter Support)

• Cloud Services (klassisch): microsoft.classiccompute/domainnames
• Cloud Services (erweiterter Support): microsoft.compute/cloudservices

Cloud Services (erweiterter Support) ist in allen Regionen mit öffentlichen Clouds und Sovereign Clouds verfügbar.

Kunden müssen das Kontingent mit denselben Prozessen wie bei jedem anderen Azure Resource Manager-Produkt anfordern. Das Kontingent in Azure Resource Manager ist regional, und für jede Region wird eine separate Kontingentanforderung benötigt.

Cloud Services (erweiterter Support) unterstützt nicht das logische Konzept eines gehosteten Diensts, der zwei Slots enthält (Produktion und Staging). Jede Bereitstellung ist eine unabhängige Bereitstellung des Clouddiensts (erweiterter Support). Um eine neue Version eines Clouddiensts zu testen und zu stagen, stellen Sie einen Clouddienst (erweiterter Support) bereit und geben dafür an, dass der VIP-Austausch mit einem anderen Clouddienst vom Typ „Erweiterter Support“ möglich ist.

Das Konzept der gehosteten Dienstnamen ist nicht mehr vorhanden, Sie können keinen leeren Clouddienst (erweiterter Support) erstellen.

Nein, Cloud Services (erweiterter Support) unterstützt Resource Health Check (RHC) nicht.

Es gibt keine Änderungen bei den Rolleninstanzmetriken.

Es werden keine Änderungen am Entwurf, an der Architektur oder den Komponenten von Web- und Workerrollen vorgenommen.

Wenn annähernd zeitgleich mehrere Skalierungsaufrufe für denselben Clouddienst (für verschiedene Rollen) erfolgen, werden die Microsoft Platform-Komponenten aufgrund einer Racebedingung nicht mehr synchronisiert, was zu Fehlern führt. Microsoft arbeitet aktiv an der Behebung dieses Problems. Die für die Zwischenzeit vorgeschlagene Übergangslösung besteht nicht darin, alle Rollen gleichzeitig automatisch zu skalieren.

Es gibt keine Änderungen am Entwurf, an der Architektur oder den Komponenten der Rolleninstanzen.

Es gibt keine Änderungen bei der Rolloutmethode. Cloud Services (klassisch) und Cloud Services (erweiterter Support) erhalten dieselben Updates.

Die Bereitstellung von Cloud Services (erweiterter Support) unterstützt nur den Status „Stopped- Allocated“, der im Azure-Portal als „beendet“ angezeigt wird. Der Status „Stopped- Deallocated“ wird nicht unterstützt.

Bereitstellungen von Cloud Services (erweiterter Support) können nicht über mehrere Cluster, Verfügbarkeitszonen und Regionen hinweg skaliert werden.

Auf die Bereitstellungs-ID, auch bekannt als private ID, kann über die CloudServiceInstanceView-API zugegriffen werden. Sie ist auch auf dem Azure-Portal auf dem Blatt „Rollen und Instanzen“ des Clouddienstes (erweiterter Support) verfügbar

Cloud Services (erweiterter Support) verwendet Azure Key Vault und öffentliche Basic-IP-Adressen (Azure Resource Manager). Kund*innen, die Zertifikate benötigen, müssen Azure Key Vault für die Zertifikatverwaltung verwenden (weitere Informationen zu Azure Key Vault-Preisen). Jede öffentliche IP-Adresse für Cloud Services (erweiterter Support) wird separat abgerechnet (weitere Informationen zu Preisen für öffentliche IP-Adressen).

Ein Fehler bei der Bandbreitenabrechnung wurde im November 2022 behoben, was dazu führte, dass Kunden möglicherweise eine erhöhte Abrechnung basierend auf ihrer ausgehenden Datenübertragung in andere Regionen oder ins Internet sehen. Weitere Informationen finden Sie auf der Azure-Bandbreitenpreisseite.

Die Vereinbarung zum Servicelevel (Service Level Agreement, SLA) für Cloud Services (erweiterter Support) ist identisch mit SLA für Cloud Services (klassisch). Weitere Informationen finden Sie unter Lizenzierungsdokumente.

Lastenausgleichsinstanzen, Netzwerksicherheitsgruppen und Routingtabellen müssen sich in der gleichen Region und Ressourcengruppe befinden.

Key Vault, das virtuelle Netzwerk, öffentliche IP-Adressen, Netzwerksicherheitsgruppen und Routingtabellen müssen sich in der gleichen Region befinden.

Öffentliche IP-Adressen, Lastenausgleichsinstanzen, Netzwerksicherheitsgruppen und Routingtabellen müssen sich im gleichen virtuellen Netzwerk befinden.

Vorlagen- und Parameterdateien können mithilfe von REST, PowerShell und der CLI als Parameter übergeben werden. Sie können auch über das Azure-Portal hochgeladen werden.

Vorlagen- und Parameterdateien werden nur für die Bereitstellungsautomatisierung verwendet. Wie in Cloud Services (klassisch) können Sie zunächst manuell abhängige Ressourcen und dann eine Bereitstellung von Cloud Services (erweiterter Support) mithilfe von PowerShell, CLI-Befehlen oder über das Portal mit vorhandenen CSDEF- und CSCFG-Dateien erstellen.

Für den in einer CSPKG-Datei enthaltenen Anwendungscode sind keine Änderungen erforderlich. Ihre vorhandenen Anwendungen funktionieren weiterhin wie zuvor.

Das CTP-Paketformat wird in Cloud Services (erweiterter Support) nicht unterstützt. Die Paketgrößenbeschränkung wurde aber auf 800 MB erweitert.

CSES bietet keinen Support für die verwaltete Identität. Das Speicherkonto erlaubt es CSES also standardmäßig nicht, auf die Paketdateien zuzugreifen, wenn das Speicherkonto in der Einstellung nur für ein ausgewähltes virtuelles Netzwerk aktiviert ist.

Nein, Bereitstellungen von Cloud Services (erweiterter Support) sind wie Cloud Services (klassisch) an einen Cluster gebunden. Daher gibt es weiterhin Zuteilungsfehler, wenn der Cluster voll ist.

Das Einschätzen der erforderlichen Zeit und der Komplexität der Migration hängt von mehreren Variablen ab. Planung ist der effektivste Schritt, um den Umfang der Arbeiten, mögliche Hindernisse und die Komplexität der Migration zu verstehen.

Virtuelle Netzwerke sind eine erforderliche Ressource für jede Bereitstellung unter Azure Resource Manager. Die Bereitstellung von Cloud Services (erweiterter Support) muss sich in einem virtuellen Netzwerk befinden.

In Azure Resource Manager werden Komponenten Ihrer Bereitstellung von Cloud Services (erweiterter Support) als Ressource zur besseren Sichtbarkeit und optimierten Kontrolle zur Verfügung gestellt. Der gleiche Typ von Ressourcen wurde in Cloud Services (klassisch) verwendet, diese Ressourcen waren jedoch ausgeblendet. Ein Beispiel für eine solche Ressource ist die öffentliche Load Balancer, bei der es sich nun um eine explizite „schreibgeschützte“ Ressource handelt, die automatisch von der Plattform erstellt wird.

Ein Subnetz mit Bereitstellungen von Cloud Services (erweiterter Support) kann nicht für Bereitstellungen aus anderen Compute-Produkten wie Virtual Machines, Virtual Machines-Skalierungsgruppen, Service Fabric usw. freigegeben werden.

Cloud Services (erweiterter Support) unterstützt dynamische und statische IP-Zuordnungsmethoden. Auf statische IP-Adressen wird in der CSCFG-Datei als reservierte IP-Adressen verwiesen.

Die Nutzung von IP-Adressen für Cloud Services (erweiterter Support) wird Kunden in Rechnung gestellt, genauso wie Benutzern IP-Adressen für virtuelle Computer in Rechnung gestellt werden.

Eine reservierte IP-Adresse kann während dem Update oder Upgrade der Bereitstellung nicht hinzugefügt, entfernt oder geändert werden. Wenn die IP-Adressen geändert werden müssen, verwenden Sie bitte einen austauschbaren Clouddienst, oder stellen Sie zwei Cloud Services mit einem CName in Azure DNS\Traffic Manager bereit, damit die IP-Adresse auf beide der Dienste verweisen kann.

Ja. Cloud Services (erweiterter Support) kann auch ein DNS-Name zugewiesen werden. Bei Azure Resource Manager ist die DNS-Bezeichnung eine optionale Eigenschaft der öffentlichen IP-Adresse, die dem Clouddienst zugewiesen wird. Das Format des DNS-Namens für auf Azure Resource Manager basierende Bereitstellungen ist <userlabel>.<region>.cloudapp.azure.com.

Nein Der Verweis auf ein virtuelles Netzwerk ist bei der Erstellung eines Clouddienstes obligatorisch. Für eine vorhandene Cloud Services-Instanz kann der Verweis auf ein virtuelles Netzwerk nicht geändert werden. Der Adressbereich des virtuellen Netzwerks selbst kann mithilfe von VNet-APIs geändert werden.

Cloud Services (erweiterter Support) hat den gleichen Prozess wie andere Compute-Angebote übernommen, bei denen sich die Zertifikate in vom Kunden verwalteten Key Vaults befinden. Dieser Prozess gibt den Kunden die vollständige Kontrolle über Ihre Geheimnisse und Zertifikate.

Nein Key Vault ist eine regionale Ressource, und Kunden benötigen einen Key Vault in jeder Region. Allerdings kann ein Key Vault für alle Bereitstellungen innerhalb einer bestimmten Region verwendet werden.

Ja. Abonnementübergreifenden Verweise auf Schlüsseltresore in Cloud Services sind nicht zugelassen, um Angriffe zur Ausweitung von Privilegien über CS-ES zu verhindern. Das Abonnement ist keine Grenze, die CS-ES für Verweise auf Geheimnisse überschreitet. Der Grund, warum abonnementübergreifende Verweise nicht zugelassen sind, ist ein wichtiger letzter Schritt, um zu verhindern, dass böswillige Benutzer CS-ES als Mechanismus zur Rechteausweitung verwenden, um auf Geheimnisse anderer Benutzer zuzugreifen. Ein Abonnement ist keine Sicherheitsgrenze, aber tiefgehende Verteidigung ist eine Anforderung. Sie können jedoch die Key Vault-Erweiterung verwenden, um abonnement- und regionsübergreifende Unterstützung für Ihre Zertifikate zu erhalten. Lesen Sie die Dokumentation hier

Ja. Der Grund, warum Regionsgrenzen erzwungen werden, besteht darin, zu verhindern, dass Benutzer Architekturen erstellen, die regionsübergreifende Abhängigkeiten aufweisen. Die regionale Isolation ist ein wichtiges Entwurfsprinzip von cloudbasierten Anwendungen. Sie können jedoch die Key Vault-Erweiterung verwenden, um abonnement- und regionsübergreifende Unterstützung für Ihre Zertifikate zu erhalten. Lesen Sie die Dokumentation hier

Wenn annähernd zeitgleich mehrere Skalierungsaufrufe für denselben Clouddienst (für verschiedene Rollen) erfolgen, werden die Microsoft Platform-Komponenten aufgrund einer Racebedingung nicht mehr synchronisiert, was zu Fehlern führt. Microsoft arbeitet aktiv an der Behebung dieses Problems. Die für die Zwischenzeit vorgeschlagene Übergangslösung besteht nicht darin, alle Rollen gleichzeitig automatisch zu skalieren.

Dieses Szenario wird über Visual Studio nicht unterstützt. Bereitstellen über PowerShell oder das Portal.

Nächste Schritte

Weitere Informationen zum Einstieg in Cloud Services (erweiterter Support) finden Sie unter Bereitstellen einer Cloud Services-Instanz (erweiterter Support) mithilfe von PowerShell.