Hello everybody here at the Lightning Talks at Boston here in Brussels.
I want to introduce to you Sybil Savon and he's talking about an SSH Proxy Health Load Balance
SSH.
Give him a warm welcome and enjoy the talk.
Thank you for coming.
So first, a bit of a preemble, I'm working at CEA in France.
It's a national research institute, we are about 20,000.
We work on fundamental research to industry.
We work on medicine, on energy, on defense.
All these subjects need a lot of compute power, so we have many supercomputers.
Our need was to enable all the users to access these computers.
The problem is we have many nodes, logging nodes on each supercomputer.
Those nodes are on a private network.
The users are on a public network, so we have to have a gateway in between.
People need to be able to connect with SSH.
I guess many of you know what is SSH.
It's a remote command line connection and of course secure.
So we had a solution in 2014 by Arno Gignar.
He made SSH Proxy, the first version of it.
It's written in Go, there is only one configuration file in YAML.
It can handle a lot of connections.
Currently, we have a thousand users simultaneously connected with 100,000-day connections.
We are ready for 100 gigabits per second.
I will just explain what we are doing at CA.
I will show you a typical platform and we will detail the configuration file step-by-step.
On this slide, you can see the final platform.
We just start with the external network, the internal network, the gateway is in between.
The user wants to connect on the internal network.
He does, for example, SSH, she may, he runs on the gateway which runs open SSH.
In open SSH, we have just one line in the configuration file, the first command one,
who says just launch SSH Proxy, SSH Proxy, then we will choose a destination node for
the user and we will connect him by launching an SSH client.
In fact, it's really easy, SSH Proxy takes the in from one size and plugs it in on the
out of the other side and the same out on the in.
Of course, such a simple platform, we have this simple file, just two lines, we define
the name of the service, it's not even necessary, but it's always good to have a name.
And you set an array of destinations, here we have one destination, easy, okay, no we
have two destinations, not really complicated, we can choose how the destination is chosen
with root select, here by default is it's random and right now if the user connects
a second timer, the second connection will also be chosen randomly, so he may land on blue
or on red, it's totally random, it's not perfect, so we add something for it to be state
full, we use it is CD, which is a distributed database, it's just three lines on the
configuration file, no, we have a state full proxy, so if the user connects a second time,
then he will always land on the same login node with the default configuration, we will
see later, okay, so as the it CD is distributed, you can put as many gateways as you
want, if you need some redundancies, some more throughput, if you want, you can add more.
And finally, if you have more platforms, you just have to add some overrides to check
the source IP, where you connect from, and depending on these IPs, you will land on the default
platform or on the other, which is left here, this is exactly how we use it at CA with 1000
of connected users.
It's right now, it's really easy, we have many features, we will have a look at some,
the first one, root select as we saw, can be random, but if you want it to be based on the
active connections, you can also be based on the currently used bandwidth, so if you want
to spread the different users connections, it may be interesting, the random one works
really generally, then you can choose the model, which can be balanced or sticky, by default
it's sticky, but if you want someone to land on different nodes each time he connects,
you choose balanced, it can be useful when you make parallel transfers and not just a simple
connection.
And finally, an option we added, because it had to be added, the max connection per user,
you can easily imagine a scenario where a user has a robot connecting every 10 seconds and
you can have problems really quickly, so with this we can avoid these problems.
So here is an example of the sticky and balanced configurations, by default, here we have
a sticky connection, so let's say the six connections are made sequentially, so the first
user connects to two shimei, okay, he runs on the red node, it's totally random, then he connects
a second time, then it's not random because it's sticky, he will land on the same, he connects
a third time, okay, he will land on the red also, then another user connects on the
shimei balanced, then he will, he will land on one of the nodes, it's chosen by connections,
as you can see on the last line, and so he SSH proxy, chooses the nodes with the last connections
established, so it can be blue, triple or golden, so it will be random between
these three, and then on each connection it will, it will land on the other nodes.
No, that's, no, that we have a lot of connections established, we want to monitor them,
so there is SSH proxy CTL which can show all the connections, all the state, all of all the
login nodes, and it can be easily scriptable because you can output it in JSON or in CSV,
and SSH proxy CTL can also, if you want, manipulate the state of the login nodes, so if you want
to take a node out of production for maintenance, for example, you just have to SSH proxy CTL
disabled the node and it's done. Finally, we already saw the override system with the new version
2, which will be available soon, really soon, we can override all the options of SSH proxy,
we can override them for a given service like we saw with much source, but we can also override
it for specific users or the group of users, and we can combine all these overrides with all
on end. There are applied from top to bottom, and each one is applied. For example, if I connect
with this configuration, my name is Cyril, so I will match user Cyril and I will land on
perier or badwa. But if someone else connects and is in the group parting, he will end also
in perier or badwa, but if he's in the group sparkling and yeast, at first the SSH proxy will
think he will land on perier and badwa, but then as there is another match later, he will finally end
on the distinctions blue red report on Galvan. There are many more features I want to talk a lot
about them. If you want to dive in all the other features or if you want to speak about SSH proxy,
you can come, we can have a drink and talk about this. Thank you for listening.