Perguntas frequentes sobre o Armazenamento de Blobs do Azure

A plataforma executa a política de ciclo de vida uma vez por dia. Após configurar uma política, ela pode levar até 24 horas para entrar em vigor. Depois que a política estiver em vigor, o tempo necessário para a execução das ações poderá variar dependendo do tamanho da conta de armazenamento e das operações executadas.

A política atualizada leva até 24 horas para entrar em vigor. Depois que a política estiver em vigor, o tempo necessário para que as ações sejam executadas variará dependendo do tamanho da conta de armazenamento e das operações executadas. Se a atualização for desabilitar ou excluir uma regra e enableAutoTierToHotFromCool tiver sido usado, a disposição automática em camadas para a camada de acesso frequente continuará ocorrendo. Por exemplo, definir uma regra incluindo enableAutoTierToHotFromCool com base no último acesso. Se a regra for desabilitada ou excluída e um blob estiver atualmente em camada de acesso esporádico ou frio e for acessado, ele retornará para a camada de acesso frequente, pois essa regra se aplica ao acesso fora do gerenciamento do ciclo de vida. O blob não passará de quente para frio ou frio, pois a regra de gerenciamento do ciclo de vida está desabilitada ou foi excluída. A única maneira de impedir autoTierToHotFromCool é desativando o acompanhamento de último acesso.

Dependendo do tamanho e do número de objetos que estão em uma conta de armazenamento, mais de uma execução pode ser necessária para processar todos os objetos. Você também pode verificar os logs dos recursos de armazenamento para ver se as operações estão sendo realizadas pela política de gerenciamento de ciclo de vida.

Verifique se os recursos de proteção de dados, tais como exclusão temporária ou controle de versão, estão ativados na conta de armazenamento. Mesmo que a política esteja excluindo os blobs, esses blobs ainda podem existir em um estado de exclusão temporária ou como uma versão mais antiga, dependendo de como esses recursos são configurados.

Se houver uma política de gerenciamento do ciclo de vida em vigor para a conta de armazenamento, reidratar um blob mudando a camada dele poderá resultar em um cenário em que a política de ciclo de vida move o blob de volta para a camada de arquivos. Isso pode acontecer se a hora da última modificação, a hora de criação ou a hora do último acesso estiver além do limite definido para a política. Há três maneiras de evitar que isso aconteça:

• Adicione a condição daysAfterLastTierChangeGreaterThan à ação tierToArchive da política. Essa condição se aplica somente à hora da última modificação. Confira Usar políticas de gerenciamento do ciclo de vida para arquivar blobs.

• Desabilite a regra que afeta esse blob temporariamente para impedir que ele seja arquivado novamente. Habilite novamente a regra quando o blob puder ser movido com segurança de volta para a camada de armazenamento de arquivos.

• Se o blob precisar permanecer permanentemente na camada frequente, esporádica ou fria, copie-o para outro local em que a política de gerenciamento do ciclo de vida não esteja em vigor.

O campo de correspondência de prefixo blob de uma política é um caminho de blob completo ou parcial, que é usado para corresponder aos blobs nos quais você deseja que as ações de política sejam aplicadas. O caminho deve começar com o nome do contêiner. Se nenhuma correspondência de prefixo for especificada, a política será aplicada a todos os blobs na conta de armazenamento. O formato da cadeia de caracteres de correspondência de prefixo é [container name]/[blob name].
Tenha em mente os seguintes pontos sobre a cadeia de caracteres de correspondência de prefixo:

• Uma cadeia de caracteres de correspondência de prefixo, como container1/ aplica-se a todos os blobs no contêiner chamado container1. Uma cadeia de caracteres de correspondência de prefixo de container1, sem o caractere de barra à direita (/), aplica-se a todos os blobs em todos os contêineres em que o nome do contêiner começa com o contêiner de cadeia de caracteres1. O prefixo corresponderá a contêineres chamados container11, container1234, container1ab e assim por diante.
• Uma cadeia de caracteres de correspondência de prefixo de container1/sub1/ aplica-se a todos os blobs no contêiner nomeado container1 que começam com a cadeia de caracteres sub1/. Por exemplo, o prefixo corresponderá aos blobs nomeados como container1/sub1/test.txt ou container1/sub1/sub2/test.txt.
• O caractere asterisco * é um caractere válido em um nome de blob. Se o caractere de asterisco for usado em um prefixo, o prefixo corresponderá a blobs com um asterisco em seus nomes. O asterisco não funciona como um caractere curinga.
• O caractere de ponto de interrogação ? é um caractere válido em um nome de blob. Se o caractere de ponto de interrogação for usado em um prefixo, o prefixo corresponderá aos blobs com um ponto de interrogação em seus nomes. O ponto de interrogação não funciona como um caractere curinga.
• A correspondência de prefixo considera apenas comparações lógicas positivas (=). Comparações lógicas negativas (!=) são ignoradas.
• A correspondência de prefixo opera diferenciando maiúsculas de minúsculas.

