Adam Heczko – TBD Topic of Presentation: Openstack, Ceph, SDN Language: Polish Abstract: TBD

1. OpenStack, CEPH, SDN
Adam Heczko

2. Adam.Heczko@qsa.pl – kilka słów o mnie
https://github.com/qsa-it-consulting/qsa-os-cluster-nn
 Urodzony w 1976 roku 
 Studiowałem na Politechnice Śląskiej, kier. Elektronika i Telekomunikacja, ostatecznie ukończyłem
Informatykę
 Pasjonat Linuxa od czasów kernela 1.2, pierwsza dystrybucja to „Slack”, potem głównie Debian
 Zawodowo głównie solutions architect (UML), security expert, network engineer, system engineer
 W tzw. „wolnych chwilach” programista Python/Ruby oraz DevOps engineer
 Zawodowo związany z Exorigo-Upos oraz własnym start-upemQSA
Projekty wykonane w ramach QSA:
 kilka wdrożeń OpenStack (1 PL, 2 EU), kilka wdrożeń vSphere (PL), kilka wdrożeń SCVMM (PL)
 doradztwo w zakresie technicznego i organizacyjnego bezpieczeństwa informacji, projekty
architektury, analizy ryzyka, obsługa incydentów, skany podatności, testy penetracyjne, ethical
hacking itp.
Projekty planowane:
 Uruchomienie chmury publicznej OpenStack dla klientów polskich IXow (np. EPIX, K-IX itd.)
 Uruchomienie kilku kolejnych chmur OpenStack 
2

3. Krótki słowniczek „cloudowy”
3
Nazwa Znaczenie
Chmura
publiczna
Chmura udostępniona publicznie, gdzie za opłatą wnoszoną do operatora chmury, można
uruchamiać własne workloady
Chmura prywatna
(dedykowana)
Chmura służąca do uruchamiania workloadów wyłącznie swojego właściciela i najczęściej przez
niego zarządzana
Chmura
hybrydowa
Chmura łącząca cechy zarówno chmury publicznej jak i dedykowanej, umożliwiająca wykonanie
operacji typu np. Cloud Bursting
Cloud Bursting Możliwość elastycznego przenoszenia workloadów z chmury prywatnej do chmury publicznej,
możliwość dokładania własnych workloadów do „zaprzyjaźnionej” chmury publicznej z poziomu
własnego „panelu”
SDN, Network
Virtualization,
Network
Overlaying
Możliwość „abstrakcji” sieci widzianych z punktu widzenia maszyn wirtualnych, rozdzielenie
funkcjonalności sieci fizycznej od tej „wirtualnej” zdefiniowanej w „panelu” chmury
Tenant, Project Grupa użytkowników, sieci wirtualnych, maszyn wirtualnych, woluminów itp. mających dostęp do
wspólnych zasobów
Workload,
Instancja
Najczęściej maszyna wirtualna (VM), ale może być to również usługa działająca w kontenerze, np.
Trove

4. OpenStack a inne frameworki „cloudowe” – krótkie porównanie
4
Product /
Framework
OpenStack CloudStack
VMware vCloud
Suite
Microsoft
SCVMM
Licence Apache 2.0 Apache 2.0 Proprietary Proprietary
Primary
hypervisor
KVM Xen ESXI Hyper-V
Secondary
hypervisors
Xen, Hyper-V,
vSphere, LXC
KVM, Hyper-V,
vSphere, LXC
- -
Primary language Python Java Mix of Mix of
Primary storage
type
Cluster: CEPH,
GlusterFS
SAN: iSCSI, NFS
SAN: iSCSI, NFS SAN: iSCSI, NFS,
FC, FCoE
Cluster: vSAN
SAN: iSCSI, FC,
FCoE
Cluster: SMB 3.0
Network
Virtualization
Open vSwitch,
Vmware NSX,
Arista EOS, Cisco
Nexus, Brocade ,
HP, Mellanox, NEC
OpenFlow Plugin,
OpenDaylight
Open vSwitch Vmware NSX,
Arista EOS, Cisco
Nexus, Brocade ,
HP
NVGRE virtual
switch
Multi-tenant, Self
Service Portal
Yes, Horizon Yes Yes Yes, Self-Service
Portal/SCVMM
Hybrid Cloud
solutions
RackConnect
allows migrate to
RackSpace
Citrix
CloudPlatform
allows migration
between clouds
vCloud Connector SCVMM allows
migrate to Azure
Cost of
implementation
Free, add
consultancy and
integration fee
Free, add
consultancy and
integration fee

