modelisation d’application

November 17th, 2016

Les applications sont devenues de plus en plus complexes et étudier le comportement et leur performance l'est d'autant plus. Surtout que beaucoup d'entre-elles comportent énormément de paramètres, typiquement, si on prend des produits comme web logic JBoss le manuel de tuning comporte des centaines de pages. D'où l'idée de modéliser les applications, c'est-à-dire d'avoir une vue un peu "stratosphérique" afin de mieux comprendre sur quels leviers agir.
Cette vision est bien sur une vision macro, mais on constate à travers les exemples relativement simples qu'elle a déjà un certain nombre de point d'observation et d'analyse sur lequel il faut porter son attention.
Ce modèle expose les relations entre les demandes générées par une charge de transaction et les ressources du système pour y faire face.
On pourra, bien sûr, la faire évoluer, soit en ajoutant d'autres éléments non pris en compte, soit en augmentant la précision du modèle.

TLDR;
* un délai dans une transaction vient de : un manque de ressource active ou un accès limité à une ressource active du à un manque de ressource passive.
* un manque de ressource passive est la cause d'une sous-utilisation de ressource active.
* dans un environnement majoritairement virtuel, les queues sont les indicateurs les plus fiables.

Construction du modèle

Pour construire notre modèle, on va avoir besoin d'un certain nombre d'éléments.

Les transactions

Elle caractérise notre requête utilisateur ! Si on imagine une usine de voiture, ou notre véhicule va parcourir la chaine, ici c'est notre transaction qui va visiter différent serveur et y passer du temps. On va trouver par exemple des choses comme :

  • login
  • rapport d'activité
  • une transformation de données
  • l'exécution d'une règle business
  • etc…

Les ressources

C'est tout ce qui va pouvoir être alloué pour la transaction. On va les classer en deux catégories : actives et passives.

En actives, on va trouver :

  • CPU
  • I/O
  • Network

En passives :

  • threads
  • espaces de stockage
  • allocation mémoire
  • les locks

De manière imagé on peut dire que les ressources actives exécutent la transaction et les transferts de données, tandis que les ressources passives fournissent un accès aux ressources actives que la transaction va consommer. D'un point de vus mesure, de façon général, une ressource active sera mesurer par un temps d'exécution tandis qu'un ressource passive sera plutôt une quantité (ex: nombre de connections, ou taille de mémoire …)

Nœud physique

Un nœud physique représente un serveur, une Appliance ou un élément de réseau.
Chaque un ensemble de ressources active et passive a une queue dans laquelle les transactions sont en attente de ressources disponibles.

Nœud virtuel

Un nœud virtuel c'est bien évidemment une machine virtuelle qui est représenté par un time-slice, ainsi une queue d'attente.

Nœud de ressources partagées

C'est un nœud physique qui possède des ressources partagées (ex: disques, CPU, etc.) à la différence d'un nœud physique.

La matrice ressource transaction

Avec une matrice on va définir pour chaque transaction les ressources active ou passive que qui vont être utilisé pour consommer le service.

matrice

matrice

L'utilisateur

L'utilisateur, évidemment, c'est la source de tout et notre but est de s'assurer qu'il y aura assez de ressources pour pouvoir les accueillir. Dans notre modèle, une transaction commence son voyage lorsqu'un utilisateur click sur un lien.
Au passage, on peut noter, que le temps entre deux clique d'un même utilisateur (souvent appelé think-time dans les logiciels) définit l'intensité du flux.

Exemples de modélisation

A partir de ces éléments, on peut définir notre modèle. Ici, on a composé deux modèles d'exemple de déploiement : un complètement physique et un complètement virtuel d'une application web Basic (aka 3 tiers). On va regarder un petit peu les différences que nos modèles peuvent nous montrer.
Dans un très classique 3 tiers on trouve : un serveur web, un serveur d'application et une base de données et on va supposer que 3 machines seront utilisées. Par ailleurs, on va dire que la transaction va commencer son voyage quand l'utilisateur va cliquer sur le lien et va donc suivre le cheminement à travers le serveur Web puis le serveur d'application, etc. La transaction va solliciter des ressources actives et passives telle qu'indiqué dans la matrice. A la fin, la réponse sera retournée à l'utilisateur. Le temps qui aura était passé dans tous les nœuds sera le temps de réponse. On peut d'ores et déjà voir que ce temps est à deux composantes : le temps de traitement par les ressources actives, et le temps d'attente d'accès aux ressources.

