Discussion :

[jff42]

Bonjour,
Quels sont les avantages/inconvénients d'avoir

• un pool d'application IIS unique pour toutes les applications SHP,
• un pool distinct par appli web
• un mix des deux solutions ?

J'avais comme première idée qu'en cloisonnant (chacun la sienne) on fiabilise et on donne de la souplesse, mais j'ai l'impression que c'est vorace en mémoire (plusieurs applis avec plusieurs pools mettent une machine à genou).

Quelles sont les bonnes pratiques ?
Merci

[nonoxp]

Salut,

Pour avoir testé les deux extrêmes, je pense qu'un mix s'impose, avec une petite tendance vers le regroupement d'applis sharepoint dans quelques pools d'appli.

Le critère principal (pour moi) pour sortir une appli dans un pool séparé est la sécurité/fiabilité. Dans un contexte de fourniture de service à un client, c'est une solution pour éviter les effets de bords des autres applis web. Bien sûr que cette méthode a un coût en termes de mémoire, de gestion, et de complexité (jobs/listeners) rajoutés par sharepoint. A titre d'exemple : on commence à manquer de souffle vers 12-14 pools et avoir des soucis réels vers 17-20 pools sur un serveur standalone 4core / 4Go de RAM.

Ca dépend vraiment du contexte de mutualisation de ta ressource serveur et du type d'accès que tu souhaites pour les applis. Ex.: Un site de type intra/extranet et un site de type public n'ont pas vocation à subir la même charge et les mêmes attaques, donc intéressant à cloisonner.

[jff42]

Merci, ça confirme mes recherches.

Pour les autres : j'aurais aimé des retours de plusieurs personnes pour comparer, et tirer des "bonnes pratiques" ... Donc je simplifie la question :

Quand Sharepoint vous demande "créer un nouveau pool / utiliser un pool existant", que répondez-vous ?

[kazoumoulox]

De manière générale, dans les bonnes pratiques :
- 1 Web Application == 1 pool d'application afin d'isoler les accès (charge serveur) et également isoler les cas d'erreur (si une erreur sur une WebApp, les autres peuvent continuer à fonctionner)
- 1 Service d'application == 1 pool d'application ici aussi pour sécuriser l'exécution et éviter la surconsommation de mémoire lors de l'utilisation en parallèle de ces services par les utilisateurs. La sécurité est également importante... les pools d'application fonctionnent grâce à des comptes de domaine avec des droits particuliers (SQL, fichiers du serveur, IIS).

Ne pas oublier également que dans le cas de la production, le load balancing est possible sur les WebApp et les services... et diminue donc l'utilisation proc/mémoire et donc améliore les temps d'accès dans la globalité.

J'espère avoir été clair (et ne pas oublier que je prend pour cible les fermes de production... pour du dev, on peut mutualiser)

[Bluedeep]

De manière générale, dans les bonnes pratiques :
- 1 Web Application == 1 pool d'application afin d'isoler les accès (charge serveur) et également isoler les cas d'erreur (si une erreur sur une WebApp, les autres peuvent continuer à fonctionner)

Je ne comprens pas en quoi le pool change l'isolation en cas d'erreur.

Qu'on utilise un pool pour plusieurs appli ou un pool par appli, dans tous les cas, dans IIS, chaque application ASP.NET a son propre AppDomain, ce qui assure normalement l'isolation en cas d'erreur (en revanche ce n'est pas le cas pour une application ASP, mais ça devient rare).

[jff42]

Et moi je ne comprends pas pourquoi avoir 2 pools au lieu d'un augmente les performances : ça doit prendre 2 fois plus de mémoire, non ?
(la question est peut-être bête, désolé)

[BenjGe]

on peut se servir des pools d'applications iis pour définir des affinités processeur par exemple.
d'où l'intérêt de faire des regroupements d'appli web ou d'appli de service sharepoint

sur certains serveurs multi services comme small business server, il est souvent nécessaire de gérer la performance à la main par des limites d'allocation de ram ou des affinités processeur , en effectuant une sorte de partition de ressources entre services identifiés comme gourmand

De plus l'isolation d'application sharepoint dans les pools d'appli permet de les recycler indépendamment. Par exemple pour cette raison je laisserai toujours le site de l'administration centrale sur un pool d'appli indépendant, car un recyclage engendrera une coupure de service pour l'ensemble des applis hébergées

Pour conclure je dirai que ces choix d'affectation entre les appli sharepoint et les pools d'applis IIS sont entre autres guidées par les contraintes de l'administration du système au quotidien.

[Lapinpanda]

Je ne comprens pas en quoi le pool change l'isolation en cas d'erreur.

Qu'on utilise un pool pour plusieurs appli ou un pool par appli, dans tous les cas, dans IIS, chaque application ASP.NET a son propre AppDomain, ce qui assure normalement l'isolation en cas d'erreur (en revanche ce n'est pas le cas pour une application ASP, mais ça devient rare).

Bonjour,

Il y a bien une isolation. Premier exemple bête qui me vient à l'esprit, imaginez que le compte de service associé au Pool de votre application n'a plus accès / et désactiver / mot de passe expiré, seul une des WebApplication sera Off.

[ludojojo]

Pour compléter les propos ci-dessus, je dirais qu'un apppool par application sensible est nécessaire, pour des raisons de sécurités mais aussi et surtout de stabilité !
En effet, si une application plante assez pour faire tomber un apppool (oui ça arrive...) alors tous tes sites liés sont innacessible ! Ce qui peut avoir un impacte très fort sur une ferme de production.
En plus, la surcharge d'un application pool peut engendrer des problèmes de performance...

Et pour finir, redémarrer un apppool de prod en journée peut être impactant mais nécessaire par fois, le faire un sur un apppool "mutualisé" peut s'avérer beaucoup plus compliqué...