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 Benoît Sibaud (site web personnel) . En réponse au lien Un gros serveur pour en finir avec le cloud ?. É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.