Guide matériel Firebird

by Alexey Kovyazin, dernière mise à jour : 30 novembre 2015

On voit souvent la question suivante dans les groupes de support technique Firebird : « Quel matériel choisir pour le SGBD Firebird ? ». Ce sujet reste en permanence populaire car les exigences matérielles diffèrent selon les tâches et le matériel lui-même évolue avec le temps.

Nous avons décidé d’écrire ce guide afin de fournir les connaissances nécessaires à toute personne souhaitant choisir un matériel véritablement efficace pour sa base de données Firebird. Pour ce faire, vous devrez apprendre quelques notions de base sur le fonctionnement de Firebird, du système d’exploitation et, bien sûr, du matériel.

Un Peu de Théorie

Pour savoir quel matériel conviendra le mieux à votre base de données Firebird, nous devons comprendre comment Firebird utilise ses composants : CPU, RAM, HDD/SSD et comment ces composants interagissent avec le système d’exploitation (par exemple, avec le cache de fichiers).

Modules Fonctionnels du Serveur Firebird

Tout d’abord, nous allons examiner les modules fonctionnels de Firebird à l’aide de la Figure 1 :

Figure 1. Modules Firebird

Firebird comprend les principaux modules fonctionnels suivants :

Les objets de métadonnées : vues, tables, index, déclencheurs, procédures stockées et autres objets de base de données. Les objets de métadonnées sont situés dans l’espace d’adressage du processus Firebird (il peut s’agir de fbserver, fb_inet_server ou firebird.exe).
Le cache de tampons de pages contient les pages de base de données lues depuis le disque et est situé dans l’espace d’adressage du processus serveur. Le mécanisme de mise en cache des pages est assez complexe, nous nous contenterons donc de préciser que Firebird met en cache les pages de base de données les plus fréquemment utilisées.
Firebird trie les enregistrements en mémoire (dans l’espace d’adressage du processus serveur) jusqu’à ce que la quantité de mémoire utilisée pour toutes les opérations de tri simultanées atteigne la limite définie par le paramètre TempCacheLimit (firebird.conf). Une fois cette limite dépassée, un fichier temporaire (avec l’indicateur correspondant du système d’exploitation) est créé dans le dossier des fichiers temporaires et est utilisé pour le tri. S’il y a de la RAM libre dans le système, le fichier de tri sera mis en cache par le système d’exploitation et le tri sera effectué en mémoire.
Les tables temporaires globales (GTT) sont créées comme fichiers temporaires dans le système d’exploitation. Si le système d’exploitation dispose de mémoire libre, les opérations avec les GTT sont effectuées en RAM.

Opérations de Base avec le Matériel

Voyons comment les modules fonctionnels de Firebird interagissent avec les composants matériels lors des opérations effectuées au cours du travail avec les bases de données.

Une fois Firebird démarré, le processus serveur occupe une quantité minimale de RAM (quelques mégaoctets) et n’effectue aucune opération intensive avec le CPU ou la RAM.

Lorsqu’une connexion est établie avec la base de données, le serveur commence à lire ses métadonnées et crée les objets correspondants en mémoire, ce qui fait que le processus prend d’autant plus de ressources que plus de tables, index, déclencheurs et autres métadonnées sont utilisés. L’utilisation de la mémoire augmente, mais le CPU n’est pratiquement pas utilisé à ce stade.

Lorsque le client commence à exécuter des requêtes SQL (y compris des procédures stockées), le serveur effectue les opérations correspondantes en utilisant le matériel. Il est possible de distinguer les opérations de base suivantes impliquant une interaction avec le matériel :

lecture des pages de base de données depuis le disque dur,
écriture des pages de base de données sur le disque dur,
lecture des pages de base de données depuis le cache,
écriture des pages de base de données dans le cache,
lecture et écriture de données dans les tables temporaires globales,
traitement des requêtes SQL (par exemple, les JOIN),
tri des enregistrements dans les ensembles de résultats.

Chacune de ces opérations nécessite une certaine quantité de ressources système. Le tableau ci-dessous montre la consommation de ressources en unités d’intensité (1 signifie le moins intense, 10 le plus intense) :


	Lecture d’une page depuis le disque	Écriture d’une page sur le disque	Lecture d’une page depuis le cache de tampons	Écriture d’une page dans le cache de tampons	Lecture depuis une GTT	Écriture dans une GTT	Tri des enregistrements	Traitement des requêtes SQL
CPU	1	1	1	1	1	1	5	10
RAM	5	5	5	5	5	5	5	2
E/S disque	10	10	1	1	1	1	1	1

