LUN provisioning seems straightforward, but the choices you make have significant implications for capacity utilization, performance, and operational complexity. Working with FC-Redirect, I’ve seen both excellent and problematic provisioning strategies. Let me explore the options and trade-offs.

Thick Provisioning

Traditional thick provisioning allocates all storage upfront:

Process: Create a 100 GB LUN, the array immediately allocates 100 GB of physical storage.

Benefits:

  • Guaranteed capacity—you can’t run out
  • Predictable performance—no competition for physical resources
  • Simple management—what you see is what you get
  • Faster writes initially—no allocation overhead

Costs:

  • Wasted capacity—often 40-50% of allocated storage is unused
  • Poor utilization—paying for storage you’re not using
  • Inflexibility—can’t easily reclaim unused space

Thick provisioning is the traditional approach and still makes sense for certain workloads.

Thin Provisioning

Thin provisioning allocates storage on-demand:

Process: Create a 100 GB LUN, the array allocates minimal initial space. As data is written, physical storage is allocated incrementally.

Benefits:

  • Much better capacity utilization—typically 50-70% improvement
  • Flexibility—provision more virtual capacity than physical
  • Deferred spending—buy physical storage as needed
  • Easier provisioning—don’t need to calculate exact needs upfront

Costs:

  • Capacity monitoring required—can run out of physical space
  • Performance variability—allocation overhead on first write to blocks
  • Complexity—virtual vs. physical capacity management
  • Snapshot complications—snapshots consume real space

Thin provisioning has become standard in most environments, but it requires active management.

Thick vs. Thin Performance

Performance characteristics differ:

Thick Provisioning:

  • First write to a block: Fast (just write data)
  • Subsequent writes: Fast
  • Reads: Fast
  • Predictable performance

Thin Provisioning:

  • First write to a block: Slower (allocate, zero, then write)
  • Subsequent writes: Fast
  • Reads: Fast
  • Performance variability during allocation

For performance-critical workloads, thick provisioning may be preferred. For most workloads, thin provisioning’s performance is acceptable.

Capacity Management with Thin Provisioning

Thin provisioning requires vigilant capacity management:

Monitoring

Physical Capacity: Track actual used capacity vs. total capacity.

Allocated Capacity: Track total virtual capacity allocated.

Growth Rate: Monitor how quickly physical capacity is being consumed.

Per-LUN: Track allocation rate per LUN to identify rapidly growing volumes.

Without monitoring, you’ll be surprised when the array runs out of physical capacity.

Thresholds and Alerts

Set up alerts:

Warning Threshold: Alert at 70-75% physical capacity.

Critical Threshold: Alert at 85-90% physical capacity.

Rapid Growth: Alert on unusually fast capacity consumption.

Early warnings allow time to add capacity before running out.

Over-Provisioning Ratio

The ratio of virtual to physical capacity:

Conservative: 1.2:1 (20% over-provisioned)—safe but doesn’t leverage thin provisioning much.

Moderate: 1.5:1 to 2:1—good balance of utilization and safety.

Aggressive: 3:1 or higher—maximizes utilization but risky.

The right ratio depends on your environment and risk tolerance. I recommend starting conservative and increasing based on actual usage patterns.

Zero-on-Demand

Some arrays support zero-on-demand for thin LUNs:

Traditional Thin: Blocks are zeroed when allocated, then data is written. This is two operations.

Zero-on-Demand: Unallocated blocks return zeros on read without physical allocation. Write allocates and writes. More efficient.

Benefits: Reduces allocation overhead, especially for read-before-write workloads.

If your array supports it, zero-on-demand is generally better for thin provisioning.

Reclaiming Space

A challenge with thin provisioning is space reclamation:

The Problem: When you delete files in a file system, the file system marks blocks as free, but the array doesn’t know. The array continues allocating physical space for blocks the file system considers free.

Solutions:

SCSI UNMAP: Command that tells the array which blocks are no longer needed.

VMware VAAI: VMware’s thin provisioning APIs support space reclamation.

Array-Side Detection: Some arrays detect zero blocks and reclaim space automatically.

Manual Reclamation: Some arrays provide tools to reclaim unused space manually.

Without reclamation, thin LUNs only grow, never shrink. Space reclamation is essential for long-term thin provisioning health.

Provisioning for Virtual Machines

VMware introduces additional provisioning choices:

Virtual Disk Formats

Thick Eager Zeroed: All space allocated and zeroed at creation. Best performance, required for certain features (FT), but slow creation.

Thick Lazy Zeroed: All space allocated but zeroed on first write. Faster creation than eager zeroed.

Thin: Space allocated on-demand. Best utilization but performance variability.

Combining Array and VM Thin Provisioning

You can have thin provisioning at both layers:

Array Thin + VM Thin: Maximum flexibility but two layers of capacity management.

Array Thin + VM Thick: VM sees thick provisioning guarantees while array uses thin provisioning.

Array Thick + VM Thin: Array guarantees capacity while VM layer provides flexibility.

Each combination has trade-offs. I generally recommend array thin + VM thick for a good balance.

Automatic Thin Provisioning

Some systems provide automatic thin provisioning:

Automatic Allocation: Allocates storage in chunks as needed.

Automatic Reclamation: Detects and reclaims unused space automatically.

Threshold-Based Expansion: Automatically adds physical capacity when thresholds are reached.

Automation reduces management overhead but requires trust in the algorithms.

Storage Virtualization and Provisioning

Storage virtualization like FC-Redirect adds another layer:

Virtual LUN Provisioning: FC-Redirect can present thin virtual LUNs backed by thick physical LUNs, or vice versa.

Centralized Thin Provisioning: Thin provisioning managed centrally across multiple arrays.

Policy-Based: Automatically provision new LUNs based on policies.

Migration Transparency: Migrate between thick and thin provisioned storage without host impact.

Virtualization provides flexibility in provisioning strategies.

Provisioning Policies

Establish clear provisioning policies:

Production Workloads

Database Transaction Logs: Thick provisioning for predictable performance.

Database Data: Thick or thin depending on performance requirements.

Email: Thin provisioning acceptable for most email systems.

File Servers: Thin provisioning works well.

Non-Production Workloads

Development/Test: Thin provisioning maximizes utilization.

Snapshots/Clones: Thin provisioning essential for efficiency.

Temporary Storage: Thin provisioning appropriate.

Clear policies prevent inconsistent provisioning decisions.

Capacity Forecasting

With thin provisioning, forecasting becomes more complex:

Track Actual Growth: Monitor how quickly physical capacity is consumed.

Extrapolate: Project when you’ll need additional capacity.

Plan Procurement: Order capacity with lead time to arrive before you run out.

Seasonal Patterns: Account for seasonal variations in capacity consumption.

Good forecasting prevents capacity emergencies.

Performance Monitoring

Monitor performance implications of provisioning:

Allocation Latency: Track latency spikes during thin provisioning allocation.

Queue Depth: High queue depths during allocation indicate performance impact.

Controller CPU: Thin provisioning uses more controller CPU.

Cache Effectiveness: Allocation can impact cache hit rates.

If thin provisioning impacts performance unacceptably, consider thick provisioning for affected workloads.

Thin Provisioning and Snapshots

Snapshots complicate thin provisioning:

Copy-on-Write Snapshots: When blocks are modified, original data is copied to snapshot space. This consumes real capacity.

Many Snapshots: Multiple snapshots multiply space consumption.

Old Snapshots: Long-lived snapshots accumulate changes, consuming more space.

Snapshot Space Exhaustion: Running out of snapshot space can impact production.

Reserve adequate capacity for snapshots—typically 20-30% of thin provisioned capacity.

Data Reduction Technologies

Modern arrays combine thin provisioning with data reduction:

Deduplication: Eliminates duplicate blocks. Can dramatically improve effective capacity.

Compression: Compresses data, effectively increasing capacity.

Combination: Thin provisioning + deduplication + compression can provide 3-5x or more effective capacity.

These technologies improve thin provisioning economics but add complexity.

Migration Considerations

Migrating between thick and thin:

Thick to Thin: Relatively straightforward. Create thin LUN, copy data, point to new LUN.

Thin to Thick: May require careful planning if physical capacity is limited.

Testing: Always test migration in non-production first.

Verification: Verify data integrity after migration.

With FC-Redirect, we can migrate between thick and thin provisioned arrays transparently to hosts.

Best Practices

Based on experience, here are best practices:

Start Conservative: Begin with lower over-provisioning ratios and increase as you gain experience.

Monitor Religiously: Set up comprehensive monitoring and alerting.

Establish Policies: Clear policies for which workloads get thick vs. thin.

Plan Capacity: Forecast capacity needs and order hardware with adequate lead time.

Enable Reclamation: Use UNMAP or other reclamation mechanisms.

Reserve for Snapshots: Plan for snapshot capacity consumption.

Test Failover: Test what happens when you run out of capacity.

Document: Document provisioning decisions and rationale.

Common Mistakes

Mistakes I see frequently:

No Monitoring: Provisioning thin without monitoring capacity.

Excessive Over-Provisioning: Provisioning 10:1 virtual to physical. Eventually you run out.

No Reclamation: Thin LUNs grow but never shrink.

Wrong Workloads: Using thin provisioning for performance-critical workloads without testing.

No Snapshot Planning: Not accounting for snapshot space consumption.

Ignoring Alerts: Setting up alerts but not responding to them.

These mistakes lead to capacity exhaustion and performance problems.

Looking Forward

Thin provisioning evolution:

Better Reclamation: More automatic and efficient space reclamation.

Predictive Analytics: Using analytics to predict capacity needs and optimize allocation.

Integration with Cloud: Thin provisioning combined with cloud storage tiering.

Data Reduction: Tighter integration of thin provisioning with deduplication and compression.

Thin provisioning will continue improving and becoming more sophisticated.

Conclusion

LUN provisioning strategy significantly impacts capacity utilization, performance, and operational complexity. Thin provisioning provides much better utilization but requires active management.

The key is understanding the trade-offs:

  • Thick provisioning: Simple, predictable, wasteful
  • Thin provisioning: Efficient, flexible, requires monitoring

Most environments benefit from thin provisioning for most workloads, with thick provisioning reserved for performance-critical applications.

Working with FC-Redirect has shown me how storage virtualization can simplify provisioning management. Centralized thin provisioning policies across heterogeneous arrays reduces complexity while improving utilization.

Choose provisioning strategies thoughtfully, monitor carefully, and adjust based on actual usage patterns. With proper management, thin provisioning dramatically improves capacity utilization without sacrificing reliability or performance.