5. OpenStack – co to jest i dlaczego
warto zwrócić na to uwagę
 Oprogramowanie Open Source na licencji Apache 2.0
 Projekt utworzony przez NASA i RackSpace w 2010 roku
 Ma na celu budowę skalowalnej chmury obliczeniowej
 OS używany jest do zarządzania chmurą przez: AT&T, CERN, Cisco, Rackspace, HP, Ebay,
PayPal, DreamHost, DigitalOcean, Intel, Sony itd.
Kluczowe wyróżniki OS:
 Ogromna „społeczność” aktywnych developerów, testerów, użytkowników
 Szybki postęp / development
 Przewidywalny cykl kolejnych wydań, 2 razy w roku
 Najbardziej znaczący projekt chmurowy na licencji Open Source
 Architektura warstwowa, gdzie najważniejszym elementem jest API. Na bazie API i wywołań
REST (http/https) działa cała ta „maszyneria”
 Pomimo kilku wad (złożoność, niedoróbki tu i tam), technicznie dojrzały i umożliwiający
budowanie skalowalnej i niezawodnej chmury (NO SPOF)
5

6. OpenStack – najważniejsze elementy układanki
6
Nazwa Znaczenie
Cloud controller Najważniejszy element układanki w chmurze OpenStack, serwer fizyczny bądź maszyna wirtualna który jest
serwerem API i de facto zarządza chmurą
Nova Usługa + API zarządzające Hypervisorami. Np. Nova Compute Host = serwer z zainstalowanymi pakietami
nova-compute-kvm , qemu-kvm
Glance Usługa + API OS, odpowiedzialne za zarządzanie „obrazami” z których można uruchomić „workload”, czyli
najczęściej maszynę wirtualną. Z usługą Glance najczęściej komunikują się usługi Nova (pobiera obraz do
uruchomienia), Cinder (klonuje obraz do wolumenu)
Cinder Usługa + API OS, który zarządza urządzeniami „blokowymi” czyli woluminami (dyskami wirtualnymi). Cinder
udostęnia składnikom „Nova” i „Glance” spójne API, niezależnie od typu użytego faktycznie storage’u: NFS,
iSCSI, Ceph, GlusterFS, ZFS/Nexenta, Netapp itd.
Swift Usługa + API OS służąca do przechowywania danych typu „Object Store”. Zwykle to Glance składuje w
storage Swift’a obrazy. W przypadku zastosowania uniwersalnego, klastrowego systemu plików (Ceph),
można zastąpić usługę „Swift” właśnie Ceph’em.
Keystone Usługa + API OS będąca swego rodzaju „Active Directory” OpenStack’a. Kataloguje usługi (service
endpoints), projekty (projects, tenants), użytkowników, role. Zarządza uwierzytelnienem (auth - tokenami)
Neutron Usługa + API OS która zarządza sieciami wirtualnymi w warstwie 2 i 3. W uproszczeniu , jest to składnik
„SDN” OpenStack’a. Dla składnika „Nova” udostępnia spójne API, niezależnie od techniki użytej „pod
spodem”. Typowe „pluginy” L2 dla Neutrona to: Open vSwitch, Arista, Cisco, Mellanox, Brocade,
Linuxbridge. Niektóre pluginy umożliwiają wybór podtypów sieci fizycznej: Flat, VLAN, GRE, VXLAN itd.
Neutron udostępnia również usługi L3, najczęściej realizowane software’owo na bazie Linuxa.
Najpopularniejsze usługi: DHCP Agent, VPN Agent, L3 Agent (L3 router, NAT)
Horizon Portal WWW OpenStack’a, gdzie użytkownicy chmury mogą definiować sieci, maszyny wirtualne
(workloady). Przez Horizon’a można się również zalogować do konsoli graficznej uruchomionej w OS
maszyny wirtualnej.
Ceilometer System bilingowy OS, a w zasadzie API REST które udostępnia liczniki zużycia zasobów przez
poszczególnych uczestników chmury.

