bc8e3704db
File location changes to support DS flattend Install TOC Add minitocs and remove duplicate include directive Convert images to figures and add captions Incorporate server prep. steps Add links to post-install steps. Inline overview and HW topics in procs. Patchset 1 review updates. Rework to reuse some StX install content in partner context and some partner install content in StX context. Conditionalize ipv6_note Share aio_duplex_extend Conditionalize Openstack prod name Add HW requirement includes for worker and storage nodes. Link worker and stor reqs to DX, StD and Dedicated install topics. Fix comment notation Correct for duplicate strings in output Updates and additions based on GW review Make ansible_install_time_only note available DS. Move link target from r6 > r7 Temporarily restore alarms to satisfy build Migrate DX flattening to new layout Additional HW requirements to DX, Std and Dedicated tables. Migrate Standard flattening to new layout Roll this-ver forward to r7 Migrate Dedicated Storage flattening to new layout Address review comments. Standardize HW requirement tables Support horizontally conditionalized inline content Address additional review comments Signed-off-by: Ron Stone <ronald.stone@windriver.com> Change-Id: I14c8a1e51f6b6ceff69be063a654b4aadb7d3b8c
2.3 KiB
Standard Configuration with Dedicated Storage
Deployment of with dedicated storage nodes provides the highest capacity (single region), performance, and scalability.
See Common Components <common-components> for a
description of common components of this deployment configuration.
The differentiating physical feature of this model is that the controller, storage, and worker functionalities are deployed on separate physical hosts allowing controller nodes, storage nodes, and worker nodes to scale independently from each other.
The controller nodes provide the control-plane function for the system. Two controller nodes are required to provide redundancy. The controller nodes' server and peripheral resources such as CPU cores/speed, memory, storage, and network interfaces can be scaled to meet requirements.
Storage nodes provide a large scale Ceph cluster for the storage backend for Kubernetes . They are deployed in replication groups of either two or three for redundancy. For a system configured to use two storage hosts per replication group, a maximum of eight storage hosts (four replication groups) are supported. For a system with three storage hosts per replication group, up to nine storage hosts (three replication groups) are supported. The system provides redundancy and scalability through the number of Ceph installed in a storage node group, with more providing more capacity and better storage performance. The scalability and performance of the storage function is affected by the size and speed, optional or Ceph journals, CPU cores and speeds, memory, disk controllers, and networking. can be grouped into storage tiers according to their performance characteristics.
Alternatively, instead of configuring Storage Nodes, you can configure an external Netapp Trident storage backend.
On worker nodes, the primary disk is used for system requirements and for container local ephemeral storage.