Introduction
This blog article discusses Access Rights feature and its implementation in VSAN from StarWind environment. Access Rights allows you to segregate the storage between multiple clusters or hypervisors. You can configure the feature with StarWind Management Console, and, in this article, I’ll teach you how that can be done.
But, before I start, I’d like to discuss when you may need storage segregation. Look, imagine your storage pool to be a computer disk used by multiple users. Obviously, each needs some privacy so that other users (except of admin, of course) have no idea what’s going on beyond their parts of the storage. They can neither read files nor write anything to other users’ storage segments. The same applies to the what you have in real life – the storage pool. You may want only specific devices to be visible for another host or only a specific channel to be available for data transfer for some reason. Well, here access rights come in handy!
Preconfiguring the Servers
Today, I have two nodes with pre-installed VSAN from StarWind.
There are two highly-available devices (HA): Storage 1 and Storage 2. Also, I have one additional compute node. Today, I am going to connect two nodes to the Storage 1 locally, while Storage 2 is connected to the compute node.
Configuring Access Rights
StarWind allows setting access restrictions for iSCSI initiators with StarWind Management Console.
Click on the host and select Access Rights. By doing this, you get the rules list. In that window, you can manage all rules: you can add a new one, change, or remove a rule. Also, you can see on that list the default rules which were created during configuring replication. They are set to “Allow” by default.
First, in order to segregate Storage 1 and Storage 2, deny all default connections on both servers from StarWind Management Console. Once this is done, you won’t be able to see any targets on the iSCSI initiators listing. Only sync channels are still on the list as they are allowed.
Setting up Storage 1 to be available for local Node 1 and Node 2
Right-click the Access rights tab and select Add rule.
Now, go to the Source, Destination, and Interface tabs and do some changes there.
In the Source tab, you can set IP Address, DNS name, or IQN restrictions for the source. You can learn IQN by clicking on a target in StarWind Management Console.
In my case, I use source IP addresses. Let’s see what’s on the list. 127.0.0.1 is a loopback accelerator used to connect the targets locally. Also, there are two iSCSI connections: Node 1 (172.16.10.11), and Node 2 (172.16.10.22).
In Destination, you can choose destination devices only by their IQNs.
In my case, there are only two targets IQNs.
To add a new Interface, you must select its IP address from the dropdown list. I will leave the default “All Interfaces” option. Why? Well, I segregate two environments: local Node 1 and Node 2 and the compute node. I do not need to do anything with interfaces as configuring both source and destination should be enough for that purpose.
Below, you can find the already configured rule for Storage 1.
Now, go to Storage 1 iSCSI Initiator Properties to check whether both Node 1 and Node 2 are available for connecting to Storage 1.
In the rule for Storage 2, I use the compute node iSCSI IP address as a Source. Thus, only that IP address can be used to reach Storage 2. I specify two devices IQNs as Destination.
If rules are complex, or there are too many entities on the list (i.e., nodes, interfaces, or devices), you can prioritize them in the Access Rules Order menu. Right-click the node and select Arrange Rules.
To modify priority, use arrows up and down.
Conclusion
I have configured two StarWind devices and segregated them between two environments.
As far as you see Access Rights feature is very simple and easy-to-use with an intuitive interface.
