Efektivita virtualizace

Pavel Troller patrol na sinus.cz
Úterý Únor 24 09:22:31 CET 2015


Zdravím,

>
> Dne 24.2.2015 v 8:18 Petr Simek napsal(a):
>> On Tue, 24 Feb 2015, Admin HWnews wrote:
>>
>>> ale aplikace a OS maji problem jej vytizit -  na dvouprocesorovem
>>> sestijadru na 3GHz s 256GB RAM proste nic rozumneho nepustite abyste
>>> to utavil (bavim se o beznych aplikacich a beznych OS). Po
>>> virtualizaci se vam z toho stane masina, ktera se zjednodusene tvari
>>> jako server 1x 36GHz (2x6x3GHz), ktera
>>
>> To ne - kdyz definujete virtual tak mu pridelujete pocet jader, pamet
>> a disk, takze pocet jader co dostane ty ma , vic ne.
>
> No psal jsem, ze to je zjednodusenej vyklad a asi to nebylo uplne 
> stastne...spis jsem mel napsat, ze v podstate muzete kazdemu virtualu 
> pridelit cely vykon masiny a diky nerovnomerne zatezi (ve virtualech) se HW 
> opravdu vytizi tak jako byste ty jadra jel tak jako byste mel vykon CPU na 
> 36GHz - nemyslel jsem to tak, ze jeden virtual dostane 36GHz
>
>>> dokaze prelejvat vykon mezi virtualy (navic to muzete zdruzit do
>>> farmy, kde mate jednak zalohovatelnost a snadnou moznost navysovat
>>> vykonu jen pridavanim serveru) - pisu to zjednodusene neni to takhle
>>> primocare. Podobne je to i s
>>
>> Tohle reseni uz je ale za penize a navic potrebuje externi diskove pole
>> kde maji ty virtualy disky. Casem zjistite ze potrebuje zalohovat dalsim
>> diskovym polem a ze kdyz na nej navesite moc virtualu tak to zacne
>> zpomalovat na IOPS . Neni to tak ruzove.
> samozrejme ze to neni zadarmo a neni to ani levne (myslel jsem, ze kolega 
> se ptal zpocatku obecne a az pak jak to ctu to aplikoval na konkretni 
> reseni v malem).

To je zajímavé... A já si myslel, že OpenStack je zadarmo... Vůbec se divím,
že to tu nikdo nezmínil... Já dělám v Telco industry a tam na to přechází
naprostá většina vendorů, věci typu vmware se zdají být již na smetišti
dějin...

  Zdraví Pavel

> No vzhledem, ze ted prave migrujeme cely nas system na neco takoveho tak 
> vim, ze ze pole jsou opravdu nestestim - mame tu farmu pripojenou na dve 
> pole - je to zapojene nejak krizem (nejsem fakt architekturar) - uz tyden 
> migruju data ze Sybase pod Win na Sybase bezicim na Solarisu a navic menime 
> velikost stranek na SQL takze nehrozi zadna trivialni zalezitost jako je 
> dump ci bcp - pisu na to skripty a pres proxy tabulky to prenasim - je to 
> opravdu ocistec co se tyka rychlosti ve srovnani s lokalnim FS - na druhou 
> stranu je to o vysoke dostupnosti, skalovatelnosti a vsechny bonusy, ktere 
> mi snad dovoli klidne spat.
>
>>
>>> filesystemem - provozujeme ted cast virtualu jedoucich bez poli z
>>> lokalnich disku a i tam je to vyrazne rychlejsi nez pri primem provozu
>>> bez virtualizace - vidim to treba na dumpech SQL, ale i na vysledcich
>>> ruznych seeku v DB.
>>
>> Tohle se mi uplne nezda ze by na stejnem zeleze nasazenim virtualizace
>> doslo ke zrychleni.
> no je to tak, meli jsme dve SQL na dvou identickych serverech Thomas Krenn 
> 815 - jedno nainstalovane bez virtualu tedy Win 2008R2 a na tom Sybase ASE, 
> ktere bezelo jako produkcni a pak druhe SQL jako hot standby, ktere jsme se 
> rozhodli na ten server dat jako virtualizovany OS, nebot jsme nemeli 
> zkusenosti jak se SQL bude na virtualu chovat. Pred rokem (podle zakona 
> schvalnosti o Silvestru) se nam na produkcnim stroji rozpadl raid (pomerne 
> dost nestastne a resilo se to i s vyrobcem radice a myslim, ze jsme pak 
> menili vsechny disky) a prevedli jsme produkci na ten virtualizovany server 
> - mohu to srovnavat tedy pomerne dobre - nevim zda to je tim, ze VMware pod 
> virtualem nejak dokaze kesovat pristupy na disk a nejak optimalizuje 
> zapisy, ale server se opravdu chova lepe. Jednoznacne je to znat na 
> dumpech, ktere driv trvaly pres dve hodiny a ted jsou za 1.5 hodiny hotove 
> (delame je lokalne na druhy raid a pak se presouvaj ftpkem na fileserver)
>>
>>> Navic neni ani nezanedbatelne, ze treba restart virtualizovaneho OS je
>>> otazka vterin - u fyzicke masiny jsou to dnes minuty nez se
>>> zinicializuji pole, ochekuji pameti apod..
>>
>> Ta prenositelnost virtualu diky simulovanemu HW je skvela vec.
>>
>>> Jinak zalohy se delaji pres tzv. snapshoty, ktere se daji delat i za
>>> chodu virtualu coz je opravdu skvela vec a navic presun serveru na
>>> jinou masinu pokud je virtualizovano solo je otazka jen prenest
>>> snapshot - nehrozi zadne problemy s jinym HW pod tim.
>>
>> Pokud maji zalohy pomoci snapshotu fungovat bez problemu musi byt jeste
>> podpora v danem virtualu - aby se uzavrely transakce a ulozily na disk a
>> aby se cache vyplivla na disk aby byl filesystem v konzistentnim stavu
>> kdyz se dela snapshot. Neni to tak jednoduche jak to vyrobci popisuji.
>>
>> Navic nemame moc dobre zkusenosti s VMware s mhoha snapshoty, dela to
>> pak "zvlastni" veci.
> priznam se, ze nevim jak je to udelane, ale na tech nasich serverech (ktere 
> bezi z lokalu a ne nad polem) se musel nainstalovat jeste jeden malinky 
> virtual, kde bezi neco od VMware a to zajistuje tu moznost udelat snapshot 
> - my je delame jednou denne protoze na SQLku se krome dat v DB nic nemeni a 
> ty jsou zalohovany dumpy kazdych 5 minut. Takze je to jen proforma, kdyby 
> bylo treba obnovit virtual nekam jinam - data do SQL by se stejne tahala 
> extra
>
> RV


Další informace o konferenci Hw-list