RedHat OpenStack Platform Overview from CEO of Innovations Development Lab

1. R E D H AT O P E N STAC K
P L AT F O R M OV E RV I E W
I N N OVAT I O N S D E V E LO P M E N T L A B
D M Y T R O H A N Z H E LO
R E D H AT ACC R E D I T E D P R O F E S S I O N A L
R E D H AT S A L E S E N G I N E E R S P E C I A L I ST - C LO U D I N F R A ST R U C T U R E

2. G E N E R A L OV E RV I E W

3. • The OpenStack project is an open source cloud computing platform that
supports all types of cloud environments. The project aims for simple
implementation, massive scalability, and a rich set of features. Cloud
computing experts from around the world contribute to the project.
• OpenStack provides an Infrastructure-as-a-Service (IaaS) solution
through a variety of complementary services. Each service offers an
Application Programming Interface (API) that facilitates this integration.
• This guide covers step-by-step deployment of the major OpenStack
services using a functional example architecture suitable for new users of
OpenStack with sufficient Linux experience. This guide is not intended to
be used for production system installations, but to create a minimum
proof-of-concept for the purpose of learning about OpenStack.
3

4. O P E N STAC K M A P
4

5. O P E N STAC K CO M P O N E N T S
• Compute (Nova)
• Networking (Neutron)
• Block Storage (Cinder)
• Object Storage (Swift)
• VM Image Storage (Glance)
• Identity and Access Control
(Keystone)
5
• Orchestration Engine (Heat)
• Telemetry (Ceilometer)
• Bare Metal for Tenants (Ironic)
• Dashboard (Horizon)
• Data Processing (Sahara)
• Deployment and Management
(Director)

6. OV E RV I E W
OpenStack Connects Two Worlds
6

7. OV E RV I E W
• Tenants are actual IaaS cloud users
• Consume services enabled in the cloud
• See only their own and shared cloud resources
• Isolated from other tenants
• Do not have a view to the cloud infrastructure
• Operators are users with special privileges
• Often the same role that has root access to the systems
• Configure, monitor, and maintain OpenStack cloud for tenants
• Aware about cloud infrastructure and external network and storage
environment
7

8. OV E RV I E W
Cloud Interfaces
• Tenants and operators use the same interfaces:
• OpenStack Dashboard (Horizon)
• CLI tools
• REST APIs
• Libraries (such as os_cloud in Ansible or boto in Python)
• OpenStack policy engine filters which API calls require
administrative privileges
8

9. CO M P U T E ( N OVA )
9
T E N A N T V I E W O P E R ATO R V I E W
• I need VMs, anytime
• How many can I
have?
• It must be secure
• SSH and VNC,
please
• I have hardware
capacity available
• This is how you
consume it
• I set usage quotas
• I design for
performance and
scalability

10. CO M P U T E ( N OVA )
10
T E N A N T V I E W O P E R ATO R V I E W
• Similar to Amazon EC2
• Self-service VMs: Boot an instance of a selected
flavor (vCPU, RAM, disk size), OS image (from
Glance), SSH key pair, host aggregate or availability
zone (AZ), custom metadata, user data, security
groups, with/without ephemeral disk
• Reboot, stop, resize, terminate
• See the console log of this instance, open VNC/
SPICE session, change VM root password (if OS
supports)
• Reserve, assign, and release floating IPs
• Manage key pairs and security groups
• Check quota usage
• Select which Neutron network or port
• Other Neutron/Cinder shortcuts for network and
volume management
• No need to manage hypervisors individually, due to
distributed design of OpenStack, at any scale
• Supports KVM and VMware (vCenter)
• Defines which choices are available to tenants:
flavors offering specific capabilities and carefully
planned capacity and overcommit ratios
• Easier maintenance and operations with support for
node evacuation, mark “host down,” and instance
live-migration
• Define host aggregates and AZs with specific
metadata to allow advanced scheduling and
request filtering
• Set NFV-specific flavors, including vCPU pinning,
large pages, vCPU, RAM, and I/O device NUMA
awareness, SR-IOV/PCI passthrough
• Instance HA, transparent to tenants, if enabled

11. CO M P U T E ( N OVA )
11

12. N E T WO R K I N G ( N E U T R O N )
12
T E N A N T V I E W O P E R ATO R V I E W
• I need my own
network, isolated
from others
• Some private IPs,
some public IPs
• These are my QoS
specs
• Let me share
networks with
others
• I design a network
overlay and provide
external access
• I have very few
public IPs
• I set rules, policies,
quotas
• With SDN, I can
centrally manage
and monitor it all

