LINUX.ORG.RU

Ceph для РСУБД или Эластика, стоит ли?

 , , , ,


0

3

Привет всем,

Я админю PostgreSQL с потоковой репликацией, и всегда использовал прямой доступ к дискам, в котором используются RAID-10, ну или на крайний случай RAID-1. Собственно, тоже самое касается др. stateful-сервисов, как: Elastic, MongoDB и других. Просто, использую, как правило встроенные механизмы репликации и сервисы реплицируются, где условная одна нода stateful-сервиса использует RAID-10 или RAID-1 для хранения своих данных.

РСУБД базы, в среднем, по 300 Гб юзаются у нас. Юзаем:

  • материлиз. вьюхи
  • хранимки
  • tablespaces организованы опред. образом и др.

Эластик кластер, и вовсе, 5 терабайт держит округлено.

В чем суть моего вопроса?

Сейчас, маркетологи на удаленке топят за перевод на Ceph. Да-да, как смешно бы не звучало (хотя, может быть и не будет смешно для кого-то).

Основной их аргумент, что: в публичных облаках, типа Mail.Ru cloud, AWS и др. Давно хостят базы на дистрибутивных storages, будь то Ceph или AWS block storage и не фиг использовать эти ваши «дедовские способы», что мол время прошло.

Я думаю, что это будет очень медленно, т.к. к примеру если взять Elastic-кластер, допустим три или более нод, то получается картина, что запускается распределенное приложение на распределенной FS. Да и в целом, манагеры с маркетологами не очень понимают разницы между managed сервисами и unmanaged, сути их технической разницы.

И, у меня возникают следующие логические вопросы:

  1. А, почему бы просто не позволить Elastic справиться с этим - с помощью собственных/встроенных механизмов по шардам и репликам, используя прямой доступ к дискам?

  2. В чем такой кайф дать прослойку в виде Ceph, которую еще нужно уметь поддерживать? Ведь, это достаточно сложный инструмент. К тому же, увелич. вероятность «обсера», ибо если вылетит Цеф, то вылетит - всё, что на нем хостится.

Итого/вывод:

В целом, я могу добавить еще, что наши маркетологи и манагеры на удаленной работе давно бы всё перевели в облака, если бы их воля и не необходимость держать приватные данные юзеров на собственных машинах. По договорам у нас - нельзя хостить клиентские данные в облаках.

Почему, вообще, слушают менеджеров и маркетологов по данным вопросам? Я углубляться не буду и скажу проще, просто время такое, когда надо соблюдать soft skills, когда надо выслушивать не только технический персонал и когда маркетолог или манагер может означать больше, чем даже архитекор. В случае, если они приводят большой мешок с деньгами.

Может, я устарел и Ceph - не так уже и плох, и я не умею его готовить? Вполне возможно.

Если у кого-то был опыт с деплоем Ceph и хостингом реплицируемых stateful-сервисов на нем, то прошу поделиться впечатлениями и личным опытом в эксплуатации, спасибо.

Хорошо потюненый all-flash сеф станцует на костях любого all-hdd рейда. Но это недешевое удовольствие - хотя, классическая отказоустойчивая «двухголовая» хранилка с репликацией тоже озвучит вам весьма обидный ценник.

Но правильным решением для СУБД всё же лучше использовать репликацию средствами самой СУБД - то есть либо мастер-слейв, либо мультимастер.

И в любом случае время RAID закончилось.

Nastishka ★★★★★ ()
Ответ на: комментарий от Nastishka

Но правильным решением для СУБД всё же лучше использовать репликацию средствами самой СУБД - то есть либо мастер-слейв, либо мультимастер.

Так, я и использую :) Процитирую себя же, #1:

Просто, использую, как правило встроенные механизмы репликации и сервисы реплицируются, где условная одна нода stateful-сервиса использует RAID-10 или RAID-1 для хранения своих данных.

И #2:

А, почему бы просто не позволить Elastic справиться с этим - с помощью собственных/встроенных механизмов по шардам и репликам, используя прямой доступ к дискам?

RAID-то на одной ноде используется, где просто объединение нескольких физических дисков в одно для повышения отказоустойчивости и производительности, ибо:

  1. вылетит один диск, данные будут на другом, в случае RAID-10 - 4-е диска, но опять повторюсь это на одной ноде, допустим master

  2. это ни как отменяет того, что используются нативные механизмы репликаций Postgres или Elastic, RAID-то на одной тачке, а на другой тачке - тоже RAID. Короче, изображу текстом, условно:

bare metal A
md0 (RAID-10)

  1. /dev/sda
  2. /dev/sdb
  3. /dev/sdc
  4. /dev/sdd

md device (md0)

PostgreSQL master data; на md0-девайсе, с xfs или ext4

+++ потоковая репликация со слотами PgSQL +++

bare metal B
md0 (RAID-10)

  1. /dev/sda
  2. /dev/sdb
  3. /dev/sdc
  4. /dev/sdd

md device (md0); PostgreSQL slave data; на md0-девайсе, с xfs или ext4

PS: добавлю, что многие ДБА очень весьма блются от Ceph, GlusterFS и от NFS. Общался с разными и те, кто Постгрю обслуживает, и те кто Оракл. Все что-то в один голос - против:

  1. виртуализации дисков
  2. против прослойки в виде любой дистрибутивной FS для юзания, особенного под high load DB
  3. и процитирую одного своего знакого ДБА, который MariaDB/MySQL админит, в том контексте, что человек использует RAID-массивы на NVMe:

[DBA] advices, [17.07.21 01:59] [Forwarded from Жека] 150Gb будут 2-3 часа заливаться, если в MySQL на RAID-10 из NVMe SSD

[DBA] advices, [17.07.21 02:12] [Forwarded from Жека] на mysql03.staging - buffer_pool 130G если ты сравниваешь запросы, которые из RAM выполняются - разницы с NVMe не будет

  1. А, если речь про облака, мол там все в виртуалках и дистрибутивно. Я думаю, что Амазон или Гугл свои хранилища довели до очень хорошего состояния, т.к. там целая Ops-команда огромная для поддержки всего и бесполезно сравнивать мощи крупных IaaS/PaaS-провайдеров, когда у тебя всего 9 bare-metal серверов, не самых мощных. И где, тебе еще самому это все обслуживать и продумывать моменты, что диски могут сломаться.
twinpeaks ()

Я против Ceph’а для БД, по двум причинам:

  1. Низкая производительность. Даже на all-flash у тебя не получится выжать более 2500 IOPS в один поток.

  2. Низкая надежность. На прошлом месте работы я был вынужден чинить чужие кластера после инцидентов, в том числе после багов в самом Ceph. А их там побольше, чем в btrfs. В итоге заработал понимание, что этому никто не учит, и, как следствие постановки недостижимых целей, выгорание. А в текущей архитектуре с RAID’ами все хранилки сразу сломаться просто не могут.

AEP ★★★★★ ()
Последнее исправление: AEP (всего исправлений: 2)

Ceph бывает разный.

У меня эластик живет на rbd-дисках (десять датанод по 4тб каждая, утилизация примерно 2.5/4), около года потратил на войну с регулярным вылетом нод из кластера по i/o, вроде победил, но осадочек остался. Из минусов решения - ceph на хардах, поэтому вот случился у харда пмс, вместо 10ms на запись он выдал секунду - и все, ноды падают с ошибкой i/o и реджойнятся в кластер (с последующей реактивацией шардов, которая занимает какое-то время).

Сейчас коллеги, которые рулят виртуалками, тестируют cinderlib в качестве провайдера для ovirt, если результаты по i/o мне понравятся - попробую уйти с rbd в сторону cinder-дисков.

У коллег есть монга, которую они закинули в cephfs. 300 гигов базы и она дохнет как я не знаю. I/O ужасное, база валится раз в неделю, восстановление занимает еще неделю. Ответственные тоже ждут вердикта по cinder.

Вообще у меня где-то была небольшая заметка с тестами pg_test_fsync поверх различных типов волюмов, выданных в виртуалку (вмвара на FC хранилке с блинами, ceph+iscsi, ceph+rbd, ceph+cephfs, какие-то еще тесты делал). Точно помню, что именно в разрезе fsync вмвара выиграла по всем фронтам.

l0stparadise ★★★★★ ()
Ответ на: комментарий от l0stparadise

Делаю вывод, что я - не одинок в оценке Ceph. Жалко, что все облаками прекрываются… Сравнивать мощи public clouds и размеров их команды с двумя калеками, которые админят на фирме… Бесполезно… Опять же, мое имхо…

twinpeaks ()
Ответ на: комментарий от Nastishka

Если это тот синдер про который обычно говорят, то это просто оркестрация - а под капотом там может быть чуть не дюжина разных реализаций. В том числе сеф :-)

Nastishka ★★★★★ (11.08.21 19:08:52)

Может, я что-то не допонимаю, но:

https://ru.wikipedia.org/wiki/OpenStack#Cinder

Cinder (OpenStack Block Storage) - блочное хранилище (в отличие от объектного хранилища Swift). Реализация подобна решению Amazon Elastic Block Store.

http://onreader.mdl.ru/LearningCeph/content/Ch09.html

Cinder поддерживает множество систем хранения. Чтобы настроить Cinder для использования Ceph измените файл настройки Cinder и определите драйвер RBD, который должен будет использовать OpenStack Cinder.

