RTVV, UN PROYECTO CON HISTORIA

During the performance test, the tools described in the Test methodology section generated the client workload for Exchange Server, SQL Server, and SharePoint Server simultaneously and the application performance was monitored. The solution team ran each test for 8 hours to simulate a normal working day. This section provides the detailed performance results.

Overview

Notes

• Benchmark results are highly dependent upon workload, specific application requirements, and system design and implementation.

Relative system performance will vary as a result of these and other factors. Therefore, this workload should not be used as a substitute for a specific customer application benchmark when critical capacity planning and/or product evaluation decisions are contemplated.

• All performance data contained in this report was obtained in a rigorously controlled environment. Results obtained in other operating environments may vary significantly.

• EMC Corporation does not warrant or represent that a user can or will achieve similar performance expressed in transactions per minute.

Test objectives

Testing of this solution validates application and VMAX 10K storage performance with FAST VP enabled.

We introduced RecoverPoint CRR replication into the environment to provide remote data protection, and a network emulator device to produce the network latency between the two sites. In this case, RPAs provided asynchronous replication, where the VMAX 10K array-based splitter splits all the writes and sends them to the production volumes and RPA. We conducted tests to verify the RecoverPoint replication impact on the production environment.

Test scenarios

The solution team used the following scenarios to test the solution:

• Baseline testing without RecoverPoint replication in place

• RecoverPoint CRR protection under 25 ms network latency (2,500 km round trip distance)

• RecoverPoint CRR protection under 85 ms network latency (8,500 km round trip distance)

Table 18 lists the performance counters that we monitored on the Hyper-V root servers during the baseline test.

Hyper-V root servers

• Hyper-V Hypervisor Virtual Processor\% Guest Run Time shows the percentage of virtual processor time spent in guest code for the virtual machines.

• Hyper-V Hypervisor Virtual Processor\% Hypervisor Run Time shows the percentage of processor time spent in hypervisor code for the virtual machines.

• Hyper-V Hypervisor Virtual Processor\% Total Run Time shows the percentage of processor time spent in guest and hypervisor code for the virtual machines.

The processor utilization remained in a healthy state on all Hyper-V nodes.

Table 18. Hyper-V processor usage in baseline test

Performance counter Target Node 1 Node 2 Node 3 Node 4 Hyper-V Hypervisor Virtual

Processor\% Guest Run Time <65% 43.2% 44.9% 35.0% 38.9%

Hyper-V Hypervisor Virtual

Processor\% Hypervisor Run Time <5% 4.9% 4.1% 4.7% 3.4%

Hyper-V Hypervisor Virtual

Processor\%Total Run Time <70% 48.1% 49.0% 39.7% 42.3%

Table 19 shows the detailed LoadGen test results on the Exchange Mailbox Server and HUB/CAS server. Performance data was collected at 15-second intervals for the duration of each 8-hour test run. For accuracy, the results of the first and the last hours were discarded and were averaged over the duration of the rest of the test.

Exchange Server 2010

As shown in Table 19, the performance results were all within the acceptable parameters.

Table 19. Exchange LoadGen results in baseline test

Server Performance counter Target Result

MBX server Processor\%Processor Time < 80% 52.6%

MSExchangeIS\RPC Requests < 70 2.1 MSExchangeIS\RPC Averaged Latency < 10 ms 2.8 ms MSExchange Database\I/O Database

Reads (Attached) Average Latency < 20 ms 16.7 ms MSExchange Database\I/O Database

Reads (Recovery) Average Latency < 200 ms 16.8 ms MSExchange Database\I/O Database

Writes (Attached) Average Latency < 20 ms 4.0 ms MSExchange Database\I/O Database

Writes (Recovery) Average Latency < 200 ms 4.7 ms MSExchange Database\IO Log Writes

Average Latency < 10 ms 2.7 ms HUB /CAS server Processor\%Processor Time < 80% 40.8%

MSExchange RpcClientAccess\RPC

Averaged Latency < 250 ms 12.3 ms

Server Performance counter Target Result MSExchange RpcClientAccess\RPC

Requests < 40 4.2

\MSExchangeTransport

Queues(_total)\Aggregate Delivery

Queue Length (All Queues) < 3,000 1.5

\MSExchangeTransport

Queues(_total)\Active Mailbox Delivery

