Tak jde život... (Anebo co nového ve vpsFree.cz) (diskuse)

[Limoto]

 

Hlavní problém je v tom, že herní servery generují dost trafficu

Většina ne.

 

[snajpa]

Otázka je, co si představujeme pod pojmem dost trafficu. A taky záleží na vytížení - kolik hraje lidí, atd. v průběhu dne. Zatím tam máme asi 5 CS 1.6 serverů a jde to, to je pravda. Jenže ti lidi, co nám psali, že chtějí provozovat, to by generovalo fakt hodně trafficu (celej jeden komerční hosting CS serverů - to jsme museli zamítnout - na to se ani VPS moc nehodí, aby tam běželo nějakých 100 CS serverů - to už je na dedikovanou ne zrovna slabou mašinu).

[Limoto]

No, o CS:S serverech jsem slyšel, že geerují hodně trafficu, CS 1.6 nevím. Každopádně u ničeho jinýho jsem si toho nevšiml

[snajpa]

Pravda je, že nám tam nějakej ten tejden běžel GTA San Andreas Multiplayer server, plně public dokonce na listu veřejných serverů a traffic byl v řádech stovek MB (ale nevím kolik lidí na tom hrálo, což značně degraduje hodnotu takové informace).

[xkucf03]

Třeba mně tam běží veřejný Sauerbraten server a ten nežere skoro vůbec – viz svickova.frantovo.cz – kdybyste si chtěl někdo zahrát, tak napište na jabber.

[petr_p]

Jak veřejný, když je auth? Ale dobrý nakopnutí. Už dlouho plánuji dopsat IPv6 do Sauerbraten/enet.

[xkucf03]

ty se tam nepřihlásíš? já žádné heslo nezadávám a občas si tam i s někým zahraju

[petr_p]

Nevím, já jsem si jen vypsal seznam serverů a spletl jsem si, co dělá auth (autentizace setmaster). Připojit se lze, je to dobrý.

[xkucf03]

Asi bychom časem měli umístit jeden server do serverovny s neomezenými přenosy – pro tyhle případy – ať si pak lidi vyberou, jestli chtějí kvalitu a budou se držet trochu na uzdě, nebo chtějí neomezené přenosy a nevadí, že budou občas výpadky nebo problémy. Pak je tu ještě třetí možnost – neomezené přenosy a vysoká kvalita – myslím, že pokud to někdo zaplatí, není problém něco takového zorganizovat pod křídly našeho sdružení – ovšem cena se odvíjí od nabídky datacenter a s tím nic nenaděláme.

[petr_p]

Člověče, to vám výměna jádra dá vždycky tak zabrat?

Vždyť se prostě uvaří nové jádro, potřebné soubory se překopírují do /boot a až když je vše připraveno, tak se zavaděči řekne, ať pro tentokrát natáhne nové jádro. Pak dáme reboot a obvykle naběhne nové jádro (aby ne, když se používá oldconfig). Záležitost nejvýše dvou minut. Když se něco pokazí, tak stačí reset a najede starý systém a pak si může člověk v klidu rozmyslet, co udělal špatně. Po úspěšném bootu pak ještě zbývá kontrola, že vše, co má, běží, ale to už nemá vliv na dostupnost služeb. Po nějaké době (hodiny, dny), kdy je stabilita nového jádra prověřena, se v konfiguraci zavaděče přesune nové jádro do výchozí polohy a tím upgradovací cyklus končí.

[snajpa]

Asi takhle - uvařit vlastní jádro - mrkni se na http://git.openvz.org/ pro představu, kolik lidí se OpenVZ patchsetu věnuje. Navíc, když se něco nepovede, volám podporu Master Internet aby připojili KVM k serveru, což trvá nejdýl (takovejch 10minut). A koukám, že já blbec jsem tam zapomněl napsat, že jsem měl problémy s firewallem, jak jsem ladil tu podporu ve vpsAdminu a tak se mi povedlo ten výpadek prodloužit. To si piš, že jsem měl nervy v kýblu

[petr_p]

Jo tak, vy nemáte v serveru IPMI a testujete patche na ostrým stroji? To bych taky potřeboval kýbl.

[Jendа]

Proč nepoužíváte distribuční jádro? Nerýpu (protože ještě produkčně nevirtualizuji), ptám se .

[snajpa]

Právě že jsem přepínal z domavařeného na distribuční a kapku jsem se přepočítal a nekouknul na nastavení Grubu pořádně.

[Tomáš Srnka]

Myslim, ze tie jadra boli menene na dialku, v tom pripade chvilu trvalo, kym pripojili KVM .

[Tomáš Srnka]

nejak som to zle zaradil

[Heron]

V takovém případě ale stačilo na power switchi odpojit na chvíli napájení a server by nabootoval do starého jádra.

[snajpa]

To byla moje blbost. Přeci jenom se to pořád učím. Příště už by se to nemělo opakovat.

[Heron]

Jasně, chyby děláme všichni - je důležité se z nich umět poučit. Začátky jsou vždy těžké, ale po létech je to to na co člověk rád vzpomíná . Jen tak dál v dobře započaté práci.

[Ondrej 'SanTiago' Zajicek]

> V takovém případě ale stačilo na power switchi odpojit na chvíli napájení a server by nabootoval do starého jádra.

Pokud to mas tak v GRUBu nastavene.

[Michal Fecko]

Nejaké grafy záťaže CPU a diskov? najmä pri i7 ma to zaujíma vo špičke

[snajpa]

Alfa Beta

[Michal Fecko]

Hmmm, cpu bety sa teda oproti alfovemu Qcku riadne nudi - a to ma ak som to dobre pochopil viac ludi, nie?

[Heron]

Ten stroj beta nemá platný https certifikát. Je tam z alfy.

[Luboš Doležel (Doli)]

Z vlastních zkušeností z firmy můžu říct, že lidé s virtuály jsou nejnevděčnější zákazníci. Je mezi nimi až příliš mnoho lidí, co s Linuxem vůbec neumí, a to byste nevěřili, co s tím dokážou udělat! Jestli jste si mysleli, že není možné Linux zavirovat, jste na omylu!

[Michal Fecko]

Ako? Daj priklad, pls :-]

[Luboš Doležel (Doli)]

To kdybych věděl Ale šikovně se ty stvůry maskujou. Jen je vám pak divný, když bash dělá TCP spojení...

[Michal Fecko]

ale to je potom vazne, nie? som netusil ze Linux je tak lahko napadnutelny... prakticky som realne pouzitelny virus pre Linux osobne ani nevidel...

[Luboš Doležel (Doli)]

Není to vážné, spíš s majiteli serverů je to vážné. Normálnímu smrtelníkovi se nemůže podařit nadělat tolik děr. Děravý CMS, slabé heslo na FTP, slabé heslo na SSH a už to lítá. A než aby si tam dali lepší hesla, tak chtějí omezovat IP adresy v iptables...

[trekker.dk]

Před nějakou dobou tady vyšla zprávička s odkazem na článek na téma napadnutelnost Linuxu. Jedním ze závěrů bylo to, že ELF binárky se dají napadnou velmi dobře.

[Michal Fecko]

Čiastočne offtopic - aké su vaše názory na tzv. skladané servery [povačšine lacnejšie, avšak iba jeden zdroj, sata disky bez hotplugu, jednoprocáková doska, do 16G RAM] vs. značkove servery [s dvojitym napajanim, hotplug SAS diskami, 16+ GB RAM, vyššiou cenou, prisposobenou šasi s poväčšine prepracovanejším prevedením [BIOS, HW a pod.]]?

[Heron]

Na domácí žvýkání je skládaný server dostačující.

[Michal Fecko]

A co ak ten server poskytuje komercne "zvykani" viacerym ludom [zakaznikom]?

[Heron]

To fakt ne.

Když už si to ti lidé platí, tak očekávají jistou kvalitu. Tu nelze dosáhnout se skládačkou z běžných komponent, některé ani neexistují - hledal jsem do své domácí stanice HW raid řadič (CPU + baterií zálohovanou cache). Do klasických PCI-E jsou to všechno fake raidy (a to ještě s minimálním počtem portů, takže ani na sw raid nepoužitelné), PCI-X nebo 64 v běžný desce zase nemáš). Sežeň běžnou desku třeba s ECC RAMkama . Zde je velmi tlustá čára oddělující servery a PC.

A když už začneš na koleně stavět server ze serverových komponent, tak velmi rychle zjistíš, že je to lepší koupit od profíků jako celek. Oni to testují, ladí výkonnost. PC jsou optimalizováné pro jeden thread (bohužel i CPU i7 - turbo režim - a to jsem se těšil, že se konečně programátoři naučí používat vlákna), server je celkově stavěn pro multiprocesový přístup. Dále tu je SW s HCL. Dát ESX na takový HW z jejich seznamu je hračka, najdeš na to spousty rad (které v konečném důsledku ani nepotřebuješ, protože to je testované), když něco neklapne (včetně podpory od výrobce).

[Bluebear]

Když už si to ti lidé platí, tak očekávají jistou kvalitu. Tu nelze dosáhnout se skládačkou z běžných komponent

