B2W Software Resource Requirements & Recommendations

Transcription

1 B2W Software Resource Requirements & Recommendations v2019.2, December 21, 2018 Introduction... 2 Resource Determination Factors... 2 Environment Configuration Options... 3 Considerations... 3 Estimate... 3 Operational Suite... 3 Server Hardware Requirements... 4 Small Scale (1-50 Users)... 4 Standard & Large Scale (50+ Users)... 4 Estimate... 4 Operational Suite... 4 Server Software Requirements... 5 Operational Suite Additional Requirements... 5 Estimate Additional Requirements... 5 Client Workstation Requirements... 6 Tablet Device Requirements... 6 SQL Server Requirements & Performance... 7 SQL Editions & Licensing... 7 SQL Server Reporting Services... 8 SQL Server Performance... 8 Disk Performance... 8 Memory Pagefile... 8 Processor Affinity... 8 Memory Allocation... 8 Always On Availability Groups... 8 Appendix A Estimate Environment Examples... 9 Appendix B Operational Suite Environment Examples Appendix C Windows Server Optimizations & Recommendations Overall Performance Settings Disk Timeout Windows File System Settings Last Access Timestamp Disable 8.3 MS-DOS filenames Pagefile Settings Appendix D OS/SQL/.NET Compatibility Matrix... 15

2 Introduction B2W Software products can scale from individual-use, single-node installation all the way up to a highly available deployment with thousands of users comprising multiple application tiers behind a load balancer with SQL instances using SQL Always On. The information contained in this document should apply to a majority of deployments, but your requirements may vary depending on the usage. B2W Software employs the following Microsoft technologies: Windows, Windows Server, SQL Server, SQL Server Reporting Services, Azure Cloud, Office As well as several third party technologies for Reporting, and SMS messaging. Resource Determination Factors B2W Software installations require the following items to be considered in determining how your environment should be structured with compute and storage resources. High Availability/Disaster Recovery SQL Databases/Instances User/License Count Mobile/Offline Users Tablet Database Download Third-party Integrations Web/Windows Services Reporting Usage Data Volume Product Mix Future Scaling and Expansion Mission-critical systems require highly available systems and an environment configuration will need a larger number of compute and storage resources. The number of SQL databases and/or instances has an impact on required compute and storage resources. This includes test, staging and/or archival databases. The number of users concurrently active in the system has an impact on computer and storage resources that can increase over time. Mobile Estimate and Tablet syncing have a moderate impact on compute and storage resources. The Tablet Database Download feature requires additional storage resources depending on your application database size. Import/Export integration of B2W data to/from other systems has an impact on compute and storage resources that can increase as B2W data volume expands. This includes Job/Resource data and Telematics. Specific functionality requires services to be installed and utilized on B2W servers and can impact compute and storage resources. Reporting usage can have an impact on compute and storage resources depending on the size of reports and/or the data that is being consumed. High counts of Resource, Field Log and/or Work Orders will impact compute and storage resources. Additionally, file attachments to Field Logs and Estimates will have a high impact on compute and storage resources. Consider your intended B2W product mix when planning your environment. A mix of multiple products together (e.g. Estimate, Track, Maintain, Schedule) will have a high impact on compute and storage resources. Consider how your B2W implementation will grow and/or expand over time and plan your compute and storage resources accordingly. B2W Software Resource Requirements v Page 2

