Questions infra derrière Public Cloud et demande retour stabilité

- Disques SSD : Normalement c'est du local en raid. Il faudrait vérifier avec le support OVH.

- En cas de crash de l'hôte normalement la VM est migrée sur un autre hôte. Je dis bien normalement.
ça peut arriver (c'est d'ailleurs la norme) que la VM soit down le temps de remonter l'host, voir au mieux d'être migré sur un autre host.
Mais j'ai eu le cas d'une migration "à chaud", ça m'a corrompu plusieurs bases de données... Il a fallu redémarrer en rescue, faire un fsck, certaines tables ont pu être réparées, d'autre j'ai du restaurer des sauvegardes...

- Est ce que l'infra est stable : dans les grandes lignes oui. Bon ça reste du mutualisé, par conséquent ça ne vaut pas un dédié...
Il faut savoir que le disque additionnel est sur du CEPH, donc perfs assez médiocres et instables. Et les disques sont bridés également, en bande passante et en iops.

Perso je considère que sur des services critiques il faut prendre des dédiés.
Même si c'est pour monter ses propres machines virtuelles sur ses dédiés.
OVH a une excellente offre sur dédié, il faut en profiter. Mais ça implique de mettre en place sa propre archi...

De mon côté je ne préconise le Cloud que dans les situations suivantes :
- Besoins faibles, par conséquent un dédié serait trop puissant et inutile.
- Des frontaux web (par exemple), scalable, redondants.

Pour des services critiques (perfs, disponibilités, liberté de configuration) il faut (selon moi) partir sur du dédié, et monter son infra sois même. Histoire d'avoir le contrôle sur tout l'environnement.
Et de toute façon quand on voit le prix des Public Cloud, du genre le C2-30 à 125€ HT / mois ! A ce prix là on a un infra 2 de base qui doit être 2x + performant et on est tout seul dessus !

Quand à la pseudo disponibilité des dédiés, j'ai un meilleur taux de disponibilité sur mes dédiés que sur les clouds... Les pannes hardwares sont rares et généralement gérable. Et la pseudo disponibilité du Cloud ne vaut pas le surcoût entrainé par les offres Cloud... Sans parler de la différence de performance...

[EDIT]
Je rajouterai quand même que je suis un vieux monsieur qui n'a pas du tout fait le "saut" technologique de Kubernete, docker et autres nouvelles techno.
Moi j'aime mon bon vieux dédié que je configure comme je veux, qui fonctionne comme je veux et sur lequel je contrôle ce qui se passe.
[/EDIT]

Bonjour,

D'abord pour les questions.

1. SSD locaux et RAID: oui il y a du RAID partout. Si on perd un disque, on le change, on ne perd pas les donnees des instances. Pour faire ca, on eteind pas sauvagement le host, on le vide d'abord (on live-migra a chaud les instances, c'est transparent dans presque tous les cas, mais on sait que ca peut affecter les perfs des BDD)
2. En cas de crash de l'hote: il faut attendre que l'hote reviennent (jy reviens plus bas)
3. Infra stable: oui.


Concernant le point 2. Je pense qu'il ne faut pas comparer PCC (private cloud / vmware chez OVH) et PCI (Public Cloud / OpenStack chez OVH).

* Sur un PCC, on a tendence a chérir ses instances, a les bichonner, a les considérer unique.
* Au contraire, sur un PCI, on doit considerer ses instances comme faisant partie d'un troupeau. A vous de repartir vos instances pour faire tourner votre service. en gardant toujours en tete qu'une instance peut etre defaillante.

C'est le paradigme du "Pet VS Cattle".

Chez OVH, on sait que nos clients aiment cherir leurs instances, dont on fait tout pour que les instances sur PCI aient le meilleur uptime.
Neamoins, prendre en consideration ce paradigme de Pet VS Cattle est toujours une bonne idee.


Par exemple, un des conseils que je peux donner, c'est d'utiliser les server-group (https://docs.openstack.org/python-openstackclient/latest/cli/command-objects/server-group.html) pour demarrer vos instances sur 2 hosts differents (avec une regle d'anti-affinite).

Cela permet de s'assurer que si une instance1 sur un hostA a un probleme, alors l'instance2 sur un hostB continuera de tourner.

Merci de ton retour Sich :)

Très bonne remarque sur le groupe anti affinité.
Pas forcément mis en avant dans le manager car il faut passer par l'API.

Mais effectivement, c'est impératif d'utiliser cela quand on a une infra de plusieurs serveurs.

Bonjour Arnaud et merci de tes retours.

