Příspěvky

436

Sítě / Re:T-Mobile - slovenská GeoIP

« kdy: 23. 03. 2021, 16:12:00 »

GeoIP je z podstaty věci neoficiální a negarantovaná. Jestliže jiná na ní závislá služba garantuje svoji funkčnost, pak se musí sama postarat, aby jí to jelo, jestliže negarantuje, pak není co vymáhat.

A co je prosim vas na internetu (ktery nikomu nepatri, a nad nimz nikdo nema kontrolu) "oficialni" ci "garantovane" ?!?!?!?

Slovo garantovat bych nepoužil, ale obecně věci jako DNS, BGP, TLS (a nové CT) a jiné nízkoúrovňové mají svoje standardy, existují organizace, které je zastřešují, existuje proces jak ověřovat soulad se standardy a vesměs se to dodržuje.

Zůstaneme-li u IP adres, je tady poměrně přesné a jasné člěnění, IANA zastřešuje jednotlivé RIRy, ty vedou databázi AS a k nim přidělených prefixů, tahle evidence je poté veřejné a nižší dělení na jednotlivé IP adresy se nedělá, protože to je velice těžko realizovatelné z podstaty fungování IP sítí a nemluvě o nemožnosti v případě IPv6 sítí. Požadovat něco takového po ISP je absurdní.

To může napsat jen někdo, kdo tráví tolik času diskutovánhím na Rootu, že se k řešení problémů už nedostane. Já chápu, jak moc je blokování dle lokace fujky, ale ač je to technicky nepěkné, chrání mi to pět Teamspeak serverů před shazováním minimálně jednou denně krátkým DDoS. A funguje to na sto procent. Češi si tohle tolik nedovolí, po nich by se dalo snadno jít.

DDoS zpravidla na svém FW a serveru nezastavíš, ucpe linky daleko dříve, proto to slovo "distributed". Plést dohromady zákaz omezování služeb podle země v rámci EU, o kterém se tady bavíme a ochrana infrastruktury před útoky je nesmysl, jsou to rozdílné věci, ani tohle ti nebrání po whitelistování sítě nabízet službu i do jiného státu. "Češi nedovolí", podobné útoky jsou automatizované a vede ze zařízení, které má útočník pod kontrolou - botnety - nehraje v tom roli národnost a hromada zařízení útočí i z ČR.

437

Server / Re:Přechod z ext4 na ZFS - podstatné snížení rychlosti databázové aplikace

« kdy: 23. 03. 2021, 10:09:18 »

Důvodem je to, že zápisy pro (OLTP) databáze jsou náhodné, což v případě copy-on-write strategie pro data způsobuje že logicky souvislé soubory jsou nesouvisle roztrhány na disku. Logické sekvenční čtení (=čtení souvislá řada bloků) pak není vůbec fyzicky sekvenční a je spíše náhodné lítání hlavičky po disku podle toho kde jsou zrovna data zapsána. A výkon náhodného čtení/zápisu z disku je řádově nižší než sekvenční čtení/zápis.

Platí to i u SSD disků?

neplatí, u ssd není již takový propad při náhodném zápisu/čtení, naopak sám ssd data rovnoměrně rozděluje po celém disku i v případě zápisu souvislých bloků a nejsem s to tohle ovlivnit, pač se zapisuje do logické a nikoliv fyzické struktury.

Je to i nesmyslu z pohledu jak vlastně databáze funguje, běžně dělá malé inserty a u nich nezajistím souvislé bloky dat, od dob, kdy databáze nepoužívají raw device, ale nějaký FS, je fragmentace jejich dat na pořadu dne, dnes již většinou není potřeba výrazně řešit. Běžné plotnové disky mají AU (alokační jednotka) 4kb, zatímco innodb ukládá data po 16kb, dochází tedy k fragmentaci již i jednotlivých ukládaných bloků, nějaké snahy jako dělat až 4MB předalokaci tady jsou a většinou i fungují, pořád ale platí, že i na plotnových discích se musí na OLTP databázích občas spustit kompakce. Copy on write FS (COW FS) pro databáze v tom nedělají velký rozdíl, innodb samo vždy přepisuje/připisuje 16kb bloky dat, pokud se zachovají stejně velké bloky u na straně FS, je to v pořádku. U hodně specializovaných databází mohu mít pro jednotlivé tabulky specializované disky, pak se data ukládají souvisle, takové řešení jsem ale už dlouho neviděl, nebylo potřeba.

438

Vývoj / Re:Knihovna pro vytváření flow (open source Azure Logic Apps)

