Preguntas frecuentes sobre Azure Blob Storage

Una vez configurada una directiva, puede tardar hasta 24 horas en entrar en vigor. Una vez que la directiva está en vigor, el tiempo necesario para que las acciones se ejecuten puede variar según el tamaño de la cuenta de almacenamiento y las operaciones realizadas.

La directiva actualizada tarda hasta 24 horas en entrar en vigor. Una vez que la directiva está en vigor, el tiempo necesario para que las acciones se ejecuten varían según el tamaño de la cuenta de almacenamiento y las operaciones que se realizan. Si la actualización va a deshabilitar o eliminar una regla y se ha usado enableAutoTierToHotFromCool, se seguirán haciendo niveles automáticos en el nivel de acceso de acceso frecuente. Por ejemplo, establezca una regla que incluya enableAutoTierToHotFromCool en función del último acceso. Si la regla está deshabilitada o eliminada y un blob se encuentra actualmente en estado de nivel de acceso esporádico y, después, se accede a él, volverá al nivel de acceso frecuente, que es el que se aplica en el acceso fuera de la administración del ciclo de vida. Luego, el blob no pasará de nivel de acceso frecuente a nivel de acceso esporádico, ya que la regla de administración del ciclo de vida está deshabilitada o eliminada. La única manera de evitar autoTierToHotFromCool es desactivar el seguimiento de la hora del último acceso.

En función del tamaño y el número de objetos que hay en una cuenta de almacenamiento, es posible que se necesite más de una ejecución para procesar todos los objetos. También puede comprobar los registros de recursos de almacenamiento para ver si la directiva de administración del ciclo de vida realiza las operaciones.

Compruebe si las características de protección de datos, como la eliminación temporal o el control de versiones, están habilitados en la cuenta de almacenamiento. Incluso si la directiva elimina los blobs, esos blobs podrían seguir existiendo en un estado de eliminación temporal o como una versión anterior en función de cómo se configuren estas características.

Si hay una directiva de administración del ciclo de vida en vigor para la cuenta de almacenamiento, la rehidratación de un blob cambiando su nivel puede dar lugar a un escenario en el que la directiva de ciclo de vida mueva el blob de nuevo al nivel de archivo. Esto puede ocurrir si la hora de la última modificación, la hora de creación o la hora de último acceso es posterior al umbral establecido para la directiva. Hay tres maneras de evitar que esto suceda:

• Agregue la condición daysAfterLastTierChangeGreaterThan a la acción tierToArchive de la directiva. Vea Uso de directivas de administración del ciclo de vida para archivar blobs.

• Deshabilite la regla que afecte temporalmente a este blob para impedir que se vuelva a archivar. Vuelva a habilitar la regla cuando el blob se pueda volver a mover con seguridad al nivel de archivo.

• Si el blob debe permanecer permanentemente en el nivel de acceso frecuente o esporádico, cópielo en otra ubicación donde la directiva de administración del ciclo de vida no esté en vigor.

El campo de coincidencia del prefijo del blob de una directiva es una ruta de acceso de blob completa o parcial, que se usa para comparar la coincidencia con los blobs a los que desea que se apliquen las acciones de la directiva. La ruta de acceso debe comenzar con el nombre del contenedor. Si no se especifica ninguna coincidencia de prefijo, la directiva se aplicará a todos los blobs de la cuenta de almacenamiento. El formato de la cadena de coincidencia del prefijo es [container name]/[blob name].
Tenga en cuenta los puntos siguientes sobre la cadena de coincidencia del prefijo:

• Una cadena de coincidencia del prefijo como container1/ se aplica a todos los blobs del contenedor denominado container1. Una cadena de coincidencia del prefijo como container1, sin el carácter de barra diagonal final (/), se aplica a todos los blobs de todos los contenedores en los que el nombre del contenedor comienza con la cadena container1. El prefijo coincidirá con los contenedores denominados container11, container1234, container1ab, etc.
• Una cadena de coincidencia del prefijo como container1/sub1/ se aplica a todos los blobs del contenedor denominado container1 que empiecen por la cadena sub1/. Por ejemplo, el prefijo coincidirá con blobs denominados container1/sub1/test.txt o container1/sub1/sub2/test.txt.
• El carácter de asterisco * es un carácter válido en un nombre de blob. Si el carácter de asterisco se usa en un prefijo, este coincidirá con blobs que tengan un asterisco en sus nombres. El asterisco no funciona como carácter comodín.
• El signo de interrogación ? es un carácter válido en un nombre de blob. Si el signo de interrogación se usa en un prefijo, este coincidirá con blobs que tengan un signo de interrogación en sus nombres. El signo de interrogación no funciona como carácter comodín.
• La coincidencia de prefijo solo tiene en cuenta comparaciones lógicas positivas (=). Las comparaciones lógicas negativas (!=) se ignoran.
• La coincidencia de prefijos funciona de forma que distingue mayúsculas de minúsculas.

