Дело в том, что нет доступа к настройкам телефона планшета, то есть нет доступа к стандартным настройкам, о которых вы говорите. Поэтому и возник вопрос.
rionnagel, 2 сервера подключены по 10G, третий из-за отсутствия 10G карты подключен через 2G (LACP).
Сейчас вручную переделал разделы LVM под брики, без thin provisioning, посмотрим как будет себя вести gluster.
Больше скажу, размер данных на примонтированных дисках бриков на всех трех хостах равен!
Одинаковый вывод df-h:
/dev/mapper/RHGS_vg_data-data_lv 498G 197G 301G 40% /gluster_bricks/data
Проблема найдена. Но, я не знаю откуда ноги растут. Данные записаны на volume с помощью стандартных механизмов OVIRT. Все три брика находятся в онлайне, по моему мнению, все должно быть одинаково, replicated, нет арбитров. OVIRT показывает, что брики синхронны, каждый заполнен на 32%.
А в от вывод lvs -a с трех хостов:
LV VG Attr LSize Pool Origin Data%
Хост1: data_lv RHGS_vg_data Vwi-aot--- 497,50g data_lv_pool 54,76
Хост2: data_lv RHGS_vg_data Vwi-aot--- 498,30g data_lv_pool 74,65
Хост3: data_lv RHGS_vg_data Vwi-aot--- 497.30g data_lv_pool 54.52
Хост 2 кандидат на начало проблем топика. Почему на нем места отъелось больше в полтора раза?? Объем бриков 500Гб. Если скопировать на раздел еще 150 (это позволяет объем), Хост3 вывалится в вышеуказанные проблемы. Что с ним не так??
Да, разобрался. Проблема с thin provisioning. Thin provisioning pool в LVM, в котором находится раздел с данными брика заполняется на 100% и начинаются проблемы. Похоже неразрешимые.
Теперь, самое интересное, как сделать так, чтобы он не заполнялсся настолько, чтобы это начинало приводить к проблемам с ФС. Это же ненормально?! Когда стоит рабочая система настроенная, объем данных не превышает размера выделенного тома, и тут на тебе.
Нужна помощь специалистов по glusterfs. Чего-то я не понимаю из основ. И не пойму в какую сторону смотреть.
Добавлю: да, проблема 100% с thin provisioning. Пул забит на 100%. При этом с тома все данные были удалены (перенесены). Но, т.к. этот хост был в оффлайне по причине ошибок ФС, на его брике данные остались. Данных там примерно 50% от размера брика. Сейчас он в онлайне, но данные с него не удаляются! Хотя починен fxs_repair. Ошибок пока нет, почему брик не приводится в соответствие другим? Где replicated? Как заставить сделать это его вручную? reset-brick и heal data full ни к чему не приводят!
Вообще непонятно, это нормальное поведение glusterfs? Неужели он не должен удалить удаленные с тома данные с данные с брика, который был отключен в момент удаления (привести в соответствие с другими (том REPLICATED)? Уже долгое время висит и ничего не делает, что за странная штука?
Добавлю, нарыл кое-что в логах. Похоже проблема с thin provisioning. Вот такие записи перед началом повальных ошибок с ФС:
Jan 19 17:03:40 srv01 kernel: device-mapper: thin: 253:4: reached low water mark for data device: sending event.
Jan 19 17:03:40 srv01 kernel: device-mapper: thin: 253:4: switching pool to out-of-data-space (queue IO) mode
Но, так как с thin provisioning на LVM дела не имел, буду читать..
ubx7b8, Да, проблема точно не связана с ovirt-provider-ovn. С ним разобрался, настроил, все работает, никаких ошибок. Но вот основную проблему решить так и не удалось. Писал даже на ovirt.org, единственное, что подсказывает уважаемый Simone Tiraboschi:
vm: up refers to vm status at virt level polling a local vdsm, health: bad refers instead to a live check on the engine portal over http.
Bad name resolution or network routing issues can cause this. I'd suggest to check if everything is fine on network side.
То есть, какая-то проблема с сетью.
Но, никак не могу найти проблему. Сетевые настройки на обеих хостах идентичны (ip конечно разный). Все нормально резолвится, пингуется и т.д. Уже обновил до последней версии ветки 4.3, те же самые проблемы. Куда рыть - непонятно. Получается, что когда HostedEngine запущен на проблемном хосте (например вручную туда ее можно мигрировать), определяется статус как state=EngineStarting. Посмотрю еще engine.log Если что-то там есть интересное, выложу сюда.
Я же говорю, проблема однозначно не в DNS. Ping и Traceroute проходят спокойно и непринужденно. Определение IP по адресу никаких проблем не вызывает. А вот сайт не открывается и по сей день! Открывается только через левые прокси/анонимайзеры, Opera Turbo и т.д. То есть блокировка идет именно по имени сайта. Вот такие дела. Кому помешал?
Нет, настроек нет. Добыть их конечно не проблема, как и wireshark'ом посмотреть, что там происходит, но боюсь, не поможет.
Про сквид это я так, пример привел на всякий случай. Уже несколько провайдеров и несколько разных подключений перепробовал, с телефона (ов) например, та же беда. Не открывается сайт и все тут. А сквид тут только в одном месте, на работе, и вот так ругается.
Так дело-то совсем не в этом. DNS отрабатывает более чем, но по имени сайта не ходит ни один браузер. Сайт открывается, ничего не происходит при этом. Даже кэш сквида дает интересную ошибку (минут через 15 после ожидания):
Произошла следующая ошибка:
Превышено время ожидания ответа.
Система сообщила:
[No Error]
Превышено время ожидания ответа во время чтения данных из сети. Сеть или сервер не работают либо перегружены. Пожалуйста, повторите запрос.
Вот [No Error] вообще в первый раз вижу.
А если в адресную строку вбить IP-адрес, то Хабр уже сам ругается, как описано выше, что не хорошо так заходить.
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.