I/O Performance of Cisco UCS M-Series Modular Servers with Cisco UCS M142 Compute Cartridges

White Paper I/O Performance of Cisco UCS M-Series Modular Servers with Cisco UCS M142 Compute Cartridges October 2015 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public. Page 1 of 19

Executive Summary Introduction The emergence of cloud-scale applications with massive scale-out requirements demands a dense computing platform with ease of provisioning for thousands of computing nodes across multiple deployment domains. These applications demand a single management window, power efficiency, shared network and basic local storage I/O, and best-in-class price-to-performance ratios. Cloud-scale distributed applications, such as massively multiplayer online games (MMOGs), high-performance computing (HPC) workloads, and video-transcoding applications, require a nonvirtualized infrastructure with a large number of physical servers with adequate processor speed, memory, and local storage capacity. To meet these demands, server vendors have tried to reduce the size of servers, to create smaller consumable units, with less focus on converged infrastructure and management. The result is miniaturized servers, or cartridges, each with its own individual storage controller, network controller, blade management controller, and hard drives. These cartridges are housed in a chassis that provides common power and cooling, and sometimes aggregation of networking resources. This approach does address the computational requirements of cloud-scale applications, but it increases the complexity of deployment, operations, and lifecycle management. Cisco UCS M-Series Modular Servers use a different approach. Building on the fundamentals of converged infrastructure, the Cisco UCS M-Series takes advantage of proven Cisco application-specific integrated circuit (ASIC) design and technologies to decouple the networking and storage components of the server cartridge and provide them as flexible, configurable resources that can be distributed as needed to the servers in the chassis. In this model, the server is a computing node that consists simply of CPU and memory resources, with standard PCI Express (PCIe) connectivity from the CPU to the chassis resources. The components shared in the chassis are the power, cooling, storage, and networking resources. In addition, the award-winning Cisco UCS Manager provides management and scalability to the M-Series modular chassis, bringing consistency and simplicity to device management. This document discusses how customers with applications such as MMOGs and distributed web and Java workloads can achieve nearly linear scalability on nonvirtualized computing servers with shared power, management, cooling, storage, and networking resources. In general, MMOGs and web-distributed workloads require limited but distributed computing resources and tend to use nonvirtualized or bare-metal services. Applications with such requirements are excellent candidates for modular servers. This document evaluates the performance of such applications across multiple cartridges plugged into a Cisco UCS M-Series modular chassis Audience The audience for this document includes customers, sales engineers, field consultants, professional services staff, IT managers, and partner engineering staff who want to deploy Cisco UCS M-Series Modular Servers. This document is intended to help customers seeking to understand the characterization of I/O performance on Cisco UCS M-Series servers used in a farm of nonvirtualized or bare-metal servers for distributed cloud-scale applications such as online gaming, video transcoding, and web workloads. With the innovative Cisco Unified Computing System (Cisco UCS) design, the M-Series provides a high-density, modular, and power-efficient platform to meet the needs of parallelized workloads. 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public. Page 2 of 19

Solution Overview The Cisco UCS M-Series Modular Servers include a new 2-rack-unit (2RU) chassis: the Cisco UCS M4308 Modular Chassis. This chassis supports eight Cisco UCS M142 Compute Cartridges for scalability to 16 compute nodes. The modular chassis is built on the foundation of proven Cisco innovation in virtual interface card (VIC) technology and is connected to a pair of Cisco UCS fabric interconnects with Cisco UCS Manager, providing ease and scalability with industry-leading Cisco UCS management. Figure 1 illustrates the Cisco UCS M-Series Modular Server architecture. Figure 1. Cisco UCS M-Series Modular Server Architecture The solution described in this document enhances the performance and scalability of cloud-scale applications such as MMOGs and distributed e-commerce application workloads, which truly harness the modular computing capabilities of the M-Series servers. Cloud-scale applications run concurrently on several bare-metal servers, and the applications themselves manage the availability of workloads. These applications are massively parallelized and scale horizontally. A typical application can spawned a number of smaller instances. The application instance flexibly adapts to the underlying infrastructure. Because of the massive scale, the deployment model requires only minimal computing elements. Resiliency and availability are built in the application layer. Recovery from any hardware failure is managed automatically by the application architecture. Figure 2 illustrates the cloud-scale deployment model. 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public. Page 3 of 19

