Network configuration model of any BrickStor appliance is essentially identical and as follows. All systems have an even number, two or four onboard 1GbE or 10GbE RJ45 interfaces clustered together to the right of the power supplies. Onboard 10GbE, 25GbE, etc. fiber or copper interfaces are typically included with every system and either reside on one of the two riser cards or installed into a special interface on the system board, on the far-right edge of the chassis. Under normal circumstances the leftmost Ethernet interface is automatically configured for the purposes of management access, which includes ‘ssh’ for some initial setup and for diagnostic as well as some feature configuration not currently accessible via the graphical management interface, as well as for access via the graphical management interface.

All physical interfaces are abstracted with one or multiple virtual interfaces, which do not typically share the MAC address of their underlying physical interface. Relationship of virtual interfaces to physical is many to one, meaning a single physical interface may possess one or multiple virtual interfaces. Multiple virtual interface over a single physical interface are common in VLAN tagging scenarios, which we discuss later in the document.

It is also possible to bond links into what we commonly refer to as an aggregate, more commonly known as a LAG (Link Aggregation Group), with or without LACP capability. Due to various complexities of configuration and the wide range of possible configurations we will not discuss the details of this configuration in this guide. If this is a requirement, please contact RackTop support for details.

Multiple virtual interfaces do not share a MAC address, instead each is assigned a randomly generated address, unless one is explicitly provided. We will not discuss the details of this customization here. If this is a requirement, please contact RackTop support for details.

The appliance ships with at least one already existing virtual interface named ‘admin0’, configured to automatically obtain an IP address via DHCP to ease initial configuration whenever possible. This is the primary management interface, meaning this is the interface used to manage the machine as an administrator, not meant for data traffic normally.

At least one data interface is required to expose files via one or more supported protocols: AFP, NFS, and SMB. For all interfaces other than management, which typically will already exist and will not need to be created or re-created, use the naming convention 'dataXX', where ‘XX’ is a non-negative numeric value starting with 0. All physical interfaces are suitable candidates, sans the first interface used for management as discussed previously. Needs vary, but a typical configuration will use 10GbE, 25GbE, and similar high bandwidth interfaces for all data access.

Virtual interfaces on BrickStorOS are configured via ‘dladm’, which must be created before a physical link can be used. After a system has been connected to network equipment, information about state of physical interfaces can be seen with a command in the following example. A typical output follows this general appearance:

# dladm show-phys

In the above example it can be seen that the link named ‘igb0’ is up and configured at 1GbE. This is the physical interface on which virtual interface ‘admin0’ is provisioned. Typically, data interfaces will follow the naming convention prescribed earlier and use high speed interfaces, commonly identified as ixgbeXX, where XX is a non-negative numeric value starting with 0. Following is an example of establishing such a data interface over physical interface called ‘ixgbe0’.

# dladm create-vnic -l ixgbe0 data0

Once a virtual interface has been created, an IP address must be assigned to this interface. IP interfaces on BrickStorOS are configured via ‘ipadm’. The default ‘admin0’ IP interface cannot be modified since it is a temporary interface from an ipadm standpoint, instead it needs to be created persistently if a static IP address assignment is required. If you need to create a static IP, perform the following either via ssh, while connected via an IP address assigned to another interface, or directly via console of virtual console:

# ipadm delete-if admin0

# ipadm create-if admin0

# ipadm create-addr –T static –a local=x.x.x.x/24 admin0/v4

Where in the last command ‘x.x.x.x/24’ is the IP address/CIDR and ‘admin0/v4’ is the interface name and IP version (4 or 6). Upon creation of an IP interface, two addresses are configured, IPv4 and IPv6. For all intents and purposes IPv6 interface should be ignored usually.

If, in the previous steps, you have deleted an interface, you may not have a default gateway if the interface that was deleted was the only one on its subnet. You can find your default gateway by using:

# netstat -rn

Routing Table: IPv4

Routing Table: IPv6

From there, under the flags column you are looking for a ‘G’, which stands for gateway and a ‘default’ designation under the ‘Destination’ column. You can add a new permanent default route using the following:

# route –p add default x.x.x.x

Where x.x.x.x is your default gateway. You can now see your default route in ‘netstat –rn’

By default BSRAPID is configured to listen on all interfaces on port 8443. However, the service can be configured to listen on a different port and on specific IP addresses. To configure this behavior, change the Listen Address in /etc/racktop/bsrapid/bsrapid.conf

