Dimensionnement serveur MySQL

Perso sur les projets gourmands je prends du dédié.
Les SP-32 fonctionnent à merveille avec des disques NVMe...

Les offres R2 n'ont pas un CPU assez puissant, il faut un bon CPU sur MySQL surtout avec une grosse bdd.
Côté RAM il en faut pas mal vu la taille de la bdd, si le serveur ne sert qu'à MySQL 15Go ça devrait le faire néanmoins.

Le cloud database je ne sais pas ce que ça vaut côté perf.

Dans tous les cas la RAM est tjrs utile. Une telle boutique doit faire pas mal de ventes quand même, mettre 50€ de plus par mois ne devrait pas être un soucis..

> Une telle boutique doit faire pas mal de ventes quand même, mettre 50€ de plus par mois ne devrait pas être un soucis..

Gros catalogue ne veut pas forcément dire beaucoup de vente :D
Actuellement on tourne au alentours de 30 / jour, peut monter jusqu'à 100.

> Les SP-32 fonctionnent à merveille avec des disques NVMe...

Juste pour du MySQL?

L’intérêt de l'offre Cloud Databases est que je ne m'occupe de rien et il y a aussi une Haute disponibilité.

Si tu prends un SP-32 tu mets tout le site dessus.

Pour le cloud database j'ai presque envie de dire, bah test tu verras bien ?
Me semble que ça ne coûte pas une fortune...
Mais je n'ai jamais testé, aucun retour d'expérience là dessus.

Pour héberger le SQL en Cloud quid du C2-7 si il ne fait que SQL ? Le C2-15 est trop cher, autant prendre un SP-32 et tt mettre dessus.

un collègue de chan, public cloud, serveur HS depuis hier soir.

