pg_hba.conf

Introdução

O arquivo pg_hba.conf (PostgreSQL Host-Based Authentication) é uma peça fundamental na configuração de segurança de qualquer instância PostgreSQL. Ele define as regras de autenticação e acesso ao banco de dados, determinando quem pode se conectar, de onde e como essas conexões são autenticadas. Neste artigo, exploraremos as diversas opções de configuração disponíveis no pg_hba.conf, desde os métodos de autenticação até a especificação de IPs, usuários e grupos. Também abordaremos os modelos de autenticação mais comuns, como TRUST, password, md5 e scram-sha-256, além de métodos específicos como ident e peer. Ao final, você será capaz de configurar esse arquivo para garantir um ambiente seguro e eficiente para suas aplicações.

Roteiro:

• Modelo de autenticação
  • TYPE (tipos de conexão)
    • local
    • host
    • hostssl
  • DATABASE (banco de dados)
  • USER (usuários ou grupos de usuários)
  • ADDRESS (endereços)
  • METHOD (método)
  • OPTIONS (opções)
  • Exemplos
  • Considerações importantes
• Ident file

Modelo de autenticação

O modelo de autenticação define como a autenticação será realizada e gerenciada, verificando a identidade dos usuários do banco de dados de diferentes formas. No PostgreSQL, o principal modelo é baseado no arquivo pg_hba.conf. Ele pode estar localizado em diferentes locais, dependendo do seu ambiente:

• /var/lib/pgsql/<versão>/data/ nos ambientes Linux Red Hat e derivados (como CentOS);
• /etc/postgresql/<versão>/<cluster>/pg_hba.conf nos ambientes Linux Debian e derivados (como Ubuntu);
• C:\Program Files\PostgreSQL\<versão>\data\pg_hba.conf em Windows;
• Se você criou o seu cluster de dados em um diretório específico e não está utilizando o Linux Debian, o pg_hba.conf deverá estar nesse diretório, que chamamos de $PGDATA (que é a variável de ambiente que contém essa localização).

O pg_hba.conf tem como características regras específicas que suportam vários métodos de autenticação, que podem ainda ser aplicados de forma seletiva.

A estrutura básica do pg_hba.conf é (em cada linha):

TYPE  DATABASE  USER  ADDRESS  METHOD [OPTIONS]

Sendo que  TYPE se refere ao tipo de conexão, DATABASE, ao banco de dados  ao qual a regra se aplica, USER, a usuário ou grupo de usuários, ADDRESS, ao endereço IP ou intervalo (range) de IPs, METHOD  ao método de autenticação, e OPTIONS a algumas opções que podem existir de acordo com o método escolhido, respectivamente.
Além disso, no pg_hba.conf, as linhas de regras são divididas por seções, sendo uma para conexões locais, outra para IPv4, outra para IPv6 e mais uma para replicações.
Apenas para lembrar, é tradição no universo Linux/Unix (de onde o PostgreSQL surgiu) usar o caractere ‘#‘ para marcar comentários no início da linha.

Confira um exemplo de conteúdo do pg_hba.conf:

# DO NOT DISABLE!
# If you change this first entry you will need to make sure that the
# database superuser can access the database using some other method.
# Noninteractive access to all databases is required during automatic
# maintenance (custom daily cronjobs, replication, and similar tasks).
#
# Database administrative login by Unix domain socket
local   all             postgres                                peer

# TYPE  DATABASE        USER            ADDRESS                 METHOD

# "local" is for Unix domain socket connections only
local   all             all                                     peer
# IPv4 local connections:
host    all             all             127.0.0.1/32            scram-sha-256
# IPv6 local connections:
host    all             all             ::1/128                 scram-sha-256
# Allow replication connections from localhost, by a user with the
# replication privilege.
local   replication     all                                     peer
host    replication     all             127.0.0.1/32            scram-sha-256
host    replication     all             ::1/128                 scram-sha-256

TYPE (tipos de conexão)

O PostgreSQL suporta diversos tipos de conexão, cada um com suas próprias características e casos de uso, que determinam como os clientes podem se conectar ao servidor de banco de dados. Entre os principais e mais utilizados, estão:

• local: conexões feitas através de Unix sockets no mesmo sistema onde o servidor PostgreSQL está rodando, ou seja, conexões locais, portanto, não sendo necessário passar a informação da coluna ADDRESS;
• host: conexões TCP/IP tanto locais quanto remotas não criptografadas, ou seja, sem criptografia SSL;
• hostssl: para conexões TCP/IP seguras, ou seja, criptografadas via SSL. É o que recomendamos utilizar e teremos um artigo especial dedicado a ele.

Existem ainda as opções mais incomuns: hostnossl (sem SSL), hostgssenc (com criptografia GSSAPI) e hostnogssenc (sem criptografia GSSAPI).

DATABASE (banco de dados)

Para isolar as regras de autenticação, deve-se especificar a qual banco a linha com as instruções se refere, sendo possível utilizar all para aplicação em todos os bancos. Além disso, há a opção samerole, que é particularmente útil em ambientes com multitenancy, onde diferentes usuários ou grupos precisam acessar seus próprios bancos de dados sem interferir em outros. Com samerole, o Postgres permite que um usuário se conecte apenas a bancos de dados cujo nome coincide com uma role (grupo) da qual ele é membro. Assim, é possível definir que cada usuário tenha acesso apenas aos bancos relacionados ao seu papel, reforçando a segurança e o isolamento entre bancos de dados de diferentes usuários.

USER (usuários ou grupos de usuários)

É possível especificar usuários individuais do PostgreSQL no pg_hba.conf pelo campo USER ou, ainda, usar all para corresponder a todos os usuários, assim como para os bancos de dados.
Podemos também indicar grupos de usuários com o prefixo +, por exemplo, +admins, o que torna fácil o processo de gerenciar permissões de vários usuários simultaneamente. É importante lembrar que não são grupos do sistema operacional, mas, sim, roles definidas no PostgreSQL.
No contexto do PostgreSQL, um “grupo de usuários” é, na verdade, uma role à qual outras roles (usuários) recebem grants (privilégios). Isso permite agrupar vários usuários sob uma mesma role, facilitando o gerenciamento de permissões e acessos em ambientes mais complexos.
Além disso, também podemos informar nomes de usuário como expressões regulares, indicando com o prefixo /, e também é possível gerenciar os usuários, com nome ou expressões regulares, em um arquivo separado, que deve ser mencionado com o prefixo @. Há ainda o caso de replicação, que trata-se de uma conexão usada para sincronizar dados entre servidores, e que deve ser indicada nessa coluna com a palavra-chave replication.

