если делать снапшот с аттаченного вольюма, что-то может произойти с его качеством ?

странный вопрос

он естественно будет не консистентным если без агента внутри ВМ. фс будет битой с горантией 90% только через чек поднимется

он естественно будет не консистентным если без агента внутри ВМ. фс будет битой с горантией 90% только через чек поднимется

Это если вм включена)

естественно. А если ВМ выключена волюм не приаттачен -))) логично же ?

естественно. А если ВМ выключена волюм не приаттачен -))) логично же ?

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

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

да, вот на выключенном вольюме и было предупреждение

тот вольюм который можно было отцепить, отцепил и сделал снапшот в итоге

тот вольюм который можно было отцепить, отцепил и сделал снапшот в итоге

С выключенной вм спокойно делай.

С выключенной вм спокойно делай.

ок, да, так и сделал

он естественно будет не консистентным если без агента внутри ВМ. фс будет битой с горантией 90% только через чек поднимется

Ну зачем обманывать? Снапшот будет просто копией диска на указанный момент времени, и всё. Как будто ему тупо срубили питание. Современные ФС абсолютно спокойно такое переживают, никакого fsck им не надо - просто реплеится журнал и всё. Могут потеряться только несброшенные кэши - ну так никто и не обещал

Коллеги, здравствуйте. Уже несколько дней пытаюсь побороть проблему, подскажите, куда копать? Установлен snap microstack, там по умолчанию сеть external 10.20.20.0 и адрес 10.20.20.1. Локально на horizon dashboard заходит. Удаленно - нет. Роутинг на сеть естественно прописал, allowed hosts стоит "*". Открывает страницу аутентфикации, после нее nginx выдает 502 Bad Gateway. Уже чего только не перепробовал - и сети поменял вместо 10.20.20.0 внешнюю (без nat) сконфигурил, но видимо копаю не туда. В коротком доке по microstack написано, что для удаленного доступа надо сделать port forwarding на локальной машине, но этот вариант мне не годится.

Ну зачем обманывать? Снапшот будет просто копией диска на указанный момент времени, и всё. Как будто ему тупо срубили питание. Современные ФС абсолютно спокойно такое переживают, никакого fsck им не надо - просто реплеится журнал и всё. Могут потеряться только несброшенные кэши - ну так никто и не обещал

Ну практика показывает другое, я сам писал сценарий для Rally подобный. С киллом -9 процесса . И таки процентов 90 ВМок улетало в уmergency mode.

Но это при том что там внутри была активная запись, там у меня fio крутился

Ну практика показывает другое, я сам писал сценарий для Rally подобный. С киллом -9 процесса . И таки процентов 90 ВМок улетало в уmergency mode.

kill -9 и снятие снапшота с диска работающей вм эт разное.

Включите тут лайки к сообщениям плиз, хочется наваливать плюсов

kill -9 и снятие снапшота с диска работающей вм эт разное.

абсолютно тоже самое. Если у тебя нет агента внутри ВМ и ты делаешь безагентный бэкап с помощью снапов. У тебя не скинутые буфферы. sync ни кто не сделал. И ломается метадата у ФС. Но опять же это я тестил на большой нагрузке на диск. На умеренной впослне может подняться. Ну и например был у нас прикол в WG. Mkhl не даст соврать когда отъезжала полка на NFS. Приходилось чекать все ФС иначе не взлетали.

абсолютно тоже самое. Если у тебя нет агента внутри ВМ и ты делаешь безагентный бэкап с помощью снапов. У тебя не скинутые буфферы. sync ни кто не сделал. И ломается метадата у ФС. Но опять же это я тестил на большой нагрузке на диск. На умеренной впослне может подняться. Ну и например был у нас прикол в WG. Mkhl не даст соврать когда отъезжала полка на NFS. Приходилось чекать все ФС иначе не взлетали.

Поверх NFS хранились образы дисков виртуальных машин?

угу сторадж на соляре -) по NFS это говно работало ))) Мы знаем что кривизна -)) Но как есть )

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

Этот примр ничем не отличается от снятия снапа безагентского. Причем чем больше рамы у ВМ тем больше шанс отхватить поломанную метадату

не все приложухи с диском работают в IO_DIRECT, как следствие они оседают в грязных страницах. И это нормально так ломает FSки

