Perguntas frequentes sobre o Armazenamento de Blobs do Azure

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

A política atualizada demora até 24 horas para entrar em vigor. Quando a política estiver em vigor, o tempo necessário para a execução das ações varia dependendo do tamanho da conta de armazenamento e das operações executadas. Se a atualização for para desabilitar ou excluir uma regra e habilitar AutoTierToHotFromCool foi usado, a hierarquização automática para a camada quente ainda acontecerá. Por exemplo, defina uma regra incluindo enableAutoTierToHotFromCool com base no último acesso. Se a regra for desabilitada ou excluída e um blob estiver atualmente na camada fria ou fria e, em seguida, acessado, ele voltará para a camada de atalho conforme isso for aplicado no acesso fora do gerenciamento do ciclo de vida. O blob não passará de quente para frio ou frio, uma vez que a regra de gerenciamento do ciclo de vida está desabilitada ou excluída. A única maneira de evitar o autoTierToHotFromCool é desativar o rastreamento do tempo do ú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 de recursos de armazenamento para ver se as operações estão sendo executadas pela política de gerenciamento do ciclo de vida.

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

Se houver uma política de gerenciamento de ciclo de vida em vigor para a conta de armazenamento, a reidratação de um blob alterando seu nível pode resultar em um cenário em que a política de ciclo de vida move o blob de volta para a camada de arquivamento. 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. Existem três maneiras de evitar que isso aconteça:

• Adicione a daysAfterLastTierChangeGreaterThan condição à ação tierToArchive da política. Esta condição aplica-se apenas à hora da última modificação. Consulte Usar políticas de gerenciamento de ciclo de vida para arquivar blobs.

• Desative a regra que afeta esse blob temporariamente para evitar que ele seja arquivado novamente. Reative a regra quando o blob puder ser movido com segurança de volta para a camada de arquivamento.

• Se o blob precisar permanecer na camada quente, fria ou fria permanentemente, copie o blob para outro local onde a política de gerenciamento do ciclo de vida não esteja em vigor.

O campo de correspondência do prefixo de blobs de uma política é um caminho de blobs completo ou parcial utilizado para corresponder aos blobs aos quais quer aplicar as ações da política. O caminho deve começar com o nome do contêiner. Se não for especificada nenhuma correspondência de prefixo, 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á aos 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 chamado container1 que começam com a cadeia de caracteres sub1/. Por exemplo, o prefixo corresponderá aos blobs denominados 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 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á a 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 (=). As comparações lógicas negativas (!=) são ignoradas.
• A correspondência de prefixos opera de maneira sensível a maiúsculas e minúsculas.

Infelizmente, não há como 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 fornecer uma experiência consistente, não podemos garantir o tempo exato de execução para cada execução. O tempo de execução da regra de inventário pode variar. Por exemplo, se a política de hoje estiver agendada para as 12h05, ela poderá entrar em ação às 12h07, 12h15 ou qualquer outro horário no dia seguinte.

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

A mudança foi implementada para melhorar o desempenho do inventário de blobs, particularmente para grandes contas de armazenamento contendo mais de cinco milhões de objetos. Agora, os resultados são gravados em paralelo a vários arquivos, eliminando o gargalo do uso de um único arquivo de inventário. Essa alteração foi motivada pelo feedback dos clientes, que relataram dificuldades em 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 blobs. Espera-se que melhore o desempenho e reduza o tempo geral de execução. 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. Apenas os novos resultados de inventário de blob têm vários arquivos de inventário.

Não, a mudança acontece perfeitamente.

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

• Se o seu processamento atual pressupõe um único arquivo de resultados de inventário, então você precisa 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 há necessidade de fazer alterações na forma como você processa os resultados. A abordagem existente continua a funcionar perfeitamente com o recurso atualizado.

Isso não é recomendado, mas é possível. Por favor, trabalhe através de seus canais de suporte para pedir para desativar esse recurso.

Por favor, trabalhe através da sua equipe de conta atual e canais de suporte.

Esta mudança começará a ser implementada gradualmente a partir de 1º de setembro de 2023.

N.º O Azure Compute dá suporte às métricas em discos. Para obter mais informações, consulte Métricas por disco para discos gerenciados e não gerenciados.