ADDRESS (endereços)

O campo ADDRESS no pg_hba.conf permite especificar quais endereços podem se conectar:

• Subnet: permite conexões de uma faixa de IPs, por exemplo:
  • 192.168.1.1/32 ou fe80::7a31:c1ff:fa34:9eb3/128 – permite apenas um IP específico;
  • 127.0.0.1 ou ::1/128 - (ipv6) – permite apenas conexões locais;
  • 192.168.1.0/24 – permite todos os IPs classe C, de 192.168.1.0 a 192.168.1.255;
  • 192.168.0.0/16 – permite todos os IPs classe B, de 192.168.0.0 a 192.168.255.255;
  • 192.0.0.0/8 – permite todos os IPs classe A, de 192.0.0.0 a 192.255.255.255;
  • 0.0.0.0/0 ou ::0/0 (ipv6) – permite qualquer IP (não recomendamos usar esta configuração em ambiente de produção).
• IP-mask: permite a definição de uma faixa de IPs, semelhante a anterior, mas em vez de usar a subnet, colocamos o IP e a máscara de IPs:
  • 192.168.1.0 ou 255.255.255.0 – permite todos os IPs classe C, de 192.168.1.0 a 192.168.1.255;
  • 192.168.0.0 ou 255.255.0.0 – permite todos os IPs classe B, de 192.168.0.0 a 192.168.255.255.
• Hostname: além de endereços IP, podemos utilizar um hostname, no qual o PostgreSQL realiza várias verificações para garantir a correspondência entre o hostname especificado e o cliente. Lembrando que qualquer lentidão na resolução de nomes pelo DNS irá provocar uma lentidão no processo de conexão em si.
  • Hostname específico: é só colocá-lo, como exemplo.com;
  • Subdomínios: necessário colocar o prefixo “.” antes do hostname, e assim qualquer endereço com esse subdomínio será autorizado, como em .exemplo.com permitiria conexão de sub.exemplo.com, app.exemplo.com etc. (mas não o próprio exemplo.com).
• Também podemos utilizar all para permitir a conexão de qualquer IP, samehost para permitir qualquer IP do próprio servidor e samenet para permitir qualquer IP em qualquer sub-rede à qual o servidor esteja conectado.

METHOD (método)

Os métodos de autenticação no PostgreSQL são as diferentes maneiras que o banco de dados usa para verificar e realizar a autenticação, indo desde a exigência de senhas até a confiança total e permissão absoluta. Os principais são:

• trust: permite conexões sem nenhuma autenticação, ou seja, se o seu IP for contemplado na lista de endereços autorizados, não será necessário fornecer senhas, por isso é adequado apenas para ambiente de testes e desenvolvimento local ou com redes totalmente isoladas e confiáveis endereçando apenas um IP local ou um IP único confiável;
• password / md5 / scram-sha-256: é exigida uma senha no momento da conexão, que varia entre essas três opções com diferentes níveis de segurança:
  • password: senha em texto simples, sem criptografia durante a transmissão pela rede;
  • md5: usa hash MD5 para criptografar a senha durante a transmissão, o que torna o processo um pouco mais seguro, mas seu uso está sendo descontinuado em favor do próximo método considerado mais seguro;
  • scram-sha-256: usa o método SCRAM (Salted Challenge Response Authentication Mechanism) como hash SHA-256, o que o torna a opção baseada em senha mais segura, já que seu protocolo de autenticação não transmite a senha real, e sua criptografia é considerada muito forte.

É importante saber que o tipo de encriptação padrão da senha (md5 ou scram-sha-256) é definido pelo parâmetro password_encryption, que significa que todos os seus usuários criados com senha, ou com a senha alterada, vão tê-la com a criptografia apontada por esse parâmetro. O nosso padrão é scram-sha-256, porém fizemos alterações para exemplificar diferentes cenários;

• ident: usa o serviço de identificação do sistema operacional (Ident ou identd) para autenticar, confiando na informação que o SO passa, por isso requer que o cliente esteja em um servidor ident (mais comum em ambientes Linux, em que o serviço Ident já vem ativado por padrão); 
• peer: confia nas informações de usuários do SO local, ou seja, diferente do ident, não precisa de um serviço externo para isso e só funciona para redes locais. É esse o método de autenticação que costumamos usar para acessar o psql com usuário postgres (estando conectado ao usuário postgres do SO);
• Além desses, o PostgreSQL suporta vários outros métodos, incluindo:
  • reject: rejeita todas as conexões, podendo ser usado para filtrar e impedir grupos; 
  • sspi: autenticação nativa do Windows;
  • ldap: para autenticação via servidores LDAP;
  • radius: para autenticação via servidores RADIUS;
  • cert: usa certificados SSL do cliente para autenticação.

OPTIONS (opções)

Além de todas as configurações que vimos, é possível ainda inserir mais opções para o método de autenticação, que devem ter o formato de nome=valor, e servem para especificar opções adicionais para o método escolhido. Algumas delas são:

• clientcert: além das opções específicas de cada método de autenticação, existe essa opção geral, que pode ser usada em qualquer entrada do tipo hostssl. Essa opção tem dois valores possíveis: verify-ca e verify-full, sendo que o primeiro exige que o cliente apresente um certificado SSL válido e confiável, e o segundo, além de exigir um certificado válido, também verifica se o Common Name (CN) no certificado do cliente corresponde ao nome de usuário ou a um mapeamento aplicável. Isso fornece um nível extra de segurança;
• clientname: quando você está usando autenticação com certificado de cliente (usando o método cert ou a opção clientcert), você pode usar essa opção para especificar qual parte das credenciais do certificado do cliente deve ser comparada com o nome de usuário, sendo as subopções clientname=CN, em que o nome de usuário será comparado com o Common Name (CN) do certificado, e clientname=DN, em que o nome de usuário será comparado com o Distinguished Name (DN) completo do certificado, conforme o formato RFC 2253;
• include, include_if_exists e include_dir: essas opções permitem definir suas regras de autenticação em um arquivo separado, sendo necessário passar o local do arquivo entre aspas simples. A diferença entre essas opções é que a primeira apenas checa o local do arquivo informado e tenta substituir as regras, a segunda faz isso apenas se o arquivo existir, caso contrário será exibida uma mensagem indicando que o arquivo não foi lido, e a última reconhece todos os arquivos de um diretório.

Exemplos

Conexão local de todos os usuários com peer

local		all		all		peer

Este é o caso que possibilita o acesso ao psql pelo usuário postgres do SO, pulando a etapa de fornecimento de senha (acessamos o banco também chamado postgres):

postgresdebian:~$ psql -U postgres -d postgres
psql (16.2 (Debian 16.2-1.pgdg120+2))
Type "help" for help.

postgres=#

Além desse usuário, poderíamos repetir esse tipo de acesso com qualquer outro usuário que existisse tanto no banco de dados quanto no SO, claro, com o mesmo nome nos dois lugares:

ludmila@debian:~$ psql -U ludmila -d postgres
psql (16.2 (Debian 16.2-1.pgdg120+2))
Type "help" for help.

postgres=>

Além disso, conforme explicado, podemos aplicar as regras por banco de dados, então, se fosse especificado o método de conexão peer apenas para o banco postgres, não seria possível acessar sem senha em outros bancos.

Conexão host com IP específico e senha sem criptografia

host		all		all		192.168.1.10/32		password

Como você pode notar, foi solicitada a senha para acessar o banco de outro IP:

fabio@debian-2:~$ psql -h 64.23.248.23 -p 5432 -U fabio -d postgres
Password for user fabio:
psql (16.4 (Debian 16.4-1.pgdg120+1), server 16.2 (Debian 16.2-1.pgdg120+2))
SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, compression: off)
Type "help" for help.

postgres=>

Mas, se a tentativa de acessar fosse feita da rede local com o mesmo usuário fabio, considerando que temos no mesmo arquivo a linha de regras exemplificadas anteriormente, este seria o resultado:

fabio@debian:~$ psql -U fabio -d postgres
psql (16.2 (Debian 16.2-1.pgdg120+2))
Type "help" for help.

postgres=>

Conexão host para grupo de usuários com IP específico e trust

host	    all	 +groupname	      192.168.1.20/32	trust

Esse cenário permite que os usuários pertencentes ao grupo editors se conectem de um IP específico sem a necessidade de informar senha. No nosso caso, o usuário ana está neste grupo:

ana@debian-2:~$ psql -h 64.23.248.23 -p 5432 -U ana -d postgres
psql (16.4 (Debian 16.4-1.pgdg120+1), server 16.2 (Debian 16.2-1.pgdg120+2))
SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, compression: off)
Type "help" for help.

postgres=>

Conexão host para bancos de dados com o mesmo proprietário (samerole)

host    samerole    all     192.168.1.0/24    md5

Com essa configuração, se o usuário user1 tentar acessar o banco de dados que ele mesmo possui, a senha será solicitada, porém, se ele tentar acessar um banco que pertence a outro usuário, como user2, ele não conseguirá, pois a regra só se aplica aos bancos que possuem o mesmo proprietário.

Considerações importantes

• As regras são aplicadas na ordem em que aparecem no arquivo;
• As primeiras regras têm prioridade, então coloque as mais restritivas no início;
• Após modificar o pg_hba.conf, recarregue as configurações com o comando systemctl reload postgresql;
• Se não funcionar, deve-se checar os logs do banco ou então consultar a tabela pg_hba_file_rule do catálogo para entender onde está o erro dentro do pg_hba.conf ;

$ tail postgresql-16-main.log
2024-11-13 17:29:31.029 UTC [141035] LOG:  received SIGHUP, reloading configuration files
2024-11-13 17:29:31.037 UTC [141035] LOG:  invalid connection type "hoost"
2024-11-13 17:29:31.037 UTC [141035] CONTEXT:  line 126 of configuration file "/etc/postgresql/16/main/pg_hba.conf"
2024-11-13 17:29:31.037 UTC [141035] LOG:  /etc/postgresql/16/main/pg_hba.conf was not reloaded

postgres=# select * from pg_hba_file_rules ;
 rule_number |              file_name              | line_number | type  |   database    | user_name  |  address  |                 netmask                 |  auth_method  | options |              error
-------------+-------------------------------------+-------------+-------+---------------+------------+-----------+-----------------------------------------+---------------+---------+---------------------------------
           1 | /etc/postgresql/16/main/pg_hba.conf |         118 | local | {all}         | {postgres} |           |                                         | peer          |         |
           2 | /etc/postgresql/16/main/pg_hba.conf |         125 | local | {all}         | {all}      |           |                                         | trust         |         |
             | /etc/postgresql/16/main/pg_hba.conf |         126 |       |               |            |           |                                         |               |         | invalid connection type "hoost"
           3 | /etc/postgresql/16/main/pg_hba.conf |         128 | host  | {all}         | {all}      | ::1       | ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff | scram-sha-256 |         |
           4 | /etc/postgresql/16/main/pg_hba.conf |         131 | local | {replication} | {all}      |           |                                         | peer          |         |
           5 | /etc/postgresql/16/main/pg_hba.conf |         132 | host  | {replication} | {all}      | 127.0.0.1 | 255.255.255.255                         | scram-sha-256 |         |
           6 | /etc/postgresql/16/main/pg_hba.conf |         133 | host  | {replication} | {all}      | ::1       | ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff | scram-sha-256 |         |
(7 rows)

• Teste as configurações em um ambiente de desenvolvimento antes de aplicá-las em produção.

Ident file

