Guia de Hardware para Firebird

Por Alexey Kovyazin, última atualização: 30 de novembro de 2015

Você pode frequentemente ver a seguinte pergunta em grupos de suporte técnico do Firebird: “Qual é o hardware ideal para o SGBD Firebird?”. Este tópico permanece permanentemente popular porque os requisitos de hardware diferem conforme as tarefas e o próprio hardware muda com o tempo.

Decidimos escrever este guia para fornecer o conhecimento necessário a qualquer pessoa que queira escolher um hardware verdadeiramente eficaz para seu banco de dados Firebird. Para fazer isso, você precisará aprender alguns detalhes básicos sobre como o Firebird, o sistema operacional e, claro, o hardware funcionam.

Um Pouco de Teoria

Para descobrir qual hardware será mais adequado para seu banco de dados Firebird, precisamos entender como o Firebird usa seus componentes: CPU, RAM, HDD/SSD e como esses componentes interagem com o sistema operacional (por exemplo, com o cache de arquivos).

Módulos Funcionais do Servidor Firebird

Primeiramente, vamos analisar os módulos funcionais do Firebird com a ajuda da Figura 1:

Figura 1. Módulos do Firebird

O Firebird inclui os seguintes módulos funcionais principais:

Objetos de metadados: visões, tabelas, índices, gatilhos, procedimentos armazenados e outros objetos de banco de dados. Os objetos de metadados estão localizados no espaço de endereçamento do processo do Firebird (pode ser fbserver, fb_inet_server ou firebird.exe).
O cache de buffers de páginas contém páginas de banco de dados lidas do disco e está localizado no espaço de endereçamento do processo do servidor. O mecanismo de cache de páginas é bastante complexo, então apenas afirmaremos que o Firebird armazena em cache as páginas de banco de dados mais frequentemente usadas.
O Firebird classifica os registros na memória (no espaço de endereçamento do processo do servidor) até que a quantidade de memória usada para todas as operações de classificação simultâneas atinja o limite definido pelo parâmetro TempCacheLimit (firebird.conf). Uma vez que esse limite é excedido, um arquivo temporário (com o sinalizador correspondente do sistema operacional) é criado na pasta de arquivos temporários e é usado para classificação. Se houver RAM livre no sistema, o arquivo de classificação será armazenado em cache pelo sistema operacional e a classificação será realizada na memória.
Tabelas Temporárias Globais (GTTs) são criadas como arquivos temporários no sistema operacional. Se o sistema operacional tiver memória livre, as operações com GTTs são realizadas na RAM.

Operações Básicas com Hardware

Vamos ver como os módulos funcionais do Firebird interagem com os componentes de hardware durante as operações realizadas no curso do trabalho com bancos de dados.

Uma vez que o Firebird é iniciado, o processo do servidor ocupa a quantidade mínima de RAM (alguns megabytes) e não realiza operações intensivas com a CPU ou RAM.

Quando uma conexão é estabelecida com o banco de dados, o servidor começa a ler seus metadados e cria os objetos correspondentes na memória, o que resulta no processo consumindo mais recursos quanto mais tabelas, índices, gatilhos e outros metadados forem usados. O uso de memória aumenta, mas a CPU praticamente não é usada nesta fase.

Quando o cliente começa a executar consultas SQL (incluindo procedimentos armazenados), o servidor realiza as operações correspondentes usando hardware. É possível destacar as seguintes operações básicas que envolvem interação com hardware:

leitura de páginas de banco de dados do disco rígido,
gravação de páginas de banco de dados no disco rígido,
leitura de páginas de banco de dados do cache,
gravação de páginas de banco de dados no cache,
leitura e gravação de dados em tabelas temporárias globais,
processamento de consultas SQL (por exemplo, JOINs),
classificação de registros em conjuntos de resultados.

Cada uma dessas operações requer uma certa quantidade de recursos do sistema. A tabela abaixo mostra o consumo de recursos em unidades intensas (1 significa menos intenso, 10 significa mais intenso):


	Ler uma página do disco	Gravar uma página no disco	Ler uma página do cache de buffers de páginas	Gravar uma página no cache de buffers de páginas	Ler de uma GTT	Gravar em uma GTT	Classificar registros	Processar consultas SQL
