И не только для бекапа, конечно, но в основном.

Тех, кто полагается только на снепшоты как на бекап - вон из профессии. :)

Ты можешь запустить другой инстанс на этом снимке, зайти в него и сделать оттуда бекап

Это нужно, чтобы не трогать рабочие инстансы, на нагрузке, и тихонечко слить бекап в сторонке.

+1

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

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

Вот согласен. Никогда не знаешь как какой то mysql например доедет в него и в каком виде. Бекапы нужно настраивать из системы.

Вместе со значащими данными хранить файлы ОС и всякую временную шелуху туповато как-то и вообще не DevOps

резюме снапшоты зло, бэкапим средствами системы)))

из самой ОС

резюме снапшоты зло, бэкапим средствами системы)))

Нет, сами снимки — это хорошо, но это не бекап.

Снимки для клонирования системы

Нет, сами снимки — это хорошо, но это не бекап.

Именно. Снимки - отличный инструмент для уменьшения окна влияния процесса РК на сервис

Снимок должен существовать, во время того как делается бекап. После этого ты его уничтожаешь. Или ты можешь просто работь со снимками, чтобы быстро тестировать, что-то.

Снимки для клонирования системы

Клонирование системы в OpenStack это лишнее.

Вот тут не согласен. Хотя смотря что понимать под клонированием :)

Клонирование системы в OpenStack это лишнее.

Почему? Развернул сервис, потом наделал пачку из образа

Если у тебя есть что-то, что должно быть на всех машинах, надо делать образ и заливать его Grance и уже с этим образом работать как с "клоном"

То есть, в понятиях OpenStack это все клонирование.

Ну клонирование подключаемых блочных дисков у части моих пользователей именно классическое клонирование в большинстве случаев. Без промежуточной выгрузки в glance

Инстанс— это не конкретная "заливка" на железо же, это просто cloud-образ OS с подключенными ядрами, памятью и дисками.

Ну клонирование подключаемых блочных дисков у части моих пользователей именно классическое клонирование в большинстве случаев. Без промежуточной выгрузки в glance

