Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - _Tomáš_

Stran: 1 ... 32 33 [34] 35 36 ... 47
496
Server / Re:HW raid 10 vs 6
« kdy: 29. 01. 2021, 15:16:18 »
Pánové řešíte nesmysly. Disky jsou nespolehlivá zařízení a každý den hrajete loterii. Proto jsou v roce 2021 úvahy o RAID 10 nebo 6 zamrznutím v čase, řešením pro dnešní dobu je distribuované úložiště/FS.

ano, i v konzervativním bankovním sektoru se přechází na distribuované uložiště, odhadem největší české banky už mají poměr 50:50 v porovnání s diskovými poli, ty už se skoro nerozšiřují.

Porovnávání čísel hypotetické spolehlivosti se řešilo snad vždy, pak člověk koupí disky najednou z jedné série a umřou mu všechny ve stejném čase.

497
Server / Re:HW raid 10 vs 6
« kdy: 21. 01. 2021, 23:08:32 »
kolik tam bylo cpu jader? Těch 48 cpu při plném zatížení se nejspíš dost nepěkně pralo s plánovačem v Linuxu a dělalo to neplechu, to mohlo způsobit tak vysoký iowait a disky vytížené nebyly. Tyhle diskové pole mají mezi sebou obrovské rozdíly. Pro mě to jsou blackboxy a zkušenosti mám jen s klasickými 2U s 16 - 20 disky.

Samozřejmě, pokud tam zajistíš UPS, uděláš zálohování, proč ne. On ten čip uvnitř může být stejný, proč by ne, ale může být jiný firmware, jiný způsob chlazení a napájení atd. U enterprise ssd se začaly TLC objevovat teprve nedávno a mixed use jsou snad jen na MLC.

On to je podobný problém jako používat konzumní plotnové disky do serverů, občas to dává smysl a lze to použít, pak do 4U skříně nacpeš několik desítek disků s NCQ a parkováním hlaviček, navzájem si udělají takové vibrace a kolísání proudu, že v nejlepším budou odpadávat, v nejhorším zapíší poškozená data. To jsem zažil. Když víš co jak, můžeš ušetřit, když nevíš a chceš jen ušetřit, můžeš se ošklivě spálit.

498
Server / Re:HW raid 10 vs 6
« kdy: 21. 01. 2021, 21:07:47 »
No po pravde bych dnes pro takhle malou kapacitu tocici disky vubec neuvazoval. Pokud tam nebudou nejake extremni zapisy, dal bych tam, dva 7TB nvme (napr. Samsung PM983) v raid1 a hotovo. S 1.3 DWPD na 5 let by to nemusel byt zadny problem.

v takovém případě můžeš použít jen SW raid (ty HW v běžných serverech nemají podporuje pcie a nvme). SW raid pro tyhle rychlé disky je dost úzké hrdlo a nesplní to očekávání (odzkoušeno), výrazně klesnou iops při paralelním přístup z více procesů a riziko rozbití FS při ztrátě napájení je obrovské, běžně raid děláš i kvůli záloze dat a spolehlivosti a nikoliv jen kvůli rychlosti.

Každopádně využít ssd v raid může být dobrá cesta, jen cena je astronomická, takový dva HPE 6.4TB SAS (MU) v serveru výjdou na 300k (pokud mám dobrou slevu). To asi není dobrý směr. Kupovat konzumní na satě s tlc/qlc technologií se také může vymstít, zejména, když jsou data cennější než ty disky.

Po těch spoustě rozbitých FS při problémech s napájením bych do SW raid už nešel, je to strašně moc práce v době, kdy to člověk nechce řešit. Buď HW raid s baterii (i z bazaru stojí pár korun) nebo nějaký distribuovaný FS, což je mimochodem věc, kterou poslední dobou u projetků ty drahá disková pole nahrazujeme.

499
Server / Re:HW raid 10 vs 6
« kdy: 20. 01. 2021, 20:01:05 »
on je rozdíl kdo bude ty paritní bloky počítat, jestli CPU, budeš mít zdržení a nevyužiješ rychlejšího paralelního ukládání u R10. Pokud diskový řadič s cache a baterií, měřit se to bude při většině použití velice složitě a dopad na výkon nemusí být v podstatě žádný.

