Re: [Comm] Непонятное поведение p9

Re: [Comm] Непонятное поведение p9

[Pavel Isopenko]

Добрый.

06.09.2019 14:25, Yuri Khachaturyan пишет:
> Причина была - systemd ругался на то, что у меня /usr в отдельном разделе
> диска и он еще не смонтировался.
Его можно понять. А причину поместить именно usr в отдельном разделе не 
подскажете? Может быть есть решение получше.
Бывают очевидные поводы отделить home, var, srv, даже 
/var/lib/libvirt/images иногда. Но usr?
-- 
С уважением, *Павел Исопенко*
тел. +79165329582
email: master@pauli.ru
XMPP: pavelri@jabber.credoaudit.ru

Re: [Comm] Непонятное поведение p9

[Pavel Isopenko]

06.09.2019 15:19, Anton Gorlov пишет:
> С вероятностью 99% у Вас помирают диски на сервере. Как можно быстрее
> копируйте/бекапьте что ещё можно с сервера вытащить и бегом за новыми
> дисками.

Присоединяюсь. Добавлю, что старые диски можно ещё попробовать прогнать 
через whdd, который объективно покажет что и как. Может статься козлит 
один из них  а не все, тогда можно будет сэкономить. Да и изучить вопрос 
всяко не помешает.

Бэкап (в смысле экстренная эвакуация) - однозначно, затем как можно 
более полная ревизия железа.  Если окажется исправно можно будет заново 
аккуратно установить и пользоваться дальше. Хотя вот ещё: пять лет назад 
достался. А всего сколько ему? Может реально пора, вне зависимости от 
состояния?

И - нет, собственно p9 так себя не ведёт. У меня alt-p9-server из 
стартеркитов уже в продакшене. Ничего такого не наблюдалось.


-- 
С уважением, *Павел Исопенко*
тел. +79165329582
email: master@pauli.ru
XMPP: pavelri@jabber.credoaudit.ru

Re: [Comm] Непонятное поведение p9

[Pavel Isopenko]

06.09.2019 15:27, Yuri Khachaturyan пишет:
>           Write Cache                        : Enabled (write-back)
>           FRU                                : None
>           S.M.A.R.T.                         : No
>           S.M.A.R.T. warnings                : 0
>           NCQ status                         : Disabled
>
>
> И так по всем 6 дискам выдает. Также на уровне биоса контроллера - ни
> единой ошибки нет по дискам. Откуда такое предположение, что это именно
> диски умирают?

Потому что до жути похоже на проблему именно дисковой подсистемы. Но что 
конкретно диски действительно не факт, может быть ещё проблема 
контроллера. В первую очередь

          Write Cache                        : Enabled (write-back)

BBU на контроллере точно жив? Если есть хоть малейшее сомнение, а пять 
лет для АКБ на BBU это срок, применение отложенной записи не 
рекомендуется категорически. Я бы сразу переставил на  Disabled 
(write-thru).

-- 
С уважением, *Павел Исопенко*
тел. +79165329582
email: master@pauli.ru
XMPP: pavelri@jabber.credoaudit.ru

Re: [Comm] Непонятное поведение p9

[Sergey]

On Friday 06 September 2019, Yuri Khachaturyan wrote:

> Первый раз перезагрузка не помогла, пришлось переустанавливаться.
> Причина была - systemd ругался на то, что у меня /usr в отдельном
> разделе диска и он еще не смонтировался. 

Что, опять? Чинили же вроде?

-- 
С уважением, Сергей.

Re: [Comm] Непонятное поведение p9

[Sergey]

On Friday 06 September 2019, Pavel Isopenko wrote:

> Бывают очевидные поводы отделить home, var, srv, даже 
> /var/lib/libvirt/images иногда. Но usr?
 
Вот и разработчики systemd недоумевают: как это так можно
посметь делить ФС не так, как они задумали.

-- 
С уважением, Сергей.

