• Home
  • About
  •  

    OpenStack Manila – A Q&A on Liberty and Mitaka

    October 16th, 2015

    Our recent Webcast with OpenStack Manila OpenStack Manila Project Team Lead (PTL), Ben Swartzlander, generated a lot of great questions. As promised, we’ve complied answers for all of the questions that came in. If you think of additional questions, please feel free to comment on this blog. And if you missed the live Webcast, it’s now available on-demand.

    Q. Is Hitachi Data Systems contributing to the Manila project?

    A. Yes, Hitachi contributed a new driver and also contributed a major new feature (migration) during Liberty. HDS was also active during the Kilo release with a different driver which is unfortunately no longer maintained.

    Q. EMC has open sourced ViPER as CopperHD. Do you see any overlap between Manila/Cinder from one side and CopperHD from the other hand?

    A. I’m not familiar enough with CoprHD to answer authoritatively, but I understand that there is definitely some overlap between it and Cinder, and I also expect there is some overlap with Manila. Assuming there is some overlap, I think that’s a great thing because competition within open source drives greater quality, and it’s confirmation that there is real demand for what we’re building.

    Q. Could Manila be used stand-alone (without OpenStack) to create a fileshare server?

    A. Yes, the only OpenStack service Manila depends on is Keystone (for authentication). Running Manila in a stand-alone fashion is a specific use case the team supports.

    Q. If we are mapping the snap shot images what is the guarantee for data integrity?

    A. Snapshots are typically crash-consistent copies of the filesystem at a point in time. In reality the exact guarantee depends on the backend used, and that’s something we’d like to avoid, so that the snapshot semantics are clear to the user. In the future, backends which cannot meet the crash-consistent guarantee will probably be forced to advertise a different capability so end users are aware of what they’re getting.

    Q. Is there manila automation with ansible?

    A. As far as I know this hasn’t been done yet.

    Q. For kilo deployed in production does it work for all commercial drivers or is there a chart that says which commercial drivers support kilo?

    A. The developer doc now has a table which attempts to answer this question. However, the most reliable way to see which drivers are part of the stable/kilo release would be to look at the driver directory of the code. This is an area where the docs need to improve.

    Q. Could you explain consistency groups?

    A. Consistency groups are a mechanism to ensure that 2 or more shares can be snapshotted in a single operation. Without CGs, you can take 2 snapshots of 2 shares but there is no guarantee that those snapshots will represent the same point in time. CGs allow you to guarantee that the snapshots are synchronized, which makes it possible to use multiple shares together for a single application and to take snapshots of that application’s data in a consistent way.

    Q. How is the consistency group in Manila different from Cinder? Is it similar?

    A. The designs are very similar. There are some semantic differences in terms of how you modify the membership of the CGs, but the snapshot functionality is identical.

    Q. Are you considering pNFS, but I guess this will be hard since it has req. on the client as well?

    A. Manila is agnostic to the data protocol so if the backend supports pNFS and Manila is asked to create an NFS share, it may very well get a share with pNFS support. Certainly Manila supports shares with multiple export locations so that on a system with multiple network interfaces, or a clustered system, Manila will tell the clients about all of the paths to the share. In the future we may want Manila to actually know the capabilities of the backends w.r.t. what version of NFS they support so that if a user requires a minimum version we can guarantee that they get that version or get a sensible error if it’s not possible.

    Q. Share Replication. In what mode, Async and/or Sync?

    A. We plan to support both, and the choice of which is used will be up to the administrator. Communication about which is used and any relevant information like RPO time would be out of band from Manila. The goal of the feature in Manila is to make Manila able to configure the replication relationship, and able to initiate failovers. The intention is for planned failovers to be disruptive but with no data loss, and for unplanned failovers to be disruptive, with data loss corresponding to the RPO that the administrator configured (which would be zero for synchronous replication).

    Q. Can you point me to any resources with SNIA available for OpenStack? Where can I download document, videos, etc?

    A. You can find several informative OpenStack on-demand Webcasts on the SNIA BrightTalk channel here.

     

     

     

     

     

     

     

     

     

     

     

     

     

     


    What to Expect from OpenStack Manila Liberty

    September 11th, 2015

    On October 7, 2015, the SNIA Ethernet Storage Forum is pleased to present its next live Webcast on OpenStack Manila. Manila is the OpenStack file share service that provides the management of file shares (for example, NFS and CIFS) as a core service to OpenStack. Intended to be an open-standards, highly-available and fault-tolerant component of OpenStack, Manila also aims to provide API-compatibility with popular systems like Amazon EC2.

    I will be moderating this Webcast, presented by the OpenStack Manila Project Team Lead (PTL), Ben Swartzlander, who will dive into:

    • An overview of Manila
    • New features that are being delivered for OpenStack Liberty (due October 2015)
    • A preview of Makita

    With Liberty availability due next month, this information is extremely timely; I encourage you to register now to block your calendar. This will be a live and interactive Webcast, please bring your questions. I look forward to “seeing” you on October 7th.


    OpenStack File Services Options

    August 17th, 2015

    How can OpenStack consume and control file services appropriate to High Performance Compute (HPC) in a cloud and multi-tenanted environment? Find out on September 22nd when SNIA Cloud hosts a live Webcast and examines two approaches to integration.

    One approach is to have OpenStack manage the storage infrastructure services using Cinder, Nova and Neutron to provide HPC Filesystem as a Service.

    A second option is to use Manila file services for OpenStack to control the HPC File system deployment and manage the exports etc. This part also looks at the creation (in progress) of the Lustre Manila driver and its current progress.

    I hope you’ll join Alex McDonald and me as we discuss the pros and cons of each approach. Register today and


    OpenStack Manila Webcast – Shared File Services for the Cloud

    January 7th, 2015

    On January 29th, we continue our Cloud Developer’s series by hosting a live Webcast on OpenStack Manila – the OpenStack file share service. Manila provides the management of file shares (for example, NFS and CIFS) as a core service to OpenStack. Manila currently works with a variety of vendors’ storage products, including NetApp, Red Hat, EMC, IBM, and with the Linux NFS server.

    In this Webcast we will:

    • Introduce the Manila file share service
    • Review key Manila concepts
    • Describe the logical architecture of Manila and its API structure
    • Explain what’s new in Juno, the latest release of OpenStack
    • Highlight the roadmap for Manila in the next release, OpenStack Kilo, and beyond

    Register now for this live event that we expect will be informative and interactive. I hope you’ll join us.