0
Items : 0
Subtotal : 0,00 
View CartCheck Out
0
Items : 0
Subtotal : 0,00 
View CartCheck Out

Przedstawiam wam ostatnią cześć podsumowania zmian w wersji vSphere 5. Zajmiemy się zmianami w obsłudze zasobów dyskowych. Myślę, że właśnie w tym miejscu zaszły największe zmiany, dzięki którym odejdzie nam sporo problemów i zmartwień. Tak, więc…

vSphere VMFS 5

Wraz z nową wersją vSphere przyjdzie nowy system plików VMFS w wersji 5. Będzie to w zasadzie przebudowany od podstaw, nowy system plików z nową architekturą i zwiększoną stabilnością i wydajnością. Zmiany są fundamentalne i co najważniejsze tak długo wyczekiwane:

  • Wsparcie dla zasobów dyskowych do 64TB
  • Unified block size
  • Usprawniony mechanizm subblock

Dla nas szaraczków oznacza to przede wszystkim uwolnienie się z jarzma 2TB powierzchni dyskowej, która wielokrotnie przyprawiała o nieżyt wątroby. Dodatkowo ujednolicony rozmiar bloku, 1MB, umożliwia łatwiejsze wdrożenie i zmniejszenie złożoności architektonicznej, oraz ułatwienie zarządzania przy zachowaniu skalowalności i elastyczności, które wcześniej można było znaleźć tylko z przy dużych rozmiarach bloków. Należy zauważyć, że woluminy, podczas uaktualniania z VMFS-3 do VMFS-5 zachowują oryginalny rozmiar bloku, gdyż zmieniając rozmiar bloku należałoby sformatować wolumin. Aby zwiększyć skalowalność i zmniejszyć obciążenie pamięci związane z obsługą małych plików, wprowadzono różne ulepszenia w VMFS-5. Jednym z nich są zoptymalizowane rozmiaru subblock i podziału tych bloków. W efekcie daje to, tak jak już wspomniałem, wsparcie dla dużych woluminów (64TB) i zapewnia wyższa gęstość wirtualnych maszyn, jednocześnie zmniejszając obciążenie związane z małymi plikami. VMFS-5 jest w stanie przydzielić 30.000 subblock’ów 8KB kazdy do plików, takich jak pliki logów, plik metadanych wirtualnej maszyny (. vmx). Natomiast dla plików o rozmiarze mniejszym niż 1KB używane są tak zwane „small file blocks”.

vSphere Storage DRS

Odkąd VMware wprowadził funkcję Storage vMotion nie trudno było się domyślić że kiedyś nadejdzie ten moment kiedy to problem rozkładania między zasobami dyskowymi zostanie oddzielony od nas kolejną warstwą abstrakcji. Jeżeli okaże się, że VMware stworzy klastrowanie zasobów dyskowych tak samo dobrze jak zrobił to ze zwykłym, DRS to…hymmm… Perspektywa domku w górach i zarządzanie z stamtąd całą farmą ESX’ów zdaje się coraz bardziej krystalizować 🙂 Ale może nie ma co się zbyt wcześnie napalać. Zobaczmy najpierw, co jest planowane…

Wraz z nowym vSphere 5.0 pojawi się również nowy obiekt w VMware vCenter zwany „Datastore Cluster”. Klastry obiektów Datastore stanowią podstawę Stroage DRS. Datastore Cluster jest zbiorem wolumenów VMFS zagregowanych w jednym obiekcie – tak też jest widziany z pozycji administratora. Kiedy tworzony jest Datastore Cluster, Storage DRS może zarządzać zasobami pamięci masowej w taki sam sposób jak zwykły DRS zarządza zasobami hostów w klastrze. Podobnie jak w przypadku klastra hostów Datastore Cluster jest używany do łączenia zasobów pamięci masowej, umożliwiając inteligentne i szybkie umieszczenie nowych maszyn wirtualnych jak i wirtualnych dysków, a także równoważenie obciążenia istniejących. Poniższy rysunek przedstawia Datastore Cluster o pojemności 12 TB tworzony przez cztery 3TB wolumeny.

Storage DRS umożliwiaj automatyczne rozmieszczenie maszyn podczas ich tworzenia, oraz utrzymuje równowagę, pomagając dla administratorów vSphere w podejmowaniu decyzji o rozmieszczeniu maszyn na podstawie miejsca i możliwości I/O konkretnego wolumenu. Podczas tworzenia VM, jako miejsce docelowe można wybrać Datastore Cluster zarówno dla tej maszyny wirtualnej lub jednego z jej wirtualnych dysków. Storage DRS umieści tą maszynę wirtualną na wybranym wolumenie biorąc pod uwagę wolną przestrzeń i możliwości I/O. VMware doszedł do wniosku, że wstępne, ręczne rozlokowanie okazało się być bardzo złożonym procesem w większości środowisk. W rezultacie pozostawianie rezerw takich czynników jak bieżące wykorzystanie przestrzeni i obciążenie I/O były często ignorowane. Storage DRS ma zapewnić zrównoważenie obciążenia poprzez zminimalizowanie ryzyka wąskich gardeł I/O, oraz wykorzystania całej przestrzeni. Poniższy rysunek przedstawia definiowalne progi.

