Un peu de nouveau !!

Posted on by
Reply

J’ai parlé dans le courant de l’année du D525 qui est un dual core 4 thread. Depuis, j’ai changé ma plateforme silencieuse pour ce type de composant. Je n’ai pas encore bien eu le temps de réaliser toute la batterie de test (déménagement oblige), mais promis, ça va arriver…

Je peux déjà vous dire que ça tourne plutôt pas mal, en tout cas mieux que ma plateforme NVidia ION précédente pour une utilisation bureautique, sufr & co. je regrette seulement que la machine Zotak que j’ai commandé cette fois-ci ait en son sein un ventilateur, ce qui, pour une solution Zero dB, est très regrettable. Mais la documentation sur le site indiquait silencieuse… J’en profite donc pour un petit coup de gueule sur la notion de silence … dès lors qu’il y a du bruits et un ventilo, peut-on parler de solution silencieuse sans induire le consommateur en erreur ? Bon, ceci étant dit, le bruit généré est plus que acceptable, lors de mes derniers usage, j’avoue que celui-ci etait masqué par le bruit d’un disque externe placé à coté.

Quoi de neuf depuis tout ce temps ?

Posted on by
Reply

Voila un moment que je n’ai rien écrit … logique, le 0dB marche parfaitement et silencieusement… Par ailleurs, pas grand chose de nouveau dans le paysage. Alros pour quoi lire la suite ? a vous de voir ! lol !

Bon, quoi de neuf dans le monde du silence, pas grand chose à mon grand désarroi, j’aime beaucoup ma plateforme silencieuse quoi que j’aimerai lui donner un peu plus de punch. Rien de neuf coté CPU non ventilé à part le Atom D525 qui offre un dual core et 4 canaux d’exécution (ce qui est toutefois déjà pas mal). Il semble que l’engouement pour ces processeurs ne suscite chez item, amd ou via qu’une fréquence de mise à jour très faible. Les nouveauté pourraient toutefois arriver cette année avec la sortie imminente des atom D2500 et D2700 permettant de passer les 2G en double coeurs tout en restant à 10W … Alors je n’ai qu’une chose à dire … vivement cette sortie que ce site revive un peu avce une nouvelle plateforme à tester !

Bon week-end à vous !

Migration de VM de Xen vers KVM-Qemu

Posted on by
Reply

J’ai pu expérimenter la migration de VM avec kvm-qemu sur une opensuse 11.3 … Rien à redire c’est tres simple à mettre en oeuvre à condition de respecter 2,3 petites choses qui sont notées nul part :
– Pour pouvoir lancer la migration, il est nécessaire que le fichier de description de la VM soit bien présent sur la destination.
– Pour pouvoir lancer la migration, il faut que la source se connecte en utilisant le nom de machine et non son adresse IP sans quoi un message d’erreur générique est affiché, sans plus de détails.
– Il faut que le chemin du disque de la vm, partagé entre source et destination soit totalement identique.
– Il faut que le port VNC (à vérifier) soit disponible, celui-ci étant dynamique, il semble qu’il soit préférable de le forcer à une valeur fixe par VM lorsque la destination a deja des VM en cours d’exécution.

Cours de virtualisation

Posted on by
Reply

Ce document à été conçu dans le cadre d’une formation d’IUT informatique, pour une option de seconde année
Il aborde les notions de virtualisation de serveurs, de bureau et d’application. La mise à jour est de Janvier 2011.

Le support de cours est téléchargeable au format PDF ici.

Ainsi Fon fon fon …

Posted on by
Reply

L’histoire en soit à peu d’importance d’autant que rien n’en prouve la véracité. Cependant, d’un point de vu technique la situation est totalement probable. Après avoir creusé le sujet de FON avec le peu d’information disponible quant à la sécurité, voici ce que l’on peut en dire.

