Changes

Jump to: navigation, search

CT storage backends

961 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|-|'''Filesystem over filesystem'''|Yes|No|No|?|-|'''Effect of HN filesystem corruption at /vz'''|{{Yes|No corruption}}|{{No|Possible corruption}}|?|?
|-
|'''Maturityin O/VZ'''|{{No|Since 2012}}|{{Yes|Since ~2005 (?)}}|{{Yes|Since 1998}}|{{No|Since 2014}}
|-
!colspan="11" style="font-style:bold;background-color:gold;"|2. Performance and design features|-|'''Maximum disk container volume space'''|Limited:4 TiB <ref>[[Ploop/Limits]]</ref> ploop v1 - 2 Tb, ploop v2 - 4 Tb|Limited by ext4 filesystem1 EiB <ref>[https://en.wikipedia.org/wiki/Ext4 Ext4]</ref>|?|256 ZiB
|-
|'''Disk space overhead'''
|{{Yes}}, up Up to 20% for allocated ext4 metadata|{{No}}|Up to 20%|?
|-
|'''SpeedDisk I/O speed'''|Fast|Fast only with small amount of containers per node, slowdown in case of big number of small files.|Fast
|Fast
|Fast only with small amount of containers per node
|-
|'''I/O isolation'''
|Good
|Bad, "no inodes" issues (when file system journal is bottleneck)
|-
|'''Need for run external tools for compaction VE images'''
|{{Yes}}, you should vzctl compact every few days for saving your disk space
|{{No}}
|-
|'''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><ref>[[Ploop/Backup]]</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}} for saving HN space|{{Yes|No}}|{{No|Not available}}, in [https://lists.openvz.org/pipermail/users/2015-July/006335.html vzctl] from OpenVZ -stable|{{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}}|?
|-
|}
</translate>
[[Category: Storage]]
Retrieved from "https://wiki.openvz.org/Special:MobileDiff/17834...19644"

Navigation menu