Снапшоты qcow2 средствами qemu-kvm и последующее их копирование, что позволяет производить резервное копирование более гранулярно и с меньшими затратами ресурсов
Свап позволяет системе эффективней использовать кэш. В условиях отстутсвия memory pressure вы этого можете не заметить. Но когда оно появляется, наличие swap позволяет системе оперировать эффективней. И в статье я объясняю почему это происходит.
Кубик пытается изобразить из себя «распределенную платформу» и сам занимается менеджментом ресурсов, выставляет ограничения и прочими способами обещает поддерживать йоды в неперегруженном состоянии. Ну вот такой у них полиси «вы должны предоставить столько ресурсов чтобы хватило» написанный исходя из политики «проще добавить железа чем оптимизировать»
Свап это для ситуации «работаем на тех ресурсах которые есть».
Точно-точно? Потому что бакфил это тотальный залив всех объектов PG в новую реплику, а recover — переливка только дегрейднутых объектов, что существенно легче. backfill это «массовый рекавер» но не наоборот.
Деквалификация. Тех кто мог сделать код что в любую щель пролезет давно понанимали большие компании, а нынешний молодняк в большинстве своем… Не слишком хорошо знаком с основами, скажем так. 90% даже про syn/ack не слышали, а уж воспользоваться каким-нибудь HTTP CONNECT через прокси для сканирования удаленной сети для них как магия.
Там все средства распилены и занесены куда надо кому над ов нужных пропорциях, поэтому на выполнение работ денег нет. Поинтересуйтесь сколько там получает какой-нибудь «ведущий специалист» и потом попробуйте представить, пойдет ли на такую оплату спец достаточно высокой квалификации?
Что как бы закономерно. Трансляция команд x64 -> ARM это конечно замечательно и М1 процессор замечательный — но если софт активно использует векторные инструкции и собран нормальным компилятором, то «внезапно» оказывается, что похороненный интел вылезает из земли и съедает всех танцующих на его могиле, после чего прячется и ждет следующих танцующих.
И поскольку в 2017 году clang и LLVM сливали GCC и ICC по производительности сгенерированного кода почти двукратно, я бы не исключал, что эппл подтянули свой компилятор чтобы он под ARM начал генерировать вменяемый код, и теперь сранивают нормально собраный армовский бинарник со сгенерированным их же компилятором унылым кодом x86.
В общем так же не вижу смысла продолжать. Собираете лабу — снимаете цифры со 100% дегрейдом домена под нагрузкой в течение нескольких минут, снимаете цифры, пишете статью, её и обсуждаем.
Специально для вас повторю — лабораторный сетап с учетом использовавшихся в нем дисков являлся достаточно сбалансированным и не имел откровенных проблем, а соотношение производительности дисков и сети вполне соответствовало рекомендуемой конфигурации.
И как то непонятно получается то вы говорите «2x10 вполне бы хватило», то говорите «Вот только это не помогает.»
Тривиально. «Вполне бы хватило» для того чтобы полность с гарантией возможности OSD по рекаверу. Не помогает — потом что выигрыш в 15-20% кторый можно получить улучшив сеть не способен закрыть потери от рекавера.
Но почему то вас очень задевает, когда я вам говорю то же самое.
Меня раздражают эльфы-архитекторы предлагающие заливать железом архитектурные проблемы. Зависимость между стоимостью и производительностью логарифмическая.
это вообще ни какого отношение к обсуждению не имеет
Ну почему же? Если Вы с таким апломбом декларируете о том, что у всех неправильный сетап — то наверняка Вы знаете правильный. Сообщество ждет. Сефовский чат в будет рад услышать предложения эксперта.
вот наконец то вы озвучили это. Агрегация и бондинги появились за долго до 2016-2017 года
Разумеется. Я вам по секрету скажу — в продуктиве мы это использовали. И не только мы — в общем то практически все, у кого сеф в продуткиве, к этим ухищрениям прибегают.
Вот только это не помогает. Не выходит разницу в порядок замаскировать двукратным увеличением полосы. И я вам еще более страшную тайну открою — даже 2x40G вам не поможет. Потому, что Ceph надо вместо записи 4KB прочесть 4MB, записать 4MB, обновить пачку метаданных (причем зачастую еще и в синхронном режиме, то есть в один поток) — и только потом собственно приступать к записи 4KB. И опять же — те, кто использует сеф в продуктиве это тоже знают.
И именно поэтому в майнстриме ведутся работы по оптимизации рекавера, чтобы не реплицировать объект полностью. Потому, что разработчики понимают, что алгоритмическую проблему просто «закидать железом» нельзя.
Насколько я понимаю, у вас есть правильная конфигурация, которая позволит потерять в производительности не более 50% при отказе 30 процентов оборудования? Я думаю, сообществу было бы интересно её увидеть. И её стоимостную оценку, в долларах за гигабайт. Включая сетевое оборудование. В расчете, ну, например, на 300TB полезного пространства. А то знаете ли, с эльфийскими фантазиями о бюджете можно много насочинять, а так чуть ближе к земле будет.
Что же до сетапа стенда — конфигурация стенда вполне себе разумная. OSD обслуживает порядка 45 IOPS в секунду (исходя из service time 22ms, мы же говорим о рекаверных операциях блоком 4MB), сеть десятка, одна нода протянет 400… 450 IOPS по дискам и примерно 300 IOPS по сети. Чуть получше сеть хотелось бы конечно (2x10 вполне бы хватило) — но в целом да, нормальный сетап для компонентов 2016-2017 года.
будут расти кэши записи и врезультате все это встанет в интересную позицию
Кэш тут ни причем. Проблема деградации производительности происходит только от архитектуры и реализации Ceph, который рекаверит объект полным копированием перед записью с целью обеспечить надежность. К проблеме роста потребления памяти это не имеет никакого отношения, потому что объем данных, размещенных в очереди на запись, на один-три порядка меньше чем объем данных репликации.
В классическом кейсе RBD, когда у вас например 1000 образов (== 1000 клиентов) у каждого из которых очередь в 128 запросов, при записи по 64KB в одну операцию у вас требуемый на «кэши» объем памяти будет порядка 8GB на весь кластер.
Проблема потребления памяти имеет свои корни в большом объеме данных, которые OSD удерживает в памяти во время начального согласования статуса PG (пиринга), в объеме хранимых PG log и в том, как OSD принимает решение о транкейте этих логов. OSD в режиме рекавера выедает память даже в отсутствие нагрузки — еще в процессе пиринга. И это особенно активно проявляется в erasure code большой размерности (например 6+2, 8+3 и т.д.) при большом количестве PG — либо у нас не потранкейчены логи и мы быстро собираем дегрейднутые объекты, либо логи потранкейчены, и тогда нам надо собрать собрать информацию о версиях всех объектов. Либо перезаливать PG полностью.
30 человек на это недоразумение под названием «социальный мониторинг»? Вот реально, любая адекватная команда из 5 человек сделает его за месяц. И качественнее. Причем один человек будет ПМ.
Для сефа бессмысленно иметь четное количество мониторов, скажем так. Единственный смысл этого это очередной Росреестр или клаудмаус когда один монитор умер, два пролюбили — и вот тогда… Но это уж надо очень-очень поврежденную карму иметь.
Свап это для ситуации «работаем на тех ресурсах которые есть».
Точно-точно? Потому что бакфил это тотальный залив всех объектов PG в новую реплику, а recover — переливка только дегрейднутых объектов, что существенно легче. backfill это «массовый рекавер» но не наоборот.
И поскольку в 2017 году clang и LLVM сливали GCC и ICC по производительности сгенерированного кода почти двукратно, я бы не исключал, что эппл подтянули свой компилятор чтобы он под ARM начал генерировать вменяемый код, и теперь сранивают нормально собраный армовский бинарник со сгенерированным их же компилятором унылым кодом x86.
Тривиально. «Вполне бы хватило» для того чтобы полность с гарантией возможности OSD по рекаверу. Не помогает — потом что выигрыш в 15-20% кторый можно получить улучшив сеть не способен закрыть потери от рекавера.
Меня раздражают эльфы-архитекторы предлагающие заливать железом архитектурные проблемы. Зависимость между стоимостью и производительностью логарифмическая.
Ну почему же? Если Вы с таким апломбом декларируете о том, что у всех неправильный сетап — то наверняка Вы знаете правильный. Сообщество ждет. Сефовский чат в будет рад услышать предложения эксперта.
Разумеется. Я вам по секрету скажу — в продуктиве мы это использовали. И не только мы — в общем то практически все, у кого сеф в продуткиве, к этим ухищрениям прибегают.
Вот только это не помогает. Не выходит разницу в порядок замаскировать двукратным увеличением полосы. И я вам еще более страшную тайну открою — даже 2x40G вам не поможет. Потому, что Ceph надо вместо записи 4KB прочесть 4MB, записать 4MB, обновить пачку метаданных (причем зачастую еще и в синхронном режиме, то есть в один поток) — и только потом собственно приступать к записи 4KB. И опять же — те, кто использует сеф в продуктиве это тоже знают.
И именно поэтому в майнстриме ведутся работы по оптимизации рекавера, чтобы не реплицировать объект полностью. Потому, что разработчики понимают, что алгоритмическую проблему просто «закидать железом» нельзя.
Насколько я понимаю, у вас есть правильная конфигурация, которая позволит потерять в производительности не более 50% при отказе 30 процентов оборудования? Я думаю, сообществу было бы интересно её увидеть. И её стоимостную оценку, в долларах за гигабайт. Включая сетевое оборудование. В расчете, ну, например, на 300TB полезного пространства. А то знаете ли, с эльфийскими фантазиями о бюджете можно много насочинять, а так чуть ближе к земле будет.
Что же до сетапа стенда — конфигурация стенда вполне себе разумная. OSD обслуживает порядка 45 IOPS в секунду (исходя из service time 22ms, мы же говорим о рекаверных операциях блоком 4MB), сеть десятка, одна нода протянет 400… 450 IOPS по дискам и примерно 300 IOPS по сети. Чуть получше сеть хотелось бы конечно (2x10 вполне бы хватило) — но в целом да, нормальный сетап для компонентов 2016-2017 года.
Кэш тут ни причем. Проблема деградации производительности происходит только от архитектуры и реализации Ceph, который рекаверит объект полным копированием перед записью с целью обеспечить надежность. К проблеме роста потребления памяти это не имеет никакого отношения, потому что объем данных, размещенных в очереди на запись, на один-три порядка меньше чем объем данных репликации.
В классическом кейсе RBD, когда у вас например 1000 образов (== 1000 клиентов) у каждого из которых очередь в 128 запросов, при записи по 64KB в одну операцию у вас требуемый на «кэши» объем памяти будет порядка 8GB на весь кластер.
Проблема потребления памяти имеет свои корни в большом объеме данных, которые OSD удерживает в памяти во время начального согласования статуса PG (пиринга), в объеме хранимых PG log и в том, как OSD принимает решение о транкейте этих логов. OSD в режиме рекавера выедает память даже в отсутствие нагрузки — еще в процессе пиринга. И это особенно активно проявляется в erasure code большой размерности (например 6+2, 8+3 и т.д.) при большом количестве PG — либо у нас не потранкейчены логи и мы быстро собираем дегрейднутые объекты, либо логи потранкейчены, и тогда нам надо собрать собрать информацию о версиях всех объектов. Либо перезаливать PG полностью.