yamashi Ecris:

Mais d'ici 2010 quand le jeu sortira nous aurons surement près de 100 core par serveur avec 30go de ram je ne pense pas que ce genre de problème puisse intervenir.
Pour ce qui est du recovery les serveurs ne peuvent pas planter sauf sous une coupure de courant donc je n'ai pas a me soucier de ca.

Pour le recovery je parlais "recovery en cas de surcharge", pas en cas de problème d'update DB.

Pour info je travaille sur des stations Sun Fire T2000, qui ont 16Go de RAM et un CPU UltraSPARC T1 avec 32 CoolThreads en exécution simultanée (4 core émulant 8 thread) - c'est du petit matériel en fait - et le problème se présente car ça n'a rien à voir avec l'optimisation du code ou le matériel seuls, c'est un problème lié aux réseaux quels qu'ils soient.

En pratique, on modélise la charge serveur et réseau en fonction de ce qu'on attend. Ensuite on configure des algos (balance de charge à proportions dnamiques, controle de charge adaptif basé sur système de monitoring avec courbe de régulation dynamique en proportionnel intégral) pour coller à ce modèle théorique, puis l'algo s'adapte de manière automatique en fonction de ce qui est observé.

C'est une façon de faire, mais quand on travaille sur des serveurs qui reçoivent une charge distribuée le problème de balance comme de régulation va se présenter. Si le serveur se plante ou surcharge, quelle est le temps de recovery si on ne peut pas basculer (surcharge globale par exemple)? Et de switchover? Si le serveur est surchargé, comment déplacer sa charge (en optimisant les destinataires) sans sous-charger ce serveur? Au vu du cout d'un serveur, comment assurer que l'usage est optimal sans controle et distribution de charge? Pourquoi ne pas refuser certaines connexions plutot que de vouloir à tout prix les gérer?

Je pense que quand on développe sur plusieurs serveurs, ces problèmes doivent être pris en compte. Les process industriels existent (PI, PID, etc.), de plus ils sont simples à mettre en oeuvre, par exemple:

• un système de distribution de charge qui monitore les serveurs de DB et distribue en fonction de la charge monitorée sur chaque serveur DB, donc dont les proportions sont dynamiques puisque la charge sur chaque serveur peut varier indépendamment des autres
• une modélisation de serveur avec charge à courbe dynamique et refus d'envoi à un serveur si celui-ci est surchargé + rebalance)

Et puis, si ça n'était pas nécessaire, je serais au chômage depuis longtemps Je pense en développer une lib pour gérer ça dans le projet ALODP d'ailleurs... Car tabler sur le seul matériel est une mauvaise idée à mon sens.

yamashi Ecris:

Dans le cas ou un serveur serait surpeuplé (a partir de 5000 joueurs dans la zone ce qui n'arrivera sûrement jamais)

Tu as fait des stress-tests? Dire que ça n'arrivera jamais c'est une erreur, dans les systèmes à charge aléatoire tu ne peux pas le calculer, tout ce qu'on peut faire c'est des modèles théoriques et c'est pour ça justement qu'on utilise des régulateurs adaptifs rapides afin d'éviter que la destination n'explose. Et si même ta charge était uniforme et synchronisée, ça ne serait pas mieux (peut-être même pire). Evidemment, pour les serveurs Web on ne fait pas attention à ça puisque c'est du "best effort", si le serveur est down tant pis. Mais du best effort pour un jeu réseau en ligne je trouve ça moyen.

Tu proposes de redistribuer, c'est bien, mais pas suffisant à mon avis.

valholl

yamashi Ecris:

Mais d'ici 2010 quand le jeu sortira nous aurons surement près de 100 core par serveur avec 30go de ram je ne pense pas que ce genre de problème puisse intervenir.
Pour ce qui est du recovery les serveurs ne peuvent pas planter sauf sous une coupure de courant donc je n'ai pas a me soucier de ca.

Pour le recovery je parlais "recovery en cas de surcharge", pas en cas de problème d'update DB.

Pour info je travaille sur des stations Sun Fire T2000, qui ont 16Go de RAM et un CPU UltraSPARC T1 avec 32 CoolThreads en exécution simultanée (4 core émulant 8 thread) - c'est du petit matériel en fait - et le problème se présente car ça n'a rien à voir avec l'optimisation du code ou le matériel seuls, c'est un problème lié aux réseaux quels qu'ils soient.

En pratique, on modélise la charge serveur et réseau en fonction de ce qu'on attend. Ensuite on configure des algos (balance de charge à proportions dnamiques, controle de charge adaptif basé sur système de monitoring avec courbe de régulation dynamique en proportionnel intégral) pour coller à ce modèle théorique, puis l'algo s'adapte de manière automatique en fonction de ce qui est observé.

C'est une façon de faire, mais quand on travaille sur des serveurs qui reçoivent une charge distribuée le problème de balance comme de régulation va se présenter. Si le serveur se plante ou surcharge, quelle est le temps de recovery si on ne peut pas basculer (surcharge globale par exemple)? Et de switchover? Si le serveur est surchargé, comment déplacer sa charge (en optimisant les destinataires) sans sous-charger ce serveur? Au vu du cout d'un serveur, comment assurer que l'usage est optimal sans controle et distribution de charge? Pourquoi ne pas refuser certaines connexions plutot que de vouloir à tout prix les gérer?

Je pense que quand on développe sur plusieurs serveurs, ces problèmes doivent être pris en compte. Les process industriels existent (PI, PID, etc.), de plus ils sont simples à mettre en oeuvre, par exemple:

• un système de distribution de charge qui monitore les serveurs de DB et distribue en fonction de la charge monitorée sur chaque serveur DB, donc dont les proportions sont dynamiques puisque la charge sur chaque serveur peut varier indépendamment des autres
• une modélisation de serveur avec charge à courbe dynamique et refus d'envoi à un serveur si celui-ci est surchargé + rebalance)

Et puis, si ça n'était pas nécessaire, je serais au chômage depuis longtemps Je pense en développer une lib pour gérer ça dans le projet ALODP d'ailleurs... Car tabler sur le seul matériel est une mauvaise idée à mon sens.

yamashi Ecris:

Dans le cas ou un serveur serait surpeuplé (a partir de 5000 joueurs dans la zone ce qui n'arrivera sûrement jamais)

Tu as fait des stress-tests? Dire que ça n'arrivera jamais c'est une erreur, dans les systèmes à charge aléatoire tu ne peux pas le calculer, tout ce qu'on peut faire c'est des modèles théoriques et c'est pour ça justement qu'on utilise des régulateurs adaptifs rapides afin d'éviter que la destination n'explose. Et si même ta charge était uniforme et synchronisée, ça ne serait pas mieux (peut-être même pire). Evidemment, pour les serveurs Web on ne fait pas attention à ça puisque c'est du "best effort", si le serveur est down tant pis. Mais du best effort pour un jeu réseau en ligne je trouve ça moyen.

Tu proposes de redistribuer, c'est bien, mais pas suffisant à mon avis.

valholl