« kdy: 22. 03. 2021, 16:39:23 »

vloni jsme "vykradli" frontend z Nifi a postavil nad tom admin pro SDN. Je to pod Apache 2.0, takže se to dá dobře použít.

439

Sítě / Re:T-Mobile - slovenská GeoIP

« kdy: 22. 03. 2021, 12:18:45 »

to že tady jsou třetí společnosti a vedou si databázi ip adres a jejich umístění přece nemá moc společného s T-mobilem. U nadnárodních operátorů je trochu problém, že hranice vlastně neexistují.

Žiju v pohraničí a je to neřešitelný problém, v podstatě 10 let bojuji s tím že řada služeb mě prostě strká do jiného státu a pak mám smůlu, protože se s nimi nedá moc mluvit, v čele s Googlem, který mi pořad vrací německé výsledky vyhledávání, ikdyž v češtině, nastavení u Google účtu moc nepomáhá. Operátor ale bohužel nemá moc možností jak to změnit u třetích stran.

Kdyby se někomu podařilo přesvědčit ČTÚ, že by poskytovatel internetu měl vyvinout přiměřené úsilí, aby problém pomohl odstranit, bylo by po problému. Kdyby se nesnažil, byl by třeba nucen dávat 50 % slevu na připojení k internetu. Samozřejmě nemůže být odpovědný za všechny databáze, ale za ty hlavní, které používají google, seznam, hlavní televizní stanice a několik největších služeb by zodpovědný měl být. Pokud máte např. VDSL  není problém vyměnit arogantního poskytovatele za jiného. Vesnický Wifi poskytovatel si to asi také nemůže dovolit, majitel by to schytával každý den od všech lidí co potkává. Zbývá umravnit jen velká nadnárodní hovada a proto navrhuji ten ČTÚ. Možná by bylo dobré si to předjednat předem.

Ono je třeba rozlišovat ip adresy už také proto, aby to správně routovalo.  Např. zde je seznam IP adres, které se směrují přes NIX a  SIX. https://support.master.cz/peeringy-cz-sk/

máma tedy snahy o omezování geo ip (v rámci celé EU) a ty bys vynutil, aby ISP ty geo ip databáze povinně aktualizovali, skvělé. Řadu let se tady zákonodárci nějak snaží omezit vliv geo ip a ty bys ještě přidal povinnost takové databáze ze zákona vést a to jen proto, že neumíš napsat poskytovateli služby, že jsi jinde a domluvit se s ním, nepřipadá ti to ujeté?

Hele to je nesmysl, asi netušíš jak ty sítě a tyhle geo věci fungují, je nemožné to dát jako povinnost poskytovatelém, protože nad tím nemají vůbec žádnou moc, takové databáze se nevedou podle žádného zákona, on by byl i problém je vést, protože podle čeho má vůbec ISP tu lokalitu odvodit? Podle fakturační adresy? Podle adresy kam je jeho síť připojena? Co když zákazník si provoz bude routovat do jiného státu (běžně dělají nadnárodní společnosti, že centralizují svoje brány)?

440

Sítě / Re:T-Mobile - slovenská GeoIP

« kdy: 21. 03. 2021, 17:36:35 »

to že tady jsou třetí společnosti a vedou si databázi ip adres a jejich umístění přece nemá moc společného s T-mobilem. U nadnárodních operátorů je trochu problém, že hranice vlastně neexistují.

Žiju v pohraničí a je to neřešitelný problém, v podstatě 10 let bojuji s tím že řada služeb mě prostě strká do jiného státu a pak mám smůlu, protože se s nimi nedá moc mluvit, v čele s Googlem, který mi pořad vrací německé výsledky vyhledávání, ikdyž v češtině, nastavení u Google účtu moc nepomáhá. Operátor ale bohužel nemá moc možností jak to změnit u třetích stran.

441

Server / Re:Přechod z ext4 na ZFS - podstatné snížení rychlosti databázové aplikace

« kdy: 21. 03. 2021, 14:52:13 »

Mysql to u innodb používá, viz "To take full advantage of this feature, an innodb_flush_method setting of O_DIRECT is recommended. " na https://dev.mysql.com/doc/refman/5.7/en/innodb-disk-io.html

Řada databází používá O_DIRECT, protože si sami řeší buffer a nepotřebují, aby to fs či OS buffer vedle nich, stejně tak třeba innodb používá doublewrite buffe a je schopná se dosta z chyb, které mohou vzniknout při neúspěšném zápisu O_DIRECT (nemáš totiž jistotu, že data doputovala na disk).

