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 - starosta

Stran: [1]
1
Server / Re:Kdy a proč využít Docker nebo více serverů?
« kdy: 26. 04. 2023, 20:15:57 »
Myslím, že vím co se chce, asi jsem to měl více rozepsat nebo to takto neuvádět bez kontextu.
Stávající systém běží v cloudu, garanci mají 99,99 %, v noci se dělá snapshot celého serveru, jsou k dispozici 2 po sobě, databáze je replikována na jiný server v jiném geografickém umístění. Kdyby ten virtuál klekl a nešel ani spustit, tak spuštění ze zálohy otázka minut a dosypání dat z repliky je na pár desítek minut. Takto to funguje, vyhovuje to a nový systém bude podobný. Nakonec my takovou spolehlivost negarantujeme, při aktualizaci Windows jednou za měsíc stejně na pár minut až desítek minut nejede, než se restartuje. To není problém, je to o víkendu a v noci, kdy je relativně klid.

Těch 10 sekund uvedu na příkladu - když byl před léty systém několik hodin přetížený, tak odezva databáze byla třeba 10-20 sekund. A protože na ten server komunikují desítky jiných systémů a stále něco požadují, tak ty odpovědi trvaly a začalo to vadit.
A to je v podstatě to, čemu bychom chtěli předejít. Takže třeba web bude ukládat do hlavní DB a číst z repliky. Kdyby se stalo, že web bude vyčítat takové množství dat, že DB přetíží, tak to až tak vadit nebude, hlavní DB pojede dále.
Další věcí je zvýšení bezpečnosti, kdy nyní máme vše na jednom serveru, což nějak necítím jako dobré řešení. V neposlední řadě jde například o lepší způsob aktualizace jednotlivých částí, bez větších výpadků. Např. DB se musí zastavit, aktualizovat, spustit, migrovat atd. a to nějakou dobu trvá. Kdyby byly 2 DB servery v dockeru, spustí se replikace na novou verzi a pak se to jen přepne - skoro bez výpadků.
A nakonec chceme použít Keycloak a ten je výhodné provozovat v Dockeru, novou verzi si připravíme mimo, spustíme kontejner a přepneme.

Když se vrátím k prvnímu postu, tak mi fakt jde o zorientování se v tom, kdy třeba použít docker a na co více virtuálů.
Už hledám DevOps konzultanta.

2
Vypni v biosu IOMMU.
Zkoušel jsem, pád ihned po spuštění skriptu.

Když jsi to řešil s podporou FTDI, tak přepokládám první co zjišovali bylo jestli nemáš nějaký fake chip.
O tomhle vím, problém byl s ovladači ve Windows, v Linuxu ne. FTDi chipy používáme mnoho let, kupujeme je od oficiálních dodavatelů, v provozu máme stovky kusů. V tom to není. Na stejném AMD HW to s Windows funguje, na jiném Intel HW ten samý kus ve Win i Linuxu také. Je to asi něco v XHCI driveru v kernelu.

3
Ještě se k tomu vracím, nemohl jsem se přihlásit do fóra.
Včera jsem to zkoušel na jádře 5.1 na Ubuntu serveru a problém je stejný, systém spadnul po několika sekundách.
Kernel log: https://paste.ee/p/EmLsw

Přihlásil jsem se do mailing listu linux-usb, tak snad to někam povede.

4
Dobré dopoledne,
obracím se na místní zkušené uživatele Debianu, potažmo jiných distribucí s dotazem. Mám problém s převodníkem "USB to serial" od FTDI typ FT232R na Debianu. Při vyčítání obsahu EEPROM dojde k chybovým výpisům do "kern.log" a nakonec pádu systému.
Abychom vyloučili problém v našem programu, využili jsme příklady čtení EEPROM v ovladačích FTDI a s nimi se to děje taky.

Detailní popis testu. Mám tuto konfiguraci:
1) Hardware
- základní desky s chipsetem AMD A320M - MSI A320M PRO-VD PLUS, ASUS PRIME A320M-K, GIGABYTE A320M-S2H
- poslední biosy, natáhnutá defaultní konfigurace
- CPU AMD Athlon 200GE nebo AMD Ryzen 3 2200G
- 4GB RAM, SSD disk Kingston A400 120GB
- USB to serial převodník s FT232R https://www.ftdichip.com/Products/ICs/FT232R.htm

2) Operační systém
- Debian Linux 9.6 64bit, instalován z Netinst bez grafického desktopu, výchozí konfigurace
- kernely 4.9.0.8-amd64, 4.18.0-0.bpo.1-amd64

3) Ovladače
- libftd2xx drivers verze 1.4.8, https://www.ftdichip.com/Drivers/D2XX.htm

4) Provedené testy na Debianu
- připojit FT232R do portu USB2.0 (ne do portu USB3!)
- použít příklad z adresáře: ...\libftd2xx-i386-1.4.8.tar\release\examples\
- přidat parametr "-m32" do proměnné "CFLAGS" v souboru "Rules.make"
- zkompilovat "\examples\EEPROM\user\read\"
- spustit "test.sh"
Debian Linux spadne po pár minutách.
Mezitím vypíše do "kern.log" mnoho chybových výpisů a postupně tuhne: https://paste.ee/p/xxIZ2

5) Důležité poznámky
- tento problém nastane pouze pokud je FT232R připojen do portu USB2.0, pokud je připojen do portu USB3, žádné chybové výpisy se nekonají a vše funguje bez problémů
- zkusili jsme Ubuntu server 19.04 - výchozí instalace, kernel 5.0.0 - stejný problém na USB2.0. jako s Debianem
- pokud na stejném hardwaru spustím Win10 + nejnovější ovladače, vše funguje bez problémů v USB2.0 i USB3
- pokud stejný test udělám s Debianem 9.6. na platformě Intel, deska MSI B250M PRO-VH, CPU Intel Pentium G4560, 4GB RAM, SSD drive Kingston A400 120GB, vše funguje bez problémů v USB2.0 i USB3


Řeším to asi 5 měsíců s podporu FTDI, ale nikam to nevede. Napřed se nic nedělo, pak nemají HW, pak nemají čas, na moje PC se nechtějí připojit, pořád nějaké výmluvy.

Nedokážu úplně určit, kde je problém, ale tipuji v ovladači xhci_hcd v kernelu. Dokáže mi někdo s tímto poradit? Případně kam se obrátit a problém nahlásit? Děkuji.

Stran: [1]