Помните, я рассказывал историю про проблемы в СУБД, когда бились ни с того ни с сего таблицы в MySQL? Уже почти год прошёл 😱 Как время летит. Вот эти заметки:

◽️первая ошибка
◽️её анализ на восстановленной копии виртуалки
◽️повторение через полгода

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

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

В итоге я заказал новый сервер и переехал туда. Ошибка больше не повторялась. Вспомнил об этой истории на днях, когда один из читателей попросил совета. Не буду всё рассказывать, передам только суть.

Арендовали новый ProLiant DL360 Gen10 железным рейдом. Массив средствами контроллера собирать не стали, прокинули диски напрямую. Установили туда Proxmox на ZFS. Настроили виртуалки. Периодически гипервизор начал падать с kernel panic.

Долго разбирались сами, крутили настройки. Гуглили ошибки и мучали ИИ. То же самое делал хостер. В итоге ничего не помогло. Падать стали реже, но всё равно раз в несколько дней зависание. Вопрос, что с этим делать.

Я посоветовал следующее:

1️⃣ Сервер арендованный. Первое, что сделал бы я - заменил его. Либо просто договорился с хостером о прозрачной замене, либо, если он не согласен, дождался бы окончания аренды (она обычно помесячная) и заказал заново другой. По этой причине не люблю оплачивать сразу больше, чем на месяц. У тебя сужается пространство для манёвра.

2️⃣ Если тип виртуализации не критичен, заменил бы гипервизор. Вместо KVM взял бы ESXI или Hyper-V. Рейд собрал бы средствами железного контроллера.

Железо иногда глючит, даже новое брендовое. Хоть и не часто, но такое бывает. И мой пример с СУБД как раз из этой серии. И я с этим сталкивался не раз. В дополнение к этому глючит иногда связка железа с конкретной системой. Можно много времени потратить на решение проблемы в текущем железе и софте и не решить её. Самое простое в этом случае - сначала заменить железо, если не поможет - гипервизор. Может так оказаться, что больше ничего делать и не придётся. А перекинуть виртуалки дело несложное, тем более если система ещё не в проде.

Даже если проблема не с железом, то потом уже спокойно без задних мыслей решаем последовательно проблему дальше. Если же при таких ошибках не поменять железо, а пытаться решить проблему прошивками и настройками, то даже если на первый взгляд поможет, нет гарантий, что не стрельнет через месяц-два. Эти проблемы бывают сильно растянуты по времени. Надо по возможности сразу сужать проблемную область.

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

———
ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX

#железо #совет