diff --git a/main.rst b/main.rst index f7c4628..99acec5 100644 --- a/main.rst +++ b/main.rst @@ -5,6 +5,8 @@ #. ``ceph osd out osd.42``. Эта команда заставит Ceph перенести все данные с этого диска на другие диски без даже вре́менного понижения количества реплик. + А ещё можно установить ей вес 0. Или перебросить в другое место дерева, чтобы + crush его не зацеплял. #. Мониторить ``ceph osd safe-to-destroy``. #. На ноде: ``sudo systemctl stop ceph-osd@42``. #. ``ceph osd purge osd.42``. @@ -24,8 +26,12 @@ #. ``partprobe /dev/{journal-disk}``. fdisk не умеет говорить ядру о применении измененной таблицы разделов если диск используется (например, под другие журналы/бд на этом же диске. +#. Но лучше использовать gdisk. Тогда в принципе не получится поменять + данные используемых разделов, а вот неиспользуемые можно шатать как угодно. #. Перед извлечением диска физически на лету выполнить: ``echo 1 > /sys/block/{data-disk}/device/delete``. + Но это не обязательно. Вменяемое железо через несколько секунд поймёт, + что девайс выдернули, и удалит его. Переход на Luminous ------------------- @@ -129,19 +135,37 @@ Bluestore Как работает ------------ * Tiering vs bcache vs dm-cache + инструкции по дмкешу. -* почему дедупликация крайне затруднена в архитектуре Ceph +* почему дедупликация крайне затруднена в архитектуре Ceph - дело в том, что OSD + работают полностью независимо друг от друга, и общаются только со своими peer'ами в рамках + PG. Это не дает возможности создать общедоступное (пусть даже распределенное) дерево хэшей + по которому можно найти подлежащий дедупликации блок. Вторая проблема в том, что если дедуплицированный + блок лежит в другой PG, это приведет к тому, что необходимо делать запрос на другую OSD, а это + в ceph пока не реализовано. * в файлсторе всё полностью пишется в журнал. один врайт превращается в два сисколла врайт - - один в журнал (с синком) и один в основное хранилище. Но основное хранилище фсинкается - время от времени. Запись в журнал линейная, а в основное хранилище рандомная. При записи - в хранилище поможет параллельность которую может диск (например, NCQ). при записи в журнал - параллельность не используется. поэтому для файлстора надо бенчить именно *так*. + - один в журнал (с синком) и один в основное хранилище (на самом деле в несколько вызовов, + поскольку журнальные записи впоследствии помечаются как скоммиченные...). Но основное + хранилище фсинкается время от времени. Запись в журнал линейная, а в основное хранилище + рандомная. При записи в хранилище поможет параллельность которую может диск (например, NCQ). + При записи в журнал параллельность не используется. поэтому для файлстора надо бенчить именно *так*. WAL используется как writeback-cache по-сути. * при выносе журнала или БД на отдельный диск теряется возможность перевставлять диски в - другой нод. При старте ОСД (бай дефолт есть параметр) обновляет себя в крушмапе. -* При потере журнала вседиски на него зааттаченные превращаются в труху -* При потере данных всех мониторов теряется весь кластер. + другой нод. При старте ОСД (бай дефолт есть параметр) обновляет себя в крушмапе. Что приводит + к ребалансу. Ну и по факту, применимо только для мелких плоских кластеров со стандартным + "start from root via host" правилами. +* При потере журнала вседиски на него зааттаченные превращаются в труху. На самом деле это не совсем + так, и можно пересоздать журнал, но при этом все копии PG на этой OSD будут оставшими, и предстоит + рекавер и обязательный scrub/deep scrub. +* При потере данных всех мониторов теряется весь кластер. Данные RBD можно достать, но это + очень-очень больно и очень-очень долго, хотя и реализуемо. И потому применимо только к + очень-преочень ценным данным. * Нужно использовать именно три реплики потому что если две - то при скраб ерроре не понятно - кому верить + кому верить. Но - в блусторе эта проблема решена. Правда, тут стреляет второй фактор, под + названием "вероятность отказа диска" и "время восстановления избыточности". Поскольку данные + размазанны более-менее равномерно, это приводит к тому, что при отказе двух дисков случается + гарантированная потеря данных, а если у вас более 500 дисков, вероятность отказа второго диска + когда первый ещё не отрекаверился заметно больше ноля. Поэтому совсем большие пулы "на весь кластер" + лучше не делать. По крайней мере, при факапе накроется не всё (а с большим количеством дисков и size=2 + вы подписались на факап) * запись и чтение делается исключительно с мастера в актинг сете. При записи данные отправляются на мастер осд а он по кластер-сети отправляет параллельно на два слейва. on_safe-коллбэк клиента вызывается когда данные записались в WAL на всех репликах. @@ -168,12 +192,23 @@ Bluestore * Инструкцию по перемещению журнала на другое место для файлстора. и факт что это невозможно для блюстора. * понимание, что ИО одного и того же обжекта (или 4-мб-блока в рбд) никак не распараллеливается магически. и оно будет равно иопсам журнала или осн. хранилища. -* почему мелкие объекты плохо в радосе и большие тоже плохо. -* почему при убирании диска надо сначала сделать цеф осд аут, а не просто вырубить диск. +* почему мелкие объекты плохо в радосе и большие тоже плохо. Мелкие объекты приводят к тому что будет + много метаданных. А значит OSD будет пухнуть в памяти, будут долго стартовать, внутри PG они будут + долго пириться. Большие плохо потому, что в этом случае при первой записи в неконсистентный объект + будет случаться его рекавер, а чем больше объект - тем дольше рекавер. В результате для блочных стораджей + RBD можно получить падение производительности в 10...100 раз. А ещё образы из мелких объектов очень + долго удаляются. Иногда сутками. +* почему при убирании диска надо сначала сделать цеф осд аут, а не просто вырубить диск. Чтобы сохранить + избыточность. OSD которая out не принимает новые PG, но участвует в пиринговых отношениях для тех PG + на ней лежат, а значит сохраняется нужное количество реплик на время переезда. * для более быстрой перезагрузки используйте kexec. systemctl kexec. однако с кривым железом может не работать (сетёвки и рейды/хба). * https://habrahabr.ru/post/313644/ -* почему size=3 min_size=1 (size 3/1) моежт привести к проблемам. +* почему size=3 min_size=1 (size 3/1) моежт привести к проблемам. Потому, что класnер может быть активен, + когда у вас есть всего одна копия данных. И при сбое диска вы модете её потерять. После чего получите incomplete + PG. Неn, можно incomplete вернуть в работу, но все изменения, естественно, будут потеряны. А при распределенной + натуре ceph это гарантирует смерть всех сколь-нибудь активно используемых файловых систем на RBD которые лежали + в такой incomplete PG. * Каждая пг устанавливает свой кворум таким образом много * ссылка на калькулятор количества ПГ. почему много пг плохо и мало пг тоже плохо. @@ -202,10 +237,14 @@ Bluestore Сеть ---- -* что бек сеть надо точно 10 гигабит. привести расчёты. +* что бек сеть надо точно 10 гигабит. Тут всё просто. Представим, что один сервер ёкнулся и потом вернулся. + Это вызывает рекавер при каждой записи в дегрейднутый объект. При типовом объекте в 4 мегабайта, по 10Гб + сети сервер обслужит 300 IOPS даже под рекавером. А при гигабитной - 30 IOPS. В идеальном случае. При том, + по факту это приведет к росту средней latency на порядок (а то и на 2-3 порядка, если кластер маленький). * Отключить оффлоадинг (и как проверить помогло ли) - меряем RTT внутри TCP. * джамбофреймы могут помочь но не особо. сложности со свичами обычно. -* мониторить состояние линка. оно иногда самопроизвольно падает с гигабита на 100 мегабит. +* мониторить состояние линка. оно иногда самопроизвольно падает с гигабита на 100 мегабит. Но это проблема + говножелеза. * Тюнинг TCP/IP - отключать контрак Диски