Queue Length < 250 1.2

\MSExchangeTransport

Queues(_total)\Active Remote Delivery

Queue Length < 250 0

The baseline performance test indicated the maximum user load on the production SharePoint farm when combined with the SQL and SharePoint working load in the entire environment. We ran this test for eight hours with a full user load.

SharePoint Server 2010

We used a common mix of user profiles to emulate different types of business organizations. For example, some organizations are browse-intensive, while others are search- and/or modify-intensive. Table 20 shows the user load profile in this solution.

Table 20. User load profile

User profile Percentage

Browse/Search/Modify 80/10/10

As the “Modify” test scenario involves the following three parts, we expected the test time for this scenario to be longer when compared with “Browse” and “Search”:

• Download document form SharePoint

• Modify the metadata of the document

• Upload document to SharePoint

Also, the incremental crawl ran every five minutes to make sure the index was up to date and the query results were accurate.

The test results in Table 21 show that the maximum user capacity is 35,308.

Table 21. SharePoint VSTS results in baseline test

Performance counter Target Test result

Passed tests/sec N/A 58

Concurrency (%) N/A 10

Maximum user capacity N/A 35,308

Browse average response time < 3 sec 0.6 sec Search average response time < 3 sec 1.65 sec Modify average response time < 5 sec 4.73 sec

Figure 18 shows the Passed Tests/Sec in the above test profile. The average number is 58 with three WFEs.

Figure 18. Passed Tests/Sec in the VSTS baseline test

During the test, the WFE server can experience a very heavy CPU load. We recorded an average of about 70 percent CPU usage with frequent spikes up to 96.67 percent, as shown in Table 22. This indicates that when we met the full user load, the bottleneck was CPU utilization on the WFE servers.

Table 22. SharePoint VM CPU and memory usage in baseline test

Server Average CPU time (%) Average memory usage (%)

SQL01 47 99

SQL02 26 99

WFE01 70 71.5

WFE02 72 71.6

WFE03 74 71.7

APP01 12 37.8

APP02 11 35.6

Table 23 lists some important disk performance counters for SharePoint content database, property database, and crawl database.

Table 23. Disk performance for SharePoint databases

LUNs Performance counter Target Results

Content DB Avg. Disk Sec/Reads <20 ms 4 ms Avg. Disk Sec/Writes <20 ms 3 ms

Avg. IOPS N/A 137

Max. IOPS N/A 475

Log for Content DB Avg. Disk Sec/Reads <20 ms 0 ms Avg. Disk Sec/Writes <20 ms 3 ms

Avg. IOPS N/A 4

Property DB Max. IOPS N/A 1,565

Crawl DB Max. IOPS N/A 1,571

In another common scenario, when full crawl was running at the back-end while the above test profile was still in process, we achieved about 6,500 IOPS on average for the whole SharePoint farm. For VSTS, the Passed Tests/Sec was 53 on average.

Figure 19 shows detailed IOPS information from the VMAX 10K storage for the entire SharePoint farm.

Figure 19. Total IOPS for the SharePoint farm during full crawl

On average, the SQL Server processed over 1,800 database transactions per second during the 8-hour test. Microsoft’s acceptable user response times were comfortably met at all times.

SQL Server 2012

Note: We configured this 8-hour test with realistic user values and user load concurrency counts. The aim of this test was not to run the SQL Server at maximum performance capacity, but to run the test at capacity with

acceptable headroom for additional operations. The TPC-E-like user workload translated to back-end SQL Server CPU Utilization was around 80 percent on both SQL01and SQL02. Average test response time stayed well within acceptable parameters.

We recorded the SQL Server response times for client requests to determine the amount of time it took the SQL Server to respond to a client request and gauge the overall client experience. The Transaction/sec average response time per request should not exceed 10 ms.

Throughout the duration of the 8-hour load tests, SQL Server performance remained stable. Due to checkpoint activity, some peaks and dips were seen.

We tracked the Transaction/sec performance counter on the SQL Server to monitor the response time.

We tracked the following performance monitor counters on SQL Server to monitor the disk I/O activities:

• Latency

ƒ Reads: Average Disk sec/read

ƒ Writes: Average Disk sec/write

ƒ Transfers: Average Disk sec/transfer

• IOPS

ƒ Read IOPS: Disk Reads/sec