FON est un systeme de HotSpot mondial qui permet d’ouvrir votre réseau aux autres, je ne vais pas détailler le fonctionnel, mais d’un point de vue technique, le systeme (une AP) gère deux réseaux Wifi, le premier privé, protégé par WPA dans lequel vous mettez vos propres machine et un second réseau, lui public sans sécurité dans lequel viennent se connecter les inconnus de passage. L’Internet est ensuite accessible comme sur tous les hotspot : tant que vous n’êtes pas authentifié vous n’accedez qu’a une page de login et ensuite vous avez un accès HTTP/HTTPS classique.
Le point important est qu’une fois authentifié, vous accédez à l’Internet exactement de la même façon qu’un ordinateur du reseau privé (hors mis que bcp de ports sont filtrés), c’est à dire que l’adresse IP des utilisateurs hotspot se trouvera être la même adresse IP que celle du propriétaire de la ligne. Du point de vue des traces laissées sur Internet, c’est donc la personne qui met à disposition le point d’accès qui se retrouve responsable des action faites par des inconnus.
Le système semble logguer les actions de connexion/deconnexion mais pas le détail de ce qui est fait (après le login, les échanges ne sont plus centralisés et les box ne peuvent stocker un historique important, enfin du point de vue provider il n’est pas possible de dissocier les flux).Ainsi, s’il est possible de prouver qu’une autre personne utilisait Internet au moment de faits, il n’est pas possible de prouver qui était l’auteur de ces faits. En conséquence le système est donc dangereux pour la personne mettant en ?uvre le service. Prenons un exemple:
Une personnes se connecte à des sites pédophiles ou terroristes en utilisant cet accès, (cette personne aura d’ailleurs tout intérêt à utiliser ce type d’accès puisqu’il permet assez facilement d’y être anonyme (point à vérifier)), elle laisse des traces sur les serveur accédés. Dans le cadre d’une enquête de police ces traces sont recueillies et un beau matin à 6:00 vous pouvez voir débarquer un peu plus de monde que prévu à cette heure-ci. Même innocent, cette situation sera loin d’être agréable je l’imagine.

J’adore le principe ouvert de FON, mais d’un point de vue technique, je trouve que les capacité de log sont un peu légère, il est certes difficile de totalement protéger la personne qui partage sont adresse IP, mais je pense que le niveau de log inscrit dans le système devrait être très détaillé avec une rétention de plusieurs années. Voir, le recours à un proxy FON serait une solution bien plus sécurisante pour celui qui partage, ainsi ce n’est pas son IP mais celle du proxy qui serait visible des services de police, qui se tournerait vers FON pour obtenir des informations. Ceux-ci seraient donc alerté dès le début de la procédure de l’innocence présumée forte de celui qui a prété son acces.

De Xen à KVM …

Posted on by
Reply

Depuis environ 4-5 ans j’utilise Xen pour la consolidation de mes machines perso sur un serveur, précedemment bi-coeurs et maintenant quadri-coeurs. J’ai tout d’abord utilisé Xen pour des fonctionnalité de migration de VM me permettant à l’époque où j’hébergeais à la maison d’avoir une solution de replis sur un serveur habituellement utilisé en DEV en cas de crash de mon serveur de Prod. Puis en passant au Core2Duo, j’ai profité de la virtualisation pour faire de la consolidation et ainsi debrancher 4 machines qui ne font maintenant plus qu’une avec un petit NAS. Puis, récemment, j’ai décidé une mise à jour vers un Core2Quad avant que la technologie ne change trop et me demande un upgrade complet (ce que par ailleurs j’ai tout de même du faire à cause des imcompatibilité carte mère / cpu à 45nm)
Lors de ce changement de hardware, je ne m’attendais vraiment pas à devoir abandonner Xen, c’est pourtant ce qui s’est produit. Installant une OpenSuse 11.3, je me suis retrouvé sur un système totalement instable sous Xen (y compris sans VM monté) crashant dès lors que quelques dizaines ou centaine de Mo ont été transférés sur le réseau. Personne n’ayant pu m’aider suffisamment, même si le support Novell a bien regardé mon problème, j’ai finalement opté pour une solution plus radicale : passer sous hyperviseur qemu-kvm, lui reposant sur le noyan classique que j’ai pu tester comme étant stable sur ma configuration.
La migration s’est faite sans trop de mal, Xen comme KVM travaillent avec un disque logique dans un fichier (enfin je les ait utilisé ainsi) de même format. Je n’ai donc eu à modifier que le noyau pour y ajouter un noyau “default” en plus du noyau Xen et booter ce nouveau système sous qemu. Les outils Yast pour gérer ces VM ont été simple et facile d’usage pour créer un exemple de description de VM au format XML. J’ai ensuite pu retourcher ceux-ci à la main pour reprendre les adresse mac de mes config Xen. Une fois la technique trouvée en ayant migré la première (car les doc sur Internet ne sont pas légion et ne correspondaient pas à ma situation) j’ai pu migré mes VM en 10 minutes chacune.
Depuis 3j l’ensemble de mes VM fonctionnent convenablement. De ce que j’ai pu voir, les options de configuration de Kvm sont un peu plus riche que celle de Xen, toutefois, je cherche encore comment prioriser les VM (peut être simplement avce nice d’ailleurs) et un équivalent de xen top qui, je trouve, était pas mal…
Tout ceci me fait dire que Xen prend du plomb dans l’aile, déjà car il démontre un certain manque de stabilité qu’un module noyau devrait combler (kvm) et par ailleurs parce-que sa mise en oeuvre se trouve plus complexe que celle de kvm (noyau spécifique…) à suivre !

