Příspěvky

76

Server / Re:K8s, PostgreSQL a replikace na tři nody

« kdy: 26. 01. 2023, 11:59:22 »

Uplne vsetci na to idu zle.

Vymyslas ohybak na narovnavak.

Toto ti nebude fungovat spolahlivo a uz vobec to nebude skalovat. Co ked tych nodov budes potrebovat 25?

Chces master-less architekturu.

Odpoved je Apache Cassandra.

Su na to aj operatory.

snuff1987 tady chce sql databázi a ty mu doporučíš cassandru? Opravdu? Vždyť to je naprosto něco jiného a ještě poměrně složitého na provoz, nevím, proč v poslední době jí tolik lidí vytahuje z hrobu a snaží se na tom stavět projekty a pak si volají o pomoc, když jim to nejde. To je stejně slepá cesta jak mongo, hbase aj.

Nejspíš správné řešení je active-standby a asynchronní synchronizace na standby nody, to pg umí velice dobře. Failover není ve většině projektů tak častý, aby se to muselo řešit bez výpadkově a beztrátově. Odkázané řešení od bitnami, kde logiku failoveru řeší pg proxy není vůbec špatné (technicky, provozně) a pořád máš výhodnu plné sql databáze.

Master-master replikace je vyšší dívčí a v dynamickém prostředí (cloud, k8s, multisite) to nedělá dobroty. Stale stavy, konflikty, dead locky budou nastavát vždy a není snadné se s tím automaticky vypořádat, cena za nevýpadkový provoz jsou provozní výpadky, složitá logika v aplikaci, která vše maskuje a drahá údržba. Naproti tomu active-standby s pravidelnými snapshoty, notifikacemi na vysoký replication lag, udržováním spare instancí je snadné i pro průměrné vývojáře, dobře to funguje v prostředí cloudu a k8s jen s nevýhodou delších failover časů a možností ztráty dat při failoveru, jedná se ale o čerstvá data, která lze aplikačně ošetřit (wait for standby sync).

Samozřejmě, poku se snuff1987 to chce naučit, vyzkoušet si master-master je nejlepší cesta, uvidí co to obnáší a taková zkušenost je k nezaplacení. Pokud ale dělá komerční projekt, neměl by vymýšlet příliš komplexní řešení na hypotetické problémy, může se to vymstít.

77

Server / Re:K8s, PostgreSQL a replikace na tři nody

« kdy: 24. 01. 2023, 11:10:07 »

Podivej se ja Crunchydata to umi vsechno co pozadujes.

a není už lepší použít https://www.percona.com/software/postgresql-distribution? Crunchydata mi připadají dost uzavřené, řada věcí se tam řeší enteprise cestou (= složitě se spoustou kroků), ale vídám to jen málo. Máš s tím více zkušeností? Dokážeš to popsat a porovnat?

78

Software / Re:Čím nahrazujete OpenVZ

« kdy: 24. 01. 2023, 11:06:08 »

tak je také otázka k čemu jsi to používal. Hojně jsme ale projekty, kde bylo openvz migrovali do systemd-nspawn, tam kde bylo potřeba nějaké silnější odstínění, tak qemu+kvm (např. přes libvirt). Mimo domácí prostředí pak docker, podman a další nástavby.

Ten vpsadminos je dílo vpsfree a oni si ho udržují, pěkná věc, ale kombinace ruby, perlu, nixos může být pro někoho velká bariéra, asi bych to nepoužíval mimo, nikdy nevíš, jestli to tak zůstane, co tam jak změní, ale na doma, proč ne. Stejně tak to založit na nixos sám není špatný nápad, jejich konfigurace deklarativní cestou je flexibilní.

79

Server / Re:K8s, PostgreSQL a replikace na tři nody

« kdy: 21. 01. 2023, 21:20:22 »

k8s na relační databáze bývá jedna z nejhorší kombinací, bohužel často vídaných, dokonce i zmíněný Oracle RAC vidím v tom běžet.

Jednoduché řešení je, nedělej to.

postgresql-ha od bitnami je pěkné řešení (technicky, jako další image od nich), ale pozor na to, že to celé visí na pg proxy, která si udržuje spojení na více pg serverů, hlídá si který je dostupný a pak případě udělá failover. Tady pozor, nemůžeš (=neměl bys) mít více pg proxy, takže ideální nasazení je mít pg proxy jako sidecar k aplikaci a pro každou aplikací vlastní sadu pg.

Citusdata je na tohle takový drobný overkill, to bych nedoporučoval tomu, kdo se na to musí ptát.