http://onreader.mdl.ru/CephCookbook/content/Ch02.html

Программа Cinder OpenStack предоставляет блочные устройства виртуальным машинам. В этом рецепте мы настроим Cinder OpenStack на применение Ceph для поддержки хранения. Для взаимодействия с нашим блочным устройством Ceph Cinder OpenStack требуется драйвер.

Оркестрация чего имеется ввиду? Block devices через RADOS?

twinpeaks ()
Ответ на: комментарий от twinpeaks

Давайте так объясню, как для школьников.

Cinder это не «блочное хранилище» - это интерфейс управления всяческими стораджами. Он не умеет ничего сам хранить - только раздает то что организуется другими. То есть вы регистрируете в синдере кластер сефа, NetApp-овский сторадж, делловский, IBMовский и три линукса - с NFS, с самбой и с LVM.

А потом говорите «создай диск по указанным правилам» и он сам выберет вам где его создать, отправит туда нужные команды, а когда вам потребуется подключиться к этому диску - отправите команду «расскажи мне как подключиться к этому диску» и синдер сообщит вам логины, пароли, адреса, имена файлов и пути, таргеты, луны и т.д. - то есть всё, что нужно для подключения к диску.

Вот только дело в том, что если у вас есть где создавать диски - вы их можете создавать там и без синдера. А если создавать негде - синдер вам не поможет :-)

Nastishka ★★★★★ ()
Ответ на: комментарий от Nastishka

Понятно, что под капотом может быть что угодно, и в нашем случае это будет цеф =)

Но логика то немного другая. По сути все общение с цефом - это какая-то прослойка между рулем и сиденьем - будь то rbd, iscsi, rados или cinderlib или что там еще можно налепить. И логично, что каждая прослойка несет за собой какой-то оверхед. Задача - найти наименьший.

Когда мы поднимали первый цеф, в голове людей была многолетняя привычка к iscsi - соответственно, был поднят iscsi gateway и приклеен в нужные места (если кто-то из гугла будет это читать - хорошо подумайте, прежде чем его использовать). Контора живет в концепции сервисных платформ с максимальной изоляцией оных (152фз над головой), поэтому новая платформа - новый iscsi-лун, в определенный момент приехали к совокуплению с соотношением pg/osd. Чтобы гонять меньше трафика через iscsi gateway, который, как оказалось позже, стабильностью не блещет, всякие титаники увезли в rbd (выше написал - с эластиком обплевался, но победил таки) или cephfs, о чем тоже ребята жалеют. RBD лично мне из этой братии нравится больше всего, но если условному джуну нужно поднять виртуалку с базой - или «сеньор сгенери мне ключик», или пускать их куда не надо.

И вот примерно в этот момент и начали смотреть на cinderlib, который и довольно производительный, и не требует общения с цефом для тех, кто будет катать свои виртуалки, и уровень абстракции вполне устраивает.

Ну и да, под синдером может быть не только цеф, но и что угодно, что может понадобиться в будущем, если партия решит, что цеф больше не наш выход.

l0stparadise ★★★★★ ()
Ответ на: комментарий от Nastishka

Nastishka ★★★★★ (11.08.21 23:11:47)

IBMовский и три линукса - с NFS

Что-то сомневаюсь, что DBA будет в восторге, хотя бы если взять тот же МуСКЛ:

https://dev.mysql.com/doc/refman/8.0/en/disk-issues.html

Using NFS with MySQL You should be cautious when considering whether to use NFS with MySQL. Potential issues, which vary by operating system and NFS version, include the following:

MySQL data and log files placed on NFS volumes becoming locked and unavailable for use. Locking issues may occur in cases where multiple instances of MySQL access the same data directory or where MySQL is shut down improperly, due to a power outage, for example. NFS version 4 addresses underlying locking issues with the introduction of advisory and lease-based locking. However, sharing a data directory among MySQL instances is not recommended.

Data inconsistencies introduced due to messages received out of order or lost network traffic. To avoid this issue, use TCP with hard and intr mount options.

Maximum file size limitations. NFS Version 2 clients can only access the lowest 2GB of a file (signed 32 bit offset). NFS Version 3 clients support larger files (up to 64 bit offsets). The maximum supported file size also depends on the local file system of the NFS server.

Да и, и др. РСУБД касается, нарыл:

Ceph reaction to a missing OSD If an OSD goes down, the Ceph cluster starts copying data with fewer copies than specified. Although good for high availability, the copying process significantly impacts performance. This implies that you cannot run a Ceph with a nearly full storage, you must have enough disk space to handle the loss of one node.