13. N E T WO R K I N G ( N E U T R O N )
13
T E N A N T V I E W O P E R ATO R V I E W
• Similar to Amazon VPC, ELB
• Create, Report, Update, Delete (CRUD) networks,
subnets and ports, for basic L2 and L3 with IP
address management (DHCP)
• Define a tenant network (overlay)
• Additionally:
• Provider networks
• Quotas
• Security groups (per port)
• East/West L3 routing with tenant-defined
routers
• External gateway, NAT, floating IPs
• Load balancing, VPN and firewall
• IPv6 tenant network management
• QoS (rate limit policies) per port, per network
• RBAC for granular sharing of tenant networks
• Defines provider networks, manually set up in
Neutron by the operator, representing pre-existing
networks (i.e. VLAN), useful for pointing to
corporate DNS or gateways with multiple routes
• Multiple simultaneous L2 technologies on a single
installation via ML2
• Default Open vSwitch, or choose from dozens of
commercial SDN vendors
• Configures SSL/TLS back end for LBaaS
• Define floating IP ranges, normally for publicly
routable IPv4 addresses
• Offer/delegate IPv6 tenant networks (SLAAC,
DHCP)
• Define and enforce QoS (currently only egress
flows)
• VXLAN offloading to HW available (up to 4x
throughput)
• Distributed Virtual Routing (DVR) for better
scalability
• L2Pop and responder to mitigate ARP flooding at
scale

14. N E T WO R K I N G ( N E U T R O N )
14

15. B LO C K STO R AG E ( C I N D E R )
15
T E N A N T V I E W O P E R ATO R V I E W
• Too much data in
my VMs!
• I need permanent
storage
• Can I snapshot,
back up, and roll
back?
• Encrypted, please
• I constantly buy
storage
• I must allocate
space to tenants
• I can combine
different tiers of
technologies (NAS,
SAN)
• I set rules, policies,
quotas

16. B LO C K STO R AG E ( C I N D E R )
16
T E N A N T V I E W O P E R ATO R V I E W
• Similar to Amazon EBS
• CRUD operations with block devices
• Add hard drives to an instance
• Persistent storage, can be cloned, snapshotted,
replicated, or imported/exported to another AZ
(also public storage like Google Cloud Storage)
• Encryption available via LUKS (if enabled by Ops)
• Hot-unplug from one instance and re-attach to
another instance
• Non-disruptive and incremental snapshot: ideal for
backup/restore and DR use cases
• QoS available (total IOPS)
• If exposed, vendor-specific features (mirroring,
compression, replication, and thin provisioning)
• Uses Red Hat Ceph storage by default
• Multiple back ends (LVM, iSCSI, NFS, ScaleIO, etc.)
including proprietary ones with more specific
features
• Faster provisioning via oversubscription, thin
provisioning, and generic image cache
• Simplified operations, DR and backup with generic
volume migration and replication (sync/async, with
N number of replicas) between different storage
back ends
• Private volume types for premium levels of service
(SSD, thick provisioned)
• iSCSI multi-path support for extra reliability

17. B LO C K STO R AG E ( C I N D E R )
17

18. O B J E C T STO R AG E ( S W I F T )
18
T E N A N T V I E W O P E R ATO R V I E W
• My application
needs object
storage (files,
media)
• I can use HTTP(s)
• Stateless, please!
No time for
mounting file
systems
• I offer a private S3-
like experience
• I must scale without
limits
• I want advanced
features

19. O B J E C T STO R AG E ( S W I F T )
19
T E N A N T V I E W O P E R ATO R V I E W
• Similar to Amazon S3 (a modern version
of FTP, WebDAV)
• CRUD objects in containers, per account
• Ideal for storing static objects (media,
web files, email)
• Only useful if the application understands
the Swift/S3 API
• Also useful for storing Glance image
backups
• Not meant to be used as POSIX file
system
• Fast-POST allows fast, efficient updates of
metadata without uploading content
again
• Very few dependencies with other
OpenStack modules, mostly Keystone for
RBAC
• Scales horizontally up to petabytes
• Replication for global clusters
• Advanced Swift features: middleware for
API processing, temporary URLs, URL
rewrite
• Swift requires its own storage space, not
integrated with Ceph
• Reduced availability for further storage
efficiency with erasure coding

