Join Us for 15 Minutes in the Clouds

Everyone is familiar with the term “Cloud” but it’s still worth asking “What is Cloud?”  It can be defined as “networked computing facilities providing remote data storage and processing services via the Internet.” And while that definition is simple (if a little wordy!), the real-world of cloud is complex, dynamic, and ever growing.

That’s why we’re hosting this series which will include brief 15-minute discussions on cloud and cloud related technologies:

  • What is Cloud – terminology 
  • Cloud application architecture 
  • Cloud data privacy & security 
  • Cloud provider storage offerings

At this first talk “What is Cloud?” on March 2, 2022, the SNIA Cloud Storage Technologies Initiative will present a brief history of “The Cloud.” If you are a cloud expert, these sessions might not be for you, but for everyone else, this series of short talks might clear up a lot of questions you may have. Join us for a discussion on:

Read More

How Gateways Benefit Cloud Object Storage

The use of cloud object storage is ramping up sharply especially in the public cloud, where its simplicity can significantly reduce capital budgets and operating expenses. And while it makes good economic sense, enterprises are challenged with legacy applications that do not support standard protocols to move data to and from the cloud.

That’s why the SNIA Cloud Storage Initiative is hosting a live webcast on September 26th, “Cloud Object Storage and the Use of Gateways.”

Object storage is a secure, simple, scalable, and cost-effective means of managing the explosive growth of unstructured data enterprises generate every day. Enterprises have developed data strategies specific to the public cloud; improved data protection, long term archive, application development, DevOps, Data Science, and cognitive artificial intelligence to name a few.

However, these same organizations have legacy applications and infrastructure that are not object storage friendly, but use file protocols like NFS and SMB. Gateways enable SMB and NFS data transfers to be converted to Amazon’s S3 protocol while optimizing data with deduplication, providing QoS (quality of service), and efficiencies on the data path to the cloud.

This webcast will highlight the market trends toward the adoption of object storage and the use of gateways to execute a cloud strategy, the benefits of object storage when gateways are deployed, and the use cases that are best suited to leverage this solution.

You will learn:

  • The benefits of object storage when gateways are deployed
  • Primary use cases for using object storage and gateways in private, public or hybrid cloud
  • How gateways can help achieve the goals of your cloud strategy without
    retooling your on-premise infrastructure and applications

We plan to share some pearls of wisdom on the challenges organizations are facing with object storage in the cloud from a vendor-neutral, SNIA perspective. If you need a firm background on cloud object storage before September 26th, I encourage you to watch the SNIA Cloud on-demand webcast, “Cloud Object Storage 101.” It will provide you with a foundation to get even more out of this upcoming webcast.

I hope you will join us on September 26th. Register now to save your spot.

Security and Privacy in the Cloud

When it comes to the cloud, security is always a topic for discussion. Standards organizations like SNIA are in the vanguard of describing cloud concepts and usage, and (as you might expect) are leading on how and where security fits in this new world of dispersed and publicly stored and managed data. On July 20th, the SNIA Cloud Storage Initiative is hosting a live webcast “The State of Cloud Security.” In this webcast, I will be joined by SNIA experts Eric Hibbard and Mark Carlson who will take us through a discussion of existing cloud and emerging technologies, such as the Internet of Things (IoT), Analytics & Big Data, and more, and explain how we’re describing and solving the significant security concerns these technologies are creating. They will discuss emerging ISO/IEC standards, SLA frameworks and security and privacy certifications. This webcast will be of interest to managers and acquirers of cloud storage (whether internal or external), and developers of private and public cloud solutions who want to know more about security and privacy in the cloud.

Topics covered will include:

  • Summary of the standards developing organization (SDO) activities:
    • Work on cloud concepts, Cloud Data Management Interface (CDMI), an SLA framework, and cloud security and privacy
  • Securing the Cloud Supply Chain:
    • Outsourcing and cloud security, Cloud Certifications (FedRAMP, CSA STAR)
  • Emerging & Related Technologies:
    • Virtualization/Containers, Federation, Big Data/Analytics in the Cloud, IoT and the Cloud

Register today. We hope to see you on July 20th where Eric, Mark and I will be ready to answer your cloud security questions.

Learn How to Develop Interoperable Cloud Encryption and Access Control

