Choisir la bonne archi mysql

20 réponses

Page 1 2

Auteur	Message
cerise \| Modérateur Inscrit le : 31/10/2008	# Le 06/01/2013 à 10:08 Bonjour dans le cadre d'une application en saas php / Mysql, on a le choix entre 2 solutions : 1 - une seule base avec tous les clients 2 - autant de bases que de clients la base comporte environ 70 tables Je n'arrive pas à savoir ce qui est préférable. Les 2 solutions semblent avoir leurs avantages et leurs inconvénients. La solution 2 me semble dans l'idéal la plus propre, ne serait-ce que pour le cloisonnement total des données et la nullité des risques qu'un client accède aux données du voisins. Et par ailleurs, un client qui s'en va, sa base est supprimée et ça n'a pas d'incidence sur les autres bases. La solution 2 permet donc d'isoler complètement les clients, chacun sa base, de les répartir sur plusieurs serveurs au fil du temps, mais avec 10 000 clients, ça veut donc dire autant de bases, et ça veut dire aussi bonjour la maintenance Combien mysql peut-il gérer de bases pour conserver des performances acceptables ? Car si à partir de 100 bases les perfs chutent, ça va être difficile d'envisager de monter 100 serveurs Mysql Qu'en pensent les pros ?
krucial \| Jean Christophe Administrateur Inscrit le : 09/03/2005	# Le 06/01/2013 à 10:28 J'y connais pas grand chose, mais je pense qu'au niveau perf, mieux vaut 100 petites base qu'une très grosse. JC - Mes sites \| Affiliation devis travaux \| Cotes voitures anciennes
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 06/01/2013 à 10:37 Hello, ça dépend aussi du volume de données, mais oui quand il y a trop de fichiers on peut rencontrer quelques soucis : - déjà la limite du nombre de BDD dépend du filesystem utilisé (32k en ext3 et 64k en ext4 par exemple, et à priori pas de limite en XFS) - MySQL, comme tout process, est limité en nombre de tables ouvertes simultanément. C'est en partie tunable, mais au delà de 64k tables je ne suis pas certain que ça se comporte bien... s'il y a de l'activité sur plus de 64k table à la fois, ça pourrait être un gros goulet d'étranglement - attention au nombre d'inode : si tu as plein de tables de moins d'1Mo par exemple, le ratio inode / espace disque risque d'être foireux et t'empêcher d'ajouter des tables. - le fait de scinder tes clients par base, est-ce que ça implique de dupliquer une partie des données ? Quel pourcentage ? À noter que par défaut InnoDB stocke dans un seul tablespace les données de toutes les tables. Ce qui pour le coup éliminerait une partie des contraintes ci dessus. L'inconvénient c'est que l'espace n'est pas libéré en cas de suppression de client, et que pour ma part je déteste ce fonctionnement, assez galère à maintenir dans le temps. Sinon, entre avoir un seul serveur avec X bases, et X serveurs avec 1 base, y a de la marge ;) J'aurais tendance à grouper jusqu'à un certain volume... genre 50Go de données par serveur, si tu pars sur des machines type EG 64G. daevel : infogérance et conseil \|\| moi
cerise \| Gaël Modérateur Inscrit le : 31/10/2008	# Le 06/01/2013 à 11:00 donc en clair Bool, tu préconises la solution 2 soit une base par client ? L'appli sera hébergée sur un private Cloud, donc ce n'est pas un soucis pour ajouter une VM Mysql dans l'archi. On a pensé à un dispatcheur qui fonctionnerait comme suite : les clients 1 à x >> connexion au serveur mysql 1 les clients x+1 à y >> serveur 2 etc etc la question c'est que je n'ai pas trop idée jusqu'à combien de bases c'est raisonnable par serveur. On m'a dit qu'à partir d'une centaine de bases, ça commençait à attaquer sérieusement les perfs, et je trouve que du coup c'est pas beaucoup, j'aurais pensé que gérer des milliers était possible (dans la limite du filesystem qui me semblait le premier facteur limitant avant le nombre de bases en fait), ce qui à priori est loin des 64k tables que tu indiques. Donc à priori on serait plus proche des 1000 clients par serveur que des 100, ce qui est déjà plus envisageable
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 06/01/2013 à 11:13 Yep, je serais plutôt pour la solution 2, qui «scale» beaucoup mieux dans le temps. Quant à une hypothétique limite à 100, je n'ai jamais remarqué ça non. Là tout de suite, je suis connecté sur un des serveurs d'un client avec ce type de répartition : daevel@node02:~$ mysql -Be 'show databases' \| wc -l 1286 Le soucis par contre avec une répartition fixe par «numéro» comme ça, c'est que tu pars du principe que tous les clients auraient le même volume de données & accès. Est-ce vraiment le cas ? Mon client en question était parti là dessus, et du coup on se retrouve avec des machines stockant 20Go de données, et d'autres à plus de 200Go. Coté ressources, «suffit» d'ajuster la puissance de la VM (merci la virtualisation), mais tu te retrouves quand même avec une conf MySQL spécifique à chaque machine, c'est plus chiant à gérer/maintenir. daevel : infogérance et conseil \|\| moi
cerise \| Gaël Modérateur Inscrit le : 31/10/2008	# Le 06/01/2013 à 11:23 c'est pas faux tu as raison, mais ça me paraît difficile d'anticiper une telle inconnue. Si on part du principe qu'un serveur peut héberger 1000 clients, on peut faire une moyenne des ressources nécessaires et garder une marge de sécurité. Dans le cadre de l'automatisation de la création des comptes, je ne vois pas en outre comment on peut faire plus simple qu'une répartition par id client
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 06/01/2013 à 11:28 Oui dès lors que la répartition est automatique, tu auras le problème... Une solution serait de passer par une table de correspondance, mais la gestion n'est pas forcément aisée et ça fait un hook supplémentaire. daevel : infogérance et conseil \|\| moi
ddpetit \| Damien Modérateur Inscrit le : 03/05/2006	# Le 06/01/2013 à 11:29 Pourquoi ne pas partir sur du NoSQL qui permettrait de traiter de gros volumes de données. Je n'y connais pas grand chose, j'ai étudié la question de loin car je ne suis pas dans le cas là pour le moment. Y'en a qui connaissent ? Loccasion.com - Vente de voitures d'occasion - Mandataire Auto
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 06/01/2013 à 11:51 Le «NoSQL» c'est magnifique quand tu fais du clé valeur... mais c'est vite limité. Donc ça dépend de ton usage, mais si tu as de gros besoin de jointures et group by, tu vas vite être coincé. daevel : infogérance et conseil \|\| moi
PyRoFlo \| Florent Modérateur Inscrit le : 09/05/2005	# Le 06/01/2013 à 17:12 Clairement, je partirai avec la solution 1, en jouant avec le partitionnement . Selon moi l'argument du cloisonnement des données ne tient pas : il suffit d'utiliser un utilisateur SQL par client, avec les bonnes permissions. Sauf si tu sais que tes clients auront une grosse volumétrie de données (plusieurs Go), je pense que c'est le meilleur compromis perfs / maintenabilité. Pour les éventuels gros clients, tu peux toujours en faire un cas particulier et les isoler sur un autre serveur. Feu d'artifice Paris
tonguide \| Jeremy Modérateur Inscrit le : 09/05/2005	# Le 06/01/2013 à 17:28 Sinon grouper les clients sur la même table avec ID du client à chaque ligne ? Et isoler les clients qui grossissent ou risques de grossir vite. Sauf si évidemment il faut qu'ils puissent avoir accès seul à MySql ?
caaptusss \| Jérémy Membre Inscrit le : 25/09/2007	# Le 06/01/2013 à 17:32 Coté technologie, pensez aussi à memcache, déployé notamment dans le cas ou vous avez plusieurs centaines de lectures sur vos bases chaque secondes. Techno utilisée par Facebook et Twitter, et à notre niveau pour maintenir une application de résultats sportifs (je vous laisse imaginer le nombre de req/s les soirs de matchs de foot) FirstHeberg.com
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 06/01/2013 à 18:10 C'est vrai que si on parle d'un petit volume, comme l'indique Pyroflo, ça vaut pas le coup de se prendre la tête. Avoir une idée de la volumétrie aiderait. Déjà, à moins de 50Go de données, je ne vois aucune raison de scinder. Par contre pour la sécurité, MySQL ne gère pas les droits par ligne. Donc un client, même avec un compte spécifique, aura accès à toutes les lignes d'une table sinon rien. Généralement c'est loin d'être super efficace coté sécurité. daevel : infogérance et conseil \|\| moi
PyRoFlo \| Florent Modérateur Inscrit le : 09/05/2005	# Le 06/01/2013 à 19:03 Bool a dit :Par contre pour la sécurité, MySQL ne gère pas les droits par ligne. Donc un client, même avec un compte spécifique, aura accès à toutes les lignes d'une table sinon rien. Généralement c'est loin d'être super efficace coté sécurité. Exact, j'ai un peu mélangé avec Oracle. A voir selon la criticité du projet si c'est réellement nécessaire. Feu d'artifice Paris
cerise \| Gaël Modérateur Inscrit le : 31/10/2008	# Le 07/01/2013 à 09:18 pour l'exemple, prenez une plateforme de blog ou chacun aurait son blog ou chacun aurait son blog avec sa base Dans le principe, l'appli est censée être propre à chaque client, chacun avec ses données. Si un client part, il doit supprimer ses données. Tout mettre dans une base est du coup moins propre à l'usage non ? Comment vous réglez en outre la question des tables avec autoincremente et des champs uniques ? Le partitionnement peut quelque chose à ce niveau ?
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 07/01/2013 à 09:31 Ok, donc on est plutôt sur du très faible volume ? Tout mettre dans une base est du coup moins propre à l'usage non ? Bof, pour le coup je vois pas trop. Comment vous réglez en outre la question des tables avec autoincremente et des champs uniques ? Quelle question ? Les autoincrement restent tels quels, et pour les clés d'unicité tu y ajoutes l'idClient si besoin. Le partitionnement peut quelque chose à ce niveau ? Du tout, au contraire le partitionnement est allergique avec les clés d'unicités. daevel : infogérance et conseil \|\| moi
nayluge \| Cyril Membre Inscrit le : 09/01/2008	# Le 10/01/2013 à 00:23 Je vote aussi Solution 2 pour : 1 - Isolation des données. 2 - Scalabilité future 3 - Maintenance ( niveau tuning, c'est plus simple de gérer n petites bases qu'une énorme ). Par contre le sql sur VM ... Faut pas avoir trop de succès ...
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 10/01/2013 à 01:16 Y a VM et VM. Quand il commence à y avoir plusieurs dizaines de Go de RAM et de coeurs, avec un stockage qui tient la root, ça permet d'avoir un serveur MySQL redondé, sans avoir recours à la réplication bancale, ou nécessiter du MySQL Cluster. Perso c'est une solution que j'aime bien au contraire. daevel : infogérance et conseil \|\| moi
nayluge \| Cyril Membre Inscrit le : 09/01/2008	# Le 10/01/2013 à 01:51 C'est pas les coeurs ou la ram que je blame, c'est les perfs disques ... Ps: t'es bien dur avec la repli Mysql
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 10/01/2013 à 09:07 bah pour les perfs disque, ça dépend de l'infra de stockage. Si le stockage utilise des technos «haut de gamme» (contrôleur avec writeback mémoire, système avec writeback ssd, gros cache mémoire, disques SAS, etc), ça peut très bien se passer. Par contre c'est vrai qu'on a eu de mauvais retour sur les perfs disque du PCC. Est-ce toujours le cas cerise ? Et oui, je déteste la réplication MySQL, très peu fiable à mon goût. J'ai un client qui l'utilise beaucoup, si tu fais un checksum des tables (via MySQL hein, pas depuis l'OS) on a des hash différents pour chaque node... C'est juste flippant. Par contre je n'ai toujours pas eu l'occasion de tester un cluster Galera, qui est nettement plus fiable sur le papier. daevel : infogérance et conseil \|\| moi

