Pourquoi n'est-il pas conseillé d'avoir la base de données et le serveur Web sur la même machine?


127

En écoutant l'interview de Scott Hanselman avec l'équipe de Stack Overflow ( parties 1 et 2 ), il a insisté sur le fait que le serveur SQL et le serveur d'applications devraient être sur des machines distinctes. Est-ce juste pour s'assurer que si un serveur est compromis, les deux systèmes ne sont pas accessibles? Les problèmes de sécurité l'emportent-ils sur la complexité de deux serveurs (surcoût, connexion réseau dédiée entre les deux, plus de maintenance, etc.), en particulier pour une petite application, où aucune des pièces n'utilise trop de CPU ou de mémoire? Même avec deux serveurs, avec un serveur compromis, un attaquant pourrait encore faire de sérieux dommages, soit en supprimant la base de données, soit en manipulant le code de l'application.

Pourquoi serait-ce si grave si les performances ne sont pas un problème?

Réponses:


158
  1. Sécurité. Votre serveur Web réside dans une zone démilitarisée, accessible sur Internet public et prenant des informations non fiables d'utilisateurs anonymes. Si votre serveur Web est compromis et que vous avez suivi les règles de moindre privilège pour vous connecter à votre base de données, l'exposition maximale est ce que votre application peut faire via l'API de base de données. Si vous avez un niveau commercial entre les deux, vous avez une étape de plus entre votre attaquant et vos données. Si, en revanche, votre base de données se trouve sur le même serveur, l'attaquant a désormais un accès root à vos données et à votre serveur.
  2. Évolutivité. Garder votre serveur Web sans état vous permet de faire évoluer vos serveurs Web horizontalement sans effort. Il est très difficile de mettre à l'échelle horizontalement un serveur de base de données.
  3. Performance. 2 boîtes = 2 fois le processeur, 2 fois la RAM et 2 fois les broches pour l'accès au disque.

Cela étant dit, je peux certainement voir des cas raisonnables où aucun de ces points n'a vraiment d'importance.


27
Mais avec 2 machines, vous avez le double de la probabilité de défaillance matérielle;)
TWith2Sugars

4
@ TWith2Sugars - par opposition à quoi?
Kev

3
Réf. point 1. Si le niveau Web appartient, que voulez-vous ou avez-vous besoin de plus que l'interface API application / base de données? C'est sûrement la partie terminée à ce moment-là de toute façon? Les choses deviennent alors très intéressantes en termes de services requis pour prendre en charge l'infrastructure DMZ, par exemple les services AD ou Microsoft en jeu?
Noelie Dunne

4
@Noelie - Votre niveau Web n'aurait pas accès pour dire, sauvegarder la base de données dans un fichier et ftp ce fichier sur ftp.hackers.com en utilisant xp_cmdshell. Ou supprimez la base de données. Ou modifiez les valeurs de configuration. etc.
Mark Brackett

6
@kirgy - puisque les deux machines sont en parallèle et sont chacune un point de défaillance unique, la fiabilité globale est moindre; ce n'est pas techniquement le double (c'est en fait 1 - (r1 * r2)) mais assez proche pour une grande fiabilité et de petits nœuds .... Dans le cas de 0,01%, ce serait 0,0199%. Mais pour 100 nœuds, ce serait 36,6% au lieu des 100% impliqués par la déclaration de doublement.
Mark Brackett

45

Cela n'a pas vraiment d' importance (vous pouvez facilement exécuter votre site avec le Web / la base de données sur la même machine), c'est juste l'étape la plus simple de la mise à l'échelle.

C'est exactement ce que StackOverflow a fait - en commençant par une seule machine exécutant IIS / SQL Server, puis quand il a commencé à être lourdement chargé, un deuxième serveur a été acheté et le serveur SQL a été déplacé dessus.

Si les performances ne sont pas un problème, ne gaspillez pas d'argent en achetant / en entretenant deux serveurs.


3
Je suis d'accord, cela peut être fait pendant que la charge est faible ... à mesure que la charge augmente, il est facile de les séparer en 2 machines ou plus.
EJ Brennan

4
Je suis entré et j'allais commenter la même chose. Changer de serveur DB est aussi simple que de changer votre chaîne de connexion (dans la plupart des cas).
CitizenBane

Uuh, j'aime ça. Quelqu'un pense au contexte avant de proposer une solution!
demisx le

22

