S3 и зачем вообще городить ещё один клиент…

Вы нормально знаете Ceph, пулы, RGW, где смотреть логи и почему внезапно полезли 403. Вопрос в другом: вокруг кластера живут люди, которым нужен не Ceph, а S3 как диск в облаке . Им нужно залить билд, вытащить дамп, перекинуть префикс между стендами, выдать временную ссылку, проверить, что объект реально лежит и какой у него размер. Без чтения ceph -w s3cmd rados etc, без объяснений про placement groups и без вашего участия в каждой мелочи. CLI и скрипты вы держите для себя и для пайплайнов. Консоль облака у вас может быть про другой контур. А типичный пользователь упирается в простую вещь: хочу окно с таблицей, перетаскиванием и понятной ошибкой , а не пятнадцать шагов «спроси админа». Отсюда и смысл отдельного десктопного клиента под S3 API: не заменить вам эксплуатацию, а снять с вас поток однотипных ручных запросов и дать людям самообслуживание в рамках выданных ключей и политик.

https://habr.com/ru/articles/1023538/

#S3 #ceph #minio #client #s3cmd #aws #aws_s3 #aws_sdk

Год в проде с Ceph: как мы пришли к новой референсной архитектуре

Привет, Хабр! Меня зовут Игорь Шишкин, я руковожу отделом разработки облачной платформы и архитектором SDS в Рунити. Ранее я уже рассказывал про то, как мы выбирали SDS (Software Defined Storage), почему остановились на Ceph, а также о наших процессах в R&D. В этой статье , поделюсь, что мы поймали за год в продакшене, какие решения в дизайне кластеров оказались ошибочными, как это изменило нашу референсную архитектуру и к чему мы пришли в итоге.

https://habr.com/ru/companies/runity/articles/1021222/

#регоблако #ceph #s3 #hsdc #конфигурация #exhausted #jbod #hba #архитектура #кластер

Found the common point between century-old blues standards and my homelab AMA

#ceph #proxmox #homelab #blues

Latest experience with Ceph: Never enable `rbytes` on the CephFS client mount unless absolutely necessary.
This places an extremely heavy metadata load on the MDS and the OSDs.
So we’re not talking about a 20–30% increase, but rather, depending on the size and depth of the filesystem, an increase of several dozen to hundreds of times.

#ceph #cephfs #osd #mds

Da migriert man den ganzen Mastodon Bumms auf S3 Storage und dann sind da noch immer 150G belegt. Die anderen Mastodon Instanzen liegen so um die 2G ohne die Mediendateien.

Stellt sich heraus, dass ich am 9. April 2023 wohl mal irrtuemlich /home/mastodon nach ~/live/public kopiert habe - warum auch immer.

Naja, da liegen halt ca. 142G drin und es faellt mir erst auf, nachdem die 1T an Mediendateien nun im S3 sind.

Putzig.

Zeigt aber auch, dass ich offenbar Eines nicht habe: Mangel an Speicher.

#mastoadmin #ceph #s3

Sodele… nach der Umstellung auf S3 Storage bei https://baltic.social/ war nun auch https://fedisocial.de/ mit der Umstellung dran.

Wenn man erst einmal ein funktionierendes Setup gefunden hat, das mit #Mastodon, #S3 Storage auf #Ceph radosgw und #haproxy auf der #pfSense funktioniert, ist das eigentlich dann relativ straight-forward…

Als Nächstes kommen dann die 1.2 TB hier auf der Instanz dran. Das ist allein schon wegen der Datenmenge nicht ganz so fluffig…

#mastoadmin #fediadmin

Ich teste grad auf Arbeit unseren #Ceph #Cluster mit Bonnie++. Über 2x 25 Gbit/s mit LACP bekomme ich 2.1 GB/s write, 1.2 GB/s rewrite und 1.8 GB/s reading hin.

Allerdings erst, nachdem ich read_ahead_kb auf 64M gesetzt habe.

Aber ich denke, das sind fuer ein Single Thread Test schon ganz ordentliche Werte mit 12x OSD x 6 Nodes.

Spannend wird es ja dann, wenn mehrere Clients zugreifen.

Respect for #Ceph.
Managed to kill a SATA-controller, let the cluster run with one of three legs cut off for a week (decided halfway through to mark the dead OSDs out, so I wouldn‘t have stale objects on my 2/1-pools).
Got it to recover/rebalance again, and while scrubbing two drives (15 y/o) started throwing read errors (on a previously healthy node).
Well, gotta get new drives I guess.
And never did I lose any data, or had Ceph refuse to operate with two of the three working.

#Proxmox

Was ich bei #Ceph nicht so recht verstehe:

Nachdem ich die eine OSD geloescht und mit WAL/DB auf SSD wieder hinzugefuegt habe, werden ja die ganzen Daten wieder auf die OSD kopiert. Aber Write Bytes bleibt beharrlich bei 0.

Wird das rausgerechnet oder nur die Client-Daten erfasst, also z.B. was ueber das Public Network kommt, aber nicht ueber das Cluster Network?