SNIA Cloud is hosting a live webcast on December 20th, “Developing Interoperable Cloud Encryption and Access Control,” to discuss and demonstrate encrypted objects and delegated access control. For the data protection needs of sharing health and other data across different cloud services, this webcast will explore the capabilities of the Cloud Data Management Interface (CDMI) in addressing these requirements and show implementations of CDMI extensions for a health care example.

See it in action! This webcast will include a demonstration by Peter van Liesdonk of Philips who will share the results of testing at the SDC 2016 Cloud Plugfest for Encrypted Objects and Delegated Access Control extensions to CDMI 1.1.1.

You’ll will see and learn:

  • New CDMI features (Encrypted Objects and Delegated Access Control)
  • Implementation experiences with new features
  • A live demo of a healthcare-based example

Register today. My colleagues, Peter van Liesdonk, David Slik and I will be on-hand to answer any questions you may have. We hope to see you there.


The Next Step for Containers: Best Practices and Data Management Services

In our first SNIA Cloud webcast on containers, we provided a solid foundation on what containers are, container storage challenges and Docker. If you missed the live event, it’s now available on-demand. I encourage you to check it out, as well as our webcast Q&A blog.

So now that we have set the stage and you’ve become acquainted with basic container technologies and the associated storage challenges in supporting applications running within containers in production, we will be back on December 7th. This time we will take a deeper dive into what differentiates this technology from what you are used to with virtual machines. Containers can both complement virtual machines and also replace them, as they promise the ability to scale exponentially higher. They can easily be ported from one physical server to another or to one platform—such as on-premise—to another—such as public cloud providers like Amazon AWS.

At our December 7th webcast, “Containers: Best Practices and Data Management Services,” we’ll explore container best practices to address the various challenges around networking, security and logging. We’ll also look at what types of applications more easily lend themselves to a microservice architecture versus which applications may require additional investments to refactor/re-architect to take advantage of microservices.

On December 7th, we’ll be on hand to answer your questions on the spot. I encourage you to register today. We hope you can attend!

Containers: No Shortage of Interest or Questions

Based on record-breaking registration and attendance at our recent SNIA Cloud webcast, Intro to Containers, Container Storage and Docker, It’s clear that containers is a hot topic that folks want to learn more about – especially from a vendor-neutral authority like SNIA. If you missed the live event, it’s now available on-demand together with the webcast slides.

We were bombarded with questions at the live webcast and we ran out of time before we could answer them all, so as promised, here are answers from our expert presenters, Chad Thibodeau and Keith Hudgins. Oh, and please don’t forget to register for part two of this webcast, Containers: Best Practices and Data Management Services, on December 7, 2016.

Q: Would you please highlight key challenges a company may face to move from a hypervisor to container environment?

CT: The main challenge that gets raised in moving from virtual machines to containers is around security as when deployed on bare-metal, all of the containers share the core operating system. However, there are arguments that containers can still be effectively isolated.

KH: Primarily paring down your applications to their minimum running requirements. This can be quite difficult with long-entrenched legacy applications!

Q: With a VM you allocate a finite amount of vCPU and RAM, with a high degree of confidence that those resources will be available to whatever workload is running in the VM. Is that also true of containers – does (or can) the workload get a guaranteed allocation of CPU and memory resources?

CT: Keith, I’ll let you address this one from the application microservice; from the storage side, an SLA or Quality-of-Service can be defined for a container volume if the storage provider offers this capability.

KH: By default, you don’t allocate CPU or ram availability. Most containers are small enough that it’s not a consideration. However, if you need to specify priority, we have a method to do that. Please review the docs here.

Q: Where are microservices most useful? Are there certain environments where they are more likely to be deployed & which verticals or type of solutions/apps will see more benefit?

CT: Microservices can apply to applications within most verticals; for financials it was mentioned that Goldman Sachs is planning on containerizing 90% of their existing applications to web-service such as Netflix. Some of the determining factors are whether the application(s) would benefit from what container technology provides such as rapid deployment, lightweight, portability, and the ability to scale beyond typical monolithic applications.

KH: Microservices are most useful with network-facing applications that don’t require heavy transactional control. Note that it *is* possible to build transactional microservices, but the best practices on that route hasn’t been optimized yet.

Q: What OS version / Hypervisor, support containerization, are working towards cutting the “noisy neighbor” issue?

CT: Containers are supported by both MS Windows and Linux operating systems. The specific version of Linux OS will be more dependent upon the level of capabilities included (Keith, more your area) and MS Windows Server 2016 is the first release of Windows with container (Docker) support.

