Глава 3. Под капотом Proxmox

Содержание
  1. Режимы архивирования
  2. Хранилище Proxmox VE
  3. Типы хранилищ
  4. Тонкая Настройка
  5. Конфигурация хранилища
  6. Пулы Хранения
  7. Общие свойства хранилищ
  8. Владелец тома
  9. Использование интерфейса командной строки
  10. Автоматизация создания резервных копий
  11. Про бэкапы в Proxmox VE
  12. Выполнение процедуры резервирования
  13. Восстановление из резервной копии
  14. Работа с образами дисков
  15. Графический интерфейс пользователя
  16. Администрирование и не только
  17. Хранилище Proxmox VE
  18. Типы хранилищ
  19. Тонкая Настройка
  20. Конфигурация хранилища
  21. Пулы Хранения
  22. Общие свойства хранилищ
  23. Владелец тома
  24. Использование интерфейса командной строки
  25. Алгоритмы резервного копирования
  26. Изменение размера виртуального диска
  27. Понедельник, 16 декабря 2019 г.
  28. Руководство администратора Proxmox VE R 6.0 Глава 8.
  29. Добавление и удаление хранилища ZFS в Proxmox VE.
  30. Содержание:
  31. 1. Введение.
  32. 2. Подключаем диск в системе.
  33. 3. Добавление нового хранилища.
  34. 4. Удаление хранилища.
  35. Администрирование и не только
  36. Клонирование виртуальной машины

Режимы архивирования

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

  1. Режим Snapshot (Снимок). Этот режим можно еще назвать как Live backup, поскольку для его использования не требуется останавливать работу виртуальной машины. Использование этого механизма не прерывает работу VM, но имеет два очень серьезных недостатка — могут возникать проблемы из-за блокировок файлов операционной системой и самая низкая скорость создания. Резервные копии, созданные этим методом, надо всегда проверять в тестовой среде. В противном случае есть риск, что при необходимости экстренного восстановления, они могут дать сбой.
  2. Режим Suspend (Приостановка). Виртуальная машина временно «замораживает» свое состояние, до окончания процесса резервного копирования. Содержимое оперативной памяти не стирается, что позволяет продолжить работу ровно с той точки, на которой работа была приостановлена. Разумеется, это вызывает простой сервера на время копирования информации, зато нет необходимости выключения/включения виртуальной машины, что достаточно критично для некоторых сервисов. Особенно, если запуск части сервисов не является автоматическим. Тем не менее такие резервные копии также следует разворачивать в тестовой среде для проверки.
  3. Режим Stop (Остановка). Самый надежный способ резервного копирования, но требующий полного выключения виртуальной машины. Отправляется команда на штатное выключение, после остановки выполняется резервное копирование и затем отдается команда на включение виртуальной машины. Количество ошибок при таком подходе минимально и чаще всего сводится к нулю. Резервные копии, созданные таким способом, практически всегда разворачиваются корректно.

Хранилище Proxmox VE

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

Библиотека хранения (пакет libpve-storage-perl) использует гибкую систему плагинов для обеспечения общего интерфейса для всех типов хранения. Она может быть адаптирована для включения дополнительных типов хранения в будущем.

Типы хранилищ

Существует в основном два различных класса типов хранилищ:
Хранилище файлового уровня Технологии хранения на уровне файлов позволяют получить доступ к полнофункциональной файловой системе (POSIX). Они в целом более гибкие, чем любое хранилище уровня блока (см. ниже), и позволяют хранить контент любого типа. ZFS, вероятно, самая продвинутая система, и она имеет полную поддержку снимков и клонов. Хранилище блочного уровня Позволяет хранить большие необработанные образы. Обычно невозможно хранить другие файлы (ISO, резервные копии, ..) на таком типе хранилища. Большинство современных реализаций блочных хранилищ поддерживают моментальные снимки и клоны. RADOS и GlusterFS с распределенной системой хранения, реплицируют данные на различные узлы. Таблица 8.1: Доступные типы хранения

1 : В файловых хранилищах моментальные снимки возможны в формате qcow2.
2 : Можно использовать LVM поверх хранилища iSCSI. Таким образом, вы получаете общее хранилище LVM.

Тонкая Настройка

Ряд хранилищ, и образы QEMU в формате qcow2 , поддерживает динамическое выделение памяти. При активированной тонкой настройке в хранилище будут записаны только те блоки, которые фактически используются гостевой системой.

Скажем, например, вы создаете виртуальную машину с жестким диском 32 ГБ, и после установки операционной системы гостевой системы корневая файловая система виртуальной машины содержит 3 ГБ данных. В этом случае только 3 ГБ записываются в хранилище, даже если гостевая виртуальная машина видит жесткий диск 32 ГБ. Таким образом, тонкая настройка позволяет создавать образы дисков, которые больше, чем доступные в настоящее время блоки хранения. Можно создавать большие образы дисков для виртуальных машин, а при необходимости добавлять дополнительные диски в хранилище без изменения размера файловых систем виртуальных машин.

Все типы хранилищ, которые имеют функцию “моментальные снимки”, также поддерживают тонкую настройку. Осторожно! Если хранилище заполнено, все гости, использующие Тома в этом хранилище, получают ошибки ввода-вывода. Это может привести к несогласованности файловой системы и повреждению данных. Поэтому рекомендуется избегать чрезмерного использования тонкой настройки ресурсов в вашем хранилище или внимательно следить за свободным пространством, чтобы избежать таких ситуаций.

Конфигурация хранилища

Все связанные с Proxmox VE конфигурации хранилища хранятся в одном текстовом файле по адресу /etc/pve/storage.cfg

Поскольку этот файл находится в папке /etc/pve/ , он автоматически распределяется по всем узлам кластера. Таким образом, все узлы имеют одинаковую конфигурацию хранилища. Совместное использование конфигурации хранилища имеет смысл для общего хранилища, поскольку одно и то же «общее» хранилище доступно со всех узлов. Но это также полезно для локальных типов хранения. В этом случае такое локальное хранилище доступно на всех узлах, но оно физически отличается и может иметь совершенно разное содержимое.

Пулы Хранения

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

Чтобы быть более конкретным, взгляните на конфигурацию хранилища по умолчанию после установки. Он содержит один специальный локальный пул хранения с именем local, который ссылается на каталог /var/lib/vz и всегда доступен. Программа установки Proxmox VE создает дополнительные записи хранилища в зависимости от типа хранилища, выбранного во время установки.

Конфигурация хранилища по умолчанию ( /etc/pve/storage.cfg )

Глава 3. Под капотом Proxmox

Общие свойства хранилищ

Владелец тома

Существует отношение собственности для томов типа образ. Каждый такой Том принадлежит виртуальной машине или контейнеру. Например, том local:230/example-image.raw принадлежит VM 230. Большинство серверных систем хранения данных кодирует эту информацию о владельце в имя Тома.

При удалении виртуальной машины или контейнера система также удаляет все связанные Тома, принадлежащие этой виртуальной машине или контейнеру.

Использование интерфейса командной строки

Рекомендуется ознакомиться с концепцией пулов хранения и идентификаторов томов, но в реальной жизни вы не обязаны выполнять какие-либо из этих низкоуровневых операций в командной строке. Обычно выделение и удаление томов выполняется средствами управления виртуальными машинами и контейнерами.

Тем не менее, существует инструмент командной строки под названием pvesm (“Proxmox VE Storage Manager”), который способен выполнять общие задачи управления хранилищем.

Автоматизация создания резервных копий

Использование ручного способа создания резервных копий — задача весьма трудоемкая и занимает много времени. Поэтому Proxmox VE содержит в себе средство для автоматического резервного копирования по расписанию. Рассмотрим, как это сделать:

  1. Используя веб-интерфейс гипервизора, открываем пункт Датацентр.
  2. Выбираем пункт Резервирование.
  3. Нажимаем кнопку Добавить.
  4. Задаем параметры для планировщика.