Pokud s tím aplikace umí, tak daleko lépe pro takovéhle malé hraní mi ze zkušenosti vychází použít mariadb s galerou v master-master variantě, já vím, nemá global locking, má omezenou velikost na update statement, má vyšší latence, ale zase s sqlproxy si rozumí, funguje to transparentně a když aplikace nemá problémy s nevýhodami, tak i v k8s se nad tím dá stavět, se spoustou hvězdiček.

80

Sítě / Re:Horší WiFi na MikroTik hAP ax3

« kdy: 19. 01. 2023, 14:04:10 »

hm, to není moc informací .

V jednom případě je ax3 rychlejší o 1/3, ve všech ostatní výrazně pomalejší. Není tam teda nějaké technické omezení nebo jeho nevýkonnost. Co mě zaujalo je právě variabilita mezi jednotlivými měřeními, až na ten jediný případ u ax3 (to spíše vylučuje, že by to byl vadný kus), tak ax3 dost skáče nahoru dolu, zatímco ac3 má daleko vyrovnanější čísla mezi jednotlivými měřeními.

Směřujem mi to právě k tomu, že máš problémy s rušením, odrazem signálu. Při měření přes nettest je rychlost stabilní, až při vyšších přenosech se projevuje problém.

Hledal bych rozdíly právě v rádiové části, v něčem bude rozdíl. Nemůžeš zkusit změnit místo, kde to měříš? Ax3 jsem měl několikrát v ruce a neměl jsem s ním tyhle problémy.

81

Sítě / Re:x11vnc - poslech na dvou rozhraních

« kdy: 19. 01. 2023, 11:47:19 »

x11vnc sám to neumí, buď konkrétní rozhraní nebo všechny (0.0.0.0). Kromě toho, co píše _Jenda bych jako další možnost viděl forward na straně iptables, kdy si to spojení 192.168.x.x na vnc odchytne a pošle na vnc interface.

Jen pozor na to VPN tailscale, je nutné, aby vpn byla up v momentě, kdy x11vnc startuje a stejně tak, aby se při odpojení také neodstranil interface, pokud tohle nemůžeš zajistit, tak jen 0.0.0.0, kdy se to automaticky připíchne i na nové interfacy a přes iptables vyřešit omezení.

82

Server / Re:FTP - kontrola úplnosti uploadu

« kdy: 19. 01. 2023, 11:42:18 »

FTP nemá žádné kontrolní součty, sice FTPS díky šifrování je odolné proti ztrátě dat cestou, ale pokud se zdrojová strana ukončí, tak soubor zůstane nahraný pouze částečně.

Často tohle jsme řešili nahráváním souboru do tmp a až poté přesun na cíl, ale pořád existovali situace, kdy se soubor nenahrál celý. Jediná možnost je mít na straně serveru implementovaný nějaký checksum mechanismus.

Jako náhradu mohu doporučit SFTP, kde probíhá kontrola při přenosu a upload do tmp nebo rsync, který přímo dělá kontrolní součty na obou stranách (ať už nešifrovaně přes rsync protokol nebo přes ssh).

83

Sítě / Re:Horší WiFi na MikroTik hAP ax3

« kdy: 19. 01. 2023, 11:38:34 »

802.11ac mám nastavené na obou, abych porovnával stejné standardy.

Rychlosti na 802.11ax jsou podobné jako na ac.

a co kanál, jeho šířka, rušení? Jaký je šum na rádiu? Pořád tady platí nějaké fyzikální zákon a prostě nelze prohodit dvě zařízení, nenastavit stejné podmínky a měřit to jen tak. Vždyť i blbé natočení routeru o 20 stupňů může mít desítky % dopad na přenosovou rychlost a ten ax3 přitom má antény řešeny lehce jinak.

84

Sítě / Re:Horší WiFi na MikroTik hAP ax3

« kdy: 18. 01. 2023, 21:16:56 »

a jak vypadá konfigurace? Jak máš umístěné antény a sílu signálu? Ty routery nejsou totožné, chovají se rádiově lehce jinak.

85

Distribuce / Re:Automatické aktualizace PHP v Debianu

« kdy: 17. 01. 2023, 15:24:23 »

žádnou aplikační závislost neinstaluji přes systémové balíčky, pokud není možný docker (či systemd nspawn nebo jail), tak používám třeba něco na způsob conda-forge balíčků https://anaconda.org/conda-forge/php.

