HPE 3PAR 數(shù)據(jù)保護(hù)方案

1、HPE 3PAR 數(shù)據(jù)保護(hù)方案Async Streaming3PAR Remote Copy Asynchronous StreamingCache-based replication architecture2Async Streaming ReplicationPrimarySecondaryLow RPO (seconds)Low RTO (1+ minutes)123Writes issued from host server are stored in local arrays cache (after local cache mirroring)1An acknowledgemen

2、t is sent to the host resulting in low latency from the host to the system2Writes cache pages are coalesced into tickets that describe IO order and replicated to the second system3Write IO is then replayed in order on the secondary system to ensure consistency with primary443PAR 的復(fù)制Protect and share

3、 dataSmartInitial setup in minutesSimple and intuitive commandsNo consulting services required CompleteNative IP LAN or FC SAN-basedReservation-less No extra copies or infrastructure neededFully compatible with all 3PAR Thin Technologies Any combination of sync and async periodic RC Mirror 1:1 up to

4、 4:4 between 7k, 8k, 10k, 10k, T- and F-classTrue async RC 1:1 mirror between any 7k, 8k, 10k and 20kSupport details can be found in the “OS Upgrade Pre-Planning Guide”VMware vSphere Site Recovery Manager (SRM) and vSphere Metro Storage cluster (vMSC) certifiedScalable1 RCIP link per node up to 8 pe

5、r 3PAR arrayUp to 4 RCFC links per node up to 32 per 3PAR array1:1 ConfigurationSync RC and/or Async Periodic RCAny 3PAR arraysSee a demo video here /watch?v=7RVozzXOuRQ 4:4 ConfigurationSync RC and/or Async Periodic RCAny 7000, 8000, 10000 or 20000 arrayPSSP3PAR Remote Copy SynchronousContinuous op

6、eration and synchronizationReal-time MirrorHighest I/O currencyLock-step data consistencySpace EfficientThin provisioning awareTargeted UseCampus-wide business continuityGuaranteed Consistency Enabled by Volume Groups2 : Primary array writes I/O to secondary write cachePS1 : Host server writes I/O t

7、o primary write cache23 : Remote array acknowledges the receipt of the I/O144 : Host I/O acknowledged to host3PrimarySecondaryHostLocal Snapshots3PAR Remote Copy Asynchronous PeriodicInitial setup and synchronization Efficient even with high latency linksLocal writes acknowledgementBandwidth-friendl

8、yJust delta replicationSpace efficientThin awareGuaranteed Consistency Enabled by Volume GroupsBased on snapshots3Step 2 :Local snapshot createdPrimarySecondaryStep 1 :Secondary volume created2Step 3 :Initial synchronizationPS3PAR Remote Copy Asynchronous PeriodicContinuous operation and periodic re

9、synchronizationIdeal for long-distance implementationsEfficient even with high latency linksLocal write acknowledgementBandwidth-friendlyJust delta replicationSpace efficientThin awareGuaranteed Consistency Enabled by Volume GroupsBased on snapshots42 : Host I/O acknowledged to hostSecondary1 : Host

10、 server writes I/O to primary write cacheLocal Snapshots12Manual or scheduled resync3 : Create local and remote snapshot4 : Replicate snapshot delta 33RemoteSnapshotPSPrimaryHost3PAR Synchronous Long Distance Configuration3PAR的三中心容災(zāi)Combines the ability to maintain concurrent metro-distance synchrono

11、us Remote Copies with RTO=0 AND continental distance asynchronous Remote Copies for Disaster Tolerance (DT)Async Periodic RCActivePrimarySecondaryPS2TertiaryS1Async Periodic RCStandbySync RCSynchronous Long Distance 1:2 Configuration Metropolitan distanceContinental distanceFind 4 SLD demo videos he

12、re /playlist?list=PL9UfCHCZQuNDmU8WRXT_RU7yG_sL-eweV 3PARAsync Streaming Tech IntroductionNew: 3PAR Remote Copy Asynchronous StreamingContinuous operation with RPO close to 0Efficient with higher latency linksLocal write acknowledgement Maintains local server write IO performance and latency Write I

13、O data is queued in local cache and replicated at max available link speed Guaranteed Consistency Enabled by Volume Groups and Write IO tickets (tags)2 : Host I/O acknowledged to hostPS1 : Host server writes I/O to primary write cache33 : Primary array writes I/O to secondary write cache124 : Remote