Comme vous pouvez le constater, les opérations les plus gourmandes en ressources sont celles qui impliquent un accès au disque, car les disques restent le composant matériel le plus lent malgré les progrès réalisés ces dernières années avec les SSD.

Cela conduit à l’une des façons d’optimiser les performances qui est entièrement liée au matériel : transférer toutes les opérations de lecture-écriture en RAM. Mais notez que l’approche consistant à augmenter le cache de pages ne fonctionne pas. Nous traiterons ce problème en détail dans la section RAM.

Opérations Effectuées Simultanément

En général, il est nécessaire de choisir un matériel pour un serveur qui desservira de nombreux clients, il est donc vraiment important de comprendre comment le parallélisme des opérations est implémenté.

Du point de vue des composants matériels, on peut parler de l’utilisation parallèle du CPU, du disque et de la RAM. Les CPU modernes ont plusieurs cœurs qui peuvent exécuter des ensembles d’instructions en parallèle, de sorte que le serveur SGBD répartit les opérations entre les cœurs, ce qui signifie que plus le CPU a de cœurs, plus de clients pourront travailler sur ce serveur.

Ce n’est pas si simple du point de vue des disques. Lorsque les disques durs traditionnels (HDD) lisent des informations, ils déplacent physiquement la tête sur le matériau magnétique à une vitesse finie. Une base de données peut être assez volumineuse, par exemple 3 téraoctets, et si les requêtes SQL des clients accèdent en parallèle à ses données situées dans différentes zones du disque, la tête du disque sautera entre différentes zones du disque, ralentissant ainsi sérieusement les opérations de lecture et d’écriture. Cela augmentera considérablement la file d’attente du disque tandis que le reste des ressources (CPU, RAM) restera inactif. Bien sûr, le cache du disque (le cache du HDD ou du contrôleur RAID) compense en partie ce ralentissement, mais cela ne suffit pas.

Contrairement aux HDD traditionnels, les disques SSD sont beaucoup moins sujets à la dégradation des performances en cas d’accès parallèle aux données. L’avantage d’un SSD est particulièrement évident lors de l’écriture de données en parallèle - nos tests montrent qu’un SSD est 7 fois plus rapide qu’un disque SATA (lien !). Cependant, les SSD présentent certains problèmes qui doivent être pris en compte lors de leur utilisation (voir Sélection des Disques) afin d’éviter les ralentissements, les pannes précoces et la perte de données.

Les opérations avec la RAM sont effectuées très rapidement sur les ordinateurs modernes, elles sont pratiquement limitées uniquement par la bande passante du bus de données, de sorte que ces opérations ne constituent pas un goulot d’étranglement même s’il y a beaucoup de requêtes SQL parallèles.

Flux de Données

Lors de l’exécution de requêtes SQL, Firebird lit et écrit beaucoup de données, les transfère entre les modules fonctionnels et les composants matériels correspondants. Pour identifier les goulots d’étranglement possibles, nous devons comprendre comment l’échange de données est effectué. La Figure 2 ci-dessous nous aidera :

Figure 2. Flux de données entre la RAM et le stockage persistant

Évidemment, le transfert de données du stockage persistant vers la RAM et inversement est l’opération la plus longue. Elle crée deux flux de données : la lecture/écriture des pages de données depuis les fichiers de base de données et la lecture/écriture des fichiers de tri. Comme il peut y avoir plusieurs fichiers de tri et qu’ils peuvent être assez volumineux, ils peuvent créer une charge assez lourde sur les disques, il est donc conseillé de diriger ces flux d’entrée/sortie vers des disques différents.

Sauvegarde

Firebird offre deux méthodes de sauvegarde : la sauvegarde vérifiée à l’aide de l’utilitaire gbak et la sauvegarde incrémentale non vérifiée à l’aide de l’utilitaire nbackup.

Nous recommandons de combiner ces méthodes de sauvegarde : exécutez nbackup souvent (par exemple, toutes les heures, tous les jours et toutes les semaines) et créez une copie de sauvegarde vérifiée chaque nuit avec gbak.

Quelle que soit la méthode de sauvegarde utilisée, le fichier de base de données est lu (en totalité ou en partie) et la copie de sauvegarde (complète ou incrémentale) est écrite. Les opérations d’écriture sont effectuées séquentiellement pendant le processus de sauvegarde, ce qui signifie que des disques durs classiques peu coûteux avec interface SATA (HDD SATA) conviendront bien pour la sauvegarde, car ils écrivent séquentiellement assez rapidement.

Sélection du Matériel Approprié

Maintenant que nous avons une idée de la façon dont Firebird interagit avec le matériel, nous devons nous attarder sur les facteurs qui affectent le choix de chaque composant particulier et ses spécifications.