KH: Docker supports running containers under Windows and Linux kernels. We don’t care whether it’s on metal or virtualized. It’s possible to set affinity groups in a production Docker installation to help manage noisy neighbor issues, but note that fundamentally Docker is NOT a multi-tenant system.

Q: What is “stateful database”? How does it differ from regular databases?

CT: Most databases are stateful such as Oracle, MySQL, Cassandra, MongoDB or Redis. The confusion may be around the Gartner quote which stated “Stateful Database Applications” in which they simply meant that databases are examples of stateful applications.

KH: Any database is by definition stateful. A “stateless” container is one that is running a process that doesn’t store persistent data to disk. This could be a caching system, web application server, load balancer, queue runner, or pretty much any component that doesn’t need to store data. Everything else is “stateful” and needs some way to shove that data into a reliable datastore.

Q: What factors should be considered when choosing between containers and virtual servers for a given project/use case?

CT: The driving factors for container deployments are: portability, minimal footprint (low overhead since no hypervisor or guest OS), rapid provisioning and de-commissioning, scalability and largely open-source based. If any (or all) of these are deemed valuable to you, then you should consider container deployment technology.

KH: That’s a very broad question! It helps to understand that a container is simply a wrapper around one process that is running on a container host. So it’d be one database service, or one web app server, for example. If you can break up your application into a bunch of these single processes and chain those processes together via networking (DB serves data through the network layer to your cache, which supplies the web app, which is behind the load balancer, etc) then it’s a great candidate for containerization.

Q: Sounds like a lightweight hypervisor?

CT: Containers have been compared to virtual machines as a “lightweight VM”; however, there are distinctions mostly around the fact that the hardware resources are not virtualized for containers, but rather the application is abstracted.

KH: That’s not a bad way to start thinking about it. However, you don’t have a second kernel underneath the hypervisor, so there’s no hardware abstraction. Also, in general you don’t want to run a full OS stack per container, just what you need for the application. That way your containers are lean and efficient.

Q: So is there a practical limit to the number of users you need to have for an app in order for containers/microservices to be preferable vs. traditional apps?

CT: Not necessarily. It is more about what you are trying to achieve with the application and the requirements you have around things like: platform agnostic, portability, ease-of-deployment, scalability, etc. But I wouldn’t put a hard number on when containers make more sense over virtual machines or bare-metal deployments for that matter.

KH: Nope! Microservices is far more about making it easier to build and maintain your applications than it is about scaling. Like anything, you can over-abstract your application design and go extra silly with it, but it’s fundamentally about a better way of managing your applications’ lifecycle than it is about how many users you can push through the pipe.

Q: So is graph and memory the same thing?

CT: Keith, I’ll let you address this one.

KH: Nope. Graph refers to our copy-on-write storage for images at runtime. Our docs can explain it way better than I can in a Q&A session. Look here for more info.

Q: Similar to the Docker Container Networking, are there any specific efforts going on around Docker Storage? For example, are you (or will you be) building any products to support features that you mentioned (such as ‘Storage vMotion’ like capabilities)?

CT: Keith, I’ll let you address this one. However, there are initiatives and activities on the storage side around providing vMotion like capabilities for the data and application state.

KH: It’s always a possibility. There’s nothing I can say right now, but stay tuned.

Q: Let me shift gear, here, where does containerization work with NFV, and how should one correlate to the ask of Telco provider(s)?

CT: Keith, I’ll let you address this one–should be right up your alley.

KH: While this webinar is fundamentally about storage technologies, Docker does have a very broad ecosystem of network partners. NFV is a very broad topic and can’t easily be covered in one quick bite, but there are definitely efforts using Docker as both an enablement technology for NFV, as well as integrating Docker’s built-in networking capabilities in an NFV scope for application delivery.

Q: It would be helpful to circle back at the end and summarize what is Open Source and what is a commercial product, I’m trying to grasp what you miss out on by staying just Open Source. I know that excludes the Universal Control Plane but I don’t yet see what UCP delivers, what its USP is.

CT: Keith, I’ll let you address this one–should be right up your alley.

KH: UCP is the only unique commercial component of Docker. It combines a web-based GUI with role-based access control (RBAC) to make it easier to control security and access to Docker components in a production environment. We do maintain a separate codebase for our commercially supported Engine and Registry, but that’s mainly done to maintain a more stable release, with critical patches backported from the upstream open source projects. Fundamentally, CS Engine and DTR are the same product as their open source upstreams, only on a slower, more stable release cycle. Click here for an overview, and links to some more detailed information on what’s involved in our commercial products:

