A voir également:
- Concurrent OPENSSH
- Concurrent action - Guide
- Nouveau concurrent netflix - Accueil - Streaming
- Concurrent wawacity - Accueil - Outils
- Concurrent gamsgo - Accueil - Services en ligne
- Openssh - Télécharger - Divers Web & Internet
2 réponses
Sous linux, non je ne pense pas. Quel intérêt de toute façon ?
Tung
Messages postés
187
Date d'inscription
Statut
Membre
Dernière intervention
8
au fait , on a un petit projet à faire sur la synchronisation inter serveur , et bien sur pendant la présentation faut présenter les différentes outils disponible puis sélectionné la plus performante , tu vois ce que je veux dire ?
Pour de la synchronisation je ferais plutôt du rsync, qui peut tourner sur ssh. En fait tu dois faire la distinction entre l'outil qui va servir pour le transport (par exemple ssh) et celui qui fait la synchronisation.
Si par exemple il s'agissait uniquement de fichiers textes (comme c'est le cas pour un code source), on pourrait envisager svn, qui peut tourner sur http, https, ssh ou en direct.
Ensuite si le but est d'avoir à tout instant deux arborescences identiques, c'est peut être plutôt un partage de fichiers sur le réseau que tu cherches (cf samba et nfs).
Bref ça dépend de ce que tu veux faire, de ton besoin etc...
Si par exemple il s'agissait uniquement de fichiers textes (comme c'est le cas pour un code source), on pourrait envisager svn, qui peut tourner sur http, https, ssh ou en direct.
Ensuite si le but est d'avoir à tout instant deux arborescences identiques, c'est peut être plutôt un partage de fichiers sur le réseau que tu cherches (cf samba et nfs).
Bref ça dépend de ce que tu veux faire, de ton besoin etc...
le but du projet est de sauvegarder une copie de chaque base de données mysql de chacun des serveurs dans l'autre.
Exemple :
j'ai 3 serveurs A et B et C contenant respectivement les base de données BDA,BDB,BDC.
donc on doit synchroniser les 3 serveurs afin que chaque serveur contient en plus de sa base de donnée ,une copie des 2 autres bases.
On a prévue pour le transport d'utiliser OpenSSH puisqu'il est déjà présent sous linux.
Pour la synchronisation on a le choix entre UNISON et RSYNC.
Si vous pouvez me dire si une comparaison entre Telnet et OpenSSH pourrait m'être utile dans la presentation ?
et qu'elle est la meilleur solution entre les 2 synchroniseur ( UNISON et RSYNC.) ?
Merci d'avance.
Exemple :
j'ai 3 serveurs A et B et C contenant respectivement les base de données BDA,BDB,BDC.
donc on doit synchroniser les 3 serveurs afin que chaque serveur contient en plus de sa base de donnée ,une copie des 2 autres bases.
On a prévue pour le transport d'utiliser OpenSSH puisqu'il est déjà présent sous linux.
Pour la synchronisation on a le choix entre UNISON et RSYNC.
Si vous pouvez me dire si une comparaison entre Telnet et OpenSSH pourrait m'être utile dans la presentation ?
et qu'elle est la meilleur solution entre les 2 synchroniseur ( UNISON et RSYNC.) ?
Merci d'avance.
Telnet c'est pas chiffré, ça ne devrait pas être utilisé. Dans ton cas je t'invite à n'utiliser que ssh. Pour synchroniser des bases de données rsync ne fonctionnera pas bien. Plusieurs approches pour le faire
A) Backup physique :
1) le serveur source et cible,
2) faire une archive de la base sur le serveur source,
3) lancer le serveur source
4) la copier avec scp vers le serveur cible,
5) décompresser l'archive
6) lancer le serveur cible
Avantages :
- rapide en temps,
- coût en espace disque raisonnable
Inconvénients :
- pas adapté à certains moteurs de base de donnés (par exemple si tu utilises MySQL, ça peut le faire en MyISAM mais pas en InnoDB, pour lequel il faudrait se tourner vers innoDBHotBackup par exemple)
- problème de compatibilité éventuel si les versions des serveurs diffèrent.
- la synchronisation se fait pour le backup physique mais n'est pas faite en permanence (d'où son nom de backup)
B) Backup logique :
1) Lancer un dump de la ou les bases à sauver avec la commande mysqldump sur le serveur source
2) Transférer le dump via scp vers le serveur cible
3) Charger le dump sur le serveur cible à l'aide de la commande mysql.
Avantages :
- pas de problème de version
- pas d'interruption de service
Inconvénients :
- lent
- coûteux en espace disque
- la synchronisation se fait pour le backup physique mais n'est pas faite en permanence (d'où son nom de backup)
C) Réplication mysql :
http://dev.mysql.com/doc/refman/5.0/fr/replication.html
Avantages :
- synchronisation permanente (on peut l'utiliser pour mettre en place un cluster mysql conjointement avec mysql-proxy)
- peu coûteux en espace disque
Inconvénients :
- plus complexe à mettre en place (nécessite quelques notions en administration mysql et en réseau)
- nécessite de modifier la configuration mysql (/etc/mysql.my.cnf) et d'ajouter sur le serveur maître un profil mysql.
- la communication entre les deux serveurs n'est pas chiffrée par défaut mais mysql propose des solution basées sur SSL et X509 pour chiffrer la réplication. Une autre approche consiste à faire circuler la communication via un tunnel ssh. Toutefois chiffrer une réplication et plus généralement du trafic mysql dégrade très sensiblement les performances.
Bonne chance
A) Backup physique :
1) le serveur source et cible,
2) faire une archive de la base sur le serveur source,
3) lancer le serveur source
4) la copier avec scp vers le serveur cible,
5) décompresser l'archive
6) lancer le serveur cible
Avantages :
- rapide en temps,
- coût en espace disque raisonnable
Inconvénients :
- pas adapté à certains moteurs de base de donnés (par exemple si tu utilises MySQL, ça peut le faire en MyISAM mais pas en InnoDB, pour lequel il faudrait se tourner vers innoDBHotBackup par exemple)
- problème de compatibilité éventuel si les versions des serveurs diffèrent.
- la synchronisation se fait pour le backup physique mais n'est pas faite en permanence (d'où son nom de backup)
B) Backup logique :
1) Lancer un dump de la ou les bases à sauver avec la commande mysqldump sur le serveur source
2) Transférer le dump via scp vers le serveur cible
3) Charger le dump sur le serveur cible à l'aide de la commande mysql.
Avantages :
- pas de problème de version
- pas d'interruption de service
Inconvénients :
- lent
- coûteux en espace disque
- la synchronisation se fait pour le backup physique mais n'est pas faite en permanence (d'où son nom de backup)
C) Réplication mysql :
http://dev.mysql.com/doc/refman/5.0/fr/replication.html
Avantages :
- synchronisation permanente (on peut l'utiliser pour mettre en place un cluster mysql conjointement avec mysql-proxy)
- peu coûteux en espace disque
Inconvénients :
- plus complexe à mettre en place (nécessite quelques notions en administration mysql et en réseau)
- nécessite de modifier la configuration mysql (/etc/mysql.my.cnf) et d'ajouter sur le serveur maître un profil mysql.
- la communication entre les deux serveurs n'est pas chiffrée par défaut mais mysql propose des solution basées sur SSL et X509 pour chiffrer la réplication. Une autre approche consiste à faire circuler la communication via un tunnel ssh. Toutefois chiffrer une réplication et plus généralement du trafic mysql dégrade très sensiblement les performances.
Bonne chance