1 Module: Designing SRDF/S Solutions

This module focuses on designing SRDF/S solutions.
The factors that contribute to the

response time impact in SRDF/S are described in detail. Detailed description of the Business
Continuity Solution Design (BCSD) tool and its use for designing SRDF/S solutions, are also
covered.
Copyright 2015 EMC Corporation. All rights reserved. Module: Designing SRDF/S Solutions 1
This lesson covers the factors that contribute to response time impact in an SRDF/S
solution. Considerations for the design on an SRDF/S solution.
One of the most important considerations for planning, design and implementing a
Synchronous solution is setting the appropriate expectation. If there is delayed response
and it was identified up front, it has less impact on the project than to introduce it at the
time of production. The increase in response time is a function of a number of factors as
listed in the slide. We will address each of these individually.
Applications write in predetermined block size (4K, 8K, etc…). Log bursts may send larger
writes attempting efficiency. Block sizes can be determined by gathering performance data
e.g. SAR on HP-UX:
• Write I/Os per second
• Blocks written per second
• Simple Calculation: block write rate / write I/O rate = # 512 byte blocks per write I/O
The size of the I/O matters as it is sent across the link. Smaller pipes have a tougher time
with larger block sizes.
Here we can see what the effect on the transfer rate is with various block sizes. For
example, let’s use a T3 line.
T3: Speed = 45 Mbits/sec approx 4.5MBytes/sec
4K block: 4K / 4.5 = 0.9 msec
27K block: 27K / 4.5 = 5.9 msec
Insufficient bandwidth will also cause response time elongation. With Synchronous
replication, you should have sufficient bandwidth all the time. The picture on the slide
shows the amount of data that has to be replicated as a function of time. To minimize the
response time elongation, ensure that the Max bandwidth is provided by the network at all
times. If we assume that only the average bandwidth is provided for, then there will be
times during the day (the shaded section) when response times may be unduly elongated,
causing applications to time out.
If data is not required for remote restart, it should not be mirrored. Find out from the
customer which data is not required. Examples might include paging space, test
filesystems, filesystems used for database reorgs, temporary files, etc. Determine the Write
workload by collecting performance data.
The number of round trips with each I/O to be replicated via SRDF/S depends on the
remote adapter and network extension equipment in use. The response time will be
affected by the distance and the number of round trips.
When we size, we must account for the round trip. In synchronous an I/O is not complete
until it has made a round trip. GigE requires a single round trip, but Fibre Channel requires
two round trips unless Write Acceleration/Fast Write/SiRT equipment is used.
With SRDF over Fibre Channel and DWDM implementations, the Protocol converter delay for
switches or multiplexors is considered to be insignificant. IP networks require qualification
to ensure they have sufficient quality to carry data replication workloads, without significant
packet loss and inconsistent packet arrival.
Determining the appropriate number of remote adapters depends on the write workload
(writes/s, block size) and the type of remote adapters and the specific microcode level.
The workload will indicate how much data has to be replicated. Hand calculations are easy
to do if the workload never varies and the block size is always the same. But in reality, the
workload changes over time and the there can be a mixture of block sizes depending on the
nature of the workload. Therefore, resort to a tool which can determine precisely how many
RAs are necessary based on the varying workload.
The RA Utilization Chart, displayed on this slide, was generated with the BCSD tool
performing an SRDF/S analysis using real workload data.
BCSD essentially looks at the average write block size for each volume in an interval and
based on Symmetrix Performance Engineering test results, utilizes the published SPEED
throughput results as the basis for determining the RA Utilization chart. The chart shows a
peak RA utilization of about 85%. We design for 50% utilization, hence this will necessitate
a minimum of 4 remote adapters in order to handle the workload and provide redundancy.
In an SRDF/S solution, the extended response time directly affects the maximum number of
writes/sec that one can sustain to a particular volume. Why is this important? Without
SRDF/S, an application may have been performing 500 writes/sec without any problems.
But the implementation of SRDF/S is going to extend the response time and, as a
consequence, you may find that only 400 writes/sec can be sustained. This could be a
problem; therefore, you should perform an analysis and identify all the volumes which will
hit the write limits.
Either try to increase the volume write limits or try to reduce the writes/sec per volume that
the application is performing.
Some of the factors that contribute to the volume write limits really cannot be changed. The
distance between sites typically cannot be changed.
More often than not the best way to resolve the issue might be to distribute the workload
over more volumes. If this is a pre-sales situation, then in all probability a migration to the
new VMAX3 array has to be done anyway. Identify the problem volumes and make sure
that the application is laid out better in the new array.
This slide helps you understand write distribution. Write I/Os are usually concentrated on a
few volumes.
The SRDF solution should be tailored to satisfy the writes to the busiest volumes.
Symmetrix Remote Data Facility (SRDF) with HYPERMAX OS 5977 Q1 2015 Service Release
(SR) in conjunction with Solutions Enabler 8.0.2 supports R21 and R22 devices. In previous
versions of HYPERMAX OS these volumes could not be created. R21 devices are used in a
cascaded SRDF configuration, including SRDF/Star and R22 devices are specifically designed
for Star configurations. Use SolVE Desktop for specific interfamily SRDF configurations.
This lesson covered the factors that contribute to response time impact in an SRDF/S
solution and the considerations for designing SRDF/S solution.
This lesson covers the methods to calculate the response time impact due to SRDF/S.
For Synchronous, we must have sufficient capacity/throughput to handle the workload. We
must also know what other factors contribute to response time elongation. We should
devise methods to quantify the impact contributed by the various factors.
Gather statistical information as you need from each host or Symmetrix. Having gathered
statistical information, filter out any unwanted data, measure writes per second per
volume/LUN, and find out the average block size for both online and batch workloads. This
information will enable you to calculate throughput maxima, performance impacts, and
bandwidth requirements.
Before there were modeling tools, there were individual spreadsheets that used iterations of
the same formulas that applied basic math to find the results of an SRDF/S solution. The
problem with theses models was they were often prone to errors and miscalculations.
To estimate the impact of implementing SRDF on the expected Write I/O response times,
first we need to calculate the amount of time it will take to send the I/O across the SRDF
link to the R2 and get confirmation back that the data has been received. This is important
because in Synchronous mode, the Write I/O is not confirmed as completed to the host
until it has been sent to the R2 and an acknowledgement received back from the Target
Symmetrix. Therefore, host response time for a local Write I/O is extended.
With SRDF over Fibre Channel and DWDM implementations, the Protocol converter delay for
switches or multiplexors is considered to be insignificant. However, careful consideration
should be made to ensure sufficient “buffer to buffer credits” for SRDF over Fibre Channel
implementations.
Signal Propagation Delay: The speed of light through a fiber optic cable is constant,
however a small delay is incurred. This can be calculated as 1 millisecond per 125 miles.
Remember to take into account the number of “round trips” needed when calculating this
figure.
“Data Transfer Time” is the amount of time it takes for a single write I/O to be transmitted
across the SRDF link in one direction. This is dependent on the block size and the
bandwidth of a single SRDF link available.
Even though multiple SRDF links should be configured for resiliency, a single I/O can only
be transmitted down one link, therefore data transfer time cannot be improved by
increasing the number of links. To improve data transfer time, (and therefore the host Write
I/O Response Time), it is necessary to use a faster link such as Fibre Channel.
The SRDF Link Service Time can now be calculated. The protocol converter delay + signal
propagation delay + data transfer time = SRDF Link Service Time.
SRDF Response Time = Current Response Time + Link Service Time
Now we can calculate the average expected host Response Time after implementing SRDF.
The SRDF Write I/O Response Time is calculated by adding the Link Service Time to the
current Response Time (or new expected non-SRDF response time).
The READ I/O response is unaffected by implementing SRDF. The only exception to this is
when all of the local mirrors for a Symmetrix Logical Volume fail and the data has to be
“read across the link” to service host Read I/O requests. This should be acceptable to the
user as the alternative without SRDF is that the Read I/O would simply fail.
Average Expected Response Time for Read & Write IOs can be calculated by using the
formula:
(Read I/O Response Time * Read Ratio) + (Write I/O Response Time * Write Ratio)
The maximum number of writes possible through a single SRDF link is determined from
SPEED Charts. This assumes that IOs are evenly spread across a number of Symmetrix
Logical Volumes and that IOs from multiple volumes can be queued on the link.
This value takes into account the model of Symmetrix, Enginuity, or SRDF Channel Director
used. Different Enginuity versions can also affect SRDF performance due to the efficiency
and number of SRDF Queues used to service Write IOs through the link.
The number of RA links required can now be calculated using the following formula:
Write I/O per second / Max RA writes per second
We have calculated new I/O response times and the number of links required, so now the
SRDF Sizing & Performance planning is complete, right? Not yet, we still have to consider if
the busiest volumes in the Symmetrix can be serviced.
To calculate the Maximum writes per second per Symmetrix Logical Volume, use the
following formula: 1/Write Response Time.
In this case study, the Write Response Time was calculated as 6.22 milliseconds, therefore
it is possible to service 161 Write I/Os per second per Symmetrix Logical Volume or a
maximum of 186 I/Os based on the read/write ratio of 70:30.
If after reviewing the Workload Analyzer and other performance data, it is found that the
busiest volumes currently perform more than 186 I/Os per second, then it would be
necessary to look at alternative options for reducing the workload so that the performance
expectation can be met.
Can Symmetrix metavolumes be used to spread the write I/O workload over multiple
Symmetrix Logical Volumes?
Is this volume only busy at certain times, i.e. used for Batch processing?
• Can SRDF for this volume be Split during the busy time frame?
• Can a BCV/Clone of the Production volume be mirrored with SRDF instead during this
time frame?
With the introduction of corporate sponsored sizing tools, the risk associated with
synchronous design is reduced to the data that is input into the tool. Since the tool models
with host or Symmetrix performance data, the risk is reduced to the data collection sample.
At the present time, BCSD addresses the key risks listed above.
The slide addresses the design methodology implemented within BCSD, with respect to
bandwidth requirements and network latency for synchronous response time.
The methodology for computing Remote Adapter requirements and identifying potential hot
volumes is listed on this slide.
The overhead listed in the chart is accounted for in BCSD by reducing the available
bandwidth.
For example:
SRDF/Synchronous FCIP Example with no SIRT
SRDF/S + Symmetrix FC remote adapter (no SiRT) + Switch with FCIP enabled (converting
FC to IP)
End-to-end link less than 10Gb
50MB/sec Ethernet circuit
Overhead = Fibre Channel 13% + Fibre Channel ACK 8% + FCIP 6% + IP 8% = 37%
Usable Network Throughput = 50MB/sec * (1 - .37) = 31.5MB/sec
For additional examples please refer to the

