А если нет - EOL

Every other stable releases is a LTS (Long Term Stable) and will receive updates until two LTS are published. For instance Dumpling is retired when Hammer is published, Firefly is retired when Jewel is published etc.

http://docs.ceph.com/docs/master/releases/

May 2017

С мая EOL

ключевое слово: Estimated

Ок, жди.

я то жду, я постоянно мониторю исходники и трекер

:)

Коллеги, есть ли какой-то функционал, который автоматически меняет crushmap? У меня через 2-3 часа после задания crushmap она самопроизвольно изменяется

параметр нужно выставить: osd crush update on start = false

Коллеги, есть ли какой-то функционал, который автоматически меняет crushmap? У меня через 2-3 часа после задания crushmap она самопроизвольно изменяется

А что именно изменяется?

Item прыгает между хостами

параметр нужно выставить: osd crush update on start = false

Спасибо!

Спасибо!

Пожалуйста :)

👍👍👍

Item прыгает между хостами

Я бы на вашем месте поковырял, почему он прыгает :)

Я бы на вашем месте поковырял, почему он прыгает :)

Руки косые у меня. Я хочу ssd с хоста посадить в один ruleset, hdd - в другой. При прыге все садится в один ruleset, как было

Руки косые у меня. Я хочу ssd с хоста посадить в один ruleset, hdd - в другой. При прыге все садится в один ruleset, как было

Правила отдельно, а иерархия контейнеров отдельно. Это имеется ввиду, а не правила?

Правила то тут и непричем как таковые.

Правила то тут и непричем как таковые.

Item скачет между контейнерами, да

На разных контейнерах разные правила, да

Item скачет между контейнерами, да

Какой item то? OSD?

Какой item то? OSD?

да

При старте osd, по умолчанию, crushmap обновляется с учётом host.

