[W2K3] [CPS4] Architecture de la ferme pour le bureau publié

Bonjour,



Dans l’architecture de notre ferme Citrix, afin d’utiliser le bureau publié, nous avons 2 serveurs Citrix en Load balancing dont nous avons publié le bureau, puis sur 5 autres serveurs les applications publiées. Ce qui fait que, pour un utilisateur qui lance le bureau publié, l’utilisateur va ouvrir une session sur Serveur1. Puis l’utilisateur va lancer une application qu’il a sur son bureau publié, mais cette application se trouve sur un autre serveur Citrix (Serveur2 par exemple), la connexion va donc prendre encore 20sec environ, et ainsi de suite pour chaque application ne se trouvant pas sur le serveur où est publié le bureau.



Je trouve ça lourd pour l’utilisateur mais notre spécialiste Citrix qui est intervenu chez nous, nous a dit que c’était une sécurité d’avoir le bureau publié sur 2 serveurs en Load balancing (et je suis d’accord) mais au détriment des temps de connexion que rencontrent les utilisateurs.



Quel est selon vous le meilleur choix à faire ?



Pour ma part, j’aurais bien enlevé le Load balancing et installé sur chaque serveur les applications utilisées par nos utilisateurs afin qu’ils n’aient plus ces longs temps de connexion.

bonjour,



mmm logiquement il va y avoir du débat ici… ;D



il y a plusieurs façons de faire…

  1. la full Citrix compliant : pleins de serveurs en silo (en groupe de serveurs par application) et tu accèdes aux applications par PNA (ou WI ou au pire PN).


  2. la “je veux des bureaux tous pareils” : tu installes toutes tes applications sur tous les serveurs et tu publies un seul bureau en LB. faut pas rire j’ai pas mal d’exemples de fermes de 200+ serveurs avec ce principe


  3. la “des bureaux basiques et ensuite les applis” : tu prends des serveurs avec juste MS Office pour les utilisateurs de OS/2, Linux, Unix, Mac, BeOS, blabla blabli et pour les autres applis, c’est via PNA en passthrough.



    y aura surement 4, 5, 6 etc ;D



    il faut savoir que tu aura un temps de lancement pour chacune des applications SAUF si un serveur héberge plusieurs applications (session sharing) et ceci que tu lance les applis en direct ou via un bureau publié.



    le bureau publié sur deux serveurs c’est clair que c’est une sécurité. apres le fait d’avoir un bureau publié n’a aucune incidence sur les temps de connexions. ceux-ci seront présents également si tu enleves les bureaux publiés et ne fait que de la publication d’application.



    installer les applications sur tous les serveurs est un peu suicidaire selon le type d’application… certaines sont très gourmandes et peuvent faire impacter rapidement ton serveur (user1 lance un Catia alors que user2 joue au solitaire… user2 va rapidement crier que son solitaire bouge plus les cartes aussi vite). Sans parler de tous les problèmes d’incompatibilité (moi je veux Word 97 car ma macro fonctionne qu’avec lui, et mon SAP a besoin de Word 2003 et mon Siebel il veut IE6 alors que machin chose ne tourne qu’avec IE7 etc etc)



    perso, je me pencherai sérieusement sur les 20 secondes de logon…

Fight ! :laugh:



Whaooo, ton consultant n’a pas tort, mais:



7 serveurs, c’est une petite batterie. Il te monte un silo… sa se discute, et pour ca il faut plus d’information:



Quel type de poste utilisateur, plus exactement c’est des win32 ou pas (avec ou sans bureau local)?

Les différentes applications sont elles compatibles entre elles (comme dit Thinisfat avec Word, client Oracle…)?

Quel sont les fréquences de mise à jour des appli (genre, si tu a besoin de mettre à jour une appli avec un reboot en pleine prod tu es bien obligé de l’isoler) ?

Combien d’utilisateur concomitant (comme tu n’as que deux bureaux …)?



++

Round 2 : take position, engage, fight !!!



Perso , je raisonne par le nombre, je m’explique.

Si on considère que l’application est utilisée par au moins 70 % des users (ou que cette application n’est pas très complexe à déployer) et que cette application ne consomme pas énormement de resource au point de claquer un serveur avec 2 sessions concommitantes, l’application peut être intégrée sur les serveurs “bureautiques”.



Les applications hors de ce cadre (incompatibilités, ressources excessive) peuvent se voir mettre au coin sur un serveur à part.

L’avantage de mettre le plus possible d’applications sur le serveur bureautique est le lancement instantané des applications via des shortcuts locaux. Je pense aussi que cette mouvance cadre avec l’augmentation perpetuelle de la puissances des serveurs (bi-pro quad coeur, etc).



L’inconvénient majeur d’une solution silo est la gestion des profils, la communication entre la session bureau et les sessions applicatives(presse-papier, pb de seamless, com entre applis, … )et la conso moyenne de ressources par utilisateur (2 sessions ou plus, mem, cpu, disque, 2 profils,) qui necessite souvent plus de serveurs et jouer via des scripts ex : avoir les même imprimantes rsx entre les profils…



Sinon j’aime bien les silos :), cela m’a aidé plusieurs fois avec des applis kipu.

Pas de fight en vue :-X ?

ah ben non… >:(

C’est fou ca >:( C’est le premier point a voir, et ca ne perturbe personne ???



Enfin, bientôt avec XenServer, XenApp et provisioning server la discutions sera bien plus fun ;D ;D