CPU	1	1	1	1	1	1	5	10
RAM	5	5	5	5	5	5	5	2
E/S de Disco	10	10	1	1	1	1	1	1

Como você pode ver, as operações que mais consomem recursos são aquelas que envolvem acesso ao disco, pois os discos continuam sendo o componente de hardware mais lento, apesar do progresso dos últimos anos relacionado aos SSDs.

Isso leva a uma das maneiras de otimizar o desempenho que é totalmente relacionada ao hardware - levar todas as operações de leitura e gravação para a RAM. Mas observe que a abordagem de aumentar o cache de páginas não funciona. Trataremos desse assunto em detalhes na seção sobre RAM.

Operações Realizadas Simultaneamente

Normalmente, é necessário escolher hardware para um servidor que atenderá muitos clientes, então é realmente importante entender como o paralelismo das operações é implementado.

Do ponto de vista dos componentes de hardware, podemos falar sobre o uso paralelo da CPU, do disco e da RAM. CPUs modernas têm vários núcleos que podem executar conjuntos de instruções em paralelo, então o servidor do SGBD distribui as operações entre os núcleos, o que significa a conclusão de que quanto mais núcleos a CPU tiver, mais clientes poderão trabalhar neste servidor.

Não é tão simples do ponto de vista dos discos. Quando os discos rígidos tradicionais (HDDs) leem informações, eles movem fisicamente a cabeça sobre o material magnético a uma velocidade finita. Um banco de dados pode ser bastante grande, ou seja, 3 terabytes de tamanho, e se consultas SQL de clientes acessarem seus dados localizados em diferentes áreas do disco em paralelo, a cabeça do disco saltará entre diferentes áreas do disco, desacelerando seriamente as operações de leitura e gravação. Isso aumentará consideravelmente a fila do disco enquanto o restante dos recursos (CPU, RAM) fica ocioso. Claro, o cache do disco (o cache do HDD ou do controlador RAID) compensa essa desaceleração até certo ponto, mas não é suficiente.

Ao contrário dos HDDs tradicionais, as unidades de estado sólido (SSDs) são muito menos propensas à degradação de desempenho em caso de acesso paralelo aos dados. A vantagem de um SSD é especialmente óbvia quando você grava dados em paralelo - nossos testes mostram que um SSD é 7 vezes mais rápido que um disco SATA (link!). No entanto, os SSDs têm alguns problemas que devem ser levados em consideração durante seu uso (veja Selecionando Discos) para evitar lentidão, quebras prematuras e perda de dados.

As operações com RAM são executadas muito rapidamente em computadores modernos, sendo praticamente limitadas apenas pela largura de banda do barramento de dados, portanto, essas operações não atuam como um gargalo, mesmo que haja muitas consultas SQL paralelas.

Fluxos de Dados

Ao executar consultas SQL, o Firebird lê e grava muitos dados, transfere-os entre módulos funcionais e componentes de hardware correspondentes. Para identificar possíveis gargalos, precisamos entender como a troca de dados é realizada. A Figura 2 abaixo nos ajudará com isso:

Figura 2. Fluxos de dados entre RAM e armazenamento persistente

Obviamente, transferir dados do armazenamento persistente para a RAM e vice-versa é a operação que mais consome tempo. Ela cria dois fluxos de dados: leitura/gravação de páginas de dados dos arquivos de banco de dados e leitura/gravação de arquivos de classificação. Como pode haver vários arquivos de classificação e eles podem ser bastante grandes, eles podem criar uma carga bastante pesada nos discos, portanto, é aconselhável direcionar esses fluxos de entrada/saída para discos diferentes.

Backup

O Firebird oferece dois métodos de backup: backup verificado com a ajuda do utilitário gbak e backup incremental não verificado com a ajuda do utilitário nbackup.

Recomendamos que você combine esses métodos de backup: execute o nbackup com frequência (por exemplo, a cada hora, dia e semana) e crie uma cópia de backup verificada todas as noites com a ajuda do gbak.

Qualquer que seja o método de backup usado, o arquivo de banco de dados é lido (todo ou parte dele) e a cópia de backup (completa ou incremental) é gravada. As operações de gravação são realizadas sequencialmente durante o processo de backup, o que significa que discos rígidos comuns e baratos com interface SATA (HDD SATA) serão bons para backup, pois gravam sequencialmente com bastante rapidez.

