si ce n'est le pricing pas toujours évident à suivre et prévoir.
Et c'est rien de le dire. A chaque fois c'est la surprise pour mes clients en fin de mois. Avant il fallait être chaman pour faire marcher Windows maintenant il faut être chaman pour prévoir ta facture de gaz (gce, aws, azur).
oui désolé il était un petit peu tôt il eut été préférable de donner un peu plus d'explication et de spécifier que je n'ai rien à voir avec cette entreprise si ce n'est que j'en suis un client satisfait et que le repeuplement des campagnes est un peu mon dada :) (et que mes phrases sont bien trop longues).
Repeuplement qui me semble possible via la création d'espace de travail commun. Là ou je suis j'ai des comptables, une paysagiste, des éleveurs d'abeilles, un spécialiste de la sdram en embarqué, une formatrice en sécurité agricole, des infirmières, une spécialiste de la prévision météo dans une entreprise qui fabrique des éoliennes, un vendeur de poutre en béton et c'est très enrichissant.
je voudrais partager mon expérience et mettre un petit bémol au télé travail.
C'est clair que c'est vraiment super. J'ai commencé à télétravailler en 2009. J'étais célibataire, au bord de la mer et dans ma ville natale. J'y ai retrouvé mes potes. J'ai vraiment passé des années super.
Puis j'ai déménagé dans un nouvel endroit que je n'aime pas trop, j'ai maintenant une famille. Pendant deux ans j'ai bossé seul de la maison. Et bien ça a été la grosse déprime.
Aujourd'hui je me suis trouvé un bureau dans un espace de coworking et c'est vraiment le bon compromis. Je fréquente des gens mais ne bosse pas avec. Donc pas de tension et uniquement les bon cotés. J'ai les 15min de changement ce contexte le matin et le soir. Et j'organise ma journée comme je l'entend.
et donc ? il faudrait que j'accepte que toutes mes données de santé soient sous le joug de multinationales sur lesquels je n'ai aucun pouvoir démocratique ? bah non.
Et ça vaut pour tout ces milliardaires qui se pensent au dessus des autres parce qu'ils sont riches (Tu te crois supérieur parce que t'es mon supérieur ? - stupeflip) et qui s'octroient le droit de rendre des miettes de ce qu'ils ont volé à coup de com sur les vaccins, les recherches, leur participation à l'opensource (ahahahah …) etc. « Voler en grand et restituer en petit, c’est la philanthropie » (Paul Lafargue). Vivre en société c'est accepter de partager. Vivre en démocratie c'est accepter d'avoir un pouvoir démocratique sur les acteurs de la société. Ces gens la ont le plus besoin d'état pour les protéger et les rendre riche mais n'acceptent ni de partager, ni de contrôle démocratique. Au final ça finira mal. Pour eux.
"On prépare vos menus, on enlève vos ordures, on vous relie par téléphone, on conduit vos ambulances, on vous protège pendant votre sommeil. Jouez pas aux cons avec nous." Tyler durden.
merci beaucoup pour ces informations. J'ai toujours navigué avec firefox et un bloqueur de pub. (Adblock avant, Ublock origin aujourd'hui). Je ne comprend pas comment les gens peuvent accepter ce harcèlement. Ils ont probablement l'habitude. Personnellement la pub me rend malade. Le peu de temps que je passe dans le métro parisien me révulse, je ne regarde plus la tv autre que arte simplement parce qu'il n'y a pas de pub. Pareil pour la radio. Je n'écoute que france culture parce qu'il n'y a pas de pub. J'ai d'ailleurs découvert pendant les grèves de radio france les "autres radios". Le choc …. je n'étais pas prêt.
Posté par oau .
En réponse à la dépêche Harbor 2.0.
Évalué à 2.
oui pardon c'est l'outils de bench rbd qui vient avec ceph.
ceph osd pool create scbench 128 128
ceph osd pool set scbench size 2
ceph osd pool set scbench min_size 2
rados bench -p scbench 30 write --no-cleanup
rados bench -t 32 -p scbench 30 seq
rados bench -t 32 -p scbench 30 rand
ceph osd pool delete scbench scbench --yes-i-really-really-mean-it
Pour les cartes raid oui en avoir une avec une batterie est bien sur un plus. Mais dans mon cas une carte raid c'est 57€ HT par mois de plus. C'est à dire 50% de plus par node. Je n'ai pas les moyens et surtout je n'en ai pas le besoin vu mes mes gros I/O sont fait en local directement sur les nvme.
Personne n'a encore écrit de scheduler "CFQ" pour le réseau ? Il n'y a rien la dessus dans les cgroup ?
ça discute pas mal sur la ML sur le sujet ces derniers temps. Je dirais que non parce que pour le moment ce n'est pas la piste prise. En gros les monitor discutent avec les osd sur le même canal que les données du cluster. Sur un cluster très chargé avec beaucoup de discussion entre les osd, le message de supervision des monitors peut mettre plusieurs minutes à revenir. Ce qui a pour effet de sortir l'osd du cluster et de lancer une rééquilibrage les données à travers le cluster, donc de le charger encore plus etc.
Posté par oau .
En réponse à la dépêche Harbor 2.0.
Évalué à 1.
certes. Mais tu compares deux choses qui n'ont rien à voir. Entre un nvme en local et un fs distribué bien sur que tu n'as pas les mêmes performances. Surtout avec un réseau à 2Gbps. C'est pour cette raison que mes pg tourne en local. Mais j'ai retrouvé mes premiers bench sur ma plateforme actuelle avant qu'elle ne passe en production.
Et pgbench me donnait 355 transaction per second sur le ceph
Voici un test sur ma préprop qui est au bureau. Avec 3 noeuds, 6 osd ssd. Mais surtout un réseau de 10Gbps en fibre. Qui fait donc bien 10Gbps.
Voisi le résultat en écriture avec un réplica de 2 ou j'ai un réplica de 3 en prod:
Total time run: 30.1047
Total writes made: 4503
Write size: 4194304
Object size: 4194304
Bandwidth (MB/sec): 598.311
Stddev Bandwidth: 164.823
Max bandwidth (MB/sec): 916
Min bandwidth (MB/sec): 416
Average IOPS: 149
Stddev IOPS: 41.2057
Max IOPS: 229
Min IOPS: 104
Average Latency(s): 0.106944
Stddev Latency(s): 0.0585435
Max latency(s): 0.45911
Min latency(s): 0.0203194
En lecture séquentielle
Total time run: 16.2453
Total reads made: 4503
Read size: 4194304
Object size: 4194304
Bandwidth (MB/sec): 1108.75
Average IOPS: 277
Stddev IOPS: 5.1316
Max IOPS: 287
Min IOPS: 270
Average Latency(s): 0.113968
Max latency(s): 0.362494
Min latency(s): 0.02719
En lecture aléatoire
Total time run: 30.1095
Total reads made: 8357
Read size: 4194304
Object size: 4194304
Bandwidth (MB/sec): 1110.21
Average IOPS: 277
Stddev IOPS: 10.3682
Max IOPS: 290
Min IOPS: 232
Average Latency(s): 0.113859
Max latency(s): 0.461317
Min latency(s): 0.0280363
On voit bien qu'on est limité par la bande passante du réseau.
Par contre une dernière chose qui peut potentiellement poser problème. Un client qui fait vraiment de très très gros IO sur un cluster peut totalement l'écrouler et pour le moment il n'y a pas vraiment de parade. Si ce n'est de tuer le dit client.
Posté par oau .
En réponse à la dépêche Harbor 2.0.
Évalué à 1.
depuis 2014 les choses ont bien changé :
petit bench de mon cluster. 7 nodes avec des ssd de 1to et un lien de 2Gbps entre chaque. Sur chaque nodes tourne ceph mais aussi ma prod k8s
montage et formatage de l'image ceph.
rbd map kube/test
mkfs.ext4 /dev/rbd1
mount /dev/rbd1 /mnt/
Un petit dd dedans pour les perf en écriture :
dd if=/dev/zero of=test bs=8192k count=1000 oflag=direct
1000+0 records in
1000+0 records out
8388608000 bytes (8.4 GB, 7.8 GiB) copied, 71.8563 s, 117 MB/s
Les performances de ceph dépendent clairement du réseau. Plus gros sera le réseau plus ca ira vite. Il faut aussi bien faire attention au disques choisis.
Posté par oau .
En réponse à la dépêche Harbor 2.0.
Évalué à 1.
Je pense qu’on s’est mal compris. Le posgresql en sus qui tourne dans ceph et qui est un replica de la production qui tourne sur des disques en local n’est là que pour avoir la possibilité d’en faire un snapshot.
Mais tout est géré par k8s. Aussi bien le cluster de postgres de prod qui est géré par helm et qui a un Persistent Volume local géré aussi par k8s, et le postgres en sus qui est une image docker que j’ai faite mais qui est géré aussi par k8s (dans un statefulset) et qui a un Persistant Volume dans ceph et enfin les Snaphot de la base dans ceph sont eux aussi géré par k8s via la fonctionnalité de Snapshot de k8s. Je ne fais absolument rien hors de k8s.
Pour clarifier la gestion sur stockage dans k8s. Il y a plusieurs choses.
Le plus simple c’est le stockage éphèmere. Le container écrit sur le disque local du node qui le fait tourner. Quand le container s’arrête tout est perdu.
Ensuite on a la couche stockage persistant. On a d’abord un type storageclass. Dans mon cas j’en ai deux. Une locale et une pour ceph.
Pour la locale je dois créer à la main les lv et les assigner ensuite dans un Persistant Volume (PV), je ne crois pas qu’on puisse encore lui donner un vg et débrouille-toi pour créer les lv.
Pour ceph c’est plus simple. Je crée un Persistant Volume Claim (PVC) qui va créer automatiquement le PV avec la bonne taille.
Avec tout ça il y a un volumesnapshotclass et un volumespnashot qui vont me permettre de créer des snapshot de mes PVC et de les transformer en PV. Ça m’évite de copier 50G de base quand j’ai besoin d’une nouvelle pile pour tester une branche de notre dev.
Là je snapshot mon postgres qui tourne dans ceph et je démarre un nouveau postgres sur le PV créé à partir du snaphost. Merci à postgres d’être capable de se relancer proprement à partir d’un snapshot totalement inconsistant. J’ai vu qu’une commande fsfreeze existait mais pour le moment ça marche.
Donc maintenant j’ai mon pvc.
Si je l’utilise dans un déploiement tous mes pod vont pouvoir y accéder. J’ai donc un volume partagé entre tous mes pods.
Si je l’utilise dans un Statefulset un seul pod pourra utiliser mon pvc et le nom du pod sera fixe.
En tout cas, je note que l'on est loin d'avoir une solution pérenne et performante
pour gérer les données persistantes dans k8s.
Je ne suis pas d’accord avec ça. Depuis l’arrivée des Statefulset ce n’est plus le cas.
Tu ne peux pas avoir un soft qui se créait sa propre base de donnée et l'utilise (par > exemple avec helm).
Si tout à fait. C'est le cas de gitlab, de owncloud par exemple. Tu leur donnes le nom de ta storageclass et ils se débrouillent.
Posté par oau .
En réponse à la dépêche Harbor 2.0.
Évalué à 1.
En vrai ça dépend de la taille de ton cluster ceph. Si comme moi il est tout petit en stockage (30to) et moins petit en node (7 nodes) effectivement on s'en fout.
Mais sur un cluster plus gros ceph peut être assez violent quand il se reconstruit sur la consommation des ressources. Principalement parce que souvent les gens mettent 3 machines avec 48 disques de 12to. Et quand une machine meurt ou reboot sans le petit noout qui va bien et bien il faut reconstruire beaucoup de données. Si tu as sur les mêmes machine ta prod k8s elle va en souffrir.
Posté par oau .
En réponse à la dépêche Harbor 2.0.
Évalué à 1.
C'est vrai. Mais je suis très stressé sur la pérennité des données que je reçois. Alors je réplique partout et je backup tout le temps. Mon cluster ceph est d'ailleurs répliqué sur un autre DC au cas ou …
Pour tout dire je reçois mes flux de données sur un serveur. Je transfère les données brutes dans l'object storage de ceph et dans kafka, qui lui a sont propre moyen de réplication et a qui j'ai donné des disques dans ceph. Donc encore répliqué. Et je retiens les données dans kafka indéfiniment.
Ensuite ça passe dans un ETL qui envoie ça dans une base postgres avec 4 réplica. 3 sur des disques locaux géré avec stolon et 1 dans ceph. Celui dans ceph permet de faire des snapshots de postgres pour démarrer une stack de dev avec les même données que dans la prod et alimenté par le kafka. Stack qui est démarré automatiquement quand je pousse une nouvelle branche dans gitlab.
Au final mes dev peuvent avoir en 2/3min une pile applicative complète et à jour sur laquelle développer juste en créant une nouvelle branche.
Et enfin la sortie de l'ETL va aussi dans EKS de même que tout mes logs pour faire un peu de data visualisation avec kibana. Mais sur ce point je ne suis vraiment pas au top.
Posté par oau .
En réponse à la dépêche Harbor 2.0.
Évalué à 1.
Pour pouvoir garder tes données ? Si j'installe un elastiksearch je veux pouvoir conserver mes données si la machine disparaît pour une raison ou une autre. Si je n'ai pas de fs partagé les données sont en local. Ou dans un stockage éphémère qui disparaît quand le pod redémarre ou dans un Persistent Volume local qui disparaîtra si la machine disparaît. Qu'elle crashe, qu'elle disparaisse du réseau, que le disque meure etc.
Posté par oau .
En réponse à la dépêche Harbor 2.0.
Évalué à 1.
Je n'ai encore vu si la modes des clusters k8s était de séparer serveur de calcul et serveur de fichiers > (de volumes, SAN…), ou bien de faire n machines identiques, avec partage distant ou non des fichiers par > une techno d'accès réseau.
Ça ce n'est qu'un question d'argent. Si tu es riche tu as 3 machines maîtres k8s et 3 autres monitor pour ceph. N machines pour tes données cephs (OSD) et N autres machines pour k8s (les computes). Si tu es pauvre comme moi tu as 7 machines identiques qui font tout :) et vraiment pour mon usage c'est tout à fait bien.
Posté par oau .
En réponse à la dépêche Harbor 2.0.
Évalué à 1.
Effectivement pour mes bases je n’utilise pas ceph. j'utilise stolon que je déploie avec helm et qui gère la réplication de postgres. Postgres qui tourne sur le stockage local qui sera quand même toujours plus rapide que ceph.
Ceph c'est plus pour les disques de elastiksearch, prometheus, pour notre owncloud et comme object storage. Je l'utilise aussi pour les applications que je déploie directement avec helm comme gitlab ou un peu à la mains comme zimbra.
Posté par oau .
En réponse à la dépêche Harbor 2.0.
Évalué à 2.
Ceph n'est pas une obligation mais avoir un stockage partagé oui. Tu peux utiliser autre chose. HDFS je n'ai jamais utilisé. Mais vraiment ça ne me donne pas envie, de loin ca à l'air particulièrement lourd. Sur la ML de ceph beaucoup de gens cherchent à remplacer HDFS par ceph.
Posté par oau .
En réponse à la dépêche Harbor 2.0.
Évalué à 2.
C'est la partie qui exécute les commandes kubectl, typiquement dans un .gitlab-ci.yaml ?
c’est en partie ça, on parle aussi d’infrastructure as code. C’est un moyen de garder une consistance entre une infra décrite avec du code et la réalité.
J'ai l'impression aussi que l'installation de kubernetes lui-même n'est pas simple. Par exemple, si on
veut se faire un cluster à soi chez un fournisseurs de bare-metal (ovh) ou de VM.
C’est ce que je fais chez OVH. Kubernetes c’est 3 binaires en go et une base etcd. C’est donc assez simple. À installer et à mettre à jour.
La partie pas nécessairement simple est au niveau du réseau quand on veut bien tout séparer dans différents vlans. Il faut assi bien faire attention aux api qu’on utilise dans ses yaml. Il y a des changements lors des montés de version qui peuvent casser les déploiements. Dans mon souvenir les déploiements ont changé entre la version 1.15 et 1.16, c’est passé de beta à stable. Après c’est juste une ligne à changer dans son yaml. Mais sur le coup ça surprend.
Ensuite il faut aussi installer et donc maintenir un cluster Ceph pour le stockage ce qui rajoute de la complexité et du temps pour faire l’exploitation.
Mais dans l’ensemble ce n’est pas si compliqué que ça quand je pense aux usines à gaz que j'ai dû installer pour "des grands comptes". Ceph est incroyablement stable, simple, cohérent, performant et plein de fonctionnalité. Pour mon utilisation c’est vraiment un point final à la gestion du stockage. Je dirais la même chose pour k8s.
Après je ne propose pas à mes clients de faire la même chose chez eux. Il est tellement simple de déployer un cluster k8s chez google, aws ou azure que je ne suis pas sur que le faire chez soi ait du sens si on parle de simplicité. Par contre niveaux coût par mois pour le moment il semble que c'est quand même bien moins cher de le faire soi-même. On garde aussi la main sur le hardware qu’on utilise.
Avant de partir sur un type de serveur chez ovh j'ai passé un bon mois à tester les différentes offres. Surtout au niveau des disques SSD/NVME. Ceph est particulièrement tatillon sur les disques.
Au final k8s et Ceph ont totalement changé ma tripple vie de dev, de datascientist et d’admin. Avant je faisais 50 % d’admin, 40 % de dev et 10 % de datascience. Aujourd’hui je fais 10 % d’admin, 40 % de dev et 50 % de datascience. Mon unique outil d’admin c’est git. Et c’est un admin de trèèès longue date qui dit ça ;)
Posté par oau .
En réponse à la dépêche Harbor 2.0.
Évalué à 2.
Bonjour,
effectivement, je suis en plein dedans. Autant je pense que la couche container avec ou sans docker et orchestrateur avec kubernetes est stable et on trouve un kubernetes chez tous les hébergeurs de cloud.
La partie déploiement ne l'est pas du tout. Et pour le moment je ne vois rien qui se détache réellement.
Helm c'est bien pour déployer des applications qui existent déjà. Je le vois comme le apt du cloud. Mais pour déployer sa propre application je trouve ça trop lourd. Il y a terraform dont beaucoup de gens parlent, mais apprendre encore un langage relativement neuf c'est pénible et pas nécessairement pérenne. Je n'ai pas encore regardé kompose ou crossplane mais j'ai un faible pour pulumi. C'est du python et j'aime bien le python.
Après pour une application relativement simple avec 2, 3 services, une base de données, un django, un nginx ce n'est pas forcément nécessaire. Un petit coup de envsubst dans le yaml suffit. Mais il est vrai que ma cicd gitlab qui faisait 20 lignes il y a un an en fait 400 aujourd’hui …
Microsoft reconnait avoir toujours été du mauvais côté de l’Histoire
internet, le zune, le windows phone, la xbox, bing, le Kin, Games for Windows, le cloud, HoloLens, rt, vista, millenium, 8, silverlight, msn, powershell, cortana, edge.
J'ai toujours trouvé la police de Windows particulièrement moche. Mais vraiment. Ca fait même partie des raisons de ma transition définitive sous linux.
Récemment j'ai passé du temps sur azure pour un client et j'ai retrouvé cette police… Sur une page web ca choque. J'ai l'impression que la police est particulièrement aliasé. Cest le cas ou c'est moi ? Si c'est le cas pourquoi garder une police aliasé ? C'est toujours la même police sur windows 10 ?
Merci pour ce que vous faites, j'ai travaillé pendant longtemps sur du matériel HP avec des DL et j'ai toujours beaucoup aimé leur robustesse, leur stabilité et leur ouverture vers linux. Si en plus maintenant on va avoir du logiciel libre dedans c'est fantastique.
depuis un an j'utilise nord partout, j'aime vraiment bien. C'est tout doux comme couleur. J'utilise les versions pour vim, gnome-terminal, powerline.bash, i3 et firefox. Bref tout ce que j'utilise au quotidien. Vous pourrez trouver mes dotfiles sur gitlab.com
[^] # Re: Le cloude c'est la vie
Posté par oau . En réponse au lien AWS a encaissé une attaque DDoS de 2,3 Tbps. Évalué à 1.
Et c'est rien de le dire. A chaque fois c'est la surprise pour mes clients en fin de mois. Avant il fallait être chaman pour faire marcher Windows maintenant il faut être chaman pour prévoir ta facture de gaz (gce, aws, azur).
[^] # Re: Espace de coworking
Posté par oau . En réponse au journal Télétravail, premier pas vers une délocalisation générale ?. Évalué à 3.
oui désolé il était un petit peu tôt il eut été préférable de donner un peu plus d'explication et de spécifier que je n'ai rien à voir avec cette entreprise si ce n'est que j'en suis un client satisfait et que le repeuplement des campagnes est un peu mon dada :) (et que mes phrases sont bien trop longues).
Repeuplement qui me semble possible via la création d'espace de travail commun. Là ou je suis j'ai des comptables, une paysagiste, des éleveurs d'abeilles, un spécialiste de la sdram en embarqué, une formatrice en sécurité agricole, des infirmières, une spécialiste de la prévision météo dans une entreprise qui fabrique des éoliennes, un vendeur de poutre en béton et c'est très enrichissant.
# Espace de coworking
Posté par oau . En réponse au journal Télétravail, premier pas vers une délocalisation générale ?. Évalué à 6.
Bonjour,
je voudrais partager mon expérience et mettre un petit bémol au télé travail.
C'est clair que c'est vraiment super. J'ai commencé à télétravailler en 2009. J'étais célibataire, au bord de la mer et dans ma ville natale. J'y ai retrouvé mes potes. J'ai vraiment passé des années super.
Puis j'ai déménagé dans un nouvel endroit que je n'aime pas trop, j'ai maintenant une famille. Pendant deux ans j'ai bossé seul de la maison. Et bien ça a été la grosse déprime.
Aujourd'hui je me suis trouvé un bureau dans un espace de coworking et c'est vraiment le bon compromis. Je fréquente des gens mais ne bosse pas avec. Donc pas de tension et uniquement les bon cotés. J'ai les 15min de changement ce contexte le matin et le soir. Et j'organise ma journée comme je l'entend.
https://www.relais-entreprises.fr
[^] # Re: Données du grand débat public
Posté par oau . En réponse au journal [HS] Microsoft ♥ Linux - Episode VI "AYBABTU". Évalué à 7.
et donc ? il faudrait que j'accepte que toutes mes données de santé soient sous le joug de multinationales sur lesquels je n'ai aucun pouvoir démocratique ? bah non.
Et ça vaut pour tout ces milliardaires qui se pensent au dessus des autres parce qu'ils sont riches (Tu te crois supérieur parce que t'es mon supérieur ? - stupeflip) et qui s'octroient le droit de rendre des miettes de ce qu'ils ont volé à coup de com sur les vaccins, les recherches, leur participation à l'opensource (ahahahah …) etc. « Voler en grand et restituer en petit, c’est la philanthropie » (Paul Lafargue). Vivre en société c'est accepter de partager. Vivre en démocratie c'est accepter d'avoir un pouvoir démocratique sur les acteurs de la société. Ces gens la ont le plus besoin d'état pour les protéger et les rendre riche mais n'acceptent ni de partager, ni de contrôle démocratique. Au final ça finira mal. Pour eux.
"On prépare vos menus, on enlève vos ordures, on vous relie par téléphone, on conduit vos ambulances, on vous protège pendant votre sommeil. Jouez pas aux cons avec nous." Tyler durden.
# excellent article
Posté par oau . En réponse au lien Criteo, un géant du marketing de surveillance français. Évalué à 8.
merci beaucoup pour ces informations. J'ai toujours navigué avec firefox et un bloqueur de pub. (Adblock avant, Ublock origin aujourd'hui). Je ne comprend pas comment les gens peuvent accepter ce harcèlement. Ils ont probablement l'habitude. Personnellement la pub me rend malade. Le peu de temps que je passe dans le métro parisien me révulse, je ne regarde plus la tv autre que arte simplement parce qu'il n'y a pas de pub. Pareil pour la radio. Je n'écoute que france culture parce qu'il n'y a pas de pub. J'ai d'ailleurs découvert pendant les grèves de radio france les "autres radios". Le choc …. je n'étais pas prêt.
[^] # Re: container compatible OCI ?
Posté par oau . En réponse à la dépêche Harbor 2.0. Évalué à 2.
oui pardon c'est l'outils de bench rbd qui vient avec ceph.
Pour les cartes raid oui en avoir une avec une batterie est bien sur un plus. Mais dans mon cas une carte raid c'est 57€ HT par mois de plus. C'est à dire 50% de plus par node. Je n'ai pas les moyens et surtout je n'en ai pas le besoin vu mes mes gros I/O sont fait en local directement sur les nvme.
ça discute pas mal sur la ML sur le sujet ces derniers temps. Je dirais que non parce que pour le moment ce n'est pas la piste prise. En gros les monitor discutent avec les osd sur le même canal que les données du cluster. Sur un cluster très chargé avec beaucoup de discussion entre les osd, le message de supervision des monitors peut mettre plusieurs minutes à revenir. Ce qui a pour effet de sortir l'osd du cluster et de lancer une rééquilibrage les données à travers le cluster, donc de le charger encore plus etc.
[^] # Re: container compatible OCI ?
Posté par oau . En réponse à la dépêche Harbor 2.0. Évalué à 1.
certes. Mais tu compares deux choses qui n'ont rien à voir. Entre un nvme en local et un fs distribué bien sur que tu n'as pas les mêmes performances. Surtout avec un réseau à 2Gbps. C'est pour cette raison que mes pg tourne en local. Mais j'ai retrouvé mes premiers bench sur ma plateforme actuelle avant qu'elle ne passe en production.
Et pgbench me donnait 355 transaction per second sur le ceph
Voici un test sur ma préprop qui est au bureau. Avec 3 noeuds, 6 osd ssd. Mais surtout un réseau de 10Gbps en fibre. Qui fait donc bien 10Gbps.
Voisi le résultat en écriture avec un réplica de 2 ou j'ai un réplica de 3 en prod:
En lecture séquentielle
En lecture aléatoire
On voit bien qu'on est limité par la bande passante du réseau.
Par contre une dernière chose qui peut potentiellement poser problème. Un client qui fait vraiment de très très gros IO sur un cluster peut totalement l'écrouler et pour le moment il n'y a pas vraiment de parade. Si ce n'est de tuer le dit client.
[^] # Re: container compatible OCI ?
Posté par oau . En réponse à la dépêche Harbor 2.0. Évalué à 1.
depuis 2014 les choses ont bien changé :
petit bench de mon cluster. 7 nodes avec des ssd de 1to et un lien de 2Gbps entre chaque. Sur chaque nodes tourne ceph mais aussi ma prod k8s
montage et formatage de l'image ceph.
rbd map kube/test
mkfs.ext4 /dev/rbd1
mount /dev/rbd1 /mnt/
Un petit dd dedans pour les perf en écriture :
dd if=/dev/zero of=test bs=8192k count=1000 oflag=direct
1000+0 records in
1000+0 records out
8388608000 bytes (8.4 GB, 7.8 GiB) copied, 71.8563 s, 117 MB/s
Les performances de ceph dépendent clairement du réseau. Plus gros sera le réseau plus ca ira vite. Il faut aussi bien faire attention au disques choisis.
[^] # Re: container compatible OCI ?
Posté par oau . En réponse à la dépêche Harbor 2.0. Évalué à 1.
Je pense qu’on s’est mal compris. Le posgresql en sus qui tourne dans ceph et qui est un replica de la production qui tourne sur des disques en local n’est là que pour avoir la possibilité d’en faire un snapshot.
Mais tout est géré par k8s. Aussi bien le cluster de postgres de prod qui est géré par helm et qui a un Persistent Volume local géré aussi par k8s, et le postgres en sus qui est une image docker que j’ai faite mais qui est géré aussi par k8s (dans un statefulset) et qui a un Persistant Volume dans ceph et enfin les Snaphot de la base dans ceph sont eux aussi géré par k8s via la fonctionnalité de Snapshot de k8s. Je ne fais absolument rien hors de k8s.
Pour clarifier la gestion sur stockage dans k8s. Il y a plusieurs choses.
Le plus simple c’est le stockage éphèmere. Le container écrit sur le disque local du node qui le fait tourner. Quand le container s’arrête tout est perdu.
Ensuite on a la couche stockage persistant. On a d’abord un type storageclass. Dans mon cas j’en ai deux. Une locale et une pour ceph.
Pour la locale je dois créer à la main les lv et les assigner ensuite dans un Persistant Volume (PV), je ne crois pas qu’on puisse encore lui donner un vg et débrouille-toi pour créer les lv.
Pour ceph c’est plus simple. Je crée un Persistant Volume Claim (PVC) qui va créer automatiquement le PV avec la bonne taille.
Avec tout ça il y a un volumesnapshotclass et un volumespnashot qui vont me permettre de créer des snapshot de mes PVC et de les transformer en PV. Ça m’évite de copier 50G de base quand j’ai besoin d’une nouvelle pile pour tester une branche de notre dev.
Là je snapshot mon postgres qui tourne dans ceph et je démarre un nouveau postgres sur le PV créé à partir du snaphost. Merci à postgres d’être capable de se relancer proprement à partir d’un snapshot totalement inconsistant. J’ai vu qu’une commande fsfreeze existait mais pour le moment ça marche.
Donc maintenant j’ai mon pvc.
Si je l’utilise dans un déploiement tous mes pod vont pouvoir y accéder. J’ai donc un volume partagé entre tous mes pods.
Si je l’utilise dans un Statefulset un seul pod pourra utiliser mon pvc et le nom du pod sera fixe.
Je ne suis pas d’accord avec ça. Depuis l’arrivée des Statefulset ce n’est plus le cas.
Si tout à fait. C'est le cas de gitlab, de owncloud par exemple. Tu leur donnes le nom de ta storageclass et ils se débrouillent.
[^] # Re: container compatible OCI ?
Posté par oau . En réponse à la dépêche Harbor 2.0. Évalué à 1.
En vrai ça dépend de la taille de ton cluster ceph. Si comme moi il est tout petit en stockage (30to) et moins petit en node (7 nodes) effectivement on s'en fout.
Mais sur un cluster plus gros ceph peut être assez violent quand il se reconstruit sur la consommation des ressources. Principalement parce que souvent les gens mettent 3 machines avec 48 disques de 12to. Et quand une machine meurt ou reboot sans le petit noout qui va bien et bien il faut reconstruire beaucoup de données. Si tu as sur les mêmes machine ta prod k8s elle va en souffrir.
[^] # Re: container compatible OCI ?
Posté par oau . En réponse à la dépêche Harbor 2.0. Évalué à 1.
C'est vrai. Mais je suis très stressé sur la pérennité des données que je reçois. Alors je réplique partout et je backup tout le temps. Mon cluster ceph est d'ailleurs répliqué sur un autre DC au cas ou …
Pour tout dire je reçois mes flux de données sur un serveur. Je transfère les données brutes dans l'object storage de ceph et dans kafka, qui lui a sont propre moyen de réplication et a qui j'ai donné des disques dans ceph. Donc encore répliqué. Et je retiens les données dans kafka indéfiniment.
Ensuite ça passe dans un ETL qui envoie ça dans une base postgres avec 4 réplica. 3 sur des disques locaux géré avec stolon et 1 dans ceph. Celui dans ceph permet de faire des snapshots de postgres pour démarrer une stack de dev avec les même données que dans la prod et alimenté par le kafka. Stack qui est démarré automatiquement quand je pousse une nouvelle branche dans gitlab.
Au final mes dev peuvent avoir en 2/3min une pile applicative complète et à jour sur laquelle développer juste en créant une nouvelle branche.
Et enfin la sortie de l'ETL va aussi dans EKS de même que tout mes logs pour faire un peu de data visualisation avec kibana. Mais sur ce point je ne suis vraiment pas au top.
[^] # Re: container compatible OCI ?
Posté par oau . En réponse à la dépêche Harbor 2.0. Évalué à 1.
Pour pouvoir garder tes données ? Si j'installe un elastiksearch je veux pouvoir conserver mes données si la machine disparaît pour une raison ou une autre. Si je n'ai pas de fs partagé les données sont en local. Ou dans un stockage éphémère qui disparaît quand le pod redémarre ou dans un Persistent Volume local qui disparaîtra si la machine disparaît. Qu'elle crashe, qu'elle disparaisse du réseau, que le disque meure etc.
[^] # Re: container compatible OCI ?
Posté par oau . En réponse à la dépêche Harbor 2.0. Évalué à 1.
Ça ce n'est qu'un question d'argent. Si tu es riche tu as 3 machines maîtres k8s et 3 autres monitor pour ceph. N machines pour tes données cephs (OSD) et N autres machines pour k8s (les computes). Si tu es pauvre comme moi tu as 7 machines identiques qui font tout :) et vraiment pour mon usage c'est tout à fait bien.
[^] # Re: container compatible OCI ?
Posté par oau . En réponse à la dépêche Harbor 2.0. Évalué à 1.
Effectivement pour mes bases je n’utilise pas ceph. j'utilise stolon que je déploie avec helm et qui gère la réplication de postgres. Postgres qui tourne sur le stockage local qui sera quand même toujours plus rapide que ceph.
Ceph c'est plus pour les disques de elastiksearch, prometheus, pour notre owncloud et comme object storage. Je l'utilise aussi pour les applications que je déploie directement avec helm comme gitlab ou un peu à la mains comme zimbra.
[^] # Re: container compatible OCI ?
Posté par oau . En réponse à la dépêche Harbor 2.0. Évalué à 2.
Ceph n'est pas une obligation mais avoir un stockage partagé oui. Tu peux utiliser autre chose. HDFS je n'ai jamais utilisé. Mais vraiment ça ne me donne pas envie, de loin ca à l'air particulièrement lourd. Sur la ML de ceph beaucoup de gens cherchent à remplacer HDFS par ceph.
[^] # Re: container compatible OCI ?
Posté par oau . En réponse à la dépêche Harbor 2.0. Évalué à 2.
pour tester microk8s est bien plus simple je trouve que minikube qui dans mon souvenir nécessite virtualbox ou kvm
[^] # Re: container compatible OCI ?
Posté par oau . En réponse à la dépêche Harbor 2.0. Évalué à 2.
c’est en partie ça, on parle aussi d’infrastructure as code. C’est un moyen de garder une consistance entre une infra décrite avec du code et la réalité.
C’est ce que je fais chez OVH. Kubernetes c’est 3 binaires en go et une base etcd. C’est donc assez simple. À installer et à mettre à jour.
La partie pas nécessairement simple est au niveau du réseau quand on veut bien tout séparer dans différents vlans. Il faut assi bien faire attention aux api qu’on utilise dans ses yaml. Il y a des changements lors des montés de version qui peuvent casser les déploiements. Dans mon souvenir les déploiements ont changé entre la version 1.15 et 1.16, c’est passé de beta à stable. Après c’est juste une ligne à changer dans son yaml. Mais sur le coup ça surprend.
Ensuite il faut aussi installer et donc maintenir un cluster Ceph pour le stockage ce qui rajoute de la complexité et du temps pour faire l’exploitation.
Mais dans l’ensemble ce n’est pas si compliqué que ça quand je pense aux usines à gaz que j'ai dû installer pour "des grands comptes". Ceph est incroyablement stable, simple, cohérent, performant et plein de fonctionnalité. Pour mon utilisation c’est vraiment un point final à la gestion du stockage. Je dirais la même chose pour k8s.
Après je ne propose pas à mes clients de faire la même chose chez eux. Il est tellement simple de déployer un cluster k8s chez google, aws ou azure que je ne suis pas sur que le faire chez soi ait du sens si on parle de simplicité. Par contre niveaux coût par mois pour le moment il semble que c'est quand même bien moins cher de le faire soi-même. On garde aussi la main sur le hardware qu’on utilise.
Avant de partir sur un type de serveur chez ovh j'ai passé un bon mois à tester les différentes offres. Surtout au niveau des disques SSD/NVME. Ceph est particulièrement tatillon sur les disques.
Au final k8s et Ceph ont totalement changé ma tripple vie de dev, de datascientist et d’admin. Avant je faisais 50 % d’admin, 40 % de dev et 10 % de datascience. Aujourd’hui je fais 10 % d’admin, 40 % de dev et 50 % de datascience. Mon unique outil d’admin c’est git. Et c’est un admin de trèèès longue date qui dit ça ;)
[^] # Re: container compatible OCI ?
Posté par oau . En réponse à la dépêche Harbor 2.0. Évalué à 2.
Bonjour,
effectivement, je suis en plein dedans. Autant je pense que la couche container avec ou sans docker et orchestrateur avec kubernetes est stable et on trouve un kubernetes chez tous les hébergeurs de cloud.
La partie déploiement ne l'est pas du tout. Et pour le moment je ne vois rien qui se détache réellement.
Helm c'est bien pour déployer des applications qui existent déjà. Je le vois comme le apt du cloud. Mais pour déployer sa propre application je trouve ça trop lourd. Il y a terraform dont beaucoup de gens parlent, mais apprendre encore un langage relativement neuf c'est pénible et pas nécessairement pérenne. Je n'ai pas encore regardé kompose ou crossplane mais j'ai un faible pour pulumi. C'est du python et j'aime bien le python.
Après pour une application relativement simple avec 2, 3 services, une base de données, un django, un nginx ce n'est pas forcément nécessaire. Un petit coup de envsubst dans le yaml suffit. Mais il est vrai que ma cicd gitlab qui faisait 20 lignes il y a un an en fait 400 aujourd’hui …
# Même si on est pas vendredi ....
Posté par oau . En réponse au journal Compétition : faites exploser les compteurs du trolomètres. Évalué à 6.
pas taper j’arrête, je suis déjà dehors => []
[^] # Re: Actif Actif, multimaster, bi site?
Posté par oau . En réponse au journal Postgresql, un retour d'expérience. Évalué à 1.
Stolon en prod ici depuis 18 mois. Et franchement c'est top.
https://github.com/sorintlab/stolon
Par contre pas de actif/actif pour autant que je sache. En écriture du moins. Les n replica sont accessibles en lecture.
# Vu qu'on de windows j'aurais une question.
Posté par oau . En réponse au journal Mieux que Santa Barbara : Munich revient aux logiciels libres. Évalué à 3.
J'ai toujours trouvé la police de Windows particulièrement moche. Mais vraiment. Ca fait même partie des raisons de ma transition définitive sous linux.
Récemment j'ai passé du temps sur azure pour un client et j'ai retrouvé cette police… Sur une page web ca choque. J'ai l'impression que la police est particulièrement aliasé. Cest le cas ou c'est moi ? Si c'est le cas pourquoi garder une police aliasé ? C'est toujours la même police sur windows 10 ?
# Tout est css...
Posté par oau . En réponse à la dépêche Sortie de Deno 1.0. Évalué à 3.
http://www.commitstrip.com/fr/2019/03/15/css-css-everywhere/
# Merci !
Posté par oau . En réponse au journal Microcode ouvert sur materiel HPE ?. Évalué à 4.
Merci pour ce que vous faites, j'ai travaillé pendant longtemps sur du matériel HP avec des DL et j'ai toujours beaucoup aimé leur robustesse, leur stabilité et leur ouverture vers linux. Si en plus maintenant on va avoir du logiciel libre dedans c'est fantastique.
# Polices
Posté par oau . En réponse à la dépêche Quelle palette de couleurs pour vos outils ?. Évalué à 3.
vous pourriez partager les polices que vous utilisez ? J'ai du mal à en trouver une qui me plaît. Aujourd'hui j'utilise Source code pro.
# Nord
Posté par oau . En réponse à la dépêche Quelle palette de couleurs pour vos outils ?. Évalué à 4.
depuis un an j'utilise nord partout, j'aime vraiment bien. C'est tout doux comme couleur. J'utilise les versions pour vim, gnome-terminal, powerline.bash, i3 et firefox. Bref tout ce que j'utilise au quotidien. Vous pourrez trouver mes dotfiles sur gitlab.com