Guida Hardware Firebird

Автор: Алексей Ковязин, последнее обновление: 30 ноября 2015 года

В группах технической поддержки Firebird часто можно увидеть такой вопрос: «Какое аппаратное обеспечение выбрать для СУБД Firebird?». Эта тема остается постоянно популярной, потому что требования к аппаратному обеспечению зависят от задач, а само оборудование со временем меняется.

Мы решили написать это руководство, чтобы предоставить необходимые знания всем, кто хочет выбрать по-настоящему эффективное аппаратное обеспечение для своей базы данных Firebird. Для этого вам придется изучить некоторые базовые детали того, как работают Firebird, операционная система и, конечно же, аппаратное обеспечение.

Немного теории

Чтобы выяснить, какое аппаратное обеспечение лучше всего подойдет для вашей базы данных Firebird, мы должны понять, как Firebird использует свои компоненты: процессор, оперативную память, жесткий диск/SSD и как эти компоненты взаимодействуют с операционной системой (например, с файловым кэшем).

Функциональные модули сервера Firebird

Прежде всего, мы рассмотрим функциональные модули Firebird с помощью рисунка 1:

Рисунок 1. Модули Firebird

Firebird включает следующие основные функциональные модули:

Объекты метаданных: представления, таблицы, индексы, триггеры, хранимые процедуры и другие объекты базы данных. Объекты метаданных расположены в адресном пространстве процесса Firebird (это может быть fbserver, fb_inet_server или firebird.exe).
Кэш буферов страниц содержит страницы базы данных, прочитанные с диска, и расположен в адресном пространстве серверного процесса. Механизм кэширования страниц довольно сложен, поэтому мы лишь отметим, что Firebird кэширует наиболее часто используемые страницы базы данных.
Firebird сортирует записи в памяти (в адресном пространстве серверного процесса), пока объем памяти, используемой для всех одновременных операций сортировки, не достигнет предела, установленного параметром TempCacheLimit (firebird.conf). После превышения этого предела в папке с временными файлами создается временный файл (с соответствующим флагом операционной системы), который используется для сортировки. Если в системе есть свободная оперативная память, файл сортировки будет кэшироваться операционной системой, и сортировка будет выполняться в памяти.
Глобальные временные таблицы (GTT) создаются как временные файлы в операционной системе. Если у операционной системы есть свободная память, операции с GTT выполняются в оперативной памяти.

Основные операции с аппаратным обеспечением

Давайте посмотрим, как функциональные модули Firebird взаимодействуют с аппаратными компонентами во время операций, выполняемых в процессе работы с базами данных.

После запуска Firebird серверный процесс занимает минимальный объем оперативной памяти (несколько мегабайт) и не выполняет интенсивных операций с процессором или оперативной памятью.

Когда устанавливается соединение с базой данных, сервер начинает читать ее метаданные и создавать соответствующие объекты в памяти, что приводит к тому, что процесс потребляет тем больше ресурсов, чем больше таблиц, индексов, триггеров и других метаданных используется. Использование памяти увеличивается, но на этом этапе процессор практически не задействован.

Когда клиент начинает выполнять SQL-запросы (включая хранимые процедуры), сервер выполняет соответствующие операции с использованием аппаратного обеспечения. Можно выделить следующие основные операции, связанные с взаимодействием с аппаратным обеспечением:

чтение страниц базы данных с жесткого диска,
запись страниц базы данных на жесткий диск,
чтение страниц базы данных из кэша,
запись страниц базы данных в кэш,
чтение данных из глобальных временных таблиц и запись в них,
обработка SQL-запросов (например, JOIN),
сортировка записей в результирующих наборах.

Каждая из этих операций требует определенного объема системных ресурсов. В таблице ниже показано потребление ресурсов в интенсивных единицах (1 означает наименее интенсивно, 10 - наиболее интенсивно):


	Чтение страницы с диска	Запись страницы на диск	Чтение страницы из кэша буферов страниц	Запись страницы в кэш буферов страниц	Чтение из GTT	Запись в GTT	Сортировка записей	Обработка SQL-запросов
CPU	1	1	1	1	1	1	5	10
RAM	5	5	5	5	5	5	5	2
Дисковый ввод-вывод	10	10	1	1	1	1	1	1

