Cost and performance comparison for OpenStack compute and ...

COST AND PERFORMANCE COMPARISON FOR OPENSTACK COMPUTE AND STORAGE INFRASTRUCTURE

Hyper-converged architectures are emerging that can bring increased performance and significant cost reduction to virtualized infrastructures, where compute, network, and storage coexist closely on physical resources. Another trend shows cloud frameworks, such as OpenStack, are emerging and maturing to offer APIs for more efficient self-service provisioning and consumption of such resources. The combination of these industry trends and technology developments provides customers with many options when choosing the underlying virtualization technology for their cloud. Two key components of cloud infrastructure design factor into its performance—the hypervisor itself and its underlying storage—making the architecture of the storage a critical consideration for businesses. Two main approaches to storage architectures are converged and non-converged. Non-converged storage exists on its own “tier,” separate from the compute infrastructure, and is typically shared storage either provided by traditional storage arrays or built from commodity server hardware running specialized software. Red Hat Storage Server uses this model by aggregating disks on multiple commodity server nodes and running a Red Hat version of GlusterFS. The converged storage model, which also presents shared storage to compute resources, collapses the storage and compute hardware tiers and leverages local disks in each compute node so that performance and capacity can be scaled out together. VMware Virtual SAN takes this converged approach, using disks in each compute node, while also presenting the aggregate storage pool to the vSphere cluster as a < ovf_exported.vmdk 5. Use a Web browser to navigate to the IP address of the controller VM and login to Dashboard. 6. Click Flavors and create a new flavor with the appropriate sizing. 7. Under admin, click Instances. 8. Launch an instance with the appropriate flavor and select the base image under Boot from Image. 9. Repeat step 8 until there are 16 instances created. Cost and performance comparison for OpenStack compute and storage infrastructure

A Principled Technologies test report 14

Constructing the Red Hat environment Installing Red Hat Storage 2.1 onto the Dell PowerEdge R720 servers Repeat these steps for each Dell PowerEdge R720. 1. Insert the Red Hat Storage installation media and power on the server, choosing to boot from the DVD drive. 2. Select Install or upgrade an existing system and press Enter. 3. Use the TCP/IP configuration screen to add a static IP address. 4. Press Next at the installation welcome screen. 5. Choose a language and press Enter. 6. Choose a keyboard layout and press Enter. 7. Select Basic Storage Devices and click Next. 8. Enter a hostname and click Next. 9. Select your time zone and click Next. 10. Enter a root password twice and click Next. 11. Select Use All Space and click Next. 12. At the Boot Loader screen, click Next. 13. At the Minimal Selection screen, click Next. 14. After the installation completes, reboot the server. Installing Red Hat Enterprise Linux onto the Dell PowerEdge C8000 servers Repeat these steps for each Dell PowerEdge C8000. 1. Insert the Red Hat Storage installation media and power on the server, choosing to boot from the DVD drive. 2. Select Install or upgrade an existing system and press Enter. 3. Use the TCP/IP configuration screen to add a static IP address. 4. Press Next at the installation welcome screen. 5. Choose a language and press Enter. 6. Choose a keyboard layout and press Enter. 7. Select Basic Storage Devices and click Next. 8. Enter a hostname and click Next. 9. Select your time zone and click Next. 10. Enter a root password twice and click Next. 11. Select Use All Space and click Next. 12. At the Boot Loader screen, click Next. 13. At the Minimal Selection screen, click Next. 14. After the installation completes, reboot the server. Installing Red Hat OpenStack Platform 4 We installed Red Hat OpenStack onto a VM on a separate server. We placed all services on one VM running Red Hat Enterprise Linux 6.5 and had one NIC connected to the compute network. Our setup closely follows the documentation found here: https://access.redhat.com/site/documentation/enUS/Red_Hat_Enterprise_Linux_OpenStack_Platform/4/html-single/Installation_and_Configuration_Guide/index.html Cost and performance comparison for OpenStack compute and storage infrastructure

A Principled Technologies test report 15

