Tadam!!! EMC ogłosiło zupełnie nowy produkt w swoim portfolio.
Będący od pewnego czasu tajemnicą "poliszynela" projekt Lightning, doczekał się swojego oficjalnego przedstawienia i oficjalnego produktu nazwanego VFCache (Very Fast Cache :D )
Oczywiście na stronach EMC i kibicujących im blogerów zachwalana jest innowacyjność i unikalność nowego produktu, natomiast reszta świata storage i jego komentatorów już tak entuzjastycznie nastawiona nie jest. Słyszy się nawet, że EMC właśnie wynalazło i z wielkim hukiem zaprezentowało koło :D
VFCache a.k.a Project Lightning
Czym jest VFCache? W skrócie można powiedzieć, że jest to karta na magistrali PCIe zawierająca moduły pamięci flash. Ma służyć jako bardzo szybka pamięć (szybsza niż SSD czy cache w macierzy) przyłączoną bezpośrednio do serwera. Dzięki temu nie będzie opóźnień związanych z przesyłem danych z/do macierzy a szybkie pamięci flash zapewnią bardzo dobrą wydajność i ekstremalnie niskie czasy odpowiedzi.
Pomysł fajny ale nie można powiedzieć, że nowy. Oparte na flash karty PCIe do serwerów są już na rynku - jako przykład można podać firmę Fusion-io. Sama idea "przytwierdzenia" storage na sztywno do serwera także może budzić kontrowersje. Takie podejście to przecież "powrót do korzeni" i odejście od wyspecjalizowanych macierzy agregujących w sobie ruch i dane z wielu hostów.
Trochę szczegółów:
VFCache to karta PCIe, z modułami pamięci NAND Flash wykonanej w technologii SLC (Single Level Cell).
Obecnie oferowany jest jedynie model o pojemności 300GB.
Jeżeli chodzi o wydajność to kształtuje się ona na poziomie 750tyś IOPS przy odczycie, natomiast opóźnienia robią wrażenie gdyż są deklarowane jako nie przekraczające 50mikrosekund (0,05ms).
Oczywiście są to dane oficjalnie podawane przez EMC i pewnie mocno "podrasowane" marketingowo". Wartości robią wrażenie i są obiecujące, ale poczekajmy na jakiś bardziej niezależne i zmierzone na rzeczywistych, a nie maksymalnie zoptymalizowanym pod to rozwiązanie, danych.
Warto wspomnieć, że VFCache działa tylko dla operacji odczytu, wszystkie żądania zapisu przechodzą dalej do zewnętrznej macierzy (tryb write-through) i przez nią są obsługiwane. Oczywiście w tym przypadku nie ma mowy o przyśpieszeniu działania. Kartę można także uruchomić w tzw: split-mode, część pojemności jest wtedy wykorzystywana jako typowy read cache, natomiast na pozostałej przestrzeni można umieścić zasoby dyskowe (coś jak mała macierz DAS)
Jeżeli chodzi o uruchomienie VFCache to oprócz samego umieszczenia karty PCIe, trzeba także zainstalować odpowiedni sterownik w systemie operacyjnym. Przy VMware oprócz sterownika w ESXie, muszą także być obecni "agenci" VFCache na każdej maszynie wirtualnej.
W czym tkwi siła nowego produktu? Na chwilę obecną na pewno warto wspomnieć o integracji z FASTem czyli oprogoramowaniem EMC do automatycznego-tieringu. VFCache może być uznany za warstwę storage jeszcze szybszą niż dyski SSD i na niego będą przeniesione dane do których system odwołuje się najczęściej. Bardzo ambitne są plany rozwoju - między innymi w tym roku powinna pokazać się obsługa deduplikacji.
Gdzie na chwilę obecną EMC ma jeszcze zaległości? Na pewno trzeba powiększyć liczbę serwerów dla jakich wspierany jest VFCache - w tej chwili lista obejmuje kilkanaście pozycji i nie jest to powalająca liczba. Nie wspierane są blady (nawet Cisco UCS!) - wynika to z potrzeby zmiany architektury dla rozwiązań blade-owych (brak PCIe). Szwankuje także obsługa niektórych funkcji VMware, między innymi to rozwiązanie nie będzie działało z vMotion.
Podsumowanie:
Moje własne, prywatne zdanie jest takie, że produkt ten w chwili obecnej na pewno nie jest żadną rewolucją ale ma bardzo duże możliwości rozwoju. Największa siła to współpraca z najróżniejszymi funkcjonalnościami innych produktów EMC (np: FASTem).
Project Thunder:
EMC zapowiedziało także wprowadzenie nowego produktu, obecnie jest on na etapie projektu i nosi nazwę Thunder.
Projekt Thunder wygląda na nową macierz, różniącą się od pozostałych w portfolio EMC tym iż będzie wyłącznie oparta na dyskach SSD (tzw: "solid state array"). Z tych informacji które dostępne są w tej chwili nowy produkt będzie cechował się, oczywiście poza bardzo dużą wydajnością, także sporymi możliwościami jeżeli chodzi o skalowanie. Oprócz "normalnego" "scale-up" czyli dokładania dodatkowych dysków, będzie można także robić tzw: "scale-out", który polega na łączeniu odrębnych macierzy w jedną (mniej-więcej na zasadzie klastra) - pozwoli to zarówno na zwiększenie mocy kontrolerów, jak i oczywiście na jeszcze większe możliwości rozbudowy dostępnej do wystawiania przestrzeni.
Więcej informacji o projekcie Thunder na pewno zostanie przedstawiona na majowym EMC World.
Do poczytania:
Lightning, thunder and reverberations
From lightning to thunder
Vfcache means very fast cache indeed
The next generation of enterprise flash storage
Flashpoint with Pat Gelsinger
Emc VFcache - server caching solution announced
Vfcache hello world and covers come off project thunder
niedziela, 12 lutego 2012
wtorek, 7 lutego 2012
Clariion - Rzut oka na Unisphere + menu do zarządzania macierzą
Trochę czasu upłynęło od ostatniego wpisu związanego z Clariionami i przygotowaniami do egzaminu. Niestety nadmiar zajęć bardziej priorytetowych spowodował, że nieco "odpuściłem" pisanie na blogu.
Ten wpis skupi się na Unisphere i pokaże pewne podstawowe informacje jaki można sprawdzić za pomocą tego interfejsu. Dość dużo będzie zrzutów ekranu, bo nie ma większego sensu opisywanie słowami tego co ładnie można po prostu pokazać.
Start: Dashboard + okolice
Unisphere pojawił się razem z FLARE30 i zastąpił poprzedni interface nazywany NaviSphere.
Zaraz po zalogowaniu się (poprzez wpisanie adresu IP naszego Clariiona do przeglądarki), widzimy tzw: dashboard czyli stonę startową z najróżniejszymi charakterystykami.
Standardowy dashboard bez modyfikacji wygląda następująco:
Poszczególne panele można zmieniać wykorzystując obecny w okolicach prawego górnego rogu przycisk Customize.
Standardowo dostajemy informację o urządzeniach (Clariionach, Centerach i VNXach) w naszej domenie, alarmach i ostrzeżeniach oraz pewne podstawowe dane dotyczące zarządzania pojemnością - zarówno Clariionów jak i macierzy Celerra.
W górnej części mamy poziome menu z kilkoma głównymi opcjami.
W tym wpisie chciałbym skupić się na najbardziej rozbudowanej części tego menu czyli pozycji System List
Po przejściu na zakładkę System Lists otrzymamy wykaz naszych macierzy w domenie:
Na tym zrzucie raczej ubogo, jeden samotny Clariion CX-240 :D
Poprzez "prawo-klik" na danym urządzeniu dostajemy się do menu kontekstowego z wieloma opcjami dotyczącycmi zarządzania konkretnym urządzeniem:
Jak widać cała pula opcji do wyboru. Nie będę się rozwodził na temat każdej z nich (większość będzie bardziej lub mniej opisana w kolejnych wpisach).
Menu dla pojedynczego systemu (macierzy)
Po wybraniu jednego z systemów (macierzy), dostajemy kolejne menu i opcje pozwalające nam monitorować/zarządzać nim:
Menu ma następującą strukturę (zaznaczyłem jedynie "pod-menu" w tych ważniejszych pozycjach):
I przechodząc po kolei:
Menu System:
Zakładka System Information wygląda następująco:
Główną część okna zajmują podstawowe informacje o danej macierzy takie jak status, nr seryjny adresy IP kontrolerów itd... Na lewo znajduje się panel sterujący podzielony na kilka sekcji, związanych z poszczególnymi typami zadań.
Kolejną opcją w menu system jest Hardware:
Środkową część okna zajmuje lista komponentów macierzy pod postacią "drzewka"
Po prawej stronie możemy zobaczyć szczegółowe własności wybranego komponentu oraz w niektórych przypadkach jego graficzny obraz z zaznaczonym położeniem.
Zakładka Hot Spares jest "nudna" więc nie będziemy jej tutaj prezentowali. Nazwa dość jednoznacznie tłumaczy jej zawartość.
Menu Storage:
Główna zakładka menu storage zawierająca podsumowanie to Summary:
Menu z opcjami po lewej stronie (identyczne dla wszystkich zakładek z grupy Storage) pozwala nam na przeproawdzenie podstawowych operacji na LUNach i Storage grupach, przy czym za najważniejszą należy oczywiście uznać stworzenie nowego LUNa. Dominującą część okna zajmuje coś w stylu "dashboard"-a z ogólnymi informacjami na temat statusu LUNów oraz pojemności i wykorzystania macierzy.
Pozostałe opcje (poza Summary) w menu Storage pokazują nam po kolei kolejne "struktury" jakie tworzymy na macierzy aby finalnie:
Zakładka Disks pokazuje nam jakie dyski mamy w macierzy - czyli zaczynamy od podstawowy fizycznych "cegiełek" dostarczających przestrzeń.
Same dyski nie umożliwią nam jeszcze wystawiania przestrzeni do serwerów, należy je odpowiednio skonfigurować - utworzyć z nich grupy ( w przypadku wystawiania tradycyjnego) lub pule (w przypadku użycia "thin provisioningu"). Każda grupa/pula dysków ma przypisany do siebie rodzaj protekcji RAID (0/1/5/6 itd...). Informacje na temat obecnych na macierzy grup/pul są dostępne w zakładce Pools/RAID Groups:
Mając stworzone struktury RAID można na nich tworzyć LUNy. Czyli te objekty, które będziemy prezentowali dla hostów.
Jak się nietrudno zorientować zakładka na której są informacje o LUNach nazywa się LUNs:
Oprócz obecnych w każdej zakładce menu Storage opcji "zadokowanych" po lewej stronie okna, pozostałą jego część zajmuje lista wszystkich LUNów zdefiniowanych na macierzy razem z pewnymi podstawowymi informacjami o nich (Nazwa, Numer, Status, Pojemność, Do jakiego hosta został wystawiony)
Po stworzeniu LUNów została nam jeszcze tylko jedna rzecz do skonfigurowania na macierzy, tak aby z przestrzeni danego LUNa mógł korzystać host.
Należy wykonać tzw: mapowanie czyli zezwolić macierzy na skomunikowanie się ze sobą wybranego hosta z wybranym LUNem. Wykorzystuje się do tego strukturę nazwaną Storage Group, która składa się z dwóch części. W jednej z nich mamy listę LUNów, a w drugiej listę Hostów. To co robi macierz to pozwala aby wszystkie hosty z grupy, miały dostęp do wszystkich LUNów z tej samej grupy.
Oczywiście przy tworzeniu takich grup mamy do dyspozycji różne warianty i opcje, ale w tym wpisie nie chodzi nam o wyjaśnienie tego procesu ale tylko pokazanie miejsca gdzie w Unisphere są okienka i menu związane z takimi objektami.
Znajduje się to w zakładce Storage Gropus:
W górnej części widzimy listę zdefiniowanych grup a na dole w zakładkach można sprawdzić jakie LUNy i hosty zostały do niej przypisane.
Ostatnia pozycja to Folders , w przeciwieństiwe do pozostałych opcji nie jest to kolejny "krok" przy tworzeniu i wystawianiu zasobów. W tym oknie możemy zobaczyć sobie LUNy podzielone na różne kategorie (foldery) - między innymi: LUNy nie wystawione do hostów, LUNy przypisane do poszczególnych SP, MetaLUNy (czyli kilka LUNów połączonych w jeden). Można także w tym miejscu zdefiniować swoje katalogi i poprzypisywać do nie zasoby.
Menu Hosts:
Tak jak i w pozostałych przypadkach menu host posiada swoją zakładkę Summary:
I tak jak się można domyślić znajduje się na niej kilka okienek z podstawowymi informacjami na temat widzianych przez macierz hostów.
Pozostałe dwie opcje w menu "Hosts" odpowiadają za liste wszystkich serwerów podpiętych do macierzy (Host List) oraz za integrację z VMware (Virtualization).
Dość lakonicznie to opisuję, ale więcej nie trzeba :D
Pozostałe Menu z grupy System List:
Zostały jeszcze 4 nieomówione menu z całej grupy opcji związanych z poszczególnymi macierzami.
Są to mianowicie: Replicas, Monitoring, Settings, Support
Nie będę poświęcał im tyle czasu i uwagi w tym wpisie co pozostałym. Jeżeli chodzi o menu Replicas to oczywiście zawiera ono opcje to tworzenia i konfigurowania najróżniejszych tworów związanych z replikami lokalnymi oraz zdalnymi - same mechanizmy będą opisane w innym miejscu i późniejszym czasie.
Jeżeli chodzi o Monitoring, to każda z jego opcji jest jakby osobnym narzędziem, przy czym niektóre z nich są osobno licencjonowane (np Analyzer czy Quality of Service Manager). One także powinny doczekać się swoich własnych wpisów.
Menu Settings oraz Support są średnio ciekawe i nie ma tam fajerwerków - nazwa mówi wszysko.
Podsumowując:
Wpis dość długi i dodatkowo pełen zrzutów ekranowych. W zasadzie mam co do niego ambiwalentne uczucia, gdyż to wszysko co jest tutaj opisane poznaje się w ciągu kilkunastu minut "przeklikiwania" się przez macierz. Przygotowanie tego wpisu zajęło mi dużo więcej czasu, szczególnie w zakresie przygotowywania zrzutów i zaciemniania wszelkiego rodzaju numerów seryjnych oraz nazw.
Na pewno pojawi się jeszcze jeden (lub nawet więcej) wpisów związanych z Unisphere, ale będą bardziej treściwe i pokażą jak wykonywać pewne (podstawowe) czynności na macierzy lub gdzie szukać bardziej precyzyjnych ustawień - obiecuję nie będzie już takiej treści ogólnej z zdjęciami dashbordów i listw z menu :D
Choć najprawdopodobniej kolejny post na blogu nie będzie dotyczył Clariionów i przygotowań do nieszczęsnego egzaminu.
Ten wpis skupi się na Unisphere i pokaże pewne podstawowe informacje jaki można sprawdzić za pomocą tego interfejsu. Dość dużo będzie zrzutów ekranu, bo nie ma większego sensu opisywanie słowami tego co ładnie można po prostu pokazać.
Start: Dashboard + okolice
Unisphere pojawił się razem z FLARE30 i zastąpił poprzedni interface nazywany NaviSphere.
Zaraz po zalogowaniu się (poprzez wpisanie adresu IP naszego Clariiona do przeglądarki), widzimy tzw: dashboard czyli stonę startową z najróżniejszymi charakterystykami.
Standardowy dashboard bez modyfikacji wygląda następująco:
Poszczególne panele można zmieniać wykorzystując obecny w okolicach prawego górnego rogu przycisk Customize.
Standardowo dostajemy informację o urządzeniach (Clariionach, Centerach i VNXach) w naszej domenie, alarmach i ostrzeżeniach oraz pewne podstawowe dane dotyczące zarządzania pojemnością - zarówno Clariionów jak i macierzy Celerra.
W górnej części mamy poziome menu z kilkoma głównymi opcjami.
- Dashboard - wyświetlenie dashboardu
- System List - Lista naszych urządzeń w domenie
- Domains - Informacje o domenach
- Alerts - Czyli log z wszyskimi alarmami
- Support - Opcje związane z serwisowaniem macierzy
Część z tych pozycji jest rozwijalna i udostępnia kolejne "pod-menu":
Po przejściu na zakładkę System Lists otrzymamy wykaz naszych macierzy w domenie:
Na tym zrzucie raczej ubogo, jeden samotny Clariion CX-240 :D
Poprzez "prawo-klik" na danym urządzeniu dostajemy się do menu kontekstowego z wieloma opcjami dotyczącycmi zarządzania konkretnym urządzeniem:
Jak widać cała pula opcji do wyboru. Nie będę się rozwodził na temat każdej z nich (większość będzie bardziej lub mniej opisana w kolejnych wpisach).
Menu dla pojedynczego systemu (macierzy)
Po wybraniu jednego z systemów (macierzy), dostajemy kolejne menu i opcje pozwalające nam monitorować/zarządzać nim:
Menu ma następującą strukturę (zaznaczyłem jedynie "pod-menu" w tych ważniejszych pozycjach):
- System
- System Information
- Hardware
- Hot Spares
- Storage
- Summary
- Disks
- Pools/RAID Groups
- LUNs
- Storage Groups
- Folders
- Hosts
- Summary
- Host List
- Virtualization
- Replicas
- Monitoring
- Reports
- SP Event Logs
- Event Notification
- Analyzer
- Quality of Service Manager
- Settings
- Support
I przechodząc po kolei:
Menu System:
Zakładka System Information wygląda następująco:
Główną część okna zajmują podstawowe informacje o danej macierzy takie jak status, nr seryjny adresy IP kontrolerów itd... Na lewo znajduje się panel sterujący podzielony na kilka sekcji, związanych z poszczególnymi typami zadań.
Kolejną opcją w menu system jest Hardware:
Środkową część okna zajmuje lista komponentów macierzy pod postacią "drzewka"
Po prawej stronie możemy zobaczyć szczegółowe własności wybranego komponentu oraz w niektórych przypadkach jego graficzny obraz z zaznaczonym położeniem.
Zakładka Hot Spares jest "nudna" więc nie będziemy jej tutaj prezentowali. Nazwa dość jednoznacznie tłumaczy jej zawartość.
Menu Storage:
Główna zakładka menu storage zawierająca podsumowanie to Summary:
Menu z opcjami po lewej stronie (identyczne dla wszystkich zakładek z grupy Storage) pozwala nam na przeproawdzenie podstawowych operacji na LUNach i Storage grupach, przy czym za najważniejszą należy oczywiście uznać stworzenie nowego LUNa. Dominującą część okna zajmuje coś w stylu "dashboard"-a z ogólnymi informacjami na temat statusu LUNów oraz pojemności i wykorzystania macierzy.
Pozostałe opcje (poza Summary) w menu Storage pokazują nam po kolei kolejne "struktury" jakie tworzymy na macierzy aby finalnie:
Zakładka Disks pokazuje nam jakie dyski mamy w macierzy - czyli zaczynamy od podstawowy fizycznych "cegiełek" dostarczających przestrzeń.
Same dyski nie umożliwią nam jeszcze wystawiania przestrzeni do serwerów, należy je odpowiednio skonfigurować - utworzyć z nich grupy ( w przypadku wystawiania tradycyjnego) lub pule (w przypadku użycia "thin provisioningu"). Każda grupa/pula dysków ma przypisany do siebie rodzaj protekcji RAID (0/1/5/6 itd...). Informacje na temat obecnych na macierzy grup/pul są dostępne w zakładce Pools/RAID Groups:
Mając stworzone struktury RAID można na nich tworzyć LUNy. Czyli te objekty, które będziemy prezentowali dla hostów.
Jak się nietrudno zorientować zakładka na której są informacje o LUNach nazywa się LUNs:
Oprócz obecnych w każdej zakładce menu Storage opcji "zadokowanych" po lewej stronie okna, pozostałą jego część zajmuje lista wszystkich LUNów zdefiniowanych na macierzy razem z pewnymi podstawowymi informacjami o nich (Nazwa, Numer, Status, Pojemność, Do jakiego hosta został wystawiony)
Po stworzeniu LUNów została nam jeszcze tylko jedna rzecz do skonfigurowania na macierzy, tak aby z przestrzeni danego LUNa mógł korzystać host.
Należy wykonać tzw: mapowanie czyli zezwolić macierzy na skomunikowanie się ze sobą wybranego hosta z wybranym LUNem. Wykorzystuje się do tego strukturę nazwaną Storage Group, która składa się z dwóch części. W jednej z nich mamy listę LUNów, a w drugiej listę Hostów. To co robi macierz to pozwala aby wszystkie hosty z grupy, miały dostęp do wszystkich LUNów z tej samej grupy.
Oczywiście przy tworzeniu takich grup mamy do dyspozycji różne warianty i opcje, ale w tym wpisie nie chodzi nam o wyjaśnienie tego procesu ale tylko pokazanie miejsca gdzie w Unisphere są okienka i menu związane z takimi objektami.
Znajduje się to w zakładce Storage Gropus:
W górnej części widzimy listę zdefiniowanych grup a na dole w zakładkach można sprawdzić jakie LUNy i hosty zostały do niej przypisane.
Ostatnia pozycja to Folders , w przeciwieństiwe do pozostałych opcji nie jest to kolejny "krok" przy tworzeniu i wystawianiu zasobów. W tym oknie możemy zobaczyć sobie LUNy podzielone na różne kategorie (foldery) - między innymi: LUNy nie wystawione do hostów, LUNy przypisane do poszczególnych SP, MetaLUNy (czyli kilka LUNów połączonych w jeden). Można także w tym miejscu zdefiniować swoje katalogi i poprzypisywać do nie zasoby.
Menu Hosts:
Tak jak i w pozostałych przypadkach menu host posiada swoją zakładkę Summary:
I tak jak się można domyślić znajduje się na niej kilka okienek z podstawowymi informacjami na temat widzianych przez macierz hostów.
Pozostałe dwie opcje w menu "Hosts" odpowiadają za liste wszystkich serwerów podpiętych do macierzy (Host List) oraz za integrację z VMware (Virtualization).
Dość lakonicznie to opisuję, ale więcej nie trzeba :D
Pozostałe Menu z grupy System List:
Zostały jeszcze 4 nieomówione menu z całej grupy opcji związanych z poszczególnymi macierzami.
Są to mianowicie: Replicas, Monitoring, Settings, Support
Nie będę poświęcał im tyle czasu i uwagi w tym wpisie co pozostałym. Jeżeli chodzi o menu Replicas to oczywiście zawiera ono opcje to tworzenia i konfigurowania najróżniejszych tworów związanych z replikami lokalnymi oraz zdalnymi - same mechanizmy będą opisane w innym miejscu i późniejszym czasie.
Jeżeli chodzi o Monitoring, to każda z jego opcji jest jakby osobnym narzędziem, przy czym niektóre z nich są osobno licencjonowane (np Analyzer czy Quality of Service Manager). One także powinny doczekać się swoich własnych wpisów.
Menu Settings oraz Support są średnio ciekawe i nie ma tam fajerwerków - nazwa mówi wszysko.
Podsumowując:
Wpis dość długi i dodatkowo pełen zrzutów ekranowych. W zasadzie mam co do niego ambiwalentne uczucia, gdyż to wszysko co jest tutaj opisane poznaje się w ciągu kilkunastu minut "przeklikiwania" się przez macierz. Przygotowanie tego wpisu zajęło mi dużo więcej czasu, szczególnie w zakresie przygotowywania zrzutów i zaciemniania wszelkiego rodzaju numerów seryjnych oraz nazw.
Na pewno pojawi się jeszcze jeden (lub nawet więcej) wpisów związanych z Unisphere, ale będą bardziej treściwe i pokażą jak wykonywać pewne (podstawowe) czynności na macierzy lub gdzie szukać bardziej precyzyjnych ustawień - obiecuję nie będzie już takiej treści ogólnej z zdjęciami dashbordów i listw z menu :D
Choć najprawdopodobniej kolejny post na blogu nie będzie dotyczył Clariionów i przygotowań do nieszczęsnego egzaminu.
sobota, 17 grudnia 2011
Clariion - FAST Cache
Po wpisie dotyczącym autentyfikacji użytkowników i innych spraw średnio przydatnych przy codziennym administrowaniu macierzami, wracamy do zagadnień "ciekawszych".
Dzisiejszym tematem jest nowa funkcjonalność zaimplementowana we FLARE30 i dostępna w macierzach Clariion CX4 oraz VNX, chodzi mianowicie o FAST Cache. Nazwa może być trochę myląca, ponieważ jest to co innego niż FAST (nazwa na automatyczny tiering w macierzach EMC). Gdyby opisać jednym zdaniem działanie FAST Cache, to jest to wykorzystanie dysków SSD do rozszerzenia pamięci cache.
Podstawy
Funkcjonalność FAST Cache została wprowadzona przez FLARE30 i polega ona na wykorzystaniu dysków SSD, nie jako przestrzeni do wystawiania danych, ale jako rozszerzenie pamięci cache. Można (w zależności od konfiguracji i ilości dysków SSD) "rozbudować" cache macierzy o wielkości od 73GB do 2TB.
Celem takiego ruchu jest oczywiście zapewnienie większej wydajności jaką zapewnia zwiększona "pamięć podręczna". Dyski SSD mają dużo lepsze parametry niż ich "tradycyjni", mechaniczni koledzy i dlatego operacje IO są na nich wykonywane dużo szybciej.
Uruchomienie funkcjonalności FAST Cache może być wykonane podczas działania macierzy i nie wymaga jej wyłączenia, to samo dotyczy zmian (zwiększenia/zmniejszenia/usunięcia) ilości przestrzeni o jaką chcemy "rozbudować" nasz cache.
Do FAST Cache możemy dołączać całe dyski SSD, nie jest możliwe podzielenie dysku na części i wykorzystanie np: kawałka na wystawianie przestrzeni, a reszty dla FAST Cache.
Po uruchomienia FAST Cache wszyskie nowo tworzone LUNy mają domyślnie aktywną opcję korzystania z tej funkcjonalności, jeżeli chcemy uruchomić ją także dla już istniejących zasobów, należy to zrobić ręcznie( włączenie/wyłączenie FAST Cache można robić per LUN lub per storage pula). Zasoby znajdujące się na dyskach SSD mają FAST Cache wyłączony.
Porównanie pamięci cache i FAST cache.
Mimo iż dyski SSD są dużo szybsze niż mechniczne to jednak nie zapewnieją tych samych parametrów i czasów odpowiedzi co "natywny" cache macierzy oparty na kościach DRAM.
W tabelce jest porównanie tych dwóch rodzajów "cache":
Działanie FAST Cache:
Czas na opisanie budowy i działania FAST Cache na nieco większym poziomie szczegółowości.
Na FAST Cache składają się dwa komponenty:
Dzisiejszym tematem jest nowa funkcjonalność zaimplementowana we FLARE30 i dostępna w macierzach Clariion CX4 oraz VNX, chodzi mianowicie o FAST Cache. Nazwa może być trochę myląca, ponieważ jest to co innego niż FAST (nazwa na automatyczny tiering w macierzach EMC). Gdyby opisać jednym zdaniem działanie FAST Cache, to jest to wykorzystanie dysków SSD do rozszerzenia pamięci cache.
Podstawy
Funkcjonalność FAST Cache została wprowadzona przez FLARE30 i polega ona na wykorzystaniu dysków SSD, nie jako przestrzeni do wystawiania danych, ale jako rozszerzenie pamięci cache. Można (w zależności od konfiguracji i ilości dysków SSD) "rozbudować" cache macierzy o wielkości od 73GB do 2TB.
Celem takiego ruchu jest oczywiście zapewnienie większej wydajności jaką zapewnia zwiększona "pamięć podręczna". Dyski SSD mają dużo lepsze parametry niż ich "tradycyjni", mechaniczni koledzy i dlatego operacje IO są na nich wykonywane dużo szybciej.
Uruchomienie funkcjonalności FAST Cache może być wykonane podczas działania macierzy i nie wymaga jej wyłączenia, to samo dotyczy zmian (zwiększenia/zmniejszenia/usunięcia) ilości przestrzeni o jaką chcemy "rozbudować" nasz cache.
Do FAST Cache możemy dołączać całe dyski SSD, nie jest możliwe podzielenie dysku na części i wykorzystanie np: kawałka na wystawianie przestrzeni, a reszty dla FAST Cache.
Po uruchomienia FAST Cache wszyskie nowo tworzone LUNy mają domyślnie aktywną opcję korzystania z tej funkcjonalności, jeżeli chcemy uruchomić ją także dla już istniejących zasobów, należy to zrobić ręcznie( włączenie/wyłączenie FAST Cache można robić per LUN lub per storage pula). Zasoby znajdujące się na dyskach SSD mają FAST Cache wyłączony.
Porównanie pamięci cache i FAST cache.
Mimo iż dyski SSD są dużo szybsze niż mechniczne to jednak nie zapewnieją tych samych parametrów i czasów odpowiedzi co "natywny" cache macierzy oparty na kościach DRAM.
W tabelce jest porównanie tych dwóch rodzajów "cache":
| Parametr | DRAM | Fast Cache |
| Wielkość | do 32GB (zależy od modelu macierzy) | do 2TB |
| Czas odpowiedzi | nanosekundy do milisekund | milisekundy do mikrosekund |
| Podział | Osobne obszary dla odczytu i zapisu | Współny obszar używany do "cachowanie" danych na odczyt i zapis |
| Ziarnistość (min rozmiar danych jakie można zapisać w cache) | Rozmiar pojedyńczej strony jest możliwy do zdefiniowania prze użytkownika. Możliwy zakres: od 2Kb do 16Kb | Operuje na kawałkach (extends) o wielkości 64Kb |
| Odporność na awarie | Nie jest odporny na utratę zasilania (musi być podtrzymany bateryjnie do czasu zrzutu na dysk). Po uszkodzeniu wymagana interwencja serwisanta. | Odporny na zanik zasilania. Uszkodzony dysk SSD w Fast Cache może być zastąpiony hot spare i wymieniony ręcznie. |
Działanie FAST Cache:
Czas na opisanie budowy i działania FAST Cache na nieco większym poziomie szczegółowości.
Na FAST Cache składają się dwa komponenty:
- Policy engine - odpowiada za zarządzanie i odpowiednie kierowanie przepływem żądań IO przez FAST Cache. Ten moduł decyduje który fragmet danych ma być umieszczony w pamięci FAST Cache, dba również o to aby nieużywane fragmenty były z niej usuwane.
- Memory map - mapa pokazująca jakie dane są w FAST Cache, przechowuje informację o zawartości każdego z 64KB fragmentów na jaki podzielony jest FAST Cache.
Przepływ danych przy włączonym FAST Cache:
Żądania IO przychodzące do macierzy są sprawdzane czy dotyczą zapisu/odczytu z LUNu (lub z puli) która ma włączoną funkcjonalność FAST Cache. Jeżeli tak to sprawdzane jest (w memory map) czy dane te są już w FAST Cache czy nie. Jeżeli ich nie ma, to dalsza "droga" danego IO jest taka sama jak w przypadku nie używania FAST Cache.
Jeżeli dane są w fast cache to policy engine przekierowuje IO do Fast Cache. Jeżeli IO jest żądaniem odczytu, a dane znajdują się w pamieci DRAM (czyli natywnym cache) to są stamtąd odczytywane, jeżeli ich tam nie ma, do odczyt ma miejsce z dysku SSD, a dodatkowo dane te są także zapisywane w DRAMie.
Jeżeli od strony hosta przychodzi żądanie zapisu, to jest ono obsługiwane w ten sam sposób, co normalnie (czyli z wyłączonym FAST Cache) - dane trafiają do DRAMu. Różnica polega na tym, że tzw "de-stagingig" czyli zrzucanie danych z pamięci cache na dyski, odbywa się dwuetapowo, najpierw dane są przegrywane z wewnętrznego cache (DRAM) na dyski SSD (Flash Cache), a dopiero potem na dyski mechaniczne. Pozwala to na dużo szybsze czyszczenie pamięci cache na DRAM z tzw "dirty pages", czyli danych które już zostały zaraportowane hostowi jako zapisane, ale ciągle są obecne jedynie w natywnej pamięci cache (DRAM), która nie jest odporna na zanik zasilania.
O tym, które dane są obecne w FLASH Cache, decyduje policy engine. Algorytm który jest wykorzystywany opiera się częstości w jakie hosty wykonują operacje IO na konkretnych blokach danych.
Proces przenoszenia często używanych danych z dysków mechanicznych na SSD nazywany jest Promotion. Przeniesienie danych do których częstość odwołań spadła z FLASH Cacha spowrotem na dyski mechaniczne nazywana jest Write Back.
Co do Write Back to nie mam pełnej jasnosci jak on dokładnie działa: W dokumentacji EMC (h8046-fast-cache-wp) pisze wyraźnie, że dane są kopiowane z SSD na HDD. Nieścisłość według mnie polega na tym, że podczas promocji do FAST Cache dane nie są przenoszone, ale kopiowane, czyli cały czas rezydują w swoim orginalnym miejscu, w cache - czy to zwykłym, czy FAST - znajduje się tylko ich kopia. Operacja odwrotna czyli Write Back nie powinien nic kopiować tylko zaznaczać na memory map, że dany blok nie jest już w tej pamięci obecny.
Jak uruchomić FAST Cache:
Z poziomu Unisphere Fast Cache uaktywnia się po wyborze opcji Storage System Properties na zakładce FAST Cache. Po uruchomieniu funkcjonalność ta jest domyślnie włączona dla wszyskich nowych zasobów.
Przy tworzeniu LUNa można włączyć/wyłączyć używanie przez niego FAST Cache w zakładce Create LUN-->Advanced poprzez zaznaczenie/odznaczenie odpowiedniego pola wyboru.
Dla istniejących LUNów zmiana tego parametru jest możliwa miejscu Properties-->Cache, w przypadku thin pool-i ustawienia FAST Cache są w Properties-->Advance.
Uruchamiać i konfigurować FAST Cache można również z poziomu CLI:
Uruchamianie FAST Cache:
cache -fast -create -disks -rtype -mode
gdzie:
-disks <-- dyski z których chcemy stworzyć FAST Cache.
-rtype <-- rodzaj protekcji (powinien być RAID1)
-mode <-- tryb ro (read only) lub rw (read write)
Usunięcie FAST Cache:
cache -fast -destroy
Jeżeli od strony hosta przychodzi żądanie zapisu, to jest ono obsługiwane w ten sam sposób, co normalnie (czyli z wyłączonym FAST Cache) - dane trafiają do DRAMu. Różnica polega na tym, że tzw "de-stagingig" czyli zrzucanie danych z pamięci cache na dyski, odbywa się dwuetapowo, najpierw dane są przegrywane z wewnętrznego cache (DRAM) na dyski SSD (Flash Cache), a dopiero potem na dyski mechaniczne. Pozwala to na dużo szybsze czyszczenie pamięci cache na DRAM z tzw "dirty pages", czyli danych które już zostały zaraportowane hostowi jako zapisane, ale ciągle są obecne jedynie w natywnej pamięci cache (DRAM), która nie jest odporna na zanik zasilania.
O tym, które dane są obecne w FLASH Cache, decyduje policy engine. Algorytm który jest wykorzystywany opiera się częstości w jakie hosty wykonują operacje IO na konkretnych blokach danych.
Proces przenoszenia często używanych danych z dysków mechanicznych na SSD nazywany jest Promotion. Przeniesienie danych do których częstość odwołań spadła z FLASH Cacha spowrotem na dyski mechaniczne nazywana jest Write Back.
Co do Write Back to nie mam pełnej jasnosci jak on dokładnie działa: W dokumentacji EMC (h8046-fast-cache-wp) pisze wyraźnie, że dane są kopiowane z SSD na HDD. Nieścisłość według mnie polega na tym, że podczas promocji do FAST Cache dane nie są przenoszone, ale kopiowane, czyli cały czas rezydują w swoim orginalnym miejscu, w cache - czy to zwykłym, czy FAST - znajduje się tylko ich kopia. Operacja odwrotna czyli Write Back nie powinien nic kopiować tylko zaznaczać na memory map, że dany blok nie jest już w tej pamięci obecny.
Jak uruchomić FAST Cache:
Z poziomu Unisphere Fast Cache uaktywnia się po wyborze opcji Storage System Properties na zakładce FAST Cache. Po uruchomieniu funkcjonalność ta jest domyślnie włączona dla wszyskich nowych zasobów.
Przy tworzeniu LUNa można włączyć/wyłączyć używanie przez niego FAST Cache w zakładce Create LUN-->Advanced poprzez zaznaczenie/odznaczenie odpowiedniego pola wyboru.
Dla istniejących LUNów zmiana tego parametru jest możliwa miejscu Properties-->Cache, w przypadku thin pool-i ustawienia FAST Cache są w Properties-->Advance.
Uruchamiać i konfigurować FAST Cache można również z poziomu CLI:
Uruchamianie FAST Cache:
cache -fast -create -disks -rtype -mode
gdzie:
-disks <-- dyski z których chcemy stworzyć FAST Cache.
-rtype <-- rodzaj protekcji (powinien być RAID1)
-mode <-- tryb ro (read only) lub rw (read write)
Usunięcie FAST Cache:
cache -fast -destroy
poniedziałek, 12 grudnia 2011
Magiczny kwadrat Gartnera dla macierzy
Dzisiaj krótki wpis nie związany z wątkiem Clariionów i przygotowania do certyfikacji z tego zakresu.
Gartner, czyli jedna z największych firm doradczych specjalizujących się w nowych technologiach, opublikowała swój tzw: "magiczny kwadrat" za rok 2011 dla macierzy mid-range oraz high-end.
Kwadrat ten jest układem współrzędnych, gdzie na osi poziomej mamy "completness of vision" co można nazwać innowacyjnością i potencjałem jaki tkwi w danej firmie, na osi pionowej natomiast "ability to execute" czyli jaką siłę przebicia i pozycję na rynku ma dany dostawca.
Te dwie linie dzielą cały duży "kwadrat" na cztery mniejsze. Obecność w danym "kwadraciku" pozwala (oczywiście w przybliżeniu) zaklasyfikowac daną firmę i ocenić jej produkty.
Te cztery mniejsze "kwadraciki" to:
Gartner, czyli jedna z największych firm doradczych specjalizujących się w nowych technologiach, opublikowała swój tzw: "magiczny kwadrat" za rok 2011 dla macierzy mid-range oraz high-end.
Kwadrat ten jest układem współrzędnych, gdzie na osi poziomej mamy "completness of vision" co można nazwać innowacyjnością i potencjałem jaki tkwi w danej firmie, na osi pionowej natomiast "ability to execute" czyli jaką siłę przebicia i pozycję na rynku ma dany dostawca.
Te dwie linie dzielą cały duży "kwadrat" na cztery mniejsze. Obecność w danym "kwadraciku" pozwala (oczywiście w przybliżeniu) zaklasyfikowac daną firmę i ocenić jej produkty.
Te cztery mniejsze "kwadraciki" to:
- Leaders (wysoka "completness of vision" i wysoka "ability to execute") - firmy liderzy, dobra pozycja na rynku, duże możliwości i duży potencjał na rozwój
- Challengers (niska"completness of vision" i wysoka "ability to execute") - firmy o dużych możliwościach marketingowo-sprzedażowych, silnej pozycji ale nieco w stagnacji. Mniej innowacyjne i nowoczesne.
- Visionares(wysoka "completness of vision" i niska "ability to execute") - zwykle małe firmy z małym udziałem na rynku, ale oferującym bardzo nowatorskie rozwiązania.
- Niche players(niska "completness of vision" i niska "ability to execute") - gracze "niszowi" zwykle nie liczący się na danym rynku i z gorszymi rozwiązaniami niż konkurencja
Dla macierzy mid i hig-end Gartner widzi obecną sytuację następująco:
 |