SSD locaux et RAID: oui il y a du RAID partout. Si on perd un disque, on le change, on ne perd pas les donnees des instances. Pour faire ca, on eteind pas sauvagement le host, on le vide d'abord (on live-migra a chaud les instances, c'est transparent dans presque tous les cas, mais on sait que ca peut affecter les perfs des BDD)

Donc si je comprends bien, un hôte contient n VMs et deux disques physiques SSD en RAID sur lesquels sont alloués les disques vitruels des VMs ? Du coup, la migration live consiste à déplacer les données sur un autre hôte, ce qui peut prendre un certain temps en fonction de la taille des disques.

C'est le paradigme du "Pet VS Cattle".

Ok , c'est bon à savoir. Il faut juste éviter les SPOF mais c'est déjà ce qu'on fait pour les projets critiques. Après c'est vrai que l'uptime des PCC est vraiment bon, du coup il faudra juste qu'on se prépare mentalement à ce que ça tombe peut-être plus régulièrement.

Cela permet de s'assurer que si une instance1 sur un hostA a un probleme, alors l'instance2 sur un hostB continuera de tourner.

Je pensais déployer les VMs dans différentes régions pour contrer ce problème. C'est pas comme ça qu'il faut faire ?

Une autre question liée : est-ce que HEAT est toujours en BETA ? Si non, vous recommandez plutôt ça ou TerraForm ?

Merci

[quote]Je pensais déployer les VMs dans différentes régions pour contrer ce problème.[/quote]

Alors déployer les vms sur plusieurs régions attention, tout dépend de la config...
Par exemple un cluster MySQL aura des perfs déplorables car en cas d'enregistrement il doit valider sur toutes les nodes, et l'éloignement impacte tout de même les perfs.

Il vaut mieux être sur le même DC mais sur plusieurs hosts différents via les groupes anti affinité.

[quote]l faudra juste qu'on se prépare mentalement à ce que ça tombe peut-être plus régulièrement[/quote]

Heu zen, c'est stable quand même. Les plantages restent rare.
Par contre il peut y avoir des variations de perfs en fonction de la charge de l'Host. Sur le public cloud les ressources sont garanties, mais bon, on arrive quand même à ressentir des variations par moment.

Je rejoints la réponse d'Arnaud plus haut quand il dit qu'il faut construire une infra redontante. Du genre un cluster MySQL sur 3 vms, puis des frontaux web derrière un LB. Dans ces conditions le Public Cloud c'est très bien.

Reste le serveur de stockage, un NAS HA éventuellement, mais pas compatible VRack...

Si on arrive à avoir une infra où l'on peut "perdre" ponctuellement une VM dans ce cas le public cloud c'est très bien car très souple d'utilisation.

Par exemple un cluster MySQL aura des perfs déplorables car en cas d'enregistrement il doit valider sur toutes les nodes, et l'éloignement impacte tout de même les perfs.

Oui, je pensais plutôt aux frontaux.

Si on arrive à avoir une infra où l'on peut "perdre" ponctuellement une VM dans ce cas le public cloud c'est très bien car très souple d'utilisation.

Oui, c'est comme ça que je l'envisage. Pour ce qui est des perfs, je suis pas trop inquiet vu qu'on peut rajouter des vms si nécessaire. Et si vraiment c'est pourri pour le SQL, je les passerais en effet sur des dédiés. L'interconnexion avec le Vrack devrait faciliter les choses.

Je vais monter une infra pour tester tout ça. J'en profiterai pour tester les perfs du cloud database au passage.

Dommage juste qu'il n'y ait pas le composant router de neutron, ça simplifierait encore un peu plus les choses !

Oui heat est encore en beta.
On offre aussi l'option router en beta. Voir ici : https://labs.ovh.com/public-cloud-l3-services

Deployer sur plusieurs regions c'est aussi une bonne idee pour encore plus de separation en cas de pannes, mais comme dit par Sich, il faut faire attention que le software le supporte (un cluster de DB ou un cluster de rabbitmq par exemple n'aime pas trop la latence...)

Oui heat est encore en beta.
On offre aussi l'option router en beta. Voir ici : https://labs.ovh.com/public-cloud-l3-services

Ok. Vu que c'est pour de la prod, ça m'ira pas.

Merci encore des retours.

Ça veut dire quoi "anti-affinité"?

ça permet de créer par exemple 3 VMs et de s'assurer qu'elles ne seront pas sur le même serveur hôte.

Si l'hôte tombe en panne cela n'impacte pas toute l'infra.

Ok, merci.

les disques sont bridés également, en bande passante et en iops.

Hello, pour info on ne limite que les IO/s.
La bande passante est donc égale à la taille du bloc * limite en IO/s

