Bonjour � tous,Salut Fabian
J'aimerais connaitre votre avis sur ces questions. Mon but est de solliciter le moins possible, au niveau de l'acc�s disque, CPU et Ram du serveur nomm� SERV1.
Imaginons donc deux servers. SERV1 cr�e des fichiers (a peu pres tout le temps) et SERV2 est cens� les r�cup�rer (toutes les 5 minutes) et faire du chipotage dessus.
Est-il pr�f�rable d'utiliser NFS et d'exporter le r�pertoire contenant les fichiers? Si oui, SERV2 ferait mieux de copier les fichiers sur son disque local pour les lire, ou devrait-il les lire sur le disque mont�?
Et compar� � un server FTP tournant sur SERV1?
Est-ce que l'une ou l'autre m�thode est plus favorable si ce sont des petits fichiers? ou des grands?
Plusieurs options sont possibles.
Soit SERV1 est l'initiateur et envoit activement les fichiers vers SERV2 (SERV2 faisant ainsi de la collecte passive), soit SERV2 est l'initiateur et va chercher les fichiers depuis SERV1 (SERV2 fait de la collecte active).
Donc soit:
- push: SERV1 ======envoit===> SERV2
- pull: SERV1 <==va chercher== SERV2
En outre, le type de transfert: - transfert isol�: FTP, HTTP, SSH (SCP) - transfert "connect�"/connectivit� permanente: NFS
Je ne prendrais d�j� pas FTP car il a un grand "overhead" dans sa phase de login: �a prend plus de temps pour se connecter que pour transf�rer un petit fichier.
SSH (scp) a le m�me probl�me, mais permet des transferts encrypt�s (si la s�curit� de ces donn�es est importante - je suppose que non - SCP est certainement le meilleur choix).
Tu devrais cr�er et utiliser des certificats sans passphrase pour �viter de devoir donner un mot de passe.
Remarque que si SERV1 ou SERV2 sont accessibles publiquement (ou par d'autres users), le niveau de s�curit� est d�j� moindre car les certificats ont plus de risques d'�tre compromis.
Soit, laissons de c�t� l'aspect s�curit� ;)
Pour un transfert "isol�" (je veux dire par l�: ouverture de connexion, envoi/r�ception du fichier, fermeture de connexion), HTTP est certainement le meilleur choix car il a un "overhead" minimal (le handshake TCP, c'est tout).
De plus, il y a tout ce qu'il faut question outils pour mettre �a en place rapidement:
- c�t� serveur (*): Apache, Tomcat ou un autre serveur HTTP plus l�ger (il y en a une multitude)
- c�t� client (*): curl, wget
(*) client ou serveur: �a d�pend du choix de strat�gie pour d�cider de l'initiateur du transfert (push ou pull), �a peut �tre SERV1 ou SERV2 ;)
Encore plus l�ger que HTTP: RCP, mais il n'est vraiment pas tr�s s�curis�. Note que c'est du TCP aussi => overhead handshake TCP.
Mais il est plus facile � mettre en place que HTTP (quoique... ;)).
Note que �a d�pend un peu de la fr�quence des transferts, mais si c'est toutes les x minutes, l'overhead TCP est � ignorer.
NFS a l'avantage de co�ter le moins en terme d'overhead, il n'y a pas de connexion � proprement parler (en tout cas pas pour chaque transfert) et est tr�s simple � mettre en place.
Il a n�anmoins l'inconv�nient de g�rer tr�s difficilement les situations d'erreur (perte de connectivit� entre SERV1 et SERV2). Il n'est pas tr�s "failsafe" ;)
Avec des connexions �tablies � chaque transfert (p.ex. HTTP ou RCP), tu re�ois imm�diatement un message d'erreur sur l'initiateur.
Alors quant � choisir entre le mod�le push et pull...
Personellement, je trouve le mod�le push plus int�ressant et plus facile � mettre en place, car tu �vites que (dans un mod�le pull) SERV2 se connecte � SERV1 pour voir s'il a des fichiers � t�l�charger alors qu'il n'y en a peut-�tre pas.
Avec le mod�le push, c'est un transfert actif:
- SERV1 cr�e un fichier
- SERV1 initie le transfert et fait p.ex. un RCP ou un upload FTP vers SERV2
Note que le mod�le push est plus difficile � mettre en place avec HTTP: tu devrais pour cela avoir quelque chose du c�t� serveur HTTP (SERV2) qui prend les donn�es envoy�es par POST (HTTP) afin de les sauvegarder sur disque... beurk ;)
Si tu choisis HTTP, prends plut�t le mod�le pull:
- SERV1 cr�e les fichiers et ne s'occupe pas du transfert, et cela dans un r�pertoire accessible via p.ex. Apache
- SERV2, toutes les x minutes (p.ex. via cron), initie le transfert (pull) des fichiers via HTTP (p.ex. avec wget ou curl)
Voil�, voil� ;)
-- -o) Pascal Bleser http://guru.unixtech.be /\\ <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> _\_v The more things change, the more they stay insane.
_______________________________________________________ Linux Mailing List - http://www.unixtech.be Subscribe/Unsubscribe: http://www.unixtech.be/mailman/listinfo/linux Archives: http://www.mail-archive.com/[EMAIL PROTECTED] IRC: efnet.unixtech.be:6667 - #unixtech
