epicor 9.05.7xx hardware sizing guide

Epicor® 9.05.700

Hardware Sizing and

Configuration Guide for SQL™

and Progress

® Databases

Epicor 9.05.700: Hardware Sizing and Configuration Guide i

Table of Contents

Introduction 1

How to Use the Hardware Sizing Guide 1

Important Comments 2

Application Load Profile 4

What is Typical Usage and What Should You Avoid? 4

Determine Your Unique Application Usage Pattern 5

Server Hardware Sizing 7

Epicor 9.05 Application Server 7

[Standard] - Microsoft SQL Server 2008 R2 Server 8

[Medium] - Microsoft SQL Server 2008 R2 Server 11

[Large] - Microsoft SQL Server 2008 R2 Server 14

Epicor 9.05 Using Microsoft SQL Server 2008 R2 Scenarios 16

[5-40 users] - Epicor 9.05 using Microsoft SQL Server 2008 R2 16



[1000 users] - Epicor 9.05 using Microsoft SQL Server 2008 R2 19

Epicor 9.05 Using OpenEdge Database Scenarios 20

[5-40 users] - Epicor 9.05 Using OpenEdge Database 20

[41-150 users] - Epicor 9.05 Using OpenEdge Database 21

[151–300 users] - Epicor 9.05 Using OpenEdge Database 24

[300+ users] - Epicor 9.05 Using OpenEdge Database 26

Epicor 9.05 Using MS SQL Server 2008 R2 on VMware vSphere 5.0 27

Epicor 9.05 VMware Virtual Application Server 27

[10-20 users] - Epicor 9.05 Using MS SQL Server 2008 R2 on VMware vSphere 5.0 28



Epicor 9.05 Using MS SQL Server 2008 R2 on MS Windows Server 2008 R2 Hyper-V 31

Epicor 9.05 Hyper-V Virtual Application Server 31

[10-20 users] - Epicor 9.05 using MS SQL Server 2008 R2 on MS Windows Server 2008 R2

Hyper-V 32

[21-49 users] - Epicor 9.05 Using MS SQL Server 2008 R2 on MS Windows Server 2008 R2

Hyper-V 33

[50-100 users] - Epicor 9.05 Using MS SQL Server 2008 R2 on MS Windows Server 2008 R2

Hyper-V 34

Other Hardware Requirements 35

Epicor Client Machine / Epicor Workstation 35

Epicor 9.05.700: Hardware Sizing and Configuration Guide i i

Remote Desktop Services 36

Epicor Web Access (EWA) 37

Epicor Service Connect (ESC) 38

Hardware for Other Epicor Systems 38

Handheld Equipment 39

Barcode Equipment 39

MES Workstation 39

Communications 39

Printer 39

Backup Equipment 39

Network 40

Appendix 42

Testing Performance of an Existing SAN 42

Sizing Processor the CPU(s) 44

Sizing Memory Requirements (RAM) 45

Disk System – Sizing, Configuration and RAID 46

Backup and Fault Tolerance UPS 50

Epicor 9.05.700: Hardware Sizing and Configuration Guide 1

Introduction

Welcome to the Hardware Sizing and Configuration Guide. The goal of this guide is to provide a

practical approach to sizing your Epicor 9.05 application and database server to obtain the best

performance possible from your Epicor software. It will also help you plan for the future growth of

your system.

The key to success in getting your hardware sized correctly is to define your application load

correctly and then to match it with the appropriate hardware resources. Choosing a hardware

architecture which can grow as your business and / or application load grows is also important.

It is difficult to accurately provide a hardware recommendation that matches your unique

application usage pattern. Many customers find this guide very useful and accurate after they

have followed all the steps described in the sections. There are some cases where the provided

recommendations may not fully work out in your unique situation. It is therefore difficult to

guarantee or imply that the hardware purchased using this hardware sizing guide will solve your

unique business requirements. To improve the odds of success, we highly recommend that you

work with the Epicor Technical Solutions group and implement their hardware sizing

recommendations. Please use the Epicor Sizing Spreadsheet to further improve the accuracy of

your application load profile. You can download the Epicor Sizing Spreadsheet from EPICweb or

contact your Epicor representative who will be happy to provide you with the latest copy.

How to Use the Hardware Sizing Guide

The Hardware Sizing Guide is divided into sections to assist you through the sizing process. During the

hardware sizing process, the steps include:

1. User Count (Office + MES users)

2. Application Load Profile - Determine your application load profile (Standard, Medium, High

usage). To do this, go to the “Application Load Profiles” section.

3. Number of Epicor 9.05 Application Servers and Database Server Choice

* Epicor recommends physical Epicor 9.05 application servers and physical database server for

better performance

Locate the scenario section that is relevant to your environment. Depending on your user

count from step 1, environment preference, physical Epicor 9.05 application appserver or virtual

Epicor 9.05 application appserver, type of database (MS SQL Server / OpenEdge), go to the

respective sections titled with user count in the front:

Epicor 9.05 using Microsoft SQL Server 2008 R2 scenarios

Epicor 9.05 using OpenEdge Database scenarios

VMware vSphere scenarios

Microsoft Hyper-V scenarios

4. Locate the Hardware specifications. Review the hardware specifications of the servers which

are located in the “Server Hardware Sizing” section.

Here is an example:

In this example, the environment has the following specifications:

User Count - 35 users (Office + MES users)

Application Load Profile – typical manufacturing customer except they would prefer to run

MRP during busy times.

Number of Epicor 9.05 Application Servers and Database Server Choice - Epicor 9.05.700

using Microsoft SQL Server 2008 R2 database on a physical server configuration.


i. As this environment uses Epicor 9.05 on Microsoft SQL Server 2008 R2, physical appserver

and it has MRP use during busy times, then the “Application Load Profiles (Epicor 9.05

using Microsoft SQL 2008 R2)” section shows that the application load profile is LOAD03

– High.

ii. As this environment has 35 users, we will look at the [5-40 users] - Epicor 9.05 using

Microsoft SQL Server 2008 R2 scenario.

iii. Since the load is LOAD03 – High for this environment, we will look at the hardware

recommendations under the LOAD03 – High column.

iv. The column tells us that the example environment will require two APP01 application

servers and a SQLBOX02 SQL database server.

v. To find out the hardware specification for the APP01 application server, go to the Table

named APP01 (Epicor 9.05 application server). This environment will need two servers

with the APP01 hardware specification.

vi. To find out the hardware specification for the SQLBOX02 SQL database server, go to the

table named SQLBOX02 ([Medium] - Microsoft SQL Server 2008 R2 server). This

environment will need one SQL database server with the SQLBOX02 hardware

specification.

Important Comments

Be sure to tell your hardware vendor that you plan to use these machines as an ERP application

server and database server. The processing demands of a database server and application server

versus a file server are much different and your hardware vendor should adjust the recommended

configuration accordingly. Consider other factors such as manufacturer reliability, service, and

maintenance. These factors are extremely important if the machine runs into a hardware problem

and you are faced with downtime.

Expandability. You should consider expandability when choosing server(s). For example, if you

require multiple processors in the future, will the machine accept more processors? What if you find

out that your business practices requires extensive I/O – can you add more disks to your system or

add an external disk array? Can you add more RAM?

Database server cannot be scaled out. The available CPU resources on the SQL database server will

determine the room for growth in an Epicor 9.05 environment.

It is possible to add additional Epicor 9.05 application servers over time (scale out) as the

application usage load grows. SQL Server on the other hand cannot be scaled out; it can only be

scaled up (by adding additional resources to the server). If you are planning on growing your

environment and introducing additional heavy load in the future, then consider purchasing a server

with a motherboard that has four CPU sockets and leave two of them available for future growth.

This is a good insurance against having to replace the whole server if additional CPU resources are

required.

Deploy the supported version of software at all times. It is strongly recommended that you run fully

supported versions of software at all times. As a practical matter, Epicor cannot support or certify

releases for third party vendor software, such as Microsoft, or any other vendor software, that no

longer carries mainstream support from that vendor. In other words, when the vendor phases out its

support of a particular package, Epicor’s support for that same software package or version

generally ends as well.

Virtual Deployment of Epicor Applications. Virtualization is an abstraction layer that decouples the

physical hardware from the operating system to deliver enhanced IT resource utilization and

flexibility. There are various non-Epicor software products available that can be used to build your