Selecionando o Hardware Adequado

Agora que temos uma ideia de como o Firebird interage com o hardware, devemos nos aprofundar nos fatores que afetam a escolha de cada componente específico e suas especificações.

Às vezes, as estatísticas reais de um banco de dados específico afetam fortemente a escolha dos componentes de hardware, então usaremos ferramentas do HQbird (o pacote de distribuição profissional do Firebird da IBSurgeon) para obter essas estatísticas. Você pode baixar a versão de avaliação do HQbird em http://hqbird.com/en/hqbird/.

CPU

Ao escolher a CPU, você deve levar em consideração as três coisas a seguir:

Quais consultas predominam no aplicativo,
O número de conexões ativas com o banco de dados em média e sob cargas de pico,
Versão e arquitetura do Firebird.

Quais Consultas Predominam no Aplicativo?

O Firebird sempre executa uma consulta em um núcleo, portanto, consultas complexas e mal otimizadas podem usar um núcleo até 100%, forçando outras consultas para núcleos menos carregados. E quanto mais núcleos houver, menores serão as chances de que toda a CPU seja usada e de que os usuários notem qualquer degradação de desempenho no aplicativo.

Se o aplicativo executa principalmente consultas SQL simples e curtas, todas as consultas são bem otimizadas e nenhuma consulta ad hoc é gerada (por exemplo, para relatórios), a CPU não apresentará gargalo para o desempenho e você pode escolher uma CPU de baixo custo com menos núcleos.

Se o aplicativo contém um gerador de relatórios ou muitas consultas lentas que retornam uma grande quantidade de dados, você precisa de uma CPU com mais núcleos.

O Número de Conexões Ativas com o Banco de Dados em Média e sob Cargas de Pico

O número de conexões (usuários ativos) também influencia a escolha da CPU. Infelizmente, mesmo os desenvolvedores de aplicativos não têm ideia exata de quantas conexões, consultas e transações estão ativas em um determinado momento. Para obter informações mais precisas sobre isso, recomendamos que você use a ferramenta MON$ Logger do HQbird e faça alguns snapshots enquanto ela está em execução, onde você verá quantas conexões estão realmente estabelecidas.

Figura 3. MON$ Logger: número de conexões

Por exemplo, aqui você pode ver que o número de conexões é 296. Obviamente, é muito otimista usar uma CPU de quatro núcleos neste caso, enquanto uma solução de 24 núcleos será perfeitamente adequada. Também é aconselhável contar o número de consultas em execução simultânea, pois as conexões podem estar ociosas sem nenhuma consulta SQL em execução.

Você pode usar a taxa de 10 a 30 conexões por núcleo para estimar aproximadamente o número necessário de núcleos em sua CPU. 10 conexões por núcleo para um aplicativo com consultas principalmente complicadas e lentas, 30 conexões por núcleo para um aplicativo com consultas principalmente simples e bem otimizadas.

Versão e Arquitetura do Firebird

Se você usa o Firebird versão 2.5, observe que deve usar a arquitetura Classic ou SuperClassic para poder distribuir o processamento entre vários núcleos. Na versão 2.5, a arquitetura SuperServer pode usar apenas um núcleo para um banco de dados, portanto, não deve ser usada em sistemas que consomem muitos recursos.

No Firebird versão 3.0, SuperServer, Classic e SuperClassic usam os recursos de CPUs multi-core. O Firebird 3.0 SuperServer mostra o melhor desempenho.

RAM

Ao escolher a RAM, você deve prestar atenção a duas coisas:

o módulo de memória deve ter código de correção de erros (RAM ECC)
a quantidade de RAM deve ser calculada corretamente

RAM ECC

A RAM ECC reduz consideravelmente o número de erros que ocorrem no curso do trabalho com a memória e é fortemente recomendada para uso em sistemas industriais.

Cálculo da Quantidade Necessária de RAM

Para calcular a quantidade de memória, teremos que analisar as peculiaridades das várias arquiteturas do Firebird. O Firebird 2.5 Classic e o Firebird 3.0 Classic executam um processo separado para atender cada conexão, o SuperClassic executa uma thread separada para cada conexão, mas praticamente com a mesma estrutura de consumo de memória - cada conexão tem seu próprio cache de páginas independente.

