Un des avantages **escontés** d'une offre OpenStack / public cloud est l'adaptation des performances (et du prix) aux besoins réels.
Cette évolutivité fonctionne actuellement... dans un seul sens : Nous pouvons certes créer des s1-2 et les mettre à jour vers des s1-4 ou b2 mais **JAMAIS** en sens inverse (à l'exception du cas particulier "b2-flex")
Nous comprenons cette restriction due aux tailles de disque différentes. Nous aimerions vivement pouvoir créer des **s1-2, s1-4, ... dotées de 50GB de disque** afin de pouvoir les upgrader vers du b2-7 ou r2-30 **MAIS aussi les downgrader** aussi aisément.
J'ai sollicité le support par le passé concernant le fait que des root-volumes (même "externals") ne pouvaient être détachés (même d'une instance stoppées) empêchant donc le contournement du problème. https://community.ovhcloud.com/community/fr/detacher-un-volume-persistent-bootable?id=community_question&sys_id=58f2b98c355a82d0f078b41a47e1f050
(Ce problème, distinct, est tout autant dommageable)
**La résolution de ce problème serait pourtant triviale de la part d'OVH !**
Il suffirait de nous doter de templates S1-* dotés de 50GB de disque. Ceci n'aurait aucun coût, n'implique pas de régression et ne risque nullement d'affecter les clients existants.
Permettez-nous désormais d'attendre une réponse plus concrète à ce problème récurrent et fondamental lorsqu'on parle évolutivité. (Quand on ajoute le fait que des instances stoppées continuent d'être facturées sauf à être supprimées, on se rend compte que des progrès reste à faire à ce sujet)
J'ai déjà sollicité le support de multiple fois sans recevoir de réponse autre que _"transféré à R&D"_.
(qui est la manière polie d'OVH de répondre que "rien de concret ne sera fait")
J'espère me tromper, mais cette absence de réponse depuis des mois, me fait craindre d'y voir une mesquinerie commerciale consistant à bloquer les utilisateurs avec des ressources plus importantes que nécessaire sous peine de devoir réinstaller leur OS.
Autre situation identique :
https://community.ovhcloud.com/community/fr/basculer-une-offre-public-cloud-general-purpose-b2-7-vers-une-offre-sandbox?id=community_question&sys_id=4d9ea58c859e06d01e111c5c94ac5bee
Downgrader une instance (ex B2 vers S1)
Related questions
- Dimensionnement serveur MySQL
46235 
07.11.2018 12:32
- [RESOLU] Connexion impossible en SSH
38795 05.06.2019 20:05
- Bonjour, Je n'est reçus aucun mot de passe root lors de mon achat!
34016 05.02.2018 20:47
- Gitlab private docker registry
33889 16.03.2018 13:05
- Ssh connection timed out port 22
33109 11.12.2019 08:21
- Configuration IP failover avec netplan (Ubuntu 17.10)
32577 12.01.2018 23:23
- Problème connexion ssh
32320 04.02.2018 09:46
- IP Failover sur Debian 9
31878 18.11.2016 20:40
- Instance Public Cloud en "error"
29726 15.12.2025 10:04
- Connexion OpenStack Swift Object Storage
25540 11.04.2019 10:09
Bonjour,
attention il y a aussi une différence de ressources entre les instances sandbox (shared) et les autres (dedicated).
Du coup contractuellement et techniquement ça doit être un poil plus complexe car si l'instance d=se fait downgrade vers un sandbox ils doivent aussi vous changer d'host.
Cordialement, janus57
Contractuellement, je ne crois que ce soit un problème. Techniquement, je ne suis pas non plus certain que cela doive nécessairement impliquer un _changement d'host_.
Mais si tel était le cas, je pense que la fonctionnalité le vaudrait largement.
Si cela s'avérait véritablement impossible, il faudrait non seulement que OVH le dise, mais alors il s'agirait de se décider à aborder sérieusement le problème fondamental du détachement de root-volume:
https://blueprints.launchpad.net/nova/+spec/detach-boot-volume
Auquel cas, les admins prévoyant créerait leur root sur un volume détachable et réatachable à une autre instance et l'on retrouverait la possibilité d'upgrade/downgrade.
J'aurais du mal à croire qu'OVH n'ait pas la possibilité de contribuer efficacement à de telles fonctionnalités d'OpenStack.
Bonjour,
vu que d'un côté on a une instances avec des ressources garantie (Cf : CGV/CGU) et de l'autre non garantie contractuellement il faut quand même que le clients valide qu'il a connaissance que le downgrade entraine la perte de la garantie des ressources.
Et techniquement les instances avec ressources garantie ne se trouvent (normalement) pas mélangé avec des instances ou les ressources sont partagé (dans la liste des travaux cela se constate vite quand un host est down et que cela down 50 instances c'est du partagé).
Donc effectivement techniquement parlant cela n'est pas réellement impossible mais comme souvent il n'y a pas que la technique qui compte mais tout ce qui tourne autours (comme la R&D pour le process automatique).
Note : à l'origine les instances sandbox avais les même config que les VPS mais avec les avantages lié à la partie public cloud (ip-fo/vrack/snapshot et d'autres).
Cordialement, janus57
Comme le dit @janus57 les offres Sx sont à part dans la gamme public cloud.
Ces instances n'ont pas de ressources garanties et commercialement OVH n'a probablement pas envie que vous passiez facilement de la gamme public cloud "standard" à la gamme sandbox...
> OVH n'a probablement pas envie que vous passiez facilement de la gamme public cloud "standard" à la gamme sandbox...
Ce que j'appelais plus haut _"mesquinerie commerciale"_ (... si cela s'avérait juste).
Quoiqu'il en soit, des s1-2 et s1-4 dotées de 50GB permettraient déjà des bascules indistinctement entre les 3 sandbox et ce sera déjà une première étape, celle-là **très simple à mettre en œuvre**.
D'ailleurs "sandbox" un terme passablement _commercial_ lui aussi : Elles conviennent à de nombreux usages IRL.
Je continue d'attendre vivement une réponse efficace d'OVH à ce sujet. Tant le détachement de disque que le downgrade font partie du cœur de fonctionnalités attendues. Parce qu'il s'il s'agit de faire des `rsync` pour monter (ou descendre) en gamme, alors n'importe quel autre prestataire de VPS fait l'affaire.
c'est un choix commercial, c'est leur droit d'organiser leurs offres comme bon leur semble...
Bonjour,
C'est un choix commercial couple a un choix technique.
Chaque groupe d'instance s-, r-, b-, c- tourne sur des hyperviseurs differents.
Nous autorisons le passages des r- vers b- / c- (dans tous les sens) avec les flavors de type -flex (50G de disque).
On ne veut pas le faire pour les s-, c'est tout.
Ceci etant dit, il est possible de le faire manuellement pour vous, moyennant un snapshot de l'instance, telechargement de l'image, reduction eventuelle du filesystem, reduction de la partition, re-upload de la nouvelle image et nouveau boot. C'est complique mais pas infaisable.
Bonne journee
Choix, certes, mais hautement regrettable car comme je l'évoquais plus haut, et au risque de rappeler une évidence, l'augmentation des performance à la demande ne fait sens qu'à la condition de permettre aussi leur réduction.
L'idée du snapshot, pour l'avoir déjà pratiquée, est totalement irréaliste en production: délais (de génération, downoad, upload, ...) + complexité des opérations.
La seule véritable solution qui satisferait à ce problème (et à d'autres) a déjà été évoquée ici l'an dernier :
https://community.ovh.com/en/t/detach-a-boot-volume/4591
Il s'agit de permettre de détacher les disque (bootable) d'instances une fois stopped/shelved afin de pouvoir procéder au remplacement/substitution. De nombreux usages seraient (enfin) résolu par cette seule fonctionnalité :
- Boot disque de substitution pour backup/OS upgrade
- Redimensionnement du disque pour élargissement du filesystem
- Attache à une instance plus performante pour upgrade **et** downgrade