Merge "Introduction editorial updates"
This commit is contained in:
Zuul
Gerrit Code Review
commit
437179ebff
@ -2,14 +2,14 @@
|
||||
Consuming StarlingX
|
||||
===================
|
||||
|
||||
StarlingX is ready for you to use today. However limitations exist regarding
|
||||
what you can do with the open source software. Features of the software
|
||||
like secure boot and live software update are not fully enabled by the community.
|
||||
StarlingX is ready for you to use today, however, limitations exist regarding
|
||||
what you can do with the open source software. Software features like secure
|
||||
boot and live software update are not fully enabled by the community.
|
||||
|
||||
The community does not provide signed software images, which are needed to enable
|
||||
features that depend on signed images to implement security features. Providing
|
||||
signed images is typically the responsibility of commercial vendors or the users
|
||||
themselves. As such, the following are three ways in which you can consume StarlingX.
|
||||
themselves. Here are three ways in which you can consume StarlingX.
|
||||
|
||||
---------------------------
|
||||
Deploy the open source code
|
||||
@ -22,17 +22,17 @@ and daily builds.
|
||||
As previously mentioned, these images are not signed and thus do not support
|
||||
secure boot or live software updates. You can also build your own images.
|
||||
|
||||
The StarlingX community recommends that anyone looking to deploy the open source
|
||||
The StarlingX community recommends that users planning to deploy the open source
|
||||
software use the release images, which have been tested and validated by the
|
||||
community. Developers looking to work against the tip of the source trees would
|
||||
typcally use the daily builds.
|
||||
community. Developers planning to work against the tip of the source trees
|
||||
typically use the daily builds.
|
||||
|
||||
---------------------------------------
|
||||
Deploy an internal version of StarlingX
|
||||
---------------------------------------
|
||||
|
||||
If you are part of a company, the company itself can create a team to create
|
||||
their own version of StarlingX for the company. Such a team could do acceptance
|
||||
their own version of StarlingX for internal use. Such a team can do acceptance
|
||||
testing of the open source software, customize it as needed, sign their own
|
||||
internal images, and use the features in StarlingX to enable secure boot and to
|
||||
develop and deliver live software updates (patches) to their internal users.
|
||||
@ -41,10 +41,10 @@ develop and deliver live software updates (patches) to their internal users.
|
||||
Deploy code from a vendor
|
||||
-------------------------
|
||||
|
||||
You can also consume a commercial vendor's StarlingX-based product or solution.
|
||||
Vendors can provide signed images and signed software updates. They can add
|
||||
features or content to the open source software. They may provide other services
|
||||
such as technical support.
|
||||
You can consume a commercial vendor's StarlingX-based product or solution.
|
||||
Vendors provide signed images and signed software updates. They may also add
|
||||
features or content to the open source software and they may provide other
|
||||
services such as technical support.
|
||||
|
||||
The StarlingX community expects several vendors to provide StarlingX-based products
|
||||
and solutions. We hope to see more as our community grows.
|
||||
|
||||
@ -5,26 +5,26 @@ Deployment Options
|
||||
StarlingX provides a pre-defined set of standard configurations. These
|
||||
configurations are:
|
||||
|
||||
All-in-one Simplex ("Simplex" or "AIO-SX")
|
||||
All-in-one Simplex (*Simplex* or *AIO-SX*)
|
||||
The Simplex configuration runs all edge cloud functions (control, storage, and
|
||||
application workloads) on one node. This configuration is intended for very
|
||||
small and physically isolated edge sites that do not require high availability.
|
||||
|
||||
All-in-one Duplex ("Duplex" or "AIO-DX")
|
||||
All-in-one Duplex (*Duplex* or *AIO-DX*)
|
||||
The Duplex configuration runs all edge cloud functions (control, storage, and
|
||||
application workloads) on one node, but there is a second node in the system
|
||||
application workloads) on one node. There is a second node in the system
|
||||
for Active / Standby based high availability for all platform and application
|
||||
services.
|
||||
|
||||
Standard with Controller Storage
|
||||
This configuration allows for 1 or 2 controller nodes that also provide
|
||||
storage for the edge cloud. The configuration also allows for between 1 and
|
||||
ninety-nine compute nodes to run application workloads. This configuration
|
||||
works best for edge clouds with smaller storage needs.
|
||||
99 compute nodes to run application workloads. This configuration works best
|
||||
for edge clouds with smaller storage needs.
|
||||
|
||||
Standard with Dedicated Storage
|
||||
This configuration has dedicated storage nodes in addition to the controller
|
||||
and compute nodes. You can use this configuration for edge clouds that require
|
||||
and compute nodes. This configuration is used for edge clouds that require
|
||||
larger amounts of storage.
|
||||
|
||||
Standard with Ironic
|
||||
|
||||
@ -10,15 +10,15 @@ Key features of StarlingX include:
|
||||
* Provided as a single, easy to install package that includes an operating system,
|
||||
storage and networking components, and all the cloud infrastructure needed to
|
||||
run edge workloads.
|
||||
* All of the software has been optimized to meet edge application requirements
|
||||
* Pre-defined configurations designed to meet a variety of edge cloud deployment
|
||||
needs
|
||||
* Optimized software that meets edge application requirements.
|
||||
* Designed with pre-defined configurations to meet a variety of edge cloud deployment
|
||||
needs.
|
||||
* Tested and released as a complete stack, ensuring compatibility among open
|
||||
source components
|
||||
* Provides fault management and service managmenent, to ensure high availability
|
||||
of user applications
|
||||
source components.
|
||||
* Included fault management and service management capabilities, which provide
|
||||
high availability for user applications.
|
||||
* Optimized by the community for security, ultra-low latency, extremely high
|
||||
service uptime, and streamlined operation
|
||||
service uptime, and streamlined operation.
|
||||
|
||||
Learn more about StarlingX:
|
||||
|
||||
|
||||
@ -10,12 +10,12 @@ All-in-one Controller Node
|
||||
and storage function.
|
||||
|
||||
Bare Metal
|
||||
A node running without hypervisors (e.g. application workloads run directly on
|
||||
the operating system which runs directly on the hardware).
|
||||
A node running without hypervisors (for example, application workloads run
|
||||
directly on the operating system which runs directly on the hardware).
|
||||
|
||||
Compute or Worker
|
||||
A node within a StarlingX edge cloud that is dedicated to running application
|
||||
workloads. There can be 0 to ninety-nine compute nodes in a StarlingX edge
|
||||
workloads. There can be 0 to 99 compute nodes in a StarlingX edge
|
||||
cloud.
|
||||
|
||||
- Runs virtual switch for realizing virtual networks.
|
||||
@ -23,12 +23,12 @@ Compute or Worker
|
||||
|
||||
Controller
|
||||
A node within a StarlingX edge cloud that runs the cloud management software
|
||||
("control plane"). There can be either one or two controller nodes in a
|
||||
(*control plane*). There can be either one or two controller nodes in a
|
||||
StarlingX edge cloud.
|
||||
|
||||
- Runs cloud control functions for managing cloud resources.
|
||||
- Runs all OpenStack control functions (e.g. managing images, virtual
|
||||
volumes, virtual network, and virtual machines).
|
||||
- Runs all OpenStack control functions, such as managing images, virtual
|
||||
volumes, virtual network, and virtual machines.
|
||||
- Can be part of a two-node HA control node cluster for running control
|
||||
functions either active/active or active/standby.
|
||||
|
||||
@ -48,14 +48,15 @@ Infra Network
|
||||
to the INFRA network.
|
||||
|
||||
IPMI Network
|
||||
An optional network on which IPMI interfaces of all nodes are connected. The
|
||||
network must be reachable using L3/IP from the controller's OAM interfaces.
|
||||
An optional network on which Intelligent Platform Management Interface
|
||||
(IPMI) interfaces of all nodes are connected. The network must be reachable
|
||||
using L3/IP from the controller's OAM interfaces.
|
||||
|
||||
You can optionally connect all node types to the IPMI network.
|
||||
|
||||
Management Network
|
||||
A private network (i.e. not connected externally), tipically 10GE, used for
|
||||
the following:
|
||||
A private network (that is, not connected externally), typically 10GE, used
|
||||
for the following:
|
||||
|
||||
- Internal OpenStack / StarlingX monitoring and control.
|
||||
- VM I/O access to a storage cluster.
|
||||
@ -63,20 +64,20 @@ Management Network
|
||||
All nodes are required to be connected to the management network.
|
||||
|
||||
Node
|
||||
A computer which is usually a server-class system.
|
||||
A computer that is usually a server-class system.
|
||||
|
||||
Node Interfaces
|
||||
All nodes' network interfaces can, in general, optionally be either:
|
||||
|
||||
- Untagged single port.
|
||||
- Untagged two-port LAG and optionally split between redudant L2 switches
|
||||
- Untagged two-port LAG and optionally split between redundant L2 switches
|
||||
running vPC (Virtual Port-Channel), also known as multichassis
|
||||
EtherChannel (MEC).
|
||||
- VLAN on either single-port ETH interface or two-port LAG interface.
|
||||
|
||||
OAM Network
|
||||
The network on which all external StarlingX platform APIs are exposed,
|
||||
(i.e. REST APIs, Horizon web server, SSH, and SNMP), typically 1GE.
|
||||
(that is, REST APIs, Horizon web server, SSH, and SNMP), typically 1GE.
|
||||
|
||||
Only controller type nodes are required to be connected to the OAM network.
|
||||
|
||||
@ -85,15 +86,15 @@ PXEBoot Network
|
||||
network.
|
||||
|
||||
By default, controllers use the management network for boot/install of other
|
||||
nodes in the OpenStack cloud. If this optional network is used, all node types
|
||||
are required to be connected to the PXEBoot network.
|
||||
nodes in the OpenStack cloud. If this optional network is used, all node
|
||||
types are required to be connected to the PXEBoot network.
|
||||
|
||||
A PXEBoot network is required for a variety of special case situations:
|
||||
|
||||
- Cases where the management network must be IPv6:
|
||||
|
||||
- IPv6 does not support PXEBoot. Therefore, IPv4 PXEBoot network must be
|
||||
configured.
|
||||
- IPv6 does not support PXEBoot. Therefore, you must configure an IPv4
|
||||
PXEBoot network.
|
||||
|
||||
- Cases where the management network must be VLAN tagged:
|
||||
|
||||
@ -114,9 +115,9 @@ Storage
|
||||
- Runs CEPH distributed storage software.
|
||||
- Part of an HA multi-node CEPH storage cluster supporting a replication
|
||||
factor of two or three, journal caching, and class tiering.
|
||||
- Provides HA persistent storage for images, virtual volumes (i.e. block
|
||||
- Provides HA persistent storage for images, virtual volumes (that is, block
|
||||
storage), and object storage.
|
||||
|
||||
Virtual Machines (VM)
|
||||
An instance of a node provided by software (a hypervisor) which runs within
|
||||
An instance of a node provided by software (a hypervisor), which runs within
|
||||
the host operating system and hardware.
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user