VMstore T7000 Series Icon

VMstore T7000 Series

On-prem VMstore platform.

Tintri Cloud Platform

Managed infrastructure powered by Tintri.

Tintri Cloud Engine

Container-driven VMstore platform.

All Die Hard Tintri News & Events Perspectives Products & Solutions Technical

Do More with Less: Lessons Every IT Team Can Learn from DevOps

  • KEY TAKEAWAYS
  • VMstore makes it easy to automate common IT pain points. Copy offload accelerates VM provisioning.
  • Self-service restore puts control in users’ hands and save hours of help desk time.
  • Accelerated SQL reporting ensures that regular reports don’t interfere with interactive users.

IT teams can adopt DevOps practices and principles to streamline IT operations at scale.

If you don’t have a DR site, you can accomplish the same thing simply by cloning each production database and running reports against the clone. VMstore auto-tuned QoS ensures that reports can run against a database clone on the same storage system without interfering with production workloads.

If your team or your company isn’t involved in application development and test, you may feel like the DevOps blogs that Tintri has been running over the last few months don’t apply to you. But the truth is, there’s a lot that every IT team can learn and apply from DevOps practices. This blog explains how to adapt the copy offload, self-service, and copy data management practices that are mainstays of DevOps to a broader set of IT uses cases.

DevOps is all about doing more with less, using fewer resources and getting more done in a shorter amount of time. Those lessons are applicable to anyone running IT at scale. Puppet, a leading provider of configuration management software for DevOps and enterprise IT, has noted this same trend over the past several years and expanded on the theme in its 2017 State of DevOps Report. Puppet notes:

It doesn’t matter if your apps are greenfield, brownfield or legacy—as long as they are architected with testability and deployability in mind, high performance is achievable. We were surprised to find that the type of system—whether it was a system of engagement or a system of record, packaged or custom, legacy or greenfield—is not significant.

The following sections describe how you can apply DevOps principles and the capabilities of VMstore all-flash storage to several traditional IT use cases in more detail:

  • Rapid provisioning and deployment with copy offload
  • Self-service for VDI environments
  • Reporting from SQL Databases

If you look at our previous blog on automating workflows for DevOps, we provide a complete list of the APIs and tools that VMstore supports for automation of a full range of IT workflows.

Accelerate Provisioning and Deployment with Copy Offload

Any time you’re provisioning a set of virtual machines (VMs)—developer VMs, dev/test VMs, virtual desktops, or application instances for an enterprise application—it can take a long time to accomplish. For instance, if it takes two hours to provision a SQL VM from a template, and you have to do 10 of them, that’s 20 hours total. Maybe you can provision multiple VMs in parallel, but that still takes a long time, puts extra load on the system, and whoever you’re provisioning the VMs for has to wait. When you start talking about hundreds or thousands of VMs, provisioning time using traditional methods can extend to weeks or months.

VMstore all-flash storage uses copy offload to simplify any type of provisioning process, dropping deployment time from hours to seconds—using the same tools you normally use. You don’t have to redesign your workflow to take advantage of copy offload. For example, one company shrunk its QA cycle requiring thousands of VMs from 5 hours to just 15 minutes—20x faster.

In VMware environments, just add the VMstore VAAI plugin to each host to take advantage of copy offload. If you’re using Microsoft Hyper-V and SCVMM, you don’t have to do anything at all. You just point your virtual hosts at VMstore storage and live happily ever after.

Self-Service Restore for VDI at Scale

DevOps teams often put tools directly in the hands of users to enable self-help. As a VDI environment grows to thousands—or tens of thousands—of seats, the ability to provide self-service becomes critical. In the traditional file restore workflow, when a VDI user loses a file, the user calls the help desk, the help desk calls the backup team, and the backup team does whatever is needed to restore the missing file. Help desks spend a lot of time just handling restore requests. It’s a completely manual process that eats up multiple people’s time.

With a small amount of automation and either ChatOps or the desktop portal you may already have for your help desk, it’s possible to put the necessary functionality for self-service restore in the hands of the user—without giving anyone access to anything they can mess up.

VMstore space-efficient snapshots make it possible to create recovery points every hour or at even shorter intervals if desired. Restore is facilitated by mounting the appropriate snapshot of the affected user’s VM to the original VM as a temporary disk. Once that occurs, the user can retrieve the file or files needed from the snapshot.

With VM and container-granular operations, VMstore makes it simple to script the process. To see how to do it in PowerShell, see our previous blog post, Automating Workflows in Your CI/CD Pipeline.

Reporting from SQL Databases

A VMstore customer came to us with a problem with their SQL applications, each with a separate database and separate set of users. Because the users are geographically distributed, these databases are in use virtually around the clock. The result is that there is no good time to run daily, weekly, monthly, or quarterly reporting. Reports were quite intensive and could run for up to eight hours. During that period, user applications effectively ground to a halt.

To help them solve the problem, we adopted an approach that is once again very similar to a DevOps environment where you have separate production and test data. Basically, what was needed was a replica of production data that reports could run against.

In this case, the customer already had a complete replica of its production data at a DR site. By spinning up the necessary database VMs at the DR site, they were able to run reports against a snapshot of the production data with no impact on production or the ongoing replication process for DR. This works great for anyone who has a DR site since in many cases the resources are otherwise not very active.

This site is registered on wpml.org as a development site. Switch to a production site key to remove this banner.