Parfois, les statistiques réelles d’une base de données particulière influencent fortement le choix des composants matériels, nous utiliserons donc les outils de HQbird (le pack de distribution professionnel de Firebird d’IBSurgeon) pour obtenir ces statistiques. Vous pouvez télécharger la version d’essai de HQbird sur http://hqbird.com/en/hqbird/.

CPU

Lors du choix du CPU, vous devez prendre en compte les trois éléments suivants :

Quelles requêtes prédominent dans l’application,
Le nombre de connexions actives à la base de données en moyenne et sous charge de pointe,
La version et l’architecture de Firebird.

Quelles Requêtes Prédominent dans l’Application ?

Firebird exécute toujours une requête sur un seul cœur, donc des requêtes complexes et mal optimisées peuvent utiliser un cœur jusqu’à 100 %, forçant les autres requêtes vers des cœurs moins chargés, et plus il y a de cœurs, plus les chances sont faibles que le CPU entier soit utilisé et que les utilisateurs remarquent une dégradation des performances dans l’application.

Si l’application exécute principalement des requêtes SQL simples et courtes, que toutes les requêtes sont bien optimisées et qu’aucune requête ad hoc n’est générée (par exemple, pour des rapports), le CPU ne présentera aucun goulot d’étranglement pour les performances et vous pouvez choisir un CPU d’entrée de gamme avec moins de cœurs.

Si l’application contient un générateur de rapports ou beaucoup de requêtes lentes renvoyant une grande quantité de données, vous avez besoin d’un CPU avec plus de cœurs.

Le Nombre de Connexions Actives à la Base de Données en Moyenne et sous Charge de Pointe

Le nombre de connexions (utilisateurs actifs) influence également le choix du CPU. Malheureusement, même les développeurs d’applications n’ont aucune idée du nombre exact de connexions, de requêtes et de transactions actives à un moment donné. Pour obtenir des informations plus précises à ce sujet, nous recommandons d’utiliser l’outil MON$ Logger de HQbird et de faire quelques captures pendant son exécution où vous verrez combien de connexions sont réellement établies.

Figure 3. MON$ Logger : nombre de connexions

Par exemple, vous pouvez voir ici que le nombre de connexions est de 296. Évidemment, il est trop optimiste d’utiliser un CPU quadricœur dans ce cas, tandis qu’une solution à 24 cœurs sera tout à fait acceptable. Il est également conseillé de compter le nombre de requêtes s’exécutant simultanément, car les connexions peuvent être inactives sans aucune requête SQL en cours.

Vous pouvez utiliser le taux de 10 à 30 connexions par cœur pour estimer approximativement le nombre de cœurs nécessaire dans votre CPU. 10 connexions par cœur pour une application avec principalement des requêtes complexes et lentes, 30 connexions par cœur pour une application avec principalement des requêtes simples et bien optimisées.

Version et Architecture de Firebird

Si vous utilisez Firebird version 2.5, notez que vous devez utiliser l’architecture Classic ou SuperClassic pour pouvoir répartir le traitement entre plusieurs cœurs. Dans la version 2.5, l’architecture SuperServer ne peut utiliser qu’un seul cœur pour une base de données, elle ne doit donc pas être utilisée dans les systèmes qui consomment beaucoup de ressources.

Dans Firebird version 3.0, SuperServer, Classic et SuperClassic utilisent les fonctionnalités des CPU multi-cœurs. Firebird 3.0 SuperServer offre les meilleures performances.

RAM

Lors du choix de la RAM, vous devez prêter attention à deux choses :

le module mémoire doit avoir un code de correction d’erreurs (RAM ECC)
la quantité de RAM doit être correctement calculée

RAM ECC

La RAM ECC réduit considérablement le nombre d’erreurs qui se produisent au cours du travail avec la mémoire et il est fortement recommandé de l’utiliser dans les systèmes industriels.

Calcul de la quantité de RAM nécessaire

Pour calculer la quantité de mémoire, nous devons examiner les particularités des différentes architectures Firebird. Firebird 2.5 Classic et Firebird 3.0 Classic exécutent un processus séparé pour servir chaque connexion, SuperClassic exécute un thread séparé pour chaque connexion, mais avec pratiquement la même structure de consommation mémoire - chaque connexion possède son propre cache de pages indépendant.

Firebird SuperServer exécute un seul processus avec un seul cache de pages pour toutes les connexions.

Ainsi, les paramètres suivants affectent la consommation mémoire globale :

