/docs/MyDocs

To get this branch, use:
bzr branch http://darksoft.org/webbzr/docs/MyDocs

« back to all changes in this revision

Viewing changes to Administration/Server/Cluster/orchestration.txt

  • Committer: Suren A. Chilingaryan
  • Date: 2017-04-03 02:45:17 UTC
  • Revision ID: csa@suren.me-20170403024517-dwzj0z0k1cmhxm7u
Restructuring, OpenShift, Ansible, Git

Show diffs side-by-side

added added

removed removed

Lines of Context:
Administration/Server/Cluster/orchestration.txt
1
 
Batch
2
 
=====
3
 
 - Slurm:
4
 
 
5
 
 
6
 
Cloud
7
 
=====
8
 
Docker swarm is a simple solution well integrated in docker infrastructure, but does not cater
9
 
for node failures currently. The Kubernetes seems optimal for container scheduling. The Mesos
10
 
is a more universal tool and is well integrated with other Apache infrastructures like Hadoop,
11
 
Spark, and Storm.
12
 
 
13
 
Requirements
14
 
------------
15
 
 - Managing groups of services
16
 
 - Node failover management and high availability
17
 
 - Automatic scallability management
18
 
 - Automatic updates
19
 
 - Proper schedulling of heavy ocasional tasks like data mining
20
 
 
21
 
Docker Swarm
22
 
------------
23
 
 Swarm VM is running on a single node of docker cluster and distributes all tasks 
24
 
 schedulled locally with standard docker interface. Other nodes, just run docker
25
 
 daemon. 
26
 
  + Directly works docker compose
27
 
  + Supports multiple schedulling policies: 
28
 
     fewest containers per node, most containers per node, start specific images
29
 
     on the marked nodes, start specific images on the same node.
30
 
  - Only runs containers as scheduled. Do not have logic to auto-start more copies
31
 
  of specific containers under high load. Also will not restart containers which are 
32
 
  stopped or crashed.
33
 
  - Does not provide a special support for automatic updates
34
 
 
35
 
 The HA can be implemented based on etcd, Consul, or ZooKeeper which will handle fail-over
36
 
 to backup manager.
37
 
 
38
 
CoreOS EtcD/Fleet
39
 
------
40
 
 The CoreOS is distributed operating system built on top of SystemD and containers (and it is not
41
 
 running on top of CentOS/Ubuntu/etc.) It provides  number of services used by other schedulers
42
 
 directly or re-implemented as concept.
43
 
 - rkt: Rocket containers (an alternative to Docker)
44
 
 - etcd: distributed key-value storage 
45
 
 - fleet: distributed SystemD unit scheduling service for rkt containers
46
 
 
47
 
 The Fleet is build on top of SystemD and allows to execute SystemD unit files across the 
48
 
 nodes of cluster. Each node runs engine and agent, but only a single engine is active. 
49
 
 Engine accepts Unit files and schedules them on the least loaded agent. The unit file
50
 
 is normally simply runs the container. 
51
 
 - The supports vairous hints and constraints. For instance, the units can be schedulled
52
 
 global (and will run on all machines) or on a single machine. It is possible to schedule
53
 
 multiple units together, etc.
54
 
 - Socket activation is supported, i.e. container can be schedulled upon connection on a 
55
 
 given port.
56
 
 - The architecture is fault-tolerant. The services from crashed node will be re-scheduled 
57
 
 on other nodes. The etcd is used to store status of the cluster and units.
58
 
 
59
 
 It is positioned as low-level cluster engine and expected to be a part
60
 
 of higher level solution, like Kubernetes.
61
 
 
62
 
Google Kubernetes
63
 
-----------------
64
 
 Kubernets is based on etcd (distributed key-value storage) and provides Master sever
65
 
 and multiple working nodes. The HA mode with multiple server are solely based on 
66
 
 etcd. The working nodes (minions) should just run docker and kubelet services. 
67
 
 The master server runs number of control services:
68
 
 - etcd service
69
 
 - API Services alowing management of cluster
70
 
 - Scheduler taking care for resource management
71
 
 - Controller Manager allowing automatic replication of the services, etc.
72
 
 
73
 
 The basic scheduling unit in Kubernetes is a pod, a collection of co-located containers 
74
 
 forming a service. The pods are conceptually similar to the Docker Composer and use somehow
75
 
 similar script to describe relations. Pods can define common storage and are will integrated
76
 
 with Gluster, NFS, iSCSI, and number of Cloud storages. The most important n unique IP is 
77
 
 assigned to each pod in the cluster which can be used to access it independent of current 
78
 
 placement.
79
 
 
80
 
 Also, Kubernetes allows tasks to be more precise about scheduling perference specifying 
81
 
 placement requirements (predicates) and  preferences (priority). Basically, this allows 
82
 
 both manual and automatic scheduling and any hybrid vairant in between:
83
 
 - predicate:  mandatory requirement (run on specific node, amount of memory, etc.)
84
 
 - priority: preferred, but not mandatory, requirement
85
 
 
86
 
 The main difference to Docker Swarm is Controlers managed Controller Manager which can 
87
 
 automatize schedulling of replicas, etc.
88
 
 - Replication: Will ensure that given number of pod replicas is running in the cluster
89
 
 - DaemonSet: Will ensure that a single instance of pod is running at each cluster node
90
 
 - Job Contoller: The batch joba
91
 
 
92
 
 Also, the automatic updates are suported.
93
 
 
94
 
Apache Mesos
95
 
------------
96
 
 Mesos is a more general purpose tool not limited to containers, but is able to schedule 
97
 
 standard applications on hosts. It tries to solve isolation problem differently by allowing
98
 
 to asign for specific task a part of general pool of the servers. This is achieved with 2 
99
 
 level schedulling. Mesos master just distributes cluster resources between registered frameworks
100
 
 which perform task schedulling withing allocated budget. Itt could easily switch resources away 
101
 
 from framework1 (for example, doing big-data analysis) and allocate them to framework2 (for example, 
102
 
 a web server), if there is heavy network traffic. There are number of frameworks:
103
 
 - Chronos: A cron replacement which automatically starts and stops services.
104
 
 - Marathon: Provides API for starting and stopping services and Chronos can be one of them
105
 
 - Apache Aurora: Apache scheduler aimed on fault tolerant and long-running services taking 
106
 
 care for restarting, migration, etc.
107
 
 - Task specific frameworks: MPI, Hadoop/Spark/Storm, Cassandra, ElasticSearch, Jenkins, etc.
108
 
 - More: Singularity, Torque, 
109
 
 
110
 
 HA is supported. There is always a single active Master and a number of StandBy master servers. The
111
 
 ZooKeeper is running on all master nodes and elects the active Master.
112
 
 
113
 
 Mesos is known to scale well on really large clusters, but may be overcomplicated for a small cluster
114
 
 we run at IPE.