Ceph в ProxMox на ZFS
В своей работе (системный администратор) приходится всегда искать вещи и знания, уникальные для своего региона. Одной из таких вещей в нашей конторе является ProxMox, поставленный на файловой системе ZFS, позволяющей использовать неплохой raid массив без использования железных контроллеров. Однажды, думая, чем можно еще удивить и порадовать клиентов, мы решили всё это водрузить на распределенную файловую систему Ceph. Не знаю уж, насколько было такое решение адекватным, но я решил воплотить желание в жизнь. И тут понеслась… Я перелопатил горы статей и форумов, но так и не нашел одного адекватного мануала, описывающего в подробностях что и как делать, поэтому, справившись со всем, родилась эта статья, кому интересно, добро пожаловать под кат.
Итак, в принципе, всё делается в консоли и веб-морда ProxMox нам особо не нужна. Делал я всё в тестовом режиме, поэтому было поднято две виртуалки с четырьмя дисками внутри не очень мощного по железу проксмокса (этакая матрёшка). Четыре диска изначально были обусловлены тем, что хотелось поднять, как и на будущем уже не тестовом железе, на ZFS10, но не вышла золотая рыбка по неведомым мне причинам (на самом деле, было лень разбираться). Вышло так, что ProxMox не смог разметить ZFS10 на виртуальных дисках, поэтому было решено использовать немного другую “географию”. На одном из дисков ставился собственно сам ProxMox, на двух других поднимался ZFS1, третий был якобы под журнал Ceph, но я в итоге про него забыл, поэтому пока оставим его в покое. Итак, приступим.
Тут будет небольшая вводная:
Проксмокс у нас свежеустановленный в двух местах. Ноды называются ceph1 и ceph2. Делаем на обеих нодах всё одинаково, кроме тех мест, что я обозначу. Сеть у нас 192.168.111.0/24. Первая нода (ceph1) имеет адрес 192.168.111.1, вторая (ceph2) — 192.168.111.2. Диски на обеих нодам имеют следующие значения: /dev/vda — диск, на котором стоит ProxMox, /dev/vdb и /dev/vdc — диски, предназначенные для ZFS, /dev/vdd — диск для журнала Ceph.
Первое, что нам нужно сделать, это поменять платный репозиторий ProxMox, требующий подписки, на бесплатный:
Там комментируем единственную строку и вписываем новую ниже:
Далее обновляем наш ProxMox:
Устанавливаем пакеты для работы с Ceph:
Следующим шагом нам нужно сделать кластер из проксмоксов.
На первой ноде выполняем последовательно:
где mycluster — это имя нашего кластера.
Соглашаемся с тем, что нужно принять ssh ключ и вводим пароль root от первой ноды.
Проверяем всё это дело командой pvecm status
Далее инициализуруем конфигурацию Ceph (делается только на первой ноде, которая будет “главной”):
это создаст нам симлинк на /etc/ceph/ceph.conf, от которого мы будем далее отталкиваться.
Сразу после этого нам надо добавить туда опцию в раздел [osd]:
Это связано с тем, что ZFS не умеет directIO.
Следующее, чем делаем, это готовим наш ZFS пул. Для этого диски нужно разметить в GPT:
Там последовательно нажимаем g и w (g для создания таблицы GPT и w для принятия изменений). То же самое повторяем на /dev/vdc.
Создаем зеркальный ZFS пул, называться он у нас будет как принято в ProxMox – rpool:
Проверим командой zpool status -v и получим (по крайней мере должны):
ZFS пул у нас создан, пришло самое время заняться самым главным — ceph.
Создадим файловую систему (странное название, но оно взято с доки по ZFS) для нашего монитора Ceph:
Создадим сам монитор (сначала на первой ноде, потом на второй):
Далее начинается то, с чем пришлось повозиться, а именно то, как сделать блочное устройство для Ceph OSD (а он именно с ними и работает) в ZFS и чтобы оно еще и работало.
А делается всё просто — через zvol:
90G — это то, сколько мы отдаем нашему Ceph на растерзание. Так мало потому, что сервер виртуальный и больше 100G я ему не давал.
Ну и сделаем сам Ceph OSD:
—fs-type у нас выбран XFS потому, что XFS — это дефолтная ФС у Ceph. FSID — это ID нашего Ceph, который можно подсмотреть в /etc/ceph/ceph.conf. Ну, и /dev/zd0 — это наш zvol.
Если после этого у вас df -h не покажет примерно такое:
значит что-то пошло не так и вам либо нужно перезагрузиться, либо ещё раз нужно выполнить создание ceph OSD.
В общем то, на этом мы уже сделали наш ceph и можно дальше им рулить уже в вебморде ProxMox и создать на нем нужное RDB хранилище, но вы не сможете его использовать (собственно, ради чего всё это затевалось). Лечится простым способом (для этого всё-таки хранилище надо создать) — нужно скопировать ключ ceph с первой ноды во вторую.
Открываем конфиг хранилищ ProxMox:
И вписываем туда нужный нам RBD:
Здесь test — это имя нашего хранилища, а IP адреса — это то, где находятся ceph мониторы, то есть наши проксмоксы. Остальные опции дефолтные.
Дальше создаем папочку для ключа на второй ноде:
И копируем ключ с первой:
Здесь ceph1 — наша первая нода, а test — имя хранилища.
На этом можно ставить точку — хранилище активно и работает, можем пользоваться всеми плюшками ceph.
Deploy Hyper-Converged Ceph Cluster
Proxmox VE unifies your compute and storage systems, that is, you can use the same physical nodes within a cluster for both computing (processing VMs and containers) and replicated storage. The traditional silos of compute and storage resources can be wrapped up into a single hyper-converged appliance. Separate storage networks (SANs) and connections via network attached storage (NAS) disappear. With the integration of Ceph, an open source software-defined storage platform, Proxmox VE has the ability to run and manage Ceph storage directly on the hypervisor nodes.
Ceph is a distributed object store and file system designed to provide excellent performance, reliability and scalability.
Easy setup and management via CLI and GUI
Scalable to the exabyte level
Setup pools with different performance and redundancy characteristics
Data is replicated, making it fault tolerant
Runs on commodity hardware
No need for hardware RAID controllers
For small to medium-sized deployments, it is possible to install a Ceph server for RADOS Block Devices (RBD) directly on your Proxmox VE cluster nodes (see Ceph RADOS Block Devices (RBD)). Recent hardware has a lot of CPU power and RAM, so running storage services and VMs on the same node is possible.
To simplify management, we provide pveceph — a tool for installing and managing Ceph services on Proxmox VE nodes.
Ceph Monitor (ceph-mon)
Ceph Manager (ceph-mgr)
Ceph OSD (ceph-osd; Object Storage Daemon)
| We highly recommend to get familiar with Ceph [Ceph intro https://docs.ceph.com/en/quincy/start/intro/] , its architecture [Ceph architecture https://docs.ceph.com/en/quincy/architecture/] and vocabulary [Ceph glossary https://docs.ceph.com/en/quincy/glossary] . |
Precondition
To build a hyper-converged Proxmox + Ceph Cluster, you must use at least three (preferably) identical servers for the setup.
Check also the recommendations from Ceph’s website.
A high CPU core frequency reduces latency and should be preferred. As a simple rule of thumb, you should assign a CPU core (or thread) to each Ceph service to provide enough resources for stable and durable Ceph performance.
Memory
Especially in a hyper-converged setup, the memory consumption needs to be carefully monitored. In addition to the predicted memory usage of virtual machines and containers, you must also account for having enough memory available for Ceph to provide excellent and stable performance.
As a rule of thumb, for roughly 1 TiB of data, 1 GiB of memory will be used by an OSD. Especially during recovery, re-balancing or backfilling.
The daemon itself will use additional memory. The Bluestore backend of the daemon requires by default 3-5 GiB of memory (adjustable). In contrast, the legacy Filestore backend uses the OS page cache and the memory consumption is generally related to PGs of an OSD daemon.
Network
We recommend a network bandwidth of at least 10 GbE or more, which is used exclusively for Ceph. A meshed network setup
[Full Mesh Network for Ceph https://pve.proxmox.com/wiki/Full_Mesh_Network_for_Ceph_Server]
is also an option if there are no 10 GbE switches available.
The volume of traffic, especially during recovery, will interfere with other services on the same network and may even break the Proxmox VE cluster stack.
Furthermore, you should estimate your bandwidth needs. While one HDD might not saturate a 1 Gb link, multiple HDD OSDs per node can, and modern NVMe SSDs will even saturate 10 Gbps of bandwidth quickly. Deploying a network capable of even more bandwidth will ensure that this isn’t your bottleneck and won’t be anytime soon. 25, 40 or even 100 Gbps are possible.
Disks
When planning the size of your Ceph cluster, it is important to take the recovery time into consideration. Especially with small clusters, recovery might take long. It is recommended that you use SSDs instead of HDDs in small setups to reduce recovery time, minimizing the likelihood of a subsequent failure event during recovery.
In general, SSDs will provide more IOPS than spinning disks. With this in mind, in addition to the higher cost, it may make sense to implement a class based separation of pools. Another way to speed up OSDs is to use a faster disk as a journal or DB/Write-Ahead-Log device, see creating Ceph OSDs. If a faster disk is used for multiple OSDs, a proper balance between OSD and WAL / DB (or journal) disk must be selected, otherwise the faster disk becomes the bottleneck for all linked OSDs.
Aside from the disk type, Ceph performs best with an even sized and distributed amount of disks per node. For example, 4 x 500 GB disks within each node is better than a mixed setup with a single 1 TB and three 250 GB disk.
You also need to balance OSD count and single OSD capacity. More capacity allows you to increase storage density, but it also means that a single OSD failure forces Ceph to recover more data at once.
Avoid RAID
As Ceph handles data object redundancy and multiple parallel writes to disks (OSDs) on its own, using a RAID controller normally doesn’t improve performance or availability. On the contrary, Ceph is designed to handle whole disks on it’s own, without any abstraction in between. RAID controllers are not designed for the Ceph workload and may complicate things and sometimes even reduce performance, as their write and caching algorithms may interfere with the ones from Ceph.
| Avoid RAID controllers. Use host bus adapter (HBA) instead. |
| The above recommendations should be seen as a rough guidance for choosing hardware. Therefore, it is still essential to adapt it to your specific needs. You should test your setup and monitor health and performance continuously. |
Initial Ceph Installation & Configuration
Using the Web-based Wizard
With Proxmox VE you have the benefit of an easy to use installation wizard for Ceph. Click on one of your cluster nodes and navigate to the Ceph section in the menu tree. If Ceph is not already installed, you will see a prompt offering to do so.
The wizard is divided into multiple sections, where each needs to finish successfully, in order to use Ceph.
First you need to chose which Ceph version you want to install. Prefer the one from your other nodes, or the newest if this is the first node you install Ceph.
After starting the installation, the wizard will download and install all the required packages from Proxmox VE’s Ceph repository.
After finishing the installation step, you will need to create a configuration. This step is only needed once per cluster, as this configuration is distributed automatically to all remaining cluster members through Proxmox VE’s clustered configuration file system (pmxcfs).
The configuration step includes the following settings:
Public Network: You can set up a dedicated network for Ceph. This setting is required. Separating your Ceph traffic is highly recommended. Otherwise, it could cause trouble with other latency dependent services, for example, cluster communication may decrease Ceph’s performance.
Cluster Network: As an optional step, you can go even further and separate the OSD replication & heartbeat traffic as well. This will relieve the public network and could lead to significant performance improvements, especially in large clusters.
You have two more options which are considered advanced and therefore should only changed if you know what you are doing.
Number of replicas: Defines how often an object is replicated
Minimum replicas: Defines the minimum number of required replicas for I/O to be marked as complete.
Additionally, you need to choose your first monitor node. This step is required.
That’s it. You should now see a success page as the last step, with further instructions on how to proceed. Your system is now ready to start using Ceph. To get started, you will need to create some additional monitors, OSDs and at least one pool.
The rest of this chapter will guide you through getting the most out of your Proxmox VE based Ceph setup. This includes the aforementioned tips and more, such as CephFS, which is a helpful addition to your new Ceph cluster.
CLI Installation of Ceph Packages
Alternatively to the the recommended Proxmox VE Ceph installation wizard available in the web-interface, you can use the following CLI command on each node:
This sets up an apt package repository in /etc/apt/sources.list.d/ceph.list and installs the required software.
Initial Ceph configuration via CLI
Use the Proxmox VE Ceph installation wizard (recommended) or run the following command on one node:
This creates an initial configuration at /etc/pve/ceph.conf with a dedicated network for Ceph. This file is automatically distributed to all Proxmox VE nodes, using pmxcfs. The command also creates a symbolic link at /etc/ceph/ceph.conf , which points to that file. Thus, you can simply run Ceph commands without the need to specify a configuration file.
Ceph Monitor
The Ceph Monitor (MON)
[Ceph Monitor https://docs.ceph.com/en/quincy/start/intro/]
maintains a master copy of the cluster map. For high availability, you need at least 3 monitors. One monitor will already be installed if you used the installation wizard. You won’t need more than 3 monitors, as long as your cluster is small to medium-sized. Only really large clusters will require more than this.
Create Monitors
On each node where you want to place a monitor (three monitors are recommended), create one by using the Ceph → Monitor tab in the GUI or run:
Destroy Monitors
To remove a Ceph Monitor via the GUI, first select a node in the tree view and go to the Ceph → Monitor panel. Select the MON and click the Destroy button.
To remove a Ceph Monitor via the CLI, first connect to the node on which the MON is running. Then execute the following command:
| At least three Monitors are needed for quorum. |
Ceph Manager
The Manager daemon runs alongside the monitors. It provides an interface to monitor the cluster. Since the release of Ceph luminous, at least one ceph-mgr
[Ceph Manager https://docs.ceph.com/en/quincy/mgr/]
daemon is required.
Create Manager
Multiple Managers can be installed, but only one Manager is active at any given time.
| It is recommended to install the Ceph Manager on the monitor nodes. For high availability install more then one manager. |
Destroy Manager
To remove a Ceph Manager via the GUI, first select a node in the tree view and go to the Ceph → Monitor panel. Select the Manager and click the Destroy button.
To remove a Ceph Monitor via the CLI, first connect to the node on which the Manager is running. Then execute the following command:
| While a manager is not a hard-dependency, it is crucial for a Ceph cluster, as it handles important features like PG-autoscaling, device health monitoring, telemetry and more. |
Ceph OSDs
Ceph Object Storage Daemons store objects for Ceph over the network. It is recommended to use one OSD per physical disk.
Create OSDs
You can create an OSD either via the Proxmox VE web-interface or via the CLI using pveceph . For example:
| We recommend a Ceph cluster with at least three nodes and at least 12 OSDs, evenly distributed among the nodes. |
If the disk was in use before (for example, for ZFS or as an OSD) you first need to zap all traces of that usage. To remove the partition table, boot sector and any other OSD leftover, you can use the following command:
| The above command will destroy all data on the disk! |
Ceph Bluestore
Starting with the Ceph Kraken release, a new Ceph OSD storage type was introduced called Bluestore
[Ceph Bluestore https://ceph.com/community/new-luminous-bluestore/]
. This is the default when creating OSDs since Ceph Luminous.
Block.db and block.wal
If you want to use a separate DB/WAL device for your OSDs, you can specify it through the -db_dev and -wal_dev options. The WAL is placed with the DB, if not specified separately.
You can directly choose the size of those with the -db_size and -wal_size parameters respectively. If they are not given, the following values (in order) will be used:
bluestore_block_
… database, section global
10% (DB)/1% (WAL) of OSD size
| The DB stores BlueStore’s internal metadata, and the WAL is BlueStore’s internal journal or write-ahead log. It is recommended to use a fast SSD or NVRAM for better performance. |
Ceph Filestore
Before Ceph Luminous, Filestore was used as the default storage type for Ceph OSDs. Starting with Ceph Nautilus, Proxmox VE does not support creating such OSDs with pveceph anymore. If you still want to create filestore OSDs, use ceph-volume directly.
Destroy OSDs
To remove an OSD via the GUI, first select a Proxmox VE node in the tree view and go to the Ceph → OSD panel. Then select the OSD to destroy and click the OUT button. Once the OSD status has changed from in to out , click the STOP button. Finally, after the status has changed from up to down , select Destroy from the More drop-down menu.
To remove an OSD via the CLI run the following commands.
| The first command instructs Ceph not to include the OSD in the data distribution. The second command stops the OSD service. Until this time, no data is lost. |
The following command destroys the OSD. Specify the -cleanup option to additionally destroy the partition table.
| The above command will destroy all data on the disk! |
Ceph Pools
A pool is a logical group for storing objects. It holds a collection of objects, known as Placement Groups ( PG , pg_num ).
Create and Edit Pools
You can create and edit pools from the command line or the web-interface of any Proxmox VE host under Ceph → Pools.
When no options are given, we set a default of 128 PGs, a size of 3 replicas and a min_size of 2 replicas, to ensure no data loss occurs if any OSD fails.
| Do not set a min_size of 1. A replicated pool with min_size of 1 allows I/O on an object when it has only 1 replica, which could lead to data loss, incomplete PGs or unfound objects. |
It is advised that you either enable the PG-Autoscaler or calculate the PG number based on your setup. You can find the formula and the PG calculator
[PG calculator https://web.archive.org/web/20210301111112/http://ceph.com/pgcalc/]
online. From Ceph Nautilus onward, you can change the number of PGs
[Placement Groups https://docs.ceph.com/en/quincy/rados/operations/placement-groups/]
after the setup.
The PG autoscaler
[Automated Scaling https://docs.ceph.com/en/quincy/rados/operations/placement-groups/#automated-scaling]
can automatically scale the PG count for a pool in the background. Setting the Target Size or Target Ratio advanced parameters helps the PG-Autoscaler to make better decisions.
| If you would also like to automatically define a storage for your pool, keep the ‘Add as Storage’ checkbox checked in the web-interface, or use the command line option —add_storages at pool creation. |
Pool Options
The following options are available on pool creation, and partially also when editing a pool.
The name of the pool. This must be unique and can’t be changed afterwards.
The number of replicas per object. Ceph always tries to have this many copies of an object. Default: 3 .
PG Autoscale Mode
The automatic PG scaling mode
[autoscaler]
of the pool. If set to warn , it produces a warning message when a pool has a non-optimal PG count. Default: warn .
Configure a VM or container storage using the new pool. Default: true (only visible on creation).
The minimum number of replicas per object. Ceph will reject I/O on the pool if a PG has less than this many replicas. Default: 2 .
The rule to use for mapping object placement in the cluster. These rules define how data is placed within the cluster. See Ceph CRUSH & device classes for information on device-based rules.
The number of placement groups
[placement_groups]
that the pool should have at the beginning. Default: 128 .
The ratio of data that is expected in the pool. The PG autoscaler uses the ratio relative to other ratio sets. It takes precedence over the target size if both are set.
The estimated amount of data expected in the pool. The PG autoscaler uses this size to estimate the optimal PG count.
The minimum number of placement groups. This setting is used to fine-tune the lower bound of the PG count for that pool. The PG autoscaler will not merge PGs below this threshold.
Further information on Ceph pool handling can be found in the Ceph pool operation
[Ceph pool operation https://docs.ceph.com/en/quincy/rados/operations/pools/]
manual.
Erasure Coded Pools
Erasure coding (EC) is a form of ‘forward error correction’ codes that allows to recover from a certain amount of data loss. Erasure coded pools can offer more usable space compared to replicated pools, but they do that for the price of performance.
For comparison: in classic, replicated pools, multiple replicas of the data are stored ( size ) while in erasure coded pool, data is split into k data chunks with additional m coding (checking) chunks. Those coding chunks can be used to recreate data should data chunks be missing.
The number of coding chunks, m , defines how many OSDs can be lost without losing any data. The total amount of objects stored is k + m .
Creating EC Pools
Erasure coded (EC) pools can be created with the pveceph CLI tooling. Planning an EC pool needs to account for the fact, that they work differently than replicated pools.
The default min_size of an EC pool depends on the m parameter. If m = 1 , the min_size of the EC pool will be k . The min_size will be k + 1 if m > 1 . The Ceph documentation recommends a conservative min_size of k + 2
[Ceph Erasure Coded Pool Recovery https://docs.ceph.com/en/quincy/rados/operations/erasure-code/#erasure-coded-pool-recovery]
.
If there are less than min_size OSDs available, any IO to the pool will be blocked until there are enough OSDs available again.
| When planning an erasure coded pool, keep an eye on the min_size as it defines how many OSDs need to be available. Otherwise, IO will be blocked. |
For example, an EC pool with k = 2 and m = 1 will have size = 3 , min_size = 2 and will stay operational if one OSD fails. If the pool is configured with k = 2 , m = 2 , it will have a size = 4 and min_size = 3 and stay operational if one OSD is lost.
To create a new EC pool, run the following command:
Optional parameters are failure-domain and device-class . If you need to change any EC profile settings used by the pool, you will have to create a new pool with a new profile.
This will create a new EC pool plus the needed replicated pool to store the RBD omap and other metadata. In the end, there will be a <pool name>-data and <pool name>-metada pool. The default behavior is to create a matching storage configuration as well. If that behavior is not wanted, you can disable it by providing the --add_storages 0 parameter. When configuring the storage configuration manually, keep in mind that the data-pool parameter needs to be set. Only then will the EC pool be used to store the data objects. For example:
| The optional parameters --size , --min_size and --crush_rule will be used for the replicated metadata pool, but not for the erasure coded data pool. If you need to change the min_size on the data pool, you can do it later. The size and crush_rule parameters cannot be changed on erasure coded pools. |
If there is a need to further customize the EC profile, you can do so by creating it with the Ceph tools directly
[Ceph Erasure Code Profile https://docs.ceph.com/en/quincy/rados/operations/erasure-code/#erasure-code-profiles]
, and specify the profile to use with the profile parameter.
Adding EC Pools as Storage
You can add an already existing EC pool as storage to Proxmox VE. It works the same way as adding an RBD pool but requires the extra data-pool option.
| Do not forget to add the keyring and monhost option for any external Ceph clusters, not managed by the local Proxmox VE cluster. |
Destroy Pools
To destroy a pool via the GUI, select a node in the tree view and go to the Ceph → Pools panel. Select the pool to destroy and click the Destroy button. To confirm the destruction of the pool, you need to enter the pool name.
Run the following command to destroy a pool. Specify the -remove_storages to also remove the associated storage.
| Pool deletion runs in the background and can take some time. You will notice the data usage in the cluster decreasing throughout this process. |
PG Autoscaler
The PG autoscaler allows the cluster to consider the amount of (expected) data stored in each pool and to choose the appropriate pg_num values automatically. It is available since Ceph Nautilus.
You may need to activate the PG autoscaler module before adjustments can take effect.
The autoscaler is configured on a per pool basis and has the following modes:
A health warning is issued if the suggested pg_num value differs too much from the current value.
The pg_num is adjusted automatically with no need for any manual interaction.
No automatic pg_num adjustments are made, and no warning will be issued if the PG count is not optimal.
The scaling factor can be adjusted to facilitate future data storage with the target_size , target_size_ratio and the pg_num_min options.
| By default, the autoscaler considers tuning the PG count of a pool if it is off by a factor of 3. This will lead to a considerable shift in data placement and might introduce a high load on the cluster. |
You can find a more in-depth introduction to the PG autoscaler on Ceph’s Blog — New in Nautilus: PG merging and autotuning.
Ceph CRUSH & device classes
The
[CRUSH https://ceph.com/wp-content/uploads/2016/08/weil-crush-sc06.pdf]
(Controlled Replication Under Scalable Hashing) algorithm is at the foundation of Ceph.
CRUSH calculates where to store and retrieve data from. This has the advantage that no central indexing service is needed. CRUSH works using a map of OSDs, buckets (device locations) and rulesets (data replication) for pools.
| Further information can be found in the Ceph documentation, under the section CRUSH map [CRUSH map https://docs.ceph.com/en/quincy/rados/operations/crush-map/] . |
This map can be altered to reflect different replication hierarchies. The object replicas can be separated (e.g., failure domains), while maintaining the desired distribution.
A common configuration is to use different classes of disks for different Ceph pools. For this reason, Ceph introduced device classes with luminous, to accommodate the need for easy ruleset generation.
The device classes can be seen in the ceph osd tree output. These classes represent their own root bucket, which can be seen with the below command.
Example output form the above command:
To instruct a pool to only distribute objects on a specific device class, you first need to create a ruleset for the device class:
name of the rule, to connect with a pool (seen in GUI & CLI)
which crush root it should belong to (default Ceph root «default»)
at which failure-domain the objects should be distributed (usually host)
what type of OSD backing store to use (e.g., nvme, ssd, hdd)
Once the rule is in the CRUSH map, you can tell a pool to use the ruleset.
| If the pool already contains objects, these must be moved accordingly. Depending on your setup, this may introduce a big performance impact on your cluster. As an alternative, you can create a new pool and move disks separately. |
Ceph Client
Following the setup from the previous sections, you can configure Proxmox VE to use such pools to store VM and Container images. Simply use the GUI to add a new RBD storage (see section Ceph RADOS Block Devices (RBD)).
You also need to copy the keyring to a predefined location for an external Ceph cluster. If Ceph is installed on the Proxmox nodes itself, then this will be done automatically.
| The filename needs to be <storage_id> + `.keyring , where <storage_id> is the expression after rbd: in /etc/pve/storage.cfg . In the following example, my-ceph-storage is the <storage_id> : |
CephFS
Ceph also provides a filesystem, which runs on top of the same object storage as RADOS block devices do. A Metadata Server ( MDS ) is used to map the RADOS backed objects to files and directories, allowing Ceph to provide a POSIX-compliant, replicated filesystem. This allows you to easily configure a clustered, highly available, shared filesystem. Ceph’s Metadata Servers guarantee that files are evenly distributed over the entire Ceph cluster. As a result, even cases of high load will not overwhelm a single host, which can be an issue with traditional shared filesystem approaches, for example NFS .
Proxmox VE supports both creating a hyper-converged CephFS and using an existing CephFS as storage to save backups, ISO files, and container templates.
Metadata Server (MDS)
CephFS needs at least one Metadata Server to be configured and running, in order to function. You can create an MDS through the Proxmox VE web GUI’s Node -> CephFS panel or from the command line with:
Multiple metadata servers can be created in a cluster, but with the default settings, only one can be active at a time. If an MDS or its node becomes unresponsive (or crashes), another standby MDS will get promoted to active . You can speed up the handover between the active and standby MDS by using the hotstandby parameter option on creation, or if you have already created it you may set/add:
in the respective MDS section of /etc/pve/ceph.conf . With this enabled, the specified MDS will remain in a warm state, polling the active one, so that it can take over faster in case of any issues.
| This active polling will have an additional performance impact on your system and the active MDS . |
Multiple Active MDS
Since Luminous (12.2.x) you can have multiple active metadata servers running at once, but this is normally only useful if you have a high amount of clients running in parallel. Otherwise the MDS is rarely the bottleneck in a system. If you want to set this up, please refer to the Ceph documentation.
[Configuring multiple active MDS daemons https://docs.ceph.com/en/quincy/cephfs/multimds/]
Create CephFS
With Proxmox VE’s integration of CephFS, you can easily create a CephFS using the web interface, CLI or an external API interface. Some prerequisites are required for this to work:
Install Ceph packages — if this was already done some time ago, you may want to rerun it on an up-to-date system to ensure that all CephFS related packages get installed.
After this is complete, you can simply create a CephFS through either the Web GUI’s Node -> CephFS panel or the command line tool pveceph , for example:
This creates a CephFS named cephfs, using a pool for its data named cephfs_data with 128 placement groups and a pool for its metadata named cephfs_metadata with one quarter of the data pool’s placement groups ( 32 ). Check the Proxmox VE managed Ceph pool chapter or visit the Ceph documentation for more information regarding an appropriate placement group number ( pg_num ) for your setup
[placement_groups]
. Additionally, the —add-storage parameter will add the CephFS to the Proxmox VE storage configuration after it has been created successfully.
Destroy CephFS
| Destroying a CephFS will render all of its data unusable. This cannot be undone! |
To completely and gracefully remove a CephFS, the following steps are necessary:
Disconnect every non-Proxmox VE client (e.g. unmount the CephFS in guests).
Disable all related CephFS Proxmox VE storage entries (to prevent it from being automatically mounted).
Remove all used resources from guests (e.g. ISOs) that are on the CephFS you want to destroy.
Unmount the CephFS storages on all cluster nodes manually with
Where <STORAGE-NAME> is the name of the CephFS storage in your Proxmox VE.
Now make sure that no metadata server ( MDS ) is running for that CephFS, either by stopping or destroying them. This can be done through the web interface or via the command line interface, for the latter you would issue the following command:
to stop them, or
to destroy them.
Note that standby servers will automatically be promoted to active when an active MDS is stopped or removed, so it is best to first stop all standby servers.
Now you can destroy the CephFS with
This will automatically destroy the underlying Ceph pools as well as remove the storages from pve config.
After these steps, the CephFS should be completely removed and if you have other CephFS instances, the stopped metadata servers can be started again to act as standbys.
Ceph maintenance
Replace OSDs
One of the most common maintenance tasks in Ceph is to replace the disk of an OSD. If a disk is already in a failed state, then you can go ahead and run through the steps in Destroy OSDs. Ceph will recreate those copies on the remaining OSDs if possible. This rebalancing will start as soon as an OSD failure is detected or an OSD was actively stopped.
| With the default size/min_size (3/2) of a pool, recovery only starts when ‘size + 1` nodes are available. The reason for this is that the Ceph object balancer CRUSH defaults to a full node as `failure domain’. |
To replace a functioning disk from the GUI, go through the steps in Destroy OSDs. The only addition is to wait until the cluster shows HEALTH_OK before stopping the OSD to destroy it.
On the command line, use the following commands:
You can check with the command below if the OSD can be safely removed.
Once the above check tells you that it is safe to remove the OSD, you can continue with the following commands:
Replace the old disk with the new one and use the same procedure as described in Create OSDs.
Trim/Discard
It is good practice to run fstrim (discard) regularly on VMs and containers. This releases data blocks that the filesystem isn’t using anymore. It reduces data usage and resource load. Most modern operating systems issue such discard commands to their disks regularly. You only need to ensure that the Virtual Machines enable the disk discard option.
Scrub & Deep Scrub
Ceph ensures data integrity by scrubbing placement groups. Ceph checks every object in a PG for its health. There are two forms of Scrubbing, daily cheap metadata checks and weekly deep data checks. The weekly deep scrub reads the objects and uses checksums to ensure data integrity. If a running scrub interferes with business (performance) needs, you can adjust the time when scrubs
[Ceph scrubbing https://docs.ceph.com/en/quincy/rados/configuration/osd-config-ref/#scrubbing]
are executed.
Ceph Monitoring and Troubleshooting
It is important to continuously monitor the health of a Ceph deployment from the beginning, either by using the Ceph tools or by accessing the status through the Proxmox VE API.
The following Ceph commands can be used to see if the cluster is healthy (HEALTH_OK), if there are warnings (HEALTH_WARN), or even errors (HEALTH_ERR). If the cluster is in an unhealthy state, the status commands below will also give you an overview of the current events and actions to take.
Proxmox. Ceph
Ceph — это распределенное хранилище объектов и файловая система, предназначенная для обеспечения отличной производительности, надежности и масштабируемости.
Proxmox VE объединяет вычислительные системы и системы хранения. Это позволяет локальные хранилища (диски) объединять в одно гиперконвергентное устройство. Благодаря интеграции Ceph, Proxmox VE имеет возможность запускать и управлять хранилищем Ceph непосредственно на узлах гипервизора.
По сути получаем вместо SAN или NAS хранилищ объединенное распределенное отказоустойчивое гиперконвергентное устройство (хранилище).
Данная технология реализована у VMware (VMware Virtual SAN) и Microsoft (Storage Spaces Direct).
Познакомиться с Ceph можно в этой статье: Знакомство с хранилищем Ceph в картинках.
Установка Ceph
Установим на всех нодах кластера:
Определим сети и назначим ноду монитора:
Готово. Установим на остальных нодах. Поскольку конфигурация в кластере уже установлена вместе с первой нодой, на остальных нодах этого не потребуется.
Если необходимо можно создать дополнительные мониторы:
На всех нодах добавляем диски в OSD:
И создаем Metadata Server:
Создаем хранилище в кластере CephFS:
CephFS – поддерживает тип хранилищ ISO images, VZDump backup, Container template, Snippets.
Для размещения дисков виртуальных машин и контейнеров нужно создать RDB Storage.
Далее добавим еще один сервер монитор и Metadata Server.
Создаем виртуальную машину или контейнер с размещением на Ceph (RDB) и тестируем работоспособность, возможность миграции между нодами.
Пример: Создан контейнер с веб сайтом (phpBB) на PVE3 с размещением на Ceph (RDB) диске. Создан ресурс высокой доступности (HA Resource) на контейнер. После выключаем ноду PVE3.
Результат. Контейнер мигрировал на рабочую ноду, сохранив работоспособность, Ceph деградировал, но сохранил работоспособность.
Восстановим работоспособность PVE3 и проверим данные.
Тема с гиперковергентыми устройствами и средами достаточно масштабна и наряду с преимуществами имеет не меньше подводных камней, сложностей и проблем. В рамках одной статьи невозможно продемонстрировать все нюансы технологии. Однако можно сказать, что, чем больше объектов будет учувствовать в данной среде, тем больше устойчивость среды к отказам.
Администрирование и не только
Не вполне стандартные задачи, с которыми мне приходится сталкиваться по работе и способы их решения.
Страницы
- Главная страница
- Оглавление
- Документация
- Обо мне
вторник, 5 ноября 2019 г.
Руководство администратора Proxmox VE R 6.0 Глава 4.
Гиперконвергентная инфраструктура
Преимущества гиперконвергентной инфраструктуры (HCI) с Proxmox VE
- Масштабируемость: плавное расширение вычислительных, сетевых и запоминающих устройств (т. е. быстрое и независимое масштабирование серверов и хранилищ).
- Низкая стоимость: Proxmox VE является ПО с открытым исходным кодом и объединяет все необходимые компоненты, такие как вычислительные ресурсы, хранилище, сеть, резервное копирование и Центр управления. Он может заменить дорогостоящую вычислительную инфраструктуру / инфраструктуру хранения данных.
- Защита данных и эффективность: интегрированы такие службы, как резервное копирование и аварийное восстановление.
- Простота: простота настройки и централизованное администрирование.
- Открытый исходный код: • Отсутствие блокировки со стороны поставщика
Управление службами Ceph на узлах Proxmox VE
Proxmox VE объединяет ваши вычислительные системы и системы хранения, т.е. вы можете использовать одни и те же физические узлы в кластере как для вычислений (обработка виртуальных машин и контейнеров), так и для реплицированного хранилища. Традиционные хранилища вычислительных и запоминающих ресурсов могут быть объединены в одно гиперконвергентное устройство. Отдельные сети хранения (SANs) и подключения через сетевые хранилища (NAS) исчезают. Благодаря интеграции Ceph, программной платформы хранения с открытым исходным кодом, Proxmox VE имеет возможность запускать и управлять хранилищем Ceph непосредственно на узлах гипервизора.
Ceph — это распределенное хранилище объектов и файловая система, предназначенная для обеспечения отличной производительности, надежности и масштабируемости.
- Простая настройка и управление с поддержкой CLI и GUI
- Тонкая настройка
- Поддержка снапшотов
- Самовосстановление
- Масштабируемость до уровня эксабайт
- Настройка пулов с различными характеристиками производительности и резервирования
- Данные реплицируются, что делает их отказоустойчивыми
- Работает на бюджетном оборудовании
- Нет необходимости в аппаратных RAID контроллерах
- Открытый исходный код
- Ceph Monitor (ceph-mon)
- Ceph Manager (ceph-mgr)
- Ceph OSD (ceph-osd; Object Storage Daemon)
Предварительное условие
Для построения гиперконвергентного кластера Proxmox + Ceph должно быть как минимум три (желательно) одинаковых сервера для установки.
Проверьте также рекомендации с веб-сайта Ceph.
CPU
Более высокая частота ядра процессора уменьшает задержки и является предпочтительной. В качестве простого практического правила вы должны назначить ядро (или поток) процессора каждому сервису Ceph, чтобы обеспечить достаточно ресурсов для стабильной и надежной работы Ceph.
Память
Особенно в гиперконвергентной установке, потребление памяти необходимо тщательно контролировать. В дополнение к предполагаемой рабочей нагрузке от виртуальных машин и контейнера, Ceph требуется достаточно памяти, чтобы обеспечить хорошую и стабильную производительность. Как правило, для примерно 1 TiB данных, 1 GiB памяти будет использоваться OSD. Кэширование OSD будет использовать дополнительную память.
Сеть
Мы рекомендуем пропускную способность сети, которая используется исключительно для Ceph не менее 10 GbE или более. Ячеистая топология сети 2 также является выходом, если нет доступных коммутаторов 10 GbE. Объем трафика, особенно во время восстановления, будет мешать другим службам в той же сети и может даже разрушить стек кластера Proxmox VE. Кроме того, оцените свои потребности в пропускной способности. В то время как один жесткий диск может не насыщать канал 1 Гб, несколько жестких дисков на узле могут, а современные накопители SSD NVMe даже быстро насыщают пропускную способность 10 Gbps. Развертывание сети, способной к еще большей пропускной способности, гарантирует, что это не ваше узкое место и не будет в ближайшее время, возможно 25, 40 или даже 100 Gbps.
Диски
При планировании размера кластера Ceph важно учитывать время восстановления. Особенно с небольшими кластерами, восстановление может занять много времени. Рекомендуется использовать твердотельные накопители вместо жестких дисков в небольших установках, чтобы сократить время восстановления, минимизируя вероятность последующего сбоя во время восстановления.
В целом SSD накопители обеспечивают больше операций ввода-вывода, чем вращающиеся диски. Этот факт и более высокая стоимость могут сделать привлекательным разделение пулов на основе классов устройств (см раздел 4.2.9). Другая возможность ускорить OSD — использовать более быстрый диск для журнала или DB/Write-Ahead-Log устройства (см. раздел Ceph OSD.) Если для нескольких операционных систем используется более быстрый диск, необходимо выбрать правильный баланс между OSD и Wal/DB (или журнальным) диском, в противном случае более быстрый диск становится узким местом для всех связанных операционных систем. Помимо типа диска, Ceph лучше всего работает с равномерным распределением размеров и количества дисков на узел. Например, 4 х 500 ГБ дисков с в каждом узле лучше, чем смешанная установка с одним 1 ТБ и три 250 ГБ диска.
Также необходимо сбалансировать количество OSD и емкость одного OSD. Большая емкость позволяет увеличить плотность хранения, но это также означает, что сбой одного OSD сразу заставляет ceph восстанавливать большее количество данных.
Отказ от RAID
Поскольку Ceph самостоятельно обрабатывает избыточность объектов данных и распаралеливание операций записи на диски (OSD) , использование RAID — контроллера обычно не улучшает производительность или доступность. Напротив, Ceph предназначен для работы напрямую с дисками самостоятельно, без какой-либо абстракции между ними. RAID — контроллеры не предназначены для использования Ceph и могут усложнять ситуацию, а иногда даже снижать производительность, так как их алгоритмы записи и кэширования могут мешать работе Ceph.
Начальная установка и настройка Ceph
С Proxmox VE вы можете воспользоваться простым в использовании мастером установки Ceph. Щелкните на одном из узлов кластера и перейдите к разделу Ceph в дереве меню. Если пакет еще не установлен, вам будет предложено сделать это сейчас.
Мастер разделен на различные разделы, каждый из них должен быть успешно завершен, чтобы использовать Ceph. После запуска установки мастер загрузит и установит все необходимые пакеты из репозитория Ceph Proxmox VE.
После завершения первого шага, вам нужно будет создать конфигурацию. Этот шаг необходим только один раз для каждого кластера, поскольку эта конфигурация автоматически распространяется среди всех остальных узлов кластера через файловую систему конфигурации кластера Proxmox VE (pmxcfs), глава 7.
- Публичная сеть: Вы должны настроить выделенную сеть для Ceph, этот параметр является обязательным. Отделение вашего трафика Ceph настоятельно рекомендуется, потому что это может привести к проблемам с другими зависимыми от задержки службами, например, взаимодействие узлов кластера может снизить производительность Ceph, если этого не сделано.
- Сеть кластера: В качестве дополнительного шага вы можете пойти еще дальше и отделить трафик репликации разделов OSD (см. 4.2.7) и heartbeat трафик. Это облегчит работу общедоступной сети и может привести к значительному повышению производительности, особенно в больших кластерах.
У вас есть еще два варианта, которые считаются расширенными и поэтому должны изменяться только в том случае, если вы являетесь экспертом.
- Количество реплик: Определяет частоту репликации объекта.
- Минимальное количество реплик: Определяет минимальное количество требуемых реплик для I/O, помеченных как завершенные.
Вот и все, вы должны увидеть сообщение об успешном окончании установки в качестве последнего шага, с инструкциями о дальнейших действиях. Теперь вы готовы начать использовать Ceph, дальше вам нужно будет создать дополнительные мониторы (см. раздел 4.2.5), создать несколько OSD (см. раздел 4.2.7) и по крайней мере один пул (см. раздел 4.2.8).
Установка пакетов Ceph
Создание начальной конфигурации Ceph
Создание Ceph мониторов
Ceph Monitor (MON) 3 поддерживает главную копию карты кластера. Для высокой доступности необходимо иметь не менее 3 мониторов. Один монитор уже был установлен, если вы использовали мастер установки. Вам не понадобится более 3 мониторов, пока ваш кластер мал до среднего размера, только действительно большие кластеры требуют большего количества.
Создание Ceph Manager
Создание Ceph OSD
Используя GUI или с помощью коммандной строки следующим образом: Совет Мы рекомендуем размер кластера Ceph, начиная с 12 OSD, равномерно распределенных между вашими, по крайней мере, тремя узлами (4 OSD на каждом узле). Если диск использовался ранее (например, ZFS/RAID/OSD), для удаления таблицы разделов, загрузочного сектора и всех оставшихся OSD должна быть достаточно следующей команды. Внимание! Приведенная выше команда уничтожит данные на диске! Ceph Bluestore
Начиная с выпуска Ceph Kraken, был представлен новый тип хранилища ceph OSD, так называемый Bluestore 5 . Это значение по умолчанию при создании OSD начиная с Ceph Luminous.
Block.db и block.wal
- bluestore_block_
- . database, section osd
- . database, section global
- . file, section osd
- . file, section global
Создание Ceph Пулов
Пул-это логическая группа для хранения объектов. Он содержит группы размещения (PG, pg_num), набор объектов.
Если параметры не заданы, используется значение по умолчанию 128PG, size 3 реплики и min_size 2 реплики для обслуживания объектов в случае деградации пула. Примечание Количество PG по умолчанию подходит для 2-5 дисков. Ceph выдает предупреждение HEALTH_WARNING, если у вас слишком мало или слишком много PG в вашем кластере. Рекомендуется рассчитать число PG в зависимости от ваших настроек, в интернете вы можете найти формулу и онлайн PG калькулятор 6 . Количество PG может быть увеличено позже, но оно никогда не может быть уменьшено.
Ceph CRUSH и классы устройств
Фундамент Ceph — это его алгоритм «Controlled Replication Under Scalable Hashing» (CRUSH 8 ).
CRUSH вычисляет, где хранить и откуда извлекать данные, преимуществом этого подхода является то, что не требуется централизованная служба индексирования. CRUSH работает с картой OSD, сегментов (расположения устройств) и наборов правил (репликация данных) для пулов.
Примечание Дополнительную информацию можно найти в документации Ceph, в разделе CRUSH map a . a CRUSH map http://docs.ceph.com/docs/luminous/rados/operations/crush-map/ 8 CRUSH https://ceph.com/wp-content/uploads/2016/08/weil-crush-sc06.pdf Эта карта может быть изменена для отражения различных иерархий репликации. Реплики объектов могут быть разделены (например отказ доменов), сохраняя при этом желаемое распределение. Общим вариантом использования является использование различных классов дисков для разных пулов Ceph. По этой причине Ceph ввел классы устройств с версии luminous, чтобы удовлетворить потребность в простом создании набора правил.Классы устройств можно увидеть в выходных данных ceph osd tree. Эти классы представляют свои собственные корневые сегменты, которые можно увидеть с помощью приведенной ниже команды. Пример вывода формы приведенной выше команды:
Ceph Client
Затем можно настроить Proxmox VE для использования таких пулов для хранения образов виртуальных машин или контейнеров. Просто используйте графический интерфейс, чтобы добавить новое хранилище RBD (см. раздел Ceph RADOS Block Devices (RBD) раздел 8.14).
CephFS
Proxmox VE поддерживает оба варианта, используя существующую CephFS в качестве хранилища (см. раздел 8.15) для сохранения резервных копий, ISO-файлов или шаблонов контейнеров и создавая гиперконвергентную CephFS.
Сервер метаданных (MDS)
Для функционирования CephFS необходим как минимум один сервер метаданных, который должен быть настроен и запущен. Можно просто создать его через узел Proxmox VE web GUI -> панель CephFS или в командной строке с помощью: В кластере можно создать несколько серверов метаданных. Но с настройками по умолчанию только один единовременно может быть активным. Если MDS или его узел перестает отвечать на запросы (или аварийно завершает работу), другой резервный MDS будет активирован. Можно ускорить передачу обслуживания между активным и резервным MDS помощью опции hotstandby при создании MDS, или если вы его уже создали его, вы можете установить/добавить: в соответствующем разделе MDS файла ceph.conf . Если этот параметр включен, этот конкретный MDS всегда будет опрашивать активный, так что он сможет приступить к обслуживанию быстрее, поскольку он находится в готовом к обслуживанию состоянии. Но, естественно, регулярный опрос вызовет некоторую дополнительную нагрузку на вашу систему и активный MDS.
Несколько активных MDS
Начиная с Ceph Luminous (12.2.x), вы также можете использовать несколько активных серверов метаданных, но это обычно полезно только для большого количества параллельных клиентов, так как в противном случае MDS редко является узким местом. Если вы все же хотите настроить их, пожалуйста, обратитесь к документации ceph 9 .
CephFS интегрирована в Proxmox VE и вы можете легко создавать CephFS через веб-интерфейс, интерфейс командной строки или внешний API. Для этого требуются некоторые предварительные условия:
- Установка пакетов Ceph (см. раздел 4.2.3), если это уже было сделано некоторое время назад, вы можете повторно запустить его в обновленной системе, чтобы убедиться, что также установлены все пакеты, связанные с CephFS.
- Установлены Мониторы. (см. Раздел 4.2.5)
- Настроены ваши OSD. (см. Раздел 4.2.7)
- Настроен хотябы один MDS. (см. Раздел 4.2.11)
Внимание! Уничтожение CephFS сделает все его данные непригодными для использования, и может быть отменено! Если вы действительно хотите уничтожить существующий CephFS, вам сначала нужно остановить или уничтожить все сервера метаданных (MDS). Вы можете уничтожить их либо через веб-интерфейс или интерфейс командной строки, с помощью: на каждом узле Proxmox VE, где размещается демон MDS.
Ceph Мониторинг и устранение неполадок
Хорошей практикой является непрерывный мониторинг работоспособности ceph с самого начала развертывания. Как через набор инструментов самого ceph, так и путем доступа к его статусу через API Proxmox VE.
Нижеследующие команды ceph могут использоваться, чтобы увидеть, является ли кластер исправным (HEALTH_OK), есть ли предупреждения (HEALTH_WARN), или ошибки (HEALTH_ERR). Если кластер находится в нерабочем состоянии, нижеприведенные команды состояния также дадут вам обзор текущих событий и действий.
# одноразовый вывод статуса: # непрерывный вывод изменений статуса (нажать CTRL+C для остановки) Для получения более детальной информации, каждая служба ceph имеет файл журнала в /var/log/ceph/ и если нет достаточной детализации, уровень логирования можно настроить 11 .