Category Archives: Switches

Turbo LAMP Stack for Today’s Demanding Application Workload

With the rise of cloud computing and mobile technologies, today’s market demands applications that deliver information from mounds of data to a myriad of end user devices. This data must be personalized, localized, and curated for the user and sent back to these devices. Businesses must retrieve data from their own systems—typically ERP, SCM and HRM applications–and then deliver it through systems of engagement with those end users.

 

The standard for building these systems is the LAMP stack, which consists of Linux as the operating system, an Apache web server, an open source relational database like MySQL or MariaDB, and PHP as the development language.

 

LAMP stack has become popular because each component can be theoretically interchanged and adapted without lock in to a specific vendor software stack.  These solutions have grown to support many business critical systems of engagement, despite the need for more powerful, scalable and reliable hardware systems. Ideally, the LAMP stack can be optimized for dynamic scale out as well as scale up virtualized infrastructures.

Continue reading

Effort-less Integration with Switch Abstraction Interface (SAI)

You realize that it is time to get a new car. You go to the local dealer and look around. You spot the car you want, and it meets your budget. You take a look at the list of features you wrote down at home, and you check each and every one of them.

A salesperson approaches you and asks: “How may I help you?

You say: “I like this one, is it possible to take it to a test drive?

The salesperson says: “Of course, may I see your driver’s license?” You hand him your license.

He takes a look and says: “I’m sorry, but you will need to take additional driving lessons to drive this model.

What? I don’t mind reading the owner’s manual, but why driving lessons? This is a car, not a school bus!

 

030315 amir sheffer lux_vs_eco_cars
Same driver’s license, right?

Obviously, each car make and model is different, but they share so much of their functionality, that you can change from one make and model to another almost instantly. If that wasn’t the case, we would all be forced to buy the same model again and again.

So why not in Ethernet switching?

The Ethernet switch industry faces a similar conflict. In the heart of almost every Ethernet switch you would find a switching ASIC, and while every ASIC is different, they share a lot of functionality. So yes, you should read the manual to operate them correctly, but why do you need driving lessons to use an ASIC from another manufacturer?

 

Continue reading

Open MLAG: The Road to the Open Ethernet Switch System

Making another step towards enabling a world of truly open Ethernet switches, Mellanox recently became the first vendor to release as open source,  implementation of Multi Chassis Link Aggregation Group, or as it is more commonly known – MLAG.

Mellanox is involved and contributes to other open source projects, such as OpenStack, ONIE, Puppet and others, and already contributed certain adaptor applications to the open source community. Mellanox is the first and only vendor to open-source its switch SDK API. Mellanox is also a leading member and contributor of the Open Compute Project, where it provides NICs, switches and software.

Continue reading

Enabling Application Performance in Data Center Environments

Ethernet switches are simple: they need to move packets around from port to port based on the attributes of each packet. There are plenty of switch vendors from which to choose. Differentiating in this saturated market is the aspiration of each vendor.

 

Mellanox Technologies switches are unique in this market. Not just “yet another switch” but a design based on a self-built switching ASIC and a variety of 1RU switches. These switches excel in performance compared to any other switch offered in the market. Being first and (still) the only vendor with a complete end-to-end 40GbE solution, Mellanox provides a complete interconnect solution and the ability to achieve the highest price-performance ratio.

Continue reading

Virtual Modular Switch (VMS) Values for Your Data Center

200361973-001

Building a large scale data center is not an easy task and one that includes considerable cost. The larger the cluster is, the larger the core switching element needs to be to carry traffic between servers and storage elements of the data center.

 

Multiple redundancy and distribution mechanisms are needed to avoid network outages, make implementations resilient and reduce the business impact of failed network elements.

 

The Virtual Modular Switch (VMS) solution provides a distributed core element to the data center.  The VMS is logically placed where you would traditionally place a chassis.  Its benefit is targeted for increased resiliency by offering built-in redundancy and distribution of the networking load between multiple elements.

Continue reading

Virtual Modular Switch (VMS): A Network Evolution Story – Part 3

Covered in previous blog posts (Part 1 and Part 2), the concept of the Virtual Modular Switch (VMS) is clearly an advantage for networks of medium to large scale.  As we move into huge networks where multiple modular switches are needed, this advantage reduces to the point where it is a matter of personal preference whether to implement using VMS or multiple chassis.

 