virtual deployment. Epicor does not itself support or warrant these virtual environments or the Epicor

Software as used in the virtual environment. However, Epicor does and will continue to support its


own software to the extent that any issues (performance or otherwise) experienced in a virtual

environment can be reproduced by Epicor in a non-virtual environment.

When designing the virtual server infrastructure, please ensure that you are matching the virtual

machine’s specs with the hardware specifications mentioned in this guide. When matching

hardware specs with your virtual server machine you must make sure you are not interchanging

sockets with cores.

Each virtual machine instance consumes anywhere from 5-15% per virtual machine on the host

machine, depending on the host machine’s hardware. Please take that additional usage into

consideration as well.

See the following sections for details: “Epicor 9.05 using Microsoft SQL Server 2008 R2 on VMware

vSphere 5.0” or “Epicor 9.05 using Microsoft SQL Server 2008 R2 on Microsoft Windows Server 2008 R2

Hyper-V”.

Performance Tuning. Relational databases are advanced systems that sometimes require tuning for

optimal performance. One major selling point of both platforms is that the database engines are

largely self-tuning. However, it can still be useful to perform some level of tuning on a database

particularly in the area of database input/output operations to the physical disk subsystem. If

performed by an experienced professional, this tuning can substantially improve performance on

your hardware. Note that there are many considerations, outside of the scope of this guide, that are

involved in maintaining the server at peak performance.

Don’t run other Applications on Epicor Production application and database Server. Due to the

mission critical nature of any company’s Enterprise Resource Planning (ERP) system, it is

recommended that you have a server dedicated to running Epicor 9.05 production instance.

Running other applications including Test / Training / Pilot / development implementation of Epicor

9.05 application on the database and / or separate application server can degrade performance.

While certain situations may be suitable for dual hosting, it is strongly recommended that Epicor run

on a dedicated machine. Microsoft Small Business Server (SBS) is not a recommended platform for

Epicor due to the multi-application design of this product.

Where do we Run Test / Pilot / Training / Development Environments? These installations don’t require

a high end server like the one required for production environment and hence should be on a

separate and possibly less powerful server.

File Server Functions. The server machine for Epicor should not be used as a network file server

because file and print services require large amounts of resources. Using a single server for both file

and print services and your Epicor database will significantly reduce database performance.

SQL Server Licensing. When deciding on processors, note the SQL Server 2008 R2 licensing can be

processor dependent so factor that into the total performance vs. cost determination. We do not

recommend using CAL based licensing.

Spread I/O Load Across Multiple Disk Spindles. Once you have adequate RAM and CPU, focus on

the Disk Subsystem to improve performance. Generally, if you have the fastest disks then the more

disks in a RAID 10 the faster the READ / WRITE performance will be. Spreading the I/O load across

multiple physical RAID configurations also helps. Enterprise SSDs can greatly improve the I/O

subsystem performance.

Direct Network Connection Between the Application Server and Database Server. When you

separate the database server from the Epicor 9.05 Application Server, it has to be directly

connected with at least a 1 Gigabit network connection between the application and database

servers. If this condition is not met the application performance will suffer. We don’t want any

latency between them.

Disaster Recovery and High Availability. Unfortunately it is beyond the scope of this guide to cover

the details of this topic. Epicor Technical Solutions group is a great resource for this discussion and

they will be happy to work with you to design a DR and HA solution that suits your business needs.


Application Load Profile

The objective of this section is to help you determine the application usage load profile. For your

number of Office and MES users does your workload qualify as standard or medium or high usage?

Determining this will improve the odds of you purchasing the correct hardware to match your

unique business.

The key to any sizing project is to understand the types of workloads involved. Answering the

following questions will allow you to more accurately judge your server requirements:

What is your total number of users including office users, data collection users (MES users) and

any other software which will use the services of the Epicor 9.05 application server and / or

Epicor 9.05 database?

How many concurrent users will use your Epicor system? An Epicor 9.05 installation with higher

concurrent users requires more CPU, memory, network bandwidth and disk spindles to spread

the I/O load around.

What is your application usage pattern? Each customer’s application usage pattern is unique,

even if two customers have the same number of users and concurrency. Use the Table named

Application Load Profile in this section to guide you in the correct direction. You can also work

with the Epicor Technical Solutions group to determine an even better understanding of your

application usage pattern.

The hardware recommendations provided in this sizing guide assume a typical usage of the Epicor

9.05 application. We define typical usage in the following section. We also describe some

scenarios which will increase the demand on the hardware. If your installation has one or more of

those scenarios, then you will have to adjust the hardware specifications accordingly. Epicor

Technical Solutions is a great resource in helping you find hardware specifications that matches

your business needs.

What is Typical Usage and What Should You Avoid?

Typical Usage. The hardware recommendation provided in this guide should work for a wide variety

of customers. But it is also normal to expect that typical load assumes that during the very busy

times of the day or month the load on the server will be higher than usual. We expect the server’s

response to be slower than less busy times of the day. Unfortunately, we cannot anticipate what the

peak load for your business practice / application usage will be. If you find the server response

unacceptable, upgrade the appropriate component which is under pressure to remedy the

situation. It is important to choose a hardware architecture which allows for expandability. Epicor

Technical Solutions can also help you here.

Non-Typical usage that is not considered in the minimum hardware recommendations. The

following scenarios increase the resource utilization on a typical Epicor 9.05 installation:

Running large BAQs – Epicor 9.05 BAQs are powerful tools and can be used to query any

amount of data from the server. If your end user writes an inefficient query which retrieves lots

of records and has incorrect joins not supported by indexes, the BAQ will be a resource hog –

both on the Epicor 9.05 Application Server and the database server. The best solution is to test

and then deploy commonly used BAQs.

ODBC queries – Make sure your custom ODBC queries are efficient and are not share-locking

records on the database server. Share lock of records in a highly updated table will prevent

other users from updating that record and result in slow performance.

Running large reports / processes – If possible, schedule processes / reports which run for a

long time and consume a lot of resources to the less busy time of the day / week. If too many

large processes / reports / BAQs are running simultaneously on the server, then other users will

see a performance degradation specially if the hardware does not support this level of

concurrency.


Service Connect – If you have a high volume of transactions flowing through Service Connect

to the Epicor 9.05 application server, then consider using a dedicated application server for

this purpose. High volume Service Connect workflows that use multiple threads can generate a

lot of load on the receiving Epicor 9.05 Application Server and consequently the SQL database

server. Consider scheduling resource intensive work flows in a way so that they do not clash

with other resource intensive processes – like MRP and EDI.

In-house application / EDI work flow – The hardware guide cannot anticipate the load from

any in-house or 3rd party application that will use the services of Epicor 9.05 application server

and / or database. Please adjust your hardware guidelines accordingly.

Determine Your Unique Application Usage Pattern

These application load profiles represent an approximation of what a Standard, Medium and High

application load profile entails. It is recommended that you contact Epicor Technical Solutions for a

detailed application load sizing activity.

Please review the Application Load profiles table in this section, following are some points on how to

use this table to determine your application load profile. We are trying to find out for your number

of Epicor 9.05 licenses (Office + MES), what is the load profile – is it Standard or Medium or High.

- If all of the conditions under LOAD01 – Standard apply for your environment, then you have

the LOAD01 – Standard application load profile.

- If your environment has one of the below LOAD03 - High conditions, then your environment

is by default a LOAD03 – High application load profile environment:

o MRP during busy times

o 24/7 usage

o High number of Service Connect (ESC) / EDI work flow transactions during busy

times

Consider selecting a load profile one step above your current application load profile if you plan on

introducing additional load to the system.

For example, if you are currently at LOAD01 – Standard but plan on introducing a high number of

Service Connect (ESC) / EDI work flow transactions, then select the LOAD03 – High application load

profile.

Table: Application Load Profiles

These application load profiles represent an approximation of what a Standard, Medium and High

application load entails. This helps determine that for the same number of user count does your application

usage pattern equate to standard or high usage. It is recommended that you contact Epicor Technical

Solutions for a detailed application load sizing activity.

Application Load Profiles LOAD01 – Standard LOAD02 – Medium LOAD03 – High

Service Connect (ESC) / EDI

work flows

Consider volume and time

goals. Distribution.

Low number of

transactions and

during less busy

times

High number of transactions

and during less busy times,

for example off hours

High number of

transactions during

busy times

24 / 7 usage No No Yes

