Quota, parts et coeurs en option
Par zllak le lundi 27 décembre 2010, 17:39 - Hébergement - Lien permanent
La prochaine version (3.0.8) va apporter un changement majeur dans la gestion du quota Hébergement, ainsi que dans l'utilisation de l'API associée. Notez bien que les modifications décrites ci-dessous n'arriveront que lors de la mise en production effective de la 3.0.8, dans les prochains jours.
Le changement a principalement été motivé par l'envie de vous proposer des cœurs en options pour vos serveurs. Mais il s'est avéré que dans l'état actuel des choses, cette option n'était pas possible.
Petite explication...
Existant
Lors de la création d'un serveur, le nombre de cœurs est déterminé en fonction du nombre de parts associées au serveur. Nous donnons un cœur CPU toutes les 4 parts, soit :
- 1 cœur pour un serveur avec 1 à 4 parts
- 2 cœurs pour un serveur de 5 à 8 parts
...
- 6 cœurs pour un serveur de 21 à 24 parts.
Le nombre total de cœurs utilisés dépend donc directement de l'utilisation des parts. Prenons l'exemple d'un client qui aurait 48 parts :
- Si il créé 48 serveurs, il aura donc un total de 48 cœurs utilisés.
- Si il créé deux serveurs de 24 parts, il aura donc un total de 12 cœurs utilisés (6 par serveur).
Il devient évident qu'il est très difficile de déterminer le nombre de cœurs "disponibles" puisque cela dépend entièrement de l'utilisation qu'il est fait des parts. Et sans cette notion essentielle de "cœur disponible", nous ne pouvions pas vous proposer d'acheter des cœurs supplémentaires.
Changements
Il a donc fallu trouver une solution pour palier ce problème. Nous sommes arrivés à une solution qui permettait de rester cohérent avec l'existant, tout en ouvrant la possibilité de compter des cœurs en option.
La solution qui nous est venue est tout simplement de supprimer les parts. Les parts au sens technique bien-sûr. La part devient ce qu'elle aurait toujours du être : un bundle commercial, et non une notion technique.
Pour rappel, la part apporte aujourd'hui :
- 8192 Mo d'espace disque,
- 5 Mbps de bande passante,
- 256 Mo de mémoire.
Le droit de créer un serveur ne s'appuyait que sur le fait d'avoir une part disponible.
Pour supprimer cette notion technique de part, nous avons donc ajouté dans ce bundle "part" : 1 quota-serveur. Pour créer un serveur, il faudra donc avoir 1 quota-serveur et des ressources disponibles (mémoire, disque, et cœur).
En effet, pour les utilisateurs de l'API, la méthode vm.create prenait un paramètre "shares". Ce paramètre disparait donc. Il laisse sa place au paramètre "cores", qui représente le nombre de cœurs qui seront utilisés par ce serveur.
Maintenant, pour maintenir l'offre actuelle, nous avons dû ruser :)
Le quota-serveur inclut 0.75 de quota de cœur et chaque bundle (le bundle "part") inclut, lui, 0.25 de quota de cœur. Si vous souhaitez créer un serveur avec 2 cœurs, 1 quota-serveur sera utilisé et fournira 0.75 de quota-cœur. Le premier bundle "part" fournira le 0.25 manquant pour compléter le 1er cœur et vous devrez disposer de 1 de quota-cœur (fournit avec les parts ou en option) supplémentaire pour avoir votre second cœur.
Pour les utilisateurs de l'API, par exemple, si l'on veut créer un serveur avec 3 cœurs, on appelle la méthode 'vm.create' avec le paramètre "cores" qui vaut 3 directement. Vous consommerez de votre pool de ressources, 1 quota-serveur et 2.25 de quota-cœur.
Autre note, quand un serveur est créé, les 0.75 quota-cœur fournit par le quota-serveur viendront s'ajouter à votre total de cœur. Il n'est donc pas bizarre de voir ce chiffre monter après chaque création de serveur.
Site web
Pour le site web, les deux nouveaux quotas ont fait leur apparition dans la barre de récapitulatif des ressources. Sur la page de création de serveur, on ne choisit désormais plus le nombre de parts, mais le nombre de cœurs, ainsi que sur la page de mise à jour des serveurs. Là, comme dans l'API, on ne parle que de cœurs entiers, pas de virgule.
Il faut également choisir la bande passante désirée lors de la création de l'interface réseau, car c'était le nombre de parts qui déterminait la bande passante. En attendant de vous fournir de la bande passante en option (cette année), nous la globalisons et vous permettons d'utiliser votre quota comme vous le souhaitez.
API
Les méthodes qui ont été impactées sont 'vm.create', 'vm.update' et 'account.info'. Les paramètres "shares" des méthodes 'vm.create' et 'vm.update' disparaissent, et les paramètres "cores" et "bandwidth" font leur apparition :
- cores : nombre de cœurs pour la création/mise à jour du serveur (entier de 1 à 6)
- bandwidth : la bande passante pour créer l'interface réseau (selon votre quota)
Le paramètre "shares" reste disponible jusqu'à la fin de la période de beta de l'API. Il disparaitra totalement après cette période.
La méthode 'account.info' affiche désormais les ressources 'granted', 'used' et 'available' pour "cores" et "servers".
Ces changements interviendront dans les prochains jours, lors de la mise en production de l'API 3.0.8
Commentaires
Good good good les cœurs en option. Quels seront les prix?
Ca sera 9€HT/m en grille A...un billet va suivre sur le bar quand ça sera disponible (en début de semaine prochaine)
Bonjour, pouvez-vous nous donner une estimation pour la date de sortie de la bande passante en option ? merci
Bonjour,
Je ne trouve pas le nouveau mode très pertinent après utilisation. Au lieu d'avoir une part qui a un sens et qui permet d'accroitre la puissance de son serveur à tous les niveaux, vous avez préféré faire comme votre voisin OVH et faire un système "au composant", sauf que vous avez voulu garder votre système de parts "générales". Donc on achète des parts, mais au final on ne sait plus trop ce qu'on achète. Coté gestion, ce n'est plus clair du tout. Alors qu'avant, on ne faisait que rajouter une part à son serveur, maintenant on doit réfléchir précisément à ce qu'on a besoin parmi les différents éléments, puis trouver les bonnes pages pour les augmenter. J'ai par exemple un peu galéré pour réussir à augmenter la BP d'un serveur.
Pour moi vous voulez la force marketing de la "part" (et qui était vraiment pratique à l'utilisation) à tout d'un coup un système sur-mesure, qui gagne certes en souplesse pour ceux qui savent vraiment ce dont leur hébergement à besoin mais qui devient une source de complexité pour les autres. Imaginons un client lambda qui a un blog, son blog commence à ramer car il fait davantage de traffic, est-ce qu'il doit augmenter au niveau du processeur, de la ram, de la BP ? Le client lambda à mon avis n'en sait rien.
Là je trouve que vous avez clairement reculé, au lieu de continuer à faire des outils simples et puissants, vous avez voulu de la souplesse en perdant totalement de l'ergonomie de l'outils et de la facilité de prise en main.
En plus vous continuez à présenter coté site marketing, le système de parts comme il était avant, alors qu'une fois sur son système de gestion, le client lambda ne comprendra plus où ses parts sont et où la fameuse facilité est passée.
Pour moi, la situation est bancale, et il y a 2 solutions possibles :
- Soit vous revenez sur un vrai système de parts et quand on va sur la gestion de son serveur, on peut ajouter/supprimer des parts, comme avant. Et, éventuellement, pour ceux qui veulent vous permettez de rajouter des coeurs, ou de la ram à l'unité, dans un système de paiement autre.
- Soit vous êtes sur un système complet à l'unité, où quand on ne paye on n'achète pas une part, mais on achète clairement de la RAM, du processeur ou du réseau.
Là vous voulez avant tout (j'ai l'impression) un système qui vous arrange, mais qui (je pense) n'arrange pas l'utilisateur final. Complexifier les outils au lieu de les simplifier ne correspond pas à l'image que j'ai de Gandi depuis plus de 10 ans... La plusvalue gandi est-elle en train de disparaître ? ;)
Bref, pour moi c'est un peu un EPIC FAIL, j'espère que le système sera repensé à nouveau en prenant en compte tous les types d'utilisateur...