Alauda Container Platform
  • Русский

    • Удаление дисков, групп томов device-class или узлов из локального хранилища ACP TopoLVM

    В этом документе описывается, как удалить неисправные диски, удалить группы томов device-class из device class и удалить узлы хранилища в локальном хранилище ACP TopoLVM.

    В зависимости от области сбоя, в документе рассматриваются следующие сценарии:

    • Удаление volume group device из device-class volume group
    • Удаление device-class volume group из device class
    • Удаление узла хранилища TopoLVM
    Предупреждение о рисках
    • Процедура в этом документе напрямую удаляет ресурсы хранилища, такие как PVC, PV и logicalvolumes.topolvm.cybozu.com. После удаления этих ресурсов данные на затронутых томах обычно невозможно восстановить. Сделайте резервную копию данных заранее.
    • Перед началом убедитесь, что вы правильно определили диск, группу томов device-class или узел, и запланировали окно обслуживания для затронутых рабочих нагрузок.

    Содержание

    ТерминыВыбор правильного сценарияСценарий 1: Удаление volume group device из device-class volume groupСценарий пользователяПредварительные условияПроверка возможности восстановления device-class volume groupПроцедураСценарий 2: Удаление device-class volume group из device classСценарий пользователяПредварительные условияПроверка полной повреждённости device-class volume groupПроцедураСценарий 3: Удаление узла хранилища TopoLVMСценарий пользователяПредварительные условияПроцедура

    Термины

    ТерминОписание
    device classЛогический класс хранилища, состоящий из одной или нескольких групп томов device-class на разных узлах.
    device-class volume groupLVM volume group на узле, представляющая ресурсы хранилища device class на этом узле.
    volume group deviceДиск на узле. В LVM соответствует физическому тому (physical volume).

    Выбор правильного сценария

    Используйте следующую таблицу, чтобы определить, какой сценарий применим к вашей среде.

    УсловиеСценарий 1: Удаление volume group deviceСценарий 2: Удаление device-class volume groupСценарий 3: Удаление узла хранилища TopoLVM
    Доступность узлаУзел всё ещё доступен.Узел всё ещё доступен.Узел больше не подлежит восстановлению или вы решили навсегда удалить его из TopolvmCluster.
    Статус группы томовЦелевая LVM volume group всё ещё существует и распознаётся.Целевая LVM volume group больше не существует или не распознаётся, но узел сохраняется.Узел и все группы томов device-class на этом узле будут удалены вместе.
    Область удаленияУдаление одного или нескольких неисправных дисков из группы томов.Удаление одной группы томов device-class из сохраняемого узла.Удаление всего узла из TopolvmCluster.
    План сохраненияУзел и группа томов device-class сохраняются.Узел сохраняется, но целевая группа томов device-class не сохраняется.Ни узел, ни какие-либо группы томов device-class на этом узле не сохраняются.

    Сценарий 1: Удаление volume group device из device-class volume group

    Сценарий пользователя

    • Используйте эту процедуру, когда device-class volume group не полностью повреждена, но один или несколько volume group devices в группе томов вышли из строя и должны быть удалены.

    Предварительные условия

    • Целевой узел всё ещё в кластере и доступен.
    • Provision Type целевого device class — Thick.
    • Целевая группа томов device-class не полностью повреждена, и в группе томов остаётся хотя бы один исправный volume group device.

    Проверка возможности восстановления device-class volume group

    Выполните следующую команду на целевом узле:

    vgs <vg-name>

    Параметры:

    • <vg-name>: имя целевой LVM volume group.

    Если команда возвращает нормальный вывод или сообщает только о пропавших некоторых PV, при этом группа томов всё ещё существует, значит device-class volume group не полностью повреждена, и вы можете следовать этой процедуре.

    Пример вывода:

    WARNING: Couldn't find device with uuid VJes6j-2a8V-8Cxf-eW84-yEJK-K24A-yBc9OD.