Figure 2. Cloud-Scale Application Model Cisco UCS M-Series Modular Servers Cisco UCS M-Series Modular Servers were designed specifically for the highly parallelized workloads typically found in cloud, online gaming, and multivariable computing. This unique new design eliminates the complexity of traditional servers by disaggregating the underlying component parts. Underutilized and overprovisioned local resources that have historically been inside traditional servers (such as hard disk drives [HDDs], network I/O resources, and baseboard and network controllers) are now aggregated and shared across multiple computing nodes. These components include local disks and power, cooling, network I/O, and system management resources. This separation of components by the M-Series platform decouples the lifecycles of the component subsystems. Organizations no longer need to replace an entire system because the processors, hard drives, or network I/O resources need to be updated or refreshed. The M-Series allows application performance to be optimized by scaling subsystems to achieve the best ratio of computing nodes to network I/O and shared local storage resources in small, discrete increments. This new design also allows smaller increments of scale, so that your applications can have the number of computing nodes that they require to achieve the desired performance and availability without overprovisioning or wasting resources. 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public. Page 4 of 19

With this groundbreaking design, the M-Series provides a high-density, modular, and power-efficient platform designed to meet the needs of parallelized workloads with: Better performance per watt used Optimized computing capacity and rack space utilization Award-winning Cisco UCS Manager provides management for the M-Series with consistency and simplicity. Cisco UCS Manager is a model-based, automated tool for device management that allows easy integration with higherlevel tools using the system s open XML API. Cisco System Link Technology At the core of the Cisco UCS M-Series servers is Cisco System Link technology. The M-Series takes advantage of this technology to decouple the networking and storage components of the server cartridge and provide them as flexible, configurable resources that can be distributed as needed to the servers in the chassis. System Link technology is the third-generation technology underlying the VIC and the fourth-generation technology underlying the unified fabric in unified computing. It is this specific component that gives the computing nodes access to the shared I/O resources in the chassis. System Link technology helps create a new PCIe physical function called the Small Computer System Interface (SCSI) network interface card (NIC; snic) that presents a virtual storage controller to the operating system and maps multiple drive resources to a specific service profile in Cisco UCS. This innovative technology provides a mechanism that enables each computing node in the M-Series server to have its own specific virtual drive carved out of the available physical drives in the chassis. This capability is achieved using standard PCIe addressing, in which each computing node addresses its own snic. As a result, the nodes can share the same RAID controller without the need for multiroot I/O virtualization, and the operating system does not require any special knowledge of a change in the PCIe addressing format. Figure 3 illustrates the disaggregation of servers through System Link technology. Figure 3. Cisco System Link Technology Cisco UCS M4308 Modular Chassis The Cisco UCS M4308 Modular Chassis (Figure 4) extends the capabilities of the Cisco UCS portfolio to a highdensity 2RU form-factor chassis with up to eight front-access slots that accommodate up to eight single-wide cartridges. 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public. Page 5 of 19

The chassis architecture accommodates computing cartridges as well as other specialized cartridges. The rear of the chassis supports four solid-state disk (SSD) drives that are connected to an internal removable RAID controller. Storage capacity and connectivity are distributed to the pluggable computing cartridges using Cisco s thirdgeneration VIC. Network I/O is provided by two 40-Gbps Quad Small Form-Factor Pluggable (QSFP) ports, which aggregate all computing cartridge I/O and management traffic into a single connection for cable consolidation and efficiency. An upstream top-of-rack switch with VNTag support is required for the total solution and is available now with the Cisco UCS 6200 Series Fabric Interconnects. The Cisco UCS M4308 chassis is physically cabled to the Cisco UCS 6200 Series Fabric Interconnects. Fabric interconnects provide the management and communication backbone for the chassis and the installed computing cartridges. Up to 20 Cisco UCS M4308 chassis and associated cartridges can be attached to a pair of fabric interconnects and managed as part of a single domain. Centralized unified management is provided by Cisco UCS Manager, which comes embedded on the fabric interconnects. Figure 4. Cisco UCS M4308 Modular Chassis Cisco UCS M142 Compute Cartridge The Cisco UCS M142 Compute Cartridge (Figure 5) is the first in a series of cartridges that will be supported in the Cisco UCS M4308 Modular Chassis. The Cisco UCS M142 cartridge has two independent computing nodes. Each computing node has a single-socket Intel Xeon processor E3 series CPU with up to 32 GB of memory. Each computing node has an individual management connection to Cisco UCS Manager through the shared infrastructure within the chassis. Meeting the density and power-efficiency objectives of cloud-scale computing, the Cisco UCS M142 supports low-powerconsumption CPUs that provide optimal performance for specific applications. Applications that are suited to run on the Cisco UCS M142 include online content delivery, dedicated hosting, financial modeling, and business analytics. 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public. Page 6 of 19

