mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 12:46:18 +01:00
188 lines
8.2 KiB
Plaintext
188 lines
8.2 KiB
Plaintext
// This is included in the following assemblies:
|
|
//
|
|
// installing_ibm_cloud_classic/install-ibm-cloud-installing-on-ibm-cloud.adoc
|
|
:_mod-docs-content-type: PROCEDURE
|
|
[id="setting-up-ibm-cloud-infrastructure_{context}"]
|
|
= Setting up {ibm-cloud-bm-title} infrastructure
|
|
|
|
To deploy an {product-title} cluster on {ibm-cloud-bm} infrastructure, you must first provision the {ibm-cloud-name} nodes.
|
|
|
|
[IMPORTANT]
|
|
====
|
|
Red Hat supports IPMI and PXE on the `provisioning` network only. Red Hat has not tested Red Fish, virtual media, or other complementary technologies such as Secure Boot on {ibm-cloud-name} deployments. The `provisioning` network is required.
|
|
====
|
|
|
|
You can customize {ibm-cloud-name} nodes using the {ibm-cloud-name} API. When creating {ibm-cloud-name} nodes, you must consider the following requirements.
|
|
|
|
[discrete]
|
|
== Use one data center per cluster
|
|
|
|
All nodes in the {product-title} cluster must run in the same {ibm-cloud-name} data center.
|
|
|
|
[discrete]
|
|
== Create public and private VLANs
|
|
|
|
Create all nodes with a single public VLAN and a single private VLAN.
|
|
|
|
[discrete]
|
|
== Ensure subnets have sufficient IP addresses
|
|
|
|
{ibm-cloud-name} public VLAN subnets use a `/28` prefix by default, which provides 16 IP addresses. That is sufficient for a cluster consisting of three control plane nodes, four worker nodes, and two IP addresses for the API VIP and Ingress VIP on the `baremetal` network. For larger clusters, you might need a smaller prefix.
|
|
|
|
{ibm-cloud-name} private VLAN subnets use a `/26` prefix by default, which provides 64 IP addresses. {ibm-cloud-bm} uses private network IP addresses to access the Baseboard Management Controller (BMC) of each node. {product-title} creates an additional subnet for the `provisioning` network. Network traffic for the `provisioning` network subnet routes through the private VLAN. For larger clusters, you might need a smaller prefix.
|
|
|
|
.IP addresses per prefix
|
|
[options="header"]
|
|
|====
|
|
|IP addresses |Prefix
|
|
|32| `/27`
|
|
|64| `/26`
|
|
|128| `/25`
|
|
|256| `/24`
|
|
|====
|
|
|
|
[discrete]
|
|
== Configuring NICs
|
|
|
|
{product-title} deploys with two networks:
|
|
|
|
- `provisioning`: The `provisioning` network is a non-routable network used for provisioning the underlying operating system on each node that is a part of the {product-title} cluster.
|
|
|
|
- `baremetal`: The `baremetal` network is a routable network. You can use any NIC order to interface with the `baremetal` network, provided it is not the NIC specified in the `provisioningNetworkInterface` configuration setting or the NIC associated to a node's `bootMACAddress` configuration setting for the `provisioning` network.
|
|
|
|
While the cluster nodes can contain more than two NICs, the installation process only focuses on the first two NICs. For example:
|
|
|
|
[options="header"]
|
|
|===
|
|
|NIC |Network |VLAN
|
|
| NIC1 | `provisioning` | <provisioning_vlan>
|
|
| NIC2 | `baremetal` | <baremetal_vlan>
|
|
|===
|
|
|
|
In the previous example, NIC1 on all control plane and worker nodes connects to the non-routable network (`provisioning`) that is only used for the installation of the {product-title} cluster. NIC2 on all control plane and worker nodes connects to the routable `baremetal` network.
|
|
|
|
[options="header"]
|
|
|===
|
|
|PXE |Boot order
|
|
| NIC1 PXE-enabled `provisioning` network | 1
|
|
| NIC2 `baremetal` network. | 2
|
|
|===
|
|
|
|
[NOTE]
|
|
====
|
|
Ensure PXE is enabled on the NIC used for the `provisioning` network and is disabled on all other NICs.
|
|
====
|
|
|
|
[discrete]
|
|
== Configuring canonical names
|
|
|
|
Clients access the {product-title} cluster nodes over the `baremetal` network. Configure {ibm-cloud-name} subdomains or subzones where the canonical name extension is the cluster name.
|
|
|
|
----
|
|
<cluster_name>.<domain>
|
|
----
|
|
|
|
For example:
|
|
|
|
----
|
|
test-cluster.example.com
|
|
----
|
|
|
|
[discrete]
|
|
== Creating DNS entries
|
|
|
|
You must create DNS `A` record entries resolving to unused IP addresses on the public subnet for the following:
|
|
|
|
[width="100%", options="header"]
|
|
|=====
|
|
| Usage | Host Name | IP
|
|
| API | api.<cluster_name>.<domain> | <ip>
|
|
| Ingress LB (apps) | *.apps.<cluster_name>.<domain> | <ip>
|
|
|=====
|
|
|
|
Control plane and worker nodes already have DNS entries after provisioning.
|
|
|
|
The following table provides an example of fully qualified domain names. The API and Nameserver addresses begin with canonical name extensions. The host names of the control plane and worker nodes are examples, so you can use any host naming convention you prefer.
|
|
|
|
[width="100%", options="header"]
|
|
|=====
|
|
| Usage | Host Name | IP
|
|
| API | api.<cluster_name>.<domain> | <ip>
|
|
| Ingress LB (apps) | *.apps.<cluster_name>.<domain> | <ip>
|
|
| Provisioner node | provisioner.<cluster_name>.<domain> | <ip>
|
|
| Master-0 | openshift-master-0.<cluster_name>.<domain> | <ip>
|
|
| Master-1 | openshift-master-1.<cluster_name>.<domain> | <ip>
|
|
| Master-2 | openshift-master-2.<cluster_name>.<domain> | <ip>
|
|
| Worker-0 | openshift-worker-0.<cluster_name>.<domain> | <ip>
|
|
| Worker-1 | openshift-worker-1.<cluster_name>.<domain> | <ip>
|
|
| Worker-n | openshift-worker-n.<cluster_name>.<domain> | <ip>
|
|
|=====
|
|
|
|
{product-title} includes functionality that uses cluster membership information to generate `A` records. This resolves the node names to their IP addresses. After the nodes are registered with the API, the cluster can disperse node information without using CoreDNS-mDNS. This eliminates the network traffic associated with multicast DNS.
|
|
|
|
[IMPORTANT]
|
|
====
|
|
After provisioning the {ibm-cloud-name} nodes, you must create a DNS entry for the `api.<cluster_name>.<domain>` domain name on the external DNS because removing CoreDNS causes the local entry to disappear. Failure to create a DNS record for the `api.<cluster_name>.<domain>` domain name in the external DNS server prevents worker nodes from joining the cluster.
|
|
====
|
|
|
|
[discrete]
|
|
== Network Time Protocol (NTP)
|
|
|
|
Each {product-title} node in the cluster must have access to an NTP server. {product-title} nodes use NTP to synchronize their clocks. For example, cluster nodes use SSL certificates that require validation, which might fail if the date and time between the nodes are not in sync.
|
|
|
|
[IMPORTANT]
|
|
====
|
|
Define a consistent clock date and time format in each cluster node's BIOS settings, or installation might fail.
|
|
====
|
|
|
|
[discrete]
|
|
== Configure a DHCP server
|
|
|
|
{ibm-cloud-bm} does not run DHCP on the public or private VLANs. After provisioning {ibm-cloud-name} nodes, you must set up a DHCP server for the public VLAN, which corresponds to {product-title}'s `baremetal` network.
|
|
|
|
[NOTE]
|
|
====
|
|
The IP addresses allocated to each node do not need to match the IP addresses allocated by the {ibm-cloud-bm} provisioning system.
|
|
====
|
|
|
|
See the "Configuring the public subnet" section for details.
|
|
|
|
[discrete]
|
|
== Ensure BMC access privileges
|
|
|
|
The "Remote management" page for each node on the dashboard contains the node's intelligent platform management interface (IPMI) credentials. The default IPMI privileges prevent the user from making certain boot target changes. You must change the privilege level to `OPERATOR` so that Ironic can make those changes.
|
|
|
|
In the `install-config.yaml` file, add the `privilegelevel` parameter to the URLs used to configure each BMC. See the "Configuring the install-config.yaml file" section for additional details. For example:
|
|
|
|
[source,yaml]
|
|
----
|
|
ipmi://<IP>:<port>?privilegelevel=OPERATOR
|
|
----
|
|
|
|
Alternatively, contact {ibm-cloud-name} support and request that they increase the IPMI privileges to `ADMINISTRATOR` for each node.
|
|
|
|
[discrete]
|
|
== Create bare metal servers
|
|
|
|
Create bare metal servers in the link:https://cloud.ibm.com[{ibm-cloud-name} dashboard] by navigating to *Create resource* -> *Bare Metal Servers for Classic*.
|
|
|
|
Alternatively, you can create bare metal servers with the `ibmcloud` CLI utility. For example:
|
|
|
|
[source,terminal]
|
|
----
|
|
$ ibmcloud sl hardware create --hostname <SERVERNAME> \
|
|
--domain <DOMAIN> \
|
|
--size <SIZE> \
|
|
--os <OS-TYPE> \
|
|
--datacenter <DC-NAME> \
|
|
--port-speed <SPEED> \
|
|
--billing <BILLING>
|
|
----
|
|
|
|
See link:https://cloud.ibm.com/docs/cli?topic=cli-install-ibmcloud-cli[Installing the stand-alone {ibm-cloud-name} CLI] for details on installing the {ibm-cloud-name} CLI.
|
|
|
|
[NOTE]
|
|
====
|
|
{ibm-cloud-name} servers might take 3-5 hours to become available.
|
|
====
|