20. O B J E C T STO R AG E ( S W I F T )
20

21. V M I M AG E STO R AG E ( G L A N C E )
21
T E N A N T V I E W O P E R ATO R V I E W
• Which operating
systems can I use?
• This is my own
version, store it just
for me
• Is the OS image
genuine?
• Take this VMware
template and
import it
• Only approved OS
can be used in my
cloud
• Centrally offer
updated OS
• Leverage storage
integration to
reduce network
usage

22. V M I M AG E STO R AG E ( G L A N C E )
22
T E N A N T V I E W O P E R ATO R V I E W
• Similar to Amazon AMIs
• CRUD images (VM templates, a bootable
OS) and snapshots (VM backup)
• Private or public images
• Upload from file or from URL
• Metadata can host any key-value pair,
useful for documenting OS version, date,
etc.
• Multiple disk formats (QCOW2, RAW, ISO,
VDI, VMDK) and container formats (bare,
OVF, AMI, ARI)
• Checksum and signature verification for
extra security
• Best practice: Offer “golden images” to
tenants via public Glance images
• Store images using Cinder as back end
• If not using Ceph, director configures
Swift as a Glance image store
• If using Ceph, Glance leverages advanced
RBD features (cache, thin provisioning,
immediate snapshot)
• Automatic Nova/libvirt/KVM optimization
depending on guest OS via os_name
attribute

23. V M I M AG E STO R AG E ( G L A N C E )
23

24. I D E N T I TY A N D ACC E S S CO N T R O L
( K E Y STO N E )
24
T E N A N T V I E W O P E R ATO R V I E W
• I am not a hacker,
believe me!
• My boss just gave
me permission to
ask for VMs
• Where are all the
services?
• I am a project lead, I
must be admin of
my project
• Who are you?
• Let me validate with
LDAP
• I must integrate with
my company’s SSO
• I must secure entry
points with TLS
certificates

25. I D E N T I TY A N D ACC E S S CO N T R O L
( K E Y STO N E )
25
T E N A N T V I E W O P E R ATO R V I E W
• Similar to Amazon IAM
• Authenticates and gives authorization to
users. Provides session tokens that are
used for all OpenStack actions
• CRUD user, tenants (project), roles (as
long as Operator allows it)
• Change password, also download
credentials file (RC) with EC2 keys
• Discover OpenStack endpoints via
catalog
• Kerberos for SSO in both Web (Horizon)
and in CLI on client systems with SSSD
• Federated Identity: Same user/password
across multiple OpenStack providers
• CRUD user, tenants (project), roles, and
domains (for v3) for better RBAC
• SAML Federation for authentication with
external providers (pre-existing) or other
clouds, via Red Hat SSO
• Multiple identity back ends: LDAP,
ActiveDirectory, FreeIPA, PAM, etc.
• Preferred authorization back end is
MariaDB
• Lightweight tokens (Fernet) for better
performance and scalability
• Logs in standard CADF auditable format
• Public endpoint protection with SSL/TLS

26. I D E N T I TY A N D ACC E S S CO N T R O L
( K E Y STO N E )
26

27. O R C H E ST R AT I O N E N G I N E ( H E AT )
27
T E N A N T V I E W O P E R ATO R V I E W
• This is the blueprint
of my application
deployment:
dependencies,
config, etc.
• Can you run this for
me?
• Scale it out when
this threshold is
reached
• To compete with
public clouds, I
should offer an
orchestration
engine
• Auto-scaling, load
balancers, and
quotas allow me to
monitor and predict
demand

28. O R C H E ST R AT I O N E N G I N E ( H E AT )
28
T E N A N T V I E W O P E R ATO R V I E W
• Similar to Amazon CloudFormation
• CRUD templates (stacks) that can be
stopped and resumed
• Instructs OpenStack to automate
deployment of resources as defined in
HOT or CloudFormation (CFN) languages
• Well-defined and mature, HOT offers
more modularity and flexibility
improvements (i.e., resource chains, pre-
delete hooks, etc.)
• Very useful when combined with
Ceilometer and LBaaS. Example use case
is instance auto-scaling by creating
another VM when cluster load reaches
80% CPU
• Heat may require minor tuning to ensure
enough CPU and RAM are assigned to it
• Can offer shared templates, approved by
IT
• Excellent integration with CloudForms to
create an advanced service catalog to
end users, with policies and customized
quota and capacity management

29. O R C H E ST R AT I O N E N G I N E ( H E AT )
29