O Firebird SuperServer executa um processo com um cache de páginas para todas as conexões.

Assim, os seguintes parâmetros afetam o consumo geral de memória:

Número de conexões
Tamanho da página do banco de dados
Tamanho dos metadados (proporcional ao número de tabelas, triggers, stored procedures, etc.; não ajustável; determinado pelo uso físico)
Para Classic e SuperClassic - por conexão
Para SuperServer - por instância de um banco de dados aberto
Tamanho do cache de páginas (determinado pelos parâmetros no cabeçalho do banco de dados ou no firebird.conf ou nas propriedades de uma conexão específica)
Para Classic e SuperClassic - por conexão
Para SuperServer - por instância de um banco de dados aberto
Tamanho do cache de classificação (determinado pelo parâmetro no firebird.conf). Observe que a memória para classificação não é alocada de uma só vez, mas conforme se torna necessária.
Para Classic - por conexão
Para SuperServer e SuperClassic - por processo (ou seja, um cache de classificação)
Para Classic/SuperClassic - tamanho da tabela de locks (geralmente é pequeno, então vamos deixá-lo fora do nosso cálculo).

A empresa IBSurgeon realizou alguns testes e obteve um conjunto de valores ideais para o número de páginas no cache de páginas do Firebird:

Classic/SuperClassic - de 256 a 2000 páginas
SuperServer 2.5 - 10000 páginas
SuperServer 3.0 - 100000 páginas

Com base nesses testes, criamos arquivos de configuração otimizados do Firebird para servidores com 4-6 GB de memória. Você pode baixá-los aqui: /br/optimized-firebird-configuration/

Fórmulas para Calcular a Quantidade Necessária de RAM

Abaixo você pode ver fórmulas usadas para estimar a quantidade aproximada de memória que será necessária para o Firebird. O consumo real de memória pode diferir, pois esta estimativa não leva em conta a quantidade de memória necessária para metadados, para as máscaras de bits dos índices, etc., o que pode aumentar o consumo de memória. No entanto, também é assumido que a memória de classificação será usada ao máximo em todas as conexões, o que geralmente não é o caso.

Quando seu banco de dados já está em uso, você pode observar a quantidade média de memória usada pelo processo do Firebird (com a ajuda do Gerenciador de Tarefas ou do ProcessExplorer).

Estimativa para Classic:

Número de conexões * ( (Número de páginas no cache * Tamanho da página) + Tamanho do cache de classificação )

Exemplo para Classic: suponha que esperamos 100 usuários ativos, o tamanho da página do banco de dados está definido para 8 KB e o número de páginas no cache de páginas está definido para 256, o tamanho do cache de classificação é aumentado de 8 MB (o valor padrão para Classic e SuperClassic) para 64 MB:

((256.8 KB)+64) = 6600 MB

Estimativa para SuperClassic:

Número de conexões * (Número de páginas no cache * Tamanho da página) + Tamanho do cache de classificação

Exemplo para SuperClassic: 100 usuários, o tamanho da página do banco de dados é 8 KB, o número de páginas no cache de páginas é 256, o tamanho do cache de classificação é 1024 MB

100.(256.8 KB) + 1024 MB = 2024 MB

Estimativa para SuperServer:

(Número de páginas no cache * Tamanho da página) + Tamanho do cache de classificação

Exemplo para SuperServer (Firebird 2.5): 1 banco de dados, 100 usuários, o tamanho da página do banco de dados é 8 KB, o número de páginas no cache de páginas é 10000, o tamanho do cache de classificação é 1024 MB:

(10000.8 KB) + 1024 = 1102 MB

Exemplo para SuperServer (Firebird 3.0): 1 banco de dados, 100 usuários, o tamanho da página do banco de dados é 8 KB, o número de páginas no cache de páginas é 100000, o tamanho do cache de classificação é 1024 MB:

(100000.8 KB) + 1024 = 1805 MB

“Memória Excessiva”

O Firebird é frequentemente culpado pelo uso ineficaz de memória - quando o processo em execução do servidor consome uma pequena quantidade de RAM e o restante da memória permanece supostamente não utilizado.

Na verdade, isso não é verdade. Essa conclusão basicamente reside no mal-entendido de como o mecanismo de cache do Firebird funciona e na imperfeição das ferramentas de monitoramento do sistema operacional.

