 Hello everyone. I'm Debiko, senior engineering major. I'm from Taiwan so I'm so glad to be here because I joined the last time in Detroit but this time more people than there so I tried my best to share what's the longest and how long it works and the current status and the future plan okay okay so I will talk about what's a long home and the current future list and about the community momentum at the moment and the story and roadmap of course the most important part is release so I'll talk a little bit about release what we have right now and by this end of year and inside the long home I will also talk about the control plan, data plan and about the data service, nature, backup, repair car, rebuilding and of course out of cost this recovery and mostly important part when you do a long home and when doing the upgrading long home and everyone will care about your service will get an impact so also we'll explain a little bit about about in-life migration and this one is what's next so let's go over one by one okay so probably some of you already use a long home already and so basically long home is a highly available software device storage system for precision balling especially for our Kubernetes for sure and it's a light way because people come to our kiosk always always ask how to install a long home and some of you bet let's say a long home is easy to set up so this is the most primary attraction items for users to start using long home and also we provide a very simple UI so you can get understand how the volumes work in your Kubernetes cluster and of course it's a precision balling so it's a precision balling solution for any kind of Kubernetes we mentioned some are destroy version and destroy type in our documentation they mean those are distro are distro actually verify in our daily regression we have a daily question to verify each maintain support branch for now master branch for sure for the upcoming 1.5 and 1.4 and 1.3 we always wonder regression every day and the next one storage agnostic because long home want to make it easy to use all those persistent for a replica your data will be on the host of fire system we try to simulate the long home disk on the fire system so they mean you can prepare your use on your root fire system if you want to try but for your production we have a best practice so you need have a dedicated partition for each long disk a more detail you can check the documentation and the next one like I say we not just provide an in-class capability for volume we also want to provide out of cluster capability for the backup and restore so let me you can set up the the external backup target or we call it backup store we support NFS and S3 interface so you can back out your volume to external backup target then restore to other cluster and this one alone does not have any external database for their status for his status persistent we just rely on Kubernetes on native staff customer resource and also all the application implementation way is based on the control plan pattern if you are interested you can take look our repo is a special long-home manager and this one is open source for sure and right now is incubating we try to attract more contribution from the external parties to help us to make long-home grow not just adoption also in contribution so to the girl is the same want to make graduation so need your help special here okay so it is what's the long-home in general and feature list I will not go over all them but I want to say long already provide the primary feature when you want to use your production and especially he verified by different on different component distro like I mentioned document in the our documentation and also for volume part it provide a simple vision you have a better strategy for your space efficiency and he have in-class a snitch up and revert and also he have out-of-class backup and restore and for the volume self also clone and expansion and some people are come especially these two days I come to ask does long-home provide encryption yes we provide encryption based on the Kubernetes secret resource to provide your credential to encrypt your volume and because long-home is the distributed box system so every IO you'll be encrypt over the over over the fly on the fly and also we call it encrypt encryption in transit and at the end you will step into a replicas so it's at rest so it's a by default right now actually we introduce in a 1.2 and for replicas we have a different replicas placement strategy I want to mention cross zone is the billing functionality we can make sure replicas on each known zone so you don't need to worry about the data loads and of course are replicas rebalancing some some people you want a special one long home on public cloud they have some strategy to down up down their notes they want to have a better level better a better balance for their replicas when there are no come back so we also have this kind of capability so this a lot of things so volume Kubernetes and also describing life volume upgrade all kind of things actually in the current long-home version and what I want to mention more is about we also care about user they want to use the some automatic way to control their data so we introduce a one mechanism code recurrent job so recurrent job you can make a recurrent job for your volume or globally have a default return job you can met a snapshot and backup or some type some type of use case they don't really care about a snapshot so we introduce in one fight have a snapshot delete and clean up to save your space so this is recurrent job and want to add more for example in one fight will also have for auto trim is a five season train automatically so it's the I think he's a very useful for user because as a broad storage solution it does not really recognize what's happening on the five system so have auto trim you will be help you to train your five system automatically okay so the last part is about about a volume type as a small and volume type we support a broad volume and five season volume at the moment but I will share more about our plan for a certain interface and as a small is a rewrite only and rewrite many for sure and really many right now become GA in one fall I especially one fall is just released by end of last year and this fall we have a three type of district already verify in our daily regression and I'm 64 also gradually to our GA in one fall so I I want to hear more feedback about the usage so if you have so I think this is a general feature list I want to talk more about the new stuff later okay about long home or momentum and long-home keep growing he's like several years project I would say like a grow with the Kubernetes so right now the github a lot of feedback from the user and also we hear several stories about the adoption adoption in production and I for example payment gateway I just heard these days and also H telecom this kind of scene is very interesting and also some consulting company tried to use a long home build a solution for their customer and user so this quite outstanding impressive and also right now over a war there's about the 83,000 notes running long home right now so we have a pop public mattress is a mattress long home dial you will get the information he's keep growing and over the time star users start to keep upgrading the version to let his one and of course after donate to a CNC if we get a lot of exposure to let the people understand long home try to use okay long story I want to go over quickly from the one three because we start have a new idea after after long home become GA and one one and one two this kind of thing matter the long home grows based on the user's deep end take example from the zero three we start have a external backup store as three and zero six disaster recovery volume happened and one dollar or more volume capability also include and one that one I will start to graduate some experimental features and one that two encryption and also recurring job and how about one three it happened less this year June and we have a Kubernetes we want to met a user not just operate long home from the UI we want to let them use the native way through the customer resource so we introduce the mutation webhook and also the mission webhook and also we have a different type of version V1 beta 1 is before version and later we current versions V1 beta 2 and we want to enforce user to do a migration by themselves so we have a conversion webhook to transit if you have a V1 beta 1 you can correctly use the V1 beta 2 resource directly so no need to do any menu operation and storage network so some users there want to have a separate traffic for their control plan for long control and data plan so we have storage network based on motors so so user can set up their networking have an extra leak to serve for different components in long home and public cloud because the goal for long home is wrong on wrong anywhere including public cloud or on premium so we got some feedback from user they are running on public cloud like Azure or some something else so we want to do something for that especially like upgrade because the public cloud this role upgrades is a little different it's not like no poor and no replacement not in not in place upgrade so want to do something for that and also user care about a cost when they're running on a cloud so they they usually will use the class the auto scheduler auto scare so we do something for that and right now we support it as experimental and in one fight we want to met a class auto scale GA and what was the criteria to met a GA of course testing so we are doing a testing to a three major distro public cloud distro and we want to make sure our our test tree no pace in the in the in this loss distro and space efficient essential perch because people care about a space efficiency so we do a space efficiency essential perch is different from the essential deletion or something you try to delete the first nature next to a volume head so it's a new strategy a special for the user not really care about a snitch up and CSI snitch up of course for you for you sir they can use the long-haul UI they can use the customer resource long customer resource but we also want then use the CSI and CSI have a protocol for the snitch up volume snitch up so user can use a volume snitch up to do the in-class of long-haul volume snitch up and also they can do the out-of-cross the CSI snitch up for the backup for now and back image yeah we talk about volume but why back image a year because some volume will be based on the backing image a special virtual workflow so we want to do something for that and also provide the user can download the back into let me you can is pull your volume as a backing image then download from the website so provide another way to back up a backup strategy because right now we have a backup target because store but you also can download the backing image you found a volume directly so this another way and security come your community amount of control and data plan so you can we use a TRS you can provide your public key and your your your keys so we can do the security commute by this option in depending on your configuration and upgrade pace we try to improve it so after one three I believe if you use the long-haul you will feel an upgrade become faster because we do some filtering and but important thing how about one full a one full is released I remember it's last day of last year so so we do have a lot of outstanding items the first one is train so right now you can train your volume yeah this is very important we got a lot of feedback from users and rewrite many got G we introduce a recovery mechanic to make sure that when share manager is a rewrite many engine if you get it unstable in your cluster when you come back still will will prevent the data loads for the connection so this one already GA a long system itself backup restore and we support the volume bigger restore but some feedback they also want to make the long system pick up every store to keep the current setting so we have that as well right now and nature checks some people asking be asked before does the long-haul have a some way to make sure the data is the integrity these parts and people prefer the wonderful we don't have an integrity we use the revision counter it's the easy way to make sure that everything is working well but too serious you want to make sure the data consistent really and data integrity so we make our basic unit of a volume is essential have a checksum capability so to make sure everything is correct and be road protection we also will leverage the checks on so you just check some to detect your check your snitch up over replicas is incorrect we will try to review for the other health replicas so this is already easy in one full and one dot 25 so everyone know one to 25 have a PSP drop so there's a very critical issue for many project so for long on the same so we try to do that and if you use the Kubernetes version before 124 125 long can support wonderful if you use a one 25 or even after wonderful can support we have a setting you can configure and we can respect that settings to met the correct installation and I'm city for like I say he already passed our internal testing and support bundle enhancement we want to improve on the issue report from the community users and internally we have a spring base development work load and we have a dedicated members every spring to watch and follow the community feedback so this is active but I want to make it efficient so how to collect the support bundle from users the issue will be very important for us and we improve this part in one full and online volume expansion also this is a request from the community user and in one full it's happened and local volume as you know as you know alone provide the volume replication but sometimes use case they user want to rely on application label replication instead of blocks of our volume replication so we think about probably we can support in current architecture provide the local volume to make your replica next to your work load and just one replicas and we call it strict local and for this part it's still the engine communicate with the replica still go over the network stack but we use the you need Domensaki so he said you save a lot of time to gather improve however we have a further plan for that because the current local volume space based on the current architecture but want to do something different in the in a later version okay the important by is one fine you will be happened in June and what's in will happen we will introduce a new data engine right now the data engine current data engines based on ice gauze stack and you have some concern about the performance so I want to do something based on SBDK and this one at least the layer 3 item want to achieve the first one is replication the second snapshot the third one is the degree volume and this is a basket functionality for the volume life cycle and want to make it happen as a experimental so cost auto-scare this one will be congeal and instance major engine replica consolidation if you use a long home you will think about why long home instant major pod series consume a lot of resource because they response for the your volume process however we have a separate instance major for the volume and replicas so people will get confused when especially doing the upgrade because doing upgrade they will become the full instance major parts we want to achieve the life migration to make sure your service without any interruption however this kind of a read our parts will have a default CPU request so user will we are concerned about the request we resource how we consume a lot so in one one fight we try to consolidate instance major engine and replica to one part so they mean when you do in the upgrade the instant major and most there are two parts and also can ensure your volume migration without service down time okay okay like I mentioned auto-train what happened and the other part not just rerun only rewrite many we also support volume training and auto-train okay backing image I mentioned the back image before and back image you you need to operate only two way UI long home UI or long home customer resource but right now we want to do a long does conform to the standard interface so want to rely on the CSI so volume stage how you can do a send way to manage your backing image so these are something different and backup backup store there are still right now support to interface one is the S3 the other one is NFS and we again community is very important they give a lot of feedback for they want to have a CIFS and Ezio I heard about Ezio they want to do some storage tiering for the backup so these two type of block store will support in one fight in Kubernetes train awareness and policy actually we already leverage PDB part disrupted budget for the instant major in the current version already to make sure your body will be safe when do no drain however in our documentation we mentioned user need to is cool some specific parts when they doing the drain operation especially like a CSI stuff or long home web hook component etc and I think we think this is still very tedious for user we want user just like a do the drain operation without any extra consideration right so these part will be automatic happen we will handle we will use a same mechanic in PDB to put that those components new long home volume attachment right now right now long have a lot of logic to understand the body's stage or not because some kind of scenario we will do a auto attachment auto detachment and sometimes you will be conflict with the user operation or wall operation so right now is user imperative way to consider the current status what's the current status but somehow still possible have some corner case happen to mess the attachment going to the wrong current condition so we introduce the new long home volume attachment very similar to the Kubernetes volume attachment but it's led us to better handle a special auto attachment and auto detachment like a recurring job okay recurring job yeah as I say recurring job we have a backup and snapshot and right now have a snapshot delete and clean up I can say one story because some of user run long home with the workload like a database and a special distributed database and their database have a replication they don't really care about a snesha they don't care about number of replicas they just want to use a lot of functionality from long home so this recurring job can make sure you can do something for you this kind of wall or modeling so you can create a default or recurring job or specific recurring job for your specific volume to do the snesha deletion and clean up to clean up your unnecessary specific usage okay so this is one fine and I hope you happen soon right now the target is June so let's expect and long home release and long have a very regular and consistent release cycle for every year we will have a two feature release so this year is one three and one four and this year will be one five and one six and for each feature release we will try to maintain for one year so for each branch there will be three months one patch so you will see for example one three today we just release one three three to include some resilient fix it but we still working on one four two next month and also one five so it's all ongoing even you use a one three or one four you all supported so and we want to fix the issue a special box and and small improvement in the current development for example we developing one the five we were definitely backport to one three and one four to make sure you your user experience is a consistent across the different support branches okay so we talked about the long home plan and roadmap briefly so let's talk about how long walks and long architecture is very straightforward so if you think about it's a request from the TV PR PVC together with your workload and long we recognize rely on the CSI side cut together with the long home so we will create corresponding engine and replica but what's the engine engine you can think about the volume the volume itself together with the volume from in and volume replica is your data so for long home by default default storage costs we will have three replicas for each volume so they mean when you create a volume you will have a one engine for your front end and have a downstream replica three replicas so they mean your replica can be placed on the different nodes or even different disk so when you have a one note down and your part will get rescheduled by Kubernetes so your volume will be immediately up because you still have a replica on the nodes so that's the long home so so back to the left side so they have a control plan like I say Kubernetes control controller CR no other persistent service database so just that's it and data plan data data plan is the volume following together with a volume engine so the current following is the ice car seat target and also volume replicas is a data and body life cycle CSI PV PVC the same always alive with the current protocol and data placement right now long home disk this is a terminology long disk is on the host of fire system so each of the fire system you can create different folder or even specific one point for a specific disk for long home usage but if you just a new beginner you want to try long home you don't need to have separate disk you can dredge just use your Lufa disk to try so this is benefit you want to know about long home to ensure time yep okay so what's actually running inside the long of like a volume from or volume engine this kind of thing so if you talk about I talk about the volume from in is actually we were asked guys ice car seat and color module ice car seat TCP so this is why you need to install an open ice car seat to make sure have ice car seat initiator to connect to the ice car seat target server created by long home for each volume and for volume we use we have our own long home TGT so you were together running with a long-home engine and long engine will have a data server and volume controller the data server will reach we'll get the traffic receive the traffic the IO traffic from the ice car seat target to to write downstream the downstream replicas and modern replicas it can be local next to your wallow or even remote on different nodes so can can again save your data on your host disk and this is best volume like connection relationship but the data plane for each volume and however you can have a following data operation likes nature review coils merge prune purge big up this kind of operation against to your volume and actually this kind of operation is happening happen in replica level because the engine is a phone and replica is the real place for your data placement okay so what I'm talking about is the current stack but how about SPK what we will do and SPK we are very good for while but based on the current resource we try to bail our do our best to make it happen so SPK is a special you are very care about IO performance and your environment have a good resource for this kind of setup so this why I mentioned using the high performance application and he have a concept like a B def bar device you can abstract the B def and the and the string of B def to connect together to make your bar level happen and also you can expose the B def as a remote bar device the protocol you can suppose I got ice car seat and me and me over fabrics and you probably were curious you have ice car seat do we do we want to switch to your current stack to to SPK no we were not because we want to leverage SPI together with a B and E over fabric to get a better performance for this part and also if you talk about long long have a snapshot simple vision this kind of capability how we can happen when we use it in this SPK so we will use a SPK one functionality is called logical volume the logical volume is actually the trend of Snatch up the same as the long home and also he provides in provision and you have a better asynchronous programming for show and memory usage so this is SPK and compare compared to a current architecture of a long home so how you will look like so volume fine will become the ambient over fabric and we need have a initiated for that the good good news is MV and E have a kernel module ready for in native kernel right now so you don't need to do any extra stuff and volume engine we will rely on SPK TGT it's not the long-home TGT D anymore it's SPT TGT and long-home engine will be long-home SPK B def okay so for the volume replica is actually the remote or local logical volume provided by SPK so they mean they can do a following operation Snatch review coalesce merge etc so we try to use the same architecture so when user use a long home they can strictly understand okay the new architecture is actually the same as the current okay so this is the purpose and one five yeah multiple engine SPK target for one fight is be a mental is the primary item I mentioned and one six feature parity to make sure you have a same capability with the current architecture and this is the database and I just want to show up and the rectangle part is the user's kernel space so you can see a left side is the current stack you have several some context which between the user space and then space but the right side there's just a kernel space for file system and then me over February product device other than that old user space so you will get it improved and also based on the SPK design so I will show some numbers about a performance later okay let's go back to see how long work some primary use case like this one is resilient and fail over when you have a pot have a balling and you will be have a replica engine like I say that everything is running right so the same for other workloads you probably have others and this time when you're low somehow in counting not no not ready due to some involuntary situation and your parts will be fail over to other nodes and because your body have a rapicots so you will immediately launch the engine new engine to connect to the old rapicots yep so this this one and what what the scene did not explain here when you are no combat what's happened your fail rapica will get reused so we try to reuse the failure because as possible if he can be reused and if you have some delta change up between the new or healthy rapica we will try to do the delta sink so this is a resilience and fail over and the interesting part I want to share right now we are doing some negative testing in our curve daily regression because right now our testing is all is about a 200 to 250 test case we are trying to do in introduce this kind of test case like a no-down or try to break you see the system to make sure the volume behave correctly so we are doing something automatically okay control plan like I say all the scene running on Copernetics so CSI is a primary interface special for dynamic provision volume so you will talk with a long manager is our control plan to do the other operation so all the persistent stuff will set into a Copernetic API server as a customer resource yeah that's it but except the CSI parking he's the headless right it's not the user interface so user can use the long home UI or even use a long home CR they will go over the long home API but before that I did not describe here we have another layer on top of long-home manager is the Copernetic at the mission web hook so you will make sure the behavior will be sent okay so this is a current implementation and I also got ask some question about the zone yeah long-home have a support for zone for sure so you can make sure your replica can be distributed to each loan and if your zone have some problems you can still have a rape car layer snesha the snesha is is the same we have for each volume we have a snesha chain so for example you have an empty volume and you start to have some data into and you try to do a snesha and when you do a snesha the new modeling head will be created and the old volume head will become snesha one and the same the following operation will be sent so then let me you can better leverage you your your space because it's a sparse file so we try to do like a copy on right stuff for the for the volume and what I say here is all same with the new data engine by SPK the behavior behavior will be the same and volume backup morning get back up we try to make up the Easter to external backup store and based on the snesha so and we use a reference count to make sure we don't have a like redundant backup trunk in the remote bigger target so this is what we achieve and this part will not happen in a one fight with the SPDK but want to achieve is part of feature parity in one six okay and life migration life upgrade when you are wanting your system you want to upgrade the long home and what we will do to make sure your service without any downtime we will post your body engine a little bit and do a snesha immediately usually snesha is very quick quick because he's copy on right so he's very quick just create a new volume hat and the matter current volume had to be 01 and new new replicas in the read only more because he cannot be read you don't have snesha train right so if I you can ease able to write and then on post the engine on post the engine they mean the I okay start continue and think snesha to the new replicas and set the new replicas to rewrite read and write so everything is okay so this is for like a post new snesha and life body hands happens then right now can begin the right IO and let us think the snesha from the healthy replicas and become the read write so between the read only and rewrite you will read super will be impact for sure but after sync the snesha everything will go to go go back to normal okay yep so this is the life migration what we are doing and when doing the life upgrade so we will create the the other pair of a new engine and replicas together so they mean your volume will suddenly have a if your volume have a two replicas you will suddenly become the full replica for the migration purpose but after that we will do the engine replacement to rep replace to a new one and all one will be get clean so this for the life migration without any downtime okay and this one is disaster recovery and yeah because I think as the story social you cannot just provide the in-class operation you need have a story for out of cluster a special disaster recovery even for disaster recovery or for other purpose for testing somehow so long on provide you can beg out your volume to external right but this air recovery here is quite different it could it can do an incremental way so they mean if your source ball source cluster a he have a pot have ongoing data coming and you can keep back up to the remote pecker target and incrementally restore to your destination standby cluster and until you make it activate you will start to serve on for your world low so this is important to make the foundation for your volume recovery disaster recovery okay so I I talk about what's the long-haul and how long work primary use case and right now I want to share some information about how occurring status because run out of time so this is run replica performance comparison left side the road disc the middle part is the one for and three more and the last one is the one fine you will see you will see the one file performance is getting better than one for a lot and also super is close to the road disc so the total change okay how about the three replicas the three replica if you compare to the one for you will see the I OPS and that is getting improved and also the bandwidth but you've been with we were curious what's happening the rebounder bandwidth is lower than the current one because right now we are still doing the implementation we want to do the same behavior to let a read I O from the old replica but right now it's from the one replica so we are still doing the implementation I think he will happen in one by yep so yeah this is about the long-haul very brief and I I will be still here tomorrow in our kiosk so if you have any question you can come to ask and talk about your use case and your feedback about long-haul okay and oh sorry that's one the last one so the go the simply say I open from us and I'm just storage and Ronnie way so this is the goal for long-haul we want to make sure we can achieve this goal okay including a current stack all the features that we say SPDK okay thank you