[PROPOSAL] Placement Plugins
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 3.7k
- Forks
- 676
- Avg merge
- 4d 9h
- Merged PRs (30d)
- 6
Description
Hello,
I work with the Failover Clustering team in Microsoft, whose feature capabilities are described here https://technet.microsoft.com/en-us/library/hh831579(v=ws.11).aspx. Some highlights are
- It is a feature installed with Windows Server (Full, Nano and Server Core).
- It is a tightly coupled group of server nodes (up to 64 nodes per cluster) that act as the availability foundation for mainly
o Hyper-V (Private hoster IaaS)
o SQL on premise High Availability
o Scaleout file based storage
o Office365/Exchange - It is highly and successfully deployed in private cloud solutions like Microsoft Azure Stack, Cloud Platform System and Storsimple appliances.
Since containers in Windows have evolved from Hyper-V and virtualization let me explain some of the main aspects of how failover clusters play with Hyper-V.
- Hyper-V plugs in as a resource DLL into the cluster orchestrator. The DLL implements well defined entry points that control the life cycle of VMs.
- VMs failover on node failures.
- Cluster monitors VM health – It also has capabilities to monitor services running inside the VM.
- VM placement based on a rich set of policies including CPU and memory.
- Dynamic load balancing of VMs and failback
- VM priority and preemption
- Node specific characteristics like possible and preferred VM owners
Docker Swarm now offers a clustering and orchestration mechanism for Windows containers. While architecturally quite different from a failover cluster I did notice that it offered a nice plugin model for storage (volumes) and networking. I read that plugins for placement (orchestration) would be available starting in version 1.13. I think that there is an opportunity for Docker containers running on Windows Server to take advantage of the rich set of placement policies offered by a failover cluster through a plugin or some equivalent mechanism.
I quickly browsed through the Docker scheduler code and noticed two overall principles (please forgive me if I misread the logic).
- Global Schedule
o This tries to ensure that all swarm nodes host the same number of tasks. - Node specific schedule
- Ready Filter
o Node status is Ready and Active - Resource Filter
o Number of CPUs and memory needed for the task is lesser than what the node has available - Plugin Filter
o Volume and network plugins referenced by a container are installed on the node - Constraint Filter (constraints are specified through API by key-value strings, default is no constraints)
o Node Id match
o Node hostname match
o Node IP match
o Node role match
o Node OS match
o Node architecture match
o Node label match (I believe this is a custom string)
o Engine label match
It looks like there is some opportunity for failover cluster backed global intelligence (storage and network topology, fault domains) and local intelligence (CPU, memory and perf counters).
Imagine a deployment scenario of Hyper-V, file storage and containers where containers are deployed with the Docker CLI and are placed by a plugin backed by a failover cluster.
I am looking for guidance from the swarmkit community about the feasibility of building a placement plugin.
Thanks
Sudhir
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the Docker scheduler code and the existing volume and network plugin model mentioned in the issue. Compare the requested failover-cluster-backed placement policies with the current global and node-specific scheduling filters. Done means documenting whether a placement plugin or equivalent mechanism is feasible and defining its scope.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- docker, go
- Domain
- devops, distributed-systems
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 20/100