3 Environment Configuration Options Your environment configuration will play a large role in the proper functionality and performance expectation of your B2W Software installation. Considerations Small scale node configurations are not recommended for any high-volume production operation Active Directory Domain with Kerberos Authentication is required for any Operational Suite configuration option with two (2) or more servers Always On Availability Groups require: o SQL Server Enterprise Edition on each node o File Share Witness (in primary/secondary or even-number node installations) o Windows Failover Clustering on each node o Up to eight (8) maximum secondary replica nodes Actual user counts depend greatly on compute and storage resources allocated based on the Resource Determination Factors on Page 2 Estimate See Appendix A for more detail on the following configuration options: Configuration Type Users Servers Notes Small Scale - Tier Small Scale - Tier Standard Client/Server Remote Desktop Services 1 or Citrix 2 Client/Server Up to 1, Additional RDS Servers for higher user counts Client/Server w/database Failover Up to 1, Additional RDS Servers for higher user counts Remote Desktop Services 1 or Citrix 2 w/database Failover 1, Remote Desktop Services (formerly Terminal Services) requires additional licensing through Microsoft. 2 Citrix Virtual Apps (formerly XenApp) requires additional licensing through Citrix. Operational Suite See Appendix B for more detail on the following configuration options: Configuration Type Users Servers AD Domain 1 Notes Small Scale - Tier Low volume and light reporting Small Scale - Tier Low volume and light reporting Dual Node Required Low volume and light reporting Simple Multi-Node Up to Required Low to medium volume and reporting Multi-Node w/database Failover Up to 1, Required Medium to high volume and reporting High-Availability w/database Failover Load-balanced application and reporting nodes 1 1, Required High volume and reporting 1 Active Directory Domain Services with Kerberos required for multi-node environments 2 High volume reporting environments should also load-balance report server nodes. B2W Software Resource Requirements v Page 3

4 Server Hardware Requirements B2W Software products require adequate compute resources due to the nature of their operation which includes heavy computation, calculation and data volume (See Resource Determination Factors on Page 2). Server-class processors are required for all server installations of Operational Suite and/or Estimate and B2W Software recommends Intel Xeon Scalable, Intel Xeon E3 v4+ or Intel Xeon E5 v4+ processors. Small Scale (1-50 Users) The following small scale requirements are for Estimate and Operational Suite, installed separately or together. Tier Users Tier Users Server Role Cores / Threads Memory Storage Application/Database 4 / 8 12 GB 250 GB Server Role Cores / Threads Memory Storage Application/Database 8 / GB 250 GB Standard & Large Scale (50+ Users) The following requirements are for Estimate and Operational Suite, installed separately. Estimate Operational Suite Users Two-Node Users Server Role Cores / Threads Memory Storage Database 8 / GB 250 GB Server Role Cores / Threads Memory Storage Application 4 / 8 16 GB 100 GB Database 8 / GB 250 GB RDS/Citrix Up to 500 Users Server Role Cores / Threads Memory Storage Application 8 / GB 100 GB Database 8 / GB 250 GB Simple Multi-Node Up to 500 Users Server Role Cores / Threads Memory Storage Application 4 / 8 32 GB 100 GB Database 8 / GB 250 GB Reporting 4 / 8 32 GB 100 GB Database Failover Up to 500 Users Server Role Qty Cores / Threads Memory Storage Application 1+ 8 / GB 100 GB Database 2 8 / GB 250 GB Up to 1,000 Users Server Role Qty Cores / Threads Memory Storage Application 1 8 / GB 150 GB Database 2 14 / GB 400 GB Reporting 1 8 / GB 200 GB RDS/Citrix with Database Failover 1,000+ Users 1,000+ Users Server Role Qty Cores / Threads Memory Storage Application 2+ 8 / GB 150 GB Database 2 14 / GB 250 GB Server Role Qty Cores / Threads Memory Storage Application 2 10 / GB 250 GB Database 2 14 / GB 400 GB Reporting / GB 250 GB B2W Software Resource Requirements v Page 4

5 Server Software Requirements The following server software requirements have been certified for use the Estimate and/or Operational Suite. Estimate Operational Suite Operating System Windows Server 2008R Internet Information Services (IIS) Microsoft.NET Framework Microsoft SQL Server & Reporting Express 2, Standard or Enterprise 3 Edition: 2008 (SP2) 2017 Microsoft Excel Not Required Built-in or Custom SMTP Configuration SMTP Configuration 1 Microsoft.NET 3.5 is a prerequisite for all installations 2 SQL Express Editions do not support Always On Availability Groups and are not supported for user counts beyond five (5) 3 Enterprise Edition is required for Always On Availability Groups Operational Suite Additional Requirements Certain functionality and features in Operational Suite may require Windows Services to be installed. Depending on your installation configuration these services may require internet access: Alerts & Notifications EDS (Inform integration) Estimate Additional Requirements FTP Services 7.5 is required to use the Estimate Auto-update feature Management Reporting requires IIS and SQL Server Reporting Services Embedded Excel Workbooks or DOT Item Database Add-ins require Microsoft Excel B2W Software Resource Requirements v Page 5