Configure BSRAPID to listen on any interface with port 5443

ListenAddress = “:5443”

Configure BSRAPID to listen only on 10.1.12.120 port 5443

ListenAddress = “10.1.12.120:5443”

Set the time zone of BrickStor through the command line by editing the following file.

# tzselect

Then follow the prompts. A reboot is required for the changes to take effect.

Your BrickStor storage appliance comes equipped with a Remote Management Module frequently abbreviated to RMM. RackTop recommends connecting this Ethernet interface as well as the ‘admin0’ management Ethernet interface to a dedicated management network, if one is available. Separation of management and administration concerns from data access is a recommended best practice. This enables you to access the appliance as if you were standing in front of it with a crash cart or KVM, even when services such as SSH are down. You can use RMM to power cycle the machine or see and use the console. If RMM is already configured, you can find the IP address with this command from the terminal:

# bsradm hw rmm

IpSource: DHCP Address

IpAddress: 192.168.0.101

SubnetMask: 255.255.255.0

MacAddress: 00:1e:67:50:c7:c1

SnmpCommunityString: public

DefaultGateway: 192.168.0.1

Vlan: 0

Once you have the IP address, you can login to RMM via your browser. You will need to use Java to access the console and this will most likely require adding a security exception for the IP address in the Java control panel.

To allow a given local account administrative access of a BrickStor appliance via BrickStor SP Manager, this account must be in the ‘bsradmins’ group of the appliance. To add a user to the group, run the following command, replacing username placeholder with actual local account name:

# usermod -G bsradmins <username>

To add e-mail addresses to receive notifications from the BrickStor appliance, use the following command format at the terminal:

# bsradm notify add <email address> –all

Other options besides the “all” notifications options are:

--system Add to system notification list

--reports Add to reports notification list

--faults Add to faults notification list

To list users and their notification types, use:

# bsradm notify show

And to remove users from their notification, use:

# bsradm notify remove <email address> --all

The first step for making a CIFS share available for users is to join Active Directory, which requires several configuration steps before joining the domain will be possible. A machine account will be created for a BrickStor upon successful domain join operation. This machine account will enable users to passthrough authenticate and be either permitted or denied access to shares without requiring separate authentication against the BrickStor. In other words, once users are logged into Active Directory, their authentication information is stored on their system and in Active Directory, and no further authentication prompts are necessary in order to access shares on a domain-joined BrickStor.

Active Directory requires certain attributes of name resolution, which usually means the BrickStor must be configured to resolve names against domain in the given instance of Active Directory to which it will be bound. BrickStor’s domain setting must also be set to name of domain being joined.

First, validate what is currently configured, because no change may be necessary. Check currently configured domain with the following command:

# bsradm dns domain get

If the value reported is correct, that is, it matches the Active Directory domain name, no change is necessary. If, however a modification is necessary, change should be made with the following command, replacing placeholder ‘domain.tld’ with actual fully qualified Active Directory domain name:

# bsradm dns domain set <domain.tld>

Next, confirm that correct DNS resolvers are configured, and if not, make necessary changes. In most environments at least two DNS servers will be configured and BrickStor must point to these resolvers, which in typical Active Directory configurations will be domain controllers also, or commonly member servers with a dedicated DNS function.

First, validate what is currently configured, because no change may be necessary. Check currently configured domain name resolution servers with the following command:

# bsradm dns ns show

If values reported are correct, no further resolver changes should be necessary. If, however DNS servers need changing, use the following commands to add/remove entries, replacing placeholder ‘address’ with IP address of system being added or removed.

# bsradm dns ns add <address>

# bsradm dns ns remove <address>

The command for joining the storage appliance to the domain is:

# smbadm join -y -u <Administrator Account> <domain.tld>

Where ‘Administrator’ is the name of the user you want to use to join the domain. This account is only used to create the computer object and does not need to be a service account. You will be prompted for a password. If the join fails, please double check your username and password and the settings in /etc/resolv.conf.

To view the domain type:

# smbadm list

Also verify that forward and reverse lookups are correct within active directory for the BrickStor.

There are several scripts included with BrickStor for monitoring the performance of the storage portion of the system. Dtrace and kstat are powerful tools for analyzing the storage performance and behavior.