WEBVTT 00:00.000 --> 00:02.000 . 00:06.000 --> 00:08.000 . 00:08.000 --> 00:10.000 . 00:10.000 --> 00:12.000 . 00:12.000 --> 00:14.000 . 00:14.000 --> 00:16.000 . 00:16.000 --> 00:18.000 . 00:18.000 --> 00:20.000 . 00:20.000 --> 00:22.000 . 00:22.000 --> 00:24.000 . 00:24.000 --> 00:26.000 . 00:26.000 --> 00:38.820 Good morning, R. I am G-FIN. I hope I am more developed the end. Yes. So, I am part of the 00:38.820 --> 00:46.200 vegetable team, works in IBM. So, I sat in my career in like five years ago, I was trying 00:46.200 --> 00:51.200 to integrate self with look for the algebra be side, then curl M mostly work in algebra 00:51.200 --> 00:59.120 vector steps. So, this is a new project which we are working on. So, today I am plan to cover 00:59.120 --> 01:04.240 following things. I will just give a brief and robot what is in the agent telling is what 01:04.240 --> 01:09.680 it means, it means, different type of different things, but I will clear on that part. Then 01:09.680 --> 01:14.640 what do we have in algebra at the moment, then I will brief you talk about cloud transition 01:14.640 --> 01:21.440 with short because the demo is based on those things and I also mentioned before about 01:21.440 --> 01:29.040 like S3 tape, what it is and FIN. So, what is intelligent trying? So, basically you need 01:29.040 --> 01:35.160 to move the data across different storage mediums, maybe hard HDs, SSDs, that is the basic 01:35.160 --> 01:41.640 idea. And here in S3, like we talk about storage glasses, purpose and storage basically. 01:41.640 --> 01:45.680 So, faster storage glasses, you need to move the data from different storage glasses like 01:45.680 --> 01:51.600 this standard storage glasses, then this glacier storage glass and all. And why we do not 01:51.600 --> 01:56.600 do not do that? So, why do we need that? Because basically it optimizes your course 01:56.600 --> 02:03.640 like you can keep the most recently access data in a faster medium and like the data 02:03.640 --> 02:08.640 which is not that much useful, you can move Tesla or medium. And how it based on policies 02:08.640 --> 02:12.920 like the policies maybe on the access time, like the oscillation access that I will 02:12.920 --> 02:19.120 be in the first medium and not much like it will be on the slower medium or after time 02:19.120 --> 02:23.240 say 10 days you need to move this data to another storage glass kind of. 02:23.240 --> 02:29.240 Now, what do we have in algebra? So, if you know like there is a placement targets, that 02:29.240 --> 02:33.160 is what we call like in which we can defend different types of storage glasses and each 02:33.160 --> 02:38.600 storage glasses represent one pool. So, if a pool is created on a faster device, 02:38.600 --> 02:45.120 then you can name it like fast something like that. And this is, by default it creates 02:45.120 --> 02:49.720 pools on the safe cluster, but I am talking about like you can also specify pools in 02:49.720 --> 02:54.720 your data can go on. And as I mentioned before we have storage glasses which is similar 02:54.720 --> 03:02.760 to what it provides, but yeah it based on safe pools. Then how we do the data transition 03:02.760 --> 03:09.080 or data movement like again with a safe cycle policies. So, we need to set that policy 03:09.080 --> 03:18.360 on the on the buckets. And one thing is like, so the placement target, what do I say? 03:18.360 --> 03:22.520 Like, so this need to be mentioned when you create a bucket. So, that is because there is 03:22.520 --> 03:27.080 a default placement constraint like that we need to mention that. And you can mention 03:27.080 --> 03:31.600 the storage glasses for the object operation like you can say if you put an object in a 03:31.600 --> 03:33.600 different specific storage, then you can mention that. 03:33.600 --> 03:38.160 So, that is a manual way of doing it. And after that you can automatic or like you can 03:38.160 --> 03:42.680 do a life cycle policy and that I will more cause different storage glasses. And all 03:42.680 --> 03:47.600 the configuration are defined in the so on so on view level. So, the placement target will 03:47.600 --> 03:51.720 be defined in the so on view level. And the so on level we will define the storage glasses 03:51.720 --> 03:59.240 because in as w, the so on of persons the pool basically like you most of the times like 03:59.240 --> 04:03.400 if it is a defaulting then it will be a defaults on, but here you should. 04:03.400 --> 04:10.520 Yeah. Now, as I mentioned earlier so I have mentioned about like the data movement across 04:10.520 --> 04:15.400 different storage glasses. This is bit more advanced or not advanced, different use case. 04:15.400 --> 04:21.880 So, here the movement is happening between RCW which is a on-prem and other one is like 04:21.880 --> 04:26.040 the cloud endpoint. So, the cloud endpoint need to be like more like an ST combatable 04:26.920 --> 04:32.040 thing. And so, here the so on level configuration is not required. In the placement view 04:32.040 --> 04:37.080 you just define the storage glass and the storage off you need to mention the configuration. 04:37.080 --> 04:41.560 So, this is a special type of storage glass which is not cloud a street. And you need to 04:41.560 --> 04:47.800 provide the like the S3 and point details like access points, we can and if you 04:47.800 --> 04:52.040 want to mention bucket which bucket you need to put the data under. So, basically this seems 04:52.680 --> 04:56.360 to be bit controversial in the sense like the on-prem attribute data is more 04:56.360 --> 05:01.800 across cloud cloud you know it is ghostly and on-prem is cheaper. So, this is kind of 05:01.800 --> 05:07.720 first step we are trying to sing with cloud thing and yeah in the later slides the 05:07.720 --> 05:12.360 indelgenting or like the tm which you are working which makes make sense if you 05:12.360 --> 05:18.280 if I mention the ST tape. So, yeah as I mentioned this is a unidirectional process as of 05:19.240 --> 05:24.280 you know and like I mean as of now in the sense on the later series the 05:25.720 --> 05:31.560 skewed one like it is kind of a solid the like it is unidirectional the data will move to the cloud 05:31.560 --> 05:37.480 but you cannot access the data after movement. And you can we can the head of it. So, you will 05:37.480 --> 05:42.840 have an offense in the on-prem cluster and you can look on the data on the cloud. So, that is 05:43.400 --> 05:50.120 cloud tension and so, this part is more is in the master's of so, basically this adds the 05:50.120 --> 05:56.280 restore capability. So, we try to map the restore functionality with restore APNST but again in 05:56.280 --> 06:02.520 a three the restore APNST is more like you need to move the data from a glacier to the standard 06:02.520 --> 06:08.680 sorry task kind of thing. That is why the APNST is used but we are just trying to adopt the APNST for 06:08.680 --> 06:16.360 this purpose this use case like if you you send list of the cost from the attribute cluster 06:16.360 --> 06:21.560 then it will pick up the objects from the cloud. Again there is also you can use a normal 06:21.560 --> 06:27.160 get-tropation and on which is kind of a way to like in which you will you won't know like it 06:27.160 --> 06:30.920 will assume you see down on the data from the cloud and then you can access that if you 06:30.920 --> 06:35.640 will send get-tocus or something like that on the head of the object. Now so, there are two types 06:36.520 --> 06:40.200 of restoring so, one is temporary. Again it is based on the restore APNST which is three 06:40.200 --> 06:46.840 powers. So, temporary the data will be stored temporary and life cycle rules which we are 06:46.840 --> 06:51.640 written on the bucket it is not applicable for the data and there is an expression time like 06:51.640 --> 06:56.920 in the next slide I will give more details about the STP. So, after that expression day 06:56.920 --> 07:01.720 so, something like that that will be again move back to a step data like kind of a head object 07:02.680 --> 07:09.560 so, permanent is more like the object will be stored permanently and so, there is no time limit 07:09.560 --> 07:14.280 or something like that but the life cycle will apply on that because if you say 10 days after 07:14.280 --> 07:19.640 the object need to be moved back to cloud it will move back to the cloud. Then one key difference 07:19.640 --> 07:24.600 is that the restore type if it is a temporary thing then we are not doing it for the application 07:24.600 --> 07:28.840 like multi set purposes we will just keep it a month soon because anyway the data will be 07:28.840 --> 07:34.120 moved after something right or I mean got delayed after something but the permanent like the 07:34.120 --> 07:43.000 data will be located on the different sources and for the get occurs this is for the VU sorry 07:43.000 --> 07:48.840 for the STG get occurs if you say getting the object I asked to get occurs then the object will 07:48.840 --> 07:58.040 be we store temporary purpose similar to temporary. Now this is how the APN looks like. So, 07:58.040 --> 08:03.960 as I mentioned the STG the APN is defined to move the data from glacier or like low coastal 08:03.960 --> 08:11.720 cluster high-speed storage class using list of objects but for our use case we are only supporting 08:11.720 --> 08:17.480 one parameter in those circuits which is days. So, this is defined then it is a temporary straw 08:17.480 --> 08:23.000 if day is not defined then it is more like permanent room. So, these are two options at the 08:23.000 --> 08:27.160 amount which are available for this one is version ID. So, if you have multiple versions of objects 08:27.160 --> 08:31.880 if you want to download one version of list of one version then you can do that. So, 08:32.680 --> 08:38.040 the current version in the it will be moved like in the so if you have multiple versions say and 08:39.160 --> 08:43.880 the four versions we moved to the cloud and the current version is five fifth version and if you are 08:43.880 --> 08:49.320 doing a list of then it will list on the third version then the on-prem attribute will have the third 08:49.400 --> 08:54.600 version of jet. So, the latest version will be all right that is what I am trying to say. 08:56.600 --> 09:02.440 And for the this is for the list of object call like similar to that STG has a get call like 09:02.440 --> 09:08.200 CPE or get of it called or will also will fetch subject from the cloud. For that you need to 09:08.200 --> 09:14.920 configure two parameters in the TA config. So, one is which makes the like the get to cost 09:15.880 --> 09:21.480 allowed a little like it will make the if the cost is initiated then only if this options 09:21.480 --> 09:25.880 that then only the little will happen other on is similar to the list your days like how long 09:25.880 --> 09:34.360 you need to keep the object on the attribute server. Now, this basically like the variation 09:34.360 --> 09:40.440 thing like how we can see the object is transition back to the attribute server. So, we had different 09:40.520 --> 09:46.360 headers. So, when you initiate the request it is a sync call from the attribute. So, if you 09:46.360 --> 09:52.360 mark the object is like we saw in progress and when it is completed we will mark it is we cloud 09:52.360 --> 09:59.000 will start if it is failed then we make it lists of failed again and all this can be found from 09:59.000 --> 10:04.920 the rados admin objects chat come in as well as from the header like if you call as three 10:05.000 --> 10:12.360 head of jet or something like that you can see that with your status that is come. Now, for the 10:12.360 --> 10:17.880 permanent list we are currently putting back the object to standard storage glass like even if 10:17.880 --> 10:22.840 we have multiple storage glass in the cluster we only put in the standard storage glass it is 10:22.840 --> 10:28.040 can site like disillimitation maybe in future we will change it. But, for time the jet we are 10:28.040 --> 10:32.040 not changing the storage glass it will be still pointed to the cloud test storage glass which you 10:32.040 --> 10:40.920 are defined. Now, what is a street tape? So, most of you know type is like made chip storage which 10:40.920 --> 10:46.760 is available. Now, most of the stream enders also supporting like the tape storage. So, basically 10:46.760 --> 10:53.320 the tape like when I am as honest we all like versidity. So, basically the here the tape 10:53.320 --> 10:59.880 have an S3 interface you can send call S3 causality. So, that is a basic idea and why people are 10:59.960 --> 11:07.000 doing it. So, basically the tape like the it is causer fatigue and like it is more doable than 11:07.000 --> 11:13.800 the other type of storage mediums. And yeah, so the thing is that integrity and market and support. 11:13.800 --> 11:19.240 So, this is like the features of tape which can be. So, here basically tape is kind of a different 11:19.240 --> 11:26.920 storage glass and you can we are moving a data from the S3 object storage tape. We are again 11:27.000 --> 11:33.400 to S3 con. So, as I mentioned we only support S3 on the RGB level. So, this can be also consumed. 11:33.400 --> 11:38.360 So, the plan is to integrate with different type of tapes and since we have working IBM first 11:38.360 --> 11:45.400 goal is to integrate the diamond tape which is the type solution which IBM provides. So, 11:45.400 --> 11:50.120 this is like ongoing work. So, we are trying to support a different type of storage glass 11:50.200 --> 11:56.520 on a cloud as thick ratio and the PIS already the name we need to add the extra facility. 11:56.520 --> 12:02.680 So, this might be more sense like from indignity in purpose like the yeah, moving a data 12:02.680 --> 12:08.680 to a tape store is then and cloud or like more closely thing. So, we came also on like we need to 12:08.680 --> 12:13.080 define policies which will automatically the things. So, that is the next step and 12:14.360 --> 12:18.920 other thing is we need to add more debugging purpose in the for the use of positive because 12:18.920 --> 12:23.240 here you are need to debug two different two different storage mediums one is on the 12:23.240 --> 12:29.320 side and other is outside of the stuff. So, yeah this two do is also like a tackling which all 12:29.320 --> 12:36.200 the things are pending from our side of which are ongoing things yeah. So, any questions I will 12:36.200 --> 12:43.560 go through demo if you want to ask a system we can ask a system after demos which might be more 12:43.640 --> 12:56.120 clear like how the things will work. So, this is a coded demo and I hope it is visible is it 12:56.120 --> 13:05.480 visible in the back end. So, basically I have created a safe cluster and using this chart 13:06.440 --> 13:18.040 so, my actually sounding and if you just check yeah it is as of now I am T. Now, I need to configure 13:18.040 --> 13:28.760 the I have configured the I have configured the what you say the cloud transition things here. 13:29.640 --> 13:36.040 So, basically I have like a single node cluster so, it is a default sound group and if you go 13:37.240 --> 13:46.040 I have defined the placement and the is a cloud IBM storage class. Now, I have defined 13:46.120 --> 14:12.440 the like T a configured I am it as like and poya and this is a cloud us see type and on so, yeah and I also 14:12.440 --> 14:17.960 said some configuration like it is kind of two configuration so, which will simulate that attack 14:17.960 --> 14:24.760 transition we store instead of days like one day will be come to one 20 seconds for for example and 14:24.760 --> 14:30.440 here for the waste already like how long the waste or like how long the object will be it will 14:30.440 --> 14:35.400 be 60 seconds it is kind of simulation purpose. Now, I am going to create a bucket 14:35.480 --> 14:45.160 bucket is calculated now I need to set the life cycle rule. So, yeah if you have mentioned 14:45.160 --> 14:51.240 one day after that the object need to be transition and I have given the cloud like the storage 14:51.320 --> 15:07.240 class so, stored IBM. So, this is the an APA to put the life cycle configuration on the bucket 15:09.720 --> 15:14.440 basically now I need to add some data so, I am just 15:14.440 --> 15:26.120 also this is a cloud endpoint which I have afforded in the TA config. So, if we check on this 15:26.200 --> 15:35.960 and point at the moment yeah there is no bucket name BCT which I have created earlier so, yeah 15:45.560 --> 15:51.640 so, basically I am copying certain data to the bucket and see the transition happening then 15:51.720 --> 15:59.720 I will call this for a question. 15:59.720 --> 16:21.800 So, this is basically this subject call it will show the head condons you can see the 16:21.800 --> 16:27.320 storage class is standard at the moment. So, I have created three files on its 16:27.320 --> 16:34.120 permanent one for its two and four temporary so, all of them has currently standard storage class. 16:34.120 --> 16:57.560 So, the transition not happened so, just take some time and just forwarding a bit. 17:35.080 --> 17:40.200 So, one thing we do not know that m time won't be changed for the array process. So, 17:40.200 --> 17:43.320 we can not do m time 18:10.200 --> 18:25.200 Now, you can see all the that I got transition. And if you check the head of it again, 18:25.200 --> 18:52.200 now, the storage just is cloud IBM. So, this is the permanent was shopping. 18:52.200 --> 19:19.200 As you can see, the object got was stored here, but I am time is same. 19:19.200 --> 19:38.200 So, in the demo, I face a mixture. So, basically when I try to reassure the objects, the 19:38.200 --> 19:48.200 first object got transition back to cloud. So, that is why the permanent is fine. So, now, the 19:48.200 --> 20:06.200 object got was stored. Finally, I am going to go into the way through. 20:19.200 --> 20:26.200 So, as you can see, like, it is just small object like it got to be stored so fastly. 20:26.200 --> 20:32.200 Otherwise, like it will just complete all the course, but it may take some time on the back end. 20:32.200 --> 20:40.200 Now, I need to show the permanent again, because the life cycle will kick off and like it passes 20:40.200 --> 20:52.200 from and of it back to the cloud. Now, I think I have all the sets. Now, if you check the head of 20:52.200 --> 21:00.200 jets, I mean. So, you can see the permanent has the storage last standard and yeah, 21:00.200 --> 21:07.200 other two has cloud IBM still the storage. The size is changed, but yeah, otherwise, storage 21:08.200 --> 21:16.200 was still the same. Yeah, you can also just show in the back tab to the head. 21:16.200 --> 21:22.200 So, that is the demo. Any questions? 21:38.200 --> 21:52.200 So, the question was how the core time management for the storage classes, like how you 21:52.200 --> 21:57.200 can manage the core terms, different storage classes and so on. Actually, for me, the last 21:57.200 --> 22:00.200 condition, then only I came to know we have issue with the storage class, 22:00.200 --> 22:05.200 cortices. So, like for me, the last condition, we have mentioned like we have the issues 22:05.200 --> 22:10.200 with the cortons, storage classes and so on. So, then only I came to the issue with that. 22:10.200 --> 22:14.200 So, we look into that. So, yeah. 22:14.200 --> 22:16.200 I mean, also I found it is not possible. 22:16.200 --> 22:18.200 Yeah, I found it is not possible. 22:18.200 --> 22:22.200 Yeah, I found it is not possible. Because this feature both developed as a 22:22.200 --> 22:26.200 other economist possible on this, this was featured like parallel with the 22:26.200 --> 22:43.200 conning thing. We never test the conning thing against the issue. 22:43.200 --> 22:51.200 The question was, the question was whether we get bucket notification on the 22:51.200 --> 22:54.200 list of the class. Again, it is not implemented like it is two 22:54.200 --> 22:57.200 delicas on our side. 22:57.200 --> 22:58.200 That is good. 22:58.200 --> 23:07.200 Also, regarding the namespaces of the beggin start. So, you have like your namespace on these 23:07.200 --> 23:11.200 red or spooks to give a side and then you have your backup namespace. 23:11.200 --> 23:17.200 And so, how is the name pollution for bucket names managed in that regard? 23:17.200 --> 23:23.200 The customers, the namespace on the self-cluster and how we can manage the 23:23.200 --> 23:28.200 namespaces in self-cluster and the tape cluster of the cloud back in. 23:28.200 --> 23:33.200 So, actually, we are not creating a bucket on the cloud back in. 23:33.200 --> 23:38.200 So, it was on the demo since I forwarding it to what to remove. 23:38.200 --> 23:43.200 Basically, we are just creating path kind of stuff on the bucket. 23:43.200 --> 23:47.200 Like, it is an object we are just showing it to a bucket which is mentioned on the cloud. 23:47.200 --> 23:52.200 So, we are not creating a bucket. So, the type of pollution won't happen as far as I understand. 23:52.200 --> 23:59.200 We got in the users, I think it is all in a string, because the sending from 23:59.200 --> 24:04.200 AGW to the end user. So, AGW does not know about the user. 24:04.200 --> 24:08.200 Like, it just has the credentials. That is it, nothing apart from the user. 24:08.200 --> 24:11.200 So, AGW is not available to the users or something like that. 24:11.200 --> 24:17.200 So, that again ties into the way to the invoice potential customers 24:17.200 --> 24:19.200 on the back end storage usage. 24:19.200 --> 24:24.200 So, yeah. 24:24.200 --> 24:27.200 Yeah. 24:27.200 --> 24:28.200 Yeah. 24:28.200 --> 24:33.200 You don't want to sell it for free. 24:33.200 --> 24:34.200 So, yeah. 24:34.200 --> 24:43.200 Let me tell you some of how the testing that you can see how the test features 24:43.200 --> 24:46.200 use as well. 24:46.200 --> 24:49.200 I mean, it is triggered by the client. 24:49.200 --> 24:52.200 It is also important. 24:52.200 --> 24:56.200 Okay. So, the customer is kind of matrix from the client side here. 24:56.200 --> 25:01.200 The matrix which how much the customer send from the client for the story and on. 25:01.200 --> 25:02.200 Okay. 25:02.200 --> 25:05.200 How many of these stores they did for example in the last 24 hours? 25:05.200 --> 25:07.200 Yeah. So, the customer send matrix all like. 25:07.200 --> 25:12.200 So, basically we may need to add the telemetry part, I guess, which is like the most 25:12.200 --> 25:14.200 or because it is not added. 25:14.200 --> 25:26.200 Similar to get to a put, we may need to add the rest of the telemetry side. 25:26.200 --> 25:27.200 Okay. 25:27.200 --> 25:37.200 Thank you.