Auteur

Message

Inscrit le : 31/10/2008

# Le 06/01/2013 à 10:08

Bonjour

dans le cadre d'une application en saas php / Mysql, on a le choix entre 2 solutions :

1 - une seule base avec tous les clients
2 - autant de bases que de clients

la base comporte environ 70 tables

Je n'arrive pas à savoir ce qui est préférable. Les 2 solutions semblent avoir leurs avantages et leurs inconvénients.

La solution 2 me semble dans l'idéal la plus propre, ne serait-ce que pour le cloisonnement total des données et la nullité des risques qu'un client accède aux données du voisins.
Et par ailleurs, un client qui s'en va, sa base est supprimée et ça n'a pas d'incidence sur les autres bases.

La solution 2 permet donc d'isoler complètement les clients, chacun sa base, de les répartir sur plusieurs serveurs au fil du temps, mais avec 10 000 clients, ça veut donc dire autant de bases, et ça veut dire aussi bonjour la maintenance

Combien mysql peut-il gérer de bases pour conserver des performances acceptables ? Car si à partir de 100 bases les perfs chutent, ça va être difficile d'envisager de monter 100 serveurs Mysql

Qu'en pensent les pros ?

krucial | Jean Christophe
Administrateur

Inscrit le : 09/03/2005

# Le 06/01/2013 à 10:28