Nombre de connexions
Taille de page de la base de données
Taille des métadonnées (proportionnelle au nombre de tables, déclencheurs, procédures stockées, etc. ; non ajustable ; déterminée par l’utilisation physique)
Pour Classic et SuperClassic - par connexion
Pour SuperServer - par instance d’une base de données ouverte
Taille du cache de pages (déterminée par les paramètres dans l’en-tête de la base de données ou dans firebird.conf ou dans les propriétés d’une connexion particulière)
Pour Classic et SuperClassic - par connexion
Pour SuperServer - par instance d’une base de données ouverte
Taille du cache de tri (déterminée par le paramètre dans firebird.conf). Notez que la mémoire pour le tri n’est pas allouée d’un coup mais au fur et à mesure des besoins.
Pour Classic - par connexion
Pour SuperServer et SuperClassic - par processus (c’est-à-dire un seul cache de tri)
Pour Classic/SuperClassic - taille de la table de verrous (elle est généralement petite, nous la laisserons donc hors de notre calcul).

La société IBSurgeon a effectué quelques tests et obtenu un ensemble de valeurs optimales pour le nombre de pages dans le cache de pages Firebird :

Classic/SuperClassic - de 256 à 2000 pages
SuperServer 2.5 - 10000 pages
SuperServer 3.0 - 100000 pages

En nous basant sur ces tests, nous avons créé des fichiers de configuration Firebird optimisés pour des serveurs avec 4-6 Go de mémoire. Vous pouvez les télécharger ici : /fr/optimized-firebird-configuration/

Formules pour calculer la quantité de RAM nécessaire

Vous trouverez ci-dessous des formules utilisées pour estimer la quantité approximative de mémoire requise par Firebird. La consommation mémoire réelle peut différer car cette estimation ne prend pas en compte la mémoire nécessaire pour les métadonnées, les masques binaires des index, etc., ce qui peut augmenter la consommation mémoire. Cependant, il est également supposé que la mémoire de tri sera utilisée au maximum dans toutes les connexions, ce qui n’est généralement pas le cas.

Lorsque votre base de données est déjà en production, vous pouvez examiner la quantité moyenne de mémoire utilisée par le processus Firebird (à l’aide du Gestionnaire des tâches ou de ProcessExplorer).

Estimation pour Classic :

Nombre de connexions * ( (Nombre de pages dans le cache * Taille de page) + Taille du cache de tri )

Exemple pour Classic : supposons que nous attendons 100 utilisateurs actifs, la taille de page de la base de données est définie à 8 Ko et le nombre de pages dans le cache de pages est défini à 256, la taille du cache de tri est augmentée de 8 Mo (la valeur par défaut pour Classic et SuperClassic) à 64 Mo :

((256.8 Ko)+64) = 6600 Mo

Estimation pour SuperClassic :

Nombre de connexions * (Nombre de pages dans le cache * Taille de page) + Taille du cache de tri

Exemple pour SuperClassic : 100 utilisateurs, la taille de page de la base de données est de 8 Ko, le nombre de pages dans le cache de pages est de 256, la taille du cache de tri est de 1024 Mo

100.(256.8 Ko) + 1024 Mo = 2024 Mo

Estimation pour SuperServer :

(Nombre de pages dans le cache * Taille de page) + Taille du cache de tri

Exemple pour SuperServer (Firebird 2.5) : 1 base de données, 100 utilisateurs, la taille de page de la base de données est de 8 Ko, le nombre de pages dans le cache de pages est de 10000, la taille du cache de tri est de 1024 Mo :

(10000.8 Ko) + 1024 = 1102 Mo

Exemple pour SuperServer (Firebird 3.0) : 1 base de données, 100 utilisateurs, la taille de page de la base de données est de 8 Ko, le nombre de pages dans le cache de pages est de 100000, la taille du cache de tri est de 1024 Mo :

(100000.8 Ko) + 1024 = 1805 Mo

« Mémoire excessive »

Firebird est souvent critiqué pour une utilisation inefficace de la mémoire - lorsque le processus en cours du serveur consomme une petite quantité de RAM et que le reste de la mémoire reste prétendument inutilisé.

En réalité, ce n’est pas vrai. Cette conclusion repose essentiellement sur une incompréhension du fonctionnement du mécanisme de mise en cache de Firebird et sur l’imperfection des outils de surveillance du système d’exploitation.

Tout d’abord, vous devez être absolument clair que Firebird utilise intensivement le cache de fichiers du système d’exploitation. Lorsqu’une page est chargée dans le cache de pages Firebird, elle passe par le cache de fichiers du système d’exploitation. Lorsque Firebird décharge une page de son cache de pages, le système d’exploitation continue de conserver ce fragment de la base de données dans sa RAM, à condition qu’il dispose de suffisamment de mémoire libre.