Em primeiro lugar, você deve ter absoluta clareza de que o Firebird usa extensivamente o cache de arquivos do sistema operacional. Quando uma página é carregada no cache de páginas do Firebird, ela passa pelo cache de arquivos do sistema operacional. Quando o Firebird descarrega uma página do seu cache de páginas, o sistema operacional continua mantendo esse trecho do banco de dados em sua RAM, desde que tenha memória livre suficiente.

Figura 4. Níveis de cache: Firebird, SO e armazenamento

No entanto, se você apenas observar, o sistema operacional não mostra a memória alocada para o cache de arquivos como sendo usada. Por exemplo, aqui está a situação típica de distribuição de memória quando o servidor Firebird está em execução, conforme mostrado pelo Gerenciador de Tarefas:

Figura 5. O Gerenciador de Tarefas não mostra o uso do cache de arquivos

Parece que apenas 6,3 GB de 16 GB estão sendo usados.

No entanto, se você usar a ferramenta RAMMap (da SysInternals da Microsoft), tudo parece muito mais lógico:

Figura 6. RAMMap mostra detalhes sobre o uso de memória: arquivos mapeados são bancos de dados em cache

Os arquivos de banco de dados (dbw350.fb252x64.fdb e dbw250.fb252x64.fdb) são armazenados em cache pelo sistema operacional e ocupam toda a memória declarada pelo Gerenciador de Tarefas como livre:

Figura 7. RAMMap: detalhes sobre o uso do cache de arquivos

Portanto, concluímos que o sistema operacional usa efetivamente toda a memória disponível para armazenar em cache o banco de dados, até carregar completamente o banco de dados na memória.

Subsistema de Disco

A configuração correta do subsistema de disco desempenha um papel importante na escolha e configuração de hardware para o Firebird, pois qualquer erro nesta etapa resultará em grandes falhas difíceis de corrigir.

Discos Separados para Tudo

Para reduzir a competição pela entrada/saída de disco entre operações com o arquivo do banco de dados e diminuir as chances de perda simultânea do banco de dados e do backup, é recomendado ter três discos diferentes (ou arrays RAID): um para o banco de dados, um para arquivos temporários e um para criar e armazenar cópias de backup.

Quando dizemos “discos separados”, significa que os fluxos de dados devem passar por canais de entrada/saída diferentes. Se você criar três discos lógicos em um disco físico, não haverá aumento de desempenho. No entanto, se você organizar três discos lógicos em um dispositivo de armazenamento de dados equipado com controladores multicanal, o desempenho provavelmente será aumentado porque o dispositivo pode distribuir fluxos de dados entre os controladores. Às vezes, dedicar um disco separado para armazenar arquivos do sistema operacional e o arquivo de troca do sistema operacional é dito aumentar o desempenho.

SSD para um Banco de Dados

SSD é a melhor escolha para trabalhar com um banco de dados porque garante grande escalabilidade durante entrada/saída paralela. É obrigatório usar discos empresariais com o número aumentado de ciclos de leitura/gravação, caso contrário, é altamente possível que você perca dados devido a uma falha do SSD.

Há algum tempo, os SSDs eram propensos a maior desgaste quando havia pouco espaço livre no disco (menos de 30%). Simplificando, cada modificação em um SSD é gravada em uma nova célula livre, então a falta de espaço livre levava ao aumento do desgaste das células que permaneciam livres e à vida útil mais curta do disco.

Os fabricantes de controladores SSD modernos declaram que esse problema foi resolvido movendo preventivamente dados estáticos e agora o desgaste das células é mais ou menos nivelado. No entanto, as especificações exatas e os algoritmos de operação dos SSDs são mantidos em segredo pelos fabricantes, então ainda recomendamos que você deixe 30% do espaço nos SSDs livre, bem como reduza sua vida útil esperada e planeje substituí-los não menos que uma vez a cada três anos.

Suponha que o tamanho do seu banco de dados seja atualmente 100 GB e cresça 1 GB por mês. Nesse caso, você não deve comprar um SSD de tamanho mínimo (120 GB), mas é melhor escolher o próximo dispositivo na linha de produtos - 250 GB. Ao mesmo tempo, comprar um SSD de 512 gigabytes será um desperdício de dinheiro, pois é aconselhável substituir o disco em três anos.