Building the test VMs 1. Upload the VMDK file used from the VMware solution to the Red Hat OpenStack controller. 2. Convert the VMDK file to qcow2 format: qemu-img convert –f vmdk –O qcow2 ovf_exported.vmdk base.qcow2 3. Upload the converted disk to Glance: glance image-create --name=base --disk-format=qcow2 --container-format=bare \ --is-public=True --file=base.qcow2 4. Use a Web browser to navigate to the IP address of the controller VM and login to Dashboard. 5. Click Flavors and create a new flavor with the appropriate sizing. 6. Under admin, click Instances. 7. Launch an instance with the appropriate flavor and select the base image under Boot from Image. 8. Repeat step 8 until there are 16 instances created.

Running the benchmarks Building the YCSB and Cassandra environment The YCSB and Cassandra environment consists of 16 VMs running the Cassandra back-end, and four client VMs running the YCSB benchmarking client. Each of the 20 VMs begins as a minimal CentOS installation with the Software Development Workstation package added. 1. Set a static IP address and turn off iptables for each VM. 2. Edit /etc/hosts on each VM to reflect the hostnames of your choice. 3. Download YCSB and Maven onto the client VMs and Cassandra onto the back end VMs. We used the following links: 

YCSB: git clone https://github.com/cmatser/YCSB.git



Maven: http://maven.apache.org/download.cgi



Cassandra: http://cassandra.apache.org/download/

4. On the client VMs, run mvn clean package in the YCSB directory to build YCSB. 5. On the backend VMs, configure cassandra.yaml to reflect the following: 

listen_address:



broadcast_address:



rpc_address:



seed: “”

6. Run ant in the Cassandra directory to build Cassandra. 7. Start Cassandra on the seed nodes (node 1). Cassandra is started by running bin/cassandra. Once the line “Startup completed! Now serving reads.” appears, Cassandra has started and pressing Enter will return to the shell. 8. Start Cassandra on the subsequent nodes. Output should reflect a bootstrapping process as they receive configuration information from the seed node. 9. On one of the Cassandra nodes, run bin/cqlsh 9160 to connect the Cassandra CLI. Run the following commands to create and configure a keyspace and table for YCSB to use. Take care to

Cost and performance comparison for OpenStack compute and storage infrastructure

A Principled Technologies test report 16

include the semicolon after each command and keep the names ycsb and usertable as they are YCSB defaults. 

create keyspace ycsb with replication = { ‘class’ : ‘SimpleStratregy’, ‘replication_factor’ : 1 };



use ycsb;



create table usertable(y_id varchar primary key, field0 varchar, field1 varchar, field2 varchar, field3 varchar, field4 varchar, field5 varchar, field6 varchar, field7 varchar, field8 varchar, field9 varchar);

10. Copy the Cassandra .jar files in …apache-cassandra-2.0.4/lib/ to /YCSB/cassandra/target/ on the client VMs. Running the YCSB benchmark We first used one of the YCSB clients to generate 400,000,000 records into the Cassandra database. We then edited one of the standard workload files to reflect a 70/30 read to insert ratio and ran the YCSB client from four VMs simultaneously. To generate the dataset, run the following command from one YCSB client: ./bin/ycsb load cassandra-cql -P workloads/workloadc_70_30 -p host=192.168.1.101 -p port=9042 -p recordcount=400000000 -p operationcount=400000000 -p threads=16 -s > load.dat To run the benchmark, run the following command from each YCSB client simultaneously: ./bin/ycsb load cassandra-cql -P workloads/workloadc_70_30 -p host=192.168.1.101 -p port=9042 -p recordcount=400000000 -p operationcount=8000000 -p threads=128 -s > run.dat Installing FIO onto the test VMs Our FIO environment consisted of 16 test VMs with the same specification as the Cassandra VMs. Repeat the following steps for each test VM. 1. Download FIO 2.1.6.1 from an appropriate mirror and extract the package. 2. Edit the “configure” file to change the “ext4 move extent” flag to yes 3. Run configure 4. Run make install 5. Create a 6.2 GB test file by running: dd if=/dev/zero of=/fio_test_file oflag=direct bs=1M count=6200 6. Run FIO on the test file: fio --ioengine=libaio --name=test1 --filename=/fio_test_file --overwrite=1 -direct=1 --iodepth=64 --bs=4k --rw=randrw --rwmixread=70 --size=6200m -runtime=300