Figure 4. Niveaux de cache : Firebird, OS et stockage

Cependant, si vous regardez simplement, le système d’exploitation n’affiche pas la mémoire allouée au cache de fichiers comme étant utilisée. Par exemple, voici la situation typique de répartition de la mémoire lorsque le serveur Firebird est en cours d’exécution, telle qu’affichée par le Gestionnaire des tâches :

Figure 5. Le Gestionnaire des tâches n’affiche pas l’utilisation du cache de fichiers

Il semble que seulement 6,3 Go sur 16 Go soient utilisés.

Cependant, si vous utilisez l’outil RAMMap (de SysInternals par Microsoft), tout semble beaucoup plus logique :

Figure 6. RAMMap affiche des détails sur l’utilisation de la mémoire : les fichiers mappés sont des bases de données en cache

Les fichiers de base de données (dbw350.fb252x64.fdb et dbw250.fb252x64.fdb) sont mis en cache par le système d’exploitation et occupent toute la mémoire déclarée comme libre par le Gestionnaire des tâches :

Figure 7. RAMMap : détails sur l’utilisation du cache de fichiers

Nous concluons donc que le système d’exploitation utilise efficacement toute la mémoire disponible pour mettre en cache la base de données, jusqu’à charger complètement la base de données en mémoire.

Sous-système de disque

La configuration correcte du sous-système de disque joue un rôle important dans le choix et la configuration du matériel pour Firebird, car toute erreur à cette étape entraînera des défaillances majeures difficiles à corriger.

Des disques séparés pour tout

Pour réduire la concurrence pour les entrées/sorties disque entre les opérations sur le fichier de base de données et pour diminuer les risques de perte simultanée de la base de données et des sauvegardes, il est recommandé d’avoir trois disques différents (ou baies RAID) : un pour la base de données, un pour les fichiers temporaires et un pour la création et le stockage des copies de sauvegarde.

Lorsque nous disons « disques séparés », cela signifie que les flux de données doivent passer par des canaux d’entrée/sortie différents. Si vous créez trois disques logiques sur un seul disque physique, il n’y aura aucune augmentation des performances. Cependant, si vous organisez trois disques logiques sur un périphérique de stockage équipé de contrôleurs multicanaux, les performances seront très probablement améliorées car le périphérique peut répartir les flux de données entre les contrôleurs. Parfois, dédier un disque séparé au stockage des fichiers du système d’exploitation et du fichier d’échange du système d’exploitation est considéré comme améliorant les performances.

SSD pour une base de données

Le SSD est le meilleur choix pour travailler avec une base de données car il garantit une excellente évolutivité lors des entrées/sorties parallèles. Il est impératif d’utiliser des disques d’entreprise avec un nombre accru de cycles de lecture/écriture, sinon il est fortement possible de perdre des données en raison d’une défaillance du SSD.

Il y a quelque temps, les SSD étaient sujets à une usure accrue lorsqu’il restait peu d’espace libre sur le disque (moins de 30 %). En termes simples, chaque modification sur un SSD est écrite dans une nouvelle cellule libre, donc le manque d’espace libre entraînait une usure accrue des cellules restées libres et une durée de vie plus courte du disque.

Les fabricants de contrôleurs SSD modernes déclarent que ce problème a été résolu en déplaçant préventivement les données statiques et que l’usure des cellules est désormais plus ou moins nivelée. Cependant, les spécifications exactes et les algorithmes de fonctionnement des SSD sont gardés secrets par les fabricants, nous recommandons donc toujours de laisser 30 % d’espace libre sur les SSD, ainsi que de réduire leur durée de vie attendue et de prévoir de les remplacer au moins une fois tous les trois ans.

Supposons que la taille de votre base de données soit actuellement de 100 Go et qu’elle croisse de 1 Go par mois. Dans ce cas, vous ne devez pas acheter un SSD de taille minimale (120 Go), mais il est préférable de choisir le périphérique suivant dans la gamme de produits - 250 Go. En même temps, acheter un SSD de 512 Go serait un gaspillage d’argent car il est conseillé de remplacer le disque dans trois ans.

La meilleure pratique consiste à dédier un SSD exclusivement au travail avec la base de données, car toute opération d’entrée/sortie réduit la durée de vie des disques.

Disque pour les fichiers temporaires

