Difference between revisions of "CT storage backends"
(ZFS is not a SimFS) |
(return back row with 'Shared storage support', merge three tables to single table) |
||
Line 1: | Line 1: | ||
{{stub}} | {{stub}} | ||
<translate> | <translate> | ||
− | = Comparison | + | |
+ | = Comparison table = | ||
<!--T:1--> | <!--T:1--> | ||
− | |||
{| class="wikitable sortable" style="text-align: center;" | {| class="wikitable sortable" style="text-align: center;" | ||
+ | |- | ||
! Feature | ! Feature | ||
! OVZ Ploop | ! OVZ Ploop | ||
Line 11: | Line 12: | ||
! LVM (ext4) | ! LVM (ext4) | ||
! ZFS | ! ZFS | ||
+ | |- | ||
+ | !colspan="11" style="font-style:bold;background-color:gold;"|1. Solidity in front of failures and security | ||
|- | |- | ||
|'''I/O isolation''' | |'''I/O isolation''' | ||
|{{Yes|Good}} | |{{Yes|Good}} | ||
− | |{{No|Bad}}: | + | |{{No|Bad}}: Possibility of "no inodes" issues (when file system journal become a bottleneck). |
+ | |{{Yes|Good}} | ||
|{{Yes|Good}} | |{{Yes|Good}} | ||
+ | |- | ||
+ | |'''Security''' | ||
|{{Yes|Good}} | |{{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''' | |'''Reliability''' | ||
Line 25: | Line 34: | ||
|- | |- | ||
|'''Filesystem over filesystem''' | |'''Filesystem over filesystem''' | ||
− | + | |Yes | |
− | + | |No | |
− | + | |No | |
|? | |? | ||
|- | |- | ||
|'''Effect of HN filesystem corruption at /vz''' | |'''Effect of HN filesystem corruption at /vz''' | ||
− | |{{Yes|No | + | |{{Yes|No corruption}} |
− | |{{No| | + | |{{No|Possible corruption}} |
|? | |? | ||
|? | |? | ||
Line 42: | Line 51: | ||
|{{No|Since 2014}} | |{{No|Since 2014}} | ||
|- | |- | ||
− | + | !colspan="11" style="font-style:bold;background-color:gold;"|2. Performance and design features | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
|- | |- | ||
|'''Maximum container volume space''' | |'''Maximum container volume space''' | ||
Line 58: | Line 59: | ||
|256 ZiB | |256 ZiB | ||
|- | |- | ||
− | |''' | + | |'''Disk space overhead''' |
− | | | + | |Up to 20% |
− | + | |No | |
− | | | + | |Up to 20% |
|? | |? | ||
|- | |- | ||
− | |'''Disk | + | |'''Disk I/O speed''' |
− | |Fast | + | |Fast |
− | | | + | |Fast only with small amount of containers per node, slowdown in case of big number of small files. |
− | |Fast | + | |Fast |
− | |Fast | + | |Fast |
|- | |- | ||
|'''Disk space overcommit (provide more space for containers than available on server now)''' | |'''Disk space overcommit (provide more space for containers than available on server now)''' | ||
Line 100: | Line 101: | ||
|{{Yes}} | |{{Yes}} | ||
|- | |- | ||
− | |} | + | |'''Shared storage support (Virtuozzo storage, NFS)''' |
− | + | |{{Yes|Yes}} | |
− | + | |{{No|No}} | |
− | + | |{{Yes|Yes}} | |
− | + | |? | |
− | + | |- | |
− | + | !colspan="11" style="font-style:bold;background-color:gold;"|3. Maintenance | |
− | |||
− | |||
|- | |- | ||
|'''vzctl integration''' | |'''vzctl integration''' |
Revision as of 11:09, 7 June 2016
<translate>
Comparison table
Feature | OVZ Ploop | OVZ SimFS (ext4) | LVM (ext4) | ZFS | ||||||
---|---|---|---|---|---|---|---|---|---|---|
1. Solidity in front of failures and security | ||||||||||
I/O isolation | Good | Bad: Possibility of "no inodes" issues (when file system journal become a bottleneck). | Good | Good | ||||||
Security | Good | Bad: Some bug could be exploited to escape CT and access HN file system [1] [2] | ||||||||
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 | ||||||
Filesystem over filesystem | Yes | No | No | ? | ||||||
Effect of HN filesystem corruption at /vz | No corruption | Possible corruption | ? | ? | ||||||
Maturity in O/VZ | Since 2012 | Since ~2005 | Since 1998 | Since 2014 | ||||||
2. Performance and design features | ||||||||||
Maximum container volume space | 4 TiB [3] | 1 EiB [4] | ? | 256 ZiB | ||||||
Disk space overhead | Up to 20% | No | Up to 20% | ? | ||||||
Disk I/O speed | Fast | Fast only with small amount of containers per node, slowdown in case of big number of small files. | Fast | Fast | ||||||
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 | ||||||
Incremental backup support on filesystem level | Yes, through snapshots | No | No | Yes | ||||||
Shared storage support (Virtuozzo storage, NFS) | Yes | No | Yes | ? | ||||||
3. Maintenance | ||||||||||
vzctl integration | Complete | Complete | No, many manual operations | No, some manual operations | ||||||
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[5] [6] | Easy, slow, and sometimes inconsistent in case some application depends on inode IDs | Fast | Fast theoretically | ||||||
Snapshot support | Yes[7] | 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>