Introdução

O Docker tornou-se essencial hoje em dia… quase todos os produtos são distribuídos como containers e até muitas vezes nem há outra opção (os scripts de instalação começam a ser raros). O Docker Compose leva isto ainda mais longe, permitindo instalar e executar aplicações constituídas por múltiplos containers.

E qual é o problema com isto?

Bem, o problema é que quando um upgrade docker compose falha já numa fase avançada, por exemplo quando falham as migrações da base de dados, ficamos sem forma de voltar à versão anterior… se alguma coisa nos dados foi alterada pela nova versão, como fazemos para voltar à versão anterior que até funcionava tão bem!???

Este post discute o problema, fornece uma solução manual utilizando funcionalidades padrão do Docker, e apresenta uma solução mais avançada e automatizada para fazer backup de stacks Docker Compose. Aviso – este é o 1º artigo que escrevi com a ajuda do meu assistente pessoal virtual (neste artigo usei o chatgpt, e penso usar outros no futuro para comparar). Fiz alterações no texto, mas acho que se nota bem as secções que são 100% artificiais porque parecem anúncios e o português é um pouco “abrasileirado”.

Por Que o Docker Compose é Tão Popular

O Docker Compose ganhou popularidade significativa devido a várias razões principais:

1. Configuração Simplificada de Multi-Containers: O Docker Compose permite definir e executar aplicações Docker multi-container usando um único ficheiro docker-compose.yml. Isso simplifica o processo de gerir aplicações complexas com múltiplos serviços.
2. Facilidade de Uso: Com o Docker Compose, você pode facilmente iniciar, parar e configurar todos os seus serviços de aplicação usando comandos simples. Isso reduz a complexidade envolvida na gestão de containers individuais.
3. Replicação de Ambiente: O Docker Compose facilita a replicação do mesmo ambiente em diferentes estágios de desenvolvimento, teste e produção. Isso garante consistência e reduz a probabilidade de problemas específicos do ambiente.
4. Networking: O Docker Compose configura automaticamente a rede entre containers, permitindo que eles se comuniquem sem problemas. Isso é particularmente útil para arquiteturas de microserviços.
5. Escalabilidade: O Docker Compose suporta a escalabilidade dos serviços para cima e para baixo com um único comando, facilitando o gerenciamento de cargas de trabalho variáveis.

O Problema

O problema é simples: como podemos fazer um backup de todos os volumes usados por todos os containers num docker-compose.yml? Vamos tentar resolver estas 4 questões:

1. Consistência de Dados: Garantir que os dados sejam guardados num estado consistente , que é crucial especialmente para bases de dados e outros serviços em que o estado em disco é relevante na recuperação. O que isto quer dizer é que temos de parar os containers antes de fazer o backup. Vamos fazer stop em vez de down – explicação mais adiante.
2. Recuperação de Desastres: Ter backups confiáveis é essencial para a recuperação de desastres. Em caso de perda ou corrupção de dados, você pode restaurar rapidamente seus serviços. “Obviously”…
3. Rastreamento de Versões: Manter o controle das versões exatas das imagens Docker e das configurações usadas nos seus serviços garante que você possa recriar o mesmo ambiente se necessário. Ou seja, para voltarmos à “versão anterior” temos de guardar os ids das imagens que estavam em uso em cada container quando fizemos o backup.
4. Eficiência: Usar compressão multi-thread acelera o processo de backup, economizando tempo e recursos. Isto porque hoje em dia, toda a gente que usa docker tem multi-cores… fazer uma compressão do backup usando apenas 1 thread é esperar mais tempo desnecessariamente.

O Processo Manual

Tanto quanto sei o Docker não fornece uma solução abrangente out-of-the-box (OOTB) para funcionalidades avançadas de backup, mas tem os blocos de construção básicos necessários para criar backups. Vamos ver este processo passo-a-passo…

Se alguém souber de um processo “oficial” backup-restore ou snapshot por favor deixe aqui um comentário.

Passo 1: Parar os Serviços

Primeiro, paramos os serviços para garantir a consistência dos dados.

docker compose stop

Também podemos fazer docker compose down. A diferença do comando stop é que não destrói os containers… ou seja, ao fazermos stop/start os containers mantém o estado. Por exemplo, se alterámos alguma coisa num container como instalar um pacote, essa alteração mantém-se ao fazer start. Se fizermos down/up os containers são recriados no seu estado inicial, perdendo-se todas as alterações que tenhamos feito (exceto claro o que estiver guardado em volumes).

Passo 2: Backup dos Volumes

Em seguida, usamos os comandos docker run e tar para criar backups dos seus volumes.

Dado que os containers Docker são como máquinas temporárias, em cada reinicio voltam ao seu estado inicial e tudo o que lá pusemos de novo ou atualizado desaparece. Os Volumes são áreas de ficheiros onde podemos guardar dados que são mantidos mesmo quando reiniciamos os containers.

Ora, como explica a AI o que são volumes?

“Volumes são áreas de armazenamento persistente usadas por containers Docker para armazenar dados. Eles permitem que os dados sejam armazenados fora do ciclo de vida dos containers, garantindo que as informações permaneçam intactas mesmo após reinicializações ou recriações dos containers.”

Por exemplo, os Volumes têm de ser usados em containers de bases de dados. De outra forma, quando se reinicializasse esse container a bd voltava ao 0.

Ou seja, um backup de um container é na verdade apenas o backup dos seus volumes. Fazer backup de um container não faz sentido algum…

# Listar volumes
docker volume ls
# Fazer backup de cada volume
docker run --rm -v <nome_do_volume>:/data -v <pasta_local_para_backup>:/backup busybox tar czf /backup/volume_name.tar.gz -C /data .

Aqui temos muito sumo para analisar… usamos 2 capacidades do docker: i) corremos um container temporário que é apagado assim que for terminado (opção -rm) e ii) ligamos este container temporário ao volume que queremos copiar (opção -v). Este é um truque elegante que tem várias coisas importantes:

1. montamos o volume queremos guardar à pasta interna /data no container temporário;
2. montamos a pasta local onde queremos guardar o backup na pasta interna /backup
3. vamos usar o comando tar para comprimir a pasta interna /data para a pasta /backup;
4. os ficheiros na pasta interna /backup vão aparecer na <pasta_local_para_backup> fora do container, no próprio host.

Pois é… um comando tão simples e afinal cheio de truques…

No script final, mais à frente, vamos fazer algumas coisas adicionais – vamos listar os volumes de cada container referido no docker-compose, incluindo volumes anónimos (sem nome). Isto permite automatizar o backup do grupo de containers.

Passo 3: Guardar o Ficheiro Docker Compose

Copiamos manualmente o ficheiro Docker Compose para o local do backup.

cp docker-compose.yml <pasta_local_para_backup>docker-compose_<data>.yml

Num processo de recriação do estado funcional anterior ao desastre vamos precisar do docker-compose.yml tal como estava antes de qualquer alteração. Também vamos precisar de saber a versão exata de cada container que estava em uso…

Passo 4: Registrar as Versões das Imagens

Registamos manualmente as versões das imagens usadas nos seus containers.

# Listar todos os containers em execução docker ps
# Para cada container, obter o ID da imagem
docker inspect --format='{{.Name}} {{.Image}}' container_id

Isto é fundamental… há containers com um ritmo acelerado de lançamento de novas versões. Para voltarmos ao estado inicial temos de saber as versões exatas, e alterar o docker-compose.yml para “tagar” essas versões, garantindo que puxamos as mesmas versões que estavam em uso no momento do backup (em geral são puxadas as versões mais recentes). Isto obrigará à edição do .yml antes de o usar.

Passo 5: Reiniciar os Serviços

Finalmente, voltamos a iniciar os containers:

docker-compose start

Isto serve apenas para voltar a ter os containers a funcionar. Uma vez que já fizemos o backup, podemos então prosseguir com o update dos containers.

Solução Automatizada com Script

Obviamente fazer isto tudo antes de fazermos um update aos nossos containers é absurdo… e a mim irrita-me ligeiramente que o docker não tenha um comando docker compose snapshot… mas enfim…

Já que vamos criar um script então mais vale usar compressão multi-thread e uma opção de dry run. Além disso procuramos volumes com e sem nome (anonymous). O nosso script vai chamar-se compose_snapshot.sh.

Funcionalidades do Script

1. Análise de Argumentos: O script aceita argumentos para o ficheiro Docker Compose, pasta de saída, número de threads para compressão e uma opção de dry run.
2. Consistência de Dados: O script para todos os containers em execução antes de realizar o backup para garantir a consistência dos dados.
3. Compressão Multi-Thread: O script usa pigz para compressão multi-thread, tornando o processo de backup mais rápido e eficiente.
4. Rastreamento de Versões: O script salva os IDs exatos das imagens e o ficheiro Docker Compose usado para o backup, permitindo a recriação precisa do ambiente.
5. Funcionalidade de Dry Run: O script inclui uma opção de dry run para listar os volumes que seriam backupados sem realizar o backup real.

O Script

Aqui está o script compose_snapshot.sh, escrito a meias por mim e pelo meu novo assistente virtual (tenho de lhe arranjar um nome… ART (Asshole Research Transport)*):

#!/bin/bash

# Função para exibir informações de uso
usage() {
  echo "Uso: $0 -f <compose_file> -o <output_folder> -p <num_threads> [--dry-run]"
  exit 1
}

DRY_RUN=false
NUM_THREADS=4

# Analisar argumentos
while getopts ":f:o:p:-:" opt; do
  case ${opt} in
    f )
      COMPOSE_FILE=$OPTARG
      ;;
    o )
      OUTPUT_FOLDER=$OPTARG
      ;;
    p )
      NUM_THREADS=$OPTARG
      ;;
    - )
      case "${OPTARG}" in
        dry-run)
          DRY_RUN=true
          ;;
        *)
          usage
          ;;
      esac
      ;;
    \? )
      usage
      ;;
  esac
done

# Verificar se todos os argumentos necessários são fornecidos
if [ -z "$COMPOSE_FILE" ] || [ -z "$OUTPUT_FOLDER" ] || [ -z "$NUM_THREADS" ]; then
  usage
fi

# Verificar se o ficheiro Docker Compose existe
if [ ! -f "$COMPOSE_FILE" ]; then
  echo "Erro: Ficheiro Compose $COMPOSE_FILE não encontrado."
  exit 1
fi

# Criar pasta de saída se não existir
mkdir -p "$OUTPUT_FOLDER"

# Obter o timestamp atual
timestamp=$(date +%Y%m%d%H%M%S)

# Copiar o ficheiro Docker Compose para a pasta de saída com o timestamp
cp "$COMPOSE_FILE" "$OUTPUT_FOLDER/$(basename "$COMPOSE_FILE" .yml)_${timestamp}.yml"

# Verificar se os serviços Docker Compose estão ativos
if ! docker compose -f "$COMPOSE_FILE" ps | grep -q "Up"; then
  echo "Erro: Serviços Docker Compose não estão em execução. Por favor, inicie os serviços usando 'docker compose -f $COMPOSE_FILE up -d' e tente novamente."
  exit 1
fi

# Obter todos os IDs dos containers do projeto Docker Compose
CONTAINER_IDS=$(docker compose -f "$COMPOSE_FILE" ps -q)

# Função para fazer backup de um volume
backup_volume() {
  local volume_name=$1
  local output_folder=$2
  local timestamp=$3
  local num_threads=$4
  local backup_file="$output_folder/${volume_name}_${timestamp}.tar.gz"

  if [ "$DRY_RUN" = true ]; then
    echo "Faria backup do volume $volume_name para $backup_file"
  else
    echo "Fazendo backup do volume $volume_name para $backup_file"
    docker run --rm -v "$volume_name:/mnt/volume" -v "$output_folder:/backup" alpine \
      sh -c "apk add --no-cache pigz && tar cvf - -C /mnt/volume . | pigz -p $num_threads > /backup/${volume_name}_${timestamp}.tar.gz"
  fi
}

if [ "$DRY_RUN" = false ]; then
  # Parar containers
  echo "Parando todos os containers..."
  docker compose -f "$COMPOSE_FILE" stop
fi

# Fazer backup dos volumes de cada container
for container_id in $CONTAINER_IDS; do
  # Obter os volumes montados de cada container
  VOLUMES=$(docker inspect --format '{{ range .Mounts }}{{ .Name }} {{ end }}' $container_id)

  for volume in $VOLUMES; do
    # Ignorar nomes de volumes vazios (montagens não de volumes)
    if [ -n "$volume" ]; then
      backup_volume "$volume" "$OUTPUT_FOLDER" "$timestamp" "$NUM_THREADS"
    fi
  done

  # Listar o ID da imagem de cada container
  IMAGE_ID=$(docker inspect --format '{{.Image}}' $container_id)
  CONTAINER_NAME=$(docker inspect --format '{{.Name}}' $container_id | cut -c2-)

  echo "Container $CONTAINER_NAME está a usar a imagem ID $IMAGE_ID" >> "$OUTPUT_FOLDER/image_ids_${timestamp}.txt"
done

if [ "$DRY_RUN" = false ]; then
  # Reiniciar containers
  echo "Iniciando todos os containers..."
  docker compose -f "$COMPOSE_FILE" start
fi

if [ "$DRY_RUN" = true ]; then
  echo "Dry run concluído. Nenhum volume foi backupado e nenhum container foi parado."
