DataKeeper Cluster Edition for Windows Technical Documentation · 2016. 8. 17. · Answer 205 ResizeorGrowMirroredVolumes 205 Question 205 Answer 205 Server2012:ServerManager“FileandStorageServices”DiskStatus

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



N-Shared-Disk Replicated toMultiple N-Shared-Disk Targets 99



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


Failed to CreateMirror 214

User Interface - Failed to CreateMirror - Application Event Log 214

Error/Message 214

Description 214

xiv Table of Contents


Hyper-V Host Cluster Error 214

Failover Cluster Error After Changing Virtual Machine ConfigurationWhile VM IsClustered 214

Description 215


MaxResyncPasses Value 216

Mirroring with Dynamic Disks 216


New Resources Offline But Unlocked 217

WSFC Server - Newly Created Resources Appear Offline But Are Unlocked 217

Error/Message 217

Description 217


Server Login Accounts and Passwords Must Be Same on Each Server in the Cluster 217

Error Message 217

Description/Cause 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


User Interface - Failed to CreateMirror 219

User Interface - Failed to CreateMirror, Event ID 137 219

Error/Message 219

Description 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


WSFC 2008 R2 SP1 Procedure Change 221

Description 221


WSFC Server 221

WSFC Server – Cluster Validation, Clustering SQL Server 2008 221

Error/Message 222

Description 222


Windows Server 2012 Specific Issues 222

Windows Server 2012MMC Snap-in Crash 223

Description 223


Windows Server 2012 -- Simultaneous Move of Multiple Clustered File Server Roles CanResult in DataKeeper Switchover Failures 224

Description 224


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


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


WSFC 2012 File Shares Cannot be Created for File Server Role Using Server Manager orFailover Cluster Manager 231

Description 231


WSFC 2012 New File Server Type Not Supported 231

Description 231


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.


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


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:



If a Domain or Server account is selected above, the DataKeeper Service LogOn ID and PasswordEntry Form is displayed to enter that information.

6Overview


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.


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 Intent Log


DataKeeperCluster EditionEnvironment



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


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.


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.


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.


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


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.


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


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


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


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


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


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


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


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


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


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:




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 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 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.


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.