ну оно не померло, оно просто болит

не дает? иопсы?

мы про цеф или про комбо из цефа и опенсткека? ну вообще как бы иопсы и иопсы, latency не стабильный и высокий

мы про цеф или про комбо из цефа и опенсткека? ну вообще как бы иопсы и иопсы, latency не стабильный и высокий

у меня только цеф. виртуализация стара и непокобелима, никто разгребать этот XEN не будет, себе дороже

о да, особенно если старый

xen

@cloud_flood

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

с цефом

на хабре было же

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

что ты хочешь услышать?

на хабре было же

по моему там все врут

что ты хочешь услышать?

ну что нибудь увлекательное, вот я знаю в тиониксе много цефа

они там с ним сражаются давно

но чет инфы нет особо

но чет инфы нет особо

ну так успешный тионикс успешен

ну что нибудь увлекательное, вот я знаю в тиониксе много цефа

что? что ололо 100к иопсов с 20 SATA 7200 дисков не бывает потому что физика бессердечная сука? что тиринг не очень производительно работает для RBD и это описано в оф доке?

да это и так всё понятно

да вот не всем

что латенси у нас упирается в физику и если надо прям малые задержки то используйте infiniband или ждите RDMA stable

типичный диалог кто-то:Nutanix быстрый, цеф медленный хор:да да, медленный CEPH. я:а диски то какие у вас? хор:ой какие диски, нутаникс дает 100к ипосов.

что латенси у нас упирается в физику и если надо прям малые задержки то используйте infiniband или ждите RDMA stable

Сейчас маленькие латенси может и Ethernet дать, если нормальный коммутатор взять

Хочется все же RDMA

типичный диалог кто-то:Nutanix быстрый, цеф медленный хор:да да, медленный CEPH. я:а диски то какие у вас? хор:ой какие диски, нутаникс дает 100к ипосов.

data locality умеет ceph?

Сейчас маленькие латенси может и Ethernet дать, если нормальный коммутатор взять

Скорее проблемы в хосте, а не в свитчах ( мало кто хочет писать свой велосипед поверх dpdk и поддерживать его потом )

data locality умеет ceph?

и в гиперконвергентость с виртуализацией не умеет. яж не спорю с этим.

типичный диалог кто-то:Nutanix быстрый, цеф медленный хор:да да, медленный CEPH. я:а диски то какие у вас? хор:ой какие диски, нутаникс дает 100к ипосов.

1 лям на 4 ноды... За что ты так нутаникс обижаешь?

1 лям на 4 ноды... За что ты так нутаникс обижаешь?

я не обижаю. я хочу что бы сравнивали сравнимое блеадь.

:P

data locality умеет ceph?

А зачем? Что бы быть ограниченными только теми дисками, которые доступны ноде?

понеслась)

А зачем? Что бы быть ограниченными только теми дисками, которые доступны ноде?

(facepalm)

Ну вы хоть узнайте сначала что это и как работает, а то выглядит забавно.

Скорее проблемы в хосте, а не в свитчах ( мало кто хочет писать свой велосипед поверх dpdk и поддерживать его потом )

Свичи тоже важны. DPDK тоже хорошо бы, но после RDMA - будет не нужен

а что если RDMA не нужен?

а что если RDMA не нужен?

всмысле?

ну не нужен

ну не нужен

ну при ethernet есть физические ограничения ниже которых ты не упадешь

Давайте тут обсуждать цеф

@SinTeZoiD давай доклад про ceph =)

Сейчас про ceph писать особо нечего, основные темы давно пережеванны.

@SinTeZoiD давай доклад про ceph =)

до DPDK + CEPH я так и не добрался

Я сегодня написал конвертор рбд снапшота в qcow2

Типа экспорта диффа но в формате qcow2

Раотает! И быстро!

Теперь можно мутить инкрементальные бекапы из которых можно восстановиться вобще без цефа

А в чем была проблема? Qemu-img давно так может, а в 2.9 он теперь асинхронный и работать должен, по словам разработчиков, быстрее

Не низвожу твою работу, не подумай.

А в чем была проблема? Qemu-img давно так может, а в 2.9 он теперь асинхронный и работать должен, по словам разработчиков, быстрее

Не умеет. Допустим, у меня есть рбд образ в 11 гигов. Я сделал снапшот в цефе. Поработал. Размер диффа в снапшоте 100 мегабайт. Внимание -- вопрос. Как из этого стандартными средствами получить 11-гиговый кукоу2(эту часть конечно можно) И ВТОРОЙ КУКОУ2 размером 100 мегабайт физически, но 11 гигов виртуально, при этом в качестве бэкинг-стора ссылающийся на первый кукоу2?

Кароч я сделал rbd diff export но в формате qcow2. Что позволяет в случае аварии в цефе указать его виртуалке и запустить виртуалку не имея цефа вобще.

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

и как эту цепочку запустить в qemu?

Указать последний кукоу. И все.

Искаропки.

Вернее не последний а любой

м-м ... не совсем понял: указываю последний дифф в сто метров? и откуда он остальные данные возьмёт на 11 гигов?

Внутри кукоу2 будет ссылка на имя файла базового образа. Коим в нашем соучае будет являться предыдущий снапшот.

Он это умеет

А qemu-img умеет merge'ить diff'ы?

А qemu-img умеет merge'ить diff'ы?

Да!

А куему аж на лету. Но это совсем другая история

т.е. если у меня есть цепочка 4->3->2->base, то можно 3 diff с 2ым merge'ить? Чтобы получилось 4->2.5->base?

Ээээ

Щас ман кину

Блин. Не кину

http://wiki.libvirt.org/page/Live-merge-an-entire-disk-image-chain-including-current-active-disk

Но это про куему. Но и qemu-img rebase есть

Прост для целей бекапа мерджи не нужны. Во избежание ерроров, вместо мерджей старых снапшотов в один, лучше раз в месяц с цефа стянуть полную копию и начать цепу с нуля.

К меня так. Классический полный бекап и серия инкрементальных

В любом случае из любой цепочки можно сделать цельный образ через qemu-img convert. Прост это больше io чем могло бы быть

А!! Мердж возможен через команду qemu-io по ходу

Кстати, все что ты сделал, можно было сделать средствами qemu, посылая комманды qmp в процессу. Читаю сейчас доку, наконец-то разрабы описали все команды qmp в доке

А!! Мердж возможен через команду qemu-io по ходу

Просто из любопытства, а ФС то как синкаете? xfs_freze какой-нибудь перед снапшотом?

Просто из любопытства, а ФС то как синкаете? xfs_freze какой-нибудь перед снапшотом?

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

а вобще — sync() + fsfreeze()

через qemu-ga

но это полировка торпеды и нинужность

только замедляет общее время бекапленья

если приложению похер на свои данные (не делает фсинк) то и мне тоже похер.

Это ты конечно, загнул, т.е. bd должна при каждом комитете делать fsync?

Это ты конечно, загнул, т.е. bd должна при каждом комитете делать fsync?

нет, но БД умеет восстанавливаться целостно.