Par exemple, ça parle de réplication, mais est ce que l'idée est d'avoir une réplication en temps réel (et donc synchrone) auquel cas les performances vont chuter si tu fait ça sur un site distant, ou d'avoir des trucs asynchrones et de la magie pour revenir quand ça explose ?
Il n'y a pas spécialement de discussion sur la volumétrie non plus ou la question du lien entre les sites.
Le type de données va aussi importer. L'utilisation de GlusterFS pour stocker des images de VM fait parti des cas supportés par le projet (vu que c'est des gros fichiers, ç'est assez performant), et le projet ovirt le supporte. Mais de la même façon, des gens placent le stockage en mode bloc dans Ceph.
Mais si le but est d'avoir des machines dont tu fait des snapshot, je pense que tu peux pas éviter d'aller dans la VM et faire des choses pour que les données sur le disque soit cohérentes.
J'ai par exemple du mal à voir comment une synchro des blocs ne va pas corrompre une base de données et une appli web si ça pête au mauvais moment, vu que c'est rarement atomique (sauf à tout mettre dans la base de données, et à avoir des transactions, mais je pense que pas grand monde vérifie ça, et qu'à choisir entre une appli qui va exploser sous un cas critique, et pas d'appli, les gens prennent l'appli quand même).
Du coup, si tu fait la redondance au niveau au dessus, tu as moins besoin au niveau en dessous.
Donc les besoins vont dépendre des applis. Est ce qu'il faut avoir de la HA automatique, ou remonter rapidement suffit ? Comment le systéme va devoir se débrouillé en mode dégradé ?
Pour reprendre l'appli d'exemple de toute à l'heure, une solution de stockage classique avec une base SQL répliqué suffirait, avec des frontends sans état, pas besoin de sortir des trucs complexes (pour peu que les VMs soit identiques)
Et sinon, on est en 2017, les archis à base de conteneurs ont le vent en poupe, et ont le bon gout de pousser à séparer données et codes, ce qui permet aussi de se focaliser sur ce qui AMHA importe, les données. Je dit pas que c'est une bonne idée, mais je pense que c'est pas déconnant de regarder. Et pas regarder docker tout nu, plus des choses comme kubernetes/openshift ou mesos, avec idéalement une stack supporté.
Et la partie "pas de java" me parait quand même restrictive et sans doute mal exprimé. Parce que je suis sur que pour certaines choses, y a sans doute d'autres languages qui vont faire pire que java (cough golang et rust pour du statique, ruby pour tirer 5T de deps), donc je suis sur qu'il y a plus précis comme demande.
# ça manque de données
Posté par Misc (site web personnel) . En réponse au journal FAI associatif / FDN / Hébergement et stockage. Évalué à 4.
Le draft manque AMHA d'info.
Par exemple, ça parle de réplication, mais est ce que l'idée est d'avoir une réplication en temps réel (et donc synchrone) auquel cas les performances vont chuter si tu fait ça sur un site distant, ou d'avoir des trucs asynchrones et de la magie pour revenir quand ça explose ?
Il n'y a pas spécialement de discussion sur la volumétrie non plus ou la question du lien entre les sites.
Le type de données va aussi importer. L'utilisation de GlusterFS pour stocker des images de VM fait parti des cas supportés par le projet (vu que c'est des gros fichiers, ç'est assez performant), et le projet ovirt le supporte. Mais de la même façon, des gens placent le stockage en mode bloc dans Ceph.
Mais si le but est d'avoir des machines dont tu fait des snapshot, je pense que tu peux pas éviter d'aller dans la VM et faire des choses pour que les données sur le disque soit cohérentes.
J'ai par exemple du mal à voir comment une synchro des blocs ne va pas corrompre une base de données et une appli web si ça pête au mauvais moment, vu que c'est rarement atomique (sauf à tout mettre dans la base de données, et à avoir des transactions, mais je pense que pas grand monde vérifie ça, et qu'à choisir entre une appli qui va exploser sous un cas critique, et pas d'appli, les gens prennent l'appli quand même).
Du coup, si tu fait la redondance au niveau au dessus, tu as moins besoin au niveau en dessous.
Donc les besoins vont dépendre des applis. Est ce qu'il faut avoir de la HA automatique, ou remonter rapidement suffit ? Comment le systéme va devoir se débrouillé en mode dégradé ?
Pour reprendre l'appli d'exemple de toute à l'heure, une solution de stockage classique avec une base SQL répliqué suffirait, avec des frontends sans état, pas besoin de sortir des trucs complexes (pour peu que les VMs soit identiques)
Et sinon, on est en 2017, les archis à base de conteneurs ont le vent en poupe, et ont le bon gout de pousser à séparer données et codes, ce qui permet aussi de se focaliser sur ce qui AMHA importe, les données. Je dit pas que c'est une bonne idée, mais je pense que c'est pas déconnant de regarder. Et pas regarder docker tout nu, plus des choses comme kubernetes/openshift ou mesos, avec idéalement une stack supporté.
Et la partie "pas de java" me parait quand même restrictive et sans doute mal exprimé. Parce que je suis sur que pour certaines choses, y a sans doute d'autres languages qui vont faire pire que java (cough golang et rust pour du statique, ruby pour tirer 5T de deps), donc je suis sur qu'il y a plus précis comme demande.