# Docker Swarm key concepts Building upon the core features of Docker Engine, Docker Swarm enables you to create a Swarm of Docker Engines and orchestrate services to run in the Swarm. This topic describes key concepts to help you begin using Docker Swarm. ## Swarm **Docker Swarm** is the name for the cluster management and orchestration features embedded in the Docker Engine. A **Swarm** is a cluster of Docker Engines where you deploy a set of application services. When you deploy an application to a Swarm, you specify the desired state of the services, such as which services to run and how many instances of those services. The Swarm takes care of all orchestration duties required to keep the services running in the desired state. ## Node A **node** is an active instance of the Docker Engine in the Swarm. When you deploy your application to a Swarm, **manager nodes** accept the service definition that describes the Swarm's desired state. Manager nodes also perform the orchestration and cluster management functions required to maintain the desired state of the Swarm. For example, when a manager node receives notice to deploy a web server, it dispatches the service tasks to worker nodes. By default the Docker Engine starts one manager node for a Swarm, but as you scale you can add more managers to make the cluster more fault-tolerant. If you require high availability Swarm management, Docker recommends three or five Managers in your cluster. Because Swarm manager nodes share data using Raft, there must be an odd number of managers. The Swarm cluster can continue functioning in the face of up to `N/2` failures where `N` is the number of manager nodes. More than five managers is likely to degrade cluster performance and is not recommended. **Worker nodes** receive and execute tasks dispatched from manager nodes. By default manager nodes are also worker nodes, but you can configure managers to be manager-only nodes. ## Services and tasks A **service** is the definition of how to run the various tasks that make up your application. For example, you may create a service that deploys a Redis image in your Swarm. A **task** is the atomic scheduling unit of Swarm. For example a task may be to schedule a Redis container to run on a worker node. ## Service types For **replicated services**, Swarm deploys a specific number of replica tasks based upon the scale you set in the desired state. For **global services**, Swarm runs one task for the service on every available node in the cluster. ## Load balancing Swarm uses **ingress load balancing** to expose the services you want to make available externally to the Swarm. Swarm can automatically assign the service a **PublishedPort** or you can configure a PublishedPort for the service in the 30000-32767 range. External components, such as cloud load balancers, can access the service on the PublishedPort of any node in the cluster, even if the node is not currently running the service. Swarm has an internal DNS component that automatically assigns each service in the Swarm DNS entry. Swarm uses **internal load balancing** distribute requests among services within the cluster based upon the services' DNS name.