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 ... 202 203 [204] 205 206
3046
Ale nevím, jak dnes vypadají možnosti konfiguraci Windows firewallu, to bude podle mne podstatnější omezení.

Souhlas. Windows Advanced Firewall je statelfull (na rozdíl od Basic Firewall). 100% to tvrdit nedokážu, ale jsem přesvědčený, že jakmile spojení pravidlem projde, celý jeho zbytek už doběhne i po změnách. To už lze lehce vyzkoušet.

3047
Server / Re:Zálohování virtuálních strojů za chodu
« kdy: 14. 09. 2017, 10:32:01 »
Zajimave. Ja jsem dump postgre pres jednotlive databaze zrusil, protoze to pak vyzaduje i dumpovat uzivatele extra atd...Takze to pouzivam jen vyjimecne. Za zaklad povazuji zalohovani pres WAL, ale je to zrout mista, takze to nelze bez extra nastroju drzet takovou dobu, jako kompresovane dumpy - ale ty jsou pouze nouzova zaloha.

Na to je jednoduchý script, který zazálohuje i globaldata:
for I in `/usr/bin/psql -d template1 -q -t -c "SELECT datname FROM pg_database WHERE datname NOT IN ('template0') ORDER BY datname;"`; do
        /usr/bin/pg_dump -F t ${I} | /usr/bin/lzop -1 > ${TEMPDIR}/${DATE}${I}.tar.lzo
done


S tou nedostatecnou deduplikaci souhlasim, ale zase se da udelat Always Incremental, k cemuz se snad taky nejak dostanu casem.

To ano, ale stejně musíte dělat full zálohy, mít dlouhý řetěz inkrementů není bezpečné.

S tou lzo kompresi, predpokladam, ze to vyzaduje LZO na klientech. Je mi milejsi, kdyz se o kompresi stara zalohovaci server, nez client, ale zatim co jsem videl, tak uspesnost komprese mi pripada lepsi na strane klienta, ale mozna se pletu, exaktne to zmerene nemam.

Bareos umí obojí, ale vycházím z toho, že úzké hrdlo je CPU bareosu a síť. Naopak na hypervizorech mám přebytek CPU. Proto LZO na straně klienta vychází lépe.


3048
To, že Windows firewall neřeší už navázaná spojení máte ověřené?

Čistě empiricky, nikdy jsem neřešil tento konkrétní problém - proto to píšu s vyjádřením určité míry nejistoty.
Také vycházím ze zkušeností s firewally. Statefull firewally by po změně pravidla musely detekovat, čeho se změna pravidla týká, a v conntracku shodit už navázaná spojení. Je možné, že to některý umí, ale já o tom nevím.

3049
Už navázaná spojení tímto způsobem neutnete. Můžete scriptem povolovat / zakazovat nadefinované pravidlo ve windows fireallu, ale účinné to bude až od dalšího spojení. Tedy: 1. prodleva = provedení příkazu, 2. prodleva = účinnost až od dalšího spojení.
To ale platí jen pro TCP/IP (případně SCTP) spojení a případ, kdy na firewallu kontrolujete jen první paket spojení a ostatní pakety již navázaného spojení propouštíte bez kontroly. Pokud se pravidla na firewallu nastaví tak, že má zahazovat všechny pakety daného spojení, komunikace v daném spojení se ukončí okamžitě (ale samotné spojení zůstane otevřené až do timeoutu).

Vycházím z Windows Firewallu, který je statefull. Tazatel se ptal na ovládání pomocí netsh.
Stateless FW je možný, ale není moc zvyklý, a upřímně ani nevím, jestli lze spolehlivě do windows implementovat, jestli by nemusel být předsazený.

3050
Sítě / Re:Router pro full BGP
« kdy: 14. 09. 2017, 05:34:03 »
Ahoj,

planuji bgp, mam dva upstream linky 10Gb a 1Gbit a hledam router, celkem trafik ~ 2.5gbit,
bude pouze resit bgp a routing, vse ostatni se deje v siti dale.
 
Premyslim o:
1. Mikrotiku (odrauzuje ma implementace bgp jako single core, je to stabilní ?, má to výkon ?)
2. Linux server s bird ( jake je pro to vhodne distro ? mel bych bird komplikovat ? předpokládám, že
    stabilní je to dost, nasadit bych to na nějaké Supermicro železo)
