bcache with iscsi, mpath and lvm

bcache with iscsi, mpath and lvm

[infernix]

Hi,

I've got the following stack, bottom to top:

- iscsi sans with multiple NICs
- servers with multiple NICs
- open-iscsi cross-connecting to the san over those multiple nics
- multipath to aggregate and load-balance IO over said paths
- LVM on top of multiple mpathX devices
- qemu-kvm running with disks connecting to logical volumes in said LVM

I am wondering if bcache can fit in, and if so, where?

Ideally I would say it sits between multipath and LVM, e.g. it is active 
for the /dev/mapper/mpathX devices. But that doesn't work because there 
isn't really a filesystem on it and so it doesn't get assigned an UUID. 
Even if it did, that UUID would be the same for all sdX devices in the 
multipath device.

Is there any other way of activating bcache besides passing it an UUID? 
And can it even work on top of a dm-multipath device?

Thanks!

Re: bcache with iscsi, mpath and lvm

[Joseph Glanville]

Hi,

I'm not a bcache expert by any means but I might hazard a few comments inline.

On 1 February 2012 02:36, infernix <infernix-ZHiucA87ovfk1uMJSBkQmQ@public.gmane.org> wrote:
> Hi,
>
> I've got the following stack, bottom to top:
>
> - iscsi sans with multiple NICs
> - servers with multiple NICs
> - open-iscsi cross-connecting to the san over those multiple nics
> - multipath to aggregate and load-balance IO over said paths
> - LVM on top of multiple mpathX devices
> - qemu-kvm running with disks connecting to logical volumes in said LVM
>
> I am wondering if bcache can fit in, and if so, where?

The primary purpose of bcache is to serve as a writeback cache as this
provides the most benefit to I/O.
However where you place this cache depends on your usage patterns and
bottlenecks...
If you are bottlenecking purely on random I/O then the easiest and
most logical place for bcache is infront of your iSCSI backing store
on your SAN.

Looking something like this:

SAN NICs > IET or SCST > bcache > Backing store

This is super simple and means you make the most possible use out of
the cache because all of your clients random I/O is gauranteed to make
its way through this path.

If however you are bottlenecked on the iSCSI interconnect you could
feasibly place bcache ontop of the multipath devices (they are just
standard dm targets) right below the VMs.
This adds the highest possible amount of performance to the VMs at the
cost of increased maintaince, complexity of multiple caches and
ofcourse cost.

>
> Ideally I would say it sits between multipath and LVM, e.g. it is active for
> the /dev/mapper/mpathX devices. But that doesn't work because there isn't
> really a filesystem on it and so it doesn't get assigned an UUID. Even if it
> did, that UUID would be the same for all sdX devices in the multipath
> device.
>
> Is there any other way of activating bcache besides passing it an UUID? And
> can it even work on top of a dm-multipath device?

It works on LVM so it should work fine on multipath targets too.

>
> Thanks!
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bcache" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


Hope that was able to help abit. :)
Keep the list in the loop on your progress.

Joseph.

-- 
Founder | Director | VP Research
Orion Virtualisation Solutions | www.orionvm.com.au | Phone: 1300 56
99 52 | Mobile: 0428 754 846

Re: bcache with iscsi, mpath and lvm

[infernix]

Op 31-1-2012 16:50, Joseph Glanville schreef:
>> I've got the following stack, bottom to top:
>> - iscsi sans with multiple NICs
>> - servers with multiple NICs
>> - open-iscsi cross-connecting to the san over those multiple nics
>> - multipath to aggregate and load-balance IO over said paths
>> - LVM on top of multiple mpathX devices
>> - qemu-kvm running with disks connecting to logical volumes in said LVM

> If you are bottlenecking purely on random I/O then the easiest and
> most logical place for bcache is infront of your iSCSI backing store
> on your SAN.

Agreed. But since the SAN is proprietary, there's zero chance of 
implementing bcache on the SAN :)

> If however you are bottlenecked on the iSCSI interconnect you could
> feasibly place bcache ontop of the multipath devices (they are just
> standard dm targets) right below the VMs.
> This adds the highest possible amount of performance to the VMs at the
> cost of increased maintaince, complexity of multiple caches and
> ofcourse cost.

Yes. So that is why I think the tradeoff of putting bcache on the mpath 
devices is the best. There's no shared storage use between servers; each 
just uses its own LVs. As long as I'm using writethrough, this is safe. 
Doing writeback is simply impossible with multiple caches like this.

Setting up bcache for each and every logical volume is not really going 
to work because they are quite dynamic.

>> Is there any other way of activating bcache besides passing it an UUID? And
>> can it even work on top of a dm-multipath device?
>
> It works on LVM so it should work fine on multipath targets too.

Except that I can't get an UUID from the LVM PVs:

blkid /dev/mpath/mpath2 -s UUID -o value

Returns nothing. So I'm a little confused as to how to register the 
device for caching.

Re: bcache with iscsi, mpath and lvm

[Joseph Glanville]

On 1 February 2012 03:04, infernix <infernix-ZHiucA87ovfk1uMJSBkQmQ@public.gmane.org> wrote:
> Op 31-1-2012 16:50, Joseph Glanville schreef:
>
>>> I've got the following stack, bottom to top:
>>> - iscsi sans with multiple NICs
>>> - servers with multiple NICs
>>> - open-iscsi cross-connecting to the san over those multiple nics
>>> - multipath to aggregate and load-balance IO over said paths
>>> - LVM on top of multiple mpathX devices
>>> - qemu-kvm running with disks connecting to logical volumes in said LVM
>
>
>> If you are bottlenecking purely on random I/O then the easiest and
>> most logical place for bcache is infront of your iSCSI backing store
>> on your SAN.
>
>
> Agreed. But since the SAN is proprietary, there's zero chance of
> implementing bcache on the SAN :)

Ahh the wonders of proprietary appliances. :P

>
>
>> If however you are bottlenecked on the iSCSI interconnect you could
>> feasibly place bcache ontop of the multipath devices (they are just
>> standard dm targets) right below the VMs.
>> This adds the highest possible amount of performance to the VMs at the
>> cost of increased maintaince, complexity of multiple caches and
>> ofcourse cost.
>
>
> Yes. So that is why I think the tradeoff of putting bcache on the mpath
> devices is the best. There's no shared storage use between servers; each
> just uses its own LVs. As long as I'm using writethrough, this is safe.
> Doing writeback is simply impossible with multiple caches like this.

It's actually quite easy to script, you can use SCSI ID or similar to
map the LUNs or LVs (not sure how you have things setup)
to block paths, which you can then use with multipath -ll to get the
multipath WWID
I'm playing with something similar atm.

>
> Setting up bcache for each and every logical volume is not really going to
> work because they are quite dynamic.
>
>
>>> Is there any other way of activating bcache besides passing it an UUID?
>>> And
>>> can it even work on top of a dm-multipath device?
>>
>>
>> It works on LVM so it should work fine on multipath targets too.
>
>
> Except that I can't get an UUID from the LVM PVs:
>
> blkid /dev/mpath/mpath2 -s UUID -o value

That is a very valid point.. bcache should probably index by something
other than UUID because most block devices don't have them.. only
filesystems..

>
> Returns nothing. So I'm a little confused as to how to register the device
> for caching.
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bcache" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Founder | Director | VP Research
Orion Virtualisation Solutions | www.orionvm.com.au | Phone: 1300 56
99 52 | Mobile: 0428 754 846