Difference between revisions of "CT storage backends"

From OpenVZ Virtuozzo Containers Wiki
Jump to: navigation, search
(References, vzctl integration)
(Some ZFS fixes and updates)
 
(5 intermediate revisions by 3 users not shown)
Line 1: Line 1:
 
{{stub}}
 
{{stub}}
 
<translate>
 
<translate>
= Comparison tables =
+
 
 +
= Comparison table =
  
 
<!--T:1-->
 
<!--T:1-->
=== Solidity in front of failures and security ===
 
 
{| class="wikitable sortable" style="text-align: center;"
 
{| class="wikitable sortable" style="text-align: center;"
 +
|-
 
! Feature
 
! Feature
 
! OVZ Ploop
 
! OVZ Ploop
 
! OVZ SimFS (ext4)
 
! OVZ SimFS (ext4)
 
! LVM (ext4)
 
! LVM (ext4)
! ZFS (~simfs)
+
! 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}}: 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>
+
|{{No|Bad}}: Possibility of "no inodes" issues (when file system journal become a bottleneck).
 
|{{Yes|Good}}
 
|{{Yes|Good}}
 
|{{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'''
 
|'''Reliability'''
Line 24: Line 33:
 
|{{Yes|Excellent}}: no write hole, checksumming and COW
 
|{{Yes|Excellent}}: no write hole, checksumming and COW
 
|-
 
|-
|'''Risk to be using filesystem over filesystem'''
+
|'''Filesystem over filesystem'''
|{{No|Yes}}
+
|Yes
|{{Yes|No}}
+
|No
|{{Yes|No}}
+
|No
|?
+
|{{Yes|Using zvol}}
 
|-
 
|-
 
|'''Effect of HN filesystem corruption at /vz'''
 
|'''Effect of HN filesystem corruption at /vz'''
|{{Yes|No effect}}
+
|{{Yes|No corruption}}
|{{No|Same FS}}
+
|{{No|Possible corruption}}
 
|?
 
|?
 
|?
 
|?
 
|-
 
|-
 
|'''Maturity in O/VZ'''
 
|'''Maturity in O/VZ'''
|{{No|Since 2012}}
+
|{{Yes|Since 2012}}
 
|{{Yes|Since ~2005}}
 
|{{Yes|Since ~2005}}
 
|{{Yes|Since 1998}}
 
|{{Yes|Since 1998}}
|{{No|Since 2014}}
+
|{{Yes|Since 2014}}
 
|-
 
|-
|}
+
!colspan="11" style="font-style:bold;background-color:gold;"|2. Performance and design features
 
 
=== Performance and design features ===
 
{| class="wikitable sortable" style="text-align: center;"
 
! Feature
 
! OVZ Ploop
 
! OVZ SimFS (ext4)
 
! LVM (ext4)
 
! ZFS (~simfs)
 
 
|-
 
|-
 
|'''Maximum container volume space'''
 
|'''Maximum container volume space'''
Line 58: Line 59:
 
|256 ZiB
 
|256 ZiB
 
|-
 
|-
|'''Wasted space due to architecture'''
+
|'''Disk space overhead'''
|{{No|up to 20%}}
+
|Up to 20%
|{{Yes|No}}
+
|No
|{{No|up to 20%}}
+
|Up to 20%
|?
+
|No, but if using zvol is up to 50% depending on volblocksize
 
|-
 
|-
|'''Disk i/o speed'''
+
|'''Disk I/O speed'''
|Fast in any case
+
|Fast
|Very fast with small amount of containers
+
|Fast only with small amount of containers per node, slowdown in case of big number of small files.
|Fast in any case
+
|Fast
|Fast in any case
+
|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 79: Line 80:
 
|{{Yes}}
 
|{{Yes}}
 
|{{No}}
 
|{{No}}
|Yes
+
|{{Yes}}
|No
+
|{{Yes|Using zvol}}
 
|-
 
|-
 
|'''Second level quotes in Linux (inside container)'''
 
|'''Second level quotes in Linux (inside container)'''
Line 86: Line 87:
 
|{{Yes}}
 
|{{Yes}}
 
|{{Yes}}
 
|{{Yes}}
|{{No|Not implemented}}
+
|{{Yes|Using zvol}}
 
|-
 
|-
 
|'''Potential support for QCOW2 and other image formats'''
 
|'''Potential support for QCOW2 and other image formats'''
Line 92: Line 93:
 
|{{No}}
 
|{{No}}
 
|{{No}}
 
|{{No}}
|No
+
|{{No}}
 
|-
 
|-
 
|'''Incremental backup support on filesystem level'''
 
|'''Incremental backup support on filesystem level'''
Line 100: Line 101:
 
|{{Yes}}
 
|{{Yes}}
 
|-
 
|-
|}
+
|'''Shared storage support (Virtuozzo storage, NFS)'''
 
+
|{{Yes|Yes}}
=== Administrator operations ===
+
|{{No|No}}
{| class="wikitable sortable" style="text-align: center;"
+
|{{Yes|Yes}}
! Feature
+
|{{Yes|NFS only}}
! OVZ Ploop
+
|-
! OVZ SimFS (ext4)
+
!colspan="11" style="font-style:bold;background-color:gold;"|3. Maintenance
! LVM (ext4)
 
! ZFS (~simfs)
 
 
|-
 
|-
 
|'''vzctl integration'''
 
|'''vzctl integration'''
 
|{{Yes|Complete}}
 
|{{Yes|Complete}}
 
|{{Yes|Complete}}
 
|{{Yes|Complete}}
|{{No|No}}, many manual operations
+
|{{No}}, many manual operations
|{{Yes|No}}, some manual operations
+
|{{No}}, some manual operations
 
|-
 
|-
 
|'''External compaction for container volumes'''
 
|'''External compaction for container volumes'''
Line 126: Line 125:
 
|{{Yes}}
 
|{{Yes}}
 
|?
 
|?
|?
+
|{{Yes|Only using ZFS filesystem}}
 
|-
 
|-
 
|'''Live backup'''
 
|'''Live backup'''
 
|{{Yes|Easy, fast and consistent}}<ref>[http://openvz.livejournal.com/44508.html ploop snapshots and backups]</ref> <ref>[[Ploop/Backup]]</ref>
 
|{{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|Easy, slow, and sometimes inconsistent}} in case some application depends on inode IDs
|{{No|Fast}}
+
|{{No|No}}
|{{Yes|Fast}} theoretically
+
|{{Yes|Fast}} via ZFS Send/Receive
 
|-
 
|-
 
|'''Snapshot support'''
 
|'''Snapshot support'''
Line 144: Line 143:
 
|{{No|Not reliable and slow}}, if some application depends on inode IDs
 
|{{No|Not reliable and slow}}, if some application depends on inode IDs
 
|{{No|Not implemented}}
 
|{{No|Not implemented}}
|{{Yes|Fast}} theoretically
+
|{{Yes|Fast}} via ZFS Send/Receive
 
|-
 
|-
 
|'''Continue failed CT migration'''
 
|'''Continue failed CT migration'''

Latest revision as of 18:02, 15 December 2022

<translate>

Comparison table[edit]

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 Using zvol
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% No, but if using zvol is up to 50% depending on volblocksize
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 Using zvol
Second level quotes in Linux (inside container) Yes Yes Yes Using zvol
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 NFS only
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 ? Only using ZFS filesystem
Live backup Easy, fast and consistent[5] [6] Easy, slow, and sometimes inconsistent in case some application depends on inode IDs No Fast via ZFS Send/Receive
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 via ZFS Send/Receive
Continue failed CT migration Yes, in vzctl from OpenVZ -stable Yes, option "--keep-dst" Not implemented ?

</translate>