none
RDS sur 2012 plante constamment RRS feed

  • Question

  • Bonjour,

    Nous avons un serveur 2012 R2 sur lequel est installé le service RDS + Broker + Gestionnaire de licences. L'AD est sur un Windows Server 2008 R2. Toutes les majs sont installés sur les deux.

    Ce serveur accueille près de 70 personnes au maximum en simultané et nous le savons, est un peu sous-dimensionné au niveau du CPU.

    Deux fois par jour, le serveur se fige pour des raisons inconnues. à vrai dire, il est encore accessible (par les lecteurs réseaux, ping etc...) mais c'est comme si il attendait une action qui l'empêche de faire autre chose. Les applications sont toutes bloquées les unes après les autres. Le problème n'est certainement pas aléatoire mais nous n'arrivons ni à le reproduire ni à savoir d'où il provient.

    Nous avons déjà éliminé comme piste un serveur non à jour, et ce n'est pas non plus un problème de charge. Il a planté plusieurs fois alors que nous n'étions que 7.

    Auriez-vous des pistes ?

    Merci beaucoup, je reste à disposition.

    Config du serveur : Xeon 4cores, 50 go de Ram

    vendredi 9 juin 2017 08:23

Réponses

  • Bonjour à tous,

    Quelques mises à jour d'informations :

    • La piste de la surcharge CPU se réduit, le serveur a freeze alors que nous n'étions que deux sessions. Cela semble assez peu pour un Xeon.
    • Pour le DDOS, j'y ai songé mais le souci c'est que les tentatives sont parfaitement réparties dans le temps (une toutes les 30 secondes). Donc ça n'a pas l'air d'être un pic de connexion qui fait chuter le serveur. Les freezes répétés du serveur peuvent être espacés de deux heures ou deux jours, donc pas de lien avec un dépassement de mémoire/registre/logs à priori.
    • On parle de 70 connexions simultanées en TSE classique.

    Je suppose que le 100Mo était pour le remote App car en moyenne nous tournons tous à 200 Mo minimum avec des pics à 3Go pour certains utilisateurs.

    Je mets en place le data collector set et je reviens vers vous dès que j'ai des nouvelles. Merci encore.

    lundi 12 juin 2017 08:01

