the only part. where I do not follow the Guide is that the datastore, represented by physical SSD, where the unity is installed on, is the same where also the data vmdks are lying.
But, in my opinion, this is not correlating with the high cpu usage?
I noticed in the Best Practice guide the following:
"When provisioning storage for UnityVSA, it is recommended to use storage for the OS that is physically separate from the storage that will be used for storage pools"
It's possible that have the OS and datastore on the same physical SSD might cause contention, increasing CPU overhead. Might be worth a try to separate those.
glen
Edit:
When say the CPU is 80% - which CPU - the Servers? The VSA is using two cores.
So, like the best-practise I setup the VSA on SSD, it's has also some virtual drives for some pools here but there is no data on it. The VSA system is running on SSDs, the pool I created is running on FC disks.
The screenshot above shows what happens if I copy a 50GB VMDK via vMotion from local storage to the VSA.
One thing that I also don't understand is that the CPU usage of VSA is still high after the VMDK migration is completed.
The physical host is a test server with this setup:
DELL-Sam L
Moderator
•
7.8K Posts
0
November 1st, 2018 13:00
Hello marcka,
Did you check out our best practice guide to make sure you have everything set correctly? Here is a link to the guide just in case you need it.
https://support.emc.com/docu69891_Dell-EMC-Unity:-Best-Practices-Guide.pdf
Please let us know if you have any other questions.
marcka1
3 Posts
0
November 8th, 2018 22:00
Hey,
the only part. where I do not follow the Guide is that the datastore, represented by physical SSD, where the unity is installed on, is the same where also the data vmdks are lying.
But, in my opinion, this is not correlating with the high cpu usage?
kelleg
4 Operator
•
4.5K Posts
0
November 9th, 2018 09:00
I noticed in the Best Practice guide the following:
"When provisioning storage for UnityVSA, it is recommended to use storage for the OS that is physically separate from the storage that will be used for storage pools"
It's possible that have the OS and datastore on the same physical SSD might cause contention, increasing CPU overhead. Might be worth a try to separate those.
glen
Edit:
When say the CPU is 80% - which CPU - the Servers? The VSA is using two cores.
marcka1
3 Posts
0
November 12th, 2018 23:00
So, like the best-practise I setup the VSA on SSD, it's has also some virtual drives for some pools here but there is no data on it. The VSA system is running on SSDs, the pool I created is running on FC disks.
The screenshot above shows what happens if I copy a 50GB VMDK via vMotion from local storage to the VSA.
One thing that I also don't understand is that the CPU usage of VSA is still high after the VMDK migration is completed.
The physical host is a test server with this setup: