Professional Documents
Culture Documents
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.
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. 2010 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.
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 ................................................................................................................................10 PROCESS AND ADMINISTRATION......................................................................................................................................11 Proper Staff Training ...........................................................................................................................................11 Systems for Testing Deployments .......................................................................................................................11 Systems for Testing Recovery ..............................................................................................................................11 OVERVIEW OF BACKUP AND RECOVERY STRATEGIES ............................................................................................................12 Database Backup Models....................................................................................................................................12 Database Recovery Models .................................................................................................................................12 PURCHASING THE RIGHT SKU OF SQL SERVER ...................................................................................................................13 SINGLE-SYSTEM AVAILABILITY ............................................................................................................................. 14 GUIDELINES FOR IMPLEMENTING A BACKUP AND RECOVERY PLAN .........................................................................................14 Importance of Practicing Recovery .....................................................................................................................14 RESOURCE GOVERNOR ..................................................................................................................................................15 USING MULTIPLE SYSTEMS TO IMPROVE AVAILABILITY ....................................................................................... 15 LOG SHIPPING .............................................................................................................................................................16 Log Shipping Servers ...........................................................................................................................................16 Setting Up Log Shipping using SSMS ...................................................................................................................17 Switching to the Secondary Server ......................................................................................................................24 Switching WFC to the Secondary Database Server .............................................................................................24 Other Log Shipping Details ..................................................................................................................................25 FAILOVER CLUSTERING ..................................................................................................................................................25 Failover Clustering Concepts ...............................................................................................................................25 Installing a Failover Clustered Instance of SQL Server ........................................................................................27
Maintaining a Failover Clustered Instance of SQL Server ...................................................................................35 When Should You Use a Failover Cluster? ...........................................................................................................36 DATABASE MIRRORING .................................................................................................................................................37 REPLICATION ...............................................................................................................................................................37 SUMMARY ........................................................................................................................................................... 37 LINKS FOR FURTHER INFORMATION .................................................................................................................... 38
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 solutions 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 productivityall without straining valuable IT resourcesleading 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 enterprises 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 systems 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.
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.
Kronos Workforce Central 6.1 with Microsoft SQL Server: Performance and Scalability for the Enterprise, http://www.kronos.com/ms/benchmark2
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.
Database Tier
The database tierthe focus of the best practices presented in this documentstores 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.
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 achievefor example, 99% (2 nines) or 99.99% (4 nines).
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.
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 achievefor 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 87.6. The following table shows a common set of system availability figures based on the number of nines you want to achieve:
restore. However, there are many issues related to restoring a backup to a point in time that arent 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.
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
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.
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.
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.
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:
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 servers 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 Lets 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.
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 servers 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, its easiest if you have used domain user accounts for the SQL Server and SQL Server Agent services to simplify security configurations. Lets 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.
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.
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.
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.
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.
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.
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.
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.
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.
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 2008. 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 simplicitys sake, this whitepaper will use a 2-node cluster as the standard configuration.
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 clusternot 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 computerin this example, the other computer in the two-node clusterthe 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 clients 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 dont 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.
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.
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.
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.
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.
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.
6. When you click Next, youll 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.
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 cant change the startup type for the services because the clustering service will take care of starting and stopping the services.
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 wont 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:
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.
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:
Service control. You dont 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.
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 doesnt have to change connection strings and users dont 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.
Database Mirroring
Kronos has not tested or certified Workforce Central with database mirroring. However, Kronos has not identified any technical reasons why database mirroring would cause problems for Workforce Central. If you are considering database mirroring for your deployment, work with your Kronos support team to address any questions you may have. For information about planning and configuring database mirroring in SQL Server, see the topic in Books Online for details.
Replication
Kronos does not support using replication in the database with Workforce Central.
Summary
Kronos Workforce Central, coupled with Microsoft SQL Server database software, provides you with a complete, strategic solution that easily controls all aspects of workforce management. 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. SQL Server provides an ideal database platform for Workforce Central. Its built-in features deliver reliability and security on a scalable foundation that helps organizations reliably manage large missioncritical workloads and complex business applications. Using the high availability techniques discussed in this paper will improve the availability of Workforce Central and help you avoid and minimize downtime. For more high availability resources, see the links in the following section.
SQL Server information can be found in Books Online: SQL Server 2008 R2 Books Online SQL Server 2008 Books Online SQL Server 2005 Books Online For Kronos and Microsoft news, events, and further information, see the Kronos/Microsoft Alliance page. Following is a list of technical whitepapers that were tested and validated by the SQL Server development team. These can help you learn more about specific SQL Server topics.
High Availability with SQL Server 2008 R2 High Availability and Disaster Recovery at ServiceU: A SQL Server 2008 Technical Case Study SQL Server High Availability Always On Website SQL Server 2008 Failover Clustering Running SQL Server 2008 in a Hyper-V Environment - Best Practices and Performance Recommendations Database Mirroring and Log Shipping Working Together Partial Database Availability Implementing Application Failover with Database Mirroring Database Mirroring Best Practices and Performance Considerations