Как видите, наиболее ресурсоемкими являются операции, связанные с доступом к диску, поскольку диски остаются самым медленным аппаратным компонентом, несмотря на прогресс последних лет, связанный с SSD.

Это приводит к одному из способов оптимизации производительности, который полностью связан с аппаратным обеспечением, - перенести все операции чтения-записи в оперативную память. Но обратите внимание, что подход с увеличением кэша страниц не работает. Мы подробно рассмотрим этот вопрос в разделе об оперативной памяти.

Одновременно выполняемые операции

Обычно необходимо выбирать аппаратное обеспечение для сервера, который будет обслуживать множество клиентов, поэтому очень важно понимать, как реализован параллелизм операций.

С точки зрения аппаратных компонентов мы можем говорить о параллельном использовании процессора, диска и оперативной памяти. Современные процессоры имеют несколько ядер, которые могут выполнять наборы инструкций параллельно, поэтому сервер СУБД распределяет операции между ядрами, что означает вывод: чем больше ядер у процессора, тем больше клиентов смогут работать на этом сервере.

С точки зрения дисков все не так просто. Когда традиционные жесткие диски (HDD) считывают информацию, они физически перемещают головку над магнитным материалом с некоторой конечной скоростью. База данных может быть довольно большой, например, 3 терабайта, и если SQL-запросы от клиентов параллельно обращаются к данным, расположенным в разных областях диска, головка диска будет прыгать между разными областями, что серьезно замедлит операции чтения и записи. Это значительно увеличит очередь диска, в то время как остальные ресурсы (процессор, оперативная память) будут простаивать. Конечно, дисковый кэш (кэш HDD или RAID-контроллера) в некоторой степени компенсирует это замедление, но этого недостаточно.

В отличие от традиционных HDD, твердотельные накопители (SSD) гораздо менее подвержены деградации производительности при параллельном доступе к данным. Преимущество SSD особенно очевидно при параллельной записи данных - наши тесты показывают, что SSD в 7 раз быстрее, чем SATA-диск (ссылка!). Однако у SSD есть некоторые проблемы, которые необходимо учитывать при их использовании (см. «Выбор дисков»), чтобы избежать замедлений, преждевременных поломок и потери данных.

Операции с оперативной памятью на современных компьютерах выполняются очень быстро, они практически ограничены только пропускной способностью шины данных, поэтому эти операции не являются узким местом, даже если выполняется много параллельных SQL-запросов.

Потоки данных

При выполнении SQL-запросов Firebird читает и записывает много данных, передавая их между функциональными модулями и соответствующими аппаратными компонентами. Чтобы выявить возможные узкие места, нам нужно понять, как осуществляется обмен данными. Рисунок 2 ниже поможет нам в этом:

Рисунок 2. Потоки данных между оперативной памятью и постоянным хранилищем

Очевидно, что передача данных из постоянного хранилища в оперативную память и обратно является самой трудоемкой операцией. Она создает два потока данных: чтение/запись страниц данных из файлов базы данных и чтение/запись файлов сортировки. Поскольку файлов сортировки может быть несколько и они могут быть довольно большими, они могут создавать значительную нагрузку на диски, поэтому желательно направлять эти потоки ввода-вывода на разные диски.

Резервное копирование

Firebird предлагает два метода резервного копирования: проверенное резервное копирование с помощью утилиты gbak и непроверенное инкрементальное резервное копирование с помощью утилиты nbackup.

Мы рекомендуем комбинировать эти методы резервного копирования: запускать nbackup часто (например, каждый час, день и неделю) и создавать проверенную резервную копию каждую ночь с помощью gbak.

Какой бы метод резервного копирования вы ни использовали, файл базы данных читается (целиком или частично) и записывается резервная копия (полная или инкрементальная). Операции записи выполняются последовательно во время процесса резервного копирования, что означает, что обычные недорогие жесткие диски с интерфейсом SATA (HDD SATA) будут хороши для резервного копирования, поскольку они последовательно записывают довольно быстро.

Выбор подходящего аппаратного обеспечения

Теперь, когда у нас есть представление о том, как Firebird взаимодействует с аппаратным обеспечением, мы должны остановиться на факторах, влияющих на выбор каждого конкретного компонента и его характеристик.