Figure 5. Cisco UCS M142 Compute Cartridge Table 1 lists the hardware and software components of the Cisco UCS M-Series solution with Cisco UCS M142 cartridges. Table 1. Component Hardware and Software Configuration Components Configuration Cisco UCS M-Series Chassis Computing cartridge Shared internal storage 1 Cisco UCS M4308 Modular Chassis. 8 Cisco UCS M142 Compute Cartridges, each equipped with two physical servers, with each server having 1 Intel Xeon processor E3-1275L v3 and 32 GB of physical memory 4 x 400-GB 2.5-inch enterprise performance 6-Gbps SAS SSD drives 4 x 480-GB 2.5-inch enterprise value 6-Gbps SATA SSD drives 4 x 1.6-TB 2.5-inch enterprise performance 12-Gbps SAS SSD drives Fabric interconnect Operating system 2 Cisco UCS 6248UP 1RU fabric interconnects Microsoft Windows 2012 R2 Standard Cisco 12-Gbps SAS Modular RAID Controller The Cisco UCS M4308 Modular Chassis is equipped with a Cisco 12-Gbps serial-attached SCSI (SAS) modular RAID controller for internal drives. Solid-State Disk Drives The SSD drives used in the testing described in this document were selected based on the following factors: Low cost with higher-capacity SSD drive (480-GB SATA with 6 Gbps) High speed with lower-capacity SSD drive (400-GB SAS with 6 Gbps) High speed with high-capacity SSD (1.6-TB SAS with 12 Gbps) For the most shared storage, using a 1.6-TB SSD drive, the chassis has 6.4 TB of shared storage capacity. A fully populated chassis with 16 servers can use the shared storage by having logical unit numbers (LUNs) configured on each server. To meet the requirements of different application environments, Cisco offers both enterprise performance SSD drives and enterprise value SSD drives. These all deliver superior performance compared to HDDs; however, enterprise performance SSD drives support greater read/write workloads and have a longer expected service life. Enterprise value SSD drives provide relatively large storage capacity at lower cost, but they do not have the endurance of the enterprise performance SSD drives. 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public. Page 7 of 19

Enterprise performance SSD drives provide high endurance and support up to 10 full-drive write operations per day. These drives are targeted at write-centric I/O applications such as caching, online transaction processing (OLTP), data warehousing, and virtual desktop infrastructure (VDI). Enterprise value SSD drives provide low endurance and support up to 1 full-drive write operation per day. These drives are targeted at read-centric I/O applications such as OS boot, streaming media, and collaboration. Performance Data Performance data was obtained using the Iometer measurement tool, with analysis based on the metrics of I/O operations per second (IOPS) for random I/O workloads, and megabytes per second (MBps) throughput for sequential I/O workloads. From this analysis, specific recommendations can be made for storage configuration parameters. Many combinations of drive types and RAID levels are possible. For these I/O performance characterization tests, performance evaluations were limited to 400-GB, 480-GB, and 1.6-TB SSD drives, with configurations of RAID 0, 1, and 5 virtual disks because these are used for I/O access for most of the use cases targeted for these servers. Virtual Disk Options The following controller options can be configured with virtual disks to accelerate write and read performance and provide data integrity: RAID level Stripe size Access policy Disk cache policy I/O cache policy Read policy Write policy RAID Levels Table 2 summarizes the supported RAID levels and their characteristics. Table 2. RAID Levels and Characteristics RAID Level Characteristics Parity Redundancy RAID 0 Striping of 2 or more disks to achieve optimal performance No No RAID 1 Data mirroring on 2 disks for redundancy with slight performance improvement No Yes RAID 5 Data striping with distributed parity for improved and fault tolerance Yes Yes RAID 6 Data striping with dual parity with dual fault tolerance Yes Yes RAID 10 Data mirroring and striping for redundancy and performance improvement No Yes For the scope of the testing described here, RAID 0, 1, and 5 were used. Access Policy The following access policy options were considered: RW: Read and write access is permitted. 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public. Page 8 of 19