Infelizmente, não há nenhuma maneira de acompanhar o momento em que a política será executada, pois é um processo de agendamento em segundo plano. No entanto, a plataforma executará a política uma vez por dia.

A regra de inventário diário foi projetada para ser executada uma vez por dia. Além disso, há uma regra de inventário semanal programada para todos os domingos.

Embora nos esforcemos para oferecer uma experiência consistente, não podemos garantir o horário exato de execução de cada execução. O tempo de execução da regra de inventário pode variar. Por exemplo, se a política de hoje estiver programada para as 00h05, ela poderá entrar em vigor às 00h07, 00h15 ou em qualquer outro horário do dia seguinte.

O relatório inventário de blobs produz três tipos de arquivos. Consulte Arquivos de inventário. Os clientes existentes que usam o inventário de blobs podem ver uma alteração no número de arquivos de inventário, de um arquivo para vários arquivos. Hoje, já temos um arquivo de manifesto que fornece a lista de arquivos. Esse comportamento permanece inalterado, portanto, esses arquivos são listados no arquivo de manifesto.

A alteração foi implementada para melhorar o desempenho do inventário de blobs, especialmente para grandes contas de armazenamento que contêm mais de cinco milhões de objetos. Agora, os resultados são gravados em paralelo a vários arquivos, eliminando o gargalo de usar um único arquivo de inventário. Essa alteração foi solicitada pelos comentários dos clientes, pois eles relataram dificuldades para abrir e trabalhar com o arquivo de inventário único excessivamente grande.

Como usuário, essa alteração tem um impacto positivo em sua experiência com execuções de inventário de blob. Espera-se que ele melhore o desempenho e reduza o tempo de execução geral. No entanto, para se beneficiar totalmente dessa melhoria, você deve garantir que seu código seja atualizado para processar vários arquivos de resultados em vez de apenas um. Esse ajuste alinha seu código com a nova abordagem e otimiza o tratamento de dados de inventário.

Não, os dados existentes não são afetados. Somente novos resultados de inventário de blobs têm vários arquivos de inventário.

Não, a alteração acontece perfeitamente.

Suas ações necessárias dependem de como você processa atualmente os resultados do inventário de blobs:

• Se o processamento atual pressupõe um único arquivo de resultados de inventário, você precisará modificar seu código para acomodar vários arquivos de resultados de inventário.

• No entanto, se o processamento atual envolver a leitura da lista de arquivos de resultados do arquivo de manifesto, não será necessário fazer alterações na forma como você processa os resultados. A abordagem existente continua funcionando perfeitamente com o recurso atualizado.

Isso não é recomendado, mas é possível. Trabalhe em seus canais de suporte para pedir para desativar esse recurso.

Trabalhe por meio da equipe de conta atual e dos canais de suporte.

Essa alteração iniciará a distribuição gradual a partir de 1º de setembro de 2023.

Não. A Computação do Azure suporta as métricas em discos. Para obter mais informações, consulte Métricas por dicso para discos gerenciados e não gerenciados.

Alguns gráficos de métricas do Azure, como os que exibem dados de disponibilidade e latência, usam uma linha tracejada para indicar que há um valor ausente (também conhecido como valor nulo) entre dois pontos de dados de granularidade de tempo conhecidos. Por exemplo, se no seletor de tempo você escolheu a granularidade de tempo 1 minute, mas a métrica foi relatada em 07:26, 07:27, 07:29 e 07:30, uma linha tracejada se conectará a 07:27 e 07:29 porque há um intervalo de minutos entre esses dois pontos de dados. Uma linha sólida conecta todos os outros pontos de dados. A linha tracejada cai para zero quando a métrica usa agregação de contagem e soma. Nas agregações média, mínima ou máxima, uma linha tracejada conecta os dois pontos de dados conhecidos mais próximos. Além disso, quando os dados estão ausentes no lado mais à direita ou à esquerda do gráfico, a linha tracejada se expande na direção do ponto de dados ausente.

Você pode configurar um alerta de integridade do recurso com base no serviço Azure Resource Health para acompanhar a disponibilidade da conta de armazenamento. Se não houver transações na conta, o alerta será relatado com base na integridade do cluster de armazenamento em que a conta de armazenamento está localizada.