J'y connais pas grand chose, mais je pense qu'au niveau perf, mieux vaut 100 petites base qu'une très grosse.

JC - Mes sites | Affiliation devis travaux | Cotes voitures anciennes

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 06/01/2013 à 10:37

Hello,

ça dépend aussi du volume de données, mais oui quand il y a trop de fichiers on peut rencontrer quelques soucis :
- déjà la limite du nombre de BDD dépend du filesystem utilisé (32k en ext3 et 64k en ext4 par exemple, et à priori pas de limite en XFS)
- MySQL, comme tout process, est limité en nombre de tables ouvertes simultanément. C'est en partie tunable, mais au delà de 64k tables je ne suis pas certain que ça se comporte bien... s'il y a de l'activité sur plus de 64k table à la fois, ça pourrait être un gros goulet d'étranglement
- attention au nombre d'inode : si tu as plein de tables de moins d'1Mo par exemple, le ratio inode / espace disque risque d'être foireux et t'empêcher d'ajouter des tables.
- le fait de scinder tes clients par base, est-ce que ça implique de dupliquer une partie des données ? Quel pourcentage ?

À noter que par défaut InnoDB stocke dans un seul tablespace les données de toutes les tables. Ce qui pour le coup éliminerait une partie des contraintes ci dessus. L'inconvénient c'est que l'espace n'est pas libéré en cas de suppression de client, et que pour ma part je déteste ce fonctionnement, assez galère à maintenir dans le temps.

Sinon, entre avoir un seul serveur avec X bases, et X serveurs avec 1 base, y a de la marge ;) J'aurais tendance à grouper jusqu'à un certain volume... genre 50Go de données par serveur, si tu pars sur des machines type EG 64G.

daevel : infogérance et conseil || moi

cerise | Gaël
Modérateur

Inscrit le : 31/10/2008

# Le 06/01/2013 à 11:00

donc en clair Bool, tu préconises la solution 2 soit une base par client ?
L'appli sera hébergée sur un private Cloud, donc ce n'est pas un soucis pour ajouter une VM Mysql dans l'archi.

On a pensé à un dispatcheur qui fonctionnerait comme suite :

les clients 1 à x >> connexion au serveur mysql 1
les clients x+1 à y >> serveur 2 etc etc

la question c'est que je n'ai pas trop idée jusqu'à combien de bases c'est raisonnable par serveur. On m'a dit qu'à partir d'une centaine de bases, ça commençait à attaquer sérieusement les perfs, et je trouve que du coup c'est pas beaucoup, j'aurais pensé que gérer des milliers était possible (dans la limite du filesystem qui me semblait le premier facteur limitant avant le nombre de bases en fait), ce qui à priori est loin des 64k tables que tu indiques. Donc à priori on serait plus proche des 1000 clients par serveur que des 100, ce qui est déjà plus envisageable

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 06/01/2013 à 11:13

Yep, je serais plutôt pour la solution 2, qui «scale» beaucoup mieux dans le temps.

Quant à une hypothétique limite à 100, je n'ai jamais remarqué ça non. Là tout de suite, je suis connecté sur un des serveurs d'un client avec ce type de répartition :

daevel@node02:~$ mysql -Be 'show databases' | wc -l

1286

Le soucis par contre avec une répartition fixe par «numéro» comme ça, c'est que tu pars du principe que tous les clients auraient le même volume de données & accès. Est-ce vraiment le cas ?

Mon client en question était parti là dessus, et du coup on se retrouve avec des machines stockant 20Go de données, et d'autres à plus de 200Go. Coté ressources, «suffit» d'ajuster la puissance de la VM (merci la virtualisation), mais tu te retrouves quand même avec une conf MySQL spécifique à chaque machine, c'est plus chiant à gérer/maintenir.

daevel : infogérance et conseil || moi

cerise | Gaël
Modérateur

Inscrit le : 31/10/2008

# Le 06/01/2013 à 11:23

c'est pas faux tu as raison, mais ça me paraît difficile d'anticiper une telle inconnue.
Si on part du principe qu'un serveur peut héberger 1000 clients, on peut faire une moyenne des ressources nécessaires et garder une marge de sécurité.
Dans le cadre de l'automatisation de la création des comptes, je ne vois pas en outre comment on peut faire plus simple qu'une répartition par id client

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 06/01/2013 à 11:28

Oui dès lors que la répartition est automatique, tu auras le problème... Une solution serait de passer par une table de correspondance, mais la gestion n'est pas forcément aisée et ça fait un hook supplémentaire.

daevel : infogérance et conseil || moi

ddpetit | Damien
Modérateur

Inscrit le : 03/05/2006

# Le 06/01/2013 à 11:29

Pourquoi ne pas partir sur du NoSQL qui permettrait de traiter de gros volumes de données. Je n'y connais pas grand chose, j'ai étudié la question de loin car je ne suis pas dans le cas là pour le moment. Y'en a qui connaissent ?

Loccasion.com - Vente de voitures d'occasion - Mandataire Auto

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 06/01/2013 à 11:51

Le «NoSQL» c'est magnifique quand tu fais du clé valeur... mais c'est vite limité. Donc ça dépend de ton usage, mais si tu as de gros besoin de jointures et group by, tu vas vite être coincé.

daevel : infogérance et conseil || moi

PyRoFlo | Florent
Modérateur

Inscrit le : 09/05/2005

# Le 06/01/2013 à 17:12

Clairement, je partirai avec la solution 1, en jouant avec le partitionnement . Selon moi l'argument du cloisonnement des données ne tient pas : il suffit d'utiliser un utilisateur SQL par client, avec les bonnes permissions.

Sauf si tu sais que tes clients auront une grosse volumétrie de données (plusieurs Go), je pense que c'est le meilleur compromis perfs / maintenabilité.

Pour les éventuels gros clients, tu peux toujours en faire un cas particulier et les isoler sur un autre serveur.

Feu d'artifice Paris

tonguide | Jeremy
Modérateur

Inscrit le : 09/05/2005

# Le 06/01/2013 à 17:28

Sinon grouper les clients sur la même table avec ID du client à chaque ligne ?
Et isoler les clients qui grossissent ou risques de grossir vite. Sauf si évidemment il faut qu'ils puissent avoir accès seul à MySql ?

caaptusss | Jérémy
Membre

Inscrit le : 25/09/2007

# Le 06/01/2013 à 17:32

Coté technologie, pensez aussi à memcache, déployé notamment dans le cas ou vous avez plusieurs centaines de lectures sur vos bases chaque secondes.
Techno utilisée par Facebook et Twitter, et à notre niveau pour maintenir une application de résultats sportifs (je vous laisse imaginer le nombre de req/s les soirs de matchs de foot)

FirstHeberg.com

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 06/01/2013 à 18:10

C'est vrai que si on parle d'un petit volume, comme l'indique Pyroflo, ça vaut pas le coup de se prendre la tête. Avoir une idée de la volumétrie aiderait. Déjà, à moins de 50Go de données, je ne vois aucune raison de scinder.