30. T E L E M E T R Y ( C E I LO M E T E R )
30
T E N A N T V I E W O P E R ATO R V I E W
• How much CPU,
RAM, disk am I
using per hour?
• Notify me of any
alarms here
• I wish I could charge
back/show back
how much every
user is consuming
• This is useful for my
own internal usage!

31. T E L E M E T R Y ( C E I LO M E T E R )
31
T E N A N T V I E W O P E R ATO R V I E W
• Similar to Amazon CloudWatch
• Metrics (CPU, RAM usage) and events
(e.g., instance is created) can be listed
• Alarms (e.g., CPU threshold reached) can
also be triggered. Alarm thresholds can
be custom defined, all via the Aodh API
(pronounced “hey”)
• Querying for historical values is available
• Historically, Ceilometer required tuning at
scale to allow for tenants polling historical
values. MongoDB was the only back end
• Now Ceilometer offers much better
performance and scalability thanks to the
split of its components
• Gnocchi stores/indexes time-series
metrics
• Aodh does the same for alarms
• Panko is the event engine
• Connects with CloudForms for capacity
monitoring and management

32. T E L E M E T R Y ( C E I LO M E T E R )
32

33. B A R E M E TA L F O R T E N A N T S ( I R O N I C )
33
T E N A N T V I E W O P E R ATO R V I E W
• I need a physical
VM for a while, with
a generic OS
• I do not have many
security or isolation
concerns, nor
network protection
needs
• I have some spare
nodes in a separate
cluster, with a
shared network
• I will offer them to
trusted users
groups
• I will provide the OS
image

34. B A R E M E TA L F O R T E N A N T S ( I R O N I C )
34
T E N A N T V I E W O P E R ATO R V I E W
• Similar to Amazon Dedicated EC2 Servers
• Nova commands are used against an
existing bare-metal Host Aggregate
• After Ironic reserves a bare-metal node,
Nova is used to provision the instance
• Only works with Glance images tagged
hypervisor_type=ironic
• Can deploy Linux or Windows machines
(requires extra steps)
• Allocates a pool of nodes to be entirely
allocated to certain tenants, on demand
• Requires careful design for tenant-facing
service (network isolation, security, etc.)
• Defines Nova Host Aggregates with key-
value baremetal and a flavor with key
hypervisor_type="ironic"
• Quotas and capacity planning are needed
• Good integration with most hardware
vendors: Dell, Cisco, HP, etc.
• Introspection process to detect HW
capabilities
• Requires many Nova and Neutron
changes (i.e. Flat Networking for PXE
provisioning)

35. B A R E M E TA L F O R T E N A N T S ( I R O N I C )
35

36. DA S H B OA R D ( H O R I ZO N )
36
T E N A N T V I E W O P E R ATO R V I E W
• I need a UI to
manage my
workloads or
troubleshoot
• I do not like the CLI
• I want to see my
Heat topologies
• Quickly display my
quota usage and
default options
• I want an admin
panel
• I want quick access
to my Red Hat
Insights account
• I want to see all
Neutron networks
and routers

37. DA S H B OA R D ( H O R I ZO N )
37

38. DATA P R O C E S S I N G ( S A H A R A )
38
T E N A N T V I E W O P E R ATO R V I E W
• I need a Hadoop
cluster for a few
hours
• I need to try
different big data
platforms
• I want my clusters to
scale automatically
• I do not have the
manpower to
customize big data
platforms to all of
my tenants
• I will get third-party
providers and
deliver their stacks
as a service

39. DATA P R O C E S S I N G ( S A H A R A )
39
T E N A N T V I E W O P E R ATO R V I E W
• Similar to Amazon Elastic MapReduce
(EMR)
• Run Hadoop workloads in a few clicks
without expertise in Hadoop operations
• Simple parameters such as Hadoop
version, cluster topology, and node count
• Data can be hosted elsewhere (S3, Swift,
etc.)
• Rapid provisioning of Hadoop clusters for
Dev and QA
• “Analytics-as-a-Service" for bursty or ad
hoc workloads
• Utilization of unused compute power
from a general-purpose OpenStack cloud
to perform data processing tasks
• Supports Hadoop distributions on
CentOS and Red Hat Enterprise Linux 7:
• Cloudera
• HortonWorks
• Ambari
• MapR
• Plugin Image Packaging Tool to validate
custom plug-ins, package them, and
generate clusters from clean, versioned,
OS-only images

