High Availability Options for Kronos Workforce Central Suite on SQL Server

Transcription

1 High Availability Options for Kronos Workforce Central Suite on SQL Server Maximize value and operational efficiency throughout your workforce management software Technical Reviewers: Richard Waymire, Solid Quality Mentors Jennifer Green, Kronos Paul Sullivan, Kronos Microsoft Corporation Published: August 2010 Abstract The Kronos Workforce Central suite provides the end-to-end solution to help your company executives, supervisors, and employees excel in all areas of workforce management. Workforce Central automates your laborintensive administrative processes, freeing your workforce to focus on productivity and quality. Microsoft SQL Server database software provides an ideal database platform for Workforce Central. With SQL Server as a foundation, Kronos Workforce Central software can further decrease the time and costs related to managing worker information. This whitepaper provides recommendations for configuring high availability options for the SQL Server database platform running Workforce Central; this paper complements the detailed support documentation provided on the Kronos support Web site. Implementing a high availability solution will improve the availability of Microsoft SQL Server and, therefore, the Workforce Central system so that you can effectively manage your workers, reduce operating expenses, increase productivity, and improve employee satisfaction.

2 Copyright Information The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication. This whitepaper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED, OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in, or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation. Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property Microsoft Corporation. All rights reserved. Microsoft, SQL Server, Hyper-V, MSDN, and Windows are trademarks of the Microsoft group of companies. All other trademarks are property of their respective owners. 2010, Kronos Incorporated. Kronos, the Kronos logo, Workforce Central and Workforce Accruals are registered trademarks, and Workforce Analytics, Workforce Attendance, Workforce HR, Workforce Forecast Manager, Workforce Leave, Workforce Payroll, Workforce Scheduler, Workforce Central Portal, and Workforce Timekeeper are trademarks of Kronos Incorporated or a related company. All other product and company names are used for identification purposes only and may be the trademarks of their respective owners. All specifications are subject to change. All rights reserved.

3 Table of Contents OVERVIEW... 5 KRONOS WORKFORCE CENTRAL: THE SOLUTION FOR WORKFORCE MANAGEMENT... 5 SQL SERVER: AN ENTERPRISE-READY DATABASE PLATFORM FOR WORKFORCE CENTRAL... 6 BETTER TOGETHER: WORKFORCE CENTRAL ON THE SQL SERVER DATABASE PLATFORM... 6 THE WORKFORCE CENTRAL ARCHITECTURE... 7 CLIENT SOFTWARE TIER... 7 WORKFORCE CENTRAL PLATFORM AND APPLICATIONS... 7 DATABASE TIER... 8 HIGH AVAILABILITY OPTIONS FOR SQL SERVER... 8 UNDERSTANDING AVAILABILITY TERMS... 8 Recovery Point Objective (RPO)... 8 Recovery Time Objective (RTO)... 8 Downtime... 8 Nines... 9 YOUR AVAILABILITY STRATEGY... 9 FIRST LINE OF DEFENSE: QUALITY HARDWARE... 9 SETTING YOUR AVAILABILITY GOALS PROCESS AND ADMINISTRATION Proper Staff Training Systems for Testing Deployments Systems for Testing Recovery OVERVIEW OF BACKUP AND RECOVERY STRATEGIES Database Backup Models Database Recovery Models PURCHASING THE RIGHT SKU OF SQL SERVER SINGLE-SYSTEM AVAILABILITY GUIDELINES FOR IMPLEMENTING A BACKUP AND RECOVERY PLAN Importance of Practicing Recovery RESOURCE GOVERNOR USING MULTIPLE SYSTEMS TO IMPROVE AVAILABILITY LOG SHIPPING Log Shipping Servers Setting Up Log Shipping using SSMS Switching to the Secondary Server Switching WFC to the Secondary Database Server Other Log Shipping Details FAILOVER CLUSTERING Failover Clustering Concepts Installing a Failover Clustered Instance of SQL Server... 27

4 Maintaining a Failover Clustered Instance of SQL Server When Should You Use a Failover Cluster? DATABASE MIRRORING REPLICATION SUMMARY LINKS FOR FURTHER INFORMATION... 38

5 Overview Workforce management requires employers to address a multitude of challenges: implementing costreduction measures, improving hiring practices, reducing employee absenteeism and turnover, aligning labor resources with current demand, forecasting future demand, and many others. Businesses often find it difficult to provide the IT resources needed to address these areas and manage their workforce effectively. And without effective employee management, overhead increases and the company becomes less efficient, causing it to miss opportunities and lose productivity. Kronos Workforce Central is one of the most widely deployed solutions used for workforce management in nearly every industry. Using Microsoft SQL Server database software to power Workforce Central lets you take full advantage of the solution s capabilities. By combining the reliable and scalable database infrastructure of SQL Server with Kronos workforce management technology, you get the functionality and the high-quality information you need to manage your employees. You can control labor costs, minimize compliance risk, and improve workforce productivity all without straining valuable IT resources leading to a low total cost of ownership (TCO). The performance of Workforce Central and the underlying SQL Server database platform is critical to employers. The value of business information is time sensitive, so if the workforce management software is running inefficiently, it negatively affects operations and the enterprise s bottom line. This whitepaper, intended for database administrators (DBAs), presents high availability options for Workforce Central on the SQL Server database platform. This guidance can help DBAs optimize uptime for Workforce Central, keeping the system s essential functions available to meet critical business needs. Note that Workforce Central supports Microsoft SQL Server 2005, SQL Server 2008, and SQL Server 2008 R2 database software. Unless there is a specific difference, this document uses SQL Server to refer to all versions. Kronos Workforce Central: The Solution for Workforce Management The Kronos Workforce Central suite provides an end-to-end, integrated solution that gives company executives, supervisors, and employees the ability to see and control all aspects of workforce management. Workforce Central can automate and simplify essential business and administrative processes, eliminating error-prone, labor-intensive manual processes. By taking advantage of these capabilities, organizations can improve workforce productivity and quality and facilitate better decision making, saving both time and money. Workforce Central consists of best-in-class software applications that are fully configurable, making them easy to implement, scale, and maintain. These applications include: Workforce Timekeeper, which provides basic scheduling capabilities to support attendance monitoring, tracking, and pay distribution Workforce Scheduler, which optimizes staff deployment, automates numerous tasks, and provides advanced features to align labor resources with demand