Par contre pour la sécurité, MySQL ne gère pas les droits par ligne. Donc un client, même avec un compte spécifique, aura accès à toutes les lignes d'une table sinon rien. Généralement c'est loin d'être super efficace coté sécurité.

daevel : infogérance et conseil || moi

PyRoFlo | Florent
Modérateur

Inscrit le : 09/05/2005

# Le 06/01/2013 à 19:03

Bool a dit :Par contre pour la sécurité, MySQL ne gère pas les droits par ligne. Donc un client, même avec un compte spécifique, aura accès à toutes les lignes d'une table sinon rien. Généralement c'est loin d'être super efficace coté sécurité.

Exact, j'ai un peu mélangé avec Oracle. A voir selon la criticité du projet si c'est réellement nécessaire.

Feu d'artifice Paris

cerise | Gaël
Modérateur

Inscrit le : 31/10/2008

# Le 07/01/2013 à 09:18

pour l'exemple, prenez une plateforme de blog ou chacun aurait son blog ou chacun aurait son blog avec sa base
Dans le principe, l'appli est censée être propre à chaque client, chacun avec ses données. Si un client part, il doit supprimer ses données.

Tout mettre dans une base est du coup moins propre à l'usage non ? Comment vous réglez en outre la question des tables avec autoincremente et des champs uniques ? Le partitionnement peut quelque chose à ce niveau ?

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 07/01/2013 à 09:31

Ok, donc on est plutôt sur du très faible volume ?

Tout mettre dans une base est du coup moins propre à l'usage non ?

Bof, pour le coup je vois pas trop.

Comment vous réglez en outre la question des tables avec autoincremente et des champs uniques ?

Quelle question ? Les autoincrement restent tels quels, et pour les clés d'unicité tu y ajoutes l'idClient si besoin.

Le partitionnement peut quelque chose à ce niveau ?

Du tout, au contraire le partitionnement est allergique avec les clés d'unicités.

daevel : infogérance et conseil || moi

nayluge | Cyril
Membre

Inscrit le : 09/01/2008

# Le 10/01/2013 à 00:23

Je vote aussi Solution 2 pour :

1 - Isolation des données.
2 - Scalabilité future
3 - Maintenance ( niveau tuning, c'est plus simple de gérer n petites bases qu'une énorme ).

Par contre le sql sur VM ... Faut pas avoir trop de succès ...

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 10/01/2013 à 01:16

Y a VM et VM. Quand il commence à y avoir plusieurs dizaines de Go de RAM et de coeurs, avec un stockage qui tient la root, ça permet d'avoir un serveur MySQL redondé, sans avoir recours à la réplication bancale, ou nécessiter du MySQL Cluster.

Perso c'est une solution que j'aime bien au contraire.

daevel : infogérance et conseil || moi

nayluge | Cyril
Membre

Inscrit le : 09/01/2008

# Le 10/01/2013 à 01:51

C'est pas les coeurs ou la ram que je blame, c'est les perfs disques ...

Ps: t'es bien dur avec la repli Mysql

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 10/01/2013 à 09:07

bah pour les perfs disque, ça dépend de l'infra de stockage. Si le stockage utilise des technos «haut de gamme» (contrôleur avec writeback mémoire, système avec writeback ssd, gros cache mémoire, disques SAS, etc), ça peut très bien se passer.
Par contre c'est vrai qu'on a eu de mauvais retour sur les perfs disque du PCC. Est-ce toujours le cas cerise ?

Et oui, je déteste la réplication MySQL, très peu fiable à mon goût. J'ai un client qui l'utilise beaucoup, si tu fais un checksum des tables (via MySQL hein, pas depuis l'OS) on a des hash différents pour chaque node... C'est juste flippant.

Par contre je n'ai toujours pas eu l'occasion de tester un cluster Galera, qui est nettement plus fiable sur le papier.

daevel : infogérance et conseil || moi

Page 1 2

Répondre

Vous ne pouvez pas participer au forum, car votre inscription n'a pas été validée. Pour vous faire valider en tant que Membre, cliquez ici.