13 494
правки
Изменения
м
Причина в томВ данной статье описано, что локальные каких показателей производительности можно добиться от цефа и как. Но сразу предупрежу: локальный SSD вы не догоните. Локальные SSD сейчас ОЧЕНЬ быстрые (особенно NVMe). Порядок latency: , порядок их задержки — 0.05ms. Догнать их эту цифру SDS-ке крайне трудно (одна только сеть сожрёт те же 0.05ms), перегнать — перегнать — наверное, вообще невозможно. В этой статье собран опыт о том, что (и почему) можно сделать с Ceph-ом, чтобы он стал побыстрее. Примерным ориентиром служит доклад Nick Fisk «Low-Latency Ceph», в его исполнении Low latency это 0.7ms; на лучший результат рассчитывать особенно не приходится. 0.7ms — это всего лишь примерно ~1500 iops в 1 поток.
Нет описания правки
Ceph — это SDS (по-русски — программная СХД), которая по некоторым параметрам является уникальной в своём роде, и в целом, умеет очень многое — S3, диски виртуалок, кластерную FS + огромный багаж дополнительных фич.
И всё было бы хорошо — бери, ставь, запускай своё облако и руби бабло — если бы не один маленький нюанс: ПРОИЗВОДИТЕЛЬНОСТЬ. Терять 95 % производительности в Production-е разумным людям обычно жалко. «Облакам» типа AWS, GCP, Яндекса , по-видимому, не жалко — у них тоже собственные крафтовые SDS и они тоже тормозят примерно так же. Не жалко, видимо, ибо дорого — эти 95 % заложены в прайс. :-) но этот вопрос оставим — кто мы такие, чтобы их судить.
== Бенчмаркинг ==
Задержки обычно важнее простой пиковой производительности случайного чтения/записи, так как далеко не каждое приложение может загрузить диск при большом параллелизме / глубокой очереди (32-128 запросов).
Примерным ориентиром наилучшей возможной задержки Ceph служит доклад Nick Fisk «Low-Latency Ceph», в его исполнении Low latency это 0.7ms. Это и есть ориентир, на лучший результат рассчитывать особенно не приходится. 0.7ms — это всего лишь примерно ~1500 iops в 1 поток.
=== Тестирование дисков ===
