Efektivita virtualizace

[RV]

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).
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
---------------------------------

Pro případ, že tato zpráva obsahuje návrh smlouvy, Česká pošta, s.p. vylučuje možnost přijetí návrhu smlouvy s jakýmikoli změnami, dodatky či odchylkami. Navržení změn, dodatků či odchylek z Vaší strany považujeme toliko za podnět k dalšímu jednání o obsahu smlouvy. Až do okamžiku podpisu/uzavření smlouvy nejsme jakoukoli naší nabídkou vázáni. Výsledky jednání předcházejících uzavření smlouvy považuje Česká pošta, s.p. za nezávazné. Česká pošta, s.p. nenese žádnou odpovědnost za případné ukončení nebo přerušení jednání o smlouvě, a to bez ohledu na jeho důvod.

 

Tento e-mail včetně příloh může obsahovat důvěrné informace. Jestliže nejste zamýšlený adresát tohoto e-mailu, pak jakákoliv forma zveřejnění, tisk, kopírování, distribuce nebo šíření tohoto e-mailu a připojených příloh je přísně zakázáno. Pokud obdržíte tento e-mail omylem, oznamte to neprodleně jeho odesilateli a okamžitě tento e-mail včetně jeho příloh trvale vymažte ze svého systému. Odesilatel e-mailu neodpovídá za jakoukoliv škodu způsobenou modifikacemi či zpožděním přenosu e-mailu.


In the event that this email contains a contract proposal, Česká pošta, s.p. hereby excludes acceptance of the contract proposal with alterations, amendments and adjustments of any nature. Your proposal of alterations, amendments and adjustments may only be subject of further contract negotiation. Česká pošta, s.p. is not bound by any of its offer until the contract is concluded. Česká pošta s.p. considers the result of contract negotiations preceding the conclusion of contract non-binding. Česká pošta, s.p. is not liable for termination or interruption of any contract negotiation for whatever reason.

 

This e-mail and any attached files may contain confidential information. If you are not the intended addressee of this e-mail, you are hereby notified that any disclosure, printing, copying, distribution or dissemination of this e-mail and any attached files is strictly prohibited. If you receive this e-mail in error, please immediately notify the sender and permanently delete this e-mail and its attachments from your system. The sender of this e-mail does not accept liability for any damage that may be caused by any modifications or delay in the transmission of it.