Иногда фактическая статистика конкретной базы данных сильно влияет на выбор аппаратных компонентов, поэтому мы будем использовать инструменты из HQbird (профессионального дистрибутива Firebird от IBSurgeon), чтобы получить эту статистику. Вы можете скачать пробную версию HQbird по адресу http://hqbird.com/en/hqbird/.

CPU

При выборе процессора следует учитывать три вещи:

Какие запросы преобладают в приложении,
Количество активных подключений к базе данных в среднем и при пиковых нагрузках,
Версия и архитектура Firebird.

Какие запросы преобладают в приложении?

Firebird всегда выполняет один запрос на одном ядре, поэтому сложные и плохо оптимизированные запросы могут использовать одно ядро до 100%, вытесняя другие запросы на менее загруженные ядра, и чем больше ядер, тем ниже вероятность того, что весь процессор будет загружен и пользователи заметят ухудшение производительности приложения.

Если приложение в основном выполняет простые короткие SQL-запросы, все запросы хорошо оптимизированы и не генерируются ad hoc-запросы (например, для отчетов), процессор не будет узким местом для производительности, и вы можете выбрать недорогой процессор с меньшим количеством ядер.

Если приложение содержит генератор отчетов или много медленных запросов, возвращающих большой объем данных, вам нужен процессор с большим количеством ядер.

Количество активных подключений к базе данных в среднем и при пиковых нагрузках

Количество подключений (активных пользователей) также влияет на выбор процессора. К сожалению, даже разработчики приложений не имеют точного представления о том, сколько подключений, запросов и транзакций активно в конкретный момент. Чтобы получить более точную информацию об этом, мы рекомендуем использовать инструмент MON$ Logger из HQbird и сделать несколько снимков во время его работы, где вы увидите, сколько подключений фактически установлено.

Рисунок 3. MON$ Logger: количество подключений

Например, здесь видно, что количество подключений равно 296. Очевидно, что в этом случае слишком оптимистично использовать четырехъядерный процессор, в то время как 24-ядерное решение будет вполне приемлемым. Также желательно подсчитать количество одновременно выполняющихся запросов, поскольку подключения могут быть неактивными без выполняемых SQL-запросов.

Вы можете использовать соотношение от 10 до 30 подключений на 1 ядро для приблизительной оценки необходимого количества ядер в вашем процессоре. 10 подключений на ядро для приложения с преимущественно сложными и медленными запросами, 30 подключений на ядро для приложения с преимущественно простыми хорошо оптимизированными запросами.

Версия и архитектура Firebird

Если вы используете Firebird версии 2.5, обратите внимание, что для распределения обработки между несколькими ядрами следует использовать архитектуру Classic или SuperClassic. В версии 2.5 архитектура SuperServer может использовать только одно ядро для одной базы данных, поэтому ее не следует использовать в системах, потребляющих много ресурсов.

В Firebird версии 3.0 SuperServer, Classic и SuperClassic используют возможности многоядерных процессоров. Firebird 3.0 SuperServer показывает наилучшую производительность.

Оперативная память

При выборе оперативной памяти следует обратить внимание на две вещи:

модуль памяти должен иметь код исправления ошибок (ECC RAM)
объем оперативной памяти должен быть правильно рассчитан

ECC RAM

ECC RAM значительно снижает количество ошибок, возникающих при работе с памятью, и настоятельно рекомендуется для использования в промышленных системах.

Calcolo della Quantità di RAM Necessaria

Per calcolare la quantità di memoria, dobbiamo esaminare le peculiarità delle varie architetture di Firebird. Firebird 2.5 Classic e Firebird 3.0 Classic eseguono un processo separato per servire ogni connessione, SuperClassic esegue un thread separato per ogni connessione, ma praticamente con la stessa struttura di consumo di memoria - ogni connessione ha la propria cache di pagine indipendente.

Firebird SuperServer esegue un unico processo con una sola cache di pagine per tutte le connessioni.

Pertanto, i seguenti parametri influenzano il consumo complessivo di memoria:

