W niniejszym artykule chciałbym opisać cechy działania macierzy All Flash AccelStor z jednej z najbardziej popularnych platform wirtualizacji – VMware vSphere. Szczególnie chciałbym zwrócić uwagę na parametry, które pomogą uzyskać maksymalne korzyści z użycia tak potężnego narzędzia jak All Flash.
Macierze All Flash AccelStor NeoSapphire™ są lub węzłami opartymi na pamięci SSD, które w zasadniczy sposób różnią się w podejściu do realizacji koncepcji przechowywania danych i organizacji dostępu do nich z wykorzystaniem własnej technologii zamiast popularnych algorytmów RAID. Macierze oferują blokowy dostęp dla hostów poprzez interfejsy Fibre Channel lub iSCSI. Sprawiedliwie należy zauważyć, że modele z interfejsem iSCSI mają również dostęp plikowy jako miły dodatek. Jednak w ramach niniejszego artykułu skoncentrujemy się na zastosowaniu protokołów blokowych jako najbardziej wydajnych dla All Flash.
Cały proces wdrażania i późniejszej konfiguracji współpracy macierzy AccelStor z systemem wirtualizacji VMware vSphere można podzielić na kilka etapów:
- Realizacja topologii połączenia i konfiguracja sieci SAN;
- Konfiguracja macierzy All Flash;
- Konfiguracja hostów ESXi;
- Konfiguracja maszyn wirtualnych.
W przykładach użyto macierzy AccelStor NeoSapphire™ z interfejsem Fibre Channel i z interfejsem iSCSI. Jako podstawowe oprogramowanie użyto VMware vSphere 6.7U1.
Przed wdrożeniem opisanych w artykule systemów zdecydowanie zaleca się zapoznanie z dokumentacją VMware dotyczącą wydajności ( ) oraz ustawień iSCSI ()
Topologia połączenia i konfiguracja sieci SAN
Podstawowymi komponentami sieci SAN są adaptery HBA w hostach ESXi, przełączniki SAN i węzły macierzy. Typowa topologia takiej sieci wyglądałaby tak:
Pod terminem Switch rozumie się zarówno oddzielny fizyczny przełącznik, jak i zestaw przełączników (Fabric), jak również urządzenie dzielone między różnymi usługami (VSAN w przypadku Fibre Channel i VLAN w przypadku iSCSI). Użycie dwóch niezależnych przełączników/Fabric pozwoli wyeliminować potencjalny punkt awarii.
Bezpośrednie połączenie hostów z macierzą, choć jest obsługiwane, jest zdecydowanie odradzane. Wydajność macierzy All Flash jest wystarczająco wysoka, a do maksymalnej prędkości konieczne jest wykorzystanie wszystkich portów macierzy. Dlatego obecność przynajmniej jednego switcha między hostami a NeoSapphire™ jest obowiązkowa.
Posiadanie dwóch portów w HBA hosta jest również obowiązkowym wymogiem, aby osiągnąć maksymalną wydajność i zapewnić odporność na awarie.
W przypadku korzystania z interfejsu Fibre Channel konieczne jest skonfigurowanie zonowania w celu wykluczenia potencjalnych kolizji pomiędzy inicjatorami a celami. Strefy są budowane na zasadzie „jeden port inicjatora – jeden lub kilka portów macierzy”.
Jeśli połączenie odbywa się poprzez iSCSI w przypadku używania switcha współdzielonego z innymi usługami, konieczne jest izolowanie ruchu iSCSI w ramach oddzielnego VLAN. Zdecydowanie zaleca się również włączenie wsparcia dla Jumbo Frames (MTU = 9000) w celu zwiększenia rozmiarów pakietów w sieci, co pozwala na zmniejszenie ilości danych sterujących podczas transmisji. Należy jednak pamiętać, że dla prawidłowego działania konieczne jest zmodyfikowanie ustawienia MTU na wszystkich komponentach sieci w łańcuchu „inicjator-switch-cel”.
Konfiguracja macierzy All Flash
Macierz dostarczana jest klientom z już utworzonymi grupami . Dlatego nie ma potrzeby podejmowania działań w celu połączenia dysków w jedną strukturę. Wystarczy utworzyć wolumeny o wymaganym rozmiarze i w odpowiedniej liczbie.
Dla wygody dostępna jest funkcjonalność masowego tworzenia kilku wolumenów o zadanej wielkości. Domyślnie tworzone są wolumeny „cienkie”, ponieważ pozwala to na bardziej racjonalne wykorzystanie dostępnej przestrzeni magazynowej (w tym dzięki wsparciu dla Space Reclamation). Z punktu widzenia wydajności różnica między wolumenami „cienkimi” a „grubymi” nie przekracza 1%. Niemniej jednak, jeśli wymagana jest maksymalna wydajność z macierzy, zawsze można przekonwertować dowolny wolumen „cienki” na „gruby”. Należy jednak pamiętać, że taka operacja jest nieodwracalna.
Następnie pozostaje „opublikować” utworzone wolumeny i ustawić dla nich uprawnienia dostępu ze strony hostów za pomocą ACL (adresy IP dla iSCSI i WWPN dla FC) i fizycznego podziału według portów macierzy. Dla modeli iSCSI odbywa się to poprzez utworzenie Target.
W przypadku modeli FC publikacja odbywa się poprzez utworzenie LUN dla każdego portu macierzy.
Aby przyspieszyć proces konfiguracji, hosty można grupować. Co więcej, jeśli na hoście używana jest wieloportowa FC HBA (co w praktyce zdarza się najczęściej), to system automatycznie rozpoznaje, że porty takiej HBA należą do jednego hosta dzięki WWPN, różniącym się o jeden. Obsługiwane jest również zbiorowe utworzenie Target/LUN dla obu interfejsów.
Ważną uwagą w przypadku korzystania z interfejsu iSCSI jest tworzenie dla wolumenów od razu kilku targetów w celu zwiększenia wydajności, ponieważ kolejka na targetie nie może być zmieniana i w rzeczywistości będzie wąskim gardłem.
Konfiguracja hostów ESXi
Ze strony hostów ESXi podstawowa konfiguracja przeprowadzana jest według całkiem oczekiwanego scenariusza. Kolejność działań dla połączenia iSCSI:
- Dodanie Adaptera Software iSCSI (nie jest wymagane, jeśli już został dodany, lub w przypadku użycia Adaptera Hardware iSCSI);
- Utworzenie vSwitch, przez który będzie przechodził ruch iSCSI i dodanie do niego fizycznych uplink i VMkernel;
- Dodanie do Dynamic Discovery adresów macierzy;
- Utworzenie Datastore
Kilka ważnych uwag:
- Ogólnie rzecz biorąc, można również użyć już istniejącego vSwitch, ale w przypadku oddzielnego vSwitch zarządzanie ustawieniami hosta będzie znacznie łatwiejsze.
- Należy oddzielić ruch zarządzania i iSCSI na oddzielnych fizycznych łączach i/lub VLAN w celu uniknięcia problemów z wydajnością.
- Adresy IP VMkernel i odpowiednich portów All Flash macierzy powinny znajdować się w tej samej podsieci znowu ze względów wydajności.
- Aby zapewnić odporność na awarie, zgodnie z zasadami VMware vSwitch musi mieć co najmniej dwa fizyczne uplink.
- Jeśli używane są Jumbo Frames, należy zmienić MTU zarówno w vSwitch, jak i w VMkernel.
- Warto przypomnieć, że zgodnie z zaleceniami VMware dla fizycznych adapterów, które będą używane do pracy z ruchem iSCSI, konieczne jest skonfigurowanie teamingu i przełączania awaryjnego. W szczególności każdy VMkernel powinien działać tylko przez jeden uplink, drugi uplink należy ustawić w tryb unused. Dla zapewnienia odporności na awarie należy dodać dwa VMkernel, z których każdy będzie działał przez swój własny uplink.
Adapter VMkernel (vmk#)
Fizyczny adapter sieciowy (vmnic#)
vmk1 (Storage01)
Aktywne adaptery
vmnic2
Nieużywane adaptery
vmnic3
vmk2 (Storage02)
Aktywne adaptery
vmnic3
Nieużywane adaptery
vmnic2
Aby połączyć się przez Fibre Channel, nie są wymagane żadne wstępne działania. Można od razu tworzyć Datastore.
Po utworzeniu Datastore należy upewnić się, że stosowana jest polityka Round Robin dla ścieżek do Target/LUN jako najbardziej wydajna.
Domyślnie ustawienia VMware zakładają wykorzystanie tej polityki w schemacie: 1000 zapytań przez pierwszą ścieżkę, kolejne 1000 zapytań przez drugą ścieżkę itd. Takie interakcje hosta z dwukontrolerowym macierzą będą niezrównoważone. Dlatego zalecamy ustawienie parametru Round Robin policy = 1 przez Esxcli/PowerCLI.
Ustawienia
Dla Esxcli:
- Wyświetl dostępne LUN
esxcli storage nmp device list
- Skopiuj nazwę urządzenia
- Zmień politykę Round Robin
esxcli storage nmp psp roundrobin deviceconfig set —type=iops —iops=1 —device=«Device_ID»
Większość nowoczesnych aplikacji została zaprojektowana do wymiany dużych pakietów danych w celu maksymalizacji wykorzystania pasma i zmniejszenia obciążenia procesora. Dlatego ESXi domyślnie przesyła zapytania wejścia/wyjścia na urządzenie pamięci masowej w porcjach do 32767KB. Jednak w przypadku niektórych scenariuszy wymiana mniejszych porcji jest bardziej wydajna. W odniesieniu do macierzy AccelStor dotyczą to następujące scenariusze:
- Maszyna wirtualna używa UEFI zamiast Legacy BIOS
- Używane jest replikowanie vSphere
Dla takich scenariuszy zaleca się zmianę wartości parametru Disk.DiskMaxIOSize na 4096.
Dla połączeń iSCSI zaleca się zmianę parametru Login Timeout na 30 (domyślnie 5) w celu zwiększenia stabilności połączenia oraz wyłączenie opóźnienia potwierdzeń przesyłanych pakietów DelayedAck. Obie opcje znajdują się w vSphere Client: Host → Configure → Storage → Storage Adapters → Advanced Options dla adaptera iSCSI.
Kwestia liczby używanych wolumenów dla datastore jest dosyć delikatna. Oczywiste jest, że dla uproszczenia zarządzania rodzi się chęć stworzenia jednego dużego wolumenu dla całej pojemności macierzy. Jednak posiadanie kilku wolumenów i, odpowiednio, datastore pozytywnie wpływa na ogólną wydajność (więcej o kolejkach nieco dalej w tekście). Dlatego zalecamy utworzenie co najmniej dwóch wolumenów.
Jeszcze stosunkowo niedawno VMware zalecała ograniczenie liczby maszyn wirtualnych na jednym datastore w celu uzyskania maksymalnej wydajności. Jednak obecnie, zwłaszcza w dobie VDI, ten problem już nie jest tak istotny. Nie zmienia to jednak zasady – należy rozdzielać maszyny wirtualne, które wymagają intensywnego IO, na różne datastore. Aby określić optymalną liczbę maszyn wirtualnych na jeden wolumen, nie ma nic lepszego niż przeprowadzenie w ramach swojej infrastruktury.
Konfiguracja maszyn wirtualnych
Przy konfiguracji maszyn wirtualnych nie ma szczególnych wymagań, dokładniej są one całkiem standardowe:
- Użycie maksymalnie możliwej wersji VM (kompatybilność)
- Z większą ostrożnością ustalać rozmiar RAM przy gęstym osadzeniu maszyn wirtualnych, na przykład w VDI (ponieważ domyślnie przy uruchamianiu tworzony jest plik stronicowania o wielkości porównywalnej z pamięcią RAM, co zużywa użyteczną pojemność i wpływa na ostateczną wydajność)
- Używać najbardziej wydajnych pod względem IO wersji adapterów: sieciowego typu VMXNET 3 i SCSI typu PVSCSI
- Używać typu dysku Thick Provision Eager Zeroed dla maksymalnej wydajności i Thin Provisioning dla maksymalnie efektywnego wykorzystania przestrzeni dyskowej
- W miarę możliwości ograniczać działanie maszyn mniej krytycznych dla wejścia/wyjścia za pomocą Virtual Disk Limit
- Obowiązkowo instalować VMware Tools
Uwagi o kolejkach
Kolejka (lub Outstanding I/Os) to liczba żądań wejścia/wyjścia (komend SCSI), które czekają na przetworzenie w danym momencie w konkretnym urządzeniu/aplikacji. W przypadku przepełnienia kolejki zgłaszany jest błąd QFULL, co w rezultacie przekłada się na zwiększenie parametru latency. Przy użyciu systemów dyskowych (talerzowych) teoretycznie im wyższa kolejka, tym wyższa ich wydajność. Jednak nie należy przesadzać, ponieważ łatwo można napotkać problem QFULL. W przypadku systemów All Flash z jednej strony jest to nieco prostsze, ponieważ macierz ma opóźnienia o rzędy mniejsze i dlatego często nie wymaga osobnej regulacji rozmiaru kolejek. Z drugiej strony, w niektórych scenariuszach użytkowania (silne odchylenie w wymaganiach dotyczących IO dla konkretnych maszyn wirtualnych, testy maksymalnej wydajności itp.) może być potrzebne, jeśli nie zmieniać parametrów kolejek, to przynajmniej zrozumieć, jakich wskaźników można osiągnąć i, co najważniejsze, jakimi drogami.
Na macierzy All Flash AccelStor nie ma żadnych limitów w odniesieniu do woluminów czy portów wejścia/wyjścia. W razie potrzeby nawet pojedynczy wolumin może uzyskać wszystkie zasoby macierzy. Jedynym ograniczeniem dla kolejek są cele iSCSI. Właśnie z tego powodu wcześniej wskazano na potrzebę utworzenia kilku (w idealnym przypadku do 8 sztuk) celów na każdy wolumin, aby przezwyciężyć ten limit. Powtórzymy również, że macierze AccelStor są bardzo wydajnymi rozwiązaniami. Dlatego należy wykorzystać wszystkie porty interfejsowe systemu, aby osiągnąć maksymalną prędkość.
Ze strony hosta ESXi sytuacja jest zupełnie inna. Sam host stosuje praktykę równego dostępu do zasobów dla wszystkich uczestników. Dlatego istnieją oddzielne kolejki IO do gościnnego systemu operacyjnego i HBA. Kolejki do gościnnego systemu operacyjnego są połączone z kolejkami do wirtualnego adaptera SCSI i wirtualnego dysku:
Kolejka do HBA zależy od konkretnego typu/dostawcy:
Ostateczna wydajność maszyny wirtualnej będzie określana przez najmniejszą wartość wskaźnika kolejki (Queue Depth limit) wśród komponentów hosta.
Dzięki tym wartościom można ocenić wskaźniki wydajności, które możemy uzyskać w danej konfiguracji. Na przykład, chcemy poznać teoretyczną wydajność maszyny wirtualnej (bez odniesienia do bloku) przy opóźnieniu 0,5 ms. W takim przypadku jej IOPS = (1 000 / opóźnienie) * Outstanding I/Os (limit głębokości kolejki)
Przykłady
Przykład 1
- Adapter HBA FC Emulex
- Jedna VM na datastore
- Adapter SCSI VMware Paravirtual
Tutaj limit głębokości kolejki jest określany przez Emulex HBA. Dlatego IOPS = (1000 / 0.5) * 32 = 64K
Przykład 2
- Adapter oprogramowania iSCSI VMware
- Jedna VM na datastore
- Adapter SCSI VMware Paravirtual
Tutaj limit głębokości kolejki określa już adapter Paravirtual SCSI. Dlatego IOPS = (1000 / 0.5) * 64 = 128K
Najwyższe modele macierzy All Flash AccelStor (na przykład, ) są w stanie zapewnić wydajność 700K IOPS przy zapisie przy bloku 4K. Przy takiej wielkości bloku całkowicie jasne jest, że pojedyncza maszyna wirtualna nie jest w stanie obciążyć takiej macierzy. Do tego potrzeba 11 (dla przykładu 1) lub 6 (dla przykładu 2) wirtualek.
W rezultacie, przy prawidłowej konfiguracji wszystkich opisanych komponentów wirtualnego centrum danych, można uzyskać bardzo imponujące wyniki pod względem wydajności.
4K Random, 70% Odczyt / 30% Zapis
W rzeczywistości świat jest o wiele bardziej skomplikowany, aby opisać go prostą formułą. Na jednym hoście zawsze znajduje się wiele maszyn wirtualnych o różnych konfiguracjach i wymaganiach dotyczących IO. Ponadto procesor hosta zajmuje się obsługą operacji we/wy, której moc nie jest nieskończona. Zatem, aby ujawnić pełny potencjał tej samej w rzeczywistości potrzeba co najmniej trzech hostów. Dodatkowo aplikacje pracujące wewnątrz maszyn wirtualnych wprowadzają własne korekty. Dlatego w celu dokładnego określenia wielkości proponujemy macierzy All Flash w infrastrukturze klienta na rzeczywistych zadaniach.
Źródło: habr.com
