This patch work after patch from http://bugs.x2go.org/cgi-bin/bugreport.cgi?bug=686
-- С уважением, Сергей Савко, начальник IT отдела. +7-931-361-04-02
Control: clone -1 -2 -3 Control: reassign -2 x2goclient Control: reassign -3 python-x2go Control: retitle -1 add exclude-hosts parameter to selectsession task Control: retitle -2 request another server from broker provided server is down Control: retitle -3 request another server from broker provided server is down Control: severity -1 wishlist Control: severity -2 wishlist Control: severity -3 wishlist Control: block -2 by -1 Control: block -3 by -1 Control: tag -1 - patch
Hi Sergey,
On Fr 05 Dez 2014 17:14:51 CET, Sergey Savko wrote:
This patch work after patch from
http://bugs.x2go.org/cgi-bin/bugreport.cgi?bug=686
After thinking this through a little, I come to the conclusion that
the broker cannot decide if a machine is down or not.
We have to think very generically. There may be a scenario where the
broker machine may be on an network segment where it cannot ping/reach
the X2Go Servers.
The X2Go Clients can reach the X2Go Broker. The broker provides an
X2Go Server address on the "selectsession" broker task to the X2Go
Client. Then the X2Go Client should test if that X2Go Server address
works (via a simple ping6/ping command, machines should always be
pingable!!!). If the ping fails, X2Go Client should go back to the
broker and say: hey, that server failed for me, give me another one
(but not the one you already gave me).
I fear we need to do four things for this bug to get fixed:
- extend broker/client communication protocol (second/third/...
selectsession call with a list of hosts that did not work on previous attempts) - extend X2Go Session Broker with an exclude-hosts (or so)
parameter for the selectsession task - Adapt X2Go Client: ping X2Go Server, go back to the broker if
server is down and request another server - Adapt Python X2Go: dito
Regards, Mike
--
DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976 148
GnuPG Key ID 0x25771B31 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 06.12.2014 um 23:56 schrieb Mike Gabriel:
Then the X2Go Client should test if that X2Go Server address works (via a simple ping6/ping command, machines should always be pingable!!!)
Chiming in here: Even if they aren't pingable - Port 22 (or whichever you've set in the config as SSH port to be used) must be accepting connections. You can test that on Linux with
nc -z ip.goes.he.re port_goes_here && echo "is reachable"
... and I'm sure there are ways to do that inside the client code, too. Check if you can get a TCP handshake going within a set time frame (1 second? 2 seconds? 5 seconds?), then disconnect and proceed depending on the result.
Actually ... simply lowering the timeout value for the currently existing code that handles the connection, when called in broker client mode, might already work.
- -Stefan
BAUR-ITCS UG (haftungsbeschränkt) Geschäftsführer: Stefan Baur Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364 Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32)
iQEcBAEBAgAGBQJUg46CAAoJEG7d9BjNvlEZAhIIAJA21I9lvk3hY6R3eAiCO2MG YSNlsUy/ShyhwB37UCNyCLOtEJ9j14xS73UNjbTiRkIFRE12kdtS8vyAPAdZJYqi 2+vbiVjg+TZ31rvk7RrkPyEepJ3+0UfRkfFPDm07sTP47DiBx+zYOyie2qVdrw1U GXJtQrylZRlzhVUi7rbAmNSp1HYaQ+B5yRX1ApmvNrZ+1+GZFybyZO2+eDM6ClHI QBmCePp5DPfN5bE9d+GvxWArkWQe5sgNT1USz7r64F5DOgB09M8f6vkuW3ygq4cW 8dDBhPnJv4PKs7IxLNnM+K1OnPopcKs1/EmkD5nbcNCvGSRW93nV4ic6RoZSD7g= =8x/F -----END PGP SIGNATURE-----
If the server will give the address to which it can not connect, there will be no load balancing works. Since the server is connected to receive the coefficient of loading.
----- Исходное сообщение ----- От: "Mike Gabriel" <mike.gabriel@das-netzwerkteam.de> Кому: "Sergey Savko" <savko@tophouse.ru>, 684@bugs.x2go.org Отправленные: Воскресенье, 7 Декабрь 2014 г 1:56:05 Тема: Re: [X2Go-Dev] Bug#684: select_session offers offline servers to X2Go Client
Control: clone -1 -2 -3 Control: reassign -2 x2goclient Control: reassign -3 python-x2go Control: retitle -1 add exclude-hosts parameter to selectsession task Control: retitle -2 request another server from broker provided server is down Control: retitle -3 request another server from broker provided server is down Control: severity -1 wishlist Control: severity -2 wishlist Control: severity -3 wishlist Control: block -2 by -1 Control: block -3 by -1 Control: tag -1 - patch
Hi Sergey,
On Fr 05 Dez 2014 17:14:51 CET, Sergey Savko wrote:
This patch work after patch from
http://bugs.x2go.org/cgi-bin/bugreport.cgi?bug=686
After thinking this through a little, I come to the conclusion that
the broker cannot decide if a machine is down or not.
We have to think very generically. There may be a scenario where the
broker machine may be on an network segment where it cannot ping/reach
the X2Go Servers.
The X2Go Clients can reach the X2Go Broker. The broker provides an
X2Go Server address on the "selectsession" broker task to the X2Go
Client. Then the X2Go Client should test if that X2Go Server address
works (via a simple ping6/ping command, machines should always be
pingable!!!). If the ping fails, X2Go Client should go back to the
broker and say: hey, that server failed for me, give me another one
(but not the one you already gave me).
I fear we need to do four things for this bug to get fixed:
- extend broker/client communication protocol (second/third/...
selectsession call with a list of hosts that did not work on previous attempts) - extend X2Go Session Broker with an exclude-hosts (or so)
parameter for the selectsession task - Adapt X2Go Client: ping X2Go Server, go back to the broker if
server is down and request another server - Adapt Python X2Go: dito
Regards, Mike
--
DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976 148
GnuPG Key ID 0x25771B31 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
clone #684 -1 retitle -1 select_session offers offline servers to X2Go Client thanks
Hi Sergey,
On So 07 Dez 2014 00:45:28 CET, Sergey Savko wrote:
If the server will give the address to which it can not connect,
there will be no load balancing works. Since the server is connected to receive the coefficient of loading.
Actually, after a third or fourth though: in cases where we use SSH to
connected from broker server to broker agent, there we can evaluate
the online status of the X2Go Server. So, in those cases we should
filter out, if a server is down or not and exclude that server from
the list of possible X2Go Servers.
Plus, I still think, that X2Go Client should request another machine,
if the provided server was offline and more than one server is
configured in the broker's session profile.
So, cloning this bug again...
#684: for tracking the new feature of re-requesting a server address new bug: filter out offline servers on the broker side already
Greets, Mike
--
DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976 148
GnuPG Key ID 0x25771B31 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
Processing commands for control@bugs.x2go.org:
clone #684 -1 Bug #684 [python-x2gobroker] add exclude-hosts parameter to selectsession task Bug 684 cloned as bug 692 692 was not blocked by any bugs. 692 was blocking: 690 691 Added blocking bug(s) of 692: 690 692 was blocked by: 690 692 was blocking: 690 691 Added blocking bug(s) of 692: 691; removed blocking bug(s) of 692: 690 retitle -1 select_session offers offline servers to X2Go Client Bug #692 [python-x2gobroker] add exclude-hosts parameter to selectsession task Changed Bug title to 'select_session offers offline servers to X2Go Client' from 'add exclude-hosts parameter to selectsession task' thanks Stopping processing here.
Please contact me if you need assistance.
684: http://bugs.x2go.org/cgi-bin/bugreport.cgi?bug=684 692: http://bugs.x2go.org/cgi-bin/bugreport.cgi?bug=692 X2Go Bug Tracking System Contact owner@bugs.x2go.org with problems
If you make a x2goclient connection to each farm server, then time will be increased by seconds for such connection. And if the server farm consist of more then 2-3 servers, then connection time will increase strongly.
----- Исходное сообщение -----
Plus, I still think, that X2Go Client should request another machine,
if the provided server was offline and more than one server is
configured in the broker's session profile.
Why not introduce a datastore which holds the current state of all the servers in the server farm? Then the broker could query that one for information to choose server from. One could either use a separate database server for this or use something like sqlite (or mysql / postgresql / other) on each server host with some sort of replication (redundancy and avoids the need to contact one specific server - all can reply to the queries) or caching of the central datastore contents.
On how to update this information in the datastore there's two ways I'm thinking of right now:
- Each server in the server farm writes to the datastore it's current status at regular intervals
- One, or several (backup role if the "master" should fail) server(s) have been given the responsibility to query the servers in the farm for their status at regular intervals
Regardless of the chosen implementation from one of those solutions would IMO:
- Make the broker-role easier to implement with regard to "advanced" setups
- Removes the wait for / time issue at connection, or selection, process - just contact the datastore
- Makes it possible to write a simple and central management app/webapp which one could administer the entire server farm
- other possibilites
Regards, Terje
2014-12-08 14:06 GMT+01:00 Sergey Savko <savko@tophouse.ru>:
If you make a x2goclient connection to each farm server, then time will be increased by seconds for such connection. And if the server farm consist of more then 2-3 servers, then connection time will increase strongly.
----- Исходное сообщение -----
Plus, I still think, that X2Go Client should request another machine, if the provided server was offline and more than one server is configured in the broker's session profile.
x2go-dev mailing list x2go-dev@lists.x2go.org http://lists.x2go.org/listinfo/x2go-dev
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 08.12.2014 um 22:48 schrieb Terje Andersen:
Why not introduce a datastore which holds the current state of all the servers in the server farm? Then the broker could query that one for information to choose server from.
<snip>
Welcome to Citrix MetaFrame Presentation Server, ca. 2003-2004.
While doing it that way may be an option, I think we should take a look what Citrix et al. have learned in the last ten years. ;-)
Of course, if they still happen to do it that way for Citrix XenApp (the current incarnation of MetaFrame), then it probably means there is no better solution.
- -Stefan
BAUR-ITCS UG (haftungsbeschränkt) Geschäftsführer: Stefan Baur Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364 Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32)
iQEcBAEBAgAGBQJUhibyAAoJEG7d9BjNvlEZywsIAJymqWdJ4bkAmiE6s1CxPcJZ SvFT6zqD2jSRpxubnThTi5q3ycF8AG6j7M7N/E5mJlMzhul2VcAWwMDt+0aerOlI kzK5d4tFVQomVSs7CV6vOAuLU8/5hURtpUHHmd4298nQzqvaBn1vHAHnzCuDzj+V j6X34PtLlHzGMtPcxQqYz2cP9YMX0nFmYysCI+C3aBqAJe3EVv3095xpDzeYmfL9 o93R8v12/akuDwSar3FpHkF9o9dxew9Igd5wY0SDlKpXtm9TEDOyDUpcTgsguA2g wmlqIihukKYJqlOLsCHGRL9hC+tENbJndcKjh++stZaHrCikEB9Lk5tG1zFwmEU= =cm95 -----END PGP SIGNATURE-----
HI Stefan, hi Terje,
On Mo 08 Dez 2014 23:32:18 CET, Stefan Baur wrote:
Am 08.12.2014 um 22:48 schrieb Terje Andersen:
Why not introduce a datastore which holds the current state of all the servers in the server farm? Then the broker could query that one for information to choose server from.
<snip>
Welcome to Citrix MetaFrame Presentation Server, ca. 2003-2004.
While doing it that way may be an option, I think we should take a look what Citrix et al. have learned in the last ten years. ;-)
Of course, if they still happen to do it that way for Citrix XenApp (the current incarnation of MetaFrame), then it probably means there is no better solution.
- -Stefan
Mr Lee and I have something similar in mind for X2Go next generation.
The ideal form maybe is:
o all servers individually check their current load status regularly o the servers in a farm exchange session states and load status among each other in regular intervals o a broker machine simply is part of such a farm (but not offering the remote desktop/application service), so it know everything already and doesn't have to query it o nothing gets written to a DB, if a machine goes down it looses its memory. If it comes up it joins back into the circle of servers and learns about the others anew (and provides info about itself to the others) o all information is stored in RAM by a permanent daemon process, no extra storage backend should be necessary (the information becomes useless immediately when a machine goes down, so why keep it in a DB?)
Greets, Mike
--
DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976 148
GnuPG Key ID 0x25771B31 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
-
Mike Gabriel -
owner＠bugs.x2go.org -
Sergey Savko -
Stefan Baur -
Terje Andersen