Aktualności - Moim zdaniem
Image
MOIM ZDANIEM
Autor

Partnerstwo firm Citrix i Microsoft było burzliwe i interesujące od zawsze - niezależnie od tego, czy w modzie były akurat usługi terminalowe, czy wirtualizacja i chmury obliczeniowe. Wielu zadaje sobie pytanie, czy na dłuższą metę da się współpracować oferując niemalże identyczne produkty na wąskim jak by nie patrzeć rynku, w tym przypadku hypervisorów? Citrix mówi, że się da i że nie konkuruje z Microsoftem - a co na to Microsoft?

21.10.2010
19.10.2010
16.07.2010
Image
Nowe oprogramowanie do serwerów sieciowych QNAP – wersja V3.3
01.07.2010
QNAP Systems udostępnił nową wersję firmware do obsługi swoich dysków sieciowych NAS. Aktualizacja V3.3 wprowadza nowe funkcje oraz udoskonalenia,...  
Analitycy Gartnera i IDC są zgodni: na umowie VMware-Novell skorzystają klienci obu firm – i one same
24.06.2010
W tym miesiącu firmy VMware i Novell ogłosiły rozszerzenie strategicznego partnerstwa o nową umowę OEM, na mocy której VMware będzie dystrybuował i...  
Nowe produkty HP do zarządzania usługami
22.06.2010
HP zaprezentował nowe produkty do zarządzania usługami, które pomogą klientom wdrażać hybrydowe modele dostarczania aplikacji. Obejmują one...  
Oracle prezentuje pakiet oprogramowania Oracle Business Process Management Suite 11g
22.06.2010
Firma Oracle zaprezentowała pakiet oprogramowania Oracle Business Process Management Suite 11g, który pozwoli klientom obniżyć koszty, lepiej...  
Cryptzone zaprezentował AppGate Satellite
18.06.2010
Cryptzone przedstawił dziś nowy pomysł dotyczący kontroli dostępu do sieci – AppGate Satellite. Jest to sposób na budowę bezpiecznych wirtualnych...  
Asmax prezentuje nowe urządzenie klasy NAS
18.06.2010
W ofercie Veracomp jest już dostępne nowe rozwiązanie kategorii NAS - Asmax GIGA NAS-Print Serwer. Jest to jedno z najmniejszych urządzeń NAS,...  
Oracle rozszerza ofertę rozwiązań do wirtualizacji komputerów biurkowych
14.06.2010
Nowy klient Sun Ray oraz nowa wersja oprogramowania Oracle Virtual Desktop Infrastructure zapewniają wyższy poziom wydajności, elastyczności i...  
Niższe ceny na serwery i dyski sieciowe QNAP
14.06.2010
EPA Systemy wprowadziła nowy cennik na dyski i serwery sieciowe QNAP. Podstawowe modele, kierowane głównie do odbiorców indywidualnych oraz małych...  
Nowy ProxyAV 1200 firmy Blue Coat chroni przed złośliwym oprogramowaniem
09.06.2010
Firma Blue Coat Systems rozszerzyła rodzinę urządzeń Blue Coat ProxyAV o model Blue Coat Proxy AV1200, służący do skanowania treści w czasie...  
Exploity – najczęściej wykorzystywane szkodliwe narzędzia w maju
08.06.2010
Kaspersky Lab prezentuje listę szkodliwych programów, które najczęściej atakowały użytkowników w kwietniu 2010 r. Podobnie jak w poprzednich...  
Image

Wirtualnie znaczy...?

24.05.2008 11:11, Autor: Tomek Bryja (tomekb), Komentarze (14)

Znany z filozofii "eat your own dog food" Microsoft poinformował o całkowitym zwirtualizowaniu przy pomocy Hyper-V platformy obsługującej dwie spore witryny techniczne dla programistów oraz specjalistów IT - MSDN oraz TechNet. Dokument opisujący techniczne aspekty całego procesu, który pobrać można ze stron firmy, świadczyć ma o niewątpliwych korzyściach z wirtualizacji i pokazać, jak od kuchni wygląda i sprawdza się taka wirtualna platforma.

Opracowanie istotnie jest bardzo interesujące, to lektura dobra nie tylko na weekend. Warto jednak przyjrzeć się scenariuszowi nieco bardziej krytycznym okiem... Pierwsza ciekawostka to fakt, do którego dokopał się serwis virtualization.info - flagowe witryny Microsoft notują niewiele więcej niż 100 mln wywołań stron miesięcznie. W dobie serwisów Web 2.0 nie jest to wcale jakoś wyjątkowo dużo. Do tego, Microsoft zdecydował się wyłącznie na wirtualizację tzw. frontendu platformy - czyli samych serwerów IIS.

Najciekawsza część dokumentu to rezultaty testów i porównań wydajności. Pierwsza obserwacja - sam hypervisor okazał się odpowiedzialny za nie więcej niż 6% obciążenia procesorów fizycznych maszyn. Niestety, to nie jedyne koszty związane z obsługą środowiska wirtualnego - zaobserwowano także trzyprocentowe straty na całkowitej wydajności maszyn fizycznych związane z dynamiczną alokacją dwóch procesorów dla trzech instancji wirtualnych.

Biorąc pod uwagę zalety wirtualizacji, straty te byłyby całkowicie do zaakceptowania. Byłyby, gdyby na nich się skończyło - jak jednak czytamy w kolejnych punktach raportu, fizyczna platforma do hostingu MSDN obsługiwała 21% więcej wywołań na sekundę na 1% CPU niż platforma wirtualna. Ten dość pokrętny wskaźnik jest najważniejszym podsumowaniem ogólnej wydajności całej nowej platformy i sugeruje spadek wydajności rzędu 21% na samych serwerach obsługujących IIS - a to nie jest już mało. Fakt, że nie zdecydowano się na wirtualizację backendu, w tym serwerów SQL, znaczyć może że w scenariuszu wirtualizacji tego elementu spadek wydajności byłby jeszcze większy, na tyle spory by przekreślić sensowność wirtualizacji.

Dodatkowo, zredukowanie ilości serwerów fizycznych - co wskazywane jest jako kluczowa zaleta wirtualizacji - wiązała sie głównie z wymianą starych naszyn na nowe. Można zatem postawić przewrotne pytanie - o ile bardziej dałoby się zredukować liczbę serwerów, gdyby zdecydować się na upgrade bez stosowania wirtualizacji. W chwili obecnej wymiana kilkuletnich maszyn oznacza w większości przypadków naprawdę znaczny skok - z 32-bitowych, jednordzeniowych procesorów do wielordzeniowych, 64-bitowych platform na dużo szybszych szynach i nowych dyskach SAS. Fakt, że nowe platformy są o tyle mocniejsze, by nawet po obciążeniu ich kosztami wirtualizacji osiągnąć tak znaczną redukcję ilości potrzebnego w środowisku produkcyjnym sprzętu, nie musi automatycznie oznaczać że warto decydować się na poświęcenie niemałej części zasobów nowego nabytku na wirtualizację.

Owszem, zalety wirtualizacji całości środowiska składającego się z serwerów pełniących różne role i pracujących pod różnymi platformami będą olbrzymie. Scenariusz opisywany przez Microsoft zakłada jednak wirtualizację jedynie części środowiska - a co za tym idzie, zamiast uproszczenia infrastruktury które miałoby miejsce w przypadku wirtualizacji całości, mamy tylko dodatkowy element komplikujący układankę - i co więcej, wirtualizuje się homogeniczne środowisko składające się z maszyn o identycznej roli, identycznym oprogramowaniu i prawdopodobnie o identycznej konfiguracji.

Dobrze zatem zastanowić się, czy jest to warte straty wydajności, którą lepiej uzmysłowić sobie mniej marketingowo, niż określenie spadku jako "21% na 1% CPU" - wygodnie pomija ono bowiem fakt, że 1% obciążenia procesora nowego typu to znacznie więcej zasobów, niż 1% procesora sprzed kilku lat. Dla Microsoft odpowiedź jest prosta - warto, bo to nieoceniona promocja Hyper-V. We własnym przypadku warto jednak przeprowadzić naprawdę gruntowną analizę i nie dać wmówić sobie na fali zafascynowania wirtualizacją usług serwerowych, że przy faktycznie coraz mocniejszych procesorach już teraz nie można przejść obok niej obojętnie.

PS. Dla porządku trzeba zwrócić uwagę, że testowany przez Microsoft scenariusz zakładał wykorzystanie wersji RC0 platformy Hyper-V oraz mniej wydajnej witualizacji w oparciu o obrazy dysków VHD. Ciekawe, na ile wyniki zmieniłyby sie wraz poprawą tych dwóch parametrów, ciekawe też jak wyglądałoby porównanie w takim scenariuszu różnych hypervisorów.

Komentarze

