Комментарии 116
Порой количество таймаутов по блок девайсам (в ВМ virtio-scsi) просто зашкаливало. Кластерам перконы от такого оочень печально. В итоге похоронили саму идею довести кластер до приемлемого уровня производительности и просто ушли на покупной солюшн с ceph-a.
1. сеть
2. размер объектов
3. активность записи
Короче говоря, с тех пор как мы отказались от цефа, жить стало намного проще и приятнее.
IBM решил ещё землицы сверху присыпать?
Поясните, пожалуйста, что Вы имели в виду.
IBM купил RedHat который развивал Ceph. Спустя месяц, поддержка Ceph была передана OSF. У IBM есть своё, аналогичное проприетарное решение за много денег. Ещё спустя пару недель начались статьи про то сколько много проблем в Ceph. Хотя до этого, на том же хабре все кушали кактус видимо.
Я мимокрокодил, просто слежу за новостями и не верю в совпадения, поэтому и спросил:)
Но мне кажется, что такие статьи сами по себе даже были бы полезней, как мы взяли технологию X и споткнулись об грабли здесь, и прострелили себе палец там, чем простые мануалы вида «развернуть кластер за 10 минут для чайников».
Я кончено так себе аналитег, но смысл им продавать красношапку тем более дешевле чем купили? Избавиться от убыточных или конкурирующих решений и иметь уважение.
Как бы под это дело гном не закопали. Хотя, может лучше бы и закопали, а то сообщество расслабилось на корпоративных харчах :)
Запустили сделку 28 октября 2018, есть не более года до её завершения или отмены. Вероятно будут какие-то дополнительные отчеты в SEC и пресс-релизы об окончательном завершении.
https://www.sec.gov/Archives/edgar/data/51143/000110465918064384/a18-37205_28k.htm
… right of either party to terminate the Merger Agreement if the Merger is not consummated on or before October 28, 2019 (subject to certain extension rights), (ii) the right of Red Hat to terminate the Merger Agreement to accept a Superior Proposal (..) for an alternative acquisition transaction… and (iii) the right of IBM to terminate due to a change of recommendation by the Red Hat Board of Directors.
…
If the Merger Agreement is terminated under certain circumstances, including termination by Red Hat ..., Red Hat will be obligated to pay to IBM a termination fee of $975,000,000 in cash.
Юридический план процесса совершенно непонятен и точных дат не содержит: https://www.sec.gov/Archives/edgar/data/1087423/000119312518310577/d640856dex21.htm
Как минимум:
— забрать все патенты себе (и задушить конкурентов, чтоб они не смогли их использовать)
— забрать все перспективные технологии
— убить разработку всего конкурентного по отношению к продуктам IBM
а все остальное продать по бросовой цене — деньги ведь не пахнут.
Just big business, nothing personal.
Достаточно — это сколько?
● Не отключайте SWAP.
Разве своп поможет? Имхо только продлит агонию.
По рекомендации разработчика ceph 1 Gb на 1Tb:
Hardware recommendations
Дополню:
Там приписка «Чем больше тем лучше».
Насчёт свопа согласен. Он скорее продлит агонию. Но мои эксперименты с безсвоповыми серверами показывают, что их действительно сложно готовить правильно. Тем более, когда на них крутится софт, который привык к оптимистичному выделению/распределению памяти. Это не означает, что все плохо. Можно. Но нужно понимать риски и иметь крепкие нервы )
Кстати, у меня есть подозрение, что при использовании без свопа, у нас ОЗУ недоутилизирована (парадокс), но это можно объяснить хотя бы тем, что нам ее понадобится в пиках больше (своп действительно позволяет их "сгладить" ценой на нагрузки на диск и латентность)
2. пришедший OOM валит без разбора всех и вызывает шторм
если бы была возможность лимитировать ceph по памяти настройками самого ceph, то swapless конфигурация имела бы смысл. Но в наших реалиях потребление памяти ceph'ом можно только прогнозировать…
1. ceph плохо переживает, когда ОС ему на malloc говорит что память не выделит
архитектурный просчет, ИМХО. Памяти ведь никогда не бесконечное количество, к сожалению.
И еще я почти наверняка уверен, что любое ПО «течет» так или иначе. Просто какое-то — сильнее, а другое — меньше (я даже сталкивался с утечками в драйверах в ядре).
2. пришедший OOM валит без разбора всех и вызывает шторм
Ну, это тоже регулируется относительно. Тот же oom_score_adj никто не отменял. Но, понятное дело, лучше до этого не доводить.
Поэтому просто принимает за данность, что процессы должны умирать рано или поздно. Лучше всего — в контролируемые администратором промежутки времени.
Интереснее вот что: выгоднее держать много маленьких серверов или мало больших имеющих swap на NVME и кучей памяти. Особенно если учесть что плотные чипы DDR дороже чем менее плотные, да и слоты под них не бесконечные. При этом в маленькие сервера нужны 10G карты, нужна коммутация, что тоже затраты.
Надо различать swapping и thrashing. Свапинг — 5-20 операций в секунду, устройство свопа утилизировано меньше 10%, thrashing — красное в atop'е (>90%). Второе — аварийный режим и должен ловиться мониторингом по факту «началось», ещё до того, как обсыпется прикладной софт.
Я бы разделил так. swap для определенных видов нагрузок категорически нежелателен. Например, мы делаем бескомпромиссно быструю систему и самое главное — предсказуемую по latency. Fail fast & fail safe. Но при этом распределенную и масштабируемую. Тот же куб предполагает, что своп выключен. Например, serverfault.com/questions/881517/why-disable-swap-on-kubernetes
github.com/kubernetes/kubernetes/issues/53533
kubernetes.io/docs/setup/independent
Swap disabled. You MUST disable swap in order for the kubelet to work properly.
Для других типов нагрузок swap необходим.
Касательно ceph… ну, не знаю. Я не спец по нему. Но думаю, что можно и обойти.
Надо различать swapping и thrashing. Свапинг — 5-20 операций в секунду, устройство свопа утилизировано меньше 10%,
касательно своппинга. Ядро вообще им заниматься не должно, т.к. тот же page cache должно быть можно сбросить и считать все немодифицированные страницы с диска. Если страница модифицирована, то там, очевидно, НУЖНЫЕ данные. А если они не нужны, то, извините, вопрос к тому через какое место написан софт.
Насчёт «вопросы к тому, через какое место написан софт».
Ну вот смотрите. У нас есть python. Python всегда хранит в памяти исходный текст того, что выполняет, но работает с байткодом. Что делать? Все эти десятки мегабайт help(), копии всех объявлений строк, включая локализации т.д. Оно всё отлично улетает в swap, но не может быть выкинуто из кеша (потому что RSS).
Если у вас есть вопросы к софту, и он является индустриальным стандартом, то можно либо быть д'Артаньяном, либо жить с тем, что есть.
Если страница модифицирована, это может быть копия конфига, это может быть данные инициализации сервиса, структур кода, который не используется и т.д.
В видео отлично объяснено откуда появляются неиспользуемые страницы памяти — фрагментация памяти. Многие языки программирования не делают дефрагментации, и даже SLAB не сильно помогает из-за того, что used области перемежаются с unused.
Опять же, вы можете заявить «ваш софт говно», но я могу сказать только одно в ответ: «другого софта у меня для вас нет, жрите что дали».
Ну вот смотрите. У нас есть python. Python всегда хранит в памяти исходный текст того, что выполняет, но работает с байткодом. Что делать? Все эти десятки мегабайт help(), копии всех объявлений строк, включая локализации т.д. Оно всё отлично улетает в swap, но не может быть выкинуто из кеша (потому что RSS).
Вообще отдельный вопрос зачем Python так делает. Чтобы потом всегда можно было перекомпилировать код? Ну, такое себе. Либо получается, что разрабы языка и интерпретатора не считают, что это проблема (и доп. расходы на эти «лишние» данные не такие большие).
Опять же, вы можете заявить «ваш софт говно», но я могу сказать только одно в ответ: «другого софта у меня для вас нет, жрите что дали».
эт точно. Хорошо, когда софт пишут по заказу ) там можно выдвигать требования. А когда уже есть готовая коробка или решение — ну, да, приходится жить с тем, что есть.
… Когда софт пишут по заказу обычно выдвигаемые требования кроются выдвигаемыми инвоисами и вопрос экономии десятка мегабайт на копии процесса автоматически снимается.
. Я только что завернул предложение уменьшить число серверов на локацию (не важно в чём). Аргумент: сервер стоит 100 баксов в месяц, на 4 локации это экономит 400 евро в месяц. Причина, почему завернул? 2 месяца работы команды из трёх человек для поддержки такого режима. Берём 6 зп, делим на 400 евро и видим, что окупаемость за горизонтом планирования.
Свап не «продлевает агонию» — он позволяет сохранить доступность данных с деградацией производительности. Большой latency («тормозит») лучше чем полная недоступность данных.
Свап не «продлевает агонию» — он позволяет сохранить доступность данных с деградацией производительности. Большой latency («тормозит») лучше чем полная недоступность данных.
если речь не про Ceph, то все ровно наоборот. Тормозит == недоступность сервиса (условно у пользователя страница открывается 5 минут — мы все равно его потеряли) и приплыли.
К тому же зачастую наличие swap'а маскирует проблему, заметает ее под ковер. Что приводит к ее возникновению уже сильно позже и существенно с более серьезными последствиями (речь не про самые простые случаи, ес-но, типа самого дешевого хостинга, который лишь бы хоть как-то работал).
Грамотным видится подход с ограничением доступного объем для каждого OSD, но действительно есть риск не угадать с точными значениями и создать проблемы на ровном месте.
Не надо путать нормальную работу и аварийную. Своп мешает первой но нужен для второй.
А чтобы проблемы не заметались под ковер — нужен мониторинг.
(и кроме варианта — сделать swap)
Дело в том, что аварии-то не было. Было… снижение производительности на время переходных процессов.
Я даже не шучу. Просто в 40 раз меньшая производительность. Но ни одного запроса не потеряно, данные не потеряны. Latency в сотни секунд, очереди в тысячи запросов, но всё хорошо.
Чтобы снижения производительности не было, надо иметь запас по мощности.
Допускаю, что возможен отказ любого другого плана. Помимо "легла по питанию". Ну, свитчи сдохли. Или человеческий фактор — что-то кривой настроили или обновили. Короче — отказы случаются и лучше к ним быть готовыми заранее
К сожалению swapinness не панацея. У меня есть сервер на котором 80% памяти это пейдж кеш т.е. свободно но ядро даже при нуле сваппинесс свапит еще как.
Этот же — личный сервер, на котором в некоторых случаях (очень редких) возможен всплеск потребления памяти, поэтому пока не отключаю.
Меня просто удивляет невозможность заставить систему не свапить при наличии большого объема page cache и\или свободной памяти. По идее ручка vm.swappiness как раз призвана регулировать это поведение, но судя по всему она носит рекомендательный характер :)
Потому что нулевой сваппинесс — это не означает, что свапаться будет запрещено совсем.
Поэтому если нужно старое поведение ядер до 3.15 — ставим свопность в 1.
Потому что нулевой сваппинесс — это не означает, что свапаться будет запрещено совсем.Никто и не ожидает что оно не будет свапиться вообще. Но я ожидаю что пока у меня page cache дофига еще то оно не будет свапиться, а это не так:
# free -h
total used free shared buff/cache available
Mem: 15G 2.5G 417M 35M 12G 12G
Swap: 14G 1.1M 14G
1.1Мб все равно уже в свапе и это через полчаса после того как я сделал swapoff/swapon. Через сутки там уже будет метров 300-500.
Поэтому если нужно старое поведение ядер до 3.15 — ставим свопность в 1.Не влияет. Картина выше как раз с:
# sysctl vm.swappiness
vm.swappiness = 1
При 12Гб доступной памяти ядро все равно упорно лезет в свап.
# uname -a
Linux ams 4.4.0-138-generic #164-Ubuntu SMP Tue Oct 2 17:16:02 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
Да, этот момент хорошо бы лине переработать, но у меня квалификации недостаточно. А опытным видимо и так хорошо.
# uname -a
Linux pve1 4.15.17-3-pve #1 SMP PVE 4.15.17-12 (Fri, 08 Jun 2018 11:18:32 +0200) x86_64 GNU/Linux
# sysctl vm.swappiness
vm.swappiness = 60
# free -h
total used free shared buff/cache available
Mem: 251G 102G 5.2G 131M 144G 147G
Swap: 8.0G 7.9G 94M
# cat /opt/swapfree.sh
#!/bin/bash
free_mem="$(free | grep 'Mem:' | awk '{print $7}')"
used_swap="$(free | grep 'Swap:' | awk '{print $3}')"
echo -e "Free memory:\t$free_mem kB ($((free_mem / 1024)) MiB)\nUsed swap:\t$used_swap kB ($((used_swap / 1024)) MiB)"
if [[ $used_swap -eq 0 ]]; then
echo "Congratulations! No swap is in use."
elif [[ $used_swap -lt $free_mem ]]; then
echo "Freeing swap..."
/sbin/swapoff -a
/sbin/swapon -a
else
>&2 echo "Not enough free memory. Exiting."
exit 1
fi
Кривой костыль, но хоть не дает свап забивать особо.sync; echo 3 > /proc/sys/vm/drop_caches
чуть подробнее например тут
www.tecmint.com/clear-ram-memory-cache-buffer-and-swap-space-on-linux
Я не хочу его сбрасывать, он хороший и полезный. Если очистить — ядру опять придется его наполнять и насиловать винт.
Я же только выталкиваю страницы из свапа обратно в память.
Можно делать не 3 а 1 или 2, тогда только часть кэша будет очищена. А поскольку большой нагрузки на диски там не было, сбрасывали дисковый кэш, он быстро и достаточно безболезненно заполнялся опять, данными для актуальных запросов.
Ну кроме варианта продать все и забыть.
Что можно сделать людям, у которых есть много серверов с большими дисками, но нет памяти.
Собрать RAID60 из дисков со всех серверов, подключенных по iSCSI :)
Да, будет SPOF, но можно довольно быстро собрать тот же RAID на другом сервере кластера при гибели первого.
Но консистентность там ровно такая же как в рейде с локальными дисками. Если нет буфферизации записи на сетевом (ISCSI/FCoE/NBD) уровне — тут уже зависит от настроек таргета.
Еще можно сделать DRBD9 — он умеет >2 реплик, собрать какую-нибудь хитрую конфигурацию.
Как pacemaker помогает LVM?
SPOF будет в любом случаеРазумеется нет. Active-Passive резервирование — это тоже fault-tolerant решение.
Но пока это будет происходить — массив будет недоступен.С учётом того, что драйвер дисковой системы обычно ждёт ответа 30-60 секунд до того, как поднимет ошибку в приложение — переключение может быть произведено вполне прозрачно для клиентов.
В данном же случае непонятны условия эксплуатации и миграции, и в каких случаях будут проблемы у клиентов.
Вот ситуация — приходит грустный электрик и говорит, ребята завтра город будет кабель менять вводный, извините на полдня выключает нас. А дизеля у нас нет, и мы готовимся просто потушиться на это время. Как это штатно сделать — и главное как после этого взлететь чтобы и данные не деградировали и волосы на теле не поседели…
Я думаю это будет безболезненнее чем просто отключать OSD и держать кластер в деградированном состоянии.
делаем shutdown / suspend клиентов (нет клиентов — нет нагрузки — нет дегрейдов — не будет рекавера)
опционально — делаем osd nodown
шатдауним сеф
обратное включение:
включаем оборудование
дожидаемся что все osd запустились
снимаем noout (и nodown если он стоял)
запускаем клиентов
К примеру сколько нод нужно для организации ceph? Возможно ли чтоб ноды были с разными дисками? На proxmox стоит ли его поднимать? Нужен ли raid при настройке ceph?
Буду благодарен за помощь, начальство дало задачу слепить из хранилищ ceph, а как это организовать мало информации.Спасибо.
pve.proxmox.com/pve-docs/chapter-pveceph.html
Если у вас уже стоит проксмокс, то лучше поднимать на нем, в нем уже есть удобный мониторинг и управление. Убедитесь только, что оперативной памяти хватит всем виртуалкам и хранилищу, и что у вас есть отдельная сеть для обмена данных.
Минимум три ноды, что для самого проксмокса, что для хранилища.
Диски можно разные, но желательно, чтобы не было перекоса по суммарному объему на нодах.
Для дисков хранилища рейд не нужен.
Делали мы миникластер из трёх нод на проксмоксе. Кое как запустили, вроде работает, через какое-то время одна года вылетела по железу — вроде работает, порадовались, починили железо, включили и прилегло всё намертво на восстановлении :(
1. чем больше нод, тем лучше. 4-5 минимум ИМХО, лучше СИЛЬНО больше;
2. ноды с разными дисками да, конечно;
3. стоит ли — поднимите тестовый стенд и проверьте сами;
4. raid категорически не рекомендуется
2) habr.com/post/252221
2 факапа с интервалом в месяц. Причина похоже в использовании ceph…
Ответ, почему же так произошло, кроется в Linux’овом malloc’е.
Только вот ceph использует другие реализации malloc — gperftools tcmalloc или jemalloc (https://www.msi.umn.edu/sites/default/files/MN_RH_BOFSC15.pdf https://ceph.com/geen-categorie/the-ceph-and-tcmalloc-performance-story/ https://github.com/ceph/ceph/blob/1ade7149106cfe12ed7af16edd609bdd0e561708/CMakeLists.txt#L339).
"specify memory allocator to use. currently tcmalloc, tcmalloc_minimal, \
jemalloc, and libc is supported. if not specified, will try to find tcmalloc, \
and then jemalloc. If neither of then is found. use the one in libc."
Они умеет агрессивно отдавать все свободные страницы (из середины кучи, арены, или иной структуры учета памяти) обратно в ОС (через MADV_FREE или MADV_DONTNEED) — http://man7.org/linux/man-pages/man2/madvise.2.html
MADV_DONTNEED
Do not expect access in the near future. (For the time being,
the application is finished with the given range, so the
kernel can free resources associated with it.)
…
The kernel is free to delay freeing the pages until an
appropriate moment. The resident set size (RSS) of the
calling process will be immediately reduced however.
MADV_FREE (since Linux 4.5)
The application no longer requires the pages in the range
specified by addr and len. The kernel can thus free these
pages, but the freeing could be delayed until memory pressure
occurs.
Ага. Но ему это не слишком помогает. Либо куча фрагментирована либо еще что то. И jemalloc не используют. В определенных условиях оно крашит осд через несколько часов работы
Насколько я помню, для многих размерных классов tcmalloc группирует несколько страниц памяти для хранения объектов одного размерного класса (span, http://goog-perftools.sourceforge.net/doc/tcmalloc.html Set of Small Chunks gperftools/src/span.h Span.sizeclass; к "small" относит все что <= 32Кб), за счет чего фрагментация может несколько уменьшится. В отличие от glibc, где malloc экономит байты и смешивает все размеры, в tcmalloc внутри одной страницы все объекты имеют один размер, и, часто, сходные времена жизни.
Либо цеф просто слишком много навыделял. Полезно проверить профиль памяти — http://docs.ceph.com/docs/master/rados/troubleshooting/memory-profiling/ (в профиль попадают выделения памяти, совершенные после запуска профилирования).
Кто-нибудь пробовал ceph с glibc malloc?
И, судя по всему, были и другие стойки.
Что мешало через карты настроить одну копию osd на одну стойку + ceph.conf min 2 norm 3 копии?
Это дало бы вам возможность полностью обслуживать одну любую стойку без прерывания доступа к данным на запись со стороны клиентов. Так же это ускоряет запись, после 2 копий отпуская сессию, 3-я фоном создается.
У нас всего 3 хоста, как раз разнесены в разные стойки, с распределением в картах записью 1 копии osd на 1 хост. Для обслуживания хоста достаточно включить noout nodown и спокойно менять комплектующие, ставить прошивки.
Но не уверен насколько такой пул приемлем для rbd.
Начиная со слов «после 2 копий отпуская сессию».
И стенд с которого снимались графики как раз и был настроен под 3/2, и
1. Я не буду давать ссылку на цитату, на сайт разработчиков если кому надо найдете сами, где говорилось примерно следующее: «Не используйте под ceph несколько мощных машин, используйте много маленьких.» Они же взяли три мощные тачки и запихнули по 10ssd в каждую. Далее на оф. сайте не раз говорится что ceph очень требователен к сети! Они же это все обвязали 10Гбитной сетью. Одна нормальная ssd-ха способна при копировании утилизировать 10Гбитную сеть. Теперь взглянем на картину вцелом. На каждой машине по 10 демонов OSD пытаются реплейсить и актуализировать данные, при этом еще идет жесткая клиентская нагрузка. Конечно при таком раскладе сеть будет утилизирована полностью, будут расти кэши записи и врезультате все это встанет в интересную позицию. А на какой исход еще можно было расчитывать при такой конфигурации. Наивно было полагать что все 10 ssd дисков синхронизируются под клиентским хайлоадом при 10Гбитной сети. И конечно чуда не произошло.
2. Тестирование. Вот здесь комментарии излишни, мало того что они не умеют считать дважды два. Так они ввели в эксплуатацию hiload систему которая не тестировалась на hiload. А на какой исход эти господа расчитывали вообще?! Нужно было тестировать, выяснить его физические пределы, а продакшене использовать не более 50%. Вот тогда не будет ни каких «Анатомий катостроф».
Мы с вами точно одну и ту же статью читали?
где рекламируется их собственный патч, без которого ceph по их заверениям «нежизнеспособное говно». А получите вы этот патч только когда станете их клиентом.
Не вижу призыва покупать патч. Напротив, вижу обещание предоставить этот патч сообществу после доработки (уж не знаю произошло ли это за 2 года, пишу про то что прочитал).
Наивно было полагать что все 10 ssd дисков синхронизируются под клиентским хайлоадом при 10Гбитной сети. И конечно чуда не произошло.
Вы так пишете, как будто проблема была в пропускной способности сети, а не в доступной оперативной памяти.
Не вижу призыва покупать патч. Напротив, вижу обещание предоставить этот патч сообществу после доработки (уж не знаю произошло ли это за 2 года, пишу про то что прочитал).
На видео 41:38 человек явно спрашивает где можно посмотреть патч, где он его вежливо посылает на хрен и говорит что получите, цитирую: «Когда приобретете наш програмно-аппартный комплекс».
Вы так пишете, как будто проблема была в пропускной способности сети, а не в доступной оперативной памяти.
И да, по моему мнению здесь была проблема именно в сети. Оперативы нехватало, потому что данные не могли записаться и росли кэши.
будут расти кэши записи и врезультате все это встанет в интересную позицию
Кэш тут ни причем. Проблема деградации производительности происходит только от архитектуры и реализации Ceph, который рекаверит объект полным копированием перед записью с целью обеспечить надежность. К проблеме роста потребления памяти это не имеет никакого отношения, потому что объем данных, размещенных в очереди на запись, на один-три порядка меньше чем объем данных репликации.
В классическом кейсе RBD, когда у вас например 1000 образов (== 1000 клиентов) у каждого из которых очередь в 128 запросов, при записи по 64KB в одну операцию у вас требуемый на «кэши» объем памяти будет порядка 8GB на весь кластер.
Проблема потребления памяти имеет свои корни в большом объеме данных, которые OSD удерживает в памяти во время начального согласования статуса PG (пиринга), в объеме хранимых PG log и в том, как OSD принимает решение о транкейте этих логов. OSD в режиме рекавера выедает память даже в отсутствие нагрузки — еще в процессе пиринга. И это особенно активно проявляется в erasure code большой размерности (например 6+2, 8+3 и т.д.) при большом количестве PG — либо у нас не потранкейчены логи и мы быстро собираем дегрейднутые объекты, либо логи потранкейчены, и тогда нам надо собрать собрать информацию о версиях всех объектов. Либо перезаливать PG полностью.
Это ж просто способ воспроизвести проблему в лабораторных условиях. Исходно-то на эти грабли DigitalOcean наступили (и, возможно, не только они).
Насколько я понимаю, у вас есть правильная конфигурация, которая позволит потерять в производительности не более 50% при отказе 30 процентов оборудования? Я думаю, сообществу было бы интересно её увидеть. И её стоимостную оценку, в долларах за гигабайт. Включая сетевое оборудование. В расчете, ну, например, на 300TB полезного пространства. А то знаете ли, с эльфийскими фантазиями о бюджете можно много насочинять, а так чуть ближе к земле будет.
Что же до сетапа стенда — конфигурация стенда вполне себе разумная. OSD обслуживает порядка 45 IOPS в секунду (исходя из service time 22ms, мы же говорим о рекаверных операциях блоком 4MB), сеть десятка, одна нода протянет 400… 450 IOPS по дискам и примерно 300 IOPS по сети. Чуть получше сеть хотелось бы конечно (2x10 вполне бы хватило) — но в целом да, нормальный сетап для компонентов 2016-2017 года.
А то знаете ли, с эльфийскими фантазиями о бюджете можно много насочинять, а так чуть ближе к земле будет.это вообще ни какого отношение к обсуждению не имеет. Могу лишь напомнить что кроилово, ведет к попадалову.
2x10 вполне бы хватиловот наконец то вы озвучили это. Агрегация и бондинги появились за долго до 2016-2017 года.
это вообще ни какого отношение к обсуждению не имеет
Ну почему же? Если Вы с таким апломбом декларируете о том, что у всех неправильный сетап — то наверняка Вы знаете правильный. Сообщество ждет. Сефовский чат в будет рад услышать предложения эксперта.
вот наконец то вы озвучили это. Агрегация и бондинги появились за долго до 2016-2017 года
Разумеется. Я вам по секрету скажу — в продуктиве мы это использовали. И не только мы — в общем то практически все, у кого сеф в продуткиве, к этим ухищрениям прибегают.
Вот только это не помогает. Не выходит разницу в порядок замаскировать двукратным увеличением полосы. И я вам еще более страшную тайну открою — даже 2x40G вам не поможет. Потому, что Ceph надо вместо записи 4KB прочесть 4MB, записать 4MB, обновить пачку метаданных (причем зачастую еще и в синхронном режиме, то есть в один поток) — и только потом собственно приступать к записи 4KB. И опять же — те, кто использует сеф в продуктиве это тоже знают.
И именно поэтому в майнстриме ведутся работы по оптимизации рекавера, чтобы не реплицировать объект полностью. Потому, что разработчики понимают, что алгоритмическую проблему просто «закидать железом» нельзя.
Ну почему же? Если Вы с таким апломбом декларируете о том, что у всех неправильный сетап — то наверняка Вы знаете правильный. Сообщество ждет. Сефовский чат в будет рад услышать предложения эксперта.
Можете указать место, где я говорю «Я один знаю правильную конфигурацию». По моему я явно выделил что цитирую, и это речь о «эльфийскими фантазиями о бюджете». Что касается конфигурации, то не у всех, а у вас в данном конкретном описываемом кейсе. И это сказал не я, а разработчики цефа, что набить под завязку винтами три тачки — это неправильно. Вы и сами об этом пишите:
Что мы можем сделать?
Ответ 1: Бороться можно только архитектурой — делать больше доменов отказа.
Но почему то вас очень задевает, когда я вам говорю то же самое.
Разумеется. Я вам по секрету скажу — в продуктиве мы это использовали. И не только мы — в общем то практически все, у кого сеф в продуткиве, к этим ухищрениям прибегают.Так а почему в статье/докладе об этом не слова и все тесты без бондов. И кстати почему не слова об утилизации сетевых интерфейсов.
И как то непонятно получается то вы говорите «2x10 вполне бы хватило», то говорите «Вот только это не помогает.» Вы уж определитесь.)
И как то непонятно получается то вы говорите «2x10 вполне бы хватило», то говорите «Вот только это не помогает.»
Тривиально. «Вполне бы хватило» для того чтобы полность с гарантией возможности OSD по рекаверу. Не помогает — потом что выигрыш в 15-20% кторый можно получить улучшив сеть не способен закрыть потери от рекавера.
Но почему то вас очень задевает, когда я вам говорю то же самое.
Меня раздражают эльфы-архитекторы предлагающие заливать железом архитектурные проблемы. Зависимость между стоимостью и производительностью логарифмическая.
пишете статью
Очень может быть. Как раз в планах скоро тестирование сборки стоит. Забегая вперед, скажу что сегодня с утра провел небольшое тестирование на 3 ссд, в каждой машине, в пиках загрузка по сети была около 9Гбит. Бонд работал с загрузкой обоих линков. Тестирование производилось без даунгрейда.
Ceph. Анатомия катастрофы