Introducing Nebula One private cloud system
nebula.com
nebula.com
The most important one: Is that Patrick Stewart doing the voice over in your video? :-)
My only concern with the design is that it's not clear that clustering gives you true redundancy, as it appears the 48 port 10gbps switch is integrated to the same PSU as the controller, and could be a SPOF for a rack of servers?
I assume the switch is essentially running a completely separate control plane from the x86 hardware, and forwarding plane, that can be controlled by other appliances in the cluster?
"You can run a cloud with a single Nebula One controller, but the system was designed to have multiple controllers for high availability and resiliency, says Kemp. The Cosmos operating system can currently span as many as five controllers in a single OpenStack controller domain and automatically load-balances work across controllers and the five racks of servers attached to them. With those five racks, you can have on the order of 2,500 cores and 5PB of storage, depending on the servers you pick."
http://www.theregister.co.uk/2013/04/02/nebula_one_openstack...
I'm saying that a rack full of servers is all hooked up to a single controller. You then have multiple, interconnected controllers, each one connecting a rack of servers. This is meant to give you HA and resiliency.
However, that is only true if the switch control plane is separate from the x86 hardware running in the controller (because, here we're getting HA and redundancy against the risk of controller hardware failure). I'd hope or expect that to be the case, because Nebula has smart people, but I don't see any material to that effect, yet.
(Typically a DC server farm will have two switches per rack of servers, with a dual-homed server having a connection into each. Therefore if one switch dies, you still have a redundant data path (though, only half the bandwidth)).
Regarding the underlying framework, I'm not very familiar with OpenStack (we use CloudStack right now), but is this a proprietary fork of OpenStack or are you guys moving the project forward upstream?
You can use a browser-based web dashboard or REST apis to interact with the system. Object storage (think S3) is exposed externally, block storage is supported, but it isn't currently exposed outside the system (its for vms only). AD integration is in the works.
Why is a cloud platform company pushing hardware?
Edit: Sorry you answered me on the other thread.
I was under the impression that Nebula's sole mission was to further OpenStack, but I suppose that was a misunderstanding. To clarify, is it Nebula's long-term goal to sell hardware?
For example, what networking are you going to use? Arista? Great. What's their latest supported APIs for Quantum? Well, they just changed (as in, last I heard they had a pull request open to OpenStack Quantum for support). OK. So Arista's API is now stable, great. Do they actually support what you want to do with your end devices?
What are you going to install Glance onto? Is the hardware going to be good enough? SSD? How fat will the pipe be into the switch? Dual homed? Quad? Is that going to fast enough if you want to spin up 100 VMs at once?
etc. etc.
Developing the hardware gives us full control over orchestration and updates and many many other areas.
We do have many of the contributors of OpenStack under one of our roofs (Mountain View, Seattle, Remote) and we do contribute a ton to OpenStack, both in code and the Foundataion. As far as the company goes, yes, we are a computer systems company, making hardware and software.
Honestly, if I was CTO at a start-up: OpenStack, a stack of cheap machines, maxed with memory and disks (if required), Open vSwitch, a standard 48 port 10gbps switch (though you can probably get away with 24 ports), open to all staff.
Setup of OpenStack may take a little longer, and it won't scale without serious work, but it will be cheaper and easier to control costs than spinning up AWS.
I think the main pain-point that is being fixed here is that initial setup of OpenStack. I've been doing this stuff for many, many years and it give ME a headache. It truly is that bad (and deploying with Puppet or Chef only lessens the pain while adding different layers of complexity).
Pretty much exactly what I've wanted.
The benefit of converged infrastructure while leaving a choice in compute vendor and integrating the controller, interconnect and orchestrator in a single unit.
Very, very cool.