VMware VMFS5 i rozmiar LUN - wiele mniejszych magazynów danych lub 1 duży magazyn danych?


10

Ponieważ VMFS5 nie ma już limitu 2 TB dla woluminu VMFS, zastanawiam się, który scenariusz byłby ogólnie bardziej korzystny: -

  • Mniej jednostek LUN o większym rozmiarze lub
  • Więcej jednostek LUN o mniejszych rozmiarach.

W moim przypadku mam nową 24-dyskową macierz pamięci z dyskami 600 GB. Będę używał RAID10, czyli około 7,2 TB, i spróbuję zdecydować, czy pójść z 1 dużym magazynem danych o pojemności 7 TB, czy z wieloma sklepami o pojemności 1 TB każdy.

Jakie są zalety i wady każdego podejścia?

Aktualizacja : Oczywiście, pominąłem uwzględnienie gorących części w moich obliczeniach, więc będzie to nieco poniżej 7,2 TB, ale ogólny pomysł jest taki sam. :-)

Aktualizacja 2 : Istnieje 60 maszyn wirtualnych i 3 hosty. Żadna z naszych maszyn wirtualnych nie jest szczególnie intensywna we / wy. Większość z nich to serwery WWW / aplikacji, a także rzeczy takie jak monitorowanie (Munin / Nagios), 2 kontrolery Windows z minimalnym obciążeniem i tak dalej. Serwery DB rzadko są zwirtualizowane, chyba że mają BARDZO niskie wymagania we / wy. W tej chwili uważam, że jedynym wirtualnym serwerem DB, który mamy, jest skrzynka MSSQL, a DB w tym pudełku wynosi <1 GB.

Aktualizacja 3 : Więcej informacji na temat macierzy i łączności FC. Macierz to IBM DS3524, 2 kontrolery z 2 GB pamięci podręcznej każdy. 4x porty FC 8Gbit na kontroler. Każdy host ESXi ma 2 karty HBA FC 4 Gb / s.


1
Czy masz licencję na korzystanie z StorageDRS?
Chopper3

@ Chopper3: obecnie mamy zwykłe licencje Enterprise, a nie Plus, więc na razie brak StorageDRS.
ThatGraemeGuy

@ThatGraemeGuy Jaka była tego rozdzielczość?
ewwhite

