Petabajty z kosmosu (serio)

1. Petabajty z kosmosu (serio)
powered by
Alek Cesarz, Piotr Misiak

2. Co robimy
Rozwiązania chmurowe
Chmury publiczne – bezpieczne, skalowalne, łatwo zarządzalne (API)
Chmury prywatne – bezpieczne, na dedykowanych zasobach, instalowane u użytkownika,
integrowane z lokalnymi systemami i zasobami
Chmury hybrydowe – wykorzystanie chmur publicznych do rozszerzenia możliwości własnej
infrastruktury
Wykorzystywane najlepsze otwarte projekty
OpenStack
Ceph
Unikalne możliwości
Integracja infrastruktury wirtualnej i fizycznej
Dedykowane zwirtualizowane serwery (lokalne dyski, GPU)
Szeroki zestaw usług dodanych
Kluczowe projekty
EO Cloud (EO Innovation Platform Testbed) dla ESA
CDS Hybrid Cloud dla ECMWF
CREODIAS dla ESA/EC

3. Projekt COPERNICUS
Sentinel-1 A/B – od 2014
C-SAR – Synthetic Aperture Radar
obrazowanie ukształtowania powierzchni ziemi
Sentinel-2 A/B – od 2015
MSI – Multi-Spectral Instrument
pomiary w 12 zakresach od 442,3nm do 2202,4nm
Sentinel-3 – od 2016
SLSTR (Sea and Land Surface Temperature Radiometer) SRAL (SAR Altimeter)
OLCI (Ocean and Land Colour Instrument) MWR (Microwave Radiometer)
obserwacja powierzchni wód morskich, śródlądowych i lodowców
Sentinel-5 Precursor – od 2017
TROPOspheric Monitoring Instrument
wielozakresowa (UV, VIS, NIR, SWIR) obserwacja atmosfery

4. I nie tylko COPERNICUS
4

5. Obserwacja zmian
5
Algi w Dnieprze
Most na Wiśle

6. Co z tego wynika
6
• Ogromne ilości danych - dziesiątki, a wkrótce setki TB dziennie
• Rozproszenie źródeł
• Przetwarzanie maszynowe
• Dostęp publiczny do danych programu Copernicus
• Rozpędzenie pomysłów na wykorzystanie danych
11,259,604 produktów
9,173 TB danych
3,118,277,982 obiektów 0
10
20
30
EO data (in PB)
7.5
13
19
25
2018 2019 2020 2021

7. CREODIAS
7

8. Polska
Francja
Słowenia
Creotech
Instrume
nts
WIZIPISI
CloudFer
ro
Eversis
Sinergis
e
Geomatys
CREODIAS

9. 9

10. 10

11. Storage – dobre złego, a może złe dobrego początki
11
Żródło: Giacinto Donvito et al 2014 J. Phys.: Conf. Ser. 513 042014
„Write once – read many” – czy na pewno?
Ceph – wolny i nie do końca stabilny
HDFS – wolny i zasobożerny
GlusterFS – idealne rozwiązanie?
ZFS, kompresja, replikacja, rebalancing, RedHat…

12. Storage – pierwsze problemy
12
20TB dziennie w normalnej pracy, 50TB przy uzupełnianiu danych
1 węzeł storage na 3 dni!

13. Storage – pierwsze problemy
13
200 MBps

14. Storage – pierwsze problemy
14

15. Storage – pierwsze problemy
15
200 MBps
N x 200 MBps! + nadmiarowość + metadane

16. Storage
16
Lessons learned:
- „write once – read many” nie jest do końca prawdą
- „odporność” systemu na rozbudowy jest krytyczna
- ograniczenia HW pokazują się nie tam gdzie się ich spodziewamy
- zabezpieczenie danych niekoniecznie musi być realizowane na poziomie FS
Na szczęście Ceph „dojrzał” ((-:

17. Jak to robimy teraz?
17

18. Komponenty Open Source
18
Linux
nasz podstawowy, ukochany, jedyny system operacyjny
OpenStack
serwery, sieci, storage na wzór AWS
Ceph
storage blokowy dla OpenStacka oraz obiektowy dla danych satelitarnych
Midonet
sieć dla OpenStacka, plugin do Neutrona
Ansible
narzędzie do zarządzania całą infrastrukturą
Cumulus Linux
system operacyjny na switchach, nie do końca taki open ;)

19.  Ubuntu LTS, aktualnie 16.04
 Automatyczna instalacja i konfiguracja systemu przy użyciu Cobblera i
Ansible
 Monitoring za pomocą Zabbixa
 Centralne składowisko logów
 Centralne zarządzanie dostępami
Linux w CloudFerro

20.  Jeden z największych projektów Open Source na świecie, projekt wspierają wszystkie
liczące się firmy w branży, bardzo duże community
 Umożliwia zbudowanie chmury prywatnej albo publicznej na wzór AWS
 Wirtualne serwery, kontenery, wirtualne sieci, wirtualny storage
 Bardzo szybki rozwój - wydania wersji co pół roku
 Składa się z wielu oddzielnych modułów/projektów, każdy z nich odpowiada za
konkretny obszar, komunikacja między modułami i z użytkownikiem via REST API
 Nieskończona ilość konfiguracji, sposobów deploymentu, integracji
OpenStack

21.  Vaniliowa wersja Mitaka i Pike z kilkoma drobnymi patchami
 Instalacja i konfiguracja za pomocą projektu OpenStack Kolla
 Każdy serwis OpenStacka jest w dedykowanym kontenerze Dockera
 Używane moduły: Keystone, Nova, Glance, Neutron, Cinder, Horizon, Ceilometer
 Midonet jako plugin do Neutrona
 Instalacje z 50+ compute nodów
 Billing klientów oraz jego integracja z OpenStack jest naszym autorskim
rozwiązaniem
OpenStack w CloudFerro

22.  Tylko fernet tokens w Keystonie
 Wszystkie serwisy OpenStacka są bardzo wrażliwe na komunikację z
RabbitMQ
 Multitenacy jest problematyczne – domeny, projekty
 Uwaga na aktualizacje – potrafią wprowadzić nowe bugi
 Najlepiej być jeden albo dwa wydania w tyle
OpenStack tips & tricks

23.  Osobna instalacja na potrzeby OpenStacka:
 storage blokowy i obiektowy
 kilkanaście serwerów per OpenStack
 dwa typy dysków SSD i HDD
 Osobna instalacja dla danych satelitarnych:
 w tej chwili 9PB danych netto
 erasure coding
 dostęp obiektowy
 2200+ dysków
 mamy swojego forka kodu z własnymi modyfikacjami
Ceph w CloudFerro

24.  Zalecana najnowsza i spójna wersja
 Uwaga na operacje snaptrim i scrub
 Trzeba mieć backfilling pod kontrolą
 Uwaga na ilość miejsca na dysku na serwerach z ceph-mon :)
 Microbursts
 Stan WARNING I ERROR to nie koniec świata, jeżeli się
