Workloads on VMware Cloud Flex Storage

Business Case

VMware vSAN™ has been the default storage in VMware Cloud™ on AWS. The scale-out architecture of VMware vSAN enables powerful non-disruptive scale-up or scale-out capabilities. You can expand capacity and performance non-disruptively by adding hosts to a cluster (scale-out). As application workloads grow organically, some storage capacity-heavy workloads may be challenging to optimize using vSAN alone. In these situations, VMware Cloud Flex Storage™ can augment the additional storage requirement for these workloads. VMware Cloud Flex Storage offers a new approach to help better align your cloud resources with your applications and data needs. With this scalable, elastic, and natively integrated storage service for VMware Cloud on AWS, fully managed by VMware, you can flexibly scale storage and compute independently and pay only for the resources you use.

In this paper we present the result of deployment and validation of popular application workloads like Splunk, Video surveillance, RabbitMQ, Cassandra, Oracle Database using VMware Cloud Flex Storage or a combination of vSAN and VMware Cloud Flex Storage.

Audience

This solution is intended for IT administrators, architect’s virtualization, and storage architects involved in planning, architecting, and administering a virtualized workload on VMware Cloud on AWS.

VMware Cloud on AWS Overview

Solution technology components are listed below:

· VMware Cloud on AWS

· VMware Cloud Flex Storage

VMware Cloud on AWS

VMware Cloud on AWS brings VMware’s enterprise class Software-Defined Data Center software to the AWS Cloud and enables customers to run production applications across VMware vSphere®-based private, public and hybrid cloud environments, with optimized access to AWS services. Jointly engineered by VMware and AWS, this on-demand service enables IT teams to seamlessly extend, migrate and manage their cloud-based resources with familiar VMware tools –minimizes the hassles of learning new skills or utilizing new tools. VMware Cloud on AWS integrates VMware’s flagship compute, storage, and network virtualization products (VMware vSphere, VMware vSAN and VMware NSX®) along with VMware vCenter® management as well as robust disaster protection, and optimizes it to run on dedicated, elastic, Amazon EC2 bare-metal infrastructure that is fully integrated as part of the AWS Cloud. This service is delivered and supported by VMware and its partner community. This service is sold by VMware, AWS, and their respective partner networks. With the same architecture and operational experience on-premises and in the cloud, IT teams can now quickly derive instant business value from use of the AWS and VMware hybrid cloud experience.

Figure 1. VMware Cloud on AWS SDDC (Software Defined Datacenter) with VMware Cloud Flex Storage

VMware Cloud Flex Storage

Overview

VMware Cloud Flex Storage is a scalable, elastic, and natively integrated storage service for VMware Cloud on AWS that is fully managed by VMware and delivered with predictable cloud economics. Customers can scale storage without adding hosts, simplify operations with a solution that is easy to purchase, use, and manage, and benefit from a straightforward pay-as-you-go consumption model. Figure 1 shows VMware Cloud on AWS SDDC with both vSAN datastore and VMware Cloud Flex datastore.

Architecture

VMware Cloud Flex Storage is built on a mature and enterprise-class filesystem that has been developed and production-hardened over many years, dating back to Datrium’s Disaggregated Hyperconverged Infrastructure (DHCI) storage product, which VMware acquired in July 2020. It is the same filesystem that has been backing the VMware Cloud Disaster Recovery service. The filesystem has a two-tier design that allows for independent scaling of storage performance and capacity, using a Log-Structure Filesystem (LFS) design. You can read more about the filesystem architecture in Sazzala Reddy’s (Chief Technologist and a founder of Datrium) blog here. The combination of LFS with a 2-tier design, along with efficient snapshots and immutability, makes this a multi-purpose filesystem that unlocks many use cases, such as backup, disaster recovery, ransomware protection, and recovery. With VMware Cloud Flex Storage, we are extending this proven technology to primary storage and making it available in the public cloud, where it delivers exceptional storage performance, scalability, and cost efficiency for traditional and modern workloads. A goal of this solution is to strike a balance between the performance of NVMe AWS hardware, and the durability and economics of the object storage. The write IO path has all incoming writes mirrored to redundant NVMe devices. Generous allocations of read cache in addition, help smooth out the higher latency response of S3 storage for cache friendly workloads. Do note that outliers of colder data from S3 that are not cached will respond in the tens of milliseconds. For workloads requiring more consistent reads on cold data such as transactional database workloads, vSAN is still recommended. Figure 2 shows the 2-tier architecture of VMware Cloud Flex datastore.

