Příspěvky

3361

Server / Re:Nativní ZFS v Linuxu pozastavuje po zaplnění bufferu zápis na 8 TB disk

« kdy: 06. 03. 2016, 08:40:25 »

FreeBSD mi nesedlo

V čem ti nesedlo? Bude to pravděpodobně jenom nezvyk...

3362

Sítě / Re:Bootovani po siti (PXE) z iSCSI - Win7 BSOD

« kdy: 05. 03. 2016, 16:24:58 »

edit: to 4 melo byt, proc reagujes kdyz ne?

Protoze jsem ten prispevek napsal driv, nez jsi to poslal a uz se mi ho nechtelo upravovat.

3363

Sítě / Re:Bootovani po siti (PXE) z iSCSI - Win7 BSOD

« kdy: 05. 03. 2016, 14:52:40 »

4. kernel naběhne a dál dělá, co potřebuje - tj. zejména načte root FS a pak už normálně bootuje

Tady mělo být "načte root FS z místa B", přičemž A muže být s B totožné, ale nemusí. Například se může načíst kernel+initrd přes tftp a rootfs potom připojit přes NFS.

3364

Sítě / Re:Bootovani po siti (PXE) z iSCSI - Win7 BSOD

« kdy: 05. 03. 2016, 14:50:29 »

Nevím, jak je na tom Windows, ale obecně to funguje tak, že:

1. v ROM karty je kód, který umí přes TFTP načíst nějaký zavaděč
2. ten "nějaký zavaděč" umí z místa A načíst kernel + případně nějaký ramdisk a umístit ho do paměti
3. "nějaký zavaděč" takhle zavedený kernel spustí
4. kernel naběhne a dál dělá, co potřebuje - tj. zejména načte root FS a pak už normálně bootuje

...takže jak vidíš, to, že ti začne (jakýkoli) OS bootovat, je stádium 3 a vůbec to ještě neznamená, že ten OS umí z iSCSI nabootovat. Musí totiž 1. umět načíst rootfs z iSCSI, 2. musí ho umět přimountovat a bootovat z něj.

Jestli to Windows umí nebo neumí, to nevím, ale silně o tom pochybuju a že ti to začalo bootovat neznamená, že to umí.

3365

Sítě / Re:Jak propojit dvě serverovny do LAN?

« kdy: 05. 03. 2016, 14:44:42 »

A jak jste doteď řešení hledali, že jste nenašli VPN? Nebo něčím nevyhovuje? Pokud ano, čím?

3366

Vývoj / Re:numpy extract s podmienkou

« kdy: 05. 03. 2016, 11:11:42 »

Jo a ještě možná důvod, proč nepoužít dataframe se sloupci r, g, b, alpha, se kterým by se ti pracovalo asi vůbec nejlíp.

3367

Vývoj / Re:numpy extract s podmienkou

« kdy: 05. 03. 2016, 11:08:43 »

Mohl bys uvést kompletní self-contained příklad pro obrázek řekněme 2x3? Tj. přiřazení všech hodnot, ukázku, co děláš a v čem se ti to nedaří? Plus možná nějaký krátký komentář, jaký máš důvod používat vícerozměrné pole - máš konkrétní důvod, proč nepoužít

Kód: [Vybrat]

alfa[(row*ROW_LEN)+col] 

?

3368

Studium a uplatnění / Re:Proč tolik matematiky?

« kdy: 04. 03. 2016, 18:16:28 »

Spíš bych očekával, že tímhle směrem budou hodně šlapat, dobře to propojí se svými mainframy, budou podporovat hybridní řešení s nějakým tím LinuxOne u zákazníka... ...a bude to docela hezká věc.

No... a už tady máme přesně tohle řešení nejen od IBM, ale i od SuSE: http://www.enterprisetimes.co.uk/2016/03/04/suse-targets-private-cloud-with-openstack-6

3369

Server / Re:Nativní ZFS v Linuxu pozastavuje po zaplnění bufferu zápis na 8 TB disk

