Un NAS (QNAP TVS 671) en serveur de BDD?

Salut
ma question va paraître un peu bête, mais j'avoue que je sèche un peu.

Je suis médecin et je viens d'installer une configuration réseau pour notre nouveau cabinet. L'usage est essentiellement un logiciel de gestion de dossiers patients, une BDD donc.

La configuration actuelle comprend:
- un serveur: I7, 16Go de RAM, SSD, Carte ethernet 1Gbt
- 16 postes client: I5, 8Go de Ram, SSD sur tous les poste, ethernet 1Gbt
- tous les câbles sont de catégorie 6
- switch paramétrable full duplex 1Gbt

Malgré tout cela, l'accès à certaines données sont extrêmement lents sur les postes clients, alors que sur le serveur cet accès est assez rapide. En même temps je ne vois pas comment améliorer le réseau dans la configuration actuelle. Les seuls choix possibles, AMHA seraient:

- prendre un serveur de type Xeon (mais bonjour le coût) genre dell.... Mais quel configuration? une proposition?
- prendre si possible mon QNAP TVS 671 en replaçant les DD par des SSD (le tout en raid) et et utiliser les 4 ports ethernet en agrégation, sachant qu'il a 4Go de Ram

Alors voici mes questions:
1°- Le choix d'un Nas QNAP est il pertinent ou faut il partir sur serveur dédié classique?
2°- Si on peut partir sur le QNAP, comment le paramétrer pour avoir les meilleurs flux sur le réseau (type Raid en particulier, le type d'agrégation des ports?)

Merci de vos avis

Avant de vouloir changer le matériel, il serait plus utile de comprendre pourquoi tu as ces lenteurs.

- Lenteur réseau ?
- IOPS sur le serveur ?
- requêtes mal fichues ?

Citation:

---

Envoyé par becket

Avant de vouloir changer le matériel, il serait plus utile de comprendre pourquoi tu as ces lenteurs.

- Lenteur réseau ?
- IOPS sur le serveur ?
- requêtes mal fichues ?

---

Merci de ta réponse.
A priori:
- je ne vois pas de lenteur réseau, mais comment puis je le quantifier?
- OS sur tous les postes est W7 pro
- les requêtes sont identiques qq soit le poste de travail, et pour être précis, c'est l'ouverture d'un dossier qui est très long sur les postes clients, alors que sur le serveur, ca se passe plutôt bien

Amitiés
Nikan

Un NAS pour gérer une base de données n'est pas forcément la meilleure chose. Un NAS normalement sert de stockage sur le réseau.

Je présumes que le moteur de bases de données est stocké sur un serveur. Les fichiers de bases de données sont sur le SSD du serveur ?

Quel est le moteur de base de données ? Je pencherais comme ça sur un problème d'optimisation bases de données.
Tu peux tester le temps de copie de 20 Go de données sous forme de fichiers entre un client et le serveur, de façon à estimer la vitesse et voir si elle est normale.

Citation:

---

Envoyé par chrtophe

Un NAS pour gérer une base de données n'est pas forcément la meilleure chose. Un NAS normalement sert de stockage sur le réseau.

Je présumes que le moteur de bases de données est stocké sur un serveur. Les fichiers de bases de données sont sur le SSD du serveur ?

Quel est le moteur de base de données ? Je pencherais comme ça sur un problème d'optimisation bases de données.
Tu peux tester le temps de copie de 20 Go de données sous forme de fichiers entre un client et le serveur, de façon à estimer la vitesse et voir si elle est normale.

---

A vrai dire, la BDD est assez comment dirais je, obscure :mouarf: elle est bien sur la SSD
C'est un logiciel de gestion de dossier médical, avec probablement une BDD propriétaire
Je vais tester la vitesse sur le réseau comme tu me le proposes.`
Mais pour le coup, si je devais améliorer le serveur, que puis je faire de plus que la configuration actuelle? Le fait d'ajouter des cartes réseaux et les agregger peut il améliorer les choses? Ou alors mettre plusieurs SSD et monter un Raid? Si oui quel type de Raid serait le plus rapide. Petite précision, la taille totale des fichiers de la BDD n'excède pas 2 Go...Donc je n'ai pas besoin d'un monstre de stockage

Tu as déjà une machine correcte, je suis pas sûr que d'en mettre une plus puissante améliore les choses, il faudrait pouvoir tester sans echeter le matériel. Je soupçonne le logiciel propriétaire de ne pas être optimum, exemple utilisation de fichier à plat genre hyperfile et non une base de données SQL.

je suis assez d'accord avec toi. Je soupconne aussi le Type de BDD, et je pense que l'on est prisonnier de l'éditeur. Ca fait plus de 15 ans que l'on demande de passer en SQL. Nada

Citation:

---

Envoyé par chrtophe

Tu peux tester le temps de copie de 20 Go de données sous forme de fichiers entre un client et le serveur, de façon à estimer la vitesse et voir si elle est normale.

---

Quelle est la vitesse "normale" d'une telle copie sur un réseau en Gbites? Logiquement je dirais 20 secondes si je fais un simple calcul mathematique, mais je suppose que c'est trop simple :mouarf:

Gbits/s != Gbytes/s

Je dirais 3-4 minutes.

1octet=8 bits
20Go*8=160 Gbits, auxquels il faut ajouter une charge pour les contrôles, disons arbitrairement 15%
160 Gbits+15%=184Gbits
A une vitesse de 1Gbits, il te faudra 184 secondes soit 3 minutes. Mais il fait prendre en compte les autres choses que font les machines qui peuvent ralentir la copie, 5 minutes pourraient être considérés normales, mais pas 10 par exemple.

Après, il y a des outils pour tester plus précisément.

Dans le cas d'une base de données, un accès sans SQL peut être pénalisant, car le fichier peut être parcouru jusqu'à trouver les données recherchées, et sauter d'un enregistrement à un autre, même de façon séquentielle est pénalisant en temps. d'accès.

OK Christophe
Merci pour ces précisions.
Je viens de faire des tests avec un outil dédié (Lan Speed Test) entre un poste client et le serveur., sur un fichier de 1Go. Voici les résultats:


Date: 2018-04-08 08:21:18
Folder or Server IP: 192.168.1.3
Packet Size: 1 GB to 1 GB
Packet Size Avg: 1,000,000,000 Bytes
Packets: 1
Total Test Time: 38.08968 sec
Throughput: Average
Write: 15,7740 (507*163*044)
Read: 19,5579 (409*041*243)
Write Speed: 507,16 Mbps
Read Speed: 409,04 Mbps
Write Cache: Enabled
Read Cache: Disabled
Status: Finished...

qu'en penses tu?

Citation:

---

Envoyé par chrtophe

Je dirais 3-4 minutes.

1octet=8 bits
20Go*8=160 Gbits, auxquels il faut ajouter une charge pour les contrôles, disons arbitrairement 15%
160 Gbits+15%=184Gbits
A une vitesse de 1Gbits, il te faudra 184 secondes soit 3 minutes. Mais il fait prendre en compte les autres choses que font les machines qui peuvent ralentir la copie, 5 minutes pourraient être considérés normales, mais pas 10 par exemple.

Après, il y a des outils pour tester plus précisément.

Dans le cas d'une base de données, un accès sans SQL peut être pénalisant, car le fichier peut être parcouru jusqu'à trouver les données recherchées, et sauter d'un enregistrement à un autre, même de façon séquentielle est pénalisant en temps. d'accès.

---

Ben bon je viens de faire un test avec un fichier unique de 35 Go. Si je me cale sur ton calcul + charge de controle, je devrais arriver entre 5 et 6 minutes. La copie de SSD en SSD, ca m'a pris 7min30.
Donc je pense que le réseau est bon.
Ca doit venir de ma BDD qui est merdique

Il n'est pas certains que ce soit la base de données. Mêmes des bases de données dites "à plat" (un fichier texte ou binaire par table, la base étant le répertoire les stockant) comme du Hyperfile, Paradox, etc.... sont quand même relativement performantes pour une utilisation raisonnable.

Maintenant, est-ce que la base de données est correctement construite, que fait le logiciel avec cette base. Peut-être bien qu'à l'ouverture de la fiche, il spamme la base de requêtes inutiles (j'ai connu ça, 50 fois la même très grosse requête à l'ouverture d'un écran, sans raison réelle), peut-être bien qu'il fait des recherches sur certains paramètres, qui sont extrêmement lentes parce que la base a été mal construite.
Tout ça n'est pas un problème de base de données en tant que telle, tout ça est un problème de conception et de développement, donc un problème incombant à l'éditeur de ton logiciel.

Tu peux toujours te retourner vers lui pour qu'il analyse la situation et résout ton problème.

Ou te tourner vers la concurrence ;)

Sevyc a raison mais utiliser SQL pourrait permettre de meilleures performances. En tout cas pour moi, ce n'est pas un problème de performance de ta machine.

La plupart des bases de données, même à fichier plat, s'interroge en SQL. Le problème n'est pas SQL ou pas. A la limite on pourrait parler de problème de performance du moteur de base données qui peut être moindre, mais je ne pense pas que ce soit le problème ici, tout au moins pas le problème primordial. On peut très bien faire des bases très performantes sur des moteurs moins performants et faire des bases complètements inutilisable sur du SQLServer pourtant un des plus performant du moment.

Un logiciel pour un cabinet médical ne manipule pas tant que ça de données (ayant travailler pour le domaine de la dentisterie pendant quelque temps, je connais un peu), il ne nécessite pas forcément le summun de la performance en matière de moteur de base de données. Il ne nécessite pas forcément du SQLServer, Oracle ou autre DBase.
Des systèmes comme Hyperfile, Firebird (ce que l'on avait, nous), etc, sont largement suffisant en principe.

De toute façon, le choix du type de base de données reste à la discrétion de l'éditeur qui fait ce qui veut sur ce point à partir du moment ou le logiciel est son propre produit. La seule solution est d'obtenir une oreille attentive de l'éditeur qui analyse, identifie le problème et le corrige dans son logiciel.


Mais je suis de l'avis général, de prime abords la config matérielle n'est pas en cause. Peut-être un paramétrage très spécifique du réseau ou des postes, mais comme cela fonctionne correctement avec d'autres logiciels à coté, ça ne peut être vu qu'avec l'éditeur du logiciel.

Bonjour,
Merci infiniment vous venez de répondre à ma question , c'est vraiment super :-)