Rob -
To answer your last question... It is I/O intensive on the fibre channel. This will also cause a spike in CPU utilization. The bottleneck is usually the SAN.
Dave
This is still considered a general no-no, but with the latest VC 2.5 and VCB 1.5 you can now place them both on the same system, previously there were a lot of issues with this.
If you found this or other information useful, please consider awarding points for "Correct" or "Helpful".
I'm assuming you purchased such a high end blade because it's the same as others you already have, and you might plan to re-use this as a physical ESX host at some stage?
...Simply because we purchased a new blade centre for a new VM infrastructure, one of which got used as the VC.
No more technical than that!!!
so many cores and so much ram for such a small task.
does the database live on another blade as well?
if you don't mind me asking, how many physical ESX hosts do you have (or plan to have) and approximately how many VM's?
I know - sickening isn't it!!!
We currently have only migrated about 7 servers but that will ramp up to aprox 50 in the not too distant future.
We currently run 4 x esx servers which we will gradually increase to 19 as required.
They will all be the same spec - 32gb ram with ridiculous processors!
:smileygrin:
what did you do about the database server for virtualcenter. is it running on another blade like this? or did you already have a database server somewhere else that you are using?
oh no,
we have a BIG server for SQL......lol
Rob -
If you leverage VCB properly, it is VERY I/O intensive and may cause VC to go offline at times...Assuming you have Windows EE installed to use more RAM and have the /PAE switch in boot.ini...As mentioned, it is considered best practice to make it a separate physical box. You may want to consider making Virtual Center a VM to gain availability and then dedicate the extra blade to VCB.
If you are going to VMworld, check out my breakout session: BC2497 VMware Consolidated Backup - Report from the Trenches
Dave
Dave,
Why must you be so overly smart with these things!? Stealing points all over the place!
Rob,
Dave makes a great design change point, that could really let you leverage the entire environment much better and allow you to really turn loose VCB.
If you found this or other information useful, please consider awarding points for "Correct" or "Helpful".
Ok, to go slightly more depth...
We can't make the VC a VM. This was not recommended by Dell who implemented the new VMWare infrastructure.
Whilst I know this CAN be done, because of the way our existing PHYSICAL machines had to keep their IP addresses when we migrate them, we had to allocate a new subnet for Vmotion, HA and SC Traffic. The network design is such that the VMs cant see the ESX IP range, nor do we want them to, therefore the VC which needs to see both networks, cannot be migrated to a VM.
We have 2 options -
"Suck it and see" whether VCB on the VC causes a problem with VC bearing in mind the spec of the server is very high, and it does very little.
Buy another blade for the centre and use this for VCB which seems like a lot of money for one server to perform VCB.
It was mentioned that VCB is very IO intensive - is this on processor, NIC or disk usage? If CPU I dont see it as much of an issue - the server it's on should cope easily enough. If it's disk usage, we would have to make sure that VCB runs when the servers are not being heavily utilised, likewise NIC
wpatton -
Didn't mean to offend... Rob - give the points to wpatton - he DID answer your question. I was just adding my two cents. Didn't mean to steal points..
Dave
Dave,
Sorry, that was absolutely pure sarcasm, I couldn't care less about the points, really I was just commenting on the fact that you really nailed the question with some good insight....sarcasmmaking me look bad!sarcasm
Just in jest for a good laugh, carry on with the good work!
If you found this or other information useful, please consider awarding points for "Correct" or "Helpful".
That's the way I originally took the message, but then I wasn't sure. No worries.
Rob -
To answer your last question... It is I/O intensive on the fibre channel. This will also cause a spike in CPU utilization. The bottleneck is usually the SAN.
Dave