40. DATA P R O C E S S I N G ( S A H A R A )
40

41. S H A R E D F I L E SY ST E M ( M A N I L A )
41
T E N A N T V I E W O P E R ATO R V I E W
• I need a network
folder to share files
between VMs
• Sometimes I share it
with other users in
my team
• I do not want to
manage the folder
(permissions,
quotas)
• I do not have the
time to create
temporary shares
and enable network
security
• I wish I could
automatically
leverage OpenStack
users and groups

42. S H A R E D F I L E SY ST E M ( M A N I L A )
42
T E N A N T V I E W O P E R ATO R V I E W
• Similar to Amazon Elastic File System but
not just NFS, also CIFS
• Creates a network file share, available in a
Neutron shared network
• Can be shared with other tenants (RBAC),
including mappings to LDAP entities
• User-defined quotas, policies, replication,
snapshots, and extend/shrink capacity
• VM operating system must connect to the
share using whatever network protocol
has been set (NFS, CIFS)
• Significantly reduces operational burden
• Delegates storage management to end
users with clearly defined limits and
boundaries
• NFS (access by IP address or subnet)
• CIFS (authentication by user)
• In OpenStack Platform, Manila is GA,
deployed via director
• Only NetApp driver is GA
• CephFS driver is Tech Preview

43. S H A R E D F I L E SY ST E M ( M A N I L A )
43

44. D I R E C TO R

45. R E D H AT O P E N STAC K P L AT F O R M
D I R E C TO R
• Leverages best practices and reference architectures from extensive field
experience
• Safely upgrade and update production OpenStack deployments
• Out-of-the-box Control Plane HA thanks to Pacemaker
• External load balancer support
• Ceph deployment and configuration as storage back end
• Can connect to existing Ceph
• API-driven deployment (and management) of Red Hat OpenStack Platform
• Allows CloudForms integration
45

46. R E D H AT O P E N STAC K P L AT F O R M
D I R E C TO R
• Supported partner hardware integration (Ironic, Cinder, Neutron,
Manila)
• Cisco UCS, Dell, Intel, HP, Fujitsu, SeaMicro, and Open
CloudServer
• Cisco Nexus 1000v (networking) and other SDNs
• Netapp Data ONTAP (Cinder, Manila storage) and other storage
• Configuration stored as YAML code (VLAN, IP ranges)
• Director CLI unified with standard OpenStack interfaces
46

47. D I R E C TO R
Building Scalable Clouds
• Scales to hundreds of nodes, automating entire hardware life cycle
• Ready state configuration for selected hardware that automatically configures RAID,
BIOS, network bonding, etc.
• Pattern-based automatic discovery and selection of appropriate nodes from hardware
inventory
• Automated Health Check can execute performance test before deployment to
identify possible misconfigurations or faulty servers
• Ability to validate installation post deployment using Tempest
• Easy to scale up and down—add compute and storage capacity (see deployment limits)
• Enhanced management via CloudForms for both tenants and administrators
47

48. T R I P L E O
OpenStack on OpenStack
• Director is based on upstream OpenStack deployment project TripleO
• Operator uses a specialized OpenStack installation: undercloud
• Undercloud deploys and updates production OpenStack installation: overcloud
48

49. D I R E C TO R T R I P L E O
49
Life Cycle

50. D I R E C TO R G R A P H I CA L U S E R
I N T E R FAC E ( U N D E R C LO U D )
50

51. D I R E C TO R VA L I DAT I O N S
( U N D E R C LO U D )
• Ansible-driven solution to catch potential hardware, networking, and
deployment issues to reduce deployment failures
• Simplifies the burden on IT staff by providing recommended configuration
solution settings when issues are detected
• Helps customers to achieve production-ready deployments through entire
process
• Pre-installation (prior to starting deployment)
• Post-installation (checks after deployment)
• Upstream project: tripleo-validations
51

52. D E FAU LT R O L E S ( R E F. A R C H )
• Five default roles:
• Controller
• Compute
• BlockStorage (Cinder)
• CephStorage
• ObjectStorage (Swift)
• Operators can easily customize
and create their own roles
• Further tuning available as post-
installation scripts
52

53. CO M P O S A B L E R O L E S A N D
C U STO M S E RV I C E S
• Distribute services specific to your data center and architecture
requirements to individual node or group of nodes
53

54. CO N T R O L P L A N E H I G H AVA I L A B I L I TY
54

