Nomad, a cluster manager and scheduler
hashicorp.com
Nomad, a cluster manager and scheduler
1–10 of 48 posts
Re: Nomad, a cluster manager and scheduler
#2Congrats to Hashicorp, it's always exciting to see another release from you. Now I just have to find an excuse to use them... ;-)
Re: Nomad, a cluster manager and scheduler
#3That's... no small release. If it indeed has everything they claim that's extraordinary. What's the catch? Why haven't they made more noise about this?
Re: Nomad, a cluster manager and scheduler
#4That's... no small release. If it indeed has everything they claim that's extraordinary. What's the catch? Why haven't they made more noise about this?
I think this is their noise. :)
Their big conference is today, so I expect a few more announcements.
Re: Nomad, a cluster manager and scheduler
#5Anyone able to give a compare/contrast here with other cluster management systems... Apache Mesos or Kubernetes, for example?
Re: Nomad, a cluster manager and scheduler
#6Anyone able to give a compare/contrast here with other cluster management systems... Apache Mesos or Kubernetes, for example?
Hashicorp themselves have published comparisons to Kubernetes, Mesos, et al on the Nomad site[1]. They look well written and generally not too biased.
Re: Nomad, a cluster manager and scheduler
#7They're building a nice little ecosystem...
Re: Nomad, a cluster manager and scheduler
#8>Nomad is designed to be a global state, optimistically concurrent scheduler. Global state means schedulers get access to the entire state of the cluster when making decisions enabling richer constraints, job priorities, resource preemption, and faster placements.
Can anyone shed light on how that's possible? I was under the impression that global state in distributed systems was not possible?
Re: Nomad, a cluster manager and scheduler
#9> Nomad is designed to be a global state, optimistically concurrent scheduler. Global state means schedulers get access to the entire state of the cluster when making decisions enabling richer constraints, job priorities, resource preemption, and faster placements. Can anyone shed light on how that's possible? I was under the impression that global state in distributed systems was not possible?
http://research.google.com/pubs/pub41684.html
Basically, there's a server that holds state for the cluster. When a scheduler attempts to load a job into the cluster, it grabs state from the aforementioned server, performs its job placement calculations, and then tries to submit its answer to the master state. Since there are many such schedulers, and the amount of time it takes to place a job is non-trivial, its possible that during the processing time to calculate placement, another scheduler might've consumed the requested resources. In this case, the first scheduler will provision whichever services are not in conflict for placement location, and perform a new calculation with the new state to place the remaining conflicted servers.
The general idea is that most services don't have such a high affinity that the components need to be started all at the same time (a MapReduce job on 10,000 nodes can still run with 5,000 nodes while the second 5k are provisioning). The tradeoff here is that you have to manage conflicts, but the hope is that there are few enough that your optimism is rewarded.
Does that make sense?
Re: Nomad, a cluster manager and scheduler
#10> Nomad is designed to be a global state, optimistically concurrent scheduler. Global state means schedulers get access to the entire state of the cluster when making decisions enabling richer constraints, job priorities, resource preemption, and faster placements. Can anyone shed light on how that's possible? I was under the impression that global state in distributed systems was not possible?
It's possible but there are tradeoffs depending on what you mean by "global" and "state". If the state is strongly consistent (CP) then during a network partition the minority side of the partition will basically shut down and stop working. If the state is eventually consistent (AP) then it will become inconsistent during a network partition and have to be reconciled after the partition heals.