Q: Is there demand for concurrent access, across container hosts, to persistent data? If so, what are those use case scenarios?

CT: Yes, actually if you think about a micro-service architecture, you will most likely have many containers accessing a common set of container data volumes simultaneously. This is exactly the reason for persistent storage–if the containers running the application services get migrated or moved to other physical nodes, they need to maintain access to their respective container data volumes in many cases.

KH: What a great question! That demand is small, but there. In most cases, persistent data is maintained concurrently through clustering processes (database replication, object storage, etc) but there are some edge cases for large file processing (rendering, big data needs) where there are some asks for that capability.

Q: is it possible to run windows applications on Linux container and vice versa?

CT: To my knowledge, you should be able to run Linux applications within the recently announced Windows Server 2016 supported containers (see article here), but you can’t run Windows applications within Linux containers.

KH: No. A container is essentially a process running in a named concurrency group under the kernel. Therefore, you need a Linux kernel to run Linux processes, and likewise for Windows. It will be possible to run Windows and Linux containers under the same management umbrella very soon. We’re waiting on some network features to roll out in Windows Server 2016 SP1 for that capability.

Q: is it a good idea to run legacy apps in a container? Exactly what is the relation between microservices and containers? Container-like technology used to be popular in various UNIX OSes. What is different now? is the best choice a microservice in a container & spin multiple instantiations fast?

CT: Keith, I’ll let you address this one–should be right up your alley.

KH: Container technology is still popular in several UNIX OSes. Under the hood, a Docker Linux container isn’t very different from a Solaris Zone. The difference is primarily the lifecycle tools to build and maintain your containers from both the developer and operations sides. The newer generation of container runtimes is simply much easier to use than older methods. From a Docker perspective: Docker Hub, the ease of use of the ‘Docker’ CLI command tools, and clustering capabilities in Engine are the main differences. As always, design your architecture to fit your team, user, and application needs. However, if you do want to use a microservices approach, maintaining each part of your application stack as a suite of microservices does make running them widely parallel a strong approach.

Q: Is a micro service self-contained with respect to data requirements. Can a service that depends on an external datasource be a micro service?

CT: A micro service is by definition self-contained; however, it also would typically connect to one or more container data volumes. Regarding accessing external data sources, not exactly sure what is meant here, but the micro services can be running on one physical server with the container data volumes being created and managed on a separate DAS/SAN/NAS storage platform.

KH: Yes, absolutely. An API broker for an external, legacy datastore is a good example of a microservice.

Q: How are container images qualified so that they can be trusted for automated pulls?

CT: Keith, I’ll let you address this one–should be right up your alley. I believe that there is NOT a vetting or certification process done by Docker when posting to either the public Hub or to a trusted registry. This would be the responsibility of the container image developer.

KH: In a few ways. First, containers are rarely built from scratch. They are normally built from base images released by trusted providers like Microsoft, Ubuntu, Red Hat, etc. First you should prove trust in that base image through similar methods as you would a VM image. In a Docker Datacenter install, a user with Admin rights can then bring those base images into Docker Trusted Registry (DTR) and then also do a review of internal images built on top of that base before blessing them to go into production. There are also 3rd party security scanning technologies you can use, should that be a concern.

Q: For stateless applications, can Docker help apply updates to the application without taking a downtime? For example, a container is running version n of an application and version n+1 needs to be deployed without causing a downtime to users, could one spin a new container with version n+1 of the application and deploy it?

CT: If the application is truly stateless, then it shouldn’t matter if they are torn down and restarted on another physical server/node to allow the application of a new patch or OS update on the original node. However, this would need to be correctly architected.

KH: Yes. Using Docker Engine in Swarm mode, we provide a command ‘Docker service update’ to do exactly that. Check the docs.

Q: Flocker vs. Convoy vs. others – could you talk about these interfaces and their adoption?

CT: ClusterHQ (Flocker) has developed a generic storage volume plugin that they then provided back to the Docker community to incorporate the Docker engine. I’m not very familiar with Convoy, but it appears to be a Rancher-developed storage plugin that they have made available as open source, but it is not part of the Docker release.

