[..] Broker tcp pour répartir les connexions rdp

[edouard37]

Bonjour,

Comme le titre l'indique, je souhaite mettre en place un broker pour répartir les connexions entre plusieurs serveurs RDP.


La synoptique de cette idée est la suivante :

Je lance sur un serveur mon broker qui écoute sur le 3389 (RDP) si c'est le premier user qui se connecte alors je l'envoi vers le serveur 1....et j'enregistre son IP son login et l'ip du serveur dans une BDD. Puis le deuxième user ira se connecter sur le deuxième serveur (avec enregistrement dans la BDD des infos.)

Maintenant, user 1 se connecte (alors on supprime dans la bdd ses infos)

User 3 se connecte, je ne l'envoi pas vers mon troisième serveur mais vers le serveur 1.

Avez-vous des idées sur la mise en place de ce genre d'outils, des liens, des tuyaux sur ce qui concerne tcp connexion/listen...la redirection des communications.....pouvez-vous partager votre experience...


Merci à vous de votre retour.

Bonne journée.

Edouard

[Tlem]

Merci de lire les règles de présentation d'un message.

[edouard37]

Ok, je suis arrivé trop tard. Merci timmalos

[edouard37]

Un petit up.

Personne n'est intéressé ???

[Yogui]

intéressé ... bien sûr lol

Mais le problème est que je n'ai aucune idée de savoir comment faire...

Problème 1 rediriger un flux RDP.

Problème 2 gérer la base de donnée en gérant les déconnection sauvage.

Problème 3 récupérer les infos des clients tse (ce problème n'est présent que si client tse de type linux)


sinon pour répartir les connexions RDP entre X serveur en prenant en compte non pas le nombre d'utilisateur mais l'utilisation processus et ram j'ai plus une idée...

une GUI de connection qui intéroge les serveurs sur leurs ram disponible et sur l'utilisation de son/ces processeur/s pour diriger l'utilisateur vers le serveur le plus disponible. Ce doit être possible avec autoit si les client sont windows.

petit édit (avec ce genre de script de connexion faut compter plusieurs longue seconde avant d'avoir le login du serveur)

[edouard37]

Merci pour ta réponse :

Voici ma réflexion :

Solution 1 : Accès au broker via l'icône rdp. Mon broker écoute les connexion entrante sur le 3389. Dès qu'une connexion arrive, il enregistre IP et login et le serveur vers lequel l'utilisateur est redirigé dans une bdd.
Problème : comme tu l'as dit, comment gérer les déconnexions normales et les déconnexions sauvage mais surtout la redirection.

Solution 2 : un exe que lance mon user qui va interroger une BDD, chaque utilisateur qui interroge la bdd et qui souhaite se connecter s'enregistre dans la bdd. Puis en fonction du résultat de la requête, le rdp récupère la bonne IP et se connecte au serveur. Dans le principe, si nb user de serveur 1 > nb user de serveur 2, alors tu te connectes sur serveur 2. Le soir RAZ de toutes les connexion de la BDD, ou alors on test si session rdp existe tjs (voir comment les récupérer)

Du coup, avec la solution deux, ce n'est plus tellement un broker, mais quelquechose qui pourrait plus ou moins fonctionner. De plus dans mon cas, ce sont de très bonne machine, du coup le test RAM / Proc n'est peut être pas nécessaire..;et par conséquent on gagnera du temps à l'ouverture.

Mes clients sont tous en Windows....

[Yogui]

autre solution l'équilibrage de charge Windows avec montage d'un annuaire session (windows 2000 / 2003 / 2008 serveur advance pour avoir l'annuaire)

[edouard37]

Il y a une condition importante pour l'annuaire de session : domaine w2003 avec tse en w2003 Enterprise.....ce que je n'ai pas.

[jl56]

Bonjour

Dans un premier jet d'idée .
Je verrai plutot le probleme dans un autre sens

exemple un poste exécute un script, celui lit dans un fichier (exemple rdp.ini)
si un poste s'est déja connecté sur le serveur1.
Si non alors exécution du rdp sur ce serveur et inscription dans le fichier rdp.ini .
Si oui test sur le 2 emm serveur ,rdp2.ini etc..

A la sortie de la connexion ont dévalide le poste dans le fichier pour libérer le serveur

A+ jl56

[edouard37]

Bonjour jl56,
Ta solution n'est pas mal....
Dans la partie déconnexion, cela implique qu'il y a un script indépendant qui tourne sur le serveur et qui désenregistre le user. Comment le ferais-tu tourner ??? Par GPO à la fermeture de la session ???

[Yogui]

j'ai testé avec 2 serveurs un "lanceur" de connexion un .ini mis à disposition sur un serveur pour tenté de repartir la charge...

ça fonctionne... effectivement les clients se connectent alternativement sur l'un et l'autre serveur

tse.ini
[IP:XXX.XXX.XXX.XXX]
ServeurA
[IP:XXX.XXX.XXX.XXX]
ServeurB


hypothèse de travaille et ce qu'il reste à faire

Lorsqu'une session se déconnecte alors un autre script pour supprimer l'entrée avec l'IP (GPO ou service sur le serveur ts ?)
lors d'une déco sauvage rien mais si le client se reconnecte alors récupération des infos dans le .ini et "rebranchement" sur le bon serveur (récupération de la session) paramètrage du serveur TSE fermeture des sessions déconnectée depuis X temps.

[edouard37]

On est d'accord.

Je vais essayer de voir ça....pour la partie client dans un premier temps...et pour la partie serveur dans un deuxième.

Pour la partie déconnexion, que penses tu de l'utilisation de query.exe + lecture du fichier ini qui se lance via un exe autoit à la fermeture de la session..... Query.exe devrait pouvoir nous retourner une infos intéressante....et exploitable

[jl56]

Bonjour à tous

Dans la stratégie de ton domaine tu peux paramétrer un script à la fermeture de session des utilisateur membre d'une OU ( j'utilise un script à l'ouverture pour connecter les lecteurs réseau ).

Dans ce script tu lances le script autoit pour désinscrire le client en cours.


A+ JL56