выпадение устройства nvme - I / O 0 QID 0 timeout,контроллер отключен
У нас всего 6 серверов Supermicro ( или очень похожая спецификация), За последние две недели одному из них случайным образом выпадал диск NVMe из-за:
[66.856719] nvme 0000: 03: 00.0: I / O 0 QID 0 timeout, отключить контроллер
[66.957911] nvme 0000: 03: 00.0: Ошибка идентификации контроллера (-4)
[66.957961] nvme 0000: 03: 00.0: Удаление после сбоя датчика состояние: -5
Мы пробовали:
- Замена диска
- Замена кабелей NVMe
- Замена контроллера NVMe (материнская плата)
- Замена объединительной платы
- При переходе с ядра 4.5.0 на 4.4.2 задано последние изменения в подсистеме хранения данных
- Обновление микропрограмм диска и материнской платы
- Замена материнской платы
Таким образом, это, по сути, совершенно новый сервер, за исключением того, что мы не выполняли переустановку - почему? Потому что я хочу понять проблему, и если переустановка исправит ее, мы никогда не узнаем, почему это происходит на этом компьютере, а не на другом нашем 5.
- При работе диска не сообщается об ошибках SMART или nvme-cli.
Если диск вставлен в другой отсек, он работает нормально, и любой диск, замененный в этот отсек, в конечном итоге выходит из строя / выходит из строя.
CentOS 7 (установлены последние исправления)
- Ядро 4.5. Подключение к storage.googleapis.com | 74.125.133.128 |: 443 ... сбой: время ожидания подключения истекло.
Как мне убедиться, что служба может загружать файлы из Интернета?
My cloud-config
#cloud-config coreos: units: - name: bootstrap.service command: start content: | [Unit] Description=Bootstrap instance After=network-online.target Requires=network-online.target [Service] Type=oneshot RemainAfterExit=true ExecStart=/usr/bin/mkdir -p /tmp/kubernetes-staging ExecStart=cd /tmp/kubernetes-staging ExecStart=/bin/sh -c "cd /tmp/kubernetes-staging && wget https://storage.googleapis.com/experimentalberlin/staging.tar.gz && tar xf staging.tar.gz" ExecStart=/tmp/kubernetes-staging/worker/bootstrap.sh [Install] WantedBy=local.target
Я бы сделал несколько шагов тактика устранения неполадок. Прошу прощения за дополнительную информацию и излишние объяснения, всем здесь, в CoreOS, приходится иметь дело с этим от меня. ;)
Прежде всего, вы хотите убедиться, что URL-адрес, с которого вы пытаетесь загрузить, можно получить изнутри кластера. В настоящее время я не вижу причин, по которым это должно быть не , поскольку я смог получить его (в стороне, как правило, лучше не помещать материал закрытого ключа в общедоступный tarball. в этом случае, хотя он все еще не оптимально , может быть лучше включить эти активы либо в пользовательские данные , либо, по крайней мере, защитить архив с помощью симметричного шифрования . )
Поскольку cloud-init запускается после того, как сеть подключена к сети, этого должно быть достаточно (служба метаданных находится по адресу http://169.254.169.254 , и поэтому облачная конфигурация не может быть получена до тех пор, пока после того, как сеть будет в сети.) Это означает, что вероятные виновники связаны с временными проблемами сети или другими деталями.
Когда я пытаюсь пройти через это, я получаю следующую ошибку:
core@rbtest ~ $ journalctl -u bootstrap.service
-- Logs begin at Wed 2016-04-13 17:31:35 UTC, end at Wed 2016-04-13 17:33:09 UTC. --
Apr 13 17:31:47 rbtest.c.coreos-support.internal systemd[1]: [/etc/systemd/system/bootstrap.service:10] Executable path is not absolute, ignoring: cd /tmp/kubernetes-staging
Apr 13 17:31:47 rbtest.c.coreos-support.internal systemd[1]: Starting Bootstrap instance...
Apr 13 17:31:47 rbtest.c.coreos-support.internal sh[1074]: --2016-04-13 17:31:47-- https://storage.googleapis.com/experimentalberlin/staging.tar.gz
Apr 13 17:31:47 rbtest.c.coreos-support.internal sh[1074]: Resolving storage.googleapis.com... 209.85.200.128, 2607:f8b0:4001:c08::80
Apr 13 17:31:47 rbtest.c.coreos-support.internal sh[1074]: Connecting to storage.googleapis.com|209.85.200.128|:443... connected.
Apr 13 17:31:48 rbtest.c.coreos-support.internal sh[1074]: HTTP request sent, awaiting response... 200 OK
Apr 13 17:31:48 rbtest.c.coreos-support.internal sh[1074]: Length: 4722 (4.6K) [application/x-tar]
Apr 13 17:31:48 rbtest.c.coreos-support.internal sh[1074]: Saving to: 'staging.tar.gz'
Apr 13 17:31:48 rbtest.c.coreos-support.internal sh[1074]: 0K .... 100% 47.4M=0s
Apr 13 17:31:48 rbtest.c.coreos-support.internal sh[1074]: 2016-04-13 17:31:48 (47.4 MB/s) - 'staging.tar.gz' saved [4722/4722]
Apr 13 17:31:48 rbtest.c.coreos-support.internal systemd[1]: bootstrap.service: Main process exited, code=exited, status=203/EXEC
Apr 13 17:31:48 rbtest.c.coreos-support.internal systemd[1]: Failed to start Bootstrap instance.
Apr 13 17:31:48 rbtest.c.coreos-support.internal systemd[1]: bootstrap.service: Unit entered failed state.
Apr 13 17:31:48 rbtest.c.coreos-support.internal systemd[1]: bootstrap.service: Failed with result 'exit-code'.
Подсказка здесь - строка:
bootstrap.service: Main process exited, code=exited, status=203/EXEC
Это сообщение сообщает вам, что при запуске самого скрипта возникла проблема. Копаться в этом имеет смысл, поскольку, когда я смотрю на верхнюю часть этого сценария оболочки, нет shebang , сообщающего systemd , как запускать исполняемый файл (в данном случае это все Bourne Shell / Bourne-Again Shell совместимые команды, поэтому shebang, вероятно, должен быть либо #! / Bin / sh , либо #! / Bin / bash .) Добавление shebang должно решить эту проблему.
Некоторые другие второстепенные гниды:
при использовании
wgetукажите место загрузки:wget -O / tmp / kubernetes-staging / staging. tar.gz https://storage.googleapis.com/experimentalberlin/staging.tar.gzпри расширении вашего архива вы можете вывести его в определенное место с помощью
-C:tar xf /tmp/kubernetes-staging/staging.tar.gz -C / tmp / kubernetes- постановка /
Это позволяет вам разделить их на соответствующие параметры ExecStart = , что обеспечивает дополнительное протоколирование.
- Поскольку большинство этих команд являются предварительными для выполнения фактического
начальной загрузки. sh, я бы изменил все параметрыExecStart =(за исключением последнего) наExecStartPre =.