W tym artykule chciałbym omówić możliwości macierzy All Flash AccelStor współpracujących z jedną z najpopularniejszych platform wirtualizacyjnych – VMware vSphere. W szczególności skup się na tych parametrach, które pomogą Ci uzyskać maksymalny efekt przy użyciu tak potężnego narzędzia, jak All Flash.
AccelStor NeoSapphire™ Wszystkie macierze Flash są lub urządzenia węzłowe oparte na dyskach SSD charakteryzujące się zasadniczo odmiennym podejściem do realizacji koncepcji przechowywania danych i organizacji dostępu do nich z wykorzystaniem autorskiej technologii zamiast bardzo popularnych algorytmów RAID. Macierze zapewniają blokowy dostęp do hostów za pośrednictwem interfejsów Fibre Channel lub iSCSI. Aby być uczciwym, zauważamy, że modele z interfejsem ISCSI mają również dostęp do plików, co jest miłym dodatkiem. Jednak w tym artykule skupimy się na wykorzystaniu protokołów blokowych jako najbardziej produktywnych dla All Flash.
Cały proces wdrożenia i późniejszej konfiguracji wspólnego działania macierzy AccelStor i systemu wirtualizacji VMware vSphere można podzielić na kilka etapów:
- Implementacja topologii połączeń i konfiguracja sieci SAN;
- Konfigurowanie tablicy All Flash;
- Konfiguracja hostów ESXi;
- Konfigurowanie maszyn wirtualnych.
Jako przykładowy sprzęt wykorzystano macierze AccelStor NeoSapphire™ Fibre Channel i macierze iSCSI. Oprogramowanie bazowe to VMware vSphere 6.7U1.
Przed wdrożeniem systemów opisanych w tym artykule zdecydowanie zaleca się zapoznanie się z dokumentacją firmy VMware dotyczącą problemów z wydajnością ( ) i ustawienia iSCSI ()
Topologia połączeń i konfiguracja sieci SAN
Głównymi komponentami sieci SAN są karty HBA w hostach ESXi, przełączniki SAN i węzły macierzy. Typowa topologia takiej sieci wyglądałaby następująco:
Termin przełącznik odnosi się tutaj zarówno do oddzielnego przełącznika fizycznego lub zestawu przełączników (Fabric), jak i do urządzenia współdzielonego pomiędzy różnymi usługami (VSAN w przypadku Fibre Channel i VLAN w przypadku iSCSI). Użycie dwóch niezależnych przełączników/tkanin wyeliminuje możliwy punkt awarii.
Bezpośrednie połączenie hostów z macierzą, choć obsługiwane, zdecydowanie nie jest zalecane. Wydajność tablic All Flash jest dość wysoka. Aby uzyskać maksymalną prędkość, należy wykorzystać wszystkie porty macierzy. Dlatego obecność co najmniej jednego przełącznika pomiędzy hostami a NeoSapphire™ jest obowiązkowa.
Obecność dwóch portów na karcie HBA hosta jest również obowiązkowym wymogiem w celu osiągnięcia maksymalnej wydajności i zapewnienia odporności na awarie.
W przypadku korzystania z interfejsu Fibre Channel należy skonfigurować podział na strefy, aby wyeliminować możliwe kolizje między inicjatorami i obiektami docelowymi. Strefy budowane są na zasadzie „jeden port inicjatora – jeden lub więcej portów macierzy”.
Jeśli korzystasz z połączenia poprzez iSCSI w przypadku korzystania z przełącznika współdzielonego z innymi usługami, wówczas konieczne jest izolowanie ruchu iSCSI w ramach osobnej sieci VLAN. Zdecydowanie zaleca się także włączenie obsługi ramek Jumbo (MTU = 9000), aby zwiększyć rozmiar pakietów w sieci, a tym samym zmniejszyć ilość informacji narzutowych podczas transmisji. Warto jednak pamiętać, że do poprawnego działania konieczna jest zmiana parametru MTU na wszystkich elementach sieci w łańcuchu „inicjator-przełącznik-cel”.
Konfigurowanie tablicy All Flash
Macierz dostarczana jest klientom posiadającym już utworzone grupy . Dlatego nie trzeba podejmować żadnych działań, aby połączyć dyski w jedną strukturę. Wystarczy utworzyć woluminy o wymaganym rozmiarze i ilości.
Dla wygody istnieje możliwość wsadowego tworzenia kilku woluminów o danym rozmiarze jednocześnie. Domyślnie tworzone są woluminy cienkie, ponieważ pozwala to na bardziej efektywne wykorzystanie dostępnej przestrzeni dyskowej (w tym obsługę odzyskiwania przestrzeni). Pod względem wydajności różnica między objętościami „cienkimi” i „grubymi” nie przekracza 1%. Jeśli jednak chcesz „wycisnąć cały sok” z tablicy, zawsze możesz przekonwertować dowolną „cienką” objętość na „grubą”. Należy jednak pamiętać, że taka operacja jest nieodwracalna.
Następnie pozostaje „opublikować” utworzone woluminy i ustawić prawa dostępu do nich z hostów za pomocą list ACL (adresy IP dla iSCSI i WWPN dla FC) oraz fizyczną separację portami macierzy. W przypadku modeli iSCSI odbywa się to poprzez utworzenie obiektu docelowego.
W przypadku modeli FC publikowanie odbywa się poprzez utworzenie jednostki LUN dla każdego portu macierzy.
Aby przyspieszyć proces konfiguracji, hosty można łączyć w grupy. Co więcej, jeśli host korzysta z wieloportowej karty HBA FC (co w praktyce zdarza się najczęściej), wówczas system automatycznie określa, że porty takiej karty HBA należą do jednego hosta dzięki różnicującym się o jeden numerom WWPN. W przypadku obu interfejsów obsługiwane jest także wsadowe tworzenie obiektów docelowych/jednostek LUN.
Ważną uwagą dotyczącą korzystania z interfejsu iSCSI jest utworzenie wielu obiektów docelowych dla woluminów jednocześnie w celu zwiększenia wydajności, ponieważ kolejki na obiekcie docelowym nie można zmienić i będzie to stanowić wąskie gardło.
Konfigurowanie hostów ESXi
Po stronie hosta ESXi podstawowa konfiguracja odbywa się według całkowicie oczekiwanego scenariusza. Procedura połączenia iSCSI:
- Dodaj programowy adapter iSCSI (nie jest wymagany, jeśli został już dodany lub jeśli używasz sprzętowego adaptera iSCSI);
- Stworzenie vSwitcha, przez który będzie przechodził ruch iSCSI oraz dodanie do niego fizycznego łącza nadrzędnego i VMkernal;
- Dodawanie adresów tablic do Dynamic Discovery;
- Tworzenie magazynu danych
Kilka ważnych uwag:
- W ogólnym przypadku oczywiście można wykorzystać istniejący vSwitch, ale w przypadku osobnego vSwitcha zarządzanie ustawieniami hosta będzie znacznie łatwiejsze.
- Aby uniknąć problemów z wydajnością, konieczne jest rozdzielenie ruchu związanego z zarządzaniem i iSCSI na osobne łącza fizyczne i/lub sieci VLAN.
- Adresy IP VMkernal i odpowiadające im porty macierzy All Flash muszą znajdować się w tej samej podsieci, ponownie ze względu na problemy z wydajnością.
- Aby zapewnić odporność na awarie zgodnie z zasadami VMware, vSwitch musi mieć co najmniej dwa fizyczne łącza nadrzędne
- Jeśli używane są ramki Jumbo, musisz zmienić MTU zarówno vSwitch, jak i VMkernal
- Warto przypomnieć, że zgodnie z zaleceniami VMware dotyczącymi adapterów fizycznych, które będą wykorzystywane do pracy z ruchem iSCSI, konieczne jest skonfigurowanie Teamingu i Failover. W szczególności każdy VMkernal musi pracować tylko przez jedno łącze w górę, drugie łącze w górę musi zostać przełączone w tryb nieużywany. Aby zapewnić odporność na awarie, musisz dodać dwa VMkernals, z których każdy będzie działał poprzez własne łącze nadrzędne.
Adapter jądra VM (vmk#)
Fizyczna karta sieciowa (vmnic#)
vmk1 (Pamięć01)
Aktywne adaptery
vmnic2
Nieużywane adaptery
vmnic3
vmk2 (Pamięć02)
Aktywne adaptery
vmnic3
Nieużywane adaptery
vmnic2
Aby połączyć się za pośrednictwem protokołu Fibre Channel, nie są wymagane żadne wstępne kroki. Możesz od razu utworzyć Datastore.
Po utworzeniu magazynu danych należy upewnić się, że zasada Round Robin dla ścieżek do obiektu docelowego/jednostki LUN jest używana jako najskuteczniejsza.
Domyślnie ustawienia VMware przewidują stosowanie tej polityki według schematu: 1000 żądań pierwszą ścieżką, kolejne 1000 żądań drugą ścieżką itd. Taka interakcja między hostem a macierzą z dwoma kontrolerami będzie niezrównoważona. Dlatego zalecamy ustawienie parametru zasady Round Robin = 1 za pośrednictwem Esxcli/PowerCLI.
Parametry
Dla Esxcli:
- Lista dostępnych jednostek LUN
lista urządzeń nmp pamięci masowej esxcli
- Skopiuj nazwę urządzenia
- Zmień zasady okrężne
esxcli Storage nmp psp roundrobin zestaw konfiguracji urządzenia — typ = iops — iops = 1 — urządzenie = „ID_urządzenia”
Większość nowoczesnych aplikacji jest zaprojektowana do wymiany dużych pakietów danych w celu maksymalnego wykorzystania przepustowości i zmniejszenia obciążenia procesora. Dlatego ESXi domyślnie wysyła żądania we/wy do urządzenia pamięci masowej w fragmentach o wielkości do 32767 KB. Jednak w niektórych scenariuszach wymiana mniejszych fragmentów będzie bardziej produktywna. W przypadku tablic AccelStor są to następujące scenariusze:
- Maszyna wirtualna używa UEFI zamiast starszego BIOS-u
- Używa replikacji vSphere
W takich scenariuszach zaleca się zmianę wartości parametru Disk.DiskMaxIOSize na 4096.
W przypadku połączeń iSCSI zaleca się zmianę parametru Login Timeout na 30 (domyślnie 5), aby zwiększyć stabilność połączenia i wyłączyć opóźnienie DelayedAck dla potwierdzeń przesyłanych pakietów. Obie opcje są dostępne w kliencie vSphere: Host → Konfiguruj → Pamięć → Adaptery pamięci → Opcje zaawansowane adaptera iSCSI
Dość subtelną kwestią jest liczba woluminów używanych w magazynie danych. Oczywiste jest, że dla ułatwienia zarządzania istnieje potrzeba utworzenia jednego dużego woluminu dla całej objętości tablicy. Jednak obecność kilku woluminów i odpowiednio magazynu danych ma korzystny wpływ na ogólną wydajność (więcej o kolejkach poniżej). Dlatego zalecamy utworzenie co najmniej dwóch woluminów.
Jeszcze stosunkowo niedawno firma VMware zalecała ograniczenie liczby maszyn wirtualnych w jednym magazynie danych, ponownie w celu uzyskania jak najwyższej wydajności. Jednak obecnie, zwłaszcza w obliczu rozprzestrzeniania się VDI, problem ten nie jest już tak dotkliwy. Nie anuluje to jednak starej zasady — dystrybucji maszyn wirtualnych wymagających intensywnego operacji we/wy do różnych magazynów danych. Aby określić optymalną liczbę maszyn wirtualnych na wolumin, nie ma nic lepszego niż w ramach swojej infrastruktury.
Konfigurowanie maszyn wirtualnych
Przy konfigurowaniu maszyn wirtualnych nie ma specjalnych wymagań, a raczej są one całkiem zwyczajne:
- Korzystanie z najwyższej możliwej wersji maszyny wirtualnej (kompatybilność)
- Ostrożniej jest ustawiać rozmiar pamięci RAM podczas gęstego umieszczania maszyn wirtualnych, na przykład w VDI (ponieważ domyślnie przy uruchomieniu tworzony jest plik strony o rozmiarze proporcjonalnym do pamięci RAM, co zużywa użyteczną pojemność i ma wpływ na ostatni występ)
- Użyj najbardziej wydajnych wersji adapterów pod względem IO: typ sieciowy VMXNET 3 i typ SCSI PVSCSI
- Użyj typu dysku typu Thick Provision Eager Zeroed, aby uzyskać maksymalną wydajność, lub typu Thin Provisioning, aby maksymalnie wykorzystać przestrzeń dyskową
- Jeśli to możliwe, ogranicz działanie maszyn niemających krytycznego znaczenia we/wy za pomocą programu Virtual Disk Limit
- Pamiętaj, aby zainstalować narzędzia VMware
Uwagi dotyczące kolejek
Kolejka (lub zaległe wejścia/wyjścia) to liczba żądań wejścia/wyjścia (polecenia SCSI), które w dowolnym momencie oczekują na przetworzenie dla określonego urządzenia/aplikacji. W przypadku przepełnienia kolejki generowane są błędy QFULL, co ostatecznie skutkuje wzrostem parametru opóźnienia. W przypadku korzystania z dyskowych (wrzecionowych) systemów pamięci masowej teoretycznie im wyższa kolejka, tym wyższa ich wydajność. Nie należy go jednak nadużywać, ponieważ łatwo jest natknąć się na QFULL. W przypadku systemów All Flash z jednej strony wszystko jest nieco prostsze: w końcu macierz ma opóźnienia o rząd wielkości mniejsze i dlatego najczęściej nie ma potrzeby osobnego regulowania wielkości kolejek. Ale z drugiej strony, w niektórych scenariuszach użycia (silne zniekształcenie wymagań IO dla konkretnych maszyn wirtualnych, testy maksymalnej wydajności itp.) konieczna jest, jeśli nie zmiana parametrów kolejek, to przynajmniej zrozumienie, jakie wskaźniki można osiągnąć, a najważniejsze jest, w jaki sposób.
W samej macierzy AccelStor All Flash nie ma żadnych ograniczeń w odniesieniu do woluminów lub portów we/wy. W razie potrzeby nawet pojedynczy wolumin może przyjąć wszystkie zasoby tablicy. Jedynym ograniczeniem kolejki są obiekty docelowe iSCSI. Z tego też powodu powyżej wskazano konieczność stworzenia kilku (najlepiej do 8 sztuk) celów dla każdego tomu, aby pokonać ten limit. Powtórzmy też, że macierze AccelStor to bardzo produktywne rozwiązania. Dlatego, aby osiągnąć maksymalną prędkość, należy wykorzystać wszystkie porty interfejsu systemu.
Po stronie hosta ESXi sytuacja jest zupełnie inna. Sam gospodarz stosuje praktykę równego dostępu do zasobów dla wszystkich uczestników. Dlatego istnieją oddzielne kolejki we/wy dla systemu gościa i karty HBA. Kolejki do systemu gościa są łączone z kolejek do wirtualnego adaptera SCSI i dysku wirtualnego:
Kolejka do karty HBA zależy od konkretnego typu/dostawcy:
Ostateczna wydajność maszyny wirtualnej zostanie określona na podstawie najniższego limitu głębokości kolejki wśród komponentów hosta.
Dzięki tym wartościom możemy ocenić wskaźniki wydajności, jakie możemy uzyskać w danej konfiguracji. Na przykład chcemy poznać teoretyczną wydajność maszyny wirtualnej (bez wiązania bloków) z opóźnieniem 0.5 ms. Wtedy jego IOPS = (1,000/opóźnienie) * Znakomite we/wy (limit głębokości kolejki)
Примеры
Przykład 1
- Adapter HBA FC Emulex
- Jedna maszyna wirtualna na magazyn danych
- Parawirtualny adapter SCSI VMware
Tutaj limit głębokości kolejki jest określany przez Emulex HBA. Zatem IOPS = (1000/0.5)*32 = 64 tys
Przykład 2
- Adapter oprogramowania VMware iSCSI
- Jedna maszyna wirtualna na magazyn danych
- Parawirtualny adapter SCSI VMware
W tym przypadku limit głębokości kolejki jest już określony przez parawirtualny adapter SCSI. Zatem IOPS = (1000/0.5)*64 = 128 tys
Najlepsze modele macierzy All Flash AccelStor (np. ) są w stanie zapewnić wydajność zapisu 700 tys. IOPS w bloku 4K. Przy takim rozmiarze bloku jest całkiem oczywiste, że pojedyncza maszyna wirtualna nie jest w stanie załadować takiej tablicy. Aby to zrobić, będziesz potrzebować 11 (na przykład 1) lub 6 (na przykład 2) maszyn wirtualnych.
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 losowo, 70% odczytu, 30% zapisu
Tak naprawdę świat rzeczywisty jest o wiele bardziej złożony, niż można to opisać prostym wzorem. Jeden host zawsze obsługuje wiele maszyn wirtualnych o różnych konfiguracjach i wymaganiach we/wy. Za przetwarzanie we/wy odpowiada procesor hosta, którego moc nie jest nieskończona. Aby odblokować pełny potencjał tego samego w rzeczywistości będziesz potrzebować trzech hostów. Ponadto aplikacje działające na maszynach wirtualnych dokonują własnych dostosowań. Dlatego też dla dokładnego wymiarowania oferujemy Wszystkie tablice Flash wewnątrz infrastruktury Klienta na realnie bieżących zadaniach.
Źródło: www.habr.com