A melhor prática é dedicar um SSD exclusivamente para trabalhar com o banco de dados, pois qualquer operação de entrada/saída reduz a vida útil dos discos.

Disco para Arquivos Temporários

Como os arquivos temporários aparecem no disco somente quando não há quantidade suficiente de RAM, a melhor maneira é evitar essa situação completamente, é claro. É possível avaliar o número e o tamanho dos arquivos temporários em um sistema de produção apenas monitorando a pasta com arquivos temporários. O FBDataGuard do pacote de distribuição HQbird faz esse tipo de monitoramento. Depois de saber quantos arquivos temporários de classificação são criados no disco e quando são criados, você poderá aumentar a quantidade de RAM e alterar a configuração no firebird.conf.

Em qualquer caso, o Firebird exige que você especifique a pasta onde os arquivos temporários serão armazenados. Normalmente, o padrão é deixado inalterado, ou seja, a pasta do sistema operacional para arquivos temporários é usada. Se a RAM livre for suficiente, essa é uma boa escolha.

No entanto, há outra questão importante sobre a localização dos arquivos temporários no disco - é a criação de índices ao restaurar uma cópia de backup verificada (criada com o utilitário gbak). Quando um índice é criado, um arquivo temporário contendo todas as chaves desse índice também é criado. Se o banco de dados for bastante grande, o tamanho do índice para alguma tabela grande também pode ser bastante grande. Por exemplo, o índice da maior tabela contendo 3,2 bilhões de registros em um banco de dados de 1 terabyte é de 29 GB, mas foram necessários 180 GB de espaço livre para criar esse índice:

Para evitar a falta de espaço livre no disco do sistema, é possível especificar mais um disco como espaço reservado adicional no firebird.conf:

TempDirectories =C:\temp; H:\Temp

Se não houver espaço no primeiro disco, o Firebird continuará a usar o segundo disco para arquivos temporários e assim por diante.

HDD para Backups

HDDs regulares com interface SATA ou nSAS serão adequados para criar e armazenar cópias de backup. Eles garantem operações rápidas de gravação e leitura sequenciais para arquivos de backup e são baratos o suficiente para não economizar em seu tamanho e manter várias cópias de backup.

Os discos para cópias de backup devem sempre ter espaço livre extra: o tamanho da cópia de backup mais recente + 10%. Nesse caso, é possível criar uma nova cópia de backup, garantir que o processo de backup seja concluído com sucesso (esse processo pode levar várias horas para um banco de dados com tamanho de vários terabytes) e somente depois disso excluir a cópia de backup anterior.

Se você excluir a cópia de backup anterior antes que a nova seja criada, é possível que nenhuma nova cópia de backup seja criada enquanto a antiga já foi excluída e o banco de dados seja corrompido, por exemplo, devido a uma falha de disco.

Se você usar o método de backup recomendado acima (a combinação de backup incremental de três níveis e backup verificado uma vez por dia armazenando apenas uma cópia mais recente), use a seguinte fórmula para calcular o espaço mínimo para backup:

Tamanho_do_banco*3+0.2.Tamanho_do_banco

Vamos considerar o seguinte exemplo de cálculo de espaço necessário para backup:

Suponha que temos um banco de dados de 100 GB para o qual armazenamos backup incremental de três níveis (semana-dia-hora - uma cópia de cada) e uma cópia de backup verificado diário. Nesse caso, as cópias de backup ocuparão o seguinte espaço:

Nbackup_level_0.semanal - 100 GB
Nbackup_level_1.diário - 5 GB (aproximadamente)
Nbackup_level_2.horário - 200 MB (aproximadamente)
Backup verificado diário - 100 GB (aproximadamente)
Além disso, você precisa de 110 GB reservados para poder criar a próxima cópia de backup.

Total - 316 GB.

! o tamanho do arquivo incremental de primeiro nível ou superior depende do número de páginas modificadas desde a última execução do nbackup. O tamanho desses arquivos só pode ser determinado experimentalmente, pois a quantidade de alterações em um banco de dados depende dos aplicativos.

Naturalmente, a estimativa de espaço para backup deve levar em conta o possível aumento anormal no tamanho do banco de dados e, correspondentemente, aumentar a quantidade de espaço livre; caso contrário, o processo de backup pode ser interrompido inesperadamente devido à falta de espaço.