Cela donne le modèle physique suivant :
modele physique

Tandis que l'on aura un modèle virtuel comme ici :
modele virtuel

On observe rapidement une différence majeure entre le virtuel et le non virtuel.
* Le modèle virtuel a un ensemble de ressources partagées à travers les VMs.
* chaque VM ne peut utiliser ses ressources passive ou partagé que lorsque l'hyperviseur lui alloue un time-slice.

Analyse/Utilisation

Avec notre modèle, on va pouvoir, par exemple, regarder ce qui allonge le temps de réponse de nos transactions.
En regardant les schémas, on peut voir que pour traiter la transaction, nos serveurs ont besoin de CPU (!), et/ou que l'application à besoin de mémoire (ressources) pour son traitement. Que se passe-t-il si on manque de l'un de ces éléments ? Notre transaction va se retrouver dans une des queues à attendre ! Résultat, notre transaction va être retardée alors que le CPU n'est pas complétement utilisé par exemple.

Une famine de ressource passive entraine une sous-utilisation d'une ressource active.

Un délai peut-être causé par deux choses :
* un manque de ressource active.
* un accès limité à une ressource active à cause d'un manque de ressource passive.

En terme de production, cela veut dire que pour identifier les goulets d'étranglement, il va falloir monitorer non seulement les ressources active mais aussi les ressources passives. Et dans les ressources passive, il y a autant les éléments physiques "classiques" (mémoire, espace disque…) mais aussi des éléments plus logiciels (threads, connections pool, lock, les sémaphores etc.). On constate que pour pouvoir définir les ressources passives à monitoré cela demande des connaissances fines de l'interne de l'application et de son architecture.

allons plus loin…

Mais si on regarde le modèle virtuel cette fois, on va également constater d'autres effets.
On note, entre autre, l'apparition d'une nouvelle ressource critique : le time-slice que partagent toutes les VMs hébergées sur un même serveur.
Cet élément est structurant, pour qu'une VM puisse tourner il faut que son hyperviseur lui alloue une time-slice pour accéder à ses ressources physiques, ce qui n'est le cas que lorsque la ressource partagé demandé par la VM devient disponible !
De façon générale, un hyperviseur traite les VM comme des processus qui peuvent être stoppés et/ou reprises à n'importe quel moment. L'impact est que la VM ne peut plus compter sur un espace-temps linéaire et en conséquence les métriques de performances sont plus forcément représentatives !

