Opção de armazenamento Premium SSD v2 na Base de Dados do Azure para PostgreSQL

SSD Premium v2 oferece maior desempenho do que SSD Premium, além de ser menos dispendioso, como regra geral. Pode ajustar individualmente o desempenho (capacidade, taxa de transferência e IOPS (operações de entrada/saída por segundo)) do SSD Premium v2 a qualquer momento. A capacidade de fazer estes ajustes significa que as suas cargas de trabalho podem ser eficientes em termos de custos, ao mesmo tempo que satisfazem as necessidades de desempenho em constante mudança. Por exemplo, um banco de dados com transações intensivas pode precisar lidar com uma grande quantidade de IOPS por alguns dias de demanda excepcionalmente alta. Ou um aplicativo de jogos pode exigir uma taxa de transferência mais alta apenas durante os horários de pico. Para a maioria das cargas de trabalho de uso geral, o SSD Premium v2 oferece o melhor preço de desempenho. Agora, pode implementar instâncias de servidor flexíveis do Base de Dados do Azure para PostgreSQL com disco SSD Premium v2 em todas as regiões nas quais está disponível.

Diferenças entre SSD Premium e SSD Premium v2

Ao contrário do SSD Premium, o SSD Premium v2 não tem tamanhos dedicados. Você pode definir um disco SSD Premium v2 para qualquer tamanho que preferir e fazer ajustes granulares de acordo com seus requisitos de carga de trabalho. Esses incrementos granulares podem ir em etapas de 1 GiB. O SSD Premium v2 não suporta cache do host, mas ainda assim oferece uma latência inferior ao SSD Premium. As capacidades dos SSD premium v2 variam entre 1 GiB e 64 TiB.

O SSD premium v2 oferece configurações flexíveis de IOPS. O Base de Dados do Azure para PostgreSQL Server fornece uma base de IOPS de 3.000 para discos até 399 GiB, e 12.000 IOPS para discos de 400 GiB ou superiores, sem custo adicional. Os discos podem atingir até 80.000 IOPS quando dimensionados com pelo menos 160 GiB. Os IOPS para além do nível gratuito têm custos adicionais.

O SSD premium v2 também oferece configurações flexíveis de throughput. Base de Dados do Azure para PostgreSQL fornece uma taxa de transferência de base de 125 MB/s para discos até 399 GiB, e 500 MB/s para discos de 400 GiB ou superiores, sem custo adicional. A largura de banda para além da camada gratuita implica custos adicionais.

IOPS

O Base de Dados do Azure para PostgreSQL Server oferece um IOPS base de 3000 para discos até 399 GiB, e 12000 IOPS para discos de 400 GiB ou maior, sem custo adicional. Para atingir 80.000 IOPS em um disco, ele deve ser de pelo menos 160 GiB. Aumentar o IOPS além do nível gratuito resulta em cobranças extras.

Capacidade de processamento

Base de Dados do Azure para PostgreSQL oferece um débito base de 125 MB/s para discos até 399 GiB, e 500 MB/s para discos a partir de 400 GiB, sem custos adicionais. Aumentar a taxa de transferência para além do nível gratuito resulta em taxas adicionais.

O armazenamento que fornece corresponde à quantidade de capacidade de armazenamento disponível para a sua instância de servidor flexível Base de Dados do Azure para PostgreSQL. Esse armazenamento é usado para arquivos de banco de dados, arquivos temporários, logs de transações e logs de servidor PostgreSQL. A quantidade total de armazenamento provisionada também define a capacidade de E/S disponível para o servidor.

A tabela seguinte apresenta uma visão geral das capacidades e máximos de desempenho dos discos premium SSD v2 para o ajudar a decidir qual deve usar.

Seu tipo de máquina virtual também tem limites de IOPS. Embora você possa selecionar qualquer tamanho de armazenamento, independentemente do tipo de servidor, talvez não seja possível usar todas as IOPS que o armazenamento fornece, especialmente quando você escolhe um servidor com alguns vCores.

Para saber mais, consulte Opções de cálculo em Base de Dados do Azure para PostgreSQL.

Funcionalidades suportadas

O SSD Premium v2 suporta funcionalidades Alta Disponibilidade, backups Georredundantes, Réplicas Geográficas, Atualização de Versão Principal, CMK (Chaves Geridas pelo Cliente) e Geo DR (Recuperação em Desastres) para o Base de Dados do Azure para PostgreSQL nas regiões suportadas abaixo.

Américas: Brasil Sul*, Brasil Sudeste*, Canadá Central, Canadá Este, Centro dos EUA, Leste dos EUA, Leste dos EUA 2, Norte Central dos EUA, Sul Central dos EUA, Oeste dos EUA, Oeste dos EUA 2, Oeste dos EUA 3*.

