Standardowy mechanizm wirtualizacyjny – ciąg dalszy

Nieprecyzyjne narzędzie, jakim jest agregacja LUN, może efektywnie rozwiązać problem przydziału pojemności tylko wtedy, jeśli wszystkie zdefiniowane jednostki LUN mają najmniejszy możliwy rozmiar. Dzięki temu woluminy wirtualne można budować z bardzo małych jednostek („klocków Lego”). W przeciwnym razie znaczna część pojemności zostanie zmarnotrawiona.

Nieefektywny przydział pojemności to rozrzutność, choć nie tak kosztowna jak bliźniaczy problem — nieefektywne wykorzystanie pojemności. Jeśli policzymy, ile przestrzeni dyskowej w drogich macierzach zajmują pliki niepotrzebne, powielone i rzadko używane, które mogłyby być przechowywane w tańszych macierzach lub zarchiwizowane na taśmach, stopień wykorzystania pamięci w większości współczesnych infrastruktur okaże się zatrważająco niski: mniej więcej w granicach 30 procent.

Nawet przy cenie 1,5 dolara za gigabajt pamięci masowej stanowi to spory koszt dla organizacji. Zważywszy zaś, że obecnie w niemal każdym środowisku stosuje się lustrzane macierze RAID jako środek ochrony danych, problem rośnie w postępie geometrycznym .

Kwestią tą zajmiemy się w następnym rozdziale. Musimy jeszcze podsumować naszą dyskusję o wirtualizacji.

Po prawej stronie przedstawiono uproszczony widok wirtualizacji z perspektywy dysku, macierzy, a wreszcie sieci FC SAN. Istnieje wiele warstw wirtualizacji, począwszy od pierwotnego odwzorowania domen bitowych na powierzchni dysku, poprzez nałożenie systemu plików, tworzenie zestawów RAID, definicję jednostek LUN aż do wydzielania stref sieci SAN.

Na samym dole modelu — przeznaczone dla tych spośród nas, którzy źle postępowali w swoim życiu i muszą za to odpokutować — znajduje się coś, co zwykliśmy zwać „wirtualizacją”.

Leave a reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>