Ony ty značkové stroje taky nejsou žádná sláva, tedy pokud vybíráš z levnějších modelů. Dostaneš víceméně totéž, jako by sis to složil doma, akorát výrobce má vyzkoušené, že to spolu jakžtakž funguje, nakoupil to levněji ve velkém, ušetřené peníze si strčil do kapsy a prodá ti to o dvacet procent dráž.

Máš ovšem velikou pravdu, že kvalitní komponenty (nebo přesněji komponenty, které nejsou úplný šunt) se shánějí setsakra těžko. To, co se prodává v běžných obchodech, je často totální vylevněný šunt vhodný jedině na smetiště. Kromě toho je nutné myslet na to, aby to spolu dokázalo rozumně spolupracovat a aby se to vůbec vešlo do bedny (na to jsem si několikrát hnusně naběhl).

Suma sumárum, koupí značkového stroje si člověk ušetří fůru běhání a nervů, ale o vyšší kvalitě bych si nedělal iluze - pokud nejdeš do velkého serveru, který je drahý jako svině.

Zálohovat, zálohovat, zálohovat, to je heslo dne.

[xxx]

Nadruhou stranu, pokud bude člověk těch servrů stavět třeba 20, tak už se to počáteční běhání může vyplatit.

[Bluebear]

Hmmm, 20 serverů, to stojí těžké prachy tak či tak

Přiznám, že tady bych asi měl těžké dilema.

Okamžitý výdaj bude určitě menší, když člověk navrhne jednu sestavu a koupí tutéž dvacetkrát plus daný počet náhradních dílů. Poměr cena/výkon bude také určitě lepší než u dvaceti ekvivalentních značkových strojů.

Ale: u takové farmičky už obvykle hraje velkou roli i to, jak rychle se to podaří opravit a nahodit, a se značkovými servery většinou přichází i lepší záruka. Ale zase až s těmi dražšími, u těch levných je to stejně bída.

Je otázka, jestli by se v takovém případě nevyplatilo koupit menší počet velkých, drahých serverů, které mívají jak velký výkon, tak profesionální záruku a servis.

[snajpa]

Ohledně vpsFree.cz jsem zastáncem levnýho a rychle nahraditelnýho hw, až to dotáhneme na vlastní rack, tak případnej servis chci řešit hrubou a rychlou výměnou kus za kus a obnovení dat ze zálohy. Btw - neví někdo o solidním, ne-kernel-patch-hnus FS, kterej se umí chovat jako RAID mirror po síti? (glusterFS vypadá zajímavě, takže něco dalšího?)

[snajpa]

Zapomněl jsem zmínit nutnost přístup k zápisu ze všech nodů.

[VSi]

Dokonce jsem se vás chystal zeptat, jaké řešení plánujete pro tu "online migraci".

Tohle jsem taky řešil, a použitelně vypadá snad už jen DRBD. Zdá se mi dost ověřený a funkční, na vlastní testování se teprve chystám. Jinak pár lidí tady už psalo, že s tím mají velmi dobré zkušenosti. Já mám pořád strach, že když něco takové zprovozním, budu se nejvíc bát aby se to nerozpadlo (stav split-brain, když si každý uzel myslí, že ten druhý spadnul).

Nad DRBD může být normálně Ext3 - pak může být FS připojen jen na jednom z uzlů. Nebo nějaký clusterový FS, třeba OCFS2 nebo GFS - pak můžete zapisovat z obou uzlů DRBD zároveň. Nebo lze mít nad DRBD svazkem clustered LVM pro Xen virtuální disky, pak lze dělat i živou migraci Xen guestů mezi fyzickými stroji.

[snajpa]

Online migraci řeší OpenVZ utilitka vzmigrate. Nejdřív sesyncne (přes ssh) stav virtuálů (rootfs, context - paměť, stav v jádře atd.) a pak jednoduše "přepne" mezi HW servery. Pravda je, že úspěšnost online migrace není 100%. To jsem ve vpsAdminu vyřešil fallbackem na offline migraci.

DRBD se mi osobně moc nezdá, jednak je to moc v kernelu, to má nic-moc výkon a je to nestabilní (aspoň co jsem to zkoušel naposled). Navíc to neumí pravej multimaster pro víc než 2 nody. Takže jediný řešení vidím v GlusterFS 2.

[VSi]

Online migraci řeší OpenVZ utilitka vzmigrate. Nejdřív sesyncne (přes ssh) stav virtuálů (rootfs, context - paměť, stav v jádře atd.) a pak jednoduše "přepne" mezi HW servery.

Hmm, tak to je docela pěkné.

