Grid federation is a new feature in storage grid 11.7 introducing the ability to create a birectional trusted and secure connection between two storage grid systems. Grid federation enables two key features account cloning and cross- grid replication or CGR. In this video, I will be giving an overview and a demo of these new features. Account cloning is the replication of tenant information over a grid federation connection. The tenant itself, tenant groups, tenant users, and optionally S3 access keys are all replicated over account cloning. Note that tenant root user passwords and local user passwords are not replicated automatically. Also note that edits or deletes to users or groups within a tenant are not automatically replicated over account cloning. Account cloning is a prerequisite for cross- grid replication.CGR is the automatic replication of objects between selected S3 buckets over a grid federation connection. S3 version ID, the create time, the part contents for multiart objects, as well as the segment contents for non-multiart objects are all replicated over CGR. Note that object versioning must be enabled on both buckets in a CGR connection. Now, let's log on to two storage grid systems and explore these new features. For this demo, I'm going to be using two storage grid instances. On the left here, I have grid A and on the right, grid B. To begin configuring your grid federation connection on either grid, go to configuration, grid federation, and click add connection.Give the connection a name. Enter the IP address of your current grid.For a port number, which can be any number between 23,000 and 23,999, as long as it's an unused port, enter the provisioning passphrase. And finally, enter the IP address of your second grid and click save and continue. Now we download the verification file which will upload to grid B to connect grid B to grid A. So on grid B go to configuration grid federation and click upload verification file. Enter the provisioning passphrase for grid.Click save and test. All right. Now we can see success. Grid A to grid B connection has been added. And if we go back to grid A, we can see connection status connected. Now that our grids are connected, we can set up a tenant on grid A and clone it to grid B using grid federation. Go to the tenant page, click create, give your tenant a name. Hit continue, and be sure to select the use grid federation connection permission.Select grid A to grid B or whatever your connection is called under the grid federation menu. Click continue. Set the root password. Click create tenant. Now if we go to grid B under tenants we can see federated tenant. Note that you need to set the root password for your tenant on grid B as the tenant password will not be cloned automatically. And now going back to grid A and logging into the tenant manager, we can clone groups and users using the account clone feature. So if I go to users in the tenant manager, click create user, make a test user, set the password, click continue, create user. If we go to the tenant manager on grid B,we can see the user has been cloned. So now going back to grid A, we can create a group on grid A and clone it to grid B with grid federation. Go to create group. Make a test group. continue and finally add our test user. Now, if we go to grid B, go to groups, we can see test group appear. Now, we've created a user and group and clone them to grid B using the account clone feature. Note that any edits or deletes to users or groups on either grid will not be automatically synced to the other grid. Edits or deletes will need to be manually done on both grids. Now, let's create some S3 access keys. Note that access keys will not automatically be cloned from grid A to grid B. To do that, we'll have to go to the API, scroll down to S3, and use this post operation to clone the keys from grid A to grid B. So, let's go ahead and create our keys. In this, we're going to enter the user ID associated with the keys. In this case, it's root. Go ahead and copy the access key, paste it in here. Copy the secret key expiration date if we want to. Go ahead and execute. We can see the 204 code here means that the keys have successfully cloned. If we go over to grid B here, we can see our access key ending in 8 L, which is the same over here.Now, let's go ahead and set up some buckets to use for cross grid replication. Note that you have to manually create the bucket on both grid A and grid B. Buckets will not be cloned automatically. So, go ahead and click create bucket. Name our bucket. Click continue. Go ahead and enable object versioning. And note that object versioning is a prerequisite for cross- grid replication. Now we go ahead and create bucket. Go to the bucket details page. Go to the cross grid replication tab and click enable. Go ahead and select the grid A to grid B connection. And we'll see an error that says the specified bucket does not exist on grid B. So go ahead and go over to grid B. Go to the tenant manager. Go to buckets. Create our bucket one. Same deal as before. Enable object versioning. Now go to the bucket details page. Here we can see the cross grid replication tab. If we go ahead and go to grid A and click enable and test. We can see a success notification here. Note that the CGR connection we've just created goes only one way from grid A to grid B. If we want a birectional CGR connection, we'll have to enable CGR on the bucket on grid B. Now we see another success notification. We can go ahead and test the connection once more to check that the connection is healthy. And now we've set up a birectional cross- grid replication connection from grid A to grid B. to demo the CGR connection. I've opened bucket one on grid A. In grid B using Storage Grid's experimental S3 console. So now looking at bucket one on grid A, we can see it's empty. On grid B, it's empty. On grid A, I'm going to go ahead and upload some test data. So now we have the small test.ext object. If we go over to grid B, we can see that it appears here as well. Thank you for watching.