Řešíš tady výkonnost mysql nad zfs, tam je tahle funkce velice důležité, protože to výrazně tu výkonnost ovlivňuje, ale chce to měřit, měřit a měřit. Jiná databáze to bude mít trochu jinak, chceš-li z toho vytlačit víc, musíš si nastudovat jak se chová a jak jí práci ulehči a hlavně jak tu práci neduplikovat.

Různé FS se chovají různé, xfs má konstatní čas pro zápis, ač je pomalejší, je takhle pomalé vždy a nemá občasné pauzy, jak to má ext4. ZFS zase poskytuje silnou podporu pro COW, snapshoty, replikace, snadnějí správu a lepší kontrolu nad samotnými block device, nepotřebuješ pak používat drahé RAID pole. Důvody, výhody a cíle bys měl mít ujasněné dopředu, pak je možné ladit.

442

Server / Re:Přechod z ext4 na ZFS - podstatné snížení rychlosti databázové aplikace

« kdy: 21. 03. 2021, 00:48:48 »

Jak pomocí microbench debugovat O_DIRECT u zfs jsem nepochopil ani nikde nenašel.  Ale myšlenka že testovat raději přímo výkon disku než výkon databáze je dobrá, protože je to podstatně snandnější a rychlejší.

Kód: [Vybrat]

fio --direct=1 --ioengine=libaio --bs=16k ...

Např. konkrétně:

Kód: [Vybrat]

fio --name=randrw --rw=randrw --direct=1 --ioengine=libaio --bs=16k --numjobs=8 --rwmixread=80 --size=10G --runtime=1800 --group_reporting 

nepoužívej iodepth a ani sync, pro mysql potřebuješ měřit O_DIRECT. O_SYNC znamená použití kernel cache při zápisu a volání fsync(2) po každém blocku, tj. dva syncally, to měříš něco, co mysql nepoužívá, takže výsledky nejsou relevantní.

Nepíšeš jak máš nastavený zfs/ext4, takže těžko soudit z výsledků tvého měření.

443

Server / Re:Přechod z ext4 na ZFS - podstatné snížení rychlosti databázové aplikace

« kdy: 19. 03. 2021, 21:18:13 »

ještě malý tip, v případě mysql a innodb je vždy nejrychlejší nejprve debugovat přímo O_DIRECT zápis s 16KB, je dobré vyzkoušet více kernelů, zejména po 4.8 byly nějaké regrese na ssd/nvme. Výkonnost mysql to pak reflektuje většinou velice dobře, výjimkou je ext4, který je dost šíleny pro databáze a měření. Pokud máš tak velké rozdíly proti ext4, máš zfs nevhodně nastavený, projdi nastavení znovu, najdi mikrobench, který ti dovolí rychleji zkoušet různé varianty

444

Server / Re:Přechod z ext4 na ZFS - podstatné snížení rychlosti databázové aplikace

« kdy: 17. 03. 2021, 10:12:48 »

xsouku04: pokud chceš konkrétně poradit, tak sem musíš strčit konfiguraci databáze, zfs a sysctl, bez toho tě můžeme odkazovat pouze na obecné doporučení.

445

Server / Re:Přechod z ext4 na ZFS - podstatné snížení rychlosti databázové aplikace

« kdy: 16. 03. 2021, 23:12:13 »

Nemá ZFS něco na vypnutí copy-on-write, tak jako se doporučuje chattr +C u databází na btrfs?

nemá, zfs neumí in-place zápis. Používá se ale stejný block size (record size u zfs) jako je page size u databáze, která zapisuje, pak každý zápis skončí v novém blocku a není potřeba dělat žádné kopírování přepisovaného blocku.

446

Server / Re:Přechod z ext4 na ZFS - podstatné snížení rychlosti databázové aplikace

« kdy: 16. 03. 2021, 22:08:28 »

lets encrypt se moc pěkně rozepsali o tom, jak ladili zfs pro mariadb, začti se https://github.com/letsencrypt/openzfs-nvme-databases a pak se případně zeptej co ti není jasné, co jsi zkoušel a jaké jsi měl výśedky.

openvz má nastavení určité limity a priority přes cgroup, lxc je čistá kniha, musíš to tam nastavit a vyřešit sám jinak se ti může a bude stávat, že jeden vytíží celý server a ostatní si nemusí vrznout.

447

Distribuce / Re:Vlastní PPA repos

« kdy: 16. 03. 2021, 00:33:03 »

PPA repo je obyčejný http server s předem danou strukturou. Pro generování toho obsahu můžeš použít třeba apt-ftparchive nebo dpkg-scanpackages, k tomu trochu gpg pro podpisy.

