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

151–160 of 230 posts

Re: ClusterHQ is shutting down

#151

Post by ownagefool »

cookiecaper wrote: post #115
contingencies wrote: post #82

Earlier quoted context omitted.

Look at the list of PV types for Kube What I see is a lot of complex network filesystems, vendor-specific solutions and gateway protocols to expensive SAN solutions, which are already chalk and cheese in terms of features and performance. Arguably one of the best features of unix-style systems is support for arbitrary mount points, filesystem drivers and (network or local) blockstores. Storage is, essentially, a well…

Yes. k8s is cool but it is vastly overcomplicated for the needs of the non-Googles. We've been porting my company's production infrastructure to it over the last year and while it's been fun, I don't think it's been the correct thing for us. Since suggesting your company is not in the same class of the companies that see literally billions of unique users every day, and thus may not need such overcomplicated solution…

Out of interest, what are you migrating from?

Re: ClusterHQ is shutting down

#152

Post by otterley »

chrissnell wrote: post #136
tw04 wrote: post #60

Earlier quoted context omitted.

>NFS? No way. Not performant. Really? https://www.spec.org/sfs2008/results/res2011q4/sfs2008-20111... And those are nothing compared to modern systems.

Let me clarify: not performant in any way that we want to implement. The NetApp referenced in that analysis would cost as much as we've spent on both of our OpenStack and Kube clusters. NetApp is great if you're a hospital or a bank but not an internet company. We need something built on common PC chassis, either as distributed local storage or some type of high speed interconnect.

Storage is definitely one of those businesses where "fast, good, cheap: pick any two" has always applied, and still does.

Re: ClusterHQ is shutting down

#153

Post by otterley »

cookiecaper wrote: post #135
seanp2k2 wrote: post #72

Earlier quoted context omitted.

I've had many problems with NFS, but they were not performance related. Mostly FS hangs with some program waiting for IO that never comes.

This is the biggest issue I've had with NFS. If the mount goes stale, programs can get stuck in an uninterruptable state that takes a reboot to clear out.

Just mount the file system with "soft,intr" options and you won't have that problem. Otherwise NFS is (perhaps unrealistically) optimistic that the server will come back.

Re: ClusterHQ is shutting down

#154

Post by cookiecaper »

ownagefool wrote: post #151
cookiecaper wrote: post #115

Earlier quoted context omitted.

Yes. k8s is cool but it is vastly overcomplicated for the needs of the non-Googles. We've been porting my company's production infrastructure to it over the last year and while it's been fun, I don't think it's been the correct thing for us. Since suggesting your company is not in the same class of the companies that see literally billions of unique users every day, and thus may not need such overcomplicated solution…

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, so we still had some cloud-style flexibility and could do things like auto-scaling).

Re: ClusterHQ is shutting down

#155

Post by monkeywork »

colanderman wrote: post #94
mst wrote: post #91

Earlier quoted context omitted.

Is the hardware storing the data in-datacentre too? I think that was the key thing.

We (ClearSky) store your data off-site (except a small cache), but provide performance as if the data were on-site.

So you are essentially doing AWS Storage Gateway then?

http://docs.aws.amazon.com/storagegateway/latest/userguide/G...

Re: ClusterHQ is shutting down

#156

Post by TheIronYuppie »

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…

May I ask - what's the biggest issue you've been facing? Anything we can do to make it easier/more useful? We've found that there are a ton of things that people just end up reinventing unless it comes in the box (e.g. autoscaling, rolling deployments, roll backs, replications, aggregated logging/monitoring, etc).

Disclosure: I work at Google on Kubernetes

Re: ClusterHQ is shutting down

#157

Post by doublerebel »

FrankenPC wrote: post #89

I should make a startup called Trampoline. Other startups pay me insurance premiums and I hop in with a team and salaries for ejected employees to keep doors open for however long they paid for after a crash. As part of the customer SLA they cite Trampoline and the duration of post mortem life being paid for.

I like this idea, but I wonder how it would affect the business decisions of founders once they know they have a safety net.

Re: ClusterHQ is shutting down

#158

Post by TheIronYuppie »

tazjin wrote: post #144
contingencies wrote: post #82

Earlier quoted context omitted.

Look at the list of PV types for Kube What I see is a lot of complex network filesystems, vendor-specific solutions and gateway protocols to expensive SAN solutions, which are already chalk and cheese in terms of features and performance. Arguably one of the best features of unix-style systems is support for arbitrary mount points, filesystem drivers and (network or local) blockstores. Storage is, essentially, a well…

> Storage is, essentially, a well-solved problem at the OS level. The fact that this option is marked "single node testing only – local storage is not supported in any way and WILL NOT WORK in a multi-node cluster" raises eyebrows. Just to clarify this a bit: Persistent volumes as an API _resource_ in Kubernetes are independent of which node a container requesting them is scheduled on, which is why it makes little se…

Yep, can't repeat this enough. If you've solved node storage management, you've solved k8s storage management too. Use hostpath and call it a day.

Disclosure: I work at Google on Kubernetes

Re: ClusterHQ is shutting down

#159

Post by TheIronYuppie »

luka-birsa wrote: post #92
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…

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…

What would it look like to be integrated? Could you just use your existing node solutions and hostpath and be set?

Disclosure: I work at Google on Kubernetes

Re: ClusterHQ is shutting down

#160

Post by colanderman »

chrissnell wrote: post #137
colanderman wrote: post #94

Earlier quoted context omitted.

We (ClearSky) store your data off-site (except a small cache), but provide performance as if the data were on-site.

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.

Check out this report if you don't believe me: http://www.clearskydata.com/clearsky-takes-primary-storage-t...

Several members of our team were core developers of EqualLogic (pre-Dell buyout). We have significant investment from Akamai. I promise you this is not snake oil.

Post reply on HN