Toutes métriques qui utilise un intervalle de temps (ex: utilisation CPU, nombre d'IOPS… en gros les compteurs les plus populaires) devient par conséquent non représentative

Que peut-on y faire ?

En se reportant à notre modèle, on perçoit que chaque ressource listé à une queue associé, et que pour avoir accès à sa ressource notre VM va devoir y attendre !

Les tailles de queues et les temps d'attente dans celle-ci sont les éléments majeurs qui définissent la performance de notre système car indépendant de toute notion de temps.

On peut aussi constater qu'une queue fournit l'indication d'un écart entre la demande (généré par notre charge de travail) et la disponibilité des ressources pour la satisfaire.

On peut aussi se poser la question de la pertinence de notre modèle de déploiement dans le cas virtuel. En effet, dans notre cas, la transaction va voyager à travers différentes VMs ce qui va augmenter le temps de traitement car chaque VMs va devoir attendre l'allocation d'un time-slice, les composants installés dans chaque VM venant en compétition des ressources partagées.
Imaginons donc le nouveau déploiement suivant : une application est installée entièrement dans une VMs dédié.
modele virtuel partagé
Le résultat implique qu'une transaction pourra être un durant un seul time-slice diminuant de fait son temps de traitement ! On aura toujours compétition sur les ressources partagé, mais, ici, entre applications et non plus au sein d'une même application.

Conclusion

Notre modèle, certes simplifié, nous permet déjà d'observer les gros points d'attentions et de mettre en évidence des différences entre physique et virtuel.

Bien sûr, en prenant en compte d'autres éléments dans sa construction, on pourra aller plus loin dans la modélisation de son comportement. D'autre part, parmi les évolutions, on peut aussi envisager d'aller chercher la théorie des queues, pour essayer de modéliser plus finement toutes les file qu'on l'on a dans le système.

Modele Mémoire Java vs Physique

January 12th, 2016

La JVM est un modèle complet d’ordinateur, il inclus notamment celui de la mémoire. Mais en pratique cela peut-être très différent du modèle physique et avoir un impact sur le programme. Un modèle mémoire, quant à lui, décrit les conditions dans lesquels une écriture faite par un thread sera visible par un autre thread faisant une lecture. La plupart des développeurs pensent que l’écriture d’une variable quelconque sans aucune synchronisation sera visible de n’importe quel thread faisant une lecture (on appelle se comportement “sequential consistency” ) . Et pourtant, il n’y a pas que la mémoire, le cache etc., qui peuvent poser des problèmes de mémoires, il y a aussi, par exemple, le compilateur. Il est possible par exemple que l’optimisation faite par un compilateur casse une application ! C’est pourquoi il est utile de mieux comprendre le modèle de mémoire proposé par la JVM.
Le modèle mémoire de la JVM.
Le modèle interne de la JVM est relativement simple. Il se décompose en deux grande partie : la pile (heap) et la pile de thread. Chaque thread qui tourne possède sa propre pile, qui contient les appels#160; mais aussi les variables locales de type primitif (ex: int) . Cela implique par exemple que chaque thread à sa propre version d’une variable locale.
La pile (heap) contient elle tous les objets crée par l’application et ce quelque soit le thread qui l’a crée (incluant aussi les objets comme Integer ).
On peut résumer ainsi :
* variable local primitive : stocker dans la pile local
* variable local “objet” : la réference est dans la pile local, l’objet est dans la Heap.
Il est à noté que de ce fait, tous les objets de la Heap peuvent être accéder par n’importe quel thread, à partir du moment ou on a une référence.
Prenons par exemple le code suivant :
public class MyRunnable implements Runnable() {
public void run() {
methodOne();
}
public void methodOne() {
int localVariable1 = 45;
MySharedObject localVariable2 = MySharedObject.sharedInstance;
//... do more with local variables.
methodTwo();
}
public void methodTwo() {
Integer localVariable1 = new Integer(99);
//... do more with local variable.
}
}
public class MySharedObject {

//static variable pointing to instance of MySharedObject
public static final MySharedObject sharedInstance = new MySharedObject();
//member variables pointing to two objects on the heap
public Integer object2 = new Integer(22);
public Integer object4 = new Integer(44);
public long member1 = 12345;
public long member1 = 67890;
}

2 threads déclarent des variables locales, dont l’une pointe ver un objet partagé sur la Heap. les références sont stocké dans chaque pile, mais l’objet est le même sur la Heap. Résultat, les objets 2 et 4 sont accessible par les 2 threads, par contre, les objets 1 et 5 ne le sont pas.

Le modèle physique
Venons en maintenant au modèle physique. De nos jour, un ordinateur est généralement constitué de plusieurs CPU souvent eux même constitué de plusieurs cœurs. Chaque cœur peux faire tourner un thread de façon indépendante. Chaque cœur possède également ses propres registres et de la mémoire cache, de même que le CPU (L1/L2/L3…). Bien évidement, un ordinateur dispose aussi de mémoire RAM commune et accessible à tous. Point important : quand un cœur à besoin d’un élément en RAM, il va le lire dans l’un de ses caches puis dans ses registres. A l’inverse, pour mettre à jour, il va d’abord écrire dans le cache, puis plus tard l’écrire en mémoire. Souvent, ces deux mécanisme ne se font pas unitairement, mais par ce que l’on appel “cache line” ce qui implique la lecture ou l’écriture de plusieurs valeurs en même temps.
cpu-diagram
Rassemblons les deux modèles
Maintenant que nous avons une vision des deux modèles, on peut repérer les différences. il est clair par exemple que le hardware ne fait pas la différence Heap/Stack. On peut aussi comprendre qu’a un instant donné des variables ou de morceau de Heap peuvent se retrouver dans différents endroits : cache, registre, RAM etc …
java-memory-model-5
Et c’est la que les problèmes peuvent arriver !
On peut les classer en deux grandes catégories :
* les problèmes de visibilités
* les “race conditions”
Problème de Visibilité
Imaginons un objet qui se trouve dans la Heap. Initialement stocké dans la RAM. Imaginons qu’un thread souhaite y accéder, comme on l’a vu, l’objet va se retrouver dans le cache d’un CPU. Supposons que l’on fasse des modifications sur cet objet. Tant que le CPU n’aura pas vidé sont cache en RAM, les modifications ne seront pas visible par les autres CPUs qui accèderait à la valeur ! C’est la qu’intervient la notion de volatile qui force la lecture mais aussi l’écriture en RAM de la variable. On appelle aussi cela une “Memory Barrier”, en assembleur se sont des instructions qui force l’ordre d’exécution de certaines actions. Notons que dans certains cas il n’est même pas nécessaire d’avoir plusieurs thread pour être dans ce genre de cas les optimisation du compilateur peuvent avoir ce genre d’effet de bord.
Si on résume : le mot clef volatile indique à la JVM de produire les instructions permettant au processeur de garantir la cohérence de la mémoire RAM.
Attention quand même d’après la JLS :

It should be noted that the presence of a happens-before relationship between two actions does not necessarily imply that they have to take place in that order in an implementation. If the reordering produces results consistent with a legal execution, it is not illegal.

ce qui veux dire que l’on parle d’ordre et pas de temps cpu, et qu’il y a donc des cas ou volatile seul ne suffit pas.
Pour plus de détail vous pouvez vous référer aux $17.4.4 “Synchronization order” et#160; §17.4.5 ‘’”happens-before order” de la JLS
Les Race Conditions
Imaginons cette fois ci que les deux threads font l’opération simultanément.#160; Cette fois, les valeurs sont bonnes, mais le résultat final ne l’est pas. ex: si on a fait 2 additions, on espère avoir 3#160; (1+1+1 !) or on aura 2 (1+1) !
La solution ? la synchronisation ! Un bloc dit synchronisé garantie qu’un seul thread peut entrée dans cette section “critique” à un instant donnée. Au passage, il garantie aussi que toutes les variables seront lues depuis la RAM, et qu’à la sortie du bloc, toutes les variables modifiées seront écrite en RAM et ce qu’elles soit volatile ou non.

Diffy : faire des tests sans les eacute;crire ?

November 27th, 2015

pnbsp; pLes systèmes sont de plus en plus complexe et les tests de non régression suivent le même chemin. Twitter propose donc une solution qui ne demande qu’une installation minimale pour detecter un maximum de bug. C’est le genre de chose que vous lisez et vous vous demandez pourquoi vous ne l’avez jamais fait avant p“emAs the complexity of a system grows, it very quickly becomes impossible to get adequate coverage using hand-written tests, and there’s a need for more advanced automated techniques that require minimal effort from developers. Diffy is one such approach we use/em,” explique Puneet Khanduri, membre de l’équipe de développent Twitter dans un post. h3Pourquoi ?/h3 pLorsque l’on développe, notre code évolue en permanence. De plus, de nos jours, avec des architectures comme SOA, on se retrouve avec de très grands nombres de services, très souvent en croissance rapide. Il devient donc difficile de savoir si, tous marchent correctement. pLa réponse traditionnelle à ce problème passe généralement par l’écriture de tests unitaires. Malheureusement, cela prend du temps, la portée en est fréquemment très limité, le nombre de ces tests croit par ailleurs de façon exponentielle et devient très vite ingérable. p“emwriting good tests can take more time than writing the code itself/em.” nous dit Puneet Khanduri pTwitter propose une nouvelle approche avec Diffy. pAlors, qui y-a-t-il de différent ? Souvenez-vous, il vous est surement déjà arrivé de faire ce que l’on appelle communément des « Y » pour copier des données (souvent de prod) vers une nouvelle version. Diffy industrialise et automatise cette idée. h3Comment ça marche Diffy ?/h3 pDiffy va nous permettre de faire tourner l’ancien et le nouveau code et de comparer les résultats. C’est de ce côté là que se trouve la grande nouveauté. pEn général, quand on fait un « Y », on fait des tests par échantillons sur le résultat, en général sur ce qui est en BDD ou dans des fichiers. Diffy, lui utilise le résultat des requêtes. En effet, il va faire proxy et/ou multicast des requêtes en entrée, mais aussi récupérer les résultats et les comparer et rapporter les régressions. A la base, si le résultat est le même, le service est bon. Mais à l’usage on va se rendre compte que ce n’est pas si simple. En effet, pour tous un tas de raison (comme des timestamps, des sessionids, des randoms, des races conditions, etc.), il arrive que pour une même requête le résultat soit différent, on obtient alors beaucoup de faux positif. pC’est là qu’intervient la proposition de Twitter : appliquer une annulation de bruit. pComment ça se passe ? pL’idée de Twitter, et de, non pas, faire tourner 2 versions, mais 3 versions : la nouvelle bien sûr, mais aussi 2 anciennes. pa href=”http://vald70.free.fr/wordpress/wp-content/diffy.png”img title=”diffy” style=”border-top: 0px; border-right: 0px; background-image: none; border-bottom: 0px; padding-top: 0px; padding-left: 0px; border-left: 0px; display: inline; padding-right: 0px” border=”0″ alt=”diffy” src=”http://vald70.free.fr/wordpress/wp-content/diffy-thumb.png” width=”234″ height=”244″/a/p pLe postulat est que les différences de résultats fournis par les deux anciennes correspondent au bruit de fond. Et les différences entre la nouvelle et une ancienne à nos régressions. Bien sûr, il faut rajouter à cela un peu de statistique pour limiter le nombre de faux positif./p pOn peut donc se trouver dans plusieurs cas : p* les deux instances v1 renvoient la même réponse, et la nouvelle v2, une réponse différente. C’est le cas le plus simple, il est remonté directement dans les rapport.a href=”http://vald70.free.fr/wordpress/wp-content/diff-v1.png”img title=”diff_v1″ style=”border-top: 0px; border-right: 0px; background-image: none; border-bottom: 0px; padding-top: 0px; padding-left: 0px; border-left: 0px; display: inline; padding-right: 0px” border=”0″ alt=”diff_v1″ src=”http://vald70.free.fr/wordpress/wp-content/diff-v1-thumb.png” width=”210″ height=”244″/a p* cas le plus courant : toutes les version on des différences, par exemple un sessionid. Dans un premier temps Diffy va remonter un warning indiquent un possible bruit de fond. Et vous allez pouvoir l’exclure des rapports.a href=”http://vald70.free.fr/wordpress/wp-content/diffy-noise.png”img title=”diffy_noise” style=”border-top: 0px; border-right: 0px; background-image: none; border-bottom: 0px; padding-top: 0px; padding-left: 0px; border-left: 0px; display: inline; padding-right: 0px” border=”0″ alt=”diffy_noise” src=”http://vald70.free.fr/wordpress/wp-content/diffy-noise-thumb.png” width=”222″ height=”244″/a pPour le moment, il manque encore des fonctionnalités, par exemple si votre réponse peux changer en fonction de certains paramètres il va être difficile de la classifier en bruit ou en normal ! pMais, pour 80% des ca,s cela offre une grande avancé dans les tests. pPour tester : ples sources du projet : a title=”https://github.com/twitter/diffy” href=”https://github.com/twitter/diffy”https://github.com/twitter/diffy/a, avec pour les afficionados de Docker, des exemples pour lancer vos tests sous Docker !

recreacute;e un fichier VMX

November 3rd, 2015

pnbsp;/p pIl se peut que pour diverses raison le fichier VMX d’une machine virtuelle vmware soit corrompus./p pSi vous avez encore en votre possession les fichiers de log il y a un moyen de reconstituer ce fichier avec un minimum de manipulation./p pstrongprérequis/strong : /p p* un accès SSH sur l’hôte ESXi/p p* un script shell !/p pfont face=”Source Code Pro”#!/bin/bash/font/p pfont face=”Source Code Pro”#VMXFILENAME=$(sed -n ’s/^.*Config file: \(.\+\)$/\1/p’ vmware.log)brecho -e “#\041/usr/bin/vmware” gt; ${VMXFILENAME}brecho ‘.encoding = “UTF-8″‘ gt;gt; ${VMXFILENAME}brsed -n ‘/DICT — CONFIGURATION/,/DICT —/ s/^.*DICT \+\(.\+\) = \(.\+\)$/\1 = “\2″/p’ vmware.log gt;gt; ${VMXFILENAME}/font/p pstrongméthode/strong :/p p* se placer dans le répertoire de la VM/p p* exécuter le script : /p pex: font face=”Source Code Pro”/vmfs/volumes/513397ea—143299f0—1e26—000c29428399/vm3#nbsp; sh recreatevmx.sh/font/p pfont face=”Source Code Pro”* re-enregister la VM :/font/p p#vim-cmd solo/registervm font face=”Source Code Pro”/vmfs/volumes/513397ea—143299f0—1e26—000c29428399/vm3//fontvm3.vmx/p pstrongnote/strong: /p pil est possible que l’UUID est changé si vous avez fait des manip sur la data store./p pvous pouvez ajouter les lignes suivantes au script pour en tenir compte :/p pcodefont face=”Source Code Pro”NEWUUID=$(sed -n “s/^.*UUID: Writing uuid.location value: ‘\(.\+\)’.*$/\1/p” vmware.log)/font/code/p pfont face=”Source Code Pro”if [ "${NEWUUID}" ] then sed -i “s/uuid.location = .*$/uuid.location = \”${NEWUUID}\”/” ${VMXFILENAME} fi/font/p

Microsoft Azure utilise de lrsquo;assistance hardware FPGA pour son SDN

October 1st, 2015

Alors que Flickr prend la voie des GPGPU, Microsoft semble prendre celle de FPGA…

Microsoft Azure est construit sur du Software Defined Networking (SDN) et obtient sa scalabilité en se basant sur du logiciel pour répondre à ses besoins.

La société a déclaré qu’elle a commencé à utiliser le matériel qu’elle appelle l’Azure SmartNIC dans ses centres de données. Le emsmartNIC intègre de la logique FPGA (Field Programmable Gate Array) qui permet à l’adaptateur réseau d’être reprogrammé au besoin par Microsoft.

«Nous utilisons la technologie FPGA qui a été introduite pour Bing”, a déclaré Albert Greenberg, distinguished engineer en développement réseau chez Microsoft.

“Il a été utilisé pour accélérer l’indexation et la recherche de Bing, et nous avons eu cette technologie dans la maison que nous avons appliqué à la carte réseau, et nous obtenons des économies incroyables avec, beaucoup mieux que si nous avions à le faire sur le serveur lui-même en utilisant sa puissance de calcul. “

pemSmartNIC : une carte d’interface réseau, une carte FPGA, ce qui signifie qu’il est programmable par logiciel. SmartNIC couvre les fonctions qui ont besoin d’un coup de pouce du matériel, ou que Microsoft préfèrerez simplement décharger du CPU.

- La philosophie étant que les processeurs sont mieux utilisés à exécuté des machines virtuelles pour servir les clients Azure.

Le strong100 Gb/s réseau commence à devenir une réalité dans le centre de données,nbsp; SmartNIC va être appliqué en ligne - ce qui signifie que tous les flux de trafic passent à travers elle - pour toutes les fonctions y compris le cryptage, le traitement de la qualité de service, et l’accélération du stockage. En l’occurrence, le cryptage est un excellent exemple de «boost»: le matériel sera toujours en mesure de le faire plus vite que logiciel.

«Nous sommes une société de logiciels, ce qui nous permet de déployer le matériel à la vitesse du logiciel. Nous pouvons changer la programmation des FPGAs chaque semaine. Non pas que nous allons le faire chaque semaine, mais nous pourrions le faire si nous le devions pour corriger n’importe quel problème “ dit Russinovich le CTO de Microsoft Azure.

pRussinovich a également indiqué que les règles des SmartNIC FPGA proviennent d’un élément central appelé le iVirtual Filtering Platform (VFP). Il envoie un paquet à travers des tables de correspondance d’actions à venir avec une règle particulière pour l’écoulement de ce paquet – Une exception chez Azure : plutôt que d’appliquer des règles par flux, Microsoft tend à le faire par-connexion, mais quoiqu’il arrive, le VFP regarde juste un paquet et applique les règles qui en découlent pour les paquets ultérieurs de la connexion et/ou du flux et si nécessaire, ces règles sont mises en œuvre par le biais des SmartNIC./p pLors d’une conférence, Russinovich a également parlé du système à plusieurs niveaux de contrôleurs SDN dans Azure, chaque niveau étant responsable de délégué les flux aux clusters inférieurs, Mais aussi de garder un état pour les cas de bascule./p pDans la même idée, Microsoft déploie également des Altera Arria 10 FPGA. Microsoft entend ici utiliser tout le potentiel IEEE754 (virgule flottante) en utilisant OpenCL et du VHDL pour coder le FPGA./p pDurant ses tests, Microsoft obtient 40 GFLOPS-par-Watt avec les échantillons Arria 10 et le Developer Kit, ce qui donne un rapport GFLOPS-par-Watt trois fois meilleur que celui obtenu avec du GPGPU./p pLa conférence de Mark Russinovich : a href=”https://youtu.be/RffHFIhg5Sc”https://youtu.be/RffHFIhg5Sc/a/p

osx yosemite (10.10) et canon mp620

April 18th, 2015

jusqu’à présent j’était sous 10.9 et ma mp620 fonctionnait très bien. Mais voila, un passage en 10.10 et puis plus rien ! Selon canon seule la mp630 fonctionne en 10.10 ! pourtant quelques heures avant ma 610 n’avait pas de problème ;-)
Du coup me voila à la recherche de solution, la première d’entre elle : installer les drivers pour 10.9. Jusque là pas de problème tous s’installe correctement. Pourtant pas d’imprimante détecter, à si le scanner lui est reconnu et s’installe, magnifique. Après quelques recherche j’apprend que Apple est passé à CUPS 2.0 et que dans sa grande bonté, il a même mis en oeuvre du sandboxing… Et voila le problème, mes bon vieux driver 10.9 ne sont pas compatible avec le sandboxing.
ouf il ya un solution : le mode “Relax” ;-)