6 Workforce Forecast Manager, which generates accurate, cost-effective schedules by accounting for fluctuations in workforce demand, using historical data and current business drivers to predict future demand Additional applications such as Workforce Attendance, Workforce Accruals, and Workforce Leave provide real-time visibility into all aspects of the labor tracking and reporting process. Workforce Portal and Workforce Analytics can be used to focus, aggregate, and analyze your relevant labor data, while Workforce HR delivers automated processes to reduce the frustration and time associated with managing your employee information. Together, the Workforce Central applications provide a complete solution for workforce management. SQL Server: An Enterprise-Ready Database Platform for Workforce Central Microsoft SQL Server provides an ideal database platform for Workforce Central. SQL Server is a highperformance, integrated database and business intelligence solution for data management and analysis. This easy-to-implement, easy-to-support foundation provides a multifunctional solution for large-scale online transaction processing (OLTP), data warehousing, and e-commerce applications and a solution for data integration, analysis, and reporting. SQL Server can help companies manage large volumes of mission-critical data and run software applications such as Kronos Workforce Central to optimize their business performance. SQL Server can extract and transform data from a variety of sources, including XML data files, flat files, and relational data sources, and then load it into one or more destinations. In addition to rapid data mining, analysis, processing, and reporting capabilities, SQL Server has built-in features that give you a secure, reliable, and productive data management environment that truly protects your data helping reduce the potential risk of corruption. With its scalable infrastructure, SQL Server has the capability to grow with your business and keep up with your toughest data challenges. Better Together: Workforce Central on the SQL Server Database Platform Running Kronos Workforce Central on SQL Server delivers measureable value by channeling workforce data into manageable, automated processes. This decreases administrative time, improves productivity, reduces costs, and generates greater employee satisfaction. Benchmarking tests confirm that SQL Server scales to meet the performance needs of even the largest enterprise customers, while providing lower initial costs and licensing fees. 1 1 Kronos Workforce Central 6.1 with Microsoft SQL Server: Performance and Scalability for the Enterprise,

7 The Workforce Central Architecture Best practices for Workforce Central on the SQL Server database platform start with configuration of the system. It is helpful to review and to have a thorough understanding of the Workforce Central architecture (see Figure 1). Figure 1: Kronos architecture The Workforce Central suite is a Java 2 Enterprise Edition- (J2EE-) compatible set of applications that uses a three-tier structure: the client software tier, the Workforce Central platform and applications, and the database tier. Client Software Tier The client layer contains browsers, operating systems, a Java Runtime Environment (JRE), and other supporting technologies such as Adobe Acrobat Reader. Client computers access a Workforce Central application through a Web URL using a browser. The application functions are then implemented as HTML pages or Java applets. The applets are downloaded via.jar files and use a sticky cache, which means that applets are only downloaded the first time that the client accesses them. Several Workforce Central applications such as Process Designer, Interface Designer, and Workforce Worksheet operate at the client level. Workforce Central Platform and Applications This tier provides the business logic and connections to the back-end database. It contains the common infrastructure, applications, application server, and Web server components, including: Base platform. This consists of data, code, business logic, graphical user interfaces (GUIs), and application programming interfaces (APIs). Modular set of applications and components. These use various extensibility mechanisms. The applications and components are installed separately as needed and are licensed separately. Loosely coupled integration technologies. These technologies connect the pieces of the applications and components with each other and with third-party applications.

8 Database Tier The database tier the focus of the best practices presented in this document stores all of the application data. Note that the two main applications used by most Kronos customers, Workforce HR/Payroll and Workforce Timekeeper, can share a database; the schemas can exist side by side in the database. Because Workforce HR/Payroll supports only SQL Server, you must use SQL Server, and not an alternative database, for combined installations. High Availability Options for SQL Server SQL Server 2005, SQL Server 2008, and SQL Server 2008 R2 have a variety of technical capabilities to address your goals for system availability. As a DBA or systems administrator, you should understand these capabilities so that you can make good choices to optimize your system availability. Key considerations include which edition of SQL Server to purchase and which technologies to deploy on a single system and may include how to configure multiple systems to work together to ensure your availability goals can be met. Understanding Availability Terms A good starting point to any conversation about availability is ensuring that a common language is used. Term definitions are essential to a successful discussion about designing and configuring a high availability solution and meeting your availability requirements. Here are some essential availability terms to understand. Recovery Point Objective (RPO) RPO indicates how much data you are willing to either lose or manually re-enter (if possible) in the event of a system failure. Recovery Time Objective (RTO) RTO indicates how much downtime you are able to accept on a particular system before the impact is too much for your business to tolerate. Downtime Downtime is defined (for the purposes of this paper) as the time that the database system is not available to your application. If the database system is unable (for any reason) to perform work on behalf of your application, then the database is considered to be down. There are two types of downtime: Planned downtime. Many systems have a predefined maintenance window or time that is set aside on a daily or weekly basis for maintenance work to be performed on a system. From a SQL Server perspective, this could be time that is set aside for reorganizing indexes, rolling out upgrades, performing testing on the production system, or creating backups. Planned downtime is a way to prevent the additional load that these activities place on the system from reducing the system s performance.