не все приложухи с диском работают в IO_DIRECT, как следствие они оседают в грязных страницах. И это нормально так ломает FSки

При чём тут фс и дата? Вопрос же как фс мету запишет

И не синкнутая дата - проблема приложения

И если от вм синк как-то "пропустить", то да, аминь

При чём тут фс и дата? Вопрос же как фс мету запишет

да мета там тоже ломается, ext3 такие приколы точно не любит.

да мета там тоже ломается, ext3 такие приколы точно не любит.

Ну журнал на то и нужен

Ну журнал на то и нужен

так я и не говорю, что ей кабзда. Но ВМка на RHEL не стартует, она в emergency mode падает.

делаешь чек и поехали дальше

там ext2 что ли?

И это еще раз доказывает что дельфин умнейшее животное и потому не использует давно протухшие фс и ядра)

И да еще зависти от ФС. Но я например знаю таких дуриков. Которые в облаке когда им не хватило 50Гб диска, они добавляют еще диск на 10Гб и через LVM его размазывают. Как тут делать безагентные бэкапы - вопрос риторический

А у @Outlingo есть хорошая статья на тему бекапов, но в контексте MCS (VK)

Да я видел ее ))) Да и Артема знаю )))

@Outlingo И кстати да по поводу статьи на некоторых типах нагрузок рид эхед даже нужно увеличивать -))) всякие там S3 и другие файлопомойки

ну и хосты где сами бэкапы лежат

оч сильно помогает при восстановлении

то есть ВМ будет испорчена всякий раз, когда зависла или умерла compute-нода, если в этот момент была запись? а что в 'cache' в libvirt стоит при этом? не unsafe или writeback, часом?

@Outlingo И кстати да по поводу статьи на некоторых типах нагрузок рид эхед даже нужно увеличивать -))) всякие там S3 и другие файлопомойки

Это клиент может сам себе сделать если хочет.

Это клиент может сам себе сделать если хочет.

не Тем, я про сами бэкап хосты когда у нас линейное чтение идет. Я до 2Мб увеличивал со 128кб и мне это давало не хилый прирос по скоросте восстановления из бэкапа. Я про это

Я так на Hitachi USP-V и EMC Symmetrix увеличивал, там на восстановлении мне давало примерно +30%

не Тем, я про сами бэкап хосты когда у нас линейное чтение идет. Я до 2Мб увеличивал со 128кб и мне это давало не хилый прирос по скоросте восстановления из бэкапа. Я про это

На восстановлении вообще все читается блоками примерно вплоть до 250МБ

если делать снапшот с аттаченного вольюма, что-то может произойти с его качеством ?

Вроде бы более безопасно делать в хорайзоне снапшот вмки. В апи это что-то типа создание имаджа с вм, не помню точно. Если в имадже кему агент есть и метаданные правильные, то вмку приморозят перед созданием снапшота. Можно написать скрипт, который будет выполнять дополнительные действия по подготовке вм к снапшоту, который будет выполняться внутри вм, что повышает шансы снять консистентый. Код этот в нове уже давно есть, недавно его смотрел в очередной раз. Но тестов не проводил

Всем привет. Создаю инстанс openstack --os-compute-api-version 2.74 server create --image "cirros" --flavor '2 vCPU, 2G RAM, 1G SSD' --network provider max_id-654 Подскажите, что за строка accessIPv4?

Всем привет. Создаю инстанс openstack --os-compute-api-version 2.74 server create --image "cirros" --flavor '2 vCPU, 2G RAM, 1G SSD' --network provider max_id-654 Подскажите, что за строка accessIPv4?

https://docs.openstack.org/api-ref/compute/

https://docs.openstack.org/api-ref/compute/

Был я там. по поиску не находит. Это надо раскрывать каждую вкладку и искать. Поэтому и спросил.

Ой, да ну его блин

Ой, да ну его блин

Уже нашел ))

`accessIPv4 (Optional) body string IPv4 address that should be used to access this server.`

Ты шутишь чтоль или у тебя картинки не грузятся?

Я скриншот к ссылке приложил.

Ты шутишь чтоль или у тебя картинки не грузятся?

?

Блин. Извиняюсь. Слепой

