[Bugs] [Bug 1249950] [RFE] Sharding feature

[bugzilla at redhat.com]

https://bugzilla.redhat.com/show_bug.cgi?id=1249950

Paul Cuzner <pcuzner at redhat.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pcuzner at redhat.com



--- Comment #4 from Paul Cuzner <pcuzner at redhat.com> ---
The virtualisation use case derives a number of benefits from the introduction
of sharding in gluster. The list below shows where we are today, coupled with
the benefit sharding brings to the virtualisation use case

1. without sharding a virtual disk size is limited to the size of the brick
   - with sharding the size limit is lifted to the size of the gluster volume
   - with sharding the impact of a mix of large and small virtual disks filling
some bricks before others is less of a problem since the shards are distributed
across all bricks regardless of vdisk size

2. without sharding self heal is based on whole file, full or diff algorithms.
This is fine for files that are not constantly open and changing - but in the
virt use case a self heal event triggers a resync for all vm's. This level of
resync increases cpu and I/O contention within the environment, and in the
hyperconverged use case leads to non-responsive vm's
  - with sharding, self heal is able to operate at the shard level 
  - with sharding the time to heal is significantly reduced (early test showed
a 1.5->2hr self heal reduced to <5mins)

3. without sharding the performance potential of a vdisk is limited by a single
host and single brick.
   - with sharding, there is a potential increase in the performance potential
of a vdisk since more bricks/nodes are responsible for the vdisk.

4. without sharding, geo-replication operates at the whole file level, which in
the context of virtualisation means the complete vdisk. Since powered on vm's
are constantly changing, geo-rep becomes an impractical option due to high cpu,
io contention and consistency.
  - with sharding, georep is potentially able to operate at the changed shard
level avoiding the full or diff for the complete file entirely, making geo-rep
more viable for virtualisation use cases

5. without sharding, the IOPS provided to a vdisk is a product of the
underlying disks in the brick. To date this requires a RAID card to aggregate
the IOPS of the underlying disks to provide adequate performance to the file
(virtual disk)
  - with sharding, there is the potential to adopt a JBOD strategy since
sharding itself is distributing the data to aggregate the IO. This reduces
cost, and simplifies the configuration and deployment processes required at
scale.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=ti7wH0tst7&a=cc_unsubscribe