BCSD_v1.6.10_Getting_Started_Guide_v1.00.pdf
The slide shows the basic workflow to setup a Project within BCSD.
The flow starts by creating a Customer. Once a Customer has been created, Projects can be
created under this customer. At any given time one can only work on one project.
Each project consists of Sites, Network Circuits, Physical Relationships, Logical

Relationships and optionally Composite Groups. Sites, Network Circuits and Physical
Relationships are called “Assets”.
Under each project the next step is to create Sites. A project can have one or more sites.
Typically one would have at least two sites. Each site consists of Arrays and Switches. At
least one Array and one Switch must be defined for each site. For each array, Replication
Port Groups and Replication Groups need to be defined.
A Network Circuit defines the circuit type and available bandwidth – for synchronous
replication the number of IP hops and distance are also specified.
Physical Relationship defines the actual physical connectivity for the replication model. It is
defined by specifying the source/target sites, arrays, replication port groups and switches.
The network circuit is also specified.
The Logical Relationship is defined by specifying the Physical Relationship and the
Replication Groups. The Replication Product (SRDF/A or SRDF/S) to be analyzed in specified
here as well.
We will investigate each of these steps in detail later on in this course.
The slide represents the workflow for modeling within BCSD. Defining a project in complete
detail, as we saw over the last few slides, is essential.
Once the project is defined, the next step is to map performance data to the replication
groups that were defined in the project.
Performance Data can be loaded into BCSD as soon as a Customer and Project have been
created. Performance Data that has been loaded for a given customer can be used in any of
the projects under the same customer. A given data set needs to be loaded only once. The
same data set can be used by many projects by mapping the data set to a given Replication
group.
Once the data mapping has been done, one can validate the project assets and then run
the modeling calculations.
After the modeling calculations complete, view the results. Results are displayed as Charts
and Risk Reports. Summary Reports can also be generated.
This lesson covered the methods to calculate the response time impact due to SRDF/S.
This lesson covers the syntax and guidelines for collecting data from different host OS that
can be used as input to the BCSD tool.
We will need to focus on some subset of the hour or the day. We look to the customer to
identify the peak production times and then confirm with host- or Symmetrix-based
production data statistics. A minimum of three days of data at 10 minute intervals is
recommended. The data capture period should ideally include the peak workload periods
such as end-of-the month, end of quarter, end of year processing. It is important to capture
the IO size of the write I/Os. This metric has a direct impact on the bandwidth requirement
for SRDF. The minimum data collection interval should not be less than a minute as this will
lead to unpredictable results and errors.
In many cases, where a host environment is being migrated to an EMC storage architecture
where none currently exists, the host based performance metrics needs to be used to
design a possible solution. It is important to include the devices on each host from the
vendor storage that will be replaced by EMC storage.
The tools listed can be used for collecting host based performance metrics. The command
can be scheduled in cron or any other scheduling product for the three-to-five days of data
capture period. The data collected from these sources are used by the Business Continuity
Solution Designer (BCSD) tool. We will discuss the data collection procedure for sar, iostat
and perfmon in the next few slides. BCSD supports the Symmetrix BTP data, VMAX3 DCF
data, as well as CLARiiON NAR data.
The EMC Modeling Tools Data Collection Guide has detailed procedures for all of these host
and array based data collections.
Ask the customer for a list of servers that are attached to the storage array. This is the
environment that the storage replication design will be performed on:
• Identify specific LUNS (by device) that need to be replicated.
• Identify and plan the 3-5 day peak activity data collection period.
Verify that the Customer is current with the latest patches of the Operating System. For
Solaris, there are recorded patch incompatibilities that cause iostat to report incorrect
statistics. Use iostat for AIX, Linux and Solaris and sar for HP-UX.
Create and run a scheduled (CRON) job for data collection on each host.
Use best available medium to transfer the output file in order to import into the modeling
tool.
“SAR” or System Activity Reporting, is a common performance measurement tool that can
be used across any UNIX platform.
For HP-UX Systems the BCSD tool requires SAR data. The syntax for data collection is
shown on the slide:
SAR Name of command
-d Time and date stamp for each report
-b Buffer I/O statistics
600 Interval duration in seconds (10 minutes)
144 Count of intervals to display (24 hours of 10 minute intervals)
Review the vendor’s man pages (UNIX Manual Pages, for online reference documentation)
to double check the exact meaning of the various fields.
iostat is another major UNIX disk performance measurement tool. Iostat’s appearance
differs greatly under different versions of UNIX. As was the case with sar, iostat data is
often never collected unless the customer suspects a problem.
AIX
-d Displays only the disk utilization report
-T Adds a column containing the time, but no date (AIX 5.2 and above)
Linux
-d Limits iostat output to the device utilization report only
-x Displays extended format
-t 600 Print the time of each report interval in 600 second increments (10 minutes)
Solaris
-Td Time and date stamp for each report
-x Displays extended device statistics
-r Comma separated format
Review the vendor’s man pages (UNIX Manual Pages, for online reference documentation)
to double check the exact meaning of the various fields.
Data collection on ESX and ESXi servers is performed using esxtop command. As this
command creates a large number of additional columns with all of the counters, it is
important to use the Filter esxtop for BCSD tool to remove these extra columns before
importing the data into BCSD. For additional information consult EMC Modeling Tools Data
Collection Guide.
Request a list of servers that are attached to the storage array that storage replication
design will be performed on. Identify specific LUNS (by device) that need to be replicated.
Identify and plan the 3-5 day peak activity data collection period.
Setup Perfmon to collect Disk Statistics, off by default.
Configure Perfmon for data collection by setting up log file and resetting counters.
Configure Perfmon collection interval and schedule.
Configure Perfmon collection log file format as .CSV
Collect the output text file. Use best available medium to transfer the output field in order
to import into the modeling tool.
The limitations of host based data collection is listed on the slide.
This lesson covered the syntax and guidelines for collecting data from different host OS that
can be used as input to the BCSD tool.
This lesson covers the details of designing an SRDF/S solution using BCSD and performance
data collected from host(s) attached to an array.
Now let us walk through a sample sizing effort using the BCSD Tool.
A customer “BCSD” was created first. Then project “SRDF-S Model” was created. Two sites
“Source” and “Target” were also created. A compression ratio of 1:1 will be used for this
project. The performance data tag of “SyncHostData” will be used by this project. In the
SQL Server database, a new database with the name “BCSD_DB_SyncHostData” will be
created and the performance data will be stored in this database.
For this model we create a project with two sites (one for the local site and one for the
remote site). At each of the sites we create one Array and one Switch.
The local array is a VMAX 200K, with 4 Engines and Enginuity 5977. One RA Port Group
with two Fibre ports has been defined. We will use SiRT, but Enginuity compression will not
be used.
One Replication Group has been created, the Replication Group uses the replication ports
from the RA Port Group “Local Port Group” – both ports will be used for SRDF. For the
Source array the Rep Flag should be set to “Source”.
Transmit Idle Time and Delta Set Extension settings are not necessary for an SRDF/S
model.
The local switch is a Generic DWDM Switch, with FC inbound ports and DWDM outbound
ports.
The remote array is also a VMAX 200K, with 4 Engines and Enginuity 5977. One RA Port
Group with two Fibre ports has been defined. SiRT has been enabled. No Compression.
One Replication Group has been created, the Replication Group uses the replication ports
from the RA Port Group “Remote Port Group” – both ports will be used for SRDF. For the
Remote Array the Rep Flag of Target must be specified.
Transmit Idle Time and Delta Set Extension settings are not necessary for an SRDF/S
model.
The remote switch is a Generic DWDM Switch. With FC inbound ports and DWDM outbound
ports.
Based on the Customer’s information, the network circuit is DWDM with a total of 30 MB/s
of bandwidth. For Synchronous modeling, we have to specify the distance or the latency. In
this example the distance of 100 km has been specified.
The Physical relationship tells the model how the various components are physically
connected. In this example, Site Local is connected to Site Remote.
The Primary Array is connected to the DR Array.
The Replication Port Group “Local Port Group” on the Local Array is connected to the
“Remote Port Group” Replication Port Group on the Remote Array.
The Local Replication Port Group is connected to the switch “Local Switch”, while the
Remote Replication Port Group is connected to the switch “Remote Switch”.
The switch groups are connected together with the “SRDFS Network Circuit” Network
Circuit.
The Logical relationship is used to specify the type of modeling that is to be done – In this
case SRDF/S. In addition the logical relationship is used to specify the Physical Relationship
and the Replication Groups that should be modeled. The maximum available throughput for
SRDF is also specified – in this case a 100% of the available bandwidth. For SRDF/A we also
specify some additional information. We will see SRDF/A modeling in the SRDF/A lecture.
To load performance data click on the “Load Performance Data” icon or choose Tools 
Load Performance Data from the main menu.
Select the performance file type using the pick list. In this case we have AIX iostat data.
Then browse for the location where the data file is and choose it. Type in a unique Load Tag
or pick an existing tag if you want to model this data along with existing data. In this
example we have used a load tag of 1.
Select the GMT offset via the pick list.
By default the current date will be reflected in the Start Date. In this example for this AIX
data we have to specify the date on which the data was collected. Double clicking on the
Start Date will allow you to specify the date when the date was collected. With AIX iostat
data, the data collection date information is not available in the iostat output and hence has
to be included during import.
To map data to a replication group click on the “Map Replication Groups” icon or choose
Tools  Map Replication Groups from the main menu.
If multiple data sets were imported with different load tags, all the unique load tags will be
listed in the Load Tags to Include box. (In this example we see just one load tag).
Load tag of “1” has been populated. Click on “1”. This populates the Files to Include with
the AIX iostat data file name.
Now click on the file to be loaded in the Files to include box.
One can choose to include all volumes or alternately specify the file for the volumes to be
included/excluded in the analysis. The file format is a single column with the named of the
volumes to be included/excluded. Out of all the volumes for which there is performance
data, we are interested in only a subset of volumes for our SRDF/S replication. These
devices are the ones specified in the CSV file.
Finally choose the Replication Group to map to via the pick list.
Note that more that one set of performance data can be mapped to a replication group. One
has the choice of doing a “Replace” or “Append” when mapping a data set to a Replication
Group.
So if one more data set is to be included, we would choose the “Append” radio button and
then pick another load tag, the corresponding performance data file and any
include/exclude file.
Click OK to complete the process.
The volume mapping can be confirmed by editing the Replication Group of the source array.
The mapping can be confirmed by editing the Replication Group of the source array. The
example shows the subset of volumes that have been mapped to the replication group. The
performance data can be Viewed or Exported as a CSV file.
To validate a model click on the “Validate Project Assets” icon or choose Tools  Validate
Project Assets from the main menu.
In this example, the project validation comes up with two warnings. The warnings tell us
that we have not defined any drive groups. For SRDF/S modeling this is not very crucial.
For SRDF/A modeling defining drive groups is important. BCSD will check for a balanced
configuration, so drive groups with the appropriate disks and RAID types should be
specified in order to get a complete SRDF/A risk analysis.
To run a model click on the “Run Modelling” icon or choose Tools  Run Modelling from the
main menu.
The project will be validated first and once the project is validated we can run the model by
specifying the Start/End times and the GMT offset. The start and end times specify the
times in the data files for which the analysis should actually be done. If you want all the
data to be analyzed simply change the start date to a date that pre-dates the data
collection date.
BCSD will show the progress of the modeling and once the modeling is complete it will show
a message that indicates that the modeling is complete.
Once the model has successfully run, we can take a look at the modeling results. The
modeling results are available for the Logical and Physical Relationships and for the Arrays.
We will take a look at some of the results of the analysis that we just performed.
The Modeling Properties tab of the Logical Relationship will show a summary of the
workload. For this case we can see that the Max Writes/s about 5,100.0 and that the
maximum raw throughput that would be required is about 105 MB/s. We can also see that
the RA utilization is almost 36%.
The Raw Throughput Chart shows the amount of bandwidth required to sustain the SRDF/S
solution. The green line represent the available throughput after accounting for all the
overheads. It is about 28 MB/s in this case, after accounting for the overheads. The
maximum required throughput for SRDF/S is around 105 MB/s. Even if a compression of
2:1 is used, the bandwidth is insufficient to sustain this SRDF/S solution. So more
bandwidth needs to be provided.
If there are insufficient remote adapters configured, the resulting performance will be
unacceptable. With two RAs configured, the chart shows a peak RA utilization of 40%. We
design for 50% utilization with SRDF/S, as indicated by the green line. So two RFs are
sufficient to support his workload. However if one RFs fails then the remaining RF will hit
80% utilization.
After initial synchronization, only write activity is replicated between the source and the
target arrays. For this reason, it is not surprising that application performance impacts are
most commonly detected on high write activity volumes. The top 15 most “Write Intensive”
volumes have been identified. If subsequent performance issues do arise, it is likely that
one or more of these volumes will be involved. BCSD will identify the possible problem
volumes in the Volume Exceptions tab. It is recommended that:
• Write activity for these volumes is traced to the initiating application.
• Multiple “hot” write active datasets or file systems are separated onto their own logical
volumes.
Volumes that cannot sustain the same throughput (in write I/Os per second) in the
proposed configuration are identified in the Volume Exceptions tab of the SRDF Logical
Relationship.
All the volumes that could potentially be a problem for SRDF/S are listed. In this example
we see that hdiskpower28 and hdiskpower58 could encounter the Volume Write Limits due
to the implementation of SRDF/S. At the present time, hdiskpower28 is receiving about 371
writes/s but with the implementation of SRDF/S as modeled the volume will only be able to
do about 230 write/s. Likewise hdiskpower58 is receiving 362 Writes/s but with SRDF/S it
can sustain only about 214 Writes/s. This may be unacceptable to the customer and must
be brought to their attention.
The recommended SRDF/S configuration does not have adequate bandwidth. The 2 RFs
configured on each Array (Local and Remote) are sufficient to keep the RA utilization at
about 50% and to have redundancy. The two problems volumes found during modeling
need to be addressed before the solution can be implemented.
After reviewing all of the charts, generate a customer-presentable report. Once you have
generated this Word document, you can tailor it to meet your customer’s specific needs.
This demo covers the modeling an SRDF/S solution with BCSD using Host data.
This demo covers the modeling an SRDF/S solution with BCSD using BTP data.
This lesson covered the details of designing an SRDF/S solution using BCSD and
performance data collected from host(s) attached to an array.
This module covered designing SRDF/S solutions. The factors that contribute to the
response time impact in SRDF/S are described in detail. Detailed description of the Business
Continuity Solution Design (BCSD) tool and its use for designing SRDF/S solutions, are also
covered.

