Commit ebe40858 authored by Thierry Fenasse's avatar Thierry Fenasse

quelques captures et un début de readme

parent 79612e80
GlusterFS
=========
Bottleneck ?
------------
* la vitesse du disque en lecture et écriture
* la vitesse du contrôleur en lecture et écriture
* la vitesse de la carte réseau du serveurs
Donc l'idée arrive vite d'avoir **plusieurs disques**, peut-être sur **plusieurs contrôleurs**, et aussi **plusieurs cartes réseaux**, voir **plusieurs serveurs**.
Mais tout ça coûte en électricité !
Si par exemple 1000 clients sont entrain d'uploader leurs vidéos de vacances et leur photos hautes définitions dans leur « cloud personnel », c'est 1000 clients seront limités par leur **vitesse d'envoi** respectives.
Si ces 1000 clients téléchargent leur données sur leur nouvel ordi pour en avoir une copie locale, c'est 1000 clients seront limités par leur **vitesse de réception**.
Si tout ça se fesait vers des serveurs dont les accès réseaux seraient limités à du Gigabit (100Mbps), c'est cette connexion qui serait la limite. **Mais**, si cette connexion tombe sur un serveur de stockage dont les disques plafonnent à du 60Mbps, ce sont eux qui limiteront le débit, peut importe le nombre de clients.
Par rapport à ces limitations, seul la **distribution** vers plusieurs serveurs ou plusieurs disques pourrait lever les limitations de ces vitesses.
Distribuer des données, c'est bien, ça réparti la charge, mais encore faut-il les sauvegarder. Et là c'est la **réplication** qui entre en compte. En effet, le modèle qui compine la **distribution et la réplication** est possible avec GlusterFS (ou d'autres), c'est qu'il y a une raison. L'un pour augmenter la rapidité grace à la distribution de la charge de travail et augmenter la vitesse, l'autre pour assure la dosiponibilité en réplicant les données vers plusieurs systèmes simultanément.
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment