OpenStack, CEPH, SDN

Adam Heczko

Adam.Heczko@qsa.pl – kilka słów o mniehttps://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-upem QSA

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

Krótki słowniczek „cloudowy”

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

OpenStack a inne frameworki „cloudowe” – krótkie porównanie

Product / Framework

OpenStack CloudStackVMware

vCloud SuiteMicrosoft 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, GlusterFSSAN: iSCSI, NFS

SAN: iSCSI, NFS

SAN: iSCSI, NFS, FC, FCoECluster: vSAN

SAN: iSCSI, FC, FCoECluster: 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

OpenStack – co to jest i dlaczegowarto 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)

OpenStack – najważniejsze elementy układanki

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.

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

Gdzie podział się CD-ROM? – czyli krótko o „cloud-init” i DevOpsW 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:

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.

Storage OpenStack’a, czyli podstawa każdej chmury

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 plików) Dostarcza wszelkich potrzebnych funkcjonalności „enterprise” typu snapshot, clone, copy on write, thin provision, storage

tiering, cache tiering itp.

Sieć typu SDN dla OpenStack’a: Neutron

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.

Sieć typu SDN dla OpenStack’a: Neutron

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

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 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.

OpenStack: segregacja, „chmura w modelu usługowym” i przykłady możliwego użycia

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