MRP (applies to

Manufacturing customers) During less busy

times, for example

off hours

During less busy times,

for example off hours

During busy times

Heavy financial reporting

and posting – i.e. several

concurrent running jobs

No Yes Yes


Customization (BPM, custom

code) No Yes Yes

In-house application

running on Epicor 9.05

database or utilizing Epicor

9.05 business logic on

application server

No Yes Yes

Growth and acquisition of

new users No No Yes

Seasonal peaks No No Yes


Server Hardware Sizing

Epicor 9.05 Application Server

Table: APP01

Table: APP01 Description

Operating System Windows Server 2008 R2 Standard Edition (2008 x64/x32 will also work)

Application Epicor 9.05 (with MS SQL 2008 R2 as the database)

Processors

2 x CPU sockets with at least Xeon Six-Core

Intel Xeon Westmere Six-Core recommendations:

3 GHz frequency (X5670 or faster. X5690 is highly recommended)

12MB L3 cache or more, QPI Speed of 6.4 GT/s

Intel Xeon Sandy Bridge Eight-Core recommendations (available Q2 2012):

2.9 GHz frequency (E5-2690 or faster)

20MB L3 cache or more

It is recommended to leave Hyper-Threading enabled (check BIOS settings).

Disable Power Saving options and C-States in BIOS. Enable Turbo Boost.

Memory (RAM) 32 GB DDR3-1066 (or faster) ECC

SSD - Solid State Drive

(SAS / SATA based)

storage

(recommended)

Operating system: 2 x 15k RPM HDDs in RAID 1

The following files are stored in 2 x SSDs in RAID 1:

Epicor 9.05 files (Epicor905)

Reports and temporary data (EpicorData)

Two SSDs are required.

Two SCSI / SAS HDDs are required.

Hard Disk Drive storage Operating system: 2 x 15k RPM HDDs in RAID 1

The following files are stored in 6 x 15k RPM HDDs in RAID 10:



Eight SCSI / SAS HDDs are required.

Network For good network performance, use 1 Gbit (or faster) network cards

To ensure that network latency is as low as possible between the Epicor

application server and the SQL database server, add at least two network cards:

One dedicated network card that is directly connected to the SQL

database

(Cable from network card to network card)

One dedicated network card that is connected to the LAN

(and is processing all network traffic except SQL database traffic)

Example server

make/model

HP DL380, Dell R710


[Standard] - Microsoft SQL Server 2008 R2 Server

Table: SQLBOX01

Table: SQLBOX01 Description

Operating System Windows Server 2008 R2 Standard Edition (2008 x64 will also work)

If you wish to utilize more than 32GB of RAM, then Enterprise Edition has to be

used.

Database Microsoft SQL Server 2008 R2 Standard Edition x64 recommended

(SQL Server 2008 x64 will also work)

Processors

2 x CPU sockets with at least Xeon Six-Core

Intel Xeon Six-Core recommendations:



Intel Xeon Sandy Bridge Eight-Core recommendations (available Q2 2012):


20MB L3 cache or more





storage

(SAS / SATA)

(recommended)


The following files are sharing 4 x SSDs in RAID 10:

SQL database

SQL transaction log

SQL tempdb

Four SSDs are required (6 Gbit/s S-ATA or SAS is recommended)


SQL Server is very write intensive and the SSD has to be able to accommodate

heavy writes (both from a performance and durability perspective). SLC-based

SSDs are recommended.

Contact Epicor Technical Solutions or your storage vendor for additional details on

how to design a solution that can accommodate the performance and durability

requirements that SQL Server has on the storage subsystem.


Solid State Drive

(PCI Express based)

(recommended)


The following files are sharing 2 x PCI Express SSD cards (for example Fusion-io) in

RAID 1:

SQL database

SQL transaction log

SQL tempdb

If you want to use a single PCI Express SSD card; then make sure that you have

redundancy in the form of database mirroring and/or log shipping.

A setup with two mirrored PCI Express SSD cards is recommended.

SLC-based cards are recommended.

Ensure that the bus interface (PCI Express) bandwidth supports the maximum

bandwidth (read/write) of the SSD card.

Hard Disk Drive storage


SQL database: 6 x 15k RPM HDDs in RAID 10

SQL transaction log: 2 x 15k RPM HDDs in RAID 1

SQL tempdb: 4 x 15k RPM HDDs in RAID 10

Fourteen SCSI / SAS HDD are required


how to design a solution that can accommodate the performance requirements

that SQL Server has on the storage subsystem.

Existing Storage Area

Network (SAN) To find out if your SAN delivers sufficient performance, see the “Testing

Performance of an Existing SAN” section in the Appendix for details on how to run

a storage benchmarking tool (SQLIO).

Required SQLIO results:

Database drive letter (location of SQL mdf file):

Must be able to deliver at least 50MB/sec at a latency of less than 5ms.

Transaction log drive letter (location of SQL log file):


Tempdb drive letter (location of SQL temp db file):


Network For good network performance, use 1 Gbit (or faster) network cards.

To ensure that network latency is as low as possible between the SQL database

server and the Epicor application server(s); add one dedicated network card for

each Epicor application server.

The Epicor application server(s) should then be directly connected to the SQL

database server - cable from network card to network card.

An example:

If the environment has two Epicor application servers, then the SQL database

should have at least three network cards:

One dedicated network card per connected Epicor application server

One network card for general LAN connectivity.


Example server

make/model HP DL380, Dell R710


[Medium] - Microsoft SQL Server 2008 R2 Server

Table: SQLBOX02


Operating System Windows Server 2008 R2 Standard Edition (2008 x64 will also work).

If you wish to utilize more than 32GB of RAM, you must use Enterprise Edition.



Processors

2 x CPU sockets with Xeon Ten-Core in a four-socket server

Please refer to “Database server cannot be scaled out” in General Comments

section.

Note: If your current expected load is at the SQLBOX02 level and you are

considering introducing additional heavy load which could require a SQLBOX03

server; then consider purchasing a four-socket server and leave two of the CPU

sockets available for future growth. This is a good insurance against having to

replace the whole server if additional CPU resources are required.

Intel Xeon Ten-Core recommendations (for four-socket server motherboard):





Memory (RAM) 32 GB DDR3-1066 (or faster) ECC or more


storage

(SAS / SATA)



SQL database

SQL transaction log

SQL tempdb

Four SSDs are required.









Solid State Drive

(PCI Express based)

(recommended)



RAID 1:

SQL database

SQL transaction log

SQL tempdb











Twenty SCSI / SAS HDD are required













Tempdb drive letter (location of SQL temp db):








An example:



One dedicated network card per connected Epicor application server.

One network card for general LAN connectivity


Example server



[Large] - Microsoft SQL Server 2008 R2 Server

Table: SQLBOX03


Operating System Windows Server 2008 R2 Enterprise Edition (2008 x64 will also work)



Processors

4 x CPU sockets with Xeon Ten-Core in a four-socket server.

Please refer to note Database server cannot be scaled out in General comments

section.






Memory (RAM) 64 GB DDR3-1066 (or faster) ECC or more.


(SAS / SATA based)

storage



SQL database

SQL transaction log

SQL tempdb

Six SSDs are required.









Solid State Drive

(PCI Express based)

(recommended)



RAID 1:

SQL database

SQL transaction log

SQL tempdb











Forty SCSI / SAS HDD are required.













Tempdb drive letter (location of SQL temp db file):








An example:



One dedicated network card per connected Epicor application server.

One network card for general LAN connectivity.


Epicor 9.05 Using Microsoft SQL Server 2008 R2 Scenarios

[5-40 users] - Epicor 9.05 using Microsoft SQL Server 2008 R2

* See the “Application Load Profile” section for details.

Example server


These recommendations represent an approximation of the required hardware to support an implementation based on

the application load profile.

For more detailed recommendations; contact Epicor Technical Solutions and they can help you design the best

hardware configuration to run your business.

Application Load

Profile * LOAD01 – Standard * LOAD02 – Medium * LOAD03 – High

Number of Epicor

9.05 application

servers

(See Table: APP01 for

hardware details)

1 x APP01 1 x APP01 1 x APP01 (Interactive)

1 x APP01 (Reporting)

Total: 2 x APP01

SQL database server SQLBOX01 (see table) SQLBOX01 (see table) SQLBOX02 (see table)








Application Load


Number of Epicor

9.05 application

servers


hardware details)