dokładnie rozumie co się dzieje w klastrze
Ceph tips & tricks

25.  instalacja/konfiguracja systemu operacyjnego - nasze playbooki
 instalacja/konfiguracja OpenStack - Openstack Kolla
 instalacja/konfiguracja Ceph – ceph-ansible
 instalacja/konfiguracja switchy/sieci - nasze playbooki,
korzystamy z modułu nclu
 brakuje modułów do fizycznej instalacji urządzeń w szafach :/
Ansible everything!

26.  Projekt Neutron odpowiada za konfigurację sieci wirtualnych w projektach
 Modułowa architektura, praktycznie do każdej funkcji da się podpiąć plugin, których jest cała
masa pluginów Open Source oraz od różnych vendorów – Cisco, Juniper, etc.
 Zapewnia komunikację dla VMek i kontenerów: zwykłe sieci L2, routing L3, VPNaaS, FwaaS,
LBaaS, peering BPG, etc.
 SDN: OpenContrail, OpenDaylight, Midonet, Calico, etc.
 Pełna separacja sieci użytkowników
 Użytkownicy mają pełną kontrolę nad wirtualnymi sieciami, routerami, etc.
OpenStack networking

27. Vanilla OpenStack networking

28.  problemy z programowaniem OpenVswitch – np. nie działają konkretne ścieżki, VMka nie
może pobrać IP z DHCP
 problemy z masowym deploymentem Vmek – przy provisioningu 100 VMek na raz kilka
czasami nie dostaje adresu IP
 L3-HA - proces keepalived per Virtual Router – setki, tysiące procesów, powodował m.in.
bałagan w sieci w połączeniu z bugami Cumulus Linux
 mimo DVR ruch z VMek bez FloatingIP nadal przechodzi przez Network Node – oczywisty
bottleneck
Vanilla OpenStack networking

29. Midonet w OpenStack

30. Midonet w OpenStack

31. Sieć w CloudFerro

32. Sieć w CloudFerro

33. Broadcom Trident II Mellanox Spectrum
Mellanox
SN2410
Mellanox
SN2700
Sprzęt sieciowy

34. Cumulus Linux (2.5 → 3.7)

35. Cumulus Linux
w praktyce

36. General issues/bugs/f**ckups:
 kernel panic na jednym switchu (bo był uszkodzony) - 30 sek network downtime
 VxLAN VTEP - integracja z Midonet - SPOF, cieknąca pamięć - konieczne restarty raz na dobę
 jak jest skonfigurany CLAG/MLAG to nie można podnieść sieci na jednym switchu
 jeden serwer zabił nam sieć bo uszkodzona karta wysyłała non stop ramki pauzujące
 po reloadzie konfiguracji niepoprawne MTU na interfejsach
 podczas aplikowania konfiguracji zrestartował się jeden switch i za chwilę drugi :)
 nazwa interfejsu dłuższa niż 15 znaków - stan nieustalony, trzeba restartować proces CLAGd albo switcha
Cumulus Linux w praktyce

37. EVPN issues/bugs/f**ckups:
HyperLoops: problemy z przenoszeniem serwerów między parami switchy - switche albo zaczynają floodować pakiety
unicast, albo wysyłają je nie tam gdzie powinny - live session z Cumulusem - reboot switcha położył nam sieć :)
HyperLoops: duplikaty pakietów - brakuje wpisów MAC switcha peera, więc switch flooduje na wszystkie interfejsy, ale tylko
czasami :)
HyperLoops: flapowanie wpisów w tablicy MAC – wg. Cumulusa to jest OK :D
HyperLoops: co innego w control plane, co innego w data plane – pętla w sieci
adresy VIP i ich mobilność w sieci - IP rozgłaszane jednocześnie z dwóch par switchy
ARP suppression - switch odpowiada na ARPy także w innych VLANach
brakowało wpisów ARP na switchach - brak albo niepoprawna instalacja MACa switcha peera - only Mellanox related
Cumulus Linux w praktyce

38. Nadal lubimy Cumulus Linuxa :D

39. Dziękuję za uwagę
sadd
Dziękuję za uwagę. Zapraszamy do kontaktu:
www.creodias.eu
https://twitter.com/CREODIAS
https://twitter.com/CloudFerro
https://www.linkedin.com/company/clfr/