else
  echo "Backup concluído. IDs das imagens salvos em $OUTPUT_FOLDER/image_ids_${timestamp}.txt."
  echo "Ficheiro Docker Compose salvo em $OUTPUT_FOLDER/$(basename "$COMPOSE_FILE" .yml)_${timestamp}.yml."
fi

Conclusão

O script compose_snapshot.sh é uma ferramenta para facilitar o backup de stacks Docker Compose de forma rápida, com garantia de consistência dos dados, compressão multi-thread, rastreamento de versões e com uma opção de dry run. Implementar uma solução de backup como esta não só protege os seus dados, mas também garante que você pode rapidamente recuperar e recriar o seu ambiente quando necessário. Mas pessoalmente é algo que quero fazer sempre e rapidamente antes de qualquer update a um stack docker-compose.

Nota 1: falta o script de restore! Que pretendo em breve publicar…

Nota 2: o método que uso atualmente é colocar o docker dentro de um container LXD. Antes de fazer um update aos containers, faço apenas 1 comando: lxc snapshot <container> <nome_do_snapshot>. Fácil e rápido.
Mas há coisas que não funcionam bem nesta abordagem, como usar GPUs. Daí o script…

Nota 3: há ferramentas que devem fazer backup de containers, como o portainer. Mas mascaram a mecânica das coisas, impedindo que aprendamos como a tecnologia funciona, e substituindo essa aprendizagem por outra que me parece menos útil.

*ART dos fantásticos livros do MurderBot.

Introdução

