Discussion :

[Niclass]

Bonsoir , j'ai un serveur Node.js qui attaque une BDD Firebird, je voulais savoir s'il était possible de monter 2 serveurs firebird sur 2 port différent pour que si le serveur 1 tombe les requêtes soient directement captées par le second serveur ?

Une autre question : j'ai 25 clients sur ce serveur avec 25 bases de 1Go et 30 users simultanés sur chaque base, sachant que chaque user ouvre son propre pool de 5 connections à sa base... Quelle architecture serveur pensez-vous être là meilleure (Linux,Windows) ? Quelle type de serveur fb (classic, superserver...) ? 1 serveur firebird par client ou 1 pour tout le monde ?

Merci d'avance

[SergioMaster]

Bonjour et bienvenue ,

je voulais savoir s'il était possible de monter 2 serveurs firebird sur 2 port différent

Oui, bien que la suite me laisse perplexe

pour que si le serveur 1 tombe les requêtes soient directement captées par le second serveur ?

là, je vois pas, déjà, le terme "tomber" : arrêt du de firebird ou baisse des performances ?

Une autre question : j'ai 25 clients sur ce serveur avec 25 bases de 1Go et 30 users simultanés sur chaque base, sachant que chaque user ouvre son propre pool de 5 connections à sa base... Quelle type de serveur fb (classic, superserver...) ? 1 serveur firebird par client ou 1 pour tout le monde ?

j'ai vu un schéma qui résume bien les différents apport de chaque type de serveur
http://www.sinatica.com/blog/en/inde...r-superclassic
qui devrait donner les réponses à cette question

Quelle architecture serveur pensez-vous être là meilleure (Linux,Windows) ?

ça ce n'est pas vraiment une question Firebird, mais un choix d'OS, A.M.H.A. Linux est certainement plus "secure et fiable" que Windows mais ce n'est que mon avis personnel, peut être une réponse moins "affective" dans cette vidéo

et dans cette documentation

[Niclass]

Bonjour et merci pour ta réponse

En fait actuellement nous avons 1 superserver de monté par client, nous avons penser ne plus mettre qu'un seul pour l'ensemble des clients.
Mais au cas ou il y ai un soucis avec ce serveur (crash du process -> tomber ) qu'il y en ai un second qui reprenne nativement le relais pour que ce soit transparent pour les utilisateurs, une espèce de clustering du serveur firebird semblable au clustering de NodeJS.

Au vu du lien de Sinatica, il semble en effet que notre solution idéale serait d'utiliser un ClassicServer

Nous poursuivons nos investigations

[SergioMaster]

Bonjour,

Mais au cas ou il y ai un soucis avec ce serveur (crash du process -> tomber ) qu'il y en ai un second qui reprenne nativement le relais pour que ce soit transparent pour les utilisateurs, une espèce de clustering du serveur firebird semblable au clustering de NodeJS.

Je ne connais pas NodeJs, donc j'aurais du mal à faire la comparaison. Ce que je sais en revanche (à mes dépends quelquefois) c'est qu'avec le Firebird Guardian un crash serveur firebird est vite géré et le service redémarré. En fait ce que je ne vois pas c'est comment se ferait la gestion, par le programme, du changement de port pour utiliser l'autre instance de Firebird

Au vu du lien de Sinatica, il semble en effet que notre solution idéale serait d'utiliser un ClassicServer

c'est ce sur quoi je pencherai aussi quoique le superclassic soit aussi très attrayant, l'idéal dans votre config aurait été un mix entre ces deux derniers chaque Client <- ici je parle de Société clients (et donc tout ses utilisateurs) ayant une instance SuperClassic, pour avoir autant de fbserver que de société et autant de cache par fbserver que d'utilisateurs (bref d'ouvrir/de faire autant de port/installation que de société en mode super classic.)
Maintenant cela semble un peu "délire" si P.Makowski passe par là qu'il me corrige

[Niclass]

