Comments 116
UFO just landed and posted this here
Вопрос к пользователям крупных ceph кластеров: а у вас нет проблем с таймаутами на клиентах во время ребаланса или подобных внутренних процессов кластера?
Порой количество таймаутов по блок девайсам (в ВМ virtio-scsi) просто зашкаливало. Кластерам перконы от такого оочень печально. В итоге похоронили саму идею довести кластер до приемлемого уровня производительности и просто ушли на покупной солюшн с ceph-a.
Порой количество таймаутов по блок девайсам (в ВМ virtio-scsi) просто зашкаливало. Кластерам перконы от такого оочень печально. В итоге похоронили саму идею довести кластер до приемлемого уровня производительности и просто ушли на покупной солюшн с ceph-a.
Не сказал бы, что тут прямая корреляция от размера кластера. Большее влияние оказывает
1. сеть
2. размер объектов
3. активность записи
1. сеть
2. размер объектов
3. активность записи
Почти год я с ними боролся, и моя история успеха с ceph крайне похожа на вашу. Масла в огонь еще добавляло то, что когда они происходят, systemd на ВМ считает что нужно уйти в emergency mode, из которого их нужно руками выводить. И происходило это не только на ребалансе, а еще иногда и на deep-scrub.
Короче говоря, с тех пор как мы отказались от цефа, жить стало намного проще и приятнее.
Короче говоря, с тех пор как мы отказались от цефа, жить стало намного проще и приятнее.
Очень интересно как организована группа SCSI Gateways. Особенно в плане отказоустойчивости, или направьте где можно узнать больше по этому вопросу.
IBM решил ещё землицы сверху присыпать?
Поясните, пожалуйста, что Вы имели в виду.
IBM купил RedHat который развивал Ceph. Спустя месяц, поддержка Ceph была передана OSF. У IBM есть своё, аналогичное проприетарное решение за много денег. Ещё спустя пару недель начались статьи про то сколько много проблем в Ceph. Хотя до этого, на том же хабре все кушали кактус видимо.
Я мимокрокодил, просто слежу за новостями и не верю в совпадения, поэтому и спросил:)
Возможно имелось ввиду, что сейчас могут посыпаться статьи в стиле get the facts с факапами на продуктах от RedHat, и это как раз будет перед продажей RedHat-a.
Но мне кажется, что такие статьи сами по себе даже были бы полезней, как мы взяли технологию X и споткнулись об грабли здесь, и прострелили себе палец там, чем простые мануалы вида «развернуть кластер за 10 минут для чайников».
Но мне кажется, что такие статьи сами по себе даже были бы полезней, как мы взяли технологию 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.
Как минимум:
— забрать все патенты себе (и задушить конкурентов, чтоб они не смогли их использовать)
— забрать все перспективные технологии
— убить разработку всего конкурентного по отношению к продуктам IBM
а все остальное продать по бросовой цене — деньги ведь не пахнут.
Just big business, nothing personal.
● Выделяйте достаточно RAM на узлах OSD.
Достаточно — это сколько?
● Не отключайте SWAP.
Разве своп поможет? Имхо только продлит агонию.
Достаточно — это сколько?
● Не отключайте SWAP.
Разве своп поможет? Имхо только продлит агонию.
достаточный — это что бы хватило, надо считать. посыл один чем больше — тем лучше. можно вот матчасть почитать. не плохо расписано от докладчика ceph.pro/linux_vm_swap.html и бонусом www.linuxatemyram.com
> Достаточно — это сколько?
По рекомендации разработчика ceph 1 Gb на 1Tb:
Hardware recommendations
Дополню:
Там приписка «Чем больше тем лучше».
По рекомендации разработчика ceph 1 Gb на 1Tb:
Hardware recommendations
Дополню:
Там приписка «Чем больше тем лучше».
Насчёт свопа согласен. Он скорее продлит агонию. Но мои эксперименты с безсвоповыми серверами показывают, что их действительно сложно готовить правильно. Тем более, когда на них крутится софт, который привык к оптимистичному выделению/распределению памяти. Это не означает, что все плохо. Можно. Но нужно понимать риски и иметь крепкие нервы )
Кстати, у меня есть подозрение, что при использовании без свопа, у нас ОЗУ недоутилизирована (парадокс), но это можно объяснить хотя бы тем, что нам ее понадобится в пиках больше (своп действительно позволяет их "сгладить" ценой на нагрузки на диск и латентность)
1. ceph плохо переживает, когда ОС ему на malloc говорит что память не выделит
2. пришедший OOM валит без разбора всех и вызывает шторм
если бы была возможность лимитировать ceph по памяти настройками самого ceph, то swapless конфигурация имела бы смысл. Но в наших реалиях потребление памяти ceph'ом можно только прогнозировать…
2. пришедший OOM валит без разбора всех и вызывает шторм
если бы была возможность лимитировать ceph по памяти настройками самого ceph, то swapless конфигурация имела бы смысл. Но в наших реалиях потребление памяти ceph'ом можно только прогнозировать…
1. ceph плохо переживает, когда ОС ему на malloc говорит что память не выделит
архитектурный просчет, ИМХО. Памяти ведь никогда не бесконечное количество, к сожалению.
И еще я почти наверняка уверен, что любое ПО «течет» так или иначе. Просто какое-то — сильнее, а другое — меньше (я даже сталкивался с утечками в драйверах в ядре).
2. пришедший OOM валит без разбора всех и вызывает шторм
Ну, это тоже регулируется относительно. Тот же oom_score_adj никто не отменял. Но, понятное дело, лучше до этого не доводить.
Поэтому просто принимает за данность, что процессы должны умирать рано или поздно. Лучше всего — в контролируемые администратором промежутки времени.
«oom_score_adj» — у вас есть десяток процессов OSD которые примерно одинаково загружены и примерно одинаково потребляют память и есть незначительные потребители типа cron/sshd/что-то ещё. Если вы убиваете какую-то OSD, это всё равно что её терминирует OOM-killer. Просто пройдет это мягче. А завершение ssd и высвобождение 50MB RAM вам ничего не даст, потому что у вас OSD (например!) весит 7GB RSS.
Уточним — отказ malloc сеф не «плохо переживает» — он его вообще не переживает. OSD тут же абортися. Проверяли :-)
Если объем данных большой, можно swap запихать на NVME какой-нибудь, что, безусловно, медленнее оперативной памяти, но по крайней мере не даст процессам умирать и отсрочит проблему, а возможно и вовсе избавит. Эффект домино происходит именно из-за того что процессы умирают без разбора. Повезет — умрет osd, не повезет — ssh или что похуже.
Интереснее вот что: выгоднее держать много маленьких серверов или мало больших имеющих swap на NVME и кучей памяти. Особенно если учесть что плотные чипы DDR дороже чем менее плотные, да и слоты под них не бесконечные. При этом в маленькие сервера нужны 10G карты, нужна коммутация, что тоже затраты.
Интереснее вот что: выгоднее держать много маленьких серверов или мало больших имеющих swap на NVME и кучей памяти. Особенно если учесть что плотные чипы DDR дороже чем менее плотные, да и слоты под них не бесконечные. При этом в маленькие сервера нужны 10G карты, нужна коммутация, что тоже затраты.
А что дороже: NVME или оперативка?
Для многих систем даже своп на чём попало — это круто. На многогигабайтных системах в своп может улетать всякая редкоиспользуемая (читай, не используемая) фигня, и лежать там до скончания смерти сервера.
Надо различать swapping и thrashing. Свапинг — 5-20 операций в секунду, устройство свопа утилизировано меньше 10%, thrashing — красное в atop'е (>90%). Второе — аварийный режим и должен ловиться мониторингом по факту «началось», ещё до того, как обсыпется прикладной софт.
Надо различать 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 необходим.
Касательно ceph… ну, не знаю. Я не спец по нему. Но думаю, что можно и обойти.
касательно своппинга. Ядро вообще им заниматься не должно, т.к. тот же page cache должно быть можно сбросить и считать все немодифицированные страницы с диска. Если страница модифицирована, то там, очевидно, НУЖНЫЕ данные. А если они не нужны, то, извините, вопрос к тому через какое место написан софт.
Я бы разделил так. 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 должно быть можно сбросить и считать все немодифицированные страницы с диска. Если страница модифицирована, то там, очевидно, НУЖНЫЕ данные. А если они не нужны, то, извините, вопрос к тому через какое место написан софт.
Давайте без экстрима. Да, есть случаи, когда swap недопустим. Однако, таких случаев меньшинство. Если мы рассчитываем на realtime, сюрприз, мы ошиблись ОС. Особой разницы между мегапромахом NUMA при скедулинге и swap'ом на 10-20 страниц с нормальной SSD (менее 10ms на всё) нет.
Насчёт «вопросы к тому, через какое место написан софт».
Ну вот смотрите. У нас есть python. Python всегда хранит в памяти исходный текст того, что выполняет, но работает с байткодом. Что делать? Все эти десятки мегабайт help(), копии всех объявлений строк, включая локализации т.д. Оно всё отлично улетает в swap, но не может быть выкинуто из кеша (потому что RSS).
Если у вас есть вопросы к софту, и он является индустриальным стандартом, то можно либо быть д'Артаньяном, либо жить с тем, что есть.
Если страница модифицирована, это может быть копия конфига, это может быть данные инициализации сервиса, структур кода, который не используется и т.д.
В видео отлично объяснено откуда появляются неиспользуемые страницы памяти — фрагментация памяти. Многие языки программирования не делают дефрагментации, и даже SLAB не сильно помогает из-за того, что used области перемежаются с unused.
Опять же, вы можете заявить «ваш софт говно», но я могу сказать только одно в ответ: «другого софта у меня для вас нет, жрите что дали».
Насчёт «вопросы к тому, через какое место написан софт».
Ну вот смотрите. У нас есть python. Python всегда хранит в памяти исходный текст того, что выполняет, но работает с байткодом. Что делать? Все эти десятки мегабайт help(), копии всех объявлений строк, включая локализации т.д. Оно всё отлично улетает в swap, но не может быть выкинуто из кеша (потому что RSS).
Если у вас есть вопросы к софту, и он является индустриальным стандартом, то можно либо быть д'Артаньяном, либо жить с тем, что есть.
Если страница модифицирована, это может быть копия конфига, это может быть данные инициализации сервиса, структур кода, который не используется и т.д.
В видео отлично объяснено откуда появляются неиспользуемые страницы памяти — фрагментация памяти. Многие языки программирования не делают дефрагментации, и даже SLAB не сильно помогает из-за того, что used области перемежаются с unused.
Опять же, вы можете заявить «ваш софт говно», но я могу сказать только одно в ответ: «другого софта у меня для вас нет, жрите что дали».
Спасибо за подробный ответ.
Вообще отдельный вопрос зачем Python так делает. Чтобы потом всегда можно было перекомпилировать код? Ну, такое себе. Либо получается, что разрабы языка и интерпретатора не считают, что это проблема (и доп. расходы на эти «лишние» данные не такие большие).
эт точно. Хорошо, когда софт пишут по заказу ) там можно выдвигать требования. А когда уже есть готовая коробка или решение — ну, да, приходится жить с тем, что есть.
Ну вот смотрите. У нас есть python. Python всегда хранит в памяти исходный текст того, что выполняет, но работает с байткодом. Что делать? Все эти десятки мегабайт help(), копии всех объявлений строк, включая локализации т.д. Оно всё отлично улетает в swap, но не может быть выкинуто из кеша (потому что RSS).
Вообще отдельный вопрос зачем Python так делает. Чтобы потом всегда можно было перекомпилировать код? Ну, такое себе. Либо получается, что разрабы языка и интерпретатора не считают, что это проблема (и доп. расходы на эти «лишние» данные не такие большие).
Опять же, вы можете заявить «ваш софт говно», но я могу сказать только одно в ответ: «другого софта у меня для вас нет, жрите что дали».
эт точно. Хорошо, когда софт пишут по заказу ) там можно выдвигать требования. А когда уже есть готовая коробка или решение — ну, да, приходится жить с тем, что есть.
Потому что интроспекция. Можно ругать его в продакшене, но у интроспекции есть значительные плюсы.
… Когда софт пишут по заказу обычно выдвигаемые требования кроются выдвигаемыми инвоисами и вопрос экономии десятка мегабайт на копии процесса автоматически снимается.
. Я только что завернул предложение уменьшить число серверов на локацию (не важно в чём). Аргумент: сервер стоит 100 баксов в месяц, на 4 локации это экономит 400 евро в месяц. Причина, почему завернул? 2 месяца работы команды из трёх человек для поддержки такого режима. Берём 6 зп, делим на 400 евро и видим, что окупаемость за горизонтом планирования.
… Когда софт пишут по заказу обычно выдвигаемые требования кроются выдвигаемыми инвоисами и вопрос экономии десятка мегабайт на копии процесса автоматически снимается.
. Я только что завернул предложение уменьшить число серверов на локацию (не важно в чём). Аргумент: сервер стоит 100 баксов в месяц, на 4 локации это экономит 400 евро в месяц. Причина, почему завернул? 2 месяца работы команды из трёх человек для поддержки такого режима. Берём 6 зп, делим на 400 евро и видим, что окупаемость за горизонтом планирования.
Вы точно знаете, что ваши процесс точно-точно не начнут потреблять памяти больше, чем вы ожидаете? В случае с сефом это крайне критично — если если у вас падает по OOM OSD, это ещё более нагружает остальные узлы. Ну и всё осложняется архитектурой сефа. Фактически, если у вас упала одна OSD по OOM — у вас всё еще всё сравнительно нормально. Но если её перезапуск убивает другую, то пора «напрягаться». Потому что как только вылетит сразу две OSD в разных доменах отказа — всё, у вас проблемы с доступностью данных.
Свап не «продлевает агонию» — он позволяет сохранить доступность данных с деградацией производительности. Большой latency («тормозит») лучше чем полная недоступность данных.
Свап не «продлевает агонию» — он позволяет сохранить доступность данных с деградацией производительности. Большой latency («тормозит») лучше чем полная недоступность данных.
Свап не «продлевает агонию» — он позволяет сохранить доступность данных с деградацией производительности. Большой latency («тормозит») лучше чем полная недоступность данных.
если речь не про Ceph, то все ровно наоборот. Тормозит == недоступность сервиса (условно у пользователя страница открывается 5 минут — мы все равно его потеряли) и приплыли.
К тому же зачастую наличие swap'а маскирует проблему, заметает ее под ковер. Что приводит к ее возникновению уже сильно позже и существенно с более серьезными последствиями (речь не про самые простые случаи, ес-но, типа самого дешевого хостинга, который лишь бы хоть как-то работал).
Грамотным видится подход с ограничением доступного объем для каждого OSD, но действительно есть риск не угадать с точными значениями и создать проблемы на ровном месте.
Не надо путать нормальную работу и аварийную. Своп мешает первой но нужен для второй.
А чтобы проблемы не заметались под ковер — нужен мониторинг.
Варианты как обеспечить работу в аварийном режиме, но без сильного запаса по железу?
(и кроме варианта — сделать swap)
(и кроме варианта — сделать swap)
Без запаса всегда будет тонко.
Дело в том, что аварии-то не было. Было… снижение производительности на время переходных процессов.
Я даже не шучу. Просто в 40 раз меньшая производительность. Но ни одного запроса не потеряно, данные не потеряны. Latency в сотни секунд, очереди в тысячи запросов, но всё хорошо.
Чтобы снижения производительности не было, надо иметь запас по мощности.
Дело в том, что аварии-то не было. Было… снижение производительности на время переходных процессов.
Я даже не шучу. Просто в 40 раз меньшая производительность. Но ни одного запроса не потеряно, данные не потеряны. Latency в сотни секунд, очереди в тысячи запросов, но всё хорошо.
Чтобы снижения производительности не было, надо иметь запас по мощности.
Если у вас стойка «легла по питанию» это значит в ней нет ИБП? Вам не кажется, что нужно начинать планирование кластера именно с этой части?
Допускаю, что возможен отказ любого другого плана. Помимо "легла по питанию". Ну, свитчи сдохли. Или человеческий фактор — что-то кривой настроили или обновили. Короче — отказы случаются и лучше к ним быть готовыми заранее
Не имеет значения причина отказа. Приедет экскаватор и перекопает коммуникации, откажет коммутатор, сетевики совершат непреднамеренный теракт в процессе настройки своего оборудования, ядро свалится в kernel panic. Как «все реки текут вниз», так и все отказы приводят к одному и тому же финалу: offline OSD => start OSD => PG peering => Recovery.
Фирмваря умной розетки решила, что потребности в электричестве больше нет. Или блоки питания не подружились друг с другом.
Встречал несколько раз ситуации, когда по питанию вылетали целые машзалы — потому что ломался централизованный ИБП.
По мне все эти центральные ИБП — большое зло, ибо есть пословица «чем больше шкаф, тем громче и больнее он падает». В идеале по 3КВ ИБП на сервак или по 2КВ на каждый блок питания сервака гораздо надежнее. 3КВ-ники стОят недорого, по сравнению с последствиями от падения центрального. На крайний случай отдельный ИБП на стойку. Одна линия от него, вторая от центрального ИБП.
Таки без SWAP-a совсем не здорово. Можно настроить swapeness таким образом, что свап будет использоваться только в том случае когда с RAM совсем беда, здесь есть хоть какая-то вероятность, что нода не ляжет.
К сожалению swapinness не панацея. У меня есть сервер на котором 80% памяти это пейдж кеш т.е. свободно но ядро даже при нуле сваппинесс свапит еще как.
Как вариант демонтировать swap из системы совсем. За возможность это осуществить, а также за последствия ручаться не могу.
На большинстве серверов у меня он и так отключен — так безопаснее. Особенно в кластерной среде, когда тупящая нода хуже дохлой.
Этот же — личный сервер, на котором в некоторых случаях (очень редких) возможен всплеск потребления памяти, поэтому пока не отключаю.
Меня просто удивляет невозможность заставить систему не свапить при наличии большого объема page cache и\или свободной памяти. По идее ручка vm.swappiness как раз призвана регулировать это поведение, но судя по всему она носит рекомендательный характер :)
Этот же — личный сервер, на котором в некоторых случаях (очень редких) возможен всплеск потребления памяти, поэтому пока не отключаю.
Меня просто удивляет невозможность заставить систему не свапить при наличии большого объема page cache и\или свободной памяти. По идее ручка vm.swappiness как раз призвана регулировать это поведение, но судя по всему она носит рекомендательный характер :)
С «крутилкой» swappiness согласен с вами. Её метрики вообще не прослеживаются. Недавно настраивал 1С+PostreSQL+CentOS на весьма дряблой виртуалке. Так вот при создании чистой БД установщик жаловался на нехватку RAM и «затыкался». В swappiness, были «попробованы» цифры 50,60,80,90....98,99 — не помогало пока не поставил 100, т.е. предельное значение, когда система свапит всё, что можно. И только тогда, скрежеча винчестером, установка завершилась. Поэтому, образно весь swapiness можно привести только к двум состояниям — вкл и выкл, без каких либо промежуточных.
Вот тут интересный анализ поведения этой ручки и как оно изменилось после 3.15 ядра: eklitzke.org/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 14G1.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
На прошлой работе у моего начальника от этого тоже пукан рвало. Как так, почему памяти много (в buff/cache гигов 12 из 16), а лезем в своп? Проблема была в том что некоторые запросы выполнялись медленно, нужное приложение в своп вытесняло.
Да, этот момент хорошо бы лине переработать, но у меня квалификации недостаточно. А опытным видимо и так хорошо.
Да, этот момент хорошо бы лине переработать, но у меня квалификации недостаточно. А опытным видимо и так хорошо.
У меня есть пример еще хуже
# 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
sync; echo 3 > /proc/sys/vm/drop_caches
чуть подробнее например тут
www.tecmint.com/clear-ram-memory-cache-buffer-and-swap-space-on-linux
Причем тут сброс page cache?
Я не хочу его сбрасывать, он хороший и полезный. Если очистить — ядру опять придется его наполнять и насиловать винт.
Я же только выталкиваю страницы из свапа обратно в память.
Я не хочу его сбрасывать, он хороший и полезный. Если очистить — ядру опять придется его наполнять и насиловать винт.
Я же только выталкиваю страницы из свапа обратно в память.
Своп почти сразу опять начнёт заполняться. Подобный скрипт тоже был, «если занято больше гига свопа то сбросить буферы и вычистить своп».
Можно делать не 3 а 1 или 2, тогда только часть кэша будет очищена. А поскольку большой нагрузки на диски там не было, сбрасывали дисковый кэш, он быстро и достаточно безболезненно заполнялся опять, данными для актуальных запросов.
Можно делать не 3 а 1 или 2, тогда только часть кэша будет очищена. А поскольку большой нагрузки на диски там не было, сбрасывали дисковый кэш, он быстро и достаточно безболезненно заполнялся опять, данными для актуальных запросов.
5 лет прошло, а ceph все так же не хватает памяти. Что можно сделать людям, у которых есть много серверов с большими дисками, но нет памяти. Как пример комментарий
Ну кроме варианта продать все и забыть.
Ну кроме варианта продать все и забыть.
Что можно сделать людям, у которых есть много серверов с большими дисками, но нет памяти.
Собрать RAID60 из дисков со всех серверов, подключенных по iSCSI :)
Да, будет SPOF, но можно довольно быстро собрать тот же RAID на другом сервере кластера при гибели первого.
Консистентность данных? Split brain? «Не, не слышали» (сказало левое полушарие), «не, не слышали, но я обновлю запись» (сказало правое полушарие).
Вообще это шутка была — такое вываливать в прод мне бы в голову не пришло :)
Но консистентность там ровно такая же как в рейде с локальными дисками. Если нет буфферизации записи на сетевом (ISCSI/FCoE/NBD) уровне — тут уже зависит от настроек таргета.
Еще можно сделать DRBD9 — он умеет >2 реплик, собрать какую-нибудь хитрую конфигурацию.
Но консистентность там ровно такая же как в рейде с локальными дисками. Если нет буфферизации записи на сетевом (ISCSI/FCoE/NBD) уровне — тут уже зависит от настроек таргета.
Еще можно сделать DRBD9 — он умеет >2 реплик, собрать какую-нибудь хитрую конфигурацию.
Можно диски собрать в lvm и засунуть в pacemaker, тогда spof вообще не будет.
Можно подробнее, пожалуйста?
Как pacemaker помогает LVM?
Как pacemaker помогает LVM?
SPOF будет в любом случае, просто с пейсмейкером после помирания SPOF он его мигрирует на живую ноду. Но пока это будет происходить — массив будет недоступен.
SPOF будет в любом случаеРазумеется нет. Active-Passive резервирование — это тоже fault-tolerant решение.
Но пока это будет происходить — массив будет недоступен.С учётом того, что драйвер дисковой системы обычно ждёт ответа 30-60 секунд до того, как поднимет ошибку в приложение — переключение может быть произведено вполне прозрачно для клиентов.
Зависит от терминологии и скорости переключения. На мой взгляд, если клиенты не замечают отказа — то SPOF нет.
В данном же случае непонятны условия эксплуатации и миграции, и в каких случаях будут проблемы у клиентов.
В данном же случае непонятны условия эксплуатации и миграции, и в каких случаях будут проблемы у клиентов.
Чтобы не было разногласий в терминологии — предлагаю пользоваться общеупотребимой. А в ней вообще никакого упоминания скорости переключения нет)
Слушайте, отличный доклад. Читается как детектив. И вот вопрос от человека который с Ceph не работает. При таких проблемах в случае выхода из строя (отключения) части OSD, как это хозяйство вообще штатно-то выключается? весь кластер.
Вот ситуация — приходит грустный электрик и говорит, ребята завтра город будет кабель менять вводный, извините на полдня выключает нас. А дизеля у нас нет, и мы готовимся просто потушиться на это время. Как это штатно сделать — и главное как после этого взлететь чтобы и данные не деградировали и волосы на теле не поседели…
Вот ситуация — приходит грустный электрик и говорит, ребята завтра город будет кабель менять вводный, извините на полдня выключает нас. А дизеля у нас нет, и мы готовимся просто потушиться на это время. Как это штатно сделать — и главное как после этого взлететь чтобы и данные не деградировали и волосы на теле не поседели…
Отличный вопрос! Меня тоже очень интересует штатная работа такой балалайки. Или предполагается что все живут в отказоустойчивых ЦОДах? А как насчет того, что даже яндекс отключает в рамках учений один из нескольких своих ЦОДов?
Отключаешь всех клиентов от кластера и следуешь ceph.com/planet/how-to-do-a-ceph-cluster-maintenance-shutdown
бедные клиенты. А прозрачно-то никак не сделать?
Ну вводная у оратора выше — отключение всего ДЦ, поэтому тут на клиентов Ceph, я думаю, плевать. Если же нужно выключить, допустим, одну стойку, то можно просто повыкидывать OSD из кластера docs.ceph.com/docs/master/rados/operations/add-or-rm-osds и дождаться окончания ребалансировки. Затем добавить обратно.
Я думаю это будет безболезненнее чем просто отключать OSD и держать кластер в деградированном состоянии.
Я думаю это будет безболезненнее чем просто отключать OSD и держать кластер в деградированном состоянии.
выставляем на кластере флаги noout (обязательно)
делаем shutdown / suspend клиентов (нет клиентов — нет нагрузки — нет дегрейдов — не будет рекавера)
опционально — делаем osd nodown
шатдауним сеф
обратное включение:
включаем оборудование
дожидаемся что все osd запустились
снимаем noout (и nodown если он стоял)
запускаем клиентов
делаем shutdown / suspend клиентов (нет клиентов — нет нагрузки — нет дегрейдов — не будет рекавера)
опционально — делаем osd nodown
шатдауним сеф
обратное включение:
включаем оборудование
дожидаемся что все osd запустились
снимаем noout (и nodown если он стоял)
запускаем клиентов
ceph osd set noout чтобы предотвратить перебалансировку в ходе поочередного shutdown узлов, после удачного старта ceph osd unset noout.
Супердоклад. Что делать понятно, но рассказ о том, что происходило — бесценно.
Где можно подробней почитать о CEPH.При попытке что то настроить возникает куча вопросов на которые нет ответа.
К примеру сколько нод нужно для организации ceph? Возможно ли чтоб ноды были с разными дисками? На proxmox стоит ли его поднимать? Нужен ли raid при настройке ceph?
Буду благодарен за помощь, начальство дало задачу слепить из хранилищ ceph, а как это организовать мало информации.Спасибо.
К примеру сколько нод нужно для организации ceph? Возможно ли чтоб ноды были с разными дисками? На proxmox стоит ли его поднимать? Нужен ли raid при настройке ceph?
Буду благодарен за помощь, начальство дало задачу слепить из хранилищ ceph, а как это организовать мало информации.Спасибо.
В официальной документации же есть ответы.
pve.proxmox.com/pve-docs/chapter-pveceph.html
Если у вас уже стоит проксмокс, то лучше поднимать на нем, в нем уже есть удобный мониторинг и управление. Убедитесь только, что оперативной памяти хватит всем виртуалкам и хранилищу, и что у вас есть отдельная сеть для обмена данных.
Минимум три ноды, что для самого проксмокса, что для хранилища.
Диски можно разные, но желательно, чтобы не было перекоса по суммарному объему на нодах.
Для дисков хранилища рейд не нужен.
pve.proxmox.com/pve-docs/chapter-pveceph.html
Если у вас уже стоит проксмокс, то лучше поднимать на нем, в нем уже есть удобный мониторинг и управление. Убедитесь только, что оперативной памяти хватит всем виртуалкам и хранилищу, и что у вас есть отдельная сеть для обмена данных.
Минимум три ноды, что для самого проксмокса, что для хранилища.
Диски можно разные, но желательно, чтобы не было перекоса по суммарному объему на нодах.
Для дисков хранилища рейд не нужен.
Делали мы миникластер из трёх нод на проксмоксе. Кое как запустили, вроде работает, через какое-то время одна года вылетела по железу — вроде работает, порадовались, починили железо, включили и прилегло всё намертво на восстановлении :(
0. где спросить живых людей — телеграм-канал @ceph_ru;
1. чем больше нод, тем лучше. 4-5 минимум ИМХО, лучше СИЛЬНО больше;
2. ноды с разными дисками да, конечно;
3. стоит ли — поднимите тестовый стенд и проверьте сами;
4. raid категорически не рекомендуется
1. чем больше нод, тем лучше. 4-5 минимум ИМХО, лучше СИЛЬНО больше;
2. ноды с разными дисками да, конечно;
3. стоит ли — поднимите тестовый стенд и проверьте сами;
4. raid категорически не рекомендуется
А что за легенда о Cloudmouse? Она гласит о том, что не нужно включать опции yesIwantEnableThisDangerousFeature=1?
1) habr.com/post/250097
2) habr.com/post/252221
2 факапа с интервалом в месяц. Причина похоже в использовании ceph…
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 и спокойно менять комплектующие, ставить прошивки.
И, судя по всему, были и другие стойки.
Что мешало через карты настроить одну копию osd на одну стойку + ceph.conf min 2 norm 3 копии?
Это дало бы вам возможность полностью обслуживать одну любую стойку без прерывания доступа к данным на запись со стороны клиентов. Так же это ускоряет запись, после 2 копий отпуская сессию, 3-я фоном создается.
У нас всего 3 хоста, как раз разнесены в разные стойки, с распределением в картах записью 1 копии osd на 1 хост. Для обслуживания хоста достаточно включить noout nodown и спокойно менять комплектующие, ставить прошивки.
Еще попадался вариант кодирования, когда пул создается с доп контрольными суммами, что на хосте есть и блок данных, и блок четности. В результате при восстановлении задействуется локальный диск с хранимой четностью, уменьшая нагрузку на сеть.
Но не уверен насколько такой пул приемлем для rbd.
Но не уверен насколько такой пул приемлем для rbd.
У вас неверное (очень) представление о работе ceph.
Начиная со слов «после 2 копий отпуская сессию».
И стенд с которого снимались графики как раз и был настроен под 3/2, и
Начиная со слов «после 2 копий отпуская сессию».
И стенд с которого снимались графики как раз и был настроен под 3/2, и
Где бы я не упомянал о ceph, мне сразу давали ссылку на эту «Анатомию катастрофы». А так ли это? Что вижу здесь я. Это исключительно хайпанутая статья, где рекламируется их собственный патч, без которого ceph по их заверениям «нежизнеспособное говно». А получите вы этот патч только когда станете их клиентом. Давайте все же попытаемся разобраться что происходило.
1. Я не буду давать ссылку на цитату, на сайт разработчиков если кому надо найдете сами, где говорилось примерно следующее: «Не используйте под ceph несколько мощных машин, используйте много маленьких.» Они же взяли три мощные тачки и запихнули по 10ssd в каждую. Далее на оф. сайте не раз говорится что ceph очень требователен к сети! Они же это все обвязали 10Гбитной сетью. Одна нормальная ssd-ха способна при копировании утилизировать 10Гбитную сеть. Теперь взглянем на картину вцелом. На каждой машине по 10 демонов OSD пытаются реплейсить и актуализировать данные, при этом еще идет жесткая клиентская нагрузка. Конечно при таком раскладе сеть будет утилизирована полностью, будут расти кэши записи и врезультате все это встанет в интересную позицию. А на какой исход еще можно было расчитывать при такой конфигурации. Наивно было полагать что все 10 ssd дисков синхронизируются под клиентским хайлоадом при 10Гбитной сети. И конечно чуда не произошло.
2. Тестирование. Вот здесь комментарии излишни, мало того что они не умеют считать дважды два. Так они ввели в эксплуатацию hiload систему которая не тестировалась на hiload. А на какой исход эти господа расчитывали вообще?! Нужно было тестировать, выяснить его физические пределы, а продакшене использовать не более 50%. Вот тогда не будет ни каких «Анатомий катостроф».
1. Я не буду давать ссылку на цитату, на сайт разработчиков если кому надо найдете сами, где говорилось примерно следующее: «Не используйте под ceph несколько мощных машин, используйте много маленьких.» Они же взяли три мощные тачки и запихнули по 10ssd в каждую. Далее на оф. сайте не раз говорится что ceph очень требователен к сети! Они же это все обвязали 10Гбитной сетью. Одна нормальная ssd-ха способна при копировании утилизировать 10Гбитную сеть. Теперь взглянем на картину вцелом. На каждой машине по 10 демонов OSD пытаются реплейсить и актуализировать данные, при этом еще идет жесткая клиентская нагрузка. Конечно при таком раскладе сеть будет утилизирована полностью, будут расти кэши записи и врезультате все это встанет в интересную позицию. А на какой исход еще можно было расчитывать при такой конфигурации. Наивно было полагать что все 10 ssd дисков синхронизируются под клиентским хайлоадом при 10Гбитной сети. И конечно чуда не произошло.
2. Тестирование. Вот здесь комментарии излишни, мало того что они не умеют считать дважды два. Так они ввели в эксплуатацию hiload систему которая не тестировалась на hiload. А на какой исход эти господа расчитывали вообще?! Нужно было тестировать, выяснить его физические пределы, а продакшене использовать не более 50%. Вот тогда не будет ни каких «Анатомий катостроф».
Мы с вами точно одну и ту же статью читали?
где рекламируется их собственный патч, без которого ceph по их заверениям «нежизнеспособное говно». А получите вы этот патч только когда станете их клиентом.
Не вижу призыва покупать патч. Напротив, вижу обещание предоставить этот патч сообществу после доработки (уж не знаю произошло ли это за 2 года, пишу про то что прочитал).
Наивно было полагать что все 10 ssd дисков синхронизируются под клиентским хайлоадом при 10Гбитной сети. И конечно чуда не произошло.
Вы так пишете, как будто проблема была в пропускной способности сети, а не в доступной оперативной памяти.
Если вы про патч, то см видео 41:38
Не вижу призыва покупать патч. Напротив, вижу обещание предоставить этот патч сообществу после доработки (уж не знаю произошло ли это за 2 года, пишу про то что прочитал).
На видео 41:38 человек явно спрашивает где можно посмотреть патч, где он его вежливо посылает на хрен и говорит что получите, цитирую: «Когда приобретете наш програмно-аппартный комплекс».
Вы так пишете, как будто проблема была в пропускной способности сети, а не в доступной оперативной памяти.
И да, по моему мнению здесь была проблема именно в сети. Оперативы нехватало, потому что данные не могли записаться и росли кэши.
будут расти кэши записи и врезультате все это встанет в интересную позицию
Кэш тут ни причем. Проблема деградации производительности происходит только от архитектуры и реализации Ceph, который рекаверит объект полным копированием перед записью с целью обеспечить надежность. К проблеме роста потребления памяти это не имеет никакого отношения, потому что объем данных, размещенных в очереди на запись, на один-три порядка меньше чем объем данных репликации.
В классическом кейсе RBD, когда у вас например 1000 образов (== 1000 клиентов) у каждого из которых очередь в 128 запросов, при записи по 64KB в одну операцию у вас требуемый на «кэши» объем памяти будет порядка 8GB на весь кластер.
Проблема потребления памяти имеет свои корни в большом объеме данных, которые OSD удерживает в памяти во время начального согласования статуса PG (пиринга), в объеме хранимых PG log и в том, как OSD принимает решение о транкейте этих логов. OSD в режиме рекавера выедает память даже в отсутствие нагрузки — еще в процессе пиринга. И это особенно активно проявляется в erasure code большой размерности (например 6+2, 8+3 и т.д.) при большом количестве PG — либо у нас не потранкейчены логи и мы быстро собираем дегрейднутые объекты, либо логи потранкейчены, и тогда нам надо собрать собрать информацию о версиях всех объектов. Либо перезаливать PG полностью.
Ну то есть вы настаиваете, что конфигурация была подобрана оптимально. Три машины по 10ssd в каждой, обвязаны 10Г сетью? Так надо делать?
Это ж просто способ воспроизвести проблему в лабораторных условиях. Исходно-то на эти грабли DigitalOcean наступили (и, возможно, не только они).
Ммм, как интересно.
Насколько я понимаю, у вас есть правильная конфигурация, которая позволит потерять в производительности не более 50% при отказе 30 процентов оборудования? Я думаю, сообществу было бы интересно её увидеть. И её стоимостную оценку, в долларах за гигабайт. Включая сетевое оборудование. В расчете, ну, например, на 300TB полезного пространства. А то знаете ли, с эльфийскими фантазиями о бюджете можно много насочинять, а так чуть ближе к земле будет.
Что же до сетапа стенда — конфигурация стенда вполне себе разумная. OSD обслуживает порядка 45 IOPS в секунду (исходя из service time 22ms, мы же говорим о рекаверных операциях блоком 4MB), сеть десятка, одна нода протянет 400… 450 IOPS по дискам и примерно 300 IOPS по сети. Чуть получше сеть хотелось бы конечно (2x10 вполне бы хватило) — но в целом да, нормальный сетап для компонентов 2016-2017 года.
Насколько я понимаю, у вас есть правильная конфигурация, которая позволит потерять в производительности не более 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% кторый можно получить улучшив сеть не способен закрыть потери от рекавера.
Но почему то вас очень задевает, когда я вам говорю то же самое.
Меня раздражают эльфы-архитекторы предлагающие заливать железом архитектурные проблемы. Зависимость между стоимостью и производительностью логарифмическая.
Во первых я не сказал что цеф не имеет проблем. Ровно так же как я и не говорил, что «Знаю как надо». Это почему то вы за меня сказали. И где я предложил заливать архитектурные проблемы железом? Не передергивайте, я сказал что ваша конфигурация идет вразрез с рекомендациями. А у вас единственный аргумент «А ты знаешь сколько это будет стоить». Мы обсуждали архитектуру, а не стоимость. Я сразу сказал что эта не тема обсуждения. Давайте тогда тогда на двух тачках соберем 50 ссдэх воткнем, кворум отключим, а когда все медным тазом накроется напишем статью анатомия апакалипсеца ))) Дальше не вижу смысла продолжать дискуссию, полезной нагрузки она не несет.
Специально для вас повторю — лабораторный сетап с учетом использовавшихся в нем дисков являлся достаточно сбалансированным и не имел откровенных проблем, а соотношение производительности дисков и сети вполне соответствовало рекомендуемой конфигурации.
В общем так же не вижу смысла продолжать. Собираете лабу — снимаете цифры со 100% дегрейдом домена под нагрузкой в течение нескольких минут, снимаете цифры, пишете статью, её и обсуждаем.
пишете статью
Очень может быть. Как раз в планах скоро тестирование сборки стоит. Забегая вперед, скажу что сегодня с утра провел небольшое тестирование на 3 ссд, в каждой машине, в пиках загрузка по сети была около 9Гбит. Бонд работал с загрузкой обоих линков. Тестирование производилось без даунгрейда.
Sign up to leave a comment.
Ceph. Анатомия катастрофы