K DRBD se dají najít informace o seriózním a stabilním nasazení, problémy s výkonem by neměly být zásadní (je samozřejmě nutné propojení Gb ethernetem, popř. více Gb rozhraní v trunku). Ale je pravda, že to bude citlivé na verzi jádra + verzi DRBD modulů, bude to chtít trochu ladění nebo zjistit ověřenou konfiguraci a moc na to nesahat. Pro víc než 2 stroje to taky není. Jako možné řešení bych viděl 2× storage server s výkonným s mnoha disky v HW RAIDu + replikace přes DRBD, podívejte se na distribuci OpenFiler, tam údajně iSCSI a DRBD funguje bezvadně. A k tomu hromadu serverů, na kterých poběží OpenVZ virtuální servery. Propojení přes iSCSI a nad tím GFS. Obecně bych asi čekal, že clusterové věci budou vyladěné v enterprise distribucích, při použití skoro-poslední verze jádra asi lze čekat problémy...

Až budete mít plný rack, můžete uvažovat o nějakém diskovém poli s iSCSI rozhraním.

Glusterfs vypadá hodně zajímavě, ale mě tam chybí podpora uživatelských kvót a ACL.

[snajpa]

Glusterfs vypadá hodně zajímavě, ale mě tam chybí podpora uživatelských kvót a ACL.

Tak to potom AFS nebo Lustre.

[VSi]

AFS – pokud myslíte Andrew File System, tak tam pokud vím ani replikace dat není. Je možné mít data ve více kopiích, ale jen jedna je RW, ostatní jen pro čtení. Nutnou součástí je Kerberos autentizace. Kouzlo AFS je v něčem jiném - je to globální filesystem, používá se v prostředí s desítkami tisíc uživatelů - např. univerzity (určitě na ZČU, jako hlavní síťový FS), CERN. Tady si vlastnostmi nejsem úplně jistý, ale pro tohle použití to není vhodná věc. AFS je distribuovaný - tj. data v rámci jedné adresářové struktury lze mít transparentně uložená na různých serverech.

Lustre – co jsem našel, tak je to pro clustery se stovkami až tisíci stroji, nic moc vhodného pro 3 servery.

viz http://en.wikipedia.org/wiki/Replication_(computer_science)#Disk_storage_replication

[snajpa]

ad AFS - nevěděl jsem. ad Lustre - no, je pravda že to je kapku overkill pro 3 stroje Smutnou pravdou je, že současnej stav není ideální ani u jednoho FS / replikačního cluster řešení. Ona to asi není žádná sranda to odladit tak, aby to jelo výkonně a spolehlivě.

Každopádně GlusterFS se hodí tam, kde není potřeba dělat psí kusy -> takže záloha, sdílená data pro nějakou aplikaci a podobně. Rootfs VPS na to stejně nejde umístit, to lze (u openvz) jenom na ext2/3.

[VSi]

S tím zhodnocením situace souhlasím. Holt kdo potřebuje takový výkon a spolehlivost, obvykle má prostředky i na pořízení nějakého plně HW řešení replikace, nebo alespoň diskového pole s redundantními řadiči a propojením k serverům. Software řešení na normálním HW stejně bude mít vždycky značné limity ve výkonnosti, takže po vývoji něčeho takového nebude až tak velká poptávka.

Pro méně náročné situace myslím stačí ten GlusterFS nebo DRBD, kde se zřejmě dá postavit spolehlivé řešení, i když ne úplně ideální a podle všech představ (poslední kernel etc.).

Jinak k takovéhle diskusi by měla sloužit i skupina Virtualizace (uvažovalo se snad o doplnění názvu + High Availability), kde si toho spíš někdo všimne. Určitě tam jsou lidé, kteří by k tomu měli co říct. Zkuste položit dotaz i tam.

[xxx]

Myslím, že nejde říct obecně ne. Záleží na tom jaké komponenty tam člověk vecpe. Pokud vezme nějakou 1U case, Intel Server Board a nějaký rozumný paměti a procesor. Tak má furt obstojný server za dobrý peníze. S tím diskovým subsystémem jste se trefil. Souhlasím s tím, že tam se asi láme chleba. Dokud stačí dva 1TB v sw RAID1, tak není co řešit. Když stačit přestanou, tak už stojí za to uvažovat o hotovém řešní.

[kapo]

 Mate to nejak pravidelne zalohovane? O necem takovem uvazuji pro osobni/komercni repozitar, ale bez zaloh bych do toho nesel.

[DoomDog]

No bolo by super keby alpha zalohovala betu navzajom (to najdolezitejsie) + nejake zalohy na 3. cisto backup server ...

[Heron]

