Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ClusterHQ is shutting down

clusterhq.com

Post reply on HN
Print view View original

201–210 of 230 posts

Re: ClusterHQ is shutting down

#201

Post by colanderman »

brazzledazzle wrote: post #191
chrissnell wrote: post #137

Earlier quoted context omitted.

I don't believe you. There's no way you're coming even close to local disk performance with an off-prem solution. Feel free to prove me wrong but I don't think that this is a reasonable solution for backing storage for a database.

Well it seems clear to me that they can only provide that level of performance for blocks already in their onsite cache. Presumably they're using a novel compression/de-duplication scheme and maybe prioritizing blocks using historical and/or predictive analysis to cache the right data at the right time but you can only transfer data as fast as you can transfer it. I'm guessing a full export of all of your data (that…

Bandwidth is much less a problem for OLTP workloads than latency is. (If all you care about is bandwidth, S3 is your friend.)

With ClearSky, even for workloads that don't fit in the edge cache (which we believe are few), you'll still see single-digit millisecond random read (and write) latencies. This is made possible by our points of presence (PoPs) located in each metro area we serve. These PoPs house the lion's share of data in a private cloud, and are connected to each customer site with private lines with sub-millisecond latency.

In other words, the speed of light is very fast when it goes in a straight line with nothing in its way ;) While we do have some secret sauce in the data pipeline, it is because we own the network to the customer that we can provide the performance we do.