3. Něco uplne jineho napr. starší Cisco či něco jiného doporučte ?

Jaké máte zkušenosti, případně na čem provozujete pokud toto řešíte?
Díky Mark

Pokud se jedná o full BGP, vždy platilo, že nemá smysl experimentovat s ničím jiným, než Ciscem. Největší problémy nebyly ani tak s výkonem (v tom je Cisco de facto pozadu vs. cena za hw), ale zejména díky bugům v implementaci, když pak pošlete ven prefixy, které nemáte, způsobíte tím ostatním spoustu problémů. Na interní použití bych se nebál Mikrotika CCR, ale pokud chcete full BGP, tak předpokládám, že to nebude jen pro interní použití :).

3051
OS: Windows 7

Ahoj všem,

Hledám způsob jak (jedním tlačítkem) okamžitě odstřihnout aplikaci od internetu a zase povolit.
Napadlo mě použít příkaz "netsh" a povolovat a zakazovat aplikaci v bráně firewall.

Bojím se ale že tam nějaká prodleva přece bude :-/

Už navázaná spojení tímto způsobem neutnete. Můžete scriptem povolovat / zakazovat nadefinované pravidlo ve windows fireallu, ale účinné to bude až od dalšího spojení. Tedy: 1. prodleva = provedení příkazu, 2. prodleva = účinnost až od dalšího spojení.

3052
Software / Re:Kopírování tabulátorů z SSH terminálu Putty
« kdy: 14. 09. 2017, 05:28:12 »
kdyz edituji python script odsazeny tabulatory pres SSH v Putty v editoru nano  a oznacim a zkopiruji cast kodu, tak aby se zkopirovaly tabulatory a ne mezery?

Bohužel, nejde. Interpretace tabů je na editoru / prohlížeči. V něm se nastavuje, za kolik mezer má taby nahradit, takže do okna terminálu už jdou mezery (zjednodušeně řečeno). Toto chování se ovlivňuje v .nanorc parametrem set tabsize X. Stačí takto vysvětlení, proč to nejde?

3053
Server / Re:Zálohování virtuálních strojů za chodu
« kdy: 14. 09. 2017, 05:22:29 »
Rozsirim tema zalohy virtulaek. Pod KVM virtualizaci planujeme pouzit https://www.bareos.org/ na zalohy
1.)virtualek
2.)obsahu virtualek zejmena:
2.1.)Postgre SQL
2.2.)My/MariaDB
2.3.)Staticka data

Používám Bareos.
Ad 1) nemám zkušenost, ale nevidím v tom sílu bareosu.
Ad 2.1) bez problému, fs zálohuju s vyloučením datového adresáře PG, v nezávislém jobu mám script na dump po jednotlivých databázích (pro obnovu je to lepší, než pgdumpall); lze nastavit zálohování base+wal, bylo by to asi i lepší, ale u toho bych považoval za nutné naplánovat pravidelné testy obnovitelnosti, a to se mi nechtělo.
Ad 2.2) obdobně, script, který ve smyčce dumpuje databázi po databázi.
Ad 2.3) bez problémů, jen pokud chcete zálohovat i extended attributes, hlásí čas od času warningy.

Dobrou zkušenost mám s tím, že bareos provede zálohu rychle, efektivně, a při použití jeho interní lzo komprese, tak i s malým objemem dat.

Pak mám speciální případy, např. stroj, kde je několik TB fotek, a kde zákazník nemá požadavek na archivaci stavu X dní, stačí mu poslední záloha (archiv má u sebe), tam mám v jobu nastavený na dané adresáře rsync. Rsync pak dělám na ZFS s nastavenou deduplikací, protože některé fotky se opakují (dosahuji efektivity uložení 1:1,2) Takže job nejprve spustí rsync, a po něm udělá klasicky zálohu zbytku OS.

Jako slabiny vidím menší stabilitu bareosu, chybějící deduplikaci (dedup by base jobs mi moc nepomáhá), složité nastavování retence dat, a aktuálně má bug při restore, pokud máte datasety nastavené do různých adresářů (pokud je máte v jednom, je to bez problémů).