Ještě bych doporučil se podívat na R50 (s 1 paritními bloky pro každý R5), zůstane ti odhadem 9 TB dat a mohou dva disky umřít.

Všechno bude záležet na kolik iops takový storage budeš cílit, pokud třeba 500, rozdíl nepoznáš, pokud třeba 2000, volil bych odhadem R10. Jaký FS (nějaký COW?) a služby na tom pojedou?

500
Server / Re:Změna formát datumu ve /var/log/messages
« kdy: 20. 01. 2021, 16:28:43 »
vzhledem k tomu, že to je nastavení distribuce, tak se budou návody rozcházet podle distribuce, každá si volí jinou konfiguraci a službu, která se o logy stará.

Většina z nich má třeba konfiguraci v /etc/syslog.conf, ten samotný formát datumu je odvozených od tvých locales, takže uprav locales pro syslog daemona nebo pro celý systém a tam si to změň.

Máš důvod, proč si parser píšeš ručně a nevyužiješ hotové řešení? Ukládání přímo syslog zpráv do databáze umí sám rsyslog nativně https://www.rsyslog.com/doc/v8-stable/tutorials/database.html, ten doinstaluješ na systém poměrně snadno. Pak tady jsou nástroje jako filebeat, fluentd, fluent-bit a další, které tohle už umí. Pokud se to chceš naučit, nic se neděje, ale dělat to pro produkční systém vidím jako zbytečné.

501
Sítě / Re:Síťovka blokuje port - může?
« kdy: 19. 01. 2021, 00:52:43 »
port 5900 je vnc, není v biosu zapnutý něco jako vzdálený přístup? Tenhle systém obsahuje funkci vzdálené správy (myslím, že Intel AMT či něco takového).

Samotné blokování je nepravděpodobné, spíše to někdo "krade".

502
Studium a uplatnění / Re:Pohovory po letech freelance
« kdy: 16. 01. 2021, 21:33:05 »
Ještě by mě zajímalo...

Denně mi chodí průměně 2 nabídky práce na linkedinu - většinou od agentur... má nějakou výhodu nebo smysl jít přes ně, nebo je lepší odpovídat přímo firmě na nějakých pracovních portálech?

Má smysl psát do firem, které zrovna nikoho nehledají, ale líbilo by se mi v nich pracovat? 

Díky

do řady velkých firem se jinak než přes agentury nedostaneš, nenabírají přímo a chtějí, aby jim to někdo protřídil dopředu.

Do malých je lepší napsat, oslovit je, klidně se nabídnout. Za mě, vypsání pozice na web je strašně dlouhá cesta od doby, kdy si tým uvědomí, že mu někdo schází. Občas se stane, že tě osloví později až jim někdo odejde, je dobré jim s průvodním dopisem dát i povolením, že si mohou kontakt nechat pro budoucí potřeby.

503
Studium a uplatnění / Re:Pohovory po letech freelance
« kdy: 15. 01. 2021, 17:09:42 »
typy otázek hodně odpovídají znalostem toho, kdo ten pohovor s tebou vede, bohužel moc univerzálních způsobů jak ověřit způsobilost uchazeče není a ani ve velkých společnostech není proces jednotný.

Jestli neumíš popsat stromové struktury, komprese nebo určit asymptotickou složitost, nedělej si z toho hlavu, buď ta pozice opravdu není zatím pro tebe nebo můžeš být rád, že v takové firmě pracovat nebudeš.

Neboj se na otázky občas odpovědět, že nevíš nebo že jsi nejsi jistý. Nemusíš odpovědět na vše a znát úplně vše. Často dávám otázky jen kvůli tomu, aby se mi uchazeč vlastně rozpovídal o tom co dělá, jak k práci přistupuje, s čím se setkal, co řešil, co umí. Někdy můžeš mít znalosti/zkušenosti, které se jim do týmu hodí a přitom je nenapadne se zeptat.

Určitě bys měl zvládat základy práce s IDE, s gitem, umět se pohybovat v githubu/gitlabu, u frontendu měl nějaké představy nástrojích jako babel, webpack, ale je jedno, jestli zrovna ujíždíš na swc nebo tě to minulo. Když znáš jeden z těch nástrojů, další se rychle doučíš. Osobně bych třeba zvažoval, jestli do týmu vzít člověka, který neumí git/svn/cvs a nepracuje s verzováním, pak by totiž mohl mít problém vůbec začít spolupracovat v týmu.