sudo sh -c ‘echo “Sandboxing Relaxed” >> /etc/cups/cups-files.conf’
sudo launchctl stop org.cups.cupsd

et voila un peu restart, un peu d’attente et voila mon imprimante qui apparait ! et je peut même imprimer avec, c’est un comble, n’est-ce pas monsieur Canon ?

Paypal the next step ?

April 1st, 2015

p#160;/p pLa partie Front de Paypal est à présent 100% sous Openstack à annoncé Sri Shivananda son VP il y a quelques jours./p pSous cette apparente simple annonce, il y a beaucoup d’implications !/p pPremier point : toute la partie WEB et API est maintenant sur un cloud privé basé sur OpenStack./p pEnsuite, c’est le fruit d’un travail commencé il y a maintenant quelques années (plus précisément en 2011 img class=”wlEmoticon wlEmoticon-winkingsmile” style=”border-top-style: none; border-left-style: none; border-bottom-style: none; border-right-style: none” alt=”Clignement d#39;œil” src=”http://vald70.free.fr/wordpress/wp-content/wlemoticon-winkingsmile.png” / avec la bascule progressive (20% durant cette première période de Noël) des flux vers une nouvelle plateforme OpenStack, pour en arrivé aujourd’hui à 100%./p pPourquoi ce choix ? Le principal levier était de ne pas être lié à un fournisseur (en l’occurrence VMWare), l’usage d’OpenStack leur fournissant plus de souplesse dans leurs choix./p pem“With OpenStack, PayPal has more control over customization and more choice in the vendors it uses for its hybrid cloud environment,” Sri Shivananda, vice president of global platform and infrastructure at PayPal, said via email./em/p pParmi les autres avantages : le time to market, qui permet maintenant de déployer les applications en quelques minutes contre plusieurs jours./p pL’un des points important à noter est la participation active à plusieurs communautés#160; Open source./p pIl faut aussi noter que Paypal a choisit d’utiliser sa propre distribution d’OpenStack et non pas une solution du commerce et qu’il a, à ce jour, un déploiement de celle-ci sur plus de 8500 serveurs mais quelle n’est pas non plus exclusive vis-à-vis de VMWare./p pCet usage d’un cloud privée est en augmentation selon les dernières études faites par GigaOM ( One-Third of Cloud Users’ Clouds are Private, Heavily OpenStack 01/2015 ) et plus de 65% des sondés considèrent qu’OpenStack est prêt pour la production et beaucoup de vendeurs propose des distributions, mais on le voie ce n’est pas la seul route…/p pemBut there are also users like PayPal that have enough of their own engineering muscle to build cloud infrastructure using OpenStack on their own. Convincing customers like these to pay for a vendor’s package of a piece of open source technology is a tough sell.
/em/p
p#160;/p pa title=”https://www.paypal-community.com/t5/PayPal-Forward/PayPal-s-Front-End-Cloud-Powered-by-OpenStack/ba-p/959621″
href=”https://www.paypal-community.com/t5/PayPal-Forward/PayPal-s-Front-End-Cloud-Powered-by-OpenStack/ba-p/959621″
https://www.paypal-community.com/t5/PayPal-Forward/PayPal-s-Front-End-Cloud-Powered-by-OpenStack/ba-p/959621/a/p