Há alguns anos publiquei um artigo sobre a conversão de um modelo digital do terreno global para o sistema de coordenadas português e também cortado aos limites de Portugal Continental (https://blog.viasig.com/2010/03/mdt-30m-para-portugal/). Depois coloquei-o numa partilha online. Até hoje continua a ser procurado, embora tenha já feito várias referências para novos dados – melhores e mais atuais.

Os dados que recomendo são da Agência Europeia do Ambiente – o EU-DEM – que pode ser obtido aqui: https://land.copernicus.eu/imagery-in-situ/eu-dem/eu-dem-v1.1?tab=metadata. Estes dados são baseados no SRTM, melhorados com uma série de correções que estão documentadas.

Este mdt tem 25m de resolução, com um erro médio quadrático de +-7m!! O que me parece excelente.

Nota técnica – na realidade estes dados não são um mdt, mas sim um mds – modelo digital da superfície, ou seja, não representam a cota do terreno e sim o topo dos objetos na superfície, como árvores e edifícios e outras estruturas. Mas mesmo isto não é bem correto no caso do eu-dem… Aparentemente, estes dados podem representar o topo de objetos, como árvores e estruturas, mas, por outro lado, como sinais radar (usados na missão original) podem penetrar a canópia das árvores, também não há certeza que os dados representem a cota do topo das árvores.

Este artigo é muito simples – pretende disponibilizar uma versão pronta a usar para Portugal. Nada de especial – vamos apenas derivar uma versão que estará projetada para o nosso sistema de coordenadas, e cortada à extensão do nosso país (continente), usando apenas o QGIS. No fim do artigo há um link para descarregar os dados finais preparados para Portugal.

Obter os dados

Os dados são fáceis de obter – estão divididos em quadrículas de 1.000km de lado, em formato tiff, 32bit, e Portugal abrange 2 destas quadrículas. Podemos vê-las usando o visualizador que encontramos no link acima:

Como vemos, temos de descarregar as quadrículas E10N10 e E20N20. Vamos ao separador Download, e escolhemos estas quadrículas. Descarregamos e passamos ao processamento em QGIS.

Visualizar em QGIS

Os dados estão zipados. Descomprimimos e obtemos 1 tif por quadrícula que podemos carregar no QGIS:

Abrimos as propriedades dos 2 ficheiros e vemos a seguinte informação sobre os ficheiros:

• Projeção – IGNF:ETRS89LAEA – ETRS89 Lambert Azimutal Equal Area
• Resolução espacial: 25m
• Largura e Altura: 40.000×40.000 pixeis (1.000kmx1.000km)
• Tipo de pixel: 32bit
• Compressão: LZW
• Pirâmides: Sim
• Valor “nulo” (no data): -3.40282e+38
• Tamanho total em disco: 983.45MB + 956.04 MB

Plano de Ação

Então qual é o nosso plano de ação?

1. Vamos juntar os 2 ficheiros num mosaico virtual, que praticamente não ocupa espaço em disco, mas representa todos os dados como um só conjunto;
2. Vamos cortar este mosaico virtual pelos limites de portugal;
3. E vamos reprojetar para o sistema de coordenadas português. Vamos também escolher uma compressão eficiente e que conserve os dados sem alterações;
4. E no fim, zipamos e colocamos algures online para a malta usar.

Para o corte vamos usar a Carta Administrativa Oficial Portuguese disponível no site da DGT.

1. Unir 2 ficheiros raster num mosaico virtual

Isto é um truque – criar ficheiros virtuais que são apenas pequenos ficheiros de texto que descrevem as operações que queremos fazer, mas sem as fazer realmente. Isto permite criar novas representações dos nossos dados sem ocupar espaço em disco, mas em troca, ocupamos mais o processador e a memória. Já falei várias vezes sobre este fantástico formato VRT, e pode-se ler mais sobre ficheiros VRT aqui.

Para criar um ficheiro VRT a partir de outros ficheiros, usamos a ferramenta “Criar raster virtual” nas ferramentas de processamento do QGIS. Aqui, indicamos os 2 ficheiros que queremos incluir no VRT. A vantagem é que em vez de esperarmos que quase 2GB de dados sejam mastigados para criar um novo ficheiro de mais 2GB, vamos apenas criar muito rapidamente um pequeno ficheiro de texto com 2kb:

O resultado é um ficheiro que se comporta como uma só imagem, que no fundo serve apenas de apontador para 2 ficheiros TIF originais:

De seguida, vamos reprojetar este mosaico virtual para o sistema de coordenadas português.

2. e 3. Cortar e Reprojetar

Bom, reprojetar em QGIS é facílimo. Mas para complicar um bocadinho, vamos cortar e reprojetar num só passo! ahpoisé…

Podemos usar a ferramenta de corte para reprojetar porque tem lá a opção para escolher um sistema de coordenadas diferente para o ficheiro de saída. Assim, é escusado executar depois outra ferramenta só para a reprojeção.

Em primeiro lugar, temos de arranjar o polígono de Portugal continental para cortar o nosso mosaico virtual. A CAOP está disponível para download no site da DGT.

Vê-se bem que dei um toquezinho nos limites de Portugal – o que fiz foi aumentar um pouco a parte litoral para que não deixe nada de fora – é que o eu-dem não tem exatamente os mesmos contornos que a nossa CAOP, como seria de esperar. Por isso, ao aumentar a parte litoral quis evitar deixar de fora algumas partes do eu-dem.

Para fazer o corte do raster com um ficheiro vetorial, usamos a ferramenta “Recortar raster pela camada de máscara”. Aqui vamos usar alguns truques que explico a seguir:

A maioria das opções usadas não têm nada de especial: escolhemos o ficheiro a cortar (mdt), o ficheiro de corte (portugal), uma compressão elevada, e o ficheiro de saída. Mas algumas opções são menos óbvias:

• Na compressão elevada, podemos mudar o parâmetro “PREDICTOR” para o valor 3, que é mais eficiente com valores decimais (que é o nosso caso);
• Nos parâmetros adicionais, vamos incluir “-co tiled=yes” para produzir um ficheiro organizado por blocos comprimidos (isto é importante porque permite melhor compressão e desempenho);
• Nos parâmetros adicionais vamos também aproveitar para dar mais memória ao processamento (é isso que fazem os parâmetros GDAL_CACHEMAX e o WM).

Estas opções em conjunto fazem o processo mais rápido e permitem obter um ficheiro mais pequeno.

O ficheiro resultante tem as seguintes características:

• Projeção – ETRS89 PT TM06 (3763)
• Resolução espacial: 24,99m
• Largura e Altura: 11.633×23.220 pixeis (290kmx580km)
• Tipo de pixel: 32bit
• Compressão: Deflate, Level 9, Predictor 3
• Pirâmides: Não
• Valor “nulo” (no data): -3.40282e+38
• Tamanho total em disco: 346,39 MB

E pronto, o resultado é um mds/mdt para Portugal, já no nosso sistema de coordenadas. Para visualizar, alteramos o sistema de coordenadas do projeto para ETRS89 PT TM06, e vemos que a forma e orientação já é familiar:

Podemos melhorar um pouco o estilo e clareza da visualização alterando a simbologia, e também podemos criar pirâmides/overviews/”vistas gerais” para acelerar a visualização a qualquer escala.

Pirâmides/overviews/”vistas gerais”

As “vistas gerais”, tradução de pirâmides ou overviews, também são referidas neste blog exaustivamente… são versões de resoluções cada vez menores e rápidas (pixel cada vez maior), que tornam a visualização dos dados extremamente rápida – o software escolhe automaticamente que resolução mostra para cada escala.

O costume é usar compressão jpeg, mas neste caso não é possível porque não é compatível com dados 32 bit. Isto foi um pretexto para ir ver as novidades em termos de compressão, e há muitas. Um artigo excelente que compara os novos métodos LERC e ZSTD é o “Guide to GeoTIFF compression and optimization with GDAL” do Koko Alberti – tem no blog mais gemas preciosas que vale a pena ler…

Então, olhando para este artigo vemos que a compressão mais compacta e mais rápida para ficheiros de 32bit é o ZSTD com predictor 3, muitíssimo superior à compressão Deflate e ainda por cima muito mais rápida de visualizar!! Mas mais à frente neste artigo o Koko olha para uma compressão que degrada os dados, a LERC (Limited Error Raster Compression), que rebenta com a escala de compressão… claro que perde dados, e por isso compara-se diretamente com jpeg. Mas tem a vantagem de podermos definir o erro máximo que queremos tolerar. Sendo para pirâmides que servem apenas para visualizar, será uma excelente opção! Qual é o problema?? O GDAL permite criar pirâmides neste formato mas não permite que se defina os parâmetros de compressão, e por isso, não conseguimos definir o erro admissível… para já está fora de ação…

Então, podemos criar as vistas gerais (não me habituo a esta tradução…) usando a compressão ZSTD com predictor=3:

É produzido um ficheiro .ovr com o tamanho de 126MB. Para os dados em causa, esta compressão foi praticamente igual à “High compression” do QGIS… não sei se vale a pena.

E terminámos… o restante é só para nerds… o link para download está no fim do artigo.

Só por carolice, tentei comprimir este ovr com compressão LERC_DEFLATE e um erro de 0,5m, depois adicionei-lhe pirâmides, e obtive um tamanho de 66MB, perto de metade!!!! Como é apenas para visualização, é uma opção incrível quando não conseguimos usar JPEG. (Mas não se esqueçam que ao fazer identify no mdt, vão obter o valor visível, logo se querem ver a cota “verdadeira” têm de fazer zoom até verem a imagem base e não as pirâmides!)

Converter de 32bit para inteiros 16bit

Como sou do século passado e acho que espaço em disco é valioso, vou converter de 32bit para 16bit, porque as elevações no nosso território variam de -5 a 2000 e qualquer coisa metros. Estes valores cabem perfeitamente em 16bit. Mas como 16bit têm de ser inteiros (porque no qgis não há reais de 16bit), também vamos deitar fora as casas decimais… para um erro médio quadrático de 7m, e para os usos em causa, parece-me que não é grave deitar fora ou ganhar até 0,5m de elevação.

Sendo sincero, eu costumo fazer isto na linha de comando, com o GDAL. Mas o desafio aqui era fazer tudo em QGIS, que tem funções próprias e também acesso a todas as ferramentas do GDAL, disponibilizando uma interface de utilizador simpática.

Há várias formas de fazer esta conversão, mas temos de ter cuidado porque não queremos alterar os valores. No nosso caso, queremos preservar os valores de altimetria e passá-los apenas a inteiros de 16bit. Isto porque em 16bit os valores podem variar entre -32768 e +32767 , portanto mais que suficiente para guardar os nossos valores. O único valor que será convertido será o valor nulo que passará automaticamente a -32768. É que há vários algoritmos que recalculam os valores para que fiquem proporcionalmente na mesma “posição” dentro do novo domínio de valores possíveis. Por exemplo, se passarmos de 32bit para 16bit estes algoritmos partem do princípio que existem dados fora do intervalo válido de 16bit e por isso usam uma interpolação linear para os colocar neste intervalo. Assim, um valor de 2147483647 passaria a 32768, e por aí fora.

Então para manter os valores, a ferramenta que usei foi a Converter (Translate): https://docs.qgis.org/3.22/en/docs/user_manual/processing_algs/qgis/rasteranalysis.html#round-raster. Esta ferramenta é apenas uma interface para o comando GDAL – gdal_translate, que permite uma imensidão de parâmetros, mas nós queremos apenas fazer 2 coisas: passar a 16bit e manter a compressão do original:

Produzimos assim um ficheiro de apenas 68MB… Mais as pirâmides com apenas 30MB. Faz alguma diferença… como apenas removemos a parte decimal das cotas, o erro máximo é inferior +-0,5m:

Conclusão

Bem, aquilo que era para ser um simples artigo para disponibilizar um ficheiro de altimetria para Portugal, acabou por ficar um bocadinho extenso

O ficheiro zipado 32bit está aqui: https://blog.viasig.com/eu-dem_portugal_32bit.zip.

E para quem quiser algo mais pequeno e não se importar de usar cotas inteiras (sem parte decimal) tem aqui a versão 16bit: https://blog.viasig.com/eu-dem-portugal-16bit.zip.

Até breve, e qualquer coisa deixem comentário.

TLDR: Neste post discutimos formas de acelerar o processo de criação de overviews, e no fim usamos um script que reduz o tempo de processamento em 20%-50%. O script é apresentado abaixo e está no github.

Na visualização de rasters é obrigatório construir as overviews ou pirâmides, para conseguirmos uma visualização rápida.

As overviews são uma série de cópias do nosso raster com resoluções cada vez menores (pixeis maiores), e geralmente cada nível aplica uma redução de 50% na resolução. Por exemplo, numa resolução original de 0,30m/pixel, as overviews são imagens com resoluções de 0,60 – 1,20 – 2,40m/pixel e assim sucessivamente até que não faz sentido reduzir mais a imagem.

Em geral, a construção destas pirâmides é feito com o comando gdaladdo, e é o processo mais moroso quando processamos grandes áreas. Nem a conversão com compressão, nem a união de muitos rasters leva tanto tempo.

Actualmente, com discos SSD rapidíssimos e memória super-abundante, e processadores multi-core, o comando gdaladdo que constrói overviews continua a usar apenas 1 core… por outro lado, é mais lento que outros comandos, como o gdal_translate.

Recentemente processei novos mosaicos para o Alentejo, desta vez com ortofotomapas com 0,30m de resolução, rgb+nir. E, claro, construir overviews foi uma tortura… mais de 8h para cada metade (dividi a área em 2 blocos este/oeste). O processador nunca passou dos 17% (i7 de 4 cores/8threads), e o disco SSD nunca passou de uns miseráveis 5MB/s (quando o disco é capaz de 1000MB/s). Muito frustrante…

O processo que uso consiste sempre em manter os ficheiros independentes, e criar um mosaico .vrt. Por hábito não crio mosaicos tif enormes. Este processo é descrito em artigos anteriores.

Depois de pesquisar online, vi 3 sugestões para melhorar o tempo de criar overviews:

• Criar uma escada de vrt’s e construir um nível de overviews diferente para cada um em paralelo usando o gdal_translate, e depois configurá-los para que o 1º referencie o 2º, e este o 3º, e por ai fora. Mais info aqui: http://osgeo-org.1560.x6.nabble.com/gdal-dev-Scale-dependent-VRT-for-overviews-td4966814.html.
• Ter 2 cópias iguais do vrt, construir níveis diferentes de overviews para cada vrt com 2 comandos simultâneos, e depois juntá-los num só overview usando o comando tiffcp!! Mais info aqui: https://gis.stackexchange.com/questions/281890/how-to-add-other-images-as-tiff-overviews.
• Criar imagens de resolução reduzida, usando o gdal_translate, e renomear estas imagens com extensão .ovr repetida, ou seja, mosaico.vrt.ovr, depois mosaico.vrt.ovr.ovr, e sucessivamente. Embora com ficheiros a mais, pareceu-me muito rápido.

Isto ensinou-me uma série de coisas novas:

1. Os ficheiros .ovr são na verdade ficheiros TIFF multi-página (herança do tempo dos faxes!), onde um tiff é “colado” a outro dentro do mesmo ficheiro. Eu não sabia isto sobre os .ovr. Ou seja, cada resolução é um tiff, dentro do ovr, que é também um tiff (matrioska?).
2. É possível juntar vários tiff num só tiff multi-página usando o comando “tiffcp tiff1 tiff2 tiffunido”.
3. O OSGEO4W inclui uma versão “geo-activada” dos comandos tiff, mantendo as características SIG dos ficheiros.
4. Podemos ter overviews de overviews, juntando a extensão .ovr ao ficheiro .ovr anterior, numa sucessão que funciona em gdal, qgis, e arcgis. Deve funcionar nos restantes programas, como geoserver, mapserver, etc.

Teste

Vamos fazer um teste com uma série mais pequena de ortofotomapas, para vermos qual é a melhoria no tempo de criação de overviews: vamos usar 3 processos simultânos de gdal_translate, onde cada processo constrói um resample diferente (x2, x4, x8), e renomeando-os para terem extensão .ovr acrescida.

A nossa coleção de ortos de testes é constituída por:

• 29 ficheiros 3 bandas x 8 bit, num total de 276MB, já comprimidos em tiff/jpeg, com 5km de lado, e 0,30m de resolução.
• Um mosaico virtual .vrt com todos os 29 ortos, “teste_script.vrt”, com dimensão de 166.667 x 100.000 pixeis.

O método consiste em executar 3 comandos em simultâneo:

• Processo 1: resample para 0,6m/pixel
• Processo 2: resample para 1,2m/pixel
• Processo 3: resample para 2,4m/pixel, mais construção de pirâmides para este resample apenas

Assim, no processo 1 teremos este comando:

gdal_translate -of gtiff -tr 0.6 0.6 -ro -r average --config GDAL_CACHEMAX 1024 -co photometric=ycbcr -co interleave=pixel -co tiled=yes -co compress=jpeg teste_script.vrt teste_script.vrt.ovr

Ou seja, construimos uma cópia do mosaico, em formato tiff, com 2x o tamanho do pixel original (0,6m/pixel) e damos o nome certo para que seja automaticamente reconhecido como overviews do original -> teste_script.vrt.ovr.

No processo 2, construímos um resample com 4x o tamanho do pixel (1,2m/pixel), e damos o nome que o faz ser reconhecido como overviews do 1º processo:

gdal_translate -of gtiff -tr 1.2 1.2 -ro -r average --config GDAL_CACHEMAX 1024 -co photometric=ycbcr -co interleave=pixel -co tiled=yes -co compress=jpeg teste_script.vrt teste_script.vrt.ovr.ovr  

No processo 3, construímos o 3º nível, com 8x a resolução (2,4m/pixel), e com um nome que o marque como as overviews do 2º nível:

gdal_translate -of gtiff -tr 2.4 2.4 -ro -r average --config GDAL_CACHEMAX 1024 -co photometric=ycbcr -co interleave=pixel -co tiled=yes -co compress=jpeg teste_script.vrt teste_script.vrt.ovr.ovr.ovr

Já que sabemos que este resample é muitíssimo mais rápido que o 1º, terminando por isso muito cedo, podemos aproveitar para criar pirâmides para este 3º nível. Isto permitirá termos a série completa de overviews no final:

gdaladdo -ro -r average --config GDAL_CACHEMAX 1024 --config COMPRESS_OVERVIEW JPEG --config PHOTOMETRIC_OVERVIEW YCBCR --config INTERLEAVE_OVERVIEW PIXEL  teste_script.vrt.ovr.ovr.ovr

O script faz uma série de correções aos nomes dos ficheiros caso detecte uma máscara externa, que é o caso do nosso teste (ficheiro .msk). Ficamos assim com os seguintes ficheiros:

      50 194 teste_script.vrt
  12 434 020 teste_script.vrt.msk
   6 003 920 teste_script.vrt.msk.ovr
   1 525 126 teste_script.vrt.msk.ovr.ovr
     395 087 teste_script.vrt.msk.ovr.ovr.ovr
     267 858 teste_script.vrt.msk.ovr.ovr.ovr.ovr
 466 889 237 teste_script.vrt.ovr
 116 024 726 teste_script.vrt.ovr.ovr
  32 529 152 teste_script.vrt.ovr.ovr.ovr
  11 135 760 teste_script.vrt.ovr.ovr.ovr.ovr
               10 File(s)    647 255 080 bytes

O tempo de execução foi de 06:47,4 min. E podemos ver a ocupação de CPU, disco e memória muito mais altos:

E funciona? Vamos a ver…

gdalinfo teste_script.vrt
 Driver: VRT/Virtual Raster
 Files: teste_script.vrt
        teste_script.vrt.ovr
        teste_script.vrt.ovr.ovr
        teste_script.vrt.ovr.ovr.ovr
        teste_script.vrt.ovr.ovr.ovr.ovr
        teste_script.vrt.msk
        230_060_irg.tif
        230_065_irg.tif
...  ...  ...  ...  ...
Size is 166667, 100000
 Coordinate System is:
... ... ... ... ...
Band 1 Block=128x128 Type=Byte, ColorInterp=Red
   Min=0.000 Max=255.000
   Minimum=0.000, Maximum=255.000, Mean=109.688, StdDev=100.399
   Overviews: 83334x50000, 41667x25000, 20833x12500, 10417x6250, 5209x3125, 2605x1563, 1303x782, 652x391, 326x196, 163x98
   Mask Flags: PER_DATASET
 ...  ...  ...  ...  ... 

O gdalinfo reconhe todas as pirâmides. E o QGIS?

Pequeno à parte: Já em artigos anteriores referi que o QGIS tem de ser “convencido” a ler máscaras externas. Isto não causa problemas ao processo. Aparentemente, o GDAL tem um comportamento diferente com máscaras externas, em que as expõe com valores 0/1, em vez de valores 0/255 como acontece com máscaras internas. Sem esta correção a máscara não é detectadas correctamente pelo QGIS, e temos de a ignorar, aparecendo as zonas pretas sem dados. Se corrigirmos editando o vrt, tudo aparece correctamente. Mas em qualquer dos casos as overviews funcionam:

Com o gdaladdo “normal”

Para compararmos, vamos criar overviews com o processo normal:

timing "gdaladdo --config GDAL_CACHEMAX 1024 --config COMPRESS_OVERVIEW JPEG --config PHOTOMETRIC_OVERVIEW YCBCR --config INTERLEAVE_OVERVIEW PIXEL teste_gdaladdo.vrt"

14:52:45,10

a executar o comando indicado: "gdaladdo --config GDAL_CACHEMAX 1024 --config COMPRESS_OVERVIEW JPEG --config PHOTOMETRIC_OVERVIEW YCBCR --config INTERLEAVE_OVERVIEW PIXEL teste_gdaladdo.vrt"

0…10…20…30…40…50…60…70…80…90…100 - done.

0…10…20…30…40…50…60…70…80…90…100 - done.

15:01:17,19

Assim, o processo normal demorou 08:32,1 min.

E os ficheiros deste processo normal são:

      50 194 teste_gdaladdo.vrt
  23 195 175 teste_gdaladdo.vrt.msk
 827 911 591 teste_gdaladdo.vrt.ovr
  3 File(s)    851 156 960 bytes

Nota: este vrt tem uma máscara externa .msk. Como me esqueci do parâmetro -ro (readonly), as overviews da máscara foram adicionadas ao próprio msk. Também me esqueci do método resample average, que seria mais lento…

Comparação

O processo de construir overviews em paralelo, divido em 3 processos simultâneos, é 20% mais rápido, e ainda com um bónus de ocupar menos 23% em disco! (não sei porquê)

Ou seja, conseguimos subir o uso do CPU para 45%, e o disco para 19MB/s. Nada mau. A memória ocupada pelo processo depende do uso que fizermos da flag –config GDAL_CACHEMAX. No nosso caso, definimo-la como 1GB. Logo 3 processos ocupam obviamente 3x esta quantidade.

O ganho de velocidade resulta do processamento em simultâneo – enquanto se processa o 1º nível, processam-se logo os restantes e as máscaras também desses níveis caso exista máscara no raster original.

Script

Numa tentativa de automatizar o processo, criei um script bat para windows. Pode ser obtido aqui: https://github.com/dncpax/Turbo_GDAL_Overviews .

Algumas notas interessantes sobre o bat:

• É possível imitar uma execução em background usando “start /b” dentro do bat.
• A shell DOS só faz aritmética de inteiros, por isso temos de indicar as 3 resoluções que queremos – x2, x4 e x8 – porque em geral não são inteiros e não os conseguimos calcular no bat.
• Usamos DELAYEDEXPANSION porque precisamos de mostrar o tempo de execução.
• Temos de renomear os ficheiros resultantes da máscara externa (.msk) porque ficam com nomes que impedem o seu reconhecimento. O script trata disso com uma série de renames.

A migração para Linux deve ser fácil, porque 80% do script é só validação de argumentos. O que interessa são comandos gdal. Voluntários procuram-se…

Para executar indicamos o raster e as 3 resoluções iniciais das overviews:

turbo_overviews.bat teste_script.vrt 0.6 1.2 2.4  
Inicio em: 13:29:24,69  
Input file size is 166667, 100000  
Input file size is 166667, 100000  00
Input file size is 166667, 100000  
0…10…20…30…40…50….60…70…..80…..9010….100 - done.  
..0…10…20…30….40…50…60…70…80…90.20..100 - done.  
0…10…20…30…40…50…60…70…80…90….100 - done.  
10..30…..40…20..50…..6030…..70…40.80…..90…50.100 - done.  
…60…70…80…90…100 - done.  
Fim em: 13:36:12,07

Conclusões

Se calhar este post é optimista: só fiz 1 teste sério… pode ser o caso de não funcionar mais vez nenhuma ;)…

Para mim é realmente estranho a falta de processamento multi-core no GDAL. Talvez seja uma questão de tempo, mas já se sente a falta. O que existe é muito incipiente e apenas funciona em cenários que não me são aplicáveis (e.g. compressão DEFLATE).

Há mais alternativas a este processo, mas nos testes que fiz não tive tão bons resultados.