Naturalmente, ferramentas inteligentes de backup (FBDataGuard da HQbird) perceberão a falta de espaço para as cópias de backup e enviarão a mensagem correspondente ao administrador.

HDD para um Banco de Dados

Um SSD pode se tornar uma solução cara demais, ou o banco de dados pode ser grande demais, e você terá que usar métodos menos caros. Nesse caso, você deve usar um HDD com interface SAS. Se não for possível, use discos SATA com interface nSAS ou a opção mais barata - discos SATA comuns.

Para aumentar a velocidade (e também a confiabilidade - veja abaixo) dos discos rígidos, você deve combiná-los em RAID10. RAID10 é uma combinação de blocos espelhados (RAID1) e distribuídos (RAID0). Um bom controlador RAID bem configurado com cache grande é uma boa alternativa aos SSDs.

Confiabilidade e RAID

Naturalmente, é necessário aumentar a confiabilidade do subsistema de discos combinando os discos em RAID em todas as variantes mencionadas acima (exceto para o disco dedicado exclusivamente a arquivos temporários).

• Para SSDs, certifique-se de usar RAID1 - ou seja, dois discos espelhados nos quais as alterações são gravadas simultaneamente, o que torna as chances de perder todos os dados consideravelmente menores. RAID 10 composto por SSDs provavelmente será redundante, pois o barramento RAID limitará a taxa de transferência. Por exemplo, a interface de 6 Gbit/s tem uma taxa de transferência de 600 megabytes por segundo, enquanto os SSDs únicos modernos já atingiram essa velocidade. Assim, obteremos o mesmo limite de 600 MB/s para RAID 10.

Exceto que você pode usar PCI Express 3.0 para combinar SSDs em RAID 10, pois a taxa de transferência desse barramento já é de 16 gigabits por segundo ou mais.

• Se você usar HDDs para fins de backup, é suficiente usar RAID1, que garantirá a segurança das cópias de backup e a velocidade aceitável de leitura e gravação.

• HDDs usados para um banco de dados devem ser combinados em RAID10 (pelo menos 4 discos), que fornecem a combinação ideal de custo, confiabilidade e desempenho. Alguns usuários também usam RAID5, sacrificando o desempenho por mais espaço.

Configuração de RAID para Firebird

Primeiro de tudo, você deve garantir que haja uma unidade de bateria de backup (BBU) devidamente carregada no RAID. Se não houver essa unidade de bateria, a maioria dos RAIDs muda para o modo de gravação segura (o cache do disco é completamente desabilitado), que fornece uma velocidade de entrada/saída menor do que um disco SATA comum!

Esse fato causa a maioria das mensagens frustradas ao suporte técnico de usuários que compraram um servidor caro e descobriram que ele funciona mais devagar do que um computador desktop. Infelizmente, alguns fornecedores não incluem unidades de bateria por padrão; por isso, é a primeira coisa que você deve verificar e corrigir, se necessário.

Em seguida, você deve configurar o cache de leitura e gravação. Frequentemente, o cache está desabilitado por padrão e, se você quiser tornar o RAID bastante rápido, precisa habilitar o cache.

Além de habilitar o cache, você deve verificar como ele funciona - pode ser write through (gravação direta) ou write back (gravação diferida). A maneira rápida de trabalhar com cache é write back - nesse caso, quaisquer alterações são gravadas no controlador de cache e, depois de um tempo, diretamente no disco.

Você pode usar ferramentas dos fabricantes fornecidas com o RAID para verificar a unidade de bateria, o cache e o modo.

Controladores RAID modernos também podem ajustar finamente o cache - ele pode ser ajustado para facilitar a leitura ou a gravação. Normalmente, é dividido em 50%/50% para leitura e gravação.

Para descobrir exatamente como configurar o cache, você também pode usar a ferramenta MON$ Logger do pacote avançado de distribuição da HQbird. Ela mostra a proporção entre operações de leitura e gravação (agregadas desde o momento da primeira conexão ao servidor):

Figura 8. HQbird MON$Logger: proporção de leitura/gravação

Como você pode ver, há muito mais operações de leitura do que de gravação neste exemplo, então faz sentido configurar o controlador RAID para 80% de operações de leitura e 20% de operações de gravação.

SAN e bancos de dados