Numero di connessioni
Dimensione della pagina del database
Dimensione dei metadati (proporzionale al numero di tabelle, trigger, procedure memorizzate, ecc.; non regolabile; determinata dall’uso fisico)
Per Classic e SuperClassic - per connessione
Per SuperServer - per istanza di un database aperto
Dimensione della cache di pagine (determinata dai parametri nell’intestazione del database o in firebird.conf o nelle proprietà di una particolare connessione)
Per Classic e SuperClassic - per connessione
Per SuperServer - per istanza di un database aperto
Dimensione della cache di ordinamento (determinata dal parametro in firebird.conf). Nota che la memoria per l’ordinamento non viene allocata tutta in una volta ma solo quando necessario.
Per Classic - per connessione
Per SuperServer e SuperClassic - per processo (cioè, una sola cache di ordinamento)
Per Classic/SuperClassic - dimensione della tabella di lock (di solito è piccola, quindi la escluderemo dal nostro calcolo).

La società IBSurgeon ha eseguito alcuni test e ha ottenuto un insieme di valori ottimali per il numero di pagine nella cache di pagine di Firebird:

Classic/SuperClassic - da 256 a 2000 pagine
SuperServer 2.5 - 10000 pagine
SuperServer 3.0 - 100000 pagine

Basandoci su questi test, abbiamo creato file di configurazione Firebird ottimizzati per server con 4-6 GB di memoria. Puoi scaricarli qui: /it/optimized-firebird-configuration/

Formule per il Calcolo della Quantità di RAM Necessaria

Di seguito puoi vedere le formule utilizzate per stimare la quantità approssimativa di memoria che sarà richiesta da Firebird. Il consumo effettivo di memoria può differire poiché questa stima non tiene conto della quantità di memoria richiesta per i metadati, per le maschere di bit degli indici, ecc., che possono aumentare il consumo di memoria. Tuttavia, si presume anche che la memoria di ordinamento sarà utilizzata al massimo in tutte le connessioni, cosa che di solito non accade.

Quando il tuo database è già in uso, puoi osservare la quantità media di memoria utilizzata dal processo Firebird (con l’aiuto di TaskManager o ProcessExplorer).

Stima per Classic:

Numero di connessioni * ( (Numero di pagine in cache * Dimensione pagina) + Dimensione cache di ordinamento )

Esempio per Classic: supponiamo di aspettarci 100 utenti attivi, la dimensione della pagina del database è impostata a 8 KB e il numero di pagine nella cache di pagine è impostato a 256, la dimensione della cache di ordinamento è aumentata da 8 MB (il valore predefinito per Classic e SuperClassic) a 64 MB:

((256.8 KB)+64) = 6600 MB

Stima per SuperClassic:

Numero di connessioni * (Numero di pagine in cache * Dimensione pagina) + Dimensione cache di ordinamento

Esempio per SuperClassic: 100 utenti, dimensione pagina del database 8 KB, numero di pagine nella cache di pagine 256, dimensione cache di ordinamento 1024 MB

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

Stima per SuperServer:

(Numero di pagine in cache * Dimensione pagina) + Dimensione cache di ordinamento

Esempio per SuperServer (Firebird 2.5): 1 database, 100 utenti, dimensione pagina del database 8 KB, numero di pagine nella cache di pagine 10000, dimensione cache di ordinamento 1024 MB:

(10000.8 KB) + 1024 = 1102 MB

Esempio per SuperServer (Firebird 3.0): 1 database, 100 utenti, dimensione pagina del database 8 KB, numero di pagine nella cache di pagine 100000, dimensione cache di ordinamento 1024 MB:

(100000.8 KB) + 1024 = 1805 MB

“Memoria Eccessiva”

Firebird è spesso accusato di un uso inefficiente della memoria - quando il processo in esecuzione del server consuma una piccola quantità di RAM e il resto della memoria rimane presumibilmente inutilizzato.

In realtà, non è vero. Questa conclusione si basa fondamentalmente su un fraintendimento del funzionamento del meccanismo di caching di Firebird e sull’imperfezione degli strumenti di monitoraggio del sistema operativo.

Prima di tutto, devi essere assolutamente chiaro che Firebird utilizza estesamente la cache dei file del sistema operativo. Quando una pagina viene caricata nella cache di pagine di Firebird, passa attraverso la cache dei file del sistema operativo. Quando Firebird scarica una pagina dalla sua cache di pagine, il sistema operativo continua a mantenere questo pezzo del database nella sua RAM, purché abbia abbastanza memoria libera.