Há outros programas que podem fazer resample de imagens e com processamento multi-core, como o imagemagick. Isto obrigará a copiar a georeferenciação para as imagens resultantes porque estes programas não reconhecem a componente SIG das imagens. Mas pode ser interessante.

De qualquer forma, por agora, este processo parece funcionar bem. Falta testar com um mosaico “à séria”. Pode ser que os 20% de maior rapidez se confirmem!

Até breve!

Adenda

Teste com um mosaico um pouco maior…

Este mosaico é similar mas maior: tem uma dimensão de 233.334 x 383.334 pixeis, em 258 ficheiros, num total de 10,3GB. Demorou 41:38,2 min, em vez de 01:35 h com o GDAL v.3.0.4 (na v2.3.0 tinha demorado 08:42:33 h) do gdaladdo… Ou seja, um ganho de 56%!

Observámos uma ocupação do disco interessante: mais de 60MB/s…

Os tamanhos foram similares: 4.4GB vs 4.9GB.

E correctamente visualizado em QGIS:

Neste mosaico mais encorpado, a melhoria é enorme… Curioso em ver a aplicação em mosaicos muito maiores.

Versão abreviada…

Podem aceder aqui a um motor de mosaicos de imagens Sentinel-2 RGB e IRG para Portugal, com serviço WMS, com suporte temporal… O serviço WMS está funcional, mas para usar em QGIS é preciso algumas definições (ler abaixo, muuuito abaixo).

http://sentinelpt.viasig.com/

Alguns avisos: isto é um projecto pessoal, de carolice, tem muitos defeitos, eu sei, que podem ou não vir a ser resolvidos… Estou muito interessado em ouvir sugestões, e para isso nada melhor que o twitter ou os comentários aqui no blog.

Se a carga for demasiada no servidor, os pedidos são “desacelerados”, por forma a manter o servidor equilibrado. Por favor, não usem scripts de download… Pretendo incluir a função de download em breve. Entretanto, se precisarem de alguma imagem é só dizer, eu farei os possíveis para responder atempadamente.

E pronto, agora quem tem curiosidade e paciência pode continuar a ler…

Introdução

Acho as imagens Sentinel um prodígio, a sério. Temos imagens de 10m de resolução, 7 em 7 dias, para grande parte do planeta, gratuitas! É espantoso…

Tenho usado imagens que pesquiso e descarrego a partir dos sites de distribuição da ESA. Mas é um processo moroso obter as imagens – cada uma é 1GB num zip com 13 ficheiros jpeg2000, e mais uma dezena de outros ficheiros de metadados. Ainda mais moroso se quiser juntar algumas imagens. Mas é tudo gratuito.

Também consulto visualizadores web com imagens processadas, com equilibrio de cores, e sem nuvens, e com várias combinações de bandas. É só pesquisar… também é gratuito.

Agora, se subirmos um pouco o grau de exigência e quisermos sobrepor a nossa informação às imagens, podemos usar um serviço WMS. Mas aqui já é pago, e começa nos 20€/mês por utilizador particular ou académico. Se for empresa o preço já sobe. E é completamente justificado. Mas também é um pouco contraditório em relação ao que se pretende do programa Copernicus, que seria disseminar o mais possível os resultados do programa na sociedade civil… 20€/mês parece-me um pouco contraditório.

Na mais recente incursão pelos sites de descarga das imagens, comecei a fazer alguns scripts, muito simples. Mas a coisa foi-se alongando, e acabei por automatizar grande parte do que seria um servidor wms, com dados processados periodicamente. Foi assim que nasceu este projecto – WMS Time Machine!

Isto não é bem uma invenção… Os nossos vizinhos aqui ao lado do Institut Cartogràfic i Geològic de Catalunya têm um servidor WMS-T de imagens Sentinel *do caraças!*…

http://www.icgc.cat/en/Public-Administration-and-Enterprises/Services/Online-services-Geoservices/WMS-Ortoimatges/WMS-Sentinel-2-orthoimages

É pena ser só para a Catalunha…

Componentes e Processo geral

Os passos do processo e os componentes de software usado são:

1. Pesquisa e descargas de imagens – Sentinelsat
2. Processamento das imagens – GDAL/OGR
3. Manutenção da BD de imagens – GDAL/OGR
4. Serviço WMS Time – MapServer
5. Visualizar o serviço em QGIS
6. Visualizador Web – OpenLayers (Feito à pressa! No futuro, talvez um de jeito

Pesquisa e descarga das imagens – Sentinelsat

A pesquisa das imagens e a filtragem das que interessam é feita usando a biblioteca python SentinelSat, que também inclui uma CLI. São apenas usadas imagens Sentinel-2, nível 2A (significa que têm já correção atmosférica).

O esquema de pesquisa é muito simples, e estou a procurar formas de o melhorar. É indicada uma data, e são pesquisadas 16 quadrículas ou tiles ou grânulos (não tenho paciência para ler o dicionário do Sentinel) que correspondem a Portugal, que tenham sido obtidas até 5 dias atrás, com nuvens até 70%. Também são recusadas imagens com menos de 75% do seu tamanho normal para evitar imagens com grandes áreas sem dados. Alguns mosaicos podem ter sido construídos manualmente com nuvens até 90%…

Um exemplo de pesquisa com Sentinelsat:

 sentinelsat  --start 20190818 --end 20190819 --sentinel 2 --instrument MSI  --producttype S2MSI2A --cloud 40 --query "filename=/.+29S(N|P)C.+/"  --user bla --password blabla 

Este comando procura ficheiros com nomes que incluam “29SNC” ou “29SPC” entre os dias 18 e 19-08-2019, com cobertura de nuvens até 40%. A facilidade de usar expressões regulares é muito flexível. Os docs do Sentinelsat e da interface de pesquisa da ESA são muito bons.

Só são descarregadas 4 bandas das 13 disponíveis: B02 (Red), B03 (Green), B04 (Blue), e B08 (Infrared). Isto significa que para uma data são descarregados 64 ficheiros .jp2 (16 tiles x 4 bandas), cerca de 7GB no total. As 4 bandas são depois combinadas em combinações RGB e IRG.

O processo de pesquisa deveria ser melhorado… Gostava de evitar mosaicos com partes significativas sem dados (neste momento há tiles com 25% de área sem dados). Estou a pensar numa pesquisa sobre um maior período, ordenar as imagens por qualidade, e detectar que datas apresentam melhores coberturas. Ou seja, um processo quase inverso do actual… Outra opção é usar o footprint de cada imagem e analisar geometricamente qual a combinação com menores vazios, ou mesmo só fazer o mosaico se não houver vazios.

Processamento das imagens – GDAL

Depois de descarregados, os ficheiros são processados com GDAL e OGR. As 4 bandas de cada quadrícula ou grânulo são convertidas para 8bit, sendo criadas uma imagem virtual RGB e outra IRG para cada Tile. Depois é aplicado um stretch “virtual” para melhorar o contraste. São criados tileindexes para reunir todas as imagens RGB e IRG do país para uma data. Em seguida tento explicar melhor…

A compressão faz com que o tamanho das bandas passe de ~100MB (jp2000, 16bit) para ~6MB (tiff/jpeg, 8bit). E assim os 64 ficheiros tif só ocupam 600MB para todo Portugal Continental, numa data.

É importante referir que para passar de 16bit para 8bit usei a forma mais simples do parâmetro -scale, que efectivamente passa os valores min-max dos 16bits da imagem, para valores entre 0-255. Isto efectivamente já provoca uma alteração à cor e contraste da imagem. E, obviamente, alguma perda de informação. Estas imagens são apenas para visualização e não se recomendam para análise.

Foi necessário melhorar ainda mais o contraste para que as imagens não fiquem demasiado escuras. Como o MapServer não suporta grande coisa na simbologia de rasters, tive de resolver ao nível dos dados.

Encontrei muita informação sobre a opção scale, mas poucas soluções para ajuste do contraste. Algumas óptimas soluções permitem criar novas imagens melhoradas, mas obrigam a mais espaço em disco e mais tempo de processamento…

A solução foi criar um .vrt que faz um ajuste ao contraste dinamicamente através da opção -scale. É usado o método de ajuste pelo desvio padrão, aplicando-o a cada banda. Ou seja, em cada banda é obtida a média e o desvio padrão, e o ajuste é feito calculando novos mínimos e máximos (fazendo o mesmo que uma das opções de Contrast Enhancement do QGIS):

-scale 0 255 media-2.8*stdev media+2.8*stddev

Funciona muito bem, desde que não existam nuvens na imagem:

Com nuvens, e respectivas sombras, tudo piora, como é de esperar… será necessário melhorar o processo para evitar estas áreas brancas e negras:

Criar base de dados das datas e imagens – OGR

Numa data temos assim 16 imagens RGB, e 16 imagens IRG. Todas são virtuais (.vrt), apens combinam 3 das 4 bandas, e não ocupam espaço. Agora queremos criar uma listagem que indique que datas já recolhemos, e quais as imagens que constituem cada data.

A base de de dados é apenas um shapefile com as quadrículas de todas as imagens vrt… o processo é simples e consiste em criar tileindexes… uma forma anciã de ver mosaicos de imagens e que ainda funciona em Mapserver.

Começamos por criar um tileindex das imagens numa data. Simples comando de gdaltindex. Um exemplo de índice rgb do mosaico para o dia 30/06/2019:

Na verdade, os índices são geograficamente todos iguais, porque uso sempre as mesmas 16 tiles. Mas o ideal seria pesquisar pela área de Portugal, e ver que tiles têm melhor cobertura na data escolhida.

A única coisa que varia entre datas são os ficheiros de imagem que são descarregados.

Bom, já temos um tileindex para cada dia descarregado, que é um shapefile com um atributo a indicar o caminho para cada imagem.

Como fazer uma base de dados de todos os mosaicos que já foram descarregados e existem no servidor? A resposta é simples: copiamos estes registos para um shapefile global usando ogr2ogr com a opção -update. E sempre que se constrói um mosaico para uma data nova, vamos inserir estes registos no shapefile global.

Aqui é usada a função SQL do OGR, que é absolutamente fantástica… permite executar SQL ao carregar dados para um shapefile, ou qualquer outro formato.

Assim, ao copiar as quads de um mosaico para o índice global aproveitamos para actualizar alguns campos extra:

• data do mosaico (campo time)
• data da imagem (campo dataimg)
• nome do ficheiro (campo location)
• nome do ficheiro com contraste melhorado (campo localviz)

Significa que sabemos as datas todas que recolhemos, e as imagens que as compõem. Tudo com shapefile!! (o shapefile é eterno!)

E é compatível com MapServer…

Só um exemplo do comando ogr para apagar imagens que já existam de uma data:

ogrinfo -dialect SQLITE tileindex_global_irg.shp -sql "DELETE FROM tileindex_global_irg where location like '%_20190830%_irg_%.vrt'"

Publicar as imagens num serviço WMS-Time

Usei o MapServer como servidor WMS com suporte do parâmetro Time.

O MapServer é fácil de configurar e manipular apenas com ficheiros de texto. A sua arquitectura é tão simples que apenas é necessário um nginx para o colocar na net. A exigência de memória é também muito reduzida. E claro, é um óptimo amigo do GDAL/OGR. Tudo o que era preciso…

Assim, foi criado um mapfile único com 4 layers:

1. Índice das imagens, com label mostrando a data de cada imagem
2. Índice das imagens, com label mostrando o nome do ficheiro (para vermos a tile respectiva se quisermos obter o original no site da ESA)
3. Mosaico RGB
4. Mosaico IRG

Todos apontam para o tileindex RGB ou para o tileindex IRG. Os índices são vectoriais, e os mosaicos são rasters. Simples.

O parâmetro TIME permite filtrar os dados para só mostrar aqueles que cumprem essa query. Ou seja, passamos uma data e o servidor devolve uma imagem onde todos os layers com TIME definido são filtrados por essa data.

No nosso caso, o campo usado para o filtro de data é o campo time, que indica a data de construção do mosaico. Por exemplo, este request mostra só imagens do mosaico RGB com data de 2019-06-30:

http://sentinelpt.viasig.com/wms/sentinelpt/?SERVICE=WMS&VERSION=1.3.0&REQUEST=GetMap&FORMAT=image%2Fjpeg&TRANSPARENT=true&LAYERS=SentinelPT_RGB%2CIndice&TIME=2019-06-30&CRS=EPSG%3A3857&STYLES=&WIDTH=866&HEIGHT=538&BBOX=-868964.8014314906%2C4637845.355088675%2C-860690.4931196203%2C4642985.745240854

Há uma limitação ainda por resolver no serviço WMS: as datas disponíveis podem ser anunciadas pelo serviço. Mas neste momento estão fixadas:

Como ver no QGIS

Pois é… o QGIS não tem grande suporte para usar WMS-Time… mas funciona com alguns truques – basta indicar a data que queremos no url do serviço, e ligar as opções para ignorar os url’s devolvidos no capabilities doc:

Visualizador web

Bom, este visualizador é muito básico. Foi feito com base neste viewer baseado em OpenLayers: https://www.earder.com/tutorials/timeseries-with-geoserver-and-openlayers/.

Permite selecionar a data, tema RGB ou IRG, com ou sem labels. E ver o link WMS correspondente à data selecionada:

http://sentinelpt.viasig.com/

Melhorias??

Tantas, tantas…

• Criar transparência onde não há dados (zonas negras)
• Criar serviço de download (WCS)?
• Melhorar o ajuste de contraste automático actual, de acordo com cada imagem ou fazendo um match dos histogramas (neste momento, é feito um stretch de desvio padrão em todas as bandas)
• Excluir as nuvens do ajuste de contraste
• Criar serviço de tiles (WMTS)?
• Usar um visualizador web como deve ser (TerriaJS?)
• Obter dados para 2017
• Download dos footprints das imagens e usá-los na pesquisa e processamento
• Selecionar entre tiles disponíveis com menor área sem dados
• Reduzir a compressão dos ficheiros, aumentando a qualidade

Acho que nem eu próprio li isto tudo… mas fica para cábula futura.

Legalidades

Este é um projecto pessoal, sem qualquer garantia. Portanto, use por sua própria conta e risco. Contém dados de imagem de satélite Copernicus Sentinel-2 para vários anos, processados para efeitos de visualização e arquivo. Os dados originais são disponibilizados gratuitamente pela União Europeia para todos os fins. Mais informação pode ser consultada aqui: https://scihub.copernicus.eu.

Os dados deste projecto são disponibilizados sob a licença Atribuição 4.0 Internacional (CC BY 4.0)(link). Em resumo, esta licença permite qualquer uso dos dados, mesmo comercialmente, desde que seja indicada a sua fonte e não sejam impostas restrições adicionais aos dados.

É totalmente desaconselhado criar tablespaces na directoria DATA do pgsql. Podem ver-se vários avisos e explicações na net:
https://hunleyd.github.io/posts/Where-Not-To-Put-Your-Tablespaces/

Este post resulta de eu ter cometido este erro há muito tempo atrás (v8.4) e só agora estar a pagar por ele…

Como funcionam os tablespaces no postgres?

Tablespaces em pgsql são pastas onde são colocados os ficheiros de dados, e a teoria é que permitem espalhar os dados em diferentes discos para equilibrar os acessos e o desempenho. Também dão flexibilidade para gerir falta de espaço em disco, p.e. colocando um tablespace noutro disco que tem espaço, e que receberá determinados dados (todos os novos dados, só algumas tabelas, etc.).
Esta divisão também pode ser feita quando temos só um disco, ficando a bd preparada para um cenário futuro com mais discos.

O postgres tem 2 tablespaces iniciais: pg_default e pg_global.
O pg_global é destinado aos objectos de sistema, e o pg_default é obviamente onde são gravados os nossos dados.
A grande questão é: no disco, onde está o pg_default? Está na pasta DATA\base!

Existe uma directoria que baralha isto tudo: DATA\pg_tablespace. E que está vazia. É aqui que os utilizadores costumam baralhar o sistema (como eu), e pensando que esta pasta é onde está o tablespace default, vão raciocinar que podem criar os seus tablespaces ao “lado”, por exemplo DATA\meu_tablespace.

Lição – a directoria DATA não é para o user mexer! É de sistema, é gerida pelo postgres, está off-limits!
Pois mas eu não sabia… e vai daí, criei uma série de tablespaces aqui mesmo:

CREATE TABLESPACE meu_tablspc LOCATION 'C:\Program Files\PostgreSQL\9.3\data\meusdadosgeo';

Na versão actual, o postgres vai avisar que isto não se deve fazer. Eu já fiz isto há muito tempo (comecei na 8.4), e não me lembro de aviso nenhum.
Anos mais tarde, ao fazer upgrades com pg_upgrade comecei a ter os problemas respectivos…

Como funcionam os tablespaces e a directoria pg_tblspc?

Para criar um tablespace novo, temos de criar previamente a directoria onde queremos que o tablespace se localize.
Depois executamos o sql de criação do tablespace, e o postgres vai criar um link (ou junction no Windows) na pasta DATA\pg_tblspc.
Quer isto dizer que não são criadas sub-dirs – são criados apontadores para a pasta de cada tablespace.
Em Windows, podemos verificar que são junctions usando a linha de comando e fazendo um simples dir:

dir "D:\Program Files\PostgreSQL\9.3\data\pg_tblspc"

 Directory of D:\Program Files\PostgreSQL\9.3\data\pg_tblspc

22/01/2019  13:23              .

22/01/2019  13:23              ..

22/01/2019  13:23         12493007 [D:\Program Files\PostgreSQL\tables

paces_digc\sisma_tblspc]

22/01/2019  13:23         18357 [D:\Program Files\PostgreSQL\tablespac

es_digc\always_tblspc]

Podemos ver que a sub-dir 18357 é na realidade um junction que aponta para uma dir noutro local.

Ao criarmos os tablespaces dentro da pasta DATA estão a ver a confusão, certo? Estamos efectivamente a alterar a forma como o postgres gere os tablespaces, criando links/junctions que apontam para a pasta DATA. Quando quiserem usar o pg_upgrade, que vai tentar perceber a estrutura dos tablespaces, e não vai conseguir… resultando em erro de upgrade.

Se está nesta situação terá de a corrigir. Não é difícil mas como temos de alterar a estrutura e localização dos ficheiros de dados da bd é arriscado, e basta um erro para arruinar a bd. Portanto, antes de mais nada faça um snapshot da vm do postgres, ou se não é vm, faça um backup integral da bd. (better paranoid than dead)

Como corrigir?

Os tablespaces, dizem os docs, devem ser criados numa pasta cujo dono é a conta do sistema operativo que controla o serviço do postgres. No meu caso é “Network Service”.
Assim, optei por criar uma pasta para todos os meus tablespaces na dir de instalação do postgres. Isto porque em Windows, o postgres instala as versões como sub-dirs desta:

C:\Program Files\PostgreSQL\9.3
C:\Program Files\PostgreSQL\9.5

Assim, a minha pasta será criada desta forma:
C:\Program Files\PostgreSQL\meus_tablespaces

Fica à prova de apagar acidentalmente… ou pelo menos parece fazer parte da instalação o que fará pensar 2x…

C:\Program Files\PostgreSQL\9.3
C:\Program Files\PostgreSQL\9.5
C:\Program Files\PostgreSQL\tablespaces_adicionais

Depois, paramos a bd, e vamos apagar os junctions e recriá-los apontando para subpastas correctas.

Receita

A seguir apresento, em jeito de resumo, uma sequência de passos para corrigir a situação. Os exemplos consideram que existem 2 tablespaces para corrigir. (Será, naturalmente, melhor exportar os comandos para ficheiros de texto e criar pequenos scripts para ajudar…)

1) parar o serviço do postgres