Desafortunadamente, no hay forma de hacer un seguimiento del momento en el que se ejecutará la directiva, ya que es un proceso de programación en segundo plano. Pero la plataforma ejecutará la directiva una vez al día.

La regla de inventario diario está diseñada para ejecutarse una vez al día. Además, hay una regla de inventario semanal programada para cada domingo.

Aunque nos esforzamos por ofrecer una experiencia coherente, no podemos garantizar la hora exacta de ejecución de cada ejecución. La hora de ejecución de la regla de inventario puede variar. Por ejemplo, si la directiva de hoy está programada para las 12:05 a. m., podría iniciarse a las 12:07 a. m., 12:15 a. m., o cualquier otra hora del día siguiente.

El informe inventario de blobs genera tres tipos de archivos. Consulte Archivos de inventario. Los clientes existentes que usan el inventario de blobs pueden ver un cambio en el número de archivos de inventario, de un archivo a varios archivos. En la actualidad, ya tenemos un archivo de manifiesto que proporciona la lista de archivos. Este comportamiento permanece sin cambios, por lo que estos archivos se enumeran en el archivo de manifiesto.

El cambio se implementó para mejorar el rendimiento del inventario de blobs, especialmente para las cuentas de almacenamiento grandes que contienen más de cinco millones de objetos. Ahora, los resultados se escriben en paralelo en varios archivos, lo que elimina el cuello de botella de usar un único archivo de inventario. Este cambio se debe a los comentarios de los clientes, que señalaban dificultades para abrir y trabajar con el archivo de inventario único, excesivamente grande.

Como usuario, este cambio tiene un impacto positivo en su experiencia con ejecuciones de inventario de blobs. Se espera que mejore el rendimiento y reduzca el tiempo de ejecución general. Sin embargo, para beneficiarse plenamente de esta mejora, debe asegurarse de que su código está actualizado para procesar varios archivos de resultados en lugar de solo uno. Este ajuste alinea el código con el nuevo enfoque y optimiza el control de los datos de inventario.

No, los datos existentes no se ven afectados. Solo los resultados del inventario de blobs nuevos tienen varios archivos de inventario.

No, el cambio se produce sin problemas.

Las acciones necesarias dependen de cómo procese actualmente los resultados del inventario de blobs:

• Si el procesamiento actual supone un único archivo de resultados de inventario, debe modificar el código para dar cabida a varios archivos de resultados de inventario.

• Sin embargo, si el procesamiento actual implica leer la lista de archivos de resultados del archivo de manifiesto, no es necesario realizar ningún cambio en cómo procesar los resultados. El enfoque existente sigue funcionando sin problemas con la característica actualizada.

Esto no se recomienda, pero es posible. Trabaje con los canales de soporte técnico para pedir que desactive esta característica.

Trabaje con el equipo de cuenta actual y los canales de soporte técnico.

Este cambio iniciará el lanzamiento gradual a partir del 1 de septiembre de 2023.

No. Azure Compute admite las métricas en discos. Para obtener más información, consulte Métricas por disco para discos administrados y no administrados.

En algunos gráficos de métricas de Azure, como los que muestran datos de disponibilidad y latencia, se usa una línea discontinua para indicar que falta un valor (también conocido como valor NULL) entre dos puntos de datos del intervalo de tiempo conocidos. Por ejemplo, si en el selector de tiempo eligió 1 minute como granularidad de tiempo, pero la métrica se notificó a las 07:26, a las 07:27, a las 07:29 y a las 07:30, una línea discontinua conecta 07:27 y 07:29 porque falta un intervalo de un minuto entre esos dos puntos de datos. Los demás puntos de datos se conectan por una línea continua. La línea discontinua cae a cero cuando la métrica usa la agregación count y sum. Para las agregaciones avg, min o max, la línea discontinua conecta los dos puntos de datos conocidos más cercanos. Además, cuando faltan los datos en el lado más a la derecha o más a la izquierda del gráfico, la línea discontinua se expande hacia la dirección del punto de datos faltante.

Puede configurar una alerta de estado del recurso basada en el servicio Azure Resource Health para realizar un seguimiento de la disponibilidad de la cuenta de almacenamiento. Si no hay transacciones en la cuenta, la alerta informa en función del estado del clúster de almacenamiento donde se encuentra la cuenta de almacenamiento.