WARNING: VG hdd-2ab8f0a2-7d1d-42d7-ba6b-da94c6185c33 is missing PV VJes6j-2a8V-8Cxf-eW84-yEJK-K24A-yBc9OD (last written to /dev/vdb).
WARNING: Couldn't find all devices for LV hdd-2ab8f0a2-7d1d-42d7-ba6b-da94c6185c33/b6b331f0-5242-420f-a531-df90628bef80 while checking used and assumed devices.

    Процедура

    Шаг 1: Остановите topolvm-operator

    Выполните следующую команду на управляющем узле, чтобы предотвратить согласование ресурсов оператором во время очистки:

    kubectl -n nativestor-system scale --replicas 0 deployment topolvm-operator

    Шаг 2: Найдите затронутый LVM логический том

    Выполните следующую команду на целевом узле, чтобы найти логические тома, использующие неисправные диски:

    lvs -a -o +devices <vg-name> | egrep "<path-to-disks>|unknown device" | awk '{print $1}'

    Параметры:

    • <vg-name>: имя целевой LVM volume group.
    • <path-to-disks>: пути к устройствам неисправных дисков, например /dev/vdb. Для нескольких дисков разделяйте через |.

    Например:

    lvs -a -o +devices hdd-2ab8f0a2-7d1d-42d7-ba6b-da94c6185c33 2>/dev/null | egrep "/dev/vdb|unknown" | awk '{print $1}'

    Пример вывода:

    b6b331f0-5242-420f-a531-df90628bef80

    Шаг 3: Найдите затронутые PVC и PV

    Выполните следующую команду на управляющем узле, чтобы найти связанные PV и PVC по имени логического тома:

    kubectl get pv -o json | jq -r --arg HANDLE <lv-name> '
  .items[]
  | select(.spec.csi.volumeHandle == $HANDLE)
  | [.metadata.name, .spec.claimRef.namespace, .spec.claimRef.name]
  | @tsv
'

    Параметры:

    • <lv-name>: имя затронутого LVM логического тома.

    Пример вывода:

    pvc-e11f6c18-0e15-4c70-9a24-e7136fabfb2f	demo-space	pvc-topolvm

    В выводе:

    • Колонка 1 — имя PersistentVolume.
    • Колонка 2 — namespace PersistentVolumeClaim.
    • Колонка 3 — имя PersistentVolumeClaim.

    Шаг 4: Остановите рабочие нагрузки, использующие затронутые PVC

    После определения затронутых PVC остановите рабочие нагрузки, которые их используют, и убедитесь, что все связанные Pod остановлены, прежде чем продолжить.

    Шаг 5: Удалите затронутые ресурсы хранилища Kubernetes

    Выполните следующие команды на управляющем узле:

    kubectl delete pvc -n <pvc-namespace> <pvc-name>
