This is a blog series about our new storage solution: the Discovery Series from DataGravity. It covers why we selected the solution. We'll continue through our initial journey from selection to standardization, deployment and testing.
Congratulations, by now you’ve hopefully decided to order, or have ordered an array. Here are some things to work through to get prepared.
For controller connectivity, you can choose between 10-GBASE-T over Cat6 cables or opt for SFP+ ports for flexibility. With SFP+, you can choose passive 2-pair TwinAx cables for a low-cost, low-power, direct-attach setup, or you can choose the optical route and typically go with 10GBASE-SR. You’ll want to have a redundant set of switches (recommended in a stack) four available ports and the necessary Cat6, TwinAx or fiber cables. If you go with fiber, pick up transceivers and possibly attenuators if you need to reduce power levels into acceptable ranges for the distance installed.
The switching architecture is extremely important. Find reliable, low-latency switches that have standard storage configuration capabilities – jumbo frames, flow control and storm control. Please don’t skimp here. If you desire any recommendations, please reach out. Use supported, industry-standard network interfaces, switches, optics and cables for a reliable deployment.
Shared Network Architecture
I’ve always recommended and installed storage networks as dedicated for storage. With the initial release of the discovery series, you’ll configure your 10Gb interfaces (Bond 1) for multiple roles when using the “Web UI and Data” setup option:
- Diagnostic – One IP per controller, utilized to access each controller and used for outbound communication – services such as AD, DNS, LDAP, NIS, NTP, SMTP, etc. Place these typically on your server network (LAN).
- Public IP – A floating IP, the primary IP that you will use for inbound communication for management of the Discovery Series plus, by default, CIFS/SMB traffic. Place this typically on your server network as well.
- Storage – Used for iSCSI and/or NFS. Dedicate at least one VLAN for each storage protocol, and ensure jumbo frames are configured.
This was probably the hardest thing to wrap my head around – bringing my server traffic into my storage network. It wasn’t something I was used to, so it required some adjustments to the network. There are plenty of ways to accomplish this, but be sure to consider high speed, redundant links wherever they make sense. If for the diagnostic and public interface you’re only dealing with management traffic, then 1Gb is suitable. However, if you plan to run CIFS/SMB traffic, then ensure you have enough bandwidth available back into your primary network.
There is another setup option for “Web UI Only” that keeps management and diagnostics on Bond0 and the 1Gb links. It also permits you to spin up your iSCSI/NFS data connections on Bond1. For simplicity, reduction of cables and higher-speed CIFS/SMB, we opted to use Bond1.
You will need to have at least two VLANs: one for management and one for your data if you’re using a single storage protocol. In my environment, I have this configured:
- Management – Untagged on my server network
- iSCSI – Tagged into my iSCSI network
- NFS1 – Tagged into my first NFS network
- NFS2 – Tagged into my second NFS network
On the storage networks, I maintain connectivity for my server adapters into untagged ports. A single iSCSI network is suitable since the protocol supports multipathing. Over on NFS however, we do not have multiple paths. We will maintain a single connection, and while VMware can have adapters fail over, it will initiate a connection over the first suitable VMkernel port. The mention of two NFS networks is for redundancy as well as scaling out for maximum possible bandwidth. VMware-specific configuration guidance is upcoming in part five of the series.
Now that the various networks are planned out, start gathering available IP addresses and planning out firewall rules if necessary. Having these prepared in advance should help the setup process go much more smoothly:
- Public Address – Single IP, subnet mask and default gateway address. Inbound HTTPS traffic is minimally required, possibly bring in CIFS/SMB as well.
- Diagnostic IPs – Two IPs, one for each controller, subnet mask and default gateway address. Inbound SSH traffic is recommended for support. Outbound traffic should be permitted for the services that are utilized. Don’t lock things down too far before the setup is complete and you’ve had a chance to survey the traffic that the controllers are sending out.
- DNS Servers / Domain Name – Have these IPs handy, possibly your domain controllers and active directory DNS name. You’ll input these during setup, and they will be validated.
- NTP Servers – Utilize one on your network if it exists. Consider setting one up on Windows following this article or utilize a public source such as the NTP Pool. It really helps to have an in-sync clock for proper event correlation, and it is especially important for authentication services
- NIS – Domain name and IP address/host name, if used.
- Active Directory / LDAP – Domain name, server information, etc.
- SMTP – A server IP/host name plus authentication information if it’s required
Depending on your authentication configuration, you will need to have different information prepared:
- Active Directory – It’s a very simple setup. You will need to provide a username and password that have rights to join machines to the domain. The discovery series will become a domain member and authentication will start to work. Specify an Active Directory security group for users with super user privileges, storage admin privileges and another for standard user privileges. We highly recommend creating custom groups and not utilizing the built-in Domain Admins/Domain Users groups to keep SIDs unique.
- LDAP – If you’re using LDAP in your infrastructure, the page should be fairly straightforward. Prepare the standard attributes such as the Base DN, Bind (root) DN and Bind DN password. Plan for the base User and Group DNs and then the attribute maps (such as sAMAccountName).
- VMware – Credentials with enough rights to view the attributes about virtual machines, manage snapshots and access diagnostic logging. It’s recommended to target these to a vCenter instance and apply the permissions across the entire infrastructure. You can specify per-host credentials with the absence of vCenter. With the initial release of the Discovery Series, you need to keep the username to 32 characters or less. Even though longer usernames will validate, there’s a limitation that prevents the saving of the credentials.
Start to think about Discovery Point policies now. First and foremost, you will want one called InitialLoad-None with all schedules disabled that is essential for data migrations. The out-of-the-box default policy fires every four hours as well as with 3% data change. Consider what suits your business requirements the best, how often should things be snapped for rollback and discovery, and especially how long should the rollback and change-based discovery be available? Discovery Points can be applied to an entire mount point, volume or individual virtual machine. There’s a great deal of flexibility, so be sure to consider what’s important to your business and, possibly, discuss the plan internally.
More to Come
The next article in the blog series will cover the initial configuration of a Discovery Series array. If you’d like any further information on the solution, please don’t hesitate to reach out! We’d love to answer any questions you have, and it doesn’t matter where you’re located – we’re all over the place too!
If you haven’t yet, be sure to check out our other posts within this series:
- Introduction – Why Data Gravity?
- Acquisition / Cabling – Initial Impressions
- Preparations / Network Architecture
- Initial Configuration