/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/Orchestration/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/Orchestration/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.