Need to build a small business server cluster for the purpose of crunching data. It will not host a web site that needs to be available 24/7.
- It does need to support servers that host Redis, a Cassandra database cluster, and a Python web server. Operating system will most likely be Centos 6.4
- Other servers in the cluster should be able to communicate very fast with each other, especially the Redis server. This will probably require the use of internal IP addresses?
- We will need to use multi-data center replication to synchronize the Cassandra cluster with the one that we currently have hosted on the cloud
Was looking into network switches and we are unsure of the appropriate specifications that we should be looking for.
- Does the switch need to be "managed" or can it be "unmanged"?
- Does the switch need to support IPv6 or just IPv4?
- Do we need an enterprise level Cisco switch, or can we go with something like a $200 DLink managed (or unmanaged) small business switch?
Thanks so much!
On the surface it sounds like you just need a layer 2 Ethernet switch. Clarify for me, though, if you don't already have equipment handling the connection to "the cloud" where you host your replicated Cassandra cluster. You'll need a router (and, ideally, a firewall and potentially a network address translation facility since you're might use "internal IP addresses") to connect this network to another (like the Internet) if you don't already have that. A layer 2 switch isn't going to do that for you and, more than likely, the feature set of most moderately-priced layer 3 switches won't be "rich" enough to support everything you need your Internet router to do. You may be in a situation where you need both a router and a switch (or a router with some switch ports on it).
The applications you describe won't necessarily need a switch that supports routing functionality (a "layer 3 switch"). Any layer 2 switch can switch IPv4 and IPv6 traffic because it's operating at a lower layer and blissfully unaware of the layers above. If you need the switch to have an IPv6-addressable management interface, however, that will be something you'll want to shop for.
When you say "This will probably require the use of internal IP addresses." that makes me think that the machines in question have multiple network interfaces-- internal-facing and external. If that's the case I'd strongly recommend getting two switches-- one to host the internal network and one to host the external. You technically can use virtual LAN (VLAN) functionality to "partition" a single switch into multiple logical layer 2 switches but there's a non-zero risk of "cross-over" traffic between the VLANs. If the internal traffic isn't suitable to expose to the Internet then I'd put it on switches that are physically separate from switches handling Internet traffic.
I always prefer managed switches because I want to see packet and byte counts on ports, see the switch's CPU utilization, get logs, etc. Moreover, I want to be able to graph traffic flows (using SNMP-based tools like Cacti or MRTG, typically) to diagnose bottlenecks. I also want to be able to look at the switch's MAC address table when I'm diagnosing oddball issues (NICs that go crazy and start making up wacky MACs, etc). The cost for a low-end managed switch isn't bad and it doesn't leave you "blind" like an unmanaged switch does.
re: a specific switch manufacturer - We don't really make recommendations here. As @syneticon-dj says in his answer, it's up to you to decide what's appropriate for your needs. The "higher-end" manufacturers often require maintenance agreements to receive support entitlements (including, in some cases, hardware warranty). It may just be cheaper to purchase a spare and leave it sit on the shelf. I've had little need for support from switch manufacturers for software issue resolution outside of dedicated iSCSI networks where, arguably, everything stacked on top of your storage solution lives and dies by the efficiency and reliability of your switches.
A managed switch is going to offer additional functionality (e.g. redundancy, stacking, troubleshooting, reporting, VLANs, aggregation) compared to an unmanaged switch. Typically, technical or organizational requirements would push you one way or the other - you either need the functionality (and buy managed switches) or you don't.
The IP protocol version is only relevant if your switch is exposing a management interface through IP or is in fact a router which would forward IPv4 / IPv6 packets. Again, whether you do or do not need that is mostly answered by the question if you do or do not (intend to) use IPv6.
This is something only you will be able to answer. Take a good look at the tech spec sheets, make sure that everything you need supported feature-wise indeed is supported, get a tech sample unit to test it in a lab.
Spec sheets aside, a cheap small business switch would have an entirely different level of support provided by the manufacturer than an enterprise-level switch. This not only applies to hardware failures and replacement policies but also and especially to software-related switch problems.
D-Link (as well as Netgear and many other players in this market) is not necessarily designing, building or programming the switch models at the lower end of their product range. The low-cost models are typically just OEM devices which have been re-labeled to the respective brand. So all support you can get with software-related issues is at the level of "did you try to switch it off and on again?". If you find features not working as expected with this kind of switches, your only remedy is to bin them and buy ones known to work. This certainly is different with Cisco or other major brands where you indeed do get support engineers deserving their name. And where issues get resolved through firmware updates. Unsurprisingly, it comes with a different price tag than the Hobson's choice.
This being said, if all you are after is the basic feature set (e.g. just switching, no complex topologies) you are very unlikely to ever get in a situation where you are facing a bug requiring fixing, so there is no general "anything but Cisco is crap" rule.