14、 array acknowledges the receipt of the I/O4PrimarySecondaryHostNEW: HP 3PAR Remote Copy Asynchronous StreamingRobust, Cost-Effective DR included with Remote CopyAdvantages30 seconds or less* RPO with fast recovery timeNo host write IO latency impact (vs. Synchronous replication)Distance flexibility

15、(up to 150ms round-trip latency with RCIP)Application integration for app consistent recoverySupported on midrange arrays! PrimarySecondaryBase VolumeIP or FCAsynchronousSupported on 3PAR StoreServ:7000/8000/10000/20000How does it workJust like Synchronous and Periodic Asynchronous modes, Asynchrono

16、us Streaming Remote Copy ensures IO consistency across the volumes in a Remote Copy GroupAsynchronous Streaming Remote Copy uses the concepts of replication “sets”, “subsets” and “tickets” to ensure IO delivery and ordering Data is held in cache on both the source and target array as part of the rep

17、lication processAs a result, a solution must ensure array IO performance is sufficient for the IO load and that there is sufficient replication bandwidth between arrays to prevent cache on either array from filling up with replication dataEither having too small of a link or an undersized array can

18、result in RC Groups being suspendedThe Asynchronous Remote Copy can (and will) use up to 20% of the cache on the source arrayToday there are no hard limits on how much cache is used on the target array to hold target dataHow does it workSets and sub-setsEven though “sets” are cluster wide they are a

19、ctually broken down into “sub-sets”There is one sub-set per node for each Remote Copy GroupNode0Node1Node3Node2Asynchronous Streaming Replication Set Node0 SubsetNode1 SubsetNode2 SubsetNode3 SubsetTicketTicketTicketTicketTicketTicketTicketTicketTicketTicketTicketTicketHow does it workSub-setsWhen a

20、 sub-set is created on the source array it is assigned a node on the destination arrayThe destination node chosen for the sub-sets coming from a source node will not change unless an error occurs that causes a different target node to be used for the subsetA write IO coming from a server is placed i

21、nto a sub-set on the node that owns the LD the write IO belongs toThis may be a different node than the one the write IO came in onSee “Life of An IO” for details on how data flows through a 3PAR and how the owning node for an IO always is responsible for the data associated with that IOHow does it

22、workSets and sub-setsIOs for the sub-sets on a node on the source array are sent to the subset destination node on the target arrayNode1Node0Node2Node3Node0Node1Node3Node2Node0 Subset Node1 SubsetNode2 SubsetNode3 SubsetHow does it workReplication Delta “Sets”Delta “sets” are cluster wide and are br

23、oken down into “sub-sets” with each node on the source array being responsible for a sub-set of the setReplication “sets” provide the granularity on which IO consistency is maintained for a given Remote Copy groupThe number of IOs in a set is variable and depends on the number of writes the server d

24、id to the VVs in the RC group over the 100ms periodA given replication set is associated with at most one Remote Copy groupReplication sets represent a quantum of time (100ms default)A new “set” is started for every Remote Copy group approximately every 100ms (subject to change) and is facilitated b

25、y incrementing a cluster wide “sequence number”A set is designated as a sequence_number.Group_IDSequence_number cluster wide sequence numberGroup_ID Remote Copy Group IDHow does it workReplication “Tickets”When a write IO comes into a node on the source array the data for the write is mirrored to ca

26、che on the appropriate node in the cluster (see the “Life of An IO” presentation for details) and the IO is passed to the Remote Copy layer for replication processingA replication ticket for that IO is generated and the IO is added to the current active subset on the node that owns the LBA for the I

27、O requestReplication tickets are unique across the array and are used to enforce IO ordering and ensure IO deliveryInformation that makes up the subset is mirrored to the nodes partner node (policy memory, not data cache)We mirror the subset information from a node to its partner so that the partner

28、 can recover the subset in the event the node failsThe server is then sent an IO complete and the IO gets queued up to be replicated to the remote array How does it workReplication SetsA replication set is made up of “sub-sets” containing Remote Copy “tickets” for the VVs in a Remote Copy Group (mor

29、e on “sub-sets” and “tickets” in a moment)There is a Manifest Record for every Remote Copy Group and the Manifest Record specifies how many IOs are in each sub-set belonging to a setOnce all subsets for a given set have been sent to the target array the source sends the target a “Manifest Record” fo