Figura 4. Livelli di cache: Firebird, OS e storage

Tuttavia, se guardi semplicemente, il sistema operativo non mostra la memoria allocata alla cache dei file come utilizzata. Ad esempio, ecco la tipica situazione di distribuzione della memoria quando il server Firebird è in esecuzione, come mostrato da TaskManager:

Figura 5. TaskManager non mostra l’uso della cache dei file

Sembra come se solo 6,3 GB su 16 GB fossero utilizzati.

Tuttavia, se usi lo strumento RAMMap (da SysInternals di Microsoft), tutto appare molto più logico:

Figura 6. RAMMap mostra dettagli sull’uso della memoria: i file mappati sono database in cache

I file del database (dbw350.fb252x64.fdb e dbw250.fb252x64.fdb) sono memorizzati nella cache dal sistema operativo e occupano l’intera memoria dichiarata come libera da TaskManager:

Figura 7. RAMMap: dettagli sull’uso della cache dei file

Da qui concludiamo che il sistema operativo utilizza efficacemente tutta la memoria disponibile per memorizzare nella cache il database fino a caricare completamente il database in memoria.

Sottosistema Disco

La corretta configurazione del sottosistema disco gioca un ruolo importante nella scelta e configurazione dell’hardware per Firebird perché qualsiasi errore in questo passaggio comporterà gravi guasti difficili da correggere.

Dischi Separati per Tutto

Per ridurre la competizione per l’input/output del disco tra le operazioni con il file del database e per diminuire le possibilità di perdita simultanea del database e dei backup, si consiglia di avere tre dischi diversi (o array RAID): uno per il database, uno per i file temporanei e uno per creare e conservare le copie di backup.

Quando diciamo “dischi separati”, significa che i flussi di dati devono passare attraverso canali di input/output diversi. Se crei tre dischi logici su un disco fisico, non ci sarà alcun aumento delle prestazioni. Tuttavia, se organizzi tre dischi logici su un dispositivo di archiviazione dotato di controller multicanale, le prestazioni saranno molto probabilmente aumentate perché il dispositivo può distribuire i flussi di dati tra i controller. A volte si dice che dedicare un disco separato alla memorizzazione dei file di sistema operativo e del file di swap del sistema operativo aumenti le prestazioni.

SSD per un Database

L’SSD è la scelta migliore per lavorare con un database perché garantisce un’ottima scalabilità durante l’input/output parallelo. È obbligatorio utilizzare dischi enterprise con un numero aumentato di cicli di lettura/scrittura, altrimenti è molto probabile che tu perda dati a causa di un guasto dell’SSD.

Qualche tempo fa, gli SSD erano soggetti a un’usura aumentata nel caso in cui rimanesse poco spazio libero sul disco (meno del 30%). In parole semplici, ogni modifica su un SSD viene scritta in una nuova cella libera, quindi la mancanza di spazio libero portava a un’usura aumentata delle celle che rimanevano libere e a una durata di vita più breve del disco.

I produttori dei moderni controller SSD dichiarano che questo problema è stato risolto spostando preventivamente i dati statici e ora l’usura delle celle è più o meno livellata. Tuttavia, le specifiche esatte e gli algoritmi di funzionamento degli SSD sono tenuti segreti dai produttori, quindi raccomandiamo comunque di lasciare il 30% di spazio sugli SSD libero, oltre a ridurre la loro durata di vita prevista e pianificare di sostituirli non meno di una volta ogni tre anni.

Supponiamo che la dimensione del tuo database sia attualmente di 100 GB e cresca di 1 GB al mese. In questo caso, non devi acquistare un SSD di dimensione minima (120 GB), ma è meglio scegliere il dispositivo successivo nella linea di prodotti - 250 GB. Allo stesso tempo, acquistare un SSD da 512 gigabyte sarà uno spreco di denaro poiché è consigliabile sostituire il disco entro tre anni.

La migliore pratica è dedicare un SSD esclusivamente al lavoro con il database poiché qualsiasi operazione di input/output riduce la durata di vita dei dischi.

Disco per File Temporanei

