- Tiering vs bcache vs dm-cache + инструкции по дмкешу.
- почему дедупликация крайне затруднена в архитектуре Ceph
В filestore всё полностью пишется в журнал. WAL используется как writeback-cache по сути. Один write в rados превращается в два сисколла write -- один в журнал (с синком) и один в основное хранилище. Основное хранилище фсинкается время от времени. Запись в журнал линейная, а в основное хранилище рандомная. При записи в хранилище поможет параллельность которую может диск (например, NCQ). При записи в журнал параллельность не используется, поэтому диск под журнал для файлстора надо бенчить именно так: wal_bench_.
- при выносе журнала или БД на отдельный диск теряется возможность перевставлять диски в другой нод. При старте ОСД (бай дефолт есть параметр) обновляет себя в крушмапе.
- При потере журнала вседиски на него зааттаченные превращаются в труху
- При потере данных всех мониторов теряется весь кластер.
- Нужно использовать именно три реплики потому что если две - то при скраб ерроре не понятно кому верить
- запись и чтение делается исключительно с мастера в актинг сете. При записи данные отправляются на мастер осд а он по кластер-сети отправляет параллельно на два слейва. on_safe-коллбэк клиента вызывается когда данные записались в WAL на всех репликах. Дожидания прописывания в основное хранилище в принципе нет. Есть коллбэк когда данные есть в памяти на всех трёх репликах.
- бкеш врёт относительно ротейшионал и цеф использует не те настройки. Бкеш writeback
(кеширование записи) не нужен потому что с файлстором это делается через WAL, а с
блюстором есть опция по записи даже больших запросов в БД которую нужно вынести на ССД.
С чтением тоже не нужен потому что:
- виртуалки с рбд и так не плохо кешируют то что уже читали
- запись потребляет в 3 раза больше иопсов (размер пула=3). а на самом деле ещё больше по причине двойной записи и даже ещё больше если это файлстор. Чтение требует один-в-один. поэтому цеф на чтение хорош.
- Нормальный кеш делает через тиеринг в цефе (но это не точно).
- Описание цифр в ceph -s. откуда берутся цифры и что они означают.
- Как посчитать реальную вместимость кластера. мин. загруженность осд.
- сколько должен давать кластер иопсов и мегабайтов в секунду на чтение и на запись. какие паттерны использования и параллельность.
- ceph-deploy требует GPT. Размер журнала и БД надо выставлять.
- Инструкцию по перемещению журнала на другое место для файлстора. и факт что это невозможно для блюстора.
- понимание, что ИО одного и того же обжекта (или 4-мб-блока в рбд) никак не распараллеливается магически. и оно будет равно иопсам журнала или осн. хранилища.
- почему мелкие объекты плохо в радосе и большие тоже плохо.
- почему при убирании диска надо сначала сделать цеф осд аут, а не просто вырубить диск.
- для более быстрой перезагрузки используйте kexec. systemctl kexec. однако с кривым железом может не работать (сетёвки и рейды/хба).
- https://habrahabr.ru/post/313644/
- почему size=3 min_size=1 (size 3/1) моежт привести к проблемам.
- Каждая пг устанавливает свой кворум таким образом много
- ссылка на калькулятор количества ПГ. почему много пг плохо и мало пг тоже плохо.
- http://ceph.com/pgcalc
- если мало - то неравномерность, потенциально не все осд могут быть заюзаны.
- если много - юсадж памяти, перегрузка сети