2) vamos anotar as pastas dos nossos tablespaces, e os números dos junctions/links, vendo o conteúdo da pasta DATA\pg_tblspc:

 dir "D:\Program Files\PostgreSQL\9.3\data\pg_tblspc"
       12493007 [D:\Program Files\PostgreSQL\9.3\data\sisma_tblspc]
       18357 [D:\Program Files\PostgreSQL\9.3\data\always_tblspc]

3) vamos mover as dirs dos nossos tablespaces para a nova localização saudável

move "D:\Program Files\PostgreSQL\9.3\data\sisma_tblspc"   "D:\Program Files\PostgreSQL\tablespaces_adicionais"
move "D:\Program Files\PostgreSQL\9.3\data\always_tblspc"   "D:\Program Files\PostgreSQL\tablespaces_adicionais" 

4) vamos apagar os junctions todos na pasta DATA\pg_tablspc

rd D:\Program Files\PostgreSQL\9.3\data\pg_tblspc\12493007
rd D:\Program Files\PostgreSQL\9.3\data\pg_tblspc\18357

5) vamos recriar os junctions apontando-os para as dir correctas

mklink /J "D:\Program Files\PostgreSQL\9.3\data\pg_tblspc\12493007" "D:\Program Files\PostgreSQL\tablespaces_adicionais\sisma_tblspc"
mklink /J "D:\Program Files\PostgreSQL\9.3\data\pg_tblspc\18357" "D:\Program Files\PostgreSQL\tablespaces_adicionaisc\always_tblspc"

6) iniciamos o serviço do postgres

E testamos, com diversas queries, e verificamos se no log surgem erros. Mas em principio se a bd iniciou não haverá problemas.
Se ocorrer um erro ao iniciar o serviço e não conseguir perceber a razão, terá de repor a situação, usando o snapshot da vm, ou restaurando toda a bd a partir do backup que fez.

A partir daqui, podemos ver que a estrutura dos tablespaces em disco ficou:

dir "D:\Program Files\PostgreSQL\tablespaces_adicionais"
  Volume in drive D is Data
  Volume Serial Number is 9CB2-EBBD
  Directory of D:\Program Files\PostgreSQL\tablespaces_adicionais
 22/01/2019  13:18              .
 22/01/2019  13:18              ..
 25/01/2019  18:58              always_tblspc
 25/01/2019  18:58              sisma_tblspc 

Interessante também, e relevante para um processo de upgrade, é ver o conteúdo destas pastas:

dir "D:\Program Files\PostgreSQL\tablespaces_adicionais\sisma_tblspc"
  Volume in drive D is Data
  Volume Serial Number is 9CB2-EBBD
  Directory of D:\Program Files\PostgreSQL\tablespaces_adicionais\sisma_tblspc
 25/01/2019  18:58              .
 25/01/2019  18:58              ..
 24/01/2019  18:59              PG_9.3_201306121 

Ou seja, o postgresql cria uma sub-pasta marcando a versão do postgres que coloca aqui os dados. Num upgrade serão criadas aqui sub-pastas correspondentes à nova versão.

E isso fica para um próximo post… Até breve.

Quando o postgresql termina abruptamente de forma anormal, geralmente recupera sem problemas.
Mas recentemente sucedeu-me que no log apareciam milhares de mensagens deste tipo:

2019-01-24 13:31:39 GMT LOG:  autovacuum: found orphan temp table "pg_temp_56"."sde_logfile_data" in database "postgis"

Aparentemente estas mensagens são escritas pelo menos todos os segundos, o que degrada o desempenho e aumenta o tamanho dos logs.

Para resolver, basta apagar os schemas tablespaces problemáticos:

DROP SCHEMA pg_temp_56;

Estes schemas tablespaces “especiais” podem ser listados assim:

select relname,nspname from pg_class join pg_namespace on (relnamespace=
 pg_namespace.oid) where pg_is_other_temp_schema(relnamespace);

E confirmando com as mensagens de log, podemos apagar apenas aqueles de que o autovacuum se queixa.

Ao procurar na web, esta queixa não é muito frequente, mas acontece [1]. E nas listas de mail do postgresql [2], vemos até um debate acesso entre os programadores do postgres sobre se continuam a debitar este n.º exagerado de mensagens ou se devem limitar ou eliminar mesmo as mensagens. A opção actual é jogar pelo seguro – manter, para que os responsáveis pela base de dados notem que algo se passa e se preocupem o suficiente para corrigir a situação.

Comigo funcionou…

Evitar conexões…

É conveniente apagar estes schemas tablespaces tendo a certeza de que não há conexões à bd… Para isso, basta editar o ficheiro pg_hba.conf de forma a permitir apenas conexões do localhost.

Devemos comentar as linhas que dão acesso à bd de outros endereços, e deixar ou incluir apenas as linhas que dão acesso ao localhost. Um exemplo seria:

#IPv4 local connections:
host    all             all             127.0.0.1/32            md5
#IPv6 local connections:
host    all             all             ::1/128                 md5
#INTRANET - comentado temporariamente
#host     all     all     192.168.0.0/16  md5
#host     all     all     10.10.0.0/16  md5 

Reiniciamos o serviço do postgresql o que provocará o fecho de todas as conexões, e o assumir da nova configuração, impedindo conexões indesejadas. No meu caso, antes disto, parei o servidor web e o servidor de mapas. Só para ser simpático e não deixar aplicações em estados de erro…

Depois de apagar os schemas tablespaces, devemos reiniciar o serviço postgresql, e verificar se no log aparecem mais avisos deste tipo, porque o autovacuum é também iniciado. Se sim, apagamos os schemas tablespaces em erro.

Quando tudo estiver ok, revertemos o pg_hba.conf para permitir novamente conexões, e reiniciamos o serviço postgresql. Testamos uma aplicação qualquer para vermos se tudo está bem. Vamos para casa ter com a família…

Já tenho todas as minhas aplicações web instaladas em containers LXD separados, numa vps de 3gb ram e 4 vcores, baseada em kvm. Comprei na última black friday e custa-me 5€/mês. Quem estiver à procura de vps baratas recomendo verem aqui: https://lowendbox.com/.

Nesta altura, tenho 3 máquinas:

~$ lxc list
+------------+---------+----------------------+------+------------+-----------+
|    NAME    |  STATE  |         IPV4         | IPV6 |    TYPE    | SNAPSHOTS |
+------------+---------+----------------------+------+------------+-----------+
| dncplex    | RUNNING | 10.166.62.195 (eth0) |      | PERSISTENT | 0         |
+------------+---------+----------------------+------+------------+-----------+
| planetasig | RUNNING | 10.166.62.245 (eth0) |      | PERSISTENT | 0         |
+------------+---------+----------------------+------+------------+-----------+
| viasigwp   | RUNNING | 10.166.62.152 (eth0) |      | PERSISTENT | 0         |
+------------+---------+----------------------+------+------------+-----------+

A máquina “dncplex” é o meu servidor de música, com plex server e o fantástico MyMedia for Alexa! que permite aceder à minha biblioteca de música no meu Echo!

A “planetasig” é obviamente o PlanetaSIG, e a “viasigwp” é este mesmo blog.

