Comment [poliment?] Dire aux éditeurs de logiciels qu'ils ne savent pas de quoi ils parlent
Pas une question technique, mais néanmoins valable. Scénario:
HP ProLiant DL380 Gen 8 avec 2 processeurs Xeon E5-2667 à 8 cœurs et 256 Go RAM exécutant ESXi 5.5. Huit VM pour un système de fournisseur donné. Quatre VM pour le test, quatre VM pour la production. Les quatre serveurs de chaque environnement remplissent des fonctions différentes, par exemple: serveur Web, serveur d'application principal, OLAP DB et serveur SQL DB.
Partages de CPU configurés pour empêcher l'environnement de test d'avoir un impact sur la production. Tout le stockage sur SAN.
Nous avons eu quelques questions concernant les performances, et le fournisseur insiste sur le fait que nous devons donner au système de production plus de mémoire et de processeurs virtuels. Cependant, nous pouvons clairement voir de vCenter que les allocations existantes ne sont pas touchées, par exemple: une vue mensuelle de l'utilisation du processeur sur le serveur d'applications principal oscille autour de 8%, avec la pointe impaire jusqu'à 30%. Les pics coïncident généralement avec le lancement du logiciel de sauvegarde.
Histoire similaire sur RAM - le chiffre d'utilisation le plus élevé sur les serveurs est de ~ 35%.
Nous avons donc creusé, en utilisant Process Monitor (Microsoft SysInternals) et Wireshark, et notre recommandation au fournisseur est de faire un réglage TNS en premier lieu. Cependant, c'est d'ailleurs le point.
Ma question est: comment pouvons-nous leur faire reconnaître que les statistiques VMware que nous leur avons envoyées sont une preuve suffisante que plus de RAM/vCPU n'aidera pas?
--- MISE À JOUR 12/07/2014 ---
Semaine intéressante. Notre direction informatique a déclaré que nous devrions modifier les allocations VM, et nous attendons maintenant un certain temps d'indisponibilité de la part des utilisateurs professionnels. Étrangement, les utilisateurs professionnels sont ceux qui disent que certains certains aspects de l'application fonctionnent lentement (par rapport à quoi, je ne sais pas), mais ils vont "nous le faire savoir" quand nous pourrons démonter le système (grogner, grogner!).
Soit dit en passant, l'aspect "lent" du système n'est apparemment pas l'élément HTTP (S), c'est-à-dire: "l'application mince" utilisée par la plupart des utilisateurs. On dirait que ce sont les installations "gros client", utilisées par les principaux organismes financiers, qui sont apparemment "lentes". Cela signifie que nous considérons maintenant l'interaction client-serveur dans nos investigations.
Comme le but initial de la question était de demander de l'aide pour savoir s'il fallait emprunter la voie du "poke it", ou simplement faire le changement, et nous procédons maintenant au changement, je vais le fermer en utilisant long couest la réponse.
Merci à tous pour votre participation; comme d'habitude, serverfault a été plus qu'un simple forum - c'est un peu comme le canapé d'un psychologue :-)
Je vous suggère de faire les ajustements demandés. Ensuite, comparez les performances pour leur montrer que cela n'a fait aucune différence. Vous pouvez même aller aussi loin pour le comparer avec moins de mémoire et vCPU pour faire valoir votre point de vue.
En outre, "Nous vous payons pour soutenir le logiciel avec des solutions réelles, pas de conjectures."
Pourvu que vous soyez sûr que vous respectez les spécifications du système qu'ils documentent.
Ensuite, toute affirmation qu'ils font en ce qui concerne l'exigence de plus RAM ou CPU, ils devraient être en mesure de sauvegarder. En tant qu'experts de leur système, je tiens les gens à rendre compte de cela.
Demandez-leur des détails.
Quelles informations fournies sur le système indiquent plus RAM est nécessaire et comment avez-vous interprété cela?
Quelles informations fournies sur le système indiquent que davantage de CPU est nécessaire et comment avez-vous interprété cela?
Les données dont je dispose - à première vue - contredisent ce que vous me dites. Pouvez-vous m'expliquer pourquoi je peux mal interpréter cela?
J'interprète cette [série de données évidentes] comme signifiant [interprétation évidente]. Pouvez-vous confirmer que je l'interprète correctement par rapport à mon problème?
Ayant traité de soutien dans le passé, j'ai posé les mêmes questions. Parfois j'avais raison et ils ne focalisaient pas correctement leur attention sur mon problème. D'autres fois cependant, j'étais faux et j'interprétais les données de manière incorrecte, ou je n'incluais pas d'autres données qui étaient importantes dans mon analyse.
Dans tous les cas, ces deux situations étaient un avantage net pour moi, soit j'ai appris quelque chose de nouveau que je ne connaissais pas auparavant - soit j'ai demandé à leurs équipes de support de réfléchir plus sérieusement à mon problème pour obtenir un niveau décent cause première.
Si l'équipe de support n'est pas en mesure de vous fournir une extension logique de son argumentation sur une base dont vous pouvez être satisfait (vous devez avoir un esprit ouvert pour vous compromettre, être raisonnable d'accepter que votre interprétation des données est erronée), alors cela devrait devenir très présent dans leur réponse. Même dans le pire des cas, vous pouvez l'utiliser comme base pour aggraver le problème.
Pour cette situation spécifique (où vous avez VMware et des développeurs d'applications ou un tiers qui ne comprend pas l'allocation des ressources), j'utilise l'équivalent d'une semaine de mesures obtenues de vCenter Operations Manager (vCops - téléchargez une démo si nécessaire) pour identifier les contraintes réelles, les goulots d'étranglement et les exigences de dimensionnement des machines virtuelles de l'application.
Parfois, j'ai pu satisfaire les consommateurs les plus tenaces en modifiant VM réservations ou en changeant les priorités pour gérer les scénarios de contention; " Si la RAM | CPU est serrée, [~ # ~] votre [~ # ~] VM aura priorité ! ". Mauvaises choses se sont produits quand j'ai permis aux éditeurs de logiciels de dicter leurs exigences sur mes clusters vSphere sans analyse réelle .
Mais en général, les chiffres et les données devraient l'emporter.
Un exemple de quelque chose que j'ai utilisé pour justifier VM dimensionnement pour le développeur d'une application Tomcat:
Dev : Le VM a besoin du processeur MOAR !
Moi : Eh bien, la mémoire est votre plus grande contrainte, et voici une carte thermique de vos performances en fonction du temps ... Les mercredis à 18 heures sont les périodes les plus stressantes, nous pouvons donc spécifier autour de cette période de pointe. Oh, et voici une recommandation de dimensionnement basée sur les 6 dernières semaines de mesures de production ...
L'important est de pouvoir prouver que vous utilisez les meilleures pratiques pour l'allocation de votre système, notamment RAM et réservations CPU pour votre serveur SQL.
Ceci étant dit, le plus simple est de procéder aux ajustements demandés, au moins temporairement. En tout cas, cela tend à faire traîner les vendeurs. Je ne peux pas compter le nombre de fois où j'ai dû faire quelque chose de fou comme ça pour satisfaire une technologie à l'autre bout de la ligne que c'est vraiment leur logiciel qui ne se comporte pas.
J'avais l'habitude de travailler au support - et une partie de ce que vous demandez semble très rationnelle (et l'est probablement): mais il y a quelques questions à poser vous-même avant de simplement faire "l'amélioration des performances" qu'ils demandent
- exécutez-vous au moins avec la configuration minimale requise indiquée par le fournisseur?
- si vous êtes au moins à sysreqs minimum, êtes-vous déjà à leurs paramètres système "recommandés"?
Les fournisseurs 99 fois sur 100 (d'après mon expérience - tant du côté du support que du côté client/terrain) ne traiteront même pas les problèmes liés aux performances jusqu'à ce que/à moins que les systèmes correspondent à ce que leur documentation demande. Peut-être que c'est un système qui fonctionne très bien 99,5% du temps avec 1 CPU et 512M RAM - mais si la configuration système requise dit 4 CPU et 4G RAM et vous 'ai seulement 2 CPU et 1G de RAM, ils sont bien dans leurs droits d'exiger que plus de ressources soient affectées*.
Il est probable qu'ils vous demandent d'augmenter les ressources système à cause de quelque chose qu'ils ont trouvé dans le laboratoire/développement où un problème disparaît comme par magie si vous franchissez un seuil spécifique; si c'est le cas, oui c'est un exemple de débogage potentiellement pauvre de leur côté, mais gardez à l'esprit qu'ils n'ont pas le temps d'éliminer tous les bogue/problème possible qui survient - certains ont juste besoin d'être contournés, et si c'est le cas ici, allez-y.
Il y a aussi une chance non négligeable que les problèmes que vous voyez ne fassent même pas partie de "leur" logiciel, mais d'un composant sur lequel ils s'appuient d'une autre source (fournisseur, bibliothèque OSS, etc.). J'ai rencontré cette situation exacte liée à la taille du swap, BEA WebLogic et le Sun JRE chez un client il y a quelques années.
tl; dr:
En bref, travaillez avec leur équipe de support, en escaladant au besoin, jusqu'à ce que vous trouviez une résolution - mais ne soyez pas surpris lorsque certaines des suggestions/étapes de débogage/correctifs sonnent de manière décalée ou inutile.
*Si elle vraiment n'a pas "besoin" de ces ressources supplémentaires, vous êtes probablement en mesure de déposer un bug de document/RFE pour l'avenir versions - mais ne pas pousser cette route jusqu'à ce que vous avez démontré que ce n'est pas le problème à portée de main
^un livre électronique que j'ai écrit peut vous être utile sur le sujet: Débogage et prise en charge des systèmes logiciels
Soit demander d'augmenter le ticket ou demander un représentant différent. Selon le fournisseur dont il s'agit, l'escalade peut être utile si vous dites que vous estimez que le niveau de support actuel ne résout pas correctement le problème. S'ils n'escaladent pas, demander un représentant différent peut être utile, car cela nécessite beaucoup moins de "justification", car il suffit de ne pas être satisfait de l'actuel.
Si c'est un grand fournisseur, il suffit de fermer le ticket et d'en ouvrir un nouveau sur le même problème, car il peut être acheminé vers un autre représentant, mais je le déconseille car il est de mauvaise forme.
Vous pouvez également défendre votre position et demander une justification de la façon dont plus de RAM/vCPU vous aidera, ou vous pouvez simplement lui donner plus de RAM/vCPU pour prouver que cela n'aidera pas.
Je jette mes deux cents. Nous avons assez bien réussi avec cette approche - de bien meilleurs résultats et moins de frustration de la part de tous. Cela nécessite beaucoup plus d'efforts que le jeu du blâme et l'ajout aveugle de ressources, mais il a également de meilleures chances de trouver le problème sous-jacent.
Lorsque nous rencontrons de graves problèmes avec nos applications sur site qui sont soutenues par des contrats de support des fournisseurs, et que les fournisseurs commencent leur danse aléatoire (qui semble toujours inclure des demandes extra-basées non basées sur les données pour plus de CPU ou de RAM), nous avons tendance à faites ces 3 choses:
Faites passer la priorité à l'équivalent du système vers le bas - ils rechignent généralement, mais généralement vers le bas lorsque vous expliquez qu'il est effectivement inutilisable même s'il est techniquement "fonctionnel". Traitez-le comme un problème grave à résoudre. Ici, nous appelons cela une équipe de tigres, qui se réunit quotidiennement pour obtenir des mises à jour de statut de toutes les parties prenantes. Habituellement, le vendeur vous demandera de changer des choses. Si c'est un système de prod, c'est problématique, mais si vous voulez qu'ils aident, vous devrez accepter la responsabilité de les aider à isoler le problème, donc cela aide si vous avez un environnement de développement/de mise en scène où vous pouvez exécuter des tests.
Dites au fournisseur que vous souhaitez qu'il réplique votre environnement, afin qu'ils puissent isoler le problème dans leur laboratoire. Ils peuvent même héberger des éléments dans un environnement cloud si nécessaire. Il ne doit pas nécessairement correspondre exactement à votre environnement, bien que ce soit idéal. Le fait est que vous voulez que le VENDEUR essaie activement de reproduire votre problème, afin qu'il puisse tester ses conjectures sur son système au lieu du vôtre. Demandez-leur les diagrammes, les spécifications, etc. de cet environnement répliqué pour vous assurer qu'ils le font.
Fournissez-leur (sous NDA bien sûr) avec votre ensemble de données réel afin qu'ils puissent l'exécuter/rejouer pour de vrai au lieu de deviner. Dans notre cas, la plupart de nos problèmes d'application fournis par le fournisseur (tous deux transitoires) et chronique) se révèlent souvent être des problèmes avec les bases de données fournies par le fournisseur. Je ne peux pas compter le nombre de fois que nous avons fait cela et ils ont finalement identifié le problème jusqu'à quelque chose d'inattendu dans les données réelles - des artefacts étranges de l'application mises à jour il y a 2 ans où quelque chose ne s'est pas converti proprement; enregistrements obsolètes exposant un problème avec les paramètres du GC; les requêtes ne fonctionnent pas tout à fait parce que NOS valeurs de données cassent une routine de transmogrification dans le code du fournisseur, etc. Des choses que nous ne serions jamais en mesure d'identifier par nos propres moyens.
Nous l'avons fait avec un certain nombre de fournisseurs au cours des dernières années, et ils sont initialement très réticents à le faire à notre façon. Cependant, une fois que cela a fonctionné, cela apparaît toujours comme un point positif dans les examens trimestriels que nous organisons avec nos fournisseurs. Et cela contribue à cimenter notre relation technique avec ces fournisseurs. Ils ne veulent pas de problèmes vagues. Ils veulent des problèmes spécifiques qu'ils peuvent analyser pour améliorer leurs produits.
J'espère que la suggestion vous aidera. Je sais que ce n'est pas une approche unique, mais si vous pouvez la balancer, je pense que vous la trouverez utile.
La vraie question est de savoir qui est responsable ici? Si vous ne pouvez pas passer de manière réaliste à un autre fournisseur, alors ils ont le pouvoir, et tout ce que vous pouvez vraiment faire est d'accepter tout ce qu'ils disent et d'espérer que cela fonctionnera. Pas une situation heureuse! Sinon, je vous suggère de demander un autre représentant (comme d'autres l'ont dit), mais précisez que vous n'êtes pas satisfait du service et que vous chercherez ailleurs s'ils ne peuvent pas faire le travail.
Ne vous contentez pas de "faire les ajustements qu'ils ont suggérés" si vous êtes sûr qu'ils ne fonctionneront pas, car cela établit un modèle pour votre relation qui vous nuira à long terme. Vous les payez pour vous fournir un service, et ils ne devraient pas pouvoir dicter vos actions plus que quelqu'un que j'engage pour peindre ma maison ne peut dicter de quelle couleur il sera.
Cela peut sembler drastique, car il semble que ce ne soit pas un problème extrêmement critique, mais le fait est que s'ils vous dérangent sur quelque chose de mineur, ils feront probablement la même chose pour quelque chose de grand, et la dernière chose que vous voulez est de rencontrer une sorte d'horrible charlie foxtrot six mois plus tard et avoir alors le même problème avec le vendeur.
Assurez-vous que toutes les mesures que vous prendrez pour résoudre le problème maintenant fonctionneront aussi bien lorsque vous êtes à deux jours d'une date limite et que tout se casse ...
Je vais publier une vue du côté du vendeur.
Nous avions ce client qui avait ce problème récurrent où les performances du logiciel chutaient toutes les quelques heures environ à un rythme vraiment abyssal puis revenaient quelques heures plus tard.
Le profileur de bulitine dans le système a indiqué que la vitesse du processeur (ou éventuellement de la mémoire) du système était dégoûtante et lente, quelque chose comme 100 MHz au lieu des 2 GHz attendus. Doubler le CPU fourni par le VM n'a pas changé le symptôme et ils pensaient que nous gaspillions.
Comme ils ne pouvaient pas obtenir un processeur plus rapide (plus de processeurs n'allaient pas aider), nous avons ensuite essayé de permuter les machines virtuelles TEST et PROD. Le problème est ensuite apparu sur TEST le lendemain. Ensuite, nous avons essayé de promouvoir l'un des clients en une instance autonome (sans serveur). Aucun problème sur ce poste de travail pendant que le serveur s'étouffait.
Ils ont produit des rapports de l'hôte VM n'indiquant aucun problème de performances et ont à nouveau tenté de prétendre qu'il s'agissait d'un problème d'application.
Enfin, j'ai [un ingénieur] (je n'avais aucun support de ceux qui occupaient des postes de support dédiés) demandé spécifiquement une boîte physique. Le client a crié un meurtre sanglant mais sans que personne n'ait d'autre solution potentielle, il l'a fait. Que savez-vous, le problème a disparu comme par magie.
Nous n'avons jamais découvert quel était le problème. Tous les programmes de référence se sont révélés normaux, mais le profileur d'application nous a dit que les ressources informatiques n'étaient tout simplement pas adéquates. Il y a une sorte de signature spécifique que nous recherchons dans le profileur maintenant. Si nous le voyons, nous savons qu'avant d'aller plus loin, le problème est l'interaction VM, mais ce n'était tout simplement pas connu à l'époque.
Ils pensaient vraiment que j'en étais plein. Je ne l'étais pas. J'étais hors des options.
EDIT, mise à jour des années plus tard:
Avec de plus en plus de clients souhaitant s'exécuter sur des machines virtuelles et la direction désireuse de tenter de résoudre le problème à tout prix, nous avons obtenu un bon matériel VM. J'ai pu construire un programme de gravure VM spécialisé qui s'exécutait dans l'espace utilisateur (et ne nécessitait aucun privilège) sur deux machines virtuelles à cœur unique avec 512 Mo de RAM, qui était en mesure de drainer les performances de mémoire de 1/3 d'un autre single -core VM avec seulement 4 cœurs au total sur 16 en cours d'utilisation sur l'hôte VM et la plupart de son ram encore libre. Le programme n'a déclenché aucune alarme et n'a montré rien d'extraordinaire sur l'hôte VM ni sur aucun des invités, sauf que l'accès à la mémoire était lent.
Maintenant, nous pouvons dire aux clients que nous savons qu'il y a un problème avec les machines virtuelles, et ce n'est pas notre logiciel. Nous recevons toujours de temps à autre des demandes de clients concernant des logiciels compatibles avec VM. Je me demande pourquoi la direction ne laisse pas le support leur dire que nous avons pu développer un logiciel qui ralentit tous les autres VM sur le même hôte.
Ce qui est effrayant, c'est que la technique impliquée est une simple transformation d'une technique de programmation bien connue impliquant une synchronisation sans verrouillage. Des centaines de fournisseurs de logiciels pourraient avoir ce VM égouttoir dans leur logiciel et ne pas le savoir. L'obtention d'un verrou d'instruction atomique vivement contesté devrait être rare mais pas impossible. La partie amusante de tout cela est que j'obtenais le verrou pour contester les VM ACROSS.