Configuration Cleanup

[JustinHenne]

I have been out of working with NAS setup for a while and due to a very rushed timeline that has just passed I am in the process of cleaning up the mess. This is also my first time working with TrueNAS.

Here is a short of the setup. The network is 100% offline. The 2 BNXT connections are configured with static IP's. All drives are in 1 RAID'd pool. That is connected to 3 Esxi servers (as a datastore) using NFS (all tied to the management IP). There are 2 not configured IGB NIC's that will not allow me to us the same subnet as the BNXT.

What I am looking to do is to setup the additional NIC's with IP's and move the management to one of them. Once that is done I would like to bond the 2 BNXT's together to allow for a faster connection and redundancy. If possible I want to keep all the IP's in the same grouping (meaning something like 192.x.x.100-103). With 192.x.x.100 and 101 being the management IGB and the 102,103 being the BNXT bonded datastore (NFS) connection

What I am looking for is any documentation/recommendations/insight that can point me in the right direction. Since this is already operational and I do have some data stored on the NAS I am working with caution.

Thanks in advance for any/all help.

 

[Arwen]

First off, unless the NICs are bonded into a LACP group, they can't be in the same sub-net.

Resource - Multiple network interfaces on a single subnet

We've had a number of people over the years bring up the topic of multiple network interfaces on a single subnet. Often done by Windows administrators or storage admins, where it works to varying degrees, this is sadly not proper IP networking...

www.truenas.com

Yes, you can make one of the 1Gbps NICs as a management NIC, but in a different sub-net as the 2 BNXT bonded NICs. With a bond / lagg / LACP you only need 1 IP address, though you can add more in the same sub-net as aliases.

Their are lots of Resources and sticky forum threads that can help. The Resources can be accessed at the top of any forum web page. Many Resource posts have discussion threads with additional information. The sticky forum threads are at the top of the sub-forum, in which they reside.

Here are some Resources related to your questions and configuration:

Resource - LACP ... friend or foe?

Too many LACP discussions lately. Here's what you need to know. 1) Link aggregation groups are an interesting way to boost network throughput. They're typically managed by a protocol called Link Aggregation Control Protocol (LACP). Link...

www.truenas.com

10 Gig Networking Primer

This is a discussion of high speed networking for newcomers, with specific emphasis on practical small- to medium-scale deployments for home labs or small office users. It originated with a forum thread located here that has many pages of...

www.truenas.com

Resource - The path to success for block storage

ZFS does two different things very well. One is storage of large sequentially-written files, such as archives, logs, or data files, where the file does not have the middle bits modified after creation. This is optimal for RAIDZ. It's what most...

www.truenas.com

Resource - Sync writes, or: Why is my ESXi NFS so slow, and why is iSCSI faster?

This post is not specific to ESXi, however, ESXi users typically experience more trouble with this topic due to the way VMware works. When an application on a client machine wishes to write something to storage, it issues a write request. On a...

www.truenas.com

Some differences between RAIDZ and mirrors, and why we use mirrors for block storage

ZFS is a complicated, powerful system. Unfortunately, it isn't actually magic, and there's a lot of opportunity for disappointment if you don't understand what's going on. RAIDZ (including Z2, Z3) is good for storing large sequential files...

www.truenas.com

Since you are a new user to the forum, we don't know much about you, except what you wrote. It might be helpful for you to describe your hardware in details and your pool / configuration in detail as well. We have occasional new users that make configuration mistakes that are hard to correct later. But, early on would have been easier.