Poiché i file temporanei appaiono sul disco solo quando non c’è abbastanza RAM, il modo migliore è ovviamente evitare del tutto questa situazione. È possibile valutare il numero e la dimensione dei file temporanei in un sistema di produzione solo monitorando la cartella con i file temporanei. FBDataGuard dalla distribuzione HQbird esegue questo tipo di monitoraggio. Una volta che sai quanti file di ordinamento temporanei vengono creati sul disco e quando vengono creati, sarai in grado di aumentare la quantità di RAM e modificare la configurazione in firebird.conf.

In ogni caso, Firebird richiede che tu specifichi la cartella dove verranno memorizzati i file temporanei. Di solito, il valore predefinito viene lasciato invariato, cioè viene utilizzata la cartella del sistema operativo per i file temporanei. Se la RAM libera è sufficiente, questa è una buona scelta.

Tuttavia, c’è un’altra questione importante riguardante la posizione dei file temporanei sul disco - è la creazione di indici quando ripristini una copia di backup verificata (creata con l’utilità gbak). Quando viene creato un indice, viene creato anche un file temporaneo contenente tutte le chiavi di questo indice. Se il database è abbastanza grande, la dimensione dell’indice per qualche grande tabella può essere anch’essa abbastanza grande. Ad esempio, l’indice della tabella più grande contenente 3,2 miliardi di record in un database da 1 terabyte è di 29 GB, ma sono stati necessari 180 GB di spazio libero per creare questo indice:

Per prevenire la mancanza di spazio libero sul disco di sistema, è possibile specificare un altro disco come spazio riservato aggiuntivo in firebird.conf:

TempDirectories =C:\temp; H:\Temp

Se non c’è spazio sul primo disco, Firebird continuerà a utilizzare il secondo disco per i file temporanei e così via.

HDD per Backup

I normali HDD con interfaccia SATA o nSAS andranno bene per creare e conservare le copie di backup. Garantiscono operazioni di scrittura e lettura sequenziale veloci per i file di backup e sono abbastanza economici da non dover risparmiare sulla loro dimensione e per conservare più copie di backup.

I dischi per le copie di backup devono avere sempre spazio libero extra: la dimensione dell’ultima copia di backup + 10%. In questo caso, è possibile creare una nuova copia di backup, assicurarsi che il processo di backup sia completato con successo (questo processo può richiedere diverse ore per un database con una dimensione di diversi terabyte) e solo dopo eliminare la copia di backup precedente.

Se elimini la copia di backup precedente prima che la nuova venga creata, è possibile che nessuna nuova copia di backup venga creata mentre quella vecchia sarà già stata eliminata e il database sarà corrotto, ad esempio, a causa di un guasto del disco.

Se usi il metodo di backup raccomandato sopra (la combinazione di backup incrementale a tre livelli e backup verificato una volta al giorno conservando solo l’ultima copia), usa la seguente formula per calcolare lo spazio minimo per il backup:

Dimensione_database*3+0.2.Dimensione_database

Consideriamo il seguente esempio di calcolo dello spazio necessario per il backup:

Supponiamo di avere un database di 100 GB per il quale conserviamo un backup incrementale a tre livelli (settimana-giorno-ora - una copia ciascuno) e una copia di backup verificato giornaliero. In questo caso, le copie di backup occuperanno il seguente spazio:

Nbackup_level_0.weekly - 100 GB
Nbackup_level_1.daily - 5 GB (circa)
Nbackup_level_2.hourly - 200 MB (circa)
Backup verificato giornaliero - 100 GB (circa)
Inoltre, hai bisogno di 110 GB riservati per poter creare la prossima copia di backup.

Totale - 316 GB.

! la dimensione del file incrementale di primo livello o superiore dipende dal numero di pagine modificate dal momento dell’ultima esecuzione di nbackup. La dimensione di questi file può essere determinata solo sperimentalmente, poiché la quantità di modifiche in un database dipende dalle applicazioni.

Naturalmente, la stima dello spazio per il backup dovrebbe tenere conto di un possibile aumento anomalo delle dimensioni del database e aumentare di conseguenza lo spazio libero, altrimenti il processo di backup potrebbe essere interrotto inaspettatamente per mancanza di spazio.

Naturalmente, gli strumenti di backup intelligenti (FBDataGuard di HQbird) noteranno la mancanza di spazio per le copie di backup e invieranno il messaggio corrispondente all’amministratore.

HDD per un Database