Read Only: Read access is permitted, but write access is denied. Blocked: No access is permitted. Disk Cache Policy The following disk cache policy options were considered: Disabled: Disk caching is disabled. The drive sends a data transfer completion signal to the controller when the disk media has actually received all the data in a transaction. This process helps ensure data integrity in the event of a power failure. Enabled: Disk caching is enabled. The drive sends a data transfer completion signal to the controller when the drive cache has received all the data in a transaction. However, the data has not actually been transferred to the disk media, so data may be permanently lost in the event of a power failure. Although disk caching can accelerate I/O performance, it is not recommended for enterprise deployments. I/O Cache Policy The following I/O cache policy options were considered: Direct: Data transfers from read and write operations are not buffered in cache memory. Cached: Data transfers from read and write operations are buffered in cache memory. Subsequent read requests for the same data can then be satisfied from the cache. Note that Cached I/O refers to the caching of read data, and Read Ahead refers to the caching of speculative future read data. Read Policy The following read policy options were considered: No Read Ahead (Normal Read): Only the requested data is read, and the controller does not read ahead any data. Always Read Ahead: The controller reads sequentially ahead of requested data and stores the additional data in cache memory, anticipating that the data will be needed soon. Write Policy The following write policy options were considered: Write Through: Data is written directly to the disks. The controller sends a data transfer completion signal to the host when the drive subsystem has received all the data in a transaction. Write Back: Data is first written to the controller cache memory, and when it receives acknowledgment from the host, data is flushed to the disks. Data is written to the disks when the commit operation occurs at the controller cache. The controller sends a data transfer completion signal to the host when the controller cache has received all the data in a transaction. Write Back with Battery Backup: Battery backup is used to provide data integrity protection in the event of a power failure. Battery backup is always recommended for enterprise deployments. The Write Through setting was used for all disk I/O testing performed on the Cisco UCS M-Series servers. 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public. Page 9 of 19

SDD Drive Performance Results Three choices of SSD drive (400-GB SAS, 480-GB SATA, and 1.6-TB SAS) are available for the current Cisco UCS M-Series servers. For testing purposes, the following workloads were run: Disk I/O (sequential and random access) Disk I/O plus network I/O (combined), run together (from the same server) to reproduce a typical workload scenario Figures 6 through 19 were prepared from Iometer measurement data. They illustrate the I/O performance of: 400-GB 6-Gbps SAS enterprise performance (high endurance) SSD drives 480-GB 6-Gbps SATA enterprise value SSD drives 1.6-TB 12-Gbps SAS enterprise performance (high endurance) SSD drives Disk I/O and network I/O combined using 1.6-TB 12-Gbps SAS SSD drives Table 3 shows the workload and access patterns used in the tests. Table 3. Workload and Access Patterns I/O Mode Sequential (240-KB block size) Random (8-KB block size) I/O Ratio (Read:Write) 100:0 0:100 RAID 0 RAID 1 RAID 0 RAID 1 70:30 RAID 5 In this performance testing, RAID 0, 1, and 5 were considered. RAID 0 and 1 were used to get the raw performance data on SSD drives with sequential read/write operations using 240 KB as the optimal block size. For random IOPS, RAID 5 was used with an 8-KB block size for efficiency in application workloads. Graph Data In the graphs in Figures 6 through 19, on the X axis, ser represents the number of servers, and cart represents the number of Cisco UCS M142 cartridges. In a single M142 cartridge, a maximum of two servers can be run. Data was collected for the following configurations: 1 server: 1 cartridge 2 servers: 1 cartridge 4 servers: 2 cartridges 4 servers: 4 cartridges 8 servers: 4 cartridges 8 servers: 8 cartridges 16 servers: 8 cartridges 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public. Page 10 of 19

Disk I/O Performance for 400-GB 6-Gbps SAS Enterprise Performance (High Endurance) SSD Drives Figures 6 through 10 show the results for 400-GB 6-Gbps SAS enterprise performance SSD drives. Figure 6. RAID 0 Sequential Read (100% Read and 0% Write) Figure 6 illustrates the sequential read bandwidth for 400-GB SSD RAID 0 configurations with the I/O workload varying from 1 server to 16 servers. The 100 percent read and 0 percent write tests reached peak bandwidth of about 2200 MBps without exceeding acceptable response times. Figure 7. RAID 0 Sequential Write (0% Read and 100% Write) Figure 7 illustrates the sequential write bandwidth behavior for 400-GB SSD RAID 0 configurations ranging from 1 server to 16 servers. The 100 percent write and 0 percent read tests reached peak bandwidth of about 1600 MBps without exceeding acceptable response-time limits. 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public. Page 11 of 19

