The document discusses OpenStack infrastructure architecture and compares OpenStack to VMware and KVM virtualization platforms. It outlines the logical and physical architecture of OpenStack, including the roles of key components like Nova, Swift, Glance, Cinder, Neutron and Keystone. It then compares the architectures of KVM and VMware and analyzes some advantages of KVM like lower costs. Finally, it presents the physical architecture and deployment of an OpenStack system.

1. KIẾN TRÚC HẠ TẦNG
OPENSTACK
Người thực hiện: Phan Anh Sơn

2. Nội dung
• Kiến trúc hạ tầng, cách thức liên lạc, kết nối giữa các
component.
• Nghiên cứu về cấu trúc và đưa ra so sánh giữa hai nền tảng
ảo hóa là KVM và VMWare

3. Mục tiêu
• Đưa ra các bước cơ bản để triển khai thành công một hệ
thống Openstack đơn giản
• Thực hiện một buổi báo cáo chi tiết về nhiệm vụ của mình

4. Conceptual Architecture

5. Logical Architecture

7. Identity (“Keystone”)
• Keystone provides a single point
of integration for OpenStack
policy, catalog, token and
authentication.
• keystone handles API requests as
well as providing configurable
catalog, policy, token and identity
services.
• Most people will use this as a
point of customization for their
current authentication services.

8. Dashboard (“Horizon”)
• Django application that users can
access in their web browser
• Communicates with each
OpenStack service through their
API (and sometimes their admin
API)

9. Object Storage (“Swift”)
• Stores and serves objects (files)
• Employs object level replication
to safeguard data
• Accepts client requests via
Objectstore API or HTTP from
clients through swift-proxy
• Maintains distributed account and
container databases

10. Image Service (“Glance”)
•glance-api accepts Image API
calls for image discovery, image
retrieval and image storage.
•glance-registry stores, processes
and retrieves metadata about
images (size, type, etc.).
•Database to store the image
metadata.

11. Compute (“Nova”)
• nova-api accepts and responds to
end user compute API calls.
• Supports OpenStack Compute
API, Amazon's EC2 API and a
special Admin API (for
privileged users to perform
administrative actions).
• Initiates most of the orchestration
activities (such as running an
instance)
• Enforces some policy (mostly
quota checks)
• Authentication is handled through
middleware before getting to this
daemon

12. Nova Compute
• The nova-compute process is
primarily a worker daemon that
creates and terminates virtual
machine instances via
hypervisor's APIs
• The process by which it does so is
fairly complex but the basics are
simple: accept actions from the
queue and then perform a series
of system commands (like
launching a KVM instance) to
carry them out while updating
state in the database.

13. Nova Compute

14. Nova Scheduler
• The nova-schedule process is conceptually the simplest piece of code in
OpenStack Nova: take a virtual machine instance request from the queue
and determines where it should run (specifically, which compute server
host it should run on).

15. Nova Scheduler
def _schedule(self, context, topic, request_spec, filter_properties):
"""Picks a host that is up at random."""
elevated = context.elevated()
hosts = self.hosts_up(elevated, topic)
if not hosts:
msg = _("Is the appropriate service running?")
raise exception.NoValidHost(reason=msg)
hosts = self._filter_hosts(request_spec, hosts, filter_properties)
if not hosts:
msg = _("Could not find another compute")
raise exception.NoValidHost(reason=msg)
return hosts[int(random.random() * len(hosts))]

16. Block Storage (“Cinder”)
• cinder-api accepts API requests and
routes them to cinder-volume for
action.
• cinder-volume acts upon the requests
by reading or writing to the Cinder
database to maintain state, interacting
with other processes (like cinder-
scheduler) through a message queue
and directly upon block storage
providing hardware or software..
• Much like nova-scheduler, the cinder-
scheduler daemon picks the optimal
block storage provider node to create
the volume on.

17. Networking (“Quantum”)
• quantum-server accepts API
requests and then routes them to
the appropriate quantum plugin
for action.
• Quantum ships with plugins and
agents for:
• Cisco virtual and physical
switches
• Nicira NVP product
• NEC OpenFlow products
• Open vSwitch
• Linux bridging
• Ryu Network Operating
System
• Midokua

19. Comparing VMware and KVM

20. KVM architecture

21. KVM architecture
• When using KVM, guests run as a Linux process on the host.
• Virtual CPUs (vCPUs) are implemented as normal threads, handled by
the Linux scheduler.
• Guests inherit features such as NUMA and Huge Pages from the kernel.
• Disk and network I/O settings in the host have a significant performance
impact.
• Network traffic typically travels through a software-based bridge.

22. VMware architecture

23. VMware architecture(cont)

24. VMware architecture(cont)

25. Comparing VMware and KVM
• VMware and KVM both offer similar functionality when it comes to
performing the functions required by most IT managers (the ability to
build, deploy, and manage virtual machines)
• KVM can cost up-to 40% less to implement and operate as compared
with VMware.

26. Comparing VMware and KVM
• Background
•EMC’s VMware is the x86 market share leader when it comes to
virtualization and related infrastructure and management (1998).
•KVM (which stands for kernel -based virtual machine) is an open
source implementation of virtualization (it leverages the Linux
kernel)
•KVM was released as part of Linux 2.6.20 (in February, 2007)

27. Comparing VMware and Openstack

28. Comparing VMware and Openstack

29. Comparing VMware and Openstack

30. Comparing VMware and Openstack

31. OpenStack Deployment

32. Architecture: Components

33. Physical architecture
Compute Nodes
Provides virtual servers upon demand
-> Compute: Nova

34. Physical architecture
Storage Node
● Provides object storage.
It allows to store or retrieve
files
→ Object storage : “Swift”
● Provides persistent block
storage to guest Vms.
→ Block storage : “Cinder”

35. Physical architecture
Controller Node

36. Physical architecture
Network Node
● Provides a modular WebUI
for all the OpenStack services.
→ Dashboard : "Horizon"
● Provides authentication and
authorization for all the OpenStack
services.
→ Identity : "Keystone"
● Provides a catalog and repository
for virtual disk images.
● → Image : "Glance"

37. Physical architectureNetwork Node
● Provides "network connectivity as a service"

38. Physical architecture
Multinode architecture

39. Architecture for SYS

40. Conclusions
● Performance for SYS: Maximum
● The problem that need to solves about connecting inside
each component
○ Database
○ Cache
○ Storage
○ Configuration

41. THANK YOU !