Глава 3. Под капотом Proxmox

  • Отмечаем галочкой пункт Включить.
  • Сохраняем изменения, используя кнопку Создать.
  • Теперь планировщик будет автоматически запускать программу резервного копирования в точно указанное время, исходя из заданного расписания.

    Читайте также:  Бесплатные хостинги без рекламы

    Про бэкапы в Proxmox VE

    Глава 3. Под капотом Proxmox

    В статье «Магия виртуализации: вводный курс в Proxmox VE» мы успешно установили на сервер гипервизор, подключили к нему хранилище, позаботились об элементарной безопасности и даже создали первую виртуальную машину. Теперь разберем как реализовать самые базовые задачи, которые приходится выполнять, чтобы всегда иметь возможность восстановить работу сервисов в случае сбоя.

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

    Рассказывать о необходимости создания бэкапов мы не будем, поскольку это очевидно и уже давно является аксиомой. Остановимся на некоторых неочевидных вещах и особенностях.

    Сначала рассмотрим каким образом сохраняются данные при процедуре резервного копирования.

    Выполнение процедуры резервирования

    Для создания резервной копии:

    1. Переходим на нужную виртуальную машину.
    2. Выбираем пункт Резервирование.
    3. Нажимаем кнопку Резервировать сейчас. Откроется окно, в котором можно будет выбрать параметры будущей резервной копии.

    Глава 3. Под капотом Proxmox

  • В качестве хранилища указываем то, которое мы подключали в предыдущей части.
  • После выбора параметров нажимаем кнопку Резервирование и ждем, пока резервная копия будет создана. Об этом будет говорить надпись TASK OK.

    Глава 3. Под капотом Proxmox

    Теперь созданные архивы с резервными копиями виртуальных машин станут доступны для скачивания с сервера. Самым простым и банальным способом копирования является SFTP. Для этого воспользуйтесь популярным кроссплатформенным FTP-клиентом FileZilla, который умеет работать по SFTP-протоколу.

    1. В поле Хост вводим IP-адрес нашего сервера виртуализации, в поле Имя пользователя вводим root, в поле Пароль — тот, который был выбран при установке, а в поле Порт указываем «22» (либо любой другой порт, который был задан для SSH-подключений).
    2. Нажимаем кнопку Быстрое соединение и, если все данные были введены правильно, то в активной панели Вы увидите все файлы, расположенные на сервере.
    3. Переходим в директорию /mnt/storage. Все создаваемые резервные копии будут лежать в поддиректории «dump». Они будут иметь вид:
      • vzdump-qemu-номер_машины-дата-время.vma.gz в случае выбора метода GZIP;
      • vzdump-qemu-номер_машины-дата-время.vma.lzo в случае выбора метода LZO.

    Резервные копии рекомендуется сразу скачивать с сервера и сохранять в надежном месте, например, в нашем облачном хранилище. Если распаковать файл с разрешением vma, одноименной утилитой, идущей в комплекте с Proxmox, то внутри будут файлы с расширениями raw, conf и fw. В этих файлах содержится следующее:

    • raw — образ диска;
    • conf — конфигурация VM;
    • fw — настройки файервола.

    Восстановление из резервной копии

    Рассмотрим ситуацию, когда виртуальную машину случайно удалили и требуется ее экстренное восстановление из резервной копии:

    1. Открываем хранилище, на котором лежит резервная копия.
    2. Переходим на вкладку Содержимое.
    3. Выбираем нужную копию и нажимаем кнопку Восстановление.

    Глава 3. Под капотом Proxmox

  • Указываем целевое хранилище и ID, который будет присвоен машине, после завершения процесса.
  • Нажимаем кнопку Восстановление.
  • Как только восстановление завершится, VM появится в списке доступных.

    Работа с образами дисков

    В комплекте c Proxmox есть очень удобная утилита, под названием qemu-img. Одной из ее функций является конвертирование образов виртуальных дисков. Чтобы воспользоваться им, достаточно открыть консоль гипервизора и выполнить команду в формате:

    В приведенном примере, vmdk-образ виртуального накопителя VMware под названием test будет преобразован в формат qcow2. Это очень полезная команда, когда требуется исправить ошибку при изначальном выборе формата.

    Благодаря этой же команде можно принудительно создать нужный образ, используя аргумент create:

    Такая команда создаст образ test в формате RAW, размером 40 Гб. Теперь он годится для подключения к любой из виртуальных машин.

    Графический интерфейс пользователя

    Proxmox VE-это просто. В нем нет необходимости устанавливать отдельный инструмент управления, и все может быть сделано через ваш веб-браузер (последние Firefox или Google Chrome является предпочтительным). Для доступа к гостевой консоли используется встроенная консоль HTML5. В качестве альтернативы можно использовать SPICE.

    Поскольку мы используем файловую систему кластера Proxmox (pmxcfs), вы можете подключиться к любому узлу для управления всем кластером. Каждый узел может управлять всем кластером. Нет необходимости в выделенном узле диспетчера.

    Вы можете использовать веб-интерфейс администрирования с любым современным браузером. Когда Proxmox VE обнаруживает, что вы подключаетесь с мобильного устройства, вы перенаправляетесь на более простой, сенсорный пользовательский интерфейс.


    Администрирование и не только

    Не вполне стандартные задачи, с которыми мне приходится сталкиваться по работе и способы их решения.

    Хранилище Proxmox VE

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

    Библиотека хранения (пакет libpve-storage-perl) использует гибкую систему плагинов для обеспечения общего интерфейса для всех типов хранения. Она может быть адаптирована для включения дополнительных типов хранения в будущем.

    Типы хранилищ

    Существует в основном два различных класса типов хранилищ:
    Хранилище файлового уровня Технологии хранения на уровне файлов позволяют получить доступ к полнофункциональной файловой системе (POSIX). Они в целом более гибкие, чем любое хранилище уровня блока (см. ниже), и позволяют хранить контент любого типа. ZFS, вероятно, самая продвинутая система, и она имеет полную поддержку снимков и клонов. Хранилище блочного уровня Позволяет хранить большие необработанные образы. Обычно невозможно хранить другие файлы (ISO, резервные копии, ..) на таком типе хранилища. Большинство современных реализаций блочных хранилищ поддерживают моментальные снимки и клоны. RADOS и GlusterFS с распределенной системой хранения, реплицируют данные на различные узлы. Таблица 8.1: Доступные типы хранения

    1 : В файловых хранилищах моментальные снимки возможны в формате qcow2.
    2 : Можно использовать LVM поверх хранилища iSCSI. Таким образом, вы получаете общее хранилище LVM.

    Тонкая Настройка

    Ряд хранилищ, и образы QEMU в формате qcow2 , поддерживает динамическое выделение памяти. При активированной тонкой настройке в хранилище будут записаны только те блоки, которые фактически используются гостевой системой.

    Скажем, например, вы создаете виртуальную машину с жестким диском 32 ГБ, и после установки операционной системы гостевой системы корневая файловая система виртуальной машины содержит 3 ГБ данных. В этом случае только 3 ГБ записываются в хранилище, даже если гостевая виртуальная машина видит жесткий диск 32 ГБ. Таким образом, тонкая настройка позволяет создавать образы дисков, которые больше, чем доступные в настоящее время блоки хранения. Можно создавать большие образы дисков для виртуальных машин, а при необходимости добавлять дополнительные диски в хранилище без изменения размера файловых систем виртуальных машин.

    Все типы хранилищ, которые имеют функцию “моментальные снимки”, также поддерживают тонкую настройку. Осторожно! Если хранилище заполнено, все гости, использующие Тома в этом хранилище, получают ошибки ввода-вывода. Это может привести к несогласованности файловой системы и повреждению данных. Поэтому рекомендуется избегать чрезмерного использования тонкой настройки ресурсов в вашем хранилище или внимательно следить за свободным пространством, чтобы избежать таких ситуаций.

    Конфигурация хранилища

    Все связанные с Proxmox VE конфигурации хранилища хранятся в одном текстовом файле по адресу /etc/pve/storage.cfg

    Поскольку этот файл находится в папке /etc/pve/ , он автоматически распределяется по всем узлам кластера. Таким образом, все узлы имеют одинаковую конфигурацию хранилища. Совместное использование конфигурации хранилища имеет смысл для общего хранилища, поскольку одно и то же «общее» хранилище доступно со всех узлов. Но это также полезно для локальных типов хранения. В этом случае такое локальное хранилище доступно на всех узлах, но оно физически отличается и может иметь совершенно разное содержимое.

    Читайте также:  Улучшите управление программным обеспечением с помощью локального репозитория Centos 7: инструкции

    Пулы Хранения

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

    Чтобы быть более конкретным, взгляните на конфигурацию хранилища по умолчанию после установки. Он содержит один специальный локальный пул хранения с именем local, который ссылается на каталог /var/lib/vz и всегда доступен. Программа установки Proxmox VE создает дополнительные записи хранилища в зависимости от типа хранилища, выбранного во время установки.

    Конфигурация хранилища по умолчанию ( /etc/pve/storage.cfg )

    Глава 3. Под капотом Proxmox

    Общие свойства хранилищ

    Владелец тома

    Существует отношение собственности для томов типа образ. Каждый такой Том принадлежит виртуальной машине или контейнеру. Например, том local:230/example-image.raw принадлежит VM 230. Большинство серверных систем хранения данных кодирует эту информацию о владельце в имя Тома.

    При удалении виртуальной машины или контейнера система также удаляет все связанные Тома, принадлежащие этой виртуальной машине или контейнеру.

    Использование интерфейса командной строки

    Рекомендуется ознакомиться с концепцией пулов хранения и идентификаторов томов, но в реальной жизни вы не обязаны выполнять какие-либо из этих низкоуровневых операций в командной строке. Обычно выделение и удаление томов выполняется средствами управления виртуальными машинами и контейнерами.

    Тем не менее, существует инструмент командной строки под названием pvesm (“Proxmox VE Storage Manager”), который способен выполнять общие задачи управления хранилищем.

    Алгоритмы резервного копирования

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

    Разберем вначале механизмы сжатия:

    1. Сжатие LZO. Алгоритм сжатия данных без потерь, придуманный еще в середине 90-х годов. Код был написан Маркусом Оберхеймером (реализуется в Proxmox утилитой lzop). Основной особенностью этого алгоритма является очень скоростная распаковка. Следовательно, любая резервная копия, созданная с помощью этого алгоритма, может при необходимости быть развернута за минимальное время.
    2. Сжатие GZIP. При использовании этого алгоритма резервная копия будет «на лету» сжиматься утилитой GNU Zip, использующей мощный алгоритм Deflate, созданный Филом Кацем. Основной упор делается на максимальное сжатие данных, что позволяет сократить место на диске, занимаемое резервными копиями. Главным отличием от LZO является то, что процедуры компрессии/декомпреcсии занимают достаточно большое количество времени.

    Изменение размера виртуального диска

    И в заключение покажем как увеличить размер образа диска, если по каким-то причинам места на нем перестало хватать. Для этого воспользуемся аргументом resize:

    Теперь наш образ стал размером 80 Гб. Посмотреть подробную информацию об образе можно с помощью аргумента info:

    Не стоит забывать, что само расширение образа не увеличит размер раздела автоматически — просто добавит доступное свободное пространство. Для увеличения раздела воспользуйтесь командой:

    где /dev/sda1 — нужный раздел.

    Понедельник, 16 декабря 2019 г.

    Руководство администратора Proxmox VE R 6.0 Глава 8.

    Добавление и удаление хранилища ZFS в Proxmox VE.

    Содержание:

    1. Введение.

    1.1. Описание файловой системы.

    ZFS (Zettabyte File System) — файловая система, изначально созданная в Sun Microsystems для операционной системы Solaris. Эта файловая система поддерживает большие объёмы данных, объединяет концепции файловой системы и менеджера логических дисков (томов) и физических носителей, новаторскую структуру данных на дисках, легковесные файловые системы (англ. lightweight filesystems), а также простое управление томами хранения данных. ZFS является проектом с открытым исходным кодом и лицензируется под CDDL (Common Development and Distribution License).

    Основное преимущество ZFS — это её полный контроль над физическими и логическими носителями. Зная, как именно расположены данные на дисках, ZFS способна обеспечить высокую скорость доступа к ним, контроль их целостности, а также минимизацию фрагментации данных. Это позволяет динамически выделять или освобождать дисковое пространство на одном или более носителях для логической файловой системы. Кроме того, имеет место переменный размер блока, что лучшим образом влияет на производительность, параллельность выполнения операций чтения-записи, а также 64-разрядный механизм использования контрольных сумм, сводящий к минимуму вероятность незаметного разрушения данных.

    В Proxmox VE с помощью ZFS можно позволить себе репликацию данных на другой гипервизор, миграцию виртуальной машины/LXC контейнера, доступ к LXC контейнеру с хост-системы и так далее.

    1.2. Пулы хранения.

    В отличие от традиционных файловых систем, которые располагаются на одном устройстве и, следовательно, при использовании более чем на одном устройстве для них требуется менеджер томов, ZFS строится поверх виртуальных пулов хранения данных, называемых zpool. Пул построен из виртуальных устройств (vdevs), каждое из которых является либо физическим устройством, либо зеркалом (RAID 1) одного или нескольких устройств, либо (RAID Z) — группой из двух или более устройств. Ёмкость всех vdevs затем доступна для всех файловых систем в zpool.

    Для ограничения пространства, доступного конкретной файловой системе или тому, может быть установлена квота. Кроме того, возможно использование дискового резервирования (лимита) — это гарантирует, что всегда будет оставаться некоторый доступный объём для конкретной файловой системы или тома.

    Каждый пул хранения состоит из одного или нескольких виртуальных устройств (virtual device, vdev). В свою очередь, каждый vdev включает одно или несколько реальных устройств. Большинство виртуальных устройств используются для простого хранения данных, но существует несколько вспомогательных классов vdev, включая CACHE, LOG и SPECIAL. Каждый из этих типов vdev может иметь одну из пяти топологий: единое устройство (single-device), RAIDz1, RAIDz2, RAIDz3 или зеркало (mirror).

    RAIDz1, RAIDz2 и RAIDz3 — это особые разновидности того, что назовут RAID двойной (диагональной) чётности. 1, 2 и 3 относятся к тому, сколько блоков чётности выделено для каждой полосы данных. Вместо отдельных дисков для обеспечения чётности виртуальные устройства RAIDz полуравномерно распределяют эту чётность по дискам. Массив RAIDz может потерять столько дисков, сколько у него блоков чётности; если он потеряет ещё один, то выйдет из строя и заберет с собой пул хранения.

    В зеркальных виртуальных устройствах (mirror vdev) каждый блок хранится на каждом устройстве в vdev. Хотя наиболее распространённые двойные зеркала (two-wide), в зеркале может быть любое произвольное количество устройств — в больших установках для повышения производительности чтения и отказоустойчивости часто используются тройные. Зеркало vdev может пережить любой сбой, пока продолжает работать хотя бы одно устройство в vdev.

    Одиночные vdev по своей сути опасны. Такое виртуальное устройство не переживёт ни одного сбоя — и если используется в качестве хранилища или специального vdev, то его сбой приведёт к уничтожению всего пула. Будьте здесь очень, очень осторожны.

    Виртуальные устройства CACHE, LOG и SPECIAL могут быть созданы по любой из вышеперечисленных топологий — но помните, что потеря виртуального устройства SPECIAL означает потерю пула, поэтому настоятельно рекомендуется избыточная топология.

    1.3. Встроенное сжатие.

    Механизм копирования при записи также упрощает систему встроенного сжатия. В традиционной файловой системы сжатие проблематично — как старая версия, так и новая версия изменённых данных находятся в одном и том же пространстве.

    Если рассмотреть фрагмент данных в середине файла, который начинает свою жизнь как мегабайт нулей от 0x00000000 и так далее — его очень легко сжать до одного сектора на диске. Но что произойдёт, если мы заменим этот мегабайт нулей на мегабайт несжимаемых данных, таких как JPEG или псевдослучайный шум? Неожиданно этому мегабайту данных потребуется не один, а 256 секторов по 4 КиБ, а в этом месте на диске зарезервирован только один сектор.

    Читайте также:  Откройте для себя искусство отслеживания трафика: привлеките больше посетителей на свой сайт

    У ZFS нет такой проблемы, так как изменённые записи всегда записываются в неиспользуемое пространство — исходный блок занимает только один сектор 4 КиБ, а новая запись займёт 256, но это не проблема — недавно изменённый фрагмент из «середины» файла был бы записан в неиспользуемое пространство независимо от того, изменился его размер или нет, поэтому для ZFS это вполне штатная ситуация.

    Встроенное сжатие ZFS отключено по умолчанию, и система предлагает подключаемые алгоритмы — сейчас среди них LZ4, gzip (1-9), LZJB и ZLE.

    • LZ4 — это потоковый алгоритм, предлагающий чрезвычайно быстрое сжатие и декомпрессию и выигрыш в производительности для большинства случаев использования — даже на довольно медленных CPU.
    • GZIP — почтенный алгоритм, который знают и любят все пользователи Linux-систем. Он может быть реализован с уровнями сжатия 1-9, с увеличением степени сжатия и использования CPU по мере приближения к уровню 9. Алгоритм хорошо подходит для всех текстовых (или других чрезвычайно сжимаемых) вариантов использования, но в противном случае часто вызывает проблемы c CPU — используйте его с осторожностью, особенно на более высоких уровнях.
    • LZJB — оригинальный алгоритм в ZFS. Он устарел и больше не должен использоваться, LZ4 превосходит его по всем показателям.
    • ZLE — кодировка нулевого уровня, Zero Level Encoding. Она вообще не трогает нормальные данные, но сжимает большие последовательности нулей. Полезно для полностью несжимаемых наборов данных (например, JPEG, MP4 или других уже сжатых форматов), так как он игнорирует несжимаемые данные, но сжимает неиспользуемое пространство в итоговых записях.

    Рекомендуется сжатие LZ4 практически для всех вариантов использования. Штраф за производительность при встрече с несжимаемыми данными очень мал, а прирост производительности для типичных данных значителен. Копирование образа виртуальной машины для новой инсталляции операционной системы Windows (свежеустановленная операционная система, никаких данных внутри ещё нет) с compression=lz4 прошло на 27% быстрее, чем с compression=none .

    Последний, самый базовый строительный блок — сектор. Это наименьшая физическая единица, которая может быть записана или считана с базового устройства. В течение нескольких десятилетий в большинстве дисков использовались секторы по 512 байт. В последнее время большинство дисков настроено на сектора 4 КиБ, а в некоторых — особенно SSD — сектора 8 КиБ или даже больше.

    В системе ZFS есть свойство, которое позволяет вручную установить размер сектора. Это свойство ashift. Несколько запутанно, что ashift является степенью двойки. Например, ashift=9 означает размер сектора 2^9, или 512 байт.

    ZFS запрашивает у операционной системы подробную информацию о каждом блочном устройстве, когда оно добавляется в новый vdev, и теоретически автоматически устанавливает ashift должным образом на основе этой информации. К сожалению, многие диски лгут о своём размере сектора, чтобы сохранить совместимость с Windows XP (которая была неспособна понять диски с другими размерами секторов).

    Это означает, что администратору ZFS настоятельно рекомендуется знать фактический размер сектора своих устройств и вручную устанавливать ashift. Если установлен слишком маленький ashift, то астрономически увеличивается количество операций чтения/записи. Так, запись 512-байтовых «секторов» в реальный сектор 4 КиБ означает необходимость записать первый «сектор», затем прочитать сектор 4 КиБ, изменить его со вторым 512-байтовым «сектором», записать его обратно в новый сектор 4 КиБ и так далее для каждой записи.

    В реальном мире такой штраф бьёт по твёрдотельным накопителям Samsung EVO, для которых должен действовать ashift=13 , но эти SSD врут о своём размере сектора, и поэтому по умолчанию устанавливается ashift=9 . Если опытный системный администратор не изменит этот параметр, то этот SSD работает медленнее обычного магнитного HDD.

    Для сравнения, за слишком большой размер ashift нет практически никакого штрафа. Реального снижения производительности нет, а увеличение неиспользуемого пространства бесконечно мало (или равно нулю при включённом сжатии). Поэтому мы настоятельно рекомендуем даже тем дискам, которые действительно используют 512-байтовые секторы, установить ashift=12 или даже ashift=13 , чтобы уверенно смотреть в будущее.

    Внимание! Свойство ashift устанавливается для каждого виртуального устройства vdev, а не для пула, как многие ошибочно думают — и не изменяется после установки. Если вы случайно сбили ashift при добавлении нового vdev в пул, то вы безвозвратно загрязнили этот пул устройством с низкой производительностью и, как правило, нет другого выхода, кроме как уничтожить пул и начать всё сначала. Даже удаление vdev не спасёт от сбитой настройки ashift!

    2. Подключаем диск в системе.

    Подключаем физический диск к серверу и смотрим появился ли он в системе. Просто выполните действия в web-интерфейсе гипервизора Proxmox VE.

    Инициализируем диск в GPT разметке диска.

    Глава 3. Под капотом Proxmox

    Если всё хорошо, то преобразование может начаться сразу:

    Глава 3. Под капотом Proxmox

    А может не начаться и выдать выдать ошибку:

    Глава 3. Под капотом Proxmox

    Исправить ее очень просто. Переходим в консоль сервера и вводим эту команду в консоль:

    # /sbin/sgdisk /dev/sdb -U R -g

    Глава 3. Под капотом Proxmox

    Затем снова переходим в меню преобразования диска в GPT и операция завершается успешно.

    Глава 3. Под капотом Proxmox

    3. Добавление нового хранилища.

    Добавляем новое хранилище в web-панели управления Proxmox VE.

    Переходим в web-интерфейс панели управления Proxmox VE, Выбираем сервер виртуальных машин и раздел «Диски» — «ZFS»:

    Глава 3. Под капотом Proxmox

    Готово! ZFS в строю.

    Глава 3. Под капотом Proxmox

    Теперь мы можем использовать хранилище для размещения виртуальных машин и контейнеров.

    4. Удаление хранилища.

    Удаление производится простым способом. Паркуем все виртуальные машины, которые используют данное хранилище, размонтируем хранилище и удалим его.

    # zpool destroy name_of_zfs

    Внимание! Удаление не предусматривает запроса на подтверждение. Имейте в виду. Удаляется сразу.

    Adblock
    detector

    Администрирование и не только

    Не вполне стандартные задачи, с которыми мне приходится сталкиваться по работе и способы их решения.

    Клонирование виртуальной машины

    Для примера, предположим, что в компании требуется внести изменения в какой-либо критичный сервис. Такое изменение реализуется через внесение множества правок в конфигурационные файлы. Результат при этом непредсказуем и любая ошибка способна вызвать сбой сервиса. Чтобы подобный эксперимент не затронул работающий сервер, рекомендуется выполнить клонирование виртуальной машины.

    Если этим сервисом является веб-сервер, то достаточно только изменить А-запись у Вашего DNS-провайдера, после чего запросы клиентов по этому доменному имени будут направляться уже на адрес клонированной виртуальной машины.

    Кстати, Selectel предоставляет всем своим клиентам услугу размещения любого количества доменов на NS-серверах бесплатно. Управление записями осуществляется как с помощью нашей панели управления, так и с помощью специального API. Подробнее об этом читайте в нашей базе знаний.

    Клонирование VM в Proxmox является очень простой задачей. Для ее выполнения необходимо выполнить следующие действия:

    1. Перейти на нужную нам машину.
    2. Выбрать из меню More пункт Clone.
    3. В открывшемся окне заполнить параметр Имя.

    Глава 3. Под капотом Proxmox

  • Выполнить клонирование нажатием кнопки Clone.
  • Этот инструмент позволяет сделать копию виртуальной машины не только на локальном сервере. Если несколько серверов виртуализации объединить в кластер, то с помощью этого инструмента можно сразу переместить созданную копию на нужный физический сервер. Полезной функцией является выбор дискового хранилища (параметр Target Storage), что очень удобно при перемещении виртуальной машины с одного физического носителя на другой.

    Оцените статью
    Хостинги