Nous sommes en train de revoir notre architecture et nous étudions plusieurs
pistes.
Notre fournisseur de matériel nous propose un gros serveur quadri-pro pour
faire tournée notre appli. Nous sommes totalement maitre de celle-ci car c'est
nous qui l'avons développé, ce qui veux dire que nous pouvons l'adapter à
différent type d'infrastructures.
J'en viens à ma question :
Est il préférable d'avoir un serveur quadri-pro ou deux serveurs bi-pro ? Le
choix se fera en fonction du rapport performance/prix.
Le traitement effectué par les serveurs sont de séquentiels et seront selon
l'architecture choisie multithreads sur une appli ou multithread sur deux
applis tournants sur 2 serveurs :
Première solution : traitement de 4 données sur un serveur
1 serveur quadri-processeurs :
- Application avec quatre threads traitant chacun une donnée
Deuxième solution : traitement de 2 données par serveur sur 2 serveurs
2 serveurs biprocesseurs :
- Deux applications avec deux threads traitant chacun une donnée
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Jacques Barathon [MS]
"Fred" wrote in message news: <snip>
Est il préférable d'avoir un serveur quadri-pro ou deux serveurs bi-pro ? Le choix se fera en fonction du rapport performance/prix.
Le traitement effectué par les serveurs sont de séquentiels et seront selon l'architecture choisie multithreads sur une appli ou multithread sur deux applis tournants sur 2 serveurs :
Première solution : traitement de 4 données sur un serveur
1 serveur quadri-processeurs :
- Application avec quatre threads traitant chacun une donnée
Deuxième solution : traitement de 2 données par serveur sur 2 serveurs
2 serveurs biprocesseurs :
- Deux applications avec deux threads traitant chacun une donnée
Difficile d'apporter une réponse franche. J'essaierai plutôt de donner quelques conseils quant à la meilleure façon de répondre par vous-même.
La 1ere solution a l'avantage de la simplicité, ce qui n'est pas négligeable.
Dans le 2e cas il faudra mettre en place un partage des données, à priori dans une architecture de type cluster/SAN. Cela aura un impact significatif sur le coût de la solution, à l'achat et à la maintenance.
Dans cette solution il faudra également prévoir une synchronisation entre les deux applis, soit un coût supplémentaire potentiel dans les performances. A évaluer en fonction de la technique de synchronisation utilisée.
Pour vraiment évaluer les avantages de la 2e solution en termes de performance, il faudrait évaluer l'impact de l'application sur les principaux sous-ensembles du serveur, notamment la CPU, la mémoire, les disques durs et l'interface réseau. Cette évaluation peut se faire au cours d'un pilote sur un matériel le plus proche possible du ou des matériels choisis au final. Vous pouvez par exemple vous faire prêter par votre fournisseur un serveur bi-pro le temps de faire vos tests. Si ce n'est pas possible, vous pouvez faire vos tests sur une machine plus classique et extrapoler à partir des résultats obtenus, mais la marge d'erreur sera plus grande.
Si l'un de ces sous-ensembles court le risque d'être saturé dans l'utilisation de l'application et qu'un accroissement de capacité de ce sous-ensemble n'est pas envisageable ou ne suffira pas, il peut y avoir un avantage significatif à partager l'application sur deux serveurs. Si le risque de saturation est faible voire nul, ou s'il existe mais n'est pas considéré comme impactant pour l'usage prévu, vous pouvez opter pour la solution d'avoir un seul serveur.
Pour finir, un avantage à prendre en compte dans la solution à deux serveurs est la tolérance de panne: dans une architecture cluster où les deux serveurs sont actifs et où l'application est "cluster-aware", quand tout se passe bien le travail est réparti entre les deux serveurs (répartition déterminée par l'application selon ses propres critères) et en cas de problème sur un serveur les traitements peuvent être repris sur l'autre serveur le temps de le remettre en service. Pour que tout cela fonctionne aussi idéalement que décrit, il faut que l'application sache fonctionner en cluster (qu'elle soit "cluster-aware" comme je disais plus haut). Il doit exister des livres blancs à ce sujet, il faudrait fouiller notamment sur le site de Microsoft.
Jacques
"Fred" <Fred@ifrance.com> wrote in message
news:O5nHU70RGHA.5908@TK2MSFTNGP14.phx.gbl...
<snip>
Est il préférable d'avoir un serveur quadri-pro ou deux serveurs bi-pro ?
Le choix se fera en fonction du rapport performance/prix.
Le traitement effectué par les serveurs sont de séquentiels et seront
selon l'architecture choisie multithreads sur une appli ou multithread sur
deux applis tournants sur 2 serveurs :
Première solution : traitement de 4 données sur un serveur
1 serveur quadri-processeurs :
- Application avec quatre threads traitant chacun une donnée
Deuxième solution : traitement de 2 données par serveur sur 2 serveurs
2 serveurs biprocesseurs :
- Deux applications avec deux threads traitant chacun une
donnée
Difficile d'apporter une réponse franche. J'essaierai plutôt de donner
quelques conseils quant à la meilleure façon de répondre par vous-même.
La 1ere solution a l'avantage de la simplicité, ce qui n'est pas
négligeable.
Dans le 2e cas il faudra mettre en place un partage des données, à priori
dans une architecture de type cluster/SAN. Cela aura un impact significatif
sur le coût de la solution, à l'achat et à la maintenance.
Dans cette solution il faudra également prévoir une synchronisation entre
les deux applis, soit un coût supplémentaire potentiel dans les
performances. A évaluer en fonction de la technique de synchronisation
utilisée.
Pour vraiment évaluer les avantages de la 2e solution en termes de
performance, il faudrait évaluer l'impact de l'application sur les
principaux sous-ensembles du serveur, notamment la CPU, la mémoire, les
disques durs et l'interface réseau. Cette évaluation peut se faire au cours
d'un pilote sur un matériel le plus proche possible du ou des matériels
choisis au final. Vous pouvez par exemple vous faire prêter par votre
fournisseur un serveur bi-pro le temps de faire vos tests. Si ce n'est pas
possible, vous pouvez faire vos tests sur une machine plus classique et
extrapoler à partir des résultats obtenus, mais la marge d'erreur sera plus
grande.
Si l'un de ces sous-ensembles court le risque d'être saturé dans
l'utilisation de l'application et qu'un accroissement de capacité de ce
sous-ensemble n'est pas envisageable ou ne suffira pas, il peut y avoir un
avantage significatif à partager l'application sur deux serveurs. Si le
risque de saturation est faible voire nul, ou s'il existe mais n'est pas
considéré comme impactant pour l'usage prévu, vous pouvez opter pour la
solution d'avoir un seul serveur.
Pour finir, un avantage à prendre en compte dans la solution à deux serveurs
est la tolérance de panne: dans une architecture cluster où les deux
serveurs sont actifs et où l'application est "cluster-aware", quand tout se
passe bien le travail est réparti entre les deux serveurs (répartition
déterminée par l'application selon ses propres critères) et en cas de
problème sur un serveur les traitements peuvent être repris sur l'autre
serveur le temps de le remettre en service. Pour que tout cela fonctionne
aussi idéalement que décrit, il faut que l'application sache fonctionner en
cluster (qu'elle soit "cluster-aware" comme je disais plus haut). Il doit
exister des livres blancs à ce sujet, il faudrait fouiller notamment sur le
site de Microsoft.
Est il préférable d'avoir un serveur quadri-pro ou deux serveurs bi-pro ? Le choix se fera en fonction du rapport performance/prix.
Le traitement effectué par les serveurs sont de séquentiels et seront selon l'architecture choisie multithreads sur une appli ou multithread sur deux applis tournants sur 2 serveurs :
Première solution : traitement de 4 données sur un serveur
1 serveur quadri-processeurs :
- Application avec quatre threads traitant chacun une donnée
Deuxième solution : traitement de 2 données par serveur sur 2 serveurs
2 serveurs biprocesseurs :
- Deux applications avec deux threads traitant chacun une donnée
Difficile d'apporter une réponse franche. J'essaierai plutôt de donner quelques conseils quant à la meilleure façon de répondre par vous-même.
La 1ere solution a l'avantage de la simplicité, ce qui n'est pas négligeable.
Dans le 2e cas il faudra mettre en place un partage des données, à priori dans une architecture de type cluster/SAN. Cela aura un impact significatif sur le coût de la solution, à l'achat et à la maintenance.
Dans cette solution il faudra également prévoir une synchronisation entre les deux applis, soit un coût supplémentaire potentiel dans les performances. A évaluer en fonction de la technique de synchronisation utilisée.
Pour vraiment évaluer les avantages de la 2e solution en termes de performance, il faudrait évaluer l'impact de l'application sur les principaux sous-ensembles du serveur, notamment la CPU, la mémoire, les disques durs et l'interface réseau. Cette évaluation peut se faire au cours d'un pilote sur un matériel le plus proche possible du ou des matériels choisis au final. Vous pouvez par exemple vous faire prêter par votre fournisseur un serveur bi-pro le temps de faire vos tests. Si ce n'est pas possible, vous pouvez faire vos tests sur une machine plus classique et extrapoler à partir des résultats obtenus, mais la marge d'erreur sera plus grande.
Si l'un de ces sous-ensembles court le risque d'être saturé dans l'utilisation de l'application et qu'un accroissement de capacité de ce sous-ensemble n'est pas envisageable ou ne suffira pas, il peut y avoir un avantage significatif à partager l'application sur deux serveurs. Si le risque de saturation est faible voire nul, ou s'il existe mais n'est pas considéré comme impactant pour l'usage prévu, vous pouvez opter pour la solution d'avoir un seul serveur.
Pour finir, un avantage à prendre en compte dans la solution à deux serveurs est la tolérance de panne: dans une architecture cluster où les deux serveurs sont actifs et où l'application est "cluster-aware", quand tout se passe bien le travail est réparti entre les deux serveurs (répartition déterminée par l'application selon ses propres critères) et en cas de problème sur un serveur les traitements peuvent être repris sur l'autre serveur le temps de le remettre en service. Pour que tout cela fonctionne aussi idéalement que décrit, il faut que l'application sache fonctionner en cluster (qu'elle soit "cluster-aware" comme je disais plus haut). Il doit exister des livres blancs à ce sujet, il faudrait fouiller notamment sur le site de Microsoft.
Jacques
Fred
Merci pour votre réponse très complète !
"Jacques Barathon [MS]" a écrit dans le message de news:
"Fred" wrote in message news: <snip>
Est il préférable d'avoir un serveur quadri-pro ou deux serveurs bi-pro ? Le choix se fera en fonction du rapport performance/prix.
Le traitement effectué par les serveurs sont de séquentiels et seront selon l'architecture choisie multithreads sur une appli ou multithread sur deux applis tournants sur 2 serveurs :
Première solution : traitement de 4 données sur un serveur
1 serveur quadri-processeurs :
- Application avec quatre threads traitant chacun une donnée
Deuxième solution : traitement de 2 données par serveur sur 2 serveurs
2 serveurs biprocesseurs :
- Deux applications avec deux threads traitant chacun une donnée
Difficile d'apporter une réponse franche. J'essaierai plutôt de donner quelques conseils quant à la meilleure façon de répondre par vous-même.
La 1ere solution a l'avantage de la simplicité, ce qui n'est pas négligeable.
Dans le 2e cas il faudra mettre en place un partage des données, à priori dans une architecture de type cluster/SAN. Cela aura un impact significatif sur le coût de la solution, à l'achat et à la maintenance.
Dans cette solution il faudra également prévoir une synchronisation entre les deux applis, soit un coût supplémentaire potentiel dans les performances. A évaluer en fonction de la technique de synchronisation utilisée.
Pour vraiment évaluer les avantages de la 2e solution en termes de performance, il faudrait évaluer l'impact de l'application sur les principaux sous-ensembles du serveur, notamment la CPU, la mémoire, les disques durs et l'interface réseau. Cette évaluation peut se faire au cours d'un pilote sur un matériel le plus proche possible du ou des matériels choisis au final. Vous pouvez par exemple vous faire prêter par votre fournisseur un serveur bi-pro le temps de faire vos tests. Si ce n'est pas possible, vous pouvez faire vos tests sur une machine plus classique et extrapoler à partir des résultats obtenus, mais la marge d'erreur sera plus grande.
Si l'un de ces sous-ensembles court le risque d'être saturé dans l'utilisation de l'application et qu'un accroissement de capacité de ce sous-ensemble n'est pas envisageable ou ne suffira pas, il peut y avoir un avantage significatif à partager l'application sur deux serveurs. Si le risque de saturation est faible voire nul, ou s'il existe mais n'est pas considéré comme impactant pour l'usage prévu, vous pouvez opter pour la solution d'avoir un seul serveur.
Pour finir, un avantage à prendre en compte dans la solution à deux serveurs est la tolérance de panne: dans une architecture cluster où les deux serveurs sont actifs et où l'application est "cluster-aware", quand tout se passe bien le travail est réparti entre les deux serveurs (répartition déterminée par l'application selon ses propres critères) et en cas de problème sur un serveur les traitements peuvent être repris sur l'autre serveur le temps de le remettre en service. Pour que tout cela fonctionne aussi idéalement que décrit, il faut que l'application sache fonctionner en cluster (qu'elle soit "cluster-aware" comme je disais plus haut). Il doit exister des livres blancs à ce sujet, il faudrait fouiller notamment sur le site de Microsoft.
Jacques
Merci pour votre réponse très complète !
"Jacques Barathon [MS]" <jbaratho@online.microsoft.com> a écrit dans le
message de news: uNagdg1RGHA.4976@TK2MSFTNGP11.phx.gbl...
"Fred" <Fred@ifrance.com> wrote in message
news:O5nHU70RGHA.5908@TK2MSFTNGP14.phx.gbl...
<snip>
Est il préférable d'avoir un serveur quadri-pro ou deux serveurs bi-pro ?
Le choix se fera en fonction du rapport performance/prix.
Le traitement effectué par les serveurs sont de séquentiels et seront
selon l'architecture choisie multithreads sur une appli ou multithread
sur deux applis tournants sur 2 serveurs :
Première solution : traitement de 4 données sur un serveur
1 serveur quadri-processeurs :
- Application avec quatre threads traitant chacun une donnée
Deuxième solution : traitement de 2 données par serveur sur 2 serveurs
2 serveurs biprocesseurs :
- Deux applications avec deux threads traitant chacun une
donnée
Difficile d'apporter une réponse franche. J'essaierai plutôt de donner
quelques conseils quant à la meilleure façon de répondre par vous-même.
La 1ere solution a l'avantage de la simplicité, ce qui n'est pas
négligeable.
Dans le 2e cas il faudra mettre en place un partage des données, à priori
dans une architecture de type cluster/SAN. Cela aura un impact
significatif sur le coût de la solution, à l'achat et à la maintenance.
Dans cette solution il faudra également prévoir une synchronisation entre
les deux applis, soit un coût supplémentaire potentiel dans les
performances. A évaluer en fonction de la technique de synchronisation
utilisée.
Pour vraiment évaluer les avantages de la 2e solution en termes de
performance, il faudrait évaluer l'impact de l'application sur les
principaux sous-ensembles du serveur, notamment la CPU, la mémoire, les
disques durs et l'interface réseau. Cette évaluation peut se faire au
cours d'un pilote sur un matériel le plus proche possible du ou des
matériels choisis au final. Vous pouvez par exemple vous faire prêter par
votre fournisseur un serveur bi-pro le temps de faire vos tests. Si ce
n'est pas possible, vous pouvez faire vos tests sur une machine plus
classique et extrapoler à partir des résultats obtenus, mais la marge
d'erreur sera plus grande.
Si l'un de ces sous-ensembles court le risque d'être saturé dans
l'utilisation de l'application et qu'un accroissement de capacité de ce
sous-ensemble n'est pas envisageable ou ne suffira pas, il peut y avoir un
avantage significatif à partager l'application sur deux serveurs. Si le
risque de saturation est faible voire nul, ou s'il existe mais n'est pas
considéré comme impactant pour l'usage prévu, vous pouvez opter pour la
solution d'avoir un seul serveur.
Pour finir, un avantage à prendre en compte dans la solution à deux
serveurs est la tolérance de panne: dans une architecture cluster où les
deux serveurs sont actifs et où l'application est "cluster-aware", quand
tout se passe bien le travail est réparti entre les deux serveurs
(répartition déterminée par l'application selon ses propres critères) et
en cas de problème sur un serveur les traitements peuvent être repris sur
l'autre serveur le temps de le remettre en service. Pour que tout cela
fonctionne aussi idéalement que décrit, il faut que l'application sache
fonctionner en cluster (qu'elle soit "cluster-aware" comme je disais plus
haut). Il doit exister des livres blancs à ce sujet, il faudrait fouiller
notamment sur le site de Microsoft.
"Jacques Barathon [MS]" a écrit dans le message de news:
"Fred" wrote in message news: <snip>
Est il préférable d'avoir un serveur quadri-pro ou deux serveurs bi-pro ? Le choix se fera en fonction du rapport performance/prix.
Le traitement effectué par les serveurs sont de séquentiels et seront selon l'architecture choisie multithreads sur une appli ou multithread sur deux applis tournants sur 2 serveurs :
Première solution : traitement de 4 données sur un serveur
1 serveur quadri-processeurs :
- Application avec quatre threads traitant chacun une donnée
Deuxième solution : traitement de 2 données par serveur sur 2 serveurs
2 serveurs biprocesseurs :
- Deux applications avec deux threads traitant chacun une donnée
Difficile d'apporter une réponse franche. J'essaierai plutôt de donner quelques conseils quant à la meilleure façon de répondre par vous-même.
La 1ere solution a l'avantage de la simplicité, ce qui n'est pas négligeable.
Dans le 2e cas il faudra mettre en place un partage des données, à priori dans une architecture de type cluster/SAN. Cela aura un impact significatif sur le coût de la solution, à l'achat et à la maintenance.
Dans cette solution il faudra également prévoir une synchronisation entre les deux applis, soit un coût supplémentaire potentiel dans les performances. A évaluer en fonction de la technique de synchronisation utilisée.
Pour vraiment évaluer les avantages de la 2e solution en termes de performance, il faudrait évaluer l'impact de l'application sur les principaux sous-ensembles du serveur, notamment la CPU, la mémoire, les disques durs et l'interface réseau. Cette évaluation peut se faire au cours d'un pilote sur un matériel le plus proche possible du ou des matériels choisis au final. Vous pouvez par exemple vous faire prêter par votre fournisseur un serveur bi-pro le temps de faire vos tests. Si ce n'est pas possible, vous pouvez faire vos tests sur une machine plus classique et extrapoler à partir des résultats obtenus, mais la marge d'erreur sera plus grande.
Si l'un de ces sous-ensembles court le risque d'être saturé dans l'utilisation de l'application et qu'un accroissement de capacité de ce sous-ensemble n'est pas envisageable ou ne suffira pas, il peut y avoir un avantage significatif à partager l'application sur deux serveurs. Si le risque de saturation est faible voire nul, ou s'il existe mais n'est pas considéré comme impactant pour l'usage prévu, vous pouvez opter pour la solution d'avoir un seul serveur.
Pour finir, un avantage à prendre en compte dans la solution à deux serveurs est la tolérance de panne: dans une architecture cluster où les deux serveurs sont actifs et où l'application est "cluster-aware", quand tout se passe bien le travail est réparti entre les deux serveurs (répartition déterminée par l'application selon ses propres critères) et en cas de problème sur un serveur les traitements peuvent être repris sur l'autre serveur le temps de le remettre en service. Pour que tout cela fonctionne aussi idéalement que décrit, il faut que l'application sache fonctionner en cluster (qu'elle soit "cluster-aware" comme je disais plus haut). Il doit exister des livres blancs à ce sujet, il faudrait fouiller notamment sur le site de Microsoft.