« kdy: 03. 03. 2016, 21:07:27 »

Ok, mohu zkusit zápis náhodných dat na blokové zařízení na kterém je nyní ZFS. Napřed bych zazálohoval třeba 10 GB na jiný disk, přepsal je náhodnými daty a pak původní data vrátil. Tím by se předpokládám nemělo nic stát, když to zařízení nebude používané a dám si pozor na to, co zadávám za parametry. Co zkusit dál pokud zjistím, že ta rychlost je podstatně vyšší a hlavně plynulá?

No to je hodně velká prasárna. Můžeš to udělat, pokud 1. tam nemáš data, na kterých ti záleží, 2. budeš přesně vědět, co děláš, 3. nebudeš to dělat na "klidném", ale na úplně odpojeném FS, to znamená "zpool export ...". Každopádně ale potřebuješ vyzkoušet i ty další vrstvy.

Jak bych prosím mohl zjistit?

LUKS jsem nikdy nepoužíval, takže přesnou radu nechám na kolegy. Obecně musíš mít podporu AES-NI v jádře (měla by být běžně) a LUKS musí používat šifru, kterou AES-NI podporuje.

Představme si [...] Představoval bych si, že data do plného bufferu půjdou přidávat stejnou rychlostí, jakou se z něj zapisují na fyzický disk.

Není tak úplně důležité, co si představujeme, ale jak to reálně funguje ZFS je dost složitá věc samo o sobě a ty mu tam přidáváš ještě dvě vrstvy navíc, takže jak se to reálně chová nejseš imho vůbec schopnej odhadnout.

Ok, tuto zkušenost respektuji. Chtěl bych se zeptat, připravuji se o nějaké jiné vlastnosti než jen výkon?

Připravíš se o všechny vlastnosti, které využívají toho, že ZFS ví, co jsou živá data, zatímco mdraid to neví. Čili stoprocentně si způsobíš to, že při výpadku bide probíhat resilvering celého disku, zatímco ZFS by resilverovalo jenom živá data.

Předpokládám, že se připravíš i o nějaké optimalizace zápisu, ale to neumím pozitivně říct, je to jenom odhad.

A mohu se na RAIDZ a RAIDZ2 spolehnout v Linuxových implementacích "ZFS on Linux" a "ZFS-FUSE"? A umí už ZFS konverzi RAIDZ na RAIDZ2?

Já osobně bych se na ZFS on linux nespoléhal vůbec Na FreeBSD se to ladilo fakt roky a pořád ještě to není úplně bullet-proof, ale je to produkčně použitelný. ZFS on Linux bych na produkci nedal (ale to je každého věc, čemu bude důvěřovat a čemu ne).

A právě proto jsem chtěl RAID řešit přes mdadm, aby přidávat disky bylo možné.

Nejsem si jistý, jestli si významně pomůžeš. Musel bych si sepsat konkrétní postup přidávání disku a jejich propagaci do zpoolu, teď z hlavy to nedokážu říct, jak dobře to půjde.

Takže předpokládám správně, že implementace ZFS v OpenIndiana vychází z implementace v OpenSolaris? Funguje na OpenIndiana hardware bez problémů a lze doinstalovat KDE či xfce? Vyvíjí se vůbec aktivně OpenIndiana?

Solaris ani jeho klony jsem nikdy nepoužíval, takže bohužel neporadím.

Aha, to je dobré vědět, děkuji. Jen na tom nechápu: Myslel jsem, že Linux je rozšířenější než FreeBSD či OpenIndiana, tj. software by měl být pro Linux obecně lépe odladěný. Je to jinak?

Je to tak co se týče aplikačního software. Co se týče samotného OS, tak je všechno odladěné tak, jak to výrobce odladí A ZFS prostě pochází ze Solarisu, takže nejlíp funguje tam. Pak slušně funguje na FreeBSD, protože se tam už dlouho ladí ... no a pak je všechno ostatní.