KH: Flocker and Convoy are brokerage-type volume drivers that have the capability to connect with several storage backends. Each has its own API to talk to and manage volumes under the hood. It’s also possible to integrate directly with Docker’s volume API. If you’re mainly interested in integrating purely with Docker Engine, a direct Docker Volume API plugin is the best approach. However, both Flocker and Convoy provide some ease-of-use features and capabilities that might make it attractive to go their routes. Volume API docs are here.

Q: Does the link in communication between different containers that run microservices incur the very load we are trying to escape from monolithic approach?

CT: Keith, I’ll let you address this one–should be right up your alley.

KH: That’s a very philosophical question! I’d argue that using modern API methods like REST over HTTP is so lightweight that the distributed approach makes more sense.

Q: Docker Swarm?

CT: Keith, I’ll let you address this one.

KH: Swarm is our clustering technology to chain together several Docker Engine hosts into one big cluster. Prior to Engine 1.12, it was a standalone product. After 1.12, we added SwarmKit into Engine to make building and maintaining swarms much easier. For more info, check out old Swarm docs and new Swarm docs.

Q: Do the applications need to be re-written/revised to take advantage of Container approach?

CT: Most legacy or monolithic applications will need to be refactored to best take advantage of a micro-service architecture.

KH: Typically, yes. Web applications are already built in a distributed way, so they’re the easiest to convert.

Q: Do microservices implement Unikernels?

CT: Keith, I’ll let you also address this. My take: Containers run microservices and leverage the entire OS (Linux kernel and all of its libraries, drivers, etc.). A unikernel is a very small and minimalistic kernel that doesn’t contain the additional bloat of the full kernel and therefore, is considered to run that much faster and leaner. Docker acquired a unikernels company and will most likely provide support for running microservices with unikernels and how they may provide a container like wrapper.

KH: Not directly. Unikernels are a new method to run arbitrary runtimes under a single kernel. Docker is currently doing some early work with microkernel technology to improve containers, but it’s not rolled into core Engine yet.

Q: Can a Docker container run on bare metal instead of a host OS directly. If yes, what benefits does this approach provide?

CT: A Docker container requires a host OS to run; however, when we refer to “bare-metal” we are referring to a “non-virtualized server”. The key benefit this provides is that you don’t waste efficiencies by eliminating the hypervisor and guest OS and it is also much more manageable as with the hypervisor and guest OS scenario, you have to manage and maintain all of the VMs that may have different guest OS’s and versions.

KH: No. A Docker container needs Docker Engine to run, so you’ll need to run Engine under a supported OS on the metal. Running Engine on a physical server means your containers will get full “on the iron” IO, since there’s no hypervisor abstraction layer between your container and the hardware it’s running on.

Q: Are packaged software companies like Oracle moving to containerization?

CT: Oracle is developing product offerings that are containerized applications. They would be best able to address your question.

KH: Here is Oracle’s GitHub repository of their official Docker containers and here is their official images in Docker Hub.

See? I told you there was no shortage of questions! If you still have one, please comment in this blog below and we’ll get back to you as soon as we can. Follow us on Twitter @SNIACloud to stay up-to-date on what SNIA Cloud is doing with containers. And don’t forget to register for part two of this webcast, Containers: Best Practices and Data Services, on December 7th. We hope to see you there!



Cloud Object Storage – You’ve Got Questions, We’ve Got Answers

The SNIA Cloud Storage Initiative hosted a live Webcast “Cloud Object Storage 101.” Like any “101” type course, there were a lot of good questions. Here they all are – with our answers. If you have additional questions, please let us know by commenting on this blog.

Q. How do you envision the new role of tape (LTO) in this unstructured data growth?

A. Exactly the same way that tape has always played a part; it’s the storage medium that requires no power to store cold data and is cheap per bit. Although it has a limited shelf life, and although we believe that flash will eventually replace it, it still has a secure & growing foreseeable future.

Q. What are your thoughts on whether object storage can exist outside the bounds of supporting file systems? Block devices directly storing objects using the key as reference and removing the intervening file system? A hierarchy of objects instead of files?

A. All of these things. Objects can be objects identified by an ID in a flat non-hierarchical structure; or we can impose a hierarchy by key- to objectID translation; or indeed, an object may contain complete file systems or be treated like a block device. There are really no restrictions on how we can build meta data that describes all these things over the bytes of storage that makes up an object.

Q. Can you run write insensitive low latency apps on object storage, ex: virtual machines?

A. Yes. Object storage can be made up of the same stuff as other high performance storage systems; for instance, flash connect via high bandwidth and low latency networks. Or they could even be object stores built over PCIe and NVDIMM.

