Journal Terracotta monte les JVM en grappe

Posté par (page perso) .
Tags : aucun
10
9
fév.
2010
Pour satisfaire les besoins des applications JavaEE modernes, le recours au clustering est souvent indispensable. Celui-ci vise à augmenter les ressources allouées aux applications en multipliant les serveurs à sa disposition. Les solutions de clustering de serveurs d'application et de bases de données sont légions dans les environnements techniques des entreprises modernes mais qu'en est-il du clustering de JVM?

C'est la mission que s'est donnée Terracotta avec son outil OpenTerracotta. L'idée derrière le concept de Terracotta est de descendre la mise en grappe d'un cran pour l'appliquer directement aux machines virtuelles Java. Ceci permet de faire fonctionner une application trop gourmande pour une seule JVM sur plusieurs d'entre-elles de façon complètement transparente pour l'applicatif. De cette manière, le développeur est débarrassé de toute préoccupation de programmation en grappe et peut ainsi se consacrer pleinement à son application dont la conception est de fait simplifiée.
L'architecture d'une telle solution est classique quand il s'agit de clustering : un serveur, des clients et (moins courant) un serveur de stockage.

Les clients accueillent chacun une JVM qui inclut au démarrage un ensemble d'API Terracotta. Leur rôle est d'intercepter les appels Java responsables de la synchronisation des processus est d'y injecter du bytecode afin d'informer le serveur Terracotta des changements effectués sur le tas (heap) et donc les altérations subies par les objets. Les composants Terracotta répartis ne s'échangent que des deltas sur les objets des tas et économise ainsi la bande passante. Toutes les données qui concernent les objets Java sont enfin conservées par le serveur de stockage.
Dans les faits, Terracotta trouve quatre champs d'applications majeurs :
  • Réplication de sessions HTTP (Tomcat, Oracle WebLogic, Struts, Spring, ...)
  • Cache Distribué
  • Clustering de POJO/Intégration Spring
  • Collaboration, Coordination, et gestion d'évènements