9 Note: Planned downtime typically does not include tasks such as loading data, which is a normal part of application workflow in many environments. Unplanned downtime. Unplanned downtime represents the time that the database system is unexpectedly unavailable to perform work for your applications. This kind of downtime may be caused by a wide variety of issues with the system, such as: o A runaway query that consumes all available resources o A database that has become corrupt and must be restored o A server crash that makes the entire server unavailable Nines Nines is a term that is used in the context of determining the degree of availability you want your system to have. In most cases, businesses want system availability to be within the 99.x % range. When determining your availability needs, you need to determine how many nines you want to achieve for example, 99% (2 nines) or 99.99% (4 nines). Your Availability Strategy Your availability strategy will vary significantly based on your RPO and RTO needs. Do you have maintenance windows for routine maintenance, or are you required to have your application available 24x7x365? As with many kinds of systems, the higher your availability requirements, the more money it will cost to achieve those requirements. What s the cost to your business if RPO is not zero? Will you lose your customers if you lose data they entered into your system? If your RTO is zero, what kinds of processes and technology will you need to purchase, deploy, and configure to achieve your goals? First Line of Defense: Quality Hardware One of the first considerations for your system availability is high quality hardware. In cloud computing, data centers that use inexpensive, replaceable pizza box servers reduce server costs; this model works reasonably well with the right infrastructure or when data persistence is not an issue. However, with a database server, data persistence is critical, which limits the pizza-box approach for the database server. Still, machines appropriate for running database servers are not necessarily expensive. Prices have dropped dramatically for a quality system with significant amounts of disk and memory. A well configured database server from any of the standard hardware vendors can cost much less than $50,000 and still be scalable and high performing. Your hardware costs may be affected by ensuring that other components also promote higher system availability. Redundant networks, network cards, power supplies, and so on add to the cost of a highly available system, but having them will eliminate different points of failure that could lead to system downtime. Another key aspect of system availability to consider when investing in hardware is the storage subsystem. If you want to take advantage of mirrored copies of the data and transaction logs in storage,

10 or more advanced technologies such as remote mirroring of the disks (more for disaster recovery than availability purposes), a higher initial investment may be required. If you do not use these capabilities, consider RAID 5 or some other level of RAID for basic protection against disk failure. Disk failure should be an expected event. Having the right infrastructure in place to deal with this expected failure is essential to maintaining system availability. Setting Your Availability Goals To determine your high availability needs and which technologies to use, such as which edition of SQL Server to implement or whether to employ multiple systems, you need to know your availability goals. What RPO do you want to achieve? What RTO do you need? If your SQL Server installation is supporting a business-critical system that must always be available, then the combination of people, process, and systems you need to achieve that availability goal will be significantly more than that for a system that can tolerate more planned or unplanned downtime. Many companies define a formal process for setting their availability goals. This paper assumes that you have some process in place for determining those targets and helping answer the following questions: Do I need a dedicated SQL Server DBA? Can I largely automate this system and have it be under someone s desk, or do I need the system monitored at all times to ensure that our high availability goals are met? If you have an IT or data center department, the staff may want a formal Service Level Agreement (SLA) to define exactly what the expectations (and the costs) are for meeting these goals. Calculating Downtime Based on Your Availability Needs As noted above, availability is frequently spoken of as the number of nines you want to achieve for example, 2 nines (99%) or 3 nines (99.9%) of availability. You can use the following equation to calculate the number of hours of downtime your system can tolerate during a year, based on the number of nines you want to achieve: Total available hours/year (Total available hours/year * desired availability/100) The total available hours per year is 8,760 (365 days * 24 hours). So if you want 99% system availability during the year, the equation would look like this: 8760 (8760 * 99/100) The resulting number of hours of downtime for the year is The following table shows a common set of system availability figures based on the number of nines you want to achieve:

11 Availability Goal Hours of Downtime per Year Minutes of Downtime per Year 99% , % % % Process and Administration Although they are not often mentioned in technical whitepapers, other important factors affecting system availability are the processes and people in place to properly support the system. Proper Staff Training If your availability goals extend beyond 99%, you need to have a primary SQL Server DBA and, if possible, a backup DBA on staff. If you run only one instance of SQL Server, you may be able to crosstrain a DBA from some other product to also support SQL Server. It is important to have a backup DBA to fill in when the primary DBA is away for any reason. This training doesn t have to be a formal certification class, but it does need to ensure basic knowledge of administering and troubleshooting the version of SQL Server that you deploy to support your application. If you can t afford to have such expertise on your staff, an alternative is to find a partner company that can provide support and escalation help if you have difficulties with your database. There are many resources to help DBAs and other systems administrators keep current on SQL Server, Windows, and the environmental ecosystem that surrounds your database. Attending conferences, reading books and whitepapers, and being involved with local user groups can help DBAs improve their skills and be better prepared to provide the SQL Server availability your organization needs. Systems for Testing Deployments A key factor in whether a system has sufficient availability has nothing to do with your production server. Having test systems and using them greatly improves the availability of your production databases. You can thoroughly test application changes or customizations on test systems before deploying them to your production system. This practice ensures that routine problems, coding errors, or administrative configuration mistakes will be discovered before they have a chance to disrupt your company s ongoing business operations. Frequently, test systems are seen as a target to save money. The hardware costs, combined with the software licenses, can be a significant investment. However, not having such systems substantially increases the likelihood of system availability problems because you cannot test application changes adequately. And a developer s workstation configuration is not similar enough to your production systems to use as a test system. In the long run, the downtime caused by untested deployments will cost more than the hardware and software for a test system. Systems for Testing Recovery Another important investment area is having one or more systems on which to practice backup and restore operations. A competent and well trained DBA will have a deep understanding of backup and

