Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

[MOSS 2007] - Webapps et collections de sites.

3 réponses
Avatar
Houdini
Bonjour à toutes et à tous,

Une question idiote:

Vaut-il mieux:
a) - une webApp pour x collections de sites ou
b) - 1 webApp par collection de sites ?

Solution A: (admettons). Tout est accessible à partir du port 80,
administration simplifiée (1 webApp), une seule base de données .... Si la
WebApp est "out", il n'y a plus de collection de sites disponibles.

Solution B: (admettons): 1 webapp avec un port précis, 1 collection de
sites, 1 base/collection. Si une WebApp est "out", seule la collection
concernée ne sera pas dispo, les autres continueront à fonctionner. Est-ce
plus sécuritaire ? Plus gourmand ? En cas de retour arrière ou de
maintenance, est-ce plus pratique ?

Merci de votre avis.
Cordialement,
Houdini.

3 réponses

Avatar
Etienne Legendre
Bonjour

La solution B semble mieux mais attention que certains points tel que les
content types sont dans un collection de sites.

EtienneL

"Houdini" a écrit dans le message de
news:
Bonjour à toutes et à tous,

Une question idiote:

Vaut-il mieux:
a) - une webApp pour x collections de sites ou
b) - 1 webApp par collection de sites ?

Solution A: (admettons). Tout est accessible à partir du port 80,
administration simplifiée (1 webApp), une seule base de données .... Si la
WebApp est "out", il n'y a plus de collection de sites disponibles.

Solution B: (admettons): 1 webapp avec un port précis, 1 collection de
sites, 1 base/collection. Si une WebApp est "out", seule la collection
concernée ne sera pas dispo, les autres continueront à fonctionner. Est-ce
plus sécuritaire ? Plus gourmand ? En cas de retour arrière ou de
maintenance, est-ce plus pratique ?

Merci de votre avis.
Cordialement,
Houdini.


Avatar
e.issaly
On Feb 4, 4:02 pm, Houdini wrote:
Bonjour à toutes et à tous,

Une question idiote:

Vaut-il mieux:
a) - une webApp pour x collections de sites ou
b) - 1 webApp par collection de sites ?

Solution A: (admettons). Tout est accessible à partir du port 80,
administration simplifiée (1 webApp), une seule base de données .... Si la
WebApp est "out", il n'y a plus de collection de sites disponibles.

Solution B: (admettons): 1 webapp avec un port précis, 1 collection de
sites, 1 base/collection. Si une WebApp est "out", seule la collection
concernée ne sera pas dispo, les autres continueront à fonctionner. E st-ce
plus sécuritaire ? Plus gourmand ? En cas de retour arrière ou de
maintenance, est-ce plus pratique ?

Merci de votre avis.
Cordialement,
Houdini.



La solution 2 (une base sql par collection) est plus performante et
plus sure si tu utilise un restore SQL, par contre c'est un peu ch*ant
à administrer :D
Si tu penses que une collection va devenir >= 100Go, faut séparer sans
hésiter à mon avis.

Rien que pour le temps de restaurer la bande.... :)

pour créer une sitecol dans une BD précise il vaut mieux utiliser
stsadm, mais on peut aussi passer par l'interface d'admin en mettant
"0" et "1" en limites de sites.
sinon, créer toutes les BD et les mettre offline, puis online une par
une doit marcher :)
Avatar
Lognoul Marc [MVP]
Bonsoir

a) - une webApp pour x collections de sites ou
b) - 1 webApp par collection de sites ?

Solution A: (admettons). Tout est accessible à partir du port 80,
administration simplifiée (1 webApp), une seule base de données .... Si la
WebApp est "out", il n'y a plus de collection de sites disponibles.


En terme IIS/SharePoint, il faudra d'abord définir ce que "out" veut dire ;)

Règle générale: "keep it simple": une web app, 1 app pool, un nombre minimum
de managed paths et qq centaines (voire milliers) de site collections
fonctionneront sans problèmes et contenteront 90% des utilisateurs
SharePoint tout en gardant la configuration et la maintenance aisées

Solution B: (admettons): 1 webapp avec un port précis, 1 collection de
sites, 1 base/collection. Si une WebApp est "out", seule la collection
concernée ne sera pas dispo, les autres continueront à fonctionner. Est-ce
plus sécuritaire ? Plus gourmand ? En cas de retour arrière ou de
maintenance, est-ce plus pratique ?


Pour que cela aie du sens en terme de sécurité, il faudrait faire tourner
chaque web application sous un application pool différent qui lui-même
possède une identité dédiée qui ne soit pas administrateur du système...
Chaque Web app et chaque content database entraine une charge supplémentaire
car elles impliquent un certain nombre de "timer jobs" qui leur sont liés ->
plus on ajoute de content database, de web application et surtout
d'application pools, plus on accroit "l'overhead" (mémoire + handles en
particulier). La combinaison idéale de ceux-ci devrait se baser sur les
tests de charge et sur le test des procédures opérationnelles,
backup/restore, optimisation....

--
Marc [MCSE, MCTS, MVP]
[Heureux celui qui a pu pénétrer les causes secrètes des choses]
[Blog: http://www.marc-antho-etc.net/blog/]