OpenStack, CEPH, SDN
Adam Heczko
Adam.Heczko@qsa.pl – kilka słów o mnie
https://github.com/qsa-it-consulting/qsa-os-cluster-nn
 Urodzony w 1976 roku 
...
Krótki słowniczek „cloudowy”
3
Nazwa Znaczenie
Chmura
publiczna
Chmura udostępniona publicznie, gdzie za opłatą wnosz...
OpenStack a inne frameworki „cloudowe” – krótkie porównanie
4
Product /
Framework
OpenStack CloudStack
VMware vCloud ...
OpenStack – co to jest i dlaczego
warto zwrócić na to uwagę
 Oprogramowanie Open Source na licencji Apache 2.0
 Proje...
OpenStack – najważniejsze elementy układanki
6
Nazwa Znaczenie
Cloud controller Najważniejszy element układanki w chmur...
Architektura OpenStack’a – omówienie głównych
składników
7
Gdzie podział się CD-ROM? – czyli krótko o „cloud-init” i
DevOps
W przeciwieństwie do tradycyjnych rozwiązań wirtualizac...
Gdzie podział się CD-ROM? – czyli krótko o DevOps
Kolejną ewolucją napędu „CD-ROM” i „cloud-init” są narzędzia typu „conf...
Storage OpenStack’a, czyli podstawa każdej chmury
10
Storage dla OpenStack’a:
Ceph to w stosunku do „Open Stack” projekt zewnętrzny. Ze storage’u oferowanego przez Ceph korzy...
Sieć typu SDN dla OpenStack’a: Neutron
12
Neutron to API/usługa OpenStack’a dostarczająca łączność dla maszyn wirtualnyc...
Sieć typu SDN dla OpenStack’a: Neutron
13
Minimalna, ale w pełni odporna na awarię architektura
OpenStack’a
14
Monitorowanie OpenStack’a
Poprawność działania chmury należy sprawdzać w kilku warstwach:
 Warstwa sprzętu – monitorowa...
OpenStack: segregacja, „chmura w modelu usługowym” i przykłady
możliwego użycia
16
Operator chmury może udostępniać jej...
of 16

PLNOG 13: Adam Heczko: Openstack, Ceph, SDN

Adam Heczko – TBD Topic of Presentation: Openstack, Ceph, SDN Language: Polish Abstract: TBD
Published on: Mar 4, 2016
Published in: Internet      
Source: www.slideshare.net


Transcripts - PLNOG 13: Adam Heczko: Openstack, Ceph, SDN

  • 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

Related Documents