Is it possible to run more than one node on a physical host without full-fat VM?
Clash Royale CLAN TAG#URR8PPP
up vote
0
down vote
favorite
I am planning on running Docker and Swarms on some rPi 3B+'s. My first goal is to test the fault tolerance abilities of RAFT consensus across at least 3 machines so I can simulate failure of a node.
According to:
https://docs.docker.com/get-started/part4/
.. a node within the current way of doing things (swarmkit, Docker v18) is a docker machine running on a physical host right under the host's OS, or a "full-fat" VM guest OS > docker machine that runs a layer underneath the physical host.
is it possible to run multiple nodes on a linux machine in parallel without having to do the full-fat VM work?
Since ARM doesn't have hardware virtualization capabilities like x86 platforms, and rPi has a limited amount of computation power, there would be a huge performance hit running VM's in order to have multiple nodes on a single physical host. I'm curious if there's an alternative or if I'm just entirely misunderstanding how this Docker Engine / swarmkit interaction works.
docker arm arm64
asked Dec 1 at 6:59
david_coneff
13
add a comment |
up vote
0
down vote
favorite
I am planning on running Docker and Swarms on some rPi 3B+'s. My first goal is to test the fault tolerance abilities of RAFT consensus across at least 3 machines so I can simulate failure of a node.
According to:
https://docs.docker.com/get-started/part4/
.. a node within the current way of doing things (swarmkit, Docker v18) is a docker machine running on a physical host right under the host's OS, or a "full-fat" VM guest OS > docker machine that runs a layer underneath the physical host.
is it possible to run multiple nodes on a linux machine in parallel without having to do the full-fat VM work?
Since ARM doesn't have hardware virtualization capabilities like x86 platforms, and rPi has a limited amount of computation power, there would be a huge performance hit running VM's in order to have multiple nodes on a single physical host. I'm curious if there's an alternative or if I'm just entirely misunderstanding how this Docker Engine / swarmkit interaction works.
docker arm arm64
asked Dec 1 at 6:59
david_coneff
13
1
Not an answer to your question, but if you are just getting into container orchestration, don't bother with swarm. It's basically dead as even docker (the company) has shifted focus to kubernetes. Kubernetes is the most popular solution but ECS (AWS only) is also fairly popular.
– jordanm
Dec 1 at 7:33
Thanks for the heads up. When I was looking at the options, Kubernetes seemed more developed but also more difficult to deploy according to comparisons of the two orchestration frameworks. But I'd rather be using the one that still has a future! The split between the old Docker <1.1.2 + Swarm and the new Docker >1.1.2 + Swarmkit was already confusing enough in their official documentation.
– david_coneff
Dec 1 at 7:44
If you can leverage VirtIO or other paravirtualization technologies, running VM's on a Pi actually isn't really all that much of a performance hit. The big performance killer on the Pi in most cases is the storage interface. This isn't to say that you'll get native equivalent performance, but it's still good enough for network simulation (and will probably beat containers for that, as the networking is actually marginally simpler using a VM).
– Austin Hemmelgarn
Dec 3 at 20:46
Yes, the Pi has extremely limited available bandwidth because the bus is shared by network, local storage and the CPU. I'm not doing anything bandwidth intensive but there are reasons I want the GPIO and radio capabilities present for some of my projects though, and being able to deploy them with kubernetes management would be a huge plus. One option I was considering is using QEMU. The Wikipedia mentioned it now has good support for ARMx64 and the processor inside the Pi. As long as I could run at least 2 x logical nodes per Pi board that would be a huge boon.
– david_coneff
Dec 4 at 1:39
add a comment |
up vote
0
down vote
favorite
up vote
0
down vote
favorite
I am planning on running Docker and Swarms on some rPi 3B+'s. My first goal is to test the fault tolerance abilities of RAFT consensus across at least 3 machines so I can simulate failure of a node.
According to:
https://docs.docker.com/get-started/part4/
.. a node within the current way of doing things (swarmkit, Docker v18) is a docker machine running on a physical host right under the host's OS, or a "full-fat" VM guest OS > docker machine that runs a layer underneath the physical host.
is it possible to run multiple nodes on a linux machine in parallel without having to do the full-fat VM work?
Since ARM doesn't have hardware virtualization capabilities like x86 platforms, and rPi has a limited amount of computation power, there would be a huge performance hit running VM's in order to have multiple nodes on a single physical host. I'm curious if there's an alternative or if I'm just entirely misunderstanding how this Docker Engine / swarmkit interaction works.
docker arm arm64
asked Dec 1 at 6:59
david_coneff
13
I am planning on running Docker and Swarms on some rPi 3B+'s. My first goal is to test the fault tolerance abilities of RAFT consensus across at least 3 machines so I can simulate failure of a node.
According to:
https://docs.docker.com/get-started/part4/
.. a node within the current way of doing things (swarmkit, Docker v18) is a docker machine running on a physical host right under the host's OS, or a "full-fat" VM guest OS > docker machine that runs a layer underneath the physical host.
is it possible to run multiple nodes on a linux machine in parallel without having to do the full-fat VM work?
Since ARM doesn't have hardware virtualization capabilities like x86 platforms, and rPi has a limited amount of computation power, there would be a huge performance hit running VM's in order to have multiple nodes on a single physical host. I'm curious if there's an alternative or if I'm just entirely misunderstanding how this Docker Engine / swarmkit interaction works.
docker arm arm64
docker arm arm64
asked Dec 1 at 6:59
david_coneff
13
asked Dec 1 at 6:59
david_coneff
13
edited Dec 1 at 7:42
asked Dec 1 at 6:59
david_coneff
13
asked Dec 1 at 6:59
david_coneff
13
asked Dec 1 at 6:59
david_coneff
13
13
1
Not an answer to your question, but if you are just getting into container orchestration, don't bother with swarm. It's basically dead as even docker (the company) has shifted focus to kubernetes. Kubernetes is the most popular solution but ECS (AWS only) is also fairly popular.
– jordanm
Dec 1 at 7:33
Thanks for the heads up. When I was looking at the options, Kubernetes seemed more developed but also more difficult to deploy according to comparisons of the two orchestration frameworks. But I'd rather be using the one that still has a future! The split between the old Docker <1.1.2 + Swarm and the new Docker >1.1.2 + Swarmkit was already confusing enough in their official documentation.
– david_coneff
Dec 1 at 7:44
If you can leverage VirtIO or other paravirtualization technologies, running VM's on a Pi actually isn't really all that much of a performance hit. The big performance killer on the Pi in most cases is the storage interface. This isn't to say that you'll get native equivalent performance, but it's still good enough for network simulation (and will probably beat containers for that, as the networking is actually marginally simpler using a VM).
– Austin Hemmelgarn
Dec 3 at 20:46
Yes, the Pi has extremely limited available bandwidth because the bus is shared by network, local storage and the CPU. I'm not doing anything bandwidth intensive but there are reasons I want the GPIO and radio capabilities present for some of my projects though, and being able to deploy them with kubernetes management would be a huge plus. One option I was considering is using QEMU. The Wikipedia mentioned it now has good support for ARMx64 and the processor inside the Pi. As long as I could run at least 2 x logical nodes per Pi board that would be a huge boon.
– david_coneff
Dec 4 at 1:39
add a comment |
1
Not an answer to your question, but if you are just getting into container orchestration, don't bother with swarm. It's basically dead as even docker (the company) has shifted focus to kubernetes. Kubernetes is the most popular solution but ECS (AWS only) is also fairly popular.
– jordanm
Dec 1 at 7:33
Thanks for the heads up. When I was looking at the options, Kubernetes seemed more developed but also more difficult to deploy according to comparisons of the two orchestration frameworks. But I'd rather be using the one that still has a future! The split between the old Docker <1.1.2 + Swarm and the new Docker >1.1.2 + Swarmkit was already confusing enough in their official documentation.
– david_coneff
Dec 1 at 7:44
If you can leverage VirtIO or other paravirtualization technologies, running VM's on a Pi actually isn't really all that much of a performance hit. The big performance killer on the Pi in most cases is the storage interface. This isn't to say that you'll get native equivalent performance, but it's still good enough for network simulation (and will probably beat containers for that, as the networking is actually marginally simpler using a VM).
– Austin Hemmelgarn
Dec 3 at 20:46
Yes, the Pi has extremely limited available bandwidth because the bus is shared by network, local storage and the CPU. I'm not doing anything bandwidth intensive but there are reasons I want the GPIO and radio capabilities present for some of my projects though, and being able to deploy them with kubernetes management would be a huge plus. One option I was considering is using QEMU. The Wikipedia mentioned it now has good support for ARMx64 and the processor inside the Pi. As long as I could run at least 2 x logical nodes per Pi board that would be a huge boon.
– david_coneff
Dec 4 at 1:39
1
1
Not an answer to your question, but if you are just getting into container orchestration, don't bother with swarm. It's basically dead as even docker (the company) has shifted focus to kubernetes. Kubernetes is the most popular solution but ECS (AWS only) is also fairly popular.
– jordanm
Dec 1 at 7:33
Not an answer to your question, but if you are just getting into container orchestration, don't bother with swarm. It's basically dead as even docker (the company) has shifted focus to kubernetes. Kubernetes is the most popular solution but ECS (AWS only) is also fairly popular.
– jordanm
Dec 1 at 7:33
Thanks for the heads up. When I was looking at the options, Kubernetes seemed more developed but also more difficult to deploy according to comparisons of the two orchestration frameworks. But I'd rather be using the one that still has a future! The split between the old Docker <1.1.2 + Swarm and the new Docker >1.1.2 + Swarmkit was already confusing enough in their official documentation.
– david_coneff
Dec 1 at 7:44
Thanks for the heads up. When I was looking at the options, Kubernetes seemed more developed but also more difficult to deploy according to comparisons of the two orchestration frameworks. But I'd rather be using the one that still has a future! The split between the old Docker <1.1.2 + Swarm and the new Docker >1.1.2 + Swarmkit was already confusing enough in their official documentation.
– david_coneff
Dec 1 at 7:44
If you can leverage VirtIO or other paravirtualization technologies, running VM's on a Pi actually isn't really all that much of a performance hit. The big performance killer on the Pi in most cases is the storage interface. This isn't to say that you'll get native equivalent performance, but it's still good enough for network simulation (and will probably beat containers for that, as the networking is actually marginally simpler using a VM).
– Austin Hemmelgarn
Dec 3 at 20:46
If you can leverage VirtIO or other paravirtualization technologies, running VM's on a Pi actually isn't really all that much of a performance hit. The big performance killer on the Pi in most cases is the storage interface. This isn't to say that you'll get native equivalent performance, but it's still good enough for network simulation (and will probably beat containers for that, as the networking is actually marginally simpler using a VM).
– Austin Hemmelgarn
Dec 3 at 20:46
Yes, the Pi has extremely limited available bandwidth because the bus is shared by network, local storage and the CPU. I'm not doing anything bandwidth intensive but there are reasons I want the GPIO and radio capabilities present for some of my projects though, and being able to deploy them with kubernetes management would be a huge plus. One option I was considering is using QEMU. The Wikipedia mentioned it now has good support for ARMx64 and the processor inside the Pi. As long as I could run at least 2 x logical nodes per Pi board that would be a huge boon.
– david_coneff
Dec 4 at 1:39
Yes, the Pi has extremely limited available bandwidth because the bus is shared by network, local storage and the CPU. I'm not doing anything bandwidth intensive but there are reasons I want the GPIO and radio capabilities present for some of my projects though, and being able to deploy them with kubernetes management would be a huge plus. One option I was considering is using QEMU. The Wikipedia mentioned it now has good support for ARMx64 and the processor inside the Pi. As long as I could run at least 2 x logical nodes per Pi board that would be a huge boon.
– david_coneff
Dec 4 at 1:39
add a comment |
1 Answer
1
active
oldest
votes
up vote
0
down vote
Based on jordanm's comment & the fact that both Docker Swarm and Kubernetes orchestration uniformly say a given node has to have either a full-VM or a physical host, I'm going to say it is in fact not possible in either system, but it would be especially fruitless to try doing so with Docker Swarm since it's already a DOA platform.
answered Dec 1 at 8:31
david_coneff
13
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
0
down vote
Based on jordanm's comment & the fact that both Docker Swarm and Kubernetes orchestration uniformly say a given node has to have either a full-VM or a physical host, I'm going to say it is in fact not possible in either system, but it would be especially fruitless to try doing so with Docker Swarm since it's already a DOA platform.
answered Dec 1 at 8:31
david_coneff
13
add a comment |
up vote
0
down vote
Based on jordanm's comment & the fact that both Docker Swarm and Kubernetes orchestration uniformly say a given node has to have either a full-VM or a physical host, I'm going to say it is in fact not possible in either system, but it would be especially fruitless to try doing so with Docker Swarm since it's already a DOA platform.
answered Dec 1 at 8:31
david_coneff
13
add a comment |
up vote
0
down vote
up vote
0
down vote
Based on jordanm's comment & the fact that both Docker Swarm and Kubernetes orchestration uniformly say a given node has to have either a full-VM or a physical host, I'm going to say it is in fact not possible in either system, but it would be especially fruitless to try doing so with Docker Swarm since it's already a DOA platform.
answered Dec 1 at 8:31
david_coneff
13
Based on jordanm's comment & the fact that both Docker Swarm and Kubernetes orchestration uniformly say a given node has to have either a full-VM or a physical host, I'm going to say it is in fact not possible in either system, but it would be especially fruitless to try doing so with Docker Swarm since it's already a DOA platform.
answered Dec 1 at 8:31
david_coneff
13
answered Dec 1 at 8:31
david_coneff
13
answered Dec 1 at 8:31
david_coneff
13
answered Dec 1 at 8:31
david_coneff
13
13
add a comment |
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f485310%2fis-it-possible-to-run-more-than-one-node-on-a-physical-host-without-full-fat-vm%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
Not an answer to your question, but if you are just getting into container orchestration, don't bother with swarm. It's basically dead as even docker (the company) has shifted focus to kubernetes. Kubernetes is the most popular solution but ECS (AWS only) is also fairly popular.
– jordanm
Dec 1 at 7:33
Thanks for the heads up. When I was looking at the options, Kubernetes seemed more developed but also more difficult to deploy according to comparisons of the two orchestration frameworks. But I'd rather be using the one that still has a future! The split between the old Docker <1.1.2 + Swarm and the new Docker >1.1.2 + Swarmkit was already confusing enough in their official documentation.
– david_coneff
Dec 1 at 7:44
If you can leverage VirtIO or other paravirtualization technologies, running VM's on a Pi actually isn't really all that much of a performance hit. The big performance killer on the Pi in most cases is the storage interface. This isn't to say that you'll get native equivalent performance, but it's still good enough for network simulation (and will probably beat containers for that, as the networking is actually marginally simpler using a VM).
– Austin Hemmelgarn
Dec 3 at 20:46
Yes, the Pi has extremely limited available bandwidth because the bus is shared by network, local storage and the CPU. I'm not doing anything bandwidth intensive but there are reasons I want the GPIO and radio capabilities present for some of my projects though, and being able to deploy them with kubernetes management would be a huge plus. One option I was considering is using QEMU. The Wikipedia mentioned it now has good support for ARMx64 and the processor inside the Pi. As long as I could run at least 2 x logical nodes per Pi board that would be a huge boon.
– david_coneff
Dec 4 at 1:39