Comme les fichiers temporaires n’apparaissent sur le disque que lorsqu’il n’y a pas assez de RAM, la meilleure façon est d’éviter cette situation, bien sûr. Il est possible d’évaluer le nombre et la taille des fichiers temporaires dans un système de production uniquement en surveillant le dossier des fichiers temporaires. FBDataGuard du package de distribution HQbird effectue ce type de surveillance. Une fois que vous savez combien de fichiers de tri temporaires sont créés sur le disque et quand ils sont créés, vous pourrez augmenter la quantité de RAM et modifier la configuration dans firebird.conf.

Dans tous les cas, Firebird exige que vous spécifiiez le dossier où les fichiers temporaires seront stockés. Habituellement, la valeur par défaut est laissée inchangée, c’est-à-dire que le dossier du système d’exploitation pour les fichiers temporaires est utilisé. Si la RAM libre est suffisante, c’est un bon choix.

Cependant, il existe un autre problème important concernant l’emplacement des fichiers temporaires sur le disque - il s’agit de la création d’index lors de la restauration d’une copie de sauvegarde vérifiée (créée avec l’utilitaire gbak). Lorsqu’un index est créé, un fichier temporaire contenant toutes les clés de cet index est également créé. Si la base de données est assez grande, la taille de l’index pour une grande table peut également être assez importante. Par exemple, l’index de la plus grande table contenant 3,2 milliards d’enregistrements dans une base de données de 1 téraoctet est de 29 Go, mais il a fallu 180 Go d’espace libre pour créer cet index :

Pour éviter le manque d’espace libre sur le disque système, il est possible de spécifier un autre disque comme espace réservé supplémentaire dans firebird.conf :

TempDirectories =C:\temp; H:\Temp

S’il n’y a pas d’espace sur le premier disque, Firebird continuera à utiliser le deuxième disque pour les fichiers temporaires et ainsi de suite.

HDD pour les sauvegardes

Les HDD classiques avec interface SATA ou nSAS conviendront pour créer et stocker des copies de sauvegarde. Ils garantissent des opérations d’écriture et de lecture séquentielles rapides pour les fichiers de sauvegarde et sont suffisamment bon marché pour ne pas lésiner sur leur taille et conserver plusieurs copies de sauvegarde.

Les disques pour les copies de sauvegarde doivent toujours avoir de l’espace libre supplémentaire : la taille de la dernière copie de sauvegarde + 10 %. Dans ce cas, il est possible de créer une nouvelle copie de sauvegarde, de s’assurer que le processus de sauvegarde s’est terminé avec succès (ce processus peut prendre plusieurs heures pour une base de données de plusieurs téraoctets) et seulement après cela de supprimer la copie de sauvegarde précédente.

Si vous supprimez la copie de sauvegarde précédente avant que la nouvelle ne soit créée, il est possible qu’aucune nouvelle copie de sauvegarde ne soit créée alors que l’ancienne aura déjà été supprimée et que la base de données sera corrompue, par exemple, en raison d’une défaillance du disque.

Si vous utilisez la méthode de sauvegarde recommandée ci-dessus (la combinaison de sauvegarde incrémentale à trois niveaux et de sauvegarde vérifiée une fois par jour en ne conservant qu’une seule copie la plus récente), utilisez la formule suivante pour calculer l’espace minimum pour la sauvegarde :

Taille_de_la_base*3+0.2.Taille_de_la_base

Considérons l’exemple de calcul suivant de l’espace nécessaire pour la sauvegarde :

Supposons que nous ayons une base de données de 100 Go pour laquelle nous stockons une sauvegarde incrémentale à trois niveaux (semaine-jour-heure - une copie chacun) et une copie de sauvegarde vérifiée quotidienne. Dans ce cas, les copies de sauvegarde occuperont l’espace suivant :

Nbackup_level_0.weekly - 100 Go
Nbackup_level_1.daily - 5 Go (environ)
Nbackup_level_2.hourly - 200 Mo (environ)
Sauvegarde vérifiée quotidienne - 100 Go (environ)
Plus vous devez réserver 110 Go pour pouvoir créer la prochaine copie de sauvegarde.

Total - 316 Go.

! la taille du fichier incrémental de premier niveau ou supérieur dépend du nombre de pages modifiées depuis la dernière exécution de nbackup. La taille de ces fichiers ne peut être déterminée que de manière expérimentale, car la quantité de modifications dans une base de données dépend des applications.

Bien entendu, l’estimation de l’espace pour la sauvegarde doit prendre en compte une éventuelle augmentation anormale de la taille de la base de données et augmenter en conséquence l’espace libre, sinon le processus de sauvegarde peut être interrompu de manière inattendue par manque d’espace.

Naturellement, les outils de sauvegarde intelligents (FBDataGuard de HQbird) remarqueront le manque d’espace pour les copies de sauvegarde et enverront le message correspondant à l’administrateur.

