]> git.proxmox.com Git - pve-docs.git/blobdiff - pvecm.adoc
vrf : remove net.ipv4.tcp_l3mdev_accept=1 sysctl tuning
[pve-docs.git] / pvecm.adoc
index 47996706eb7ca633b6fd2ee7995b2a35563e99ca..7c786bc99f7f158f442c05becf10458623be6ab6 100644 (file)
@@ -1,3 +1,4 @@
+[[chapter_pvecm]]
 ifdef::manvolnum[]
 pvecm(1)
 ========
@@ -74,6 +75,8 @@ manually enabled first.
 * We recommend a dedicated NIC for the cluster traffic, especially if
   you use shared storage.
 
+* Root password of a cluster node is required for adding nodes.
+
 NOTE: It is not possible to mix Proxmox VE 3.x and earlier with
 Proxmox VE 4.0 cluster nodes.
 
@@ -85,14 +88,14 @@ First, install {PVE} on all nodes. Make sure that each node is
 installed with the final hostname and IP configuration. Changing the
 hostname and IP is not possible after cluster creation.
 
-Currently the cluster creation has to be done on the console, so you
-need to login via `ssh`.
+Currently the cluster creation can either be done on the console(login via `ssh`) or the GUI.
 
+[[pvecm_create_cluster]]
 Create the Cluster
 ------------------
 
 Login via `ssh` to the first {pve} node. Use a unique name for your cluster.
-This name cannot be changed later.
+This name cannot be changed later. The cluster name follows the same rules as node names.
 
  hp1# pvecm create YOUR-CLUSTER-NAME
 
@@ -104,7 +107,22 @@ To check the state of your cluster use:
 
  hp1# pvecm status
 
+Multiple Clusters In Same Network
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+It is possible to create multiple clusters in the same physical or logical
+network. Each cluster must have a unique name, which is used to generate the
+cluster's multicast group address. As long as no duplicate cluster names are
+configured in one network segment, the different clusters won't interfere with
+each other.
+
+If multiple clusters operate in a single network it may be beneficial to setup
+an IGMP querier and enable IGMP Snooping in said network. This may reduce the
+load of the network significantly because multicast packets are only delivered
+to endpoints of the respective member nodes.
 
+
+[[pvecm_join_node_to_cluster]]
 Adding Nodes to the Cluster
 ---------------------------
 
@@ -170,6 +188,7 @@ Membership information
          4          1 hp4
 ----
 
+[[adding-nodes-with-separated-cluster-network]]
 Adding Nodes With Separated Cluster Network
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -444,7 +463,7 @@ Separate On Cluster Creation
 This is possible through the 'ring0_addr' and 'bindnet0_addr' parameter of
 the 'pvecm create' command used for creating a new cluster.
 
-If you have setup a additional NIC with a static address on 10.10.10.1/25
+If you have setup an additional NIC with a static address on 10.10.10.1/25
 and want to send and receive all cluster communication over this interface
 you would execute:
 
@@ -459,6 +478,9 @@ To check if everything is working properly execute:
 systemctl status corosync
 ----
 
+Afterwards, proceed as descripted in the section to
+<<adding-nodes-with-separated-cluster-network,add nodes with a separated cluster network>>.
+
 [[separate-cluster-net-after-creation]]
 Separate After Cluster Creation
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -607,6 +629,7 @@ systemctl status corosync
 If corosync runs again correct restart corosync also on all other nodes.
 They will then join the cluster membership one by one on the new network.
 
+[[pvecm_rrp]]
 Redundant Ring Protocol
 ~~~~~~~~~~~~~~~~~~~~~~~
 To avoid a single point of failure you should implement counter measurements.
@@ -876,7 +899,7 @@ xref:pct_migration[Container Migration Chapter]
 Migration Type
 ~~~~~~~~~~~~~~
 
-The migration type defines if the migration data should be sent over a
+The migration type defines if the migration data should be sent over an
 encrypted (`secure`) channel or an unencrypted (`insecure`) one.
 Setting the migration type to insecure means that the RAM content of a
 virtual guest gets also transferred unencrypted, which can lead to