Anonymous
Мне не за чем
Anonymous
Но есть коллеги, которым нужно
Anonymous
Объясняли нуждой приоритизации траффика прода перед тестовым и девелоперским
citius
всем привет. снова я с ансбл-опенстеком.
опять какая-то дичь :D
установка в repo контейнер падает на сборке venv для кейстоуна.
падает на python зависимостях:
Could not find a version that satisfies the requirement pyasn1>=0.3.7 (from python-ldap) (from versions: 0.3.1)\nNo matching distribution found for pyasn1>=0.3.7 (from python-ldap)"
citius
чо с этим можно сделать то? )))
Александр
😄
Михаил
Shamil
Shamil
Вот специально сейчас прод выключил, диск стал Availible, а не Attached
NS 🇷🇺
Михаил
Shamil
Shamil
У меня очень кодовый скрипт, единственный выебон там, это то, что он заливает архивы в Nexus как maven-артефакты, с версионированием и всем таким...
Shamil
Но вообще вопрос насущный. Какие best practices в бекапе на OpenStack?
J
Ну в плане бэкапов.
Dima
Вопрос что бэкапить. Если свои данные изнутри то xtrabackup, tar, rsync и duplicity
Обычно за глаза хватает.
Dima
Если диск то снапшот и с него потом бекап.
Shamil
Ну в плане бэкапов.
На голом железе нальзя сделать снимок, запутить с него интанс, и забекапить приложухой. Например.
J
Та и хуй с ним.
Бэкапить целиком виртуалки на регулярной основе это тот еще дурной тон.
Shamil
J
Аргументов толковых не будет но моё чутьё мне всегда подсказывало что резервные копии должны содержать как можно меньше мусора не относящегося, собственно к полезным данным и при этом должны быть как можно более независимыми.
То есть, копия базы - это копия базы, а копия конфигов твоих - это отдельный репозиторий, а то и несколько. Резервные копии блобов типа фотографий\видео - ды ок, можно прям целиком их и переливать в какое-т отдельное место.
И все это по отдельности можно восстановить из разных контрольных точек, а не откатывая целиком окружение, если тебе нужны только старые конфиги или старая база.
У такого подхода и обратная сторона есть, но все ж)
J
А снапшоты все эти, что средствами системы что срдствами хранилища - это так се.
Подходит если вся инфрастуктура для людей со стороны и каждый отвечает только за свою виртуалку. Тогда да, идеально для них.
Shamil
Aleksey
Госпда, подскажите плз доку по анонсированию FIP и SNAT на бордер роутер по протоколу маршрутизации, но через приватную сеть. Не так как тут: https://docs.openstack.org/mitaka/networking-guide/config-bgp-dynamic-routing.html
Fox
коллеги подскажите, пока вьехать не получается) есть офисная сетка со своим шлюзом с DHCP (PXE) нужно чтобы до офисной сетки напрямую был доступ у виртуалки, если я добавлю сеть в опенстек, там же появится и DCHP... Или я что то не допонял...
Artem
Artem
Fox
Все понял
satandyh
Товарищи, небольшой вопрос по noVNC. Я так понимаю, что на compute нодах и controller'ах ip адреса для proxy должны быть из одной подсветки, так?
Fox
хм в фуеле нету функционала дополнительных external networks
Fox
значит будем ручками
satandyh
Ну и второй вопросец: эта самая подсесть из первого вопроса должна отличаться от той сети, к которой будет подключаться сам клиент, чтобы собственно наблюдать всю красоту и внутренний мир вм?
J
Утро вопросов)
Гуд)
J
Fox
Fox
Проверю
Aleksey
Если я всё правильно понял, то с помощью "subnet service type" мы можем назначить внешний пул для FIP и приватный пул для DVR. Но в таком случае для доступа к FIP из вне на бордер надо заанонсить маршруты. Это же можно сделать с помощью BGP-agent? Как проанонсировать SNAT на бордер?
J
SNAT - в смысле адрес на виртуальном роутере в который делается snat?
Aleksey
Igor
при создании bgp спикера есть параметр
--advertise-floating-ip-host-routes
вроде это то что нужно ?
Igor
я не проверял его, у нас ipv6 сеть анонсится, а v4 только для плавающих адресов
Aleksey
ipv6 это self-service?
Igor
нет, это публичная сеть
Igor
тоесть у нас виртуалки с dualstack - приватные сети + плвающие адреса на каждый инстанс и ipv6 на каждой виртуалке
J
snat адреса берутся из external сетей.
Соответсно, если эти сети анонсируются, то у нас все ок.
J
Я пока никак не охвачу всю картину в целом.
Aleksey
есть у нас провайдерская сеть и мы не хотим тратить по IP на DVR, как я понял мы можем воспользоваться subnet service type для использования приватной сети между DVR и бордер роутером, таким образом мы не тратим дополнительны IP, но из-за этого бордер должен получать инфу за каким приватным IP какой внешний, насколько я понимаю такая же схема должны бать и для нетворк ноды. Анонс FIP на бордер по BGP у меня в целом работает вот по этому ману: https://docs.openstack.org/mitaka/networking-guide/config-bgp-dynamic-routing.html
J
Andrey
не должно иметь смысла) какая вам разница потратите вы FIP или IP из сервисной сети, они оба должны роутиться
Andrey
или у вас FIP это внешние белые айпишники ?
Aleksey
белые
Andrey
тогда нат на бордере не забудте) или на вашем edge) сколько у вас нод если не секрет ? ) за сколько айпишников идет борьба ? =)
Aleksey
А зачем нам нат на бордере? Главное чтобы бордер знал про белые IP и через какие приватные доступны. В данный момент это вопрос принципа :)
Andrey
DVR немного мутный для меня
1) я создал ВМ с приватным адресом
2) я обратился с нее в инет
- трафик с компьюты пойдет на бордер, с натом ?
- трафик с компьюты пойдет на "нетноду" и там висит нат ?
J
Это уж так, докопаться, но в целом то мож плавающие адреса и не нужны?
Можно dhcp агентом раздавать в провайдерской сети. Тогда прям и ок выходит, вроде.
Andrey
Aleksey
Aleksey
J
контреилом запахло и подобными штуками)
Andrey
контрейл это про другое)) тут запахло костылями)
Михаил
Михаил
Александр
#Вакансия #Москва
В облачную компанию ТИОНИКС (дочка РОСТЕЛЕКОМА) http://tionix.ru/
требуются ИНЖЕНЕРЫ ТЕХНИЧЕСКОЙ ПОДДЕРЖКИ.
ЗП 100-160 на руки. Территориально офис на Остаповском проезде.
Основные задачи и обязанности:
1. Обеспечение бесперебойной работы облачных решений на базе OpenStack:
2. Настройка инфраструктурных сервисов и компонентов.
3. Оптимизация производительности.
4. Поддержка и консультация пользователей облачной платформы в качестве 2-ой линии поддержки.
5. Мониторинг инфраструктуры и устранение инцидентов.
6. Разработка и актуализация эксплуатационной документации.
ТРЕБОВАНИЯ:
1. Опыт работы системным администратором, системным инженером Linux от 3 лет.
2. Хорошие знания ALTLinux/RHEL/Debian или их производных, наличие сертификатов RHCSA, RHCE будет преимуществом.
3. Опыт работы с системами виртуализации KVM/Xen, Docker/LXC.
4. Знание и опыт работы c MySQL/PostgreSQL.
5. Понимание архитектуры OpenStack, опыт разворачивания в тестовой среде, реальный опыт будет преимуществом.
6. Понимание архитектуры распределенной системой хранения данных Ceph, опыт разворачивания в тестовой среде, реальный опыт будет преимуществом.
7. Понимание принципов работы основных сетевых протоколов и служб(IP, UDP, TCP, DNS, DHCP, FTP), модели OSI и стека протоколов TCP/IP.
8. Опыт написания скриптов(Bash/Python/Perl/Ruby).
9. Английский - чтение технической документации
10. Желание осваивать новое, умение работать в команде.
Михаил
Igor
да
Михаил
#Вакансия #Москва
В облачную компанию ТИОНИКС (дочка РОСТЕЛЕКОМА) http://tionix.ru/
требуются ИНЖЕНЕРЫ ТЕХНИЧЕСКОЙ ПОДДЕРЖКИ.
ЗП 100-160 на руки. Территориально офис на Остаповском проезде.
Основные задачи и обязанности:
1. Обеспечение бесперебойной работы облачных решений на базе OpenStack:
2. Настройка инфраструктурных сервисов и компонентов.
3. Оптимизация производительности.
4. Поддержка и консультация пользователей облачной платформы в качестве 2-ой линии поддержки.
5. Мониторинг инфраструктуры и устранение инцидентов.
6. Разработка и актуализация эксплуатационной документации.
ТРЕБОВАНИЯ:
1. Опыт работы системным администратором, системным инженером Linux от 3 лет.
2. Хорошие знания ALTLinux/RHEL/Debian или их производных, наличие сертификатов RHCSA, RHCE будет преимуществом.
3. Опыт работы с системами виртуализации KVM/Xen, Docker/LXC.
4. Знание и опыт работы c MySQL/PostgreSQL.
5. Понимание архитектуры OpenStack, опыт разворачивания в тестовой среде, реальный опыт будет преимуществом.
6. Понимание архитектуры распределенной системой хранения данных Ceph, опыт разворачивания в тестовой среде, реальный опыт будет преимуществом.
7. Понимание принципов работы основных сетевых протоколов и служб(IP, UDP, TCP, DNS, DHCP, FTP), модели OSI и стека протоколов TCP/IP.
8. Опыт написания скриптов(Bash/Python/Perl/Ruby).
9. Английский - чтение технической документации
10. Желание осваивать новое, умение работать в команде.
вот ты шустрый то)
Михаил
да
over IPv6 не пробовали?)
Александр
Igor
но с на сетевые bgp пришлось повесить еще ipv6 адрес
Михаил
Александр
Igor
Igor
а чем бы это помогло? так то можно
Jaroslav
Привет, есть ли подводные грабли, если включить на сетевых адаптерах SR-IOV, и нарезать порты сетевух на виртуальные адаптеры? Достаточно ли для счастья в сервере BMC порта, 1Gb адаптера для OOBM, и 2х25Gb адаептеров?