When the odds are even, this preference can come down to a matter of cost of equipment, cost of operating the equipment, certain network KPIs that need to be met or any other parameter that the network facilitator will care about.

 

The Mellanox implementation of VMS is based on our own ASIC design known as SwitchX. It is used as the fabric element in each of our Ethernet (and InfiniBand) product line of switches. SwitchX carries 36 high speed interfaces of standard 40 GbE which when used in a non-blocking fat tree topology, allows 18 ports to be used for external interfaces and 18 ports to be used as internal interfaces towards the spine layer of the VMS fat tree. Having 36 ports on each of the spine elements allows as many as 36 leaf elements.  The total number of external ports in a non-blocking two tier VMS is 36*18=648.

Continue reading

Automate the Fabric

If you search the internet for data center automation tools, you will come up with many options. You can easily find software tools that automate server provisioning, network equipment configuration or monitor the different elements. But you cannot find tools for automatic fabric configuration.

Fabrics become more popular these days. If traditional aggregation switching in data centers of Cloud providers, Web 2.0 providers, and large-scale enterprises has been based on modular switches, we now see them being replaced by fabrics – arrays of fixed, 1U switches. These fabrics increase the flexibility and efficiency in data center aggregation – lower cost of equipment, power reduction, better scalability and high resiliency.

Mellanox Virtual Modular Switch™ (VMS) is such a fabric, comprised of Mellanox 10, 40, and 56GbE fixed switches. It provides an optimized approach for aggregating racks. The VMS excels in its flexibility, power savings and performance.  Based on Mellanox switches, the VMS leverages the unique advantages of the SwitchX-2, the highest performing 36-port 40GbE switching IC.

The Need for Automation

blog2_storage_2014_Feb20

The scalability that the fabrics bring drives a change in the way they are configured. The legacy way to configure switches and routers is scripting – each device has its management interface, typically CLI, and when the right configuration script is applied to each switch, they interwork as a single fabric. However, this approach does not scale and one cannot configure big fabrics in mega data centers this way, since creating and maintaining scripts for many fixed switches can become a nightmare. So, fabric creation automation is required – a tool that can do it both automatically and fast, to allow short setup time.

Continue reading

Mellanox Boosts SDN and Open Source with New Switch Software

Authored by:  Amir Sheffer, Sr. Product Manager

This week we reinforced our commitment to Open Ethernet, open source and Software Defined Networking (SDN). With the latest software package for our Ethernet switches. Mellanox has added support for two widely used tools—OpenFlow and Puppet, among other important features.

The introduction of the new functionality allows users to move towards using more SDN and automation in their data centers. Compared to custom CLI scripts, OpenFlow and Puppet enable customers to control and monitor switches in a unified, centralized manner, thus simplifying the overall network management effort, with less time and cost. Forwarding rules, policies and configurations can be set once then applied to many switches across the network, automatically.

 

Amir Sheffer Blog 010714

Flexible OpenFlow Support

Mellanox Ethernet switches can now operate in OpenFlow hybrid switch mode, and expose both an OpenFlow forwarding pipeline and a locally-managed switching and routing pipeline. The OpenFlow forwarding pipeline utilizes thousands of processing rules (or flows), the highest number in the industry.

Switches interface with an OpenFlow controller using an integrated OpenFlow agent that allows direct access to the SwitchX®-2-based switch forwarding and routing planes.  The hybrid switch model provides the most robust, easy-to-use and efficient implementation, as it can forward a packet according to the OpenFlow configuration, when such a match is found, or can handle it by its forwarding/routing pipeline, according to the locally-managed switch control applications.

 

 

OpenFlow and Puppet 011014 - Diagram2

 

This allows customers to implement OpenFlow rules where they provide the most benefit without needing to move every switch completely to OpenFlow-only management. By processing non-OpenFlow data through its local management plane and leveraging the local forwarding pipeline, the hybrid switch increases network performance and efficiency, through faster processing of new flows as well as lower load on the controllers.