Powyższe zalecenia będą wykonywane wtedy, gdy jeden lub więcej wolumenów w klastrze obiektu DataStore przekroczy skonfigurowane wykorzystanie przestrzeni lub próg opóźnienia I/O. Progi te są zwykle definiowane podczas konfiguracji Datastore Cluster. Storage DRS domyślnie ocenia obciążenie I/O co 8 godzin. Gdy zostanie przekroczone maksimum skonfigurowanego wykorzystania przestrzeni lub opóźnienie I/O przekroczy domyślne 15ms Storage DRS obliczyć wszystkie możliwe ruchy, do zrównoważenia obciążenia odpowiednio przy rozpatrywaniu kosztów i korzyści z migracji.

Storage DRS podobnie jak zwykły DRS oferuje Affinity Rules. Domyślnie maszyny wirtualne i ich wirtualne dyski są trzymane razem na tym samym wolumenie. Affinity rules umożliwiają kontrolę nad tym czy dyski wirtualne być razem czy osobno, an tym samym wolumenie czy na innych, oraz czy powinny „pływać” po różnych datastorach w ramach klastra. Storage DRS oferuje trzy typy reguł powinowactwa:

  • VMDK Anti-Affinity – dyski wirtualne maszyny wirtualnej z wieloma dyskami są umieszczane na różnych wolumenach.
  • VMDK Affinity – dyski wirtualne są trzymane razem na tym samym wolumenie.
  • Anti-VM Affinity – dwie maszyny wirtualne, w tym związane z nimi dyski, są umieszczane na różnych składnicami danych.

Ponadto, przechowalnia DRS oferuje tryb konserwacji Datastore (Maintenance Mode), który automatycznie ewakuuje wszystkich maszyn wirtualnych i ich dyski twarde z wybranego wolumenu na pozostałe datastore w klastrze Storage DRS.
Storage DRS działa zarówno na wolumenach opartych o VMFS i NFS. Jednak ich mieszanie w jednym klastrze nie jest aktualnie obsługiwane.

vSphere Storage API – Storage Awareness

vSphere  Storage API rozszerzyło się o nowy bajer marketingowy – „Storage Awareness” co w tłumaczeniu daje niebagatelnie brzmiącą nazwę „Świadomość Storage”. Jest to nowy zestaw interfejsów, API, które pozwolą VMware vCenter Server wykryć możliwości macierzy i znajdujących się na niej LUN’ów/Datastorów, co znacznie ułatwia wybór odpowiedniego dysku wirtualnego umieszczenia urządzenia lub tworzenie klastrów Stroage DRS. vSphere  Storage API – Storage Awareness ma ułatwiać proces rozwiązywania problemów związanych z urządzeniami dostarczającymi zasoby dyskowe. Dzięki sile (też macie wrażenie, że nazwa jak jakiegoś czaru z Diablo) Świadomości Storage mamy mieć w przystępny sposób zaprezentowane dane o możliwościach przechowywania danych takich jak poziom RAID, thin/thick provisioned, statusie replikacji itp. Wszystko to będziemy mogli zobaczyć w VMware vCenter Server poprzez „system-defined capabilities” dostępnych poprzez Storage Views i SMS API.

vSphere Storage APIs – Array Integration

Mechanizm vSphere  Storage API – Array Integration (VAAI) został wprowadzony z vSphere 4.1, zapewniając odciążenie w trzech podstawowych działaniach:

  • Full copy – umożliwiając dla macierzy wykonanie pełnej kopii danych z macierzy na macierz.
  • Block zeroing – umożliwiając wyzerowanie przez macierz dużej ilości bloków.
  • Hardware-assisted locking – zapewniając alternatywny mechanizm ochrony metadanych VMFS.

Z vSphere 5.0, wsparcie dla podstawowych działań VAAI zostało ulepszone oraz wprowadzono dodatkowe:

  • vSphere Thin Provisioning (Thin Provisioning), umożliwiając odzyskiwanie niewykorzystanego miejsca i monitorowanie wykorzystania przestrzeni dla thin-provisioned LUNs.
  • Sprzętowa akceleracja dla NAS.
  • Standaryzacjia SCSI przez zgodność z T10 dla full copy, block zeroing i hardware-assisted locking.

