reklama

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 - Miroslav Šilhavý

Stran: [1] 2 3 ... 127
1
Hardware / Re:Provoz racku s UPS na sníženou sazbu PRE
« kdy: 11. 09. 2019, 12:16:13 »
Ale jiste, vsak jsem psal ze mi jde o tech drahych 8 hodin denne....

Prosímvás, zapojte hlavu a počítejte.

Spotřebujete 300 W.
Za 16 hodin spotřebujete 4,8 kWh denně v nízkém tarifu.
Za 8 hodin spotřebujete 2,4 kWh denně ve vysokém tarifu.

Rozdíl mezi tarifem NT a VT je 0,32 Kč za kWh. (V sazbě D35d).

Takže se zde bavíme o úspoře 2,4 kWh × 0,32 Kč = 0,77 Kč denně.

Kdybyste měl UPS úplně zadarmo, jste schopný za rok ušetřit 281 Kč.

Opravdu myslíte Váš dotaz stále vážně?

2
Hardware / Re:Hot-swap disku k Odroid-H2
« kdy: 10. 09. 2019, 15:21:18 »
Co sa tyka instalacie ESXi, tak zatial to mam na spolocnom SSD 120GB, ale skusim si to preinstalovat na USB 3.0 snad to bude (co sa tyka rychlosti read/write) podobne

ESXi se instaluje klidně na pomalé USB, je potřeba jen při bootu, pak už to na něj nehrabe. Stačí 16 GB flash disk.

3
Hardware / Re:Hot-swap disku k Odroid-H2
« kdy: 10. 09. 2019, 14:23:50 »
Teoreticky by to jít mělo, ale v praxi si myslím, že to není příliš podporovaná a zkoušená cesta pod ESXi.
Samotné ESXi by mělo být instalované na nezávislém disku (tj. ne tam, kde jsou virtuálky) - využívá se na to např. SD-karta, USB flash disk (nutno doporučit průmyslovou odolnost), nebo třeba SATA-DOM.

Na úložiště je zase běžné, že se připojuje přes RAID řadič, který se o to postará (nebo ESXi nepodporuje žádnou variantu SW RAID). Na HW RAIDU se to provádí běžně, vytáhne se šuplík za chodu, vymění se za chodu. Druhá velmi běžná varianta je SAN a připojení přes iSCSI nebo FC.

Pokud nemáte šuplík a celou sestavu nastavenou na hotswap, podle mě riskujete, že se něco nezadaří a půjde to k zemi.

4
Hardware / Re:Provoz RACKu s UPS na snizenou sazbu PRE
« kdy: 07. 09. 2019, 21:01:21 »
neexistuje nejaky zpusob jak pouzit baterie, ale nemuset generovat ~220V ?
neexistuji napajeni desek, ktere z baterie primo vyrobi +12 V, + 5 V a dalsi napeti co jsou treba na zakladnich deskach.

Některé prvky - switche, routery, ..., mají vstup 48 VDC a v datacentrech bývají větve jak 230 VAC, tak 48 VDC.

5
Hardware / Re:Provoz RACKu s UPS na snizenou sazbu PRE
« kdy: 07. 09. 2019, 18:46:51 »
Ja netvrdim ze jsem prisel na neco prevratneho, jen me to napadlo a rad bych slysel nejake ZÁVAŽNÉ argumenty ze (a proc) je to pripadne blbost, nez to zacnu detailneji pocitat. je pravdepodobne ze jsem neco zasadniho prehledl.

1. ztráty při transformaci a usměrnění na 14,7 VDC
2. balastní teplo chemické reakce při dobíjení akumulátoru
3. ztráty při zestřídání DC=>AC a transformaci
4. nemožnost regulace účinníku (resp. naprosto neefektivní)
5. cena a životnost akumulátorů

Argument jsem Vám předložil: i reverzní franciska je účinnější, než ukládání elektrochemickou cestou.

6
Hardware / Re:Provoz RACKu s UPS na snizenou sazbu PRE
« kdy: 07. 09. 2019, 18:42:53 »
Ja bych to zkombinoval se solarem (den) a levnejsi proud (noc), typicky ten solarni system ma nejake baterie, protoze byva delan prave na dobijeni kdy slunce sviti (pokud se jedna o izolovany system, ne ten podvod s dotacema kde to pere rovnou do site)

Soláry i baterie mají trochu (velký) problém s kompenzací jalového výkonu, který je v síti potřeba. To značně snižuje hodnotu výroby takové elektřiny. Na běžné elektrárně se trochu přebudí generátor, a jalovina je na světě. Na soláru to moc nejde - tím značně klesá využitelnost, byť čisté kilowatthodiny vypadají slibně.

7
Hardware / Re:Provoz RACKu s UPS na snizenou sazbu PRE
« kdy: 07. 09. 2019, 17:25:46 »
Datova centra maji s distributory sjednany velkoobchodni ceny, proto se jim to nevyplati. Ja mluvim o standardnich cenikovych maoobchodnich cenach.

:) to je stále ta samá konspirační logika. Pokud by se vyplatilo ukládat energii v akumulátorech, už by to nejen u nás, ale i ve světě někdo realizoval. Je mi líto, ale per petuum mobile jste nevynalezl.

(Nebo jste se nechtěl zeptat, ale jen utvrdit v přesvědčení..?)