(Fancy PDF with a few more details here: http://cdn2.hubspot.net/hubfs/445689/2015_assets/ClearSky-Da...)

Re: ClusterHQ is shutting down

#202

Post by WestCoastJustin »

benley wrote: post #190
user5994461 wrote: post #177

Earlier quoted context omitted.

I don't want to break your hopes but stateful containers will only ever run on GCE and AWS. The entire existence of stateful containers depends on having network storage at hands. The only good network storages are GCE and AWS volumes, which are proprietary trade-secret technologies only available there. If you want to play it old-school. You can run virtual machines with VmWare on bare metal servers with SAN disks (…

If virtual machines with live migration is what you're after, vmware is not your only option. You can get largely the same effect without involving any iscsi/FC/SAN tech with another open source project, which happens to originate from the same place as Kubernetes: http://www.ganeti.org/ Ganeti has been battle-tested for about a decade too, supports an assortment of storage backends, including some clustered ones lik…

Thank you. I've used Ganeti extensively and it help wrangle our Xen/DRBD rats nest very quickly. It's an awesome project.

Re: ClusterHQ is shutting down

#203

Post by icebraining »

brazzledazzle wrote: post #188
luka-birsa wrote: post #92

Earlier quoted context omitted.

Same here. Running ~100 app servers in K8S and the rest (databases & legacy apps) as regular GCE instances with PD drives. But long term going K8S-only is instrumental for us to prevent vendor lock-in. I really hope that storage for K8S happens this year in a form that is simpler than Gluster/Ceph/etc and preferably integrated. Right now we're using NFS and it's ok for the simple applications but I right now I wouldn…

Correct me if I'm wrong, but if you have the storage solved for the rest why not just use that same storage mechanism? If you're using local storage on your legacy applications and are essentially bound to the one node why couldn't you tag one node and use hostpath in kubernetes? Since these applications are fundamentally not designed for something like kubernetes what everyone seems to be asking for is Kubernetes to…

There's ZREP [1]. It uses the snapshots feature of ZFS, which can send them over the network, to continually (but asynchronously) mirror the local filesystem to a remote machine.

It seems to provide exactly the features required (fast local access with failover), at the expense of a window of lost data (since the replication isn't synchronous and confirmed).

[1] http://www.bolthole.com/solaris/zrep/

Re: ClusterHQ is shutting down

#204

Post by Perceptes »

gtirloni wrote: post #76

Oh the immediate shutdowns! After going through the immediate Nebula shutdown, I'm glad we weren't depending on ClusterHQ. Same question I had for Nebula: you had no idea that a month ago you'd have to shutdown, right? I've started to follow these ex-CEOs so we avoid their next companies. This kind of shutdown is just terrible.

For the record, I totally agree with you here, and with your further comments below. The HN attitude that running a startup is some moral virtue is obnoxious. This company simply screwed over its users. They aren't owed anything.

Re: ClusterHQ is shutting down

#205

Post by [deleted] »

BinaryIdiot wrote: post #8

How many people were employed at ClusterHQ? Honestly I never even heard of the company but I had heard of some of the open source projects. Maybe I'm just out of the loop. Also any information as to lessons learned, etc? Basically why it failed? Looking at the marketing material I didn't see anything really remarkable about it (nothing that stood out as a "oh this is why I would give them money") so I'm curious. > I’…

[deleted]

Re: ClusterHQ is shutting down

#206

Post by ownagefool »

cookiecaper wrote: post #154
ownagefool wrote: post #151

Earlier quoted context omitted.

Out of interest, what are you migrating from?

Deployment across EC2 nodes, managed with devops scripts from a few different tools and monitored with conventional monitoring solutions like Nagios/Munin. We migrated from colocated racks to that a few years back. Personally, while there is undoubtedly a convenience factor with being pure EC2 and a cool factor with k8s, I think 80% of our stuff would be better off in the racks (which included a couple of hypervisors…

Whilst I often agree with you that we're a hype driven machine that more than often just creates more work for ourselves, I actually think kubernetes is an improvement over tying an app directly to EC2.

Obviously I imagine you know other tools better and it depends how you do it, but kube gives you a lot more by default. Arguably more importantly, I can lift and shift kubernetes and put it in any cloud or on-premise. I'm not really sure what the benefit of running a VMs would give you, other than possibly live migrations.

Re: ClusterHQ is shutting down

#207

Post by davidopp__ »

user5994461 wrote: post #177
chrissnell wrote: post #15

We've been running Kubernetes (500+ containers) in production for over a year now. I believe (and hope) that 2017 will be the year that persistent data storage will be solved. We are ready to move our data out of OpenStack and have our data services (Elasticsearch, Cassandra, MySQL, MongoDB) join the rest of our apps on Kube-orchestrated infrastructure. But, we're not there yet. The options just aren't good enough. L…

I don't want to break your hopes but stateful containers will only ever run on GCE and AWS. The entire existence of stateful containers depends on having network storage at hands. The only good network storages are GCE and AWS volumes, which are proprietary trade-secret technologies only available there. If you want to play it old-school. You can run virtual machines with VmWare on bare metal servers with SAN disks (…

> I don't want to break your hopes but stateful containers will only ever run on GCE and AWS.

Actually Kubernetes is starting to work on support for persistent local volumes; we know the lack of this feature is a significant barrier for running some stateful applications on Kubernetes, particularly on bare metal. The concrete proposal for how we are thinking to do it is at https://github.com/kubernetes/kubernetes/pull/30044

The high-level feature requests are at https://github.com/kubernetes/features/issues/121 and https://github.com/kubernetes/kubernetes/issues/7562

(Disclosure: I work on Kubernetes at Google.)

Re: ClusterHQ is shutting down

#209

Post by vacri »

BinaryIdiot wrote: post #129
vacri wrote: post #77

Earlier quoted context omitted.

> If you're stating that you're going to greatly enjoy your failure 'Relish' in this context doesn't mean 'greatly enjoy', as in entertainment. It means simply 'to significantly value', as in valuing the learning opportunity, but not necessarily the event itself.

> It means simply 'to significantly value' Er, not trying to be pedantic but I can't find this definition anywhere. Is that an informal use? I only see references to the condiment or similar to 'greatly enjoy'. Might be one of those cases where using more specific wording would have helped the blog entry.

The article is talking about relishing the richness of life's experience, not some sort of Machiavellian cackling while you watch people lose their jobs. The failures are simply to be valued as learning experiences that are part of life. That particular phrase is preceded in the same sentence with another phrase saying that the failures basically aren't pleasureable.

Read the paragraph as a whole, and don't just fish out one phrase and take it out of context.

Re: ClusterHQ is shutting down

#210

Post by jondubois »

chrissnell wrote: post #15

We've been running Kubernetes (500+ containers) in production for over a year now. I believe (and hope) that 2017 will be the year that persistent data storage will be solved. We are ready to move our data out of OpenStack and have our data services (Elasticsearch, Cassandra, MySQL, MongoDB) join the rest of our apps on Kube-orchestrated infrastructure. But, we're not there yet. The options just aren't good enough. L…

Yes I think that Kubernetes is too stubborn with regards to how it wants to decouple Pods/Containers from specific Nodes.

Many new databases (especially NoSQL ones) already support clustering and rely on being tightly coupled to specific nodes/machines in order to work. I think K8s currently makes this a bit too difficult - They need to improve support/documentation for using host storage for these kinds of clustered DBs.

NFS doesn't make sense for storing structured data because it doesn't know what the best way to partition/search your data is going to be (the directory tree structure isn't always what we need) - I think that this can only be solved at the DB layer unfortunately.

Post reply on HN