Os storages integrados tornaram-se populares recentemente. Eles incluem um conjunto de discos flexivelmente personalizável (todos os tipos de RAID) com recursos avançados de cache. Normalmente, os SANs têm vários controladores de entrada/saída, o que possibilita atender vários servidores simultaneamente e trabalhar de forma bastante rápida.

Muitas organizações compram SANs e os usam em seu trabalho com bancos de dados Firebird. Se um SAN estiver configurado corretamente, é possível alcançar um bom desempenho. Você deve levar em consideração os seguintes pontos se usar SAN:

Vários controladores de disco de alto desempenho que fornecem uma troca de dados multicanal devem estar disponíveis.
Unidades de bateria de backup (BBU) devem estar presentes, se previstas no projeto.
Os discos do banco de dados devem ser combinados em RAID10.
O cache deve estar habilitado e o modo de gravação deve ser alterado para write back.
Se vários computadores estiverem conectados ao SAN, cada um deles deve ter seu próprio controlador.
Os drivers mais recentes do SAN devem estar instalados. Já encontramos casos em que drivers mais recentes proporcionaram um aumento de 30% no desempenho.
Se houver vários discos lógicos em um SAN (para bancos de dados, cópias de backup, sistema operacional), eles terão canais de entrada/saída diferentes. Tentar usar um único canal para todos os discos resultará em menor desempenho.
Da mesma forma, se vários servidores e bancos de dados usarem um SAN ao mesmo tempo, o desempenho pode ser menor devido ao aumento da largura de banda dos controladores de entrada/saída.
Métodos combinados são frequentemente usados - quando o sistema operacional e os arquivos temporários são armazenados em discos locais, enquanto o banco de dados e os arquivos de backup são armazenados em um SAN.

Frequentemente, os SANs são usados como “dois servidores - um SAN” para criar um cluster à prova de falhas. Deve-se notar que tal cluster pode resolver problemas relacionados apenas a falhas de hardware em um dos servidores, alternando para o segundo servidor imediatamente. Se o problema estiver relacionado ao SAN ou ao próprio banco de dados, essa solução não ajudará.

Para construir uma solução verdadeiramente à prova de falhas, você deve usar soluções que repliquem dados entre duas instâncias de banco de dados. Você pode entrar em contato com [email protected] para saber mais sobre as soluções disponíveis para Firebird.

Breves Conclusões e Recomendações

Vamos resumir as conclusões e recomendações para Firebird em relação ao hardware.

CPUs multi-core devem ser usadas para atender a um grande número de usuários.
A quantidade mínima de RAM é calculada com base no número de usuários e na configuração do banco de dados; o excesso de RAM será efetivamente usado pelo sistema operacional para armazenar em cache o arquivo do banco de dados.
Use discos separados para bancos de dados, arquivos temporários e arquivos de backup.
Prefira usar SSDs para bancos de dados.
Reserve pelo menos 30% de espaço livre nos SSDs.
É aconselhável dedicar um disco ao banco de dados.
Use SSDs empresariais (com muitos ciclos de gravação/leitura).
Certifique-se de usar RAID.
Para SSD - RAID 1, para HDD - RAID10, para HDD de backup - RAID1. i. SAS, SATA, nSAS
Certifique-se de que a bateria do RAID esteja presente e carregada.
Certifique-se de que esteja alternado para write back.
Alguns controladores RAID já têm o tamanho do cache configurado, por exemplo, 75% para leitura, 25% para gravação, ou 50/50 etc. Portanto, é necessário instalar o MON$Logger - o software que controlará os parâmetros do RAID, verificar a proporção de leitura/gravação e alterar as configurações do RAID.
Há prós e contras no uso de SANs. Para aproveitar ao máximo, você deve configurar o SAN corretamente.
Para construir uma solução à prova de falhas, você precisa usar soluções com réplicas executadas em servidores diferentes.

Contatos

A empresa IBSurgeon/IBase.ru vem desenvolvendo um pacote avançado de distribuição HQbird para empresas, fornecendo suporte técnico complexo para Firebird e desenvolvendo pacotes de distribuição personalizados, bem como resolvendo outros problemas complicados.

A IBSurgeon também oferece o serviço de Otimização de Firebird para melhorar o desempenho de bancos de dados Firebird.

Entre em contato conosco: [email protected]