D'autre part, se référant à un autre blog de Scott (Watermasyck, de Telligent) - ils ont constaté que la plupart des utilisateurs pouvaient accélérer les sites Web (en utilisant le serveur communautaire de Telligent), en plaçant la base de données sur la même machine que le site Web. Cependant, dans le cas de leur client, le serveur de base de données et le serveur Web sont généralement les seules applications sur cette machine, et le site Web ne sollicite pas trop la machine. Ensuite, l'efficacité de ne pas avoir à envoyer davantage de données sur le réseau a compensé l'augmentation de la tension.


4
... jusqu'à ce que l'utilisation simultanée augmente et que le serveur de base de données ait besoin de plus de mémoire pour utiliser efficacement les tampons et les caches. Une fois que les serveurs Web / d'applications et de base de données ont besoin de plus de mémoire qu'ils ne peuvent en partager sur un seul boîtier, la pagination et les E / S de disque augmentent et les performances augmentent.
kermatt

@MattK - mais que faire si vous avez énormément de mémoire? Nous avons une application où chaque client a sa propre base de données, de sorte que la base de données et les serveurs Web peuvent évoluer horizontalement très facilement. Étant donné que nous avons plus de mémoire que de disque utilisé (64 Go contre ~ 40 Go), ne serait-il pas préférable pour les performances de tout garder sur la même machine?
Bip bip

1
Si votre jeu de travail tient en mémoire, vous ne verrez peut-être aucun des problèmes de performances que je mentionne. Le plus souvent, les serveurs ont plus de disque que de RAM, mais il semble que dans votre cas, vous avez des bases de données qui tiennent entièrement dans la RAM - tant que les applications sur le serveur partagé n'en consomment pas trop.
kermatt

15

Je pense que le principal facteur serait la performance. Le code du serveur Web / de l'application et SQL Server mettront en cache les données couramment demandées en mémoire et vous tuez les performances de votre cache en les exécutant dans le même espace mémoire.


12
Et si vous avez une petite base de données (ish), mais avec des tonnes de mémoire? Le coût de passage sur le réseau pour chaque appel de base de données, en particulier s'il y en a beaucoup, ne l'emporterait-il pas sur les avantages?
Bip bip

1
@Tom Ritter Bien que les performances soient un problème (selon cette réponse et le point n ° 3 de la réponse de Mark Brackett), je sais que certaines personnes (moi y compris) mettraient probablement l'argent économisé en NE PAS obtenir un serveur DB séparé dans PLUS de CPU / RAM / etc. sur le serveur unique qui l'a remplacé. Cela devrait donc être pris en compte. En ce qui concerne la mémoire séparée, IIS et SQL pourraient être configurés pour tenir compte de leur concurrence sur les ressources. Personnellement, le «kicker» pour moi était le point n ° 1 de Mark ... la sécurité. J'aime l'idée de l'accès limité qu'un serveur Web compromis aurait à un serveur DB séparé .
Dylan - INNO Software

@Tom, vous pouvez toujours diviser l'espace mémoire en deux unités distinctes. Une moitié pour le serveur et une moitié pour la base de données.
Pacerier

15

Tom a raison à ce sujet. D'autres raisons sont que ce n'est pas rentable et qu'il existe des risques de sécurité supplémentaires.

Les serveurs Web ont des exigences matérielles différentes de celles des serveurs de base de données. Les serveurs de base de données s'en tirent mieux avec beaucoup de mémoire et une matrice de disques très rapide, tandis que les serveurs Web n'ont besoin que de suffisamment de mémoire pour mettre en cache les fichiers et les requêtes de base de données fréquentes (selon votre configuration). En ce qui concerne la rentabilité, les deux serveurs ne seront pas nécessairement moins chers, mais le rapport performances / coût devrait être plus élevé car vous n'avez pas à différentes applications en concurrence pour les ressources. Pour cette raison, vous devrez probablement dépenser beaucoup plus pour un serveur qui répond aux deux et offre des performances équivalentes à 2 serveurs spécialisés.

Le problème de sécurité est que si la machine unique est compromise, le serveur Web et la base de données sont vulnérables. Avec deux serveurs, vous avez une certaine marge de manœuvre car le 2ème serveur sera toujours sécurisé (au moins pendant un certain temps).

