[Thinlinc-technical] HA++
Rui Lapa
rui.lapa at ruilapa.net
Wed Apr 23 12:39:50 CEST 2014
Hello,
Let me explain a little more.
Currently, we have a centralized FreeNX scenario with 2 frontend
servers and 29 backend servers, supporting +500 users, all running in
the LAN, on old server hardware.
This scenario has been running for 4 years. We created message
queuing and remote tasks to alleviate our stupid day to day sysadmin
jobs, ...
More info, on this 2 year old presentation (sorry, portuguese)
http://www.slideshare.net/rui_lapa/desktop-linux-na-tranquilidade-portolinux-presentation?qid=a331b942-8a98-4ae9-aea0-c02698e698b4&v=default&b=&from_search=1
At the moment, we are evolving the solution to "crazy", so we want
to provide a desktop to external "entities" and shops without internal
network access, while still providing internal linux desktops.
The crazy is, that the external desktops servers will run on a
cloud provider.
In the future, we plan to ONLY use cloud servers, while keeping the
2 vsmservers on the DMZ.
So far, we tested 2 scenarios already, with great success:
- 2 vsmservers + 2 agents, all on LAN
- 2 vsmservers + 2 agents, all on the cloud provider with a VIP
(opened ports TCP 904, 1010 and 22)
At this time we are doing our final test, where we have 2 DMZ
vsmservers, 3 LAN agents and 2 Cloud agents.
The datacenter has 4 dedicated internet circuits, with 1 IP each,
in a in/output load balancing scenario. (F5 BigIp).
The cloud agents are getting 4 (tcp/904) pollings from each
external ip of each circuit.
Due to this, we configured cloud agents "/vsmagent/allowed_clients"
mapped to the 4 external NAT IP's.
Unfortunately, even though, we get the tcpdump from each IP to
TCP/904 and see the replies, the vsmservers webadmin status load page
keeps considering these servers one cycle up, the next up/down, randomly.
The internal vsmserver have the "/vsmserver/terminalservers", with
the external cloud ip's and the internal lan ips.
But, is there anything more we need to do?
Thanks a lot for the help,
Rui Lapa
PS: This is a crazy project, but I like CRAZY! ;)
On 04/23/2014 07:26 AM, Peter Astrand wrote:
>
> In general, we recommend that all machines of a cluster (both VSM
> Servers and VSM Agents) are located on the same network segment. Running
> VSM Server in a DMZ and the Agents on another network does not really
> give any advantages. Any particular reason why you want to do that?
>
> Also, splitting the cluster across the Internet is not either
> recommended. The communication protocols used inside a ThinLinc cluster
> are designed for a local network segment.
>
> Can you tell us what you are trying to achieve? Perhaps you are looking
> for some kind of "meta cluster" or "cluster of cluster" functionality?
>
> Best regards, Peter
>
> On Mon, 21 Apr 2014, Rui Lapa wrote:
>
>> Hello,
>>
>> We are testing thinlinc with a strange scenario.
>>
>> The vsmservers will be on our facilities (DMZ), and the agents will
>> be both on our facilities (LAN) and simultaneouslly on remote
>> locations (Internet).
>>
>> The vsmservers have private IP's, NAT'd behind 4 possible circuits,
>> each one with it's own external IP (round-robin).
>> We have an external virtual IP load balanced to both vsmservers.
>>
>> The external agents will receive a status polling (tcp/904) from
>> either 4 external IP's.
>> The internal agents will be polled using their private LAN IP.
>>
>> On the agent we have configured "/vsmagent/allowed_clients" mapped
>> to the 4 public IP's, but they are switching down/up/down/up!
>>
>> Is this scenario possible, and where are we making a mistake?
>>
>> Thanks a lot,
>> Rui Lapa
>> _______________________________________________
>> Thinlinc-technical mailing list
>> Thinlinc-technical at lists.cendio.se
>> Manage your subscription:
>> http://lists.cendio.se/mailman/listinfo/thinlinc-technical
>>
>>
>
>
> ---
> Peter Astrand ThinLinc Chief Developer
> Cendio AB http://cendio.com
> Teknikringen 8 http://twitter.com/ThinLinc
> 583 30 Linkoping http://facebook.com/ThinLinc
> Phone: +46-13-214600 http://google.com/+CendioThinLinc
More information about the Thinlinc-technical
mailing list