7. Architektura OpenStack’a – omówienie głównych
składników
7

8. Gdzie podział się CD-ROM? – czyli krótko o „cloud-init” i
DevOps
W przeciwieństwie do tradycyjnych rozwiązań wirtualizacji (Proxmox, Xen Server, oVirt,
ESXI), w rozwiązaniach cloudowych nie istnieje pojęcie „instalacji”. W typowym centrum
danych, gdzie uruchomiono kilkaset (tysięcy) maszyn wirtualnych, nikt nie ma czasu na
instalację „z palca”. Podobnie jest w OpenStack, gdzie próżno szukać napędu CD-ROM.
Pojęcie „instalacja” zastąpiona „VM Bootstrap”, i to podczas bootstrapu maszyny są do niej
„injektowane” parametry startowe, zgodnie z życzeniem użytkownika.
Przykładowy skrypt wykonywany podczas bootstrapu instancji:
8

9. Gdzie podział się CD-ROM? – czyli krótko o DevOps
Kolejną ewolucją napędu „CD-ROM” i „cloud-init” są narzędzia typu „configuration
management”. W środowisku „Cloud” często zwykło się posługiwać narzędziemi typu Chef,
Puppet, Ansible, Salt, Juju itd. Da facto samą instalację OpenStack’a często wykonuje się za
pomocą narzędzi Chef bądź Puppet. Jest to przydatne zwłaszcza w instalacjach większych, gdzie
do skonfigurowania jest np. 150 serwerów, a każdy z nich przygotowuje się wg podobnej
„receptury”. Zarządzanie instalacją i konfiguracją serwerów za pomocą narzędzi programowych
nazywa się właśnie „Development Operations”, w skrócie DevOps.
9

10. Storage OpenStack’a, czyli podstawa każdej chmury
10

11. Storage dla OpenStack’a:
Ceph to w stosunku do „Open Stack” projekt zewnętrzny. Ze storage’u oferowanego przez Ceph korzystają następujące usługi OpenStack:
 Glance (image store dla Nova/KVM)
 Cinder (block/volume storage dla Nova/KVM)
 Swift (REST object storage)
Ceph jest klastrowym, wysoce skalowalnym systemem plików który „szturmem” zdobywa zwolenników wśród „stackerów”.
Podstawowe cechy CEPH:
 Open Source, z możliwością wykupienia komercyjnego supportu
 Rozwiązanie w 100% software’owe, działa na zwykłych serwerach x86
 Typu „scale out”, tzn. gdzie zwiększenie i wydajności pojemności odbywa się poprzez dodawanie kolejnych serwerów do klastra
 „Samo naprawialne” – posiada własne „monitory” które monitorują pracę klastra i zapewniają dostępność storage’u
 NO SPOF – rozwiązanie klastrowe
 Umożliwia sterowanie poziomami replikacji, można np. zwiększyć poziom repliki do 3 dla wybranej puli (czyt. „woluminu”)
 Eliminuje potrzebę RAIDa , LUNów, przełączników FC i innych zmor „data center”
 Dostarcza podstawowe dla działania „chmury” sposoby dostępu do storage’u: Object (S3/Rest), Block (woluminy dla KVM/Xen), Filesystem (sieciowy system
11
plików)
 Dostarcza wszelkich potrzebnych funkcjonalności „enterprise” typu snapshot, clone, copy on write, thin provision, storage tiering, cache tiering itp.