ƒ Write IOPS: Disk Writes/sec

ƒ Total IOPS: Disk Transfers/sec

From a SQL Server client perspective, we validated each test by comparing the results of select performance counters to the allowed Microsoft-specified criteria. We

collected the performance counter data at one-second intervals for the duration of each test run. We discarded the results of the first and last hours and averaged the results over the remaining test duration.

Table 24 details the SQL Server results.

Table 24. SQL Server results in baseline test

Counter Target SQL01 SQL02

Transaction/sec N/A 1,881 2,158

Before FAST VP was enabled, all database LUNs were initially bound to the RAID 5 (3+1) FC storage pool (450 GB 15k FC disks). After enabling the FAST VP policy, the

highly active data (hot data) was automatically moved to the FAST Flash tier, and the inactive data (cold data) moved to the SATA tier. In this situation, the total IOPS increased with better disk latency, and more transactions were processed from the client load.

During the baseline test, the VMAX 10K array and thin pools achieved good performance results. In general, the system met the IOPS requirements for all applications as designed, and still provides enough room for future growth. FAST VP offers a simple and cost-effective way to provide optimal performance of a given mixed configuration, by automatically tiering storage to the changing application needs. Customers can change the policy as they want to meet different application requirements.

VMAX 10K storage

Figure 20 and Figure 21 show that front-end utilization of the VMAX 10K array was below 25 percent and around 50 percent at the back end. The VMAX 10K array can handle the mixed Microsoft workload without any system stress.

Figure 20. VMAX 10K front-end utilization

Figure 21. VMAX 10K back-end utilization

After FAST VP stabilized the data movement, the average utilization of FC and SATA disks was below 60 percent, while the average utilization of the EFD disks was around 30 percent.

Figure 22 shows disk utilization on the VMAX 10K storage array. As we did not use all disks on the array, some disks show zero utilization.

Figure 22. VMAX 10K disk utilization

In this solution, we used RecoverPoint CRR to replicate all data storage volumes in the production environment to a remote site. This section describes application

performance while RecoverPoint replication was being performed in the background, and RecoverPoint performance. We tested the following two scenarios:

RecoverPoint replication impact

• RecoverPoint CRR protection under 25 ms network latency

• RecoverPoint CRR protection under 85 ms network latency Application performance with RecoverPoint replication

We found that RecoverPoint replication has little impact on the production applications and the different latencies have little effect on the production performance either.

Table 25 provides a detailed comparison of the Exchange performance between the baseline and with RecoverPoint replication enabled. We can see that the key performance counters remain at the same level across the three test scenarios.

Table 25. Exchange LoadGen results in baseline and RecoverPoint replication tests Server Performance counter Target Baseline RP-25 ms RP-85 ms MBX server Processor\%Processor Time < 80% 52.6% 51.3% 53.1%

MSExchangeIS\RPC

Requests < 70 2.1 2.0 2.2

MSExchangeIS\RPC

Averaged Latency < 10 ms 2.8 ms 2.9 ms 3.0 ms MSExchange Database\I/O

Database Reads (Attached) Average Latency

< 20 ms 16.7ms 15.2 ms 15.9 ms

MSExchange Database\I/O Database Reads (Recovery) Average Latency

< 200 ms 16.8 ms 15.2 ms 17.2 ms

Server Performance counter Target Baseline RP-25 ms RP-85 ms Delivery Queue Length (All Queues)

Table 26 describes SharePoint performance between the baseline and with

RecoverPoint replication enabled. The Passed tests/sec remained the same and the response time was not affected by RecoverPoint replication.

Table 26. SharePoint VSTS results in baseline and RecoverPoint replication tests

Test scenario Target Baseline RP 25 ms RP 85 ms

Passed tests/sec N/A 58 58 58

Concurrency (%) N/A 10 10 10

Maximum user capacity N/A 35,308 35,308 35,308

Browse average response time < 3 sec 0.6 sec 0.58 sec 0.61 sec Search average response time < 3 sec 1.65 sec 1.58 sec 1.70 sec Modify average response time < 5 sec 4.73 sec 4.66 sec 4.71 sec

Table 27 provides a comparison of the SQL Server performance between the baseline and with RecoverPoint replication enabled. Similar to Exchange and SharePoint, the SQL Server performance did not show much change. There was a slight rise and fall in some counters but this was within the 5 percent range, which we consider normal behavior.