tomeko
(niezalogowany)
25.05.2008 22:10

tomeko (niezalogowany)
 

Ze wskaznikami i procentami nie ma co dyskutowac, chociaz dokument jest dosyc mocno ogolny wiec IMO trudno to dokladnie osadzic. Na przyklad nie wiem jaka byla konfguracja fizycznych maszyn ktore wczesniej utrzymywaly maszyny w odniesieniu do maszyn wirtualnych itp. Ja jednak nie o tym ...

... czytajac Twój komentasz zastanowilem sie "Po co stosujemy wirtualizacje?". Jedna rzecz, dla ktorej raczej napewno nie stosuje sie wirtualizacji to zwiekszenie wydajnosci, chociaz oczywiscie przy konsolidacji aplikacji ze starszych maszyn na maszyny wirtualne oparte na nowszym sprzecie taki zysk moze sie pojawic. Ale patrzylbym na to jak na efekt dodatkowy zwiazany z samym procesem zmiany sprzetu.

Wirtualizacja ma przynosic korzysci glownie poprzez:
- konsolidacje maszyn fizycznych
- zmniejszenie kosztow utrzymania maszyn
- zmniejszenie kosztow zarzadzania srodowiskiem

Dodatkowe wzgledy to oczywiscie zapewnienie latwiejszego deploymentu, przelaczen i odtwarzania na wypadek awarii itp.

Pojawia sie wiec w tym kontekscie pytanie - czy wskazany przez Ciebie spadek wydajnosci, w kontekscie korzysci z wirtualizacji jest faktycznie istotnym zagadnieniem? W dokumencie nie ma danych na ten temat ale zakladajac ze w trakcie procesu nastapila konsolidacja maszyn fizycznych i zmniejszono ich ilosc, przy zachowaniu ogolnej wydajnosci calego rozwiazania (a takie stwierdzenie sie w dokumencie pojawia). Mamy wiec taka sama tudziez przynajmniej spelniajaca zalozone kryteria wydajnosci i SLA srodowisko, oparte o mniejsza ilosc maszyn fizycznych ktorymi trzeba zarzadzac i zalozmy (dlatego ze takich danych nie mamy wiec pisze - zalozmy) ze ze zmniejszonymi kosztami zarzadzania i utrzymania calosci z punktu widzenia "operations". Czy w takim wypadku spadek wydajnosci pojedynczej maszyny wirtualnej wzgledem pojedynczej maszyny fizycznej jest faktycznie czyms istotnym???

Z duzym prawdopodobienstwem a nawet pewnoscia udaloby sie uzyskac efekt konsolidacji maszyn tez w przypadku zastapienia starszego sprzetu nowszym w mocniejszej konfiugracji. Pytanie tylko czy taki sam jak w przypadku zastosowania wirtualizacji (co prawda nie wiemy jaki byl bo tego wlasnie, a jest to IMO istotna informacja w calosci brakuje) i czy rozwiazanie takie w ogolnym rozrachunku nie byloby drozsze z punktu widzenia calosci zarzadzania srodowiskiem (deployment, operations etc) niz wdrozenie tego rozwiazania na srodowisku zwirtualizowanym.

I to jest IMO wyznacznik tego czy wirtualizacja tego typu srodowiska jest korzystna czy tez nie. Wydajnosc pojedynczej maszyny nie mowi zbyt wiele o obrazie calosci.

Zgodze sie ze wydajnosc pojedynczej maszyny porownywana pomiedzy fizyczna a wirtualna bedzie wazna w przyadku instalacji skladajacych sie z pojedynczej maszyny na przyklad. Tylko wtedy moze sie okazac ze ten kto to bedzie robil nie bedzie decydowal sie na "przeladowanie" maszyny fizycznej maszynami wirtualnymi tak jak to mialo miejsce w tym wypadku, czy wybierze dyski oparte o VHD czy dedykowane napedy tudziez LUNy. Nawet w przypadku, gdy maszyna wirtualna obnizy calosciowo wydajnosc, ktora jednak bedzie nadal spelniala zalozenia w zakresie wymagan i SLA to inne korzysci ze srodowiska wirtualnego moga te wady zniwelowac.

Tak ze IMO w tym dokumencie nie ma danych, ktore pozwalaja ocenic czy projekt przyniosl korzysci czy tez straty z punktu widzenia organizacji IT.

 
Ryan
26.05.2008 3:17

Ryan (brak avatara)
 