Спасибо.

Вроде бы более безопасно делать в хорайзоне снапшот вмки. В апи это что-то типа создание имаджа с вм, не помню точно. Если в имадже кему агент есть и метаданные правильные, то вмку приморозят перед созданием снапшота. Можно написать скрипт, который будет выполнять дополнительные действия по подготовке вм к снапшоту, который будет выполняться внутри вм, что повышает шансы снять консистентый. Код этот в нове уже давно есть, недавно его смотрел в очередной раз. Но тестов не проводил

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

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

Так ведь?

Мог просто сделать снапшот с force-флагом

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

Так ведь?

Да, в целом так. Могут быть разные нюансы в зависимости от бэкенда под циндером

Да, в целом так. Могут быть разные нюансы в зависимости от бэкенда под циндером

Есть источник где эти нюансы описаны?

В документации к бэкэнду же. Зависит от хранилища которое используешь, короче.

Есть источник где эти нюансы описаны?

самый правильный критерий истины-проверить у себя на своей версии дистрибутива, бэкенда и конфигах. с опенстеком лучше так: то что не протестировано у себя - то не работает

В документации к бэкэнду же. Зависит от хранилища которое используешь, короче.

Понял, а в самом плохом случае что может быть? Пока что со стеком работаю только в рамках определённых задач, поэтому со всеми особенностями могу быть не знаком

самый правильный критерий истины-проверить у себя на своей версии дистрибутива, бэкенда и конфигах. с опенстеком лучше так: то что не протестировано у себя - то не работает

согласен, ну, создавал диски из снапшотов, они работали

Понял, а в самом плохом случае что может быть? Пока что со стеком работаю только в рамках определённых задач, поэтому со всеми особенностями могу быть не знаком

Это не про стек больше вопрос. В худшем случае если снапшот будет битым получишь битый том на выходе.

Или если во время пересоздания тома из снапшота что-нибудь поломается.

Всем привет!

у кого есть решение по ошибками —————————————[core:error] [pid 235689:tid 140624489400064] (13)Permission denied: [client 192.168.102.214:64010] AH00035: access to /dashboard/auth/login denied (filesystem path '/usr/share/openstack-dashboard/openstack_dashboard') because search permissions are missing on a component of the path

WSGIDaemonProcess dashboard WSGIProcessGroup dashboard WSGISocketPrefix run/wsgi WSGIApplicationGroup %{GLOBAL} WSGIScriptAlias /dashboard /usr/share/openstack-dashboard/openstack_dashboard/wsgi/django.wsgi Alias /dashboard/static /usr/share/openstack-dashboard/static <Directory /usr/share/openstack-dashboard/openstack_dashboard/wsgi> Options All AllowOverride All Require all granted </Directory> <Directory /usr/share/openstack-dashboard/static> Options All AllowOverride All Require all granted </Directory>

OS: centos 8 stream

Рискую быть кэпом: права на директории проверил? Включая selinux?

[root@controller openstack-dashboard(keystone)]# ls -la total 16 drw-r-----. 4 apache root 64 Apr 28 11:59 . drwxr-xr-x. 134 root root 4096 Apr 28 11:59 .. -rwxr-xr-x. 1 apache apache 827 Mar 30 17:30 manage.py drwxr-xr-x. 18 apache apache 4096 Apr 28 11:59 openstack_dashboard drwxr-xr-x. 10 apache apache 114 Apr 28 11:59 static

selinux включен

setsebool -P httpd_can_network_connect on

drw-r-----. 4 apache root 64 Apr 28 11:59 .

apache может читать, но wsgi запускается от него же?

а, и "x" нет вообще ни для кого

сделай нормальный 0750 для начала?

drwxr-x---. 4 apache apache 64 Apr 28 11:59 openstack-dashboard

сделай нормальный 0750 для начала?

но зачем? manage.py нужна для ручных действий в консоли и интерпретатор можно легко указать руками вот так: python manage.py согласно конфигу, апач же будет импортировать wsgi приложение /usr/share/openstack-dashboard/openstack_dashboard/wsgi/django.wsgi это значит, что есть папка /usr/share/openstack-dashboard/openstack_dashboard/ в ней должен быть файл djanfo.py в котором есть переменная wsgi = ...