Upload
wsi
View
2
Download
0
Embed Size (px)
Citation preview
[email protected] – 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-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 kilku kolejnych chmur OpenStack
2
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
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
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
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.
Gdzie podział się CD-ROM? – czyli krótko o „cloud-init” i DevOps
8
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:
Gdzie podział się CD-ROM? – czyli krótko o DevOps
9
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 dla OpenStack’a:
11
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
W praktyce, w większych klastrach cały czas zdarzają się awaria dysków/całych serwerów, a CEPH cały czas się „rebalansuje”, rolą operatora klastra jest stopniowa wymiana uszkodzonych elementów i „podłączanie” do klastra sprawnych w celu zapewnienia oczekiwanej pojemności i wydajności
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
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,
W warstwie L2 /L2.5 najczęściej „Flat”, VLAN, VXLAN, na które nakładany jest „SDN”owy overlay, w implementacji referencyjnej jest to Open vSwitch + pluginy L3: DHCP/DNS, L3 router, fwaas, lbaas, vpnaas
Część funkcjonalności oznaczona jako eksperymentalna, ale dająca się używać
Neutron dostarcza usługi takie jak:
Serwer DHCP/DNS (neutron-dhcp-agent), implementacja referencyjna to 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
13
W warstwie 2 Neutron może korzystać z różnych typów sieci jednocześnie. Zakładając użycie typowych przełączników L2/L3, i zakładając że nie przekroczymy w naszej instalacji OpenStack’a maksymalnej liczby VLANów 4096, zwykle używa się typu sieci „vlan”. Na zdefiniowane na przełącznikach sieci fizyczne „vlan” nakłada się „SDN”-owe sieci IPv4/IPv6 , L3 routery i usługi dodatkowe (fwaas, lbaas itd.).
W większych instalacjach OpenStack, gdzie limit 4096 vlanów (sieci wirtualnych dla projektów) w domenie L2 jest zbyt mały, najczęściej stosuje się:
1. Wielokrotne definicje „physnet”, opisujące oddzielne domeny L2 i przyporządkowane im porty kart Ethernet,
2. Przełączniki SDN’owe z obsługą VXLAN
Karta 4-portowa umożliwiająca automatyczne, tanie skalowanie Data Center do 16 000 sieci wirtualnych.
Schemat blokowy API/usługi Neutron
Monitorowanie OpenStack’a
16
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 i systemów plików
Baza danych MySQL – monitorowanie liczników wydajności bazy i hostów MySQL, „slow log” itp.
W przypadku użycia Galery, monitorowanie stanu klastra SQL (show status where variable_name like 'wsrep_%';)
Monitorowanie RabbitMQ, w przypadku konfiguracji HA, monitorowanie stanu klastra Rabbit
Monitorowanie API OpenStack: własne skrypty które „wyciągają” coś korzystając z API i sprawdzają, czy odpowiedź jest zgodna z oczekiwaniami
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
17
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, [email protected]