J'adhère pour Amazon. Par contre il me semble suboptimal de crawler plusieurs fois le web pour l'indexer. Mutualiser l'effort dans ce cas me semble pertinent.
Après je ne m'étais pas rendu compte que Google était devenu nul. Il me trouve toujours les messages d'erreur cryptique de certains outils utilisés par mes clients. Pour le reste, dans mon utilisation d'internet Google ne fait pas vraiment partie du paysage. Je vais sur les sites qui m'intéressent et quand je cherche quelque chose je passe souvent pas wikipédia puis de lien en lien.
J'y pense depuis un moment mais mon avis est que effectivement on ne peut plus lutter contre Google ou Amazon. Ces entreprises sont trop en avance pour être contrées. Par contre on pourrait les rendre publique. Mon idée serait de mondialiser , une nationalisation mais au niveau mondial, ces entreprises et les mettre sous l'égide d'une entité responsable dans le giron de l'ONU par exemple.
Certes l'ONU n'est pas la panacée mais ce serait un moindre mal et une nouvelle direction qui me semble importante.
Cette idée vient d'une conférence sur le déploiement de la paire de cuivre en France. Le type disait que en 5ans le déploiement avait était fait dans 100% des bâtiments français.
Quand je vois qu'on paye une fibre 'PRO' des centaines d'euros par mois en plein Boulogne Billancourt, je me dis que France Telecom aurait pu faire beaucoup mieux, il y a déjà longtemps.
oui les cpu nvidia sont bien supportés. La seule galère que j'ai eu c'est que les drivers pour les cartes h100 ne sont pas les mêmes que pour ma gtx de gamer et j'ai mis un moment à comprendre …
Qui n'est quand même pas si lointain que ça, EDF avait les moyens d'avoir sa propre it. Pourquoi avoir besoin d'amazon ? Que fait amazon que EDF ne pourrait pas faire ?
j'en suis arrivé aux même conclusions oui. Percona. Mais avec un backup à froid. Je n'ai pas encore suffisamment d'exp et donc de confiance pour me lancer dans des acrobaties surtout quand la doc dit :
mongodump and mongorestore cannot be part of a backup strategy for 4.2+ sharded clusters that have sharded transactions in progress, as backups created with mongodump do not maintain the atomicity guarantees of transactions across shards.
dans les 3/4 des clients dont je fais la prod, qui sont des pme on va dire avec une grosse douzaine de dev qui font les choix technique parce qu'en vrai il n'y a que des dev dans ces boites. Et la plupart pour pas dire la totalité sont des jeunes prestas de 25ans qui ne sont que de passage. Alors est ce que c'est maintenable ? Ce n'est pas la question. En vrai plus c'est pourri plus longtemps ils gardent leur mission. Et donc oui c'est mal géré.
Après j'ai passé pas mal de temps dans des très grosses boites et les problèmes étaient différents mais tout aussi pénible pour moi qui faisait de la prod. Vmware/Windows/apache/mysql ou Vmware/windows/websphere/oracle ? Non debian/python/postgres … J'ai finis pas me faire dégager :) Alors maintenant c'est moi qui comment qu'on fait :)
moi mon père il me parlait de cartes perforées, de fortran et il mettait son code au coffre le soir. :)
J'essaie juste de dire. Attendre, prendre son temps, soupeser les besoins, mettre les avantages et les inconvénients et ne pas réécrire la roue avant de mettre en prod des technos ingérables.
C'est surtout que les jeunes ont été éduqués par les vieux.
la on tombe sur le cœur du problème, la formation et dans mon cas le recrutement. Je ne dirais pas que les jeunes ont été mal éduqués par les vieux, je dirais plutôt que les jeunes n'ont pas été éduqué tout cours sur l'histoire de leur métier. En terme d'informatique je parle. Et puis l’adage qui dis "quand on sait faire on fait, quand on sait pas faire on enseigne" marche pas mal :) (blague tout ça, enseigner c'est avant tout la pédagogie. Pédagogie qu'un expert dans un domaine n'aura pas forcément etc etc)
Ayant énormément de mal à recruter je prend maintenant des jeunes en stage pendant leurs études et je les forme. J'en garde moins d'un quart chaque année. Et certaines années aucun.
Entre ceux qui sont là sans savoir pourquoi ils sont la, ceux qui veulent "devenir riche", ceux qui veulent pas parler aux clients, ceux qui ne veulent pas parler tout court, ceux qui veulent pas faire d'astreintes, ceux qui partent en vacances sans prévenir. C'est vraiment pas simple.
Ensuite j'entends tout à fait que aujourd'hui la relation au travail "des jeunes" est différentes de la mienne. Je n'ai pas de problème avec ça.
Bref le sujet c'était les backups :) par les jeunes c'était mieux avant, moi de mon temps etc.
Qu'il y ait des gens qui innovent c'est super et c'est tant mieux. Par contre moi qui dois faire tenir de la prod de plus en plus grosse avec des coûts de maintenance de plus en plus faible je préfère me reposer sur des technos stable, très stable. Par exemple debian et postgres.
Pour ceph j'ai attendu 5ans avant de le passer en prod. Pour kubernetes, 3 ans. Pour le framework js front pratiquement 10ans et pour celui que j'ai choisi (vuejs) 5ans.
Bref l'innovation c'est nécessaire. Passer en prod des produits hype et pas terminé c'est dangereux.
Apprendre du passé bien sûr, être persuadé que les difficultés d’hier sont exactement
les mêmes que celle d’aujourd’hui c’est vraiment être vieux con et ignorant.
Et me faire dire ce que je ne dis pas c'est … ?
Je ne dis pas que tout était mieux avant, que uniquement les anciennes technos sont bonnes. Sinon je n'aurais pas dans ma stack kubernetes, ceph ou kafka. Jamais de la vie.
Je dis simplement que pour faire des choix et surtout pour ne pas ré inventer cette satanée roue il est pertinent de regarder ce qui a été fait avant et qui fonctionne pour éviter de faire des mauvais choix. Par mauvais choix j'entends des choix basés sur des technos hype propulsé par une tonne de communique qui sont très souvent difficiles et donc très couteuses à maintenir en prod et rarement pertinente. Genre mongodb.
je suis surpris de voir que ce mot n'apparait pas dans les commentaires. En tant que responsable de la prod de plusieurs boites c'est la première chose à laquelle on réfléchit avant de choisir un produit.
Comment on le backup, on le restaure, on le monitore, on le réplique. Est-il possible de faire du PITR ? Il est nécessaire de pouvoir faire tout ça facilement.
Par exemple ces derniers temps je récupère des clients avec mongodb et microservice en js.
Question : comment on backup mongodb. Eh bien on peut pas de ce que j'en comprends, enfin si on peut mais c'est pas consistant. Alors la nuit on passe le base en read only, on snapshot les fs, on repasse en read write et on copie les données sur le serveur de backup. Et au lieu d'avoir un seul fichier, j'en ai autant que de noeud de la base. J'ai l'impression de retourner en 2004 avec mysql …
Mais alors, pourquoi mongodb ? Qui y a-t-il comme données dans cette base pour nécessiter un mongodb ? Une simple base utilisateur qui permet l'authentification à l'application en question. Les dev de cette application ont donc réécrit ldap en js.
Point vieux con : les jeunes n'ont plus aucune culture en informatique, ils ne connaissent que la surface et les trucs à la mode. Jamais il ne se disent que avant eux on a déjà résolu tout ces problèmes. L'arrivée de chatgp n'ajoute rien de bon à tout ca.
Bref pour terminer : le bon outil pour le bon besoin. C'est primordial. Quiconque a déjà bricolé avec un couteau suisse comprendra.
je rebondis sur la partie IA et notebooks Jupyter. Depuis 2015 je bosse avec des "data scientist". Leur principal point commun c'est d'utiliser et donc de livrer leur code sous forme de notebooks Jupyter. J'avais donc, à priori, deux voie pour passer leurs livrables en production. Soit apprendre à des ds à coder correctement et à livrer du code que l'on peut directement mettre en prod (ils adorent les csv avec des chemins en dur …).
On ne peut pas dire que ça a échoué, on dira que ça n'a pas marché. Alors on a décidé de prendre des dev pyton pour faire de la datascience. Ça a marché un temps. Mais depuis deux ans on fabrique nos propres algo de traitement du langage et là ça coince. Un dev python ne sait plus faire.
Résultat des courses j'ai deux équipes une de ds qui nous livre du code pas vraiment utilisable et une équipe de dev python qui ré-écris toute ou partie du code pour la faire rentrer sur la plateforme.
Pour limiter les réécritures on essaie de packager un maximum de chose. En particulier nos structures de données et l'accès aux dites données, pour enfin ne plus voir de chemin en dur vers un csv …
Et je termine donc : nous utilisons pyenv, pdm et docker pour le dev, comme ça on isole bien notre env dans docker. Et gitlab pour la publication de nos packages.
je ne crois pas l'avoir vu mais :b string avec string étant tout ou partie d'un nom de fichier permet facilement de circuler entre les buffers. Ajouter :vs :sp pour cinder l'affichage et je n'ai besoin de rien de plus. A oui :e file pour ouvrir un fichier.
C'est une question difficile. Et encore mon fils est petit. Il n'a que 9ans. Dès le collège ça deviendra encore plus compliqué parce que pour le moment il n'y a pas dans son école d'interaction sociale via les réseaux.
Pour le moment j'ai réussi à faire en sorte que l'écran, quel qu'il soit (tv, console, pc, téléphone) soit une activité que l'on fait ensemble. On choisit un film, une série, un jeu vidéo et on le fait ensemble. On joue à ingress ou à pokémon go sur le téléphone mais dehors.
De mon point de vue le problème n'est pas l'écran en lui-même mais plutôt ce que l'on en fait. Si c'est pour les mettre devant loft story, tfou ou jouer à gta à 10ans parce que comme ca ils sont tranquilles c'est non. Si c'est pour faire un truc ensemble et de leur âge (it takes two sur ps4, porco rosso ou astérix et cléopatre) c'est oui.
Quand il joue seul il fait du lego, du découpage, il invente des jeux, crée des labyrinthes bref, quand il est seul il n'y a pas d'écran.
Seule entorse, une fois la table mise il a 20min pour regarder un épisode de pokémon pendant que le repas cuit.
[^] # Re: Quelques explications
Posté par oau . En réponse au lien coup de force de broadcom sur les licences vmware : appel à la commission européenne. Évalué à 7 (+6/-0).
c'est bien fait pour eux ? Oui je pense, même si c'est pas très charitable ça me fait bien rigoler.
[^] # Re: Je suis pas un grand fan pourtant
Posté par oau . En réponse au lien En fait, l'IA ne sert à rien. Évalué à 6 (+5/-0).
Ca reste tout de même une quantité stratosphérique d'énergie consommée pour pas souvent grand-chose.
[^] # Re: service publique
Posté par oau . En réponse au journal Traduction : Payer ne permet pas d'échapper aux monopoles. Évalué à 3 (+2/-0).
J'adhère pour Amazon. Par contre il me semble suboptimal de crawler plusieurs fois le web pour l'indexer. Mutualiser l'effort dans ce cas me semble pertinent.
Après je ne m'étais pas rendu compte que Google était devenu nul. Il me trouve toujours les messages d'erreur cryptique de certains outils utilisés par mes clients. Pour le reste, dans mon utilisation d'internet Google ne fait pas vraiment partie du paysage. Je vais sur les sites qui m'intéressent et quand je cherche quelque chose je passe souvent pas wikipédia puis de lien en lien.
# service publique
Posté par oau . En réponse au journal Traduction : Payer ne permet pas d'échapper aux monopoles. Évalué à 3 (+2/-0).
Bonjour,
J'y pense depuis un moment mais mon avis est que effectivement on ne peut plus lutter contre Google ou Amazon. Ces entreprises sont trop en avance pour être contrées. Par contre on pourrait les rendre publique. Mon idée serait de mondialiser , une nationalisation mais au niveau mondial, ces entreprises et les mettre sous l'égide d'une entité responsable dans le giron de l'ONU par exemple.
Certes l'ONU n'est pas la panacée mais ce serait un moindre mal et une nouvelle direction qui me semble importante.
Cette idée vient d'une conférence sur le déploiement de la paire de cuivre en France. Le type disait que en 5ans le déploiement avait était fait dans 100% des bâtiments français.
Quand je vois qu'on paye une fibre 'PRO' des centaines d'euros par mois en plein Boulogne Billancourt, je me dis que France Telecom aurait pu faire beaucoup mieux, il y a déjà longtemps.
oau
[^] # Re: Support des GPU
Posté par oau . En réponse au journal Introduction pratique aux grands modèles de langage / LLM. Évalué à 2 (+1/-0).
oui les cpu nvidia sont bien supportés. La seule galère que j'ai eu c'est que les drivers pour les cartes h100 ne sont pas les mêmes que pour ma gtx de gamer et j'ai mis un moment à comprendre …
# de mon temps
Posté par oau . En réponse au lien EDF - contrat avec Amazon pour gérer la planification de la maintenance des centrales nucléaires. Évalué à 1 (+0/-0).
Qui n'est quand même pas si lointain que ça, EDF avait les moyens d'avoir sa propre it. Pourquoi avoir besoin d'amazon ? Que fait amazon que EDF ne pourrait pas faire ?
[^] # Re: backup ?
Posté par oau . En réponse au journal Tour d'horizon de l'état des bases NoSQL. Évalué à 3.
j'en suis arrivé aux même conclusions oui. Percona. Mais avec un backup à froid. Je n'ai pas encore suffisamment d'exp et donc de confiance pour me lancer dans des acrobaties surtout quand la doc dit :
https://www.mongodb.com/docs/manual/core/backups/#back-up-with-mongodump
le reste de la description fait un peu flipper je trouve.
[^] # Re: backup ?
Posté par oau . En réponse au journal Tour d'horizon de l'état des bases NoSQL. Évalué à 2. Dernière modification le 25 décembre 2023 à 18:47.
hello
dans les 3/4 des clients dont je fais la prod, qui sont des pme on va dire avec une grosse douzaine de dev qui font les choix technique parce qu'en vrai il n'y a que des dev dans ces boites. Et la plupart pour pas dire la totalité sont des jeunes prestas de 25ans qui ne sont que de passage. Alors est ce que c'est maintenable ? Ce n'est pas la question. En vrai plus c'est pourri plus longtemps ils gardent leur mission. Et donc oui c'est mal géré.
Après j'ai passé pas mal de temps dans des très grosses boites et les problèmes étaient différents mais tout aussi pénible pour moi qui faisait de la prod. Vmware/Windows/apache/mysql ou Vmware/windows/websphere/oracle ? Non debian/python/postgres … J'ai finis pas me faire dégager :) Alors maintenant c'est moi qui comment qu'on fait :)
[^] # Re: backup ?
Posté par oau . En réponse au journal Tour d'horizon de l'état des bases NoSQL. Évalué à 1.
moi mon père il me parlait de cartes perforées, de fortran et il mettait son code au coffre le soir. :)
J'essaie juste de dire. Attendre, prendre son temps, soupeser les besoins, mettre les avantages et les inconvénients et ne pas réécrire la roue avant de mettre en prod des technos ingérables.
[^] # Re: backup ?
Posté par oau . En réponse au journal Tour d'horizon de l'état des bases NoSQL. Évalué à 3.
la on tombe sur le cœur du problème, la formation et dans mon cas le recrutement. Je ne dirais pas que les jeunes ont été mal éduqués par les vieux, je dirais plutôt que les jeunes n'ont pas été éduqué tout cours sur l'histoire de leur métier. En terme d'informatique je parle. Et puis l’adage qui dis "quand on sait faire on fait, quand on sait pas faire on enseigne" marche pas mal :) (blague tout ça, enseigner c'est avant tout la pédagogie. Pédagogie qu'un expert dans un domaine n'aura pas forcément etc etc)
Ayant énormément de mal à recruter je prend maintenant des jeunes en stage pendant leurs études et je les forme. J'en garde moins d'un quart chaque année. Et certaines années aucun.
Entre ceux qui sont là sans savoir pourquoi ils sont la, ceux qui veulent "devenir riche", ceux qui veulent pas parler aux clients, ceux qui ne veulent pas parler tout court, ceux qui veulent pas faire d'astreintes, ceux qui partent en vacances sans prévenir. C'est vraiment pas simple.
Ensuite j'entends tout à fait que aujourd'hui la relation au travail "des jeunes" est différentes de la mienne. Je n'ai pas de problème avec ça.
Bref le sujet c'était les backups :) par les jeunes c'était mieux avant, moi de mon temps etc.
[^] # Re: backup ?
Posté par oau . En réponse au journal Tour d'horizon de l'état des bases NoSQL. Évalué à 6.
Qu'il y ait des gens qui innovent c'est super et c'est tant mieux. Par contre moi qui dois faire tenir de la prod de plus en plus grosse avec des coûts de maintenance de plus en plus faible je préfère me reposer sur des technos stable, très stable. Par exemple debian et postgres.
Pour ceph j'ai attendu 5ans avant de le passer en prod. Pour kubernetes, 3 ans. Pour le framework js front pratiquement 10ans et pour celui que j'ai choisi (vuejs) 5ans.
Bref l'innovation c'est nécessaire. Passer en prod des produits hype et pas terminé c'est dangereux.
[^] # Re: backup ?
Posté par oau . En réponse au journal Tour d'horizon de l'état des bases NoSQL. Évalué à 4.
Et me faire dire ce que je ne dis pas c'est … ?
Je ne dis pas que tout était mieux avant, que uniquement les anciennes technos sont bonnes. Sinon je n'aurais pas dans ma stack kubernetes, ceph ou kafka. Jamais de la vie.
Je dis simplement que pour faire des choix et surtout pour ne pas ré inventer cette satanée roue il est pertinent de regarder ce qui a été fait avant et qui fonctionne pour éviter de faire des mauvais choix. Par mauvais choix j'entends des choix basés sur des technos hype propulsé par une tonne de communique qui sont très souvent difficiles et donc très couteuses à maintenir en prod et rarement pertinente. Genre mongodb.
# backup ?
Posté par oau . En réponse au journal Tour d'horizon de l'état des bases NoSQL. Évalué à 10.
bonjour,
je suis surpris de voir que ce mot n'apparait pas dans les commentaires. En tant que responsable de la prod de plusieurs boites c'est la première chose à laquelle on réfléchit avant de choisir un produit.
Comment on le backup, on le restaure, on le monitore, on le réplique. Est-il possible de faire du PITR ? Il est nécessaire de pouvoir faire tout ça facilement.
Par exemple ces derniers temps je récupère des clients avec mongodb et microservice en js.
Question : comment on backup mongodb. Eh bien on peut pas de ce que j'en comprends, enfin si on peut mais c'est pas consistant. Alors la nuit on passe le base en read only, on snapshot les fs, on repasse en read write et on copie les données sur le serveur de backup. Et au lieu d'avoir un seul fichier, j'en ai autant que de noeud de la base. J'ai l'impression de retourner en 2004 avec mysql …
Mais alors, pourquoi mongodb ? Qui y a-t-il comme données dans cette base pour nécessiter un mongodb ? Une simple base utilisateur qui permet l'authentification à l'application en question. Les dev de cette application ont donc réécrit ldap en js.
Point vieux con : les jeunes n'ont plus aucune culture en informatique, ils ne connaissent que la surface et les trucs à la mode. Jamais il ne se disent que avant eux on a déjà résolu tout ces problèmes. L'arrivée de chatgp n'ajoute rien de bon à tout ca.
Bref pour terminer : le bon outil pour le bon besoin. C'est primordial. Quiconque a déjà bricolé avec un couteau suisse comprendra.
[^] # Re: Avis d'un utilisateur / dev
Posté par oau . En réponse à la dépêche L'installation et la distribution de paquets Python (2/4). Évalué à 5. Dernière modification le 24 décembre 2023 à 11:06.
hello
je rebondis sur la partie IA et notebooks Jupyter. Depuis 2015 je bosse avec des "data scientist". Leur principal point commun c'est d'utiliser et donc de livrer leur code sous forme de notebooks Jupyter. J'avais donc, à priori, deux voie pour passer leurs livrables en production. Soit apprendre à des ds à coder correctement et à livrer du code que l'on peut directement mettre en prod (ils adorent les csv avec des chemins en dur …).
On ne peut pas dire que ça a échoué, on dira que ça n'a pas marché. Alors on a décidé de prendre des dev pyton pour faire de la datascience. Ça a marché un temps. Mais depuis deux ans on fabrique nos propres algo de traitement du langage et là ça coince. Un dev python ne sait plus faire.
Résultat des courses j'ai deux équipes une de ds qui nous livre du code pas vraiment utilisable et une équipe de dev python qui ré-écris toute ou partie du code pour la faire rentrer sur la plateforme.
Pour limiter les réécritures on essaie de packager un maximum de chose. En particulier nos structures de données et l'accès aux dites données, pour enfin ne plus voir de chemin en dur vers un csv …
Et je termine donc : nous utilisons pyenv, pdm et docker pour le dev, comme ça on isole bien notre env dans docker. Et gitlab pour la publication de nos packages.
[^] # Re: Ajout
Posté par oau . En réponse au journal travailler sur de nombreux fichiers avec Vim et NeoVim, sur une seule vue. Évalué à 3.
Je code avec vi depuis 1997. Aujourd'hui c'est même mon métier et ça marche très bien. Python/Django/vuejs/k8s.
Je ne manque de rien 🤗
# Ajout
Posté par oau . En réponse au journal travailler sur de nombreux fichiers avec Vim et NeoVim, sur une seule vue. Évalué à 2.
hello,
je ne crois pas l'avoir vu mais :b string avec string étant tout ou partie d'un nom de fichier permet facilement de circuler entre les buffers. Ajouter :vs :sp pour cinder l'affichage et je n'ai besoin de rien de plus. A oui :e file pour ouvrir un fichier.
vim c'est bien pour coder mangez en :)
# Pas simple
Posté par oau . En réponse au sondage Les zécrans de vos enfants. Évalué à 6.
C'est une question difficile. Et encore mon fils est petit. Il n'a que 9ans. Dès le collège ça deviendra encore plus compliqué parce que pour le moment il n'y a pas dans son école d'interaction sociale via les réseaux.
Pour le moment j'ai réussi à faire en sorte que l'écran, quel qu'il soit (tv, console, pc, téléphone) soit une activité que l'on fait ensemble. On choisit un film, une série, un jeu vidéo et on le fait ensemble. On joue à ingress ou à pokémon go sur le téléphone mais dehors.
De mon point de vue le problème n'est pas l'écran en lui-même mais plutôt ce que l'on en fait. Si c'est pour les mettre devant loft story, tfou ou jouer à gta à 10ans parce que comme ca ils sont tranquilles c'est non. Si c'est pour faire un truc ensemble et de leur âge (it takes two sur ps4, porco rosso ou astérix et cléopatre) c'est oui.
Quand il joue seul il fait du lego, du découpage, il invente des jeux, crée des labyrinthes bref, quand il est seul il n'y a pas d'écran.
Seule entorse, une fois la table mise il a 20min pour regarder un épisode de pokémon pendant que le repas cuit.
# Merci
Posté par oau . En réponse au journal RPCDataloader: chargement et pré-traitement de données distribué pour l'IA. Évalué à 1.
Pour la découverte, ici on utilise knative et Kafka pour faire ça. J'avoue ça juste marche parfaitement. Mais je vais quand même regarder ça. Merci.
[^] # Re: Vim
Posté par oau . En réponse au journal VSCodium & support python : pyright. Évalué à 3.
Vim c'est bien
[^] # Re: c'est pour ca que
Posté par oau . En réponse au journal Comment j'ai foutu en l'air une partie de notre prod (et comment on l'a remise sur pieds). Évalué à 3.
c'était le sens de ces mots :)
# c'est pour ca que
Posté par oau . En réponse au journal Comment j'ai foutu en l'air une partie de notre prod (et comment on l'a remise sur pieds). Évalué à 8.
et on teste les backup
ceph + borg
[^] # Re: Alternative ?
Posté par oau . En réponse au journal scratch_manager: gestionnaire de mise en cache de jeux de données. Évalué à 1. Dernière modification le 17 décembre 2022 à 19:11.
Ceph , cephfs et S3 c'est excellent pour faire ça. J'ai le même genre de problèmatique que j'ai résolu avec une stack ceph + k8s + kafka.
Effectivement ça demande des compétences mais quand il faut passer en production un pipeline de traitement de données il faut des compétences.
[^] # Re: Réponse
Posté par oau . En réponse au journal Adieu Grammalecte ?. Évalué à 2.
des bisous des bisous des bisous :)
[^] # Re: cloud baremetal
Posté par oau . En réponse au journal Le cloud ça scale bien. Évalué à 1.
Pas sûr 3 DC dans 3 zones différentes. Si ta baie cramé tu perds tout.
[^] # Re: cloud baremetal
Posté par oau . En réponse au journal Le cloud ça scale bien. Évalué à 2.
Certes mais ton disque que tu exposes en iscsi est sur une machine. Si cette machine disparait tu perds ton disque.
L'avantage de ceph est que ton disque (rbd, nfs, iscsi, samba, whatever) et toujours disponible tant que ton cluster fonctionne.
Avec le setup qu'on fait on peut perdre les deux tiers des serveurs sans perdre de données. Chaque block est répliqué trois fois.