1 x APP01 1 x APP01 (Interactive)


Total: 2 x APP01

1 x APP01 (Interactive)


1 x APP01 (SC / EDI)

Total: 3 x APP01







For more detailed recommendations contact Epicor Technical Solutions and they can help you design the best


Application Load


Number of Epicor

9.05 application

servers


hardware details)

1 x APP01 1 x APP01 (Interactive)

2 x APP01 (Load

balanced - Reporting)

Total: 3 x APP01



2 x APP01 (SC / EDI)

Total: 5 x APP01



[1000 users] - Epicor 9.05 using Microsoft SQL Server 2008 R2


the LOAD01 – Standard application load profile (See table in “Application Load Profile” section).

Contact Epicor Technical Solutions if your workload is at fits any of the LOAD02 – Medium or LOAD03 – High application load profiles ( See table in “Application Load Profile” section).



Microsoft SQL Server

2008 R2 1000 users, application usage profile: Standard

Number of Epicor 9.05

application servers (See

Table: APP01 for

hardware details)

Epicor 9.05 is a stateless application so it is possible to add additional Epicor 9.05

application servers as the load grows.

Note that the SQL database server cannot be scaled out – it can only be scaled

up (by adding additional CPUs / RAM).



Total: 4 x APP01

Create two load balanced pools (Interactive and Reporting) of application

servers.

If needed, you can create an additional pool for Service Connect / EDI.

A hardware load balancer is recommended.

SQL database server

SQLBOX3 is the recommended choice if the load profile is LOAD01 – Standard.

CPU:

The available CPU resources on the SQL database server will determine the room

for growth in an Epicor environment.

It is possible to add additional Epicor 9.05 application servers over time (scale

out) as the load grows.

SQL Server cannot be scaled out; it can only be scaled up (by adding additional

hardware resources to the server).

If your current expected load is at the LOAD01 – Standard level and you are

considering introducing additional heavy load (growing to LOAD02 – Medium or

LOAD03 – High) which could require additional CPU resources; then consider

purchasing an eight-socket server and leave four of the CPU sockets available for

future growth. This is a good insurance against having to replace the whole server

if additional CPU resources are required.

Intel Xeon Ten-Core recommendations (for eight-socket server motherboard):




Storage:

PCI Express-based SSD storage is recommended (for example Fusion-io).

SLC-based SSDs are recommended.


Epicor 9.05 Using OpenEdge Database Scenarios

[5-40 users] - Epicor 9.05 Using OpenEdge Database

These recommendations represent an approximation of the required hardware to support an implementation based on the LOAD01 – Standard application load profile (See table in “Application Load Profile” section).



OpenEdge Database Small 5-40 Users

(Office + Data Collection)

Operating System • Windows Server 2008 R2 Standard Edition (2008 x64/32 will also work)

• Linux ES 3.0 (32-bit)

• Unix HP/UX 11 (32-bit or 64-bit)

Processors

2 x CPU sockets with at least Xeon Six-core.


3 GHz frequency (X5670 or faster)



Disable Power Saving options and C-States in BIOS.


Solid State Drive (SAS /

SATA based) storage

(recommended)


The following files are stored in 2 x SSD in RAID 1:



OpenEdge database files

OpenEdge database bi files

Two SSDs are required.



Hard Disk Drive storage Operating system: 2 x 15k RPM HDDs in RAID 1.

The following files are stored in 4 x 15k RPM HDD in RAID 10:






Consider separate partition for Epicor 9.05 reports.

Eight SCSI / SAS HDDs are required.

Network 1 Gbit or faster


[41-150 users] - Epicor 9.05 Using OpenEdge Database

Example server






OpenEdge Database Medium - 41-150 Users


Operating System • Windows Server 2008 R2 Standard Edition (2008 x64/x32 will also work).

If you wish to utilize more than 32GB of RAM, Enterprise Edition must be used.



Processors


The available CPU resources on the OpenEdge database server will determine the

room for growth in an Epicor environment.

It is possible to add additional application servers over time (scale out) as the

load grows. For example you may want to add an application server for reporting

purpose.

OpenEdge database server cannot be scaled out; it can only be scaled up (by

adding additional resources to the server). If you are planning on growing your

environment and introducing additional heavy load in the future, then consider

purchasing a server with a motherboard that has four CPU sockets and leave two

of them available for future growth. This is a good insurance against having to









SATA based) storage

(recommended)


The following files are stored in 4 x SSD in RAID 10:





Four SSDs are required.












Sixteen SCSI / SAS HDDs are required.


Example server



[151–300 users] - Epicor 9.05 Using OpenEdge Database





OpenEdge Database Large - 151 – 300 Users


Operating System • Windows Server 2008 R2 Standard Edition (2008 x64/x32 will also work).




Processors


The available CPU resources on the OpenEdge database server will determine the

room for growth in an Epicor environment.

The OpenEdge database server cannot be scaled out; it can only be scaled up

(by adding additional hardware resources to the server).

Note: If your current expected load is at a two-socket CPU level and you are

considering introducing additional heavy load which could require a four-socket

server; then consider purchasing a four-socket server and leave two of the CPU

sockets available for future growth. This is a good insurance against having to



2.4 GHz frequency (E7-4870 or faster).

30MB L3 cache or more, QPI Speed of 6.4 GT/s.



Note: Add 1 additional Epicor 9.05 application server for reporting and ESC / EDI

processing needs. Keep interactive Epicor 9.05 application server on the same

server as OpenEdge database. This step should be taken in consultation with

Epicor Technical Solutions group.


Solid State Drive

(SAS / SATA based)

storage

(recommended)







Six SSDs are required.












Thirty-two SCSI / SAS HDDs are required


Example server



[300+ users] - Epicor 9.05 Using OpenEdge Database



For more detailed recommendations; contact Epicor Technical Solutions and they can help you design the

best hardware configuration to run your business.

OpenEdge Database Large – 300+ Users


Operating System • Windows Server 2008 R2 Standard Edition (2008 x64/x32 will also work)




Processors


Consider splitting the Epicor application server and OpenEdge database server.






Add additional Epicor 9.05 application server for reporting and EDI / ESC

processing needs. Keep interactive Epicor 9.05 application server on the same

server as the OpenEdge database. This step should be taken in consultation with

Epicor Technical Solutions group as they will be able to advice you if you need

one or more Epicor 9.05 application servers for reporting and EDI / ESC

processing.

Memory (RAM) 32 GB DDR3-1066 (or faster) ECC or more

Storage (PCI Express SSD

option and SAS / SATA

SSD option)

PCI Express SSD option:


The following files are stored in 2 x PCI Express SSD cards (for example Fusion-io)

in RAID 1:





SAS / SATA SSD option:








Network 1Gbit or faster. Dedicated network connection (cable from network card to

network card) from application server to OpenEdge database server.


Epicor 9.05 Using MS SQL Server 2008 R2 on VMware vSphere 5.0

Epicor 9.05 VMware Virtual Application Server

Table: VMWAREAPP01

Example server


Table: VMWAREAPP01 Description

Host software VMware vSphere 5.0

Guest OS Windows Server 2008 R2 Standard Edition (2008 x64/x32 will also work)

Application Epicor 9.05 (with Microsoft SQL 2008 R2 as the database)

Virtual CPU count 4 virtual CPUs

Create a full CPU reservation to ensure that the virtual machine has dedicated

access to physical CPU cores.

It is not recommended to overcommit CPU resources.

Memory (RAM) 12 GB (reserved RAM)

It is not recommended to overcommit memory resources.

If needed, disable Memory Ballooning so that the virtual application server has

a dedicated amount of RAM.

Ensure that the RAM on the host supports ECC.

Physical CPU requirements

(host requirements) It is recommended that the virtualization host has one of the following CPUs:



Intel Xeon Ten-Core recommendations (for two-socket server motherboard):




Ensure that VT-x and EPT are supported and enabled.



Virtual hard disk Use Thick Provisioning and ensure that Eager Zeroing is in use.

Enable Storage I/O Control (SIOC) and set the threshold to 25ms.

Virtual hard disk controller Use the Paravirtual SCSI adapter.

Guest OS virtualization

software Install and use the latest VMware Tools.

Network Ensure that the physical host has multiple physical network cards which are all

utilized by the hosted virtual machines.

Use the VMXNET3 virtual network card.


[10-20 users] - Epicor 9.05 Using MS SQL Server 2008 R2 on VMware vSphere 5.0

Note: Users in 0-20 user range should consider the Epicor Express product.


Load balancing Physical load balancing appliance recommended. Software based works too.

Use Multicast Mode if you are using Microsoft Network Load Balancing (NLB).

This is recommended for stability reasons.

Backup software Image-level (snapshot) backups are not supported.

File-level backups are supported.

These recommendations represent an approximation of the required resources to support an implementation based on




Application Load


Number of Epicor

9.05 application

servers (See Table:

VMWAREAPP01 for

configuration details)

1 x VMWAREAPP01

(Interactive)

1 x VMWAREAPP01

(Reporting)

Total: 2 x

VMWAREAPP01

1 x VMWAREAPP01

(Interactive)

2 x VMWAREAPP01

(Load balanced -

Reporting)

Total: 3 x VMWAREAPP01

2 x VMWAREAPP01

(Load balanced -

Interactive)

2 x VMWAREAPP01

(Load balanced - Reporting

/ SC / EDI)



Hard Disk Drive

storage Place the .vmdk files on

a RAID 10 partition with

at least four 15k RPM

disks

Place the .vmdk files on



disks

Place the .vmdk files on a

RAID 10 partition with at least

four 15k RPM disks

Solid State Drive (SAS

/ SATA based)

storage

(recommended)



at least two SSDs


a RAID 1 partition with at

least two SSDs



two SSDs








Application Load


Number of Epicor

9.05 application

servers (see Table:

VMWAREAPP01 for


2 x VMWAREAPP01

(Load balanced -

Interactive)

2 x VMWAREAPP01

(Load balanced -

Reporting)

Total: 4 x

VMWAREAPP01

2 x VMWAREAPP01

(Load balanced -

Interactive)

3 x VMWAREAPP01

(Load balanced -

Reporting)


3 x VMWAREAPP01

(Load balanced -

Interactive)

5 x VMWAREAPP01

(Load balanced – Reporting

/ SC / EDI)



Hard Disk Drive




disks


a dedicated RAID 10

partition with at least four

15k RPM disks


dedicated RAID 10 partition

with at least six 15k RPM disks


/ SATA based)

storage

(recommended)



at least two SSDs



least two SSDs



two SSDs








Application Load


Number of Epicor

9.05 application

servers (see Table:

VMWAREAPP01 for


3 x VMWAREAPP01

(Load balanced -

Interactive)

3 x VMWAREAPP01

(Load balanced -

Reporting)

Total: 6 x

VMWAREAPP01

4 x VMWAREAPP01

(Load balanced -

Interactive)

4 x VMWAREAPP01

(Load balanced -

Reporting)


5 x VMWAREAPP01

(Load balanced -

Interactive)

5 x VMWAREAPP01


/ SC / EDI)



Hard Disk Drive


a dedicated RAID 10

partition with at least

four 15k RPM disks


a dedicated RAID 10

partition with at least six

15k RPM disks



with at least eight 15k RPM

disks


/ SATA based)

storage

(recommended)



at least two SSDs



least two SSDs



two SSDs


Epicor 9.05 Using MS SQL Server 2008 R2 on MS Windows Server 2008 R2 Hyper-V

Epicor 9.05 Hyper-V Virtual Application Server

Table: HYPERVAPP01

Table: HYPERVAPP01 Description

Host software Microsoft Windows Server 2008 R2 with Hyper-V role

Guest OS Windows Server 2008 R2 Standard Edition (2008 x64/x32 will also work).

Application Epicor 9.05 (with Microsoft SQL 2008 R2 as the database)

Virtual CPU count 4 virtual CPUs

Create a full (100%) virtual machine reserve to ensure that the virtual machine has

dedicated access to physical CPU cores.

It is not recommended to overcommit CPU resources.

Memory (RAM) 12 GB (reserved RAM)

Select Static memory when you allocate memory to the virtual machine.

It is not recommended to overcommit memory resources.

Ensure that the RAM on the host supports ECC.

Physical CPU (host)

requirements It is recommended that the virtualization host has one of the following CPUs:







Ensure that VT-x and EPT are supported and enabled.



Virtual hard disk Use Fixed Size virtual hard disks.

Virtual hard disk

controller Use the IDE Controller option for the virtual hard disk that contains the OS.

Use the SCSI Controller option for all other virtual hard disks.

Guest OS virtualization

software Install and use the latest Integration Services.

Network Use the Network Adapter virtual network card (and not the Legacy Network

Adapter).

Load balancing Physical load balancing appliance recommended. Software based works too.

Use Multicast Mode if you are using Microsoft Network Load Balancing (NLB). This

is recommended for stability reasons.


[10-20 users] - Epicor 9.05 using MS SQL Server 2008 R2 on MS Windows Server 2008 R2 Hyper-V

Note: Users in 0-20 user range should consider the Epicor Express product.


Backup software Image-level (snapshot) backups are not supported.

File-level backups are supported.





Application Load


Number of Epicor

9.05 application

servers (see Table:

HYPERVAPP01 for


1 x HYPERVAPP01

(Interactive)

1 x HYPERVAPP01

(Reporting)

Total: 2 x HYPERVAPP01

1 x HYPERVAPP01

(Interactive)

2 x HYPERVAPP01

(Load balanced -

Reporting)


2 x HYPERVAPP01

(Load balanced -

Interactive)

2 x HYPERVAPP01

(Load balanced - Reporting

/ SC / EDI)



Hard Disk Drive

storage Place the .vhd files on a

RAID 10 partition with at

least four 15k RPM disks

Place the .vhd files on a



Place the .vhd files on a RAID

10 partition with at least four

15k RPM disks


/ SATA based)

storage

(recommended)



least two SSDs



least two SSDs


1 partition with at least two

SSDs


[21-49 users] - Epicor 9.05 Using MS SQL Server 2008 R2 on MS Windows Server 2008 R2 Hyper-V






Application Load


Number of Epicor

9.05 application

servers (see Table:

HYPERVAPP01 for


2 x HYPERVAPP01 (Load

balanced - Interactive)


balanced -

Reporting)


2 x HYPERVAPP01

(Load balanced -

Interactive)

3 x HYPERVAPP01

(Load balanced -

Reporting)


3 x HYPERVAPP01

(Load balanced -

Interactive)

5 x HYPERVAPP01


/ SC / EDI)



Hard Disk Drive





dedicated RAID 10

partition with at least four

15k RPM disks



with at least six 15k RPM disks


/ SATA based)

storage

(recommended)



least two SSDs



least two SSDs



SSDs


[50-100 users] - Epicor 9.05 Using MS SQL Server 2008 R2 on MS Windows Server 2008 R2 Hyper-V






Application Load


No of Epicor 9.05

application servers

(see Table:

HYPERVAPP01 for





balanced -

Reporting)



balanced -

Interactive)


balanced - Reporting)





balanced – Reporting / SC /

EDI)



Hard Disk Drive


dedicated RAID 10

partition with at least

four 15k RPM disks


dedicated RAID 10

partition with at least six

15k RPM disks



with at least eight 15k RPM

disks


/ SATA based)

storage

(recommended)



least two SSDs



least two SSDs



SSDs


Other Hardware Requirements

Epicor Client Machine / Epicor Workstation

For desktop / network clients, keep in mind that other installed applications, specifically Microsoft

products, have requirements of their own over and above the requirements for Epicor 9.05. The

Epicor client will perform better on workstations that have sufficient memory and processor power to

run all your applications.

(*) The Epicor 9.05 and Vista Service Pack will run Windows Vista Business Edition 64-bit version by

using the Microsoft Windows-32-bit-on-Windows-64 (WOW64) subsystems. WOW64 is an x86 emulator

that allows 32-bit-bit Windows-based applications to run on 64-bit Windows.

Windows Vista / 7

Business Edition

Network Workstation

Recommended Configuration

Operating System Windows 7 Professional

OR Windows Vista Business Edition

(32-bit or 64-bit*)

Processor 2.8 GHz or higher. Recommended dual core 32-bit or 64-bit processor and

SATA hard drives. SSD is especially beneficial if the workstation runs

multiple applications at the same time.

RAM 4 GB

Disk Space for Epicor 2 GB

Monitor SVGA or higher adapter

Color SVGA monitor with 1024 X 768 resolution

DVD-R DVD-R drive (if not on server)

Other Internet connection recommended for online support and downloading

latest updates. Fast network connection recommended between client

and Epicor 9.05 Application Server. Epicor 9.05 application will work on

slower networks but the performance will be better if you have a fast

connection with low latency.


Remote Desktop Services

Each Remote Desktop Services server can accommodate 25 users adequately.

Microsoft Remote

Desktop Services Up to 25 Users



Processor 2 x CPU sockets with at least Xeon Six-Core.




2 GHz frequency (E7-2850 or faster)





Memory (RAM) 32 GB or more


SATA based) storage

(recommended)

2 x SSDs in RAID 1

Hard Disk Drive storage 6 x 15k RPM SCSI / SAS Drives in RAID 10

Free Disk Space 20GB Minimum



Epicor Web Access (EWA)

Epicor Web Access



Browsers supported Supported Browsers and versions - Internet Explorer - Internet Explorer 8 (and IE

9 in compatibility mode), Mozilla Firefox – Firefox 3.5.X (use latest patch and

follow setup details in the installation guide), Apple Safari - Safari 4.0.X (use

latest patch) and Chrome.

Supported Mobile Browsers and versions - Apple Safari - Safari 3.2 (iPhone),

Blackberry Browser 4.6 and Chrome (Android)

Web Printing support Windows Server 2008 / 2008 R2

Processor 1 x CPU socket per 30 concurrent users









Note: Epicor Web Access generates additional load on Epicor 9.05 Application

Server. If you have a high volume of transactions flowing through Epicor Web

Access to the Epicor 9.05 application server, then consider using a dedicated

Epicor 9.05 application server for this purpose. High usage of Epicor Web Access

will result in higher load on the receiving Epicor 9.05 application server and

consequently on the database server.

Memory (RAM) 16 GB per 30 concurrent users


SATA based) storage

(recommended)

2 x SSDs in RAID 1




Enable Static and/or Dynamic IIS Compression if your CPU utilization permits.


Epicor Service Connect (ESC)

Hardware for Other Epicor Systems

Epicor Service

Connect


Processor 1 x CPU socket with at least Xeon Quad-Core



Note: Epicor Service Connect generates additional load on Epicor 9.05

Application Server. If you have a high volume of transactions flowing through

Service Connect to the Epicor 9.05 application server, then consider using a

dedicated Epicor 9.05 application server for this purpose. High volume Service

Connect workflows that use multiple threads can generate a lot of load on the

receiving Epicor 9.05 application server and consequently on the database

server.

Memory (RAM) 8 GB




This table is meant to list other Epicor or 3rd party software that might need

additional server hardware. It is beyond the scope of this guide to spec

out in detail what those hardware requirements will be. We are listing

commonly used systems here so that you can plan for additional

hardware procurements.

Epicor Replication For hardware specs, please contact Epicor Technical Solutions group

EPM For hardware specs, please contact Epicor Technical Solutions group

AFR, Info worker, Enterprise

Search, Activity Stream, E9

Portal, Open4, Insite Manifest

For hardware specs, please contact Epicor Technical Solutions group

PLM , IQS For hardware specs, please contact Epicor Technical Solutions group

Hardware for any other

Epicor or 3rd party software

purchased through Epicor?

If you have purchased any other software license from Epicor, please work

with the Epicor Technical Solutions group to see if you need extra servers

to run them. Some applications can be installed on one shared server.


Handheld Equipment

Device Requirements

Screen size minimum of 240 x 320

Device must support MS Terminal Services client

IEEE 802.11 Radio Frequency standards support

Access Points

IEEE 802.11 Radio Frequency standards support

Barcode Equipment

Support for Bar 39 Barcode

MES Workstation

PioneerPOS Stealth M5

Same configuration as Epicor workstation

Communications

An Internet connection is required to access the Epicor Online Support Center for interim and

commercial releases and remote support.

DSL or higher quality connection recommended.

Internet Explorer 7.0 or higher is needed for Epicor Help.

Printer

At least one laser printer required for standard reports and forms

Must have current Windows drivers

Backup Equipment

Epicor recommends your company invest in a reliable backup system. Your hardware vendor can

recommend and install one for you.


Network

Hardware Recommendations

A 1 Gbit (or faster) network is recommended.

Fiber optic cable is recommended in environment with electrical noise.

When designing network, try to minimize the ping time / latency between the Epicor 9.05 client

workstations and the Epicor 9.05 application server box. For example users having a 125ms ping

time will see slower response than the users having a ping time of 25ms between the workstation

and the application server box.

If you have users in remote sites, consider placing a Remote Desktop Services (RDS) server on the

same location (same LAN) as the Epicor 9.05 server. Instead of running the Epicor 9.05 client locally

and connecting to the Epicor 9.05 server over a WAN, users can access the client on a Remote

Desktop session. This improves performance as the Epicor 9.05 server and Epicor 9.05 client are both

on the same LAN.

WAN accelerator - Consider implementing WAN accelerators on both sides of a WAN if you have

environments with high latency and/or low bandwidth.

Network Bandwidth

The bandwidth of a network defines the amount of data that can be transferred across the network

at once. If the bandwidth of the network is insufficient for the amount of information being

transmitted (usually because too many users are on a single network segment), performance drops

noticeably. In these cases, the network will need re-configuring to lower the amount of traffic or

increase the bandwidth of the network. Traditional hubs are being replaced by high-speed data

switches, which further help alleviate network bottlenecks. Multiple server network cards and

automated load balancing may be considered too.

Network bandwidth is not the only factor that determines the "speed" of a network as perceived by

the end user. The other key element of network performance is latency. While it would often appear

that data is transmitted instantly between one point and another (that is, with no delay at all), this is

typically not the case. Network latency may be caused by:

The time it takes for a packet to travel from point to point

The transmission medium (optical fiber, wireless, etc.) may introduce some delay because larger

packets typically take longer to move from place to place

Routers and other processing points each take time to examine and possibly make changes to

packet header

Intermediate devices such as switches and bridges may cause delays

It is often difficult to diagnose a network bandwidth or latency issue and this is best handled by

professional network analysts.

As a general rule, the Epicor client has a bandwidth requirement of 10 Kbps (kilobits per second) to

500Kbps. This will vary depending on the volume of data transferred between the client and the

server. Additionally, file attachments require increased bandwidth.

A simplified rule of thumb for the number of clients to connect per network segment is to determine

the worst-case acceptable throughput for each network client, then divide that amount into the

selected network throughput. For example, if each client should have no less than 1.5 Mbps of

available bandwidth, and the network supports 100 Mbps, the segment could possibly support 66


clients. Unfortunately this simple calculation does not take into account the network latency,

network media characteristics, or network traffic in addition to Epicor, but it does provide for a good

starting point for the maximum amount of clients per network segment.


Appendix

Testing Performance of an Existing SAN

If you have an existing SAN and want to ensure that it can deliver good performance, then you can

run a Microsoft storage benchmark utility called SQLIO.

The following tests are designed to test various aspects of an I/O disk subsystem i.e. bandwidth

(Mega Bytes/second i.e. MB/Sec), Latency (milliseconds), performance of your I/O system with

desired block size (64KB) and file size and type of I/O – read or write and sequential v/s random

writes. The parameters described in previous statement have a great impact on IOPS and hence

they are specified exactly as needed here for testing using SQLIO. On the same machine you will

get different IOPS number if you change any one parameter. So testing with Epicor recommended

parameters is highly recommended.

Download SQLIO from: http://www.microsoft.com/download/en/details.aspx?id=20163

Instructions: The default install path on a 64-bit OS for SQLIO is C:\Program Files (x86)\SQLIO\

In the SQLIO install path, the configuration file called param.txt determines which drive letter SQLIO

will test.

If you want to test the D-drive letter, then change the param.txt content to the following:

D:\testfile.dat 2 0x0 80000

Steps to run each test:

1. Open up a Windows Command Prompt on the server that you installed the SQLIO utility. For example

START > RUN > CMD, this opens up the Command window.

2. Change directory to the SQLIO folder, e.g. C:\users\admin>CD C:\Program Files (x86)\SQLIO

3. Run 3 tests below using specified parameters on each drives. Each test requires 80 Gig of free space

on the respective drive.

4. Compare results - Refer Server Hardware Sizing, specs for SQLBOX01, SQLBOX2 and SQLBOX03

(depending on what SQL box you need) - SAN section. There you will find exactly how many Mega

Bytes / Sec we expect with 5ms or better latency. For OpenEdge db you need 100 MB/sec with 5ms or

better latency.

Test 1: Database (.mdf) drive letter

(In case of OpenEdge database you can test the drive which will host d1 file i.e. data / extent

file(s)):

This test will test 64k random writes.

Modify the param.txt file so that it points to the database drive letter and then run the following

command:

sqlio -kW -t8 –s900 -o8 -frandom -b64 -BH -LS -Fparam.txt

Test 2: Transaction log (.ldf) drive letter

(In case of OpenEdge database you can test the drive which will host the bi file):

This test will test 64k sequential writes.

Modify the param.txt file so that it points to the transaction log drive letter and then run the

following command:

sqlio -kW -t2 –s900 -dM -o8 -fsequential -b64 -BH -LS –Fparam.txt

http://www.microsoft.com/download/en/details.aspx?id=20163


Test 3: Tempdb drive letter:

This test will test 64k random writes.

Modify the param.txt file so that it points to the tempdb drive letter and then run the following

command:

sqlio -kW -t8 –s900 -o8 -frandom -b64 -BH -LS -Fparam.txt


Sizing Processor the CPU(s)

The primary object when sizing the model and number of CPU’s is related directly to the type of

workload, the number of users (peak load) and the expected volume of transactions for your Epicor

system. These key variables determine the overall demand that will be placed on the database

server. The typical rule of thumb is to configure the fastest CPU that is economically feasible.

Business requirements and the resources needed to support server-based applications are

constantly increasing. Therefore, starting with the fastest possible CPU and a server architecture that

can support multiple CPUs provides better long-term investment protection.

Windows Server 2008 x64 / 2008 R2 are both multi-process and multi-threaded enabled operating

systems. Without any real applications running under Windows, there are multiple active processes

and threads. Thus, additional CPUs are normally helpful to a degree. Also, consider that both the

Progress database and SQL Server 2008 R2 are designed for a Symmetric Multi-Processing (SMP)

environment and that the Epicor application is multi-threaded and will scale to multi processors

when present. Epicor would recommend starting with at least a Quad-Core processor server with a

large amount of L3 cache.

Configure enough CPU resources to drive all of the server’s resources. Develop the server

configuration such that the CPU is “fed”. This is achieved by ensuring there is enough CPU cache,

main memory (RAM), and I/O channels for the disk and network devices. Windows Server 2008 x64 /

2008 R2 and other servers can easily be slowed by its weakest component in the data path that is

not providing the data requested by the CPU.

For optimal performance, configure the CPUs in the following way:

Enable Hyper-Threading

Disable Power Saving settings including C-States (in BIOS)

Enable Turbo Boost

Growth Path. If you have empty CPU sockets on your server’s mother board, consider adding extra

CPUs to satisfy demands on your Epicor 9.05 installation put by concurrent users. Epicor 9.05

architecture allows for splitting the application and database on to separate servers. You can also

add multiple application server machines to allow for your growth.


Sizing Memory Requirements (RAM)

This section is provided to give you an idea of how we calculate how much RAM is required. The

steps provided here are for users whose application usage pattern is totally unpredictable and does

not match the scenarios we provided earlier in the guide. The RAM we have specified in the

hardware sizing tables that matches your user count and application load profile supersedes if it

exceeds the calculation you determine from this section.

For a starting point, be sure you take into consideration the following:

All applications that the application server and / or database server is running

Windows 2008 x64 / 2008 R2 Server requirements

Windows 2008 x64 / 2008 R2 Server File System Cache use

The number of concurrent Epicor users supported by the system

The amount of server resources configured (CPU, Disk, Network, etc.)

Performance expectation - for most environments, larger amounts of RAM will yield higher

levels of overall performance

For Progress database systems, the database can be buffered into memory for faster

performance. Progress recommends using ⅓ to ½ your server’s RAM for this

Budget 400 MB to ½ Gig of RAM for each AppServer agent. Typically 10 AppServer agents

are required to server 40 users.

Each database will have at least 10 and possibly more than 25 AppServer agents,

depending on the number of concurrent users

Growth Path for RAM: The above mentioned requirements suggest a starting memory size for the

server of at least 16 GB of RAM. When purchasing RAM, consider future upgrade options and the

RAM limit for your server’s operating system.

Example, Memory (RAM) Configuration (40 Users)

Operating System = 1.5GB

10 Epicor 9.05 AppServer agents running per 40 users @ 0.4 GB per AppServer agent = 4 GB

per 40 users

Database Cache allowance = 2.0 GB

Total = ~8 GB

Each Additional 40 Users

Additional 4GB for 10 Appserver agents

Additional 2GB assumption for larger database

Total 6.0GB


Disk System – Sizing, Configuration and RAID

Sizing Disk Subsystem

There are three primary areas to consider when sizing the disk sub system.

Capacity

Availability

Performance – RPM and multiple spindles writing at once in a RAID configuration to

increase the read / write performance

Consider each of these factors jointly when configuring your I/O system.

How Much Disk Capacity?

Capacity is the initial concern for the disk subsystem, but too often its relationship to availability and

performance are not taken into consideration. Capacity is the easiest resource to calculate. The

size of your Epicor database will depend on the number of users and their transaction volume. In

general, Epicor databases range from 300 MB for smaller systems to over 200 GB for larger systems.

Consider that many customers use training databases in addition to a production database. You

may also have the requirement to evaluate a new version of Epicor in a test environment prior to

upgrading your production database.

What Types of Drives Should I Purchase?

Always select the fastest drives and disk adapter technology available within your budget.

For best performance, select SCSI Ultra-Fast/Wide Disk Adapters, Ultra-Fast/Wide Disk Drives or Serial

Attached SCSI (SAS) rotating at 15,000 rpm. Select a higher value of disk buffer size like 16 or 32 MB

or more.

Enterprise SSD is a good choice especially for the SQL database server.

How Do I Protect My Data?

Availability is the concept that your data is important enough to require some level of protection

while keeping the cost of the server within your budget. Protecting your data is the most important

consideration. There are many ways to protect your data from potential disaster, which include

backups, security software, and hardware protection. For this discussion we will focus on hardware

protection, and more specifically Redundant Array of Independent Disks (RAID). See the “Fault

Tolerant RAID Configurations” section for additional details.

Backups – see separate section

READ and WRITE Cache

Systems that contain a large READ disk cache within the controller can dramatically improve the

performance of the application server. This option is relatively inexpensive when purchased with the

overall system and therefore is recommended, particularly for larger implementations. WRITE caches

can cause integrity issues under extremely rare and complex circumstances. Most caches can be

configured easily enough to avoid this rare issue by turning off the write cache.


System Drive Configuration (Spread I/O Load to Gain Performance)

The number of drives you purchase and how you decide to configure them depends on your

budget, the intensity of your transactions, the desired performance and the need for fault

tolerance. Your budget determines the number and speed of the disks you can afford. The intensity

of transactions predicts what disk I/O you will need.

Note that the SQL database servers’ storage subsystem requires the best possible I/O performance

as it is a very important factor when it comes to the performance of the environment.

Remember that the disk size is often not the critical factor but rather the speed in writing and

reading to the drives. Therefore, more drives mean these operations can be spread out over more

disk heads. Implementing RAID will help reduce administration, increase performance, and provide

fault tolerance, depending on which RAID type is chosen.

The major components of an Epicor 9.05 Service Pack Progress system include:

Operating system

Application code

Application generated reports

Progress database

Database bi files

Database data files

The major components of an Epicor 9.05 Service Pack SQL Server 2008 R2 system include:

Operating system

Application code

Application generated reports

SQL Server 2008 R2 database

SQL data file (.MDF)

SQL log files (.LDF)

SQL tempdb file

In an ideal system, each one of these items would have its own disk, with the database file being

located on a RAID10 set and log files being mirrored for maximum performance and integrity. There

are always some tradeoffs between the number of disks employed and performance and data

integrity. The initial recommendation would be to never locate the database or log files on anything

but fault tolerate drives. Your data is worth far more than the additional cost of the required drives.

The components that might be combined are the operating system and the application code. The

log file should be the last component you combine with something else.

Also, consider having a spare drive or two on the system. You will often find you need them later.

Spare drives will let you have a copy of the database for testing, provide space for expansion

during a version upgrade, or provide a formatted drive in case of disk failure.

The drive configurations listed below illustrate the tradeoff between cost and performance and fault

tolerance for each SQL Server 2008 R2 database component listed above.

Performance for the listed configurations may be enhanced by adding additional drives to the RAID

arrays.

Base your drive capacity decisions (i.e. 36GB, 72GB, 146GB) on estimated future growth /

incremental cost.

Growth Path – Buy a system which allows you to put several disks internally. If your scenario dictates

external disk array / SAN then you should always buy an array which allows you to slide in more disk

spindles if needed. Remember, we add more disk spindles not to add capacity but to spread the

I/O load across multiple spindles.

Fault Tolerant RAID Configurations

One of the most powerful methods of improving the performance of any drive subsystem is to

employ multiple drives working in tandem. This is extra important for the SQL database server

storage subsystem. The reason for this is simple: there will always be limits to the performance that a


single drive, no matter how fast, can achieve. This limit is derived from the fact that one drive can

only perform one operation at a time, having only one set of read/write heads. A multi-drive

configuration can deliver some amazing performance gains when used with an operating system

that supports an asynchronous I/O model and device concurrency (talking to multiple devices

simultaneously) such as Windows 2008 (x64) / 2008 R2 Server. The most common reason for using

multiple drive sets is their use in RAID configurations. A RAID array is a collection of disks that provide

a single logical volume to the operating system and user, faster performance than a single logical

drive by itself, and in most implementations, some form of fault tolerance. For RAID disk arrays, fault

tolerance means that one member disk in a set can fail and the operating system or RAID hardware

can recover and rebuild the information from the data contained on the other member drives in

the set.

RAID is defined in a series of levels (starting with level 0), most of which provide some form of data

fault tolerance in addition to their speed advantages. Because the data redundancy and

performance implications of RAID are so significant, their use warrants consideration by anyone

looking to achieve maximum disk subsystem performance. The following RAID configurations are

supported with your Epicor applications:

RAID 0. Also known as disk striping. RAID 0 is the only common implementation of RAID that

offers no fault tolerance. It does, however, offer the fastest performance of any RAID level; it

works by striping data evenly across two or more drives in the RAID 0 set. This concurrent drive

usage translates to excellent read/write performance and is the best choice for maximum

performance where data fault tolerance on the drive array itself is neither a concern nor a

requirement.

RAID 1. Also known as disk mirroring or duplexing. With RAID 1, two drives of equivalent

capacity are used. One is a “mirror” or “shadow” of the other. Disk mirroring provides a

redundant, identical copy of a selected disk - all data written to the primary disk is also written

to the mirror disk. RAID 1 provides the best fault tolerance because no rebuilding is required in

the event of a failure. RAID 1 generally improves read performance but may degrade write

performance. When two controllers are used in RAID 1 (one for each drive), this is referred to

as disk duplexing.

RAID 10 (RAID 1 + RAID 0, or RAID 0 +1 / RAID 1 + 0). Also known as mirroring with striping. RAID

10 uses a striped array of disks, which are then mirrored to another identical set of striped

disks. For example, a striped array can be created using three disks. The striped array of disks is

then mirrored using another set of three striped disks. RAID 10 provides the performance

benefits of disk striping with the disk redundancy of mirroring, without the performance issues

associated with parity maintenance. RAID 10 provides the highest read/write performance of

any of the RAID levels at the expense of using twice as many disks. This is advised for high

security / high performance situations.

Epicor recommends RAID 10 for database files and Epicor 9.05 application server’s temporary

and report files.

RAID 5 (or any other combination similar to RAID 5). Not recommended and supported. It

does not mean that Epicor 9.05 application will not work. It means that performance will

suffer if you configure your disks in a RAID 5 or any other RAID 5* combination.

Implementation Types

The four common RAID implementations include:

In the operating system

In the disk controller

Via a dedicated RAID controller hardware

In a separate subsystem

Implementing RAID as part of the operating system is the least expensive option and also the least

desirable. Software implemented RAID solutions lack hardware level control and place additional

load on the server, reducing the amount of server resources available for your Epicor applications.


A RAID implementation in a disk controller uses less processor power and system resources than an

operating system based solution. Usually, special device drivers are required for these disk

controllers. The advantage to this type of implementation is that it is inexpensive, but the

disadvantage is that it provides very limited fault-tolerance. Failed disks cannot be replaced while

the system is operational. However, this is better than no RAID at all.

A RAID implementation via a dedicated RAID controller card, combined with hot swappable disks is

cost-effective and has the advantage of not requiring the machine to go off-line to replace a disk.

A RAID implementation that is a separate subsystem from the computer is best. It can have its own

power supplies, battery backup, spare controllers, hot-standby disks, and other capabilities all of

which are independent of the computer. Failure of a component in the computer should not affect

the disk subsystem and vice versa.


Backup and Fault Tolerance UPS

Other server considerations include:

Backup devices

Uninterruptible power supply and redundant components

Backup Devices

It is extremely important that your business information is backed up on a regular basis. The

frequency and type of backup should be discussed with your implementation team, but one or

more tape / backup drives on the server can ensure a timely backup is made. It is also possible to

backup to the local disk, and then copy the file elsewhere for storage. Consider off-site storage for

backups as well. Test your backup scripts and restore procedures and backup files regularly.

Uninterruptible Power Supply (UPS) and Redundant Components

The production server is the key to the business, and should be protected. Power outages can

damage the server hardware and can occasionally corrupt the software; therefore, the server

should be protected with a UPS, specifically one with server software that is capable of initiating a

clean shut-down of the server. Recovery from a power outage is usually not a problem, but why

take the risk.

The mission critical nature of an ERP system necessitates consideration of redundant processors,

network controllers, storage controllers, hot-swappable hard drives, and power supplies. You should

also consider network hub/switch redundancy.

Such components contribute to a “highly-available” solution which is tolerant of most hardware

failures and allow for service to be postponed to off-hours. Businesses requiring continuous

availability (24 x 7) may also want to consider hot plug support for controllers, on-line spare hard

drives, redundant processor power modules, and redundant hot-swappable fans to provide the

highest-availability solution that can be serviced during business hours without an interruption in

productivity. Network hubs, routers, and server monitors should also be considered when assessing

UPS requirements.


About Epicor

For over 20 years, Epicor has been a recognized leader dedicated to providing leading edge

enterprise software solutions to midmarket companies around the world. With over 20,000

customers, Epicor delivers end-to-end, industry-specific solutions that enable companies to

immediately improve business operations and build competitive advantage in today’s real-time

global economy. Epicor’s comprehensive suite of integrated software solutions for Customer

Relationship Management, Financials, Manufacturing, Supply Chain Management, and Services

Execution and Control provide the scalability and flexibility to support long-term growth. Epicor’s

solutions are complemented by a full range of services, providing a single point of accountability to

promote rapid return on investment and low total cost of ownership.

Disclaimer

This document and its contents, including the viewpoints, recommendations, dates and

functionality descriptions expressed herein are believed to be accurate as of its date of publication,

February 2012. However, Epicor Software Corporation does not make any guarantee,

representations or warranties with regard to the enclosed information and specifically disclaims the

implied warranties of fitness for a particular purpose and merchantability. All information contained

herein is subject to change without notice. The usage of any Epicor Software shall be pursuant to an

Epicor end user license agreement and the performance of any consulting services by Epicor

personnel shall be pursuant to Epicor’s standard services terms and conditions. Any hardware

purchased shall be subject to its own equipment purchase agreement. Epicor is a registered

trademark of Epicor Software Corporation. All other trademarks acknowledged. Copyright © 2012

Epicor Software Corporation.

Trademark and Copyright Acknowledgement

Copyright © Epicor Software Corporation 2012. Epicor, Vantage and Vista are trademarks and/or

registered trademarks of Epicor Software Corporation. All other trademarks acknowledged. Epicor

reserves the right to make modifications or changes to the functionality, and plans described herein

without further notice. This document is intended solely to inform the audience of Epicor's current

intentions. Epicor makes no warranties, express or implied in or by this document. The contents of this

document are believed to be current and accurate as of its date of publication. For a complete

description of the product features, please refer to the product’s user guides, reference manuals

and release notes.

For more information on Epicor, contact: Epicor Software Corporation

4120 Dublin Boulevard, Suite 300 Dublin, CA 94568-7759

www.epicor.com 1.888.448.2636

epicor 9.05.7xx hardware sizing guide

Documents