diff options
author | Victor Laza <vlaza@cloudbasesolutions.com> | 2015-04-10 10:52:08 +0300 |
---|---|---|
committer | Victor Laza <vlaza@cloudbasesolutions.com> | 2015-05-07 16:02:50 +0300 |
commit | 2db95b8f2d22cff97f23bbe25eebd83a1991fd6c (patch) | |
tree | 40ea335f1ced4e1881142ff2101b7b09fa12b3e0 /docs | |
parent | ef817b11b6265e2af2b25e8f4d3bba101c6b49ea (diff) |
Adding pharos project spec.rst in docs/
JIRA: PHAROS-8 - Adding pharos spec.rst ar request of Trevor including
images; all sourced from https://wiki.opnfv.org/pharos/pharos_specification
Change-Id: I754c0d34d851bc080113fdb125089bfed9d13760
Signed-off-by: Victor Laza <vlaza@cloudbasesolutions.com>
Diffstat (limited to 'docs')
-rw-r--r-- | docs/images/bridge1.png | bin | 0 -> 78415 bytes | |||
-rw-r--r-- | docs/images/bridge2.png | bin | 0 -> 77276 bytes | |||
-rw-r--r-- | docs/images/opnfv-example-lab-diagram.png | bin | 0 -> 70804 bytes | |||
-rw-r--r-- | docs/images/opnfv-pharos-diagram-v01.jpg | bin | 0 -> 63461 bytes | |||
-rw-r--r-- | docs/images/pharos-archi1.jpg | bin | 0 -> 104922 bytes | |||
-rw-r--r-- | docs/spec.rst | 217 |
6 files changed, 217 insertions, 0 deletions
diff --git a/docs/images/bridge1.png b/docs/images/bridge1.png Binary files differnew file mode 100644 index 00000000..9a557aef --- /dev/null +++ b/docs/images/bridge1.png diff --git a/docs/images/bridge2.png b/docs/images/bridge2.png Binary files differnew file mode 100644 index 00000000..7d8c3831 --- /dev/null +++ b/docs/images/bridge2.png diff --git a/docs/images/opnfv-example-lab-diagram.png b/docs/images/opnfv-example-lab-diagram.png Binary files differnew file mode 100644 index 00000000..5a3901cd --- /dev/null +++ b/docs/images/opnfv-example-lab-diagram.png diff --git a/docs/images/opnfv-pharos-diagram-v01.jpg b/docs/images/opnfv-pharos-diagram-v01.jpg Binary files differnew file mode 100644 index 00000000..b6886554 --- /dev/null +++ b/docs/images/opnfv-pharos-diagram-v01.jpg diff --git a/docs/images/pharos-archi1.jpg b/docs/images/pharos-archi1.jpg Binary files differnew file mode 100644 index 00000000..3c4478a8 --- /dev/null +++ b/docs/images/pharos-archi1.jpg diff --git a/docs/spec.rst b/docs/spec.rst new file mode 100644 index 00000000..df80fdfa --- /dev/null +++ b/docs/spec.rst @@ -0,0 +1,217 @@ +Pharos Specification +===================== + +Objectives / Scope +------------------- + +Pharos spec defines the OPNFV test environment (in which OPNFV platform can be deployed and tested … + +- Provides a secure, scalable, standard and HA environment +- Supports full deployment lifecycle (this requires a bare metal environment) +- Supports functional and performance testing +- Provides common tooling and test scenarios (including test cases and workloads) available to the community +- Provides mechanisms and procedures for secure remote access to the test environment + +Virtualized environments will be useful but do not provide a fully featured deployment/test capability + +The high level architecture may be summarized as follow: + +.. image:: images/pharos-archi1.jpg + +Constraints of a Pharos compliant OPNFV test-bed environment +------------------------------------------------------------- + +- One jump (provisioning server) in which the installer runs in a VM +- 2 - 5 compute / controller nodes +- Jump server provisioned with CentOS7 +- Installer (e.g. Foreman) runs its own DHCP server therefore management network should not have DHCP server +- Remote access +- A lights-out network is required for remote management and bare metal provisioning capability + +Target Systems State +--------------------- + +- Target system state includes default software components, network configuration, storage requirements `https://wiki.opnfv.org/get_started/get_started_system_state <https://wiki.opnfv.org/get_started/get_started_system_state>` + + +Rls 1 specification is modeled from Arno + +* First draft of environment for BGS https://wiki.opnfv.org/get_started/get_started_work_environment +* Fuel environment https://wiki.opnfv.org/get_started/networkingblueprint +* Foreman environment https://wiki.opnfv.org/get_started_experiment1#topology + +Hardware +--------- + +**Servers** + +CPU: + +* Intel Xeon E5-2600 (IvyBridge at least, or similar) + +Local Storage: + +* Disks: 4 x 500G-2T + 1 x 300GB SSD (leave some room for experiments) +* First 2 disks should be combined to form a 1 TB virtual store for the OS/Software etc +* Remaining should be combined to form a virtual disk for CEPH storage +* The 5'th disk (SSD) for distributed storage (CEPH) journal towards SSD technology. +* Performance testing requires a mix of compute nodes that have CEPH(swift+Cinder) and without CEPH storage +* Virtual ISO boot capabilities or a separate PXE boot server (DHCP/tftp or Cobbler) + +Memory: + +* 32G RAM Minimum + +Power Supply Single + +* Single power supply acceptable (redundant power not required/nice to have) + +**Provisioning** + +Pre-provisioning Jump Server + +* OS - CentOS7 +* KVM / Qemu +* Installer (Foreman, Fuel, ...) in a VM +* Collaboration Tools + +Test Tools + +Jumphost - `functest <http://artifacts.opnfv.org/functest/docs/functest.html>`_ + +Controller nodes - bare metal + +Compute nodes - bare metal + +**Security** + +- Servers + + - Default permissions + - Server Logins + - **Pharos team needs to provide consistent usernames for infrastructure** + +Remote management +------------------ + +**Remote access** + +- Remote access is required for … + + 1. Developers to access deploy/test environments (credentials to be issued per POD / user) + 2. Connection of each environment to Jenkins master hosted by Linux Foundation for automated deployment and test + +- VPN is optional and dependent on company security rules (out of Pharos scope) +- POD access rules / restrictions … + + - Refer to individual test-bed as each company may have different access rules and procedures + +- Basic requirement is for SSH sessions to be established (initially on jump server) +- Majority of packages installed on a system (tools or applications) will be pulled from an external storage solution so this type of things should be solved in a very general sense for the projects + +Firewall rules + +- SSH sessions +- Jenkins sessions + +Lights-out Management: + +- Out-of-band management for power on/off/reset and bare-metal provisioning +- Access to server is through lights-out-management tool and/or a serial console +- Intel lights-out ⇒ RMM http://www.intel.com/content/www/us/en/server-management/intel-remote-management-module.html +- HP lights-out ⇒ ILO http://www8.hp.com/us/en/products/servers/ilo/index.html +- CISCO lights-out ⇒ UCS https://developer.cisco.com/site/ucs-dev-center/index.gsp + +Linux Foundation - VPN service for accessing Lights-Out Management (LOM) infrastructure for the UCS-M hardware + +- People who can authorize access … 1) 2) 3) +- The people who request VPN access must have a valid PGP key bearing a valid signature from one of these three people. When issuing OpenVPN credentials, LF will be sending TLS certificates and 2-factor authentication tokens, encrypted to each recipient's PGP key. + +Networking +----------- + +Test-bed network + +* 24 or 48 Port TOR Switch +* NICS - 1GE, 10GE - per server can be on-board or PCI-e +* Connectivity for each data/control network is through a separate NIC. This simplifies Switch Management however requires more NICs on the server and also more switch ports +* Lights-out network can share with Admin/Management + +Network Interfaces + +* Option 1: 4x1G Control, 2x40G Data, 48 Port Switch + + * 1 x 1G for ILMI (Lights out Management ) + * 1 x 1G for Admin/PXE boot + * 1 x 1G for control Plane connectivity + * 1 x 1G for storage + * 2 x 40G (or 10G) for data network (redundancy, NIC bonding, High bandwidth testing) + +* Option II: 1x1G Control, 2x 40G (or 10G) Data, 24 Port Switch + + * Connectivity to networks is through VLANs on the Control NIC. Data NIC used for VNF traffic and storage traffic segmented through VLANs + +* Option III: 2x1G Control, 2x10G Data, 2x40G Storage, 24 Port Switch + + * Data NIC used for VNF traffic, storage NIC used for control plane and Storage segmented through VLANs (separate host traffic from VNF) + * 1 x 1G for IPMI + * 1 x 1G for Admin/PXE boot + * 2 x 10G for control plane connectivity/Storage + * 2 x 40G (or 10G) for data network + +Storage Network +---------------- + +- Needs specification + +** Topology ** + +- Subnet, VLANs (want to standardize but may be constrained by existing lab setups or rules) +- IPs +- Types of NW - lights-out, public, private, admin, storage +- May be special NW requirements for performance related projects +- Default gateways + +.. image:: images/bridge1.png + +controller node bridge topology overview + + +.. image:: images/bridge2.png + +compute node bridge topology overview + +Architecture +------------- + +** Network Diagram ** + +The Pharos architecture may be described as follow: Figure 1: Standard Deployment Environment + +.. image:: images/opnfv-pharos-diagram-v01.jpg + +Figure 1: Standard Deployment Environment + + +Tools +------ + +- Jenkins +- Tempest / Rally +- Robot +- Git repository +- Jira +- FAQ channel + +Sample Network Drawings +----------------------- + +Files for documenting lab network layout. These were contributed as Visio VSDX format compressed as a ZIP file. Here is a sample of what the visio looks like. + +Download the visio zip file here: `opnfv-example-lab-diagram.vsdx.zip <https://wiki.opnfv.org/_media/opnfv-example-lab-diagram.vsdx.zip>` + +.. image:: images/opnfv-example-lab-diagram.png + +FYI: `Here <http://www.opendaylight.org/community/community-labs>` is what the OpenDaylight lab wiki pages look like. + + |