12 restore. However, there are many issues related to restoring a backup to a point in time that aren t obvious until you attempt to perform a restore operation. Questions include: Are the backups available? Do you understand how to determine the latest differential backup? Which transaction log backups will you need to be able to finish the restore? These are not questions you want the DBA asking during a critical recovery operation, with your business losing money every minute the system is down. If you have a test deployment system, your DBA may be able to use it to also practice recovery operations. Organizations will need to determine that possibility on a case-by-case basis. However, practicing restore operations on a regular basis will keep the DBA sharp and ensure that, if the need arises, the staff is well prepared and recovery operations will proceed smoothly. Overview of Backup and Recovery Strategies A critical part of any system s availability strategy includes backup and recovery. In the event of a single system failure, your only recovery option is to restore from a backup. In fact, if the failure is serious enough, you may have to re-install Windows and SQL Server before you can recover the data. Kronos recommends that you carefully plan, document, and test a backup and recovery strategy and that you store backup files to disk (local or network) or tape. These backups should not be stored on the same server as the database. As an extra precaution, you should store a copy of the backups off-site for disaster recovery. Here is a quick overview of database backup and recovery models; we ll go into more detail later in the paper as we discuss strategies for single-system availability and multiple-system availability. Database Backup Models The scope of a backup can be a whole database, a partial database, or a set of files or filegroups. For each type of backup, SQL Server supports full and differential backups: Full backup. Contains all the data in a specific database or set of filegroups or files as well as enough transaction log information to allow the data to be recovered. Differential backup. Includes database changes since the last full backup. Transaction log backup. Records any database changes. Database file or filegroup backup. Allows copies of specific database files; this type of backup is not recommended for Workforce Central Database Recovery Models There are three recovery models for databases in SQL Server: Full recovery model. This is the best model for preventing critical data loss and restoring data to a specific point in time. This model is generally used by enterprise production systems. If the transaction log is available, you can get up-to-the-minute recovery and point-in-time restore if the end of the transaction log is backed up and restored. The trade-off for the Full recovery

13 model is that it can negatively affect the performance of other operations due to increased logging. The administrative overhead is also higher than with the Simple recovery model. Simple recovery model. This model is appropriate if the data backed up is not critical, the data is static or does not change often, or if data loss is not a concern for the organization. In this situation, the organization loses all transactions since the last full or last differential backup. This model is typical for test environments or production databases that are not mission critical. Bulk-logged model. This model is for environments that have critical data but for which logging large amounts of data degrades system performance or whose bulk operations need to be performed after hours so they do not interfere with normal transaction processing. This model is sometimes used temporarily during data loading and then the system is moved back to the Full recovery model, to improve the performance of data loading operations. The recovery model you select determines which kinds of backups and recovery operations are allowed. It also requires you to change allocations for transaction log space and affects the size of the transaction log backups (if you are using them). In general, Kronos recommends that you have your database in the Full recovery model. Important: It is good practice to test your backup and recovery plan. If possible, simulate a disaster such as an air conditioning failure during a heat wave to make sure that your emergency procedures function as planned. At the very least, rebuild the database from scratch using your backups, and make sure that your system can access the restored database. Purchasing the Right SKU of SQL Server As you move up the scale of improved availability, you will find that the features of the higher-end editions of SQL Server may be beneficial. The SQL Server team continues to put the focus of SQL Server Enterprise Edition (and with SQL Server 2008 R2, Data Center Edition) on performance and scalability. For example, the following chart, adapted from Microsoft s SQL Server Compare Edition Features page, shows that the vast majority of availability technologies in this paper are available only in the Enterprise (and Data Center) editions of SQL Server. Feature Enterprise Edition Standard Edition Database Mirroring Fully supported Yes, but single-threaded, high safety only Log Shipping Fully supported Fully supported Failover Clustering 16-node failover clustering 2-node failover clustering Online Indexing Yes No Mirrored Backups Yes No Backup Compression Yes No Resource Governor Yes No Hot-add Memory and CPU Yes No Fast Recovery Yes No Online Page and File Restore Yes No Database Snapshots Yes No