Re: [Comm] Непонятное поведение p9

[Sergey]

On Monday 09 September 2019, Yuri Khachaturyan wrote:

> А есть ли вообще где-нибудь принятые нормы создания ФС?

Всё весьма условно: https://www.altlinux.org/РазбиениеДиска

-- 
С уважением, Сергей.

Re: [Comm] Непонятное поведение p9

[Michael Shigorin]

On Wed, Nov 20, 2019 at 10:07:24PM +0300, Yuri Khachaturyan wrote:
> Есть мысль в неисправности контроллера (Intel ServerRAID 8K) или же
> все-таки проблема в драйвере aacraid? Как это можно диагностировать?
> В логах ни слова о проблеме нет.
> Мои мысли следующие на этот счет:
> 1. продуть разъемы SATA от пыли сжатым воздухом.
> 2. попробовать собрать mdraid вместо аппаратного (а вдруг)
> 3. заменить ОС на FreeBSD и посмотреть что будет.
> Ваше мнение?

4. update-kernel -t un-def (или из p8, если там работало).

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [Comm] Непонятное поведение p9

[Павел Исопенко]

20.11.2019 22:07, Yuri Khachaturyan пишет:
> В продолжение этой темы.
> Заменил диски на новые и 100% рабочие (тестировал каждый диск перед 
> установкой посекторно).

Это правильно.

> Сервер проработал 1.5 суток и опять та же история - просто отвалился 
> /dev/sda и система не дает ни залогиниться локально, ни 
> естесственно удаленно.

Все признаки указывают на аппаратную неисправность. Ни p9, ни p8 и 
никакая другая p* так себя не вели. Никогда. Я бы начал с замены блока 
питания. Далее всё - компонент за компонентом. А лучше сервер целиком, 
так продуктивнее. Старый разобрать на запчасти. Даже если дело в 
драйвере и старый сервер исправен, мы ничего не теряем, комплект ЗИП 
лишним не будет.

> Есть мысль в неисправности контроллера (Intel ServerRAID 8K) или же 
> все-таки проблема в драйвере aacraid? Как это можно диагностировать?

Подменой контроллера на заведомо исправный. Такой найдётся?

> 
> В логах ни слова о проблеме нет.

Когда подсистема хранения останавливается внезапно, куда писать лог?


> 1. продуть разъемы SATA от пыли сжатым воздухом.

Не стоит усилий. Просто остановить на несколько минут сервер и 
вынуть-вставить разъёмы. Любая пыль неизбежно будет сдвинута с пятна 
контакта. Кстати, а откуда в серверной вообще пыль? Что с фильтрами и 
вообще с климат-контролем? А как насчёт наддува корпуса, что с 
терморежимом и схемой теплопереноса, всё ли исправно?

> 2. попробовать собрать mdraid вместо аппаратного (а вдруг)

Можно. Как-то расследовал похожий случай. Закончилось тем что RAID 
попросту развалился у меня в руках - конструктивный дефект, заложенный 
изготовителем восемь лет тому назад. Уже год сервер доживает с 
программным RAID5, и нет проблем.

> 3. заменить ОС на FreeBSD и посмотреть что будет.

Уже известно. Ничего хорошего. Но попробовать можно. Опыт, как-никак.

> 
> Ваше мнение?

Новый сервер, старый на запчасти. И не жалеть. Хороший так себя не 
поведёт, а плохого не жалко.


-- 
С уважением, Павел Исопенко
тел. +79165329582
email: master@pauli.ru
XMPP: pavelri@jabber.credoaudit.ru

Re: [Comm] Непонятное поведение p9

[Sergey]

On Thursday 21 November 2019, Павел Исопенко wrote:

> > В логах ни слова о проблеме нет.
> 
> Когда подсистема хранения останавливается внезапно, куда писать лог?
 
Кстати, можно на соседний сервер лить параллельно.

-- 
С уважением, Сергей
a_s_y@sama.ru

