En este artículo se tratan las preguntas frecuentes relacionadas con Azure Cloud Services (soporte extendido).
General
¿Cuál es el nombre del recurso de Cloud Services (clásico) y Cloud Services (soporte extendido)?
- Cloud Services (clásico):
microsoft.classiccompute/domainnames - Cloud Services (soporte extendido):
microsoft.compute/cloudservices
¿Qué ubicaciones están disponibles para implementar Cloud Services (soporte extendido)?
Cloud Services (soporte extendido) está disponible en todas las regiones de la nube pública y soberana.
¿Cómo cambia mi cuota?
Los clientes deberán solicitar cuota mediante los mismos procesos que cualquier otro producto de Azure Resource Manager. La cuota en Azure Resource Manager es regional y se necesitará una solicitud de cuota independiente para cada región.
¿Por qué ya no aparece un espacio de ensayo y producción?
Cloud Services (soporte extendido) no admite el concepto lógico de un servicio hospedado, que incluía dos ranuras (Producción y ensayo). Cada implementación es una implementación de Cloud Services (soporte extendido) independiente. Para probar y ensayar una nueva versión de un servicio en la nube, implemente un servicio de Cloud Services (soporte extendido) y etiquételo como "con intercambio de VIP" con otro servicio de Cloud Services (soporte extendido)
¿Por qué ya no se pueden crear instancias vacías de Cloud Services?
El concepto de nombres de servicio hospedado ya no existe, no puede crear un servicio en la nube vacío (soporte extendido).
¿Admite Cloud Services (soporte extendido) Resource Health Check (RHC)?
No, Cloud Services (soporte extendido) no admite Resource Health Check (RHC).
¿Cómo cambian las métricas de las instancias de rol?
No hay cambios en las métricas de las instancias de rol.
¿Cómo cambian los roles web y de trabajo?
No hay ningún cambio en el diseño, la arquitectura o los componentes de los roles web y de trabajo.
El escalado de instancia de rol sigue fallando, ¿cómo se mitiga este problema?
Cuando se suceden varias llamadas a escala en el mismo servicio en la nube (para distintos roles) aproximadamente al mismo tiempo, debido a una condición de carrera, los componentes de la Plataforma Microsoft dejan de sincronizarse, lo que provoca errores. Microsoft está tratando de resolver este problema. La solución alternativa sugerida para el provisional es no escalar automáticamente todos los roles de manera simultánea.
¿Cómo cambian las instancias de rol?
No hay ningún cambio en el diseño, la arquitectura o los componentes de las instancias de rol.
¿Cómo cambiarán las actualizaciones del sistema operativo invitado?
No hay ningún cambio en el método de implementación. Cloud Services (clásico) y Cloud Services (soporte extendido) recibirán las mismas actualizaciones.
¿Cloud Services (soporte extendido) admite los estados detenido-asignado y detenido-desasignado?
La implementación de Cloud Services (soporte extendido) solo admite el estado detenido-asignado, que aparece como "detenido" en Azure Portal. Detenido: no se admite el estado desasignado.
¿Las implementaciones de Cloud Services (soporte extendido) admiten el escalado entre clústeres, zonas de disponibilidad y regiones?
Las implementaciones de Cloud Services (soporte extendido) no se pueden escalar entre varios clústeres, zonas de disponibilidad y regiones.
Cómo puedo obtener el identificador de implementación de mi servicio en la nube (soporte extendido)
Se puede acceder al identificador de implementación, también conocido como identificador privado, mediante la API CloudServiceInstanceView . También está disponible en Azure Portal en la hoja Rol e instancias de Cloud Services (soporte extendido).
¿Existen diferencias de precio entre Cloud Services (clásico) y Cloud Services (soporte extendido)?
Cloud Services (soporte extendido) utiliza direcciones IP públicas de Azure Key Vault y básicas (ARM). Los clientes que necesiten certificados deben usar Azure Key Vault para la administración de certificados (más información sobre los precios de Azure Key Vault). Cada dirección IP pública de Cloud Services (soporte extendido) se cobra por separado (más información sobre los precios de las direcciones IP públicas).
¿Por qué veo un cambio en el importe de facturación después de las implementaciones de noviembre de 2022 para Cloud Services (soporte extendido)?
Se corrigió un error en la facturación de ancho de banda en noviembre de 2022, lo que da lugar a que los clientes vean una mayor facturación en función de su transferencia de datos a otras regiones o a Internet. Para obtener más referencia, visite la página de precios de ancho de banda de Azure.
¿Cuál es el Acuerdo de Nivel de Servicio (SLA) para Cloud Services (soporte extendido)?
El Acuerdo de Nivel de Servicio (SLA) para Cloud Services (soporte extendido) es el mismo que el Acuerdo de Nivel de Servicio para Cloud Services (clásico). Consulte Documentos de licencia.
Recursos
¿Qué recursos vinculados a una implementación de Cloud Services (soporte extendido) deben residir en el mismo grupo de recursos?
Los equilibradores de carga, los grupos de seguridad de red y las tablas de rutas deben residir en la misma región y en el mismo grupo de recursos.
¿Qué recursos vinculados a una implementación de Cloud Services (soporte extendido) deben residir en la misma región?
Key Vault, la red virtual, las direcciones IP públicas, los grupos de seguridad de red y las tablas de rutas deben residir en la misma región.
¿Qué recursos vinculados a una implementación de Cloud Services (soporte extendido) deben residir en la misma red virtual?
Las direcciones IP públicas, los equilibradores de carga, los grupos de seguridad de red y las tablas de rutas deben residir en la misma red virtual.
Archivos de implementación
¿Cómo puedo usar una plantilla para implementar o administrar mi implementación?
Los archivos de plantilla y de parámetro se pueden pasar como parámetro mediante REST, PowerShell y la CLI. También se pueden cargar mediante Azure Portal.
¿Es necesario mantener cuatro archivos ahora? (template, parameter, csdef, cscfg)
Los archivos de plantilla y de parámetro solo se usan para la automatización de la implementación. Al igual que con Cloud Services (clásico), puede crear manualmente recursos dependientes en primer lugar y después una implementación de Cloud Services (soporte extendido) con PowerShell, comandos de la CLI o mediante el portal con los archivos csdef y cscfg existentes.
¿Cómo cambia mi código de aplicación en Cloud Services (soporte extendido)
No se requieren cambios en el código de aplicación empaquetado en cspkg. Las aplicaciones existentes seguirán funcionando como de costumbre.
¿Permite Cloud Services (soporte extendido) el formato de paquete CTP?
El formato de paquete CTP no se admite en Cloud Services (soporte extendido). Sin embargo, permite un límite de tamaño de paquete mejorado, de 800 MB.
CSES requiere que sus archivos de paquete se almacenen en una cuenta de almacenamiento. ¿Se puede establecer la cuenta de almacenamiento como "habilitar el acceso desde redes virtuales seleccionadas"
CSES no admite la compatibilidad con identidades administradas. Por lo tanto, la cuenta de almacenamiento por diseño no permite que CSES acceda a los archivos de paquete cuando la cuenta de almacenamiento solo está habilitada en la configuración.
Migración
¿Cloud Services (soporte extendido) puede mitigar los errores de asignación?
No, las implementaciones de Cloud Services (soporte extendido) están vinculadas a un clúster, lo mismo que sucede con Cloud Services (clásico). Por lo tanto, los errores de asignación seguirán existiendo si el clúster está lleno.
¿Cuándo es necesario migrar?
La estimación del tiempo necesario y la complejidad de la migración depende de una serie de variables. La planificación es el paso más eficaz para comprender el ámbito del trabajo, los inhibidores y la complejidad de la migración.
Redes
¿Por qué no se puede crear una implementación sin una red virtual?
Las redes virtuales son un recurso necesario para cualquier implementación en Azure Resource Manager. La implementación de Cloud Services (soporte extendido) debe residir en una red virtual.
¿Por qué ahora me aparecen tantos recursos de red?
En Azure Resource Manager, los componentes de la implementación de Cloud Services (soporte extendido) se exponen como un recurso para mejorar la visibilidad y el control. En Cloud Services (clásico) se usaban recursos del mismo tipo, pero estaban ocultos. Un ejemplo de este tipo de recurso es Load Balancer público, que ahora es un recurso explícito de "solo lectura" creado automáticamente por la plataforma.
¿Qué restricciones se aplican a una subred con respecto a Cloud Services (soporte extendido)?
Una subred que contenga implementaciones de Cloud Services (soporte extendido) no se puede compartir con implementaciones de otros productos de proceso como Virtual Machines, Virtual Machines Scale Sets, Service Fabric, etc.
¿Qué métodos de asignación de IP se admiten en Cloud Services (soporte extendido)?
Cloud Services (soporte extendido) es compatible con los métodos de asignación de IP estática y dinámica. En el archivo cscfg se hace referencia a las direcciones IP estáticas como direcciones IP reservadas.
¿Por qué me cobran las direcciones IP?
A los clientes se les factura el uso de la dirección IP en Cloud Services (soporte extendido) del mismo modo que se factura a los usuarios las direcciones IP asociadas a las máquinas virtuales.
¿Se puede actualizar la dirección IP reservada después de una implementación correcta?
No se puede agregar, quitar ni cambiar una dirección IP reservada durante la actualización o actualización de la implementación. Si es necesario cambiar las direcciones IP, use un servicio en la nube intercambiable o implemente dos servicios en la nube con un CName en Azure DNS\Traffic Manager para que la dirección IP pueda apuntar a cualquiera de ellas.
¿Puedo usar un nombre DNS con Cloud Services (soporte extendido)?
Sí. También se puede asignar un nombre DNS a Cloud Services (soporte extendido). Con Azure Resource Manager, la etiqueta DNS es una propiedad opcional de la dirección IP pública que se asigna al servicio en la nube. El formato del nombre DNS en las implementaciones basadas en Azure Resource Manager es <userlabel>.<region>.cloudapp.azure.com.
¿Puedo actualizar o cambiar la referencia de red virtual de una instancia existente de Cloud Services (soporte extendido)?
No. La referencia de red virtual es obligatoria durante la creación de un servicio en la nube. Para un servicio en la nube existente, no se puede cambiar la referencia de red virtual. El propio espacio de direcciones de red virtual se puede modificar mediante las API de red virtual.
Certificados y Key Vault
¿Por qué es necesario administrar mis certificados en Cloud Services (soporte extendido)?
Cloud Services (soporte extendido) ha adoptado el mismo proceso que otras ofertas de proceso en las que los certificados residen en los almacenes de claves administrados por el cliente. Esto permite a los clientes tener un control completo sobre sus secretos y certificados.
¿Puedo usar una instancia de Key Vault en todas las implementaciones en todas las regiones?
No. Key Vault es un recurso regional, así que los clientes necesitan una instancia de Key Vault en cada región. Sin embargo, se puede usar una instancia de Key Vault en todas las implementaciones realizadas dentro de una región determinada.
Al especificar los secretos o certificados que se instalarán en una instancia de Cloud Services, ¿debe el recurso de KeyVault estar en la misma suscripción de Azure que el recurso de Cloud Services?
Sí. No se permiten referencias entre almacenes de claves de suscripción en Cloud Services para protegerse contra la escalación de ataques de privilegios a través de CS-ES. La suscripción no es un límite que CS-ES cruzará para las referencias a secretos. La razón por la que no se permiten referencias entre suscripciones es como un paso final importante para evitar que usuarios malintencionados usen CS-ES como mecanismo de escalación de privilegios para acceder a los secretos de otros usuarios. La suscripción no es un límite de seguridad, pero la defensa en profundidad es un requisito. Sin embargo, puede usar la extensión de Key Vault para obtener compatibilidad entre suscripciones y regiones para los certificados. Consulte la documentación aquí.
Al especificar secretos o certificados que se instalarán en una instancia de Cloud Services, ¿debe el recurso de KeyVault estar en la misma región que el recurso de Cloud Services?
Sí. La razón por la que aplicamos límites de región es impedir que los usuarios creen arquitecturas que tengan dependencias entre regiones. El aislamiento regional es un principio de diseño clave de aplicaciones basadas en la nube. Sin embargo, puede usar la extensión de Key Vault para obtener compatibilidad entre suscripciones y regiones para los certificados. Consulte la documentación aquí.
Problemas conocidos
El escalado de instancia de rol sigue fallando, ¿cómo se mitiga este problema?
Cuando se suceden varias llamadas a escala en el mismo servicio en la nube (para distintos roles) aproximadamente al mismo tiempo, debido a una condición de carrera, los componentes de la Plataforma Microsoft dejan de sincronizarse, lo que provoca errores. Microsoft está tratando de resolver este problema. La solución alternativa sugerida para el provisional es no escalar automáticamente todos los roles de manera simultánea.
Visual Studio/Tools no admite la implementación de CS-ES cuando la red virtual se encuentra en un grupo de recursos diferente. ¿Cómo implementar?
Este escenario no se admite a través de Visual Studio. Implemente a través de PowerShell o Portal.
Pasos siguientes
Para empezar a usar Cloud Services (soporte extendido), consulte Implementación de una instancia de Cloud Services (soporte extendido) mediante PowerShell.