...čili mám desetkrát míň RAM než je na tolik dat doporučeno. Chápu tím vysvětlení zápisu 1 MB/s, ale ne problémů s plynulostí.

V IT je spousta věcí, které nechápu Pokud jdeš nedoporučovanou cestou, nesmíš se divit ničemu.

Hashe používané při deduplikaci se při čtení nijak necachují? Dokáži si představit situace, kdy by se to hodilo.

Myslím, že autoři ZFS jsou znalostmi nad námi o tolik světelných let, že si určitě dokáží představit ledacos, o čem se nám ani nesní Jde o to, jak a proč je to implementované, ne jak si to my dva laici představujeme jako Hurvínek válku

3370

Server / Re:Nativní ZFS v Linuxu pozastavuje po zaplnění bufferu zápis na 8 TB disk

« kdy: 03. 03. 2016, 20:49:09 »

LZJB je lepší než GZIP? Jak jsem již uvedl, o rychlost mi moc nejde, proto upřednostňuji efektivitu komprese, která by měla být u GZIP obvykle lepší než u LZJB.

Jo, tak pokud ti nejde o výkon a jde o kompresi, tak pak gzip. Můžeš zvážit i jinou úroveň - gzip-7, gzip-8... ale rozdíly jsou malé a CPU penalizace je velká. Záleží na tobě, musíš si sám udělat benchmarky, co ti bude vyhovovat.

3371

Server / Re:Nativní ZFS v Linuxu pozastavuje po zaplnění bufferu zápis na 8 TB disk

« kdy: 03. 03. 2016, 19:06:39 »

compression=gzip

Gzip je špatná komprese. Pokud tvoje verze ZFS podporuje něco jiného, použij to v tomhle pořadí:

LZ4 > LZJB > GZIP

3372

Server / Re:Nativní ZFS v Linuxu pozastavuje po zaplnění bufferu zápis na 8 TB disk

« kdy: 03. 03. 2016, 19:01:51 »

Zní to zajímavě, děkuji. Leč hned po koupi jsem provedl nějaké testy, při kterých sekvenční zápis byl podstatně rychlejší než 1 MB/s.

Disk nemůže zapisovat rychlostí 1MBps, máš tam něco zatraceně špatně.

Být tebou, řeším vrstvu po vrstvě - prvně rychlost zápisu na holý disk (bez jakéhokoliv FS), potom s další vrstvou, s další vrstvou...

Mám trochu podezření na to, jestli ti ten LUKS jede přes AES-NI... 1MBps by byl sice dost málo i bez ní, ale jeden z hlavních podezřelých to je.

Každopádně primárně řeším plynulost zápisu. Aby ten ZFS pool neměl každou chvíli na několik minut pozastavené veškeré zápisy. Potřebuji aby šlo na pool kdykoliv zapisovat, i kdyby nízkou rychlostí.

Pokud ti to opravdu zapisuje rychlostí 1MBps a data tam hrneš rychleji, tak se tohle prostě nevyhnutelně stane, co jiného by se mělo stát? Buffer by bobtnal donekonečna...

Bojím se mít každý disk šifrovaný zvlášť a až na tom ZFS RAID, protože jednak ZFS RAID moc neumím a pak nevím, zda umí funkce jako mdadm včetně konverze RAID 5 na 6 (resp. RAIDZ na RAIDZ2) nebo dokonce naopak, obzvláště v nativní Linuxové open-source implementaci "ZFS on Linux".

Rozhodně potřebuješ RAID na úrovni ZFS, jinak se zbytečně připravuješ o jeho vlastnosti a zbytečně to kombinuješ s další vrstvou, která nic neví o datech nad ní. Je to špatně a nedělej to tak.

Přidávat disky po jednom v ZFS nejde, musíš si buď dopředu připravit scénář, který pro ZFS funguje, nebo se musíš připravit, že v určitém stádiu budeš muset všechna data odlít pryč a vytvořit nový pool.

Není to nic, co by ses musel kdovíjak učit. Stačí si to prostě vyzkoušet na par loop-devicech...

