Epicor 9.

05

Hardware Sizing and Configuration Guide for SQL and Progress Databases

Table of Contents
Introduction Determining Epicor 9.05 application load Selecting the Right Server Configuration General Comments and Typical usage Sizing Processor the CPU(s) Sizing Memory Requirements (RAM) Sizing Disk Subsystems How Much Disk Capacity? What Types of Drives Should I Purchase? How Do I Protect My Data? Fault Tolerant RAID Configurations Implementation Types System Drive Configuration i.e. how to spread the I/O load to gain performance Network Network Bandwidth Backup and Fault Tolerance Tape Backup Devices Uninterruptible Power Supply (UPS) and Redundant Components Hardware Sizing Guide Epicor 9.05 installation using OpenEdge database Epicor 9.05 installation using Microsoft SQL Server 2008 database Microsoft Terminal Services Other Hardware Requirements Handheld Equipment Barcode Equipment MES Workstation Communications Printer Tape Drive Backup Equipment Network Hardware Recommendations Other Software Requirements Epicor Web Access Requirements About Epicor 1 1 1 2 5 6 7 7 7 7 7 8 9 11 11 12 12 12 13 13 14 16 17 17 17 17 17 17 17 18 19 19 20

Epicor 9.05: Hardware Sizing and Configuration Guide

Introduction
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.

Determining Epicor 9.05 application load

The key to any sizing project is to understand the types of workloads involved. Answers to the following questions will allow you to more accurately judge your server requirements: Your total number of users including office users, data collection 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 your Epicor system have? An Epicor 9.05 installation a higher concurrent users requires more CPU, memory, Network bandwidth and disk spindles to spread the I/O load around. Your application usage pattern. No two customers application usage pattern is the same even if they have the same number of users and concurrency.

The hardware recommendations provided in this sizing guide assumes a typical usage of Epicor 9.05 application. We define typical usage in the next 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.

Selecting the Right Server Configuration

After considering the answers to the questions listed above, you are ready to move on to the next step of selecting the hardware for your Epicor 9.05 server. For this discussion, the hardware configuration is divided into following areas: General comments and description of a typical usage Processor Memory Disk drives including RAID arrays Network Backup and Fault tolerance

General Comments and Typical usage

Let your hardware vendor know that you plan to use this machine as a 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 his 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? Deploy the supported version of software at all times we strongly recommend 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, Epicors 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 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 machines specs with the hardware specifications mentioned in this guide. When matching hardware specs with your virtual server machine you have to make sure you are not interchanging sockets with cores. For example, when this sizing guide recommends 2 sockets (physical CPU) and each socket should be Quad-core, it means 8 VCPU or virtual CPU for your virtual server software. Each virtual machine instance consumes anywhere from 5-15% per virtual machine on the host machine, depending on the host machines hardware. Please take that additional usage into consideration as well. 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 paper, that are involved in maintaining the server at peak performance

Epicor 9.05: Hardware Sizing and Configuration Guide

What do we mean by typical usage and what are the things to avoid? Typical load 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 servers 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, please 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 can cause performance problems The following scenarios increases the resource utilization on a typical Epicor 9.05 installation and should be avoided: o Running large BAQs Epicor 9.05 BAQs are very powerful tools and can be used to query any amount of data from the server. If your end user ends up writing an inefficient query which retrieves lots of records and has incorrect joins not supported by indexes the BAQ will be a resource hog both for the appserver 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. In house application / EDI Work flow The hardware guide cannot anticipate the load from any in-house / 3rd party application that will use the services of Epicor 9.05 application server and / or database. Please adjust the hardware guidelines accordingly.

Running Other Applications on Production box Due to the mission critical nature of any companys 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 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 dont require a high end box like the one required for production environment and hence should be on a separate and possibly less powerful box. 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.

Epicor 9.05: Hardware Sizing and Configuration Guide

Licensing - When deciding on processors, note the SQL Server 2008 licensing can be processor dependent so factor that into the total performance vs. cost determination. If you are upgrading to the Enterprise Edition of Windows for increasing the RAM usage, consider upgrading to 64-bit version of Windows and you may not need Windows Enterprise edition. 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. Direct network connection between the application server and database server - When you do separate the database server from the application server, it has to be directly connected with at least a 1 Gigabit network connection between the application and database servers.

Epicor 9.05: Hardware Sizing and Configuration Guide

Sizing Processor the CPU(s)

The primary object when sizing the model and number of CPUs 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 longterm investment protection. Windows 2003 / 2008 Server is both a multi-process and multi-threaded enabled operating system. 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 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 L1 and L2 cache. Configure enough CPU resources to drive all of the servers 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 2003 / 2008 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. Growth Path If you have empty CPU sockets on your servers 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 appserver and database on separate boxes. You can also add multiple appservers machines to allow for your growth.

Epicor 9.05: Hardware Sizing and Configuration Guide

Sizing Memory Requirements (RAM)

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 2003 / 2008 Server requirements Windows 2003 / 2008 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 servers 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 Appservers, 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 8GB of RAM. When purchasing RAM, consider future upgrade options and the RAM limit for your servers 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 agent Additional 2GB assumption for larger database Total 6.0GB

Epicor 9.05: Hardware Sizing and Configuration Guide

Sizing Disk Subsystems

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 10 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 and Ultra Fast/Wide Disk Drives rotating at 15,000 rpm. Select a higher value of disk buffer size like 16 or 32 MB or more.

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). Backups see separate section on that.

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. 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 multidrive configuration can deliver some amazing performance gains when used with an operating system that supports an asynchronous I/O model and device
Epicor 9.05: Hardware Sizing and Configuration Guide 7

concurrency (talking to multiple devices simultaneously) such as Windows 2003 / 2008 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. In the case of 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 RAID0+1/RAID1+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 and high performance situations. 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
There are four common RAID implementations: In the operating system In the disk controller

Epicor 9.05: Hardware Sizing and Configuration Guide

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 hotswappable 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.

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 i.e. how to spread the I/O load to gain performance
The number of drives you purchase and how you decide to configure them will depend on your budget, the intensity of your transactions, the desired performance and the need for fault tolerance. Your budget will determine the number and speed of the disks you can afford. The intensity of transactions will predict what disk I/O you will need. 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 are: 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 2008system are:

Epicor 9.05: Hardware Sizing and Configuration Guide

Operating system Application Code Application generated reports SQL Server 2008database SQL data file (.MDF) SQL log files (.LDF) SQL temp db 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 will always be 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 2008database component listed above. Performance for any of the listed configurations may be enhanced by adding additional drives to the RAID arrays. Base your drive capacity decisions (i.e. 9GB, 18GB, 36GB) on estimated future growth and 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.

Epicor 9.05: Hardware Sizing and Configuration Guide

10

Network
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 left to professional network analysts. As a general rule, the Epicor client has a bandwidth requirement of 10 Kbps (kilo bits 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 then 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.

Epicor 9.05: Hardware Sizing and Configuration Guide

11

Backup and Fault Tolerance

Other server considerations include: Tape backup devices Uninterruptible power supply and redundant components

Tape 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 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.

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.

Epicor 9.05: Hardware Sizing and Configuration Guide

12

Hardware Sizing Guide

Epicor 9.05 installation using OpenEdge database
Epicor 9.05 Application and Progress OpenEdge Database server. (Minimum recommendations satisfies typical usage) Epicor Technical Solutions can also help you figure out the best hardware configuration to run your business. Progress Database Operating System Small - 5-40 Users (Office + Data Collection) Medium - 41-150 Users (Office + Data Collection) Large - 150 300+ Users (Office + Data Collection)

Windows 2003 /

2008 Server (64- bit recommended, 32bit works too) bit)

Windows 2003 / 2008

Server (64- bit recommended, 32-bit works too) (32-bit bit) 64-bit)

Windows 2003 / 2008 Server

(64- bit recommended, 32bit works too)

Linux ES 3.0 (32-bit Unix HP/UX 11 (32bit or 64-bit)

Processors (Try to get the fastest processor GHz wise and highest # of cores the sockets allow. More cores will allow you to run multiple user requests and processes in parallel and will help during peak usage) Memory (RAM) Hard Drives (Note: Multiple hard drives are specified for spreading the I/O load across several spindles. In general, the more the spindles the less I/O latency and higher overall performance) Progress DB Split the bi file and db files on separate disk arrays for performance. Disk Controllers Free Disk Space Monitor , DVD-R reqd. Target Price for hardware

Linux ES 3.0 Unix HP/UX 11 (32-bit or

Linux ES 3.0 (32-bit bit) Unix HP/UX 11 (32-bit or 64bit)

2 CPU sockets filled with XEON Quad-core ~3.0 GHz (or better GHz
wise and Core wise)

4 CPU sockets filled with XEON Quad-core or Hexcore ~3.0 GHz (or better
GHz wise and Core wise) Some installations may benefit from a separate appserver box to run reports / processes.

4 CPU sockets filled with XEON Hex-core ~3.0 GHz (or better GHz wise and Core wise) -250 and higher users should consider splitting the appserver and database server if the installation becomes CPU bound. Also consider appserver box for running reports / processes. -Direct connection between appserver and Progress db box.

16 GB Eight SCSI / SAS Drives 15k RPM with RAID 1 or 10 array (*)

24 GB Sixteen SCSI / SAS Drives, 15k RPM with RAID 10 80-150 users should consider an external disk array it will alleviate I/O bottlenecks and improve performance. Consider Separate partition for Epicor 9.05 reports.

32 GB or higher At least 32 SCSI / SAS Drives, 15k RPM with RAID 10. You can get max 16 drives in the server rack. For remaining consider an external disk array Spread the db files across multiple RAID drives. Separate partition for Epicor 9.05 reports.

1 10 GB Minimum
SVGA 1024x768, DVD-R

2 20 GB Minimum SVGA 1024x768, DVD-R $15-25k

4 40 GB Minimum SVGA 1024x768, DVD-R $25 35k

13

$7-9k

Epicor 9.05: Hardware Sizing and Configuration Guide

Epicor 9.05 installation using Microsoft SQL Server 2008 database

Epicor 9.05 Application and SQL Server 2008 database (Minimum recommendations satisfies typical usage) Note: SQL Server 2008 is the version compatible with Epicor 9.05 Service Pack. 64-bit SQL Server highly recommended. Epicor Technical Solutions can also help you figure out the best hardware configuration to run your business. SQL Database Operating System Small - 5-40 Users (Office + Data Collection) Windows 2003 / 2008 Server (64-bit recommended) 32-bit works too. Split SQL and appserver box? YES
Very small deployments having 10 users or less dont have to split.

Medium - 41-125 Users (Office + Data Collection) Windows 2003 / 2008 Server (64-bit recommended) 32-bit works too. YES

Large - 125 250+ Users (Office + Data Collection) Windows 2003 / 2008 Server (64-bit recommended) 32-bit works too. YES

Processors (Try to get the fastest processor GHz wise and highest # of cores the sockets allow. More cores will allow you to run multiple user requests and processes in parallel and will help during peak usage)

SQL Server - 2 CPU sockets filled with XEON Quad or Hex-core ~3.0 GHz (or better GHz wise and Core wise) Application Server 2 CPU sockets filled with XEON Quad or Hex-core ~3.0 GHz (or better GHz wise and Core wise) Direct connection between SQL and appserver box i.e. less than 1 ms ping time i.e. no latency.

SQL Server - 4 CPU sockets filled with XEON Quad or Hex-core ~3.0 GHz (or better GHz wise and Core wise) Application Server 4 CPU sockets filled with XEON Hexcore ~3.0 GHz (or better GHz wise and Core wise) Direct connection between SQL and appserver box i.e. less than 1 ms ping time i.e. no latency.

SQL Server - 4 CPU sockets filled with XEON Hex-core ~3.0 GHz (or better GHz wise and Core wise) Application Server 4 CPU sockets filled with XEON Hexcore ~3.0 GHz (or better GHz wise and Core wise) Higher loads and user counts will benefit from multiple appserver machines. Consider an appserver box dedicated for reports and processes. Direct connection between SQL and appserver box i.e. less than 1 ms ping time - i.e. no latency.

Memory (RAM)

8 GB 16GB for SQL Server box.

16 GB for application server. 32 GB for SQL Server. SQL Server Box - Sixteen SCSI / SAS Drives 15k RPM with RAID 10 on the SQL Server. Spread SQL db, SQL log and temp-db files across multiple RAID10 arrays. Appserver Box - Six SCSI Drives 15k RPM on appserver box with a separate partition to store Epicor 9.05 reports. External disk array can allow you to add more spindles and hence alleviate I/O bottlenecks.

16 GB for application server. 32 GB for SQL Server. SQL Server Box - At least 32 SCSI / SAS Drives 15k RPM with RAID 10. You can get 16 drives in the server rack. For remaining drives consider an external disk array. Spread SQL db, SQL Log and temp-db files across multiple RAID10 arrays. Appserver Box - Six SCSI Drives 15k RPM on the appserver box with a partition to store Epicor 9.05 reports.

Hard Drives (Note: Multiple hard drives are specified for spreading the I/O load across several spindles. In general, the more the spindles the less I/O latency and higher overall performance)

SQL Server Box - Eight SCSI / SAS Drives 15k RPM with RAID 1 or 10 (*) Spread SQL db, SQL log and temp-db files across multiple RAID10 drives.

Disk Controllers Free Disk Space Monitor DVD-R Drive Target Price for hardware

1 10 GB Minimum SVGA 1024x768 Required $7-9k

2 20GB Minimum SVGA 1024x768 Required $35 - $45k

4 40GB Minimum SVGA 1024x768 Required $50k and above depending on load. 14

Epicor 9.05: Hardware Sizing and Configuration Guide

Network 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. Windows XP Professional SP2 Network Workstation
Operating System Processor

Minimum Requirements

Recommended Configuration

Windows XP Professional SP3 1.8 GHz processor

Windows 7 Professional 2.8 GHz or higher. Recommended dual core processor and SATA hard drives 2 GB 2 GB SVGA or higher adapter Color SVGA monitor with 1024 X 768 resolution DVD-R drive (if not on server) Internet connection recommended for online support and downloading latest updates

RAM Disk Space for Epicor Monitor

1GB 1 GB SVGA or higher adapter Color SVGA monitor with 1024 X 768 resolution DVD-R drive (if not on server) Internet connection recommended for online support and downloading latest updates

DVD-R Other

Windows Vista Business Edition Network Workstation

Operating System

Minimum Requirements

Recommended Configuration

Windows Vista Business Edition (32-bit or 64-bit*)

Windows 7 Professional OR Windows Vista Business Edition (32-bit or 64-bit*) 2.8 GHz or higher. Recommended dual core 32-bit or 64-bit processor and SATA hard drives. 4 GB 2 GB SVGA or higher adapter Color SVGA monitor with 1024 X 768 resolution DVD-R drive (if not on server) Internet connection recommended for online support and downloading latest updates

Processor

1.8 GHz 32-bit or 64-bit processor

RAM Disk Space for Epicor Monitor

2 GB 2 GB SVGA or higher adapter Color SVGA monitor with 1024 X 768 resolution DVD-R drive (if not on server) Internet connection recommended for online support and downloading latest updates

DVD-R Other

(*) 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.
Epicor 9.05: Hardware Sizing and Configuration Guide 15

Microsoft Terminal Services

Each Terminal Services server can accommodate 15 users adequately.

Microsoft Terminal Services

Operating System

Up to 15 Users

Windows 2003 / 2008 Server Enterprise Edition (64-bit recommended/ 32-bit works too) Xeon Quad-Core ~3.0 GHz (or better) 8 GB 15k RPM SCSI / SAS Drives 2 X RAID 1 (**) One 20GB Minimum SVGA 1024x768 Required About $10 K

Processor Memory (RAM) Hard Drive Disk Controllers Free Disk Space Monitor DVD-R Drive Target Price

(**) See System Drive Configuration recommendations

Epicor 9.05: Hardware Sizing and Configuration Guide

16

Other Hardware Requirements

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
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

Tape Drive Backup Equipment

Epicor recommends your company invest in a reliable backup system. Your hardware vendor can recommend and install one for you.

Epicor 9.05: Hardware Sizing and Configuration Guide

17

Network Hardware Recommendations

A 1 GBPS network is recommended Fiber optic cable 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 appserver 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 appserver box.

We strongly recommend 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, Epicors support for that same software package or version generally ends as well.

Epicor 9.05: Hardware Sizing and Configuration Guide

18

Other Software Requirements

Epicor Web Access Requirements
Supported Browsers and versions Internet Explorer - Internet Explorer 8 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)

Supported Mobile Browsers and versions Apple Safari - Safari 3.2 (iPhone) Opera Mini Blackberry Browser 4.6 Chrome (android )

Web Printing Support Windows Server 2003 Windows Server 2008 requires EWA 2003 print server defined

Epicor 9.05: Hardware Sizing and Configuration Guide

19

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 todays real-time global economy. Epicors 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. Epicors 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, March 2010. 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 Epicors 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 2009 Epicor Software Corporation. Trademark and Copyright Acknowledgement Copyright Epicor Software Corporation 2009. 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 products user guides, reference manuals and release notes.

Epicor 9.05: Hardware Sizing and Configuration Guide

20

For more information on Epicor, contact: Epicor Software Corporation 18200 Von Karman, Suite 1000 Irvine, California 92612 www.epicor.com 800-997-7528