├── .gitignore ├── Makefile ├── _static ├── .gitignore ├── cloudmouse.png └── qemu-img-bandwith.jpg ├── _templates └── .gitignore ├── about.rst ├── bench-disks.rst ├── bench.rst ├── bluestore.rst ├── ceph-choice.rst ├── cephfs.rst ├── cloudmouse.rst ├── conf.py ├── cpu_and_mem.rst ├── developing.rst ├── disks.rst ├── how-it-works.rst ├── how_to_remove_osd.rst ├── index.rst ├── monitoring.rst ├── network.rst ├── rbd-qemu.rst ├── rbd.rst ├── rookio.rst ├── see_also.rst ├── tuning.rst └── upgrade-to-luminous.rst /.gitignore: -------------------------------------------------------------------------------- 1 | /_build 2 | -------------------------------------------------------------------------------- /Makefile: -------------------------------------------------------------------------------- 1 | # Minimal makefile for Sphinx documentation 2 | # 3 | 4 | # You can set these variables from the command line. 5 | SPHINXOPTS = 6 | SPHINXBUILD = sphinx-build 7 | SPHINXPROJ = CephFAQ 8 | SOURCEDIR = . 9 | BUILDDIR = _build 10 | 11 | # Put it first so that "make" without argument is like "make help". 12 | help: 13 | @$(SPHINXBUILD) -M help "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O) 14 | 15 | .PHONY: help Makefile 16 | 17 | # Catch-all target: route all unknown targets to Sphinx using the new 18 | # "make mode" option. $(O) is meant as a shortcut for $(SPHINXOPTS). 19 | %: Makefile 20 | @$(SPHINXBUILD) -M $@ "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O) -------------------------------------------------------------------------------- /_static/.gitignore: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/socketpair/ceph-docs/66894491d843e5e4f7a41ff63902f7a1aa2e0638/_static/.gitignore -------------------------------------------------------------------------------- /_static/cloudmouse.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/socketpair/ceph-docs/66894491d843e5e4f7a41ff63902f7a1aa2e0638/_static/cloudmouse.png -------------------------------------------------------------------------------- /_static/qemu-img-bandwith.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/socketpair/ceph-docs/66894491d843e5e4f7a41ff63902f7a1aa2e0638/_static/qemu-img-bandwith.jpg -------------------------------------------------------------------------------- /_templates/.gitignore: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/socketpair/ceph-docs/66894491d843e5e4f7a41ff63902f7a1aa2e0638/_templates/.gitignore -------------------------------------------------------------------------------- /about.rst: -------------------------------------------------------------------------------- 1 | ***************** 2 | Об этом документе 3 | ***************** 4 | 5 | Эта документация собирает в себе опыт использования 6 | `Ceph `_ несколькими специалистами. 7 | Вы можете улучшить её, задав вопрос `на GitHub `_, 8 | либо создав pull-request с исправлениями. 9 | 10 | Также, активное обсуждение вопросов о Ceph ведётся в 11 | `telegram-группе `_. 12 | 13 | Мэйнтенйнером проекта является Коренберг Марк 14 | `socketpair@gmail.com `_. 15 | 16 | http://ceph-docs.readthedocs.io 17 | 18 | Авторы 19 | ====== 20 | 21 | * Alexey Lesovsky @lesovsky 22 | * Maksim Shchuplov 23 | * Vitaliy Filippov 24 | * Коренберг Марк 25 | -------------------------------------------------------------------------------- /bench-disks.rst: -------------------------------------------------------------------------------- 1 | Бенчмаркинг дисков 2 | ================== 3 | 4 | SSD диски всегда дают лучшие результаты от разумной параллельности. Поэтому все 5 | тесты здесь для SSD имеет смысл провести с ``--iodepth=...``. Возможно, вместо 6 | этого (или вместе с) добавить к fio опцию ``--jobs=...``. Здесь важно с помощью 7 | настроек эмулировать нагрузку соответствующую настройкам Ceph, а не просто 8 | запредельную. Каноничная статья про IOPS: https://habr.com/post/154235 9 | 10 | При тестах нужно учесть, что HBA может иметь собственный кеш, искажающий 11 | результаты. Не стоит отключать кеш на самом диске. Есть мнение, что он позволяет 12 | диску производить оптимизации при записи. 13 | 14 | Некоторые производители дисков применяют свои инновационные технологии, поэтому 15 | тесты могут выдавать завышенные результаты (особенно если тесты не длятся достаточно 16 | долго). Для магнитных дисков хочется отдельно отметить HGST Media Cache Architecture: 17 | http://www.tomsitpro.com/articles/hgst-ultrastar-c15k600-hdd,2-906-3.html 18 | 19 | Тестировать лучше всего весь диск (/dev/sdX). Можно раздел или linear LVM 20 | (говорят, для NVME он таки тормозит), но точно не файл на ФС. 21 | 22 | Перед каждым тестом SSD для получения воспроизводимых результатов лучше 23 | выполнить команду 24 | 25 | .. code-block:: sh 26 | 27 | blkdiscard /dev/YOUR_DEVICE 28 | 29 | HDD или SSD под FullFlash 30 | ------------------------- 31 | 32 | Линейное чтение/запись 33 | ^^^^^^^^^^^^^^^^^^^^^^ 34 | 35 | .. code-block:: sh 36 | 37 | fio --ioengine=libaio --direct=1 --name=test --runtime=60 --filename=/dev/sdX \ 38 | --bs=4M --rw=read 39 | 40 | fio --ioengine=libaio --direct=1 --name=test --runtime=60 --filename=/dev/sdX \ 41 | --bs=4M --rw=write --sync=1 42 | 43 | С HDD разница может быть значительной (в 2 раза?) в зависимости от того, 44 | в начале диска происходит тест или в конце. Скорость также зависит от 45 | плотности записи и количества оборотов в секунду. Плотность записи зависит от 46 | размера блинов и количества используемых плоскостей (количества головок). 47 | 48 | Тест показывает максимально возможную скорость (смотреть МБ/сек). 49 | Запускать несколько потоков для HDD смысла нет. 50 | Во избежание влияния кеша диска (и расстояния от начала) при повторных запусках, 51 | возможно, стоит поменять на --rw=randread / --rw=randwrite. При этом результат 52 | тестов должен быть примерно тот же. 53 | TODO: убедиться, что в rand-режиме смещение выравнено по размеру блока. 54 | 55 | Случайное чтение/запись 56 | ^^^^^^^^^^^^^^^^^^^^^^^ 57 | 58 | .. code-block:: sh 59 | 60 | fio --ioengine=libaio --direct=1 --name=test --runtime=60 --filename=/dev/sdX \ 61 | --bs=4k --rw=randread 62 | 63 | fio --ioengine=libaio --direct=1 --name=test --runtime=60 --filename=/dev/sdX \ 64 | --bs=4k --rw=randwrite --sync 65 | 66 | Тест показывает максимальную скорость в самых худших для диска условиях 67 | (Смотреть IOPS). 68 | 69 | Чтение 70 | """""" 71 | 72 | Для моделирования реальной нагрузки стоит запустить в несколько потоков. 73 | TODO: посмотреть какой опции в Ceph это соответствует. 74 | Для SATA технология NCQ даст ускорение для этого теста в 75 | многопоточном режиме. По моим экспериментам ускорение всего в 1.5 раза всего 76 | (но это не точно). Для типичного SATA контроллера, NCQ включается только в 77 | режиме AHCI. 78 | 79 | Запись 80 | """""" 81 | 82 | При записи в основное хранилище (после записи в журнал) OSD запускает в 83 | параллель много операций записи, а потом один sync. В этом случае, диск имеет 84 | возможность (за счёт переставления порядка записи секторов, а также за счёт 85 | слияния смежных IO в один) произвести оптимизации. Я не знаю как в fio 86 | сэмулировать подобное поведение. Придумал две методики: 87 | 88 | # Тестировать случайную запись в один поток с ожиданием синка -- это покажет 89 | самый худший (но не реалистичный) случай. 90 | 91 | # Тестировать без sync, но долго. Этим самым мы проверим возможности диска по 92 | оптимизации. Долго -- потому что нужно нивелировать результы первых записей 93 | в кеш диска. Кеш диска отключать нельзя так как это потенциально отключает 94 | оптимизации в контроллере диска. 95 | 96 | SSD под журнал 97 | -------------- 98 | 99 | .. _wal_bench: 100 | 101 | Линейная запись мелкими блоками в один поток. 102 | Журнал в системах хранилища использует именно такой паттерн (см. filestore_wal_). 103 | 104 | .. code-block:: sh 105 | 106 | fio --ioengine=libaio --direct=1 --name=test --runtime=60 --filename=/dev/sdX \ 107 | --bs=4k --rw=write --sync 108 | 109 | На типичном HDD 7200 об/мин. этот тест покажет 7200 / 60 = 120 оп./сек. 110 | На SSD результаты могут очень сильно отличаться -- от 200 IOPS до 250000 IOPS (NVME). 111 | TODO: примеры по конкретным моделям. 112 | 113 | Для FileStore, в журнал пишется весь объём данных, так что размер блока в реальности 114 | будет случайным, нужно попробовать разные размеры блока (от 4k до 4 MB) чтобы понять 115 | производительность журнала на различных операциях. 116 | 117 | Неразобранное 118 | ------------- 119 | 120 | SSD с (супер)конденсаторами позволяют успеть сбросить кэш во флеш-память при 121 | потере питания -- и просто игнорировать запросы fsync. Конденсаторы в описаниях 122 | обычно называются "enhanced/advanced power loss protection". Этой характеристикой 123 | часто обладают "серверные" SSD. Например, в Intel DC S3100 конденсаторов нет, 124 | а в Intel DC S4600 есть. Лучше SATA SSD с конденсаторами, чем NVMe без. Обычная 125 | NVMe будет точно так же тормозить при синхронизации. 126 | 127 | hdparm, blkdiscard, smartctl (sata mode), CPU idlemode 128 | TODO: написать как интерпретировать результат. 129 | выставить шедулер диска. 130 | узнать юзает ли цеф пейджкеш (директ или нет) 131 | fsync vs fdatasync vs sync 132 | -------------------------------------------------------------------------------- /bench.rst: -------------------------------------------------------------------------------- 1 | *********** 2 | Бенчмаркинг 3 | *********** 4 | 5 | Важным моментом при бенчмаркинге является правильный выбор настроек и железа 6 | на КЛИЕНТСКОМ компьютере. Для бенчмаркинга затрагивающего сеть лучше всего 7 | запускать тест на compute-node, или другими словами, на том сервере где будет 8 | работать клиентское по отношению к Ceph приложение. 9 | 10 | .. include:: bench-disks.rst 11 | 12 | Бенчмаркинг CPU 13 | =============== 14 | 15 | .. code-block:: sh 16 | 17 | openssl speed 18 | 19 | Бенчмаркинг памяти 20 | ================== 21 | 22 | .. code-block:: sh 23 | 24 | sysbench memory --threads=1 --memory-block-size=1M run 25 | 26 | .. code-block:: sh 27 | 28 | sysbench memory --threads=8 --memory-block-size=1M run 29 | 30 | Бенчмаркинг сети 31 | ================ 32 | 33 | * На каждом ноде запускаем iperf3-сервер командой ``iperf3 -s``. 34 | https://arr4.wordpress.com/2016/04/21/iperf3-on-fedora-23-as-a-service ? 35 | 36 | * На сервере, который будет потенциальным клиентом запускаем ``iperf3 -с YOUR_NODE_IP``. 37 | Для тестировния внутрикластерной сети -- аналогично, но запускаем клиентскую часть 38 | на одном из нодов. Чтобы протестировать трафик в противоположном направлении, есть 39 | ключ ``-R``. Для теста UDP нужны дополнительные параметры клиента ``-u -b 0``. 40 | 41 | * TODO: как инетпретировать результаты. 42 | 43 | Бенчмаркинг Rados 44 | ================= 45 | 46 | IOPS через rados bench в режиме, соответствующем RBD (4 Кб блоки в 4 Мб объектах) 47 | и 16 одновременно запущенных виртуалок: 48 | 49 | .. code-block:: sh 50 | 51 | rados bench -p YOUR_POOL -t 16 -b 4096 -o $((4096 * 1024)) 60 write 52 | 53 | Ввиду выполняемых запросов одновременно на нескольких дисках, 54 | тест должен показать "хорошие" результаты. Зависит от многих факторов 55 | (сети, CPU, количества реплик, Erasure Coding, версии Ceph и фазы Луны). 56 | 57 | Бенчмаркинг отдельного OSD 58 | ========================== 59 | 60 | .. code-block:: sh 61 | 62 | ceph tell osd.N bench [TOTAL_DATA_BYTES] [BYTES_PER_WRITE] 63 | 64 | Тест почти бессмысленный, ибо выполняется отдельным ОСД без учёта сети со 65 | странными паттернами нагрузки. Имеет смысл сравнивать полученные цифры с fio 66 | на этих же дисках. 67 | 68 | Бенчмаркинг отдельного OSD через librados 69 | ========================================= 70 | 71 | IOPS при записи в объект всегда равно IOPS самого медленного OSD среди acting set 72 | соответствующей PG. Поэтому важно найти такие медленные OSD. Для этого написана 73 | специальная утилита: https://github.com/socketpair/ceph-bench 74 | 75 | Для работы этой утилиты нужен пул размером 1 с тем же правилом что и production пул. 76 | Утилита работает через librados (не используя RBD), подбирает для тестов такие 77 | названия объектов чтобы они лежали на конкретных OSD и производит запись в них. 78 | Утилита на питоне, так что для all-flash стораджей и 10 Гбит/с может упереться в CPU. 79 | 80 | Бенчмаркинг RBD 81 | =============== 82 | 83 | Производительность может отличаться на заполненном (allocated) и незаполненном 84 | RBD-образе. TODO: Написать как БЫСТРО заполнить тестовый образ. Учесть сжатие в 85 | Bluestore. 86 | 87 | * Прямой через rbd bench 88 | (https://tracker.ceph.com/projects/ceph/wiki/Benchmark_Ceph_Cluster_Performance) 89 | 90 | * Прямой (fio + librbd). Говорят, fio врёт с драйвером librbd. 91 | 92 | * Замапленный (fio поверх /dev/rbd0) 93 | 94 | * Fio изнутри виртуалки. Параллельной нагрузки она не создаст -- qemu rbd 95 | драйвер работает в один поток. Это непроверенная информация. 96 | -------------------------------------------------------------------------------- /bluestore.rst: -------------------------------------------------------------------------------- 1 | ********* 2 | Bluestore 3 | ********* 4 | 5 | * Снапшоты в блюсторе эффективнее чем в Filestore. В Filestore при изменении 6 | одного бита в обьекте -- копируется весь объект. В блюсторе я так понял, система 7 | слоёв. Но это не точно, нужны пруфы. 8 | * Насчёт выбора размера БД: Google + "recommended rocksdb/rockswal sizes when using SSD/HDD" 9 | * TODO: Как посмотреть текущий размер БД ? 10 | * WAL находится в БД. БД находится в блюсторе. Если вынести БД то она вместе 11 | с журналом выносится. Вроде (нужен пруф) БД устроена так что самые горячие 12 | данные хранятся в её начале. Если БД не вмещается под отведённое место (если 13 | она выносная) то часть БД хранится отдельно, а часть в основном хранилище. 14 | * Нет возможности после создания БД встроенной вынести её отдельно. Аналогично 15 | с её WAL. 16 | 17 | * Настройки блюстора: 18 | 19 | .. code:: 20 | 21 | bluestore_cache_size = 536870912 22 | bluestore_prefer_deferred_size_hdd = 104857600 23 | bluestore_prefer_deferred_size_ssd = 104857600 24 | bluestore_prefer_deferred_size = 104857600 25 | 26 | в т.ч. так как не понятно, понял ли что диск rotational. 27 | 28 | * По исходникам смотрел -- он определяет что диск rotational и из этого делает 29 | вывод SSD или нет. В том числе при старте OSD оно смотрит не назначен ли класс 30 | OSD и ставит ssd/hdd на основании этого. А ещё применяет разные настройки в 31 | зависимости от этого. Bcache (всегда?) ставит флаг что диск что non-rotational 32 | ДАЖЕ ЕСЛИ РЕАЛЬНЫЙ КЕШ НЕ ПРИАТТАЧЕН к кеш-девайсу. 33 | -------------------------------------------------------------------------------- /ceph-choice.rst: -------------------------------------------------------------------------------- 1 | ****************** 2 | Нужен ли вам Ceph? 3 | ****************** 4 | 5 | Когда НЕ нужен 6 | ============== 7 | 8 | * У вас нет экспертизы в Linux. Если вы с большим трудом умеете работать в 9 | консоли, то Ceph не для вас. 10 | 11 | * У вас нет денег на 10G сеть и серверные SSD. Кластер на десктопном железе 12 | заработает, но на performance tuning его может уйти очень много времени. 13 | 14 | * Ваш SSD выдает меньше 10K IOPS в один поток (s sync). Это минимальные 15 | системные требования для тех кто решил пробовать на desktop железе. 16 | 17 | * Cross-DC для образов виртуальных машин (неприемлемые задержки). 18 | 19 | * Меньше 5 серверов для production кластера. Для тестов вполне хватит и трёх. 20 | 21 | * Малое S3-хранилище. Для 100 тыс. картинок и minio неплох. 22 | 23 | * Огромное S3-хранилище. Миллиард объектов в Ceph будут болью, лучше рассмотреть 24 | иные решения, например, поверх чистых k-v хранилищ. 25 | 26 | * iscsi + rbd. Очень сложно. 27 | 28 | * Когда все данные вмещаются на один сервер. Нужно 50ТБ? Соберите RAID. 29 | 30 | 31 | Когда стоит задуматься о Ceph? 32 | ============================== 33 | 34 | * Большое количество статических файлов, например, для разадчи по WEB через S3. 35 | Однако, мелкие (размером меньше килобайта) файлы хранить будет болезненно. 36 | 37 | * Если требуется S3 cross-DC. google: radosgw federation 38 | 39 | * Вы строите частное облако -- Сeph совсем не идеален, но все остальные 40 | opensource еще хуже. 41 | 42 | * Shared Storage для виртуальных машин. Очень спорная тема, но иногда другого 43 | выхода нет. 44 | -------------------------------------------------------------------------------- /cephfs.rst: -------------------------------------------------------------------------------- 1 | ****** 2 | CephFS 3 | ****** 4 | 5 | Хранить образы виртуалок на CephFS -- полный маразм. 6 | -------------------------------------------------------------------------------- /cloudmouse.rst: -------------------------------------------------------------------------------- 1 | ********** 2 | CloudMouse 3 | ********** 4 | 5 | .. image:: _static/cloudmouse.png 6 | :alt: Логотип 7 | :align: left 8 | 9 | VPS-хостинг. Год основания -- 2013. Отличились тем, что использовали Ceph крайне неумело, 10 | что привело 10.02.2015 к резкой гибели их бизнеса в связи с полной потерей данных (бекапы 11 | они не делали). 12 | Потом везде на форумах кричали, что Ceph -- глючное поделие и именно он привёл к проблеме. 13 | Эта ситуация нанеслa огромный урон репутации Ceph как надёжного хранилища данных. 14 | 15 | Между тем, в Сети крайне трудно найти информацию о том что же именно произошло. Эта ситуация 16 | сейчас используется при каждом удобном и неудобном случае когда кто-то хочет сказать что у 17 | Ceph есть проблемы. 18 | 19 | .. pull-quote:: 20 | 21 | Недавно, на выставке РИТ++, мне довелось поговорить со специалистом из компании, которая работает на рынке облачного хостинга под брендом flops.ru. Эта компания известна тем, что использует как раз Ceph и построила на нем платформу публичного облачного хостинга. Интересные ребята, кстати, энтузиасты и большие молодцы, серьезно. Я воспользовался случаем узнать «из первых рук» их компетентное мнение о том, насколько реально «скачать Ceph и сделать все то же самое на нем». Ответ был однозначен: «Это утопия». 22 | Так, в частности, он рассказал, что они в flops потратили на доводку, допиливание и вычищение багов примерно полтора года труда их команды разработчиков. Они взяли довольно старую версию (v 0.67 «Dumpling») и «пилили» ее. И в итоге действительно допилили ее до продакшна. Текущая же версия, в том виде, в котором она выложена в паблик, несмотря на major и stable в названии, в продакшн непригодна. 23 | «Помните историю cloudmouse, который, в результате слова бага и сбоя в марте этого года потерял данные 22 тысяч виртуальных машин (включая их бэкапы, а перед этим они теряли данные в феврале) и, в результате, ушел из бизнеса? Ребята взяли текущую версию Ceph, и сделали свою систему на ней. Результат — вот такой.» 24 | Собственно мне больше нечего добавить к этому ответу на вопрос, «можно ли скачать Ceph и сделать бесплатно то же самое, что у вас за деньги?». 25 | Можно. Но не сразу, не быстро, и, по факту, не бесплатно. 26 | 27 | -- http://blog.in-a-nutshell.ru/nutanix-vs-ceph/ 28 | 29 | .. pull-quote:: 30 | 31 | В результате некого «аппаратного сбоя» компания потеряла около 22 000 виртуальных машин своих 32 | клиентов без возможности восстановления. При этом ни о какой компенсации речи и не шло, при 33 | этом, техническая поддержка держала своих клиентов в неведении около 1,5 суток. 34 | 35 | -- https://1spla.ru/blog/kak_ne_nujno_delati_oblako 36 | 37 | .. pull-quote:: 38 | 39 | Честно вам сказать из-за чего развалился? Ибо сам даже смотрел их кластер и пытался 40 | помочь... Помнится мне, что тогда еще актуальная версия Ceph'а была Firefly. 41 | Но им жутко не нравилась его производительность. Ну они и обновились, на в то время, 42 | не стабильный hammer. А когда пошли ошибки, то потом ещё и обновились аж на master ветку. 43 | А у мастер ветки была проблема связанная с утечкой памяти, ну и при нехватке памяти на 44 | сервере (еще один баг) убились данные. И количество репликаций у них было 2. Хотя и 45 | количество репликации бы тут не помогли. Так что Ceph там был не при чём. Банально админы 46 | накосячили, ну или их руководство. 47 | 48 | -- Аноним. 49 | 50 | 51 | .. pull-quote:: 52 | 53 | И вроде еще вместо бекапов снапшоты использовали. 54 | 55 | -- `@socketpair `_ 56 | 57 | .. pull-quote:: 58 | 59 | Спасибо всем пользователям, кто понял ситуацию, остался и создают виртуальные машины. 60 | Они действительно стали работать в 10-40раз быстрее, и это не связано с нагрузкой на облако. 61 | 62 | По поводу СХД, мы используем как минимум 8, с 3х кратной репликацией данных. 63 | Те "кусочек данных размером 1мб" хранится на 3х разных дисках на 3х СХД. А все данные хранятся 64 | примерно на 300+х дисках. Как мы ранее сообщали, проблема потери данных была связана с 65 | аппаратно-програмным сбоем в связки: Ceph+rbd+osd+pg. Другими словами, все связи между блоками 66 | данных в кластере были утеряны. 67 | 68 | Еще раз, приносим свои извинения. 69 | По обращению в тикеты, мы помогаем настраивать сервера. 70 | По поводу компенсаций, мы планируем их зачислить на балансы в ближайшие дни. 71 | 72 | P.s. мы понимаем свою вину перед пользователи, но уверяем вас, мы нашли причины и исправили их. 73 | А многим облачным компаниям, еще только предстоит ее найти. 74 | 75 | -- https://searchengines.guru/showpost.php?p=13490140 76 | 77 | .. pull-quote:: 78 | 79 | Судя по тому, что никаких технических подробностей этого падения они не привели, 80 | косяк на сто процентов их, а не Ceph'a. Очевидно, что был бы это глюк Ceph'a они 81 | бы молчать не стали, защитили бы свою репутацию. 82 | 83 | -- https://www.linux.org.ru/news/opensource/11500740/page1#comment-11503052 84 | 85 | Ccылки: 86 | 87 | * https://habrahabr.ru/post/252221 88 | * https://habrahabr.ru/post/250097 89 | * https://1spla.ru/blog/kak_ne_nujno_delati_oblako 90 | * https://go.backupland.com/crash/clodemouse_deleted_vds/clodemouse_deleted_vds.html 91 | -------------------------------------------------------------------------------- /conf.py: -------------------------------------------------------------------------------- 1 | #!/usr/bin/env python3 2 | import datetime 3 | 4 | # Add any Sphinx extension module names here, as strings. They can be 5 | # extensions coming with Sphinx (named 'sphinx.ext.*') or your custom 6 | # ones. 7 | extensions = ['sphinx.ext.intersphinx', 8 | 'sphinx.ext.todo', 9 | 'sphinx.ext.mathjax', 10 | 'sphinx.ext.githubpages'] 11 | 12 | # Add any paths that contain templates here, relative to this directory. 13 | templates_path = ['_templates'] 14 | source_suffix = '.rst' 15 | master_doc = 'index' 16 | 17 | # General information about the project. 18 | project = 'Заметки о Ceph' 19 | author = 'Коренберг Марк' 20 | copyright = '%d, %s' % (datetime.datetime.now().year, author) 21 | 22 | # The version info for the project you're documenting, acts as replacement for 23 | # |version| and |release|, also used in various other places throughout the 24 | # built documents. 25 | # 26 | # The short X.Y version. 27 | version = '1.0' 28 | # The full version, including alpha/beta/rc tags. 29 | release = '1.0' 30 | language = 'ru' 31 | 32 | html_theme = "sphinx_rtd_theme" 33 | html_static_path = ['_static'] 34 | htmlhelp_basename = 'CephFAQdoc' 35 | # https://sphinx-rtd-theme.readthedocs.io/en/latest/ 36 | html_show_sourcelink = False 37 | html_theme_options = { 38 | 'display_version': False, 39 | } 40 | 41 | latex_elements = { 42 | # The paper size ('letterpaper' or 'a4paper'). 43 | # 44 | # 'papersize': 'letterpaper', 45 | 46 | # The font size ('10pt', '11pt' or '12pt'). 47 | # 48 | # 'pointsize': '10pt', 49 | 50 | # Additional stuff for the LaTeX preamble. 51 | # 52 | # 'preamble': '', 53 | 54 | # Latex figure (float) alignment 55 | # 56 | # 'figure_align': 'htbp', 57 | } 58 | 59 | # Grouping the document tree into LaTeX files. List of tuples 60 | # (source start file, target name, title, 61 | # author, documentclass [howto, manual, or own class]). 62 | latex_documents = [ 63 | (master_doc, 'CephFAQ.tex', project, author, 'manual'), 64 | ] 65 | -------------------------------------------------------------------------------- /cpu_and_mem.rst: -------------------------------------------------------------------------------- 1 | ******************* 2 | Процессоры и память 3 | ******************* 4 | 5 | * Для Ceph-нодов требуется (а не просто рекомендуется) память с ECC. Сбой в памяти 6 | мастер-OSD в acting set приведёт к необнаруживаемому повреждению данных 7 | даже если это BlueStore со своим CRC32c. Данные могут повредиться до 8 | подсчёта CRC32 и распространиться по slave-OSD. 9 | 10 | Немного близкая тема и про клиентов. Если данные испорчены до подсчёта 11 | CRC32 в рамках протокола мессенджера Ceph, то они будут повреждены и это 12 | не обнаружится. 13 | 14 | * CPU Governor & powersave mode. Отличная статья в арче: 15 | https://wiki.archlinux.org/index.php/CPU_frequency_scaling 16 | 17 | * CRC32 аппаратное в блюсторе (и в месенджере не с блюстором?) 18 | * Гипертрединг не нужен. Потому что это просто доп-набор регистров. 19 | В Ceph нет CPU-bound задач. Есть CRC32, но оно реализуется через спец команду 20 | в sse4.3, а такой блок ЕМНИП один на ядро. Однако, при сжатии в блюсторе может иметь 21 | значение. 22 | * ramspeed = ramsmp 23 | * cpuburn 24 | * i7z, powertop 25 | * cpupower frequency-info, how to set governor (+permanently) 26 | * grub + nopti + performance + luacode + meltdown 27 | -------------------------------------------------------------------------------- /developing.rst: -------------------------------------------------------------------------------- 1 | ***************** 2 | Для разработчиков 3 | ***************** 4 | 5 | Документированное 6 | ================= 7 | 8 | * Багтрекер: https://tracker.ceph.com/projects/ceph 9 | * Расписание релизов: http://docs.ceph.com/docs/master/releases/schedule 10 | * Github: https://github.com/ceph/ceph 11 | 12 | Недокументированное 13 | =================== 14 | 15 | * Trello со списком актуальных задач: https://trello.com/cephstorage 16 | -------------------------------------------------------------------------------- /disks.rst: -------------------------------------------------------------------------------- 1 | ***** 2 | Диски 3 | ***** 4 | 5 | Неразобранные мысли 6 | =================== 7 | 8 | * Не имеет никакого смысла использовать рэйды как хранилище для Ceph. Здесь 9 | имеется в виду какой-либо способ программного или аппаратного объединения 10 | дисков в один виртуальный. Потенциальные проблемы: 11 | 12 | * Опасность обмана команд по сбросу кеша. Например, включенный Writeback на 13 | аппартаном RAID без BBU. 14 | 15 | * Программный RAID (mdadm, зеркало) ПОВРЕЖДАЕТ данные при записи в режиме 16 | O_DIRECT если в процессе записи страница меняется в параллельном потоке. 17 | В этом случае ПОДТВЕРЖДЁННЫЕ данные будут различаться в половинках 18 | зеркального рэйда. При следующем (scrub?) рэйда будут проблемы. 19 | TODO: Нужен proof. 20 | 21 | * Программные рэйды не защищают от сбоя питания -- да, разумеется вышестоящие 22 | FS/БД должны быть готовы к повреждению неподтверждённых данных, но при 23 | проверке (scrub?) различие данных на репликах приведёт к проблемам. 24 | 25 | * Во время смерти диска RAID находится в состоянии degraded пока не добавят 26 | новый диск. Либо нужен spare-диск который в случае с Ceph глупо не 27 | использовать. Degraded RAID внезапно для Ceph будет давать худшие 28 | характеристики пока не восстановится. RAID не знает какие данные нужны а 29 | какие -- нет, поэтому процесс восстановления реплик -- долгий -- 30 | синхронизирует мусор либо нули. 31 | 32 | * Для RAID нужны диски одинакового размера. Для Ceph это не требуется. 33 | 34 | * Аппаратные рэйды нужно отдельно мониторить и администрировать. 35 | 36 | * Зеркало не нужно потому что Ceph сам сделает столько реплик сколько 37 | требуется. Страйпинг не нужен потому что повышение производительности 38 | делается другими способами (с помощью SSD). Raid 5,6 в случае дегрейда 39 | причиняет боль. 40 | 41 | * В общем и целом, Ceph можно рассматривать как огромный распределённый RAID. 42 | Зачем делать RAID состоящий из RAID не понятно. 43 | 44 | * Акустик, хпа, паверсейвинг, настроить автотесты по смарту. 45 | * отдискардить ссд перед использованием. 46 | * fstrim -v -a (filestore on ssd), blkdiscard on LVM/Partition. 47 | * мониторить смарт 48 | * как бенчить - ссд и разного рода коммерческий обман. деградация изза недискарда - надо дать 49 | продыхнуть, некоторое количество быстрых ячеек и тиринг на них. суперкапазиторы. перегрев ссд и тхроттлинг 50 | * бенчмаркинг несколько дисков одновременно ибо контроллеры. 51 | * на ссд обновлять прошивки критично важно. ещё про блеклисты в ядрах насчёт багов. 52 | * дискард на них медленный, поэтому лучше оставить продискарденную область и этого достаточно. 53 | * жеоательно не ставить одинаковые диски с одинаковым юсаджем - ибо умрут скорее всего одновременно 54 | ибо нагрузка примерно одинаковая. 55 | * Диск шедулеры 56 | * имхо магнитные сас-диски не нужны. их возможности не будут задействованы для получения преимущества 57 | перед сата. Сата 12 гбит для магнитных дисков не нужен. Для магнитных (7200 оборотов) 58 | даже сата2 (3 гбит ~ 300 МБ/сек) хватит. 59 | * убедиться что диски подключены как сата6. 60 | * чего ожидать от бенчмаркинга. реальная таблица с реальными моделями. 61 | * при бенчмаркинге ссд может оказаться что уперлись в контроллер а не в диск. 62 | * NCQ, 7200 и 180 IOPS. 32 для большей возможности выбора в диске. Также как посчитать теоретические иопсы. 63 | 64 | 65 | Типы SSD 66 | ======== 67 | 68 | Все SSD условно можно разделить на категории: 69 | 70 | * Consumer SATA (потребительские). Их ставят в ноутбуки и обычные компьютеры. 71 | Такие диски под нагрузкой могут вести себя непредсказуемо. Показатели 72 | могут меняться внезапно. Некоторые имеют производительность сравнимую с HDD 73 | или даже USB-flash. 74 | 75 | * Enterprise SATA (серверные). С защитой от сбоев по 76 | питанию и проверкой целостности данных. Например, линейка Intel DC имеет 77 | поддержку технологий power loss protection и end-to-end data protection. 78 | Такие диски производят только Intel, Fujitsu, и немного Samsung. Эти диски 79 | дают стабильные и предсказуемые показатели под нагрузкой. 80 | 81 | * NVMe SSD. Вставляются в PCIe разъемы и позволяют обойти ограничение SATA 82 | интерфейса в 6 Gbit/s ( ~500-550 MB/s ). NVMe SSD по сравнению с SATA SSD 83 | дают лучшие результаты в плане задержек и IOPS. 84 | 85 | Планировщики IO 86 | =============== 87 | 88 | Планировщик -- это подсистема ядра, которая отвечает за обработку запросов IO 89 | и их передачу драйверу устройства. Планировщик задумывался как "умная" прослойка 90 | между софтом и железом, которая бы упорядочивала хаотичный поток запросов от 91 | приложений и делала бы его оптимальным для обработки на стороне устройства 92 | хранения. Для классических SAS/SATA дисков есть несколько планировщиков: 93 | 94 | * cfq -- планировщик, предназнaченный для десктопной нагрузки, по умолчанию 95 | имеет 64 очереди с разными классификаторами и весами. НЕ РЕКОМЕНДУЕТСЯ для 96 | SSD. (А ПОЧЕМУ?) 97 | 98 | * deadline -- планировщик с 4 очередями, 2 для запросов на чтение и 2 для 99 | запросов на запись. Рекомендуется для аппаратных RAID (ПОЧЕМУ?). 100 | 101 | * noop -- планировщик с 2 очередями, не имеет алгоритмов сортировки и слияния 102 | запросов. Рекомендуется для SSD, так как для SSD не нужно двигать головку и 103 | оптимизировать ее перемещение. Рекомендуется включать в виртуальных машинах. 104 | 105 | С развитием SSD/NVMe появилась технология blk-mq (Multi-Queue Block IO Queueing 106 | Mechanism). Она позволяет обрабатывать IO запросы паралелльно в несколько 107 | очередей. По сути blk-mq не является планировщиком, а является частью драйвера (КАКОГО?). 108 | Рекомендуется для серверных SSD и NVMe. 109 | 110 | * Начиная с ядра Linux 4.12, для blk-mq появились свои планировщики: 111 | 112 | * bfq -- аналог cfq для десктопных ворклоадов. 113 | 114 | * mq-deadline -- аналог deadline. 115 | 116 | * kyber -- аналог noop. 117 | -------------------------------------------------------------------------------- /how-it-works.rst: -------------------------------------------------------------------------------- 1 | ************ 2 | Как работает 3 | ************ 4 | 5 | * Tiering vs bcache vs dm-cache + инструкции по дмкешу. 6 | * почему дедупликация крайне затруднена в архитектуре Ceph 7 | * 8 | .. _filestore_wal: 9 | 10 | В filestore всё полностью пишется в журнал. WAL используется как 11 | writeback-cache по сути. Один write в rados превращается в два сисколла write 12 | -- один в журнал (с синком) и один в основное хранилище. Основное хранилище фсинкается 13 | время от времени. Запись в журнал линейная, а в основное хранилище рандомная. При записи 14 | в хранилище поможет параллельность которую может диск (например, NCQ). При записи в журнал 15 | параллельность не используется, поэтому диск под журнал для файлстора надо бенчить именно 16 | так: wal_bench_. 17 | 18 | * при выносе журнала или БД на отдельный диск теряется возможность перевставлять диски в 19 | другой нод. При старте ОСД (бай дефолт есть параметр) обновляет себя в крушмапе. 20 | * При потере журнала вседиски на него зааттаченные превращаются в труху 21 | * При потере данных всех мониторов теряется весь кластер. 22 | * Нужно использовать именно три реплики потому что если две - то при скраб ерроре не понятно 23 | кому верить 24 | * запись и чтение делается исключительно с мастера в актинг сете. При записи данные 25 | отправляются на мастер осд а он по кластер-сети отправляет параллельно на два слейва. 26 | on_safe-коллбэк клиента вызывается когда данные записались в WAL на всех репликах. 27 | Дожидания прописывания в основное хранилище в принципе нет. Есть коллбэк когда данные 28 | есть в памяти на всех трёх репликах. 29 | * бкеш врёт относительно ротейшионал и цеф использует не те настройки. Бкеш writeback 30 | (кеширование записи) не нужен потому что с файлстором это делается через WAL, а с 31 | блюстором есть опция по записи даже больших запросов в БД которую нужно вынести на ССД. 32 | С чтением тоже не нужен потому что: 33 | 34 | #. виртуалки с рбд и так не плохо кешируют то что уже читали 35 | 36 | #. запись потребляет в 3 раза больше иопсов (размер пула=3). а на самом деле ещё больше по 37 | причине двойной записи и даже ещё больше если это файлстор. Чтение требует один-в-один. 38 | поэтому цеф на чтение хорош. 39 | 40 | #. Нормальный кеш делает через тиеринг в цефе (но это не точно). 41 | 42 | * Описание цифр в ceph -s. откуда берутся цифры и что они означают. 43 | * Как посчитать реальную вместимость кластера. мин. загруженность осд. 44 | * сколько должен давать кластер иопсов и мегабайтов в секунду на чтение и на запись. 45 | какие паттерны использования и параллельность. 46 | * ceph-deploy требует GPT. Размер журнала и БД надо выставлять. 47 | * Инструкцию по перемещению журнала на другое место для файлстора. и факт что это невозможно для блюстора. 48 | * понимание, что ИО одного и того же обжекта (или 4-мб-блока в рбд) никак не распараллеливается магически. 49 | и оно будет равно иопсам журнала или осн. хранилища. 50 | * почему мелкие объекты плохо в радосе и большие тоже плохо. 51 | * почему при убирании диска надо сначала сделать цеф осд аут, а не просто вырубить диск. 52 | * для более быстрой перезагрузки используйте kexec. systemctl kexec. однако с кривым железом может 53 | не работать (сетёвки и рейды/хба). 54 | * https://habrahabr.ru/post/313644/ 55 | * почему size=3 min_size=1 (size 3/1) моежт привести к проблемам. 56 | * Каждая пг устанавливает свой кворум таким образом много 57 | * ссылка на калькулятор количества ПГ. почему много пг плохо и мало пг тоже плохо. 58 | 59 | * http://ceph.com/pgcalc 60 | 61 | * если мало - то неравномерность, потенциально не все осд могут быть заюзаны. 62 | 63 | * если много - юсадж памяти, перегрузка сети 64 | -------------------------------------------------------------------------------- /how_to_remove_osd.rst: -------------------------------------------------------------------------------- 1 | *************** 2 | Как удалить OSD 3 | *************** 4 | 5 | Для примера будем удалять `osd.42`. 6 | 7 | #. ``ceph osd out osd.42``. Эта команда заставит Ceph перенести все данные с 8 | этого диска на другие диски без даже вре́менного понижения количества реплик. 9 | #. Мониторить ``ceph osd safe-to-destroy``. 10 | #. На ноде: ``sudo systemctl stop ceph-osd@42``. 11 | #. ``ceph osd purge osd.42``. 12 | 13 | Дальнейшие операцию производятся на ноде под правами root: 14 | 15 | #. Посмотреть и запомнить вывод ``lsblk -f``. Пригодится далее для ``wipefs``. 16 | #. Посмотреть и запомнить ``readlink -f /var/lib/ceph/osd/ceph-42/*`` 17 | (Пригодится для удаления журнального раздела если он выносной). 18 | #. ``umount /var/lib/ceph/osd/ceph-42``. 19 | #. ``rmdir /var/lib/ceph/osd/ceph-42``. 20 | #. ``wipefs -a /dev/{data-disk-partition(s)}``. см. сохранённый вывод ``lsblk``. 21 | #. ``wipefs -a /dev/{data-disk}``. см. сохранённый вывод ``lsblk``. 22 | #. Если выносной журнал/бд: ``fdisk /dev/{journal-disk}``, удалить 23 | соответствующий раздел. Современный fdisk умеет работать с GPT. 24 | какой именно раздел -- см. сохранённый вывод ``readlink``. 25 | #. ``partprobe /dev/{journal-disk}``. fdisk не умеет говорить ядру о применении 26 | измененной таблицы разделов если диск используется (например, под другие 27 | журналы/бд на этом же диске. Эта тулза из комплекта parted. 28 | #. Перед извлечением диска физически на лету, выполнить: 29 | ``echo 1 > /sys/block/{data-disk}/device/delete``. 30 | -------------------------------------------------------------------------------- /index.rst: -------------------------------------------------------------------------------- 1 | ============== 2 | Заметки о Ceph 3 | ============== 4 | 5 | .. toctree:: 6 | :maxdepth: 2 7 | :caption: Содержание: 8 | 9 | about 10 | developing 11 | ceph-choice 12 | upgrade-to-luminous 13 | rbd 14 | bench 15 | bluestore 16 | cephfs 17 | cpu_and_mem 18 | disks 19 | how-it-works 20 | how_to_remove_osd 21 | monitoring 22 | network 23 | tuning 24 | cloudmouse 25 | rookio 26 | see_also 27 | -------------------------------------------------------------------------------- /monitoring.rst: -------------------------------------------------------------------------------- 1 | ********** 2 | Мониторинг 3 | ********** 4 | 5 | * два вида экспортеров под прометеус 6 | * мониторить температуры, свап, иопсы (латенси) дисков 7 | -------------------------------------------------------------------------------- /network.rst: -------------------------------------------------------------------------------- 1 | **** 2 | Сеть 3 | **** 4 | 5 | * что бек сеть надо точно 10 гигабит. привести расчёты. 6 | * Отключить оффлоадинг (и как проверить помогло ли) - меряем RTT внутри TCP. 7 | * джамбофреймы могут помочь но не особо. сложности со свичами обычно. 8 | * мониторить состояние линка. оно иногда самопроизвольно падает с гигабита на 100 мегабит. 9 | * Тюнинг TCP/IP - отключать контрак 10 | -------------------------------------------------------------------------------- /rbd-qemu.rst: -------------------------------------------------------------------------------- 1 | RBD, Qemu и discard 2 | =================== 3 | 4 | И Ceph (RBD) и Qemu умеют в discard/trim/unmap. Это означает, что гостевая ОС 5 | может отправить соответствующий запрос к хранилищу, чтобы сообщить что данные не 6 | нужны. Исходно это было предназначено для SSD-дисков с целью оптимизации 7 | wear-leveling (выравнивание износа). В RBD это позволяет удалить ненужные данные 8 | из кластера и тем самым уменьшить бекфиллинг, размеры снапшотов и др. 9 | 10 | Мы знаем, что RBD виртуально делит диски на куски по 4 МБ (по-умолчанию). Каждый 11 | кусок -- это один объект Rados. Соответственно, дискард может либо удалить целиком 12 | один объект (если он не нужен), либо сократить размер (вплоть до нуля). Что он не может 13 | -- так это продискардить середину объекта или начало. Он мог бы просто заполнить нулями, 14 | но нет. Появляется ошибка, правда, не фатальная. В API RBD нет функции для 15 | выяснения размера чанка. Поэтому Qemu не может догадаться какие дискарды можно отправлять 16 | в librbd, а какие закончатся ошибкой. В документации про это ничего не сказано. 17 | 18 | Есть костыль для ceph.conf -- параметр ``rbd_skip_partial_discard``. Однако: 19 | 20 | * http://tracker.ceph.com/issues/16386 21 | * http://tracker.ceph.com/issues/16869 22 | 23 | В связи с чем, лучше проинструктировать Qemu чтобы она сообщила в гостевую об 24 | имеющемся выравнивании в 4 МБ. Тогда ядро гостевой ОС не будет отправлять дискарды 25 | которые невозможно выполнить в RBD. 26 | 27 | К сожалению, libvirt напрямую не может указать это для каждого диска персонально. 28 | Но есть костыль: 29 | 30 | .. code-block:: xml 31 | 32 | 33 | 34 | 35 | 36 | 37 | ... 38 | 39 | 49 | 50 | ... 51 | 52 | 53 | 54 | .. important:: 55 | 56 | ``xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'`` крайне важен. 57 | Без этой строки ```` будет проигнорирован. Проверить 58 | можно повторно отредактировав описание ВЫКЛЮЧЕНОЙ виртуальной машины 59 | ``virsh edit some-domain`` 60 | 61 | Данный фрагмент будет работать только для virtio-scsi. Для IDE аналогично, 62 | но мне неизвестно как :). 63 | 64 | (Пример по ссылке http://docs.ceph.com/docs/master/rbd/qemu-rbd похоже что 65 | устарел и не работает) 66 | 67 | Для справки есть ещё такие параметры: 68 | 69 | * ``logical_block_size`` 70 | * ``physical_block_size`` 71 | * ``min_io_size`` 72 | * ``opt_io_size`` 73 | 74 | .. important:: 75 | 76 | Discard будет работать только для виртуальных дисковых интерфейсов IDE и 77 | virtio-scsi. Не путайте virtio и virtio-scsi -- это два совершенно разных 78 | интерфейса. virtio устарел и более не развивается. В гостевой ОС 79 | virtio-scsi выглядит как ``/dev/sd*``, а virtio как ``/dev/vd*``. 80 | 81 | 82 | Их всех можно посмотреть командой ``lsblk`` в гостевой ОС чтобы удостовериться, 83 | что виртуальная машина настроена правильно 84 | (``DISC-GRAN`` равен размеру чанка в RBD): 85 | 86 | .. code:: 87 | 88 | $ lsblk -D 89 | NAME DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO 90 | sda 0 4M 1G 0 91 | ├─sda1 4176896 4M 1G 0 92 | ├─sda2 3145728 4M 1G 0 93 | └─sda3 3145728 4M 1G 0 94 | 95 | $ lsblk -t 96 | NAME ALIGNMENT MIN-IO OPT-IO PHY-SEC LOG-SEC ROTA SCHED RQ-SIZE RA WSAME 97 | sda 0 512 0 512 512 1 deadline 128 128 2G 98 | ├─sda1 0 512 0 512 512 1 deadline 128 128 2G 99 | ├─sda2 0 512 0 512 512 1 deadline 128 128 2G 100 | └─sda3 0 512 0 512 512 1 deadline 128 128 2G 101 | 102 | 103 | Чтобы это заработало полностью, нужно не только убедиться что эта возможность 104 | появилась на блочном уровне в гостевой ОС, но и чтобы гостевая ОС 105 | использовала эту функцию. 106 | 107 | Linux 108 | ----- 109 | 110 | * ``fstrim -v -a``. Вручную, либо по расписанию (раз в неделю). Рекомендуется. 111 | не уверен, но в Ubuntu, по-моему, работает из коробки. 112 | * Опции для SWAP-разделов. TODO: расписать какие именно. Есть первичный дискард 113 | перед подключением, есть включение дискарда во время работы. 114 | * Есть опции при монтировании различных ФС чтобы выполняли discard для данных 115 | которые стали ненужными (после удаления файлов) 116 | * Команда ``blkdiscard`` для очистки всего устройства либо раздела или тома LVM. 117 | 118 | .. warning:: 119 | 120 | Говорят, что опции монтирования и аналогичные опции для SWAP-раздела понижают 121 | производительность. С другой стороны, массивный fstrim по расписанию может 122 | дать непредвиденные проседания IO в гостевой ОС. 123 | 124 | Windows 125 | ------- 126 | 127 | TODO: всё работает из коробки как-то само собой. На старых версиях можно включить 128 | через реестр. Как посмотреть ? Как форсировано прочистить ? 129 | 130 | Настоятельно рекомендуется установить дополнения в гостевую ОС: 131 | 132 | * https://fedoraproject.org/wiki/Windows_Virtio_Drivers 133 | * https://www.linux-kvm.org/page/WindowsGuestDrivers/Download_Drivers 134 | 135 | Иначе придётся довольствоваться только IDE, а это сильно меньшая производительность. 136 | 137 | RBD, Qemu и rotational 138 | ====================== 139 | 140 | Для более оптимальной работы приложений внутри гостевой ОС можно пометить диск как 141 | non-rotational. По-умолчанию, он rotational. 142 | 143 | Коммит, который это добавляет: https://github.com/qemu/qemu/commit/070f80095ad5b1143b50d2faffd2b1a84292e00d 144 | 145 | Такая возможность есть, начиная с qemu 2.11 и выше. Настраивается аналогично 146 | ``discard_granularity``. Нужно выставить 147 | ``scsi-hd.rotation_rate=1`` и ``scsi-block.rotation_rate=1`` 148 | (на всякий случай) 149 | -------------------------------------------------------------------------------- /rbd.rst: -------------------------------------------------------------------------------- 1 | *** 2 | RBD 3 | *** 4 | 5 | .. include:: rbd-qemu.rst 6 | 7 | RBD Features 8 | ============ 9 | 10 | В ceph.conf есть параметр rbd_default_features. Там указываются фичи RBD. В 11 | зависимости от версии Ceph можно указывать только числами, либо ещё можно 12 | строками: https://github.com/ceph/ceph/pull/11175. 13 | 14 | .. http://www.tablesgenerator.com 15 | 16 | +----------------------------+-----------+----------------+-------------------------------------------------------------+ 17 | | #define | Численное | Строковое | Описание | 18 | | | значение | значение | | 19 | | | | в ceph.conf | | 20 | +============================+===========+================+=============================================================+ 21 | | RBD_FEATURE_LAYERING | 1 | layering | Layering support. Layering enables you to use cloning. | 22 | +----------------------------+-----------+----------------+-------------------------------------------------------------+ 23 | | RBD_FEATURE_STRIPINGV2 | 2 | striping | Striping spreads data across multiple objects. | 24 | | | | | Striping helps with parallelism for sequential | 25 | | | | | read/write workloads. | 26 | +----------------------------+-----------+----------------+-------------------------------------------------------------+ 27 | | RBD_FEATURE_EXCLUSIVE_LOCK | 4 | exclusive-lock | When enabled, it requires a client to get a lock | 28 | | | | | on an object before making a write. | 29 | +----------------------------+-----------+----------------+-------------------------------------------------------------+ 30 | | RBD_FEATURE_OBJECT_MAP | 8 | object-map | Block devices are thin provisioned. That mean, they | 31 | | | | | only store data that actually exists. Object map | 32 | | | | | support helps track which objects actually exist | 33 | | | | | (have data stored on a drive). Enabling object map | 34 | | | | | support speeds up I/O operations for cloning, or | 35 | | | | | importing and exporting a sparsely populated image. | 36 | +----------------------------+-----------+----------------+-------------------------------------------------------------+ 37 | | RBD_FEATURE_FAST_DIFF | 16 | fast-diff | Fast-diff support depends on object map support and | 38 | | | | | exclusive lock support. It adds another property to the | 39 | | | | | object map, which makes it much faster to generate diffs | 40 | | | | | between snapshots of an image, and the actual data usage | 41 | | | | | of a snapshot much faster. | 42 | +----------------------------+-----------+----------------+-------------------------------------------------------------+ 43 | | RBD_FEATURE_DEEP_FLATTEN | 32 | deep-flatten | Deep-flatten makes rbd flatten work on all the snapshots | 44 | | | | | of an image, in addition to the image itself. Without it, | 45 | | | | | snapshots of an image will still rely on the parent, so the | 46 | | | | | parent will not be delete-able until the snapshots are | 47 | | | | | deleted. Deep-flatten makes a parent independent of its | 48 | | | | | clones, even if they have snapshots. | 49 | +----------------------------+-----------+----------------+-------------------------------------------------------------+ 50 | | RBD_FEATURE_JOURNALING | 64 | journaling | | 51 | +----------------------------+-----------+----------------+-------------------------------------------------------------+ 52 | | RBD_FEATURE_DATA_POOL | 128 | data-pool | | 53 | +----------------------------+-----------+----------------+-------------------------------------------------------------+ 54 | 55 | 56 | Недорасписанное 57 | =============== 58 | 59 | * опции для рбд образов типа фастдифф 60 | * бага с удалением снапшотов созданных ранними версиями 61 | * откат к снапшоту крайне медленный (как он работает) и что без дедупликации по сравнению со старыми 62 | объектам 63 | 64 | * Виды кеширования в квм - дока от сусе где демелиоратор сказал что он не прав. 65 | И описание что есть потеря данных при вырубания питания. 66 | 67 | * https://www.spinics.net/lists/ceph-users/msg15983.html 68 | * http://docs.ceph.com/docs/master/rbd/qemu-rbd/#qemu-cache-options 69 | * https://github.com/ceph/ceph/pull/10797 70 | 71 | * скруб еррор -- как понять хотябы какой это образ. 72 | * как бекапить :) 73 | * в рбд сразу после снапшота будут наблюдаться тормоза так как 4-мб объекты будут копироваться целиком даже при записи одного сектора. 74 | * оборванное удаление образа. как доудалить остатки. 75 | * Ядерный драйвер RBD не умеет во много опций. в частности, фастдифф. Варианты -- FUSEmount -- каждый файл это образ. либо NBD. 76 | * iscsi 77 | * qemu-nbd vs rbd-nbd 78 | * преобразование в qcow2 и обратно. сжатие qcow2. Перенос в другой пул средством 79 | qemu-img. хотя более быстро -- на уровне rados. 80 | * Перенос образов между пулами и копирование образов: рекомендуется qemu-img версии 81 | более 2.9. 82 | 83 | .. image:: _static/qemu-img-bandwith.jpg 84 | :alt: График пропускной способности 85 | 86 | https://github.com/qemu/qemu/commit/2d9187bc65727d9dd63e2c410b5500add3db0b0d и описание опций. 87 | 88 | .. code-block:: sh 89 | 90 | $ qemu-img convert -m 16 -W -p -n -f raw -O raw \ 91 | rbd:/ 92 | rbd:/ 93 | 94 | Это если ceph.conf настроен. Можно вообще без него: 95 | 96 | .. code-block:: sh 97 | 98 | $ qemu-img convert -p -n -f raw -O raw \ 99 | rbd:/:id=cinder:key=:mon_host=172.16.16.2,172.16.16.3,172.16.16.4 \ 100 | rbd:/:id=cinder:key=:mon_host=172.16.16.2,172.16.16.3,172.16.16.4 101 | 102 | 103 | * Сделав снапшот хотябы одного образа, сделать снапшот пула уже не получится. Узнать бы почему. 104 | -------------------------------------------------------------------------------- /rookio.rst: -------------------------------------------------------------------------------- 1 | ******* 2 | Rook.io 3 | ******* 4 | 5 | https://rook.io 6 | 7 | Это кластер Ceph в докер-контейнерах. 8 | 9 | Почему не стоит его использовать 10 | ================================ 11 | 12 | * Сeph потребляет много памяти. А к механизму OOM и работе лимитов kubernetes 13 | есть вопросы. 14 | * Cложности отладки. В Ceph есть баги, от которых падают OSD. Примерно понятно 15 | как отлаживать их в стандартном окружении, а в kubernetes? Пересобирать образ? 16 | А зачем тогда вообще rook.io? 17 | * В Сeph нет контрольных сумм при записи (Filestore), так что крайне рекомендуется 18 | использовать оперативную память с ECC. Если вы разворачиваете rook.io на десктопных 19 | компьютерахв (Например, Hetzner), то у вас могут быть проблемы. 20 | * Требование 10G-сети. 21 | * А зачем? Если вы в облаке, то пользуйтесь услугами облака. 22 | -------------------------------------------------------------------------------- /see_also.rst: -------------------------------------------------------------------------------- 1 | ******** 2 | See also 3 | ******** 4 | 5 | * http://tracker.ceph.com/projects/ceph/wiki/Tuning_for_All_Flash_Deployments 6 | * https://media.readthedocs.org/pdf/crush/latest/crush.pdf 7 | -------------------------------------------------------------------------------- /tuning.rst: -------------------------------------------------------------------------------- 1 | **************************** 2 | Типичные крутилки/инструкции 3 | **************************** 4 | 5 | * Минимизация влияния бекфиллов и рекавери на IO 6 | 7 | #. Дефолтные настройки параметров МЕНЯЮТСЯ в разных версиях Ceph, поэтому если 8 | интересное для вас значение совпадает с дефолтом -- пропишите его явно. 9 | #. Замедляя бекфиллы и рекавери вы увеличиваете риск потери данных, потому что 10 | во время этих процессов может умереть OSD. 11 | #. Чем больше значение приоритета тем больше Ceph уделяет времени на выполнение 12 | данной операции. В команде nice и в управлении дисковыми приоритетами в 13 | Linux -- наоборот (чем больше число -- тем меньше времени уделяется). 14 | #. TODO: там есть ещё параметры ограничивающие по LoadAverage... 15 | 16 | .. code:: 17 | 18 | osd_max_backfills = 1 19 | 20 | osd_recovery_max_active = 1 21 | osd_recovery_threads = 1 22 | osd_recovery_op_priority = 1 23 | osd_client_op_priority = 63 24 | 25 | osd_scrub_priority = 1 26 | osd_scrub_begin_hour = 1 27 | osd_scrub_end_hour = 7 28 | osd_scrub_during_recovery = false 29 | 30 | * Reweight by utilisation + новые ребалансер в Люминоусе 31 | -------------------------------------------------------------------------------- /upgrade-to-luminous.rst: -------------------------------------------------------------------------------- 1 | ******************* 2 | Переход на Luminous 3 | ******************* 4 | 5 | #. Делаем всё по инструкции: http://docs.ceph.com/docs/master/releases/luminous/#upgrade-from-jewel-or-kraken 6 | 7 | #. Укажите какие пулы для чего будут использоваться 8 | (``rbd``, ``cephfs`` или ``cephfs_metadata``. Про остальные ничего не знаю.) 9 | ``ceph osd pool application enable POOLNAME POOLTYPE`` 10 | 11 | #. Надо как-то там подправить пермишшены (osd blacklist). Там ошибка в документации 12 | -- слетают пермишшены. Ещё кому-то там надо дать больше прав (писать в мгр?) 13 | без этого ceph osd df перестает работать. После смены прав что перезапускать? 14 | Обнаруживается через передеплой MGR/Monitor/OSD. ceph-deploy выставляет другие 15 | права -- не как было при Кракене. 16 | 17 | #. Проблемы с удалением старых снапшотов RBD (known bug). Лечится удалением 18 | снапшота клиентом от джевел или кракен. TODO: пруф и копия в блоке про RBD. 19 | 20 | #. По-моему нужно уcтановить классы OSD. Но они вроде при перезапуске сами 21 | себя проставят. TODO: команда. 22 | 23 | #. Включаем дашборд 24 | 25 | ``ceph mgr module enable dashboard``. 26 | Возможно, нужно добавить ещё и во тэто в ceph.conf: 27 | 28 | .. code:: 29 | 30 | [mgr] 31 | mgr_modules = dashboard 32 | 33 | А потом ещё и ``ceph config-key put mgr/dashboard/server_addr ::``. Без этого 34 | дашборд не заработает. 35 | 36 | Смотрим по ``ceph -s`` какой менеджер активен и подключаемся туда на порт ???? (вписать). 37 | 38 | 39 | #. Меняем straw -> straw2: 40 | 41 | .. code-block:: sh 42 | 43 | # Создадим полный crush-map и сохраним его во временный файл 44 | ceph osd getcrushmap | crushtool -d - | sed -r 's/alg straw$/alg straw2/' | crushtool -c /dev/stdin -o newcrush.dat 45 | # TODO: Перед установкой посмотреть сколько данных будет не на сових местах. 46 | # Установим его в качестве нового крушмапа. 47 | ceph osd setcrushmap -i newcrush.dat 48 | 49 | 50 | #. Оптимизируем CRUSH-map: 51 | 52 | В новых версиях меняются алгоритмы консистентного хеша. Как итог -- меньше 53 | ребаланса при добавлении/удалении OSD, например, или более равномерное 54 | распределение по OSD. 55 | 56 | .. warning:: 57 | 58 | Это требует повышения минимальной версии до Jewel. Более старые клиенты 59 | не смогут подключаться к такому кластеры потому что не могут в такое 60 | хеширование. Возможны промежуточные варианты (чуть получше хеширование, 61 | но не самое лучшее) -- см. ссылку выше. 62 | 63 | .. warning:: 64 | 65 | Не смотря на заявление документации о том что будет перемещение не более 66 | чем 10% данных, в моём кластере было около 50% данных не на своих местах. 67 | 68 | .. code-block:: sh 69 | 70 | ceph osd set-require-min-compat-client jewel 71 | ceph osd crush tunables optimal 72 | 73 | #. See also 74 | 75 | http://crush.readthedocs.io/en/latest/ceph/optimize.html 76 | --------------------------------------------------------------------------------