Figure 8. RAID 1 Sequential Read (100% Read and 0% Write) Figure 8 illustrates the sequential read bandwidth for 400-GB SSD RAID 1 configurations ranging from 1 server to 16 servers. The results are similar to those for RAID 0 (2200-MBps peak bandwidth), with a workload of 100 percent read and no write operations. Figure 9. RAID 1 Sequential Write (0% Read and 100% Write) Figure 9 illustrates the sequential write bandwidth for 400-GB SSD RAID 1 configurations ranging from 1 server to 16 servers. The peak bandwidth is reduced to almost half (800 MBps) that for RAID 0, which is expected given that two write I/O processes are issued for every single write operation. 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public. Page 12 of 19

Figure 10. RAID 5 Random IOPS (70% Read and 30% Write) Figure 10 illustrates RAID 5 random read (70 percent) and write (30 percent) performance with 8 KB as the block size on 400-GB SSD drives. For random workloads, IOPS is a more appropriate measure than bandwidth, and hence it is used. The IOPS varied nearly linearly (when scaled from 1 server to 16 servers), peaking at about 15,000 IOPS for a 16-server configuration, and the response time stayed well within limits. Disk I/O Performance for 480-GB 6-Gbps SATA Enterprise Value SSD Drives Figures 11 through 15 show the results for 480-GB 6-Gbps SATA enterprise value SSD drives. Figure 11. RAID 0 Sequential Read (100% Read and 0% Write) Figure 11 illustrates the sequential read bandwidth for 480-GB SSD RAID 0 configurations with the I/O workload varying from 1 server to 16 servers. The 100 percent read and 0 percent write tests reached peak bandwidth of about 1500 MBps without exceeding acceptable response times. 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public. Page 13 of 19

Figure 12. RAID 0 Sequential Write (0% Read and 100% Write) Figure 12 illustrates the sequential read bandwidth for 400-GB SSD RAID 0 configurations with the I/O workload varying from 1 server to 16 servers. The 0 percent read and 100 percent write workload reached peak bandwidth of about 1450 MBps with acceptable response times. Figure 13. RAID 1 Sequential Read (100% Read and 0% Write) Figure 13 illustrates the sequential read bandwidth for 480-GB SSD RAID 1 configurations with I/O workload varying from 1 server to 16 servers. The results are similar to those for RAID 0 (about 1600-MBps peak bandwidth), with a workload of 100 percent read operations and no write operations. 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public. Page 14 of 19

Figure 14. RAID 1 Sequential Write (0% Read and 100% Write) Figure 14 illustrates the sequential write bandwidth for 400-GB SSD RAID 1 configurations ranging from 1 server to 16 servers. The peak bandwidth is reduced to almost half (800 MBps) that for RAID 0, which is expected given that two write I/O processes are issued for every single write operation. Figure 15. RAID 5 Random IOPS (70% Read and 30% Write) Figure 15 illustrates RAID 5 random read (70 percent) and write (30 percent) performance with an 8-KB block size on 480-GB SSD drives. The IOPS varied nearly linearly (when scaled from 1 server to 16 servers), peaking at about 15,000 IOPS for 16 servers configuration, and the response time stayed well within limits. Random IOPS performance on RAID 5 testing illustrated that the RAID 5 IOPS values were less than the RAID 0 IOPS values. This behavior is expected, because RAID 5 has four I/O penalties, and write operations are expensive in a RAID 5 configuration. Disk I/O Performance for 1.6-TB 12-Gbps SAS Enterprise Performance (High Endurance) SSD Drives Tests were conducted on 1.6-TB SSD drives with RAID 0 configurations to determine the maximum bandwidth given that the SAS adapter used is 12 Gbps (unlike the 400- and 480-GB SSD drives, which use a 6-Gbps adapter). Figures 16 and 17 show the results. 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public. Page 15 of 19

