... et au dela !


Beau comme ma 10ème opensim.

Oui, je me suis lancé dans opensim... surtout pour l'interet technique.
C'est en Alpha version, mais utilisable.

Opensim, ce n'est pas un seul serveur, mais plusieurs serveurs.
UserServer, GridServer, AssetServer, SimServer, InventoryServer, ScriptServer, MessagingServer.

Chacun ayant sa fonction, et sa base de donnée.
On peut tout faire tourner sur un seul serveur ("standalone"), c'est bien pour des mini-grillé privée ou bien faire tourner ca en mode "grille" pour gerer... des centaine... milliers... centaines de milliers de sim !!

J'aime bien commencer petit ... mais toujours voir grand ;)
Pour le coté grille, je me suis installé sur la francogrid et je collabore avec eux pour penser a une architecture de grille capable de gerer des milliers de sim.

Pour resumer de facon simple, il y a 2 type d'approches :
- Un serveur "gros cul" super bourrin genre octocore 16GB de RAM, etc ...
- L'approche "google", une quantité astronomiqe de miniserveurs pas cher.


Pour le serveur "gros cul", le matos coute horriblement cher.
Au debut il sera largement sous-utilisé, perte d'argent.
Apres... il risque de ne pas etre assez puissant... il faut le changer vers quelque chose de plus puissant... en considerant que ca existe !!

L'approche "google", c'est plein de serveur pas cher, et on rajoute des serveurs en fonction de la charge.
Ca demande la realisation d'outils speciaux, on ne manage pas aussi facilement un gros serveur que des milliers de petits. Mais ca... c'est mon metier ;)

Et donc j'ai adopté l'approche "google". Qui a de multiple autres avantages amis je ne vais pas me lancer dans des explications barbares : trop long, trop compliqué et ... Secret Industriel ;)

Je me concentre d'abord sur la partie "serveur de sim". La grille etant fonctionnelle, supportant largement la charge pour l'instant, et va de toute facon radicalement changé d'architecture dans le futur, pas la peine de se prendre la tete sur un truc qui sera obsolete dans 6 mois. Cela dit il faut y penser des maintenant, car on sait a quoi ca va ressembler dans le futur.


Grosso-modo, un serveur de sim a besoin de quoi :
- Beaucoup de RAM, en quantité assez fixe par sim.
- Un serveur sql
- Tres peu d'espace disque (tout est sur le serveur sql)
- Du cpu... de facon variable.

Une sim peut utiliser 5% du cpu comme elle peut en utiliser 100%, beaucoup de facteurs entre en jeu.
L'idée est d'avoir x sim par serveur, et de faire evoluer dynamiquement le nombre de sim par serveur selon la charge. Un serveur peut tres bien supporter 10 sims qui foutent rien (a condition d'avoir assez de ram), comme ne pas arriver a supporter une seul sim. Et... ca peut changer au fil des jours, on meme de la journée !

Voir : http://88.191.75.142/SLstat/

Il faut voir gros, et eliminer l'inutile pour reduire les couts au maximum.
A commencer par l'espace disque par sim...

Tous les serveur de sim vont utiliser une baie iSCSI pour le stockage... 1Go de disque par sim c'est largement suffisant, alors pourquoi depenser dans des disques qui font au minimum dans les 80Go.  Economie d'energie, economie de matos, ... d'argent. L'idée c'est bien sur de proposer des sims les moins chere possible ;)

Peu de ram par serveur en general, car le cpu sera a fond bien avant qu'il y ai assez de sim pour bouffer toute la ram dispo.
Cas particulier : Quelques serveurs avec beaucoup de RAM pour gerer des sims qui n'ont pas besoin de CPU. (water sim, etc)


pour les bases SQL de chaques sim (et non pas de la grille, ou de l'inventaire, juste celles des sims).
Une quantité de serveur sql "moyens" avec un systeme de replication et de proxy-cache.

Autrement dit : chaque sim va interroger 2 front-end (redondance), qui vont se charger de faire les requetes et de fournir le resultat au serveur de sim. Qu'il y ai 1, 2, 5000 serveurs sql derriere n'est pas le probleme des sims.
Ca permet un load-balancing dynamique et de faire evoluer l'architecture en fonction de la charge... pas besoin d'un serveur enorme et couteux, ni de se perdre dans des optimisations fastidieuses... Et si un serveur sql plante, ca ne pose strictement aucun probleme grace a la replication. Qu'on tourne avec 50 ou 49 petits serveurs sql ne changera pas grand chose... 2% ... Qu'on tourne avec 2 ou 1 gros serveur ... pose un gros probleme (50% !! )
(autrement dit : plus un serveur est gros, plus dure est la chute)

Configuration dynamique... il faut des outils simple pour migrer une sim d'un serveur a l'autre.
Une grande partie est resolue en externalisant la base de donnée.
Si un serveur plante... on relance les sims sur un autre serveur... aucun probleme de donnée perdue... puisque les données ne sont pas sur le serveur qui a planté.

Actuellement, j'ai 9 sims sur 2 serveurs. Et je peux en rajouter d'autres ... normal, y'a personne :))
Au fur et a mesure que la charge augmentera, il suffira de rajouter des serveurs pour avoir moins de serveurs par sim.

Grosso modo : pour le meme prix, il est possible de faire tourner 10 sims peu chargée.... ou une seule sim chargée ;)

Pourquoi je raconte tout ca ?
Les grandes lignes de l'architecture mise en place n'est pas vraiment secrete...
Les outils et les details le sont, et sur ce point je n'ai rien dit ;)
Les competances pour mettre tout ca en place... m'appartiennent ;)


Donc... d'ici peu, je pourrai proposer l'hebergement de sims sur opensim (francogrid ou grille privée).
A (beaucoup?) moins de 30.000L$ par sim .
Comparés aux 100.000L$ chez LL ;)

Et meme mieux, avec ce systeme dynamique... Un forfait ou vous payez "a la charge".
Par exemple, pour le meme prix : "10 sim peu chargée" ou "1 sim chargée".
Et louer des "unité de charge" supplementaire au fur et a mesure que la charge de chaque sim augmente.

C'est pas beau ca ?

Entre 2 posts serieux, on trouve parfois des perles, ca viens de JOL, et ca sera classé dans la catégorie "exercice de style".
J'suis fan, merci pour ce post !!