Dříve jsem tohle hodnotil jako nesmysl, prostě mělo vše být instalované z oficiálních udržovaných repositářů, ale dnes aplikační vývoj na projektech, kde dělám je hodně OS nezávislý a vývojáři jedou jiným životním cyklem než samotný OS, často OS potřebujeme aktualizovat a neohlížet se na vývojáře, být schopný aplikaci otestovat a sestavit.

Další důvod je schopnost konečné sestavení nějak rozumně testovat, doba, kdy člověk dal update a trnul co za skripty se na produkci spustí a co udělají za změny je pro mě pryč, nechci, aby se na produkci spouštělo cokoliv nedetermistického, hci produkci prostě atomicky přepnout a ne instalovat a čekat.

Dnes se mi velice osvědčuje používat nixos, generovat celý vm/docker/chroot dopředu vč. aplikace, testovat, analyzovat, kontrolovat a pak 1:1 nasadit. Máme pak přesný přehled o tom, která aplikace s jakými závislostmi kde přesně běží, máme možnost dělat emergency patche i do zdrojáků php a nečekat na maintenera.

Po letech s debianem začínám tu jejich filosofii deb balíčků, install scriptů a závislostí nemít rád.

86

Server / Re:VPS hosting pro minecraft server

« kdy: 15. 01. 2023, 00:28:25 »

nj. ale ten oracle je arm a minecraft na arm je lehce problém, funguje verze z MS app store, ale ne ta pro linux.

87

Server / Re:Komprimovat či nekomprimovat data pro HTTP

« kdy: 14. 01. 2023, 11:37:49 »

u malých webů to je asi úplně jedno, mohu-li mluvit o velkých (miliony unikátních uživatelů měsíčně), tak online komprese na http serveru se nepoužívá, ale co je potřeba se komprimuje dopředu, jde zejména o statické soubory, tam se dá rozhodnout má-li to cenu nebo nikoliv, webový server pak zvolí správný předkomprimovaný soubor (logicky je přece mrháním výkonu milionkrát komprimovat každý soubor pro každého návštěvníka zvlášť).

Občas je potřeba komprimovat generovaný obsah z aplikace, o to se převážně starají sami aplikace nebo se přidá prostředník k aplikacím, který kompresování zajistí. Důvod je, že aplikační servery se škálují daleko lépe než ty proxy přes které teče obsah.

88

Windows a jiné systémy / Re:Detekce verze Windows webovou aplikací

« kdy: 11. 01. 2023, 15:23:49 »

A není lepší ten Windows aktualizovat? Přeci jen Windows 7 včera přišel o podporu a již nebudou vycházet další bezpečností aktualizace, což pro tebe může být obrovské riziko.

To záleží jak to Česká spořitelna implementuje, user-agent je dobrý začátek, ten umíš změnit, ale pak existuje spousty dalších doprovodných signálů, které prozradí samotný OS a tam to může být těžší.

89

Server / Re:Hosting s Grafana nebo vzdáleným přístupem k DB?

« kdy: 11. 01. 2023, 13:20:41 »

Tak grafana je samostatná služba, která se musí provozovat extra, to běžné hostingy nedělají, zejména když grafana sama o sobě nezvládá dobře multi-tenant prostředí a musíš pro každého provozovat extra instanci.

A potřebuješ přímo grafanu? Nestačí ti projekt typu https://tmep.cz?

Jinak všichni si tohle provozují doma, tam to máš zadarmo, docker image stáhneš a běží ti to (pro hrátky asi dostatečné). Mysql a ani grafana (ač se o to snaží) by neměla být vystrčena do internetu, není to snadno zabezpečitelné, takže pokud si to budeš provozovat sám, tak si pořídit vps, udělat si tunel/vpn k sobě a tak tam lít data.

90

Studium a uplatnění / Re:Komerční banka - Java developer (inkubátor)

« kdy: 10. 01. 2023, 10:03:58 »

M_D: uhf, díky za dlouhý a přínosný popis. Ano, zahučel jsem do toho, protože jsem tyhle detaily neměl ošetřené, nečekal jsem to a nevěděl jsem, že jsou postižitelné i krátké kontrakty a omylem jsem se usvědčil. Zajímavá je pro mě poznámka, že je důležitá odbornost, jako OSVČ dělám právě ty povídací školení nebo optimalizace databází na produkci, tam mám vstupní kartičku i se jménem asi do 10 společností a přemýšlel jsem, jestli to takhle nechat, převést na firmu nebo se na to vykašlat. Očividně to je ale díky odbornosti pořád cesta průchodná.