В предыдущем разделе вы установили Proxmox VE и впервые перешли в его веб-интерфейс, а именно на экран входа в систему, за которым отображалось предупреждение о самоподписанном сертификате. В этом разделе мы превратим эту «голую» установку в платформу, действительно готовую для работы с виртуальными машинами: настоящие обновления пакетов, сетевой мост, хранилище и оптимизация памяти, которая становится важной, когда несколько виртуальных машин работают одновременно.
Исправить репозитории пакетов
При первом входе в систему на узле прежде всего появляется предупреждение: корпоративный репозиторий включен, но к нему не привязана ни одна активная подписка, поэтому все операции с пакетами в этом репозитории заканчиваются сбоем.
Почему платный репозиторий вообще включен по умолчанию на сервере без подписки?
Потому что это более безопасный вариант по умолчанию. Репозиторий «Enterprise» - самый тщательно протестированный из тех, что поставляются с Proxmox, а программа установки не может заранее определить, есть ли у данного сервера подписка или нет, поэтому она в любом случае включает один и тот же репозиторий, а исправление оставляет на усмотрение того, кто настраивает сервер.
Исправление, по сути, состоит из двух этапов: отключение только корпоративного репозитория на самом деле ухудшает ситуацию, поскольку в результате на узле не останется ни одного включенного репозитория Proxmox.
Кнопка «Добавить» на этом же экране предлагает то, чего не хватало: репозиторий без подписки, созданный именно для такой ситуации.
Второй, отдельный корпоративный репозиторий для пакетов Ceph останется включенным даже после этого исправления и по-прежнему будет выдавать ошибку при обновлении; его можно оставить без изменений, если хранилище Ceph не входит в ваши планы, что выходит за рамки данного руководства.
После добавления репозитория без подписки статус узла меняется: вместо одного предупреждения появляется комбинация, которую стоит научиться распознавать: обновления теперь работают, но при этом отображается напоминание о том, что этот репозиторий не является тем, который Proxmox рекомендует для рабочего кластера.
Обновить систему
При наличии рабочего репозитория панель «Обновления» может действительно обновить список пакетов, а не выдавать сразу же ошибку. Журнал задач, связанный с этим обновлением, стоит прочитать хотя бы раз, так как в нём точно указано, какие репозитории ответили, а какие - нет.
Отсюда кнопка «Обновить» на том же экране запускает собственно обновление пакета - ту же операцию, что и apt full-upgrade в командной строке. Запуск этой команды сразу после новой установки, когда ещё не создано ни одной виртуальной машины, означает, что перезагрузка, вызванная обновлением самого ядра, пока не приведёт к прерыванию каких-либо реальных процессов.
Ознакомьтесь с сетевым мостом
Программа установки уже создала один сетевой интерфейс, помимо физической карты: vmbr0 - мост Linux, построенный поверх физического nic0 и содержащий IP-адрес для управления, заданный во время установки.
Зачем устанавливать мост между виртуальными машинами и физической сетью, вместо того чтобы просто использовать сетевую карту напрямую?
Ведь физический сетевой адаптер может быть подключен только к одному месту одновременно. Мост, напротив, работает как небольшой виртуальный коммутатор: физический сетевой адаптер подключается к одной его стороне, а виртуальные сетевые интерфейсы всех виртуальных машин - к другой, причём каждый из них имеет собственный MAC-адрес и может независимо от других отправлять и принимать трафик по одному и тому же физическому каналу.
Кроме того, именно к этому мосту в разделе, посвящённому маршрутизации IPv4, который будет рассмотрен далее в данном руководстве, будет привязан второй адрес, поэтому пока здесь ничего менять не нужно - достаточно просто распознать его, когда он вновь появится.
Обзор хранилища
Сразу после установки появляются две записи хранилища, обе расположенные на одном диске, выбранном во время настройки, но предназначенные для разных целей.
Перед созданием виртуальных машин в следующей части: если на сервере установлено более одного физического диска, добавьте остальные в разделе «Datacenter», «Storage», «Add now». Чтобы проверить, какие диски уже видимы Proxmox, сравните этот список с дисками, отображавшимися в сводке по установке; всё, чего здесь нет, необходимо добавить вручную, так как Proxmox никогда не определяет назначение второго диска автоматически.
Настройка кэша и ЦП с учетом плотности виртуальных машин
Два параметра определяют, сколько виртуальных машин фактически поместится в оперативной памяти данного сервера, и ни один из них не настраивается программой установки специально для хостинговой нагрузки, поскольку у неё нет возможности узнать, для чего именно предназначена эта машина.
Включение дедупликации данных с помощью KSM
Функция объединения одинаковых страниц памяти ядра (Kernel Samepage Merging, KSM) позволяет нескольким виртуальным машинам, работающим под управлением одной и той же гостевой ОС, совместно использовать страницы памяти вместо того, чтобы каждая из них хранила собственную отдельную копию практически идентичного содержимого. Proxmox реализует эту функцию с помощью демона настройки ksmtuned, который отслеживает загрузку памяти и включает фактическое объединение страниц только в тех случаях, когда это целесообразно.
На только что установленном узле, на котором пока не запущено ни одной виртуальной машины, этот демон активен, но находится в режиме ожидания, и это стоит проверить самостоятельно, а не просто предполагать.
Эти нули не являются признаком неправильной настройки - это ожидаемое состояние на хосте, у которого нет нагрузки на память, требующей реагирования. Как только появляется несколько виртуальных машин с одной и той же ОС, ksmtuned самостоятельно переключает параметр run в значение 1, и показатель pages_shared начинает расти - и всё это без каких-либо ручных действий; сами пороги настройки хранятся в /etc/ksmtuned.conf если впоследствии понадобится их настроить, хотя настройки по умолчанию являются неплохой отправной точкой для первой платформы.
Снизить показатель Swappiness и проверить микрокод процессора
Параметр swappiness определяет, насколько активно ядро перемещает данные в область подкачки вместо того, чтобы хранить их в оперативной памяти, а значение по умолчанию в Debian (60) было выбрано для универсального настольного компьютера задолго до того, как появились виртуальные машины, каждая из которых требует собственной оперативной памяти. Для непосредственной проверки этого параметра, а также информации о том, какой микрокод процессора фактически загружен, достаточно одной команды.
Более низкое значение не позволяет ядру выгружать память виртуальной машины только потому, что к ней не обращались в течение последних нескольких секунд, что в случае гипервизора имеет большее значение, чем практически где-либо ещё: для пользователя виртуальная машина, память которой была выгружена, кажется «зависшей». Запись настройки в файл в каталоге /etc/sysctl.d/ позволяет ему сохраняться после перезагрузки, а не быть одноразовым значением, которое сбрасывается при перезагрузке.
Стоит разобраться в этих двух крайностях, а не просто слепо выбирать какое-то число. При значении swappiness, равном 60, ядро начинает проактивно использовать подкачку задолго до того, как оперативная память действительно закончится, жертвуя небольшой производительностью файлового кэша ради запаса, который на настольном компьютере редко бывает нужен; на хосте, на котором запущены виртуальные машины, эта же проактивная подкачка может незаметно выгрузить виртуальную машину, которая просто простояла некоторое время, причём гостевая ОС этой виртуальной машины даже не догадывается, что это произошло - она просто воспринимает работу как замедленную. При значении swappiness, равном 0, ядро почти полностью избегает использования свопа и вместо этого полагается на механизм «out-of-memory killer», когда оперативная память действительно заканчивается, что является более серьёзным сбоем, чем небольшая подкачка. Низкое, но ненулевое значение (в данном случае 10) позволяет использовать своп в качестве «страховочной сетки» на случай реального исчерпания памяти, не прибегая к нему в первую очередь.
Подержанные корпоративные серверы, подобные тем, что рекомендуются в Части 1, зачастую уже имеют установленный актуальный пакет микрокода, оставшийся с момента их последнего реального использования; запуск программы установки не требует никаких затрат, даже если окажется, что ничего делать не нужно, и позволяет обновить микрокод тех процессоров, которым это действительно необходимо.
На этом сервере проверка пакета микрокода Intel подтвердила, что он уже установлен в самой новой доступной версии, поскольку он входит в базовую установку Debian: устанавливать ничего не нужно, что само по себе является полезной информацией, а не пустой тратой времени. Сам микрокод представляет собой прошивку для процессора, исправляющую реальные аппаратные ошибки, обнаруженные компаниями Intel или AMD после того, как чип уже поступил в продажу; некоторые из них касаются исключительно корректности работы, а другие - безопасности; сервер, купленный б/у в соответствии с рекомендациями из Части 1, мог простоять на складе или работать без вмешательства в течение многих лет, меняя владельцев, - достаточно долго, чтобы накопилось несколько таких не установленных исправлений. Выполнение этой одной команды ничего не стоит, независимо от результата, и это единственный способ узнать наверняка, а не просто предполагать, что б/у машина обновлена до последней версии.
Создать учетную запись администратора без прав root
На всех экранах, показанных до сих пор в этом руководстве, использовалась учетная запись root, что вполне подходит для первого часа настройки сервера, но не стоит делать это повседневной привычкой после того, как платформа начнет нормально работать.
Разве root - это не обычный способ управления одноузловым хостом Proxmox?
Это работает, но в случае утечки всего одного пароля root злоумышленник получает полный контроль над всей платформой: нет отдельной учетной записи, которую можно было бы заблокировать, и нет отдельного входа в систему, который можно было бы отследить в журнале задач. Специальная учетная запись администратора решает эту проблему, не лишая root каких-либо возможностей.
Чтобы добавить учетную запись, сначала необходимо сделать выбор, который на первый взгляд может показаться неочевидным: к какому пространству принадлежит данная учетная запись. Для учетной записи Linux PAM необходимо, чтобы на сервере уже существовал реальный пользователь Unix; учетная запись сервера аутентификации Proxmox VE, сокращённо pve, существует только внутри самой системы Proxmox, имеет собственный пароль и не требует ничего на базовой ОС.
Для учетной записи администратора, которой нужен только веб-интерфейс, проще всего выбрать реалм pve - именно он отображается в списке пользователей сразу после создания. Стоит подробно остановиться на этом компромиссе, а не обходить его стороной: учётная запись PAM, поскольку она сопоставляется с реальным пользователем Unix, также может подключаться к серверу по SSH и получать доступ к реальной оболочке, так же как и пользователь root, в то время как учётная запись pve-realm существует исключительно внутри собственной системы аутентификации Proxmox и не имеет доступа к оболочке вообще, независимо от того, какая роль ей присвоена в веб-интерфейсе. Для учетной записи, предназначенной исключительно для управления виртуальными машинами и хранилищем через браузер и ни для чего больше, это не ограничение, а именно то ограничение, которое необходимо: потеря пароля к этой учетной записи никогда не приведёт к передаче доступа к командной оболочке базовой ОС, как это произошло бы в случае взлома учетной записи PAM.
Присвоить ему роль
Вновь созданный пользователь в Proxmox изначально не имеет доступа ни к чему; само существование пользователя не означает, что ему разрешено что-либо делать, и именно эту связь и обеспечивает раздел «Права доступа» в разделе «Центр обработки данных». Право доступа связывает один путь в дереве ресурсов с одним пользователем и одной ролью.
Путь / означает всё дерево ресурсов в целом, включая каждую виртуальную машину и каждое хранилище; параметр «Propagate» (по умолчанию включен) распространяет эту роль также на все элементы, расположенные ниже данного пути, как существующие, так и будущие. В результате получается учетная запись с такими же правами доступа, как у root, авторизованная под собственным именем.
«Администратор» - это самая широкая из существующих ролей, и она подходит для личной учетной записи отдельного пользователя, но это не единственный вариант прав доступа, который может возникнуть, когда данная платформа перестанет быть проектом одного человека. Proxmox также предоставляет более узкие встроенные роли: PVEVMAdmin - для тех, кто должен управлять только виртуальными машинами, не затрагивая хранилище или пользователей, PVEAuditor - для просмотра только в режиме чтения без возможности что-либо изменять; в том же диалоговом окне «Добавить: права пользователя» можно выбрать любую из них вместо «Администратора», причём путь не обязательно должен начинаться с корневого каталога / тоже; ограничение области действия собственным путем одной виртуальной машины, напротив, привязывает этот доступ исключительно к этой виртуальной машине и ни к чему большему. Пока что в этом нет необходимости, если на одном узле используется одна учетная запись администратора, но этот механизм - тот самый, который впоследствии разграничивает, к чему может обращаться оператор, работающий с клиентами, а к чему - только владелец платформы.
Включить двухфакторную аутентификацию
Proxmox поддерживает четыре метода дополнительной аутентификации: коды TOTP из приложения-аутентификатора, аппаратные ключи WebAuthn, одноразовые ключи восстановления и Yubico OTP; для использования TOTP не требуется приобретать ничего дополнительного, поэтому его целесообразно настроить в первую очередь.
Сканирование этого кода в приложении-аутентификаторе и ввод шестизначного кода, сгенерированного приложением, - вот что на самом деле подтверждает настройку; Proxmox не включит TFA для учетной записи, пока подлинный код не подтвердит работоспособность секретного ключа.
Стоит об этом подумать заранее, пока ситуация не стала критической: что произойдет, если телефон с приложением-аутентификатором потеряется, будет сброшен или просто разрядится в неподходящий момент? Именно для этого и существуют ключи восстановления - один из трех типов двухфакторной аутентификации: набор одноразовых кодов, сгенерированных заранее и хранящихся где-то за пределами самого телефона, каждый из которых можно использовать ровно один раз для входа в систему без использования приложения TOTP вообще. Без заранее настроенного метода восстановления потеря единственного устройства TOTP полностью блокирует доступ к этой учетной записи до тех пор, пока другая учетная запись администратора или сам root не удалит запись TFA на экране «Двухфакторная аутентификация», показанном ранее.
Включить брандмауэр
Proxmox поставляется с полнофункциональным брандмауэром, который по умолчанию отключен на всех уровнях - как на узлах, так и на виртуальных машинах. Прежде чем включать его, стоит один раз ознакомиться с политиками по умолчанию, поскольку именно они определяют, что произойдет в момент его включения.
Прежде чем установить для параметра «Брандмауэр» значение «Да»: убедитесь, что уже существует правило, разрешающее пропуск трафика через порт управления, иначе этот веб-интерфейс станет недоступным сразу после включения брандмауэра. Чтобы это проверить, сначала добавьте и включите правило, убедитесь, что оно отображается в списке, и только после этого включите сам брандмауэр.
Еще два параметра на том же экране приобретают большее значение после подключения виртуальных машин, чем в данный момент. ebtables, включенный по умолчанию, осуществляет фильтрацию непосредственно на сетевом мосте, а не только в сетевом стеке самого хоста, что впоследствии позволяет фильтровать трафик виртуальной машины, даже если технически он вообще не достигает входной цепочки хоста; именно поэтому «Forward Policy» существует как отдельный параметр, отличный от «Input Policy»: трафик, проходящий через хост по пути к виртуальной машине или от неё, считается перенаправленным, а не входящим, и оба типа трафика оцениваются по совершенно разным наборам правил. Правило, написанное для порта управления, должно находиться в разделе «Input»; правило, предназначенное для фильтрации того, что сама виртуальная машина может отправлять или принимать, должно находиться в другом месте - эта деталь станет актуальной только после того, как появится первая виртуальная машина, описанная в Части 3.
Для добавления правила в веб-интерфейсе необходимо указать как протокол, так и порт; если при настройке порта назначения оставить поле «Протокол» пустым, операция завершится сбоем - об этой ошибке стоит знать заранее, чтобы не пришлось устранять неполадки «на ходу».
Ошибка в настройке правила после включения брандмауэра не является столь необратимой, как может показаться, поскольку физическая или виртуальная консоль, использовавшаяся в данном руководстве в главе, посвящённой установке, вообще не проходит через сетевой брандмауэр; это сеанс прямой консоли, полностью обходящий сетевой стек, поэтому доступ к ней сохраняется даже при блокировке всех портов политикой ввода. Редактирование правила или полное pve-firewall stop Как уже упоминалось, всегда есть способ вернуться в систему, о чём стоит помнить, прежде чем рассматривать блокировку брандмауэром как ситуацию, требующую полной переустановки.
Автоматизация выдачи сертификатов с помощью ACME
Предупреждение о самоподписанном сертификате, упомянутое в предыдущем разделе, не обязательно будет отображаться постоянно. Proxmox имеет встроенную поддержку ACME - того же протокола, который использует Let's Encrypt, - и может самостоятельно запрашивать и продлевать настоящий сертификат, как только на него будет указано на настоящий общедоступный домен.
Доступно два каталога, и прежде чем выбрать один из них, важно учесть разницу между ними.
- Let's Encrypt V2: выдает настоящие, надежные сертификаты, и каждая попытка учитывается в рамках общедоступных ограничений по частоте запросов к Let's Encrypt. Использовать стоит только в том случае, если налаживание работы уже завершено.
- Тестовая среда Let's Encrypt V2: выдает сертификаты, которым браузеры не доверяют, но с гораздо более высокими лимитами, созданные специально для тестирования настройки без израсходования реальной квоты.
Для выполнения этого шага в реальных условиях необходим домен, который действительно разрешается на этот сервер из общедоступного Интернета, чего редко бывает в лабораторных условиях или в домашней лаборатории; данное руководство охватывает только процесс регистрации учетной записи, описанный выше, а остальные шаги выполняются естественным образом, как только реальный домен будет настроен на реальную среду развертывания.
Стоит понять, в чем на самом деле заключается этот этап, даже если не описывать его здесь подробно. Let's Encrypt должен убедиться, что сервер, запрашивающий сертификат, действительно контролирует домен, о котором идет речь, и делает это с помощью проверки: в случае распространенного метода HTTP-01 Proxmox на короткое время предоставляет доступ к определённому файлу по конкретному URL в рамках этого домена на порту 80, а собственные серверы Let's Encrypt загружают его для подтверждения; только после этого выдаётся сертификат. Это имеет прямое отношение к описанному выше разделу о брандмауэре, поскольку хост с включенным брандмауэром, на котором разрешен только порт 8006, сразу же провалит эту проверку: порт 80 также должен быть доступен, по крайней мере, на время запроса. После выдачи Proxmox самостоятельно проверяет срок действия сертификата и автоматически продлевает его задолго до истечения 90-дневного срока действия сертификатов Let's Encrypt, регистрируя сбой в журнале задач, а не оставляя просроченный сертификат незамеченным, если что-то пойдет не так.
Настроить реальные уведомления
Адрес электронной почты, указанный при установке, уже выполняет определённую функцию: Proxmox заранее настраивает пункт назначения уведомлений под названием «mail-to-root» и модуль сопоставления, который перенаправляет туда все уведомления, ещё до того, как пользователь начнёт что-либо настраивать вручную.
То, что цели и условия сопоставления представляют собой отдельные элементы, а не единый набор настроек, сделано намеренно: цель лишь определяет, куда может быть отправлено уведомление, а условие сопоставления решает, какие уведомления действительно туда поступят. Показанный выше сопоставитель по умолчанию направляет всё в «mail-to-root», поскольку у него вообще нет условий фильтрации, но сопоставитель может с такой же лёгкостью ориентироваться на уровень серьёзности или тип события, отправляя только сообщения о сбоях резервного копирования или заданий репликации в веб-хук, который оповещает кого-либо, в то время как рутинные уведомления об успешном выполнении остаются в электронной почте, на которые никому не нужно реагировать в режиме реального времени. Именно такое разделение не позволяет растущей платформе либо завалить почтовый ящик рутинным шумом, либо, что ещё хуже, затерять единственное уведомление, которое действительно требовало реакции.
Для любых задач, выходящих за рамки электронной почты, цель веб-хука поддерживает большинство реальных систем оповещения: URL, метод, настраиваемые заголовки и тело сообщения, при этом секретные данные, такие как токены аутентификации, хранятся в отдельном поле, а не передаются в виде открытого текста в теле сообщения.
Ознакомьтесь с параметрами центра обработки данных и узлов
Несколько настроек, которые не вписываются ни в какой другой раздел интерфейса, находятся в разделе «Datacenter» → «Options»; большинство из них настраивается один раз во время установки и впоследствии практически не изменяется.
Одну строку стоит рассмотреть повнимательнее: префикс MAC-адреса, по умолчанию BC:24:11, является начальной частью каждого автоматически сгенерированного сетевого интерфейса виртуальной машины; именно благодаря ему при перехвате пакетов в общей сети можно отличить трафик виртуальной машины Proxmox от любого другого трафика в сети. В сети, где несколько гипервизоров от разных производителей подключены к одному коммутатору, этот префикс часто является самым быстрым способом определить, «откуда на самом деле исходит этот трафик», без необходимости сверки с какими-либо другими данными, поскольку каждый крупный производитель гипервизоров регистрирует и использует свой собственный уникальный префикс точно таким же образом.
Вторая оптимизация ОЗУ осуществляется на уровне узла, наряду с установленным по умолчанию значением «ballooning» в 80 процентов: это целевой объем выделенной виртуальной машине ОЗУ, который драйвер ballooning пытается фактически сохранить в зарезервированном состоянии, возвращая остальную часть хосту в случае нехватки памяти - той самой нехватки, которая также запускает KSM.
Однако механизм «ballooning» работает только при условии, что гостевая ОС взаимодействует с ним - это легко предположить, но слепо полагаться на это было бы ошибкой. Этот механизм опирается на драйвер, работающий внутри самой виртуальной машины - драйвер «balloon», который обычно устанавливается вместе с гостевым агентом QEMU на современных гостевых системах Linux и Windows и который «надувает» «шарик» из страниц памяти, которые гостевая ОС соглашается не использовать, освобождая их обратно для хоста. Виртуальная машина без этого драйвера, особенно старая или минималистичная гостевая ОС, просто не участвует в этом процессе: хост может запрашивать память, но ничего из неё не будет освобождено. На платформе, где работает смешанный набор гостевых операционных систем, реальная эффективность «баллонинга» в конечном итоге ограничивается теми виртуальными машинами, которые проявляют наименьшую готовность к сотрудничеству, независимо от установленной здесь целевой отметки в 80 процентов.
Создать токен API для автоматизации
Для работы со скриптами, использующими API Proxmox, без ввода пароля в скрипте необходимо сначала получить токен, привязанный к пользователю, но не связанный с его логином.
При включенной функции «Разделение привилегий» этот токен изначально не имеет никаких прав доступа, как и совершенно новый пользователь; на том же экране «Права доступа», который используется для самого opsadmin, этому токену в нужный момент предоставляются собственные, более ограниченные права.
Секрет появляется только один раз - сразу после создания, и в этом-то и заключается суть: ничто в этой конструкции не позволяет восстановить его позже - его можно лишь заново сгенерировать в виде нового значения.
Именно это отделение от собственного пароля пользователя делает токены действительно полезными для автоматизации, а не просто бюрократической формальностью. Если секретный ключ этого токена окажется там, где ему не место - например, будет по ошибке закоммитирован в скрипт и отправлен в репозиторий, - то исправить ситуацию можно, удалив или перегенерировав этот конкретный токен из списка API-токенов; собственный пароль opsadmin, его сеансы входа и настройки двухфакторной аутентификации останутся при этом совершенно нетронутыми, поскольку токен изначально не использовал учетные данные той учетной записи, к которой он принадлежит. Утечка пароля пользователя, напротив, означает сброс этого пароля и, возможно, всех связанных с ним сеансов. Разделение привилегий усиливает эту изоляцию ещё на один уровень: даже полностью утечённый секрет токена ограничен теми узкими правами, которые были явно предоставлены самому токену, что представляет собой гораздо меньшую зону поражения, чем полная учётная запись самого opsadmin.
Проверьте состояние DNS, файла hosts и дисков
Несколько мелких проверок завершают процесс новой установки; на них легко не обратить внимания и пропустить, не осознавая их важности.
Одноузловой хост, у которого пока нет других серверов для взаимодействия, может создать впечатление, что DNS практически не играет никакой роли, но на самом деле он уже выполняет реальную работу каждый раз, когда этот узел обращается к чему-либо по имени, а не по чистому IP-адресу. Репозиторий без подписки, полученный по имени хоста ещё на этапе «Обновление» в Части 2, пул NTP, используемый для поддержания точности часов, будущий второй узел, присоединяющийся в качестве члена кластера по собственному имени хоста, а не по IP-адресу - всё это зависит от того, действительно ли работает настроенный здесь DNS-сервер. Неправильный или недоступный DNS-сервер в данном случае является распространённой и запутывающей причиной apt update возникает сбой, похожий на сетевую проблему, хотя сама сеть работает нормально, а нарушено лишь разрешение имен.
Файл hosts данного узла можно редактировать прямо в интерфейсе, и строка, которую следует проверить, - это запись, относящаяся к самому серверу: его IP-адрес сопоставлен с точным полным доменным именем (FQDN), заданным при установке, что и позволяет этому доменному имени разрешаться на сам сервер, совершенно не завися от внешнего DNS.
Эта запись имеет большее значение, чем может показаться, поскольку собственные внутренние инструменты Proxmox также полагаются на правильное разрешение этого имени хоста, наряду со всеми внешними ресурсами. Если эта строка когда-либо будет отредактирована или случайно удалена, симптомы не обязательно будут выглядеть как проблема с файлом hosts; некоторые внутренние вызовы API или, позже, кластерная связь между узлами могут начать давать сбои, которые сначала будут выглядеть как проблема с сетью или сертификатом, тогда как фактической и гораздо более простой причиной будет отсутствующая или неверная запись в файле hosts.
Информация о состоянии дисков находится в разделе «Диски», где рядом с каждым устройством в списке расположена кнопка «Показать значения S.M.A.R.T.»; на реальном оборудовании с реальными дисками она отображает перераспределенные секторы, уровень износа и количество часов работы задолго до того, как диск действительно выйдет из строя.
На этом виртуальном диске эта же кнопка не выдает никаких результатов, что вполне ожидаемо и не является ошибкой: виртуальный диск не подвержен физическому износу, о котором можно было бы сообщить.
При работе с реальным оборудованием эту таблицу стоит изучить, а не просто бегло просматривать, поскольку практически всю полезную работу выполняет лишь небольшое количество её атрибутов. Если показатель «Количество перераспределенных секторов» превышает ноль, это означает, что диск уже начал незаметно выводить из обращения поврежденные секторы и перераспределять их на резервные - это стандартный для отрасли сигнал раннего предупреждения, появляющийся задолго до того, как диск окончательно выйдет из строя; показатель «Часы работы» дает прямое представление о том, какой ресурс уже отработал подержанный диск до того, как он попал на этот сервер. Учитывая совет из Части 1 о покупке подержанного корпоративного оборудования, диски, унаследованные вместе с этим сервером, могут уже иметь реальный наработанный ресурс и реальный износ от предыдущего срока службы, поэтому стоит проверить эту таблицу сразу после установки, а не предполагать, что указание «восстановленный» в объявлении означает, что диски тоже были заменены.
В заключение
- Для устранения предупреждения, связанного с репозиторием, необходимо выполнить два шага: отключить Enterprise, а затем добавить no-subscription.
- KSM, «раздувание» и более низкое значение swappiness позволяют разместить больше виртуальных машин в одном и том же объеме оперативной памяти.
- Учетная запись администратора без прав root с двухфакторной аутентификацией (TFA) и соответствующим правилом брандмауэра - вот что делает доступ исключительно с правами root ненужным в повседневной работе.
- ACME, уведомления и токены API уже подготовлены для использования реальных сертификатов, оповещений и последующей автоматизации.
В следующем разделе вы создадите первую виртуальную машину на этой платформе и установите на ней гостевую ОС.