Disque dur pour une base de données

Un SSD peut s’avérer être une solution trop coûteuse ou la base de données peut être trop volumineuse, et vous devrez alors utiliser des méthodes moins chères. Dans ce cas, vous devez utiliser un disque dur avec interface SAS. Si cela n’est pas possible, utilisez des disques SATA avec interface nSAS ou l’option la moins chère - des disques SATA ordinaires.

Pour augmenter la vitesse (et aussi la fiabilité - voir ci-dessous) des disques durs, vous devez les combiner en RAID10. Le RAID10 est une combinaison de blocs en miroir (RAID1) et en répartition (RAID0). Un bon contrôleur RAID bien configuré avec un grand cache est une excellente alternative aux SSD.

Fiabilité et RAID

Bien sûr, il est nécessaire d’augmenter la fiabilité du sous-système de disques en combinant les disques en RAID dans toutes les variantes mentionnées ci-dessus (sauf pour le disque dédié exclusivement aux fichiers temporaires).

• Pour les SSD, assurez-vous d’utiliser le RAID1 - c’est-à-dire deux disques en miroir sur lesquels les modifications sont écrites simultanément, ce qui réduit considérablement les risques de perte de toutes les données. Le RAID 10 composé de SSD sera très probablement redondant, car le bus RAID limitera le débit. Par exemple, l’interface 6 Gbit/s a un débit de 600 mégaoctets par seconde, alors que les SSD modernes individuels ont déjà atteint cette vitesse. Ainsi, nous obtiendrons la même limite de 600 Mo/s pour le RAID 10.

Sauf que vous pouvez utiliser PCI Express 3.0 pour combiner des SSD en RAID 10, car le débit de ce bus est déjà de 16 gigabits par seconde et plus.

• Si vous utilisez des disques durs à des fins de sauvegarde, il suffit d’utiliser le RAID1 qui garantira la sécurité des copies de sauvegarde et une vitesse de lecture et d’écriture acceptable.

• Les disques durs utilisés pour une base de données doivent être combinés en RAID10 (au moins 4 disques) qui offrent la combinaison optimale de coût, de fiabilité et de performances. Certains utilisateurs utilisent également le RAID5 en sacrifiant les performances pour un espace plus grand.

Configuration RAID pour Firebird

Tout d’abord, vous devez vous assurer qu’il y a une unité de batterie de secours correctement chargée (BBU) dans le RAID. S’il n’y a pas une telle unité de batterie, la plupart des RAID passent en mode d’écriture sécurisée (le cache du disque est complètement désactivé), ce qui offre une vitesse d’entrée/sortie inférieure à celle d’un disque SATA ordinaire !

Ce fait est à l’origine de la plupart des messages de frustration adressés au support technique par des utilisateurs qui ont acheté un serveur coûteux et ont découvert qu’il fonctionne plus lentement qu’un ordinateur de bureau. Malheureusement, certains fournisseurs n’incluent pas d’unités de batterie par défaut, c’est pourquoi c’est la première chose que vous devez vérifier et corriger, si nécessaire.

Ensuite, vous devez configurer le cache de lecture et d’écriture. Souvent, le cache est désactivé par défaut et si vous voulez rendre le RAID assez rapide, vous devez activer le cache.

En plus d’activer le cache, vous devez vérifier comment il fonctionne - il peut être en écriture directe (write through) ou en écriture différée (write back). La méthode rapide pour travailler avec le cache est l’écriture différée - dans ce cas, toutes les modifications sont écrites dans le contrôleur de cache et, peu après, directement sur le disque.

Vous pouvez utiliser les outils des fabricants fournis avec le RAID pour vérifier l’unité de batterie, le cache et le mode.

Les contrôleurs RAID modernes peuvent également affiner le cache - il peut être ajusté pour faciliter la lecture ou l’écriture. Habituellement, il est réparti à 50 %/50 % entre lecture et écriture.

Pour savoir exactement comment configurer le cache, vous pouvez également utiliser l’outil MON$ Logger du package de distribution avancé HQbird. Il montre le taux des opérations de lecture par rapport aux opérations d’écriture (agrégé depuis le moment de la première connexion au serveur) :

Figure 8. HQbird MON$Logger : rapport lecture/écriture

Comme vous pouvez le voir, il y a beaucoup plus d’opérations de lecture que d’opérations d’écriture dans cet exemple, il est donc logique de configurer le contrôleur RAID pour 80 % d’opérations de lecture et 20 % d’opérations d’écriture.

SAN et bases de données