kubectl delete pv <pv-name>
kubectl delete logicalvolumes.topolvm.cybozu.com <logicalvolume-name>

    Параметры:

    • <pvc-namespace>: namespace затронутого PVC.
    • <pvc-name>: имя затронутого PVC.
    • <pv-name>: имя затронутого PV.
    • <logicalvolume-name>: имя ресурса TopoLVM logicalvolumes.topolvm.cybozu.com. Совпадает с <pv-name>.

    Если в результате запроса несколько ресурсов, удаляйте их по одному согласно сопоставлению.

    Если ресурс не удаётся удалить обычным способом, добавьте --force по необходимости.

    Шаг 6: Очистите остаточные LVM логические тома

    Выполните следующую команду на целевом узле, чтобы проверить, остались ли логические тома:

    lvs -a -o +devices <vg-name> 2>/dev/null | egrep "<path-to-disks>|unknown device" | awk '{print $1}'

    Параметры:

    • <vg-name>: имя целевой LVM volume group.
    • <path-to-disks>: пути к устройствам неисправных дисков, например /dev/vdb. Для нескольких дисков разделяйте через |.

    Если команда возвращает вывод, удалите оставшиеся логические тома по одному:

    lvremove <vg-name>/<lv-name>

    Параметры:

    • <vg-name>: имя целевой LVM volume group.
    • <lv-name>: имя логического тома для удаления.

    При необходимости добавьте --force.

    Шаг 7: Удалите отсутствующий физический том из группы томов LVM

    Выполните следующую команду на целевом узле:

    vgreduce --removemissing <vg-name>

    Параметры:

    • <vg-name>: имя целевой LVM volume group.

    При необходимости добавьте --force.

    Шаг 8: Обновите ресурс TopolvmCluster

    Выполните следующую команду на управляющем узле:

    kubectl -n nativestor-system edit topolvmclusters.topolvm.cybozu.com topolvm

    В редакторе удалите неисправный volume group device из списка devices целевого узла. Например, удалите /dev/vdb из конфигурации для nodeName: 192.168.133.50.

    До:

    spec:
  storage:
    deviceClasses:
      - classes:
          - className: hdd
            default: true
            devices:
              - name: /dev/vdb
                type: disk
              - name: /dev/vdc
                type: disk
            volumeGroup: hdd-2ab8f0a2-7d1d-42d7-ba6b-da94c6185c33
        nodeName: 192.168.133.50

    После:

    spec:
  storage:
    deviceClasses:
      - classes:
          - className: hdd
            default: true
            devices:
              - name: /dev/vdc
                type: disk
            volumeGroup: hdd-2ab8f0a2-7d1d-42d7-ba6b-da94c6185c33
        nodeName: 192.168.133.50

    Шаг 9: Обновите ConfigMap lvmdconfig

    Выполните следующую команду на управляющем узле:

    kubectl -n nativestor-system edit configmaps lvmdconfig-<node-name>

    Параметры:

    • <node-name>: имя целевого узла.

    В редакторе удалите статус неисправного volume group device из status.json. Например, удалите запись deviceStates для /dev/vdb.

    До:

    status.json: '{"node":"192.168.133.50","phase":"","failClasses":[],"successClasses":[{"className":"hdd","vgName":"hdd-2ab8f0a2-7d1d-42d7-ba6b-da94c6185c33","state":"Ready","message":"create successful","deviceStates":[{"name":"/dev/vdb","state":"Online"},{"name":"/dev/vdc","state":"Online"}]}],"loops":[],"raids":[]}'

    После:

    status.json: '{"node":"192.168.133.50","phase":"","failClasses":[],"successClasses":[{"className":"hdd","vgName":"hdd-2ab8f0a2-7d1d-42d7-ba6b-da94c6185c33","state":"Ready","message":"create successful","deviceStates":[{"name":"/dev/vdc","state":"Online"}]}],"loops":[],"raids":[]}'

    Шаг 10: Запустите topolvm-operator

    Выполните следующую команду на управляющем узле:

    kubectl -n nativestor-system scale --replicas 1 deployment topolvm-operator

    Шаг 11: Проверьте, что volume group device удалён

    Выполните следующую команду на управляющем узле:

    kubectl -n nativestor-system get topolvmclusters.topolvm.cybozu.com topolvm -o jsonpath="{.status.nodeStorageState}" | jq

    Убедитесь, что удалённый volume group device больше не отображается в deviceStates целевого узла.

    Сценарий 2: Удаление device-class volume group из device class

    Сценарий пользователя

    • Используйте эту процедуру, когда группа томов device-class на узле полностью повреждена и не может быть восстановлена удалением только одного volume group device.

    Предварительные условия

    • Целевой узел всё ещё в кластере и доступен.
    • Целевая группа томов device-class полностью повреждена.
    • После удаления целевой группы томов device-class на узле остаётся хотя бы одна другая группа томов device-class.

    Проверка полной повреждённости device-class volume group

    Выполните следующую команду на целевом узле:

    vgs

    Если целевая LVM volume group больше не отображается в выводе, значит device-class volume group полностью повреждена, и вы можете следовать этой процедуре.

    Примечание

    В этом сценарии удаляется вся группа томов device-class с узла, а не только один volume group device в этой группе.

    Процедура

    Шаг 1: Остановите topolvm-operator

    Выполните следующую команду на управляющем узле:

    kubectl -n nativestor-system scale --replicas 0 deployment topolvm-operator

    Шаг 2: Найдите затронутые PVC и PV

    Выполните следующую команду на управляющем узле, чтобы найти PV, PVC и ресурсы logicalvolumes.topolvm.cybozu.com, связанные с указанным классом хранилища на целевом узле:

    kubectl get pv -o json | jq -r --arg NODE <node-name> --arg SC <storageclass-name> '
  .items[]
  | select(.spec.nodeAffinity.required.nodeSelectorTerms[]?.matchExpressions[]? | select(.key=="topology.topolvm.cybozu.com/node") | .values[]? == $NODE)
  | select(.spec.storageClassName == $SC)
  | [.metadata.name, .spec.claimRef.namespace, .spec.claimRef.name]
  | @tsv