En outre, il existe certains avantages en termes d'évolutivité, car il se peut que vous n'ayez à gérer que quelques serveurs de base de données utilisés par un ensemble d'applications Web différentes. De cette façon, vous avez moins de travail à faire pour appliquer les mises à niveau ou les correctifs et régler les performances. Je pense qu'il existe des outils de gestion de serveur pour faciliter ces tâches (dans le cas d'une seule machine).


2
Si vous exécutez autre chose que des SP, votre serveur Web a probablement un accès complet aux données de votre base de données de toute façon
George Mauer

Pourquoi n'est-ce pas rentable? Veuillez préciser.
Robert Jeppesen

Robert J'ai développé cela et ajouté quelques commentaires sur l'évolutivité et la maintenance.
Dana the Sane

9

La sécurité est une préoccupation majeure. Idéalement, votre serveur de base de données doit être placé derrière un pare-feu avec uniquement les ports requis pour accéder aux données ouverts. Votre application Web doit se connecter au serveur de base de données avec un compte SQL qui possède juste assez de droits pour que l'application fonctionne et pas plus. Par exemple, vous devez supprimer les droits qui permettent de supprimer des objets et vous ne devriez certainement pas vous connecter en utilisant des comptes tels que «sa».

Dans le cas où vous perdez le serveur Web à cause d'un détournement (c'est-à-dire une élévation complète des privilèges vers les droits d'administrateur), le pire des cas est que la base de données de votre application peut être compromise mais pas l'ensemble du serveur de base de données (comme ce serait le cas si le serveur de base de données et serveur Web étaient la même machine). Si vous avez chiffré vos chaînes de connexion à la base de données et que le pirate n'est pas assez averti pour les déchiffrer, tout ce que vous avez perdu est le serveur Web.


Mais vous sauvegardez la base de données, non? Sinon, vous risqueriez tout autant de le perdre en raison d'une panne matérielle ou d'un bug rarement excité. Une attaque qui tue le serveur Web entraînera à elle seule des temps d'arrêt. Des privilèges suffisants pour ajouter des enregistrements aux tables suffisent à rendre un site inutile.
Daniel Earwicker

Bien sûr, vous sauvegardez la base de données, c'est implicite, où dans mon message ai-je suggéré le contraire.
Kev

1
Oui, mais la conclusion est donc qu'une attaque destinée à faire tomber le site peut le faire en détruisant la configuration du serveur web ou la base de données, et la solution est la même pour les deux: restaurer à partir d'une sauvegarde. La protection spéciale de la base de données est (a) inutile et (b) impossible de toute façon.
Daniel Earwicker

@Earwicker - qu'en est-il de toutes les autres bases de données résidant sur le serveur DB? Tout ce que vous avez perdu est une base de données.
Kev

8
Outre Daniel, vous manquez un point ÉNORME. Il ne s'agit pas d'une sauvegarde de base de données, mais des données compromises. Vos clients accepteraient-ils qu'un "pirate informatique ait volé toutes vos données client et de vente, mais ne vous inquiétez pas, j'ai une sauvegarde." :)
Dylan - INNO Software

9

Un facteur qui n'a pas encore été mentionné est l'équilibrage de charge. Si vous commencez par considérer le serveur Web et la base de données comme des machines distinctes, vous optimisez le nombre d'allers-retours réseau et il devient également plus facile d'ajouter un deuxième serveur Web ou un deuxième moteur de base de données à mesure que les besoins augmentent.


6

Je peux dire par expérience de première main que c'est souvent une bonne idée de placer le serveur Web et la base de données sur différentes machines. Si vous avez une application qui consomme beaucoup de ressources, cela peut facilement provoquer un pic de cycles du processeur sur la machine, ce qui entraîne essentiellement l'arrêt de la machine. Cependant, si votre application a une utilisation limitée de la base de données, ce ne serait probablement pas grave de les faire partager un serveur.


6

Wow, personne n'évoque le fait que si vous achetez réellement un serveur SQL à 5k dollars, vous voudrez peut-être l'utiliser pour plus que votre application Web. Si vous utilisez express, peut-être que vous ne vous en souciez pas. Je vois des serveurs SQL exécuter des bases de données pour 20 à 30 applications, donc les mettre sur le serveur Web ne serait pas intelligent.

Deuxièmement, cela dépend de la destination du serveur. Je travaille pour des sociétés financières et le gouvernement. Nous utilisons donc une approche folle dans le cul consistant à n'utiliser que des sprocs et à limiter les ports du serveur Web à SQL. Donc, si l'application Web est piratée. La seule chose que le pirate peut faire est d'appeler des sprocs car le compte utilisateur sur le serveur Web est verrouillé pour ne voir / appeler que les sprocs de la base de données. Alors maintenant, le pirate doit trouver comment entrer dans la base de données. Si c'est bien sur le serveur Web, c'est facile d'accès.


5

Je suis d'accord avec Daniel Earwicker - la question de sécurité est assez imparfaite.

Si vous avez une configuration de boîte unique avec un serveur Web et uniquement la base de données pour ce serveur Web, si ce serveur Web est compromis, vous perdez à la fois le serveur Web et uniquement la base de données de cette application spécifique.

C'est exactement la même chose que ce qui se passe si vous perdez le serveur Web sur une configuration à 2 serveurs. Vous perdez le serveur Web, et uniquement la base de données pour cette application spécifique.

L'argument selon lequel `` l'intégrité du reste du serveur de base de données est maintenue '' lorsque vous avez une configuration à 2 serveurs n'est pas pertinent, car dans le premier scénario, tous les autres serveurs de base de données relatifs à toutes les autres applications (s'il y en a) restent également inchangés - étant, comme ils le sont, hébergés ailleurs.

