un système de fichier répliqué mais où toutes les requêtes passe sur le serveur primaire (lors n'étant qu'une réplication) et que les performances soit du coup proche de NFS. De la même manière la réplication peut être asynchrone.
bascule à chaud ou non ?
si tu veux une bascule à chaud, il faut une VIP qui va passer de primaire sur secondaire ainsi quand S1 sera down, S2 prend le relais et tes applis continuent d'interroger l'IP VIP
mais ca ne pourra pas se faire avec du kimsufi qui ne peuvent pas partager un pool d'IP failover.
si tu veux faire un systeme "maitre/slave" tu peux simplement faire :
- un rsync de temps en temps
- un disque en DRBD : replication de niveau bloc
le probleme commence à arriver quand tu veux que les 2 serveurs ecrivent tous les deux dans l'espace commun et c'est qu'entre en jeu les systemes de fichiers distribués
- glusterfs
- ceph
pour la performance il faut aussi que tu regardes les bandes passantes alloués en "interne" à tes machines.
chez kimsufi c'est un reseau à 100Mbps au cul de chaque machine
donc si tu as en plus un peu de trafic, ben il n'en reste pas beaucoup pour la replication de données entre les machines.
et evidemment les performances des disques et CPU des machines
car c'est quand meme cela qui va impacter aussi les performances
sinon sur internet, il y a des comparatifs de performances hadoop/ceph/glusterfs et ca semble glusterfs qui sort gagnant (sur leur infra)
on trouve aussi des tunings comme les desactivations des caches, la gestion des buffers...
# pas simple avec ton infra
Posté par NeoX . En réponse au message Système de fichier distribué 'rapide'. Évalué à 2.
bascule à chaud ou non ?
si tu veux une bascule à chaud, il faut une VIP qui va passer de primaire sur secondaire ainsi quand S1 sera down, S2 prend le relais et tes applis continuent d'interroger l'IP VIP
mais ca ne pourra pas se faire avec du kimsufi qui ne peuvent pas partager un pool d'IP failover.
si tu veux faire un systeme "maitre/slave" tu peux simplement faire :
- un rsync de temps en temps
- un disque en DRBD : replication de niveau bloc
le probleme commence à arriver quand tu veux que les 2 serveurs ecrivent tous les deux dans l'espace commun et c'est qu'entre en jeu les systemes de fichiers distribués
- glusterfs
- ceph
pour la performance il faut aussi que tu regardes les bandes passantes alloués en "interne" à tes machines.
chez kimsufi c'est un reseau à 100Mbps au cul de chaque machine
donc si tu as en plus un peu de trafic, ben il n'en reste pas beaucoup pour la replication de données entre les machines.
et evidemment les performances des disques et CPU des machines
car c'est quand meme cela qui va impacter aussi les performances
sinon sur internet, il y a des comparatifs de performances hadoop/ceph/glusterfs et ca semble glusterfs qui sort gagnant (sur leur infra)
on trouve aussi des tunings comme les desactivations des caches, la gestion des buffers...