Design of Infrastructure for NCR Counterpoint

Design of Infrastructure for NCR Counterpoint The purpose of this document is to assist in determining the correct type of implementation, help implementation teams make critical decisions buying or building servers and POS hardware, and serve as a general guide for designing and planning a successful NCR Counterpoint deployment. This document covers several topics, including Single-Site implementations, the advantages and disadvantages of WAN and Multi-Site implementations, as well as Hybrid configurations. Additionally, this document covers basic NCR Counterpoint implementation concepts and important considerations for each type of implementation. Single-Site questions and considerations The Single-Site systems is defined as one location with either a single server or multiple servers all serving a set of workstations. When designing a Single-Site system, there are many questions that need to be considered. A sampling of those questions are: - How many concurrent users will there be on this system? - Ticket volume o What is the average hourly ticket volume? o What is the peak ticket volume? - Is there existing POS equipment to consider? o Will the client want to re-use the existing equipment? o If so, does it meet the minimum specifications to run Counterpoint? o If not, can it be upgraded to meet the minimums and will it need to be upgraded in the future? - Does the customer need redundancy? - What is the current disaster recovery plan? - Are there third-party hardware and/or software applications to consider? - How many Counterpoint workstations will be supported? - Will customizations require Hold/Recall? If so this may cause a decrease in ticket performance. - Are there growth plans for this site in the future? - Does the application server need to be separate from the database server? Server Sizing for Single-Site Using the questions above as a guide, the required hardware can be built to scale to the needs of the customer. As demonstrated in the sample questions, there is specific information needed to create the proper environment for a successful implementation of NCR Counterpoint. Those 1

topics include: ticket volume, number of concurrent users, capabilities of existing POS equitment, redundancy and disaster recovery, third-party hardware and software, workstation count, and potential customizations. Ticket Volume Ticket volume is one of the main factors that helps determine database server requirements. Ticket volume is measured by peak ticket volume and average ticket volume. Peak ticket volume is the number of tickets being received by a database server at the busiest point possible. These times are usually related to a specific time of year or period of time. For instance in most retail stores, the holiday season is when the stores will experience the peak transaction volume. The servers need to be able to handle this volume for sustained periods. It is during these periods when servers that are not configured to handle the load will break down or stop working due to over-heating or over-loading of the queue to the disk drives. From a customer perspective, the Counterpoint application will become noticeably less responsive if servers are under-resourced during peak periods. Upon a reboot and resuming operations, the server would eventually see the same peak volume and slow again. Average ticket volume is used to determine the size of disk drives needed over long periods of time since ticket history will be the biggest space consumer over time.. Average ticket volume can be calculated by dividing the total number of tickets in a day by the number of minutes the stores were open. After all, ticket history is the biggest absorbtion of space as time continues forward. The risk of running out of disk space can be mitigated by annually purging sales history. Most businesses are required by law to retain at least 3 years of sales history. In some industries, the law requires 7 years. In most cases, 100 average tickets will require 200 to 400k of space depending on whether it is a gridded, serialized, or standard set of items. Use the NCR Counterpoint Server Sizing Guide for specific guidance regarding the relationship between ticket volume and server hard drive size. Concurrent Users Another factor for single-site implementations is the number of concurrent users running the NCR Counterpoint application. NCR Counterpoint follows a standard client-server relationship. In other words, the server provides the data and files necessary to run the application. However, the client uses a subset of files that run the application. Typically, single servers running Microsoft Windows Server 2008 can handle over 60 users. Use the NCR Counterpoint Server Sizing Guide for specific guidance regarding the relationship between user count and server specifications. Existing Equipment In some instances, a client may want to use existing hardware (server, terminals, printers, scanners, etc). In that case, you will need to determine if the hardware is fit for the purpose or can be upgraded if it is below minimum specifications. It is advisable to consider the possibility that the upgrades may be necessary in the future. Use the NCR Counterpoint Server Sizing 2

Guide to ensure that existing server hardware meets the requirements to run NCR Counterpoint efficiently. Also evaluate any existing peripherals to determine their suitability and whether current drivers exist for the operating system on the device to which it will be attached. Third-party Hardware and Software Applications Integrating third-party devices or software applications can affect the server architecture because some types of integration may cause additional overhead and require more processing power to perform tasks. Examples of integration are: obtaining the weather condtion from the web and stamping it on the ticket; acquiring a weight from a large truck scale within ticket entry; interfacing to Purchasing systems, external inventory systems, or an external application that launches from ticket entry to create work tickets. These types of applications will take additional RAM, disk space, disk I/O, and processing power so the server must be sized appropriately to handle the additional loads. Ensure that software applications that run on the NCR Counterpoint server, or that access the server, are added to the NCR Counterpoint server sizing requirements found in the NCR Counterpoint Server Sizing Guide. Workstation Count CPServices, an NCR Counterpoint service that runs on the server, requires RAM and processing power on the server. Approximately 50 MB of RAM is required to run the service. If Offline Ticket Entry is used, the service will need an additional 5 to 10 MB for each workstation connected. This requirement can vary, based on the server s processor and available RAM. Use the NCR Counterpoint Server Sizing Guide to plan server size based on number of workstations. Additionally, larger file packets use more memory as they are being processed or built. For servers, incoming ticket files can affect the response time of the server as they are received and processed. Another area that affects the server is during the build of large configuration packets for the workstations in databases with 20,000+ items and/or complex item grids. One example of a large configuration packet is the initial data load of offline stations. All these factors should be considered in the calculations for total RAM on the server. Counterpoint SQL Customizations The last consideration for a NCR Counterpoint environment are customizations within the product. The use of hold and recall on payments or lines can change the server requirements significantly. Adding a single hold and recall for each ticket will increase the server requirement by as much as 30% to 50%, as hold and recall operations almost double the amount of tickets the SQL server reads and writes. Line-by-line hold and recall could increase the server specifications by as much as 50% to 70%. A combination of RAM, higher speed processors, and larger disk arrays can help manage the additional load of hold and recall. Consider designing customizations to avoid using hold and recall for each ticket. Customizations that use hold and recall must be clearly documented with specific information regarding its use and expected impact on server processing and memory needs. Use the hold and recall section of the NCR Counterpoint Server Sizing Guide to plan server size when using this operation. 3

Additional Considerations Growth Plans The customer s growth plans are very important to consider when making architectural decisions. Ask these questions: - Is the customer planning to add more stores? - Is the customer adding an Ecommerce site (considered another store)? - Is the customer expanding an existing store (more merchandise, more registers, etc)? - Is the customer adding more users? - Is the customer adding other applications (e.g., Integration, Accounting packages, etc.)? By getting these answers up front, you'll be able to determine a server specification that will handle the peak load for the customer s immediate needs and will accommodate future growth. Use the NCR Counterpoint Server Sizing Guide, and include those growth plans in the selection of the right server specification. Redundancy A recommended standard practice for servers is to build in redundancy. Redundancy in server hardware would include extra drives (usually in a RAID configuration), extra power supplies, additional fans, and extra NIC cards. For instance, redundant network cards are necessary to guarantee network requests can be handled when one fails. An ultimate redundant solution may include an additional server to meet up-time requirements by some clients. Disaster Recovery A comprehensive disaster recovery plan needs to be implemented in case the unthinkable happens. With a proper disaster recovery plan, downtime can be minimized, data can be recovered, and operations can continue with little or no impact. Considerations for redundancy can include duplicate servers, extra hard drives, replacement RAM, extra power supplies, securing copies of applications for reinstall, Offline processing, and secure backup plans for data and files. The ultimate goal is to minimize downtime for a client s application. More information on disaster recovery can be found on various websites listed at the end of this document. Splitting the Application and Database Servers When is it necessary or wise to split the application and database servers for a NCR Counterpoint solution? Ask these questions: - When is one server insufficient for the deployment? - When do you split servers between the application and the database? When designing a NCR Counterpoint solution, it is important to know when you should split the Counterpoint application and database (including SQL Server) across different servers. Here is a list of factors that can help you understand when multiple servers should be considered: 4

- Current Hardware will not support the number of users - Hard Drive I/O is being utilized totally for SQL causing problems with the Application - More than 50 to 75 Counterpoint users - Application and SQL Server are competing for resources on the server Additional factors would include limited memory, hard drive utilization and requirements, and processor limitations. Use the NCR Counterpoint Server Sizing Guide to examine when the servers should be split. WAN Implementation General Information A WAN deployment is very similar to a Single-Site install and all the topics above apply to the WAN model. One thing that differs for a WAN implementation is that this deployment model involves multiple servers, including a database server, an application server (which may be the same as the database server), and a Remote Desktop server. Remote Desktop servers run the NCR Counterpoint application on POS terminals at different physical locations without the overhead of NCR Counterpoint being installed on each terminal. The Remote Desktop server would run Windows Remote Desktop Services from Windows Server 2008 R2. Remote Desktop Servers In the past on older operating systems, Remote Desktop Servers have been limited to 20 to 30 users with the maximum amount of 4GB RAM available. With Windows Server 2008 R2, these systems can sustain up to 150 users if properly configured. In order for these servers to handle all these users, the servers need dedicated processors to run the multiple desktop windows for the remote users. Minimally, the server should be a dualcore processor for 20 users. When the user count exceeds 20 users, consider moving the server to quad-core processors. The additional processors in this configuration ensures the operating system will have enough processing power while servicing the Remote Desktop clients. For more than 75 users, the processors should be increased again. Additionally, each session of the NCR Counterpoint application can use a maximum of 200 MB of RAM. Multiply this value by the number of users to determine the amount of RAM needed for the server. Remember to allow at least 4 GB RAM for the operating system. The high memory requirements for the server allow activities to occur in the server's memory, rather than swapping in and out of the paging file for Windows. This is very important and the server should be monitored to make sure that memory is sufficient. Use the NCR Counterpoint Server Sizing Guide to configure your Remote Desktop server appropiately. 5

Bandwidth Requirements In order to successfully implement a WAN solution, high speed internet access is essential at each client location. Cable internet access or better is recommended, but DSL is acceptable. A minimum of 64k per client is required to connect Remote Desktop clients. A minimum of 128k should be considered at each site, since customers usually want to connect to the internet and will pull resources from the Remote Desktop clients. At the main site, the clients require the same bandwidth per connection. In order to calculate the customer s bandwidth requirements, multiply the sum of the clients by 64k to obtain the requirement just for the WAN implementation of NCR. Counterpoint. Other operations such as internet credit card processing, internet usage, and video/voice can add to the bandwidth needed. The sum of all these types of connectivity are needed in order to understand the full bandwidth requirement. For example, at a 10-store retail chain with 2 registers per location, the minimum bandwidth needed for each store should be 256k to allow for internet usage as well as the 2-64k Remote Desktop connections. At the main site, the requirement would be 1.28 MB of bandwidth (20 users X 64k per user). In this case, a T1 (which has 1.5 MB capability) should be considered to meet just the NCR Counterpoint bandwidth requirements, unless other operations need more bandwidth. Alternative WAN Model A different WAN model that utilizes the same servers listed above, but has lower bandwidth requirements, as the POS workstations would run in Always Offline mode. Always Offline workstations utilize the Offline Ticket Entry Option of NCR Counterpoint. However, they never connect to the Remote Desktop server. This model allows the terminal server to be used by back-office workstations only and reduces licensing costs required by Remote Desktop Services. In order for this to work, the client must understand the limitations of the Offline Ticket Entry feature within NCR Counterpoint. Use the NCR Counterpoint Server Sizing Guide to configure your WAN with Always Offline deployment appropriately. Multi-Site Implementation General Information Another deployment model is the Multi-Site implementation. In this deployment model, each site has a server that acts as an application/database server to run NCR Counterpoint locally. Data in each site's database is replicated back to a Hub server at a central site, where a master database retains the data for all sites. The replication is done by an application named DataXtend. The application synchronizes changes back and forth in the databases from each remote site to the central site. In this type of deployment, the server s processing load comes from the replication of the databases. DataXtend replication requires a combination of good hard drives (due to high drive I/O), memory and processors to move the data quickly. 6

Hard Drives As mentioned above, the Multi-Site deployment model requires heavy processing power, and heavy drive I/O. The reason for the heavy processing nad heavy drive I/O is due to the fact that the replication process compares each table and data field to ensure that the data has been sent or received successfully. Heavy drive I/O can cause early failures of drives that are not built for business class applications. Data shows that SATA (Serial ATA) drives will fail 1.5 times as fast as SAS (Serial Attached SCSI). Additionally, SAS drives will perform faster than SATA. Even though SAS is more expensive, this is the recommended drive to use on Multi-Site deployments. Bandwidth Requirements In order to successfully implement a Multi-Site solution, high speed internet access at each client location is essential. Cable internet access or better is recommended, but DSL is acceptable. A minimum of 128k should be considered at each site to give replication enough bandwidth. At the Hub location, bandwidth must be adequate to handle sites replicating with the Hub simultaneously. Multiply the number of sites that will replicate at the same time by 64k to ensure there is enough bandwidth. For example, for a 10-store chain where each remote site is scheduled to replicate every hour, assume that 4 replications with the Hub could occur at the same point. This would require 256k of bandwidth (4 X 64k) to ensure data can move freely. Remember to add the additional bandwidth needed for other activities such as internet credit card processing, internet usage, and video/voice requirements. Servicablity and Maintenance The Multi-Site deployment model relies on many components and requires hardware at each location, which can take a lot of time to set up and deploy. Additionally, the configuration requires a deep understanding and knowledge of networking and SQL databases. This makes the Multi-Site deployment model one of the most complex setups for NCR Counterpoint. Additionally, the service to maintain this model is higher and more complex. Instead of maintaining one database at the corporate level (i.e., Single-Site or WAN deployments), a database exists at each location and must have continual maintenance. Without the maintenance, Multi-Site servers will encounter issues and errors that will take serious time to resolve. This fact can make the Multi-Site deployment model more expensive and difficult to maintain for a customer. Selecting the Right Implementation Model for a Customer with Multiple Stores When selecting an implementation model for a multiple-store system, it is important to have all the facts about the client and their current infrastructure. Additionally, it is good to pick a starting position. The best place to start for multiple stores is with a WAN model, due to these reasons: - One database to maintain - Deployment and implementation are easier - Maintenance and upgrades are eaier 7

- One area to perform maintenance - Support issues are less complicated - Inventory is "real-time" for all locations - Reports will be accurate since all information is available - Real-time information is available to the merchant o Customers o Inventory o Transfers o Purchasing o History - Forward thinking to the future model of NCR Counterpoint and its capabilities. The WAN model is most consistent with development strategy for NCR Counterpoint. The following decision tree uses these factors to help you decide which implementation model to follow. The basis for this decision tree is to assume a WAN multiple-store installation, and then to disprove that decision based on the facts you gather from the customer s location and capabilities. 8

Counterpoint SQL Implementation Selection Flowchart 9

Real-World Multiple Store Implementation Examples Here are a few examples of multiple-store installations and the deployment method that was chosen: Example # W1 Facts: - Five sporting goods stores - Want a system to help with: o Daily reporting o Inventory management Shrinkage Lack of tracking inventory Hard to tell when out of merchandise o Customer service considerations Do not know what customers are looking for Do not know if they are getting good repeat business No loyalty programs - Three registers per store - QuickBooks Accounting at main site - Great connectivity between sites - No existing infrastructure, cash registers currently in use Decision: Following the above flowchart, we start by assuming a WAN deployment and find no reasons to disprove this deployment so WAN is implemented. Example # W2 Facts: - Five sporting goods stores - Legacy POS system - Old devices (with compatible drivers for servers) o Parallel/Serial printers (old Epson) o Printer-driven cash drawers o Keyboard-wedge Devices - Three registers per site - Currently polling information with modems - Windows XP Professional on machines with 1 GB RAM 10

Decision: Start the process by assuming a WAN deployment. At this point, we have no reason to disprove the WAN architecture. However, the following factors need to be reviewed to ensure success: - Workstations need more RAM to meet minimum requirements for NCR Counterpoint, especially for Offline Ticket Entry - Need to check hard drive space on the server equipment and workstations Example # W3 Facts: - Five sporting goods stores - Legacy system (older POS System) - Old devices (drivers not compatible for servers) o Parallel/Serial printers (old Epson) o Printer-driven cash drawers o Keyboard-wedge Devices - Three registers per store - One Server per store - No space for a data center - Polling with modems - Windows XP Professional on machines with 1 GB RAM Decision: If infrastructure can handle Multi-Site, that is cheapest solution for the following reasons: - Legacy device issues o Not compatible with WAN architecture Drivers not compatible Interface not compatible - No space for a data center - Servers at the stores already exist (if they can be utilitized) However, the following factors need to be reviewed to ensure success: - Workstations need more RAM to meet minimum requirements for NCR Counterpoint, especially for Offline Ticket Entry - Need to check recommended requirements for the server equipment and workstations 11

Quick Sheet of Facts Here are several of the facts that were presented in this document for quick reference. Multi-Site Minimum Bandwidth requirement: 128k Data Replication, using a third-party data replication engine, will use as much bandwidth as available. It will not be stable on dial-up and will have problems. WAN or Remote Desktop Services Minimum Bandwidth requirement: 128k + 64k for each session after 2 sessions Per session requirement: 64k per session Example 1: A 256k ADSL line (typically from the phone company) can handle either 3 or 4 Terminal Services clients depending on the noise on the line. Example 2: A T1 is 24 channels of 56k traffic and can handle somewhere between 23 to 24 clients depending on stability of the T1. RAM for Remote Desktop Servers Each open session on a Remote Dekstop Server will require between 80 MB and 200 MB of RAM. A standard Remote Desktop session running TouchScreen Ticket Entry will require around 80 MB of RAM because of images and memory requirements for POS. Use the maximum of 200 MB of RAM per session for calculating the amount of RAM needed for Remote Desktop Servers. Heavy Order Entry While not typical in NCR Counterpoint, merchants operating a heavy order-entry system (one doing 20+ lines per order) will see a decline in ticket processing power as more lines are added to a ticket. After 20 lines, the Ticket Entry engine requires more RAM and a more powerful processor to handle the ticket in memory. When 50 lines are reached, a quad-core processor running 4 GB of RAM will work very hard on NCR Counterpoint. More RAM will be required to take the ticket further. This is mainly due to all the ticket calculations being performed as the ticket increases in size. CPServices and CP Offline Mode CPServices, a required Windows service installed with and used by Counterpoint, utilizes between 50 and 60 MB per install. In an Offline Ticket Entry environment, the server will need an additional 5 to 10 MB per offline workstation. 12

An average database rebuild for an offline workstation will require 500 MB RAM on the server. However, this is subject to the size of the database (number of items, customers, and so forth). Larger databases will require more RAM to build the file. Note: Rebuilds, Full Extracts, and Communication packages associated with NCR Counterpoint Offline mode will cause momentary spikes in server usage. 13

Other Reading Disaster Recovery The purpose of this section is to provide further reading material about Disaster Recovery Plans. 1) Definition and General information about Disaster Recovery Plans, Wikipedia, 2012. http://en.wikipedia.org/wiki/disaster_recovery_plan 2) The Disaster Recovery Plan, SANS Institute InfoSec Reading Room, 2012. http://www.sans.org/reading_room/whitepapers/recovery/disaster-recovery-plan_1164 3) IT Disaster Recovery Plan, Ready.Gov by FEMA, 2012. http://www.ready.gov/business/implementation/it 4) Disaster Recovery Plan, SBA.gov, 2012. http://www.sba.gov/content/disaster-recoveryplan 5) Pro SQL Server Disaster Recovery, SQL Server Performance.com, 2012. http://www.sql-server-performance.com/2010/pro-sql-server-disaster-recovery/ 6) Create Backups without Breaking the Database Backup Sequence, SQL Server Performance.com, 2012. http://www.sql-server-performance.com/2008/create-backupswithout-breaking-database-backup-sequence/ 7) Probabilities and Disaster Recovery, SQL Server Central.com, 2012. http://www.sqlservercentral.com/articles/editorial/76220/ 8) In the Real World Disaster!, SQL Server Central.com, 2012. http://www.sqlservercentral.com/articles/disaster+recovery+(dr)/intherealworlddisaster /669/ 9) Disaster Recovery An Afterthought?, SQL Server Central.com, 2012. http://www.sqlservercentral.com/articles/editorial/67413/ 10) Preparing for the Unthinkable a Disaster/Recovery Implementation, SQL Server Central.com, 2012. http://www.sqlservercentral.com/articles/disaster+recovery+(dr)/71992/ 14