Letnia Akademia SUSE Implementacja nowych rozwiązań open source wszystko, co musisz wiedzieć! Każdy kolejny czwartek do 7 września w godz. 10:00-12:00.
Omawiane tematy: Dzisiaj: Ciągłość działania serwerów Linux (Zero Downtime z Live Patching, Rollback, HA) 24 sierpnia: OpenStack z pudełka Jak zacząć, architektura, konfiguracja oprogramowania, zarządzanie chmurą, kalkulacja usług i aprowizacja, 31 sierpnia: Budowa Software Defined Storage z SUSE Enterprise Storage. 7 września: Konteneryzacja aplikacji z SUSE CaaS Platform (orkiestracja z Kubernetes, MicroOS dla mikroserwisów i kontenerów, zarządzanie konfiguracją z Salt) Nagranie z 3 sierpnia: Zarządzanie farmami serwerów Linux i kontenerami z SUSE Manager 3.1 (dystrybucje rpm SUSE/Red Hat) 2
Informacje porządkowe Wszystkie zajęcia są nagrywane Link do nagrania i prezentacji rozsyłamy do wszystkich zarejestrowanych osób W trakcie można zadawać pytania korzystając z okna Questions PS. Zapraszamy na SUSECON 2017 w czeskiej Pradze (25-29 września). Jest już dostępny katalog sesji. www.susecon.com 3
Zapraszamy na zajęcia! Poprowadzi je Dariusz Puchalak z firmy OSEC ośrodka szkoleniowego SUSE 4
Letnia Akademia SUSE - Zero Downtime Dariusz Puchalak
Dariusz Puchalak 20+ lat Linux/Unix Sysadmin 10+ lat trener 3+ lat w OSEC
http://www.osec.pl Od 2009 na rynku doświadczona kadra (ACNI, RHCA) specjalizacja open-source subskrypcje, szkolenia, konsultacje
Wysoka dostępność - co, jak i dlaczego?
Czy potrzebujemy HA??
High-Availability usługi dostępne tak długo, jak się da eliminacja wąskich gardeł eliminacja pojedynczych punktów awarii (SPOF)
Czy da się utrzymać w działaniu usługę, która zawiera błędy??
SLES Live Patching czyli jak nie restartować serwerów i zapewnić bezpieczeństwo.
Live Kernel Patching Musi cały czas działać! vs Ma być bezpiecznie!
Okno serwisowe vs szybki reboot.?
Wymaganie bezpieczeństwo. PCI-DSS ISO 27001
Live Kernel Patching Zjeść ciastko. Mieć ciastko. :)
Live Kernel Patching In-memory DB Mission Critical Loooooong simulations Massive (and time critical) deployment
Live Kernel Patching Technologia: kgraft
kgraft zalety. Nie wymaga zatrzymania kernela. Budowany bezpośrednio z kodu w języku C. Bardzo mało kodu wykorzystuje już istniejące mechanizmy w kernelu.
kgraft działanie. kgraft patch mały moduł kernel. Podmiana całej funkcji w kernelu. Kolejny patch kgraft zastępuje już istniejący.
kgraft ograniczenia. Tylko do błędów krytycznych. Zmiana wew. struktur kernela wymaga specjalnej uwagi. (na szczęście raczej nie będzie takiej potrzeby) :) Wymaga stabilnego środowiska. Patch nie jest przenośny między różnymi wersjami kernela.
kgraft ograniczenia. Nie można poprawić kgrafta. Nie można poprawić ftrace Nie można poprawić tzw. main loop Nie można poprawić modułów firm 3-cich.
Live Kernel Patching HOWTO Aktywuj SLE Live Patching Zainstaluj kgraft i kgraft-patch Sprawdź, czy jakieś procesy wymagają obudzenia (/sys/kernel/kgraft/in_progress lub kgr -v blocking) Obudź procesy aby zakończyć proces podmiany funkcji kernel (kgr poke) Można instalować kolejny patch
Live Kernel Patching Można wydłużyć uptime :) Pozwala wycofać zmianę! (ale wymaga później restartu serwera). Wymaga subskrypcji. Moduły firm trzecich mogą zablokować proces łatania. Program Temporary Fix (SUSE) dla kernela wymaga później 2 restartów.
SLES HA Extension wprowadzenie.
Typy klastrów.?
Typy klastrów. klastry wydajnościowe klastry niezawodnościowe klastry równoważące obciążenia za: https://pl.wikipedia.org/wiki/klaster_komputerowy
Typy klastrów. Klastry ze współdzieloną pamięcią dyskową Klastry sieciowe (bez współdzielonej pamięci dyskowej)
Czy zawsze musimy użyć technologii HA??
Kiedy nie potrzeba klastrów. DNS LDAP
Kiedy potrzeba klastrów. NFS Samba
Klastry HA - terminy Node Heartbeat Resource (zasób) i resource group (grupa zasobów) Quorum Epoch (epoka ;) ) Split Brain Fencing STONITH
Terminy. active-passive active-active
SLE HA Extension Add-on od SLES 11 Potrzeba subskrypcji Do 32 nodeów Geo Cluster Extension Korzysta z Corosync/Pacemaker (czerwona konkurencja już też) Zarządzanie via cmdline crm. Zarządzanie via web HAWK tylko SLES
Split-Brain?
Split-Brain Części klastra mają inne wyobrażenie o jego stanie. Jeden lub więcej node jest w stanie nieokreślonym. W wyniku Split-Brain można uszkodzić dane. Sytuacja ze Split-Brain musi być wyjaśniona przed uruchomieniem zasobów.
Jak uniknąć Split-Brain??
Jak uniknąć Split-Brain? Dobra komunikacja sieciowa (najlepiej redundantna). Dobre połączenie do pamięci dyskowej (najlepiej redundantne). Taka sama konfiguracja node ów. Trochę szczęścia? ;>
Jak sobie radzić, ze Split-Brain? Fencing SFEX - Shared File Exclusiveness STONITH
STONITH Shoot The Other Node In The Head Shoot The Offending Node In The Head
STONITH Deathmatch
Typy STONITH IPMI APC power SBD libvirt...
RRP Redundant Ring Protocol Drugi interface dla heartbeatu Może pomóc zapobiec rozdzieleniu klastra.
MPIO MultiPath I/O
SLES HA Extension - działanie.
Współdzielona pamięć dyskowa. Klastrowe systemy plików: OCFS2 GFS2
Zalety OCSF2/GFS2. Lepsza wydajność od sieciowych systemów plików (NFS/Samba) Aplikacje mogą korzystać z memory-mapped files. brak SPOF (nie jak w NFS'ie)
Wady OCFS2/GFS2. Nie można cacheować informacji w inode'ach.
Zasoby. Zasób klastra: dowolny element zarządzany przez klaster, np. adres IP system plików usługa
Zasoby W zależności od typu zasobu może on działać w trybie: active/passive active/active
RA Resource Agent ustandaryzowany interfejs do zasobów klastra
Grupowanie zasobów. Podstawowe zasoby łączymy razem w grupy.
Przypadek specjalny: 2-node klaster
Pytania? Dariusz.Puchalak@osec.pl