55. N F V I N STA L L AT I O N S W I T H D I R E C TO R
• Director allows operator to define advanced resource partitioning at deploy
time with control of NUMA/CPU pinning, Hugepages, IRQ isolation, SR-IOV,
and OVS+DPDK all via composable roles
55
S R - I OV D E P LOY M E N T
( D P D K G U E ST )
OV S + D P D K D E P LOY M E N T
( D P D K G U E ST )

56. I N T E G R AT I O N S

57. R E D H AT E N T E R P R I S E L I N U X
57

58. C E RT I F I E D PA RT N E R P LU G - I N S
58

59. S O F T WA R E - D E F I N E D N E T WO R K I N G
• Dozens of software-defined networking (SDN) partners, Neutron certified
• Director can automatically configure Cisco, Nuage, PLUMgrid
• More to come
• Two main networking models:
• Software-centric; uses general-purpose hardware
• Hardware-centric; requires specific network hardware
• Can extend Neutron via ML2 drivers, core plug-ins, or advanced services
59

60. R E D H AT C LO U D F O R M S
• Two complementary options
• OpenStack workload management
• OpenStack infrastructure management
• OpenStack workload management
• Tenant- and operator-facing
• Self-service console
• Orchestration
• OpenStack infrastructure management
• Operator-facing
• Deployment details, service monitoring, drift history
• Scaling
60

61. R E D H AT C E P H STO R AG E
• Red Hat Ceph Storage is included with Red Hat OpenStack Platform
• Support for up to 64TB
• Red Hat OpenStack Platform director supports Ceph Storage deployment
• Ceph is default back end for OpenStack services
• Ceph cluster can be installed and updated by director
• Overcloud can be connected to externally managed Ceph cluster
• Ceph RADOS Object Gateway can be enabled
61

62. P E R F O R M A N C E M O N I TO R I N G
62

63. AVA I L A B I L I TY M O N I TO R I N G
63

64. C E N T R A L I Z E D LO G G I N G
64

65. R E D H AT I D E N T I TY M A N AG E M E N T
65

66. R E D H AT S AT E L L I T E
• Advanced Management of Node Content
• Subscription management
• Review of content (packages) on nodes
• New content notification, errata overview
• Manage which packages are available to nodes
66

67. O P E N S H I F T CO N TA I N E R P L AT F O R M
67

68. A N S I B L E E N G I N E A N D
A N S I B L E TO W E R
68

69. R E D H AT C LO U D S U I T E
69

70. H Y P E RV I S O R S

71. C H O O S I N G A H Y P E RV I S O R
A hypervisor provides software to manage virtual machine access to the underlying
hardware. The hypervisor creates, manages, and monitors virtual machines. OpenStack
Compute (nova) supports many hypervisors to various degrees, including:
• Ironic
• KVM
• LXC
• QEMU
• VMware ESX/ESXi
• Xen (using libvirt)
• XenServer
• Hyper-V
• PowerVM
• UML
• Virtuozzo
• zVM
71

72. H A R D WA R E

73. H A R D WA R E R E Q U I R E M E N T S
73

74. H A R D WA R E R E CO M M E N DAT I O N S
IOPS-OPTIMIZED SOLUTIONS
With the growing use of flash storage, IOPS-intensive workloads are increasingly being hosted on
Ceph clusters to let organizations emulate high-performance public cloud solutions with private
cloud storage. These workloads commonly involve structured data from MySQL-, MariaDB-, or
PostgreSQL-based applications. OSDs are typically hosted on NVMe SSDs with co-located Ceph
write journals. Typical servers are listed in Table 2, and include the following elements:
• CPU. 10 cores per NVMe SSD, assuming a 2 GHz CPU.
• RAM. 16GB baseline, plus 2GB per OSD.
• Networking. 10 Gigabit Ethernet (GbE) per 12 OSDs (each for client- and cluster-facing
networks).
• OSD media. High-performance, high-endurance enterprise NVMe SSDs.
• OSDs. Four per NVMe SSD.
• Journal media. High-performance, high-endurance enterprise NVMe SSD, co-located with OSDs.
• Controller. Native PCIe bus.
74