Na netu je spousta zdrojů, tady je třeba man page od Ubuntu https://help.ubuntu.com/community/Repositories/Personal.

Github nedávno přidal podporu pro hostování PPA.

448

Server / Re:Databáze - 300 GB tabulka

« kdy: 13. 03. 2021, 23:29:19 »

problém bych neřekl, že je v použité databázi, ale ve způsobu jak s ní pracuješ, jak s mariadb, tak i pgsql je možné mít tabulky i k TB, ale už to chce odejít z výchozího nastavení.

Pg umí od 9.x insert on conflict do nothing, stejně tak mariadb umí insert on duplicate key. V kombinaci s prepared statements a bulkem pro třeba 5000 values, zvedneš rychlost ukládání dat do db o dva řády (tj. cca 20000 insertů za vteřinu na jediné instanci při 10 paralelních dotazech a ve výchozím nastavení). Pg umí i dobře komprinovat data, takže ti ušetří místo na disku. Na webu najdeš řadu kalkulaček pro nastavení db podle množství dat a druhu práce.

Zkus ClickHouse, tenhle úkol by mohl zvládat ve výchozím nastavení a poměrně rychle, má pokročilé metody komprese dat a můžeš ušetřit i 80 % původní velikosti.

Pokud nepotřebuješ přímo databázi, mrkni třeba na formát dat Apache Parquet, dostupný je z řady programovacích jazyků, data umí velice efektivně deduplikovat, komprimovat. Rychle s tím lze pracovat třeba přes spark (python, scala, r), za pár desítek minut na středně silném stroji to máš uložené a zpracované.

Další možnost je jít do cloudu, pronajmout si na pár desítek minut nějakou databázi, tam data zpracovat a pak si je stáhnout zpracovaný a deduplikovaný, pokud teda to chceš jednorázově.

449

Studium a uplatnění / Re:IČO nebo HPP jako programátor?

« kdy: 07. 03. 2021, 13:32:44 »

No moje zkusenost je zase jina. Napriklad firma s businessem v logistice. Skoro vsechen vyvoj si outsourcuji, ale maji tym architektu internich kteri maji drzet lajnu... Prave z duvodu, ze pak muzou vystridat dodavatele a neutece jim klicova znalost.

Samozřejmě asi najdeš příklady na obě strany, já těch společností navštívil několik desítek a z principu jen ty, kteří mají tyhle lidi externě, jinak bych tam nebyl.

DHL v německu má řadu architektů externě, u české pobočky nevím, ta hodně outsourcuje a je tam dost zmatek, pro UPS jsem také dělal, u PPL jsem nepotkal architekta ani toho interního, Zásilkovna má vše vlastní, co jsem pochytil.

Např. česká Škodovka to dělá podobně, interní tým architektů, kteří drží znalosti a vývoj kompletně outsourcovaný. To je dobrý patern, ale musíš si ty architekty zaplatit a pak i ten externí vývoj, vidím to jen u těch hodně velkých společnostní (na našem trhu), které primárně nedělají online služby, ale jsou zejména z průmyslu.

Tím se dostáváme zase k původní otázce, podle mě rozdíl stará práce na HPP a nová na IČO s o 50 % vyššími neočištěnými příjmy mi nepříjde tak moc výhodné a něco, proč bych do toho měl jít. Nejspíš při změně práce si jinde umíš vyhádat aspoň o 20 % víc i na HPP. Práci na IČO právě vidím výhodnou pro tyhle vyšší pozice, kdy pracuješ opravdu pár dní týdně na projektu, můžeš mít více projektů, takže žádné problémy s vysvětlování švarcu a rozdíl v penězích už je opravdu vysoký.

450

Software / Re:Jak neobnovitelně smazat data na HDD?

« kdy: 07. 03. 2021, 13:09:51 »

v provozních směrnicích máme i pro SED disky povinnost je mnohokrát přepsat a poté zkartovat. Obecně SED je taková okrajová záležitost, není žádná kontrola nad výrobci, nikdo moc dobře neví, jak to vlastně mají vnitře dělané a nenarazil jsem ani na žádné normy, které by bylo potřeba dodržovat.

u plotnových většinou stačí přepsat vše několikrát a ověřit, jestli náhodou disk neobsauje příliš realokovaných dat. U SSD to je horší, neumím totiž zapsat na konkrétní místo a i při 100 % zaplněném disku jsou využity sparse bloky, takže se může stát, že vlastně tam data zůstanou.