Re: [Comm] Непонятное поведение p9

[alexei]

----- Исходное сообщение -----
> От: "Yuri Khachaturyan" <yukh@yukh.ru>
> Кому: "ALT Linux Community general discussions" <community@lists.altlinux.org>
> Отправленные: Четверг, 21 Ноябрь 2019 г 16:10:03
> Тема: Re: [Comm]	Непонятное поведение p9

> чт, 21 нояб. 2019 г. в 00:07, Sergey < [ mailto:a_s_y@sama.ru | a_s_y@sama.ru ]
> >:
> 
> 
> On Thursday 21 November 2019, Павел Исопенко wrote:
> 
>> > В логах ни слова о проблеме нет.
>> 
>> Когда подсистема хранения останавливается внезапно, куда писать лог?
> 
> Кстати, можно на соседний сервер лить параллельно.
> 
> Пока не нашел как это настроить в случае с systemd и journal.

Когда сыпется железо, достаточно следить за dmesg. Как-то вот так:

#!/bin/sh

# set log level for kernel messages
dmesg -n 8

modprobe configfs
modprobe netconsole

# 'netconsole' dir is auto created if the module is loaded
mkdir /sys/kernel/config/netconsole/target1
cd /sys/kernel/config/netconsole/target1/

# set local IP address
echo IP_LOCAL > /sys/kernel/config/netconsole/target1/local_ip
# set destination IP address
echo IP_LOGSERVER > /sys/kernel/config/netconsole/target1/remote_ip
# set local network device name (find it trough ifconfig, examples: eth0, eno1, wlan0)
echo IFNAME > /sys/kernel/config/netconsole/target1/dev_name
# find destination MAC address
arping -I $(cat /sys/kernel/config/netconsole/target1/dev_name) \
          $(cat /sys/kernel/config/netconsole/target1/remote_ip) -f | \
          grep -o ..:..:..:..:..:.. > /sys/kernel/config/netconsole/target1/remote_mac

echo 1 > /sys/kernel/config/netconsole/target1/enabled

На стороне IP_LOGSERVER запустить что-то типа

nc -u -l 6666 >> /var/log/netconsole.log

и ждать

Re: [Comm] Непонятное поведение p9

[Pavel Isopenko]

21.11.2019 11:09, Yuri Khachaturyan пишет:
> ср, 20 нояб. 2019 г. в 23:44, Павел Исопенко <master@pauli.ru 
> <mailto:master@pauli.ru>>:
>
>
>      Далее всё - компонент за компонентом.
>
> Аппаратную неисправность чего? БП? Или все таки контроллер?

Материнская плата? Даже один конденсатор ценою доллар за пачку способен 
натворить то, что описано выше по треду. Или микротрещина, расширяющаяся 
при прогреве. Сколько таких матерей выбросил за свою карьеру...

> Вариант с заменой сервера не подходит ввиду того, что сервер - мой 
> личный, не корпоративный и я не готов вкладывать в него на сегодняшний 
> день серьезные деньги.

А если вариант с переходом на полностью виртуальную инфраструктуру? 
Начальных вложений ноль. Подробности ниже.

> Увы, но что имею, тем и приходится пользоваться. Цель - реанимировать 
> именно этот сервер.

Точно это цель? Реален шанс побить дохлую лошадь.

> Новые сервера буду запускать в строй только тогда, когда от них будет 
> хоть какая то прибыль.

Да. По умолчанию считается что цель - именно прибыль, а не реанимация 
антиквариата. Если не хобби, разумеется (тогда молчу).

Совсем недавно сразу несколько крупных провайдеров запустили свои 
проекты IaaS. Ну как недавно? Больше года, так что некоторые выводы уже 
есть. Главный из них в том, что альтовые стартеркиты, включая p9 - 
подходят, и подходят хорошо. У меня с февраля уже месят данные в режиме 
опытной эксплуатации (это когда нагрузка реальная, производственная, 
просто не все приложения там) - и ни малейшего чиха. Вот и 
заинтересовало, откуда это внезапно у p9 непонятное поведение.

