1 votes

RDS, scalr avec EC2 ou xeround pour une base de données de 40GB

Nous préparons actuellement la migration d'un site web à fort trafic vers le cloud.

Nous pensons utiliser scalr pour nous aider à gérer l'ensemble de la configuration, d'autant plus que nous n'avons pas d'expérience avec amazon.

Nous ne savons pas si nous devrions utiliser la fonctionnalité MySQL de Scalr qui repose sur des instances EC2 soutenues par EBS ou si nous devrions utiliser RDS ou même xeround et bénéficier d'une maintenance et d'une gestion beaucoup plus faciles.

Notre ensemble de données est d'environ 40 Go et nous consommons une bande passante de 4 000 Go par mois entre le serveur d'application et le serveur de base de données.

Avez-vous des expériences sur des installations similaires ?

Merci d'avance

2voto

Ed Ball Points 1341

Je peux vous dire, d'après mon expérience, que j'ai une grande base de données, mais beaucoup plus grande que la vôtre, d'environ 90 gigaoctets.

Nous avons opté pour RDS et au moins 3 à 4 fois par jour, nous obtenions une latence horrible sur les requêtes. Par exemple, des requêtes qui prenaient une seconde duraient 10 à 20 secondes. Nous sommes passés à leur plus grande instance soutenue par EBS raided et les performances étaient à peu près les mêmes, mais nous n'avons pas eu ces pics de latence vraiment terribles.

-2voto

Parth Points 11

Le passage à l'informatique dématérialisée est en effet une très bonne option - La partie la plus difficile de l'évolution de votre application dématérialisée est l'évolution de la base de données. Ne vous méprenez pas, MySQL dispose de solutions de basculement (combien de temps cela prend-il ?), qui peuvent prendre en charge plusieurs répliques pour gérer les lectures. Scalr et RDS sont des options très pertinentes si vous connaissez leurs limites Avec Scalr - ils vont faire évoluer votre base de données en provisionnant des bases de données esclaves et maîtres, et en configurant la réplication des données. Bien que l'auto-provisionnement facilite les choses et que la réplication offre une certaine solution, gardez à l'esprit que l'ajout de réplications en lecture ne résoudra pas les écritures OLTP , pas plus qu'il ne gérera une véritable élasticité linéaire à la demande. Chaque fois que vous ajoutez une réplique de lecture, il s'agira probablement d'un événement de service.
Pour l'AH, Scalr utilise EBS. Si le dernier temps d'arrêt très long d'AWS EBS est une indication, assurez-vous que vos données/stockage sont également HA

Les solutions évolutives doivent être linéaires et élastiques (elles peuvent être modifiées à la demande, sans temps d'arrêt). Les applications en nuage ont besoin d'une véritable HA native - plusieurs répliques effectuant des opérations de lecture et d'écriture en permanence, et non de basculement. RDS prouvera la même configuration "MySQL préconfigurée" et aura donc les mêmes limitations. Enfin, assurez-vous qu'il n'y a pas de point de défaillance unique et quel est l'impact sur vos développeurs à chaque fois que vous apportez une modification à l'application. Chez Xeround, notre objectif était de répondre à ces questions. Nos gènes de qualité Telco et notre solution développée dès le premier jour comme une solution virtuelle pour des opérations en nuage nous permettent d'offrir une DB en nuage à la demande, élastique, super évolutive et hautement disponible, " sans souci ".
Nous avons mené une phase bêta d'un an avec des milliers d'utilisateurs, dont beaucoup sont exactement comme vous.
Nous sommes maintenant en GA - veuillez vous connecter pour un Essai gratuit de 30 (sans carte de crédit) et vérifiez par vous-même.

Razi Sharir (Xeround).

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X