SteelEye DataKeeper Cluster Edition
v7.5
Technical Documentation
December 2012
This document and the information herein is the property of SIOS Technology Corp. (previouslyknown as SteelEye® Technology, Inc.) and all unauthorized use and reproduction is prohibited. SIOSTechnology Corp. makes no warranties with respect to the contents of this document and reservesthe right to revise this publication andmake changes to the products described herein without priornotification. It is the policy of SIOS Technology Corp. to improve products as new technology,components and software become available. SIOS Technology Corp., therefore, reserves the right tochange specifications without prior notice.
LifeKeeper, SteelEye and SteelEye DataKeeper are registered trademarks of SIOS TechnologyCorp.
Other brand and product names used herein are for identification purposes only andmay betrademarks of their respective companies.
Tomaintain the quality of our publications, we welcome your comments on the accuracy, clarity,organization, and value of this document.
Address correspondence to:[email protected]
Copyright © 2012By SIOS Technology Corp.SanMateo, CA U.S.A.All rights reserved
Table of Contents
All SteelEye DataKeeper Cluster Edition Documentation xviii
Introduction xviii
New Features of SteelEye DataKeeper Cluster Edition v7 xviii
Bug Fixes xxi
Product Definitions and Platforms xxii
Product Requirements xxii
Requirements forWindows 2008 xxiii
Known Issues xxiii
SCVMM 2012 xxiii
Windows Server 2012 xxiii
DataKeeper Cluster Edition Quick Start Guide xxiv
DataKeeper Cluster Edition Quick Start Guide xxiv
Prerequisites and Installation xxiv
Configuration xxiv
2-Node Replicated Cluster xxv
3- or 4-NodeMulti-Site Cluster with Mixed Shared/Replicated Storage xxvi
Management xxvii
Troubleshooting xxvii
Chapter 1: Introduction 1
DataKeeper with High Availability - Cluster Edition Overview 1
Features 2
User Interface 2
SteelEye DataKeeper User Interface 2
DataKeeper Components 3
DataKeeper Service LogOn ID and Password Selection 4
Table of Contents i
Understanding Replication 8
How SteelEye DataKeeperWorks 8
User Accounts and Domain Considerations 9
SteelEye DataKeeper Intent Log 10
Non-Shared Volumes 10
Shared Volumes 10
Configuration Issue 11
Relocation of Intent Log 11
SteelEye DataKeeper Resynchronization 11
Initial Creation of aMirror 12
Example: Whitespace Elimination 12
Synchronous and Asynchronous Mirroring 12
Synchronous Mirroring 13
Asynchronous Mirroring 15
Mirror PAUSED 17
Mirror RESYNCING 18
Read andWrite Operations 19
VolumeConsiderations 20
What Volumes Cannot beMirrored 20
Volume Size Considerations 21
Specifying Network Cards for Mirroring 21
Dedicated LAN for Replication 21
PerformanceMonitor Counters 21
Mirror State Counters 22
Mirror Elapsed Time 22
Mirror State 22
Mirror Type 23
Network Number of Reconnects 23
Write Queue Counters 23
Queue Current Length 23
ii Table of Contents
Queue HighWater 23
Queue Low Water 24
Resynchronization Control Counters 24
Resync Current Block 24
Resync Dirty Blocks 24
Resync Elapsed Time 24
Resync New Writes 25
Resync Pass 25
Resync Total Blocks 25
Resync Phase 25
Chapter 2: Installation 27
Chapter 3: Configuration 28
Requirements/Considerations 28
Sector Size 28
Network Bandwidth 28
Determine Network Bandwidth Requirements 28
Measuring Rate of Change 29
Network Adapter Settings 29
User Accounts and Domain Considerations 30
Firewall Configurations 32
ConfiguringMicrosoft's Windows Firewall with Advanced Security - Example 32
High-Speed Storage Best Practices 36
Configure Bitmaps 36
Disk Partition Size 36
Increase theWriteQueueLowWater Tunable 37
Handling Unmanaged Shutdown Issues 38
Other Recommendations/Suggestions 38
WAN Considerations 38
Initial Synchronization of Data Across the LAN orWAN 39
Verifying Data on the Target Volume 41
Table of Contents iii
Compression 41
Bandwidth Throttle 42
Chapter 4: Administration 43
DataKeeper Event Log Notification 43
Primary Server Shutdown 44
Secondary Server Failures 44
ExtensiveWrite Considerations 45
CHKDSK Considerations 45
DKSUPPORT 45
Event Log Considerations 45
Using Disk Management 46
Registry Entries 46
Registry Entries that MAY beModified 46
BandwidthThrottle † 47
BitmapBaseDir* 47
CompressionLevel † 47
DontFlushAsyncQueue * 48
PingInterval * 48
MaxResyncPasses * 48
TargetPortBase * 49
TargetPortIncr * 49
TargetDispatchPort * † 50
WriteQueueHighWater * † 51
WriteQueueLowWater*† 52
Registry Entries that SHOULD NOT beModified 52
ErrorControl 53
DisplayName 53
ImagePath 53
Start 54
Type 54
iv Table of Contents
ErrorControl 54
Group 55
Start 55
Tag 55
Type 55
BuildDate 56
BuildTime 56
LastStartTime 56
Version 57
BitmapFileValidOnFailover 57
Failover 58
MirrorRole 58
VolumeAttributes 58
BitmapFileEnabled 59
BitmapFileValid 59
Enabled 60
TargetDriveLetter 60
SourceDriveLetter 61
MirrorState 61
MirrorType 62
CleanShutdown 62
BreakUserRequested 62
RemoteName 63
Using EMCMD with SteelEye DataKeeper 63
Mirror State Definitions 63
BREAKMIRROR 64
EMCMD BREAKMIRROR [] 64
CHANGEMIRRORENDPOINTS 64
EMCMD CHANGEMIRRORENDPOINTS 64
1x1Mirror CHANGEMIRRORENDPOINTS Command Example 65
Table of Contents v
2x1Mirror CHANGEMIRRORENDPOINTS Command Example 66
1x1x1Mirror CHANGEMIRRORENDPOINTS Command Example 67
CLEARASR_OK 68
EMCMD CLEARASR_OK [] 68
CLEARSWITCHOVER 68
EMCMD CLEARSWITCHOVER 68
CONTINUEMIRROR 69
EMCMD CONTINUEMIRROR [] 69
CREATEJOB 69
EMCMD CREATEJOB ... 69
CREATEMIRROR 69
EMCMD CREATEMIRROR [options] 69
DELETEJOB 70
EMCMD DELETEJOB [] 70
DELETELOCALMIRRORONLY 71
EMCMD DELETELOCALMIRRORONLY [] 71
DELETEMIRROR 71
EMCMD DELETEMIRROR [] 71
GETASR_OK 71
EMCMD GETASR_OK 71
GETCOMPLETEVOLUMELIST 72
EMCMD GETCOMPLETEVOLUMELIST 72
GETCONFIGURATION 72
EMCMD GETCONFIGURATION 72
GETEXTENDEDVOLUMEINFO 73
EMCMD GETEXTENDEDVOLUMEINFO 73
GETJOBINFO 73
EMCMD GETJOBINFO [] 73
GETMIRRORTYPE 74
vi Table of Contents
EMCMD GETMIRRORTYPE 74
GETJOBINFOFORVOL 74
EMCMD GETJOBINFOFORVOL [|] 74
GETMIRRORVOLINFO 74
EMCMD GETMIRRORVOLINFO 74
GETREMOTEBITMAP 75
EMCMD GETREMOTEBITMAP 75
GETRESYNCSTATUS 75
EMCMD GETRESYNCSTATUS 75
GETSERVICEINFO 77
EMCMD GETSERVICEINFO 77
GETSOURCEMIRROREDVOLUMES 77
EMCMD GETSOURCEMIRROREDVOLUMES 77
GETTARGETMIRROREDVOLUMES 79
EMCMD GETTARGETMIRROREDVOLUMES 79
GETVOLUMEDRVSTATE 79
EMCMD GETVOLUMEDRVSTATE 79
GETVOLUMEINFO 81
EMCMD GETVOLUMEINFO 81
ISBREAKUSERREQUESTED 82
EMCMD ISBREAKUSERREQUESTED 82
ISPOTENTIALMIRRORVOL 82
EMCMD ISPOTENTIALMIRRORVOL 82
LOCKVOLUME 83
EMCMD LOCKVOLUME 83
MERGETARGETBITMAP 83
EMCMD MERGETARGETBITMAP 83
PAUSEMIRROR 83
EMCMD PAUSEMIRROR [] 83
PREPARETOBECOMETARGET 84
Table of Contents vii
EMCMD PREPARETOBECOMETARGET 84
READREGISTRY 85
EMCMD READREGISTRY 85
REGISTERCLUSTERVOLUME 85
EMCMD REGISTERCLUSTERVOLUME 85
RESTARTVOLUMEPIPE 85
EMCMD RESTARTVOLUMEPIPE 85
RESYNCMIRROR 86
EMCMD RESYNCMIRROR [] 86
SETASR_OK 86
EMCMD SETASR_OK [] 86
SETCONFIGURATION 87
EMCMD SETCONFIGURATION 87
STOPSERVICE 88
EMCMD STOPSERVICE 88
SWITCHOVERVOLUME 88
EMCMD SWITCHOVERVOLUME [-f] 88
UNLOCKVOLUME 89
EMCMD UNLOCKVOLUME 89
UPDATEJOB 89
EMCMD UPDATEJOB [ ]... 89
UPDATEVOLUMEINFO 89
EMCMD UPDATEVOLUMEINFO 89
Chapter 5: User Guide 91
Getting Started 91
Choose Your Configuration 91
Disk-to-Disk 91
One-to-One 92
One-to-Many (Multiple Targets) 94
Many-to-One 95
viii Table of Contents
N-Shared-Disk Replicated to One 96
DataKeeper Standalone 97
DataKeeper & Failover Clustering 97
N-Shared-Disk Replicated to N-Shared-Disk 97
DataKeeper Standalone 98
DataKeeper & Failover Clustering 99
N-Shared-Disk Replicated toMultiple N-Shared-Disk Targets 99
DataKeeper Standalone 100
DataKeeper & Failover Clustering 100
Setting Up SteelEye DataKeeper 100
Connecting to a Server 101
Disconnecting from a Server 101
Creating a Job 102
ConfiguringMirrors 102
Creating aMirror 102
Creating theMirror 102
CreatingMirrors With Shared Volumes 103
Safe Creation of a Shared-Storage VolumeResource 106
CreatingMirrors With Multiple Targets 107
Switchover and Failover with Multiple Targets 108
Manual Switchover to a Target Server 109
Source Server Failure - Manual Switchover to a Target Server 110
WorkingWith Jobs 111
Jobs 111
Renaming a Job 112
Deleting a Job 113
Reassigning a Job 113
Switching Over aMirror 113
Requirements for Switchover 114
WorkingWithMirrors 114
Table of Contents ix
ManagingMirrors 114
Pause and Unlock 115
Continue and Lock 115
Partial Resync 116
Break 116
Resync 116
Deleting aMirror 116
Replacing a Target 117
Using the BREAK Command 117
Using the DELETE Command 117
DataKeeper VolumeResize 117
Non-Shared Volume Procedure 118
Shared Volume Procedure - Basic Disk 118
Error Handling: 119
Restrictions 119
Mirror Properties 119
Changing the Compression Level of an ExistingMirror 121
WorkingWith Shared Volumes 122
Managing Shared Volumes 122
Adding a Shared System 123
Removing a Shared System 124
UsingMicrosoft iSCSI Target With DataKeeper onWindows 2012 124
Installation of the iSCSI Target 125
Creation of Mirror and Configuration of Cluster 126
Creation of iSCSI Virtual Disks 130
Setting UpMultiple Virtual Disks Within the Same Target Name 132
Setup of iSCSI Initiator onWindows 2012 132
Using SteelEye DataKeeper Standard Edition To Provide Disaster Recovery For Hyper-V Virtual Machines 134
Considerations 134
Preparing the Environment 134
x Table of Contents
Create and Configure a Hyper-V Virtual Machine 135
Install an Operating System and Any Required Applications in the Virtual Machine 138
Configure the Target Server to Run the Virtual Machine 138
Planned/Unplanned Switchover 142
Planned Switchover 142
Unplanned Switchover 144
Switchback 145
Using Cluster Edition 145
Creating a DataKeeper VolumeResource inWSFC 145
Automatic Creation of aMirror inWSFC 145
Manual Creation of aMirror inWSFC 146
Extending a Traditional 2-NodeWSFC Cluster to a Third Node via DataKeeper 147
Extending a Traditional 2-NodeWSFC SQLServer Cluster to a Third Node viaDataKeeper 161
Extending a Traditional 2-Node Cluster to a Shared-Replicated Configuration 173
Add a Shared Node UsingWindows Server 2008 or 2008R2 173
Add a Shared Node UsingWindows Server 2008R2 "SP1" 173
Using DataKeeper Cluster Edition to EnableMulti-Site Hyper-V Clusters 174
Using DataKeeper Cluster Edition to EnableMulti-Site File Share Resources withWin-dows Server 2003Microsoft Cluster Service 184
Replacing Physical Disk Resource in MSCSWith DataKeeper VolumeResource 190
Split-Brain Issue and Recovery 191
Recovery Procedure: 192
Switchover in an N-Shared x N-Shared Configuration 193
Switchover to a Shared Source Server 195
Switchover to the Current Target System 195
Switchover to a Shared Target System 196
Failover 196
Installing and Using DataKeeper Cluster Edition onWindows Server 2008 / 2012 CorePlatforms 196
Chapter 6: Frequently Asked Questions 200
Awareness of Windows Filenames and Directory Names 200
Table of Contents xi
Question 200
Answer 200
ChangeMirror Endpoints 200
Question 200
Answer 200
ChangeMirror Type 200
Question 200
Answer 201
Create aMirror and Rename Job and Delete Job Actions GrayedOut 201
Question 201
Answer 201
Data Transfer Network Protocols 201
Question 201
Answer 201
Delete and Switchover Actions GrayedOut 201
Question 201
Answer 201
Deleting aMirror FAQ 201
Question 202
Answer 202
Error Messages Log 202
Question 202
Answer 202
Inability to Create aMirror 202
Question 202
Answer 203
Network Disconnect 203
Scenario #1 203
Question 203
Answer 203
xii Table of Contents
Question 203
Answer 203
Question 204
Answer 204
Scenario #2 204
Question 204
Answer 204
What is the best practice when rebooting aWSFC source node/cluster owner? 204
Reclaim Full Capacity of Target Drive 204
Question 204
Answer 205
Resize or Grow Mirrored Volumes 205
Question 205
Answer 205
Server 2012: Server Manager “File and Storage Services” Disk Status 205
Question 205
Answer 205
Split-Brain FAQs 206
Scenario 206
Question 206
Answer 206
Question 206
Answer 206
Question 206
Answer 206
Question 207
Answer 207
Question 207
Answer 207
Question 207
Table of Contents xiii
Answer 207
Question 207
Answer 207
Question 207
Answer 208
Stop Replication Between Source and Target 208
Question 208
Answer 208
Using Volume Shadow Copy 208
Question 208
Answer 208
Volumes Unavailable for Mirroring 209
Question 209
Answer 209
Chapter 7: Troubleshooting 211
Known Issues andWorkarounds 211
Access to Designated VolumeDenied 211
Compatibility Issue with Symantec Endpoint Protection Version 12 211
Counter Logs DoNot Work onWindows 2003 213
PerformanceMonitor - Counter Logs DoNot Work onWindows 2003 213
Error/Message 213
Suggested Action 213
DataKeeper VolumeNot Available as Cluster Resource Type 213
Error/Message 213
Description 214
Suggested Action 214
Failed to CreateMirror 214
User Interface - Failed to CreateMirror - Application Event Log 214
Error/Message 214
Description 214
xiv Table of Contents
Suggested Action 214
Hyper-V Host Cluster Error 214
Failover Cluster Error After Changing Virtual Machine ConfigurationWhile VM IsClustered 214
Description 215
Suggested Action 215
MaxResyncPasses Value 216
Mirroring with Dynamic Disks 216
Suggested Action 216
New Resources Offline But Unlocked 217
WSFC Server - Newly Created Resources Appear Offline But Are Unlocked 217
Error/Message 217
Description 217
Suggested Action 217
Server Login Accounts and Passwords Must Be Same on Each Server in the Cluster 217
Error Message 217
Description/Cause 218
Suggested Action 218
System Event Log - CreateMirror Failed in the GUI 218
Error/Message 218
Description 218
Unable to Determine Previous Install Path 218
Installation - Fatal Error: Unable to Determine Previous Install Path 218
Error/Message 218
Description 218
Suggested Action 219
User Interface - Failed to CreateMirror 219
User Interface - Failed to CreateMirror, Event ID 137 219
Error/Message 219
Description 219
Suggested Action 219
Table of Contents xv
User Interface - Shows Only One Side of theMirror 220
Windows Backup/Recover Not Supported 220
WSFC -MS DTC Resource Failure 221
Error/Message 221
Description 221
Suggested Action 221
WSFC 2008 R2 SP1 Procedure Change 221
Description 221
Suggested Action 221
WSFC Server 221
WSFC Server – Cluster Validation, Clustering SQL Server 2008 221
Error/Message 222
Description 222
Suggested Action 222
Windows Server 2012 Specific Issues 222
Windows Server 2012MMC Snap-in Crash 223
Description 223
Suggested Action 223
Windows Server 2012 -- Simultaneous Move of Multiple Clustered File Server Roles CanResult in DataKeeper Switchover Failures 224
Description 224
Suggested Action 225
Windows Server 2012 Default InformationMissing DuringMirror Creation 225
CreatingMirrors with Multiple Targets 225
CreatingMirrors with Shared Volumes 225
Windows Server 2012 iSCSI Target Role Does Not Support Dynamic Disks 226
Description 226
Windows Server 2012 NIC Teaming Issue 227
WSFC 2012 Cluster Creation Default Setting Issue 228
Description 228
Suggested Action 228
xvi Table of Contents
WSFC 2012 Failover Cluster Manager UI Defect (Delete ActionMissing) 229
WSFC 2012 File Server ResourceManager Event Log Errors 230
Description 230
Suggested Action 230
WSFC 2012 File Shares Cannot be Created for File Server Role Using Server Manager orFailover Cluster Manager 231
Description 231
Suggested Action 231
WSFC 2012 New File Server Type Not Supported 231
Description 231
Suggested Action 232
WSFC 2012 Server Manager -- Incorrect VolumeDisplay 232
Description 232
WSFC 2012 Server Manager -- DataKeeper "Disk" Not Shown as Clustered 234
Restrictions 234
Bitlocker Does Not Support DataKeeper 234
CHANGEMIRRORENDPOINTS 235
Description: 235
Workaround: 235
CHKDSK 235
Description 235
DataKeeper VolumeResize Restriction 235
Directory for BitmapMust Be Created Prior to Relocation 236
Description 236
Intensive I-O with Synchronous Replication 236
Description 236
Path NameRestriction 236
Description 236
Resource Tag NameRestrictions 236
Tag Name Length 236
Valid "Special" Characters 236
Table of Contents xvii
Invalid Characters 237
Index 238
All SteelEye DataKeeper Cluster Edition DocumentationThis WebHelp provides a single, all-inclusive collection of SteelEye DataKeeper Cluster Edition forWindows Technical Documentation. Use this collection for searching across all DKCE forWindowsDocuments.
SteelEye DataKeeper Cluster EditionRelease Notes
Version 7.5(Version 7 Update5)
Important!!Read This Document Before Attempting To Install Or Use This Product!
This document contains last minute information that must be considered before, during andafter installation.
IntroductionSteelEye DataKeeper Cluster Edition (DKCE) is a highly optimized host-based replication solutionwhich integrates seamlessly withWindows Server 2012, Windows Server 2008/2008 R2/2008 R2SP1 Failover Clustering as well as Windows Server 2003 Cluster Service. Features of WindowsServer 2008/2008 R2/2008 R2 SP1 Failover Clustering such as cross-subnet failover and tunableheartbeat parameters make it easier for administrators to deploy geographically dispersed clusters.SteelEye DataKeeper provides the data replicationmechanism which extends both versions ofWindows Clustering, allowing administrators to take advantage of these advanced features tosupport non-shared disk high availability configurations.
Once SteelEye DataKeeper Cluster Edition is installed, a new storage class resource type calledDataKeeper Volume is available. This new SteelEye DataKeeper Volume resource can be used inplace of the traditional Physical Disk shared storage resource to enable geographically dispersedclusters, also known as multi-site clusters.
New Features of SteelEye DataKeeper Cluster Edition v7
Feature Description
New in This Release
xviii Table of Contents
Feature Description
Windows Server 2012 DataKeeper now supports Windows Server 2012. For relatedinformation, see theWindows Server 2012 section below.
Performance Improvements Major performance improvements in I/O bandwidth and CPUutilization for mirroring.
Using iSCSI Target withDataKeeper onWindows Server2012
Support for Microsoft iSCSI Target cluster resources onWin-dows Server 2012 now allows customers to build iSCSI Targetclusters using replicated storage with DataKeeper Cluster Edi-tion. In addition to traditional use cases for iSCSI Target soft-ware, iSCSI Target clusters can also be used in CSVconfigurations allowing for the possibility of using DataKeeperCluster Edition to replicate Scale Out File Server workloads aswell as Hyper-V VMs deployed on CSVs hosted on the iSCSITarget cluster.
General maintenance See Bug Fixes below.
New in DKCE Version 7.4.3General maintenance Bug fixes.
New in DKCE Version 7.4
VolumeResizing DataKeeper now supports resizing of volumes while retainingmirror settings.
Service ID and Password Selec-tion Enhancement
DataKeeper supports authenticated connections via enhancedDataKeeper Service LogOn ID and Password selections.
CHANGEMIRRORENDPOINTSEnhancement
DataKeeper's CHANGEMIRRORENDPOINTS commandhas now been expanded to three nodes.
SQL Server 2012 DataKeeper now supports Windows Server Failover Clustersrunning SQL Server 2012.
New in DKCE Version 7.3.1DataKeeper Core General maintenance.
New in DKCE Version 7.3DataKeeper Core General maintenance.
New in DKCE Version 7.2.2LifeKeeper 7.2.1 compatibility DataKeeper 7.2.2 is compatible with LifeKeeper 7.2.1.
New in DKCE Version 7.2.1
Windows 2008 R2 SP1 support Beginning with Version 7.2.1, DataKeeper supports Windows2008 R2 SP1.
64-bit PerformanceMonitor coun-ters
SteelEye DataKeeper PerformanceMonitor counters are avail-able in both the 64-bit and 32-bit PerformanceMonitor applic-ation.
Table of Contents xix
Feature DescriptionLifeKeeper 7.2.1 compatibility DataKeeper 7.2.1 is compatible with LifeKeeper 7.2.1.
Sector Size Enhancement Support for disks with sector size not equal to 512 bytes.
Documentation
A complete reference providing instructions for installing, con-figuring, administering and troubleshooting SteelEyeDataKeeper forWindows is now available on the Docu-mentation section of the SIOS Technology Corp. website.
New in DKCE Version 7.2Microsoft Data ProtectionMan-ager support
DataKeeper 7.2 supports Microsoft Data ProtectionManager2010 onWindows Server Failover Clustering 2008.
Microsoft System Center VirtualMachineManager support
DataKeeper 7.2 supports Microsoft System Center VirtualMachineManager.
Automatic creation of aDataKeeper VolumeResource inWSFC
DataKeeper 7.2 allows resource to be automatically assignedtoWSFC Available Storage duringmirror creation.
New EMCMD:CHANGEMIRRORENDPOINTS
DataKeeper 7.2 added this command to simplify moving aDataKeeper protected volume to another network location.
DataKeeper Online Help Enhance-ments
“Extending a Traditional 2-NodeWSFC Cluster to a ThirdNode via DataKeeper” added in the DataKeeper 7.2 OnlineHelp.
LifeKeeper 7.2 compatibility DataKeeper 7.2 is compatible with LifeKeeper 7.2.
Subscription-based licensing sup-port
DataKeeper 7.2 supports subscription-based, time-limitedlicensing with an automatic license renewal option.
File Server ResourceManagersupport
DataKeeper 7.2 and later supports Disk Quota functionalityusing File Server ResourceManager onWindows Server 2008R2. File Screening is not supported.
New in DKCE Version 7.1.22+ Node Support in anMSCS/WSFC cluster
Beginning with Cluster Edition 7.1.2, DataKeeper supportsmore than two nodes in anMSCS/WSFC cluster.
Mixed shared storage/replicatedstorage cluster support
Beginning with Cluster Edition 7.1.2, DataKeeper supportsmixed shared storage/replicated storage clusters.
New in DKCE Version 7.1.1
Microsoft System Center VirtualMachineManager 2008 R2* sup-port
DataKeeper v7.1.1 and later supports Microsoft SystemCenter Virtual MachineManager 2008 R2**
Note: Microsoft System Center Virtual MachineManager 2008is not compatible with SteelEye DataKeeper Cluster Editionv7.1.2 (see Known Issues in the DataKeeper TechnicalDocumentation Troubleshooting Section for furtherinformation)
xx Table of Contents
http://us.sios.com/support/sios-product-documentationhttp://us.sios.com/support/sios-product-documentationhttp://us.sios.com/support/sios-product-documentationhttp://us.sios.com/support/sios-product-documentation
Feature Description
New in DKCE Version 7.1One-to-many replication con-figurations
DataKeeper 7.1 and later supports one-to-many replication con-figurations.
New in DKCE Version 7Windows 2008 R2 support DataKeeper Version 7 supports Windows 2008 R2.
Windows Server 2003MSCS sup-port
DataKeeper Version 7 supports Windows Server 2003MSCSfor multi-site clusters.
File Share Resources type sup-port
DataKeeper Version 7 supports File Share Resources type inWSFC.
Integration with SteelEyeLifeKeeper v7 DataKeeper Version 7 is now integrated with LifeKeeper v7
Localized for Japan DataKeeper Version 7 is now localized for Japan
Bug FixesThe following is a list of the latest bug fixes and enhancements.
Bug Description1436 Increase the failover speed of DKCE VolumeResource
2002 File Share list not created/preserved across nodes upon failover/switchover
2096 DK GUI cleanup : DK GUI showing system created job after mirror resource creation fromLK GUI
3189 Using lower case letters for the drive letter in bitmap directory name in registry causesCreate Mirror to hang
3251 Increase replication speed - transmit multiple writes in a single send request
Table of Contents xxi
Product Definitions and PlatformsProduct Requirements
Product Operating Systems Additional Software
ServerComponents
Microsoft Windows:
Server 2003 EnterpriseEdition; 32- or 64-bit version
N/A
Microsoft Windows:
Server 2008 EnterpriseEdition or DatacenterEdition 32- or 64-bit version,SP1 and SP2
Server 2008 R2/2008 R2SP1 Enterprise Edition orDatacenter Edition 64-bitversion
Hotfix – KB 951308
http://support.microsoft.com/kb/951308
If protecting Hyper-V resources, Hotfix KB 958065
http://support.microsoft.com/?id=958065
Note: These hotfixes are not required forWindowsServer 2008 SP2 andWindows Server 2008 R2/2008R2 SP1.
Microsoft Windows:
Server 2012 Datacenterand Standard
See below for details.
User Inter-face
Microsoft Windows:l Server 2003 R1 and
R2l Server 2008 R1,
R2 and R2 SP1l Server 2012 Data-
center and Standardl Vistal XPl Windows 7
Microsoft .Net Framework 3.5 SP1 - download from:http://www.microsoft.com/net
MMC 3.0 - download from:http://support.microsoft.com/kb/907265
Make sure you verify the following settings prior to installing and configuring SteelEye DataKeeperCluster Edition.
l Important: SIOS Technology Corp. recommends that users use Domain accounts that havelocal Admin privileges on all servers running DataKeeper. If you are using Local accounts, theusername and passwords must match on all servers running DataKeeper. Thisrecommendation is for all editions and all platforms.
l TheWindows Failover Cluster environment must be installed and configured prior to installingthe SteelEye DataKeeper Cluster Edition software up to the point of creating your first clusterresource. Follow Microsoft best practices for deploying geographically dispersed clusters,including changing the quorummodemajority node set with a file share witness. If the basic
xxii Table of Contents
http://support.microsoft.com/kb/951308http://support.microsoft.com/?id=958065http://support.microsoft.com/kb/907265
Windows cluster is not configured prior to installing DataKeeper Cluster Edition, arepair installation of DataKeeper Cluster Edition is necessary before you are able tocreate a DataKeeper cluster resource.
Requirements for Windows 2008While installing SteelEye DKCE onWindows 2008, a dialog box will appear asking whether theinstaller shouldmake the system configuration changes described below. If the installer is notallowed tomake these changes, they will need to bemademanually after installation is complete.
l Windows Firewall
l TheDistributed Link Tracking Clientmust be disabled
In addition, if yourWindows 2008 servers are not in a domain, the Local Security policy setting"Network Access: Let Everyone permissions apply to anonymous users" must be enabled. Ifthe servers are in a domain, then this setting is not required.
Known IssuesSCVMM 2012If using DataKeeper with SCVMM 2012, youmust use SP1.
Windows Server 2012For issues and enhancements related toWindows Server 2012, see the following topics in theKnown Issues section of the DataKeeper Cluster Edition Technical Documentation:
l WSFC 2012 Failover Cluster Manager UI Defect
l WSFC 2012 New File Server Type Not Supported
l Manual Creation of aMirror inWSFC
l WSFC 2012 Cluster Creation Default Setting Issue
l WSFC 2012 File Shares Cannot be Created for File Server Resource
l WSFC 2012 Server Manager -- Incorrect VolumeDisplay
l WSFC 2012 Server Manager -- DataKeeper "Disk" Not Shown as Clustered
l Windows Server 2012 Default InformationMissing DuringMirror Creation
l Windows Server 2012MMC Snap-in Crash
l Windows Server 2012 -- Simultaneous Move of Multiple Clustered File Server Roles Can Res-ult in DataKeeper Switchover Failures
l Windows Server 2012 iSCSI Target Role Does Not Support Dynamic Disks
l Using iSCSI Target with DataKeeper
Table of Contents xxiii
DataKeeper Cluster Edition Quick Start GuideTo get started using SteelEye DataKeeper Cluster Edition, refer to the DataKeeper Cluster EditionQuick Start Guide.
DataKeeper Cluster Edition Quick Start GuideThis topic provides step-by-step instructions for installing and configuring DataKeeper ClusterEdition. The series of steps includes links into the documentation that describe each step in detail.
Prerequisites and Installation1. Read the DataKeeper Cluster Edition Release Notes for late breaking information.
2. Firewall Configurations - Make sure you understand what ports must be opened on anyfirewalls.
3. Network Bandwidth - If replicating across aWAN, it is critical that a rate of change analysisbe done to ensure there is adequate bandwidth.
4. DataKeeper is a block-level volume replication solution and requires that each node in thecluster have additional volume(s) (other than the system drive) that are the same size andsame drive letters. Please review VolumeConsiderations for additional information regardingstorage requirements.
5. Configure your Cluster - Prior to installing DataKeeper Cluster Edition, it is important to haveWindows Server configured as a cluster using either a nodemajority quorum (if there is an oddnumber of nodes) or a node and file sharemajority quorum (if there is an even number ofnodes). Consult theMicrosoft documentation on clustering or this article on the Clustering forMereMortals blog for step-by-step instructions. Microsoft released a hotfix that allowsdisabling of a node's vote whichmay help achieve a higher level of availability in certain multi-site cluster configurations. This hotfix and when it should be used is described in this article inClustering for MereMortals.
6. After the basic cluster is configured but prior to any cluster resources being created, install andlicense DataKeeper Cluster Edition on all cluster nodes. See the DataKeeper Cluster EditionInstallation Guide for detailed instructions.
7. Note - If installing DataKeeper Cluster Edition on Windows "Core" (GUI-lessWindows), make sure to read this section for detailed instructions - Installing andUsing DataKeeper Cluster Edition on Windows 2008 Server Core Platforms.
8. If using High-Speed Storage, review High-Speed Storage Best Practices.
ConfigurationThe following sections describe themost common cluster configurations. Follow the instructions inthe section that most likely matches your environment.
xxiv Table of Contents
http://clusteringformeremortals.com/2009/09/15/step-by-step-configuring-a-2-node-multi-site-cluster-on-windows-server-2008-r2-�-part-1/http://clusteringformeremortals.com/2009/09/15/step-by-step-configuring-a-2-node-multi-site-cluster-on-windows-server-2008-r2-�-part-1/http://clusteringformeremortals.com/2009/09/15/step-by-step-configuring-a-2-node-multi-site-cluster-on-windows-server-2008-r2-�-part-1/http://clusteringformeremortals.com/2009/09/15/step-by-step-configuring-a-2-node-multi-site-cluster-on-windows-server-2008-r2-�-part-1/http://support.microsoft.com/kb/2494036http://clusteringformeremortals.com/2009/09/15/step-by-step-configuring-a-2-node-multi-site-cluster-on-windows-server-2008-r2-�-part-1/http://clusteringformeremortals.com/2009/09/15/step-by-step-configuring-a-2-node-multi-site-cluster-on-windows-server-2008-r2-�-part-1/http://clusteringformeremortals.com/2009/09/15/step-by-step-configuring-a-2-node-multi-site-cluster-on-windows-server-2008-r2-�-part-1/http://clusteringformeremortals.com/2009/09/15/step-by-step-configuring-a-2-node-multi-site-cluster-on-windows-server-2008-r2-�-part-1/
2-Node Replicated Cluster
1. The initial configurationmust be done from the DataKeeper UI running on one of the clusternodes. If it is not possible to run the DataKeeper UI on a cluster node, such as when runningDataKeeper on aWindows Core only server, install the DataKeeper UI on any computerrunningWindows XP or higher and follow the instruction in the Core Only section for creating amirror and registering the cluster resources via the CLI.
2. Once the DataKeeper UI is running, connect to each of the nodes in the cluster.
3. Create a Job using the DataKeeper UI. This process creates amirror and adds theDataKeeper Volume resource to the Available Storage*. *Note - If clustering Hyper-V VMs, do not add the DataKeeper Volume Resource toAvailable Storage at the end of the mirror creation process. Instead, allow the mirrorto create but do not choose to register the DataKeeper Volume in Available Storage atthe end of the Mirror Creation Wizard, then follow the instructions on this page, UsingDataKeeper Cluster Edition to EnableMulti-Site Hyper-V Clusters.
4. If additional mirrors are required, you can Add aMirror to a Job.
5. With the DataKeeper Volume(s) now in Available Storage, you are able to create clusterresources (SQL, File Server, etc.) in the sameway as if there were a shared disk resource inthe cluster. Refer to Microsoft documentation for additional information or view this article inClustering for MereMortals for step-by-step cluster configuration instructions.
Table of Contents xxv
http://clusteringformeremortals.com/2009/09/15/step-by-step-configuring-a-2-node-multi-site-cluster-on-windows-server-2008-r2-�-part-1/http://clusteringformeremortals.com/2009/09/15/step-by-step-configuring-a-2-node-multi-site-cluster-on-windows-server-2008-r2-�-part-1/http://clusteringformeremortals.com/2009/09/15/step-by-step-configuring-a-2-node-multi-site-cluster-on-windows-server-2008-r2-�-part-1/http://clusteringformeremortals.com/2009/09/15/step-by-step-configuring-a-2-node-multi-site-cluster-on-windows-server-2008-r2-�-part-1/
3- or 4-Node Multi-Site Cluster with Mixed Shared/Replicated Storage
1. The initial configurationmust be done from the DataKeeper UI running on one of the clusternodes. If it is not possible to run the DataKeeper UI on a cluster node, such as when runningDataKeeper on aWindows Core only server, install the DataKeeper UI on any computerrunningWindows XP or higher and follow the instruction in the Core Only section for creating amirror and registering the cluster resources via the CLI.
2. Once the DataKeeper UI is running, connect to each of the nodes in the cluster. Important - Inorder for DataKeeper to detect that a disk is shared, ALL of the nodes of the cluster must beconnected to through the DataKeeper UI.
3. Prior to creating the DataKeeper Job, the storagemust be configured such that the nodeslocated in the same location each have have access to the shared storage. The instructionsfor the Safe Creation of a Shared-Storage Volume contain the information needed to safelygive both servers access to shared storage once the storage has been provisioned and thesame LUN has been handed off to each of the shared cluster nodes. The process ofprovisioning the storage and handing it off to two or more servers at the same time will bedependent upon the storage array. Please refer to your storage documentation for instructionson provisioning storage for clustered environments.
4. Create a job using the instructions in "CreatingMirrors With Shared Volumes." This processcreates amirror as well as collects information about the shared disks and then adds theDataKeeper Volume resource to the Available Storage.**Note - If clustering Hyper-V VMs, do not add the DataKeeper Volume Resource toAvailable Storage at the end of the mirror creation process. Instead, allow the mirrorto create but do not choose to register the DataKeeper Volume in Available Storage atthe end of the Mirror Creation Wizard, then follow the instructions on this page, Using
xxvi Table of Contents
DataKeeper Cluster Edition to EnableMulti-Site Hyper-V Clusters.
5. If additional mirrors are required, you can Add aMirror to a Job.
6. With the DataKeeper Volume(s) now in Available Storage, you are able to create clusterresources (SQL, File Server, etc.) in the sameway as if there were a shared disk resource inthe cluster. Refer to Microsoft documentation for additional information or view this article inClustering for MereMortals for step-by-step cluster configuration instructions.
ManagementOnce a DataKeeper volume is registered withWindows Server Failover Clustering, all of themanagement of that volumewill be done through theWindows Server Failover Clustering interface.All of themanagement functions normally available in DataKeeper will be disabled on any volume thatis under cluster control. Instead, the DataKeeper Volume cluster resource will control themirrordirection, so when a DataKeeper Volume comes online on a node, that node becomes the source ofthemirror. The properties of the DataKeeper Volume cluster resource also display basic mirroringinformation such as the source, target, type and state of themirror.
For more information, please refer to the DataKeeper Cluster Edition TechnicalDocumentationDataKeeper Cluster Edition Technical Documentation.
TroubleshootingUse the following resources to help troubleshoot issues:
l Troubleshooting issues section
l For customers with a support contract - http://us.sios.com/support/overview/
l For evaluation custmers only - Pre-sales support
Table of Contents xxvii
http://clusteringformeremortals.com/2009/09/15/step-by-step-configuring-a-2-node-multi-site-cluster-on-windows-server-2008-r2-�-part-1/http://clusteringformeremortals.com/2009/09/15/step-by-step-configuring-a-2-node-multi-site-cluster-on-windows-server-2008-r2-�-part-1/http://clusteringformeremortals.com/2009/09/15/step-by-step-configuring-a-2-node-multi-site-cluster-on-windows-server-2008-r2-�-part-1/http://clusteringformeremortals.com/2009/09/15/step-by-step-configuring-a-2-node-multi-site-cluster-on-windows-server-2008-r2-�-part-1/http://us.sios.com/support/overview/mailto:[email protected]:[email protected]:[email protected]
Chapter 1: Introduction
DataKeeper with High Availability - Cluster Edition OverviewSteelEye DataKeeper Cluster Edition (DKCE) is a highly optimized host-based replication solutionwhich integrates seamlessly with Microsoft Windows Server 2008 Failover Clustering (WSFC) andMicrosoft Cluster Server (MSCS). New features of Windows Server 2008 Failover Clustering, suchas cross-subnet failover and tunable heartbeat parameters, make it possible for administrators todeploy geographically dispersed clusters. SteelEye DataKeeper provides the data replicationmechanism which extends Windows Server 2008 Failover Clustering, allowing administrators to takeadvantage of these advanced features to support high availability and disaster recoveryconfigurations.
SteelEye DataKeeper Cluster Edition is a separately licensed product. Once installed, a new storageresource type calledDataKeeper Volume is available in Microsoft Windows Server FailoverClustering andMicrosoft Windows Cluster Server. This new SteelEye DataKeeper Volume resourcecan be used in place of the traditional Physical Disk shared storage resource to enable geographicallydispersed clusters..
Important Consideration: Prior to installing SteelEye DataKeeper Cluster Edition, your MicrosoftWindows Server Failover Cluster environment should be installed and created. This product requiresa SteelEye DataKeeper Cluster Edition License. SteelEye DataKeeper resource type registrationoccurs 60 seconds after detecting a Failover Cluster configuration.
SteelEye DataKeeper Cluster Edition1
Features
FeaturesSome of the features include the following:
l Synchronous or Asynchronous block level volume replication.
l Built-inWAN optimization enabling SteelEye DataKeeper to fully utilize a high speed/highlatency network connection without the need forWAN accelerators.
l Efficient compression algorithms optimizing use of available bandwidth.
l IntuitiveMMC 3.0 GUI.
User Interface
SteelEye DataKeeper User InterfaceThe SteelEye DataKeeper User Interface uses a standardMMC snap-in interface.
2Overview
DataKeeper Components
l The left pane displays the Console Tree view. This includes the Jobs andReports. Currently,there are two reports available - Job Overview andServer Overview. The Job Overviewreport provides a summary of all the jobs on the connected servers. TheServer Overviewreport provides a summary of all themirrors on the connected servers.
l Themiddle pane is theSummary view. This includes information about the selected item.
l The right column is theActions view. This pane appears when activated through theViewmenu. The options available from this pane are the same options available from theActionmenu. This column is divided into two sections. TheActions in the top section apply to thejob and every mirror within the job. TheActions in the bottom section apply only to theselectedmirror.
l At the bottom of themain window, three tabs appear: Mirror, Source Server and TargetServer. These tabs provide information on themirror that has been selected.
DataKeeper ComponentsSteelEye DataKeeper forWindows is comprised of the following components:
l DataKeeper Driver (ExtMirr.sys) - The DataKeeper Driver is a kernel mode driver and isresponsible for all mirroring activity between themirror endpoints.
l DataKeeper Service (ExtMirrSvc.exe) - The DataKeeper Service links the DataKeeper GUIand Command Line Interface to the DataKeeper Driver. All commands tomanipulate themirrorare relayed through the DataKeeper Service to the DataKeeper Driver.
Important: Stopping the DataKeeper Service does not stopmirroring. Sending the driver aPAUSE mirror, BREAK mirror or DELETE mirror command is the only way to interruptmirroring.
SteelEye DataKeeper Cluster Edition3
DataKeeper Service LogOn ID and Password Selection
l DataKeeper Service Log On ID and Password Selection - The DataKeeper Service LogOn ID and Password Selection allows you to select the type of account to be used to start theservice. Domain and Server account IDs with administrator privileges allow improved disasterrecovery when network disruptions occur.
l Command Line Interface (EMCMD.exe) – There is an entire suite of EMCMD commandoptions that can be used to operate DataKeeper.
l DataKeeper GUI (Datakeeper.msc) - The DataKeeper GUI is anMMC 3.0 (MicrosoftManagement Console) based user interface which allows you to control mirroring activity andobtain mirror status.
l Packaging files, SPS scripts, help files, etc.
The following diagram displays how the DataKeeper components interface with the NTFS file systemand each other to perform data replication.
DataKeeper Service Log On ID and Password SelectionDuring a new DataKeeper installation setup, the user will be prompted for a DataKeeper Service LogOn ID and Password.
4Overview
DataKeeper Service LogOn ID and Password Selection
The DataKeeper Service uses authenticated connections to perform volume switchovers andmakemirror role changes across multiple servers. The LogOn ID account chosen to run the DataKeeperService will determine how much authority and permission is available to establish connectionsbetween servers and perform volume switchovers, especially when server or network disruptionsoccur.
Several types of Service LogOn ID accounts are available as follows:
l A Domain Accountwith administrator privileges, valid on all connected servers in the domain(recommended)
l A Server Accountwith administrator privileges, valid on all connected servers
l The Local System Account (not recommended)
Note: ForWorkgroups, use theServer Account option and use the server name \administrator on each system as the Service Account for DataKeeper. You should also logon to all servers using this same Log On ID and Password (see related Known Issue).
Note: The domain or server account usedmust be added to the Local System Administrators Group.The account must have administrator privileges on each server in which DataKeeper is installed.
Please note that the Local System account cannot be authenticated properly in a domain whennetwork connectivity with Active Directory is lost. In that situation, connections between serverscannot be established with the Local System account causing DataKeeper volume switchovercommands, via the network, to be rejected. IT organizations requiring fault tolerance during a disasterrecovery, including network disruptions, should not use the Local System account.
DataKeeper Installation – Service Logon ID Type Selection:
SteelEye DataKeeper Cluster Edition5
DataKeeper Service LogOn ID and Password Selection
If a Domain or Server account is selected above, the DataKeeper Service LogOn ID and PasswordEntry Form is displayed to enter that information.
6Overview
DataKeeper Service LogOn ID and Password Selection
If the DataKeeper Service has previously been configured with a Service LogOn ID and Password,the setup program will omit the Service ID and Password selection dialogs. However, at any time, anadministrator canmodify the DataKeeper Service LogOn ID and Password using theWindowsService Applet. Be sure to restart the DataKeeper Service after changing the LogOn ID and/orPassword.
SteelEye DataKeeper Cluster Edition7
Understanding Replication
Understanding Replication
How SteelEye DataKeeper WorksAt the highest level, DataKeeper provides the ability to mirror a volume on one system (source) to adifferent volume on another system (target) across any network. When themirror is created, all dataon the source volume is initially replicated to the target volume, overwriting it. When this initialsynchronization (also referred to as a full resync of the data) of the volumes is complete, the targetvolume is an exact replica of the source volume in terms of size and data content. Once themirror isestablished, DataKeeper intercepts all writes to the source volume and replicates that data acrossthe network to the target volume.
Replication is performed at the block level in one of two ways:
l Synchronous replication
l Asynchronous replication
Inmost cases, asynchronous mirroring is recommended because of the performance impact ofsynchronous mirroring.
8Overview
User Accounts and Domain Considerations
User Accounts and Domain ConsiderationsBecause DataKeeper will be accessing volumes on both the local server and remote server, there areseveral requirements and recommendations to be aware of when running the DataKeeper Service andthe DataKeeper UI in single domain environments as well as mixed environments and Cluster Editionenvironments.
The following table outlines these requirements:
Environment DataKeeper ServiceRequirementsDataKeeper UIRequirements
SameDomain
or
Trusted DomainEnvironment
l Run the DK Service on allsystems as the sameaccount with the samecredentials
l Okay to use the default =Local System Account
l Log in as adomainadmin andrun the DKGUI
l Or use “runas”Administratoroption to runDK GUI
MixedEnvironmentServers in aMixture ofDomain andWorkGroup
or
Servers inSeparateDomains
l Create a local account oneach system with sameaccount name and password
l Add this local account to theAdministrator Group
l Run the DK Service on allsystems with the localaccount
l Log in usingthe localaccount youcreated torun the DKService
l Run the DKGUI
You shouldalso log onto allserversusing thissame LogOn ID andPassword(see relatedKnownIssue).
SteelEye DataKeeper Cluster Edition9
SteelEye DataKeeper Intent Log
Environment DataKeeper ServiceRequirementsDataKeeper UIRequirements
DataKeeperCluster EditionEnvironment
l Create a local account oneach system with sameaccount name and password
l Add this local account to theAdministrator Group
l Run the DK Service on allsystems with this localadministrator account
l Log in usingthe localadministratoraccount youcreated torun the DKService
l Run the DKGUI
SteelEye DataKeeper Intent LogSteelEye DataKeeper uses an intent log (also referred to as a bitmap file) to track changes made tothe source volume. This log, stored on themirror source system, is a persistent record of writerequests which have not yet been committed to both servers.
The intent log gives SteelEye DataKeeper the ability to survive a source system failure withoutrequiring a full mirror resync after the recovery of the source server.
There is some performance overhead associated with the intent log, since each write to the volumemust also be reflected in the intent log file. Tominimize this impact, it is recommended that the intentlogs be stored on a physical disk that is not involved in heavy read or write activity.
Non-Shared VolumesBy default, this intent log feature is enabled, and the intent log files are stored in a subdirectory called"Bitmaps" under the directory where SteelEye DataKeeper was installed.
To create the intent log file in a directory other than the default location, set the BitmapBaseDirregistry entry to a directory where SteelEye DataKeeper will create the file. (Note: The drive lettermust be in uppercase.) See "Relocation of Intent Log" for more information.
To disable the intent log feature, clear the BitmapBaseDir registry entry (set it to an empty string) onall current and potential mirror endpoint servers. Disabling the intent log requires a reboot oneach of these systems in order for this setting to take effect. Keep inmind that if this feature isdisabled, a full resync will be performed in the event of a source system failure.
Shared VolumesWhen replicating shared volumes, the intent log files are stored in a subdirectory called"ReplicationBitmaps" on the replicated volume itself. This is necessary to allow switchover to theother shared source servers without resulting in a full resync of the data.
10Overview
Configuration Issue
SIOS does not recommend relocating intent logs from their default locations.
Configuration IssueWhen configuring a BitmapBaseDir registry entry, make sure that the folder and drive letter specifiedexist. (Note: The drive letter must be in uppercase.) If configured with a drive letter that does notexist, the followingmessage will be received upon system boot up:
Global bitmap volume {drive letter}: has not been detectedyet. Mirror source threads may hang if this volume does notexist. Check to make sure that the BitmapBaseDir registryentry specifies a valid volume for storage of bitmaps.
Relocation of Intent LogTo relocate the Intent Log (bitmap file), please perform the following on all servers involved:
Note: LEAVE THE MIRROR IN THE MIRRORINGSTATE! Do not pause it and thenmove thebitmap file.
1. If you havemore than one DataKeeper mirror, move all mirrors to a single system so that it issource for all mirrors.
2. On all systems, create the directory for the new location of the bitmap files ( i.e.R:\Bitmaps). Important: If you choose to relocate the bitmap file from the default location(%EXTMIRRBASE%\Bitmaps), youmust first create the new directory before changing the loc-ation in the registry and rebooting the system.
3. Modify the BitmapBaseDir registry value on all systems other than themirror source system toreflect the new location. This includes mirror targets and any systems that share the volumewith themirror source or share with any of the targets.
Edit Registry via regedit:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ExtMirr\Parameters
Modify the "BitmapBaseDir" parameter, change to the new location ( i.e.R:\Bitmaps) (Note: The drive letter must be in uppercase.)
4. Reboot each of the non-source systems. If this volume is part of aWindows cluster, be surethat you do not shut down toomany nodes simultaneously or youmay lose the cluster quorumand cause the cluster to shut down on the remaining nodes.
5. Switch any volumes on the source system over to another system (target or shared source).Repeat Steps 2 and 3 on the system that was previously source.
6. After rebooting the original source system, all volume resources can be switched back to thatsystem.
SteelEye DataKeeper Resynchronization
SteelEye DataKeeper Cluster Edition11
Initial Creation of aMirror
SteelEye DataKeeper performs resynchronization through the use of a bitmap file (intent log). Itallocates memory that is used to keep track of "dirty" or "clean" blocks. When a full resync begins,SteelEye DataKeeper initializes the bit for each block that is in use by the file system to 1 ("dirty"),indicating that it needs to be sent to the target system. A full resync occurs at the initial creation of amirror and during the resync operation after amirror is broken. It then starts at the beginning of thebitmap, finds the first block whose bit is set to 1 or dirty, reads the corresponding block from the localhard disk, and sends it to the remote system. After this has completed successfully, it sets the blockto 0 ("clean"). SteelEye DataKeeper then finds the next dirty bit and repeats this process.
As new writes come in during a resync, the corresponding blocks are set to 1 or dirty.
Once resync gets to the end of the bitmap, it looks to see if there are still any dirty blocks. It does thisthrough a counter that is incremented when one is made dirty and decremented when cleaned. If anyblocks are dirty, it resets its pointer to the beginning of the bitmap and starts again, only sending thedirty blocks to the remote system.
This process continues for multiple passes until all blocks are clean. When this happens, themirrorwill go from theResynchronizing state to theMirroring state, and at that point, every write ismirrored (the bitmap is no longer necessary at that point).
You can follow the resynchronization process by viewing the resynchronization control counters inPerformanceMonitor.
This same resynchronizationmechanism is used when you CONTINUE a PAUSED mirror.
Warning: If the target system is rebooted/shut down via the DK GUI whenmirrors are paused andunlocked, a full resync will occur. To prevent the full resync in this case, be sure to perform a"Continue and Lock" prior to rebooting or shutting down the target system.
Initial Creation of a MirrorWhen themirror is created, DataKeeper must perform an initial synchronization of the data from thesource volume to the target volume. This is referred to as a full resync. However, prior to this initialfull resync of the data, DataKeeper first performs a process called “whitespace elimination” whereall blocks of currently unused space on the source volume are eliminated from the initialsynchronization and those blocks do not have to be replicated to the target volume.
Example: Whitespace Elimination
Source Volume Capacity 80 GB
Source Volume Free Space 35 GB
Amount of data to be resynced from source volume to target volume during initialcreation of the mirror. 55 GB
Synchronous and Asynchronous MirroringSteelEye DataKeeper employs both asynchronous and synchronous mirroring schemes.Understanding the advantages and disadvantages between synchronous and asynchronous mirroringis essential to the correct operation of SteelEye DataKeeper.
12Overview
Synchronous Mirroring
Synchronous MirroringWith synchronous mirroring, each write is intercepted and transmitted to the target system to bewritten on the target volume at the same time that the write is committed to the underlying storagedevice on the source system. Once both the local and target writes are complete, the write request isacknowledged as complete and control is returned to the application that initiated the write.Persistent bitmap file on the source system is updated.
The following sequence of events describes what happens when a write request is made to thesource volume of a synchronous mirror.
1. The following occur in parallel.
a. Write request is intercepted and transmitted to the target system.
b. Target system executes the write request on the target volume and sends the status ofthe write back to the source system.
c. When the target system returns a successful status, the source system executes thewrite to the source volume and returns to the caller.
2. Should an error occur during network transmission or while the target system executes itstarget volumewrite, the write process on the target is terminated. The source system willcomplete the write request on its source volume, and the state of themirror changes fromMirroring toPaused.
SteelEye DataKeeper Cluster Edition13
Synchronous Mirroring
In this diagram, Write Request 1 has already completed. Both the target and the source volumeshave been updated.
Write Request 2 has been sent from the application and the write is about to be written to the targetvolume. Once written to the target volume, DataKeeper will send an acknowledgment that the writewas successful on the target volume, and in parallel, the write is committed to the source volume.
At this point, the write request is complete and control is returned to the application that initiated thewrite.
While synchronous mirroring insures that there will be no data loss in the event of a source systemfailure, synchronous mirroring can have a significant impact on the application’s performance,especially inWAN or slow network configurations, because the applicationmust wait for the write tooccur on the source and across the network on the target.
14Overview
Asynchronous Mirroring
Asynchronous MirroringIn most cases, SIOS recommends using asynchronous mirroring. With asynchronous mirroring, eachwrite is intercepted and a copy of the data is made. That copy is queued to be transmitted to the targetsystem as soon as the network will allow it. Meanwhile, the original write request is committed to theunderlying storage device and control is immediately returned to the application that initiated thewrite. (Note: Certain database applications may send flush commands causing DataKeeper toperform in a synchronous manner. To prevent performance from being impacted in such cases, theregistry entry "DontFlushAsyncQueue" may be set.)
At any given time, theremay be write transactions waiting in the queue to be sent to the targetmachine. But it is important to understand that these writes reach the target volume in time order, sothe integrity of the data on the target volume is always a valid snapshot of the source volume at somepoint in time. Should the source system fail, it is possible that the target system did not receive all ofthe writes that were queued up, but the data that has made it to the target volume is valid and usable.
The following sequence of events describes what happens when a write request is made to thesource volume of a synchronous mirror.
1. Persistent bitmap file on the source system is updated.
2. Source system adds a copy of the write to the Asynchronous Write Queue.
3. Source system executes the write request to its source volume and returns to the caller.
4. Writes that are in the queue are sent to the target system. The target system executes thewrite request on its target volume and then sends the status of the write back to the primary.
5. Should an error occur during network transmission or while the target system executes itstarget volumewrite, the write process on the secondary is terminated. The state of themirrorthen changes fromMirroring toPaused.
SteelEye DataKeeper Cluster Edition15
Asynchronous Mirroring
In the diagram above, the two write requests have been written to the source volume and are in thequeue to be sent to the target system. However, control has already returned back to the applicationwho initiated the writes.
In the diagram below, the third write request has been initiated while the first two writes havesuccessfully been written to both the source and target volumes. While in themirroring state, writerequests are sent to the target volume in time order. Thus, the target volume is always an exactreplica of the source volume at some point in time.
16Overview
Mirror PAUSED
Mirror PAUSEDIn the event of an interruption to the normal mirroring process as described above, themirror changesfrom theMIRRORING state to aPAUSED state. All changes to the source volume are tracked in thepersistent bitmap file only and nothing is sent to the target system.
SteelEye DataKeeper Cluster Edition17
Mirror RESYNCING
Mirror RESYNCINGWhen the interruption of either an Asynchronous or Synchronous mirror is resolved, it is necessary toresynchronize the source and target volumes and themirror enters into aRESYNC state.
DataKeeper reads sequentially through the persistent bitmap file to determine what blocks havechanged on the source volumewhile themirror was PAUSED and then resynchronizes only thoseblocks to the target volume. This procedure is known as a partial resync of the data.
The user may notice a Resync Pending state in the GUI, which is a transitory state and will changeto theResync state.
During resynchronization, all writes are treated as Asynchronous, even if themirror is a Synchronousmirror. The appropriate bits in the bitmap aremarked dirty and are later sent to the target during theprocess of partial resync as described above.
18Overview
Read andWrite Operations
Read and Write OperationsAfter the volumemirror is created and the two drives on the primary and secondary servers aresynchronized, the following events occur:
l The system locks out all user access to the target volume; reads and writes are not allowed tothe target volume. The source volume is accessible for both reads and writes.
l Bothmirrored and non-mirrored volume read operations arriving at the driver on the primaryserver are passed on and allowed to complete normally without intervention. Reads of amirrored volume on the secondary system are not allowed, i.e., the secondary has notassumed the role of a failed primary.
l Whenever the primary server receives a write request, the system first determines whetherthe request is for amirrored volume. If not, the write is allowed to complete normally withoutany further intervention. If the write request is for amirrored volume, the request is handleddepending on themirroring type:
l If the type is synchronous, then the write request is sent to both the source and targetvolumes at the same time. Should an error occur during network transmission or while
SteelEye DataKeeper Cluster Edition19
VolumeConsiderations
the target system executes its write, the write process on the target is terminated. Thesource will then complete the write request, and the state of themirror changes fromMirroring toPaused. The write operation is not acknowledged as complete until thesource disk write completes and notification from the target is received (success orfailure).
l If the type is asynchronous, then the primary executes the write request to its sourcevolume, puts a copy of the write on the asynchronous write queue and returns to thecaller. Writes that are in the queue are sent to the target volume. The secondarysystem executes the write request on the target volume and then sends the status ofthe write back to the primary. Should an error occur during network transmission orwhile the secondary executes its mirrored volumewrite, the write process on thesecondary is terminated. The state of themirror then changes fromMirroring toPaused.
To ensure uninterrupted system operation, SteelEye DataKeeper momentarily pauses themirror andautomatically continues it (i.e., performs a partial resync) in the following cases:
l In Asynchronous mirroring, when the asynchronous write queue length reaches theWriteQueueHighWater mark due to amassive number of writes to the volume in a short periodof time (e.g., database creation). The user canmonitor themirroring behavior using theSteelEye DataKeeper PerformanceMonitor counters and adjust theWriteQueueHighWatermark if necessary. See Registry Entries for more details.
l When transmission of a write to the target system times out or fails due to resource shortage(e.g., source system resource starvation due to a flood of writes/network transmissions in ashort period of time).
Volume ConsiderationsSteelEye DataKeeper primary and secondary systems have three types of volumes: system, non-mirrored andmirrored. Duringmirroring operations, system and non-mirrored volumes are not affectedand the user has full access to all applications and data on these volumes.
What Volumes Cannot be MirroredThe SteelEye DataKeeper service filters out the following types of disk partitions:
l Windows system volume
l Volume(s) that contain theWindows pagefile
l Non-NTFS formatted volumes (e.g. FAT, FAT32, Raw FS)
l Non-fixed drive types (e.g. CD-ROMs, diskettes)
l Target volumes that are smaller than the source volume
20Overview
Volume Size Considerations
Volume Size ConsiderationsThe source and target systems are not required to have drives of the same physical size. When themirror is established, the target volumemust be the same size, or larger than the source volume.
There is no limit on the size of volumes that can participate in a SteelEye DataKeeper mirror.However, you should be aware that on initial mirror creation, all data that is in use by the file systemon the source volumemust be sent to the target. For instance, on a 20GB volumewith 2 GB usedand 18GB free, 2 GB of datamust be synchronized to the target. The speed of the networkconnection between the two systems, along with the amount of data to be synchronized, dictateshow long the initial mirror creation will take.
Specifying Network Cards for MirroringSteelEye DataKeeper allows the administrator to specify which IP addresses should be used asmirror end-points. This allows the replicated data to be transmitted across a specific network whichpermits the user to segment mirrored traffic away from the client network if desired.
Dedicated LAN for ReplicationWhile it is not required, a dedicated (private) network between the two servers will provideperformance benefits and not adversely affect the client network.
Performance Monitor CountersSteelEye DataKeeper provides counters that extend PerformanceMonitor with statistics about thestatus of mirroring on volumes. The counters are installed during the full installation of SteelEyeDataKeeper software.
To access the counters, do the following:
1. On aMicrosoft Windows 2003 system, start theWindows PerformanceMonitor through theStart menu in the Administrative Tools program group by selecting Performance.On aMicrosoft Windows 2008 system, start theWindows PerformanceMonitor through theStart menu in the Reliability and Performance group.
2. Select SystemMonitor from the Console Root pane.
3. Click the + button in the chart pane to open the Add Counters dialog box.
4. Select the SIOS Data Replication object.
On a system with amirror in the Source role, there will be one instance available for each target ofthat mirror.
SteelEye DataKeeper provides 14 counters that allow themonitoring of various operations related tothe product. These counters allow themonitoring of such things as status, queuing statistics andgeneral mirror status.
SteelEye DataKeeper Cluster Edition21
Mirror State Counters
Mirror State CountersMirror Elapsed TimeDefault Value: 0
Range: 0 - MAX_ULONG
This value represents the amount of time, in seconds, that the volume has been inMirror state. Thisvalue will be 0 for volumes that are not currently involved in amirror, volumes that are currentlyundergoingmirror creation (and synchronization), and volumes for which amirror has been broken ordeleted.
Mirror StateDefault: 0
Range: 0 - 5
This value represents the current mirroring state of a volume. The following values are defined:
0 None - The volume is not currently involved in amirror.
1 Mirroring - The volume is currently mirroring to a target.
2 Resynchronizing - The volume is currently being synchronized with its target.
3 Broken - Themirror exists but the source and target volumes are not in sync. New writes to thevolume are not tracked.
22Overview
Mirror Type
4 Paused - Themirror exists but the source and target volumes are not in sync. The source serverkeeps track of any new writes.
5 Resync Pending - The source volume is waiting to be resynchronized.
Mirror TypeDefault: 0
Range: 0-2
This value represents the type of mirroring this volume is engaged in. The following values aredefined for this release:
0 None - The volume is not currently involved in amirror.
1 Synchronous - Data is written to the target volume first.
2 Asynchronous - Data is written to the source volume first and queued to be sent to the target.
Network Number of ReconnectsDefault: 0
Range: 0 - MAX_ULONG
This value is the number of network reconnections that have beenmade while the volume has beenmirrored. A network reconnection occurs when communication is lost with the target.
Write Queue Counters
Queue Current LengthDefault Value: 0
Range: 0 -
This value represents the current length, in terms of number of writes, of the SteelEye DataKeeperAsynchronous write queue for volumes currently beingmirrored. Writes to the target system arepushed onto a queue and committed to the target at a later time, allowing writes to complete locallyfirst.
Queue High WaterDefault: 20000
Range: 0x4e20
SteelEye DataKeeper Cluster Edition23
Queue Low Water
This counter displays the Asynchronous write queue high water mark as set in the registry. Duringmassive I/O traffic, if the Queue Current Length (above) reaches this value, the SteelEye DataKeeperdriver will momentarily pause themirror, drain the queue down to the Queue Low Water mark (below)and automatically start a partial resync.
Queue Low WaterDefault: 150
Range: 0x96
This counter displays the Asynchronous write queue low water mark as set in the registry. Duringmassive I/O traffic, if the queue length reaches theWriteQueueHighWater mark (above), theSteelEye DataKeeper driver will momentarily pause themirror. When the queue length goes down tothe Queue Low Water mark, the SteelEye DataKeeper driver will automatically start a partial resync.
Resynchronization Control Counters
Resync Current BlockDefault: 0
Range: 0 -
During the synchronization process, this value represents the current block that is being sent to thetarget. At other times (i.e. whenmirror state is not EmMirrorStateResync), this value will be 0.
During synchronization, a given block may be sent to the target multiple times if writes are ongoing tothe volume. This is based on the number of resync passes that are required.
Resync Dirty BlocksDefault Value: 0
Range: 0 -
This value is the number of total blocks that are dirty duringmirror resynchronization. "Dirty" blocksare those that must be sent to the target machine before synchronization is complete. This value willbe 0 for all states other than EmMirrorStateResync.
When amirror synchronization is begun, this value will be initially equal to the value of Resync TotalBlocks. Please note that during amirror synchronization, Resync Dirty Blocks may actually increaseif a large number of incoming writes aremade to the volume.
Resync Elapsed TimeDefault Value: 0
24Overview
Resync New Writes
Range: 0 - MAX_ULONG
While themirror is being synchronized, this value represents the elapsed time in seconds that thesynchronization has been occurring. After amirror is successfully resynchronized, the valuerepresents the total amount of time the previous synchronization operation took since the last systemboot. The value will be 0 for volumes that either never have been synchronized or volumes that werenot synchronized during the last boot.
Resync New WritesDefault: 0
Range: 0 - MAX_ULONG
This value represents the number of writes that have occurred on the volume since a synchronizationoperation has begun. This value will directly affect the number of dirty blocks, the number of passesrequired to synchronize themirror and the amount of time the synchronization takes to complete.
Resync PassDefault Value: 10
Range: 0 - MaxResyncPasses (Registry)
This value is the number of passes that have currently beenmade through the volume during theresynchronization process to update the target. The number of passes required to complete thesynchronization process will increase based on the amount of writing that is being performed duringsynchronization. While writing to the source volume is allowed during synchronization, heavy writeswill cause the synchronization to take longer, thus resulting in amuch longer time until it is finished.
Resync Total BlocksDefault Value: 0
Range: 0 - MAX_ULONG
This value represents the number of 64k blocks used for resynchronization of themirrored volume.The value is approximately equal to the file system size of the volume divided by 64K. Please notethat the file system size is less than the partition size of the volume that is shown in theWindowsDisk Management program. To see the file system size, type CHKDSK X: (where X is the driveletter).
Resync PhaseDefault Value: 0
Range: 0 - 3
Themirror resync goes through a number of phases. Once the state is set to "resync", the phase isinitialized to RESYNC_INITIAL_PHASE. If a full resync is to be performed, then it is transitioned to
SteelEye DataKeeper Cluster Edition25
Resync Phase
RESYNC_FULL_PHASE. If a partial resync is to occur, then this state is recorded as RESYNC_UPDATE_PHASE. The valid states are as follows:
RESYNC_NO_PHASE 0
RESYNC_INITIAL_PHASE 1
RESYNC_FULL_PHASE 2
RESYNC_UPDATE_PHASE 3
26Overview
Chapter 2: Installation
For installation and licensing information, refer to theDataKeeper Cluster Edition Installation Guideon the SIOS Technical Doumentation site.
l http://docs.us.sios.com/#SPS4W
SteelEye DataKeeper Cluster Edition27
Chapter 3: Configuration
Requirements/ConsiderationsThe topics in this section identify several prerequisites to be aware of before implementing yourDataKeeper configuration.
Sector SizeBeginning with DataKeeper Version 7.2.1, disks with sector size not equal to 512 bytes aresupported. However, DataKeeper requires that themirror source volume be configured on disk(s)whose sector size is the same as the disk(s) where themirror target is configured. NTFS Metadataincludes the disk sector size. DataKeeper replicates the entire NTFS file system from source totarget, so the sector sizes must match.
Note: For DataKeeper Version 7.2 and prior, only disk devices whose sector size is the standard512 bytes are supported.
Network BandwidthBecause DataKeeper can replicate data across any available network, special considerationmust begiven to the question, "Is there sufficient bandwidth to successfully replicate the volume and keep themirror in themirroring state as the source volume is updated throughout the day?"
Keeping themirror in themirroring state is critical, because a switchover of the volume is notallowed unless themirror is in themirroring state.
Determine Network Bandwidth RequirementsPrior to installing SteelEye DataKeeper, you should determine the network bandwidth requirementsfor replicating your data. Use themethod below tomeasure the rate of change for the data that youplan to replicate. This value indicates the amount of network bandwidth that will be required toreplicate that data.
After determining the network bandwidth requirements, ensure that your network is configured toperform optimally. If your network bandwidth requirements are above your current available networkcapacity, youmust consider one or more of the following options:
l Enable compression in DataKeeper, or in the network hardware, if possible
l Create a local, non-replicated storage repository for temporary data and swap files if you arereplicating Hyper-V virtual machines
SteelEye DataKeeper Cluster Edition28
Measuring Rate of Change
l Reduce the amount of data being replicated
l Increase your network capacity
If the network capacity is not sufficient to keep up with the rate of change that occurs on your disks,DataKeeper mirrors will remain in a resynchronizing state for considerable periods of time. Duringresynchronization, data on the target volume is not guaranteed to be consistent.
Measuring Rate of ChangeUse PerformanceMonitor (perfmon) to measure the rate of change that occurs on your volumes thatare to be replicated. The best way to do this is to create a log of disk write activity for some period oftime (one day, for instance) to determine what the peak disk write periods are.
To track disk write activity,
l use perfmon to create a user-defined data collector set onWindows 2008 or a performancecounter log onWindows 2003.
l add the counter "Disk Write Bytes/sec" for each volume - the volume counters can be found inthe logical disks group.
l start the log and let it run for the predetermined amount of time, then stop and open the log.
An alternative to creating a log of disk writes is to use perfmon to track disk write bytes/secinteractively, in the PerformanceMonitor tool, and to observe themaximum and average valuesthere.
SteelEye DataKeeper handles short bursts of write activity by adding that data to its async queue.However, make sure that over any extended period of time, the disk write activity for all replicatedvolumes combined remains, on average, below the amount of change that DataKeeper and yournetwork can transmit.
SteelEye DataKeeper can handle the following average rates of change, approximately:
Network Bandwidth Rate of Change1.5Mbps (T1) 182,000 Bytes/sec (1.45Mbps)
10Mbps 1,175,000 Bytes/sec (9.4Mbps)
45Mbps (T3) 5,250,000 Bytes/sec (41.75Mbps)
100Mbps 12,000,000 Bytes/sec (96Mbps)
1000Mbps (Gigabit) 65,000,000 Bytes/sec (520Mbps)
Network Adapter SettingsDataKeeper requires that "File and Printer Sharing for Microsoft Networks" be enabled on thenetwork interfaces tomake a NAMED PIPE connection and be able to run DataKeeper’s commandline tool (EMCMD).
29Configuration
User Accounts and Domain Considerations
To test if you canmake a Named Pipe connection, try to map a network drive on the TARGETsystem. If that fails, you have a Named Pipe issue.
DataKeeper also requires that NetBIOS over TCP/IP andSMB protocols be enabled. If the GUIdoes not operate correctly, make sure the following network configurations are enabled:
l EnableNetBIOS over TCP/IP andSMB protocols as in the following example:
My Computer->Manage->System Tools->DeviceManager->View->Show Hidden Devices->Non-Plug andPlay Drivers->NetBIOS over Tcpip (Enable)
l EnableNetBIOS over TCP/IP on each network adapter carryingmirror traffic as in thefollowing example:
Start->Settings->Network and Dial-up Connections->->Properties->InternetProtocol(TCP/IP)->Properties->Advanced…button->WINS tab->Enable NetBIOS over TCP/IP radiobutton (Checked)
l Enable theMicrosoft “Client for Microsoft Networks” component on each system where theDataKeeper Administrator GUI will be used. This must be on the same adapter withNetBIOSover TCP/IP enabled (above). For example:
Start->Settings->Network and Dial-up Connections->->Properties->Client forMicrosoft Networks(checked)
l Enable theMicrosoft “File and Printer Sharing for Microsoft Networks” component oneach system which the DataKeeper Administrator GUI will connect to locally and remotely.This must be on the same adapter withNetBIOS over TCP/IP enabled (above). For example:
Start->Settings->Network and Dial-up Connections->->Properties->File andPrinter Sharing for Microsoft
User Accounts and Domain ConsiderationsBecause DataKeeper will be accessing volumes on both the local server and remote server, there areseveral requirements and recommendations to be aware of when running the DataKeeper Service andthe DataKeeper UI in single domain environments as well as mixed environments and Cluster Editionenvironments.
The following table outlines these requirements:
SteelEye DataKeeper Cluster Edition30
User Accounts and Domain Considerations
Environment DataKeeper ServiceRequirementsDataKeeper UIRequirements
SameDomain
or
Trusted DomainEnvironment
l Run the DK Service on allsystems as the sameaccount with the samecredentials
l Okay to use the default =Local System Account
l Log in as adomainadmin andrun the DKGUI
l Or use “runas”Administratoroption to runDK GUI
MixedEnvironmentServers in aMixture ofDomain andWorkGroup
or
Servers inSeparateDomains
l Create a local account oneach system with sameaccount name and password
l Add this local account to theAdministrator Group
l Run the DK Service on allsystems with the localaccount
l Log in usingthe localaccount youcreated torun the DKService
l Run the DKGUI
You shouldalso log onto allserversusing thissame LogOn ID andPassword(see relatedKnownIssue).
DataKeeperCluster EditionEnvironment
l Create a local account oneach system with sameaccount name and password
l Add this local account to theAdministrator Group
l Run the DK Service on allsystems with this localadministrator account
l Log in usingthe localadministratoraccount youcreated torun the DKService
l Run the DKGUI
31Configuration
Firewall Configurations
Firewall ConfigurationsSteelEye DataKeeper cannot function properly if the firewall settings for the source and targetmachines are not configured correctly. This means you will need to configure a rule for inbound andoutbound connections on each server running SteelEye DataKeeper as well as any network firewallsthat replication traffic must traverse.
During installation of SteelEye DataKeeper, you will be prompted to allow the installer to configureyour firewall rules needed by DataKeeper as well as to configure other system settings that arerequired by DataKeeper onWindows 2008. This is not necessary forWindows 2003. If you choose toallow the installer to make these changes, you will not need to configure your firewall manually. If youchoose not to allow the installer to make these changes, you will need to configure your systemmanually as described in this section.
The ports that are required to be open for replication are as follows: 137, 138, 139, 445, 9999, plusports in the 10000 to 10025 range, depending upon which volume letters you plan on replicating. Thechart below shows the additional ports whichmust be open depending upon which drive letters youplan on replicating.
Port # Volume Letter Port # Volume Letter10000 A 10013 N
10001 B 10014 O
10002 C 10015 P
10003 D 10016 Q
10004 E 10017 R
10005 F 10018 S
10006 G 10019 T
10007 H 10020 U
10008 I 10021 V
10009 J 10022 W
10010 K 10023 X
10011 L 10024 Y
10012 M 10025 Z
Configuring Microsoft's Windows Firewall with Advanced Security- ExampleThe exact steps required to configure the firewall for each cluster is as varied as each possible clusterconfiguration, but the following procedure and screen shots will give you one example to follow whenusing SteelEye DataKeeper to replicate the E: and F: volumes. Note the Port # and Volume Lettertable listings in the previous section.
SteelEye DataKeeper Cluster Edition32
ConfiguringMicrosoft's Windows Firewall with Advanced Security - Example
1. OpenMicrosoft'sWindows Server Manager and select Inbound Rules to create a rule forthe TCP protocol as well as the UDP protocol.
2. Select New Rule from theActions panel in the right column of the window. Select Port asthe type of rule to be created. Select Next.