Zvažoval jsem přechod z Linux Mint nebo Debian-based OS obecně na OpenSolaris, ten je ale kvůli Oracle "discontinued". Zvažuji proto přechod na nástupce jménem OpenIndiana, ale byla by to celkem velká změna a nevím, jak moc kvalitní je implementace ZFS v OpenIndiana.

Určitě o několik řádů kvalitnější než na Linuxu

Nicméně pokud se ti nechce do Solarisích klonů, na FreeBSD už je ZFS mnoho let a je už slušně vychytané.

a myslím problém bude s tou deduplikací, kolik máš ram? máš l2arc? já měl deduplikaci jen na 4T (půlka plná) zapnutou a s 16GB RAM to dělalo velmi velké problémy, musel jsem deduplikaci vypnout.

Mám sice jen 4 GB RAM

NO WAY!

A general rule of thumb is 1 GB of RAM for every 1 TB of storage. If the deduplication feature is used, a general rule of thumb is 5 GB of RAM per TB of storage to be deduplicated.

https://www.freebsd.org/doc/handbook/zfs-advanced.html

...čili máš desetkrát míň RAM než je na tolik dat doporučeno.

, ale swap 16 GB je téměř vždy prázdný.

Se swapem to imho nemá co dělat.

L2ARC je téměř 100 GB, pokud se nemýlím a je společně s logem na SSD disku:

L2ARC je read cache, která se použije jenom v případě, že čteš data, která nejsou nacachovaná v RAM. Pokud z poolu nečteš, nepoužije se ani 1B L2ARC Takže s tvými problémy se zápisem to nijak nesouvisí.

3373

Server / Re:Postix doručování emailů na dva servery

« kdy: 03. 03. 2016, 12:07:57 »

K serveru co poštu filtruje.. rsp chci aby email došel jak do starého serveru, tak do tohodle třetího zároveň.

Tak teď teda nevím. Server A je "gateway", chodí tam maily zvenku, on je filtruje a ham posílá na server B. Ty chceš mít redundantní A nebo B?

(ne že by to měnilo něco na tom, co jsem psal dřív, ale aspoň to zadání by mohlo být jasné )

3374

Server / Re:Postix doručování emailů na dva servery

« kdy: 03. 03. 2016, 10:47:44 »

Není to nestandardní, je to stav, kterému se říká "Split domain".
Část uživatelů ve stejné doméně je na jednom serveru, část na druhém.

To ale není to, na co se OP ptal.

3375

Server / Re:Postix doručování emailů na dva servery

« kdy: 03. 03. 2016, 07:59:05 »

Jak už to tak bývá, bylo by lepší, kdybys popsal, čeho se snažíš dosáhnout než se ptát, jak implementovat řešení, které sis vymyslel. To tvoje řešení je totiž nestandardní a dost pravděpodobně nic opradu neřeší, proto ho nemůžeš nikde najít.

Pokud ti jde o opravdové HA, musíš na to jít klasičtější cestou - nejspíš přes nějaké sdílené úložiště, failover, možná i předávání IP adres kvůli failoveru IMAPu. Na to návody najdeš a snadné to nebude. Nebo jít ještě klasičtější a jednodušší cestou - backup MX.

To tvoje řešení by mělo minimálně tři problémy (v tomhle pořadí důležitosti):

1. pokud uživatelé na serveru poštu i čtou, tak když přepneš na druhý server, objeví se jim tam všechny maily - i ty, které už četli, vyřídili, smazali a nebudou tam mít maily, které odeslali (pokud mají složku odeslané na IMAPu). To určitě nechceš a jít cestou nějaké synchronizace je nasazování narovnáváku na ohýbák.

2. ten vstupní postfix je pořád single point of failure, takže je otázka, jestli to tvoje řešení vůbec něco řeší (to je otázka na tebe, ty tu situaci tam znáš)

3. je to nestandardní řešení a nikdo ti s ním pak nepomůže, když ti to nebude fungovat