11:00 AM -- Thin provisioning of storage has evolved into one of the key features that new storage systems must offer. It allows you to create array volumes and assign them to applications at the projected capacity the application needs. But, as I discussed in my article on Thin Provisioning Basics, actual capacity is only allocated when new data is created in the system. This can mean a dramatic cost savings in storage acquisition costs.
As is true with most technologies, there are some things to keep in mind when you deploy thin provisioning -- and they dont necessarily include the knee-jerk concern about over-provisioning yourself out of actual disk space. Between the reporting that is available and responsible administration practices, the capacity emergency scenario rarely, if ever, raises its head. Instead there are other things that storage administrators should think about -- including expectations for how thin provisioning works in conjunction with data lifecycle practices.
One such area is block space reclamation, or rather, the lack thereof. The idea behind block space reclamation is to return blocks of storage that are no longer occupied by data so that they can be used again (reclaimed) and assigned to other volumes.
Let's say you create a 500-GB thin volume and things start off as predicted using 10 percent of that capacity, or 50 GB. Good! That's what thin is for -- it saved you 450 GBs or so right off the bat. Way to go.
Over several years, let's assume the volume grows and the used capacity approaches the expected 500 GB. As part of normal lifecycle processes you archive 100 GB of data that is more than three years old to a disk archive or even tape. Good for you! The volume that was thin when it started is now the size it would have been if you had created a fat volume originally. The capacity purchases you made over the years cost less per GB than if you hard-provisioned all the capacity up front. Of course, if the capacity only grows to 350 GB instead of 500 GB, then you would never have had to spend any money on 150 GB of unnecessary capacity. Any way you slice it, it's an excellent lifecycle story.
To realize the benefits of cloud-native software, an application must actually be cloud-native—designed to run in the cloud, interacting with disaggregated cloud services, fully manageable as code—to deliver the expected benefits.
By combining resources and expertise, the AI-Enabled ICT Workforce Consortium will offer a blueprint for how industries can adapt to an AI-dominated future.
IT leaders should heed the guidance of cybersecurity insurance providers who think businesses should prioritize security education, incident preparedness, regular internal audits, and ongoing vulnerability scanning and patching.