1 Module: Designing SRDF/S Solutions

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

1 Module: Designing SRDF/S Solutions

Uploaded by

Copyright:

Available Formats

This module focuses on designing SRDF/S solutions.

The factors that contribute to the

T3: Speed = 45 Mbits/sec approx 4.5MBytes/sec

4K block: 4K / 4.5 = 0.9 msec

27K block: 27K / 4.5 = 5.9 msec

Write I/O per second / Max RA writes per second

SRDF/Synchronous FCIP Example with no SIRT

End-to-end link less than 10Gb

50MB/sec Ethernet circuit

Overhead = Fibre Channel 13% + Fibre Channel ACK 8% + FCIP 6% + IP 8% = 37%

Usable Network Throughput = 50MB/sec * (1 - .37) = 31.5MB/sec

For additional examples please refer to the

Each project consists of Sites, Network Circuits, Physical Relationships, Logical

We will investigate each of these steps in detail later on in this course.

SAR Name of command

-d Time and date stamp for each report

-b Buffer I/O statistics

600 Interval duration in seconds (10 minutes)

144 Count of intervals to display (24 hours of 10 minute intervals)

-d Displays only the disk utilization report

600 Interval duration in seconds (10 minutes)

144 Count of intervals to display (24 hours of 10 minute intervals)

-d Limits iostat output to the device utilization report only

-x Displays extended format

144 Count of intervals to display (24 hours of 10 minute intervals)

-Td Time and date stamp for each report

-x Displays extended device statistics

-r Comma separated format

600 Interval duration in seconds (10 minutes)

144 Count of intervals to display (24 hours of 10 minute intervals)

Setup Perfmon to collect Disk Statistics, off by default.

Configure Perfmon collection interval and schedule.

Configure Perfmon collection log file format as .CSV

The Primary Array is connected to the DR Array.

Select the GMT offset via the pick list.

Now click on the file to be loaded in the Files to include box.

Click OK to complete the process.

You might also like