Pourquoi les grands sites utilisent-ils plusieurs serveurs au lieu d'un serveur avec de meilleures spécifications?

J'ai lu que Stack Overflow utilise 10 serveurs ou plus pour desservir le site Stack Overflow. Différents serveurs ont différentes fonctions telles que le proxy inverse, le serveur de base de données ou le serveur HTTP.

J'ai vu un serveur unique autonome puissant avec ces spécifications:

• 2 x Xeon E5-2630v2 à 2,60 GHz, total 12 noyaux, 24 fils; 30 Mo
• 64 Go ECC Reg. jusqu'à 768 Go de DDR3 à 1600 MHz
• 4 séries Intel 520/530 de 120 Go (80 000 IOPS aléatoires, ~ 550 Mo / s)
• HP iLo4 Advanced avec port de gestion Ethernet dédié.

Pourquoi ne pas utiliser un seul serveur avec des spécifications plus élevées, telles que 768 Go de RAM, 20 To + disque dur, 4+ x Xeon? Quels sont les avantages liés à l'utilisation de plusieurs serveurs ou les inconvénients liés à l'utilisation d'un seul serveur haute spécification?

Un seul serveur puissant ne peut être mis à niveau que jusqu'à présent. Une fois que vous disposez du serveur le plus puissant disponible, votre site ne peut pas se développer davantage sans le scinder entre les serveurs ou le rendre plus efficace.

Il y a aussi le facteur coût. Un serveur très puissant peut coûter dix fois plus cher que deux serveurs deux fois moins puissants. Vous voulez pouvoir acheter votre matériel au prix le plus bas et ne pas être bloqué dans un prix plus élevé, car c'est la seule solution qui fonctionnera.

La disponibilité et la fiabilité entrent également en jeu. Avec deux serveurs ou plus, un peut échouer ou être mis hors ligne pour maintenance et le site peut rester actif. Vous ne pouvez pas faire cela avec un seul serveur.

La plupart des grands sites Web utilisent des équilibreurs de charge et plusieurs serveurs. Je travaillais pour TripAdvisor. Ils ont publié un excellent article sur l'architecture de TripAdvisor et sur la manière dont ils la rendent hautement évolutive avec plusieurs serveurs.

Il est possible d'exécuter un service avancé sur un seul serveur. Un exemple que je connais est Mailinator. L'auteur a publié un article sur l'architecture de Mailinator . Il s’efforce de rendre son code plus efficace plutôt que d’acheter de nouveaux serveurs. Cela finit par être une limitation qui dicte le fonctionnement de son service. Il ne conserve le courrier que quelques heures avant que l’unique machine ne le supprime pour laisser de la place à d’autres.

La mise à niveau d'un seul serveur est appelée mise à l' échelle verticale . L'ajout de serveurs est connu comme une mise à l' échelle horizontale . Pour plus d'informations sur ce sujet, voici quelques articles qui comparent les deux:

• Wikipedia: Mise à l'échelle horizontale et verticale
• Réflexions IBM sur le cloud: comment expliquer la mise à l'échelle verticale et horizontale dans le cloud
• Vidéo Internap: mise à l'échelle verticale vs horizontale

Du contre-amiral Grace Hopper:

Sur la construction d’ordinateurs plus grands: "À l’époque des pionniers, ils utilisaient des bœufs pour tirer fort, et quand un bœuf ne pouvait pas bouger une bille, ils n’essayaient pas de faire pousser un plus gros bœuf. Nous ne devrions pas essayer de plus gros ordinateurs, mais pour plus de systèmes d'ordinateurs ".

la source

Stephen explique la considération majeure à prendre en compte lors du choix d'une architecture système: le compromis entre la mise à l'échelle verticale et horizontale. Je vais ajouter quelques autres considérations:

• Séparation des problèmes: vous mentionnez plusieurs systèmes radicalement différents: les serveurs mandataires inversés, les bases de données, les serveurs de contenu, etc. Du point de vue de la maintenance et de la sécurité, il est clairement avantageux de laisser ces responsabilités réparties sur différents systèmes afin qu'ils puissent exécuter un système d'exploitation différent (version) si nécessaire, peut être mis à jour séparément et n'a pas d'incidence sur les autres services en cas de compromission.
• Livraison de contenu: tel est l'objectif ultime d'un serveur Web et se prête bien à un modèle distribué. Les systèmes peuvent être dupliqués et répartis géographiquement de manière à minimiser la latence des connexions longue distance. Cela permet également la redondance . Les grands sites Web utilisent des équilibreurs de charge (encore un autre ensemble de serveurs!) Pour permettre le basculement automatique afin de maintenir le service opérationnel à tout moment.

Il existe en fait une classe de serveurs entière qui prend la mise à l'échelle verticale à un autre niveau: les ordinateurs centraux. Ils présentent de nombreux avantages (rapidité, fiabilité) et inconvénients (coût), mais ils sont généralement utilisés lorsque des quantités énormes de données doivent être traitées via le traitement entrée-sortie dans ce que nous appelons le traitement des transactions (pensez aux achats par carte de , élection et recensement). Les banques, par exemple, desservent des sites à partir de serveurs Web à échelle verticale, tandis que le back-end finissait par traiter les transactions via le système central.

Il est intéressant de noter que des sociétés telles que Paypal et Visa s'éloignent des systèmes centraux vers des systèmes en cluster de milliers de systèmes mis à l'échelle horizontalement. Dans un monde numérique en rapide évolution, même les ordinateurs centraux atteignent le plafond de la mise à l'échelle horizontale:

"Avec toutes les exigences de disponibilité et de performances, nous ne pouvions pas continuer à traiter les paiements sur les ordinateurs centraux,