le support cet AM: ping ok, ça marche, redémarrez ! (j'étais en rescue pour regarder les logs)
reboot KO, serveur dhcp down, visible dans les logs pourtant!

dans les travaux:

> We have some trooble on network since 06/11 22h CET
Issue is identify. There issue with dhcp server on host and your instance loose dhcp lease on instance.

plus 18h après début incident, toujours pas rétabli...

Oui dans ces conditions il vaut mieux un bon vieux dédié...

c'est fou, Ovh annonce https://www.ovh.com/fr/public-cloud/ 99.999% de sla sur son public cloud...

et ça correspond à 5mn de downtime par an! https://uptime.is/99.999

là on frôle les 22heures, de quoi faire plaisir à @EmmanuelP2

Bonjour,

attention a la SLA chez OVH, elle est au mois et c'est leur robots qui doivent constater (ou le support…) le down sinon elle est pas appliqué (et en plus si on peu la désactiver dans le manager…).
Et après même si elle est appliqué c'est maximum 100% du prix du serveur.

Après pour le "cloud database" mis à part le fait que c'est OVH qui manage la partie hard/soft (avec les conséquences du coup) à mon avis y a peut d’intérêt sur une grosse BDD surtout si il faut attendre le support en cas de plantage de l'instance (et en plus la latence sera surement mauvaise, passage par le réseau publique oblige).

Cordialement, janus57

http://travaux.ovh.net/?do=details&id=35140
la date de constat n'est pas indiqué, mais le comment de 9h35 ce matin est indicatif

ça veut dire quoi: au mois?
au mois c'est 26s de downtime une telle sla...

Bonjour,

et pourtant c'est bien ça dans le contrat :
[img]https://i.imgur.com/kAsB4l2.png[/img]
Par contre ils sont malin vu que c'est à partir de l'ouverture de l'incident que cela commence.
Du coup théoriquement parlant la SLA (dans ce cas précis) démarre le 06/11/2018 @ 22h CET.

Aussi sur les indemnités d'après le contrat c'est pas fou non plus…
[img]https://i.imgur.com/ssvd8Xb.png[/img]

Du coup là même si un dédié est "overkill" cela pourrais éventuellement permettre de procéder différemment comme passer par la case virtualisation (on isole la VM web de la VM SQL et on priorise la VM SQL, et pour faire les sauvegarde pas de prise de tête car on sauvegarde la VM voir d'autres possibilités).

Cordialement, janus57

mouais, pure escroquerie et/ou inconsciente proche de la débilité profonde

sûr que les risques financiers limités au mois sont du foutage de gueule quand certains client pensent être à l'abri en prenant du managé et n'imaginent même pas une journée d'indisponibilité.

et là y'a plus d'argument valable comme *c'est du pas cher, pas de se services*.

tout ça pour un serveur dhcp.

Bonjour,

plus de 24 heures de panne ! J'ai une formation qui commence dans 2 heures et mes supports sont inaccessibles. Pour les autres sites hébergés sur cette instance, je vais avoir du mal à expliquer à mes clients que le changement récent du serveur est pertinent dans ces conditions.

> Si tu prends un SP-32 tu mets tout le site dessus.

L’intérêt pour moi de partir sur du Public Cloud était la sécurité de pouvoir relancé une machine à partir d'un snapshot rapidement s'il y a un problème. Là avec un dédié compliqué...

Je n'ai pas non plus une connaissance de malade en sysadmin.


@janus57, ok je prends note, il vaut mieux partir sur une Instance ou dédié donc pour avoir de meilleur performance (peut-être avec un vRack du coup?)

Bonjour,

@janus57, ok je prends note, il vaut mieux partir sur une Instance ou dédié donc pour avoir de meilleur performance (peut-être avec un vRack du coup?)

le vRack est utile si vous souhaitez à court terme agrandir votre infra ou "l'exploser" en plusieurs serveurs.
Exemple : faire un cluster MariaDB avec des instances sandbox (S1-8 + anti-afinity) et transférer la partie web sur un Public cloud C2-7
Après dans cette exemple c'est la partie web qui est pas redondée et on est à 10€ d'un SP-32 avec du NVMe.
Et dans les 2 cas prévoir un backup externe (hors OVH ?).

Cordialement, janus57

@janus57, je pensais partir sur ça



Si mon VPS d'email tombe pendant quelques heures ce n'est pas un problème pour nous.

Pour ce qui est de la redondance, je pensais faire des snapshots régulier des 2 serveurs si problème, redéployer une sauvegarde via l'API OpenStack avec transfert de l'IPFO.

Puis dans un second temps si cela fonctionne bien, partir sur une "vraie" infra avec effectivement un cluster pour chaque service + IPLB.

Avec le temps on se rends compte que tout le coût de maintenance de tout ça rends la solution peu pratique... Il vaut mieux avoir un bon serveur stable qui risque éventuellement de tomber en panne 1x tous les 2 ans qu'avoir toute une infra sur du public cloud qui ne sera peut être pas aussi stable. Car le cloud reste du mutualisé et parce que la complexité de l'infra rends l'administration de tout ça plus pénible et augmente les risques de problèmes.

Perso sauf besoin vital de haute disponibilité je reste sur des solutions simples, qui au final s'avère répondre parfaitement aux besoins dans un budget raisonnable sans prise de tête au niveau gestion.

Le tout avec des sauvegardes quotidienne et un script maison d'installation serveur qui me permet de remonter un serveur en 1H environ (sans remise en ligne des backups). Le backup étant fait sur un autre dédié dans un autre DC.

Il faut bien comprendre que + une solution est complexe, plus il y'a des risques de complications et + il va falloir passer du temps à surveiller / maintenir.

Perso sur des projets importants les publics clouds sont utilisés uniquement sur des frontaux web facturé à l'heure que je peux ajouter / supprimer rapidement. Le "core" de l'infra elle restant sur du dédié.
Typiquement pour un client avec des gros besoins 1 dédié pour le web, 1 dédié pour les bdd et des frontaux web en public cloud en cas de pic d'activité.

J'ai quelques VPS pour des clients, mais ils sont sur mes propres serveurs Hosts que je peux gérer moi même.

Il me reste encore quelques clients avec des public cloud, généralement pour des projets intermédiaires (trop gros pour un petit vps, trop petit pour un dédié). Mais les perfs restent moyenne je trouve.

Merci pour ce retour.

Je pense que nous sommes entre 2. VPS trop petit maintenant et un (deux?) dédié trop gros niveau budget.

C'est compliqué :D

Dans ce cas perso je recommande de rester sur des CPU à + de 3Ghz.
Eventuellement séparer l'instance avec le sgbd et une instance avec le serveur web.
Des disques locaux (mais toutes les instances sont en disques locaux maintenant).
Et voir si ça tourne.

Au moins on reste sur une solution simple. Pas de cluster, pas de réplication mysql avec remontée automatique du 2° serveur en master etc...

A partir de là voir comment ça se comporte. Même pourquoi pas partir sur 2 C2-7 et upgrader si nécessaire. Ou des B2-7 si le budget est vraiment trop limité.

Mais par exemple avec 2 C2-7 on est déjà à 64€ HT / mois.
Un SP-32 c'est 80€ HT / mois (avec disques nvme).
Ce qui fait à peine 16€ de + par mois pour une différence de perfs réellement énorme.

La solution est pertinente (question coût) avec 2 B2-7. Mais la différence de CPU se fera sentir.

Bonjour,

je reviens vers vous après plus de 60 jours d'uptime, mon C2-7 dédié à mon MySQL fonctionne parfaitement bien. Je vais maintenant prendre une 2ème instance pour le front web.

Merci pour ce retour :)
(comme quoi ça marche aussi parfois)