Providing data for Azure virtual machines #282
Conversation
bpetit
changed the title
|
We tried to assess how coherent the data is by comparing it to AWS instances, and are running analysis on how the different input data and hypothesis are important in the result. So far, it seems coherent, so if anyone want to review the PR, that would be great :) You can find results we generated for testing in results.csv and the script that generated those data in generate_impact_azure. Let us know if we could do something more to make review easier. Cheers |
| - Bursts and overcommit are not accounted for, as the scripts in their current form only extract the number of vCPUs for each instance, without considering if this instance is a burstable instance. Fixing this would mean to extract informations about burst conditions for each instance and change the value of vcpus accordingly (or rely on a mecanism in BoaviztAPI that doesn't exist today). | ||
| - For GPUs (concerning NVv3 and NVv4 series): GPU units and memory for the hosts are established by matching the number of vCPUS for an instance and the number of vCPUS for the host, and establishing | ||
| the potential number of GPUs in the host with the documentation for the instances. | ||
| - Current version of the API doesn't account for remote storage. A share of the impacts of local hardware storage is allocated to the virtual machine, which makes sense. In the case of Azure data, we don't have the actual stoarage hardware and volume available for Dedicated Hosts / Bare metal machines. It means that current version of the impacts calculated by the API for Azure is **underestimated** regarding impacts of storage, as we don't account neither for remote storage nor for local storage. |
There was a problem hiding this comment.
This looks like a modeling discussion we might have in the next Boavizta Tools meeting, isn't it ? @demeringo @da-ekchajzer
|
Tried to explain a bit more the perimeter covered by the api's cloud/instance route here. I'd be happy to have your feedback on this :) |
del: aws vantage export, not the right folder
…cleaning dedicated hosts data
… from the official documentation clean: cleaned_dedicated_hosts
fix: changed name for sorting script
…s been completed with missing or incomplete references
docs: fixing dead link
docs: improved results.md
docs: documenting underestimated impact for storage
docs: GPU units still has to be filled for virtual machines
docs: improving readme and results.md, adding GreenPixie as sponsor, detailling life cycle steps covered docs: improving readme and results.md, adding GreenPixie as sponsor, detailling life cycle steps covered
…in manual_.csv file
…emote storage docs: adding explanation of perimeter of the cloud/instance route
docs: improving results.md docs: improved results.md
|
Hi @da-ekchajzer @demeringo @samuelrince, Data generated in result.csv seem coherent, not too far from data generated for AWS instances with the same script. I think we could procede with a global review any time you want now. Last thing I may do, but it could be in another PR, will be to include data for instances still missing, especially A and B series. As said in the README, we thank GreenPixie for sponsoring this PR. |
bpetit
changed the title
Great, particularly the diagram 👍 |
|
@bpetit I have looked and tried the PR and might have found a misconfiguration for 'id=Dadsv5-Type1' in server.csv. Am I right or do I misunderstand the configuration? |
Hello @havontuur ! What is indicated for On the issue of storage, the allocation remains a problem, as we have not found reliable information on the hardware devices present on dedicated hosts yet. Were you referring to this page from the Azure documentation on virtual machines when you were mentioning 96 vCPU and 3600 GiB of SSD storage ? |
Hi there,
Here is a PR aggregating data to feed the API with Microsoft Azure data for virtual machines (and supposed underlying hosts).
This should not be merged until we at least clean it up (for instance, our scripts are not PEP8 at all 😋) and improve the readme (+ that it is reviewed of course), but we wanted to allow contributors to review it in advance and give feedbacks.
I hope it is not too much noise until it is clean.
kudos @bdromard and ping to join the discussion :)