Figure 2. VMware Cloud Flex Storage Architecture

VMware Cloud on AWS Configuration

For the workload validation, we used four-host VMware Cloud on AWS SDDC. A VMware vSphere® Cluster is provisioned using these four hosts. Each host in the cluster had the following configuration as shown in Table 1.

Table 1. VMware Cloud on AWS ESXi Host Configuration

Number of Host	4
SDDC Host Type	Amazon EC2 i3.metal
CPU Type	Intel(R) Xeon(R) CPU E5-2686 v4
CPU Cores	36 Cores @ 2.30GHz
Memory per Host	512 GB
vSAN Datastore (Capacity)	44.47 TB
VMware Cloud Flex Storage Datastore (Capacity)	200 TB
Network	25Gbps

SDDC Hosts

There are several types of hosts available in VMware Cloud on AWS SDDC: i3 (Intel Broadwell), i3en (Intel Cascade Lake) and i4i (Intel Ice Lake). We would choose the appropriate one depending on the type of workloads. In this solution validation, i3 is used. For more details on VMware Cloud on AWS host types, see here.

vSAN Datastore

The default storage option available in VMware Cloud on AWS is vSAN. VMware Cloud on AWS provides two vSAN “logical” datastores in each SDDC cluster: “WorkloadDatastore” managed by the customer and “vsanDatastore” managed by VMware. These datastores are logical entities that share a common capacity pool. WorkloadDatastore provides storage for the application VMs. As we advance, vSAN datastore refers to the WorkloadDatastore. vSAN datastore storage capacity scales with the number of nodes in the SDDC. Data redundancy requirements are defined per VMware Cloud on AWS SLAs and are enforced by using Automated Storage Policy management. All RAID configurations consume data to support redundancy. You can calculate the projected capacity needs for your workloads based on the host instance type, cluster configuration, and failure tolerance settings using the VMware Cloud on AWS Sizer and TCO tool found here. vSAN Storage policy defines storage parameters for virtual machine objects. In this validation, the disk provisioned from the vSAN datastore used the default cluster policy. The default vSAN storage policy for this cluster is shown in Figure 3 and it uses RAID 1 mirror protection.

Figure 3. vSAN Storage Policy Availability Settings—Mirror

VMware Cloud Flex Storage Datastore

VMware Cloud Flex Storage provides NFS datastores for workloads that do not require vSAN performance for mission-critical or consistent low-latency storage requirements. It can be purchased as a term subscription or pay as you go. Since VMware Cloud Flex Storage is found on the Scale-Out Cloud Filesystem (SCFS), it has the following built-in data services: encryption, resiliency, storage efficiency, and data integrity features that are always on by default. The virtual machine objects using this storage uses the VMware Cloud Flex Storage policy named as vmc-fs. As shown in Figure 4, this policy has no other user-editable parameters as all the data services are fixed and built-in.

Figure 4. VMware Cloud Flex Storage Policy

Target Application Workloads Validation on VMware Cloud Flex Storage

Multiple options are available and discussed here to validate that a workload is suitable to be deployed on VMware Cloud Flex Storage. One of them is to identify write heavy, low IO, and storage capacity-hungry workloads, which may be a suitable candidate for moving to VMware Cloud Flex Storage. Despite the workload, all the write IO is going to be cached. The primary concern of response latency is from read-heavy workloads that exceed the cache working set size. Large (multi-TB working set), random read-heavy applications needing low latency should be prioritized to remain on the vSAN datastore. Based on this background, some of the following popular workloads are validated on VMware Cloud Flex Storage.

Splunk cold storage
Video Surveillance
RabbitMQ
Cassandra (IOT application and tabular application)
Oracle Database (archive log, backup, and non-production)

The above is not an exhaustive list of applications that can be deployed on VMware Cloud Flex Storage. Many other similar or custom workloads might fit the criteria for deployment. For those workloads, we need to perform the IO assessment and then make the decision.

Splunk Enterprise

Overview

The Splunk platform uses machine data—the digital exhaust created by the systems, technologies, and infrastructure powering modern businesses—to address big data, IT operations, security, and analytics use cases. The insights gained from machine data can support any use cases across an organization and can be enriched with data from other sources. Splunk software helps to create the hidden value from ever-growing machine data. As data volume increases and decisions are being made based on this data, retention periods are getting longer. As a result, organizations are looking for enterprise-grade storage with high performance and cost-efficient and scalable storage.

Solution Architecture and Validation

Splunk’s deployment model differs based on the size of the deployment. Some of the standard deployment models, as per Splunk, are:

Departmental: A single instance that combines indexing and search management functions.
Small enterprise: One search head with two or three indexers.
Medium enterprise: A small search head cluster with several indexers.
Large enterprise: A large search head cluster, with large numbers of indexers.

Splunk Traditional Architecture

In traditional Splunk architecture, depending on the data ingestion rate and retention period, the storage provisioned to the Splunk instance can be one of the following two models.

vSAN storage (hot, warmpath, and coldpath)
vSAN storage (hot and warmpath with high performance) + VMware Cloud Flex Storage (coldpath with large capacity)

For departmental, small enterprise, and some medium enterprise deployments, a vSAN datastore without additional external storage may be sufficient. In this deployment, the retention period may be small, so less cold storage is consumed.

For large enterprise deployments requiring extended data retention, the second option of vSAN storage for hot and warm buckets and VMware Cloud Flex Storage for cold buckets is efficient and scalable. vSphere VM is flexible to consume disks from both vSAN and VMware Cloud Flex Storage. Figure 5 shows the traditional Splunk Enterprise solution on VMware Cloud on AWS and VMware Cloud Flex Storage.

Figure 5. Traditional Splunk Enterprise Environment on VMware Cloud on AWS

Splunk VM Configuration