Configuration: Modélisation ou Scripting ?

October 9th, 2014

 

Quel est la différence entre un langage descriptif et un langage déclaratif ? Prenons un exemple… Si vous cherchez une voiture, vous allez dire, je veux 5 place, un grand coffre, le gps, l’iphone etc… vous n’allez pas demander si la roue est installé par une machine XYZ et un tournevis cruciforme ?

Et bien, c’est cela la différence ! Dans un cas, le langage déclaratif, vous indiquer dans quel état vous souhaitez que le système soit tandis que dans l’autre vous explicitez quels sont les étapes pour y arriver.

Dans le cas de la gestion de configuration, cette différence est important.  En effet, dans un cas vous dite juste, je veux un serveur apache/tomcat, dans l’autre vous dite, il faut récupérer le rpm apache, puis l’installer, puis activer mod_http puis … etc !

Dans le premier cas on modélise l’état que l’on veux avoir, alors que dans le second il faut faire attention a toutes les variantes que l’on pourrait trouver, genre, zut, il y a déjà un apache, je doit vérifier la version etc …

Conclusion

On peut lister ainsi les bénéfices d’une gestion de configuration déclarative :

* c’est répétable : chaque exécution donnera le même résultat quelque soit l’état de départ.

* c’est consistent :encore une fois , quelques soit l’état de départ, l’état d’arrivé sera celui désiré.

