Mesos actually handles the lower level part (determining which machines are up and which resources they have (CPU, memory, disks, network ports, GPUs), running tasks on machines, isolating resources from each running task on each machine, either with its own containerizer or using Docker, etc), but the tasks themselves and their scheduling details (how many tasks to run, should it try to run each task on a different machine or not, etc) are determined by the framework you are using. There are some popular "meta-frameworks" (like Marathon and Aurora) that abstract away the Mesos interface and let you just say "run five instances of this Docker container, one per physical machine". They also might handle higher level details, like service registration/discovery, rolling updates and more.

>Because they are not down. Their shares are just sent to another worker from the pool seamlessly.

Eh, depends on what you consider by "seamlessly": basically if a node goes down, everything it was running will be rescheduled and ran again on other nodes, but this might take some minutes, and ensuring this failure is not perceived from the outside depends entirely on you. Disk management is entirely up to you also, so you have to roll your own SAN if you want to have something like that (at my company Mesos disk space is completely ephemeral, and truly persistent state is always stored on S3 or external databases).