| Źródło: Gartner (październik 2011) |
Można powiedzieć, NetApp na czele ale bardzo blisko EMC a także HP,IBM i DELL.
EMC mimo iż wciąż wśród liderów to jednak pod względem innowacyjności zostało ocenione nieco gorzej.
Najgorsi z najlepszych to Hitachi. Pojawia się tutaj także firma o której szczerze przyznam mało wiem (i chyba trzeba będzie to zmienić) czyli XIO - jedyny z wizjonerów według Gartnera.
Pozostali gracze to w zasadzie albo "niche players", albo na granicy tak jak Fujitsu i Oracle. Muszę przyznać, że wypozycjonowanie tego ostatniego mnie nieco zaskoczyło - myślałem że będzie lepiej.
Oprócz samego "magicznego kwadratu" Gartner daje także dość dokładne wytyczne według jakich kryteriów był on wyznaczany oraz wskazuje silne i słabe strony każdego z uwzględnionych producentów.
Nie będę się powtarzał i zainteresowanych odsyłam do samego raportu:
wtorek, 15 listopada 2011
Clariion - Unisphere Security Features
Tytuł po angielsku (brakło weny do stworzenia jakiegoś w miarę dobrego tłumaczenia) ale sama treść już w języku ojczystym ;)
Tym razem będzie o czymś na co w praktyce (przynajmniej mojej osobistej) raczej nie zwracałem uwagi. Temat przewodni to bezpieczeństwo a konkretnie sposoby na jakie Clariion (a w zasadzie Unisphere) pilnuje, aby dostępu do niego miały tylko uprawnione osoby i tylko w tym zakresie jaki został im udostępniony.
Ponieważ operacje zakładania i dawania dostępu nowym użytkownikom do macierzy to nie jest coś, co się przeprowadza regularnie i często, tak więc zwykle nie pamięta się wszyskich możliwości i niuansów jakie są z tym związane.
Podejrzewam jednak, że udane podejście do egzaminu na Clariion Specialist wymaga odświeżenia i uporządkowania sobie wiedzy w tym zakresie.
Do rzeczy.
Macierzą można zarządzać przez dwa główne interfejsy. Unisphere - czyli GUI dostępne poprzez przeglądarkę sieciową lub za pomocą linii komend.
Unisphere:
Aby dostać się do Unisphere należy w przeglądarce wpisać adres http://<clariion_ip> - powoduje to uruchomienie apletu Javy. Aplet ten zestawia bezpieczne, szyfrowane połączenie ( SSL/TLS na porcie 443) z storage management serwerem na macierzy. Dzięki temu, mimo iż nie jest bezpośrednio używany https, połączenie jest zabezpieczone.
Szyfrowana jest także cała komunikacja pomiędzy storage management serwerami na różnych macierzach.
Podczas logowania się do macierzy za pomocą Unisphere użytkownik autentyfikuje się podając login, hasło oraz tzw zakres (scope)
SecureCLI:
Podczas używania linii poleceń komunikacja z macierzą jest zabezpieczona w ten sam sposób, co przy łączeniu poprzez Unisphere (szyfrowanie połączenia).
Jeżeli chodzi o autoryzację, to administrator przy wpisywaniu komend, każdorazowo powinien podać login,hasło oraz zakres. Ponieważ takie rozwiązanie nie jest zbyt wygodne mamy możliwość stworzenia tzw "Security File". "Security File" jest przypisany do danego użytkownika na systemie operacyjnym, z którego wydaje się polecenia do clariiona i zawiera w sobie zaszyfrowany login,hasło i scope. Dzięki temu dany użytkownik nie musi ich podawać razem z każdą wysłaną komendą.
Komenda tworząca "Security File" to addusersecurity i ma następującą składnię:
naviseccli -addusersecurity -user <username> -password <pw> -scope<0|1|2>
Sam "Security file" to tak naprawdę dwa pliki które umiejscawiają się na home folderze użytkownika:
SecuredCLISecurityFile.xml i SecuredCLIXMLEncrypted.key
Usunięcie "Security Pliku" wykonuje się poleceniem:
naviseccli -removeusersecurity
Zakres (scope):
Każde konto do zarządzania Clariionami ma jeden z trzech zakresów:
Autentyfikacja przez serwer LDAP:
Metoda wykorzystania do zarządzania Clariionami konta z domeny jest najbardziej wygodna. Dzięki temu nie musimy wyodrębniać zarządzania użytkownikami macierzą do innego miejsca i możemy utrzymać centralny punkt (domena np: AD) do zarządzania uprawnieniami.
Macierz musi być najpierw odpowiednio skonfigurowana aby móc na niej korzystać z użytkowników domenowych. Z poziomu Unisphere ustawienia dotyczące LDAPa można znaleźć w menu:
All Systems > Domains > Configure LDAP for CLARiiON Systems
W tym miejscu można przede wszystkim dodać(i zmienić) adresy naszych kontrolerów domeny.
Tutaj także ustawia się interwał synchronizacji. Storage server przechowuje (cache-uje) informacje o kontach i ich uprawnieniach pobrane z domeny tak, żeby każde wydane polecenie nie musiało być autentyfikowane z kontrolerem. Standardowo ten cache jest czyszczony co 24h, ale jeżeli chcemy aby czas ten uległ skróceniu i macierz częściej odświeżała/synchronizowała informacje z domeny możemy zmienić.
Role użytkowników:
Ostatni temat jaki zostanie omówiony w tym wpisie, to role czyli rodzaje kont jakie można założyć na macierzy. Różnią się one, oczywiście, rodzajem uprawnień, a przez to działaniami jakie dany użytkownik może wykonywać.
Dostępne są następujące role:
Co istotne żadna z tych 3 ról "replikacyjnych" nie zezwala na tworzenie nowych bytów związanych z replikacją (jak klony, kopie migawkowe itd...). Możliwe jest jedynie zarządzanie już istniejącymi obiektami.
Tym razem będzie o czymś na co w praktyce (przynajmniej mojej osobistej) raczej nie zwracałem uwagi. Temat przewodni to bezpieczeństwo a konkretnie sposoby na jakie Clariion (a w zasadzie Unisphere) pilnuje, aby dostępu do niego miały tylko uprawnione osoby i tylko w tym zakresie jaki został im udostępniony.
Ponieważ operacje zakładania i dawania dostępu nowym użytkownikom do macierzy to nie jest coś, co się przeprowadza regularnie i często, tak więc zwykle nie pamięta się wszyskich możliwości i niuansów jakie są z tym związane.
Podejrzewam jednak, że udane podejście do egzaminu na Clariion Specialist wymaga odświeżenia i uporządkowania sobie wiedzy w tym zakresie.
Do rzeczy.
Macierzą można zarządzać przez dwa główne interfejsy. Unisphere - czyli GUI dostępne poprzez przeglądarkę sieciową lub za pomocą linii komend.
Unisphere:
Aby dostać się do Unisphere należy w przeglądarce wpisać adres http://<clariion_ip> - powoduje to uruchomienie apletu Javy. Aplet ten zestawia bezpieczne, szyfrowane połączenie ( SSL/TLS na porcie 443) z storage management serwerem na macierzy. Dzięki temu, mimo iż nie jest bezpośrednio używany https, połączenie jest zabezpieczone.
Szyfrowana jest także cała komunikacja pomiędzy storage management serwerami na różnych macierzach.
Podczas logowania się do macierzy za pomocą Unisphere użytkownik autentyfikuje się podając login, hasło oraz tzw zakres (scope)
SecureCLI:
Podczas używania linii poleceń komunikacja z macierzą jest zabezpieczona w ten sam sposób, co przy łączeniu poprzez Unisphere (szyfrowanie połączenia).
Jeżeli chodzi o autoryzację, to administrator przy wpisywaniu komend, każdorazowo powinien podać login,hasło oraz zakres. Ponieważ takie rozwiązanie nie jest zbyt wygodne mamy możliwość stworzenia tzw "Security File". "Security File" jest przypisany do danego użytkownika na systemie operacyjnym, z którego wydaje się polecenia do clariiona i zawiera w sobie zaszyfrowany login,hasło i scope. Dzięki temu dany użytkownik nie musi ich podawać razem z każdą wysłaną komendą.
Komenda tworząca "Security File" to addusersecurity i ma następującą składnię:
naviseccli -addusersecurity -user <username> -password <pw> -scope<0|1|2>
Sam "Security file" to tak naprawdę dwa pliki które umiejscawiają się na home folderze użytkownika:
SecuredCLISecurityFile.xml i SecuredCLIXMLEncrypted.key
Usunięcie "Security Pliku" wykonuje się poleceniem:
naviseccli -removeusersecurity
Zakres (scope):
Każde konto do zarządzania Clariionami ma jeden z trzech zakresów:
- Local - konto zdefiniowane na jednej macierzy
- Global - konto umożliwiające administrowanie każdą z macierzy w domenie
- LDAP - konto zdefiniowane na serwerze LDAP (np: w domenie AD) i umożliwiające zalogowanie się do każdej macierzy używającej LDAPu do autentyfikacji
Autentyfikacja przez serwer LDAP:
Metoda wykorzystania do zarządzania Clariionami konta z domeny jest najbardziej wygodna. Dzięki temu nie musimy wyodrębniać zarządzania użytkownikami macierzą do innego miejsca i możemy utrzymać centralny punkt (domena np: AD) do zarządzania uprawnieniami.
Macierz musi być najpierw odpowiednio skonfigurowana aby móc na niej korzystać z użytkowników domenowych. Z poziomu Unisphere ustawienia dotyczące LDAPa można znaleźć w menu:
All Systems > Domains > Configure LDAP for CLARiiON Systems
W tym miejscu można przede wszystkim dodać(i zmienić) adresy naszych kontrolerów domeny.
Tutaj także ustawia się interwał synchronizacji. Storage server przechowuje (cache-uje) informacje o kontach i ich uprawnieniach pobrane z domeny tak, żeby każde wydane polecenie nie musiało być autentyfikowane z kontrolerem. Standardowo ten cache jest czyszczony co 24h, ale jeżeli chcemy aby czas ten uległ skróceniu i macierz częściej odświeżała/synchronizowała informacje z domeny możemy zmienić.
Role użytkowników:
Ostatni temat jaki zostanie omówiony w tym wpisie, to role czyli rodzaje kont jakie można założyć na macierzy. Różnią się one, oczywiście, rodzajem uprawnień, a przez to działaniami jakie dany użytkownik może wykonywać.
Dostępne są następujące role:
- Monitor - użytkownik z uprawnieniami read-only
- Manager - użytkownik mogący zarządzać macierzą ale nie mający uprawnień do tworzenia i zarządzania kontami użytkowników na niej.
- Administratror - użytkownik posiadający maksymalne uprawnienia zarówno jeżeli chodzi o zarządzanie macierzą (tworzenie, wystawianie LUNów, definiowanie RAID grup itd..) jak i o zarządzanie użytkownikami
- Security Administrator - użytkownik mogący tworzyć i zarządzać innymi użytkownikami, ale nie mogący konfigurować macierzy.
Od FLARE29 dostępne są także 3 role do działań związanych z replikacją:
- Local Replication - użytkownik może wykonywać operacje związane z replikacją lokalną SnapView
- Replication - użytkownik może wykonać operacje związane z replikcją zdalną - MirrorView, oraz lokalną.
- Replication/Recovery - rola podobna jak Replication ale dodatkowo użytkownik może wykonywać operacje "odzyskania" np: roll-back z kopii migawkowej.
Co istotne żadna z tych 3 ról "replikacyjnych" nie zezwala na tworzenie nowych bytów związanych z replikacją (jak klony, kopie migawkowe itd...). Możliwe jest jedynie zarządzanie już istniejącymi obiektami.
Przejście na konto z Google+
Mała zmiana na tym blogu.
Połączyłem swoje konto Bloggerowe z kontem Google+
Bezpośrednie zmiany dla czytających są takie, że teraz z prawego górnego rogu będzie straszyło zdjęcie mojej facjaty, a link zamiast do profilu na Bloggerze poprowadzi do Google+
Niestety wszystkie komentarze jakie zrobiłem do tej pory będą dalej wyświetlały jako autora Akodo (czyli nazwę mojego profilu Bloggerowego). Niezbyt to fajne, ale do przeżycia.
Jeżeli z jakiś powodów takie ustawienie mi się "odwidzi" to wrócę na powrót do odseparowania tych dwóch "tożsamości" ale nie widzę zbytnio powodów czemu miałbym tak robić.
Profile połączyłem bo chciałem. Nie stoi za tym żadna większa przyczyna :D
Połączyłem swoje konto Bloggerowe z kontem Google+
Bezpośrednie zmiany dla czytających są takie, że teraz z prawego górnego rogu będzie straszyło zdjęcie mojej facjaty, a link zamiast do profilu na Bloggerze poprowadzi do Google+
Niestety wszystkie komentarze jakie zrobiłem do tej pory będą dalej wyświetlały jako autora Akodo (czyli nazwę mojego profilu Bloggerowego). Niezbyt to fajne, ale do przeżycia.
Jeżeli z jakiś powodów takie ustawienie mi się "odwidzi" to wrócę na powrót do odseparowania tych dwóch "tożsamości" ale nie widzę zbytnio powodów czemu miałbym tak robić.
Profile połączyłem bo chciałem. Nie stoi za tym żadna większa przyczyna :D
poniedziałek, 7 listopada 2011
Clariion - software (przegląd)
Dzisiaj na tapetę bierzemy software na jakim działa Clariion.
Całe oprogramowanie związane z tą macierzą można podzielić na dwie kategorie:
Nieco więcej szczegółów opisujących działanie najważniejszych z tych pozycji oraz wzajemne interakcje między nimi:
Unisphere
Jest to interejs, który pozwala nam poprzez przeglądarke i aplet JAVA podłączyć się do macierzy. Unisphere łączy się z Management Serverem zainstalowanym na Service Procesorze macierzy i dostarcza wygodnego interfejsu do zarządzania jej zasobami.
Unisphere pojawił się razem z FLARE30, w poprzednich wersjach firmwaru powłoka i GUI nazywało się NaviSphere.
Unisphere ( a konkretnie jeden z jego ekranów pokazujący stan komponentów hardware) wygląda następująco:
Co prawda ten zrzut nie jest z Unisphere działającego na Clariionie ale na jego "następcy" VNXie ale wygląd jest identyczny.
W materiałach EMC Unisphere jest zakwalifikowany jako oprogramowanie "host based" (zainstalowany na serwerze podpiętym do macierzy) ale ja jakoś bardziej bym go umiejscawiał w samym SP - jako część FLARE.
FLARE
Flare (Fibre Logic Array Runtime Environment) jest głównym oprogramowaniem działającym na Clariionie i zapewnia macierzy jej podstawową funkcjonalność (tworzenie RAIDów, obsługa cache etc...). FLARE jest umieszczony w tzw: vaulcie (5 pierwszych dysków na pierwszej półce dyskowej) i podczas ładowania/startu Service Procesorów jest na nie wgrywany. FLARE tak naprawdę jest to Windows XP z "nakładką" przygotowaną przez EMC.
(Storage) Management Server
Oprogramowanie działające albo na samym SP w Clariionie albo (opcjonalnie) na wydzielonym serwerze Windowsa. Polecenia jakie użytkownik(administrator) wysyła do macierzy poprzez przeglądarkę sieciową(Unisphere) lub z linii poleceń trafiają do Management Servera. Management Server kieruje następnie dane polecenia do odpowiedniego modułu nimi zarządzającego (np: Performance, Security, Raporty itd...). Wszyskie komendy wymagające zmiany na samej macierzy idą do FLARE.
Management server zajmuje się także zarządzanie tzw: domeną.
Domena jest to grupa Clariionów zarządzana z jednego miejsca. Posiadając więcej macierzy tego typu niezbyt wygodne było by zarządzanie każdą z nich poprzez bezpośrednie logowanie - dlatego tworzy się domenę - pojedynczy punkt zarządzania - i możemy administrować nimi logując się tylko do jednej, wybranej macierzy, która staje się wtedy kontrolerem domeny (nie ma to oczywiście nic wspólnego z kontrolerem domeny Acitve Directory znanego z produktów Microsoft-u).
Jeżeli posiadamy naprawdę dużą liczbę Clariionów (kilkaset) i chcemy je umieścić w jednej domenie, można rozważyć instalację Management Servera na dedykowanym serwerze z Windowsem i w ten sposób odciążymy Service Procesor macierzy od kontrolowania tak dużej domeny. Ma to jednak sens jedynie w naprawdę dużych środowiskach.
NaviSphere Secure CLI
Jest to interfejs tekstowy (Command Line Interface) za pomocą którego można administrować Clariionami. Jest to metoda alternatywna do graficznego interfejsu dostępnego poprzez przeglądarkę sieciową i Unisphere. Wykorzystując tą metodę zarządzania wydajemy polecenia bezpośrednio do macierzy (do Management Servera) - nie ma tutaj użycia domeny i pojedynczego punktu do zarządzania i monitorowania.
Całe oprogramowanie związane z tą macierzą można podzielić na dwie kategorie:
- Software na macierzy
- Management Server & User Interface server
- Unisphere Agent
- FLARE
- Software zainstalowany na serwerze podpiętym do macierzy
- Unisphere
- Unisphere agent (opcjonalnie)
- Navisphere Secure CLI
- Unisphere Server Utility
- Unisphere Storage System Initialization Utility
- Unisphere Service Manager
- Management Server & User Interface server (opcjonalnie)
Nieco więcej szczegółów opisujących działanie najważniejszych z tych pozycji oraz wzajemne interakcje między nimi:
Unisphere
Jest to interejs, który pozwala nam poprzez przeglądarke i aplet JAVA podłączyć się do macierzy. Unisphere łączy się z Management Serverem zainstalowanym na Service Procesorze macierzy i dostarcza wygodnego interfejsu do zarządzania jej zasobami.
Unisphere pojawił się razem z FLARE30, w poprzednich wersjach firmwaru powłoka i GUI nazywało się NaviSphere.
Unisphere ( a konkretnie jeden z jego ekranów pokazujący stan komponentów hardware) wygląda następująco:
 |