Table 27. SQL Server results in baseline and RecoverPoint replication tests

Test scenario Baseline RP–25ms RP–85ms

Counter Target SQL01 SQL02 SQL01 SQL02 SQL01 SQL02

Avg Disk sec/read < 10 ms 6 ms 4 ms 6 ms 5 ms 6 ms 4 ms Avg Disk sec/write < 5 ms 3 ms 3 ms 3 ms 3 ms 3 ms 3 ms Avg Disk sec/transfer < 10 ms 6 ms 5 ms 6 ms 5 ms 6 ms 4 ms Disk Reads/sec N/A 3,674 4,255 3,497 4,256 3,673 4,169

Disk Writes/sec N/A 512 581 495 574 517 574

Disk Transfers/sec N/A 4,186 4,836 3,992 4,830 4,190 4,743

Processor Time < 80% 79% 82% 82% 78% 81% 86%

Transaction/sec N/A 1,881 2,158 1,806 2,158 1,891 2,166

Figure 23 and Figure 24 compare the performance of the OLTP workloads, including the I/O latency and the total IOPS on both SQL Servers. RecoverPoint has little impact on the SQL Server performance.

Figure 23. SQL01 performance result comparison with the OTLP load running

Figure 24. SQL02 performance result comparison with the OTLP load running RecoverPoint performance under 25 ms latency

During the tests, we also recorded the performance on RecoverPoint. From

RecoverPoint version 3.2 on, a new export_consolidated_statistics CLI command is available that exports the performance data of RecoverPoint appliances. The exported data is bundled in a zipped file that contains multiple CSV files, where each file represents a different time slice. While many methods are available to analyze these CSV files, EMC provides a Long Term Analysis Tool based on Excel, with the powerful Pivot Charting feature to analyze RecoverPoint performance data. In the following section, we used this tool to demonstrate key RecoverPoint data during our testing.

Figure 25 shows the RecoverPoint Box Utilization in the test with 25 ms network latency. It is under 50 percent on average.

Figure 25. RecoverPoint Box Utilization in 25 ms latency test

Data lag and time lag are the two important counters to measure RecoverPoint RPO status. Figure 26 shows the RecoverPoint time lag on each of the consistency groups in the environment. The average time lag was only two seconds throughout the testing.

Figure 26. RecoverPoint time lag in 25 ms latency test

Figure 27 shows the RecoverPoint data lag on each of the consistency groups in the environment. The average data lag in average was around:

• 25 MB for the four Exchange Mailbox Server virtual machines

• 10 MB for the four SQL virtual machines (including two for SharePoint)

• 5 MB or even less for the other virtual machines

Figure 27. RecoverPoint data lag in 25 ms latency test

Figure 28 shows the RecoverPoint compression ratio on the consistency groups in the environment. RecoverPoint achieved around:

• 3x compression ratio on the Exchange Mailbox Server and SQL Server virtual machines

• 1.5x compression ratio on the SharePoint SQL virtual machines

Figure 28. RecoverPoint compression ratio in 25 ms latency test RecoverPoint performance under 85 ms latency

Figure 29 shows the RecoverPoint Box Utilization in the test with 85 ms network latency. It is under 60 percent on average.

Figure 29. RecoverPoint Box Utilization in 85 ms latency test

Figure 30 shows the RecoverPoint time lag on each of the consistency groups in the environment. The average time lag was only three seconds through the testing.

Figure 30. RecoverPoint time lag in 85 ms latency test

Figure 31 shows the RecoverPoint data lag on each of the consistency groups in the environment. The average data lag was around:

• 40 MB for the four Exchange Mailbox Server virtual machines

• 20 MB for the four SQL virtual machines (including two for SharePoint)

• 10 MB or even less for the other virtual machines

Figure 31. RecoverPoint data lag in 85 ms latency test

Figure 32 shows the RecoverPoint compression ratio on the consistency groups in the environment. Similar to the 25 ms latency test, RecoverPoint achieved around:

• 3x compression ratio on Exchange Mailbox Server and SQL Server virtual machines

• 1.5x compression ratio on the SharePoint SQL virtual machines

Figure 32. RecoverPoint compression ratio in 85 ms latency test

In document uumuuuuinhflI 530958709 (página 160-180)