Est-il utile d'utiliser un serveur MySQL séparé?

Une question similaire s'est transformée en soupe d'opinion ici : alors peut-être qu'il n'y a pas de «bonne» réponse à cela, mais je veux vérifier avec la communauté.

Mon client est sur le point de lancer une publicité télévisée. Ils attendent du trafic dans le département à 7 chiffres au cours du mois à venir. Mon travail consiste à m'assurer que le serveur ne tombe pas.

Ma question: vaut-il la peine de diviser la base de données MySQL sur un serveur séparé, qui ne sert que la base de données. Je veux ensuite avoir plusieurs serveurs qui contiennent la base de code et servent apache, en interface avec la boîte de base de données. Tous seront des conteneurs virtuels.

Je ne pense PAS que je souhaite utiliser plusieurs serveurs de base de données - il semble que cela introduira une complexité inutile et des erreurs / goulots d'étranglement potentiels.

Ai-je tort? Accueillerait volontiers quelques avis d'expérience à ce sujet Merci.

Nous avons utilisé un serveur MySQL distinct dans plusieurs cas où les magasins étaient confrontés à un trafic élevé. Il y a quelques avantages

1. Les serveurs de base de données dédiés peuvent être modifiés en fonction des besoins spécifiques de MySQL, qui sont différents d'un serveur Web
2. Il est facile d'ajouter un deuxième serveur de base de données (à charge équilibrée) au cluster en cas de besoin
3. Lorsque votre base de données tombe en panne, elle ne plante pas le frontend, vous pouvez donc afficher une page d'avertissement ou d'erreur décente.

Lorsque Magento est correctement mis en cache avec Varnish ou toute autre extension FPC, le goulot d'étranglement principal sera la base de données de ce que j'ai vécu. La puissance réelle sera requise pour votre base de données. De cette façon, vous pouvez commencer avec un serveur Web relativement petit et investir davantage dans le serveur de base de données.

Sécurité:

En plus de la réponse de Sander, j'ajouterais qu'à certains niveaux de conformité PCI, c'est une exigence :

Serveurs Web et de base de données distincts CHD est stocké en masse dans la base de données, ce qui en fait une cible de grande valeur pour un attaquant. Un serveur de base de données séparé signifie que l'accès peut être strictement contrôlé (exposition limitée). Requis par la section 1 du PCI DSS.

Source: http://www.focusonpci.com/site/index.php/PCI-101/technical-requirements.html

En séparant les tâches Web et de base de données, vous limitez votre exposition. En règle générale, votre base de données se trouve dans un segment privé de votre réseau et inaccessible publiquement.

Une connexion VPN statique est également suggérée, en PCI, entre votre web / db et la détection d'intrusion est fortement suggérée sur votre équipement réseau. En cas de compromis, la base de données sera isolée et la connexion VPN interrompue de telle sorte que, même si votre application et votre clé de chiffrement sont désormais compromises, l'accès au magasin de données a été verrouillé et inaccessible.

Haute disponibilité / reprise après sinistre:

Sander est sur le point ici. Allez le voter. J'ajouterais que même dans le cas d'une petite tâche de maintenance comme la sauvegarde d'un système de fichiers ou un vidage de base de données, votre base de données sera, au mieux, limitée en lecture seule pendant un certain temps. Dans des cas extrêmes, j'ai vu des délais d'attente de verrouillage et des files d'attente de processus se remplir que toutes les connexions disponibles sont mises en file d'attente ou abandonnées. Le site "tombe en panne", effectivement.

Vous pouvez atténuer cela en séparant votre base de données et en planifiant votre serveur Web pour placer le site en mode maintenance pendant ces fenêtres de sauvegarde sans aucune conséquence pour le système de fichiers du serveur Web.

Je voudrais ajouter mon centime. Lorsqu'un environnement de production est conçu, pensez à avoir une application et une base de données sur différents serveurs en règle générale. Il donnera les avantages suivants directement ou directement:

• De meilleures performances globales (votre application a plus de ressources)
• Système plus fiable (le crash ou le calage de l'un peut ne pas affecter l'autre. Bien sûr, l'application peut ne pas fonctionner selon les besoins, mais un composant)
• Ressources dédiées selon les besoins (vous pouvez allouer CPU / RAM / Stockage à chaque serveur selon les besoins)
• Meilleure sécurité (uniquement si vous autorisez la connexion à la base de données en dehors de votre machine, mais cela peut être atténué avec des restrictions de pare-feu basées sur l'adresse IP ou des approches similaires)
• Doit l'exigence pour atteindre hautement disponible (HA)
• Systèmes Facile à répondre aux besoins de reprise après sinistre (DR)
• À mon avis, seuls les inconvénients sont plus de coûts et plus de serveurs à gérer.

Merci et Reagrd, Imran Javed Zia