так не нужно енжин перезапускать или не нужно ям апдейт ?

Энжин пока не обновляем.

Перезапускаем его.

пошел на перезапуск

ok

[root@ovmgmt dbutils]# systemctl restart ovirt-engine.service [root@ovmgmt dbutils]# systemctl status ovirt-engine ● ovirt-engine.service - oVirt Engine Loaded: loaded (/usr/lib/systemd/system/ovirt-engine.service; enabled; vendor preset: disabled) Active: active (running) since Чт 2018-10-11 13:38:21 MSK; 15s ago Main PID: 19355 (ovirt-engine.py) CGroup: /system.slice/ovirt-engine.service ├─19355 /usr/bin/python /usr/share/ovirt-engine/services/ovirt-engine/ovirt-engine.py --redirect-output --syste... └─19397 ovirt-engine -server -XX:+TieredCompilation -Xms4081M -Xmx4081M -Xss1M -Djava.awt.headless=true -Dsun.r... окт 11 13:38:20 ovmgmt.ins.ru systemd[1]: Starting oVirt Engine... окт 11 13:38:20 ovmgmt.ins.ru ovirt-engine.py[19355]: 2018-10-11 13:38:20,458+0300 ovirt-engine: INFO _detectJBossV...l=36 окт 11 13:38:21 ovmgmt.ins.ru ovirt-engine.py[19355]: 2018-10-11 13:38:21,276+0300 ovirt-engine: INFO _detectJBossV...'[]' окт 11 13:38:21 ovmgmt.ins.ru systemd[1]: Started oVirt Engine. Hint: Some lines were ellipsized, use -l to show in full.

тщву 1 в состоянии Connecting

О

Хост в дауне ?

Ждем когда закончится поднятие энжина, поднятие роли SPM на живой ноде.

Выводим ноду битую в meintenance.

Что - бы не сделать шкоду работающим виртуалкам пройдем еще раз по здоровью гластера По всем томам. gluster volume heal <имя тома> info |grep "Status\|Number"

Нода в обслуживание ушла ?

Nfr jyf yt ds[jlbn d vfqyntyfyct

Так она не хочет в майнтенансе выходить

Опять Нон респонсиве

iptables-save с нее ?

Ее в ребут увело

видимо енжин

Отключаем временно на кластере fencing

Блин, это где ?

Compute/clusters

Свойства клайстера, раздел fancing.

нашел, сделал

Power Managment на нодах настроен ?

да

Как бы он ее в ребут отправил

Но, по крайней мере, виртуалки с нее слезли

Это был HARD Fancing через ILO видимо.

Загрузится нода.

В фаирволе ее обять от энжина блокируем.

Она долго ребутается. минут 5

Напиши карту томов гластера. Сервера и где какие брики.

Вслепую очень тяжело.

все ноды держат на себе по одному брику каждого тома.

Карту лучше дай. Ноды и что где лежит. В том числе и энжин.

нода1-iso node2-iso node3 - iso node1 - data node2 - data node3 - data node1-engine node2-engine node3-engine node1-export node2-export node3 - export

Engine на отдельной машине ?

engine yf jnltkmyjq vfibyt/ ukecnthyjt ty;by - ctqxfc yt bcgjkmpetncz

гластерное енжине сейчас не используется.

эта сцука встала в АП

Ну вот.

Я тебе очень рекомендую дотянуть все до одной версии.

Это не от того что фенсинг отключили на кластере?

Только делать это акуратно.

Это не от того что фенсинг отключили на кластере?

Нет.

т.е. можно сейчас его включать?

Это видимо все - таки где - то разные версии. Потому - что энжин node1 не сильно по VDSM понимает.

т.е. можно сейчас его включать?

Тут решать тебе.

Мне не совсем понятно как дотягивать до одной версии. Ладно, когда висят ящики, можно провести апдейт на нодах. а когда их нет, а версии разные ?

вручную при помощи yum update - тоже не всегда получается ... чего-то не понимаю.

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

/taskcleaner

вручную при помощи yum update - тоже не всегда получается ... чего-то не понимаю.

Все должно получиться.

Я от гластера хочу отказаться. он меня глюками своими уже задалбывать начал. уйти на iSCSI или NFS

ISCSI лучше не стоит.

Но от гластера лучше уйти.

Почему ? У меня 10Гбит сетка выделена специально под работу с хранилищем

Неужно НФС лучще iSCSI ?

Глюки у гластера конечно есть, но он тоже имеет правл на жизнь. Скоростей на нем больших не получишь, да и эксплуатационные человекочасы на него нужны больше, чем на тот - же CEPH.

Я - бы рекомендовал - бы тебе Ceph + NFS-Ganesha. А если нужны быстрые диски, то можно туда досыпать Ceph RBD. Головной боли будет меньша. Но на старте изучения Ceph, головной боли будет не мало. Но оно того стоит.

ERROR: S client not available

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

Неужно НФС лучще iSCSI ?

Сам по себе NFS - это точка отказа. Если идет речь о класическом NFS. Падает у тебя сервер NFS - падает весь кластер.

Эх FC бы......

Нужно стремиться к такой схеме, в которой не будет единой точки отказа.

Эх FC бы......

Поверь, там тоже хватает неприятностей :)