14 Single-System Availability This section discusses how to improve your availability on a single server without using a secondary (or tertiary) server. With proper administrative efforts, along with effective policies and procedures, you can achieve good availability with a single server. Guidelines for Implementing a Backup and Recovery Plan Keep the following guidelines in mind as you develop and implement a backup and recovery strategy for Workforce Central running on SQL Server in a single-system environment: If you choose the SQL Server Full recovery model, the transaction log can grow very quickly. For this reason, schedule the transaction log to be backed up multiple times throughout the day to ensure that the log is truncated frequently and provides improved data recoverability (smaller RPO and less data loss). If you choose the Simple recovery model, schedule full database backups to occur at least once per day. With this method, data recoverability is limited to the last full database backup. Database backups should be stored off-site if possible to improve your disaster recovery capabilities. Create a Mirrored backup media set, send one copy off-site, and keep the other copy local for faster restore operations in the event of a non-catastrophic event. Have at least one backup device for each database, and give each device a name that clearly describes the database with which it is associated. For example, for a database called timekeepingdb, name the backup device TIMEKEEPERDB_BACKUPS. Back up a database immediately after you make extensive changes or perform non-logged operations. Back up the master database any time you perform an operation that alters the structure of any database. Otherwise, if the master database fails, you lose information about those changes. Also, be sure to include regular backups of the master and msdb databases as part of your overall backup strategy. The master database contains information about the databases on your system and security information such as who can log in to the system. The msdb database stores information about scheduled jobs. Enable the CHECKSUM option on your backup operations to help ensure the integrity of your backups. If you use SQL Server Enterprise Edition, enable backup compression to save space on your backup jobs and speed up restore operations. Checksum is automatically enabled for compressed backups. Importance of Practicing Recovery It can t be emphasized enough: You must practice your restore/recovery operations on a regular basis. System availability will likely be affected by how often your DBAs have practiced restoring the database and/or otherwise recovering from system failures. Your DBAs must be comfortable with restore operations, locations of the database backups, how to request and get a copy of off-site backups, and other aspects of the backup and recovery plan.

15 Resource Governor Resource Governor is an application you can use to restrict the amount of CPU and memory that queries are able to take from SQL Server. Resource Governor is a great option if you can tag connections to SQL Server that you know may consume resources that would take away from higher priority workloads. For example, you could restrict system maintenance activities from consuming more than 25% of the CPU on your SQL Server installation. Resource Governor requires the Enterprise Edition of SQL Server 2008 (or later). For more information about Resource Governor, see the Resource Governor topic in SQL Server Books Online. Using Multiple Systems to Improve Availability As you have seen above, there are many things you can do on a single system that affect your availability. Solid operational best practices and a strong backup and recovery strategy will do more than just about anything else to help ensure availability. And in many cases, sites simply do not have multiple systems and/or copies of SQL Server to take advantage of to improve their system availability. However, for mission-critical systems such as Workforce Central, you should consider further protection options to ensure the availability of your SQL Server database in the event of a single-system failure. These additional options include: Log shipping Failover clustering Database mirroring As you will see as we walk through each option, these features provide much faster availability than having to perform a restore operation on a single-system implementation. As with single-system availability, there is no one right answer when choosing technology. If you have the SQL Server Standard Edition, some choices will not be available to you. You may also be constrained by other factors, such as whether you can afford the storage space to keep a second (or third) copy of your database, logs, and backups. The best approach to choosing a technology is to define your availability goals, review the available technologies, and implement the appropriate technologies that will help you meet your goals. A Note on Domain Membership and Service Accounts For nearly all multi-server availability solutions, there is the need to move data and/or information around between multiple systems. For this to work properly, the SQL Server and SQL Server Agent services will need to have service accounts that can work across the network. Although Kronos does not make a specific recommendation for service accounts, you will find that each of the options for multiple-system installations are easier to implement if you use Windows servers that meet the following criteria:

16 The servers are members of the same domain (or where a trust relationship is established). The servers use service accounts rather than using machine accounts (such as LocalSystem or NetworkService). Note: Technically, in newer versions of Windows (such as Windows Server 2008 or Windows Server 2008 R2), NetworkService can work across the network. For the purposes of this whitepaper, the examples use domain user accounts that support the SQL Server and SQL Server Agent services. Log Shipping Log shipping sends copies of the transaction log from your primary server to a second copy of your database, installed on another instance of SQL Server. In theory, you can have both instances of SQL Server on a single physical server, but that will not really improve your availability. When the transaction log is copied to the secondary server, it is applied in a recovery operation to the existing copy of your database. As each new copy of the transaction log arrives, it too is recovered. You determine how current the secondary server s copy of the database is by deciding how often transaction log backups are created and sent to the secondary server. Log shipping can also have a third server, known as the monitor server, involved in the setup. The monitor server is used to: Keep the history of the log shipping operations Send out an alert if log shipping fails for some reason Be familiar with the following important guidelines before implementing log shipping: Because log shipping is based on the transaction log backups, your database must not use the Simple recovery model. Log shipping is automated through the SQL Server Agent service, so ensure that SQL Server Agent is running. Because log shipping is based on making backups of the transaction log, those now become your production backups. For a restore operation, you need all of the transaction log backups since the last full backup. For example, if you log-ship every 1 minute to a remote system during the day, you may have to restore hundreds of small transaction logs from the last full backup to the current point in time. Log Shipping Servers Let s look in more detail at the servers involved with log shipping. Primary server. The primary server is the instance of SQL Server where your production Kronos SQL Server database resides. You need to connect SQL Server Management Studio (SSMS) to the primary server to perform administrative tasks when setting up log shipping.