Profil-Driven Storage

Zarządzanie zasobami dyskowymi oraz dopasowanie do nich wymagań SLA może być trudnym i uciążliwym zadaniem. vSphere 5.0 wprowadza Profile Storage, które umożliwią szybkie i inteligentne rozmieszczenie maszyn wirtualnych w oparciu o SLA dostępności, wydajności lub innych wymagań pod względem przechowywania danych.

Korzystanie z Profili Storage daje możliwość definiowania różnych właściwości składowania. Profile te są używane podczas tworzenia, klonowania i Storage VMotion maszyny wirtualnej miedzy wolumenami w klastrze jak również na niezależnych datastorach. Mają zapewnić, aby maszyna nigdy nie znalazła się na zasobie niegwarantującym jej odpowiednich warunków określonych przez SLA.

Profile Storage korzystają z następujących czynności:

  • Pełna integracja z vSphere  Storage API – Storage Awareness, umożliwiając korzystanie z charakterystyki pamięci masowych.
  • Wsparcie dla NFS, iSCSI i Fibre Channel (FC) i wszystkich macierzy dyskowych na liście HCL.
  • Umożliwienie dla administratora vSphere oznaczania zasobów dyskowych w oparciu o wymagania klienta, lub założenia biznesowe.
  • Korzystanie z charakterystyki przechowywania i/lub zdefiniowanych przez administratora opisów do tworzenia wirtualnych zasad umieszczenia w celu stworzenia Profilu Storage.
  • Zapewnienie łatwego sposobu sprawdzenia przestrzegania zasad. Gwarantuje to, że maszyna wirtualna nie jest migrowana na niestosowne miejsce składowania, lub gdy jest to konieczne administrator jest o tym informowany.

Jak wspomniałem, Profile Storage pozwalają na sprawdzenie zgodności wszystkich maszyn wirtualnych i związanych nimi  z dysków wirtualnych w jednym okienku.

Dodatkowo także umożliwiają podejrzenie zgodności na poziomie maszyny wirtualnej. Daje to możliwość sprawdzania przez użytkowników mających prawa tylko do swoich maszyn, czy stan faktyczny jest zgodny z umową SLA.

Fibre Channel over Ethernet Software Initiator i ulepszenia iSCSI Initiator

Już w wersji vSphere 4.0 wprowadzono wsparcie dla adapterów Fibre Channel over Ethernet (FCoE). Wersja vSphere 5.0 będzie rozwijać ten nurt poprzez wprowadzenie programowych adapterów FCoE. Jednak abyśmy mieli możliwość konfiguracji softwareowego adaptera FCoE nasz interfejs sieciowy musi wspierać technologię częściowego odciążania FCoE (partial FCoE offload capabilities).

Po stworzeniu programowego adaptera FCoE pojawi się nam nowe urządzenie w zakładce Storage Adapters. Dzięki temu bez sprzętowego wsparcia dla FCoE będziemy mogli korzystać z dobrodziejstw tej przyjemnej technologii, a nasza infrastruktura stanie się zdecydowanie bardziej elastyczna.

VMware zdecydowało się na kompletne przepisanie i zoptymalizowanie inicjatora iSCSI. Nowy inicjator iSCSI ma być bardziej wydajny i zdolny do obsłużenia więcej IOPS niż kiedykolwiek wcześniej. Dodano obsługę wielu kart dla VMkernel, aby połączyć się z macierzą iSCSI. Dodatkowo wprowadzono możliwość pełnej konfiguracji iSCSI poprzez vSphere klienta, a nie jak było dotychczas przez konsolę.

Ufff… w następnej odsłonie licencjonowanie.

About the author

Bloger i niezależny konsultant z wieloletnim doświadczeniem w branży IT. Specjalizujący się w wirtualizacji i cloud computingu. Posiada tytuły MCP, MCTS, VCP oraz VMware vExpert.
4 Responses
  1. Witam

    Rozpoczynam dopiero zgłębianie tajników wirtualizacji, ale pojawiło się dręczace mnie pytanie:
    „Dla nas szaraczków oznacza to przede wszystkim uwolnienie się z jarzma 2TB powierzchni dyskowej”
    Mnie nie udało się dopiąć do serwera dysku virtualnego wiekszego niż 2TB 🙁 (datastor ma 4TB), czy zrobiłem cos źle ?

  2. Mam wersję Vware vSphere 5.
    Bez problemu mogę tworzyć datastory większe od 2TB, ale nie mogę stworzyć dysku virtualnego większego od 2TB (wynika to z ograniczenia wielkości pliku VMFS).
    Jakie są sposoby na udostępnienie w systemie gościa powierzchni np. 3-4TB ?

Leave a Reply