This is much more flexible than another OpenFlow switch mode called OpenFlow-only. This mode does not allow the switch to have a local control plane, so each and every flow must be configured by the OpenFlow controller, which in turn creates high load on the controllers, resulting in high latency and low efficiency.

Open-Source Automation via Puppet

Further enhancing the openness of our switches and the standardization of configuration, Mellanox switches now integrate the Puppet™ automation software agent. Puppet provides an open-source-based standard interface for device configuration and management. Tasks, such as software downloads, port configurations, and VLAN management can be managed automatically according to defined policies.  Mellanox’s implementation of the Puppet agent is Netdev, which is a vendor-neutral network abstraction framework. Mellanox Netdev has been submitted to the DevOps community and can be downloaded for free.

Customers have the choice to manage our switches using a CLI, Web GUI, SNMP, XML, and now Puppet and OpenFlow. This allows the flexibility to design the easiest and most scalable management solution for each environment, and expands Mellanox’s commitment to open source.

 OpenFlow and Puppet 011014 - Diagram3 revised

Mellanox is involved and contributes to other open source projects, such as OpenStackONIE, Quagga and others, and already contributed certain adaptor applications to the open source community. Mellanox is also a leading member and contributor of the Open Compute Project, where it provides NICs, switches and software.

RESOURCES

 

 

Virtual Modular Switch (VMS): A Network Evolution Story – Part 2

Distributed elements, in any sector, have their basic benefits and drawbacks compared to a single large tool.  It is similar to the preference of using small aircraft over a jumbo 747 for carrying passengers between proximate airfields or to using a bus vs. multiple private cars to move a football team around.

 

In networking, the analysis between a Virtual Modular Switch (VMS) and a Modular switch is cost and performance driven. A network facilitator will prefer a solution that gets the job done at the lowest cost. Such an analysis will produce different results based on the cluster’s size. If the number of network ports required for the solution can be fitted into a single chassis based device, this means that the use of the chassis, although equipped with redundant peripheral elements such as fans and power units, is presenting a single point of failure in the network. In order to solve this, a second chassis is introduced for sharing the load and provide connectivity in case of chassis failure.

 

From a financial point of view, assuming you had a chassis of 1000 ports in full use, you need to deploy a solution of 2000 ports for high availability purposes which means a 100% price increase. Using 2/3 of the ports in the chassis will translate to 200% increase on top of the real required investment and more such examples are easy to find. Other problem with the chassis is that it comes in very few form factors so if your solution requires 501 ports while the chassis of choice supports 500, you need to add another and pay the double cost.

 

Alternatively, breaking the solution into multiple devices in a VMS gives both improved granularity in terms of port count and high availability in terms of impact from failure. In loose terms, if the VMS consists of 20 switches, the failure of a switch translates to 5% loss of network capacity. Regardless from how powerful and complicated the chassis is, this is a classic case where the strength of many tops the strength of one.

 

Ran Almog VMS Part 2

 

 

Continue reading

The Train Has Left the Station, Open Ethernet is Happening

Authored by:   Amit Katz – Sr. Director, Product Management

Customers are tired of paying huge sums of money for Ethernet switches for no good reason. At some point, OpenFlow seemed like the way to change the networking world, but various factors such as overlay networks, changing market interests, and other unforeseen developments, it is hard to view OpenFlow today as a game-changer. While it remains a very important technology and provides a valuable mean of implementing certain functionalities, it has not created a revolution in the networking industry.

 

The real revolution that is occurring today is based on a combination of the momentum gained by the Open Compute Platform and the increasing number of switch software and hardware suppliers. Initiatives to open the switch, such as Mellanox’s Open Ethernet that was announced earlier this year, have placed us on the right path to bringing networking to where servers are today: affordable, open, and software-defined.

 

But is this revolution all about saving on cost? Not at all – cost is important but flexibility, openness, and the freedom to choose are equally important. One of the key elements in enabling vendor selection elasticity is Open Network Install Environment (ONIE), which decouples the switch hardware from its software, enabling vendors to provide something very similar to what we see in the server world: hardware without an Operating System. That means customer can buy a server with many ports and install their choice of OS on top of it. In the event that the customer wants to change the OS, the lion’s share of the investment (the hardware piece) is protected.

Continue reading