| źródło: Screenshot z własnego ekranu ;) Uruchomione EMC VNXe Demo |
Co prawda ten zrzut nie jest z Unisphere działającego na Clariionie ale na jego "następcy" VNXie ale wygląd jest identyczny.
W materiałach EMC Unisphere jest zakwalifikowany jako oprogramowanie "host based" (zainstalowany na serwerze podpiętym do macierzy) ale ja jakoś bardziej bym go umiejscawiał w samym SP - jako część FLARE.
FLARE
Flare (Fibre Logic Array Runtime Environment) jest głównym oprogramowaniem działającym na Clariionie i zapewnia macierzy jej podstawową funkcjonalność (tworzenie RAIDów, obsługa cache etc...). FLARE jest umieszczony w tzw: vaulcie (5 pierwszych dysków na pierwszej półce dyskowej) i podczas ładowania/startu Service Procesorów jest na nie wgrywany. FLARE tak naprawdę jest to Windows XP z "nakładką" przygotowaną przez EMC.
(Storage) Management Server
Oprogramowanie działające albo na samym SP w Clariionie albo (opcjonalnie) na wydzielonym serwerze Windowsa. Polecenia jakie użytkownik(administrator) wysyła do macierzy poprzez przeglądarkę sieciową(Unisphere) lub z linii poleceń trafiają do Management Servera. Management Server kieruje następnie dane polecenia do odpowiedniego modułu nimi zarządzającego (np: Performance, Security, Raporty itd...). Wszyskie komendy wymagające zmiany na samej macierzy idą do FLARE.
Management server zajmuje się także zarządzanie tzw: domeną.
Domena jest to grupa Clariionów zarządzana z jednego miejsca. Posiadając więcej macierzy tego typu niezbyt wygodne było by zarządzanie każdą z nich poprzez bezpośrednie logowanie - dlatego tworzy się domenę - pojedynczy punkt zarządzania - i możemy administrować nimi logując się tylko do jednej, wybranej macierzy, która staje się wtedy kontrolerem domeny (nie ma to oczywiście nic wspólnego z kontrolerem domeny Acitve Directory znanego z produktów Microsoft-u).
Jeżeli posiadamy naprawdę dużą liczbę Clariionów (kilkaset) i chcemy je umieścić w jednej domenie, można rozważyć instalację Management Servera na dedykowanym serwerze z Windowsem i w ten sposób odciążymy Service Procesor macierzy od kontrolowania tak dużej domeny. Ma to jednak sens jedynie w naprawdę dużych środowiskach.
NaviSphere Secure CLI
Jest to interfejs tekstowy (Command Line Interface) za pomocą którego można administrować Clariionami. Jest to metoda alternatywna do graficznego interfejsu dostępnego poprzez przeglądarkę sieciową i Unisphere. Wykorzystując tą metodę zarządzania wydajemy polecenia bezpośrednio do macierzy (do Management Servera) - nie ma tutaj użycia domeny i pojedynczego punktu do zarządzania i monitorowania.
Subskrybuj:
Posty (Atom)