Como tive sempre receio de upgrades de versões major no wordpress fui adiando o upgrade da v3 para a v4. E esta já vai na v4.9.5. Está mesmo na altura de fazer o upgrade à prova de falha.

Uma vez que uso o lxd, o plano é copiar o container para um novo, e fazer aí o upgrade. Se correr bem, paro o container antigo v3, e fico com o novo já com o wordpress v4. Se correr mal, apago e recomeço, ou desisto e fico na mesma… risco 0…

Clonar o container original

Para copiar ou clonar um container lxd é muito simples – basta usar o comando copy:

$ lxc copy viasigwp viasigwp4

$ lxc list
 +------------+---------+----------------------+------+------------+-----------+
 | NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS |
 +------------+---------+----------------------+------+------------+-----------+
 | dncplex | RUNNING | 10.166.62.195 (eth0) | | PERSISTENT | 0 |
 +------------+---------+----------------------+------+------------+-----------+
 | planetasig | RUNNING | 10.166.62.245 (eth0) | | PERSISTENT | 0 |
 +------------+---------+----------------------+------+------------+-----------+
 | viasigwp | RUNNING | 10.166.62.152 (eth0) | | PERSISTENT | 0 |
 +------------+---------+----------------------+------+------------+-----------+
 | viasigwp4 | STOPPED | | | PERSISTENT | 0 |
 +------------+---------+----------------------+------+------------+-----------+

Ok, o nosso novo container está parado. Temos de o iniciar…

$ lxc start viasigwp4
$ lxc list
 +------------+---------+----------------------+------+------------+-----------+
 | NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS |
 +------------+---------+----------------------+------+------------+-----------+
 | dncplex | RUNNING | 10.166.62.195 (eth0) | | PERSISTENT | 0 |
 +------------+---------+----------------------+------+------------+-----------+
 | planetasig | RUNNING | 10.166.62.245 (eth0) | | PERSISTENT | 0 |
 +------------+---------+----------------------+------+------------+-----------+
 | viasigwp | RUNNING | 10.166.62.152 (eth0) | | PERSISTENT | 0 |
 +------------+---------+----------------------+------+------------+-----------+
 | viasigwp4 | RUNNING | | | PERSISTENT | 0 |
 +------------+---------+----------------------+------+------------+-----------+

O IP ainda não está atribuído pelo dhcp do lxd, mas é só esperar um pouco e será atribuído um novo IP. (acabou por ser atribuído o ip 10.166.62.181)

Vamos parar o container original para evitar confusões e termos a certeza que vamos realmente usar o novo. O comando para parar containers lxd é stop obviamente:

$ lxc stop viasigwp

Configurar o tráfego no HAProxy

Eu ainda farei um artigo sobre a configuração do tráfego entre a internet e os containers lxd. Por agora, vou apenas rapidamente mostrar a alteração do ip ligado ao domínio do blog.viasig.com. Ou seja, o tráfego que chega à vps usando o nome blog.viasig.com era dirigido para o container original “viasigwp” com ip 10.166.62.245.

Agora, temos um novo container, onde faremos o upgrade, que tem um novo ip 10.166.62.181. É para este novo ip que o HAProxy deve enviar o tráfego do endereço blog.viasig.

Mostro abaixo a parte da configuração do HAProxy relevante para o blog a negrito e laranja (apenas no final da secção abaixo):

$ sudo nano /etc/haproxy/haproxy.cfg

frontend public
 # Listen on port 80
 bind *:80

 mode http

#redirecionamentos de dominios http para https,
#antes de definirmos os servidores http para os dominios http
#1-blog.viasig.com
redirect scheme https code 301 if !{ ssl_fc } { hdr(host) -i blog.viasig.com }

#como uso https no blog, este é o frontend que redireciona o seu trafego
frontend public_https
 bind *:443
 mode tcp
 option tcplog
 tcp-request inspect-delay 5s
 tcp-request content accept if { req_ssl_hello_type 1 }
 default_backend bk_ssl_default

backend bk_ssl_default
 mode tcp
 option tcplog
 acl blogviasig_https req_ssl_sni -i blog.viasig.com

 use-server server1 if blogviasig_https

 option ssl-hello-chk
 #o blog v3 é desativado
 #server server1 10.166.62.152:443 check
 #e o novo v4 é ativado
 server server1 10.166.62.181:443 check

Testamos a configuração só para ter a certeza que está correcta, e carregamos a nova config:

$ sudo haproxy -c -V -f /etc/haproxy/haproxy.cfg
 Configuration file is valid
 $ sudo systemctl reload haproxy
 $ systemctl status haproxy
 ● haproxy.service - HAProxy Load Balancer
 Loaded: loaded (/lib/systemd/system/haproxy.service; enabled; vendor preset:
 Active: active (running) (Result: exit-code) since Tue 2018-12-04 19:16:08 WE
 Docs: man:haproxy(1)
 file:/usr/share/doc/haproxy/configuration.txt.gz
 Process: 31800 ExecReload=/bin/kill -USR2 $MAINPID (code=exited, status=0/SUCC
 Process: 31797 ExecReload=/usr/sbin/haproxy -c -f ${CONFIG} (code=exited, stat
 Process: 995 ExecStartPre=/usr/sbin/haproxy -f ${CONFIG} -c -q (code=exited, s
 Main PID: 1019 (haproxy-systemd)
 Tasks: 3
 Memory: 5.2M
 CPU: 23min 7.777s
 CGroup: /system.slice/haproxy.service
 ├─ 1019 /usr/sbin/haproxy-systemd-wrapper -f /etc/haproxy/haproxy.cfg
 ├─31808 /usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg -p /run/haproxy
 └─31809 /usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg -p /run/haproxy

Upgrade do wordpress

Podemos usar o browser para abrir o endereço blog.viasig.com e fazer o upgrade. É só clicar no botão de upgrade e rapidamente temos o ecrã de sucesso:

Arrumação final

Tudo correu bem. Podemos ver a lista dos containers como ficou:

$ lxc list
 +------------+---------+----------------------+------+------------+-----------+
 | NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS |
 +------------+---------+----------------------+------+------------+-----------+
 | dncplex | RUNNING | 10.166.62.195 (eth0) | | PERSISTENT | 0 |
 +------------+---------+----------------------+------+------------+-----------+
 | planetasig | RUNNING | 10.166.62.245 (eth0) | | PERSISTENT | 0 |
 +------------+---------+----------------------+------+------------+-----------+
 | viasigwp | STOPPED | | | PERSISTENT | 0 |
 +------------+---------+----------------------+------+------------+-----------+
 | viasigwp4 | RUNNING | 10.166.62.181 (eth0) | | PERSISTENT | 0 |
 +------------+---------+----------------------+------+------------+-----------+

Podemos apagar o container  viasigwp quando tivermos a certeza que já não precisamos delete, com o comando lxc delete viasigwp.

Por agora está parado… apenas a ocupar 1,4GB de disco:

$ sudo du -sh /var/lib/lxd/containers/viasigwp
1.4G /var/lib/lxd/containers/viasigwp

Já agora, podemos ver a memória usada pelo wp4:

$ lxc info viasigwp4
Name: viasigwp4
Remote: unix://
Architecture: x86_64
Created: 2018/04/13 21:43 UTC
Status: Running
Type: persistent
Profiles: default
Pid: 30377
Ips:
 eth0: inet 10.166.62.181 vethFNKBJU
 eth0: inet6 fe80::216:3eff:fef9:2084 vethFNKBJU
 lo: inet 127.0.0.1
 lo: inet6 ::1
Resources:
 Processes: 69
 Memory usage:
 Memory (current): 576.75MB
 Memory (peak): 719.80MB
 Network usage:
 eth0:
 Bytes received: 303.39MB
 Bytes sent: 601.68MB
 Packets received: 2521373
 Packets sent: 1531654
 lo:
 Bytes received: 0B
 Bytes sent: 0B
 Packets received: 0
 Packets sent: 0

Podemos ver que depois de 1 semana, o wp 4 usou um máximo de 719MB de memória. Podemos limitar a memória máxima disponível a um container lxd, bem como limitar o uso de processador, espaço em disco e a velocidade de acesso ou IOps,  e da mesma forma para a placa de rede. Tudo  sobre o controle de recursos no lxd pode ser visto aqui com detalhe: https://stgraber.org/2016/03/26/lxd-2-0-resource-control-412/.

No meu caso, limitei a memória máxima do container do plex server a apenas 512MB. Isto porque o plex tem a mania de usar toda a memória que encontra!! O comando que usei foi:

lxc config set dncplex limits.memory 512MB

Podemos ver as configurações com o comando inverso de config show:

$ lxc config show dncplex
architecture: x86_64
config:
 limits.memory: 512MB
 volatile.base_image: e1e62217dabb1acff585f13472af44b2720839546d1c3fb60d6187afa91fc995
 volatile.eth0.hwaddr: 00:16:3e:dd:e6:40
 volatile.idmap.base: "0"
 volatile.idmap.next: '[{"Isuid":true,"Isgid":false,"Hostid":100000,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":100000,"Nsid":0,"Maprange":65536}]'
 volatile.last_state.idmap: '[{"Isuid":true,"Isgid":false,"Hostid":100000,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":100000,"Nsid":0,"Maprange":65536}]'
 volatile.last_state.power: RUNNING
devices:
 root:
 path: /
 type: disk
ephemeral: false
profiles:
- default
stateful: false
description: ""

Assim, a memória fica controlada.

E é tudo… se tudo correr bem o próximo artigo será sobre HAProxy…

Saudações virtuais!

Fica já a nota que o docker e o lxd são concorrentes, mas talvez sejam mais complementares. O docker isola componentes, o lxd isola sistemas operativos. Terão por isso vantagens e desvantagens muitas vezes simétricas. E ambos são similares na tecnologia de base que usam (lxc e chroot + cgroups). Basicamente, usam capacidades do kernel linux para isolar componentes (é por isso que só podemos “virtualizar” componentes linux e não windows ou mac). Na verdade, e para ser tecnicamente menos incorrecto, não se criam máquinas virtuais, mas sim containers. Mas para simplicidade, no resto do texto quando falo de containers ou VM’s é tudo o mesmo… containers.

Aquilo que me entusiasma no LXD é a simplicidade de uso, com muito poucos  comandos, e a facilidade de gerir sistemas que integram vários componentes, como geralmente acontece numa plataforma SIG (qgis, postgresql, geoserver, etc.). Como o LXD virtualiza um SO inteiro, é natural e fácil usá-lo para conter sistemas aplicacionais inteiros.

As máquinas LXD podem ser criadas em directorias no nosso servidor Ubuntu, e podem conter diversos sistemas operativos. E é muito fácil clonar, fazer snapshots, parar e iniciar estes contentores de SO. Já cópias de segurança obrigam a alguma ginástica, mas estão a trabalhar num método simplificado.

Também é fácil limitar os recursos usados por cada VM, quer na memória máxima, quer no processador (cores, % de tempo, etc.), e vários outros recursos. Podem ver info completa aqui: https://stgraber.org/2016/03/26/lxd-2-0-resource-control-412/.

A existência do LXD vem baixar a complexidade da virtualização baseada em containers, deixando de usar hypervisors como o KVM, OpenVZ, VMWare, VirtualBox, e HyperV.

Podemos instalar o Ubuntu directamente na máquina física, e criar VM’s usando comandos LXD. Os seus defensores indicam ganhos de desempenho, ou mais correctamente menos perda de desempenho, e por isso potencial maior densidade de VM’s. Não posso confirmar nem desmentir porque não testei nada disto. Mas parece-me algo lógico.

Só mais um detalhe – o LXD suporta nested virtualization, ou seja, dentro de uma VM Ubuntu podemos usá-lo para criar VM’s, que estão dentro da nossa VM inicial… confuso? Cuidado, que o OpenVZ não suporta lxd… portanto ao comprarem uma VPS assegurem-se que é baseada em KVM.

Nested Virtualization… whaaat?

Instalar o LXD

Instalar o LXD é muito simples – já vem incluído no Ubuntu.

É preciso no entanto iniciá-lo uma primeira vez e definir a sua configuração, que principalmente define o tipo storage usado pelas máquinas a criar (baseadas em directorias ou pools zfs), e a configuração da rede que dirá se as VM’s são acessíveis do exterior, e se poderão comunicar entre si.

O tutorial que usei como base foi este da Digital Ocean: https://www.digitalocean.com/community/tutorials/how-to-set-up-and-use-lxd-on-ubuntu-16-04.

A diferença é que escolhi usar directorias para mais simplicidade, em vez de ZFS. Embora ZFS seja a opção recomendada pela Canonical, fabricante do Ubuntu, envolve uma complexidade que seria contraproducente para mim – o objectivo é ter simplicidade máxima e o menor número de pontos de falha. Mais info aqui: https://insights.ubuntu.com/2016/02/16/zfs-is-the-fs-for-containers-in-ubuntu-16-04/.

Então, a sessão de configuração do lxd foi assim (o meu user é dncpax e as respostas estão a negrito):

$ sudo usermod --append --groups lxd dncpax
$ sudo lxd init
Do you want to configure a new storage pool (yes/no) [default=yes]? y
Name of the storage backend to use (dir or zfs) [default=dir]: dir
Would you like LXD to be available over the network (yes/no) [default=no]? no
Do you want to configure the LXD bridge (yes/no) [default=yes]? yes

Como se vê escolhi sempre os defaults.

Neste ponto, o lxd lança um wizard de configuração da rede em modo texto (podemos usar num terminal). Se respondermos sempre com defaults, vamos ter no final uma rede interna gerida pelo LXD, do tipo 10.0.0.X.

Desta forma, as VM’s poderão contactar a máquina “mãe” e outras VM’s, e também a Internet. Mas não receberão tráfego exterior, ou seja, ninguém conseguirá aceder às nossas VM’s.

(Para permitir o acesso do “exterior” às nossas VM’s LXD vamos ter de usar algum tipo de router/firewall (IPTables) ou reverse proxy (NGinx ou HAProxy). Eu escolhi usar o HAProxy, que veremos noutro artigo.)

Durante o wizard, vai ser configurada uma rede IPv4, e opcionalmente uma rede IPv6. Eu usei sempre os defaults, mas não configurei a rede IPv6:

A minha rede foi configurada como 10.70.99.X, e assim todas as VM’s terão um IP deste tipo.

Utilizar LXD

A partir daqui temos os comandos do lxd ao dispor. Parte são baseados em lxc e outros em lxd. (lxc é o componente de base do lxd.)

Por exemplo, ver as VM’s criadas (não há ainda) – lxc list:

$ lxc list
+------+--------+------+------+------+-----------+
| NOME | ESTADO | IPV4 | IPV6 | TIPO | SNAPSHOTS |
+------+--------+------+------+------+-----------

Nota: se tiverem um erro de permissão negada, é porque o vosso novo grupo lxd não está ainda “activo”. Podem fechar a sessão e abrir uma nova com o mesmo login e continuar o trabalho, ou executarem “newgrp lxd”.

Ver a configuração do lxd – lxc info:

$ lxc info
config: {}
api_extensions:
- id_map
- id_map_base
- resource_limits
api_status: stable
api_version: "1.0"
auth: trusted
auth_methods: []
public: false
environment:
  addresses: []
  architectures:
  - x86_64
  - i686
  certificate: |
    -----BEGIN CERTIFICATE-----
    MIIFWzCCA0OgAwIVK3ESSSDQAIgte5p8cNcFQHJo0byAjiQD2YkT/sXr+3mf5U
    bla bla bla bla
    hTuelEv1+SWzBsN2nDbF7ZUDhw4cioBS59fkWidNrg==
    -----END CERTIFICATE-----
  certificate_fingerprint: 85ab3c61 bla 6d2bae
  driver: lxc
  driver_version: 2.0.8
  kernel: Linux
  kernel_architecture: x86_64
  kernel_version: 4.4.0-109-generic
  server: lxd
  server_pid: 3276
  server_version: 2.0.11
  storage: dir
  storage_version: ""

Então o que temos por agora? Um deamon lxd que coordenará a existência e o isolamento das VM’s a criar. Podemos ver o seu estado actual com systemctl (notem a memória ocupada):

systemctl status lxd
● lxd.service - LXD - main daemon
   Loaded: loaded (/lib/systemd/system/lxd.service; indirect; vendor preset: ena
   Active: active (running) since Qui 2018-01-18 21:35:36 WET; 14min ago
     Docs: man:lxd(1)
  Process: 3315 ExecStartPost=/usr/bin/lxd waitready --timeout=600 (code=exited,
  Process: 3277 ExecStartPost=/usr/lib/lxd/profile-config (code=exited, status=0
  Process: 3265 ExecStartPre=/usr/lib/x86_64-linux-gnu/lxc/lxc-apparmor-load (co
 Main PID: 3276 (lxd)
    Tasks: 9
   Memory: 7.5M
      CPU: 438ms
   CGroup: /system.slice/lxd.service
           └─3276 /usr/bin/lxd --group lxd --logfile=/var/log/lxd/lxd.log

Jan 18 21:35:35 ubuntumin systemd[1]: Starting LXD - main daemon...
Jan 18 21:35:36 ubuntumin lxd[3276]: lvl=warn msg="CGroup memory swap accounting
Jan 18 21:35:36 ubuntumin systemd[1]: Started LXD - main daemon.

Criar e gerir VM’s

Trabalhar com VM’s ou containers LXD é muito fácil, e basicamente limita-se a estes passos:

1. Criar o container com o OS escolhido
2. Aceder ao container na nossa shell ou por ssh
3. Configurar alguns limites se quisermos (de memória p.e.)
4. Parar ou reiniciar um container
5. Ver os detalhes de um container, incluindo memória ocupada

A melhor página que conheço sobre gestão de containers LXD é esta: https://insights.ubuntu.com/2016/03/22/lxd-2-0-your-first-lxd-container/

Então para criar uma VM de Ubuntu dentro do nosso Ubuntu usamos o comando lxc launch. O sistema operativo que queremos usar pode ser escolhido de uma lista já extensa que pode ser consultada aqui: https://us.images.linuxcontainers.org/.

Antes de instalar uma máquina novinha vamos antes ver como temos a memória:

$ free -m
              total        used        free      shared  buff/cache   available
Mem:           2000          47        1501           3         451        1795

Como se vê, estamos só com 47MB usados e 451MB em cache.

Para instalar a nova vm chamada “wordpress1” (como é a 1ª vez, a imagem é descarregada do repositório online):

$ lxc launch ubuntu:16.04 wordpress1
A criar wordpress1
A iniciar wordpress1

E pronto. Temos um novo ubuntu fresquinho. Podemos ver na lista de containers com lxc list:

$ lxc list
+------------+---------+---------------------+------+-------------+-----------+
|    NOME    | ESTADO  |        IPV4         | IPV6 |    TIPO     | SNAPSHOTS |
+------------+---------+---------------------+------+-------------+-----------+
| wordpress1 | RUNNING | 10.70.99.165 (eth0) |      | PERSISTENTE | 0         |
+------------+---------+---------------------+------+-------------+-----------+

Podemos ver a lista dos containers, se estão iniciados, e os endereços IP internos.

Para vermos a configuração de um container, incluíndo a memória usada:

$ lxc info wordpress1
Nome: wordpress1
Remote: unix://
Arquitetura: x86_64
Criado: 2018/01/18 22:20 UTC
Estado: Running
Tipo: persistente
Perfis: default
Pid: 4426
Ips:
  eth0: inet    10.70.99.165    vethWJS19I
  eth0: inet6   fe80::216:3eff:fef3:793c        vethWJS19I
  lo:   inet    127.0.0.1
  lo:   inet6   ::1
Recursos:
  Processos: 27
  Memory usage:
    Memória (atual): 31.77MB
    Memória (máxima): 152.54MB
  Network usage:
    lo:
      Bytes recebidos: 0B
      Bytes enviados: 0B
      Pacotes recebidos: 0
      Pacotes enviados: 0
    eth0:
      Bytes recebidos: 195.18kB
      Bytes enviados: 7.45kB
      Pacotes recebidos: 138
      Pacotes enviados: 90

Até agora a memória ocupada variou entre 31 e 157 MB…

Para aceder podemos usar ssh ou um comando do lxc (exec):

$ lxc exec wordpress1 -- sudo --login --user ubuntu
To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.

ubuntu@wordpress1:~

Estamos agora “dentro” da nova máquina wordpress1, com o login ubuntu… podemos ver os seus processos de forma isolada, sem acesso à máquina mãe:

$ ps aux
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.2  37596  5616 ?        Ss   22:20   0:00 /sbin/init
root        55  0.0  0.1  41724  3284 ?        Ss   22:20   0:00 /lib/systemd/sy
root        57  0.0  0.1  35280  3228 ?        Ss   22:20   0:00 /lib/systemd/sy
root       232  0.0  0.0  16000   856 ?        Ss   22:20   0:00 /sbin/dhclient
daemon     318  0.0  0.1  26048  2164 ?        Ss   22:20   0:00 /usr/sbin/atd -
syslog     324  0.0  0.1 186904  3288 ?        Ssl  22:20   0:00 /usr/sbin/rsysl
root       326  0.0  0.0  20104  1208 ?        Ss   22:20   0:00 /lib/systemd/sy
root       327  0.0  0.2 272872  5960 ?        Ssl  22:20   0:00 /usr/lib/accoun
root       328  0.0  0.2  65524  5476 ?        Ss   22:20   0:00 /usr/sbin/sshd
message+   329  0.0  0.1  42896  3828 ?        Ss   22:20   0:00 /usr/bin/dbus-d
root       341  0.0  0.1  26072  2528 ?        Ss   22:20   0:00 /usr/sbin/cron
root       342  0.0  1.2 158844 26576 ?        Ssl  22:20   0:00 /usr/lib/snapd/
root       350  0.0  0.4 277184  8260 ?        Ssl  22:20   0:00 /usr/lib/policy
root       378  0.0  0.0  12848  1784 ?        Ss+  22:20   0:00 /sbin/agetty --
root       441  0.0  0.1  59508  4032 ?        Ss   22:25   0:00 sudo --login --
ubuntu     442  0.0  0.2  23012  5064 ?        S    22:25   0:00 -bash
ubuntu     459  0.0  0.1  37764  3276 ?        R+   22:26   0:00 ps aux

A partir daqui podemos instalar o que quisermos da forma habitual. Podemos aceder ao exterior, mas não o inverso – do exterior aceder ao nosso container. E isso será para resolver noutro post.

Por agora, deixem-me terminar com um pequeno teste de desempenho. Uso sempre o 7zip para testes rápidos de cpu. Portanto vamos instalar o 7zip no container testar o cpu com só 1 thread, e depois fazer o mesmo na máquina mãe, para vermos neste caso a quebra de rendimento.

$ sudo apt-get update
Hit:1 http://archive.ubuntu.com/ubuntu xenial InRelease
bla bla
Fetched 24.6 MB in 10s (2276 kB/s)
Reading package lists... Done
$ sudo apt-get install 7zip-full
bla bla
Setting up p7zip-full (9.20.1~dfsg.1-4.2) ...
$ 7z b -mmt1

7-Zip [64] 9.20  Copyright (c) 1999-2010 Igor Pavlov  2010-11-18
p7zip Version 9.20 (locale=C.UTF-8,Utf16=on,HugeFiles=on,2 CPUs)

RAM size:    2000 MB,  # CPU hardware threads:   2
RAM usage:    419 MB,  # Benchmark threads:      1

Dict        Compressing          |        Decompressing
      Speed Usage    R/U Rating  |    Speed Usage    R/U Rating
       KB/s     %   MIPS   MIPS  |     KB/s     %   MIPS   MIPS

22:    3917   100   3811   3810  |    41983   100   3791   3790
23:    3735   100   3806   3806  |    39076   100   3578   3577
24:    3337   100   3589   3588  |    39359   100   3652   3652
25:    3339   100   3812   3812  |    39856   100   3748   3748
----------------------------------------------------------------
Avr:          100   3755   3754               100   3692   3692
Tot:          100   3723   3723

Portanto, dentro do container temos um total de 3723 MIPS de compressão. Vamos sair do container e fazer o mesmo exercício:

ubuntu@wordpress1:~$ exit
logout
dncpax@ubuntumin:~$
dncpax@ubuntumin:~$ 7z b -mmt1

7-Zip [64] 9.20  Copyright (c) 1999-2010 Igor Pavlov  2010-11-18
p7zip Version 9.20 (locale=pt_PT.UTF-8,Utf16=on,HugeFiles=on,2 CPUs)

RAM size:    2000 MB,  # CPU hardware threads:   2
RAM usage:    419 MB,  # Benchmark threads:      1

Dict        Compressing          |        Decompressing
      Speed Usage    R/U Rating  |    Speed Usage    R/U Rating
       KB/s     %   MIPS   MIPS  |     KB/s     %   MIPS   MIPS

22:    3815   100   3712   3711  |    41670   100   3762   3762
23:    3696   100   3767   3766  |    41115   100   3765   3764
24:    3557   100   3825   3825  |    40444   100   3753   3753
25:    3408   100   3891   3891  |    40016   100   3764   3763
----------------------------------------------------------------
Avr:          100   3799   3798               100   3761   3761
Tot:          100   3780   3779

Temos então na máquina LXD 3780 MIPS de compressão.

Ou seja, 3723/3780 = 98% de desempenho no container! Sim, é um teste simplista, e não representa uma avaliação real, mas é óptimo indicador.

E pronto, acabo por aqui. O próximo post da série será dedicado a coisas mais sérias, como ter várias máquinas LXD a comunicar com o exterior, e ver como limitar os recursos usados por uma delas. Até breve.

Ora, esses testes usam dados alfanuméricos e queries “normais”, de escrita e leitura, usando tabelas relacionadas. Ou seja, o pgbench tenta simular uma utilização usual do pgsql.

No nosso caso, SIGianos, a utilização usual não tem nada a haver – usamos dados espaciais e queries muito próprias. Este artigo mostra uma forma de medirmos o desempenho do PostGIS, usando também a ferramenta pgbench.

Uso “normal” de SIG

Quando um programa “normal”, não geográfico, consulta uma base de dados, em geral, obtém alguns registos, e pode até cruzá-los, para dar um resultado final. Provavelmente, apresenta uma tabela de resultados, paginados, com algumas colunas (menos de 10?). Um bom exemplo, é um programa de facturação ou de gestão de stocks. É este tipo de programas que o pgbench tenta simular.

Há uma enorme diferença para o uso que um programa de SIG faz de uma base de dados. O uso normal SIG é visualizar um mapa. E isso faz toda a diferença.

Este simples mapa de enquadramento usa 7 tabelas. A área visível usa um total de 618 registos (1+261+177+1+3+29+146). Se visualizarmos o país inteiro, a conta passa para 5841 registos. É muita informação para uma das operações mais básicas – pan e zoom.

Do ponto de vista da base de dados, o uso SIG é diferente:

• Um mapa é, tipicamente, composto por diversos temas (facilmente mais de 10);
• Cada tema é uma tabela espacial diferente na base de dados, logo em cada visualização vamos ler uma série de tabelas;
• Cada tema/tabela pode ser lido na totalidade (não paginado) se visualizarmos toda a área do tema;
• Cada tema/tabela pode ter aplicada uma selecção (filtro) logo de início com base nos atributos (e.g. para vermos apenas uma categoria de rios ou estradas);
• Cada tema/tabela pode ainda ter aplicado um filtro espacial se estivermos a visualizar apenas uma área específica (ou seja, são apenas pedidos os dados relativos ao rectângulo visível no mapa);
• Mas, principalmente, os dados geográficos são muitos mais “pesados” ou “gordos”: têm uma coluna que contém todos os vértices da geometria! (Cada vértice tem 2 números do tipo double, o que equivale a 2 colunas em dados alfanuméricos.)
• Para agravar a coisa, os utilizadores nunca escolhem os campos que precisam para trabalhar, e assim quando abrem a tabela de atributos todos os campos são lidos.

Usar o pgbench para simular utilizadores SIG

Uma das capacidades do pgbench é que permite testar queries à base de dados feitas por nós, em vez de usar as pré-definidas. Basta criar um ficheiro sql que contém as nossas queries e passá-lo ao pgbench com o parâmetro –f.

É esta capacidade que usamos para simular queries espaciais e medir o desempenho em Transações por Minuto (TPS), tal com se faz para uma base de dados não espacial.

Assim, configuramos o PostgreSQL para que guarde no log todas as queries que recebe. Depois usamos o QGIS com um mapa típico que utilizamos frequentemente, e fazemos zoom a diversos locais e com diferentes escalas. A partir dos logs do PostgreSQL obtemos as queries SQL de cada zoom, e criamos um ficheiro .sql para cada zoom.

Em resumo, no nosso exemplo, obtivemos 10 ficheiros zoomN.sql que correspondem a 10 visualizações no QGIS do mesmo mapa, a escalas diferentes: zoom1.sql, zoom2.sql, … até zoom10.sql. Ou seja, um ficheiro .sql equivale a 1 mapa:

zoom1 – 1:1M                                                        zoom2 – 1:288.000

zoom3 – 1:72.000                                                        zoom4 – 1:18.000

Cada visualização criou um ficheiro .sql que podemos usar no pgbench, e simular vários utilizadores simultâneos de QGIS. Aqui,há uma simplificação: cada zoom é feito instantaneamente a seguir ao outro. Ou seja, vamos simular super-utilizadores!  que não fazem pausas entre zooms e pans.

O comando para simular 12 super-utilizadores que fazem 10 zooms/pans é o seguinte:

pgbench -f zoom1.sql -f zoom2.sql -f zoom3.sql -f zoom4.sql -f zoom5.sql -f zoom6.sql -f zoom7.sql -f zoom8.sql zoom9.sql zoom10.sql  -h <servidor> –U <user> -n -l -c 12 -j 2 -T 180 postgis

Tal como no artigo anterior sobre pgbench, o significado dos parâmetros é:

• -n = não fazer vacuum aos dados, porque estamos a usar a bd de produção;
• -l = log de tempos para um ficheiro;
• -c 12 = simular 12 conexões simultâneas, ou seja, 12 utilizadores de SIG;
• -j 2 = simular 2 threads por conexão (pouco impacto tem);
• -T 180 = simular durante 180 segundos (3min);

Os resultados são:

transaction type: Custom query
scaling factor: 1
query mode: simple
number of clients: 12
number of threads: 2
duration: 180 s
number of transactions actually processed: 4004
tps = 22.148347 (including connections establishing)
tps = 22.188888 (excluding connections establishing)


O que quer isto dizer?

O que interessa é o valor final de 22.18 tps. Isto significa que o nosso PostGIS consegue responder a um ritmo de 22,18 mapas por segundo, em média. Ou seja, deviamos dizer 22,18 MPS (maps per second)

Este valor é a média para todas as escalas que utilizámos no teste. Podemos testar cada escala em separado, e obter desempenhos por escala. Num outro teste usando dados do OpenStreetMap, fizemos este gráfico:

Obviamente, quanto maior a escala, maior o detalhe, e, geralmente, menos dados. Logo, à escala 1:1M temos um poder de processamento de 1,51 MPS, e à escala :1:5600 temos 112,92 MPS.

O que interessa nisto tudo é que podemos comparar agora entre servidores diferentes de PostGIS, e entre configurações diferentes num servidor, para determinarmos a melhor configuração.

Notem que este teste elimina o factor QGIS, ou seja, não se considera o desempenho do QGIS a desenhar o mapa. Uma vez que convertemos cada vizualização num ficheiro .sql, ao executar o teste só usamos o ficheiro .sql. Assim, o desempenho do QGIS não entra na equação, o que é necessário se queremos medir o desempenho do servidor PostGIS.

Outras questões de desempenho

Ao testar o desempenho do PostGIS, acabamos por nos apercebermos de alguns factores que influenciam e muito os resultados e o desempenho observado de um servidor PostGIS.

Por exemplo, se durante o teste verificarmos o que se passa no servidor, podemos ter algumas surpresas:

(Sim, eu sei… é windows…)

O CPU esteve a 91%, para conseguir responder aos nossos 12 QGIS simulados. É perigoso andar tão perto dos 100%, porque o desempenho começa a diminuir. Aqui temos de jogar com o n.º de conexões. Neste caso, baixar de 12 para 10 conexões simultâneas até poderia dar resultados melhores. Cada servidor terá o seu n.º de conexões para o qual se obtém o máximo de tps. Temos de experimentar vários valores e ver o melhor.

Os valores de memória apresentados no Task Manager são inúteis, porque a memória ocupada está sempre perto dos 100%. Teríamos de fazer outro tipo de análise.

Já a ocupação de rede é interessante: é enorme! 769 Mbps! É muito fácil limitar o desempenho do PostGIS por causa de uma má ligação de rede entre o PostGIS e os utilizadores. Se compararmos com o teste de queries “normais” não espaciais, vemos que a ocupação de rede é apenas de 22 Mbps (para o total das 12 conexões simultâneas).

Outra questão importante para os resultados dos testes é observar o estado do PC onde corremos o pgbench, principalmente quanto à ocupação do CPU: como o pgbench corre num só processo ocupa só 1 core, e podemos facilmente limitar os resultados porque o nosso CPU não consegue responder. Temos de verificar durante os testes se o processo pgbench.exe ocupa MENOS que 1 core. No meu caso, usei um i5, que tem 4 cores. Logo, o pgbench tinha de ocupar menos de 25% de cpu para que os resultados fossem bem medidos.

Conclusão

Usar o pgbench com dados espaciais dá-nos uma excelente forma de testar o desempenho do PostGIS. Podemos perceber qual o melhor servidor, se físico, se virtual, para o nosso caso particular. Podemos ainda testar configurações alternativas do PostgreSQL e identificar aquela que dá melhores resultados.

Melhor ainda, será criar um pacote de dados OSM e os scripts .sql correspondentes, e usá-los para termos um teste padrão de PostGIS. Se todos usarmos estes dados vamos conseguir partilhar resultados entre toda a comunidade. Hmmm, temos de pensar nisto…

Mas, no meu caso e imagino muitos outros, como uso mais servidores Windows, precisei de instalar o MapServer de forma a que funcione com IIS. Para além disto, preciso também que o endereço web dos meus mapas não mostre sempre o ficheiro de configuração usado. É feio, e é um risco de segurança. Ninguém devia saber a estrutura das directorias no disco rígido do servidor.

MapServer como aplicação FastCGI – As melhores instruções

A parte inicial de configurar o IIS de forma a executar o MapServer é mais ou menos fácil de encontrar na net. Esta parte consiste em configurar o IIS de forma a considerar o executável mapserv.exe como sendo uma aplicação FastCGI. Isto é mais ou menos padrão nos IIS >7.0 (win7/win8/win2008/win2012). Este link explica bem como fazer isto, usando os ficheiros do MS4W:

https://github.com/mapserver/mapserver/wiki/Installing-Mapserver-under-IIS-7.n-with-FastCGI

Mas melhor ainda é uma instalação automática – sim existe! Preparada pelo nosso grande Tamas Szekeres:

http://www.gisinternals.com/query.html?content=filelist&file=release-1600-gdal-1-11-1-mapserver-6-4-1.zip

Nesta página escolham o ficheiro mapserver-6.4.1-1600-core.msi.

A minha instalação

Eu preferi fazer uma instalação manual, usando ficheiro zip do Tamas Szekeres contendo todo o software, em vez do .msi. Isto dá-me mais flexibilidade para encontrar a configuração que mais se ajusta às minhas necessidades.

Criei uma directoria wwwroot\MapServer, e descomprimi aqui o ficheiro zip. Este ficheiro contém apenas 2 directorias: bin e doc.

E, para facilitar a organização dos ficheiros map e daquilo que serão os serviços web, acrescentei mais 3 directorias: mapfiles, servicos, e tmp.

O aspecto final é este:

Ou seja, tudo o que pertence ao MapServer propriamente dito fica dentro da pasta “binarios”. Agora falta configurar o IIS para executar o mapserv.exe como aplicação FastCGI. A receita é curta e é feita na consola de gestão do IIS…

1) Dar permissões de escrita à pasta tmp.

Este passo é apenas necessário para permitir que o MapServer consiga criar ficheiros, o que apenas sucede em alguns cenários. Em princípio, se servirmos apenas WMS, WFS, não será necessário. Mas pelo sim, pelo não, mais vale configurar…

2) Permitir a execução de scripts na pasta MapServer.

Na pasta MapServer, abrir a funcionalidade “Handler Mappings” :

e abrir a acção “Edit Feature Permissions”. Nesta janela dar permissões de “Read”, “Script”:

3) Definir um documento default a apontar para o executável.

Mais tarde pode ser removido, mas para testar é muito útil. Nas definições básicas da pasta MapServer, escolher a funcionalidade “Default Document”, e escrever o caminho para o executável mapserv.exe (cuidado com as barras /):

4) Criar a aplicação FastCGIS para o MapServer.

Esta configuração é feita no nó principal do nosso site. Por isso, selecionamos o nó “Default web site” ou o nome que demos ao nosso site, a abrimos a funcionalidade “Handler Mappings”:

Aqui, clicamos na acção “Add Module Mapping” e definimos estas propriedades:

Ou seja, definimos que o executável mapserv.exe deve ser executado como uma aplicação FastCGI. Temos ainda de clicar no botão “Request Restrictions” e definir os “verbos” permitidos e o acesso necessário à aplicação:

5) Último passo! Temos de definir as variáveis de ambiente que o MapServer necessita.

Estas variáveis estão todas escritas no ficheiro SDKShell.bat que está na pasta do MapServer. Estas variáveis têm de ser definidas ao nível da aplicação FastCGI, e o único sítio onde se pode fazer é ao nível do servidor IIS e não ao nível do site. Por isso, é preciso selecionar o nó raíz do IIS, e selecionar a opção “FastCGI Settings”:

Nesta janela, vemos a nossa aplicação FastCGI já criada. Podemos editar a nossa aplicação, e na janela de configuração clicamos na opção “Environment Variables”. Aqui temos de criar 4 variáveis:

As 4 variáveis de ambiente são:

• PATH = C:\Inetpub\wwwroot\MapServer\binarios;C:\Inetpub\wwwroot\MapServer\binarios\gdal\python\osgeo;C:\Inetpub\wwwroot\MapServer\binarios\proj\apps;C:\Inetpub\wwwroot\MapServer\binarios\gdal\apps;C:\Inetpub\wwwroot\MapServer\binarios\ms\apps;C:\Inetpub\wwwroot\MapServer\binarios\gdal\csharp;C:\Inetpub\wwwroot\MapServer\binarios\ms\csharp;C:\Inetpub\wwwroot\MapServer\binarios\curl;%PATH%
• GDAL_DATA = C:\Inetpub\wwwroot\MapServer\binarios\gdal-data
• GDAL_DRIVER_PATH = C:\Inetpub\wwwroot\MapServer\binarios\gdal\plugins
• PROJ_LIB = C:/Inetpub/wwwroot/MapServer/binarios/proj/share

E é tudo.

Depois desta configuração, os pedidos ao MapServer já devem funcionar:

http://localhost/MapServer

Parabéns – o MapServer está a funcionar. A partir daqui o uso é o normal. Podemos indicar o mapa que queremos usando o parâmetro mode=map&map=ficheiro. Por exemplo:

Agora, a questão é conseguir ter endereços simpáticos, que não mostrem o nome e caminho do ficheiro de configuração… o que queremos são endereços do tipo:

• http://localhost/MapServer/servicos/PDM
• http://localhost/MapServer/servicos/PlantasLocalizacao

Mas é opcional… já podemos publicar todos os ficheiros map que quisermos. Fica a promessa de outro artigo com esta configuração para breve.

Ah, e já agora – este processo pode-se usar para instalar o QGIS Server. É exactamente a mesma coisa.

Bons web services!