{"id":5471,"date":"2018-02-01T13:59:54","date_gmt":"2018-02-01T18:59:54","guid":{"rendered":"http:\/\/chriscolotti.us\/?p=5471"},"modified":"2018-02-01T13:59:54","modified_gmt":"2018-02-01T18:59:54","slug":"the-ease-of-setting-up-and-using-tintri-synchronous-replication","status":"publish","type":"post","link":"https:\/\/chriscolotti.us\/vmware\/the-ease-of-setting-up-and-using-tintri-synchronous-replication\/","title":{"rendered":"The Ease Of Setting Up And Using Tintri Synchronous Replication"},"content":{"rendered":"
<\/p>\n
I realized today that I have not actually blogged yet about the Tintri Synchronous Replication feature that was released a few months back.\u00a0 I decided to jump back into the lab to show people just how easy this is to use.\u00a0 What Tintri has built it’s base on has always been ease of use, and to be honest this feature is no different.\u00a0 Let’s take a look at just how easy it is to configure and use.<\/p>\n
<\/p>\n
For you to configure and use Tintri Synchronous Replication, like the SRM setup I detailed previously it’s a few simple steps.\u00a0 This will require the use of Tintri Global Center 3.7 or higher to implement.\u00a0 I suggest you read the Tintri Global Center admin guide for latency requirements and other considerations.<\/p>\n
The first thing to look at is something I wrote a couple of weeks ago to understand the difference between the Tintri Service Groups<\/a>.\u00a0 The reason is there is some differences between how they are used and where they are configured.\u00a0 For the sake of this I will assume you’ve got the understanding of the different ones.\u00a0 Bear in mind Tintri is hoping to converge these in the future to make things easier.\u00a0 The first thing you need to do is create a new Tintri Service Group and run through the six simple steps.\u00a0 Remember this Tintri Service Group today cannot be used with SRM those are configured separately.<\/p>\n First just give the group a name<\/p>\n <\/a><\/p>\n Then select “Option 2” for the synchronous replication<\/p>\n <\/a><\/p>\n The next step is where you define a sub folder for the group to use as well as the PRIMARY VMstore.\u00a0 The folder will be created and we will use this later to mount as a datastore in vSphere.\u00a0 This folder will be created on both Tintri VMstores from this one screen.<\/p>\n <\/a><\/p>\n Here is where we setup the cluster configuration.\u00a0 We select the secondary VMstore and we assign a cluster IP address which should be on the Data network range.\u00a0 This cluster IP will be used to mount the previous sub folder as a new datastore.\u00a0 In my lab only one VMstore as a Replication IP, but ideally you would use both replication networks on both ends.\u00a0 in my case I am using the data network on the other side.\u00a0 Then you can test the settings.<\/p>\n <\/a><\/p>\n We can just set some basic alerts<\/p>\n <\/a><\/p>\n Finally review the settings and create the Tintri Service Group<\/p>\n <\/a><\/p>\n Once this is done the group will be created and do an initial setup.\u00a0 You can see the status of the group to check or modify settings or add snapshot protection as well to the group.<\/p>\n <\/a><\/p>\n As I mentioned at the start once you setup this new “Cluster” you just need to present the new construct to vSphere.\u00a0 To do this you simply mount the datastore as a new NFS mount point.\u00a0 You will use the Cluster IP you created and the sub folder.\u00a0 I suggest you name the datastore to reflect the Tintri Service Group’s usage.\u00a0 This new datastore will effectively span both Tintri VMstores with the single namespace.\u00a0 While you can still deploy virtual machines to the base Tintri mount point those will not be replicated.<\/p>\nUsing the new Service Group in vSphere<\/h2>\n