• # r√©sum√©

    Post√©¬†par¬† . √Čvalu√©¬†√†¬†4.

    Il y a de nombreux cas d'usages o√Ļ, quand vous avez besoin de cro√ģtre en puissance processeur ou en d√©bit r√©seau, il est plus simple et moins cher de prendre un unique serveur plus gros que l'ancien, plut√īt que de grossir "horizontalement" en rajoutant des serveurs, ou en se tournant vers un fournisseur de services "cloud" "sans serveur". L'exception est si votre cas d'usage implique des pics d'activit√© tr√®s importants et peu fr√©quents.

    • [^] # Re: r√©sum√©

      Post√©¬†par¬† (site web personnel) . √Čvalu√©¬†√†¬†3. Derni√®re modification le 04/08/22 √† 09:06.

      Le gros serveur a pour gros problème sa disponibilité si il casse ou si le réseau autour de lui casse. Et il y a les sauvegardes. Le mieux est donc d'avoir 'quelques' gros serveurs distant.

      "La première sécurité est la liberté"

      • [^] # Re: r√©sum√©

        Post√©¬†par¬† (site web personnel) . √Čvalu√©¬†√†¬†8.

        Si tu t'en fiche de la disponibilité, tout sur un serveur.
        Si tu veux de la disponibilité, un service actif-actif sera sur deux serveurs, une grappe de serveurs rabbitmq / kafka / mongodb / elasticsearch / truc-qui-va-par-3 sera sur trois serveurs.
        Si tu veux encore plus de disponibilité, les deux ou trois serveurs seront dans des datacenters proches mais distincts.
        Si tu veux encore plus de disponibilité, les groupes de 2 ou 3 seront dupliqués sur un second groupe de 2 ou 3 datacenters éloignés.
        Si… avoir des fournisseurs différents et idéalement des technologies différentes.
        Si… encore d'autres régions ailleurs sur le globe.
        Si… d'autres planètes et satellites naturels ou artificiels
        Si… d'autres systèmes solaires, galaxies, amas de galaxies, etc.
        Si… ta prévision marketing est supérieure à la population de la petite planète bleue, revois les chiffres de ton avant-vente.
        Nb: la latence entre les sites augmente, et la disponibilité des adminsys sur place diminue.

        Plein de serveurs : plus de temps à les patcher pour la sécurité, à les superviser, à les opérer en général (tout avoir automatiser ne change rien au fait que ça prend plus de temps que sur peu de serveurs). Plus de pannes (logicielle, matérielle, réseau, API de cloud qui bogue, électrique, désastre naturel, etc. ; chacune ayant moins d'impact sur le service rendu, mais nécessitant du temps de réparation, automatisé ou non).
        Peu de gros serveurs : moins de temps à patcher, j'aimerai bien voir le BIOS qui compte la RAM au démarrage :), moins de temps à superviser, opérer, il faut avoir suffisamment de services pour les remplir d'un point de vue économique, les pannes ont un gros impact service, si ce modèle se tape un souci *bleed/CPU-qui-fuit les solutions peuvent être assez limitées. Ah aussi c'est plus facile de leur donner des noms sympas et signifiants que des noms aléatoires.

        • [^] # Re: r√©sum√©

          Post√©¬†par¬† (site web personnel) . √Čvalu√©¬†√†¬†6.

          Bon résumé :)

          La partie patch d'OS peut aussi être acheté (genre clever-cloud ou autre cloud).

          Ah aussi c'est plus facile de leur donner des noms sympas et signifiants que des noms aléatoires.

          http://cloudscaling.com/blog/cloud-computing/the-history-of-pets-vs-cattle/

          "La première sécurité est la liberté"

          • [^] # Re: r√©sum√©

            Post√©¬†par¬† (site web personnel) . √Čvalu√©¬†√†¬†5.

            http://cloudscaling.com/blog/cloud-computing/the-history-of-pets-vs-cattle/

            Je sais bien, mais tant qu'à avoir seulement deux gros serveurs, autant les nommer la Belle et la Bête, tandis que si tu as 101 serveurs, ça sera pénible pour les prénoms de dalmatiens…

            Idée de génie : une API qui pioche dans les prénoms de mamounes (*) de http://liguedesofficiersdetatcivil.fr/ pour nommer des serveurs, cumulant ainsi les inconvénients des deux approches… une liste infinie de prénoms non retenables et impossibles à écrire sans faute.

            (*) la manoune (peu importe son genre) va appeler sa progéniture Bhen'hoyst, qui se prononcera "beunoi", comme ça sa descendance sera unique et ne sera pas comme "les autres moutons", même si elle ne saura jamais écrire son prénom, et les autres n'ont plus d'ailleurs.

            • c'est Bhen'hoyst qui a plant√©, ou Beunoidhs¬†?
            • non ssh sur Bbenhn'oua¬†!
            • [^] # Re: r√©sum√©

              Post√©¬†par¬† (site web personnel) . √Čvalu√©¬†√†¬†4. Derni√®re modification le 04/08/22 √† 11:05.

              J'ai un souvenir des serveurs de dev unix sous nom égyptien. Bizarrement Hatchepsout était moins encombré que Toutankhamon.

              "La première sécurité est la liberté"

        • [^] # Re: r√©sum√©

          Post√©¬†par¬† . √Čvalu√©¬†√†¬†3.

          plus de temps à les patcher pour la sécurité, à les superviser, à les opérer en général (tout avoir automatiser ne change rien au fait que ça prend plus de temps que sur peu de serveurs).

          De mon expérience quand tu as peu de serveur, tu procrastine l'automatisation ça prend donc au final plus de temps et c'est sujet à plus d'erreur du coup. Et tu as des temps de disponibilité bien plus allongé parce que tu dois attendre que l'admin prenne en compte ta demande.

          Parce que oui l'automatisation n'est pas gratuite, mais plus on s'y prend tard plus c'est compliqué. Mais ça permet d'y passer du temps quand tu le souhaites et pas d'y passer du temps quand tu as une demande avec de la pression ou autre chose à faire.

          il faut avoir suffisamment de services pour les remplir d'un point de vue économique

          C'est bien plus simple de dimensionner des petites machines que des grosses.

          Des petites machines tu peux aussi les allumer/√©teindre au besoin. Sans aller jusqu'√† de l'√©lasticit√© o√Ļ tu allume ou √©teint en fonction de la charge, tu peux √©teindre des machines les week-ends d√©j√†.

          Les petites machines sont bien plus souples aussi. Si tu as plusieurs r√©seaux physiques et que finalement tu veux une machine de plus d'un c√īt√© et une de moins de l'autre c'est faisable. Tu peux faire la m√™me chose si tu veux finalement d√©ployer sur plusieurs sites sans augmenter la capacit√© totale (tu veux juste gagner en r√©silience).

          Les grosses machines viennent aussi avec des contrats constructeurs très chère et bloquant par exemple avec un DRM pour n'utiliser que des disques du constructeur.

          Les petites machines te permettent d'utiliser des vlans pour segmenter ton usage.

          https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Suivre le flux des commentaires

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