De même, à la question posée par Kev «qu'en est-il de toutes les autres bases de données résidant sur le serveur DB? Tout ce que vous avez perdu est une base de données.

  • si vous hébergiez une application et une base de données sur un serveur, vous n'hébergeriez que les bases de données sur ce serveur liées à cette application. Par conséquent, vous ne perdriez aucune base de données supplémentaire dans une configuration de serveur unique par rapport à une configuration de serveur multiple.

En revanche, dans une configuration à 2 serveurs, où l'attaquant avait accès au serveur Web, et par proxy, des droits limités (dans le meilleur des cas) sur le serveur de base de données, ils pourraient mettre en danger les bases de données de toutes les autres applications en portant des requêtes lentes et gourmandes en mémoire ou en maximisant l'espace de stockage disponible sur le serveur de base de données. En séparant les applications en leurs propres préoccupations, tout comme la virtualisation, vous les isolez également à des fins de sécurité de manière positive.


4

Cela dépend de l'application et du but. Lorsque la haute disponibilité et les performances ne sont pas essentielles, il n'est pas mal de ne pas séparer la base de données et le serveur Web. Compte tenu en particulier des gains de performances - si l'application effectue un grand nombre de requêtes de base de données, une quantité considérable de charge réseau peut être supprimée en gardant tout sur le même système, en maintenant les temps de réponse bas.


2

Je pense que c'est parce que les deux machines doivent généralement être optimisées de différentes manières. À part cela, je n'en ai aucune idée, nous exécutons toutes nos applications avec la base de données du serveur sur la même machine - à condition que nous ne soyons pas confrontés au public - mais nous n'avons eu aucun problème.

Je ne peux pas imaginer que trop de gens se soucient du fait qu'une machine soit compromise sur les deux, car l'application Web aura généralement un accès presque illimité aux données, sinon au schéma à l'intérieur de la base de données.

Intéressé par ce que les autres pourraient dire.


1
George, je pense que vous devriez vous référer à la réponse de Mark Brackett. La sécurité de votre serveur Web vis-à-vis de la base de données ne serait PAS la même que si le serveur était séparé. Plus précisément, le "disque local" ne serait pas accessible. De plus, si un seul site Web (parmi tant d'autres) était piraté, il n'aurait probablement compromis l'accès à la base de données de CE SITE (à moins que vous n'utilisiez un utilisateur trop puissant pour cette chaîne de connexion). Il existe d'innombrables autres scénarios, je ne pense tout simplement pas qu'un commentaire ici soit l'endroit pour eux.
Dylan - INNO Software

2

J'ai écouté ce podcast, et c'était amusant, mais l'argument de la sécurité n'avait aucun sens pour moi. Si vous avez compromis le serveur A et que ce serveur peut accéder aux données du serveur B, vous avez instantanément accès aux données du serveur B.


Pas vrai. Vous avez accès à toutes les données ou privilèges de la Box A sur la Box B.Dans une configuration sécurisée, cela signifierait que vous disposez du plus haut niveau d'accès à la base de données que l'application sur la Box A possède. Cependant, vous n'avez pas de privs sur la base de données, ni de racine sur le système d'exploitation de Box B.
Mark Brackett

2
«Vous avez accès à toutes les données ou privilèges que la boîte A avait sur la boîte B» - c'est ce que je voulais dire par «vous avez instantanément accès aux données sur le serveur B». Si le SGBDR était sur la case A et qu'il n'y avait pas de case B, quelle différence cela ferait-il? NB. nous supposons que vous avez déjà piraté la boîte A, de toute façon.
Daniel Earwicker

Dans une configuration à deux boîtes, si vous appliquez le principe du moindre privilège, si la boîte A (web) est compromise, alors le pire qui aurait dû arriver est que vous avez perdu la base de données sur la boîte B et pas plus.
Kev

