CategoryLinux

Linux Timeline

Je neuvěřítelné kolik existuje různých linuxových distribucí… O to zajímavější je tento pěkný graf, zachycující co odkud pochází a jak se jednotlivé distra vyvíjela.

gldt1210

3TB disk pod Linuxem

Do jednoho z linuxových serverů (Fedora 23) jsem nově instaloval dva 3TB disky. V době, kdy tera lítají tam a zpět jsem nečekal žádný problém… Jenže jedna věc je si o tom číst a věc druhá je takové disky skutečně mít a používat je…

Pokud připojíte disk a spustíte klasický fdisk, abyste si vytvořili novou partišnu, pak výsledkem bude diskový oddíl o velikosti 2TB… Důvod je jasný: 32 bitový LBA, který umožňuje adresovat maximálně 2TB, při velikosti sektoru 512B. 512 x 2na32 = 2TB.

GPT

Rěšením tohoto problému je GPT od Intelu, který je v Linuxu podporován a umožní vám vytvořit diskový oddíl větší než 2TB. Bez zabíhání o podrobnostech o GPT je tím zásadním důvodem zvětšení LBA z 32 na 64 bitů. Pak můžete vytvořit diskový oddíl o velikosti 8ZB. 512 x 2na64 = 8.6 billion TiB.

Pro samotné vytvoření diskového oddílu se nepoužívá nástroj fdisk, ale parted, který umí GPT. Finálním krokem je pak naformátování nového diskovho oddílu pro nějaký file systém:

File system Max vol size Max file size
Ext3 16TiB 2TiB
Ext4 1EiB 16TiB
ReiserFS 16TiB 8TiB
JFS 32PiB 4PiB
XFS 16EiB 8EiB

718037827599-1-zoom

Unix shell v JavaScriptu

687474703a2f2f692e67697068792e636f6d2f785430424b4e7755504668466a32676c72792e676966

Cash je multiplatformní implementace Unix shellu napsaná komplentně v ES6. Nevyžaduje žádnou kompilaci a není závislá na dalších externích aplikacích či jakémkoliv SW…

Redis

800px-Redis_Logo.svg

Redis je key-value databáze, kde value nemusí být jen ordinální hodnota, ale komplexnější struktura. Největší výhodou Redisu je to, že se jedná o in-memory databázi, což znamená, že vaše data jsou uložena přímo v RAM a práce s nimi je tedy nesrovnatelně rychlejší než s konvenčními databázemi. Tím samozřejmě nechci říct, že nejde nakonfigurovat MongoDB jako in-memory database, ale neni to typický inuse case.

Díky tomuto je Redis přímo předurčen k použití jako uložiště pro session proměnné www serveru, nebo čehokoliv jiného. Takto Redis primárně používám já. Session jsou proměnné které si mezi sebou vyměňuje klientův prohlížeč na straně jedné a vaše webová backend aplikace na straně serveru. A tou může být například NodeJS aplikace. Typicky Apache i Nginx pro sessions používají disk a data ukládají do souborů na disku. Přesunutím je do Redisu získáváte zrychlení práce se session daty, protože nejsou na pomalém disku, ale v neskutečně rychlejší RAM. Super.

No a jednou se třeba kvůli škálovatelnosti rozhodnote používat nějaký load balancer, jako je Nginx a zátěž (připojující se klienty) budete distribuovat mezi několik fyzických serverů. Super, protože krom samotného rozdělení zátěže získáte i redudantní prostředí, kdy vás neohrozí výpadek některého z vašich serverů, protože jeho práci za něj automaticky přebírají ostatní servery (o distribuci requestů se stará přímo Nginx).

No a přesně tady vyvstává problém: je sice cool, že Nginx pořeší výkon a dostupnost, ale právě vzhledem k tomu, že requesty klientů poletují mezi různými servery a vy v podstatě nevíte který ze serverů bude na daný požadavek odpovídat, musíte nějak pořešit i centrální a distribuované uložiště sessions dat. Protože je vám prd platné, že máte rychlý Redis, když není zrovna dostupný.

Řešením Redis uložiště je pak jeho nakonfingurování jako replica setu, kdy data jsou ukládána na master server a zároveň replikována na slave servery a tím je zajištěna jeji redudance, ale navíc ještě vlastní high availability manager: redis-sentinel, který monitoruje jednotlivé hosty v replica setu a podle jejich dostupnosti, či nedostupnosti, určuje jak se bude s daty pracovat. Redis uložiště se pak jeví jako jediný prostor na jakémkoliv stroji bez ohledu na to, jestli některý z fyzických strojů opradu neběží.