Chciałem rozedrzeć koszulę, ale chyba nie ma po co. Tomek O. doskonale podsumował to, co Tomku B. mimochodem lub celowo pominąłeś. Wirtualizacji dokonuje się w zupełnie innym celu niż zdaje się sugerować Twój tekst. Hyper-V to nie megiczna różdżka rozwiązująca wszystkie problemy administratorów, tylko rozwiązanie "coś-za-coś". Hyper-V daje Ci m.in. większą dostępność kosztem nieco mniejszej wydajności. Liczby są IMO przesadzone, gdyż nie odpowiadają wartościom które widziałem. Z drugiej strony dotyczyły one testowych konfiguracji a nie migracji na taką skalę, więc i 21% mieści się w wiarygodnych granicach.

 
Laik
(niezalogowany)
26.05.2008 8:37

Laik (niezalogowany)
 

TomekB i TomeO piszecie o cyzms takim: "czy wybierze dyski oparte o VHD czy dedykowane napedy tudziez LUNy."

Czy moge prosic o dluzsze wyjasnienie roznicy w tymch rozwiazaniach. Jak sie je stosuje, kosztach i jakie sa plusy. Tak dla totalnego laika bo przyznam sie ze piersze o tym slysze. Bardzo dziekuje.

 
masakra
26.05.2008 9:34

masakra
 

Laik: Napisałem jakiś czas temu na moim blogu ( http://blogs.technet.com/mkedziora/archive/2008/04... ) kilka zdań na temat dysków w wirtualnych maszynach.

A komentarz swoj do artykulu mam podobny jak chlopaki juz napisali - w Hyper-V nie chodzi przede wszystkim o wydajnosc (choc ona rowniez jest wazna) ale wlasnie o nizsze koszty zarzadania i sprzetu + wygodniejsza obsluga (backupy, restore'y, itp)

 
tomekb
26.05.2008 11:23

tomekb
 

Widzę, że aż trzech pracowników Microsoft ruszyło z odsieczą :)

"Jedna rzecz, dla ktorej raczej napewno nie stosuje sie wirtualizacji to zwiekszenie wydajnosci."

Nieprawda - wirtualizację stosować można między innymi w celu wyeliminowania fragmentacji zasobów, a więc w celu ogólnego zwiększenia wydajności środowiska. Wyobrazmy sobie 5 serwerów, z których jeden obciążony jest niewiele, a drugi tylko przez 2 dni w miesiącu - wirtualizacja pozwoliłaby wykorzystać ich zasoby przez pozostałe 3 serwery.

Wszystko zależy jednak od konkretnego scenariusza i o tym wlasnie był felieton - nie sugerowałem nigdzie że wirtualizację stosuje się w jakimś jednym konkretnym celu, nie sugerowałem że w wirtualizacji chodzi wyłącznie o wydajność, chciałem tylko zwrócić uwagę na to, co się udało bo zauważył to Dominik - że, "Hyper-V to nie megiczna różdżka rozwiązująca wszystkie problemy administratorów, to coś za coś" i dlatego warto mocno przemyśleć jej wdrożenie. Posunąłbym się nawet dalej, że to nie jest rozwiązanie dla wszystkich - o czym sam MS dobrze wie i np. dlatego nie proponuje Hyper-V w edycjach Windows Server jak SBS czy nawet EBS dla środowisk z ponad setką stacji roboczych.

"czy wskazany przez Ciebie spadek wydajnosci, w kontekscie korzysci z wirtualizacji jest faktycznie istotnym zagadnieniem?"

BRAWO :) Wlasnie do postawienia sobie takich pytan chciałem tym felietonem skłonić :) Odpowiedź zostawmy już jednak użytkownikom. Sam jestem zdania że nawet mocno ponad 20% spadek wydajności może _w_niektórych_przypadkach_ usprawiedliwić zastosowanie wirtualizacji. Co jednak, gdyby ten spadek był rzędu 50%? Zauważ, że z jakiegoś powodu MS nie zdecydował się na wirtualizację w tym scenariuszu serwerów SQL - moja teoria jest własnie taka, że ze względu na zbyt duży spadek wydajności.

"Hyper-V daje Ci m.in. większą dostępność kosztem nieco mniejszej wydajności."

To jest zbyt duże uproszczenie i na to właśnie też chciałem zwrócić uwage felietonem. Czasami daje większą dostępność, czasami większą wydajność, czasami uproszczenie zarządzania... nie zawsze wszystko naraz, czasami jedno kosztem drugiego. Np w opisywanym scenariuszu zaryzykuję stwierdzenie, że zysk z uproszczonego zarządzania farmą identycznych serwerów IIS pracujących najpewniej w trybie shared config będzie znikomy. Strata na wydajności jednak spora.