12. Sieć typu SDN dla OpenStack’a: Neutron
12
Neutron to API/usługa OpenStack’a dostarczająca łączność dla maszyn wirtualnych i ich „vNIC”. Neutron „wirtualizuje”
sieć w podobny sposób do tego, w jaki „Nova” wirtualizuje serwery, czyli zapewnia dedykowaną dla vNIC łączność,
niezależnie od architektury sieciowej będącej „pod spodem”.
Kluczowe wyróżniki:
 Pełna kontrola software’owa nad wirtualnymi połączeniami sieciowymi,
 Bezpieczeństwo i pełna izolacja sieci pomiędzy projektami,
 Technologicznie uniwersalny: definiuje API, do którego vendorzy dostarczają implementacji,
 Implementacja referencyjna to Open vSwitch + OSS dostępne na Linuxie,
 Część funkcjonalności eksperymentalna
Neutron dostarcza usługi takie jak:
 Serwer DHCP (neutron-dhcp-agent), dnsmasq,
 L3 router z NAT (neutron-ovs-dvr) , implementacja referencyjna to Linux kernel + iptables,
 Firewall (neutron-fwaas-agent), implementacja referencyjna to Linux kernel + iptables,
 Load Balancer (neutron-lbaas-agent), implementacja referencyjna to HAProxy,
 VPN (neutron-vpn-agent), implementacja referencyjna to Openswan
Neutron jest wysoce modularny, i jest wiele „pluginów” vendorów, zapewniające różne funkcjonalności L2/L3.

13. Sieć typu SDN dla OpenStack’a: Neutron
13

14. Minimalna, ale w pełni odporna na awarię architektura
OpenStack’a
14

15. Monitorowanie OpenStack’a
Poprawność działania chmury należy sprawdzać w kilku warstwach:
 Warstwa sprzętu – monitorowanie poprzez IPMI/SNMP stanu hostów, temperatury, błędów na portach przełączników
15
i inne monitoringi
 Monitorowanie HDD
 Baza danych MySQL – monitorowanie wydajności, hostów MySQL, „slow log” itp.
 W przypadku użycia Galery, monitorowanie stanu klastra
 Monitorowanie RabbitMQ, w przypadku konfiguracji HA, monitorowanie stanu klastra Rabbit
 Monitorowanie API OpenStack: centralny Syslog + Logwatch, a w większych instalacjach Logstash + Kibana, Splunk
itp.
 Monitorowanie bezpieczeństwa, np. liczby nieudanych prób dostępu do Horizon’a
 Monitorowanie wydajności chmury i trendów w zużyciu zasobów: Ceph, Ceilometer
System bilingowy: Ceilometer, REST API z którego łatwo „wyciągnąć” dane o zużyciu zasobów globalnym jak i dla
pojedynczych projektów/agregatów hostów.

16. OpenStack: segregacja, „chmura w modelu usługowym” i przykłady
możliwego użycia
16
Operator chmury może udostępniać jej zasoby na kilka różnych sposobów.
 Standardowy sposób udostępniania zasobów polega na tworzeniu dla kolejnych klientów dedykowanych projektów
(projects, tenants). W ramach jednego projektu istnieje wielu użytkowników, o uprawnieniach „admin” bądź
„member”.
Użytkownicy projektu łączą się do portalu OpenStack pod adres https://chmura.operator1.pl/mójprojekt/
 Można również wydzielić część infrastruktury i dedykować ją danemu klientowi. Jest to swego rodzaju rozwiązanie
„Cloud As A Service”, czyli chmury w modelu usługowym. Użytkownik loguje się wtedy do chmury operatora np. po
nazwie https://chmura.mojafirma.pl/ i korzysta z dedykowanych, wydzielonych przez operatora serwerów (compute).
Reszta infrastruktury (keystone, kontroler chmury, serwery storage, networking) jest nadal wspólna dla wszystkich
użytkowników chmury.
Naturalnymi dostawcami usług „IaaS” oraz „CaaS” są operatorzy posiadający dobre relacje z klientami i dysponujący
wydajną siecią teletransmisyjną FTTH.
To wszystko, dziękuję i życzę wszystkim powodzenia w przygodzie z własną chmurą 
Zapraszam do współpracy, Adam.Heczko@qsa.pl