@ewwhite: niestety nie pamiętam. To było tak dawno temu i od roku jestem z dala od tej pracy. :-( Niejasno pamiętam, że utworzyłem 4 magazyny danych VMFS o jednakowej wielkości na macierz 24-dyskową i wiem, że po przejściu na nowe tablice FWIW nie mieliśmy żadnych problemów z We / Wy.
ThatGraemeGuy

Odpowiedzi:


4

Nie określono, ile maszyn wirtualnych masz ani co będą robić. Nawet bez tych informacji unikałbym tworzenia jednej dużej jednostki LUN ze względu na rozmiar / wydajność, rywalizację i elastyczność.


2

Zakładam, że zamierzasz wirtualizować serwery, a nie komputery stacjonarne, dobrze? Następnie założę, że będziesz używać kilku serwerów ESX / ESXi, aby uzyskać dostęp do swojej pamięci i zarządzać nimi przez vCenter Server.

Decydując o wielkości LUN i liczbie VMFS, balansujesz kilka czynników: wydajność, elastyczność konfiguracji i wykorzystanie zasobów, a jednocześnie ogranicza je obsługiwana maksymalna konfiguracja infrastruktury.

Możesz uzyskać najlepszą wydajność dzięki mapowaniu 1 maszyny wirtualnej na 1 jednostkę LUN / VMFS. Nie ma konkurencji między maszynami na tym samym VMFS, brak rywalizacji o blokowanie, każde obciążenie jest oddzielone i wszystko jest dobre. Problem polega na tym, że zamierzasz zarządzać bezbożną liczbą jednostek LUN, możesz osiągnąć obsługiwane maksymalne limity, napotkać bóle głowy przy zmianie rozmiaru i migracji VMFS, mieć niewykorzystane zasoby (te wolne miejsce na jednym punkcie procentowym na VMFS sumują się) i ogólnie stworzyć coś, co nie jest przyjemny w zarządzaniu.

Druga skrajność to jeden wielki VMFS przeznaczony do hostowania wszystkiego. W ten sposób uzyskasz najlepsze wykorzystanie zasobów, nie będzie problemu z podjęciem decyzji o tym, gdzie wdrożyć i problemów z VMFS X będącym gorącym punktem, podczas gdy VMFS Y jest na biegu jałowym. Koszt będzie sumą wydajności. Dlaczego? Z powodu blokowania. Gdy jeden ESX pisze na danym VMFS, inne są zablokowane na czas potrzebny do ukończenia IO i muszą ponowić próbę. To kosztuje wydajność. Poza placami zabaw / środowiskami testowymi i programistycznymi niewłaściwe podejście do konfiguracji pamięci.

Zaakceptowaną praktyką jest tworzenie magazynów danych wystarczająco dużych, aby obsługiwać wiele maszyn wirtualnych, i dzielenie dostępnej przestrzeni dyskowej na porcje o odpowiedniej wielkości. Jaka jest liczba maszyn wirtualnych zależy od maszyn wirtualnych. Możesz potrzebować jednej lub kilku krytycznych baz danych produkcyjnych na VMFS, ale wpuść trzy lub cztery tuziny maszyn testowych i programistycznych do tego samego magazynu danych. Liczba maszyn wirtualnych w magazynie danych zależy również od sprzętu (rozmiar dysku, rpm, pamięć podręczna kontrolerów itp.) I wzorców dostępu (dla dowolnego poziomu wydajności można hostować znacznie więcej serwerów WWW na tym samym VMFS niż serwery poczty).

Mniejsze magazyny danych mają także jeszcze jedną zaletę: zapobiegają fizycznemu zatłoczeniu zbyt wielu maszyn wirtualnych na magazyn danych. Żadna presja zarządzania nie zmieści dodatkowego terabajta dysków wirtualnych w magazynie o pojemności pół terabajta (przynajmniej dopóki nie usłyszą o cienkim udostępnianiu i deduplikacji).

Jeszcze jedno: podczas tworzenia tych magazynów danych standaryzuj jeden rozmiar bloku. Upraszcza to wiele rzeczy później, gdy chcesz coś zrobić w magazynach danych i zobaczyć brzydkie „niezgodne” błędy.

Aktualizacja : DS3k będzie posiadał aktywne / pasywne kontrolery (tzn. Dowolna jednostka LUN może być obsługiwana przez kontroler A lub B, dostęp do jednostki LUN za pośrednictwem kontrolera niebędącego właścicielem powoduje utratę wydajności), więc opłaca się mieć parzystą liczbę jednostek LUN , równomiernie rozmieszczone między kontrolerami.

Mogę sobie wyobrazić, że zacznę od 15 maszyn wirtualnych / jednostek LUN z przestrzenią do około 20.


Nawiasem mówiąc, VMFS5 ma znacznie mniej rywalizacji o blokowanie niż wcześniej.
Chopper3

Dodano dodatkowe informacje na temat maszyn wirtualnych i systemu pamięci masowej.
ThatGraemeGuy

1

Krótka odpowiedź na twoje pytanie brzmi: wszystko zależy od twoich wzorców IO, i będzie to unikalne dla twojego środowiska.

Proponuję zajrzeć tutaj: http://www.yellow-bricks.com/2011/07/29/vmfs-5-lun-sizing/, ponieważ może to pomóc w rozważeniu przewidywanego IOPS i liczby jednostek LUNS. To powiedziawszy, jeśli popełnisz błąd po stronie ostrożności, niektórzy ludzie doradziliby posiadanie wielu jednostek LUNS (jeśli moja korekta poprzedniej odpowiedzi zostanie zatwierdzona, zobacz moje komentarze dotyczące kolejek IUN jednostki LUN po stronie tablicy). Zwykle się zgadzam, ale poszedłbym dalej, aby następnie połączyć je w jeden / kilka woluminów VMFS (nie wierzcie FUD w zakresy i inne ograniczenia VMFS http://virtualgeek.typepad.com/virtual_geek/2009/03 /vmfs-best-practices-and-counter-fud.html). Przyniesie to korzyść w zakresie zarządzania jednym / kilkoma magazynami danych w ramach vSphere, a ponieważ vSphere automatycznie równoważy maszyny wirtualne w dostępnych zakresach, zaczynając od pierwszego bloku każdego zakresu, korzyści w zakresie wydajności rozkładają twoje IO na wiele jednostek LUN.

Coś innego do rozważenia ... Mówisz, że żadna z maszyn wirtualnych nie jest szczególnie intensywna we / wy. Biorąc to pod uwagę, możesz rozważyć połączenie RAID5 i RAID10, aby uzyskać to, co najlepsze z obu światów (przestrzeń i prędkość).

Ponadto, jeśli masz maszyny wirtualne skonfigurowane z wieloma VMDK, a wzorce IO systemu operacyjnego i aplikacji są rozproszone na tych dyskach wirtualnych (tj. OS, WWW, DB, dzienniki itp. Na oddzielnym VMDK), możesz następnie zlokalizować każdy VMDK na inny magazyn danych pasujący do możliwości IO tej fizycznej jednostki LUN (np. OS na RAID5, Logs na RAID10). Chodzi o zachowanie podobnych wzorców We / Wy, aby skorzystać z mechanicznego zachowania bazowych dysków, aby na przykład zapisy dziennika na jednej maszynie wirtualnej nie wpływały na szybkość odczytu sieci na innej maszynie wirtualnej.

FYI ... no może z powodzeniem wirtualizacji serwerów DB, wystarczy przeanalizować IO Patterns & IOPS ceny i cel, który IO do odpowiedniej jednostki LUN; cały czas będąc świadomym wzorców IOPS i IOPS, które ta LUN już robi. To dlatego wielu administratorzy winni virtualiseation dla słabych wyników DB ... bo one nie dokładnie obliczyć IO / IOPS że wiele serwerów będzie generować gdy oni umieścić je na wspólnej LUN (tj. Do zarzucenia administratorów, nie jest wina wirtualizacji ).


0

Każdy wolumin (LUN) ma swoją własną głębokość kolejki, więc aby uniknąć rywalizacji o IO, wiele implementacji wykorzystuje więcej mniejszych jednostek LUN. To powiedziawszy, dość łatwo można utworzyć jednostki LUN dotyczące magazynu danych. Wadą większych (i mniej) magazynów danych VMWare jest, o ile mi wiadomo, że możesz napotkać pewne ograniczenia dotyczące liczby maszyn wirtualnych, które mogą być włączone jednocześnie.


0

Inną kwestią jest wydajność kontrolera. Nie znam konkretnie Twojej sieci SAN, ale większość, jeśli nie wszystkie, sieci SAN wymagały, aby jednostka LUN była własnością pojedynczego kontrolera naraz. Chcesz mieć wystarczającą liczbę jednostek LUN w systemie, aby móc zrównoważyć obciążenie pracą między kontrolerami.

Na przykład, jeśli masz tylko jedną jednostkę LUN, będziesz używać tylko jednego aktywnego kontrolera na raz. Drugi siedziałby bezczynnie, ponieważ nie miałby nic do roboty.

Gdybyś miał dwie jednostki LUN, ale jedna była znacznie bardziej obciążona od drugiej, używałbyś obu kontrolerów, ale nie równo. W miarę dodawania kolejnych jednostek LUN kontrolery dzielą obciążenie bardziej równomiernie.

Szczegółowe porady dla Ciebie:

Wszystkie maszyny wirtualne są względnie takie same pod względem wymagań wydajnościowych. Utworzyłbym dwie jednostki LUN, po jednej na kontroler. Zacznij umieszczać maszyny wirtualne na pierwszej jednostce LUN i mierz opóźnienie we / wy oraz głębokość kolejki w miarę, jak maszyny wirtualne się wprowadzają. Nie używaj jeszcze drugiej jednostki LUN. Kontynuuj wypełnianie jednostki LUN 1. Osiągniesz punkt, w którym zaczniesz widzieć wskaźniki wydajności, że jednostka LUN jest pełna, lub przeprowadzisz migrację połowy maszyn wirtualnych do tej jednostki LUN i nadal utrzymasz wydajność.

Jeśli zauważysz problemy z wydajnością, usunę 30% maszyn wirtualnych z jednostki LUN 1 i przeniosę je do jednostki LUN 2. Następnie zacznę wypełniać jednostkę LUN 2 w ten sam sposób. W razie potrzeby przejdź do jednostki LUN 3 ... czy to ma sens? Chodzi o to, aby osiągnąć maksymalną gęstość VM na danej jednostce LUN wraz z około 30% narzutem dla miejsca na krówki.

Zrobiłbym również parę „wysokowydajnych” jednostek LUN dla dowolnych maszyn wirtualnych o dużym trafieniu. Ponownie, jeden na kontroler do podziału obciążenia.


-1

W oparciu o powyższe wyjaśnienia powinieneś być w porządku z 1 magazynem danych. 60 VM ponad 3 hostami nie jest aż tak zła (20: 1). Poleciłbym jednak uaktualnić kartę HBA do 8 Gb, jeśli jest to finansowo możliwe na co najmniej jednym hoście, pod warunkiem, że twój przełącznik światłowodowy jest przełącznikiem co najmniej 8 Gb.

Biorąc to pod uwagę, utworzę co najmniej 2, jeśli nie 3 magazyny danych w tablicy. 1 magazyn danych na host, ze wszystkimi serwerami uzyskującymi dostęp do innych dla vMotion. Nie wiem wiele o tablicy IBM; z EMC stworzyłbym pojedynczą grupę RAID10 z 3 jednostkami LUN dla każdego magazynu danych. Dzięki tej konfiguracji host z kartami HBA 8 Gb byłby świetny dla Twoich wyższych systemów I / O.

Możesz zrobić 1 magazyn danych / serwer, i są takie przypadki, które robię sam, ale robię to tylko z replikacją SAN na specjalnych serwerach. Zarządzanie 87 różnymi magazynami danych na 9 serwerach dla vMotion staje się mylące po skonfigurowaniu! Większość moich maszyn wirtualnych znajduje się we współdzielonych magazynach danych z 5-10 serwerami na nich, w zależności od potrzebnej przestrzeni.

Ostatnia uwaga. Jeśli masz jakieś serwery w parze przełączania awaryjnego / klastrze lub zrównoważone obciążenie, będziesz chciał, aby były w różnych magazynach danych. Nie chcesz, aby magazyn danych zawiódł, a następnie nie pozostanie bez serwerów. Trzeba przyznać, że jeśli zgubisz tablicę, stracisz wszystko, ale właśnie dlatego wykonujemy kopię zapasową, prawda?


2
Trudno mi uwierzyć, że OP będzie potrzebował przepustowości większej niż 2x4 Gb, a nawet 1x 4 Gb. Czy potrafisz wyjaśnić, dlaczego warto było to ulepszenie, oprócz tego, że „im więcej, tym lepiej”? Również utworzenie 3 magazynów danych wydaje się być dobrą równowagą, ale powiedzenie „jeden na host” jest mylące, ponieważ oczywiście wszystkie magazyny danych będą dostępne dla wszystkich hostów. W przeciwnym razie nie będzie można użyć Storage vMotion, vMotion ani HA ...
Jeremy

Nie mówię, że dodaj 8 Gb na całej planszy, jak powiedziałem, to zalecenie, a nie wymóg. 2x4Gb jest świetny i nigdy nie zrobiłbym 1x4Gb tylko dlatego, że potrzebujesz zbędnej ścieżki. Zainstalowanie go na jednym pozwala na dowolną rozbudowę do wyższych systemów I / O. Do licha, obecnie używam naszego systemu Exchange z kartami HBA 2x4 Gb, ale mają one tylko 3-4 maszyn wirtualnych na host.
ARivera3483
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.