Если диск пустой, то его нужно подключить и сделать все остальное в графическом интерфейсе. Вы увидите диск в GUI, если кликнете на ваш узел -> Диски. У него должно быть написано "Использование: нет". Тогда вы можете нажать на LVM-Thin (или что-то еще) и нажать Создать Thinpool, оставив галочку "Добавить хранилище" отмеченной. Это и есть вся процедура. Если вы не можете выбрать его в диалоговом окне Создания Thinpool (=> не пустой) и больше не нуждаетесь в данных на нем, то вам нужно быть абсолютно уверенным, что вы знаете имя вашего диска (например, /dev/sdc ...) и выполнить (предполагая, что ваш диск /dev/sdc) команду: wipefs -a /dev/sdc dd if=/dev/zero of=/dev/sdc bs=1M count=200 Затем выполните процедуру из вышеупомянутого.

Всем привет, надеюсь, у вас всё в порядке. Как я и говорил, я работаю над новой архитектурой своего второго проекта, который можно описать как k8s/docker/rancher + S3-подобное хранилище и PostgreSQL для метаданных. С самого начала я работал по стандартной схеме с 3 рабочими узлами / мастером + 1 узлом Rancher. Это несколько соответствовало целям HCI. Я начал свои исследования в этом направлении (и Proxmox + CEPH или Proxmox + Gluster были среди конкурентов). Но это было вчера. Теперь, похоже, мой клиент думает о развитии своего продукта и спросил меня: "Эй, Боб! (пусть будет, что меня зовут Боб) Как ты смотришь на то, чтобы объединить всё это в одном кластере k3s и избавиться от надоедливых кластеров HCI (поскольку их приложение не столь требовательное к серверной части и позволяет клиентской стороне использовать свои ЦП)? Можешь подумать об этом?" Так как мой мозг чуть ли не взрывается, я решил поработать над этим новым (даже тревожным) выбором. Я предложил им всё-таки работать с гипервизором + SDS в автономном режиме и сделать асинхронную репликацию на втором гипервизоре, чтобы иметь хоть какую-то устойчивость (у них есть требование о 4-часовом перезапуске после сбоя). Как вы считаете, это хорошая идея? Есть ли у вас рекомендации, плюсы и минусы HCI по сравнению с 2 большими узлами актив/резервный? С использованием PROXMOX VE? + CEPH в обоих случаях, чтобы сравнить одно и то же. Я думаю, что это может быть хорошей идеей упростить архитектуру на сетевой стороне и не поддерживать распределённое хранилище, если это не является требованием, чтобы приложение работало независимо от стоимости.

Ок, спасибо. Есть ли какое-то универсальное правило, чтобы рассчитать, что потребуется для моего гипервизора, чтобы поддерживать услуги резервного копирования и мониторинга, и оценить общие потребности моей инфраструктуры? Это нужно для оценки, чтобы предоставить элемент сравнения моему руководству. На этом этапе это не окончательная оценка стоимости оборудования. Это будет точно рассчитано в реальных условиях во время R&D POC. Что-то похожее на то, что у меня есть в руководстве PVE по оценке моих потребностей для хранения CEPH?

Я прочитал твою информацию относительно бенчмарков. На мой взгляд, это немного излишне для моей текущей задачи. Я буду сильно полагаться на эти данные, когда буду тестировать и конструкцию своего POC, и это будет очень полезно в это время. Или, по крайней мере, перед тем, как отдать свою «кулинарную» рецептуру моему продавцу оборудования. Сейчас мне нужны некие «относительные» указания, такие как: резервируйте 10% ваших вычислительных мощностей для вашего HCI или, как правило, считайте 1 ГБ ОЗУ на 1 ТБ хранилища. Просто чтобы иметь общее представление о том, во что мне нужно будет инвестировать, чтобы все работало, и сравнить с другими аппаратными/HCI платформами.