M$ Storage Spaces equivalent

[Bicka]

I am trying to get a new Proxmox installation up and running and I would like to ask what the best solution is for shared storage to host an Access Database and access it from M$ Terminal Services running on Windows Server 2008 32bit.
I need 16bit support as the App is legacy.

I have done extensive testing with various file shares (Turn-key Linux, Windows etc) on Proxmox. The performance was unacceptable, the current system Server 2003 runs natively on an old server and has great performance.
Would the Performance be maximised if the files were located inside the VHD on the server VM? or is there a CIFS or NFS solution for storing the database external to the VM that will offer high performance?

The server is basic as it will only be serving this legacy Access 2.0 16bit App.

Xeon Quad Core, 16GB of ECC RAM, 2x2TB HDD, 1x256GB SSD.

I have been reading up and am quite impressed with the M$ 2012 R2 Storage Spaces solution (http://technet.microsoft.com/en-us/library/dn387076.aspx)
I would like to know if there is an equivalent here for Software RAID1 with SSD Tier.
The M$ solution looks like the perfect solution although I find the Free Hyper-V no-GUI management to be a chore and this would be simplified by Proxmox web interface (which I love).

My Stumbling block now is how do I implement a Software RAID1 with SSD Tier solution on Proxmox?

and

What is the best location to store my database files to be accessed from Windows Terminal Server with Maximum performance?

I am happy to store the Database on the SSD and have a replication event to backup the files to the HDD every 5mins as data loss of 5mins is acceptable for our application.

I like the idea of a hyper-visor so I can deploy additional servers later or move to a VDI solution for some of the remote workstations. I found the file access performance to be unacceptable between VMs on proxmox which was my previous question.

Sorry for the long post.

Thanks in advance.

 

[m.ardito]

The server is basic as it will only be serving this legacy Access 2.0 16bit App.

And I thought my access 97 legacy apps were too old...

when you say your performance were "unacceptable", it would be best to have more details about remote storage and pve (version, storage conf) hw setup (disks, raid, network, etc) and which tests bring you to this consideration (type, output), so that others can help you.

Marco

 

[Bicka]

Sorry for the absence.

I have spend the past week testing various VDI solutions on Proxmox.

I have tested:
Windows 8.1 32bit - The NTVDM installs to run the 16bit app but the performance is woeful (CPU climbs to 100%) often there is a 2-3second lag with the blue circle of death. The screen colours are broken icons missing etc.
Windows 7 32bit - NTVDM is already included and the Program runs much faster here but Windows 7 has the same screen color issues (which can be fixed by group policy). There is noticable lag 5 to 20seconds adding lines to the database.
Windows XP 32bit - Operating system is unsupported come 2014, the Program runs as it should however, noticeable lag 5 to 20seconds adding lines to the database.
Windows Server 2003 32bit - Runs slower than the physical install on the ancient PC.

Storage options tested:
IDE, SATA, VirtIO, LVM, Directory
2x2TB HDD and 1x256GB SSD all the mounting options, partitioning etc have been tested in Proxmox host.
I have tested software RAID levels with MDADM, Guest RAID1 & 0, Windows Storage Spaces, SSD Caching software etc.
The IOPS are great, 430MB/s Avg, and 13,000IOPS Storage model is def not the issue here.


The old Physical Server running SBS 2003 is dual core 2.0Ghz 2gb of RAM and the application is lightning fast, the performance is even better over RDP, adding lines to the database is instant. This is the fastest solution, although it is running an old IDE 320gb hard drive...


This has lead me to the conclusion that DOSEMU on the 64bit Linux Kernel is slowing me down. Are there any people out there running 16bit apps on proxmox?

I have even considered WINE but that opens up another multitude of issues with printing, report engine etc.

What a nightmare.

Sorry if the post isn't clear. I'm just at a loss to see if its possible to run 16bit apps with any success on 64bit hyper-visor, or in a VDI or Terminal Server setup.

Thanks.

 

[m.ardito]

Sorry if the post isn't clear. I'm just at a loss to see if its possible to run 16bit apps with any success on 64bit hyper-visor, or in a VDI or Terminal Server setup.Thanks.

Someone could test something on other installs, but... how can we reproduce something similar? Is there any similar application still around?

Marco

 

[Bicka]

Someone could test something on other installs, but... how can we reproduce something similar? Is there any similar application still around?

Marco

The Application is VB3.0 running Access 2.0 Database. It is possible that nobody still uses ancient software like this. I am really struggling with the developer to try and update the basecode, I would even re-write it myself in .NET4 and mySQL if I had the opportunity.

I do appreciate the response, I think I have come to the conclusion that the CPU running in long mode 64bit is not capable of executing 16bit code, the 16bit code must be passed through several layers of emulation which causes the slowdown, running baremetal 32bit OS keeps the CPU in real mode or 8086 mode.

I will be testing Windows 8.1 32bit Enterprise directly installed on the box (no proxmox) to determine if the performance issue is caused by the visualization layer.

- Bicka

 

[Bicka]

The Performance is great on Windows 8.1 pro 32bit installed baremetal runs lightning fast directly on SSD. This is fast via RDP or via console.

Graphics Performance on proxmox is terrible. CPU thrashes to 100% and the screen is laggy. Could this be a graphics driver issue? is there a graphics driver for proxmox?

Crystal Disk mark runs Super fast on proxmox, so it isn't a storage issue at all, the IO is fast.

Thanks.

P.S. I realised 'Storage Spaces' is pretty similar to LVM but its management is automated to allow SSD caching, fakeRAID etc automagically.