Un SSD potrebbe rivelarsi una soluzione troppo costosa o il database potrebbe essere troppo grande e si dovranno utilizzare metodi meno costosi. In questo caso, si dovrebbe utilizzare un HDD con interfaccia SAS. Se non è possibile, utilizzare dischi SATA con interfaccia nSAS o l’opzione più economica - normali dischi SATA.

Per aumentare la velocità (e anche l’affidabilità - vedere sotto) dei dischi rigidi, si dovrebbero combinare in RAID10. RAID10 è una combinazione di blocchi mirrorati (RAID1) e striping (RAID0). Un buon controller RAID ben configurato con ampia cache è una valida alternativa agli SSD.

Affidabilità e RAID

Naturalmente, è necessario aumentare l’affidabilità del sottosistema disco combinando i dischi in RAID in tutte le varianti sopra menzionate (tranne per il disco dedicato esclusivamente ai file temporanei).

• Per gli SSD, assicurarsi di utilizzare RAID1 - cioè due dischi mirrorati su cui le modifiche vengono scritte simultaneamente, il che rende le possibilità di perdere tutti i dati considerevolmente minori. RAID 10 composto da SSD sarà molto probabilmente ridondante poiché il bus RAID limiterà la velocità di trasferimento. Ad esempio, l’interfaccia a 6 Gbit/s ha una velocità di trasferimento di 600 megabyte al secondo mentre i moderni SSD singoli hanno già raggiunto questa velocità. Quindi, otterremo lo stesso limite di 600 MB/s per RAID 10.

Tranne che si possa utilizzare PCI Express 3.0 per combinare gli SSD in RAID 10 perché la velocità di trasferimento di questo bus è già di 16 gigabit al secondo e superiore.

• Se si utilizzano HDD per scopi di backup, è sufficiente utilizzare RAID1 che garantirà la sicurezza delle copie di backup e una velocità di lettura e scrittura accettabile.

• Gli HDD utilizzati per un database dovrebbero essere combinati in RAID10 (almeno 4 dischi) che forniscono la combinazione ottimale di costo, affidabilità e prestazioni. Alcuni utenti utilizzano anche RAID5 sacrificando le prestazioni per uno spazio maggiore.

Configurazione RAID per Firebird

Prima di tutto, si dovrebbe assicurare che ci sia un’unità batteria di backup (BBU) adeguatamente carica nel RAID. Se non c’è tale unità batteria, la maggior parte dei RAID passa alla modalità di scrittura sicura (la cache del disco è completamente disabilitata) che fornisce una velocità di input/output inferiore rispetto a un normale disco SATA!

Questo fatto causa la maggior parte dei messaggi frustrati al supporto tecnico da parte di utenti che hanno acquistato un server costoso e hanno scoperto che funziona più lentamente di un computer desktop. Sfortunatamente, alcuni fornitori non includono unità batteria per impostazione predefinita, quindi è la prima cosa che si dovrebbe controllare e correggere, se necessario.

Poi si dovrebbe configurare la cache di lettura e scrittura. Spesso, la cache è disabilitata per impostazione predefinita e se si vuole rendere il RAID abbastanza veloce, è necessario abilitare la cache.

Oltre ad abilitare la cache, si dovrebbe verificare come funziona - può essere write through e write back. Il modo veloce per lavorare con la cache è write back - in questo caso, qualsiasi modifica viene scritta nel controller della cache e, dopo un po’, direttamente sul disco.

Si possono utilizzare gli strumenti dei produttori forniti con il RAID per verificare l’unità batteria, la cache e la modalità.

I moderni controller RAID possono anche ottimizzare finemente la cache - può essere regolata per facilitare la lettura o la scrittura. Di solito, è divisa 50%/50% per lettura e scrittura.

Per scoprire esattamente come configurare la cache, si può anche utilizzare lo strumento MON$ Logger del pacchetto di distribuzione avanzato HQbird. Mostra il rapporto tra operazioni di lettura e scrittura (aggregato dal momento della prima connessione al server):

Figura 8. HQbird MON$Logger: rapporto letture/scritture

Come si può vedere, ci sono molte più operazioni di lettura che di scrittura in questo esempio, quindi ha senso configurare il controller RAID per l'80% di operazioni di lettura e il 20% di operazioni di scrittura.

