Monthly Archives: January 2014

Mellanox Technologies Delivers the World’s First 40GbE NIC for OCP Servers

Last year, Open Compute Project (OCP) launched a new network project focused on developing operating system agnostic switches to address the need for a highly efficient and cost effective open switch platform. Mellanox Technologies collaborated with Cumulus Networks and the OCP community to define unified and open drivers for the OCP switch hardware platforms. As a result, any software provider can now deliver a networking operating system to the open switch specifications on top of the Open Network Install Environment (ONIE) boot loader.

At the upcoming OCP Summit, Mellanox will present recent technical advances such as loading Net-OS on an x86 system with ONIE, OCP platform control using Linux sysfs calls, full L2 and L3 Open Ethernet Switch API, and also demonstrate Open SwitchX SDK. To support this, Mellanox developed SX1024-OCP, a SwitchX®-2-based TOR switch which supports 48 10GbE SFP+ ports and up to 12 40GbE QSFP ports.

The SX1024-OCP enables non-blocking connectivity within the OCP’s Open Rack and 1.92Tb/s throughput. Alternatively,40GBE NIC designed with OCP Compliant ConnectX-3 it can enable 60 10GbE server ports when using QSFP+ to SFP+ breakout cables to increase rack efficiency for less bandwidth demanding applications.

Mellanox also introduced SX1036-OCP, a SwitchX-2-based spine switch, which supports 36 40GbE QSFP ports. The SX1036-OCP enables non-blocking connectivity between the racks. These open source switches are the first switches on the market to support ONIE over x86 dual core processors.

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

 

 

Process Affinity: Hop on the Bus, Gus!

This is an excerpt of a post published today on the Cisco HPC Networking blog by Joshua Ladd, Mellanox:

At some point in the process of pondering this blog post I noticed that my subconscious had, much to my annoyance, registered a snippet of the chorus to Paul Simon’s timeless classic “50 Ways to Leave Your Lover” with my brain’s internal progress thread. Seemingly, endlessly repeating, billions of times over (well, at least ten times over) the catchy hook that offers one, of presumably 50, possible ways to leave one’s lover – “Hop on the bus, Gus.” Assuming Gus does indeed wish to extricate himself from a passionate predicament, this seems a reasonable suggestion. But, supposing Gus has a really jilted lover; his response to Mr. Simon’s exhortation might be “Just how many hops to that damn bus, Paul?”

HPC practitioners may find themselves asking a similar question, though in a somewhat less contentious context (pun intended.) Given the complexity of modern HPC systems with their increasingly stratified memory subsystems and myriad ways of interconnecting memory, networking, computing, and storage components such as NUMA nodes, computational accelerators, host channel adapters, NICs, VICs, JBODs, Target Channel Adapters, etc., reasoning about process placement has become a much more complex task with much larger performance implications between the “best” and the “worst” placement policies. To compound this complexity, the “best” and “worse” placement necessarily depends upon the specific application instance and its communication and I/O pattern. Indeed, an in-depth discussion on Open MPI’s sophisticated process affinity system is far beyond the scope of this humble blog post and I refer the interested reader to the deep dive talk Jeff Squyres (Cisco) gave at Euro MPI on this topic.

In this posting I’ll only consider the problem framed by Gus’ hypothetical query; How can one map MPI processes as close to an I/O device as possible thereby minimizing data movement or ‘hops’ through the intranode interconnect for those processes? This is a very reasonable request but the ability to automate this process has remained mostly absent in modern HPC middleware. Fortunately, powerful tools such as “hwloc” are available to help us with just such a task. Hwloc usually manipulates processing units and memory, but it can also discover I/O devices and report their locality as well. In simplest terms, this can be leveraged to place I/O intensive applications on cores near the I/O devices they use. Whereas Gus probably didn’t have the luxury to choose his locality so as to minimize the number of hops necessary to get on his bus, Open MPI, with the help of hwloc, now provides a mechanism for mapping MPI processes to NUMA nodes “closest” to an I/O device.

Read the full text of the blog here.

Joshua Ladd is an Open MPI developer & HPC algorithms engineer at Mellanox Technologies.  His primary interests reside in algorithm design and development for extreme-scale high performance computing systems. Prior to joining Mellanox Technologies, Josh was a staff research scientist at the Oak Ridge National Lab where he was engaged in R&D on high-performance communication middleware.  Josh holds a B.S., M.S., and Ph.D. all in applied mathematics.

 

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