30、r the setWhen the target array receives a Manifest Record it checks to ensure it has received all IOs that belong to each sub-set in the setIf the target determines that any IOs are missing it will request the source array to resend the missing IOsThe target has all the IOs for all sub-sets each nod

31、e passes the IOs for its subset to the VV layerThe IOs for a set are not applied to the target VVs until the entire set is complete and all IOs belonging to each sub-set in the set have been received (IO consistency)How does it workReplication Sub SetsDelta sets are always applied on the target arra

32、y in the same order they are created on the source arrayThe sub-sets that make up a delta set may be applied independently on the target array as no IO ordering across sub-sets on the target is requiredWe only need to ensure that all IOs for each subset in a set all get appliedCollisions are handled

33、 appropriatelyWhile the IOs for the subsets in one set are being applied to the VVs for a Remote Copy Group the next set is being generatedAfter the receipt of all IOs for the subsets in a set (verified via the manifest repord) the target array notifies the source that the set has been received and

34、the source can then release any cache pages it was holding onto in the event an IO had to be retransmitted to the targetThis means that with Asynchronous Streaming Remote Copy a Remote Copy group gets IO consistency on the target array at the delta set level of 100ms incrementsHow does it workDelta

35、SetsTicket1Ticket2Ticket3Ticket4Ticket5Ticket6Ticket7ManifestTicket8Ticket9Ticket10Ticket11Ticket12Ticket13Ticket14ManifestRemote Copy GroupTarget ArrayTicket1Ticket2Ticket4Ticket5Ticket6Ticket3Ticket7ManifestTicket8Ticket9Ticket10Ticket11Ticket12Ticket13Ticket14ManifestSet #1Set #2Source ArrayHost

36、WritesHow does it workMaintaining IO ConsistencyHost IO is grouped together into data sets based on sequence of IOData is then sent to the target, however it can arrive out of order A set is applied only after all subsets arrive and there is no previous dataset pendingMaximum latency for Asynchronou

37、s Streaming replicationDelta Set, Cluster Seq No. 1001 Subset for Node0Delta Set, Cluster Seq No. 1002 Subset for Node1Subset for Node0Delta Set, Cluster Seq No. 1003 Subset for Node1Delta Set, Cluster Seq No. 1001 Delta Set, Cluster Seq No. 1002 Delta Set, Cluster Seq No. 1003 Host IOSubset for Nod

38、e0Subset for Node1Host IOHost IOHost IOHost IOHost IOHost IOHost IOHow does it workWrite IOs are placed into the sub-set managed by the node that owns the LD the write is forTicket1Ticket2Ticket3Ticket4Ticket5Ticket6Ticket7ManifestSetHost WritesNode 0Node 1Ticket4Ticket2Ticket7Ticket1Ticket5Ticket3T

39、icket6ManifestNode 1Node 0Remote Copy GroupSetSub-set 0Sub-set 1Sub-set 0Sub-set 1Configuration rulescreatercopygroup has a new mode ,“async”, for Asynchronous Streaming modeThe following example creates an Asynchronous Streaming mode group name Group1 whose RC target name is Inserv2creatercopygroup

40、 Group1 InServ2:async22Configuration rulesSetrcopygroup The setrcopygroup command has some new capabilities to support Asynchronous Streaming Remote CopyThe “mode” subcommand now allows the user to switch between sync, periodic and async modesAsync is the new mode used to specify Asynchronous Stream

41、ing replicationGroup must be stopped prior to changing modeThe “period” subcommand now allows the user to set Asynchronous streaming policies for specific groups Groups that are in asynchronous streaming mode will transition to “Logging” state when replication resources drop below sustainable limits

42、The defined “period” value specifies how long the group remains suspended before RC tries to restart it. Groups with larger “period” values will be stopped first and restarted last providing some level of control over which groups stop firstSetting a period value of zero (0) will result in the group

43、 not restarting automatically, it will require a manual restart if RC suspends the groupConfiguration rulesSetrcopygroup snap_freq” for async replication mode The snap_freq parameter specifies how frequently an automatic coordinated snapshot (CSS) is takenDefault is one hourMinimum is five minutesMa

44、ximum is one yearThe automatically created CSS provides us with a resync point in the even a resync is requiredSnapshots can be an expensive operation if the Remote Copy Group has a lot of volumesIt is recommended that if the default one hour snap_freq value is decreased that it be done so carefully

