Skip to content

main.rst

Latest commit

 

History

History
331 lines (268 loc) · 26.9 KB

main.rst

File metadata and controls

331 lines (268 loc) · 26.9 KB
Raw

Как удалить OSD

Для примера будем удалять osd.42.

  1. ceph osd out osd.42. Эта команда заставит Ceph перенести все данные с этого диска на другие диски без даже вре́менного понижения количества реплик. А ещё можно установить ей вес 0. Или перебросить в другое место дерева, чтобы crush его не зацеплял.
  2. Мониторить ceph osd safe-to-destroy.
  3. На ноде: sudo systemctl stop ceph-osd@42.
  4. ceph osd purge osd.42.

Дальнейшие операцию производятся на ноде под правами root:

  1. Посмотреть и запомнить вывод lsblk -f. Пригодится далее для wipefs.
  2. Посмотреть и запомнить readlink -f /var/lib/ceph/osd/ceph-42/* (Пригодится для удаления журнального раздела если он выносной).
  3. umount /var/lib/ceph/osd/ceph-42.
  4. rmdir /var/lib/ceph/osd/ceph-42.
  5. wipefs -a /dev/{data-disk-partition(s)}. см. сохранённый вывод lsblk.
  6. wipefs -a /dev/{data-disk}. см. сохранённый вывод lsblk.
  7. Если выносной журнал/бд: fdisk /dev/{journal-disk}, удалить соответствующий раздел. Современный fdisk умеет работать с GPT. какой именно раздел -- см. сохранённый вывод readlink.
  8. partprobe /dev/{journal-disk}. fdisk не умеет говорить ядру о применении измененной таблицы разделов если диск используется (например, под другие журналы/бд на этом же диске.
  9. Но лучше использовать gdisk. Тогда в принципе не получится поменять данные используемых разделов, а вот неиспользуемые можно шатать как угодно.
  10. Перед извлечением диска физически на лету выполнить: echo 1 > /sys/block/{data-disk}/device/delete. Но это не обязательно. Вменяемое железо через несколько секунд поймёт, что девайс выдернули, и удалит его.

Переход на Luminous

  1. Делаем всё по инструкции: http://docs.ceph.com/docs/master/release-notes/#upgrade-from-jewel-or-kraken

  2. Укажите какие пулы для чего будут использоваться (rbd, cephfs или cephfs_metadata. Про остальные ничего не знаю.) ceph osd pool application enable POOLNAME POOLTYPE

  3. Надо как-то там подправить пермишшены (osd blacklist). Там ошибка в документации -- слетают пермишшены. Ещё кому-то там надо дать больше прав (писать в мгр?) без этого ceph osd df перестает работать. После смены прав что перезапускать? Обнаруживается через передеплой MGR/Monitor/OSD. ceph-deploy выставляет другие права -- не как было при Кракене.

  4. Проблемы с удалением старых снапшотов RBD (known bug). Лечится удалением снапшота клиентом от джевел или кракен. TODO: пруф и копия в блоке про RBD.

  5. По-моему нужно учтановить классы ОСД. Но они вроде при перезапуске сами себя проставят. TODO: команда.

  6. Включаем дашборд

    ceph mgr module enable dashboard. Возможно, нужно добавить ещё и во тэто в ceph.conf:

    [mgr]
mgr_modules = dashboard

    А потом ещё и ceph config-key put mgr/dashboard/server_addr ::. Без этого дашборд не заработает.

    Смотрим по ceph -s какой менеджер активен и подключаемся туда на порт ???? (вписать).

CephFS

Хранить образы виртуалок на CephFS -- полный маразм.

Типичные крутилки/инструкции

  • Минимизация влияния бекфиллов и рекавери на IO

    1. Дефолтные настройки параметров МЕНЯЮТСЯ в разных версиях Ceph, поэтому если интересное для вас значение совпадает с дефолтом -- пропишите его явно.
    2. Замедляя бекфиллы и рекавери вы увеличиваете риск потери данных, потому что во время этих процессов может умереть OSD.
    3. Чем больше значение приоритета тем больше Ceph уделяет времени на выполнение данной операции. В команде nice и в управлении дисковыми приоритетами в Linux -- наоборот (чем больше число -- тем меньше времени уделяется).
    4. TODO: там есть ещё параметры ограничивающие по LoadAverage...
    osd_max_backfills = 1

osd_recovery_max_active = 1
osd_recovery_threads = 1
osd_recovery_op_priority = 1
osd_client_op_priority = 63

osd_scrub_priority = 1
osd_scrub_begin_hour = 1
osd_scrub_end_hour = 7
osd_scrub_during_recovery = false

  • Reweight by utilisation + новые ребалансер в Люминоусе

Bluestore

  • Какие размеры БД и вал нужны + средства как посмотреть текущее

  • WAL находится в БД. БД находится в блюсторе. Если вынести БД то она вместе с журналом выносится. Вроде (нужен пруф) БД устроена так что самые горячие данные хранятся в её начале. Если БД не вмещается под отведённое место (если она выносная) то часть БД хранится отдельно, а часть в основном хранилище.

  • Нет возможности после создания БД встроенной вынести её отдельно. Аналогично с её WAL.

  • Настройки блюстора:

    bluestore_cache_size = 536870912
bluestore_prefer_deferred_size_hdd = 104857600
bluestore_prefer_deferred_size_ssd = 104857600
bluestore_prefer_deferred_size = 104857600

    в т.ч. так как не понятно, понял ли что диск rotational.

  • По исходникам смотрел -- он определяет что диск rotational и из этого делает вывод SSD или нет. В том числе при старте OSD оно смотрит не назначен ли класс OSD и ставит ssd/hdd на основании этого. А ещё применяет разные настройки в зависимости от этого. Bcache (всегда?) ставит флаг что диск что non-rotational ДАЖЕ ЕСЛИ РЕАЛЬНЫЙ КЕШ НЕ ПРИАТТАЧЕН к кеш-девайсу.

Как работает

  • Tiering vs bcache vs dm-cache + инструкции по дмкешу.
  • почему дедупликация крайне затруднена в архитектуре Ceph - дело в том, что OSD работают полностью независимо друг от друга, и общаются только со своими peer'ами в рамках PG. Это не дает возможности создать общедоступное (пусть даже распределенное) дерево хэшей по которому можно найти подлежащий дедупликации блок. Вторая проблема в том, что если дедуплицированный блок лежит в другой PG, это приведет к тому, что необходимо делать запрос на другую OSD, а это в ceph пока не реализовано.
  • в файлсторе всё полностью пишется в журнал. один врайт превращается в два сисколла врайт - один в журнал (с синком) и один в основное хранилище (на самом деле в несколько вызовов, поскольку журнальные записи впоследствии помечаются как скоммиченные...). Но основное хранилище фсинкается время от времени. Запись в журнал линейная, а в основное хранилище рандомная. При записи в хранилище поможет параллельность которую может диск (например, NCQ). При записи в журнал параллельность не используется. поэтому для файлстора надо бенчить именно так. WAL используется как writeback-cache по-сути.
  • при выносе журнала или БД на отдельный диск теряется возможность перевставлять диски в другой нод. При старте ОСД (бай дефолт есть параметр) обновляет себя в крушмапе. Что приводит к ребалансу. Ну и по факту, применимо только для мелких плоских кластеров со стандартным "start from root via host" правилами.
  • При потере журнала вседиски на него зааттаченные превращаются в труху. На самом деле это не совсем так, и можно пересоздать журнал, но при этом все копии PG на этой OSD будут оставшими, и предстоит рекавер и обязательный scrub/deep scrub.
  • При потере данных всех мониторов теряется весь кластер. Данные RBD можно достать, но это очень-очень больно и очень-очень долго, хотя и реализуемо. И потому применимо только к очень-преочень ценным данным.
  • Нужно использовать именно три реплики потому что если две - то при скраб ерроре не понятно кому верить. Но - в блусторе эта проблема решена. Правда, тут стреляет второй фактор, под названием "вероятность отказа диска" и "время восстановления избыточности". Поскольку данные размазанны более-менее равномерно, это приводит к тому, что при отказе двух дисков случается гарантированная потеря данных, а если у вас более 500 дисков, вероятность отказа второго диска когда первый ещё не отрекаверился заметно больше ноля. Поэтому совсем большие пулы "на весь кластер" лучше не делать. По крайней мере, при факапе накроется не всё (а с большим количеством дисков и size=2 вы подписались на факап)
  • запись и чтение делается исключительно с мастера в актинг сете. При записи данные отправляются на мастер осд а он по кластер-сети отправляет параллельно на два слейва. on_safe-коллбэк клиента вызывается когда данные записались в WAL на всех репликах. Должидания прописывания в основное хранилище в принципе нет. Есть коллбэк когда данные есть в памяти на всех трёх репликах.
  • бкеш врёт относительно ротейшионал и цеф использует не те настройки. Бкеш writeback (кеширование записи) не нужен потому что с файлстором это делается через WAL, а с блюстором есть опция по записи даже больших запросов в БД которую нужно вынести на ССД. С чтением тоже не нужен потому что:
    1. виртуалки с рбд и так не плохо кешируют то что уже читали
    2. запись потребляет в 3 раза больше иопсов (размер пула=3). а на самом деле ещё больше по причине двойной записи и даже ещё больше если это файлстор. Чтение требует один-в-один. поэтому цеф на чтение хорош.
    3. Нормальный кеш делает через тиеринг в цефе (но это не точно).
  • Описание цифр в ceph -s. откуда берутся цифры и что они означают.
  • Как посчитать реальную вместимость кластера. мин. загруженность осд.
  • сколько должен давать кластер иопсов и мегабайтов в секунду на чтение и на запись. какие паттерны использования и параллельность.
  • ceph-deploy требует GPT. Размер журнала и БД надо выставлять.
  • Инструкцию по перемещению журнала на другое место для файлстора. и факт что это невозможно для блюстора.
  • понимание, что ИО одного и того же обжекта (или 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) моежт привести к проблемам. Потому, что класnер может быть активен, когда у вас есть всего одна копия данных. И при сбое диска вы модете её потерять. После чего получите incomplete PG. Неn, можно incomplete вернуть в работу, но все изменения, естественно, будут потеряны. А при распределенной натуре ceph это гарантирует смерть всех сколь-нибудь активно используемых файловых систем на RBD которые лежали в такой incomplete PG.
  • Каждая пг устанавливает свой кворум таким образом много
  • ссылка на калькулятор количества ПГ. почему много пг плохо и мало пг тоже плохо.
    • http://ceph.com/pgcalc
    • если мало - то неравномерность, потенциально не все осд могут быть заюзаны.
    • если много - юсадж памяти, перегрузка сети

Бенчмаркинг

  • Как бенчмаркить сам цеф и рбд. какие типовые кейсы. говорят, фио врёт про рбд (надо исходники посмотреть рбд драйвера).
  • что иопсы равны самым медленным иопсам серди актинг сета.
  • как бенчить радос. нужно сопоставить рассчетное и фактическое. ибо всегда можно создать нагрузку которая задосит кластер.
  • RBD надо бенчить на зааллокейченном диске.

Мониторинг

  • два вида экспортеров под прометеус
  • мониторить температуры, свап, иопсы (латенси) дисков

Сеть

  • что бек сеть надо точно 10 гигабит. Тут всё просто. Представим, что один сервер ёкнулся и потом вернулся. Это вызывает рекавер при каждой записи в дегрейднутый объект. При типовом объекте в 4 мегабайта, по 10Гб сети сервер обслужит 300 IOPS даже под рекавером. А при гигабитной - 30 IOPS. В идеальном случае. При том, по факту это приведет к росту средней latency на порядок (а то и на 2-3 порядка, если кластер маленький).
  • Отключить оффлоадинг (и как проверить помогло ли) - меряем RTT внутри TCP.
  • джамбофреймы могут помочь но не особо. сложности со свичами обычно.
  • мониторить состояние линка. оно иногда самопроизвольно падает с гигабита на 100 мегабит. Но это проблема говножелеза.
  • Тюнинг TCP/IP - отключать контрак

Диски

  • Не имеет никакого смысла использовать рэйды как хранилище для Ceph. Здесь имеется в виду какой-либо способ программного или аппаратного объединения дисков в один виртуальный. Потенциальные проблемы:
    • Опасность обмана команд по сбросу кеша. Например, включенный Writeback на аппартаном RAID без BBU.
    • Программный RAID (mdadm, зеркало) ПОВРЕЖДАЕТ данные при записи в режиме O_DIRECT если в процессе записи страница меняется в параллельном потоке. В этом случае ПОДТВЕРЖДЁННЫЕ данные будут различаться в половинках зеркального рэйда. При следующем (scrub?) рэйда будут проблемы. TODO: Нужен proof.
    • Программные рэйды не защищают от сбоя питания -- да, разумеется вышестоящие FS/БД должны быть готовы к повреждению неподтверждённых данных, но при проверке (scrub?) различие данных на репликах приведёт к проблемам.
    • Во время смерти диска RAID находится в состоянии degraded пока не добавят новый диск. Либо нужен spare-диск который в случае с Ceph глупо не использовать. Degraded RAID внезапно для Ceph будет давать худшие характеристики пока не восстановится. RAID не знает какие данные нужны а какие -- нет, поэтому процесс восстановления реплик -- долгий -- синхронизирует мусор либо нули.
    • Для RAID нужны диски одинакового размера. Для Ceph это не требуется.
    • Аппаратные рэйды нужно отдельно мониторить и администрировать.
    • Зеркало не нужно потому что Ceph сам сделает столько реплик сколько требуется. Страйпинг не нужен потому что повышение производительности делается другими способами (с помощью SSD). Raid 5,6 в случае дегрейда причиняет боль.
    • В общем и целом, Ceph можно рассматривать как огромный распределённый RAID. Зачем делать RAID состоящий из RAID не понятно.
  • Акустик, хпа, паверсейвинг, настроить автотесты по смарту.
  • отдискардить ссд перед использованием.
  • fstrim -v -a (filestore on ssd), blkdiscard on LVM/Partition.
  • мониторить смарт
  • как бенчить - ссд и разного рода коммерческий обман. деградация изза недискарда - надо дать продыхнуть, некоторое количество быстрых ячеек и тиринг на них. суперкапазиторы.
  • бенчмаркинг несколько дисков одновременно ибо контроллеры.
  • на ссд обновлять прошивки критично важно. ещё про блеклисты в ядрах насчёт багов.
  • дискард на них медленный, поэтому лучше оставить продискарденную область и этого достаточно.
  • жеоательно не ставить одинаковые диски с одинаковым юсаджем - ибо умрут скорее всего одновременно ибо нагрузка примерно одинаковая.
  • Диск шедулеры
  • имхо магнитные сас-диски не нужны. их возможности не будут задействованы для получения преимущества перед сата. Сата 12 гбит для магнитных дисков не нужен. Для магнитных (7200 оборотов) даже сата2 (3 гбит ~ 300 мб.сек) хватит.
  • убедиться что диски подключены как сата6.
  • чего ожидать от бенчмаркинга. реальная таблица с реальными моделями.
  • при бенчмаркинге ссд может оказаться что уперлись в контроллер а не в диск.

Процессоры и память

  • Для Ceph-нодов требуется (не рекомендуется) память с ECC. Сбой в памяти мастер-OSD в acting set приведёт к необнаруживаемому повреждению данных даже если это BlueStore со своим CRC32c. Данные могут повредиться до подсчёта CRC32 и распространиться по slave-OSD.

    Немного близкая тема и про клиентов. Если данные испорчены до подсчёта CRC32 в рамках протокола мессенджера Ceph, то они будут повреждены и это не обнаружится.

  • CPU Governor & powersave mode. Отличная статья в арче: https://wiki.archlinux.org/index.php/CPU_frequency_scaling

  • CRC32 аппаратное в блюсторе (и в месенджере не с блюстором?)

  • гипертрединг нинужен. потому что это просто доп-набор регистров. В цефе по идее нет цпу-боунд задач есть крк32 но оно реализуется через спец команду в sse4.3 а такой блок емнип один на ядро. при сжатии в блюсторе может иметь значение однако.

  • ramspeed = ramsmp

  • cpuburn

  • i7z, powertop

  • cpupower frequency-info, how to set governor (+permanently)

  • grub + nopti + performance + luacode + meltdown