Resultados 1 a 3 de 3
  1. #1
    WHT-BR Top Member
    Data de Ingresso
    Dec 2010

    [EN] OpenStack Neutron is suitable for deployments of 30 nodes or fewer

    Networking is becoming a bigger issue for OpenStack as deployments get more serious.

    Mirantis announced today that its OpenStack distribution has added support for Juniper Contrail and OpenContrail.

    It fits the usual mantra of offering customers choices and all that. But Mirantis’ motivations are more specific, Chief Marketing Officer Boris Renski says.

    Large OpenStack deployments require some networking help. VMware‘s NSX would do the trick and has been a default choice for Mirantis’ customers; it’s already supported in Mirantis OpenStack. But many customers already use a VMware environment in their data centers — banks are a good example — and they’re moving to OpenStack because they want to avoid vendor lock-in. To stay true to that philosophy, these customers would need an alternative to NSX.

    Contrail is the second most popular networking choice for Mirantis’ user base, so Mirantis is expanding its partnership with Juniper. It’s adding Contrail support and providing a reference design that works with Mirantis OpenStack 6.0, which is compatible with the OpenStack Juno release that arrived last year.

    This doesn’t mean that you get NSX or Contrail truly bundled in with OpenStack, by the way. The way it works is: You set up one of those networking environments yourself, and through APIs, Mirantis’ OpenStack will take advantage of it.

    OpenStack Hits the Limit

    Networking is becoming a bigger issue for OpenStack as deployments get more serious. The OpenStack Neutron project, which handles networking, is suitable for deployments of about 30 nodes or fewer, Renski says. Beyond that size, “everybody knows” that plain vanilla Neutron won’t scale properly, he says.

    “It’s not so much about the number of nodes. It’s about the intensity of the network coverage,” he says. In other words, the scaling problem relates to how frequently nodes are activated or deactivated, or how often the network changes. “Sometimes it can get as bad as the entire cluster going down.”

    So, companies often start with a small OpenStack pilot. Once it needs to grow beyond about 30 nodes, though, they need to make a networking choice. NSX-MH, the multi-hypervisor version of that software, has been the most popular choice, Renski says. Contrail, in both the commercial and open source varieties, has been second.

    Renski thinks that’s because “Juniper has done a great job aligning with the OpenStack community.” The company has been active on OpenStack mailing lists and responsive when questions and problems get discussed there, he says.

    “They’re on the path to be the Ceph of the networking space,” Renski says, citing the open source project that’s become the de facto block-storage standard for OpenStack. “They’re not quite there yet, but more and more customers we’re seeing are adopting Contrail.”

    The “Ceph of networking” crown is still up for grabs, though. Midokura recently open-sourced its MidoNet platform in hopes of contending for that title. Akanda, which shares some lineage with Ceph, is trying the same thing.

    VMware could be a candidate as well, especially now that the company offers its own OpenStack distribution in addition to NSX, providing an all-in-one package for those customers who want it.

    Mirantis might add support for other network virtualization options later. Some of its customers are using Big Switch or Midokura technology; whether that warrants integration is going to be a matter of demand, Renski says.

    Adding more options would help bolster Mirantis’ status as a pure OpenStack provider. Unlike HP, VMware, or even Red Hat, Mirantis doesn’t offer goods for other parts of the data center, giving it a good claim on a Switzerland style of neutrality.

  2. #2
    WHT-BR Top Member
    Data de Ingresso
    Dec 2010
    Convém reproduzir parte do artigo "eu lhe disse" de Randy Bias


    Vanilla-land: A Fairy-Tale in the Making

    You can’t run OpenStack at scale and in production (the only measure that matters) in a “vanilla” manner. Here I am considering “vanilla” to include all three definitions above: default settings, no proprietary code, and no modifications.

    UPDATE: I want to be clear that by “production” I mean large scale production deployments. Anything that requires a multi-tiered switch fabric and typically over 3-5 racks in size. Yes, people run smaller production systems; however, it’s arguable they should be all-in on public cloud instead of wasting time running infrastructure. Also, for the purposes of this article talking about 5-10 server deployments doesn’t make sense. At that size, you can obviously run “vanilla OpenStack”, but I haven’t engaged with any enterprise that operates at this scale.

    The closest you can get to this is DevStack, which is not scalable nor acceptable for production.


    It would really take far too long to go through all of the gory details, but I need to give you some solid examples so you can understand. Let’s do this.

    General Configuration

    First, there are well over 500 configuration options for OpenStack. Many options immediately take you into proprietary land. Want to use your existing hypervisor, ESX? ESX is proprietary code, creating vendor lock-in and increasing costs. Want to use your existing storage or networking vendors? Same deal.

    Don’t want to reuse technology you already have? Then be prepared for a shock about what you’ll get by default from core projects.


    Whether you use nova-networking or Neutron, the “default” mode is what nova-networking calls “single_host” mode. Single host mode is very simple. You attach VLANs to a single virtual machine (or a single bare metal host) which acts as the gateway and firewall for all customers and all applications. Limited scalability and performance since an x86 server will never have the performance of a switch with proprietary ASICs and firmware. Worst of all, the only real failover model here is to use a high availability active/passive model. Most people use Linux-HA, which means that on failover, you’re looking at 45-60 seconds when absolutely NO network traffic is running through your cloud. Can you imagine a system-wide networking failure of 60 seconds each time you failover the single_host server to do maintenance?

    You can’t run like this in production, which means you *will* be using a Neutron plugin that provides control over a proprietary non-OpenStack networking solution, whether that’s bare metal switching, SDN, or something else.


    You Can Reduce Vendor Lock-in, But … You Can’t Eliminate It

    Are you trying to eliminate vendor lock-in? Power to you. That’s the right move. Just don’t expect to succeed.
    Última edição por 5ms; 21-03-2015 às 23:08.

  3. #3
    WHT-BR Top Member
    Data de Ingresso
    Dec 2010
    NSX is an Achilles heel because Software-Defined Networking (SDN) and networking in the enterprise is typically a big decision traditionally driven by independent groups in the organization, not necessarily the same groups that are making OpenStack-related decisions. Many companies will choose NSX, but many will choose Juniper or other fabrics. And in cases where NSX was not chosen, VIO will end up getting locked out. Hence it is an opportunity for Mirantis to win more business as the Switzerland of Openstack by being pure play and partnering with Juniper Networks
    Boris Renski

Permissões de Postagem

  • Você não pode iniciar novos tópicos
  • Você não pode enviar respostas
  • Você não pode enviar anexos
  • Você não pode editar suas mensagens