 Okay, I think we can get started. Hello everyone, I am David Koh, senior engine manager at Suicide. Okay, I'm the co-owner of a long-home project and leading the team to work on long-home. We also have many contributions from external to help with long-home growth. Okay, so today I will talk about long-home briefly as usual and deep dive and also going to the current status and the future plan for long-home and finally Q&A. Okay, so long-home I believe some of you are already using long-home, but I want to do an overview again to let everybody know more about long-home itself. Okay, so the agenda, the first I will go through the long-home high-level view and project and release updates and also then go into the long-home details, what long-home suppose and how long-home works and how the long-home inside components work exactly and what's the new V2 data engine we are working on and of course IO performance between the V1 and V2 data engine. And that is what's new in 1.6, the latest release, we just released in February. And also what's next? So our long-home is a magnetic distributed bar storage system based on Copernetics. It's run on Copernetics as well. So it does not need any external dependency to make you able to run long-home on Copernetics. So it's just based on Copernetics control plan, control patterns and also customer resource. That's it. And he provide highly available precision volume. So all stuff including steady provision or dynamic provision or follow standard. Nothing different. And the important part, our long-home model is based on Snatcher chain. So here's a copy on right, incremental Snatch out. This is in cluster. But out of cluster we also support remote backup. So basically you can set up a remote backup target and backup your volume. Use the different patterns periodically or on demand backup. And also we know about users care about how to handle DCS recovery happen to your volume or even your cluster. So close cluster DCS recovery, we also have a solution for that. We call it DR volume. And about installation, the long target is not just a very strict area. We want long can run anywhere. So I call here is a playful agnostic installation. So no matters on prem or cloud or age. We also want to target for that. And we also doing some improvement. I will share more later. And this is open source on by CNSF right now in Cubating. And we try to target to graduation. So really expect for looking forward to everyone contributed to long home as well. And high level view are some pillars we are focusing on when we develop long home. The first one is reliability. And we want to make sure the data for a crash consistent for the data to respect for data integrity. And also multiple layer protection, like I say, in class essentially out of class backup and performance. We have a V1 volume right now. And beyond volume based on some, based on iSCSI, SCSI, iSCSI takes that. But we want to do something different for V2. So it will be on NV and over fabrics support based on the SBDK. I will talk more about V2 letters. And use abilities. We want to make long home easy to understand. Especially when you have a Kubernetes concept, you also can quickly understand, use the same pattern to understand long home. So all the behavior we map it to the long home resource is a Kubernetes resource. And installation also provide different ways. And one click installation just that everybody knows. There are many ways to install long home manifest, ham chart, or even from some application marketplace. You also can do that. And also in the 1.6.0 we verify the different gap solution to install long home, upgrade long home as well. And UI will have a very simple UI. And the simple UI provides the primary functions when you operate your violins or even do on demand operation. And maintenance, the most important part for long home, we don't want to interrupt user wallow. So especially the user doing no upgrade or even long home upgrade or even no maintenance. So we provide a volume upgrade or even volume migration or even drain policy for when you use a long home. So to avoid any downtime for your wallow. Okay, so this is Peter. We are always following up when developing long home. Okay, so this is project updates. Right now adoption is keep growing. And four years ago we donated long home to CNCF as a sandbox project. And after two years he promoted incubating project. Of course right now we are looking forward for the graduation. And right now around the world it's over 111,000 nodes using running long home. So it means about 13,000 clusters using long home as storage providers solutions. And for area, like I said, we want long home run anywhere. So right now long home can run age. Probably you saw some news about some company use a long home as a storage solution for their age solution. So age, on-prem, cloud. And this also all the area I want to target for the installation part. And for the domain, for the community information, we know some AI staff, telco, data visualization, observabilities, etc. They use a long home in these areas. So the next one I just want to mention, long home not just use it into an end user solution. You also become the critical mission component in any service provider solution as well. So this is a different type of position for long home to use the long home in different area. And collaboration. I want to highlight this one. And last year I attend the QCon Europe Amsterdam. And many people come to ask us about does the long home support telos? Many people. So in 160, we made it happen and what was a telos contributor as well. Long home right now can run on telos in us. And also we have external contributor. They have used the OKD for their distro. So long home can run on OKD as well. Release update. The latest release is 160. It's a feature release. So there are new features including in two. And actually this week, by this week, we will release 161. And I believe it should be a stable one because 160 already over 10,000 nodes install 160 right now. OK. And that is the stable release is 154 and 144. We continue have a patch release for that. And I will probably can talk about some risk here. And upcoming release, we usually have three months patch release for a stable patch release branch. Patch release for support a stable release branch. And also we change the feature release. Originally it's the two feature release per year. We want to move forward faster. So right now we change it to three feature release per year to make sure we can bring more innovation to and features to let a user try and feedback so we can people quickly. And for upcoming release, yeah, 161 and 155 and 170 will be happen July. Many new feature will be coming to once seven zero. I will share the roadmap letters. Of course, one act by end of this year. This is long list, but this is overview to let the people, everyone know what the zone home primary functionality capability has. So for Kubernetes precision volume support, we support different type of volume modes, broad volume and fire systems. And in the past, we also plan to do some sir interface for up to storage. But right now the priority change we will revisit letters and as a small is a rewrite only a rewrite many. We continue doing that. And we want to do something new for rewrite many h a in one seven and see that protocol. This is very standard. We want to met a dynamic provision volume work correctly. So provision attachments, nature clone expansion. We also doing and in the current older versions. And also we are wanting to do some volume group stuff in the following features and volume capabilities. This is an important part to know about what the capability of the volume has. We based on simple vision. No matter V1 or V2. And it's a chance to be on right. You can do a dream. And we have a recurring job to train the volume automatically expand the volume and live upgrade and live migration. So and our performance V1 we still very one V1 continue have a promote increase the performance. But V1 is based on ice goddess stack. So the challenge is there. So we plan to do something in one act. But for upcoming one seven we focus on the V2 because V2 is a new engine based on SBK can quickly bring the benefit of a higher performance for long volume. And of course local volume and data locality and storage to barge in the past we only support V1 long disk. It's a based on fire system on host by V2 is a robot device. So you can dedicate a robot device for your volume and replica scheduling and anti affinity in the past alone only support no and zone. But for the community feedback. Most of people actually have a multiple disk on one note. They want replica can be considered that part as well. And that the replica more than one can can schedule on the same note by different disk. So right now we also support the disk repair scheduling anti affinity. Of course in the future this label auto rebalancing will be introduced as well. Right now it's no label. And from the ecosystem side. We talk about the volume cell flying capability could put this Kubernetes perceived violence. Yes. For the ecosystem part we have a data protection data service and data redemption and data protection is based on the replication encryption in seed in transit and arrest including the remote backup. And bureau protection based on data integrity for the station level. Someone asked me. At Kiosk today and data service. In class of nature. Reverse out of class of a guy restore and the other. Data reduction reduction because long is based on station. So the space consumption of a station matter. And we introduce few way to let you can manage. Well fail for us nation. So including a recurring job you can periodically clean up such up to measure such up. And also such a size and maximum number of such management. Of course bigger complexion. This is not all the feature list of course. But I want to in short time to let you know this is area along already cover. And how long work. Everyone people come to me as about what's a long desire or I always say very I always say very simple. Because the design is very straightforward. The first one is a control plan. It's a control brain is deployed by demon say we call it long manager is composed of a long controllers. The Kubernetes console very standard and reconsoling long customer resource. That's it. And data plans actually we have data plan few components. But the primary function for the data plan is understand some requests from the control plan to see when I need to manage or create the volume. When I need to operate like is tension is 10 or dream the volumes you understand and do the following stuff. So for the volume self is actually three components for it. The first one is a volume front ends for you. One is ice car seat for V2 is ambient over fabric and volume engine. We call is entry point for the I.O. Okay. And also here he have a control pot for the engine and downstream volume replica is the data placement. So your data will be set into the replicas and you can decide how many replicas you want. And of course by default Longhorn is three replicas. But it really depends on your usage. Some people are some use case your application level already have a replication. So you're not really rely on the longhorn to do a double replication. But you want to rely on the longhorn other capability like a backup station. So you can determine how many replicas you want. And the third one life cycle. The life cycle. I don't talk about the step provision. But basically it's around for dynamic provision is around the CSI. So all the CSI cycle components functionality. This is what we want to achieve. Actually we already support and trigger points of PVC and data placement. Like I said, long disc two type for seasonal host and robot device. So the left hand side, right hand side, there's a diagram on Longhorn documentation page as well. You can quickly understand the page. You can see your part you will request the volumes. And long will understand that because it's a dynamic provision and CSI cycle and we'll call the CSI drivers. We will understand that data point will create engine is the entry point for the volume and downstream replicas for the data placement. And we will understand which disc have more despise than others. Then we will press there. And if your world is part one is the manager manage wall for example, deployments or step aside. Yeah, deployment and your wall or somehow is fail and need to fail overs. And in short time when your world will bring up another notes long will understand to bring out a volume up. But replica is intact the same. So you can very short time to bring out the ice got the front end and engine process. So this is how long long will basically work. And like I say long manager is a control plan. So what does it really like look like? There's a CSI API is an interface. I call our long home CSI parking long CSI parking is wrong on each notes. If you are using a long for known for long home, there will be a long home CSI parking. And he will communicate with the long home manager through the API. We have we have an internal restaurant API for that. So long CSI can communicate with that. And we will serve a persistent customer resource to our Kubernetes API server for sure. But important part we will reconciling for each resource. Some some resource is a period period reconcil. But some resources actually event driven depends on the different scenario. And create a set of components for the violence. And the other important part the interface the going to the communicate with the long home manager, not just long CSI parking. You also long UI and long home customer resource. You can manage the long home by UI or even modify or create a long home customer resource for that. And replication, like I briefly explained a little bit. Yeah, you can request the part have a valid request. And no one will determine to create the engine next to your workload on the same notes. And communicate with the replicas on this note or even the other notes. And we have a configuration code data locality. So you will try to make the one of replicas next to your workload have a better performance. And of course, we all we also have a replica balancing. So if your workload somehow move and we will try to balance to make the replica next to your workload as well. Okay, this is a set patterns and the note down. There's the new parts run on another note and can create the engine connect to the easy replicas. But how about a number of replicas? Originally two replicas right now is one replicas know how long is that has the one location code still time out. So he can be confused prevailing or globally. And you will know, okay, I will not bring up the replica until it's a real since happens. Otherwise on probably the note will be come back because he's maintenance. No maintenance. So you will come back. We will not spend as high effort to rebuild about review replicas. But if you over the still time out, we will rebuild it. And also some real scenario is not is about the involuntary involuntary note reboot. Okay, Molly snapshot. Like I say, he's a standard chain. Copy and write. So initially there's the empty volume heads. The data will compete continue right into. And secondly, if you are have a special trigger by users or system station when we do in a backup, they will be automatic create a system station and the new body head will be create. And the previous station will become immutable and they just for read purpose. And continue for that. And the real data you see the volume content will be likely they want the right hand side, but it's actually combined with the all the multiple station together. And Snatch out actually if you are data intensive data, the volume, the volume difference will be will change frequently. So probably will be occupied more space than you expect. So long have like I say before space Snatch out space management. You can use the recurring job to train or even a merge delete Snatch out to merge your Snatch out to reduce the space consumption. And the McKinsey is based on Spotify for V1, but V2 SBDK. There's the logical volume to support that as well. And big up big guy is based on the Snatch out. But we use the reference count to make sure there's no. Not used data still pick up on the remote bigger targets. So you will see, for example, in these pictures, we pick up the Snatch out to and Snatch out three. So you will not see the Snatch out the the you only you only have some reference. There was there will be no duplicate data for that. And the reference count to understand, okay, this big up is reference to which block of data. And this is Snatch out Snatch out two is reference to that one. So there's no duplicate data for that. Okay, Rebiya rebuilding is also very important for long home because sometimes you will know will be done for some reasons, a special in one involuntary reason. So how long can make sure the number of replica available your volume because this is the purpose and the design for long home volume. So firstly, we will post the engine the front end. So the IO will be stopped a little bit, but we will take the Snatch out immediately. The Snatch out is very quick because it will just make the first body and had to become the first nation. Snatch out then create a new body and had then add a new replicat in the rewrite only modes and I'm post the engine. They sink a red snatch out to the new new set of the new new set of replicats and set a new replica rewrite rewrite. Okay. So this is for post the first create a new Snatch out and create a new replicats only live data. But right now we can support right now read for that. So the data can be continued for that. So continue for that for right. But you only can refund the easy replicats. But at the same time we will sink Snatch out because Snatch is immutable. And mark the new replica is rewrite. So the old IO can go into the both replicats. So this is replicats rebuilding and live upgrades. Every time when you upgrade long home, your volume is still running, still serving for your world law. But actually the engine process and replica process already be upgrade and concurrently and sequentially to make sure every engine every volume will be have a new engine process and a new replica process. So what we are doing is more like a program deployment. We will prepare another set of engine and replica process. But actually data is no movement. The replica is point to the same data. And later if engine and replica process get ready, we will point to the new engines and tear down the old engine and replica sets. So for the IO it always continues. Nothing change. Long disaster recovery, this is DR volume. A special if you are planning to have a standby cluster for your current cluster. So you can make a backup for your volume to a central middleware backup target, backup store. We support different type of backup store. S3, NFS, CIFS, some user-user GCP stuff. And as yours. So because of the four main, what we said is all the same. The only difference is the price and destination. So when you set up a backup target, backup store, you can backup your volume. Periodically to the remote backup. But the other volume is different. The other volume, when you pick up, he will immediately restore delta restore to the standby cluster. Even you are not activated the volume on that standby cluster. So when your cluster, for example, like a Kubernetes cluster in region eight has some problem. Disaster happens. So you can, in a short time, to bring up the cluster, be back and activate the DR volume, become the normal volumes. So this is DR volume purpose. Okay, we already talked about the different design, the patterns long has and behaviors. So what does the long home, the inside component really work? Okay, this is the diagram I can share with you. Now, no major demon said, like I say, and data plane, we call you instance manager. So when you deploy long home, you will see an instant major for that. And here I specified a V1 and V2 because in one fight, we introduced V2 data engine as a preview features. At that time, we make the one instant major to server two type of data engine. However, they will be called some problems because V2 data engine based on SBDK need higher resource consumption, a special dedicated CPU for that. Okay, and higher bigger huge page page memory for that as well. Then, and we realize when people use a V1, probably their environment is different. Probably home lab or age. And it does not really care about a high performance IO. They really care about to make sure we have a perceived violence for that scenario. So in one six, we introduce, we separate the instance managers. So when you install one six by default, he will enable the V1, but you can disable V1 in enable V2 exclusively. Of course, if you have a better resource set up and you can enable both. So we want to make it independent without any dependency in between. So this is the purpose. Okay, so when, like I say in the previous page, the interface will become come to the CSI driver or long home CR customer resource and go into a long home managers. He will communicate with the V1 instant managers. I didn't describe the detail in the instant major, but there are a lot of JRPG servers inside. Respond for different capabilities. So V1 instant major will be create for V1. For V1, you will create the front end Isakas target servers and V1 engine and V1 replica, local replica or remote replicas. The same for V2. We use the same design concept for V2. The primary reason for that, we want the users can quickly understand all the design for different type of data engine because when you use the V2 engine, you can see, okay, the same way, the same flow as the V1. So V2, he will bring out the NVMe overfabric target servers, SBKray1, BDEV, and logical volume, logical replicas, local air remotes. And when everything get ready, he will be available for your workload to consume. And share managers, share managers respond for rewrite manning. Just one step difference. For when we recognize our last volume request for rewrite manning, normal manager will understand and create a share manager part. And share manager part will use the normal volume created by instant manager and mung into the share manager part. And provide the NFS is for endpoint to the consumer workload. So this is most of case user want to use a long home, a special multiple workload want to use the same volume. And probably you think of this diagram, you're thinking, well, this is a single point of value, right? The share managers. So in one file, we introduce a recover backend for share manager. So when he fell over, it can be recovered quickly in short time. But eventually the HA is the target goal. So in one seven, we are doing some evaluation for share manager HA. So this is purpose to make it eventually HA. Back image manager. This is new stuff. Because long home not just useful application level workloads. And you also provide a bra volume, volume type. Okay. So some solution integrate long home is the bra volume because that kind of application is actually VN. And VN do want to use a long home because long home have a backing image concept. And that means your volume can be bring up not just empty raw volume, you can base on the raw image or QCALT2. And we will bring up your volume with the data set into the image. So the difference here, only two parts. When we know, okay, your storage cost defined, the volume should be from the back image. Long home know that, long home will bring up the, we call it back image data source. The source defined, we want to support, in the future support different source. But right now it's HTTP. So it's, it can get the back image from the remote, remote, remote source. And down into the backing image data source component will be delete. It's just a fertile on purpose, on demand part for downloading back image. Okay. Then you will be hand over to back image manager to respond for the back image distribution and the replication across know across the disk. Because back image will be used by replicats. Okay. So this is a point. Okay. V2 data engine. What's the V2 data engine? Simply say he's based on SPDK. We call it the second, the next generation of long home modeling. But he does not mean we will duplicate the V1 because we will keep the V1 continue improving the V1 performance. Like I said before, different environment setup, low spec, high spec, they will determine what the data engine want to use. Okay. He has a broad device concept. You have a different broad device defined, different function to represent the final broad device for workloads. Okay. So the most important, the protocol uses the NBME over fabrics. This is very, very important force to provide a higher performance for our V2 volumes. Okay. The similarly parts for V1 and V2, replicats, logical volume for V2, snapshot space file for V1, block cluster, block for V2, and sparse file extension, extend for V1. And back again, V1, BDF, and engine process, and NBME over fabric for V2 and Iskasi for V1. And cross node replicat connection, engine to connection, connect to the remote replicats can through the NBME over fabric, but V1 is homemade TCP protocol. We're doing. And this is just show, quickly showcase the difference. The part is a context switch between the kernel space and user space. So the right hand side is V2. So it will be higher efficient because no context switch for that. And also it's based on NBME over fabric. Okay. This what I say V1, Iskasi. We use Iskasi initiator of a client and Iskasi target will be bring up together with a long engine and replicats is a homemade solution. And for V2, or NBME CLI, right now is CLI, but we are planning to do aesthetic binding, probably not in 1.7, but eventually in 1.8, we want to do that because we want to decouple from NBME CLI. And engine is NBME over fabric target server together with the long engine. The same concept, then replicats will be logical or valid. And our performance, these are the important parts. So the red bar is the V2, the yellow bar is the V1, the blue bar is the local disk. You can quickly understand the difference gap here and bring V2 bring high performance NBME1. And throughput, because long is a multiple replicats, you will see the read case is higher than others also have an improvement than V1. Rendering right because we reach out the capacity of the underlying disk in our test bay. Let's see, again, you see the V1, high latency, but V2 is lower latency than V1. So this is very important to define a different position to use case when you want to have a higher performance for your workload. Okay, quickly, because no time. So 1.6.0, if you not try yet, give your try and give us feedback. 1.6.0, what we have right now, we have a volume station backup reverb for V2 and backup restore for V2. But backup restore is very interesting. We not just backup V2 volume and restore backup volume. You can backup V2 volume, restore to V1 volume. You can backup the V1 volume, restore to V2 volume. So this is purpose you want to make lamp seamless integrate depends on your different scenario use case. And separate the data plan for V1, V2, and M64. We make sure we just try it and make it happen in 1.6.0. You can run the M64 for V2 data engine. Pay for analysis I already mentioned. Talos, OKD, specific efficiency. You can manage how many stations you want, how many sites of stations usage you need. So in 1.6.0 we have a configuration for that global configuration or even volume space configuration. Bar volume encryption, we already have a five system volume encryption. Bar volume encryption is very beneficial for your world is the virtual machine. OK, no drain. This is very important for your non-maintenance because when you have less healthy replicas, nothing you can do before. But right now we introduce a broad for eviction. It will automatically evict your replica for you. And we also backport this feature to 1.5. OK, backup image, backup restore already coming into 1.6.0. What's next? So 1.6.1, we will release by this week. So give a try, you should be the first stable release of 1.6. And 1.7.0, what we want to do is feature parity for the V1 data engine in V2. Live upgrade, migration, replica rebuilding on light, backup image, violins, trim, expansion, and volume group. Snatch out already have a volume group of Snatch out. We want to integrate, but we also think about restore as well. And we are many HA experimental. So this is what we want to plan to do in the upcoming feature release in July. So please look in for it. Yeah, that's it. Any questions? OK, thank you. Long has a kiosk. So if you have any questions, you can come to ask me. I will be at kiosk next two days. OK, thank you.