Search
StarWind is a hyperconverged (HCI) vendor with focus on Enterprise ROBO, SMB & Edge

Access Rights in StarWind Virtual SAN® How it works

  • September 4, 2018
  • 8 min read
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.
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.

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.

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

 

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.

Hey! Found Vitalii’s article helpful? Looking to deploy a new, easy-to-manage, and cost-effective hyperconverged infrastructure?
Alex Bykovskyi
Alex Bykovskyi StarWind Virtual HCI Appliance Product Manager
Well, we can help you with this one! Building a new hyperconverged environment is a breeze with StarWind Virtual HCI Appliance (VHCA). It’s a complete hyperconverged infrastructure solution that combines hypervisor (vSphere, Hyper-V, Proxmox, or our custom version of KVM), software-defined storage (StarWind VSAN), and streamlined management tools. Interested in diving deeper into VHCA’s capabilities and features? Book your StarWind Virtual HCI Appliance demo today!