Hi Joe (And List'ers) There is a known issue with Gig-E, and the "Auto Settings", there were several RFC's on this (I could track them back if needed) and they differed in the negotiation process, so it all depends on the HW deployed if it negotiates Full-Duplex or not.
Thus, you should always (well, we had the rule at least!) set the Switch/Router to FULL AND the Physical NIC Card to FULL. Else you're more than likely running HALF/Negotiated, which means about 400MB/Sec [it you are lucky]... I personally LOVE this little free tool called "IPERF", whcih is a type of "Client/Server" network performance testing tool. We were thinking aabout automating some testing scripts around this as well. See http://dast.nlanr.net/Projects/Iperf/ as it runs in ALL environments :) :) and it fits my price-range (Free) You basically setup a monitoring server (Say the DB Server), and then from a client (Say your AR Server) and then test-away, and ensure you change the packet-sizes, etc. This way you can "test & Document, Tweak & re-test!" Concerning tuning in ESX or Virtual Server environment(s), it boils down to several things, and it boils down to "research before virtualization", you must have a very clear understanding of BASIC Processor Usage, Memory Usage, Network Usage graphed throughout the 24 hour / week long / month long period. You could imagine a server which is idle during the day, but at night gets slammed because of some batch processing (say your CMDB Recon / EIE / etc).. Also, you might have some weekly / monthly / quarterly / year-end type of performance issues as well. This will allow you to chart / graph which systems are "safe" to exist on the same physical machine while being virtualized. Of course, you can always move some instances around to fit for the spikes caused by Month / Quarter / Year end demands :) that is IF you have them documented before... I know there are some excellent references on the VMWare site, but I believe it is best to start with the basics prior to getting in and tweaking internal VMWare settings, etc... HTH Robert Molenda On Feb 3, 2008 9:58 AM, Joe D'Souza <[EMAIL PROTECTED]> wrote: > ** Hey Robert, > > You might be able to help me a tad bit here... > > Could you elaborate a little on the "GIG-E full/auto-configuration > issue" as I am pretty sure I am facing that here... > > Also do you have any documentations on "Performance Tuning in Virtual > Environments" specific to Remedy or otherwise? > > We recently moved from VM to physical hardware, as we were experiencing > really poor performance on our development environment, but moving to > physical didn't help too much. So we are suspecting our network > configuration were we got a Gig card set to auto as the currently installed > driver supports only a max of 100 MB full duplex. Is there any issue related > to this? > > Joe > > -----Original Message----- > *From:* Action Request System discussion list(ARSList) [mailto: > [EMAIL PROTECTED] Behalf Of *Robert Molenda > *Sent:* Sunday, February 03, 2008 12:20 PM > *To:* arslist@ARSLIST.ORG > *Subject:* Re: Virtualizing Remedy > > ** I also use MS Virtual Server at home (it is free), and VMWare ESX for > work. (6.3 P22 Windows 2003) > > Some key points to consider, is you MUST have knowledge of "Performance > Tuning in Virtual Environments", the major bottle necks is not the CPU or > Memory (faster and more is always best right!), however in the NETWORK > Configurations... > > You must remember that for fail-over, etc that all NIC's are allocated to > a BOND (Multiple Physical to one Virtual) and then the BOND is allocated > (Attached) to the Virtual Server(s). Also remember the GIG-E > full/auto-configuration issue... > > You MUST use a bunch of fore-thought to the allocation of these BONDS to > the systems. We had terrible performance on ESX, until I (not the NT / ESX > Administrators) got in and figured out that they had ONE BOND that was > allocated to Remedy-Production Server and the Business Objects broadcast > scheduler/server and one other 'heavy network' server... Well, as I say > DDUUHH RIGHT! > > As soon as we reconfigured the three largest systems, POOF Screamed faster > than the older physical hardware did. > > One other 'trick' is to create a VIRTUAL NIC, to connect your Server to > the Database. Although this does have fail over restrictions (both VM's must > be moved to another same-box-configuration)... > > As to "not officially supported", there are many things BMC (Remedy) does > not "officially support" but in fact works OK, such as Fail Over Microsoft > Clusters... (not that I suggest this any-longer, go VM!) > You administrators can easily 'clone' a system into a new environment (for > load ballencing), so you only patch ONE system, then "Clone & Configure"... > Speaking of patching (Binaries, not application unfortunately), you can > clone prod to a test, patch and test, then clone forward again. Total outage > is very short, expecially in vload ballenced-virtual-ized environments. > > HTH > Robert Molenda > On Feb 3, 2008 8:19 AM, Jason <[EMAIL PROTECTED]> wrote: > > > ** I've run both ms virtual server and vmware with 6.3 and 7.01. A good > > server with a dedicated NIC, multiple processors, and a few Gig's of RAM > > will work for a smaller environment on 6.3. Just be prepared to throw A > > LOT more hardware at it if you upgrade to 7 or have a lot of users and data. > > > > > > Jason > > > > ----- Original Message ---- > > From: Steven Pataray <[EMAIL PROTECTED]> > > To: arslist@ARSLIST.ORG > > Sent: Friday, February 1, 2008 12:22:47 PM > > Subject: Virtualizing Remedy > > > > ** Our company is starting to get heavy on creating Virtual Servers but > > none are production worthy yet because of the hardware on the physical > > server. How close are other companies getting where Virtualization for > > production machines are a reality? We are using Microsoft Virtual Servers at > > work but at home I play with Vmware products IMHO is better. I'd really like > > to get to the point where I can run a production Remedy server on a Virtual > > server so Disaster Recovery is as quick and cheap as a copy/paste. Or an > > production installation is as easy a download. > > > > Steve > > > > AR Server: 6.03.00 patch 023 > > Mid-Tier Patch 21 > > Oracle 10gR1 > > HelpDesk 6.03 > > > __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" > html___ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
