Bonjour,
Je poste ici car je ne sais pas où poster. Existe-t-il un espace sur le forum ou ailleurs sur le site de OVH où on pourrait avoir des conseils en architecture? Un endroit où on dirait: voila ce que j'ai comme projet , qu'est-ce que vous me conseillez comme architecture , en supposant que j'implémente toute ma solution chez OVH? Car moi je suis un peu noyé dans toutes ces solutions, je ne sais pas par quel bout les prendre.
J'imagine que si cela existe ce n'est peut-être pas gratuit, mais c'est à voir.
Pour vous en dire un peu plus, j'ai le projet suivant:
- une appli sur Smartphone,
- tant que le réseau 3G n'est pas disponible, chaque utilisateur peu travailler en local sur le Smartphone et entrer des données qui seront stockées sur le Smartphone,
- dès que le réseau est accessible, ou à la demande de l'utilisateur, l'appli se connecte à un espace web (où l'utilisateur aura un compte) et fait quelque chose de l'ordre de la sauvegarde ou de la réplication sur le serveur,
- d'autre part, chaque utilisateur peut se connecter sur l'espace web, sur son compte, et faire du back-office, voire du front-office, c'est-à-dire la même chose que ce qu'il fait avec l'appli Smartphone.
En volumétrie on va dire qu'il y a moins de 500Mo de storage sur le serveur et sur le Smartphone, par utilisateur.
Il y aurait donc un site, sur lequel se trouverait les espaces client dont je parle plus haut, mais aussi où on pourrait télécharger l'appli Smartphone. Ce site serait dans un premier temps déployé en français, avec un nom de domaine en .fr et .com, mais plus tard en anglais, allemand et espagnol, avec les extensions correspondantes (y compris .us pour l'anglais, et .ca pour le français, etc).
On peut imaginer que ce service soit payant. L'appli Smartphone est développée sous Android Studio.
Je ne sais pas si c'est très clair, que me conseillez-vous comme solution pour le serveur?
La vraie question est plutôt de savoir le nombre d'utilisateur là dessus. Si ça sera du linux / windows. Besoin de haute disponibilité.
Après en fonction de ces infos ben c'est assez simple.
Les VPS c'est l'entrée de gamme. Puis les public cloud, puis les serveurs dédiés… Eventuellement le dedicated cloud derrière.
La vraie question est plutôt de savoir le nombre d'utilisateur là dessus.
Potentiellement il peut y avoir autant d'utilisateur qu'un gros site de commerce comme La Redoute, et je n'ai aucune idée de combien ça en fait, mais c'est de cette ordre en terme de diffusion : diffusion nationale. Et pour chiffrer la diffusion dans les 3 autres pays disons qu'on multiplierait par 4.
Si ça sera du linux / windows.
Ce serait du linux.
Besoin de haute disponibilité.
Disponibilité moyenne, je dirais. Je pense qu'il faudrait un dispositif de réinstanciation et de redémarrage en cas de crash, mais par contre ce n'est pas de la haute disponibilité, l'utilisateur peut supporter une indisponibilité temporaire du serveur, car il peut travailler en local.
Après en fonction de ces infos ben c'est assez simple.
Les VPS c'est l'entrée de gamme. Puis les public cloud, puis les serveurs dédiés... Eventuellement le dedicated cloud derrière.
Parmi ces formules, laquelle proposent une réinstanciation en cas de crash?
Et quelle solution de stockage?
Qu'appelez vous réinstanciation ?
Dans tous les cas vu la masse d'utilisateurs prévus sur une telle infra il faut quelque chose de scalable…
C'est quoi l'archi logicielle derrière ? Car ça va déterminer ce qu'il est possible de faire.
Qu'appelez vous réinstanciation ?
Le fait que si une instance crash, il y a une autre instance qui se crée et qui part de là où était celle qui a crashé. Il me semble que ce genre de chose existe, je ne sais pas si il faut parler d'instance ou de serveur ou d'image, c'est assez flou dans mon esprit, mais je veux dire : qu'en cas de crash, il n'y ait pas d'interruption de service. Je ne sais pas sur quelles solutions OVH on peut avoir cela en standard, ou à défaut l'implementer : VPS SSD , VPS Cloud, autre?
C'est quoi l'archi logicielle derrière ? Car ça va déterminer ce qu'il est possible de faire.
Ce n'est pas encore très clair dans mon esprit, mais j'ai l'impression qu'on pourrait utiliser un CMS basique, en tout cas ce serait du Php+MySql
Il n'y pas de magie avec une instance qui se recrée toute seule…
Dans le scénario actuel pour ma part je partirai sur 3 serveurs dédié pour faire un cluster mysql et un nas pour stocker les fichiers…
Mais ça demande du travail pour gérer ce genre de choses…
Il n'y pas de magie avec une instance qui se recrée toute seule...
Il me semblait bien que cela existait : on parle dans la com OVH de "non interruption du service en cas de crash", je ne sais plus à propos de quelle solution ils en parlent mais ça existe. Et nulle besoin n'avoir recours à la magie, il suffit qu'une seconde instance soit répliquée (sur un autre serveur) en permanence à partir de la première , prête à prendre la suite en cas de crash de la première.
Bien sur ce n'est pas gratuit, mais bon je m'en passerai, car dans le cas présent l'utilisateur peut continuer à travailler en local en cas d'interruption du service.
C'est possible oui, dans des systèmes virtualisés.
A base de proxmox ou de vmware.
Le problème sur ce genre de système c'est qu'on passe par du stockage réseau et la stabilité des performances pose régulièrement problème.
Et pour en revenir à la problématique de base il faut voir si l'appli sera bien optimisée ou si il va y avoir beaucoup d'appels à la bdd… Pour savoir si il faut du scalable ou si un serveur en solo suffit.
Dans tous les cas perso je partirai sur un serveur dédié, les instances "cloud" posent trop de problèmes. Tout ça pour avoir de la HA qui au final n'est pas si souvent nécessaire.
Ok pour le serveur dédié, je pense que tu as raison, c'est plus sur et on maîtrise mieux.
En ce qui concerne l'optimisation je n'y ai pas réfléchi, j'y réfléchirai, donc là, ce que j'écris ce n'est pas dans le marbre : peut-être qu'il suffirait de brider les échanges entre Smartphone et le serveur, de réserver des plages horaires, on répartirait les utilisateurs par plages pendant lesquelles le smartphone pourrait répliquer sur le serveur.
Mais après il ne faut pas qu'un utilisateur s'amuse à faire du front office par le web alors que son Smartphone n'a pas pu répliquer, et je ne vois pas comment le serveur peut savoir si le Smartphone a pu répliquer ou pas, s'il n'a pas eu d'info ça peut très bien être parce que l'utilisateur n'en a pas rentré sur son Smartphone.
J'y réfléchirai, merci de ton aide.
En fait il faudrait que je m'inspire de cas existant déjà: ce que je veux faire n'est pas très éloigné d'un carnet d'adresses: existant sur le Smartphone, créé sur le Smartphone et répliqué sur serveur. C'est comparable et termes de volume de stockage. En terme d'I/O c'est peut-être plus volumineux, mais genre 4 à 10 fois quelque chose qui de toutes façons n'est pas très gros par utilisateurs.
Après il peut y avoir beaucoup d'utilisateurs. Il faudrait que je vois l'archi d'un carnet d'adresse comme celui d'Orange ou autre.
Après côté applicatif ce n'est pas mon domaine. Tout ce que je sais c'est qu'il faut surtout éviter d'interroger MySQL. Moins on l'interroge mieux on se porte.
Par conséquent il faut gérer les choses via du cache (en ram ou se forme de petits fichiers) autant que possible.
Le cas concret c'est une requete select qui donnera 99% du temps la même réponse. Là il faut stocker la réponse ailleurs (petit fichier en ramdisk ou sur ssd, memcache, …). Et penser à supprimer ce cache en cas de mise à jour de l'enregistrement source. L'usage d'un CDN peux aider aussi, mais uniquement pour les données qui ne bougent pas et sont communes à tout le monde (.css, images, …).
A la limite pour tester ton appli en mode dev je partirai sur un petit VPS. Puis après bascule sur un dédié pour la mise en prod.
Car difficile de savoir comment tout ceci va se comporter tant que l'appli n'a pas été codée.
Ok merci pour tes conseils. Peut-on faire du ramdisk sur les VPS?
oui c'est possible.
A mon avis démarre sur du petit, au moins le temps du développement.
Ensuite pour de la forte charge le dédié est recommandé.
En cas de MySQL il est recommandé d'utiliser des tables innodb pour pouvoir faire du clustering par la suite.
tables innodb
Dans MySql 5.5 c'est le défaut, je viens de le voir sur Wikipedia, effectivement c'est bien ce qu'il m'avait semblé voir sur les VPS notamment (où on peut aller voir comment est implémenté la base MySql en termes de fichiers).
clustering
Je suppose que tu parles de data clustering (et non pas de grappe de serveurs) : j'ai regardé à quoi cela correspondait, j'avoue que je ne saisie pas bien : c'est différent de la persistance objet? Parce là je verrais l’opportunité, mais pour le data clustering je ne vois pas.
Le clustering consiste à avoir au moins 3 serveurs qui se répliquent entres eux.
Pour pouvoir répartir la charge.
Pour assurer de la tolérance de panne.
Pour être "scalable" facilement en ajoutant des serveurs au cluster.
Uniquement valable si 1 seul serveur n'est pas suffisant pour gérer ton appli et absorber la charge.