Skvělé: jako celek pak vše vypadá jako tří vrstvá architektůra:

  1. NodeJS aplikace, která komunikuje s redis-sentinelem (NPM balíček, ale i Python modul a víc jsem nezkoušel). Respektive ví o všech instnancích sentinelu
  2. Se samontou aplikací komunikuje redis-sentinel, který ví o všech fyzických Redis instancích a propaguje do aplikací funční master server. Sentinel se stará o monitoring jednolivých Redis serverů. Běží na všcech nodech a komunikují mezi sebou navzájem.
  3. No a úplně vespod jsou samotné instance Redis databáze. Jedna z nich je master a ostatní jsou slave.

Instalace, konfigurace

Osobně vycházím z toho,že mám 3 fyzické stroje, na kterých mi běží Nginx, pod ním na nějakém portu (reverzní proxy cache) NodeJS aplikace s Express web frameworkem, který pro session používa midleware Redis.

Instalace Redisu

Konfigurace je pak v /etc/redis.conf a /etc/redis-sentinel.conf

Konfigurace

Nejprve je potřeba rozeběhnout jednotlive instance Redis replica setu.

Do /etc/redis.conf na master serveru přídat následující:

Na slave serverech je potřeba ještě přidat informaci o tom, kde je master server:
slaveof IP PORT
Kde IP je ip adresa server na kterém běží master Redis instance.
Defaultní port Redisu je 6379.

Pak stačí všechny Redis instance zrestartovat a přhlásit se k nim pomocí bash příkazu redis-cli:

Protože je zapnutá autorizace, je potřeba zadat auth NejakeSuperHeslo.
Po zapsáni dat na master serveru: set pocitadlo 1, by mělo jít vyčíst počítadlo příkazem get pocitadlo z ostatních slave Redis serverů.

Tímto máme funkční Redis replica set s jedním master serverem a dvěma slave servery.

Nad tímto replica setem spustíme redis-sentinel, který se stará o monitoring jednotlivách serverů v replica setu.
Jediné co je potřeba je doplnit info pro autorizaci a pak info o master serveru:

ip je IP adresa master serveru
mymaster je název redis serveru
2 je počet serverů které musí souhlasit s tím, že master je nedostupný pro zvolení nového mastera

redis-sentinel je potřeba spustit na všech serverech a jako IP adresu uvést IP adresu master serveru dle výchozí konfigurace. Sentinel si dynamciky za provozu bude nastavovat IP master serveru dle dostupnosti jednotlivých serverů.

Připojení se z Python aplikace

Redis Sentinel v NodeJS

Cockpit Management Console

Pokud spravujete nějaký ten linuxový server, bude se vám určitě hodit Cockpit Management Console. Jedná se o webovou aplikaci, která vám ve webovém prohlížeči přehledně ukáže, co se právě děje na vašem serveru. Krom toho, že vidíte jak je na tom CPU, RAM, LAN a disky, můžete shazovat a nahazovat služby, koukat se do logu. Součástí webového rozhraní je dokonce i linuxová konzole. Pokud na serveru spouštíte Docker, pak jednotlivé kontejnery můžete skrze Cockpit spravovat…
cockpit

Instalace

Aplikace pak běží na defaultním portu 9090 (http://localhost:9090)

Automatický update Fedory

Pokud máte více serverů, které běží na nějakém linuxovém OS, v mém případě je to Fedora od RedHatu, pak vás jistě hodně rychle omrzí ruční aktualizace systému skrze DNF.

A vůbec pokud těch strojů je víc… Cron je super, ale psát si a udržovat vlastní scripty na něco, co vymysleli druzí také není to pravé ořechové.

dnf-automatic

A přesně k tomu se hodí dnf-automatic.

Snímek obrazovky 2016-03-07 v 10.47.32

Je jasné, že pokud běžíte nějaké kritické aplikace, které jsou závislé na nějakých konkrétních verzí aplikací, pak budete muset tuto závislost nějak ošetřit.

Předpověd počasí v Bashi

Výsledkem je předpověď počasí na 3 dny s informacemi o všem dúležitém a to včetně obrázků:

Snímek obrazovky 2016-02-18 v 13.28.35

SUSE


Fedora 23

Dnes vyšla nová verze operačního systému Fedora. Konkrétně Fedora 23. Fedora je linuxový operační sysém, který pohání všechny mé servery.

Info o novinkách získáte zde.

Jak upgradovat z verze 22

Jako root:

Zdroj

Svět bez Linuxu

© 2017 pepa.holla.cz

Theme by Anders NorénUp ↑