Парни, привет всем. Столкнулся с проблемой одной. Не знаю, глупая она или нет но гугл молчит упорно. Есть rgw. Добавил юзверя, все по инструкции( конфигурируется S3) Тестирую через питоновсикй скрипт из документации который начинается с "import boto.s3.connection" В конечном итоге получаю 403 ("<?xml version="1.0" encoding="UTF-8"?><Error><Code>InvalidAccessKeyId</Code><RequestId>tx000000000000000000053-00596cee9b-196d4-default</RequestId><HostId>196d4-default-default</HostId></Error> ") В дебагах нашел вот такое: 2017-07-17 20:06:35.041904 7fbfacfb9700 2 req 83:0.000116:s3:GET /:list_buckets:authorizing 2017-07-17 20:06:35.041936 7fbfacfb9700 20 get_system_obj_state: rctx=0x7fbfacfb21e0 obj=default.rgw.users.keys:I580C6LRM9905GZ2QFIG state=0x7fc01000c908 s->prefetch_data=0 2017-07-17 20:06:35.041951 7fbfacfb9700 10 cache get: name=default.rgw.users.keys+I580C6LRM9905GZ2QFIG : hit (requested=6, cached=7) 2017-07-17 20:06:35.041965 7fbfacfb9700 20 get_system_obj_state: s->obj_tag was set empty 2017-07-17 20:06:35.041969 7fbfacfb9700 10 cache get: name=default.rgw.users.keys+I580C6LRM9905GZ2QFIG : hit (requested=1, cached=7) 2017-07-17 20:06:35.041991 7fbfacfb9700 20 get_system_obj_state: rctx=0x7fbfacfb1ea0 obj=default.rgw.users.uid:vkom state=0x7fc01000e538 s->prefetch_data=0 2017-07-17 20:06:35.041995 7fbfacfb9700 10 cache get: name=default.rgw.users.uid+vkom : miss 2017-07-17 20:06:35.042094 7fbfacfb9700 1 -- 172.27.15.86:0/958352733 --> 172.27.15.86:6812/17090 -- osd_op(client.104148.0:10318 26.94f8c756 vkom [call version.read,getxattrs,stat] snapc 0=[] ack+read+known_if_redirected e235) v7 -- ?+0 0x7fc010010960 con 0x7fc0e00222a0 2017-07-17 20:06:35.042998 7fc0da6fb700 1 -- 172.27.15.86:0/958352733 <== osd.3 172.27.15.86:6812/17090 177 ==== osd_op_reply(10318 vkom [call,getxattrs,stat] v0'0 uv0 ack = -1 ((1) Operation not permitted)) v7 ==== 208+0+0 (1560361267 0 0) 0x7fc08800b440 con 0x7fc0e00222a0 2017-07-17 20:06:35.043204 7fbfacfb9700 5 error reading user info, uid=I580C6LRM9905GZ2QFIG can't authenticate 2017-07-17 20:06:35.043217 7fbfacfb9700 10 failed to authorize request 2017-07-17 20:06:35.043221 7fbfacfb9700 20 handler->ERRORHANDLER: err_no=-2028 new_err_no=-2028 2017-07-17 20:06:35.043339 7fbfacfb9700 2 req 83:0.001550:s3:GET /:list_buckets:op status=0 2017-07-17 20:06:35.043348 7fbfacfb9700 2 req 83:0.001559:s3:GET /:list_buckets:http status=403 В пулах вот такое: [root@portal-storage1 tmp]# rados -p default.rgw.users.uid ls vkom vkom.buckets [root@portal-storage1 tmp]# rados -p default.rgw.users.uid ls vkom [root@portal-storage1 tmp]# Accesskey Accessid копирую правильно. Проверял 200 раз Увидел кто ошибку? Может кто помочь с этим? Заранее благодарю за ответы и идеи

Слишком многа букаф.

@vadimka_kom , Возможно твой скрипт использует для авторизации aws4

мне в этом помогла вот такая конфигурация: rgw s3 auth aws4 force boto2 compat = false в ceph.conf

правда я столкнулся с данной проблемой при использовании ruby aws sdk

мне в этом помогла вот такая конфигурация: rgw s3 auth aws4 force boto2 compat = false в ceph.conf

Приеду на работу, попробую. Спасибо большое

@vadimka_kom , Возможно твой скрипт использует для авторизации aws4

Скрипт из доки, не думаю, но все же еще разок гляну.

ребзя, есть трабл. Описываю. - есть несколько компьют на которых хостятся инстансы опенстека - есть цеф с железными мониторами но это не важно я полагаю - все хранится в цефе. И вольюм и система - вольюм маунтится в нутри инстанса в /mnt/volume/ - команда ниже запускается для image.img (образ убунты клауд имадж). То есть cd /mnt/volume и там выполняется dd что ниже представлена - кастомер хочет получить объяснение "почему при измерении с помощью команды for i in {1..50}; do dd if=image.img of=test bs=4k count=100 oflag=direct;done они получают усредненный результат на одной из компьют больше на треть чем на остальных компьютах. Например 34 Мб/сек против 18 Мб/сек"

я понимаю что так не меряется производительность цефа

но вопрос стоит в другом

почему при равных условиях получается результат на одной из компьют больше на треть чем на остальных компьютах

hw bug ? маунтите руками тома в компьюты и меряйте - точно станет ясно опенстек шалит или hw/linux

да из-за всего угодно может быть. Версии kernel и cpu одинаковые?

что я смотрел уже: - dmesg на предмет разницы - virsh dumpxml на инстансах на предмет разности - нагрузку сети/процессоров/load average на компьютах и на инстансах - писал из /dev/zero и реально существующий файл - сравнивал время на инстансах/компьютах

jumbo frame везде?

может и hw bug но нужно знать наверняка. Я форматил и маунтил вольюм руками в /mnt/volume, только девайс добавлял через апи опенстека

да из-за всего угодно может быть. Версии kernel и cpu одинаковые?

uname одинаковый

jumbo frame везде?

должен быть везде - как проверить?

управление питанием динамическое или performance?

должен быть везде - как проверить?

сек

ребзя, есть трабл. Описываю. - есть несколько компьют на которых хостятся инстансы опенстека - есть цеф с железными мониторами но это не важно я полагаю - все хранится в цефе. И вольюм и система - вольюм маунтится в нутри инстанса в /mnt/volume/ - команда ниже запускается для image.img (образ убунты клауд имадж). То есть cd /mnt/volume и там выполняется dd что ниже представлена - кастомер хочет получить объяснение "почему при измерении с помощью команды for i in {1..50}; do dd if=image.img of=test bs=4k count=100 oflag=direct;done они получают усредненный результат на одной из компьют больше на треть чем на остальных компьютах. Например 34 Мб/сек против 18 Мб/сек"

Все равно чот не хватает информации. Аппаратные конфигурации, ОС, конфигурация ceph клиентов везде одинаковые, да?

/proc/cpuinfo - одинаковый

Все равно чот не хватает информации. Аппаратные конфигурации, ОС, конфигурация ceph клиентов везде одинаковые, да?

да, это все идентично

компьюты заказывались пакованом в один момент в HP

и конфигурация одинаковая везде

инстансы подняты на обычном клауд имадж убунты 16 чистой

сеть замерейте айперфом

должен быть везде - как проверить?

ping -M do -s 8972 kvm02p24

например вот так

В общем, я бы перед тем как в угадайку играть потестил сам.

И не dd, а fio, например, взял бы.

сеть замерейте айперфом

мерял, там везде около 10 гигабит +- при iperf в 10 потоков с интерфейса на интерфейс между компьютами

мерял, там везде около 10 гигабит +- при iperf в 10 потоков с интерфейса на интерфейс между компьютами

а попробуй именно в один поток, т.к. dd однопоточный в принципе своем.

И не dd, а fio, например, взял бы.

вопрос в другом - почему при равных условиях получается результат на одной из компьют больше на треть чем на остальных компьютах

я знаю что dd не та тулзовина которой надо мерять

а попробуй именно в один поток, т.к. dd однопоточный в принципе своем.

между компьютми померять или как?

ага, сравни, имеется ли разница. Но я бы начал с MTU.

вопрос в другом - почему при равных условиях получается результат на одной из компьют больше на треть чем на остальных компьютах

Вопрос не в этом пока) Вопрос в методологии тестирования. Я понимаю, мне б тож покоя не давало то что дд выдает разные результаты, но первым делом нормально протестил бы.