The “no out” OSD attribute mitigates this, and prevents Ceph from reacting automatically to a failure (but you are then on your own). When using the “no out” attribute, you must monitor and detect that you are running in degraded mode and take action. This resembles a failed disk in a RAID set. You can choose this behavior as default with the mon_osd_auto_mark_auto_out_in setting.

Scrubbing Every day and every week (deep), Ceph scrubs operations that, although they are throttled, can still impact performance. You can modify the interval and the hours that control the scrub action. Once per day and once per week are likely fine. But you need to set osd_scrub_begin_hour and osd_scrub_end_hour to restrict the scrubbing to off hours. Also, scrubbing throttles itself to not put too much load on the nodes. The osd_scrub_load_threshold variable sets the threshold.

Касаемо NFS:

Nastishka ★★★★★ (11.08.21 23:11:47)

То есть вы регистрируете в синдере кластер сефа, NetApp-овский сторадж, делловский, IBMовский и три линукса - с NFS, с самбой и с LVM.

Это перечисление, что ли? Просто, я что-то не понял причем тут NFS и Ceph? Ceph, вроде, блочные ус-ва сам организует, OSDшки ставятся. Placement группы формируются, и т.д.

twinpeaks ()
Ответ на: комментарий от twinpeaks

Так никто не говорит, что облака это плохо. Просто задачи нужно решать так, чтоб это хорошо работало, а не с использованием модных тенденций. Мне нравится ceph, он ни в коем случае не плохой. Просто я для себя пришел к тому, что мы ceph’ом решаем задачи, для которых он не является оптимальным. Или мы его до конца не приготовили, что тоже возможно.

l0stparadise ★★★★★ ()
Ответ на: комментарий от l0stparadise

Да я тоже не говорю, что облака - это прямо так плохо :)

Тут, зависит сугубо от размера кошелька конторы, если фирма готова платить за обработку гигабайтных и терабайтных данных в managed сервисах, типа CloudSQL, то пожалуйста.

Но, реальность как правило уходит (на многих фирмах видел) в такое русло:

  1. хостинг приватных данных клиентов, мало кто хочет хостить данные в облаке, особенно если это касается финансовой сферы

  2. зачастую хотят кастомизированный Postgres, к примеру, TimeScale DB подрубить и др. к самому Postgres

  3. реплицировать гигабайтные/терабайтные данные между разными DC, к примеру гонять данные между Сингапуром, Парижем, Россией и ЮАР. То здесь, накладываются ограничения законадательств разных стран, а в случае с Китаем - еще веселее из-за их более специфичных законов и великого файерволла

К чему это я? Что все равно, в реальной практике как-то сводится, что чем крупнее фирма-заказы, то возможностей managed-сервисов в public clouds не хватает.

PS: могу быть не прав, исхожу из своего реального опыта.

twinpeaks ()
Ответ на: комментарий от l0stparadise

И вот примерно в этот момент и начали смотреть на cinderlib, который и довольно производительный, и не требует общения с цефом для тех, кто будет катать свои виртуалки, и уровень абстракции вполне устраивает.

Вы очень неправы. Очень-очень-сильно неправы, рассчитывая на помощь синдера в этой задаче.

Nastishka ★★★★★ ()
Ответ на: комментарий от Nastishka

Но, за объяснение - спасибо. Правда, таки, не решает моих проблем :(

Чем глубже читаю линки по связке Ceph + any solid database, то больше мата читаю. Х/з, как с маркетологами беседовать…

twinpeaks ()
Ответ на: комментарий от l0stparadise

И логично, что каждая прослойка несет за собой какой-то оверхед. Задача - найти наименьший.

Overhead тут - не самое худшее и страшное :) Я бы еще за условные downtime боялся, особенно послушав:

https://www.youtube.com/watch?v=_fWYUl2QsoI

Ceph. Анатомия катастрофы / Артемий Капитула (RCNTEC)

PS: представляю, если на Ceph будут стоять:

  • MQ brokers с перситентность того, что из очередей
  • RDBMS (Postres)
  • NoSQL (Elastic, MongoDB, Redis)

Причем все одновременно и под high load. Небось, фильм ужасов для DevOps/SysAdmin.

twinpeaks ()
Ответ на: комментарий от AEP

В-общем, пока из всех сообщений, я больше всего солидарен с Вами.

А их там побольше, чем в btrfs

Ой, перепрочел… Не напоминайте даже это слово :) Хлебнул горя с ней, после чего строго XFS или ext4. А btrfs для меня в кошмарных снах снится.

В одном проекте достался проект, где были базы на Arch Linux, 3-и ноды и всё на btrfs, включая host os.

В-общем, перевел все добро на CentOS v7 + XFS, ибо были бессонные ночи по инцидентам с этой btrfs…

twinpeaks ()