Problèmes de stabilité avec l’hyperviseur Xen – kernel debug

Posted on by
Reply

Bon, chaque mie à jour de matos à son lot d’emmerdes, et à ce jeux, je n’ai franchement pas de bol 🙁 l’informatique doit m’en vouloir … bref, me voila avec un système Xen Linux qui crash lamentablement dès que sont transférés plusieurs 100ènes de Mo sur une des cartes réseau … perso, je pense que le périphérique virtuel BR (bridge) est moisi, mais bon …
Manque de bol, les logs ne sont pas parlante et surtout rarement accessibles. De fait, j’ai eu besoin de brancher un jolie cable null-modem entre mon server et un portable pour avoir les logs jusqu’au dernier instant. Un petit rappel ici de comment mettre en oeuvre ceci

Tout d’abord, il faut trouver le cable null-modem, je le dit tout de suite, le petit dealer informatique du coin, lui parler null-modem ou chinois c’est kifkif ; j’ai donc trouvé mon bonheur chez un petit vendeur de composants électronique (mais pourquoi ai-je balancé mes tonnes de câbles passés !!!)
Une fois connecté, il est simple de tester la connexion en tapant sur un coté :
tail -f /dev/ttyS0
et de l’autre coté :
echo “coucou” > /dev/ttyS0

L’activation de la console se fait ensuite en modifiant /boot/grub/menu.lst pour ajouter les options suivante sur la ligne de commande, attention dans le cas de xen et d’un kernel normal c’est un peu différent :
Pour xen ajouter à la ligne kernel : loglvl=all guest_loglvl=all com1=9600,8n1 console=com1
¨Pour xen ajouter à la ligne modules : console=hvc0 earlyprintk=xen
Pour Linux ajouter :

Reste ensuite à booter et ecouter, pour l’ecoute je conseille deux terminaux :
cat /dev/ttyS0 > log.out
tail -f log.out
Comme ca on enregistre et affiche en meme temps le résultat dans un fichier.
Pour la vitesse, il serait mieux de passer à 115200 bauds, toutefois, pour ma part, je ne sais pourquoi mais le portable de reception n’a pas eu envie d’aller au dela de 9600bps, ce qui, il faut le dire ralenti grave le boot au point de le planter parfois.

Test de performance d’un serveur Kimsufi

Posted on by
Reply

Après avoir utilisé un serveur RPS durant 1 an, j’ai choisi de migrer sur un serveur Kimsufi. Le serveur RPS n’est pas mal mais le disque pose problème : il y a le principe du disque partagé à la bande passante vraiment trop limitée d’une part et la taille de ce disque elle aussi trop contraignante d’autre part.
Le serveur RPS offre un processeur normalement un peu plus rapide (double coeur et fréquence plus élevée) mais dont l’usage semble vraiment limité par le disque pour un usage web faisant appel à une BDD.

Le but de cet article est donc de comparer la performance avec mes petits outils habituels : bonnie++ et lmbench

Test du disque

  • Seq Out Char : Kim ( 33 M/s ) – RPS ( 5 M/s )
  • Seq Out Blk : Kim ( 50 M/s ) – RPS ( 6 M/s )
  • Seq In Char : Kim ( 38 M/s ) – RPS ( 4.7 M/s )
  • Seq In Blk : Kim ( 106 M/s ) – RPS ( 5.7 M/s )
  • Rand. Seek : Kim ( 186 /s ) – RPS ( 113 /s )