Retence dat se dá nastavit přes datasety, ale je potřeba přemýšlet o tom, jak velký bude jednotlivý soubor vs. retence dat v něm. Dá se očekávat, že na full zálohách budete potřebovat delší retenci, na inkrementech kratší. Pokud oba druhy zálohy skončí ve stejném datasetu, tak nemá možnost se uvolnit a de facto bude data držet tak dlouhou dobu, dokud nevyexspiruje i full.

Dost nepohodlné je konfigurování plánovače. Pokud máte víc strojů k zálohování, budete patrně chtít, aby full zálohy neběžely ve stejný den, ale rozložily se. Pak musíte na každý job nadefinovat i vlastní schedule, ale konfigurace není moc čitelná, takže si musíte vést evidenci bokem, třeba v excelu.

Nižsí stabilita bareosu se někdy projevuje v nekonzistentním stavu jeho databáze - není to žádná tragedie, ale když zrovna potřebujete obnovit soubor, a musíte začít řešit i toto, je to ke vzteku.

Za slabinu považuji to, že po rekonfiguraci neexistuje vždy možnost reloadu, aniž by spadly běžící joby. Opět, dá se s tím žít, ale pokud to uděláte uprostřed full zálohy, ta bude muset proběhnout znovu, ale data v datasetu už jsou, a budou čekat na exspiraci (také nedořešený stav).

Stačí popis takto?

3054
Server / Re:zalohování virtuálních strojů
« kdy: 13. 09. 2017, 22:21:50 »
Takže když v aplikaci otevřu soubor pro zápis, zkrátím na 0, začnu zapisovat záznam po záznamu a mezi 3.-4. záznamem přijde požadavek na snapshot, tak v tom souboru bude co? Budu mít v tom snapshotu půlku např. zdrojáku, příp. při "uložit vše" budou 3 zdrojáky staré a 4 nové? Jedná se stále o konzistentní stav?

Situaci, kterou popisujete, nevyřeší žádné opatření. Když pustíte archivaci, může proběhnout ve stejně nevhodný okamžik. Backup pomocí agenta taky. Backup VM taky. Když uděláte shutdown, abyste udělal snapshot za studena, tak i shutdown se může strefit do stejného okamžiku.

VSS + quiesce posouvá spolehlivost o kus dál, byť ne na 100 %.

3055
Server / Re:zalohování virtuálních strojů
« kdy: 13. 09. 2017, 21:09:16 »
Místo rozčilování je nutné si uvědomit, že snapshoty vůbec nemusí představovat konzistentní stav systému. Pokud udělám snapshot v průběhu zápisu do souboru, tak asi moc konzistentní nebude. S databázemi je to ještě horší kvůli rozpracovaným transakcím - proto je lepší zálohovat databáze exportem, při kterém vůbec nevadí, že se mezitím data modifikují.

VMWare od toho má funkci Quiesce, která přes vmware tools vyžádá zápis filesystému do konzistentního stavu.

https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1015180

3056
Server / Re:zalohování virtuálních strojů
« kdy: 13. 09. 2017, 20:07:13 »
no a to je ten problem...vzhledem k tomu ze nemam misto na disku a uz jednou se me skarede potrapilo tak, ze jsem nedokazal udelat merge kvuli nedostatku mista na disku, nechci jiz neco podobneho zazit...proto delat snapshoty s tak dlouhym odstupem je prozatim nemozne

Rozumím, u virtualizace a u snapshotů je potřeba mít opravdu rezervy, a ideálně i monitoring. Teprve, když si pro to vytvoříte podmínky, můžete využít tyto vychytávky. Pokud nemáte dost rezerv na datastoru s VM, pak dělejte jen snapshot => plná záloha => merge. A to každý den. Zase budete potřebovat hodně místa na zálohy.

Samozřejmě, vždycky Vám zůstává možnost zálohovat agentem, po souborech. Výhody, nevýhody i cenu jednotlivých řešení znáte, dál už je to jen o výběru cesty.

3057
Server / Re:zalohování virtuálních strojů
« kdy: 13. 09. 2017, 20:06:47 »
no a to je ten problem...vzhledem k tomu ze nemam misto na disku a uz jednou se me skarede potrapilo tak, ze jsem nedokazal udelat merge kvuli nedostatku mista na disku, nechci jiz neco podobneho zazit...proto delat snapshoty s tak dlouhym odstupem je prozatim nemozne