Figure 16. RAID 0 Sequential Read (100% Read and 0% Write) Figure 16 illustrates the sequential read bandwidth for 1.6-TB SSD RAID 0 configurations ranging from 1 server to 16 servers. The 100 percent read and 0 percent write workload reached the maximum bandwidth of about 3000 MBps for 16 servers with acceptable response times. This result shows that the SAS SSD drive with a 12-Gbps adapter can consume 35 percent more bandwidth than the SAS drive with a 6-Gbps adapter for a 100 percent read workload. Figure 17. RAID 0 Sequential Write (0% Read and 100% Write) Figure 17 illustrates the sequential write bandwidth for 1.6-TB SSD RAID 0 configurations ranging from 1 server to 16 servers. The 0 percent read and 100 percent write workload reaches a peak bandwidth of about 1400 MBps for 16 servers. Performance for Simultaneous Disk and Network I/O on 1.6-TB 12-Gbps SAS Enterprise Performance (High Endurance) SSD Drives Disk I/O tests and network I/O tests were run together to verify that disk I/O is not affected while network traffic is running, because the Cisco UCS M-Series architecture uses System Link technology in the controller (for both storage and Ethernet traffic). Figures 18 and 19 show the results. 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public. Page 16 of 19

Figure 18. RAID 0 Sequential Read with Network I/O (100% Read and 0% Write with Network I/O) Figure 18 illustrates the disk traffic and network traffic behavior for 1.6-TB SSD RAID 0 configurations with 100 percent read and 0 percent write operations. Disk read bandwidth is not degraded, and it reached the same peak value of about 3000 MBps as in the test with disk traffic alone (see Figure 16). This behavior is tested with 4, 8, and 16 servers and both network and disk bandwidth increases Figure 19. RAID 0 Sequential Write with Network I/O (0% Read and 100% Write with Network I/O) Figure 19 illustrates the disk traffic and network traffic behavior for 1.6-TB SSD RAID 0 configurations with 0 percent read and 100 percent write operations. The disk write bandwidth was not degraded, and it reached the same peak value of about 1400 MBps as in the test with disk traffic alone (see Figure 17). This behavior was tested with 4, 8, and 16 servers and both network and disk bandwidth increases For More Information See Cisco UCS M-Series Modular Servers at http://www.cisco.com/c/en/us/products/servers-unified-computing/ucs-m-series-modular-servers/index.html. 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public. Page 17 of 19

Appendix: Test Environment Tables 4 through 7 summarize the hardware and software configurations used for the I/O performance measurement tests presented in this document. The tables list the server properties, BIOS properties, virtual drive policies, and Iometer settings. Table 4. Server Properties Name Product name Cartridge name CPUs: 1 CPU on each server Value UCSME-4308 UCSME-142L1-M4 Intel Xeon processor CPU E3-1275L v3 at 2.70 GHz Number of cores 4 Number of threads 8 Total memory Memory DIMMs (16) Memory speed Network controller Storage controller RAID controller SSD drives (4) 32 GB 8 GB x 4 UDIMMs 1600 MHz Cisco System Link Cisco System Link Cisco 12-Gbps SAS modular RAID controller 400-GB 6-Gbps SATA enterprise performance SSD drive (Samsung SM1625) 480-GB 6-Gbps SAS enterprise value SSD drive (Intel S3500) 1.6-TB 12-Gbps SAS enterprise performance SSD drive (Toshiba PX02SMB160) Table 5. BIOS Properties Name BIOS version Intel Hyper-Threading Technology Number of enabled cores Enhanced Intel SpeedStep Technology (EIST) Turbo Mode Intel Virtualization CPU Advanced Encryption Standard (AES) Execute Disable Bit Intel VT-d Hardware Prefetcher Intel VT-d Address Translation Services (ATS) Support Boot Performance Mode Energy Performance Adjacent Cache Line Prefetcher Run CPU Built-in Self-Test (BIST) During n Value UCSME.142M4.2.0.3d.0.031320150453 Enabled All Enabled Enabled Enabled Enabled Enabled Enabled Enabled Disabled Turbo Performance Performance Enabled Disabled 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public. Page 18 of 19

Table 6. System default values configured for SSD Virtual Drive Policies Stripe Size Access Policy Read Policy Write Policy IO Policy Drive Cache 64 KB Read Write Normal Write Through Direct I/O Disabled Table 7. Iometer Settings Name Value Iometer version Version 1.1.0 Run time 45 minutes (per access specification) Ramp-up time 0 second Record results All Number of workers 1 Number of outstanding I/O operations per target 1 to X number of outstanding IO to scale bandwidth and IOPS as per the workload Write I/O data pattern Repeating bytes Transfer delay 0 ms Burst length 1 I/O operation Align I/O operations on Request-size boundaries Reply size No reply Printed in USA C11-735873-00 10/15 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public. Page 19 of 19