Příspěvky

76

Server / Re:Domácí ústředna a vzdálené ovládání SIM karty

« kdy: 14. 04. 2021, 14:03:47 »

Jde to i bez vlastního serveru a mnohem levněji.  Náklady méně než 50 USD na SIM. (je možné koupit čtyřportovou nebo osmiporotovou GSM bárnu - např. https://www.aliexpress.com/item/1005001506959516.html .
Jak to nastavit je popsáno zde. http://forum.odorik.cz/viewtopic.php?f=14&t=4364
Zbývá ale dořešit SMS s tím nemám zkušenost, ale určitě to jde. Je to dobře škálovatelné.
Přesměrovat hovor tak, aby bylo zjevné na kterou sim se volalo jde tak, že si hovor nepřeměrujete na k tomu orčené běžné nebo nomadické číslo u Odorik.cz. To si teprve můžete přesměrovat na mobil, ale tak,  že se při zdvihnutí přidá hláška, která vás informuje které číslo bylo použito.
Problém je ale u SMS, které nelze přesměrovat.

77

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

« kdy: 01. 04. 2021, 11:08:56 »

nejde ale o problém ztráty jednoho řádku, ale ztráty celých datových souborů se spoustami řádků, nikdo pak nedokáže říct, co tam vlastně bylo a jak. Stejně tak při poškození ti to může vracet jiné hodnoty. MyIsam používá takovou divnou binární strukturu, kdy v souboru .frm je uvedena struktura tabulky, jednotlivé sloupce mají své flagy, poté v .myd jsou je uveden flag sloupce a poté binární obsah a takhle pořád dokola. Pokud se něco poškodí, část dat zmizí nebo tam vznikne jiná chyba, nemáš moc záchytných bodů jak poznat od sebe samotná binární data a struktury. Je možné se tím snažit ručně nějak projít a najít bod, kdy se to začalo rozbíjet, ale je to obrovsky těžké, už u desítek společností jsem se snažil z toho vydobít kritická data. Dělej zálohy a nespoléhej na to, že se to nerozbije. U dlouho běžících systémů bez ECC lze pozorovat i chyby, které způsobují chyby paměti.

ECC máme. Jinak asi máme štěstí, že jsem nikdy nic takového zatím neviděl. Jediné co se někdy stalo, je když se zkopíruje tabulka za chodu (soubory tabulky), nebo vypadne elektřina, musí se daná tabulka opravit. Po opravě žádné viditelné poškozených jsem niky neviděl. Jinak zálohovat se musí vždy.Kromě nočních záloh (prosté rsync) máme několik clonů.

78

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

« kdy: 31. 03. 2021, 14:00:05 »

No kdybych to celé dělal znovu, tak samozřejmě použiji už inodb, ale databáze se zakládala před patnácti lety. Ale jelikož potřebujeme dostupnost 24/7 tak se mi  do přechodu z lety osvědčeného myisam moc nechce.
Rozumím tomu, že konzistence dat např. u účetnictví je naprosto zásadní, ale pokud nezaúčtuji nebo ztratím např. jeden hovor z deseti milionů, tak to žádný zásadní problém není. Ale ani s tím jsem se nesetkal. Pro některé aplikace, např. logování je fakt jedno jestli použijete myisam nebo inodb.
Předpokládám, že overhead kvůli zfs bude zanedbatelný, za to snadné stěhování virtuálů z jedhoho fyzického stroje na jiný si myslím, že to stojí. Hlavně to mít vždy možnost spustit to stejné na záložním stroji.

Pro toho kdo si může dovolit alespoň noční nebo ještě lépe víkendové odstávky jsou samozřejmě priority jinde.

79

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

« kdy: 31. 03. 2021, 10:45:18 »

Já jen kroutím hlavou nad tím, že někdo raději koupí dražší hardware jen kvůli tomu, aby měl potenciálně stejný výkon na ZFS jako předtím na ext4. Kdyby bylo složité MySQL zálohovat tak neřeknu, ale tohle mi připadá jako strkání hranolu do kulatého otvoru.

No těch serverů máme hodně. A hlavní databáze musí jet 24/7 bez výpadků. Díky snapshotům je stěhování podstatně jednodušší než dělat z repliky hlavní stroj. Je to prostě příliš složité než aby se neukázal nějaký zádrhel. Chci hlavně jednotný způsob stěhování pro všechny virtuály.
A také se mi nechce věřit že by ten rozdíl byl až takový. S novým strojem budu moci udělat nové testy a hledat proč je rozdíl tak velký.

Na zalohovani (a pripadnou migraci dat) zive MySQL neni potreba zastaveni databaze a ani bezici replika. Staci pouzit nastroj k tomu urceny - xtrabackup.

My používáme stále zastaralou myIsam, který zdá se má jedinou podstatnou nevýhodu v tom, že jeden select může někdy zamčít celou tabulku. To řešíme tak, že náročnější, ale méně důležité čtení provádíme z clonů. Jinak pro naše použití má mírně vyšší výkon než innodb.  Výhoda je, že zálohu je možné provést obyčejným rsync. Pokud chci mít jistotu, že nebudu muset opravovat nějakou tabulku, tak mohu na pár vteřin umělě tabulky zamčít a poté provést rsync znovu. ZFS snapshot je rychlejší a spolehlivější a zamčení tabulek se tak počítá na milisekundy a lze tedy udělat i za plného provozu.
Jinak používáme  klonování, tedy provést kopii celé databáze je potřeba jen naprosto výjimečně právě pro nastartování klonování. Pak už stačí provádět zálohy z klonu, který se může zastavit i na dlouhé hodiny, protože to poté dožene.
ZFS je ale dobré v tom, že může v pravidelných intervalech (třeba i jednou za 5 minut) dělat zálohu celého serveru, který pak stačí prostě spustit někde jinde s tím, že se přijde o data maximálně za 5 minut. (ale i ty bychom patrně našli v klonech, takže oni to ne). A hlavně, přes ZFS lze takto zálohovat libovolný virtuál  nejenom databázi.

S innodb jsme experimentovali a jednou se nám stalo, že se data natolik poškodila, že se z nich nedalo vyčíst vůbec nic. To se myisam nestane.

S xtrabackup nemám zkušenost.

80

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

« kdy: 28. 03. 2021, 22:20:45 »

Bohužel tyto vlastnosti ale prodejci neinzeruji?

Ale inzeruji a to zcela zretelne Pro podobny typ zateze je treba vybirat mezi disky oznacenymi jako "serverove", "enterprise", "pro datova centra" apod. (a taky jim pripadne zajistit radne chlazeni.)
https://www.czc.cz/pevne-disky-do-serveru/produkty?q-c-0-f_94358671=sSSD
https://www.mironet.cz/pevne-disky-a-ssd+fc14401/?pn11473%5B%5D=Intern%C3%AD&pn11038%5B%5D=SSD&pn11037%5B%5D=Intern%C3%AD%20-%20Server
atd.

Mimochodem, hned druha reakce v tomto vlakne byla "Co je to za SSD?". Takze tak.

Nikde nepíší o tom, že při použití trim reálná rychlost zápisu náhodně skáče mezi uváděnou rychlostí a rychlstí  30 krát nižší. A pokud trim není použit tak plná rychlost zápisu vydrží jen v desítkách vteřin a pak je třicetinásobně nižší. Tohle je podstatný údaj totiž i pro běžné uživatele bez serveru, i když i vzhledem k ceně se může rozhodnout že  mu to nevadí.
Když SSD disky začínali, koupil jsem i nějaké profi serverové, ale byli více poruchové než ty obyčejné Kingstony, které bez problému fungují doposud.

81

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

« kdy: 27. 03. 2021, 22:21:48 »

Ještě dodám, že ony problémové disky jsou Kingston Now A400, 2,5" - 480GB
https://www.czc.cz/kingston-now-a400-2-5-480gb/213704/produkt
Zkusil jsem začít používat trim, ale výsledek byl, že ono třicetinásobné zpomalení začalo být více náhodně. Celková rychlost ale byla zdá se poté trochu lepší. Nicméně databáze si nemůže dovolit zničehonic třicetinásobně pomalejší zápis. A pokud je to náhodné, je to snad ještě horší, protože i při menším množství zapisovaných dat se tohle zpomalení může vyskytnout v tu nejméně vhodnou chvilku.

82

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

« kdy: 24. 03. 2021, 22:23:36 »

Z toho vůbec nejsem chytrý. Vypadá to jako by pro zápis malých bloků nebyly SSD vůbec nějak výrazně rychlejší?

Nedaří se mi to najít...

Tak bylo to tady:
https://forum.root.cz/index.php?topic=21870.0

Díky moc. To bude přesně ono. Tedy důvod je ten že dnešním levným SSD diskům při delším zápisu za chvilku dramaticky klesne (až třicetinásobně) rychlost, protože dojde rychle zápisová cache. Při testech je to vidět. SSD disky co jsem kupoval tak před 8 lety byly sice v té době mnohonásobně dražší, ale i když měli papírově rychlosti úplně stejné jako dnes, tohle zpomalení neměli.  Rychlost zápisu byla po celou dobu konstantní a fungují nám na serverech stále k plné spokojenosti. Proto jsem neviděl důvod, proč kupovat něco jiného. Prostě dnešní low end SSD disky nejsou vhodné na déle trvající zápisy. Což ale u běžného použití na starém notebook není úplně typické použití (větší instalace se dělá jednou a na filmy je ssd škoda, když mohu použít původní disk) a proto to až tak nevadí.
Dnes je asi lepší koupit nějaké lepší M.2 disky, které nejenom že by měly být zase několikanásobně rychlejší, ale rychlost by jím neměla při déle trvajícím zápisu výrazně klesat. Bohužel tyto vlastnosti ale prodejci neinzeruji?
 ZFS je zdá se nevinně, tam při dobrém vyladění máte rychlosti podobné jako u ext4, při špatném třeba poloviční, ale není to násobek.

83

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

« kdy: 23. 03. 2021, 08:31:19 »

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ů?

84

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

« kdy: 21. 03. 2021, 17:54:57 »

Jasně, T-Mobile dostane pokutu za to, že já mám ve své soukromé databázi na disku u jejich IP adresy uvedenu Austrálii.

Ale samozřejmě že to ovlivnit může a měl by. Viz má reklamace lokality ip adresy u nej.cz .
Všechny ti poskytovatelé obsahu pro které je lokace důležitá určitě čerpají z více různých zdrojů. Tedy nemluvte o soukromé databázi u někoho na disku.

85

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

« kdy: 21. 03. 2021, 17:48:49 »

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/

86

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

« kdy: 21. 03. 2021, 16:55:20 »

Podle mě by se o tohle měl starat poskytovatel internetu.

Co přesně nechápete na tom, že těch databází je spousta, neexistuje žádný jejich seznam, tudíž poskytovatel internetu nemůže tušit, kde by to měl změnit? Co když jsem si já teď začal takovou databázi tvořit, mám ji u sebe na lokálním disku? Jak se o ní má T-Mobile dozvědět, aby mohl řešit nějakou změnu?

Mezitím můžete zkusit reklamaci provést i u poskytovatele obsahu, ale není to zrovna efektivní, protože těch může být více.

Databází IP adres je také více. A jenom poskytovatel obsahu ví, kterou databázi používá.

Je otázka jestli ono odmítání T-mobile není jen selhání jednoho člověka.

Není to selhání T-Mobile, T-Mobile s tím nic dělat nemůže, protože netuší a nemůže tušit, ve které databázi třetí strany je chyba.

Od toho je tady ČTÚ aby posoudil jestli je to selhání T-mobile. Dost možná nazná že ano, protože je nyní více prozákaznicky orientovaný. Po všech koncových zákaznícich nemůžeme chtít aby obesílal všechny své poskytovatele obsahu. To je myslím dostatečný argument. A jestli bude drzá možná dostane i pokutu. Těch hlavních databázízase tolik není a poskytovatel by měl vyvinout přiměřené úsilí. Menší poskytovatelé s tím nemají problém a pokud je někdo arogantní, zaslouží si přes prsty.

To je jako by tvrdil, že jej nezajímá, že jeho ip adresy jsou dostupné jen někdy a od někud, že to není jeho chyba a problém.  Pro reklamaci na ČTÚ je potřeba reklamovat poslední vyúčtování s tím že chci slevu za omezenou službu. Je třeba mít písemně, že to zamítá. Tohle se pak pošle na ČTÚ a ten rozhodne.

87

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

« kdy: 21. 03. 2021, 15:38:34 »

Podle mě by se o tohle měl starat poskytovatel internetu. Přece nemůžete chtít po všech zákaznících z problémového rozsahu, aby kontaktovali všechny poskytovatele služeb. Mnohem efektivnější je když se o opravu postará poskytovatel internetových služeb, protože to může udělat po celých blocích.  Podstatné je dokázat, že problém má více různých poskytovatelů obsahu a problém není běžný a řešení přes poskytovatele internetu je nejefektivnější, protože jedině on ví kde své adresy zkutečně používá. Z čeho by mohl mít respekt, je reklamace na ČTÚ a požadování významné slevy za takový polovičatý internet.
To že je T-mobile velký nutně neznamená, že mu arogance projde.
Mezitím můžete zkusit reklamaci provést i u poskytovatele obsahu, ale není to zrovna efektivní, protože těch může být více.

Je otázka jestli ono odmítání T-mobile není jen selhání jednoho člověka. Pracují tam někdy lidi, že by jeden brečel.  Vím o jedné příhodě, když člověk reklamoval, že se nemůže z mobilu dovolat do jedné jihoamercké země, tak pracovník pobočky radil tam přidat jakýsi prefix před číslo  a  volat tedy do Mongolska Na to už pak člověk nemá co říct. Prý to naše na googlu a je tak invoativní.

88

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

« kdy: 21. 03. 2021, 15:29:43 »

Podle mě by se o tohle měl starat poskytovatel internetu. Přece nemůžete chtít po všech zákaznících z problémového rozsahu, aby kontaktovali všechny poskytovatele služeb. Mnohem efektivnější je když se o opravu postará poskytovatel internetových služeb, protože to může udělat po celých blocích.  Podstatné je dokázat, že problém má více různých poskytovatelů obsahu a problém není běžný a řešení přes poskytovatele internetu je nejefektivnější, protože jedině on ví kde své adresy zkutečně používá. Z čeho by mohl mít respekt, je reklamace na ČTÚ a požadování významné slevy za takový polovičatý internet.
To že je T-mobile velký nutně neznamená, že mu arogance projde.
Mezitím můžete zkusit reklamaci provést i u poskytovatele obsahu, ale není to zrovna efektivní, protože těch může být více.

Je otázka jestli ono odmítání T-mobile není jen selhání jednoho člověka. Pracují tam někdy lidi, že by jeden brečel.  Vím o jedné příhodě, když člověk reklamoval, že se nemůže z mobilu dovolat do jedné jihoamercké země, tak pracovník pobočky radil tam přidat jakýsi prefix před číslo  a  volat tedy do Mongolska Na to už pak člověk nemá co říct.

89

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

« kdy: 21. 03. 2021, 14:07:22 »

Tak jsem zjistil, že zfs umí O_DIRECT až od verze 0.80 . Zato stable debian buster používá (modinfo zfs | grep version) 0.7.12 . Vypadá ale, že instalovat nejaktuálnější verzi je jednoduché, stačí přidat repozitář buster-backports .
https://packages.debian.org/buster-backports/zfs-dkms
Vzhledem k tomu, že ze ZFS tak dlouho bez onoho DIRECT obešle, je ten O_DIRECT opravdu důležitý? Nikde jsem nenašel článek o tom jak je ZFS kvůli absenci O_DIRECT nevhodný pro databáze.
Zde jsou nějaké informace k O_DIRECT na zfs. https://github.com/openzfs/zfs/pull/7823

Vzhledem k  tomu, že jsem zkusil už skoro vše, tak zkusit novější verzi ZFS dává smysl.

90

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

« kdy: 21. 03. 2021, 12:42:09 »

Já si naopak myslím, že T-mobile za to může.   Jednou jsem reklamoval špatné město u nej.cz a pomohlo to. Majitel ip adresy může databázi určitě aktualizovat.