En effet, nous sommes toujours en dicussion avec les collègues sur le choix du serveur FB ...

Merci par avance pour tes éclaircissements

[SergioMaster]

Bonjour,

si vous avez arrêté votre choix de SGBD pourquoi ne pas faire appel à un expert en la matière P.Makowski
il ne passe plus beaucoup (hélas) sur ce forum mais un mail privé pour faire appel à ses services pourrait peut être avoir une réponse (après tout c'est son activité une heure de son temps ne doit être si difficile à budgétiser et vous en ferais gagner beaucoup)

[makowski]

Bonsoir , j'ai un serveur Node.js qui attaque une BDD Firebird, je voulais savoir s'il était possible de monter 2 serveurs firebird sur 2 port différent pour que si le serveur 1 tombe les requêtes soient directement captées par le second serveur ?

il faudrait définir "tombe" , en fait Classic Serveur c'est déjà un peu ça, puisque que c'est un process par connection, donc s'il y a un crash dans une connexion les autres ne sont pas affectées.

sinon, mettre deux Firebird en // avec un en secours, c'est possible aussi, une replication et un PaceMaker (http://www.linux-ha.org/wiki/Pacemaker) cela permet de le faire.
voir aussi la conf de RedSoft http://ibphoenix.com/files/conf2016/...dSoft-2016.pdf

[Niclass]

Merci Philippe pour ta réponse, et encore une dernière question sur quel type d'architecture m'orienterais tu ?

Actuellement nous avons un superserver par client ?

Cordialement.

[makowski]

Actuellement nous avons un superserver par client ?

oui pourquoi pas, surtout sus Windows, et encore plus avec fb3

mais cela reste des généralités.

[Niclass]

Je reviens sur ce post,

nous avons débuté la migration sur une seconde VM de notre applicatif sous FB3...

nous avons cependant un problème au niveau de la mémoire, en effet quand sous firebird 2.5.4, le serveur occupait entre 50Mo à 80Mo,
avec firebird 3.0 le process monte jusqu'à 500Mo !

Les performances sont équivalentes à priori et le firebird.conf n'a pas été modifié dans les deux cas !

Une idée ?

[Artemus24]

Salut à tous.

je voulais savoir s'il était possible de monter 2 serveurs firebird sur 2 port différent ...

La réponse est oui, dans cette première partie de votre phrase, mais je ne voie pas trop l'intérêt de multiplier les serveurs.

... pour que si le serveur 1 tombe les requêtes soient directement captées par le second serveur ?

Ce dont vous parlez se nomme de la réplication.
Vous avez deux serveurs dont l'un est le maitre et l'autre est l'esclave.
Je sais que cela existe sous MySql (MariaDB), mais sous FireBird je ne sais pas s'il y a quelque chose d'équivalent.

Je ferai la même remarque que mes autres collègues, qu'est-ce que vous entendez par "tomber" ?

Un problème réseau fait que le serveur ne soit plus disponible.
Un timeout est aussi une façon de rendre votre tâche indisponible.
Un problème avec un disque. Si vous n'êtes pas en RAID, vous allez devoir vous taper les manipulations et vous faire perdre beaucoup de temps.
Une indisponibilité du serveur est peu probable, sauf si vous l'avez mal configuré.
Par exemple, vous avez un problème de mémoire car trop d'utilisateurs accèdent en même temps.

Le mieux est d'invertir dans le matériel pour obtenir ce que l'on nomme une tolérance de panne.
Le cas du backup, des disques montés en RAID avec effet miroir ...

Et après il reste l'aspect serveur FireBird.
N'étant pas trop spécialiste de ce qui touche l'aspect système, le mieux est de se reporter à la documentation pour s'informer sur les différences de choix.
--> https://firebirdsql.org/manual/qsg25...-or-super.html
--> https://firebirdsql.org/manual/fr/qs...-or-super.html
--> http://www.firebirdmanual.com/firebi...uperclassic/10

Après la véritable question est le choix de votre serveur SGBD.
Comme il y a une monté en puissance, est-ce que FireBird put répondre à vos attentes ?

Les performances sont équivalentes à priori et le firebird.conf n'a pas été modifié dans les deux cas !
Une idée ?

Ce n'est plus exactement le même serveur FireBird.
Pourquoi passez-vous à la version 3.0 ?

@+

[vanquish]

Ce dont vous parlez se nomme de la réplication.
Vous avez deux serveurs dont l'un est le maitre et l'autre est l'esclave.
Je sais que cela existe sous MySql (MariaDB), mais sous FireBird je ne sais pas s'il y a quelque chose d'équivalent.

Il existe des solutions à base de triggers, mais cela me semble lourd à mettre en place.
J'ai découvert il y a peu une solution proposé par ib Surgeon : HQBird (la config à 800€)
http://ib-aid.com/en/hqbird/
Je n'ai pas encore testé, mais cela semble intéressant.

[Niclass]

Merci pour vos réponses,

nous avons décider de migrer sous Firebird 3.0 afin de bénéficier des dernières améliorations du moteur de base de données et comme nous avons ré-écrit une partie de notre serveur NodeJS pour passer à la version 6, nous avons profiter de ceci pour upgrade la version de Firebird en 3.0.

Du coup le constat est flagrant, avec le Firebird 2.5, le simple fait de lancer notre serveur node et de lancer un pool de connexions, le service consomme 9 Mo de mémoire et avec un Firebird 3.0 la création du pool fait monter le serveur à 60 Mo.

Je me posais donc la question s'il n'y avait pas de modifications à effectuer au niveau du firebird.conf de FB3.0 pour se rapprocher de la consommation mémoire du Firebird 2.5 ?

[vanquish]

Vous avez 25 bases.
Si chacune d'entre elle a un cache de 4 Mo (ce qui est faible pour une base de 1 Go), ça fait tout de suite 100 Mo.

Ca c'est en SuperServeur.
En mode classique, le cache est alloué pour chaque connexion ; ça peut donc monter très vite.

A noter qu'avec FB 3.0, sauf cas spécifique, le mode classique n'a plus beaucoup d'intérêt.

Le cache peut se paramétrer avec gfix (ou flame robin etc.) au sein même du FDB.
Si à zéro dans le FDB, on peut définir un cache par défaut dans firebird.conf ou encore (le mieux à mon sens) par base dans database.conf

Je parle de Mo, mais en fait le cache se défini en 'pages' (de 4, 8 ou 16 ko en fonction de la base).

La différence peut venir de la taille des pages entre la base original en FB 2.5 et la base remonté en FB 3.0
Si, lors du remontage du backup, la page est passé de 4 à 16 Ko, l'occupation mémoire a quadruplé.

Sinon, le principe du système de cache n'a guère changé entre Fb 2.5 et 3.0. (superserveur est devenu multi-thread, mais il alloue toujours un cache partagé par toutes les connexions à une même base).

[Niclass]

Notre test a été effectué avec 1 seule base sur le serveur firebird:
- les deux versions en superserver
- un page size identique de 16384
- un fichier firebird.conf vierge

à noter que nous avons un post en parallèle sur stackoverflow et que l'on nous remonte qu'il y aurait des memoryleak avec notre version de Firebird 3.0.2 ...
enfin ç ce niveau ce n'est plus une fuite mais le robinet qui est ouvert à fond

[vanquish]

Effectivement :
http://tracker.firebirdsql.org/brows...story-tabpanel

Si ce n'est qu'en test pourquoi ne pas essayer avec un snapshot_builds ?
https://www.firebirdsql.org/en/snapshot-builds/

A priori, c'est corrigé dans la 3.0.3

Ce qui m'épate c'est la différence dès la phase de connexion.
Mais la consommation initiale n'est pas un vrai problème si cela reste stabilisé à l'usage.

Je suis intéressée par votre retour.