Pull to refresh

Comments 14

Несколько больших серверов, на которых установлено много дисков, обеспечат наилучшую производительность.


Facepalm. Традиционная рекомендация — как можно больше небольших серверов. Чем больше серверов, тем больше ядер на диск. По бенчмаркам ceph упирается примерно 300% cpu на ядро на запись, и 200% на чтение (в сумме — 500%). Если у вас быстрые диски, то вынь да положь пять ядер на диск.


Использование шпинделей под ceph при сегодняшних ценах на SSD — спорно. Очень спорно. Планировать нагрузку на SSD можно более менее разумно, на шпиндели почти невозможно, потому что любая случайная параллельная нагрузка вгоняет диски в полный аут (а на SSD просто просаживает пропорционально нагрузке).

300% cpu на ядро на запись, и 200% на чтение (в сумме — 500%)

Не очепятка случайно ли? 300% cpu на диск?

Это жаргон. Цеф жрёт процессор, много процессора. Когда сервера планируются, если конфигурация планируется без cpu/net bottleneck'ов, то учитывается worst case CPU use для ceph'а, и это 5 ядер CPU на устройство. Если само устройство достаточно быстрое, можно найти нагрузку, которая таки 500% сожрёт.


Чтобы самим посчитать — сделайте ceph-osd на brd (block ram disk), в этой ситуации все боттлнеки будут в коде ceph'а (если бенчмаркать rados на пуле из одной osd на localhost). И это от 480 до 530% cpu в зависимости от модели.


Если конфигурация делается cpu bound (это нормально — вопрос цены же), то тут нужно хорошо понимать, что под определёнными нагрузками диски (SSD) будут простаивать.

Я вполне понимаю суть изначального сообщения. Просто у вас уровнем выше написано "300% + 200% на ядро", что вроде как должно быть чем-то вроде "300% + 200% на blockdev". Ядро воспринимается как "ядро cpu" в том контексте.

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

Ну, cloudmouse это отдельный случай, а у ceph'а есть простые настройки о том, что важнее, сохранность данных или доступность. Нужна сохранность — min_size=2 (или даже 3), нужна доступность — min_size=1 под личную ответственность.

Алсо, отказ ноды в ceph'е не приводит к людой деградации производительности, данные просто реплицируются на оставшиеся ноды. По нагрузке это мало отличается от deep_scrub'а, который и так регулярно делается.

Кажется Вы написали ответ, не заглядывая в ссылки, где детально описана суть проблемы.

Мне кажется, что очень сильно зависит от топологии. Если Вы внимательно почитаете исходную статью, то увидите, что там достаточно специфический конфиг с несколькими демонами цефа (OSD, если я правильно помню терминологию) на один узел. И их конкуренция друг с другом в условиях лимитированной озу.
Это не отменяет того, что при помощи цефа можно хорошо себе отстрелить обе ноги, но надо же «нормально делать — нормально будет»

Там же написаны базовые рекомендации — не собирать суперкомпьютеры под ceph. Если у вас кластер из 1000 почти-десктопных серверов (1 процессор, 8 тредов, 2 ssd), то вы вылетевшую стойку после двух суток починки не заметите. А если у вас superdome с 4x24 тредами и двумя jbod enscolsure на каждый сервер, то тут даунтайм одного сервера расштатает всё и вся.


Кстати, при том, что операционная боль от "медленного цефа" сохраняется, я напоминаю, что основной выбор тут — надёжность данных.


Историю mousecloud я знаю, но я не знаю что именно такого плохого они сделали.

Это также не бесплатно для любой компании.

Я прошу прощения, но у меня мозг сломался на этой фразе. Заглянул в оригинал и все стало понятно:


It's also not going to be free for every organization.
Разница с гластером в первую очередь в том, что гластер это только файловое хранилище. Сеф даёт сразу все — блок, файл и объектное хранилище. При чем все три являются надстройками над rados, которое тоже объектное. Знаю на рынке других таких систем.
Как правило сеф надёжнее и таки быстрее, если говорить о нелинейных нагрузках.

Антиреклама курсов?


Такое ощущение, что статью писал человек, с ceph вообще незнакомый. Периодически вообще сравнивается тёплое с мягким: расскажите, например, как образом вы сравниваете GlusterFS — файловую систему, и один из компонентов ceph: объектное хранилище? С точки зрения возможности использования под Win сравните тогда CephFS с GlusterFS — ни первую, ни вторую там использовать нельзя (хотя сейчас пишут какой-то драйвер, вроде).


А жаль: софт-то отличный.

Only those users with full accounts are able to leave comments. Log in, please.