Bonjour, Simple question autour de la virtualisation avec KVM : comment partagez vous les disques entre plusieurs systèmes hôte, afin de pouvoir faire du live-migration ou du start on failure (équivalent Vmware HA) ? NFS ? DRBD ? ISCSI ? autre système de partage de fichier ?
Si vous disposez d'un SAN, prenez vous le pari d'open-iscsi, ou montez vous un opensolaris à coté qui repartage après en NFS/whatever ? Je pose cette question saugrenue car il me semble avoir entendu dire que l'implémentation de iscsi sous solaris est plus stable (est ce vrai ?)
Par ailleurs, comment faites vous pour obtenir du thin provisionning ? Utilisez vous cette astuce :http://www.njcrawford.com/2010/01/21/growing-a-kvm-raw-hard-drive-image-file... ? J'ai rencontré des problèmes avec cette méthode en cas de sauvegarde avec compression puisqu'au moment de la décompression la copie prend la place prévue et non la place "thin provisionnée". Peut etre il y a t il des options de compression que j'ai raté. Le format qcow2 semble permettre ce genre de chose, mais est visiblement, d'après la documentation de KVM incompatible avec virtio, faisant perdre des performances.
Merci. Florian MAURY
Le Fri, Aug 06, 2010 at 02:28:45PM +0200, Florian MAURY [pub-frsag@x-cli.com] a écrit:
Bonjour, Simple question autour de la virtualisation avec KVM : comment partagez vous les disques entre plusieurs systèmes hôte, afin de pouvoir faire du live-migration ou du start on failure (équivalent Vmware HA) ? NFS ? DRBD ? ISCSI ? autre système de partage de fichier ?
Là où on a de la HA autour de KVM (et surtout Xen), c'est avec du DRBD. On orchestre le tout avec Ganeti : http://code.google.com/p/ganeti/
Le 06/08/10 14:28, Florian MAURY a écrit :
Bonjour, Simple question autour de la virtualisation avec KVM : comment partagez vous les disques entre plusieurs systèmes hôte, afin de pouvoir faire du live-migration ou du start on failure (équivalent Vmware HA) ?
OCFS2 sur SAN Tip top
Tu as oublié de préciser : fibré (dm multipath tout çà tout çà)
Mais c'était dans le cas d'images disques pour Xen
Je crois que ca ne peut pas s'appliquer a KVM, il lui faut impérativement du LVM si je dis pas de bétise ?
-- Fabien VANEENOO
Le 06/08/10 14:28, Florian MAURY a �crit :
Bonjour, Simple question autour de la virtualisation avec KVM : comment partagez vous les disques entre plusieurs syst�mes h�te, afin de pouvoir faire du live-migration ou du start on failure (�quivalent Vmware HA) ?
OCFS2 sur SAN Tip top
-- Charles-Christian Croix Karlesnine.com
Write it, cut it, paste it, save it, Load it, check it, quick, rewrite it _______________________________________________ FRsaG mailing list FRsaG@frsag.org http://www.frsag.org/mailman/listinfo/frsag
2010/8/6 Fabien VANEENOO frsag.mailing.list@kathryl.net:
Tu as oublié de préciser : fibré (dm multipath tout çà tout çà)
Mais c'était dans le cas d'images disques pour Xen
Je crois que ca ne peut pas s'appliquer a KVM, il lui faut impérativement du LVM si je dis pas de bétise ?
Merci pour vos avis. Continuez à envoyer vos retours d'exp (que ce message ne vous stoppe pas) puisque visiblement il n'y a pas de concensus établi.
Non, non, on peut utiliser aussi des fichiers.
Pour ce qui est du thin provisionning, je viens d'apprendre que l'astuce à base de dd, ca s'appelle des sparse files, et qu'il y a plein d'outils qui peuvent le prendre en charge, sous peine qu'on mette les bonnes options. Il me manquait la dénomination officielle pour trouver tout ce qu'il me fallait :) Donc problème résolu, c'est ce dont j'avais besoin !
J'en arrive donc à la question suivante, justement : dans la mesure où l'on peut faire du thin provisionning avec des fichiers mais pas avec LVM (qui alloue tout l'espace de volume d'un coup, même si on peut le grow après coup ; et que du coup on ne peut pas provisionner plus grand que la taille du/des disques physiques) il y a t il un intérêt quelconque à utiliser LVM ?
Florian MAURY
il y a t il un intérêt quelconque à utiliser LVM ?
Snapshot peut être ?
Il y a trop d'utilisation différente qui correspondent à des besoins différents pour sortir une utilisation type/standard/bateau :) (de mon point de vue)
F.
Bonjour,
je n'utilise pas (encore ?) KVM, mais uniquement Xen pour le moment. Néanmoins je suppose que les besoins sont similaires, donc je vais me permettre de répondre. ;)
Actuellement je gère donc ça via DRBD, directement sur l'host (le "Dom0 Xen"). Et j'en suis assez satisfait, mais ça fait longtemps que je n'ai pas fait de bench.
J'envisage de déporter ce boulot sur une paire de machines dédiées à cela, avec DRBD pour la redondance et iSCSI pour exporter vers les hosts Xen. Mais j'ai de gros doutes sur les performances, notamment en terme de latence (sur un VLAN Ethernet 10Gbps). Une solution - pour ce qui est des lectures en tous cas - serait d'utiliser des SSD en cache sur les hosts Xen (via dmcache par exemple). Mais je suis un peu frileux pour tester ça pour le moment.
Donc moi aussi je suis preneur de retours d'expériences sur ce genre de technos.
Bon week end ! Olivier B.
On 06/08/2010 14:28, Florian MAURY wrote:
Bonjour, Simple question autour de la virtualisation avec KVM : comment partagez vous les disques entre plusieurs systèmes hôte, afin de pouvoir faire du live-migration ou du start on failure (équivalent Vmware HA) ? NFS ? DRBD ? ISCSI ? autre système de partage de fichier ?
Si vous disposez d'un SAN, prenez vous le pari d'open-iscsi, ou montez vous un opensolaris à coté qui repartage après en NFS/whatever ? Je pose cette question saugrenue car il me semble avoir entendu dire que l'implémentation de iscsi sous solaris est plus stable (est ce vrai ?)
Par ailleurs, comment faites vous pour obtenir du thin provisionning ? Utilisez vous cette astuce :http://www.njcrawford.com/2010/01/21/growing-a-kvm-raw-hard-drive-image-file... ? J'ai rencontré des problèmes avec cette méthode en cas de sauvegarde avec compression puisqu'au moment de la décompression la copie prend la place prévue et non la place "thin provisionnée". Peut etre il y a t il des options de compression que j'ai raté. Le format qcow2 semble permettre ce genre de chose, mais est visiblement, d'après la documentation de KVM incompatible avec virtio, faisant perdre des performances.
Merci. Florian MAURY _______________________________________________ FRsaG mailing list FRsaG@frsag.org http://www.frsag.org/mailman/listinfo/frsag
Bonsoir,
On 06/08, Olivier Bonvalet wrote:
Actuellement je gère donc ça via DRBD, directement sur l'host (le "Dom0 Xen"). Et j'en suis assez satisfait, mais ça fait longtemps que je n'ai pas fait de bench.
Ici, nous avons tourné quelques temps sur une plate-forme similaire : 2 machines en DRBD master/master offrant en partage iscsi des volumes montés par des dom0 sur d'autres machines et faisant tourner les VMs en xen. Côté fonctionnel, il y avait ce qu'il nous fallait (redondance du stockage, bascule à chaud des VMs) à part l'évolutivité (perfs IOs de DRBD)
C'était clairement une étape de lancement avant d'avoir des SANs que nous utilisons désormais avec des grappes de machines qui montent les mêmes volumes partagés en iscsi. La gestion des volumes des VMs est faite via CLVMd (du LVM partagé par plusieurs serveurs), les VMs (en KVM) montent donc (en raw) des volumes au sein de ce LVM. Le SAN arrive à faire du thin provisionning malgré les volumes LVM affectés systématiquement.
Côté snapshot, c'est donc fait de manière globale sur le SAN. Le snapshot LVM étant beaucoup trop impactant sur les performances, nous ne l'implémentons pas pour chaque volume de VM. Nous regroupons donc les VMs par politique similaire.
Nous avons de la réplication asynchrone sur les SANs pour la sécurité des données mais nous testons actuellement la réplication synchrone en utilisant des volumes CLVM mirror répartis sur 2 SANs.
Dans ce que nous avons testé/utilisé et abandonné : - Les images de VMs au format qcow2 sur de l'OCFS2 partagé par les grappes de serveurs : trop instables, beaucoups de problèmes de corruption de donnée, probablement plus à cause d'OCFS2 (en tout cas de la version que l'on avait utilisée). Dommage c'était assez plaisant (pour le provisionning par exemple) d'autant que qcow2 permet du snapshot simple.
- heartbeat pour migrer/démarrer automatiquement les VMs. Finalement ça génère plus de soucis qu'autre chose. Nous n'avons que rarement besoin de bouger les VMs et le risque de corruption peut être trop important.
Ca reste une petite plate-forme de VMs même si apparemment le modèle semble satisfaisant pour évoluer.
Bonjour
Dans cet échange je ne vois que DRDB. Les solutions comme finefs, glusterfs, moosefs ne sont pas assez sérieuses/costaudes/pérennes/adaptées/... (cocher/ajouter les bonnes réponses) Est ce juste pour raisons historiques ou bien y a t il d'autres raisons plus pratique ?
Km
Le Sat, 7 Aug 2010 17:58:06 +0200, "cam.lafit@azerttyu.net" cam.lafit@azerttyu.net a écrit :
Bonjour
Dans cet échange je ne vois que DRDB.
DRDB travaille au niveau bloc. C'est un block device qu'on peut en plus partage entre des noeuds en actif/actif/actif, actif/passif/actif, etc.
On y met ce qu'on veut dessus. Il permet aussi lors des phases d'intégration d'avoir des contrôles d'intégrité à la volée (très pratique si on utilise des NICs qui font du TCP offload par exemple et qui le font mal). Le contrôle d'intégrité de la réplication est vraiment une fonctionnalité qu'y est loin d'être offerte en standard par d'autres système bcp plus cher. Il réplique à 98% de la vitesse du fil correctement tuné (la phase de tuning peut être un peu fastidieuse, il faut bien comprendre comment marche le système de drainage des caches divers fonctionnent et comment ils sont stacké).
Sur un DRBD correctement tuné, le bottleneck n'est ni les PPS de ton réseau, ni les MIPS de ton CPU, c'est la bande passante de tes disques et/ou de ton contrôleur.
C'est pas cher et çà fait autant si ne n'est plus que des alternatives bcp plus chère qui travaille au niveau bloc device.
a +.
Le Sat, Aug 14, 2010 at 12:03:19AM +0200, Jerome Benoit a écrit:
Sur un DRBD correctement tuné, le bottleneck n'est ni les PPS de ton réseau, ni les MIPS de ton CPU, c'est la bande passante de tes disques et/ou de ton contrôleur.
Si tu as une doc sur le tuning de drdb, de ses cache, ainsi que sur le tcpoffload, ça m'intéresserait beaucoup, et je pense ne pas être le seul ici...
Arnaud.
Le Sat, 14 Aug 2010 10:30:50 +0200, Arnaud Launay asl@launay.org a écrit :
Si tu as une doc sur le tuning de drdb, de ses cache, ainsi que sur le tcpoffload, ça m'intéresserait beaucoup, et je pense ne pas être le seul ici...
Tu as tjs la doc de linbit mais elle expose surtout les tunables importants, pas tellement quoi en faire (et quelques tests d'I/O pour générer une charge) :
http://www.drbd.org/users-guide-emb/p-performance.html
Il n'y pas de tuning qui ira pour tous types de hardware.
Les deux les plus importants pour le throughput sont :
unplug-watermark, extrêmement hardware spécifique. al-extents, extrêmement workload spécifique.
a +.
Le Sat, 14 Aug 2010 10:30:50 +0200, Arnaud Launay asl@launay.org a écrit :
ainsi que sur le tcpoffload, ça m'intéresserait beaucoup,
J'ai oublié çà ...
En fait il arrive que sur les NICs qui font du TCP offloading on ait soit des bugs (corruption des paquets TCP), soit des pbs de performances. Il est par conséquence primordial de pouvoir flasher leur firmware.
Pour les pbs de perfs, des outils comme uperf ou netperf permettent de rapidement les identifier : on fait des benchmarks avec et sans le TCP offloading, si sans çà marche plus vite, houston, on a un pb :p
Pour les corruption de paquets TCP, soit lors du benchmarking tu fais des captures de paquets et tu regardes les trames, soit tu prends un outil qui te permet de garantir l'intégrité des trames TCP par un autre moyen que le checksum standard de TCP. Dans le cadre d'une intégration de DRBD avec des NICs qui font du TCP offload, tu as cette possibilité en natif, tu l'actives sur DRBD le temps de la phase de test (parce que c'est pas fait pour être mis en prod, sauf si tu as plus besoin d'intégrité que de throughput) et çà te permet de vérifier que le TCP offloading n'est pas source de corruption.
a +.
Le Fri, 6 Aug 2010 19:47:49 +0200, Cyril Bellot cbellot@teaser.net a écrit :
Ici, nous avons tourné quelques temps sur une plate-forme similaire : 2 machines en DRBD master/master offrant en partage iscsi des volumes montés par des dom0 sur d'autres machines et faisant tourner les VMs en xen. Côté fonctionnel, il y avait ce qu'il nous fallait (redondance du stockage, bascule à chaud des VMs) à part l'évolutivité (perfs IOs de DRBD)
C'est cette partie de l'architecture que j'ai du mal à comprendre. Vous aviez un besoin spécifique d'offrir sur le réseau du stockage à d'autres machines, ces autres machines étant dédiés à la virtualisation ? (parce que en gros, vous avez flingué toutes les performances de DRBD en utilisant un serveur iSCSI par dessus ...)
- heartbeat pour migrer/démarrer automatiquement les VMs. Finalement
ça génère plus de soucis qu'autre chose. Nous n'avons que rarement besoin de bouger les VMs et le risque de corruption peut être trop important.
Pacemaker (la nouvelle mouture de heartbeat) gère très bien maintenant des migrations de VM. L'arbre de décision pour chaque type de pannes/pbs est la clé de la phase de conception dès qu'on fait de la HA.
a +.
On 14/08, Jerome Benoit wrote:
Le Fri, 6 Aug 2010 19:47:49 +0200, Cyril Bellot cbellot@teaser.net a écrit :
Ici, nous avons tourné quelques temps sur une plate-forme similaire : 2 machines en DRBD master/master offrant en partage iscsi des volumes montés par des dom0 sur d'autres machines et faisant tourner les VMs en xen. Côté fonctionnel, il y avait ce qu'il nous fallait (redondance du stockage, bascule à chaud des VMs) à part l'évolutivité (perfs IOs de DRBD)
C'est cette partie de l'architecture que j'ai du mal à comprendre. Vous aviez un besoin spécifique d'offrir sur le réseau du stockage à d'autres machines, ces autres machines étant dédiés à la virtualisation ? (parce que en gros, vous avez flingué toutes les performances de DRBD en utilisant un serveur iSCSI par dessus ...)
Le bottleneck restait DRBD (les IO disques en l'occurence) et pas l'iSCSI. On pouvait monter à pleine capacité réseau quand ça générait peu d'IOs (pour des opérations sur des gros blocs par exemple)
Le Sat, 14 Aug 2010 09:35:14 +0200, Cyril Bellot cbellot@teaser.net a écrit :
Le bottleneck restait DRBD (les IO disques en l'occurence) et pas l'iSCSI. On pouvait monter à pleine capacité réseau quand ça générait peu d'IOs (pour des opérations sur des gros blocs par exemple)
Les I/O disques sur DBRD ou les I/O sur les disques et le contrôleur "sous" DRDB ?
Parce que si c'est le premier cas, mon expérience avec DRDB me fait dire qu'il a été mal tuné :)
a +.
Le 06/08/2010 14:28, Florian MAURY a écrit :
Bonjour, Simple question autour de la virtualisation avec KVM : comment partagez vous les disques entre plusieurs systèmes hôte, afin de pouvoir faire du live-migration ou du start on failure (équivalent Vmware HA) ? NFS ? DRBD ? ISCSI ? autre système de partage de fichier ?
Ici je commence à jouer avec iSCSI sur IB (RDMA) avec multipath sur 2 réseaux (switchs) différents. Le choix de IB c'est simplement le prix, pour 3000 € j'ai eu 2 switchs 24p 8Gbps, 12 HBA et les câbles qui vont bien.
Le SAN est un Sun Storage cluster qui gère le thin provisioning, les snapshots et la déduplication.
On va faire tourner plusieurs centaine de K€ de CA par an sur le SAN donc une solution bricolée maison n'était pas envisageable. La seule autre solution qui me plaisait était de l'Equallogic en 10G mais à 60K€ la tête de 3 To utiles ce n'était pas possible.
Je vais déjà tester les perfs de KVM par rapport à Xen (PV) sur du matériel dernier cri (Xeon 5600) et ferai un retour sur la liste. J"ai aussi prévu de documenter la partie iSCSI sur IB avec le stockage Sun.
Fred.
Ici je commence à jouer avec iSCSI sur IB (RDMA) avec multipath sur 2 réseaux (switchs) différents. Le choix de IB c'est simplement le prix, pour 3000 € j'ai eu 2 switchs 24p 8Gbps, 12 HBA et les câbles qui vont bien.
Le SAN est un Sun Storage cluster qui gère le thin provisioning, les snapshots et la déduplication.
On va faire tourner plusieurs centaine de K€ de CA par an sur le SAN donc une solution bricolée maison n'était pas envisageable. La seule autre solution qui me plaisait était de l'Equallogic en 10G mais à 60K€ la tête de 3 To utiles ce n'était pas possible.
Je vais déjà tester les perfs de KVM par rapport à Xen (PV) sur du matériel dernier cri (Xeon 5600) et ferai un retour sur la liste. J"ai aussi prévu de documenter la partie iSCSI sur IB avec le stockage Sun.
Fred.
Je ne saurais que trop te conseiller de tester en fiber direct, parce que toutes mes expériences avec le iscsi se sont soldés par des échecs. Pas que cela ne marchait pas, mais c'était souvent lent, instable, surtout sur les clients, et au final source de trop d'emmerdements. Au prix actuel des cartes Fiber et d'un Fabric je me demande vraiment si cela vaut le coup de s'embêter avec iscsi. Sinon quitte à ne pas faire du bricoler maison, il peut être intéressant d'évaluer vmware. C'est peut être pas libre et payant, mais l'intégration est vraiment bonne, et les performances pas si en retrait par rapport à KVM ou Xen. Enfin cela dépend surtout de ce que l'on veut faire tourner comme guest. Pour du linux c'est sur que Xen ou KVM explose tout. (en PV).
Reste un conseil d'ordre général sur la virtualisation. La virtualisation c'est bien, mais pas pour tout, et il faut bien réfléchir a ce que l'on veut faire tourner dessus. (exemple débile : pas de bases de données :)
Le 9 août 2010 à 20:52, Raphael Mazelier a écrit :
Reste un conseil d'ordre général sur la virtualisation. La virtualisation c'est bien, mais pas pour tout, et il faut bien réfléchir a ce que l'on veut faire tourner dessus. (exemple débile : pas de bases de données :)
Je module un peu ta phrase, on ne virtualise pas de machine qui occupent 50% ou plus des ressources d'un serveur physique. Pour les base de données ca dépend encore de la charge, même avec de grosses bases si les ressources mem, io nécessaires sont faibles alors la virtualisation est possible et permet souvent de redonder l'ancien serveur physique qui était finalement un spof.
-- Pierre-Henry Muller
Le 14 août 2010 10:06, Pierre-Henry Muller wallace@morkitu.org a écrit :
Je module un peu ta phrase, on ne virtualise pas de machine qui occupent 50% ou plus des ressources d'un serveur physique. Pour les base de données ca dépend encore de la charge, même avec de grosses bases si les ressources mem, io nécessaires sont faibles alors la virtualisation est possible et permet souvent de redonder l'ancien serveur physique qui était finalement un spof. --
Bonjour Pierre Henri,
Je ne suis pas d'accord, les candidats idéaux à de la virtualisation sont les deux extrèmes (serveur qui ne fout rien, serveur qui travaille beaucoup) car, justement, les moyens des uns font les moyens des autres et, ainsi, tu peux mutualiser plus avant tes serveurs.
Dans ma vie pro, la grosse difficulté est de virtualiser des machines qui tournent "dans la moyenne", car on ne sait absolument pas en prédire l'évolution.
Après, c'est un sizing et des pools de ressources corrects qui permettront de faire en sorte que chacun ait ce dont il a besoin, pas plus ni moins.
Bon week end,
Olivier
Je ne suis pas d'accord, les candidats idéaux à de la virtualisation sont les deux extrèmes (serveur qui ne fout rien, serveur qui travaille beaucoup) car, justement, les moyens des uns font les moyens des autres et, ainsi, tu peux mutualiser plus avant tes serveurs.
Dans le second cas, la virtualisation n'est utile que pour gagner du temps, des sysadmins : on clic pour ajouter une ressource. Mais ça a un coût: il faut entre 30 et 50% de serveurs en plus que pour obtenir la même chose. Sinon Google, Facebook et Twitter ferait de la virtualisation (ils le font peut-être, mais pas pour l'architecture de prod).
Gain de temps, mais aussi "jouet" de sysadmins, ou encore pour combler un manque de compétence. Pour moi, la virtualisation ne doit pas servir dans le second cas décris par Pierre-Henry (scalability), mais pour des tas d'autres: - plateformes de test d'architecture - plateformes de test d'application multi environnements - environnement de builds - ...
Le 14 août 2010 à 10:39, Greg a écrit :
Je ne suis pas d'accord, les candidats idéaux à de la virtualisation sont les deux extrèmes (serveur qui ne fout rien, serveur qui travaille beaucoup) car, justement, les moyens des uns font les moyens des autres et, ainsi, tu peux mutualiser plus avant tes serveurs.
Dans le second cas, la virtualisation n'est utile que pour gagner du temps, des sysadmins : on clic pour ajouter une ressource. Mais ça a un coût: il faut entre 30 et 50% de serveurs en plus que pour obtenir la même chose. Sinon Google, Facebook et Twitter ferait de la virtualisation (ils le font peut-être, mais pas pour l'architecture de prod).
Gagner du temps sur le déploiement c'est un problème résolu par des solutions de provisionning (genre MDT pour Microsoft, Spacewalk pour Red Hat ou des solutions plus custom), pas spécifiquement par la virtualisation.
Le chiffre de 30 à 50% de machines en plus pour obtenir la même chose, je veux bien savoir d'où il sort. Surtout que depuis l'arrivée des processeurs avec VT-d et assimilé, l'overhead de la virtualisation est très réduite. Le dernier problème qu'on peut avoir c'est la contention sur les I/O. Du coup je pense que la virtualisation est intéressante quand on a des workloads faibles à mutualiser sur un seul serveur ou des workloads plus dimensionnées par le CPU que par les I/O.
Pour Google, Facebook ou Twitter, ça peut être simplement que la virtualisation n'est pas adaptée à leurs workloads et/ou ils ont commencé à construire leurs infra avant que la virtualisation ne soit suffisamment performante. Ils sont peut-être plus intéressés par des solutions de ce type : http://en.community.dell.com/dell-blogs/direct2dell/b/direct2dell/archive/20...
Et ils ont quand même la facilité de déploiement grâce à des solutions de provisionning maison. Mais les gros cloud providers eux sont basés sur de la virtualisation (de mémoire, AWS sur Xen, Rackspace sur VMWare, Azure sur Hyper-V...).
Je trouve que ta vision de la virtualisation est un peu dépassée.
-- Vincent Morel
Hello,
Le 14 août 2010 à 10:39, Greg a écrit :
Je ne suis pas d'accord, les candidats idéaux à de la virtualisation sont les deux extrèmes (serveur qui ne fout rien, serveur qui travaille beaucoup) car, justement, les moyens des uns font les moyens des autres et, ainsi, tu peux mutualiser plus avant tes serveurs.
Dans le second cas, la virtualisation n'est utile que pour gagner du temps, des sysadmins : on clic pour ajouter une ressource. Mais ça a un coût: il faut entre 30 et 50% de serveurs en plus que pour obtenir la même chose. Sinon Google, Facebook et Twitter ferait de la virtualisation (ils le font peut-être, mais pas pour l'architecture de prod).
Il y a virtualisation utile et celle qui est inutile.
L'utile c'est quand tu as 2 serveurs important et que tu peux pas te permettre de perdre ce serveur et avoir le temps de le remonter...
La virtualisation aide quand on fait bien les choses....
La version inutile c'est :
- les machins qui ont besoin de temps réel à la micro seconde voire nano seconde, exemple : trading boursier, récupération de data temps réel - les machins qui sont un cluster et qui peuvent se permettre de perdre une machine, exmple : google, cluster de calcul, ...
Dans ces deux cas, on peux pas ou ça sert a rien car coûte trop cher en perf...
Après il est sûr que la virtu ça coute de la perf, mais bon, quand on voit les CPU qui sortent... pourquoi s'en priver?
Si on trouve que le coût en CPU est trop élevé... bah des fois réapprendre aux développeurs a coder c'est aussi une bonne idée... comment faire ? baisser la prio de leur VM de dev a des valeurs basses.... histoire de leur faire comprendre qu'un code bien optimisé c'est de l'argent de gagné !
Xavier
Je tique un peu sur la possibilité de faire de la DB en virtualisé (quand je parle de DB c'est pas pour le Spip de mémé) vu les temps d'accès. La dernière fois qu'on en avait parlé, tu me disais que le temps d'accès n'était plus un problème grâce aux nouvelles technos de ouf, que les débits était incroyables, etc.
Je reste quand même plus rassuré pour un serveur bourré de ram et de sas, et assez confiant vu ce que promet la flash pour les années à venir. Me trompe-je ?
Benjamin
On Sat, 14 Aug 2010 18:26:01 +0200, Benjamin Billon bbillon-ml@splio.fr wrote:
Je tique un peu sur la possibilité de faire de la DB en virtualisé (quand je parle de DB c'est pas pour le Spip de mémé) vu les temps
d'accès.
La dernière fois qu'on en avait parlé, tu me disais que le temps d'accès n'était plus un problème grâce aux nouvelles technos de ouf, que les débits était incroyables, etc.
Bien sur, toute couche de virtualisation entraine des pertes.
Je reste quand même plus rassuré pour un serveur bourré de ram et de sas, et assez confiant vu ce que promet la flash pour les années à venir. Me trompe-je ?
Dans mon cas perso, j'ai concu une infra avec un ami, pour un projet, nous allons commencer par virtualiser les DB, pour des raisons de couts.
Qui peut faire une infra redondée, scalable et pas cher sans virtualisation?
Scalable dans le sens ou je vais avoir deux serveurs hôtes pour débuter. Quand les besoins s'en feront sentir, et/ou que les moyens seront là, nous allons migrer des VM sur d'autre serveurs .... voir une VM qui occupera un serveur physique directement (le passage d'un domU à un serveur physique n'est pas si complexe :] ).
La redondance n'est donc pas, dans ce cas assurée au niveau des serveurs hôtes, mais des serveurs invités. (exemple : une ndoe SQL sur l'hôte 1, une node SQL sur l'hôte 2).
Pour d'autres besoins, au boulot, la virtualisation est aussi de rigueur, mais pour d'autres raisons.
Il est préférable d'avoir 10 petites machines indépendantes qui font leur taff dans leur coin, qu'une grosse qui risque plus de planter. L'archi a donc été concue (par mon prédécésseur) dans ce sens là. Quelques paires de serveurs hôtes redondées, des serveurs virtuels par dessus.
Benjamin
Voila pour mes deux centimes :)
Il est préférable d'avoir 10 petites machines indépendantes qui font leur taff dans leur coin, qu'une grosse qui risque plus de planter. L'archi a donc été concue (par mon prédécésseur) dans ce sens là. Quelques paires de serveurs hôtes redondées, des serveurs virtuels par dessus.
Ca dépend vraiment de la finalité de la BDD et de la façon dont elle sera utilisée ; il n'y a de toutes façons pas de solution ultime, tout dépend des contraintes inhérentes à chaque projet. Dans des cas de plus en plus fréquents, le NoSQL devient une option réaliste et crédible. Et on rejoint les Twitter, Facebook et autres sites sans virtualisation.
Il est préférable d'avoir 10 petites machines indépendantes qui font leur taff dans leur coin, qu'une grosse qui risque plus de planter. L'archi a donc été concue (par mon prédécésseur) dans ce sens là. Quelques paires de serveurs hôtes redondées, des serveurs virtuels par dessus.
Ca dépend vraiment de la finalité de la BDD et de la façon dont elle sera utilisée ; il n'y a de toutes façons pas de solution ultime, tout dépend des contraintes inhérentes à chaque projet. Dans des cas de plus en plus fréquents, le NoSQL devient une option réaliste et crédible. Et on rejoint les Twitter, Facebook et autres sites sans virtualisation.
On Sat, 14 Aug 2010 12:49:01 +0200, eberkut eberkut@minithins.net wrote:
Pour Google, Facebook ou Twitter, ça peut être simplement que la virtualisation n'est pas adaptée à leurs workloads et/ou ils ont commencé à construire leurs infra avant que la virtualisation ne soit suffisamment performante.
Pas adaptée à leurs workloads, certainement. Par contre, Twitter refait son infra à neuf cet été et ne passe a priori pas à du virtualisé donc j'ai un doute sur la deuxième possibilité.
Et ils ont quand même la facilité de déploiement grâce à des solutions de provisionning maison. Mais les gros cloud providers eux sont basés sur de la virtualisation (de mémoire, AWS sur Xen, Rackspace sur VMWare, Azure sur Hyper-V...).
AWS sur Xen, d'accord pour EC2 et EMR, mais je ne suis pas certain que les services de stockage de données comme S3, SQS ou SimpleDB tournent en environnement virtualisé. Quelqu'un aurait plus d'infos là-dessus ?
On Sat, 14 Aug 2010 19:14:54 +0200, Benjamin Billon bbillon-ml@splio.fr wrote:
Dans des cas de plus en plus fréquents, le NoSQL devient une option réaliste et crédible. Et on rejoint les Twitter, Facebook et autres sites sans virtualisation.
Ça dépend de quelle virtualisation on parle. Pas mal de BDD NoSQL scalables sont en Java ou en Erlang et les deux langages tournent dans leur propre VM. Je considère déjà ça comme une forme réduite de virtualisation.
On Sat, 14 Aug 2010 17:16:23 +0200, Xavier Beaudouin kiwi@oav.net wrote:
Si on trouve que le coût en CPU est trop élevé... bah des fois réapprendre aux développeurs a coder c'est aussi une bonne idée... comment faire ? baisser la prio de leur VM de dev a des valeurs basses.... histoire de leur faire comprendre qu'un code bien optimisé c'est de l'argent de gagné !
Si ça leur fait prendre deux fois plus longtemps pour finir une application ou choisir la performance contre la fiabilité, pas certain que ça soit une bonne opération. Le CPU coûte souvent moins cher que le dev, et presque toujours moins que le downtime.
On n'a pas abordé la différence mais il y a virtualisation totale et virtualisation partielle.
Totale c'est un vmware ou un hvm sous xen, partielle c'est de la para virtualisation
Perso faire tourner du Debian sur du Debian en PV sous xen 4 ca fait perdre 3% de perfs en moyenne sur mes tests, autant dire que même sur une machine qui n'accueillerais qu'une seule vm car trop gournande, je ne me gênerais plus à installer une base xen pour pouvoir rapidement déplacer la machine en cas de soucis hardware.
Combien de fois pour des clients dont l'archi n'était pas redondé ou faussement redondé (serveurs dans un pool avec des verrus en spof genre des crons super importantes), on a du réinstaller le serveur de nuit un dimanche soir par ex puis y restaurer un backup?
En PV sur un san ou tout autre mécanisme type pouvant faire des snapshots genre lvm, il n'y a qu'à booter directement la vm sur une autres machines dans le cas d'un san ou restaurer la partition lvm d'un backup vers une autre machine xen. Bien plus rapide qu'une réinstall complète en croisant les doigts que la procédure soit à jour ... et le backup correctement fait...
Dans le cas des grosses infra Google, FB, Twitter ... clairement ils ont tous des outils internes de déploiement de masse. Pour parler de facebook, si ca n'a pas changé depuis 2 ans, ils étaient 3 admins sys pour gérer plusieurs milliers de serveurs. Une autre équipe était chargé de l'installation et alimentait la base infra en indiquant les nouvelles machines prêtes. Les admins n'avaient cas dire à quel usage la machine était destiné et l'installation, la prise en compte des datas et la mise en prod s'effectue toute seule. C'est à peu près le même principe chez Google avec en plus leur super file systeme, les autres je ne connais pas (pas eu d'infos d'un ancien salarié).
Pour ma part c'est donc oui à la paravirtualisation bien géré en production, la perte de perfs est négligeable et ca permet de sacrément réduire les couts. Pour la full virtualisation oui pour de la préprod, dev, test, tout ce que vous voulez mais pas de la prod.
Après j'ai aussi vu de très grosses boites qui mettent des fermes de vmware avec des san dans tous les sens pour la redondance et qui migrent tous leurs anciens serveurs dessus. Oui là il y a une économie d'infra (passer de 25 baies à 8), ca assure la redondance à chaud de machines qui ne l'étaient pas ou qui ne pouvaient l'être (progiciel, logiciel imposé par un client, ...). Mais clairement c'est client ne sont pas des archis web, mais des archis informatiques au service de la production de l'entreprise (grande distribution, transport de fret, constructeur auto, ...). Ils ont les moyens de faire correctement du full virtualisé et en plus ils sont quand même gagnant et peuvent même garder les vieux serveurs NT qu'ils n'osent pas migrer et qu'ils ne savaient de toute façon pas réinstaller.
A voir donc les usages tout n'est pas bon en virtualisation mais dans certains cas ca aide vraiment. -- Pierre-Henry Muller
Bonjour,
Nous avons besoin de faire un pont sans fils entre deux bâtiment, nous avons 25m entre les deux emplacement sur la même façade d'immeuble en plein Paris donc avec énormément de Wifi dans les air. Nous allons faire passer dedans tout le réseau informatique, essentiellement domaine, exchange et partage de fichier (office basic)
Nous pouvons mettre des antennes sur la façade.
Nous avons penser à utiliser du 802.11a pour une question de perturbation des ondes. http://www.acksys.fr/fr/produits/wlg_Ethernet_air_pack.htm C'est très cher et seulement en 54 Mbps (j'imagine que nous aurons à peine 20 Mbps).
Le n c'est forcément beaucoup moins cher mais je ne trouve pas de matériel professionnel et c'est impensable d'avoir une liaison instable...
Est-ce que vous avez des infos à me donner? Des conseils?
Merci Charles
Le 24/08/2010 13:47, Charles a écrit :
Bonjour,
Nous avons besoin de faire un pont sans fils entre deux bâtiment, nous avons 25m entre les deux emplacement sur la même façade d'immeuble en plein Paris donc avec énormément de Wifi dans les air. Nous allons faire passer dedans tout le réseau informatique, essentiellement domaine, exchange et partage de fichier (office basic)
Bonjour,
j'imagine que vous ne pouvez pas tirer de fibre entre les 2 batiments ?
On voudrai bien, mais ca semble impossible entre les syndics, les copros, les concierges etc... On installe dans une semaine.
Charles
-----Message d'origine----- De : frsag-bounces@frsag.org [mailto:frsag-bounces@frsag.org] De la part de Greg Envoyé : mardi 24 août 2010 13:55 À : frsag@frsag.org Objet : Re: [FRsaG] Pont réseau sans fils 802.11a ? n? laser ?
Le 24/08/2010 13:47, Charles a écrit :
Bonjour,
Nous avons besoin de faire un pont sans fils entre deux bâtiment, nous
avons
25m entre les deux emplacement sur la même façade d'immeuble en plein
Paris
donc avec énormément de Wifi dans les air. Nous allons faire passer dedans tout le réseau informatique,
essentiellement
domaine, exchange et partage de fichier (office basic)
Bonjour,
j'imagine que vous ne pouvez pas tirer de fibre entre les 2 batiments ?
Le 24/08/2010 14:18, Charles a écrit :
On voudrai bien, mais ca semble impossible entre les syndics, les copros, les concierges etc... On installe dans une semaine.
Le syndic ne voulait pas qu'on passe par le toit ou le couloir, par contre il n'y avait pas de problème pour passer par les gaines électriques qui descendent verticalement au sous-sol. Après pour relier les 2 batiments il y a encore d'autres freins, mais ça doit forcément se faire.
Bonjour, Tu peux toujours regarder du côté des produits Terescope. Vu la distance ça risque d'être un peu surdimensionné, mais j'ai en tête un modèleTS4000/FET/F . Il y a des modèles "moins" performant qui devraient te convenir....
Paul Soave.
-----Message d'origine----- De : frsag-bounces@frsag.org [mailto:frsag-bounces@frsag.org] De la part de Charles Envoyé : mardi 24 août 2010 13:47 À : 'French SysAdmin Group' Objet : [FRsaG] Pont réseau sans fils 802.11a ? n? laser ?
Bonjour,
Nous avons besoin de faire un pont sans fils entre deux bâtiment, nous avons 25m entre les deux emplacement sur la même façade d'immeuble en plein Paris donc avec énormément de Wifi dans les air. Nous allons faire passer dedans tout le réseau informatique, essentiellement domaine, exchange et partage de fichier (office basic)
Nous pouvons mettre des antennes sur la façade.
Nous avons penser à utiliser du 802.11a pour une question de perturbation des ondes. http://www.acksys.fr/fr/produits/wlg_Ethernet_air_pack.htm C'est très cher et seulement en 54 Mbps (j'imagine que nous aurons à peine 20 Mbps).
Le n c'est forcément beaucoup moins cher mais je ne trouve pas de matériel professionnel et c'est impensable d'avoir une liaison instable...
Est-ce que vous avez des infos à me donner? Des conseils?
Merci Charles
_______________________________________________ FRsaG mailing list FRsaG@frsag.org http://www.frsag.org/mailman/listinfo/frsag
Merci pour vos réponses, plusieurs personne mon parlé des systèmes Laser mais clairement c'est disproportionner niveau tarifs, nous aimerions un solution à 1000-1500 € on est sur de la TPE et sur le site distant nous n'aurons que 3 utilisateurs.
Charles
-----Message d'origine----- De : frsag-bounces@frsag.org [mailto:frsag-bounces@frsag.org] De la part de Comint PSE Envoyé : mardi 24 août 2010 14:30 À : 'French SysAdmin Group' Objet : Re: [FRsaG] Pont réseau sans fils 802.11a ? n? laser ?
Bonjour, Tu peux toujours regarder du côté des produits Terescope. Vu la distance ça risque d'être un peu surdimensionné, mais j'ai en tête un modèleTS4000/FET/F . Il y a des modèles "moins" performant qui devraient te convenir....
Paul Soave.
-----Message d'origine----- De : frsag-bounces@frsag.org [mailto:frsag-bounces@frsag.org] De la part de Charles Envoyé : mardi 24 août 2010 13:47 À : 'French SysAdmin Group' Objet : [FRsaG] Pont réseau sans fils 802.11a ? n? laser ?
Bonjour,
Nous avons besoin de faire un pont sans fils entre deux bâtiment, nous avons 25m entre les deux emplacement sur la même façade d'immeuble en plein Paris donc avec énormément de Wifi dans les air. Nous allons faire passer dedans tout le réseau informatique, essentiellement domaine, exchange et partage de fichier (office basic)
Nous pouvons mettre des antennes sur la façade.
Nous avons penser à utiliser du 802.11a pour une question de perturbation des ondes. http://www.acksys.fr/fr/produits/wlg_Ethernet_air_pack.htm C'est très cher et seulement en 54 Mbps (j'imagine que nous aurons à peine 20 Mbps).
Le n c'est forcément beaucoup moins cher mais je ne trouve pas de matériel professionnel et c'est impensable d'avoir une liaison instable...
Est-ce que vous avez des infos à me donner? Des conseils?
Merci Charles
_______________________________________________ FRsaG mailing list FRsaG@frsag.org http://www.frsag.org/mailman/listinfo/frsag
_______________________________________________ FRsaG mailing list FRsaG@frsag.org http://www.frsag.org/mailman/listinfo/frsag
Est-ce qu'une box de chaque côté et un VPN ne suffirait pas pour cet usage ? En plein Paris il y a du débit, surtout si vous êtes couverts en FTTH...
Regarde les solutions AirMax de Ubiquiti, ils proposent jusqu'à 150Mbits à plusieurs dizaines de kilomètres. http://www.ubnt.com/powerbridgem . Je n'ai personnellement pas eu d'expérience avec mais j'ai quelques connaissances qui ont des liens très stables grâce à ce matériel.
http://www.ubnt.com/powerbridgemSinon le laser j'ai entendu dire que c'était vraiment très très bof niveau débits et résistance aux intempéries.
http://www.ubnt.com/powerbridgemTito
2010/8/24 Charles cognacboy@worldonline.fr
Merci pour vos réponses, plusieurs personne mon parlé des systèmes Laser mais clairement c'est disproportionner niveau tarifs, nous aimerions un solution à 1000-1500 € on est sur de la TPE et sur le site distant nous n'aurons que 3 utilisateurs.
Charles
-----Message d'origine----- De : frsag-bounces@frsag.org [mailto:frsag-bounces@frsag.org] De la part de Comint PSE Envoyé : mardi 24 août 2010 14:30 À : 'French SysAdmin Group' Objet : Re: [FRsaG] Pont réseau sans fils 802.11a ? n? laser ?
Bonjour, Tu peux toujours regarder du côté des produits Terescope. Vu la distance ça risque d'être un peu surdimensionné, mais j'ai en tête un modèleTS4000/FET/F . Il y a des modèles "moins" performant qui devraient te convenir....
Paul Soave.
-----Message d'origine----- De : frsag-bounces@frsag.org [mailto:frsag-bounces@frsag.org] De la part de Charles Envoyé : mardi 24 août 2010 13:47 À : 'French SysAdmin Group' Objet : [FRsaG] Pont réseau sans fils 802.11a ? n? laser ?
Bonjour,
Nous avons besoin de faire un pont sans fils entre deux bâtiment, nous avons 25m entre les deux emplacement sur la même façade d'immeuble en plein Paris donc avec énormément de Wifi dans les air. Nous allons faire passer dedans tout le réseau informatique, essentiellement domaine, exchange et partage de fichier (office basic)
Nous pouvons mettre des antennes sur la façade.
Nous avons penser à utiliser du 802.11a pour une question de perturbation des ondes. http://www.acksys.fr/fr/produits/wlg_Ethernet_air_pack.htm C'est très cher et seulement en 54 Mbps (j'imagine que nous aurons à peine 20 Mbps).
Le n c'est forcément beaucoup moins cher mais je ne trouve pas de matériel professionnel et c'est impensable d'avoir une liaison instable...
Est-ce que vous avez des infos à me donner? Des conseils?
Merci Charles
FRsaG mailing list FRsaG@frsag.org http://www.frsag.org/mailman/listinfo/frsag
FRsaG mailing list FRsaG@frsag.org http://www.frsag.org/mailman/listinfo/frsag
FRsaG mailing list FRsaG@frsag.org http://www.frsag.org/mailman/listinfo/frsag
On Tue, 24 Aug 2010 21:21:34 +0200, "Christophe De Wolf" tito@webtito.be said:
Sinon le laser j'ai entendu dire que c'était vraiment très très bof niveau débits et résistance aux intempéries.
Habituellement, les equipements laser font du 1Gbps full-duplex. Cote intemperies, j'ai pu comprendre que ca a beaucoup evolue. Par contre, ca reste du laser avec tout ce que ca implique, notamment la precision a centimetre pres et ses inconvenients.... Et le prix est non-negligeable (min 3000 EUR la paire selon mes informations).
Le 24/08/2010 21:37, Radu-Adrian Feurdean a écrit :
On Tue, 24 Aug 2010 21:21:34 +0200, "Christophe De Wolf" tito@webtito.be said:
Sinon le laser j'ai entendu dire que c'était vraiment très très bof niveau débits et résistance aux intempéries.
Habituellement, les equipements laser font du 1Gbps full-duplex. Cote intemperies, j'ai pu comprendre que ca a beaucoup evolue. Par contre, ca reste du laser avec tout ce que ca implique, notamment la precision a centimetre pres et ses inconvenients.... Et le prix est non-negligeable (min 3000 EUR la paire selon mes informations).
Je prend ce sujet en cours, mais j'ai vu "technologie laser".
J'ai vécu cette solution en prod, résultats : - Ne fonctionne pas les jours de brume - Fonctionne mal les jours de pluie - Ne fonctionne pas quand un pigeon est devant - Ne fonctionne pas quand une araignée est sur le capteur - .. j'en passe :)
La solution, pour nous, a été de poser une fibre qui traverse la route...
Le 25/08/10, frsag@webmail.frfrsag@webmail.fr a écrit :
Je prend ce sujet en cours, mais j'ai vu "technologie laser".
J'ai vécu cette solution en prod, résultats :
- Ne fonctionne pas les jours de brume
- Fonctionne mal les jours de pluie
- Ne fonctionne pas quand un pigeon est devant
- Ne fonctionne pas quand une araignée est sur le capteur
- .. j'en passe :)
C'est de la fibre sans fibre, en somme?
Le 25/08/2010 10:08, Rémi Bouhl a écrit :
Le 25/08/10, frsag@webmail.frfrsag@webmail.fr a écrit :
Je prend ce sujet en cours, mais j'ai vu "technologie laser".
J'ai vécu cette solution en prod, résultats :
- Ne fonctionne pas les jours de brume
- Fonctionne mal les jours de pluie
- Ne fonctionne pas quand un pigeon est devant
- Ne fonctionne pas quand une araignée est sur le capteur
- .. j'en passe :)
C'est de la fibre sans fibre, en somme?
On peut dépeindre ça comme ça, oui...
Maintenant je ne me souviens plus le nom du matériel ni comment c'était branché derrière. ... Les machins qui me donnent des ulcères, je les supprime de ma mémoire.
Je viens de commander un pont avec deux Ubiquiti AirMax NanoStation M5 franchement ca a l'air très bien c'est fait pour fonctionner à 1km et j'ai 25m a tout casser, donc j'espère avoir pas loin de 50 Mbps pour 300e tt compris avec les socles câbles étanches etc...
Je vous dis comment ca marche la semaine prochaine.
Merci à tous.
-----Message d'origine----- De : frsag-bounces@frsag.org [mailto:frsag-bounces@frsag.org] De la part de frsag@webmail.fr Envoyé : mercredi 25 août 2010 19:56 À : French SysAdmin Group Objet : Re: [FRsAG] [FRsaG] Pont réseau sans fils 802.11a ? n? laser ?
Le 25/08/2010 10:08, Rémi Bouhl a écrit :
Le 25/08/10, frsag@webmail.frfrsag@webmail.fr a écrit :
Je prend ce sujet en cours, mais j'ai vu "technologie laser".
J'ai vécu cette solution en prod, résultats :
- Ne fonctionne pas les jours de brume
- Fonctionne mal les jours de pluie
- Ne fonctionne pas quand un pigeon est devant
- Ne fonctionne pas quand une araignée est sur le capteur
- .. j'en passe :)
C'est de la fibre sans fibre, en somme?
On peut dépeindre ça comme ça, oui...
Maintenant je ne me souviens plus le nom du matériel ni comment c'était branché derrière. ... Les machins qui me donnent des ulcères, je les supprime de ma mémoire.
_______________________________________________ FRsAG mailing list FRsAG@frsag.org http://www.frsag.org/mailman/listinfo/frsag
Même avis,
J'ai eu le même cas de figure, et j'ai opté pour du matériel alvarion en hiperlan2 (concurrent du 802.11a)... Perso le laser comme le dit Rémi, trop de facteurs peuvent dégrader son signal, donc bon! La fibre elle peut couter très cher, même si de la fibre aérienne coute environ 50% moins chère.
Mervyn
Le 25/08/2010 20:32, Charles a écrit :
Je viens de commander un pont avec deux Ubiquiti AirMax NanoStation M5 franchement ca a l'air très bien c'est fait pour fonctionner à 1km et j'ai 25m a tout casser, donc j'espère avoir pas loin de 50 Mbps pour 300e tt compris avec les socles câbles étanches etc...
Je vous dis comment ca marche la semaine prochaine.
Merci à tous.
-----Message d'origine----- De : frsag-bounces@frsag.org [mailto:frsag-bounces@frsag.org] De la part de frsag@webmail.fr Envoyé : mercredi 25 août 2010 19:56 À : French SysAdmin Group Objet : Re: [FRsAG] [FRsaG] Pont réseau sans fils 802.11a ? n? laser ?
Le 25/08/2010 10:08, Rémi Bouhl a écrit :
Le 25/08/10, frsag@webmail.frfrsag@webmail.fr a écrit :
Je prend ce sujet en cours, mais j'ai vu "technologie laser".
J'ai vécu cette solution en prod, résultats :
- Ne fonctionne pas les jours de brume
- Fonctionne mal les jours de pluie
- Ne fonctionne pas quand un pigeon est devant
- Ne fonctionne pas quand une araignée est sur le capteur
- .. j'en passe :)
C'est de la fibre sans fibre, en somme?
On peut dépeindre ça comme ça, oui...
Maintenant je ne me souviens plus le nom du matériel ni comment c'était branché derrière. ... Les machins qui me donnent des ulcères, je les supprime de ma mémoire.
FRsAG mailing list FRsAG@frsag.org http://www.frsag.org/mailman/listinfo/frsag
FRsAG mailing list FRsAG@frsag.org http://www.frsag.org/mailman/listinfo/frsag
N'hésite pas à nous faire aussi un retour dans un peu plus longtemps (1 mois et 3 mois, avec le début de l'hiver), pour voir si ça tiens la route avec les intempéries !
Je te souhaite bonne chance avec cette marque et ton infra. J'espère que tu t'en sortira mieux que moi, qui a surtout eu un gros mauvais souvenir ...
Le 25/08/2010 20:32, Charles a écrit :
Je viens de commander un pont avec deux Ubiquiti AirMax NanoStation M5 franchement ca a l'air très bien c'est fait pour fonctionner à 1km et j'ai 25m a tout casser, donc j'espère avoir pas loin de 50 Mbps pour 300e tt compris avec les socles câbles étanches etc...
Je vous dis comment ca marche la semaine prochaine.
Merci à tous.
-----Message d'origine----- De : frsag-bounces@frsag.org [mailto:frsag-bounces@frsag.org] De la part de frsag@webmail.fr Envoyé : mercredi 25 août 2010 19:56 À : French SysAdmin Group Objet : Re: [FRsAG] [FRsaG] Pont réseau sans fils 802.11a ? n? laser ?
Le 25/08/2010 10:08, Rémi Bouhl a écrit :
Le 25/08/10, frsag@webmail.frfrsag@webmail.fr a écrit :
Je prend ce sujet en cours, mais j'ai vu "technologie laser".
J'ai vécu cette solution en prod, résultats :
- Ne fonctionne pas les jours de brume
- Fonctionne mal les jours de pluie
- Ne fonctionne pas quand un pigeon est devant
- Ne fonctionne pas quand une araignée est sur le capteur
- .. j'en passe :)
C'est de la fibre sans fibre, en somme?
On peut dépeindre ça comme ça, oui...
Maintenant je ne me souviens plus le nom du matériel ni comment c'était branché derrière. ... Les machins qui me donnent des ulcères, je les supprime de ma mémoire.
FRsAG mailing list FRsAG@frsag.org http://www.frsag.org/mailman/listinfo/frsag
FRsAG mailing list FRsAG@frsag.org http://www.frsag.org/mailman/listinfo/frsag
On Wed, 2010-08-25 at 20:32 +0200, Charles wrote:
Je viens de commander un pont avec deux Ubiquiti AirMax NanoStation M5 franchement ca a l'air très bien c'est fait pour fonctionner à 1km et j'ai 25m a tout casser, donc j'espère avoir pas loin de 50 Mbps pour 300e tt compris avec les socles câbles étanches etc...
Je vous dis comment ca marche la semaine prochaine.
Des nouvelles quelques mois après ? :)
Laurent
Bonjour,
J'allais faire la même suggestion. La marque Ubiquiti propose toute une gamme d'AP, de la borne 802.11b standard à l'équipement longue distance (avec des antennes paraboliques, etc.).
J'utilise des Picostation (simples points d'accès) qui sont déjà très puissants, très fiables et bon marché.
De mémoire, les Nanostation font du 802.11a et sont typiquement adaptées à ce genre de situation.
De plus, si c'est pour relier 3 utilisateurs, inutile d'y mettre des milliers d'€. (àmha). -- Jonathan AMIEZ
Le mardi 24 août 2010 19:21:34, Christophe De Wolf a écrit :
Regarde les solutions AirMax de Ubiquiti, ils proposent jusqu'à 150Mbits à plusieurs dizaines de kilomètres. http://www.ubnt.com/powerbridgem . Je n'ai personnellement pas eu d'expérience avec mais j'ai quelques connaissances qui ont des liens très stables grâce à ce matériel.
http://www.ubnt.com/powerbridgemSinon le laser j'ai entendu dire que c'était vraiment très très bof niveau débits et résistance aux intempéries.
http://www.ubnt.com/powerbridgemTito
2010/8/24 Charles cognacboy@worldonline.fr
Merci pour vos réponses, plusieurs personne mon parlé des systèmes Laser mais clairement c'est disproportionner niveau tarifs, nous aimerions un solution à 1000-1500 € on est sur de la TPE et sur le site distant nous n'aurons que 3 utilisateurs.
Charles
-----Message d'origine----- De : frsag-bounces@frsag.org [mailto:frsag-bounces@frsag.org] De la part de Comint PSE Envoyé : mardi 24 août 2010 14:30 À : 'French SysAdmin Group' Objet : Re: [FRsaG] Pont réseau sans fils 802.11a ? n? laser ?
Bonjour, Tu peux toujours regarder du côté des produits Terescope. Vu la distance ça risque d'être un peu surdimensionné, mais j'ai en tête un modèleTS4000/FET/F . Il y a des modèles "moins" performant qui devraient te convenir....
Paul Soave.
-----Message d'origine----- De : frsag-bounces@frsag.org [mailto:frsag-bounces@frsag.org] De la part de Charles Envoyé : mardi 24 août 2010 13:47 À : 'French SysAdmin Group' Objet : [FRsaG] Pont réseau sans fils 802.11a ? n? laser ?
Bonjour,
Nous avons besoin de faire un pont sans fils entre deux bâtiment, nous avons 25m entre les deux emplacement sur la même façade d'immeuble en plein Paris donc avec énormément de Wifi dans les air. Nous allons faire passer dedans tout le réseau informatique, essentiellement domaine, exchange et partage de fichier (office basic)
Nous pouvons mettre des antennes sur la façade.
Nous avons penser à utiliser du 802.11a pour une question de perturbation des ondes. http://www.acksys.fr/fr/produits/wlg_Ethernet_air_pack.htm C'est très cher et seulement en 54 Mbps (j'imagine que nous aurons à peine 20 Mbps).
Le n c'est forcément beaucoup moins cher mais je ne trouve pas de matériel professionnel et c'est impensable d'avoir une liaison instable...
Est-ce que vous avez des infos à me donner? Des conseils?
Merci Charles
FRsaG mailing list FRsaG@frsag.org http://www.frsag.org/mailman/listinfo/frsag
FRsaG mailing list FRsaG@frsag.org http://www.frsag.org/mailman/listinfo/frsag
FRsaG mailing list FRsaG@frsag.org http://www.frsag.org/mailman/listinfo/frsag
En effet on m'a parlé de cette marque cet aprem mais je n'ai rien trouvé, portant nous avions sélectionner un de leur produit sur le site de mhz... mais comme nous ne connaissions pas la marque. Je vais approfondir mes recherches sur leurs produits demain mais ca semble difficile de faire mieux. En plus vu le prix et la dispo en France comme je dois installer dans une semaine.
On fera un backup vpn mais ca me semble déjà pas mal.
Merci de votre aide.
-----Message d'origine----- De : frsag-bounces@frsag.org [mailto:frsag-bounces@frsag.org] De la part de Jonathan Amiez Envoyé : mardi 24 août 2010 23:38 À : French SysAdmin Group Objet : Re: [FRsaG] Pont réseau sans fils 802.11a ? n? laser ?
Bonjour,
J'allais faire la même suggestion. La marque Ubiquiti propose toute une gamme d'AP, de la borne 802.11b standard à l'équipement longue distance (avec des antennes paraboliques, etc.).
J'utilise des Picostation (simples points d'accès) qui sont déjà très puissants, très fiables et bon marché.
De mémoire, les Nanostation font du 802.11a et sont typiquement adaptées à ce genre de situation.
De plus, si c'est pour relier 3 utilisateurs, inutile d'y mettre des milliers d'€. (àmha). -- Jonathan AMIEZ
Le mardi 24 août 2010 19:21:34, Christophe De Wolf a écrit :
Regarde les solutions AirMax de Ubiquiti, ils proposent jusqu'à 150Mbits à plusieurs dizaines de kilomètres. http://www.ubnt.com/powerbridgem . Je n'ai personnellement pas eu d'expérience avec mais j'ai quelques connaissances qui ont des liens très stables grâce à ce matériel.
http://www.ubnt.com/powerbridgemSinon le laser j'ai entendu dire que c'était vraiment très très bof niveau débits et résistance aux intempéries.
http://www.ubnt.com/powerbridgemTito
2010/8/24 Charles cognacboy@worldonline.fr
Merci pour vos réponses, plusieurs personne mon parlé des systèmes Laser mais clairement c'est disproportionner niveau tarifs, nous aimerions un solution à 1000-1500 € on est sur de la TPE et sur le site distant nous n'aurons que 3 utilisateurs.
Charles
-----Message d'origine----- De : frsag-bounces@frsag.org [mailto:frsag-bounces@frsag.org] De la part de Comint PSE Envoyé : mardi 24 août 2010 14:30 À : 'French SysAdmin Group' Objet : Re: [FRsaG] Pont réseau sans fils 802.11a ? n? laser ?
Bonjour, Tu peux toujours regarder du côté des produits Terescope. Vu la distance ça risque d'être un peu surdimensionné, mais j'ai en tête un modèleTS4000/FET/F . Il y a des modèles "moins" performant qui devraient te convenir....
Paul Soave.
-----Message d'origine----- De : frsag-bounces@frsag.org [mailto:frsag-bounces@frsag.org] De la part de Charles Envoyé : mardi 24 août 2010 13:47 À : 'French SysAdmin Group' Objet : [FRsaG] Pont réseau sans fils 802.11a ? n? laser ?
Bonjour,
Nous avons besoin de faire un pont sans fils entre deux bâtiment, nous avons 25m entre les deux emplacement sur la même façade d'immeuble en plein Paris donc avec énormément de Wifi dans les air. Nous allons faire passer dedans tout le réseau informatique, essentiellement domaine, exchange et partage de fichier (office basic)
Nous pouvons mettre des antennes sur la façade.
Nous avons penser à utiliser du 802.11a pour une question de perturbation des ondes. http://www.acksys.fr/fr/produits/wlg_Ethernet_air_pack.htm C'est très cher et seulement en 54 Mbps (j'imagine que nous aurons à peine 20 Mbps).
Le n c'est forcément beaucoup moins cher mais je ne trouve pas de matériel professionnel et c'est impensable d'avoir une liaison instable...
Est-ce que vous avez des infos à me donner? Des conseils?
Merci Charles
FRsaG mailing list FRsaG@frsag.org http://www.frsag.org/mailman/listinfo/frsag
FRsaG mailing list FRsaG@frsag.org http://www.frsag.org/mailman/listinfo/frsag
FRsaG mailing list FRsaG@frsag.org http://www.frsag.org/mailman/listinfo/frsag
_______________________________________________ FRsaG mailing list FRsaG@frsag.org http://www.frsag.org/mailman/listinfo/frsag
Des pack sympa :
http://www.fwt.fr/index1.php?WebClasse=Kit%20Complet%20Ponts/Liaisons%20Poin... http://www.fwt.fr/index1.php?WebClasse=Kit%20Complet%20Ponts/Liaisons%20Poin...
Le 24 août 2010 22:15, Charles cognacboy@worldonline.fr a écrit :
En effet on m'a parlé de cette marque cet aprem mais je n'ai rien trouvé, portant nous avions sélectionner un de leur produit sur le site de mhz... mais comme nous ne connaissions pas la marque. Je vais approfondir mes recherches sur leurs produits demain mais ca semble difficile de faire mieux. En plus vu le prix et la dispo en France comme je dois installer dans une semaine.
On fera un backup vpn mais ca me semble déjà pas mal.
Merci de votre aide.
Deux Wrt avec antenne directionnelle en pont(en wds ou mieux en routé) cela devrait assurer un débit largement suffisant pour 3 personnes (aka10M symétrique) et pour la stabilité tu peux backuper le tout avec liaison [A|S]dsl et petit openvpn par dessus.
On avait ca dans une entreprise précédente entre le siège et le datacenter (cbv) à plus de 100m. Cela marchait pas mal, sauf en cas d'orage ou d'oiseaux :)
Le 24/08/2010 20:01, Charles a écrit :
Merci pour vos réponses, plusieurs personne mon parlé des systèmes Laser mais clairement c'est disproportionner niveau tarifs, nous aimerions un solution à 1000-1500 € on est sur de la TPE et sur le site distant nous n'aurons que 3 utilisateurs.
Charles
Bonjour,
Je vous conseille de vous rapprocher de la Federation France Wireless - http://www.wireless-fr.org/ - pour leur expertise sur le sujet :)
Les technologies HyperLan ou dérivées (en fonction du budget) sont toutes indiquées pour ce genre de projet PtP.
Denis
Le 24/08/2010 13:47, Charles a écrit :
Bonjour,
Nous avons besoin de faire un pont sans fils entre deux bâtiment, nous avons 25m entre les deux emplacement sur la même façade d'immeuble en plein Paris donc avec énormément de Wifi dans les air. Nous allons faire passer dedans tout le réseau informatique, essentiellement domaine, exchange et partage de fichier (office basic)
Nous pouvons mettre des antennes sur la façade.
Nous avons penser à utiliser du 802.11a pour une question de perturbation des ondes. http://www.acksys.fr/fr/produits/wlg_Ethernet_air_pack.htm C'est très cher et seulement en 54 Mbps (j'imagine que nous aurons à peine 20 Mbps).
Le n c'est forcément beaucoup moins cher mais je ne trouve pas de matériel professionnel et c'est impensable d'avoir une liaison instable...
Est-ce que vous avez des infos à me donner? Des conseils?
Merci Charles
FRsaG mailing list FRsaG@frsag.org http://www.frsag.org/mailman/listinfo/frsag
-
Arnaud Launay -
Benjamin Billon -
Benjamin Billon -
cam.lafit＠azerttyu.net -
Charles -
Charles-Christian Croix -
Christophe De Wolf -
Comint PSE -
Cyril Bellot -
Denis Fondras -
Dominique Rousseau -
eberkut -
Fabien VANEENOO -
Fabien VANEENOO -
Florian MAURY -
frsag＠webmail.fr -
Frédéric VANNIÈRE -
Greg -
Jerome Benoit -
Jonathan Amiez -
Julien Richer -
Laurent GUERBY -
Marichy mervyn -
Olivier Bonvalet -
Olivier tourchon -
Pierre Chapuis -
Pierre Chapuis -
Pierre-Henry Muller -
Radu-Adrian Feurdean -
Raphael Mazelier -
Richard DEMONGEOT -
Rémi Bouhl -
Xavier Beaudouin