Virtualizing the database. Where ?

I'd put it where ever I had the most IO ops per second.

Which would require testing the alternatives available in the local landscape as I see no reason to say that one of your offered choices is obviously always going to be superior to the other.

Hi,

we're currently experimenting / testing an installation using a Citrix Xen Server with four Linux Server and four instances of OE AppSrv/RDBMS 10.1A (Client config). We're using a san for the physical storage. As T Basom said in his response, we noticed that the most important thing is I/O speed limit to the DB. We made two kind of test: using NFS (V4) share and iSCSI on a 2Gbps LAN (Trunk). For us, the best performance was given by NFS. We are analysing the tests results...

Best regards.

Mo.

Why would you consider iSCSI at all?

What are you trying to accomplish?

If you put the database on one virtualised disk in the VM, then you must not care about performance.  If so, that is fine.  In many instances, performance does not matter much.

If you do care about performance, then you should use as many fast spindles as you can afford, with a high bandwidth connection to them.

Using iSCSI devices means going across the network to reach your disk(s).  iSCSI is a block level protocol over TCP/IP -- disk blocks get transferred back and forth across the network.  The block size depends on the operating system's I/O unit size which would normally be some multiple of the 512 byte sector size. 4 k for example. The typical Ethernet frame size in your average LAN environment is 1518 bytes or less.  That means a disk block will not fit in a single TCP/IP packet.  The main point of iSCSI's existence is an inexpensive alternative to Fibre-Channel which requires special host-bus adapters.

If you use a performant server and a dedicated high-speed network (gigabit Ethernet or faster with jumbo Ethernet frames) with good NICs, that might work acceptably well.  Running iSCSI over the same LAN everything else goes over will not give good disk performance.  This is because of the small frame size, the network speed (100 megabit is quite common), and the competing network traffic.

Whether you get good results with iSCSI or not depends a lot on the specific products you use, especially the iSCSI server and the disks you put on it.

Nothing is ever easy, is it?

gus wrote:
Why would you consider iSCSI at all?

I won't now

What are you trying to accomplish?

I want to be able to backup the db machine as a single file that holds everything - os/db/appserver/webspeed configs, so when we restore, that's it - we're ready to roll.

We don't have any performance issues at present - Tom, before you go off on one, I'm sure that I could improve performance 3x/4x by doing all that I should / could but if I can currently get all of the info required in front of the agent in less than a second, the gain is not worth it. Yet.

Would you recommend NFS then ? Where else / how else would you put the physical files required for the DB/BI/AI

As Gus says... not every database has to be tuned to the max   OTOH you did ask for performance comparisons so I think that it is fair to have assumed that that was important to you...

As for NFS.  I'm ok with it.  I usually use it as a work-around for not having a better option though.

How big is the database?

If you do an OpenEdge database backup, that can be in a single file.  If the database is not overly large, you can direct the backup to the VM's virtual disk.

Backing up the VM image when it is turned off gives you a copy of the whole os and installed software.

If the database is large, you will need at least two files -- one for the db and one for the vm image.

NFS might be fine as long as it is properly configured and not too old (nothing earlier than NFS v3) and has all the necessary patches (depends on both operating systems of course -- NFS client and NFS server).

If you dispose of some "intelligent" SAN (eg: NetApp) , you can use snapshot and incremental snapshot ... then you can keep multiple versions of DB (With successive change)..

All that stuff I said about iSCSI put you off, did it?

Well guess what?  The same stuff applies to pretty much all the other kinds of networked storage that run over Ethernet.  For best performance, you are going to need a dedicated high-speed network, jumbo frames, and decent NICs.

Good news though: it takes about 40'ish microseconds to transmit a single 4 k byte packet over a short gigabit Ethernet connection where propagation delay isn't a factor.  That's not much compared to disk read and write times, which are nearly 100 times slower.  So networked disk access can be pretty good.  Of course, there's some additional overhead in addition to the 40 microseconds.