Redimensionnement
Avec Rightsizing, vous pouvez définir l'infrastructure cloud optimale la mieux adaptée à vos besoins actuels et à court terme, de manière à équilibrer les risques et les coûts afin de minimiser le gaspillage.
En utilisant les tableaux de bord Rightsizing, vous pouvez voir l'utilisation des ressources du cloud au fil du temps. Vous pouvez ensuite consulter les scénarios recommandés pour chaque ressource afin d'éclairer vos décisions en matière de dimensionnement du cloud.
Il existe deux tableaux de bord sur le redimensionnement :
- Redimensionnement : Consultez les recommandations de dimensionnement pour vos services cloud. Tableau de bord du redimensionnement.
- ROI de Rightsizing : Visualiser les économies potentielles et réalisées pour les tickets synchronisés avec Jira Rightsizing à l'aide d'une intégration Jira.
Le tableau de bord Rightsizing affiche par défaut l'onglet Explorer. Le Rightsizing Explorer donne un aperçu des économies possibles sur l'ensemble des ressources cloud utilisées par votre entreprise. Vous pouvez utiliser ce tableau de bord pour regrouper, filtrer et naviguer dans vos recommandations de rightsizing.
Les onglets supplémentaires dans Rightsizing sont des recommandations pour des fournisseurs de cloud spécifiques.
FAQ sur le redimensionnement
Pourquoi le délai de recommandation par défaut est-il de 10 jours?
le délai de 10 jours permet de saisir les tendances les plus récentes en matière de performance et de mieux prévoir l'utilisation future des ressources.
Quelle est la définition de l'inactivité?
Le temps d'inactivité est défini différemment selon le type de ressource, mais il est généralement représenté comme suit : Le temps d'inactivité pour le calcul (par exemple EC2 ) est le temps passé en dessous de 2 % de CPU sur une échelle de 1 à 100. Idle pour Block Storage / Disk (par exemple EBS ) est le pourcentage d'heures avec zéro IOPS. L'inactivité pour le stockage relationnel/la base de données (par exemple RDS ) est basée sur le nombre de connexions/sessions actives de la base de données à un moment donné.
Comment déterminer les dépenses?
Les dépenses sont les dépenses d'utilisation de l'instance pour l'informatique (par exemple EC2 ) et le stockage relationnel/la base de données (par exemple RDS ). L'entrepôt de données (par exemple Redshift ) exclut le transfert de données. Pour les objets et les Block Storage (par exemple S3 et EBS ), les dépenses sont déterminées par GB Months.
Pourquoi le total des dépenses dans le redimensionnement ne correspond-il pas exactement aux valeurs affichées dans le rapport / True Cost Explorer?
Rightsizing ne répertorie que les ressources pour lesquelles il a trouvé au moins une ressource permettant de réaliser des économies, il est donc probable que ces valeurs ne correspondent pas exactement.
Pourquoi est-ce que je vois (et non set) sous State pour EBS?
Le compte n'a pas les permissions suffisantes (assurez-vous que votre politique est à jour avec les dernières permissions) ou la ressource a été active pendant moins d'une heure (les données n'apparaissent pas dans le cache Describe Data à partir de AWS ).
Pourquoi la mention N/A pour lastAttachedTime s'affiche-t-elle pour les volumes EBS non attachés?
Les volumes afficheront la date de leur dernier rattachement aux instances EC2 et à l'adresse volumeID. Pour les volumes qui n'ont pas été attachés pendant la fenêtre de redimensionnement (les 10 derniers jours par défaut), il sera indiqué N/A.
Pour EC2, les recommandations tiennent-elles compte de l'éclatement?
Nous utilisons les performances de référence pour les ressources pouvant être utilisées en rafale (par exemple, les types d'instance T2 ) et ne tenons pas compte de la rafale pour déterminer les recommandations. Cela nous permet de formuler des recommandations prudentes qui n'entraîneront pas de réduction des ressources.
Pour EC2, comment déterminer le réseau et le disque?
AWS n'indique pas les limites de débit du réseau et du disque sur EC2. En outre, la capacité de débit varie en fonction de la charge de travail (par exemple, lecture et écriture séquentielles ou aléatoires) et du transfert (par exemple, transfert de données au sein d'une région ou d'une région à l'autre). Nous utilisons les limites communément observées dans notre portefeuille de clients pour estimer la capacité.
Pourquoi les Spot Instances sont-elles exclues des recommandations de rightsizing?
Notre moteur de redimensionnement prend en compte votre charge de travail (mesures d'utilisation) et le coût d'exploitation (type d'instance actuel et prix à la demande) et génère une liste de recommandations parmi lesquelles vous pouvez choisir pour vous aider à économiser de l'argent. Les instances Spot, en revanche, sont déjà proposées à des prix fortement réduits; l'application du rightsizing dans ces situations se traduit par des économies négligeables. C'est pourquoi nous avons choisi d'exclure les Spot Instances du redimensionnement.
Lorsque nous recommandons de déplacer un type d'instance EC2 vers une instance sans stockage local, nous incorporons dans la recommandation l'ajout de EBS et tenons compte des deux dans les économies réalisées.
À quelle fréquence les recommandations sont-elles mises à jour?
Nous mettons à jour quotidiennement nos recommandations en matière de redimensionnement. Vous pouvez accéder aux recommandations pour les ressources 24 heures après la création de la ressource, à condition qu'il y ait suffisamment de données d'utilisation.
Comment Cloudability détermine-t-il les recommandations de redimensionnement?
Les recommandations de dimensionnement sont générées à l'aide de l'algorithme propriétaire de dimensionnement le plus performant de Cloudability. Ces recommandations varient selon les CSP (Cloud Service Providers) et les services, mais les paramètres pris en compte sont généralement ceux qui figurent dans les graphiques du volet "détails" des recommandations. Par exemple, les recommandations en matière de calcul examinent généralement une combinaison de CPU, de réseau, de disque, de mémoire et éventuellement d'autres paramètres, ainsi que l'utilisation au cours des périodes sélectionnées, afin de déterminer les meilleures options.
Que dois-je garder à l'esprit lorsque je regarde les recommandations de redimensionnement?
Lorsque vous examinez les recommandations de redimensionnement, vous devez d'abord comprendre la différence entre les options de coût de base disponibles et celles que vous avez l'intention d'utiliser. Deuxièmement, faites preuve de diligence raisonnable lorsque vous mettez en œuvre une certaine recommandation, car Cloudability ne connaît pas l'objectif de chaque ressource. Vos équipes peuvent avoir gardé certaines ressources "inactives" ou "sous-utilisées" dans un but spécifique, mais Cloudability peut recommander de mettre fin à ces ressources ou d'en réduire la taille.
Dans la section "Rightsizing", pouvons-nous fixer la période de retour en arrière (délai) à 60 jours?
Actuellement, le redimensionnement dans Cloudability ne prend en charge que la période de recul ou le calendrier de 10 jours et de 30 jours.
Quelles sont les différentes valeurs d'état affichées dans Azure disk rightsizing et que signifient-elles?
Dans les recommandations de redimensionnement pour le disque Azure, les valeurs d'état sont les suivantes :
- ActiveSAS: Le disque est actuellement associé à un Uri SAS actif.
- ActiveSASFrozen: Le disque est attaché à une VM en hibernation et est associé à un URI SAS actif.
- ActiveUpload: Un disque est créé pour le téléchargement et un jeton d'écriture a été délivré pour le téléchargement.
- Attaché : Le disque est actuellement attaché à une VM en cours d'exécution.
- Gelé : Le disque est attaché à une VM qui est en état d'hibernation.
- ReadyToUpload: Un disque est prêt à être créé par téléchargement en demandant un jeton d'écriture.
- Réservé : Le disque est attaché à une VM dont l'allocation a été arrêtée.
- Non attaché : Le disque n'est pas utilisé et peut être attaché à une VM.
Voir la documentation suivante Azure sous "fields" pour les valeurs les plus récentes et leurs définitions https://learn.microsoft.com/en-us/dotnet/api/microsoft.azure.management.compute.models.diskstate?view=azure-dotnet-legacy#fields
Les recommandations de dimensionnement prennent-elles en compte les remises accordées par les fournisseurs de services en nuage (CSP) en raison des engagements horaires? Si les recommandations sont appliquées, les dépenses horaires diminuent-elles?
Pour AWS, une mesure de coût personnalisée doit être mise en place. Pour Azure et GCP, une grille tarifaire est fournie par ces fournisseurs de services cloud. Il n'est donc pas nécessaire d'établir un prix personnalisé. Les dépenses horaires entrent en vigueur la fois suivante, une fois que les données relatives aux coûts et à l'utilisation ont été saisies et traitées.