17 Secondary server. The secondary server is the instance of SQL Server with a warm standby installation of your production database available. You can have more than one secondary server for disaster recovery purposes. It is recommended that the Windows server you use as a secondary server have roughly the same hardware specifications as the primary server in terms of CPU, memory, and disk I/O to ensure adequate performance if the primary server fails. There are two ways that you can initialize your secondary server s copy of your production Kronos database. You can initialize the database as part of the configuration process for log shipping. Or you can perform a manual recovery of a production database backup yourself before you begin log shipping. Monitor server (optional). A monitor server is used to keep track of the log shipping process itself and to alert the DBA team of any failures in the log shipping process. A monitor server is optional, but if you have a third instance of SQL Server on a separate machine, it is recommended that you also use it for this role. The example configuration we will look at in a moment does not use a monitor server. For more information about monitor servers, see the Monitoring Log Shipping topic in Books Online. Setting Up Log Shipping using SSMS The easiest way to set up, configure, and manage log shipping is to use SQL Server Management Studio (SSMS). You can use Transact-SQL (T-SQL) directly to perform these steps, but for a basic log shipping configuration, there is no advantage to using T-SQL directly. The setup of SSMS starts by having a primary and secondary server installed and configured. As stated earlier, it s easiest if you have used domain user accounts for the SQL Server and SQL Server Agent services to simplify security configurations. Let s look at an example of how to set up log shipping through SSMS. This example uses RWClustN1\LogShipPrimary as the production server instance and RWClustN2\LogShipSecond as the secondary instance. 1. Create a file share location for a copy of the transaction log backups that will be moved from the primary to the secondary server. To do this, log on to the secondary server (RWClustN2), and create a share on a drive with enough space to handle the transaction logs. For this example, the share is called logshipfiles (\\rwclustn2\logshipfiles). Make sure that you: Give the SQL Server and SQL Server Agent service accounts full control over the share and full control permissions at the file system level Allow file and print sharing through the Windows Firewall 2. Start SSMS and connect to the primary server instance. Note: You do not have to be physically using SSMS on the primary server instance; you can use SSMS remotely from your desktop. 3. Right-click the database you want to log ship, and then select Properties, Transaction Log Shipping. The dialog box shown in Figure 2 will appear.

18 Figure 2 - Transaction Log Shipping database properties 4. Check the option called Enable this as a primary database in a log shipping configuration. Then click the Backup Settings button. The dialog box shown in Figure 3 will appear.

19 Figure 3 Transaction Log Shipping job settings 5. On this dialog box, complete the following settings: Network path to backup folder. Specify where you want the transaction log backups to be placed for your log shipping. For this example, the backup folder is the remote server. Delete files older than. Specify how often transaction logs should be deleted. For this example, the setting specifies that transaction logs that are older than 3 days (72 hours) should be deleted. Alert if no backup occurs within. Specify when to send an alert that no backup has occurred. For this example, the setting matches the Delete files older than setting.

20 Job name and Schedule. Specify a name for the transaction log backup job and how often you want it to occur. For this example, the default settings are used. To reduce the chance of data loss, specify a more frequent schedule (for example, every minute). Note: In practice, the amount of activity in your logs may affect your ability to shrink the window for performing and shipping log backups. Set backup compression. Indicate whether to compress the backups. This example assumes that SQL Server Enterprise Edition is being used, so compression is an option. Click OK when you have completed these settings, and return to the transaction log shipping Database Properties screen. 6. On the Database Properties screen, add under the list of secondary server instances and databases, and select the secondary server. For this example, the secondary server is rwclustn2\logshipsecond. The Secondary Database Settings dialog box in Figure 4 will appear. Figure 4 Secondary Database Settings

21 7. If you have not already initialized a backup of your production database, use the default settings on this screen to have SSMS do the initialization. Important: If you have a large database or are trying to set this up in the middle of the day, use an offline backup to restore to the secondary server. Then in this dialog box, select the backup you want to use. 8. Click the Copy Files tab to get to the screen that Figure 5 shows. Figure 5 Copy Files for secondary database settings 9. Enter the file path of the location for your log shipping files. This is the same path you entered earlier. Then, enter a name for the job and a schedule. The frequency of the copy jobs should correspond to the frequency you specified for the transaction log backups. Click the Restore Transaction Log tab, and the dialog box in Figure 6 will appear.

22 Figure 6 The Restore Transaction Log tab of the Secondary Database Settings dialog box 10. On the Restore Transaction Log tab, use the default setting of No recovery mode. Note: This whitepaper does not discuss the standby mode option. If you want to use standby mode, see the topic in Books Online. On this screen, you also have a number of choices for configuring the restore of your backups, including delaying the restore if you want to have a grace period before transaction logs are restored in full. You can also adjust how often the copied transaction logs are restored on your standby server. For this example, the default settings are used. Now, click OK to return to the completed Database Properties screen, which Figure 7 shows.

23 Figure 7 The completed Log Shipping properties dialog box 11. Click OK on this screen, and you have finished configuring transaction log shipping for your database. Figure 8 shows the Save Log Shipping Configuration screen that confirms the configuration. Note: Because log shipping is configured for a single database, you would simply repeat this process if you wanted to log ship another database.

24 Figure 8 The Save Log Shipping Configuration screen shows the log shipping actually taking place Switching to the Secondary Server Once you have completed the log shipping configuration, test that you can switch to the secondary server. When the automated jobs are running, they will back up the transaction log on your primary server, copy them physically to your secondary server, and then restore them to your secondary instance of SQL Server. They will restore the database with the NORECOVERY option so that transaction logs can continue to be restored. Imagine a scenario where you are able to back up the last bit of the transaction log, but otherwise need to switch to your secondary server. How should you handle this case? 1. Take the transaction log backup on your primary server and copy it to your secondary server. 2. Verify that your last log shipping job has run. 3. Restore the last bit of your transaction log without the NORECOVERY option. This will bring the database online and make it available for your users. Switching WFC to the Secondary Database Server After you bring the database online, you will need to change the Workforce Central (WFC) database connection properties to reflect the use of the secondary database. This is accomplished through the WFC SuperUser by logging into WFC and navigating to Setup, System Settings and then selecting the Database tab. On that tab, change the site.database.url and site.database.dotnetdbconnection properties to reflect the new database and then restart WFC. It will connect to the secondary database.