O ident file é um arquivo utilizado pelo PostgreSQL para mapear nomes de usuários do sistema operacional para nomes de usuários do banco de dados. Ele é útil quando você usa o método de autenticação ident, que verifica a identidade do usuário que está tentando se conectar ao banco de dados com base no nome de usuário do sistema operacional.

Para fazer essa autenticação baseada nos usuários do SO, o PostgreSQL consulta o ident file para mapear o nome de usuário do SO para o nome de usuário do banco de dados.

Esse arquivo geralmente é chamado pg_ident.conf e está localizado no mesmo diretório que o arquivo pg_hba.conf (/etc/postgresql/<versão>/<cluster>/pg_hba.conf para sistemas de base Linux). 

Seu conteúdo é simples, com cada linha contendo três colunas:

1. Mapa de identidade: nome de um grupo de mapeamento definido;
2. Nome de usuário do SO: nome do usuário no sistema operacional;
3. Nome de usuário do banco: nome do usuário no banco de dados que corresponde ao usuário do SO. 

Após feita a configuração do arquivo pg_ident.conf, para utilizá-lo basta selecionar como método de autenticação no pg_hba.conf o ident e, então, como última opção da linha de regra, informar o nome do mapa definido no ident file. Exemplo:

mymap   seu_usuario_os   seu_usuario_db

Nesse caso, mymap é o nome do seu mapeamento, seu_usuario_os é o nome do usuário no sistema operacional, e seu_usuario_db é o nome do usuário no banco de dados.

Para aplicar isso no pg_hba.conf, poderíamos incluir essa linha nas regras do arquivo:

host   all	all   192.168.1.10/32   ident   mymap

Sendo que ident é o método escolhido, e a opção extra mymap refere-se ao mapeamento que queremos utilizar (considerando que podemos mapear vários usuários no ident file).

Conclusão

O pg_hba.conf é uma peça fundamental na definição de políticas de acesso ao banco de dados. Ele é relativamente simples de configurar e tem uma sintaxe bastante intuitiva se compararmos com outros bancos de dados por aí. No entanto, conhecer as opções disponíveis é uma condição indispensável para administrar um ambiente de produção de forma minimamente segura. 

Por padrão, as instalações do PostgreSQL vêm apenas habilitadas para permitir conexões locais, o que gera uma certa frustração em novatos. Algumas pessoas, na pressa de colocar o banco de dados no ar, acabam utilizando o método TRUST ou colocando faixas de IPs abertas para o mundo todo com 0.0.0.0/0, o que deixa o servidor completamente vulnerável a ataques. Na mesma linha, você deve utilizar o ALL para usuários, e nomes de bancos de dados devem ser utilizados com moderação. Aqui vale a regra do “menor privilégio possível”. Você deve sempre colocar as regras mais restritas possíveis para permitir que as aplicações e os usuários acessem o banco de dados com segurança. 

Outra tendência forte é utilizar conexões com criptografia SSL para todas as conexões que não forem locais, evitando possíveis ataques de pessoas que ficam escutando o tráfego da sua rede. Isso é tão importante hoje que escrevemos um artigo só sobre isso, que você poderá conferir mais adiante. Portanto, seja cuidadoso e crie regras com prudência. Lembre-se, você pode alterá-las e adicionar quantas linhas forem necessárias depois; e recarregar o arquivo pg_hba.conf sem precisar reiniciar o serviço do PostgreSQL, apenas dando um RELOAD.

Escolhendo hardware para o seu servidor PostgreSQL

Introdução

Agora que já falamos sobre cenários e seus tipos de cargas de dados, chegou o momento de sermos mais específicos e falarmos sobre hardware. A escolha do hardware correto é crucial para a performance e a segurança de um servidor de banco de dados. 
Neste artigo, abordaremos os aspectos mais importantes do hardware para bancos de dados, considerando diferentes cenários de uso: aplicações web, OLTP e Data Warehouse.
Um ponto importante antes de começar a fuçar em diferentes possibilidades é, ao falar de bancos de dados em produção, ter uma postura um pouco mais conservadora. Ninguém gosta de arriscar demais quando falamos em bancos de dados. O prejuízo que se tem no caso de um desastre é alto demais. Então, lembre-se disso ao fazer as suas escolhas. Em ambientes de produção, evite a última moda, o lançamento mais recente, a tecnologia disruptiva, até que ela tenha sido testada e aprovada amplamente pelo mercado. Escolha componentes conhecidos, de fornecedores confiáveis e com robustez comprovada, sempre.

Roteiro:

• Diferenças entre ambientes (teste, homologação e produção)
• CPU
• Memória RAM
• Disco & Cia
• Rede
• Aspectos importantes de hardware para banco de dados
• Hardware para cenários específicos

Diferenças entre ambientes (testes, homologação e produção)

A escolha do hardware para servidores de bancos de dados varia significativamente de acordo com o ambiente em que ele vai rodar. Apesar de cada equipe usar um nome diferente, geralmente os ambientes são resumidos em três categorias:

• Testes ou desenvolvimento: algumas pessoas desenvolvem no seu próprio desktop ou possuem um servidor menor para testes e desenvolvimento. Geralmente, utilizam um hardware bem menor com menos poder de fogo e sem muitos requisitos de segurança. Aqui, o mais importante é a flexibilidade de subir novos ambientes para novas tarefas. É muito comum precisar subir um ambiente de teste novo isolado para desenvolver uma funcionalidade específica. O uso de contêineres também é bem comum;
• Homologação ou QA: aqui os requisitos de desempenho geralmente são importantes. É comum utilizar uma cópia recente da base de produção, com o mesmo volume de dados, na hora de homologar uma nova funcionalidade ou simular um erro encontrado por um usuário. Nesse caso, não queremos apenas saber se alguma coisa funciona ou não, queremos saber se o desempenho é satisfatório, medir a velocidade, fazer testes com carga mais próxima possível da realidade, para evitar sustos na hora de colocar em produção. Por outro lado, os requisitos de segurança do hardware também não são importantes, de forma que não há uma preocupação com alta disponibilidade do hardware, por exemplo;
• Produção: aqui é o nosso ponto focal do artigo. Precisamos tanto de desempenho como de segurança. Aí é que entra o problema da tríade: custo, segurança e desempenho. Você não consegue ter os três ao mesmo tempo, precisa escolher apenas dois! Focaremos boa parte do nosso artigo especificamente nesse ambiente, que é o mais crítico de todos e onde os custos chamam a atenção. Portanto, é importante saber onde investir o seu limitado orçamento para tirar o melhor proveito possível dele. 

