czwartek, 13 grudnia 2012

Kwestia swobody ruchów


Gdy tak rozmawiamy sobie dziś o informatyce, to aż serce rośnie na myśl, co to możemy jeszcze zrobić i co to już dziś nie jest zupełnie żadnym problemem. I że - oczywiście, nasze serwisy, aplikacje i dane, tak dynamicznie i intuicyjnie przemykają się pomiędzy poszczególnymi platformami, że nic tylko przyklasnąć!

Otóż, jak wiadomo - wraz z końcem roku więcej jest okazji do spotkań. I tak też usiedliśmy sobie ze starymi znajomymi parającymi się branżą IT i (zupełnie przypadkiem) rozmowa zeszła w sfery technologii. Dawno, dawno temu, kiedy o wirtualizacji serwerów nie mówili nawet najbardziej natchnieni wieszcze, była już funkcjonalność nazywana „Dynamiczna Rekonfiguracja”. Polegała ona, z grubsza rzecz biorąc na tym, że do pracującej maszyny można było dołożyć i nowy procesor, i nową pamięć RAM, i nową kartę FC. A jak system zgłosił, że coś jest nie w porządku, to również, bez wyłączania i zatrzymywania czegokolwiek - można było wskazany procesor, czy pamięć, czy kartę wyjąć i wymienić. Ot, tak. W dużych systemach można było też podzielić dużą maszynę na maszyny mniejsze i przemieszczać zasoby między nimi stosownie do potrzeb i humoru. A jak by się stało coś NAPRAWDĘ ZŁEGO (jakiś sabotaż, albo niewprawna obsługa, albo łata systemowa nie taka jak trzeba) – to jak się już system MUSIAŁ przewrócić, to działo się to tylko w obrębie takiego małego „sub serwera”, a nie całej ogromnej maszyny.

A dziś, proszę: nasza aplikacja i wszystkie jej siostry i sąsiadki, rezydują sobie w świecie wirtualnym, serwera rzeczywistego nie tykają się inaczej, jak tylko przez sterylną osłonę wirtualizatora, a jak trzeba, lub gdy się tylko wydaje, to ani się obejrzymy i są na zupełnie innej maszynie fizycznej... Więc taka Dynamiczna Rekonfiguracja – to po co to komu? 

Ale tak patrząc z innej strony, można by zauważyć, że ta dzisiejsza, mała i poręczna maszyna (że weźmy dla przykładu T4-4) mieści 32 rdzenie procesorów i liczy jakieś 256 wątków sprzętowych – czyli więcej, niż wcale nie tak dawno temu kilka serwerów po tonę każdy. Tych aplikacji i usług, które na takiej maszynie chodzą może być całkiem sporo. Gdy dojdzie więc do sytuacji, że wszystkie one gdzieś będą MUSIAŁY uciec, to na TYCH INNYCH serwerach może się zrobić trochę ciasno...
Ale znowu, tak patrząc jeszcze z innej strony, to nasze IT jest dziś takie oszczędne i akuratne, że współczynnik wykorzystania platformy dziś nie taki jak dawniej – nie jakieś tam nędzne 20-30% ale 70-80-90! I to nie jeden serwer - a wszystkie! Gdyby więc (odpukajmy w niemalowany krzem) taka jedna maszyna by się złożyła, to na reszcie środowiska mógłby się zrobić całkiem spory tłok i... lepiej nie pisać.
Ale z trzeciej strony - przecież takie rzeczy to wypadek, a zdarzenia szczególne tolerujemy w szczególny sposób. Tylko gdy się ma pod opieką takich serwerów dłuuuugi szereg, to prawdopodobieństwo wystąpienia takiej SZCZEGÓLNOŚCI, z tytułu normalnej działalności serwisowej dramatycznie rośnie. 

I tu doszliśmy (wspólnie) do konstatacji, że gdyby na ten przykład, mieć w serwerze taką Dynamiczną Rekonfigurację, to byłoby w sumie całkiem miło. No bo przecież, wtedy wymiana procesora, czy dołożenie pamięci nie wymagałoby wyłączenia całego serwera – można by dołożyć czy wymienić samą płytę, czy procesor, czy RAM, czy HBA. Od tak. A taka możliwość podziału na Domeny Systemowe, niby nie jest tak niezbędnie potrzebna, ale warto mieć gwarancję, że TEN serwer, z TYM administratorem nigdy wyżej zasobów, które mu przydzielimy fizycznie nie wyskoczy. I nikomu innemu nic złego nie grozi, nawet gdyby rwane szczypcami z TEJ domeny serwera odłamki krzemu na boki fruwały... 
Tak sobie rozmawialiśmy ze starymi znajomymi, że moda, która dziś w naszym świecie IT dobrze się nosi, to garniturki tak ciasno przy ciele wymagań skrojone, że żadna zakładka czy fałdka naddatków uchować się nie ma prawa. I w zasadzie to dobrze. Bo cała nasza technologia silna i wydajna jest, i swą informatyczną urodą piękna i młoda. W tej dopasowanej modzie zupełnie jej więc do twarzy: że aż serce rośnie widząc tę prężącą się pod osłoną aplikacji systemową muskulaturę!
Tylko jak coś się nie uda, powinie, przydarzy, omsknie, to jakoś tak mamy mniejszą swobodę ruchów... 

Informatyka dzisiejsza jest bezsprzecznie o epokę świetlną dalej, niż ta z czasów gdy wymyślano Dynamiczną Rekonfigurację. Pewne zasadnicze reguły się jednak nie zmieniły. Aby migrować aplikacje z systemu na system trzeba mieć i mechanizm i zasoby. Aby sprawnie utrzymywać i serwisować duże środowiska w dzisiejszym reżimie kosztowym, trzeba dysponować mechanizmem, który zmniejszy granularność zdarzeń z całego serwera do jego małego ułamka. Dlatego dziś maszyny serii M4000/5000/8000/9000 wyposażone w mechanizm dynamicznej rekonfiguracji, cały czas działają i dobrze służą ich aktualnym użytkownikom, dostarczając tę niezbędną rezerwę luzu na wypadek gdyby... 



Jakiś czas temu wspominałem o zbliżającej się premierze nowych maszyn serii T. Jak by nie liczyć, będą to całkiem potężne maszyny, zdolne uciągnąć ogromne obciążenia wielu aplikacji. Więc może nie byłoby źle, gdyby znana, używana i ciesząca się szacunkiem Dynamiczna Rekonfiguracja zagościła tam, obok tak bardzo dynamicznie rozwijającej się wirtualizacji. 

Bo niezbędne jest dziś mieć taką doskonałą możliwość wykorzystania i przydzielania zasobów. Ale dobrze jest też mieć taką trochę większą swobodę ruchów!
A jak będzie? Może nie uprzedzajmy wypadków... 

Napisz do autora
Zbigniew Swoczyna, szef Zespołu wsparcia sprzedaży Oracle Hardware w Oracle Polska.

Brak komentarzy:

Prześlij komentarz