* c’est auto-documenté : en général les langages déclaratif sont très simple et facilement compréhensible contrairement à des scripts et en général beaucoup plus concis/compact. Et de fait, devient un atout pour l’auditabilité.

exemple d’outils déclaratif :

* puppet, salt, confsolve, lcfg, bcfg2

exemple d’outils non déclaratif :

* fabric, chef,

That’s Not My Problem - I’m Renting Them

October 9th, 2014

 

Cette petite phrase de Adrian Cockroft “That’s not my problem, I’m renting them.”, c’est la réponse un peu imagé qu’il a faite lorsque quelqu’un l’a interrogé sur la fiabilité des SSD !

Un peu imagé, pourquoi ? Parce qu’en fait c’est l’illustration même de l’abstraction qu’offre le cloud. Et c’est bien comme ça qu’il faut voir les choses aujourd’hui. le cloud et plus généralement la virtualisation offre un tel niveau d’abstraction qu’il ne faut plus se préoccuper des ces aspects matériels sauf bien sur si vous en êtes le fournisseur et non l’utilisateur.

vmware et les “large pages”

October 7th, 2014

 

VMWare comme la plupart des OS à une gestion de mémoire qui s’adapte en fonction des usages.

L’un des paramètres sur lequel on peut influer pour affiner ses algorithme s’appelle le “LPageAlwaysTryForNPT”  ou encore l’allocation de pages larges.  Mais Kesako ?