Q. Is erasure coding (EC) expensive in terms of networking and resources utilization (especially in case of rebuild)?

A. No, that’s one of the advantages of EC. Rebuilds take place by reading data from many disks and writing it to many disks; in traditional RAID rebuilds, the focus is normally on the one disk that’s being rebuilt.

Q. Is there any overhead for small files or object use cases? Do you have a recommended size?

A. Each system will have its own advantages and disadvantages for objects of specific sizes. In general, object stores are designed to store billions of objects, so the number of objects is usually not an issue.

Q. Can you comment on Internet bandwidth limitations on geographically dispersed erasure coded data?

A. Smart caching can make a big difference, but at the end of the day, a geographically EC dispersed object store won’t be faster than a local store. You can’t beat the speed of light.

Q. The suppliers all claim easy exit strategies from their systems. If we were to use one of the on-premise solutions such as ECS or Cleversafe, and then down the road decide to move off-premise, is the migration/egress typically as easy as claimed?

A. In general, any proprietary interface might lock you in. The SNIA’s CDMI is vendor neutral, and supported by a number of vendors. Amazon’s S3 is a popular and common interface. Ultimately, vendors want your data on their systems – and that means making it easy to get the data from a competing vendor’s system; lock-in is not what vendors want. Talk to your vendor and ask for other users’ experiences to get confirmation of their claims.

Q. Based on factual information, where are you seeing the most common use cases for Object Storage?

A. There are many, and each vendor of cloud storage has particular markets. Backup is a common case, as are systems in the healthcare space that treat data such as scans and X-rays as objects.

Q. NAS filers only scale up not out. They are hard to manage at scale. Why use them anymore?

A. There are many NAS systems that scale out as well as up. NFSv4 support high degrees of scale out and there are file systems like Gluster that provide very large-scale solutions indeed, into the multi-petabyte range.

Q. Are there any specific uses cases to avoid when considering object storage?

A. Yes. Many legacy applications will not generate any savings or gains if moved to object storage.

Q. Would you agree with industry statements that 80% of all data written today will NEVER be accessed again; and that we just don’t know WHICH 20% will be read again?

A. Yes to the first part, and no to the second. Knowing which 80% is cold is the trick. The industry is developing smart ways of analyzing data to help with the issue of ensuring cached data is hot data, and that cold data is placed correctly first time around.

Q. Is there also the possibility to bring “compliance” in the object storage? (thinking about banking, medical and other sensible data that needs to be tracked, retention, etc…)

A. Yes. Many object storage vendors provide software to do this.


Containers, Docker and Storage: An Introduction

Containers are the latest in what are new and innovative ways of packaging, managing and deploying distributed applications. On October 6th, the SNIA Cloud Storage Initiative will host a live webcast, “Intro to Containers, Container Storage Challenges and Docker.” Together with our guest speaker from Docker, Keith Hudgins, we’ll begin by introducing the concept of containers. You’ll learn what they are and the advantages they bring illustrated by use cases, why you might want to consider them as an app deployment model, and how they differ from VMs or bare metal deployment environments.

We’ll follow up with a look at what is required from a storage perspective, specifically when supporting stateful applications, using Docker, one of the leading software containerization platforms that provides a lightweight, open and secure environment for the deployment and management of containers. Finally, we’ll round out our Docker introduction by presenting a few key takeaways from DockerCon, the industry-leading event for makers and operators of distributed applications built on Docker, that recently took place in Seattle in June of this year.

Join us for this discussion on:

  • Application deployment history
  • Containers vs. virtual machines vs. bare metal
  • Factors driving containers and common use cases
  • Storage ecosystem and features
  • Container storage table stakes (focus on Enterprise-class storage services)
  • Introduction to Docker
  • Key takeaways from DockerCon 2016

This event is live, so we’ll be on hand to answer your questions. Please register today. We hope to see you on Oct. 6th!

Q&A – OpenStack Mitaka and Data Protection

At our recent SNIA Webcast “Data Protection and OpenStack Mitaka,” Ben Swartzlander, Project Team Lead OpenStack Manila (NetApp), and Dr. Sam Fineberg, Distinguished Technologist (HPE), provided terrific insight into data protection capabilities surrounding OpenStack. If you missed the Webcast, I encourage you to watch it on-demand at your convenience. We did not have time to get to all of out attendees’ questions during the live event, so as promised, here are answers to the questions we received.

Q. Why are there NFS drivers for Cinder?

 A. It’s fairly common in the virtualization world to store virtual disks as files in filesystems. NFS is widely used to connect hypervisors to storage arrays for the purpose of storing virtual disks, which is Cinder’s main purpose.

 Q. What does “crash-consistent” mean?

 A. It means that data on disk is what would be there is the system “crashed” at that point in time. In other words, the data reflects the order of the writes, and if any writes are lost, they are the most recent writes. To avoid losing data with a crash consistent snapshot, one must force all recently written data and metadata to be flushed to disk prior to snapshotting, and prevent further changes during the snapshot operation.

Q. How do you recover from a Cinder replication failover?

 A. The system will continue to function after the failover, however, there is currently no mechanism to “fail-back” or “re-replicate” the volumes. This function is currently in development, and the OpenStack community will have a solution in a future release.

 Q. What is a Cinder volume type?

 A. Volume types are administrator-defined “menu choices” that users can select when creating new volumes. They contain hidden metadata, in the cinder.conf file, which Cinder uses to decide where to place them at creation time, and which drivers to use to configure them when created.

 Q. Can you replicate when multiple Cinder backends are in use?

 A. Yes

 Q. What makes a Cinder “backup” different from a Cinder “snapshot”?

 A. Snapshots are used for preserving the state of a volume from changes, allowing recovery from software or user errors, and also allowing a volume to remain stable long enough for it to be backed up. Snapshots are also very efficient to create, since many devices can create them without copying any data. However, snapshots are local to the primary data and typically have no additional protection from hardware failures. In other words, the snapshot is stored on the same storage devices and typically shares disk blocks with the original volume.

Backups are stored in a neutral format which can be restored anywhere and typically on separate (possibly remote) hardware, making them ideal for recovery from hardware failures.

 Q. Can you explain what “share types” are and how they work?

 A. They are Manila’s version of Cinder’s volume types. One key difference is that some of the metadata about them is not hidden and visible to end users. Certain APIs work with shares of types that have specific capabilities.

 Q. What’s the difference between Cinder’s multi-attached and Manila’s shared file system?

A. Multi-attached Cinder volumes require cluster-aware filesystems or similar technology to be used on top of them. Ordinary file systems cannot handle multi-attachment and will corrupt data quickly if attached more than one system. Therefore cinder’s multi-attach mechanism is only intended for fiesystems or database software that is specifically designed to use it.

Manilla’s shared filesystems use industry standard network protocols, like NFS and SMB, to provide filesystems to arbitrary numbers of clients where shared access is a fundamental part of the design.

 Q. Is it true that failover is automatic?

 A. No. Failover is not automatic, for Cinder or Manila

 Q. Follow-up on failure, my question was for the array-loss scenario described in the Block discussion. Once the admin decides the array has failed, does it need to perform failover on a “VM-by-VM basis’? How does the VM know to re-attach to another Fabric, etc.?

A. Failover is all at once, but VMs do need to be reattached one at a time.

 Q. What about Cinder? Is unified object storage on SHV server the future of storage?

 A. This is a matter of opinion. We can’t give an unbiased response.

 Q. What about a “global file share/file system view” of a lot of Manila “file shares” (i.e. a scalable global name space…)

 A. Shares have disjoint namespaces intentionally. This allows Manila to provide a simple interface which works with lots of implementations. A single large namespace could be more valuable but would preclude many implementations.



Cloud Storage: Solving Interoperability Challenges

Cloud storage has transformed the storage industry, however interoperability challenges that were overlooked during the initial stages of growth are now emerging as front and center issues. I hope you will join us on July 19th for our live Webcast, “Cloud Storage: Solving Interoperability Challenges,” to learn the major challenges facing the use of businesses services from multiple cloud providers and moving data from one cloud provider to another.

CSI Webcast graphic

We’ll discuss how the SNIA Cloud Data Management Interface standard (CDMI) addresses these challenges by offering data and metadata portability between clouds and explain how the SNIA CDMI Conformance Test Program helps cloud storage providers achieve CDMI conformance.

Join us on July 19th to learn:

  • Critical challenges that the cloud storage industry is facing
  • Issues in a multi-cloud API environment
  • Addressing cloud storage interoperability challenges
  • How the CDMI standard works
  • Benefits of CDMI conformance testing
  • Benefits for end user companies

You can register today. We look forward to seeing you on July 19th.