Oni ti to zálohovat nebudou. Server na hostingu (a je jedno jestli fyzický či virtuální) si musíš zálohovat sám.

[snajpa]

No teď jsme to probírali a schválili, musím to implementovat.

[Heron]

Je to váš boj

Takže hromadu pásek, páskovou knihovnu a ohnivzdorný trezor na jiné lokalitě.

[trekker.dk]

To už je lepší samostatný zálohovací stroj s diskama - pravděpodobně to bude levnější než pásky a rozhodně to bude pohodlnější.

[snajpa]

To zas ne. Pro dobrotu na žebrotu? Timhle stylem by to asi nešlo. Prostě záloha do kříže mezi dvojicemi serverů a odchod na párek.

[snajpa]

To mělo bejt na Herona. Chjo.

[Heron]

No, však jsem psal, že to zálohovat nebudete .

Hele, neber to moje rýpání moc osobně. Ono je fakt lepší, když si člověk nabije čumák sám a přijde na to, že to měl dělat jinak.

Já koncem minulého roku moc potřeboval server na páteři a chtěl jsem pořídit HP ProLiant DL380 G5 a na to nasadit ESX(i). Skončilo to na čem? No na penězích. Ty máš odvahu a čas vzít rachotinu a odvést to na housing a nasadit tam něco co potřebuje patch do kernelu. I to se cení.

[thingie]

Jako by potřeba patche do kernelu něco znamenala.

[snajpa]

Zálohují se bude do kříže (alfa->beta a beta->alfa) 1x týdně přes vzdump - musím to odladit a spustím to někdy během dneška/zítřka. Momentálně není jak vymyslet jiný způsob.

[snajpa]

Píšu kraviny - správně je "Zálohovat se budou"

[Luboš Doležel (Doli)]

Co takhle lidem poskytnout místo, kam si mohou zálohy sami rsyncovat?

[snajpa]

Spíš bych to viděl na podporu "snapshotu" celého VPS ve vpsAdminu -> na kliknutí. Tak to ještě teda doprobereme.

[kapo]

 Nevim, jak OpenVZ funguje, jestli mate pristup do filesystemu virtualu, ale pokud jo, tak by mozna bylo nejlepsi zaloha: zakaznik nadefinuje adresare a ty se zalohuji. Precijen zalohovat cele virtualy muze byt prostorove celkem narocne...

[snajpa]

To není špatnej nápad. Mrknu na možnosti jak to vymyslet. (Přístup k FS virtuálů je, protože je to de facto jenom chroot)

[Michal Fecko]

Nieje to lepsie ked sa to bude robit celkovo a automaticky - preco by sa mal o nieco "zakaznik" starat?

[xkucf03]

Zase když jsou zálohy v režii zákazníka, tak si sám může vytáhnout třeba smazané soubory nebo přepsané konfiguráky ze zálohy – když se zálohuje všechno najednou, tak je to opruz, který musí dělat správce centrálního serveru. Docela zajímavý by byl solaris a jeho ZFS snapshoty – možná až budeme dělat další server…

[Limoto]

 

solaris a jeho ZFS snapshoty

A nebo taky FreeBSD...

 

[Heron]

preco by sa mal o nieco "zakaznik" starat?

Třeba proto, že to jsou jeho data?

[Jendа]

Protože mi třeba stačí zálohovat jenom databáze?

[MaFy]

Zatím jsem to tu nenašel, ale já se hlásím jako zájemce o soft

[snajpa]

Ok, až to uvedeme do (aspoň trochu) publikovatelnýho stavu (měsíc, dva - musíme dodělat přechod na gettext a PDO). S fancy one-command instalátorem ale zatím tak jako tak nepočítej

[default]

Jen malý dotaz: jakou máte dostupnost?

[snajpa]

https://alfa.vpsfree.cz/vpsadmin/?page=

[default]

Já se neptal na to, co vysype minun na základě historie, ale co garantuje občanské sdružení nebo čeho by chtěli administrátoři dosáhnout.

[xkucf03]

Neměří to minun ale nezávislý měřák

Čeho bychom chtěli dosáhnout? Co garantujeme? Ale no tak, naslibovat se dá cokoli, důležité jsou výsledky Chceš čtyři devitky, nebo víc, 100%? Slíbit můžeme cokoli, ale pokud chceš SLA a smluvní pokuty pokud nebude dodržená požadovaná dostupnost… budeš muset zvolit komerční dražší hosting. Pro dostupnost děláme to nejlepší, co umíme, ostatně, běží na tom i naše stroje.

[default]

Pro dostupnost děláme to nejlepší, co umíme, ostatně, běží na tom i naše stroje.

Díky, to mi stačí.