Avec un facteur de l’ordre de 10, il est clair que la performance du serveur kimsufi est très loin devant celle du RPS. La perf du RPS est de l’ordre de celle d’un disque NFS sur reseau 100Mb ; soit de l’ordre de 2 fois moindre qu’un disque USB suivant d’autres tests que j’ai pu réaliser. La performance du disque Kimsufi est conforme à des tests effectués sur des disques classiques sata. Ce facteur limitant impacte fortement les performances d’accès à la base de donnée par exemple ; pour le reste, sur un serveur web, hors temps de backup c’est moins critique.

Test du processeur

  • Fork de process : Kim ( 271 ms ) – RPS ( 191 ms )
  • Exec de process : Kim ( 1042 ms ) – RPS ( 654 ms )
  • Calcul int add : Kim ( 0.38 ns ) – RPS ( 0.48 ns )
  • Calcul int mul/div : Kim ( 0.38/23 ns ) – RPS ( 0.19/20.5 ns )
  • Calcul double add : Kim ( 2.26 ns ) – RPS ( 1.91 ns )
  • Calcul double mul/div : Kim ( 3/17 ns ) – RPS ( 1.93 / 10.4 ns)
  • 16p/64K Context switch : Kim ( 24 ms ) – RPS ( 22 ms)
  • Latence TCP : Kim ( 35 us ) – RPS ( 25.2 us)
  • Local comm – TCP : Kim ( 126 M/s ) – RPS ( 474 M/s )
  • Local comm – Bcopy : Kim ( 572 G/s ) – RPS ( 1.1 G/s )
  • Local comm – mem rd : Kim ( 2.2 G/s ) – RPS ( 2.5 G/s )
  • Local comm – mem wr : Kim ( 0.9 G/s ) – RPS ( 1.5 G/s )
  • Memory lantency L1/L2/Main/Rand: Kim ( 1.5/25/70/426 ns ) – RPS ( 1.4/8.1/62.5/180 ns )

Comme convenu la performance du Celeron est en dessous de celle de l’atom d’une génération plus recente avec une fréquence plus élevée et surtout un double coeur. N’empêche que l’écart entre les deux n’est pas d’un facteur 10 pas de 30 à 50% surtout lié aux accès mémoire.

Reste à tester mysql ; pour se faire j’ai utilisé myBench un petit outil tout simple en php :

  • Create 500k record : Kim ( 138 s ) – RPS ( 34 s)
  • Create md5 record / s : Kim ( 3300 ) – RPS ( 12949 )

Résultat plutôt surprenant où je m’attendais à ce que le kimsufi soit largement devant … une petite vérification des fichiers de conf s’impose ! à moins que ce ne soit le bench qui ne travaille que dans le cache …
Voyons donc avec sql-bench qui est distribué avec mysql et couvre plus de tests: (perl run-all-tests –server=mysql –user=.. –password=.. apres avoir créé une base ‘test’ sur mysql)

  • Alter : Kim ( 15s ) – RPS ( 49s )
  • Big-Table : Kim ( 10s ) – RPS ( 7s )
  • Connect : Kim ( 289s ) – RPS ( 121s )
  • Create : Kim ( 119s ) – RPS ( 4680s estimé )
  • Insert : Kim ( 2183s ) – RPS ( 581s estimé )
  • Select : Kim ( 141s ) – RPS ( 58s )
  • Update with key : Kim ( 159s ) – RPS ( 28s )

Etrange comportement du RPS sur les creation de table, j’imagine que celles-ci demande beaucoup d’I/O. Les requetes de select et insert sont beaucoup plus rapide. Ma config ayant beaucoup de cache (pour plier au probleme de disque) la puissance CPU semble prendre le dessus sur les requete insert/select/update et ce avec un facteur important de l’ordre de 2 à 3. Il semble donc, et c’est avec surprise, que la config RPS soit meilleure pour les accès bdd, ce qui pour le coup m’ennuie. On note toutefois que dès lors que l’on sort des conditions optimales, le test n’est pas du tout linéaire …

Voici donc quelques détails supplémentaires avec 1.5M de lignes à traiter:

  • Insert 3×1.5M : Kim ( 705s ) – RPS (146s )

Rien de bien neuf donc… si limite il y a dans la rupture de linéarité, elle est bien au dela des 1.5M de lignes.
Au final, une fois les sites migrés, je constate, à l’aide d’une sonde woozweb, que le temps de chargement moyen du site est 2 fois plus lente avec un KimSufi qu’avec un RPS, mais reste totalement acceptable, situant mes site dans la trache où 40% des sites font mieux pour du java et 9% pour du php basique.