Last time I checked, the official stance from what was then IBM is that
virtual environments other than VMWare were not supported, and even
then, any DB issues that you ran into while running under VMWare would
need to be fully replicated in a physical environment before support
would be provided. As a result we took a policy of not supporting
virtual for any of our end-users, and strongly pushed them all to remain
on physical. 

In most cases where they still went ahead and installed on virtual, all
appeared to be fine initially and would run perfectly "fine" for a
period of a few months before performance would degrade over time to the
point where the our clients complained it was unacceptable, at which
point we would get them to switch back to physical.

Having said all that, when configured properly, it *does* work.. The key
points to follow will be the same as virtualizing something like
Exchange/SQL Server where your IO requirements need special
consideration. Stay away from dynamic virtual disks, use pass-through
disks or iSCSI targets if possible, or worst case use a fixed/static
disk image for the best IO performance. File sizing and fragmentation
can leave you dead in the water so be sure to have processes to monitor
these and keep everything as optimal as possible. I personally found a
number of IO performance bottlenecks in our application while
troubleshooting virtual servers with tools like Sysinternals Filemon,
where seeking IO within files is quite obvious due to the repeated
access to the same file but at sequential addresses.. Once we got a
handle on the file sizing, and some of the code was cleaned up,
performance was reasonable, and has remained as such for more than the
normal "few months"...

As an aside, with SB+ on virtual, we found a major bottleneck with the
way the TUXFER.DATA.% port files are created/cleared on use. For some
reason in a virtual environment, the CLEAR-FILE on a static UDT file can
take a considerable time to complete, so transfers to Excel would pause
for a significant time before initiating. We solved this by pre-creating
a fixed number of TUXFER.DATA.% files (250 in our case) as dynamic
files.. This not only solved owner and general windows permission issues
(Error 202 etc) but meant that the clear down was near instantaneous for
the SB processing..

FYI all of this was with UniData on Windows, I suspect UniData on Linux
in virtual would be considerably better due to how shared memory works
under Linux as compared to Windows...

HTH 

Ray

-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Kevin King
Sent: 26 January 2010 17:32
To: U2 Users List
Subject: [U2] Unidata on Virtualized Server

Is anyone running Unidata (+ SB+) on a virtualized server, i.e. VMWare?
If
so, what considerations and concerns are there in this environment that
are
different from a dedicated Unidata server?

(Yes, I searched the archive and didn't find anything that recent, so my
apologies for asking a question that has been asked before.)

-Kevin
http://www.PrecisOnline.com
_______________________________________________
U2-Users mailing list
[email protected]
http://listserver.u2ug.org/mailman/listinfo/u2-users

_______________________________________________
U2-Users mailing list
[email protected]
http://listserver.u2ug.org/mailman/listinfo/u2-users

Reply via email to