25 Other Log Shipping Details This is where you have a little bit of a pause for further consideration about your log shipping implementation. How do your users switch over to the secondary server? How do they know that something went wrong with the primary server? How do you switch back to the primary server? These topics are beyond the scope of this whitepaper but are issues you must research before deploying log shipping with your production system. Note that one of the major drawbacks of log shipping is that there is no automated client failover or failback solution. However, in terms of automation of the log shipping itself and ease of configuration, this is a straightforward high availability option. Failover Clustering Failover clustering is high availability solution that was introduced in SQL Server 6.5. However, the failover clustering implementation has been extensively modified and rewritten in several releases, including SQL Server 2000, 2005, and SQL Server These modifications have included dramatic changes in the setup program, where much of the work of installing, configuring, and maintaining a failover cluster configuration is done. Conceptually, however, failover clustering has not changed much in all these releases. For Kronos, we will discuss failover clustering for SQL Server 2005, SQL Server 2008, and SQL Server 2008 R2. Failover Clustering Concepts The first step in understanding failover clustering is to understand the terms that are used (or misused) in the technical community. Additionally, failover clustering is much easier to understand once you think of a clustered instance of SQL Server as running on its own logical computer. A cluster is simply one or more computers that are logically thought of as being in a clustered relationship. Logically speaking, a single computer is a cluster of one. When you add a second computer, things get more interesting. A cluster typically means that the computer(s) that are part of the cluster are working for some common purpose. In a Windows Failover Cluster environment, the computers are physically and logically connected by various communications mechanisms and usually have at least one shared disk resource between them. A more typical SQL Server cluster has several disk resources shared between at least two computers. Creating a Windows Failover Cluster requires a series of configuration steps that vary slightly depending on the operating system. This whitepaper assumes Windows Server 2008 R2 as the operating system, and you can read about Windows Failover clustering here. The basic hardware for a cluster is essentially the same as for any other standalone computer but will have a couple of key differences. Although technically not required anymore, most clusters will have at least one disk that is physically connected to both computers in a cluster. Note: Depending on the version of the operating system, you may have many nodes in your cluster. However, for simplicity s sake, this whitepaper will use a 2-node cluster as the standard configuration.

26 Additionally, there are typically at least two network cards in each computer: one for the public network, and one for the computers in the cluster to talk to each other without interference from public networks. Once you have the required computers in a cluster, you install the Failover Clustering Role in Windows Server and then create a logical failover cluster. The rest of this paper assumes you have completed that process and have a cluster with at least one shared disk resource. A Logical Computer When you install SQL Server as a clustered instance, you are asked for several components that look a lot like you are setting up a computer. Underlying a clustered deployment is the fact that Windows is logically creating a virtual computer on the network to host your SQL Server instance. A virtual computer is not the same thing as a virtual machine, which has a separate operating system running for you. However, the virtual computer has a unique IP address (or multiple IP addresses), a unique computer name assigned to your clustered instance, and the shared disk resources that the clustered SQL Server uses to store data and log files. All of these resources will be installed in a cluster group by SQL Server setup. On top of all of these resources is an instance of SQL Server, including the SQL Server and SQL Server Agent services. If you wanted to, you could also install a clustered instance of SQL Server Analysis Services. However, Analysis Services is typically not needed to support a Kronos environment. Once everything is installed, you have a virtual instance of SQL Server running on a single node of the cluster (a computer in the cluster). Logically, however, you can think of having a virtual SQL Server available for connections just as if it were installed standalone on that computer. The difference is that you connect to the instance using the computer name assigned to the cluster not the physical computer name on which SQL Server happens to be running at the moment. The key advantage of a failover cluster is that when the system fails over to the other computer in this example, the other computer in the two-node cluster the name of SQL Server remains the same. The same is true of the IP address(es). So while there may be some amount of downtime while switching nodes, from the client s perspective, they will notice only that SQL Server is down for a very brief time (seconds or minutes) and then is available again to receive connections. Unlike with log shipping, with failover clustering, there is no administrative intervention, and clients don t need to know the name of the secondary server or make any changes to their client-side configurations. After a failover, things just work. Active-Active Some users might want to have an active-active cluster configuration, which is multiple computers that serve up a single workload of SQL Server. Currently, that is not possible with SQL Server. As an alternative, you implement a separately installed SQL Server instance: one instance on one node of your cluster, and another instance on the other node of the cluster by default.

27 An active-active cluster is a way to further justify the expense of the hardware for a cluster so that one server is not sitting idle waiting for a failover to happen. However, one drawback to this strategy is that if there is a failure of one of the nodes, there will be significantly reduced CPU and memory capacity because the two instances of SQL Server are now running on a single computer. So why not add a third computer and in the event that node1 or node2 fails, have the default failover go to node3? That is certainly possible, and you can continue to scale that out for up to 16 nodes. However, you need the Enterprise or Datacenter editions of Windows and SQL Server to implement that strategy. Active-Passive The active-passive configuration strategy is pretty straightforward. You have a clustered instance of SQL Server installed, one computer (node) hosting the instance of SQL Server and SQL Server Agent, and the other node available in case anything goes wrong. Other than the cost of hardware that is idle except when a failover occurs, active-passive is an ideal configuration. Why? When a failure does occur and the memory and CPU configuration are identical for the two computers, operations continue shortly after a failover as if nothing had happened. From an end-user perspective, the Kronos application continues to function, and the same level of CPU and memory is available to process queries and support the application. In addition, you need only one SQL Server license for a 2+ node active-passive configuration. Installing a Failover Clustered Instance of SQL Server The installation procedure for SQL Server failover clustering has changed with every release of SQL Server. However, it is largely the same from SQL Server 2008 to SQL Server 2008 R2. The installation example in this section uses the setup steps for SQL Server 2008 R2. There are two types of installations of failover clustering: a one-part setup or a two-part setup that includes a prepare phase. The example in this section demonstrates the one-part setup of a failover cluster. Note: To save space, this whitepaper shows only the unique dialogs for a failover cluster. 1. To start, launch the SQL Server setup utility. To do this, click the Installation link in the SQL Server Installation Center, and then select the option called New SQL Server failover cluster installation, shown in Figure 9.

