Lien Un gros serveur pour en finir avec le cloud ? Posté par devnewton 🍺 (site web personnel) le 03 août 2022 à 11:17. Étiquettes : cloud hébergement 11 3août2022 https://specbranch.com/posts/one-big-server/
# résumé
Posté par Papey . É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 Nicolas Boulay (site web personnel) . Évalué à  3. Dernière modification le 04 août 2022 à 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 Benoît Sibaud (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 Nicolas Boulay (site web personnel) . Évalué à  6.
Bon résumé :)
La partie patch d'OS peut aussi être acheté (genre clever-cloud ou autre cloud).
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 Benoît Sibaud (site web personnel) . Évalué à  5.
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.
[^] # Re: résumé
Posté par Nicolas Boulay (site web personnel) . Évalué à  4. Dernière modification le 04 août 2022 à 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 barmic 🦦 . Évalué à  3.
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.
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.