6 Client Workstation Requirements Intel Core or Xeon processors are recommended for client workstations. The minimum requirements are as follows: Estimate Operational Suite CPU Cores/Threads 4 / 8 CPU Type Intel Xeon E3 v5+ or Intel Core i5 v7+ Memory (RAM) Hard Disk Display Resolution 4 GB 10 GB 1280 x 1024 pixels Operating System Windows 7 10 Microsoft.NET Framework Microsoft Excel Not Required Internet Browser 2 Internet Explorer 11 (32-bit) Internet Explorer 11 (Track, Dispatch) Microsoft Edge Mozilla Firefox Google Chrome The following additional requirements for a stand-alone, single-user installation Internet Information Services (IIS) 7 10 Microsoft SQL Server & Reporting 2008 (SP2) 2017 Express Edition 3 1 Microsoft Excel is required for B2W Estimate s embedded workbooks feature 2 Internet Explorer is required for B2W Estimate Enterprise Edition s Custom Properties feature 3 Reporting Services included with Express w/ Advance Services Edition Tablet Device Requirements Minimum Storage Capacity RAM 16 GB 2 GB Operating System 1 ios Android Minimum Screen Resolution 1024 x 768 Minimum Screen Size 7.0 in High-speed internet connection Synchronization Requirements A VPN connection is required to support secure synchronization with the B2W server when not connected to your network. 1 Tablet operating systems can be deprecated by the manufacturer at any time without notice. B2W Software Resource Requirements v Page 6

7 SQL Server Requirements & Performance B2W Software products require: Microsoft SQL Server as their database engine Reporting Services which is used by Operational Suite and Estimate Management Reporting as their analytics engine That they reside on their own SQL Server instances for performance, availability and recovery reasons An English instance of SQL Server using the default collation setting named: SQL_Latin1_General_CP1_CI_AS See Page 5 - Server Software Requirements to view B2W certified and supported versions. SQL Editions & Licensing Server + CAL license model requires a license for each physical and/or virtual SQL Server, and a license for each user and/or devices connecting to that server. Per Core license model currently is a 4-core minimum per physical or virtual processor. The major benefit of this option is that there is no requirement to try to quantify the number of users or devices accessing the SQL Server(s). Installations of B2W Software products of less than five (5) users may use the Express Edition of SQL Server. Express has the following limitations: Express Limited maximum database size of 10GB (SQL 2008R2 to current version) Reporting Services with Express does not support subscriptions or report builder Maintenance Plans (e.g. jobs, backups) are not supported Maintain and Schedule products are not supported Express Edition is free to use for individual installations. Standard Edition delivers basic database and reporting and has the following features and benefits: Always On Basic Availability Groups Always On Basic Availability Groups option with SQL Standard Edition has the following limitations: Standard Only available with SQL Server 2016 and later Limited to one (1) database Limited to two (2) replicas (primary and secondary) No backups, read-only or integrity checks on secondary No support for distributed availability groups Standard Edition requires Server + CAL or Per Core licensing. Your licensing will depend on your installation and data-tier environment specifications. Enterprise Edition offers high-end datacenter capabilities for mission-critical workloads, faster performance and unlimited virtualization in addition to the following features: Enterprise Always On Availability Groups See Page 8 - SQL Server Performance for detail on these features. Enterprise Edition requires Per Core licensing. Your licensing will depend on your installation and data-tier environment specifications. B2W Software Resource Requirements v Page 7