'

    Параметры:

    • <node-name>: имя целевого узла.
    • <storageclass-name>: имя класса хранилища, связанного с целевой группой томов device-class. Если задействовано несколько классов, выполните запрос отдельно для каждого.

    Пример вывода:

    pvc-e11f6c18-0e15-4c70-9a24-e7136fabfb2f	demo-space	pvc-topolvm

    В выводе:

    • Колонка 1 — имя и PersistentVolume, и ресурса logicalvolumes.topolvm.cybozu.com.
    • Колонки 2 и 3 — namespace и имя PersistentVolumeClaim.

    Если с целевой группой томов device-class связаны несколько классов хранилища, повторите этот запрос и последующие шаги очистки для каждого класса.

    Шаг 3: Остановите рабочие нагрузки, использующие затронутые PVC

    После определения затронутых PVC остановите рабочие нагрузки, которые их используют, и убедитесь, что все связанные Pod остановлены, прежде чем продолжить.

    Шаг 4: Удалите затронутые ресурсы хранилища Kubernetes

    Выполните следующие команды на управляющем узле:

    kubectl delete pvc -n <pvc-namespace> <pvc-name>
kubectl delete pv <pv-name>
kubectl delete logicalvolumes.topolvm.cybozu.com <logicalvolume-name>

    Параметры:

    • <pvc-namespace>: namespace затронутого PVC.
    • <pvc-name>: имя затронутого PVC.
    • <pv-name>: имя затронутого PV.
    • <logicalvolume-name>: имя ресурса TopoLVM logicalvolumes.topolvm.cybozu.com. Совпадает с <pv-name>.

    Если в результате запроса несколько ресурсов, удаляйте их по одному согласно сопоставлению.

    Если ресурс не удаётся удалить обычным способом, добавьте --force по необходимости.

    Шаг 5: Обновите ресурс TopolvmCluster

    Выполните следующую команду на управляющем узле:

    kubectl -n nativestor-system edit topolvmclusters.topolvm.cybozu.com topolvm

    В редакторе удалите группу томов device-class с целевого узла. Например, в конфигурации для nodeName: 192.168.140.13 удалите запись className: hdd и связанные с ней volumeGroup и devices.

    До:

    spec:
  storage:
    deviceClasses:
      - classes:
          - className: ssd
            default: true
            devices:
              - name: /dev/vdc
                type: disk
            volumeGroup: ssd-4a8737fc-48d3-4c61-882d-0a5bcc6f77a1
          - className: hdd
            devices:
              - name: /dev/vdb
                type: disk
            volumeGroup: hdd-97dc00f3-1df6-4f64-8ddc-7b0b6c5d6de5
        nodeName: 192.168.140.13

    После:

    spec:
  storage:
    deviceClasses:
      - classes:
          - className: ssd
            default: true
            devices:
              - name: /dev/vdc
                type: disk
            volumeGroup: ssd-4a8737fc-48d3-4c61-882d-0a5bcc6f77a1
        nodeName: 192.168.140.13

    Если удалённая запись className имела default: true, назначьте другой оставшийся класс как класс по умолчанию.

    Шаг 6: Обновите ConfigMap lvmdconfig

    Выполните следующую команду на управляющем узле:

    kubectl -n nativestor-system edit configmaps lvmdconfig-<node-name>

    Параметры:

    • <node-name>: имя целевого узла.

    В редакторе удалите конфигурацию, соответствующую целевой группе томов device-class, из lvmd.yaml и status.json. Например, удалите конфигурацию для className: hdd.

    До:

    lvmd.yaml: |
  socket-name: /run/topolvm/lvmd.sock
  device-classes:
  - name: ssd
    volume-group: ssd-4a8737fc-48d3-4c61-882d-0a5bcc6f77a1
    default: true
    type: thick
  - name: hdd
    volume-group: hdd-97dc00f3-1df6-4f64-8ddc-7b0b6c5d6de5
    default: false
    type: thick