8
Hardware / Re:Provoz RACKu s UPS na snizenou sazbu PRE
« kdy: 07. 09. 2019, 16:50:08 »
Mnohem vhodnější bude LiPol nebo lepší, bezpečnější a dražší LiFePO4.

Jenže za UPS připojí jedině některý typ olověné - nejčastěji bezúdržbovou. Trakční je jen varianta olověné.

9
Hardware / Re:Provoz RACKu s UPS na snizenou sazbu PRE
« kdy: 07. 09. 2019, 16:39:03 »
Zapominate ze jsme v regulovanem prostredi, nikoliv na volnem trhu. Distributori kazdorocne dokladaji ERU sve naklady na distribuci, a ERU je zahrne do regulovane slozky ceny elektriny na dalsi obdobi.

Je daleko jednodussi proste dolozit regulatorovi naklady nez budovat bateriove stanice....

Já si to nemyslím. Kdyby ne samotný distributor, tak například datová centra by to zavedla. Vyjednala by si distribuční sazbu pro odběr v noci (á la distribuční sazba pro veřejné osvětlelní ) a energii by akumulovali. Ani distributoři, ani výrobci zatím nepřišli s ničím, co by bylo efektivní. Nejefektivnější jsou zatím přečerpávací elektrárny s reverzními francisovými turbínami, akumulátory se absolutně nechytají.

10
Hardware / Re:Provoz RACKu s UPS na snizenou sazbu PRE
« kdy: 07. 09. 2019, 14:33:32 »
Prvni otazka je zda se to vubec vyplati s ohledem na zivotnost baterek. Dalsi otazka je jak pripadne spocitat kapacitu pridavne baterky protoze PRE u tohoto tarifu negarantuje rozlozeni "mezer" v case behem dne. Jedine co garantuje je minimalne 5 zapnuti denne o delce minimalne 1 hodina.

Kdyby se to vyplatilo, měli by takové "UPS" samotní distributoři. V distribučních uzlech, nebo na koncích. (Většinu ceny elektřiny tvoří distribuce, nikoliv její výroba). Leč, nevyplatí se to.

...

A zcela jste zapomněl, že maximální kapacita baterií je omezená dobíjecími schopnostmi UPS. Za dobíjecí obvod UPS nemůžete posadit neomezené množství baterií.

11
Pokud se nepletu, tak je to tím, že obě (sub)domény běží na stejné IP adrese.
Prohlížeč už má navázaný CONNECT na cílovou IP adresu, takže v prvním kroku necítí potřebu navázat nový CONNECT.
Teprve v druhém kroku ověří, že sice CONNECT vede na stejnou IP adresu, ale Host (v SNI) neodpovídá. Proto potřebuje nové spojení, nový CONNECT.

Opravte mě někdo, pokud to chápu špatně.

12
EDIT: koukam, ze kolega Šilhavý to napsal prede mnou (mel jsem to tu dele otevrene)

To je jedno.

13
...

Pokud má oddělený SQL server smysl, pak je to jedině v tom, že dotazy budou co nejkomplexnější a směřovat k tomu, aby co nejvíc početního výkonu převzal SQL server, ale zároveň bylo potřeba nejméně přenosového pásma. Pokud mezi PHP a MySQL serverm putuje příliš mnoho dat nebo příliš mnoho dotazů, oddělení serverů se nevyplatí. V prvním případě to zpomalí kapacita linky (1 Gbbps?), v druhém případě se nasčítají latence.

Bez měření se k tomu nedá nic víc říct.

14
Pokud umíte správně používat SQL, pak je rozdělení na místě - rozdělit dopředu, sloučit se to dá vždycky. Opačně se to dělá hůř.

Co se týče správného použití SQL, tak tam mám snad jen poznámku k tomu, že SQL se používá pro maximální optimalizaci práce s daty, a aby se přenášelo minimum dat - pak nevadí ani oddělený server. Bohužel, MySQL se dá optimalizovat jen velmi omezeně - spíš se používá na mnoho malých selectů než na jeden velký. V takovém případě se oddělení serverů projeví poklesem výkonnosti. (U ERP systémů není nic divného mít select na tři stránky, dvanáct joinů, pět subselectů apod., ale s tím Vám MySQL nepomůže).

Takže odpověď zní: při správném použití to smysl dává. Při nesprávném (které díky výběru technologií trochu předpokládám) to ubere na výkonu.

15
Software / Re:Konverze archivu ze zip do 7z
« kdy: 02. 09. 2019, 19:02:28 »
Tak tar asi taky nemusi nacitat .tar celý celý - to by odporovalo jeho použití na páskách, ne? Ale nevím, zda to funguje s kompresí.

Je to přesně tak. Tar+komprese je vlastně solid archiv, proto i tar+gzip komprimoval vždy lépe, než samotný zip.
Rar, pokud se pamatuji, přišel se solid archivem a taky s archivací podle přípony (na dosu), čímž docílil toho, že podobné soubory se komprimovaly blízko sebe a tím docílil lepší komprese - něco tak na čtvrtině cesty mezi kompresí a kompresí s deduplikací.

Archivátor s vnitřní deduplikací neznám, ale docela by to mohlo být zajímavé, jen by asi bylo těžké určit velikost bloku pro deduplikaci. Malý blok = hodně režie. Velký blok = menší šance zásahu.

Stran: [1] 2 3 ... 127

reklama