La capacidad del blob y la métrica de recuento de blobs se emiten cada hora. Un proceso en segundo plano calcula estas métricas y las actualiza varias veces al día.

Los registros de Analytics tienen registros de todas las operaciones de lectura, escritura, enumeración y eliminación con solicitudes correctas o con errores en todas las operaciones. Los registros de Analytics son la mejor solución pero no se garantiza ningún orden.

La fuente de cambios es una solución que proporciona un registro transaccional de mutaciones o cambios correctos en su cuenta como, por ejemplo, la creación, modificación y eliminación de blobs. La fuente de cambios garantiza que todos los eventos se registren y se muestren en el orden de cambios correctos por cada blob, por lo que no tiene que filtrar el ruido en caso de un volumen enorme de operaciones de lectura o solicitudes con errores. La fuente de cambios se ha diseñado y está optimizada fundamentalmente para el desarrollo de aplicaciones que requieren ciertas garantías.

Puede usar ambas características ya que fuente de cambios y los eventos de Blob Storage proporcionan la misma información con la misma garantía de fiabilidad, siendo la principal diferencia la latencia, el orden y el almacenamiento de los registros de eventos. La fuente de cambios publica entradas en el registro a los pocos minutos del cambio y también garantiza el orden de las operaciones de cambio por cada blob. Los eventos de Storage se insertan en tiempo real y es posible que no estén ordenados. Los eventos de fuente de cambios se almacenan de forma duradera dentro de la cuenta de almacenamiento como registros estables de solo lectura con su propia definición de retención, mientras que los eventos de Storage son transitorios y los consume el controlador de eventos a menos que los almacene explícitamente. Con la fuente de cambios, todas las aplicaciones pueden utilizar los registros a su conveniencia con las API o los SDK de blobs.

Sí. Se admiten reglas de seguridad de red de la cuenta de almacenamiento, como firewalls basados en IP y VNET, para el punto de conexión del sitio web estático, y se pueden usar para proteger el sitio web.

No. Un sitio web estático solo admite acceso de lectura público anónimo para los archivos del contenedor $web.

Puede configurar un dominio personalizado con un sitio web estático mediante Azure Content Delivery Network (Azure CDN). Azure CDN proporciona latencias bajas coherentes al sitio web desde cualquier lugar del mundo.

Puede configurar un certificado SSL personalizado con un sitio web estático mediante Azure CDN. Azure CDN proporciona latencias bajas coherentes al sitio web desde cualquier lugar del mundo.

Puede configurar el encabezado host para un sitio web estático mediante Azure CDN - Verizon Premium. Nos interesa conocer sus comentarios aquí.

Puede ocurrir un error 404 si hace referencia a un nombre de archivo con mayúsculas y minúsculas incorrectas. Por ejemplo, Index.html en lugar de index.html. Los nombres de archivo y las extensiones en la URL de un sitio web estático distinguen mayúsculas de minúsculas, aunque entreguen a través de HTTP. Esto también puede ocurrir si el punto de conexión de Azure CDN aún no está aprovisionado. Espere hasta 90 minutos después de aprovisionar una nueva red de Azure CDN para que se complete la propagación.

En Azure Portal, abra la página de configuración del sitio web estático de su cuenta y busque el nombre y la extensión que se establecieron en el campo Nombre del documento de índice. Asegúrese de que este nombre sea exactamente el mismo que el nombre del archivo ubicado en el contenedor $web de la cuenta de almacenamiento. Los nombres de archivo y las extensiones en la URL de un sitio web estático distinguen mayúsculas de minúsculas, aunque entreguen a través de HTTP.

No, si tiene que buscar dentro de los datos de blobs, use la aceleración de consultas o Azure Search.

Las etiquetas de índice de blobs solo admiten tipos de datos de cadena y las consultas devuelven resultados con ordenación lexicográfica. En el caso de los números, rellene el número con ceros. Para las fechas y horas, almacénelas como formato compatible con ISO 8601.

No, las etiquetas de Resource Manager ayudan a organizar los recursos del plano de control, como suscripciones, grupos de recursos y cuentas de almacenamiento. Las etiquetas de índice permiten la administración y detección de blobs en el plano de datos.

La capacidad de almacenamiento para Blob Storage se factura en unidades de la cantidad media diaria de datos almacenados, en gigabytes (GB), durante un periodo mensual. Por ejemplo, si ha utilizado de forma constante 10 GB de almacenamiento durante la primera mitad del mes y nada durante la segunda mitad, se le facturará un uso medio de 5 GB de almacenamiento.

Pasos siguientes

Para más información acerca de Azure Blob Storage, visite los vínculos siguientes:

• Introducción a Almacenamiento de Azure
• Qué es Azure Blob Storage