75. H A R D WA R E R E CO M M E N DAT I O N S
THROUGHPUT-OPTIMIZED SOLUTIONS
Throughput-optimized Ceph solutions are usually centered around semi-structured or unstructured
data. Large-block sequential I/O is typical. Storage media on OSD hosts is commonly HDDs with
write journals on SSD-based volumes. Typical server elements include:
• CPU. 0.5 cores per HDD, assuming a 2 GHz CPU.
• RAM. 16GB baseline, plus 2GB per OSD.
• Networking. 10 Gigabit Ethernet (GbE) per 12 OSDs (each for client- and cluster-facing
networks).
• OSD media. 7,200 RPM enterprise HDDs.
• OSDs. One per HDD.
• Journal media. High-endurance, high-performance enterprise serial-attached SCSI (SAS) or
NVMe SSDs.
• OSD-to-journal ratio. 4-5:1 for an SSD journal, or 12-18:1 for an NVMe journal.
• Host bus adapter (HBA). just a bunch of disks (JBOD).
75

76. H A R D WA R E R E CO M M E N DAT I O N S
COST/CAPACITY-OPTIMIZED SOLUTIONS
Cost/capacity-optimized solutions typically focus on higher capacity, or longer archival
scenarios. Data can be either semi-structured or unstructured. Workloads include media
archives, big data analytics archives, and machine image backups. Large-block sequential I/
O is typical. For greater cost effectiveness, OSDs are usually hosted on HDDs with Ceph write
journals co-located on the HDDs. Solutions typically include the following elements:
• CPU. 0.5 cores per HDD, assuming a 2 GHz CPU.
• RAM. 16GB baseline, plus 2GB per OSD.
• Networking. 10 GbE per 12 OSDs (each for client- and cluster-facing networks).
• OSD media. 7,200 RPM enterprise HDDs.
• OSDs. One per HDD.
• Journal media. Co-located on the HDD.
• HBA. JBOD.
76

77. N E T WO R K I N G O P T I O N 1 :
P R OV I D E R N E T WO R K S
77

78. N E T WO R K I N G O P T I O N 2 :
S E L F-S E RV I C E N E T WO R K
78

79. N E T WO R K L AYO U T
• The example architectures assume use of the following networks:
• Managed on 10.0.0.0/24 with gateway 10.0.0.1
This network requires a gateway to provide Internet access to all nodes for administrative purposes such as
package installation, security updates, DNS, and NTP.
• Provider on 203.0.113.0/24 with gateway 203.0.113.1
This network requires a gateway to provide Internet access to all instances in your OpenStack environment.
79

80. S U B S C R I P T I O N

81. R E D H AT O P E N STAC K P L AT F O R M
O F F E R I N G S
Red Hat OpenStack Platform subscriptions come in two versions:
1. Red Hat OpenStack Platform
2. Red Hat OpenStack Platform (without guest operating system)
The only difference between the two is that the first version includes the right to
use Red Hat Enterprise Linux® as the guest operating system in an unlimited
number of virtual machines hosted by OpenStack. Both versions include the
ability to run Red Hat OpenStack Platform.
A Red Hat OpenStack Platform subscription allows you to install and run the
included software on a single server with up to two populated sockets. If the
server has more than two sockets, you can stack additional subscriptions on it
until the number of allowed sockets is equal or greater than the number of
populated sockets in the server.
81

82. A S S E M B L I N G YO U R S U B S C R I P T I O N
O R D E R
To determine the Red Hat OpenStack Platform subscription needed for each
server in a private cloud deployment, look at the role the server will perform.
The Red Hat OpenStack Platform deployment model includes two main
concepts: The undercloud and the overcloud.
82

83. U N D E R C LO U D
The undercloud installs, configures, and manages the overcloud.
Typically, a single server is assigned the role of being the
undercloud. The best practice is to install the following software
components in virtual machines on the undercloud server:
• Red Hat OpenStack Platform director
• Red Hat CloudForms
Since this server uses Red Hat OpenStack Platform and will run
virtual machines using Red Hat Enterprise Linux as the guest
operating system, a Red Hat OpenStack Platform subscription
should be purchased.
83

84. OV E R C LO U D
The overcloud has all the components needed to run your private
cloud. The servers that host the overcloud are usually assigned one of
the following three roles:
• Controller: Nodes that provide administration, networking, and high
availability for the OpenStack environment.
• Compute: Nodes that provide computing resources for the
OpenStack environment.
• Storage: Nodes that provide storage for the OpenStack
environment.
Each role has different subscription considerations
84