"W dokumencie nie ma danych na ten temat ale zakladajac ze w trakcie procesu nastapila konsolidacja maszyn fizycznych i zmniejszono ich ilosc, przy zachowaniu ogolnej wydajnosci calego rozwiazania"

Heh, zmniejszono liczbę maszyn fizycznych bo zastąpiono kilkuletnie maszyny nowymi serwerami na quad-core'ach ;) ale sam to później też widzę zauważyłeś.

"w Hyper-V nie chodzi przede wszystkim o wydajnosc (choc ona rowniez jest wazna) ale wlasnie o nizsze koszty zarzadania i sprzetu + wygodniejsza obsluga"

Banał rodem z informacji marketingowych, bo całość jest widzisz bardziej skomplikowana niż papka którą karmi się w ulotkach.

O wydajność chodzi, owszem - tylko że w niektórych scenariuszach wirtualizacja może wpłynąć na ten parametr dodatnie, raz ujemnie.

O niższe koszty sprzętu też chodzi i też - raz wirtualizacja może wpłynąć na nie dodanie (szczególnie w środowiskach heterogenicznych lub przy dużej fragmentacji zasobów, a raz ujemnie (kiedy spadek wydajności będzie spory i będzie wymagał np. o 20% więcej zasobów sprzętowych).

O niższe koszty zarządzania też chodzi, tylko też - czasem wirtualizacja może tu pomóc bardzo, a czasem (kiedy np. mamy małe środowisko złożone z kilku maszyn o identycznej konfiguracji) może pomóc niewiele lub nawet sprawy skomplikować.

Zapomniałeś jeszcze zacytować, że chodzi też o dostępność, za co szef powinien zmyć ci głowę, bo IMO jest to jednym z kluczowych parametrów - ale znowu, czasami zyski są tu kolosalne (szczególnie przy cudach które w tym zakresie można robić np. z rozwiązaniami VMware), a czasem konsolidacja małej ilości identycznych maszyn pracujących w trybie wspólnej konfiguracji na dwóch serwerach fizycznych może moim zdaniem wpłynąć na to nawet negatywnie - bo o ile przy czterech takich maszynach awaria jednej będzie praktycznie niezauważona, to przy dwóch może doprowadzić do przeciążenia środowiska bo jedna pozostała może sobie z taką ilością ruchu nie poradzić.

Wniosek z tego jest taki, że wirtualizacja jest świetna, owszem, ale trzeba stosować ją z głową a nie bezmyślnie - czemu sprzyjda fala hurraoptymizmu i fascynacji tą technologią, wspierana dodatkowo przez fanatyzm marketingowy.

Cieszę się więc z komentarzy, bo właśnie do takiej dyskusji felieton miał zachęcić :)

 
tomeko
(niezalogowany)
26.05.2008 11:50

tomeko (niezalogowany)
 

(...) Widzę, że aż trzech pracowników Microsoft ruszyło z odsieczą :) (...)

Nie wiem dlaczego odbierasz komentarze tutaj tylko i wylacznie przez pryzmat firmy w ktorej powiedzmy ja pracuje. FYI - moja praca w firmie nie polega na namawianiu ludzi do kupowania technologii i nie poczuwam sie do gonienia z odsiecza zeby ratowac wizerunek firmy itp. Taki sam komentarz napisalbym gdyby calosc odbyla sie na VMWare bo to zagadnienie ogolne i raczej oderwane od konkretnej technologii wirtualizacji.

(...) Heh, zmniejszono liczbę maszyn fizycznych bo zastąpiono kilkuletnie maszyny nowymi serwerami na quad-core'ach ;) ale sam to później też widzę zauważyłeś.(...)

Tak ... od poczatku jestem tego swiadom. Tylko nie ma w dokumencie danych na temat jakosci i ilosci tej zmiany. Po prostu brak jest informacji pozwalajcych oszacowac to czy pozytywny efekt z konsolidacji maszyn przez zastosowanie wirtualizacji jest wiekszy czy mniejszy gdyby po prostu zmniejszono liczbe maszyn poprzez tylko i wylacznie wymiane sprzetu.

