Hi, good evening. Thank you for taking some time out to listen to my discussion about software NAS with open stack My name is Suki Bains and I work for my genetics and before I really talk about What our solution is for open stack a quick few words about our company?  We're based out of Mountain View We're about 45 strong today and what we've built is a software defined storage solution That's can sit on open stack as well as other infrastructures and the reason we built this is because there's a perceived issues with current enterprise storage solutions around scalability security and the complexity and more important the cost of what it takes to actually provision file services To a distributed or even to a large-scale infrastructure So given those kind of issues at hand. What's our solution for that? So our solution is actually called the measure net it's cloud storage platform as the name suggests It's been designed from the ground up for use with Cloud whether it's public cloud private cloud or even a hybrid of those But it is designed from the ground up to you be used with cloud As I said, we are a software defined storage platform So we don't actually store any data ourselves So we do look to an object store as a target repository for storing data So in the context of open stack, that's going to be swift and possibly even safe So given these two solutions together enables us to provide File services to what we see as two very good use cases. So the first one is we call elastic mass So if you look at this as being an in cloud file system So if you have VM applications running and you want to provision some Temporary or even permanent storage to those applications We can allow you to do that Because we're a software defined solution So you can actually spin us up as a virtual filer and you can present services to your applications It can consume those services and if you want to then end those services because maybe you were doing some kind of service Like a rendering as a service where you want to spin up some virtual resources Do some processing and then blow everything away. You can do that You can't do that with a physical server so we'll allow you to spin up as many virtual filers as you want Another use case that we see quite often is NAS consolidation A lot of our customers have a very widely distributed NAS infrastructure They have so many filers, you know, it's not just about server sprawl is also filer sprawl now How do I manage these hundreds and thousands of small NAS filers? So there's a desire to try and collapse that onto a smaller footprint Now one thing that we're able to do is to actually use an object store and present Data to an endpoint user and still maintain an acceptable level of service So the end user experience is like they're using data locally. So how do we do this? We have a totally different architecture We're not a monolithic storage platform that you see today You see commonplace with like CMC in that app. We don't have the architecture We've actually adopted a distributed architecture where we have three core components We have our machine analytics virtual filer which sits in VM space We also have some endpoint agents to do some heavy lifting at the place where data is ingested and used and Finally, there's an object store now. We don't provide that we look to our customers to provide that So the endpoint agent like I said does a lot of the heavy lifting in how we process your data So if you look at when you're ingesting data when you're writing stuff out, we will do in-stream chunking and hashing That hashing is used to deliver functions like the doop. We'll also do encryption and compression So all that is being done at the edge Not at the core again with a monolithic storage solution You don't have enough horsepower to do that We want to use all the CPU the memory that's available at the edge to do all that processing for you On the read side you're going to benefit tremendously from all the read caching we do the caching of the directory So the idea is the end user experience of using our solution is that they're using local storage Even though the data could be actually living a long distance away in some kind of an object store So our virtual filer does the core storage function So it's a at the heart of what we have is a distributed file system And we provide metadata services and one of the things that we do in our solution We split the metadata and the data flows and we'll talk about that in a few minutes We also do global lock management So we have a great solution for collaboration if you want to share data across the globe will allow you to do that and Yet maintain consistency all the way through so we have a very strong consistency model with what we do On top of that we'll use your existing security infrastructure to do things like authentication and ensure that the user has rights to Access a file that they're trying to get hold of and then we run some other services like web clients and proxy services Within that core function for the virtual filer Then on top of that as you'd expect you want to have things like snapshots and disaster recovery as core data management functions within that virtual filer and The last piece of the solution is the object store which again is customer provided But if you don't know about object store, but basically object storage is the next wave of storage It provides things like scalability at up to the petabyte scale and beyond Itself healing it's got built-in replication policies It allows you to reduce the cost of Deploying storage and also reduces the effort that's required to actually manage storage And it's very easy to configure multiple levels of nines of availability with an object store So how does all this work in practice? Like I said, we do actually split out the Metadata and the data piece itself. So once we deploy our endpoint agent on your endpoint devices now the endpoint device could be Tablet it could be an iPhone it could be a laptop workstation or server We don't really care. It's all an endpoint device that's going to consume some form of file services now The metadata is actually stored on our virtual Filer that sits in VM space. So that's where all the encryption keys are held and we've got a very strong security model We make sure the encryption keys don't really coexist in the object store. We keep the two separate So the data plane is really where the client Starts to do IO to the object store to get the data. They want so how does it work in practice? So let's take a sequence of events that would happen. So a client is going to request a read or a write Every single time a file is requested. We would always go and talk to our Virtual filer the virtual filer will first of all do the authentication of the user Make sure they have rights to access that file and then hand off signed URAs so they can go away and actually Find where that object is within the cloud Because the agent doesn't really know where its data is stored All that is actually stored within the virtual filer so once we hand off the signed URLs to the MagFest agent that will then go into session with the object store So we're essentially out of the data path as soon as the the agent has those keys and the signed URLs He's able to go away and collect the chunks from the object store and Reconstitute that file and start using it Now we actually gave the agent a 15 minute lease on that file So he's free to go away and do IO against that object at will for the next 15 minutes After that it expires now the reason we've done this is that we believe again in security if an endpoint device is lost Within 15 minutes. No one can get access to the data because your keys have expired So again if you think about the edge usage case scenario with laptops iPhones and the rest of it We can make sure that your your data is secure So that's what it does. How do you deploy it? So this all sits as I said in VM space So a typical deployment scenario is you're going to have a single hypervisor hosting some of our modules. We don't Depending on what you want to deploy we will spin up separate VMs to provide that function and again It's not always convenient to have a failure domain like this So you may want to have a second hypervisor where you can actually design and build out HA and ER type solutions as well So this actually runs on Amazon EC to VMware and we're going to very soon have support for OpenStack Nova as well We've got ESX running on Nova in the labs We have some work to do in KVM But we soon expect to have that available as a platform that we can actually run our virtual file around So it always exists within a VM infrastructure So what's the use case for for OpenStack? So if some of you are playing with OpenStack today, you probably already are using object storage with Swift by default if it's enabled If it's enabled OpenStack, we'll try and use it as the repository for glance so How can we change this and why do we want to change this and bring benefit to you? Well, what we say is well, let's slip in our virtual filer Now the controller which actually is hosting glance is still doing native rest communication to the object store through our agent However, what we have done now is we've actually presented an NFS mount point to glance a glance is now longer using Swift glance thinks it's using an NFS mount and as soon as you have an NFS mount We can start to share that with other resources. So you may have some other OpenStack Installations that have their own glance image or their own glance instance So we could actually have a common repository for all of your glance instances and that common repository is going to be D-duped so we can make sure you're efficiently using your storage resources or D-duping all of your glance images But as it's an NFS mount you can also mount it to a Linux server In fact, we're actually a distributed file system and we could actually even mount that to a Windows server So you can start to share that data now again using the basic Swift object store is difficult for you to get visibility of what's in there And the only way you can do that is with glance We're giving you the ability to use legacy access methods the methods that you're used to to access your data across different different platforms So once you're doing this Using Swift as a back-end repository for your data Why not look at how you can use that to deploy file services and other parts of infrastructure home directories for end users Talked about the in-cloud file system So if you're going to have temporary workloads that you need to provision temporary Storage services to we can do that as well Active archive is another great use case for us and also backup as well Now again, we are about giving choice. So we're going to give you the ability to have Data presented in SIFs and NFS like access methods across a multitude of different endpoints Tablets servers all of it is really is one file system which you can present everywhere and on that theme of choices we also want to give you the choice of Looking at other object stores. So we actually support a whole range of object stores both public private Commercial not or even the the the the free ones as well So you've got the choice to decide how you want to deploy your file services We're essentially we're an abstraction layer that sits on top of your object store and allows you to then provision up SIFs in NFS So this may look like a busy and complicated slide But one thing I will say why not try to see how this could work for you Have a free demo and a free trial of our software see how you can make it work for Your own OpenStack installation serve up services to to glance and then see how you can grow that within your In your environment further applications So normally I would actually ask you any questions This is not the best platform for asking questions So what I'd urge is come across to our stand enjoy a beer Ask all the questions you want to ask and we can give you a bit more detail about how we can allow you to use OpenStack Swift as A platform providing for providing NFS and SIF file services within your infrastructure at a very low cost point Thank you very much


This study found that the COVID-19 pandemic had a significant impact on the utilization of primary health care services in Yinchuan, Ningxia, China. Specifically, there was a decrease in the number of outpatient visits per day, as well as an increase in the cost of each visit. Additionally, the study showed that the decline in outpatient visits was more pronounced among people over the age of 45, while the rebound was stronger among those under 45. Furthermore, the study also found that the number of outpatient visits was negatively correlated with the number of recent COVID-19 cases in the area.