Europa: Áustria Este, França Central*, Alemanha Centro-Oeste, Alemanha Norte, Itália Norte*, Norte da Europa, Noruega Este, Noruega Oeste, Polónia Central*, Espanha Central*, Suécia Central*, Suíça Norte, Suíça Oeste, Reino Unido Sul, Reino Unido Oeste, Europa Ocidental.

Ásia-Pacífico e Médio Oriente: Austrália Central 2*, Austrália Leste, Austrália Sudeste, Índia Central, Ásia Oriental, Indonésia Central*, Israel Central*, Japão Este, Japão Oeste, Jio Índia Central, Jio Índia Oeste, Coreia Central*, Malásia Ocidental*, Nova Zelândia Norte*, Sul da Índia, Sudeste Asiático, Emirados Árabes Unidos Norte*.

África: África do Sul Norte, África do Sul Oeste.

As regiões soberanas, incluindo o China North 3 e o Governo dos EUA na Virgínia, suportam apenas implantações de SSDv2 independentes e atualmente não suportam estas funcionalidades.

Limitações e considerações

• Backups de longo prazo, crescimento automático de armazenamento e PostgreSQL versão 13 não são atualmente suportados com o SSD Premium v2.

• Pode provisionar o SSD Premium v2 usando apenas as camadas de computação de Uso Geral e Otimização de Memória. Criar um novo nível de computação Burstable com o SSD Premium v2 não é suportado.

• Embora CMK e backups geo-redundantes sejam suportados, ativar backups geo-redundantes com o CMK não é atualmente suportado.

• Pode ajustar as definições de desempenho do disco (IOPS ou throughput) até quatro vezes num período de 24 horas. Para discos recém-criados, o limite é de três ajustes durante as primeiras 24 horas.

• Para servidores maiores, o backup automatizado inicial demora mais tempo a concluir e aparece no portal do Azure depois de concluído. Não é necessária qualquer ação durante este período. Recomendamos esperar que o backup inicial seja concluído antes de realizar qualquer operação dependente do backup, como criar réplicas de leitura na região ou realizar uma atualização de versão importante. Após o backup inicial, todos os backups subsequentes são incrementais e normalmente concluídos rapidamente.

• A migração online do SSD Premium para o SSD Premium v2 não é suportada. Para migrar entre estes tipos de armazenamento, pode realizar uma restauração pontual de um servidor SSD Premium para um novo servidor usando o SSD Premium v2. Em alternativa, pode criar uma réplica de leitura de um servidor SSD Premium para um servidor SSD Premium v2 e promovê-la após a conclusão da replicação. Como o autogrow de armazenamento não é atualmente suportado no SSD Premium v2, tens de desativar o autogrow de armazenamento no servidor de origem do SSD Premium antes de iniciar a migração.

• A replicação do SSD Premium para o SSD Premium v2 é suportada apenas para cenários de migração. A replicação contínua não é suportada porque o SSD Premium não consegue igualar o desempenho do SSD Premium v2 e pode resultar em maior latência.

• Se realizar qualquer operação que exija hidratação do disco, pode ocorrer um erro. Este erro ocorre porque os discos SSD Premium v2 não suportam qualquer operação enquanto o disco ainda está hidratado.

Mensagem de erro: Não foi possível concluir a operação porque o disco ainda está a ser hidratado. Tente novamente depois de algum tempo.

As operações que podem desencadear este comportamento incluem:
Realizar escalabilidade de computação, escalabilidade de armazenamento, permitir alta disponibilidade (HA) ou failovers não planeados em rápida sucessão. Se estiveres a fazer grandes atualizações de versão, adicionar HA, iniciar failovers ou criar réplicas na região num curto intervalo antes da hidratação do disco terminar. Criar um novo servidor usando PITR (restauração pontual no tempo) e ativar imediatamente Réplicas de Alta Disponibilidade ou Leitura enquanto o disco ainda está a ser hidratado.

Melhor prática:
Para evitar erros, espaça estas operações ou completa-as sequencialmente, permitindo que a hidratação termine entre as ações.

Pode monitorizar o seu consumo de I/O no portal Azure, ou usando comandos CLI do Azure. As métricas relevantes a serem monitoradas são o limite de armazenamento, a porcentagem de armazenamento, o armazenamento usado e a porcentagem de E/S.

Conteúdo relacionado

• Gerir Base de Dados do Azure para PostgreSQL usando o portal Azure.
• Limites em Base de Dados do Azure para PostgreSQL.