зачем между компьютами, между компьютами и ceph osd

journal`ы на всех osd одинаковые? write-back cache? Настройки клиента одинаковые на разных compute?

зачем между компьютами, между компьютами и ceph osd

чтобы бы исключить private network между клиентом и ceph

Ребята, так ваще бесполезная угадайка получается. Не зная конфигурации железа и софта у коллеги, не имея результатов нормальных тестов - пытатсья угадать чо не так)

Ребята, так ваще бесполезная угадайка получается. Не зная конфигурации железа и софта у коллеги, не имея результатов нормальных тестов - пытатсья угадать чо не так)

+100500

hyper threading точно везде отключен ? ))

Примем за истину что конфигурация софта и железа вообще одинаковая везде. Тогда вот какие вопросы: Как с количеством инстансов и расходом процессорного времени на гипервизорах? Тоже примерно одинаково? Есть ли где-то агрегация линков? Если да, как настроена?

Выше говорил вроде что все сравнивал, но я так, убедиться)

journal`ы на всех osd одинаковые? write-back cache? Настройки клиента одинаковые на разных compute?

дв

Примем за истину что конфигурация софта и железа вообще одинаковая везде. Тогда вот какие вопросы: Как с количеством инстансов и расходом процессорного времени на гипервизорах? Тоже примерно одинаково? Есть ли где-то агрегация линков? Если да, как настроена?

конфиги одинаковые везде и загруженность инстансами отличается +- на 1 инстанс. Дело даже в том что на компьюте с инстансом с бОльшей скоростью больше хостится инстансов

это не угадайка - я хотел бы получить идеи которые можно проверить. Я потестирую это с помощью fio кончно же но сейчас у меня нет времени - нужно выдать пачку идей для того чтоб меня не пилили по поводу "почему это может так вот быть мы же меряем пробуем поведение смоделировать реальное чего-то там бла бла бла"

а реплик столько же, сколько osd?

агрегация линков - не могу ответить на этот вопрос

это не угадайка - я хотел бы получить идеи которые можно проверить. Я потестирую это с помощью fio кончно же но сейчас у меня нет времени - нужно выдать пачку идей для того чтоб меня не пилили по поводу "почему это может так вот быть мы же меряем пробуем поведение смоделировать реальное чего-то там бла бла бла"

Хуёвая ситуация. Я бы, конечно, послал куда подальше с этими истериками и суетой и попросил время разобратсья спокойно. Но это, видимо, не вариант.

ставлю на баг с гипертредигом! https://lists.debian.org/debian-devel/2017/06/msg00308.html

ставлю на баг с гипертредигом! https://lists.debian.org/debian-devel/2017/06/msg00308.html

Если бы он был, то не возникал бы только на одной машинке и не имел бы постоянное состояние.

Хуёвая ситуация. Я бы, конечно, послал куда подальше с этими истериками и суетой и попросил время разобратсья спокойно. Но это, видимо, не вариант.

не вариант к сожалению так как их уже мурыжили в саппорте и саппорт пришел ко мне теперь...правда, я не совсем понимаю почему))