504
Studium a uplatnění / Re:Pohovory po letech freelance
« kdy: 15. 01. 2021, 09:58:20 »
... jelikož dělám v hodně jazycích takže si prostě nepamatuju syntax a hodně věcí googlim, ikdyž kódu 100% rozumím.

To je hodně častá (a blbá) výmluva. Také dáváme na pohovoru kandidátům malý příklad na nějaký algoritmus (mohou používat IDE s IntelliSense), ale základní syntaxi jazyka bys měl ovládat i bez IDE.

Když na pohovoru nevíš, jak se v daném jazyku deklaruje proměnná, pole nebo funkce, případně nevíš jaká je syntaxe for-cyklu, těžko se věří, že s jazykem aktivně pracuješ. Tím pádem budeš mít spíše povrchní znalosti a i když cizí kód přečteš, vůbec to neznamená, že bys ekvivalentní kód byl schopen napsat.

ono se to opravdu plete, zejména, když se na pohovoru zeptají na jazyk, které nebyl v požadavcích nebo naopak chtějí trochu jinou verzi než v které člověk dělá.

Na tom, jestli umí napsat kód z paměti bych nelpěl, lidé bývají na pohovoru nervózní, zbytečně se stresují, že neumí kód správně a neumí se na to často povznést, programování je z velké části o algoritmizaci, schopnosti problém rozložit na elementární komponenty programovovacího jazyku, frameworku, správně pochopit logiku okolního kódu. Nachytat někoho, že neumí přesnou syntaxi je strašně jednoduché, já raději dávám vytištěný kód a ať mi uchazeč o něm něco poví, ať řekne co dělá a jak funguje, když potřebuji vědět do jaké míru kód umí.

Čau všichni,

Dva roky dělám freelance full-stack developera se zaměřením hlavně na front end - React, Next.js, Gatsby, Jamstack. Předtím jsem dělal 2 roky jako junior frontendak. Už mě nebaví se pořád dohadovat s klientama a trávit půlku času jen komunikací s nima, tak bych rád zkusil zase štěstí někde ve firmě (lokalita Brno).

Chtěl bych se zeptat, jestli tu někdo ví, jak to na pohovorech na front-endaka tady v česku probíhá. Do první práce jsem se dostal na poprvé a bez tecnickýho pohovoru a další zkušenosti nemám. Je mi jasný, že to je firma od firmy, ale mám trošku hrůzu z whiteboardingu případně psaní kódu z fleku někde jako test, jelikož dělám v hodně jazycích takže si prostě nepamatuju syntax a hodně věcí googlim, ikdyž kódu 100% rozumím. Četl jsem strašidelný příběhy z pohovorů, kdy se ptají na věci, který vůbec nesouvisí s následnou prací apod.

Máte někdo zkušenosti? Díky.

Nejlepší je, když si na pár pohovorů půjdeš, obsah i forma bývá různá. Někdy tě vzpovídají o technických věcech, někdy ti dají příklad na vypracování dopředu, někdy se tě ptají jen na minulé projekty. V zásadě se vždy mrkni na technologie v požadavcích a osvěž si je, otázky na to určitě padnou, stejně tak se podívej na tu společnost, co dělá, jaké produkty má, vždy to druhou stranu potěší, když víš kam vlastně na pohovor jdeš.

Každý to ale dělá úplně jinak. Osobně u juniorů či méně zkušených (což jsi asi ty) se ptám na jejich zkušenosti, které technologie je zajímají, v čem a jak dlouho dělali, co bylo jejich úkolem a náplní práce, nesnažím se najít jejich technické limity, ale spíše zjistit přístup k práci.

506
Software / Re:Dohledový systém
« kdy: 10. 01. 2021, 15:42:06 »
nagios, zabbix, icinga2 velice dobře slouží k takovémotu obecnému monitorování všeho. Nové věci jako Prometheus/Grafana/Kibana/Kafka/Logstash nasazujeme poslední dobou vedle toho a slouží velice dobře, pokud potřebuji notifikovat, korelovat a sledovat různé události v čase na sobě závislé a pak podle složitých pravidel dávat vědět na různá místa podle závažnosti (ala IDS/IPS/SIEM), stejně tak se hodí velká flexibilita ve sběru různých metrik z různých zdrojů vč. aplikačních dat a to vše v distribuované podobě. Připravené dashboardy a grafy jsou fajn, ale zpravidla si stejně všude potřebujem vytvořit vlastní, je skvělé pokud je možné spojovat metriky z více zdrojů a pohledů vč. hodnot z logů.