status.json: '{"node":"192.168.140.13","phase":"","failClasses":[],"successClasses":[{"className":"hdd","vgName":"hdd-97dc00f3-1df6-4f64-8ddc-7b0b6c5d6de5","state":"Ready","message":"create successful","deviceStates":[{"name":"/dev/vdb","state":"Online"}]},{"className":"ssd","vgName":"ssd-4a8737fc-48d3-4c61-882d-0a5bcc6f77a1","state":"Ready","message":"create successful","deviceStates":[{"name":"/dev/vdc","state":"Online"}]}],"loops":[],"raids":[]}'

    После:

    lvmd.yaml: |
  socket-name: /run/topolvm/lvmd.sock
  device-classes:
  - name: ssd
    volume-group: ssd-4a8737fc-48d3-4c61-882d-0a5bcc6f77a1
    default: true
    type: thick
status.json: '{"node":"192.168.140.13","phase":"","failClasses":[],"successClasses":[{"className":"ssd","vgName":"ssd-4a8737fc-48d3-4c61-882d-0a5bcc6f77a1","state":"Ready","message":"create successful","deviceStates":[{"name":"/dev/vdc","state":"Online"}]}],"loops":[],"raids":[]}'

    Если удалённая запись className имела default: true, назначьте другой оставшийся класс как класс по умолчанию.

    Шаг 7: Запустите topolvm-operator

    Выполните следующую команду на управляющем узле:

    kubectl -n nativestor-system scale --replicas 1 deployment topolvm-operator

    Шаг 8: Проверьте, что device-class volume group удалена

    Выполните следующую команду на управляющем узле:

    kubectl -n nativestor-system get topolvmclusters.topolvm.cybozu.com topolvm -o jsonpath="{.status.nodeStorageState}" | jq

    Убедитесь, что удалённая группа томов device-class больше не отображается на целевом узле, а оставшиеся группы томов device-class находятся в здоровом состоянии.

    Сценарий 3: Удаление узла хранилища TopoLVM

    Сценарий пользователя

    • Целевой узел больше не подлежит восстановлению, или вы решили навсегда удалить его из TopolvmCluster.

    Предварительные условия

    • Вы решили не сохранять никакие группы томов device-class на целевом узле.
    • Рабочие нагрузки, использующие локальные тома на целевом узле, остановлены или перенесены на другие узлы.
    • Оставшиеся узлы могут продолжать размещать необходимые рабочие нагрузки после удаления целевого узла.

    Процедура

    Шаг 1: Остановите topolvm-operator

    Выполните следующую команду на управляющем узле:

    kubectl -n nativestor-system scale --replicas 0 deployment topolvm-operator

    Шаг 2: Найдите затронутые PVC и PV

    Выполните следующую команду на управляющем узле, чтобы найти PV, PVC и ресурсы logicalvolumes.topolvm.cybozu.com, связанные с целевым узлом:

    kubectl get pv -o json | jq -r --arg NODE <node-name> '
  .items[]
  | select(.spec.nodeAffinity.required.nodeSelectorTerms[]?.matchExpressions[]? | select(.key=="topology.topolvm.cybozu.com/node") | .values[]? == $NODE)
  | [.metadata.name, .spec.claimRef.namespace, .spec.claimRef.name]
  | @tsv