Ну вот это, на мой взгляд неоптимальный подход, Glanse как бы вообще нужен для этого (-: можно было бы просто с образами работать, напрямую через libvirt и делов-то. А Glanse он как бы безопасность и скорость обеспечивает.

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

И потом место экономишь, на блочном хранилище. Один образ 10ГБ, 10 образов 100ГБ, ладно 250 рублей/мес. а если больше?

Ну вот это, на мой взгляд неоптимальный подход, Glanse как бы вообще нужен для этого (-: можно было бы просто с образами работать, напрямую через libvirt и делов-то. А Glanse он как бы безопасность и скорость обеспечивает.

Гланс как раз антискорость в данном случае

Гланс как раз антискорость в данном случае

почему это, почему это?

Без него клонирование средствами СХД - секунды. С ним: выгрузка в хранилище гланс, конвертация. После обратная проценудра: выгрузка на cinder-volume, загрузка в блочный диск

Без него клонирование средствами СХД - секунды. С ним: выгрузка в хранилище гланс, конвертация. После обратная проценудра: выгрузка на cinder-volume, загрузка в блочный диск

Вроде обсуждали же уже раза три-пять?

Вроде обсуждали же уже раза три-пять?

Значит я пропустил. И что было в обсуждении?

Если glance полные url настроен показывать, то будет все склонировано средствами хранилища, если драйвер умеет это.

То есть, без прогона всего этого через сам glance,

Эм. С каких пор glance умеет FC и iSCSI?

Эм. С каких пор glance умеет FC и iSCSI?

а, это... -_-

Это единоразовые расходы, зато у тебя нет проблем с разбиением дисков, при "клонировании". OpenStack за тебя все сам сделает. А если ты будешь, вот так вот из вольюма копировать и тебе нужно, чтобы тома были в итоге разного размера, то схватишь головняка с resizefs и так далее...

Надеюсь, простят мне этот каламбур. FC вертел я всем ясно где.

Ну не Ceph’ом единым. У меня три типа бэкендов для Cinder активно используются. Ceph, OceanStor (iSCSI), Storwize (FC). Крутимся как можем

Ну не Ceph’ом единым. У меня три типа бэкендов для Cinder активно используются. Ceph, OceanStor (iSCSI), Storwize (FC). Крутимся как можем

Да ну ясно-понятно. Но и из SDS не только цеф есть. iscsi и fc, с ними все понятно. Их хорошо железу напрямую отдавать, а не виртуалкам.

Надеюсь, простят мне этот каламбур. FC вертел я всем ясно где.

Это не каламбур, но я тоже его там же вертел, не поверишь (-:

Да ну ясно-понятно. Но и из SDS не только цеф есть. iscsi и fc, с ними все понятно. Их хорошо железу напрямую отдавать, а не виртуалкам.

Ну на счёт FC согласен. А вот против отдачи iSCSI виртуалке не знаю доводов

Федор-Семен туды их в качель...

Есть какие-то доводы где могут быть грабли?

По той же скорости, не? Как он там заворачивает все это в Ethernet? Кто-нибудь мерял?

Есть какие-то доводы где могут быть грабли?

Грабли в том что iscsi - это не цеф, не шипдог и не openio, Поэтому и возникает прблема про которую выше говорили. Гланс, к примеру, все через себя гнать будет. Cinder - тож, если что. А других минусов нету вроде.

По той же скорости, не? Как он там заворачивает все это в Ethernet? Кто-нибудь мерял?

Что заворачивается?

Что заворачивается?

А он же даже не в Ethernet заворачивается, а в TCP, ну вот прибавь все косяки хранилищ, к косякам TCP и будет iSCSI

Ну в IP, хрен с ним, 3-й уровень короче.

Ну потенциально конечно могут быть косяки, но вроде пока работает без нареканий

На мой взгляд в случае iSCSI потенциальные косяки такие же как и при Ceph/RBD и другим подобным

На мой взгляд в случае iSCSI потенциальные косяки такие же как и при Ceph/RBD и другим подобным

Все правильно, поэтому он и получает меньше лучей поноса нежели FC.

FC тоже был бы не так плох, если бы им занималось, столько же людей сколько и IP (-:

А какие претензии к FC?

Ну кроме цены на оборудование :)

Ну кроме цены на оборудование :)

Еще раз цена. И еще его неуниверсальность.

Ну он разрабатывался под узкий круг задач

Как-то не прижился он. Infiniband потихоньку распространяется, эзернеты с низкими задержками и TCP с наворотами - тож.

FC не просто прижился, он стандарт де-факто 😀

Проблема просто в том, что FC пришел в дома, слишком поздно.

Просто в enterprise. Для него он и разрабатывался

enterprise для меня синоним говноедства и спускания денег в унитаз, к сожалению. Ничо с собой поделать не могу)

Сколько человек ты знаешь, которые могут настроить агрегацию портов, на циске? И сколько человек, которые сделают то же, на FC свиче?

Просто подуй об этом.

Сколько человек ты знаешь, которые могут настроить агрегацию портов, на циске? И сколько человек, которые сделают то же, на FC свиче?

А там не надо) Оно все само!

Сколько человек ты знаешь, которые могут настроить агрегацию портов, на циске? И сколько человек, которые сделают то же, на FC свиче?

Сравнение не в пользу циски :)

А там не надо) Оно все само!

Это понятно, что само! А если проблемы будут, много спецов ты знаешь, кто туда полезет?

Это понятно, что само! А если проблемы будут, много спецов ты знаешь, кто туда полезет?

Спецов? Да!

Но там скорее всего проблем не будет :)

Это понятно, что само! А если проблемы будут, много спецов ты знаешь, кто туда полезет?

Зачем? Не царское дело, вендорская техподдержка.

С агрегацией портов в сетевых коммутаторах постоянные проблемы (особенно при мультивендорности на разных концах). А вот за весь мой опыт работы с Энтерпрайзом и не очень ни разу не слышал о подобных проблемах в FC

А я успел поработать в интеграторе и разного наслушаться и навидаться

enterprise для меня синоним говноедства и спускания денег в унитаз, к сожалению. Ничо с собой поделать не могу)

Отчасти согласен :)

Но мы оффтопим. Как бы сейчас не проснулись сильные ми... канала сего и не выгнали нас в клауд_флуд

Та не, не должны.

Ну мы же cinder обсуждаем и его бекенды ;)

Ну мы же cinder обсуждаем и его бекенды ;)

Да-да! Админы, пометьте там себе!

Плюс в FC - не нужно думать о QoS

Минус - в этом же =)

Один клиент может положить канал

Плюс в FC - не нужно думать о QoS

Выводи в отдельную сеть, сеть хранения.

У меня так и сделано :)

У меня так и сделано :)

Тогда QoS зачем?