Плюс IaaS - ресурсы можно забирать плавно, по мере поступления прибыли. 
WestCall, говорите? Я бы поинтересовался у них по поводу IaaS.

> -- 
> С уважением, *Павел Исопенко*
> тел. +79165329582
> email: master@pauli.ru
> XMPP: pavelri@jabber.credoaudit.ru

Re: [Comm] Непонятное поведение p9

[Sergey]

On Thursday 21 November 2019, Yuri Khachaturyan wrote:

> > Кстати, можно на соседний сервер лить параллельно.
> 
> Пока не нашел как это настроить в случае с systemd и journal.

Если сходу, то можно так: https://www.altlinux.org/Journald#Возврат_syslog

-- 
С уважением, Сергей.

Re: [Comm] Непонятное поведение p9

[Павел Исопенко]

02.12.2019 19:13, Yuri Khachaturyan пишет:
> Диагностика показала, что у контроллера умерла Backup Battery. Заказал 
> новую, пока ее доставляют - продолжаю эксперименты.
> 
> Пересобрал массив на RAID5 из 6 дисков по 1ТБ с полностью отключенным 
> write-cache.
> Установил ALT Server 8.2 с ядром un-def. С пятницы все работает без 
> сбоев, правда подтормаживает файловая система.

Вопрос насколько подтормаживает.

> arcconf говорит, что батарейка живая, но визуально видно, что она вздулась.

Врёт? А вольтметром? Li-Ion c маркировкой 3,7В это 3,6 в номинале, и 
если меньше 2.8 - в мусор. Хотя, если вздулась, наверное и прибор  уже 
не нужен.

> 
> Вопрос - может ли мертвая батарейка таким образом влиять на контроллер,

Только инженер, делавший контроллер, может ответить. По опыту для начала 
просто отключить, дабы ничего не шунтировала. Если есть шлейф с разъёмом 
- снять с колодки, если контакты жёсткие - снять АКБ совсем. А перед 
этим сфотографировать, чтобы поставить как было когда придёт запчасть.

> что он просто теряет массив на какое-то время?
> 
Непонятно. Это как? Что в логах? Потерять накопитель это же сколько 
визгу должно быть?

Есть у меня один такой сервер, четыре года уже со снятой BBU АКБ - и 
ничего. Пока живая было совсем хорошо, когда сдохла пошли сбои. 
Догадался АКБ отключить и выбросить, живём без проблем дальше. 
write-cache разумеется отключен.

А вот дисковые полки, к примеру, без исправного BBU никак не хотят, 
приходится удовлетворять. Так что оно по-всякому бывает.

-- 
С уважением, Павел Исопенко
тел. +79165329582
email: master@pauli.ru
XMPP: pavelri@jabber.credoaudit.ru

Re: [Comm] Непонятное поведение p9

[alexei]

----- Исходное сообщение -----
> От: "Yuri Khachaturyan" <yukh@yukh.ru>
> Кому: "ALT Linux Community general discussions" <community@lists.altlinux.org>
> Отправленные: Вторник, 3 Декабрь 2019 г 16:29:06
> Тема: Re: [Comm]	Непонятное поведение p9

> вт, 3 дек. 2019 г. в 00:40, Павел Исопенко < [ mailto:master@pauli.ru |
> master@pauli.ru ] >:
> 
> 02.12.2019 19:13, Yuri Khachaturyan пишет:
>> Диагностика показала, что у контроллера умерла Backup Battery. Заказал
>> новую, пока ее доставляют - продолжаю эксперименты.
>> 
>> Пересобрал массив на RAID5 из 6 дисков по 1ТБ с полностью отключенным
>> write-cache.
>> Установил ALT Server 8.2 с ядром un-def. С пятницы все работает без
>> сбоев, правда подтормаживает файловая система.
> 
> Вопрос насколько подтормаживает.
> 
> 
> Под нагрузкой в 200Мбит/сек (сеть) и записи (качает торренты для теста) -
> довольно заметно.