1
Et sur une configuration à une seule boîte, si cette boîte est compromise, vous avez perdu cette boîte, qui comprend la base de données. Quelle est la différence?
Daniel Earwicker

2
La différence est que sur une configuration à deux boîtiers, si le serveur Web est compromis, tout ce que vous avez perdu est le serveur Web et au pire la base de données. Le reste de l'intégrité du serveur de base de données est préservé.
Kev

2

Les licences de base de données ne sont pas faciles et sont souvent facturées par CPU, donc en séparant vos serveurs Web, vous pouvez réduire le coût de vos licences de base de données.

Par exemple, si vous avez 1 serveur faisant à la fois le Web et la base de données contenant 8 CPU, vous devrez payer pour une licence de 8 cpu. Cependant, si vous avez deux serveurs avec chacun 4 processeurs et exécutez la base de données sur un serveur, vous n'aurez à payer que pour 4 licences de processeur.


Veuillez expliquer en quoi cela représente une économie.
John Saunders

1
John - il dit que pour obtenir des performances équivalentes à 2 machines, vous devez doubler le nombre de cœurs, ce qui doublerait les coûts de licence SQL Server. Pourquoi payer 10 à 20 000 $ de plus pour SQL Server si vous n'obtenez que les mêmes performances que l'utilisation de 2 machines.
Bip bip

seulement vrai si l'utilisation des performances / ressources (par exemple, le processeur) est dominée par les serveurs d'applications et non par le serveur de base de données. si la base de données a besoin de 8 cpus, cela ne fonctionnera pas.
Andreas Dietrich

1

Une préoccupation supplémentaire est que les bases de données aiment prendre toute la mémoire disponible et la garder en réserve pour le moment où elles veulent l'utiliser. Vous pouvez le forcer à limiter la mémoire, mais cela peut considérablement ralentir l'accès aux données.


-1

Dire qu'il y a un réel gain de performances à obtenir en exécutant un serveur de base de données sur un serveur Web est un argument erroné.

Étant donné que les serveurs de base de données acceptent des chaînes de requête et renvoient des ensembles de résultats, les données qui circulent réellement du serveur de données au serveur Web sont relativement petites, mais la puissance requise pour traiter la requête et générer l'ensemble de résultats est relativement importante. Optimiser les performances autour du temps de transfert des données, c'est donc optimiser autour de la mauvaise chose.

En ce qui concerne la sécurité, il y a des avantages à avoir le serveur de données sur un boîtier différent du serveur Web. Avoir une telle configuration n'est pas la fin de toute la sécurité, mais c'est un pas dans la bonne direction.

En ce qui concerne l'évolutivité, il est facile et relativement peu coûteux d'ajouter des serveurs Web et de les mettre en cluster pour gérer l'augmentation du trafic. Il n'est pas si facile et bon marché d'ajouter des serveurs de données et de les regrouper. En outre, les serveurs Web et les serveurs de données ont des besoins matériels différents, de sorte que plusieurs boîtiers contribuent à l'évolutivité.

Si vous commencez petit et que vous n'avez qu'une seule boîte, alors une bonne solution serait d'utiliser des machines virtuelles. L'exécution du serveur Web et du serveur de données dans différentes machines virtuelles sur un hôte vous donne tous les gains de boîtes séparées au prix d'un prix de grande boîte.


1
La question initiale concernait les serveurs d'applications, pas nécessairement les serveurs Web publics face à Internet.
João Bragança

-2

Le système d'exploitation est une autre considération. Bien que votre base de données puisse nécessiter des espaces mémoire plus importants et donc UNIX, votre serveur Web - ou plus précisément votre serveur d'applications puisque vous ne mentionnez que deux niveaux - peut être basé sur .Net et donc nécessiter Windows.


Je n'ai pas voté contre cela, mais "Bien que votre base de données puisse nécessiter des espaces mémoire plus grands et donc UNIX" - Si vous exécutez des fenêtres 64 bits et SQL 64 bits, il y a beaucoup de mémoire avec laquelle jouer.
Kev

Désolé, la mémoire a été conçue comme un exemple de raison pour le déploiement sur des systèmes d'exploitation séparés. D'autres raisons incluent: les performances, la sécurité, les normes / licences d'entreprise, le support des fournisseurs, etc.
Chris Noe

-6

D'accord! Voici le truc, il est plus sûr d'avoir votre serveur DB installé sur une autre machine et votre application sur le serveur Web. Vous connectez ensuite votre application à la base de données avec un lien Web. Merci.


3
pourquoi est-il plus sûr?
Bryan Chen
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.