Je těžké říct, který ten systém je nejlepší, když každý je k něčemu jinému. Sebelepší systém se mi může rychle rozpadnout, pokud potřebuji monitorovat virtuální stroje (či dnes dockery) s jepičím životem a vázat metriky do nějakých velkých logických celků podle oddělení nebo aplikace. Pak se láme chleba, někdo na to je horší, někdo lepší.

Stejně tak může být rozhodující, jestli si chci tvořit historii i rok zpátky, jestli chci snižovat časem granualitu dat, jestli potřebuji mít možnost nastavit retenci a granualitu pro každou metriku zvlášť, opět je to pro některé nástroje nativní (influxdb) a pro některé neřešitelný.

507
Software / Re:Dohledový systém
« kdy: 08. 01. 2021, 11:46:24 »
Pavel Rauš: používáš centreon ve free nebo placené verzi? Mně ta free připadá výrazně omezená na konfiguraci, chybí tam spousta užitečných funkcí, v placené verze to je ale výtečný nástroj a rád s ním dělám

U icinga2 jsem byl z prvnu nadšený z Directoru, vše se nakliká, ale pak vlastně člověk ztratí přímou vazbu mezi monitorováním a konfigurací. Spousty textových souborů, které mohu generovat externě ze systému podle šablon zase také nejsou k zahození, dá se nad tím dobře dělat review, dobře to verzovat, sdílet. Je to na osobní preferenci.

Prometheus + Grafana jsou hodně nenažrané a problémové, grafana vše renderuje z primárních dat až na frontendu, pokud chci dlouhé časové osy musím ručně vytvářet vlastní metriky přes agregace rovnou na backendu, to je takové neomalené. Jako malé řešení a rychlý start to je ale poměrně solidní. Grafy na jejich marketplace jsou spíše pro inspiraci než pro použití.

Člověk pak zjistí, že umírající naogis a ve spolupráci s cacti je vlastně pořád dobrá a příjemná volba, zejména pokud to znáš. Řada těch nových nástrojů mají super lazy webové ui, takže nelze rychle scrollovat přes grafy, spotřebu prostředků větší než aplikace, které monitorují a na konfiguace je čím dál častěji vysvětlena na youtube místo v textu.

508
ano, sesumírovali to v https://www.php.net/manual/en/migration80.incompatible.php, konečně kontrolují jestli druhá strana je číslo. Kromě toho se opravil i dlouholetý problém s 0 == strcmp. Od php 8 krom toho hash_equals akceptuje jako vstup pouze string, tím zamezí problémům typu předání v postu/get pole.

To nic nemění na tom, že hash_equals tady je od 5.6 a je právě určen pro porovnávání tokenů a hashů, bude na tenhle use case testování, zamezuje řadě jiných útoků, nejen chybnému přetypování.

Time attack je třeba pěkně vysvětlen tady https://blog.ircmaxell.com/2014/11/its-all-about-time.html, to jen pro ilustraci, že i === nemusí být vždy bezpečné.


509
protože:
Kód: [Vybrat]
> var_dump(0 == "0e48a24b70a0b37653552b996af51739");
bool(true)

hash_equals pak brání i dalším útoků typu timing attack.

510
Software / Re:Dohledový systém
« kdy: 06. 01. 2021, 18:27:21 »
grafana je ksicht pro zobrazení historických metrik, nemá ale uložiště, tím je třeba prometheus (či výkonnější victoriaMetrics) a jsme vlastně u mé první odpovědi :).

K zjišťovaní trendů potřebuješ historii. Zabbix + grafana + prometheus + prometheus alertmanager je pěkný stack, často ho nasazuji do menších projektů, umí to monitorovat vše, sestavit se to dá rychle, konfiguruje se to dobře přes ui, api i staticky textovými konfigy.

Další možnost je pak věci kolem influxDB, dříve jsem je měl rád, dneska jim nerozumím. Nagios pořád ale patří mezi špičku a není na něm nic zlého, když ho umíš.

Stran: 1 ... 32 33 [34] 35 36 ... 47