Hello !! Mina San
Je suis nouveau sur votre forum et à force de le consulter , je me suis enfin décider à poster …
Je suis en cours de migration en XENAPP5 et je dois mettre en place une nouvelle architecture et je voudrais savoir si cela est possible de séparer le Data Store et le Data Collector sur deux machine bien distingue ou voir mm des VM ( ESX3.5 ) … Je sais c’est un peu tordu …
Y aurait il quelqu’un qui aurait fait ca ?? si oui quels sont les inconvénients ??
merci
bonjour,
il est tout à fait possible que la machine DataCollector ne soit pas celle DataStore.
La manip la plus simple est d’aller dans la CMC(PSC) dans les propriétés de la ferme, sélectionner Zones et indiquer un serveur en “Most Preferred”. Il faut ensuite rebooter les serveurs
merci pour votre rapidité et j’avais plus ou moins soupçonner ca
Une autre question :
Suis je dans le tord en laissant mon Data Store et RM sur le même serveur et de déporter le rôle de Data Collector sur un autre serveur ? ou il faut conserver le Data collector et RM sur le mm serveur ?
On m’a conseiller la deuxième solution ( DC et la RM sont liés ),mais je ne suis pas convaincu par ses explications
Mon avis au sujet de la separation est celui :
- Je centralise tout les connexions ODBC sql2005 sur le même serveur ( RM et DS )
- J’évite un goulot entremêlement lors des accès à la bases SQL et les connexions clients
mais je crée des points de rupture en séparant les rôles
Quel est la bonne solution ou les deux sont valables ?
Bonne Soirée
Donc le DataStore est hébergé sur un serveur SQL ? dans ce cas, si un SEUL serveur fait la liaison avec le DataStore, si celui-ci tombe, tous les autres serveurs de la ferme perdront leur liaison au DataStore
pour la base RM, de toute façon le DCS (le serveur qui envoie les données à la base RM sur le serveur SQL) est unique. celui-ci n’est sollocité que lors de la mise à jour de la base…
avoir un DC qui fait que cette tâche n’est utile que sur les environnements qui commencent à être imposants. La taille critique à partir de laquelle dédier le DC (c’est à dire qu’il n’héberge pas d’applications) dépend de l’expérience de chacun (n’est ce pas Max? ;D)
mais en règle générale, c’est mieux de séparer le DS et le DC : ceci n’est donc valable que pour les fermes ayant un DS MSDE ou Access, ou pour les fermes qui fonctionneent en mode indirect (un seul serveur communique avec le serveur de SGDB)
Merci pour ce petit cours mm si cela ne m’a pas trop aiguillé
Oui the DS est l’un des points de rupture de la ferme mais je n’ai pas encore buché sur cette problématique qui est toute aussi critique qu’un DC … Auriez vous une idée ( pas cluster MSSQL )?
Revenons à nos moutons , oui j’ai besoin d’isoler les rôles infrastructures du fait que nous avons absorbé un société de service qui est dans un monde 100% citrix en XENAPP5 ( 200 utilisateurs ) et en faisant ca je pense avoir anticiper mes futurs problèmes de connexions car nous avons deja 100 connexions et cela va s’accroit d’ici la fin de l’année …
Donc j’ai monté mes machines et séparer comme je le pense ( RS et RM ensemble et fonction DC sur l’autre ) pour le moment je suis en phase de test et cela me semble concluant mais comme citer plus haut c’est autour du DS maintenant ??
étant donné le nombre total de connexions, DC et RM peuvent tout à fait être mis ensemble.
Mettre DS et RM est également une bonne solution, ce serveur sera cependant peu sollocité dans le cours normal des opérations. Le DC sera lui sollocité évidemment “fortement” le matin et le soir (en assumant que les utilisateurs ne jouent pas à ouvrir et fermer des sessions avant d’aller aux toilettes ou manger ;D)
Pour le DataStore, une base Access est amplement suffisante pour supporter le nombre de serveurs et utilisateurs indiqués mais tout comme l’utilisation d’un XenApp unique pour communiquer avec un DS hébergé en SQL/Oracle/DB2, c’est un point de rupture (tout comme une base Access).
Cependant une ferme peut fonctionner indéfiniement avec un DS absent (cependant aucune configuration de la ferme n’est possible… 
)
“”" Cependant une ferme peut fonctionner indéfiniment avec un DS absent (cependant aucune configuration de la ferme n’est possible… “”" elle est un peu bizarre cette phrase sachant que la notion de DS est importante et sensible chez Citrix , si c’est le cas, cela ne sert à rien de sécuriser ou redonder la DS sachant que cela peut fonctionner indéfiniment ou meme lors d’un crash ne rien faire cela n’aggraverai pas la situation ;D
mais bon je vais quand meme chercher une solution
Note : A parler avec vous cela m’inspire me fait avancer à petit pas dans mon projets et j’ en suis content …
le DataStore est critique dans le sens où cette base de données comporte toutes les informations sur la ferme et sa configuration (propriétés de la ferme, des serveurs ; applications publiées, load balancing, administrateurs, stratégies etc etc).
Historiquement (avec MetaFrame XP), les liencences étaient stockées dans le DataStore et si un serveur perdait la liaison avec le DS pendant plus de 96 heures (48 heures avant FR2/SP2), ce serveur n’acceptait plus de connexions.
Depuis MPS3.0, un serveur de licences a été introduit, rendant caduc la limitation de 96 heures (qui n’est plus en place dans MPS3.0 et suivants). Donc il est effectivement possible de faire fonctionner une ferme sans son DataStore, la copie locale de celui-ci (présente sur chaque serveur) étant utilisée.
Mais ce n’est guère utilisable au quotidien, étant donné que les consoles d’administration Citrix ne pourront être lancées, qu’aucune modification sur la ferme ne pourra être effectuée etc
"ThinIsFat" wrote:
Donc le DataStore est hébergé sur un serveur SQL ? dans ce cas, si un SEUL serveur fait la liaison avec le DataStore, si celui-ci tombe, tous les autres serveurs de la ferme perdront leur liaison au DataStore
pour la base RM, de toute façon le DCS (le serveur qui envoie les données à la base RM sur le serveur SQL) est unique. celui-ci n'est sollocité que lors de la mise à jour de la base...
avoir un DC qui fait que cette tâche n'est utile que sur les environnements qui commencent à être imposants. La taille critique à partir de laquelle dédier le DC (c'est à dire qu'il n'héberge pas d'applications) dépend de l'expérience de chacun (n'est ce pas Max? ;D)
mais en règle générale, c'est mieux de séparer le DS et le DC : ceci n'est donc valable que pour les fermes ayant un DS MSDE ou Access, ou pour les fermes qui fonctionneent en mode indirect (un seul serveur communique avec le serveur de SGDB)
pour la base RM, de toute façon le DCS (le serveur qui envoie les données à la base RM sur le serveur SQL) est unique. celui-ci n'est sollocité que lors de la mise à jour de la base...
avoir un DC qui fait que cette tâche n'est utile que sur les environnements qui commencent à être imposants. La taille critique à partir de laquelle dédier le DC (c'est à dire qu'il n'héberge pas d'applications) dépend de l'expérience de chacun (n'est ce pas Max? ;D)
mais en règle générale, c'est mieux de séparer le DS et le DC : ceci n'est donc valable que pour les fermes ayant un DS MSDE ou Access, ou pour les fermes qui fonctionneent en mode indirect (un seul serveur communique avec le serveur de SGDB)
De quoi ?
oulla vu la reponse il doit avoir quelque chose qui ne vous plait pas ?
mais non… max réagit à ce que j’ai dit ;D vu des sujets précédents sur quel type de SGBD était le mieux adapté en fonction du nombre de serveurs/applis/users…
"ThinIsFat" wrote:
mais non... max réagit à ce que j'ai dit ;D vu des sujets précédents sur quel type de SGBD était le mieux adapté en fonction du nombre de serveurs/applis/users..
C'est très subjectif de donner un nombre de serveurs à gérer à partir duquel il faut dédier un DC, xml ou pas.
Tout se mesure avec un jolie perfmon et dépend de la consommation de ressources des applis qui pourraient tourner sur le DC et de la façon dont les utilisateurs se connectent le matin (cfé, pause clope ou boulot direct) ....
ahahha merci mais le perfmon et moi cela ne fait pas très bon ménage et j’ai pris en considération les conseils de ThinIsFat en séparant le DS et DC , bien avec leurs bases de données qui va avec et cela me semble pas mal …
j’avoue également que je ne suis pas habitué à croiser des environnements qui n’ont pas de DC ou broker XML dédiés ;D
Bonsoir ,
Suite à mes tests semi production en combinant Xenapp4.5 et ESX3.5 et je sais que ce mélange d’environnement est encore jeune car les avis diffères sur spec des vm mais à plus de 90% , on tombe sur la configuration qui est :
La vm doit avoir un cpu , un max de ram ( 4go) avec la suppression du memory ballooning driver et des port com .
En les respectant , j’ai des comportements bizarre , des montées en change du cpu (très difficiles à expliquer , mais ce sont des alertes métriques rouges sur le Data collector) . Ces alertes apparaissent lors des phases d’installation ou paramétrage sur les serveurs d’applications et je ne comprends pas …
Ma question est la suivant , la nouvelle console " access management console " ne sera t elle pas plus sensible sur la gestion d’une ferme ou est ce la séparation en virtuel des rôles qui affole la " access management console " ??
Question : Est-ce que tu as adapté les profils de mesure Citrix à tes serveurs ?
Concernant la config des vm citrix, fait une recherche de vrc (pour virtual reality check) sur le forum.
Tu devrais trouver une étude comparative des différentes config de Vm et le nombre d’utilisateurs associés.
Il me semble que la config qui apporte la meilleure densitée est basée sur des VM bi-pro, 3,25 Go de RAM pour éviter l’activation du PAE.
Merci
" Question : Est-ce que tu as adapté les profils de mesure Citrix à tes serveurs ? " je ne comprends pas le terme profils de mesure Citrix ?? et je ne prefere pas repondre n’importe quoi …
Sinon pour l’nfos , je vais une recherche sur le forum
Rappel : Les deux vm ont la fonction DS et DC et aucune publication d’application ou de bureau n’est envisagé
Profil de mesure ou profil de contrôle
en résumé, ne JAMAIS tenir compte des valeurs remontées par RM (jaune, rouge) tant qu’elles n’ont pas été personalisées… ce sont des valeurs bateau (paquebot même) qui doivent absolument etre modifiées pour prendre en compte l’environnement
Dsl pour le retard sur retour d’expérience sur Citrix Xenapp 5 et Vmware …
Depuis le rajout d’un cpu et une légère baisse de la ram à 3,4go , le serveur souffle mieux et les metric qui s’affiche dans la Access Console ne s’affolent plus … Thk U max pour ce conseil qui évitera de me faire de cheveux devant la AC …
Donc maintenant je peux clôturer ce post …
merci encore