Cost and performance comparison for OpenStack compute and storage infrastructure

A Principled Technologies test report 17

APPENDIX C – TEST RESULTS Our testing showed that VMware vSphere with VSAN outperformed the Red Hat solution in the NoSQL Cassandra database testing, as well as raw disk performance. VMware vSphere with VSAN was also cheaper over three years. Figure 8 shows each result. Solution VMware vSphere with VSAN RHEL on Red Hat Storage

YCSB OPS 14,063 9,208

IOPS 85,832 33,148

Cost $124,291.52 $168,690.20

Figure 8: Performance results for the VMware vSphere with VSAN solution and the Red Hat Storage Server solution.

Cost and performance comparison for OpenStack compute and storage infrastructure

A Principled Technologies test report 18

ABOUT PRINCIPLED TECHNOLOGIES

Principled Technologies, Inc. 1007 Slater Road, Suite 300 Durham, NC, 27703 www.principledtechnologies.com

We provide industry-leading technology assessment and fact-based marketing services. We bring to every assignment extensive experience with and expertise in all aspects of technology testing and analysis, from researching new technologies, to developing new methodologies, to testing with existing and new tools. When the assessment is complete, we know how to present the results to a broad range of target audiences. We provide our clients with the materials they need, from market-focused data to use in their own collateral to custom sales aids, such as test reports, performance assessments, and white papers. Every document reflects the results of our trusted independent analysis. We provide customized services that focus on our clients’ individual requirements. Whether the technology involves hardware, software, Web sites, or services, we offer the experience, expertise, and tools to help our clients assess how it will fare against its competition, its performance, its market readiness, and its quality and reliability. Our founders, Mark L. Van Name and Bill Catchings, have worked together in technology assessment for over 20 years. As journalists, they published over a thousand articles on a wide array of technology subjects. They created and led the Ziff-Davis Benchmark Operation, which developed such industry-standard benchmarks as Ziff Davis Media’s Winstone and WebBench. They founded and led eTesting Labs, and after the acquisition of that company by Lionbridge Technologies were the head and CTO of VeriTest.

Principled Technologies is a registered trademark of Principled Technologies, Inc. All other product names are the trademarks of their respective owners. Disclaimer of Warranties; Limitation of Liability: PRINCIPLED TECHNOLOGIES, INC. HAS MADE REASONABLE EFFORTS TO ENSURE THE ACCURACY AND VALIDITY OF ITS TESTING, HOWEVER, PRINCIPLED TECHNOLOGIES, INC. SPECIFICALLY DISCLAIMS ANY WARRANTY, EXPRESSED OR IMPLIED, RELATING TO THE TEST RESULTS AND ANALYSIS, THEIR ACCURACY, COMPLETENESS OR QUALITY, INCLUDING ANY IMPLIED WARRANTY OF FITNESS FOR ANY PARTICULAR PURPOSE. ALL PERSONS OR ENTITIES RELYING ON THE RESULTS OF ANY TESTING DO SO AT THEIR OWN RISK, AND AGREE THAT PRINCIPLED TECHNOLOGIES, INC., ITS EMPLOYEES AND ITS SUBCONTRACTORS SHALL HAVE NO LIABILITY WHATSOEVER FROM ANY CLAIM OF LOSS OR DAMAGE ON ACCOUNT OF ANY ALLEGED ERROR OR DEFECT IN ANY TESTING PROCEDURE OR RESULT. IN NO EVENT SHALL PRINCIPLED TECHNOLOGIES, INC. BE LIABLE FOR INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES IN CONNECTION WITH ITS TESTING, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. IN NO EVENT SHALL PRINCIPLED TECHNOLOGIES, INC.’S LIABILITY, INCLUDING FOR DIRECT DAMAGES, EXCEED THE AMOUNTS PAID IN CONNECTION WITH PRINCIPLED TECHNOLOGIES, INC.’S TESTING. CUSTOMER’S SOLE AND EXCLUSIVE REMEDIES ARE AS SET FORTH HEREIN.

Cost and performance comparison for OpenStack compute and storage infrastructure

A Principled Technologies test report 19