Share on Facebook0Share on Google+0Share on LinkedIn0Share on Reddit2Tweet about this on Twitter0

Introduction

This blog article discusses Access Rights feature and its implementation in StarWind Virtual SAN 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 StarWind Virtual SAN.

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.

wp-image-9846

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.

wp-image-9847

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.

wp-image-9848

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).

wp-image-9849

In Destination, you can choose destination devices only by their IQNs.

In my case, there are only two targets IQNs.

wp-image-9850

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.

wp-image-9851

Below, you can find the already configured rule for Storage 1.

wp-image-9852

Now, go to Storage 1 iSCSI Initiator Properties to check whether both Node 1 and Node 2 are available for connecting to Storage 1.

wp-image-9853

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.

wp-image-9854

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.

wp-image-9855

To modify priority, use arrows up and down.

wp-image-9856

StarWind Virtual SAN eliminates any need for physical shared storage just by mirroring internal flash and storage resources between hypervisor servers. Furthermore, the solution can be run on the off-the-shelf hardware. Such design allows StarWind Virtual SAN to not only achieve high performance and efficient hardware utilization but also reduce operational and capital expenses.

Learn more about ➡ StarWind Virtual SAN.

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.

Views All Time
4
Views Today
5
Appreciate how useful this article was to you?
No Ratings Yet
Loading...
Back to blog
The following two tabs change content below.
Vitalii Feshchenko
Vitalii Feshchenko
Vitalii is a Post-Sales Support Engineer at StarWind about 2 years. Has a broad knowledge of storage, virtualization, backup, and infrastructure implementation. Ping pong as a hobby.