Rozumím, u virtualizace a u snapshotů je potřeba mít opravdu rezervy, a ideálně i monitoring. Teprve, když si pro to vytvoříte podmínky, můžete využít tyto vychytávky. Pokud nemáte dost rezerv na datastoru s VM, pak dělejte jen snapshot => plná záloha => merge. A to každý den. Zase budete potřebovat hodně místa na zálohy.

Samozřejmě, vždycky Vám zůstává možnost zálohovat agentem, po souborech. Výhody, nevýhody i cenu jednotlivých řešení znáte, dál už je to jen o výběru cesty.

3058
Server / Re:zalohování virtuálních strojů
« kdy: 13. 09. 2017, 19:52:18 »
Veeam backup, nebo Acronis to dělají samočinně. Před zálohováním vyvolají snapshot. Poté zálohují jenom přírůstky. vSphere umí na vmdk vymezit pouze změněné bloky od předchozí zálohy, takže inkrementální přenos je překvapivě malý. Dále, Veeam umí snapshoty a přírůstky promítnout do zálohy tak, že z nich zrekonstruuje plný image v nejnovější verzi. Tedy, je připraveno k rychlému natažení ze zálohy, a není potřeba dělat žádný replay přírůstků.
Ta technologie je velmi hezká, určitě stojí za to se na ni podívat, budete překvapený.
díky za tip
v tuto chvíly placený SW nepřipadá v úvahu, kdyz už tedy, tak mě ta partyzanstina něco přiučí
chápu tedy dobře, že tento scénař by měl fungovat?
a) primární virtualní stroj ve stavu OFF zkopíruji na založní místo (pouze jednou)
b) zítra na běžícím virtuálu udělám snapshot a ten zkopíruji na záložní místo vedle toho primáru
c) na běžícím virtuálu snapshot smažu/merge
 
bod b/c bych prováděl třeba každý den, ale vrtá mi hlavou, že každý nový snapshot, nebude pasovat proti výchozímu primárnímu...
pomůžete mi to objasnit?
díky

To byste nesměl mergovat předchozí snapshoty. Funkční scénář by mohl být: za chodu udělám v pondělí snapshot 1, ten zazálohuji. Úterý-pátek dělám další snapshoty, které zálohuji. V pondělí provedu merge všech snapshotů z minulého týdne, udělám jeden nový, a ten zase zazálohuji jako plnou zálohu.

Samozřejmě, jde to i v off stavu, jen je to bolestivější :).

3059
Server / Re:zalohování virtuálních strojů
« kdy: 13. 09. 2017, 19:30:36 »
není tomu dlouho co jsem zalozil tema na zalohovací pásky a diskuze se siroce rozvinula a mimo jiné byli zmineny zalohovací systemy jako Bacula, kterou jsem prave nasadil.
Rad bych zalohoval cele virtualní stroje, a chtel bych se zeptat jak to delate Vy...zda staci stroj pauznout, nebo treba primo za chodu a nebo je nutne vzdy virtualní stroj k zalohování vypnout.

díky

Veeam backup, nebo Acronis to dělají samočinně. Před zálohováním vyvolají snapshot. Poté zálohují jenom přírůstky. vSphere umí na vmdk vymezit pouze změněné bloky od předchozí zálohy, takže inkrementální přenos je překvapivě malý. Dále, Veeam umí snapshoty a přírůstky promítnout do zálohy tak, že z nich zrekonstruuje plný image v nejnovější verzi. Tedy, je připraveno k rychlému natažení ze zálohy, a není potřeba dělat žádný replay přírůstků.

Ta technologie je velmi hezká, určitě stojí za to se na ni podívat, budete překvapený.

3060
Hardware / Re:LSI MegaRaid - single HDD
« kdy: 13. 09. 2017, 17:04:49 »
Po zadání stejného dotazu do Googlu asi po 5 sekundách zjistíš, že ten disk máš nastavit jako RAID-0.  ::)

Podle mě by na LSI-MR měl jít nastavit přímo JBOD (Just a bunch of disks) - tedy propuštění (passthrough) pro jednotlivý disk. Rozdílem, pokud řadič JBOD podporuje, je, že konkrétní informace o disku (SMART apod.) jsou nejjednodušeji k dispozici pro OS.

Stran: 1 ... 202 203 [204] 205 206