SAN e database

Gli storage integrati sono diventati popolari recentemente. Includono un array di dischi flessibilmente personalizzabile (tutti i tipi di RAID) con funzionalità avanzate di caching. Di solito, i SAN hanno diversi controller di input/output, il che rende possibile servire più server simultaneamente e lavorare abbastanza velocemente.

Molte organizzazioni acquistano SAN e li utilizzano nel loro lavoro con database Firebird. Se un SAN è configurato correttamente, è possibile ottenere buone prestazioni. Si dovrebbero tenere in considerazione i seguenti problemi se si utilizza SAN:

Devono essere disponibili diversi controller disco ad alte prestazioni che forniscono uno scambio dati multi-canale
Devono essere presenti unità batteria di backup (BBU) se previste dal design.
I dischi del database devono essere combinati in RAID10.
La cache deve essere abilitata, la modalità di scrittura deve essere impostata su write back.
Se più computer sono collegati al SAN, ognuno di essi deve avere il proprio controller.
I driver SAN più recenti sono installati. Abbiamo incontrato casi in cui driver successivi forniti hanno dato un aumento delle prestazioni del 30%.
Se ci sono più dischi logici su un SAN (per database, copie di backup, sistema operativo), hanno canali di input/output diversi. Un tentativo di utilizzare un canale per tutti i dischi insieme comporterà prestazioni inferiori.
Allo stesso modo, se più server e database utilizzano un SAN contemporaneamente, le prestazioni potrebbero essere inferiori a causa dell’aumentata larghezza di banda dei controller di input/output.
Vengono spesso utilizzati modi combinati - quando il sistema operativo e i file temporanei sono memorizzati su dischi locali mentre il database e i file di backup sono memorizzati su un SAN.

Spesso i SAN vengono utilizzati come “due server - un SAN” per creare un cluster a prova di guasto. Va notato che tale cluster può risolvere solo problemi relativi a guasti hardware su uno dei server passando immediatamente al secondo server. Se il problema è relativo al SAN o al database stesso, questa soluzione non aiuterà.

Per costruire una soluzione realmente a prova di guasto, si dovrebbero utilizzare soluzioni che replicano i dati tra due istanze di database. Si può contattare [email protected] per scoprire più soluzioni disponibili per Firebird.

Brevi Conclusioni e Raccomandazioni

Riassumiamo conclusioni e raccomandazioni per Firebird riguardanti l’hardware.

Devono essere utilizzate CPU multi-core per servire un gran numero di utenti
La quantità minima di RAM è calcolata sulla base del numero di utenti e della configurazione del database; la quantità eccedente di RAM sarà efficacemente utilizzata dal sistema operativo per la cache del file di database.
Utilizzare dischi separati per database, file temporanei e file di backup
Preferire SSD per i database
Riservare almeno il 30% di spazio libero sugli SSD.
È consigliabile dedicare un disco al database.
Utilizzare SSD enterprise (con molti cicli di scrittura/lettura).
Assicurarsi di utilizzare RAID.
Per SSD - RAID 1, per HDD - RAID10, per HDD di backup - RAID1. i. SAS, SATA, nSAS
Assicurarsi che la batteria RAID sia presente e carica
Assicurarsi che sia impostato su write back.
Alcuni controller RAID hanno già la dimensione della cache configurata, ad esempio, 75% per la lettura, 25% per la scrittura, o 50/50 ecc. Quindi è necessario installare MON$Logger - il software che controllerà i parametri RAID, cercherà il rapporto letture/scritture e modificherà le impostazioni RAID.
Ci sono pro e contro nell’uso dei SAN. Per ottenere il massimo, si dovrebbe configurare correttamente il SAN.
Per costruire una soluzione a prova di guasto, è necessario utilizzare soluzioni con repliche in esecuzione su server diversi.

Contatti

La società IBSurgeon/IBase.ru ha sviluppato un pacchetto di distribuzione avanzato HQbird per le imprese, fornendo un supporto tecnico complesso per Firebird e sviluppando pacchetti di distribuzione personalizzati oltre a risolvere altri problemi complicati.

IBSurgeon offre anche il servizio di ottimizzazione Firebird per migliorare le prestazioni dei database Firebird.

Contattaci: [email protected]