28 Figure 9 SQL Server Installation Center The installation program checks the setup support rules, and then the setup support tools installation runs, as with a normal setup. After the setup support tools are installed, the setup support rules are checked again, this time focusing on a number of cluster-specific checks, as Figure 10 shows.

29 Figure 10 Setup Support Rules with Cluster Validation If the word Warning appears in the Status column for a rule, investigate what the warning means. For purposes of this example, disregard the warnings. 2. Click Next to open the Product Key dialog box, and do the following: a) Enter the product key and accept the license agreement. b) For Feature Selection, select the database engine services. You do not need Analysis Services or Reporting Services for Kronos. c) Select a unique instance name. The instance name must be unique across all nodes of your cluster. d) If this is a new cluster, select a default instance. If you have other instances of SQL Server already installed on your cluster, select a named instance. 3. On the Cluster Resource Group screen, shown in Figure 11, you see what appear to be several errors. They are not errors; the text just indicates that other cluster groups already exist in the cluster. Simply click Next to create a new group for SQL Server.

30 Figure 11 Cluster Resource Group 4. Now click Next to arrive at the Cluster Disk Selection dialog box, shown in Figure 12. Select the shared disks that you want to use for your SQL Server data and transaction log files. You should have at least one disk for database files and one disk for transaction log files.

31 Figure 12 Cluster Disk Selection 5. Clicking Next will bring you to the Cluster Network Configuration dialog box, shown in Figure 13. On this screen, you can either specify manual IP address configurations for both IPv4 and IPv6 or use DHCP. DHCP is easier to use, but many server administrators prefer fixed IP addresses for servers.

32 Figure 13 Cluster Network Configuration 6. When you click Next, you ll see the Cluster Security Policy dialog box, shown in Figure 14. You can use either Service SIDs (i.e., use built-in accounts with new capabilities in Windows Server 2008 and above) or domain groups, as in earlier versions of SQL Server. Service SIDs cause fewer system management issues, so if you do not have to use domain groups for another reason, use Service SIDs.

33 Figure 14 Cluster Security Policy 7. Click Next to arrive at the Server Configuration dialog box, shown in Figure 15, where you select your service account. This is very similar to any other setup of SQL Server, but note that you can t change the startup type for the services because the clustering service will take care of starting and stopping the services.

34 Figure 15 Service Account Configuration 8. After you configure the service accounts, click Next. The Service Account Configuration dialog box will appear. Add yourself as an administrator, and click Next to access screens that let you turn on error reporting and run the cluster installation rules. When the Install button appears, click it to run the installation. When the process finishes, you will have successfully installed a clustered installation of SQL Server. Although you now have a single-node cluster installation of SQL Server, this won t improve your system availability yet because the cluster is capable of running only on a single node. You need to install SQL Server on a second node. 9. To create a SQL Server installation on the second node of the cluster, launch SQL Server setup on that node and follow the same procedure as above except in these areas:

35 After the Setup Support Rules dialog box, you will see a Cluster Node Configuration dialog box, which Figure 16 shows. Your instance should be automatically selected for you to add the current node to your cluster. Click Next. Figure 16 Cluster Node Configuration You cannot change service accounts; they will be the same as the other node of the cluster. Enter any passwords if you used domain accounts. During the procedure, you will see Add Node Rules for clustering. You should see only success messages. When you finish the procedure, you will have a two-node cluster installation of SQL Server. If you wanted a 3- or 4-node cluster, you would repeat this process on each node for each instance of SQL Server that you install in your cluster. Maintaining a Failover Clustered Instance of SQL Server Maintaining a failover clustered instance of SQL Server is very similar to maintaining any other instance of SQL Server. However, there are a couple of critical exceptions:

36 Service control. You don t use the SQL Server Configuration Manager utility to control clustered services. Instead, you use the Windows Failover Cluster Manager, shown in Figure 17. For example, if you want to stop and restart SQL Server Agent, you select Take this resource offline in the context menu, and then select Bring this resource online to complete the restart. Figure 17 Windows Failover Cluster Manager Service packs. When you install a service pack on a failover cluster, you must follow the directions in the readme file for the service pack. You install the service pack on each node of the cluster. Follow the directions carefully to ensure a successful installation of the service pack. When Should You Use a Failover Cluster? Basic protection from single-system failure is provided by a Windows Failover Cluster. If you want to provide protection from system or software errors, failover clustering is often a good choice. It is appealing because IT doesn t have to change connection strings and users don t have to know that there is high availability software running at all. The shared disk is a single point of failure, but that vulnerability can be alleviated through technology such as disk mirroring or, if you have a Storage Area Network (SAN), using SAN mirroring to protect your data and transaction log files.