CPU

O primeiro ponto em que se pensa quando vamos adquirir um servidor (seja on premise ou na nuvem) para rodar um banco de dados em produção é a CPU. Talvez esse não seja o item mais importante de todos (vamos falar sobre isso adiante), mas certamente costuma ser o primeiro a ser lembrado.

Desempenho 

Do ponto de vista do desempenho, há três pontos importantes para se observar:

• Velocidade do clock da CPU. Quanto maior a velocidade da CPU, mais rapidamente ela vai processar as solicitações dos usuários do banco de dados. Isso é especialmente importante em ambientes com cálculos complexos como IA, Data Science e BI;
• Número de processadores/cores/threads. Se você está num ambiente OLTP ou Web, entenda que cada requisição de usuário vai ocupar uma CPU. Se você possuir várias dezenas de requisições ao mesmo tempo, vai precisar de várias CPUs para processá-las rapidamente. Se o número de requisições for maior que a quantidade de CPUs disponíveis, as requisições vão ficar numa fila de espera e a aplicação terá de ficar aguardando. Num ambiente de Data Science ou BI, o PostgreSQL também poderá quebrar consultas complexas e pesadas em pedaços menores e utilizar uma CPU para cada um desses pedaços, paralisando a solicitação. Dessa forma, possuir mais CPUs irá agilizar solicitações complexas e pesadas através desse tipo de recurso;
• Quantidade de cache L1, L2 e L3. Memória é sempre um bom investimento. A memória interna da CPU é mais rápida que a memória RAM externa que você mesmo instala no servidor. Bancos de dados costumam trabalhar com grandes volumes de dados, e geralmente quanto mais RAM, mais rápido você consegue processar as informações. Operações internas de consultas, como ordenações, hash joins etc., se beneficiam muito de um bom cache na CPU.

Segurança

Do ponto de vista da segurança, o mais importante é evitar processadores utilizados em desktops. Servidores de produção quase sempre operam em regime 24/7, não são desligados nunca. Então, processadores desenvolvidos para servidores têm uma vida útil maior e são feitos para rodar com carga ininterruptamente. Se você utilizar um processador de desktop para rodar no seu servidor 24/7, provavelmente a vida útil dele será menor do que a esperada. A mesma questão se aplica a outros componentes, como memória, discos etc.

CPUs para servidores de produção no mercado hoje

Existem três grandes fornecedores de CPU para servidores no mercado:

• A Intel, fornecedora mais tradicional de CPUs. Esqueça as linhas i3, i5, i7 e i9 da Intel. Em servidores, ela oferece a linha Xeon, que domina o mercado de servidores há uns bons anos. Esses servidores são considerados robustos e rápidos, possuem versões com diferentes velocidades de clock, quantidades de cache e cores. No momento em que este artigo foi escrito, a linha Xeon está na sua 6^a geração e possui processadores com até 144 cores, 3.2 GHz de frequência e 108 MB de cache (vale lembrar que existem vários tipos de cache dentro de uma CPU);
• A AMD é a segunda fornecedora mais conhecida de CPUs, sendo mais popular no mercado de desktops, mas, de uns anos para cá, ela também tem se mostrado competitiva no segmento de servidores. Assim como a Intel, a AMD possui a linha Ryzen e Athlon para desktops, mas no segmento de servidores, vamos olhar para a linha EPYC. Os processadores EPYC, no momento em que este artigo foi escrito, estão na sua 4ª geração, e a Série 9004 possui hoje modelos com até 128 cores, 4.4 GHz de frequência e até 1 GB de cache L3;
• A ARM é uma fabricante líder em processadores para dispositivos embarcados, mas que passou a ser muito utilizada na AWS, devido ao seu baixo custo e baixo consumo de energia, o que pesa consideravelmente quando pensamos num datacenter com milhares de servidores. A linha Neoverse N1 e N2 é dedicada a servidores com até 128 cores.

Memória RAM

Para manipular os dados do seu banco de dados, as informações contidas nas suas tabelas precisam estar na memória RAM antes de serem processadas pela CPU. Num cenário ideal, seria possível guardar todos os dados de todas as tabelas do seu banco de dados na RAM. Assim, todas as operações seriam muito mais rápidas. Infelizmente, isso não é possível na maioria das vezes. Hoje em dia, consideramos que um banco de dados com alguns TBs é de tamanho médio, e um servidor com 1 TB de RAM, embora seja possível e existam modelos assim no mercado, possui um custo nada acessível. Dessa forma, investir em memória costuma ser um ótimo benefício, pois quanto mais o seu banco de dados couber na RAM, maior a chance de você não precisar acessar o disco, que é muito mais lento.

DDR DIMM

A RAM é vendida em módulos com chips colados em ambos os lados de uma pequena placa, chamada de DIMM (Dual In-line Memory Module). Existem vários modelos de memória RAM no mercado com diferentes características. A primeira e mais comum é a velocidade delas. No momento em que este artigo foi escrito, as memórias costumam utilizar o padrão DDR (Double Data Rate), que hoje estão na sua 5^a geração, conhecidas como DDR5, lançadas em 2023 com velocidades entre 4000 MT/s e 8000 MT/s. O padrão DDR4, lançado em 2014, ainda se encontra no mercado e tem velocidades 1600 MT/s e 3200 MT/s. O padrão DDR6 tem lançamento previsto para 2026.

UDIMM, RDIMM e LRDIMM

Existem também os padrões UDIMM, RDIMM e LRDIMM, que se diferenciam pelos mecanismos internos de buffer.