Это особенности RAID 5. На запись это весьма печальные массив. Набортный write-cache
контроллера это безобразие как-то сглаживает.

Re: [Comm] Непонятное поведение p9

[Michael Shigorin]

On Tue, Dec 03, 2019 at 11:29:06AM +0300, Yuri Khachaturyan wrote:
> > > Пересобрал массив на RAID5 из 6 дисков по 1ТБ с полностью
> > > отключенным write-cache.  Установил ALT Server 8.2 с ядром
> > > un-def. С пятницы все работает без сбоев, правда
> > > подтормаживает файловая система.
> > Вопрос насколько подтормаживает.
> Под нагрузкой в 200Мбит/сек (сеть) и записи (качает торренты
> для теста) - довольно заметно.

Юр, я ж тебе сколько раз говорил -- под запись пятёрка непригодна,
поскольку на каждый чих затрагивает больше шпинделей, чем 1/10,
и тем лишь добавляет суммарно необходимые от дисков IOPS.

RAID5/6 сам по себе годится, когда надо много хранить,
чаще читать, чем писать, и не очень-то параллельно.

Ну и на шести дисках пятёрка с учётом тенденции дисков
к double fault (когда один уже посыпался, следующий из
той же партии может быть уже на грани и ссыпаться как
раз при пересборке массива по замене выпавшего) --
опять же не под нагрузку, а под архив разве что.
На восьми уже совсем не стоит, нужен RAID6 с двумя
избыточными.

Сам в целом сильно предпочитаю RAID10.

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [Comm] Непонятное поведение p9

[Michael Shigorin]

On Tue, Dec 03, 2019 at 01:18:06PM +0300, Yuri Khachaturyan wrote:
> Да, Миша, я в курсе обо всем этом. Раньше этот сервер именно
> так и жил на RAID10, но терять 3ТБ на сегодня не очень хочется.
> Но если уж не заставлю RAID5 работать стабильно, то придется....

Ну я не про стабильность говорил, а про производительность
и надёжность.  Но алгоритмы тоже разные (в 5/6 добавляется
XOR), так что в принципе и стабильность может быть разной.

> И да, вариант с mdraid не сработал вообще никак - работает
> крайне нестабильно, постоянно путает и теряет массивы :(

Вот это мне с твоих слов вообще непонятно оказалось...

> На днях попробую поставить в сервер дополнительный SATA
> контроллер (если решу вариант с питанием для SSD диска)
> и установлю систему на отдельный диск.

Там какой SATA DoM воткнуть точно некуда?
(или хоть вообще PATA)

Для них бывает достаточно одолжить +5V из USB набортного.

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [Comm] Непонятное поведение p9

[Pavel Isopenko]

03.12.2019 13:39, Yuri Khachaturyan пишет:

> Платформа IBM System x3650, она заточена строго под использование IBM 
> ServerRaid 8k - он в нее устанавливается даже не на PCI-E шину, а 
> сделан в виде отдельной планки, похожей на DIMM памяти.

Вот что насторожило - с год назад у меня на руках сдох контроллер в 
подобном же конструктиве (мать ASUS KGPE-D16). Тоже вроде отдельной 
планки в специальном разъёме, просто задымился. Так вот полгода перед 
кончиной вёл себя точно так же, как описано выше. Просто в точности.

Вскрытие показало конструктивный недостаток, заложенный производителем: 
радитор не был привинчен, он был приклеен. Вдобавок служил для фиксации 
RAID в разъёме, и спустя годы по термоинтерфейсу пошла (предположительно 
усталостная) трещина. Финал очевиден.

-- 
С уважением, *Павел Исопенко*
тел. +79165329582
email: master@pauli.ru
XMPP: pavelri@jabber.credoaudit.ru