// Module included in the following assemblies:
//
// * installing/installing_with_agent_bases_installer/preparing-to-install-with-agent-based-installer.adoc

:_mod-docs-content-type: CONCEPT
[id="understanding-agent-install_{context}"]
= Understanding Agent-based Installer

[role="_abstract"]
As an {product-title} user, you can leverage the advantages of the Assisted Installer hosted service in disconnected environments.

The Agent-based Installer uses a bootable ISO that contains the Assisted discovery agent and the Assisted Service. Both are required to perform the cluster installation, but the Assisted Service runs on only one of the hosts.

[NOTE]
====
Currently, ISO boot support on {ibm-z-name} (`s390x`) is available only for {op-system-base-full} KVM, which provides the flexibility to choose either PXE or ISO-based installation. For installations with z/VM and Logical Partition (LPAR), only PXE boot is supported.
====

The `openshift-install agent create image` subcommand generates an ephemeral ISO based on the inputs that you provide. You can choose to provide inputs through the following manifests:

Preferred manifests:

* `install-config.yaml`
* `agent-config.yaml`

Optional ZTP manifests:

* `cluster-manifests/cluster-deployment.yaml`
* `cluster-manifests/agent-cluster-install.yaml`
* `cluster-manifests/pull-secret.yaml`
* `cluster-manifests/infraenv.yaml`
* `cluster-manifests/cluster-image-set.yaml`
* `cluster-manifests/nmstateconfig.yaml`
* `mirror/registries.conf`
* `mirror/ca-bundle.crt`

[id="agent-based-installer-workflow_{context}"]
== Agent-based Installer workflow

One of the control plane hosts runs the Assisted Service at the start of the boot process and eventually becomes the bootstrap host. This node is called the *rendezvous host* (or node 0).

The Assisted Service ensures that all the hosts meet the requirements and triggers an {product-title} cluster deployment. All the nodes have the {op-system-base-full} image written to the disk. The non-bootstrap nodes reboot and initiate a cluster deployment.

Once the nodes are rebooted, the rendezvous host reboots and joins the cluster. The bootstrapping is then complete and the cluster is deployed.

.Node installation workflow
image::agent-based-installer-workflow.png[Agent-based installer workflow]

You can install a disconnected {product-title} cluster through the `openshift-install agent create image` subcommand for the following topologies:

* **A single-node {product-title} cluster**: A node that is both a control plane and compute.
* **A three-node {product-title} cluster** : A compact cluster that has three control plane nodes that are also compute nodes.
* **Highly available {product-title} cluster (HA)**: Three control plane nodes with any number of compute nodes.
* **Two-node {product-title} cluster with Arbiter**: Two control plane nodes with one local arbiter node. For more information, see "About a local arbiter node".

[id="agent-based-installer-recommended-resources_{context}"]
== Recommended resources for topologies

The following cluster resources are recommended for each topology:

.Recommended cluster resources
[options="header"]
|====
|Topology|Number of control plane nodes|Number of compute nodes|vCPU|Memory|Storage
|Single-node cluster|1|0|8 vCPUs|16 GB of RAM| 120 GB 
.2+|Two-node OpenShift cluster with Arbiter|2 (control plane nodes)|0|4 vCPUs|16 GB of RAM|120 GB
|1 (arbiter node)|0|2 vCPUs|8 GB of RAM|50 GB
|Two-node OpenShift cluster with fencing (TNF)|2|0|4 vCPUs|16 GB of RAM|120 GB
|Compact cluster|3|0 or 1|8 vCPUs|16 GB of RAM|120 GB
|HA cluster|3 to 5|2 and above |8 vCPUs|16 GB of RAM|120 GB
|====

[NOTE]
====
You can use as few as 4 vCPUs for an {sno} cluster.

However, running {sno} on 4 vCPUs leaves very little "headroom" for user applications, and creates a high risk of resource contention and performance degradation.

To ensure cluster stability at this threshold, you must take steps to minimize the total resource footprint of the cluster, such as limiting the amount of workloads running on the cluster or limiting cluster capabilities.
For more information, see "Cluster capabilities".

Otherwise, it is recommended to provide more compute resources to the cluster.
====

// Note to CQA assignee, the previous note about 4 vCPUs is for 4.22+ and shouldn't be cherry picked to earlier versions

// These supported platforms are also documented in nodes/nodes/nodes-nodes-adding-node-iso.adoc and installation-configuration-parameters.adoc

[id="agent-based-installer-supported-platforms_{context}"]
== Supported platforms

In the `install-config.yaml` file, specify the platform on which to perform the installation. The following platforms are supported:

* `baremetal`
* `vsphere`
* `nutanix`
* `external`
* `none`

For a two-node {product-title} cluster with fencing (TNF), only the following platforms are supported:

* `baremetal`
* `external`
* `none`
+
The `vsphere` and `nutanix` platforms are not supported for two-node clusters with fencing.

[IMPORTANT]
====
For platform `none`:

* The `none` option requires the provision of DNS name resolution and load balancing infrastructure in your cluster. See _Requirements for a cluster using the platform "none" option_ in the "Additional resources" section for more information.

* See "Deploying OpenShift 4.x on non-tested platforms using the bare metal install method" before you attempt to install an {product-title} cluster in virtualized or cloud environments.
====

[NOTE]
====
For installations on {ibm-z-name} (`s390x`) architecture, the minimum memory requirement is 24 GB RAM per host instead of 16 GB.
====