• Memórias UDIMM não possuem buffer (Unbuffered DIMM) e são mais baratas, mas consomem mais energia e são mais instáveis. Além disso, não é possível utilizar grandes quantidades de RAM UDIMM na mesma máquina. Logo, as memórias UDIMM são mais baratas e mais comuns de se encontrar em desktops. Não utilizamos memórias UDIMM em servidores de produção;
• Memórias RDIMM possuem buffer (Registred DIMM), são mais estáveis e podem utilizar vários módulos de memória na mesma máquina com velocidades maiores também. São as mais comuns de se encontrar em servidores. É esse tipo de memória que você deve utilizar no seu ambiente de produção nos dias de hoje;
• Memórias LRDIMM (Load Reduced DIMM) e outras versões proprietárias de fabricantes específicos prometem melhorias e tecnologias específicas para melhorar o desempenho ou o consumo de energia. 

ECC

Memórias em servidores de bancos de dados devem sempre utilizar o padrão ECC (Error Checking and Correcting). Memórias sem ECC têm lá seus mecanismos de detecção de erros, mas não são tão eficientes quanto as que usam ECC. Esse é o padrão mais confiável hoje, utilizado e aprovado pelo mercado há um bom tempo. Não arrisque! Falhas de memória sem ECC podem levar a falhas catastróficas no seu banco de dados.

Discos ou armazenamento não volátil

Os discos são dispositivos de armazenamento fundamentais para servidores de banco de dados, responsáveis por guardar e acessar dados de forma eficiente. Eles variam em tipo, desempenho e capacidade, influenciando diretamente a performance do banco de dados. Os discos são provavelmente o componente que você vai escolher com mais cuidado ao montar um servidor de banco de dados. Possivelmente, será a parte mais cara dele também. O problema fundamental é que, normalmente, as pessoas pensam em discos apenas pela sua capacidade. Aqui temos que pensar não apenas na capacidade (e espaço para acomodar o banco de dados, espaço para ele crescer nos próximos anos, backups etc.), mas também no desempenho, na segurança etc. Bancos de dados exigem muito dos discos, gravam constantemente, lêem o tempo todo e, se qualquer coisa der errado, o prejuízo é ainda maior do que se qualquer outro componente do servidor falhasse, pois pode envolver, além da indisponibilidade do banco de dados, a perda de dados. 

Ao pensar na “persistência dos dados”, temos que pensar em todo o conjunto envolvido no processo: 

• Storages externos
• Controladoras de discos
• RAID
• Discos
• Particionamento de discos

Storages

Em vez de armazenar os dados do seu banco dentro do servidor, você pode ter discos físicos locais dentro do servidor apenas para o sistema operacional e armazenar todos os dados num servidor externo dedicado apenas para lidar com isso, conhecido como storage. Existem diversos tipos no mercado. Os mais caros e poderosos utilizam uma rede separada, a SAN (Storage Area Network), com uma tecnologia específica, como a Fibre Channel ou a InfiniBand, ou o protocolo TCP/IP com o iSCSI. Nesse caso, você terá que utilizar duas placas adaptadoras para se comunicar com essa rede, conhecidas como HBA (Host Bus Adapter). Então existem duas possibilidades: é possível se conectar diretamente no storage, o que chamamos de DAS (Direct Attached Storage), ou numa SAN, utilizando switches e cabos especiais para conectar todos os servidores em um ou mais storages. Toda essa rede utiliza uma arquitetura chamada fabric, onde todos os componentes da rede têm redundância: HBAs, cabos, switches.
Outra opção mais simples, mais barata e bem menos robusta, segura e veloz é utilizar um NAS (Network Attached Storage), que é um storage plugado numa rede TCP/IP normal e que utiliza protocolos como o NFS (Network File System) no Linux. O NAS é uma ótima opção para armazenamento de grandes volumes de dados que não precisam de muita confiabilidade e desempenho. Esse não é o caso dos nossos bancos de dados em produção. Não o utilize em ambientes críticos.

Storages são componentes caros e complexos. Podem ter o tamanho de um simples servidor 4U num rack ou podem ocupar 2, 4, 8 racks full size inteiros. Quando você compra um brinquedinho desses, faz um contrato de suporte com o seu fornecedor por três a cinco anos. Seu equipamento será monitorado remotamente pelo fornecedor. Quando um disco falhar, ele irá bater na sua porta no dia seguinte com um técnico trazendo um disco novo debaixo do braço e vai trocar esse disco sem paralisar a sua operação. Sim, tudo utilizando hot swap e, claro, a tecnologia RAID, que vamos comentar a seguir. Quando acabar o período de contrato do suporte, você vai comprar um novo storage e substituir completamente o antigo, colocando-o para fazer coisas menos nobres, como no ambiente de homologação. Nenhum fornecedor de storage renova o contrato de suporte depois de vencido esse prazo de três a cinco anos. Entende como funciona? Além disso, um storage tem várias vantagens, como oferecer uma quantidade absurda de cache de gravação e leitura, baterias internas e redundantes que garantem o seu funcionamento em caso de falha de energia elétrica, controladoras robustas, capacidade de acomodar centenas de discos físicos e agregá-los de diferentes formas e, por fim, software caríssimo que oferece formas facilitadas de monitoramento, backup etc.

RAID

Técnica que combina múltiplos discos físicos para aumentar a performance e/ou confiabilidade. Diferentes níveis de RAID (como RAID 0, 1, 5, 10) oferecem variações entre tolerância a falhas, velocidade e capacidade de armazenamento. Aqui está um resumo sobre os mais populares:

• JBOD (Just a Bunch of Disks): é o que existia antes do RAID. Você colocava vários discos no servidor, e cada um aparecia com pelo menos uma partição separada. Você tinha que distribuir os dados em tablespaces mapeados para cada disco e sair distribuindo índices e tabelas em tablespaces distintos. Um verdadeiro show de horror e um trabalho interminável. Ninguém mais usa isso, ufa!;
• RAID 0: aumenta o desempenho ao dividir os dados entre vários discos (conhecido como striping), mas não oferece proteção contra falhas. Se um disco falhar, todos os dados são perdidos. Ninguém usa RAID 0 no nível de hardware em produção. Não faça isso, sério! O risco é enorme. No entanto, na nuvem, é comum utilizar RAID 0 por software, uma vez que já se supõe que exista algum tipo de RAID (que ninguém sabe direito qual é) no hardware do fornecedor. Veja que estamos falando de um cenário bem específico, ok?;
• RAID 1: duplica os dados em dois discos (espelhamento). Se um disco falhar, o outro tem uma cópia idêntica dos dados, oferecendo alta segurança, mas sem aumento de desempenho em leitura. Utilizamos o RAID 1 normalmente quando temos apenas dois discos idênticos. Em outros casos, utilizamos o RAID 10;
• RAID 5: distribui os dados e a paridade (informação usada para recuperar dados) entre três ou mais discos. Oferece um certo equilíbrio entre desempenho de leitura, capacidade e segurança. No entanto, para gravação, o RAID 5 tem uma perda considerável de performance, não sendo recomendado para ambientes OLTP. A segurança do RAID 5 também é muito questionável, pois quando um dos discos falha, ao substituir por um novo, é comum que um segundo disco falhe junto. No entanto, se você tiver que lidar com um volume muito grande de dados estáticos e/ou históricos (em que você faz muita leitura e pouca gravação), um bom RAID 5 pode ser uma opção como um segundo RAID, separando os dados mais críticos em um RAID 1 ou RAID 10, por exemplo;
• RAID 6: é como o RAID 5, porém requer pelo menos quatro discos, já que os dados são gravados em dois deles. Suporta falha em dois discos sem perder dados. Apesar de ser um pouco mais seguro que o RAID 5, possui os mesmos problemas que o RAID 5 em termos de desempenho;
• RAID 10 ou RAID 1 + 0: é uma junção do RAID 0 com o RAID 1. Assim você tem a segurança do espelhamento do RAID 1 com a velocidade da distribuição de dados do RAID 0. Você precisa de, no mínimo, quatro discos para fazer um RAID 10 e deve aumentar o número de discos sempre em números pares: 6, 8, 10, 12 etc. 

Se você tem um servidor muito pequeno, comece com um RAID 1. Se tem um servidor maior, pense no RAID 10. Se tem um volume muito grande de dados, pense numa combinação entre RAID 1 ou 10 com um RAID 5 ou 6.

Importante frisar que a técnica RAID não substitui backups de rotina, pois não protege contra todos os tipos de falha, como erros humanos, e não oferece histórico de versões.

Controladoras de disco

Trata-se de hardware dedicado que gerencia a comunicação entre o servidor e os discos. Controladoras RAID são específicas para implementar diferentes níveis de RAID, garantindo melhor desempenho e segurança dos dados. Se você utiliza um storage, ele já deve ter uma excelente controladora de discos embutida, então não precisa se preocupar com isso. Se está na nuvem, menos ainda. Mas se você vai guardar todos os seus discos físicos dentro do seu servidor… precisa, sim, pensar na controladora que vai utilizar. Todo servidor, em geral, tem uma controladora de discos embutida na placa-mãe. Essa controladora embutida é limitada em número de discos suportados, possibilidade de fazer RAID, cache e uso de bateria embutida.
Cada controladora suporta uma interface específica de discos. Desktops utilizavam discos SATA (Serial ATA), e servidores utilizavam o SCSI, Fibre Channel ou Serial Attached SCSI, até que os discos mecânicos passaram a dar lugar aos discos de estado sólido, os SSDs. Hoje em dia, quase ninguém usa mais discos mecânicos, e tudo isso virou de cabeça para baixo. Existem N formatos de discos SSDs e soluções que foram nascendo e morrendo com o tempo. Vale lembrar que os discos SSDs em servidores são bem diferentes dos discos utilizados em desktops. Servidores de grande porte utilizam os discos NVMe (Non Volatile Memory Express), que se conectam através do barramento PCI Express e substituem a arquitetura utilizada em discos mecânicos, a AHCI. 

Atualmente, boa parte das soluções se concentram em placas PCI Express com várias memórias SSD agrupadas e algumas capacidades embutidas de RAID e cache. Processadores para servidores de topo de linha também possuem controladoras embutidas NVMe com capacidade de gerenciar dezenas de discos SSDs. Hoje em dia, se você não vai utilizar um storage externo e quer utilizar vários discos SSDs, é melhor entrar em contato com o seu fornecedor de servidores e conversar com ele sobre as soluções disponíveis. 

Discos mecânicos

São um tanto ultrapassados, mas ainda utilizados em lugares onde se precisa de muito volume, pouco desempenho e baixo custo. Esse não costuma ser o lugar em que são utilizados bancos de dados. Apenas evite!

Discos SSD

Já faz um tempinho (2008) quando cantamos a bola de que os SSDs iriam substituir os discos magnéticos mesmo em servidores de bancos de dados; 15 anos depois, eles viraram padrão de mercado.

É um termo amplo que abrange qualquer dispositivo de armazenamento que tenha uma presença física tangível, incluindo discos magnéticos (HDDs), discos de estado sólido (SSDs), discos ópticos (como CDs e DVDs) e outros tipos de mídia de armazenamento. O termo “disco físico” é frequentemente usado para diferenciar esses dispositivos de discos virtuais ou na nuvem, que não têm uma presença física direta acessível ao usuário.

Discos magnéticos

É um tipo específico de tecnologia de armazenamento, em que os dados são gravados em discos revestidos com material magnético. O HDD (Hard Disk Drive) é o exemplo mais comum de disco magnético. Esses discos são conhecidos por sua capacidade de armazenar grandes volumes de dados a um custo relativamente baixo, mas têm desempenho de leitura e escrita mais lento em comparação com outras tecnologias, como os SSDs.

Discos SSD