On vSphere Cluster, four VMs (splunk1 to 4) were deployed, one on each host, each Splunk VM with 14 vCPUs and 128GB memory. The Ubuntu operating system was installed. Table 2 shows the Splunk VM resource allocation: one OS disk and eight data disks were provisioned to each VM. Among the eight data disks, four (sd[b-e]) were provisioned on the vSAN datastore for Splunk hot and warm buckets. The remaining four data disks (sd[f-i] were provisioned on the VMware Cloud Flex Storage datastore for cold buckets.

Figure 6 shows one of the Splunk VMs where disks on both datastores were provisioned. The high-performance hot disks were provisioned on the vSAN datastore, and the capacity-intensive cold disks were provisioned on the VMware Cloud Flex Storage datastore.

Table 2. Splunk VM Configuration

VM Resources	Splunk Master Search (splunk1)	Splunk Indexers 3 Numbers ( splunk2 to splunk4)
vCPU	14	14
Memory (GB)	128	128
Virtual Disk (vSAN datastore )	1 x 100 GB (OS) 4 x 150 GB (hot/warm data)	1 x 100 GB (OS) 4 x 150 GB (hot/warm data)
Virtual Disk (VMware Cloud Flex datastore)	4 x 500 GB (cold data)	4 x 500 GB (cold data)

Figure 6. Splunk Indexer VM Showing Disk Presented from VMware Cloud Flex and vSAN Datastore

The data disks were spread evenly over four PVSCSI controllers. Linux logical volume manager (LVM) combined the four VMDKs on each Splunk VMs and was formatted using the xfs filesystem. The resulting data disks were used to create the Splunk mount point (/opt/splunk-hot) for hot buckets and (opt/splunk-cold) for cold buckets. We used the following commands to create the logical volume and filesystem for hot and warm buckets: after the filesystem is created, it is mounted.

pvcreate /dev/sdb /dev/sdc /dev/sdd /dev/sde

vgcreate vgsplunk-hot /dev/sdb /dev/sdc /dev/sdd /dev/sde

lvcreate -l +100%free -i 4 -n lvsplunk-hot vgsplunk-hot

mkfs.xfs /dev/vgsplunk-hot/lvsplunk-hot

We used the following commands to create the logical volume and filesystem for cold buckets.

pvcreate /dev/sdf /dev/sdg /dev/sdh /dev/sdi

vgcreate vgsplunk-cold /dev/sdf /dev/sdg /dev/sdh /dev/sdi

lvcreate -l +100%free -i 4 -n lvsplunk-cold vgsplunk-cold

mkfs.xfs /dev/vgsplunk-cold/lvsplunk-cold

Splunk Roles and Application Configuration

Table 2 shows the key Splunk roles performed by the VMs.

Virtual machine splunk1 performs the search head role, and the remaining 3 VMs (splunk[2-4]) perform the indexer role.

Splunk is configured in distributed deployment mode. The search head distributes search requests to other instances called search peers or indexers in this method. Indexers perform the actual search as well as the data indexing finally, the search head merges the results back to the user.

Splunk Indexer clustering was enabled to provide high availability at the indexer level, while data indexing the peer node replicates data from other peer nodes governed by the Splunk replication factor. The Splunk Replicator factor in an indexer cluster is the number of data copies the cluster maintains. During this configuration, you also designate a search factor. The search factor determines the number of searchable copies of data the indexer cluster maintains, and it must be less than or equal to the replication factor. The Splunk replication and search factor is configured as two, respectively.

Splunk Storage Tiering Using a Mix of vSAN and VMware Cloud Flex Datastore

Hot and warm volume stores the recently ingested data and are frequently searched. Historical data is rolled over from warm to cold buckets, rolling from one tier to another is governed by the Splunk configuration file indexes.conf. Hot and warm data buckets of the Splunk enterprise are stored on a high-performance vSAN datastore, while cold data buckets and, if any frozen, are moved to capacity-intensive VMware Cloud Flex datastore. The hot/warm storage is sized appropriately, so most of the time-sensitive search results are delivered within SLAs (Service-Level Agreements). As data ages, the buckets are moved to cold, freeing up the expensive hot/warm storage.

Best practices for deploying storage for hot and warm buckets on vSAN, see Splunk on VMware vSAN.

Data Ingestion and Search Operation

To validate this log data was ingested in the Splunk cluster, which placed the data initially on the high-performance vSAN datastore. Subsequently, these buckets were rolled over to VMware Cloud Flex Storage. Search query was set to search data from aged data (VMware Cloud Flex datastore). The search results displayed events from cold bucket.

Splunk has a stringent requirement for hot and warm storage and does not recommend NFS based storage. However, for cold NFS storage is acceptable, and the latency requirements are not stringent like hot and warm storage. VMware Cloud Flex Storage for Splunk cold storage is successfully validated by performing the bucket rolling activity and subsequent searches from the aged data (cold buckets).

Video Surveillance Systems

Overview

Enterprise Grade Video Surveillance Systems are widely used across industry verticals and government law enforcement agencies. These systems have many solution components like cameras, Video Management System (VMS) Software, networking, compute, and storage. Storage is one of the critical components of this solution. The storage needs to be performant to handle the increased number of video streams and video reviewing while simultaneously being scalable to provide the required capacity to store these recordings. With the emergence of higher resolution cameras, increased cameras to monitor larger geographical areas, and increased retention requirements, massive and cost-efficient storage becomes a critical solution component.

Solution Architecture and Validation

vSphere has been used as a virtualization platform for Video Surveillance VMs widely. vSphere consolidates the number of VMs required at a particular site. In VMware Cloud on AWS, while we can use vSAN datastore as storage for Video Surveillance, to be cost efficient and to scale storage independent of compute, VMware Cloud Flex datastore is an excellent choice. Additionally, VMware Cloud Flex Storage can be a good candidate for this workload as the workload is primarily write with occasional reads generated during the video review for any investigation purpose.

Recording Server VMs are deployed on VMware Cloud on AWS and using video simulation software video surveillance like workload was generated to validate this solution.

The test environment comprised 16 VMs distributed equally among the four VMware Cloud on AWS hosts. Each VM was allocated eight disks with 100GB to record the video streams. All the virtual disk for this solution is provisioned using the VMware Cloud Flex datastore. The eight disks were spread equally across all the four PVSCSI Controllers.

Table 3. Video Recording Virtual Machine Configuration

Item Description	Quantity
Number of Video Recording Virtual Machine	16
vCPU per VM	8
Memory per VM	8 GB
Disk Per VM (Allocated from VMware Cloud Flex datastore)	8 x 100GB (For Workload / Data) 1 x 100GB (For Operating System App)

The simulator software generated multiple video streams equally spread across all 16 VMs. Each video stream drives an IO throughput of 4.5 MBps with ~90% write and ~10% read. The test started with 64 streams and it was gradually increased in increments of 32. The maximum number of video streams we achieved with this configuration was 160, with a total IO throughput of 718 MBps.

Any performance data results from the combination of hardware configuration, software configuration, test methodology, test tool, and workload profile used in the testing. This validation used a typical video surveillance-like IO workload, and VMware Cloud Flex Storage was able to deliver consistent storage performance for video streams. Depending on the customer use case, there may be a requirement for frequent security investigation, thereby increasing the read IO throughput requirement, for that deployment, recommendation is to analyze the workload, test, and then deploy such workload in production.

RabbitMQ

Overview

RabbitMQ is one of the most popular open-source message brokers. RabbitMQ is used worldwide by small startups and large enterprises. RabbitMQ is lightweight and easy to deploy on-premises and in the cloud. It supports multiple messaging protocols. RabbitMQ can be deployed in distributed and federated configurations to meet high-scale and high-availability requirements.

Furthermore, with VMware RabbitMQ, you can get all the messaging and streaming capabilities of RabbitMQ in an enterprise-grade supported distribution, to support your high-scale and high-availability requirements via rock-solid architectures.

Solution Architecture and Validation

We deployed the VMware RabbitMQ test environment using Tanzu Kubernetes Grid on the four VMware Cloud on AWS hosts.

Tanzu Kubernetes Grid Cluster node configuration is shown in Table 4. These tests were run using a 12-node RabbitMQ cluster with VMware Cloud Flex Storage. RabbitMQ perf-test load tool was used for this validation.

Table 4. Tanzu Kubernetes Grid Cluster Nodes Configuration

VM Role	vCPU	Memory (GB)	Storage (GB)	VM Count
Tanzu Kubernetes Grid cluster (workload cluster) – Control Plane	4	16	16	3
Tanzu Kubernetes Grid cluster (workload cluster) – Worker node VM	16	128	3,000	12

RabbitMQ cluster was deployed using Kubernetes operator with the following resources and configuration.

apiVersion: rabbitmq.com/v1beta1
kind: RabbitmqCluster
metadata:
  name: production
  namespace: rabbitmq-system
spec:
  replicas: 11 

resources:
    requests:
      cpu: 8
      memory: 16Gi
    limits:
      cpu: 8
      memory: 16Gi
  service:
    type: LoadBalancer 
  rabbitmq:
    additionalConfig: |
      cluster_partition_handling = pause_minority
      vm_memory_high_watermark_paging_ratio = 0.99
      disk_free_limit.relative = 1.0
      collect_statistics_interval = 10000
    advancedConfig: |
      [
          {rabbit, [
              {credit_flow_default_credit, {0,0}}
          ]}
      ].
  persistence:
    storageClassName: vmc-fs     # VMware Cloud Flex Storage policy(vmc-fs) is assigned to this namespace
    storage: “3000Gi”

We performed the following tests to validate the solution. Some nodes on the environment:

Scaling out the number of instances allows VMDKs to be distributed through the cluster. In our testing, it can achieve more stable throughput and consistent latency than scale up with 3 large VMs.
The credit flow was disabled because a single fast publisher will be throttled.

Test 1:

Description: One queue, fast publishers, and consumers to measure its throughput and latency.

Parameters: In this test, we varied the message size of 10, 100, 1,000, and 5,000 bytes using 1 queue with 2 publishers and 2 consumers.

Table 5. RabbitMQ One Queue Test Throughput Results

Message Size (byte)	Avg Published Throughput (msg/s)
10	47.8K
100	38.4K
1,000	18.5K
5,000	10.8K

In the chart above, RabbitMQ can achieve at 47.8K message per second when tested with lightweight message size of 10 bytes. It also performs at 18.5K msg/s when tested with 1KB message size.

Test 2:

Description: One queue, fix throughput to measure latency.

Parameters: In this test, we varied the message size of 10, 100, 1,000, and 5,000 bytes at the fixed throughput using 1 queue with 2 publishers and 2 consumers.

Table 6. RabbitMQ One Queue Latency Results (Fixed Throughput)

Message Size (byte)	Min Latency (ms)	Avg Latency (ms)	Max Latency (ms)
10	7.6	12	19.4
100	8.07	12.9	20
1,000	9.1	13.5	23.9
5,000	274	-	-

RabbitMQ can offer a low and consistent latency at a fixed target throughput of 10000 msg/s.

Test 3:

Description: hundreds of producers and consumers that exchange messages at a low and mostly constant rate.

Parameters: In this test, we varied the message size of 10, 100, 1,000, 5,000 bytes and 10KB with publishing 10 messages per second at 500 producers and 500 consumers.

Table 7. RabbitMQ IoT Use Case Test Results

Message Size (byte)	Min Latency (ms)	Avg Latency (ms)	Max Latency (ms)
10	5.4	9.6	19.9
100	6.2	9.4	22
1,000	6.8	9.7	23.2
5,000	7.18	12.5	32.5
10,000	8.5	21	65

Test case 3 simulates IoT workload invovles a large number of clients that exchange messages at a low and mostly constant rate. With IoT workload, publishers don’t publish many messages per second, but rather a message every fixed period of time. From the above results, multiple queues can sustain the target 5,000 msg/s throughput at consistent latency.

In conclusion, VMware Cloud Flex Storage is a suitable storage option for RabbitMQ application with high throughput and consistent, low latency. It provides high capacity with more cost-effective.

Cassandra

Overview

Apache Cassandra is a free and open-source, distributed, wide-column NoSQL database management system designed to handle large amounts of data. It is a popular choice for applications that require high availability, scalability, and flexibility.

Solution Architecture and Validation

We deployed the K8ssandra (cloud native Cassandra) environment using Tanzu Kubernetes Grid on the four VMware Cloud on AWS hosts.

Tanzu Kubernetes Grid Cluster node configuration is shown in Table 8. These tests were run using a 3-node Cassandra cluster with VMware Cloud Flex Storage. nosqlbench, DataStax’s sponsored open-source benchmarking suite was used to run the workload testing for this validation.

Table 8. Tanzu Kubernetes Grid Cluster Nodes Configuration

VM Role	vCPU	Memory (GB)	Storage (GB)	VM Count
Tanzu Kubernetes Grid cluster (workload cluster) – Control Plane	4	16	16	3
Tanzu Kubernetes Grid cluster (workload cluster) – Worker node VM	16	128	100	4

Cassandra cluster was deployed using K8ssandra operator with the following YAML file configuration:

serverVersion: "4.0.3"
    softPodAntiAffinity: false
    datacenters:
      - metadata:
          name: dc1
        telemetry:
          prometheus:
            enabled: false
        size: 3
        storageConfig:
          cassandraDataVolumeClaimSpec:
            storageClassName: vmc-fs  #VMware Cloud Flex Storage policy(vmc-fs) is assigned to this namespace.
            accessModes:
              - ReadWriteOnce
            resources:
              requests:
                storage: 1000Gi
        config:
          jvmOptions:
            heapSize: 31G
            g1gc:
               enabled: true
               setUpdatingPauseTimePercent: 5
               maxGcPauseMillis: 300
          resources:
            requests:
              memory: 59Gi
              cpu: 7500m
            limits:
              memory: 60Gi
        stargate:
          size: 1
          heapSize: 20G

Workload Test Scenario 1:

The cql-tabular2 workload is a NoSQLBench built-in workload that is designed to simulate the load generated by a tabular application. The workload creates a table called baselines.tabular2 with a column for the integer key, a column for the string value, and a column for the double value. The workload then generates random data points and inserts them into the table. The data points are evenly distributed across the different rows.

We used the cql-tabular2 profile that allowed us to stress the disks significantly. We used a replication factor of 3 with a 50/50 write/read workload, and this profile performs all statements at consistency level LOCAL_QUORUM.

  - rampup-cycles=1M
        - main-cycles=100M
        - write_ratio=5
        - read_ratio=5
        - async=300

The throughput was mean rate = 24378.36 calls/second. Latencies are:

P50: 2.173451 ms
P99: 8.270167ms
P999: 432.173136ms

Workload Test Scenario 2:

The cql-iot workload is a NoSQLBench built-in workload that is designed to simulate the load generated by an IoT application. The workload creates a table called baselines.iot with a column for the timestamp of the data point, a column for the device ID, and a column for the sensor data. The workload then generates random data points and inserts them into the table. The data points are evenly distributed across the different devices.

The cql-iot workload can be used to benchmark the performance of Cassandra under a load that is representative of an IoT application.

We used the cql-iot profile, replication factor of 3 with a 90/10 write/read workload, and this profile performs all statements at consistency level LOCAL_QUORUM.

cql-iot
        - rampup-cycles=1M
        - main-cycles=100M
        - write_ratio=9
        - read_ratio=1

The throughput was mean rate = 22858.40 calls/second. Latencies are:

P50: 1.949491ms
P99: 6.833561ms
P999: 603.148645ms

Based on the above results, VMware Cloud Flex Storage is a suitable storage option for Cassandra IoT workloads and tabular workloads.

Oracle Database

Overview

Oracle Database is a relational database management system deployed as a single instance or as RAC (Real Application Cluster), ensuring high availability, scalability, and agility for any applications. Oracle Database accommodates all system types, from the data warehouse to update-intensive OLTP (Online Transaction Processing) systems.

Solution Architecture and Validation

Enabling, sustaining, and ensuring the highest possible performance along with continued application availability is a major goal for all mission-critical Oracle applications to meet the demanding business SLAs, all the way from on-premises to VMware Hybrid Clouds.

Some of the Oracle Database use cases where VMware Cloud Flex Storage can be used are:

Oracle Database archive logs
Oracle Database backups
Oracle Database non-production workloads

Destination for Archive Log

Oracle Database enables you save filled groups of redo log files to one or more offline destinations, known collectively as the archived redo log.

The process of turning redo log files into archived redo log files is called archiving. This process is only possible if the database is running in ARCHIVELOG mode

When the database is running in ARCHIVELOG mode, the log writer process (LGWR) cannot reuse and hence overwrite a redo log group until it has been archived. The background process ARCn automates archiving operations when automatic archiving is enabled. The database starts multiple archiver processes as needed to ensure that the archiving of filled redo logs does not fall behind. Check out more information about Oracle Archivelog here.

The blog Providing Performance and Storage savings using VMware Cloud Flex Storage for Oracle Archive logs evaluates the feasibility and showcases the advantages of using VMware Cloud Flex Storage for business-critical Oracle workloads on VMware Cloud on AWS as a viable and comparable Storage option for Oracle Archive Log files destination.

Destination for Backup

The purpose of a backup and recovery strategy is to protect the database against data loss and reconstruct the database after data loss.

Typically, backup administration tasks include the following:

Planning and testing responses to different types of failures
Configuring the database environment for backup and recovery
Setting up a backup schedule
Monitoring the backup and recovery environment
Troubleshooting backup problems
Recovering from data loss if the need arises

Check out more information about Oracle backup here.

The blog Providing Storage savings and Comparable performance using VMware Cloud Flex Storage for Oracle Backups evaluates VMware Cloud Flex Storage as a viable and comparable storage option for Oracle backups destination.

Destination for Oracle Non-Production Workloads

Non-production workloads such as Development, Test, QA, Staging, Functional, Pre-Production are equally important as the Production workloads, as they are key entities and instrumental to any Production workload success.

Ensuring that Pre-Production databases are comparable in performance with the Production databases is key in ensuring that any performance related issues are identified well ahead in the process before they make it to the Production environment. In addition, ensuring that there is adequate testing and validation ensures due diligence is done with any software release.

This blog Providing Storage savings and Comparable performance using VMware Cloud Flex Storage for Oracle Non Production workloads is an exercise to evaluate VMware Cloud Flex Storage as a viable and comparable Storage option for Oracle non-production workloads.

Conclusion

VMware Cloud Flex Storage is a scalable, elastic and natively integrated storage service for VMware Cloud on AWS, fully managed by VMware, you have the flexibility to scale storage and compute independently of each other and pay only for the resources you use. VMware Cloud Flex Storage offers a simple pay-per-utilized GiB consumption model. You can buy a subscription or pay on demand. With this model, you can scale storage at a low cost without adding hosts, which reduces your overall total cost of ownership (TCO). These characteristics of VMware Cloud Flex Storage combined with the established vSAN storage in VMware Cloud on AWS help deploy various workloads cost effectively and thus improve operational flexibility.

Reference

· Selecting Workloads for VMware Cloud Flex Storage

· Traditional Splunk Reference architecture on VMware vSAN

· VMware RabbitMQ Solution on VMware vSAN

· Running K8ssandra on VMware Tanzu Kubernetes Grid with VMware Cloud on AWS with vSA

About the Author

Palani Murugan, Senior Technical Marketing Architect in VMware Cloud Infrastructure Business Group authored this paper with contributions from the following members:

Sudhir Balasubramanian, Senior Staff Solution Architect in VMware Cloud Infrastructure Business Group – Oracle Database Solution
Yimeng Liu, Senior Technical Marketing Manager in VMware Cloud Infrastructure Business Group – RabbitMQ Solution
Ting Yin, Senior Technical Marketing Architect in VMware Cloud Infrastructure Business Group – Cassandra Solution

Also, the following reviewers contributed to the reference architecture contents:

Michael McLaughlin, Senior Technical Marketing Architect at VMware
Oleg Ulyanov, Staff Cloud Solutions Architect and Group Manager at VMware
Brett Foy, Staff Solution Architect at VMware
Chen Wei, Director of the Workload Technical Marketing Team at VMware
Catherine Xu, Senior Manager of the Workload Technical Marketing team at VMware

Filter Tags

Storage vSphere Document Reference Architecture Deploy