Les stockages intégrés sont devenus populaires récemment. Ils incluent un ensemble de disques flexible et personnalisable (tous types de RAID) avec des fonctions de mise en cache avancées. En général, les SAN disposent de plusieurs contrôleurs d’entrée/sortie, ce qui permet de servir plusieurs serveurs simultanément et de fonctionner assez rapidement.

De nombreuses organisations achètent des SAN et les utilisent dans leur travail avec les bases de données Firebird. Si un SAN est configuré correctement, il est possible d’obtenir de bonnes performances. Vous devez prendre en compte les points suivants si vous utilisez un SAN :

Plusieurs contrôleurs de disques haute performance offrant un échange de données multicanal doivent être disponibles.
Des unités de batterie de secours (BBU) doivent être présentes si elles sont prévues par conception.
Les disques de la base de données doivent être combinés en RAID10.
Le cache doit être activé, le mode d’écriture doit être commuté en écriture différée (write back).
Si plusieurs ordinateurs sont connectés au SAN, chacun d’eux doit avoir son propre contrôleur.
Les derniers pilotes SAN sont installés. Nous avons rencontré des cas où des pilotes plus récents fournis ont donné une augmentation de 30 % des performances.
S’il y a plusieurs disques logiques sur un SAN (pour les bases de données, les copies de sauvegarde, le système d’exploitation), ils ont des canaux d’entrée/sortie différents. Une tentative d’utiliser un seul canal pour tous les disques ensemble entraînera une baisse des performances.
De même, si plusieurs serveurs et bases de données utilisent un SAN en même temps, les performances peuvent être inférieures en raison de l’augmentation de la bande passante des contrôleurs d’entrée/sortie.
Des méthodes combinées sont souvent utilisées - lorsque le système d’exploitation et les fichiers temporaires sont stockés sur des disques locaux tandis que la base de données et les fichiers de sauvegarde sont stockés sur un SAN.

Souvent, les SAN sont utilisés comme « deux serveurs - un SAN » afin de créer un cluster à l’épreuve des pannes. Il convient de noter qu’un tel cluster ne peut résoudre que les problèmes liés aux pannes matérielles sur l’un des serveurs en basculant immédiatement sur le second serveur. Si le problème est lié au SAN ou à la base de données elle-même, cette solution ne sera d’aucune aide.

Pour construire une solution réellement à l’épreuve des pannes, vous devez utiliser des solutions qui répliquent les données entre deux instances de base de données. Vous pouvez contacter [email protected] pour découvrir d’autres solutions disponibles pour Firebird.

Conclusions et recommandations brèves

Résumons les conclusions et recommandations pour Firebird concernant le matériel.

Des processeurs multicœurs doivent être utilisés pour servir un grand nombre d’utilisateurs.
La quantité minimale de RAM est calculée sur la base du nombre d’utilisateurs et de la configuration de la base de données ; la quantité excédentaire de RAM sera utilisée efficacement par le système d’exploitation pour mettre en cache le fichier de la base de données.
Utilisez des disques séparés pour les bases de données, les fichiers temporaires et les fichiers de sauvegarde.
Utilisez plutôt des SSD pour les bases de données.
Réservez au moins 30 % d’espace libre sur les SSD.
Il est conseillé de dédier un disque à la base de données.
Utilisez des SSD d’entreprise (avec un grand nombre de cycles d’écriture/lecture).
Assurez-vous d’utiliser le RAID.
Pour les SSD - RAID 1, pour les disques durs - RAID10, pour les disques durs de sauvegarde - RAID1. i. SAS, SATA, nSAS
Assurez-vous que la batterie RAID est présente et chargée.
Assurez-vous qu’elle est commutée en écriture différée (write back).
Certains contrôleurs RAID ont déjà la taille du cache configurée, par exemple 75 % pour la lecture, 25 % pour l’écriture, ou 50/50, etc. Il est donc nécessaire d’installer MON$Logger - le logiciel qui contrôlera les paramètres RAID, recherchera le rapport lecture/écriture et modifiera les paramètres RAID.
L’utilisation de SAN présente des avantages et des inconvénients. Pour en tirer le meilleur parti, vous devez configurer le SAN correctement.
Pour construire une solution à l’épreuve des pannes, vous devez utiliser des solutions avec des répliques exécutées sur différents serveurs.

Contacts

La société IBSurgeon/IBase.ru développe un package de distribution avancé HQbird pour les entreprises, fournit un support technique complexe pour Firebird et développe des packages de distribution personnalisés ainsi que la résolution d’autres problèmes complexes.

IBSurgeon propose également un service d’optimisation Firebird pour améliorer les performances des bases de données Firebird.

Contactez-nous : [email protected]