8 SQL Server Reporting Services Reporting Services (SSRS) generates the reports available in the B2W Operational Suite and Estimate Management Reporting products. While light use of reports has little effect on performance, moderate to heavy reporting can have an adverse effect. Your expected usage of Reporting should be a determining factor in your B2W installation environment plan. For more information, see Page 3 - Environment Configuration Options. SQL Server Performance The following should be considered when determining the specifics of the database tier of the B2W Software installation and implementation. Disk Performance The database should be configured to store data and log files on separate drives (preferably separate physical drives). Database performance is significantly enhanced with this configuration since read I/O for database files is typically random and I/O for the transaction log is typically sequential. Additionally, a database using FULL recovery mode can use the transaction log for recovery if the drive for the database files is lost but the drive for the transaction log is still available. FULL recovery mode is required for Always On Availability Groups. Ideally, SQL data, logs, backups and system databases (such as tempdb) should each be on their own physical drive for optimal performance. The file allocation unit recommended for SQL Server data and log drives is 64 KB (65536 bytes). Memory Pagefile Proper memory pagefile adjustment for data-tier machines requires capturing performance counters over a reasonable period. For more information, refer to the Pagefile section of Appendix C - Windows Server Optimization on Page 14. Processor Affinity SQL Server should be configured to automatically set Processor and I/O Affinity for all processors. Memory Allocation SQL Server maximum memory should be configured to 4GB less than total available system memory. For example, a database server with 32GB Physical RAM should have around 28GB allocated for SQL Server which leaves ample memory for remaining OS operations. Always On Availability Groups Always On Availability Groups is a high-availability and disaster recovery (HADR) solution for mission-critical databases. B2W Software Resource Requirements v Page 8

9 Appendix A Estimate Environment Examples Actual supported user counts depend on compute requirements based on Resource Determination Factors on Page 2. Small Scale & Standard Client/Server Up to 100 Users Client Application Each machine One Server for: Database RDS Client/Server Up to 1,000 Users Client Application RDS/Citrix Server Servers for: Database RDS/Citrix Server Client/Server Database Failover Up to 1,000 Users Client Application Each machine Servers for: Databases RDS Client/Server Database Failover 1,000+ Users Client Application RDS/Citrix Server(s) 1 Servers for: Databases RDS/Citrix Server(s) 1 1 RDS/Citrix Servers can be scaled to meet user volume demand. B2W Software Resource Requirements v Page 9

10 Appendix B Operational Suite Environment Examples Small Scale 1 50 Users One Server for: Application, Database & Reporting SQL Server w/ SSRS Dual-node Users Two Servers: Application Database & Reporting SQL Server on Database node Kerberos Authentication required Simple Multi-node Up to 500 Users Three Servers: Application Database Reporting SQL Server on Database & Reporting nodes Kerberos Authentication required Database Failover Up to 1,000 Users Separate Servers for: Application Primary Database Secondary Database File Share Witness (not shown) Reporting Other Requirements: SQL Server Enterprise with Availability Groups Windows Failover Clustering Kerberos Authentication B2W Software Resource Requirements v Page 10

11 High Availability & Database Failover 1,000+ Users Separate Servers for: Each Application Node Primary Database Secondary Database File Share Witness Each Reporting Node Other Requirements: SQL Server Enterprise with Availability Groups Hardware/Software Load Balancer Windows Failover Clustering Kerberos Authentication The above HADR example represents two application and two reporting nodes, but this configuration can be horizontally scaled. Report Servers should be load-balanced in high report volume environments. B2W Software Resource Requirements v Page 11

12 Appendix C Windows Server Optimizations & Recommendations The out-of-box installation of any edition of a Windows Server Operating System is configured for a middle-of-the-road performance baseline. This configuration is seldom optimal, and if left as is, leads to sub-optimal performance. Certain configuration settings are of the set-once-and-done category, while others require monitor-and-tweak category. This document identifies settings that B2W recommends for adjusting your configuration and environment. Overall Performance Settings 1. Set the Visual Effects option to Adjust for Best Performance and Processor Scheduling option to Background Services: 2. Set the Power Plan option to High Performance: B2W Software Resource Requirements v Page 12