Os logs da Análise têm registros de todas as operações de leitura, gravação, lista e exclusão das solicitações bem-sucedidas e com falha, de todas as operações. Os logs da Análise são de melhor esforço e nenhuma ordem é garantida.

O feed de alterações é uma solução que fornece log transacional de mutações bem-sucedidas ou alterações na conta, como criação, alteração e exclusão de blobs. O feed de alterações garante que todos os eventos sejam registrados e exibidos na ordem das alterações bem-sucedidas por blob. Portanto, você não precisa filtrar os registros indesejados de um grande volume de operações de leitura ou solicitações com falha. O feed de alterações é fundamentalmente projetado e otimizado para o desenvolvimento de aplicativos que exigem determinadas garantias.

Você pode aproveitar os dois recursos, pois os eventos do feed de alterações e do armazenamento de blobs fornecem as mesmas informações com a mesma garantia de confiabilidade de entrega. A diferença principal está na latência, ordenação e armazenamento de registros de eventos. O feed de alterações publica registros no log dentro de alguns minutos após a alteração, e também garante a ordem das operações de alteração por blob. Os eventos do armazenamento são enviados em tempo real e podem não ser ordenados. Os eventos do feed de alteração são permanentemente armazenados dentro da conta de armazenamento como logs estáveis de somente leitura com sua própria retenção definida. Os eventos de armazenamento são transitórios para serem consumidos pelo manipulador de eventos, a menos que você os armazene explicitamente. Com o feed de alterações, qualquer número de aplicativos pode consumir os logs da forma que desejarem, usando APIs de blob ou SDKs.

Sim. As regras de segurança de rede da conta de armazenamento, incluindo firewalls VNET e baseados em IP, têm suporte para o ponto de extremidade do site estático e podem ser usadas para proteger seu site.

Não. Um site estático dá suporte apenas ao acesso de leitura público e anônimo de arquivos no contêiner $web.

Você pode configurar um domínio personalizado com um site estático usando a CDN (Rede de Distribuição de Conteúdo) do Azure. A CDN do Azure fornece latências baixas consistentes para seu site de qualquer lugar do mundo.

Você pode configurar um certificado SSL personalizado com um site estático usando a CDN do Azure. A CDN do Azure fornece latências baixas consistentes para seu site de qualquer lugar do mundo.

Você pode configurar o cabeçalho do host para um site estático usando a CDN do Azure - Verizon Premium. Gostaríamos de ouvir sua opinião aqui.

Um erro 404 pode acontecer se você se referir a um nome de arquivo usando maiúsculas e minúsculas incorretas. Por exemplo, Index.html em vez de index.html. O nomes de arquivos e extensões em uma URL de site estático diferenciam maiúsculas de minúsculas, embora sejam veiculados por HTTP. Isso também pode acontecer se o ponto de extremidade da CDN do Azure ainda não for provisionada. Aguarde até 90 minutos depois da provisão de uma nova CDN do Azure para que a propagação seja concluída.

No portal do Azure, abra a página de configuração estática do site da sua conta e localize o nome e a extensão que está definido no campo nome do documento de índice. Verifique se esse nome é exatamente o mesmo que o nome do arquivo localizado no contêiner de $Web da conta de armazenamento. Os nomes de arquivos e extensões em uma URL de site estático diferenciam maiúsculas de minúsculas, embora sejam veiculados por HTTP.

Não, se você precisar pesquisar em seus dados de blob, use a aceleração de consulta ou o Azure Search.

Marcas de índice de blob são compatíveis apenas com tipos de dados de cadeia de caracteres e a consulta retorna resultados com a ordenação lexicográfica. Para números, preencha o número com zero. Para datas e horas, armazene como um formato compatível com ISO 8601.

Não, as marcas do Azure Resource Manager ajudam a organizar os recursos do plano de controle, como assinaturas, grupos de recursos e contas de armazenamento. Marcas de índice fornecem gerenciamento de blob e descoberta no plano de dados.

A capacidade de armazenamento é cobrada em unidades da quantidade média diária de dados armazenados, em GB, pelo período de um mês. Por exemplo, se você usar 10 GB de armazenamento de modo consistente na primeira metade do mês e nenhum volume na segunda metade, será cobrado pelo uso médio de 5 GB de armazenamento.

Próximas etapas

Você pode obter mais informações sobre o Armazenamento de Blobs do Azure visitando os seguintes links:

• Introdução ao Armazenamento do Azure
• O que é o armazenamento de Blobs do Azure?