Настройки стали только для чтения: почему место, где они живут, устроено иначе
Если вы не можете записать даже под root, дело не в заполненном диске. Proxmox не хранит настройки в обычном каталоге, и это место отказывает в записи намеренно.
AtlasPVE ·
Эта статья отвечает на
- proxmox etc pve только для чтения
- proxmox не удаётся записать в etc pve
- proxmox pmxcfs что это
- где находятся файлы конфигурации vm proxmox
- proxmox расположение файла конфигурации
Вы пытаетесь изменить файл, и в доступе отказано. Вы root. На диске есть место. И всё равно записать не получается.
Здесь ничего не сломалось. То, на что вы смотрите, не обычный каталог, и он отказывает в записи намеренно.
Место, где живут настройки, не каталог
Proxmox хранит конфигурации машин, описания хранилищ, правила брандмауэра и задания резервного копирования в одном месте. Оно выглядит как файловая система, у него есть папки и файлы, но за ним стоит небольшая база данных, и эта база копируется на каждый узел кластера.
Причина проста: все серверы кластера обязаны видеть одно и то же описание машины. Если вы собираетесь перенести машину с одного сервера на другой, принимающая сторона уже должна знать, как эта машина описана. Будь конфигурация обычным файлом на диске одного сервера, остальные о ней бы не знали.
У такого устройства три следствия, и все три встречаются в повседневной работе.
Следствие первое: без большинства запись отклоняется
Если сервер не видит большинства кластера, запись закрывается. Чтение продолжает работать, запись прекращается.
Это не поломка, это решение. Если бы сеть разделилась надвое и обе половины могли писать, у одной и той же машины появились бы два разных описания. Когда сеть вернётся, никто не сможет сказать, какое верное, и способа их объединить не будет. Вместо этого система выбирает так: сторона, оказавшаяся в меньшинстве, перестаёт писать.
Как считается большинство в кластере и почему установки из двух серверов неудобны, разобрано в отдельной статье. Здесь остаётся добавить лишь одно: именно так это правило большинства ощущается на практике, внезапной невозможностью записать.
Следствие второе: та же конструкция работает и на одиночном сервере
Даже без кластера эта конструкция работает. Одиночный сервер сам по себе является большинством, поэтому обычно ничего не ломается.
Но если служба, обеспечивающая эту конструкцию, нездорова, тот же симптом вы увидите и на одиночном сервере. То есть «у меня нет кластера, со мной такого не случится» неверно.
Есть и менее известный путь: база данных за этой конструкцией лежит на локальном диске. Когда локальный диск заполняется, запись не проходит, и вам кажется, что вы не можете изменить настройки. Симптом на стороне настроек, причина на стороне хранилища.
Следствие третье: всё, что вы туда пишете, уходит ко всем
Варианта «изменю только на этой машине» не существует. Написанное туда доходит до каждого узла кластера.
Классическая ошибка, которую делают, не зная этого, состоит в пробном изменении на одном узле в предположении, что остальных оно не касается.
Ещё один момент: это место создавалось для настроек, а не для данных. Небольшим текстовым файлам там место; сценариям, архивам и резервным копиям нет. Не заводите привычку оставлять там файлы.
Если записать не выходит, проверяйте по порядку
Сначала проверьте большинство: видит ли сервер остальной кластер? Если не видит, настоящая проблема в сети, а файл настроек ни при чём.
Затем проверьте службу: работает ли служба, обеспечивающая эту конструкцию?
Затем проверьте локальный диск: если он заполнен, в игре путь, описанный выше.
И последнее, что пропускают чаще всего: узел мог выйти из кластера. Обрыв сети, выключенный сосед, неверно настроенное правило брандмауэра. Симптом всегда выглядит одинаково, причина каждый раз в другом месте.
Что делает Atlas
Atlas читает эту конструкцию напрямую как файлы, вместо того чтобы каждый раз запускать системный инструмент запросов.
Мы измерили, почему. Каждый вызов этого инструмента обходится в сто или двести миллисекунд процессорного времени и около ста мегабайт временной памяти. При открытой панели обновление происходит раз в десять секунд, и каждое обновление требует восьми или десяти вызовов. Иначе говоря, наблюдение создавало постоянные колебания ровно на том сервере, за которым наблюдало.
Чтение той же информации из файла занимает микросекунды. Разрыв в тысячи раз, и на машине пользователя этот разрыв виден как спокойствие.
Вторая деталь изящнее: внутри этой конструкции есть счётчик изменений, который увеличивается всякий раз, когда меняются настройки. Atlas следит за ним. Поэтому в тот момент, когда настройку меняют из панели, кэш обновляется сам; спрашивать редко и никогда не показывать устаревшее становится возможным одновременно.
Это ещё одна сторона принципа, записанного в других статьях этой вики: то, что наблюдает, не должно быть тем, что стоит. Самая лёгкая ошибка средства наблюдения состоит в том, чтобы замедлить наблюдаемую систему и тем самым исказить то самое число, которое оно измеряет.
Источники
Собственная документация Proxmox. На английском, и последнее слово в этом вопросе за ней.