Difference between revisions of "CT storage backends"

From OpenVZ Virtuozzo Containers Wiki
Jump to: navigation, search
(Marked this version for translation)
(Reorganization, deduplication, +LVM +ZFS)
Line 1: Line 1:
 
{{stub}}
 
{{stub}}
 +
<translate>
 +
= Comparison tables =
  
−
<translate>
+
=== Solidity in front of failures and security ===
 
<!--T:1-->
 
<!--T:1-->
 
{| class="wikitable sortable" style="text-align: center;"
 
{| class="wikitable sortable" style="text-align: center;"
 
! Feature
 
! Feature
−
! Ploop
+
! OVZ Ploop
−
! SIMFS
+
! OVZ SimFS (ext4)
 +
! LVM (ext4)
 +
! ZFS (~simfs)
 
|-
 
|-
−
|'''Maturity'''
+
|'''I/O isolation'''
−
|Since 2012
+
|{{Yes|Good}}
−
|Since 2005 (?)
+
|{{No|Bad}}: Some bug could be exploited to escape CT and access HN file system}}: [https://bugs.openvz.org/browse/OVZ-6296 CVE-2015-2925], [http://www.openwall.com/lists/oss-security/2014/06/24/16 CVE-2014-3519]
 +
|{{Yes|Good}}
 +
|{{Yes|Good}}
 
|-
 
|-
−
|'''Maximum disk space'''
+
|'''Reliability'''
−
|Limited:<ref>[[Ploop/Limits]]</ref> ploop v1 - 2 Tb, ploop v2 - 4 Tb
+
|{{No|Low}}: big amount of files produce ext4 corruption so often
−
|Limited by ext4 filesystem
+
|Medium: fsck, power loss and HW Raid without cache can kill whole data
 +
|High: LVM metadata can be corrupted completely
 +
|{{Yes|Excellent}}: no write hole, checksumming and COW
 
|-
 
|-
−
|'''Disk space overhead'''
+
|'''Risk to be using filesystem over filesystem'''
−
|{{Yes}}, up to 20% for allocated ext4 metadata
+
|{{No|Yes}}
−
|{{No}}
+
|{{Yes|No}}
 +
|{{Yes|No}}
 +
|?
 
|-
 
|-
−
|'''Speed'''
+
|'''Effect of HN filesystem corruption at /vz'''
−
|Fast
+
|{{Yes|No effect}}
−
|Fast only with small amount of containers per node
+
|{{No|Same FS}}
 +
|?
 +
|?
 
|-
 
|-
−
|'''I/O isolation'''
+
|'''Maturity in O/VZ'''
−
|Good
+
|{{No|Since 2012}}
−
|Bad, "no inodes" issues (when file system journal is bottleneck)
+
|{{Yes|Since ~2005}}
 +
|{{Yes|Since 1998}}
 +
|{{No|Since 2014}}
 
|-
 
|-
−
|'''Need for run external tools for compaction VE images'''
+
|'''Incremental backup support on filesystem level'''
−
|{{Yes}}, you should vzctl compact every few days for saving your disk space
+
|{{Yes}}, through snapshots
 +
|{{No}}
 
|{{No}}
 
|{{No}}
 +
|{{Yes}}
 +
|-
 +
|}
 +
 +
=== Performance and design features ===
 +
<!--T:1-->
 +
{| class="wikitable sortable" style="text-align: center;"
 +
! Feature
 +
! OVZ Ploop
 +
! OVZ SimFS (ext4)
 +
! LVM (ext4)
 +
! ZFS (~simfs)
 +
|-
 +
|'''Maximum container volume space'''
 +
|4 TiB <ref>[[Ploop/Limits]]</ref>
 +
|1 EiB
 +
|1 EiB
 +
|256 ZiB
 
|-
 
|-
−
|'''Disk space overcommit (provide more space for containers than available on server now)'''
+
|'''Wasted space due to architecture'''
−
|{{Yes}}
+
|{{No|up to 20%}}
−
|{{Yes}}
+
|{{Yes|No}}
 +
|{{No|up to 20%}}
 +
|?
 
|-
 
|-
−
|'''Reliability'''
+
|'''Disk i/o speed'''
−
|Low: big amount of files produce ext4 corruption so often
+
|Fast in any case
−
|High: fsck, power loss and HW Raid without cache can kill whole data
+
|Very fast with small amount of containers
 +
|Fast in any case
 +
|Fast in any case
 
|-
 
|-
−
|'''Access to private area from host '''
+
|'''Disk space overcommit (provide more space for containers than available on server now)'''
 
|{{Yes}}
 
|{{Yes}}
 
|{{Yes}}
 
|{{Yes}}
−
|-
+
|No
−
|'''Fear to use filesystem over filesystem'''
 
 
|{{Yes}}
 
|{{Yes}}
−
|{{No}}
 
−
|-
 
−
|'''Live backup is easy and consistent'''
 
−
|{{Yes}}<ref name="ploop backup">[http://openvz.livejournal.com/44508.html ploop snapshots and backups]</ref><ref>[[Ploop/Backup]]</ref>, fast block level backup
 
−
|{{No}} (in case of big number of files )
 
−
|-
 
−
|'''Incremental backup support on filesystem level'''
 
−
|{{Yes}} (snapshots)
 
−
|{{No}}
 
 
|-
 
|-
 
|'''Different containers may use file systems of different types and properties'''
 
|'''Different containers may use file systems of different types and properties'''
 
|{{Yes}}
 
|{{Yes}}
 
|{{No}}
 
|{{No}}
 +
|Yes
 +
|No
 
|-
 
|-
−
|'''Live migration is reliable and efficient'''
+
|'''Second level quotes in Linux (inside container)'''
 
|{{Yes}}
 
|{{Yes}}
−
|{{No}}, when apps rely on files i-node numbers being constant (which is normally the case), those apps are not surviving the migration
 
−
|-
 
−
|'''Continue failed CT migration'''
 
−
|{{Yes}}, in [https://lists.openvz.org/pipermail/users/2015-July/006335.html vzctl] from OpenVZ -stable
 
−
|{{Yes}}, option "--keep-dst"
 
−
|-
 
−
|'''Second level quotes in Linux (inside container)'''
 
 
|{{Yes}}
 
|{{Yes}}
 
|{{Yes}}
 
|{{Yes}}
 +
|{{No|Not implemented}}
 
|-
 
|-
−
|'''[Potential] support for QCOW2 and other image formats'''
+
|'''Potential support for QCOW2 and other image formats'''
 
|{{Yes}}
 
|{{Yes}}
 
|{{No}}
 
|{{No}}
 +
|{{No}}
 +
|No
 
|-
 
|-
−
|'''No problems with fs corruption on /vz parition'''
+
|}
 +
 
 +
=== Administrator operations ===
 +
<!--T:1-->
 +
{| class="wikitable sortable" style="text-align: center;"
 +
! Feature
 +
! OVZ Ploop
 +
! OVZ SimFS (ext4)
 +
! LVM (ext4)
 +
! ZFS (~simfs)
 +
|-
 +
|'''External compaction for container volumes'''
 +
|{{No|Needed}} for saving HN space
 +
|{{Yes|No}}
 +
|{{No|Not available}}
 +
|{{Yes|Not required}}
 +
|-
 +
|'''Access to private area from host'''
 
|{{Yes}}
 
|{{Yes}}
−
|{{No}}
+
|{{Yes}}
 +
|?
 +
|?
 +
|-
 +
|'''Live backup'''
 +
|{{Yes|Easy, fast and consistent}}<ref name="ploop backup">[http://openvz.livejournal.com/44508.html ploop snapshots and backups]</ref><ref>[[Ploop/Backup]]</ref>
 +
|{{No|Easy, slow, and sometimes inconsistent}} in case some application depends on inode IDs
 +
|{{No|Fast}}
 +
|{{Yes|Fast}} theoretically
 
|-
 
|-
 
|'''Snapshot support'''
 
|'''Snapshot support'''
 
|{{Yes}}<ref name="ploop backup">[http://openvz.livejournal.com/44508.html ploop snapshots and backups]</ref>
 
|{{Yes}}<ref name="ploop backup">[http://openvz.livejournal.com/44508.html ploop snapshots and backups]</ref>
−
|{{No}}, (because there is a lot of small files that need to be copied)
+
|{{No}} theoretically, because of much/small files to be copied
−
|-
+
|{{Yes}}
−
|'''Better security'''
 
 
|{{Yes}}
 
|{{Yes}}
−
|{{No}} (bugs can be exploited to escape the simfs and let container access the host file system: [https://bugs.openvz.org/browse/OVZ-6296 CVE-2015-2925], [http://www.openwall.com/lists/oss-security/2014/06/24/16 CVE-2014-3519], CVE-2015-6927)
 
 
|-
 
|-
−
|'''Shared storage support (Virtuozzo storage, NFS)'''
+
|'''Live migration'''
−
|{{Yes}}
+
|{{Yes|Reliable and fast}}
−
|{{No}}
+
|{{No|Not reliable and slow}}, if some application depends on inode IDs
 +
|{{No|Not implemented}}
 +
|{{Yes|Fast}} theoretically
 
|-
 
|-
−
|''' Disk space footprint'''
+
|'''Continue failed CT migration'''
−
|{{Yes}}
+
|{{Yes}}, in [https://lists.openvz.org/pipermail/users/2015-July/006335.html vzctl] from OpenVZ -stable
−
|{{No}}
+
|{{Yes}}, option "--keep-dst"
 +
|{{No|Not implemented}}
 +
|?
 
|-
 
|-
 
|}
 
|}
 +
 
</translate>
 
</translate>
  
 
[[Category: Storage]]
 
[[Category: Storage]]

Revision as of 13:05, 6 June 2016

Under construction.svg This article is a stub. You can help OpenVZ Wiki by expanding it.

<translate>

Comparison tables

Solidity in front of failures and security

Feature OVZ Ploop OVZ SimFS (ext4) LVM (ext4) ZFS (~simfs)
I/O isolation Good Bad: Some bug could be exploited to escape CT and access HN file system}}: CVE-2015-2925, CVE-2014-3519 Good Good
Reliability Low: big amount of files produce ext4 corruption so often Medium: fsck, power loss and HW Raid without cache can kill whole data High: LVM metadata can be corrupted completely Excellent: no write hole, checksumming and COW
Risk to be using filesystem over filesystem Yes No No ?
Effect of HN filesystem corruption at /vz No effect Same FS ? ?
Maturity in O/VZ Since 2012 Since ~2005 Since 1998 Since 2014
Incremental backup support on filesystem level Yes, through snapshots No No Yes

Performance and design features

Feature OVZ Ploop OVZ SimFS (ext4) LVM (ext4) ZFS (~simfs)
Maximum container volume space 4 TiB [1] 1 EiB 1 EiB 256 ZiB
Wasted space due to architecture up to 20% No up to 20% ?
Disk i/o speed Fast in any case Very fast with small amount of containers Fast in any case Fast in any case
Disk space overcommit (provide more space for containers than available on server now) Yes Yes No Yes
Different containers may use file systems of different types and properties Yes No Yes No
Second level quotes in Linux (inside container) Yes Yes Yes Not implemented
Potential support for QCOW2 and other image formats Yes No No No

Administrator operations

Feature OVZ Ploop OVZ SimFS (ext4) LVM (ext4) ZFS (~simfs)
External compaction for container volumes Needed for saving HN space No Not available Not required
Access to private area from host Yes Yes ? ?
Live backup Easy, fast and consistent[2][3] Easy, slow, and sometimes inconsistent in case some application depends on inode IDs Fast Fast theoretically
Snapshot support Yes[2] No theoretically, because of much/small files to be copied Yes Yes
Live migration Reliable and fast Not reliable and slow, if some application depends on inode IDs Not implemented Fast theoretically
Continue failed CT migration Yes, in vzctl from OpenVZ -stable Yes, option "--keep-dst" Not implemented ?

</translate>

  1. ↑ Ploop/Limits
  2. ↑ 2.0 2.1 ploop snapshots and backups
  3. ↑ Ploop/Backup
Retrieved from "https://wiki.openvz.org/index.php?title=CT_storage_backends&oldid=19637"