Update main.rst

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 - отключать контрак
 
 Диски