Moze specyfika aplikacji dzialajacej na tych IISach jest taka ze wiele mniejszych maszyn wirtualnych obsluguje ja lepiej niz kilka duzych maszyn wieloprocesorowych itp. .... Takich danych nie ma (znaczy pewnie sa ale nie publiczne) i dlatego ja bym na podstawie tego nie wyciagal takich wnioskow po prostu. Bez danych to jest po prostu gdybanie i domysly.

(...) Zauważ, że z jakiegoś powodu MS nie zdecydował się na wirtualizację w tym scenariuszu serwerów SQL - moja teoria jest własnie taka, że ze względu na zbyt duży spadek wydajności. (...)

Nie wykluczam ze tak jest. Nie widzialem jeszcze nigdzie porownania wydajnosci SQL na platformie wirtualizacji w odniesieniu do fizycznych maszyn czy to na Hyper-V czy na VMWare ESX. Jezeli takie dane masz to sa one napewno ciekawe i warto je przedstawic. Nie wykluczam tez ze dlatego ze wirtualizacja elementu infrastruktury ktory jest latwy do zastapienia w przypadku awarii (serwery IIS) na wersji RC0 Hyper-V byla do zrealizowania a na przyklad zespol od SQL Server na taki krok sie jeszcze nie zdecydowal. Poruszamy sie wiec w obszarze spekulacji po prostu. Ja tego nie lubie, wole rozmawiac o faktach po prostu.

Na koniec taka uwaga - jezeli chciales zeby felieton do takiej dyskusji zachecil to warto bylo ten temat po prostu poruszyc w felietonie. Sam tekst skupil sie na obnizeniu wydajnosci aplikacji po przeniesieniu na platforme wirtualizacji.

 
tomekb
26.05.2008 13:47

tomekb
 

"Nie wiem dlaczego odbierasz komentarze tutaj tylko i wylacznie przez pryzmat firmy w ktorej powiedzmy ja pracuje."

Eeetam, felietonu nie pisałem przeciez z tego powodu ;) podobnie odpowiedzi na Twoje komentarze tez nie byly jakoś szczegolnie inspirowane tym faktem - jak sam zauważyłeś, dykusja jest na poziomie dość ogólnym i równie dobrze mogłaby dotyczyć dowolnych rozwiązań wirtualizacji :)

To, ze pojawiło się tu nagle w krótkich odstępach trzech pracowników MS mnie jedynie rozbawiło, nie sugerowałem że to cokolwiek innego niż czysty przypadek ;) Jesli cokolwiek wytknalem na bazie powiazania z MS, to wzięty z ulotki komentarz masakry - ktorego praca w przeciwienstwie do Twojej zwiazana jest już z namawianiem ludzi :)

 
masakra
26.05.2008 15:29

masakra
 

Ale ja tez mam swiadomosc tego, ze wirtualizacja nie wszedzie sie nadaje, i ze w kazdym przypadku dobrze by bylo rozpatrzyc czy jest sens stosowania.

I tak moim zdaniem wlasnie sie stalo w przypadku TechNetu i MSDNu - gdzie podjeto decyzje, ze tam korzysci beda duze dla firmy.

Wedlug Ciebie podaje "papke marketingowa", a sam pozniej piszesz (z czym ja sie zgadzam), ze korzysci zaleza od danej sytuacji. Wiec to co ja podalem - to ogolne korzysci z wirtualiacji. A teraz jakie konkretne korzysci Tobie beda przyswiecaly i jakie wyciagniesz z wirtualizacji - to juz Twoja sprawa.

 
Ryan.
(niezalogowany)
27.05.2008 4:17

Ryan. (niezalogowany)
 

Sorki, jestem zbyt leniwy, żeby się zalogować. :-) Napisałem co napisałem, bo mam z wirtualizacją i VHD większą niż bym chciał styczność. ;-) A Twój tekst wyraźnie _nie_ podkreśla, że Hyper-V do czegoś jednak się nadaje. To taki stealth troll w Twoim stylu, i tylko wstyd mi, że się dałem złapać. :-P

Nawiązując jeszcze do "nieprawda, że wirtualizacja nie służy zwiększeniu wydajności". Nie służy w opisywanym przez Ciebie scenariuszu, a na nim się skupiłeś. Zwiększa wydajność wyłącznie w sytuacji, gdy masz maszyny bezczynnie czekające na wykorzystanie zasobów. Ale znowu i tego w tekście nie podkreśliłeś, bo skupiłeś się na spadku wydajności w scenariuszu z systemami o dużym obciążeniu. W scenariuszu, w którym jeśli stosuje się wirtualizację, to do innych celów. Czego (znowu) nie napisałeś. No kurcze, sklasyczny stealth troll. :-D No jak mogłem, jak mogłem się dać złapać. T_T

