A good hierarchical Storage Management (HSM) for BeeGFS?
636 views
Skip to first unread message
zack....@sbcglobal.net
Sep 4, 2016, 11:08:27 PM9/4/16
to beegfs-user
We need to introduce a faster tier (formed with SSDs, obviously) into our storage infrastructure. I am aware of the fact that for Lustre (which is also widely used here), the HSM is available since Lustre 2.5. Could BeeGFS developers or a seasoned user share what you would consider a good HSM choice for BeeGFS? I prefer not to go back to Lustre :)
-- Zack
Sven Breuner
Sep 8, 2016, 5:09:58 AM9/8/16
to fhgfs...@googlegroups.com
Hi Zack,
do you have HSM in mind in the classical sense that files are being migrated
between the tiers on access and released on the upper tier when a certain
threshold is crossed? Or do you maybe rather have something like SSD caching in
mind, which could be done with software like lvmcache, bcache & friends on the
servers or RAID-controller based with something like MegaRAID CacheCade?
Typically, the people that we are aware of used either a caching technology to
improve generic use of the system. And when performance really mattered and
special applications should complete much faster, they typically rather went
with a separate BeeGFS instance, which was completely based on SSDs/NVMe.
What we are already working on and planning to have ready later this year is
support for different types of storage targets, so that you can define arbitrary
groups of similar storage targets within the same BeeGFS instance, e.g. like a
group of "SSD targets", a group of "normal HDD targets" and maybe "SMR disk
targets". We call this feature "Storage Pools".
Based on that, you will be able to define (e.g. on a per-directory basis) which
pool should be used when a new file is created inside a certain path. And there
will be a tool to migrate files from one pool to another - but that's manual,
not automatic, because it might not make sense to always copy a file from the
SMR disks to a higher layer just because it is read once; and in the other
direction, you might not want to start copying (temporary) data from the SSDs to
other pools just because the pool crosses a certain free space threshold.
Since individual quota limits can be defined on a per-pool basis then, there is
also a way to motivate system users to care about which data they have on which
pool.
Best regards,
Sven Breuner
ThinkParQ
zack....@sbcglobal.net wrote on 05.09.2016 05:08:
> We need to introduce a faster tier (formed with SSDs, obviously) into our
> storage infrastructure. I am aware of the fact that for Lustre (which is also
> widely used here), the HSM is available since Lustre 2.5
> <http://www.seagate.com/files/www-content/solutions-content/cloud-systems-and-solutions/high-performance-computing/_shared/docs/clusterstor-inside-lustre-hsm-ti.pdf>.
do you have HSM in mind in the classical sense that files are being migrated
between the tiers on access and released on the upper tier when a certain
threshold is crossed? Or do you maybe rather have something like SSD caching in
mind, which could be done with software like lvmcache, bcache & friends on the
servers or RAID-controller based with something like MegaRAID CacheCade?
Typically, the people that we are aware of used either a caching technology to
improve generic use of the system. And when performance really mattered and
special applications should complete much faster, they typically rather went
with a separate BeeGFS instance, which was completely based on SSDs/NVMe.
What we are already working on and planning to have ready later this year is
support for different types of storage targets, so that you can define arbitrary
groups of similar storage targets within the same BeeGFS instance, e.g. like a
group of "SSD targets", a group of "normal HDD targets" and maybe "SMR disk
targets". We call this feature "Storage Pools".
Based on that, you will be able to define (e.g. on a per-directory basis) which
pool should be used when a new file is created inside a certain path. And there
will be a tool to migrate files from one pool to another - but that's manual,
not automatic, because it might not make sense to always copy a file from the
SMR disks to a higher layer just because it is read once; and in the other
direction, you might not want to start copying (temporary) data from the SSDs to
other pools just because the pool crosses a certain free space threshold.
Since individual quota limits can be defined on a per-pool basis then, there is
also a way to motivate system users to care about which data they have on which
pool.
Best regards,
Sven Breuner
ThinkParQ
zack....@sbcglobal.net wrote on 05.09.2016 05:08:
> We need to introduce a faster tier (formed with SSDs, obviously) into our
> storage infrastructure. I am aware of the fact that for Lustre (which is also
> widely used here), the HSM is available since Lustre 2.5
Michael Ruepp
Sep 8, 2016, 6:09:55 AM9/8/16
to fhgfs...@googlegroups.com
Hi Zack,
We are talking currently with http://www.versity.com which developed a Linux Port of the Oracle HSM (formerly SAM-QFS) to integrate it with BeeGFS. Versity is a Hierarchical Storage Management System.
One possible Solution might be to use the Versity File System as Backend Filesystem for BeeGFS and integrate 2nd and 3rd Tiers with Infiniband Storage and Tape Libraries. There are multiple approaches discussed. If the architecture turns out to be viable, we will offer Turnkey Solutions as well as implementation Services.
Please contact me via Email if you are interested, and I will keep you in the loop.
Mit freundlichen Grüssen/Best regards,
Michael Ruepp, BA
____________________________
skype michaelruepp
phone +43 676 911 40 90
Oyonoko Development
Geschäftsführer: Michael Ruepp
A-1020 Vienna/Austria
UID: ATU41060409
IBAN: AT11 3743 1000 0387 5622
BIC: RVVGAT2B431
BIC: RVVGAT2B431
CONFIDENTIALITY NOTICE
This message (including any attachments transmitted with it) contains confidential information and is intended only for the individual named herein. If you are not the herein named addressee you should not disseminate, distribute, copy or otherwise make use of this message. Please notify the sender immediately by e-mail if you have received this message by mistake, and delete it from your systems.
--
You received this message because you are subscribed to the Google Groups "beegfs-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fhgfs-user+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply all
Reply to author
Forward
0 new messages