Changes

Jump to: navigation, search

CT storage backends

1,028 bytes added, 11:09, 7 June 2016
return back row with 'Shared storage support', merge three tables to single table
{{stub}}
<translate>
= Comparison table =
<!--T:1-->{| class="wikitable sortable"style="text-align: center;"|-
! Feature
! OVZ Ploop! SIMFSOVZ SimFS (ext4)! LVM (ext4)! ZFS|-!colspan="11" style="font-style:bold;background-color:gold;"|1. Solidity in front of failures and security|-|'''I/O isolation'''|{{Yes|Good}}|{{No|Bad}}: Possibility of "no inodes" issues (when file system journal become a bottleneck).|{{Yes|Good}}|{{Yes|Good}}|-|'''Security'''|{{Yes|Good}}|{{No|Bad}}: Some bug could be exploited to escape CT and access HN file system <ref>[https://bugs.openvz.org/browse/OVZ-6296 CVE-2015-2925]</ref> <ref>[http://www.openwall.com/lists/oss-security/2014/06/24/16 CVE-2014-3519]</ref>|||-|'''Reliability'''|{{No|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|{{Yes|Excellent}}: no write hole, checksumming and COW
|-
|'''MaturityFilesystem over filesystem'''|Since 2012Yes|No|No|Since 2005 (?)
|-
|'''Maximum disk spaceEffect of HN filesystem corruption at /vz'''|Limited:<ref>[[Ploop/Limits]]</ref> ploop v1 - 2 Tb, ploop v2 - 4 Tb{{Yes|No corruption}}|{{No|Possible corruption}}|?|Limited by ext4 filesystem?
|-
|'''Disk space overheadMaturity in O/VZ'''|{{No|Since 2012}}|{{Yes|Since ~2005}}|{{Yes|Since 1998}}, up to 20% for allocated ext4 metadata|{{No|Since 2014}}|-!colspan="11" style="font-style:bold;background-color:gold;"|2. Performance and design features
|-
|'''SpeedMaximum container volume space'''|Fast in any case4 TiB <ref>[[Ploop/Limits]]</ref>|Very fast with small amount of containers per node1 EiB <ref>[https://en.wikipedia.org/wiki/Ext4 Ext4]</ref>|?|256 ZiB
|-
|'''I/O isolationDisk space overhead'''|GoodUp to 20%|Bad, "no inodes" issues (when file system journal is bottleneck)No|Up to 20%|?
|-
|'''Need for run external tools for compaction VE imagesDisk I/O speed'''|{{Yes}}Fast|Fast only with small amount of containers per node, you should vzctl compact every few days for saving your disk spaceslowdown in case of big number of small files.|Fast|{{No}}Fast
|-
|'''Disk space overcommit (provide more space for containers than available on server now)'''
|{{Yes}}
|{{Yes}}
|No
|{{Yes}}
|-
|'''ReliabilityDifferent containers may use file systems of different types and properties'''|Low: big amount of files produce ext4 corruption so often{{Yes}}|{{No}}|Yes|High: fsck, power loss and HW Raid without cache can kill whole dataNo
|-
|'''Access to private area from host Second level quotes in Linux (inside container)'''
|{{Yes}}
|{{Yes}}
|{{Yes}}
|{{No|Not implemented}}
|-
|'''Fear to use filesystem over filesystemPotential support for QCOW2 and other image formats'''
|{{Yes}}
|{{No}}
|-|'''Live backup is easy and consistent'''|{{YesNo}}<ref name="ploop backup">[http://openvz.livejournal.com/44508.html ploop snapshots and backups]</ref>, fast block level backup|{{No}} (in case of big number of files )
|-
|'''Incremental backup support on filesystem level'''
|{{Yes}} (, through snapshots)
|{{No}}
|{{No}}
|{{Yes}}
|-
|'''Shared storage support (Virtuozzo storage, NFS)'''
|{{Yes|Yes}}
|{{No|No}}
|{{Yes|Yes}}
|?
|-
!colspan="11" style="font-style:bold;background-color:gold;"|'''Different containers may use file systems of different types and properties'''|{{Yes}}|{{No}}3. Maintenance
|-
|'''Live migration is reliable and efficientvzctl integration'''|{{Yes|Complete}}|{{Yes|Complete}}|{{No}}, when apps rely on files i-node numbers being constant (which is normally the case)many manual operations|{{No}}, those apps are not surviving the migrationsome manual operations
|-
|'''Continue failed CT migrationExternal compaction for container volumes'''|{{No|Needed}}, see also explanation from Kirfor saving HN space|{{Yes|No}}|{{No|Not available}}|{{Yes|Not required}}, option "--keep-dst"
|-
|'''Second level quotes in Linux (inside container)Access to private area from host'''
|{{Yes}}
|{{Yes}}
|?
|?
|-
|'''[Potential] support for QCOW2 and other image formatsLive backup'''|{{Yes|Easy, fast and consistent}}<ref>[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
|-
|'''No problems with fs corruption on /vz paritionSnapshot support'''|{{Yes}}<ref>[http://openvz.livejournal.com/44508.html ploop snapshots and backups]</ref>|{{No}} theoretically, because of much/small files to be copied
|{{Yes}}
|{{No}}
|-
|'''Snapshot support'''
|{{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)
|-
|'''Better security'''
|{{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|Reliable and fast}}|{{No|Not reliable and slow}}, if some application depends on inode IDs|{{No|Not implemented}}|{{Yes|Fast}}theoretically
|-
|''' Disk space footprintContinue failed CT migration'''|{{Yes}}, in [https://lists.openvz.org/pipermail/users/2015-July/006335.html vzctl] from OpenVZ -stable|{{Yes}}, option "--keep-dst"|{{No|Not implemented}}|?
|-
|
* [[Ploop]]</translate>
[[Category: Storage]]

Navigation menu