Alguns gráficos de métricas do Azure, como aqueles 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 grão de tempo conhecidos. Por exemplo, se no seletor de tempo você selecionou 1 minute granularidade de tempo, mas a métrica foi relatada em 07:26, 07:27, 07:29 e 07:30, então uma linha tracejada se conecta 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 fica a zero quando a métrica utiliza as agregações de contagem e soma. Para as 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 em falta no lado mais à direita ou mais à esquerda do gráfico, a linha tracejada expande-se para a direção do ponto de dados em falta.

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

Os logs do Google Analytics têm registros de todas as operações de leitura, gravação, listagem e exclusão com solicitações bem-sucedidas e com falha em todas as operações. Os logs de análise são de melhor esforço e nenhum pedido é garantido.

O feed de alterações é uma solução que fornece registro transacional de mutações ou alterações bem-sucedidas em sua conta, como criação, modificação e exclusões de blobs. O feed de alterações garante que todos os eventos sejam gravados e exibidos na ordem das alterações bem-sucedidas por blob, portanto, você não precisa filtrar o ruído 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 certas garantias.

Você pode aproveitar ambos os recursos, pois o feed de alterações e os eventos de armazenamento de Blob fornecem as mesmas informações com a mesma garantia de confiabilidade de entrega, com a principal diferença sendo a latência, o pedido e o armazenamento de registros de eventos. O feed de alterações publica registros no log em poucos minutos após a alteração e também garante a ordem das operações de alteração por blob. Os eventos de armazenamento são enviados em tempo real e podem não ser solicitados. Os eventos de feed de alteração são armazenados de forma durável dentro de sua conta de armazenamento como logs estáveis somente leitura com sua própria retenção definida, enquanto 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 seus aplicativos pode consumir os logs de acordo com sua própria conveniência usando APIs de blob ou SDKs.

Sim. As regras de segurança de rede da conta de armazenamento, incluindo firewalls baseadas em IP e da VNet, são suportadas para o ponto final do site estático e podem ser utilizadas para proteger o seu site.

N.º Um site estático só suporta o acesso de leitura público anónimo para os ficheiros no contentor $web.

Pode configurar um domínio personalizado com um site estático através da Rede de Entrega de Conteúdos do Microsoft Azure (CDN do Azure). A CDN do Azure fornece latências baixas consistentes ao site a partir de qualquer lugar no mundo.

Pode configurar um certificado SSL personalizado com um site estático através da CDN do Azure. A CDN do Azure fornece latências baixas consistentes ao site a partir de qualquer lugar no mundo.

Pode configurar o cabeçalho de anfitrião para um site estático através da CDN do Azure – Verizon Premium. Gostaríamos de obter os seus comentários aqui.

Um erro 404 pode acontecer se você se referir a um nome de arquivo usando um caso incorreto. Por exemplo: Index.html em vez de index.html. Os nomes de ficheiros e as extensões no URL de um site estático são sensíveis às maiúsculas e minúsculas, embora sejam servidos por HTTP. Isso também pode acontecer se o ponto de extremidade da CDN do Azure ainda não estiver provisionado. Aguarde até 90 minutos depois de provisionar uma nova CDN do Azure para que a propagação seja concluída.

No portal do Azure, abra a página de configuração do site estático da sua conta e localize o nome e a extensão definidos no campo Nome do documento de índice. Confirme que este nome é exatamente o mesmo que o nome do ficheiro localizado no contentor $web da conta de armazenamento. Os nomes de ficheiros e as extensões no URL de um site estático são sensíveis às maiúsculas e minúsculas, embora sejam servidos por HTTP.

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

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

Não, as tags do Gerenciador de Recursos ajudam a organizar recursos do plano de controle, como assinaturas, grupos de recursos e contas de armazenamento. As tags de índice fornecem gerenciamento e descoberta de blob no plano de dados.

A capacidade de armazenamento é faturada por unidades da quantidade média diária de dados armazenados (em gigabytes, GB) ao longo de um período de um mês. Por exemplo, se utilizou de forma consistente 10 GB de armazenamento durante a primeira metade do mês e nenhum na segunda metade do mês, ser-lhe-á faturada uma utilização média de 5 GB de armazenamento.

Próximos passos

Você pode saber mais sobre o Armazenamento de Blobs do Azure visitando os seguintes links:

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