Ahoj,
snažím se rozchodit KVM na Debianu podle návodu: https://kb.vpsfree.cz/
navody/vps/kvm
Skoro u konce mi virt-manager nabídne vytvoření virtuální sítě (Virtual
Network 'default' is not active. Would you like to start the network now?) a
po odsouhlasení to končí chybou:
Could not start virtual network 'default': Unable to set bridge virbr0
forward_delay: Operation not permitted
Traceback (most recent call last):
File "/usr/share/virt-manager/virtManager/netlist.py", line 344, in
validate_network
netobj.start()
File "/usr/share/virt-manager/virtManager/network.py", line 104, in start
self._backend.create()
File "/usr/lib/python2.7/dist-packages/libvirt.py", line 2820, in create
if ret == -1: raise libvirtError ('virNetworkCreate() failed', net=self)
libvirtError: Unable to set bridge virbr0 forward_delay: Operation not
permitted
Moc mne nenapadá, co by se s tím dalo udělat. Spouštím to jako root. Předem
dík, kdyby někdo věděl, kterým směrem se mám dál vydat.
Pavel
Zdar,
podarilo sa niekomu rozchodit systemd-nspawn? Skusam to na Fedore 24 a
koncim s tymto:
# systemd-nspawn -D f24
Spawning container f24 on /root/f24.
Press ^] three times within 1s to kill container.
Failed to create directory /root/f24/sys/fs/selinux: No such file or
directory
Failed to create directory /root/f24/sys/fs/selinux: No such file or
directory
Failed to mount to /root/f24/sys/fs/cgroup/perf_event: Invalid argument
Tie selinux hlasky su relativne ok, to pise bezne, ked je disablovany
selinux. Problem je ten posledny riadok.
Neriesil to niekto? Docker mi funguje normalne.
Vdaka
Brano
Ahoj,
ve firmě chceme využít pro pár věcí aws a potřebovali bychom nějakou úvodní
nalejvárnu od někoho zkušenějšího. Samozřejmě placenou. Zatím s tím nemáme
žádnou zkušenost tak v tom dost plaveme. Jsme tři a jsme z Prahy. Najde se
někdo kdo nás proškolí? Možná další spolupráce jako konzultant.
--
*Matěj Koudelka*
+420 604 266 933
Ahoj,
dnes jsme spustili registraci na LinuxDays, při které vyžadujeme potvrzení kliknutím na odkaz v e-mailu. Bohužel se zdá, že Microsoft má adresní rozsahy VPSfree na nějakém tvrdém blacklistu, takže všechny e-maily doručované na hotmail.com, hotmail.cz, outlook.com, apod. bouncují:
host mx4.hotmail.com[207.46.8.167] said: 550 SC-001
(BAY004-MC5F7) Unfortunately, messages from 37.205.10.200 weren't sent.
Please contact your Internet service provider since part of their network
is on our block list. You can also refer your provider to
http://mail.live.com/mail/troubleshooting.aspx#errors. (in reply to MAIL
FROM command)
Na vysvětlující URL je napsáno:
550 SC-001 Pošta byla odmítnuta z důvodu zásad služby Outlook.com. Příčiny odmítnutí mohou souviset s obsahem, který má charakteristiku podobnou nevyžádané poště, nebo s reputací IP adresy nebo domény. Pokud nejste správce e-mailu nebo sítě, obraťte se na poskytovatele e-mailových nebo internetových služeb s žádostí o pomoc.
…bez návodu, co dělat pokud JSEM správce e-mailu nebo sítě.
Máte někdo zkušenosti s tím, jak žádat Microsoft o nápravu?
Díky,
Ondřej Caletka
Ahojte,
Skusal uz niekdo instalovat . Docker Compose ?
Chcem si to vyskusat na pgnd (aktualne tam jedno uz mam) .. ale ak sa s tym
uz niekto hral a neslo to, nech nepalim cas ..
Chcem to nainstalovat na Ubuntu 16.04 ... Ked som skusal ten postup co je na
KB pre docker, tak po aktivacii features a restarte sa uz nerozbehlo VPS .
:- )))))
Dajte mi pls vediet . Vdaka moc ..
Michal
V praci mi dobiha vmware 5ka prijde novej stroj novej is novy vsechno.
Proxmox me celkem zajimal uz driv.
Zajimalo by mne jak se v linuxu resi takove ty hp tooly na sledovani stavu
systemu a manipulaci s polem. Nasel jsem par commandline toolu ale zda se
mi ze nejsou stejne funkcni jako ta jeich klikatka.
Co se sw raidu tyka tak mi vzdycky prislo ze pod databazi jsou o par levelu
horsi nezli hw raidy. Jediny proti u hw raidu me napada moment kdy mam
linux protoze tam nejsou tooly jako na windows umoznujici s raidem
manipulovat a diagnostikovat za chodu. (A samo situace kdy mam 3 servery
kazdej jinej vyrobce)
Dne 31. 8. 2016 13:28 napsal uživatel "Slávek Banko" <slavek.banko(a)axis.cz>:
Je hezké vidět odlišnost v přístupu. Já po různých zkušenostech s různými
HW RAIDy říkám jednoduše: "HW RAID ani omylem," protože s Linuxovým SW
raidem je mnohem lepší dohled nad stavem pole a mnohem silnější nástroj
pro analýzu a řešení problémů, když nastanou.
Podobně s VMware × KVM. Zatímco při občasných setkáních s VMware obvykle
od něj dostanu řadu klacků naházených pod nohy, KVM prostě běží.
--
Slávek
On Wednesday 31 of August 2016 10:46:37 Vaclav Dusek wrote:
> Dobry den,
>
> pokud se jedna o dulezite firemni systemy, tak bych zacal tim, ze bych
> oslovil fi, napr. Dell a nechal si od nich zpracovat nabidku na HW a SW
> od VMware - 2 servery, 2 diskova pole (iSCSI nebo FC)
>
> Jinak bych se do toho pustil v Proxmoxu s vyuzim informci z predchozi
> konzultace
>
> Vse je o penezich a analyze rizik jednotlivych reseni
>
> Dne 30.8.2016 v 20:42 Pavel Hruška napsal(a):
> > Děkuji za reakci.
> >
> > Doplním tedy: provozovat na tom budu (potřebuji) firemní
> > infrastrukturu, což znamená 3-4 Windows Servery (2008R2, 2012, ale i
> > třeba starší 2003) a nějaké podpůrné Linuxové servery. Cílem
> > virtualizace a HA je minimalizovat riziko spojené s výpadky
> > jednotlivých nodů (HW) a získat čas na jejich opravu / výměnu, plus
> > samozřejmě sdílení zdrojů.
> >
> > Zajímá mě, zda někdo dokáže posoudit rozdíl mezi free/placenou
> > distribucí, ačkoliv když se dívám na ceny, tak jsou téměř lidové.
> >
> > P.H.
> >
> > Dne 30. srpna 2016 20:34 Vaclav Dusek <Vaclav.Dusek(a)cz-pro.cz
> > <mailto:Vaclav.Dusek@cz-pro.cz>> napsal(a):
> >
> >
> > - pro beznou praci konkurenceschopne s VMware.
> >
> > - placena verze pridava moznost supportu od vyrobce, lepsi
> > aktualizace https://www.proxmox.com/en/proxmox-ve/pricing
> > <https://www.proxmox.com/en/proxmox-ve/pricing>
> >
> > Zatim jsem se s problemy nesetkal, ale zalezi co na tom budete
> > provozovat
> >
> >
> > Dne 30.8.2016 v 20:19 Pavel Hruška napsal(a):
> >
> > Mohl by se někdo více rozepsat o zkušenostech s PROXMOX?
> > Používáte free
> > nebo placenou distribuci? Je to použitelné do reálného
> > provozu jako náhrada malého clusteru (2-3 nody, HA, do 10 VM) místo
> > např. VMWare? Uvažuji výhledově o změně a na první pohled to vypadá
> > solidně.
> >
> > Díky,
> > P.
> >
> > Dne 30. srpna 2016 18:35 Tomas Herceg <tth(a)rfa.cz
> > <mailto:tth@rfa.cz> <mailto:tth@rfa.cz <mailto:tth@rfa.cz>>>
> >
> > napsal(a):
> >
> > Ahoj,
> > taky sem chtel poradit proxmox - kombinace lxc+kvm+debian
> > muzu jedine doporucit
> >
> > On 08/30/2016 06:03 PM, Vaclav Dusek wrote:
> > > Dobry den,
> > >
> > > podivejte se na https://www.proxmox.com/en/proxmox-ve
> >
> > <https://www.proxmox.com/en/proxmox-ve>
> > <https://www.proxmox.com/en/proxmox-ve
> > <https://www.proxmox.com/en/proxmox-ve>>
> >
> > > Myslim, ze neprohloupite
> > >
> > > Dne 30.8.2016 v 16:48 Pavel Bařina napsal(a):
> > >> Ahoj,
> > >> s kolegou řešíme jakou cestou virtualizace se ve firmě
> >
> > vydat. Jelikož
> >
> > >> jsou zde odborníci na OpenVZ rád bych se poradil. Já
> > >> mám
> >
> > zkušenosti s
> >
> > >> KVM z jiné firmy a kolega zatím zkoušel OpenVZ na
> > >> CentOS
> >
> > release 6.7.
> >
> > >> Vyšlo nové OpenVZ a jak jsem zahlídl i zde s pár
> > >> poznámek
> >
> > budoucnost
> >
> > >> OpenVZ může být nejistá. Jakou cestou kontejneru byste
> > >> se
> >
> > vydali vy?
> >
> > >> Nové OpenVZ, LXC nebo docker? Zároveň bychom chtěli na
> >
> > stejném stroji
> >
> > >> provozovat i KVM (pro chod Windows).
> > >>
> > >> Momentálně máme na stroji obojí. OpenVZ i KVM. Nicméně
> > >> je
> >
> > problém se
> >
> > >> spouštěním virtuálního stroje v KVM, po druhém pokusu
> > >> o
> >
> > spuštění
> >
> > >> virtuálního stroje již naběhne.
> > >>
> > >> Chyba při startu domény: Nelze vytvořit cgroup pro
> >
> > Debian-wheeze:
> > >> Adresář nebo soubor neexistuje
> > >>
> > >> Traceback (most recent call last):
> > >> File
> > >> "/usr/share/virt-manager/virtManager/asyncjob.py",
> >
> > line 91, in
> >
> > >> cb_wrapper
> > >> callback(asyncjob, *args, **kwargs)
> > >> File
> > >> "/usr/share/virt-manager/virtManager/asyncjob.py",
> >
> > line
> > 127, in
> >
> > >> tmpcb
> > >> callback(*args, **kwargs)
> > >> File
> > >> "/usr/share/virt-manager/virtManager/domain.py",
> >
> > line 1355, in
> >
> > >> startup
> > >> self._backend.create()
> > >> File "/usr/lib/python2.7/dist-packages/libvirt.py",
> >
> > line 999,
> > in create
> >
> > >> if ret == -1: raise libvirtError
> > >> ('virDomainCreate()
> >
> > failed',
> >
> > >> dom=self)
> > >> libvirtError: Nelze vytvořit cgroup pro
> > >> Debian-wheeze:
> >
> > Adresář nebo
> >
> > >> soubor neexistuje
> > >>
> > >>
> > >> KVM není spuštěno v kontejnerech jako u VPS ale
> >
> > samostatně vedle
> > OpenVZ
> >
> > >> Děkuji moc za postřehy a nakopnutí správným směrem
> > >>
> > >> Pavel
> > >
> > > _______________________________________________
> > > Community-list mailing list
> > > Community-list(a)lists.vpsfree.cz
> >
> > <mailto:Community-list@lists.vpsfree.cz>
> > <mailto:Community-list@lists.vpsfree.cz
> > <mailto:Community-list@lists.vpsfree.cz>>
> >
> > > http://lists.vpsfree.cz/listinfo/community-list
> >
> > <http://lists.vpsfree.cz/listinfo/community-list>
> > <http://lists.vpsfree.cz/listinfo/community-list
> > <http://lists.vpsfree.cz/listinfo/community-list>>
> >
> >
> > _______________________________________________
> > Community-list mailing list
> > Community-list(a)lists.vpsfree.cz
> > <mailto:Community-list@lists.vpsfree.cz>
> > <mailto:Community-list@lists.vpsfree.cz
> > <mailto:Community-list@lists.vpsfree.cz>>
> > http://lists.vpsfree.cz/listinfo/community-list
> > <http://lists.vpsfree.cz/listinfo/community-list>
> > <http://lists.vpsfree.cz/listinfo/community-list
> > <http://lists.vpsfree.cz/listinfo/community-list>>
> >
> >
> >
> >
> > --
> > Pavel Hruška
> > http://www.mrpear.net <http://www.mrpear.net/>
> > mrpear(a)mrpear.net <mailto:mrpear@mrpear.net>
> > <mailto:mrpear@mrpear.net <mailto:mrpear@mrpear.net>>
> >
> > web, webdesign, web-aplikace:
> > http://www.pearfect.cz <http://www.pearfect.cz/>
> >
> >
> > _______________________________________________
> > Community-list mailing list
> > Community-list(a)lists.vpsfree.cz
> > <mailto:Community-list@lists.vpsfree.cz>
> > http://lists.vpsfree.cz/listinfo/community-list
> > <http://lists.vpsfree.cz/listinfo/community-list>
> >
> >
> > --
> > Vaclav Dusek
> > e-mail: Vaclav.Dusek(a)cz-pro.cz <mailto:Vaclav.Dusek@cz-pro.cz>
> >
> > _______________________________________________
> > Community-list mailing list
> > Community-list(a)lists.vpsfree.cz
> > <mailto:Community-list@lists.vpsfree.cz>
> > http://lists.vpsfree.cz/listinfo/community-list
> > <http://lists.vpsfree.cz/listinfo/community-list>
> >
> >
> >
> >
> > --
> > Pavel Hruška
> > http://www.mrpear.net <http://www.mrpear.net/>
> > mrpear(a)mrpear.net <mailto:mrpear@mrpear.net>
> >
> > web, webdesign, web-aplikace:
> > http://www.pearfect.cz <http://www.pearfect.cz/>
> >
> >
> > _______________________________________________
> > Community-list mailing list
> > Community-list(a)lists.vpsfree.cz
> > http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________
Community-list mailing list
Community-list(a)lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list
Zdravim odbornikov.
Prosim o pomoc ak niekto moze a je ochotny pomoct...
Nemam ziadne skusenosti s nastavovanim linuxovych serverov - v tomto som
totalny zelenac, som obycajny web dizajner, trochu programator. Ale vela
veci sa viem naucit sam, vela veci som zvladol rozchodit za pomoci
tutorialov, ale chybaju mi skusenosti.
Mam zriadene VPS kde som nainstaloval Ubuntu 14.04, zvladol som rozchodit
apache2, mysql, php, ftp, rozne php nastavenia (cache, memory_limit,
mod_rewrite atd...)
Bezi na tom obycajny komunitny web postaveny na Wordprese, cca 400
uzivatelov.
Vsetko drzim aktualne, wordpress, jeho pluginy, apache, mysql atd...
V poslednych dnoch mi hlasili DVAJA uzivatelia, ze maju problem s webom a
to taky, ze po zadani adresy assettocorsa.eu sa im nezobrazi moj web, ale
nejaky cinsky alebo japonsky bordel... Ale nikto iny to nehlasi, iba dvaja
ludia zo 400.
Do prilohy prikladam screen co sa im zobrazi a aj zazipovany zdrojak toho
cinskeho bordelu.
Najskor som myslel ze maju zavirovane svoje lokalne PC, ale jeden z nich
je udajne ITckar a ze to skusal na viacerych PC a na viacerych miestach a
stale to same...
Potom ma napadlo, ci neni hacknuty nejaky lokalny DNS server jeho
lokalneho poskytovatela internetu, ale ked pingne somenu assettocorsa.eu
smeruje ho to na spravnu IP adresu. PC uzivatelov su udajne ciste bez
virusov.
Ja som svoj web preskenoval vsetkymi moznymi online skenermi - vsetko
ciste.
Stiahol som cely web na lokal, preskenoval aj tam vsetkym moznym - vsetko
ciste...
Z tejto strany to vyzera byt OK, otazka je ako je na tom server, ale tam
som totalny amater, viem ze je tam vsetko aktualne, ale neviem kde sahnut
a co skontrolovat ze kde by mohla byt chyba.
Nestretol sa niekto s niecim podobnym, alebo nehodite mi nejake voditko co
a kde mam skontrolovat?
Hladal som po forach ale tento problem som nikde inde nenasiel...
Vopred moc velky dik za akukolvek pomoc.
Máte rádi náš spolek vpsFree.cz? Chcete pomoci s jeho propagací?
Nominujte ho do ankety Křišťálová Lupa v kategorii Nástroje a služby:
http://kristalova.lupa.cz/nominace/
V loňském roce jsme se dostali do hlasování a skončili 9. z 11:
https://blog.vpsfree.cz/kristalovou-lupu-jsme-nevyhrali-zatim/
Přesto to pro nás znamenalo docela velký zájem lidí, měli jsme stovky
návštěv na webu a jistě se o nás dozvěděl nějaký budoucí člen.
Děkujeme za podporu.
--
Petr Krčmář
vpsFree.cz
Ahoj,
spustili jsme vlastní službu pro sdílení úryvků kódu/výstupu
programů/textu obecně:
https://paste.vpsfree.cz
Nepřihlášený uživatel může vkládat text jen s omezenou dobou
platnosti. Členové se mohou přihlásit údaji z vpsAdminu a poté lze
ukládat text i na delší dobu.
Služba využívá aplikaci HaveSnippet [1], kterou jsem napsal před pár
lety jako školní projekt a teď jsem to doladil. Má to taky klienta v
příkazové řádce [2], texty se pak dají vkládat jako:
$ cat soubor.txt | havesnippet
$ havesnippet soubor.txt
Program má i verzi se zkráceným názvem `hs`:
# cat soubor.txt | hs
Klient se nejdříve musí nastavit:
1) gem install havesnippet-client
2) přihlásit se na paste.vpsfree.cz ve webovém prohlížeči, settings
a vytvořit si klíč k API
3) havesnippet -s https://paste.vpsfree.cz \
-k <vytvořený api klíč> --save
4) echo hotovo | havesnippet
Další možnosti programu jsou popsány v README [2].
[1] https://github.com/aither64/havesnippet
[2] https://github.com/aither64/havesnippet-client
Jakub
Ahojte, je to asi offtopic ale chcel by som poprosit o radu co musim este nastavit v routeros mikrotiku ked chcem port forward.
isiel som podla navodu
http://www.icafemenu.com/how-to-port-forward-in-mikrotik-router.htm
Funguje to ale iba z vonka ked som mimo danej sieti.
Pokial som v tej sieti a chcem sa napojit napr na mojamasina.sk:1212 tak ma nepripoji.
Ked to skusim ale z inej ip ktora nieje sucast danej siete tak ma krasne napoji.
Vdaka za kazdu radu
arty
Rozhodne ti to bude fungovat pokud rozjedes v OpenVZ KVM. Sice takovy hnusny dirtyhack, ale funguje :). Ale treba ti admini napisou, ze support bude brzo i v OpenVZ.
S podravem,
J. Skácel
> On 13 Aug 2016, at 23:27, Patrik Votoček <patrik(a)votocek.cz> wrote:
>
> Zdravím,
>
> předně se omlouvám pokud sem tenhle taz nepatří a patří třeba na podporu. Podle https://kb.vpsfree.cz/informace/kam_psat jsem usoudil že se to hodí spíše sem.
>
> Chtěl bych se zeptat zda je v plánu nasazení kernelu (případně je li to vůbec technicky možné) na kterém by běžel Docker 1.11+. Rád bych totiž svou VPS zapojil do Docker Cloud-u jako jeden z Nodu. Problém ale je že Docker Cloud používá speciální build Docker Engine (Docker version 1.11.1-cs1, build bfd1f99) který je ale postavený na verzi 1.11. Nicméně 1.11+ nefunguje na současném kernelu (3.16.6-042stab113.11) ani na (3.16.6-042stab116.2) který je na pgnd.
>
> Díky
>
> Patrik Votoček
Zdravím,
předně se omlouvám pokud sem tenhle taz nepatří a patří třeba na podporu.
Podle https://kb.vpsfree.cz/informace/kam_psat jsem usoudil že se to hodí
spíše sem.
Chtěl bych se zeptat zda je v plánu nasazení kernelu (případně je li to
vůbec technicky možné) na kterém by běžel Docker 1.11+. Rád bych totiž svou
VPS zapojil do Docker Cloud-u jako jeden z Nodu. Problém ale je že Docker
Cloud používá speciální build Docker Engine (Docker version 1.11.1-cs1,
build bfd1f99) který je ale postavený na verzi 1.11. Nicméně 1.11+
nefunguje na současném kernelu (3.16.6-042stab113.11) ani na
(3.16.6-042stab116.2) který je na pgnd.
Díky
Patrik Votoček
Ahoj,
možná jste to taky v týdnu postřehli, některé emaily poslané na
seznam.cz, email.cz se vrátili jako nedoručitelné
1.
4.2.0 ebox; switch: service unavailable: libswitch: Out of options;
500,Caught std::exception while dispatching method call: character
conversion failed.:sw|500,Caught std::exception while dispatching
method call: character conversion failed.:sw|
2.
3.
4.
5.
Neznámý problém s cílovou schránkou, zkuste odeslat zprávu později
znovu
6.
Persistent Transient Failure - Other or undefined mailbox status
nebo
1.
4.2.0 ebox; Connection reset by peer
2.
3.
4.
5.
Neznámý problém s cílovou schránkou, zkuste odeslat zprávu později
znovu
6.
Persistent Transient Failure - Other or undefined mailbox status
podle vyjádření techniků seznamu už vědí kde je chyba a pracují na nápravě
Dobrý den,
dle vyjádření kolegů se již pracuje na nápravě nalezené chyby, způsobující v některých případech, kdy docházelo k odesílání zpráv z IPv6 připojení, nedoručování zpráv na Seznam. Prosíme tak ještě o strpení a jakmile od kolegů získám informaci o nasazení opravy, kontaktuji vás znovu na vaší adrese.
Děkuji.
V případě odpovědi smažte prosím ve zprávě veškerý text předchozí komunikace a ponechte předmět.
Pokud je chyba opravdu v IPv6 mělo by stačit dočasně nastavit SMTP
servery na IPv4 only. Zkusil jsem to nicméně undelivery chodí až za 24h
a na moje účty u szn to vždycky došlo ok tak uvidíme.
SH
Ahojte,
potřebuji portovat .net projekt na linux (mono). Ten projekt využívá jako
db sqlite3 a v kódu se odkazuje na sdílenou knihovnu, která na linuxu je
libsqlite3.so.0.
Potřebuji zkompilovat aktuální verzi sqlite do libsqlite3.so.0. Zdrojáky
jsou tady:
https://www.sqlite.org/download.html
Dokázal by mi s tím někdo poradit? Poběží to na Ubuntu 14.04 a potřebuji 64
bitovou verzi knihovny. Nebo se dá udělat univerzální x86/x64?
Mám jen produkční server a s kompilací na linuxu jsem vždy bojoval - miluju
proto balíčky ;). Balíček sqlite3 jsem sice sehnal, ale jen se starou
verzí...
Díky.
Pavel.
Hoj,
zacinam mit prilis overhead s managementem kontajneru, co kdo pouzivate
pro configuration management?
par klicovych bodu:
1- musi to umet urcit kontajner podle hostname nebo ip (kdyz ho premaznu
novym templatem, musi se zbuildit znova)
2- resit prubezny updaty
3- sifrovany spojeni a nejaka autentifikace - repozitar predpisu bych
potreboval mit otevrenej do netu, protoze na nej polezu z milionu
ruznejch mist.
3b* alternativne mit vic "masteru" ktery se synchronizujou, ale radsi
bych se tomu vyhnul
nice to have:
4- private data, ktery muze vit jen nektery klient
5- zfs snapshoty, pokud bude mit agenta i na hypervisoru (potazmo nejaky
pre-post hook a povolim si pristup do .zfs, ale to afaik nepujde vsude)
6- rebuild VM po nejakem case (z novejsi template) pomoci zfs clone a
nejakyho skriptu, nasleduje bod 1
predpokladam, ze s vetsinou to pujde, jedine co muze byt problem je 3,
takze spis me zajima, v cem to bude nejpohodlnejsi napsat :)
Dik,
Ghor
Ahoj,
už nějakou dobu využíváme vedle jabber MUC také kanál #vpsfree na
freenode.net. Je tam mnohem větší aktivita než na jabberu, kde už se nic
neděje. Dnes jsme došli do stavu, kdy máme všechno důležité na IRC
připraveno a můžeme jím tak jabber MUC plně nahradit.
Jak se připojit?
Server: chat.freenode.net
Kanál: #vpsfree
Web klient: http://webchat.freenode.net/
Nativní klienti: Pidgin, Irssi, Adium, atd.
Archiv: https://im.vpsfree.cz/archive/chat.freenode.net/%23vpsfree
Pro členy máme připraven IRC bouncer (ZNC) [1]. Kdyby ho někdo chtěl
využívat, můžete se ozvat na IRC nebo na podpoře.
Na kanále je náš vlastní bot [2], který vytváří webový archiv odkazovaný
výše, reaguje na příkazy a sleduje různé události, jako např.
outage-list či novinky z vpsAdminu, o kterých pak na kanále informuje.
Více info viz KB [3].
[1] https://kb.vpsfree.cz/informace/chat#bouncer
[2] https://kb.vpsfree.cz/informace/chat#bot
[3] https://kb.vpsfree.cz/informace/chat
Jakub
ahoj,
líbila by se mi featura mít defaultní SSH klíč někde ve vpsadminu, kterej by se sypal do všech (re)instalovaných VPS.
Je to dobreje nápad, nebo blbej nápad, nebo jakej je to nápad? A v který komponentě na githubu tomu mam udělat issue?
-miky.
Ahoj,
za nas se taky priklanime spise k upgradu site. NAS pouzivame take s
vedomim toho ze to neni zalohovane a nijak nas to momentalne netrapi.
Jirka
--
-------------------------------------------------
Reklalink s.r.o. | A. Jiráska 260 | Příbram | 261 01
Telefon: +420 724 330 493 | Web: http://www.reklalink.cz
On 07/28/2016 02:24 PM, Pavel Snajdr wrote:
> Prave bezi posledni dosyncnuti dat, odhadem za 2-3 hodiny prepneme
> mounty read-only na backuper, znovu vytvorime pool na nasboxu s
> bezpecnejsi konfiguraci.
> Pouijeme vetsi raidz2, pripadne raidz3 VDEVy, sebehnu si nejake
> benchmarky tech konfiguraci, co mne napadaji jako prijatelne a uvidime,
> co z toho vyleze, stejna konfigurace se potom casem pouzije i pro
> backuper, abychom se vyhnuli stejne situaci v budoucnu na backuperu.
>
> K tomu, proc jsou v tom poolu disky se slabou redundanci, ie. 3-diskove
> RAID-Z: je to historicky dane tim, ze jak backuper, tak nasbox vznikly s
> malo disky a ZFS neumi reshape poli, pridavanim bezpecnejsich VDEVu
> bychom nic neziskali, protoze ten VDEV, ktery se rozbil, byl hned ten
> druhy v poradi, ktery tam byl uz pri prvnim vyrobeni pole.
>
> Kdybychom pouzili z fleku bezpecnejsi konfiguraci, to pole by tragicky
> nestihalo na IOPS.
>
> A jeste k tomu, jak NAS vubec vzniknul - to bylo tak, ze nam prebylo
> zalohovaci pole, ktere ale uz bylo male na to, aby delalo mirror zaloham
> a nechteli jsme ho nechat valet jen tak, proto jsme ho zpristupnili vsem
> a od zacatku rikali, ze neni zalohovane - mysleli jsme si, ze to pole
> vyuzijete na zalohy domacich dat a podobne, coz tedy vetsina udelala,
> ale...
>
> Nasli se i taci, kteri pres to vsechno dali na NAS produkcni data a ted
> je cekalo velmi neprijemne prekvapeni.
>
> Cili ted stojime pred rozhodnutim, jestli investovat do redundance NASu
> (a backuperu s tim), nebo jit podle puvodniho planu a upgradovat sit na
> 10Gbit (coz je potreba pro lepsi debugovatelnost clusteru, kvuli kdumpu;
> a taky jsem se chystal nejak vyresit replikaci dat mezi nody).
>
> Co si o tom myslite? Investovat do storage a nechat to zatim na 2Gbit
> siti (ktera je, nutno rict, sem tam, uz pekne na hrane s propustnosti)?
>
> Poznamecka: prosim ujistete se, ze v odpovedi je To:
> community-list(a)lists.vpsfree.cz, na outage-list se musi prispevky
> schvalovat a mely by tam jit jenom relevantni informace o vypadcich, ne
> diskuze.
>
> /snajpa
Ahoj,
pls 10Gbit
Jan Macík
PS: (pokud nekdo znáte poctivého politika tak mě na něj prosím pošlete kontak)
______________________________________________________________
> Od: open(a)2devnull.work
> Komu: community-list(a)lists.vpsfree.cz
> Datum: 29.07.2016 11:55
> Předmět: [vpsFree.cz: community-list] NAS read-only, poskozeny filesystem
>
Za mna tiez zvysenie siete na 10 Gbit.
Oto
_______________________________________
Dňa 29.07.2016 o 0:09 Marek Palatinus napísal(a):
> 10 Gbit. Podminky NASu jsou pro neprodukcni data a zalohy zaloh uplne
> dostatecne.
>
> Marek
>
> 2016-07-28 21:51 GMT+02:00 Marek Fabian <marekfab(a)gmail.com
> <mailto:marekfab@gmail.com>>:
>
> Za mna zvyseniena 10 Gbit.
>
> Marek Fabo Fabian
>
> 2016-07-28 14:24 GMT+02:00 Pavel Snajdr <snajpa(a)snajpa.net
> <mailto:snajpa@snajpa.net>>:
>
> Prave bezi posledni dosyncnuti dat, odhadem za 2-3 hodiny prepneme
> mounty read-only na backuper, znovu vytvorime pool na nasboxu s
> bezpecnejsi konfiguraci.
> Pouijeme vetsi raidz2, pripadne raidz3 VDEVy, sebehnu si nejake
> benchmarky tech konfiguraci, co mne napadaji jako prijatelne a
> uvidime,
> co z toho vyleze, stejna konfigurace se potom casem pouzije i pro
> backuper, abychom se vyhnuli stejne situaci v budoucnu na
> backuperu.
>
> K tomu, proc jsou v tom poolu disky se slabou redundanci, ie.
> 3-diskove
> RAID-Z: je to historicky dane tim, ze jak backuper, tak nasbox
> vznikly s
> malo disky a ZFS neumi reshape poli, pridavanim bezpecnejsich
> VDEVu
> bychom nic neziskali, protoze ten VDEV, ktery se rozbil, byl
> hned ten
> druhy v poradi, ktery tam byl uz pri prvnim vyrobeni pole.
>
> Kdybychom pouzili z fleku bezpecnejsi konfiguraci, to pole by
> tragicky
> nestihalo na IOPS.
>
> A jeste k tomu, jak NAS vubec vzniknul - to bylo tak, ze nam
> prebylo
> zalohovaci pole, ktere ale uz bylo male na to, aby delalo
> mirror zaloham
> a nechteli jsme ho nechat valet jen tak, proto jsme ho
> zpristupnili vsem
> a od zacatku rikali, ze neni zalohovane - mysleli jsme si, ze
> to pole
> vyuzijete na zalohy domacich dat a podobne, coz tedy vetsina
> udelala, ale...
>
> Nasli se i taci, kteri pres to vsechno dali na NAS produkcni
> data a ted
> je cekalo velmi neprijemne prekvapeni.
>
> Cili ted stojime pred rozhodnutim, jestli investovat do
> redundance NASu
> (a backuperu s tim), nebo jit podle puvodniho planu a
> upgradovat sit na
> 10Gbit (coz je potreba pro lepsi debugovatelnost clusteru,
> kvuli kdumpu;
> a taky jsem se chystal nejak vyresit replikaci dat mezi nody).
>
> Co si o tom myslite? Investovat do storage a nechat to zatim
> na 2Gbit
> siti (ktera je, nutno rict, sem tam, uz pekne na hrane s
> propustnosti)?
>
> Poznamecka: prosim ujistete se, ze v odpovedi je To:
> community-list(a)lists.vpsfree.cz
> <mailto:community-list@lists.vpsfree.cz>, na outage-list se
> musi prispevky
> schvalovat a mely by tam jit jenom relevantni informace o
> vypadcich, ne
> diskuze.
>
> /snajpa
>
> On 07/27/2016 04:18 AM, Pavel Snajdr wrote:
> > Je odkopirovano 9.5 TB z 22 TB.
> >
> > /snajpa
> >
> > On 07/26/2016 02:22 PM, Pavel Snajdr wrote:
> >> Aktualne je odsyncovano 5 TB dat z 22 TB celkem za cca 11
> hodin, odhadem
> >> to znamena, ze se bude syncovat jeste cca dalsich 30 hodin.
> >>
> >> Behem toho je NAS dostupny jenom jako read-only.
> >>
> >> Potom pole znovu vyrobime a zacneme syncovat data zpatky,
> coz uz by melo
> >> jit rychleji (backuper ma vic disku, nez na kolika ma data
> soucasny
> >> nasbox, cili zpatky to pojede rychleji).
> >>
> >> Jedinou dalsi variantou, jak zpristupnit NAS rychleji, by
> bylo vsechna
> >> data zahodit a vyrobit na nem pool znova - a to, i kdyz
> vsude piseme, ze
> >> neni zalohovany, nam prislo jako mnohem horsi varianta, nez
> ho odstavit
> >> na par dni jako read-only.
> >>
> >> Odkopirujte si prosim data na VPSky, pokud je aplikace
> potrebuji, kdo
> >> kvuli tomu potrebujete docasne zvednout misto na disku,
> napiste na
> >> podporu a pokusime se to nejak vyresit.
> >>
> >> Pokud ta data nepotrebuji aplikace k behu, tak na to prosim
> nesahejte,
> >> od toho to syncujeme na backuper, abychom zachranili, co se da.
> >>
> >> Zatim dalsi chyby na poolu nenaskocily, poskozenych je, zda
> se, opravdu
> >> jenom 58 souboru (a to jeste ne uplne, ale maji poskozenych
> par bitu,
> >> coz se napr. u obrazku da jeste prezit - vs. ztratit je uplne).
> >>
> >> /snajpa
> >>
> >> On 07/26/2016 03:41 AM, Pavel Snajdr wrote:
> >>> Ahojte,
> >>>
> >>> na NASu doslo k poskozeni jednoho z raid-z VDEVu na ZFS
> poolu s daty.
> >>>
> >>> Stalo se to pri obnovovani toho vdevu (neco jako
> sub-raid-pole) po umrti
> >>> jednoho disku, kdy dalsi disk ze stejneho vdevu zacal
> hlasit chyby pri
> >>> cteni. Evidentne od posledniho scrubu (cca mesic zpatky)
> na nem vznikly
> >>> neopravitelne oblasti, ktere nejdou precist.
> >>>
> >>> Zatim vime o 58 neobnovitelnych souborech, je to ve stavu,
> kdy ten disk
> >>> dava nejaka data, cili to nevypada ze by bylo po datech,
> ale vic se
> >>> dozvime, jakmile dobehne sync z nasboxu na backuper.
> >>>
> >>> Prepnul jsem nasbox do readonly rezimu, aby se predeslo
> dalsimu
> >>> poskozovani dat a mezi tim se data syncuji na backuper
> (aktualne to jede
> >>> okolo 150MB/s a je to 22TB dat).
> >>>
> >>> Potom, co se data dosyncuji, znovu vyrobim pool na nasboxu
> s bezpecnejsi
> >>> konfiguraci, aby se podobne situaci predeslo a pool
> vydrzel umrti vic
> >>> disku ve vsech pripadech.
> >>>
> >>> Tem, co se jich poskozena data tykaji, napiseme behem dne
> mail se
> >>> seznamem poskozenych souboru.
> >>>
> >>> Budu dal updatovat o prubehu, jakmile bude dalsi progress.
> >>>
> >>> /snajpa
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> Outage-list mailing list
> >>> Outage-list(a)lists.vpsfree.cz
> <mailto:Outage-list@lists.vpsfree.cz>
> >>> http://lists.vpsfree.cz/listinfo/outage-list <http://lists.vpsfree.cz/listinfo/outage-list>
> >>>
> >>
> >>
> >>
> >> _______________________________________________
> >> Outage-list mailing list
> >> Outage-list(a)lists.vpsfree.cz
> <mailto:Outage-list@lists.vpsfree.cz>
> >> http://lists.vpsfree.cz/listinfo/outage-list <http://lists.vpsfree.cz/listinfo/outage-list>
> >>
> >
> >
> >
> > _______________________________________________
> > Outage-list mailing list
> > Outage-list(a)lists.vpsfree.cz
> <mailto:Outage-list@lists.vpsfree.cz>
> > http://lists.vpsfree.cz/listinfo/outage-list <http://lists.vpsfree.cz/listinfo/outage-list>
> >
>
>
> _______________________________________________
> Outage-list mailing list
> Outage-list(a)lists.vpsfree.cz <mailto:Outage-list@lists.vpsfree.cz>
> http://lists.vpsfree.cz/listinfo/outage-list <http://lists.vpsfree.cz/listinfo/outage-list>
>
>
>
>
> --
> *Marek Fabian*
> Email: marekfab(a)gmail.com <mailto:marekfab@gmail.com>
> Skype: marek.fabian
>
>
> _______________________________________________
> Community-list mailing list
> Community-list(a)lists.vpsfree.cz
> <mailto:Community-list@lists.vpsfree.cz>
> http://lists.vpsfree.cz/listinfo/community-list <http://lists.vpsfree.cz/listinfo/community-list>
>
>
>
>
> _______________________________________________
> Community-list mailing list
> Community-list(a)lists.vpsfree.cz
> http://lists.vpsfree.cz/listinfo/community-list <http://lists.vpsfree.cz/listinfo/community-list>
_______________________________________________
Community-list mailing list
Community-list(a)lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list <http://lists.vpsfree.cz/listinfo/community-list>
Za mna zvyseniena 10 Gbit.
Marek Fabo Fabian
2016-07-28 14:24 GMT+02:00 Pavel Snajdr <snajpa(a)snajpa.net>:
> Prave bezi posledni dosyncnuti dat, odhadem za 2-3 hodiny prepneme
> mounty read-only na backuper, znovu vytvorime pool na nasboxu s
> bezpecnejsi konfiguraci.
> Pouijeme vetsi raidz2, pripadne raidz3 VDEVy, sebehnu si nejake
> benchmarky tech konfiguraci, co mne napadaji jako prijatelne a uvidime,
> co z toho vyleze, stejna konfigurace se potom casem pouzije i pro
> backuper, abychom se vyhnuli stejne situaci v budoucnu na backuperu.
>
> K tomu, proc jsou v tom poolu disky se slabou redundanci, ie. 3-diskove
> RAID-Z: je to historicky dane tim, ze jak backuper, tak nasbox vznikly s
> malo disky a ZFS neumi reshape poli, pridavanim bezpecnejsich VDEVu
> bychom nic neziskali, protoze ten VDEV, ktery se rozbil, byl hned ten
> druhy v poradi, ktery tam byl uz pri prvnim vyrobeni pole.
>
> Kdybychom pouzili z fleku bezpecnejsi konfiguraci, to pole by tragicky
> nestihalo na IOPS.
>
> A jeste k tomu, jak NAS vubec vzniknul - to bylo tak, ze nam prebylo
> zalohovaci pole, ktere ale uz bylo male na to, aby delalo mirror zaloham
> a nechteli jsme ho nechat valet jen tak, proto jsme ho zpristupnili vsem
> a od zacatku rikali, ze neni zalohovane - mysleli jsme si, ze to pole
> vyuzijete na zalohy domacich dat a podobne, coz tedy vetsina udelala,
> ale...
>
> Nasli se i taci, kteri pres to vsechno dali na NAS produkcni data a ted
> je cekalo velmi neprijemne prekvapeni.
>
> Cili ted stojime pred rozhodnutim, jestli investovat do redundance NASu
> (a backuperu s tim), nebo jit podle puvodniho planu a upgradovat sit na
> 10Gbit (coz je potreba pro lepsi debugovatelnost clusteru, kvuli kdumpu;
> a taky jsem se chystal nejak vyresit replikaci dat mezi nody).
>
> Co si o tom myslite? Investovat do storage a nechat to zatim na 2Gbit
> siti (ktera je, nutno rict, sem tam, uz pekne na hrane s propustnosti)?
>
> Poznamecka: prosim ujistete se, ze v odpovedi je To:
> community-list(a)lists.vpsfree.cz, na outage-list se musi prispevky
> schvalovat a mely by tam jit jenom relevantni informace o vypadcich, ne
> diskuze.
>
> /snajpa
>
> On 07/27/2016 04:18 AM, Pavel Snajdr wrote:
> > Je odkopirovano 9.5 TB z 22 TB.
> >
> > /snajpa
> >
> > On 07/26/2016 02:22 PM, Pavel Snajdr wrote:
> >> Aktualne je odsyncovano 5 TB dat z 22 TB celkem za cca 11 hodin, odhadem
> >> to znamena, ze se bude syncovat jeste cca dalsich 30 hodin.
> >>
> >> Behem toho je NAS dostupny jenom jako read-only.
> >>
> >> Potom pole znovu vyrobime a zacneme syncovat data zpatky, coz uz by melo
> >> jit rychleji (backuper ma vic disku, nez na kolika ma data soucasny
> >> nasbox, cili zpatky to pojede rychleji).
> >>
> >> Jedinou dalsi variantou, jak zpristupnit NAS rychleji, by bylo vsechna
> >> data zahodit a vyrobit na nem pool znova - a to, i kdyz vsude piseme, ze
> >> neni zalohovany, nam prislo jako mnohem horsi varianta, nez ho odstavit
> >> na par dni jako read-only.
> >>
> >> Odkopirujte si prosim data na VPSky, pokud je aplikace potrebuji, kdo
> >> kvuli tomu potrebujete docasne zvednout misto na disku, napiste na
> >> podporu a pokusime se to nejak vyresit.
> >>
> >> Pokud ta data nepotrebuji aplikace k behu, tak na to prosim nesahejte,
> >> od toho to syncujeme na backuper, abychom zachranili, co se da.
> >>
> >> Zatim dalsi chyby na poolu nenaskocily, poskozenych je, zda se, opravdu
> >> jenom 58 souboru (a to jeste ne uplne, ale maji poskozenych par bitu,
> >> coz se napr. u obrazku da jeste prezit - vs. ztratit je uplne).
> >>
> >> /snajpa
> >>
> >> On 07/26/2016 03:41 AM, Pavel Snajdr wrote:
> >>> Ahojte,
> >>>
> >>> na NASu doslo k poskozeni jednoho z raid-z VDEVu na ZFS poolu s daty.
> >>>
> >>> Stalo se to pri obnovovani toho vdevu (neco jako sub-raid-pole) po
> umrti
> >>> jednoho disku, kdy dalsi disk ze stejneho vdevu zacal hlasit chyby pri
> >>> cteni. Evidentne od posledniho scrubu (cca mesic zpatky) na nem vznikly
> >>> neopravitelne oblasti, ktere nejdou precist.
> >>>
> >>> Zatim vime o 58 neobnovitelnych souborech, je to ve stavu, kdy ten disk
> >>> dava nejaka data, cili to nevypada ze by bylo po datech, ale vic se
> >>> dozvime, jakmile dobehne sync z nasboxu na backuper.
> >>>
> >>> Prepnul jsem nasbox do readonly rezimu, aby se predeslo dalsimu
> >>> poskozovani dat a mezi tim se data syncuji na backuper (aktualne to
> jede
> >>> okolo 150MB/s a je to 22TB dat).
> >>>
> >>> Potom, co se data dosyncuji, znovu vyrobim pool na nasboxu s
> bezpecnejsi
> >>> konfiguraci, aby se podobne situaci predeslo a pool vydrzel umrti vic
> >>> disku ve vsech pripadech.
> >>>
> >>> Tem, co se jich poskozena data tykaji, napiseme behem dne mail se
> >>> seznamem poskozenych souboru.
> >>>
> >>> Budu dal updatovat o prubehu, jakmile bude dalsi progress.
> >>>
> >>> /snajpa
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> Outage-list mailing list
> >>> Outage-list(a)lists.vpsfree.cz
> >>> http://lists.vpsfree.cz/listinfo/outage-list
> >>>
> >>
> >>
> >>
> >> _______________________________________________
> >> Outage-list mailing list
> >> Outage-list(a)lists.vpsfree.cz
> >> http://lists.vpsfree.cz/listinfo/outage-list
> >>
> >
> >
> >
> > _______________________________________________
> > Outage-list mailing list
> > Outage-list(a)lists.vpsfree.cz
> > http://lists.vpsfree.cz/listinfo/outage-list
> >
>
>
> _______________________________________________
> Outage-list mailing list
> Outage-list(a)lists.vpsfree.cz
> http://lists.vpsfree.cz/listinfo/outage-list
>
>
--
*Marek Fabian*
Email: marekfab(a)gmail.com
Skype: marek.fabian
Za mě určitě platí, že data bez redundance (ať produkční nebo neprodukční), jako by jich nebylo. Za mě klidně budu mít míň storage, ale bezpečnou.
Vojtěch Knyttl
knyttl(a)goout.cz
+420 607 008 510
https://goout.cz
On Thursday 28. July 2016 at 14:24, Pavel Snajdr wrote:
> Prave bezi posledni dosyncnuti dat, odhadem za 2-3 hodiny prepneme
> mounty read-only na backuper, znovu vytvorime pool na nasboxu s
> bezpecnejsi konfiguraci.
> Pouijeme vetsi raidz2, pripadne raidz3 VDEVy, sebehnu si nejake
> benchmarky tech konfiguraci, co mne napadaji jako prijatelne a uvidime,
> co z toho vyleze, stejna konfigurace se potom casem pouzije i pro
> backuper, abychom se vyhnuli stejne situaci v budoucnu na backuperu.
>
> K tomu, proc jsou v tom poolu disky se slabou redundanci, ie. 3-diskove
> RAID-Z: je to historicky dane tim, ze jak backuper, tak nasbox vznikly s
> malo disky a ZFS neumi reshape poli, pridavanim bezpecnejsich VDEVu
> bychom nic neziskali, protoze ten VDEV, ktery se rozbil, byl hned ten
> druhy v poradi, ktery tam byl uz pri prvnim vyrobeni pole.
>
> Kdybychom pouzili z fleku bezpecnejsi konfiguraci, to pole by tragicky
> nestihalo na IOPS.
>
> A jeste k tomu, jak NAS vubec vzniknul - to bylo tak, ze nam prebylo
> zalohovaci pole, ktere ale uz bylo male na to, aby delalo mirror zaloham
> a nechteli jsme ho nechat valet jen tak, proto jsme ho zpristupnili vsem
> a od zacatku rikali, ze neni zalohovane - mysleli jsme si, ze to pole
> vyuzijete na zalohy domacich dat a podobne, coz tedy vetsina udelala, ale...
>
> Nasli se i taci, kteri pres to vsechno dali na NAS produkcni data a ted
> je cekalo velmi neprijemne prekvapeni.
>
> Cili ted stojime pred rozhodnutim, jestli investovat do redundance NASu
> (a backuperu s tim), nebo jit podle puvodniho planu a upgradovat sit na
> 10Gbit (coz je potreba pro lepsi debugovatelnost clusteru, kvuli kdumpu;
> a taky jsem se chystal nejak vyresit replikaci dat mezi nody).
>
> Co si o tom myslite? Investovat do storage a nechat to zatim na 2Gbit
> siti (ktera je, nutno rict, sem tam, uz pekne na hrane s propustnosti)?
>
> Poznamecka: prosim ujistete se, ze v odpovedi je To:
> community-list(a)lists.vpsfree.cz (mailto:community-list@lists.vpsfree.cz), na outage-list se musi prispevky
> schvalovat a mely by tam jit jenom relevantni informace o vypadcich, ne
> diskuze.
>
> /snajpa
>
> On 07/27/2016 04:18 AM, Pavel Snajdr wrote:
> > Je odkopirovano 9.5 TB z 22 TB.
> >
> > /snajpa
> >
> > On 07/26/2016 02:22 PM, Pavel Snajdr wrote:
> > > Aktualne je odsyncovano 5 TB dat z 22 TB celkem za cca 11 hodin, odhadem
> > > to znamena, ze se bude syncovat jeste cca dalsich 30 hodin.
> > >
> > > Behem toho je NAS dostupny jenom jako read-only.
> > >
> > > Potom pole znovu vyrobime a zacneme syncovat data zpatky, coz uz by melo
> > > jit rychleji (backuper ma vic disku, nez na kolika ma data soucasny
> > > nasbox, cili zpatky to pojede rychleji).
> > >
> > > Jedinou dalsi variantou, jak zpristupnit NAS rychleji, by bylo vsechna
> > > data zahodit a vyrobit na nem pool znova - a to, i kdyz vsude piseme, ze
> > > neni zalohovany, nam prislo jako mnohem horsi varianta, nez ho odstavit
> > > na par dni jako read-only.
> > >
> > > Odkopirujte si prosim data na VPSky, pokud je aplikace potrebuji, kdo
> > > kvuli tomu potrebujete docasne zvednout misto na disku, napiste na
> > > podporu a pokusime se to nejak vyresit.
> > >
> > > Pokud ta data nepotrebuji aplikace k behu, tak na to prosim nesahejte,
> > > od toho to syncujeme na backuper, abychom zachranili, co se da.
> > >
> > > Zatim dalsi chyby na poolu nenaskocily, poskozenych je, zda se, opravdu
> > > jenom 58 souboru (a to jeste ne uplne, ale maji poskozenych par bitu,
> > > coz se napr. u obrazku da jeste prezit - vs. ztratit je uplne).
> > >
> > > /snajpa
> > >
> > > On 07/26/2016 03:41 AM, Pavel Snajdr wrote:
> > > > Ahojte,
> > > >
> > > > na NASu doslo k poskozeni jednoho z raid-z VDEVu na ZFS poolu s daty.
> > > >
> > > > Stalo se to pri obnovovani toho vdevu (neco jako sub-raid-pole) po umrti
> > > > jednoho disku, kdy dalsi disk ze stejneho vdevu zacal hlasit chyby pri
> > > > cteni. Evidentne od posledniho scrubu (cca mesic zpatky) na nem vznikly
> > > > neopravitelne oblasti, ktere nejdou precist.
> > > >
> > > > Zatim vime o 58 neobnovitelnych souborech, je to ve stavu, kdy ten disk
> > > > dava nejaka data, cili to nevypada ze by bylo po datech, ale vic se
> > > > dozvime, jakmile dobehne sync z nasboxu na backuper.
> > > >
> > > > Prepnul jsem nasbox do readonly rezimu, aby se predeslo dalsimu
> > > > poskozovani dat a mezi tim se data syncuji na backuper (aktualne to jede
> > > > okolo 150MB/s a je to 22TB dat).
> > > >
> > > > Potom, co se data dosyncuji, znovu vyrobim pool na nasboxu s bezpecnejsi
> > > > konfiguraci, aby se podobne situaci predeslo a pool vydrzel umrti vic
> > > > disku ve vsech pripadech.
> > > >
> > > > Tem, co se jich poskozena data tykaji, napiseme behem dne mail se
> > > > seznamem poskozenych souboru.
> > > >
> > > > Budu dal updatovat o prubehu, jakmile bude dalsi progress.
> > > >
> > > > /snajpa
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > Outage-list mailing list
> > > > Outage-list(a)lists.vpsfree.cz (mailto:Outage-list@lists.vpsfree.cz)
> > > > http://lists.vpsfree.cz/listinfo/outage-list
> > > >
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > Outage-list mailing list
> > > Outage-list(a)lists.vpsfree.cz (mailto:Outage-list@lists.vpsfree.cz)
> > > http://lists.vpsfree.cz/listinfo/outage-list
> > >
> >
> >
> >
> >
> > _______________________________________________
> > Outage-list mailing list
> > Outage-list(a)lists.vpsfree.cz (mailto:Outage-list@lists.vpsfree.cz)
> > http://lists.vpsfree.cz/listinfo/outage-list
> >
>
>
> _______________________________________________
> Outage-list mailing list
> Outage-list(a)lists.vpsfree.cz (mailto:Outage-list@lists.vpsfree.cz)
> http://lists.vpsfree.cz/listinfo/outage-list
>
>
10Gbit
Mám tam jednu z destinací crashplanu, přišel bych nejspíše o X
předchozích verzí souborů dozadu + smazaných, co jsem neposlal do
crashplaního cloudu - ale orig data mám, takže krom mrzení s
přenastavením crashplanu bych asi ani moc nebrečel...
J
Dne Čt, 28. červenec 2016 v 16:25 h uživatel David Kopecký napsal:
> Ahoj,
>
> rozhodne puvodni plan, 10Gbit. I kdyz jsem se chystal vyuzit NAS na
> trochu citlivejsi "produkcni" veci v nasledujici dobe, tak kdyz to
> nebude rychle pristupne, je to stejne prd platne.
>
> Dik,
> David
>
> čt 28. 7. 2016 v 15:54 odesílatel <kuba(a)ufiseru.cz> napsal:
>> Za mě momentálně raději síť, ale redundantní NAS hned po tom. A
>> důležité je to slovo "redundantní", aby si to někdo omylem nevyložil
>> jako "zálohovaný" :)
>>
>> -m.
>>
>>
>>
>> July 28 2016 3:37 PM, "Pavel Snajdr" <snajpa(a)snajpa.net> wrote:
>> > Samozrejme, ze to demokraticky nakonec rozhodne ten, kdo to
>> > odmaka a ma
>> > se o to pak starat, to je jasne :)
>> >
>> > Chtel jsem spis vedet, jak moc velky hlad je po redundantnim
>> > storage
>> > mimo VPS tak, aby mohl byt napr. sdileny mezi vice VPS pro
>> > produkcni data.
>> >
>> > Zatim to az tak nevypada.
>> >
>> > Napriklad mne zajimal prave nazor Igora, jelikoz ti tam maji, o
>> > cem vim,
>> > nejprodukcnejsi vec - kdyz nepocitam nejake ty firemni owncloudy,
>> > kterezto ale klidne mohly bezet rovnou z lokalnich disku u VPS
>> > (ale to
>> > by si ti dotycni museli priplatit za zalohovany disk space, ze...).
>> > Igor Szoke ma realny duvod nemit to lokalne, protoze je to hodne
>> > dat a
>> > kdyz ani on nema tezkou preferenci smerem k redundanci NASu,
>> > je, rekl
>> > bych, vcelku jasno, kterym smerem jit.
>> >
>> > /snajpa
>> >
>> > On 07/28/2016 03:30 PM, Miroslav Šedivý wrote:
>> >
>> >> Ahoj, za me urcite 10Gbit. Preci jen NAS je bonusova vec a
>> >> ucpana sit
>> >> postihne vsechny. Neni to tak? Nejsem proti zálohování dat na
>> >> NASu, ale
>> >> urcite az po upgrade sítě. Takovahle anketa je super, ale navzdory
>> >> demokratickým pravidlům, ktera ve vpsfree panuji by se to melo
>> >> rozhodnout s nadhledem a ne podle preferenci par diskutujících.
>> >>
>> >> Míra
>> >>
>> >> Dne 28. 7. 2016 15:23 napsal uživatel "Michal Zobec (ZOBEC
>> >> Consulting)"
>> >> <michal.zobec.news(a)gmail.com
>> >> <mailto:michal.zobec.news@gmail.com>>:
>> >>
>> >> Mě by se taky hodilo zajistit bezpečnost dat na NAS. Sice si toho
>> >> jsem vědom, že teď nejsou zálohována, ale kapacita NAS se mi hodně
>> >> líbí (i když tak intenzivně ji nepoužívám).
>> >>
>> >> …
>> >>
>> >> s přátelským pozdravem | best regards
>> >>
>> >> Michal Zobec | Senior IT Consultant, Project Manager
>> >> Mobil: +420 608960987 <tel:%2B420%20608960987> | Email:
>> >> michal(a)zobec.net <mailto:michal@zobec.net>
>> >> LinkedIn | Na volne noze
>> >>
>> >> ZOBEC Consulting | Renneska trida 393/12, 63900 Brno, Czech
>> >> Republic
>> >> web | blog | virtuální pc
>> >> Facebook | Twitter | LinkedIn | Google+
>> >>
>> >> Plánovaná nepřítomnost | Planned absence
>> >> (none)
>> >> …
>> >>
>> >> -----Original Message-----
>> >> From: community-list-bounces(a)lists.vpsfree.cz
>> >> <mailto:community-list-bounces@lists.vpsfree.cz>
>> >> [mailto:community-list-bounces@lists.vpsfree.cz
>> >> <mailto:community-list-bounces@lists.vpsfree.cz>] On Behalf Of
>> >> Pavel
>> >> Snajdr
>> >> Sent: Thursday, July 28, 2016 2:54 PM
>> >> To: vpsFree.cz Community list <community-list(a)lists.vpsfree.cz
>> >> <mailto:community-list@lists.vpsfree.cz>>
>> >> Subject: Re: [vpsFree.cz: community-list] [vpsFree: outage-
>> >> list] NAS
>> >> read-only, poskozeny filesystem
>> >>
>> >> Jo, ale to mas pravdu, ze je to za tebe, na ukor rychle site pro
>> >> vsechny (a s tim spojene vyhody, ze budeme konecne tusit, proc nam
>> >> server umrel v kernel panicu a podobne, protoze budeme mit kdump).
>> >>
>> >> Jak jsem psal, NAS od zacatku nemel byt redundantni, takze
>> >> pokud ho
>> >> prave ted vyuzivas na produkcni data, delas to spatne a tenhle
>> >> hlas
>> >> bych tedy vubec nemel pocitat.
>> >>
>> >> A tak uvidime, co reknou dalsi :)
>> >>
>> >> /snajpa
>> >>
>> >> On 07/28/2016 02:29 PM, Vojtěch Knyttl wrote:
>> >>> Za mě určitě platí, že data bez redundance (ať produkční nebo
>> >>> neprodukční), jako by jich nebylo. Za mě klidně budu mít míň
>> >>> storage,
>> >>> ale bezpečnou.
>> >>>
>> >>> Vojtěch Knyttl
>> >>>
>> >>>
>> >>> knyttl(a)goout.cz <mailto:knyttl@goout.cz>
>> >>>
>> >>> +420 607 008 510 <tel:%2B420%20607%20008%20510>
>> >>>
>> >>> https://goout.cz
>> >>>
>> >>>
>> >>> On Thursday 28. July 2016 at 14:24, Pavel Snajdr wrote:
>> >>>
>> >>>> Prave bezi posledni dosyncnuti dat, odhadem za 2-3 hodiny
>> >>>> prepneme
>> >>>> mounty read-only na backuper, znovu vytvorime pool na nasboxu s
>> >>>> bezpecnejsi konfiguraci.
>> >>>> Pouijeme vetsi raidz2, pripadne raidz3 VDEVy, sebehnu si nejake
>> >>>> benchmarky tech konfiguraci, co mne napadaji jako prijatelne a
>> >>>> uvidime, co z toho vyleze, stejna konfigurace se potom casem
>> >>>> pouzije
>> >>>> i pro backuper, abychom se vyhnuli stejne situaci v budoucnu na
>> >> backuperu.
>> >>>>
>> >>>> K tomu, proc jsou v tom poolu disky se slabou redundanci, ie.
>> >>>> 3-diskove
>> >>>> RAID-Z: je to historicky dane tim, ze jak backuper, tak nasbox
>> >>>> vznikly s malo disky a ZFS neumi reshape poli, pridavanim
>> >>>> bezpecnejsich VDEVu bychom nic neziskali, protoze ten VDEV,
>> >>>> ktery se
>> >>>> rozbil, byl hned ten druhy v poradi, ktery tam byl uz pri prvnim
>> >> vyrobeni pole.
>> >>>>
>> >>>> Kdybychom pouzili z fleku bezpecnejsi konfiguraci, to pole by
>> >>>> tragicky nestihalo na IOPS.
>> >>>>
>> >>>> A jeste k tomu, jak NAS vubec vzniknul - to bylo tak, ze nam
>> >>>> prebylo
>> >>>> zalohovaci pole, ktere ale uz bylo male na to, aby delalo mirror
>> >>>> zaloham a nechteli jsme ho nechat valet jen tak, proto jsme ho
>> >>>> zpristupnili vsem a od zacatku rikali, ze neni zalohovane -
>> >>>> mysleli
>> >>>> jsme si, ze to pole vyuzijete na zalohy domacich dat a podobne,
>> >>>> coz
>> >>>> tedy vetsina udelala, ale...
>> >>>>
>> >>>> Nasli se i taci, kteri pres to vsechno dali na NAS produkcni
>> >>>> data a
>> >>>> ted je cekalo velmi neprijemne prekvapeni.
>> >>>>
>> >>>> Cili ted stojime pred rozhodnutim, jestli investovat do
>> >>>> redundance
>> >>>> NASu (a backuperu s tim), nebo jit podle puvodniho planu a
>> >>>> upgradovat
>> >>>> sit na 10Gbit (coz je potreba pro lepsi debugovatelnost
>> >>>> clusteru,
>> >>>> kvuli kdumpu; a taky jsem se chystal nejak vyresit replikaci dat
>> >> mezi nody).
>> >>>>
>> >>>> Co si o tom myslite? Investovat do storage a nechat to zatim na
>> >>>> 2Gbit
>> >>>> siti (ktera je, nutno rict, sem tam, uz pekne na hrane s
>> >> propustnosti)?
>> >>>>
>> >>>> Poznamecka: prosim ujistete se, ze v odpovedi je To:
>> >>>> community-list(a)lists.vpsfree.cz
>> >> <mailto:community-list@lists.vpsfree.cz>
>> >>>> <mailto:community-list@lists.vpsfree.cz
>> >> <mailto:community-list@lists.vpsfree.cz>>, na outage-list se musi
>> >>>> prispevky schvalovat a mely by tam jit jenom relevantni
>> >>>> informace o
>> >>>> vypadcich, ne diskuze.
>> >>>>
>> >>>> /snajpa
>> >>>>
>> >>>> On 07/27/2016 04:18 AM, Pavel Snajdr wrote:
>> >>>>> Je odkopirovano 9.5 TB z 22 TB.
>> >>>>>
>> >>>>> /snajpa
>> >>>>>
>> >>>>> On 07/26/2016 02:22 PM, Pavel Snajdr wrote:
>> >>>>>> Aktualne je odsyncovano 5 TB dat z 22 TB celkem za cca 11
>> >>>>>> hodin,
>> >>>>>> odhadem to znamena, ze se bude syncovat jeste cca dalsich 30
>> >>>>>> hodin.
>> >>>>>>
>> >>>>>> Behem toho je NAS dostupny jenom jako read-only.
>> >>>>>>
>> >>>>>> Potom pole znovu vyrobime a zacneme syncovat data zpatky, coz
>> >>>>>> uz by
>> >>>>>> melo jit rychleji (backuper ma vic disku, nez na kolika ma
>> >>>>>> data
>> >>>>>> soucasny nasbox, cili zpatky to pojede rychleji).
>> >>>>>>
>> >>>>>> Jedinou dalsi variantou, jak zpristupnit NAS rychleji, by bylo
>> >>>>>> vsechna data zahodit a vyrobit na nem pool znova - a to, i
>> >>>>>> kdyz
>> >>>>>> vsude piseme, ze neni zalohovany, nam prislo jako mnohem horsi
>> >>>>>> varianta, nez ho odstavit na par dni jako read-only.
>> >>>>>>
>> >>>>>> Odkopirujte si prosim data na VPSky, pokud je aplikace
>> >>>>>> potrebuji,
>> >>>>>> kdo kvuli tomu potrebujete docasne zvednout misto na disku,
>> >>>>>> napiste
>> >>>>>> na podporu a pokusime se to nejak vyresit.
>> >>>>>>
>> >>>>>> Pokud ta data nepotrebuji aplikace k behu, tak na to prosim
>> >>>>>> nesahejte, od toho to syncujeme na backuper, abychom
>> >> zachranili, co se da.
>> >>>>>>
>> >>>>>> Zatim dalsi chyby na poolu nenaskocily, poskozenych je, zda
>> >>>>>> se,
>> >>>>>> opravdu jenom 58 souboru (a to jeste ne uplne, ale maji
>> >>>>>> poskozenych
>> >>>>>> par bitu, coz se napr. u obrazku da jeste prezit - vs. ztratit
>> >> je uplne).
>> >>>>>>
>> >>>>>> /snajpa
>> >>>>>>
>> >>>>>> On 07/26/2016 03:41 AM, Pavel Snajdr wrote:
>> >>>>>>> Ahojte,
>> >>>>>>>
>> >>>>>>> na NASu doslo k poskozeni jednoho z raid-z VDEVu na ZFS poolu
>> >> s daty.
>> >>>>>>>
>> >>>>>>> Stalo se to pri obnovovani toho vdevu (neco jako sub-raid-
>> >>>>>>> pole) po
>> >>>>>>> umrti jednoho disku, kdy dalsi disk ze stejneho vdevu zacal
>> >>>>>>> hlasit
>> >>>>>>> chyby pri cteni. Evidentne od posledniho scrubu (cca mesic
>> >>>>>>> zpatky)
>> >>>>>>> na nem vznikly neopravitelne oblasti, ktere nejdou precist.
>> >>>>>>>
>> >>>>>>> Zatim vime o 58 neobnovitelnych souborech, je to ve stavu,
>> >>>>>>> kdy ten
>> >>>>>>> disk dava nejaka data, cili to nevypada ze by bylo po datech,
>> >>>>>>> ale
>> >>>>>>> vic se dozvime, jakmile dobehne sync z nasboxu na backuper.
>> >>>>>>>
>> >>>>>>> Prepnul jsem nasbox do readonly rezimu, aby se predeslo
>> >>>>>>> dalsimu
>> >>>>>>> poskozovani dat a mezi tim se data syncuji na backuper
>> >>>>>>> (aktualne
>> >>>>>>> to jede okolo 150MB/s a je to 22TB dat).
>> >>>>>>>
>> >>>>>>> Potom, co se data dosyncuji, znovu vyrobim pool na nasboxu s
>> >>>>>>> bezpecnejsi konfiguraci, aby se podobne situaci predeslo a
>> >>>>>>> pool
>> >>>>>>> vydrzel umrti vic disku ve vsech pripadech.
>> >>>>>>>
>> >>>>>>> Tem, co se jich poskozena data tykaji, napiseme behem dne
>> >>>>>>> mail se
>> >>>>>>> seznamem poskozenych souboru.
>> >>>>>>>
>> >>>>>>> Budu dal updatovat o prubehu, jakmile bude dalsi progress.
>> >>>>>>>
>> >>>>>>> /snajpa
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> _______________________________________________
>> >>>>>>> Outage-list mailing list
>> >>>>>>> Outage-list(a)lists.vpsfree.cz
>> >> <mailto:Outage-list@lists.vpsfree.cz>
>> >> <mailto:Outage-list@lists.vpsfree.cz
>> >> <mailto:Outage-list@lists.vpsfree.cz>>
>> >>>>>>> http://lists.vpsfree.cz/listinfo/outage-list
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> _______________________________________________
>> >>>>>> Outage-list mailing list
>> >>>>>> Outage-list(a)lists.vpsfree.cz
>> >> <mailto:Outage-list@lists.vpsfree.cz>
>> >> <mailto:Outage-list@lists.vpsfree.cz
>> >> <mailto:Outage-list@lists.vpsfree.cz>>
>> >>>>>> http://lists.vpsfree.cz/listinfo/outage-list
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> _______________________________________________
>> >>>>> Outage-list mailing list
>> >>>>> Outage-list(a)lists.vpsfree.cz
>> >> <mailto:Outage-list@lists.vpsfree.cz>
>> >> <mailto:Outage-list@lists.vpsfree.cz
>> >> <mailto:Outage-list@lists.vpsfree.cz>>
>> >>>>> http://lists.vpsfree.cz/listinfo/outage-list
>> >>>> _______________________________________________
>> >>>> Outage-list mailing list
>> >>>> Outage-list(a)lists.vpsfree.cz
>> >> <mailto:Outage-list@lists.vpsfree.cz>
>> >> <mailto:Outage-list@lists.vpsfree.cz
>> >> <mailto:Outage-list@lists.vpsfree.cz>>
>> >>>> http://lists.vpsfree.cz/listinfo/outage-list
>> >>>
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> Community-list mailing list
>> >>> Community-list(a)lists.vpsfree.cz
>> >> <mailto:Community-list@lists.vpsfree.cz>
>> >>> http://lists.vpsfree.cz/listinfo/community-list
>> >>>
>> >>
>> >> _______________________________________________
>> >> Community-list mailing list
>> >> Community-list(a)lists.vpsfree.cz <mailto:Community-
>> >> list(a)lists.vpsfree.cz>
>> >> http://lists.vpsfree.cz/listinfo/community-list
>> >>
>> >> _______________________________________________
>> >> Community-list mailing list
>> >> Community-list(a)lists.vpsfree.cz
>> >> http://lists.vpsfree.cz/listinfo/community-list
>> >
>> > _______________________________________________
>> > Community-list mailing list
>> > Community-list(a)lists.vpsfree.cz
>> > http://lists.vpsfree.cz/listinfo/community-list
>> _______________________________________________
>> Community-list mailing list
>> Community-list(a)lists.vpsfree.cz
>> http://lists.vpsfree.cz/listinfo/community-list
> _________________________________________________
> Community-list mailing list
> Community-list(a)lists.vpsfree.cz
> http://lists.vpsfree.cz/listinfo/community-list
Ahoj,
můžete se prosím podělit o své dlouhodobější zkušenosti s našimi komerčními poskytovateli vpsek a některé doporučit?
Co jsem se tak letmo díval na některá srovnání, tak úplně důvěryhodně nevypadají. Není to prosím provokace směrem k vpsfree a výpadkům, tady naopak za sebe musím kluky co se starají pochválit, ale potřebuji pro jeden projekt vps s SLA.
Osobně mám zkušenost se 2:
digitalocean.com - 20$/měsíčně, 2x Intel(R) Xeon(R) CPU E5-2650L v3 @ 1.80GHz, 2GB RAM, 40GB SSD
I když relativně krátkou dobu (půl roku), až na jeden restart z jejich strany na začátku jsem zatím nezaznamenal žádný výpadek, ale výkon CPU mi přijde nic moc (ale to jsem asi zhýčkaný vpsfree) a taky mě nebaví posílat peníze mimo ČR + asi o 17ms vyšší odezva do Frankfurtu.
wedos.cz :-) - 160 Kč / měsíc bez DPH, 1x CPU blíže neurčený Xeon 1.7GHz, 2GB RAM, 15GB SSD
Zkušenost mám zhruba rok, co 2 měsíce to výpadek kolem 5min, výkon chabý (ale asi odpovídá parametrům). Když jsem objednával, byla to nejlevnější varianta s SSD, za IPv4 (která není součástí) chtěli 30 nebo 40 kaček měsíčně navíc, dnes ale mají v ceníku 1 Kč.
Jinak z mého chabého gůglení jsem déle času strávil nad https://www.zonercloud.cz/produkty/cloud-server-linux/ <https://www.zonercloud.cz/produkty/cloud-server-linux/>, jestli s nimi má někdo zkušenost, prosím podělte se.
Díky, Nikos
Jinak pro predstavu, co by znamenala redundance NASu:
Soucasny nasbox je pro redundanci nevhodny, protoze ma SATA disky a ty
umi jenom jednoho hosta, cili kdyz upadne head node toho storage, je
potreba SAS disku, aby mohl zacit servovat data druhy head node.
SAS umozni tedy pripojit k jednomu disku dva servery (v tomhle pripade,
jak bychom ho pouzili).
Soucasny nasbox by se pak pouzil na zalohy dat z SAS NASu a zrejme i
backuperu, cili by byla data na SAS NASu, a na soucasnem hw, ktery dela
NAS, by byla near-realtime kopie (par minut stara data, periodicky
send/recv).
Tady pri te replikaci bychom ovsem asi vyrazne breceli bez 10Gbit site.
Pokud vezmeme variantu 10Gbit site, tak by NAS zustal, jak je, backuper
to same (pricemz je oba dostaneme na prijatelnejsi konfiguraci datove
redundance na urovni disku, ale budou mit vzdycky jenom jeden head node).
Celkove muzu rict, ze s heady tech storage poli az tak problem neni a
pokud budou data ulozene bezpecneji, nez jsou ted (ie. jina konfigurace
disku v ramci toho pole), tak jedine, co tem polim realne hrozi do
budoucna je to, ze upadne head node.
All said, mame taky moznost ten SAS NAS postavit casem, az po 10Gbit siti.
/snajpa
On 07/28/2016 02:24 PM, Pavel Snajdr wrote:
> Prave bezi posledni dosyncnuti dat, odhadem za 2-3 hodiny prepneme
> mounty read-only na backuper, znovu vytvorime pool na nasboxu s
> bezpecnejsi konfiguraci.
> Pouijeme vetsi raidz2, pripadne raidz3 VDEVy, sebehnu si nejake
> benchmarky tech konfiguraci, co mne napadaji jako prijatelne a uvidime,
> co z toho vyleze, stejna konfigurace se potom casem pouzije i pro
> backuper, abychom se vyhnuli stejne situaci v budoucnu na backuperu.
>
> K tomu, proc jsou v tom poolu disky se slabou redundanci, ie. 3-diskove
> RAID-Z: je to historicky dane tim, ze jak backuper, tak nasbox vznikly s
> malo disky a ZFS neumi reshape poli, pridavanim bezpecnejsich VDEVu
> bychom nic neziskali, protoze ten VDEV, ktery se rozbil, byl hned ten
> druhy v poradi, ktery tam byl uz pri prvnim vyrobeni pole.
>
> Kdybychom pouzili z fleku bezpecnejsi konfiguraci, to pole by tragicky
> nestihalo na IOPS.
>
> A jeste k tomu, jak NAS vubec vzniknul - to bylo tak, ze nam prebylo
> zalohovaci pole, ktere ale uz bylo male na to, aby delalo mirror zaloham
> a nechteli jsme ho nechat valet jen tak, proto jsme ho zpristupnili vsem
> a od zacatku rikali, ze neni zalohovane - mysleli jsme si, ze to pole
> vyuzijete na zalohy domacich dat a podobne, coz tedy vetsina udelala, ale...
>
> Nasli se i taci, kteri pres to vsechno dali na NAS produkcni data a ted
> je cekalo velmi neprijemne prekvapeni.
>
> Cili ted stojime pred rozhodnutim, jestli investovat do redundance NASu
> (a backuperu s tim), nebo jit podle puvodniho planu a upgradovat sit na
> 10Gbit (coz je potreba pro lepsi debugovatelnost clusteru, kvuli kdumpu;
> a taky jsem se chystal nejak vyresit replikaci dat mezi nody).
>
> Co si o tom myslite? Investovat do storage a nechat to zatim na 2Gbit
> siti (ktera je, nutno rict, sem tam, uz pekne na hrane s propustnosti)?
>
> Poznamecka: prosim ujistete se, ze v odpovedi je To:
> community-list(a)lists.vpsfree.cz, na outage-list se musi prispevky
> schvalovat a mely by tam jit jenom relevantni informace o vypadcich, ne
> diskuze.
>
> /snajpa
>
> On 07/27/2016 04:18 AM, Pavel Snajdr wrote:
>> Je odkopirovano 9.5 TB z 22 TB.
>>
>> /snajpa
>>
>> On 07/26/2016 02:22 PM, Pavel Snajdr wrote:
>>> Aktualne je odsyncovano 5 TB dat z 22 TB celkem za cca 11 hodin, odhadem
>>> to znamena, ze se bude syncovat jeste cca dalsich 30 hodin.
>>>
>>> Behem toho je NAS dostupny jenom jako read-only.
>>>
>>> Potom pole znovu vyrobime a zacneme syncovat data zpatky, coz uz by melo
>>> jit rychleji (backuper ma vic disku, nez na kolika ma data soucasny
>>> nasbox, cili zpatky to pojede rychleji).
>>>
>>> Jedinou dalsi variantou, jak zpristupnit NAS rychleji, by bylo vsechna
>>> data zahodit a vyrobit na nem pool znova - a to, i kdyz vsude piseme, ze
>>> neni zalohovany, nam prislo jako mnohem horsi varianta, nez ho odstavit
>>> na par dni jako read-only.
>>>
>>> Odkopirujte si prosim data na VPSky, pokud je aplikace potrebuji, kdo
>>> kvuli tomu potrebujete docasne zvednout misto na disku, napiste na
>>> podporu a pokusime se to nejak vyresit.
>>>
>>> Pokud ta data nepotrebuji aplikace k behu, tak na to prosim nesahejte,
>>> od toho to syncujeme na backuper, abychom zachranili, co se da.
>>>
>>> Zatim dalsi chyby na poolu nenaskocily, poskozenych je, zda se, opravdu
>>> jenom 58 souboru (a to jeste ne uplne, ale maji poskozenych par bitu,
>>> coz se napr. u obrazku da jeste prezit - vs. ztratit je uplne).
>>>
>>> /snajpa
>>>
>>> On 07/26/2016 03:41 AM, Pavel Snajdr wrote:
>>>> Ahojte,
>>>>
>>>> na NASu doslo k poskozeni jednoho z raid-z VDEVu na ZFS poolu s daty.
>>>>
>>>> Stalo se to pri obnovovani toho vdevu (neco jako sub-raid-pole) po umrti
>>>> jednoho disku, kdy dalsi disk ze stejneho vdevu zacal hlasit chyby pri
>>>> cteni. Evidentne od posledniho scrubu (cca mesic zpatky) na nem vznikly
>>>> neopravitelne oblasti, ktere nejdou precist.
>>>>
>>>> Zatim vime o 58 neobnovitelnych souborech, je to ve stavu, kdy ten disk
>>>> dava nejaka data, cili to nevypada ze by bylo po datech, ale vic se
>>>> dozvime, jakmile dobehne sync z nasboxu na backuper.
>>>>
>>>> Prepnul jsem nasbox do readonly rezimu, aby se predeslo dalsimu
>>>> poskozovani dat a mezi tim se data syncuji na backuper (aktualne to jede
>>>> okolo 150MB/s a je to 22TB dat).
>>>>
>>>> Potom, co se data dosyncuji, znovu vyrobim pool na nasboxu s bezpecnejsi
>>>> konfiguraci, aby se podobne situaci predeslo a pool vydrzel umrti vic
>>>> disku ve vsech pripadech.
>>>>
>>>> Tem, co se jich poskozena data tykaji, napiseme behem dne mail se
>>>> seznamem poskozenych souboru.
>>>>
>>>> Budu dal updatovat o prubehu, jakmile bude dalsi progress.
>>>>
>>>> /snajpa
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Outage-list mailing list
>>>> Outage-list(a)lists.vpsfree.cz
>>>> http://lists.vpsfree.cz/listinfo/outage-list
>>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Outage-list mailing list
>>> Outage-list(a)lists.vpsfree.cz
>>> http://lists.vpsfree.cz/listinfo/outage-list
>>>
>>
>>
>>
>> _______________________________________________
>> Outage-list mailing list
>> Outage-list(a)lists.vpsfree.cz
>> http://lists.vpsfree.cz/listinfo/outage-list
>>
>
>
>
> _______________________________________________
> Outage-list mailing list
> Outage-list(a)lists.vpsfree.cz
> http://lists.vpsfree.cz/listinfo/outage-list
>
Podle mne určitě upgrade síťové infrastruktury.
Vždycky bylo deklarováno jak NAS funguje a pokud to někdo ignoruje, no
co na to říct. Osobně v tomto kroku pozoruji více výhod pro celý projekt
a jeho rozvoj, zvláště pokud bude mít tenhle krok (kdump,...) vliv na
vylepšení produkčního prostředí, o to by mělo jít v první řadě.
ETNyx
On 07/28/2016 02:24 PM, Pavel Snajdr wrote:
> Prave bezi posledni dosyncnuti dat, odhadem za 2-3 hodiny prepneme
> mounty read-only na backuper, znovu vytvorime pool na nasboxu s
> bezpecnejsi konfiguraci.
> Pouijeme vetsi raidz2, pripadne raidz3 VDEVy, sebehnu si nejake
> benchmarky tech konfiguraci, co mne napadaji jako prijatelne a uvidime,
> co z toho vyleze, stejna konfigurace se potom casem pouzije i pro
> backuper, abychom se vyhnuli stejne situaci v budoucnu na backuperu.
>
> K tomu, proc jsou v tom poolu disky se slabou redundanci, ie. 3-diskove
> RAID-Z: je to historicky dane tim, ze jak backuper, tak nasbox vznikly s
> malo disky a ZFS neumi reshape poli, pridavanim bezpecnejsich VDEVu
> bychom nic neziskali, protoze ten VDEV, ktery se rozbil, byl hned ten
> druhy v poradi, ktery tam byl uz pri prvnim vyrobeni pole.
>
> Kdybychom pouzili z fleku bezpecnejsi konfiguraci, to pole by tragicky
> nestihalo na IOPS.
>
> A jeste k tomu, jak NAS vubec vzniknul - to bylo tak, ze nam prebylo
> zalohovaci pole, ktere ale uz bylo male na to, aby delalo mirror zaloham
> a nechteli jsme ho nechat valet jen tak, proto jsme ho zpristupnili vsem
> a od zacatku rikali, ze neni zalohovane - mysleli jsme si, ze to pole
> vyuzijete na zalohy domacich dat a podobne, coz tedy vetsina udelala, ale...
>
> Nasli se i taci, kteri pres to vsechno dali na NAS produkcni data a ted
> je cekalo velmi neprijemne prekvapeni.
>
> Cili ted stojime pred rozhodnutim, jestli investovat do redundance NASu
> (a backuperu s tim), nebo jit podle puvodniho planu a upgradovat sit na
> 10Gbit (coz je potreba pro lepsi debugovatelnost clusteru, kvuli kdumpu;
> a taky jsem se chystal nejak vyresit replikaci dat mezi nody).
>
> Co si o tom myslite? Investovat do storage a nechat to zatim na 2Gbit
> siti (ktera je, nutno rict, sem tam, uz pekne na hrane s propustnosti)?
>
> Poznamecka: prosim ujistete se, ze v odpovedi je To:
> community-list(a)lists.vpsfree.cz, na outage-list se musi prispevky
> schvalovat a mely by tam jit jenom relevantni informace o vypadcich, ne
> diskuze.
>
> /snajpa
>
> On 07/27/2016 04:18 AM, Pavel Snajdr wrote:
>> Je odkopirovano 9.5 TB z 22 TB.
>>
>> /snajpa
>>
>> On 07/26/2016 02:22 PM, Pavel Snajdr wrote:
>>> Aktualne je odsyncovano 5 TB dat z 22 TB celkem za cca 11 hodin, odhadem
>>> to znamena, ze se bude syncovat jeste cca dalsich 30 hodin.
>>>
>>> Behem toho je NAS dostupny jenom jako read-only.
>>>
>>> Potom pole znovu vyrobime a zacneme syncovat data zpatky, coz uz by melo
>>> jit rychleji (backuper ma vic disku, nez na kolika ma data soucasny
>>> nasbox, cili zpatky to pojede rychleji).
>>>
>>> Jedinou dalsi variantou, jak zpristupnit NAS rychleji, by bylo vsechna
>>> data zahodit a vyrobit na nem pool znova - a to, i kdyz vsude piseme, ze
>>> neni zalohovany, nam prislo jako mnohem horsi varianta, nez ho odstavit
>>> na par dni jako read-only.
>>>
>>> Odkopirujte si prosim data na VPSky, pokud je aplikace potrebuji, kdo
>>> kvuli tomu potrebujete docasne zvednout misto na disku, napiste na
>>> podporu a pokusime se to nejak vyresit.
>>>
>>> Pokud ta data nepotrebuji aplikace k behu, tak na to prosim nesahejte,
>>> od toho to syncujeme na backuper, abychom zachranili, co se da.
>>>
>>> Zatim dalsi chyby na poolu nenaskocily, poskozenych je, zda se, opravdu
>>> jenom 58 souboru (a to jeste ne uplne, ale maji poskozenych par bitu,
>>> coz se napr. u obrazku da jeste prezit - vs. ztratit je uplne).
>>>
>>> /snajpa
>>>
>>> On 07/26/2016 03:41 AM, Pavel Snajdr wrote:
>>>> Ahojte,
>>>>
>>>> na NASu doslo k poskozeni jednoho z raid-z VDEVu na ZFS poolu s daty.
>>>>
>>>> Stalo se to pri obnovovani toho vdevu (neco jako sub-raid-pole) po umrti
>>>> jednoho disku, kdy dalsi disk ze stejneho vdevu zacal hlasit chyby pri
>>>> cteni. Evidentne od posledniho scrubu (cca mesic zpatky) na nem vznikly
>>>> neopravitelne oblasti, ktere nejdou precist.
>>>>
>>>> Zatim vime o 58 neobnovitelnych souborech, je to ve stavu, kdy ten disk
>>>> dava nejaka data, cili to nevypada ze by bylo po datech, ale vic se
>>>> dozvime, jakmile dobehne sync z nasboxu na backuper.
>>>>
>>>> Prepnul jsem nasbox do readonly rezimu, aby se predeslo dalsimu
>>>> poskozovani dat a mezi tim se data syncuji na backuper (aktualne to jede
>>>> okolo 150MB/s a je to 22TB dat).
>>>>
>>>> Potom, co se data dosyncuji, znovu vyrobim pool na nasboxu s bezpecnejsi
>>>> konfiguraci, aby se podobne situaci predeslo a pool vydrzel umrti vic
>>>> disku ve vsech pripadech.
>>>>
>>>> Tem, co se jich poskozena data tykaji, napiseme behem dne mail se
>>>> seznamem poskozenych souboru.
>>>>
>>>> Budu dal updatovat o prubehu, jakmile bude dalsi progress.
>>>>
>>>> /snajpa
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Outage-list mailing list
>>>> Outage-list(a)lists.vpsfree.cz
>>>> http://lists.vpsfree.cz/listinfo/outage-list
>>>>
>>>
>>>
>>> _______________________________________________
>>> Outage-list mailing list
>>> Outage-list(a)lists.vpsfree.cz
>>> http://lists.vpsfree.cz/listinfo/outage-list
>>>
>>
>>
>> _______________________________________________
>> Outage-list mailing list
>> Outage-list(a)lists.vpsfree.cz
>> http://lists.vpsfree.cz/listinfo/outage-list
>>
>
>
> _______________________________________________
> Outage-list mailing list
> Outage-list(a)lists.vpsfree.cz
> http://lists.vpsfree.cz/listinfo/outage-list