docs/pharos-spec.rst

   1 Pharos Specification
   2 =====================
   3
   4 Objectives / Scope
   5 -------------------
   6
   7 Pharos defines the state of the deployment environment (i.e. pre-deployment state). While it defines the state of the environment it does not define the implementation of a test infrastructure. This guarantees that the OPNFV platform will sucessfully deploy and can be tested using the the automated toolchain.
   8
   9 A Pharos compliant lab ...
  10 - Provides a secure, scalable, standard and HA environment
  11 - Supports full deployment lifecycle (this requires a bare metal environment)
  12 - Supports functional and performance testing
  13 - Provides common tooling and test scenarios (including test cases and workloads) available to the community
  14 - Provides mechanisms and procedures for secure remote access to the test environment
  15
  16 Virtualized environments will be useful for development but do not provide a fully featured deployment/test capability.
  17
  18 The high level architecture may be summarized as follows:
  19
  20 .. image:: images/pharos-archi1.jpg
  21
  22 Constraints of a Pharos compliant OPNFV test-bed environment
  23 -------------------------------------------------------------
  24
  25 - One CentOS 7 Jump Server on which the virtualized Openstack/OPNFV installer runs
  26 - Desired installer - may be Fuel, Foreman, etc
  27 - 2 - 5 compute / controller nodes (`BGS <https://wiki.opnfv.org/get_started/get_started_work_environment>`_ requires 5 nodes)
  28 - Network topology allowing for Lights-out management, Admin, Public, Private, and Storage Networks
  29 - Remote access
  30 - Test Tools
  31
  32 Target Systems State
  33 ---------------------
  34
  35 - 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>`
  36
  37
  38 Rls 1 specification is modeled on setups used for integration/deployment with Fuel and Foreman ...
  39
  40 * Draft of environment for BGS https://wiki.opnfv.org/get_started/get_started_work_environment
  41 * Fuel environment https://wiki.opnfv.org/get_started/networkingblueprint
  42 * Foreman environment https://wiki.opnfv.org/get_started_experiment1#topology
  43
  44 Hardware
  45 ---------
  46
  47 **Servers**
  48
  49 CPU:
  50
  51 * Intel Xeon E5-2600v2 Series (Ivy Bridge and newer, or similar)
  52
  53 Local Storage Configuration:
  54
  55 Below describes the minimum for the Pharos spec, which is designed to provide enough capacity for a reasonably functional environment. Additional and/or faster disks are nice to have and may produce a better result.
  56
  57 * Disks: 2 x 1TB + 1 x 100GB SSD
  58 * The first 1TB HDD should be used for OS & additional software/tool installation
  59 * The second 1TB HDD configured for CEPH object storage
  60 * Finally, the 100GB SSD should be used as the CEPH journal
  61 * Performance testing requires a mix of compute nodes that have CEPH(swift+Cinder) and without CEPH storage
  62 * Virtual ISO boot capabilities or a separate PXE boot server (DHCP/tftp or Cobbler)
  63
  64 Memory:
  65
  66 * 32G RAM Minimum
  67
  68 Power Supply Single
  69
  70 * Single power supply acceptable (redundant power not required/nice to have)
  71
  72 **Provisioning**
  73
  74 Jump Server Installation
  75
  76   * OS: CentOS 7
  77   * KVM / Qemu
  78   * Installer (Foreman, Fuel, ...) in a VM
  79   * Tools
  80
  81 See `Jump Server Installation <https://wiki.opnfv.org/jump_server_installation_guide>`_ for detailed Jump Server installation details.
  82
  83 Test Tools - See `functest <http://artifacts.opnfv.org/functest/docs/functest.html>`_
  84
  85 Controller nodes - these are bare metal servers
  86
  87 Compute nodes - these bare metal servers
  88
  89 **Infrastructure naming conventions / recommendations**
  90
  91 The Pharos specificaiton provides recomendations for default logins and  naming conventions
  92
  93 See `Infrastructure naming conventions <https://wiki.opnfv.org/pharos/pharos_naming>`_
  94
  95
  96 Remote management
  97 ------------------
  98
  99 **Remote access**
 100
 101 - Remote access is required for …
 102
 103   1. Developers to access deploy/test environments (credentials to be issued per POD / user)
 104   2. Connection of each environment to Jenkins master hosted by Linux Foundation for automated deployment and test
 105
 106 - VPN is optional and dependent on company security rules (out of Pharos scope)
 107 - POD access rules / restrictions …
 108
 109   - Refer to individual test-bed as each company may have different access rules and procedures
 110
 111 - Basic requirement is for SSH sessions to be established (initially on jump server)
 112 - 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
 113
 114 Firewall rules
 115
 116 - SSH sessions
 117 - Jenkins sessions
 118
 119 Lights-out Management:
 120
 121 - Out-of-band management for power on/off/reset and bare-metal provisioning
 122 - Access to server is through lights-out-management tool and/or a serial console
 123 - Intel lights-out ⇒ RMM http://www.intel.com/content/www/us/en/server-management/intel-remote-management-module.html
 124 - HP lights-out ⇒ ILO http://www8.hp.com/us/en/products/servers/ilo/index.html
 125 - CISCO lights-out ⇒ UCS https://developer.cisco.com/site/ucs-dev-center/index.gsp
 126
 127 Linux Foundation - VPN service for accessing Lights-Out Management (LOM) infrastructure for the UCS-M hardware
 128
 129 - People with admin access to LF infrastructure:
 130
 131 1. amaged@cisco.com
 132 2. cogibbs@cisco.com
 133 3. daniel.smith@ericsson.com
 134 4. dradez@redhat.com
 135 5. fatih.degirmenci@ericsson.com
 136 6. fbrockne@cisco.com
 137 7. jonas.bjurel@ericsson.com
 138 8. jose.lausuch@ericsson.com
 139 9. joseph.gasparakis@intel.com
 140 10. morgan.richomme@orange.com
 141 11. pbandzi@cisco.com
 142 12. phladky@cisco.com
 143 13. stefan.k.berg@ericsson.com
 144 14. szilard.cserey@ericsson.com
 145 15. trozet@redhat.com
 146
 147 - The people who require 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.
 148
 149 Networking
 150 -----------
 151
 152 Test-bed network
 153
 154 * 24 or 48 Port TOR Switch
 155 * NICS - 1GE, 10GE - per server can be on-board or PCI-e
 156 * 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
 157 * Lights-out network can share with Admin/Management
 158
 159 Network Interfaces
 160
 161 * Option 1: 4x1G Control, 2x40G Data, 48 Port Switch
 162
 163   * 1 x 1G for ILMI (Lights out Management )
 164   * 1 x 1G for Admin/PXE boot
 165   * 1 x 1G for control Plane connectivity
 166   * 1 x 1G for storage
 167   * 2 x 40G (or 10G) for data network (redundancy, NIC bonding, High bandwidth testing)
 168
 169 * Option II: 1x1G Control, 2x 40G (or 10G) Data, 24 Port Switch
 170
 171   * Connectivity to networks is through VLANs on the Control NIC. Data NIC used for VNF traffic and storage traffic segmented through VLANs
 172
 173 * Option III: 2x1G Control, 2x10G Data, 2x40G Storage, 24 Port Switch
 174
 175   * Data NIC used for VNF traffic, storage NIC used for control plane and Storage segmented through VLANs (separate host traffic from VNF)
 176   * 1 x 1G for IPMI
 177   * 1 x 1G for Admin/PXE boot
 178   * 2 x 10G for control plane connectivity/Storage
 179   * 2 x 40G (or 10G) for data network
 180
 181 ** Topology **
 182
 183 - Subnet, VLANs (may be constrained by existing lab setups or rules)
 184 - IPs
 185 - Types of NW - lights-out, public, private, admin, storage
 186 - May be special NW requirements for performance related projects
 187 - Default gateways
 188
 189 .. image:: images/bridge1.png
 190
 191 controller node bridge topology overview
 192
 193
 194 .. image:: images/bridge2.png
 195
 196 compute node bridge topology overview
 197
 198 Architecture
 199 -------------
 200
 201 ** Network Diagram **
 202
 203 The Pharos architecture may be described as follow: Figure 1: Standard Deployment Environment
 204
 205 .. image:: images/opnfv-pharos-diagram-v01.jpg
 206
 207 Figure 1: Standard Deployment Environment
 208
 209
 210 Tools
 211 ------
 212
 213 - Jenkins
 214 - Tempest / Rally
 215 - Robot
 216 - Git repository
 217 - Jira
 218 - FAQ channel
 219
 220 Sample Network Drawings
 221 -----------------------
 222
 223 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.
 224
 225 Download the visio zip file here: `opnfv-example-lab-diagram.vsdx.zip <https://wiki.opnfv.org/_media/opnfv-example-lab-diagram.vsdx.zip>`
 226
 227 .. image:: images/opnfv-example-lab-diagram.png
 228
 229 FYI: `Here <http://www.opendaylight.org/community/community-labs>` is what the OpenDaylight lab wiki pages look like.