Comments 18
Поправил статью, добавил ссылку на первую часть в начало.
Про ЛАСП все-таки интересно, в какую именно сторону ограничение было, от сервера к коммутатору или наоборот. Видимо, если тестировали между двумя серверами только, то ситуация симметричная и понять невозможно, но можно было бы еще с третьего сервера какой-нибудь трафик нагенерировать. А то непонятно, в чем проблема, со стороны коммутатора или со стороны сервера.
Еще по поводу теста, он проводился каким трафиком, юдп или тсп? Результаты приведенные — из iperf только? С загрузкой интерфейсов на коммутаторах и серверах сравнивали? Тому, что на 100 потоках результат сильно хуже, чем на 10 потоках, нашли обьяснение? В производительность сервера уперлись?
Копать дальше в LACP не стали: покрутили только параметры, о которых я написал в статье и сравнили с ospf. Решили не углубляться дальше и просто использовали то, что показало себя лучше.
Тесты проводили в основном TCP (UDP гоняли пару раз всего). Результаты приведены из qperf — он показывает лэтэнси и bw в зависимости от размера пакета. Он умеет последовательно запускать их разного размера
qperf --time 10 -oo msg_size:1:64K:*2 -v --use_bits_per_sec ${test_address} tcp_lat tcp_bw
В итоге прогонялось по восходящей от 1 байта до 64 KiB
Наименьшее лэтэнси было обычно пакетами до 32 байт
На коммутаторах и интерфейсах bw показывалась одинаковая.
Разница в 10 и 100 потоков — на самом сервере упора в ресурсы не заметили. Прерывания были расбросаны по ядрам и ни одно не упиралось в потолок, памяти было достаточно, ошибок на сетевых интерфейсах или рост очереди не замечали.
Погрешили на коммутаторы.
Поскольку появилось время и возможность потестировать, думаем в ближайшее время разобраться с проблемой у LACP и падением производительности при росте потоков до 100.
А во время теста с ласп физические линки из бонда точно не выпадали на коммутаторе и\или со стороны сервера? lacp fast или slow? Может просто при заполнении порта дропались сообщения lacp, физический линк вылетал из бонда, потом обратно добавлялся, на усреднении вышло меньше, чем 20 гбит.
А джуниперу думаю все равно, что 10 потоков, что 100. Надо конечно попытаться понять, в обе ли стороны скорость ограничена, или в какую-то одну, тогда будет ясно, вина на стороне коммутатора или сетевухи.
На ваш взгляд, это реально, танцы с бубном или фантастика?
Интересна скорость и возможные проблемы
Опять же чисто на уровне идеи: мы получаем kernel module для CephFS вместо userland-а для HDFS, плюс мы все лучше и лучше умеем тюнить Ceph и его компоненты, так что такой эксперимент выглядит оправданным.
Но финальный ответ только по итогам тестов, причем как нагрузочных, так и функциональных. Мы не настолько хорошо знаем Ceph, чтобы давать какие-то теоретические оценки его надежности и производительности.
Есть кластер в 1 Пб (RF=3) — нужно будет выделить 1 ( или 3?) Тб оперативки под Ceph?
Да и стабильность: диски в кластере раз в пару месяцев умирают, по гарантии меняются за 2 часа. Как с этим с CephFS?
В зависимости от задач, можно перевести CAPEX в OPEX, но это тоже надо считать от проекта и задач, но как ориентир 1 PB в AWS S3 это порядка 25k $ в месяц.
А про диски я вот совсем не понял вопрос: ну умер физический диск, его надо так же заменить, ceph отреплицирует данные как в момент выхода диска из строя, так и после установки нового.
Варианта CephFS as a Service я пока не встречал, даже не буду гадать какие SLA и времена реакции там могут быть.
Про диски — в hdfs диск меняется 2 часа, как по этому показателю в CephFS?
Если на ноде данных меньше, и у нас кластер допустим на 20 узлов, то и памяти требуется в 20 раз меньше (ну или может в 10 если учитываем репликацию), и то есть от терабайта RAM мы на Ceph тратим только 5-10%, все остальное отдаем под ML.
А про замену диска: тут не про CephFS должна быть речь, за работу с диском отвечает Ceph. И сколько времени это займет, на зависит от объема и скорости диска и занятых данных. Я тут предпочитаю провести эксперимент и замеры, а не говорить оценочно. Но не вижу причин, почему Ceph может или должен быть медленее HDFS-а.
В общем, думаю ближе к 6 или 7-ой части дойдем и до экспериментов с Hadoop-ом и CephFS-ом, тогда замерим и сравним.
Эта так называемая рекомендация "(НАПРИМЕР ~ 1 ГБ на 1ТБ)" = "however, during recovery they need significantly more RAM (e.g., ~1GB per 1TB of storage per daemon)" появилась в файле doc/start/hardware-recommendations.rst в далеком 2013 году, во времена ceph v0.73 (John Wilkins "doc: Updated docs for OSD Daemon RAM requirements. 4423"). Остается совершенно неясным как и откуда её посчитали, какие размеры дисков и ОЗУ были доступны в ту эпоху, в каких предположениях о числе PG, о числе объектов на PG, о размере объекта, о размере лога изменений и т.п. (зато такую рекомендацию легко копипастить в руководства и книги). До 2013 года там было безусловное 0.5-1ГБ "however, during recovery they need significantly more RAM (e.g., 500MB-1GB)".
В 2018 году рекомендацию поменял автор: https://github.com/ceph/ceph/pull/24247/files (повод для пересчета — issue 36163; обсуждение; commit 6af61277; ceph-13.2.3):
OSDs (ceph-osd) By default, OSDs that use the BlueStore backend require 3-5 GB of RAM. You can adjust the amount of memory the OSD consumes with the osd_memory_target configuration option when BlueStore is in use. When using the legacy FileStore backend, the operating system page cache is used for caching data, so no tuning is normally needed, and the OSD memory consumption is generally related to the number of PGs per daemon in the system.Обсуждение https://github.com/ceph/ceph/pull/24247
gregsfortytwo: Similarly we've been saying 1GB/TB on OSDs for a long time, but that messaging was quite confused for users of FileStore OSDs (I've certainly said on the list that I had no idea where it came from, since I think it was initially just made up without justification by some doc writer before we later decided it was a good idea?).
liewegas: The hardware recommendations definitely need a refresh--probably much more than I did here. (I would prefer not to block this critical fix to our defaults with a log conversation about the hardware recs, though!)
Современное руководство RH не привязывается к объему диска — https://access.redhat.com/documentation/en-us/red_hat_ceph_storage/3/html/red_hat_ceph_storage_hardware_selection_guide/ceph-hardware-min-recommend "Red Hat typically recommends a baseline of 16GB of RAM per OSD host, with an additional 2 GB of RAM per daemon" / Minimum of 5 GB of RAM per OSD container
CERN в 2015 году проверял работу вне этой рекомендации (еще на древнем Ceph firefly 0.80.8) и у них работало https://cds.cern.ch/record/2015206/files/CephScaleTestMarch2015.pdf "these machines are not within the recommended Ceph hardware spec, notably the RAM/TB ratio is far off the suggested 1GB/TB. However, this hardware is demonstrated to work well in our existing scaleout storage solution EOS"
Да, при восстановлении цеф будет потреблять память; однако формула "например около 1 ГБ на 1 ТБ данных" не универсальна и получена неизвестно каким методом и из неизвестных "мнений"/ощущений по давним материалам рассылки. Реальное потребление будет зависеть не от объемов данных, а от настроек кластера, числа объектов (либо отношения между размером объекта и дисков), интенсивности записи, длительности восстановления, настроек восстановления. Можно придумать случаи, когда и 1 ГБ на 1 ТБ будет недостаточно. И понять реальное потребление можно только на тестах, приближенных к планируемому использованию.
Сeph — от «на коленке» до «production» часть 2