Discos SSD definitivamente não são todos iguais. Uma enorme variedade de opções e formatos estão disponíveis no mercado. Temos três questões para se avaliar sobre discos: capacidade, desempenho e segurança. Capacidade é a parte mais simples. Diz respeito ao volume de dados que ele é capaz de armazenar. Nenhum mistério até aí. Velocidade já é um negócio mais manhoso, pois tem várias métricas diferentes. A primeira é a velocidade de transferência, quantos MB/s você consegue transferir. Mas não é tão simples. Essa capacidade muda se o acesso for sequencial ou aleatório. Também muda muito se for para leitura ou escrita. Outro ponto é o número de operações por segundo, medido por IOPS. Esse é um dos principais índices para medir o desempenho de um disco SSD. Novamente, varia bastante quando você está lendo ou gravando. Existem algumas outras métricas, mas essas são as principais.
Quando falamos de segurança em discos SSD, você precisa entender uma coisa importante: cada bit de um disco SSD suporta uma quantidade limitada de ciclos de gravação. Assim, quanto mais vezes você gravar no seu disco, menor será a sua vida útil. Sendo assim, quando você compra um disco SSD, ele vem com uma medida de MTBF (Mean Time Between Failures). Esses testes são feitos em um regime específico de trabalho, então esses números podem mudar muito se você pegar um SSD projetado para ser utilizado em um desktop e rodar um banco de dados 24/7 nele. Ele vai abrir o bico muito antes do esperado e vai deixar você na mão. É por isso que discos SSD para servidores são classificados em três tipos:

• Read intensive, em que o disco vai suportar operações de leitura 24/7 por um bom tempo, mas não vai durar muito tempo se você fizer muitas operações de gravação. Você deve evitar o uso desse tipo de disco em bancos de dados de produção;
• Mixed use, que possui um desempenho melhor em gravação e uma durabilidade maior em ambientes com um volume razoável de escritas. Esse tipo é adequado para bancos de dados em produção em casos genéricos, mas pode ser insuficiente para ambientes OLTP, que sofrem muitas operações de gravação;
• Write intensive: esse é o tipo de disco mais caro e com melhor desempenho e durabilidade em operações de gravação. São ideais para bancos de dados em operação crítica e ambientes OLTP pesados.

Discos na nuvem

Os discos na nuvem referem-se a soluções de armazenamento fornecidas por provedores de serviços em nuvem, como AWS, Azure ou Google Cloud. Esses discos são virtuais, ou seja, não há um hardware físico específico vinculado ao usuário. Eles oferecem alta flexibilidade, escalabilidade e fácil integração com outras soluções na nuvem. Além disso, são frequentemente replicados em diferentes locais geográficos para garantir alta disponibilidade e durabilidade dos dados.
Discos na nuvem são ideais para cenários em que a elasticidade e a gestão simplificada são importantes. Cada fornecedor de nuvem possui diferentes opções de discos ou “block storage” que você pode utilizar em diversas situações. Você vai ter que estudar um pouco sobre cada um e escolher o que melhor lhe atende de acordo com o seu ambiente, mas dificilmente vai saber que tipo de hardware está sendo utilizado embaixo do capô.

Aspectos importantes de hardware para bancos de dados

Para garantir a eficiência e a performance de um banco de dados, é essencial considerar os seguintes componentes de hardware:

• CPU (Processador)
  • Número de núcleos: mais núcleos permitem processar mais transações simultaneamente;
  • Frequência: processadores com alta frequência são melhores para tarefas que requerem alto desempenho por núcleo.

• Memória RAM
  • Quantidade: deve ser suficiente para manter os dados frequentemente acessados na memória, reduzindo a necessidade de acesso ao disco;
  • Velocidade: RAM mais rápida melhora o tempo de resposta das operações.
• Armazenamento

• SSDs: oferecem alta velocidade de leitura e escrita, essencial para a performance do banco de dados;
• IOPS (Operações de Entrada/Saída por Segundo): alta IOPS é crucial para sistemas com alta carga de transações.

1. Rede
   • Largura de banda: necessária para suportar múltiplos acessos simultâneos;
   • Latência: baixa latência garante respostas rápidas.

Claro que a priorização desses componentes vai variar de acordo com o cenário e o tipo de carga de banco de dados, que exploraremos adiante.

Hardware para cenários específicos

OLTP

• Processador: você vai precisar de muitos núcleos para dar conta de muitas conexões simultâneas. Processadores rápidos com mais cache também vão ajudar no processamento de transações complexas, típicas de ambientes OLTP;
• Memória RAM: quanto mais memória melhor, sempre. Quanto mais porcentagem do banco couber na RAM, melhor. Muitas conexões simultâneas também consomem memória para fazer suas operações de consulta, então seja generoso na quantidade de RAM;
• Armazenamento: discos SSD NVMe Write intensive ou mixed use com RAID 1 ou RAID 10 são as melhores opções. 

Web

• Processador: ambientes web costumam lidar com uma quantidade absurda de requisições simultâneas. Foque aqui em ter muitas cores;
• Memória RAM: aqui você com certeza quer cachear a maior parte do seu banco. Mais uma vez seja generoso na quantidade;
• Armazenamento: aqui você deve ter uma quantidade menor de gravações em geral, discos SSD NVMe com RAID 1, 5 ou 10 do tipo read intensive ou mixed use devem resolver bem.

Data Warehouse / BI / Data Science

• Processador: você precisa de mais cores para paralelizar as consultas, mas preste mais atenção na velocidade deles, pois esse tipo de carga costuma exigir cálculos mais complexos;
• Memória RAM: esse tipo de ambiente costuma trabalhar com bases enormes, logo, vai precisar de uma boa quantidade de RAM para acompanhar;
• Armazenamento: aqui a velocidade de gravação não é tão importante, você pode, às vezes, trabalhar com RAID 5 e discos read intensive ou mixed use. Vale a pena notar a frequência e o volume de cargas periódicas que você faz nesse ambiente para dosar melhor a importância das operações de gravação.

Conclusão

Aqui, apenas pincelamos algumas considerações sobre hardware na hora de montar o seu servidor. É claro que não temos uma fórmula mágica. Cada caso é um caso. Além disso, estamos falando de tecnologias em constante evolução, o que vale hoje pode não valer mais amanhã. Mesmo assim, lembre-se de ser conservador e se preocupe com a qualidade dos componentes, pensando em utilizar um hardware mais seguro, com fontes redundantes, ventoinhas redundantes, nobreaks, geradores de energia e até ar-condicionado redundantes.
Segurança é um tema extenso e complexo, mas começa em decisões simples como a de escolher componentes feitos para aguentar o tipo de carga que você espera, em vez de achar que qualquer desktop um pouco melhor vai dar conta do recado.