Navision 5.0 (native) and SAN storage

ta5 · 2008-02-22

Hi
Is there any recommandation concerning SAN storage for native Navision? I didn't found any particular info except in the hw guide white paper, page 20.

My concerns are the following:

1) What is a recommended file splitting strategy (the db in question is about 20 GB)? If I understand this correctly, the data is striped to different disks on a SAN anyway, so maybe the strategy to split it may be counterproductive!?

2) As far as I remember, there was/is always the discussion whether to use controllers with/without cache and with/without battery buffer. Is this still an issue? If yes, where can I find detailed info on this.

Many thanks in advance.
Thomas

kine · 2008-02-22

Best performance for Native DB server is to have "directly attached" discs (SATA, PATA, SCSI controller directly connected to the server) - and to split the database to as many RAID volumes on seprate physical discs as possible.

Waldo · 2008-02-24

It is no exact science. Since there is something like SAN, these things have become quite (let's say TOO) complicated. I know that SAN can be much faster than dedicated discs. But there are about a zillion ways to set up a SAN: Number of discs, config of LUNs, RAID config, ... and all in combination with each other.

A Native DB server can only take up to 1 GB RAM and 1 CPU. That means, not scalable enough. Usually this means that when we're talking about SAN, we're talking about SQL Server (bigger company with bigger DB with more money

). That's probably the reason why there is no straight forward information to find about what the best way is to set this up.

If you find material, please post it here

. I'm very interested.

I use Kine's recommendation ... that way, you got more control over it.

garak · 2008-02-24

if you are use an SAN, be sure, that Navision is the own application on this "black box". And no other application compete with navision for network bandwith or disk i/o.

ta5 · 2008-02-26

Thanks for all your input. I don't set [solved] in the title for now, maybe someone else has an input on this.

Regards
Thomas

amcmwu · 2008-04-07

Hello

we are also trying to use a SAN and we started with a HP EVA4100 and now we have a EVA8100 but the system is still not so fast then the old one :shock: . The old one works on a Siemens Primergy P 250 XEON with 4 GB Ram and 2 SCSI-Shelfs every with 12 Disks - RAID1. All on a native database with 84GB (12*7GB). We are still trying to find the right setup, and when we have we will send it to you.

Hopeing the best and expecting the worth

Martin

Marije_Brummel · 2008-04-07

I am curious about your EVA Setup.

Some of my customers work on an EVA and the performance is just amazingly fast.

Off course they are SQL installs, one of them with 320 concurrent users in one company.

As far as Native: Multiple RAID 1 is the best way to go.

Captain_DX4 · 2008-04-07

I was at a client who used to run a native 120GB database on an Hitachi SAN. The server was a quad processor (I cannot remember exactly what specs) with 16GB memory, and the NAV service was the only service that this server was running. Normally the processing "weakest link" was the workstations on the network. Viewing the setup from the server side, data requests were hardly a blip on that box.

Marije_Brummel · 2008-04-07

Amazing!

14GB of ram doing nothing...

Captain_DX4 · 2008-04-07

*lol* Indeed! It was spec'ed and installed before I got there. I wondered if I could pocket the other 14 and if they'd ever notice. *grin*

David_Singleton · 2008-04-08

ta5 wrote:

Hi
Is there any recommandation concerning SAN storage for native Navision? I didn't found any particular info except in the hw guide white paper, page 20.
...

My comments on the use of SANs here:
Why I don’t want my clients to use SANs for Dynamics NAV (Navision) - David Singleton's Navision Blog

In terms of Native, if you have a relatively large number of users then you should partition as multiple RAID 1 arrays to get better use of the Commit cache, though in reality the 500meg or so that NAV will allocate to commit cache is not enough anyway. You can run the DB as just one big file (I have seen a single 250 Gig database file working on a SAN) but multiple LUNS and multiple parts will be better.

amcmwu · 2008-04-08

Hello

we are now at point we dont know what to do. We tried multiple LUNs, multiple Databasefiles one big file but nothing is so fast then the old system. Details about our Navision are 84 GB Database, 120 Users and we try to put it on a EVA 8100 (HP give us a new one instead of the old 4100 we wanted

. They said the FC-Switchsoftware has a bug) Server for this should be a HP BL460 BLade with 2 Quadcore 2.33Ghz and 4 GB Ram.
The problem on this is that creating a database with 100 GB takes about 20 minutes - thats OKAY- , restore the backup from the fbk-files also takes about 40 minutes thats also OKAY, but then the Navision Native Databse starts to build the keys and this takes on that maschine about 2 days ](*,) so whats wrong. Every hardware maschine with no SAN is faster on creating keys.

regards Martin

kriki · 2008-04-09

Just an idea:
Did you put the put the "Max degree of parallelism" (a sqlserver property) to 0? This should use all available cpu's to calculate the indexes.
When working normally, it is best to have the value=1.

amcmwu · 2008-04-09

kriki wrote:

Just an idea:
Did you put the put the "Max degree of parallelism" (a sqlserver property) to 0? This should use all available cpu's to calculate the indexes.
When working normally, it is best to have the value=1.

Hello kriki

what do you mean with "Max degree ..." were can i find it on a native server installlation

Regrads

kriki · 2008-04-09

sqlserver properties=>advanced=>Parallelism=>Max degree of parallelism (on SQL2005).

Marije_Brummel · 2008-04-09

Kriki, wakeup on the topic. Native.

SQL on NAV wil always use one CPU on the indexes.

What vRAID do you have? How many disks? Are your lun's sharing disks with other app's?

How is the NAV Server.exe setup? Are you restoring via a client/database or via a server.exe?

kriki · 2008-04-10

Mark Brummel wrote:

Kriki, wakeup on the topic. Native.

:oops: :oops: :oops:
Had a bad night. Didn't sleep well. And when I read SAN, I think directly of SQL and not of native. And I forgot to reread the rest of the topic.

amcmwu · 2008-04-10

Mark Brummel wrote:

Kriki, wakeup on the topic. Native.

SQL on NAV wil always use one CPU on the indexes.

What vRAID do you have? How many disks? Are your lun's sharing disks with other app's?

How is the NAV Server.exe setup? Are you restoring via a client/database or via a server.exe?

Hi Mark

we are using a Vraid1 and the shelf had about 28 FCB Disk with
300 GB. There is one big Diskgroup with 7200GB. Also we have
3 ESXServer ver3.5 with data there.

What i read the last days it is not the :roll: "best" solution.

Regards Martin

Marije_Brummel · 2008-04-10

ESX adds another virtual layer which has to be audited to find out what's happening.

If setup correctly it should not cost more than 12% extra I/O.

I have customers running on VMware/ESX, but some had to be changed before it ran ok. I use an external VMware expert for that whom I trust.

ESX is relatively new and is sold faster than there are consultants available to set it up properly.

DenSter · 2008-04-10

For emphasis:

Mark Brummel wrote:

set it up properly.

Who told you to get 2 quad core processors and 4GB of RAM for NAV native database server? It doesn't use more than ONE CPU and less than 1GB of RAM.

amcmwu · 2008-04-10

@ DenSter
It is right with the quad core processor but quad and dual were the same price and in the old system we had two dual xeon and i had to say, you can see it if you have the database running and doing the hotcopy at the
same time. We never had a performance prob at those times.

@ Mark
We tried the same jobs on VM with Disk in SAN, on Hardware with disk in SAN ans on older Hardware Server. Everytime the Hardware is faster. Now our systemhouse is going back from ESX ver. 3.5 to ver 3.02. :shock: We will see and i start praying.

Navision 5.0 (native) and SAN storage

Comments

Categories