The acronym “LUN” stands for logical unit number, which is typically used to define a subset of storage space within physical disks. LUNs uniquely identify subsets of data within the disk so the computing devices that use them can execute operations.
LUN setup and capacity limits vary by system, but they always reference an entire RAID set, drive or drives, or partitions. Treated as a single device, LUNs can be retrofitted for use in virtualization, but obscure the unit of abstraction that enterprise cloud uses: virtual applications.
It's important to understand that the term “logical unit number” itself is the actual number that identifies a specific unit—IT professionals and others have come to refer to each of these logical units as LUNs as a way of shortening how this technology is discussed. Logical units can make up the entirety of a physical storage disk, or they can be used to partition off portions of a disk into individually identifiable areas of storage.
LUNs are most commonly known for separating sections of the same disk, but they are also used to format entire hard disk drives (HDDs) and redundant arrays of independent disks sets (RAIDs). A LUN can also manage many different drives depending on its capacity, and in these instances, the LUN is treated as an individual device, which is simply identified by its logical unit number.
Because of the advent of virtualization, greater use of enterprise, hybrid, and private cloud environments, and datacenters swapping HDDs for application-level software on all-flash arrays, the LUN is getting lost in the mix. Rapidly being replaced by more modern technology, such as virtual machines (VMs) and containers, the days of the LUN seem like they may be numbered.
Some enterprise users and other smaller ventures have retrofitted the LUNs within their servers or server farms to “play nice” with cloud computing, but even with these conversions, LUNs simply aren’t built for virtualization, and certainly don’t offer the same agility or scalability that storage built on VMs and containers do. If a storage array uses LUNs, analytics can only be run on the LUN level, versus the application level, which obscures the true performance of your VMs or containers into averages and correlations. What’s more, storage based on LUNs has to be manually provisioned as needed, or as hypothetically needed, whereas storage built on the level of VMs and containers offer automated, per-application provisioning—so your IT staff won’t have to waste valuable time working on tedious manual tasks.
With LUNs (and volumes), storage cannot be architected specifically for cloud-native applications to thrive. Even other conventional all-flash arrays from other providers don’t offer the public cloud-like agility that the application-level Tintri All-Flash Array does. Using our CONNECT architecture, the performance of apps within your enterprise cloud is guaranteed, with drag-and-drop quality of service or automated service group policies. What’s more, Tintri CONNECT architecture coupled with our All-Flash Array allows you to automate migration tasks and use real-time and predictive analytics to easily and conveniently determine when it's time to scale out.
Working with an all-flash array to virtualize your enterprise data is smart. Doing it with Tintri is even smarter—and faster.
Unique control with VM-level actions for infrastructure functions including snapshots, replication and QoS make protection and performance certain in production, and accelerate test and development cycles.