Written by Shawn Mall, Systems Engineer, Big Switch
There is no question that software defined networking (SDN) is getting a lot of buzz these days. You might be thinking “it’s not ready,” or “it’s only for the big boys.” That assumption is wrong. SDN is a real and viable solution that can improve efficiencies, reduce costs, and enhance troubleshooting. We could spend a whole article on what SDN truly is, but I will spare the readers on that topic for now, just understand when I refer to SDN, I am primarily focused on automation and orchestration.
The reasons one should look at SDN, and particularly Big Switch, and realize the benefits:
- Time needed to deploy the network AND network services drops dramatically
- Cost of whitebox/britebox switching is a fraction of traditional switching
- Eliminate box-by-box management and troubleshooting
- A single pane of glass for configuring, monitoring, and troubleshooting
- Programmability – Providing numerous options for automating tasks and gathering data from the network
- Completely baked solutions that are ready to deploy for VMware and OpenStack, which integrate those orchestration and automation platforms into the Big Switch solution for zero-touch provisioning of the network
- Less error prone with automation and orchestration
- Multi-tenancy and Multi-hypervisor support
- Ability to do service chaining and service insertion on the fly
The benefits of SDN are much more than listed above, but in my conversations with customers, these are always at the top of the list. If you are standing up a greenfield environment, now is the best time to think about and plan an SDN strategy. If it’s a brownfield network, SDN implementations, including Big Switch Networks, can sit alongside your existing network as you ramp up with this next generation networking approach. With some environments, it doesn’t make sense to be 100% software defined, and that’s okay too. Place SDN where it makes sense, where you can take advantage of the benefits.
You don’t need to have 20 data centers, or hundreds of servers to take advantage of the benefits of SDN. The beauty of SDN is that it can be deployed in a variety of different environments, regardless of size.
The first step is getting your hands dirty, and playing with the technology. You can do this through a proof-of-concept (POC), or even our hands-on, hosted BSN Labs, which is free and available via your browser. Hands on experience through vendors like Big Switch and others, allow you to understand how the solution works, exactly how it can benefit your organization, and why SDN is so powerful.
Getting from here to there
Moving to an SDN fabric is similar to any previous infrastructure upgrades you might have undertaken. You will want to thoroughly understand the dependencies – from physical cable plant, compute resources, rack configuration, etc. to the duration of any outages and their impact on your operations. This comprehensive project-managed approach is a best practice for any change to your network. There are two common scenarios when migrating: either ‘expand and move’ or ‘in-place’ migrations.
Expand and move
This approach is most common when users are moving their app environment from a standard virtualization platform to OpenStack. In this example, a BCF pod with Physical + Virtual Fabric (P+V) that integrates with OpenStack, is stood up as a new environment. Once a new pod is built it does not disrupt existing infrastructure, but it is connected to the existing core network.
Once the fabric is deployed, you will be able to share your underlying data center network infrastructure across not only multiple users/projects, but also multiple instances of OpenStack. The network automatically and dynamically provisions for new workloads, with NFV service insertion, and – with the P+V fabric – improves the scale and performance of Neutron. Then the nature of self-service provides end users access to the new environment and can begin migrating workloads to the new platform.
In place migration
An example of this migration strategy is an enterprise taking their mostly vSphere environment and existing compute from a legacy two or three-tier architecture, to Big Cloud Fabric’s single L2/L3 switch fabric.
To envision this migration at a high level, you would build your BCF pod, but since you are not adding new racks as in the ‘expand and move’ use case, leaf switch pairs would be mounted in racks, often next to legacy ToRs. After bringing up the Big Cloud Fabric, you would provision fabric segments (L2 broadcast domains) to match your existing server/VM VLAN plans, and also the port membership to bring traffic into those segments. Then, you would trunk these segments to your existing infrastructure, essentially extending legacy VLANs across both existing infrastructure and the new BCF pod. From there, you would utilize the same layer 3 routing/IP infrastructure, and slowly begin to move those L3 gateways for those workloads from the existing network routers, to BCF.
Migrating is not bad or scary, as it has been depicted by some. Many have simply not been given the correct picture on how the technology works, or how it can be used without hiring a team of SDN experts. The benefits are here today, and fairly simple to use. One can start small and grow as they wish, and likely become a shining star to their management by showcasing the cost and time savings that go along with SDN.