Les effervescences de kerunix
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 ?
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 ?
Mer 28 mai 2008
6 commentaires
Si si, c'est beau comme l'avenir, le futur
Bon, je m'en vais cueillir quelques pâquerettes...
GK
Garance Kidd - le 28/05/2008 à 10h01
Ouiiiiiiiii ! Il fait enfin de nouveau soleil ;)
keru
Pfffffff
GK
Garance Kidd - le 28/05/2008 à 10h10
Honnetement, si quelque fournisseur d'acces ou autre hebergeur francais deja equipe voulait bien se lancer, il faudra pas qu'il aille chercher trop loin les competences. HEM.
Je pense a free, gandi, ovh...
Mais bon, j'dis ca, j'dis rien... ;-)
Forest/Grumly57 - le 28/05/2008 à 12h06
C'est exact :)
En attendant il y a des FAI genre Orange sur secondlife, et tout ce qu'ils font c'est des concerts. Pas d'offre de service a grande echelle comme on pourrait s'y attendre... Donc y'a de quoi voir venir :)
En attendant il y a des FAI genre Orange sur secondlife, et tout ce qu'ils font c'est des concerts. Pas d'offre de service a grande echelle comme on pourrait s'y attendre... Donc y'a de quoi voir venir :)
keru
Intéressant tout ça ... Mais tant que tu pourras pas accueillir un avatar "made in SL " (ou d'ailleurs), ça paraît joli techniquement et super financièrement ... mais potentiellement désert nan ?
Je fais quoi moi dans un opensim sans mon pack Xcite ? Je cueille des pâquerettes ? !-)
Et me réponds pas "Tu te le crées" ... En 2047 j'aurais plus envie de m'en servir ! Enfin ... je pense.
Quelque chose me dit que tu dois avoir des pistes et des idées sur ces inter-connexions ...
yongho - le 28/05/2008 à 16h54
Coucou keru ;)
Pour ma par ma grid tourne sur un serv a 2go de ram et 2x250go. j'ai eu des petits problemes au depart, mais une fois les erreurs corrigées la grid tiens tres bien le choc. Par contre je ne laisse que deux sim sur le serv grid (une obligatoire et une autre pourqu'elle ce sente moins seul :p) Mais je deconseille fortement de surchargé le serveur grid. Tout simplement parceque le serv grid maintient l'ensemble des sim des locataires. Et on a beau dire que ovh c pas cher, et bah apres de nombreux test, j'ai changé de fournisseur. Si l'on veux une sim ou l'on peux terra oubliez les serv a 30€ par mois, et pareil pour la la liaison de prims. Mieux faut payer le double et avoir une sim qui ne crash "pas" (ca arrive malgres tout) Et quand une sim plante, tu as une ligne de commande a installé pour l'auto reboot des regions. Tu dit 9 sim par seveurs,(mes respects) moi j'ai fixé des limites directement en fonction du serveur que je tarifie (houlla pas dormie le scoun, enfin si sur son clavier)En gros placé trop de sim sur un meme serveur ca revient a mettre 60 litres de gazoil dans un reservoir de 40. Je me permet de dire ca car sur ma wipigrid (wipilab) nous effectuons des bateries de test pour pouvoir stabilisé le mieux possible la grid, qui d'ailleur est toujours privée pour des raisons de sécuritè et de fiabilité (vi vi jsuis un gros case couille la dessus) Mais le terraforming est fonctionnel, la friend list aussi, la save avatar et inventaire aussi, sauf une chose que l'on ne s'explique pas encore pour le moment c'est que quand l'on parle d'un bout de sim (en tchat) on entend ou plutot on voie le texte une sim plus loin. Pour la voice, il y'a eu une version ou cela fonctionné, mais depuis la (enfin les nombreuses mise a jour)cela ne fonctionne plus :( on cherche, on cherche.
tu nous dit:Les competanses pour mettre tout ca en place... m'appartiennent ;)
non keru cela fait deja 6 mois que je taf sur opensim avec mon concierge (vi je l'appel comme ca, car il solusionne les prbs en moins de deux)
Quand a tes tarifs proposés, ne pense tu pas que fournir les premieres sim a prix coutant serait une bonne chose, enfin avec une legere marge car la maintenance prend du temps et une presence d'un staff est importante. Nous nous sommes un dixaine de sur Wipi a etre present et a effectuer une batterie de test sur la grid (crash sim,script (dur dur d'ailleur ceux la)et saturation de liaison de prims qui est ilimités sur opensim (le serv ramasse)
Voila keru, si un travail de cohesion te branche, moi je n'est rien contre mais je ne tend pas la main deux fois (enfin je crois)
bisou mon tio kerufix
scoun - le 30/05/2008 à 10h10
Il est evident que les serveurs ne tiendront pas autant de sim pendant bien longtemps ;)
Mais c'est plus facile de faire des tests d'optimisation sur un serveur lent que sur un serveur qui rigole a chaque fois que t'essayes de le charger comme un mulet.
Pour decharger l'asset serveur de la grille j'ai commencé a installer des proxy. C'est tres tres efficace. Le demarage de 7 sim prends quelques seconde au lieu de plus d'une minute.
Pour decharger les serveurs de sim, je fait tourner toutes les "regions DB" sur un serveur dedié a ca. Je suis en train d'etudier les possibilité de cluster mysql, de replication mysql, de proxy-sql, ...
Je suis convaincu de l'interet de faire tourner une tonne de petits serveur plutot que quelques gros. Et puis... techniquement, c'est plus rigolo d'avoir un cluster qu'une poignée de gros serveur.
Je suis en train de migrer des sims sur un autre serveur. Et comme les sims pointent sur la meme regionDB ... la migration s'effectue tres simplement sans avoir a migrer aussi la region DB. Ca permet de passer les sims d'un serveur a l'autre tres simplement et tres rapidement.
Bien sur, du coup, mais seulement pour l'instant, le serveur de regionDB est le maillon faible... (s'il plante, toutes les sims de tous les serveurs plantent) ... mais ca sera corrigé. C'est juste que c'est plus compliqué a mettre en place. Et si j'ai bien crompsi l'architecture des regionsDB changera, a la facon de l'asset_server DB, avec un front end HTTP plutot qu'un acces direct a la DB, ce qui simplifiera tres grandement tout ca et permetra même de mettre en place un proxy beaucoup plus simplement qu'avec un proxy-sql "standard".
Pour les prix des sims, pour l'instant j'offre du terain a des createurs. On vera par la suite comment vendre/louer, a quel prix, dans quelles conditions.
On peut collaborer oui. Deja, je publie des informations, bien que non-technique elles donnent une idée de l'architecture serveur que je met en place, et c'est pas rien ;)
Mais c'est plus facile de faire des tests d'optimisation sur un serveur lent que sur un serveur qui rigole a chaque fois que t'essayes de le charger comme un mulet.
Pour decharger l'asset serveur de la grille j'ai commencé a installer des proxy. C'est tres tres efficace. Le demarage de 7 sim prends quelques seconde au lieu de plus d'une minute.
Pour decharger les serveurs de sim, je fait tourner toutes les "regions DB" sur un serveur dedié a ca. Je suis en train d'etudier les possibilité de cluster mysql, de replication mysql, de proxy-sql, ...
Je suis convaincu de l'interet de faire tourner une tonne de petits serveur plutot que quelques gros. Et puis... techniquement, c'est plus rigolo d'avoir un cluster qu'une poignée de gros serveur.
Je suis en train de migrer des sims sur un autre serveur. Et comme les sims pointent sur la meme regionDB ... la migration s'effectue tres simplement sans avoir a migrer aussi la region DB. Ca permet de passer les sims d'un serveur a l'autre tres simplement et tres rapidement.
Bien sur, du coup, mais seulement pour l'instant, le serveur de regionDB est le maillon faible... (s'il plante, toutes les sims de tous les serveurs plantent) ... mais ca sera corrigé. C'est juste que c'est plus compliqué a mettre en place. Et si j'ai bien crompsi l'architecture des regionsDB changera, a la facon de l'asset_server DB, avec un front end HTTP plutot qu'un acces direct a la DB, ce qui simplifiera tres grandement tout ca et permetra même de mettre en place un proxy beaucoup plus simplement qu'avec un proxy-sql "standard".
Pour les prix des sims, pour l'instant j'offre du terain a des createurs. On vera par la suite comment vendre/louer, a quel prix, dans quelles conditions.
On peut collaborer oui. Deja, je publie des informations, bien que non-technique elles donnent une idée de l'architecture serveur que je met en place, et c'est pas rien ;)
keru
Pour la DB, regarde du côté de PostgreSQL/Slony ;)
Lolo - le 03/06/2008 à 23h14