In the cases where host memory is overcommitted, ESX may have to swap out pages. Since ESX will not swap out large pages, during host swapping, a large page will be broken into small pages.

En fait tout part du fait que VMware afin d’optimiser la mémoire utilise une technique dite de Transparent Page Sharing (aka TPS) qui permet de partager des pages mémoires identiques afin de libérer de la mémoire. Une sorte de deduplication. A l’origine de ça, les ESX scan régulièrement leurs page de 4Ko afin de trouver de nouveau candidat. D’un autre côté, si le hardware le permet et que l’OS de la VM le demande, ESX préfère utiliser ce que l’on appelle des “larges pages”  soit 2Mo au lieu de 4Ko, mais dans ce cas il va rarement trouver de bon candidat au partage !

A côté de cela, l’ESX comme tout OS va éventuellement swapper la mémoire au besoin. Dans ce contexte, lorsque l’ESX va swapper une page il va devoir la “casser” en petit morceau de 4Ko et va profiter de l’occasion pour tenter de trouver de nouveau candidat au partage. On peut résumer cet effet par “partager avant de swapper”.

Parmi les impacts que cela à, c’est celui de retarder le partage de page.

Le paramètre LPageAlwaysTryForNPT, va permettre de favoriser le page sharing en demandant à l’ESX de n’allouer des large pages que lorsque c’est demandé explicitement par l’OS (par exemple avec MySQL ou Oracle). L’avantage c’est que le reste du temps on aura des pages plus petite (4Ko) et l’action du TPS et donc plus de partage de page.

L’effet va donc dépendre de la workload, si vous avez un système avec de nombreuse “petite” vm, ce sera avantageux car il y aura plus de partage, la consommation mémoire va diminuer et vous pourrez poussez plus loin la consolidation. D’un autre coté si vous avez des grosses VM avec des applications demandant beaucoup de mémoire et donc très probablement des large pages (tel que MysQL ou Oracle ) il y aura plutôt un effet négatif.

Sachez aussi que le paramètre se situe au niveau Host mais aussi au niveau vm (sched.mem.alwaysTryLPageAlloc).

Il faut aussi noter que lors d’un vmotion, l’ESX transfert des pages de 4K, et les regroupe ensuite à nouveau en large page.