Pavel
на нфс же, в логе написано
Pavel
ккоу2
Pavel
флеш рояль
Anonymous
Тогда как вариант законвертить и примапить к другой вм ( ну или примапить не конвертируя)
Pavel
да чо толку, там либвирт не понимает что с памятью делать
Radik
в общем, сделал define
Radik
virsh list --all Id Name State ---------------------------------------------------- - instance-00000220 shut off virsh распознал запускаю virsh start instance-00000220 error: Failed to start domain instance-00000220 error: internal error: qemu unexpectedly closed the monitor: 2019-12-02T12:06:56.708285Z qemu-kvm: -chardev pty,id=charserial0,logfile=/dev/fdset/2,logappend=on: char device redirected to /dev/pts/3 (label charserial0) 2019-12-02T12:06:56.749371Z qemu-kvm: cannot set up guest memory 'pc.ram': Cannot allocate memory
Radik
памяти total used free shared buff/cache available Mem: 31875 8555 16378 321 6941 22505 Swap: 1022 0 1022
Anonymous
nova.conf в студию
Radik
тогда такой вопрос как сейчас можно импортнуть это всё дело и запустить в каком-нибудь proxmox или vmware
Pavel
лимиты св
Pavel
лимиты смотри, возможно кему не может сокет сделать
Pavel
или либвирт в дебаг логирование переводи, он напишет что пошло не так
Radik
принято ушел пока
Anonymous
Qemu-convert qcow в формат vmdk
Pavel
или selinux там какой без профиля под вычислительный узел на kvm
Radik
Qemu-convert qcow в формат vmdk
поможет? учитывая, что инстанс создан на базе шаблона
Radik
/srv/nfs/96cf28bd-c074-4aa4-b8fb-62cc6f364452/disk: QEMU QCOW Image (v3), has backing file (path /srv/nfs/_base/0c731df092417ccc1fc4775d18390f7362b1100c), 42949672960 bytes
Pavel
не поможет
Radik
вот и я так подумал(
Anonymous
поможет? учитывая, что инстанс создан на базе шаблона
Это если хочешь стянуть диск в формат варьки
Anonymous
А не заново пересоздавать
Radik
Это если хочешь стянуть диск в формат варьки
а дальше плюсуешь) чему верить
Radik
а, т.е. тупо куда-то приаттачить?
Anonymous
Да
Anonymous
И потом разбираемся что у тебя с либвирт, почему инстансы не создаются
Radik
да, понял спасибо всем большое
Anonymous
Если это еще надо будет
Radik
не, сам опенстэк сейчас не нужен новые создаваться не будут
Radik
в общем, отпишу, как положено решение оказалось довольно тупым, о чем сразу можно было догадаться - xml я стянул из лога - virsh define - ну и причиной allocate memory конечно же был оверкоммит🤦‍♂️
Radik
@poghost @j52089ec7e87 спасибо за помощь
Radik
А ты говорил памяти дофига)
дофига 20гб стабильно свободно
Radik
причем я даже своп ради этого врубал на всякий)
J
дофига 20гб стабильно свободно
Ну надо смотреть то на суммарно выделенную виртуалкам память. А из твоих объяснений я подумал что вообще ни одна машина на хосте не стартует.
J
а как суммарную смотреть?
openstack hypervisor show или в веб интерфейсе admin -> compute -> hypervisors
Hello
Так, немного утренней ржаки от моего начальства. Перевод by гугль транслейт с корейского. Pre-meeting request for the introduction of %Company name% OpenStack. 1. Goal The goal is to transform all server and IDC infrastructure(веб хостинг, два этажа датацентра) that %Company name% currently has into an OpenStack cloud. The work will be carried out with a phased roadmap. l %Company name% IDC Operation SE 2. Meeting Agenda How will you transition your IDC infrastructure to the OpenStack cloud? l Calculate the primary cost of introducing OpenStack l Issues on technology transfer and education Thank you.
Hello
Это имеет хоть сколько-то рациональное зерно? Переводить веб хостинг с физических машин на жирный опенстэк?
Hello
Как вообще может выглядеть миграция физических серверов в инфраструктуру опенстэка? Делать образ каждого сервера и загружать в glance?
Anonymous
Ну в общем и целом это имеет жирный плюс, но трудозатратно получится
Anonymous
И тут надо подумать стек или обойтись докерами с k8s раз это веб
Anonymous
Смотря еще какие сервисы в вебе крутятся
Hello
Смотря еще какие сервисы в вебе крутятся
Да все по классике, апачи с mysql'ами всякими, ну цмс поверх
Anonymous
В кластере?
Anonymous
Тогда путь следующий, пробуй ( если есть ресурсы) ceph-docker-k8s базы рекомендовал бы вынести отдельно, далее бэкапы средствами цмс с физики и раскаты уже в сервисах которые крутятся в докерах
Anonymous
Если есть опыт написания playbook то все будет немного проще
Anonymous
Прикоучиваешь ко все этому хозяйству kibana и grafana - профит
Anonymous
Да все по классике, апачи с mysql'ами всякими, ну цмс поверх
Ну и конечно не забываем ( если это веб) перекинуть все это на nginx
Anonymous
Ну и это мое мнение ИМХО
Anonymous
Стек я не вижу смысла тут поднимать...
Hello
Стек я не вижу смысла тут поднимать...
Меня, к сожалению не спрашивают, на чем релизовывать, мне говорят : реализуй на openstck. Про ваш вариант я в любом случае почитаю, выглдит интересно.
Anonymous
Ну ок, тогда все равно рекомендую базы в стек не запихивать, производительность у нее будет вообще не ахти какая!
Hello
Логично! Положить бд в инстансы, в потом реплецировать для "надёжности" на другие инстансы
Anonymous
Лучше БД держать на физике
Hello
Лучше БД держать на физике
Согласен. Про инстансы и репликацию была шутка..
Hello
Я правильно понимаю, что создать образ работающего сервера, например акронисом, и перенести его в среду опенстека задача как минимум нетривиальная? Я сейчас копаюсь в документации по glance и пока ничего близкого по функционалу не нашел.
Anonymous
насчёт окрониса хз, qcow/raw импорт работает отлично
Тут вопрос о миграции физической машинки в виртуальную
Tamerlan
можно еще rsync в корень с livecd
Hello
Как же я люблю такие велосипеды.. Спасибо за направление, буду гуглить!
J
Ну ок, тогда все равно рекомендую базы в стек не запихивать, производительность у нее будет вообще не ахти какая!
Производительность будет зависеть от того какой бекэнд для хранения дисков машин использовать. Но в общем случае хранить на сетевых хранилищах бессмысленная затея. Плюсов никаких, в общем то, только новые слои абстракции.
Pavel
А v2v и p2v уже не модно?
Dmitry
😉
J
Как вообще может выглядеть миграция физических серверов в инфраструктуру опенстэка? Делать образ каждого сервера и загружать в glance?
Если нужн омигрировать систему полностью, то это однозначно дерьмовая идея. Вот олько несколько пунктов: 1. Убедиться что везде нормальные udev правила для именования устройств, потому что если там нету чего-то типа системдшного predictable device namin, то имена интерфейсов пойдут по очевидной прчиине по пизде. Также проверить всё что в своих конфигах может использовать имена интерфейсов или мак адреса 2. Проверить fstab, убедиться что монтирование происходит не по именам устройств, а по меткам фс, uuid, lvm тэгам или чему угодно еще. Потому что при миграции, опять же, количество и названия дисковых устрйоств поменяются 3. Если разные точки монтирования на разных устройствах, надо придумать как всё скопировать на одно устройство и с него уже снимать образ, иначе разбираться в этой лапше покажется сущим адом. 4. Установить в системе cloud-init 5. Грузить с livecd и содавать образы в любом удобном тебе формате, загрузить их в glance 6. Нарезать в опенстеке сети согласно твоей продуманной заранее архитектуре 7. Начать потихоньку разворачивать из образов Сизифов труд. Бессмысленный и тяжелый. Проще насоздавать чистых виртуальных машин и туда смигрировать веб приложения.
J
зависит от нагрузки на базу
В любом случае затея бессмысленная, мне кажется) Не опасная, не плохая, а просто смысла нету.
J
В любом случае затея бессмысленная, мне кажется) Не опасная, не плохая, а просто смысла нету.
Если, конечно, ты контролируешь baremetal инфраструктуру. А если арендуешь где-то серверы или кто-то у тебя берет под свои приложения виртуальную машину, то, конечно, ради бога, пусть работает в виртуалке и пишет хоть в ceph хоть в какой-нибудь, прости хоспаде, solidfire, ничего плохого.
Hello
Если нужн омигрировать систему полностью, то это однозначно дерьмовая идея. Вот олько несколько пунктов: 1. Убедиться что везде нормальные udev правила для именования устройств, потому что если там нету чего-то типа системдшного predictable device namin, то имена интерфейсов пойдут по очевидной прчиине по пизде. Также проверить всё что в своих конфигах может использовать имена интерфейсов или мак адреса 2. Проверить fstab, убедиться что монтирование происходит не по именам устройств, а по меткам фс, uuid, lvm тэгам или чему угодно еще. Потому что при миграции, опять же, количество и названия дисковых устрйоств поменяются 3. Если разные точки монтирования на разных устройствах, надо придумать как всё скопировать на одно устройство и с него уже снимать образ, иначе разбираться в этой лапше покажется сущим адом. 4. Установить в системе cloud-init 5. Грузить с livecd и содавать образы в любом удобном тебе формате, загрузить их в glance 6. Нарезать в опенстеке сети согласно твоей продуманной заранее архитектуре 7. Начать потихоньку разворачивать из образов Сизифов труд. Бессмысленный и тяжелый. Проще насоздавать чистых виртуальных машин и туда смигрировать веб приложения.
>Проще насоздавать чистых виртуальных машин и туда смигрировать веб приложения. Да, к этому я и надеюсь склонить наших реформаторов. Которые хотят опенстак просто потому что модно-молодежно. >А если арендуешь где-то серверы или кто-то у тебя берет под свои приложения виртуальную машину Арендуется дата-центр, железо все своё. Я так понимаю начальство хочет продать часть железа и отказаться от части аренды, перенеся инфраструктуру на опенстак. С одной стороны, с точки зрения бизнеса, я понимаю эти фантазии, но как инженер я знаю, что мы не мэйл.ру, условный, с отделом девопсов, и реализация может встать в серьёзную головную боль, возможные простои, отказы клиентов и пр. Так что финансовая сторона вопроса тоже вызывает сомнения.. Спасибо большое за ваш список по пунктам, схоронил, попробую реализовать на какой-нибудь мартышке.
Dmitry
Я правильно понимаю, что создать образ работающего сервера, например акронисом, и перенести его в среду опенстека задача как минимум нетривиальная? Я сейчас копаюсь в документации по glance и пока ничего близкого по функционалу не нашел.
а можно в качестве наброса высказать утверждение, что переход в виртуализацию требует изменения в целом подхода к инфраструктуре... и просто перенос с baremetal в virtual machine один к одному - это: а) постоянная стрельба себе по коленям, локтям б) разочарование в людях, себе и технологиях из-за обещаний вендоров / провайдеров о прекрасном облачном мире в) вопреки ожиданиям - снижение SLA, если они есть
Dmitry
это не конструктив, скорее предостережение по поводу того, что надо остановиться и подумать - а зачем нам переносить все в виртуализацию? ...
Pavel
Попытка донести инженерную мысль Бизнесу?)
Dmitry
Надежда сделать ит мир у нас чуть более осознанным.