]> git.proxmox.com Git - pve-docs.git/blobdiff - pveceph.adoc
docs: fix typos
[pve-docs.git] / pveceph.adoc
index ebd632a27541782b4056fb733af6f089ec70765f..9101ba5b98e521bd16e20a3aa3a9883db7c6ac4b 100644 (file)
@@ -134,7 +134,7 @@ That means that you should avoid maxing out your available memory already on
 normal operation, but rather leave some headroom to cope with outages.
 
 The OSD service itself will use additional memory. The Ceph BlueStore backend of
-the daemon requires by default **3-5 GiB of memory**, b (adjustable).
+the daemon requires by default **3-5 GiB of memory** (adjustable).
 
 .Network
 We recommend a network bandwidth of at least 10 Gbps, or more, to be used
@@ -238,24 +238,36 @@ xref:chapter_pmxcfs[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.
+[[pve_ceph_wizard_networks]]
+
+* *Public Network:* This network will be used for public storage communication
+  (e.g., for virtual machines using a Ceph RBD backed disk, or a CephFS mount),
+  and communication between the different Ceph services. This setting is
+  required.
+  +
+  Separating your Ceph traffic from the {pve} cluster communication (corosync),
+  and possible the front-facing (public) networks of your virtual guests, is
+  highly recommended. Otherwise, Ceph's high-bandwidth IO-traffic could cause
+  interference with other low-latency dependent services.
 
 [thumbnail="screenshot/gui-node-ceph-install-wizard-step2.png"]
 
-* *Cluster Network:* As an optional step, you can go even further and
-separate the xref:pve_ceph_osds[OSD] replication & heartbeat traffic
-as well. This will relieve the public network and could lead to
-significant performance improvements, especially in large clusters.
+* *Cluster Network:* Specify to separate the xref:pve_ceph_osds[OSD] replication
+  and heartbeat traffic as well. This setting is optional.
+  +
+  Using a physically separated network is recommended, as it will relieve the
+  Ceph public and the virtual guests network, while also providing a significant
+  Ceph performance improvements.
+  +
+  The Ceph cluster network can be configured and moved to another physically
+  separated network at a later time.
 
-You have two more options which are considered advanced and therefore
-should only changed if you know what you are doing.
+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.
+* *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.
 
@@ -274,7 +286,7 @@ CLI Installation of Ceph Packages
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Alternatively to the the recommended {pve}  Ceph installation wizard available
-in the web-interface, you can use the following CLI command on each node:
+in the web interface, you can use the following CLI command on each node:
 
 [source,bash]
 ----
@@ -406,7 +418,7 @@ network. It is recommended to use one OSD per physical disk.
 Create OSDs
 ~~~~~~~~~~~
 
-You can create an OSD either via the {pve} web-interface or via the CLI using
+You can create an OSD either via the {pve} web interface or via the CLI using
 `pveceph`. For example:
 
 [source,bash]
@@ -524,7 +536,7 @@ known as **P**lacement **G**roups (`PG`, `pg_num`).
 Create and Edit Pools
 ~~~~~~~~~~~~~~~~~~~~~
 
-You can create and edit pools from the command line or the web-interface of any
+You can create and edit pools from the command line or the web interface of any
 {pve} host under **Ceph -> Pools**.
 
 When no options are given, we set a default of **128 PGs**, a **size of 3
@@ -555,8 +567,8 @@ pveceph pool create <pool-name> --add_storages
 ----
 
 TIP: 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, keep the `Add as Storage' checkbox checked in the web interface, or use the
+command-line option '--add_storages' at pool creation.
 
 Pool Options
 ^^^^^^^^^^^^
@@ -930,7 +942,7 @@ ensure that all CephFS related packages get installed.
 - xref:pveceph_fs_mds[Setup at least one MDS]
 
 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`,
+either the Web GUI's `Node -> CephFS` panel or the command-line tool `pveceph`,
 for example:
 
 ----
@@ -970,7 +982,7 @@ Where `<STORAGE-NAME>` is the name of the CephFS storage in your {PVE}.
 
 * 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
+  interface or via the command-line interface, for the latter you would issue
   the following command:
 +
 ----
@@ -1068,6 +1080,56 @@ scrubs footnote:[Ceph scrubbing {cephdocs-url}/rados/configuration/osd-config-re
 are executed.
 
 
+[[pveceph_shutdown]]
+Shutdown {pve} + Ceph HCI cluster
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+To shut down the whole {pve} + Ceph cluster, first stop all Ceph clients. These
+will mainly be VMs and containers. If you have additional clients that might
+access a Ceph FS or an installed RADOS GW, stop these as well.
+Highly available guests will switch their state to 'stopped' when powered down
+via the {pve} tooling.
+
+Once all clients, VMs and containers are off or not accessing the Ceph cluster
+anymore, verify that the Ceph cluster is in a healthy state. Either via the Web UI
+or the CLI:
+
+----
+ceph -s
+----
+
+To disable all self-healing actions, and to pause any client IO in the Ceph
+cluster, enable the following OSD flags in the **Ceph -> OSD** panel or via the
+CLI:
+
+----
+ceph osd set noout
+ceph osd set norecover
+ceph osd set norebalance
+ceph osd set nobackfill
+ceph osd set nodown
+ceph osd set pause
+----
+
+Start powering down your nodes without a monitor (MON). After these nodes are
+down, continue by shutting down nodes with monitors on them.
+
+When powering on the cluster, start the nodes with monitors (MONs) first. Once
+all nodes are up and running, confirm that all Ceph services are up and running
+before you unset the OSD flags again:
+
+----
+ceph osd unset pause
+ceph osd unset nodown
+ceph osd unset nobackfill
+ceph osd unset norebalance
+ceph osd unset norecover
+ceph osd unset noout
+----
+
+You can now start up the guests. Highly available guests will change their state
+to 'started' when they power on.
+
 Ceph Monitoring and Troubleshooting
 -----------------------------------