Co do odsieczy jeszcze: żebyś Ty miał taką widownię po drugiej stronie płotu, jak w założeniach TechIT miał mieć. :-P

 
tomekb
27.05.2008 10:36

tomekb
 

"A Twój tekst wyraźnie _nie_ podkreśla, że Hyper-V do czegoś jednak się nadaje."

Napisalem - "Owszem, zalety wirtualizacji całości środowiska składającego się z serwerów pełniących różne role i pracujących pod różnymi platformami będą olbrzymie." Wystarczy przeczytac felieton zanim klikniesz w "dodaj komentarz" ;)

"Nawiązując jeszcze do "nieprawda, że wirtualizacja nie służy zwiększeniu wydajności". Nie służy w opisywanym przez Ciebie scenariuszu, a na nim się skupiłeś."

Cytujesz moj komentarz odnoszacy sie do wypowiedzi TomkaO, a nie tresc felietonu.

"Ale znowu i tego w tekście nie podkreśliłeś, bo skupiłeś się na spadku wydajności w scenariuszu z systemami o dużym obciążeniu. W scenariuszu, w którym jeśli stosuje się wirtualizację, to do innych celów."

Jesli juz, to zaryzykowalem raczej pewnie przesadne ale celowo stwierdzenie, że wirtualizacja w tym scenariuszu to czysty marketing ;) Strata na wydajnosci, brak wiekszej niezawodnosci (utworzono single point of failure) i tylko wieksza wygoda zarzadzania plus mozliwosc zrobienia z tego wdrozenia halo.

"Co do odsieczy jeszcze: żebyś Ty miał taką widownię po drugiej stronie płotu, jak w założeniach TechIT miał mieć. :-P"

Dobry argument w dyskusji, nie ma co ;) Malo trafny do tego, bo poki co ogladalnosc TechITa jest wieksza niz zalozenia :)

 
tomeko
(niezalogowany)
27.05.2008 11:25

tomeko (niezalogowany)
 

O ogladalnosci TechIT nic nie wiem wiec nie bede zabieral glosu w dyskusji ale pociagne inny watek, ktory sie pojawil dopiero w tym komentarzu:

(...) brak wiekszej niezawodnosci (utworzono single point of failure) i tylko wieksza wygoda zarzadzania plus mozliwosc zrobienia z tego wdrozenia halo. (...)

Możesz pociągnąć ten wątek "single point of failure"???? Z tego co widzę to architektura MSDN\Technet zakłada zapewnienie dostępności usługi i niezawodności przez farmę serwerów IIS i load balancing. Nawet jezeli kilka maszyn wirtualnych jest na pojednyczym hoscie, i ten host pada to nie prowadzi to do zalamania uslugi. Usluga dalej jest swiadczona przez inne serwery.

Mozesz wiec wyjasnic gdzie w tym wszystkim jest "single point of failure"?

Rozumiem ze chodzi ci o to ze nie zostalo zapewniona mozliwosc przenoszenia maszyn wirtualnych pomiedzy hostami na wypadek awarii hosta. Tudziez przynajmniej nie zostalo to wspomniane. Z tym ze:
- w takiej architekturze bylby to przerost formy nad trescia ... po co zapewniac takie rzeczy jezeli utrata pojedynczego hosta nie powoduje zalamania uslugi?
- czy wg Ciebie taniej jest zapewniac konfiguracje klastrowe dla calego srodowiska z mechanizmami przenoszenia maszyn na wypadek awarii (koniecznosc zapewnienia dodatkowych maszyn z wolnymi zasobami, na ktore w razie awarii zostanie przesuniety 'workload') czy tez po prostu przewidziec dodatkowa maszyne w ramach skalowania srodowiska, ktora bedzie caly czas obslugiwala dodatkowo ruch.

Z checia poznam Twoja opinie na temat "single point of failure" wprowadzonego przez ta zmiane do tej architektury, poniewaz jak narazie nie widze tego o czym mowisz, wiec jak widac jest okazja sie czegos nauczyc.

 
tomekb
28.05.2008 10:18

tomekb
 

Przyznam, ze dokument jest tu mocno niejednoznaczny, niemniej stwierdza wystepowanie takiego scenariusza: "we installed the Hyper-V role on two physical servers, with each hosting three VMs running MSDN."