13 Disk Timeout Setting a lower disk timeout is can be beneficial in reporting potential issues faster, whether attached single disk, SAN or other disk array. The Windows Server disk timeout setting is stored here: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Disk\TimeOutValue The default setting is 60 seconds. Typically, a SAN or storage system will retry up to 8 times at the interval stored in the disk timeout. This scenario could translate to minutes before Windows reports any issues with the disk array and/or storage connection, during which time it will appear to be unresponsive or frozen depending on the data operation in question. At the default setting of 60 seconds, I/O Timeouts will not be exposed in the Windows Event log until after 60 seconds AND the timeouts have expired, so effectively, this translates to an 8-minute delay before the I/O is retried. Microsoft is recommending that the disk timeout value be set as low as possible, and no greater than 20 to 30 seconds at a maximum, so you can decrease the time to recovery on dropped I/O packets. Setting this timeout too low could prematurely trigger a timeout on a device that has not had time to spin up after being asleep. On systems that are not only using SAN storage, a low setting could cause premature timeouts on local disks that aren't given adequate time to spin up after being asleep. A practical example is with SQL Server, which will generate an Application Event any time an I/O takes longer than 15 seconds. With a default disk timeout of 60 seconds, you will not see any System events generated for I/O timeouts unless its longer than 60 seconds. A confusing manifestation of this issue is the application acting slow, SQL reporting I/O timeouts and no Windows Events logged. A disk timeout seconds is recommended. Windows File System Settings Last Access Timestamp Disabling last access timestamp and improve performance, but can affect things like Windows Search and custom backup scripts. If these things aren't utilized on your servers, then it's beneficial to disable last access timestamp. The following command can be run from an Administrator Command Prompt: fsutil behavior set disablelastaccess 1 Disable 8.3 MS-DOS filenames The use of 8.3 file names and directories for all long file names and directories on NTFS partitions may decrease directory enumeration performance. An 8.3-compliant file name refers to MS-DOS file-naming conventions. These conventions restrict file names to eight characters and optional extensions to three characters. Although disabling 8.3 file name creation increases file performance under Windows, it's possible some applications (32-bit or 64-bit) may not be able to find files and directories that have long file names. If you are unsure do not disable, otherwise, the following command can be run from an Administrator Command Prompt: fsutil behavior set disable8dot3 1 B2W Software Resource Requirements v Page 13

14 Pagefile Settings Windows is a virtual memory operating system, where each process is given its own virtual address space. Applications are loaded into the process space, and as low memory condition is detected, the operating system moves least-used pages from RAM to a page file (a process called Paging ). The page file is a special file used by the operating system to store modified pages, and is a physical extension of the RAM installed. The page file is also used to store information if the system crashes, facilitating a postmortem analysis of the crash. If the server exhausts available RAM, and either there is no page file or the page file is not large enough, applications may crash or hang because the operating is unable to allocate more memory. In some cases, the operating system may itself become unstable. The term Commit Limit refers to sum of physical memory and size of all page files that the operating system can use to allocate memory. This is also known as the System Commit. The Commit Limit may be increased by adding more RAM, or increasing the size of existing page file(s), or adding additional page file(s). Given the nature of page file, it is essential that it be sized appropriately. However, there is no single number for the size that works across all workloads. To a large extent, the size is influenced by specific workload, and type of server. A reasonable starting point to size the page file is this thumb-rule: set both the minimum and maximum page file size to 3 times the RAM, or 4 GB, whichever is larger. This is just a starting point so to arrive at a reasonably good size, the following steps need to be taken: 1. Start the Windows Performance Monitor 2. Navigate to Data Collector Sets, expand that node, and right-click on User Defined 3. Select New and Data Collector Set from the pop-up menu, select Create Manually 4. Click Next, and select Create data logs, and Performance counter 5. Click Next, and add the following counters: a. \Memory\Commit Limit b. \Memory\Committed Bytes c. \Memory\Committed Bytes in Use 6. Click Next, and specify a folder where the data should be saved 7. Click Next, and select Start this data collector set now 8. Click Finish It is vital that the information be collected over a reasonably long periods of time (at least one week). It is highly recommended that this be done when the server is under its peak load. Once the data is collected, the page file size can be computed as follows: Page File Size = (Maximum value of Committed Bytes * 1.2) RAM size For Example: If the maximum value of Committed Bytes is 34 GB, and the RAM size is 32 GB, then the page file size is (34 * 1.2) 32 = 8.8 GB. The minimum and maximum size (which was set initially using the thumb rule) can now be set to the above value. Best results are achieved when the page file is put on a physical disk that is different from the one that is hosting the operating system. B2W Software Resource Requirements v Page 14

15 Appendix D OS/SQL/.NET Compatibility Matrix B2W Software Resource Requirements v Page 15