85. CO N T R O L L E R
For controller nodes, consider whether or not you will deploy
any virtual machines on this server. If you will not deploy any
virtual machines (the most likely use case), or if any virtual
machines you do deploy on this server will not use Red Hat
Enterprise Linux as the guest operating system, then you
should purchase Red Hat OpenStack Platform (without guest
OS) for that server.
If you will deploy virtual machines on the controller node and
you will use Red Hat Enterprise Linux as the guest operating
system in those virtual machines, then you should purchase
Red Hat OpenStack Platform for that server.
85

86. CO M P U T E
For compute nodes, consider whether or not you want to use
Red Hat Enterprise Linux as the guest operating system in any of
the virtual machines hosted on these servers. If you will use Red
Hat Enterprise Linux as the guest operating system, then you
should purchase Red Hat OpenStack Platform for that server.
If you will use another operating system, such as Windows, as
the guest operating system, or if you will use standalone Red Hat
Enterprise Linux Server or Red Hat Enterprise Linux for Virtual
Datacenters subscriptions for the guest operating system, you
should purchase Red Hat OpenStack Platform (without guest
OS) for that server.
86

87. STO R AG E
For storage nodes, consider what type of storage will be used:
• Ceph storage nodes: Purchase Red Hat Ceph Storage
subscriptions for these servers.
• Block storage (Cinder) nodes: Purchase Red Hat OpenStack
Platform (without guest operating system) subscriptions for
these servers.
• Object storage (Swift) nodes: Purchase Red Hat OpenStack
Platform (without guest operating system) subscriptions for
these servers.
87

88. R E D H AT C LO U D F O R M S
A version of Red Hat CloudForms is included with each Red Hat OpenStack
Platform subscription. It is intended to be used as the day-two cloud
management tool for Red Hat OpenStack Platform.
It includes the complete feature set of Red Hat’s standalone CloudForms
offering. However, it can only be used to manage virtual machines that are
hosted by Red Hat OpenStack Platform. It cannot be used with any other
virtualization platform.
As an example, take a server using Red Hat OpenStack Platform to create and
run virtual machines. The included Red Hat CloudForms can manage all the
virtual machines hosted on that server.
However, if the private cloud includes a mix of compute servers using Red Hat
OpenStack Platform, VMware vSphere, and virtual machines hosted on Amazon
EC2, the included Red Hat CloudForms subscription can only be used to
manage the virtual machines being hosted on Red Hat OpenStack Platform.
88

89. R E D H AT C E P H STO R AG E
Red Hat OpenStack Platform and Red Hat Cloud Infrastructure subscriptions
include enablement software that is needed to use Red Hat Ceph Storage with
Red Hat OpenStack Platform. This enablement software includes the installation,
management, and monitoring tools for Ceph.
However, Red Hat Ceph Storage software needed for the storage nodes is not
included. That software component is called Red Hat Ceph Storage object
storage daemon (OSD). It is the OSD for the Ceph distributed file system and is
responsible for storing objects on a local file system and providing access to them
over the network. This software component is only available in the Red Hat Ceph
Storage SKUs.
To expand your Red Hat Ceph Storage capability into production, you can buy
any Red Hat Ceph Storage subscription, which start at 256TB. For more
information about Red Hat’s Ceph Storage solutions, visit https://redhat.com/en/
technologies/storage/ceph.
89

90. L I F E - CYC L E O P T I O N S
With the release of Red Hat OpenStack Platform version 10, a change was made to the
life-cycle periods, based on feedback from customers. It balances the needs of customers
who want access to the latest OpenStack technology as soon as it becomes available and
those who want to standardize on one version for the longest possible period.
To meet those needs, the life cycle for Red Hat OpenStack Platform will no longer be
three years for every major new release. Instead, you can choose either a one-year
(standard) or three-year (long-life) life cycle. With the three-year long-life version, you will
also have the option to purchase extended life-cycle support (ELS) for up to two
additional years. The life-cycle periods for version 10 and beyond are:
• Version 10 (based on upstream OpenStack community version “Newton”) — three
years (with the option to purchase up to two additional years).
• Version 11 (based on upstream version “Ocata”) — one year.
• Version 12 (based on upstream “P” version) — one year.
• Version 13 (based on upstream “Q” version) — three years (with the option to
purchase up to two additional years).
90

91. Innovations Development Lab
https://indevlab.com
info@indevlab.com
T H A N K YO U F O R AT T E N T I O N !
Dmytro Hanzhelo
R E D H AT ACC R E D I T E D P R O F E S S I O N A L
R E D H AT S A L E S E N G I N E E R S P E C I A L I ST - C LO U D I N F R A ST R U C T U R E