diff --git a/config/sidebar/index.md b/config/sidebar/index.md index c52029773..22c0c4675 100644 --- a/config/sidebar/index.md +++ b/config/sidebar/index.md @@ -548,6 +548,8 @@ + [On-Prem Cloud Platform](products/hosted-private-cloud-hosted-private-cloud-opcp) + [Overview](hosted-private-cloud/opcp/overview) + [Getting started](hosted-private-cloud-hosted-private-cloud-opcp-getting-started) + + [OPCP - Network integration and platform connectivity](hosted-private-cloud/opcp/opcp-network-architecture) + + [OPCP - Technical prerequisites for deployment](hosted-private-cloud/opcp/opcp-prerequisites) + [Getting started with your OPCP](hosted-private-cloud/opcp/getting-started) + [OPCP - How to install a controller](hosted-private-cloud/opcp/install-controller) + [OPCP - Node lifecycle](hosted-private-cloud/opcp/node-lifecycle) diff --git a/docs/de/guides/hosted-private-cloud/opcp/opcp-network-architecture.mdx b/docs/de/guides/hosted-private-cloud/opcp/opcp-network-architecture.mdx new file mode 120000 index 000000000..6e2260731 --- /dev/null +++ b/docs/de/guides/hosted-private-cloud/opcp/opcp-network-architecture.mdx @@ -0,0 +1 @@ +../../../../en/guides/hosted-private-cloud/opcp/opcp-network-architecture.mdx \ No newline at end of file diff --git a/docs/de/guides/hosted-private-cloud/opcp/opcp-prerequisites.mdx b/docs/de/guides/hosted-private-cloud/opcp/opcp-prerequisites.mdx new file mode 120000 index 000000000..e0d607566 --- /dev/null +++ b/docs/de/guides/hosted-private-cloud/opcp/opcp-prerequisites.mdx @@ -0,0 +1 @@ +../../../../en/guides/hosted-private-cloud/opcp/opcp-prerequisites.mdx \ No newline at end of file diff --git a/docs/en/guides/hosted-private-cloud/opcp/opcp-network-architecture.mdx b/docs/en/guides/hosted-private-cloud/opcp/opcp-network-architecture.mdx new file mode 100644 index 000000000..0f32da9ac --- /dev/null +++ b/docs/en/guides/hosted-private-cloud/opcp/opcp-network-architecture.mdx @@ -0,0 +1,242 @@ +--- +title: OPCP - Network integration and platform connectivity +description: Understand how OPCP integrates into your network — data plane, out-of-band (OOB) administration network, and which flows to allow per service model +lastUpdated: 2026-06-03 +--- + +## Objective + +**On-Prem Cloud Platform (OPCP)** is a private cloud solution deployed on your own infrastructure, delivered as an integrated stack (servers, switches, automation, control plane). Before and during deployment, your team needs to understand how OPCP interconnects with your enterprise network: which flows it sends, which services it consumes from you, and – if you have subscribed to the **Fully managed by OVHcloud** offering – how OVHcloud reaches the platform to operate it remotely. + +**The aim of this guide is to present OPCP's network architecture**, distinguishing: + +- the **out-of-band (OOB) administration network** used to operate the platform, +- the **data plane** used by the workloads hosted on the OPCP servers. + +It is intended for both **architects** preparing a deployment and **administrators** taking over a platform that has already been delivered. + +## Requirements + +- A general understanding of your enterprise network architecture (VLANs, addressing plan, edge devices, firewalls). +- Knowing the **OPCP subscription model** you have chosen (Self-managed or Fully managed by OVHcloud). +- Having reviewed the [OPCP technical prerequisites](/guides/hosted-private-cloud/opcp/opcp-prerequisites) you need to provide before deployment. + +## Instructions + +### 1. OPCP service models + +OPCP is available with two levels of delegation. The chosen model determines **who operates** the platform's control plane and therefore **which interconnection flows** must be opened toward OVHcloud. + +| Model | Who operates the **Core** (control plane)? | Who operates the **application services**? | Interconnection to OVHcloud required? | +|------|---|---|---| +| **Self-managed** | The customer | The customer | No | +| **Fully managed by OVHcloud** | OVHcloud | OVHcloud | **Yes** (IPsec) | + +Whatever the model, **managing what you deploy on top of the services provided by OPCP remains your responsibility**: virtual machines, containers, bare-metal instances, applications, business data, application-level backups, and so on. OPCP provides the platform; you remain in charge of the use you make of it. + +Whatever the model, the hardware architecture and the logical separation between networks are **identical**. The differences between Self-managed and Fully managed by OVHcloud relate to two points: + +1. **The level of access to administration interfaces.** In Self-managed mode, your teams have full control of OPCP's management interfaces: OpenStack API, SSH access to the controllers, and two command-line tools embedded on the platform: + - **`opcp-cli`**, which lets you **configure OPCP** (declaring platform resources, managing components, operational tasks), + - **`opcp-diag`**, which produces a **platform health status** and **extracts the logs** required for remote diagnostics when an incident occurs. + + In Fully managed by OVHcloud mode, these interfaces are operated by the OVHcloud teams; your teams retain consultation and application-level operation access, but platform administration is delegated. +2. **The need for an IPsec link between your administration network and OVHcloud.** Required in Fully managed by OVHcloud mode so that OVHcloud teams can operate the platform remotely; this link does not exist in Self-managed mode. + +### 2. The two OPCP network planes + +OPCP relies on a strict separation between two networks with very different roles, equipment, and uses. **This separation is structural**: it underpins the security, resiliency, and quality of service of the platform. + +#### The data plane + +The data plane is the network **used by the workloads** hosted on the OPCP servers (virtual machines, containers, bare-metal instances exposed via OpenStack). It carries: + +- the application traffic in and out of the instances, +- the communications between instances inside OPCP, +- the flows between OPCP and the rest of your production information system (databases, internal services, end users, and so on). + +In terms of hardware, the data plane relies on: + +- the **data interfaces** on the servers, +- redundant **Top-of-Rack (ToR) switches**, +- for multi-rack deployments, two additional families of switches: + - **edge** switches, which provide the **junction between the OPCP internal network and your upstream network**: they carry the uplink configuration toward your *Customer Upstream Data Network*, + - **spine** switches, which allow the platform to **scale beyond 3 racks** by aggregating the interconnection between the ToRs of several racks, +- **fibre uplinks** to your upstream network (*Customer Upstream Data Network*) in **40 GbE or 100 GbE**, depending on the optics validated by OVHcloud for your deployment. + +The data plane is **driven end-to-end by OPCP** through OpenStack Neutron: creating a network, a subnet or a security rule from Horizon or the API automatically propagates to the underlying switches. + +#### The out-of-band (OOB) administration network + +The OOB network is the network **through which OPCP administers itself** and through which you (and, in Fully managed by OVHcloud mode, the OVHcloud teams) reach the management interfaces. It is **physically and logically separated** from the data plane. It carries: + +- access to the **OpenStack APIs**, the **Horizon** interface, and the OPCP management interfaces (HTTPS), +- SSH access to the **OPCP Core Controllers** (`opcp-cli`, `opcp-diag`), +- the **inter-controller exchanges** that provide **control plane resiliency** in MINIPOD and FABRIC modes (state synchronisation, quorum election, VIP failover between the three OPCP Core Controllers), +- the logs and metrics emitted from OPCP toward your internal services, +- the outbound flows from OPCP toward your infrastructure services (NTP, DNS, S31 for backups, LDAP, syslog). + +In terms of hardware, the OOB network relies on: + +- the **OPCP Core Controllers**, each equipped with an OOB uplink negotiating at **10 GbE** related to your upstream infrastructure, plus a 1 GbE BMC port, +- **uplinks** toward your upstream OOB network (*Customer Upstream OOB Network*). + +:::warning +In MINIPOD and FABRIC modes, the three OPCP Core Controllers are reached through a shared virtual IP address, whose proper operation requires L2 reachability on a common untagged segment between the three OPCP Core Controllers. The availability of the control plane therefore depends directly on the availability of this network connection: a prolonged outage of the customer's OOB network can disrupt access to the administration of the platform. The **NANOPOD** mode is not concerned, since it only has one controller. +Data exchanged between the OPCP Core Controllers travels through OPCP's own network. Only the administrators' access to the control plane can be affected by issues on the OOB network. +::: + +:::warning +No direct communication is possible between the data plane and the OOB network from inside OPCP. Any cross-network communication must go through your upstream network, which leaves you in full control of the security rules between the two perimeters. +::: + +### 3. Deployment topologies + +OPCP is delivered in one of three deployment modes, sized for different use cases. These modes differ mainly in the number of supported racks and the resiliency of the control plane. The presence or absence of **spine** and **edge** switches between the racks and your upstream network is a direct consequence of this. + +| Mode | Use case | Control plane resiliency | Number of racks | Spine / Edge | +|---|---|---|---|---| +| **NANOPOD** | Demonstration, remote sites, non-resilient infrastructures (offices, edge) | Non-resilient (1 controller) | 1 | None | +| **MINIPOD** | Compact resilient infrastructure | Resilient (3 controllers) | 2 to 3 | Edges only | +| **FABRIC** | Datacenter deployment with shared infrastructure | Resilient (3 controllers) | 3 to 10 (and beyond with *megaspine*) | Spine + Edges | + +From a network integration standpoint, the key point to keep in mind is: + +- in **NANOPOD**, the **data plane is configured directly on the Top-of-Rack (ToR) switches**: they are the ones connecting to your *Customer Upstream Data Network*; +- in **MINIPOD** and **FABRIC**, the **data plane is configured on the edge switches**, which sit between the ToRs and your upstream network. The ToR configuration remains internal to OPCP. + +The number of **OPCP Core Controllers** follows the deployment mode: **1 controller in NANOPOD**, **3 controllers in MINIPOD and FABRIC**. + +#### Single-controller configuration (NANOPOD) + +OPCP NANOPOD topology - 1 controller + +The key elements are: + +- **Customer Servers**: the servers hosting the workloads. Their data interfaces are connected to both ToRs; their BMC is attached to the management switch. +- **ToR A / ToR B** (Arista DCS-7050CX3-32S): two redundant Top-of-Rack switches. In NANOPOD mode, **they carry the data plane directly and connect to your *Customer Upstream Data Network*** through fibre uplinks at **40 GbE or 100 GbE**, depending on the optics validated by OVHcloud. +- **Management switch (mgmt)**: dedicated switch that aggregates the server BMCs and the ToR management ports. +- A single **OPCP Core Controller**, connected through a **25 GbE or 10 GbE** OOB uplink to your *Customer Upstream OOB Network*, plus a 1 GbE BMC port for its own lights-out access. + +:::warning +With a single controller, **the control plane is not redundant**: a hardware failure or maintenance operation on this controller interrupts the administration of the platform (workloads already deployed continue to run on the servers). For any production environment requiring high availability of the control plane, choose the MINIPOD or FABRIC modes. +::: + +#### Three-controller configuration (MINIPOD and FABRIC) + +OPCP MINIPOD/FABRIC topology - 3 controllers + +Compared to NANOPOD mode, the differences are: + +- **3 OPCP Core Controllers** instead of one, each connected to the upstream OOB network with a **25 GbE or 10 GbE** uplink and a 1 GbE BMC link. A **VIP** (*Virtual IP*) is shared between the three controllers: this VIP is used to reach the OpenStack APIs and Horizon, regardless of which controller is active. +- The BMCs of all three controllers, like those of the servers, are exposed on your upstream OOB network. This ensures lights-out access to every piece of equipment even if a component internal to OPCP fails. +- **Edge switches** are inserted between the ToRs and your upstream network. **The data plane is configured on these edges**, no longer on the ToRs. In **FABRIC** mode, **spine** switches are also present to aggregate several racks; beyond ten racks, a **megaspine** layer can be added. + +### 4. How OPCP integrates with your environment + +The integration of OPCP relies on **two network perimeters** that you provide and keep under your control. + +#### Data plane side (*Customer Upstream Data Network*) + +This is your production network. OPCP connects to it through the fibre uplinks of the ToRs (in NANOPOD mode) or the edges (in MINIPOD and FABRIC modes), at speeds of **40 GbE or 100 GbE** depending on the optics validated by OVHcloud. + +**The configuration of the network attachment (uplinks toward your upstream) is driven by OPCP** through an API exposed by the platform. Depending on the deployment mode: + +- in **NANOPOD**, the configuration is applied directly on the **ToRs**; +- in **MINIPOD** and **FABRIC**, it is applied on the **edges**. + +Beyond this attachment, the content and segmentation of the data plane remain **fully driven by OPCP** through OpenStack Neutron: each Neutron network is exposed on the uplinks using one of the three modes below. + +##### Access mode +The uplink port is attached to **a single Neutron network** and presents traffic as classic **802.1Q** to your upstream equipment. This is the simplest mode and is suitable when an upstream port is dedicated to a single OPCP network. + +If your instances push their own VLAN tags inside the Neutron network (hypervisor-level tagging, specific guest needs, etc.), those inner tags are transparently handled by OPCP and your upstream still only sees standard 802.1Q frames — there is nothing extra to configure on your side. + +##### Trunk mode +The uplink port carries **several Neutron networks** over a single physical interface, each distinguished by its own VLAN ID. Because the VLAN tag set by OPCP is preserved end-to-end and never decapsulated, the framing your upstream sees depends on what happens **inside** each Neutron network: + +- **802.1Q** — if your instances do not use VLANs inside the Neutron network. Your upstream equipment must be configured to recognise the VLAN IDs assigned by OPCP. +- **802.1ad (QinQ)** — if your instances push their own VLAN tags inside the Neutron network. The OPCP-assigned VLAN becomes the outer tag and the instance VLANs become inner tags. **Your upstream equipment must be able to handle double encapsulation.** + +Both can coexist on the same trunk: each Neutron network is independent, so some can be plain 802.1Q while others are 802.1ad, depending on how each one is used. + +#### Out-of-band side (*Customer Upstream OOB Network*) + +This is the perimeter from which OPCP is administered. You need to plan for: + +- a **dedicated subnet** for OPCP, with a default gateway. This subnet hosts the controllers (and their VIP in HA configuration), +- **DNS resolution**: a domain name you delegate to OPCP (for example `*.opcp01.example.com`), together with a *forwarder* from your internal DNS resolvers to the OPCP VIP, +- **filtering rules** allowing the flows described in the matrix below, +- **access to at least one NTP time source** from OPCP's administration network (mandatory) and, depending on the options you choose, to your other internal services (syslog, S3, LDAP). + +### 5. Flow matrix to allow + +All the flows below originate from or terminate on the **out-of-band (OOB) administration network** of OPCP. None of them uses the data plane. + +#### Inbound flows (you → OPCP) + +| Source | Destination | Service | Protocol / Port | +|--------|-------------|---------|------------------| +| Administration workstations / OPCP users | OPCP controllers VIP | OpenStack API, Horizon, management interfaces | TCP/443 | +| Administrators (Self-managed mode) | OPCP controllers | SSH (`opcp-cli`, `opcp-diag`) | TCP/22 | + +#### Outbound flows (OPCP → you) + +| Source | Destination | Service | Protocol / Port | Mandatory | +|---|---|---|---|---| +| OPCP administration network | Your NTP servers | Time synchronisation | UDP/123 | **Mandatory** | +| OPCP administration network | Your DNS resolvers | External name resolution | UDP/53 | Optional | +| OPCP administration network | Your syslog servers | Log centralisation | UDP/514 or TCP/514 | Recommended | +| OPCP administration network | Your S3 endpoint | Infrastructure backup | TCP/443 | Recommended | +| OPCP administration network | Your S3 endpoint | Long-term metrics storage | TCP/443 | Recommended | +| OPCP administration network | Your Active Directory / IdP | LDAP identity federation | TCP/636 (LDAPS) | Optional | + +:::info +OPCP is designed to run in **air-gap** mode: none of these flows requires Internet access. The only expected destinations are services from your own information system. +::: + +### 6. The OVHcloud interconnection (Fully managed by OVHcloud mode) + +If you have subscribed to the **Fully managed by OVHcloud** offering, OVHcloud needs to reach your OPCP administration network in order to provide remote operations and support. This interconnection relies on a **site-to-site IPsec tunnel** between an edge device on the OVHcloud side and an edge device on the customer side. + +The default parameters proposed by OVHcloud are: + +- **IKEv2 only** (IKEv1 is not supported), +- **PSK** (Pre-Shared Key) authentication, +- **AES-256** encryption, +- **SHA-256** hash, +- **Diffie-Hellman group 14**, +- **PFS** (Perfect Forward Secrecy) enabled. + +:::warning +OVHcloud strongly discourages lowering the encryption level below AES-256. If a constraint on your side prevents the use of these parameters, contact your OVHcloud point of contact to study the alternatives. +::: + +To prepare this interconnection, you must provide OVHcloud with: + +- the **public IP address** of your IPsec endpoint, +- the **subnet** on your side to expose in the tunnel (typically the OPCP administration subnet), +- the agreed **PSK** (transmitted through a secure channel: check with your OVHcloud point of contact). + +Once the tunnel is established, OVHcloud teams reach your OPCP **only** through this interconnection, using the same flows as those described in the matrix above. No direct access from the Internet is opened on your platform. + +### 7. Addressing plan and naming + +When preparing the deployment, you will provide OVHcloud with: + +- the **subnet** allocated to the OPCP administration network and its **default gateway** (for example: subnet `172.30.1.0/24`, gateway `172.30.1.254`), +- the **hostnames and IP addresses** of the OPCP controllers, as well as the **VIP** shared in HA configuration (for example: `opcp-controller-0` / `172.30.1.10`, `opcp-controller-1` / `172.30.1.11`, `opcp-controller-2` / `172.30.1.12`, VIP `172.30.1.5`), +- the **domain name** you delegate to OPCP (for example: `opcp01.example.com`). + +The addressing plan and naming convention are **entirely under your control**: OVHcloud does not impose any format. Refer to the [OPCP technical prerequisites](/guides/hosted-private-cloud/opcp/opcp-prerequisites) guide for the full list of elements to provide. + +## Go further + +- [OPCP - Technical prerequisites for deployment](/guides/hosted-private-cloud/opcp/opcp-prerequisites) +- [Getting started with your OPCP](/guides/hosted-private-cloud/opcp/getting-started) + +For training or technical assistance implementing our solutions, contact your sales representative or visit our [Professional Services](/links/professional-services) page to request a quote and have your project analyzed by our experts. + +Join our [community of users](/links/community). + +1: S3 is a trademark of Amazon Technologies, Inc. OVHcloud's service is not sponsored by, endorsed by, or otherwise affiliated with Amazon Technologies, Inc. diff --git a/docs/en/guides/hosted-private-cloud/opcp/opcp-prerequisites.mdx b/docs/en/guides/hosted-private-cloud/opcp/opcp-prerequisites.mdx new file mode 100644 index 000000000..aac4dc5b1 --- /dev/null +++ b/docs/en/guides/hosted-private-cloud/opcp/opcp-prerequisites.mdx @@ -0,0 +1,327 @@ +--- +title: OPCP - Technical prerequisites for deployment +description: Discover the list of configuration items you need to provide to OVHcloud to prepare and deploy your OPCP platform +lastUpdated: 2026-06-03 +--- + +## Objective + +Deploying **On-Prem Cloud Platform (OPCP)** at your site requires gathering a set of configuration items beforehand. Some are mandatory for the initial bootstrap and cannot be changed after installation; others are optional or can be adjusted later. Preparing this list upfront is the **main condition for a fast deployment with no back-and-forth**. + +**The aim of this guide is to present, for each prerequisite, what it is used for, how to express it, and whether it is mandatory or optional**. + +It is intended for both **architects** preparing the delivery and **administrators** who want to understand what was configured on their platform. + +## Requirements + +- Having read the [OPCP - Network integration and platform connectivity](/guides/hosted-private-cloud/opcp/opcp-network-architecture) guide, which describes the network architecture in which these prerequisites take place. +- Knowing the **OPCP subscription model** you have chosen (Self-managed or Fully managed by OVHcloud). +- Having an identified **OVHcloud point of contact** for the delivery, to whom you will transmit the gathered items. + +## Instructions + +### 1. How to read this guide + +For each prerequisite, you will find: + +- a **description** explaining its role on the platform, +- whether it is **mandatory or optional**, +- whether it can be **modified after installation**, +- the **associated network flows** when the prerequisite implies a communication between OPCP and a service in your environment, +- a **generic example** to help you express the expected value. + +:::info +**Transmission of sensitive items.** Several prerequisites involve secrets: IPsec pre-shared key, S31 access keys, certificate private keys, and so on. These items **must not be transmitted through an insecure channel**. Agree with your OVHcloud point of contact on an appropriate transmission channel for each secret. +::: + +### 2. OVHcloud interconnection (managed mode only) + +| Field | Value | +|---|---| +| Mandatory | **Yes**, in Fully managed by OVHcloud mode | +| Modifiable after installation | Yes | +| Associated flow | Site-to-site IPsec tunnel between your endpoint and OVHcloud | + +If you have subscribed to the **Fully managed by OVHcloud** offering, an IPsec tunnel must be established between your site and OVHcloud to enable remote operations and support. You must provide: + +- the **public IP address** of your IPsec endpoint, +- the **subnet** you expose on your side (typically the OPCP administration subnet), +- the agreed **pre-shared key (PSK)** for authentication, transmitted through a secure channel. + +The default cryptographic parameters are **IKEv2 + PSK + AES-256 + SHA-256 + DH group 14 + PFS**. If your security policy requires different parameters, discuss this with your OVHcloud point of contact before deployment. + +:::warning +IKEv1 is not supported. Lowering the encryption level below AES-256 is discouraged: only consider it as a last resort. +::: + +In **Self-managed** mode, this prerequisite does not apply. + +### 3. Administration network + +| Field | Value | +|---|---| +| Mandatory | **Yes** | +| Modifiable after installation | **No** | +| Associated flow | None (local OPCP configuration) | + +Definition of the management network on which OPCP will be positioned. You must provide: + +- the **subnet** allocated to OPCP (for example: `172.30.1.0/24`), +- the **default gateway** address (for example: `172.30.1.254`). + +This network will host the OPCP controllers and their VIP. It is also the starting point for the outbound flows toward your internal services (NTP, DNS, syslog, S3, LDAP). + +:::warning +These parameters are **frozen at deployment time**: the subnet and gateway cannot be changed after installation without a full reinstallation. Validate them carefully upfront. +::: + +### 4. OPCP environment variables + +| Field | Value | +|---|---| +| Mandatory | **Yes** | +| Modifiable after installation | **No** | +| Associated flow | None | + +OPCP uses several variables to uniquely identify the deployment. They appear in Netbox, in the logs, in the monitoring, and in several other components. You must provide a value for each of them: + +| Variable | Role | Example | +|---|---|---| +| `env` | Logical identifier of the OPCP environment | `opcp-prod-0` | +| `region` | Region or geographic zone code | `par` | +| `stage` | Lifecycle stage | `prod`, `staging`, `dev` | +| `org` | Owning organisation | `mycompany` | +| `site` | Physical site identifier | `dc1` | +| `location` | Precise location within the site | `R11-1` | + +:::info +**OVHcloud does not impose any naming convention.** Adopt the nomenclature that matches your internal references. Choose it carefully: these values will be frozen and used by many components. +::: + +### 5. OPCP controller names and addresses + +| Field | Value | +|---|---| +| Mandatory | **Yes** | +| Modifiable after installation | **No** | +| Associated flow | None (local OPCP configuration) | + +For each **OPCP Core Controller** in your deployment, provide: + +- the **hostname** (FQDN or short name depending on your convention), +- the **IP address** on the administration network. + +In a 3-controller configuration, also provide the **VIP (Virtual IP)** shared between the three nodes, which will be the single entry point to the OpenStack APIs and Horizon. + +Example in a 3-controller configuration: + +| Element | Name | IP | +|---|---|---| +| Controller 0 | `opcp-controller-0` | `172.30.1.10` | +| Controller 1 | `opcp-controller-1` | `172.30.1.11` | +| Controller 2 | `opcp-controller-2` | `172.30.1.12` | +| VIP | `opcp.example.com` | `172.30.1.5` | + +### 6. Certificates + +| Field | Value | +|---|---| +| Mandatory | **Yes** | +| Modifiable after installation | Yes | +| Associated flow | None (local OPCP configuration) | + +OPCP must present valid TLS certificates for its interfaces (OpenStack API, Horizon, internal services). Three options are supported; you must choose one of them before deployment. + +#### Option A — Recommended - Intermediate certificate authority provided by the customer + +You provide an intermediate CA derived from your internal PKI. OPCP uses it to sign the service certificates. You must transmit: + +- the **intermediate CA certificate**, +- the associated **private key** (transmitted through a secure channel agreed with your OVHcloud point of contact). + +The rotation of certificates issued under this intermediate remains handled by CertManager on the OPCP side. + +#### Option B — Self-signed certificate authority generated by OPCP + +OPCP generates its own internal certificate authority and signs the required certificates. **You do not need to provide anything.** Rotation is handled automatically by CertManager. + +This is the simplest option, suitable if your security policy accepts a CA internal to the OPCP perimeter. You will however need to distribute OPCP's root certificate to your clients in order to avoid security warnings. + +#### Option C — Let's Encrypt + +OPCP requests certificates automatically from Let's Encrypt. This option requires: + +- a compatible **validation method** (HTTP-01 or DNS-01) reachable from OPCP, +- the **associated prerequisites** for this method (public resolution of the domain, outbound access to ACME servers, and so on). + +Specify with your OVHcloud point of contact the method you have chosen and the configurations to put in place on your side. + +### 7. NTP — Time synchronisation + +| Field | Value | +|---|---| +| Mandatory | **Yes** | +| Modifiable after installation | Yes | +| Associated flow | OPCP administration network → your NTP servers — UDP/123 | + +OPCP needs a reliable time source for the correct operation of all of its components (log consistency, certificate validity, quorum election, and so on). Provide: + +- one or more **IP addresses** of NTP servers, **or** **DNS names** if DNS resolution is configured. + +Example: + +- `172.30.1.200` / `ntp1.example.com` +- `172.30.1.201` / `ntp2.example.com` + +Plan for opening the **UDP/123** flow from the OPCP administration network to your NTP servers. + +### 8. DNS — Domain delegation to OPCP + +| Field | Value | +|---|---| +| Mandatory | **Yes** | +| Modifiable after installation | **No** (the DNS forwarder can be adapted as long as the FQDNs remain stable) | +| Associated flow | Your DNS resolvers → OPCP VIP — UDP/53 and TCP/53 | + +OPCP exposes its interfaces through FQDNs under a domain that you delegate to it. You must provide: + +- the **domain name** allocated to this OPCP platform (for example: `opcp01.example.com`). + +On the DNS infrastructure side, you must create a **forwarder** from your internal resolvers to the OPCP VIP, so that any request for `*.opcp01.example.com` is resolved by OPCP. + +### 9. DNS resolvers — External resolution + +| Field | Value | +|---|---| +| Mandatory | Optional | +| Modifiable after installation | Yes | +| Associated flow | OPCP administration network → your DNS resolvers — UDP/53 | + +If OPCP needs to resolve **external** domain names (for example the FQDN of your S3 endpoint or your LDAP directory), provide the address of one or more DNS resolvers. + +Example: + +- `172.30.1.100` +- `172.30.1.101` + +This prerequisite is only needed if you enable integrations relying on external FQDNs (S3 backup, long-term metrics, LDAP federation, and so on). For a strictly air-gapped platform configured by IP, it can be omitted. + +### 10. Syslog — Log centralisation + +| Field | Value | +|---|---| +| Mandatory | Optional but **recommended** | +| Modifiable after installation | Yes | +| Associated flow | OPCP administration network → your syslog servers — UDP/514 or TCP/514 | + +OPCP can forward its logs to a centralised syslog infrastructure for long-term retention and analysis. Provide: + +- the **IP address** or FQDN of the syslog server (for example: `172.30.1.250`), +- the **listening port**, +- the **protocol**: TCP or UDP. + +:::info +Without an external syslog, OPCP keeps the logs **locally** with a default retention of **7 days** and a maximum volume of **50 GB**. Beyond that, the oldest logs are deleted. For any compliance requirement imposing longer retention, configure an external syslog. +::: + +### 11. Backup — S3 endpoint + +| Field | Value | +|---|---| +| Mandatory | Optional but **recommended** | +| Modifiable after installation | Yes | +| Associated flow | OPCP administration network → your S3 endpoint — TCP/443 | + +OPCP can back up the infrastructure state (configurations, control plane state, metadata) to an S3-compatible endpoint that you provide. You must transmit: + +- the **S3 endpoint** (for example: `s3.example.com:443`), +- the **Access Key**, +- the **Secret Key**, +- the **bucket name** dedicated to backups (for example: `opcp01-backup-dc1`), +- the **S3 region name** (for example: `paris`). + +The access keys must be transmitted through a secure channel agreed with your OVHcloud point of contact. + +:::warning +Without an external backup, you have no recovery mechanism in the event of a major incident on the platform. This option is strongly recommended for any production environment. +::: + +### 12. Long-term metrics storage — S3 endpoint + +| Field | Value | +|---|---| +| Mandatory | Optional but **recommended** | +| Modifiable after installation | Yes | +| Associated flow | OPCP administration network → your S3 endpoint — TCP/443 | + +OPCP continuously collects metrics on the platform. To retain them beyond the local retention window, you can offload them to an S3 bucket. The elements to provide are the same as for the backup, but the bucket must be **separate**: + +- **S3 endpoint**, +- **Access Key**, +- **Secret Key**, +- **bucket name** dedicated to metrics (for example: `opcp01-metrics-dc1`), +- **region name**. + +You can reuse the same endpoint and the same S3 credentials as for the backup, provided you use a different bucket. + +### 13. LDAP — Identity federation + +| Field | Value | +|---|---| +| Mandatory | Optional | +| Modifiable after installation | Yes | +| Associated flow | OPCP administration network → your directory — TCP/636 (LDAPS) | + +OPCP integrates Keycloak as an identity provider. If you wish to federate access with your corporate directory (Active Directory or another LDAP server), provide: + +- the **IP addresses** or FQDNs of your LDAP servers (for example: `ldap.example.com`, `10.3.0.5`, `10.3.0.6`), +- the **listening port** (typically `636` for LDAPS). + +Without federation, users are managed directly in the Keycloak embedded in OPCP. + +### 14. SSH public key + +| Field | Value | +|---|---| +| Mandatory | Optional but **recommended** | +| Modifiable after installation | Yes | +| Associated flow | None (local OPCP configuration) | + +To access the OPCP controllers after the initial bootstrap (in particular to use `opcp-cli` and `opcp-diag`), provide one or more **SSH public keys** of the customer-side administrators. + +In **Fully managed by OVHcloud** mode, this key gives the customer access to the administration tools in addition to the access of the OVHcloud teams. + +:::info +If no key is provided, a new SSH key pair will be generated during deployment. To keep control of your access from delivery onwards, it is preferable to provide the public key yourself. +::: + +## Summary + +| Prerequisite | Status | Modifiable after installation | +|---|---|---| +| OVHcloud interconnection (IPsec) | Mandatory in managed mode | Yes | +| Administration network | Mandatory | **No** | +| OPCP environment variables | Mandatory | **No** | +| Controller names and addresses | Mandatory | **No** | +| Certificates | Mandatory | Yes | +| NTP | Mandatory | Yes | +| DNS (domain delegation) | Mandatory | **No** | +| DNS resolvers | Optional | Yes | +| Syslog | Optional but recommended | Yes | +| S3 backup | Optional but recommended | Yes | +| Long-term metrics S3 storage | Optional but recommended | Yes | +| LDAP | Optional | Yes | +| SSH public key | Optional but recommended | Yes | + +Pay particular attention to the prerequisites **not modifiable after installation**: they will shape your platform for the long term. + +## Go further + +- [OPCP - Network integration and platform connectivity](/guides/hosted-private-cloud/opcp/opcp-network-architecture) +- [Getting started with your OPCP](/guides/hosted-private-cloud/opcp/getting-started) + +For training or technical assistance implementing our solutions, contact your sales representative or visit our [Professional Services](/links/professional-services) page to request a quote and have your project analyzed by our experts. + +Join our [community of users](/links/community). + +1: S3 is a trademark of Amazon Technologies, Inc. OVHcloud's service is not sponsored by, endorsed by, or otherwise affiliated with Amazon Technologies, Inc. diff --git a/docs/es/guides/hosted-private-cloud/opcp/opcp-network-architecture.mdx b/docs/es/guides/hosted-private-cloud/opcp/opcp-network-architecture.mdx new file mode 120000 index 000000000..6e2260731 --- /dev/null +++ b/docs/es/guides/hosted-private-cloud/opcp/opcp-network-architecture.mdx @@ -0,0 +1 @@ +../../../../en/guides/hosted-private-cloud/opcp/opcp-network-architecture.mdx \ No newline at end of file diff --git a/docs/es/guides/hosted-private-cloud/opcp/opcp-prerequisites.mdx b/docs/es/guides/hosted-private-cloud/opcp/opcp-prerequisites.mdx new file mode 120000 index 000000000..e0d607566 --- /dev/null +++ b/docs/es/guides/hosted-private-cloud/opcp/opcp-prerequisites.mdx @@ -0,0 +1 @@ +../../../../en/guides/hosted-private-cloud/opcp/opcp-prerequisites.mdx \ No newline at end of file diff --git a/docs/fr/guides/hosted-private-cloud/opcp/opcp-network-architecture.mdx b/docs/fr/guides/hosted-private-cloud/opcp/opcp-network-architecture.mdx new file mode 100644 index 000000000..82bc4281f --- /dev/null +++ b/docs/fr/guides/hosted-private-cloud/opcp/opcp-network-architecture.mdx @@ -0,0 +1,242 @@ +--- +title: OPCP - Intégration réseau et connexion à la plateforme +description: "Découvrez comment OPCP s'intègre à votre réseau : réseau de données, réseau d'administration (OOB) et flux à autoriser selon votre mode de gestion" +lastUpdated: 2026-06-03 +--- + +## Objectif + +**On-Prem Cloud Platform (OPCP)** est une solution de cloud privé déployée sur vos propres infrastructures, livrée sous forme d'une pile intégrée (serveurs, commutateurs, automatisation, plan de contrôle). Avant et pendant le déploiement, votre équipe doit comprendre comment OPCP s'interconnecte avec votre réseau d'entreprise : par où il communique, quels flux il émet, quels services il consomme chez vous, et – si vous avez souscrit le mode Fully managed by OVHcloud – comment OVHcloud accède à la plateforme pour l'opérer à distance. + +**Ce guide a pour objectif de vous présenter l'architecture réseau d'OPCP**, en distinguant : + +- le **réseau d'administration (Out-of-Band, OOB)** utilisé pour piloter la plateforme, +- le **réseau de données (*data plane*)** utilisé par les charges de travail hébergées sur les serveurs OPCP. + +Il s'adresse aussi bien aux **architectes** préparant un déploiement qu'aux **administrateurs** prenant en main une plateforme déjà livrée. + +## Prérequis + +- Une vision générale de votre architecture réseau d'entreprise (VLAN, plan d'adressage, équipements de bordure, firewalls). +- Connaître le **modèle de souscription OPCP** retenu (Self-managed ou Fully managed by OVHcloud). +- Avoir parcouru la liste des [prérequis techniques OPCP](/guides/hosted-private-cloud/opcp/opcp-prerequisites) à fournir avant le déploiement. + +## En pratique + +### 1. Les niveaux de gestion d'OPCP + +OPCP est proposé selon deux niveaux de délégation. Le niveau choisi détermine **qui opère** le plan de contrôle (*control plane*) de la plateforme et donc **quels flux d'interconnexion** doivent être ouverts vers OVHcloud. + +| Mode | Qui opère le **Core** (*control plane*) ? | Qui opère les **services applicatifs** ? | Interconnexion vers OVHcloud requise ? | +|------|---|---|---| +| **Self-managed** | Le client | Le client | Non | +| **Fully managed by OVHcloud** | OVHcloud | OVHcloud | **Oui** (IPsec) | + +Quel que soit le mode, **la gestion de ce que vous déployez au-dessus des services fournis par OPCP reste de votre responsabilité** : machines virtuelles, conteneurs, instances bare-metal, applications, données métier, sauvegardes applicatives, etc. OPCP fournit la plateforme ; vous restez maître de l'usage que vous en faites. + +Quel que soit le mode, l'architecture matérielle et la séparation logique entre les réseaux sont **identiques**. Les différences entre Self-managed et Fully managed by OVHcloud portent sur deux points : + +1. **Le niveau d'accès aux interfaces d'administration.** En mode Self-managed, vos équipes disposent du contrôle complet des interfaces de gestion d'OPCP : API OpenStack, SSH aux contrôleurs, et deux outils en ligne de commande embarqués sur la plateforme : + - **`opcp-cli`**, qui permet de **configurer OPCP** (déclaration des ressources de la plateforme, gestion des composants, opérations d'exploitation), + - **`opcp-diag`**, qui produit un **état de santé de la plateforme** et **extrait les logs** nécessaires à un diagnostic à distance lorsqu'un incident survient. + + En mode Fully managed by OVHcloud, ces interfaces sont opérées par les équipes OVHcloud ; vos équipes conservent un accès en consultation et en exploitation applicative, mais l'administration plateforme est déléguée. +2. **Le besoin d'un lien IPsec entre votre réseau d'administration et OVHcloud.** Indispensable en mode Fully managed by OVHcloud pour que les équipes OVHcloud puissent opérer la plateforme à distance, ce lien n'existe pas en mode Self-managed. + +### 2. Les deux plans réseau d'OPCP + +OPCP repose sur une séparation stricte entre deux réseaux ayant des rôles, des équipements et des usages très différents. **Cette séparation est structurante** : elle conditionne la sécurité, la résilience et la qualité de service de la plateforme. + +#### Le réseau de données (*data plane*) + +Le réseau de données est le réseau **emprunté par les charges de travail** hébergées sur les serveurs OPCP (machines virtuelles, conteneurs, instances bare-metal exposées via OpenStack). C'est par lui que transitent : + +- le trafic applicatif entrant et sortant des instances, +- les communications entre instances au sein de l'OPCP, +- les flux entre OPCP et le reste de votre système d'information côté production (bases de données, services internes, utilisateurs finaux, etc.). + +Côté matériel, le réseau de données s'appuie sur : + +- les **interfaces data** des serveurs, +- les **commutateurs Top-of-Rack (ToR)** redondés, +- pour les déploiements multi-baies, deux familles supplémentaires de commutateurs : + - les commutateurs **edge**, qui assurent la **jonction entre le réseau interne d'OPCP et votre réseau amont** : ce sont eux qui portent la configuration des uplinks vers votre *Customer Upstream Data Network*, + - les commutateurs **spine**, qui permettent de **croître au-delà de 3 baies** en mutualisant l'interconnexion entre les ToR de plusieurs baies, +- des **liens uplink fibre** vers votre réseau amont (*Customer Upstream Data Network*) en **40 GbE ou 100 GbE**, selon les optiques validées par OVHcloud pour votre déploiement. + +Le réseau de données est **piloté de bout en bout par OPCP** via OpenStack Neutron : la création d'un réseau, d'un sous-réseau ou d'une règle de sécurité depuis Horizon ou l'API se propage automatiquement aux commutateurs sous-jacents. + +#### Le réseau d'administration (Out-of-Band, OOB) + +Le réseau OOB est le réseau **par lequel OPCP s'administre lui-même** et par lequel vous (et, en mode Fully managed by OVHcloud, les équipes OVHcloud) accédez aux interfaces de gestion. Il est **physiquement et logiquement séparé** du réseau de données. Il porte : + +- l'accès aux **API OpenStack**, à l'interface **Horizon** et aux outils de gestion d'OPCP (HTTPS), +- l'accès SSH aux **OPCP Core Controllers** (commandes `opcp-cli`, `opcp-diag`), +- les **échanges inter-contrôleurs** qui assurent la **résilience du plan de contrôle** en modes MINIPOD et FABRIC (synchronisation d'état, élection de quorum, bascule de la VIP entre les trois OPCP Core Controllers), +- la collecte de logs et de métriques émise depuis OPCP vers vos services internes, +- les flux sortants d'OPCP vers vos services d'infrastructure (NTP, DNS, S31 de sauvegarde, LDAP, syslog). + +Côté matériel, le réseau OOB s'appuie sur : + +- les **OPCP Core Controllers**, équipés d'un uplink OOB qui négocie en **10 GbE** en lien avec les capacités de votre infrastructure amont, et d'un port 1 GbE BMC, +- des **liens uplink** vers votre réseau OOB amont (*Customer Upstream OOB Network*). + +:::warning +En modes MINIPOD et FABRIC, les trois OPCP Core Controllers sont accessibles via une adresse IP virtuelle commune dont le bon fonctionnement nécessite une communication au sein d'un réseau L2 non taggé commun entre les trois OPCP Core Controllers. La disponibilité du plan de contrôle dépend donc directement de la disponibilité de cette connexion réseau : une panne prolongée du réseau OOB client peut perturber l'accès à l'administration de la plateforme. Le mode **NANOPOD** n'est pas concerné, puisqu'il ne dispose que d'un seul contrôleur. +Les données échangées entre les OPCP Core Controllers le sont au travers du réseau d'OPCP. Seul l'accès des administrateurs au plan de contrôle peut être affecté par des incidents sur le réseau OOB. +::: + +:::warning +Aucune communication directe n'est possible entre le réseau de données et le réseau OOB depuis l'intérieur d'OPCP. Toute communication transverse passe obligatoirement par votre réseau amont, ce qui vous laisse la maîtrise des règles de sécurité entre les deux périmètres. +::: + +### 3. Topologies de déploiement + +OPCP est livré selon trois modes de déploiement, dimensionnés en fonction du contexte d'usage. Ces modes diffèrent principalement par le nombre de baies supportées et la résilience du plan de contrôle (*control plane*). La présence ou non de commutateurs **spine** et **edge** entre les baies et votre réseau amont en est une conséquence directe. + +| Mode | Cas d'usage | Résilience du plan de contrôle | Nombre de baies | Spine / Edge | +|---|---|---|---|---| +| **NANOPOD** | Démonstration, sites distants, infrastructures non résilientes (bureaux, edge) | Non résilient (1 contrôleur) | 1 | Non | +| **MINIPOD** | Infrastructure résiliente compacte | Résilient (3 contrôleurs) | 2 à 3 | Edges uniquement | +| **FABRIC** | Déploiement datacenter avec infrastructure partagée | Résilient (3 contrôleurs) | 3 à 10 (et au-delà avec *megaspine*) | Spine + Edges | + +Du point de vue de l'intégration réseau, le point clé à retenir est : + +- en **NANOPOD**, le **réseau de données est configuré directement sur les commutateurs Top-of-Rack (ToR)** : ce sont eux qui remontent vers votre *Customer Upstream Data Network* ; +- en **MINIPOD** et **FABRIC**, le **réseau de données est configuré sur les commutateurs edge**, qui s'intercalent entre les ToR et votre réseau amont. La configuration des ToR reste interne à OPCP. + +Le nombre d'**OPCP Core Controllers** suit le mode de déploiement : **1 contrôleur en NANOPOD**, **3 contrôleurs en MINIPOD et FABRIC**. + +#### Configuration à 1 contrôleur (NANOPOD) + +Topologie OPCP NANOPOD - 1 contrôleur + +Les éléments clés sont : + +- **Customer Servers** : les serveurs hébergeant les charges de travail. Leurs interfaces data sont connectées aux deux ToR ; leur BMC est rattaché au switch de management. +- **ToR A / ToR B** (Arista DCS-7050CX3-32S) : deux commutateurs Top-of-Rack redondés. En mode NANOPOD, **ils portent directement le réseau de données et remontent vers votre *Customer Upstream Data Network*** via des liens fibre en **40 GbE ou 100 GbE**, selon les optiques validées par OVHcloud. +- **Switch de management (mgmt)** : commutateur de management dédié, qui agrège les BMC des serveurs et les ports de management des ToR. +- **OPCP Core Controller** unique, raccordé via un uplink OOB en **25 GbE ou 10 GbE** vers votre *Customer Upstream OOB Network*, plus un port 1 GbE BMC pour son propre lights-out. + +:::warning +Avec un seul contrôleur, **il n'y a pas de redondance du plan de contrôle** : une panne matérielle ou une opération de maintenance sur ce contrôleur interrompt l'administration de la plateforme (les charges de travail déjà déployées continuent à s'exécuter sur les serveurs). Pour tout environnement de production exigeant une haute disponibilité du plan de contrôle, retenez les modes MINIPOD ou FABRIC. +::: + +#### Configuration à 3 contrôleurs (MINIPOD et FABRIC) + +Topologie OPCP MINIPOD/FABRIC - 3 contrôleurs + +Par rapport au mode NANOPOD, les différences sont : + +- **3 OPCP Core Controllers** au lieu d'un seul, chacun raccordé au réseau OOB amont avec un uplink en **25 GbE ou 10 GbE** et un lien BMC 1 GbE. Une **adresse VIP** (*Virtual IP*) est partagée entre les trois contrôleurs : c'est cette adresse qui est utilisée pour atteindre les API OpenStack et l'interface Horizon, indépendamment du contrôleur actif. +- Les BMC des trois contrôleurs, comme ceux des serveurs, sont exposés sur votre réseau OOB amont. Cela garantit un accès lights-out à l'ensemble des équipements en cas de défaillance d'un composant interne à OPCP. +- Des **commutateurs edge** s'intercalent entre les ToR et votre réseau amont. **Le réseau de données est configuré sur ces edges**, et non plus sur les ToR. En mode **FABRIC**, des équipements **spine** sont également présents pour mutualiser plusieurs baies ; au-delà de dix baies, une couche **megaspine** peut être ajoutée. + +### 4. Comment OPCP s'intègre à votre environnement + +L'intégration d'OPCP repose sur **deux périmètres réseau** que vous fournissez et que vous gardez sous votre contrôle. + +#### Côté réseau de données (*Customer Upstream Data Network*) + +C'est votre réseau de production. OPCP s'y raccorde via les liens fibre des ToR (en mode NANOPOD) ou des edges (en mode MINIPOD et FABRIC), à des débits de **40 GbE ou 100 GbE** selon les optiques validées par OVHcloud. + +**La configuration du raccordement réseau (uplinks vers votre amont) est pilotée par OPCP**, à travers une API exposée par la plateforme. Selon le mode de déploiement : + +- en **NANOPOD**, la configuration est appliquée directement sur les **ToR** ; +- en **MINIPOD** et **FABRIC**, elle est appliquée sur les **edges**. + +Au-delà de ce raccordement, le contenu et la segmentation du réseau de données restent **entièrement pilotés par OPCP** via OpenStack Neutron : chaque réseau Neutron est représenté sur les uplinks selon l'un des trois modes ci-dessous. + +##### Mode access +Le port uplink est rattaché à **un unique réseau Neutron** et présente le trafic en **802.1Q** classique à votre équipement amont. C'est le mode le plus simple, adapté lorsqu'un port amont est dédié à un seul réseau OPCP. + +Si vos instances poussent leurs propres tags VLAN à l'intérieur du réseau Neutron (taggage au niveau de l'hyperviseur, besoins spécifiques des invités, etc.), ces tags internes sont gérés de manière transparente par OPCP et votre équipement amont ne voit toujours que des trames 802.1Q standard — il n'y a rien de plus à configurer de votre côté. + +##### Mode trunk +Le port uplink transporte **plusieurs réseaux Neutron** sur une seule interface physique, chacun étant distingué par son propre identifiant VLAN. Comme le tag VLAN défini par OPCP est préservé de bout en bout et jamais décapsulé, l'encapsulation que voit votre équipement amont dépend de ce qui se passe **à l'intérieur** de chaque réseau Neutron : + +- **802.1Q** — si vos instances n'utilisent pas de VLAN à l'intérieur du réseau Neutron. Votre équipement amont doit être configuré pour reconnaître les identifiants VLAN attribués par OPCP. +- **802.1ad (QinQ)** — si vos instances poussent leurs propres tags VLAN à l'intérieur du réseau Neutron. Le VLAN attribué par OPCP devient le tag externe et les VLAN des instances deviennent les tags internes. **Votre équipement amont doit être capable de gérer la double encapsulation.** + +Les deux peuvent coexister sur un même trunk : chaque réseau Neutron est indépendant, donc certains peuvent être en 802.1Q simple et d'autres en 802.1ad, selon l'usage qui est fait de chacun. + +#### Côté réseau d'administration (*Customer Upstream OOB Network*) + +C'est le périmètre depuis lequel OPCP est administré. Vous devez y prévoir : + +- un **sous-réseau dédié** à OPCP, avec une passerelle par défaut. C'est sur ce sous-réseau que sont positionnés les contrôleurs (et leur VIP en configuration HA), +- une **résolution DNS** : un nom de domaine que vous déléguez à OPCP (par exemple `*.opcp01.exemple.com`), accompagné d'un *forwarder* depuis vos résolveurs DNS internes vers la VIP OPCP, +- des **règles de filtrage** autorisant les flux décrits dans la matrice ci-dessous, +- un **accès à au moins une source de temps NTP** depuis le réseau d'administration d'OPCP (obligatoire) et, selon les options retenues, à vos autres services internes (syslog, S3, LDAP). + +### 5. Matrice des flux à autoriser + +Tous les flux suivants partent ou arrivent sur le **réseau d'administration (OOB)** d'OPCP. Aucun n'utilise le réseau de données. + +#### Flux entrants (vous → OPCP) + +| Source | Destination | Service | Protocole / Port | +|--------|-------------|---------|------------------| +| Postes d'administration / utilisateurs OPCP | VIP des contrôleurs OPCP | API OpenStack, Horizon, interfaces de gestion | TCP/443 | +| Administrateurs (mode Self-managed) | Contrôleurs OPCP | SSH (`opcp-cli`, `opcp-diag`) | TCP/22 | + +#### Flux sortants (OPCP → vous) + +| Source | Destination | Service | Protocole / Port | Obligatoire | +|---|---|---|---|---| +| Réseau d'administration OPCP | Vos serveurs NTP | Synchronisation horaire | UDP/123 | **Obligatoire** | +| Réseau d'administration OPCP | Vos résolveurs DNS | Résolution de noms externes | UDP/53 | Optionnel | +| Réseau d'administration OPCP | Vos serveurs Syslog | Centralisation des logs | UDP/514 ou TCP/514 | Recommandé | +| Réseau d'administration OPCP | Votre endpoint S3 | Backup de l'infrastructure | TCP/443 | Recommandé | +| Réseau d'administration OPCP | Votre endpoint S3 | Stockage long terme des métriques | TCP/443 | Recommandé | +| Réseau d'administration OPCP | Votre Active Directory / IdP | Fédération d'identité LDAP | TCP/636 (LDAPS) | Optionnel | + +:::info +OPCP est conçu pour fonctionner en mode **air-gap** : aucun de ces flux n'a besoin d'Internet. Les seules destinations attendues sont les services de votre propre système d'information. +::: + +### 6. L'interconnexion OVHcloud (mode Fully managed by OVHcloud) + +Si vous avez souscrit l'offre **Fully managed by OVHcloud**, OVHcloud doit pouvoir atteindre votre réseau d'administration OPCP pour assurer l'exploitation et le support à distance. Cette interconnexion repose sur un **tunnel IPsec site-à-site** entre un équipement de bordure côté OVHcloud et un équipement de bordure côté client. + +Les paramètres par défaut proposés par OVHcloud sont : + +- **IKEv2 uniquement** (IKEv1 n'est pas supporté), +- authentification par **PSK** (Pre-Shared Key), +- chiffrement **AES-256**, +- hash **SHA-256**, +- groupe Diffie-Hellman **14**, +- **PFS** (Perfect Forward Secrecy) activé. + +:::warning +OVHcloud déconseille fortement d'abaisser le niveau de chiffrement en deçà d'AES-256. Si une contrainte de votre côté empêche d'utiliser ces paramètres, contactez votre point de contact OVHcloud pour étudier les alternatives. +::: + +Pour préparer cette interconnexion, vous devez fournir à OVHcloud : + +- l'**IP publique** de votre endpoint IPsec, +- le **sous-réseau** côté client à exposer dans le tunnel (typiquement le sous-réseau d'administration d'OPCP), +- la **PSK** convenue (transmise via un canal sécurisé : voir avec votre point de contact OVHcloud). + +Une fois le tunnel établi, les équipes OVHcloud accèdent à votre OPCP **uniquement** via cette interconnexion, sur les mêmes flux que ceux décrits dans la matrice ci-dessus. Aucun accès direct depuis Internet n'est ouvert sur votre plateforme. + +### 7. Plan d'adressage et nommage + +Lors de la préparation du déploiement, vous fournirez à OVHcloud : + +- le **sous-réseau** alloué au réseau d'administration d'OPCP et sa **passerelle par défaut** (exemple : subnet `172.30.1.0/24`, gateway `172.30.1.254`), +- les **noms et adresses IP** des contrôleurs OPCP, ainsi que la **VIP** partagée en configuration HA (exemples : `opcp-controller-0` / `172.30.1.10`, `opcp-controller-1` / `172.30.1.11`, `opcp-controller-2` / `172.30.1.12`, VIP `172.30.1.5`), +- le **nom de domaine** que vous déléguez à OPCP (exemple : `opcp01.exemple.com`). + +Le plan d'adressage et la convention de nommage sont **entièrement à votre main** : OVHcloud n'impose pas de format. Reportez-vous au guide « [prérequis techniques OPCP](/guides/hosted-private-cloud/opcp/opcp-prerequisites) » pour la liste exhaustive des éléments à transmettre. + +## Aller plus loin + +- [OPCP - Prérequis techniques pour le déploiement](/guides/hosted-private-cloud/opcp/opcp-prerequisites) +- [Mise en route de votre OPCP](/guides/hosted-private-cloud/opcp/getting-started) + +Pour une formation ou une assistance technique sur la mise en œuvre de nos solutions, contactez votre commercial ou consultez la page [Professional Services](/links/professional-services) pour obtenir un devis et faire analyser votre projet par nos experts. + +Échangez avec notre [communauté d'utilisateurs](/links/community). + +1 : S3 est une marque déposée appartenant à Amazon Technologies, Inc. Les services de OVHcloud ne sont pas sponsorisés, approuvés, ou affiliés de quelque manière que ce soit. diff --git a/docs/fr/guides/hosted-private-cloud/opcp/opcp-prerequisites.mdx b/docs/fr/guides/hosted-private-cloud/opcp/opcp-prerequisites.mdx new file mode 100644 index 000000000..bb0893cdc --- /dev/null +++ b/docs/fr/guides/hosted-private-cloud/opcp/opcp-prerequisites.mdx @@ -0,0 +1,327 @@ +--- +title: OPCP - Prérequis techniques pour le déploiement +description: Découvrez la liste des éléments de configuration que vous devez fournir à OVHcloud pour préparer et déployer votre plateforme OPCP +lastUpdated: 2026-06-03 +--- + +## Objectif + +Le déploiement d'**On-Prem Cloud Platform (OPCP)** sur votre site nécessite la collecte préalable d'un ensemble d'informations de configuration. Certaines sont indispensables au bootstrap initial et ne pourront plus être modifiées après installation ; d'autres sont optionnelles ou ajustables ultérieurement. Préparer cette liste en amont est la **condition principale d'un déploiement rapide et sans aller-retour**. + +**Ce guide a pour objectif de vous présenter, pour chaque prérequis, à quoi il sert, comment le formuler et quel est son caractère obligatoire ou optionnel**. + +Il s'adresse aussi bien aux **architectes** préparant la livraison qu'aux **administrateurs** souhaitant comprendre ce qui a été paramétré sur leur plateforme. + +## Prérequis + +- Avoir parcouru le guide « [OPCP - Intégration réseau et connexion à la plateforme](/guides/hosted-private-cloud/opcp/opcp-network-architecture) », qui décrit l'architecture réseau dans laquelle s'inscrivent ces prérequis. +- Connaître le **modèle de souscription OPCP** retenu (Self-managed ou Fully managed by OVHcloud). +- Disposer d'un **point de contact OVHcloud** identifié pour la livraison, à qui transmettre les éléments collectés. + +## En pratique + +### 1. Comment lire ce guide + +Pour chaque prérequis, vous trouverez : + +- une **description** expliquant son rôle dans la plateforme, +- le **caractère obligatoire ou optionnel** de l'information, +- la **possibilité de modification après installation**, +- les **flux réseau associés** lorsque le prérequis implique une communication entre OPCP et un service de votre environnement, +- un **exemple générique** pour vous aider à formuler la valeur attendue. + +:::info +**Transmission des éléments sensibles.** Plusieurs prérequis impliquent des secrets : clé pré-partagée IPsec, clés d'accès S31, clés privées de certificats, etc. Ces éléments **ne doivent pas être transmis par un canal non sécurisé**. Convenez avec votre point de contact OVHcloud d'un canal de transmission approprié pour chaque secret. +::: + +### 2. Interconnexion OVHcloud (mode managé uniquement) + +| Champ | Valeur | +|---|---| +| Obligatoire | **Oui**, en mode Fully managed by OVHcloud | +| Modifiable après installation | Oui | +| Flux associé | Tunnel IPsec site-à-site entre votre endpoint et OVHcloud | + +Si vous avez souscrit l'offre **Fully managed by OVHcloud**, un tunnel IPsec doit être établi entre votre site et OVHcloud pour permettre l'exploitation et le support à distance. Vous devez fournir : + +- l'**adresse IP publique** de votre endpoint IPsec, +- le **sous-réseau** que vous exposez côté client (typiquement le subnet d'administration d'OPCP), +- la **clé pré-partagée (PSK)** convenue pour l'authentification, à transmettre via un canal sécurisé. + +Les paramètres cryptographiques par défaut sont **IKEv2 + PSK + AES-256 + SHA-256 + DH group 14 + PFS**. Si votre politique de sécurité exige des paramètres différents, abordez le sujet avec votre point de contact OVHcloud avant le déploiement. + +:::warning +IKEv1 n'est pas supporté. L'abaissement du niveau de chiffrement en dessous d'AES-256 est déconseillé : à n'envisager qu'en dernier recours. +::: + +En mode **Self-managed**, ce prérequis ne s'applique pas. + +### 3. Réseau d'administration + +| Champ | Valeur | +|---|---| +| Obligatoire | **Oui** | +| Modifiable après installation | **Non** | +| Flux associé | Aucun (configuration locale à OPCP) | + +Définition du réseau de management sur lequel OPCP sera positionné. Vous devez fournir : + +- le **sous-réseau** alloué à OPCP (exemple : `172.30.1.0/24`), +- l'**adresse de la passerelle par défaut** (exemple : `172.30.1.254`). + +Ce réseau accueillera les contrôleurs OPCP et leur VIP. Il sert également de point de départ aux flux sortants vers vos services internes (NTP, DNS, syslog, S3, LDAP). + +:::warning +Ces paramètres sont **figés au déploiement** : le sous-réseau et la passerelle ne peuvent pas être modifiés après l'installation sans réinstallation complète. Validez-les soigneusement en amont. +::: + +### 4. Variables d'environnement OPCP + +| Champ | Valeur | +|---|---| +| Obligatoire | **Oui** | +| Modifiable après installation | **Non** | +| Flux associé | Aucun | + +OPCP utilise plusieurs variables pour identifier le déploiement de manière unique. Elles sont reprises dans Netbox, dans les logs, dans le monitoring et dans plusieurs autres composants. Vous devez fournir une valeur pour chacune : + +| Variable | Rôle | Exemple | +|---|---|---| +| `env` | Identifiant logique de l'environnement OPCP | `opcp-prod-0` | +| `region` | Code de la région ou de la zone géographique | `par` | +| `stage` | Étape de cycle de vie | `prod`, `staging`, `dev` | +| `org` | Organisation propriétaire | `mycompany` | +| `site` | Identifiant du site physique | `dc1` | +| `location` | Localisation précise dans le site | `R11-1` | + +:::info +**Aucune convention de nommage n'est imposée par OVHcloud.** Adoptez la nomenclature qui correspond à votre référentiel interne. Choisissez-la avec soin : ces valeurs seront figées et utilisées dans de nombreux composants. +::: + +### 5. Noms et adresses des contrôleurs OPCP + +| Champ | Valeur | +|---|---| +| Obligatoire | **Oui** | +| Modifiable après installation | **Non** | +| Flux associé | Aucun (configuration locale à OPCP) | + +Pour chaque **OPCP Core Controller** de votre déploiement, fournissez : + +- le **nom d'hôte** (FQDN ou nom court selon votre convention), +- l'**adresse IP** sur le réseau d'administration. + +En configuration à 3 contrôleurs, fournissez également la **VIP (Virtual IP)** partagée entre les trois nœuds, qui constituera le point d'entrée unique vers les API OpenStack et l'interface Horizon. + +Exemple en configuration 3 contrôleurs : + +| Élément | Nom | IP | +|---|---|---| +| Contrôleur 0 | `opcp-controller-0` | `172.30.1.10` | +| Contrôleur 1 | `opcp-controller-1` | `172.30.1.11` | +| Contrôleur 2 | `opcp-controller-2` | `172.30.1.12` | +| VIP | `opcp.exemple.com` | `172.30.1.5` | + +### 6. Certificats + +| Champ | Valeur | +|---|---| +| Obligatoire | **Oui** | +| Modifiable après installation | Oui | +| Flux associé | Aucun (configuration locale à OPCP) | + +OPCP doit présenter des certificats TLS valides pour ses interfaces (API OpenStack, Horizon, services internes). Trois options sont supportées ; vous devez choisir l'une d'entre elles avant le déploiement. + +#### Option A — Recommandée - Autorité de certification intermédiaire fournie par le client + +Vous fournissez une CA intermédiaire dérivée de votre PKI interne. OPCP l'utilise pour signer les certificats des services. Vous devez transmettre : + +- le **certificat de la CA intermédiaire**, +- la **clé privée** associée (à transmettre via un canal sécurisé convenu avec votre point de contact OVHcloud). + +La rotation des certificats émis sous cette intermédiaire reste gérée par CertManager côté OPCP. + +#### Option B — Autorité de certification auto-signée générée par OPCP + +OPCP génère sa propre autorité de certification interne et signe les certificats nécessaires. **Vous n'avez rien à fournir.** La rotation est gérée automatiquement par CertManager. + +C'est l'option la plus simple, adaptée si votre politique de sécurité tolère une CA interne au périmètre OPCP. Vous devrez en revanche distribuer le certificat racine d'OPCP à vos clients pour éviter les alertes de sécurité. + +#### Option C — Let's Encrypt + +OPCP demande automatiquement les certificats auprès de Let's Encrypt. Cette option nécessite : + +- une **méthode de validation** compatible (HTTP-01 ou DNS-01) accessible depuis OPCP, +- les **prérequis associés** à cette méthode (résolution publique du domaine, accès sortant aux serveurs ACME, etc.). + +Précisez avec votre point de contact OVHcloud la méthode retenue et les configurations à mettre en place de votre côté. + +### 7. NTP — Synchronisation horaire + +| Champ | Valeur | +|---|---| +| Obligatoire | **Oui** | +| Modifiable après installation | Oui | +| Flux associé | Réseau d'administration OPCP → vos serveurs NTP — UDP/123 | + +OPCP a besoin d'une source de temps fiable pour le bon fonctionnement de l'ensemble de ses composants (cohérence des logs, validité des certificats, élection de quorum, etc.). Fournissez : + +- une ou plusieurs **adresses IP** de serveurs NTP, **ou** des **noms DNS** si la résolution DNS est configurée. + +Exemple : + +- `172.30.1.200` / `ntp1.exemple.com` +- `172.30.1.201` / `ntp2.exemple.com` + +Prévoyez l'ouverture du flux **UDP/123** depuis le réseau d'administration d'OPCP vers vos serveurs NTP. + +### 8. DNS — Délégation de domaine vers OPCP + +| Champ | Valeur | +|---|---| +| Obligatoire | **Oui** | +| Modifiable après installation | **Non** (le forwarder DNS pouvant être adapté si les FQDN restent stables) | +| Flux associé | Vos résolveurs DNS → VIP OPCP — UDP/53 et TCP/53 | + +OPCP expose ses interfaces via des FQDN sous un domaine que vous lui déléguez. Vous devez fournir : + +- le **nom de domaine** alloué à cette plateforme OPCP (exemple : `opcp01.exemple.com`). + +Côté infrastructure DNS, vous devez créer un **forwarder** depuis vos résolveurs internes vers la VIP OPCP, afin que toute requête pour `*.opcp01.exemple.com` soit résolue par OPCP. + +### 9. Résolveurs DNS — Résolution externe + +| Champ | Valeur | +|---|---| +| Obligatoire | Optionnel | +| Modifiable après installation | Oui | +| Flux associé | Réseau d'administration OPCP → vos résolveurs DNS — UDP/53 | + +Si OPCP doit résoudre des noms de domaine **externes** (par exemple le FQDN de votre endpoint S3 ou de votre annuaire LDAP), fournissez l'adresse d'un ou plusieurs résolveurs DNS. + +Exemple : + +- `172.30.1.100` +- `172.30.1.101` + +Ce prérequis n'est nécessaire que si vous activez des intégrations s'appuyant sur des FQDN externes (sauvegarde S3, métriques long terme, fédération LDAP, etc.). Pour une plateforme strictement air-gappée et configurée par IP, il peut être omis. + +### 10. Syslog — Centralisation des logs + +| Champ | Valeur | +|---|---| +| Obligatoire | Optionnel mais **recommandé** | +| Modifiable après installation | Oui | +| Flux associé | Réseau d'administration OPCP → vos serveurs syslog — UDP/514 ou TCP/514 | + +OPCP peut envoyer ses logs vers une infrastructure syslog centralisée pour rétention long terme et analyse. Fournissez : + +- l'**adresse IP** ou le FQDN du serveur syslog (exemple : `172.30.1.250`), +- le **port** d'écoute, +- le **protocole** : TCP ou UDP. + +:::info +Sans syslog externe, OPCP conserve les logs **localement** avec une rétention par défaut de **7 jours** et une volumétrie maximale de **50 Go**. Au-delà, les logs les plus anciens sont supprimés. Pour toute exigence de conformité imposant une rétention plus longue, configurez un syslog externe. +::: + +### 11. Sauvegarde — Endpoint S3 + +| Champ | Valeur | +|---|---| +| Obligatoire | Optionnel mais **recommandé** | +| Modifiable après installation | Oui | +| Flux associé | Réseau d'administration OPCP → votre endpoint S3 — TCP/443 | + +OPCP peut sauvegarder l'état de l'infrastructure (configurations, état du plan de contrôle, métadonnées) vers un endpoint compatible S3 que vous fournissez. Vous devez transmettre : + +- l'**endpoint S3** (exemple : `s3.exemple.com:443`), +- la **clé d'accès** (Access Key), +- la **clé secrète** (Secret Key), +- le **nom du bucket** dédié aux sauvegardes (exemple : `opcp01-backup-dc1`), +- le **nom de la région** S3 (exemple : `paris`). + +Les clés d'accès doivent être transmises via un canal sécurisé convenu avec votre point de contact OVHcloud. + +:::warning +Sans sauvegarde externe, vous ne disposez d'aucun mécanisme de restauration en cas d'incident majeur sur la plateforme. Cette option est très fortement recommandée pour tout environnement de production. +::: + +### 12. Stockage long terme des métriques — Endpoint S3 + +| Champ | Valeur | +|---|---| +| Obligatoire | Optionnel mais **recommandé** | +| Modifiable après installation | Oui | +| Flux associé | Réseau d'administration OPCP → votre endpoint S3 — TCP/443 | + +OPCP collecte en permanence des métriques sur la plateforme. Pour les conserver au-delà de la fenêtre de rétention locale, vous pouvez les externaliser vers un bucket S3. Les éléments à fournir sont les mêmes que pour la sauvegarde, mais le bucket doit être **distinct** : + +- **endpoint S3**, +- **clé d'accès**, +- **clé secrète**, +- **nom du bucket** dédié aux métriques (exemple : `opcp01-metrics-dc1`), +- **nom de la région**. + +Vous pouvez réutiliser le même endpoint et les mêmes identifiants S3 que pour la sauvegarde, à condition d'utiliser un bucket différent. + +### 13. LDAP — Fédération d'identité + +| Champ | Valeur | +|---|---| +| Obligatoire | Optionnel | +| Modifiable après installation | Oui | +| Flux associé | Réseau d'administration OPCP → votre annuaire — TCP/636 (LDAPS) | + +OPCP intègre Keycloak comme fournisseur d'identité. Si vous souhaitez fédérer les accès avec votre annuaire d'entreprise (Active Directory ou autre serveur LDAP), fournissez : + +- les **adresses IP** ou FQDN de vos serveurs LDAP (exemple : `ldap.exemple.com`, `10.3.0.5`, `10.3.0.6`), +- le **port** d'écoute (typiquement `636` pour LDAPS). + +Sans fédération, les utilisateurs sont gérés directement dans le Keycloak embarqué d'OPCP. + +### 14. Clé SSH publique + +| Champ | Valeur | +|---|---| +| Obligatoire | Optionnel mais **recommandé** | +| Modifiable après installation | Oui | +| Flux associé | Aucun (configuration locale à OPCP) | + +Pour accéder aux contrôleurs OPCP après le bootstrap initial (notamment pour utiliser `opcp-cli` et `opcp-diag`), fournissez une ou plusieurs **clés SSH publiques** des administrateurs côté client. + +En mode **Fully managed by OVHcloud**, cette clé donne au client un accès aux outils d'administration en complément de l'accès des équipes OVHcloud. + +:::info +Si aucune clé n'est fournie, une nouvelle paire de clés SSH sera générée lors du déploiement. Pour maîtriser vos accès dès la livraison, il est préférable de fournir vous-même la clé publique. +::: + +## Récapitulatif + +| Prérequis | Caractère | Modifiable après installation | +|---|---|---| +| Interconnexion OVHcloud (IPsec) | Obligatoire en mode managé | Oui | +| Réseau d'administration | Obligatoire | **Non** | +| Variables d'environnement OPCP | Obligatoire | **Non** | +| Noms et adresses des contrôleurs | Obligatoire | **Non** | +| Certificats | Obligatoire | Oui | +| NTP | Obligatoire | Oui | +| DNS (délégation de domaine) | Obligatoire | **Non** | +| Résolveurs DNS | Optionnel | Oui | +| Syslog | Optionnel mais recommandé | Oui | +| Sauvegarde S3 | Optionnel mais recommandé | Oui | +| Stockage long terme des métriques S3 | Optionnel mais recommandé | Oui | +| LDAP | Optionnel | Oui | +| Clé SSH publique | Optionnel mais recommandé | Oui | + +Portez une attention particulière aux prérequis **non modifiables après installation** : ils conditionneront durablement votre plateforme. + +## Aller plus loin + +- [OPCP - Intégration réseau et connexion à la plateforme](/guides/hosted-private-cloud/opcp/opcp-network-architecture) +- [Mise en route de votre OPCP](/guides/hosted-private-cloud/opcp/getting-started) + +Pour une formation ou une assistance technique sur la mise en œuvre de nos solutions, contactez votre commercial ou consultez la page [Professional Services](/links/professional-services) pour obtenir un devis et faire analyser votre projet par nos experts. + +Échangez avec notre [communauté d'utilisateurs](/links/community). + +1 : S3 est une marque déposée appartenant à Amazon Technologies, Inc. Les services de OVHcloud ne sont pas sponsorisés, approuvés, ou affiliés de quelque manière que ce soit. diff --git a/docs/it/guides/hosted-private-cloud/opcp/opcp-network-architecture.mdx b/docs/it/guides/hosted-private-cloud/opcp/opcp-network-architecture.mdx new file mode 120000 index 000000000..6e2260731 --- /dev/null +++ b/docs/it/guides/hosted-private-cloud/opcp/opcp-network-architecture.mdx @@ -0,0 +1 @@ +../../../../en/guides/hosted-private-cloud/opcp/opcp-network-architecture.mdx \ No newline at end of file diff --git a/docs/it/guides/hosted-private-cloud/opcp/opcp-prerequisites.mdx b/docs/it/guides/hosted-private-cloud/opcp/opcp-prerequisites.mdx new file mode 120000 index 000000000..e0d607566 --- /dev/null +++ b/docs/it/guides/hosted-private-cloud/opcp/opcp-prerequisites.mdx @@ -0,0 +1 @@ +../../../../en/guides/hosted-private-cloud/opcp/opcp-prerequisites.mdx \ No newline at end of file diff --git a/docs/pl/guides/hosted-private-cloud/opcp/opcp-network-architecture.mdx b/docs/pl/guides/hosted-private-cloud/opcp/opcp-network-architecture.mdx new file mode 120000 index 000000000..6e2260731 --- /dev/null +++ b/docs/pl/guides/hosted-private-cloud/opcp/opcp-network-architecture.mdx @@ -0,0 +1 @@ +../../../../en/guides/hosted-private-cloud/opcp/opcp-network-architecture.mdx \ No newline at end of file diff --git a/docs/pl/guides/hosted-private-cloud/opcp/opcp-prerequisites.mdx b/docs/pl/guides/hosted-private-cloud/opcp/opcp-prerequisites.mdx new file mode 120000 index 000000000..e0d607566 --- /dev/null +++ b/docs/pl/guides/hosted-private-cloud/opcp/opcp-prerequisites.mdx @@ -0,0 +1 @@ +../../../../en/guides/hosted-private-cloud/opcp/opcp-prerequisites.mdx \ No newline at end of file diff --git a/docs/pt/guides/hosted-private-cloud/opcp/opcp-network-architecture.mdx b/docs/pt/guides/hosted-private-cloud/opcp/opcp-network-architecture.mdx new file mode 120000 index 000000000..6e2260731 --- /dev/null +++ b/docs/pt/guides/hosted-private-cloud/opcp/opcp-network-architecture.mdx @@ -0,0 +1 @@ +../../../../en/guides/hosted-private-cloud/opcp/opcp-network-architecture.mdx \ No newline at end of file diff --git a/docs/pt/guides/hosted-private-cloud/opcp/opcp-prerequisites.mdx b/docs/pt/guides/hosted-private-cloud/opcp/opcp-prerequisites.mdx new file mode 120000 index 000000000..e0d607566 --- /dev/null +++ b/docs/pt/guides/hosted-private-cloud/opcp/opcp-prerequisites.mdx @@ -0,0 +1 @@ +../../../../en/guides/hosted-private-cloud/opcp/opcp-prerequisites.mdx \ No newline at end of file diff --git a/docs/public/images/hosted-private-cloud/opcp/opcp-network-architecture/opcp-1controller-setup.png b/docs/public/images/hosted-private-cloud/opcp/opcp-network-architecture/opcp-1controller-setup.png new file mode 100644 index 000000000..1f9ec1c22 Binary files /dev/null and b/docs/public/images/hosted-private-cloud/opcp/opcp-network-architecture/opcp-1controller-setup.png differ diff --git a/docs/public/images/hosted-private-cloud/opcp/opcp-network-architecture/opcp-3controllers-setup.png b/docs/public/images/hosted-private-cloud/opcp/opcp-network-architecture/opcp-3controllers-setup.png new file mode 100644 index 000000000..3e2cd6673 Binary files /dev/null and b/docs/public/images/hosted-private-cloud/opcp/opcp-network-architecture/opcp-3controllers-setup.png differ