Wedlug mojego doswiadczenia, przy zalozeniu obciazenia na poziomie 100mln wywolan miesiecznie i parametrow sprzetowych maszyn jak w dokumencie, awaria jednego serwera spowoduje calkowite przeciazenie lub czesciowa niedostepnosc systemu, bo drugi nie poradzi sobie z obsluga wszystkich wywolan. To wlasnie _może_ skutkowac pojedynczym puntem awarii.

Przyznaje jednak racje, ze po pierwsze finalne wdrozenie moze zakladac wieksza liczbe serwerow (choc tego dokument precyzyjnie nie okresla), po drugie istnieja mechanizmy jak np kernel-mode-caching IIS7 ktore moglyby spowodowac ze nawet jedna maszyna obsluzylaby caly ruch - tu jednak za malo danych by to stwierdzic.

Tak czy siak - tego typu scenariusz utworzenia SPOF w malej konfiguracji jest jak najbardziej realny, szczegolnie przy konsolidacji malej ilosci serwerow, ktora redukuje liczbe fizycznych maszyn wlasnie do 2 lub 3.

 
tomeko
(niezalogowany)
28.05.2008 17:41

tomeko (niezalogowany)
 

Pojedynczy punkt awarii to cos, czego awaria powoduje zalamanie swiadczenia uslugi. W tym wypadku mamy conajmniej DWA centra danych, w ktorym w kazdym mamy konfiugracje skladajaca sie z conajmniej DWOCH hostow.

Awaria jednego a nawet dwoch nie spowoduje zalamania uslugi. To jaka jest zakladana wydajnosc przy scenariuszu awarii jednego czy dwoch z tych serwerow to juz inne zagadnienie. Zalezy od tego jak one sa przeskalowane i jaki jest zapas mocy na tych hostach. Chodzi mi tutaj juz o serwery IIS, czyli jakie jest zakladane obciazenie kazdej z maszyn w normalnych warunkach i na jaki peak load sa przygotowane na wypadek awarii innych maszyn z farmy to juz zagadnienie skalowania IIS jako takiego pod konkretna aplikacje i o tym slowa nie ma w tym dokumencie. Jak znam MS IT to dokladnie to przetestowalo i przeliczylo sobie dla zalozonych wartosci normalnego uzycia i wartosci peak load.

Nie wiesz jakie obciazenie generuje apliakcja MSDN i nie wiesz jak sa przeskalowane maszyny pod ta aplikacje. Nie wiesz jakie jest ich normalne obciazenie i jaki jest zakladanyh peak load. Wiec pisanie o pojedynczym punkcie awarii w tym wypadku IMO jest gruba przesada.

Rownie dobrze ja teraz moglbym napisac ze wg mnie architektura TechIT zbudowana zostala w taki sposob ze nie jest odporna na awarie jednego serwera. Danych mam tyle samo co Ty o MSDN wiec moje stwierdzenie jest rownie uzasadnione jak Twoje.

(...)Tak czy siak - tego typu scenariusz utworzenia SPOF w malej konfiguracji jest jak najbardziej realny, szczegolnie przy konsolidacji malej ilosci serwerow, ktora redukuje liczbe fizycznych maszyn wlasnie do 2 lub 3.(...)

Zakladasz ze ten kto dokonuje konsolidacji nie dokonuje skalowania pod konkretne obciazenie ... w taki sposob to mozna sobie rozlozych infrastrukture i bez wirtualizacji ...

 
tomekb
28.05.2008 18:07

tomekb
 

Wydawało mi się, że dwa centra danych wykorzystane tam zostaly w scenariuszu zakladajacym, że drugie mialo tylko przejsciowo hostowac (stare) srodowisko fizyczne. Zaraz doczytam ponownie, jesli faktycznie w drugim datacenter hostuje sie podobny zestaw to oczywiste ze problem wtedy nie bedzie wystepowal. Tak czy siak jednak - to tylko jeden z wielu aspektow ktory pojawil sie do tego dopiero tutaj w dyskusji a nie w felietonie, no i do tego dalej jak najbardziej rzeczowy - po prostu 1) zwraca uwage na koniecznosc przeprowadzenie rzetelnego skalowania pod obciazenie 2) w wyniku takiego skalowania przy checi zachowania niezawodnosci moze okazac sie ze konsolidacja przy wirtualizacji nie bedzie az tak duza jak gdyby konsolidowac przymykajac oko na ten parametr - o co na etapie agresywnego marketingu nietrudno.

 

Dodaj komentarz

Autor: