Différences

Ci-dessous, les différences entre deux révisions de la page.

--- kb:linux:proxmox:benchmark_des_systemes_de_stockage [2020/04/02 22:07] – beu
+++ kb:linux:proxmox:benchmark_des_systemes_de_stockage [2020/04/04 14:32] (Version actuelle) – beu
@@ Ligne 3: / Ligne 3: @@
 ==== Introduction ====
-L'idée de cette page est de déterminer quel est la meilleure solution pour le stockage des Machines Virtuelles, afin de sortir quel système de stockage local, et quels options sont les plus judiciables d'un point de vue performance mais aussi en terme de fonctionnalité.
+L'idée de cette page est de déterminer quel est la meilleure solution pour le stockage des Machines Virtuelles, afin de sortir quel système de stockage local, et quelles options sont les plus judiciables d'un point de vue performance mais aussi en terme de fonctionnalité.
-J’essaie d’être le plus exhaustif en terme de configuration, même si certaines options ont pu être ignoré/oublié.
+J’essaie d’être le plus exhaustif en terme de configuration, même si certaines options ont pues être ignorées/oubliées.
 Afin de réaliser ce benchmark, je vais utiliser la machine suivante :
@@ Ligne 15: / Ligne 15: @@
 | ::: | Samsung SSD 970 EVO Plus NMVe 250GB  |
-Proxmox((a jour au 2020-04-01)), ainsi que la racine de la VM sont stocké sur le SSD Kingston, et tous les benchmarks seront fait sur le SSD NVMe Samsung qui est dédié uniquement a ceux-ci. \\
+Proxmox((a jour au 2020-04-01)), ainsi que la racine de la VM sont stocké sur le SSD Kingston, et tous les benchmarks seront faits sur le SSD NVMe Samsung qui est dédié uniquement a ceux-ci. \\
 Ce choix permet de limiter l'impact de limitation de bande passante d'IO, ni par d'autres usages.
@@ Ligne 43: / Ligne 43: @@
 ==== Les résultats ====
-J'ajoute quelques précisions pour mieux comprendre les résultats. Les valeurs "Host" présentent sur la totalité des graphs sont les valeurs de référence, en l'occurence ce que le Proxmox lui-même obtient comme resultat (pas dans un VM donc).
+J'ajoute quelques précisions pour mieux comprendre les résultats. Les valeurs "Host" présentes sur la totalité des graphs sont les valeurs de référence, en l’occurrence ce que le Proxmox lui-même obtient comme résultat (pas dans un VM donc).
 Ah, et les valeurs sont en MB/s
@@ Ligne 52: / Ligne 52: @@
 {{ :kb:linux:proxmox:disk-benchmark-cache.png |}}
 {{ :kb:linux:proxmox:disk-benchmark-snapshot.png |}}
-{{ :kb:linux:proxmox:disk-benchmark-thin-provisionning.png |}}
+{{ :kb:linux:proxmox:disk-benchmark-thin.png |}}
 Voici quelques remarques intéressantes :
-  * Les options **Discard**, **IO Thread** et **SSD Emulation** n'ont pas d’impacts sur les performances.((IO Thread peut-être utile dans le cas ou vous avez plusieurs disques))
+  * Les options **Discard**, **IO Thread** et **SSD Emulation** n'ont pas d’impacts sur les performances.((IO Thread peut être utile dans le cas ou vous avez plusieurs disques))
   * Le **VMDK** est extrêmement lent lors de l'écriture de nouveaux blocks a cause du Thin Provisionning, d'où la présence de deux passes
-  * Il n'y a pas de différences flagrante sur le système de fichier entre **ext4** et **xfs**
+  * Il n'y a pas de différence flagrante sur le système de fichiers entre **ext4** et **xfs**
-  * La libraire compression sur le **ZFS** n'a peu d’impact sur les performances. Mais si vous desactivez la compression, les performances sont plus faible ((Lors ce que la compression était désactivé, le proxmox avait tendance a redémarrer tout seul pendant les tests.))
+  * La libraire compression sur le **ZFS** n'a peu d’impact sur les performances. Mais si vous désactivez la compression, les performances sont plus faible ((Lors ce que la compression était désactivée, le proxmox avait tendance a redémarrer tout seul pendant les tests.))
-  * Le support de stockage **LVM** n'est pas affiché dans les précédents graphs car ne rentrant dans aucunes catégories. Pour faire simple, il n'a aucun avantage par rapport au Directory + RAW ou LVM-Thin. (1474MB/s Read, 2679MB/s Write)
+  * Le support de stockage **LVM** n'est pas affiché dans les précédents graphs car ne rentrant dans aucune catégorie. Pour faire simple, il n'a aucun avantage par rapport au Directory + RAW ou LVM-Thin. (1474MB/s Read, 2679MB/s Write)
-Pour approfondir le sujet, voici le document contenant tout les résultats aux tests effectué. FIXME
+Pour approfondir le sujet, voici {{ :kb:linux:proxmox:proxmox_disk_benchmark.ods |le document}} contenant tout les résultats aux tests effectué.
 ====Conclusion====
-Qu'elle système de stockage je recommande ?\\
+Quel système de stockage je recommande ?\\
 Même si il y a beaucoup de d'options possibles, je pense que d'utiliser la combinaison :
   * Controlleur SCSI VirtIO
-  * disques VirtIO
+  * disques VirtIO ((SCSI si pas compatible))
   * Pas de cache
   * Discard si compatible avec l'OS guest (a partir de Linux 5.0)
@@ Ligne 74: / Ligne 74: @@
 Après pour le support, j'en recommande 2, dépendant des besoins/possibilités:
-  * **Directory** avec images en **RAW**((qcow2 n'a plus vraiment d'intéret, si ce n'est les snapshots, car le thin-provisionning n'est plus supporté nativement par Proxmox)) car étonnament le plus performant, et permet simplement de partager ce volume avec les sauvegardes, les ISO, et autres....
+  * **Directory** avec images en **Qcow2** car supporte l'ensemble les fonctionnalités de thin-provisioning et les snapshot, et permet aussi simplement de partager ce volume avec les sauvegardes, les ISO, et autres....
   * **LVM-Thin** pour simplement le thin-provisionning, et le support des Snapshots.