Это я понимаю, и в принципе к ней и движусь. но пока медленно

И себистоимость 1М очень высока, а при совместном доступе под большой нагрузкой иногда бывают неприятности.

Это я понимаю, и в принципе к ней и движусь. но пока медленно

Все получится !

Дотягивай версии пакетов обновлениями, не жди очередного отказа.

Ага, вот только памяти дадут еще. у меня не умещаются виртуалки с одной из нод на двух других по памяти.

SAN включается двумя контроллерами в два свича. Иначе два свича бессмысленны.

Не делай единые точки отказа !

Свич тут модульный, 2 мозгов, 2 блока питания, дублирующиеся модули. на самих нодах по 2 платы 2 порта 10Гбит, включенные в режиме бондинга портов с разных карт на разные модули коммутатора.

Ага, вот только памяти дадут еще. у меня не умещаются виртуалки с одной из нод на двух других по памяти.

Дефицит железа - это проблемма у всех есть. Всегда чего - то не хватает :)

этоя схематично рисовал, в принципе вместо нескольких по схеме - один модульный

Свич тут модульный, 2 мозгов, 2 блока питания, дублирующиеся модули. на самих нодах по 2 платы 2 порта 10Гбит, включенные в режиме бондинга портов с разных карт на разные модули коммутатора.

Это хорошо...

SAN подсистема - это немного другие свичи это уже Fibre Channel. Там свичи уже свои. Зонирование балансировка, multipath и т.д.

Просто взвесьте все, перед тем, как вкладывать в это "много" денег.

Стоимость высокая, оперативности, маштабируемости там нет. Только досыпка корзин и свичей.

Оно конечно проще, но... Тут уже решение за вами.

У меня в практике были случаи вылета корзин HP MSA полностью. Два контроллера, два БП не помогли. Одна корзинка по грозе, даже не понятно как, прошило UPS, UPS целый корзина труп, вместе с половиной винтов. Хотя нормализаторы, потом UPSы. Корзина оптическая.... Вот такое тоже бывает. Так что можно наверное корзину тоже считать точкой отказа :) Смешно, но вот...

Да и на больших проектах уже давно SDS - это уже базовый уровень.

С SAN свичами , я слава богу справляюсь ? и есть у меня одна фабрика незадействованная.

Сеф - читал про него, но пока много народу сходится к тому что сырой еще... мол нежелательно в прод.

Тогда избавляйтесь от гластера и переходите полностью на SAN. Уже жить будет попроще.

Сеф - читал про него, но пока много народу сходится к тому что сырой еще... мол нежелательно в прод.

Уже можно. Много уже где в проде он работает.

Ну вот, буду сейчас что-то мутить под эту тему. ОГРОМНОЕ спасибо за помощь!

Да не за что.

Сеф - читал про него, но пока много народу сходится к тому что сырой еще... мол нежелательно в прод.

о госпаде, еще один о сырости

над вам в чат ceph-a сходить

Оооооо...... Там желание им заниматься вмиг отобьют.