'

    Параметры:

    • <node-name>: имя целевого узла.

    Шаг 3: Остановите рабочие нагрузки, использующие затронутые PVC

    После определения затронутых PVC остановите рабочие нагрузки, которые их используют, и убедитесь, что все связанные Pod остановлены, прежде чем продолжить.

    Шаг 4: Удалите затронутые ресурсы хранилища Kubernetes

    Выполните следующие команды на управляющем узле:

    kubectl delete pvc -n <pvc-namespace> <pvc-name>
kubectl delete pv <pv-name>
kubectl delete logicalvolumes.topolvm.cybozu.com <logicalvolume-name>

    Параметры:

    • <pvc-namespace>: namespace затронутого PVC.
    • <pvc-name>: имя затронутого PVC.
    • <pv-name>: имя затронутого PV.
    • <logicalvolume-name>: имя ресурса TopoLVM logicalvolumes.topolvm.cybozu.com. Совпадает с <pv-name>.

    Если в результате запроса несколько ресурсов, удаляйте их по одному согласно сопоставлению.

    Если ресурс не удаётся удалить обычным способом, добавьте --force по необходимости.

    Шаг 5: Обновите ресурс TopolvmCluster

    Выполните следующую команду на управляющем узле:

    kubectl -n nativestor-system edit topolvmclusters.topolvm.cybozu.com topolvm

    В редакторе удалите весь блок конфигурации для целевого узла. Например, удалите блок для nodeName: 192.168.140.13.

    До:

    spec:
  storage:
    deviceClasses:
      - classes:
          - className: hdd
            default: true
            devices:
              - name: /dev/vdc
                type: disk
            volumeGroup: hdd-2ab8f0a2-7d1d-42d7-ba6b-da94c6185c33
        nodeName: 192.168.133.50
      - classes:
          - className: ssd
            default: true
            devices:
              - name: /dev/vdc
                type: disk
            volumeGroup: ssd-4a8737fc-48d3-4c61-882d-0a5bcc6f77a1
          - className: hdd
            devices:
              - name: /dev/vdb
                type: disk
            volumeGroup: hdd-97dc00f3-1df6-4f64-8ddc-7b0b6c5d6de5
        nodeName: 192.168.140.13

    После:

    spec:
  storage:
    deviceClasses:
      - classes:
          - className: hdd
            default: true
            devices:
              - name: /dev/vdc
                type: disk
            volumeGroup: hdd-2ab8f0a2-7d1d-42d7-ba6b-da94c6185c33
        nodeName: 192.168.133.50

    Шаг 6: Обновите ConfigMap lvmdconfig

    Выполните следующую команду на управляющем узле:

    kubectl -n nativestor-system edit configmaps lvmdconfig-<node-name>

    Параметры:

    • <node-name>: имя целевого узла.

    В редакторе удалите полностью секции lvmd.yaml и status.json. Не оставляйте никакой конфигурации или статуса для удалённого узла.

    Шаг 7: Запустите topolvm-operator

    Выполните следующую команду на управляющем узле:

    kubectl -n nativestor-system scale --replicas 1 deployment topolvm-operator

    Шаг 8: Проверьте, что узел удалён

    Выполните следующую команду на управляющем узле:

    kubectl -n nativestor-system get topolvmclusters.topolvm.cybozu.com topolvm -o jsonpath="{.status.nodeStorageState}" | jq

    Убедитесь, что целевой узел больше не отображается в status.nodeStorageState. Например, 192.168.140.13 не должен появляться в выводе.