[ovirt-devel] [RFE] treat local NFS storage as localfs
Yaniv Dary
ydary at redhat.com
Thu Dec 22 12:30:46 UTC 2016
Also NFS had locking issues on loopback. Not really possible to do this
with NFS.
What is the issue with using a Gluster local replicate 1 for this?
Yaniv Dary
Technical Product Manager
Red Hat Israel Ltd.
34 Jerusalem Road
Building A, 4th floor
Ra'anana, Israel 4350109
Tel : +972 (9) 7692306
8272306
Email: ydary at redhat.com
IRC : ydary
On Wed, Dec 21, 2016 at 8:03 PM, Michal Skrivanek <mskrivan at redhat.com>
wrote:
> > On 21 Dec 2016, at 16:26, Martin Sivak <msivak at redhat.com> wrote:
> >
> > Hi,
> >
> >> Hope this get's in. This seems less overhead than a complete
> >> hyperconverged gluster setup.
> >
> > But NFS still is a single point of failure. Hyperconverged is supposed
> > to address that.
> >
> >>> In order to improve performance, disk I/O bound VMs can be pinned to
> >>> a host with local storage. However there still is a performance
> >>> drawback of NFS layers. Treating a local NFS storage as a local storage
> >>> improves performance for VMs pinned to host.
> >
> > So VMs on one host will get better IO performance and the others will
> > still use NFS as they do now.
> >
> > It is an interesting idea, I am just not sure if having poor-man's
> > hyperconverged setup with all the drawbacks of NFS is worth it.
> > Imagine for example what happens when that storage provider host needs
> > to be fenced or put into maintenance. The whole cluster would go down
> > (all VMs would lose storage connection, not just the VMs from the
> > affected host).
> >
> > I will let someone from the storage team to respond to this, but I do
> > not think that trading performance (each host has its own local
> > storage) and resilience (well, at least one failing host does not
> > affect the others) for migrations is a good deal.
>
> If disk performance is critical then there is an option to use direct
> access on local host using either PCI passthrough of a local storage
> controller or SCSI passthrough of LUNs.
>
> >
> > --
> > Martin Sivak
> > SLA / oVirt
> >
> >> On Wed, Dec 21, 2016 at 2:18 PM, Sven Kieske <s.kieske at mittwald.de>
> wrote:
> >>> On 21/12/16 11:44, Pavel Gashev wrote:
> >>> Hello,
> >>>
> >>> I'd like to introduce a RFE that allows to use a local storage in multi
> >>> server environments https://bugzilla.redhat.com/
> show_bug.cgi?id=1406412
> >>>
> >>> Most servers have a local storage. Some servers have very reliable
> >>> storages with hardware RAID controllers and battery units.
> >>>
> >>> Example user cases:
> >>> https://www.mail-archive.com/users@ovirt.org/msg36719.html
> >>> https://www.mail-archive.com/users@ovirt.org/msg36772.html
> >>>
> >>> The best way to use local storage in multi server "shared" datacenters
> >>> is exporting it over NFS. Using NFS allows to move disks and VMs among
> >>> servers.
> >>>
> >>> In order to improve performance, disk I/O bound VMs can be pinned to
> >>> a host with local storage. However there still is a performance
> >>> drawback of NFS layers. Treating a local NFS storage as a local storage
> >>> improves performance for VMs pinned to host.
> >>>
> >>> Currently setting up of NFS exports is out of scope of oVirt. However
> >>> this would be a way to get rid of "Local/Shared" storage types of
> >>> datacenter. So that all storages are shared, but local storages are
> >>> used as local.
> >>>
> >>> Any questions/comments are welcome.
> >>>
> >>> Specifically I'd like to request for comment on potential data
> >>> integrity issues during online VM or disk migration between NFS and
> >>> localfs.
> >>>
> >>
> >> Just let me say that I really like this as an end user.
> >>
> >> Hope this get's in. This seems less overhead than a complete
> >> hyperconverged gluster setup.
> >>
> >>
> >> --
> >> Mit freundlichen Grüßen / Regards
> >>
> >> Sven Kieske
> >>
> >> Systemadministrator
> >> Mittwald CM Service GmbH & Co. KG
> >> Königsberger Straße 6
> >> 32339 Espelkamp
> >> T: +495772 293100
> >> F: +495772 293333
> >> https://www.mittwald.de
> >> Geschäftsführer: Robert Meyer
> >> St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad
> Oeynhausen
> >> Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad
> Oeynhausen
> >>
> >>
> >> _______________________________________________
> >> Devel mailing list
> >> Devel at ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/devel
> > _______________________________________________
> > Devel mailing list
> > Devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/devel
> >
> >
> _______________________________________________
> Devel mailing list
> Devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/devel/attachments/20161222/0cb5d044/attachment.html>
More information about the Devel
mailing list