Pour une présentation plus détaillée de cet outil ambitieux qu'est Terracotta, se référer à cet autre article du blog Zenika.com. On ne pourra ensuite que citer les très bons et très techniques articles en anglais d'infoq.com et de javaworld.com pour dévoiler les derniers secrets de l'outil.
  • # KISS

    Posté par . Évalué à 10.

    Les développeurs java ont l'air d'avoir vraiment oublie les principes de bases du Keep_it_Simple,_Stupid.

    Bon je retourne a mon noyau...
    • [^] # Re: KISS

      Posté par . Évalué à -1.

      Justement, Terracotta te propose de ne pas utiliser JPA (Java Persistent API).

      Ce qui est un gros plus en terme de simplicité. En terme de performance aussi.
      • [^] # Re: KISS

        Posté par . Évalué à 7.

        on sent que tu maitrises ton sujet. JPA n'a *rien* à voir avec le clustering de serveurs (c'est une API de mapping objet-relationnel, pour accéder aux enregistrements d'un sgbd comme si c'étaient des objets java)

        On ne devient pas Pierre Tramo en 1 jour !
    • [^] # Re: KISS

      Posté par (page perso) . Évalué à 3.

      Hein ? Quoi ! déjà Vendredy !!?
      Encore un vilain tour d'IPoT…
  • # Ca me fait doucement rire ....

    Posté par . Évalué à 2.

    Pour satisfaire les besoins des applications JavaEE modernes, le recours au clustering est souvent indispensable.

    Dire qu'on pourrait se passer de clustering en n'utilisant pas des usines à gaz tel que JavaEE (en utilisant pas java tout court d'ailleurs).

    Celui-ci vise à augmenter les ressources allouées aux applications en multipliant les serveurs à sa disposition.

    Alors ..... 1 serveur Quadri Pro Quatre coeur juste pour Jave, deux autres serveurs identiques JavaEE, quatre serveur pour gérer le clustering et 1/2 serveur pour l'appli. Cool !!!

    De cette manière, le développeur est débarrassé de toute préoccupation de programmation en grappe et peut ainsi se consacrer pleinement à son application dont la conception est de fait simplifiée. Génial, le développeur, débarassé de ces basses questions matérielles pourra développer sans optimisation. On s'en fiche, si ça tient pas la charge, on ajoute un serveur pour absorber tout ça. On pourra donc passer via une archi multicouche, avec communication XML entre les couches qui feront appel à d'autres couches pour le parsing .....

    Je me marre ....
    • [^] # Re: Ca me fait doucement rire ....

      Posté par . Évalué à 0.

      Toi je pense que tu n'as pas tout compris ...
    • [^] # Re: Ca me fait doucement rire ....

      Posté par . Évalué à 2.

      Trop drôle également, le journal précédent .... http://www.linuxfr.org/~galaux/29360.html !

      Faiut rajouter 5 serveurs pour gérer la grappe !!! Et on parle d'économies d'énergie ? Et ces trucs sont censés simplifier la vie ?
      • [^] # Re: Ca me fait doucement rire ....

        Posté par . Évalué à 4.

        C'est pour ça qu'on a inventé la virtualisation : c'est magique, avec un serveur physique on a une infinité de serveurs virtuels avec autant de proc et de ram qu'on veut!
        Bon, je plaisante bien sur, mais la réalité, c'est que développer en entreprise, c'est faire de la merde très vite, et de préférence avec une belle interface utilisateur. Que ça nécessite un supercalculateur derrière, c'est le problème du client...Qui voit la virtualisation comme décrit ci-dessus...
        Ce que j'adore, c'est quand les projet débarquent en nous disant que UNIX, c'est de la merde parce que leur application elle crash toute les semaines...

        Enfin bon, java c'est beau, c'est facile et ça peu rapporter gros...(Sic!)
      • [^] # Re: Ca me fait doucement rire ....

        Posté par (page perso) . Évalué à -2.

        Tu le fais exprès ou t'es né con et borné ?
    • [^] # Re: Ca me fait doucement rire ....

      Posté par . Évalué à 3.

      T'es du genre à croire que le backend de face de bouc c'est du php?

      Va utiliser Zend et prie. Amen.
      • [^] # Re: Ca me fait doucement rire ....

        Posté par . Évalué à 1.

        Euh Facebook visiblement, c'est du PHP... certes compilé en C++ via HipHop, mais à la base c'est bien écrit en PHP.
        • [^] # Re: Ca me fait doucement rire ....

          Posté par . Évalué à -1.

          Et en plus, fesse de bouk osef : c'est un site pour kikoolol, qu'il soit bien ou mal fait, personne ne verra la différence.
        • [^] # Re: Ca me fait doucement rire ....

          Posté par . Évalué à 7.

          le front end est en php. je pense pas pour le backend. En tout cas, googleAdds, c'est du java, je me demande pour eBay et Amazon. Le site de la SNCF est passé sous JBoss.

          Terracotta, c'est :
          - pas de SQL (donc pas de DB),
          - du lazyloading,
          - de la redondance au cas où ...

          Je vois pas comment on peut dire que c'est de la merde. En plus, contrairement à Hibernate (très lourd), il utilise du Bytecode enhancement, qui consiste à compiler le code de synchronisation à l'execution (comme Toplink, la couche JPA d'Oracle).

          Donc tu ne peux pas avoir PLUS SIMPLE et PLUS PERFORMANT, si tu comprends un minimum comment ça marche. Ou alors, montre moi qu'il peut y avoir mieux en gardant la même simplicité ...

          Je sais qu'il y en a beaucoup qui ne jure que par le php, j'ai été grossier et m'en excuse, mais si vous commencez à venir cracher sur java, faudrait juste un peu d'arguments (si possible, non affectif).
          • [^] # Re: Ca me fait doucement rire ....

            Posté par . Évalué à 10.

            Non mais tu es sur linuxfr. Le site ou tout le monde peut se permettre de donner des leçons aux équipes engineering des plus gros services du monde sur un coin de nappe entre midi et 2, par ce que eux ils savent (c).

            Ebay c'est du Java (Ils utilisent que la partie "basse" de J2EE), Amazon c'est majoritairement du Java (Certains traitement sont en C++ ou Perl), linked-in c'est du Java (sauf la gestion du graphe), certains service yahoo c'est du java, orbitz aussi. Non vraiment y'a rien a dire Java ca marchera jamais, c'est pas efficace et y'a pas plus couteux en prod. Tout les gros s'en sont d'ailleurs aperçu, et ne contribuent absolument pas aux projets de la fondation Apache ;-)

            C'est pas par ce que les SSII pondent des bouzes infâmes que Java c'est de la merde. C'est juste par ce qu'ils pondent des bouzes...
            • [^] # Re: Ca me fait doucement rire ....

              Posté par (page perso) . Évalué à 5.

              Et encore, tu n'entends que parler des bouses des SSII parce que les non-bouses, c'est pas très motivant d'en parler. Ça marche et puis voilà.
            • [^] # Re: Ca me fait doucement rire ....

              Posté par (page perso) . Évalué à 8.

              Le site ou tout le monde peut se permettre de donner des leçons aux équipes engineering des plus gros services du monde sur un coin de nappe entre midi et 2, par ce que eux ils savent (c).

              Je proteste énergiquement, il n'y pas d'heure pour faire ça.

              « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

            • [^] # Re: Ca me fait doucement rire ....

              Posté par . Évalué à 7.

              Non mais tu es sur linuxfr. Le site ou tout le monde peut se permettre de donner des leçons aux équipes engineering des plus gros services du monde sur un coin de nappe entre midi et 2, par ce que eux ils savent (c).

              Quand on voit des sites comme Voyages-SNCF, oui, on se met à douter des compétences des équipes engineering, quelle que soit la taille du site, et pas forcément à tord.

              Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

          • [^] # Re: Ca me fait doucement rire ....

            Posté par (page perso) . Évalué à 6.

            Le site de la SNCF est passé sous JBoss.

            Attends, je rêve ou tu es en train de nous citer comme exemple le site de la SNCF ?

            Excusez-moi un instant, je reviens… (ha ha ha ha ha ha HA HA HA HA HA HA HA HA HA HA HA HA HA HAaaaaaaarrrrhh de l'air, aïe, mes côtes…). Pfiou, ça va mieux.

            C'était ironique, n'est-ce pas, cette citation de la SNCF ?
          • [^] # Commentaire supprimé

            Posté par . Évalué à 7.

            Ce commentaire a été supprimé par l'équipe de modération.

            • [^] # Re: Ca me fait doucement rire ....

              Posté par . Évalué à 4.

              perso, j'aimerais bien me passer de sql pour parler a mon sgbdr, mais oracle ne veut rien entendre. Les cons!

              - JAVA (le langage) -> annotations/génération automatique
              gne?
              T'as compris le concept des annotations au moins ou bien?

              - .java -> .class -> .jar -> .war -> .ear
              Pareil, gne?
              class = java compile.
              jar = zip (contenant des .class et ce que tu veux en fait). On pourrait tout mettre dans un class, mais heu ca va etre vilain quand meme et pas tres tres pratique.
              war = zip
              ear = zip

              - JPA/spring ce sont apparement des problèmes. Révolution : on peut ne pas les utiliser.
              mettre jpa et spring dans la meme phrase, c'est pour le moins etonnant.
              Moi je veux bien me passer de jpa, maintenant tout le monde stocke ses donnees dans une base de donnees relationnelle.
              Si tu connais un meilleur moyen d'interfacer du code avec un sgbdr sans devenir completement chevre a ecrire des requetes sql de partout pour persister un graphe de quelques dizaines d'objets de types completement differents, en mettant les trucs dans l'ordre pour les foreigns key, faire tes delete on cascade et tout le tralala, je suis toute ouie et je t'ecoute avec grande attention.
              • [^] # Commentaire supprimé

                Posté par . Évalué à 1.

                Ce commentaire a été supprimé par l'équipe de modération.

                • [^] # Re: Ca me fait doucement rire ....

                  Posté par . Évalué à 2.

                  Il est stupide de faire des mapping relationnel-objet.
                  aaaaaah.
                  C'est ptetre stupide, mais c'est encore ce qui marche le mieux, vois tu? J'ai meme envie de dire que c'est le seul truc qui marche...

                  Ca te gène pas 3 zip l'un dans l'autre ? C'est vraiment une solution batarde, des couches inutiles l'une au dessus de l'autre (Tu ne vois vraiment pas plus simple ou tu es vraiment de mauvaise foi ?).
                  Franchement, si c'est le seul "reproche" que t'as a afaire sur la complexite de java, t'es passe a cote d'un paquet de trucs.
                  hint: ton war ou ton ear peut contenir que des fichiers, et aucun autre zip.
                  C'est juste crade de balancer tes .class, si tu veux virer une lib, tu vas etre marron.
                  Un question pour toi, quand tu met une lib dans /usr/lib, tu met un .so? ou tu met tous les petits fichier .o a la queu leu leu?
                  Quand tu zippes un repertoire, tu prends soin avant de dezipper chaque archive que t'aurais dedans?
                  Si grouper des fichiers qui vont ensemble est inutile, je sais pas quoi te dire.

                  Bien sur, c'est un bidule qui a été ajouté pour pallier à des trucs (méta-informations, macros, dynamisme - certaines formes -, ...
                  Macros?!?!!!?
                  Les annotations sont des meta infos, c'est tout, ni plus ni moins. C'est des donnees statiques, pas de code, juste des donnees. Une annotation ne fait en rien en soi, c'est soit le compilo, soit le code appelant qui va les verifier..
                  C'est quoi la difference entre un #pragma override et un @Override?
                  Comment tu m'implementes un @Required avec des macros et des pragmas?
                  Quelles annotations peuvent etre remplacee par des macros?
                  • [^] # Commentaire supprimé

                    Posté par . Évalué à 2.

                    Ce commentaire a été supprimé par l'équipe de modération.

                    • [^] # Commentaire supprimé

                      Posté par . Évalué à 2.

                      Ce commentaire a été supprimé par l'équipe de modération.

                      • [^] # Re: Ca me fait doucement rire ....

                        Posté par . Évalué à 1.

                        ????
                        Et comment ton code appelant fait pour savoir que ton attribut est required?
                        Tu la met ou ton annotation? Non pas la, non...

                        'fin je sais pas, tu serais venu me dire "les generics sont a chier, c'est une implementation ni faite ni a faire parce que sun a pas eu les couilles de casser la compat", j'aurais compris et abonde dans ton sens, qualifier les annotation d'un truc lourd qui est une surcouche inutile a une tare, la je comprends pas, ton message ne veut rien dire...
                    • [^] # Re: Ca me fait doucement rire ....

                      Posté par . Évalué à 0.

                      tu me parlais d'autres langages, donc pas limite a lisp.

                      Explique moi donc comment tu implementes une quelconque annotation runtime avec des #define et des #pragma.
                      La tu parles visiblement de c/c++/objc, donc je suis tres tres curieux de savoir comment tu vas implementer ca.
                      Quand au etc. je voudrais bien savoir a quoi il correspond.

                      Je pense que tu ne connais pas les macro common lisp
                      Non, je ne connais pas lisp, donc expliques moi.
                      • [^] # Re: Ca me fait doucement rire ....

                        Posté par . Évalué à 3.

                        Alors c'est simple, une macro LISP est évaluée deux fois, et tout étudiant ayant déjà fait du C et utilisé les macros du C pleure du sang pour s'en dépêtrer. :-)

                        (Sinon LISP c'est bien pour de vrai)
        • [^] # Re: Ca me fait doucement rire ....

          Posté par . Évalué à 6.

          Et visiblement tu ne sais absolument pas de quoi tu parles.

          Facebook utilise différents langages et fonction des besoins, et essai d'utiliser le plus adapté au service. Tu retrouves, entre autre, du:
          - PHP pour les frontend
          - Du C/C++ pour les caches, pour les serveurs de photos (cf. http://www.facebook.com/note.php?note_id=76191543919 ) ou pour la gestion des logs (voir scribe)
          - Du Java pour tout ce qui touche au datawarehouse: Grosse contribution à hadoop, pig et hive, cassandra pour du map/reduce, bigtable & co
          - De l'Erlang pour le service de Chat
          - Du Python (voir tornado)

          D'ailleurs c'est pas un hasard si facebook à créé thrift qui permet la serialization et les appels RPC entre plusieurs langages !

          Et certainement beaucoup d'autres choses qu'ils n'ont pas documentés.

          Et pour le bozo qui t'as répondu, fourni un service qui tient la charge de fb et on en reparle après. Pour rappel, il y a quelques temps c'était 550.000 photos/sec servies en pic, 220 millions de nouvelles photos/semaine, 400 milliards de pages/mois.
    • [^] # Re: Ca me fait doucement rire ....

      Posté par (page perso) . Évalué à 7.

      Dire qu'on pourrait se passer de clustering en n'utilisant pas des usines à gaz tel que JavaEE (en utilisant pas java tout court d'ailleurs).

      Et tu proposes quoi à la place?

      http://devnewton.bci.im

  • # Halala Java

    Posté par . Évalué à 4.

    Je me suis inscrit sur linuxfr[1] uniquement car j'en avais assez de lire des commentaires moisis rédigés par des gens aux neurones dans le même état que leur commentaires dont le seule but est de tenter de faire croire qu'ils savent écrire du code mieux que les autres.

    Il y à 7 ans, je n'aimais pas Java, j'étais un "webmasteur qui maîtrise le Php" et Java c'était naze. Ensuite, chose que semble t'il personne ici ne fait, pour pouvoir critiquer je me suis décidé à apprendre Java.
    Java est plus gourmand que Php oui. Je code en Java avec Eclipse qui prend beaucoup de ressources alors que je fais du Php avec n'importe quel éditeur de texte. Mais Java est complexe et permet de tout faire, notamment grâce aux innombrables API[2], contrairement à Php.
    La complexité rebute sûrement les faibles capacités intellectuelles de certaines personnes qui, dans l'incapacité de comprendre ce langage, préfèrent le critiquer.


    [1] Dont le formulaire d'inscription et les restrictions sur le login sont en complète opposition avec les bonnes pratiques que beaucoup ici font semblant de défendre.
    [2] Les APIs sont la preuve d'un langage bien pensé. Essayez de trouver une API en Php et cherchez sont équivalent en Java, vous aurez certainement un ratio de 1:3. Après il reste à étudier les trois possibilités et voir laquelle correspond el mieux à vos attentes, à moins que devoir choisir et risquer de faire un mauvais choix vous fasse peur.
    • [^] # Re: Halala Java

      Posté par . Évalué à 10.

      En même temps, tu tapes sur les mauvaises personne ici.

      On rigole de Java, mais on rigole aussi de PHP.

      En fait, à part Lisp, rien n'est assez beau pour nous.
    • [^] # Re: Halala Java

      Posté par . Évalué à 10.

      Moi je me suis inscrit sur ce site parce que j'en avais assez de lire des commentaires de gens tristes qui prennent tout au premier degré.
      J'étais même sûr qu'il y en avait certains réceptifs à l'auto-dérision.



      La complexité rebute sûrement les faibles capacités intellectuelles de certaines personnes qui, dans l'incapacité de comprendre ce langage, préfèrent le critiquer.

      C'est puissant et argumenté comme raisonnement ca. Ca te place tout de suite intellectuellement au dessus de ceux que tu critiques.
    • [^] # Re: Halala Java

      Posté par (page perso) . Évalué à -3.

      Si tu veux une API riche, libre et extensible, va voir sur le CPAN de Perl ;-)

      Moi, les packages en org.machin.truc... je pense que le défaut de conception est à la racine.
      • [^] # Re: Halala Java

        Posté par (page perso) . Évalué à -1.

        Rahh mais non, puisque la racine est la fin !

        ??
        OK je -----> []

        « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

      • [^] # Re: Halala Java

        Posté par . Évalué à 10.


        Moi, les packages en org.machin.truc... je pense que le défaut de conception est à la racine.


        Houlala ! Parler de défaut de conception et citer Perl en référence.
        Y'en a qui osent quand même !
    • [^] # Re: Halala Java

      Posté par . Évalué à 5.

      Moi ce qui me fait rigoler c'est de voir autant de moules dirent "le web 2.0" ça pue, et les retrouver sur des news comme ici en train de dire "java ça pu, php c'est mieux" et de t'expliquer pourquoi et comment dans leurs projets web ils préfèrent d'autres solutions à Java.
      :-)
      Un des avantages de Java c'est qu'il n'est pas borné à une finalité. Java c'est aussi de zolis programmes sur des téléphones pas du tout smartphones (et pourtant ça marche). Java c'est aussi des applis dans de petites boites qui se baladent partout, vraiment partout. Bref quant php essaie encore de faire ses pruves sur le web, Java a tout conquis. Donc bon... Objectivement... Ce n'est pas parcequ'il y a des contres exemples que c'est nul. Sinon on pourrait dire que le C c'est super lourd, à la vue de Gnome.

      /zut c'est jeudi

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.