Pour les performances, on sait que ça ne répond pas à l'ensemble des besoins. On travaille dessus ;)

Hello, pour info on ne limite que les IO/s.
La bande passante est donc égale à la taille du bloc * limite en IO/s

Bonjour Etienne,

pour pouvoir faire une petite comparaison, tu sais à combien sont les IO/s sur le PCC ?

Merci

Du tout, mais je pose la question à un collègue.

La tarification des I/O ne dépend pas du type de serveur qui les utilise mais uniquement du type d'I/O non? Par exemple ce mois-ci on m'a fait payer du trafic entre un Object Storage et un PCC, c'était le tarif de l'Object Storage annoncé, que ce soit un PCC qui l'utilise ou autre chose.

Ça dépend de la taille du datastore, au max (13TB) on tourne autour de 15k io/s, 700 MB/s.

On applique pas de limites software contrairement aux disques PCI.

La tarification des I/O ne dépend pas du type de serveur qui les utilise mais uniquement du type d'I/O non? Par exemple ce mois-ci on m'a fait payer du trafic entre un Object Storage et un PCC, c'était le tarif de l'Object Storage annoncé, que ce soit un PCC qui l'utilise ou autre chose.

Je ne suis pas certain de comprendre, on facture toujours le traffic sur l'object storage.

on facture toujours le traffic sur l'object storage

Oui, que ce soit un Publc Cloud ou un VPS qui l'utilise, le tarif ne change pas.

Ok merci de l'info.

Encore une petite chose. Existe-t-il des graphiques de l'utilisation des ressources des VM sous Openstack ? Du type de ce que vous faites pour les dédiés ou vscope sur le PCC ?
Si c'est pas le cas, qu'est-ce qui est le plus utilisé pour créer un tableau de bord dans le genre ?

Merci encore :)

On ne donne pas d'équivalent, mais tu peux pousser et visualiser tes metrics via https://www.ovh.com/fr/data-platforms/metrics/

Ça dépend de la taille du datastore, au max (13TB) on tourne autour de 15k io/s, 700 MB/s.

On applique pas de limites software contrairement aux disques PCI.

Hi,

C'est technique la limitation des disques additionnels sur PCI ?
3k iops et 4TB, c'est un peu juste pour certains besoins :-)

Pour les IO/s on proposera peut être à l'avenir un nombre d'IOPS/GB.
Pour la taille c'est lié à une question pratique pour notre gestion des clusters, on peut parfois être amené à migrer des disques additionnels vers un autre cluster. Si le disque est trop gros ca pose parfois des problèmes.

En attendant tu peux très bien faire un LVM/raid avec tes disques pour améliorer les performances ou la taille du volume. Cependant, attention à l'impact CPU que ça va te provoquer.

Pour les IO/s on proposera peut être à l'avenir un nombre d'IOPS/GB.

Une offre ≥ 15k ça serait top.

Pour la taille c'est lié à une question pratique pour notre gestion des clusters, on peut parfois être amené à migrer des disques additionnels vers un autre cluster. Si le disque est trop gros ca pose parfois des problèmes.

Contrainte technique PCI@openstack ou c'est pareil sur PCC@vmware ?

En attendant tu peux très bien faire un LVM/raid avec tes disques pour améliorer les performances ou la taille du volume. Cependant, attention à l'impact CPU que ça va te provoquer.

Ah merci je n'y aurai pas pensé !
Toutefois pour ma compréhension en quoi faire un LVM/raid améliorait les performances ? _(un élément doit m'échapper ;-))_
Dernier point le facteur de réplicationx3 du "block storage" c'est intra ou inter DC ? _(GRA, RBX, SGB)_

Merci encore @EtienneM pour ces éclaircissements !

_NB : désolé à l'auteur pour cette "pollution" de topic !_

Contrainte technique PCI@openstack ou c'est pareil sur PCC@vmware ?

C'est une contrainte PCI/Ceph, il me semble que les datastore pcc sont dédiés.

Toutefois pour ma compréhension en quoi faire un LVM/raid améliorait les performances ? (un élément doit m'échapper ;-))

Tu peux faire un raid 0 pour améliorer les performances (répartir les données et donc les lectures/écritures) le stockage étant répliqué tu n'as pas plus de risques de pertes de données qu'avec un volume simple.

Dernier point le facteur de réplicationx3 du "block storage" c'est intra ou inter DC ? (GRA, RBX, SGB)

Intra, pour des questions de performances liées à la latence, on ne pourrait pas faire de cluster sur plusieurs DC. En revanche les données sont toujours réparties entre trois racks.