45、 and that the maximum value a customer can tolerate be usedHow does it workCoordinated Snapshots (CSS)Asynchronous Streaming is able to create coordinated snapshots These are snapshots that are created at the same point in time on both the source and target arrayRemote Copy creates these automatical

46、ly to provide itself with resync points should it need to perform a delta resyncDefault is top create then once an hourCSSs for Asynchronous Streaming RC are also available to customers via the “createsv” commandThis works for both Asynchronous Streaming RC Groups and for Periodic Asynchronous group

47、sConfiguration rulesStoprcopygroup There is a new option “-nosnap” that can be specified to the stoprcopy group commandFor the stoprcopygroup command, specifying the nosnap option indicates that the remote copy group should do a fast stopA fast stop means the remote copy group will stop immediately

48、without allowing any outstanding IO data to be synced across to the secondary array before the group is stopped If -nosnap is not specified, the group will default to a soft stop where we will flush all the outstanding IO data from the primary to the secondary array and take coordinated snapshots on

49、 both primary and secondary systems before indicating the group is stoppedGreen Zone Configuration rules for 3.2.2GA1. No support for 7200 or 7200C These models do not have enough data cache to support Asynchronous Streaming Remote Copy. Possible to support them in a future release with disk based l

50、ogging2. We will be supporting the following array models at first release7400 & 7400C7440 & 7440C7450 & 7450C8200, 8400, 8440 & 845010K series20K series3. Maximum replicated VVs per storage system 2400 4. Up to 512 RC Groups allowed. Max volumes per group is 3005. Source and target arrays must cont

51、ain the same number of nodes6. Support for RCFC and FCIP only Support for RCIP in 3.3.1 and later3PARAsync Streaming SizingAsynchronous Streaming RC SizerAsynchronous Streaming Remote Copy provides for higher replication latency support and small RPOs without impacting server IO performance Isolates

52、 server write IO performance from the effects of the inter-site link used for replication and from the remote arrays write IO service timesLink SpeedLink LatencyAccomplished by queuing up data at the source and replicating, at the rate the link can handle, to the destinationEnsures data consistency

53、at the target array but not data currencyIt delivers an RPO in the range of seconds compared to Periodic Asynchronous RCSolutions must be sized to ensure array cache is not overrun to prevent Remote Copy Groups from being suspendedAsynchronous Streaming RC SizerData Generation RateTimeLink Bandwidth

54、If this data cannot fit into the source arrays cache and we will suspend Remote Copy groupsIOs drain cache pressure decreasesAsynchronous Streaming RC SizerData Generation RateTimeLink BandwidthWe can solve this by deploying a faster replication linkIOs drain cache pressure decreasesAsynchronous Str

55、eaming RC SizerTheoretical Sizing Example2-node 7400c16GB of data cache per node pair (8GB per node)20%* of cache is allocated to Asynchronous Streaming Remote Copy:3.2GB of cacheThe solution is averaging 12MBs over a 48 hour period but has a spike of 220 MBs of data generation that lasts for 20 sec

56、ondsHow large of a replication link do we need to make it through the 220MBs spike?Lets try sizing with a T3, OC-3, and OC-12Its a simple formula:Time = GB of A-S cache/(Write_spike link_speed)*Subject to change before product releaseAsynchronous Streaming Enhancements333.3.1 Remote Copy Enhancement

57、sRemote Copy Asynchronous Streaming EnhancementsAsynchronous streaming support for 10G RCIPAsynchronous streaming replication has been enabled for use with 10G RCIP networksThe 20K and 8K platforms have support for 10G RCIP networks via the onboard NIC or with HBAs fitted into the platformAsynchrono

58、us streaming supports increased latency over FCIP and RCIPSupport for asynchronous streaming replicated between sites with up to 30ms RTT latency343.3.1 Remote Copy EnhancementsRemote Copy Asynchronous Streaming EnhancementsAsynchronous Streaming host throttlingAsynchronous Streaming RC host throttl

59、ing is the delaying of the IO complete for a host write (IO acknowledgement) by a small amount under certain conditions for those IOs being replicated via Asynchronous Streaming when it starts to fall behindIt is disabled by default on all 3.3.1 arrays using Asynchronous Streaming or “async” mode re

60、plicationIt is enabled system wide with the cli “setsys” command:setsys RemoteCopyHostThrottling yesGoal: To slightly throttle host write IOs under certain conditions to the point that Asynchronous Streaming RC can continue to replicate data WITHOUT exceeding the 20% cache ceiling and do this withou