Source: Adam Banks, dans ComputerWorldUK

• Taille limite. Nous aimons prétendre qu’une seule boîte avec plusieurs processeurs, puces de mémoire et disques est uniforme. Ce n'est pas tout à fait vrai, mais c'est assez vrai si vos chiffres ne deviennent pas trop gros. Il existe des limites techniques à la chaleur, à l'énergie, à la proximité, etc., ce qui signifie qu'il y aura toujours une limite pratique à la taille d'un serveur.

• Évolutivité: il existe une grande différence entre un système à serveur unique, utilisant la mémoire partagée pour IPC et un système à plusieurs serveurs utilisant la mise en réseau ou en cluster. Cependant, la différence entre deux serveurs et 200 est considérablement plus petite - si vous avez construit un système évolutif, vous pouvez le faire évoluer BEAUCOUP plus grand avant qu'il y ait un problème ... et si vous l'avez, alors vous n'avez pas besoin d'un énorme serveur unique. en premier lieu.

• Résilience - Un serveur est un endroit qu'un administrateur peut "oups". Ou il y a un problème physique qui signifie que le service pour tout ce morceau d'étain est interrompu. (Une fuite d’eau dans un centre de données, une personne s’effondrant dans un rack et le renversant, ce genre de chose). Plusieurs serveurs peuvent être répartis dans un centre de données ou, mieux encore, géographiquement. Et si vous distribuez déjà votre application, la mise à l'échelle sur des machines de taille "moyenne" est presque toujours moins chère que la même quantité de CPU / mémoire / E / S sur un plus petit nombre de machines plus grandes.

• Mises à jour - Si je corrige un serveur, cela peut rendre un service instable, nécessiter un redémarrage ou sinon, demander un temps d'indisponibilité. Si j'ai 4 serveurs exécutant la même chose, je peux en mettre un hors service pendant un certain temps pour le faire. Et laissez-le hors service si le cycle de correction / mise à jour se passe mal.

Prenons le problème à petite échelle. Un petit bureau avec un serveur exécutant la messagerie, ActiveDirectory, le partage de fichiers et le site Web de la société.

Les pirates informatiques ont frappé et vous devez redémarrer car IIS est gâché. Ou Exchange nécessite une mise à jour et un redémarrage. Ou Active Directory s'est corrompu.

N'importe lequel de ces problèmes isolés "un service est en panne" affecte l'ensemble du serveur. Tout partage sur ce serveur va donc les affecter du fait qu'il doit redémarrer ou autre chose.

Une fois qu'un véritable informaticien se présente et voit ce serveur, il recommandera de les séparer en plusieurs serveurs (et de disposer d'un serveur de contrôleur de domaine de secours).

C'est le vieil adage de "ne mettez pas tous vos œufs dans le même panier"

Maintenant, cette philosophie est appliquée aux serveurs Web. Si je n'ai qu'un seul serveur Web et que je publie mon application Web (le nouveau MyFaceLink.com) et que cela devient vraiment populaire, j'ai de nouveaux problèmes. Je ne peux pas démonter le site pour effectuer la maintenance tant que les utilisateurs y sont. Et si cela se bloque ou que je reçois trop d'utilisateurs, je suis fatigué. Même le plus gros serveur au monde sera submergé par 1 milliard de convertis FB.

Ainsi, l’équilibrage de charge entre en jeu, pour la même raison "oeufs dans le panier". Répartissez le site sur 3 serveurs et, en cas de panne, les 2 restants gèrent la capacité. Si j'ai besoin de faire des patchs, je n'en fais qu'un à la fois, et personne ne le remarque.

Au plus simple, il ne s'agit pas du prix du méga-serveur ni de la capacité réelle de ce dernier à gérer la charge (bien que cela puisse être). Il s'agit d'un seul point d'échec. Une fois que les affaires sont suffisamment occupées et qu’elles se déroulent 24h / 24, 7j / 7 au lieu de 5 utilisateurs travaillant 8h-5h, les temps morts ne sont pas acceptables. Les pannes programmées sont plus difficiles à programmer. Donc, vous répartissez la charge.

Si l'on essaie de faire en sorte qu'une machine fasse le travail de deux, certaines parties de la machine devront être plus grandes mais fonctionner à la même vitesse, certaines peuvent rester de la même taille mais devront fonctionner plus vite et d'autres devront être plus grandes et plus vite. La mesure dans laquelle il est logique de combiner les rôles de petites machines en machines plus grandes ou de scinder les rôles de machines plus grandes en machines plus petites dépend en grande partie du type de mise à l'échelle qui s'appliquerait aux parties les plus coûteuses des machines. Si les charges de travail d'un trop grand nombre de machines sont combinées en un énorme colosse, les coûts seront alors dominés par des éléments qui devraient être plus importants et plus volumineux .plus rapide pour gérer des charges de travail accrues. Même si les coûts de ces choses étaient linéaires en termes de vitesse et de taille, doubler la charge de travail ferait plus que doubler le coût d'une machine pour la traiter. Le fait que la vitesse augmente au-delà d'un certain point entraîne une augmentation (beaucoup) supérieure aux coûts linéaires, ce qui amplifie l'effet.

Il n'y a pas vraiment de point fixe où la praticité impose une subdivision du travail; En fonction du type de travail à effectuer, une machine qui combine les charges de travail de deux peut se passer de deux fois plus de mémoire, voire moins de deux fois la vitesse. D'autre part, plus un ordinateur est chargé de tâches, plus la mémoire et la vitesse requises sont mises à évoluer de manière linéaire avec la charge de travail. Plus on va au-delà, plus le coût relatif augmente chaque fois que l'on double la charge de travail.