Toutes les réponses

  • Bonjour,

    Vous pouvez vérifier l'état d'nitégrité du serveur via ces commandes :

    sfc /scannow

    chkdsk /f c:

    Dism /Online /Cleanup-Image /RestoreHealth

    Il faut également regarder le journal d'évènement pour voir si vous n'avez pas des traces correspondant au période ou vous rencontrez des problèmes.


    Merci de marquer comme réponse les sujets qui vous ont permis d'avancer afin que cela puisse être bénéfique aux personnes qui rencontrent le même problème.


    vendredi 9 juin 2017 08:49
  • Le serveur étant constamment en production, je dois m'assurer que ces commandes ne perturberont le fonctionnement d'aucun logiciels. Je posterai les résultats quand j'aurai vérifié cela.

    Au niveau des logs, j'ai effectivement des erreurs mais jamais les mêmes. J'en ai quand même une qui revient assez souvent (mais pas tout le temps) :

    "Une demande de connexion TLS 1.2 a été reçue par un client mais aucune des suites de chiffrement du client n'est prise en charge par le serveur".

    Je sais que mon serveur ne prend pas en charge TLS pour le moment. Les erreurs peuvent-elle provenir de cela selon vous ?

    vendredi 9 juin 2017 10:18
  • Vous pouvez faire un chkdsk sans le /f pour commencez si vous le souhaitez cela ne demande pas de reboot.

    Au niveau des logs, je ne pense pas que cela bloque car le paramètrage par défaut est de négocier donc si le tls n'est pas possible coté serveur, un autre sera utilisé compatible client et serveur.

    Le fait que le serveur se fige pourrait venir de sauvegarde, de driver pas à jour (si vm vérifier la version des VMware Tools / service d'intégration) d'un problème matériel, d'une erreur dans le journal d'évènement, d'une trop forte solicitation du serveur donc il faut vérifier le gestionnaire de périphérique.

    Ce n'est pas parce que vous êtes que 7 que le serveur ne sera pas à 100%

    Le plus probable pour moi si vous avez droit à des freeze c'est ram/processeur à 100%


    Merci de marquer comme réponse les sujets qui vous ont permis d'avancer afin que cela puisse être bénéfique aux personnes qui rencontrent le même problème.

    vendredi 9 juin 2017 11:08
  • Merci pour vos réponses, je vais donc checker le disque.

    Pour le CPU à 100%, il est majoritairement à 90% donc oui c'est très probable qu'il arrive à 100%. Pour autant, je le dis le serveur ne fige pas, j'ai l'impression que c'est uniquement le service RDS qui freeze. Le monitoring a les valeurs de CPU et Ram qui bougent encore, les lecteurs du RDS sont encore accessibles à distance, et il répond encore aux pings.

    vendredi 9 juin 2017 12:27
  • OK, bon on va faire simple alors ^^ 90% en temps "normal" c'est pas normal.

    Le serveur est sousdimensionné ou rencontre un problème. Vos freeze viennent de la...

    Ce n'est pas parce qu'un poste répond à un ping qu'il est en bonne santé...

    Il vous faut commencer par regarder pourquoi il est à 90% et soit mettre à jour le serveur, soit optimiser ce qui prend du CPU et qui ne devrait pas !

    Antivirus, programmes lourds etc... Vérifier les process qui utilisent beaucoup de CPU


    Merci de marquer comme réponse les sujets qui vous ont permis d'avancer afin que cela puisse être bénéfique aux personnes qui rencontrent le même problème.


    vendredi 9 juin 2017 12:52
  • Merci pour vos réponses ^^

    Effectivement on a des process qui consomment énormément de CPU : Internet Explorer et Mozilla, qui peuvent monter l'un ou l'autre à 40% pour un seul utilisateur. Pour les 69 autres utilisateurs, ça fait plus beaucoup 60% de CPU.

    Je ne comprend vraiment pas pourquoi ces navigateurs là consomment autant de CPU.

    Je ne voudrais pas changer de sujet mais j'élimine des pistes au fur et à mesure. Je constate que j'ai reçu 15000 tentatives de connexion en 48h par des personnes malintentionnées sans doute. Il peut y avoir un lien avec les freezes ?

    vendredi 9 juin 2017 15:00
  • En effet, ce n'est pas normal qu'un utilisateur utilise autant de processeur avec une seule instance. Par contre, si jamais les pages d'IE que l'utilisateur ouvre ont du java etc... ca peut aller vite ! donc il faut savoir ce qui est fait sur internet explorer quand meme ! Meme raisonnement pour firefox.

    Mais pour faire simple, un serveur normalement ne dépasse pas les 40% de cpu environs en utilisation normale... Quand il est bien dimensionné. Car lorsqu'on installe des mises à jour par exemple, cela lui demande pas mal de puissance de calcul cpu...

    Sinon, pour les 15 000 tentatives, si elles sont effectuées sur ce même serveur, en effet, cela peut provoquer des freeze. Cela s'appelle une attaque par deni de service ou le but est de faire planter la machine pour faire simple.


    Merci de marquer comme réponse les sujets qui vous ont permis d'avancer afin que cela puisse être bénéfique aux personnes qui rencontrent le même problème.

    vendredi 9 juin 2017 16:53
  • Bonjour Endast,

    Le problème décrit peut être lié à plusieurs choses : saturation de ressource (e.g CPU /RAM), problèmes réseau, conflit /pb de fonctionnement interne liés à des processus spécifique...

    Dans un premier temps, je vous invite à configurer un DataCollector set pour analyser les performances de votre serveur pendant un laps de temps.

    vous pouvez planifier le collecteur de data liées aux perfs à une heure spécifique (ou plusieurs heures), par exemple aux heures ou le problème se produit.

    Analyser les data collectées par la suite pour confirmer ou pas s'il s'agit d'un problème de perfs (saturation de ressource à une heure spécifique par exemple).

    vous parlez de 70 connexions simultanées, on parle ici d'accès Bureau Windows (mode TSE classique) ou l'accès à des RemoteApps publiés sur votre serveur RDSH (Hôte de Session) ?

    La question de sous-dimensionnement peut être résolue en calculant :

    Nombre de connexion X quantité de ressource requise par remote user.

    e.g : 70 remote users consomment 100Mo (par session Bureau à distance) = quantité RAM requise sur le serveur > 700 x 100 = 7000 Mo (~6,8 Go RAM).

    même équation pour le CPU.

    HK.


    Hicham KADIRI | Just Another IT Guy
    Livre de référence RDS 2012 R2 désormais disponible !
    RDS 2012 R2 reference book is now available !
    Découvrez tous mes eBooks )

    dimanche 11 juin 2017 22:09
  • Bonjour à tous,

    Quelques mises à jour d'informations :

    • La piste de la surcharge CPU se réduit, le serveur a freeze alors que nous n'étions que deux sessions. Cela semble assez peu pour un Xeon.
    • Pour le DDOS, j'y ai songé mais le souci c'est que les tentatives sont parfaitement réparties dans le temps (une toutes les 30 secondes). Donc ça n'a pas l'air d'être un pic de connexion qui fait chuter le serveur. Les freezes répétés du serveur peuvent être espacés de deux heures ou deux jours, donc pas de lien avec un dépassement de mémoire/registre/logs à priori.
    • On parle de 70 connexions simultanées en TSE classique.

    Je suppose que le 100Mo était pour le remote App car en moyenne nous tournons tous à 200 Mo minimum avec des pics à 3Go pour certains utilisateurs.

    Je mets en place le data collector set et je reviens vers vous dès que j'ai des nouvelles. Merci encore.

    lundi 12 juin 2017 08:01